＊ Microsoft Azure 構築参考情報 (Amazon リンク)

最近は減ってきた感がありますが、「クラウドって SalesForce でしょ？N〇K でやってたし」という流れのころは「クラウドは絶対に落ちない！」と思われていたフシが強かった気がします。そんな発想から「これからはクラウドや！うちもクラウドやるで！！俺らのアプリをクラウド化するんや！！」って人、結構いました。

いや、クラウドは止まらなかったとしても、あなたがホストしてるアプリケーションは止まるよね？

「なに言ってんだお前」って言われるのはもう慣れた。順を追って話していこう。

クラウド サービスって、サービスだけが提供されてて中身を直接覗けない、雲の中っぽいよね！ってところからそういう名前がついてるのは皆さんご存知ですね。
Office 365 を始めとした SaaS サービスは、全部が落ちちゃうって可能性はマジ低い。それは、ハードからその OS からプラットフォームからソフトウェアからアプリケーションから一切合切をすべてトータルで責任もって全部一括管理している人がいるからで、さらに言うとその規模が

半端ない。

規模を大きくすれば落ちにくくなる、それはなぜか。

サービス全体を冗長化してるから。

…じょうちょうか？ はいここ重要、テストに出るから絶対覚えること。

冗長化（じょうちょうか）とは、システムの一部に何らかの障害が発生した場合に備えて、障害発生後でもシステム全体の機能を維持し続けられるように、予備装置を平常時からバックアップとして配置し運用しておくこと。 (Wikipedia より)

ここらへんからやっと本題なんですけども、あなたが作ったアプリケーションをクラウド化するとしよう。たとえば Azure ね。
Microsoft Azure 使って、あなたが作った web アプリケーションを World Wide Web に公開するとしよう。
選択肢はいろいろあるけど、「あなたが作ったアプリケーション」という前提なのですでにモノは存在するわけだから、そのアプリケーションを実際にテストした OS の Azure 仮想マシンを使えば比較的早期にクラウドへ置くことはできるよね。
Azure 仮想マシンにはパブリック IP アドレスを付けることもできるし、web サイトをホストすることもできる。EC サイトだって運営できる。
もっと言っちゃえば、その web サイトを有料会員制で運営して顧客からお金とることだってできる。ライセンス的にも問題ない。やったね！俺の時代がついにきた！！！！

ん？仮想マシンの台数？奮発してコアの数増やしたし、1 台で十分だろ？

…お前は今まで何を聞いていたのかと。「冗長化」はテストに出ると言っただろう。
やっと本題！ クラウド プラットフォームではすべての役割を冗長化しなければならない理由とは！？

理由その 1 : インスタンスはちょいちょい再起動する

Azure 仮想マシンでも Azure App Services でもそうなんですが (Azure 仮想マシンなら台数 = インスタンス数と思ってくれ) 、インスタンス数を 1 で運用する場合はそのシステムが 5 分程度応答なくてもぎゃーぎゃー騒がないと約束してください。誰に？神様に。

Azure App Services はいわゆる PaaS で、単純明快に web サービスをホストすることだけに特化したサービスです。このブログも App Services だ。
PaaS サービスというのは OS を含めたプラットフォーム全部をベンダー (Microsoft ね) が管理しており、利用者の思惑は一切通用しません。その分利用者はすべてを Microsoft に任せて中身に集中できるというわけですが、逆を言うと 任せっきりにする＝思い通りにならない ということなんですね。
プラットフォームにアップデートがあるとか、ホストしてるハードウェアが調子悪いから別のラックに移動するよとか、その他もろもろの事情でインスタンスが再起動されることはちょいちょいありますし、OS や .Net Framework のバージョンも定期的にアップデートされます。もちろんセキュリティ更新プログラムもがんがん適用されます。これを利用者の都合で止めることはできません。

App Services だけじゃなく Azure 仮想マシンでも予期せぬ再起動は起こります。ハードウェアの故障が引き金のサービス ヒーリングとかもありますが、この資料で説明されている通り、予期せぬ再起動はどーがんばっても避けられないのですよ。

若干話が逸れ気味ですが、何が言いたいかというと、突然予告なくインスタンスが再起動したり、数十秒から数分程度応答がなくなることは当たり前ととらえなくてはならない、ということです。

ええええええええええええまじいいいいいいいいいい SLA とかどうなってんだよおおおおおおおおおお勝手に止めてんじゃねぇよおおおおおおおおおおおお

と思われるかもしれませんが、SLA が 99.99% でも月間で 4.38 分、年間でいうと 52.56 分停止することに相当します。
正直、SLA が 99.99% ってなかなかないからね。Azure 仮想マシンの SLA と App Service の SLA 見てみ。 ちなみにこのブログの App Service プランは Shared なので SLA はありません。

Azure 仮想マシンの SLA で注目してもらいたいのが、以下の前提です。

すべての仮想マシンに、同じ Azure リージョン内の 2 つ以上の可用性ゾーンにまたがりデプロイした 2 つ以上のインスタンスがある場合、マイクロソフトは、99.99% 以上の時間において少なくとも 1 つのインスタンスに対する仮想マシン接続が確保されることを保証します。

数字的には 99.99 % なんだけども、接続が確保されることを保証できるのは 2 つ以上あるインスタンスの最低 1 台。3 つインスタンスがあっても 1 台。4 つあっても 5 つあっても 1 台。

