AWS 構成の基礎知識 - 3: インフラの超概算見積もり
主要部分にフォーカスする
- 何案もあるし
- 概算だし
詳細は部分は別スクラップ ( AWS の超概算見積もりをするための基礎インプット ) で
要点は コンピューティング
と ストレージ
と 転送量
で全コストの 60-80% くらいになるんじゃね、ってところ
コストはその 3 点に絞って出して、それ以外のネットワークリソースや監視やデプロイや保守のサービスはえいやで +20% くらいとする
( 構成によってそこの料金が大きく変わるとも考えづらいし、複数案の相対比較を行うなら一律額で扱っても問題ないと判断した )
CPU / メモリ見積もり
基本的に同時アクセス数とかから出す
秒間 30 アクセス、1 アクセス 20MB 消費、などから考えて瞬間的にメモリに乗る量を考える
1000ms で 30 アクセスなので 1 アクセスに 33ms かかったらやばいとかも考慮に入れる
スケーリングの単位を考えておいて、負荷の増減はスケールアウト/インで対応すると基本的に考えれば良いのかな?
補足. スケールアップ/ダウンはスペック変更、スケールアウト/インは台数変更
→ スクラップ ( AWS - Cloud Design Pattern ) で
DB のインスタンスタイプ ( の サイズ
) についても同様の考え方
ちなみに AWS の vCPU は物理コアの半分に相当するらしい
転送量の見積もり
- 現行の、もしくは仮や理想のリクエスト数を作る
- 単位あたりのサイズを作る
- 画像なら 1MB / リクエスト とか
- Json なら 1KB / リクエスト とか
- DB レコードなら 3KB / ユーザ とか
- リクエスト数と容量をざっくり掛け算
- 雰囲気でキャッシュを入れた時の数を削る
- ぶっちゃけ大局にインパクトがないのでここはざっくり
それ以外の見積もり
先述の通りえいやで +20% とか x 万円とか乗せる
複数案の比較が目的で、案による差異が料金インパクトのでかいサービスに出ないなら、それで大丈夫
他
- staging と dev もちゃんと出しておく
- 要件やコスト次第では staging の性能を落としたり、本番に繋いだりすることも検討する
- e.g.)「staging は本番データで機能テストに使う」ならスペックは落としても良い
- e.g.)「staging で負荷試験を行う」なら普段は台数が少なくても良い
パラメータとインパクトを整理する
仮値が多いし素人意見なので、ずれをリカバリしやすい様に整理しておきたい
またサービスが成長した時に規模拡大に伴うコスト増加の予測を立てるためにも、パラメータが全体コストに与える影響を想定する
ざっと見た限りでは、こう整理できた
Fargate
- タスク数: 単純に掛け算に使われるので x2 にしたらコストは x2
- インスタンスタイプ: 1 ランクアップで x2 に見えたので 1 つあげたらコストは x2
- 実際は Fargate だと vCPU とメモリの指定のみだが、インスタンスタイプに相当させた場合のイメージ
- vCPU だけあげると x1.8 程度、メモリだけあげると x1.2 程度に見えた
→
メモリは運用しながら調整してもインパクト小
それ以外はそれなりのインパクト、特にリクエスト増加に伴う vCPU とタスク数
Aurora
- インスタンスタイプ: Fargate に書いたのと同じく 1 つあげたらコストは x2
- 台数: 単純に掛け算に使われるので x2 にしたらコストは x2
- ストレージ容量: 100GB 程度の変動は ほぼ誤差扱い
- 極端に変われば
インスタンスサイズ
が変動する可能性はある
- 極端に変われば
S3
- 容量: ほぼ比例するので x2 したらコストは x2
- 転送量: 100GB 程度の変動は ほぼ誤差扱い
取り扱い
- パラメータをいじった場合のコストへの影響が相対的に把握しやすい
- インフラ構成案複数を並べる場合に、足し引き計算がしやすい
- 比較が目的なら相対ルールの方が重宝すると判断したため