Azure 初心者向け

1. Ayumu Inaba
Cloud Solution Architect
Microsoft Japan
Microsoft Azure 入門
1

2. はじめに
Microsoft Azure は開発者や IT Pro がアプリケーションの構
築・運用・管理を行うための包括的なパブリッククラウドサービスで
す。2010 年に正式サービスを開始してから拡張と改善を継続して
おり、現在は 100 を超えるサービスや機能から構成されています。
多種多様なサービスを適材適所に選択していただくことで広範な
ユースケースに対応できる反面、その情報の多さと進化の速さゆえ
に、初学者には敷居が高くなってしまっている面が否めません。
本セミナーでは今後 Azure をご利用いただく可能性のある全ての
エンジニアに知っておいていただきたい基本的な情報を紹介し、
日々の業務の生産性向上に役立てられるようになっていただけるこ
とを目的としています。
2

3. はじめに
対象エンジニアのスキルセット
システム設計・構築・運用に関する基本的な知識をお持ちの方
終了後の期待
Azure を利用した簡単なシステムの構築ができるようになる
システムの具体的な構成要素として Azure を評価・選定できるようになる
本セミナーの形式
本セミナーは座学による講習会形式であり、実機を用いたハンズオン等は行いません
事前準備や受講のための持ち込み機材は不要です
3

4. Agenda
Microsoft Azure 概要
Azure による Web＋DB システム構築
Infrastructure as a Service
Platform as a Service
IaaS と PaaS の使い分け
Container as a Service
Azure 環境の保守と監視
クラウド時代の構築技法 ： Azure Resource Manager
Azure サブスクリプションと 開発者 ID／権限の管理
Azure ベースシステムの監視
4

5. 5
“Empower every person and
every organization on the planet
to achieve more”
“地球上のすべての個人とすべての組織が
より多くのことを達成できるようにする”

6. 6

7. Microsoft Azure 概要
Azure はシステムを構成するために一
般的に必要となる各種の “部品” を提
供するサービスの総称
エンジニアは必要な部品を “組み合わ
せ” 、アプリやデータを”配置”することで
システム構築する
各部品の特性を活かしたアーキテクチャ
を実装することで、クラウドならではメリッ
トを享受できる
7

8. 8
プラットフォーム サービス (PaaS)
インフラストラクチャ サービス (IaaS)
Web
Apps
Mobile
Apps
API
Apps
Notification
Hubs
ハイブリッド
クラウド
Backup
StorSimple
Azure Site
Recovery
Import/Export
SQL
Database CosmosDB
Redis
Cache
Azure
Search
Storage
Tables
SQL Data
Warehouse
Azure AD
Health Monitoring
AD Privileged
Identity
Management
Operational
Analytics
Cloud
Services
Batch
RemoteApp
Service
Fabric
Visual Studio
Application
Insights
VS Team Services
Domain Services
HDInsight Machine
Learning Stream Analytics
Data
Factory
Event
Hubs
Data Lake
Analytics Service
IoT Hub
Data
Catalog
セキュリティ /
統合管理
Azure Active
Directory
Multi-Factor
Authentication
Automation
Portal
Key Vault
Store/
Marketplace
VM Image Gallery
& VM Depot
Azure AD
B2C
Scheduler
Xamarin
HockeyApp
Power BI
Embedded
SQL Server
Stretch Database
Mobile
Engagement
Functions
Cognitive Services Bot Framework Cortana
Security Center
Container
Service
VM
Scale Sets
Data Lake Store
BizTalk
Services
Service Bus
Logic
Apps
API
Management
Content
Delivery
Network
Media
Services
Media
Analytics

9. Azure のサービスは IaaS か PaaS に分類される
9
ストレージ
サーバー
ネットワーク
OS
ミドルウエア
ハイパバイザ
ランタイム
アプリケーション
データ
ストレージ
サーバー
ネットワーク
OS
ミドルウエア
ハイパバイザ
ランタイム
アプリケーション
!
"
#
$
%
管
理
データ
IaaS
(Infrastructure as a Service)
PaaS
(Platform as a Service)
SaaS
(Software as a Service)
ストレージ
サーバー
ネットワーク
OS
ハイパバイザ
ランタイム
アプリケーション
データ
ミドルウエア
ストレージ
サーバー
ネットワーク
OS
ミドルウエア
ハイパバイザ
ランタイム
アプリケーション
(
)
*
管
理
データ
オンプレミス

10. 世界最大規模のインフラ
10https://azure.microsoft.com/en-us/global-infrastructure/regions/

11. グローバル ネットワーク
11https://azure.microsoft.com/ja-jp/global-infrastructure/global-network/

12. 所有（オンプレミス）から利用（サービス）へ
利用者は提供されるメニューから必要なものを選んで使う
自分に合ったものが提供される ⇒ ありものを組み合わせて賄う
ベンダーに責任を委譲する ⇒ パートナーと協力して作り上げる
12施設
ネットワーク
物理サーバ
仮想化基盤
仮想OS
ミドルウェア
アプリケーション
エンド
ユーザ
アプリ
開発部門
IT部門
使う 作る
委譲
作る
作る
委譲
委譲
委託
企業
エンド
ユーザ IT部門 ベンダー
使う
作る
作る
協力
企業
選ぶ 支援
所有 利用

13. SLA : Service Level Agreement
Azure の有償サービスは全て SLA を提供
稼働時間と接続に関する Microsoft からのコミットメント
実際の稼働率が SLA 設定値を下回った場合の利用料金に対するクレジットを規定
稼働率の測定や適用の条件については下記を確認
https://azure.microsoft.com/ja-jp/support/legal/sla/
無償プラン、プレビュー中のサービス、開発・テスト用サブスクリプションは適用外
SLA の A は Availability ではない
あくまでもクレジットを適用する基準となる閾値であって、可用性の実績値では無い
実績値は Microsoft から公表されてはいないが、信頼性の意味でも第３者による測定値を
参考にするとよい
https://cloudharmony.com
大規模障害が発生した月などは一時的に実績値が SLA を下回るケースはあるが、多くの
場合は SLA よりもはるかに高い
13

14. アーキテクチャの例
14
Enterprise Disaster Recovery
Virtual Desktop Infrastructure
High Performance
Computing

15. アーキテクチャの例
15
E-Commerce Website
Picture and Movie analytics
Predictive Maintenance

16. アーキテクチャの例
16
High Availability
Web Service
リファレンスアーキテクチャは他にもたくさんある
https://docs.microsoft.com/ja-
jp/azure/architecture/reference-architectures/
Big Data Analytics
CI/CD Pipeline

17. Shared Responsibility
17https://docs.microsoft.com/ja-jp/azure/security/security-management-and-monitoring-overview
クラウドを
使用することで確実に
得られるメリット
サービスによって
考え方が異なる
従来と全く変わらない
領域

18. コンプライアンス
18
HIPAA / HITECH
Act
FERPAGxP
21 CFR Part 11
ISO 27001 SOC 1 Type 2ISO 27018
CSA STAR
Self-Assessment
Singapore
MTCS
UK
G-Cloud
Australia
IRAP/CCSL
FISC Japan
New Zealand
GCIO
China
GB 18030
EU
Model Clauses
ENISA
IAF
Argentina
PDPA
Japan CS
Mark Gold
CDSA Shared
Assessments
Japan My
Number Act
FACT UK
GLBA
Spain
ENS
PCI DSS
Level 1
MARS-E FFIEC
China
TRUCS
SOC 2 Type 2 SOC 3
Canada
Privacy Laws
MPAA
Privacy
Shield
ISO 22301
India
MeitY
Germany IT
Grundschutz
workbook
Spain
DPA
CSA STAR
Certification
CSA STAR
Attestation
HITRUST IG Toolkit UK
China
DJCP
ISO 27017
GLOBALINDUSTRYREGIONAL

19. セキュリティへの取り組み
サイバー ディフェンス オペレーションズ センター
Azure DC 内のパブリック IP に対するトラフィックを２
４時間体制で監視
人工知能を用いた DDoS / DOS / IDS 防御機能を
標準で備えている為、不正なトラフィックを９０秒以内に、
自動検知・遮断
セキュリティ専門家やデータ サイエンティストが常駐、１
日５億件以上のトラフィックを分析
サイバー クライム センター
インターポールやセキュリティ団体、FBI や各国
の警察機関に最新の情報を提供
攻撃元発信者特定を行い、警察機関と直接連
携した対応
米国本社の他、日本を含む世界５都市に展開
19

20. Windows Microsoft Azure = オープンクラウド
20
Applications
Clients
Infrastructure
Management
Databases &
Middleware
App Frameworks
& Tools
DevOps
PaaS &
DevOps

21. AzureJAPAN
https://www.microsoft.com/ja-jp/business/nowon-azure

22. 22

23. 使い方をイメージできることは重要
使い方を知らないと“目的”に対して適切な“手段”か否かを
判断できない
生まれて初めての旅行に行く人は、車で行くべきか、電車で行くべきか、飛行機で行くべきか、
どれが一番良いのか判断できない
23
On-demand Self-Service
Broad network access
Resource pooling
Rapid elasticity
Measured Service
どのように
提供されていて
自分にとって
どんなメリットが
あるのか？

24. 24
これを
全部？！

25. まずは基本から
Azure を始めて使う開発者がいきなり躓かないために、必要
なポイントに絞って紹介
IaaS で作る Web＋DB システム
PaaS で作る Web＋DB システム
利用料金のお見積り
IaaS と PaaS の違いと使い分け
コンテナテクノロジーの活用
Infrastructure as Code の時代に
開発者 ID と権限の管理
目的は“Azure を使うってどんな感じ？” を持ち帰ること
覚えて帰る必要はありません、テストに出ません
25

26. 26

27. クラウドサービスの種類
27
ストレージ
サーバー
ネットワーク
OS
ミドルウエア
ハイパバイザ
ランタイム
アプリケーション
データ
ストレージ
サーバー
ネットワーク
OS
ミドルウエア
ハイパバイザ
ランタイム
アプリケーション
!
"
#
$
%
管
理
データ
IaaS
(Infrastructure as a Service)
PaaS
(Platform as a Service)
SaaS
(Software as a Service)
ストレージ
サーバー
ネットワーク
OS
ハイパバイザ
ランタイム
アプリケーション
データ
ミドルウエア
ストレージ
サーバー
ネットワーク
OS
ミドルウエア
ハイパバイザ
ランタイム
アプリケーション
(
)
*
管
理
データ
オンプレミス

28. 構築作業のイメージ
28