ここらへんでだいたいわかってきてるかと思いますが、ユーザーがクラウド上に自分のアプリを建てようとして用意する実行環境 (インスタンス) は、絶対的に冗長構成取ってないと SLA とか意味ないですよってことです。
2 つ以上インスタンスをデプロイする = 冗長化する ってことです。1 台死んでも、残りの 1 台が死んだインスタンスの代わりに処理を行えるような仕組みを確保しないとだめってことです。

逆に言うとですね、たとえ 1 台死んでも残りのインスタンスが代わりに処理できる仕組みさえあれば、アプリケーション全体の SLA は 100% 目指せるんですよ。限りなく止まらないシステムは、構成と運用によっては実現可能なのです。

理由その 2 : Azure 料金はコアが 2 倍なら単価も 2 倍

これは「冗長化しなけばならない理由」ではなく、料金が高くなることは冗長化したくない理由にはならない、という意味です。

Azure 仮想マシンと Azure App Service では、シリーズ (ファミリ) を選んでインスタンスのサイズを選びますが、この価格の設定が実に単純明快なのです。
単純に、コア数が倍ならメモリ量も倍、そして単価も倍になります。
1 台のマシンでコアとメモリを増やす選択をしようが、サーバーごとまるっと 1 台増やすことで結果的にコアとメモリを倍にする選択をしようが、Azure の料金的にはまったく変わらない、という結果になります。
オンプレだとこうはいかないですよね。筐体増やすのとコアとメモリだけ増やすのだとだいぶ金額変わってくるはずです。知らんけど。

例えば、アクセス数の急なスパイクが発生することを想定してコアとメモリをちょっと多めに確保するぐらいなら、実行するインスタンスの数を増やして負荷分散したって請求額は同じ、ってことです。だったら、大きめ 1 インスタンスで運用するよりは、ちょっと小さめだけど 2 インスタンスで負荷分散 で運用したほうがいろいろとメリットが出てきます。

理由その 3 : データセンター障害および災害対策

SLA にも関連するんですが、最近は BCP とかいうキーワードも出てきまして、提案および設計の段階で「どこまで災害や障害に対応するか」をゲンミツに検討するのがマジデ普通です。とはいえ、日本沈没したら業務継続できないからアメリカのデータセンターにもバックアップを… とかはちょっとやりすぎ。
考え始めたらきりがないけど、そうはいっても対策は考えておかないと、何かが起きたときに何もできない。避難訓練は重要なのです。

Azure では、ほとんどのリソースでデプロイ時にデータセンターを指定します。ということは、今あなたが作った Azure 仮想マシンはそのデータセンターにしか「無い」ということです。そのデータセンターに Azure 仮想マシンと関連する障害が起きたら、ひょっとしたらあなたのアプリケーションにも影響が及ぶかもしれません。

こういった障害対策、災害対策の一環として冗長化を構成しておく、という方法は本当に一般的に行われています。特別大企業だからやる、ってことではないです。
たとえば、web サイトを西日本と東日本において負荷分散構成することで、九州の人は西日本へ、北海道の人は東日本へアクセスする、という構成も可能です。より近いデータセンターに接続できればうれしいですよね。

以上、冗長化の必要性とメリットを簡単にご案内しましたが、ちろん、アプリケーション自体も冗長化に耐えられるように作らないといけません。
普通に web サービスならネットワーク ロード バランス (NLB) には対応できるでしょうから (このブログ的に言うと、昔は NLB できない web アプリなんてゴマンとあったのよまじで) 冗長化は比較的楽ですが、ユーザーデータやデータベース環境が web サービスと同じ OS 環境に同居してたりするとやっかいです。ご存知の通り、データベースは NLB では冗長化できません。
できるやつもあるのかな？それにしても、web サイトの NLB と同じしくみでデータベースもうまく負荷分散してくれるとは思わないほうがいいですよね。

手元のアプリケーションをクラウドにあげるぞ！！と思う前に、あなたのアプリケーションがクラウド上で生きていける作りになっているかどうか、確認することをお勧めします。

でもね。冗長化できない場合はクラウドにあげちゃいけないのかって言ったら、全然そんなことないんですよ。
冗長化すればインスタンス数は増える。必ず倍になるとは言わないが、増えるのは間違いない。そうなるとやっぱり、たいていの場合でコストは上がるんすよ。安定性と払う金額は比例するんすよ。

そうなるとね、安定性を犠牲にしてもコストを下げる、って選択肢も出てくるわけですよ。
いままでオンプレ (とかレンタルサーバーとか) では冗長化なんかまったくしてなくて、それでもなんとなく動いてたシステムをね、インスタンス数増やして冗長化してコストを上げないとクラウドに持ってっちゃいけないのかと。

いいんです。

5 分や 10 分サイトが落ちても別に問題ない！少々止まっても誰も気にしないよ！むしろ気づかないよ！！ちっさいことは気にしないよ！ワカチコワカチコ！
って言うのであれば、全然問題ありません。
たま～～にちらっとエラーが出ていたとしても、数分後には自動復旧するのであれば「気のせいだったかしら」で済ませられるのであれば、無理に冗長化なんかしなくていいんです！データの保護だけ考えれば十分です！
うちのサイトも 1 インスタンスで運用してるけど、少々止まったところで問題になるほどアクセス数多くないもんね！わっはっはー！！！

ただね、インスタンス増やすと金がかかるからと冗長化せず、死活監視だけは命 100 万人分ぐらい賭ける勢いで実施、オンプレでやってたからと言って ping 1 秒に一回投げてたまたま 1 回応答が遅かったからって「原因究明と恒久的な対応策、再発防止案について今すぐご提示ください！！！！！！！！！！！！！」なんて SR を Azure ポータルから投げる、っていうのはさすがにね、ちょっと違うだろおい と思います。