Ops summit2021 article06 | 運用自動化プラットフォーム Kompira

みなさん、こんにちは。
日本マイクロソフトAzureビジネス本部の佐藤と申します。
どうぞよろしくお願いいたします。

本日は、Microsoft AzureのOpsの現在地点とMicrosoftの提唱するOpsの今後と題しまして、お話しさせていただければと思います。
どうぞよろしくお願いします。

Ops、いわゆる運用にフォーカスをした形で、大きく2つのトピックでお話しさせて頂きます。
まず一つ目が、「Microsoft Azure」、いわゆるハイパースケールのクラウドなどと言われたりもしますが、このAzure自体の運用に関して、公開されている情報の中から運用に関するトピックについて、さまざまな観点からお話しをさせていただければと思います。

二つ目は、Microsoftの提唱するOpsの今後に関わってくることですが、今後はより一層ハイブリットクラウド、マルチクラウドの方にフォーカスが移っていくだろうと考えています。前段がMicrosoft自身のOpsにフォーカスを当てたところだとすると、後半はユーザー目線から、我々Microsoftとしてどうしていこうと考えているか、主にAzure Arcにフォーカスを当ててお話しをさせて頂きます。

Azure Vision

まずは、Azureのビジョンになります。

Microsoftの会社全体では、この地球上の人々と組織がより多くのことを成し遂げるように支援することをミッションステートメントとして掲げています。
このMicrosoftとしてのミッションステートメントだけではなく、その下にAzureとしてのビジョンもあります。
AzureはいわゆるクラウドプラットフォームとしてMicrosoftが提供しているプラットフォームソリューション群になりますが、そのMicrosoft Azureにもビジョンがあります。
それがAzure is the world’s computer、アジュールを世界のコンピューターに、というものです。
これが具体的にどういったことを意味しているかについて、次のスライドで補足します。

Intelligent Cloud、Intelligent Edge、これが先ほどのAzureのビジョン、Azureを世界のコンピューターにしていくということを実現するための戦略になりますが、このIntelligent Cloud、Intelligent Edgeという言葉自体は、数年来変えていません。
cloudとedge、これを全てをしっかり下支えするプラットフォームとして、Azureを提供していくというところ、我々は物事を成し遂げていくためのパーツやプラットフォームを提供していくという側面と、クラウドだけではなく、edge化も含めていわゆるデジタル化を促進していくという、両方の側面の意味を込められているのが、この戦略のメッセージングになります。

重要なところとして、今、デジタル化を進めていかなければいけない時代だと言われていますが、我々Microsoftとしては、単純にデジタルの時代だとかクラウドの時代だとか、そういう形で丸めては捉えていません。
右側に、サティア・ナデラがインドでのイベントで登壇した際のコメントを抜粋させていただいていますが、我々は分散コンピューティングファブリックを世界のコンピューターとして構築してますと、Azureを世界のコンピューターとして作っているんだというコメントをしています。

要するに、このクラウド時代というのは分散コンピューティング、Distributed Computingの時代だと我々は考えているわけです。
スケールアップからスケールアウトの世界観に移ってきて、スケールアウトの時代だと言われて久しいと思います。
それをより一歩進めて、分散コンピューティングの時代が来ている、と。
だからそのコンピューティングのプラットフォーム、ないしはコンピューティングのハブになるものが必要だと考えて、そのためにAzureを提供しているのだと捉えて頂ければと思います。

競合クラウドプロバイダーを凌駕するリージョン数・インフラ規模

具体的にこのAzureがどうなっているかについて、説明致します。
現在、Azureはグローバルで65を超えるリージョンを提供しています。
よく1リージョン、1データセンターだと勘違いをされることもままありますが、少し厳密なところで補足をさせて頂くと、1リージョンの中に複数ゾーンあります。
可用性ゾーンとしてサービスを提供しているリージョン、提供していないリージョンがありますが、各リージョンの中にゾーンと呼ばれる括りがあるとご理解ください。

さらにそのゾーンの中に複数のデータセンターがあります。
ですので、この65リージョンというのは、65データセンターではなくて、65×n倍のデータセンターをグローバルでサービス提供しているとご理解頂ければと思います。

