AWS Fargateにコンテナを構築してみた

#はじめに
　昨今、コンテナ技術の普及やクラウドサービスの発展により、AWSのマネージドサービスを提供する、コンテナ向けサーバーレスコンピューティングエンジンであるAWS Fargateが注目されているようです。

　今回、AWS Fargate上にコンテナを構築し、AWSのサービスを利用して運用・監視してみました。本記事では、AWS Fargateにコンテナ適用を検討している方向けに、今回利用したAWSのサービスやAWS Fargate上のコンテナの構築・運用・監視について簡単にまとめます。

　以降では、対象としたAWSの構成と、その構成を構築してコンテナを運用・監視する際に利用したAWSのサービスや気になるポイントを説明していきます。（※Dockerやコンテナ、AWSの基本的な知識を有することを前提とします。）

　AWSのサービスの具体的な利用手順は説明していないので公式サイトなどを参照してください。

#AWS Fargateとは
　AWS Fargateは、Amazon ECSとともに使用して、サーバレスでコンテナを管理します。そのため、コンテナを実行するサーバ（Amazon EC2のインスタンス）の管理・運用を意識する必要がなくなるといった利点があります。

#AWSの構成
　次のAWSの構成を構築してみました。
　　　　　　　

　上の図では、クライアント端末からAWS Fargate上のコンテナ（APサーバを構築）に、リバースプロキシサーバとロードバランサ（ELB）を経由してHTTPリクエストを送信します。コンテナのデータはDBサーバに格納します。

#コンテナ構築
　AWS Fargate上にコンテナを構築するために、次の①から⑤の流れを行いました。
　※Dockerfileの作成やコンテナイメージの作成には、別途、作業用のAmazon EC2を用意しました。

　① Dockerfileの作成
　② コンテナイメージの作成
　③ コンテナレジストリにコンテナイメージの格納
　④ AWS Fargateのクラスター、サービス、タスク定義の作成
　⑤ タスクの実行（コンテナの起動）

　コンテナ構築では、セキュア設計やコンテナ管理を容易にするために、シークレットな情報をコンテナから切り離したり、コンテナイメージからソフトウェアの設定ファイルなどを切り離すことなどがポイントになります。

##■ IPアドレス
　AWS Fargateでは、コンテナを再起動するたびに、コンテナに動的にIPアドレスが割り当てられます。そのため、直接コンテナにローカルIPアドレスやAWSのElastic IPアドレスを設定できません。
　起動したコンテナに適切にリクエストを送るために、AWS Fargateの前段にロードバランサ（ELB）を配置し、次のAWS Fargateのサービスのロードバランシングの設定画面からロードバランサ（ELB）を設定¹しました。

　これにより、コンテナ起動時に、対象のロードバランサ（ELB）のターゲットグループ（ターゲットとなるIPアドレス）が自動的に更新され、起動したコンテナに適切にリクエストを振り分けることができるようになります。

##■ Amazon ECR
　AWS Fargateでは、コンテナレジストリ（Docker HubやAmazon ECR）に格納されたコンテナイメージを元にコンテナを構築します。今回は、自作したDockerfileからコンテナイメージを作成し、Amazon ECRに格納しました。

　Amazon ECRは、格納されたコンテナイメージを自動でスキャンして脆弱性を検査します。さらに、コンテナイメージを暗号化することもできるため、セキュリティ面も安心です。

##■ Amazon EFS
　コンテナの管理を容易にするために、AWSのファイルシステムを提供するAmazon EFSを利用²しました。
　コンテナイメージには、コンテナ上で動作するソフトウェアの設定ファイルなどを含めることができますが、設定を変更するたびにコンテナイメージを作り替える必要があり、コンテナの管理に手間がかかります。Amazon EFSを利用することで、設定ファイルなどをコンテナイメージから切り離すことができ、設定変更時にコンテナイメージの作り替えが不要になるため、コンテナ管理が容易になります。

　あらかじめ、ソフトウェアの設定ファイルなどをAmazon EFSに格納し、AWS Fargate上でコンテナ起動時に自動で読み込ませることができます。

　　　　

##■ AWS Systems Manager
　DB接続情報（ユーザ名やパスワードなど）は、AWS Systems Manager パラメータストアに保存することで、ソフトウェアの設定ファイルからシークレットな情報を切り離しました。

　AWS Systems Manager パラメータストアは、設定データの管理と機密管理のためのストレージです。パスワード、データベース文字列、Amazon マシンイメージ (AMI) ID、ライセンスコードなどのデータをパラメータ値として保存でき、パラメータ値はプレーンテキストまたは暗号化されたデータとして保存できます。次はパラメータの保存例です。

　上記のパラメータ値を環境変数としてAWS Fargate上のコンテナで利用するには、次に示すように、タスク定義の「コンテナの編集」画面から「環境変数」欄にAWS Systems Manager パラメータストアのパラメータ名を設定します。

