廣瀬 一海（デプロイ王子）日本マイクロソフト株式会社Azure テクノロジースペシャリスト

愛称「デプロイ王子」/ 元 Microsoft

MVP (Azure) でした。

現在は、Microsoft Azureに関する様々

な技術支援を行っています。

お客様とAzureの使い方について設計や

検証を一緒に行う活動の傍ら、コミュニティ

やセミナーの登壇、Webメディアへの記事

執筆活動なども行っています。

可用性

性能・拡張性

運用・保守

性移行性

セキュリティ

システム環

境・エコロジー

何のため

どうやって

誰が運用

どのような

復旧目標 復旧時点

どこで

ビジネスオーナ/社内サービスチーム

災害対策ではありません

可用性

継続性

耐障害

性回復性

Copyright © 2010 IPAIPA 非機能要求の見える化と確認の手段を実現する「非機能要求グレード」の公開http://www.ipa.go.jp/sec/softwareengineering/reports/20100416.html

Copyright © 2010 IPAIPA 非機能要求の見える化と確認の手段を実現する「非機能要求グレード」の公開http://www.ipa.go.jp/sec/softwareengineering/reports/20100416.html

Copyright © 2010 IPAIPA 非機能要求の見える化と確認の手段を実現する「非機能要求グレード」の公開http://www.ipa.go.jp/sec/softwareengineering/reports/20100416.html

Copyright © 2010 IPAIPA 非機能要求の見える化と確認の手段を実現する「非機能要求グレード」の公開http://www.ipa.go.jp/sec/softwareengineering/reports/20100416.html

回復性

アーカイブ 災害復旧 (DR) 高可用性 (HA)

RPO/RTO

RTO >> 0 RTO > 0 RTO = 0

コスト/複雑さ

Best For:

データの削除データの破損コンプライアンス

計画外障害の保護HAのために再設計できないHAのコストの問題大規模障害

ミッション クリティカルなアプリローカル障害

#decode17 #DI13

#decode17 #DI13

#decode17 #DI13

#decode17 #DI13

可用性Error Budget

(年間)

Error Budget

(月間)

99% 3.65 日 7.2 時間

99.9% 8.76 時間 43.2 分

99.95% 4.38 時間 21.6 分

99.99% 52.56 分 4.32 分

99.999% 5.26 分 25.9 秒

#decode17 #DO05

可用性Error Budget

(年間)

Error Budget

(月間)例

< 99% 3.65 日 7.2 時間バックアップ & 迅速・確実なリカバリ(Infrastructure as Code)

99.9% 8.76 時間 43.2 分シングルリージョンHA

99.95% 4.38 時間 21.6 分

99.99% 52.56 分 4.32 分 マルチリージョン (Act/Stb)

99.999% 5.26 分 25.9 秒 マルチリージョン (Act/Act)

#decode17 #DO05

Cache

フォールバック:

ローカル キャッシュからデータを返す

99.95% × 99.99% = 99.94%

2 リージョンの複合 SLA = (1 − (1 − N) (1 − N)) x Traffic Manager SLA

