サーバー監視ツールを作ろう – 8日目「Process数」

まだAWSなどのクラウドサーバーが世の中的に当たり前ではなかった時（今から10年ぐらい前）に、オンプレミスでの運用は通常でした。 色々なWEBサービスを運用している会社で、サーバートラブルが当たり前のように報告されていた中、サーバー障害の法則を見つけました。 サーバーは熱に弱く、衝撃に弱く、想定以上のアクセスに弱いものです。 意図せずに何故か電圧が瞬間的に上がって、ハードウェアがおかしくなったり、CPUや電源やMBなどの回路などが突然壊れるという障害ももちろんありますが、そういう事態は恐らく消費税よりも低い確率での発生率でしょう。

サーバー障害の原因あるある

サーバー障害で最も多いのは、「人的障害」で、プログラムやサーバーOSなどのメンテナンス時に発生することがほとんどです。 金融系のシステム障害というのは、９９%ぐらいこの事象なのですが、一般的なサービスで大手企業のサーバー運用において最も多いのは、「アクセス過多」です。 最近はめったに見ることはなくなりましたが、Twitterのクジラの画像は、数年前までは、当たり前のように見かけました。 ※天空の城ラピュタが放送される時とか・・・www WEBマーケティングツールを企業に提供していた時に見かけたのは、企業が売上アップとして、WEB広告を大々的に発信したその夜に、想定以上の莫大なアクセスがあり、結果サーバーがダウンしてその日の夜の売り上げが全く無くなってしまうという事態も、何度も何社も見かけました。

アクセス数の監視方法

サーバーエンジニアとしては、「想定以上のアクセス数は面倒見きれない」と開き直りがちだが、こうした事象もちゃんと監視するのがサーバー運用なのです。 そして、こうしたアクセス過多はどうすれば監視できるかというと、パソコンでは、OSモジュールからアプリケーションモジュールまで、すべてタスクという形で、渋滞が発生するようにできています。 もちろん渋滞せずに遅延もない状態が望ましいのですが、通常のパソコンであれば、大体50個から100個ぐらいのタスクは常に動いている状態なので、値がそのぐらいでも驚いてはいけません。 そして、もちろんこのタスクを消化するのがCPUにあたるわけですが、CPUの中のコア数が処理効率に関係するのは簡単に創造できますよね。 そうした環境に応じたタスク上限数を把握しておく事がサーバー運用において最も大事というワケなんですね。 そして、肝心のタスク数を確認するには、LinuxOSであれば、"ps aux"とターミナルで打ち込むと、今現在のタスク一覧が表示されます。 もちろん、内容も重要ですが、ここでは、数が知りたいだけなので、"ps aux|wc -l"とすることで、タスク数だけが表示されるようになります。 このタスク数の値の事をサーバーエンジニア連中は「プロセス数」とか「proc数（プロック数）」という風に呼ぶことが多いので、サーバー用語を知らない人はこの点を覚えておきましょう。

psコマンドとは？

psコマンドは、動いているタスクの詳細を見るコマンドなのですが、よく使う方法としては、特定のモジュールが想定以上に立ち上がっていないか？という見方や、動作している時間などを見て、1タスク処理が想定以上に時間がかかっていないかなどを確認します。 psコマンドは色々な機能をもっているので、使いこなしたい人は是非manコマンドで熟読してみてください。 そして、webアクセスの遅延に係るのは、phpなどのcgiモジュールがpsコマンドで大量に存在している場合や、掛かっている時間が、アクセス人数の消化よりも掛かっている場合に確実に順番待ちが溜まりに溜まって、サーバータスクがいっぱいになってしまいます。 一昔前にapache+PHPで構成していたサーバー（2コア）では、proc数が200ぐらいで、サーバーが悲鳴をあげて、ダウンするような感じでしたが、最近の高スペックなサーバーでは、300~400ぐらいは、消化できるものもあります。 これは、abコマンドを使って、サーバーが落ちる値を調べるという手もありますが、サービス運用していないタイミングなどで行う必要があるので、設計時にこうした思考も必要というわけですね。

監視で重要な思考

自分の運用するサーバーのproc上限数が分かったら、何もアクセスしていない時のproc数も把握しておきましょう。 そして、その値の差分がそのサーバーのWEBサービス運用できる値という事になります。 監視対象として、MAX値を検知しても、。サーバーが動かなくなってアラートを発しても遅いので、アラート閾値を50%から70%ぐらいにセットして、サーバーアクセスが増えてきたら、台数をバランシングで増やしたり、不要なサービスを落とすようにして、サービスを停止させないようにする計画を立てておくことが重要になります。 何事も計画が大事ということですね。 こうした思考を持ち合わせていないネットワークエンジニアは、サーバーが落ちてから、ダウンした調査を行い、「PHPが想定よりも多く実行されていた・・・」などとレポートするだけなので、こうした無能な運用担当者にならないように、知識として覚えておきましょう。 でも、こうした担当者は一度はこういう経験をして痛い目を見て、二度と同じ思いをしないようにするという意識付けが重要なのかもしれませんね。

• 1日目「機能検討」
• 2日目「wget」
• 3日目「URLモニタリング」
• 4日目 : ディスク容量検知
• 5日目 : メモリ利用率検知
• 6日目 : LoadAverage検知
• 7日目 : CPU検知
• 8日目 : Process数
• 9日目 : IPアドレス監視
• 10日目 : 対話式コマンド対策
• 11日目 : サービスベータ版完成
• おまけ: サーバ監視ツールの導入
• 特集ページ