サービスメッシュの選び方

この記事は10部構成の一部です。

1. Reduce Complexity with Production-Grade Kubernetes（英語）
2. 高度なトラフィック管理でKubernetesの耐障害性を向上させる方法
3. Kubernetesの可視性を向上させる方法
4. トラフィック管理ツールを使ってKubernetesを安全にする6つの方法
5. Ingressコントローラーの選択ガイド, Part 1: 要件の特定
6. Ingress Controllerの選択ガイド, Part 2 : リスクと将来性
7. Ingress Controllerの選び方ガイド, Part 3：オープンソース / デフォルト / 商用版
8. Ingress Controllerの選択ガイド, Part 4 : NGINX Ingress Controllerのオプション
9. サービスメッシュの選び方（この記事です）
10. Performance Testing NGINX Ingress Controllers in a Dynamic Kubernetes Cloud Environment（英語）

これらのブログ一式を無料のebookとして下記よりダウンロードいただけます。– Kubernetes のテスト環境から本番環境への移行

近年、アプリケーションのマイクロサービス化やコンテナ化が進むのに伴い、サービスメッシュの導入も検討段階から本格採用へとステージが進みつつあります。2020年のCloudNative Computing Foundationの調査レポートでは、クラウドネイティブ技術に関する下記のような状況が報告されています。

Takeaway＃1：サービスメッシュの採用は急速に増加しています。

図： サービスメッシュの導入状況
回答者の27%が本番環境ですでにサービスメッシュを使用（2019年より18％増）
サービスメッシュの採用は1年で50％アップ

導入状況内訳： 27% が本番環境で利用中。23%が評価中。19％は来年中に評価を開始予定。
CloudNative Computing Foundation調査レポート（2020年）より

Takeaway ＃2：コンテナの導入が進むと同時に、より高度なトラフィック管理、より高度なセキュリティが必要となり、メッシュ技術の必要性が高まることを示しています。

図： コンテナ採用の増加により、より高度なトラフィック管理やセキュリティが必要とされ、メッシュ技術のニーズも増えている
92％（回答者）が本番環境でコンテナを採用または採用予定
23％が、本番環境で5000以上のコンテナを使用

Takeaway #3: コンテナに関連する課題のTop 3は、相互関係にあります。

図： コンテナ化における主な課題
コンテナ環境における主要な課題のトップ3はそれぞれが密接な相関関係にある
41％が一番の課題は“複雑さ”と回答、次に“セキュリティ”（32％）、3番目に “サービスメッシュ”（25％）

サービスメッシュの準備はできていますか？

もはやサービスメッシュに関する関心は、「必要かどうか？」という疑問の段階から、むしろ「いつサービスメッシュを導入すべきか」という段階に移行しつつあると考えています。コンテナを本番環境にデプロイし、Kubernetesを使用してコンテナをオーケストレーションしようとするあらゆるユーザにとって、サービスメッシュの付加価値により、アプリケーションとインフラをより完成度の高いレベルへと実現することができる可能性があると考えています。

ただし、他のテクノロジーと同様、必要性とタイミングによっては、リスクと費用がメリットを上回ってしまう可能性もあります。そのため、サービスメッシュを導入検討中の方には、ぜひ次の6つのチェックポイントを確認し、モダナイゼーションの過程についてよく理解を深めて準備していただきたいと思います。複数の項目が該当していれば、サービスメッシュにより、多くの付加価値が得られると考えます。

#1: ほぼすべての本番環境をKubernetesに移行している。
すでに本番環境のアプリケーションをKubernetesに移行している、または、コンテナ環境でのテストを始めたところ、など、長期的なアプリケーション管理のロードマップとしてKubernetesを組みこんでいる。

#2: ゼロトラストの本番環境が必要であり、サービス間の相互TLS（mTLS）が必要
本番用アプリケーションにはゼロトラストモデルが必須であり、コンテナ環境でも同レベルのセキュリティ維持が必要、または、サービスレベルのセキュリティ強化のための必要条件として移行が必要。

#3: アプリケーションの数とサービスレベルがどちらも非常に複雑
大規模な分散型アプリケーションを所有していて、かつ複数のAPIが連携し、その大半が外部との連携が必要

#4: すでに作られた本番環境用CI / CDパイプラインがある。
Git、Jenkins、Artifactory、Seleniumなどのツールを使用して、Kubernetes環境でアプリケーションを自動的にデプロイできる仕組みを持っている。

#5: 頻繁に（少なくとも1日に1回）、本番環境にデプロイする必要がある。
現状はここで、多くの方が「いいえ」と答えるかもしれませんが、それはまだ、Kubernetes環境を最大限活用しきれていないだけかもしれません。

#6: 最適なツールを用いて、モダナイズされた環境で迅速なアプリケーションデプロイを実現するDevOpsチームがいる。

サービスメッシュの所有はNetOpsチームがされる場合でも、実際の管理はクラスター内でDevOpsチームによって処理されることが多く、スタックへのメッシュの追加が必要とされている。

