落ちるのは日常茶飯事？　Webサービスの“死因”と対処策とは：「ハードウェア障害」「アクセス過多」「バッチ突き抜け」対策のポイント（1/2 ページ）

本番環境で起こってしまうWebサービスやサーバのトラブルは機会損失や信頼失墜に直結するため、開発者や運用管理者は日頃から備えておく必要がある。だが、備える際のポイントはどこにあるのか。オミカレでCTOを務める曽根壮大氏が、Webサービスやサーバの停止を「死」と捉え、“突然の死”にどう対策していけばいいのか講演した。

　鳴りやまない電話、天を仰ぐ上司、黙々と戦うエンジニア、そして5秒おきに「いつ直るんだ？」と聞いてくる偉い人――こんな「悪夢」、皆さんは経験したことがあるだろうか。2019年12月1日に開催された「PHPカンファレンス 2019」の講演「Webサービスのトラブルの現場〜Webサービスの今と昔」では、ある日突然発生するさまざまなトラブルはなぜ起こるのか、そしてどう備えるべきかを、@soudai氏（オミカレ副社長、CTO《最高技術責任者》の曽根壮大氏）が経験を踏まえて紹介した。

「Webサーバはn度死ぬ」――主な4つの死因とは

株式会社オミカレ 副社長 CTO 曽根壮大氏

　エンジニアならば誰だってWebサービスのトラブルは経験したくないものだ。だが残念ながら、トラブルは発生する。それも突然に、だ。サーバの負荷が急に跳ね上がったり、コネクションがあふれたりといったトラブルが、ホスティング環境の時代からクラウド全盛の現在までも変わらずに発生してきたとsoudai氏は説明した。

　そして「Webサーバは突然死にます。日常茶飯事です」と述べた上で、主な4つの死亡原因（死因）を挙げ、それぞれの症例と対処策を説明した。

　1つ目はアプリケーションのバグによる死だ。「死因として、これが最も多い。だからテストをしましょう。テストは、デプロイしたときにサーバが動かなくて死ぬという事態からアプリケーションを守ってくれる」とsoudai氏は述べ、「PHP Unit」などを使った単体テストや、E2E（エンドツーエンド）のテストなどを実施するよう呼び掛けた。

　2つ目はハードウェア障害による死だ。「アプリケーション側のコードを書いている際、ハードウェア障害はあまり意識しません。しかし電源周りやNIC（ネットワークアダプター）、HDDといったハードウェアは意外とさっくり壊れてしまう。だから冗長化が大切」と同氏は述べた。「クラウドを活用する際、インスタンスを1台立てて簡単にWebサービスを立ち上げられるが、障害時に備えて、もう1台立ち上がるようにしておくべきだ」とし、できれば3台構成が理想だとした。

　3つ目はアクセス過多による死だ。早期に検知し、対処するにはモニタリングが不可欠だ。soudai氏は「皆さん、アクセス監視していますか？」と会場に呼び掛け、Webサービスを構成する各コンポーネントやサービス全体の死活を監視する重要性を訴えた。

　例えばコマンドを使ったり、「Zabbix」や「Mackerel」といった監視ツールを利用してOSやApache、Nginxといったサーバの情報を収集したりするのは基本中の基本。トラブルを解決するには、障害が起きているとき情報だけでなく、「いつからどんな負荷がかかっていたか」「どう推移しているか」を知ることが重要であり、ZabbixやMackerelなどを使って過去のデータを取得してグラフ化（見える化）することが大切だという。「監視ツールへの投資は『無駄なお金だ』と言われがちですが、実はトラブルのときに自分を守ってくれるものです」（soudai氏）

　過去のログ情報は、@noborus氏が開発したコマンドラインツール「trdsql」による収集をお薦めした。trdsqlはCSVやJSONなどに対してSQL文を実行できるツールで、「どのページの実行にどのくらい時間がかかっているか」などのログがCSVやJSONでまとまっていれば、trdsqlによる分析が容易なためだという。「URL監視でWebサイトの死活監視を実施して、異常に気付けるようにしておくことも重要だ」（soudai氏）

　最後の死因は、「誰かのせいで共有サーバがおかしくなる」というものだ。たとえ自分が何もしていなくても、ホスティングサービスでリソースを共有している他の人が負荷のかかる処理を始めたことで、自分のサービスが影響を受けることもある。「自分は全然悪くないのに問題が起こることもあります」（soudai氏）

　soudai氏はさまざまな死因を説明し、「Webサーバって本当に死ぬんですよ。数百台あれば毎日死ぬ。だから、死ぬ前提で準備することが大事です。そして、死んでしまったときは、まず影響範囲を知り、どこが原因で死んだのかを知ることが大切。それには監視が不可欠です」と述べた。