メイン コンテンツへスキップ 施設一覧 Saga Aomori Akita Yokote Sendai Fukushima Seaside Toranomon Ningyocho Hamamatsucho Shibuya Gumma-Takasaki Utsunomiya Niigata-Kamo Joetsu-Myoko Kanazawa Nagano Nagoya-Motoyama Yokkaichi (Temporary Closed) Fukui Ritsumeikan Nishi-Umeda Hiroshima Fukuoka Kagoshima Naha イベント / セミナー ブログ コンテンツ ポータル 外部サイトリンク 利用規約 Office Windows Surface Xbox セール サポート Windows アプリ OneDrive Outlook Skype から Teams への移行 OneNote アクセサリ Xbox ゲーム (ダウンロード) Windows ゲーム 映画とテレビ番組 Azure Dynamics 365 Microsoft 365 データ プラットフォーム 法人向け .NET Visual Studio Windows Server Microsoft 開発者 ドキュメント Microsoft Store Microsoft Rewards 無料ダウンロード & セキュリティ プリペイド カード サイトマップの表示
同僚と会話しながらデジタルタブレットを操作する男性
Microsoft Base ロゴ

技術ブログ

Azureに関する技術情報

Microsoft Azure によるマイクロソフト自身のクラウド移行の学び

2021.06.22 Azure

Share this page on

本ポストは以下の記事の翻訳です。

Boosting Microsoft’s migration to the cloud with Microsoft Azure

2021 年 2 月 2 日 |Lukas Velush

オフィスのデスクに座っている人がキーボードの近くで両手でジェスチャーをしています。デュアルモニターには宇宙をテーマにした画面が表示され、背後の壁にはメダルが掛けられています。

マイクロソフトがクラウドへの移行を開始したとき、多くのことを学ばなければならなかったと、Microsoft Core Services Engineering (CSE) のプリンシパル サービス エンジニアである Pete Apple は述べています。移行はほぼ完了していますが、学んだことはどうなったのでしょうか? 「それらは製品に反映されています」と Apple は言います。(写真: Jim Adams | Showcase)

マイクロソフトが 60,000 台のオンプレミス サーバーによって処理されている大量の内部ワークロードをクラウドに移行し、無秩序に広がったいくつかのデータセンターを閉鎖する取り組みを開始したとき、そこにあったのは、すべてを Microsoft Azure に移行するように求めた経営者の 1 つの指示だけでした。

「今すぐクラウドへの移行を開始せよ。」

チームとして多くのことを学ぶ必要がありました。まずは Azure のいくつかのサブスクリプションから開始しました。いろいろ調べて見て回り、それらを理解し、どれだけの作業が必要かを調査しました。

– Pete Apple、プリンシプル サービス エンジニア、Core Services Engineering

2014 年は、マイクロソフトのような既存のシステムに深く依存する大企業がクラウドへの移行を始めて間もない頃でした。そうした移行を担当する IT のプロ達にとって、ツールは少なく、移行の方法を示すガイダンスもほとんどありませんでした。

「チームとして多くのことを学ぶ必要がありました」と、Microsoft Core Services Engineering (CSE) のプリンシパル サービス エンジニアである Pete Apple は述べています。「まずは Azure のいくつかのサブスクリプションから開始しました。いろいろ調べて見て回り、それらを理解し、どれだけの作業が必要かを調査しました。」

多くの作業が必要なことが判明しました。その後すぐに、さらに多くの作業が必要だとわかりました。

それから 7 年が経過し、マイクロソフトのクラウドへの移行は 96% 完了し、学んだ教訓は長いリストになります。6 か所の IT データセンターが廃止され、まだ移行されていないオンプレミス サーバーは 800 台以下となっています。かつて 60,000 台のサーバーによって処理されていた大量のワークロードはどうなったのでしょうか? 最新のエンジニアリングを組み合わせて企業内アプリケーションを再設計し、使用されていないワークロードをそぎ落とすことによって、その数が減少しました。マイクロソフトは現在、Azure 上の 7,474 台の仮想マシンと、オンプレミスの 1,567 台の仮想マシンによって運営されています。

「私たちがこの過程で学んだことは製品に反映されています」と Apple は言います。「さまざまな問題を経験しましたが、現在はとてもスムーズです。私たちの多くの苦労を伴う経験は、現在では他の企業が (移行を) 簡単に行うのに役立っています。」

意思決定フレームワークの利点

マイクロソフトの内部ワークロードの Azure への移行は、最初は困難が伴いましたが、現在ではとてもスムーズに行われていると Apple は言います。次に示すような意思決定ツリーの使用を開始してから、すべてがより適切に進むようになったと彼は説明します。

CSE のクラウド移行の意思決定ツリー

CSE のクラウド移行の意思決定ツリー

