Ingress Controllerの選び方ガイド 第3回:オープンソース、デフォルト、商用の比較

NGINX | 2021年9月20日

編集者 – この記事は全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コントローラーの選定ガイドの最初の2部を読み終え、いよいよ選定まであと一歩です。ここまでの内容を振り返ってみましょう。

  • In パート1では、パフォーマンス、予算、ユースケース、アーキテクチャ、所有権などの要件を特定する方法について説明します。
  • In パート2では、不適切なIngressコントローラーを選択することで生じる可能性のあるリスクについて説明し、将来を見据えた選択を行うための主なポイントを紹介します。

Ingressコントローラーは、オープンソース、デフォルト、商用の3つのカテゴリーに分類されます。それぞれに適したユースケースがあるため、選定前に短期的および長期的なニーズを明確にすることが重要です。このブログでは、各カテゴリーのメリットとデメリットを解説します。

オープンソースのIngress Controller

多くのオープンソースIngressコントローラーは、ユーザーとボランティア開発者のコミュニティによって保守されていますが、専任のエンジニアリングチームを擁するものもあります。特に広く利用されているオープンソースIngressコントローラーのうち2つはNGINXをベースとしており、一方はKubernetesコミュニティが保守し、もう一方はNGINXの中核エンジニアリングチームが主導してオープンソース化しています。NGINXベースのIngressコントローラーの詳しい比較については、本シリーズのパート4をご覧ください。

  • 長所:
    • 無料でコミュニティ主導 – 多くの個人や組織がオープンソースプロジェクトを選ぶのは、圧倒的な価格(無料!)だけでなく、コミュニティによって開発されたテクノロジーを好むためでもあります。
    • 機能開発のスピード – これらのIngressコントローラーは、革新的な機能をいち早く取り入れる傾向があります。
  • 短所(一般的なオープンソースプロジェクトにも共通):
    • コスト(時間) – 簡単なセットアップやスケーラビリティに必要な「すぐに使える」ツールが不足しているため、個別のニーズに合わせたカスタマイズや回避策に時間を費やすことになります。
    • リスク – 機能開発のスピードが重視され、コントリビューターがボランティアであることから、安定性、セキュリティ、信頼性に問題が生じる可能性があります。共通脆弱性識別子(CVE)に対するパッチが提供されない場合や、CVEの公開から数か月後に提供される場合もあり、攻撃者にIngressコントローラーを攻撃する十分な時間を与えることになります。
    • サポートがほとんどない、またはまったくない – ほとんどの場合、「自己解決」が基本で、頼れるのは自分自身とドキュメントだけです。自力で解決できない問題が発生しても、支援を得るのは困難(または不可能)な場合があります。ほぼ唯一の選択肢は、コミュニティフォーラムに問題を投稿し、他のメンバーが(a)回答してくれて、(b)解決策を知っていることを期待することです。
  • 要約:組織がKubernetesを初めて試す際には、手軽さや、ドキュメントに無料ですぐに使い始められると記載されていることから、オープンソースのIngressコントローラーを選ぶことがよくあります。導入初期やテスト環境、トラフィック量の少ない本番環境では、非常にうまく機能する場合があります。

デフォルトのIngress Controller

多くのデフォルトIngressコントローラーはオープンソース技術をベースとしていますが、完全なKubernetesプラットフォーム(多くの場合、その管理サポートも含む)を提供する企業によって開発・保守されているため、別のカテゴリーに分類しています。このカテゴリーには、パブリッククラウドのIngressコントローラー、Rancher、Red Hat OpenShift routerなどが含まれます。

  • 長所:
    • 無料または低コスト – 低価格であることは、これらの製品を利用する大きな理由になります。すでにプラットフォームに統合されているため、導入時の時間を確実に節約できます。
    • 高い信頼性と充実したサポート – 専任のエンジニアリングチームが保守しているため、コミュニティが保守するIngressコントローラーよりも信頼性が高い可能性があります。通常、商用サポートが含まれているか、追加料金で利用できます。
  • デメリット:
    • インフラストラクチャへのロックイン – デフォルトのIngressコントローラーはインフラストラクチャに依存するため、コントローラーやその設定を別のクラウドへ移行できません。そのため、導入環境ごとに異なるIngressコントローラーが必要となり、ツールの乱立、チームの学習負担の増大、Ingressコントローラーのセキュリティ確保の複雑化につながります。
    • 基本的な機能 – 通常、大規模な導入に必要な高度なトラフィック管理機能やセキュリティ機能が不足しています。
    • 予測不能なコスト(時間と費用) – 初期コストはゼロまたは低額でも、アプリケーションの成長に伴い、予測不能な形で大幅に増加する可能性があります。たとえば、Ingressコントローラーの最小限の機能セットに含まれていない機能をアプリに組み込むための時間が必要になります。さらに、アプリを更新するたびに、その機能の回帰テストも必要です。一部のデフォルトツールには、当初はわずかに見えるスループット料金が原因で、アプリの普及に伴ってクラウド利用料が急増するという欠点もあります。
  • 要約:デフォルトのIngressコントローラーは、Kubernetesの利用経験が浅く、Amazon Elastic Kubernetes Service(EKS)、Google Kubernetes Engine(GKE)、Microsoft Azure Kubernetes Service(AKS)、Rancher、Red Hat OpenShift Container Platformなどのマネージドプラットフォームを使用しているチームによく選ばれています。アプリが成熟し、チームが成長するにつれて、デフォルトのツールを置き換えるのではなく、エンタープライズグレードのIngressコントローラーをスタックに追加する組織が多く見られます。

