Ingress Controller選定ガイド 第2回：リスクと将来を見据えた対策

Jenn GileNGINX製品マーケティング責任者

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

1. 本番環境対応のKubernetesで複雑さを軽減
2. 高度なトラフィック管理でKubernetesのレジリエンスを向上させる方法
3. Kubernetesの可視性を向上させる方法
4. トラフィック管理ツールを使用してKubernetesを保護する6つの方法
5. Ingress Controller選定ガイド 第1回：要件の明確化
6. Ingress Controller選定ガイド 第2部：リスクと将来への備え（本記事）
7. Ingress Controller選定ガイド第3部：オープンソース、デフォルト、商用の比較
8. Ingress Controller選定ガイド、第4回：NGINX Ingress Controllerの選択肢
9. サービスメッシュの選び方
10. 動的なKubernetesクラウド環境におけるNGINX Ingress Controllerのパフォーマンステスト

一連のブログ記事をまとめた無料のeBookもダウンロードできます。『Taking Kubernetes from Test to Production』

「Ingressコントローラーの選び方」ガイドのパート1では、要件を特定する方法について説明しました。しかし、製品をテストする段階にはまだ至っていません。この記事では、不適切なIngressコントローラーを選ぶと、リリース速度が低下し、顧客を失う可能性さえあることを説明します。ほかのツールと同様に、Ingressコントローラーにもリスクが伴い、将来のスケーラビリティに影響を及ぼす可能性があります。メリットよりもデメリットが大きくなりかねない選択肢を除外する方法を見ていきましょう。

Ingress Controllerのリスク

Kubernetes向けのトラフィック管理ツールを導入する際には、複雑性、レイテンシ、セキュリティという3つの具体的なリスクを考慮する必要があります。これらの問題は相互に関連していることが多く、1つが生じると、ほかの問題も発生する可能性があります。いずれもIngressコントローラーによって生じる可能性があるため、リスクを許容できるかどうかは組織で判断する必要があります。今日の消費者は移り気であり、魅力的な機能がそろっていても、デジタル体験を損なう要因があれば受け入れられない可能性があります。

複雑さによってマイクロサービスアーキテクチャの目的が損なわれるのか？

優れたKubernetesツールとは、軽量でシンプルな設計というマイクロサービスアーキテクチャの目標に沿ったものです。こうした原則を守りながら、非常に多機能なIngressコントローラーを開発することは可能ですが、必ずしも一般的とは限りません。設計者によっては、機能を盛り込みすぎたり、基盤となるエンジンに本来備わっていない機能を追加するために複雑なスクリプトを使用したりするため、Ingressコントローラーが不必要に複雑になることがあります。

では、なぜそれが重要なのでしょうか。Kubernetesでは、ツールが過度に複雑だと、アプリケーションのパフォーマンスに悪影響を及ぼし、デプロイメントを水平方向にスケールする能力が制限される可能性があります。一般に、過度に複雑なIngressコントローラーはサイズで見分けられます。フットプリントが大きいほど、ツールは複雑です。

レイテンシー：Ingress Controllerがアプリの速度を低下させていませんか？

Ingress Controllerでは、リソース使用量、エラー、タイムアウトが原因でレイテンシが増加する可能性があります。静的デプロイと動的デプロイの両方で追加されるレイテンシを確認し、社内要件に照らして許容できないレイテンシが生じる選択肢を除外してください。再構成がアプリの速度に与える影響について詳しくは、F5のブログ記事「動的なKubernetesクラウド環境におけるNGINX Ingress Controllerのパフォーマンステスト」をご覧ください。

セキュリティ：Ingress Controllerはハッカーの侵入を許すのか？

現在のインターネットでは、共通脆弱性識別子（CVE）に該当する脆弱性が蔓延しており、IngressコントローラーのプロバイダーがCVEパッチを提供するまでの時間が、セキュリティを維持できるか侵害を受けるかの分かれ目となる可能性があります。組織のリスク許容度に応じて、パッチの提供に数日以上（長くても数週間）かかるソリューションは候補から除外することを検討してください。

CVE以外にも、一部のIngressコントローラーには別の潜在的な脆弱性があります。次のような状況を考えてみましょう。オンライン小売企業に勤務しており、オープンソースのIngressコントローラーの設定に関するトラブルシューティングで支援が必要になったとします。商用サポートを利用できないため、Stack Overflowのようなフォーラムに問題を投稿します。すると、ある人物が支援を申し出て、Ingressコントローラーやその他のKubernetesコンポーネントの設定ファイルとログファイルを調べたいと言ってきます。問題を早急に解決しなければならないというプレッシャーから、ファイルを共有してしまいます。

