「サービスメッシュ」が今注目を集めています。昨年開催されたコンテナ関連の主要なカンファレンスのすべてで「サービスメッシュ」がテーマとして取り上げられていたり、業界のインフルエンサー達は同技術の画期的なメリットについて様々な場面で語っています。
しかし、2019年初めの現時点において、サービスメッシュはいまだ未成熟な技術です。有力な実装サービスであるIstioは、一般的な企業導入にはまだ対応しておらず、プロダクション導入に成功した一握りの環境が稼働しているにすぎません。サービスメッシュの実装は他にも存在しますが、業界識者の言説に反して、大きな共感は得られていません。
このような認識のずれをどうすればなくすことができるのでしょう? 「サービスメッシュが必要だ」という声が聞かれる一方で、組織は長年にわたって、同技術を使うことなくコンテナプラットフォーム上でアプリケーションを問題なく実行し続けています。
Kubernetesを使い始めるには
サービスメッシュは一つのマイルストーンであり、出発点ではない
Kubernetes は、コンテナアプリケーションの本番導入において優れた実績を持つ高性能なプラットフォームです。複雑な分散アプリケーションに対応するために、サービスディスカバリ、ロードバランシング、ヘルスチェック、アクセス制御を集約した多機能なネットワーキングレイヤーを提供します。
これらの機能は、シンプルなアプリケーションや、理解が進み、コンテナ化されているレガシーアプリケーションにとっては十分すぎるものです。これらの機能によって、自信を持ってアプリケーションを導入し、必要に応じて拡張を行い、予期せぬ障害の経路をたどり、シンプルなアクセス制御を実行することできます。
Kubernetesは、APIにおいて入力リソースオブジェクトを提供します。このオブジェクトにより、選択したサービスにKubernetes クラスタの外部からアクセスする方法が定義され 、Ingress Controllerがこれらのポリシーを実行します。NGINXはほとんどの実装で選択されているロードバランサであり、F5はNGINX Open Source とNGINX Plusで、高性能で本番環境に対応可能なサポート機能を提供します。
vanilla KubernetesとIngress Controllerは、多くのプロダクションアプリケーションに対して必要なすべての機能を提供することから、さらに高度なものへと発展させる必要はありません。
より複雑なアプリケーションに向けた次なるステップ
セキュリティ、モニタリング、トラフィック管理を追加し、制御性と可視性を向上させる
オペレーションチームがプロダクション環境でアプリケーションを管理する際、より高度な制御と可視化が必要になる場合があります。高性能なアプリケーションでは複雑なネットワーク動作が見られる場合があり、本番環境での度重なる変更により、アプリケーションの安定性と一貫性に対するリスクが高まることが考えられます。共有Kubernetes クラスタ上で実行されている場合、コンポーネント間のトラフィックの暗号化が必要になるケースもあります。
理解の進んでいる手法を用いて、それぞれの要件を満たすことが可能です。
- サービス間のトラフィックを保護するには、SPIFFEもしくは同等の手法を用いて、各マイクロサービス上にmutual TLS（mTLS）を実装します。
- パフォーマンスと信頼性の問題を特定するには、それぞれのマイクロサービスで、Grafanaなどのツールを使った分析のためのPrometheus対応メトリックをエクスポートします。
- これらの問題をデバッグするには、各マイクロサービスにOpenTracingを組み込みます（複数の言語とフレームワークに対応）。
- 高度なロードバランシングポリシー、ブルーグリーン&カナリアデプロイメント、サーキットブレーカを実装するには、プロキシとロードバランサを導入できます。
これらの手法の一部では、各サービスに小さな変更を加える必要があります（証明書をコンテナに同梱する、PrometheusとOpenTracing用のモジュールを追加するなど）。NGINX Plusでは、サービスディスカバリとAPIドリブンな設定により変更をオーケストレートすることで、重要サービスのための専用ロードバランシングを提供することが可能です。NGINXマイクロサービスリファレンスアーキテクチャのルータメッシュパターンは、クラスタワイドのトラフィック制御ポイントを実装します。
現在プロダクションで実行されているコンテナ化されたアプリケーションのほぼ全て、制御と可視化のためにこのような手法が用いられています。
では、なぜサービスメッシュが必要なのか?
上述の手法が本番環境で実証済みであるのなら、サービスメッシュによって何が追加されるのでしょうか?
前のセクションで説明したそれぞれのステップに対応しようとした場合、アプリケーション開発者とオペレーションのチームに負荷がかかることになります。ソリューションの理解が十分に進んでいることから、ひとつひとつの負荷は軽微なものです。しかし、それが積み重なると、大規模で複雑なアプリケーションを実行している組織では最終的に臨界点に達し、サービスごとのアプリケーションの強化を拡張することが難しくなることも考えられます。
これこそが、サービスメッシュによる解消が約束されている中核の問題です。サービスメッシュの目的は、アプリケーションからは見えない、標準化された透過的な方法により、必要な能力を提供することにあります。
サービスメッシュはまだ新しい技術であり、プロダクション導入はほとんど行われていません。導入者ごとのニーズに特化した、複雑な独自ソリューションで早期の導入が進められている状況です。「サイドカープロキシ」パターンと呼ばれる、よりユニバーサルなアプローチが出現し始めています。このアプローチは、ひとつひとつのサービスインスタンスと共に、レイヤ7プロキシを導入するというものです。これらのプロキシはすべてのネットワークトラフィックをキャプチャして、mutual TLS、トレーシング、メトリック、トラフィックコントロールといった付加的な機能を一貫した方法で提供します。
サービスメッシュはごく新しい技術であり、ベンダやオープンソースプロジェクトは、機能的で安定性があり、操作しやすい実装の構築を急ピッチで進めています。2019年が「サービスメッシュの年」になることはほぼ間違いなく、汎用アプリケーションに対してサービスメッシュの一部の実装が完全にプロダクションレディとなる段階に達すると見られています。
今やるべきこととは?
2019年初めの現時点では、他のソリューションの限界にぶつからないかぎり、サービスメッシュの早期実装に踏み切るには時期尚早と思われ、短期的なソリューションが必要です。現在のサービスメッシュ実装の未成熟さと急速な変化により、導入に伴うコストとリスクが高まっています。技術の成熟と共に、今後はコストとリスクが低下し、サービスメッシュ導入の転換点が近づくことなると見込まれます。
しかし、安定性に優れ成熟したサービスメッシュがないからといって、現在検討している取り組みを先延ばしにすることがあってはなりません。これまで見てきたように、 Kubernetesをはじめとするオーケストレーションプラットフォームは豊富な機能を提供します。また、より洗練された機能が追加されることで、多くの人々が選び、広く理解されている道をたどることができます。Ingressルータや内部ロードバランサといった実証済みのソリューションを利用することで、このような道を進んでいただければと思います。サービスメッシュ実装を加えることを検討すべき転換点に到達したと気づく時が来るはずです。
