WEB問題集
金融系SaaS事業者がオンプレミスのモノリスをGoogle Cloudへ移行します。日次バッチが17時間に達しメンテナンス枠を超過しており、リリース頻度を週1から日次へ高める方針です。データ層はPostgreSQL 14、シングルライターで運用しています。アーキテクチャの初期判断として最も適切なものはどれですか。
解説
正解の根拠
Google Cloud への移行ガイダンスでは、評価と計画のあとにまず現行構成へ近い形で稼働させ、本番の実測データを得てから最適化する段階的アプローチが推奨されます。17 時間バッチとリリース頻度という 2 つの課題は、いずれも移行後に計測しながらバッチ分割やデータ層の再設計で個別に解消できます。先に Compute Engine へリフト＆シフトすれば PostgreSQL 14 の互換性とシングルライター構成をそのまま保てるため、移行時の停止リスクを最小化でき、「移行を完了させること」と「アプリを作り直すこと」のリスクを切り離して順に処理できます。
| 選択肢 | 移行戦略 | 初期リスク | 課題の解決 |
|---|---|---|---|
| 正解 (A) | Rehost の後に段階的最適化 | 低 | 移行後に順次解消 |
| (B) | 全面 Refactor | 高 | 一括変更で不確実 |
| (C) | データ層の総入れ替え | 高 | 互換性を失う |
| (D) | 現状維持 | 低 | 未解決のまま |
不正解の理由
- B: 一括書き換えは移行と再設計のリスクを同時に抱え、切り戻し先も失います。Firestore はドキュメント指向で、結合や強い参照整合性を要する金融処理をそのまま移せません。
- C: Bigtable は行キー設計に依存する NoSQL で SQL・結合・トランザクションの前提が異なり、PostgreSQL のスキーマを移せず移行計画が破綻します。
- D: オンプレミスに留めるとチューニング効果は既存ハードウェアの上限に縛られ、17 時間バッチとメンテナンス枠超過の根本解決になりません。
グローバルEC企業が、欧州・北米・アジアの3リージョンへ同時展開します。ユーザーの注文整合性は強整合性が必須で、在庫の二重販売は許容されません。読み取りは秒間50万、書き込みは秒間2万、SLOは99.99%です。データストアの最適解はどれですか。
解説
正解の根拠
Spanner はリレーショナル モデルと外部整合性 (external consistency) を両立するマネージド データベースで、TrueTime による時刻の不確実性の管理により、地理的に分散したレプリカ間でもトランザクションの直列化順序が保証されます。nam-eur-asia1 のようなマルチリージョン構成では書き込みが複数大陸のレプリカへ同期的にコミットされるため、どのリージョンから読んでも確定済みの最新値が返り、在庫の引き当てを単一トランザクションで排他できて二重販売が原理的に起こりません。読み取りはリードオンリー レプリカで水平に伸ばし、書き込みもキー範囲のスプリット分割によりノード追加でスケールするため、読み 50 万 RPS・書き 2 万 RPS を SLO 99.99 パーセント の要求とともに満たせます。
選択肢比較
| 選択肢 | 整合性モデル | 3 大陸での書き込みと要件充足 |
|---|---|---|
| A (正解) | Spanner マルチリージョン nam-eur-asia1 | 外部整合の ACID・同期コミットで二重販売を防止 |
| B | Cloud SQL HA + 各大陸のリードレプリカ | 単一ライター・非同期複製でアプリ調停が必要 |
| C | Firestore nam5 + クライアント シャーディング | nam5 は北米内・複数ドキュメント更新の一貫性が崩れる |
| D | Bigtable マルチクラスタ + アプリ側分散ロック | 結果整合でロック残留や二重取得のおそれ |
不正解の理由
- B: Cloud SQL for PostgreSQL は書き込みを受けるプライマリが 1 台で、各大陸のレプリカへの反映は非同期です。レプリカ遅延中の在庫読み取りで二重販売が起こり得るうえ、フェイルオーバー時のデータ損失も避けられません
- C: Firestore の nam5 は北米内のマルチリージョン構成であり、欧州とアジアの読み書きを同一構成に収容できません。クライアント側シャーディングを入れると在庫更新の一貫性が崩れ、強整合な引き当てになりません
- D: Bigtable のマルチクラスタ レプリケーションは結果整合で、クラスタ間の反映に遅延があります。アプリ側の分散ロックも障害時の残留や期限切れによる二重取得を避けられず、二重販売を許容しない要件には使えません
製造業の IoT プラットフォームで、世界中の30万台のセンサーから毎秒200万件の時系列メトリクスを取り込みます。直近24時間はミリ秒級でクエリしたく、過去2年は分析用に保持します。最適な取り込み・保管設計はどれですか。
解説
正解の根拠
毎秒 200 万件規模の時系列書き込みには、行キー設計に応じてノードを増やして水平スケールし、キー範囲の読み出しをミリ秒級で返せる Bigtable が適します。直近 24 時間分をここに保持し、ガベージ コレクション ポリシーで古いセルを自動的に期限切れにできます。過去 2 年分は列指向で圧縮とスキャンに優れる BigQuery に置いて分析用途に使い分けます。前段の Pub/Sub が流入のバーストを耐久性のあるバッファとして吸収し、Dataflow が変換しながら両方へ書き分けるため、ホットとコールドの要件を 1 本のパイプラインで満たせます (A)。Bigtable は行キーの範囲でデータが分散するため、センサー ID と時刻を組み合わせた行キーにすればホットスポットを避けながら直近データの範囲読み取りを高速に行えます。
選択肢比較
| 選択肢 | 取り込みと保管の構成 | 要件への適合 |
|---|---|---|
| A (正解) | Pub/Sub から Dataflow で Bigtable と BigQuery へ | ホットはミリ秒級、コールドは長期分析を両立 |
| B | MQTT から Cloud SQL へ直接書き込み | 書き込みが単一プライマリに集中し流量を捌けない |
| C | Firestore に全書き込みし TTL とエクスポート | ドキュメント型で大量の時系列書き込みに不向き |
| D | Cloud Run functions で同期処理し JSON を Cloud Storage へ | バーストで詰まり、ミリ秒級クエリも成立しない |
不正解の理由
- B: Cloud SQL は書き込みが単一のプライマリに集約されるため、垂直スケールの上限を超える秒間 200 万件は受け切れません。リードレプリカは参照を分散するだけで書き込みスループットを改善しません
- C: Firestore はドキュメント単位の更新に最適化されており、同一ドキュメントの更新頻度に制限があるうえ、都度エクスポートを介する分析では 2 年分の集計を現実的な時間で終えられません
- D: 同期的に関数を呼び出す構成は流入のバーストに追随できずバックログが膨らみます。JSON をそのまま保管する形式ではスキャン量が大きく、直近 24 時間のミリ秒級クエリを満たせません
SaaS 企業が複数チームで Google Cloud を利用するため、共通のネットワークを集中管理しつつ、各チームに独立したプロジェクトでワークロードを動かさせたいと考えています。組織ポリシーで VPC の作成権限はネットワークチームに限定したい場合、最適な設計はどれですか。
解説
正解の根拠
Shared VPC はホスト プロジェクトに VPC、サブネット、ルート、ファイアウォールを集約し、そこにサービス プロジェクトとしてアタッチした各チームのプロジェクトから、割り当てられたサブネットに対してインスタンスなどのワークロードだけを作成させる構成です。ネットワーク リソースの作成・変更権限はホスト側に置いたままなので、compute.networkAdmin のような権限をチームへ渡さずに済み、VPC 作成権限をネットワーク チームに限定するという要件を満たします。一方で各チームは自分のプロジェクトを持ち続けるため、IAM、課金、クォータ、API の有効化は独立したまま運用でき、集中管理と分権を同時に成立させられます。
選択肢比較
| 選択肢 | 構成 | ネットワーク権限の集中 | チームの独立性 |
|---|---|---|---|
| A | 単一プロジェクトを全チームで共有 | 同一プロジェクト内で分離困難 | 課金と IAM が混在 |
| B (正解) | Shared VPC のホストとサービス プロジェクト | ホスト側に集約 | プロジェクト単位で独立 |
| C | プロジェクト間で VPC ピアリングを網状構成 | 各プロジェクトに分散 | 接続管理が複雑化 |
| D | 組織レベルの VPC を全プロジェクトへ付与 | チームに作成権限を付与 | 構成自体が存在しない |
不正解の理由
- A: 単一プロジェクトの共有は IAM 境界、課金、クォータが一体化し、ファイアウォール タグの設定ミスがそのまま他チームへ波及します。
- C: VPC ピアリングは推移しないためチーム数に対して接続が急増し、CIDR 重複や上限の管理が重くなるうえ、ネットワーク権限も各プロジェクトに分散したままです。
- D: VPC は必ずプロジェクトに属するリソースで、組織レベルの VPC を各プロジェクトへ直接付ける構成は存在せず、チームに変更権限を渡す点も要件に反します。
オンプレミスのデータセンターと Google Cloud を 99.99% の可用性で接続する必要があります。トラフィックは 8Gbps、平均レイテンシ 2ms 以下が要件で、暗号化はアプリケーション層で実施済みです。設計上必須となる要素を 2 つ選んでください。
解説
正解の根拠
Dedicated Interconnect で 99.99% の可用性 SLA を満たすには、異なる 2 つのメトロにそれぞれ接続を用意し、各メトロで 2 つのエッジ アベイラビリティ ドメインを使う構成が必要です。これにより一方のメトロやドメインで障害や計画メンテナンスが起きても残りの経路が生き残ります。さらに各 VLAN アタッチメント上で Cloud Router の BGP セッションを確立すると、経路が動的に交換されて障害時に自動で切り替わります。両者が揃って初めて SLA の前提を満たします。
選択肢比較
| 選択肢 | 要素 | 99.99% / 帯域・遅延要件 |
|---|---|---|
| A | プロジェクト集約と接続 1 本化 | ×: 冗長性が無く SLA の前提を満たさない |
| B | 2 メトロ × 2 エッジ アベイラビリティ ドメイン | ○: 冗長トポロジの必須要件 |
| C | Cloud Router の BGP で動的経路 | ○: 自動フェイルオーバーの必須要件 |
| D | HA VPN のみで Interconnect を使わない | ×: 帯域と遅延が保証されない |
不正解の理由
- A: 接続を 1 本に集約すると、その回線や設備の障害・メンテナンスがそのまま全断になり、冗長構成を前提とする 99.99% SLA を満たせません。
- D: HA VPN はインターネット経由の IPsec で、トンネルあたりの帯域上限に縛られ経路品質も保証されないため、8 Gbps と平均 2 ms の要件を満たせません。