アプリケーションの用途、プラットフォーム、テクノロジは多岐にわたりますが、ほとんどのアプリケーションで共通するニーズがあります。それはアプリケーションを常にオンライン状態に保ち、ハードウェア障害から保護し、需要に応じてスケーリングし、セキュリティ侵害や攻撃から守られなければならないという点です。
アプリケーションがメインフレーム コンピュータからオープン システムに移行し始めて以来、組織はロード バランサを使用してアプリケーションの拡張性と可用性を管理してきました。複雑な問題や巧妙なセキュリティ脅威に直面するたびに、ロード バランサによってより多彩な機能セットが開発され、セキュリティと最適化の機能が増強されてきました。
時間の経過とともにシンプルだったロード バランサは強力なアプリケーション デリバリ コントローラ(ADC)へと進化していきました。世界中で何千もの組織がADCを使用して、私たちの生活を支えるアプリケーションを安全で速く、可用性の高いものへと進化させています。救急医療や銀行取引からゲーム、出会い系サービスまでADCはアプリケーションのパフォーマンスを最大限に高めるテクノロジを提供しています。
アプリケーションが従来のオンプレミス モデルからクラウド サービスに移行しても、規模、セキュリティ、可用性に対するニーズが減ることはありません。そのため、パブリック クラウドでもプライベート クラウドでもすべてのクラウド プラットフォームが、その中核的なInfrastructure-as-a-Service(IaaS)製品の一貫としてロード バランシング サービスを提供していることは当然と言えます。
Amazon Web Services(AWS)のElastic Load Balancing(ELB)サービスを利用して、組織はインターネット上最大級のアプリケーションを含む何十万ものアプリケーションを展開しています。オンプレミスのロード バランサが顧客のニーズを満たす機能を追加したように、AWSのロード バランシング サービスによって新しい機能が次々と組み込まれています。
多くの組織にとってELBは最適な選択肢ですが、重要なアプリケーションを最適にサポートするために追加機能を必要とする組織もあります。また、既にADCとロード バランサを導入してオンプレミス アプリケーションをスケーリングし、管理している企業もあります。これらの組織では、データ センタと同じプラットフォームをAWSに導入することでクラウドへの移行の時間、コスト、リスクを削減できます。組織にとってどのロード バランシング サービスが適切なのか判断する前に、AWSで利用可能なさまざまなロード バランシング オプションを見ていきましょう。
Amazon Web Servicesは主なIaaSプロバイダの中で最も広範なサービス セットを提供し、シンプルなコンピューティングとブロック ストレージから高度なデータベース、機械学習環境まで、膨大な機能と用途を網羅しています。多くのAWS顧客のアーキテクチャの主要コンポーネントはロード バランサであり、その中でもAWSは仮想プライべート クラウド(VPC)環境用として2つのサービス(いずれも「Elastic Load Balancing」という名称で提供)を提供しています。
AmazonのApplication Load Balancer(ALB)は、AWSクラウドでのロード バランシング、稼働状況の監視、URLベースの要求のルーティングを行います。ALBはいずれかのAWS証明書管理サービスからロードされた顧客のSSL証明書を使用してHTTPおよびHTTPSプロトコル ロード バランシングを提供し、さらにWebSocketトラフィックのロード バランシングもサポートします。またALBではバックエンドのElastic Compute Cloud(EC2)サーバーのリソースのオート スケーリングにも対応しています。トラフィック需要が増えるとALBは追加のサーバーを導入し、需要が減るとサーバーを削除します。
負荷の増加に対応してALBサービスも拡張されます。アプリケーションのネットワーク トラフィックが増えると、追加のALBインスタンスが作成されてDNSに登録され、DNSラウンド ロビンを使用してALBインスタンスにトラフィックが分散されます。ワークロードが突発的に急増しても最大限のパフォーマンスを発揮するには、ALBインスタンスを暖気運転しておくことをお勧めします。新しいインスタンスのスピンアップには1~7分かかります。
ALBはWebコンソール、CLI、API、クラウド フォーメーション テンプレート(CFT)、さらにAnsibleなどの多くの自動化ツールを使用して導入できます。
AWSのEastic Load Balancingファミリに新たに追加されたのがNetwork Load Balancer(NLB)です。「Classic」Load Balancerと同様にNLBはレイヤ4で動作し、接続ベースのロード バランシングとネットワーク層およびアプリケーション層のヘルス チェックを行います。NLBはトラフィックの急増と大量の接続に対処できるよう設計されています。またNLBではターゲットをRFC 1918プライベートIPアドレスやEC2インスタンスにすることができます。オートスケーリング、セルフスケーリング、導入オプションはALBと同様です。
AWSは引き続き「従来の(Classic)」Elastic Load Balancerを提供しており、このバランサではTCPトラフィック用の基本的なレイヤ4のロード バランシングはサポートしていますが、レイヤ7のトラフィック バランシングやトラフィック ステアリングはサポートしていません。オートスケーリング、セルフスケーリング、導入オプションはALBと同様です。
F5® BIG-IP® ADCプラットフォームはロード バランシングでは軽量なAWS Classic Load Balancerとは対照的です。BIG-IPはセキュリティ、アプリケーションの最適化、可用性などさまざまな課題に対応するための一連の機能を備え、簡素なソリューションでは対処できない問題を解決してアプリケーション トラフィックを管理できます。
BIG-IPは完全なトラフィック検査、制御、操作を含む包括的なアプリケーション トラフィック管理を提供します。これはアプリケーション層の要求と応答にまで及び、データ損失を防止してサーバー応答のコンテンツの操作を可能にします。この機能は高速で信頼性が高く重要な問題解決ツールとして数千という組織で使用されています。またアプリケーション トラフィックの検査と操作を完全にプログラムできるので、開発者は追加のアーキテクチャ層として利用して重要な戦略的制御点でのアプリケーションの動作を強化できます。
このようにプログラム可能であっても、この問題解決機能にはいくつかの問題があることを理解しておく必要があります。まず、BIG-IPはAWSのClassic Load BalancerとALBとは異なるインフラストラクチャ レベルで動作します。BIG-IPはVPC内にEC2インスタンスとして導入されますが、これにはメリットとデメリットの両方があります。VPCに組み込まれることで、ADCはアベイラビリティ ゾーン内のすべてのコンポーネント間のトラフィックを効率的に管理し、ユーザーはVPC内のコンポーネント間の通信を詳細に制御することができます。
同時に、これにより管理および保守対象となるEC2インスタンスが増えます。簡単に構成できますが、ミッションクリティカルなコンポーネントの可用性を高められるかどうかはユーザーにかかっています。ソフトウェアの更新と一般的な管理という点では基盤となるプラットフォームの管理はAWSではなく顧客が行い、基本的にシームレスなサービス アップグレードとは異なり、新しい機能はAWS Marketplaceにリリースされたバージョンとして配信されます。
さらにBIG-IPはオンデマンドでスケーリングすることも、アプリケーション サーバー インスタンスのオートスケーリングを行うこともできますが、ほとんどの場合、AWSコア サービスを使用する場合と比べて構成作業の多くが必然的に顧客の責任となります。
組織に適切なソリューションはアプリケーションとプラットフォームのニーズによって基本的に異なります。AWS ELBに適したアプリケーションとユース ケースもあれば、BIG-IPの高度な機能を必要とするものもあります。
ALBは基本的なURI/宛先マッピング ルールを使用したシンプルなロード バランシングを必要とするアプリケーション向けに設計されています。ALBは多くのAWSネイティブ アプリケーション向けの基本的なトラフィック分散およびスケーリング サービスに対応します。開発者やアプリケーション サプライヤがセキュリティや機能上の問題を適宜修正できる場合やセキュリティ侵害のリスクが全体的に低い場合はALBがお勧めです。
他のTCPプロトコルを使用し、堅牢でもシンプルなロード バランシング サービスが必要な同様のアプリケーションには多くの場合、Classic Load Balancerで十分です。
他に、AWSの本格的なADCを活用したいユース ケースがあります。AWSでBIG-IPを使用するメリットの一部を以下に挙げます。
BIG-IPのプラットフォーム アーキテクチャを使用すると、アプリケーション トラフィックを完全に可視化して制御できます。AWS環境内のBIG-IPインスタンスは広範な機能を備え、アプリケーション パフォーマンス、セキュリティ、可用性の問題に対処するための強力なツールキットを提供します。BIG-IPはルーティング可能なリソースに対する個々のアプリケーション層の要求を、ローカルのEC2インスタンスや別のクラウド内のサーバー インスタンスからAPIベースのサービスやオンプレミスのデバイスに転送することができます。
例えば、ALBでは要求されたURLに基づいてバックエンド リソースにトラフィックをステアリングできますが、デバイス タイプや接続速度、クライアントの場所といったさらに複雑な特性に基づいてトラフィックをステアリングする必要がある場合はBIG-IPの方が適しています。
このような高度な問題解決機能は、エンタープライズ アプリケーションをクラウドに移行する場合やアプリケーションの脆弱性や動作の問題を開発者がすぐに緩和できない場合に重要になります。アプリケーションを緊急に保護しなければならない場合やクライアント タイプが新しいため(またはクライアントのオペレーティング システムが変更されたため)にアプリケーションが誤動作する場合、特定の要求でアプリケーションがクラッシュする場合などに、BIG-IPならそれらの問題の多くを迅速、シンプル、かつ確実に解決します。
もう一つ重要なのがデータ センタとクラウド間の一貫性に対するニーズです。何千もの組織がBIG-IPデバイスを使用してデータ センタに重要なアプリケーションを展開しています。AWS BIG-IP Virtual Editionでは、データ センタに物理的にBIG-IPを配置する場合と同じアプリケーション層サービスをAWS上に配置します。BIG-IP VEを使用することで組織はアプリケーションを迅速かつ低コストで自信をもって移行することができ、スタッフは新しい技術の習得に専念することができ、さらにBIG-IPに対する組織的知識と投資を維持できます。
ネイティブ サービスであるAWS ELBを導入するにはボックスを選択するだけです。AWSでBIG-IP VEを稼働させるには、従量課金モデルまたはBring-Your-Own-Licenseモデルのいずれかを使用してAmazon Marketplaceからインスタンスを導入する必要があります。BIG-IPイメージの導入は手動で行うことも、AWS CFTなどの自動化オプションを使用して行うこともできます。F5は完全にサポートされたテンプレート一式(一部「試験」版を含む)を提供しています。これらはF5のGitHubリポジトリから入手可能です。このリポジトリにはPython SDKやその他のツールも用意されています。その他のコミュニティ支援導入ツール、プレイブック、ドキュメントはF5のDevCentralリポジトリから入手可能です。
AWS ELBとF5 BIG-IPはいずれもAWSにアプリケーションを導入しようとしている組織に説得力のある価値を提供します。制御、セキュリティ、プログラム可能性がいつどこで必要になるかを知ることで、クラウド内のアプリケーションとビジネスをサポートするのに適切なソリューションを選択できます。