「親切な協力者」のおかげで問題は解決します。しかし、その6か月後に侵害が発覚し、顧客記録からクレジットカード番号が盗まれていたことが判明します。共有したファイルに、アプリへの侵入に悪用された情報が含まれていたのです。このシナリオは、組織が有償サポートを選ぶ主な理由の1つを示しています。それは、機密性が保証されることです。

OpenRestyベースのIngress Controllerに関する注意事項

OpenRestyは、NGINX Open Sourceを基盤とし、LuaJIT、Luaスクリプト、サードパーティ製NGINXモジュールを組み込むことで、NGINX Open Sourceの機能を拡張したWebプラットフォームです。また、OpenRestyを基盤とするIngressコントローラーも複数あります。これらには、NGINX Open SourceおよびNGINX Plusを基盤とするF5のIngressコントローラーと比較して、2つのリスクが加わる可能性があると考えています。

• タイムアウト – 前述のとおり、OpenRestyはLuaスクリプトを使用して、商用のNGINX PlusベースのIngress Controllerに搭載されているような高度な機能を実装します。その1つが動的再構成です。これにより、可用性を低下させるNGINX Open Sourceの要件、すなわちサービスエンドポイントの変更時にNGINX構成を再読み込みする必要がなくなります。OpenRestyで動的再構成を実現するため、Luaハンドラーがリクエストのルーティング先となるアップストリームサービスを選択し、NGINX構成を再読み込みする必要をなくします。ただし、Luaはバックエンドの変更を継続的に確認する必要があり、リソースを消費します。その結果、受信リクエストの処理に時間がかかり、一部のリクエストが滞留して、タイムアウトの可能性が高まります。ユーザーやサービスが増えるにつれて、1秒あたりの受信リクエスト数とLuaが処理できるリクエスト数の差は指数関数的に拡大します。その結果、レイテンシーと複雑さが増し、コストも上昇します。Luaによってどの程度のレイテンシーが生じる可能性があるかについては、「動的なKubernetesクラウド環境におけるNGINX Ingress Controllerのパフォーマンステスト」をご覧ください。
• CVEパッチ適用の遅延 – NGINXのIngress Controllerと比較すると、NGINX Open SourceをベースとするOpenRestyなどのツールを基盤としたIngress Controllerでは、CVEのパッチが提供されるまでに必然的に時間がかかります。詳しくは、NGINX Plusでセキュリティ脆弱性に迅速かつ容易に対処で説明しているとおり、NGINXのCVEが発見された場合、ベンダーであるF5には通常、CVEが一般公開される前に通知されます。そのため、CVEの発表と同時にNGINX Open SourceおよびNGINX Plus向けのパッチをリリースできます。NGINX Open SourceをベースとするテクノロジーがCVEを把握するのは、その時点以降になる可能性があります。また、F5の経験では、OpenRestyのパッチ提供はF5よりも大幅に遅れます。たとえば最近の事例では、4か月遅れました。OpenRestyをベースとするIngress Controller向けのパッチには、必然的にさらに時間がかかるため、悪意のある攻撃者が脆弱性を悪用する機会が十分に生じます。

将来を見据えたIngress Controller

Kubernetesを使い始めたばかりでも、いずれは本番環境に導入したいと考えている方は多いでしょう。時間の経過とともにニーズが拡大すると考えられる主な領域は、インフラストラクチャ、セキュリティ、サポート、マルチテナンシーの4つです。

インフラストラクチャ：ハイブリッドクラウドまたはマルチクラウド環境でKubernetesを使用しますか？

組織が1種類の環境だけを全面的かつ永続的に利用するケースはまれです。一般的には、オンプレミスとクラウドを組み合わせて利用しており、プライベートクラウド、パブリッククラウド、ハイブリッドクラウド、マルチクラウドなどが含まれます。（これらの環境の違いについて詳しくは、「マルチクラウドとハイブリッドクラウドの違いとは？」をご覧ください。）

本シリーズのパート1で述べたように、各環境にデフォルトで付属するツールを選びたくなるものですが、デフォルトのIngressコントローラーには固有の問題が数多くあります。デメリットについては本シリーズのパート3ですべて取り上げますが、将来性の確保に最も関係する問題はベンダーロックインです。クラウド固有のIngressコントローラーは、すべての環境で共通して使用できません。デフォルトのクラウド固有ツールを使用すると、魅力に欠ける次の2つの選択肢しか残されないため、拡張性に影響します。

