【入門編】内部パフォーマンスメトリクス – Cloud Spanner

こんにちは！Cloud Spannerの世界へようこそ。
プロジェクトでデータベースの選定や運用に関わるようになると、「巨大なデータでも止まらずに動き続けるデータベース」として、必ず名前が挙がるのがこのCloud Spannerですね。

「なんだか凄そうだけど、内部の動きが見えなくてブラックボックスみたい……」
そんな風に感じていませんか？大丈夫です。今回は、Cloud Spannerのエンジンルームの裏側を覗き見するような気持ちで、「内部パフォーマンスメトリクス（監視の指標）」についてお話しします。

ここをクリアすれば、Cloud Spannerの基本はバッチリマスターできますよ。難しい専門用語はできるだけ使わず、身近な例え話と一緒に紐解いていきましょう！

—

1. Cloud Spannerの裏側：巨大スーパーに例えてみよう

まず、Cloud Spannerがどうやって動いているのかをイメージするために、「世界中で大人気の巨大スーパーマーケット」を想像してください。

このスーパー、毎日世界中からお客さん（リクエスト）が押し寄せます。もしレジが1つしかなかったら、大行列になってお店がパンクしてしまいますよね。
そこでCloud Spannerは、次のような仕組みをとっています。

スプリット（Split）： スーパーの売り場を「お菓子売り場」「生鮮食品売り場」「日用品売り場」という風に、細かくエリア分けすること。Cloud Spannerでは、データが大きくなると自動的にこの「エリア（＝スプリット）」に分割され、別々の店員さんたちが担当します。
ノード（Node）： そのエリアを担当する「店員さん（コンピューター資源）」のこと。

データが増えたり、特定の場所に注文が集中したりすると、Spannerはこのエリア（スプリット）を自動で分割したり、別の店員さんにヘルプを頼んだりしてバランスを取ります。

私たちが監視する「内部パフォーマンスメトリクス」とは、いわば「各売り場の店員さんが今、どれくらい忙しそうにしているかを測る健康診断のカルテ」なのです。

—

2. 押さえておきたい4つの重要メトリクス

Cloud Spannerの管理画面（Google Cloudコンソール）を開くと、たくさんのグラフが並んでいて目が回りそうになりますよね。でも、最初は以下の4つだけ押さえれば完璧です。

① スプリットごとのCPU使用率（店員さんの疲労度）

どんなもの？： 各エリア（スプリット）を担当しているCPUが、どれくらい働かされているかを示す指標です。
例え話： 「お菓子売り場」のレジに人が殺到して、店員さんが汗だくでレジ打ちをしている状態です。
なぜ重要？： Cloud Spannerでは、特定のデータだけにアクセスが集中する（これを「ホットスポット」と呼びます）と、そのエリアを担当するCPUだけが100%になり、パフォーマンスが落ちてしまいます。「特定の店員さんだけに負担が偏っていないか？」をチェックするために見ます。

② メモリ使用量（作業机の散らかり具合）

どんなもの？： クエリを処理するために、どれくらい一時的な記憶領域を使っているかを示します。
例え話： 店員さんがレジカウンターの上を書類や計算用紙の山にしてしまい、作業スペースが狭くなっている状態です。
なぜ重要？： メモリを使い果たしてしまうと、データベースは急激にスローダウンするか、エラーを起こします。複雑すぎる検索（非効率なクエリ）がメモリを圧迫していないかを確認します。

③ ディスクI/O（倉庫からの荷物の出し入れ）

どんなもの？： データの読み書きが、どれくらいディスク（ストレージ）で行われているかを示します。
例え話： レジの棚に商品がないため、わざわざ裏の巨大倉庫まで走って商品を取ってくる頻度のことです。
なぜ重要？： よく使うデータはなるべく手元（メモリ）に置いておきたいもの。ディスクへのアクセスが多すぎる場合、キャッシュが効いていない証拠であり、データの持ち方や検索方法を見直すサインになります。

④ ネットワーク待機時間（お客さんと店員さんの会話のスピード）

どんなもの？： リクエストが届いてから答えを返すまでの通信や処理にかかっている時間（レイテンシ）です。
例え話： お客さんが「これいくら？」と聞いてから、店員さんが答えを返すまでの待ち時間です。
なぜ重要？： ユーザーがシステムを使うときの「サクサク感」に直結します。ここが跳ね上がっている場合は、①〜③のどこかで詰まり（ボトルネック）が発生しているサインです。

—

3. 実務でどう活かす？トラブルシューティングの基本姿勢

これらのメトリクスを見ていると、時々「おや？」と思うようなアラートやグラフの跳ね上がりに遭遇します。そのときの先輩エンジニアとしての心構えを伝授しますね。

黄金のルール：まずは「偏り（ホットスポット）」を疑え

Cloud Spannerは、基本的に「オートスケール（自動で規模を拡大縮小してくれる）」の優等生です。全体的にデータが増えただけなら、自動で店員さんが増員されて何事もなく処理してくれます。

しかし、「特定のデータだけ」にアクセスが集中する場合（例えば、SNSで秒速でバズっている特定の投稿に対する「いいね」のカウントなど）は、自動分割が間に合わず、特定のスプリットのCPUが悲鳴を上げます。

[悪い例：特定のエリアに集中]
ユーザー ──> [ スプリット A (CPU 99%!) ] ⚠️ ここがパンク！
ユーザー ──> [ スプリット B (CPU 5% ) ]
ユーザー ──> [ スプリット C (CPU 5% ) ]

[良い例：綺麗に分散]
ユーザー ──> [ スプリット A (CPU 30%) ]
ユーザー ──> [ スプリット B (CPU 35%) ]
ユーザー ──> [ スプリット C (CPU 32%) ]

もし「CPU使用率」のグラフが一部だけ跳ね上がっていたら、設計の段階で「プライマリキー（データの住所のようなもの）」の付け方に偏りがないかを見直してみましょう。連番（1, 2, 3…）ではなく、ランダムな文字列（UUIDなど）を使うことで、データが綺麗に全エリアに分散され、店員さんたちの負担が均等になります。

—

おわりに

いかがでしたでしょうか？
Cloud Spannerの内部パフォーマンスメトリクスは、難解な数字の羅列ではなく、「データベースという街で働く人たちの働きぶりを映し出す鏡」です。

CPUで働きすぎの店員がいないか？
メモリの机が散らかっていないか？
ディスク倉庫への往復が多くないか？

こうした視点を持って監視画面眺められるようになると、Spannerはただの「黒い箱」ではなく、意思を持った頼もしい相棒のように見えてきます。

基礎をしっかり押さえたあなたなら、もうCloud Spannerの運用で迷うことは怖くありません。自信を持って、次のステップへ進んでいきましょう！