ソフトウェアシステムを最新化する場合の大きな目標のひとつは、その動作の基礎になっているインフラストラクチャから、アプリケーションを切り離すことです。これには多くの利点があります。イノベーションの促進 — 例えば、ワークロードを移行して、クラウドMLや"ビッグデータ"サービスを利用する。リソースのより効率的な割り当てや、アプリケーションのコロケーションによるコスト削減。適切な抽象化を導入し、コンポーネントのより効率的なアップグレードとパッチ適用を行うことによるセキュリティの向上。コンテナや、Kubernetesのようなオーケストレーションフレームワークを使用すれば、基盤となるハードウェアから、アプリケーションのデプロイと実行を切り離すことが可能になります。ただし、すべてのアプリケーションがこの種のプラットフォームに移行できるわけではありません。あるいは、たとえ可能であっても、段階的なプロセスで実施したいと考えるのが当然です。このため、トラフィックルーティングをネットワーキングインフラストラクチャから切り離す、さらなる抽象化層が必要になります。このような抽象化は、エッジでは入力ゲートウェイまたはAPIゲートウェイを介して、データセンター内ではサービスメッシュを介して、それぞれ実現されます。
私たちDatawireは、過去数ヶ月間、HashiCorpチームの緊密な協力のもとで開発を続けてきました。そして先頃、Ambassador APIゲートウェイとConsulサービスメッシュ間のインテグレーションをリリースしました。これら2つのテクノロジを組み合わせることにより、アプリケーションのトラフィックルーティングを、基盤となるデプロイメントやネットワークインフラストラクチャから完全に切り離すことができます。Envoy Proxyの機能を利用することで、これら２つのテクノロジは、エッジからの動的ルーティングと、ベアメタル、VM、Kubernetesにまたがるサービス間サービスとを提供します。今回のインテグレーションによって、エンドツーエンドのTLSも可能になり、その他の部門横断的な要件のサポートもできるようになります。
アプリケーションの最新化: インフラストラクチャとアプリケーションの分離
多くの組織が、大規模なデジタル変革活動の一環として、"アプリケーションの最新化(modernisation)"プログラムに取り組んでいます。この目標は極めて大きなものですが、一般的には機能のモジュール化、クラウドMLやビッグデータサービスとの統合、セキュリティの向上、コストの削減、インフラストラクチャレベルでの可観測性(observability)および回復性(resilience)に関する機能の実現などを通じたイノベーション能力の向上に焦点が当てられています。アプリケーション最新化の取り組みは、多くの場合、マイクロサービスやファンクション・アズ・ア・サービス(FaaS)などの疎結合を目的とした、カーディナリティの高い現代的アーキテクチャパターンへの移行や、 作業に対する"DevOps"あるいは責任共有アプローチの適用などの活動を伴います。
アプリケーションの最新化における重要な技術的目標のひとつは、基盤となるインフラストラクチャからアプリケーション、サービス、機能を切り離すことです。これに関して、いくつかのアプローチが、クラウドベンダによって進められています。
- AWS Outpostsは、AWSによって完全に管理されているカスタムハードウェアのインストールを通じて、AWSのサービスと運用モデルを、ユーザの所有する既存のデータセンタに提供するものです。
- Azure Stackは、Azureクラウドとユーザ自身のオンプレミスハードウェアにわたるハイブリッドアプリケーションを、一貫して構築および実行できるようにする、Azureサービスの拡張機能です。
- Google Anthosは、ソフトウェアベースの抽象化層と、関連するコントロールプレーンを通じて、GCPのコアサービスをユーザのインフラストラクチャや他社クラウドに拡張できるようにします。
その他にもAmbassador、Consul、Istio、Linkerdといったプロジェクトが、既存のコンテナベースの抽象化層によってクラウドに依存しないデプロイメントを実現するとともに、アプリケーションとインフラストラクチャの分離を可能にするための、ネットワークを抽象化する層を提供しようとしています。Dockerはデプロイメントユニットとしてのコンテナ利用を一般的なものにしました、そしてGoogleは、アプリケーションの大半がコンテナの集合体としてデプロイされることを認識し、それをKubernetesの中で"Pod"と名付けたのです。ここでのコンテナは、ネットワークとファイルシステムの名前空間を共有しています。ロギングやメトリック収集を提供するユーティリティコンテナは、アプリケーションと組み合わせることが可能です。Pod内に展開されたビジネスファンクションは、名前とネットワークのエンドポイントを提供する"サービス"抽象化を経由して公開されます。この抽象化を使用することで、デプロイとリリースの分離が可能になるのです。複数バージョンのサービスをいつでもデプロイできると同時に、トラフィックをバックエンドのPodに（"シャドウイング"トラフィック、"カナリアリリース"というように）選択的にルーティングすることで、機能をテストしたり、あるいはリリースしたりすることができます。この動的ルーティングは通常、エッジ（"エッジプロキシ"または"APIゲートウェイ"）とサービス相互間（"サービスメッシュ"と総称されるサービス間プロキシ）の両方で、プロキシを介して実現されます。
多くの組織にとって、最大の課題のひとつは、エンドユーザや社内の開発チームおよび運用チームを混乱させることなく、このようなアプリケーションとインフラストラクチャの分離を実現することにあります。この問題はメインフレームやベアメタル、VM、コンテナ、COTS、サードパーティ製アプリケーション、SaaS、社内マイクロサービスなど、一般的な企業のIT分野におけるインフラストラクチャとアプリケーションの多様性に起因しています。 従って、Kubernetesやクラウドサービスのような新しいインフラストラクチャに向けて、レガシアプリケーションの漸進的な最新化と移行を可能にする、明確な道筋を確立することが大きな目標になります。
中断を伴わない最新化と移行: APIゲートウェイとサービスメッシュの役割
オープンソースのEnvoy Proxyは現在、インフラストラクチャの世界を席巻していますが、それには正当な理由があります。このプロキシは"クラウドネイティブ"およびレイヤ7（アプリケーション）プロトコルを中心とする時代に生まれました。そのため、最新インフラストラクチャと関連する開発者/オペレータのユースケースを極めて効率的かつ効果的に処理するのです。Lyft、eBay、Pinterest、Yelp、Grouponといったエンドユーザ企業が、すべての主要クラウドベンダとの組み合わせで、サービスディスカバリ、ルーティング、可観測性を実装するために、エッジでEnvoyを運用しています。重要なのは、彼らが多くの場合、旧世代のメインフレームやVMベースのアプリケーションと、より近代的なコンテナベースのサービスとを橋渡しする通信手段としてEnvoyを使用していることです。
データプレーン（ネットワークプロキシ実装自体）は非常に強力ですが、プロキシの設定および監視に使用されるコントロールプレーンには、急勾配の学習曲線が存在します。そこで、Envoyを使用する開発者エクスペリエンスを簡素化する目的で、新たなオープンソースプロジェクトが出現しました。DatawireのAmbassador APIゲートウェイはEnvoy上で動作するエッジプロキシで、入力ないし"南北"トラフィックの管理に使用することにより、Envoyの設定を簡素化するコントロールプレーンを提供します。HashiCorpのConsulサービスメッシュは、サービス間通信ないし"東西"トラフィック用のコントロールプレーンで、プラグイン可能なプロキシ構成のひとつとしてEnvoyをサポートしています。
これら2つのテクノロジを使用することの大きなメリットは、外部ユーザと内部ユーザ、両方との接続を保ったまま、アプリケーションの任意の場所での実行が可能になることです。
- API Gatewayは、アプリケーションの構成と場所を外部コンシューマから切り離します。アプリケーションがどこにデプロイされているかに関係なく、エンドユーザ、モバイルアプリ、サードパーティからの外部要求を動的にルーティングします。
- サービスメッシュは、ロケーションの透明性を提供することによって、アプリケーションを内部コンシューマから切り離します。アプリケーションがどこにデプロイされているかに関係なく、内部サービス間要求を動的にルーティングします。
AmbassadorとConsul: VM、コンテナ、その他へのルーティング
Consulの一般的なデプロイメントは、複数のConsulサーバ（高可用性を提供するため）と、各ノード上のConsulエージェントで構成されています。ここでConsulは、データセンタ全体の設定の"真実の源"として機能し、利用可能なサービスと設定、エンドポイントを追跡し、TLS暗号化のための秘密鍵を保存します。サービスディスカバリにConsulを使用することで、Ambassadorは、ベアメタル、VM、Kubernetesのいずれで実行しているかにかかわらず、ユーザ側のエンドポイントまたはRESTに似たAPIから、Jデータセンター内の任意のConsulサービスにルーティングできます。Consulはまた、Envoyプロキシを通じて、サービス間トラフィックを透過的にルーティングすることもできます(サービス"サイドカー"パターンを使用)。これにより、エンドツーエンドのトラフィックをTLSで完全に保護することができます 。
Ambassadorは、アプリケーションやサービスへの共通の入り口として機能し、ユーザ認証、レート制限、API管理、TLSの切断など、南北トラフィックの分野横断的な機能を提供します。Consulはサービスメッシュとして機能し、ロケーションの透明性を提供するためのサービス名定義に加え、ネットワークの"セグメント化"など、明確かつ分野横断的なセキュリティ問題を宣言的に指定するポリシ・アズ・ア・コードを実現しています。ファイアウォールルールやIPテーブルを使用したサービス間通信のセキュリティでは、動的な設定によるスケールアップに対応できないため、ネットワーク固有のプロパティに依存せず、IDを通じてサービスを保護するサービスのセグメント化が、 新たなアプローチとなります。サービス名を使用したアクセスポリシの定義により、複雑なホストベースセキュリティグループやネットワークアクセスリストは回避されています。
導入方法
Ambassadorでは、Kubernetesアノテーションに基づいて構築された宣言型設定フォーマットを使用します。サービスディスカバリにConsulを使うためには、最初に、Kubernetesサービス内のアノテーションを通して、Consulをリゾルバとして登録します。
apiVersion: ambassador/v1
kind: ConsulResolver
name: consul
address: consul-server
datacenter: dc3
Ambassadorでは、標準のアノテーションベースの設定フォーマットを使用した、任意のサービスへのルーティングの設定が可能になりました。gRPC、タイムアウト、設定可能なロードバランシングなど、Ambassadorのすべての機能が完全にサポートされています。以下の例は、 /foo/と、Consulに登録されているfooサービス("foo-proxy")のマッピングを示しています。
apiVersion: ambassador/v1
kind: Mapping
prefix: /foo/
service: foo-proxy
timeout_ms: 5000
resolver: consul-server
tls: consul-tls-cert
load_balancer:
policy: round_robin
オプションのtlsプロパティでは、AmbassadorがConsulサービスのプロキシと通信するために使用するTLSコンテキストを定義することができます。AmbassadorはConsul API経由で、TLS証明書を自動的に同期します。すべてのトラフィックが安全であることを保証するためには、ローカルネットワークアドレスにバインドするようにKuberntesPod内のサービスを設定する、あるいは、プロキシがリスンしているポートを経由したインバウンド通信のみを受け入れるように基盤となるVMを設定するなどの方法で、サービスそのものを、Consulサービスプロキシからのトラフィックのみ受信するように設定する必要があります。
データセンタ全体へのAmbassadorとConsulのロールアウトには、他にもいくつかのメリットがあります。Envoyなどレイヤ7対応プロキシをエッジで使用することにより、 最新のプロトコルであるHTTP/2やgRPCなどの適切なロードバランスが可能になります。(レイヤ4ロードバランサを使用しない理由について詳しく議論するのは、このユースケースでは適切ではありません。詳細については、"We rolled out Envoy as Geckoboard"という優れた記事を参照してください。)Consulはさらに、エントリの監視、分散ロック、ヘルスチェックなどを含むキーバリューストアや、初期状態での複数データセンタサポートといった、分散システム構築時に有用な追加プリミティブも提供します。
関連技術
IBM、Googleなど、いくつかの組織や個人が、サービス間通信を中心に、Envoyにための簡略化されたコントロールプレーン提供を目的としたIstioプロジェクトを設立しました。このプロジェクトには後に、進捗管理のための"ゲートウェイ"の概念が追加されています。現在Istioは、Kubernetesへのデプロイメントのみをサポートしていますが、その他のプラットフォームのサポートもロードマップ上にあります。BuoyantはLinkerdサービスメッシュを開発しました。東西トラフィックの管理が主な対象ですが、一般的な南北プロキシとのインテグレーションも提供しています。Kong APIゲートウェイチームも、NGINXを使用した初期段階のサービスメッシュソリューションを開発中です。
サービスメッシュの"ビッグバン"型ロールアウトに注意せよ
私はDatawireでの仕事を通じて、組織全体でサービスメッシュの展開に取り組んでいるいくつかの組織と話をしました。クラウド導入やソフトウェア定義型ネットワーク(SDN)が採用されても、比較的集中されたまま残っているネットワーク運用が、ソフトウェアデリバリにおける最後の要点のひとつであることには、疑問の余地がありません。これは時として、あらゆるネットワーク技術は集中管理されるべきである、という考えにつながります。一般論として、サービスメッシュをデプロイする場合には、この種のアプローチはうまくいきません。大企業内のすべてのエンジニアが、すべてのアプリケーションをまとめてメッシュに移行する作業をオーケストレーションするというのは、合理的ではないのです。段階的な導入アプローチの方が、より現実的ですし、エッジではそうあるべきだと思います。外部公開しているアプリケーションや製品の構成とリリースを分散化できれば、さらには最新のプロキシが提供する機能を活用する方法を学ぶことができれば、内部サービスのサービスメッシュを段階的に展開する上で、理想的な出発点になります。
サービスメッシュのロールアウトにおける最初のイテレーションでは、ルーティングに注目するのが一般的です。前項のAmbassadorとConsulの設定で説明したように、最新のエッジプロキシを設定したのならば、どこに、あるいはどのように、デプロイされているかに関わらず、トラフィックルーティングの既存Consul登録サービスへの選択的な移行が可能になります。ルーティングが完了すれば、個々のサービスに対してConsulプロキシを段階的に追加して、エッジから各サービスエンドポイントに、トラフィックを（TLSを使用して）安全にルーティングできます。TLSを実装したサービスと、データセンター内のプレーンテキストを混在させても、まったく問題ありません。目標は通常、すべてのトラフィックを保護することであり、AmbassadorとConsulの組み合わせを使用することで、エンドユーザからサービスへのトラフィックの、エンドツーエンドの暗号化を段階的に展開することが可能になります。
まとめ
今回の記事では、アプリケーション最新化プログラムの一環として、アプリケーションをインフラストラクチャから切り離すことの意義について論じてきました。これらのアプリケーションがどこにデプロイされているかに関わらず、APIゲートウェイとサービスメッシュを統合してデプロイすることにより、エンドユーザからのトラフィックを新規および既存サービスの両方にルーティングするようなインクリメンタルなパスを提供できる、という方法について解説しました。アプリケーションが新プラットフォームに移行した場合でも、エッジからサービス、あるいはサービス間でのトラフィックのルーティングに使用するIDは変わりません。さらに、今回のゲートウェイからメッシュへというソリューションを実装することには、エンドツーエンドのトラフィックの暗号化、アプリケーションレベルのネットワーキングメトリクスに対する可観測性の向上など、グローバルおよびサービス間を問わず、他にもいくつかのメリットがあります。
AmbassadorとConsulの統合に関する詳細は、Ambassadorのドキュメントに、チュートリアルはConsulのドキュメントにあります。
著者について
Daniel Bryantは 、Datawireの独立系技術コンサルタントおよびプロダクトアーキテクトとして活動しています。氏の技術的専門知識は、「DevOps」ツーリング、クラウド/コンテナープラットフォーム、マイクロサービス実装を中心としたものです。さらに氏は、Javaチャンピオンであり、いくつかのオープンソースプロジェクトにもコントリビュートすると同時に、InfoQ、O'Reilly、TheNewStackでの記事の執筆や、OSCON、QCon、JavaOneなどの国際会議での講演を常に行っています。氏は恵まれた自由時間の中で、走り、読書し、また旅を楽しんでいます。