記事をご覧いただきありがとうございます。26新卒社員の鈴木です。
先日、技術研修の集大成として、4日間の「クラウド総合演習」が行われました。

今回の記事では、その活動内容の中で、「何をして、どこで苦労し、何を学んだのか」に焦点を当ててお伝えしたいと思います。

はじめに　「クラウド総合演習」概要

今回の演習内容を一言でいうと「AWS Fargateで画像生成アプリケーションを構築する」というものです。具体的には、ユーザーがテキストを入力すると、AIが自動で画像を生成してくれるアプリケーションを作成しました。
1からすべてを構築するわけではなく、講師から提示された演習ガイドと構成図に基づいて、WebアプリケーションをAWSクラウドインフラ上に構成しました。
4日間のチーム演習で、成果物の完成を目指しました。

以下の構成図を基にWBSを作成し、開発やインフラ構築を行いました。

【補足】
WBS（作業分解構成図）：プロジェクトの目標達成に必要な作業を細かく分解し、階層構造に整理した図や表
AWS Fargate：サーバーの準備や管理をすることなく、コンテナを実行できるサーバーレスなコンピューティングエンジン

4日間のロードマップ

  • 1日目：タスク・担当者・スケジュールを検討し、WBSを作成
  • 2日目：インフラ基盤の構築、フロント画面作成
  • 3日目：誤操作によりインフラ環境の再作成が必要となるトラブルが発生
  • 4日目：復旧作業およびトラブルシューティング

今回の4日間の開発は、スケジュール管理の大切さやトラブルへの向き合い方など、本当にたくさんの学びがある時間になりました！

3日目に思いがけないエラーが発生し、2日目の設定を1からやり直すことになってしまったため、残念ながら時間内にアプリを完成させ切ることはできませんでした。

ですが、このトラブルを実際に経験したことで、開発・構築における「予期せぬ事態を見越したスケジュール（バッファ）の組み方」がいかに大切かを身をもって実感できました。
ただ形にするだけでなく、アクシデントにも柔軟に対応できる計画性が大事だと実感しました。

この悔しさと学びを次に活かして、実務で何事に取り組む際にも活発に挑戦していきたいです！

エラーの発生原因と解決策

演習中には数多くのエラーに直面しましたが、その中でも最も解決に時間を要したエラーをご紹介します。
※3日目のエラーとは別のエラーです。

以下の画像はAmazon ECS（Elastic Container Service）作成時のエラー画面です。

エラーの原因
１. NAT ゲートウェイの定義がされていなかった
２. ヘルスチェックの猶予期間を0秒に設定していた （Djangoの起動が完了する前にヘルスチェックが走り、異常と判定されてコンテナの再起動を繰り返していた）

解決方法
・NAT ゲートウェイの作成
・ヘルスチェック猶予期間の延長

なぜ解決に時間がかかったのか
2日目にNAT ゲートウェイは作成していたため、トラブル後の再設定時に「NAT ゲートウェイは作成済み」と思い込み、存在しないことを見落としていました。また、エラーメッセージの読み解きに時間を要し、原因に気づくまでに時間がかかりました。

【補足】
Amazon ECS：アプリを入れた箱（コンテナ）を、止まらないように監視しながら自動で実行・停止・管理する仕組み
NAT ゲートウェイ：プライベートサブネットにあるサーバーやデータベースがインターネットにアクセスできるようにするための仕組みで、セキュリティを保ちながら外部との通信が可能になります。

成果物

デプロイまでを完了させることはできませんでしたが、ローカル環境での画面表示と動作確認までは進めることができたのでご紹介します。

まとめ

今回の演習を通じて2点の気づきを得ることができました。
1. 「慎重さ」と「多角的な視点」の重要性
インフラの構築は複数のサービスを連携するため、一か所の設定ミスがエラーに繋がります。そのため、設定は慎重に行い、エラーが発生した際は原因を多角的に探る必要があると感じました。

2.  WBSの重要性
手戻りやエラーの発生を最小限に抑えるには初めのWBS作成段階での詳細設計やタスク分解が重要であること、そしてバッファを持たせて不測の事態にも対応できるようにしておくことが重要であると実感しました。

トラブルやエラーの発生で完成には至りませんでしたが、メンバーとエラーの解決策を模索したことや、スキルの高いメンバーからの解説で理解を深められた時間は、貴重な経験となりました。
今回の学びを糧に、これからも実践を通じて成長していきたいと思います！