すべてのプロダクト
Search
ドキュメントセンター

Auto Scaling:Web サービスの弾力的かつ高可用性なアーキテクチャへの進化

最終更新日:Aug 19, 2026

ビジネスの成長に伴い、モノリシック Web サービスへの負荷が増加し、システムの安定性が低下する可能性があります。この問題に対処するため、スケーリンググループを使用してサーバーをスケールアウトし、負荷を分散させることで、モノリシックアーキテクチャを弾力的で高可用性なアーキテクチャに進化させることができます。このアプローチにより、システムの安定性と応答速度が向上します。

弾力的で高可用性なアーキテクチャを使用する理由

モノリシックアーキテクチャの問題点

一般的なモノリシックアーキテクチャでは、すべてのリソースが単一の Elastic Compute Service (ECS) インスタンスにデプロイされます。ユーザーはドメイン名または IP アドレスを介して、この単一サーバー上のサービスに直接アクセスします。このアーキテクチャには主に 2 つの問題があります。

  • 単一障害点:サービスに障害が発生すると、ビジネス全体が中断します。これはユーザーエクスペリエンスに深刻な影響を与え、顧客の損失につながる可能性があります。

  • パフォーマンスボトルネック:トラフィックが増加すると、モノリシックアーキテクチャはパフォーマンスの限界に達し、ビジネスの拡大を妨げます。急激なトラフィックスパイクは、サービスの応答時間を容易に遅くする可能性があります。

高可用性アーキテクチャの特徴

弾力的で高可用性なアーキテクチャでは、ロードバランサーがユーザーリクエストをクラスター内のインスタンスで実行されているビジネスサービスにルーティングします。このアーキテクチャには、次の主な特徴があります。

  • 単一障害点なし (高可用性):複数のサーバーを使用して負荷を分散させ、サービスキャパシティを向上させ、単一サーバーの障害による中断を防ぎます。

  • 弾力的なスケーリング:スケーリンググループを使用してサービスクラスターを管理し、ワンクリックでサーバー数を変更して迅速にスケールアウトできます。また、自動スケーリングポリシーを設定して、アプリケーションの負荷に基づいてリソースをスケーリングすることもできます。

高可用性アーキテクチャへの進化方法

図に示すように、左側のモノリシックアーキテクチャから弾力的で高可用性なアーキテクチャへの進化には 2 つのフェーズがあります。

  • フェーズ 1:データストレージとビジネスロジックの分離

    弾力的で高可用性なアーキテクチャは、ECS インスタンス全体をレプリケーションします。したがって、ECS インスタンス (およびその中のサービス) のデータストレージビジネスロジックを分離する必要があります。これはステートレス化とも呼ばれ、インスタンスを追加してスケールアウトする際のデータ整合性の問題を回避します。

    例えば、ECS インスタンスをレプリケーションする際、データベースがコピーされないようにすることで、クラスターが複数の異なるデータソースを使用するのを防ぎます。データストレージを ECS インスタンスから分離することで、すべてのインスタンスが同じデータソースを共有し、データ整合性が維持されます。

    以下の一般的な状況のいずれかに該当する場合、ビジネスへの潜在的な影響を評価し、それに応じてアーキテクチャを調整する必要があります。

    注意すべき一般的な状況

    状況 1:インスタンス上のステートフルサービス

    ECS インスタンスにデータベースなどのステートフルサービスが含まれている場合、このインスタンスをレプリケーションしてスケールアウトすると、クラスター内に複数のデータソースが存在することになり、データの不整合が発生します。MySQL や Redis などのステートフルサービスは、独自のデプロイメントに分離してください。

    また、自己管理の MySQL や Redis データベースを直接 ApsaraDB RDS に移行することもできます。自己管理データベースと比較して、ApsaraDB RDS はより安全で信頼性が高く、メンテナンスも容易です。自己管理データベースをクラウドに移行する方法については、「自己管理データベースのクラウドデータベースへの移行」をご参照ください。

    状況 2:セッションベースのサービス

    ビジネスサービスがセッションを使用してユーザーのログイン状態を維持している場合、サービスをスケーリングすると、サービスのレプリカ間でログイン情報 (セッション情報) に不整合が生じます。これにより、ユーザーが頻繁にログアウトされる可能性があります。この問題を解決するには、共有セッション管理のために別の Redis インスタンスをデプロイします。

    状況 3:非同時実行の定期タスク

    ビジネスに 1 日に 1 回だけ実行する必要がある定期タスクがある場合、スケールアウトすると複数のサーバーが同時にタスクを実行してしまいます。この状況に対処するために、タスク処理ロジックを調整する必要があるかもしれません。

  • フェーズ 2:高可用性アーキテクチャへの進化

    ECS インスタンス上のデータストレージビジネスロジックを分離した後、インスタンスとそのビジネスサービスのレプリカを作成してスケールアウトできます。

    サービスクラスターをスケーリンググループに移行して、その弾力性を活用して迅速にレプリケーションします。ロードバランサーをサービスクラスターのアクセスポイントとして使用して負荷を分散させ、システムの安定性と効率を確保します。

