| 震災アプリ開発者が語る本音の体験談 第1回 震災でAzureがどう役立ったか？ 2011/05/25 |
このたびの東北地方太平洋沖地震（通称「東日本大震災」）により被災された地域の皆さま、関係の皆さまに心よりお見舞い申し上げます。一日も早い復興を心より祈念申し上げます。
皆さま、こんにちは。亀渕です。
普段はマイクロソフト関連の提案や技術支援などを行い、Japan Windows Azure User Group（JAZUG）にて交流を行っています。
今回、「Windows Azure体験記」ということで、わたし個人の視点での体験や感じたことを、複数回にわたってBlog形式でお伝えしたいと思います。
| 東北地方太平洋沖地震での体験 |
わたし自身は西日本に在住していますので、東北地方太平洋沖地震について直接的な被害を受けることはありませんでした。しかしながら3月11日に地震が発生し、時間が経つにつれ情報が入り、その被害の大きさにただ茫然（ぼうぜん）とするだけでした。
わたしは無事で、何かしたくても何もできなくて。あまり良くない思考かもしれませんが、その当時はそんな葛藤がありました。
そんな心境の中、一夜明けて3月12日13時ごろ、JAZUGのフットワークの軽そうなメンバー宛てに1通のメールが飛び込んできます。
「日本赤十字社のWebサイトが過負荷でダウンしている。Windows Azureで復旧できないか？」
ご承知のとおり、日本赤十字社のWebサイトは災害時における献血や募金、救助情報などの核となるサイトです。
わたし個人は何もできないと思っていたのですが、「ITで、Windows Azureで、自分の持っている知識で、何かできるんじゃないか？」と、そのときあらためて気付きました。
| マイクロソフトやメーカーの対応 |
わたしは普段の業務からしてマイクロソフト関連に携わっています。そういった兼ね合いもあり、一番多くの情報を得られたのはマイクロソフトの対応でした。
マイクロソフトは、早くから無償で利用できる「Windows Azure無料パス」を、震災対応として発行し、また本来あるはずの制限の緩和や一時的な撤廃などの対応がなされていました。
これらの動きは何もマイクロソフトだけにかかわらず、「各自・各企業ができることを行った」と感じます。特に「クラウド・ベンダ各社の対応は素早かった」と記憶しています。
電力不足、ハードウェアの調達問題や即時の復旧が困難な中で、必要なリソースをすぐに確保でき、そのとき必要なITを新しく提供することができたのはクラウドだけ、というのは明白でした。
わたしはというと、Windows Azureパスのおかげで、クラウドなWindows Azureを何も気にすることなく利用できるようになったので、「後は何をするのか？」の一点のみ集中して考えることができました。
何かしらサービス化してもそれを動かす運用手段がないと意味がないので、当面のコンピュータ・リソースを気にしなくても済む、今回の各クラウド企業の対応は非常にありがたいことでした。
時を同じくして、メールでは、ITを活用した被災地支援を行うためのいろいろな手法について議論が交わされ、Twitter上では、震災の状況に関する多数の情報や、「ITで困っていることは何だ？」「何ができる？」といったクエスチョンが飛び交っていました。実際、Googleなどのネット企業は震災の数時間後にはいくつかのサービスを公開したりと、精力的に取り組んでいたようです。
| キャッシュ・サーバを作る |
最初に一報のあった日本赤十字社のサイトは、コンテンツを作成した会社とマイクロソフトが連絡を取り、「コンテンツ作成側にてサーバの増強対応を行う」と連絡があり、いったんは作業終了となりました。
ただ、この過負荷の問題は今後も必ず発生するだろうというのは、何となしには思っていました。事実、電力問題・放射線の問題がニュースで取り上げられるたびに当該サイトはダウンすることになります。
そこで、
- ミラー・サイトを作成し、負荷分散を行うために何ができる？ FTPサーバとWebサーバがあればいい？
- コンテンツの入手は？ すでに過負荷でダウンしているところに追い打ちをかけるのか？
- 仮に何かできても全て1人では対応しきれなくなるのでは……
……などを考えながら、できることを模索していました。
最終的に以下の点を目標に、ミラー・サイト（＝あるWebサイトにある、すべての情報をコピーして保持するサーバ）ではなく、リバース・プロキシ（＝リクエストをまとめてWebサーバに送ることにより、Webサーバへの負荷を軽減する仕組み）＋キャッシュ・サーバ（＝Webサーバに送ったリクエストの応答を保存して、一定期間はその応答データを利用するサーバ）を構築することに決めました。
1) コンテンツの入手を考慮しなくても済むように、ミラーではなく、リバース・プロキシ＋キャッシュ・サーバにする
2) 設定ファイルを変更するだけで簡単にWindows Azure上にデプロイできる
3) パッケージ・ファイルを公開して、わたしが対応できなくても誰かが対応できるようにする
一番気にしたのはやはり実現方法でした。ミラー・サイトは、稼働後にDNSの変更までできてしまえば、完全に元サイトの負荷をなくせます。
しかし、せっかく素早く立ち上げられるクラウドがあるのに、コンテンツの入手という一番不明瞭（ふめいりょう）で人手のかかる・時間のかかることを、わたしがしていてはいけないと。
ミラー・サイトとキャッシュ・サーバで並行に作業を進めるには問題ないですが、ミラー・サイトのアプローチはしかるべき筋から公式に動いていただいた方がよいと判断しました。
代わりとして、「リバース・プロキシの仕組みとキャッシュを併用すれば、第三者が外部にサーバを設置してもうまく負荷分散が可能では？」と考え、当初はOSS（オープンソース・ソフトウェア）のキャッシング・プロキシ・サーバ「Squid」をWindows Azure上で構築することにしました。
ソフトウェアの選定理由に特に深い意味はなく、「過去扱ったことがあり、欲しい機能が実現できることが分かっていたから」という単純な理由でした。
結局、構想して着手後、「Squid＋Windows Azureパッケージ版（アルファ版）」が出来たのは、日が変わって13日でした。
この段階は、まだまだ手動でコンフィグ（構成）しないといけない個所が多数ありましたが、その後、JAZUGの皆さんの協力もいただきながら、パッケージ・ファイルをWindows Azure上にアップロードするだけで済む正式版になり、最終的にSquidでは対応しきれなかった絶対URLの問題などに対処した「Application Request Routing IIS拡張版」と進化します。
当初からApplication Request Routing IIS拡張で動作できることが分かっていればよかったのですが、不安があったのと、「まず何かしら立ち上げる必要がある」と感じたので、（Squidによる応急的な開発の後に）時間を置いて対応することになりました。また技術的なハードルもあり、マイクロソフトのエバンジェリストの方に協力いただきながら構築していった経緯があります。
パッケージが出来た後は、JAZUGの皆さんにも展開を協力いただいて、多数のサイトのキャッシュ・サーバを短期間で展開することができました。※パッケージ版になった後は、展開まで30分〜1時間もかからなかったと思います。
その後はWebサイトだけでなく、頻繁に更新される公開情報用に、SkyDriveによるファイル共有やWindows Azureストレージを使用した簡易Webサイトの構築、Windows Azureアプリケーションの開発など、多くの方が対応され、いまも継続しています。
もし、クラウドな環境がなかったら、これらの多くの取り組みは実現できなかったかもしれないと思うと、「ITの可能性というものはまだまだあるな」と感じました。
| まとめ |
必要なときに必要なリソースを得られた、という点において、わたしにとってWindows Azureは一番身近でベストな選択でした。
しかしながらわたし個人の力量だけでは対応できなかった点があったことも考えると、使う人次第なのだということも非常に心に残りました。わたし個人だと本当に何もできなかった気がします。あらためて、「同僚やJAZUG、Cloudmix（クラウドごった煮）なコミュニティ、Twitter上の多くの人に助けられ、連携していたのだな」と思います。ありがとうございます。
復興完了まではまだ長い道のりですが、ITにかかわるものとしてできる範囲でやっていきましょう。
|
||||||||||
提供：日本マイクロソフト株式会社
アイティメディア営業企画／制作：デジタル・アドバンテージ
掲載内容有効期限：2011年7月15日
|
|
マイクロソフトによるWindows Azure 情報
|
|||||||||||
|
|||||||||||
|
＠IT内のWindows Azure 関連情報
|
|||||||||||
|
|||||||||||
|
外部サイトのWindows Azure 関連情報
|
|||
|
|||
