WEBサービス運用における、監視とバックアップについての考察

インターネットでサービス構築を行う際に、サービスが正常に動作しているかどうか担保できていますか？ と聞かれたら・・・サービス運用を実際にしている会社のエンジニア達はどのように答えるでしょうか？ 僕が過去に聞いたことがあるエンジニアのセリフです。

1. AWSで運用しているので落ちたことが無いです。 2. メディアページのようなアクセスボリュームが多くないので、問題ありません。 3. クラウドサーバーを利用しているので、毎日バックアップを取っていていざという時は、それでリカバリーします。

実際にエンジニアの人は新たな開発や、各種メンテナンスで忙しいため、大体がこうした対応をしますが、非常にお寒い会社さんでは、プログラムエンジニアは、「サーバーは自分の範疇外なので、そうした事はサーバーチームに任せてます」などと他人行儀な返答をする人もいました。 もちろん、しっかりと監視、バックアップを運用している会社もありますが、今回は「WEBサービスにおける、監視とバックアップはどのように構築すればいいか」を考えてみたいと思います。

サービスにあったポリシーを設置しよう

まず最初に考えなければいけないのが、あなたの運用しているWEBサービスは、どういう状態になったら「障害」かという事です。 サーバーがダウンしていても、利用ユーザーがページを開いていない状態であれば、障害と見なさないのか、 それとも、フルタイム稼働していないと、ログが取得できないので、少しの時間でもサーバーがダウンしていたら障害になるのか、 そうした障害の境界線は、サービス内容によって異なってきます。 もしかすると、無料公開ページでの情報提供サービスのため、サーバーがダウンしていても、保証などは一切発生しないというのであれば、障害というレベルが違ってきます。 基本的には、利用者にどういう情報をどういう頻度で提供するので、最低限どういう運用レベルを維持するかという事を「サービス利用規約」として明示しているかどうかがポイントになります。 利用規約の無い金銭の発生しないサービスであれば、正直細かな監視やバックアップをしなくてもいいのかというと、実はそうではなくて、サーバーのダウンが、ハードウェア障害でストレージがお逝きになられた場合、データ損失という自体になります。 データは消えては困るという場合は最低限のバックアップは必要になるので、できれば、最低限の監視、バックアップはお作法として嗜んでおくことをお勧めいたします。

運用ポリシーを考えよう

前置きが長くなりましたが、実際に運用ポリシーを設定してみましょう。 インターネットサービスにおいて、障害と言われるもっとも主な原因はサーバー障害や回線障害です。 他にも、ブラウザやOSなどのアップデートに伴うアプリケーションの仕様変更であったり、各種ソフトウェアのバージョンアップに伴う不具合や、上位互換性の欠如などが考えられますが、こうした事も考慮して、下記の2点で考えるといいでしょう。

1. サービスが正常に稼働している 2. サーバー、ネットワークが正常に稼働している

そして、この2点において、以下の様にリストアップしてみましょう。

# WEBページの確認 ・サイト内のそれぞれのページが正常に表示される。 ・表示完了時間が10秒以下である。 ・送信フォームで正常にデータ送信が行える。 ・検索機能やサービス機能が正常に使える。

# サーバー稼働の確認 ・サーバーがダウンしていない状態 ・サーバーに負荷がかかっていない状態 ・サーバーにデータがたまりすぎていない状態 ・不正アクセスがされていない状態。

大雑把にリストアップするとこんな感じでしょう。 もっともっと細かく書いて言ったほうがより具体的な施策ができるので、できるだけ粒度を細かくリストアップしてみましょう。

どのように監視をするのがベスト？

外部監視と内部監視

監視は大きく分けてサーバーの外部と内部で行う2種類を区別して行う事ができます。 どちらか片方ではダメで両方行う事で非常に高品位なヘルスチェックができる状態になります。 外部監視とは、サーバーの外側から確認できるのは、そのサーバーが公開サーバーであれば、pingアクセスやhttpなどのプロトコルアクセスがエラーなくできるかどうかをチェックします。 生死確認という言い方をする場合もありますが、まさしく外部からサーバーが正常動作しているのかを確認する作業です。 内部監視とは、サーバー内での負荷状態や、ストレージの圧迫率、その他コマンドを叩いて返ってくる値などが正常かどうかの判定ができます。 サービス規定などで定まっている閾値がある場合は、値チェックなどを行い、ボーダーライン判定をする事が可能になります。 このように、外部と内部で監視区分を分けて、外部監視でエラーが出た時に、内部監視ログによって、その原因をすぐに特定できるという状態が作れたら、サービス稼働率は格段にアップするでしょう。

