2023/6/30 Kazunori Inaba 2023.6.30 第30回 JAWS-UG札幌 勉強会 ECS on Fargate構築の課題と解決策 稲葉 一紀＠札幌 1

2023/6/30 Kazunori Inaba 稲葉 一紀 (Kazunori Inaba) • サーバーインフラ専門のフリーランスエンジニア＠札幌 • AWS認定は Solutions Architect Association (SAA) 1冠 • 屋号: 稲葉サーバーデザイン (2013-) https://inaba-serverdesign.jp/ 2 自己紹介

はじめに 2023/6/30 Kazunori Inaba みなさん、 ECS、使っていますか？ 3

はじめに 2023/6/30 Kazunori Inaba • 医療・介護・福祉系SNSのサーバー構築（移行）。 • 担当者: アプリ開発担当（アプリ開発とアプリコンテナ作成）と稲葉 （AWS構築）の2人。 • 2人とも、はじめてのECS構築。 • コンテナ実行環境を用意するだけなので簡単だと思っていた。 → 機能名にとまどったり、構築作業中に課題やリクエストが出てき たりで意外と大変だった！ • ECS on Fargate構築時の課題と解決策についてお話します。 ※スライドは後日Speaker Deckにアップします。 https://speakerdeck.com/kazunoriinaba/ ※ブログ書きました。 https://inaba-serverdesign.jp/blog/20230607/aws-ecs-fargate.html 4

AWS構成 2023/6/30 Kazunori Inaba • 医療・介護・ 福祉系SNS • Railsアプリ • 2023年6月上旬 Azureから移行 5

構築時の課題いろいろ 2023/6/30 Kazunori Inaba 1. ECS構成要素の理解 2. アプリケーション環境変数の渡し方 3. タスクロールとタスク実行ロール 4. 稼働中のコンテナでデバッグ 5. ログ振り分け 6. 外部アクセス時のアクセス元IPアドレス固定 6

課題1. ECS構成要素の理解(1) 2023/6/30 Kazunori Inaba いざ、ECSを構築しようとすると出てくる構成要素の用語 • クラスター • サービス • タスク • タスク定義 • コンテナ ↑抽象的なネーミングで、最初はわかりにくいような。。 7

課題1. ECS構成要素の理解(2) 2023/6/30 Kazunori Inaba • 「サービス」が中心と考えると理解しやすい • ECSとは、 • クラスター（＝複数EC2インスタンスの集合またはFargate）の上で、 • Dockerコンテナを使って、 • サービスを動作させる もの （参考記事より引用、一部変更） • Amazon EC2 Container Service(ECS)の概念整理 - Qiita https://qiita.com/NewGyu/items/9597ed2eda763bd504d7 8

課題1. ECS構成要素の理解(3) 2023/6/30 Kazunori Inaba （参考） • Amazon EC2 Container Service(ECS) の デ ー タ モ デ ル に つ い て 整 理 し た - DevelopersIO https://dev.classmethod.jp/articles/amazon-ecs-datamodel/ • どの構成要素が、どの属性をもっているかについては、AWSCLIや Terraformのドキュメントを読むと、理解しやすいのでは。 9

課題2. アプリケーション環境変数の渡し方 2023/6/30 Kazunori Inaba • 3つの方法 A. タスク定義で指定 B. Secrets Manager または Systems Managerパラメータストアを使 用 C. S3バケットに保存した環境変数ファイルを参照 • 今回は、アプリケーションが扱いやすい C. を選択。 • 環境変数ファイル専用のS3バケットを用意して、「タスク実行ロー ル」に専用S3バケット参照権限を追加。 10

課題3. タスクロールとタスク実行ロール(1) 2023/6/30 Kazunori Inaba • タスク定義作成時の ロール設定 → • 「タスクロール」と 「タスク実行ロール」 どう違う？ 11

課題3. タスクロールとタスク実行ロール(2) 2023/6/30 Kazunori Inaba • タスクロール • コンテナ化されたアプリケーションが、 AWSリソースにアクセスするために 必要な権限を管理する。 • 今回ロールに付与した権限（ポリシー） - フロントエンド、画像配信用S3バケットの読み書き - ジョブ管理用SQSキューの読み書き - ECS Exec実行に必要な権限（ログ出力含む） - FireLens Fluent BitコンテナからCloudWach Logsへのログ出力 12

課題3. タスクロールとタスク実行ロール(3) 2023/6/30 Kazunori Inaba • タスク実行ロール • （アプリケーションコンテナの外側で） ECSコンテナエージェントが、コンテナを 起動・実行するときに、AWSリソースに アクセスするために必要な権限を管理する。 • 今回ロールに付与した権限（ポリシー） - S3バケットの環境変数ファイル取得 - AmazonECSTaskExecutionRolePolicy（AWSがデフォルトで用意した、タ スク実行に必要な最小限のポリシー。ECRからのコンテナイメージダウンロ ードやCloudWatch Logsへのログ出力など） 13

課題4. 稼働中のコンテナでデバッグ 2023/6/30 Kazunori Inaba • Fargateではホストサーバーにログインできないので無理では？ → ECS Execで可能！ • docker execのように、実行中のコンテナに対して、AWS CLIでコマンドを実 行できる機能。 • ECS Exec機能はデフォルトでは無効。AWS CLIで有効化する。 （なぜかマネジメントコンソールで設定できない。。） • ECS「タスクロール」に、ECS Exec実行に必要な権限を付与。 • ECS Execコマンド → AWS Cloud Shell等で実行。 14 $ aws ecs execute-command ¥ --cluster <クラスター名> ¥ --task ＜タスクID> ¥ --container <コンテナ名> ¥ --interactive ¥ --command “<コマンド>”

