Microsoft MVP が語る Azure 移行の勘所

Copyright © PERSOL PROCESS & TECHNOLOGY CO., LTD. All Rights Reserved.
Microsoft Azure 移行セミナー in 名古屋
Microsoft MVPが語る
Azure 移行の勘所
2018年11月16日
パーソルプロセス＆テクノロジー株式会社
小田島哲也

会社概要
【社名】パーソルプロセス＆テクノロジー株式会社
【株主】パーソルホールディングス株式会社
【社員数】3,145名（2018年3月1日時点）
【事業内容】業務プロセスコンサルティング、システム企画・開発、システム運用・保守、
パッケージソフト導入及び保守運用、インフラ設計構築、クラウドサービス、
ICTアウトソーシング、エネルギーアウトソーシング、セールスアウトソーシング、
WEBアナリティクスサービス、バックオフィス支援、カスタマーサポート支援
【代表者名】代表取締役社長横道浩一
【設立】1977年9月（昭和52年9月24日）
【事業拠点】豊洲本社、大阪、名古屋、札幌、仙台、福岡、沖縄
【連携事業】パーソルプロセス＆テクノロジーベトナム
【本社所在地】〒135-0061 東京都江東区豊洲3-2-20 豊洲フロント７階
【 Web 】http://www.persol-pt.co.jp/
2

スピーカー紹介
パーソルプロセス＆テクノロジー株式会社
システムソリューション事業部
テクノロジーソリューション統括部
デジタルトランスフォーメーション部
小田島哲也（おだしまてつや）
■現在の社内での役割
・Azure 導入/技術コンサル
・Office 365 導入/技術支援
・ソリューション開発
他
3
■略歴
• Microsoft 系のテクノロジーをメインにした
アプリケーション開発案件に長年従事
• 2011年より Azure 関連の業務に従事
• 2016年、MCSA Office 365 取得
• 2018年、Microsoft MVP for Azure 受賞

本日のアジェンダ
1. クラウドに移行する際の心得
2. Azure 移行 (設計) のポイント
– 仮想マシン
– ディスクストレージ
– ネットワーク
– メンテナンス
※セキュリティ、監視、バックアップ、DR については今回は割愛...
3. まとめ
4

注意事項
• このセッションは、
2018 年 11 月時点の情報に
基づいています
• 紹介するサービスや技術の導入
タイミングは、リージョンに
よって異なります
– リージョン別の Azure 製品
https://azure.microsoft.com/ja-
jp/global-infrastructure/services/
5

クラウドに移行する際の心得

Copyright © PERSOL PROCESS & TECHNOLOGY CO., LTD. All Rights Reserved. 7
クラウドに載せるなら、これからの運用は今より”ラク”に
そのためには、自分たちもたくさん知る、考える、そして議論する

クラウドを味方にしましょう
そのためには、自分たちもたくさん知る、考える、そして議論する

それ、本当に IaaS が必要なの？
9
クラウドで
システムを
作りたい！
それ、
SaaS で
実現できない？
それ、
PaaS で
作れない？
Yes Yes
No No
SaaS で Go!!
(Office 365
など)
PaaS で Go!!
(Web Apps や
Functions など)
どうしても
必要な時だけ
IaaS で Go!!
SaaS / PaaS は Microsoft のベストプラクティスのかたまり
SaaS > PaaS > IaaS の順で実現できるか検討

クラウドのサービス提供形態
10
ユーザーが管理マイクロソフトが管理
Virtual Machine
Virtual Network
App Service
SQL Database
Office 365
Dynamics 365
Microsoft Azure
ユーザーが管理するレイヤー
＝システムを載せても引き続き運用すべき部分
クラウドベンダーが管理するレイヤー
＝システムを載せたら運用しなくて良い部分

クラウドのサービス提供形態
11
ユーザーが管理マイクロソフトが管理
Virtual Machine
Virtual Network
App Service
SQL Database
Office 365
Dynamics 365
Microsoft Azure

クラウド移行を考える時の鉄則
12
要件
今までの
やり方
本当の要件は何なのか？というところに立ち返り、
クラウドならではのやり方で実現しましょう

