Azure WebSitesにWordPressを1,000サイト詰め放題可能な「仕組み」を勉強してみた話。

Pocket

websites_title
FUKUOKA MEETUP COMMUNITYでお話させていただいた後、「どうしてAzure WebSitesにWordPressが1000サイト詰め放題できるのか」というところをちゃんと理解してないなーと思ったので、改めて勉強しなおしてみました。
今回はさすがに私1人で理解するのは無理すぎたので、 @kazumihirose さんに全面的に技術指導していただきましたが。
(というか、これ1人でわかったらジョブチェンジしてるレベル)
私的に理解できたとこをまとめますー!

Azure WebSitesの概念

レンタルサーバーと原理は同じというか、元々Azure WebSitesはレンタルサーバー業者向けの設計をクラウドにしたもの、だそうです。
例えば、サイトAにアクセスしてその後アクセスがない場合、Aはプロセスが止められてCPUもメモリも食わない状態になる。
WebSitesって全サイト常時接続ではないとのこと。
この仕組みを「アプリケーションプール」と言うそうです。

アプリケーションプールとは?

図解するとこんな感じ。
websites01

・各サイトのWordPressはそれぞれ1個のアプリケーションプールが割り当てされている
・これらは、例えば(最大CPUは30%まで、メモリは50MBまでとか)上限を決められる

で、なぜクラウドなのに「上限を決める必要があるか」というと、ここがレンタルサーバーの考え方と同じで「どこかガッツリリソース持って行ったときに全体が共倒れするのを防ぐため」。
なので、「リソースの管理」は必須になり、これをアプリケーションプールという機能で管理していると。
超えそうなら自動的にアプリケーションプールが強制停止。
これによって、他のサイトにリソースを割り当てられるし、アクセスのないサイトや無駄に動いているものも停止することができます。

ちなみに、アプリケーションプールは「プロセスの監視」も自動でするそうです。
「PHPハングアップしてる!再起動」とかメモリリークも解放するので、プロセスが健全に保てると。(この辺りはプログラマな方の領域ですね)

「必要な時に動き出して、その後しばらく動いてアクセス待つけど、無かったら止まる」
この仕組みのおかげで「1000サイト詰め放題」が実現するわけですね。

Azure WebSitesのメンテナンスの話

この「nrjlog」もそうですが、いくつかのサイトをWebSitesで運営しています。
が、今まで全く「メンテナンス」にあたったことがないなーって思ってました。
クラウドだからメンテナンス不要なのかなと。(間違ったクラウド認識)
ところが、Azure WebSitesは結構頻繁にメンテナンスがあっていたとのこと…。
そのメンテナンスの方法がすごかったので、ちょっと図解してみます。

websites02
(1)今からWebSitesになる新しいインスタンスが起動。
実はこれ、入れ替え用に既に起動してあって、空のサーバにWebSitesができるようになるこの際に新しいWebSitesになるサーバに今の「設定」が移動する。
(サイトがどれとか、名前がこれとか、PHP5.5で動かすとか)
設定が移ったら(2)へ。

websites03
(2)この「共有ディスク」内にアップロードしたWordPressが入っています。
「クラウドなのに何で制限?」って謎だったんですが、共有なので「50MB」の制限があるわけですね。(レンタルサーバー的)

(3)上位のロードバランサが「新しいWebSites見てね!」と自動で切り替え処理をしてくれます。

ロードバランサーとは?
負荷分散装置。外部から送られてくるデータや処理要求を、同等に機能する複数の装置に振り分けて一台あたりの負荷を抑える装置。
単にロードバランサという場合は、ネットワーク上でサーバの負荷を分散するサーバロードバランサを指すことが多い。
(IT用語辞典より)

websites04
(4)ここまで来たら、更新予定のサーバーのWindowsUPDATEが開始されて再起動したり。
実はクライアントは切り替えられてて新しい方にアクセスしてるんですが、全く自覚なし。
なので「結果的に止まらない」状態でメンテナンスが行われていると。

この古いWebSitesの仮想マシン(インスタンス)と新しい準備されたWebSites用の仮想マシン(インスタンス)は親のハードウェア(物理サーバ)も置いてあるラックも、電源系も別の場所にあって、万が一ラック丸ごとや物理サーバがメンテナンスなどになっても、影響しないとのこと。
このラック同士が影響しないことを専門用語で「ラックアウェアネス」というそうです。

これまでは、こういう無停止の仕組みを作るのに専門知識も必須だったし、構築にもものすごい時間がかかっていたそうなんですけど。
WebSitesだったらこの仕組みが自動で、しかも専門知識を持っていない人間までもが月6000円ちょっとの価格で使えるんですよね。
ホントすごい話だわーと個人的には改めてビックリしたとこです!

つまりAzure WebSitesって完全にPaaSだと思います

このPaaSとかホント意味わからんwだったんですけど。
最近やっと理解してきたので図解しときます。

websites05
このように、図を見たら一目瞭然なんですけど面倒なとk(ry…違う、専門知識が必須になるところはMicrosoftがしっかり提供してくれてます。
なので、Azureは知識のある人たちは自分たちでガリガリ良いようにできるし、私みたいにインフラ系の専門知識が無い人間はWebSitesを選択することで、今回のような「自分専用のレンタルサーバーのような使い方」ができるわけですね。
他のクラウドサービスを使ったことがないので完全主観にはなってしまうのですが、「ユーザー側で使い方を明確に選べる(住み分け可能)なサービス」って、ものすごくいいなぁと。
今後、全体的にこういう流れになっていくのかな?とも思ったり。

最後に

実際はこんな仕組みを理解しなくても問題なく使えるのが「Azure WebSites」なわけですが、仕組みを知っておいた方が「どんなふうに安定してるのか」とかしっかり説明できていいのかなぁと。
特にこの辺りの内容は専門用語が多く出てくるので、曖昧な知識だったら間違った認識で納得してしまうキケンもありますし…(カタカナばっか難しい)

ただ「より安定性を上げる」目的であれば、2台構成にするとかワザがいるのでしょうけど、とりあえず一般的なレンタルサーバーの安定性はWebSitesを使う時点で約束されてるわけです。
しかも「専有モード」だと月8000円くらいでこれだけの仕組みに加え、5ドメイン分までSSL無料(6サイト目から月918円)が使えるって、コスト的にもすごいと思うんですけど!w

今回は専門用語や概念が多くて、なかなか理解するのが大変でしたが、仕組みがわかるってやっぱり面白いなーと。
しかしながら「知識ゼロの人間に専門知識しかない情報をチャットで教える」という、無茶振りにも文句言うこと無く技術指導いただいた @kazumihirose さん、本当にありがとうございました!

Pocket

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

次のHTML タグと属性が使えます: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>