コラム 「SiteTrackerのシステム運用設計のポイント」 | SiteTracker(サイトトラッカー)

SiteTrackerやアクセス解析のコラムです。

第6回 SiteTrackerコラム

『SiteTracker のシステム運用設計のポイント』 2009.08.28(2012.05.09改訂)

ゼネラルマネージャー 山崎典子

「SiteTracker はインストール型のアクセス解析ツールです。」

システムの構成や運用についてはお客様毎の社内のポリシーや調達可能なサーバを利用されるなど、事情に合わせて実施されているケースも多いため、ご訪問したりお問合せをいただいた際に初めて運用状況を伺い、「そんな使い方もあるのかぁ」と感心することがあります。

よくあるのが、システム運用チームが他のシステムの運用ポリシーに合わせて構築し、ミッションクリティカルなシステムと同様のサービスレベルを提供するために運用負荷が膨大になったり、処理速度が悪化するケース。

アクセスログ解析ツールは用途としても仕組みとしても、通常の社内システムとは異なる特徴があります。

主な相違点は・・・
1. 大容量のデータを扱うため、HDDのI/O負荷が非常に高い。
2. データベースに大容量の解析データを蓄積する必要があり、またバックアップすべきアクセスログは更に多い。
3. 他システムに比べ、ミッションクリティカルでない場合が多い。
4. Webサーバで時々刻々と吐き出されるアクセスログを定期的に取り込む必要がある。
5. 直接閲覧、操作するユーザ数が少ない。
ということは、バックアップポリシーやサービスレベルもその他のシステムとは異なるはず。
では・・・

『普通はどうしてるの?』

まず、図のようにシステムを構成するのが一般的です。

システム構成例

そして、下記のような定期的な処理を自動化すると運用効率が上がります。

【日次処理】----------------------------------------------------
(1) Webサーバで一日に一回、ログローテーションを行う。
  - ログローテーションのタイミングは0:00をお勧めします。
  - 解析対象となる全てのログファイルを同じタイミングでローテートする必要があります。
(2) Webサーバからアクセス解析サーバにログファイルを転送する。
  - 解析対象とする全てのログファイルを解析サーバのローカルディスクに転送します。
(3) SiteTrackerにログファイルを取込み、解析する。
  - 解析結果が翌朝の業務開始前までに終了するようなサーバ構成やスペックが求められます。

【月次処理】---------------------------------------------------
 解析データをアーカイブする。
  - あらかじめ想定した「保持期間」を超える解析レポートをアーカイブ(静的化)し、SiteTrackerのデータベース上の解析データを削除します。

『バックアップは?』

企業におけるアクセス解析システムの重要性に依存しますが、一般的に障害発生~復旧までの対応が2、3日程度であれば、業務上、大きな支障がない場合がほとんどです。

したがって、コールドスタンバイやホットスタンバイのような、システムの冗長化は行わず、ディスク障害等でデータ復旧が必要な場合は、バックアップ-リストアの形で復旧します。(スタンバイ機を設ける場合は別途ライセンスのご購入が必要となります。)

解析データを週に一度(または月に一度)、休日の定期処理以外の時間にメンテナンス時間を設けてデータベースのフルバックアップを行い、次のフルバックアップまでの生ログ(Webサーバが吐き出したままのアクセスログ)を保持します。

ディスク障害等が発生して、データを復旧させたい場合は、最新のフルバックアップをリストアし、復旧までの日数分、日次処理を実施します。

SiteTracker の設定を変更する時には、作業内容を記したオペレーション記録を残し、最後のフルバックアップのタイミングから障害までの間に発生した作業があれば、フルバックアップをリストアした後に変更を適用します。

生ログは保管しておくことをお勧めします。 ~生ログさえあれば再解析が可能~

長期にわたった生ログについては、Webサーバの運用としてバックアップいただくことをお勧めします。特に複数サーバのログを解析する場合、解析サーバ側で保持し続けることは多くの場合、困難です。また、生ログは企業にとっての重要な資産ですので、企業のバックアップポリシーに則って保管されるべきものだと考えます。

『解析サーバのハードウェアを選ぶときに注意しなくてはいけないことは?』

まず、RAID構成ですが、通常のシステムではデータ保全性の観点から、RAID-5で構成する場合が多いのですが、SiteTrackerの場合、極端にレスポンスが悪化するため、RAID-0 またはRAID-0+1で構成してください。

また、冒頭にあるように、I/O負荷の高いシステムですので、I/O速度がボトルネックになりがちです。したがいまして、ハードディスクは回転速度は15,000rpm以上、ディスクアクセスの負荷分散のため、物理的な本数も6本以上を推奨しています。

ディスクを外付けにする場合や、データベースサーバを解析サーバと別立てにする場合は、特に通信速度がネックにならないように注意が必要です。

本当の意味でアクセス解析ツールをビジネスに活用するには、システム的な制約を極力排除することが不可欠です。その上で、マーケッターの方がアクセス解析データを「どう活かすか」を追求し、コンテンツやサイト構成の最適化、広告の費用対効果の最大化に注力できるのだと考えます。SiteTrackerの豊富な機能を皆様のビジネスに最大限にご活用いただくことが私たちの喜びです。
何かお困りな点がありましたら、お気軽にご相談ください。

SiteTrackerをお使いになる上でお困りな点がありましたらお問い合わせください。LinkIcon

山崎 典子 Noriko Yamazaki

SiteTrackerをはじめとする製品の企画・販売を行うネットビジネス事業部を取りまとめる。システムエンジニア経験も豊富で、ことあるごとに開発現場に入りたがる。

※ 記載されている所属名・役職名は、掲載当時のものです