弾力性とスケーラビリティのシナリオ判断
イベント予約サイトは、発売直後に混雑し、終了後にはほとんど利用されなくなります。台数を増やすだけではなく、増やす時期、減らす下限、処理中の要求、共通DBまで考え、弾力的に動く構成を選びます。
この単元で学ぶこと
- 時間帯ごとの需要から増減方針を決められる
- 起動遅延・上限・状態管理が弾力性に与える影響を説明できる
- 能力・可用性・料金の異なる要件を分けて判断できる
本文解説
事例の条件 予約サイトは通常毎秒150件、発売時は毎秒650件を受け付けます。検証環境ではWebサーバー1台が毎秒100件を安定処理できたとします。ここでの件数は計算練習用の仮定であり、EC2製品の保証値ではありません。本番では処理内容と混雑状態に応じて測定し直します。
まず必要な能力を計算する 通常時は150÷100を切り上げて2台、発売時は650÷100を切り上げて7台が能力上の最低数です。ただしちょうどの台数では、1台が故障した場合や予測を超えた需要に余裕がありません。高可用性の要件があれば、AZ分散や残存能力も別に設計します。
いつ増やすかを考える 発売時刻が決まっている場合、負荷が上がってから起動するだけでは準備が間に合わないことがあります。開始前に余裕を持って台数を増やす方針と、予測できない変動へ指標で追随する方針を組み合わせます。インスタンスの起動だけでなくアプリの準備と正常性確認の時間も考慮します。
終了後の縮小を設計する 発売が終われば7台分の能力を維持する必要が小さくなります。通常需要と可用性に必要な下限まで縮小すれば余剰を減らせます。ただし処理中の予約を失わないよう、新しい要求の振り分けを止めて進行中処理を完了させるなど、安全な終了を設計します。
上限と希望台数を点検する Auto Scalingの最大台数が4台なら、今回の仮定では毎秒650件へ追随できません。指標の設定だけでなく、上下限や利用可能な容量・割当制限も確認します。誤設定で過剰に増やし続けないための上限は必要ですが、業務上必要なピークを下回らないように決めます。
利用者の状態を外へ持つ あるWebサーバーのメモリだけに予約途中の情報を保持すると、台数を減らしてそのサーバーを終了したときに状態を失うおそれがあります。複数の処理先から利用できる保存先を検討し、要求の重複にも対応します。分散できるアプリとデータの設計が、増減する基盤を支えます。
DBが詰まる場合の判断 Web台数を増やしてもDBの書込み待ちが増えるだけなら、追加Web台数の料金だけが上がる場合があります。処理時間・接続数・DB負荷を確認し、原因に合った改善を行います。読み取り負荷と書き込み負荷では適切な手段も異なるため、単純に「レプリカを増やす」とは決めません。
例題：何を成果とするか 発売中の応答が要件を満たし、終了後には設定した下限へ戻り、縮小で予約が失われないことを確認します。ピーク時の性能だけを見れば拡張性は評価できても、弾力性の縮小側やデータの扱いは評価し切れません。通常時・上昇時・下降時を分けてテストします。
図解
重要ポイント
- 仮定の処理能力から必要台数を切り上げて求める。
- 予測可能なピークでは起動と準備に要する時間を見込む。
- 上限・下限は需要と可用性の双方から決める。
- 縮小時に処理中の予約や利用者状態を失わない設計が必要。
間違えやすい点
- 教材の毎秒100件をEC2の固定性能と誤解しない。
- Web台数だけで共通DBの性能まで増えるとは考えない。
- 縮小できればよいとして最低限の可用性を無視しない。
用語解説
- スケーラビリティ（拡張性）
- 仕事量が増えたときに、資源を増強することで必要な処理能力を拡大できる性質。
- 弾力性（エラスティシティ）
- 需要の増減に合わせて資源量を増やし、需要が減れば縮小できる性質。
- スケールアップ
- 1台のCPUやメモリなどを増強すること。
- スケールアウト
- 処理するインスタンスなどの台数を増やすこと。減らす操作はスケールインという。
- ボトルネック
- 全体の処理能力を制限する箇所。Webサーバーを増やしても、データベースが限界なら全体が速くならない場合がある。
関連教材
参考資料
教材データに登録された参考リンクです。リンク先の内容や更新日は提供元でご確認ください。
確認問題の出題・採点や学習履歴の保存にはログインが必要です。