ナレッジセンターに寄せられる相談は多岐に渡る。ミッションクリティカルなシステムに発生したトラブルの緊急シューティング依頼が舞い込むこともあれば、発生の予測されるトラブルを未然に防ぐためのノウハウの提供を求められることもある。

 その日、ナレッジセンターの秋山里美は、クライアントから依頼された調査レポート作成が一段落して、やれやれと一息ついていた。ナレッジセンターの仕事は、多忙な時はめったやたら忙しくなるかわりに、いったん依頼が途切れると、何日かは比較的のんびりした状態が続いたりもする。

――これで大きな依頼はほぼ片付いたから、ようやくたまっていた対応履歴のまとめ作業に着手できるかな…――

 秋山が対応履歴のドキュメント化作業に取り掛かろうとしたその時、パソコンのモニターの片隅にメッセージングツールのポップアップが立ち上がった。あれ、誰だろう・・・と目をやると、「takanoからのメッセージ」との表示。このIDは△△事業所の高野のものだ。高野とは数ヶ月前にSE Linux絡みのトラブル対応(第一回連載:リンク)で会話したのを最後に、しばらくやりとりが途絶えている。

Aki:おつかれさまです、秋山です。
takano:おつかれさまです。その節はお世話になりました。
Aki:いえ、とんでもない。その後、例のシステムはいかがですか?
takano:おかげさまで、無事先月のはじめにプレオープンを迎えました。細かい改修などは若干発生しているものの、今の所はクリティカルなトラブルが発生することもなく比較的順調に動いていますよ。
Aki:それは良かったです^^
takano:ありがとうございます^^ それで、今回は折り入ってご相談がありまして…

 高野はそう前置きすると、相談内容について話し始めた。

 高野が所属しているプロジェクトが開発したのは、大規模なイーコマースサイトの基盤となるシステムだった。クライアント企業にとってECサイトを持つのが始めての試みであったということもあり、プレオープン状態の現時点では大々的なプロモーションは行われていなかったのだが、オープンから一カ月が経過してコンテンツの量も増え、登録商品の数もそれなりに充実しつつあることを受け、いよいよ本格的なプロモーションキャンペーンを展開する方針が固められた。

 そうなると心配になってくるのがサイトの性能である。高いコストをかけて集客キャンペーンを展開したはいいが、大量アクセスに耐えられずにシステムがダウンしたなどという事態になっては目も当てられない。そこでクライアント企業からの要望により、キャンペーン実施に先駆けてシステムの見直しが行われることになった。プレオープンから現在までのシステムの稼働状況を確認し、懸念点を洗い出した上で必要な対策を施す。併せて、キャンペーン実施によるアクセス増加を考慮に入れた負荷テストのシナリオの作成・実施。過負荷状況下においても致命的なエラーを発生させることなく、システムが安定稼動することを確認する。

 プロモーションキャンペーンは翌月中旬に実施されることがほぼ決定し、高野を含む保守・運用チームのメンバーが主体となってこの件に対応することになった。プレオープン後のこの1カ月の間に、アクセス数の著しい増加は発生していない。しかし、一般モニターにサイトのプレオープンを公開するメールを送信した直後、一時的にシステムが不安定になったことがあった。システムがダウンするまでには至らなかったが、レスポンスタイムがやや低下し、いわゆる「つながりにくい状態」に陥ったことがある。モニターの人数が数百人と小数であったこともあり、その後同様の状態に陥ることはなかったが、この件は高野の意識に残った。数百人のモニター相手でこうした状態が起こるのであれば、さらに大量のアクセスがあればより深刻な事態に陥る可能性は十分にある。

takano:――というわけで、今、メンバーで手分けして調査作業を進めています。このシステムは某クラウド上に配備されていて、負荷増大時の負荷分散、オートスケーリングについてはそちらに詳しいメンバーが調査を進めているところです。
Aki:なるほど。高野さんはどのあたりの調査を担当されるんですか?
takano:それ以外の全部です(笑) まぁ、そもそも保守・運用メンバーは僕を入れて3名しかいなくて、そのうちの1名はまだ新人に毛がはえたようなものですから。実質的には僕が主体となって、新人君を指導しながら対応することになります。それで、まずはWebサーバやAPサーバの設定見直しからはじめたところなのですが、Apacheの設定に関してお知恵を借りたいことがでてきて、連絡させてもらった次第です。
Aki:Apacheの設定ですか?具体的にはどんなことでしょう?
takano:考えなければならないことは色々あるんですが、 とりあえず今知りたいのは、混雑時に「ただいまサーバーが混み合っています」みたいなページを出すための設定方法です。仮に大量のリクエストが発生して、それをさばききれないような事態が発生しても、それが原因でAPサーバが落ちてしまわないように制御を行いたいんです。
Aki:なるほど、つまり、リクエストがAPサーバの方まで流れてしまってブラウザのタイムアウトでエラーになるのではなくて、Apache側で拒否した上で、「混雑しているから後ほどアクセスしてください」というような画面を見せたいということですね。
takano:はい、そうです。
Aki:ちなみに、システムの構成はどうなっていたのでしたっけ?
takano:アプリはRuby on RailsベースのWebアプリケーションとして構築されていて、アプリケーションサーバにはmongrelを使っています。WebサーバはApache 2.2系で、Apacheとmongrelの間はmod_proxy_balancerで負荷分散を行っています。
Aki:WebサーバーとAPサーバーは異なるマシン上に配備されているのですか?
takano:いえ、同じです。マシンといってもクラウドですから、実際には仮想サーバーということになりますかね。クラウド上に仮想サーバーが1つあって、その上にApacheとmongrelが載っている、という構成です。
Aki: なるほど、おおむね理解しました。ちょうどこの辺りの話に詳しいメンバーがアーキテクト部にいますので、彼もチャットに呼びますね。

 秋本は高野にそう告げると、メッセージングツールの画面上から、メンバーの矢崎のアカウントにチャットへの招待メールを送信した。

Webシステムへのトラフィックを制御する

 不特定多数に公開されるWebシステムは、その性質上、トラフィックの正確な見積もりが困難である。「過去の経験上、こんなものだろう」という想定でトラフィック量を見積もっていても、ある日突然、思いがけないほどのアクセス増加を見ることがある。新聞や雑誌、テレビなどでサイトが紹介されたことが原因で一気にアクセスが集中することもあるし、最近ではTwitter上でのつぶやきが引き金となって人が押し寄せるケースも増えてきているようだ。

 Webシステムを開発・運用する際には、こうした急激なアクセスの増加によりシステムがダウンしてしまうことがないよう十分に配慮することが重要だ。

 ナレッジセンターには専属のメンバーが数名いるが、ナレッジセンターの上部組織であるアーキテクト部のメンバーも原則としてナレッジセンター潜在的要員とみなされ、必要に応じて作業支援を行う体制になっている。

この先は会員の登録が必要です。今なら有料会員(月額プラン)登録で6月末まで無料!