高可用性アーキテクチャへのクイック移行

ソリューションの概要

すでにデータストレージビジネスロジックを分離している (ステートレス化している) 場合は、以下の手順に従って、スケーリンググループを使用してサービスをモノリシックアーキテクチャから弾力的で高可用性なアーキテクチャに迅速に移行できます。

  1. デモ Web サイトのデプロイ (インスタンスの準備)。このソリューションでは、ステートレスなデモ Web サービスインスタンスをシミュレートして、移行プロセスを示します。既存のインスタンスを使用することもできます。

  2. ビジネスサービスを含むインスタンスイメージのビルド。このイメージは、クラスター内のインスタンスを起動するために使用され、起動時にビジネスサービスを自動的に開始します。

  3. サービスクラスターを管理するためのスケーリンググループの作成。このスケーリンググループを使用して、インスタンスを迅速にレプリケーション (スケールアウト) します。

  4. クラスターの統一アクセスポイントの設定。ロードバランサーを関連付けて、統一アクセスポイントを作成します。

  5. インスタンスのスケールアウト (検証)。インスタンスを迅速にレプリケーションし、ロードバランサーにアクセスして、クラスターが正しく動作していることを確認します。

1. デモ Web サイトのデプロイ

まず、本番環境を表すアプリケーションインスタンスが必要です。このインスタンスは、レプリケーションと自動デプロイメントに使用されます。

このチュートリアルでは、移行プロセスを体験できるデモ Web サイトサービスを提供します。[デモサービスのデプロイ] をクリックして、デモサービスをセットアップします。

このデモ Web サイトサービスには、Web サービスパッケージ、その実行環境、および起動スクリプトが含まれています。インスタンスは、データストレージとビジネスロジックを分離することで、すでにステートレス化されています。
ビジネスサービスインスタンスがすでにステートレスであり、必要なコンポーネント (ソフトウェアパッケージ、環境、起動スクリプト) を備えている場合は、実際のサービスインスタンスを代わりに使用して、以下の移行手順を実行できます。

デモサービスのデプロイ

右図に示すように、このデモアーキテクチャの ECS インスタンスには、データベースに接続する Web サービスが含まれています。サービスのアドレスにアクセスすると、現在のサーバーの IP とデータベースからクエリされた文字列が表示されます。このサービスには起動コマンドが設定されているため、ECS インスタンスの起動時に自動的に実行されます。

[デモサービスのデプロイ] 機能は Resource Orchestration Service (ROS) を使用します。この機能を使用すると、Alibaba Cloud アカウントに Virtual Private Cloud (VPC) と vSwitch、デモサービスを備えた ECS インスタンス、および ApsaraDB RDS for MySQL インスタンスが作成されます。

