Ingress Controller：名称は新しく、機能はこれまでどおり

Lori Mac Vittie特別技術者兼チーフエバンジェリスト | F5

ご当地表現。その土地ならではの意味を持つ言葉やフレーズで、地元以外の人を戸惑わせることがあります。たとえば、外出中に喉が渇いたら、私は「bubbler」を探します。おそらく皆さんは（ウィスコンシン州民の「Sconnie」ではないでしょうから）「water fountain」を探すでしょう。ウィスコンシン州では、距離をマイルではなく時間で表します。信号機は「stop n' go」ライト。だって、そこで止まったり進んだりするものですから。

夫（ウィスコンシン出身ではありません）が特に面白がるのは、「C’mere once.」という言い回しです。私や、私がこの表現を使う子どもたちには自然に通じる、としか説明のしようがありません。また、私たちは「Up North」が方角ではなく、ある場所を指すことも感覚的に理解しています。具体的な場所は話し手によって異なっても、「すべてを忘れて逃れに行く、あの場所」という、ウィスコンシン出身者なら誰もが共有するニュアンスがあるのです。

皆さんにも、育った土地ならではの言い回しのリストがあるでしょう。でも、これは私のブログなので、ここでは私のリストを使います。

とはいえ、今日の主眼は意味論そのものを論じることではなく、それがもっと身近な現象にどう当てはまるかを考えることです。もっとも、ここでいう「身近」とは、皆さんの組織内という意味ですが。

コンテナと、それに不可欠な自動クラスタリング制御システム（一般にオーケストレーションと呼ばれます）の普及は、意図せず、州境の片側で使われていた言い回しを反対側にも持ち込む結果となりました。ちなみに、ここでいう境界とは、アプリケーション開発とIT本来の領域との境界です。

コンテナ用語をめぐる奇妙な事情

必要な規模で柔軟性と信頼性を確保するために求められる多くの機能により、従来は本番環境でのみ利用されていた一部のサービスが、コンテナ「環境」へ移行しています。現在、これらの機能は表向きにはその環境に「組み込まれ」、軽量な統合（APIとメッセージキューイング）を利用することで、これまでは完全に実装されたクラウドコンピューティング環境でしか実現できなかった自動スケーリングと高可用性アプリケーションを実現しています。

この仕組みにより、ロードバランシング機能は、小規模なデーモン型サービスを介してポッド／ノードにネイティブに組み込まれます。高度な機能とは言えず（ネットワークロードバランシング機能をわずかに上回る程度です）、それでも設計どおりの役割を果たします。これらのサービスはプラグイン可能であり、実際にそのように利用されています。そのため、オープンソースやベンダー提供の他のプロジェクトを組み込み、より高度な機能（さらにはアルゴリズムも期待されます）を利用できるようになります。

しかし、これらの負荷分散機能だけでは、最終的に求められる規模の拡張性と高可用性（本番環境では不可欠です）を実現できません。また、HTTP（L7）の高度な処理を必要とするAPIルーティングにも対応していません。マイクロサービスを基盤とし、APIファサードをフロントエンドに据えたモダンアプリケーションを効率的にスケールアウトするには、こうした機能が必要です。より堅牢なソリューションが求められます。

そこで登場するのがIngress Controllerです。これは、URIとHTTPヘッダーに基づいてIngressトラフィックを解析して振り分け、アプリケーション層のルーティングとスケーラビリティを実現する「ロードバランサー」です。

実際のところ、ingress controllersを開発し、その後利用している開発者は、netopsでトラフィック管理、アプリケーションデリバリー、コンテンツスイッチング／ルーティングと呼ばれるものを、基本的に再構築したのです。netopsでは長年にわたりさまざまな用語が使われてきましたが、dev(ops)でも同様です。アプリルーティングやページルーティングも、開発者がL7ルーティングを表すために使用してきた用語です。この概念自体は、どちらのグループにとってもなじみのないものではありません。しかし、用語、つまり通称にはなじみがありません。

An Ingress Controllerは、リクエストをコンテナクラスター内の適切な（仮想）サービスにルーティングする役割を担います。そのサービスは、別の負荷分散プロキシの場合もあれば、コンテナシステム固有の構成要素の場合もあります。いずれの場合も、Ingress Controllerの役割は、HTTPリクエストのHTTPヘッダーに含まれるレイヤー7（HTTP）の値に基づいてトラフィックをルーティングすることです。通常はURIを使用しますが、ホスト名や、バージョン番号、APIキーなどのカスタム値を使用することもあります。

Once the ingress controllerがヘッダーから値を抽出すると、リソースファイルに記述されたポリシーに基づいて、リクエストの振り分け方法を決定します。均等に振り分けることも、サービスの一方のバージョンに75%、もう一方に25%を送信することもできるなど、柔軟な振り分けが可能です。また、ingress controllerはヘルスとステータスを監視する役割も担っており、リクエストを「停止中」のサービスに振り分けないよう、十分に注意する必要があります。

ネットワーク運用担当者の皆さまには、聞き覚えがあるのではないでしょうか。これは基本的に、BIG-IPのようなインテリジェントなプロキシ（L7対応）が担う機能だからです。

共通点を理解したところで、相違点もいくつかあることを確認しておきましょう。特に、Ingress Controllerは宣言的に構成されます。つまり、その構成は、コントローラー自体の外部にあるリソースファイルの記述によって決まります。これは、受信トラフィックを制御して振り分ける従来のスマートプロキシとは異なります。従来のスマートプロキシは、環境に関する信頼できる情報源です。一方、Ingress Controllerはそうではありません。実装に柔軟性を持たせる一種の「抽象化レイヤー」として機能するファイルを外部に参照します。そのため、Ingress Controller（または補完コンポーネント）は、そのファイルを読み取って解釈し、記述に応じた構成を作成する必要があります。また、その構成を最新の状態に保つ必要もあります。コンテナ化された環境では、Ingress制御部分の変動性はシステム内部ほど大きくありませんが、それでも変化するため、監視が必要です。

結局のところ、Ingress Controllerは、外部からのリクエストをコンテナ化された環境内の適切なリソースに振り分ける、アプリケーション層のルーティングを担います。これは、まさにスマートロードバランサーの定義そのものです。

名称は変わっても、機能はほとんど変わりません。

著者について

Lori Mac Vittie特別技術者兼チーフエバンジェリスト | F5

Lori MacVittieは、F5のOffice of the CTOに所属するDistinguished Engineer兼Chief Evangelistであり、アプリケーションデリバリ、自動化戦略、インフラストラクチャに関する深い専門知識を有しています。AIエージェントのガードレール策定、脆弱なマルチクラウドアーキテクチャの分析、スケーラブルなシステムの限界の検証など、複雑な事柄を明快にすることで知られています。アプリケーション開発、ITアーキテクチャ、ネットワークおよびシステム運用の分野で、30年以上にわたる業界経験を有しています。F5入社前は、受賞歴のあるテクノロジー編集者として活躍していました。 MacVittieはコンピューターサイエンスの修士号を取得しており、セキュリティ、クラウド、エンタープライズアーキテクチャにわたる分野で多数の著作を発表しています。また、テーブルトークゲームとビデオゲームをこよなく愛し、チーズについては遠慮なく強いこだわりを語ります。

Lori Mac Vittieのその他のブログ記事