IaaS/PaaS/SaaS のメリット・デメリット
製品例メリットデメリット
IaaS
仮想マシン
仮想ネットワーク
• 今までとほぼ変わらない運用
(ほぼ慣れ親しんだ取り扱い)
• クラウドの制約は受けにくい
• クラウド化するメリットが薄い
• 今までとほぼ変わらない運用
(セキュリティ対策や更新プログ
ラムの適用)
PaaS
App Service
SQL Database
• 環境構築作業の軽減
• インフラ部分の管理が不要
(ユーザーが設定できる部分有)
• 柔軟な性能や可用性
(ユーザーが設定できる部分有)
• 環境を自由に選択できない
• サービス仕様に依存
(他のクラウドサービスに移行し
づらい)
SaaS
Office 365
Dynamics 365
• 提供サービスが簡単にすぐ使える
• インフラ部分の管理が不要
(すべてベンダーにおまかせ)
• 柔軟な性能や可用性
(すべてベンダーにおまかせ)
• サービス障害が発生しても為す術
がない
• マルチテナントサービスゆえの
制約や弊害
13

(例) Web サイトをオートスケールできる環境を構築したい
14
動的 IP アドレス 328.50 円
VMSS F2 (CPU:2core/RAM:4GiB) 17,823.68 円
Managed Disks S10 (128GiB) 659.46 円
利用料金(月) 18,811.64 円～
App Service Standard S2
(CPU:2core/RAM:3.5GB/Storage:50GB)
19,295.36 円
利用料金(月) 19,295.36 円～
※1ヶ月＝730時間で算出
※1インスタンス分の料金を算出
管理すべき
リソース数
これからの運用保守に
見合うコスト
デプロイ→
システムのデリバリ
の手間
IaaS:仮想マシンスケールセット PaaS:Web Apps (App Service)

IaaS/PaaS/SaaS を採用する理由 (例)
15
製品例採用する理由 (例)
IaaS
仮想マシン
• ある特定の OS またはバージョンを採用したい
• 特殊なソフトウェア (ミドルウェアやエージェント) が必要
• 細かな設定 (OS やネットワークまわり) が必要
• サービスを閉域網で利用したい
PaaS
App Service
SQL Database
• OS またはバージョンに依存しない
• 自動復旧 (気にならないレベル)
• 柔軟なスケーリングが必要
• サービスを早く広く展開したい
• 運用するための人的コストを抑えたい
SaaS
Office 365
Dynamics 365
• 実現するための最適なサービスを発見
• 簡単に導入できる (したい)
• 運用するための人的コストをより抑えたい

既存サービスを PaaS / SaaS に移行するためには
その PaaS/SaaS
サービスのことを
知る
既存サービスの
システム要件の
見直し (断捨離)
クラウドのプラット
フォームに合わせた
システム設計
16
今までの「システム要件に合わせたインフラ設計」ではなく…

(例) SQL Database を使いたい
既存のポリシー
• DB は閉域ネットワーク内に配置する
• DB はパブリック IP アドレスを持たせない
SQL Database の仕様
• パブリックサービスのため、必ずパブリック
IP アドレスを保持する
新ポリシー案
• SQL DB の機能「ファイアウォール」
または「仮想ネットワーク規則」を
用いて、対象ネットワークからの
アクセスのみを許可する
• SQL DB の機能「脅威検出」および
「監査」を有効にし、脅威が検出
された場合の手順を決める
17

Azure 移行 (設計) のポイント
• 仮想マシン
• ディスクストレージ
• ネットワーク
• メンテナンス

仮想マシン

仮想マシンシリーズ
汎用
コンピューティング
の最適化
メモリの最適化
ストレージの
最適化
GPU
ハイ
パフォーマンス
コンピューティング
B Fsv2 Esv3 Ls NV H
Dsv3 Fs Ev3 NVv2 HB
Dv3 F M NC HC
DSv2
(DS1 - DS5 v2)
GS NCv2
Dv2
(D1 - D5 v2)
G NCv3
Av2 DSv2
(DS11 - DS15 v2)
ND
DC Dv2
(D11 - D15 v2)
NDv2
20
https://docs.microsoft.com/ja-jp/azure/virtual-machines/windows/sizes
※2018/11 現在

仮想マシンを選定するために役立ちそうなツール
• Microsoft Assessment and Planning Toolkit (MAP ツール)
• Azure Migrate
• Azure 料金計算ツール
• Azure 総保有コスト (TCO) 計算ツール
21