デモサービスインスタンスをデプロイするには、次の手順に従います。

  1. [デモサービスのデプロイ] ボタンをクリックして、[ワンクリックデプロイ] ページに移動します。

  2. 画面の指示に従って、[リージョン] と [ゾーン] を選択します。

  3. インスタンス設定セクションで、[インスタンスタイプ] を選択し、[インスタンスパスワード] を設定します。

    このチュートリアルでは、コストを節約するために、バースト可能インスタンスなどの最低構成を選択できます。利用可能なインスタンスタイプは、リージョンとアベイラビリティゾーンによって異なります。ページに表示されるオプションをご参照ください。
  4. [RDS インスタンスタイプ] を選択し、[RDS データベースパスワード] を設定します。

  5. コストを確認した後、[今すぐデプロイ] をクリックし、リソースが作成されるのを待ちます。

    [特定のリソース] タブで進捗を監視できます。監視するリソースは、作成順にセキュリティグループ、VPC、vSwitch、ECS インスタンス、ApsaraDB RDS インスタンスです。
  6. [出力の表示] タブで、WebUrl のリンクを見つけます。

    ブラウザでこのリンクに複数回アクセスできます。毎回同じ IP アドレスが表示され、同じ ECS インスタンスにアクセスしていることを確認できます。

2. インスタンスイメージのビルド

新しいインスタンスにビジネスサービスと起動スクリプトが含まれるように、準備したインスタンスからカスタムイメージを作成します。後続のインスタンスはこれをベースイメージとして使用するため、インスタンスの起動時にビジネスサービスが自動的に開始されます。

  1. ECS コンソールに移動し、ステップ 1 でインスタンスを準備したリージョンに切り替えます。

  2. ステップ 1 で準備した ECS インスタンスを見つけます。右側の [操作] 列で、[ディスクとイメージ > カスタムイメージの作成] を選択します。

  3. [カスタムイメージの作成] ダイアログボックスで、識別しやすいイメージ名を入力し、[OK] をクリックします。イメージの作成が完了するのを待ちます。ECS コンソールの左側のナビゲーションウィンドウで [インスタンス & イメージ > イメージ] をクリックして、進捗を確認できます。

3. スケーリンググループの作成

