Downloaded 71 times
![Virtual Machines メトリック
• ただこれだけだと監視対象にできる項目が少ない気がします
• 例えばメモリ使用率とか、ディスクの空き容量とかはデフォルト
だと確認することはできません
• [ホスト]と表示されてることがポイントで、仮想マシン作成直後
だと、ゲストOS側からパフォーマンス情報を取得しておらず、
Azureホストからのみ取得している状態です
41](https://image.slidesharecdn.com/tokyojazugnight12azureops-180619155947/75/Azure-41-2048.jpg)
Uploaded byShingo Kawahara
Azureの運用に欠かせないサービスたち一挙解説
第12回Tokyo Jazug Nightで発表させて頂いた資料です。 バックアップ、監視、自動化の手法を解説しています。 Azure Backup/Metric/Alert/Log Analytics/Automation/Logic Apps
Azureの運用に欠かせないサービスたち一挙解説
- 1. Azureの運用に欠かせないサービスたち 一挙解説！！ Tokyo Jazug Night#12 2018/06/19 河原 慎吾 1
- 2. 自己紹介 • 河原慎吾 • 株式会社セゾン情報システムズ –テクノベーションセンター • クラウド/インフラ/コンテナ担当 • 経歴 – VMwareベースの自社クラウド構築/運営 ⇓⇓⇓ – パブリッククラウド活用推進 • 好きなAzureのサービス – Container Instances 2
- 3.
- 4. 社内Azureワークショップ • 毎月テーマを1つ決め、ハンズオン型の勉強会を1年以上 継続開催 4 # テーマ 1クラウドとAzure 2 IaaSハンズオン 3 PaaSハンズオン 4 WebAppsから学ぶIaaSとPaaSの違い 5 VMSSから学ぶIaaSとPaaSの違い 6 バックアップハンズオン 7 IaaS監視手法と自動化サービスハンズオン 8 PaaS監視手法と監査ログ保管
- 5. 社内Azureワークショップ • みんなの声 – VirtualMachineを作ったり、Web Appsを作ったり、メリットは分かっ たけど、実際に使った場合の運用手法まで知りたい – オンプレでやってたときの運用が通用するのか知りたい • 従来オンプレやプライベートクラウドでやってきた運用がAzure だとどうなるのかを解説します • 当社でよく使う3サービスに関する運用が主です – Virtual Machines/Web Apps/SQL Database 5
- 6.
- 7. 本日のゴール♪ • これからAzureを触られる方 – こんな運用系サービスがあったんだと知って頂く •Azureは結構使ってるけど運用系サービスはあまり使ってない方 – ハマったポイントとかを織り交ぜるので是非お役立てください！ • すでに運用系サービスがっつり使ってるよって方 – 暖かく見守ってください 7
- 8.
- 9.
- 10. Azure Backupってなに？ • AzureVirtual MachineをAgentレスでバックアップ可能なサービス • 基本はAzure VMを丸ごとバックアップする。複数ディスクがあっても全て 取得する • Agentを導入することで、フォルダ/ファイル単位にバックアップが可能 • バックアップスケジュールを設定することで、定期的な取得が可能 • アプリケーション整合性の担保 • オンプレのデータをAzureにバックアップ可能 10
- 11. Azure Backup 取得/復元パターン •とても便利なサービスですが、バックアップ/リストアの手法がいくつかあ り、それぞれに注意点があったりします – VM単位バックアップ/VM単位復元 – VM単位バックアップ/ファイル単位復元 – Agentバックアップ/復元 11
- 12. VM単位バックアップ/VM単位復元 • Azure Backupは裏でAzureStorageにデータ格納するが、利用者はStorageは意識しない。 • 但し、Storageの種別（LRS/GRS）を選択することが可能（デフォルトGRS） • スケジュールや保持期限を設定可能 12
- 13. VM単位バックアップ/ファイル単位復元 • Azure BackupをiSCSIマウントすることで、VM丸ごとバックアップからファイル単位で復 元することが可能 •iSCSIマウントは、Azure Backupとネットワークが繋がればどこで実行してもOK（オンプ レでも可） 13
- 14.
- 15. VM単位とAgent単位の違い 15 # 項目 VM単位Agent 1 取得単位 VM丸ごと。複数ディスク含む。 任意のファイル/フォルダ単位 2 対応OS Windows/Linux Windows 3 リストア単位 別VMを新規作成して戻す ファイル/フォルダ単位で戻す 4 ファイル/フォルダ単位で戻す 5 整合性 Windows：アプリケーション整合性(VSS) アプリケーション整合性(VSS) 6 Linux：ファイルシステム整合性 (前後スクリプト導入でアプリケーション整合性可能) 7 OS停止中の取得 可 不可 8 リージョン バックアップ先と元が同一リージョンのみ バックアップ先と元が異なるリージョン可能
- 16. Azure Backup料金 • ストレージ料金部分は、ディスクサイズではなくバックアップさ れたデータ量によって決まります •なので、厳密な料金計算は難しいです 16https://azure.microsoft.com/ja-jp/pricing/details/backup/
- 17.
- 18. Azure Backupの気を付けよう① • Agentバックアップの場合、格納先はPaaSのAzureBackupなので、オンプレから の転送時はネットワーク構成に注意が必要 – インターネット：○ – インターネットVPN：✕ ※Azure BackupはvNetに配備できないため – ExpressRoute (Private Peer)：✕ ※Azure BackupはvNetに配備できないため – ExpressRoute (Public Peer)：○ 18 internet Express Route
- 19.
- 20.
- 21.
- 22.
- 23.
- 24. スナップショットリストア • スナップショット作成時にスナップショット保存先のディスク種 別を選択することができます • ここでHDDを選択したからといって、VM作成時にHDDしか選択 できないということはありません •あくまでもスナップショットのディスク種別です • では何が影響されるかというと、スナップショットからVMを立 ち上げるときの時間です • コストに跳ねるので、基本HDDでいいかなと思います 24
- 25.
- 26.
- 27. スナップショット料金 • VHDサイズ（＝ディスクサイズ）の内、使用している容量の Storage価格 – StandardHDD ManagedDisk料金 • 東西日本リージョン – 5.6/GB – Premium SSD Managed Disks • 東日本リージョン – 17.03/GB • 西日本リージョン – 15.46/GB 27
- 28.
- 29. スナップショットの気を付けよう • スナップショット自体の世代管理はユーザ側で考慮する必要があ ります。Azure Backupのように保持期限を設けることはできま せん •Azure Automation等の自動化サービスを使って、自分たちで取 得や世代管理を自動化する必要があります • スナップショットはディスク単位の取得になるため、複数ディス クをアタッチしたVMでは整合性に気を付ける必要があります （静止点の取り方を検討する） 29
- 30.
- 31. SQL Database • SQLDatabaseではユーザが意識することなく、自動的にバック アップが取得されます – 完全バックアップ：毎週 – 差分バックアップ：数時間に1回 – トランザクションログバックアップ：5～10分に1回 • 取得タイミングはAzure側で決定されるため、ユーザが指定する ことはできません 31
- 32. SQL Database • 保存期間はSQLDatabaseのサービスレベルにより異なります – Basic：7日間 – Standard：35日間 – Premium：35日間 32
- 33. SQL Database復元パターン • Pointin Timeリストア – 同一サーバ内に新規データベースとして復元する手法 – 保有期間に合わせた任意の時間に復元することが可能 – 主な利用用途は、何か不具合発生時に、過去に遡って検証したい場合等 が考えられます 33
- 34. SQL Database復元パターン • データベースコピー –最新時点のデータベースコピーを作成する手法 – Point in Timeリストアと違い、任意の時点を指定することはできない – 同じサーバだけでなく、異なるサーバー、異なるリージョンのサーバーにコピーすることが可能 – 主な利用用途は、最新の本番データを開発/検証用途で利用したいシーンが考えられます 34
- 35. SQL Database復元パターン • geoリストア –1時間前の状態の新規データベースとして復元する手法 – 任意の時点を指定することはできない – 異なるサーバー、異なるリージョンに作成可能 – 用途としては、リージョンが全滅した場合に、1時間前であれば他のリージョンで起動することができるとい うDR用途（よりRTO/RPOを求めるのであれば、アクティブgeoレプリケーションを使う） 35
- 36. SQL Database 長期保管 •保存期間はSQL Databaseのサービスレベルにより異なります – Basic：7日間 – Standard：35日間 – Premium：35日間 • この保有期間を最大10年延長することが可能です • バックアップ取得先にはAzure Backupを指定します • 注意点として、Azure Backupは、SQL Databaseサーバと同じ サブスクリプション・リージョン・リソースグループに配置する 必要があります 36
- 37.
- 38.
- 39. メトリック • IaaSであれPaaSであれ、Azureではパフォーマンスと正常性を視 覚的に確認できるメトリックが標準で準備されています • メトリックは1分間隔で取得されます •メトリックが特定の閾値を超えたときに通知したり、リソースを 自動スケールしたり、ユーザ側で作成した任意の処理を実行した りといったことが可能です 39
- 40. Virtual Machines メトリック •こんな感じで各メトリックを確認することが可能です 40
- 41. Virtual Machines メトリック •ただこれだけだと監視対象にできる項目が少ない気がします • 例えばメモリ使用率とか、ディスクの空き容量とかはデフォルト だと確認することはできません • [ホスト]と表示されてることがポイントで、仮想マシン作成直後 だと、ゲストOS側からパフォーマンス情報を取得しておらず、 Azureホストからのみ取得している状態です 41
- 42. Virtual Machines メトリック •ゲストレベルの診断を有効にすることで、OSのパフォー マンスモニター情報を取得することができます 42
- 43. Virtual Machines メトリック •しばらく待つとパフォーマンスモニターの情報を 確認することができます • 注意点として、Linuxのディスク使用率は取得する ことができません。必要な場合は後述するLog Analyticsを使用する必要があります 43
- 44. Virtual Machines メトリック •ちなみに実態は拡張機能の「IaaSDiagnostics」が追加 されたことでゲストOSのパフォーマンスモニタ情報を取 得できるようになりました 44
- 45. Virtual Machines メトリックアラート •次に閾値を超えた場合のアラート通知について説明します • メトリック画面の上にある「メトリックアラートの追加」を選択 します 45
- 46. Virtual Machines メトリックアラート •監視対象メトリックと閾値、期間を設定します 46
- 47. Virtual Machines メトリックアラート •通知手段を指定します • Webhook指定が可能な為、出来るこ とは非常に幅広いです。 – Slackへの通知は、カスタムJSONペイ ロードが指定できないので、Logic Apps を間に挟む必要がある 47
- 48. Virtual Machines メトリックアラート •Automation Runbook/Logic Apps を指定して、アラート発生時に自動 的に処理をさせることが可能です 48
- 49. Virtual Machines メトリックアラート •ゲスト診断ログは指定したストレージアカウントのテーブルスト レージに格納されます 49
- 50. Virtual Machines メトリックアラート •Syslogやイベントログも保管されています 50
- 51. Virtual Machines メトリックアラート •数値データであるメトリックの閾値監視方法を見てみましたが、 ログの場合は文字列データであるため、先程設定したアラート機 能が使えません • 文字列データを監視するためには、Log Analyticsを使います 51
- 52.
- 53. Log Analytics 53 • Azureリソースやオンプレ環境のデータを収集するサービス •収集したデータはクエリ発行して分析することが可能 • データの文字列を契機にアラートを発生させることも可能
- 54. Log Analytics 54 • 仮想マシンを選択して、LogAnalyticsワークスペースに接続し ます
- 55.
- 56. Log Analytics 56 • 収集するイベントログの種類とタイプを選びます •Securityイベントログは収集できません。Securityイベントログ を収集したい場合は、「Security & Compliance」ソリューショ ンをインストールする必要があります – 別途費用が発生します
- 57. Log Analytics 57 • 収集したデータはクエリを発行して確認することができます –この例では、Computer名が「win-monitor」且つ タイプが「Event」の ものを抽出
- 58.
- 59. Log Analytics アラート設定 59 •特定の条件のメッセージが出力されたときにアラート通知する設定が可能で す • 今回はイベントログでイベントレベルがエラーの場合に通知するようにしま す • アラートルールとなるクエリを発行し、「New Alert Rule」を選択します
- 60. Log Analytics アラート設定 60 •次に評価基準を設定します • 「期間」はどれくらいの範囲を対象とするか、頻度はクエリ発行間隔を表し ています • ここでは10分間隔でクエリを発行し、クエリ発行から10分前までのデータ を対象としています
- 61. Log Analytics アラート設定 61 •次にアラート名と重要度を設定します
- 62. Log Analytics アラート設定 62 •最後にアラートを検知したときにどういうアクションを起こすかを定義しま す • 以下のアクションを選択できます – メール/SMS/プッシュ/音声 • 音声は米国のみ – Azure Function – Logic Apps – Webhook – ITSM – Automation Runbook
- 63. Log Analytics アラート設定 63 •メトリックアラートと違って、Log Analyticsでは、カスタムJSONペイロー ドを含めることができるため、間にLogic Appsを挟まなくてもSlack通知が 可能です
- 64. Log Analytics アラート設定 64 •Slackには以下のように通知されます。タイトルとかアイコンとかメッセー ジとかは細かくカスタマイズできます
- 65. Log Analytics 65 • LogAnalyticsへのデータ収集対象は、必ずしもAzureリソースで ある必要はありません • ネットワークとAgentのインストールができれば、オンプレから もデータ収集が可能です
- 66.
- 67. Log Analyticsの気を付けよう① 67 • アラート頻度と期間を短くすればほぼリアルタイムで検知可能では？と思う が、これは注意が必要 •ソース（今回はイベントログ）からLog Analyticsへの送信頻度や間隔は指 定できないので、いつデータが収集されるかが分からない • あまり短くしすぎるとアラート検知漏れが発生する懸念が出てくる 14:10:30にエラーが発生したが、Log Analyticsにデータ収集 されるのに1分掛かった場合、14:12のクエリではそれを検知できない 14:12のクエリでは期間が14:11～14:12に発生したイベントという条件なので、 14:10:30に発生したイベントはアラート対象外となる
- 68.
- 69.
- 70. Microsoft マルウェア対策 70 • ウイルスやスパイウェアなどの悪意のあるソフトウェアを識別し て削除する無料のリアルタイム保護機能 •仮想マシンの拡張機能として追加する • 提供はWindowsのみ
- 71. Microsoft マルウェア対策 71 • VirtualMachinesの拡張機能から「Microsoft Antimalware」を選択する
- 72.
- 73. Antimalwareの気を付けよう 73 • Windows Server2016では、Windows Defenderがデフォルト でインストールされているため、Microsoft Antimalwareのイン ストールは不要です（インストールしてもよい。その場合、 Azure PowerShellを用いてAzure側からスケジュール設定などが 可能になる） • Windows Server 2012 R2以前は、拡張機能で追加すると、 Windowsサービスとして新規に「Microsoft Antimalware Service」が追加されます • スキャンスケジュール等の設定変更はAzure PowerShellを用い て行います
- 74. サードパーティ製品 74 • Azureサービスだけで多くの監視が可能ですが、3rd-party製 の監視ソフトウェアが必要なケースもあります – OS上のサービスやプロセスの監視 •Azureの機能では監視することができません • 代替案 – イベントログ監視しているのであればプロセスダウンをイベントログで検知する – タスクスケジューラー等で定期的に状態を確認し、異常だとイベントログに出力する ように作り込む – アラート通知に即時性を持たせたい • 特にLog Analyticsでは検知するのに時間が掛かる可能性があります
- 75.
- 76.
- 77. メトリック 77 • IaaSであれPaaSであれ、Azureではパフォーマンスと正常性を視 覚的に確認できるメトリックが標準で準備されています • メトリックは1分間隔で取得されます •メトリックが特定の閾値を超えたときに通知したり、リソースを 自動スケールしたり、ユーザ側で作成した任意の処理を実行した りといったことが可能です
- 78. App Serviceのメトリック 78 • IaaSと同じようにメトリック値を確認することができます •項目はIaaSとは異なり、App ServiceだとWeb系メトリック です
- 79.
- 80.
- 81. Application Insights 81 • Webアプリケーションパフォーマンス管理（APM）サービス •アプリケーションのパフォーマンス、使用状況を監視することが できます
- 82. Application Insights 82 • ApplicationInsightsを利用するには2パターンあります（組み合わせ可能） – 既存Web AppsにApplication Insightsを追加する • Webアプリケーション稼働中に設定追加が可能 • アプリをデプロイし直す必要がない • アプリ自体にパッケージがインストールされることもない • Web Apps限定。オンプレのWebアプリケーションでは利用できない • カスタムテレメトリが利用できない – アプリケーション自体にパッケージ追加してデプロイする • Visual StudioでApplication Insightsの設定をする • Nugetパッケージが追加となる • Web Appsに限らないので汎用性が高い • コードに追加することでカスタムテレメトリが利用可能
- 83. Application Insights 83 • ApplicationInsightsを利用すると パフォーマンス情報を取得するこ とができます
- 84. Application Insights 84 • 応答レスポンスの割合を見てみます •ほとんど250ms以下でのアクセスですが3sec-7sec掛かった処理 があることが分かります
- 85.
- 86. Application Insights 86 • 更にドリルダウンしていくと、同じ処 理が60件あったが、他は全て数ミリ秒 で処理していることが分かります •該当の時間はWeb Apps起動直後だった ため、レスポンスに時間が掛かったこ とが推測されます
- 87. Application Insights 87 • 他にも分析してみます •/Account/Registerページのレスポンスタイムが大きいことが分 かります • アクセス数は/Contactが多いです • この2ページの処理速度を改善するとユーザエクスペリエンスが 向上することが予想されます
- 88.
- 89. Webサイト応答監視 89 • Application Insightsから、WebAppsへのURL応答監視が可能 です
- 90.
- 91.
- 92.
- 93.
- 94.
- 95.
- 96. Query Performance Insight 96 •データベースパフォーマンスのトラブルシューティング をサポートする • 以下の情報が提供される – データベースリソース（DTU）の消費量情報 – CPU/期間/実行回数の上位クエリ – クエリ詳細をドリルダウンして、使用率履歴を表示
- 97. Query Performance Insight 97 •DTU消費量の多いクエリを表示
- 98. SQL Database Advisor 98 •使用履歴を分析してユーザのデータベースのパフォーマ ンスを最大限に引き出すことができる推奨事項を提供し てくれます – インデックス作成に関する推奨事項 – インデックス削除に関する推奨事項 – クエリのパラメータ化に関する推奨事項 • クエリの実行のたびに変動するパラメータを変数のように扱ってパ フォーマンスを向上させる
- 99. SQL Database Advisor 99 •実際に適用したあとの例ですが、インデックスの作成に 関する推奨事項が通知されています。
- 100.
- 101.
- 102.
- 103. Automation 103 • 実行単位（コードの単位）をRunbookと呼びます • LogAnalytics等のサービスからAutomation Runbookを 呼び出すことも可能 • ユースケース – 仮想マシンを朝9:00に起動して、18:00に停止する – SQL Databaseのサイズを月末だけスケールアップする – 定期的にSQL文を発行し件数をSlackに通知する
- 104.
- 105.
- 106. Automationの気を付けよう 106 • Automationのジョブ自体が失敗した場合はポータルからひと目で分かりま すが、ジョブは正常終了しているものの、内部的にエラーメッセージを吐い ているケースがあります • その場合は、ジョブを１つずつ選択して、確認していかなければならず非常 に手間が掛かる作業です •Automation実行結果をLog Analyticsに転送することができるので、Log Analyticsでエラー検知します • Runbook内で確認のロジックを入れても良いです。ただ、待ち合わせ処理な どを入れる場合にRunbook実行時間に注意してください（実行時間で課金さ れるため）
- 107.
- 108. Logic Apps 108 • 各サービス、ソリューションをワークフローとして繋ぐ サービス •トリガーやアクションのロジックが用意されており、そ の中から選んで繋げていく • If、switch分岐、ループなども可能 • ノンプログラミングで実現可能
- 109.
- 110. Logic Apps 110 • ユースケース –ほぼ無数にありますが・・・ – アラート発生時にLogic Appsで受けて、 JSONをパースして、Slackに通知する – SendGridのMail Drop等のイベントを Logic Appsで受けて、JSONをパースし て、メールとSlackに通知する
- 111. まとめ • バックアップ/監視/自動化に関するサービスとハマったポイント をご紹介しました • オンプレやプレイベートクラウドで実装してきた運用はほぼ実現 できますし、Azureという設計場所が変わっても設計概念は変わ らないと思っています •今日の内容の細かい実装手順はQiitaにまとめていますので是非ご 覧になってください – https://qiita.com/shingo_kawahara 111
- 112. 本日のゴール♪ • これからAzureを触られる方 – こんな運用系サービスがあったんだと知って頂く •Azureは結構使ってるけど運用系サービスはあまり使ってない方 – ハマったポイントとかを織り交ぜるので是非お役立てください！ • すでに運用系サービスがっつり使ってるよって方 – 暖かく見守ってください 112
Editor's Notes
- #3 テクノベーションセンターは2年前にできた組織で、全社のイノベーションを加速させることが目的で設立されました 私はその中で、クラウド・インフラ・コンテナを担当しています これまでは、自社クラウドの構築と運営をやってきましたが、設立を機にパブリッククラウドを中心に触ることになりました オンプレ、プライベートクラウドと同等のサービスレベルで運用するにはどうすればいいかを考えた結果をお伝えできればと思います
- #4 当社ではラストマン戦略というものを取り入れていて、ある特定の領域で、チームで一番詳しくなろう、詳しくなったら社内で一番詳しくなろう、外に飛び出してみよう といった具合で、徐々に
- #5 Azureの活用を推進するとともに、自分のスキルも向上できる！
- #7 これ以外にもセキュリティとかコスト管理とかAdvisorとかネットワーク管理他にも色々あって悩んだんですが、時間の都合上この３つをテーマにしたいと思います
- #42 これはVMware等の仮想化基盤層に関わった方ならお馴染みだと思います
- #98 ドリルダウンして、実際にどういうクエリでいつ実行されたもので、そのときのDTU消費量、実行時間、実行回数を詳細に確認することができます
- #112 一挙解説といいながらそれほど多くご紹介できませんでしたが、バックアップ・監視・自動化に関するサービスと注意事項を説明しました オンプレやプライベートクラウドで実装してきた運用はほぼ実現できると思っています Azureはサービスが多いですが、知ってさえいれば、これまでの運用設計概念は変わらないと思っています。 実装する場合の細かい手順とかはQiitaにまとめていますので、ご興味ありましたら参考ください この資料はあとでアップロードします ありがとうございました！