ハウテレビジョン開発者ブログスマートフォン用の表示で見るハウテレビジョン開発者ブログ『外資就活ドットコム』を日夜開発している技術陣がプログラミングネタ・業務改善ネタ・よしなしごとについて記していきます。2015-12-18サーバの監視システムを設計したときに考えたこと弊社では少し前にサーバをAWSに移行しました。それまでは継ぎ足し継ぎ足しで作っていたものを再構成しての移行だったので、この機会にサーバの監視体制についても一新しました。この記事ではそのときどういったことを考えて設計したかをお伝えできればと思います。はじめに決めておくとよいことサーバの監視体制を設計するにあたり、先に決めておくとよいことがいくつかあります。目標稼働率サービス提供時間中はいつでも使えることが理想です。サーバを運用していくうえで予期せぬ障害というものはつきものなので、100%いつでも完全に使える状態にしておくのは大変な労力を伴います。大規模なサービスならともかく、小規模のサービスでは100%動作するように作るのはコストに合わないことが多いと思います。そこで、どのくらいの頻度で、どのくらいの時間止まることを許容するかといったポリシーを決めておくと設計の際に役立ちます。これは目標とする稼働率を維持するのにかかるコストや、障害が発生してサービスが使えない状態になったときの損失などから決めることになります。厳密な計算や定義が必要というわけではなく、プロジェクトの関係者内で同意が取れていれば十分だと思います。実際、弊社では目標稼働率を数値として決めていません。目標稼働率は次のように具体的に考えると決めやすいと思います。例)冗長化されていないサーバが1台壊れたとき、8割復旧まで30分、完全復旧まで120分こういった目標があると、今何が足りていないか、そのために何をすべきかが明確になってきます。システム全体のバックアップを取っておきリストアするなどといった感じです。目標がないと、どこまでやっても終わりが見えなかったり、オーバースペックなものができあがってしまう恐れもあります。費用対効果を考えた対策を行っていくことが重要です。何を監視するか自分たちのサーバがどういう状態にあるべきかといったことを検討し、必要な項目を挙げていきます。サーバの監視では一般的には、サーバの死活監視CPU使用率ロードアベレージメモリ使用量(率)ディスク使用量(率)プロセスの数などを監視します。そこに、必要なプロセスの起動状況、Listenしているポートの状態などを加えていきます。実際に運用していくと自分たちに必要な情報は何かということがわかってきます。いったタイミングで随時追加していくといったやり方でも良いと思います。障害が発生した時にどういった手段でそれを通知するかを決めます。勤務時間中であれば、通常の業務で使用しているメールやSlackなどのチャットツールへの通知で十分だと思います。勤務時間外であれば、担当者個人のメールや、場合によっては電話をかけて知らせる必要があるかもしれません。複数の担当者でシフトを組んで月曜日はAさんに通知、火曜日はBさんに通知...といった設計もあり得ます。要件にもよりますが、PagerDutyなどの外部サービスがフィットするかもしれませんので、そういったサービスも一度検討してみると良いと思います。障害が発生した時、誰がどの範囲を担当するかを整理しておきます。誰がどういう作業ができるか(権限があるか)このプログラムに詳しい人は誰かなどといったことをまとめておくと、障害発生時の通知、その後の連絡体制の設計に役立ちます。復旧までの流れ障害が発生してから復旧させるまでの一連の流れを検討します。いろいろな状況が考えられるので、できるだけ網羅的に洗い出します。次のようなことが考えられます。一次担当者が寝ていて気づかなかった。一次担当者が気づいたが、修正方法がわからない。一次担当者が気づいたが、泥酔しており作業できる状態ではない。これらの事態に対してどういう対応を取るかを検討し、一連のフローにまとめます。細かく洗い出していると、複雑なフローになってしまいがちですが、なるべく単純になるように設計した方が良いです。複雑にしすぎるといざというときに何をすれば良いかわからなくなってしまいます...。クラウドサービスか自前か最近ではDataDogやMackerelなど、サーバにエージェントをインストールするだけで簡単に監視できるサービスがあります。これのサービスを使うと専用サーバを立てなくても良いので、気軽に監視を始められて便利です。料金はおよそ2000円/月/台程度のものが多いようです。自前のサーバにZabbixなどの監視システムをインストールする場合、手軽さでは負けますが自由度の高いシステムが手に入ります。クラウドサービスではデータの保存期間などが決まっている場合が多く、それが制限となってしまうこともあります。例として、弊社の監視体制をご紹介します。弊社では以下のような形で監視システムを組んでいます。(多少簡略化してあります。)ZabbixZabbixをメインで利用しています。Zabbixの選択理由は、以下のものが挙げられます。弊社では新卒就活のサービスを提供しています。就活は季節性のあるイベントですが、最近就活の時期が頻繁に変更されており、負荷のピークが必ずしも1年前とは限りません。そのためデータの保存期間を1年以上確保したいという要望があります。将来的な拡張の余地クラウドサービスでも大抵のことは実現できるとは思いますが、自前のサーバで動かしていると最悪自分たちでカスタマイズしてなんとかするという選択ができます。これまでの実績Zabbixは他社でも多く採用されており実績があり安心感があります。各種リソースの使用状況監視サイトの主要なページにHTTPアクセスして、レスポンスのステータスコードやHTMLの内容のチェックまた、ZabbixでのAWSリソースの監視については、クラスメソッドさんが後悔している「【セッションレポート】ZabbixによるAWS監視のコツ」がとても参考になりました。CloudWatchはZabbix自体を監視するために使用しています。これはあくまで補助的な役割のため、ZabbixサーバインスタンスとZabbixサーバプロセスの死活監視のみに留めています。PagerDuty障害を検知したときの通知にはPagerDutyを利用しています。PagerDutyを使っているのは、通知に関する一通りのサービスがそろっていることが理由です。スマホアプリが用意されていたり、電話で障害を知らせてくれたり...必要なものがほとんど全て用意されています。弊社では今のところ目標稼働率は数字としては特に決めていません。これまで障害の頻度がそれほど高くなかったこともあり、障害が発生した時に随時対応していこうという考えです。(もちろんやるべきことはやったうえでの話です!)障害が発生すると担当者数名に通知が届き一次対応を行います。ほとんどのものはここで対応が可能だと考えられますが、対応しきれない場合、他のエンジニアと電話やSlackなどで連携して解決にあたります。少人数で対応しているため、ベストエフォートで対応するという体制です。まとめこの記事では障害対策について書いてきました。障害はないに越したことはありませんが、サーバを運用している限り避けて通ることはできません。障害は忘れた頃にやってきます。09:09サーバの監視システムを設計したときに考えたことTweet関連記事2018-07-20業務未経験からエンジニアになって半年を振り返るこんにちは、ハウテレビジョンエンジニアのFです。WebDriverで、新規会員登録フローのE2Eブラウザテストを自動化してみた。エンジニアの@bumcruです。Qiitaの「Selenium/Appium...2015-10-27【画像57枚】開発合宿にいってきたぜ!【合宿当日編】どうもこんにちは。エンジニアのvsannaです。はてなブログPro『外資就活ドットコム』の開発チームです。技術ネタ・プログラミングネタ等々書いていきます。業務未経験からエンジニアになって半年を振り返るDocker初心者がRails+MySQLの環境構築をDockerでやってみた月別アーカイブ検索はてなブログをはじめよう!howtvさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。