Classic Load Balancer の移行 - Elastic Load Balancing
移行のメリット移行ウィザードコピーユーティリティによる移行手動移行

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

Classic Load Balancer の移行

Elastic Load Balancing は、Application Load Balancer、Network Load Balancer、Gateway Load Balancer、Classic Load Balancer などのロードバランサーをサポートします。各ロードバランサータイプの機能の違いの詳細については、Elastic Load Balancing 製品の比較を参照してください。

VPC 内の既存の Classic Load Balancer をApplication Load Balancer またはNetwork Load Balancer に移行することもできます。

Classic Load Balancer からの移行のメリット

各タイプのロードバランサーには、それぞれ独自の特徴、機能、構成があります。各ロードバランサーの利点を確認して、どのロードバランサーが最適かを判断してください。

Application Load Balancer

クラシックロードバランサーの代わりにApplication Load Balancer を使用すると、次のようなメリットがあります。

Support 対象:

  • パス条件、ホスト条件、HTTP ヘッダー条件。

  • ある URL から別の URL にリクエストをリダイレクトし、1 つの EC2 インスタンス上の複数のアプリケーションにリクエストをルーティングする。

  • カスタム HTTP レスポンスを返す。

  • IP アドレスでターゲットを登録し、Lambda 関数をターゲットとして登録します。ロードバランサーの VPC 外のターゲットを含みます。

  • 企業 ID またはソーシャル ID によるユーザーの認証。

  • Amazon Elastic Container Service (Amazon ECS) のコンテナ化されたアプリケーション。

  • 各サービスの状態を個別に監視します。

アクセスログには追加情報が含まれており、圧縮形式で保存されます。

ロードバランサーのパフォーマンスが全体的に向上しました。

Network Load Balancer

クラシックロードバランサーの代わりにNetwork Load Balancer を使用すると、次のようなメリットがあります。

Support 対象:

  • 静的 IP アドレス。ロードバランサーで有効になっているサブネットごとに 1 つの Elastic IP アドレスを割り当てることができます。

  • ロードバランサーの VPC 外のターゲットを含む IP アドレスによるターゲットの登録。

  • 1 つの EC2 インスタンス上の複数のアプリケーションにリクエストをルーティングする。

  • Amazon Elastic Container Service (Amazon ECS) のコンテナ化されたアプリケーション。

  • 各サービスの状態を個別に監視します。

揮発性のワークロードを処理し、毎秒数百万のリクエストに対応できる能力｡

移行ウィザードを使用して移行する

移行ウィザードは、Classic Load Balancer の設定を使用して、同等のApplication Load Balancer またはNetwork Load Balancer を作成します。これにより、Classic Load Balancer の移行に必要な時間と労力が他の方法に比べて削減されます。

注記

ウィザードは新しいロードバランサーを作成します。ウィザードは、既存のクラシックロードバランサーをApplication Load Balancer またはNetwork Load Balancer に変換しません。新しく作成したロードバランサーにトラフィックを手動でリダイレクトする必要があります。

制限事項

  • 新しいロードバランサーの名前は、同じリージョン内の同じタイプの既存のロードバランサーと同じにすることはできません。

  • Classic Load Balancer aws: のキーにプレフィックスを含むタグがある場合、それらのタグは移行されません。

Application Load Balancer に移行する場合

  • Classic Load Balancer にサブネットが 1 つしかない場合は、2 つ目のサブネットを指定する必要があります。

  • Classic Load Balancer に TCP ヘルスチェックを使用する HTTP/HTTPS リスナーがある場合、ヘルスチェックプロトコルは HTTP に更新され、パスは「/」に設定されます。

  • Classic Load Balancer に、カスタムまたはサポートされていないセキュリティポリシーを使用する HTTPS リスナーがある場合、移行ウィザードは新しいロードバランサータイプのデフォルトのセキュリティポリシーを使用します。

Network Load Balancer に移行する場合

  • 次のインスタンスタイプは新しいターゲットグループに登録されません:C1、CC1、CC2、CG1、CG2、CR1、CS1、G1、G2、HI1、HS1、M1、M2、M3、T1

  • Classic Load Balancer の特定のヘルスチェック設定は、新しいターゲットグループに転送できない場合があります。このような場合は、移行ウィザードのサマリーセクションに変更として表示されます。

  • Classic Load Balancer に SSL リスナーがある場合、移行ウィザードは SSL リスナーの証明書とセキュリティポリシーを使用して TLS リスナーを作成します。

