AzureとVSTSで実現するDevOps とモニタリング かめがわ かずし(@kkamegawa)

Self-intrduction KAMEGAWA Kazushi / Engineer Microsoft MVP for Visual Studio and Development Tools (2012/7～) Twitter : @kkamegawa Facebook : https://www.facebook.com/kkamegawa/ Blog : http://kkamegawa.hatenablog.jp SlideShare : https://www.slideshare.net/kkamegawa/ 出版など  アジャイルでやってみた。 http://www.shuwasystem.co.jp/products/7980html/4740.html  Build InsiderでWindows Subsystem for Linux掲載中 http://www.buildinsider.net/enterprise/wsl  Team Foundation Server 2017コンプリートガイド https://www.amazon.co.jp/dp/B073YCLHTC/

This contents based on 2018/4/21

主要プラクティス DevOpsプラクティス Infrastructure as Code(IaC) 継続的インテグレーション 自動テスト 継続的デリバリー 性能モニタリング/監視 リリースマネージメント 構成管理 サブプラクティス 可用性監視 フィーチャーフラグ セルフサービス環境 自動リカバリー (ロールバック/フォワード) プロビジョニング自動解除 仮説に基づく開発  本番でのテスト  フォルトインジェクション  使用状況モニタリング  A/Bテスト http://www.itproguy.com/devops-practices/

主要プラクティス DevOpsプラクティス Infrastructure as Code(IaC) 継続的インテグレーション 自動テスト 継続的デリバリー 性能モニタリング/監視 リリースマネージメント 構成管理 サブプラクティス 可用性監視 フィーチャーフラグ セルフサービス環境 自動リカバリー (ロールバック/フォワード) プロビジョニング自動解除 仮説に基づく開発  本番でのテスト  フォルトインジェクション  使用状況モニタリング  A/Bテスト http://www.itproguy.com/devops-practices/

オンプレミス クラウド モニタリングツール(一部) JP1 SystemWalker System Center Zabbix Elasticスタック (Elastic Search+Kibana+Beats) Prometheus NewRelic DataDog Splunk Azure Application Inisights AWS CloudWatch Google StackDriver

モニタリングに期待すること(一部) アプリケーションが稼働していなければ警告する 想定以上のメモリ,CPU, I/O負荷が発生していれ ば警告する 意図しないユーザーがアクセスしていると警告す る

モニタしてないと困ること 「遅い」といわれたときに調べられない 想定外に時間がかかっているのかわからない 何が原因で遅いのかわからない 不正アクセスがわからない そのアクセスは正常？異常？ リリースしてもいい性能かどうかわからない

モニタリングは性能監視だけに使うもの？ 検証環境で確認＆想定通りの性能か採取 A/Bテストで更新版が過大な負荷をかけてないか 確認 一部のサーバーへ実際に展開して確認する

リリース機能と組み合わせるDevOps Monitoring VSTS(TFS)のリリースとモニタリングを組み合 わせて、リリース時の継続的なモニタリングを実 現するRelease Gate機能 Continuous Monitoringとかブログで書いてる VSTS(Sprint 127)/TFS 2018の新機能 現在プレビュー https://docs.microsoft.com/en-us/vsts/collaborate/preview-features?view=vsts

Visual Studio Team Services(VSTS)って何？ Microsoft が提供する開発支援オールインワン パッケージ オンプレミスのTeam Foundation Serverもある AWSのCodeシリーズやGoogleの開発ツール、他 社のSaaS組み合わせ等 タスク管理まで組み込んでるのはVSTSくらい？ VSTS以外は他社製品, OSS, サービスとの連携が多い

VSTSとAWSのCodeシリーズとGoogleと AWS Code Commit AWS Code Deploy AWS CodeBuild AWS Code Pipeline AWS X-Ray AWS CodeStar Error Reporting Trace Debugger Developer Tools Cloud SDK Deployment Manager Cloud Source Repositories Cloud Test Lab Cloud Builder ビルド、ソース管理、テスト管理、 デプロイ、タスク管理、Wiki等

http://image-store.slidesharecdn.com/2d832540-c038-4266-829a-e79ce19bb716-original.png ほかにも組み合わせはいろいろ ※:少し古いので、今はもっと多い

Demo

ReleaseでAppInsightsのモニター設定 Application Insights のルール設定

ReleaseとMonitoring • リリース前のゲート(Gate)で条 件が一致したらリリース • リリースの判定を行うゲート • Azure Function • REST API • 拡張機能(3rdパーティサービ スを使用) • Azure Monitor • Work Item有無 • Application Insightsでアラート が記録されていなければリリー スということも可能

AppInsightsで作ったアラートが使える(はず)

Application Insightsでのアラート定義 過去24時間以内に例外が3回以上 発生したら、という条件をSQLと GUIライクで検索クエリに登録

クエリわからないときはツールに頼る RUNをクリックすると、サンプルのクエリが 出てくるので、そのままコピペすれば、 アラート(新)のクエリになる。

今日だけ困ったこと 4/21現在、Application Insightsのアラート(ク ラッシック)ルールがAzureポータルでも作れない ※:前はそもそもReleaseタスクで作れた アラート(新)は作ってもVSTSが認識しない (問い合わせ中) ちょっと我慢して ><(聞いているところ)

なんでこんな面倒なことを？ Web Appsなら別スロットでいいのでは？ Web Appsのスロットは同一リソースを共有する (正確にはApp Serviceプラン内で共有) https://docs.microsoft.com/ja-jp/azure/app-service/azure-web- sites-web-hosting-plans-in-depth-overview よって、性能や機能テストが絡む場合やモニタリ ングが必要な場合はRelease Gateは有用

Continuous Monitoring Gate 1 Gate 2 Gate 3 通過 通過 通過 失敗 失敗 失敗 失敗 失敗 失敗 失敗 通過 通過 通過 通過 通過 通過 通過 通過 承認 安定化 タイムアウト Gateはリリース 環境に複数設定 可能。 Gate1:REST API Gate2:MonitorA Gate3:MonitorB 等を仕掛けておく

複数のモニターアラートをGateに重ねる ※:Azure側の都合で エラーになっています (4/21時点)

モニタリングの困りごと(再度) 何を採取すればいいのかわからない ある程度のOS, インストールされたアプリの知識が必要 どうやって採取すればいいかわからない 採取しても「正しい」値かどうかわからない なにをもって「異常」とする？ Application InsightsとMonitorで平常時の状態を認識する 異常発生時何をすればいいのかわからない

まとめ リリースの基準をわかるように、ちゃんと平常時 の状態を記録しましょう。 Application Insights以外にもいっぱいあるけど、楽。 「レビューこれくらいやったからリリースOK」 ではなく、ちゃんと実機で測定してからリリース しましょう。

ありがとうございました！