POLB（従来型のロードバランシング）を超えて

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

スケーラビリティは、ビジネスとアプリケーションの双方に不可欠な能力です。ビジネス面では、運用のスケール拡大が、新たなアプリ経済と、そこでほぼ絶え間なく繰り広げられる急速なデプロイを支える鍵となります。アプリケーション面では、スケーラビリティによって、一般ユーザーと企業ユーザー双方の増加に対応し、いずれにも優れたパフォーマンスと可用性を確保できます。

スケーラビリティの中核を担うのが、ロードバランシングです。1990年代半ば以降、サーバー、ネットワーク、アプリケーション、サービスで構成される大規模化し続けるファーム全体にワークロードを分散することで、アプリケーションをスケールさせてきました。

かつて、ロードバランシングはネットワークを中心とするものでした。ネットワークをスケールアウトする既存の技術やプロトコルを基盤として、クライアントとサーバー間の通信のうち、ワークロードの分散に利用できる要素に重点が置かれていました。こうして、Plain Old Load Balancing（POLB）が誕生しました。

POLBは機能し、しかも非常にうまく機能しました。POLBがなければ、今日のようなWebが実現していたかどうかは、ほとんど知る由もありません。POLBは、現在の企業や消費者を支えるうえで極めて重要な役割を果たしてきました。そして今も、将来にわたって支え続けるために欠かせない存在です。

2000年代初頭のある時期、ロードバランサーはネットワーク上の戦略的な位置にあったことから、アプリケーション体験を向上させる他の機能を拡充するための理想的なプラットフォームとなりました。やがて、アプリケーションの高速化、最適化、キャッシュ、圧縮が追加されました。ネットワーク上の位置が極めて有利だったため、セキュリティ機能も同じプラットフォームに組み込まれるようになりました。アプリケーションのゲートキーパーとして、アプリケーショントラフィックを検査、抽出、変更、変換できるため、パフォーマンスだけでなくセキュリティにも同様に役立つ独自のインサイトを得られます。

2000年代初頭のある時期、私たちはPOLBの枠を超え、新たな領域へと進みました。ロードバランサーはアプリケーションデリバリープラットフォームへと進化し、POLBによるアプリケーションのスケーリングだけでなく、セキュアで高速かつ可用性の高いアプリケーションの提供にも同等の能力を発揮するようになりました。

こうした最新のプラットフォームは、ADC（アプリケーションデリバリーコントローラー）と呼ばれ、POLB機能だけでなく、実に多彩な機能を提供できます。そのため、現在、アプリケーションのデプロイだけでなくデリバリーも担う担当者にとって、非常に価値の高い存在となっています。

その役割を担うのは、ネットワークチームではなく、アーキテクトや運用チームであるケースが増えています。

この変化を後押ししてきたのは、過去10年間に登場したさまざまなテクノロジーです。アジャイル、クラウド、DevOps、モバイルなど、今日のベストプラクティスにより、一部のアプリケーションサービスはネットワークの領域からアプリケーションの領域へと移行しつつあります。

また、スケーラビリティに対する責任がネットワークからアーキテクトや運用担当者へと移行する一方で、ADCは1990年代から進歩していないかのような方法で導入されています。ADCをPOLBとして扱うことで、パフォーマンスとセキュリティの向上においてアーキテクトや運用担当者にもたらす価値の大半が活用されないままになっています（「棚上げ」ならぬ「ラック上げ」とでも言うべきでしょうか）。

その主な理由は、現在アプリケーションのスケーリングを担うアーキテクトや運用チームが、ADCによって自分たちの業務、そして何よりアプリケーションやアーキテクチャに何ができるのかを十分に理解していないことです。今こそ、この状況を変え、POLBの先へ進むときです。

POLBの先へ：L7 LBプロキシ

POLBの目標は、可用性というシンプルなものでした。冗長性に基づくHA（高可用性）アーキテクチャを実装する場合でも、N+1スケーリングアーキテクチャを使用する場合でも、目標は同じです。何があってもWebサイト（またはアプリ）を稼働させ、利用可能な状態に保つことです。

現在も目標は可用性ですが、そこには効率性と俊敏性も求められます。この3つは、現代のビジネスと、その重要なアプリケーションを支えるアーキテクチャに欠かせない特性です。しかし、これを実現するにはPOLBの枠を超え、アプリケーションのアーキテクチャとインフラストラクチャの両方に不可欠な効率性をもたらす、アプリケーションルーティングと負荷分散の領域へ進む必要があります。これらの機能は、ネットワークスタックのレイヤー7（アプリケーション層）を基盤としており、現代のアーキテクチャではHTTPを意味します。

L7 LBプロキシは、接続負荷、応答時間、アプリケーションのステータスなどのアプリケーション変数に基づいて負荷を分散できるだけでなく、URL、HTTPヘッダー、さらにはHTTPメッセージ内のデータに基づいて振り分け（ルーティング）を行うこともできます。

現在のL7ロードバランサーは、こうしたさまざまな種類のアプリケーション層データを解析・抽出し、それに基づいて処理を実行できるため、次のような多様な方法でアプリケーションやマイクロサービスアーキテクチャに関与し、その機能を拡張できます。

