コンテナを扱う場合、アプリとインフラの担当者が兼任していれば、それほど問題にならないが、分業している場合には、それぞれの役割分担としての境界線が引きずらいと感じる。実際の案件を通して、おそらくスムーズになると思われる分担について記載する。
目次
PJにおける人物定義
前提：複数の役割を兼任する場合もあるが、以下で人物定義する。
- アプリケーション開発者
AWS上で稼動するシステムのアプリケーションを開発する人を指す。ざっくりなくくりとしては、ソースコードを扱う人。 - システムの管理者
システムを監視、運用する人を指す。一般的には、AWSを所有する顧客自身になるケースが多い。 - インフラ（AWSサービス）担当者
AWSのサービスを構築し、アプリケーションが動作するための基盤（サーバやコンテナなど）を構築するする人を指す。本記事は、この担当者目線での記事となる。
役割分担
シンプルに分担する場合は、以下が良いと考える。
- 基本的な分担の方針は、作業ごとに必要な情報があり、その情報を握っている主管がやるべきという考え方。
- 少しのヒアリングで取得できるような、情報量であれば、必ずしも情報の持ち主である必要は無いが、必要な情報量がある程度のボリュームになる場合には、持ち主が実施した方が効率が良い。
| フェーズ | 作業内容 | 担当者 |
|---|---|---|
| 設計 | クラスタ | インフラ担当者 |
| タスク定義※1. | アプリ担当者 | |
| サービス | インフラ担当者 | |
| コンテナイメージ※1. | アプリ担当者 | |
| パイプライン（デプロイ） | インフラ担当者 | |
| 構築 | クラスタ | インフラ担当者 |
| タスク定義（jsonファイル作成） | アプリ担当者 | |
| サービス | インフラ担当者 | |
| コンテナイメージ※1.（Dockerfile作成＆ビルド） | アプリ担当者 | |
| パイプライン（デプロイ） | インフラ担当者 | |
| 運用 | 運用手順作成（デプロイ手順） | インフラ担当者 |
| コンテナアップデート時のデプロイ、障害対応 | システム管理者 |
※1.必要に応じてFluentbitなどのサイドカーを含む。
タスク定義の設計/構築担当者について
タスク定義では、以下のような設定が必要となる。これらをインフラ側からアプリ側に対して、ヒアリングすることで、設計、構築を行うこともできるが、環境変数の規模は100項目以上になる場合もあり、その項目をインフラ側でヒアリングして、実機に投入するのは非効率と考える。
- 環境変数
- 他のコンテナにアクセスする際のDNS名や、RDSのエンドポイントなど環境固有の値を設定する。
- EFSのマウント先
- ログの出力先
- 必要に応じて、firelensなどを設定。
- 必要に応じて、firelensなどを設定。
また、ログの出力先にFluentbitを使用し、且つカスタマイズが必要な場合にはFluentbitのイメージビルドが必要になるが、このイメージの作成にはどのようなログ（正規表現）が出力されるのか、整形が必要か、どこに出力するかといった設計が必要。これらの情報はアプリ側が握っており、インフラ側でヒアリングして設計することは非効率と思われる。
結論として、タスク定義にかかわる設計、構築とイメージのビルドについては、全般的にアプリ側で実施する仕切りにした方がよいと考える。
サービス設計/構築担当者とパイプライン（デプロイ）担当者について
サービスの設計の一部として、デプロイ方式(ECSによるローリングアップデート or CodeDeployによるBlueGreenデプロイ)を指定する必要がある。サービス設計担当とパイプライン担当を異なる担当とすることもできるが、サービス設計者は、デプロイ方式を予め意識した設計とする必要がある。そのため、認識齟齬を無くす意図で、担当者を揃える方が無難。
