[レポート]AWS Fargateを利用したマイクロサービスの開発手法[CON315] #reinvent

AWS Fargateを利用したマイクロサービスなシステムについての開発手法についてのセッションレポートとなります。

セッション内容

CON315 Deploying Microservices Using AWS Fargate

セッション概要

KPMGは、AWSのハイプロファイルバンキングクライアントの顧客デューデリジェンスソリューションを構築しました。
このソリューションは、AWS Fargateを使用してコンテナに配備される多くのマイクロサービスで構成されています。 このセッションでは、ソリューションのアーキテクチャの詳細について説明します。 HashCorpのTerraformやJenkinsなどのサードパーティのツールを使用して、インフラストラクチャとアプリケーションをどのように展開するかを議論し、本番環境でコンテナを実行するためのベストプラクティスを共有します。
Amazon DynamoDB、Amazon ECS、AWS Fargate、Amazon S3、CI / CD、自動化など、ソリューションで使用されているAWSリソースについても詳しく説明します。
私たちは、銀行の規制要件を満たすセキュリティに重点を置いています。 また、KPMGがECSおよびFargateへのカナリーデプロイメントの設定方法、秘密の管理および暗号化の処理方法、ECSサービスディスカバリとAmazon Route 53を使用するマイクロサービス間のサービスディスカバリの管理方法についても説明します。

登壇者

Deepak Dayama Ariane Gadd

Agenda

• AWS Fargate itroduction and use cases
• Managing multiple environments in AWS Fargate
• Developing, deploying and managing compliant workloads at KPMG

AWS Fargateの紹介とユースケース

AWS Fargateの概略

最初にAWSのコンテナサービス全般を基本から振り返ります。

コントロールプレーン層（Management）には、Amazon ECSとAmazon EKS。データプレーン層（HOSTING）には、Amazon EC2とAWS Fargate。イメージレジストラとしてAmazon ECRが存在します。

ECS（Fargate）を利用した時の構造がこちら。

• Task Definition
  • コンテナの定義そのもの
  • CPU使用量、メモリ使用量、イメージのURL、環境変数などを定義
• Task
  • Task Definitionから起動される実態としてのコンテナインスタンス
  • ここで、Fargateタイプを利用
• Service
  • 起動するTask数の定義
  • 関連付けられるELBの定義
  • Unhealthyなタスクの自動的な失効処理
• Cluster
  • インフラの境界線
  • 主にIAMの境界線として利用

起動タイプのEC2の採用について

以下のユースケースであれば、EC2ローンチタイプの利用も視野に入れてよい。

• GPUの利用
• Windows ネイティブコンテナの利用
• Spot Fleetの利用
• 特定のインスタンス対応の利用（例、C5 for AVX-512 instruction set）
• daemon-setsや同一タスクで共有するコンテナの利用

このように、EC2とFargateの共有も可能。

AWS Fargateにおける複数環境の管理

Fargateにおいて、clusterは管理機能の境界線と定義できる。

権限の境界をまとめた図がこれだ。

• Clusterの権限
  • 誰がClluster内のタスクを参照することができるか？
• アプリケーション（task）の権限
  • どのAWSリソースが、このアプリケーションにアクセスできるか？
• コンテナ内権限
  • ECSが動作に必要なAWS関連サービスの定義
  • 例（ECR Image pull,CloudWatch Logs pushing,ENI creation,Register/deregister targets into ELB)

以下のようなPROD,BETA,QA,DEVの4つに分かれるような複数環境の管理について見ていこう。

各コンポーネントレベルでのネットワークの境界線を意識することが重要だ。

• タスクレベル
  • Fargateにおいて、ネットワークモードはAWSVPCモードが必須となる。そのため、それぞれのタスクは個別のENIを持つ
  • セキュリティグループとネットワークACLで、全ての通信は制御可能
  • パブリックIPをサポート
• サービスレベル
  • サービスは、可用性を高めるため、複数AZのサブネットで構成することを推奨
• クラスターレベル
  • IPアドレスの不足、もしくはVPCの構成変更に対応可能とするため、異なるVPC、もしくはCIDRで構築する

また、コードの変更なしにそれぞれのクラスターを管理するために、サービスディスディスカバリーの導入を検討する。マネージド・サービスディスカバリーの導入には以下のメリットがある。

• 別途インストールや導入によるオーバーヘッドが無い
• 可用性が高くスケールしやすい
• 自動的に名前解決を行う

サービスディスカバリーはRooute 53のauto naming APIによって実現されている。

Fargateはすでに多くの顧客で利用されている。

KPMGでの導入事例

どうも、Ariane Gaddです。私の方からは、以下の3つのトピックについてお話させていただきます。

• DEVELOPING
• DEPLOYING
• MANAGINNG

KPMGhは250を超えるPruductionワークロードをもち、グローバルな非常に多くのセクターでアプリケーションをホストしています。

従来は、以下のアーキテクチャを採用していました。

• SQL 2008 on EC2
• .NET deployments to Windows EC2
• Have to managae regular patching, maintenance of servers
• Requirement for server level access

このプロジェクトでは、以下の通りにアーキテクチャーを刷新しました。

現在のマイクロサービス化したアーキテクチャがこちら。

マイクロサービスアーキテクチャ化することにより、以下のメリットを享受できました。

• Immutable deploymentsの実現
• サーバーへのログイン不要
• クラスターリソースのプロビジョニングは全て、AWS Fargateにお任せ
• OSレイヤーは管理が不要
• マシンのスケールや設定が全て不要

本番環境へのデプロイルートはこちら。

デプロイのパイプラインにおいては、ECS（Fargate）へのデプロイはTerraformを利用している。

ECSへのTerraformデプロイのサンプルコードはこのようになっています。

セキュリティに関する考慮点は以下の通り。

• Fargateは既存のVPC内で動作するため、その管理は自分たちで行う必要がある
  • セキュリティグループやNACL、サブネットなど
• 全てのマイクロサービスは前段にALBを配置
  • それぞれにWAFを設置し、SSL終端
• ログは全てCloudwatch Logsに転送
• Twistlockコンテナセキュリティはパワフルでスケーラブルなクラウドベースのコンテナセキュリティ製品
• サーバーはAWSにより管理されているため、Anti-Malware、IDS/IPSなどはAWSにお任せできる

総合的に、AWSの採用は非常に多くのメリットをKPMGに提供してくれた。

濱田感想「AWS Fargateにまつわる内容が一通り含まれたバランス良いセッション」

AWS Fargateの利用方法についての概説がわかりやすく説明されているセッションでした。特にデプロイパイプラインでTerraformを利用しているあたりは、実際のコードも含めて非常に参考になります。

CloudFormationしか使ったことのない自分ですが、Terraformも触ってみたくなりますね。特に、KPMGはCloudFormationからTerraformに移行しているという例なので、面白かったです。

それでは、今日はこのへんで。濱田（@hamako9999）でした。