PUSH型とPULL型監視

監視する時に気をつけなければいけない点として、監視をするサーバーも、サービス稼働しているモノと同じサーバーであり、監視サーバーがダウンするという自体も想定しなければいけないという事です。 いたちごっこのような無限ループが想像できますが、僕のオススメは、仮に本番サーバーが冗長構成として２台用意されているのであれば、それを相互監視するような、外部監視と内部監視をセットするだけで、両方が同時にダウンしない限り、必ずエラー検知ができる状態が作れます。 その際に、重要な思考として、PULL型とPUSH型を考えてみましょう。 PULL型というのは、外部サーバーの情報をログ取得して、正誤判定を行うやり方 PUSH型というのは、サーバーの状態を一定時間で外部サーバーに送り出して、判定は外部サーバーで行うという方法。 どちらがいいという事ではなく、理想型は、監視サーバーは、隔離されたサーバーで冗長化されていて、そのサーバー時間で定期的に他のサーバーの状態を取りに行くPULL型にする事で、ログデータが取れないという外部監視も可能になります。 また、それぞれのサーバーの内部監視ログも、監視サーバーで、一定期間収集する仕組みが作れると、多数存在する監視を一括して行う事が可能になります。 ポリシーなどをDB化して、閾値などをサーバー毎に別々に監視したり、エラーが発生した時に、メール送信などのアラート方法を一元管理できる事で、より対応の早いサービスクオリティが提供できるようになるはずです。

便利に使える監視サービス

https://savamoni.com/ 無料でサーバー監視ができてしまうサービスです。 外部監視による生死監視が5分足で行えます。 僕もこのブログでセットしているので、ダウン通知などがメールで届いて便利に使ってます。 5サイトまで無料で使えるのですが、外部監視のやり方を勉強する上でもまずはアカウント登録をしてみましょう。 ちなみに、サーバーモジュールをインストールすると、ある程度の内部監視も行えますよ。 https://www.cman.jp/network/ ping監視に加えて、ポート監視が行えます。 HTTP,FTP,POP3,SMTP,DNS などの監視ができるので、モジュールがダウンしているかどうかの監視が行えます。 https://boxil.jp/mag/a2573/ こちらのブログで、サーバー監視製品の紹介がされています。 まずは片っ端からみてみて、気に入ったものを使うのもいいでしょう。

バックアップポリシーを考えよう

バックアップをする時にとりあえずデータをコピーしておくというだけでは物足りません。 仕事でやるべきバックアップについて考えてみましょう。

期間と頻度

期間というのはバックアップデータをどのくらいの期間保持しておかなければいけないかという事。 データには、次の２つの特性があり、「最新の物のみ有効なデータ」「過去も含めた全ての履歴データが必要」データの内容によって、この２つを分別しておくといいでしょう。 例えば、サーバーのシステムログなどは、一定期間の過去分も含めて保持が必要ですが、ユーザーの利用データなどは過去のものは必要がなく、最新のデータに更新されていればいいだけです。 データバックアップにおいて、無駄なものは極力取得しない方がいいのですが、とりあえずとっておくということも消えてしまって困るよりはいいので、消さないポリシーという風に運用している会社も少なくありません。 次に「頻度」ですが、データの更新頻度とユーザーのアクセス頻度を元に考えるのがいいでしょう。 要するにデータをバックアップする頻度の事ですが、1日に1回程度でいいのか、1時間に1度バックアップしなければいけないのか、1週間に1度というケースもあるかもしれません。 もちろんサービスにより異なりますが、この頻度は、もしも本番システムでデータ破損が起きた時に復旧した状態が、どのくらい巻き戻るかという目安になります。 SNSサービスのようなユーザーデータで欠損が発生しては困るような場合は、随時ミラーリングバックアップを行うようなケースもありますが、多くのサービスでは、1日毎のバックアップを深夜バッチで取得するのg亜一般的なようです。

