コンピューティングアーキテクチャを改善する

前提

以下は既習として扱います。

• 垂直スケーリングと水平スケーリング
• Amazon EC2 Auto Scaling
• インスタンスファミリー
• 適正サイズ化
• CPUやメモリなどのボトルネック特定

CPU不足だから垂直スケーリング、需要増加だから水平スケーリング、といった基本判断はここでは再講義しません。

新しく考えるのは、既習の改善方式だけでは不足する場合に、キャパシティの取得方法やEC2の配置方法まで含めてコンピューティングアーキテクチャを改善することです。

1. 4つの改善軸を分ける

コンピューティング性能を改善するときは、次の4つを区別します。

単一ノード能力と総キャパシティは、既習の垂直・水平スケーリングで扱えます。このページでは特に、必要な性能のEC2を確保できない場合や、十分なノード数があってもノード間通信が遅い場合まで含めて考えます。

2. 既習のスケーリング方式を改善軸として利用する

特定済みの制約が単一ノード能力にある場合は、インスタンスファミリー、インスタンスサイズ、垂直スケーリングを既習の改善軸として利用します。

分散可能なワークロード全体のキャパシティが不足する場合は、水平スケーリングと、必要に応じてAmazon EC2 Auto Scalingを利用します。

ここで重要なのは、それらの仕組みを再学習することではありません。

単一ノード能力を変えるのか

総キャパシティを変えるのか

キャパシティを取得する方法自体を変えるのか

を混同しないための分類として使います。

3. スケーリング可能でもEC2を確保できるとは限らない

例えばAmazon EC2 Auto Scalingで10台まで増やせる構成でも、c7i.2xlargeだけを使用している場合、そのインスタンスタイプを対象アベイラビリティーゾーンで確保できなければ、必要台数まで増やせないことがあります。

このとき問題なのはAuto Scalingがないことではなく、キャパシティ調達を1種類のインスタンスタイプへ依存していることです。

アプリケーションが8 vCPU以上、32 GiB以上、必要なネットワーク性能といった要件を満たせばよいのであれば、特定のインスタンスタイプ名へ固定する必要はありません。

4. 複数のインスタンスタイプを候補にする

Amazon EC2 Auto Scalingでは、Mixed Instances Policyを利用して複数のインスタンスタイプを扱えます。

さらに属性ベースのインスタンスタイプ選択では、vCPU、メモリ、ストレージ属性、CPUメーカー、アクセラレーター、ネットワーク関連属性などの条件から候補を選択できます。

特定のインスタンスタイプを起動する
↓
ワークロードに必要な
コンピューティング要件を満たす
インスタンスを起動する

という考え方に変えることで、1つのインスタンスタイプや1つのキャパシティプールへの依存を減らせます。

5. 候補を増やしても性能要件は維持する

複数のインスタンスタイプを許可するとき、候補が多いほどよいわけではありません。候補はワークロードに必要な最低性能を満たす必要があります。

属性ベースのインスタンスタイプ選択では、必要な属性条件を指定できます。またAmazon EC2 Auto Scalingには、指定した基準に対してCPU性能が低い候補を除外するパフォーマンス保護があります。

現在、このパフォーマンス保護で扱う基準性能はCPU性能です。

CPU性能
→ パフォーマンス保護

必要メモリ量やその他の条件
→ 属性要件

つまり、キャパシティ候補を広げることと、性能条件を緩めることは同じではありません。

6. EC2 Fleetでキャパシティをまとめて取得する

大量のEC2キャパシティを、複数インスタンスタイプ、複数アベイラビリティーゾーン、On-Demand、Spotなどからまとめて取得したい場合は、EC2 Fleetを利用できます。

例えば、大規模バッチ処理で500 vCPU相当が必要だが特定のインスタンスタイプには固定せず、処理システム自身がEC2のライフサイクルを管理するケースです。

この場合、複数のEC2キャパシティプールを対象に必要キャパシティを要求できます。

7. Amazon EC2 Auto ScalingとEC2 Fleetの責任を分ける

両方とも複数インスタンスタイプを扱えますが、中心となる責任は異なります。

複数インスタンスタイプを扱うからといって、必ずEC2 Fleetを選ぶわけではありません。判断軸の1つは、インスタンスのライフサイクルを誰が管理するのかです。

8. ノード間通信は別の改善軸

CPUやメモリ、台数が十分でも、EC2ノード間通信が性能を制限することがあります。例えば、密結合並列処理、HPC、多数ノード間で頻繁にデータ交換する処理です。