Microsoft Assessment and Planning Toolkit (MAP ツール)
22
サーバー情報自動収集
インベントリ情報
パフォーマンス情報
移行に有用なアセスメントレポートをご提示
移行対象サーバー台数 / ワークロードの明確化
移行先のサイジング・コストシミュレーション
To Be 案のご提示・移行基本方針の策定
移行アセスメントサービス実施のメリット
具体的な移行ロードマップの作成が可能に
移行ターゲットの正確な把握
移行後の To Be 像の具現化 https://www.microsoft.com/en-us/download/details.aspx?id=7826
https://wp.techtarget.itmedia.co.jp/contents/26480
http://www.atmarkit.co.jp/ait/articles/1803/26/news007.html

Azure Migrate
23
https://docs.microsoft.com/ja-jp/azure/migrate/migrate-overview
VMware vSphere Hypervisor 上に作成された
VM 情報を取得、評価
※Hyper-V も今後対応予定
• ESXi 上の仮想マシンの構成、OS 情報取得
• 各仮想マシンの使用状況の取得
• 基本的に仮想マシンにエージェントのインストールは不要
※仮想マシン間の依存関係などを把握するためには、
別途エージェントのインストールが必要
• Azure VM での推奨サイズを提示
• Azure VM に必要な Storage 数、必要容量を提示
• オンプレミスから Azure への移行方法を提示
• Azure 利用時の想定コストを算出

MAP ツール、Azure Migrate のご利用にあたって
• 対象サーバーの構成情報とパフォーマンス情報を収集することで、
棚卸が可能
※出力結果に若干差異がある
• 情報の収集は機械的な処理となるため、以下の詳細なチェックは
ユーザーにて実施していただく
– 業界や企業内などのルールでクラウド上に載せられないデータを保持するシステム
– クラウド上での動作が提供ベンダーでサポートされていない
アプリケーションやミドルウェアが必要なシステム
– クラウド上での動作がライセンス違反であったり、契約／価格変更の必要がある
アプリケーションやミドルウェアが必要なシステム
24

Azure 料金計算ツール
25
https://azure.microsoft.com/ja-jp/pricing/calculator/

Azure 総保有コスト (TCO) 計算ツール
26
https://azure.microsoft.com/ja-jp/pricing/tco/

サービス提供を止めないための対策
単一インスタンス
保護されない
可用性セット
Availability Set
データセンター内の
障害やメンテナンス
から保護
• ハードウェア障害
• メンテナンス
可用性ゾーン
Availability Zones
データセンター全体
の障害から保護
• 電力/冷却/ネット
ワーク装置障害
• 火災、水害
リージョンペア
Region Pair
リージョン全体の
障害から保護
• 大規模な災害
27
VM SLA 99.9 %
※Premium Storage 使用
に限る
VM SLA 99.95 % VM SLA 99.99 %
• マルチリージョン化
• Azure Site Recovery
• Storage GRS/RA-GRS
冗長 (Unmanaged Disk)
• Azure Backup
https://docs.microsoft.com/ja-jp/azure/virtual-machines/windows/regions-and-availability#availability-sets
https://docs.microsoft.com/ja-jp/azure/virtual-machines/windows/regions-and-availability#availability-zones
https://azure.microsoft.com/ja-jp/support/legal/sla/virtual-machines/v1_8/

可用性セットと可用性ゾーンの違い
双方を組み合わせて利用できない
※可用性ゾーンは、東日本および西日本ではまだ利用できない
28
Azure リージョン
AZ#1 AZ#2 AZ#3
単一インスタンス
可用性セット
Availability Set
可用性ゾーン
Availability Zones
可用性ゾーンに対応している
ディスクストレージは
「管理ディスク」だけ
• 障害ドメイン
電源/ネットワークなどを共有する
範囲
• 更新ドメイン
メンテナンスを同時に実行する範囲

(参考) PaaS サービスの可用性
• PaaS サービスは自動的に可用性セットを意識した構成となる
• 負荷に応じた自動スケールアウト／スケールインも可能
• 同じコードをリージョン上にアップロードして展開する
東・西日本リージョンの活用など、マルチリージョン化が簡単な
ケースが多い
• Traffic Manager を使って
複数のリージョンで負荷分散
29
西日本東日本

ディスクストレージ

