Amazon ECSによるモダンアプリケーション開発の高速化

Pulisher : Strategic Tech Center チャン・セジョン
Description : Amazon ECSのアーキテクチャ、セキュリティ管理方式、展開方式とその違いを説明するセッション

はじめに

EKSはその間、EKSはたくさん接して扱いましたが、お客様を通じて実務でECSよりEKSを多く使うため、ECSは経験したことがなく、ECSについて知りたいという気持ちが大きく、ECSの長所や短所も知ることができるのではという期待感でセッションを申し込みました。

セッションの概要紹介

このセッションでは、ECSのアーキテクチャや展開方法、セキュリティ強化対策などについて説明します。
それでは、ECSのアーキテクチャからECSについて学んでいきましょう。

ECSは管理者や開発者がDefinitionを定義すると、それに合わせて独自にELB、Secret Manager、EFSを連動してContainerをFargateやEC2方式で起動するアーキテクチャを持っています。

知っておくべきことはECSはKubernetesではなく、AWSでサービスするContainer自体管理型サービスのような概念です。

ECSはContainerをFargate方式で上げるかEC2方式で上げるかを選択することができます。

それによって内部的なアーキテクチャが少し違います。

簡単に説明すると、Fargate方式はEC2つまり、サーバーを管理する必要がないので、ノードごとにあるノードの大黒柱であるKubeletなどを気にする必要がありません。

ECSの権限に関するセキュリティーについてです。

ContainerごとにIam Roleを個別に付与することができるので、S3へのアクセスが必要なContainer、DynamoDBへのアクセスが必要なContainerに対して個別のアクセス制御が可能です。

そのContainerがアクセス権限が必要な部分だけ与えることができるのですが、この方法がとても簡単でECSの強みだと感じる部分です。

さて、ECSのファイアウォール関連のセキュリティの話です。

実はとても簡単です。既存にAWSを使ってたら当たり前のように思えるかもしれません。

つまり、ALBが外部のトラフィックを受けてそれをFrontendサービスが受け取ります。 この時、FrontendサービスのSG InboundにALBのSG IDを登録します。

このようにBackendサービスSGにはFrontend SGを登録します。BackendでAuroraにアクセスしたらAurora SGにBackend SG IDを登録します。

簡単ですね^^。

配布方式について説明する時間です。

色んな方式がありますが、今回はRolling方式について説明します。新しくデプロイするTask Definitionを先にデプロイして、それからトラフィックを受ける役割をするServicesをデプロイします。

配布方式のうち、ブルー/グリーン方式についても説明します。

はい、この方式はTask DefinitionとServiceを新規セットで作って、既存の古いTask DefinitionとServiceセットを削除する方式です。

最後にobservabilityの部分、つまり、モニタリングの話です。

AWS Native Serviceのような場合、CloudWatchなどを使ってモニタリングして、OpenSourceの場合、Amazon Managed PrometheusやAmazon Managed Grafanaを使ってモニタリングすればいいそうです。

Amazon Managed PrometheusやAmazon Managed Grafanaを利用してモニタリングすればいいそうです。

セッションを終えて

このセッションはECSの基本的なアーキテクチャからセキュリティ管理方式、展開方式とその違いを説明するセッションでした。EKSとECSの違いを比較する内容はなくて、ちょっと残念でした。

しかし、ECSが非常にシンプルなアーキテクチャの中でAWSのサービスを活用した簡単で安定的なContainer運営サービスであることを感じさせてくれるセッションでした。

もし、顧客がインフラ管理に消費される工数を最小限にして開発だけに集中したいのであれば、ECSが優秀な選択になるだろうという考えができるようになるセッションでした。