商用Ingressコントローラー

これらのIngressコントローラーは、大規模な本番環境への導入をサポートするよう設計されたライセンス製品です。その一例が、NGINX Plusをベースとするバージョンの「F5 NGINX Ingress Controller」です。詳しくはパート4で説明します。

  • 長所:
    • 豊富な機能セット – 商用Ingressコントローラーには、大規模なデプロイに必要な高度なトラフィック管理とスケーラビリティを支える堅牢な機能セットが備わっています。WAFやサービスメッシュなど、他の本番環境向け製品と統合できる場合もあります。
    • スケーラブル – これらの選択肢は、カスタマイズや回避策を必要としない「すぐに使える」機能が充実している傾向があるため、多くの組織で時間の節約につながります。自動化パイプラインにも容易に追加でき、必要に応じてインフラストラクチャを拡張できます。
    • 高い信頼性と充実したサポート – 商用製品の主なメリットの1つは、安定性に優れていることです。各リリースで広範なテストが実施され、必要に応じてソフトウェアアップデートやセキュリティパッチが定期的に提供されます。通常、包括的な商用サポートは複数のレベルで提供されるため、重大な問題が発生した場合、多くは数分から数時間以内に機密性を保った支援を受けられます。
  • デメリット:
    • 開発ペースが遅い – 商用Ingressコントローラーでは安定性が重視されるため、オープンソース製品と比べて機能追加のペースがやや遅れる可能性があります。
    • コスト(金銭) – 商用製品には費用がかかるのが現実です。資金よりも開発リソースに余裕がある組織にとっては、状況が変わるまで、コストが導入を断念する要因になり得ます。
  • まとめ:組織の規模が拡大するにつれて、チームやアプリの複雑さに応じて、Ingressコントローラーの選択がより重要になります。組織が高度に複雑化した段階では、商用Ingressコントローラーを採用することで、管理の複雑さを軽減し、新しい製品機能の市場投入までの時間を短縮できるため、合理的な選択肢となります。

次のステップ:選択肢を評価する

この段階では、要件を満たさない選択肢を除外し、試用するIngressコントローラーをいくつかに絞り込めます。機能の概要を比較する際は、まずlearnk8sを確認することをおすすめします。learnk8sでは、評価済みのIngressコントローラーをまとめた無料の比較表を提供しています。

Ingressコントローラーについて調査を進めると、多くの選択肢がNGINXをベースとしていることに気付くでしょう。NGINXベースの選択肢の概要については、本シリーズの最終回となる近日公開予定のブログ記事「Ingressコントローラー選定ガイド 第4回:NGINX Ingress Controllerの選択肢」をご覧ください。


共有

著者について

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

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

関連するブログ記事

チュートリアル:NGINXを使用してアプリケーション向けにOpenTelemetryを構成する
NGINX | 2024/01/18

チュートリアル:NGINXを使用してアプリケーション向けにOpenTelemetryを構成する

OpenTelemetryを使用してNGINXサーバーの状態と健全性をより明確に把握することで、問題のトラブルシューティングを行い、Webアプリケーションのパフォーマンスを向上できます。

AkitaのNGINX Plus認定モジュールでAPIエンドポイントの問題を特定・修正
NGINX | 2023/05/31

AkitaのNGINX Plus認定モジュールでAPIエンドポイントの問題を特定・修正

Akita SoftwareのAPIオブザーバビリティ向け新しいNGINX Plus Certified Moduleを活用して、APIエンドポイントの問題をより迅速に特定し、修正できます。

JavaプロジェクトをスキャフォールディングしてKubernetesネイティブアプリを構築する方法
NGINX | 2023/02/09

JavaプロジェクトをスキャフォールディングしてKubernetesネイティブアプリを構築する方法

Red HatのシニアプリンシパルデベロッパーアドボケイトであるDaniel Oh氏が、Javaプロジェクトをゼロから構築するためのひな形を作成し、Kubernetesネイティブアプリケーションとしてビルドする方法を解説します。

F5 NGINXaaS for Azureのご紹介:Microsoft Azureでネイティブに利用できるSaaS型ロードバランシング
NGINX | 2022/05/24

F5 NGINXaaS for Azureのご紹介:Microsoft Azureでネイティブに利用できるSaaS型ロードバランシング

NGINXaaS for Azureは、NGINX PlusをAzureネイティブのSaaSとして利用できるサービスです。NGINXの設定を容易にリフト&シフトできるため、クラウド導入とモダンアプリの展開を加速できます。

SELinuxでNGINXおよびNGINX Plusを使用する
NGINX | 2018/08/17

SELinuxでNGINXおよびNGINX Plusを使用する

Red Hat Enterprise Linux(RHEL)および関連ディストリビューションでSecurity-Enhanced Linux(SELinux)を有効にすると、デフォルト設定によりNGINXとNGINX Plusの一部の操作が制限されます。この記事では、すべての機能を利用できるようにSELinuxの設定を変更する方法について説明します。

NGINX PlusによるAWS Auto Scalingグループの負荷分散
NGINX | 2017/03/06

NGINX PlusによるAWS Auto Scalingグループの負荷分散

新しいnginx-asg-sync統合ソフトウェアにより、NGINX PlusはAWS Auto Scalingグループの負荷を直接分散できるため、クラウドでの負荷分散がさらに柔軟になります