次の方法で共有


これから Windows Azure を始める 開発者の皆様に知っていただきたい 8 つの真実 【Reloaded】~ よっつめ

 

よっつめにお伝えしたい真実は、Windows Azure は開発者の皆様が構築されたアプリケーションの稼働を支える、 “ノンストップ” のための仕組みを用意したクラウドプラットフォームである、という事です。

 

image

 

 

例えば、ストレージサービスにおいては、リレーショナルな SQL Azure、KVS な Windows Azure Storage ともに冗長構成がとられています

 

前者の SQL Azure に関しては前回書いたように、そもそも3つのデータベースインスタンスによって稼働しており、あるインスタンスに不調があったとしても残りのインスタンスにより一貫性を確保するアーキテクチャとなっています。

 

また、後者の Windows Azure Storage に関しては、データセンター間でのデータ同期が行われています(”Geo-Replication” (ジオ レプリケーション) と呼ばれる機能)。

 

具体的には同一リージョン内(同一地域内)にあるデータセンター間でのデータ同期が行われています。Windows Azure では、”リージョン” としては、米国、欧州、そしてアジアの3つのリージョンがあります。

"アジア リージョン” (アジア地域)であれば、2か所のデータセンター、すなわち、”East Asia” と “Southeast Asia” のデータセンターがありますが、このデータセンター間で “Geo-Replication” による同期が行われています。

 

image

image

 

 

また、コンピューティングサービスに関しては、2インスタンス以上の稼働が条件になりますが、サービス レベル アグリーメント(SLA)として、月間 99.95% の稼働率を保証しています。

もし、実際のコンピューティングサービスの稼働率が、この数値を下回った場合には、「コンピューティング SLA」の内容に基づき、サービスクレジットとして月間の請求金額から一定割合の返金が行われます。

 

なお、コンピューティングサービス含め、Windows Azure の提供するサービスに関しての SLA 内容は、Windows Azure の Web サイトの サービス レベル アグリーメント のページを参照ください。

 

 

さて、ストレージ、およびコンピューティング サービスという、アプリケーションの稼働を支えるコアの部分では、上記のような仕組み、サービスを提供していますが、実際のサービス運用を考えた際にはアプリケーションの更新を行う際に、いかにサービスの停止を短くするか、という課題が残ります。

 

Windows Azure では、これに対して、(1) VIP スワップ、(2) In-Place アップグレード、および (3) アップグレードドメイン(更新ドメイン)、という機能、仕組みを提供し、アプリケーションのメンテナンスを支援しています。

 

順に説明したいと思います。

まず、(1) の VIP スワップに関しては次のような動きになります。

 

既に本番環境(Production 環境)として稼働中のサービスがあったとします。

開発者がこれに対するアップデートを作成した場合には、

image

 

まず最初にステージング環境(Staging 環境)に対して、この更新されたアプリケーションをデプロイします。

image

 

その後、Windows Azure の管理ポータルより、本番環境とステージング環境の “VIP スワップ” の操作を行います(管理ポータルでボタンをぽちっ、と押す感じ)。

image

 

すると、ロードバランサーで保持しているコンピューティング サービスの IP の値(Windows Azure のデータセンター内だけで利用している Virtual IP の値。VIP = Virtual IP のことです)が入れ替わり、先ほどまで本番環境として位置づけられていたインスタンスがステージング環境のものとして、またその逆にステージング環境のものが本番環境のものとして、位置づけられるようになります。

image

 

VIPスワップにより IP の入れ替えが終了すると、ユーザーのリクエストは更新されたインスタンス(VIPスワップ前まではステージング環境にあったインスタンス)に振り分けられることになり、ユーザーは新しいサービスを受けることが可能になります。

 

 

これに対し、(2) の In-Place アップグレードではサービスが稼働している状態で更新を行っていきます。

image

 

具体的には、稼動中のインスタンスの一部に対し、ロードバランサーからのリクエスト振り分けを中断し、その間にアプリケーションの更新を進めていきます。

image

 

アプリケーションの更新が終わると、ロードバランサーが更新されたインスタンスに対してリクエストの割り振りを再開します。

image

 

さて、この In-Place アップグレードでは、複数のインスタンスを利用しているにもかかわらず、1台のみしか更新されませんでした。これではサービスに不整合が起こってしまいます。

 

しかしながら、これはデザインされた動作であり、(3) として挙げた “アップグレードドメイン”、という仕組み(単位)で更新が行われる、ということに起因しています。

 

"アップグレードドメイン" とは、複数のインスタンスをグループ化したまとまりだと思ってください。

 

先ほどの例であれば、右側のインスタンスと、左側のインスタンスは、「異なるアップグレードドメイン」に属していることになり、右側のインスタンスの更新が終了した後に左側のインスタンスに対してもアプリケーション更新が行われます。

image

 

 

このように、Windows Azure では、アップグレードドメインという単位で更新を行うことで、サービスのすべてを一度に停止することなく順次アプリケーションの更新を行える仕組みを用意しています。

 

Windows Azure は、このような冗長構成、高可用性の保証、またアプリケーション更新のための機能提供を通じて、皆様のアプリケーションが “ノンストップ” で稼動できるように支える仕組みを持ったクラウドプラットフォームなのです。

 

Enjoy Azure!