Get Started with Azure v0.9.19.1213

Azure 初学者向けの入門資料です

Transcript

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” “地球上のすべての個人とすべての組織が より多くのことを達成できるようにする”
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. 世界最大規模のインフラ 10 https://azure.microsoft.com/en-us/global-infrastructure/regions/
11. グローバル ネットワーク 11 https://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 17 https://docs.microsoft.com/ja-jp/azure/security/security-management-and-monitoring-overview クラウドを 使用することで確実に 得られるメリット サービスによって 考え方が異なる 従来と全く変わらない 領域
18. コンプライアンス 18 HIPAA / HITECH Act FERPA GxP 21 CFR Part 11 ISO 27001 SOC 1 Type 2 ISO 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 GLOBAL INDUSTRY REGIONAL
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. Azure JAPAN https://www.microsoft.com/ja-jp/business/nowon-azure
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
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
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 などデータを格納するために必要に応じて接続する（追加） 一時ディスク ：仮想マシンの物理ホスト上のローカルストレージを使用するため揮発性（標準） 35 Hyper-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 VM02 VM01 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
45. Design for Failure and Resilience 障害を避けるだけでなく、障害が発生した時 に対応するための仕組みが重要 Data Backup データの破損や削除に備えて、以前の正常な状態に復旧する High Availability 障害時にもダウンタイムを極小化し、システムが健全な状態で継続 稼働することを目的とする Disaster Recovery 広域災害においても迅速なシステムを復旧し、業務継続・サービス 提供することを目的とする 45 Original Backup Primary site Secondary site Primary 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 Recovery High 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
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
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
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
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 89 Compute 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 S MDF LDF MDF LDF MDF LDF Backup Backup Backup Backup 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
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 標準に従ってデバイスが完全にワイプ
121. 構築作業のイメージ 121
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 …
128. コンテナという選択肢 More Control Less Agile Less Control More Agile
129. 共通デプロイ単位としての Docker Container 129 Options of compute 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 Platform IaaS 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
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 Azure Resource Manager
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
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
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
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 サブスクリプション サブスクリプション
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#（疑似コード）
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
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 の米国およびその他の国における登録商標または商標です。 その他、記載されている会社名および製品名は、一般に各社の商標です。