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

# Beanstalk クラスター環境のスケーリング
<a name="configuring-cluster-scaling"></a>

Beanstalk クラスター環境は、実行するアプリケーションの*レプリカ*の数を変更することでスケールされます。レプリカは、コンテナイメージのコピーを実行している 1 つです。Amazon EKS は、それらのレプリカに必要なノード容量を提供し、それらに合わせてノードを追加または削除するため、インスタンスのフリートではなくアプリケーションのサイズを設定します。

これは、Amazon EC2 インスタンスの Auto Scaling グループをスケールする Beanstalk Standard との主な違いです。`aws:autoscaling:*` 名前空間は Beanstalk クラスター環境には適用されません。スケーリングは、代わりに `aws:elasticbeanstalk:eks:environment:autoscaling`名前空間とその子名前空間を介して設定されます。すべてのオプションとその受け入れられる値については、「」を参照してください[Beanstalk クラスター環境の設定オプション](command-options-general-eks.md)。

## レプリカの境界の設定
<a name="configuring-cluster-scaling-replicas"></a>

レプリカ数には、 `min-replica`と の 2 つのオプションがあり`max-replica`、どちらも`aws:elasticbeanstalk:eks:environment:autoscaling`名前空間にあります。Elastic Beanstalk は、それらの間のレプリカ数を維持します。

固定数のレプリカを実行するには、両方のオプションを同じ値に設定します。より`max-replica`高く設定`min-replica`すると、環境が 2 つの間でスケールされます。は最小値`1`として `min-replica` を受け入れるため、環境は常に少なくとも 1 つのレプリカを実行します。

```
$ aws elasticbeanstalk update-environment \
    --environment-name {{my-cluster-env}} \
    --option-settings \
        Namespace=aws:elasticbeanstalk:eks:environment:autoscaling,OptionName=min-replica,Value=2 \
        Namespace=aws:elasticbeanstalk:eks:environment:autoscaling,OptionName=max-replica,Value=20
```

## Elastic Beanstalk がスケーリングするタイミングを決定する方法
<a name="configuring-cluster-scaling-triggers"></a>

これらの境界内では、1 つ以上の*トリガー*がレプリカ数を決定します。Elastic Beanstalk は、 が`polling-interval`設定した間隔でトリガーを評価します。トリガーがレポートアクティビティを停止すると、Elastic Beanstalk は環境をスケールダウンする前に が`cooldown-period`設定した期間待機します。これにより、再び必要になるレプリカが短時間で削除されなくなります。

トリガーをまったく設定しない場合、環境はレプリカの CPU 使用率に基づいてスケールされます。残りのセクションでは、代わりに設定できるトリガーについて説明します。

## CPU またはメモリでのスケーリング
<a name="configuring-cluster-scaling-cpu-memory"></a>

レプリカが消費するリソースをスケールオンするには、`aws:elasticbeanstalk:eks:environment:autoscaling:trigger`名前空間にメトリクスタイプとターゲット値を設定します。Elastic Beanstalk は、設定したターゲットの近くに環境を保持するためのレプリカを追加または削除します。
+ CPU の場合は、 `cpu-metric-type`と を設定します`cpu-value`。
+ メモリの場合は、 `memory-metric-type`と を設定します`memory-value`。

のメトリクスタイプは、 `cpu`および `memory`オプションを通じてレプリカが予約する値の割合として`Utilization`値を扱うため、 `cpu-value`の は予約された CPU の 75% を`75`ターゲットにします。のメトリクスタイプは、値をレプリカあたりの絶対量として`AverageValue`扱います。

CPU トリガーとメモリトリガーの両方を 1 つの環境で設定できます。

```
$ aws elasticbeanstalk update-environment \
    --environment-name {{my-cluster-env}} \
    --option-settings \
        Namespace=aws:elasticbeanstalk:eks:environment:autoscaling:trigger,OptionName=cpu-metric-type,Value=Utilization \
        Namespace=aws:elasticbeanstalk:eks:environment:autoscaling:trigger,OptionName=cpu-value,Value=75
```

## スケジュールに基づくスケーリング
<a name="configuring-cluster-scaling-schedule"></a>