ディスクストレージの種類
ARM
(Azure Resource Manager)
非管理対象ディスク
(Unmanaged Disk)
汎用v1
(GPv1)
Premium
SSD
Standard
HDD
汎用v2
(GPv2)
Premium
SSD
Standard
HDD
管理ディスク
(Managed Disk)
Ultra
SSD
Premium
SSD
Standard
SSD
Standard
HDD
31

ディスクストレージ
(Unmanaged Disk)
• Azure Storage に VHD を保存
• ストレージアカウントの制約を受ける
• 管理の煩雑さ
• 20,000 IOPS (HDD)/50 Gbps (SSD)
• 単一障害点となる可能性有
• REST でアクセス可
• 選べる冗長オプション
(LRS/GRS/RA-GRS)
管理ディスク
(Managed Disk)
• Azure がストレージを管理
• ストレージアカウントの制約から脱却
• ストレージアカウントの IOPS 上限
からの解放
• 可用性セットの信頼性の向上
• セキュリティの向上
• ローカル冗長 (LRS) のみ
32
https://docs.microsoft.com/ja-jp/azure/virtual-machines/windows/about-disks-and-vhds

ストレージの可用性
33
(Unmanaged Disk)
管理ディスク
(Managed Disk)
ストレージ
アカウント2
ストレージ
アカウント1
ストレージ
アカウント0
ストレージユニット0 ストレージ
ユニット0
ストレージ
ユニット1
ストレージ
ユニット2
ストレージユニットが単一障害点になりえる障害ドメインに応じたストレージユニットの独立
FD0 FD1 FD2 FD0 FD1 FD2

管理ディスクの種類
Standard
HDD
低コスト
ストレージ
最大サイズ
32 TiB
最大 IOPS
2,000 以下
最大帯域幅
500 Mbps 以下
Standard
SSD
安定した
パフォーマンス
最大サイズ
32 TiB
最大 IOPS
2,000 以下
最大帯域幅
500 Mbps 以下
Premium
SSD
ハイパフォーマンス
最大サイズ
32 TiB
最大 IOPS
20,000
最大帯域幅
750 Mbps
Ultra
SSD
ミリ秒以下の
超低レイテンシ
最大サイズ
64 TiB
最大 IOPS
160,000
最大帯域幅
2,000 Mbps
34

非管理対象ディスクのストレージアカウントの違い
汎用 v1 (GPv1) 汎用 v2 (GPv2)
パフォーマンスディスク用ストレージとしての差異はない
耐障害性ディスク用ストレージとしての差異はない
課
金
体
系
Premium 費用の差異はない
Standard ディスク容量高
(例)東日本(LRS):5.60円/GB
安
(例)東日本(LRS):5.04円/GB
ディスク操作安
(例)東日本(LRS):R/W 0.04032円
高
(例)東日本(LRS):R 0.17円/W 1.68円
データ転送
(GRS/RA-GRS)
安
(例)東日本:0円/GB
高
(例)東日本:10.08円/GB
その他 GPv1 から GPv2 への移行は可能
GPv2 から GPv1 への移行は不可
35
https://blogs.technet.microsoft.com/jpaztech/2018/06/11/choose_azure_disk/
https://azure.microsoft.com/ja-jp/pricing/details/storage/page-blobs/

非管理対象ディスクの種類
36
Standard
HDD
低コスト
ストレージ
最大サイズ
4 TiB
最大 IOPS
500 (*1)
最大帯域幅
60 Mbps (*1)
Premium
SSD
ハイパフォーマンス
最大サイズ
8 TiB
最大 IOPS
7,500 (*2)
最大帯域幅
250 Mbps (*2)
(*1)
• ストレージアカウントあたり
最大 20,000 IOPS
• VHD ファイルあたり 500 IOPS
もしくは 60 Mbps
(*2)
• ストレージアカウントあたり
最大 50 Gbps
• P60 ディスクあたり 7,500 IOPS
もしくは 250 Mbps

