Amazon EC2 実践的なユースケース

Amazon EC2は多様なワークロードに対応できる柔軟性を持ち、適切なアーキテクチャ設計により、コスト効率と高性能を両立できます。以下、主要なユースケースとその実装方法について詳しく解説します。

Webアプリケーションの3層アーキテクチャ

AWS ウェブホスティングアーキテクチャの主要コンポーネント

AWS クラウドでデプロイされるウェブホスティングアーキテクチャは、従来型のウェブホスティングアーキテクチャと比較して、より安全でスケーラブルな構成を実現できます。

ネットワーク管理 Amazon VPCを使用することで、他のお客様のネットワークから自分のネットワークを分離する機能を提供し、より安全でスケーラブルなアーキテクチャが可能になります。セキュリティグループがホストレベルのセキュリティを提供する一方で、Amazon VPCはAWSでのネットワークのセットアップの詳細を完全にコントロールできます。

具体的な構成例

  • ウェブサーバーのパブリック側のサブネットの作成
  • データベースのインターネット接続がないプライベートサブネットの作成
  • ハードウェアバーチャルプライベートネットワーク(VPN)を使用したハイブリッド型アーキテクチャの構築

セキュリティグループによる階層化セキュリティ ウェブサーバークラスターのセキュリティグループは、ウェブレイヤーのロードバランサーからのみ、かつポート80と443(HTTPとHTTPS)のTCP経由でのアクセスのみを許可します。一方、アプリケーションサーバーのセキュリティグループは、アプリケーションレイヤーのロードバランサーからのアクセスのみを許可します。

コンテンツ配信の最適化

Amazon CloudFrontの活用 ウェブトラフィックが地理的に分散している場合、CloudFrontを使用してエッジロケーションのグローバルネットワークを通じて、動的、静的、ストリーミングコンテンツを含むウェブサイトを配信できます。CloudFrontは可能な限り最高のパフォーマンスでコンテンツが配信されるように、コンテンツのリクエストを最も近いエッジロケーションに自動的にルーティングします。

スポットインスタンスを活用したWebアプリケーション

コスト最適化アーキテクチャ スポットインスタンスを活用することで、Webアプリケーションのコストを大幅に削減できます。Auto Scalingグループでオンデマンドインスタンスとスポットインスタンスを組み合わせて使用し、同じElastic Load Balancerの背後に配置することで、柔軟性を提供し、変化するトラフィック需要に対応できます。

セッション状態の外部化 セッション状態をWebティアの外部のDynamoDBテーブルに保存できます。DynamoDBはリージョナルサービスであり、データは障害耐性のためにアベイラビリティーゾーン間で自動的にレプリケートされます。

スポットインスタンス終了への対応 スポットインスタンスは2分間の警告を受けて終了される可能性があるため、IAMロールを作成してスポットインスタンスが終了通知を受信したときにELBから自動的に登録解除されるように設計する必要があります。

バッチ処理システムの構築

AWS Batchによる大規模バッチ処理

基本アーキテクチャ AWS Batchは、コンピュートリソースを管理する必要なく、あらゆる規模で計算ジョブを実行できるフルマネージドサービスです。バッチジョブのコードをパッケージ化し、依存関係を指定して、AWS Management Console、CLI、またはSDKを使用してバッチジョブを送信するだけで利用できます。

ジョブキューとコンピュート環境 AWS Batchでジョブを実行するには、ジョブをBatchジョブキュー(JQ)に送信します。ジョブキューは、送信の受け取りから実行のディスパッチ、戻りステータスの追跡まで、ジョブのライフサイクルを管理します。

動的スケーリングメカニズム AWS Batchスケジューラーサービスは定期的にジョブキューを確認し、RUNNABLE状態のジョブの要件(vCPU、GPU、メモリ)を評価します。この評価に基づいて、関連するBatchコンピュート環境(CE)がキューのジョブを処理するためにスケールアップする必要があるかどうかを特定します。

HPC(高性能コンピューティング)ワークロード

マルチノード並列ジョブのサポート Amazon Batchはマルチノード並列ジョブをサポートしており、複数のEC2インスタンスにまたがる単一のジョブを実行できます。この機能により、大規模で密結合の高性能コンピューティング(HPC)アプリケーションや分散GPU モデルトレーニングなどのワークロードを簡単かつ効率的に実行できます。

Elastic Fabric Adapterの活用 Amazon BatchはElastic Fabric Adapterをサポートしており、AWS上で大規模なノード間通信を必要とするアプリケーションを実行できるネットワークインターフェースを提供します。

機械学習ワークロードの実行

