サービスメッシュについては、何が議論されているか：KubeCon + CloudNativeCon 2018詳報（4）
KubeCon + CloudNativeCon 2018に関する連載の第3回は、IstioやEnvoyなど、サービスメッシュに関する話題をお届けする。
2018年12月中旬に開催されたKubeCon + CloudNativeCon 2018では、サービスメッシュに関する話題が活発に議論された。
サービスメッシュでは、サービス単位でプロキシを動かすことで、可視化、信頼性確保、セキュリティ、リリース管理などの機能を、アプリケーション／サービスとは切り離されたレイヤーとして提供する。
サービス単位で導入されるプロキシは「データプレーン」とも表現され、プロキシにポリシーを適用して制御するコントローラーは「コントロールプレーン」とも呼ばれる。代表的なオープンソース（OSS）のデータプレーンはEnvoyで、コントロールプレーンではIstioなどがある。データプレーンとコントロールプレーンの双方を提供しているのがLinkerdやNGINX。Linkerdはデータプレーンに分類されることもあるが、同プロジェクトを推進しているBuoyantのCEO、ウィリアム・モーガン（William Morgan）氏は、「データプレーンとコントロールプレーンの双方を提供してきたことを、これまでうまく宣伝できていなかった」と今回のイベントで話した。
今回のイベントで、おそらく最も注目を集めていたのはやはりIstio。サーバレスで注目されるKnativeと密接に連携することもあり、「Kubernetes、Knative、Istioは新たなクラウドスタックなのか」といったテーマで複数のパネルディスカッションも実施されていた。
Istioプロジェクトの創始メンバーの一人であり、EnvoyにもコントリビューションをしてきたVMwareのスリラム・ラジャゴパラン（Shriram Rajagopalan）氏に、Istioが注目される理由を聞くと、「サービスメッシュのための唯一のコントロールプレーンだからだ」と答えた。「唯一」というのは言い過ぎだろう。Istioはデフォルトで後述のEnvoyをデータプレーンとして使うが、同様にEnvoyを採用するコントロールプレーンは複数存在するし、Envoyを使うユーザー組織でコントロールプレーンを自社開発しているところも複数ある。
Istioは、Linkerdのように単一のプロジェクトでデータプレーンとコントロールプレーンの双方をカバーするのではなく、コントロールプレーンに徹していることは事実で、Envoy以外のプロキシを制御することもできないわけではない。とはいえ、Envoyの注目度および利用の広がりに乗っかっている側面もありそうだ。
Istioの具体的な機能としては、「遅延などを含めたトラフィックの可視化」「HTTP、gRPC、WebSockets、TCPといったプロトコルの自動負荷分散」「ルーティング、リトライ、フェイルオーバーなどのきめ細かなトラフィック制御」「アクセス制御、レート制限、クオータなどのポリシー制御」「アイデンティティに基づく認証／認可およびmTLSの適用によるマイクロサービス間通信のセキュリティ確保」などがある。
Istioは複雑という批判を受けることもあるが、KubernetesにおけるPodやノードよりも、「サービス」というコンセプトでの管理を指向しており、運用における抽象度を高められるメリットが指摘されている。
ますます存在感が高まるEnvoy
上述のEnvoyは、Istioとともに今回のイベントで大きな存在感を示していた。2017年9月、Cloud Native Computing Foundation（CNCF）に「インキュベーティングプロジェクト」として加入した同プロジェクトは、2018年11月には「卒業」を意味する「グラジュエ―テッドプロジェクト」となった。CNCFにおける「卒業」では利用の広がりが重要な判断要素の一つとなっているが、eBay、Netflix、Pinterest、Square、Twillio、Stripe、ヤフージャパン、クックパッドをはじめ、多数の企業がユーザーとして名を連ねている。2018年11月にはAmazon Web Services（AWS）が、Envoyをデータプレーンに用い、自社開発のコントロールプレーンと組み合わせた「AWS App Mesh」を発表した。
Envoy人気の理由につながっている特徴として、同ソフトウェアのアーキテクトであるLyftのエンジニア、マット・クライン（Matt Klein）氏は、「高速であること」「豊富なAPIを持ち、拡張しやすいこと」「商用版が存在せず、あらゆる機能をOSSにつぎ込めること」などを挙げている。
Envoyはさまざまな目的で使えるが、通信の可視化には特に力を入れてきたという。それはLyftがEnvoyを開発したいきさつに関係がある。クライン氏が今回のイベントで行った説明によると、次のようになる。
Lyftは現在でこそ完全にマイクロサービスベースだが、サービス開始当初はLAMPスタックによるモノリシックなシステム構成だった（同社は当初からAWS上にサービスを構築している）。その後ビジネスの拡大に伴い、モノリシックなシステムではHA Proxyやキューイングによりパフォーマンスの向上を図ると共に、モノリシックなシステムの横でマイクロサービスを動かすようになった。さらに内部通信にはロードバランサを導入するなど、構成が急速に複雑化した。ホップ数が多く、どこに問題が起こっているかを把握するのが難しくなったという。
クライン氏はマイクロサービスへの移行を進める企業から、当時のLyftにおける悩みに似たことを聞くことがよくあると話した。
「アジリティのためにマイクロサービスへの移行を図ったものの、その動きが止まるケース多い。開発者にとってマイクロサービスは複雑すぎて、『問題をデバッグするのが難しい』『どこで遅延が起こっているかが分かりにくい』といった不満が出てくるからだ。そのため最悪の場合、マイクロサービスは誰からも信頼を得られず、開発者はモノリシックなアプリケーションの方にコードを追加し続けることになる」（クライン氏）
多様なプロトコルやロードバランサ―を使うアプリケーション／マイクロサービスを対象として一貫したログ／トレーシングを得ることが難しい。このため、システムで何が起きているのかを把握するのは至難の業だ。こうした課題の解決を目的として、同社はEnvoyを開発したという。
セキュリティへの適用とIstio
一方、セキュリティの観点から、サービスメッシュに注目するユーザーが増えているようだ。サービスメッシュとセキュリティに関するパネルディスカッションでは、次のようなコメントがあった。
マイクロサービス化で、セキュリティ上の攻撃対象となるポイントが増えてくる。そこで、「ゼロトラスト」（各エンドポイントが当初は「誰も信じない」状態から始め、必要な通信相手と通信内容だけをホワイトリスト的に許容する）の考え方に基づくきめ細かなセキュリティを構築する必要性が生まれる。
サービス間通信はレイヤー3／4では十分に制御できず、レイヤー7で識別し、ポリシーを適用する必要がある。また、API利用の認可のためのシークレット情報をコードに埋め込む作業は、アプリケーション開発者にとって大きな負担になってくる。プロキシで認可機能を肩代わりすることにより、開発者に頼らずにセキュリティを強化できる。
このパネルディスカッションの中で、前出のIstioプロジェクトの創始メンバーであるラジャゴパラン氏は、混在環境への対応の重要性を指摘した。
ラジャゴパラン氏によると、短期間でマイクロサービスに完全移行する組織は少ない。移行は段階的に進むことが多く、長期にわたり既存システムが残り続けることも十分考えられる。従って、「マイクロサービス化＝Kubernetes上のコンテナ環境への移行」であったとしても、サービスメッシュの機能はKubernetes環境に閉じたものであってはならない。IstioがKubernetesに加え、Cloud Foundry Application Runtimeやサーバ仮想化環境に対応しているのはそのためだと話した。
関連して、Istioプロジェクトで現在強化しようとしている機能の一つは、データアクセス管理だという。
「例えばサービスメッシュを構成するサービスのそれぞれが、同じデータセンター内のOracleデータベースにアクセスしているかもしれないし、Salesforceのデータにアクセスしているかもしれない。徐々に重要なデータがクラウドやSaaSに移行すると、情報漏えい防止はますます困難な作業になってくる。サービスメッシュでは重要なデータがどこにあるか、何がどのデータにアクセスしているかを可視化できるため、データアクセスセキュリティ確保のための重要な武器になる」（ラジャゴパラン氏）
もう一つの注力分野としてラジャゴパラン氏が指摘するのはフェデレーション。「Kubernetesクラスタを、パブリッククラウドの複数のアベイラビリティゾーン（AZ）やリージョンで動かしたり、オンプレミスとパブリッククラウドで動かしたりし、これら複数のクラスタを単一のサービスメッシュとして管理したいニーズは高まる。こうした利用形態への対応を進めていく」という。
IstioのCNCF加入について、ラジャゴパラン氏は「急いではいない」と話した。CNCFへの加入はIP（知的財産権）を移譲しなければならないなど、多くの法律的な手続きが発生する。現在はそれよりも、開発作業に専念したいというのがIstioプロジェクトの総意だという。
「CNCFに加入する主なメリットは、露出が得られることだ。Istioは今回のイベントでも多数のセッションが持たれているように、CNCFに入っていなくてもその存在は十分知られつつある」（ラジャゴパラン氏）
Linkerdは一から書き直したLinkerd 2.xを紹介
一方、CNCFのインキュベーティングプロジェクトであるサービスメッシュデータプレーン／コントロールプレーンのLinkerdは過渡期にある。同プロジェクトでは2018年9月、コードを一から書き直したLinkerd 2.0（以前、「Conduit」と呼ばれていた）をリリース。今回のイベントでは、Linkerd 2.1を発表した。Linkerd 2.xは、従来のLinkerd 1.xとは別物で、相互の連携は現在のところ考えていないという。
Linkerd 2.xはKubernetes環境にターゲットを絞って設計。Rust言語で書かれたデータプレーンは軽量で、メモリ消費量が少ないという。サービスメッシュではプロキシによる遅延が話題に上るが、Linkerd 2.xのデータプレーンは安定した低遅延が特徴としている。
なお、CNCFのCOO（最高執行責任者）であるクリス・アニズィック（Chris Aniszczyk）氏は、サービスメッシュに近い分野として、APIゲートウェイのOSSプロジェクトを同団体でホストすることを検討しているという。この分野では、例えばEnvoyを使うAmbassadorなどの興味深いプロジェクトがあるとしている。
Copyright © ITmedia, Inc. All Rights Reserved.