• データパーティショニング（シャーディング）アーキテクチャ
• 複雑なURLディスパッチ
• レスポンスヘッダーを操作
• バックエンドデータに基づく動的ルーティング
• 機能分解によるスケーリング
• APIの使用量計測とアクセス制御

POLBの先へ：セキュリティ

L7 LBは、サービス対象のアプリケーションより論理的に上流に配置されるため、すべてのリクエストとレスポンスを可視化できます。これにより、リクエストが目的のアプリケーションへの転送を許可される前に、さまざまな検証や制御を実行できます。こうした検証や制御は、悪意のあるトラフィックを検出して拒否し、その悪影響がバックエンドアプリケーションの安定性、可用性、完全性に及ぶのを防ぐうえで不可欠です。

しかし、重要なのは不正なトラフィックがサーバーに到達するのを阻止することだけではありません。悪意のある攻撃者を阻止することも必要です。そのためには、有効な認証情報を持たない者だけでなく、そもそも本人のものではない認証情報を使用している者も識別できなければなりません。盗まれた認証情報に起因する侵害が増加するにつれ、アクセス制御の役割はますます重要になっています。また、クラウドの普及により、SaaSベースのアプリケーションに保存された企業データへのアクセスを許可する、孤立したアカウントやテスト用アカウントによる潜在的なリスクを軽減するため、アプリケーション全体で認証情報を一元的に管理する必要性が再び高まっています。IDフェデレーションは、単なる生産性向上のための戦略にとどまらず、企業全体のセキュリティ戦略における重要な施策となっています。

L7 LBに追加できる機能には、クライアントの行動やアイデンティティを分析する機能に加え、クライアントとバックエンドサービス間で交換されるメッセージの実際の内容を分析する機能も含まれます。これにより、L7 LBは次のような機能を実行できます。

• レイヤー7（アプリ）DDoS防御
• Webアプリファイアウォール
• OWASP Top 10
• アプリのアクセス制御
• フェデレーションID

POLBを超えて：最適化

パフォーマンスは、アプリケーション、ひいてはビジネスの成功を左右する重要な要素です。かつては、アプリケーション配信を高速化するために、アプリケーションの前段に複数のアプリケーション高速化ソリューションを導入していました。ADCも当初、同様のソリューションをオプションのアドオンコンポーネントとして取り入れていましたが、やがてその機能を中核となる負荷分散機能の一部として直接統合しました。これは、アプリケーションやサービスの配信というADCの中核的な役割において、パフォーマンスがいかに重要であるかを示しています。

そのため、L7 LBには、パフォーマンスの向上を目的としたさまざまな機能が備わっています。そのうち、特にクライアントに返されるアプリケーションのレスポンスを処理する機能は、コンテンツに重点を置いています。多くはコンテンツのサイズを縮小するための基本的な開発手法であり、その他はクライアントとサーバー間で必要となるラウンドトリップ回数の削減に重点を置いています。

また、L7プロキシはコンテンツの最適化だけに重点を置くものではなく、データベースの負荷分散技術やインメモリキャッシュ（memcachedなど）の統合によってアプリケーション全体のパフォーマンスを向上させる、パフォーマンス重視のアーキテクチャを実現するうえでも重要な役割を果たす点に留意する必要があります。このようなアーキテクチャの実現に適したL7プロキシでは、一般に、分散とルーティングを調整できるデータパススクリプト言語が利用できます。

その他の機能は、バックエンドサーバーのオーバーヘッドを削減してパフォーマンスを向上させることに加え、パフォーマンスのしきい値に基づいて負荷を分散することに重点を置いています。

L7 LBの最適化機能には、次のものがあります。

POLBの先へ：管理

インフラストラクチャをアプリケーションアーキテクチャにさらに統合するには、CI/CDパイプラインにも統合できることが不可欠です。つまり、最新のDevOpsやアジャイルに関連する手法と、リリースおよびデリバリー戦略の自動化を可能にするツールセットをサポートする必要があります。

そのため、L7 LBには、管理用のAPIだけでなく、監視およびデプロイのための手段も必要です。これにより、今日の厳しいスケジュールと予算の要件を満たすために、継続的なフィードバックとデリバリーを実現できます。

F5は、L7 LBインフラストラクチャのプロビジョニング、デプロイ、管理、監視に対応する、以下を含むさまざまなプログラム可能なオプションをサポートしています。

• RESTおよびSOAP API
• Chef、Puppet、Cisco、VMware、Electric Cloud、New Relic、Nagios、Ansible、Urban {code}などに対応するプラグイン
• スマートテンプレート

POLBの先へ：今こそ、その時

POLBやL7 LBなどのアプリケーションインフラストラクチャに対する責任が、ネットワークチームからアプリケーションチームや運用チームへ移行している背景には、さまざまな理由があります。より多くのアプリを短期間で提供したいというビジネスニーズに応えるためのアジャイルやDevOpsの導入、あるいは従来以上に迅速なスケーリングの必要性など、理由が何であれ、POLBの枠を超えることで、最新のCI/CDパイプラインに適合する、管理可能でプログラム可能な単一のプラットフォーム上で、最新のアプリケーションおよびデリバリーアーキテクチャを支えるために必要なセキュリティ、パフォーマンス、可用性について、より幅広い選択肢を得られます。

POLBの枠を超え、担当領域へと移行しつつあるインフラストラクチャの活用を検討するときです。

著者について

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

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

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