October 2015

Volume 30 Number 10

Microsoft Azure - Microsoft Azure の全体像

Tony Meleg | October 2015

毎月、本誌では、Microsoft Azure の新しいサービスや興味深いサービスを詳しく掘り下げる記事をお届けしています。開発者が知らなければならないと思えることは次から次へと登場しますが、同時に、同じことを実現する手段は実にさまざまで、混乱も生じます。1 つ 1 つのピースをすべてつなげて、「全体像」を把握することは容易ではありません。この業界で現在起きているイノベーションのペースがあまりにも速いため、全体像が見えないことが、IT 部門にとっても IT 担当者にとっても、大きな問題になります。そこで、今回は、いつもとは反対に、特定のサービスを詳しく掘り下げるのではなく、Azure 自体を理解できるようにします。

率直に言って、開発者は複雑な物事をシンプルにすることが、必ずしも得意ではありません。シンプルな問題でも、非常に複雑なソリューションを実装してしまうのが普通です。開発者は、物事のしくみ、特に自身で作成していないものがどう動くかを理解せずにはいられません。これには、信頼の問題もあるかもしれませんが、コンポーネントやソフトウェアを特定のニーズに対してカスタマイズし、調整する方法を理解するためでもあります。また、事態を制御するためでもあります。

マイクロソフトの大きな賭け

今挙げた開発者像に思い当たる節があるなら、これから書くことはお気に召さないかもしれません。Azure とは、アプリケーションのビルディング ブロック、つまり「サービス」の集合で、そのサービスごとに異なる機能を提供します。提供する機能は、開発者がビルドするアプリケーションで必要になると考えられるものです。マイクロソフトは、これらのビルディング ブロックは、回復性、高いスケーラビリティ、自己管理力を本質的に備えているべきだと考えています。世界中どこにいても任意のサービスをプロビジョニングでき、料金は利用した分だけで済みます。また、何と言っても、いつでもどこでも使用量を変更できます。そしてこれが、お気に召さないと思われるポイントですが、これらのサービスは何も手をかけなくても機能します。複雑なしくみは抽象化され、開発者が制御できることは限られ、内部を見ることはできません。つまり、サービスを信頼するしかありません。物事を制御したい、「信頼」できない、複雑なものが性に合っているので興味を持てそうもない、そう考えてはいませんか。

Azure は、データセンター インフラストラクチャ、インフラストラクチャ サービス、プラットフォーム サービスの 3 つの層に大別できます (図 1 参照)。

図 1 Microsoft Azure の概念図

この 3 つの層はスタック形式で積み上げられ、各層は下層を抽象化したものと考えます。つまり、サービスとしてのインフラストラクチャ (IaaS) は、おおまかに、基盤となる物理サーバー、ストレージ、ネットワークを抽象化したものです。サービスとしてのプラットフォーム (PaaS) は、通常サーバーにインストールし、Web サーバー、データベース、メッセージング システム、ID インフラストラクチャなど、アプリケーションを作成する際に使用するアプリケーション ソフトウェア インフラストラクチャを抽象化したものです。サービスの役割は、このソフトウェアを利用者に提供することではなく、完全に機能し、回復性があり、常時稼働しているサービスを提供すること (および、アプリケーションの動作を中断させることなく、背後で問題を監視して透過的に解決すること) です。

これらのサービスは、Azure パブリック クラウド内だけでなく、あらゆる場所で利用可能です。データセンター、ホスト、アウトソーサーでも利用できます。マイクロソフトは、このような場所を問わない Azure サービスの利用を実現する Azure Stack を発表しました。これは、Azure の秘密のソースとサービスをパッケージにまとめて、利用者のハードウェアにデプロイするものと考えられます。結局、これは Windows Server と Hyper-V のコア基盤の上に構築されたソフトウェアにすぎません。しかし、この新しい世界では、形態は大きな問題ではありません。重要なのは、必要なサービス、ソリューションを適切に設計する方法、サービスを基にプログラミングする方法だけです。

プラットフォームのビルディング ブロック

では、Azure の全体像を眺めてみましょう。図 2 は、インフラストラクチャ サービスとプラットフォーム サービスについて、すべてのサービスを機能グループ別にまとめて図示したものです。インフラストラクチャ サービスは、既存のアプリケーションの下位レベルにあるインフラストラクチャを作成できる機能であると考えてください。ディスクを搭載したコンピューターが必要です。コンピューターどうしをつなぐネットワークが必要です。共有ディスクも必要です。さらに共有ディスクを別の場所にあるシステムとネットワークに接続することも必要です。

