ハードウェア基礎 #1 コンピュータを動かす 4 つのリソース — CPU / メモリ / ストレージ / ネットワーク

サーバーを運用していると、同じ問いに繰り返しぶつかります。このサーバーはなぜ遅いのか。このインスタンスはなぜこんなに高いのか。昨日は問題なかったサービスが、なぜ今日は応答が遅れるのか。答えはほぼ必ず 4 つのうちのどれかに絞られます。CPU、メモリ、ストレージ、ネットワークです。このシリーズはその 4 つの物理リソースを運用者の目線で整理し、最後にはそれらがクラウドインスタンスのスペック表としてどう現れるかまでつなげていきます。

Linux、Docker、AWS を扱う記事は、この 4 つのリソースをすでに知っている前提で始まります。このシリーズはその前提を満たす土台です。部品を選んだり PC を組み立てたりする話ではなく、サーバーとクラウドの上で性能とコストがどこで決まるのかを扱います。

ハードウェア基礎、全 9 編にまとめました。この記事はその出発点です。

なぜハードウェアを知るべきか #

最近は物理サーバーに触れることはほとんどありません。EC2 インスタンスを選び、データベースのメモリ値を調整し、ディスクの種類を選ぶ作業は、すべてコンソールの数クリックで終わります。だからハードウェアをブラックボックスのまま見過ごしがちです。

問題は、性能とコストがまさにそのブラックボックスの中で決まることです。c5.xlarge がなぜその価格なのか、gp3 ディスクと io2 ディスクがなぜ違うのか、メモリを増やしたのになぜまだ遅いのかは、ハードウェアを知らなければ推測するしかありません。逆に 4 つのリソースの動きを理解すれば、「遅い」と「高い」が推測ではなく診断の対象に変わります。

4 つのリソース #

コンピュータ 1 台は、結局 4 つのリソースが協力する装置です。それぞれ担当が違い、足りないときに出る症状も違います。

CPU — 計算を担当する #

CPU は実際に計算を行う部品です。コードのすべての演算、条件分岐、データ加工がここで起きます。CPU が足りないと処理する仕事が列に並び、リクエストはその列の後ろで待ちます。詳しい構造は #2 で扱います。

メモリ (RAM) — いま使うデータの作業空間 #

CPU が計算するには、データが近くになければなりません。その近い作業空間が RAM です。速いものの電源が切れると中身が消える揮発性の保存先で、容量が限られています。メモリが足りなくなった瞬間、システムは遅いディスクを一時的なメモリとして使い始め、このとき性能が崖のように落ちます。#3 の主題です。

ストレージ — 電源が切れても残る保管庫 #

ストレージはデータを永続的に保管する装置です。RAM と違い、電源が切れても中身が残ります。代わりに RAM よりずっと遅いです。データベースファイル、ログ、アップロードされた画像がすべてここに住み、種類 (HDD・SSD・NVMe) と構成 (RAID) によって速度が大きく分かれます。#4 と #5 で扱います。

ネットワーク — 外とつなぐ通路 #

サーバー 1 台で完結するサービスはありません。ユーザー、データベース、他のサービスと絶えずデータをやり取りする必要があり、その通路がネットワークです。帯域幅が広くても距離が遠ければ遅くなり得ますが、この区別は運用でよく混同されます。#6 で整理します。

1 回の Web リクエストは 4 つのリソースをすべて通る #

4 つのリソースは別々に動くのではなく、1 回のリクエストの中で順に協力します。ユーザーが商品詳細ページを開くという単純なリクエストを追ってみます。

ユーザーのブラウザ
   │  ① ネットワーク — リクエストがサーバーまで届く
   ▼
Web サーバー (CPU/メモリ)
   │  ② CPU — リクエストを解釈し処理ロジックを実行
   │  ③ メモリ — 処理中のデータを置く
   ▼
データベース
   │  ④ ストレージ — ディスクから商品データを読む
   │  ⑤ メモリ — よく使うデータはキャッシュから即座に
   ▼