スケーリンググループを使用してサービスクラスターを管理することは、弾力的で高可用性なアーキテクチャの中核です。スケーリンググループを使用して、インスタンスを迅速にレプリケーションできます。スケーリンググループを作成して有効にするには、次の手順に従います。

  1. [スケーリンググループ] ページに移動します。

    1. Auto Scaling コンソールにログインします。

      Auto Scaling を初めて使用する場合は、画面の指示に従って必要な権限を付与します。詳細については、「サービスにリンクされたロール」をご参照ください。

    2. 左側のナビゲーションウィンドウで、[スケーリンググループ] をクリックします。

    3. 上部のナビゲーションバーで、Auto Scaling が有効化されているリージョンを選択します。

  2. スケーリンググループを作成します。

    1. [スケーリンググループ] ページで、[作成] をクリックして [作成] ページを開きます。

    2. ページで次の設定を完了します。表に記載されていない設定は、デフォルト値のままにすることができます。

      パラメーター

      説明

      スケーリンググループ名

      プロンプトに従って名前を入力します。この例では、名前は ess-demo です。

      タイプ

      ECS を選択します。

      インスタンス設定ソース

      [既存のインスタンスを選択] を選択します。

      既存のインスタンスを選択

      ステップ 1 で準備した ECS インスタンスを選択します。

      最小インスタンス数

      スケーリンググループ内の最小インスタンス数。インスタンス数がこの値を下回ると、自動スケールアウトイベントがトリガーされます。この例では、最小値は 0 です。

      [最大インスタンス数]

      スケーリンググループ内の最大インスタンス数。インスタンス数がこの値を超えると、自動スケールインイベントがトリガーされます。この例では、最大値は 10 です。

      [VPC] と [VSwitch の選択]

      これらの設定は、選択した ECS インスタンスに基づいて自動的に入力されます。

      重要

      複数のアベイラビリティゾーンで vSwitch を作成して選択することを推奨します。これにより、単一のアベイラビリティゾーンでのインスタンス在庫不足によるスケーリングの失敗を防ぐことができます。vSwitch を作成するには、「vSwitch の作成」をご参照ください。

      [詳細設定を表示する > 予想されるインスタンス数を有効化する]

      この機能を有効にするために選択します。有効にすると、予想インスタンス数を設定することで自動的にスケールインまたはスケールアウトできます。

      [詳細設定を表示する > 想定インスタンス数]

      0 を入力して、最初に空のスケーリンググループを作成します。

      [詳細設定を表示する > インスタンスのヘルスチェック]

      [インスタンスのステータスチェック] と [SLB ヘルスチェック] を選択します。有効にすると、システムはヘルスチェックの結果を使用して、スケーリンググループ内のすべてのインスタンスとそのビジネスサービスが正しく実行されていることを確認します。サービスが不健康になった場合、速やかに新しいインスタンスに置き換えられます。

    3. [作成する] をクリックし、スケーリンググループが作成されるのを待ちます。

  3. スケーリング設定でインスタンスイメージを変更します。

    既存のインスタンスを選択してスケーリンググループを作成すると、インスタンスの元のイメージに基づいてスケーリング設定が作成されます。ステップ 1 で作成されたインスタンスの元のイメージには、後でデプロイされたアプリケーションパッケージが含まれていません。したがって、スケーリング設定のベースイメージをステップ 2 で作成した新しいイメージに更新する必要があります。
    1. [スケーリンググループ] ページで、作成したばかりのスケーリンググループを見つけます。[操作] 列で、[詳細の表示] をクリックして、スケーリンググループの詳細ページに移動します。

    2. [インスタンスの設定ソース > スケーリング設定] タブで、唯一のスケーリング設定を見つけ、[操作] 列の [イメージの編集] をクリックします。

    3. [イメージの編集] ダイアログボックスで、[カスタムイメージ] を選択します。プロンプトに従って、ステップ 2 で作成したイメージを選択します。[OK] をクリックして変更を完了します。

  4. スケーリンググループを有効にします。

    [スケーリンググループ] ページで、右上隅の [有効化] ボタンをクリックして、スケーリンググループを有効にします。

4. 統一アクセスポイントの設定

1 つのインスタンスから多数のインスタンスにスケーリングする場合、クラスターの統一アクセスポイントが必要です。これを行うには、スケーリンググループにロードバランサーを作成して関連付けます。これにより、ユーザーリクエストがクラスター内の ECS インスタンスに自動的に分散され、負荷が分散され、リソース使用率が最大化されます。この例では、Application Load Balancer (ALB) を使用します。次の手順に従います。

4.1 ロードバランサーの作成

  1. ALB コンソールにログインします。

  2. [インスタンス] ページで、[Application Load Balancer の作成] をクリックします。

  3. Application Load Balancer (従量課金) の購入ページで、画面の指示に従って ALB を作成します。

    この例では、次の設定を使用します。記載されていない設定は、デフォルト値のままにすることができます。

    パラメーター

    説明

    リージョン

    ステップ 1 のインスタンスと同じリージョンを選択します。

    ネットワークタイプ

    [パブリックネットワーク] を選択します。

    VPC

    ステップ 1 で準備したインスタンスの VPC を選択します。

    ゾーン

    少なくとも 2 つ選択します。選択したアベイラビリティゾーンに vSwitch がない場合は、画面の指示に従って作成します。vSwitch の作成方法については、「vSwitch の作成」をご参照ください。

4.2 サーバーグループの作成

このサーバーグループはスケーリンググループに関連付けられます。スケーリンググループによって作成されたインスタンスは、自動的にこのサーバーグループに追加され、ロードバランサーを介してサービスを提供します。

  1. ALB コンソールで、リージョンを選択します。

  2. 左側のナビゲーションウィンドウで、[サーバーグループ] をクリックして [サーバーグループ] ページに移動します。[サーバーグループの作成] をクリックし、画面の指示に従ってサーバーグループを作成します。

    この例では、次の設定を使用します。記載されていない設定は、デフォルト値のままにすることができます。

    パラメーター

    説明

    [サーバーグループのタイプ]

    [サーバータイプ] を選択します。

    [サーバーグループ名]

    プロンプトに従って名前を入力します。この例では、ess-test-server-group を使用します。

    VPC

    ステップ 1 で準備したインスタンスの VPC を選択します。