図 2 Microsoft Azure のサービス

インフラストラクチャ サービス レベルの抽象化は、仮想マシン (VM) と VM にアタッチする仮想ディスクとしてコンピューターが表されるなど、基盤となる物理データセンターを表しているため、理解しやすいでしょう。この抽象化では、既に所有しているシステムを運用でき、現在と同じ方法で作業できます。抽象化されるのはコンピューターだけで、使用する可能性があるアプリケーション ソフトウェアはありません。現在ユーザーが自社のデータセンターで行っているのと同じように、ユーザー自身が、ネットワークで接続されている一連の VM で実行するソフトウェアのインストール、管理、修正プログラムの適用、エラーの修正、回復性の確保を行います。

対照的に、プラットフォーム サービスでは、サービスが使用する下位のコンピューターやストレージ、ネットワークがすべて抽象化され、ユーザーからは関与できない機能が存在します。原則として、ある特定のサービスで使われる基盤の VM を実際に操作することやその VM に接続することができない場合、そのサービスは PaaS です。また、サービスを提供するソフトウェアを選ぶことも、そのソフトウェアの調整や制御を行うこともできません。そのままで使用でき、サービス自体でエラー解決や修正プログラムの適用が行われ、Azure データセンター全体で必要なサービスのすべてのコンポーネントを監視するのは、サービスの役割です。利用者はサービスを使うことに専念します。いずれにしても、それが利用者の本来の仕事です。

余談 - Azure データセンターのインフラストラクチャ

開発者は例外なく根が Geek なので、Azure を動かしている基盤の複雑なコンピューティングやデータセンターのインフラストラクチャ全体に興味があるかもしれません。サーバーの物理ハードウェアの仕様や、採用されているスイッチ、ラック構成などを知りたいと思うかもしれません。すべてのサービスで一貫して驚くほど高いパフォーマンスを実現している複雑なネットワーク トポロジと、各地の Azure データセンターをつなぐグローバル ネットワークについて知りたいと思うかもしれません。または、現在 Azure を運営している世界各地の 24 か所のデータセンターのリージョン (近々、カナダとインドに新しい 5 か所のリージョンがオンラインになる予定) に興味があるかもしれません (図 3 参照)。

図 3 全世界の Microsoft Azure データセンター拠点

これは、新しい世界に踏み込もうとする開発者としての最初の試練です。少なくとも Azure では、そのようなことを気にしてはいけません。Azure Stack を使って独自のデータセンターに独自の "Azure" を構築する場合は、やはり、自身で (または社内のだれかが) すべての物理コンポーネントの面倒を見る必要があります。以前は、特定のアプリケーションに必要なインフラストラクチャについても気にする必要があったのは、問題が発生した場合の代償があまりに高かったことが理由の 1 つです。必要なサーバーの台数やサイズを完全に把握することはできません。最悪のケースを想定し、念のため少し上乗せします。Azure では、このような問題は存在しません。何かが足りなくなったら、その分追加するだけです。容量の大きなコンピューターが必要になったら 1 台増やし、容量が多すぎるようなら変更すればよいのです。Azure では、自社のアプリケーション ユーザーがどこにいて、ソリューションの提供に利用する最適なデータセンターはどこかを考えるだけです。通常は、最も近くにあるデータセンターを選びます。

インフラストラクチャ サービス - 細部まで制御可能だが、作業量も増加

約 60 種類ものサービスがあるのを見ると (図 2 参照)、圧倒されますが、通常、ビルドするアプリケーションの大半には、数えるほどの機能しか実装しません。通常は、Web サーバーとリレーショナル データベースを中心にして、ID やレポート、場合によってはバッチ処理などのコンポーネントを追加します。ここでは、Web インフラストラクチャとデータベースに注目してみましょう。

まず、決めることがあります。インフラストラクチャ レベルの抽象化とプラットフォーム レベルの抽象化のどちらで作業しますか。VM を稼働させ、Web サーバーとデータベースをインストールして運用しますか。ただし、これは基本的に、物理サーバー、ストレージやディスク、ネットワークの抽象化であって、サーバーで実行する必要があるソフトウェアの抽象化ではありません。簡単で、なじみがあり、想像どおりのことです。これまでのキャリアの中で行ってきたこと、現在も行っていることとまったく同じです。図 4 をご覧ください。VM には仮想ディスクがあります。これらの仮想ディスクは、複数の VM 間で共有することも、特定の VM にアタッチすることもできます。VM は仮想ネットワーク内に配置できるため、VM 間の通信が可能です。ネットワークは独自のデータセンターに接続することも、複数の Azure リージョン間で接続を確立することもできます。これはすべて、このソフトウェア抽象化を利用して実現します。つまり、1 つ以上のディスクがあり、他のコンピューターに接続しているネットワーク上に配置された 1 台のコンピューターにすぎません。

