WEB問題集
オンプレミスの MySQL 8.0 を Cloud SQL for MySQL へ移行します。テーブル合計 800 GB、24 時間稼働の業務システムで、ダウンタイムは 30 分以内に抑えたいという要件があります。最も適切な移行方式はどれですか。
正解：B
正解の根拠
Database Migration Service (DMS) は MySQL の同種移行において、初期スナップショットと binlog ベースの継続的レプリケーションを管理サービスとして提供します。カットオーバー時にレプリカを昇格するだけで切り替えが完了するため、ダウンタイムを数分に抑えられます。
| 方式 | ダウンタイム | 運用負荷 |
|---|---|---|
| DMS 継続レプリケーション | 数分 | 低 |
| mysqldump 一括 | 数時間以上 | 中 |
| GCE 自前 binlog | 数分 | 高 |
不正解の理由
- A：800 GB のダンプとインポートで 30 分を大幅に超えます。
- C：自前運用の管理コストとリスクが増加します。
- D：BigQuery は分析基盤であり OLTP の中継には適しません。
Oracle 19c で稼働する基幹システムを PostgreSQL 互換のマネージドサービスへ移行する計画があります。PL/SQL ストアドプロシージャが約 1,500 本存在し、スキーマ変換の自動化と手動レビューの両方を効率化したいと考えています。最初に採用すべきツールはどれですか。
正解：A
正解の根拠
Ora2Pg は Oracle スキーマと PL/SQL を解析し、PostgreSQL への変換可否と工数を見積もるレポートを生成します。Google Cloud の Oracle to PostgreSQL 移行ガイドでも、事前評価フェーズでの Ora2Pg 利用が推奨されています。
| フェーズ | ツール | 役割 |
|---|---|---|
| 評価 | Ora2Pg | 互換性スコアとレポート |
| 変換 | Ora2Pg / 手動 | DDL と PL/pgSQL 出力 |
| データ移行 | DMS | 初期ロードと CDC |
不正解の理由
- B：DMS はデータ移行が主目的で、PL/SQL の自動変換は対象外です。
- C：CDC は変換評価の代替になりません。
- D：PostgreSQL 移行という前提を満たしません。
SQL Server 2016 Enterprise を Cloud SQL for SQL Server へ移行します。500 GB のデータベースで、SQL Server Agent ジョブ、リンクサーバー、CLR アセンブリを利用しています。移行前のリスク評価で最初に確認すべき項目はどれですか。
正解：D
正解の根拠
Cloud SQL for SQL Server はマネージドサービスとして一部の機能（特定の CLR、SQL Server Agent の一部機能、リンクサーバーの構成など）に制限があります。リスク評価の最初のステップは、サポートマトリクスと現行機能のフィット&ギャップ分析です。
| 確認領域 | 具体例 |
|---|---|
| 機能サポート | CLR、Agent、リンクサーバー |
| バージョン | SQL Server 2017/2019/2022 |
| サイズ上限 | ストレージ最大値、メモリ |
不正解の理由
- A：容量や PITR は機能適合後に検討する事項です。
- B：Windows ライセンスは移行先サービスでは Google が管理します。
- C：Cloud SQL はマネージドなのでマシンタイプ比較は二次的です。
Cloud SQL for PostgreSQL 14 を AlloyDB for PostgreSQL に移行します。500 GB のデータベースで、移行後はベクトル検索と列指向エンジンを活用したい計画です。最も推奨される移行手順はどれですか。
正解：C
正解の根拠
Database Migration Service は PostgreSQL ソース（Cloud SQL を含む）から AlloyDB への同種移行を正式サポートしており、論理レプリケーションを用いて初期ロードと CDC を継続的に同期させます。カットオーバー時にプライマリを昇格するだけで切替が完了します。
| 項目 | DMS | pg_dump |
|---|---|---|
| ダウンタイム | 数分 | 長時間 |
| CDC | あり | なし |
| 管理 | マネージド | 手動 |
不正解の理由
- A：論理ダンプではダウンタイムが長くなり、整合性管理も手作業になります。
- B：Cloud SQL のリードレプリカは AlloyDB へは延伸できません。
- D：BigQuery 経由は OLTP 移行に不適切です。
30 TB の Cassandra クラスタを Bigtable に移行します。アプリケーションは Cassandra Query Language (CQL) を用いており、移行後は Bigtable のスケーラビリティを活用したい意向です。最も適切な移行戦略はどれですか。
正解：D
正解の根拠
Cassandra と Bigtable はどちらもワイドカラム型ですが、行キー設計やセカンダリインデックスの仕組みが異なります。Google Cloud は Cassandra to Bigtable proxy や Dataflow テンプレートを提供しており、スキーマと行キーの再設計を伴う re-platform 型の移行を推奨します。
| 比較 | Cassandra | Bigtable |
|---|---|---|
| クエリ言語 | CQL | HBase API |
| セカンダリ Idx | あり | なし |
| 強整合性 | 調整可 | 単一行のみ |
不正解の理由
- A：Cassandra を GCE で運用するのは移行ゴールに反します。
- B：Spanner は OLTP リレーショナル向けで列指向ワークロードには適しません。
- C：Datastream は Cassandra ソースを正式サポートしません。