【レポート】ECS Service Connect で ECS 上のマイクロサービスの耐障害性と可観測性を高めよう

【レポート】ECS Service Connect で ECS 上のマイクロサービスの耐障害性と可観測性を高めよう

Clock Icon2023.04.22

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは!AWS事業本部のおつまみです!

本記事は 2023 年 4 月 20 - 21 日の 2 日間開催された AWS Summit Tokyoのセッションレポートとなります。

AWS Summit Tokyoの登録を行うことで、2023 年 6 月 23 日 19 時までオンデマンドで視聴可能です。(現地参加された方は改めての登録は不要です。)

ECS Service Connect についてはこちらのブログでも紹介されています。

セッション概要

Amazon ECS 及び AWS Fargate では新しいサービス間通信の方式として、ECS Service Connect を AWS re:Invent 2022 でリリースしました。ECS Service Connect を利用することで、これまでより容易にサービス間の耐障害性や可観測性を高めることが可能となります。本セッションではこれまでのサービス間通信の方式と課題、ECS Service Connect が実現できることについて解説します。

スピーカー

アマゾン ウェブ サービス ジャパン合同会社技術統括本部
インターネットメディアソリューショングループ ソリューションアーキテクト 堀内 保大

はじめに

本セッションの対象となる方

  • コンテナやAmazon Elastic Container Service (Amazon ECS) について概要を理解している
  • Amazon ECS 上でマイクロサービスを構築したいと思っている方
  • Amazon ECS における耐障害性や可観測性の確保に興味のある方

本セッションのゴール

  • Amazon ECS におけるサービス間通信の課題、実現の選択肢を理解できるようになる
  • ECS Service Connect のユースケースやメリットを理解できるようになる

アジェンダ

  1. コンテナとAWSのコンテナサービスのメリット振り返り
  2. マイクロサービスとサービス間通信の課題や実現方法
  3. Amazon ECS Service Connect 概要
  4. Amazon ECS Service Connect Dive Deep
  5. まとめ

レポート

コンテナとAWSのコンテナサービスのメリットと振り返り

企業がコンテナサービスを採用する背景

  • スピードとアジリティ
  • 運用の優秀性とセキュリティ
  • コスト

コンテナがもたらすメリット

  • アプリケーションの可搬性
  • 複数環境にわたる一貫した実行可能性
  • 高速な開発とリリースサイクルの実現
  • サーバレスファーストでよりシンプルにコンテナを実行
  • ECS・Fargateにより高い抽象化とインフラ管理工数の低減アプリケーション開発に注力できるようになる

マイクロサービスとサービス間通信の課題や実現背景

  • マイクロサービスによる開発アジリティの向上
    • 独立した複数のサービスでソフトウェアを構成する
    • ビジネスドメインごとにサービスを分割し疎結合する
    • アプリケーションが複数のサービス

サービス間通信の信頼性を高める工夫 1.耐障害性

  • NWのエラーや遅延、 呼出先の不具合/停止に対する耐障害性の仕組みが必要
    • 呼出先サービスの位置は一定でない → サービスディスカバリ
    • 一時的な呼び出しの失敗 → リトライ (Exponential back-off) 外れ値検知
    • 継続した呼び出しの失敗 → サーキットブレーカー
    • 呼出先サービスのパフォーマンス悪化 → タイムアウト

サービス間通信の信頼性を高める工夫 2.可観測性

  • どこで何が起きたのか、 なぜ起きたのか調査するために、可観測性を高める仕組みが必要
    • 各サービスのメトリクス・ログ・トレースの取得

これまでのサービス間通信の選択肢

  • ロードバランサ有
    • Elastic Load Balancing (ELB)
  • ロードバランサ無
    • ECS service discovery
    • AWS App Mesh

Elastic Load Balancing (ELB)の利用

  • メリット
    • ヘルスチェックなどのさまざまな機能セットを有する
    • トラフィックのメトリクスを取得できる
  • 考慮点
    • 追加のインフラストラクチャが必要となる
    • ネットワークレイテンシーが増加する
    • ヘルスチェックに依存する

Amazon ECS service discoveryの利用

  • メリット
    • クライアントが対向サービスと直接通信する
    • 少数のシステムコンポーネントで構成できる
  • 考慮点
    • リトライ、外れ値検知などの信頼性を保つ通信制御・トラフィックのメトリクス取得などは含まれない

AWS App Mesh の利用

  • メリット
    • リトライ、外れ値検知、 サーキットブレーカー、タイムアウトなどのきめ細かいトラフィックの制御が可能
    • メトリクス、ログ、 トレースなどのトラフィックの豊富な可観測性をもつ
  • 考慮点
    • 追加のコンポーネントの管理が必要となる
    • 柔軟性に伴う複雑性が増す

Amazon ECS Service Connect 概要

特徴

  • サービス間通信における考慮事項が追加設定なしに組み込まれる
    • 耐障害性
    • 可観測性
    • 堅牢なデプロイ

Amazon ECS Service Connect Dive Deep

メリット

  • 耐障害性
    • 設定なしにサービス間通信に対して、耐障害性の仕組みが入る
      • 自動リトライ:NW障害や503エラー時に、Proxyレイヤで別タスクに自動リトライ
      • 外れ値検知:リクエストエラーが連続した場合、ルーティングから一定期間除外
  • 過観測性
    • ServiceConnectProxyが収集するリクエストに関する以下のCloudWatchメトリクスが利用可能
      • 自サービスに関するリクエスト関連
      • 呼び出し先サービスに対するリクエスト関連(REDに関わる)
  • 堅牢なデプロイ
    • Amazon ECSのローリングアップデートをサポート
    • コネクションドレイニング(コネクションの排出)によるダウンタイムなしのデプロイ
    • Cloud Mapを利用することでDNS TTLの影響を受けない高速なデプロイ

これからのサービス間通信の選択肢

  • ロードバランサー有
      1. Elastic Load Balancing (ELB) → 外部からアクセスさせたい。 B/Gデプロイを利用したい場合。
  • ロードバランサー無
      1. Amazon ECS service discovery → プロキシを利用せずに個別実装で信頼性をを導入する場合
      1. AWS App Mesh → 各種設定の閾値変更などの細かい通信制御の要件がある場合
      1. Amazon ECS Service Connect [new] → サービス間通信で信頼性を重視する場合のファーストプライオリティ

まとめ

  • サービス間通信では耐障害性と過観測生の実装が重要
  • 今までは3つの選択肢だったが、ECS Service Connect により、シンプルな設定で高い信頼性を持ったサービス間通信を実現できるようになった
    • 耐障害性: 1. 自動リトライ/ 2.外れ値検知/3.接続タイムアウト
    • 可観測性: サービス間の RED メトリクス
    • 堅牢なデプロイ: ダウンタイム無しのデプロイメント

感想

本記事ではECS Service Connect についてご紹介しました。
昨年のre:Inventで発表されてから、気になってはいたものの使ったことない機能だったため、大変勉強になりました。

よりDeepDiveしたい方はこちらのAWS公式Youtubeやハンズオンが参考になると思います。

最後までお読みいただきありがとうございました!
どなたかのお役に立てれば幸いです。

以上、おつまみ(@AWS11077)でした!

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.