1. 既存のクラウドですべてのニーズに対応しようとする
2. 新しい環境ごとに、負荷分散だけでなくセキュリティも含め、Ingressコントローラー向けにすべての設定を書き直す

1つ目の選択肢はビジネス上の理由から実行できないことが多く、2つ目も、ツールの乱立や新たなセキュリティ脆弱性を招き、従業員に多くの学習を求めるため、容易ではありません。3つ目の最も効率的な選択肢は、最初からインフラストラクチャに依存しないIngressコントローラーを選び、すべての環境で同じツールを使用できるようにすることです。

インフラストラクチャについては、もう1つ考慮すべき要素があります。それは認定です。Red Hat OpenShift Container Platform（OCP）を例に見てみましょう。OCPを利用している場合、Red Hat MarketplaceでOCP向けの認定Operatorが提供されており、その中にNGINX Ingress Operatorが含まれていることは、すでにご存じかもしれません。Red Hatの認定基準により、そのツールがお使いのデプロイ環境で動作することを確認でき、Red Hatとベンダーによる共同サポートが含まれる場合もあるため、安心して利用できます。多くの組織では、セキュリティと安定性の観点から認定ツールの使用が要件となっています。そのため、現時点ではテスト段階であっても、本番環境に関する自社の要件を念頭に置いておくことが重要です。

セキュリティ：Kubernetesを内部から保護するには？

境界セキュリティだけでアプリケーションと顧客を保護できた時代は終わりました。Kubernetesアプリケーションを効果的に保護するには、認証や認可を含むセキュリティをアプリケーションの近くに配置することが重要です。また、エンドツーエンド暗号化を必須とし、Kubernetes内でゼロトラストネットワークモデルを採用する組織が増える中、サービスメッシュの導入を検討することになるかもしれません。

これらはIngressコントローラーとどのような関係があるのでしょうか。実は大いに関係があります。Ingressのポイントにセキュリティ（認証、認可、DoS対策、Webアプリケーションファイアウォール）を集約することは、コストと効率の両面で非常に合理的です。ほとんどのサービスメッシュは、ほとんどのIngressコントローラーと統合できますが、その統合方法が非常に重要です。セキュリティ戦略に合ったIngressコントローラーを選ぶことで、アプリケーション開発の全工程にわたる大きな問題を回避できます。

クラウドネイティブアプリのデリバリーに伴うリスクについて詳しくは「スピードを犠牲にせずクラウドネイティブアプリを保護する」を、セキュリティツールの最適な配置場所を決める要因について詳しくは「Kubernetesでのアプリケーションサービスのデプロイ：第2部」をご覧ください。

サポート — どこまで「自力」で対応できますか？

チームがKubernetesを試しているだけの段階では、コミュニティと企業のどちらから提供されるかを問わず、サポートの優先度はそれほど高くないことが一般的です。独自の解決策や回避策を考案する時間が十分にあれば問題ありませんが、本番環境へ移行すると、この方法を続けることは困難です。現時点でサポートが不要でも、将来サポートを追加できるIngressコントローラー、または規模の拡大に応じてアップグレードできる低価格のサポートプランが用意されたIngressコントローラーを選ぶのが賢明です。

マルチテナンシー：複数のチームとアプリがコンテナ環境を安全かつセキュアに共有するには

はじめは、1つのチームと1つのアプリだけでした……どんな物語も、そんなふうに始まるのではないでしょうか。そのチームが1つのKubernetesアプリの開発に成功すると、組織はKubernetes上でより多くのサービスを運用するようになります。そして当然、サービスが増えれば、チームも増え、複雑さも増していきます。

効率を最大限に高めるため、組織はマルチテナンシーを採用し、ビジネスプロセスで求められるアクセスと分離をサポートすると同時に、運用担当者に必要な管理のしやすさと制御機能を提供するKubernetesモデルを導入します。一部のIngressコントローラーでは、複数のIngress、クラス、名前空間、ロールベースのアクセス制御（RBAC）の設定をサポートするスコープ付きリソースなど、さまざまな機能や概念を使用してクラスターを分割できます。

次のステップ：選択肢を絞り込む

要件、リスク許容度、将来性について検討したことで、多種多様なIngressコントローラーから候補を絞り込むために必要な情報がそろいました。カテゴリー別に整理すれば、このステップを効率よく進められます。本シリーズの第3回では、Ingressコントローラーを3つのカテゴリーに分け、それぞれの長所と短所を解説します。

著者について

Jenn GileNGINX製品マーケティング責任者

Jenn Gileのその他のブログ記事