F5 と AWS: クラウドでの高度なapplication配信サービス

Amazon Web Services (AWS) は、パブリック クラウド Infrastructure-as-a-Service (IaaS) の最大かつ最も普及したプロバイダーになりました。 組織は、オンプレミスのインフラストラクチャを購入したり再構成したりすることなく、applicationスタック全体を構築、テスト、展開できるようになりました。 運用applicationsは、Webapplicationファイアウォール (WAF)、SSL アクセラレーション、コンテンツ ベース ルーティング、負荷分散、DDoS 軽減、ID およびアクセス管理、プロトコル アジリティなどの高度なapplication配信サービスからメリットを得ることができ、これらの重要なapplicationsをより高速、スマート、安全に実行できます。 クラウドネイティブの AWS 導入では、F5 ソリューションにより、これらのapplicationサービスを AWS クラウド環境にシンプルかつ簡単に提供できます。

IaaS プロバイダーとして、Amazon Web Services (AWS) は、applicationsを開発するのに十分なレンタルコンピューティングインフラストラクチャを提供しています。 資本支出や維持費を一切かけずに、完全なapplicationスイートを開発して展開できます。 AWS は、オンプレミスにあるようなコンピューティング インフラストラクチャの提供に加えて、applicationサービスを提供し、インフラストラクチャを自動的に拡張し、多くの場所でapplicationsをホストします。 これらの追加機能のため、AWS のベストプラクティスは、従来のデータセンターのベストプラクティスとは異なります。 AWS と従来のデータセンターの違いをよりよく理解するには、AWS がどのようにサービスを提供しているかを理解することが重要です。

AWS から最大限のメリットを得るには、地理的分散、コンピューティング インスタンス、ネットワーク、ストレージの概念など、IaaS サービスのいくつかの重要な属性を見てみましょう。

AWS を理解するには、リソースがどのように分散されているかを物理的に説明することから始まります。 最上位レベルでは、AWS には複数のリージョンがあり、それぞれのリージョンは米国東部などの広い地理的領域をカバーしています。 各地理的リージョンには複数の可用性ゾーンが含まれており、相互に障害が発生しないように設計されているため、このように呼ばれています。 1 つのアベイラビリティ ゾーン (AZ) で障害が発生しても、リージョン内の別の AZ に障害が波及することはありません。 各 AZ は分離されていますが、リージョン内の AZ は低遅延のネットワーク リンクを介して接続されます。 可用性を目的として、リージョン内の複数の AZ にわたる冗長機能の設計パターンが存在します。

コンピューティングインスタンスは、Amazon マシンイメージ (AMI) と呼ばれるソフトウェア ディスク イメージとして始まります。 各 AMI は不変であり、それを使用するコンピューターによって読み取り専用になります。 AMI に対してコンピューティング インスタンスを起動すると、クラウド内に実行中の仮想マシンが作成されます。 コンピューティング インスタンスの仮想ハードウェア特性は、インスタンスで使用可能な CPU の数や RAM など、さまざまです。

各コンピューティング インスタンスは仮想プライベート クラウド (VPC) 内に存在し、これは物理世界の LAN にほぼ相当します。 各 VPC は論理的に分離されています。 VPC は、サブネット間の暗黙的なルーティングを持つ複数のサブネットで構成できます。 パブリック サブネットはインターネットからルーティング可能ですが、プライベート サブネットは内部でのみ利用可能です。 完全なapplicationをデプロイするには、1 つ以上のコンピューティング インスタンスを VPC 内にデプロイします。コンピューティング インスタンスまたはロード バランサーに DNS エントリが割り当てられている場合、VPC 間の通信が可能になります。

前述のように、各 AMI はそれを使用するインスタンスからは変更できません。 永続的なストレージについては、AWS は主に Simple Storage Service (S3) と Elastic Block Storage (EBS) を中心に、さまざまなソリューションを提供しています。 S3 は、オブジェクトを名前で保存し、アクセスできるオブジェクト ストレージ サービスです。 オブジェクトのサイズは 0 バイトから 5 TB までの範囲になります。 実際、各 AMI は暗黙的に S3 オブジェクトです。 オブジェクトは変更できず、作成と削除のみ可能なため、写真や仮想マシンのイメージなど、比較的静的なコンテンツに最適です。

