POLB (Plain Old Load Balancing) を超える
スケーラビリティは、ビジネスとアプリケーションの両方にとって重要な機能です。 ビジネス面では、運用のスケーリングが、新しいアプリ経済と、そのほぼ絶え間ない熱狂的な展開状態を可能にする鍵となります。 アプリケーション側では、スケーラビリティによって消費者と企業の両方の人口増加をサポートし、両方に最高のパフォーマンスと可用性を保証します。
スケーラビリティの中心となるのは負荷分散です。 1990 年代半ば以降、負荷分散は、ますます大規模化するサーバー、ネットワーク、アプリケーション、およびサービスのファーム全体にワークロードを分散することで、アプリケーションを拡張する方法となっています。
昔は、負荷分散はネットワークがすべてでした。 負荷分散は、ネットワークをスケールアウトする既存の技術とプロトコルに基づいて、ワークロードを分散するために使用できるクライアントとサーバー間の通信の側面に重点を置いています。 Plain Old Load Balancing (POLB) が誕生しました。
それはうまくいきました。 POLB がなければ、私たちが知っているような Web が実現したかどうかを知ることはほぼ不可能です。 それは、今日の企業や消費者を支え、また明日の企業や消費者を支えるために、当時も今も非常に重要なのです。
2000 年代初頭のある時期、ロード バランサの戦略的な配置により、ロード バランサは他のアプリケーション エクスペリエンスを強化する機能に拡張するのに最適なプラットフォームになりました。 最終的には、アプリケーションの高速化、最適化、キャッシュ、圧縮が追加されました。 セキュリティもこの同じプラットフォームに組み込まれることになりますが、ネットワーク内でのセキュリティの位置付けは無視できないほど完璧です。 アプリケーションのゲートキーパーとして、アプリケーション トラフィックを検査、抽出、変更、変換する機能により、パフォーマンスだけでなくセキュリティにも同様に適用される独自の洞察が得られます。
2000 年代初頭のある時期、私たちは POLB を超えて別の分野に進出しました。 ロード バランサは、POLB を使用してスケーリングするのと同じくらい安全で高速かつ利用可能なアプリケーションを配信できるアプリケーション配信プラットフォームになりました。
これらの最新プラットフォームは ADC (アプリケーション配信コントローラー) として知られており、POLB 機能だけでなく、今日アプリを展開するだけでなく配信する役割を担っている人々にとって非常に貴重な、実に豊富な機能を提供することができます。
ますます、ネットワーク チームではなく、アーキテクトと運用担当者が責任を負うようになっています。
この変化は、過去 10 年間に生まれた数々のテクノロジーによって推進されてきました。 アジャイルからクラウド、DevOps、モバイルまで、今日のベストプラクティスは、一部のアプリケーション サービスをネットワークからアプリケーションの領域へと押し出しています。
そして、スケーラビリティの責任がネットワークから設計者と運用者に移行しているにもかかわらず、ADC は 1990 年代のままであるかのように展開されています。 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 ベースのアプリケーションに保存されている企業データへのアクセスを許可する孤立したアカウントやテスト アカウントによる潜在的なリスクを軽減するために、アプリケーション全体でグローバルに資格情報を管理する必要性が再浮上しています。 アイデンティティ フェデレーションは単なる生産性向上戦略ではなく、企業全体のセキュリティ戦略における重要な戦術となっています。
L7 LB に追加できる機能には、クライアントの動作と ID を分析する機能と、クライアントとバックエンド サービス間で交換されるメッセージの実際の内容を分析する機能の両方が含まれます。 これにより、L7 LB は次のような機能を実行できるようになります。
- レイヤー 7 (アプリ) DDoS 保護
- Web アプリのファイアウォール
- OWASP トップ 10
- アプリのアクセス制御
- フェデレーションアイデンティティ
POLBを超えて: 最適化
パフォーマンスは、アプリケーションの成功、ひいてはビジネスの成功にとって重要な要素です。 以前は、組織は配信プロセスを高速化するために、アプリケーションの前に複数のアプリケーション高速化ソリューションを導入していました。 ADC はこれらの同じソリューションをオプション (アドオン) コンポーネントとして組み込んでいましたが、最終的にはこれらの機能をコア負荷分散機能の一部として直接統合しました。これは、アプリケーションとサービスの提供という中核的な焦点にとってパフォーマンスが重要であることを反映しています。
そのため、L7 LB にはパフォーマンスの向上に重点を置いたさまざまな機能が備わっています。 これらの機能の一部、特にクライアントに返されるアプリの応答に基づいて動作する機能は、コンテンツに重点を置いています。 これらの多くは、コンテンツを小さくするために使用されるコア開発者テクニックですが、クライアントとサーバー間の必要なラウンドトリップの回数を減らすことに焦点を当てたものもあります。
また、L7 プロキシはコンテンツの最適化だけでなく、データベースの負荷分散技術やメモリ内キャッシュ (memcached など) の統合など、アプリケーション全体のパフォーマンスを向上させるパフォーマンス重視のアーキテクチャを実現する重要な要素でもあることに注意することが重要です。 これらのアーキテクチャを有効にするのに適した L7 プロキシは、通常、配布とルーティングをカスタマイズする機能を提供するデータ パス スクリプト言語を使用して有効になります。
その他の機能は、パフォーマンスを向上させる方法としてバックエンド サーバーのオーバーヘッドを削減することや、パフォーマンスしきい値に基づいて負荷を分散できることに重点を置いています。
L7 LB の最適化機能と機能には以下が含まれます。
クライアント側（レスポンス最適化） |
バックエンドサーバー側 |
• 縮小 • HTTP 圧縮 • バッファリング • スクリプトの集約 • SSL オフロード |
• TCP多重化 • キャッシュ • パフォーマンスベースの負荷分散 • 自動スケーラビリティ |
POLBを超えて: 管理
インフラストラクチャをアプリケーション アーキテクチャにさらに統合する場合は、必ず CI/CD パイプラインに統合できる必要があります。 つまり、最新の DevOps および Agile 関連の方法論と、自動リリースおよび配信戦略の実行を可能にするツールセットをサポートするということです。
そのため、L7 LB は、管理できる API だけでなく、今日の厳しいスケジュールと予算に合わせて継続的なフィードバックと配信が確実に行えるように監視および展開できる手段も提供する必要があります。
F5 は、L7 LB インフラストラクチャのプロビジョニング、展開、管理、監視のためのさまざまなプログラム オプションをサポートしています。
POLBを超えて: 時間だ
POLB や L7 LB などのアプリケーション インフラストラクチャの責任がネットワーク チームからアプリケーション チームや運用チームに移行されている理由はさまざまです。 より多くのアプリをより短い配信期間で提供するというビジネス上の需要への対応としてアジャイルや DevOps を採用する場合でも、これまで以上に迅速に拡張する必要性がある場合でも、POLB を超えると、最新の CI/CD パイプラインに適合する単一の管理可能でプログラム可能なプラットフォーム上で最新のアプリと配信アーキテクチャをサポートするために必要なセキュリティ、パフォーマンス、可用性のオプションがより幅広く提供されます。
今こそ、POLB を超えて、ますます自分の領域に入りつつあるインフラストラクチャを活用し始めることを検討するときです。