図 4 仮想マシンによるサーバー、ディスク、ネットワークの抽象化

必要な VM セット内のすべてを利用者が制御し、調整やカスタマイズを行い、操作する必要があります。実際には、抽象化のおかげで、こちらの方が企業独自のオンプレミス環境よりも優れています。物理コンピューター、ホスト OS、ハイパーバイザーを気にかける必要はありません。仮想ディスクの基盤となるストレージ インフラストラクチャの回復性について心配する必要もありません。VM のサイズについては、膨大な数の選択肢があります (CPU と RAM の組み合わせを変えたり、ディスクのサイズや速度、ネットワーク帯域幅を選ぶことができます)。

さらに便利な点は、全面的に「セルフサービス」であることです。すべてを自動化できるため、驚くほど簡単に、必要なインフラストラクチャを定義し、シンプルなスクリプトで数百のインスタンスを起動できます。

たとえば、アプリケーションにある程度の規模と回復性が必要だとします。VM と Web サーバーから成る Web ファームを簡単に作成でき、データベース クラスターの作成も簡単です。開発者 (IT プロフェッショナル) なら、この作成方法には精通しており、できないことはないが、簡単でもないことを知っています。昼夜を問わず、いつでもこの作業を行うことができます。世界中のどこにでもプロビジョニングできます。使用した分だけの料金を支払うだけで、気が変わったら、いつでもすべて破棄して、完全に支払いを止めることもできます。すばらしいでしょう。しかし、あまりに話がうますぎるように思えます。デメリットはないのでしょうか。

インフラストラクチャ レベルで抽象化するデメリットは、依然として、利用者が必要なものをすべてデプロイし、稼働するためのさまざまな作業を実行しなければならないことです。すべて稼働したら、今度は、それらを停止させないようにする作業が必要です。ただし、特に「停止させないようにする」作業については、Azure リソース マネージャーなどの Azure の機能や、オンプレミス環境の機能やテクニックを活用できます。相互に関連する複雑な VM セットをデプロイすることはオンプレミス環境の方が難しく、支援ツールとして Windows PowerShell による自動化や、その他多数のサードパーティ ソリューションを利用することになります。完全に運用可能な状態になったら、今度は VM 内で使用するすべてのソフトウェアに修正プログラムを適用する必要があります。これには、実行する OS (種類は問いません) も含まれます。すべてのアプリケーション ソフトウェアの正常性を管理する必要があります。これは、Web サーバーとデータベースであれば難しくて手に負えないことはありませんが、これをスケール アウトするかその他の 5 つの機能を追加した場合は、格段に難しくなります。

制御できることを取るか、作業や手間を取るかの問題です。制御できるようにする場合は、必要な環境を構築し、すべてが稼働し続けるようにする手間を増やさなくてはなりません。

プラットフォーム サービス — 細部までは制御できないが、作業量が減少

「コンピュータ科学の問題で、別のレベルの間接参照を追加することで解決できないものはない」という格言があります。これに「だが、それはさらに別の問題を生む」という文言が追加されたバージョンもあります。

まさにそのとおりで、プラットフォーム サービスがその好例です。図 2 の Azure Services の図には、今回の例で必要な 2 つのビルディング ブロックのプラットフォーム サービスの抽象化として、Web サーバーとデータベースの 2 つがあります。Azure では、これらの抽象化は Web Apps (「Web and Mobile」セクション) と SQL Database (「Data」セクション) です。Azure でこれらのサービスをプロビジョニングします。プロビジョニングの方法は他のサービスと同じで、Azure Management Portal にアクセスし、目的のサービスを選択して、サービス名、データセンターの場所、初期パフォーマンスや価格レベルなど、必要な詳細情報を入力します。