EBS は、従来のストレージに似たストレージを提供します。 EBS に接続されたコンピューティング インスタンスは、EBS を従来のハード ディスクとして認識します。 一度に接続できる実行中のインスタンスは 1 つだけなので、EBS を共有ストレージとして使用することはできません。

AWS は、主要なインフラストラクチャコンポーネントの提供に加えて、applicationのスケーリングを可能にする追加サービスも提供します。 AWS はインフラストラクチャリソースを迅速にプロビジョニングできるため、Amazon はそれらのリソースの自動スケーリングと負荷分散を可能にするソリューションを開発しました。

AWS は Elastic Load Balancing (ELB) サービスを提供します。 当初、ELB は、プール内の複数の正常なノードにトラフィックを分散する、レイヤー 4 で動作する単純なロード バランサーを指していました。 プールは複数のアベイラビリティーゾーンにまたがることができ、1 つのアベイラビリティーゾーンで障害が発生した場合でも自動的に冗長性が確保されます。 このロード バランサは基本的なネットワーク レイヤー 7 機能を提供しますが、主にレイヤー 4 で動作し、プール内のノードに TCP トラフィックをラウンドロビン方式でルーティングするだけです。 ヘルス チェックでは、どのノードが利用可能で、トラフィックの候補となるかを判断します。 AWS では、新しいApplication Load Balancer (ALB) と区別するために、この初期ロードバランサーを Classic Load Balancer と呼ぶようになりました。

AWS にはスタンバイ容量が用意されているため、プール内のノードをスケーリングするオプションを提供できます。 AWS CloudWatch サービスは、プール内の各ノードのパフォーマンスメトリクスを監視します。 事前定義されたしきい値（CPU 使用率が 5 分間で 60% を超えるなど）を超えると、別のノードがプロビジョニングされます。 逆に、下限しきい値を超えると、ノードは削除されます。 設計者は、プール内のノードの最大数と最小数、およびノードのインスタンス化またはノードの削除をトリガーするしきい値を決定できます。 ロード バランサーの背後で自動スケーリングを使用すると、負荷に応じてノード プールを必要に応じて拡張または縮小できます。

applicationsはビジネス ルールとロジックを処理しますが、大規模な本番環境の展開、管理、および運用に必要な強化が不足していることがよくあります。 F5 ソリューションは、以下の表に詳述する高度なapplication配信サービスを提供することで、applicationsの高速化、スマート化、安全性の向上を実現します。

F5 高度なapplication配信サービス

アプリケーションレベルの監視

• 高度なapplicationヘルスチェック（複数ステップモニターを使用）
• 複数レベルのヘルスチェック（データベースとapplicationの両方が利用可能かどうかのチェックなど）
• HTTP 以外のヘルス チェック (SIP、Microsoft Windows SQL Server、FTP など)
• 最も適切に機能するサーバーにトラフィックをより適切に分散する高度なアルゴリズム

グローバルな利用可能性

• さまざまなクラウド プロバイダーやデータ センターの混在環境におけるapplicationの可用性
• BIG-IP アドバンスドモニターとの統合
• DNSSec サポート

高度なapplication配信サービスにより、applicationsの可用性とセキュリティを高めながら、より高いレベルでのパフォーマンスを実現できます。 これらのサービスは、各applicationから独立した戦略的な制御ポイントに存在できます。 サービスをapplicationのビジネス ロジックから分離することで、インフラストラクチャ、管理、パフォーマンスに関する懸念を開発チームに負担をかけることなく、applicationsがビジネス ニーズを満たすことができます。 戦略的な制御ポイントにより、ガバナンスの問題を各applicationから独立して均一に処理することもできます。