29. RDP/SSH 接続してセットアップ
仮想マシンと同時に作成されたパブリック IP アドレスに対し
て管理プロトコルを用いて接続する
通常は Windows OS であれば RDP や WinRM、Linux であれば SSH を使用する
VPN 等が無い場合はインターネット経由でこれらのプロトコルを利用する
29

30. サービスとして公開
ミドルウェア構成やアプリケーションを設定したら NSG の
ポートを開ける必要がある
NSG : Network Security Group ＝ パケットフィルタ型のファイアウォール
初期設定では RDP or SSH での接続しか許可されていないため、必要なアプリケーション
プロトコルのポートを開放する（HTTP なら 80 など）
OS 側のファイアウォール（iptables など）も別途設定する必要がある場合もある
30

31. 31

32. サブネット
仮想マシンの構成要素
基本的に Azure 仮想マシンは以下の要素で構成される
仮想マシン
OS ディスク
ネットワークインタフェース
仮想ネットワーク
32
ネットワーク
インタフェース
仮想ネットワーク
Public IP
Address
OSディスク
データディスク
ネットワーク
セキュリティ
グループ
オプション
ネットワークセキュリティグループ
パブリック IP アドレス
データディスク

33. 仮想マシンのシリーズ（性能特性）
33
Ev3 F G H L
NC NCv2 NV SAP
エントリーレベル
インスタンス
A シリーズよりも
最⼤ 36% 値下げ
A シリーズよりも
60% ⾼速な CPU
D シリーズよりも
35% ⾼速な CPU
DV2 シリーズと
同じ CPU を
安価に提供
ストレージ
最適化インスタンス
ハイエンド
コンピューティング⽤
コア数とメモリの
最⼤サイズを提供
SAP HANA on
Azure
新しい世代の
D シリーズ
メモリ最適化
インスタンス
NVidia K80
計算
NVidia P100S
計算
NVidia P40s
ディープラーニング
NVidia M60
可視化
A Av2 B D Dv2 Dv3
Fv2
ND
Skylake 搭載の
最速の仮想マシン
負荷増加に合わせて
CPU バースト可能
M
コア数とメモリの
最⼤サイズを提供

34. 仮想マシンのサイズ
各シリーズにはスペックの異なる複数
のサイズが提供されている
右記は M シリーズの例
34

35. 仮想マシンのディスク
仮想マシンに接続するディスクは以下の３つ
OS ディスク ：Windows / Linux 等の OS に加えて MW やアプリを格納することが多い（必須）
データディスク ：ファイルや DB などデータを格納するために必要に応じて接続する（追加）
一時ディスク ：仮想マシンの物理ホスト上のローカルストレージを使用するため揮発性（標準）
35Hyper-V ホスト ストレージ
仮想マシン インスタンス
作業用ディスク
※ Hyper-V ホストロー
カルの
動的拡張 VHD
キャッシュ OS ディスク
データ ディスク
1 ディスクあたり最
大 ４０９６ GB
1 VMあたり
最大 64 本VHD

36. 管理ディスクの種類
OS Disk として１つ、 Data Diskは複数接続が可能
36
Standard HDD
管理ディスク
Standard SSD
管理ディスク
Premium SSD
管理ディスク
Ultra SSD
ディスク遅延 2桁ミリ秒 1桁ミリ秒
キャッシュなし読出し: ~4ms
キャッシュなし書込み: ~1ms
<1ms
最大ディスク
サイズ
4TB -> 32TB 4TB -> 32TB 4TB -> 32TB 4TB -> 64TB
最大ディスク
IOPS
500 IOPS -> 2,000 500 IOPS -> 6,000 7,500 IOPS -> 20,000 160,000
最大ディスク
帯域幅
60 MBps -> 500
Mbps
60 MBps -> 750
Mbps
250 MBps -> 900
Mbps
16Gbps - 2 GB/s

37. Premium SSD Managed Disk の価格表
37
SKU ディスク サイズ 月額 ディスクあたりの IOPS ディスクあたりのスループット
P4 32 GiB ¥680.11 120 25 MB/秒
P6 64 GiB ¥1,314.87 240 50 MB/秒
P10 128 GiB ¥2,539.04 500 100 MB/秒
P15 256 GiB ¥4,896.72 1,100 125 MB/秒
P20 512 GiB ¥9,430.40 2,300 150 MB/秒
P30 1 TiB ¥17,409.28 5,000 200 MB/秒
P40 2 TiB ¥33,370.25 7,500 250 MB/秒
P50 4 TiB ¥63,838.73 7,500 250 MB/秒
P60 8 TiB ¥121,873.92 16,000 500 MB/秒
P70 16 TiB ¥232,141.28 18,000 750 MB/秒
P80 32 TiB (32767 GiB) ¥464,281.44 20,000 900 MB/秒

38. 仮想ネットワーク（VNET）
仮想マシンは仮想 NIC を介して仮想ネットワークに接続
サブネットに割り当てられたアドレスレンジから DHCP で IP アドレスの割り当てを受ける
RFC1918に準拠して衝突しないネットワーク設計をする
38
仮想ネットワーク (VNET)
10.2.3.4
web01 web02
サブネット1 サブネット2
10.2.3.5 10.5.3.10 10.5.3.11
ap01 ap02

39. オンプレミスと仮想ネットワークの接続
オンプレミス環境との接続方式は大きく 3 つ
Point to Site VPN, Site to Site VPN, ExpressRoute （閉域網接続）
VNET に設置した VPN Gateway とオンプレミス側のルーターをピアリングして構成する
（VNET と オンプレミスのアドレスレンジの衝突に注意）
39
インターネットインターネット

40. Network Security Group
仮想マシンの送受信トラフィックを制御するパケットフィルタ
40
仮想ネットワーク (VNET)
Firewall VM
VM02VM01
http://msdn.microsoft.com/ja-jp/library/azure/dn848316.aspx
NSG_1
NSG_2
NSG_3
DMZ
サブネット
Frontend
サブネット
Backend
サブネット

41. Azure Load Balancer
仮想ネットワークに設置する L4 仮
想ネットワークアプライアンス
可用性セットや可用性ゾーン（後述）と組み合わせて
仮想マシンの高可用性構成を実現する
負荷分散だけでなく NAT を構成することができる
41
負荷分散規則︓80/tcp
100.64.x.4 100.64.x.5
80/tcp 80/tcp
可⽤性セット

42. Azure 仮想マシンの中身
仮想マシンは IaaS なので OS より上位の
スタックはユーザーの自由に構成して良い
ただし現実問題としては Azure VM として動作可能な要件を満た
す必要があるため、一定のレギュレーションは存在する
１つ１つの要件を満たすのは煩雑であるため、構成ずみの“イメー
ジ”をベースにカスタマイズした方が早い
多数の動作確認済みのイメージが Azure
Marketplace で提供されている
OS のみのものだけでなく、ミドルウェアやアプリケーションまでセッ
トアップ済みのものもある
Microsoft だけでなく 3rd Party から提供されているものもある
42
ストレージ
サーバー
ネットワーク
OS
ミドルウエア
ハイパバイザ
ランタイム
アプリケーション
データ

43. Azure Marketplace
43

44. 44

45. Design for Failure and Resilience
障害を避けるだけでなく、障害が発生した時
に対応するための仕組みが重要
Data Backup
データの破損や削除に備えて、以前の正常な状態に復旧する
High Availability
障害時にもダウンタイムを極小化し、システムが健全な状態で継続
稼働することを目的とする
Disaster Recovery
広域災害においても迅速なシステムを復旧し、業務継続・サービス
提供することを目的とする
45
Original Backup
Primary site
Secondary sitePrimary site

46. 物理的な側面から見た仮想マシン
46
Azure DC
多数のラック
物理サーバ
（ホスト）
ストレージ
ユニット
接続
仮想マシンは、作成時に指定したリージョン
内の “どこか” にデプロイされ、ネットワーク
接続によって利用可能となる
Availability
Zone
DC
DC
AZ
AZ

47. Regional Network
Regional Network
Gateways
DC間接続を多重化することえ１つのDC障
害をリージョン全体に波及させない
DCの増設による既存リージョンの増強も
容易になっている
Software Defined
Network
ユーザーには VNET として抽象化され、
かつ構成可能な状態で提供される
プラットフォームは頻繁に構成変更が行わ
れているが、仮想化されているため影響を
受けない
47

48. Locally Redundant Storage
仮想マシンのディスクは内部的に最低でも 3 つに多重化され
ている
下記は仮想マシン（IaaS）の例だが、各種 PaaS でも同様
48
3重のレプリカ
ストレージ
障害
OS/データ
ディスク

49. Unplanned Maintenance
計画外メンテナンス（障害）発生時には Service Healing と
いう仕組みによって自動復旧が試みられる
仮想マシンからは突如再起動が発生したように見えるが、再起動後に同じディスクに接続す
るため永続化されたデータは失われない
障害の予兆が検知された場合には前述の Live Migration を使用してプロアクティブにメ
ンテが行われる場合もある
49
Hyper Visor
Host
Agent
Azure
Fabric
Controler
Devices
Hyper Visor
Host
Agent
Devices

50. Planned Maintenance
In-Place Migration
ホストマシンのメンテナンス中にゲストマシンの
メモリの内容を保持することで、再起動を避ける
仕組み
ゲストマシンは最大 30 秒程度の一時停止状
態となる（通常は１０未満）
メモリ保護更新とも呼ばれる
Live Migration
ゲストマシンのメモリの状態を保持したまま別の
ホストマシンに移動する仕組み
メンテナンスだけではなく、ハードウェア障害や
リソース割り当ての最適化にも使用される
50
https://docs.microsoft.com/ja-jp/azure/virtual-
machines/linux/maintenance-and-updates

51. Planned Maintenance ： 再起動を伴う場合
計画メンテナンスによって仮想マシンの再起動を予定された
場合 30 日以上前に通知が送信される
システムの運用スケジュールとメンテナンスのスケジュールを突き合わせて、再起動のタイミン
グに問題が無いか確認
問題がある場合には “プリエンプティブなメンテナンス期間”から適切なタイミングを選択し
て能動的にメンテナンス済みホストに再デプロイすることが可能
51
スケジュールされた
メンテナンス期間
セルフサービス期間
再起動可能な
時間帯
再起動可能な
時間帯

52. VM 内メタデータサービスを利用した自律運用
仮想マシン内部のアプリは自身が稼働する仮想マシンに予定
されたメンテナンス情報を取得することが可能
Freeze（保持）、Reboot（再起動）、Redeploy（再配置）といったイベント種別に応じた閉
塞処理等をアプリケーションに組み込む
メンテナンスに対して仮想マシンが自律的に対応するようにすることで、運用の負担を下げる
ことが可能
52
アプリ
※イベントは 10 分から 15 分前に通知されるため、人間による手動対応の用途には向いていない

