「Google Cloud で実践するクラウドマイグレーション　GCP への移行のポイントや先進事例について学ぶ　2019 年 9 月 4 日（水） 15:00–19:30」　発表資料。　Migrate for Compute Engineの事例となります

1. Google Cloud で実践するクラウドマイグレーション
LIFT＆SHIFT（V2V、V2K）を成功させるた
めのヒント
日本情報通信株式会社

2. 日本情報通信株式会社
IBM の最先端テクノロジを使用して、 NI + C はシステム開発、製
品とサービス、ネットワークサービスなどのさまざまな分野のお客
様に管理関連ソリューションを提供します。 IBM のハードウェアと
ソフトウェアのフルラインナップだけでなく、市場に出回っている幅
広いIBM 以外のミドルウェアも提供しています。当社の技術スペ
シャリストは、お客様のニーズに応じてシステムを設計、構築、お
よび保守することができます。
創業32年目 日本IBM +
NTT
Software/Cloudの売上高
グループ全体エンジニア数>1000
400+
30+

3. 常田 秀明
日本情報通信株式会社
クラウドテクニカルエバンジェリスト
Facebook: hideaki.tokida
Twitter : @tokida
今年のテーマは既存アプリのモダナイ
ゼーション（理想はあれど実装は泥臭い
世界、データをどうするかがとても難しい）
好きなサービスは、PaaS全般。ノンコー
ディングツールも好き。

4. 概要
オンプレミスのワークロードをクラウドに簡単に移行するためにGCPでは
V2VそしてV2Kをサポートしています。 これからGCPへの移行を検討して
いる企業さま向けに弊社での移行事例を基にマイグレーションを行うため
に必要となる環境面の準備、移行計画を立案する際に利用したほうが良
い機能などの知見を共有します。

5. 1
Migrate for Compute
Engine (旧 Velostrata)
を選択する理由

6. GCP に移行してみました
社内システムとして利用している、静脈認証システ
ムを GCP 環境へ移行してみました。
1. オーナーは総務部
2. システムは NI+C が外販しているNI+C Cloud X
(VMWare ベース)を利用中
3. ネットワーク設備は情報システム部門管轄の運用子
会社に委託
4. 運用や故障は情報システム部門に委託
5. 関連機器の保守はメーカと直接やり取り
クラウドチーム
(GCP 移行担当）
総務部
（オーナ部門）
情報システム部門
NI+C Cloud x
SIer
LOB
IT
既存
ベンダ

7. 静脈認証システムってどんな仕組み？
● 某社製アプリ（サーバ・クライアント型)
（製品に付随するサーバソフトウェア）
● 負荷が高いのは朝の 10 時前後(大きな
変動はない）
● システム連携がされており勤怠管理など
と連携している

8. 静脈認証システムってどんな仕組み？
● 既製品のためアプリケーションは
再構築できない
● 性能については現行通り（夜間で
も利用の可能性あり）、性能面の
考慮はネットワークレイテンシ（と
トラフィック量）
● 他システムとの通信接続必要 モノリスアプリ（従来）
オンプレミスリソース
モノリスアプリ（従来）
クラウドリソース
モダンアプリ（マイクロサー
ビス等）
オンプレミスリソース
モダンアプリ（マイクロサー
ビス等）
クラウドリソース
V2V
V2K

9. 移行先の比較（VMware or VM)
サービス名称 コメント 品質 コスト 構築
A 社 ベアメタルサーバ上に VMware 環境を構築し利用可能。現行は VMWare ベースであるが基盤運用までを
行っているわけではない。したがって移行作業は、 VM イメージ移動できるが運用コストが増えることになる。
そのため費用面では全システム移行を前提に考える必要がある。
○ x ○
B 社 VMware ベースの環境であり移行は容易。通信環境的にも既設のネットワーク設備のオプションサービスで
利用可能。ただしトータルコストが割高
○ x ◎
仮想サーバベースであるが移行ツールが今回の要件に適合。仮想サーバ、ネットワーク環境としては安定し
て動作している実績がある。今回の安価に利用可能。周辺の SaaS が充実しており今後のシステム拡張が検
討できる。
○ ◎ ◎
自社既存 ESXi(オンプレ) ハードウェアの増強費用と構築費用と構築が開始可能になるまでの期間がかかる。また機器購入のために
は 5 年の計画が必要になる。場合によっては移行の際に関連ソフトウェアのバージョンアップが必要
△ x ◎
VM 再構築し各社のクラウド上に
実装
再導入および試験には期間も時間もかかる。そのため今回は VM イメージを活用して移行できる方式を検
討したい。またすでに初期構築時の手順などがなく再度確認が必要となる。
△ x x