F5 は、AWS インフラストラクチャとのクラウドネイティブな統合を提供することで、組織が AWS 導入を最大限に活用し、applicationsのパフォーマンス、可用性、セキュリティを向上できるようにします。 次のセクションでは、AWS と F5 がどのように連携するかについて説明します。

サーバー インスタンスが汎用イメージから起動する場合、多くの場合、パラメータを変更したり、ホスト名や IP アドレスなどの構成を設定したりすることが適切です。 クライアント マシンでは、これらのパラメーターは DHCP 経由で設定されますが、サーバー パラメーターを DHCP 経由で設定すると、問題が発生することがよくあります。 ネットワーク設定以外にも、特定のインスタンスでは特定のソフトウェア パッケージや特定のソフトウェア構成が必要になる場合があります。

BIG-IP の導入の場合、管理者は、BIG-IP Local Traffic Manager (LTM) の仮想サーバーとプールの構成、BIG-IP Application Security Manager の特定の WAF 構成、または BIG-IP Advanced Firewall Manager のファイアウォール設定など、各モジュールの構成を自動化したい場合があります。 サーバー インスタンスをインストールするすべてのユーザーが同じ問題に直面します。つまり、ベース イメージが正しく機能するには追加の構成が必要です。

AWS では、インスタンスを構成するための主なアプローチとして、新しい AMI を作成する方法と、cloud-init を使用してブートプロセス中にサーバーを変更する方法の 2 つを提供しています。 頻繁に更新される可能性が低い、複数のインスタンスに共通する変更の場合は、新しい AMI を作成する方が適しています。 対照的に、cloud-init は、より少数のインスタンスに影響し、寿命が短い変更に適しています。

長期間にわたって持続すると予想される変更、および複数のインスタンスに共通する変更の場合、適切な方法は、目的の構成に類似した AMI からマシンを起動して新しい AMI を作成することです。 管理者が実行中のインスタンスに必要な変更を行った後、インスタンスは停止され、新しい AMI が生成されて AWS に登録されます。 この AMI から起動する今後のすべてのインスタンスには、変更がすでに適用されています。 このアプローチでは変更が実質的に永続的になるため、また新しい AMI の生成には時間がかかる可能性があるため、AMI に組み込まれる変更は通常、長期間持続し、複数のインスタンスで使用できるものになります。 AMI を使用するもう 1 つの理由は、一部の cloud-init プロセスは時間がかかる可能性があるため、AMI を使用すると起動時間が短縮されることです。

新しい AMI に組み込むのに適さない必要な変更は、インスタンスが起動するたびに基本的に起動スクリプトを有効にする cloud-init に適しています。 cloud-init を使用すると、インスタンス固有のシンプルな変更をインスタンスに埋め込むことができます。

cloud-init の欠点としては、パッケージのインストールなどの構成変更を起動時に実行する必要があり、起動に時間がかかることが挙げられます。 起動時間が長くなると、自動スケーリングが効果的でなくなる可能性がある自動スケーリングのシナリオでは、起動時間が長くなると実際の影響が出ます。 これらの理由から、時間のかかる変更は、cloud-init 経由で変更するのではなく、新しい AMI に含める必要があります。

変更がすべてのインスタンスではなく複数のインスタンスで使用できる場合、構成の管理も面倒になる可能性があります。 たとえば、特定の BIG-IP デプロイメントが、特定の仮想サーバ構成を持つ自動スケール グループで使用されているとします。 単一の AMI をこれらのマシンに使用し、別の AMI を別の自動スケール グループ内の他の BIG-IP マシンに使用することもできます。 各自動スケール グループに単一の AMI を使用すると、cloud-init プロセス内で各ホストに固有の変更のみが必要になります。 グループに共通する変更はすべて AMI に埋め込むことができます。このアプローチの欠点は、すべてのマシンに共通する変更ごとに AMI を更新する必要があることです。

applicationsは、通常、複数のユーザーに同時に機能を提供します。 applicationが成功すると、それが実行されるコンピューターの容量を超える可能性があります。 applicationのニーズがコンピューターのニーズを超えた場合は、容量を増やすオプションを評価する必要があります。 スケーリングには、スケールアップ、パイプライン、スケールアウトという 3 つの一般的なアプローチがあります。

