WEB問題集
金融サービス会社で稼働している Cloud SQL for MySQL がゾーン障害により 30 分のダウンタイムを記録しました。RPO はほぼゼロ、RTO は数分以内が要求されています。最小の運用工数で要件を満たすにはどの構成を採用すべきですか。
正解：D
正解の根拠
Cloud SQL の HA 構成はリージョナル永続ディスクで同期書込みを行い、自動フェイルオーバーで RPO ≒ 0、RTO 数十秒〜数分を達成します。
| 項目 | HA 構成 |
|---|---|
| RPO | ほぼゼロ（同期書込み） |
| RTO | 60〜120 秒 |
| 運用 | 自動フェイルオーバー |
不正解の理由
- A: 外部レプリカは管理負荷が高く自動フェイルオーバーの仕組みも欠けます。
- B: 非同期のため RPO がゼロにならず、昇格も手動で RTO 要件を満たしません。
- C: 5 分間隔のバックアップでは RPO を保証できず、復元時間も長くなります。
EC サイトの Cloud SQL for PostgreSQL で誤った UPDATE 文が実行され、特定テーブルが破損しました。事象から復旧までの間隔は 4 時間で、運用チームはトランザクション粒度の巻き戻しを求めています。最も適切な復旧手段はどれですか。
正解：B
正解の根拠
PITR は WAL を保持し、秒単位の任意時刻へ復元できるため、論理破損のリカバリに最適です。
| 方式 | 粒度 | 用途 |
|---|---|---|
| PITR | 秒単位 | 論理破損復旧 |
| 自動バックアップ | 日次 | 大規模災害 |
不正解の理由
- A: 前日復元では事象直前までの正常データを失い RPO が悪化します。
- C: レプリカも同じ UPDATE を受信しており昇格しても復旧になりません。
- D: エクスポートはスナップショット時点のみで時刻指定不可です。
Spanner のマルチリージョン構成で稼働する決済サービスにおいて、リージョン全体障害でもサービス継続したいという要件があります。どの構成を採用しますか。
正解：C
正解の根拠
Spanner のマルチリージョン構成は複数リージョンに同期レプリカを配置し、リージョン障害時にも 99.999% の SLA で稼働を継続します。
| 構成 | SLA |
|---|---|
| マルチリージョン | 99.999% |
| リージョナル | 99.99% |
不正解の理由
- A: 独自同期は強整合性を確保できず Spanner の利点を失います。
- B: シングルリージョンではリージョン障害で停止します。
- D: BigQuery エクスポートは分析用途で OLTP 継続はできません。
参考：Spanner 構成
Bigtable クラスタを単一クラスタで運用していますが、99.999% の可用性が必要になりました。アプリ側のフェイルオーバー実装は最小限にしたい状況です。最適な構成はどれですか。
正解：B
正解の根拠
Bigtable のレプリケーションでマルチクラスタルーティングを設定すると、クライアントが自動的に利用可能クラスタへ切替えるため高可用性を実現できます。
| ルーティング | 挙動 |
|---|---|
| マルチクラスタ | 自動フェイルオーバー |
| シングルクラスタ | 手動切替 |
不正解の理由
- A: ストレージ種別変更だけでは可用性は向上しません。
- C: バックアップは復旧手段でリアルタイム可用性は得られません。
- D: ノード追加はスループット改善でフェイルオーバーは別問題です。
AlloyDB for PostgreSQL でアナリティクス用途のクエリが遅く、フルスキャンが頻発しています。クエリパターンは集計と範囲スキャンが中心です。次の一手として何を行いますか。
正解：C
正解の根拠
AlloyDB のカラムナエンジンは頻出列を列指向でメモリ展開し、分析系クエリを大幅に高速化します。
| 用途 | 機能 |
|---|---|
| 分析 | カラムナエンジン |
| OLTP | 行指向ストレージ |
不正解の理由
- A: 移行は高コストで PostgreSQL 互換性も失われます。
- B: マシン強化は緩和策で根本的なスキャン削減にはなりません。
- D: PITR 設定はバックアップ要件で性能と無関係です。