さらに、それを接続していくためのネットワーク、単純にそれを相互に接続するだけではなく、そこで動いているサービスにアクセスする、サービスにそれぞれ作ったアプリケーション、Saas、Paas、もろもろをユーザーさんやパートナーさんに作って頂くわけです。
それがサービス提供するためのネットワーク、CDN的なところも含めたネットワークも含めて提供していますので、非常に膨大なインフラを提供しているとご理解頂ければと思います。
当然これを運用していくのは、凄まじく大変になっていきます。

Resilient Foundation of the Azure platform

先程のビジョンの通り、Azureを世界のコンピューターリソースにしていく、分散コンピューティング時代のハブにしていくと考えた場合に、このプラットフォームがしっかり信頼に足り得るもの、信用できるもの、また何かあった時でも柔軟に、英語でレジリエントという言葉を日本語で表現するとそこのコンテキストを説明するのがなかなか難しいので、そこを信頼、信用や磐石、回復性があるなど、そういった形で説明しますが、ここでは単純にレジリエントプラットフォームという形で説明をさせて下さい。

レジリエンシーが十分に担保されたプラットフォームとしていかなければならない、そのためにグローバルインフラストラクチャの設定はもちろん、設計、運用、監視まで含めてしっかりやっていくことが、我々Azureがさまざまな形で取り組んでいるポイントです。

本日の本題、オペレーション部分について、公開している情報からお話しします。
まず重要なところは、障害は可能な限り避けようという努力は我々Microsoftとして当然実施していますが、100%無くせるものではありません。
では、障害はいつ起きやすいかというと、当然変更のタイミングになるわけです。

Azure change automation

　この変更に関連する部分の管理も、当たり前といえば当たり前ですが、しっかり考えた形で実装の展開をしているところから、Azureの運用の部分をお話します。
このスライドではAzure change automation と表示しています。
新しいサービスの展開などはもちろんそうですが、何らかの構成変更、機能差分の廃止、更新のアップデート、更新の展開をするような流れ、変更、修正、新機能に関するデプロメント含めた全ての変更に関してこのプロセスを踏襲して、運用しています。

何らかの変更によって障害を引き起こす、ないしは何かを止めてしまうということを可能な限り回避するために、非常に多段階のプロセスを取っています。
開発ないしはそのテストをするプロセスは可能な限り自動化して、全て必要なプロセス、必要なテストをパスしないと次のステップに進まない、というのは至極当然です。

それをいわゆるValidation cycle、左の中でdevelopment & testの中で繰り返し行なったあとで、クオリティのゲートを越えて、テスト用の環境のところでしっかりテストして、自動テストを全てパスしてからようやく次のステップにいけます。

最初にいきなりどこかのリージョンに行くわけではなく、Canary regionsと書かせていただいている、いわゆるカナリアテストですね。
実ユーザー環境に一番近いけれども、なるべく影響範囲が少ないところから提供を進めていきます。
Production ready になりCanary regionsから提供していって、そこでも本当に何も問題が起きないことを確認してから、さらに次のステップにいきます。

次がPilot Phaseです。
ここもやはりPilot Phaseなので、本番のregionに展開しているわけではありません。その次にEarly regionsです。
これはベンダー側からすると、なかなか高飛車なことを言ってくれるじゃないかというふうに思われるかもしれませんが、各Regionごとに利用いただいているユーザーさんの数や影響の大きさには当然濃淡がありますので、Early regions、なるべく影響が少ないRegionから実際の展開を開始します。

ここでも実際に何も問題が起きないことが確認できてから、ようやくBroad なRolloutに移ります。 BroadなRolloutの中でも当然ペア化されたRegionがありますので、そこのPair Regions、日本でいえば東日本Regionsと西日本Regionsがありますが、同時に展開してしまって両方に問題が起きたら大変です。
ですので、Pair Regionsの中でもよりサイズ感の小さいほうから展開して、そののちにペアの片割れのほうに展開するという流れで非常に多段階のステップ、可能な限り自動化してテスト項目を全てパスしたら、徐々に展開していくという運用プロセスを取っています。
当然、途中で何か問題が見つかったら、一番最初まで差し戻ります。

問題を踏んだユーザーやパートナーは早く直してくれと。
それでコードが直ったら、早く展開してくれという依頼も当然ありますが、このステップ、このフェーズを通してからでないと展開できませんので、そこはしっかりテストをします。