スケールアップは、既存のコンピューターをより高速なコンピューターに置き換えるだけなので、容量を増やす最も簡単な方法です。 より高速なコンピュータをインストールすると、applicationやインフラストラクチャに変更を加えなくても、applicationのあらゆる側面とコンピュータ上のその他のサービスが高速化されます。 スケールアップの欠点は、パフォーマンスの向上に伴ってコストが指数関数的に増加する傾向があり、収益が減少する点です。 しきい値を超えると、スケールアップはコストがかかりすぎるようになります。

パイプライン化は、組み立てラインと同様に、ワークロードを連続したステップに分解した結果です。 異なるコンピューターが各ステップでそれぞれ独立して動作できる場合、全体的なスループットを向上させることができます。 ただし、パイプライン化によってスループットが向上するだけであり、多くの場合、レイテンシが犠牲になります。 言い換えると、パイプライン化により全体的なパフォーマンスは向上しますが、単一のユーザーまたは単一のリクエストのパフォーマンスは低下する可能性があります。 パイプライン化のもう 1 つの欠点は、分解可能なワークフローを深く理解する必要があり、その理解に合ったインフラストラクチャが必要になることです。 これは、インフラストラクチャの決定をビジネス ロジックに密接に結び付けており、多くの組織がやろうとしていることとはまったく逆です。

スケールアウトでは、applicationとコンピューターをそのままにして、代わりにサーバー プール全体にリクエストを均等に分散することを選択します。 applicationsは通常、複数の独立した要求を同時に処理するため、要求は同一のapplicationサーバーのプール全体に安全に分散できます。 スケール アウトには、プール メンバーのいずれかに障害が発生してもapplication全体が停止しないという冗長性の利点が追加されます。 スケールアウトの欠点は、プール内のノード間でリクエストが均等に分散されるようにするために、applicationの外部で複雑なオーケストレーションが必要になることです。

AWS オートスケールは、スケールアウトアプローチを使用して、必要なapplicationsの容量を増やします。 CloudWatch サービスはプール内のノードを監視します。 ノードが事前定義されたしきい値を超えると、CloudWatch は必要に応じて新しいノードを自動的に起動するか、プール内のノードをシャットダウンします。 BIG-IP プラットフォームでは、このプロセスは、BIG-IP インスタンスの数を変更するか、単一の BIG-IP インスタンスの背後にあるプール内のノードの数を変更するという 2 つの方法のいずれかで実行できます。 2 つのアプローチの違いは、スケーリングの対象が BIG-IP インスタンスかプールかによって異なります。

最初のシナリオでは、BIG-IP プールが ELB デバイスのペアの間に配置されます。 最初の ELB デバイスは BIG-IP メンバーのインスタンス化と終了を制御し、2 番目の ELB デバイスは各 BIG-IP インスタンスのサーバー プール内の唯一のエントリです。 このアプローチは、BIG-IP インスタンスが SSL 終了や Webapplicationファイアウォールとしての動作などの高度なapplication配信サービスを提供している場合に適しています。 最初の ELB デバイスは、負荷分散を実行すると同時に、必要に応じてプールを拡大または縮小します。

2 番目のシナリオでは、バックエンド プール メンバーの数は CloudWatch を介して増減しますが、BIG-IP インスタンスが負荷分散を実行します。 BIG-IP インスタンスは AWS と通信して、プールに追加または削除されるノードを検出します。 このアプローチは、iRules スクリプト言語などの高度な負荷分散機能を使用する場合や、URL またはコンテンツに基づいてリクエストを送信する場合に適しています。 このような場合、バックエンド プール内のサーバーの負荷を管理するには、単一の BIG-IP インスタンスで十分です。

