ハードウェア基礎 #9 クラウドインスタンスのスペックの読み方 — ワークロードに合わせて選ぶ
#8 で、IaaS を使えば結局インスタンスの種類を自分で選ぶと述べました。この最後の記事はその選ぶ作業を扱います。c5.xlarge のような名前は初めて見ると暗号のようですが、このシリーズを追ってきたなら、その中のすべての文字が #1 の 4 つのリソースで解けます。スペック表を読んでワークロードに合った種類を選ぶことでシリーズを閉じます。
ハードウェア基礎 シリーズでの今回の位置です。
- #1 コンピュータを動かす 4 つのリソース — CPU / メモリ / ストレージ / ネットワーク
- #2 CPU — コア / スレッド / クロック / キャッシュ、そして vCPU の正体
- #3 メモリ — RAM と階層構造、スワップが始まると起きること
- #4 ストレージ ① デバイス — HDD / SSD / NVMe と IOPS / スループット / レイテンシ
- #5 ストレージ ② 構成と接続 — RAID と DAS / NAS / SAN
- #6 ネットワーク — 帯域幅とレイテンシ、NIC からデータセンターまで
- #7 仮想化とコンテナ — 物理サーバー 1 台が複数台になる仕組み
- #8 クラウド — 所有から賃借へ、オンプレミスから IaaS / PaaS / SaaS まで
- #9 クラウドインスタンスのスペックの読み方 — ワークロードに合わせて選ぶ ← 今回
インスタンス名を分解する #
AWS のインスタンス名には規則があります。c5.xlarge を例にすると 3 つの断片に分かれます。
c 5 xlarge
ファミリー 世代 サイズ
(用途) (第何世代) (どれだけ大きいか)- ファミリー — どのリソースに偏った種類か (
cはコンピュート最適化) - 世代 — 第何世代か (数字が大きいほど最新で、おおむね速く効率的)
- サイズ — リソースがどれだけ多いか (
large→xlarge→2xlargeと大きくなる)
名前を読むだけで「最新世代のコンピュート寄りの中サイズ」という性格が見えます。他のクラウドも表記は違いますが、ファミリー・サイズに分けて呼ぶ構造は似ています。
ファミリー — どのリソースに偏ったか #
ファミリーは #1 の 4 つのリソースのうちどこに重みを置いたかを表します。同じ vCPU でもメモリの比率とストレージの性格が変わります。
| ファミリー | 性格 | 偏ったリソース | 合うワークロード |
|---|---|---|---|
t | バースタブル・汎用 | 普段は少なく、一時的に多く | トラフィックの少ない小規模 |
m | 汎用 | vCPU とメモリのバランス | 一般的な Web・アプリサーバー |
c | コンピュート最適化 | CPU 比重が高い | 計算中心、バッチ |
r | メモリ最適化 | メモリ比重が高い | データベース・キャッシュ |
i | ストレージ最適化 | 速いローカル NVMe | 大容量・高 IOPS |
c 系はメモリに対して vCPU が多く、r 系はその逆です。#2 の CPU と #3 のメモリのどちらがボトルネックになるかによってファミリーが分かれます。
サイズ — 同じファミリーの中の倍数 #
サイズは同じファミリーの中でリソースの量を決めます。1 段階大きくなるたびに vCPU とメモリがおおむね 2 倍ずつ増え、価格もその分上がります。
| サイズ | vCPU | メモリ | 価格 |
|---|---|---|---|
large | 2 | 基準 | 基準 |
xlarge | 4 | 2 倍 | 約 2 倍 |
2xlarge | 8 | 4 倍 | 約 4 倍 |
vCPU が #2 で見たとおり普通ハイパースレッド単位だという点を思い出すと、xlarge の 4vCPU はだいたい物理コア 2 個に相当します。
4 つのリソースでスペック表を読む #
インスタンス詳細ページのスペック表は、結局このシリーズの 4 つのリソースです。各項目をどの記事で扱ったかで整理すると、スペック表が一目で入ってきます。
| スペック表の項目 | 何か | 扱った記事 |
|---|---|---|
| vCPU | ハイパースレッド単位の計算能力 | #2 |
| メモリ (GiB) | 作業空間の量 | #3 |
| ストレージ | EBS 専用かローカル NVMe か | #4 · #5 |
| ネットワーク帯域幅 | 最大 Gbps | #6 |
「EBS 最適化」や「最大 10Gbps」のような表記も、これで解釈できます。前者は #5 のネットワークブロックストレージにより多くの帯域幅を保証するという意味で、後者は #6 の NIC の上限です。
ワークロードごとに選ぶ #
ワークロードごとにボトルネックになるリソースが違います。そのリソースに偏ったファミリーを選ぶのが出発点です。
| ワークロード | 主なボトルネック | 勧めるファミリー |
|---|---|---|
| 一般的な Web・アプリサーバー | バランス | m (汎用) |
| 計算中心のバッチ・エンコード | CPU | c (コンピュート) |
| データベース・インメモリキャッシュ | メモリ | r (メモリ) |
| 大容量・高 IOPS の保存 | ストレージ | i (ストレージ) |
| トラフィックの少ない小規模 | 普段は低い | t (バースタブル) |
選ぶ順序 #
順序は #1 のボトルネックの原則をそのまま辿ります。
- ボトルネックのリソースを決めます。 このワークロードが CPU / メモリ / ストレージ / ネットワークのうち何にもっとも敏感かを見ます。
- ファミリーを選びます。 そのリソースに偏ったファミリーを選択します。
- サイズを選びます。 必要な vCPU とメモリに合わせて決め、最初は小さく取ります。
- 測定して調整します。 実際の負荷でどのリソースが先に限界に達するかを見て、サイズやファミリーを変えます。
核心は 推測で大きく取らないこと です。小さく始めて測定で大きくする方が、最初から大きく取ってコストを漏らすよりよいです。
よく出会う落とし穴 #
「念のため大きいものにしよう」 #
もっともよくあるコストの無駄です。ほとんどのインスタンスは普段リソースが余っています。小さく始めて測定で大きくする方がコストを節約します。
「vCPU 数だけ見て選んだ」 #
同じ vCPU でもファミリーによってメモリ比率が違います。データベースを c 系に乗せるとメモリが先に足りなくなり、#3 のスワップへ落ちることがあります。
「バースタブル (t) で常時負荷を動かした」
#
#2 で押さえたとおり、t 系はクレジットが尽きると性能が制限されます。継続的に CPU を使うワークロードには合いません。
「一度選べば終わり」 #
ワークロードは変わります。測定値を見て定期的に種類を見直すことが、過剰・過少プロビジョニングを防ぎます。
まとめ — シリーズを閉じながら #
今回つかんだ絵です。
- インスタンス名は ファミリー (用途)・世代・サイズ に分解されます。
- ファミリー は 4 つのリソースのうちどこに偏ったかを (
m・c・r・i・t)、サイズ はリソースの量を決めます。 - スペック表の vCPU・メモリ・ストレージ・ネットワークは、それぞれ #2・#3・#4・#6 で扱ったそのリソースです。
- 選ぶ順序は ボトルネックのリソース → ファミリー → サイズ → 測定して調整 です。小さく始めて測定で大きくします。
9 編にわたって 4 つのリソースから出発し、クラウドインスタンスのスペック表まで来ました。これで「遅い」と「高い」は推測ではなく診断の対象です。
次回 — AWS へ #
このシリーズがスペック表を 読む 方法までだったなら、インスタンスを実際に 立ち上げて運用する 方法は AWS シリーズの担当です。AWS 基礎 でアカウントとリージョンを押さえ、AWS 中級の EC2・VPC で今回のインスタンスを直接立ち上げ、ストレージ (S3) へつなぐ流れで進めば、ハードウェアの知識が実際の運用へつながります。