このように徹底して変更管理をしていることも含めて、更新が反映されるまで時間がかかるのがある意味弊害ですが、ここまでしっかりやっていることともをご認識いただけると助かります。

ここまででも様々な段階についてご説明しましたが、この一端のところからご想像頂ける通り、現状のAzureの運用というのは、非常に凄まじいスケールで実行されています。
それぞれのサービス、それぞれのソリューション、またインフラの部分、アーキテクチャも非常に複雑になっていますし、関連するコンポーネントハードウェアは非常に多数のものがありますので、これを普通の従来の運用のアプローチでやっていこうとすると無理があります。

ですので、当然可能な限りの自動化は実行、実施をしていまして、基本的に標準で自動化できるところは自動化しきっています。それでもなかなかリアルタイムでやっていくのは難しいという状況になっています。
そこで何をやっているかというと、AIを使い始めています。
自動化の次に、いわゆる自律化を進めていこうとしているところです。

AI Ops

Azure AI Opsという言葉で説明させて頂いたりしますが、AIを使って自律化させていくことによって、可能な限り高速で、可能な限りリアルタイムに近い形でハンドリングしていく。

更には我々自身のインターナルの運用だけではなくて、それをユーザー側もセルフサービス的に情報を取れるような形にしていくために、このAI Opsを拡張して様々なサービスにも統合していく形になっています。
具体的なところをいくつか説明、代表例としてご説明させていただきます。

ML主導の可用性のケーススタディ：ディスク障害の予測

一番わかりやすい例として、ディスク障害予測のご説明をします。
前段で、今グローバルで65を超えるリージョンを提供していて、そのｎ倍で非常に多数のデータセンターを運用している、凄まじい数のサーバー、凄まじい数のディスクが動いている、というご説明をさせて頂きました。

これらの膨大な数のディスクの運用状況を母データとして、母になるデータとして全て収集して、どういう証拠、どういう振る舞いをするとこのディスクは壊れるんだという凄まじい量のデータが手元に集まって来ます。

ここでしっかりマシンラーニングを食わせることによって、どうもこのディスクはそろそろ壊れそうな傾向にあるぞということを判断します。
ディスクが本当に壊れる前から、その影響を受けるところで動いている仮想マシンないしはリソースを、基本的にはライブマイグレーション等のユーザー影響を与えない形で違うハードや違うクラスターに移して、そのまま稼働を継続させるという運用を行っています。

さらにこれが徹底しているのが、上に乗っかったものを動かしたあと、そのディスクを止めずに、ほったらかします。
そのまま壊れるまでほったらかして、本当に予測通り壊れたかどうかというところまでデータを取ります。
という形で、マシンラーニングにデータを食わせ続けることによって、精度の向上に取り組んでいます。

これ以外にも、いわゆるAI Opsという形でResource Centralや、 Project Naryaと呼んでいる形で、様々な形でのAIを活用してサービス側に反映させる、ないしはキャパシティのところに関して柔軟に対応できるようにしっかりとなにかスパイクに近いものが起きた、ないしはその成長傾向があってリソースの枯渇が見えてくるようなところから、エンドユーザーさんないしは、他のサービス、Microsoft Azureはですね、Microsoft Teamsですとか、各サービスもAzureの中で稼働しているわけですが、放出しているわけです。
そういったさまざまな形のサービスに影響を与えないようにするために、様々な形でAIを使ったオペレーションを実現、実装しています。
当然障害やインシデントをゼロにするのは難しいですが、可能な限り稼働率を上げるという努力を続けています。

ここまでAI Opsという形でマシンラーニング、ディープラーニングのところでの観点での運用の成熟の話をさせて頂きましたが、違う観点でももう一つ運用に関するトピックスをお話しします。

Azure Digital Twins

　 AzureのDigital Twinsです。
Azure Digital Twins、これはIoTのサービスの一環として提供しています。
様々なIoTデバイスからデータを吸い上げて、それをデジタル化した、いわゆる双子チックなものを作って活用していきましょうという、いわゆるIoT関連のデジタルトランスフォーメーションのシナリオかと思います。