ディスクのパフォーマンスの注意点 – 1/2
ディスク性能がストレージの許容値より劣る場合がある
37
Dsv3 CPU / メモリ最大データ
ディスク数
最大ディスク
IOPS
最大ディスク
スループット
Standard_D2s_v3 2 / 8 4 3,200 48 Mbps
Premium SSD ディスク
サイズ
ディスク
あたりの
IOPS
ディスク
あたりの
スループット
P30 1 TiB 5,000 200 Mbps
P40 2 TiB 7,500 250 Mbps
P50 4 TiB 7,500 250 Mbps
P60 8 TiB 12,500 480 Mbps
VMの制限のほうが低いため
↓↓↓
IOPS：6,400
スループット：96 Mbps
VM は制限
ストレージは
許容範囲

ディスクのパフォーマンスの注意点 – 2/2
非管理対象ディスクでの
1 ストレージアカウントに格納できるディスク数
38
https://blogs.technet.microsoft.com/jpaztech/2016/03/15/azure-vm-storage-performance/
• Standard HDD
• ストレージアカウントあたり最大 20,000 IOPS
= 500 IOPS (VHD) × 40 本
• Premium SSD
• ストレージアカウントあたり最大 50 Gbps
＝ 250 Mbps (P40/P50/P60) × 25 本

ディスクを選ぶポイント
• 「管理ディスク (Managed Disk)」は今後も発展し続ける (であろう)
• 「SSD」を標準として選ぶ (選んで欲しい)
– HDD vs SSD ではなく、どの SSD を使うかと比較する
– 容量あたりの「コストを重視する」場合は、HDD を選択肢として挙げる
39

ネットワーク

仮想ネットワーク (VNet) と
ネットワークセキュリティグループ (NSG)
41
仮想ネットワーク (VNet)
サブネットサブネット
10.0.0.0/16
10.0.1.0/24 10.0.2.0/24
通信可
優先度名前ポートプロトコルソース宛先アクション
65000 AllowVnetInBound 任意任意 VirtualNetwork VirtualNetwork 許可
65001 AllowAzureLoadBalancerInBound 任意任意 AzureLoadBalancer 任意許可
65500 DenyAllInBound 任意任意任意任意拒否
65000 AllowVnetOutBound 任意任意 VirtualNetwork VirtualNetwork 許可
65001 AllowInternetOutBound 任意任意任意 Internet 許可
65500 DenyAllOutBound 任意任意任意任意拒否送信セキュリティ規則
受信セキュリティ規則
インターネット

NSG の適用順
NSG は、仮想マシンの NIC または VNet のサブネットに割り当てられる
42
受信トラフィック送信トラフィック
サブネット
の受信セ
キュリティ
規則
NIC の受信
セキュリ
ティ規則
サブネット
の受信セ
キュリティ
規則
NIC の受信
セキュリ
ティ規則
OK OK
NG NG
OK OK
NG NG

NSG サービスタグ
NSG サービスタグは、ソース / 宛先に指定できる
43
サービスタグ意味
VirtualNetwork VNet の同一サブネット、VNet の異なるサブネット
VNet Peering で接続された異なる VNet (※)
ExpressRoute 接続されたオンプレミスネットワーク
S2S 接続されたオンプレミスネットワーク、P2S 接続されたクライアントネットワーク
AzureLoadBalancer ロードバランサー (Application Gateway も含む) の正常性プローブ IP
Internet パブリック IP (Azure PaaS サービスも含む)
AzureCloud Azure IP アドレス (全データセンターのパブリック IP も含む)
AzureTrafficManager Traffic Manager のプローブ IP
Storage Azure Storage サービスの IP
Sql Azure SQL Database, Azure SQL Data Warehouse サービスの IP
AzureCosmosDB Azure Cosmos Database サービスの IP
AppService Azure AppService サービスの IP
AzureActiveDirectory Azure AD サービスの IP
※ピアリング時に「仮想ネットワークアクセスを許可する」を有効にした場合
https://docs.microsoft.com/ja-jp/azure/virtual-network/security-overview#service-tags

アプリケーションセキュリティグループ (ASG) – 1/2
• NSG の拡張機能
• 仮想マシンをグループ化し、それを NSG (ソース / 宛先) に
セットできる
1. アプリケーショングループを定義し、アーキテクチャに合った名前を付ける
アプリケーション、ワークロードタイプ、システム、階層、環境、任意の
ロールに使用可
2. ASG と NSG を使って単一の規則を定義する
1 つの NSG をすべてのサブネット上の VNet 全体に適用できる
1 つの NSG でトラフィックポリシーを完全に可視化し、一元管理できる
3. 自社のペースでスケーリングを行う
仮想マシンを適切な ASG メンバーにすることによって、
① メンバーに新たに仮想マシンを追加しても NSG 自体を変更しなくて良い
② ASG メンバー (仮想マシン) の IP アドレスを意識しなくて良い
44
https://docs.microsoft.com/ja-jp/azure/virtual-network/security-overview#application-security-groups

