AmazonはサービスメッシュのAWS App Meshをリリースした。マイクロサービス通信の標準化,マイクロサービス間の通信ルールの実装,さらにはメトリクスやログやトレースを取得して,AWSサービスやサードパーティ製ツールに直接取り込むことが可能になる。App Meshの実体は,オープンソースのサービスメッシュデータプレーンプロキシであるEnvoy用に,AWSが独自にホストしたコントロールプレーンである。現時点ではAmazon Elastic Container Service(ECS),Amazon Elastic Container Service for Kubernetes(EKS),およびEC2上のKubernetesで使用することができる。
AWS App Meshでは,サービスのバージョンに基づいて,アプリケーション間のトラフィックルーティングを詳細に指定可能なAPI(CLIおよびSKD経由で公開される)を提供することによって,例えばカナリアリリースや,A/Bデプロイメントが可能になる。サービスのクライアントにアクセス制御や,クオータなどの制限を加えることも可能だ。Envoyの提供する機能を活用して,トラブルシュート時にトラフィックを別環境にシャドウイングしたり,カオス試験の実施のために障害を注入することもできる。ただし,これら機能の一部はGAリリースに予定されているもので,現在のApp Meshには実装されていない。
App MeshをECS上にデプロイするためには,Envoyのプロキシコンテナイメージを関連するタスク定義に追加する必要がある。Kubernetesを使用する場合は,EnvoyプロキシイメージをKubernetes PodSpecに追加しなければならない。Envoy "サイドカー"コンテナを使用することで,関連するサービスからEnvoyのブートストラップ設定で指定されたエンドポイントへの,すべての通信のインターセプトと管理,メトリクスのエクスポート,トレースが可能になる。
AWS App Meshは以下のコンポーネントで構成されている。
- サービスメッシュ: (AWS用語における)"サービスメッシュ"のインスタンスは,内部に存在するサービス間のネットワークトラフィックにおける論理的バウンダリである。
- 仮想ノード: 仮想ノードは,ECSサービスやKubernetesデプロイメントなど,特定の"タスクグループ"への論理的ポインタとして機能する。
- Envoyプロキシとルータマネージャ: Envoプロキシとそのルータマネージャコンテナイメージは,仮想ルータや可能ノードを設定したApp Meshサービスメッシュトラフィックルールを使用するように,マイクロサービスタスクグループを構成する。
- 仮想ルータ: 仮想ルータは,サービスメッシュ内のひとつ以上のサービス名のトラフィックを処理する。
- ルート: ルートは仮想ルータに関連付けられて,サービス名プレフィックスと一致するトラフィックをひとつ以上の仮想ノードに転送する。
App Meshは現在,サービス間の"東西(east-west)"トラフィックの制御と監視を対象ユースケースとしている。"入力ルーティングへのApp Meshの利用"はGA以降の機能ロードマップに掲載されているが,現在のApp Meshの資料では,すべての"南北(north-south)"インターネットトラフィックの処理,および組織の信頼するバウンダリ内にないクライアントからのトラフィックには,AWS Elastic Load Balancingの使用が推奨されている。App Meshのエコシステム以外でも,DatawireのAmbassadorやSoloのGloo,Istio Gatewayなど,Envoyをベースとして入力サポートを提供する実装の開発が進められている。
AWSでは、"AWSベストプラクティス"に基づいたコントロールプレーンやAPIなどのサービスメッシュの構築を進めている、としている。現在App Meshでは、AWS認証システムによって適切に認証されるように、SigV4用に拡張したバージョン1.8.0のEnvoyビルドを提供している(この変更はEnvioyのアップストリームにもコントリビュートされる予定である)。具体的には、App Meshはプラグインが可能なように設計されていて、独自のEnvoyイメージやIstio Mixesも今後サポートされる予定である。将来的にはその他の計算サービスのサポートも追加可能な設計となっており、スケーラブルで堅牢、費用対効果と効率を高めるために、マルチテナントコントロールプレーンとして実装されている。
発表に対するコミュニティの反応はさまざまだ。VMwareのスタッフエンジニアでIstioのコントリビュータであるShriram Rajagopalan氏など一部の人々が、例の中のソース資料の一部がIstioプロジェクトの許可なく引用されていることを指摘し、すぐに対処された。その他、Christian Posta氏らは、App Meshは"オープンソースではない、AWSのやり方だ",と述べている。GA以降の機能は現在、"Opensource App Mesh Envoy Management Service (EMS)"という名称で、App Meshの使用例リポジトリに資料として置かれているが、オープンソースリリースという範囲での情報は含まれていない。
この業界では著名なKelsey Hightower氏など数人のTwitterユーザは、AWSが既存のIstioプロジェクトにコントリビュートしないことを疑問視しており、"確立した機能セットと明確なAPIを備えることで、Envoyをもっと簡単に始めることができるはずで、その上で独自の作業を行って、最小価値のプロダクトを提供してはどうなのか"、と述べている。AWSのプリンシパルオープンソーステクノロジストであるArun Gupta氏はこの分析を支持しており、"istioは#Kubernetesとあまりにも強く結びついている、我々が必要なのはコンテナだけでなく、#AWS全体のすべてのワークロードを対象としたスケーラビリティなのだ"、と述べている。Cloud Native Computing FoundationのCTO/COOであるChris Aniszczyk氏は、"Envoyは中立的な所有と管理の下にあるが、Istioはそうではないという微妙な点もある"と、興味深い指摘をしている。
Lyftの"配管工兼ロードバランサ"(ソフトウェアエンジニア)で、Envoy Proxyの作者であるMatt Klein氏は、App Meshのリリースに関して、興味深い肯定的な意見をいくつか、Twitterで公開している。Envoyプロジェクトのおもな目標に関しては、
[Envoyコミュニティは]機能が豊富で拡張性があり、(十分に型付けされ、バージョン管理されたAPIを使って)構成可能なデータプレーンという目標を掲げています。エンドユーザエクスペリエンスの押し付けではありません。
さらに氏は、Envoyが提供する"クラウドネイティブなデータプレーン"と、KubernetesやNomad、あるいはMesosといったスケジューラが、本質的に"新しいクラウドネイティブOS"を形作るという点も示唆し,これは"構築、革新、収益化"のベースとなるプラットフォームなのだ、と主張している。
[...] ベースとなるクラウドネイティブプラットフォームOSは、完全にオープンで、すべての主要なクラウドや[P/C/F]aaSプロバイダから提供されるものになるでしょう。現金やプロプライエタリなイノベーションはその上に,セキュリティや監視,監査,ワークフロー,UIなどのサービスとして展開されるものになると思います。
[...] そして,@EnvoyProxyを既定のクラウドネイティブデータプレーンとする主要なクラウドベンダやPaaSベンダなどが集結することで,フラグメンテーションを心配することなく,システム構築を行うことができるようになります。これはとても強力です。
Klein氏はさらに,AWS re:inventのリリース発表の一部として,HashiCorpとDatadogがApp Meshの統合に着手していることを発表していることを,より高い価値の提供を目指すベンダの動向に関する自身の主張の裏付けとしている。
AWS App Meshは現在,ノースバージニア,オハイオ,オレゴン,アイルランドの各AWSリージョンでパブリックプレビューとして提供されている。AWS App Mesh使用のための追加料金はなく,サービスコンテナと並行して実行するApp Meshプロキシが使用するAWSリソースに対してのみ課金される。
GAリリースは2019年内に予定されている。完全なGAロードマップとGA以降のロードマップは,AWS APP Mesh ExampleのGitHubレポジトリで公開されている。App Meshに関する詳細な情報は,Getting Startedのページにある。