53. ↑ ↑ ↑
ここまでは Azure にビルトインされた標準機能
ここからはユーザーの構成が必要なオプション
↓ ↓ ↓
53

54. Azure で構成可能な HA/DR
54
Zone 2 Zone 3
Zone 1
Region 2
Data
center 1
Data
center 2
Zone 2 Zone 3
Zone 1
Region 1
SLA 99.9%
Single VM Single Datacenter Single Region Multiple Region
Premium
Storage
SLA 99.95%
Availability Sets
SLA 99.99%
Availability Zone Region Pair
Data Backup
ハードウェア障害への対応 ラックレベルの障害に対応 データセンターレベル障害に対応 広域災害に対応
Disaster RecoveryHigh Availability

55. 可用性セット : Availability Sets
複数の仮想マシンをラックレベルで分散配置する
異なる障害ドメイン（FD）に分散配置＝単一障害点を回避するように配置
異なる更新ドメイン（UD）に分散配置＝メンテナンスによる同時再起動を回避
計画／非計画メンテナンスを問わずに自動復旧が見込めるため、運用への負担も小さくなる
55
FD0 FD1 FD2

56. 可用性ゾーン：Availability Zone
複数の仮想マシンをリージョン内の複数のデータセンターに
分散配置する
１つないしは複数のデータセンターからなる各ゾーンは電源、冷却、ネットワークが独立
可用性ゾーンは障害ドメインおよび更新ドメインを組み合わせたもの
56
Region
Availability Zone
1
Availability Zone
2
Availability Zone
3

57. ペアリージョン ： Paired Region
複数の仮想マシンを２つのリージョンに対して地理的に分散
配置する
任意のリージョンの組み合わせではなく、ペアリージョンは指定されているものを利用すること
ペアとなるリージョンは同時にメンテナンスが行われないように運用されている
57
Primary Region
Availability
Zone 1
Availability
Zone 2
Availability
Zone 3
Secondary
Region
Availability
Zone
Availability
Zone
> 300mile

58. ワークロードも含めた可用性の考慮
クラスタレベルでの「サービスとしての可用性」のためには利用者側でも複数の仮想マシン
上に配備されることを意識したソフトウェア構成が必要
58
クラスタ
全体の
可用性
Microsoftの
責任範囲
Virtualization
Compute Storage Network
利用者の
責任範囲
Operating System
Middleware
Application
Virtualization
Compute Storage Network
Operating System
Middleware
Application

59. 例）Web サーバーの場合
仮想マシンが Web サーバーの場合にはアプリケーションをス
テートレスに実装する
前段の負荷分散装置としては Azure Load Balancer や Application Gateway といっ
た別の Azure リソースが利用可能
59
Load Balancer
ないしは
Application Gateway
HTTP/HTTPS
可用性セット
ステートレスに実装されたアプリケーションを配置
⇒ 任意のサーバーで障害ノードの代替が可能
プローブにより障害ノードを
検知したらクラスタから切り離す

60. 例）DB サーバーの場合
仮想マシンの役割が DB サーバーの場合は、対応したクラス
タ用ミドルウェアが必要になることが多い
SQL Server の場合には Always On Availability Group および Windows Server
Failover Cluster などを利用
複数の DB サーバー間でデータ同期を取りつつ、Load Balancer の NAT 機能を利用して
主系への透過的な接続を実現
60
Load Balancer
TDS
可用性セット
Active
Stand-by
主系で永続化されたデータを
Always-on の機能によって
同期レプリケーション

61. Disaster Recovery as a Service
任意のリージョン間での仮想マシンのレプリケーションとフェー
ルオーバーを実現
ソフトウェアやディスク構成に一部制約があるので注意
61
仮想マシン
（レプリケーション元）
Primary リージョン Secondary リージョン
仮想マシン
（レプリケーション先）
ディスク ディスク

62. クラスタソフトウェアの活用
複数の仮想マシンを同一の仮想ネットワークに接続することで
アプリケーション間での相互通信が可能
可用性セットないしはゾーンを使用した単一リージョン内配置の場合
ペアリージョンを使用する場合は Express Route や VNET Peeringを構成する
62
WSFC
SQL Server
Always-on
Windows
Server
WSFC
SQL Server
Always-on
Windows
Server
データ同期
WSFC
SQL Server
Always-on
Windows
Server
WSFC
SQL Server
Always-on
Windows
Server
データ同期

63. 可用性の目安
過剰品質とならないように現実的な可用性目標を設定する
63
Cost + complexity
Availability
Video delivery, broadcast systems
ATM transactions, telecommunications systems
Batch processing, data extraction, transfer, and load jobs
Internal tools like knowledge management, project tracking
Online commerce, point of sale
99%
99.9%
99.95%
99.99%
99.999%

64. Backup as a Service
仮想マシン全体、特定のフォルダ、アプリケーションデータを
バックアップ
スケジューリング、世代管理、重複排除などをポリシーで指定
GRS を有効にすることでデータのペアリージョンに退避することができる（リストア不可）
64

65. ３rd Party Solution
65
Partner Product Solution Key Workloads
CommVault
Backup and DR, Workload and Data Migration, Endpoint Data
Protection
Veritas NetBackup
Veritas BackupExec
Backup and DR, Workload and Data Migration, Endpoint Data
Protection
HPE Data Protector
HPE VM Explorer
StoreOnce CloudBank
Backup and DR
NetApp ONTAP Cloud
NetApp AltaVault Cloud-Based Appliance
Backup and DR, Migration, DevTest
Data Domain Cloud Tier
EMC Avamar Virtual Edition
EMC Data Protection Suite CloudBoost
Backup and DR
Long-Term Retention
Veeam® Cloud Connect for the Enterprise
Veeam® Cloud Connect for Service Providers
Veeam® Direct Restore to Azure
Backup and DR, Workload and Data Migration, Endpoint Data
Protection
Quest Rapid Recovery Backup and DR, Archiving
Carbonite Endpoint Protection Endpoint Data Protection
Spectrum Protect Backup and DR for Windows, Linux, and Unix
Actifio Sky Backup and DR, Data Migration, DevTest
Rubrik Backup and DR, Workload and Data Migration, Archival, Search
Cohesity CloudArchive, CloudTier, CloudReplicate
Innovative secondary storage consolidation platform with
comprehensive integration with Azure Disks and Blobs

66. SLA : Service Level Agreement
Azure の有償サービスは全て SLA を提供
稼働時間と接続に関する Microsoft からのコミットメント
実際の稼働率が SLA 設定値を下回った場合の利用料金に対するクレジットを規定
稼働率の測定や適用の条件については下記を確認
https://azure.microsoft.com/ja-jp/support/legal/sla/
無償プラン、プレビュー中のサービス、開発・テスト用サブスクリプションは適用外
SLA の A は Availability ではない
あくまでもクレジットを適用する基準となる閾値であって、可用性の実績値では無い
実績値は Microsoft から公表されてはいないが、信頼性の意味でも第３者による測定値を
参考にするとよい
https://cloudharmony.com
大規模障害が発生した月などは一時的に実績値が SLA を下回るケースはあるが、多くの
場合は SLA よりもはるかに高い
66

67. 仮想マシンの SLA
Microsoft Azure では仮想マシンの可用性（＝接続可能な
時間の割合）に対して３種類の SLA を定義している
諸条件の詳細については公式ドキュメントを参照
https://azure.microsoft.com/ja-jp/support/legal/sla/virtual-machines
67

68. 68

69. 見積もり例
69
項目 スペック 単価 台数 月額料金
Web サーバー
仮想マシン F2 : 2 vCPU, 4 GB Memory ¥10,301.76/月 4 41,207.04
OS ディスク S10 : 128 GB HDD ¥659.46/月 4 2,637.84
データディスク N/A ¥0 4 0.00
DB サーバー
仮想マシン DS3v2 : 4 vCPU, 14 GB Memory ¥33,439.84/月 2 52,489.92
OS ディスク P10 : 128 GB SSD ¥2,539.04/月 2 5,078.08
データディスク P30 : 1 TB SSD ¥17,409.28/月 2 34,818.56
ネットワーク
送信データ転送 ゾーン２ : 5TB ¥13.44/GB 5120 68,812.80
パブリックIP 動的 ¥324/月 1 324.00
ロードバランサー Basic ¥0 2 0.00
上記は2018年5月時点での東日本リージョンの料金を元に算出
最新の料金表は以下を参照
https://azure.microsoft.com/ja-jp/pricing/
※ 送信データ転送の最初の 5GB は無料
月額 ¥205,368.24

