Recommended
More Related Content
What's hot
What's hot (20)
Similar to Azure and cloud native approach.v0.6.19.0807
Similar to Azure and cloud native approach.v0.6.19.0807 (20)
More from Ayumu Inaba
Recently uploaded
Recently uploaded (8)
Azure and cloud native approach.v0.6.19.0807
- 1. Ayumu Inaba Cloud Solution Architect Microsoft Japan Cloud Native with Microsoft Azure 1
- 2. はじめに アプリケーションの実行環境としてのクラウドサービスはその 重要性を増してきていますが、従来のオンプレミス環境の代替 あるいは延長としての取り扱いが多いのも事実です。 しかしクラウドサービスの価値を最大限に活用するためには、 その特性に合わせた “クラウドネイティブ” という考え方も非 常に重要になってきます。 本資料は Microsoft Azure が提供する各種サービスを最 大限に活用することで、クラウドネイティブなアーキテクチャを 実現していくための初歩的な知識を紹介します。 2
- 3. 3 “Empower every person and every organization on the planet to achieve more” “地球上のすべての個人とすべての組織が より多くのことを達成できるようにする”
- 4. Agenda Microsoft Azure 概要 システム開発を取り巻く状況 クラウド時代のシステム設計 Azure リソースの管理 回復性に優れたインフラストラクチャ クラウドサービスの監視 変更容易なサービス 疎結合アーキテクチャ コンテナ技術の活用 サーバーレスサービスの活用 まとめ 4
- 5. 5
- 6. Microsoft Azure 概要 Azure はシステムを構成するために一 般的に必要となる各種の “部品” を提 供するサービスの総称 エンジニアは必要な部品を “組み合わ せ” 、アプリやデータを”配置”することで システム構築する 各部品の特性を活かしたアーキテクチャ を実装することで、クラウドならではメリッ トを享受できる 6
- 7. 7 プラットフォーム サービス (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
- 8. Azure のサービスは IaaS か PaaS に分類される 8 ストレージ サーバー ネットワーク OS ミドルウエア ハイパバイザ ランタイム アプリケーション データ ストレージ サーバー ネットワーク OS ミドルウエア ハイパバイザ ランタイム アプリケーション プ ロ バ イ ダ 管 理 データ IaaS (Infrastructure as a Service) PaaS (Platform as a Service) SaaS (Software as a Service) ストレージ サーバー ネットワーク OS ハイパバイザ ランタイム アプリケーション データ ミドルウエア ストレージ サーバー ネットワーク OS ミドルウエア ハイパバイザ ランタイム アプリケーション ユ ー ザ 管 理 データ オンプレミス
- 11. 所有（オンプレミス）から利用（サービス）へ 利用者は提供されるメニューから必要なものを選んで使う 自分に合ったものが提供される ⇒ ありものを組み合わせて賄う ベンダーに責任を委譲する ⇒ パートナーと協力して作り上げる 11 施設 ネットワーク 物理サーバ 仮想化基盤 仮想OS ミドルウェア アプリケーション エンド ユーザ アプリ 開発部門 IT部門 使う 作る 委譲 作る 作る 委譲 委譲 委託 企業 エンド ユーザ IT部門 ベンダー 使う 作る 作る 協力 企業 選ぶ 支援 所有 利用
- 12. 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 よりもはるかに高い 12
- 13. アーキテクチャの例 13 Enterprise Disaster Recovery Virtual Desktop Infrastructure High Performance Computing
- 14. アーキテクチャの例 14 E-Commerce Website Picture and Movie analytics Predictive Maintenance
- 15. アーキテクチャの例 15 High Availability Web Service リファレンスアーキテクチャは他にもたくさんある https://docs.microsoft.com/ja- jp/azure/architecture/reference-architectures/ Big Data Analytics CI/CD Pipeline
- 17. 混ぜるな危険 17 IaaS と PaaS の ハイブリッドも可能
- 19. 19
- 22. 技術の進化により常識は変わりつつある 128 vCPU ＋ 14TB メモリを搭載 したモンスターマシンがいつでも利用 可能 大規模リソースをオンデマンドに使い、処理が終われば 破棄、縮小 ピークに合わせて高額な設備を購入、維持する必要は ない 22 (例) Azure 仮想マシン Mシリーズ
- 24. 設計思想も変化していく 24 Design for Robustness 堅牢性重視の設計 Design for Failure 故障を前提にする設計 Design for Resiliency 回復性を重視する設計 Monitoring
- 25. ビジネスプロセスも変化 研究 開発 事業化 市場 投入 開発 事業化 市場 投入 開発 事業化 市場 投入 Process Innovation に必要な要素 • タイムリーに最小単位の製品・サービスを市場投入していく 見極めとそれを可能にする仕掛け • Agile ← DevOps ← Lean Startup
- 26. を利用している
- 27. 28
- 29. クラウド成熟モデル 30 On-Premise Lift & Shift Adaption Optimized Native REHOST REFACTOR REARCHITECT REBUILD ( New )
- 30. CNCF Cloud Native Definition v1.0 クラウドネイティブ技術は、パブリッククラウド、プライベートクラ ウド、ハイブリッドクラウドなどの近代的でダイナミックな環境 において、スケーラブルなアプリケーションを構築および実行 するための能力を組織にもたらします。 このアプローチの代表 例に、コンテナ、サービスメッシュ、マイクロサービス、イミューダ ブルインフラストラクチャ、および宣言型APIがあります。 これらの手法により、回復性、管理力、および可観測性のある 疎結合システムが実現します。 これらを堅牢な自動化と組み 合わせることで、エンジニアはインパクトのある変更を最小限 の労力で頻繁かつ予測どおりに行うことができます。 31 https://github.com/cncf/toc/blob/master/DEFINITION.md
- 31. CNCF Cloud Native Definition v1.0 目的、課題意識、実現したいことは従来と大して変わらないが、 昨今の技術を活用して少しでもラクをしよう 32 変更が容易な 疎結合システム 回復性 管理性 可観測性 クラウド サービス コンテナ技術 マイクロサービス サービスメッシュ イミュータブル 宣言型API Etc…
- 33. 34
- 34. Azure の管理概念 リソース Azure が提供する Web サイト、クラウドサービ ス、データベース、ストレージ、ネットワーク、仮想 マシン、といったサービス アクセス権設定の最小単位でもある リソースグループ 複数のリソースを束ねて管理するためのモノ 複数のリージョンのリソースをグルーピングする ことが可能 サブスクリプション アクセス権と課金を分離するためのコンテナー 35 リージョン: 東日本 サブスクリプション リージョン: West US リソースグループ リソースグループ リソースグループ
- 35. Azure のリソース管理手法 36 Azure Resource Manager Rest API 仮想マシン Web App SQL DB Etc… Azure PowerShell Azure CLI SDK C#, Node, Python, etc OSS, 3rd Party ユーザーインタラクティブ
- 36. まずは Azure Portal Azure のリソース管理手法はいくつかあるが、まずは Azure Portal から入るのが分かりやすい https://portal.azure.com 37
- 39. 40
- 40. Azure に備わった耐障害性 データは最低でも 3 つに多重化されている 下記は仮想マシン（IaaS）の例だが、各種 PaaS でも同様 41 3重のレプリカ ストレージ 障害 OS/データ ディスク
- 41. 障害時の自動復旧 : Service Healing ホストやインフラの障害を自動的に検知、復旧が行われるよう に構築・運用されている 下記は仮想マシン（IaaS）の例だが、各種 PaaS でも同様 特に何もしなくても既定でコールドスタンバイ構成が取られていると考えると良い 42 Hyper Visor Host Agent Azure Fabric Controler Devices Hyper Visor Host Agent Devices
- 43. PaaS はさらに高度に : App Service 編 大量のリソースから一部を割り当て負荷分散する仕組み (VMに比べると) 新規作成やスケール調整を迅速に行うことができる 障害時には自動的にインスタンスの切り替えおよび負荷分散の調整が行われる 44 Web Workerプール 利用者Aが占有 利用者Bが占有 利用者Cが占有 空き 負荷分散
- 44. PaaS はさらに高度に : Database 編 ユーザーからは１つのデータベースに見えるが、内部的には 3 のノードにレプリカが取られている 全てのデータベースへの書き込みが完了して初めてコミットされる Primary 障害時には Secondary が Primary に昇格、別の Secondary が準備される 各ノードはそれぞれ（前述の通り）３重化されたストレージを保有 45 P S S
- 46. 47
- 48. リソース種別に応じた稼働状態の確認 Web App の場合 SQL Database の場合 49
- 49. 正常性の確認 50 利用しているリソースの状態を確認 Resource Health Azure そのものの正常性も確認 Service Health ポータルにアクセスできない場合は Azure の状態 https://azure.microsoft.com/ja-jp/status/
- 50. 監視対象のレイヤーとツール 51 ストレージ サーバー ネットワーク OS ミドルウエア ハイパバイザ ランタイム アプリケーション データ ストレージ サーバー ネットワーク OS ハイパバイザ ランタイム アプリケーション データ ミドルウエア Resource Health Azure プラットフォーム Service Health 従来通りの監視ツールを 導入してもいいが・・・ Managed Service を 使いたいところ
- 51. Log Analytics クラウドおよびオンプレミスの環境内のワークロードが生成し たログデータを収集・管理・分析する 52 Log Analytics レポジトリ クエリー検索 ダッシュボード アラート CSV Power BI Microsoft Azure Windows または Linux （物理または仮想） System Center Operations Manager
- 52. Application Insight 53 Web アプリの正常性やパフォーマンスを監視・診断するため のサービス 各言語の SDK を使用してアプリに組み込むことで任意のプラットフォーム・アプリケーション で使用可能
- 53. Security Center セキュリティ診断にも AI の力を活用 54
- 54. 55
- 57. クラウドサービスにおける “変更” 箇所 58 ストレージ サーバー ネットワーク OS ミドルウエア ハイパバイザ ランタイム アプリケーション データ ストレージ サーバー ネットワーク OS ハイパバイザ ランタイム アプリケーション データ ミドルウエア Configuration Azure インフラストラクチャ Deployment
- 59. Azure DevOps でより高度に 旧 VSTS : Visual Studio Team Services から名称変更 60 実績のあるアジャイル ツールを使用して より迅速にユーザーに価値をもたらし、 チームの垣根を越えて作業を計画、追 跡したり、作業に関する相談をしたりで きます。 あらゆる言語、プラットフォーム、クラウドに対応し た CI/CD を使用して、ビルド、テスト、デプロイで きます。GitHub や他の Git プロバイダーに接続 し、継続的にデプロイすることもできます。 クラウドでホストされた容量無制限のプ ライベート Git リポジトリを入手し、プル 要求と高度なファイル管理により、優れ たコードを協力してビルドできます。 手動の探索的テスト ツールを使用す ることで、テストと公開を自信を持って 行うことができます。 パッケージを作成、ホストしたら、チームで共 有し、ワンクリックで CI/CD パイプラインに 成果物を追加できます。 Azure Boards Azure ReposAzure Pipelines Azure Test Plans Azure Artifacts https://azure.com/devops ➔
- 62. 優秀な DevOps 企業が達成したこと 63 DevOps 製品市場投入の 高速化 収益の増加 2,604 倍 平均修復時間の高速化 2,555 倍 変更までの リードタイム短縮 7 倍 低い変更失敗率 46 倍 開発サイクルの高速化 $ Source: 2018 Accelerate: State of DevOps: Strategies for a New Economy." N. Forsgren, J. Humble, G. Kim. DevOps Research and Assessment (DORA)
- 63. 従来型デプロイ方針の課題 本番稼働系へのアプリケーションデ プロイはリスクを伴う メンテナンスによるシステム停止を許容する？ 休日・夜間などでシステム停止リスクを低減する？ 差分ベースの構成管理によるシス テム再現性の低下 秘伝のタレ化することで保守性が下がる スケール変更や移行性にも問題が起こりやすい デプロイ失敗時に巻き戻しが困難 64 初期 保守 保守 保守 保守 保守 OS MW App v1 V2 Update V3 update 開発者 エンドユーザー ダウンタイム！連休はアップデー トのチャンス！ vs ※ CI/CD を安定させ、カットオーバーのリスクを低減、ゼロダウンタイムでのリリースを目指す
- 64. CI/CD パイプライン Blue / Green デプロイメント 高リスクな本番系へのデプロイを避け別環境へデプロイ ステージ環境ならユーザー影響なくいつでもデプロイでき、品質確認後に本番系と入れ替え 安定した状態でルーティングを切り替えるだけなのでダウンタイムも極小 65 v1 v2 v2 update v3 Production Staging
- 65. イミュータブル インフラストラクチャ 台帳と差分ベースの構成管理は大変なので辞める アプリとインフラの構成は変更できない（イミュータブル）ものと考える クラウドの特徴である「必要な時に必要なだけ利用できる」というオンデマンド性を活用 システムの再現性を高める Infrastructure as Code が重要になってくる 66 Version 1 Version 2 Version 3 新規環境と してデプロイ 品質確認後 に切り替え 新規環境と してデプロイ 弄らない
- 66. Azure Resource Manager Template 複数リソースから構成される複雑なシステムを、JSON 形式 のテンプレートファイルで表現して展開 67 Azure Resource Manager Rest API 仮想マシン Web App SQL DB Etc… テンプレート システム構成を 定義した JSON 形式ファイル パラメータ JSON or コマンドライン or ポータル入力
- 67. システム ランドスケープの構築に 68 Template Azure Resource Manage
- 69. 70
- 70. モノリシック / N-Tier 型の課題 71 OS / MW OS / MW OS / MW OS / MW 開発 デプロイ OS / MW 開発 デプロイ 密結合 アプリ全体 を展開 サーバー単位でスケール 可用性への 依存 最低でも2台から 単一テクノロ ジの縛り
- 71. 密結合 疎結合 マイクロサービス きめ細かい粒度のビジネス機能単位で独立 HTTP など汎用的なプロトコルで通信 個々のサービスは独立にデプロイできる 各サービスに適したテクノロジを採用 72
- 72. PaaS の活用 個々のマイクロサービスを全て自力で高品質に作りこむのは 大変なので、 PaaS をうまく活用するとよい 73 UI 管理画面 ログ 画像 課金 素早く頻繁 にデプロイ 認証 依存性とコ ストを分離 BL PaaSの可 用性を活用 作らない（そのまま使う） サーバーレスによ るコスト最適化
- 73. DevOpsB DevOpsA マイクロサービス アーキテクチャ 74 v1 粒度を小さく、 頻繁なリリース 外部サービスの 可用性から独立PaaS 活用による 可用性とスケール v2 Blue – Green Deployment ライフサイク ルの分離 API 化
- 75. API の提供そのものは簡単だが・・・ 開発者管理 パートナーによる アクセスSOAP から REST XML から JSON パフォーマンス クロス ドメイン 呼び出し アクセス制限 利用分析 キャッシュ URL のマスク ステータス コード IP フィルタリング レート制限 問題追跡 ブランディングされた 開発者ポータル
- 76. API ライフサイクル API 開発者 API 管理者 API 管理者アプリ開発者
- 77. API Management API Management デベロッパー ポータル API ゲートウェイ テスト Azure ポータル アプリ API API 管理者 アプリ開発者 API 開発者 ポリシー ・発行 サブスクリプション ・テスト 開発 開発 Consumer Provider
- 80. キューを活用したブロードキャスト キューのコピーを配信することで複数のロジックを並列稼働さ せる Publisher – Subscriber モデルを実装 他のサービスに影響を与えずにロジックの追加・削除や保守を容易にする 81 Pub－Sub モデル 追加・保守 の単位
- 81. キュー型アプリ開発の注意点 Azure のキュー型サービスの多くは at-least-once による 送達保証を提供している At-least-once の場合はメッセージロストの懸念はないが、多重実行される可能性がある 多重実行が許容されない場合はアプリケーション側で冪等実装の考慮が必要になる 82 2回届く可能 性がある 衝突・不整合 書き込み前の事前 チェックなどで対応
- 82. 83
- 83. Function as a Service More Control Less Agile Less Control More Agile
- 84. サーバーレスへの期待 85
- 86. Azure Functions の場合 87 CODE Bindings Bindings Trigger 【様々なトリガー】 • ストレージキュー • Blob • Timer • GitHub webhook • CosmosDB • EventHub • HTTP • ServiceBus Queue • ServiceBus Topic • etc... 【様々なデータ出力先】 • バインド機能を使った容易なデータ出力 ストレージキュー, Blob, CosmosDB, ServiceBus, etc... • コードを書けばどこにでも出力可能 SQL Database, MySQL, ファイル, etc... 実行環境 ホスティング型 （サーバ占有型） 従量課金型 （サーバレス型） public static void Run(CloudQueueMessage myQueueItem, ILogger log) { log.LogInformation($"C# Queue trigger function processed: {myQueueItem.AsString}"); } C#スクリプト
- 87. 利用シナリオ 88 ...?
- 89. 90
- 90. Why Container ？ 91 ‘ -once, Run- ’ マイクロサービス アーキテクチャ対応 Dev/Test の効率化 確実な Production 環境の配置 Developer Community の成長 アプリケーションのポータビリティ 開発, QA, 運用環境の標準化 OS やインフラ環境の抽象化 リソース配分の最適化 高速起動、スケーラビリティの確保 DevOps Developers Operations
- 91. 共通デプロイ単位としての Docker Container 92 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
- 92. 仮想マシン vs コンテナー 93 ハードウェア ハイパーバイザー (Hyper-V、vSphereなど) 仮想マシン 仮想マシン OSカーネル OSカーネル コンテナー コンテナーランタイム/ライブラリー アプリ ランタイム/ ライブラリー ランタイム/ ライブラリー アプリ アプリ コンテナーイメージ
- 93. Container as a Service More Control Less Agile Less Control More Agile
- 94. CaaS = IaaS の自由度 ＋ PaaSの利便性 95 Infrastructure Host OS Docker Infrastructure Host OS Docker Infrastructure Host OS Docker ストレージ サーバー ネットワーク OS ミドルウエア ハイパバイザ ランタイム アプリケーション データ ストレージ サーバー ネットワーク OS ハイパバイザ ランタイム アプリケーション データ ミドルウエア Container as a ServiceIaaS ミドルウェア ランタイム アプリケーション データ Container 手続き 宣言的 制約 自由 Scalability, Reliability, Portability, etc… PaaS
- 96. PaaS 中心のアーキテクチャにおける課題 サービスの粒度が細かくなると数が多くなり、独立することで コストや管理性で不利な面が出てくる 選択したクラウドで適切な PaaS サービスが提供されていない可能性も考えられる 97 ￥ ￥ ￥ ￥ ￥ デプロイ方式や監 視方法が異なる デプロイ方式や監 視方法が異なる 類似サービ スが重複 類似サービ スが重複 テストやステージング 用途の複数の環境
- 98. コンテナ オーケストレーター デファクトの Kubernates をマネージド サービスとして提供 AKS : Azure Kubernates Service 99 Kubernetes core concepts for AKS https://docs.microsoft.com/azure/aks/concepts-clusters-workloads
- 100. 101
- 101. XXX as a Service More Control Less Agile Less Control More Agile
- 102. サービスの進化の系譜とキャッチアップ方針 初学者はまずは基本となる IaaS と PaaS を把握すると良い 歴史的な経緯としてはオンプレミスの課題をクリアすべく IaaS が、IaaS の課題をクリアすべ く PaaSが、 その課題をクリアすべく CaaS / FaaS が開発・提供されてきている しかし完全なる置き換えになるわけではなく、現時点でも オンプレミスや IaaS や PaaS が優位であるケースは多い このため各サービスの特性とメリット・デメリットを把握した “使い分け”が非常に重要になる 103 IaaS PaaS CaaS FaaS 歴史的には Azure は PaaS から提供が始まり、その後ニーズにこたえる形で IaaS、FaaS、 CaaS を提供してきたが、そこはあまり気にしなくて良い
- 103. クラウドならではのメリット 104
- 105. クラウドは目的ではなく手段 106 On-Premise Lift & Shift Adaption Optimized Native REHOST REFACTOR REARCHITECT REBUILD ( New ) 特定のアーキテクチャにすることがゴールではない
- 106. みんなで幸せになるために 107
- 107. クラウド化の意義（よくある例） 108 現状 の 課題 セキュリティ 高いセキュリティの 確保は勿論のこと様々な 業界標準、コンプライア ンス対応が必要 人件費 運用の自動化を行って いないシステムの運用に かかわる人的リソース人 件費 は最大のコスト要因 サイジング サイジングが難しく、実 際に必要としているス ペック以上のスペックの ハードウェアを導入して いるケースが多い 災害対策 旧来は災害対策用の環 境が不十分のケースが 多く、バックアップもいま だにテープにしている ケースもある 開発/テスト 環境 それほど稼働率が高くな い開発やテスト用の環境 にも本番と同スペックの 環境が必要 グローバル オペレーション 海外からのアクセスがあ るにも関わらずデータセ ンターの場所が限られて いる などなど HW のコスト バックアップ/ HA ソ リューションを備えた従 来の Server / Storage / Network ハードウェアは高価
- 110. Microsoft Confidential ◼ 本資料は情報提供のみを目的としており、本資料に記載されている情報は、本資料作成時点でのマイクロソフトの見解を示したものです。状況等の変化により、内容は変更される場合があります。本資料 に特別条件等が提示されている場合、かかる条件等は、貴社との有効な契約を通じて決定されます。それまでは、正式に確定するものではありません。従って、本資料の記載内容とは異なる場合がありま す。また、本資料に記載されている価格はいずれも、別段の表記がない限り、参考価格となります。貴社の最終的な購入価格は、貴社のリセラー様により決定されます。マイクロソフトは、本資料の情報に対 して明示的、黙示的または法的な、いかなる保証も行いません。 © 2018 Microsoft Corporation. All rights reserved. Microsoft, Windows, その他本文中に登場した各製品名は、Microsoft Corporation の米国およびその他の国における登録商標または商標です。 その他、記載されている会社名および製品名は、一般に各社の商標です。