#コンテナ運用
　コンテナ運用では、システム安定稼働のための設定がポイントになります。今回はコンテナの負荷に応じたスケーリングで可用性を向上するために、AWS FargateにAuto Scalingを設定しました。

##■ Auto Scaling
　Auto Scalingは、常時必要なコンテナの起動台数や、負荷に応じてスケールイン/スケールアウトしたときのコンテナの最小/最大起動台数を設定します。さらに、自動タスクスケーリングポリシーを作成すると、リソース使用量のしきい値に応じたスケーリングやスケーリングのクールダウン期間(※)などを設定できます。

　AWS Fargateでは、コンテナの負荷に応じて柔軟にコンテナ台数をスケーリングすることが可能です。また、ホストを管理する必要がないため、スケールアウト時にサーバリソースを増強する必要などがなく、コストの削減になります。

※秒単位でスケーリングの間隔を指定します。

#コンテナ監視
　コンテナ監視では、運用時と同様にシステム安定稼働のための設定がポイントになります。今回はコンテナの保守性を向上するために、コンテナのログやリソース使用状況を監視しました。また、Prometheusに対応した形式の、コンテナの詳細なリソース状況やソフトウェアの統計情報、Java VMのパフォーマンスなどといったメトリクス³（Prometheusメトリクス）も監視しました。

##■ Amazon CloudWatch
　コンテナのログやリソース使用状況を監視するために、Amazon CloudWatchを使用しました。AWS Fargateでは、デフォルトでコンテナのログやリソース使用状況をAmazon CloudWatchに送信します。

　Amazon CloudWatchでは、アラームを作成することで、コンテナのエラーメッセージの出力やリソースの異常値を検知したときにメール通知(※)することも可能です。

※メール通知にはAmazon SNSの設定が必要です。

##■ Amazon CloudWatch エージェント
　Prometheusメトリクスを監視するために、Amazon CloudWatch エージェントを構築しました。Amazon CloudWatch エージェントを利用すると、自動でコンテナのPrometheusメトリクスを監視し、Amazon CloudWatchに送信してくれます。

　Amazon CloudWatch エージェントの構築には、Amazon CloudFormationのテンプレートを使用しました。テンプレートを使用すると、Amazon CloudWatch エージェントの構築に必要なIAMロール、AWS Systems Manager パラメータ、AWS Fargateのサービスやタスク定義などのAWSリソースが自動的に生成されるため、構築が容易です。

　AWS Fargateの場合、テンプレートは次のコマンドを実行して取得します。

# curl -O https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/master/ecs-task-definition-templates/deployment-mode/replica-service/cwagent-prometheus/cloudformation-quickstart/cwagent-ecs-prometheus-metric-for-awsvpc.yaml

　主なテンプレート編集箇所は「task_definition_list」で、以下の例のように定義することで監視したいタスク（コンテナ）を指定できます。

"task_definition_list": [
  {
    "sd_job_name": "prometheus", // メトリクスを出力したいAmazon CloudWatchのログストリーム名
    "sd_metrics_ports": "8080", // メトリクスが出力されるポート
    "sd_container_name_pattern": "^container$", // 正規表現を使用したコンテナ名
    "sd_task_definition_arn_pattern": ".*:task-definition/.*sample-task.*:[0-9]+", // 正規表現を使用したタスク定義名
    "sd_metrics_path": "/metrics" // メトリクスが出力されるエンドポイント
  }
]

　上記を設定するとAmazon CloudWatchのロググループ「aws/ecs/containerinsights/<クラスター名>/prometheus」の、"sd_job_name"に設定した名前のログストリーム配下にPrometheusメトリクスが出力されます。

#まとめ
　AWS Fargate上にコンテナを構築して、運用・監視してみました。
　AWS Fargateは、オンプレやAmazon EC2のDocker上にコンテナを適用する場合と比べて、ホストとなるサーバ（インスタンス）やDockerを意識する必要がないので、コンテナ管理が容易で、AWSマネジメントコンソールの操作で簡単にコンテナを構築できました。また、AWSのサービスと連携することにより、効率的にコンテナを構築・運用・監視できそうです。
　次は、他クラウド環境との比較や、運用費などのコスト面についても調べて比較してみたいです。

・Amazon Web Services、“Powered by AWS”ロゴ、［およびかかる資料で使用されるその他のＡＷＳ商標］は、米国その他の諸国における、Amazon.com, Inc.またはその関連会社の商標です。
・Docker は、Docker Inc. の米国およびその他の国における登録商標もしくは商標です。
・その他記載されている会社名、製品名はそれぞれ各社の商標および登録商標です。

1. 単一のロードバランサを設定する場合はAWSマネジメントコンソールの操作で設定できますが、複数のロードバランサを設定する場合は、サービス定義パラメータを使用してAWS CLIで設定する必要があります。 ↩

2. AWS Fargateのプラットフォームバージョンが1.4.0の場合のみ利用できます。 ↩

3. ソフトウェアによっては、Prometheusメトリクス出力のために別途プラグインなどを適用する必要があります。 ↩