70. VM の価格と OS ライセンス
VM 料金は 2 階建てになっておりコストダウン方式も2通り
BYOL と Reserved Instance を同時に適用することも可能
70
Compute リソースの料金
（CPU/Memory/一時ディスク）
OS の従量課金モデル料金
(Windows, RHEL, SUSE など）
※ Ubuntu/CentOS 等は ¥0
Compute リソース
OS 従量課金
Compute リソース
https://azure.microsoft.com/ja-
jp/pricing/reserved-vm-instances/
https://azure.microsoft.com/ja
-jp/pricing/hybrid-benefit/

71. スケールアウト／スケールアップ
負荷や需要に応じてスケールを調整することでコストを最適
化する
スケールアップ／ダウン は仮想マシンのスペックを変更するだけ（再起動を伴う）
スケールアウト／インは仮想マシンの追加や削除だけではなく、通常は内部で動作するアプリ
ケーションやロードバランサー等の調整も必要になることが多い
71
スケールアップ／ダウン
可用性セット
運用状況を鑑みて
適切なサイズに変更
運用状況を鑑みて
インスタンスを追加
新しいインスタンスに
負荷を分散するように
規則を調整する

72. 無駄なコストを払わないために
サービスを提供しないときは仮想マシンを停止することでの課
金を抑えることが出来る
VM は起動時間に応じて分単位（秒以下は切り捨て）で課金される
OS をシャットダウンしても課金され続けるため、ポータルから VM を停止すること
72
サブネット
ネットワーク
インタフェース
仮想ネットワーク
Public IP
Address
OSディスク
データディスク
ネットワーク
セキュリティ
グループ

73. 後片づけ
全く利用予定がない場合はリソースグループごと削除してしま
うとよい
VM を停止してもストレージの課金は継続していることに注意
（当然ながら）削除すれば全ての課金は停止する
73

74. 74

75. クラウドサービスの種類
75
ストレージ
サーバー
ネットワーク
OS
ミドルウエア
ハイパバイザ
ランタイム
アプリケーション
データ
ストレージ
サーバー
ネットワーク
OS
ミドルウエア
ハイパバイザ
ランタイム
アプリケーション
!
"
#
$
%
管
理
データ
IaaS
(Infrastructure as a
Service)
PaaS
(Platform as a
Service)
SaaS
(Software as a
Service)
ストレージ
サーバー
ネットワーク
OS
ハイパバイザ
ランタイム
アプリケーション
データ
ミドルウエア
ストレージ
サーバー
ネットワーク
OS
ミドルウエア
ハイパバイザ
ランタイム
アプリケーション
(
)
*
管
理
データ
オンプレミス

76. Azure Web Apps & SQL Database
PaaS と言ってもバリエーションが極めて多いので、まずは最
も利用頻度の高いこの２つから取り掛かると良い
76
PaaS 型 Web サーバ・AP サーバ PaaS 型 DB サーバ
サービス名称 Azure Web Apps SQL Database
正式リリース 2012 年 ６ 月 2010 年 2 月
技術的特性 共有型 Web サーバーサービス 共有型 DB サーバーサービス
技術基盤 Windows (IIS), Linux (Apache), Docker Windows, SQL Server
開発言語 .NET, Java, PHP, Pyhon, Node.js… T-SQL
主な特徴 自動負荷分散、オートスケール
自動パッチ適用、自動障害復旧
容易なユーザ認証機能の追加
Application Insights による容易な監視
拠点内 3 多重化、自動フェイルオーバ
拠点間複製、拠点間フェイルオーバ対応
自動バックアップ、時刻指定リストア
透過的暗号化などのセキュリティ対応
関連サービス Functions, Logic Apps, Application
Insights, etc…
Azure Database for MySQL, PostgreSQL,
SQL Data Warehouse

77. 構築作業のイメージ
77

78. 78

79. アプリケーションとプラットフォーム
79
Load
Balancin
g
Web Workers
共有
ストレージ
OS + Web + MW
App Deployment
Monitoring
Etc…
OS + MW
App

80. App Service のインフラストラクチャ
App Service は Stamp と呼ばれる大量のリソースの中から一部
を占有ないしは共有する形で割り当てる
各 Web Worker の正常性は Azure プラットフォームにより監視・自動運用がなされており、障害時
には自動的にインスタンスの切り替えおよび負荷分散の調整が行われる
Isolated 負荷分散および Web Worker を占有（App Service Environment）
Premium/Standard 負荷分散は共有、Web Worker を占有
Free/Shared 負荷分散および Web Worker を共有
80
Web Workerプール
利用者Aが占有
利用者Bが占有
利用者Cが占有
空き
負荷分散

81. アプリ配置方式の使い分け
検証・試用 Kudu / FTP / WebDeploy / ローカル Git
個人利用 OneDrive / Dropbox とのコンテンツ同期
本格的な開発 VSTS / GitHub / BitBucket からの継続的なデプロイ
※実践的には VSTS の Build & Release Pipeline や Jenkins 等を使用した CI/CD を構成するとよい
81
Source Code
Repository

82. アプリ設定による環境固有パラメータ
App Service の“設定” は環境変数から取得できる
.NET アプリの場合 *.config ファイルの値の上書きも出来る
アプリは配置された環境に応じて自動的に挙動を切り替える
82
設定値 設定値 設定値

83. App Service のスケーリング
スケールの調整は App Service Plan で行う
スケールアップ／ダウン は Web Worker インスタンスのスペック変更
スケールアウト／インは Web Worker インスタンスの台数の変更
手動スケールも可能だが自動的スケール機能を使用してコストを最適化する
83
スケールアップ
スケールアウト

84. 容易なユーザー認証の追加
アプリに修正を加えることなくユーザー認証を追加することが
できる
数ステップで指定の認証プロバイダと OpenID Connect による連携が有効になる
Azure Active Directory を使用すると Office ３６５ と同等の SSO が可能
84
スイッチひとつで
認証を追加

85. 障害や不審な挙動の自動診断
「問題の診断と解決」ツールを利用すると、アプリ／プラット
フォームのいずれに問題があるのかを素早く切り分け、よくあ
る問題に対する解決策・対処方法がすぐに得られる
85

86. 性能監視と解析
Application Insights を有効化することで様々なログが自
動取得され稼働監視や性能解析が容易に行える様になる
86

87. 87

88. 目的別に選べる ３ 種類の SQL Database
88
予測可能なワークロード
データベースレベルのサービス
ハイパースケール
サーバーレス
マルチテナント アプリケーション向け
リソースを共有し効率的に使用
SQL Server との高い互換性
SQL Server 2005 以降
からの直接移行
インスタンスレベルのサービス
タイムゾーン指定
DTU モデル（Basic/Standard/Premium）
vCore モデル （General Purpose/Business Critical） ※ SQL Server 向け Azure ハイブリッド特典利⽤可
Hyperscale
Serverless

89. 柔軟なスケーリング（２つの購入モデル）
DTU モデル
CPU, Memory, I/O 性能のパッケージング指標
単一パラメータでの監視及びスケール調整
データベースの専門家がいない場合に便利
サービスレベル：Basic/Standard/Premium
vCore モデル
従来型の性能設計と調整を行うためのモデル
コンピューティングとストレージを個別に選択可能
SQL Server ライセンスの持ち込みが可能
サービスレベル： General Purpose/Business Critical
89Compute
Storage
Compute
Storage

90. SQL Database の信頼性
ユーザーからは１つのデータベースに見えるが、内部的には
3 のノードにレプリカが取られている
サービスレベルによって内部アーキテクチャは若干異なる
90
P
S
S

91. Standard 可用性モデル
Basic / Standard （DTU）および General Purpose
（vCore）サービスレベルは下記のアーキテクチャを採用
Compute と Storage を分離（ステートレス＋ステートフル）
Azure Service Fabric を使用して Compute レイヤーの可用性と冗長性を制御
ログやデータファイルを Azure Storage に格納することで可用性と冗長性を担保
91
P
MDF
LDF
MDF
LDF
MDF
LDF
Cache
App
~2ms for all data access

92. Premium 可用性モデル
Premium（DTU）および Business Critical（vCore）サー
ビスレベルでは下記のアーキテクチャを採用
ログやデータファイルは各ノードにアタッチされたローカル SSD に配置することで低レイテン
シ・高IOPSを実現（バックアップはリモートストレージ）
Always On Availability Group を利用してプライマリノードへの変更はセカンダリレプリカ
（最大３つ）に対して同期される
92
P
App
S SMDF
LDF
MDF
LDF
MDF
LDF
Backup Backup
BackupBackup
Backup
Backup
<0.5ms for all data access

93. データの自動バックアップと時刻指定リストア
ポイントインタイムタイム リストア
完全（週次）、差分（数時間）、トランザクションログのバックアップ（5~10分）が自動的に行
われ、地理的冗長ストレージ内で管理される
リテンション期間（7~35日）の任意のタイミングのデータベースを復旧することが出来る
更に長いリテンション期間が必要な場合も対応可能（プレビュー中）
93
完全バックアップ（週次）
差分バックアップ（数時間）
差分バックアップ（数時間）
差分バックアップ（数時間）
Tx
Log
Tx
Log
Tx
Log
Tx
Log
Tx
Log
Tx
Log
Tx
Log
完全バックアップ
差分バックアップ
差分バックアップ
差分バックアップ
Tx
Log
Tx
Log
Tx
Log
Tx
Log
Tx
Log
Tx
Log
Tx
Log

94. 広域災害対策
アクティブ ジオ レプリケーションを有効化することで、最大４つ
の Azure リージョンに読み取り専用のレプリカを保有
前述の RAーGRS はログバックアップの転送が行われないため、数時間程度のトランザク
ション消失が起こりうる
94
プライマリ
（読み書き可能）セカンダリ
（読み取り可能）
最大 4 つ
P
S
S
P
S
S
Region 内
ログ転送（同期）
Region 間
ログ転送（非同期）

95. インテリジェンス
セキュリティ機能、監査機能、チューニング支援機能などを幅
広く提供
95
脅威検出機能
監査ログ書き
込み
機密データの
安全性確保
チューニング
支援
透過的データ
暗号化

96. データ同期
複数のクラウドおよびオンプレミス間
でデータを同期
ハイブリッドデータ同期ソリューションや分散アプリケー
ションの構築に
96
同期対象データに関する要件や制約を要確認
https://docs.microsoft.com/ja-jp/azure/sql-database/sql-database-sync-data

97. SQL Database Hyperscale
100TB級 の DB サイズをサポート
サイズに関係ない瞬間的なバック
アップ
スナップショット利用
数分単位での迅速な復元
Azure SQL Database との完全な
互換性
97

98. SQL Database Serverless
固定的にプロビジョニングされたコンピューティングを持たな
いサーバーレスモデル
コンピューティングリソースのCPU使用時間に応じて秒課金
オートスケールとアイドル時間に応じた自動停止
98
最大 16 vCore
最小 0.5 vCore
CPU使用率
自動停止
課金なし

99. プール内のデータベースは DTU を共有。支払い金額は DTU に応じて一定であり、
パフォーマンスを管理しながらコストを簡単に計算
Elastic Pool
できること
データベースに必要なパフォーマンス リソースを
必要なときに確実に確保
シンプルなリソース割り当てメカニズムと予測可
能な予算を提供
お客様のメリット
データベースを分割することで、データ量に応じて
スケールアウトすることができます。
複数のデータベースの管理が簡素化されるだけ
でなく、通常は予測不可能なワークロードの予算
が予測可能になります。
サービス階層 プールあたりの最大データベース数* プールあたりの最大 eDTU*
基本 200 1200
Standard 200 1200
Premium 50 1500
*プールあたりのデータベースと数とプール eDTU の数の現在の上限は増えることが予想されます。
99

100. SQL Server オンプレミス (Enterprise Edition) との 100% 近い互換性を備え、VNETに
完全配置できる SQL Database
Managed Instance
できること
オンプレミスまたは IaaS のアプリ、自社ビルドの
アプリ、または ISV 提供のアプリをできるだけ少
ない移行作業でVNETに配置しつつ、クラウド化
することができます。
お客様のメリット
完全な VNET 配置によりセキュリティポリシーの
厳しい状況でも既存システムを少ない移行作業
でクラウドシフトできます
100

101. 最大ストレージサイズ
101
2GB 1TB 4TB 8TB 64TB 240TB
• Premium
• General Purpose
• Business Critical
• Basi
c
• Standar
d
• Hyperscale
～100 TB
GA
※ プールの上限内で
1DB あたり
• Business
Critical • General Purpose
Elastic Pool
Single

102. 購入オプション
102
Sigle Database Elastic Pool Managed Instance
DTU
Basic 5 DTU
100MB 〜 2GB Storage
50 〜 1600 eDTU
(0 〜 5 DTU/DB)
4.88GB 〜 156.25GB Storage
N/A
Standard 10 〜 3000 DTU
100MB 〜 1TB Storage
50 〜 3000 eDTU
(0 〜 3000 DTU/DB)
50GB 〜 4TGB Storage
N/A
Premium 125 〜 4000 DTU
100MB 〜 4TB Storage
125 〜 4000 eDTU
(0 〜 4000 DTU/DB)
50GB 〜 4TGB Storage
N/A
vCore Gen4 Gen5 Gen4 Gen5 Gen4 Gen5
General Purpose 1 〜 24 vCore
〜 168 GB Memory
〜 4TB Storage
2 〜 80 vCore
〜 408 GB Memory
〜 4TB Storage
1 〜 24 vCore
(0 〜 24 vCore/DB)
〜 168 GB Memory
〜 4TB Storage
2 〜 80 vCore
(0 〜 80 vCore/DB)
〜 408 GB Memory
〜 4TB Storage
8 〜 24 vCore
32GB 〜 8TB Storage
4 〜 80 vCore
32GB 〜 8TB Storage
Business Critical 1 〜 24 vCore
〜 168 GB Memory
〜 4TB Storage
2 〜 80 vCore
〜 408 GB Memory
〜 4TB Storage
2 〜 24 vCore
(0 〜 24 vCore/DB)
〜 168 GB Memory
〜 4TB Storage
4 〜 80 vCore
(0 〜 80 vCore/DB)
〜 408 GB Memory
〜 4TB Storage
8 〜 24 vCore
32GB 〜 1TB Storage
4 〜 80 vCore
32GB 〜 4TB Storage
Serverless N/A 0.5 〜 16 vCore
2 〜 48 GB Memory
1GB 〜 3TB Storage
N/A N/A N/A N/A
Hyperscale 〜 24 vCore
〜 168 GB Memory
〜 １００TB Storage
〜 80 vCore
〜 408 GB Memory
〜 １００TB Storage
N/A N/A N/A N/A

103. 見積もり例
103
項目 スペック 単価 数量 月額料金
Web サーバー
App Service Plan S2 : 2 vCPU , 3.5 GB Memory ¥19,295.36/月 4 77,181.44
DB サーバー
SQL Database P4 : 500 DTU, 500GB Storage ¥115,486.00/月 1 115,486.00
追加ストレージ ¥19.04/GB/月 500 9,520.00
ネットワーク
送信データ転送 ゾーン２ : 5TB ¥13.44/GB 5120 68,812.80
上記は2018年5月時点での東日本リージョンの料金を元に算出
最新の料金表は以下を参照
https://azure.microsoft.com/ja-jp/pricing/
※ 送信データ転送の最初の 5GB は無料
月額 271,000.24

104. 104

105. PaaS は安い？
単純にプラットフォーム料金だけで考えると安くはない（むしろ
高い）
例）App Service の Premium v2 プランは 仮想マシンの Dv2 シリーズ相当
P3v2 ： 4core, 14 GB RAM ¥77,181.44/月
D2v2 ： 4core, 14 GB RAM ¥26,244.96/月
PaaS ≠ “ミドルウェアがセットアップ済みのサーバー”
例） App Service に含まれていて VM には含まれないもの
デプロイメントエンジン、サーバー間共有ストレージ、障害監視と自動フェイルオーバー、オートスケール、デプロ
イメントスロット、A/B テスト、HTTPS 暗号化通信、アプリケーションバックアップ、etc…
IaaS に対して PaaS 相当の機能性や品質を求めるならば、自力で設計・構築・テスト・運用
するための費用が別途必要になる
105

106. PaaS は高い？
“as a Service” のスコープが広くなれば、料金設定は高くなる
多少の構成オプションは与えられるが、基本的にベンダー定義の”サービス”を利用する
106
ストレージ
サーバー
ネットワーク
OS
ミドルウエア
ハイパバイザ
ランタイム
アプリケーション
データ
IaaS PaaS
ストレージ
サーバー
ネットワーク
OS
ハイパバイザ
ランタイム
アプリケーション
データ
ミドルウエア

107. IaaS と PaaS の連携
基本的に PaaS 系サービスは Public IP アドレスおよびイン
ターネットに公開されている
これに対し仮想マシン等の IaaS 系サービスは仮想ネットワーク単位でネットワークが分離さ
れているため、（意図的に構成しない限り）外部からのインバウンド接続を受けることはない
107
IaaS
PaaS

108. IaaS to PaaS
既定では VNET 内からの Public IP アドレスへの送信接続はシ
ステムルートを使用して SNAT 接続される
実際には Azure ネットワークから出ることはなく公衆インターネット経由になるわけではない
VM に PIP や PIP が割り当てられた LB/FW での接続も可能（送信元IPが絞れる）
Service Endpoint / Private Endpoint を使用することでPIP を使用しない絞り込みが可能
108
IaaS
PaaS

109. PaaS to IaaS
仮想ネットワーク内のリソースには直接アクセスできないため、
専用の構成が必要になる
下記 ① のパターン以外はサービスによって提供されているオプションが異なるため注意
109
IaaS
PaaS

110. PaaS を IaaS にデプロイする
いくつかの PaaS 系サービスは VNET へのデプロイが可能
App Service Environment, SQL DB Managed Instance, Etc…
110

111. PaaS で IaaS を強化する
運用負荷を軽減するための運用・管理系のサービスも組み合
わせて使用するとよい
仮想マシンだけではなく実はオンプレミスのサーバーにも対応している
PaaS の対応は部分的な場合があるので要確認
111

112. Web Apps for Windows への移植と留意事項
環境制約
MSI インストーラによるアプリインストール不可
RDP による接続不可
レジストリへの書き込み不可（読み込みは可）
ファイルアクセス
ローカル書き込みは d:¥home, d:¥local のみ可
ファイル共有へのアクセス不可
ネットワーク
80, 443 以外でのアクセス不可、localhost アクセス不可
生の Socket 利用不可
ゲートウェイ（ロードバランサ）は 230 秒でタイムアウト
国際化対応
既定のタイムゾーンは UTC （変更可）
既定のロケールは en-us （web.config で変更
可）
ログ出力
イベントログ出力は eventlog.xml にリダイレクト
PDF 出力
環境・ソフトウェアの組み合わせによって不可の場
合あり
112
PaaS 環境は「とりあえずやってみる」ことが容易なため、
まず何も考えずに移植して様子を見るところから始めるとよい

113. SQL Database への移植と留意事項
最新の DB エンジンのみが利用可能
タイムゾーンとロケールが en-us,
UTC 固定
SQLCLR の利用不可
分散トランザクションの利用不可
リンクデータベースの利用不可
T-SQL の一部が利用不可
システムストプロやシステムテーブル
の一部が利用不可
サービスブローカーの利用不可
ヒープの利用不可
SQL Agent, SQL Profiler の利用不
可
レプリケーションの利用不可
Windows 統合認証の利用不可
TCP/IP 接続以外は利用不可
既定の分離レベルが RCSI
DB の最大容量が 4TB
（オンプレミスに比べて）フェイルオーバが
起こりやすい
113
ほとんどの制約事項は Managed Instance であればなくなる or 緩和される
https://docs.microsoft.com/ja-jp/azure/sql-database/sql-database-paas-vs-sql-server-iaas

114. 仮想マシンへの移植戦略
114
OS
MW
App & Data
OS
MW
App & Data
Hyper-V

115. 新規構築は Azure Marketplace から
Microsoft を含む各ベンダーから様々な VM イメージが提供され
ている
数分で OS セットアップ済みの状態で起動してくるため、ソフトウェア導入や構成変更等を行うだけで
利用可能な状態になる
アプリケーションまで導入済みのイメージもあるため、そちらを利用できる場合には構築の手間をかな
り省くことができる
https://azuremarketplace.microsoft.com/ja-jp/marketplace/
115

116. 仮想ディスク (VHD) の持ち込み
Hyper-V 等を使用して作成した仮想ディスクを Azure に
アップロードして利用することもできる
OS だけではなくアプリケーションやデータごと Azure に持ち込む
Windows / Linux ともに事前に “Azure に対応させる” ための準備が必要になる
https://docs.microsoft.com/ja-jp/azure/virtual-machines/windows/prepare-
for-upload-vhd-image
https://docs.microsoft.com/ja-jp/azure/virtual-machines/linux/upload-vhd
116

117. Migration as a Service
Azure Site Revovery は災害対策だけではなく移行ツール
としても利用可能
117

118. オンラインデータ転送
基本的にストレージアカウントへ転送後、データを利用する
サービスへ Azure 内で転送するとよい
自社環境のインターネット帯域を消費するため、容量や実施時間に留意する必要がある
既存ストレージと作業端末を経由した V 字コピーとなる
118

119. オフラインデータ転送
時間、ネットワークの利用、コストに制限がある場合は
DataBox Family のオフライン転送製品を使用
119※ アップロード後は、NIST Special Publication 800-88 revision 1 標準に従ってデバイスが完全にワイプ

120. 120

121. 構築作業のイメージ
121

122. 122

123. Why Container ？
123
‘Write-once, Run-anywhere’
マイクロサービス アーキテクチャ対応
Dev/Test の効率化
確実な Production 環境の配置
Developer Community の成⻑
アプリケーションのポータビリティ
開発, QA, 運⽤環境の標準化
OS やインフラ環境の抽象化
リソース配分の最適化
⾼速起動、スケーラビリティの確保
DevOps
Developers
Operations

124. 仮想マシン vs コンテナー
124
ハードウェア
ハイパーバイザー (Hyper-V、vSphereなど)
仮想マシン 仮想マシン
OSカーネル
OSカーネル
コンテナー コンテナーランタイム/ライブラリー
アプリ
ランタイム/
ライブラリー
ランタイム/
ライブラリー
アプリ アプリ
コンテナーイメージ

125. Docker コンテナー
UNIX、BSD、Linuxの世界でコンテナー技術は昔からあった
OSの各種リソース管理機能を活用してリソースを分離する
dotCloud (現 Docker) 社が自社 PaaS 向けに作ったコンテナー
の仕組みを OSS にしてブレイク
アプリ開発者視点でうれしい機能、周辺ツールに力を入れている
イメージ作成、配布の仕組み、差分イメージ形式など
標準化の勢いで Docker の影響力は
弱まりつつあるが広く普及している
125
OS カーネル
コンテナー コンテナー
ランタイム/
ライブラリー
ランタイム/
ライブラリー
アプリ アプリ
+周辺ツール
コンテナーイメージレジストリから コンテナーを Pull して Run すれば環境ができる

126. Container eco-system
126
ubuntu:17.04
FROM ubuntu:17.04
RUN apt-get –y update
RUN apt-get install
nginx
MyWeb:1.0
MyApp:1.0
FROM MyWeb:1.0
RUN git clone
https://...
RUN dotnet build …
RUN dotnet run …

127. 127

128. コンテナという選択肢
More Control
Less Agile
Less Control
More Agile

129. 共通デプロイ単位としての Docker Container
129
Optionsofcompute
Azure Web App for Containers
Service Fabric
Ma en
Azure Kubernetes
Service (AKS)
Leverage the Azure platform
designed for your container needs
Keep using the platform of your choice,
running great on Azure
Azure Container Registry
Docker Hub, private
registry
Visual Studio tools InteliJ Jenkins
Redhat Openshift Container
Platform
Kubernetes

130. IaaS の自由度 ＋ PaaS の利便性
130
Infrastructure
Host OS
Docker
Infrastructure
Host OS
Docker
Infrastructure
Host OS
Docker
ストレージ
サーバー
ネットワーク
OS
ミドルウエア
ハイパバイザ
ランタイム
アプリケーション
データ
ストレージ
サーバー
ネットワーク
OS
ハイパバイザ
ランタイム
アプリケーション
データ
ミドルウエア
Container PlatformIaaS PaaS
ミドルウェア
ランタイム
アプリケーション
データ
Container
Scalability, Reliability, Portability,
etc…
依存関係地獄
からの解放
開発制約条件
からの解放

131. 主にアプリケーション用途
（不可能ではないが）コンテナにデータを保持すべきではない
永続性の必要な “データ” は Docker エコシステムを活かした CI/CD と相性が悪い
せっかくクラウドを使うならば PaaS 系のデータサービスに任せてしまった方が良い
131

132. Azure Container Instances
サーバーレス型コンテナ実行環境
仮想マシンやホスト OS などを気にせずコンテナを直接 Azure
にデプロイ
内部的には Microsoft が管理する Kubernates クラスタ環
境上で動作している
最大 4vCPU + 7GB Memory を割り当て
132
$ az container create -g acidemo --name nginx --ip-address public --cpu 2 --memory 5
--image microsoft/aci-helloworld
docker run の代わりに

133. Public / Private Container Registry
Docker Hub
Docker 社が運営するコンテナを公開・共有するた
めのサービス
各企業が提供する公式イメージなども多く公開され
ている
個人利用も可能（無償）
https://hub.docker.com
Azure Container Registry
コンテナイメージを共有するための Azure の 1 サー
ビス（有償）
アクセスコントロールによって非公開のレジストリとし
て使用する
https://myreg.azurecr.io
133

134. Production
QA
コンテナ開発サイクル
134

135. PaaS 中心のアーキテクチャにおける課題
サービスの粒度が細かくなると数が多くなり、独立することで
コストや管理性で不利な面が出てくる
選択したクラウドで適切な PaaS サービスが提供されていない可能性も考えられる
135
￥
￥
￥
￥
￥
デプロイ方式や監
視方法が異なる
デプロイ方式や監
視方法が異なる
類似サービ
スが重複
類似サービ
スが重複
テストやステージング
用途の複数の環境

136. コンテナ技術を活用した集約
相互の独立性を維持しつつ、コストに直結しやすいスケールと
可用性を共有したいが・・・
136
コンテナの
正常性
インスタンス
の数と配置
データの
永続化
インフラの
スケール
障害時の
再配置
リソース配分

137. コンテナ オーケストレーター
デファクトの Kubernates をマネージド
サービスとして提供
AKS : Azure Kubernates Service
137
Kubernetes core concepts for AKS
https://docs.microsoft.com/azure/aks/concepts-clusters-workloads

138. 138

139. 従来型デプロイ方針の課題
本番稼働系へのアプリケーションデ
プロイはリスクを伴う
メンテナンスによるシステム停止を許容する？
休日・夜間などでシステム停止リスクを低減する？
差分ベースの構成管理によるシス
テム再現性の低下
秘伝のタレ化することで保守性が下がる
スケール変更や移行性にも問題が起こりやすい
デプロイ失敗時に巻き戻しが困難
139
初期
保守
保守
保守
保守
保守
OS
MW
App v1
V2 Update
V3 update
patch
patch
Config
Config
Config
Bug Fix
Bug Fix
Bug Fix
Bug Fix
開発者 エンドユーザー
ダウンタイム！連休はアップデー
トのチャンス！
vs
※ CI/CD を安定させ、カットオーバーのリスクを低減、ゼロダウンタイムでのリリースを目指す

140. CI/CD パイプライン
Blue / Green デプロイメント
高リスクな本番系へのデプロイを避け別環境へデプロイ
ステージ環境ならユーザー影響なくいつでもデプロイでき、品質確認後に本番系と入れ替え
安定した状態でルーティングを切り替えるだけなのでダウンタイムも極小
140
v1
v2
v2 update
v3
Production
Staging

141. イミュータブル インフラストラクチャ
台帳と差分ベースの構成管理は大変なので辞める
アプリとインフラの構成は変更できない（イミュータブル）ものと考える
クラウドの特徴である「必要な時に必要なだけ利用できる」というオンデマンド性を活用
システムの再現性を高める Infrastructure as Code が重要になってくる
141
Version 1
Version 2
Version 3
新規環境と
してデプロイ
品質確認後
に切り替え
新規環境と
してデプロイ
弄らない

142. Azure の管理概念
リソース
Azure が提供する Web サイト、クラウドサービ
ス、データベース、ストレージ、ネットワーク、仮想
マシン、といったサービス
アクセス権設定の最小単位でもある
リソースグループ
複数のリソースを束ねて管理するためのモノ
複数のリージョンのリソースをグルーピングする
ことが可能
サブスクリプション
アクセス権と課金を分離するためのコンテナー
142
リージョン: 東日本
サブスクリプション
リージョン: West US
リソースグループ リソースグループ
リソースグループ

143. Azure におけるデプロイ手法の選択肢
143
Azure Resource Manager Rest API
仮想マシン Web App SQL DB Etc…
Azure PowerShell
Azure CLI
SDK
C#, Node, Python, etc
OSS,
3rd Party
ユーザーインタラクティブ

144. Azure Portal
Azure のリソース管理手法はいくつかあるが、まずは Azure
Portal から入るのが分かりやすい
https://portal.azure.com
144

145. Azure のコマンドラインツール
大量作成などはスクリプトによる自動化が有効
シェルとして対話的に使用することももちろん可能
Azure PowerShell
https://azure.microsoft.com/ja-jp/documentation/articles/powershell-install-configure/
Azure CLI
https://azure.microsoft.com/ja-jp/documentation/articles/xplat-cli-install/
145

146. Azure Cloud Shell
インストール不要で使えるブラウザベースのシェル環境
146
https://shell.azure.com

147. Azure Resource Manager
147
展開グループ化 制御
• テンプレートによる展開
• 宣⾔型／べき等性
複数のリソースを束ねる
論理的な器
• 役割ベースのアクセス制御
• タグ付け

148. Infrastructure as Code の時代に
インフラ管理の効率とスピードの向上
インフラ設計の共有・再利用
Azure での実装 ＝ Azure Resource Manager (ARM)
(*) 従来の Azure 管理モデルは、ARM との対比で Azure Service Management (ASM) と呼びます

149. Azure Resource Manager Template
低水準言語に相当するため利便性は若干犠牲になるが、Azure の
機能がフル活用できる
149
Azure Resource Manager Rest API
仮想マシン Web App SQL DB Etc…
テンプレート
システム構成を
定義した
JSON 形式ファイル
パラメータ
JSON
or コマンドライン
or ポータル入力

150. ARM テンプレートの特性
処理⼿順ではなく結果状態を記述
何度繰り返しても同じ結果を保証
これからのシステム構築・管理モデル 実装手段（例）
Infrastructure as Code Azure Resource Manager
Configuration as Code Chef, Puppet, PowerShell DSC

151. ARM による IaC の実現
151
複数リソースから構成される
複雑なシステムを、
JSON 形式のテンプレートファ
イルで表現して展開

152. システム構成の管理に
152
v1 v2 v3
初期構成
Web 2台 + DB 2 台
DBのスケールアップ
D4s_v3 ⇒ D8s_v3
Webのスケールアウト
Web 2台 ⇒ 4 台
LB の構成変更
Azure Resource Manage

153. システム ランドスケープの構築に
153
Template
Azure Resource Manage

154. 広域災害対策やグローバル分散構成に
154
Template
AzureResourceManager

155. Quick Start Template
155
公開（共有）されたテンプレートを使って、
数ステップで Azure 上に ⽬的の環境を構築可能
Deploy
to Azure

156. 実環境からの ARM テンプレート出力
https://azure.microsoft.com/en-us/blog/export-templa

157. ARM Rest API の直接操作
Azure Resource Explorer
https://resources.azure.com
157

158. 158

159. 異なる視点と悩み
管理者の悩み = Governance
開発者に任せてセキュリティ事故を起こすのは避けたい
社員の ID 管理・運用の複雑化は避けたい
勝手にクラウドを使われてしまっては困る
159
開発者の悩み = Productivity
利用サービス毎に ID を切り替えて使うのは面倒
ID 管理・運用の対するノウハウや知見が少ない
セキュリティよりも本業のサービス開発に注力したい

160. （Azure だけではない）情報資産保護と認証
160
Azure VSTS
AD連携
多要素認証
レポート
Azure Active Directory
Office
365
Other
Clouds

161. Azure AD 対応の SaaS アプリケーション
161

162. 162

163. Azure におけるデプロイ手法の選択肢
163
Azure Resource Manager
仮想マシン Web App SQL DB Etc…
Azure PowerShell
Azure CLI
SDK
C#, Node, Python, etc
OSS,
3rd Party
ユーザーインタラクティブ

164. 複数のアクセス制御レイヤ
ARM レベルでのアクセス制御が破たんした場合の影響範囲
は広く、被害が甚大なものになりうる
164
OS
Web Server
Application
アプリ認証
と認可
OS の制御機構
Admin/root
Azure AD
RBAC

165. ミスオペや不正操作を防ぐために
認証・認可、アクセス制御、監査の仕組みが重要
165
いつ誰が
何をしたか？

166. 認証と認可 – Authentication & Authorization
Azure を利用するためには Azure Active Directory によ
る認可が必要
Azure AD によって発行されたアクセストークンが無いと Azure を利用することができない
https://docs.microsoft.com/ja-jp/azure/active-directory/
166

167. RBAC
アクセス制御 – Access Management
Azure の各種リソースに対するアクセスは RBAC によって制
御される
RBAC : Role Based Access Control は リソースグループやサブスクリプション粒度での
アクセス制御が可能
https://docs.microsoft.com/ja-jp/azure/role-based-access-control/
167
サブスクリプション
リソースグループ リソースグループ

168. 監査 - Auditing
各リソースに対して行われた操作はアクティビティログに記録
され、監査することが出来る
主にアクティビティログの“管理”カテゴリが監査ログに該当する
出力されたログ内容を元にアラートを発報することも可能
https://docs.microsoft.com/ja-jp/azure/monitoring-and-diagnostics/monitoring-overview-
activity-logs
168

169. 最小特権・職務分離の原則
Azure を利用する各ユーザーがアクセス可能なリソースや実
行可能な操作は必要最低限にすべき
不正アクセスが成功してしまった場合の影響範囲の局所化
正規ユーザーの不用意な操作によるシステム破損や情報漏洩を防止
169
グループ or ユーザー Web App SQL Database Resource Group
インフラ構築担当 当該リソースグループのみフルアクセス可能
アプリ保守担当 なし なし なし
運用担当 参照とスケール操作 なし なし
監視担当 参照のみ 参照のみ 参照のみ
スコープによる分離

170. 説明責任を果たすために
監査ログを適切に取得・分析できるようにしておくことが非常
に重要
コンプライアンス要件を満たした運用を証明する
インシデント発生時に事実確認や報告資料
システム運用改善の材料
複数人で ID を共有せず、必ず個人を特定できる ID を利用
すること
適切に監査ログが取られることは不正操作の抑止力にもなり、また（不正を行っていない）利
用者の潔白を証明することにも繋がる
複数人に同一権限を持たせるためには Azure AD のグループに対して RBAC を付与すれ
ばよい
170

171. 171

172. Azure における管理対象とロール
172
アカウント
サブスクリプション
リソースグループ
リソース

173. Azure サブスクリプションの管理
サブスクリプション
＝課金用のコンテナー
＝セキュリティ境界
アカウントポータル
サブスクリプションの管理・運用はアカウントポー
タルで行う
https://account.azure.com/subscriptions
サブスクリプションの作成・名前の変更・廃止・譲渡、サー
ビス管理者・共同管理者の更新、etc…
自アカウントの利用状況データ・アカウント課金データの
表示などもこちらから行う
173

174. リソースおよびリソースグループの管理
実際のサービス利用は Azure
ポータル から行う
https://portal.azure.com
サービス管理者や共同管理者は全てリソースに対
する任意の操作が可能
管理から権限の委譲を受けた（＝サブスクリプショ
ンにアクセス権を持つ）全てのユーザーが利用
コア数クォータの増加や利用可能リージョンの拡
大等のサポートへの問い合わせもこちらから行う
※初期状態ではサービス管理者＝アカウント管理
者の状態なので混同しやすい
174

175. ポータルの使い分け
アカウントポータル（https://account.azure.com）
当該アカウントに所属するサブスクリプションを作成、管理者の任命、契約内容や確認といったような
トップレベルの管理に使用する
Azure ポータル（https://portal.azure.com）
自信がアクセス権を持つ複数のサブスクリプションにおいて、実際に Azure サービス（リソース）を作
成、運用するために使用する
175
アカウント
サブスクリプション サブスクリプション
アカウント
サブスクリプション サブスクリプション
アカウントポータル
Azure ポータル

176. 段階的な権限の移譲
アカウント管理者はサービス管理者に権限を委譲する
サブスクリプション作成時は同一人物だが、極めて強い権限を持つため分離を推奨
特に複数サブスクリプションを保有するケースでは影響範囲も大きくなる
176
本番運用
サブスクリプション
テスト環境用
サブスクリプション
開発環境用
サブスクリプション
RBAC
RBAC
RBAC
アカウントポータルで実施 Azure ポータルで実施

177. Azure 利用者の ID 管理
各サブスクリプションは必ず１つの Azure AD テナントと関連
付けられる
サブスクリプションは「アカウント管理者」が属するテナントに関連付けられる
このテナントに登録された ID 情報を元にアクセス制御（RBAC）を行う
177
サブスクリプション
リソースグループ
リソース
リソース
信頼

178. 複数の Azure 環境の使い分け
1 人の開発者が複数のサブスクリプションにアクセス権を持
つようになると注意が必要
Azure ポータルへのログイン情報を元にユーザーがアクセス可能なディレクトリおよびサブス
クリプションが自動的に特定されるが、1つとは限らない
各ユーザーは適切なサブスクリプションを操作していることを確認しながら利用する必要があ
るが、事故を防ぐためにも適切な権限分離は非常に重要
Azure ポータルのフィルタ機能や、リソース作成時のサブスクリプション指定を確認、
PowerShell によるスクリプト実行時にはサブスクリプション指定を必ず行うこと
178
個人環境
運用環境２
運用環境１
開発検証環境

179. 管理体系の変更
アカウント管理者はサービス管理者の変更だけでなく、サブス
クリプションを譲渡することが可能
譲渡した場合にはサブスクリプションに関連付けられるディレクトリは譲渡先のアカウント管理
者の所属先になる
双方のアカウント管理者が異なるディレクトリに所属している場合には、ID 管理が変更にな
るためアクセス制御に影響があることに留意
179
サブスクリプション
サブスクリプション

180. 180

181. Azure 利用者 ID は Azure AD で管理
Azure の RBAC で管理しているのはあくまでも “ロール” と
その ”アサイン”
181

182. Azure AD の管理も Azure ポータルで実施
Azure の各種サービスと一緒に Azure AD が表示されるの
で大変ややこしい
182
“全体管理者” などのディレクトリロールが割り当てられていれば
各種の操作が可能（これは RBAC ではない）

183. Azure AD によるユーザー認証
認証をよりセキュアにするために多
要素認証を有効に
仮にパスワードが漏洩しても “正規ユーザーが
持っているはずのもの” が無いと認証が通らない
ユーザーではないサービスプリンシパルには適用
できないので注意
ユーザーのサインイン履歴のレポートも
利用可能
サインインは全て記録され管理者が確認することができ
る
リスクが高いと判断されたサインインは自動的に警告さ
れる
183
https://docs.microsoft.com/ja-
jp/azure/active-directory/reports-
monitoring/overview-reports
https://docs.microsoft.com/ja-jp/azure/active-
directory/authentication/concept-mfa-howitworks

184. パートナーの ID 管理に Azure AD B2B
自社の Azure AD に協力会社のメンバーを招待できる
前ページの“新しいゲストユーザー” を使用して ID を登録
招待されたユーザーに対しても同様に RBAC によるアクセス制御が可能
https://docs.microsoft.com/ja-jp/azure/active-directory/active-directory-b2b-what-is-azure-ad-
b2b
184
Azure
Active Directory
Azure 管理コンソール・
PowerShell／コマンド

185. 一般ユーザーから見た Azure AD
ディレクトリロールが割り当てられていない一般ユーザーも
（制限されていなければ）参照は可能
新規ユーザー登録などは当然できない
185

186. Azure に対応したユーザー ID の種類
Azure を利用する際には 2 種類の ID が使用できる
職場または学校アカウント（＝Azure AD で管理された ID）
企業や教育機関において管理者が発行・管理する ID
Office 365 等の企業向けクラウドサービスの ID 基盤としても利用される
組織の Azure AD テナントが既に利用できる場合にはこちらを利用すべき
Microsoft アカウント（MSA、旧称 Windows Live ID）
コンシューマー向けサービスを利用する際に個人的に作成・使用する ID
MSA は既定のディレクトリに存在しなくても SA / CA や RBAC の権限を割り当てることが出来る
職場または学校アカウントが無い場合はサインアップ時にこちらを使用せざるを得ない
（MSA で Azure にサインアップした際にはディレクトリが自動作成されている）
186
サブスクリプションA
サブスクリプションA
fuga@outlook.com

187. ここまでは主に “人” の話
187

188. サービスプリンシパル
Azure AD では（人ではない）サービスプリンシパルと呼ばれ
る ID を登録することが出来る
クラウドの導入目的として「管理や運用の自動化」が挙げられることが多い
必ずしも人間が Azure の操作を実施する必要はない
188

189. サービスプリンシパルを作れる権限
Azure AD に対して ID を登録するため（RBACではなく）
ディレクトリに対する一定の権限が必要
ディレクトリの管理者は当然ながら可能
一般ユーザーでも「アプリの登録」が許可されている場合には可能
189
https://docs.microsoft.com/ja-
jp/azure/azure-resource-manager/resource-
group-create-service-principal-portal

190. サービスプリンシパルの作り方
まず “アプリの登録” を行う
システム用に疑似的に“ユーザー”を追加するわけではない
作成するアプリの種類は “Web アプリ/ API” を選択
ここで自動採番される GUID 形式の ”アプリ ID” がユーザー ID に該当する
登録したアプリに対して “認証キー” を生成する
ここで生成されたキーの値がパスワードに該当する
キーの値は生成のタイミングでしか表示されないため注意
うっかりキーの値を控えそこなった場合には、別のキーを生成して利用する
（キー文字列ではなく証明書や公開鍵による認証も可能）
あわせて Azure AD の “ディレクトリ ID” も控えておく
この “ディレクトリ ID” と前述の “アプリ ID” を合わせて一意になる
190

191. サービスプリンシパルのアクセス権
サービスプリンシパルに対しても（ユーザーと同様に） RBAC
によるアクセス権付与を行う
アクセス制御の方法はユーザーと全く同じ
適切なスコープとロールを選択して付与する
ユーザーと同様に必要最低限のアクセス権のみを付与
サービスプリンシパルはアプリやサービスが Azure を操作する際に認証に使用する＝ユー
ザー不在でログインするため多要素認証ができない
これは前述のキーを知っていれば誰でもログイン出来てしまうことを意味する
キーが漏洩した時に被害を最小限にするために必要最低限であることが重要
191

192. サービスプリンシパルの使い方（Interactive）
192
# スクリプト化する際はハードコードせず外部ファイルなどに切り出しておくこと
PS> $password = ConvertTo-SecureString “キー値” –AsPlainText –Force
PS> $credential = New-Object System.Management.Automation.PSCredeinatil “アプリID”, $password
PS> Connect-AzureRmAccount –ServicePrincipal –TenantId “ディレクトリID” –Credential $credential
Account : サービスプリンシパルのアプリID
SubscriptionName : RBACでアクセス権を付与したサブスクリプション名
SubscriptionId : RBACでアクセス権を付与したサブスクリプションのID
TenantId : サービスプリンシパルを登録したAzureADテナントのディレクトリID
Environment : AzureCloud
#ログインに成功したら付与されているアクセス権の状態を確認してみる
PS> Get-AzureRmRoleAssignment –ServicePrincipalName “アプリID”
RoleAssignmentId : /subscriptions/{guid}/providers/Microsoft.Authorization/roleAssignments/{guid
Scope : /subscriptions/{guid}
DisplayName : service-principal-demo
SignInName :
RoleDefinitionName : Reader
RoleDefinitionId : acdd72a7-3385-48ef-bd42-f606fba81ae7
ObjectId : 78dcffb0-b089-4552-bb8d-73b6e5a7f83b
ObjectType : ServicePrincipal
CanDelegate : False
PowerShell

193. サービスプリンシパルの利用例
193
カスタム運用ツール 自動運用
開発・テスト環境の管理 コンテナプラットフォーム
Runbo
ok
Azure Resource Manager
Runbo
ok
Runbook
Azure Resource Manager
Azure Resource Manager Azure Resource Manager

194. キーの管理が危なっかしい？
194

195. キーの保管と言えば Azure Key Vault ですが
アプリケーションが外部サービス等にアクセスする際のキーや
証明書情報は Key Vault で安全に保管できる
Key Vault にアクセスするためにはやはり認証が必要
つまり Key Vault にアクセスするための別のキーを保管する仕組みが必要
195
データベースにアクセス
するためのキーを保管
機密データ！
Key Vault にアクセスするための
キーはどこに保存する？？？
缶切りが入った缶詰を開けるためにやっぱり缶切りが必要な状態

196. Managed Identity
乱暴に言うと “特定の Azure リソースに直接紐付けられた
サービスプリンシパル”
キーや証明書を持つ任意のユーザ／サービスならサービスプリンシパルを取得できる
＝喪失しないための管理が必要だが、漏洩リスクも存在するので Key Vault に預けたい
MSI を明示的に割り当てられたリソース上で動作するアプリのみが取得できる
＝内部で動作するアプリを除き、外部からキーを取得する方法がないので悪用が難しい
196
データベースにアクセス
するためのキーを保管
機密データ！
この Web App に
割り当てられた MSI

197. MI 対応サービス
2018 年 8 月時点で MI に直接的に対応しているサービス
は限定的（一部プレビュー）であるため注意が必要
ここで言う “対応” とは、MSI の割り当てが可能なサービス（主に Compute 系）と、MSI
を使用したアクセス制御が可能なサービス（主に Data 系）の 2 種類
ただし ARM が対応しているので Azure の MSI 非対応サービスは工夫次第
また Key Vault も対応しているので Azure 以外のサービスであっても工夫次第
197

198. MI 利用イメージ
198
Azure 触れない
アプリ弄れない
// MSIの取得（実行環境への割り当てが必要）
var prvdr = new AzureServiceTokenProvider();
var token = await prvdr.GetAccessTokenAsync(
“https://database.windows.net”);
// MSIの利用（接続先でアクセス許可が必要）
var cnctn = new SqlConnection( constr ) {
AccessToken = token
};
cnctn.Open();
アクセスログ
しか見られない
MI はキーが
取れない
C#（疑似コード）

199. 199

200. ポータルでリソースの状態を把握する
200

201. リソース種別に応じた稼働状態の確認
Web App の場合 SQL Database の場合
201

202. 正常性の確認
202
利用しているリソースの状態を確認
Resource Health
Azure そのものの正常性も確認
Service Health
ポータルにアクセスできない場合は Azure の状態
https://azure.microsoft.com/ja-jp/status/

203. 監視対象のレイヤーとツール
203
ストレージ
サーバー
ネットワーク
OS
ミドルウエア
ハイパバイザ
ランタイム
アプリケーション
データ
ストレージ
サーバー
ネットワーク
OS
ハイパバイザ
ランタイム
アプリケーション
データ
ミドルウエア
Resource Health
Azure プラットフォーム Service Health
従来通りの監視ツールを
導入してもいいが・・・
Managed Service を
使いたいところ

204. Log Analytics
クラウドおよびオンプレミスの環境内のワークロードが生成し
たログデータを収集・管理・分析する
204
Log Analytics
レポジトリ クエリー検索
ダッシュボード
アラート
CSV
Power BI
Microsoft Azure
Windows または Linux
（物理または仮想）
System Center
Operations Manager

205. Application Insight
205
Web アプリの正常性やパフォーマンスを監視・診断するため
のサービス
各言語の SDK を使用してアプリに組み込むことで任意のプラットフォーム・アプリケーション
で使用可能

206. Security Center
セキュリティ診断にも AI の力を活用
206

207. 207

208. XXX as a Service
More Control
Less Agile
Less Control
More Agile

209. なぜクラウドを利用するのか？
209
Why ?

210. クラウドならではのメリット
210

211. クラウドは目的ではなく手段
211
On-Premise
Lift &
Shift
Adaption Optimized Native
REHOST REFACTOR REARCHITECT
REBUILD
( New )
クラウドサービスを使うこと ・ 特定のアーキテクチャを実現することがゴールではない

212. クラウド化の意義（よくある例）
212
現状
の
課題
セキュリティ
高いセキュリティの
確保は勿論のこと様々な
業界標準、コンプライア
ンス対応が必要
人件費
運用の自動化を行って
いないシステムの運用に
かかわる人的リソース人
件費
は最大のコスト要因
サイジング
サイジングが難しく、実
際に必要としているス
ペック以上のスペックの
ハードウェアを導入して
いるケースが多い
災害対策
旧来は災害対策用の環
境が不十分のケースが
多く、バックアップもいま
だにテープにしている
ケースもある
開発/テスト
環境
それほど稼働率が高くな
い開発やテスト用の環境
にも本番と同スペックの
環境が必要
グローバル
オペレーション
海外からのアクセスがあ
るにも関わらずデータセ
ンターの場所が限られて
いる
などなど
HW のコスト
バックアップ/ HA ソ
リューションを備えた従
来の Server /
Storage / Network
ハードウェアは高価

213. 開発・運用担当者にとっての
“クラウド化の意義”は？
213

214. 開発・運用担当者にとっての働き方改革
アプリ
開発者
アプリ
運用者
インフラ
開発者
インフラ
運用者
作る(Dev) 維持する(Ops)
アプリ
インフラ
No
Uncomfortable
Ops
クラウドサービス

215. サービスの進化の系譜とキャッチアップ方針
初学者はまずは基本となる IaaS と PaaS を把握すると良い
歴史的な経緯としてはオンプレミスの課題をクリアすべく IaaS が、IaaS の課題をクリアすべ
く PaaSが、 その課題をクリアすべく CaaS / FaaS が開発・提供されてきている
しかし完全なる置き換えになるわけではなく、現時点でも
オンプレミスや IaaS や PaaS が優位であるケースは多い
このため各サービスの特性とメリット・デメリットを把握して
うまく“使い分け”ることが重要
215
IaaS PaaS
CaaS
FaaS
歴史的には Azure は PaaS から提供が始まり、その後ニーズにこたえる形で IaaS、FaaS、
CaaS を提供してきたが、そこはあまり気にしなくて良い

216. まとめ
クラウドならではのメリットと、そもそもの利用目的を見失わな
いことが重要
Speed, Scale, Economics の最低 1 つ、出来ればすべてを活かすのが理想
使ってみたら意外と「今までとあまり変わらない」という事態に陥りやすい
IaaS / PaaS ともにオンプレミスデータセンターと同じ感覚
で使用すると落とし穴が意外とあるので注意
特に陥りがちなのがネットワーク周りの制御
全体としては多数の利用者に開放されたインフラの 1 テナントであることを意識
適材適所を判断するには、まずは触ってみることが大事
机上の評価ではわからないことも多い
216

217. Next Action
無償評価版
1ヶ月 22,500 円分の Azure クレジットをご利用いただけます
https://azure.microsoft.com/ja-jp/free/
Visual Studio サブスクライバー
月額 6,000 円～ 17,000 円の Azure クレジットの権利を有しています
https://azure.microsoft.com/ja-jp/pricing/member-offers/credit-for-visual-studio-
subscribers/
まずはお試しください
217

218. Let’s Party !
Pizza as a Service 2.0
218
Tradition
On-Premises
(legacy)
Conversation
Friends
Soda
Pizza
Fire
Oven
Electric/Gas
Homemade
Infrastructure
as a Service
(IaaS)
Conversation
Friends
Soda
Pizza
Fire
Oven
Electric/Gas
Communal Kitchen
Containers
as a Service
(CaaS)
Conversation
Friends
Soda
Pizza
Fire
Oven
Electric/Gas
Bring Your Own
Platform
as a Service
(PaaS)
Conversation
Friends
Soda
Pizza
Fire
Oven
Electric/Gas
Takeaway
Function
as a Service
(FaaS)
Conversation
Friends
Soda
Pizza
Fire
Oven
Electric/Gas
Restaurant
Software
as a Service
(SaaS)
Conversation
Friends
Soda
Pizza
Fire
Oven
Electric/Gas
Party
Configuration
Functions
Scaling...
Runtime
OS
Virtualisation
Hardware
You Manage Vendor Manages
www.paulkerrison.co.uk

219. Microsoft Confidential
n 本資料は情報提供のみを目的としており、本資料に記載されている情報は、本資料作成時点でのマイクロソフトの見解を示したものです。状況等の変化により、内容は変更される場合があります。本資料
に特別条件等が提示されている場合、かかる条件等は、貴社との有効な契約を通じて決定されます。それまでは、正式に確定するものではありません。従って、本資料の記載内容とは異なる場合がありま
す。また、本資料に記載されている価格はいずれも、別段の表記がない限り、参考価格となります。貴社の最終的な購入価格は、貴社のリセラー様により決定されます。マイクロソフトは、本資料の情報に対
して明示的、黙示的または法的な、いかなる保証も行いません。
© 2018 Microsoft Corporation. All rights reserved.
Microsoft, Windows, その他本文中に登場した各製品名は、Microsoft Corporation の米国およびその他の国における登録商標または商標です。
その他、記載されている会社名および製品名は、一般に各社の商標です。