バックアップ先

バックアップ先は、バックアップサーバーである必要がありますが、よくAWSのS3に放り込んでおけば大丈夫と言っているエンジニアの話を聞きますが、それって、膨大になった時に取り出す事が可能ですか？ AWSの様な帯域に対して課金されるサービスの場合は、安かろうとしてバックアップデータを鬼のように溜め込んでしまうと、いざという時に、スピードは遅い上、とんでもないコストが発生してしまう事もあるので、その辺は事前に計算しておいた方がいいでしょう。 もっともお手軽なのは、別場所に構築してあるストレージ領域に溜め込んで、いざという時は直接そのサーバーに触れる環境にするというのがいいでしょう。 もちろん、セキュリティは十分に考慮してくださいね。

リカバリー方法

リカバリーは、障害復旧において最も気を使う点です。 明らかなデータ破損であれば、バックアップデータをまるまる復元して、欠損期間を明示すればいいのですが、できれば欠損は無くしたいのがクオリティを追求する姿のため、今残っているデータとの差分を見つけ出し、そのデータを継ぎ足したりする事もよく行われます。 しかし、リカバリーをする時間も検討してみましょう。 仮に障害発生した当日に前日分のデータを復旧させた場合、最大1日分のデータ が失われてしまいますが、リカバリーに1日夕してしまうと、サービスが実際に使えない期間も合わせると、最大２日間もデータが取れない期間が発生してしまうことになります。 リカバリーは、十分検討を行って、復旧手順書を作っておくことで、一刻も早い安定稼働にもどすという一番重要なサービスクオリティは怠らないようにしましょう。

ディザスタリカバリー

そもそも障害は予知できないものですが、天災などの自然の脅威によるサーバートラブルは、防ぎようがありません。 地震や水害など、毎年のように日本国内のどこかの地域で発生している災害が、あなたのサービスサーバーの置いてあるデータセンターに発生するかもしれません。 クラウドサーバーだから大丈夫なんて考えているエンジニアはいないでしょうね？ クラウドサーバーでも必ず物理サーバーが存在します。 でも、クラウドサーバー運営者は、物理サーバーの設置場所を公開しないのが最近の流れなので、実際の利用者は、災害対応を事前検討しておく必要があります。 もちろんこれは、データセンターをべつのIDCに切り替えて行うというレベルの検討が必要なので、別のクラウドサービスなどを用意しておくといいでしょう。

バックアップは"rsync"

バックアップは、"rsync"コマンドで行うのが一般的です。 rsyncには、相手サーバーにデータを送信するやり方と、相手サーバーからデータを引っ張ってくる、PUSHとPULLのどちらも対応できるという優れものです。 さらに、sshアクセスでデータのやりとりを行うので、セキュリティ的にも問題なく対応できます。 具体的な使い方は rsyncを極めてとインフラ運用に強くなろう！ こちらを参考にしてください。

監視とバックアップだけでは不十分

実際にダウンした時を想定した、"手順書"を作成しておこう。 データを貯めていて、それをバックアップしているという状態では、まだまだ点数にして50点です。 それらを使ったリカバリ方法をきちんと検討して、実行できる状態にできてようやくバックアップを取っている意味が出てきます。 さらに、バックアップデータも膨大に膨れ上がりがちなので、バックアップデータの削除ポリシーなども忘れずに付け加えておかなければ、多くのチームが、バックアップサーバーが満タンになってしまってから、このことを考え始めるケースも少なくありません。 さらに、できれば、リカバリーは実践してみることをお勧めします。 僕も実際に予行練習ができておらず、仕事でサーバーがダウンしてデータが飛んだ時に修復に膨大な時間を要してしまった経験があり、少なくとも、実行するコマンドなどは書き出しておくと、自分以外でも誰でも対応することは可能になります。 バックアップは心のゆとりが生まれる非常にいい思考なので、切羽詰まっているチームなどでは、こうした思考を取り入れて、非突発する出来事を回避できるように事前準備してみませんか？