コンテナの世界から次々と生まれる専門用語に、頭がくらくらする日もあります。サービスメッシュ、オーケストレーター、レジストリなど、関連ソリューションに新たな機能が加わるたびに、新しい用語や表現も必要になるようです。そうした表現はDevOpsには通じても、NetOpsには目を細めて首をかしげられることが少なくありません。
たとえば、私が「一番近いbubblerはどこですか」と尋ねたときに浮かべるような表情です。一般にはwater fountainと呼ばれますが、ウィスコンシン州ではbubblerと呼びます。同じものでも、呼び方が違うのです。
社内環境やマルチクラウド環境でのコンテナのスケーリングに関連する「新しい」機能の多くは、実のところ、DevOpsがウォーターファウンテンを「バブラー」と呼んでいるようなものです。コンテナが勢いを失うことなく主流になり続ける中、こうした呼び方の違いがNetOpsとの摩擦を招く可能性があります。本番環境でコンテナクラスターが分離されたミニクラウドのような形態を維持していても、NetOpsが引き続き管理する企業ネットワークとの接点は残ります。そしてマルチクラウドの世界でこれらのクラスターを安全にスケーリングするには、NetOpsとDevOpsが連携しなければなりません。
Ingress Controller
- すでに述べたように、「Ingress Controller」という用語は、レイヤー7ロードバランシング（コンテンツスイッチング、コンテンツルーティングなど）を新たに言い換えたものです。Ingress Controllerは、コンテナクラスター内の適切なリソースにリクエストをルーティングする、レイヤー7（HTTP）対応のプロキシです。ネットワーク内でNetOpsが使用するHTTPプロキシと、コンテナクラスターへのエントリーポイントとして機能するHTTPプロキシの大きな違いは、Ingress Controllerがコンテナを認識する必要がある点です。ここで「コンテナを認識する」とは、自動的に構成および管理されることを意味します。これは、コンテナ環境で発生する変更、特にIngressが受信リクエストをどのようにルーティングするかを記述したリソースファイルの変更に基づいて行われます。
レイテンシーを考慮した負荷分散
- 斬新で魅力的に聞こえます。しかし、ふたを開けてみれば、実際には「最速応答」ロードバランシングアルゴリズムを活用しているにすぎないと分かり、NetOps担当者も大きくうなずくでしょう。その狙いは、「応答の遅いインスタンスからトラフィックを移す」ことでアプリのパフォーマンスを向上させることです。これが特に取り上げられているのは、一般に、コンテナオーケストレーターに標準搭載されているロードバランシングアルゴリズムがパフォーマンスを考慮しないためです。ほぼ標準となっているラウンドロビンは、パフォーマンスの最適化を目指す場合、最も避けるべきアルゴリズムの1つです。1件のクライアントリクエストを処理するために行われるマイクロサービス間の呼び出しは、そのたびにレイテンシーを増加させます。そのため、最も高いパフォーマンスに基づいてリクエストをルーティングできることは非常に重要です。
Multi-Cluster Ingress
- まず、これは業界で20年近く使われてきた用語よりも、はるかに格好よく聞こえます。要するに、これはGSLB（グローバルサーバーロードバランシング）です。期待外れかもしれませんが、内部ではマルチクラスターイングレスがまさにその役割を果たしています。イングレスコントローラーにグローバルトラフィック管理の機能を少し加えれば、あっという間に完成です。マルチクラウド構成のコンテナクラスター向けGSLBができあがります。こちらの方がずっと印象的に聞こえるので、NetOps側でもGSLBをこの用語に置き換えることに一票を投じます。
登場した用語はこれだけではなく、今後も新たな用語が出てくるでしょう。ここで挙げた用語は、「ネットワーク内」の機能や能力がDevOpsに取り込まれていることを示すうえで、特に重要なものです。Multi-Cluster Ingressのように本番環境へ移行する際にNetOpsの対応が必要になるものもあれば、そうでないものもあります。コンテナ環境内のレイテンシーを考慮した負荷分散は、今後もDevOpsの領域にとどまる可能性が高いものの、パフォーマンスや可用性の向上について議論する際に備えて理解しておくとよいでしょう。
DevOpsには、見過ごされたり、完全に無視されたりしがちな文化的要素があります。この動きがNetOpsにも影響を及ぼし続け、従来のネットワーク運用がアジャイルなネットワークの実現に向けてその原則を着実に取り入れていく中で、コミュニケーションが極めて重要になります。そのためには、共通の認識を築く必要があります。互いの専門用語を理解することは、アプリケーションのデプロイとデリバリーの双方で、迅速性、セキュリティ、信頼性を確保するために必要な、より協力的な文化を築く第一歩となります。
著者について
Lori MacVittieは、F5のOffice of the CTOに所属するDistinguished Engineer兼Chief Evangelistであり、アプリケーションデリバリ、自動化戦略、インフラストラクチャに関する深い専門知識を有しています。AIエージェントのガードレール策定、脆弱なマルチクラウドアーキテクチャの分析、スケーラブルなシステムの限界の検証など、複雑な事柄を明快にすることで知られています。アプリケーション開発、ITアーキテクチャ、ネットワークおよびシステム運用の分野で、30年以上にわたる業界経験を有しています。F5入社前は、受賞歴のあるテクノロジー編集者として活躍していました。 MacVittieはコンピューターサイエンスの修士号を取得しており、セキュリティ、クラウド、エンタープライズアーキテクチャにわたる分野で多数の著作を発表しています。また、テーブルトークゲームとビデオゲームをこよなく愛し、チーズについては遠慮なく強いこだわりを語ります。
Lori Mac Vittieのその他のブログ記事関連するブログ記事
F5 Application Study Tool：OpenTelemetryによるF5 BIG-IP環境の監視
F5の新しいオープンソースツールは、BIG-IP環境を詳細に可視化し、データを追跡するとともに、強力でカスタマイズ可能なインサイトを得るための基盤を提供します。
F5 BIG-IPでAI防御を実現
F5 BIG-IP Advanced WAF、BIG-IP APM、BIG-IP SSL Orchestratorが、生成AIアプリ向けに包括的なセキュリティソリューションを提供する仕組みをご覧ください。
F5 Advanced WAFによるGraphQL APIの保護
ここ数年、多くの組織がデジタルトランスフォーメーションを進めており、COVID-19のパンデミックによってその動きは加速しています。
アプリケーションサービスの現状 通信業界版：リーダーとしての台頭
通信ネットワークが進化し、さまざまな業界の幅広いユースケースに対応するなか、通信業界の回答者がテクノロジーリーダーとしての存在感を高めていることがわかります。
デジタルトランスフォーメーションは、単なるペーパーレス化ではない
デジタルトランスフォーメーションは、単なるペーパーレス化ではありません。真のモダナイゼーションにアプリケーションアーキテクチャとセキュリティの再構築が必要な理由を、F5ブログでご覧ください。
やめましょう。もう本当にやめましょう。HTTPSはHTTPより高速ではありません。
もうやめましょう。HTTPSはHTTPより高速ではありません。プロトコルのパフォーマンスに関する微妙な違いと、暗号化トラフィックを適切に最適化する方法については、F5ブログをご覧ください。