現状は、上記6つの項目にどれもあてはまらなかった、という方もいるかもしれません。ですが、サービスメッシュをもっとよく理解し、準備したいという方は、これ以降もぜひ参考にしてみてください。

アプリケーションに適したサービスメッシュを選択する方法

サービスメッシュが必要だと判断し導入を決めたら次に、今度は何を選ぶかが問題となります。Kubernetesが事実上コンテナオーケストレーションの標準となっているように、Istioが現在サービスメッシュの標準と考えられています。Istioは普及が進んでいるだけではなく、Kubernetesネットワーキングのあらゆる問題を解決することを目的として作られているため、唯一の選択肢に見えるかもしれませんが、さまざまなユースケースによって要件は異なり、Istioだけが選択肢とはいえません。Istioは優秀であるとともに、多くの複雑さを環境にもたらします。またそれを実行するためにエンジニアのチームの多くのリソースを必要とし、多くの時間を有することがあります。

お使いのアプリケーションにどのサービスメッシュが最適なのかを判断するためには、チームや関係者と下記ような点について、よく議論し検討することがよいと考えます。

Step 1: なぜサービスメッシュが必要か？
サービスメッシュで解決する必要がある問題は何か？たとえば、サービス間でmTLSが義務付けられている場合や、エンドツーエンドの暗号化が必要な場合があります。これには、エッジから入ってくるもの（ingressトラフィック）とメッシュ内部から（egressトラフィック）の両方が含まれるかもしれません。また、新しいKubernetesサービスにエンタープライズグレードのトラフィック管理の強力なツールが必要な場合もあるかもしれません。

Step 2: サービスメッシュをどのように使用しますか？
これはあなたの役割によって違うかもしれません。

• 開発者の場合：

  • Kubernetesに移行するレガシーアプリにセキュリティを追加する予定はありますか？
  • ネイティブのKubernetesアプリケーションにリファクタリングする際、セキュリティも導入しますか？

• プラットフォーム・インフラを担当している場合：

  • サービスメッシュをCI / CDパイプラインに追加して、新しいクラスターごとに自動的にデプロイおよび構成され、開発者が新しいインスタンスを起動したときに利用できるようにしますか？

