アクセスパターンを想定した対策
前ページで、Webサイトにアクセスが集中した場合の対策例を確認しました。ここでは、1ページ目で紹介した、Webサイトがバーストしたアクセスパターンごとに対策を紹介します。
パターン①｜国内通販サイトA「PC向けメールマガジン配信、ガラケー向けメール配信、夜間の購買ピークで異なる特性」
パターン①の国内通販サイトAの例では、参照ピークと更新ピークを分けて考える必要がありました。こういったケースでは、最もアクセスが集中するメルマガ発行タイミングに注目が集まり、夜間帯の更新ピークによるDBサーバの負荷を見落としがちになります。ノーマークだった夜間帯に、実はDBサーバがボトルネックになっていた、なんてことがないように注意が必要です。
ECサイトの注文系トランザクションは、在庫の確保や決済など比較的複雑なトランザクション処理が必要となるため、DBサーバにRDBMSを使うことがほとんどです。こういった更新系のアクセスは、CDNやAPサーバなどのキャッシュに頼れないため、更新量に耐えうるDBサーバのキャパシティ設計が重要となります。
それには、お客様との間で、システム終局におけるピークアクセス量（オーダー数、訪問数、購買率など）を性能要件として合意したうえで、それを満たせるか十分な性能検証を行い、事前に性能要件に対して十分な余裕があることを確認するしかありません。WebサーバやAPサーバはスケールアウトによってキャパシティを拡張することが比較的容易ですが、DBサーバ（特に更新系）は事前に十分なキャパシティを確保する以外、有効な手段はないといっていいでしょう[1]。近道はないのです。
[1] ユーザセッション管理などでのデータ更新処理の場合は、RDBMSではなくKVS（Key Value Store）のようなNoSQL系データストアの導入も有効です。NoSQLによるアクセス集中対策についての解説は、本連載の前回記事「ECサイトをバースト負荷から救え！ NoSQLの導入を検討すべきケースと製品選びの基準」をご覧ください。
パターン②｜海外通販サイトB「バナー広告出稿タイミング、SNSのプッシュ通知のタイミングでアクセスが集中」
パターン②の海外通販サイトBの例では、SNSアプリ（スマートフォンアプリ）へのプッシュ通知によるアクセス集中がスローダウンを引き起こし問題になっていました。プッシュ通知に記載されていたURLがAPサーバで動的生成されるページであったため、APサーバのCPUがボトルネックになっていたことがスローダウンの原因になったのです。
メルマガやSNSアプリのプッシュ通知で告知するページは、静的コンテンツで構成されたランディングページにし、CDNや静的コンテンツ専用のサーバでページを送信可能にしておくことをお勧めします。特に、SNSアプリによるプッシュ通知は基本的にスマホで受け取るため、外出先でも開封率が高く、予想しえない数のアクセスが通知されたURLへ集中する傾向にあります。
大量のアクセスがシステムを直撃しないよう、ランディングページは極力静的なページにするべきです。しかし、動的生成されるページを使いたい場合は、なるべくDBへの問い合わせが少ない処理の軽いページを見極め、性能試験などで十分な検証をしておくことが重要となります。また、通知されたURLは、スマホから低速な携帯通信網を経由してアクセスされることが多いため、サーバから送信されたページがユーザ側へ届くまでに時間がかかり、サーバのTCPポートやミドルウェアのコネクションが枯渇しやすくなります。
こういったことも想定して、OSやミドルウェアのパラメータを余裕を持った値に設定しておき、サイトの稼働中にどの程度の余裕があるかをモニタしておくことも重要です。
パターン③｜国内通販サイトC「特定の人気商品の発売にユーザが殺到」
パターン③の国内通販サイトCの例は、人気商品の購入にアクセスが殺到するケースでした。
購入系や申し込み系のアクセスをすべてさばけるように設計することが基本となりますが、キャパシティ拡張などの対策があまりにもコストに見合わないような場合には、サイトのビジネス規模などにもよりますが、特定の時間帯にアクセスが集中しないよう、事前予約や抽選販売などの仕様面の見直しといった運用によるカバーが必要となることもあります。
最悪の事態に陥らないための流量制御
サイト全体の安定性を確保するための最終的な対策として実施してほしいのが、ロードバランサやWebサーバなどの最大同時接続数による流量制御です。入口で負荷を絞り、運悪くあふれたユーザに「Sorryページ」を表示するという最後の手段です。
要件を満たすキャパシティをサイトが備えていたとしても、予想を超えるアクセス集中によりサーバが過負荷状態となってスローダウンが発生し、サイト全体がサイト全体が停止状態に陥るリスクは、企業内システムなどに比べBtoCサイトの場合大きくなります。これまで、我々まかせいのうがチューニングに呼ばれたWebサイトでも、流量制御を実施せずスローダウンによってサイト全体が停止し、原因調査や復旧に時間がかかってしまうというケースが多々ありました。
流量制御は機会損失を生むため、お客様としては「ゼロソーリー[2]」を望まれるものです。もちろん、ゼロソーリーを目指した最適な設計とチューニングを施すことは我々エンジニアの義務ですが、だからといって非常時の備えを怠ってよい、という理由にはなりません。
流量制御はいわば、サイト全体のダウンという最悪のケースを防ぐための最後の安全弁です。これを実施する負荷の閾値をサイトの最大キャパシティとしてお客様と合意しておくことは、非常に大切なことです。
[2] Sorryページを一切表示する状況にならないこと。
おわりに
サイトを運営するお客様の目的は「売上を上げて利益を得ること」です。性能を確保するために実施する様々な対処が、お客様のビジネス側面から見ると大きな制約になることも多々あります。メルマガのリンクは静的ページよりも動的ページのほうが購買率やサイト利用率が高まりますし、リッチでダイナミックなコンテンツに誘導できるほうが、エンドユーザへの訴求力が大きくなります。流量制御で全体のアクセス数を制限したり、静的なページのみでキャンペーンを実施しなくてはならなかったりする状況は、お客様のビジネスにとってマイナスと捉えられてしまうかもしれません。
システム全体がスローダウンして、巨額の機械損失を発生させてしまうことは最優先で避けなければいけませんが、それを回避するための制約でサイト自体の魅力が大きく損なわれてしまわないよう、お客様の要求と制約のバランスをとって設計に反映していくことが肝要です。
今回は、実際のECサイトでのアクセス集中の例とその対策をいくつかご紹介しました。これらの対策がすべてという訳ではありませんが、本稿がECサイトだけでなく、BtoCサイトの設計・構築・運用への一助になれば幸いです。
