Webサービス・サーバーの無停止化を試行(1)

Webサービス・サーバーの無停止化を試行(1)

巷で話題のビッグデータですが、裏方の作業は本当に大変です。

データベースやサーバーなどシステムと名のつくものは、必ずキャパシティ(許容限界)というのが存在し、それをクリアする事が地味ながらも非常に大変でしたので、その時の作業を整理して纏めて行きます。

状況確認

現在、phpで受付、そのphpがxmlを生成してデータ蓄積側に通知している。

今回の問題は、PHPプログラムにて発生してました。

細かく言うとPHPがXMLデータを作成して、データを蓄積しているサーバーに通知している箇所です。

簡単な構成

  • フロント : PHP処理
  • バックエンド:hbase

現状なデータフロー

  1. 各サービスからのデータをphpにて受付
    ・サービス毎にphpが用意されている
    ・サービスやクエリパラメータによってデータ蓄積先(テーブル)が変わる
  2. phpはクエリパラメータを解析
  3. XMLの作成
  4. バックエンドに通知

この4番の時点でバックエンドが機能していない場合は以下の問題となる

  • データ蓄積されない(冒頭にあるとおり)
  • アクセスログからのリカバリが必要となる
  • 通知したサービス側にエラーのステータスコードを返すのでjavascriptのエラーとなる
  • 開発者ツール等でみているとjavascriptのエラーになるので発覚する

検討

フロント受付とバックエンドへの通知が1つになっていることが問題と判断した。

対応案

phpは受付専門として、バックエンドの通知は別で用意することにする。
また、通知するデータの材料はURLベースなのでアクセスログから対応することが可能と判断した。

  1. 定期バッチを用意
    ・アクセスログを解析して通知するバッチを自作
  2. fluentdを使用
    ・アクセスログを監視して通知するpluginを用意

リアルタイム寄りにする必要はないがアクセスログの監視は設定で行ってくれる上、監視対象ファイルの処理ポジションを覚えていてくれるので2番を採用した

改善後の簡単な構成

現状の構成にfluentdを追加のみ

改善後のデータフロー

  1. 各サービスからのデータをphpにて受付
  2. fluentdにて処理
    ・アクセスログに書き込まれたレコードを解析
    ・クエリパラメータ解析
    ・XMLの作成
    ・バックエンドに通知

現状のバックエンドが停止している場合に起こる先の2つの問題は以下のようになる

  • データ蓄積されない問題
    バックエンドが復旧すれば停止時点から自動でXMLの通知が再開される
  • 通知したサービス側にエラーのステータスコードを返すのでjavascriptのエラーとなる
    常にステータスコード200(正常)を返却するようになるのでWebサーバが落ちているといった状態でなければ問題になることはない

次回は、作業内容について書いて行きたいと思います。

コメント