このAzure Digital TwinsもAzureのデータセンターの運用で活用しています。
レジリエントプラットフォーム、Resilient foundation of the Azure platfomと書かせて頂いていますが、設計、運用、監視全てをAIや、IoT、様々な最新のデジタルテクノロジーを使って、運用、成熟していくという取り組みを Azureとして、Microsoftとして実施させて頂いています。
ご紹介の動画がありますので、ご興味がありましたら是非ご覧ください。AzureのCTO、マーク・ルシノビッチがDigital Twinsをどういった形で活用していますということをデモを含めて解説しているセッションです。

https://youtu.be/69PrhWQorEM

Resilient foundation of the Azure platformということで、設計・運用・監視全てしっかりAIやIoT、様々な最新のデジタルテクノロジーを使って運用を成熟させていくという取組をAzureとして、Microsoftとして実施しているところが少しでも拾って頂けたら幸いです。

続いて二つ目のトピックに入ります。

我々はこの分散コンピューティングの時代に、Intelligent CloudにIntelligent Edgeというビジョンのもとに、Azureを提供していきますというところで、さまざまな形のサービスの提供や、自社のプラットフォームの運用、成熟の取り組みを進めています。

この世界観、なぜIntelligent Edgeが入っているのかということと、クラウド使って下さいということだけじゃないのが、なぜなのか。
ということで、ご紹介させていただきたいのが、次のスライドです。

このスライドで紹介している各種数字は、読んで頂ければ何を意味しているかをご想像いただけるかなと思います。

　これまで運用をしっかり一元管理していきましょうとか、ITガバナンス効かせてしていきましょうといったところを考えた場合、かつてのMicrosoftの2012,3年頃のWindows Serverサーバーと System Centerシステムセンターで話していた頃をちょっとイメージして下さい。
複数のデータセンターがあって、様々な数のハードウェア、サーバーがあって、Windows Server サーバーが物理マシン、仮想マシンでたくさんあって、拠点が2個、3個ありますと。

それはそれで運用大変でしたよね、ということも、僕自身も運用管理や導入に携わっていたこともあるので、よく認識しています。
しかし、今後はさらにそれが多様化して行きます。
数も莫大的に増えます。

この数字、そのものズバリですね。
IoTデバイスの数がどんどん増えて行って、そこから生まれていくデータも凄まじく増えて行きます。
この運用管理は、従来の自動化、一元管理から、より多様性が増して行くと思うわけです。

運用管理的なところが今回の主題にはなりますが、Microsoftとしてはこれら全てをしっかりカバーできるソリューション群が必要だと考えています。

前段お話させていただいたAzureの運用の自律化は、今後スライドでいうところのHyperscale cloud、一番右側のところの Azureの中身の話をしていたわけですけれども、Azureはいわゆるパブリッククラウド、メガスケールクラウドでサービスを提供しているだけではありません。

Azure Edge Zones、Azure Private Edge Zoneなどの開発も進めていますし、Azure Sstack family、具体的にはAzure Sstack Hubですとか、Azure Sstack HCIといったソリューション、またはIoT系でいうとAzureのIoTデバイス、さらには細部や末端のMCU、Micro computing unitとして、本当にものすごく小さなサイズのLinux kernelベースのソリューションのところまで提供しています。
末端からクラウドまで全てをカバーして行こうとしているのが我々Microsoft Azureとしての取り組みとなるわけです。

上段がいわゆるサービスとかソリューションの類のところで、下のところに Azure Arcがあります。
これが何を意味しているかというと、いわゆるクラウド側からエッジ側のところまで管理性とサービス、マネージドサービス、Paasの全てにおいて多様な世界で分散コンピューティングの時代に、やりたいことができるようにして行く必要があります。
Azure Arcでミドルウェアアッパーのスタック、ソフトウェアの管理、運用まで含めて提供していこうと考えています。
そこで後半は、この Azure Arcの部分にもう少しフォーカスをしてお話しさせて頂きます。

Azure Arc

　このAzure Arcが何かといいますと、Azureそのものをある種一つの大きなコントロールプレイと見立てます。
Azure上の動いている仮想マシンや、リソースの管理ができるのは当たり前ですが、そこの管理性、従来はいわゆるシステムセンターで提供していた様々な運用系のソリューション、バックアップや監視など、そういったところは今もうAzure上にはビルドインで入っています。

Azure buckupBackupや、Azure Mmonitor、Azure Aautomation、そういった形でビルドインで入っているわけですが、これまでAzure上のリソース、Azure上の仮想マシン、Azure上のマネージドサービスのバックアップや監視、そういったことに対応してきました。

