コラム

はじめに

こんにちは。BTCクラウドCoEの松波です。今回はECSの起動タイプについて、前回より少し深堀りしてみます。

ECS起動タイプ

前回の記事でも記載しましたが、ECSの起動タイプには大きく分けて以下の2つがあります。 ・EC2 ・Fargate 実際には、下図のとおりEC2起動タイプがさらにLinuxとWindowsで分かれています。Fargateについては特に記載がありませんが、Linuxのみです。

ECS起動タイプの使い分け

起動タイプが複数あるということはそれらを使い分けることがユーザーには求められます。以下に各起動タイプの特長を簡単に記します。 （１）Fargate Linux上で稼働するプログラムを使う場合に利用します。 サーバーレスなので、OSやミドルウェアへのパッチ適用タスクから解放されるのが利点となる一方、仮想マシンへのSSHログインができません。 環境初期構築時やインフラ観点でのデバッグを行う場合、SSMセッションマネージャを用いてコンテナに対してログインする必要があり、 それを行うためには事前にアクティベーションコードの登録、コンテナへのSSMエージェント導入、Dockerfileの修正などを実施しておく必要があります。そのあたりが若干煩雑な印象です。 性能面での利点として、スケールアウトのチューニングをする際、EC2起動タイプの場合はコンテナ/タスク設定とEC2のAuto Scalingの設定の両方でチューニングが必要ですが Fargateは前者のみでチューニングできる点が挙げられます。これからECSを使う場合、まず検討するのはこのタイプになるのではないでしょうか。 （２）EC2起動タイプ（Linux） Fargate同様、Linux上で稼働するプログラムを使う場合に利用します。 Fargateのメリット・デメリットとは対照的になりますが、OSやミドルウェアへのパッチ適用を行う必要が生じる一方、 仮想マシンへのログインは公開鍵を用いたSSHログインが可能です。 ログインすれば、dockerコマンドを用いたコンテナ状態の確認やOSコマンドを用いたサービス再起動が可能であり、トラブルシューティングの観点で対応しやすいのがメリットです。 （３）EC2起動タイプ（Windows） Windows固有のミドルウェア（IIS）や.NET Frameworkアプリケーションをコンテナで実行したい場合に利用します。 既存のWindows資源を極力修正せずにコンテナで実行するといった要件の際に採用されることが多いと考えられます。 EC2起動タイプとしてのメリット・デメリットは（２）と同様です。

ECSコンテナエージェント/Fargateコンテナエージェントについて

いずれの起動タイプにおいても、コンテナオーケストレーションを実現するためのミドルウェアが必要となります。 それがECSコンテナエージェントです。（なお、Fargateの場合はFargateコンテナエージェントが導入されますが、ユーザーが特に意識する必要が無いので以下の説明では割愛します。） ECSエージェントのイメージ図を以下に記載します。 Amazon ECS-optimized AMIを用いてECSを構築している場合は、特に設定せずともECSコンテナエージェントがインスタンスに導入されています。 Linuxの場合はecsサービス、dockerサービスがOS上のサービスとして導入され、ECSコンテナエージェントは1コンテナとして動作しています。 それに対し、Windowsの場合はECSコンテナサービスがOS上のサービスとして動作します。 ちなみに、ECSエージェントはソースコードがgithubで公開されています。詳細な仕様を知りたい人は見てみましょう。ソースはGo言語で書かれてます。（そういえばSSMエージェントもGo言語で書かれてました。）

終わりに

今回はECSの起動タイプとECSコンテナエージェントについて簡単にまとめました。 起動タイプに限った話ではありませんが、要件に応じて適切な構成を選んでいきたいものです。