あるクライアントのウェブサイトでは、3ヶ月に一度アクセスが集中するイベントが発生します。以前はレスポンスがわずかに悪化する程度で、それほど大きな問題ではありませんでしたが、最近ではサイトへのアクセスが不可能な状態まで悪化しました。
アクセスログを確認すると、サーバーが同時アクセス数についていけないほどの過剰な負荷には見えません。単純にサーバースペックが不足しているのかと思い、アクセスが集中するタイミングを調査することにしました。
topコマンドでロードアベレージを確認すると、信じられないほどの数値（40を超える）になっていました。あわてて原因を調査すると、データベースの処理が負荷の主要な原因であることが判明しました。
詳しく調べると、アクセスログをデータベースに記録する処理が負荷の原因であることが明らかになりました。アクセスログのデータベースへの記録を一時的に中断すると、ロードアベレージは通常の運用時と同じ値に収まりました。
現状のアクセスログの書き込みの仕様
ねこすけCMSに組み込まれているアクセス解析ツールは、アクセスごとにデータベースに新たなレコードを挿入する方式を採用しています。
以前は日ごとにテキストデータに記録し、数時間ごとにデータベースにデータを取り込む方式でしたが、よりリアルタイムな状況把握の要望に応えるため、アクセス毎にファイルではなくデータベースにレコードを挿入する方式に変更しました。毎回データベースに接続して挿入し、接続を切る方式です。この方式は効率が低いことは予想していましたが、どれほどのアクセスが反応に悪影響を及ぼすかを把握していませんでした。
バルクインサートが早いのは知っているが
バルクインサートの方式が高速であることは理解しています。以前はデータがテキストデータとして保存されており数時間毎にバルクインサートしていました。しかも必要な場合にリカバリーが容易でした。しかし、データベース化されていないログを手動で更新するなど、集計データを表示する前に手間がかかる問題があります。手間がかかると、運用者はますますログを閲覧しなくなります。以前の方式では、フォームが利用された際に、コンバージョンまでの経路を個別に追跡していましたが、手間が増えるだけでこれが行われなくなります。
リアルタイムデータの重要性
数量限定や期間限定のキャンペーンを行うウェブサイトの場合、リアルタイムのトラフィック把握は不可欠です。広告からのアクセスを調整したり、SNSで告知を拡散したりと、入り口のトラフィックを管理することはサイト運営者にとって重要なスキルです。そのためにはリアルタイムのアクセス統計が必要です。ただし、アクセス解析がサーバーレスポンスの悪化の原因となることは避けるべきです。
ウェブサイトによってはリアルタイムにデータベースに記録することができたり、1時間ごとにデータベース化する余裕を持たせたりする柔軟性が求められるでしょう。