アプリケーションセキュリティグループ (ASG) – 2/2
45
仮想ネットワーク (VNet)
サブネットサブネット
10.0.0.0/16
10.0.1.0/24 10.0.2.0/24
DevSV-asg
1000 AllowRDPInBound 3389 TCP xxx.xxx.xxx.xxx DevSV-asg 許可
65000 AllowVnetInBound 任意任意 VirtualNetwork VirtualNetwork 許可
65001 AllowAzureLoadBalancerInBound 任意任意 AzureLoadBalancer 任意許可
65500 DenyAllInBound 任意任意任意任意拒否
65000 AllowVnetOutBound 任意任意 VirtualNetwork VirtualNetwork 許可
65001 AllowInternetOutBound 任意任意任意 Internet 許可
65500 DenyAllOutBound 任意任意任意任意拒否
①
②
③
④④
③
① ASG を作成
② NSG を定義
③ VNet のサブネットに
適用
④ ASG のメンバーに
VM を追加

NSG のベストプラクティス
• ゲートウェイサブネット (GatewaySubnet) には NSG を適用しないこと
• 既定の規則を変更するには上書き (規則を追加) で
• 規則では最初のソースと最終的な宛先を指定すること
• プロトコル「Any」は ICMP も含む
• 規則名にはその規則が識別しやすい名前を付けること
• サービスタグや ASG を用いて、規則の数を抑えること
• 規則の優先度は間隔をあけて設定すること
• 基本的に NSG は「サブネット」にセットする
– 特定の仮想マシンに対してトラフィック制御しないといけない時だけ、
NIC にセットする
46

VNet 内の名前解決と DNS サーバーの指定
• Azure で提供される名前解決
– 同じ VNet 内に配置された仮想マシン間の名前解決
• 独自の DNS サーバーを使用する名前解決
– 異なる VNet 内に配置された仮想マシン間の名前解決
• VNet 間接続と VNet Peering
– オンプレミスのコンピューターからの Azure のホスト名の名前解決
– 内部 IP アドレス用の逆引き DNS
• DNS サーバーの指定
– VNet ごとに指定
– 仮想マシンの NIC ごとに指定
– 複数の DNS サーバーも指定できる
– 基本的に VNet に指定する
47
https://docs.microsoft.com/ja-jp/azure/virtual-network/virtual-networks-name-resolution-for-vms-and-role-instances

ネットワーク帯域幅の最適化
• 仮想マシンのサイズと種類により異なる
• 送信トラフィックのみ
• すべての NIC の合計に基づく
48
https://docs.microsoft.com/ja-jp/azure/virtual-machines/windows/sizes-general
Standard_A1_v2
250 Mbps
Standard_D2_v3
1,000 Mbps
Standard_D64_v3
30,000 Mbps

VNet 間の接続
異なる VNet 間の仮想マシンがお互いにアクセス可能
49
VNetVNet
VPN
VNetVNet
Vnet
Peering
VNet 間接続 (VPN) VNet Peering
Microsoft
ネットワーク
Microsoft
ネットワーク
• 同一リージョン内の VNet を接続
• 異なるリージョン間の VNet を接続
• 簡単な設定
• 異なるリージョン、異なる Azure
AD テナントの VNet を接続
• 両方の VNet に VPN Gateway を
設置する必要がある

VNet 間の接続方法の比較
VNet 間接続 (VPN) VNet Peering
異なるリージョン対応対応
操作 (設定手順) 複雑簡単
課金形態 VPN Gateway が利用可能な時間
＋送信データ転送
送信および受信データ転送
スループット VPN Gateway のサイズに依存高い
※Microsoft のバックボーンを使用
レイテンシ中低
異なるサブスクリプション ○ ○
異なる Azure AD テナント ○ ×
接続数 30 (S2S トンネル) 100
50
https://docs.microsoft.com/ja-jp/azure/azure-subscription-service-limits#azure-resource-manager-virtual-networking-limits
https://docs.microsoft.com/ja-jp/azure/virtual-network/virtual-network-manage-peering#requirements-and-constraints

