【正解】B
【0からの解説】
①前提知識
Spanner では、インスタンスに割り当てる「コンピューティング容量」（ノード数または処理ユニット（PU）数。1 ノード = 1,000 PU）によって、処理能力だけでなく保存できるデータ量の上限（ストレージ上限）も決まります。公式ドキュメントでは、1 ノード以上のインスタンスはノードあたり 10 TiB、1 ノード未満では 100 PU ごとに 1,024 GiB が割り当てられます。上限を超えるとデータベースへの書き込みが拒否される可能性があり、その場合はコンピューティング容量を追加する必要があります。コンピューティング容量の変更はオンラインで行え、ダウンタイムは発生しません。
②要件と制約の整理
・オートスケーラーがないため、容量は手動で増やす必要がある。
・数時間以内にストレージが不足する → 「できるだけ早く」解決する必要がある。
・本番稼働中で、書き込みが拒否されると業務に直接影響する。
③正解が要件を満たす理由
ノード数（または PU 数）を増やせば、ストレージの割り当て上限も比例して増えます。コンソールや gcloud から数分で実行でき、サービスを止めずに直ちに上限を引き上げられるため、「できるだけ早く」という要件に最も合致します。今後は Spanner のマネージド オートスケーラーを有効にして、ストレージ使用率も考慮した自動スケーリングを検討するとよいでしょう。
【誤りの選択肢】
A：読み取り専用レプリカは読み取りスループットやリージョン外への低レイテンシ読み取りのための機能であり、書き込み可能なデータの保存上限は増えません。カスタム インスタンス構成の作成も即時の対処には向きません。
C：マルチリージョン構成への移動は可用性と地理的な分散のための変更で、ストレージ上限の問題を直接解決しません。インスタンス構成の移動には時間がかかり、コストも大きく増えるため、数時間以内という緊急性にも合いません。
D：過去データのアーカイブと削除は長期的なデータ保持の施策としては有効ですが、エクスポートや削除の実施・検証に時間がかかります。また Spanner では削除したデータの領域がバージョンの保持期間やコンパクションを経てから回収されるため、ストレージ使用量がすぐには減らず、緊急の対処として不確実です。本番データを急いで削除するリスクもあります。
【参考】
コンピューティング容量、ノード、処理単位 | Spannerインスタンスを作成、管理する | Spanner