M-port にログインして、ワンタイムパスワードの設 …...1 はじめに 学外から利用される際には、必ずワンタイムパスワードの設定が必要です。
Google Cloud で実践するクラウドマイグレーション LIFT SHIFT … ·...
34
Google Cloud で実践するクラウドマイグレーション LIFT＆SHIFT（V2V、V2K）を成功させるた め䛾ヒント 日本情報通信株式会社
Transcript of Google Cloud で実践するクラウドマイグレーション LIFT SHIFT … ·...
Google Cloud で実践するクラウドマイグレーション
LIFT＆SHIFT（V2V、V2K）を成功させるため ヒント
日本情報通信株式会社
日本情報通信株式会社
IBM 先端テクノロジを使用して、 NI + C システム開発、製品とサービス、ネットワークサービスなど さまざまな分野 お客様に管理関連ソリューションを提供します。 IBM ハードウェアとソフトウェア フルラインナップだけでなく、市場に出回っている幅広いIBM 以外 ミドルウェアも提供しています。当社 技術スペシャリスト 、お客様 ニーズに応じてシステムを設計、構築、および保守することができます。
創業32年目 日本IBM + NTT
Software/Cloud 売上高
グループ全体エンジニア数>1000
400+
30+
常田 秀明 日本情報通信株式会社クラウドテクニカルエバンジェリスト
Facebook: hideaki.tokidaTwitter : @tokida
今年 テーマ 既存アプリ モダナイゼーション（理想 あれど実装 泥臭い世界、データをどうするかがとても難しい）好きなサービス 、PaaS全般。ノンコーディングツールも好き。
概要
オンプレミス ワークロードをクラウドに簡単に移行するためにGCPでV2VそしてV2Kをサポートしています。 これからGCPへ 移行を検討して
いる企業さま向けに弊社で 移行事例を基にマイグレーションを行うため
に必要となる環境面 準備、移行計画を立案する際に利用したほうが良
い機能など 知見を共有します。
1Migrate for Compute Engine (旧 Velostrata)を選択する理由
GCP に移行してみました
社内システムとして利用している、静脈認証システ
ムを GCP 環境へ移行してみました。
1. オーナー 総務部
2. システム NI+C が外販している NI+C Cloud X (VMWare ベース)を利用中
3. ネットワーク設備 情報システム部門管轄 運用子
会社に委託
4. 運用や故障 情報システム部門に委託
5. 関連機器 保守 メーカと直接やり取り
クラウドチーム(GCP 移行担当）
総務部（オーナ部門）
情報システム部門
NI+C Cloud x
SIer
LOB
IT
既存ベンダ
静脈認証システムってどんな仕組み？
● 某社製アプリ（サーバ・クライアント型)（製品に付随するサーバソフトウェア）
● 負荷が高い 朝 10 時前後(大きな
変動 ない）
● システム連携がされており勤怠管理など
と連携している
静脈認証システムってどんな仕組み？
● 既製品 ためアプリケーション
再構築できない
● 性能について 現行通り（夜間で
も利用 可能性あり）、性能面
考慮 ネットワークレイテンシ（と
トラフィック量）
● 他システムと 通信接続必要 モノリスアプリ（従来）オンプレミスリソース
モノリスアプリ（従来）クラウドリソース
モダンアプリ（マイクロサービス等）
オンプレミスリソース
モダンアプリ（マイクロサービス等）
クラウドリソース
V2V V2K
移行先 比較（VMware or VM)サービス名称 コメント 品質 コスト 構築
A 社 ベアメタルサーバ上に VMware 環境を構築し利用可能。現行 VMWare ベースであるが基盤運用までを
行っているわけで ない。したがって移行作業 、 VM イメージ移動できるが運用コストが増えることになる。
そ ため費用面で 全システム移行を前提に考える必要がある。
○ x ○
B 社 VMware ベース 環境であり移行 容易。通信環境的にも既設 ネットワーク設備 オプションサービスで
利用可能。ただしトータルコストが割高
○ x ◎
仮想サーバベースであるが移行ツールが今回 要件に適合。仮想サーバ、ネットワーク環境として 安定し
て動作している実績がある。今回 安価に利用可能。周辺 SaaS が充実しており今後 システム拡張が検
討できる。
○ ◎ ◎
自社既存 ESXi(オンプレ ) ハードウェア 増強費用と構築費用と構築が開始可能になるまで 期間がかかる。また機器購入 ために
5 年 計画が必要になる。場合によって 移行 際に関連ソフトウェア バージョンアップが必要
△ x ◎
VM 再構築し各社 クラウド上に
実装
再導入および試験に 期間も時間もかかる。そ ため今回 VM イメージを活用して移行できる方式を検
討したい。またすでに初期構築時 手順などがなく再度確認が必要となる。
△ x x
VMWare
GKE-Onpre Anthos
GCP
Anthos 概要モダナイズ 実現
GKE
c1 c2 c3 c4
VMWare/AWS/Azure
VM2 VM1
VM1
VM2
Migration for Anthos
Migration for Compute Engine
オンプレミス(他社クラウド） Google Cloud Platform
Stackdriver
GKE On-Prem
Kubernetes Engine
Compute Engine
Monitoring
Logging Error Reporti
ng
Trace
Anthos Configuration ManagerIstio
Migrate for Compute Engine 良い機能
1. 事前にテストモードで起動ができる
2. ストリーミングでデータが転送（Run in Cloud ＆ Storage Migration)
移行計画(実績）
主に移行後 コスト、移行に関する作業費用 見積もり（移行プロジェクト
予算化）
技術的な要求事項 確認
移行先環境 検討
各関連部門と 進行調整
各関連部門へ 依頼事項 発行
ネットワーク環境 構成・移行後 GCP 環境 構成
移行元 ESXi 環境へ 変更点整理
移行検証環境 構築（導入手順 確認、Migrate for Compute Engine 機能検証）
移行後 試験項目 確認
移行計画 立案
移行元代替 ESXi サーバへ 構成・アプライアンス導入 (*1)
移行元 ESXi サーバから VM イメージ 取得 (*1)
ESXi サーバと GCP 環境 VPN 環境 確立
動作試験（静脈認証 登録端末（オンプレミス上）と GCE）上 動作確認）
移行（ストリーミング転送）(*3)
立案（1Week）
プロジェクト発足（3week）
設計 (2week)
構築 (2week)
移行 (1day)
実際 準備1日、実施1日
Migration for Compute Engine 構成日本情報通信
オフィス
オフィスA(聖路加)
オフィスB(ニチレイ)
認証
登録
認証
登録
NI+
C既存回線
新規回線
ESXi asia-northeast1
asia-northeast1-basia-northeast1-a
ミラーリング(冗長化)
移行先VMGCE front manager
Virtual Private Cloud
Cloud Storage
Cloud ExtensionCloud Extension
移行先環境
Inte
rnet
Cloud VPN
NI+C YDC
vCenterPSCESXi host暫定VM
DNS/JUMPIMM
Cloud Armor
StackdriverCloudIAM
Router
PFsence
back manager
端末管理
：n
移行元VM
NI+C Cloud X 移行基盤 - 移行検証環境
VM移行時に利用
入退室管理システムへ
通信時に利用
Cloud NAT
2Getting Start でつまずくポイント
じめてみるためにチョットだけ気をつけること
1. 既存 環境や管理面で 影響
2. 移行後 コストから 予算化
3. ライセンス
4. 移行前 通信環境 確立
5. 環境で気をつけること
6. Migrate for Compute Engine 機能を活用
7. 複数ディスクもOK8. モニターで進捗を確認
1. 根回し・既存環境へ 影響
● 仮想基盤(ESX vCenter)へ構成変更が発生
● 新環境(GCP) 接続環境 用意（既存機能
へ 影響）
● 性能 影響
● 非機能 機能が変更
クラウドチーム(GCP 移行担当）
総務部（オーナ部門）
情報システム部門(運用・管理・NW）
NI+C Cloud x（インフラ提供）
SIer
LOB
IT
既存ベンダ
?
既存 根回し
1. 根回し・既存環境へ 影響
前提条件である ESX vCenter 機能追加が可能であるか確認し調整しよう。
● vCenter に対して 高権限 ユーザが必要
● 利用可能な ESX vCenter が存在しない場合に 別途構成を検討
● 一時的に VM を移行用 ESX 基盤に移動するなども必要に応じて検討して
いく必要がある（Snapshot 分 空き容量等）
● Migrate for Compute Engine（旧 Velostrata） Flash 版 vCenter から
操作がメイン
● VM上にもいくつかドライバ等が必要
2. 移行後 コストから 予算化
VM サイズ変更だけでなくネットワー
ク環境含めて全体で考える必要があ
る。
● 移行前に価格をリコメンドする仕
組みがある
● 3rd Party製品を利用することで詳
細確認する事ができる ず!?(例: Cloud Physics等)
● https://www.youtube.com/watch?v=HUHBq_VGgFg
3. ライセンス（BYOL）
持ち込みライセンスについて 理解をす
る
● 基本 GCE で提供するライセンスに移
行。単独テナントノード(β)を利用する場合
に BYOL がサポートされる（wave 機
能で移行する場合に選択可能）
● GCE でサポートされない OS ライセンス
について ... 要確認
Migration Mode
Migrate for Compute EngineSupport 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
4. 移行前 通信環境 確立
Migrate for Compute Engine (旧 Velostrata）において も大切な前提条件
ネットワークが正しく VPN を経由して疎通していること。
● VPN が利用出来なくても手順が 後 方まで進むが Cloud Extension 関連
を実行したい際にエラーになる。
● 移行後 VPN 必須で ない。
● ネットワーク帯域/ストレージ 余裕があるとよい
● 台数が増えることで帯域がど ようになるか
5. 環境で気をつけること
1. ID周り 全面的に変更されます
2. HAシステムなど 場合に 移行後 構成を検討しておく
3. Cloud Extension 自動で停止するがSSD分がある で課金が発生
する で不要であれ 削除しておく
4. DNSを利用している場合で 名前解決手段（AD利用してる場合など
も考慮が必要）
5. 移行後に非機能（Stackdriverやバックアップ） クラウド化しておく
6. Migrate for Compute Engine 機能を活用
Migrate for Compute Engine ストリーミング・切り戻し 動作などを実際に動作
してみて計画を立案しよう。
● 実際 移行に 複数台を設定可能な Runbook が利用できます。
● 事前に Migrate for Compute Engine (旧 Velostrata）らしい動きを再度手動
で確認して問題が発生した際 切り戻しなど 動きを確認して起きます
7. 複数ディスクもOK
● ストレージが複数ある場合でもStorage Migration可能
8. モニターで進捗を確認
● vCenter側と、Stackdriverで動作状況
を確認可能
● 移行 進行パーセントやWrite Commit待ちサイズ vCenterからしか見えない
が全体 メトリック値 StackDriveに流
れている でそちらからモニタリング、
アラート発砲する が良さげ
3動いているMigrate for Compute Engine デモ
Migrate Demo (8min)
1. Run in Cloud と Run in On-prem ( Move Back )
不具合が起こった時でも移行を切り戻す事が可能
2. Wave を利用した AWS から 移行
「WAVE」を利用すると一括でバッチ処理が可能
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. 変更が反映されていることを確認(画面、アクセスログ)
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 → オンプレ本番を移行
Wave を利用した AWS から 移行
1. EC2 起動を確認
2. WAVE 定義ファイル作成
3. WAVE 定義ファイル 読み込み
4. WAVEを利用して Run in Cloud を実行
4まとめ
Migration First
環境さえあれ 「まず移行してみる」という手段を選択できる。
👍 従来 移行ツールに比べて全体で 業務停止時間が少ない
👍 リスク 少ない移行が計画できる
👍 クラウドネイティブな事 移行してから考える（力をかけるシステム き
ちんと考える、塩漬けシステム ざっくり移行する）
備考
本資料 、「Google Cloud で実践するクラウドマイグレーション GCP へ 移行
ポイントや先進事例について学ぶ 2019 年 9 月 4 日（水） 15:00–19:30」で発
表した資料となります。
