すべてのプロダクト
Search

このプロダクト

    Server Load Balancer:インスタンスクローンによる迅速なデプロイ

    ドキュメントセンター

    Server Load Balancer:インスタンスクローンによる迅速なデプロイ

    最終更新日:Aug 22, 2026

    迅速な環境デプロイ、ディザスタリカバリ、構成移行などのシナリオでは、Application Load Balancer (ALB) のインスタンスクローン機能を使用して、ソースインスタンスと同一または類似のインスタンスを迅速に作成することで、デプロイ効率を向上させ、運用上の複雑さを軽減します。

    ALB インスタンスクローン

    インスタンスクローン機能は、リスナー、サーバーグループ、転送ルール、ヘルスチェックなどの主要コンポーネントを含む既存の ALB インスタンスの構成を複製します。これにより、面倒な手動での再設定を回避し、新しいインスタンスがソースインスタンスと同一または類似の構成を持つことを保証します。この機能は、特にディザスタリカバリや構成移行に役立ちます。

    主な特徴

    • 迅速な複製：Resource Orchestration Service (ROS) を利用した自動化プロセスにより、ワンクリックで既存の ALB インスタンスをクローンします。この迅速なプロセスにより、デプロイ効率が向上し、運用上の複雑さが軽減されます。

    • 構成の一貫性：新しいインスタンスがソースインスタンスと同一または類似の構成を持つことを保証し、設定ミスを防ぎます。

    • 柔軟なデプロイ：クローンしたインスタンスを別のリージョンやゾーンにデプロイすることで、複数リージョンでのビジネス拡大やディザスタリカバリのフェイルオーバーといった複雑な要件に対応します。

    ユースケース

    • 環境移行：テスト環境の構成をステージング環境や本番環境にクローンすることで、環境間の一貫性を確保し、機能リリースを加速します。

    • ディザスタリカバリ：サービス障害時にインスタンスクローンを使用して待機系の負荷分散リソースを迅速にデプロイし、ビジネス継続性と高可用性を向上させます。

    • 構成移行：バージョンアップやアーキテクチャの調整などのために、既存インスタンスの構成を新しいインスタンスに移行し、繰り返しの手動設定を回避します。

    制限事項

    • クローン先の ALB インスタンスとソースの ALB インスタンスは、同じエディションである必要があります。

    • ALB Ingress インスタンスはクローンできません。

    • 変更保護が有効になっている ALB インスタンスはクローンできません。

    • ソースの ALB インスタンスが Internet Shared Bandwidth インスタンスに追加されている場合、クローンされた ALB インスタンスは自動的に Internet Shared Bandwidth インスタンスに追加されません。インスタンスの詳細ページで手動でインスタンスを追加できます。

    • アップグレード前の ALB インスタンスをクローンすると、デフォルトでアップグレード後の ALB インスタンスが作成されます。詳細については、「アップグレード前とアップグレード後の ALB インスタンスの違い」をご参照ください。

    例

    ある企業がテスト環境に新機能をデプロイし、負荷分散のために ALB インスタンスを使用しています。この ALB インスタンスには、HTTP リクエストを HTTPS にリダイレクトする転送ルールが設定されており、カスタムドメイン名を使用してテストサービスを提供しています。テストクライアントがドメイン名 www.example.com にアクセスすると、DNS は CNAME レコードに基づいてドメイン名を ALB インスタンスに解決します。その後、ALB インスタンスは転送ルールに基づいてトラフィックを ECS01 と ECS02 に転送して処理します。

    機能が受け入れテストに合格した後、ALB インスタンスの構成を本番環境に移行する必要があります。ALB インスタンスを手動で設定するのは時間がかかり、特にトラフィックの多い本番環境では、ビジネス運用に影響を与える構成の不整合を引き起こす可能性があります。

    この問題を解決するため、同社はインスタンスクローン機能を使用して、テスト環境から本番環境へ ALB の構成を迅速に複製することにしました。この機能を使用することで、同社は本番環境に ALB インスタンスを迅速にデプロイし、新機能の迅速な立ち上げと安定した運用を保証します。

    image

    前提条件

    • ソースの ALB インスタンスにリスナー、バックエンドサーバー、および CNAME レコードが設定されている必要があります。また、カスタムドメイン名 www.example.com を介してテストアクセスが可能である必要があります。詳細については、「ALB を使用した IPv4 サービスの負荷分散」をご参照ください。

      • ソースの ALB インスタンスには、HTTP リスナーと HTTPS リスナーがあります。HTTP リスナーには、HTTP リクエストを HTTPS にリダイレクトするためのリダイレクト転送ルールが設定されています。

      • ソース ALB インスタンスのバックエンドサーバーである ECS01 と ECS02 にサービスをデプロイします。

        このトピックでは、オペレーティングシステムとして Alibaba Cloud Linux 3 を使用し、Nginx を使用して HTTP 80 サービスを設定します。

        例：ECS01 にテストサービスをデプロイ

        yum install -y nginx