レスポンス生成 (CPU/メモリ)
   │  ⑥ ネットワーク — レスポンスがユーザーへ戻る
   ▼
ユーザーのブラウザ

6 つのステップのどれか 1 つでも遅ければ、ユーザーが感じる応答時間はその分伸びます。ディスクが遅ければ ④ で、CPU が足りなければ ② で、メモリが足りなければ ③ で、距離が遠ければ ① と ⑥ で時間が漏れていきます。

ボトルネックは 1 ヶ所で生まれる #

性能でもっとも重要な原則です。全体の速度はもっとも遅い 1 ヶ所が決めます。CPU がどれだけ速くても、ディスク読み込みで詰まればそのリクエストはディスクの速度に縛られます。

だからスペックをやみくもに上げる方法は効かないことが多いです。CPU がボトルネックなのにメモリを増やせば、コストだけ上がって速度はそのままです。まず どのリソースがボトルネックかを測り、そのリソースだけを補強するのが順序です。

CPU 8 コア  メモリ十分  ディスク遅い (HDD)  ネットワーク十分
   速い        速い         ← ボトルネック        速い

→ ディスクを SSD に替えるとボトルネックが消え、
   次に遅いリソースが新しいボトルネックになる。

ボトルネックは 1 つを解決すると次のリソースへ移ります。性能改善はこのボトルネックを追いながら 1 つずつ解く作業です。

CPU とメモリは離れている #

今日のほぼすべてのコンピュータは、計算する場所 (CPU) と データを置く場所 (メモリ) が分かれた構造に従います。CPU はメモリから命令とデータを取り出して計算し、結果をまたメモリに書きます。この往復が絶えず起きます。

ここで重要な事実が 1 つ出てきます。CPU はメモリよりずっと速いです。だから CPU はメモリを待って時間を浪費しがちで、この差を埋めるために CPU の中に小さな高速の保存先である キャッシュ を置きます。キャッシュがなぜ性能を左右するかは #2 と #3 でつなげていきます。

よくある誤解 #

「コアを増やせば常に速くなる」 #

違います。1 つの作業が複数のコアに分かれて初めて効果があります。シングルスレッドだけで動く作業は、コアを 8 個に増やしても 1 個のときと速度は同じです。#2 で詳しく扱います。

「メモリが多ければ速い」 #

部分的にしか正しくありません。メモリが足りなければ確かに遅くなりますが、十分な状態でさらに増やしても速くはなりません。メモリは速度を上げるリソースというより、足りないときに崖を作るリソースに近いです。

「容量が大きければストレージが速い」 #

容量と速度は別の軸です。1TB のディスクが 100GB のディスクより必ず速いわけではありません。速さは種類 (HDD・SSD・NVMe) と IOPS が決めます。#4 で切り分けます。

「遅い原因は勘でわかる」 #

もっとも高くつく誤解です。4 つのうち何がボトルネックかは測らなければわかりません。推測でスペックを上げると、コストだけ増えてボトルネックはそのまま、ということが多いです。

まとめ #

今回つかんだ絵です。

• サーバーの性能とコストは CPU・メモリ・ストレージ・ネットワーク の 4 つのリソースで決まります。
• CPU は計算、メモリ は作業空間、ストレージ は永続保管、ネットワーク は外との通路です。
• 1 回のリクエストは 4 つのリソースを順に通り、もっとも遅い 1 ヶ所が全体の速度を決めます。
• 性能改善は ボトルネックを測って 1 つずつ 解く作業です。推測でスペックを上げる方法はコストだけ増やします。
• この 4 つのリソースはシリーズの最後で、クラウドインスタンスのスペック表としてもう一度対応づけます。

次回 — CPU #

4 つのリソースのうち計算を担う CPU から 1 段深く入っていきます。#2 CPU — コア / スレッド / クロック / キャッシュ、そして vCPU の正体 では、コアとスレッドの違い、クロックだけで性能を比較できない理由、キャッシュが速度を左右する仕組み、そしてクラウドが言う vCPU が実際は何かまで整理します。