EC2 Capacity Blocks for ML

GPU容量の事前予約 Amazon EC2 Capacity Blocks for MLを使用することで、将来の開始日に向けてアクセラレーテッドコンピュートインスタンスを簡単に予約できます。Capacity BlocksはAmazon EC2 P6-B200、P5en、P5e、P5、P4dインスタンスをサポートし、それぞれ最新のNVIDIA Blackwell GPU、NVIDIA H200 Tensor Core GPU、NVIDIA H100 Tensor Core GPU、NVIDIA A100 Tensor Core GPUによって加速されます。

UltraClustersでの高性能実行 EC2 Capacity Blocksは、高性能機械学習(ML)ワークロード向けに設計されたAmazon EC2 UltraClustersに配置されます。1から64インスタンス(512 GPUまたは1024 Trainium チップ)のクラスターサイズで最大6か月間アクセラレーテッドコンピュートインスタンスを予約でき、幅広いMLワークロードを実行する柔軟性を提供します。

主要メリット

  • 計画の確実性: アクセラレーテッドコンピュートインスタンスの将来の利用可能容量を確保することで、ML開発を確信を持って計画
  • 低レイテンシ・高スループットネットワーク: Amazon EC2 UltraClustersでの配置による分散トレーニング向けの低レイテンシ・高スループットネットワーク接続
  • 高性能: 機械学習向けのAmazon EC2で最高性能のアクセラレーテッドコンピュートインスタンスへの予測可能なアクセス

SageMaker HyperPodとの統合

Capacity Blocksを活用したAmazon SageMaker HyperPod柔軟トレーニングプランは、トレーニング要件に基づいて複数のコンピュート容量ブロックにわたってトレーニングジョブを自動的に予約・実行することで、モデルトレーニングのタイムラインと予算を満たすのに役立ちます。

HPC(高性能コンピューティング)環境の構築

Amazon EC2 Hpc6a インスタンス

密結合HPCワークロード向け設計 Amazon EC2 Hpc6aインスタンスは、第3世代AMD EPYCプロセッサーを搭載し、計算流体力学(CFD)、気象予測、マルチフィジックスシミュレーションなどの密結合で計算集約的な高性能コンピューティング(HPC)ワークロード向けに設計されています。

主要仕様と性能

  • プロセッサー: 2つの48コア第3世代AMD EPYC 7003シリーズプロセッサー(7nmプロセスノード)
  • メモリ: 384 GiBのメモリ、合計96コア(コアあたり4 GiBのメモリ)
  • ネットワーク: AWS Nitro Systemによって提供されるElastic Fabric Adapter(EFA)で100 Gbpsの低レイテンシネットワーク帯域幅

コスト効率性 Hpc6aインスタンスは、AWSでHPCワークロードをコスト効率よく実行するために特別に構築されており、類似のコンピューティング最適化x86ベースインスタンスと比較して最大70%低い価格設定となっています。

AWS ParallelClusterとの統合

AWS ParallelClusterを使用することで、Hpc6aインスタンスを同じクラスター内の他のインスタンスタイプと一緒にプロビジョニングできます。これにより、クラスター内で異なるインスタンス向けに最適化された異なるワークロードを実行する柔軟性が得られます。

マルチリージョン高可用性アーキテクチャ

複数AWSリージョンによる復旧性向上

マルチリージョンをアーキテクチャアプローチとして使用することで、Amazon Web Services(AWS)でより高い復旧性を実現できます。このアプローチは、まずAWSリージョン内の複数のアベイラビリティーゾーンでワークロードを運用し、その後複数のリージョンを使用してさらに高い復旧性を実現するために拡張することに依存しています。

Chaos Engineeringによる復旧性テスト

AWS Fault Injection Simulatorを使用した行動駆動型カオスエンジニアリングにより、ワークロードの継続的な復旧性に対する信頼を得て、証拠を提供できます。現代のカオスエンジニアリング原則を使用することで、この課題に対処できますが、カオスエンジニアリングの実践は複雑になる可能性があります。

ベストプラクティス

アーキテクチャ設計の原則

  • 用途に応じた適切なインスタンスタイプの選択
  • 複数のAZまたはリージョンでの冗長化設計
  • スポットインスタンスの活用によるコスト最適化
  • 適切なセキュリティグループとネットワーク分離の実装

運用管理の最適化

  • Auto Scalingによる動的リソース管理
  • CloudWatchによる包括的な監視
  • 定期的な障害テストとカオスエンジニアリングの実施
  • コスト最適化のための継続的な見直し

引用元:

</rewritten_file>