 |
ASP.NET Webアプリ開発の裏事情エピソード6：Webサーバ管理と闘う！―― 24時間365日、Webサイトを止めないために ―― 小田原 貴樹（ハンドル・ネーム：うりゅう）2005/04/06 |
|
Page1
Page2
|
|
外出先にて、自社のデザイナーからの突然の電話。その瞬間、嫌な予感が脳裏をよぎる。
|
筆者：
|
「もしもし？ どうした？」 |
|
デザイナー：
|
「……どうも、預かっているサイトが止まってるっぽいんですけど……」 |
|
筆者：
|
「げ！！ どういう表示になる？」 |
|
デザイナー：
|
「よく分からないエラー画面が表示されます」 |
|
筆者：
|
「『ページを表示できません』とかっていうメッセージではない？」 |
|
デザイナー：
|
「違います。何かアプリケーション・エラーがどうしたみたいな……」 |
|
筆者：
|
「データベース・サーバがハングアップしてる！ すぐに電源を入れ直してほしいんだけど！」 |
|
デザイナー：
|
「ど、どのサーバか分かりません！」 |
|
筆者：
|
「……なんていうか、ラックの一番左の黒いやつ！」 |
Webアプリケーションに限らず、昨今はサーバと連携して動作するソフトウェアが増えてきており、サーバ管理の必要性は増す一方である。ただ、Webアプリケーションの開発・運用におけるサーバ管理の難しさは、主に企業内部で使用する業務系アプリケーションの比ではないだろう。特にインターネット上で公開するようなWebアプリケーションの場合には、24時間／365日稼働していることが原則として要求されるため、運用においてはナーバスにならざるを得ない。開発終了後、どういった環境で運用を行うのかは非常に大きな問題である。
稼働時間の問題以外にも、そのようなWebアプリケーションの運用では、「サーバの台数がどうしても多くなってしまう」というシステム構成の課題が存在する。まず、最低限Webサーバが必要なのは当然として、データベースが絡んでいればデータベース・サーバが必要になる。ここまでがミニマムなシステム構成だとして、ドメインを解決するためにDNSサーバが必要になることは多々あるし、メールの送信が入るとメール・サーバも必要だ。
そんなこんなで、あっという間にサーバが4台。開発用にテスト・サーバが欲しいなぁとか、すべてのサイトを1台のWebサーバに配置するのはパフォーマンスが……などと考え始めれば際限がない。気が付けば、事務所内にはサーバが乱立し、夏場はクーラーなしでは生きていけない環境が出来上がっていたりする。
サーバの役割を明確に切り分けるためには、サーバの台数を増やす方が望ましいのだが、台数が増えれば増えるほど管理の複雑さ・煩雑さも増加する。そうするとハードウェア的なトラブルが発生する確率も高くなるわけで、冒頭の会話のような泥臭いドタバタ劇も時として繰り広げられることになる。
これは私見だが、サーバ管理面においてほかのWeb系システム言語と比較した場合、ASP.NETを利用した方が基本的には開発も運用も容易になると考えている。統合開発環境（Visual Studio .NET）を利用することで、デバッグなどでもサーバのことをほとんど意識する必要がないためだ。例えばASPで開発を行った場合には、デバッグのためだけであってもWebサーバとDBサーバの設定を行って、その都度ファイルをコピーしなければならなかった。しかも、デバッグそのものもエラー画面を確認しては修正する、といった状況でブレークポイントを設定したりということが難しかった（不可能ではなかったが）。
また、運用面においても、Windowsサーバを利用している前提であれば、配置・公開ともにそれほど手間がかかる作業はないだろう。基本的にASP.NETで開発されたアプリケーションは、開発環境で動作していれば、実際のサーバにはファイルをコピーするだけで動作する。コンパイルなどは、変更があるたびにサーバ側で自動的に実行されるため、意識をする必要がない。データベースを利用する場合には、必ずODBCの設定が必要であったASPなどに比べると、ASP.NETは配置・メンテナンスともに容易になった。ただし、新しい技術だけにトラブルが発生した場合の原因追究が難しい点や、ASP.NETに対応したレンタル・サーバやホスティング・サービスがそれほど普及していないという問題は存在する。
ということで、今回はWebアプリケーションの構築とは切っても切り離せない、サーバ管理上の悪戦苦闘をほんの一部だけご紹介しよう。一昔前であれば、プログラマとサーバ管理者の間にはきっちりとした線引きがあったように思われる。だが、インターネットの普及が進むにつれ、プログラマにもサーバ管理の知識が必要とされてきている。人海戦術など不可能な中小の現場における、「にわか管理者」の悲哀が伝われば幸いである。
メンテナンスできない？ お盆・正月が正念場！
|
デザイナー：
|
「……なんかカリカリ、音がしてませんか？」 |
|
筆者：
|
「……うん、異音がしてるね。サーバの辺りから」 |
|
デザイナー：
|
「大丈夫なんですか？」 |
|
筆者：
|
「大丈夫じゃないかもしれないんだけど、気付かないふりをしてたんだよ……」 |
|
デザイナー：
|
「気付いたんなら、何とかしましょうよ！」 |
|
筆者：
|
「うーん……でも、いまのところ動作が止まったりはしてないんだよね」 |
|
デザイナー：
|
「でも、ヤバイでしょう？」 |
|
筆者：
|
「いま（夕方）サーバを落として、メンテナンスするのはねぇ……」 |
|
デザイナー：
|
「そうですね。サイトを見ている人も多いでしょうし……」 |
|
筆者：
|
「……む、むぅ。夜の2時くらいにメンテナンスするかぁ……」 |
|
デザイナー：
|
「それまで何も起きないといいですね……」 |
インターネット向けWebアプリケーションの運用において、何よりも重要なのは「稼働している」ことだ。何かしらのトラブルで停止してしまった場合には、とにかく復旧させることを優先しなければならない。
しかし、突然動作が停止するようなトラブルが発生することはまれであり、そこに至るまでの日々の運用の中で、何かしらのサインが表れているのが普通だ。上述の会話のような異音というのも1つのサインであるし、ハードディスクの動作ランプの点滅ぐあいなども1つのサインとなるだろう。
そうしたサインが読み取れれば、トラブルが発生する前にメンテナンスを行い、障害を予防したいところなのだが、「稼働していること」が最重要なのでメンテナンスのためとはいえ、おいそれとWebサイトを停止させるわけにはいかない。そうなると自然に、アクセスの少ない深夜などにメンテナンスをしなければならなくなる。
24時間稼働が原則なのだが、どうせサイトを停止しなければならないのなら、顧客の業務が稼働している昼日中や、アクセスが集中しやすい時間帯を避けるのは当然の心理といえるだろう。特に、せっかく動作しているサーバを止めて再起動させるのには勇気がいる。再起動のプロセスでトラブルが発生し、起動しなくなってしまうことはよくあることなので、そういう事態も想定するなら深夜に作業する方が、気が楽なのだ。
何とも情けない話ではあるのだが、同様の理由でゴールデン・ウィーク、盆、正月などの長期連休は大きなメンテナンスをする最大のチャンスとなる。アクセスも比較的少ないし、何より顧客となる人々も普通は休みだ。人が休んでいるときに働かなければならないのは苦痛なのだが、トラブルによるクレームが避けられると思えば慰めにはなる。この辺りは、企業のシステム管理者と何ら変わることのない心理状況だと思われる。
|
【コラム】ASP.NETを安定稼働させるためのハードウェア・スペックとは？ |
 |
 |
| INDEX | ||
| ASP.NET Webアプリ開発の裏事情 | ||
| エピソード6：Webサーバ管理と闘う！ | ||
 |
1．Webアプリ開発者が直面するWebサーバ管理の課題 | |
| 2．Webサーバ管理に対するリスクヘッジの重要性 | ||
 |
||
 |
「ASP.NET Webアプリ開発の裏事情」 |
- 第2回 簡潔なコーディングのために （2017/7/26）
ラムダ式で記述できるメンバの増加、throw式、out変数、タプルなど、C# 7には以前よりもコードを簡潔に記述できるような機能が導入されている - 第1回 Visual Studio Codeデバッグの基礎知識 （2017/7/21）
Node.jsプログラムをデバッグしながら、Visual Studio Codeに統合されているデバッグ機能の基本の「キ」をマスターしよう - 第1回 明瞭なコーディングのために （2017/7/19）
C# 7で追加された新機能の中から、「数値リテラル構文の改善」と「ローカル関数」を紹介する。これらは分かりやすいコードを記述するのに使える - Presentation Translator （2017/7/18）
Presentation TranslatorはPowerPoint用のアドイン。プレゼンテーション時の字幕の付加や、多言語での質疑応答、スライドの翻訳を行える
 |
|
|
|
|