前段でお話しした通り、今後はより一層コンピューティングリソースが使える領域、使えるデバイス、動くものがどんどん増えていきます。
こうなってくると、これを一元的に管理していく、一貫性を担保した管理をしていくといったところが非常に重要なポイントになってきます。
そのために我々は Azure Arcを提供しているのです。

これは順次さまざまな形で、“Azure Arcなんとか”という形で、様々なサービスソリューションの提供を進めているので、Azure Arcという一つのサービスがどんと出てきておしまいというわけではありません。
次にその具体的な中身をご説明します。

　 Azure Arcには大きく2つのカテゴリーがあります。
Azure Arc enabled InfrsdtructureというカテゴリーとAzure Arc enabled Serviceという2つのカテゴリーのもとに、さまざまな形でサービスやソリューションを開発したり、機能追加を図っています。

Azure Arc enabled Infrsdtructure、これはある種簡単でして、いわゆるインフラ的なところをAzure Arcをでくっつけます。 Azureをコントロールプレーンプレイ、管理基盤としてつなげることによって、さまざまなインフラ、サーバー管理のところ、 Azure上のIaaSSの仮想マシンだけではなくて、オンプレの仮想マシンや、他社様のクラウド上にあるIaasSの仮想マシンをつなげることによって、 AzureのリソースIDが振られ送られます。
Azureのファーストパーティの管理機能ですとか、マーケットプレイスから提供させていただいているサードパーティさん、パートナーさんの Azureを活用できる管理系の機能、そういったところもAzure外のリソースにも提供していきましょうよというのがAzure Arc enabled Infrsdtructureです。

他方、Azure Arc enabled Service、これは何かと言いますと、Azure上で稼働するマネージドサービス、Paas、これを Azure外にも提供しますというものです。

例えばApp Serviceアップサービス、Data Servicesデータサービス、Machine Learning マシンラーニングのサービス、こういったものを、コンテナをモジュール化して、その他のプラットフォーム、 Azure上だけではなくて、Azure外にも提供して行こうというのがAzure Arc enabled Serviceです。

もう少し技術的に説明します。

　既存の Azureの世界観はこんな感じです。
ユーザーさんがいて、ツールの AzureのポータルやAzure CLI、そういったものから働いて、運用管理ないしは利用していただいている状態です。

その中で、Azureのリージョン上で各種リソースが動いていて、それを制御するツール群を使って頂く、または開発運用するための機能を使って頂くという形でした。
これを Azure Arcによってどう拡げようとしているかというと、こういう形で広げようとしているわけです。

　 Azure Arc enabled Infrastructure、Azure Arc enabled Serviceという形で、 Azure Arcというインターフェースを利用し、Azure 自体をその制御基盤、コントロールプレーンプレイとして扱えるようにして、のところに下請けして、実際のリソースやあとはインフラの部分、実際に動いている場所の部分、これはオンプレのデータセンター、Hエッジネットワークサイト、または他社様のクラウド、マルチクラウドもカバーするようにします、と。のところに対してもAzure Arcを介してAzureのコントロールプレーンとしての機能プレイとしての部分、上から2つの部分を機能としてを提供するものだとご理解ください。提供していきます。

さらには管理機能だけではなくてマネージドサービスも提供していきますというのが、このAzure Arcの基本的な方向感になっています。

本日はですね、OpsSummitですので運用にフォーカスをあてていく形でお話ししたいと思います。

一番わかりやすく、なおかつすでに一般提供、開示しているものとしてAzure Arc enabled Serverというものがあります。

Azure Arcを介することによって、AzureのIaas上の仮想マシン、Windows、Linux問わず、さまざまな管理機能があります。
Azure Backupバックアップ、Azure Monitorモニター、Azure Automationオートメーション、さらにまさにAzure Automanageオートマネージという形で半自動的に管理を実現する機能も、プレビューですが提供しています。
そういった機能をですね、 Azure外のリソースにも提供して行きましょうと、その中でも一番最初に出てきた機能がAzure Arc enabled Serverです。

Azure Arcのいわゆるコネクテッドエージェントという名前で呼ばれています。
Azure Arcにつなげるためのコンポーネントをサーバー環境に入れて頂きます。
WindowsでもLinuxでもいいのですが、それをつなげて頂くとAzureとしてのリソースIDが振られます。送られてきます。

