2017年9月に実施したウェビナーの資料です。

3. • Microsoft Azure の IaaS (Infrastructure as a Service)
• わずか数分で Azure データセンターで仮想サーバーが起動
• 初期費用ゼロ、使った分だけの従量課金
• Windows も Linux も

4. • 仮想化レイヤーより下はクラウドベンダーが責任をもって管理
• 仮想マシンの OS より上はユーザーが責任をもって管理

5. • 仮想化レイヤーより下についてはクラウド
ベンダーが責任をもって管理する
 クラウドベンダーがどのような安心・安全を
提供してくるかは、きちんと確認すること
• 仮想マシンの OS より上の安心・安全は
ユーザーが責任をもって管理する
 OS
 ミドルウェア・ランタイム
 データ
 アプリケーション

6. • システムで本来実現したいこと、
例：データ分析をしたい
Webショッピングサイトを提供したい
機能要件
非機能要件
• そのシステムが満たすべき品質
例：高可用性・バックアップ・災害対策・
セキュリティ・移行容易性・保守性など

8. 高可用性 (HA)
バックアップ
災害対策 (DR)
HWやSWのトラブルが発生しても、
業務を継続できるようにする
データが消失または破損したとき、
それを復旧できるようにする
大規模災害でデータセンターが
稼働できなくなったとき、
早期に業務を再開できるようにする

9. • Azure の仮想化ホスト基盤は、すべて冗長化されている。
• Azure 仮想マシンが稼働する仮想化ホストで障害が発生したとき、
そのAzure 仮想マシンは自動的に別の仮想化ホストで再起動する。

10. • 常に同時に３つのディスクへデータが書き込まれる。
• 最大で同時に２つのディスクが壊れても、データ損失なく稼働する。
VHD
ファイル

11. • ジオ冗長ストレージ(GRS)を使うと、データが自動的に別データセ
ンターにも非同期で複製される。
> 500 miles
東日本 西日本
Blob ストレージBlob ストレージ

12. • Azure 仮想マシンが１台停止しても業務を停止させたくないときは、
複数台の仮想マシンで冗長化構成を組む。
• どう冗長化構成を実装するかは、サーバーの種類により異なる。

13. • Azure 仮想マシンではディスク共有型のクラスタを構成できない。
 とくにファイルサーバーやDBサーバーにおいて要注意
• RDMBS の機能や3rd パーティのソリューションを利用した、ディ
スクを共有しない冗長化構成を考える。
〇 Azureではこちらを利用する× Azureでは利用できない

14. • Azure 仮想マシンを複数台構成
にするときは、可用性セットを
定義する。
• これにより、１つのラックの障
害で２台の仮想マシンが同時に
停止することを回避できる。
• 可用性セット自体にクラスタリ
ング・負荷分散・データ複製な
どの機能があるわけではないの
で注意すること。
障害ドメイン 障害ドメイン障害ドメイン
ラック
FC
・
・
・
・
・
・
ルータ
ラック
FC
・
・
・
・
・
・
ルータ
ラック
FC
・
・
・
・
・
・
ルータ
可用性セット
“AS1”

16. • こういうことは、いつ発生してもおかしくない！
 設定を変更したところ OS が起動しなくなった
 誤って重要なファイルを消してしまった
 アプリのバグによりデータベースのデータが破損してしまった
「定期的に」

17. • Azure 仮想マシンのディスクをまるごとバックアップ
• 稼働中にオンラインでバックアップ取得可能
• Windows にも Linux にも対応
• Azure ポータルの仮想マシン設定画面から、
簡単に構成・操作できる

18. • 主要なAzure Backupの利用形態として以下の３種類がある。
1. Azure 仮想マシンのバックアップ
2. オンプレミスの仮想マシンやDBのバックアップ
3. ファイルやフォルダのバックアップ
今日お話しするのはこれ
Azure
Backup

20. • ジオ冗長ストレージ(GRS)により、バックアップデータを別リー
ジョンに複製することもできる。
• ただし、「別リージョンですぐに業務再開したい」という要件がある場合には、
後述の Azure Site Recovery を検討すること。
Azure
Backup