定期的な時間枠中に選択した数のレプリカを実行するには、 `scaler-type`を に設定`cron`し、 でウィンドウを記述します。これにより`scaler-metadata`、4 つのフィールドを持つ JSON オブジェクトが取得されます。


| フィールド | 説明 | 
| --- | --- | 
| timezone | ウィンドウのタイムゾーン。、、 UTC America/New\_Yorkなどの IANA タイムゾーン名として表されますAsia/Tokyo。 | 
| start | ウィンドウが開くと、5 つのフィールド cron 式 (分、時間、日、月、曜日) として表示されます。 | 
| end | ウィンドウが閉じられたら、同じ形式になります。 | 
| desiredReplicas | ウィンドウが開いている間に実行するレプリカの数。min-replica および max-replica 境界内の値を選択します。 | 

ウィンドウの外では、環境は に戻ります`min-replica`。次の例では、UTC で平日の勤務時間中に 5 つのレプリカを実行します。

```
$ cat schedule.json
[
  {
    "Namespace": "aws:elasticbeanstalk:eks:environment:autoscaling:trigger",
    "OptionName": "scaler-type",
    "Value": "cron"
  },
  {
    "Namespace": "aws:elasticbeanstalk:eks:environment:autoscaling:trigger",
    "OptionName": "scaler-metadata",
    "Value": "{\"timezone\":\"UTC\",\"start\":\"0 8 * * 1-5\",\"end\":\"0 18 * * 1-5\",\"desiredReplicas\":\"5\"}"
  }
]
$ aws elasticbeanstalk update-environment \
    --environment-name {{my-cluster-env}} \
    --option-settings file://schedule.json
```