制御できなくなる代わりに作業が少なくなるのは、この部分です。データベースを例にして考えてみます。北ヨーロッパのデータセンターにデータベースをプロビジョニングします。1 分も経たないうちに、完全に機能するデータベースが提供されます。その後、独自のスキーマとデータをデータベースにデプロイし、Web アプリケーションと連携させるのが開発者の仕事です。インストールが必要なソフトウェアはなく、プロビジョニングしたものを利用できます。この場合は SQL データベースです。しかも、1 つだけではなく、3 つのデータベースが手に入ります。3 つとも可用性の高いクラスター内で連携するため、驚くほど高いレベルの回復性が得られます。これら 3 つのデータベースのパフォーマンスは、パフォーマンス レベルを変更する (支払う料金も変わります) だけで上げることも下げることもできます。3 ウェイ方式のクラスター化データベースがプロビジョニングされないようにすることはできません。Azure では、常に、機能するデータベースを確実に提供する必要があり、そのためにはこの方式が最善としているためです。

図 5 に示すように、Azure Web Apps を使って、アプリケーション用の Web インフラストラクチャをプロビジョニングする場合も、同様のモデルが適用されます。シンプルなスライダーを使って、必要なインスタンスの数を選択できます。インスタンス数を増減するだけで、後はサービスが自動的に処理します。このインスタンス数の調整さえ、負荷やスケジュールに応じて自動調整するようにシステムに指示することができます。最も重要なのは、サービスが指定された数のインスタンスを常に提供し、障害が発生したインスタンスの監視と修復を行うことです。開発者の仕事は、Web アプリケーションのコードを作成して、バイナリをサービスに渡し、起動したインスタンス全体で、必要なすべての場所にバイナリが配置されるようにすることです。

図 5 Web アプリケーションのインスタンス数の変更

プラットフォーム サービスの抽象化では、通常、サービスのプロビジョニング、回復性、管理を自動的に処理するサービスが提供されます。抽象化によって生まれる「また別の問題」とは、一部の制御が失われることです。ソフトウェアを選択することはできません。サービスの「内部」にアクセスして、OS からソフトウェア スタックに至るまで、使用しているソフトウェアの調整やカスタマイズはできません。開発者にとってはブラック ボックスです。もう 1 つ失われる制御は、サービスの機能とサービスの API に縛られるようになることです。つまり、アプリケーション コードからサービスと通信する方法が制限されます。たとえば、データベースで、サービスが提供していない特定の機能が必要になることがあるかもしれません。それは、特定のデータ型かもしれませんし、フルテキスト検索などの特定の機能自体かもしれません。既存のアプリケーションをクラウドに移行しようとして、アプリケーションが使用する機能と Azure サービスが提供する機能が一致しないかもしれません。どうすればよいでしょう。

図 2 の Azure サービスのビルディング ブロックの図では、すべてのサービスを IaaS 層か PaaS の層に分けて表示していますが、層をまたいでサービスを「連携して」使用できないとは考えないでください。たとえば、Oracle をインストールして Linux で実行している VM や、SQL Server をインストールして Windows で実行している VM と、PaaS Web App サービスとを連携して使用できない理由はありません。これで、制御と手間のバランスが取れるようになります。実際は、これをさらに発展させることができます。これらのビルディング ブロックはすべていつでも使用できる状態で、もちろんどこからでも使用できます。必要なのは、1 つのシンプルな API か、既にこれらのサービスとの通信に使用している既存のプロトコルだけです。どのビルディング ブロックも、独自のデータセンター内の既存のシステムと連携して使用できます。サードパーティのビルディング ブロックや、他のクラウド プロバイダーのビルディング ブロックでさえ、連携して使用できます。もちろん、このような連携によって生じるかもしれない遅延の問題をアプリケーションが許容できることが前提ですが、不可能ではありません。

その他のサービス

では、Azure のその他のさまざまな機能が必要な理由は何でしょう。会社の IT の状況と、現在運用しているすべてのアプリケーションを考えた場合、メッセージング システム、データ分析機能、ID インフラストラクチャ、セキュリティ層、バックアップ システム、データ ウェアハウス、監視と管理のシステムなど、これらのアプリケーションを動かしてる基盤のアプリケーション ソフトウェアはかなり多岐に渡ることがわかります。総合的に見て、IT ポートフォリオ全体としてこれらのものはすべて必要です。Azure を「IT 版レゴ」のコレクションと考えてみてはどうでしょう。次のすばらしい作品を作るとき、常に全種類のピースを動員する必要はありませんが、箱の中には全種類のピースを用意しておきたいと思いませんか。