21. • 仮想マシン全体ではなく、特定のファイルやフォルダだけをリスト
アする機能もある。
• 過去時点のディスクが追加ディスクとして仮想マシンに接続され、
そこから必要なファイル・フォルダを取り出すことができる。
Azure Backup
追加ディスクとして接続

23. • 堅牢な Azure データセンターであっても、大規模災害により稼働停
止する可能性はゼロとは言えない。
• 災害の規模や状況によって、稼働再開までに時間がかかる可能性も。
必要最低限の業務だけでも早めに再開したい
他地域・海外の利用者にサービス提供を継続したい

24. • Azure 仮想マシンのデータを、常に別のAzure データセンターに
同期する。
• 大規模災害で Azure データセンターが被災したときに、複製され
たデータをもとに別の Azure データセンターで仮想マシンを起動
し、業務を再開できる。
• 料金は2,550＋ストレージ料金のみ。
DR 用仮想マシンの料金が発生するの
は、フェールオーバー先で仮想マシン
を起動したときのみ。

25. • Azure Site Recovery には以下の２種類がある。
1. オンプレミスから Azure への DR
2. ２つの Azure データセンター間での DR (プレビュー)
今日お話しするのはこれ

31. • フェールオバー後に
仮想マシンが正しく
起動するか、事前に
テストしておくこと
が重要。
• 複製元仮想マシンを
稼働させたまま、テ
ストを実行できる。

32. • 一般的にフェールオーバー手順は複雑に
なりがち。
 手順書を見ながら実行しても、ミスする可
能性がある。
• 複数の仮想マシンからなる複雑なシステ
ムのフェールオーバー処理を、復旧計画
として定義できる。
 仮想マシン起動の順序や、Azure
Automation Runbook の実行などを定義し
ておく。
 フェールオーバーの際は、この復旧計画を
実行すればよい。

33. • ASR はディスクイメージ全体を非同期で複製する。
 Active Directoryドメインコントローラーでは、データの不整合が発生する
可能性がある。
• 原則として、Active Directoryドメインコントローラーには ASR を
利用しない。
Active Directory
によるデータ複製
Azure Site Recovery

35. • 仮想化レイヤーより下はクラウドベンダーが責任をもって管理
• 仮想マシンの OS より上はユーザーが責任をもって管理

36. • 仮想化レイヤーよりも下のセキュリティは、ク
ラウドベンダーが責任を持つ
• 仮想マシンの OS より上のセキュリティはユー
ザーが責任をもって管理する
 OS (設定、更新プログラム、パスワード)
 ミドルウェア・ランタイム (設定、更新プログラム)
 データ (暗号化、アクセス権)
 アプリケーション (脆弱性)
やるべきことはオンプレミスと大きくは変わらない

37. クラウド環境
Azure Log Analytics
オンプレミス DC
• セキュリティをはじめとするITインフラ品質強化
ログやシステム情報 マイクロソフトの知見および機械学習
• WindowsだけでなくLinux AzureだけでなくVMwareやAWS、物理サーバー

38. Log Analytics
改ざん不可能なクラウド

39. 機械学習を活用した不正なふるまい検知
セキュリティ攻撃が疑われるふるまいを検知
人工知能を活用

40. 不正なIPアドレスとの通信の検知
不正なIPアドレスとの通信を検知

41. アップデート適用状況を可視化

42. セキュリティ ベースラインの評価
マイクロソフトのベストプラクティス
改善すべき設定項目

43. 脆弱性を指摘し、強化策を提示
侵入を検知

45. • 仮想マシン作成時には、以下のアプローチを検討してください。
 停められないシステムは複数台で冗長化構成にし、可用性セットを
定義する。
 データやOSの破損・消失に備え、Azure Backup を必ず設定する。
 特に重要な、大規模災害時にもすぐに利用再開したいシステムにつ
いては、Azure Site Recovery でDRを構成する。
 セキュリティ強化のため、Azure Log Analytics および Azure
Security Center を活用する。
 具体的なセキュリティ強化策についてクラウドがガイドしてくれる。