本番環境対応のKubernetesで複雑さを軽減

NGINX | 2021年2月05日

編集者 – この記事は全10回シリーズの一部です：

一連のブログ記事をまとめた無料のeBookもダウンロードできます。『Kubernetesをテスト環境から本番環境へ』

2020年は、私たちの多くにとって決して忘れられない年となりました。学校や企業、公共サービスが突然閉鎖され、私たちは地域社会から切り離され、安全や経済的安定への不安に突如直面しました。これが2000年、あるいは2010年に起きていたらどうなっていたか、少し想像してみてください。何が違っていたでしょうか。それはテクノロジーです。医療、ストリーミング動画、リモートコラボレーションツールなど、今では当たり前となった高品質なデジタルサービスがなければ、パンデミック下での状況は大きく異なっていたでしょう。2020年のテクノロジーは、過去数十年と比べて何がそれほど違っていたのでしょうか。それはコンテナとマイクロサービスです。

マイクロサービスアーキテクチャは、一般にコンテナとKubernetesを活用し、デジタルエクスペリエンスの市場投入までの時間を短縮することで、ビジネスの成長とイノベーションを促進します。従来型アーキテクチャと併用する場合でも、単独で使用する場合でも、こうした最新のアプリケーション技術により、優れた拡張性と柔軟性、迅速なデプロイ、さらにはコスト削減も実現できます。

2020年以前には、ほとんどのお客さまがデジタルトランスフォーメーション戦略の一環として、すでにマイクロサービスの導入を開始していましたが、パンデミックによってアプリケーションのモダナイゼーションが大幅に加速しました。2020年の調査では、NGINXユーザーの回答者のうち、本番環境でマイクロサービスを使用している割合が2019年の40%から60%に増加し、コンテナの普及率は他のモダンアプリケーション技術の2倍を超えていることが明らかになりました。

Kubernetesがコンテナ化されたアプリの管理における事実上の標準であることは、Cloud Native Computing Foundation（CNCF）が2020年に実施した調査からも明らかです。この調査では、回答者の91%がKubernetesを使用しており、そのうち83%が本番環境で使用していることがわかりました。Kubernetesの導入に際し、多くの組織は大幅なアーキテクチャ変更を想定していますが、最新のアプリテクノロジーを大規模に運用することで組織に及ぶ影響は、予想外であることが少なくありません。Kubernetesを運用している場合、ビジネス上極めて重要な次の3つの障壁すべてに直面している可能性があります。

文化
アプリケーションチームがアジャイル開発やDevOpsなどの最新のアプローチを採用しても、通常は依然として「コンウェイの法則」が当てはまります。この法則は、「組織が設計するシステムは、その組織のコミュニケーション構造を反映したものになる」としています。つまり、分散アプリケーションは、リソースを共有しながらも独立して活動する分散型チームによって開発されます。この構造は、チームが迅速に活動するうえで理想的である一方、サイロ化も促します。その結果、コミュニケーション不足（それ自体がさらなる問題を引き起こします）、セキュリティ脆弱性、ツールの乱立、自動化手法の不統一、チーム間の衝突などが生じます。
複雑性
エンタープライズグレードのマイクロサービステクノロジーを実装するには、可視性、セキュリティ、トラフィック管理を実現する重要なコンポーネント群を組み合わせる必要があります。通常、チームはこのニーズを満たすために、インフラストラクチャプラットフォーム、クラウドネイティブサービス、オープンソースツールを使用します。これらの戦略にはそれぞれ適した用途がある一方、複雑性を増す可能性のある欠点もあります。また、同じ組織内の異なるチームが、同じ要件を満たすために別々の戦略を選択し、「運用上の負債」を生み出すケースも少なくありません。さらに、チームはある時点でプロセスやツールを選択すると、コンテナを使用する最新のマイクロサービス駆動型アプリケーションのデプロイと運用を取り巻く要件が変化しても、それらを使い続けます。CNCF Cloud Native Interactive Landscapeは、マイクロサービスベースのアプリケーションを支えるために必要なインフラストラクチャの複雑性をよく示しています。組織は多種多様なテクノロジーに習熟する必要があり、その結果、インフラストラクチャへのロックイン、シャドーIT、ツールの乱立、インフラストラクチャの保守担当者にとっての習得難易度の高さといった問題が生じます。
セキュリティ
セキュリティ要件は、クラウドネイティブアプリと従来型アプリで大きく異なります。Kubernetesでは、境界で囲い込むセキュリティなどの戦略が有効ではないためです。広大なエコシステムとコンテナ化されたアプリの分散性により、攻撃対象領域ははるかに拡大します。また、外部のSaaSアプリケーションに依存することで、従業員や外部の人物が悪意のあるコードを挿入したり、情報を外部に持ち出したりする機会も大幅に増えます。さらに、文化と複雑性の項目で説明した影響、特にツールの乱立は、モダンアプリのセキュリティとレジリエンスに直接影響します。エコシステム内で同じ問題を解決するために異なるツールを使用することは、非効率なだけではありません。各コンポーネントを適切に構成する方法を習得しなければならないSecOpsチームにとって、大きな課題となります。

解決策：本番環境向けKubernetes

組織が抱える多くの問題と同様に、Kubernetesの課題を克服するには、テクノロジーとプロセスを組み合わせる必要があります。この記事では、以降テクノロジーの側面に焦点を当てます。プロセスやその他のトピックについては、今後のブログ記事にご注目ください。

Kubernetesはオープンソース技術であるため、実装方法は数多くあります。標準のKubernetesを独自に構築する組織もありますが、多くの組織は、Amazon Elastic Kubernetes Service（EKS）、Google Kubernetes Engine（GKE）、Microsoft Azure Kubernetes Service（AKS）、Red Hat OpenShift Container Platform、Rancherなどのサービスが提供する柔軟性、規範性、サポートの組み合わせに価値を見いだしています。

