ロードバランシング。アプリケーションをスケールアップ（できればスケールダウンも）するために必要であり、日々利用し、依存していることは広く認識されています。今やロードバランシングは、需要に応じたスケーリングだけでなく、企業の生産性と収益を支えるアプリケーションやサービスの継続的な可用性を確保する、重要なインフラとなっています。
だからこそ、ロードバランシングを改めて見直す必要があります。現在では、こうした優れたサービスのプロビジョニング、構成、導入を担うことが多い運用担当者が、ロードバランシングを戦術的な手段として扱う傾向が強まっています。しかし、本来はそれだけにとどまりません。ロードバランシングを戦略的に捉えることで、パフォーマンスの向上、リスクの軽減、アプリケーションの提供に必要なリソースの効率的な活用が可能になります。ロードバランシングは、しばしば「配管」に例えられるほど単純なものではありません。いくつかの重要なポイントを理解すれば、運用担当者は、アプリケーションを支えるためにロードバランシングをどのように活用しているかを、より深く検討できるようになります。
それでは早速、運用担当者がロードバランシングについて知っておくべき3つのポイントをご紹介します。
1. アルゴリズムは相対的なもの
まず、ラウンドロビンは最後まで話題にすべきでないアルゴリズムだと言いたいところですが、それはすでにご存じでしょう。そこで、ラウンドロビンは省き、よりインテリジェントなアルゴリズムである最小接続数や最速応答時間について見ていきます。パフォーマンスとリソースの効率的な利用を両立させる方法を検討するうえで、これらがはるかに優れた選択肢であることは言うまでもありません。どちらも、次のリクエストをどのアプリケーションインスタンス（必要に応じてコンテナ）に割り当てるかを判断する際に重要となる、アプリケーションの特性（少なくとも、アプリケーションを配信するプラットフォームの特性）を考慮します。最小接続数では、接続数が少ないインスタンスほど余力があり、今このリクエストを処理する能力が高いと推定します。つまり、パフォーマンスよりもキャパシティの有効活用を優先する方式です。
最速応答時間は、対極的に、パフォーマンスに基づいてリクエストの転送先を決定します。インスタンスの処理が速いほど、選択される頻度も高くなります。「負荷が増えるとパフォーマンスが低下する」という運用上の原則により、最終的には負荷の低いサーバーの応答が速くなり、そのサーバーが選択されます。これはキャパシティ効率にも一定の配慮を示すものですが、このアルゴリズムは常にキャパシティよりもパフォーマンスを優先します。
ここで、アルゴリズムの名称に注目してください。最少と最速です。2匹のカメが歩道で競走している場合を考えてみましょう。どちらも一般に「遅い」と呼ばれる速度で進んでいても、一方はもう一方より速いことになります。最少接続数についても同じです。99と100のどちらかを選ぶ場合、99のほうが間違いなく少ない値です。
重要である理由
ロードバランシングによるリクエストの処理方法は、パフォーマンスと可用性に直接かつ即座に影響します。どちらも、最終的に顧客エンゲージメントと従業員の生産性を左右する重要な特性です。ロードバランシングを含むアーキテクチャを最適化することで、生産性の向上と収益目標の達成を通じたビジネスの成功につながります。
さらに詳しく：
2. 「即座に失敗する」は（多くの場合）誤解
クラウドとソフトウェア定義データセンターの台頭に伴い、アプリケーションのスケーリングにはエラスティシティが用いられるようになりました。エラスティシティでは、リソース（および予算）の利用を最適化するため、必要に応じてスケールアップとスケールダウンを行う必要があります。オンデマンドでスケールアップできるのに、なぜ余分なリソースをあらかじめ用意するのでしょうか。同様に、冗長性の原則に依存する高可用性（HA）アーキテクチャも、ほとんど時代遅れになりつつあります。プライマリアプリインスタンスに障害が発生する（可能性の低い）事態に備えて、なぜ未使用のリソースをスタンバイさせておく必要があるのでしょうか。設備投資と運用予算の無駄です。消えろ、消えろ、忌まわしきスタンバイ！
オンデマンドでのフェイルオーバーとスケーリングは理論上は理想的ですが、実際にはそれほど単純ではありません。仮想サーバー（クラウドサーバーなど、呼び方は何であれ）であっても、起動には時間がかかります。プライマリサーバーに障害が発生するか、処理能力の上限に達してから、別のサーバーを起動しようとしても（自動化システムを使用する場合も含め）、すでに手遅れです。クラウド環境のキャパシティプランニングには、従来の環境で通用していた計算方法をそのまま適用できません。需要に応じてシームレスにスケーリングするには、キャパシティのしきい値を算出する際に、リソースの消費速度と別のサーバーの起動に要する時間を考慮する必要があります。
フェイルオーバーについても同様です。プライマリサーバーに障害が発生してから代替サーバーを起動するには時間がかかります。その間にユーザーの接続が切れたり、タイムアウトが発生したりして、競合他社や話題の猫動画に流れてしまう可能性があります。待機系サーバーをアイドル状態にしておくのは、保険と同じように無駄に思えるかもしれません。しかし、いざ必要になれば、その存在のありがたさを実感するでしょう。特に、そのアプリが顧客エンゲージメントや収益を担っている場合、わずか数分のダウンタイムでも、そのリスクと結果的に生じる損失を考えれば、待機系サーバーを常時用意しておくコストを十分に上回る可能性があります。
興味深いことに、コンテナは非常に高速に起動できるため、こうした課題に対処できる可能性があります。可用性、パフォーマンス、コストのすべてが同じように重要であれば、この3つのバランスを取るうえでコンテナがもたらす価値を検討し始める時期かもしれません。
重要である理由
ダウンタイムは多大なコストをもたらします。その原因を突き止めることよりも、まずダウンタイムを回避することが重要です。障害が発生しても、ビジネスの成功に不可欠な継続的可用性を維持できるよう、適切なアーキテクチャとフェイルオーバー計画を整備しておく必要があります。
詳細情報：
3. クライアントIPは実際のクライアントIPではありません。
アプリを開発環境から本番環境に移行する際に発生する問題の中で、これはおそらく最も一般的で、簡単に回避できるものです。実際、ほとんどのロードバランシングサービス（少なくとも優れたサービス）はプロキシです。つまり、クライアントはプロキシに接続し、プロキシがアプリに接続します。どちらの接続でもHTTPの転送にTCPを使用するため、ネットワークの仕組みに従う必要があります。送信元IP（クライアントIPだと思っているもの）は、実際にはプロキシのIPアドレスです。IPアドレスに基づいてセキュリティ、認証、または使用量の計測を行っている場合、これは深刻な問題になります。HTTPヘッダーから取得した値は、必要としている値ではありません。
業界では、HTTPカスタムヘッダーを利用してこの問題に対処する方法がほぼ定着しています。おそらく必要なのはX-Forwarded-For ヘッダーです。プロキシはリクエストを転送する際に、実際のクライアントIPアドレスをこのヘッダーに格納します。ただし、これは正式な標準ではなく、業界内で事実上合意されているデファクトスタンダードにすぎないため、確認が必要です。
重要なのは、取得しようとしているクライアントIPアドレスが想定しているものとは異なるという点です。そのため、その情報を必要とするアプリが本番環境への移行後に突然動作しなくなることがないよう、開発者は事前にこの点を考慮する必要があります。
ビジネスにとって重要な理由
本番環境で問題をトラブルシューティングするコストは、開発環境やテスト環境の場合よりもはるかに高くなります。問題の特定と修正に時間がかかると、プロジェクトのスケジュールに悪影響が及び、アプリケーションが中心となる世界で競争優位性とビジネスの成功に不可欠な市場投入までの時間も長期化します。こうした一般的な問題を認識し、開発またはテスト段階で対処することで、本番環境への導入から市場投入までを迅速かつ円滑に進めることができます。
さらに詳しく：
著者について
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ブログをご覧ください。