F5 BIG-IPを活用し、コンテナ内のアプリケーションをスケールする際の階層を排除

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

それとも、悔し「涙」でしょうか？ ¯\_(ツ)_/¯ もしかすると、両方かもしれません。

ネットワークアーキテクチャとアプリケーションアーキテクチャには相互関係があります。通常は、アプリケーションアーキテクチャの変更や移行が、ソリューションとアーキテクチャの両面でネットワークにどのような影響を及ぼすかが話題になります。しかし、その逆もまた然りです。ネットワークのアーキテクチャと動作が、アプリケーションとそのアーキテクチャに極めて大きな影響を及ぼすこともあります。

つまり、モノリスが多数のマイクロサービスへと分割されるようになったのが、SOAの時代ではなく今である理由の1つは、ネットワークにあります。より正確には、ネットワークの速度です。SOAの時代には、ネットワークの性質（そして物理法則）による制約があり、4つを超えるサービスから単一のレスポンスを構成することは不可能でした。厳密には不可能ではありませんが、呼び出しのたびにレイテンシーが発生するため、望ましくありませんでした。

現在では、ネットワークの高速化と広帯域化に加え、コンピューティング性能も桁違いに向上し、こうした分割が可能になっています。さらに容易にしているのが、コーヒーとドーナツのようにマイクロサービスと組み合わせて使われることの多いコンテナの特性です。通信が必要な2つのサービス間の「ネットワーク」は仮想的な構成であることが多く（パケットが実際にホストサーバーの外へ出ることはなく、「ネットワーク上に送出」する際のレイテンシーも発生しません）、1つのリクエストに応答するために呼び出せるサービスの数は、SOAの時代に現実的に実現できた数よりもはるかに多くなっています。

しかし、だからといって、リクエストに応答するために経由する接続やホップの数、あるいはアーキテクチャがアプリケーションのパフォーマンスに及ぼす影響を無視してよいわけではありません。コンピューティングが高速化し、ネットワーク帯域が拡大しても、運用上のオーバーヘッドには依然として対処する必要があり、パフォーマンスを低下させる要因となります。運用上のオーバーヘッドに対処し、パフォーマンスを向上させる最も簡単な方法の1つは、アーキテクチャから（不要な）階層を排除して複雑さを軽減することです。

コンテナ環境の複雑さを軽減

ほとんどのコンテナ環境では、コンテナ内のマイクロサービスやアプリケーションの規模を管理するために、クラスター内で何らかのロードバランサーを使用します。これは、多くの場合、APIのL7ルーティング（イングレス制御）を担う必要がある一方、ネイティブの負荷分散機能はiptablesをベースとしており、L7ルーティングで使用されるHTTPを扱えないためです。その結果、コンテナクラスター内に多数のL7ロードバランサーが配置されます。

また、ほとんどのデプロイでは、外部トラフィックをクラスター外部からクラスター内部の適切なロードバランサーに転送するために、クラスター外部でのロードバランシングも必要になります。そのため、従来型のロードバランシングを使用して、クラスター内部の適切なロードバランサーにリクエストを分散します。

外部のロードバランサーを BIG-IP、クラスター内のロードバランサーを 内部LB と呼ぶことにします。私のブログなので、呼び方は私が決めます。

問題は、internal lb インスタンスの数が変動する（場合によっては大幅に変動する）ことです。変更があるたびに、BIG-IPにその情報を反映する必要があります。従来、これは手動で行う作業であり、BIG-IPの管理者がプールを手作業で変更する必要がありました。これは開発者やDevOpsにとって不満の種であり、NetOpsにとっては面倒な作業です。つまり、誰もこの方法を望んでいません。

そのため、F5 Container Connectorのようなソリューションが存在します。F5 Container Connectorは、コンテナオーケストレーターと連携して環境を監視する、コンテナネイティブなサービスです。internal lbに影響する変更があると、BIG-IPを更新するプロセスが開始されます。これにより、需要の増減に応じてBIG-IPが自動的に最新の状態に保たれ、アクティブで正常なinternal lbにリクエストを適切に分散できます。手動で変更する必要はありません。

この2層のスケーリングアーキテクチャには、SSL/TLSを終端できる便利な受信ポイント（BIG-IP）が用意され、測定可能なパフォーマンス向上が得られるという利点があります。優れた仕組みです。

しかし、そこで止める必要はありません。BIG-IPはL7ルーティングを提供できます。F5 Container Connectorのサービスを利用している場合は、内部ロードバランサーを完全に排除することで、さらなるパフォーマンス向上と運用オーバーヘッドの削減を実現できます。本当です。BIG-IPは、KubernetesおよびRed Hat OpenShiftのIngressコントローラーとして機能できます。

イングレスの役割をBIG-IPに移すことで、スケーリング階層を1つ（内部ロードバランサー）完全に排除し、パフォーマンスを即座に向上できます。また、外部ロードバランサーがF5 BIG-IPであるため、ボット対策機能を備えた高度なWAFなど、セキュリティ重視のアプリケーションサービスをコンテナクラスター内ではなく接続ポイントに追加で導入できます（導入しないことも可能です）。

運用チーム間の対立

コンテナの本番環境へのデプロイ頻度が高まるにつれ（実際、そうなるでしょう）、このような改善を実現し、アプリケーションのスケーラビリティ、速度、セキュリティを確保するには、DevOpsとNetOpsの連携をさらに強化する必要があります。結局のところ、単にボタンを押したり、セルフサービス型のパイプラインを利用したりするだけでは不十分です。アーキテクチャは重要な要素であり、アプリケーションパフォーマンスなどを改善する機会を逃さないためにも、DevOpsとNetOps双方の意見を取り入れて設計する必要があります。

アプリケーションパフォーマンスの向上には、チーム全体で取り組む必要があります。パフォーマンスは、コード（AppDev）、コードをデプロイするプラットフォーム（DevOps）、ネットワークアーキテクチャ、そしてアプリケーションのセキュリティ確保とスケーリングに使用するアプリケーションサービス（NetOps）の影響を受けます。可能な場合に階層をなくしてアーキテクチャを最適化することは、運用面でもビジネス面でも合理的です。ただし、その実現にはチームの全メンバーの参加が欠かせません。

ピザとビールを用意して、DevOpsとNetOpsの担当者が一堂に会し、話し合いを始めましょう。コンテナ環境から不要な階層を取り除くことで、アプリケーションのパフォーマンスを改善できるかどうかを検討してください。

著者について

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

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

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