AZ900-Cloud#7
季節変動の大きい EC サイトの次の各評価に最も適したスケーリング戦略を選択してください。
項目（ドラッグしてください）
- VMSS オートスケール (CPU しきい値 + スケジュール)
- 常時 20 倍の固定キャパシティ
- ピーク期間のみ 1 年 Reservations
通常時は最小構成、ピーク前後で自動拡張しコスト効率を両立する最適解
ピーク以外の 50 週間もリソースが遊休し課金され続ける不適解
1 年継続を前提とするため、年 2 回の突発ピークには根本的に不適な購入
解説
【正解マッチング】
| 項目 | 正しいカテゴリー |
|---|---|
| 通常時は最小構成、ピーク前後で自動拡張しコスト効率を両立する最適解 | VMSS オートスケール (CPU しきい値 + スケジュール) |
| ピーク以外の 50 週間もリソースが遊休し課金され続ける不適解 | 常時 20 倍の固定キャパシティ |
| 1 年継続を前提とするため、年 2 回の突発ピークには根本的に不適な購入 | ピーク期間のみ 1 年 Reservations |
【ポイント】
年 2 回・各 1 週間のピークがある EC サイトでは、コスト効率を重視して弾力性を活かします。VMSS のオートスケールは、CPU などのメトリクスのしきい値で通常時は最小構成に縮小し、ピーク前後で自動的にインスタンスを増減します。事前にピーク日時が判るならスケジュール ベースのスケール アクションを併用でき、需要変動にコスト効率よく追従する最適解です。常時 20 倍のキャパシティを保有する固定構成は、ピーク以外の約 50 週間 (年間の 96%) でリソースの大半が遊休するのに課金は続き、クラウドの弾力性を活かさず従来の CapEx 思考に逆戻りするため不適です。ピーク期間のみ 1 年 Reservations を購入する方式は、Reservations が 1〜3 年の継続稼働を前提とし対象期間中は常時課金されるため、年 2 回の突発ピークには根本的に不適です。自動追従の最適解か、遊休課金か、前提違いの購入かで対応付けます。
コメント