VPN 接続と VNet Peering 併用の注意点 – 1/2
51
VNetBVNetA
VNetC
オンプレミス
VNet Peering では VPN Gateway をリモートゲートウェイとして利用
することで、VPN 接続先のリソースにアクセスできる
VNet Peering
VPN 接続
https://docs.microsoft.com/ja-jp/azure/architecture/reference-architectures/hybrid-networking/hub-spoke

VPN 接続と VNet Peering 併用の注意点 – 2/2
VNet Peering ではリモートゲートウェイを 1 つしか持てない
よって、VNetB 側にも VPN Gateway があると、VNetA 側の
VPN Gateway が利用できない
52
VNetBVNetA
VNetC
オンプレミス
VNet Peering
VPN 接続
https://docs.microsoft.com/ja-jp/azure/architecture/reference-architectures/hybrid-networking/hub-spoke

サイト間接続
オンプレミスと VNet を VPN 接続
53
Azure リージョン
Gateway
Subnet
サブネットオンプレミス
VPN
デバイス VPN
Gatewayインターネット
VPN Gateway の
種類
サイト間接続マルチサイト
接続
ポイント対
サイト接続
VNet 間接続 Express
Route
との共存
SKU 帯域幅
※ベンチマーク
ルートベース ○ ○ ○ ○ ○
• Basic
• VpnGw1
• VpnGw2
• VpnGw3
• 100 Mbps
• 650 Mbps
• 1 Gbps
• 1.25 Gbps
ポリシーベース ○ × × × × • Basic • 100 Mbps
VPN

アクティブ・アクティブ構成
2 台の VPN Gateway をアクティブ・アクティブで運用
54
VPN
Gateway
VPN
デバイス
アクティブ
オンプレミス VNet
アクティブ
VPN
Gateway
VPN
デバイス
アクティブ
スタンバイ
VPN
Gateway
VPN
デバイス
アクティブ
アクティブ
アクティブ・スタンバイ
構成 (既定)
アクティブ・アクティブ
構成
アクティブ・アクティブ
構成 (デュアル冗長性)
https://docs.microsoft.com/ja-jp/azure/vpn-gateway/vpn-gateway-highlyavailable

ExpressRoute
55
https://docs.microsoft.com/ja-jp/azure/expressroute/expressroute-introduction
オンプレミスと Microsoft データセンターを閉域網で接続するサービス
※ExpressRoute 用の VPN Gateway はアクティブ・アクティブ構成

ExpressRoute の接続方法
56
WAN
オンプレミス
オンプレミス
接続ポイント
L3 接続サービス
Microsoft
ネットワーク
Microsoft
データセンター
ExpressRoute 接続サービス ExpressRoute 回線

ExpressRoute と VPN の共存
ExpressRoute と VPN は共存可能
57
ExpressRoute のバック
アップとして VPN を使用
ExpressRoute に接続されて
いないサイトを VNet に接続
https://docs.microsoft.com/ja-jp/azure/expressroute/expressroute-howto-coexist-resource-manager

ExpressRoute と VPN の共存での注意点
ExpressRoute と VPN の BGP は別物
ExpressRoute では VNet との接続時に適宜 AS がセットされるが、
VPN (S2S/P2S) の BGP 有効化ではプライベート AS となる
→つまり、互いに影響は受けない
Hub & Spoke モデルを組んだ時に、如実に違いを感じることができる
• ExpressRoute
– Spoke 間の通信はそのままで可能
• VPN
– Spoke 間の通信には UDR の設定が必要
58
HubVNet
Spoke1VNetSpoke2VNet
On-premise
VNet Peering VNet Peering
Hub & Spoke
構成

オンプレミスと VNet との接続
VPN 接続？ ExpressRoute 接続？
59
SLA が必要？
IaaS だけでなく
PaaS にも閉域
でアクセス
したい？
スループットが
2 Gbps 以上
必要？
レイテンシ
を極力
減らしたい？
の影響を
受けたくない？
ExpressRoute 接続
VPN 接続
Yes
No
Yes Yes Yes Yes
No No No
No

メンテナンス