BIG-IP インスタンスは、少なくとも 2 つのシナリオで AWS インフラストラクチャと対話する必要があります。 まず、マルチゾーン AWS デプロイメントでは、AWS Elastic IP の背後にある IP アドレスを変更する必要があります。 次に、BIG-IP インスタンスは、プール内のサーバーをスケールアップおよびスケールダウンする AWS CloudWatch サービスによって追加および削除されたプール メンバーを可視化する必要があります。 インフラストラクチャとの各やり取りは API 呼び出しを介して行われ、API 呼び出しを行う他のソフトウェアと同様に、BIG-IP インスタンスは AWS に対して認証する必要があります。 一般的に、AWS への認証には、認証情報を使用する方法と IAM ロールを使用する方法の 2 つがあります。

認証を行う最も簡単な方法は、API 呼び出しに適切な資格情報を含めることです。 AWS 認証情報は、ユーザー名とパスワードにほぼ相当するアクセスキーとシークレットキーで構成されます。 管理者は資格情報を生成し、開発者はそれをapplication内に埋め込みます。 これにより、applicationは適切な API 呼び出しにアクセスできるようになります。

シンプルですが、applicationに資格情報を埋め込むとセキュリティ上のリスクが伴います。 開発者がapplication内の資格情報を保護しないと、他の人やソフトウェアがそれを復元し、悪意のある方法で使用する可能性があります。 このアプローチでは、ソフトウェアを変更せずに資格情報を変更することも困難になります。 資格情報を使用することは迅速なテストには適切なアプローチですが、実稼働ソリューションでは認証に別のアプローチを使用する必要があります。 このため、AWS のベストプラクティスでは、applicationに保存された認証情報を使用しないことが推奨されています。

API 呼び出しの認証に対するより安全なアプローチは、IAM ロールを使用することです。 AWS Identity and アクセス管理 (IAM) を使用すると、ユーザーは AWS インフラストラクチャへのアクセスを管理できます。 BIG-IP マシンなどの任意のコンピューティング インスタンスに、特定の機能セットを承認する IAM ロールを割り当てることができます。 インスタンスが起動すると、IAM はインスタンスの一時的な認証情報セットを生成します。 これらの資格情報はインスタンスが機能している間有効となり、指定された API 機能のみが有効になります。 IAM ロールが設定されている場合、BIG-IP インスタンスは資格情報を保存せず、必要なインフラストラクチャ API のみにアクセスできるため、資格情報ベースの認証よりも高いセキュリティが提供されます。

前述したように、AWS データセンターは地理的リージョンに存在し、各リージョンはアベイラビリティーゾーン (AZ) に存在できます。 リージョン内の各 AZ は他の AZ と何も共有しません。つまり、電力、ネットワーク、建物は共有されません。 実際、各 AZ は地域内で他の AZ から地理的に分離されています。 ゾーン間の分離により、AWS サブスクライバーは、ある AZ に影響を与えるイベントが別の AZ に影響を与えないことを確信できます。 つまり、原則として、リージョン内の最大 1 つの AZ が、どの時点でも使用不可になるはずです。 つまり、2 つ以上の可用性ゾーンに展開されたサービスは継続的に利用可能である必要があります。

BIG-IP プラットフォームは、コンピューティングインスタンスに本質的に関連付けられていない IP アドレスである AWS Elastic IP を使用して、AWS AZ 全体の高可用性をサポートします。 代わりに、IP アドレスは実行中のコンピューティング インスタンスのプライベート IP アドレスに動的に転送できます。 マルチゾーンの高可用性を実現するために、BIG-IP インスタンスとapplicationサーバーの同一のセットがそれぞれ独自の AZ に配置されます。 最初に、Elastic IP は BIG-IP インスタンスの 1 つに割り当てられます。 各クライアントから Elastic IP への接続が確立され、Elastic IP はそれを BIG-IP インスタンスの 1 つにあるプライベート IP アドレスに転送します。 障害が発生した場合、他の BIG-IP インスタンスが AWS に API 呼び出しを行って責任を主張し、Elastic IP アドレスをそのインスタンスに転送するよう要求します。