新しいソリューションをビルドするときに、使用するビルディング ブロックを決める方法は、これまでとまったく変わりません。各ビルディング ブロックの機能を理解し、アプリケーションの特定のニーズに合うものを探して呼び出します。クラウドでのアプリケーションビルドは、方法が変わり、複雑になると思われていますが、そのようなことはありません。ただし、基本コンセプトが「共有」インフラストラクチャでの作業になるため、実行すべきことがいくつか増えます。つまり、サービスの多くには制約があります。この制約は、利用する各機能レベルと価格層によって異なります。どのような制約があるかを確認しておく必要があります。このような制約を常時受けることは避けるようにします。アプリケーションの負荷とニーズを基に、必要なものを変えなければなりません。制約の影響を受けないように、また、サービスの可用性と応答性を確保できるように、プログラミングする必要があります。同じツール、同じ言語とフレームワークを使ってソリューションをビルドでき、最低レベルでもすべてのサービスに REST ベースの API と、使用すべきフレームワーク固有のラッパーがあります。つまり、センサーなど、シンプルな Web スタックが実装しているものなら、文字どおりビルディング ブロックを利用できます。これは、クラウドがモノのインターネット ソリューションの爆発的な増加を促している理由の 1 つです。

クラウドが優れている点は、すばやく反復処理できること (簡単にサービスを起動できるため)、代替のアプリケーションやサービスなどを試用できること、またわずかな投資しかしていないため、失敗してもすぐに資金的に大きな痛手を受けずに撤退できることです。図 2 をもう 1 度ご覧ください。何か足りないものはありますか。必要になることはないと思えるものが図に含まれていることはありますが、必要な機能または既に使用している機能で、図に描かれていない機能を見つけるのは難しいでしょう。広範なトピックを網羅したガイダンスや、サービスごとの詳細な実装ガイダンスまで、参考になるさまざまなガイダンスが提供されています。

新しいことを学ぶ意欲は、ほとんどの開発者の DNA に刻まれています。おそらく、開発者はテクノロジーを使ってみて、新しいことを試すのが好きでしょう。勤務先では、何かをビルドしてパブリック クラウドに配置するチャンスはなさそうだとしても、クラウドは開発者が学び、成長できる世界最高の遊び場です。

変化への対処

まとめに入る前に、最後にもう 1 つ取り上げたいトピックがあります。それは、変化への対処です。残念ではありますが、ペースが速すぎて、続々登場する Azure のすべてイノベーションについていくのは難しいと感じています。これも仕事の 1 つなのですが。提供予定の機能について 3 ～5 年先までロードマップが示されていた時代は過ぎ去りました。現在は、運がよくて 6 か月です。何かを開発している途中で、新しい機能や、場合によっては新しいサービス自体が登場し、つい、それらを評価し、リファクタリングしてソリューションに組み込みたくなることがあるでしょう。機能やサービスが削除される場合も、通知期間は 1 年になっています。一方、サーバー ソフトウェアでは、これまで 10 年以上のサポート サイクルが適用されてきました。

このところ、サービスのバージョン管理が行われるようになってきました。つまり、サービスに追加された新機能によって、サービス実装や、サービスを基盤にビルドされているアプリケーションが機能しなくなる可能性があります。したがって、バージョンを管理するかどうか、つまり、新しいサイドバイサイド実装を作成するかどうかを判断しなければなりません。Azure では、最近、Azure SQL Database でこれを行いました。詳細については、「SQL Database V12 の新機能」(https://azure.microsoft.com/ja-jp/documentation/articles/sql-database-v12-whats-new/) を参照してください。

問題は、クラウドでは支払いが必要な税金が発生することです。そのことを認識し、税額を考慮する必要があります。事前に計画を立て、突然の事態に慌てることがないように、クラウドのサポートや変更についての通知プロセスに登録してください。もちろん、税額も変わってきます。金額や頻度の変化は、オンプレミスよりも高くなります。とは言え、気を落とさないでください。メリットの方がはるかに大きくなります。仕事のペースが格段に上がり、品質が向上し、引き受けなければならないリスクは大幅に減少します。

詳細については、AzureCon オンライン イベントに登録してください。AzureCon では、Azure のエキスパートの話を聞いたり、Q&A を参照したりできます。最新の Azure のイノベーションについての詳細情報も提供しています。bit.ly/1KRD76d (英語) から登録することで、アーカイブされているすべてのカンファレンス コンテンツを参照できます。2015 年 9 月 29 日に開催された AzureCon のセッション ビデオは Channel 9 AzureCon 2015 (英語) で視聴できます。

Tony Meleg は、Microsoft Azure チームのテクニカル プロダクト マネージャーです。Azure についての知識を広め、複雑なことをシンプルな概念で表現できるよう、さまざまなユーザーを対象とした技術コンテンツを作成しています。