Azure Backupバックアップ、Azure Monitorモニター、Azure Automationオートメーション等のAzureの機能、運用管理系の機能、ソリューションはもちろんAzure Security Centerセキュリティセンター、Azure Defedarディフェンダーみたいなところも含めて使えるようになりますし、当然リソースID送られてきますのでサードパーティーのソリューション群も対応していける形になっています。

と言われても、この言葉だけでの説明だとなかなかわかりにくい、イメージがつきずらいと思いますので、ちょっとデモで実際の Azure Portalポータル上でのどういうふうに見えるか、どういった形で使えるかをご説明します。

　早速クリックして中に入っていきましょう。
今日はAzure Arc enabled Serverのお話ですので、主題はAzure Arc enabled Server、Azure Arc enabled Infrastructureの中のサーバーになりますが、それ以外にも、KubernetesやSQLサーバー、Azure Sstackも画面上は見えていますし、Azure Arc enabled Service、Paas、Managed Serviceを Azure外にも提供していきましょうというものですが、それぞれプレビューのものになりますが、データベース、アプリケーションのPaaSsなども見えています。

ではサーバーに入っていきましょう。
これは私のデモ環境ですが、3台ほどつないであります。
具体的に何がつながっているかと言いますと、オンプレの環境でWindowsとLinuxをそれぞれつなげています。
どこにあるかと言いますと、 Microsoft品川Office、略称SDGTと言われておりますので、タグもSDGTとつけています。
それと加えてもう一台、Azure外で動いている別サーバもArcでつなげてあります。
具体的にどういった形で見るかもご説明しますが、比較のためにも Azure Arcのenabled Serverとしてつながっているものだけではなくて、 AzureのIaaSsの仮想マシンも一つ作っています。

　通常のIaaSsの仮想マシンですと、こういった形で色々な管理機能がついていて、色々なメニューも出ていますが、似たような形で、Azure Arc enabled Serverで管理可能になっている状態からすると、数は少ないですけれども、似たようなUIで扱える形になっております。

当然ここら辺、さまざまな管理機能をより一層充実させていくということは今後のアナウンスとしても出ていますので、ご期待いただければと思います。
具体的にどういったものが見えているかというと、まずはオンプレミスにあるLinuxの仮想マシンですね。
各種プロパティのところに見える形になっているのんですけれども、具体的にはこの拡張機能のところでエクステンションとしてOMS Agentとか、こういったものをプッシュインストールしてさまざまな管理機能が使える形になっています。

当然ながらAzure Policyポリシーで管理もできますし、更新プログラムの管理、インベントリ、どういったソフトウェアが入っているか、デーモンデモが動いているなどといったところも見える形になっています。
チェンジトラッキングという形で、いつどこで何がどういう変更を走ったかというところも、オンプレ側もしっかり見える形になっています。

いわゆるAzure Monitorモニターの Insightインサイトになりますけれども、ここで見ていくと、どういった形で動いてますと、パフォーマンスデータも俯瞰して見えるわけです。

当然のごとく、Windows Serverサーバーに関しても同様に管理ができますし、パフォーマンスのデータなども見ることができます。もちろんオンプレイスだけでなく、他のクラウド上の環境についても同じように見えます。
これを個別に見ていくと、それなりに便利かなと思いつつ、一元的な管理というメリットがわかりにくいかなと思いますので、ちょっと見方を変えましょう。

Azure Arc自体はつなげていく、いわゆるエージェントハブにはなりますが、具体的には管理機能は通常のAzure上でも使われているさまざまな管理サービスの類が関係していきます。
Azure Automationオートメーションですとか、Log Analyticsログアナリティクスのワークスペース、 Azure Monitorモニターなどが関係してきますが、それぞれのサービスのほうから見ていくと、少し見え方が変わってきます。

具体的にAutomation Accountオートメーションアカウントのほうで見ていきましょう。
ここで見ていくと、更新プログラムの管理ですね。
今ここで見えている通り、これは先ほど比較のためにお見せしたAzureのIaaSsの仮想マシンです。
それ以外、これ、Azure以外、Azure Arc enabled Serverのサーバーでつながっているサーバー群です。