(100% – (0.05% ×0.05%) x 99.99% = 99.9899%

https://docs.microsoft.com/azure/architecture/resiliency/

100% - (0.001% × 0.1%) = 99.99999%

99.95% × 99.99999% = 99.95%

#decode17 #DI13

#decode17 #DO05

SQL Server Always on / Apache Cassandra / Couchbase etc (XDCR) / MySQL Galera Cluster

MySQL Master – Slave etc

DRDB / Cluster pro X / SIOS LifeKeeper

Soon Soon New New

• シリーズごとに1コアあたりの性能は異なる。

• ACU (Azure Computing Unit) をチェックする。

➢ Standard A1を100としたときの相対的な性能。

• 常に同時に３つのディスクへデータが書き込まれる。

• 最大で同時に２つのディスクが壊れても、データ損失なく稼働する。

VHD ファイル

• ジオ冗長ストレージ(GRS)を使うと、データが自動的に別データセンターにも非同期で複製される。

• 複製元での３重化＋複製先での３重化＝合計６重化。

> 500 miles

東日本 西日本

Blob ストレージBlob ストレージ

• GRS はストレージをペアリージョンに非同期で複製する。

• GRS の複製時にはOS 内での整合性は考慮されない。

• 複数のディスクがある場合、各ディスクが異なるタイミングで複製されうる。➢ 記憶域スペースや LVM を使っている場合、不整合が生じうる。

• GRS のフェールオーバーはマイクロソフトの判断により実行される。➢ 利用者任意のタイミングでのフェールオーバーはできない。

災害時の業務継続が目的であれば、別の手段も検討する。

• 所有しているリソースに影響を及ぼしうる Azure 上の問題について、情報や解決策を提供する。➢ 自分の所有しているリソースに影響のない問題は表示されない。

➢ Azure ポータル上のアイコンから参照できる。

• Azure 仮想マシンでは原則としてディスク共有型のクラスタを構成できない。➢ とくにファイルサーバーやDBサーバーにおいて要注意

• RDMBS の機能や3rd パーティのソリューションを利用した、ディスクを共有しない冗長化構成を考える。

〇 Azureではこちらを利用する× Azureでは原則として利用できない

• Windows Server 2016 の機能である S2D (Storage Space Direct : 記憶域スペースダイレクト)を使い、Azure 仮想マシンでSQL Server AlwaysOn フェールオーバークラスターを構成できる。

• ただし S2D を使えばあらゆるワークロードでディスク共有型クラスタが構成できるわけではない。利用しているワークロードが共有ディスクとして S2D の構成をサポートしているか確認が必要。

• Azure 仮想マシンを複数台構成にするときは、可用性セットを定義する。

• これにより、１つのラックの障害で２台の仮想マシンが同時に停止することを回避できる。

• 可用性セット自体にクラスタリング・負荷分散・データ複製などの機能があるわけではないので注意すること。

障害ドメイン 障害ドメイン障害ドメイン

ラック

FC

・・・

・・・

ルータ

ラック

FC

・・・

・・・

ルータ

ラック

FC

・・・

・・・

ルータ

可用性セット

“AS1”

• 障害ドメイン (FD)➢ 同時に物理障害が起こりう

る単位 ≒ ラック

• 更新ドメイン (UD)➢ 同時にメンテナンスを行う

単位

• 2017年2月にGAした仮想マシンの新しいディスク形式。

• いろいろなメリットがあるが、➢ ストレージアカウントの作成・管理が不要に

➢ スナップショット、仮想マシンイメージの容易な作成

➢ Blobとしてのエンドポイントが無い

• 実は Managed Disk では可用性も向上している！➢ 可用性セットに含まれる仮想マシンのManaged Diskは

自動的に異なる障害ドメインに配置される。

➢ 可用性セットを構成する場合は、Managed Disk を使うことを強く推奨！

• 「理由はよくわからないけど何か調子が悪い」というときに実行してみるとよい(かもしれない)

• Azure 仮想マシンのディスクをまるごとバックアップ

• 稼働中にオンラインでバックアップ取得可能

• Windows にも Linux にも対応

• Azure ポータルの仮想マシン設定画面から、

簡単に構成・操作できる

• 主要なAzure Backupの利用形態として以下の３種類がある。

1. Azure 仮想マシンのバックアップ

2. オンプレミスの仮想マシンやDBのバックアップ

3. ファイルやフォルダのバックアップ

今日お話しするのはこれ

Azure Backup

• Windows では VSS を利用したアプリケーション整合性バックアップが取得できる。➢ SQL Server などの VSS に対応したアプリケーションであれば、アプリ

ケーションのレベルで静止点を取って、バックアップを行う。

• Linux でもユーザーが独自にバックアップ事前・事後スクリプトを設定することにより、アプリケーション整合性バックアップを取得することができる。(プレビュー)➢ VM 内にスクリプトを配置しておくと、バックアップ事前・事後にそれが自

動的に実行される。

➢ スクリプトが無い、もしくは失敗した場合でも、ファイルシステム整合性バックアップが実行される。

1. 仮想マシン全体のリストア➢ Managed Disk の仮想マシンであれば、そのままManaged Diskの仮想マ

シンとしてリストアされる。

2. ディスクのストレージアカウントへの復元➢ 復元したディスクの利用方法にもいくつかのパターンがある

1. ARMテンプレートを使って復元したディスクから新規仮想マシンを作成

2. 復元したディスクを既存の仮想マシンに接続

3. PowerShellを使って復元したディスクから新規仮想マシンを作成

• Azure Backup は現時点で以下をサポートしない。

1TB よりも大きなディスク➢ つまり 4TBディスクは未サポート

16本よりも多くのディスクを接続した仮想マシン

存在している仮想マシンの上書きリストア➢ まず仮想マシンを削除してからリストアする必要がある

• いずれも将来的にはサポートされる予定。

• 仮想マシン全体ではなく、特定のファイルやフォルダだけをリストアする機能もある。(プレビュー機能)

• 過去時点のディスクがiSCSI ディスクとして仮想マシンに接続され、そこから必要なファイル・フォルダを取り出すことができる。

Azure Backup

iSCSI ディスクとして接続

• Azure Backup では稼働中のオンラインバックアップが可能だが、バックアップ取得は業務ピーク時を外すこと。➢ バックアップ取得時にはストレージアカウントに対して大量のアクセスが発

生し、業務に影響を及ぼす可能性がある。

• 多数の仮想マシン/ディスクを1つのストレージアカウントに詰め込みすぎないようにする。

• 特にバックアップ・リストアの性能が重要な仮想マシンについては、Premium Storage の利用を検討する。

• ジオ冗長ストレージ(GRS)により、バックアップデータを別リージョンに複製することもできる。

Azure Backup

• GRS 同様、 Azure Backup サービス自体のフェールオーバーもマイクロソフトの判断で実施される。

災害時の早期業務再開のためには、ASR が適切な選択肢。

• Azure 仮想マシンのデータを、常に別のAzure データセンターに同期する。

• 大規模災害で Azure データセンターが被災したときに、複製されたデータをもとに別の Azure データセンターで仮想マシンを起動し、業務を再開できる。

• 料金は¥2,550＋ストレージ料金のみ。DR 用仮想マシンの料金が発生するのは、フェールオーバー先で仮想マシンを起動したときのみ。

• Azure Site Recovery には以下の２種類がある。

1. オンプレミスから Azure への DR

2. ２つの Azure データセンター間での DR (プレビュー)

今日お話しするのはこれ

• VM内で動作するエージェントが、同一リージョンのキャッシュストレージに変更データを書き込む。

• キャッシュストレージから複製先リージョンにデータが複製される。

• フェールオバー後に仮想マシンが正しく起動するか、事前にテストしておくことが重要。

• 複製元仮想マシンを稼働させたまま、テストを実行できる。

• 一般的にフェールオーバー手順は複雑になりがち。➢ 手順書を見ながら実行しても、ミスする可

能性がある。

• 複数の仮想マシンからなる複雑なシステムのフェールオーバー処理を、復旧計画として定義できる。➢ 仮想マシン起動の順序や、Azure

Automation Runbook の実行などを定義しておく。

➢ フェールオーバーの際は、この復旧計画を実行すればよい。

• ASR はディスクイメージ全体を非同期で複製する。➢ Active Directoryドメインコントローラーでは、データの不整合が発生する

可能性がある。

• 原則として、Active Directoryドメインコントローラーには ASR を利用しない。

Active Directoryによるデータ複製

Azure Site Recovery

• 1TB を超えるディスクはサポートされない。➢ これは Azure リージョン間での ASRについての制約。オンプレミスから

Azure への ASR では、4TB ディスクがサポートされた。

• Managed Disk はサポートされない。

• 以下の構成については、フェールオーバー時に復旧計画から自動化スクリプトを実行して構成する必要がある。➢ ロードバランサー(内部・外部ともに) / Traffic Manager

➢ Network Security Group (NSG) など

• ASR ではフェールオーバー時にIP アドレス体系を保持することも変更することも、どちらも可能。➢ IPアドレス体系を保持する場合、オンプレミスを含めたルーティングやIPア

ドレスのバッティングの回避などについての考慮が必要。

➢ IPアドレス体系を変更する場合、アプリの正常動作について確認が必要。

10.3.0.0/1610.2.0.0/16

IPアドレス体系重複のため同時接続はNG

IPアドレスが変わっても正常に動作するか？

IPアドレス体系を保持しないIPアドレス体系を保持する

• 社内 WAN からAzure 東日本リージョンへ ExpressRoute で接続していた。

• 災害が発生、ASR で西日本リージョンへフェールオーバーした。

• 社内 WAN から西日本リージョンへどう接続する？

1. あらかじめ西日本リージョンへも ExpressRoute を引いておく。➢ 災害対策用であれば従量課金がおすすめ。

2. Site-to-Site VPN 接続する。➢ 例えば、関西の業務拠点にVPN装置を配置しておき、フェールオーバー時に接続する。

3. 例外的にインターネット経由での接続を許可する。➢ 大規模災害時には社外からのアクセスに対するニーズが高まると予想される。

Office in Los Angeles

10.1.0.0/16

AS 64496

Office in New York

10.2.0.0/16

AS 64496

Network carrier s IP VPN or

Customers backbone network

Virtual Network

Virtual Network

Exp

ress

Ro

ute

Exp

ress

Ro

ute

ExpressRouteLos Angeles

ExpressRouteNew York

West US10.100.0.0/24

East US10.200.0.0/24

Microsoft s

backbone network

Gateway Gateway

広域専用線網

https://docs.microsoft.com/azure/architecture/reference-architectures/virtual-machines-windows/multi-region-application

https://docs.microsoft.com/azure/architecture/reference-architectures/virtual-machines-linux/multi-region-application

機能 ERT (推定復旧時間)

RPO (目標復旧時点)

地理レプリケーション バックアップからの地理リストア

<12時間 <1時間

アクティブ地理レプリケーション <30秒 <5秒

パターン ERT (推定復旧時間)

RPO (目標復旧時点)

アクティブ/パッシブ デプロイとDB 併置によるDR

障害検出時間 +

DNS TLL

<5秒

アクティブ/アクティブ デプロイによるアプリ負荷分散

障害検出時間 +

DNS TLL

<5秒

アクティブ/パッシブ デプロイによるデータ保存 (読み取り専用)

0 <5秒

アクティブ/パッシブ デプロイによるデータ保存 (読み書き)

障害検出時間 +

データ消失の猶予期間

0

https://docs.microsoft.com/azure/sql-database/sql-database-designing-cloud-solutions-for-disaster-recovery

App Service

CosmosDB

SQLDatabase

RedisCache

Storage(Contents)

Storage(Log, Config, etc)

CDN

App Service

CosmosDB

SQLDatabase

RedisCache

Storage(Contents)

Storage(Log, Config, etc)

TrafficManager

Active Region Standby Region

https://docs.microsoft.com/ja-jp/azure/architecture/reference-architectures/managed-web-app/multi-region-web-app

Traffic Manager

マニュアル切り替え可能(優先度変更)

SQL Database

マニュアル切り替え可能(Failover Group内でスイッチ)

Storage

マニュアル切り替え不可Cosmos DB

マニュアル切り替え可能(Write Region変更)

Azure Storageで同期するのは、対抗リージョンでの即時回復、書き込みが不要な静的データ(ログや構成ファイル、バックアップデータなど)に限定する。即時読み取りが必要な場合は、RA-GRSでセカンダリを読めるようにしておく。

App Service

CosmosDB

SQLDatabase

RedisCache

Storage(Contents)

Storage(Log, Config, etc)

App Service

CosmosDB

SQLDatabase

RedisCache

Storage(Contents)

Storage(Log, Config, etc)

TrafficManager

Active Region Standby Region

CDN

API Apps

SearchCosmos DB

(Document)

Blob

Storage

利用者

旧 IMAGE WORKSシステム(Java/Struts/PostgreSQL)

認証

App Service

Microsoft Azure

Storage

Queue

Blob

Storage

Function

s

Storag

e

Queue SQL DatabaseCosmos

DB

Cognitive

ServicesMachine

Learning

Function

s

PC Clients(Windows/Mac)Mobile Clients(iOS/Android)

API Gateway外部システム

Application

Insights

Azure

Monitor

国内データセンター

Web Apps

Token

.NET

• マスターファイル保管• アカウント管理• 権限管理

Identity

Framework

Function

s

REST/OAut

h2

SPA (Browser

App)SPA (Browser

App)

負荷モニター/オートスケール

IMAGE WORKS Modernization Architecture

Microsoft

Azure

Search

Cosmos DB

Blob

Storage

Cosmos DB

SQL Database

Search

ローカルでのインデクシング

Cosmos DB

Search

ローカルでのインデクシング

リアルタイムGeoレプリケーション

App Service App Service App Service

Traffic Manager

西日本(Primary) 米国東部 西ヨーロッパ

日本ユーザ 米国ユーザ ヨーロッパユーザ

オンプレミスIMAGE WORKS

ローカルでのインデクシング

Azure CDN Azure CDN Azure CDN

SQL Database

リアルタイムGeoレプリケーション

SQL Database

Blob

StorageBlob

Storage

6.非機能の限界を超えることができる

✓負荷に適応するリソース - Adaptive Scale

✓稼働率 100% - Zero Downtime

✓運用不要 - NoOps

Server HW

Hypervisor

VM

App Container

App

Deploy

Ready-to-go-Infrastructure

Provision/Boot

Install/Configure

VNet/Virtual Private Cloud

いつでもセルフプロビジョニングできるリソースプール

pre-provisioned ready to host

pool of ready-to-go https://msdn.microsoft.com/en-us/magazine/mt793270

Server HW

Hypervisor

VM

App Container

App

Deploy

Pre

-pro

vis

ion

ed

/ r

ead

y t

o h

ost

どのノードもいつでもデプロイできるように”暖めてある”リソースプール

そのサーバーレスネイティブな内部実装

ILBInstances

Kudu

LoadBalancer

Deployer Telemetry

Prod/Stage

Blob

Allocate

Deploy

Allocate

© 2017 Microsoft Corporation. All rights reserved.

本情報の内容（添付文書、リンク先などを含む）は、作成日時点でのものであり、予告なく変更される場合があります。

90

https://azure.microsoft.com/ja-jp/free/

自分の目と手で試しましょう！

91

ビデオで過去の

ウェブセミナーを視聴する▶▶▶ http://aka.ms/dx-ondemand

セミナー・ウェブセミナーに参加する ▶▶▶ https://aka.ms/azjp-events

Azure の活用を

電話で相談する▶▶▶

0120-952-593

または

お問い合わせフォーム

https://aka.ms/adj

対面で Azure の活用を相談する

Azure 相談窓口▶▶▶

Azure Antenna （渋谷）

月～金午前中および

特設イベントがない月曜日午後

相談窓口 (名古屋）