翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 # 大規模な実行のチェックリスト 5万以上の vCPUs で、大きなワークロードを実行する前に、次のチェックリストを検討してください。 **注記** 100 万個以上の vCPUs で大規模なワークロードを実行する予定がある場合、または大規模なガイダンスが必要な場合は、 AWS チームにお問い合わせください。 + **Amazon EC2 クォータの確認** — AWS マネジメントコンソールの Service Quotas パネルで、Amazon EC2 のクォータ (制限ともいいます) を確認してください。必要に応じて、Amazon EC2 インスタンスのピーク数に合わせてクォータ引き上げをリクエストしてください。Amazon EC2 スポットインスタンスと Amazon オンデマンドインスタンスには、別々のクォータがあることを憶えていてください。詳細については、[Service Quotas を開始させる](https://docs.aws.amazon.com/servicequotas/latest/userguide/getting-started.html) を参照してください。 + **リージョンごとに Amazon Elastic Block Store の割り当てを確認する** — 各インスタンスはオペレーティングシステムに GP2 または GP3 ボリュームを使用します。デフォルトでは、各 AWS リージョン のクォータは 300 TiB です。ただし、各インスタンスはこのクォータの一部としてカウントを使用します。そのため、各リージョンの Amazon Elastic Block Store の割り当てを確認するときは、この点を必ず考慮に入れてください。クォータに達すると、それ以上インスタンスを作成することはできません。詳細については、[Amazon Elastic Block Store エンドポイントとクォータ](https://docs.aws.amazon.com/general/latest/gr/ebs-service.html) を参照してください。 + **ストレージに Amazon S3 を使用する** — Amazon S3 はハイスループットを提供し、各アベイラビリティーゾーンのジョブとインスタンスの数に基づいて、プロビジョニングするストレージの量を推測する必要がなくなります。詳細については、[設計パターンのベストプラクティス: Simple Storage Service (Amazon S3) のパフォーマンスの最適化](https://docs.aws.amazon.com/AmazonS3/latest/userguide/optimizing-performance.html) を参照してください。 + **段階的にスケールしてボトルネックを早期に特定する** — 100 万個以上の vCPUs で実行されるジョブでは、ボトルネックを早期に特定できるように、低レベルから始めて徐々に増やしていきます。例えば、5万個のvCPUs で実行することから始めます。次にその数を 20 万個の vCPUs に、次に 50 万個の vCPUs にと増やします。つまり、望ましい vCPU 数に達するまで vCPUs 数を徐々に増やし続けます。 + **監視して潜在的な問題を早期に特定する** — 大規模に実行する際に発生する可能性のある中断や問題を避けるために、アプリケーションとアーキテクチャの両方を必ず監視してください。仮vCPUs を 1,000 から 5,000 にスケーリングしても、中断が発生する可能性があります。Amazon CloudWatch Logs を使用して、ログデータを確認したり、クライアントライブラリを使い CloudWatch 埋め込みメトリックスを使用したりできます。詳細については、[CloudWatch Logs エージェントリファレンス](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AgentReference.html) と [https://github.com/awslabs/aws-embedded-metrics-python](https://github.com/awslabs/aws-embedded-metrics-python) を参照してください。