この場合は、インスタンスタイプやインスタンス台数だけでなく、インスタンスをどのように配置するかも検討します。

9. クラスタープレイスメントグループ

クラスタープレイスメントグループは、インスタンスを単一アベイラビリティーゾーン内で近接配置します。

低いネットワークレイテンシーと高いネットワークスループットが必要なワークロードで候補になります。

ノードA
↕
ノードB
↕
ノードC
↕
ノードD

のように、計算ノード同士で大量の通信を行い、その通信時間が処理性能を制限している場合です。この問題は1台のCPUを強化する、台数を増やすだけでは直接解消できません。

10. プレイスメント戦略を混同しない

現在のAmazon EC2には、Cluster、Spread、Partition、Precision Timeなど複数のプレイスメント戦略があります。それぞれ目的が異なります。

このページで扱う低レイテンシーと高いノード間ネットワーク性能という要件では、主にClusterを評価します。

「プレイスメントグループを使う」だけでは判断として不十分であり、現在の制約に対応するプレイスメント戦略を選ぶ必要があります。

11. Clusterには別の制約もある

クラスタープレイスメントグループは単一アベイラビリティーゾーン内へ配置します。そのため、ノード間通信性能を優先する設計と、複数アベイラビリティーゾーンへ分散する設計は同じ目的ではありません。

また、必要なEC2キャパシティをグループ内へ確保できなければ、インスタンス起動に失敗する場合があります。

ノード間通信性能

キャパシティ確保

可用性要件

をまとめて考えます。

12. 改善軸どうしのトレードオフを確認する

ある改善策が1つの性能要件を満たしても、別の要件まで自動的に満たすとは限りません。

密結合処理でノード間通信性能を高めるためにCluster Placement Groupを採用しても、複数アベイラビリティーゾーンへ分散する可用性要件まで同じ仕組みだけで満たすわけではありません。

同様に、複数インスタンスタイプを許可してキャパシティ調達先を増やしても、必要な性能条件を満たす候補だけを利用する必要があります。

この変更でどの制約を解消するのか
↓
別の性能要件・可用性要件・
キャパシティ要件に何が残るのか

を確認します。1つの改善策を、すべての要件を解決する万能な対策として扱わないことが重要です。

13. 改善軸の対応

ボトルネック
↓
変更すべきアーキテクチャ軸
↓
必要なAWS機能

へ変換することが重要です。

14. このページで扱わないこと

Amazon CloudFront、AWS Global Accelerator、エッジコンピューティングなど、地理的距離やグローバル配信によるレイテンシー改善は扱いません。また、過剰なリソースをどこまで縮小するかという適正サイズ化も扱いません。

ここでは、特定済みのコンピューティングボトルネックに対して、コンピューティングアーキテクチャのどの軸を変更するかだけを扱います。

15. 判断フロー

コンピューティングボトルネック特定済み
↓
変更すべき軸を確認

├─ 単一ノード能力
│    ↓
│  既習のインスタンスファミリー
│  / 垂直スケーリング
│
├─ 総キャパシティ
│    ↓
│  既習の水平スケーリング
│  / Amazon EC2 Auto Scaling
│
├─ キャパシティ調達
│    ↓
│  Mixed Instances Policy
│  / 属性ベースのインスタンスタイプ選択
│  / EC2 Fleet
│
└─ ノード間通信
     ↓
   クラスタープレイスメントグループ

さらに、採用した改善策が解消する制約を確認し、残る性能・可用性・キャパシティ要件を確認します。

16. まとめ

既習の垂直・水平スケーリングだけでは、すべてのコンピューティング性能問題を表せません。

特に、必要なEC2を確保できない、ノード間通信が遅いという問題では、複数インスタンスタイプ、属性ベースのインスタンスタイプ選択、EC2 Fleet、クラスタープレイスメントグループまで改善対象になります。

重要なのは、特定したボトルネックが、単一ノード能力・総キャパシティ・キャパシティ調達・ノード間通信のどの軸に属するかを判断することです。

さらに、1つの改善策だけで他の性能・可用性・キャパシティ要件まで満たせるとは限らないため、改善後に残る要件も確認します。

主要AWS公式資料

• AWS Certified Solutions Architect - Professional（SAP-C02）試験ガイド
• Amazon EC2 Auto Scaling User Guide — Mixed instances groups
• Amazon EC2 Auto Scaling User Guide — Attribute-based instance type selection
• Amazon EC2 User Guide — EC2 Fleet
• Amazon EC2 User Guide — Placement groups