再構築のハウツー: 業界トップの世界規模のクラウド サービスに進化した Intune

本日は、社内でのみ使用するために書いたブログ記事を公表したいと思います。Microsoft では通常、このようなことは行っていません。

読者の皆さんは、「では、なぜこの情報を公開するのか」と疑問に思われることでしょう。まず、その疑問にお答えします。

端的に申し上げます。独自のデジタル トランスフォーメーションを進めているお客様に会うと、IT チーム (およびそのリーダー) は、インフラストラクチャやアプリをどのように拡張するかという問題と格闘している話をよく耳にします。そこには、クラウド内のものだけではなく、トランスフォーメーションの過程でクラウドのために必要となるものも含まれます。

私は、その大変さが非常によくわかります。なぜなら、かつて私も同じ経験をしたからです。

今回下記の情報を公表する目的は、私たちが自身のグローバルなクラウド サービスを構築した過程を公開して、お客様が独自のクラウドを構築する取り組みの中で、この情報を青写真として役立てもらうことにあります。

Intune は、クラウドから作成され、そしてクラウドのために作成されたものです。そして最終的には、世界をリードするモビリティ サービスとなり、真のクラウド規模を提供する唯一のサービスとなりました。

このアーキテクチャは、お客様が生産性や規模の限界に突き当たることなく、目標を達成し、データの安全性確保と知的財産の保護を実現するのに最適な方法です。

最初から何かを作り上げ (文字どおり、[ファイル]、[新規] のように)、その後、作ったものを運用し、それを毎日数十億件ものトランザクションを処理するような大規模なクラウド サービスにまで昇華するという作業は、めったに経験できることではありません。

Intune の構築はまさにこのような希少な機会で、やりがいのある経験でした。

このブログ記事で私にとって特に印象深いのは、この作業をやり遂げたエンジニアの非凡な才能です。他に言いようがありません。  今日の巨大な (そして常に成長を続ける) モバイル管理市場を見渡してみると、Intune は、真のクラウド サービスという点で際立っています。他のソリューションも、クラウド モデルがあると謳っていますが、根本的にそれらはクラウド サービスとして構築されたものではありません

今や Intune エンジニアリング チームは、大規模なクラウド サービスを完成するまでのハウツーについて、定期的なプレゼンテーションを依頼される Microsoft チームの 1 つになりました。私たちが Intune に着手した頃、Azure は、数人の非常に優秀なエンジニアの間で生まれた、かすかな光にすぎませんでした。このため、初期のアーキテクチャは Azure をベースとしたものではありませんでした。2015 年に Intune の利用率が実際に増え始めた状況を見て、私たちは、クラウドベースのマイクロサービス アーキテクチャに基づいて構築された最新の Azure サービスにするために、Intune を再構築する必要があることを認識しました。

結果的に、これは歴史的な決断になりました。

振り返ってみると、この決断がそれほどまでに重大だった理由は明らかです。  サービスが数千万、数億、そして数十億のデバイスやアプリへと拡張されていくと、期待される信頼性、拡張性、品質を提供できるのは、クラウドベースのアーキテクチャしかありません。また、クラウドベースのアーキテクチャがなければ、エンジニアリング チームは、お客様のニーズに十分な速さで対応することはできませんでした。

この変更を行って以来、数えられないほど多くのお客様からコメントが届きました。実際に体験された信頼性やパフォーマンスの変化に関する感想だけでなく、私たちが新しい技術革新を提供する速度についてもご意見をいただきました。

これはすべてアーキテクチャのおかげです。 アーキテクチャは本当に、本当に重要です。

このアーキテクチャに関するこのような見解は、Intune の再構築を決定するに何百時間もかけて他のソリューションを調べた結果生まれたものです。私たちは、Intune の再構築を始める前に、競合するさまざまなソリューションの分析と評価を徹底的に行い、Intunes を再構築するのではなく、競合するソリューションを購入すべきかどうかを検討しました。検討したソリューションはいずれも、クラウド サービスではありませんでした。1 つもなかったのです。どれも、クラウド サービスと呼ばれてはいるものの、データセンターでホストされる従来型のオンプレミス クライアント サーバー製品で、

ハイパースケールに向かうための手段ではありませんでした。

製品がクライアント サーバー モデルであるか、それともクラウド サービスであるかを簡単に見分ける 1 つの方法は、バージョン番号があるかどうかです。たとえば、”製品 X v8.3″ のようなものがあれば、それはクラウド サービスではないことがすぐにわかります。  サービスが 1 日に複数回更新されるクラウド サービスには、バージョン番号のようなものはありません。

