設計の判断
移行の計画
移行は、Migration Center で今あるものを棚卸しし、ワークロードごとに移行の型を決め、移すものの種類で道具を選ぶ順に進めます。
移行の問題で問われるのは、何をどの順番で決めるかです。最初に Migration Center で現状のサーバーとデータベースと依存関係を洗い出し、ワークロードごとに rehost や replatform などの型を決めます。道具は移すものの種類でほぼ決まります。
移行は 4 つのフェーズで進む
4 つのフェーズは Google Cloud の移行ガイドの分け方です。評価では棚卸し、依存関係、総保有コスト (TCO)、性能の基準値を取ります。計画では ID 管理、組織とプロジェクト、ネットワークを用意します。中身は リソース階層と請求 と IAM の基本 で学んだとおりです。棚卸しをせずに VM を移し始める選択肢は、順序が逆なので外します。
Migration Center は、オンプレミスの環境をスキャンしてサーバーと SQL Server、MySQL、PostgreSQL のデータベースの一覧を作ります。集めたデータから TCO のレポート、アプリ間とネットワークの依存関係、資産ごとの移行先と費用の見込みを出します。「移行の費用対効果を経営層に示したい」「どのサーバーから移すか判断したい」とあれば Migration Center が答えです。
移行の型はワークロードごとに選ぶ
| 型 | 何を変えるか | 選ぶ条件 |
|---|---|---|
| Rehost (lift and shift) | ほぼ何も変えない。VM をそのまま Compute Engine へ | 期限が厳しい。アプリに手を入れる人がいない |
| Replatform (lift and optimize) | 動く場所を変える。コンテナにして GKE へ、DB を Cloud SQL へ | コードはあまり変えずに運用の手間を減らしたい |
| Refactor (move and improve) | クラウドの機能を使うようにコードを直す | 性能、費用、機能を移行と同時に改善したい |
| Re-architect | 作りを変える。モノリスをマイクロサービスに分ける | 今の構造が規模の拡大に耐えない |
| Rebuild (remove and replace) | 捨てて作り直す | 直すより書き直すほうが安い |
| Repurchase | SaaS に置き換える。メールを Google Workspace に | 自社で持つ理由がない業務用のソフト |
迷ったら rehost で移し、最適化のフェーズで直します。移行と改修を同時に行うと、障害の原因を切り分けられません。ただし「移行と同時に運用の負荷を減らす」とあれば replatform を選びます。作る、買う、改修する、廃止するの判断は 要件からアーキテクチャを組む でも扱っています。
移すものの種類で道具が決まる
Migrate to Virtual Machines は vSphere、AWS、Azure、Google Cloud VMware Engine の VM を Compute Engine へ移します。Database Migration Service は MySQL、PostgreSQL、SQL Server を Cloud SQL や AlloyDB へ移し、初回のコピーのあと変更を継続的に複製します。「停止時間を最小に」とあればこの継続的な移行を選びます。ダンプと読み込みでは、停止時間がデータ量に比例して延びます。Oracle や SQL Server から PostgreSQL 系へエンジンを変える移行も同じサービスで、変換ワークスペースでスキーマを変換します。
Storage Transfer Service は Amazon S3、Azure Blob Storage、Cloud Storage などからの転送と、エージェントを置いたオンプレミスからの転送を扱います。大規模データの転送ガイドによると、100 TB を送るのに 1 Gbps で 10 日以上、100 Mbps で 100 日以上かかります。期限までに送り切れず増速も間に合わなければ Transfer Appliance を選びます。提供される国が限られる点に注意します。
依存関係とネットワークを先に計画する
頻繁に通信するアプリとデータベースを別々に移すと、通信が遅くなったり切れたりします。依存関係から、一緒に移すまとまり (ムーブグループ) を決めます。
移行中のオンプレミスとの接続には Cloud VPN か Cloud Interconnect を使います (オンプレミス・マルチクラウドとの接続)。VPC のサブネットの範囲は、オンプレミスと重ならないよう計画のフェーズで決めます。重なるとあとからルーティングできません。移す前には評価で取った性能の基準値を満たすかを試験し、元へ戻す手順 (ロールバック) も決めておきます。
ライセンスで費用が変わる
Compute Engine の Windows Server などのプレミアム イメージは、ライセンスの料金が VM の料金に含まれます。物理コア数や物理プロセッサ数で数えるライセンスを持ち込む (BYOL) なら、物理サーバーをほかの顧客と共有しない単一テナントノードを使います。メンテナンス時の動作を restart-in-place か migrate-within-node-group にすると、VM がノードグループの外へ移らず、数える物理サーバーが増えません。
RHEL や SLES の BYOS、SharePoint Server や SQL Server などは単一テナントノードなしで持ち込めます (Microsoft のアプリは License Mobility の条件によります)。
試してみる
Storage Transfer Service でバケット間を転送します。他クラウドからでも、転送元の指定が変わるだけです。
PROJECT_ID=$(gcloud config get-value project)
SRC=gs://${PROJECT_ID}-dojo-src
DST=gs://${PROJECT_ID}-dojo-dst
gcloud services enable storagetransfer.googleapis.com
gcloud storage buckets create $SRC $DST --location=asia-northeast1
# 転送元にファイルを置く
for i in 1 2 3; do echo "file $i" > /tmp/dojo-$i.txt; done
gcloud storage cp /tmp/dojo-*.txt $SRC/
# Storage Transfer Service のサービス エージェントに必要な権限を付ける
gcloud transfer authorize --add-missing
# 転送ジョブを作る。スケジュールを付けなければ、作成と同時に 1 回実行される
gcloud transfer jobs create $SRC $DST --name=transferJobs/dojo-copy
gcloud transfer operations list --job-names=transferJobs/dojo-copy
gcloud storage ls $DST移行期間中に転送元への書き込みが続くなら、スケジュールで差分を送り続け、切り替えの直前に最後の 1 回を実行します。
後片付けをします。
gcloud transfer jobs delete transferJobs/dojo-copy
gcloud storage rm --recursive $SRC $DST
rm /tmp/dojo-*.txt試験で問われる判断
以下は、このカリキュラムで作った例です。
「データセンターの契約が 3 か月後に切れる。数百台の VMware の VM を、アプリに手を入れずに移したい」。rehost で、Migrate to Virtual Machines を使います。VMware のまま運用を続けたいなら Google Cloud VMware Engine も候補です。
「Oracle のライセンス費用をなくすため PostgreSQL 系へ移す。停止時間は最小に」。Database Migration Service の異種移行で AlloyDB か Cloud SQL for PostgreSQL へ移します。
「拠点に 500 TB のデータがあり、回線は 100 Mbps。2 か月以内に移したい」。回線では 100 日を大きく超えるので Transfer Appliance です。
「移行の対象と優先順位をまだ決めていない。経営層に費用の見込みを示したい」。最初の作業は Migration Center での棚卸しと TCO のレポートです。
次のページでは、移したあとのシステムの費用を下げる方法を扱います。