Kubernetesプラットフォームを利用すると、容易に導入して稼働を開始できます。しかし、こうしたプラットフォームは、サービスの充実度よりも種類の多さを重視しています。そのため、必要なサービスを1か所ですべて利用できるとしても、大規模な本番環境で実際に運用するために必要な機能一式が提供される可能性は低いでしょう。特に、高度なネットワーキングとセキュリティには重点が置かれておらず、この点でKubernetesは多くのお客さまの期待に応えられていません。

Kubernetesを本番環境で運用できるレベルにするには、次の3つのコンポーネントをこの順序で追加する必要があります。

クラスターへのトラフィックの出入りを可能にする、スケーラブルなイングレス／エグレス層
これは、Ingress controllerによって実現します。Ingress controllerは、Kubernetesネットワークの複雑さを抽象化し、Kubernetesクラスター内のサービスとクラスター外のサービスを橋渡しする専用のロードバランサーです。このコンポーネントは、レジリエンスを高める機能（高度なヘルスチェックやPrometheusメトリクスなど）、迅速なスケーリングを可能にする機能（動的な再構成）、セルフサービスをサポートする機能（ロールベースアクセス制御［RBAC］）を備えることで、本番環境に対応できるようになります。
クラスター全体を脅威から保護する組み込みセキュリティ
クラスターの外部では「粗粒度」のセキュリティで十分な場合もありますが、内部では「細粒度」のセキュリティが必要です。クラスターの複雑さによっては、柔軟なWebアプリケーションファイアウォール（WAF）を、Ingressコントローラー、サービス単位のプロキシ、Pod単位のプロキシという3つの場所に導入する必要があります。この柔軟性により、課金処理などの機密性の高いアプリにはより厳格な制御を適用し、リスクが低い箇所では制御を緩和できます。
クラスター内のトラフィックを最適化する、スケーラブルなEast-Westトラフィック層
Kubernetesアプリケーションの複雑さと規模が基本的なツールで対応できる範囲を超えた場合、この3つ目のコンポーネントが必要になります。この段階では、サービスメッシュが必要です。これは、クラスター内のアプリケーションサービスに対して、よりきめ細かなトラフィック管理とセキュリティを提供するオーケストレーションツールです。通常、サービスメッシュは、コンテナ化されたアプリケーション間のアプリケーションルーティングの管理、自律的なサービス間相互TLS（mTLS）ポリシーの提供と適用、アプリケーションの可用性とセキュリティの可視化を担います。

これらのコンポーネントを選択する際は、可搬性と可視性を優先してください。プラットフォームに依存しないコンポーネントを採用すると、チームが習得して保護すべきツールが減り、ビジネスニーズに応じたワークロードの移行も容易になるため、複雑さを軽減し、セキュリティを向上できます。可視性と監視の重要性は、いくら強調してもしすぎることはありません。GrafanaやPrometheusなどの一般的なツールと統合することで、インフラストラクチャ全体を一元的に把握できる「シングルペインオブグラス」を実現し、お客さまが問題に気付く前にチームが検出できるようにします。また、本番環境レベルのKubernetesに必須とは限らないものの、最新のアプリ開発に欠かせない補完的なテクノロジーもあります。たとえば、従来型アプリをモダナイズする準備が整った組織にとって、最初のステップの1つは、APIゲートウェイを使用したマイクロサービスの構築です。

NGINXがどのように役立つか

F5のKubernetesソリューションはプラットフォームに依存せず、本番環境レベルのKubernetesを実現するために必要な3つのコンポーネントで構成されています。イングレス・エグレス層の「NGINX Ingress Controller」、WAFの「NGINX App Protect」、East-West層の「NGINX Service Mesh」です。

NGINX Ingress ControllerとともにNGINX App Protect WAFをデプロイし、NGINX Service Meshも配置したKubernetes環境のトポロジ図

これらのソリューションは、次の4つの主要領域を強化し、Kubernetesを頼れる存在にします。

自動化 – アプリをより迅速かつ安全に市場投入
NGINX Ingress Controllerのトラフィックルーティング機能とアプリオンボーディング機能を、NGINX Service MeshによるNGINX Plusサイドカーの自動デプロイと組み合わせて使用することで、アプリのデプロイ、スケーリング、セキュリティ確保、更新を行えます。
セキュリティ – 既存および新たな脅威からお客さまとビジネスを保護
NGINX App Protectをクラスター内の任意の場所に導入するとともに、NGINX Service MeshとNGINX Ingress Controllerを使用してサービス間のエンドツーエンド暗号化を管理、適用することで、潜在的な障害点を減らします。
パフォーマンス – お客さまやユーザーが期待するデジタル体験を提供
他のWAF、Ingressコントローラー、ロードバランサーを上回るパフォーマンスを備えたNGINXソリューションなら、パフォーマンスを損なうことなく、トラフィックの急増やセキュリティ脅威に容易に対処できます。
インサイト – ビジネスを進化させ、顧客へのサービスを向上
NGINX Ingress ControllerとNGINX Service Meshから、アプリのパフォーマンスと可用性に関する的確なインサイトを得られます。詳細なトレースにより、マイクロサービスアプリ全体でリクエストがどのように処理されるかを把握できます。

NGINXで本番環境に対応

NGINX Ingress Controllerは、30日間の無料トライアルとしてご利用いただけます。このトライアルには、コンテナ化されたアプリを保護するNGINX App Protectが含まれています。トライアルを最大限に活用するには、常時無料のNGINX Service Mesh（ダウンロードはf5.comから可能）を追加することを推奨します。現在は、お持ちのライセンスを任意のクラウドに持ち込むこと（BYOL）ができます。