私は、Intune の将来を楽しみにしています。なぜなら、クラウド サービスのみが成し遂げられるシナリオがあるからです。つまり、Intune エンジニアリング チームは、競合他社がまだ見つけることさえできていない問題に対するソリューションを、既に提供しているということです。そしてこれは、このチームが持つ専門知識により、お客様のニーズの予測とそれに対する対応が今後も加速し続けることを意味します。

エンジニアリング チームのリーダーとして、お客様のために構築するサービスやツールにとってこれが何を意味するかについて、またお客様から新しいプロジェクトや新しい課題の相談を受けたときに可能な対応方法について考えるのは、非常に刺激的なことです。

Intune にまだ移行されていなければ、この記事をお読みください。その後、ご連絡ください。

 


 

Intune が拡張性の高い、グローバルに分散されたクラウド サービスになるまでの道のり

 

Enterprise Mobility + Security (EMS) の一部である Intune が、Microsoft の歴史の中で最も成長の早いビジネスとして進化していく道のりは、2015 年後半頃から始まりました。このビジネスが急速に発展していくなかで、それに伴うバックエンド業務が大幅に急増し始めました。同時に、Intune、Azure、その他の独立した分野でのさまざまなサービス領域で技術革新を行ってきました。短期間で技術革新と急速な成長を両立させることは、Intune で私たちが直面した、やりがいのある、そして困難な挑戦でした。私たちはいくつかの緩和策を講じました。ただし私たちが望んでいたのは、拡張性とパフォーマンスに関して時代を先取りすることでした。この成長におけるスピードは、より成熟した拡張性の高い、グローバルに分散されたクラウド サービスにするための取り組みを加速させるための号砲のようなものでした。それから数か月間、サービスの構築、操作、運用方法の大幅な変更に取り組みました。

このブログは、Intune のクラウド サービスが、Azure で実行される最も成熟した拡張性の高いクラウド サービスになるまでの道のりを 4 回に分けて紹介するシリーズです。現在 Intune は、可用性、信頼性、パフォーマンス、拡張性、セキュリティ、機敏性の 6 つの柱を常に改善しながら、大規模に運用される最も成熟したサービスの 1 つになっています。

アーキテクチャと背景、そして顧客満足度を向上し、ビジネスの成長を促進するための迅速な受動型の措置。

  1. 近い将来の成長に備えるための積極的な対策と行動。
  2. 可用性と拡張性が高く、他の大規模な最高レベルのサービスと同等のサービスになるまで成熟させるための措置。
  3. 分散システムでの各種の大規模な運用の模範となる先駆的なサービスへの道のり。

このブログ シリーズの各回では、トピックについて簡潔に説明するだけでなく、私たちが得た教訓についての要約を説明します。以下の説明は、この 4 回シリーズの 1 回目になります。残りの 3 つのトピックについては、今後のブログで説明します。数か月以内に掲載する予定です。

背景とアーキテクチャ

2015 年当時、Intune は、社内のデータセンターでホストされている物理マシン上で実行される一連のサービスと、Azure で実行される一連の分散型サービスを組み合わせたものでした。2018 年までに、すべての Intune サービスは、Azure 上で実行されるサービスに移行されました。今回のブログ (また今後のブログ) では、Azure 上で実行される分散型サービスのみを取り上げます。物理マシン上で実行されているサービスを Azure に移行する作業は、Intune の再構築とは異なる取り組みであるため、おそらく今後別のブログとして掲載することになるでしょう。以下では、2015 年当時の背景とアーキテクチャに焦点を当てて説明します。

アーキテクチャの全体図

Intune のクラウド サービスは、Azure Service Fabric (ASF) 上に構築されています。すべてのサービスは、フロントエンド (FE) ノードと中間層 (MT) ノードのグループで構成される ASF クラスターに展開されます。FE ノードは、A4 SKU (14 GB、8 コア) でホストされます。MT ノードは、A7 SKU (56 GB、8 コア) でホストされます。クラスターは他のクラスターと完全に分離され、独立しています。クラスターはまったく別のサブスクリプションとデータセンターでホストされているため、どんな方法や形式でも相互にアクセスすることはできません。このような ASF クラスターが世界中に 18 あり、北米 (NA)、欧州 (EU)、アジア太平洋 (AP) の 3 つの地域に分散しています。各 ASF クラスターには同じサービス セットが展開されており、同じ機能を実行します。これらのサービスは、ステートレス サービスとパーティション分割型ステートフル サービスで構成されます。図 1 は、アーキテクチャの全体図を示しています。

