サービスメッシュとは何ですか?
サービスメッシュは、アプリケーション内のサービス間のすべての通信を処理するソフトウェアレイヤーです。このレイヤーは、コンテナ化されたマイクロサービスで構成されています。アプリケーションがスケールし、マイクロサービスの数が増えるにつれて、サービスのパフォーマンスをモニタリングすることは困難になります。サービス間の接続を管理するために、サービスメッシュでは、モニタリング、ログ記録、トレース、トラフィックコントロールなどの新機能を使用できます。各サービスのコードに依存しないため、ネットワークの境界を越えて複数のサービス管理システムと連携できます。
なぜサービスメッシュが必要なのですか?
最新のアプリケーションアーキテクチャでは、独立してデプロイ可能な小さなマイクロサービスの集合としてアプリケーションを構築できます。さまざまなチームが個別のマイクロサービスを構築し、それぞれのコーディング言語とツールを選択することがあります。ただし、アプリケーションコードが正しく動作するには、マイクロサービスが通信する必要があります。
アプリケーションのパフォーマンスは、サービス間の通信の速度と回復力に依存します。デベロッパーはサービス全体でアプリケーションをモニタリングして最適化する必要がありますが、システムは分散型であるため、可視性を得ることは困難です。アプリケーションがスケールするにつれて、通信の管理はさらに複雑になります。
サービスメッシュの採用には 2 つの主な要因があり、それらについて次に詳しく説明します。
サービスレベルのオブザーバビリティ
デプロイされるワークロードとサービスの数が増えるにつれ、デベロッパーはすべてがどのように連携するかを理解するのが難しくなります。例えば、サービスチームは、ダウンストリームとアップストリームの依存関係を知りたいと考えています。そして、サービスとワークロードがアプリケーションレイヤーでどのように通信するかをより詳細に可視化したいと考えています。
サービスレベルコントロール
管理者は、どのサービスが相互に通信し、どのようなアクションを実行するかを制御したいと考えています。マイクロサービスアーキテクチャ内のサービスの動作、ポリシー、相互作用をきめ細かく制御し、ガバナンスを行いたいと考えています。セキュリティポリシーを実施することは、規制遵守にとって不可欠です。
サービスメッシュにはどのような利点がありますか?
サービスメッシュは、分散アプリケーション内の複雑なサービス間通信を処理する一元化された専用インフラストラクチャレイヤーを提供します。次に、サービスメッシュの利点をいくつか紹介します。
サービスの検出
サービスメッシュはサービス検出を自動化し、サービスエンドポイントを管理する運用上の負荷を軽減します。サービスレジストリを使用して、メッシュ内のすべてのサービスを動的に検出して追跡します。サービスは、場所や基盤となるインフラストラクチャに関係なく、互いにシームレスに検索して通信できます。必要に応じて新しいサービスをデプロイすることで、迅速にスケールできます。
ロードバランシング
サービスメッシュは、ラウンドロビン、最小接続、加重ロードバランシングなどのさまざまなアルゴリズムを使用して、複数のサービスインスタンスにリクエストをインテリジェントに分散します。ロードバランシングにより、リソース使用率が向上し、高い可用性とスケーラビリティが確保されます。パフォーマンスを最適化し、ネットワーク通信のボトルネックを防ぐことができます。
トラフィック管理
サービスメッシュには高度なトラフィック管理機能があり、リクエストのルーティングとトラフィックの動作をきめ細かく制御できます。以下はその一例です。
トラフィック分割
受信トラフィックを異なるサービスバージョンまたは構成に分けることができます。メッシュは一部のトラフィックを最新バージョンに誘導するため、制御された段階的な変更のロールアウトが可能になります。これにより、移行がスムーズになり、変更による影響が最小限に抑えられます。
ミラーリングをリクエスト
主要なリクエストフローに影響を与えることなく、トラフィックをテストサービスまたはモニタリングサービスに複製して分析できます。リクエストをミラーリングすると、本稼働トラフィックに影響を与えずにサービスが特定のリクエストを処理する方法についてのインサイトが得られます。
canary デプロイ
ごく一部のユーザーまたはトラフィックを新しいサービスバージョンに誘導できますが、ほとんどのユーザーは引き続き既存の安定バージョンを使用します。公開範囲が限られているため、実際の環境で新しいバージョンの動作とパフォーマンスを試すことができます。
セキュリティ
サービスメッシュは、相互 TLS (mTLS) 暗号化、認証、承認などのセキュアな通信機能を提供します。相互 TLS により、サービス間通信での ID 検証が可能になります。トラフィックを暗号化することで、データの機密性と完全性を確保します。また、承認ポリシーを適用して、どのサービスが特定のエンドポイントにアクセスするか、特定のアクションを実行するかを制御できます。
モニタリング
サービスメッシュには包括的なモニタリング機能とオブザーバビリティ機能があり、サービスの健全性、パフォーマンス、動作に関するインサイトを得ることができます。モニタリングはトラブルシューティングとパフォーマンスの最適化もサポートします。使用できるモニタリング機能の例は次のとおりです。
- レイテンシー、エラー率、リソース使用率などのメトリクスを収集して、システム全体のパフォーマンスを分析する
- 分散トレーシングを実行して、複数のサービスにわたるリクエストの完全なパスとタイミングを確認する
- 監査、デバッグ、およびコンプライアンスの目的で、サービスイベントをログにキャプチャする
サービスメッシュの仕組み
サービスメッシュは、サービス間通信を制御するロジックを個々のサービスから削除し、通信を独自のインフラストラクチャレイヤーに抽象化します。複数のネットワークプロキシを使用して、サービス間の通信をルーティングおよび追跡します。
プロキシは、組織のネットワークとマイクロサービスの間の仲介ゲートウェイとして機能します。サービスとの間で送受信されるすべてのトラフィックは、プロキシサーバーを経由してルーティングされます。個々のプロキシは個別に動作しますが、論理的には各サービスの隣にあるため、サイドカーと呼ばれることもあります。プロキシを合わせると、サービスメッシュレイヤーが形成されます。
サービスメッシュアーキテクチャには、コントロールプレーンとデータプレーンという 2 つの主要コンポーネントがあります。
データプレーン
データプレーンは、サービスメッシュのデータ処理コンポーネントです。すべてのサイドカープロキシとその機能が含まれています。あるサービスが別のサービスと通信したい場合、サイドカープロキシは次のアクションを実行します。
- サイドカーがリクエストをインターセプトする
- リクエストが別のネットワーク接続にカプセル化される
- 送信元と宛先のプロキシ間に安全で暗号化されたチャネルが確立される
サイドカープロキシは、サービス間の低レベルのメッセージングを処理します。また、回線の遮断やリクエストの再試行などの機能も実装して、耐障害性を高め、サービスの低下を防ぎます。ロードバランシング、サービス検出、トラフィックルーティングなどのサービスメッシュ機能はデータプレーンに実装されています。
コントロールプレーン
コントロールプレーンは、サービスメッシュの中心の管理/設定レイヤーとして機能します。
コントロールプレーンを使用すると、管理者はメッシュ内のサービスを定義および設定できます。例えば、サービスエンドポイント、ルーティングルール、ロードバランシングポリシー、セキュリティ設定などのパラメータを指定できます。構成が定義されると、コントロールプレーンは必要な情報をサービスメッシュのデータプレーンに配信します。
プロキシは構成情報を使用して、受信リクエストの処理方法を決定します。また、構成の変更を受け取り、その動作を動的に適応させることもできます。サービスの再起動や中断なしに、サービスメッシュ構成をリアルタイムで変更できます。
サービスメッシュ実装には通常、コントロールプレーンに以下の機能が含まれます。
- メッシュ内のすべてのサービスを追跡するサービスレジストリ
- 新しいサービスの自動検出と使用頻度の低いサービスの削除
- メトリクス、ログ、分散トレーシング情報などのテレメトリデータの収集と集約
Istio とは?
Istio は、主に Kubernetes と連携するように設計されたオープンソースのサービスメッシュプロジェクトです。Kubernetes は、コンテナ化アプリケーションを大規模にデプロイおよび管理するために使用されるオープンソースのコンテナオーケストレーションプラットフォームです。
Istio のコントロールプレーンコンポーネントは、それ自体が Kubernetes ワークロードとして実行されます。サイドカープロキシ設計の基礎として、Kubernetes Pod (1 つの IP アドレスを共有する緊密に結合されたコンテナのセット) を使用します。
Istio のレイヤー 7 プロキシは、メインサービスと同じネットワークコンテキストで別のコンテナとして実行されます。その位置から、Pod を通過するすべてのネットワークトラフィックをインターセプト、検査、および操作できます。それでも、プライマリコンテナには変更を加える必要はなく、これが起こっていることを知る必要さえありません。
オープンソースのサービスメッシュ実装の課題は何ですか?
ここでは、Istio、Linkerd、Consul などのオープンソースプラットフォームに関連する一般的なサービスメッシュの課題をいくつか紹介します。
複雑さ
サービスメッシュには、追加のインフラストラクチャコンポーネント、構成要件、およびデプロイ上の考慮事項があります。デベロッパーと運用者は特定のサービスメッシュ実装の使用に関する専門知識を身に付ける必要があるため、習得するまでの時間が長くなります。チームのトレーニングには時間とリソースが必要です。組織は、サービスメッシュアーキテクチャの複雑さを理解し、効果的に構成するために必要な知識をチームに提供する必要があります。
運用上のオーバーヘッド
サービスメッシュは、データプレーンプロキシとコントロールプレーンコンポーネントのデプロイ、管理、モニタリングに追加のオーバーヘッドをもたらします。例えば、次のことを行う必要があります。
- サービスメッシュインフラストラクチャの高可用性とスケーラビリティを確保する
- プロキシの健全性とパフォーマンスをモニタリングする
- アップグレードと互換性の問題へ対処する
システム全体のパフォーマンスへの影響を最小限に抑えるには、サービスメッシュを慎重に設計して構成することが不可欠です。
統合に関する課題
サービスメッシュは、必要な機能を実行するために既存のインフラストラクチャとシームレスに統合する必要があります。これには、コンテナオーケストレーションプラットフォーム、ネットワークソリューション、およびテクノロジースタック内のその他のツールが含まれます。
複雑で多様な環境において、他のコンポーネントとの互換性とスムーズな統合を確保することは難しい場合があります。API、構成形式、依存関係を変更するには、継続的な計画とテストが必要です。スタックのどこかで新しいバージョンにアップグレードする必要がある場合も同様です。
AWS はお客様のサービスメッシュ要件をどのようにサポートできますか?
AWS App Mesh は、Amazon Web Services (AWS) が提供するフルマネージド型の高可用性サービスメッシュです。App Mesh で、サービス間の通信のモニタリング、管理、デバッグが簡単になります。
App Mesh は、マイクロサービスコンテナと同時にデプロイされるオープンソースのサービスメッシュプロキシである Envoy を使用します。Amazon Elastic Container Service (Amazon ECS)、Amazon Elastic Kubernetes Service (Amazon EKS)、AWS Fargate、および Kubernetes on AWS によって管理されているマイクロサービスコンテナで使用できます。また、Amazon Elastic Compute Cloud (Amazon EC2) のサービスでも使用できます。
今すぐアカウントを作成して、AWS でサービスメッシュの使用を開始しましょう。
