「EC2」タグアーカイブ

AWS WEBシステム開発におけるEC2&Aurora のインスタンス選択目安について

WebシステムにおいてEC2、Aurora PostgreSQLを使ったスタンダードなWEB3層アプリケーションを開発する際、1日のリクエスト数ごとに適切なEC2インスタンスタイプとAuroraのインスタンスサイズを選定するための基本的な表を作成しました。これらはリクエスト数やワークロードに応じて選定することが一般的であり、次の表は目安として利用できます。

ただし、実際のパフォーマンス要件やリソース消費量は、リクエストの内容(データベースの読み書き、アプリケーション処理など)、トラフィックのピークタイムなどにより異なるため、負荷テストを通じて調整する必要がありますので参考までにご利用ください。

1. EC2インスタンスタイプ選定の目安

1日のリクエスト数リクエスト/秒EC2 インスタンスタイプ (Web/App サーバー)特性制約備考
~10,0000.1 ~ 1.0t3.micro, t3.smallバースト可能な汎用インスタンス。コスト効率が高い。CPUクレジット制限。継続した高負荷には不向き。開発・テスト環境向け。コスト重視。
10,000 ~ 100,0001.0 ~ 10t3.medium, t3.largeバランス型、バースト性能あり。小規模なアプリに最適。バースト性能が必要な場合にのみ有効。小規模なプロダクション環境。
100,000 ~ 500,00010 ~ 50m5.large, m5.xlarge高い汎用性とバランス型。メモリ・CPU性能が安定。I/O性能は特定のワークロードには十分でない可能性。中規模なWebシステム。
500,000 ~ 1,000,00050 ~ 100m5.2xlarge, c5.xlargem5は汎用、c5は計算最適化。c5はCPU性能重視のアプリに有効。c5はメモリ容量が低い。I/O要求が高いワークロードには非推奨。大規模なWebアプリ。高負荷処理を要する場合。
1,000,000以上100以上c5.4xlarge, c5.9xlarge高いCPU性能とスケーラビリティ。大規模な高負荷処理に適する。メモリが重要なアプリケーションには不向き。高パフォーマンスが求められる大規模なサービス。

EC2インスタンスタイプの特徴

  • T3シリーズ: CPUクレジットベースのバースト型インスタンス。一定の時間、高負荷処理が可能。ただし、CPUクレジットが不足するとパフォーマンスが制限されるため、長時間の高負荷には不向き。
  • M5シリーズ: 汎用インスタンスタイプで、CPUとメモリのバランスが良い。I/O性能やストレージの要求がそれほど高くないアプリケーションに適している。
  • C5シリーズ: 計算最適化インスタンスタイプ。高いCPU性能が求められる処理(機械学習、ビデオエンコーディング、ハイパフォーマンスコンピューティング)に最適。メモリリソースはやや低め。

2. Aurora PostgreSQLインスタンスサイズ選定の目安

1日のリクエスト数DB トランザクション/秒Aurora インスタンスサイズ特性制約備考
~10,0000.1 ~ 1.0db.t3.mediumバースト可能な小規模インスタンス。コスト効率重視。CPUクレジットの制限。高負荷なクエリには不向き。小規模なデータベース。
10,000 ~ 100,0001.0 ~ 10db.r5.largeメモリ最適化型。中規模なトラフィックに適応。ストレージI/Oが要求される場合は制限を受けることがある。中規模なデータベースに適したバランス型。
100,000 ~ 500,00010 ~ 50db.r5.xlargeメモリとCPUのバランスが良い。高負荷なトランザクション処理にも対応。高スループットな書き込み性能が必要な場合には要検討。高可用性、処理能力が必要な環境向け。
500,000 ~ 1,000,00050 ~ 100db.r5.2xlarge高いメモリ性能を持ち、データ処理に最適。非常に高負荷なワークロードにはスケールが限られる。高負荷なクエリやトランザクション処理を行う場合。
1,000,000以上100以上db.r5.4xlarge, db.r5.8xlarge非常に高いスケーラビリティ。大規模なDBワークロードに適応。非常に高コスト。非常に高いパフォーマンスが要求される場合。

Auroraインスタンスサイズの特徴

  • T3シリーズ: バースト可能なインスタンスタイプ。低コストで運用可能だが、持続的な高負荷には不向き。小規模なアプリケーションや開発環境に最適。
  • R5シリーズ: メモリ最適化型のインスタンスタイプで、DBワークロードに特化している。トランザクション処理が多い環境や、データ分析などのメモリ集約型処理に適している。

3. その他の構成要素の考慮

  • CloudFront: Webアプリの静的コンテンツや画像などのキャッシュを効率的に処理するため、オリジンサーバーの負荷を軽減します。リクエスト数が多い場合には、キャッシュポリシーを最適化することが重要です。
  • ALB (Application Load Balancer): 大量のリクエストに対応するため、EC2インスタンスに負荷を分散します。ALBの性能は、リクエスト数に応じてスケールアウトされるため、特別なインスタンスタイプの選定は不要です。

4. 補足

  • この表は一般的なWebシステム向けのリクエスト数とワークロードを基にした目安です。Webアプリケーションの内容やDBクエリの複雑さ、またはピンポイントの負荷状況によって最適な構成が異なるため、負荷テストやパフォーマンスモニタリングを推奨します。
  • また、Auroraの自動スケーリング機能を有効にすることで、ピーク時やリクエスト数が変動する場合に柔軟に対応できます。

各サービスの詳細な料金体系や、インスタンスタイプによるコスト差も考慮する必要があります。