BIG-IP プラットフォームは、ELB と統合することで、複数の AZ や BIG-IP ノードの自動スケーリングなどの AWS 機能とシームレスに統合されたapplicationサービスを提供できます。

ELB を BIG-IP インスタンスの前に配置すると、ELB が BIG-IP インスタンスがapplicationサービスを提供している各 AZ 内の個々のapplicationスタックへのトラフィックをシームレスに分散できるため、複数の AZ にわたる展開が簡素化されます。 このアプローチにより、複数の AZ 間での負荷分散が簡素化されます。

BIG-IP インスタンスの弾力性が必要な場合、自動スケール機能を備えた ELB は、BIG-IP 仮想アプライアンスのプールを自動的にスケールアップおよびスケールダウンし、Webapplicationファイアウォール、ID 管理、SSL 終了などのapplicationサービスを提供します。 ELB サンドイッチを使用すると、トラフィックは最初の ELB にルーティングされ、そこでトラフィックが BIG-IP インスタンスのプールに分散され、自動的にスケーリングされます。 BIG-IP プール全体の構成を簡素化するために、各 BIG-IP インスタンスにはサーバー プール内に 1 つの ELB アドレスがあります。 次に、2 番目の ELB はトラフィックをダウンストリーム サーバー プールにルーティングします。

ELB と BIG-IP トポロジのさまざまな組み合わせにより、どちらか一方だけでは利用できない自動スケーリング、可用性、applicationサービスが提供されます。 ELB と BIG-IP プラットフォームの両方の利点を活用することで、アーキテクトは特定の展開に必要なレベルのサービスを提供できます。

繰り返し可能なスクリプト化されたデプロイメントを可能にするために、AWS はデプロイメントと継続的な管理の両方を簡素化する Cloud Formation Templates (CFT) を提供します。 目的のサービスまたはapplicationアーキテクチャの CFT を作成すると、AWS はそれを使用してapplicationを迅速かつ確実にプロビジョニングできます。 CFT は DevOps 環境で特に役立ち、チームがテストと本番環境展開のための繰り返し可能なプロセスを簡単に作成できるようになります。

F5 は、CFT を使用して BIG-IP インスタンスを展開することをサポートするだけでなく、一般的な BIG-IP 展開用の参照 CFT ファイルをいくつか提供します。

参照 CFT ファイル内のパラメータを調整すると、BIG-IP インスタンスや BIG-IP インスタンスの背後にあるバックエンド サーバーの自動スケーリング、さらに複雑なシナリオなど、さまざまなシナリオで BIG-IP ソリューションをスクリプト化して展開できるようになります。 CFT と F5 ソリューションを使用して AWS 内で繰り返し可能なデプロイメントを自動化することで、複雑なapplication環境を迅速かつ簡単にデプロイできます。

もちろん、テクノロジーは十分に活用できなければほとんど役に立ちません。 そのために、F5 は広範なドキュメントを提供しています。 BIG-IP プラットフォーム全般および AWS 内の BIG-IP インスタンスの詳細に関するドキュメントが利用可能です。 あらゆる質問に対する良い出発点はAsk F5です。

ドキュメント タブには、特定の BIG-IP モジュールに関する情報と、AWS 統合に関するセクション全体が表示されます。 AWS ポータルは、開始から複雑なデプロイメントシナリオに至るまで、ドキュメント、記事、コミュニティ、リソースを検索できるインターフェイスを提供します。

ドキュメントで回答されていない質問については、 F5 DevCentral コミュニティが回答とサポートを提供します。

パブリック クラウドの導入に向けた動きはもはや一時的な流行ではなく、IT における永続的なトレンドです。 Amazon Web Services は、世界最大かつ最も包括的なパブリッククラウド サービスのプロバイダーとして、オンプレミスの機器を使用せずにapplicationsを構築、テスト、展開する機能を組織に提供します。 F5 は、高度なapplication配信サービスを AWS エコシステムの一部として利用できるようにし、AWS クラウド環境でアプリケーションがより高速、スマート、安全に動作するように構成しました。