S3 バックエンド
本サンプルでは OpenTofu を IaC として利用することで AWS リソースをプログラム実行することで生成しています。 OpenTofu は登録管理してあるリソースのデータベースを .tfstate というファイル(デフォルトでは terraform.tfstate)で管理します。 (Purpose of Terraform State)
OpenTofu の操作を複数人で行う場合、.tfstate を共有する必要があります。 (The terraform_remote_state Data Source) 方法はいくつかありますが、 バックエンドを選択することで指定することができます。
本サンプルではS3 バックエンドを利用しています。
DynamoDB でのロック管理
リソースの更新状態に対してロックをかける必要があります。 (State Locking)
S3バックエンド では DynamoDB のテーブルでロック管理できるようになっています。
S3 バックエンドの構築
実際に構築するための OpenTofu の実行で、同時にバックエンドリソースを作ることができないので、まずバックエンドリソース(S3 と DynamoDB) をつくります。
OpenTofu をつかってバックエンドリソースを構築します:
docker compose run --rm tool tofu -chdir=tofu/admin initdocker compose run --rm tool tofu -chdir=tofu/admin plan -out admin.plandocker compose run --rm tool tofu -chdir=tofu/admin apply admin.plan
本サンプルでの OpenTofu のディレクトリツリー
tofu ディレクトリにソースコードを管理しています。
% tree tofu -dtofu├── admin├── modules│ ├── apigw│ ├── aurora│ ├── bedrock│ ├── ecr│ ├── saving│ ├── tfstate│ ├── tools│ └── vpc└── rag
以下の内容のリソースを構築します:
| ディレクトリ | 内容 |
| admin | OpenTofu のバックエンドリソース構築 (S3, DynamoDB) |
| rag | 本サンプルで実際に構築するリソース |
| modules | それぞれのリソース定義を モジュール化 |
modules については次で説明します。
モジュール化
moduels はさらにリソースごとに分けられています:
| ディレクトリ | 内容 |
| tfstate | OpenTofu バックエンドリソースの管理 |
| vpc | VPC(RDS のネットワークなどの定義する) |
| aurora | RDS で PostgreSQL を構築 |
| ecr | Docker イメージを管理 |
| bedrock | Bedrock Knowledge Base 関連を構築 |
| apigw | Web API インターフェースと処理の実装 |
| tools | savingで使うツールセット |
| saving | Auroro を夜間停止 |
これらのモジュールを組み合わせて admin と rag の構築を行うようにしています。
このような構成を採用するメリットは以下の２点です:
1.似たような AWS プロジェクトにコピペして使いやすい。
2.同一リソースを複数環境で定義しやすい。(例えば、 rag_prod, rag_stage のように分けるなど)
リソースネーミングルール
本サンプルでは {サービス名}-{環境} をリソースのプレフィックスとして使うようにしています。
symbol = { service = var.service env = var.env prefix = "${var.service}-${var.env}" }
これらは、環境変数で定義できるようにしています。 (TF_VAR_ をプレフィックスにつけた変数 (Environment Variables))
何もしていないと sample-ai がリソースのプレフィックスになります。
リージョン us-west-2
本サンプルではAnthropic Claude 3 Sonnet で Knowledge base を動作させたいので、 us-west-2 で全てのリソースを作っています。