翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 # Beanstalk クラスターアーキテクチャ Beanstalk クラスターは、Beanstalk Standard と同じ Elastic Beanstalk アプリケーション、アプリケーションバージョン、環境、および設定オプションの概念を使用します。Beanstalk Standard は EC2-based環境タイプです。Beanstalk クラスターは、別のコンピューティングレイヤーと設定表面を使用します。このトピックでは、相違点を側面別に説明し、該当する環境タイプを特定します。 ## コンピューティングモデル Beanstalk Standard では、Elastic Beanstalk は環境専用の Auto Scaling グループで Amazon Elastic Compute Cloud (Amazon EC2) インスタンスを起動します。アプリケーションはこれらのインスタンスで直接実行されます。Beanstalk クラスター環境では、Elastic Beanstalk は代わりにアプリケーションを Amazon EKS クラスター上のコンテナイメージとして実行し、これを Beanstalk クラスター環境で共有できます。Elastic Beanstalk はクラスターを作成して操作します。Elastic Beanstalk はアプリケーションをクラスターにスケジュールします。Elastic Beanstalk はクラスター上の各環境を分離し、設定された値と一致するようにアプリケーションレプリカの数を調整します。クラスターを作成したり、環境が実行されるクラスターを選択したり、Kubernetes バージョンを選択したりすることはありません。 一部の環境は、同じ Amazon EKS クラスターで実行できます。Elastic Beanstalk は、設定された VPC サブネットを提供する環境をクラスターに配置します。これらのサブネットが初めて使用されるときにクラスターが作成されます。「」を参照してください[環境のグループ化](#beanstalk-cluster-clusters-sharing)。Amazon EKS Auto Mode はノード容量を提供します。スケジュールされたコンテナに合わせてノードを追加および削除します。クラスターは共有でき、ノード容量は Amazon EKS によって管理されるため、インスタンス数は `aws:autoscaling:asg`名前空間では設定されません。代わりに、アプリケーションレプリカの数は`aws:elasticbeanstalk:eks:environment:autoscaling`、名前空間の `min-replica`および `max-replica`オプションで設定されます。レプリカの境界とレプリカ数を変更するトリガーについては、「」を参照してください[Beanstalk クラスター環境のスケーリング](configuring-cluster-scaling.md)。 Elastic Beanstalk は、指定したオプション設定から環境の設定を解決し、環境を作成または更新するときに解決された設定を適用します。同じ設定オプションが複数回提供されると、最後のオカレンスが優先されます。設定を変更するには、オプション設定を更新します。 ## Beanstalk Standard との違い 次の表は、Beanstalk Standard と Beanstalk クラスター環境の顧客向けの違いをまとめたものです。各行は、Elastic Beanstalk の概念を詳しく説明するトピックにリンクされています。 | 側面 | Beanstalk 標準 | Beanstalk クラスター環境 | | --- | --- | --- | | コンピューティング | aws:autoscaling:\* 名前空間を介して設定された Auto Scaling グループ内の専用 Amazon EC2 インスタンス。 | Beanstalk クラスター環境で共有できる Amazon EKS クラスターにスケジュールされたコンテナ。Elastic Beanstalk は、クラスター上の各環境を分離します。ノードは Amazon EKS Auto Mode によって提供されます。 | | スケーリング | Amazon EC2 インスタンスは Auto Scaling グループによって追加および削除され、トリガーとスケジュールされたアクションがaws:autoscaling:\*名前空間を介して設定されます。「[Elastic Beanstalk 環境インスタンスの Auto Scaling](using-features.managing.as.md)」を参照してください。 | アプリケーションレプリカは、CPU、メモリ、スケジュール、または独自のエンドポイントが報告するメトリクスで、 min-replica および max-replica 境界内で追加および削除されました。「[Beanstalk クラスター環境のスケーリング](configuring-cluster-scaling.md)」を参照してください。 | | デプロイアーティファクト | Elastic Beanstalk がプラットフォーム (ソリューションスタック) AMI で実行するソースバンドル。「[Elastic Beanstalk でサポートされているプラットフォーム](concepts.platforms.md)」を参照してください。 | Amazon Elastic Container Registry (Amazon ECR) のコンテナイメージ。イメージは直接提供されるか、Elastic Beanstalk がイメージに組み込むためのソースが提供されます。「[Beanstalk クラスター環境のコンテナイメージの構築](beanstalk-cluster-app-versions.md)」を参照してください。 | | プラットフォームの概念 | マネージドソリューションスタック (AMI 上のオペレーティングシステム、ウェブサーバー、言語ランタイム）。「[Elastic Beanstalk でサポートされているプラットフォーム](concepts.platforms.md)」を参照してください。 | ソリューションスタックまたは AMI はありません。ランタイムは、コンテナイメージと Elastic Beanstalk が作成するクラスターのバージョンによって定義されます。 | | デプロイメントポリシー | aws:elasticbeanstalk:command 名前空間を介して設定されたAll-at-onceデプロイ、ローリングデプロイ、またはイミュータブルデプロイ。 | aws:elasticbeanstalk:eks:environment:deployment 名前空間の strategyオプションで設定された、ローリング更新 (デフォルト) または一度にすべて。一度にすべての のオプション値は ですRecreate。 | | 設定名前空間 | aws:autoscaling:\* や などのクラシック名前空間aws:elasticbeanstalk:environment。「[設定オプション](command-options.md)」を参照してください。 | aws:elasticbeanstalk:eks:\* 名前空間。従来のコンピューティング名前空間は適用されません。 | | 健康 | 各インスタンスのホストマネージャーとロードバランサーから報告されます。 | インスタンスごとのヘルスは報告されません。Application Load Balancer では、ヘルスには Elastic Beanstalk が評価するロードバランサーメトリクスが含まれます。ではload-balancer-type=None、そのリクエストレート、エラーレート、レイテンシーの評価は適用されません。「[Beanstalk クラスター環境のモニタリング](monitoring-cluster-environments.md)」を参照してください。 | ## お客様が提供するリソースとサービスマネージドリソース Elastic Beanstalk は、Beanstalk クラスター環境を実行する Amazon EKS クラスターを作成して運用します。Amazon EKS に必要なクラスターとノード AWS Identity and Access Management (IAM) ロールは、お客様が用意しています。Elastic Beanstalk ではクラスター上のすべての環境が同じロールを提供する必要があるため[Beanstalk クラスターのアクセス許可](beanstalk-cluster-permissions.md)、 で説明されているロール名と AWS 管理ポリシーを使用することをお勧めします。アプリケーションロールは、Amazon EKS Pod Identity を介して実行中のアプリケーションに提供することもできます。アプリケーションロールは、環境の作成時に Elastic Beanstalk コンソールで選択されます。完全な IAM 責任モデルとアプリケーションロールの手順については、「」を参照してください[Beanstalk クラスターのアクセス許可](beanstalk-cluster-permissions.md)。 環境の VPC サブネットはオプションです。サブネットを省略すると、Elastic Beanstalk はデフォルト VPC のパブリックサブネットを使用します。サブネットセットは、環境を実行するクラスターを決定します。クラスターの割り当てと Elastic Beanstalk が動作するインフラストラクチャについては、「」を参照してください[環境のグループ化](#beanstalk-cluster-clusters-sharing)。 Elastic Beanstalk は、サービスが作成したクラスターでアプリケーションを操作します。コンテナイメージをデプロイし、`aws:elasticbeanstalk:eks:environment:deployment`名前空間を通じてローリング更新を適用します。実行中のアプリケーションレプリカの数を、設定の `min-replica`および `max-replica` 境界と照合します。「」で説明されているヘルスステータスを通じて環境レベルのヘルスを報告します[Beanstalk クラスター環境のモニタリング](monitoring-cluster-environments.md)。Elastic Beanstalk は、サービスマネージドとして環境を割り当てる各クラスターを追跡します。 **重要** Elastic Beanstalk は、予想されるサービスマネージド設定に一致するクラスターにのみ環境を割り当てます。インフラストラクチャがその設定と一致しなくなった場合、Elastic Beanstalk は新しい環境のクラスターの選択を停止します。環境の変更は、Elastic Beanstalk のオペレーションと設定を通じて行われます。 ## アプリケーションの要件と制限 Beanstalk クラスター環境には、コンテナイメージおよび 1 つ以上の同一の交換可能なレプリカとして実行できるアプリケーションが必要です。ロードバランサーはオプションです。ロードバランサーを設定すると、アプリケーションレプリカ間でリクエストが分散されます。再起動後も存続する必要があるローカル状態がレプリカに保持されないステートレスウェブサービスまたは API は、この要件を満たします。リクエストポート、CPU およびメモリリクエスト、アプリケーションレプリカの数、デプロイ動作は、 `aws:elasticbeanstalk:eks:*`オプションを使用して設定されます。Elastic Beanstalk は、Amazon EKS Auto Mode を通じてクラスター容量を提供します。 Beanstalk クラスター環境を作成する前に、次のアプリケーションの要件と制限を確認してください。 + ローカルストレージは永続的ではありません。アプリケーションの各コピーにはエフェメラルストレージがあり、コピーの再起動時に失われます。アップロード、キャッシュ、または作業ファイルをローカルディスクに書き込み、再起動後も存続する必要があるアプリケーションは、外部永続ストレージなしでは互換性がありません。 + リクエストはアプリケーションレプリカ全体に分散されます。 + Elastic Beanstalk は、サポートされている言語のソースからコンテナイメージを構築します。Dockerfile またはビルド済みイメージを指定することもできます。「[Beanstalk クラスター環境のコンテナイメージの構築](beanstalk-cluster-app-versions.md)」を参照してください。 ## 設定例 次の AWS CLI リクエストは、Beanstalk クラスター環境のリクエストポート、メモリリクエスト、実行中のレプリカの数、デプロイ動作を設定します。設定では、 `aws:elasticbeanstalk:eks:*`名前空間を使用します。 ``` $ aws elasticbeanstalk update-environment \ --environment-name my-cluster-env \ --option-settings \ Namespace=aws:elasticbeanstalk:eks:environment,OptionName=service-port,Value=8080 \ Namespace=aws:elasticbeanstalk:eks:environment,OptionName=memory,Value=1Gi \ Namespace=aws:elasticbeanstalk:eks:environment,OptionName=load-balancer-type,Value=ALB \ Namespace=aws:elasticbeanstalk:eks:environment:autoscaling,OptionName=min-replica,Value=3 \ Namespace=aws:elasticbeanstalk:eks:environment:autoscaling,OptionName=max-replica,Value=3 \ Namespace=aws:elasticbeanstalk:eks:environment:deployment,OptionName=strategy,Value=RollingUpdate \ Namespace=aws:elasticbeanstalk:eks:environment:deployment:strategy:rolling,OptionName=max-surge,Value=25% \ Namespace=aws:elasticbeanstalk:eks:environment:deployment:strategy:rolling,OptionName=max-unavailable,Value=0 ``` `strategy` オプションは `RollingUpdate`または を受け入れます。これは`Recreate`、コンソールがローリング更新として、また一度にすべてとして表示します。では`RollingUpdate`、デプロイ中に Elastic Beanstalk が開始する追加のレプリカの数`max-surge`を制限します。`max-unavailable` オプションは、一度にダウンする既存のレプリカの数を制限します。各オプションはカウントまたはパーセンテージを受け入れます。`memory` 値は、 `1Gi`や などの Kubernetes 数量表記を使用します`512Mi`。オプションの完全なセットについては、「」を参照してください[Beanstalk クラスター環境の設定オプション](command-options-general-eks.md)。 ## 環境のグループ化 Elastic Beanstalk は、使用する VPC サブネットによって Beanstalk クラスター環境をクラスターにグループ化します。 + 同じサブネットセットを使用する同じ AWS アカウントの環境は、*同じ*クラスターで実行されます。 + 異なるサブネットセットを使用する環境は、*異なる*クラスターで実行されます。 特定のサブネットセットで作成した最初の環境では、Elastic Beanstalk によってクラスターが作成されます。これには約 10 分かかります。Elastic Beanstalk は、これを環境のイベントで報告します。 ``` INFO Creating CloudFormation stack for cluster infrastructure. This is a one-time operation and generally takes about 10 minutes. stack='beanstalk-cluster-{{uuid}}' INFO Starting cluster assignment. environment='my-cluster-env' INFO Successfully completed cluster assignment. environment='my-cluster-env' clusterArn='arn:aws:eks:us-east-1:{{111122223333}}:cluster/beanstalk-cluster-{{uuid}}' ``` Elastic Beanstalk は、既存のクラスターに同じサブネットを使用する後の環境を配置します。これらのイベントは、スタック作成メッセージなしで割り当てを報告します。Elastic Beanstalk は、クラスターとそれを作成する AWS CloudFormation スタックの両方に名前を付けます`beanstalk-cluster-{{uuid}}`。 Elastic Beanstalk がサブネットを考慮する順序は重要ではありません。異なる順序で同じサブネットが同じセットです。サブネットセットのみがクラスターを選択します。クラスターがすでにサブネットセットに登録されている場合、指定するクラスターとノードのロール設定は、そのクラスターに登録されているロールと一致する必要があります。Elastic Beanstalk は競合するロール設定を拒否します。異なるロール ARNs は別のクラスターを選択しません。オブザーバビリティロールも指定すると、Elastic Beanstalk はクラスターに対して同じ方法で検証します。オプションのアプリケーションロールは環境に属し、環境によって異なる場合があります。「」の環境作成手順で設定します[アプリケーションロールを設定する](beanstalk-cluster-permissions.md#beanstalk-cluster-permissions-application-role)。 Elastic Beanstalk は、クラスターを共有する環境の数を制限しません。Amazon EKS Auto Mode は、クラスターでスケジュールされたコンテナに合わせてノードを追加します。クラスター共有では、環境固有のスケーリング制限は追加されません。各環境には、設定されたレプリカまたは自動スケーリングの制限、該当するサービスクォータ、使用可能な容量が適用されます。別のクラスターで環境を実行するには、別のサブネットセットで環境を作成します。 **重要** 既存の Beanstalk クラスター環境のサブネット、クラスター、ノード、オブザーバビリティロールを変更することはできません。Elastic Beanstalk は、環境を別のクラスターに移動するのではなく、このような更新を拒否し、レポートします。アプリケーションを別のサブネットまたはロールに移動する`Changes to EKS cluster configuration (subnets and IAM roles) are not currently supported for an existing environment. Please revert these option settings to continue.`には、必要な設定で新しい環境を作成し、2 つの環境 CNAMEs を交換します。「[Elastic Beanstalk を使用したブルー/グリーンデプロイ](using-features.CNAMESwap.md)」を参照してください。環境の作成時に使用するサブネットとクラスターロールを決定します。「[Beanstalk クラスターの開始方法](beanstalk-cluster-getting-started.md)」を参照してください。 ## コンピューティングを共有する環境間の分離 サブネットは環境間の主要な境界です。サブネットセットはクラスターを選択するため、環境のグループに独自のサブネットを与えると、そのグループには独自のクラスター、独自のノード、および独自のネットワークが与えられます。単一のクラスター内では、Elastic Beanstalk はデフォルトで Beanstalk クラスター環境間のネットワークトラフィックを分離します。 `aws:elasticbeanstalk:eks:environment`名前空間のオプションを使用すると、特定の環境が通信したり、専用ノードに環境を配置したりできます。 各選択肢の境界、その範囲を広げるオプション、共有クラスターが分離しないものについては、「」を参照してください[Beanstalk クラスター環境のマルチテナンシー](beanstalk-cluster-multi-tenancy.md)。 ## マネージドインフラストラクチャ設定 Elastic Beanstalk は、ユーザーが選択しない固定設定で各クラスターを作成します。 | 設定 | Elastic Beanstalk の設定内容 | | --- | --- | | Kubernetes バージョン | Elastic Beanstalk は、クラスターの作成時にバージョンを選択します。Elastic Beanstalk は、サポートされている最新バージョンの Kubernetes を使用して新しいクラスターを作成します。既存のクラスターの環境は、クラスターにすでにあるバージョンを実行します。そのバージョンは、クラスターの存続期間中固定されたままです。 | | ノード容量 | Amazon EKS Auto Mode。クラスターでスケジュールされたコンテナに合わせてノードを追加および削除します。ノード容量設定はサービスマネージド型です。 | | クラスターインフラストラクチャへのアクセス | サービスマネージド。Elastic Beanstalk API、、 AWS CLIまたは Elastic Beanstalk コンソールを使用して環境を設定します。 | | クラスターアドオン | Elastic Beanstalk は、環境が依存するアドオンをインストールしてピン留めします。Elastic Beanstalk が新しい固定アドオンバージョンを導入すると、後続の環境の作成または更新中にクラスターに更新が適用されます。更新は自分で計画または適用しません。 | Elastic Beanstalk はこれら自体を設定するため、クラスターを設定するのではなく、`aws:elasticbeanstalk:eks:*`オプションを使用して*アプリケーション*を設定します。「[Beanstalk クラスター環境の設定オプション](command-options-general-eks.md)」を参照してください。 ## クラスター設定ドリフト Elastic Beanstalk は、そのクラスターが予想されるサービスマネージド設定と一致している場合にのみ、作成したクラスターを操作します。インフラストラクチャがその設定と一致しなくなった場合、Elastic Beanstalk は設定ドリフトを検出し、クラスターのメンテナンスを一時停止して、環境イベントを報告します。 ``` ERROR Cluster drift detected for environment 'my-cluster-env'. {{what changed}}. Service will skip cluster maintenance for this environment. ``` クラスターがドリフトしている間: + Elastic Beanstalk は新しい環境を配置しません。 + サービスマネージド型アドオンバージョンの更新など、Elastic Beanstalk はこれを管理しなくなりました。 + すでに実行されている環境の更新は失敗します。 ドリフトは回復可能です。復旧するには、その原因となった変更を元に戻して、クラスターが Elastic Beanstalk が再度期待する設定と一致するようにします。ドリフトイベントは、変更内容に名前を付け、元に戻す内容を示します。Elastic Beanstalk は、次の環境オペレーションでクラスターを再評価し、設定が一致するとクラスターの管理を再開します。失敗したオペレーションを再試行します。 予想される設定を復元できない場合は、 AWS サポートにお問い合わせください。 ドリフトを回避するには、クラスターを直接変更するのではなく、Elastic Beanstalk オペレーションと設定オプションを使用して環境を変更します。「[Beanstalk クラスター環境の設定オプション](command-options-general-eks.md)」を参照してください。 ## クラスターの削除 Elastic Beanstalk は、最後の環境を終了してから 3 時間後にクラスターの削除をスケジュールします。この間隔で同じサブネットを持つ別の環境を作成すると、Elastic Beanstalk は保留中のクリーンアップをキャンセルし、既存のクラスターを再使用します。 **サービスマネージドインフラストラクチャの削除を検証するには** 1. 最後の環境を終了する前に、Elastic Beanstalk を使用してクラスター ARN を記録します。サービスで作成されたクラスターインフラストラクチャの場合、 CloudFormation テンプレートはクラスター名をスタック名に設定します。したがって、クラスター ARN の最終スラッシュの後の名前は、この手順で読み取り専用削除検証のスタックを識別します。 ``` $ aws elasticbeanstalk describe-environment-resources \ --environment-name my-cluster-env \ --query 'EnvironmentResources.Cluster.Name' ``` コマンドはクラスター ARN を返します。スタック名は、ARN の最後のスラッシュの後の部分です。 **重要** 派生スタック名は読み取り専用 CloudFormation ウェーター専用で、次に示すオペレーションを記述します。`delete-stack`、`update-stack`、またはサービスマネージドインフラストラクチャを変更する他のオペレーションに渡さないでください。 クラスター ARN と派生したスタック名を記録します。これらの名前は、以下の読み取り専用の検証ステップに使用します。 1. 「」の手順に従って、環境を終了し`Terminated`、 に到達することを確認します[Elastic Beanstalk 環境を終了する](using-features.terminating.md)。クラスターのクリーンアップは 3 時間の再利用間隔で個別に開始されます。環境の終了はクラスターの削除を待機しません。 1. 3 時間後に、サービスで作成されたスタックを記述するアクセス許可を持つ IAM プリンシパルを使用します。 CloudFormation ウェーターは、最大 60 分間 30 秒ごとに読み取り専用スタックの説明を使用し、スタックが存在しなくなったときに成功します。 ``` $ aws cloudformation wait stack-delete-complete \ --stack-name {{cluster-stack-name}} ``` スタックが存在しない場合、ウェーターは成功します。失敗しても、スタックは期限後も存在します。 `aws cloudformation describe-stacks`と `aws cloudformation describe-stack-events` を使用して、スタックのステータスと`DELETE_FAILED`イベントを検査します。 1. 期限後にスタックがまだ存在することがウェーターから報告された場合は、別の環境がクラスターを再利用したかどうかを判断します。アカウントとリージョン内のアクティブな Beanstalk クラスター環境を一覧表示します。 ``` $ aws elasticbeanstalk describe-environments \ --query "Environments[?Tier.Name=='Cluster' && Tier.Type=='EKS'].EnvironmentName" ``` リストされている環境ごとに、クラスター ARN を読み取ります。 ``` $ aws elasticbeanstalk describe-environment-resources \ --environment-name {{environment-name}} \ --query 'EnvironmentResources.Cluster.Name' ``` クラスター ARN が記録されたクラスター ARN と一致する環境は、削除が再利用のためにキャンセルされたことを意味します。環境が一致しない場合は、スタックのステータスと`DELETE_FAILED`イベントを使用して、保持されているリソースを診断します。サービスマネージドスタックを手動で削除または変更しないでください。スタックが期限後もアクティブな環境や実行可能な CloudFormation 障害が発生しずに残っている場合は、 AWS サポートにお問い合わせください。