systemctl start nginx.service
cd /usr/share/nginx/html/
echo "Hello World ! This is ECS01." > index.html

    • 必要に応じて、クローン先の ALB インスタンス用のバックエンドサーバーを準備します。

      • クローン先の ALB インスタンスがソースの ALB インスタンスと同じ Virtual Private Cloud (VPC) 内にある場合、ソース ALB インスタンスのバックエンドサーバー ECS01 と ECS02 を、クローン先 ALB インスタンスのバックエンドサーバーとしても使用できます。

      • クローン先の ALB インスタンスがソースの ALB インスタンスと同じ VPC 内にない場合は、クローン先の VPC にバックエンドサーバー ECS03 と ECS04 を準備し、それらにサービスをデプロイします。

    • クライアントをシミュレートするためのサーバーを準備します。ECS-A は移行前のトラフィックのテストに使用し、ECS-B は移行中のアクセストラフィックの検証に使用します。両方のサーバーはパブリックネットワークアクセスが必要です。このトピックでは、オペレーティングシステムとして Alibaba Cloud Linux 3 を使用します。

      すでにテストサーバーがある場合は、ECS-A と ECS-B を作成する必要はありません。

    操作手順

    手順 1：ソース ALB インスタンスのクローン

    1. ALB コンソールの [上部メニュー] で、ソース ALB インスタンスのリージョンを選択します。

    2. インスタンス ページでクローンするインスタンスを見つけ、操作 列で 更多操作 > クローン を選択します。

    3. クローン ダイアログボックスで、宛先 ALB インスタンスのパラメーターを設定し、次へ をクリックします。

      デフォルトでは、宛先 ALB インスタンスのパラメーターはソース ALB インスタンスのパラメーターと同じです。この例では、クローン先リージョン をドイツ (フランクフルト) から米国 (シリコンバレー) に変更し、クローン先 VPC をデフォルトの VPC1 から宛先の VPC2 に変更し、対応する宛先ゾーンと vSwitch を選択します。その他のパラメーターは、デフォルト値のままにするか、必要に応じて変更できます。

      クローンされたインスタンスがパブリックネットワークタイプで、宛先リージョンが ALB が Anycast EIP をサポートするリージョンである場合は、IP アドレスタイプ (EIP または Anycast EIP) も選択し、選択したゾーンに対応するタイプのパブリック IP アドレスを割り当てる必要があります。

    4. 設定の確認 ステップで、移行先の ALB インスタンスの情報と料金を確認し、クローン をクリックします。

    5. クローンの結果を確認します。

      クローンが完了したら、クローン先の ALB インスタンスのビジネスデータをソース ALB インスタンスのデータと比較できます。

      インスタンスクローンは ROS によって提供されます。クローンプロセス中は、ROS コンソールにログインして進捗状況を確認できます。

    6. バックエンドサーバー ECS03 と ECS04 をクローン先 ALB インスタンスのサーバーグループに追加します。

    手順 2：トラフィックのテスト

    クローン先の ALB インスタンスがバックエンドサービスに接続できることを確認するため、バックエンドサービスに iptables やその他のサードパーティ製セキュリティソフトウェアなどのアクセスポリシーがある場合は、ALB インスタンスの vSwitch の CIDR ブロックを許可リストに追加します。

    1. テストサーバー ECS-A にリモート接続します。

    2. 次のコマンドを実行して hosts ファイルを変更します。

      sudo vi /etc/hosts

      hosts ファイルに、クローン先 ALB インスタンスの Elastic IP アドレス (EIP) とドメイン名を追加します。ファイルを変更したら、変更を保存して終了します。

      47.251.XX.XX www.example.com

    3. 次のコマンドを実行して、クローン先 ALB インスタンスのトラフィック転送をテストします。

      curl -v -L www.example.com

      次の出力が返されます。これは、HTTP リクエストが正常に HTTPS にリダイレクトされ、応答サーバーが ECS03 であることを示しています。

      ECS03响应01

      ECS03响应02

      コマンドを再度実行します。応答サーバーが ECS04 に変わります。

      ECS04响应01

      ECS04响应02

    手順 3：クローン先インスタンスへのトラフィック移行

    警告

    • トラフィックを移行する前に、ソースとクローン先の ALB インスタンスの転送ルール設定を比較して、それらが同一の機能を提供することを確認します。移行中にビジネスに予期せぬ影響が出ないよう、すべての設定が受け入れテストに合格していることを確認してください。

    • ALB のトラフィックはオフピーク時に移行してください。

    ソース ALB インスタンスには CNAME レコードが設定されています。クローン先 ALB インスタンスの設定を検証した後、必要に応じてソース ALB インスタンスからクローン先 ALB インスタンスにトラフィックを移行できます。

    このトピックでは、Alibaba Cloud DNS の加重ルーティングポリシー機能を例として使用します。ソースとクローン先の ALB インスタンス間の重み比率を動的に調整することにより、DNS トラフィックはソースインスタンスから新しいインスタンスに段階的に移行されます。

    パート 1：CNAME レコードの追加

    1. 左側のナビゲーションペインで、ALB > インスタンス を選択します。インスタンス ページで、作成された ALB インスタンスの DNS 名をコピーします。

    2. 次の手順に従って、CNAME レコードを追加します。

      1. Alibaba Cloud DNS コンソールで、目的のドメイン名を探し、Actions 列の 解決設定 をクリックします。

        Alibaba Cloud に登録されていないドメインの場合、DNS 設定を行う前に、まず Alibaba Cloud DNS コンソールにドメインを追加する必要があります。

      2. 解決設定 ページで、Add Record をクリックし、CNAME レコードを設定し、次に OK をクリックします。

        この例では、Record Type を CNAME に設定し、Record Value を宛先 ALB インスタンスの DNS 名に設定します。その他の DNS レコードパラメーター は、デフォルト値のままにするか、必要に応じて変更できます。

      3. Change Resource Record Confirmation ダイアログボックスで、DNS 情報を確認し、OK をクリックします。

    パート 2：重みの設定とカナリアリリースの開始

    1. 解決設定 ページで、パート 1 で追加した CNAME レコードを見つけ、変更 の横にあるドロップダウン矢印をクリックして レコードセットを変更する をクリックします。

    2. Edit Record パネルの レコードコレクション で、送信元および宛先 ALB インスタンスの DNS レコードの重みを設定します。送信元 ALB インスタンスの DNS レコードの重みを 100 に設定し、宛先 ALB インスタンスの DNS レコードの重みを 0 に設定します。

      加重ルーティングポリシーは、ドメイン名の下で同じホスト名と DNS 回線に対して複数の A、CNAME、または AAAA レコードが存在する場合にのみ有効にできます。

    3. ビジネスへの影響が見られない場合は、ソース ALB インスタンスの DNS レコードの重みを徐々に減らし、クローン先 ALB インスタンスの DNS レコードの重みを徐々に増やします。

    4. テストサーバー ECS-B にリモート接続し、dig コマンドを複数回実行してトラフィック移行の効果を検証します。

      dig www.example.com

      次の図に出力を示します。コマンドを複数回実行すると、リクエストが重みに基づいてソース ALB インスタンスまたはクローン先 ALB インスタンスのいずれかに分散されることがわかります。

      dig解析

    (任意) パート 3：トラフィック移行の完了

    トラフィック移行の検証結果に基づいて、ソース ALB インスタンスの DNS レコードの重みを徐々に 0 に減らし、クローン先 ALB インスタンスの DNS レコードの重みを 100 に増やします。これにより、ソース ALB インスタンスからクローン先 ALB インスタンスへのトラフィック移行が完了します。

    ソース ALB インスタンスへのすべての永続的な接続が閉じ、新しいトラフィックがルーティングされなくなった後、インスタンスを一定期間監視し、ビジネスシナリオに基づいてリリースできます。

    関連ドキュメント

    • ALB インスタンスをクローンした後、ALB アクセスログを使用してクローン先インスタンスの負荷を監視し、関連する問題をトラブルシューティングできます。

    • レイヤー 7 CLB リスナーを ALB に移行する必要がある場合：

    • 必要に応じて、DNS トラフィック管理ポリシーを選択できます。

      • 加重ルーティングポリシー：設定された重みに基づいて DNS トラフィックを重み付きラウンドロビン方式で分散し、クエリリクエストに応じて対応するレコード値を返します。

      • インテリジェント DNS 解決：ユーザーの地理的な場所と ISP に基づいて DNS 結果を返し、解決のレイテンシを削減し、ウェブサイトのアクセス速度を向上させます。サポートされている回線には、ISP、ISP/省、中国本土以外、大陸、カスタム回線が含まれます。

      • Global Traffic Manager (GTM)：近接アクセス、高コンカレンシートラフィックの負荷分散、およびヘルスチェック結果に基づくトラフィックシフトを実装します。これにより、異なるリージョン間でアクティブ/アクティブおよびディザスタリカバリサービスを柔軟に構築できます。