WEBサイト運営で気を付けた方がよいことリスト

WEBサイト運営担当をやってみて、困ったことがある内容についてリストアップしておきます。

電源

サーバー全部の電源容量を計算しておかないと突然容量をオーバーしてブレーカーが落ちることになります。かなり余裕を見ていても、エアコンなど他の機器の影響で落ちたりします。コンセントの老朽化とかで突然電源切れることもあるので、絶対に落ちては駄目なサービスの場合は電源についても二系統化するべき。

バージョンアップ問題

ライブラリとかをバージョンアップすると以前は動作していたものが動作しなくなることが結構あります。ライブラリのバージョンを固定化すればいいのですが、そうするとセキュリティアップデートで困ります。基本的にはライブラリのバージョンアップを行うときには、挙動をすべてテストするのが望ましいです。ただし、低予算のプロジェクトでは無理なので、セキュリティを犠牲にしてライブラリバージョンを固定化するしかないかも。

ハードディスクのクラッシュ

ホットスワップ可能って書いてあるNASかなんかで、HDDを入れ替えたらデータが全部消えたことがあります。事前になにか手順が必要でした。マニュアルはちゃんと読みましょう。大事なデータなら大変な作業だとしてもバックアップを取ってから作業すべきです。（そういう時間や物理的リソースがないことも多いのですが）

マウントされない

停電終了時などに複数のマシンが同時に起動するとき、マウント先に複数のサーバーが同時にマウントにいくと、タイムアウトしてしまい、マウントしないサーバーが出てしまうことがあります。同じタイミングでマウントするのを避け、タイミングをずらすべきです。

ドメイン期限切れ

ある日突然サイトが見れなくなったとき、原因を調べてみるとドメインの期限が切れていたことがあります。期限切れの前に担当者にアラートメールが来るので、確認しましょう。あと管理しているドメインの期限リストを作っておき、更新するのかどうかを月イチ程度で確認するといいでしょう。

デーモン死亡

mysqldなどが突然死んでいることがあります。あとメーラーも時々死にます。apacheも死ぬときあります。だいたい再起動すると正常に動作します。ログを見ても死ぬ規則性がわからないことが多いです。原因が明白な場合はもちろん修正するのですが、原因を追求しきれないことが多いので、デーモンが生きているかどうかを常に確認する処理を行うようにしました。デーモンは突然死ぬことを前提に監視体制を作ったほうがいいと思います。

DBへのアクセスが激重

トラフィックが増えてくるとDBへのアクセスがものすごく重くなってくることがあります。１ページの表示に30秒とか1分とかかかり始めたら赤信号です。当初はそれほどのトラフィックがあることを前提に開発しないことが多いですし、後から様々な機能を追加していくので、当初予想しない処理が増えた結果として重くなるということがよくあります。実はDBへのアクセスはクエリの工夫次第でかなり軽くすることができます。ソースを改修する必要が出た場合でも間にキャッシュテーブルを一個挟むだけですごく軽くなったり。リアルタイムに更新する必要がないものに対して、重いクエリを発行してしまっていることは結構あるので、（プログラマは初期開発時点で将来そのクエリが重くなるかどうかについてあまり考えない）DBクエリをリファインすることは少ない工数で大幅なパフォーマンス向上を見込めます。

トラフィックの増大

何らかの原因でトラフィックが突如として増大することがあります。それはどれかのページにユーザーが殺到しているか、アタックか、内部的な設定のミスでパケットが無限に増大しているのかもしれません。後で問題になる可能性があるのでトラフィックが増大しているときにどのような挙動とするべきかについて、事前に関係者で話しあって置いた方がいいでしょう。基本的にはルータ側などの設定で「アクセス集中により表示できなくなっています」ページを表示します。現状のシステムでどの程度のトラフィックに耐えられるかについて、事前に顧客に提示しておいたほうがよいでしょう。事前の取り決めによりますが、安定的な運用を前提とした場合、トラフィックが突然増大したときに対応できる体制が必要です。

メンテナンス頻度

メンテナンス頻度については後で揉めることがあるので、できれば事前に顧客と話しあっておいた方がいいでしょう。絶対にサイトを止めたがらない顧客もいますので、その場合は労力に見合ったサーバ維持費用を別途見積もった方がよいでしょう。稼働率99%以上を追求するのにはそれ以下の稼働率に比べて数倍から数十倍のサーバ維持費用が発生しますが、このことをわかっていない顧客は結構います。顧客がサーバ維持費用について認識していないことは非常に危険です。メンテナンス画面についても事前に用意しておいたほうがよいでしょう。

パスワード管理

開発中のサーバをテスト的に外部に公開したときに、rootのパスワードがあまりにも簡単なものであったためにハッキングを受けたことがあります。作業のためにポートを開けていたので、そこから普通にrootで入られてしまいました。ロボットによる攻撃で、たまたまハッキング対象となるライブラリがインストールされていないサーバーだったので助かりました。パスワードの変更を忘れていたのですが、テスト的にでも外部に公開する可能性のあるサーバの場合はパスワードは最初から複雑なものにすべきです。

セッションID引継ぎ問題

PHP開発者の人はセッションID引継問題でぐぐってください。ログイン時は必ずセッションIDを新たに生成しないと駄目です。面倒なのでここでは説明しませんがこの問題があると、ある条件で他人のアカウントでログインできてしまいます。常識としてPHP開発者の人はこの問題がないかどうか必ずリリース前に確認したほうがよいです。

人的リソースがあって、テスト環境が万全であれば防げる問題も多いのですが、実際にはそういうものが用意できない会社もたくさんあると思うので、気を付けるべき点がわかっていれば事前に対策を用意しやすいかと思い書いてみました。サーバホスティングを依頼できるなら電源問題とかHDDの問題は発生しないです。（たとえ発生しても自分で解決しなくてもいい）

とりあえずここまで。思い出したら追加します。

[24時間365日] サーバ/インフラを支える技術 ?スケーラビリティ、ハイパフォーマンス、省力運用 (WEB+DB PRESS plusシリーズ)