課題5. ログ振り分け(1) 2023/6/30 Kazunori Inaba • デ フ ォ ル ト で は 、 コ ン テ ナ の 標 準 出 力 と 標 準 エ ラ ー 出 力 が 、 CloudWatch Logsの1つのロググループに出力される。 • 一度のログ出力が複数行に分かれる。 • ヘルスチェックなど、重要でないものも含め大量のログレコードがある。 → そのままでは調査しにくい。 • FireLens (Fluent Bit)を利用して、CloudWatch Logsの複数のログ グループに振り分け。 • 「アプリ」 「ワーカー」 「ヘルスチェック」「SQSポーリング」といった処 理ごとにロググループを分け、保存期間を個別に設定。 15

課題5. ログ振り分け(2) 2023/6/30 Kazunori Inaba • FireLens • アプリケーションコンテナと同じ タスク内にログ収集用コンテナを 設置（「サイドカー」）。 • ログ収集用コンテナ: Fluent Bit or Fluentdを選択 • Fluent BitまたはFluentdの設定で、ログ振り分けルールを記載。 • Kinesis Firehose経由でS3へのログ振り分けも可能。 • AWSマネジメントコンソールでは、FireLensの設定は旧UIで。 • （ECS「タスク実行ロール」ではなく）ECS「タスクロール」にCloudWatch Logsへの書き込み権限を付与する。 16

課題5. ログ振り分け(3) 2023/6/30 Kazunori Inaba • ログ複数行問題 • アプリケーション側で一度のログをJSON形式の1レコードにまとめる。 （参考） • Rails on ECSな構成でFluent Bitを利用して快適なロギングを実現する https://zenn.dev/machamp/articles/50ed6bc383539c • Fluent BitのMuitilineフィルターでも対応可？ 17

課題6. 外部アクセス時のアクセス元IPアドレス固定(1) 2023/6/30 Kazunori Inaba • 外部サービスとの連携のため「アプリケーションからインターネットア クセスする際の、アクセス元IPアドレスを固定したい」 • NATゲートウェイを作成 • NATゲートウェイにElasticIPを 付与。 • ECS用サブネットのデフォルト ルートをNATゲートウェイに。 18

課題6. 外部アクセス時のアクセス元IPアドレス固定(2) 2023/6/30 Kazunori Inaba • NATゲートウェイ利用時の注意点 • 外部インターネットへの通信のほか、VPC外のAWSサービスへの通信もNATゲ ートウェイの処理量課金の対象となる。 - ECRからのコンテナイメージダウンロード - CloudWatch Logsへのログ出力 - S3への静的コンテンツアップロード、ダウンロード - SQSキューへのアクセス • In/Outの処理量合計に対する課金 $0.062/GB 19

課題6. 外部アクセス時のアクセス元IPアドレス固定(3) 2023/6/30 Kazunori Inaba • AWSサービスへの通信をVPCエンドポイント経由とすれば、NATゲー トウェイ課金がなくなる。 • でも、VPCエンドポイントも起動時間・処理量の課金がある。 • 今回は、S3との通信のみVPCエンドポイント（ゲートウェイ型、無料）を利用。 • NATゲートウェイのIn/Out処理量を CloudWatchダッシュボードで監視。 • ECS Scheduled Taskを使用する、コンテナの増減が 多いなど、イメージダウンロード機会が多い場合は、 ECR用のVPCエンドポイントの利用を。 （参考） ・ECS/Fargate VPCエンドポイントとNAT ゲートウェイの損益分岐点をざっくり計算してみた - スクショはつらいよ https://chariosan.com/2022/03/29/ecs_fargate_vpc_endpoint_cost_bep/ 20

ECSを採用してよかったこと(1) 2023/6/30 Kazunori Inaba 【アプリ開発担当者の声】 • PC開発環境にDockerを初導入。 • コンテナをDBサーバー、バックエンド(API)、フロントエンドに分割して開発 （本番環境ではそれぞれ、RDS, ECS, S3に相当）。 • デプロイ作業はバックエンドのみをECSにデプロイできるので簡単。 • デプロイ、ロールバックが楽になった。 • 旧: Capistranoを利用し、Gitに一旦デプロイしてマージ。 • 現: コンテナをビルドしてECRにアップロードし、Webコンソールでデプロイ までできる。ロールバックはサービスのリビジョン変更で簡単。 • デプロイ時に不具合があっても、自動的にロールバックされるので安心 （サーキットブレーカー機能）。 21

ECSを採用してよかったこと(2) 2023/6/30 Kazunori Inaba 【アプリ開発担当者の声】 • 環境変数を1ファイルにまとめて切り分けられる。 • コンテナのビルドと環境変数の設定変更を別々に行える。 • ログ出力を振り分け、コンソールで検索できるので、エラーの原因究明 が早くなった。 ↑「ECSがよかった」というよりは「これを機にコンテナ化、ログ精査 に取り組んだ」ことによるメリットが大きい。 運用のメリットはこれから実感できる？ 22

まとめ 2023/6/30 Kazunori Inaba • ECS on Fargate構築時の課題と解決策、ECSを採用してよかったこと についてお話しました。 • アプリケーションのコンテナ化とECS構築、最初は大変かもしれない けど、一度やってみれば慣れるはず。 • インターネット上の情報も多い。 一度トライしてみては？ 23