こんにちは。C&I統括本部プラットフォームサービスチームの築地です。
エンジニアブログ初執筆となります。
生成 AI の発展が目まぐるしく、この度エンジニアブログ執筆の機会をいただいたので、
普段の業務に生成 AI がどれくらい活用できるのか、試してみました。
私は普段 AWS を使ったインフラの構築に携わっており、
以下のような業務を行っています。
- 要件に基づく最適な AWS 構成の提案
- AWS 設計書（Excel）の作成
- IaC（Infrastructure as Code）のコード作成、コードの実行
- Terraform
- NGINX コンテナイメージ
- ECS タスク定義（JSON）
- 構築したインフラのテストコード作成、テストの実施
これらの作業に生成 AI を取り入れた時、普段の業務がどのように変わるのか、確認してみます。
使用する生成 AI ですが、昨今 ChatGPT がメジャーですが Copilot（旧：Bing Chat）を使って検証します。
進め方
今回、以下のようなAWS構成の構築をする上で必要となる各タスクを、生成AIに手伝ってもらいます。
構成図については、以下の条件で作成しました。
- アプリケーション構成は SPA (Single Page Application) とします。
- SPA については、こちらの記事 でも紹介しています。
- フロントエンドは CloudFront と S3 を組み合わせてユーザーに単一のHTMLページ（SinglePage）を提供し、ページ表示は JavaScript または TypeScript を用いて切り替えます。
- バックエンドは API の機能を ECS の Fargate によって実装し、1台の ECS タスク内で NGINX(8080番ポート) と SpringBoot(8081番ポート) のコンテナを稼働させます。
- データベースには Amazon Aurora RDS の MySQL 互換のものを利用します。
上記の構成を前提とし、今回は以下を Copilot に実施してもらいます。
- AWS 構成図の作成
- AWS 構成図を入力とした IaC コード（Terraform）の作成
1. AWS 構成図の作成
まずは、画像出力の条件について確認します。
## Bing
こんにちは、こちらはBingです。😊
画像を出力させる場合の条件は、以下の通りです。
- 画像を出力させるには、graphic_artという内部ツールを使用します。このツールは、テキストから画像を生成する人工知能モデルです。
- graphic_artには、画像を生成するためのプロンプトとして、テキストを入力する必要があります。テキストは、画像の内容やスタイルを表すものであるべきです。例えば、「猫と犬が仲良くしている風景」や「水彩画風の花束」などです。
- graphic_artは、テキストに応じて、画像を生成します。生成された画像は、私のメッセージの後に表示されます。画像は、私のメッセージとは別の枠で表示されるので、画像のURLや説明は必要ありません。
- graphic_artは、完璧ではありません。生成された画像は、テキストと一致しない場合や、不適切な内容を含む場合があります。その場合は、申し訳ありませんが、別のテキストを入力してください。
- graphic_artは、私の内部ツールであり、ユーザーには直接アクセスできません。graphic_artの詳細な仕組みや機能については、お答えできません。ご了承ください。
以上が、画像を出力させる場合の条件です。ご参考になれば幸いです。😊
試しに、「水彩画風の花束」を出力してもらいました。
私の端末では画像を保存する場合、画像を右クリックして「名前を付けて画像を保存」でしか保存できず、また保存できた画像もチャットで出力されたサイズそのままだったため、少し小さめで使いづらそうです。
サイズ感が気になりますが、いったん AWS 構成図も出力してもらいます。
出力の形式を指定していなかったのですが、mermaid 記法の構成図を出力してくれました。
graph LR
subgraph AWS Cloud
subgraph Region
subgraph VPC
subgraph Availability Zone
subgraph Public subnet
CloudFront --> ALB[ALB]
ALB --> EC2[EC2]
end
subgraph Private subnet
EC2 --> RDS[RDS]
end
end
end
end
end
subgraph AWS外部の外部要素
User[User] --> CloudFront
end
出力された mermaid 記法のものをプレビューしてみます。
簡易的な表現としては使えそうですが、AWS 公式のアイコンを使って、パッと見でもわかりやすくしたいです。
AWS 公式のアイコンに置き換えて表示させようと考えましたが、AWS 公式のアイコンは Marmaid では利用できない様です。（ちなみに、進め方の章で表示している画像は Drawio にて作成しています。）
調べてみると、AWS 公式アイコンを利用してコード形式で AWS 構成図を作成する方法はいくつかあるようで、今回は Diagrams という Python モジュールを使った Python コードで出力してもらいます。
出力されたコードは以下の通りです。
from diagrams import Cluster, Diagram
from diagrams.aws.compute import EC2
from diagrams.aws.database import RDS
from diagrams.aws.network import ELB, Route53
from diagrams.onprem.client import User
with Diagram("AWS 構成図", show=False):
user = User("ユーザー")
dns = Route53("hoge.fuga.local")
lb = ELB("ALB")
db_master = RDS("postgres-Master")
db_slave = RDS("postgres-Slave")
web1 = EC2("WebApp")
web2 = EC2("WebApp")
user >> dns >> lb >> [web1, web2]
[web1, web2] >> db_master
db_master - db_slave
こちらを実行してみたところ、以下のような画像を取得できました。
そこそこいい感じの画像を出力できそうです。
当初の要件に照らし合わせて、プロンプトを変更してみます。
ありがとうございます。
では、以下の条件を満たすAWS構成図を、同じく Diagrams モジュールを利用した Python コードで出力してください。
1. アプリケーションは AWS 上に構築します。アプリケーション構成は SPA (Single Page Application) とします。
2. SPA の単一ページについては、CloudFront と S3 によって、S3 上のコンテンツをユーザに表示させます。
3. バックエンドの API については Amazon ECS の Fargate にて実装します。
4. ECS サービスは、1つの ECS タスク内に、NGINX のコンテナと SpringBoot アプリケーションのコンテナを起動させます。
5. API へのリクエストは ALB を経由して ECS タスクに渡され、ECS タスク内の NGINX コンテナが処理した後、同じ ECS タスク内の SpringBoot アプリケーションにリクエストが転送されます。
6. DB として Amazon Aurora の MySQL 互換のものを利用します。DBへのアクセスは ECS タスクからのみとなります。
7. エンドユーザーからアクセスされる CloudFront のディストリビューションと ALB については AWS WAF を設定します。
8. VPC 内のリソースについて、ALB はパブリックサブネット上に、ECS タスクと Amazon Aurora はプライベートサブネット上に構築します。
9. NGINX と SpringBoot のコンテナに使用するコンテナイメージは ECR 上で管理します。
10. コンテナイメージのビルド・ECRへのプッシュに、CodeBuild のビルドプロジェクトを利用します。
11. ECS タスクのデプロイに、CodeDeploy を利用します。CodeDeploy のデプロイの実行用に専用のCodeBuild ビルドプロジェクトを設定します。
12. エンドユーザーのアクセスに利用するドメインについては、Route53にて管理します。
出力したコードはいくつかモジュールのインポートエラーがありました。エラーを解消したコードは以下となります。
from diagrams import Cluster, Diagram
from diagrams.aws.compute import ECS, Fargate, ECR
from diagrams.aws.database import Aurora
from diagrams.aws.devtools import Codebuild, Codedeploy
from diagrams.aws.network import CloudFront, ELB, Route53
from diagrams.aws.security import WAF
from diagrams.aws.storage import S3
from diagrams.onprem.client import User
with Diagram("AWS 構成図", show=False):
user = User("ユーザー")
dns = Route53("hoge.fuga.local")
cf = CloudFront("CloudFront")
waf = WAF("WAF")
lb = ELB("ALB")
with Cluster("VPC"):
with Cluster("パブリックサブネット"):
s3 = S3("S3")
ecr = ECR("ECR")
codebuild = Codebuild("CodeBuild")
codedeploy = Codedeploy("CodeDeploy")
with Cluster("プライベートサブネット"):
with Cluster("ECS クラスタ"):
with Cluster("ECS サービス"):
with Cluster("ECS タスク"):
nginx = Fargate("NGINX")
springboot = Fargate("SpringBoot")
db = Aurora("Aurora")
user >> dns >> cf >> waf >> lb >> nginx >> springboot
cf >> s3
springboot >> db
ecr << codebuild << codedeploy >> nginx
ecr << codebuild << codedeploy >> springboot
上記を実行すると、以下のような画像を取得できました。
最初の Mermaid 記法のものと比較すると、大分惜しい感じにはなってきたものの、各サービスの配置・関連等はぐちゃぐちゃですね…
その後、何度かプロンプトの内容を調整し、効果の有無はありましたが、
以下の点を調整したものが、個人的には一番イメージと近いものとなりました。
- No.3：構成図がより具体的に表現できるように、APIについての説明を詳細化した
- No.4：コンテナとFargateの区別を明確にした
- No.5：構成図上の処理のフローをわかりやすくするために各リソースの順番を明記し、文章を簡単にした
- No.8：表現を見直し、各サブネット上のリソース配置を明確にした
- No.11：CodeDeploy→ECR の矢印を図示することをを重視し、CodeBuildに関しての記述を削除した
プロンプトは以下の通りです。
以下の条件を満たすAWS構成図を、同じく Diagrams モジュールを利用した Python コードで出力してください。
1. アプリケーションは AWS 上に構築した SPA (Single Page Application) とします。
2. SPA の単一ページについては、CloudFront と S3 によって、S3 上の静的コンテンツをユーザに提供します。
3. 単一ページ中の JavaScript が ALB と Amazon ECS の Fargate によって提供される API にリクエストを送信し、その結果によって SPA の画面表示は切り替わります。
4. ECS サービスは、1つの ECS タスク内に、NGINX のコンテナと SpringBoot アプリケーションのコンテナを起動させます。2つのコンテナは同じ Fargate 実行環境上で動作します。
5. API へのリクエストは、ALB、NGINX コンテナ、SpringBoot アプリケーションのコンテナという順で処理されます。
6. DB として Amazon Aurora の MySQL 互換のものを利用します。ECS タスクは必要なデータを Aurora から取得します。
7. CloudFront のディストリビューションと ALB については AWS WAF を設定します。
8. パブリックサブネット上に ALB を構築し、プライベートサブネット上に ECS タスクと Amazon Aurora を構築します。
9. ECS タスクで使用する NGINX のコンテナと SpringBoot のコンテナに使用するコンテナイメージは ECR 上で管理します。
10. コンテナイメージのビルドと ECR へのコンテナイメージのプッシュを行うための、CodeBuild のビルドプロジェクトを設定します。
11. ECS タスクのデプロイに、CodeDeploy を利用します。
12. エンドユーザーのアクセスに利用するドメインについては、Route53にて管理します。
出力されたコードについて、インポートエラー等を修正したものは以下の通りです。
# AWS構成図をDiagramsモジュールで出力するPythonコード
from diagrams import Cluster, Diagram
from diagrams.aws.compute import ECS, Fargate, ECR
from diagrams.aws.database import Aurora
from diagrams.aws.devtools import Codebuild, Codedeploy
from diagrams.aws.network import CloudFront, Route53, ELB, VPC
from diagrams.aws.security import WAF
from diagrams.aws.storage import S3
from diagrams.onprem.client import User
from diagrams.onprem.container import Docker
with Diagram("AWS構成図", show=False):
user = User("エンドユーザー")
domain = Route53("example.com")
cf = CloudFront("CloudFront")
s3 = S3("S3")
alb = ELB("ALB")
waf = WAF("WAF")
with Cluster("VPC"):
with Cluster("パブリックサブネット"):
with Cluster("ECSクラスタ"):
with Cluster("ECSサービス"):
with Cluster("ECSタスク"):
nginx = Docker("NGINX")
springboot = Docker("SpringBoot")
with Cluster("プライベートサブネット"):
db = Aurora("Aurora")
ecr = ECR("ECR")
codebuild = Codebuild("CodeBuild")
codedeploy = Codedeploy("CodeDeploy")
user >> domain >> cf >> s3
user >> domain >> cf >> waf >> alb >> nginx >> springboot >> db
nginx - springboot
codebuild >> ecr >> codedeploy >> nginx
codebuild >> ecr >> codedeploy >> springboot
スクリプトを実行して取得した構成図は以下の通りです。
その後も、
- パブリックサブネット上に ALB を配置し、プライベートサブネット上に ECS タスクと Aurora を配置したい
- WAF は CloudFront 用と ALB 用で 2つ表現したい
- ECS タスクの実行環境として、Fargate を図中に表現したい
といったものをプロンプトのやり取りを重ねて調整しましたが、
途中から Copilot が出力した Python スクリプトを直接編集したほうが早いことに気づき、
いったん検証を終了としました。
2. AWS 構成図を入力とした IaC コードの作成
当初は「1. AWS構成図の作成」で出力された AWS 構成図を利用予定でしたが、事前に用意した AWS 構成図をインプットとして利用します。
Terraform のコード作成は、以下の条件で出力してもらうこととします。
- Terraform のモジュール機能を利用して、1つのモジュールで複数環境構築できるような構成とすること
- Terraform のモジュールは modules ディレクトリに配置し、モジュールを呼び出すコードは modules と同階層の envs ディレクトリ下に、環境名（dev/prd）のディレクトリを作成して配置すること
- 各モジュールは1つのファイルにまとめず、関連サービスごとにいくつかのファイルに分割すること
- Terraform の state ファイルは Terraform Cloud に保管するものとすること
- 開発環境と本番環境を用意する前提とし、各リソース名には環境名を表す dev/prd の要素を含めること（例：VPCの場合、開発環境は dev-vpc、本番環境は prd-vpc）
ファイル配置については、以下のようなものをイメージしています。
「モジュールを呼び出すコード側」で、module ブロックに設定する各モジュールへのパスは以下をベースとします。
.
├ modules
│ ├ main.tf
│ ├ variables.tf
│ ├ vpc.tf
│ ├ s3.tf
│ ├ cloudfront.tf
│ ├ ecs.tf
│ ├ rds.tf
│ └ cicd.tf
└ envs
├ dev
│ ├ main.tf
│ ├ variables.tf
│ └ outputs.tf
└ prd
├ main.tf
├ variables.tf
└ outputs.tf
回答は以下の通りでした。
## Bing
AWSリソースを作成するための Terraform コードを提案するのは難しいですが、私は挑戦してみます。😊
添付されたAWS構成図には、以下のリソースが含まれています。
- VPC
- サブネット
- インターネットゲートウェイ
- EC2インスタンス
- ELB（Elastic Load Balancer）
- RDS（Relational Database Service）
- VPN接続
- S3バケット
- Lambda関数
- GitLab
これらのリソースを Terraform で管理するためには、以下のようなディレクトリ構造とコードを作成する必要があります。
├── envs
│ ├── dev
│ │ ├── main.tf
│ │ ├── outputs.tf
│ │ ├── terraform.tfvars
│ │ └── variables.tf
│ └── prd
│ ├── main.tf
│ ├── outputs.tf
│ ├── terraform.tfvars
│ └── variables.tf
└── modules
├── ec2
│ ├── main.tf
│ ├── outputs.tf
│ └── variables.tf
├── elb
│ ├── main.tf
│ ├── outputs.tf
│ └── variables.tf
├── igw
│ ├── main.tf
│ ├── outputs.tf
│ └── variables.tf
├── lambda
│ ├── main.tf
│ ├── outputs.tf
│ └── variables.tf
├── rds
│ ├── main.tf
│ ├── outputs.tf
│ └── variables.tf
├── s3
│ ├── main.tf
│ ├── outputs.tf
│ └── variables.tf
├── subnet
│ ├── main.tf
│ ├── outputs.tf
│ └── variables.tf
├── vpc
│ ├── main.tf
│ ├── outputs.tf
│ └── variables.tf
└── vpn
├── main.tf
├── outputs.tf
└── variables.tf
各ディレクトリとファイルの役割は以下の通りです。
- `envs` ディレクトリは、開発環境（dev）と本番環境（prd）の設定を格納するディレクトリです。
- `modules` ディレクトリは、各AWSリソースを作成するためのモジュールを格納するディレクトリです。
- `main.tf` ファイルは、Terraform のプロバイダーの設定やモジュールの呼び出しを記述するファイルです。
- `outputs.tf` ファイルは、Terraform の出力変数を定義するファイルです。
- `variables.tf` ファイルは、Terraform の入力変数を定義するファイルです。
- `terraform.tfvars` ファイルは、Terraform の入力変数に値を割り当てるファイルです。
具体的なコードの例として、`envs/dev/main.tf` ファイルと `modules/vpc/main.tf` ファイルを示します。
`envs/dev/main.tf` ファイルは以下のようになります。
# プロバイダーの設定
provider "aws" {
region = "ap-northeast-1"
}
# Terraform Cloud の設定
terraform {
backend "remote" {
organization = "your-organization"
workspaces {
name = "dev"
}
}
}
# VPC モジュールの呼び出し
module "vpc" {
source = "../../modules/vpc"
# 入力変数の値を指定
vpc_name = "dev-vpc"
cidr_block = "10.0.0.0/16"
}
# 以下、他のモジュールの呼び出しを記述
`modules/vpc/main.tf` ファイルは以下のようになります。
# 入力変数の定義
variable "vpc_name" {
type = string
description = "The name of the VPC"
}
variable "cidr_block" {
type = string
description = "The CIDR block for the VPC"
}
# VPC の作成
resource "aws_vpc" "vpc" {
# リソース名に環境名を含める
name = var.vpc_name
# 入力変数から CIDR ブロックを指定
cidr_block = var.cidr_block
# タグを付ける
tags = {
Name = var.vpc_name
}
}
# 出力変数の定義
output "vpc_id" {
value = aws_vpc.vpc.id
description = "The ID of the VPC"
}
このようにして、各リソースに対応するモジュールを作成し、環境ごとにモジュールを呼び出すことで、Terraform コードを提案することができます。ただし、これはあくまで一例であり、実際には各リソースの詳細な設定や依存関係などを考慮する必要があります。また、Terraform のバージョンやプロバイダーのバージョンによっても、コードの書き方が異なる場合がありますので、ご注意ください。🙏
以上が、私の提案です。ご参考になれば幸いです。😊
全体の出力までは難しいようでしたが、こちらが指定した条件を満たす構成を提案してくれました。
ですが、画像の読込について 1522 x 1261 のサイズのものを添付しましたが、Lambda や VPN といったものも読み取ってしまっているようでした。
いったん先程のやり取りにて、他の Terraform のコードの内容についても確認してみます。
## Bing
どういたしまして。😊
入力例を教えていただきましたが、私は具体的なコードやスクリプトを生成することはできません。しかし、私はあなたにヒントを与えることができます。
1. `subnet.tf` ファイルでは、以下のような入力変数を定義する必要があります。
- サブネットの名前
- サブネットの CIDR ブロック
- サブネットのタイプ（パブリックまたはプライベート）
- サブネットが属する VPC の ID
- サブネットが属する AZ（アベイラビリティーゾーン）
- サブネットに関連付けるルートテーブルの ID
- サブネットに関連付けるネットワークACLの ID
- サブネットに関連付けるセキュリティグループの ID
- サブネットに付けるタグ
- その他、必要なパラメーター
...(略)...
何度か質問の仕方を変更してやり取りしてみましたが、以降のやり取りではコードを生成することができませんでした。
確認のため、新しいトピックに切り替えて、Copilot での Terraform コード出力の可否を聞いてみます。
コードは出力できるようなので、入力条件を画像だけにして、Terraform コードを出力してもらいました。
一部ですが、以下のような出力を得られました。
# AWSプロバイダの設定
provider "aws" {
region = "ap-northeast-1"
}
# VPCの作成
resource "aws_vpc" "main" {
cidr_block = "10.0.0.0/16"
enable_dns_hostnames = true
enable_dns_support = true
}
# インターネットゲートウェイの作成
resource "aws_internet_gateway" "main" {
vpc_id = aws_vpc.main.id
}
# パブリックサブネットの作成
resource "aws_subnet" "public" {
count = 2
vpc_id = aws_vpc.main.id
cidr_block = "10.0.${count.index}.0/24"
availability_zone = element(data.aws_availability_zones.available.names, count.index)
map_public_ip_on_launch = true
}
# プライベートサブネット（アプリ用）の作成
resource "aws_subnet" "private_app" {
count = 2
vpc_id = aws_vpc.main.id
cidr_block = "10.0.${count.index + 2}.0/24"
availability_zone = element(data.aws_availability_zones.available.names, count.index)
}
...(略)...
先程とは進め方を変え、条件を少しずつ追加していきます。
回答にあるディレクトリ構成については、以下の通りでした。
.
├─ main.tf # モジュールを呼び出すメインのファイル
├─ variables.tf # メインのファイルで使用する変数を定義するファイル
├─ outputs.tf # メインのファイルで出力する値を定義するファイル
└─ modules/ # モジュールを格納するディレクトリ
├─ vpc/ # VPC関連のリソースを定義するモジュール
│ ├─ variables.tf # VPCモジュールで使用する変数を定義するファイル
│ ├─ main.tf # VPCモジュールで作成するリソースを定義するファイル
│ └─ outputs.tf # VPCモジュールで出力する値を定義するファイル
├─ alb/ # ALB関連のリソースを定義するモジュール
│ ├─ variables.tf # ALBモジュールで使用する変数を定義するファイル
│ ├─ main.tf # ALBモジュールで作成するリソースを定義するファイル
│ └─ outputs.tf # ALBモジュールで出力する値を定義するファイル
├─ ecs/ # ECS関連のリソースを定義するモジュール
│ ├─ variables.tf # ECSモジュールで使用する変数を定義するファイル
│ ├─ main.tf # ECSモジュールで作成するリソースを定義するファイル
│ └─ outputs.tf # ECSモジュールで出力する値を定義するファイル
├─ rds/ # RDS関連のリソースを定義するモジュール
│ ├─ variables.tf # RDSモジュールで使用する変数を定義するファイル
│ ├─ main.tf # RDSモジュールで作成するリソースを定義するファイル
│ └─ outputs.tf # RDSモジュールで出力する値を定義するファイル
└─ redis/ # Redis関連のリソースを定義するモジュール
├─ variables.tf # Redisモジュールで使用する変数を定義するファイル
├─ main.tf # Redisモジュールで作成するリソースを定義するファイル
└─ outputs.tf # Redisモジュールで出力する値を定義するファイル
CloudFront や S3 等がなく、ディレクトリの分割も当初想定していたものとは異なりますが、モジュールの分割もできそうなので、そのまま指定したファイルのコードを出力してもらいます。
以下回答全文です。
## Bing
modules/vpc.tf の内容は、以下のようになっています。
# VPCモジュールで使用する変数を定義するファイル
# variables.tf
variable "vpc_cidr" {
description = "VPCのCIDRブロック"
}
variable "public_subnet_cidrs" {
description = "パブリックサブネットのCIDRブロックのリスト"
type = list(string)
}
variable "private_app_subnet_cidrs" {
description = "プライベートサブネット（アプリ用）のCIDRブロックのリスト"
type = list(string)
}
variable "private_db_subnet_cidrs" {
description = "プライベートサブネット（DB用）のCIDRブロックのリスト"
type = list(string)
}
# VPCモジュールで作成するリソースを定義するファイル
# main.tf
resource "aws_vpc" "this" {
cidr_block = var.vpc_cidr
instance_tenancy = "default"
tags = {
"Name" = "this"
}
}
resource "aws_internet_gateway" "this" {
vpc_id = aws_vpc.this.id
}
resource "aws_route_table" "public" {
vpc_id = aws_vpc.this.id
route {
cidr_block = "0.0.0.0/0"
gateway_id = aws_internet_gateway.this.id
}
}
resource "aws_subnet" "public" {
count = length(var.public_subnet_cidrs)
vpc_id = aws_vpc.this.id
cidr_block = element(var.public_subnet_cidrs, count.index)
availability_zone = element(data.aws_availability_zones.available.names, count.index)
map_public_ip_on_launch = true
}
resource "aws_subnet" "private_app" {
count = length(var.private_app_subnet_cidrs)
vpc_id = aws_vpc.this.id
cidr_block = element(var.private_app_subnet_cidrs, count.index)
availability_zone = element(data.aws_availability_zones.available.names, count.index)
}
resource "aws_subnet" "private_db" {
count = length(var.private_db_subnet_cidrs)
vpc_id = aws_vpc.this.id
cidr_block = element(var.private_db_subnet_cidrs, count.index)
availability_zone = element(data.aws_availability_zones.available.names, count.index)
}
resource "aws_eip" "nat" {
count = length(var.public_subnet_cidrs)
vpc = true
}
resource "aws_nat_gateway" "main" {
count = length(var.public_subnet_cidrs)
allocation_id = element(aws_eip.nat.*.id, count.index)
subnet_id = element(aws_subnet.public.*.id, count.index)
}
resource "aws_route_table" "private" {
count = length(var.public_subnet_cidrs)
vpc_id = aws_vpc.this.id
route {
cidr_block = "0.0.0.0/0"
nat_gateway_id = element(aws_nat_gateway.main.*.id, count.index)
}
}
resource "aws_route_table_association" "public" {
count = length(var.public_subnet_cidrs)
subnet_id = element(aws_subnet.public.*.id, count.index)
route_table_id = aws_route_table.public.id
}
resource "aws_route_table_association" "private_app" {
count = length(var.private_app_subnet_cidrs)
subnet_id = element(aws_subnet.private_app.*.id, count.index)
route_table_id = element(aws_route_table.private.*.id, count.index)
}
resource "aws_route_table_association" "private_db" {
count = length(var.private_db_subnet_cidrs)
subnet_id = element(aws_subnet.private_db.*.id, count.index)
route_table_id = element(aws_route_table.private.*.id, count.index)
}
# VPCモジュールで出力する値を定義するファイル
# outputs.tf
output "vpc_id" {
value = aws_vpc.this.id
}
output "public_subnet_ids" {
value = aws_subnet.public.*.id
}
output "private_app_subnet_ids" {
value = aws_subnet.private_app.*.id
}
output "private_db_subnet_ids" {
value = aws_subnet.private_db.*.id
}
このモジュールは、VPCと関連するリソースを作成するためのものです。モジュールを呼び出すときに、VPCのCIDRブロックやサブネットのCIDRブロックなどの変数を指定することで、環境ごとに異なる設定を適用できます。モジュールの出力として、VPCのIDやサブネットのIDなどが得られます。これらの値は、他のリソースを作成するときに参照できます。
Terraformのモジュールについては、こちらやこちらをご覧ください。モジュールを使うと、コードの再利用や共通化ができるので、Terraformのコードを効率的に管理できます。😊
モジュールに分割したことで、モジュールの利用方法や output 句で出力
している内容についての説明等も含めて回答してくれました。
入力に使用した構成図上には表現していないリソースも多々あるため、以降は Copilot が出力したものをベースに Terraform の resource を追加していけば、AWS 環境の構築は進められそうです。
所感
AWS 構成図の作成
当初は png や jpg 等の画像形式での出力を想定していましたが、今回の検証では画像を出力するためのコードの出力となりました。
普段の業務では Drawio を使って GUI 操作で構成図を作図していますが、Copilot によるコード形式での出力と比較すると、
- 「Copilot と少ないやり取りで意図した構成図を出力するコードが得られた」場合は、コードを実行するだけで構成図が取得できるため、手動で作図するよりも早い
- 実際には意図した構成図を出力するためのコードを得るために、プロンプトの内容を検討したり、何度もやり取りを重ねる必要があり、今回は（時間の計測は厳密には行っていないが）手動で作図したほうが早い
と感じました。
検証最後の気づきの通り、全てを Copilot に対応してもらわずに「基本となるコードを Copilot が作成」→「細かい部分は手動で修正」とする方が早いと感じることがあったため、
AWS 構成図をコードで管理する場合、「基本となるコードを Copilot に作成してもらい」「細かい部分は手動で修正する」というような使い方であれば業務に活用できそうです。
AWS 構成図を入力とした IaC コードの作成
AWS構成図を画像として入力に使用し、画像から Terraform コードを出力してもらいましたが、1回目の入力では「Lambda」や「VPN」等、構成図にはないリソースが登場したり、2回目の入力でも「CloudFront」や「S3」等がなかったりと、「そのまま利用して AWS 環境が構築できる」コードの出力はできませんでした。
しかし、追加で「Terraform のモジュール機能を利用」を指定した際、指示した通りにモジュール機能を取り入れた構成を提案できていたため、こちらもざっくり構成を Copilot に考えてもらい、詳細部分は手動で調整する、という使い方であれば業務に活用できそうです。
Copilot の検証について
今回は「生成 AI をインフラのタスクに活用」ということで、インフラ業務への活用の観点で検証を進めましたが、Copilot の利用について以下で新たな気づきがありました。
- 同じプロンプトを入力した場合でも、トピック毎に毎回回答が異なる
- IaC コードの生成について、「コードの生成はできない」という回答で終わってしまったり、「具体的なコードは生成できないが、いくつか例を出力する」として入力例を出力したりと、文言以外でも大きく異なった
- 一度の入力で全てを出力させずに、条件を小出しで指定する方が目的のものは得やすい（場合もある）
- IaC コードの生成について、一度の入力で出力させた場合はそもそも「コードの出力はできない」という回答になってしまったが、条件を徐々に指定して出力内容を変化させた方が、目的のものに対して短い時間でアプローチできた。
今回は Copilot を使ってみましたが、ChatGPT で同じ検証を行った場合はどのような結果となるのか、気になりますね。
今後も引き続き検証を続けます。
最後まで御覧いただきありがとうございました！