廣瀬 一海(デプロイ王子)日本マイクロソフト株式会社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としたときの相対的な性能。
• 常に同時に3つのディスクへデータが書き込まれる。
• 最大で同時に2つのディスクが壊れても、データ損失なく稼働する。
VHD ファイル
• ジオ冗長ストレージ(GRS)を使うと、データが自動的に別データセンターにも非同期で複製される。
• 複製元での3重化+複製先での3重化=合計6重化。
> 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 仮想マシンを複数台構成にするときは、可用性セットを定義する。
• これにより、1つのラックの障害で2台の仮想マシンが同時に停止することを回避できる。
• 可用性セット自体にクラスタリング・負荷分散・データ複製などの機能があるわけではないので注意すること。
障害ドメイン 障害ドメイン障害ドメイン
ラック
FC
・・・
・・・
ルータ
ラック
FC
・・・
・・・
ルータ
ラック
FC
・・・
・・・
ルータ
可用性セット
“AS1”
• 障害ドメイン (FD)➢ 同時に物理障害が起こりう
る単位 ≒ ラック
• 更新ドメイン (UD)➢ 同時にメンテナンスを行う
単位
• 2017年2月にGAした仮想マシンの新しいディスク形式。
• いろいろなメリットがあるが、➢ ストレージアカウントの作成・管理が不要に
➢ スナップショット、仮想マシンイメージの容易な作成
➢ Blobとしてのエンドポイントが無い
• 実は Managed Disk では可用性も向上している!➢ 可用性セットに含まれる仮想マシンのManaged Diskは
自動的に異なる障害ドメインに配置される。
➢ 可用性セットを構成する場合は、Managed Disk を使うことを強く推奨!
• 「理由はよくわからないけど何か調子が悪い」というときに実行してみるとよい(かもしれない)
• Azure 仮想マシンのディスクをまるごとバックアップ
• 稼働中にオンラインでバックアップ取得可能
• Windows にも Linux にも対応
• Azure ポータルの仮想マシン設定画面から、
簡単に構成・操作できる
• 主要なAzure Backupの利用形態として以下の3種類がある。
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 には以下の2種類がある。
1. オンプレミスから Azure への DR
2. 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 (渋谷)
月~金午前中および
特設イベントがない月曜日午後
相談窓口 (名古屋)