Step 3: 導入の際、最も重要となる要件は何ですか？
インフラに依存しないサービスメッシュが必要ですか？
可視化ツールとの互換性は必要ですか？ Kubernetesネイティブであるか？
使いやすさは？
メッシュ内のサービス間トラフィック(East Westトラフィック）と同じツールで、エッジでの入力（ingress）および出力(egress)トラフィック（North Southトラフィック）も管理していきたいですか？

このような質問への回答を検討することで、オプションを評価するための要件が明確になり、選択に役立ちます。

NGINXが提供するソリューション

2020年に開発版としてリリースされていたNGINX Service Meshが、このたび公式版としてリリースされました。NGINX Service Meshは、開発者向けに最適化されたフリーソフトで、KubernetesでEast West（サービス間）トラフィックとNorth South（ingressとegress）の両方にmTLSとエンドツーエンド暗号化を実現する最も軽量でシンプルなソリューションです。煩雑にならないようシンプルで、かつ高度な柔軟性と優れたインサイトを提供できるようアプリケーションデータプレーンで動く、独自のサービスメッシュソリューションです。

次のような特長があります。

• 使いやすさ：Kubernetes環境の管理自体が煩雑なため、mTLSと高度なトラフィック管理を追加したいが、これ以上複雑にはしたくない。サービスメッシュをできるだけシンプルに導入・管理したい。
• 軽量：リソースを浪費したり、パフォーマンスに影響を与えたりしないコンポーネントが必要。
• 環境の依存がない：すべてのKubernetes環境で同じサービスメッシュを使用したい。
• エコシステムとの互換性：Ingressコントローラーおよび可視化ツールと統合可能で、遅延の少ないKubernetesネイティブのサービスメッシュが必要。

アーキテクチャについて

NGINXサービスメッシュには2つの主要なコンポーネントがあります。

コントロールプレーン

KubernetesのAPIサーバーと連携し、アプリケーションの動的なサポートと管理を実現する軽量のコントロールプレーンとなっています。アプリケーションがスケーリングおよびデプロイされるたびに同じく更新され、各ワークロードインスタンスは自動的に保護され、他のアプリケーションコンポーネントと統合されます。これにより、「設定したら忘れる」ことが可能になり、他のビジネスソリューションに貴重な時間を費やすことができるようになります。

データプレーン

NGINX Service Meshの一番優れた点は、完全に統合された高性能なデータプレーンです。 NGINX Plusを活用し、高可用性でスケーラブルなコンテナ環境を運用するNGINXのデータプレーンは、他のサイドカーでは提供できないレベルのエンタープライズトラフィック管理、パフォーマンス、およびスケーラビリティを実現します。本番環境グレードのサービスメッシュ展開に必要なシームレスで透過的なロードバランシング、リバースプロキシ、トラフィックルーティング、認証、および暗号化機能を提供します。NGINX PlusをベースとするNGINX Ingress Controller,との組み合わせにより、単一の構成で管理できる統合データプレーンが実現します。

NGINX Service Mesh の特長

NGINX Service Meshの優れた特長は以下の通りです。

非常にシンプル

NGINX Service Mesh は使いやすく、インフラなど環境に依存しません。Kubernetes上の標準インターフェースを定義するサービスメッシュインターフェース（SMI）仕様を実装し、本番用トラフィックに対する影響を最小限に、そして最小限の労力で新しいバージョンを実行できるようSMI拡張機能を提供します。NGINX Service Meshは、NGINX Ingress Controllerともネイティブに統合され、サービス間（East Westトラフィック）のリバースプロキシサイドカーとしてトラフィック管理を可能にするとともに、エッジでの入力および出力（North Southトラフィック）の設定を一元化および合理化できる統合データプレーンを作成します。他のメッシュ製品とは異なり、NGINX Service Meshは別途サイドカーをNGINX Ingress Controllerに追加する必要がないため、Kubernetes環境での余分なレイテンシや複雑さが増すこともありません。

レジリエンスの向上

コンテナ向けの優れたトラフィック管理機能により、新しくデプロイされたサービスインスタンスへのトラフィックを制限し、時間の経過とともに徐々に増加させるようポリシーを指定することができます。レート制限やサーキットブレーカーなどの機能により、サービスを流れるトラフィックを完璧に制御できます。レートシェーピング、サービス品質（QoS）、サービススロットリング、ブルーグリーンデプロイ、カナリアリリース、サーキットブレーカーパターン、A / Bテスト、APIゲートウェイ機能など、広範で、堅牢なトラフィック管理機能を活用することができます。

さらに詳細を知りたい方は、関連ブログ「高度なトラフィック管理でKubernetesの耐障害性を向上させる方法」もご参照ください。また、NGINX Service Meshを使ったトラフィック分割の方法についてもデモもご覧いただけます。

トラフィックのきめ細かい管理

NGINX Service Meshは、メトリクスの収集や分析のためOpenTracingやPrometheusと連携しています。NGINX Plus APIは、NGINX Service MeshサイドカーとNGINX Ingress Controllerポッドからメトリクスを生成します。組み込みのGrafanaダッシュボードを使用して、ミリ秒、日ごとのオーバーレイ、トラフィックの急増に至るまでの詳細を視覚化することができます。

さらなる詳細については、関連ブログ「Kubernetesの可視性を向上させる方法」をご覧ください。また、NGINXでPrometheusとGrafanaを使用する方法は、こちらのライブストリームをご覧ください。

コンテナ環境でのセキュアなアプリケーション構築

mTLS暗号化とレイヤー7保護を個々のマイクロサービスにまで拡張し、アクセス制御を活用して、アプリケーションのトポロジに関するポリシーを定義することができます。これにより、相互通信可能なサービスをきめ細かく制御できます。 NGINX Service Meshは、ゲートウェイとしての設定とガバナンス、および入力と出力、そしてサービス間トラフィックの許可リストのサポートを含む高度なセキュリティ機能を可能にします。 NGINX PlusのNGINX Ingress Controllerモジュールを使用し、内部サービスへのNorth Southトラフィックをデフォルトでブロックしたり、NGINX App Protectを使用したエッジファイアウォールも利用できます。

アクセス制御を用いてエンドツーエンドの暗号化によるゼロトラスト環境を管理する方法についてのデモは、こちらをご覧ください。

サービスメッシュの準備がまだできていない場合

Kubernetesをまだ使い始めたばかり、または大規模な本番環境へのデプロイに躊躇している場合など、まだサービスメッシュ導入の準備が整っていない方もいるかもしれません。そのような場合は、ぜひIngressコントローラーと組み込みのセキュリティモジュールを備えたこれからの2つのデータプレーンコンポーネントを試してみてください。一般的にKubernetesの課題とされる煩雑さやセキュリティ、可視性、スケーラビリティなどの問題を解決するチャンスです。さらなる詳細については、関連ブログ「Reduce Complexity with Production‑Grade Kubernetes」もご覧ください。

まずは始めてみましょう

サービスメッシュに関するウェビナーも実施しています。ぜひご覧ください。
サービスメッシュはなぜ必要？NGINX Service Mesh 技術解説セミナー

NGINX Service Meshはフリーのソフトウェアです。ダウンロードして10分ほどでデプロイできます。開始する前に、こちらのドキュメントを確認ください。またデモもご用意していますので、ご覧ください。ぜひ今後の参考のため、フィードバックをGitHubでお寄せください。

もし、お客様の環境にIstioが最適である場合は、F5のAspen Meshをご確認ください。こちらは、オープンソースのIstio上に構築されたエンタープライズグレードのサービスメッシュです。リアルタイムのトラフィックGUIを備えているため、5Gを提供しようとしているサービスプロバイダーなどに最適です。