4.3 リスナーの設定

HTTP プロトコルからのリクエストを転送するために、HTTP リスナーを作成します。ロードバランサーインスタンスが HTTP リクエストを受信すると、リクエストをサーバーグループ内の ECS インスタンスに転送できます。

  1. ALB コンソールで、リージョンを選択します。

  2. 左側のナビゲーションウィンドウで、[インスタンス] をクリックします。ステップ 4.1 で作成したロードバランサーを見つけ、[操作] 列の [リスナーの作成] をクリックします。画面の指示に従ってリスナーを作成します。

    この例では、次の設定を使用します。記載されていない設定は、デフォルト値のままにすることができます。

    パラメーター

    説明

    リスナープロトコルの選択

    HTTP を選択します。

    リスナーポート

    ロードバランサーがサービスを提供するポート。デモサービスはポート 80 を使用します。これは、リスナーがロードバランサーのポート 80 へのリクエストを処理することを意味します。

    [サーバーグループの選択]

    ステップ 4.2 で作成したサーバーグループを選択します。

4.4 ロードバランサーの関連付け

  1. [スケーリンググループ] ページで、ステップ 3 で作成したスケーリンググループを見つけます。[操作] 列で、[詳細の表示] をクリックして、スケーリンググループの詳細ページに移動します。

  2. [基本情報] タブで、[関連付けられた ALB/NLB サーバーグループ] を見つけます。[関連付けられた ALB/NLB サーバーグループの追加] をクリックします。表示されるダイアログボックスで、[サーバーグループの追加] をクリックし、プロンプトに従ってステップ 4.2 で作成したサーバーグループを関連付けます。設定後、[OK] をクリックして関連付けを完了します。

    重要

    この設定のポート番号は、ビジネスサービスがサービスを提供するポートである必要があります。この例のデモサービスはポート 80 を使用します。

5. スケールアウトと検証

スケーリンググループを設定し、ロードバランサーに関連付けた後、インスタンスをスケールアウトしてクラスターが正しく動作することを確認できます。

  1. スケーリンググループのスケールアウトイベントをトリガーすると、スケーリンググループは自動的にインスタンスを作成します。

    スケーリンググループの予想インスタンス数を変更することで、スケールアウトイベントをトリガーできます。次の手順に従います。

    1. [スケーリンググループ] ページで、作成したばかりのスケーリンググループを見つけます。[操作] 列で、[詳細の表示] をクリックして、スケーリンググループの詳細ページに移動します。

    2. [基本情報] タブで、[インスタンススケーリングの概要] を見つけ、image をクリックします。[インスタンススケーリング概要の編集] ダイアログボックスで、[想定インスタンス数] を 0 から 3 に変更します (これは、クラスターがサービスを提供するために 3 つの ECS インスタンスを必要とすることを意味します)。[OK] をクリックして変更を適用します。

    3. インスタンスが作成されるのを待ちます。スケーリンググループに 3 つの ECS インスタンスが作成されます。[インスタンス] タブで作成ステータスを確認できます。

  2. ロードバランサーのアドレスにアクセスして、新しいインスタンスにリクエストがルーティングされていることを確認します。

    1. ALB コンソールに移動します。

    2. ステップ 4.1 で作成したロードバランサーを見つけます。[DNS 名] の下に、アクセス URL があります。

    3. この URL に複数回アクセスします。異なる IP アドレスが表示されるはずです。これにより、ロードバランサーを介して異なるサーバーにアクセスできることが確認できます。

6. (任意) リソースのクリーンアップ

