応用課題
1. 課題の概要
この章で学んだ内容をもとに、シンプルなタスク管理APIを動作させるAWSインフラを Terraformでデプロイ します。AWSコンソールからの手動操作ではなく、コードとしてインフラを定義することで、再現性のあるデプロイを実現します。
その上で、構築した内容について、手順を追えたかではなく、なぜその構成を選んだのかを自分の言葉で説明できるか を確認する課題です。メンタリングでの口頭報告 がゴールです。
2. 事前準備
2.1 サンプルアプリのダウンロード
zipには FastAPI + SQLAlchemy で実装されたシンプルなタスク管理APIが入っています。EC2上での実行を想定しており、同梱の setup.sh で systemd サービス化までのセットアップが完了します。
2.2 必要なツール
3. 必須要件
3.1 Terraform でのインフラ構築（EC2構成）
サンプルアプリを動作させるためのAWSインフラを Terraform でデプロイすること。以下を含めること。
- VPC（Public SubnetとPrivate Subnetを2つ以上のAZに分散）
- ALB（Public Subnet）
- EC2インスタンス（Amazon Linux 2023、Private Subnet、FastAPIアプリを動作させる）
- RDS（MySQL 8.x、Private Subnet、マルチAZ構成）
- セキュリティグループ（ALB・EC2・RDS間および外部からの通信を制御）
アプリケーションのセットアップ自体は、Terraform でインフラを構築した後に SSH 経由で setup.sh を実行する形で構いません。EC2 の UserData などで起動時に自動セットアップする形を取れれば、より一歩進んだ実装になります。
3.2 コードの構成
- リージョン・CIDR・インスタンスタイプなどの値は
variableで外部化 していること（ハードコーディング禁止） - リソース間の依存関係は リソース参照（
aws_vpc.main.idなど）で表現していること - ファイルは
main.tf/variables.tf/outputs.tf/terraform.tfvarsに分割していること - 主要なリソースID・エンドポイントは
outputとして外部に公開していること .gitignoreでterraform.tfstate*・.terraform/・*.tfvars（機密情報を含む場合）を除外していること
3.3 README
README に以下を記載すること。
- 変数化した値の選定理由
- ハマったポイント・工夫した箇所
4. 発展課題（任意）
4.1 ECS/Fargate に移行する
EC2ベースで構築した構成を、ECS/Fargateに移行する。
- アプリケーションをコンテナ化する（Dockerfile +
.dockerignore） - コンテナイメージを ECR にpushし、ECSタスク定義から参照する
- ECSクラスタを作成し、Fargate起動タイプでタスクを実行する
- ALBターゲットグループを EC2 から ECS（Fargate）に切り替える
- 不要となった EC2 関連のTerraformリソースを削除する
4.2 モジュール化
責務やライフサイクルが異なるリソースを モジュール に分割し、再利用しやすい構成にする。例として、ネットワーク基盤（VPC・Subnet等）と、アプリケーション層（EC2 や ECS・ALB等）を別モジュールに分離する形が考えられる。モジュールごとに variables.tf / outputs.tf を用意し、入出力のインターフェースを明示する。
4.3 リモートバックエンドの設定
- Terraformのstateを S3 + DynamoDB でリモートバックエンド管理する設計に変更する
4.4 独自ドメインでHTTPS化
- Route53で独自ドメインを設定する
- ACMでSSL証明書を発行し、ALBでHTTPS化する
5. メンタリング報告
この応用課題は、構築できたら メンタリングで自分の言葉で説明する ことがゴールです。手順通りに動かせることと、その意図や仕組みを理解していることは別物です。実務では、構築した環境について上司・チームメンバー・お客様に説明する場面が必ず発生します。「なんとなく動いた」で終わらせず、自分の言葉で語れるレベルまで引き上げるのがこの課題の狙いです。
メンタリングでは、メンターから「なぜそうしたのか」「他の選択肢は検討したか」「実務だとどうするか」といった踏み込んだ質問を行います。即答できる状態まで準備しておいてください。
5.1 事前準備の進め方
事前準備の進め方は自由です。話しやすい形式を選んでください。
- スライドやドキュメントで事前にまとめておく
- Notion やマークダウンなどでメモを整理しておく
- 事前にブログにまとめておく
- 口頭一発勝負
など、何でも構いません。
メンターから「どのような質問が来そうか」を事前に考えておくことも、準備の一環として取り組んでみてください。
5.2 報告観点
報告の単位（どこまでをひとまとまりとして説明するか）は、自分で考えて整理してください。構築した内容のうち、伝えるべきだと思う単位で区切り、それぞれについて以下の4つの観点で整理してメンタリングで報告してください。
1. 何をやったか（自分の言葉で）
- 自分が実際に行った内容を自分の言葉で説明する
- 事実だけでなく「なぜそうしたのか」まで踏み込む
- 「課題に書かれている通りに作業した」という説明では不十分
2. どんなメリットがあるか
- 採用した技術・構成・ツールが、何を解決するために存在するのかを言語化する
- 「便利だから」「教材で言われたから」ではなく、具体的な利点を自分の言葉で説明する
3. 改善点はあるか・もっと良い方法はあるか
- 自分が構築したものの限界や、もう一段ブラッシュアップする余地を挙げる
- セキュリティ・コスト・運用負荷など、視点はなんでも構わない
- すぐに直せなくても、課題感として認識できていることが重要
4. 類似の技術と比べて何が違うか
- 採用した技術と似た選択肢を1つ以上挙げ、それぞれの違いを説明する
- 自分が選ばなかった選択肢を意識できているかが問われる観点
6. 提出形式
6.1 GitHubリポジトリ
実装したコード（main.tf / variables.tf / outputs.tf / terraform.tfvars / .gitignore / README.md など）をアップロードしたGitHubリポジトリのURLを記載してください。
6.2 まとめ
実装中に苦労したこと、工夫したこと、学んだことを記載してください。