クラウド移行チームはこの意思決定ツリーを使用して、60,000 台のオンプレミス サーバーをクラウドに移行する作業を乗り切りました。(グラフィック: Marissa Stout | Showcase)

最初に、CSE 移行チーム メンバーは次のような問いを立てました。「まったく新しいエクスペリエンスを構築しているのか?」この答えが「はい」の場合、意思決定は簡単です。クラウドでネイティブに構築する利点をフルに活用して最新のアプリケーションを構築します。

答えが「いいえ、既存のアプリケーションをクラウドに移行する必要がある」の場合、意思決定ツリーはより複雑になります。チームはいくつかの難しい質問に答えていく必要があります。

PaaS (サービスとしてのプラットフォーム) のアプローチを採用するか? クラウドの利点をフルに活用するためにエクスペリエンスをゼロから作り直すか? (どの企業もこれを行うのに必要な時間や予算を確保できるわけではありません。) または IaaS (サービスとしてのインフラストラクチャ) のアプローチを採用するか? この場合はリフト&シフトと、将来、構築し直すことが理に適うようになったときのための計画とが必要です。

この質問には次の 2 種類のアプリケーションが関連しています。サードパーティ ベンダーによってマイクロソフト向けに構築されたアプリケーションと、CSE またはマイクロソフト内の他のチームによって構築されたアプリケーションです。

サードパーティのアプリケーションの場合は柔軟性に制限があります。PaaS アプローチを採用して最初から構築し直すか、Azure IaaS にリフト&シフトするかのいずれかを選択することになります。

「内部アプリケーションの場合はより多くの選択肢があります」と Apple は言います。彼は、アプリケーションをミッションクリティカルなものと、そうでないものに分けることができると説明します。

ミッションクリティカルなアプリケーションの場合、チームは最初に、ゼロから構築し直して最新化を行うのに必要な予算とエンジニアリングの時間を確保することを目指します。「これは理想的なシナリオです」と Apple は言います。予算が確保できない場合は、最新化が可能になったときにそれを行う計画を立てながら、IaaS のアプローチを採用することになります。

その結果、ミッションクリティカルでないプロジェクトではリフト&シフトが行われ、そのプロジェクトが不要になるまでそのままの状態が維持されます。該当のタスクを吸収する新しい何かが構築されたときにこのプロジェクトをシャットダウンする、または状況に合わなくなったらそのまま廃止する、という考え方です。

「多くの場合、ミッションクリティカルでないアプリケーションを維持していくための専門知識を私たちは有していませんでした」と Apple は言います。「それらのアプリケーションの開発に携わった多くのエンジニアは、他のチームまたは他のプロジェクトに移っていきました。私たちは、そのエクスペリエンスの一部が再び重要になれば、それについて新しい何かを構築しようと考えました。」

移行を適切に行う

CSE の移行チームは当初、クラウドへの移行は 1 つの大きなリフト&シフトのオペレーションの実装であると単純に考えていた、と Apple は述べています。これは、その当時の一般的な考え方でもありました。すべてのワークロードを現状のままクラウドに移行し、残りの作業は後で面倒を見るというものです。

「これは良い方法ではありませんでした。その理由はいくつかあります」と Apple は言います。まず分類しなければならない、多くの相互接続と組み込みシステムがあったと述べています。「私たちのクラウド移行作業は、考えていたよりもはるかに複雑なものになることをすぐに理解しました。」

多くのことを試した後に、一度戻ってより全体的に考える必要があることをチームは理解しました。

最初のステップは、現在自分たちの手の中に何があるかを把握することでした。マイクロソフトのワークロードは 10 以上のデータセンターに分散していました。それらのワークロードを所有しているのは誰か、それらは何のために使用されているか (あるいは、そもそもそれらは使用されているのか) を誰も追跡していませんでした。

マイクロソフトの文化は長い間、必要であれば何でもプロビジョニングせよ、最悪のシナリオをカバーするために大きく構えよというものでした。初期のコストをカバーできた後、それらのサーバーを維持するためにいくらコストがかかるかをチームが忘れてしまうことがよくありました。実稼動環境、開発環境、テスト環境を稼動させた後、追跡されない処理能力の量は大きく、常に増加していきました。

「自分たちがどのようなサーバーを使用しているかを知らないことすらありました」と Apple は言います。「テスト環境を使用してメイン サービスを運用している人もいました。」

誰が何の費用を支払っているのかを把握しなければなりません。

大変なことです。 「コストについては少し理解していました。各チームが所有しているものと、実際にコストを支払っているものに関してです。そして、それらを整理していかなければなりませんでした」と Apple は言います。「Azure に移行したら、すべてのコストについて説明責任が求められます。支払っているすべてのコストについて完全な明確性が求められるのです。」

驚くべき発見もありました。

