ECS Express Mode でサイドカーコンテナとして Fluent Bit を追加してみる
ECS Express Mode で設定可能な項目と設定不可能な項目について
ECS で簡単にコンテナアプリケーションをデプロイ可能な機能として Express Mode が登場しました。
本機能を利用すればタスク定義や ECS サービスなどの細かい設定は考慮不要となり、最低限コンテナイメージの URI さえあれば誰でもアプリケーションをデプロイできます。
また、あくまで通常の ALB と ECS を簡単に構築するという建付けなので、細かく設定したくなった場合は素の ALB や ECS としての運用に切り替えることも可能です。
2026 年 1 月時点で ECS Express Mode から設定可能な項目は下記になります。
- コンテナイメージ URI
- CPU
- メモリ
- ECS クラスター
- ECS サービス名
- タスクロール
- タスク実行ロール
- コンテナポート
- ヘルスチェックパス
- 環境変数
- コマンド
- オートスケーリングするメトリクス、しきい値
- タスクの最小数、最大数
- 配置サブネット
- ECS サービスに付与するセキュリティグループ
- アプリケーションログのロググループ名
- アプリケーションログのログストリーム名
- タグ
それ以外の項目を設定したい場合、Express Mode で作成された基盤となるリソースの設定を直接変更する必要があります。
現時点で ECS Express Mode 外で設定を変更したくなるようなケースとしては下記が考えられます。
- カスタムドメイン対応
- サイドカー追加 (特に Fluent Bit)
- アプリケーションログの保持期間設定変更
- デプロイフローの簡略化
あまりにも Express Mode 外でカスタマイズしたい部分が多い場合は最初から通常の ECS として作成するのが良いと思います。
一方で、カスタムドメイン対応とサイドカー追加は公式ドキュメントでも紹介されている内容です。
この 2 つとアプリケーションログの保持期間設定変更くらいが ECS Express Mode 管理のサービスとして運用しながらカスタマイズする代表的なケースだと思います。
また、現状 ECS Express Mode はカナリアデプロイかつベイクタイム (トラフィック切り替え後に既存タスクを残す時間) が 3 分となり、一度のデプロイにかかる時間が長めです。
デプロイにかかる時間を短縮したい場合は ECS サービスの設定から変更すると良いでしょう。
逆に下記のような設定をカスタマイズしたい場合、通常の ECS を作成してしまった方が良いと思います。
- CPU アーキテクチャとして ARM を指定したい (最初に指定できず、必ず最初のデプロイが失敗する)
- パブリックサブネットに ALB、プライベートサブネットに ECS を配置したい (最初に指定できず、後から設定変更するのも面倒)
- ローリングアップデートを採用したい (そもそも利用不可)
Express Mode 外で設定変更した際の挙動について
ECS Express Mode を利用した場合も基盤となるリソースの設定値を直接変更することが可能です。
例外として ECS のデプロイ戦略がありますが、基本的には全ての項目を直接設定できます。
標準 AWS サービス API を使用すると、個々のリソースを直接制御できます。これにより、Express Mode が設定用に提供するパラメータのセットを超えて、すべてのリソースのすべてのパラメータを制御できます。
https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/express-service-advanced-customization.html#express-service-shared-responsibility
また、ECS Express Mode のコンソール等から明示的にバッティングする更新をリクエストしない限り、直接変更した内容が上書きされることはありません。
Express Mode の更新の一部としてリクエストされない限り、Express Mode は変更を上書きしません。ユーザーには、直接 API を使用した変更が Express Mode の設定にどのように影響するかを理解し、結果として生じる競合やサービスの問題を解決する責任があります。
https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/express-service-advanced-customization.html#express-service-shared-responsibility
Express Mode 側からの構成変更が Express Mode 管理外の変更を巻き戻さないように考慮するのはそれなりに面倒です。
そのため、直接設定変更する内容が多くなる場合は通常の ECS として運用すべきです。
Fluent Bit を追加してログルーティングを行っている場合、ロググループの設定を ECS Express Mode 側で更新した場合に、設定を巻き戻してしまいます。
この場合だと、例えば、Express Mode に新しいロググループとログストリーム名を指定した場合、logDriver は awslogs に更新されます。
https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/express-service-advanced-customization.html#express-service-customization-examples
やってみる
今回はマネジメントコンソールから Fluent Bit 経由でログを S3 に出力するよう設定します。
ECS 環境ですので、FireLens の形で設定します。
ECS サービス作成
ECS Express Mode で ECS サービスを作成します。
イメージ URI としては public.ecr.aws/nginx/nginx:latest を指定しました。
タスク実行ロールの作成方法などは [アップデート] ECS Express Mode を利用できるようになりました に記載しているので省略します。
S3 作成
事前に Fluent Bit 経由でログを出力する先の S3 を作成します。
S3 のサービスページに移動して「バケットを作成」をクリックします。
バケット名だけ指定して、他はデフォルト設定とします。
タスクロールの作成
続いて S3 にログを配置するためのタスクロールを作成します。
IAM のサービスページに移動して「ロールを作成」をクリックします。
ユースケースとして Elastic Container Service の Elastic Container Service Task を選択します。
AWS マネージドポリシーの AmazonS3FullAccess を付与します。
今回は広めに AmazonS3FullAccess を付与してしまいましたが、Fluent Bit 公式ドキュメント 記載の下記ポリシー等を作成して付与するとよりセキュアになります。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": ["s3:PutObject"],
"Resource": "*"
}
]
}
ロール名を指定して「ロールを作成」をクリックします。
タスクロールの設定
続いてタスクロールを設定します。
ECS サービスの設定を直接変更することも可能ですが、直接のカスタマイズは可能な限り避けたいので ECS Express Mode 側から指定します。
作成した ECS サービスを選択して「更新」をクリックします。
「その他の設定 - オプション」からタスクロールを指定して「更新」をクリックします。
ECS サービスの更新が完了するまで待ちます。
特に短縮する設定を行っていなければ 10 分程度かかります(長い)。
Fluent Bit 追加
Fluent Bit を追加して作成した S3 にログを出力するようにします。
こちらは ECS タスク定義設定から直接 Fluent Bit を追加します。
リソースタブから利用されているタスク定義の詳細ページに遷移します。
「新しいリビジョンの作成」をクリックします。
「コンテナ - 1」の 「ログ収集」 において送信先を 「AWS FireLens 経由で S3 にログをエクスポートする」に変更します。
先程作成した S3 バケットのバケット名を指定します。
設定変更した段階で「ログルーティングコンテナ (FireLens)」 が追加され、メモリのソフト制限が 0.05GB に設定されます。
ECS Express Mode のデフォルト設定で作成すると、タスクサイズはメモリ 2GB でプライマリコンテナの「メモリのソフト制限」も 2GB になります。
この状態でさらに Fluent Bit 分を確保しようとした場合、合計メモリ予約数がタスクサイズで指定したメモリサイズを超えてしまいます。
そのため、Main コンテナ (ECS Express Mode でイメージ URI を渡して作成した方のコンテナ) の「メモリのソフト制限」から 0.05 GB 分引いてあげる必要あります。
「作成」をクリックすると新しくタスク定義が作成され、メモリの予約数も上手くタスクサイズに収まります。
「デプロイ > サービスを更新」をクリックします。
クラスターと ECS サービスを選択し、「新しいデプロイの強制」にチェックをつけます。
「更新」をクリックします。
ここまで対応完了すると無事ログが S3 に格納され始めました。
タスクサイズを更新すると？
ECS Express Mode は明示的にバッティングする際に Express Mode 外の変更を上書きしてしまいます。
とはいえ、誤って Express Mode 側からロググループ名/ログストリーム名の設定さえ変えなければ、今回行ったサイドカー周りの設定を ECS Express Mode が巻き戻すことは無さそうです。
ただ、止むを得ず「メモリのソフト制限」を変更してしまいました。
この状態でタスクサイズを変更するとどうなるのでしょうか？
Express Mode 側からタスクサイズ 2vCPU、メモリ 4GB に変更してみます。
「更新」をクリックすると「InvalidParameterException
The sum of all container 'memoryReservation' values cannot be greater than the value of the task 'memory'.」というエラーで怒られました。
どうやらタスクサイズを変更すると同等の値でプライマリコンテナのメモリ予約数も上書きするようです。
サイドカー分を考慮してくれないため、Express Mode 側からタスクサイズの変更ができなくなってしまいました。
スケールアウトに頼るとか、タスク定義を変更する場合は直接タスク定義を修正するとか、代替手段はあるものの、この辺りも良い感じにやってくれたらより嬉しかったですね。
最後に
Express Mode は便利ですが、実体となる ECS サービス側の設定を変更するべきか、Express Mode 側から設定を入れるべきかの判断を求められるユースケースでは大分考慮事項が増える感じがしますね。
サイドカーを追加する可能性が高いワークロードでは最初から通常の ECS として作成した方が結果的にシンプルに運用できるかもしれません。
とはいえ、このようなサイドカー追加もサポートはされているので、ECS Express Mode で運用している中でサイドカーを追加したくなった方は試してみて下さい。
また、カスタムドメイン設定についても下記記事で紹介されているので、こちらも是非参考にしていただければと思います。