図 1: Intune のグローバル クラスター (別名: Azure スケール ユニット (ASU) – アーキテクチャ図 (2015) SKU (14 GB、8 コア)。MT ノードは、A7 SKU (56 GB、8 コア) でホストされます。

クラスター アーキテクチャのドリルダウン

各クラスター内では、80 以下の固有の種類のステートレス マイクロサービス セットと 40 以下の固有の種類のステートフル マイクロサービスを含む 5000 以上のサービスがあります。ステートレス サービスは、Azure ロード バランサーによってルーティングされたすべての FE ノードで複数のインスタンスを実行します。ステートフル サービスといくつかの重要なステートレス サービスは、MT ノードで実行されます。ステートフル サービスは、社内で No-SQL データベースとして構築されたインメモリ アーキテクチャ (2015 年にここで説明した内容を思い出してください) に基づいて構築されます。

実装されたステートフル インメモリ ストアは、AVL ツリーとハッシュ セットを組み合わせたもので、非常に高速の書き込み、取得、テーブル スキャン、セカンダリ インデックス検索を可能にします。これらのステートフル サービスは、スケール アウトのためにパーティション分割されます。各パーティションには、可用性を処理するために 5 つのレプリカが含まれます。この 5 つのうち 1 つはプライマリ レプリカとして機能し、すべての要求がここで処理されます。残りの 4 つは、プライマリから複製されたセカンダリ レプリカです。一部のサービスは、データ操作について厳密な整合性を必要とします。これは、書き込み要求を満たすためにレプリカのクォーラムが必要であることを意味します。これらのシナリオでは、CAP 定理により AP より CP の方が優先されます。つまり、レプリカのクォーラムが使用できない場合、書き込みは失敗し、そのため可用性が失われます。一部のシナリオでは、結果整合性に問題はなく、CP より AP を優先することによる利点もあります。しかし、単純化するために、初期のアーキテクチャでは、すべてのサービスで厳密な整合性をサポートしていました。現在は、CP が優先されています。

ASF はさまざまな面で優れており、その 1 つは、サービスがクラスター全体に密に詰め込まれていることです。各 MT ノードで実行されるプロセスの一般的な数は 30 から 50 で、複数のステートフル レプリカをホストします。さらに、レプリカのフェールオーバーおよび移動の管理とオーケストレーション、すべてのサービス展開のローリング アップグレード、クラスター全体の負荷分散などの複雑な作業をすべて処理する点でも優れています。万一プライマリ レプリカがダウンした場合、ASF によってセカンダリ レプリカがプライマリに自動的に昇格され、新しいセカンダリ レプリカが構築されて、5 つのレプリカ要件を満たします。新しいセカンダリ レプリカは、プライマリからセカンダリへの完全なメモリ間データ転送を開始し、完了します。さらに、障害またはパーティション損失が発生してすべてのレプリカが消失した場合に復旧できるように、データは Azure テーブル/Blob を保管する外部の永続記憶域に定期的にバックアップされます。RPO は 10 分です。図 2 は、クラスター図を示しています。図 2 は、クラスター図を示しています。

スケール図 2: Intune の Azure スケール ユニット (別名: クラスターまたは ASU) のアーキテクチャ (2015)。障害またはパーティション損失が発生してすべてのレプリカが消失した場合から復旧するための RPO。図 2 は、クラスター図を示しています。図 2 は、クラスター図を示しています。

問題

前述のとおり、2015 年末から 2016 年初めの利用率の急増 (1 日あたりのトランザクション件数は約 3 bn から 7 bn に増加) に伴い、バックエンド サービスではトラフィックの大幅な増加が見られ始めました。そこで、早急に緩和措置を講じて、このような「成長の痛み」によって生じた問題に対処するための戦略的なソリューションの考案について検討を開始しました。

問題 #1:

最初に認識したのは、適切なテレメトリと警告が必要であるということでした。この時点では、基盤となる Azure インフラストラクチャの急速な技術革新の結果、テレメトリを必要とする規模も広がり、また一般提供のタイミングなどが理由となり、テレメトリをただちに活用することができませんでした。このため、戦術的な観点から、緩和策を開始するための十分なデータを取得できるように、いくつかの計測/診断ソリューションを早急に考案する必要がありました。適切なテレメトリを取得できるようになると、「最大の安心感」を実現するために解決しなければならない最も重大な問題に関するデータの収集を開始しました。

テレメトリにすばやく投資したおかげで、大きな効果がありました。戦略的ソリューションの調査と決定、そしてその繰り返しを短期間で行うことができました。残りの問題はすべて、この短期間に発生したものですが、テレメトリへの投資の効果は絶大でした。

問題 #2:

私たちはテレメトリから、一部のパーティションが膨大な量のデータを処理していることに気づきました。1 つのパーティションに、数百万ものオブジェクトが格納される場合もあり、トランザクションの回数は、クラスター全体で 1 日あたり最大 60 億回にも達していました。データ量の増加は、既存のプライマリ/セカンダリ レプリカがダウンしたとき、または負荷分散が必要になったときに、セカンダリ レプリカを構築する必要が生じた場合にデータ転送が増加することを意味します。データ量が増えれば増えるほど、セカンダリ レプリカの構築に要する時間も長くなり、それに伴ってメモリおよび CPU のコストも増加します。

この時間の大半は、再構築中にレプリカ間で転送する必要があるデータのシリアル化とその解除にあてられました。私たちはデータ コントラクト シリアライザーを使用していましたが、いくつものシリアライザーのさまざまなパフォーマンスを調査した結果、使用するシリアライザーを Avro に変更することにしました。Avro により、スループットと CPU 使用量が 50% 改善され、再構築に要する時間も大幅に短縮されました。たとえば、4 GB のデータ転送の場合、最長 35 分を要していた再構築が 20 分以下で完了するようになりました。これは最善とは言えませんが、私たちは緊急の措置だと考えました。そういう意味では、このソリューションは有効でした。次回のブログでは、この再構築の時間を 20 分からさらに短縮して数秒にした方法を紹介します。

問題 #3:

利用率の増加は、効率的に (CPU/メモリ単位) 処理できるように十分最適化されていなかったアルゴリズムに、新しいトラフィックと検索パターンをもたらしました。AVL ツリーを使って効率的なセカンダリ インデックス検索を設計していましたが、特定の検索パターンについては、さらに最適化することができました。当初私たちは、通常のセカンダリ インデックス ツリーは、フル テーブル スキャンを実行するメイン ツリーよりもサイズが小さく、すべてのニーズに対応できるはずだと考えていました。しかし、CPU 使用量が増加する問題をいくつか調べると、特定のセカンダリ インデックス検索で、CPU が固まってしまうトラフィック パターンがあることに気づきました。詳細に分析すると、セカンダリ インデックス内に数百万個のオブジェクトがあると、ページングと検索による並べ替えにより、CPU 使用量が極端に増加し、そのノードで実行されているすべてのサービスが影響を受けることがわかりました。

これは非常に有用な分析情報だったので、私たちはただちに対応し、代替のアルゴリズムを設計することができました。ページングと検索による並べ替えについては、AVL ツリーの代わりに、最大ヒープ アプローチを設計して実装しました。最大ヒープでは、挿入と検索の時間計算量が桁違いに改善されます。100 万個のオブジェクトの場合、挿入は 5 秒から 250 ミリ秒に短縮され、order by (基本的には並べ替え) は 5 秒から 1.5 秒に改善されました。これらの種類の操作を実行する検索クエリの件数を考えると、この改善は、クラスター内のメモリと CPU の使用量の大幅な節約になりました。

問題 #4:

データ増加の影響が最も大きかったのは、展開とアップグレードのときでした。OS のパッチ適用スケジュールの一環として、FE ノードと MT ノードが Azure によって再起動される際には、この問題がさらに悪化しました。これらのノードは、アップグレード ドメイン (UD) 別に順次再起動されます。各 UD が完全に機能するようになり、次の UD のアップグレードに移るまで最悪 20 分かかりました。

アップグレードでは、次の 2 種類の問題に直面しました。

  • ステートフル サービスのレプリカ数は、UD の数と等しく、両方とも 5 つでした。このため、1 つの UD をアップグレードする場合、ASF は、さまざまな制約 (障害ドメインの配置を維持するためにレプリカを適切に分散させる、プライマリとセカンダリを同じノードに配置しないなど) を維持しながら、すべてのレプリカをその UD から他の 4 つの UD に移動する必要がありました。したがって、アップグレード中、かなりの量のレプリカの移動と密度が必要でした。上記の問題 #2 から、一部の再構築には最長 20 分かかることがわかっていました。つまり、セカンダリ レプリカは、次の UD のアップグレードまでに十分な準備ができていないことになります。この結果、クォーラムを失うことになりました。アップグレード中に書き込み要求を満たすのに十分な数のレプリカがアクティブではなかったためです。図 3 は、アップグレード中のレプリカ密度の変化を示しています。サービスの 1 つで、レプリカの数が 350 以下から 1000 以下に急増している部分は、多数の再構築が発生していることを示しています。緊急の対応策として、ノードの SKU 数を増加することにしました。これによって多少緩和されますが、基盤となるインフラストラクチャは、SKU のインプレース アップグレードをサポートしていません。  このため、新しいクラスターにフェールオーバーする必要がありましたが、これは、データの移行が必要であることを意味します。その手順は非常に複雑なので、このアイデアを断念しました。今後のブログ記事のいずれかで、この制限をどのように克服したかを説明します。
  • Intune チームと ASF チームは、この問題を詳細に分析し、ASF チームの助けを借りて、最終的に 4 つのレプリカと 5 つの UD を使用するのが最適な構成であるという結論に達しました。そうすれば、常に 1 つの UD は追加のレプリカを受け入れることができ、レプリカの過度の移動も回避できます。この結果、クラスターの安定性が大幅に向上し、アップグレード中に 3 倍に増えるレプリカの密度が、50 から 75% 減少しました。

 

図 3: アップグレード中のレプリカ数と密度の変化

 

最終的に、クラスター内のレプリカ数とメモリ使用量のバランスも改善されることがわかりました。いくつかのノードは使用率が高く、その他のノードはほとんどアイドル状態でした。このため、トラフィックの急増またはアップグレードが発生すると、負荷の高いノードに過度の負担がかかることは明らかでした。解決策として、クラスターに負荷分散指標、レポート、構成を実装しました。この効果を図 4 と図 5 にわかりやすく示します。青色の線は、改善後の負荷分散を示します。X 軸は、使用しているノードの名前です。

 

図 4: 負荷分散の改善前と改善後のノードあたりのレプリカ数。

 

図 5: 負荷分散の改善前と改善後のノードあたりのメモリ使用量。

 

教訓

  • この経験から得た教訓のうち、大規模なクラウド サービスに応用できると思われる上位 4 つについて説明します。
  • 設計の最も重要な要素の 1 つとして、テレメトリと警告を含めます。実稼働前の環境で、テレメトリと警告を監視し、繰り返し改善を行ってから、その機能を実稼働環境で顧客に公開します。
  • 依存関係を把握します。スケール ソリューションが、依存するプラットフォームと一致しない場合、すべてがむだになります。たとえば、スケール アウトするソリューションが 10 ノードから 500 ノードに増加する場合、依存するプラットフォーム (Azure、AWS など) がその増加をサポートするかどうか、およびそれに要する時間を確認します。たとえば、一度に数ノードずつ増加するという制限があれば、この遅延を考慮するように対応メカニズム (警告など) を調整する必要があります。同様のもう 1 つの例はスケール アップです。スケール アップ ソリューションが、SKU のアップグレードである場合、依存するプラットフォームが、パフォーマンスの低い SKU からパフォーマンスの高い SKU へのインプレース アップグレードをサポートしているかどうかを確認します。
  • 想定を継続的に検証します。多くのクラウド サービスとプラットフォームは今もなお進化しているので、ほんの数か月前の想定は、多くの点で有効ではなくなっている可能性があります。たとえば、依存するプラットフォームの設計/アーキテクチャ、代替可能なより優れた/最適化されたソリューション、廃止された機能などがあります。有効性を検証するには、コア コードのパスを監視してトラフィック パターンに変更がないかどうかを確認する、既存の設計/アルゴリズム/実装がまだ有効であるかどうかを確認するなどの方法があります。クラウド サービスのトラフィック使用パターンは変更される可能性があります。また、数か月前は有効だったソリューションが今はもう最適ではなくなっている可能性もあるので、より効率的なものに改訂/交換する必要があります。
  • キャパシティ プランニングの実施を優先します。予測キャパシティ分析の方法を決定し、それを必ず定期的に見直します。こうすることで、顧客に影響が及ぶスケール問題について事前対応か、事後対応かを区別することができます。

結論

上記のすべてのソリューションを実装し、ロールアウトするには、約 3 から 4 か月かかりました。2016 年までには、大きな励みになるような成果が現れました。クラスターの安定性、可用性、信頼性が著しく向上しました。これは、私たちが行った信頼性と安定性の改善に対して、お客様から肯定的な意見や反応をいただいたことからも感じられます。これは大きな励みとなる一歩ですが、上記の改善作業から、さらなる改善に向けて前進するためのあらゆる教訓が得られました。成熟した拡張可能な分散型クラウド サービスまでの道のりは始まったばかりです。


本ブログの投稿で説明している機能の内容は、国/地域によって異なる場合があります。お住まいの国/地域で提供されている特定の製品の詳細情報については、Microsoft 365Office 365Windows 10Enterprise Mobility + Security をご覧ください。
本ブログの投稿からリンクしているコンテンツは、日本語訳が存在しない場合があります。
本情報の内容 (添付文書、リンク先などを含む) は、作成日時点でのものであり、予告なく変更される場合があります。