1時間で2万もの集中アクセスが発生するチケット販売サイトを安定させるための活用方法

チケット販売開始直後の2万PVをどう安定させるかが課題

CPIを選択した理由は何ですか？

常にCPIさんを選んでいるわけではなくて申し訳ないんですけど、サーバーは常にシステムや状況に応じて選定しています。複雑なシステムが動くものだとAWSを検討したりもします。

今回は総合的にみてCPIの専用サーバーを2台構成にしてロードバランサーを入れることで、急な瞬間アクセスにも耐えられると判断しました。

急な瞬間アクセスがある要因はなんですか？

まず、『テーマパーク』と『チケット販売サイト』を切り分けて考えるとこの二つのサイトがいかにアクセスが安定しないかがわかります。

『テーマパーク』には、毎年必ず繁忙期が存在しており、通常時は月間60万~70万PV程度のアクセスですが、繁忙期、特に7月、8月、12月はアクセスが倍以上になります。直近で2019年8月には1,467,000PVを記録しました。 ここに『チケット販売サイト』の特性が加わると、今度はチケットの販売開始直後の集中アクセスを考慮する必要があります。

通常だと1日2万~3万のアクセスが、販売開始後は1日15万以上のアクセスが発生します。特にチケット販売開始直後は、1時間の間に2万以上のアクセスが集中します。

こうした集中的なアクセス時の課題を解決するために、ロードバランサーも必要となりました。

チケット販売でユーザーに離脱されないために落ちない設計

ロードバランサーを導入した経緯を教えてください。

単純にサイトを利用するユーザー様のためです。

チケット販売サイトは、通常のECサイトよりも、販売開始時間前から待機しているユーザーが多数いらっしゃいます。 現実で考えるとお店に並んでいるお客様と同じですが、ここでもしシステムがダウンしてしまうと、後からきたお客様と順番が変わってしまったりします。

現実であれば順番通りご案内できますが、Web上だとやはりシステムに依存してしまう関係上、サイトがダウンするわけにはいかないんですよね。 この構成によって、サイトは比較的安定しています。

ここで登場したロードバランサーについて

ロードバランサーとは、大きく分けて「サイトに何かあったときのため」、または「サイトを安定させるため」に利用します。ここではロードバランサーについて、CPIから補足いたします。

サイトに何かあったときのための構成

一般的には冗長化と呼ばれ、システムに何か問題が発生した時に備え、障害発生後にも機能を維持できるように行う仕組みです。

本来、専用サーバーを利用する場合、DNSから直接専用サーバーのIPアドレスを指定します。そのため、ユーザーの導線としてはGoogleなどの検索を行った後、DNSサーバーを介して専用サーバーに辿り着き、ページを閲覧します。

CPIの場合、ここにロードバランサーを追加すると以下のような構成になります。

DNSから専用サーバーではなく、ロードバランサーを指定します。ユーザーの導線としては、Googleなどの検索を行った後、DNSサーバーを介してロードバランサーに辿り着き、その後専用サーバーAに案内されます。

これは100：0の割合で振り分けられた構成になっており、何も問題がなければ、全てのユーザーはAサーバーのサイトを利用します。

ロードバランサーは、このAサーバーの健康状態を細かくチェックしています。例えばAサーバーになんらかの障害が発生すると、ロードバランサーが自動的にユーザーをBへ案内してくれます。

さらにAサーバーが復旧した場合、また自動的にAサーバーにユーザーを案内してくれます。

Aサーバーの内容は定期的にBサーバーへ同期を行っており、Aサーバーで障害が発生しても、ユーザーは問題なくサイトを利用できるわけです。ただしAからBへの同期はリアルタイムではないため、データベース用にCサーバーを用意したり、Bサーバーのみにデータベースを構築するケースが多いです。

サイトを安定させるための構成

目的に応じて導入することで、常に安定したWebサイトを構築する事ができます。

チケット販売サイトの場合、一瞬で多くのアクセスが発生するため、負荷を分散する必要がありました。

そのため、今回の導入目的はこの「サイトを安定させるため」の構成です。今回はAサーバーとBサーバーという2台の専用サーバーを用意し、ユーザーがDNSサーバーを介してロードバランサーにたどり着いた後、５０：５０でユーザーを振り分ける設定を行います。

すると1000人のアクセスが発生した場合、Aサーバーに500人、Bサーバーに500人とユーザーを分散する事ができます。

同期頻度にもよりますが、データベースをAサーバーとBサーバーそれぞれに分けてしまうと、Aサーバーで購入したユーザーが、次にアクセスした時にBサーバーに案内されてしまう事があり、購入履歴が見られなくなります。

そのため、データベースをBのみにする事で、A、Bどちらもリアルタイムにデータを同期できるようになります。このような構成にする事で、負荷の分散を行い、瞬間アクセスにも耐えるWebサイトが完成します。

もちろん、5台の専用サーバーを使って、ロードバランサーで２５：２５：２５：２５と4台に負荷を分散し、データベース用に1台の専用サーバーを使うなんてことも可能です。これはアクセスや状況に応じてカスタマイズすることで、機会損失のないサーバーにする事ができます。

構成については状況に応じて変化しますので、お気軽にご相談ください。