仮想マシンのメンテナンス
影響なしで
メンテナンス
実施
インプレース
マイグレーション
•VM のメモリを保持
したままホスト OS を
更新
•VM は短時間 (約30秒
間)、一時停止
ライブ
マイグレーション
•VM を更新済みの
別ホストへ移行
•移行前後で性能が低下
する可能性有
•多くのVMシリーズで
サポート
•ユーザーが意図的に
実施することはできな
い
ユーザーによる
再デプロイ
•セルフメンテナンス
ウインドウを提供
61
実行できない場合ホストの再起動
が必要な場合
実行できない場合
https://docs.microsoft.com/ja-jp/azure/virtual-machines/windows/manage-availability
https://docs.microsoft.com/ja-jp/azure/virtual-machines/windows/maintenance-and-updates
https://docs.microsoft.com/ja-jp/azure/virtual-machines/windows/maintenance-notifications
メンテナンスに
よる VM 停止を
伴う場合

VPN Gateway のメンテナンス
自動切り替えにかかる時間
• 計画的なメンテナンスの場合、10 ～ 15 秒間
• 計画外の中断が発生した場合、60 ～ 90 秒間
62
https://docs.microsoft.com/ja-jp/azure/vpn-gateway/vpn-gateway-highlyavailable
VPN
Gateway
VPN
デバイス
アクティブ
スタンバイ
VPN
Gateway
VPN
デバイス
アクティブ
フェールオーバー

3.まとめ

「とりあえず IaaS で...」チョット待った！
これからも、今までと変わらずたいへんな思い (運用保守) しますか?
SaaS / PaaS は Microsoft のベストプラクティスのかたまり
「要件」≠「今までのやり方」

「クラウドにまかせる」
気持ちで
• クラウドの制約はあるけど、
受け入れる
• より大きな「メリット」が
受けられます!!
65

IaaS への移行は、仮想マシンだけではない！
• 仮想マシン / ディスクストレージ
– ディスク性能は、仮想マシンの制限を受ける場合がある、それを意識して選ぶ
– 管理ディスク & SSD がオススメ
– サービス提供を止めないための対策は、方針 (目標) を決めて、それ相応な形に
• 仮想ネットワーク
– ネットワーク帯域幅は、仮想マシンに性能目標があり、それ次第で決まる
– NSG の設定内容は複雑になりがち、いろいろ工夫してシンプルに
– ネットワーク設計もしっかりやりましょう
66

とにかくやってみよう！
「ラク」になった分、
クラウドスキルをアップ
しましょう！
– Azure は進化し続ける
– Azure を触り続けることが
大事
67

Appendix

参考文献
• クラウドアーキテクトへの道～基礎から学ぶサービス利用設計 –
Microsoft de:code 2018
https://youtu.be/MQBfmUVhy54
• なぜ、そのサービスを選ぶのか？ – クラウドにおけるアーキテクチャ
選択眼 – Microsoft de:code 2018
https://youtu.be/zGgtKUtPilw
• 百戦錬磨の Azure アーキテクトが語る、Azure Virtual Machines 設計
の勘所 – Microsoft Tech Summit 2017
https://youtu.be/5NAAvQVF3cw
• もう迷わない! Azure Virtual Network の使い方 – Microsoft Tech
Summit 2017
https://youtu.be/_eUrMqtnHhs
69

移行ステップの工程
70
(1)
棚卸
• ソフトウェア
や利用用途
などを確認
(2)
精査
• アプリと利用
用途を分類
(3)
ターゲット
• 移行先を選定
(4)
実行
• いざ！
クラウドへ
(5)
最適化
• 運用の最適解
を求める

棚卸した結果をこんなふうに分類して精査
タイプ別
Windows Server
の役割
Microsoft サーバー製品
カスタム
アプリケーション
パッケージ
ソフトウェア
重要度別
ミッションクリティカル
なもの
優先順位の高いもの
最低限必要なもの
リタイア可能なもの
難易度とリスク別
高
中
低
71

Microsoft MVP が語る Azure 移行の勘所

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a Microsoft MVP が語る Azure 移行の勘所

Semelhante a Microsoft MVP が語る Azure 移行の勘所 (20)

Mais de Tetsuya Odashima

Mais de Tetsuya Odashima (6)

Último

Último (11)

Microsoft MVP が語る Azure 移行の勘所