クラスターが不要になった場合は、このプロセスに従ってリソースをクリーンアップできます。

  1. ステップ 4.1 で作成したロードバランサーを解放します。詳細については、「ALB インスタンスの解放」をご参照ください。

  2. ステップ 3 で作成したスケーリンググループを削除します。詳細については、「スケーリンググループの削除」をご参照ください。

  3. ステップ 4.2 で作成したサーバーグループを削除します。詳細については、「サーバーグループの作成と管理」をご参照ください。

  4. ステップ 2 で作成したカスタムイメージを削除します。詳細については、「カスタムイメージの削除」をご参照ください。

  5. ステップ 3ステップ 4.1 で作成した vSwitch を削除します。詳細については、「VPC の作成と管理」および「vSwitch の削除」をご参照ください。

  6. ステップ 1 でデプロイしたデモサービスをクリーンアップします。ステップ 1 からデモサービスをデプロイした場合は、その ROS スタックを削除できます。スタックを削除する際、[削除方法] として [リソースの解放] を選択して、デモサービスによって作成されたリソースをクリーンアップします。詳細については、「スタックの削除」をご参照ください。

次のステップ

本番環境に移行する前に

この弾力的で高可用性なソリューションが本番環境で安定して動作することを保証するため、本番環境に移行する前に次のアクションを完了することを推奨します。

  • スケーリンググループ設定の改良

    • マルチゾーンディザスタリカバリの実装:スケーリンググループに複数のアベイラビリティゾーンの vSwitch を設定し、マルチゾーンスケーリングポリシーを設定できます。これにより、スケーリンググループは複数のアベイラビリティゾーンにわたってインスタンスを作成し、サービスインスタンスをそれらの間で均等に分散させ、スケーリングの成功率とクラスターのディザスタリカバリ能力を向上させることができます。詳細については、「スケーリングポリシー」をご参照ください。

    • 複数のインスタンスタイプの選択:単一のインスタンスタイプが在庫切れの場合、スケールアウトイベントが失敗する可能性があります。複数のインスタンスタイプを選択することで、スケーリングの成功率を向上させることができます。詳細については、「スケーリング設定の作成 (ECS インスタンス)」をご参照ください。

  • 徹底的なテストの実施

    この弾力的で高可用性なソリューションを本番環境で使用する予定がある場合は、クラスターを設定した後にテストを実施することを推奨します。これにより、サービスがレプリケーションされたときに正しく動作することを確認し、クラスターのストレステストを実行してリソース要件を見積もることができます。

ドメイン名を使用したアクセス

DNS レコードの更新

以前にドメイン名を使用して ECS インスタンスにアクセスしていた場合は、ドメインの DNS レコードを更新してロードバランサーを指すようにすることができます。これにより、ユーザーがドメインにアクセスすると、リクエストはロードバランサーを介してサービスクラスターにルーティングされます。詳細については、「ALB インスタンスの CNAME 解決の設定」をご参照ください。

重要

DNS を更新した後、伝播には時間がかかります。元のサービス IP アドレスを変更したり、元のインスタンスをすぐに停止したりしないでください。元の ECS インスタンスをしばらく実行し続けてください。そのインバウンドトラフィックを監視し、トラフィックがゼロに減少した後にのみ停止してください。

これにより、ローカル DNS キャッシュがまだ元の IP アドレスを指しているユーザーのサービス中断を回避できます。

HTTPS プロトコルのサポート

この例では HTTP を使用します。クラスターのドメインで HTTPS を有効にするには、ロードバランサーに HTTPS リスナーを設定します。詳細については、「HTTPS リスナーの追加」をご参照ください。

Auto Scaling 機能の使用

  • スケーリング戦略の設計:このチュートリアルでは、自動スケーリング戦略の設計については説明しません。後でスケーリンググループに自動スケーリングを設定して、コストを最適化できます。スケーリング戦略の設計方法については、「サポートされているスケーリング戦略」をご参照ください。

  • 高度な機能:スケーリング成功率の向上やコストのさらなる削減など、スケーリンググループに対するより高度な要件がある場合は、「高度な機能」をご参照ください。