環境は 1 つのスケジュールに従います。異なる週末スケジュールなど、複数のウィンドウでレプリカ数を変更するには、「」で説明されているように、スケジュールを別のトリガーと組み合わせてください[トリガーの組み合わせ](#configuring-cluster-scaling-combining)。

**注記**  
`scaler-metadata` 値自体が JSON ドキュメントであるため、設定は ファイルに含まれます。が に AWS CLI 受け入れるフォームについては`--option-settings`、[『』の「短縮構文の使用 AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-usage-shorthand.html)」を参照してください。

## 独自のエンドポイントからのメトリクスのスケーリング
<a name="configuring-cluster-scaling-metrics-api"></a>

キューの深さや処理中のジョブの数など、独自のサービスが報告する値をスケールアップするには、 `scaler-type`を に設定します`metrics-api`。Elastic Beanstalk は、指定した HTTP エンドポイントを読み取り、そこで見つかった数値に基づいてスケーリングします。でエンドポイントを記述します`scaler-metadata`。


| フィールド | 説明 | 
| --- | --- | 
| url | Elastic Beanstalk が読み取るエンドポイント。 | 
| valueLocation | 数値が点線のパスとして JSON レスポンスにある場所。のレスポンス本文の場合{"data":{"result":[{"value":"500"}]}}、場所は ですdata.result.0.value。 | 
| targetValue | 1 つのレプリカが処理することが予想される量。 | 

Elastic Beanstalk は、報告された値を で除算`targetValue`し、切り上げてレプリカ数を取得し、その数をレプリカの境界内に保持します。`targetValue` が の場合`100`、報告された の値は 5 つのレプリカを要求`500`します。

トリガーは独自の環境にポイントできます。環境の URL は起動後にのみ認識されるため、作成時ではなく`url`更新時に を設定します。

次の例では、アプリケーションが報告する深さに基づいてスケールし、報告された作業の 100 ユニットごとに 1 つのレプリカを使用します。

```
$ cat trigger.json
[
  {
    "Namespace": "aws:elasticbeanstalk:eks:environment:autoscaling:trigger",
    "OptionName": "scaler-type",
    "Value": "metrics-api"
  },
  {
    "Namespace": "aws:elasticbeanstalk:eks:environment:autoscaling:trigger",
    "OptionName": "scaler-metadata",
    "Value": "{\"url\":\"https://{{my-service.example.com}}/queue-depth\",\"valueLocation\":\"data.result.0.value\",\"targetValue\":\"100\"}"
  }
]
$ aws elasticbeanstalk update-environment \
    --environment-name {{my-cluster-env}} \
    --option-settings file://trigger.json
```

### エンドポイントへの認証
<a name="configuring-cluster-scaling-metrics-api-auth"></a>

エンドポイントに認証情報が必要な場合は、それらを AWS Secrets Manager シークレットに保存し、シークレットの ARN `scaler-auth-secret`に設定します。`scaler-type` が の場合にのみ設定できます`metrics-api`。エンドポイントが想定するスキーム`scaler-auth-mode`に設定します。シークレットの値は、そのスキームに依存するキーを持つ JSON オブジェクトです。


| [Authentication mode] (認証モード) | シークレットに必要なキー | 
| --- | --- | 
| bearer、デフォルト | token | 
| basic | username および password | 
| apiKey | apiKey | 
| tls | ca、cert、および key | 

環境`application-role`のオプションも設定します。Elastic Beanstalk は、 `application-role`が設定されている場合にのみ存在する環境の Pod Identity を介して認証情報をレプリカにマウントします。これがないと、マウントは失敗し、レプリカは起動しません。スケジュールトリガーはそれを必要としません。また、認証情報を必要としないメトリクスエンドポイントも必要としません。

環境の*アプリケーションロール*はシークレットを読み取るため、シークレットの ARN `secretsmanager:DescribeSecret`で `secretsmanager:GetSecretValue`と の両方を付与します。Elastic Beanstalk は、スケジュールに従って認証情報を更新し、更新によってシークレットの最新バージョンがチェックされるため、付与された環境は正常に`GetSecretValue`のみ開始され、それ以降の更新ごとに失敗します。Beanstalk クラスター環境が使用するロールについては、「」を参照してください[Beanstalk クラスターのアクセス許可](beanstalk-cluster-permissions.md)。

このシークレットは、アプリケーションにシークレットを提供する `secrets`オプションとは別のものです。の値を変更すると、レプリカの起動時に認証情報がマウントされるため、環境のレプリカが`scaler-auth-secret`置き換えられます。

## トリガーの組み合わせ
<a name="configuring-cluster-scaling-combining"></a>

環境は、スケジュールまたはエンドポイントメトリクスのいずれかのイベント駆動型トリガーを 1 つ受け取ります。これは、 `scaler-type`と が 1 つのトリガーを`scaler-metadata`記述するためです。CPU とメモリのトリガーをそのトリガーと一緒に持ち込むことができます。

2 つの動作を組み合わせる前に知る価値があります。
+ を設定すると、「」で説明されているデフォルトの CPU スケーリングが`scaler-type`置き換えられます[Elastic Beanstalk がスケーリングするタイミングを決定する方法](#configuring-cluster-scaling-triggers)。CPU のスケーリングを維持するには、 `cpu-metric-type`と を`cpu-value`明示的に設定します。
+ 複数のトリガーが適用されると、レプリカ数の最大値が優先されます。5 つのレプリカを要求するスケジュールと、3 つのプロデューサー 5 を要求する CPU トリガー。

スケジュールと CPU トリガーをペアリングすることは一般的な組み合わせです。スケジュールはビジー時間中に予想されるレプリカ数を保持し、CPU トリガーは残りの時間利用可能のままです。

## 環境スケールの監視
<a name="configuring-cluster-scaling-watching"></a>

Elastic Beanstalk コンソールの環境のモニタリングページには、**アプリケーションのレプリカ数**グラフが表示されます。このグラフは、環境が時間の経過とともに実行されているレプリカを報告します。**CPU (コア)** グラフと**メモリ (バイト) **グラフと比較すると、トリガーがターゲットを保持しているかどうかがわかります。Beanstalk クラスター環境が報告するヘルスとメトリクスについては、「」を参照してください[Beanstalk クラスター環境のモニタリング](monitoring-cluster-environments.md)。

Elastic Beanstalk はスケーリング設定を変更すると環境イベントを記録するため、環境のイベントストリームにはスケーリング変更が有効になった日時が表示されます。