翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# ステップ 4: MyStack の拡張
**重要**
この AWS OpsWorks Stacks サービスは 2024 年 5 月 26 日にサポート終了となり、新規および既存のお客様の両方で無効になっています。できるだけ早くワークロードを他のソリューションに移行することを強くお勧めします。移行についてご質問がある場合は、[AWS re:Post](https://repost.aws/) または[AWS プレミアムサポート](https://aws.amazon.com/support)を通じて AWS サポート チームにお問い合わせください。
MyStack にあるアプリケーションサーバーは現在 1 個のみです。本稼働用のスタックでは、おそらく、複数のアプリケーションサーバーで着信トラフィックを処理し、ロードバランサーでアプリケーションサーバー全体の着信トラフィックを均等に分散させる必要があります。アーキテクチャは次のようになります。
![\[AWS OpsWorks stack architecture with load balancer, application servers, and RDS instance.\]](http://docs.aws.amazon.com/ja_jp/opsworks/latest/userguide/images/php_walkthrough_arch_4.png)
OpsWorks スタックを使用すると、スタックを簡単にスケールアウトできます。このセクションでは、2 番目の 24/7 PHP アプリケーションサーバー インスタンスを MyStack に追加し、両方のインスタンスを Elastic Load Balancing ロードバランサーの後ろに配置することにより、スタックを拡張する方法の基本について説明します。プロシージャを簡単に拡張して任意の数の 24/7 インスタンスを追加するか、時間ベースまたは負荷ベースのインスタンスを使用して OpsWorks スタックを自動的にスケーリングできます。詳細については、「[時間ベースおよび負荷ベースのインスタンスによる負荷の管理](workinginstances-autoscaling.md)」を参照してください。
# ステップ 4.1: Load Balancer の追加
**重要**
この AWS OpsWorks Stacks サービスは 2024 年 5 月 26 日にサポート終了となり、新規および既存のお客様の両方で無効になっています。できるだけ早くワークロードを他のソリューションに移行することを強くお勧めします。移行についてご質問がある場合は、[AWS re:Post](https://repost.aws/) または[AWS プレミアムサポート](https://aws.amazon.com/support)を通じて AWS サポート チームにお問い合わせください。
Elastic Load Balancing は、受信アプリケーショントラフィックを複数の Amazon EC2 インスタンスに自動的に分散させる AWS サービスです。Elastic Load Balancing は、トラフィックの分散の他に、以下のことも行います。
+ 健全でない Amazon EC2 インスタンスを検出します。
問題のあるインスタンスが復旧するまで、トラフィックのルートを残りの正常なインスタンスに変更します。
+ 着信トラフィックに応じて、自動的にそのリクエスト処理能力を拡張します。
**注記**
ロードバランサーで 2 つの目的を達成できます。明らかな目的は、アプリケーションサーバーで負荷を均等化することです。さらに、多くのサイトでは、ユーザーがアプリケーションサーバーおよびデータベースに直接アクセスできないようにすることが求められます。 OpsWorks スタックでは、次のようにパブリックサブネットとプライベートサブネットを持つ Virtual Private Cloud (VPC) でスタックを実行することでこれを行うことができます。
アプリケーションサーバーおよびデータベースをプライベートサブネットに配置します。VPC 内の他のインスタンスはこれらにアクセスできますが、ユーザーはアクセスできません。
パブリックサブネット内のロードバランサーにユーザートラフィックを送ると、このトラフィックはプライベートサブネット内のアプリケーションサーバーに転送され、ユーザーにレスポンスが返されます。
詳細については、「[VPC でのスタックの実行](workingstacks-vpc.md)」を参照してください。このチュートリアルの例を拡張して VPC で実行する CloudFormation テンプレートについては、 [`OpsWorksVPCtemplates.zip` ファイル](samples/OpsWorksVPCtemplates.zip)をダウンロードします。
多くの場合、Elastic Load Balancing はレイヤーと呼ばれますが、他の組み込みレイヤーとは動作が多少異なります。レイヤーを作成してインスタンスを追加する代わりに、Amazon EC2 コンソールを使用して Elastic Load Balancing ロードバランサーを作成し、それを既存のレイヤーの 1 つ、通常はアプリケーションサーバーレイヤーにアタッチします。 OpsWorks スタックはレイヤーの既存のインスタンスをサービスに登録し、新しいインスタンスを自動的に追加します。次の手順は、ロードバランサーを MyStack の PHP アプリケーションサーバーレイヤーに追加する方法を説明しています。
**注記**
OpsWorks スタックは Application Load Balancer をサポートしていません。Classic Load Balancer は OpsWorks スタックでのみ使用できます。
**ロードバランサーを PHP アプリケーションサーバーレイヤーにアタッチするには**
1. Amazon EC2 コンソールを使用して、MyStack の新しいロードバランサーを作成します。アカウントで EC2 Classic をサポートするかどうかによって詳細が異なります。詳細については、「[Elastic Load Balancing の開始方法](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/load-balancer-getting-started.html)」を参照してください。[**Create Load Balancer**] ウィザードを実行するときに、ロードバランサーを次のように設定します。
**Load Balancer の定義**
ロードバランサーに PHP-LB などのわかりやすい名前を割り当てて、 OpsWorks スタックコンソールで見つけやすくします。次に [**Continue**] を選択し、残りの設定のデフォルト値を受け入れます。
[**Create LB Inside**] メニューから 1 つ以上のサブネットがある VPC を選択する場合は、ロードバランサーでトラフィックをルーティングするアベイラビリティーゾーンごとにサブネットを選択する必要があります。
**セキュリティグループの割り当て**
アカウントでデフォルト VPC がサポートされている場合は、このページがウィザードに表示され、ロードバランサーのセキュリティグループを決定できます。EC2 Classic の場合、このページは表示されません。
このウォークスルーでは、[**default VPC security group**] を選択します。
**セキュリティ設定の構成**
**[Define Load Balancer]** (Load Balancer の定義) ページで、**[Load Balancer Protocol]** (Load Balancer プロトコル) として **[HTTPS]** を選択した場合、このページで証明書、暗号、および SSL プロトコルの設定を構成します。このウォークスルーでは、デフォルト値を受け入れ、[**Configure Health Check**] を選択します。
**ヘルスチェックの設定**
ping パスに **/** を設定し、残りの設定にデフォルト値を受け入れます。
**EC2 インスタンスの追加**
**Continue**; を選択します。 OpsWorks スタックはロードバランサーにインスタンスを自動的に登録します。
**タグの追加**
タグを追加すると検索しやすくなります。各タグはキーと値のペアです。たとえば、このウォークスルーでは、キーとして「**Description**」、値として「**Test LB**」を指定できます。
**確認**
選択内容を確認して [**Create**] を選択し、次に [**Close**] を選択すると、ロードバランサーが起動します。
1. アカウントでデフォルト VPC がサポートされている場合は、ロードバランサーを起動した後で、セキュリティグループに適切な進入ルールがあることを確認する必要があります。デフォルトルールでは、着信トラフィックは受け入れられません。
1. Amazon EC2 のナビゲーションペインで、**[Security Groups]** (セキュリティグループ) を選択します。
1. [**default VPC security group**] を選択します。
1. **[Inbound]** (インバウンド) タブで、**[Edit]** (編集) を選択します。
1. このウォークスルーでは、**[Source]** を **[Anywhere]** に設定します。これにより、ロードバランサーでは任意の IP アドレスからの着信トラフィックを受け入れます。
1. OpsWorks スタックコンソールに戻ります。[**Layers**] (レイヤー) ページで、レイヤーの [**Network**] (ネットワーク) リンクを選択し、[**Edit**] (編集) を選択します。
1. [**Elastic Load Balancing**] で、ステップ 1 で作成した ロードバランサーを選択し、[**Save**] を選択します。
![\[Dropdown menu for Elastic Load Balancer selection with options "Available ELBs" and "None".\]](http://docs.aws.amazon.com/ja_jp/opsworks/latest/userguide/images/elb_select.png)
ロードバランサーをレイヤーにアタッチすると、 OpsWorks Stacks はレイヤーの現在のインスタンスを自動的に登録し、オンラインになると新しいインスタンスを追加します。
1. [**Layers**] (レイヤー) ページで、ロードバランサーの名前をクリックして詳細ページを開きます。登録が完了し、インスタンスがヘルスチェックに合格すると、ロードバランサーページのインスタンスの横に緑色のチェックマークが OpsWorks スタックに表示されます。
![\[Elastic Load Balancing details page showing one EC2 instance in US-west-2a with InService status.\]](http://docs.aws.amazon.com/ja_jp/opsworks/latest/userguide/images/elb_properties3.png)
これで、ロードバランサーにリクエストを送信することによって SimplePHPApp を実行できます。
**ロードバランサーを通じて SimplePHPApp を実行するには**
1. ロードバランサーの詳細ページを再度開きます (開いていない場合)。
1. プロパティページで、インスタンスのヘルスチェックステータスを確認し、ロードバランサーの DNS 名をクリックして SimplePHPApp を実行します。ロードバランサーが PHP アプリケーションサーバーインスタンスにリクエストを転送すると、レスポンスが返されます。これは、PHP アプリケーションサーバーインスタンスのパブリック IP アドレスをクリックした場合とまったく同じレスポンスになるはずです。
![\[Elastic Load Balancing settings showing DNS name for PHP-LB in US West region.\]](http://docs.aws.amazon.com/ja_jp/opsworks/latest/userguide/images/elb_properties2.png)
**注記**
OpsWorks スタックは HAProxy ロードバランサーもサポートしており、一部のアプリケーションには利点がある場合があります。詳細については、「[HAProxy OpsWorks スタックレイヤー](layers-haproxy.md)」を参照してください。
# ステップ 4.2: PHP アプリケーションサーバーインスタンスの追加
**重要**
この AWS OpsWorks Stacks サービスは 2024 年 5 月 26 日にサポート終了となり、新規および既存のお客様の両方で無効になっています。できるだけ早くワークロードを他のソリューションに移行することを強くお勧めします。移行についてご質問がある場合は、[AWS re:Post](https://repost.aws/) または[AWS プレミアムサポート](https://aws.amazon.com/support)を通じて AWS サポート チームにお問い合わせください。
ロードバランサーが適切に配置されたので、インスタンスを PHP アプリケーションサーバーレイヤーに追加することによりスタックを拡張できます。ユーザーから見た場合、このオペレーションはシームレスです。新しい PHP App Server インスタンスがオンラインになるたびに、 OpsWorks スタックはロードバランサーに自動的に登録して SimplePHPApp をデプロイするため、サーバーは受信トラフィックの処理をすぐに開始できます。簡略にするために、このトピックでは 1 つの追加 PHP アプリケーションサーバー インスタンスの追加方法を示しますが、同じ方法で必要な数だけ追加できます。
**別のインスタンスを PHP アプリケーションサーバーレイヤーに追加するには**
1. [Instances] ページの **[PHP App Server]** (PHP アプリケーションサーバー) で **[\$1 Instance]** (\$1 インスタンス) をクリックします。
1. デフォルト設定を受け入れて、[**Add Instance**] をクリックします。
1. [**start**] をクリックしてインスタンスを開始します。
# ステップ 4.3: MyStack の監視
**重要**
この AWS OpsWorks Stacks サービスは 2024 年 5 月 26 日にサポート終了となり、新規および既存のお客様の両方で無効になっています。できるだけ早くワークロードを他のソリューションに移行することを強くお勧めします。移行についてご質問がある場合は、[AWS re:Post](https://repost.aws/) または[AWS プレミアムサポート](https://aws.amazon.com/support)を通じて AWS サポート チームにお問い合わせください。
OpsWorks スタックは Amazon CloudWatch を使用してスタックのメトリクスを提供し、**モニタリング**ページで便宜上要約します。スタック全体、特定のレイヤー、特定のインスタンスに対するメトリクスを閲覧することができます。
**MyStack を監視するには**
1. ナビゲーションペインで [**Monitoring**] をクリックすると、各レイヤーの平均メトリクスを含む一連のグラフが表示されます。[**CPU System**]、[**Memory Used**]、および [**Load**] のメニューを使用してさまざまな関連メトリクスを表示できます。
![\[Monitoring dashboard showing CPU, memory, load, and process metrics over time for system layers.\]](http://docs.aws.amazon.com/ja_jp/opsworks/latest/userguide/images/monitor_stack.png)
1. [**PHP App Server**] をクリックすると、レイヤーのインスタンスごとのメトリクスが表示されます。
![\[Dashboard showing CPU, memory, load, and processes metrics for Layer PHP App Server over time.\]](http://docs.aws.amazon.com/ja_jp/opsworks/latest/userguide/images/monitor_layer.png)
1. [**php-app1**] をクリックすると、そのインスタンスのメトリクスが表示されます。スライダーを動かすことで、特定の時点のメトリクスを確認することができます。
![\[Dashboard showing CPU, memory, load, and process metrics for a PHP application instance.\]](http://docs.aws.amazon.com/ja_jp/opsworks/latest/userguide/images/monitor_instance.png)
**注記**
OpsWorks スタックは Ganglia モニタリングサーバーもサポートしており、一部のアプリケーションには利点がある場合があります。詳細については、「[Ganglia レイヤー](workinglayers-ganglia.md)」を参照してください。