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

それとも、それは悔しさの「涙」でしょうか？¯\_(ツ)_/¯ おそらく両方でしょう。

ネットワーク アーキテクチャとアプリケーション アーキテクチャの間には関係があります。 通常、私たちは、ソリューションとアーキテクチャの両方の観点から、アプリケーション アーキテクチャの変更と移行がネットワークにどのような影響を与えるかについて話をします。 しかし、逆もまた真なりであり、ネットワークのアーキテクチャと動作は、アプリケーションとそのアーキテクチャにかなり大きな影響を及ぼす可能性があります。

つまり、SOA 時代ではなく現在、モノリスが多数のマイクロサービスに分解されている理由の 1 つは、ネットワークです。 もっと正確に言えば、ネットワークの速度のためです。 SOA の時代には、ネットワークの性質 (および物理法則) によって課せられた制限があり、3 つまたは 4 つ以上のサービスから単一の応答を作成することは不可能でした。 はい、不可能ではありませんが、各呼び出しで遅延が発生するため、望ましくありません。

今日では、より高速で、より太いネットワークと桁違いに高速なコンピューティングが実現可能となり、その分解が実現可能になりました。 さらに簡単になるのは、コーヒーとドーナツのようにマイクロサービスと頻繁に組み合わせられるコンテナの性質です。 通信する必要がある 2 つのサービス間の「ネットワーク」は仮想構造であることが多いため (パケットは実際にはホスト サーバーから出ることはなく、「回線に流す」ために発生する遅延の影響を受けません)、単一の要求に応答するために呼び出すことができるサービスの数は、SOA の時代に合理的に達成できた数よりもはるかに多くなります。

しかし、これは、リクエストに応答するために通過しなければならない接続とホップの数や、アーキテクチャがアプリケーションのパフォーマンスに与える影響を無視すべきだという意味ではありません。 コンピューティングが高速化し、パイプが太くなったとしても、運用上のオーバーヘッドは依然として対処しなければならない問題だからです。 依然としてパフォーマンスを妨げるもの。 運用上のオーバーヘッドに対処し (パフォーマンスを向上させる) 最も簡単な方法の 1 つは、アーキテクチャ内の (不要な) 層を排除して複雑さを軽減することです。

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

ほとんどのコンテナ デプロイメントでは、コンテナ環境内のマイクロサービス/アプリのスケールを管理するために、クラスター内で何らかのタイプのロード バランサーが使用されます。 これは、多くの場合、API の L7 ルーティング (つまりイングレス制御) を実行するタスクが課せられ、ネイティブの負荷分散構造は iptables に基づいているためです。iptables は当然ながら、L7 ルーティングの言語である HTTP を話しません。 つまり、クラスター コンテナ内には多数の L7 ロード バランサーが存在します。

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

BIG-IP外部のロード バランサを「内部 lb」、クラスター内のロード バランサを「内部 lb」と呼びます。 それは私のブログだから、そういうことです。

問題は、内部 lbインスタンスの数が変動することです (場合によっては劇的に変動します)。 変更があるたびに、BIG-IP がそれを認識する必要がありま す。 従来、これは手動操作であり、BIG-IP の所有者が外に出てプールを手動で変更する必要がありました。 これは、開発者や DevOps にとってはイライラすることであり、NetOps にとっては面倒なことです。 言い換えれば、誰もこのようにやりたくないのです。

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

この 2 層のスケーリング アーキテクチャには、SSL/TLS を終了できる便利な受信場所 (BIG-IP) を提供するという利点があり、測定可能なパフォーマンスの向上が実現します。 ニース。

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

イングレス責任を BIG-IP に移行することで、スケール層全体 (内部 lb) が排除され、パフォーマンスが即座に向上します。 外部 lb はF5 BIG-IPであるため、コンテナー クラスター内ではなく (またはまったく)、コンタクト ポイントでボット防御機能を備えた高度な WAF などのセキュリティ重視のアプリケーション サービスをさらに展開できます。 

クラッシュ・オブ・オプス クラン

コンテナがより頻繁に本番環境に導入されるようになると (そうなるでしょう)、こうした改善を実装し、アプリのスケール、速度、セキュリティを確保するために、DevOps と NetOps 間の連携を強化する必要が出てきます。 結局のところ、ボタンを押すことやセルフサービスのパイプラインだけではありません。 アーキテクチャは、アプリケーション パフォーマンスなどの改善の機会を無視しないように、DevOps と NetOps の両方の入力に基づいて設計する必要がある重要なコンポーネントです。

アプリケーションのパフォーマンスはチームスポーツだからです。 これは、コード (AppDev)、コードがデプロイされるプラットフォーム (DevOps)、ネットワーク アーキテクチャ、およびアプリのセキュリティ保護と拡張に使用されるアプリケーション サービス (NetOps) によって影響を受けます。 可能な場合は階層を排除してアーキテクチャの最適化を採用すると、運用上およびビジネス上のメリットが得られます。 しかし、チームの全選手の参加が必要です。

ピザとビールを注文して、DevOps と NetOps を組み合わせて話し合いを始めましょう。 コンテナ環境内の不要な層を削除することで、アプリのパフォーマンスを向上できるかどうかを確認してください。