AWS re:Invent 2022 参加報告レポート(2) 空前絶後の発展を続けるECS。その進化に迫る

はじめに

こんにちは。NTTデータシステム技術本部クラウド技術部です。
私たちNTTデータでも、どんどんクラウドネイティブなプロジェクトが増えています。クラウドネイティブなプロジェクトではコンテナ基盤のデファクトスタンダードであるKubernetesを利用するケースもありますが、AWSを利用するプロジェクトでは、よりAWSの各種サービスと連携が容易であるECS(Amazon Elastic Container Service)が利用されるケースも多くあります。

今回は2022年11月28日から5日間にかけて開催されたAWS re:Inventから筆者が参加してきたセッションを振り返り、コンテナやECSに関する情報をお届けします。

なお、本記事はAWS re:Invent 2022 参加報告レポートの第２回です。第1回ではKeynote(基調講演)について紹介しています。ぜひこちらもご覧ください。

第1回:
AWSは次の形態へ。Keynoteで見るサステナビリティ強化と産業界に特化したビジネス価値向上への追求

ECSとは

ご存じの方も多いと思いますが、まずはECSについておさらいをしましょう。

ECS(Amazon Elastic Container Service)は、AWSが提供するコンテナオーケストレーションのマネージドサービスです。コントロールプレーンはAWS側が管理し、データプレーンについてもFargateを使うことでインフラ部分がAWS管理となり、利用者はアプリケーションの提供に専念することができます。

AWSが提供するコンテナオーケストレーションのサービスとしては、他にもOSSのコンテナオーケストレータであるKubernetesをベースとしたEKS(Elastic Kubernetes Service)もあります。EKSはKubernetesをベースとしているため、豊富なサードパーティソリューションを取り入れて利用することができます。それに対してECSはAWS独自仕様となるため対応するソリューションはEKSに比べると少ないものの、EKSに比べるとよりマネージドで提供される機能が多く、AWSの各種サービスとの連携がしやすいことから、一般的には簡易に運用することが可能になります。

利用がどんどん広がるECS

本稿を読んでいる方の中にもすでにコンテナを利用している方は多くいらっしゃると思います。
re:Inventにおいてもコンテナへの注目度は依然として高く、多くのセッションに聴講者が詰めかけ、満員で入れないセッションも数多くありました。講演の中でもECSのタスクは毎週22億以上ものタスクが起動していることが紹介され、その利用度の高さを知りました。

ECS Service Connect

今回のre:Inventにおいて、ECS関連で大きな盛り上がりを見せた新機能が、ECS Service Connectです。

これはECSのサービス間通信の新たな選択肢となるものです。これまでECSのサービス間通信は、以下の3種類の選択肢が用意されていました。

Cloud Mapを利用したサービスディスカバリ。名前解決をしてサービスへの通信をおこなう
Elastic Load Balancing(ELB)を用いてサービスへの通信をおこなう
App Meshを用いてサービスメッシュを構築する

それぞれ一長一短、特徴があり、利用をする際には重要視する要件やノックアウトファクターをもとに選定をおこなってきました。これが新しい選択肢の追加により、大きく変わることが予想されます。

ECS Service Connectについては、それだけを語るセッションもありました。その中ではECS Service Connectの特徴として、Cloud Mapを用いたサービスディスカバリよりも高性能で、App Meshよりも構成要素が少なくシンプルな構成であるという説明がありました。

筆者もre:Inventから帰ってきたあと、さっそく試してみましたがマネジメントコンソール上で、数か所設定を入れるだけで簡単に動作させることができました。また、機能面でも、サービス間通信のメトリクス（通信量やHTTPレスポンスのステータスコード別のレスポンス数など）も簡単に取得することができました。

ECS Service Connectの登場により、より多彩なシステムをECS上で構築できると筆者は考えています。これまでのECSでは、シンプルなシステム構成は簡易に実現できる一方で、MSA(マイクロサービスアーキテクチャ)を実装しようとする場合、実現方式に課題がありました。サービス間通信にもELBを利用するとシステム構成が複雑になり、インフラコストも高くついてしまいます。Cloud Mapのサービスディスカバリではサービス間通信のメトリクスがデフォルトでは取得できないことから、障害時等の解析や分析が難しく、そのためのメトリクス取得を利用者側で作りこむ必要がありました。App Meshであればサービスメッシュを構築できますが、独自要素が多く学習コストが高くなり、導入が困難なケースが多々ありました。

その点、ECS Service Connectであれば、シンプルな構成でサービス間通信のメトリクスも取得できるため、今後ECS上でもMSAの実現が容易になると考えます。ECS Service Connectは、今後のサービス間通信のデファクトスタンダードに成長していくと思われます。ぜひECSを利用している方にはチェックしていただきたい、そんな機能アップデートでした。

今後のECS

また、私が参加したセッションでは、ECSのGeneral ManagerであるNick Coultより、今後の機能拡張に関する予告も行われました。

筆者が特に気になったのはECSのネイティブでのBlue/Greenデプロイ(B/Gデプロイ)やカナリアデプロイへの対応です。

切り戻しを迅速におこないたいケースや利用者影響を極小化しながら段階的にリリースしたい場合、B/Gデプロイやカナリアデプロイを検討するケースは多くあります。現時点のECSではB/Gデプロイを実現するにはELBを用意して、CodeDeployを利用してターゲットグループを操作するか、AWS APIを使ってそれを作りこむ必要があります。

前述したECS Service Connectも、現時点ではB/Gデプロイには対応しておらず、ELB以外の方式と同様にローリングアップデートにしか対応していません。

セッションでは詳細は詳しく語られませんでしたが、セッション後に登壇者の方と議論したところ「ECSのサービス開発は別チームでおこなっているので実際にどのようなスペックになるかは断言できないけれど、自分もECS Service Connectをはじめ他の方式でもB/Gデプロイに対応するようになると信じているし、そうなると嬉しいよね」と言っていました。

これがリリースされることで、これまでのコンテナへの通信やコンテナ間通信の選定基準が大きく変わることが予感されます。今後これまで以上に柔軟性の高いシステムが作れ、エンドユーザへの価値が提供しやすくなるのが楽しみです。

他にもタスク定義の削除やFargateのGPU対応などこれまで実現できなかった内容も予告されています。なお、AWSの各種サービスの中でもコンテナのサービスは、他のサービスと異なる特徴的な点として、今後のロードマップや開発状況が公開されています。ECSをはじめとするコンテナ関連の今後のサービス進化をいち早く知りたい方はこちらをチェックすることもオススメです。