移行ウィザードを使用してClassic Load Balancer を移行するには

  1. Amazon EC2 コンソール (https://console.aws.amazon.com/ec2/) を開きます。

  2. ナビゲーションペインの [ロードバランシング] で [ロードバランサー] を選択します。

  3. 移行するClassic Load Balancer を選択します。

  4. ロードバランサーの [詳細] セクションで、[移行ウィザードの起動] を選択します。

  5. [Application Load Balancer に移行] または [Network Load Balancer に移行] を選択して、移行ウィザードを開きます。

  6. [新しいロードバランサーに名前を付ける] の [ロードバランサー名] に、新しいロードバランサーの名前を入力します。

  7. [新しいターゲットグループに名前を付けてターゲットを確認する] で、[ターゲットグループ名] に新しいターゲットグループの名前を入力します。

  8. (オプション) [ターゲット] で、新しいターゲットグループに登録されるターゲットインスタンスを確認できます。

  9. (オプション)「レビュータグ」では、新しいロードバランサーに適用されるタグを確認できます。

  10. 「Application Load Balancer の概要」または「Network Load Balancer の概要」で、移行ウィザードによって割り当てられた構成オプションを確認して確認します。

  11. 設定の概要を確認したら、[Application Load Balancer の作成] または [Network Load Balancer の作成] を選択して移行を開始します。

ロードバランサーのコピーユーティリティを使用して移行します。

ロードバランサーのコピーユーティリティは、 AWS GitHub ページの Elastic Load Balancing Tools リポジトリ内にあります。

リソース

ロードバランサーを手動で移行します。

以下の情報は、VPC 内の既存の Classic Load Balancer に基づいて、新しい Application Load Balancer または Network Load Balancer を手動で作成するための一般的な手順を示しています。 AWS Management Console、 AWS CLI、または AWS SDK を使用して移行できます。詳細については、「Elastic Load Balancing の使用開始」を参照してください。

移行プロセスを完了すると、新しいロードバランサーの機能を利用できます。

ステップ 1: 新しいロードバランサーを作成する

移行する Classic Load Balancer と同等の設定でロードバランサーを作成します。

  1. 新しいロードバランサーを、Classic Load Balancer と同じスキーム (インターネット向けまたは内部向け)、サブネット、セキュリティグループを設定して作成します。

  2. ロードバランサーの 1 つのターゲットグループを、Classic Load Balancerと同じヘルスチェック設定で作成します。

  3. 次のいずれかを行ってください。

    • Classic Load Balancer が Auto Scaling グループに接続されている場合は、ターゲットグループを Auto Scaling グループに接続します。これにより、Auto Scaling インスタンスがターゲットグループに登録されます。

    • EC2 インスタンスをターゲットグループに登録します。

  4. 1 つ以上のリスナーを作成し、各リスナーに、リクエストをターゲットグループに転送するデフォルトのルールを設定します。HTTPS リスナーを作成する場合は、Classic Load Balancer 用に指定したのと同じ証明書を指定できます。デフォルトのセキュリティポリシーを使用することをお勧めします。

  5. Classic Load Balancer がタグ付けされている場合は、それらを見直して、関連性のあるタグを新しいロードバランサーに追加します。

ステップ 2: トラフィックを新しいロードバランサーに段階的にリダイレクトする

インスタンスを新しいロードバランサーに登録したら、古いロードバランサーから新しいロードバランサーにトラフィックをリダイレクトするプロセスを開始できます。これにより、アプリケーションの可用性に与えるリスクを最小限に抑えながら、新しいロードバランサーをテストできます。

トラフィックを新しいロードバランサーに段階的にリダイレクトするには

  1. インターネットに接続したウェブブラウザのアドレスフィールドに、新しいロードバランサーの DNS 名を貼り付けます。すべて適切な場合は、ブラウザにアプリケーションのデフォルトページが表示されます。

  2. ドメイン名を新しいロードバランサーに関連付ける新しい DNS レコードを作成します。DNS サービスが重み付けをサポートしている場合は、新しい DNS レコードに重み 1 を、古いロードバランサーの既存の DNS レコードに重み 9 を指定します。これで、トラフィックの 10% が新しいロードバランサーに、90% が古いロードバランサーにリダイレクトされます。

  3. 新しいロードバランサーをモニタリングして、トラフィックが受信され、リクエストがインスタンスにルーティングされていることを確認します。

    重要

    DNS レコードの time-to-live (TTL) は 60 秒です。つまり、ドメイン名を解決する DNS サーバーは、変更が反映される間、レコード情報を 60 秒間キャッシュに保持します。したがって、これらの DNS サーバーは、前のステップを完了してから最大 60 秒間、トラフィックを引き続き古いロードバランサーにルーティングできます。伝達の実行中、トラフィックは両方のロードバランサーにリダイレクトされる可能性があります。

  4. すべてのトラフィックが新しいロードバランサーにリダイレクトされるまで、DNS レコードの重みの更新を繰り返します。完了したら、古いロードバランサーの DNS レコードを削除できます。

ステップ 3: ポリシー、スクリプト、およびコードを更新する

Classic Load Balancer を Application Load Balancer または Network Load Balancer に移行した場合は、必ず以下のことを行ってください。

  • API バージョン 2012-06-01 を使用する IAM ポリシーを更新して、バージョン 2015-12-01 を使用します。

  • CloudWatch 名前空間のメトリクスを使用するプロセスを、AWS/ELBAWS/ApplicationELBAWS/NetworkELBまたは名前空間のメトリクスを使用するように更新します。

  • aws elb AWS CLI aws elbv2 AWS CLI コマンドを使用するスクリプトをコマンドを使用するように更新します。

  • AWS CloudFormation AWS::ElasticLoadBalancing::LoadBalancerリソースを使用するテンプレートを更新してリソースを使用する。AWS::ElasticLoadBalancingV2

  • Elastic Load Balancing API バージョン 2012-06-01 を使用するコードを更新して、バージョン 2015-12-01 を使用します。

リソース
ステップ 4: 古いロードバランサーを削除する

古い Classic Load Balancer は、以下を行った後に削除できます。

  • すべてのトラフィックを古いロードバランサーから新しいロードバランサーにリダイレクトしました。

  • 古いロードバランサーにルーティングされたすべての既存のリクエストが完了しました。