「Exchange Server がまるごと 1 つ実行されているのに、わずか 8 人しか使用していませんでした。いったいどういうことでしょうか? Office 365 を使用すべきです」と Apple は言います。「『別の方法を見つけてこれは廃止しよう』という状況がたくさんありました。私たちはそうした状況を整理していくことができました。これはまるで、3 年前にストレージ施設をオープンしたものの、突然、必要だと考えていたすべてのことが必要でなくなったのを理解するようなものでした。」

クラウドへの移行によって、多くのことをもう一度やり直す機会が生まれました。

「長い間行われてきた多くの悪習慣や無作法を一掃することができました」と Apple は言います。「ファイアウォールの設定方法を修正し、ExpressRoute ネットワークをロックダウンし、社内の Corpnet へのアクセスの規制を強化しました。クラウドへの移行を通じてセキュリティを大きく強化することができました。」

これは本質的に、未開の土地を開発する機会でした。

「私たちはそれを十分にやれたわけではありません。しかし、それを適切に行うことはできました。それは非常に強力なものでした」と Heather Pfluger は言います。彼女は CSE の Core Platform Engineering Team のパートナー グループ マネージャーを務めており、移行の最前線にいました。

多くの間違いがありましたが、それは意義のあることでした。なぜなら、チームは新しいテクノロジの習得と、何十年にもわたって染み込んだ考え方の変更を行おうとしていたからです。

「愚かなこともしました」と Pfluger は言います。「意気込んでリフト&シフトを行いましたが、それが財務上の問題を引き起こしたこともありました。再設計や最適化を行う必要があったのに行わなかったこともありました。」

それらすべてが学習につながったと彼女は言います。現在、チームは最適化ダッシュボードを活用して、必要なものだけを購入するようにしています。この変化によって、CSE は数百万ドルのコストを削減できました。

Apple によると、これらの新しい理解は全社を通じて大きな違いを生み出しています。

彼は次のように言います。「クラウドへの移行は物事の新しいやり方を作り出すことであるという考え方を人々に植え付ける必要がありました。私たちは、多くの物事のやり方をリセットしているところであり、それはビジネスの運営方法も変えています。」

チームでやり方を変えたことについて、彼は多くの項目をすらすらと挙げました。

  • イベントやアラートを、中央の IT 運用チームではなく DevOps チームに直接送信する
  • リソースが必要になったタイミングで、数分以内にそのリソースを用意する (長く苦しい時間をかけて計画したりしない、または 1 週間をかけて手動で VM を構築したりしない)
  • 負荷に基づいて動的にリソースのスケール アップとスケール ダウンを行う
  • 古い「連続実行」モデルを使用せずに、周期的なビジネスのリズムに合わせて月ごと、または週ごとにサイズを変更する
  • アイドル状態のときはソリューションのコストをゼロまたはほぼゼロにする
  • ビルド用のカスタムの Windows オペレーティング システム イメージを使用するのではなく、Azure ギャラリー イメージを使用したり、Azure オートメーションによってイメージをアップデートしたりする
  • 多くの手動による手順を必要とする物理的なネットワーク ファイアウォール構成ではなく、クラウド内でソフトウェア定義のネットワーク構成を作成する
  • Azure のツールを使用してオンプレミス環境を管理する

今では、はるかに多くのことができるようになっています。内部ユーザーが私たちのレポートに問題があることを見つけるのは望ましいことではありません。私たちが自ら問題を迅速に発見して修正し、マイクロソフトの従業員ユーザーが問題を目にすることがないような状態を望んでいます。

– Heather Pfluger、パートナー グループ マネージャー、Core Platform Engineering Team

Pfluger のチームは、マイクロソフトの従業員ユーザーが日々使用するテレメトリ ツールを作成しています。

「今では、はるかに多くのことができるようになっています」と彼女は言い、目標は常に満足度を向上させることであると説明します。「内部ユーザーが私たちのレポートに問題があることを見つけるのは望ましいことではありません。私たちが自ら問題を迅速に発見して修正し、マイクロソフトの従業員ユーザーが問題を目にすることがないような状態を望んでいます。」

これは実現しつつあります。

「マイクロソフトの従業員ユーザーが問題を発見することはほぼないレベルまで来ました」と Pfluger は言います。「私たちは向上していますが、さらに長い道が続きます。」

すべての人が継続して学び、調整し、物事の新しいやり方を見つけることを Apple は望んでいます。

「現在では、私たちの投資とイノベーションはすべてクラウドで行われています」と彼は言います。「新しいことや、より強力なことを行う機会は果てしなく存在します。私は、次に行くべき場所を見つけることを楽しみにしています。」

トップに戻る
日本語 (日本)
プライバシーに関する選択のオプトアウト アイコン プライバシーに関する選択
コンシューマーの正常性のプライバシー Microsoft に問い合わせ プライバシー 特定商取引法に基づく表示 Cookie の管理 使用条件 商標 広告について