10. VMWare
GKE-Onpre Anthos
GCP
Anthosの概要
モダナイズの実現
GKE
c1 c2 c3 c4
VMWare/AWS/Azure
VM
2
VM1
VM1
VM
2
Migration for Anthos
Migration for Compute Engine
オンプレミス(他社クラウド） Google Cloud Platform
Stackdriver
GKE
On-Prem
Kubernetes
Engine
Compute
Engine
Monitorin
g
Logging Error
Reporti
ng
Trace
Anthos Configuration Manager
Istio

11. Migrate for Compute Engine の良い機能
1. 事前にテストモードで起動ができる
2. ストリーミングでデータが転送（Run in Cloud ＆ Storage Migration)

12. 移行計画(実績）
主に移行後のコスト、移
行に関する作業費用の見
積もり（移行プロジェクト
の予算化）
技術的な要求事項の確
認
移行先環境の検討
各関連部門との進行調整
各関連部門への依頼事
項の発行
ネットワーク環境の構成・
移行後の GCP 環境の構
成
移行元 ESXi 環境への変
更点整理
移行検証環境の構築（導
入手順の確認、 Migrate
for Compute Engine の
機能検証）
移行後の試験項目の確
認
移行計画の立案
移行元代替 ESXi サーバ
への構成・アプライアンス
の導入 (*1)
移行元 ESXi サーバから
VM イメージの取得 (*1)
ESXi サーバと GCP 環境
の VPN 環境の確立
動作試験（静脈認証の登
録端末（オンプレミス上）
と GCE）上の動作確認）
移行（ストリーミング転送）
(*3)
立案
（1Week）
プロジェクト発足
（3week）
設計
(2week)
構築
(2week)
移行
(1day)
実際は準備1日、実施1日

13. Migration for Compute Engine の構成
日本情報通信
オフィス
オフィスA
(聖路加)
オフィスB
(ニチレイ)
認証
登録
認証
登録
NI+C既存回線新規回線
ESXi asia-northeast1
asia-northeast1-basia-northeast1-a
ミラーリング(冗長化)
移行先VM
GCE front manager
Virtual Private
Cloud
Cloud Storage
Cloud ExtensionCloud Extension
移行先環境
Internet
Cloud VPN
NI+C YDC
vCenterPSCESXi host暫定VM
DNS/
JUMPIMM
Cloud
Armor
Stackdriver
Cloud
IAM
Router
PFsence
back manager
端末管理
：
n
移行元VM
NI+C Cloud X 移行基盤 - 移行検証環境
VM移行時に利用
入退室管理システムへ
通信時に利用
Cloud NAT

14. 2
Getting Start でつまずくポ
イント

15. はじめてみるためにチョットだけ気をつけること
1. 既存の環境や管理面での影響
2. 移行後のコストからの予算化
3. ライセンス
4. 移行前の通信環境の確立
5. 環境で気をつけること
6. Migrate for Compute Engineの機能を活用
7. 複数ディスクもOK
8. モニターで進捗を確認

16. 1. 根回し・既存環境への影響
● 仮想基盤(ESX vCenter)へ構成変更が発生
● 新環境(GCP)の接続環境の用意（既存機能
への影響）
● 性能の影響
● 非機能の機能が変更
クラウドチーム
(GCP 移行担当）
総務部
（オーナ部門）
情報システム部門
(運用・管理・NW）
NI+C Cloud x
（インフラ提供）
SIer
LOB
IT
既存
ベンダ
?
既存の根回し

17. 1. 根回し・既存環境への影響
前提条件である ESX vCenter の機能追加が可能であるか確認し調整しよう。
● vCenter に対しての高権限のユーザが必要
● 利用可能な ESX vCenter が存在しない場合には別途構成を検討
● 一時的に VM を移行用の ESX 基盤に移動するなども必要に応じて検討して
いく必要がある（Snapshot 分の空き容量等）
● Migrate for Compute Engine（旧 Velostrata）はFlash 版の vCenter からの
操作がメイン
● VM上にもいくつかドライバ等が必要

18. 2. 移行後のコストからの予算化
VMのサイズ変更だけでなくネットワー
ク環境含めて全体で考える必要があ
る。
● 移行前に価格をリコメンドする仕
組みがある
● 3rd Party製品を利用することで詳
細確認する事ができるはず!?(例:
Cloud Physics等)
● https://www.youtube.com/watch?v=HUHBq_VGgFg

19. 3. ライセンス（BYOL）
持ち込みライセンスについての理解をす
る
● 基本は GCE で提供するライセンスに移
行。単独テナントノード(β)を利用する場合
には BYOL がサポートされる（wave の機
能で移行する場合に選択可能）
● GCE でサポートされないOS のライセンス
については... 要確認
Migration
Mode
Migrate for Compute Engine
Support Operating System
Online WIndows Server 2008 R2 SP1
or higher
CentOS 6.4 + / 7
Windows Server 2012 / 2012
R2
RHEL 6.4+ / 7
Windows Server 2016 Debian 8.5+ / 9
Windows Server 1709 (SAC) Ubuntu 14 / 16 / 18
SUSE 11 SP3+ / 12 SP2 / 12 SP3 / 12
SP4 / 15
Offline Windows Server 2003 / 2003
R2
Ubuntu 12.x
Windows Server 2008

20. 4. 移行前の通信環境の確立
Migrate for Compute Engine (旧 Velostrata）において最も大切な前提条件は
ネットワークが正しく VPN を経由して疎通していること。
● VPN が利用出来なくても手順が最後の方まで進むが Cloud Extension 関連
を実行したい際にエラーになる。
● 移行後は VPN は必須ではない。
● ネットワーク帯域/ストレージは余裕があるとよい
● 台数が増えることで帯域がどのようになるか

21. 5. 環境で気をつけること
1. ID周りは全面的に変更されます
2. HAシステムなどの場合には移行後の構成を検討しておく
3. Cloud Extension は自動で停止するがSSD分があるので課金が発生
するので不要であれば削除しておく
4. DNSを利用している場合での名前解決手段（AD利用してる場合など
も考慮が必要）
5. 移行後に非機能（Stackdriverやバックアップ）はクラウド化しておく

22. 6. Migrate for Compute Engineの機能を活用
Migrate for Compute Engine のストリーミング・切り戻しの動作などを実際に動作
してみて計画を立案しよう。
● 実際の移行には複数台を設定可能な Runbook が利用できます。
● 事前に Migrate for Compute Engine (旧 Velostrata）らしい動きを再度手動
で確認して問題が発生した際の切り戻しなどの動きを確認して起きます

23. 7. 複数ディスクもOK
● ストレージが複数ある場合でもStorage Migration可能

24. 8. モニターで進捗を確認
● vCenter側と、Stackdriverで動作状況
を確認可能
● 移行の進行パーセントやWrite Commit
待ちサイズはvCenterからしか見えない
が全体のメトリック値はStackDriveに流
れているのでそちらからモニタリング、
アラート発砲するのが良さげ

25. 3
動いているMigrate for
Compute Engineのデ
モ

26. Migrate Demo (8min)
1. Run in Cloud と Run in On-prem ( Move Back )
不具合が起こった時でも移行を切り戻す事が可能
2. Wave を利用した AWS からの移行
「WAVE」を利用すると一括でバッチ処理が可能

27. Run in Cloud と Run in On-prem ( Move Back )
1. Run in Cloudを実行 (VMware から GCP へ )
2. GCP上で動作を確認 (ブラウザでnginxのWelcome画面の確認）
3. GCP上でnginxの内容を修正、変更を確認
4. Run On-premissを実行（GCPからVMwareへ）
5. 変更が反映されていることを確認(画面、アクセスログ)

28. 5minでは終わらないので動画です。（実際には 15分位の作業です）

29. Run in Cloud と Run in On-prem ( Move Back )
Use Case #1:
万が一の保険として利用（数日実際に動かしてみる）
① Test in Cloud → 完全に分離しているため安全に試験
② Run in Cloud → 万が一の保険として利用
OK : 裏側でStorage Migrationを開始しそのまま利用開始
NG : Move Backで切り戻して原因を特定
Use Case #2:（さらに念入りに！？）
Case #1 を開発環境で実施
① Run in Cloud → オンプレ開発環境を移行して試験実施
② Run in Cloud → オンプレ本番を移行

30. Wave を利用した AWS からの移行
1. EC2の起動を確認
2. WAVEの定義ファイル作成
3. WAVEの定義ファイルの読み込み
4. WAVEを利用して Run in Cloud を実行

31. EC2の場合には、1台毎にVelostra Importerのサーバが起動する

32. 4まとめ

33. Migration First
環境さえあれば「まず移行してみる」という手段を選択できる。
👍 従来の移行ツールに比べて全体での業務停止時間が少ない
👍 リスクの少ない移行が計画できる
👍 クラウドネイティブな事は移行してから考える（力をかけるシステムはき
ちんと考える、塩漬けシステムはざっくり移行する）

34. 備考
本資料は、「Google Cloud で実践するクラウドマイグレーション GCP への移行
のポイントや先進事例について学ぶ 2019 年 9 月 4 日（水） 15:00–19:30」で発
表した資料となります。

35. Backup Desktop images

36. 1. Run in Cloudを実行 (VMware から GCP へ )
2. GCP上で動作を確認 (ブラウザでnginxのWelcome画面の確認）
3. GCP上でnginxの内容を修正、変更を確認
4. Run On-premissを実行（GCPからVMwareへ）
5. 変更が反映されていることを確認(画面、アクセスログ)

46. https://www.youtube.com/watch?v=WD454APAPV8&t=2559s