「LINE砲」って？
今年の2月、3月、5月の三回にわたり、LINE電話をご利用の皆様に、LINE株式会社様と共同でIIJmioのプロモーションメッセージを送信いたしました。お送りしたメッセージをタップすると、IIJmioのキャンペーンサイトにリンクするというものです。
こういった、LINEを活用したプロモーションメッセージを送信すると、「LINE砲」と呼ばれる現象が発生します。LINEのメッセージ配信はほとんど一斉に皆さんのスマホに着信し、さらにそれを読まれた方が素早く反応してWebサイトにアクセスされるため、メッセージの配信直後からリンク先のキャンペーンサイトにとんでもない勢いでアクセスが殺到するのです。これを大砲になぞらえたのが「LINE砲」です。(「LINE砲」は非公式に使われている俗称です)
この「LINE砲」、実はWebサーバにとってはかなりの試練です。LINEから誘導された大量のアクセスに対し、Webサーバの処理能力が追いつかないと、ブラウザにエラー画面が表示されたり、画面が表示されなくなってしまったりします。せっかくメッセージを見てWebサイトにアクセスしてくださったのに、これではあまりに申し訳ありません。(そして、広告費用がもったいないです)LINEでプロモーションを行うためには、大量のアクセスに耐えられる強力なWebサーバを準備しておく必要があるのです。
「LINE砲」に耐えるWebサイト
このようにプロモーションなどでトラフィックが急増する場合に活躍するのが「IIJ GIOコンテンツアクセラレーションサービス」(略称CAS)です。CASはWebキャッシュサービス(CDN)と呼ばれるものの一つで、大量のアクセスに対してWebサーバに代わってコンテンツを送り出してくれます。CASを使うことで、Webサーバを強化することなく「LINE砲」の圧倒的なアクセスを受け止めることができるのです。
先程のIIJmioのプロモーションメッセージのために用意したWebサイトで、実際にお客様向けにどの程度のトラフィックを配信したのかを見てみましょう。1
ご覧の通り、メッセージを配信した瞬間、まるで絶壁のように垂直にトラフィック(=アクセス)が立ち上がり、瞬間最大で2.4Gbpsにも達していることがわかります。スマホ向けの比較的シンプルなWebサイトでこれだけのトラフィックはなかなかたたき出せません。
どうしてCASを使う方が良いのか？
「CASのようなサービスを使わなくても、最初から強力なWebサーバを用意しておけば良いのでは？」と思う方もいらっしゃるのではないでしょうか。確かにクラウド(IaaS)を使えば一日単位で仮想サーバを利用することができますので、キャンペーンに合わせてサーバを用意することも不可能ではありません。ですが、IaaSを使うよりもCASを使った方が色々メリットがあるのです。
どれだけサーバを準備すれば良いかわからない
この手のプロモーションでいつも頭を悩ませるのが、「どれだけの性能のサーバを準備すれば良いか」です。メッセージを送った件数だけでなく、クリエイティブ(広告画像や宣伝文句)の出来の良さにも依存するため、プロモーションによってどれだけWebサイトにアクセスがあるのか予測がつかないのです。
予測がつかない以上、当てずっぽうでサーバを用意することになります。もちろん、高性能なサーバを大量に用意すればサーバの能力不足で画面が表示されなくなることは避けられますが、思ったほどにアクセスが伸びなかった場合はそのサーバが無駄になります。いくらクラウドといえどもサーバの用意には費用もかかりますし、準備の手間も馬鹿になりません。
その点、CASであればアクセス数の想定は不要です。IIJが用意した設備は非常に大きなキャパシティがありますので、「LINE砲」のような大量のアクセスでも耐えられます。また、CASは初期費用無料且つ、実際に配信したトラフィック量にのみ課金しますので、アクセスが多くても少なくても無駄な費用は発生しないのです。
オートスケーリングでは間に合わない
ところで、IaaSサービスには「オートスケーリング」という機能もあります。これは、アクセス数の増加に合わせて仮想サーバを自動的に追加する仕組みです。アクセス数の予測ができない場合でも、必要に応じて自動的に仮想サーバを増やすことができれば無駄は最小限に抑えられるにちがいない、という理屈です。
ところが、「LINE砲」のようなパターンではオートスケーリングはうまく機能しません。というのも、一般的に、オートスケーリングは、アクセス増加→仮想サーバの負荷上昇→仮想サーバのコピー→仮想サーバ起動という順番で動作するため、サーバが追加されるまでにある程度のタイムラグがあります。しかし、前掲のグラフのように「LINE砲」ではある瞬間に突然大量のアクセスが押し寄せるため、オートスケーリングがこのアクセスに反応しても、新しい仮想サーバが追加されるまでのタイムラグに耐えきれないのです。
CASの設備はそのようなアクセスの急増も考慮した構成になっていますので、タイムラグ無くアクセスを受け止めることができます。
CASでは対応できないケース
と言っても、CASも万能ではありません。後に詳しく書きますが、CASは「キャッシュサーバ」という仕組みを使っています。キャッシュサーバでは、アクセスのたびに毎回同じ内容を返すWebサイトには効果的に利用できますが、アクセスのたびに異なる内容を返すWebサイトでは効果が限定的です。
たとえば、ECサイトではアクセスするたびにカートの中身が変わったり在庫量が変わったりしますが、このようなサイトはCASにはあまり向いていません。また、ブログ系のサイトでも、アクセス毎にサーバ上のプログラムで画面を生成するタイプの場合は同様に効果が限定されます。
このようなサイトに大量のアクセスがある場合は、Webサーバ自体の性能を高めるか、大量のアクセスを受け止めるためのクッションページを別に設けるなど、別の手法での対策が必要です。
CAS活用の具体的なTips
色々メリットがあるCASですが、効果的に活用するためにはいくつかポイントを押さえておく必要があります。IIJmioのプロモーションサイトを例に、そのポイントをご紹介しましょう。
CAS利用時の基本的な構成
CASの基本的な動作原理は次の通りです。
コンテンツを配置するのは、「オリジンサーバ」と呼ばれるWebサーバです。オリジンサーバは新規に準備しても構いませんし、既存のWebサーバをそのまま利用することもできます(既存Webサーバを利用する場合の注意はこの後に)。
Web閲覧者からのリクエストは、オリジンサーバではなくCASが受け付けます。最初のアクセスの時にはコンテンツがCASには保存されていませんので、このリクエストをオリジンサーバに中継してコンテンツを取得します。そのコンテンツをWeb閲覧者に返しつつ、CASの一時保存領域に保存(キャッシュ)します。
次回以降、同じリクエストが送られたときは、CASはオリジンサーバにリクエストを中継することなく、保存しておいたコンテンツをWeb閲覧者に返します。2こうすることで、オリジンサーバ(Webサーバ)の能力が十分ではなくても、多数のアクセスを受け止めることができるのです。
今回のプロモーションサイトの構成
IIJmioのプロモーションメッセージで使用した、キャンペーンサイトpromo.iijmio.jpは次のような構成です。
Webサーバは、本家サイトwww.iijmio.jpとは別に、IIJ GIOホスティングパッケージのV803を2台利用しています。ここではパッケージからインストールできるApache httpdを動かしていますが、特に凝ったチューニングは行っていません。サーバが2台あるのは万が一の障害に対応するためで、能力的には1台で十分まかなえるレベルです(V80ではなく、一番低いグレードのV10でも十分でした)。
IIJmioの本家Webサイトであるwww.iijmio.jpは、新規のお申し込みなどを受け付けるためにサーバ上のプログラムで毎回画面を生成しています。このため、www.iijmio.jpに対してCASを使っても効果が限定的なので、大量のアクセスが見込まれるプロモーションサイト専用のWebサーバを用意しました。
先程のトラフィックグラフを再掲します。左側のグラフはCASが送り出したトラフィックのグラフで、前述の通りメッセージを配信した直後に2.4Gbps程度の鋭いピークが出ています。ところが、右側のグラフにあるように、Webサーバ自身が送り出したトラフィックはピークでも1～2Mbps程度。なんと、ほとんどのコンテンツはCASの設備から配信されており、Webサーバにはそよ風程度のアクセスしか来ていないのがわかります。
cookieつきのリクエスト
CASを使う上で注意しなければならないのは、cookieを使用したWebサイトへの適用です。cookieはWebサイトにログインしたユーザ毎に画面を出し分けたり、アクセス解析のために使われたりしています。4
CASは、初期設定ではcookieが使われているWebサイトのコンテンツをキャッシュしません。cookieを使ったWebサイトのコンテンツをキャッシュする場合は、CASの管理画面から「cookie付きリクエスト」を「キャッシュする」と設定してください。
初期設定が「キャッシュしない」になっているのには理由があります。cookieを利用したWebサイトでは、cookieの内容によって同じURLでも画面を出し分けている場合があります。例えば前述のようなログイン機能を持ったWebサイトの場合、同じURLにアクセスしていてもログインした人によって、それぞれのお名前が表示されるようになっています。このようなサイトでcookieを無視してキャッシュに保存されたコンテンツを返してしまうと、他人のお名前が入ったページが表示されてしまう可能性があります。このような個人情報漏洩に繋がる恐れがあるため、標準の設定ではcookieが使われている場合にキャッシュしないように設定しているのです。
IIJmioでの事例にように、プロモーションサイト専用のWebサイトを準備し、そのサイトにログイン機能を一切つけないようにすれば、このような危険性はなくなります。その上で、プロモーションを見て実際に契約を行われる方だけを通常のWebサイトに誘導することで、通常のWebサイトに過度な負担がかからないようにしています。
ところで、ここでもう一つ注意が必要なのが、Google Analyticsを始めとしたWebアクセス解析サービスです。これらのサービスでは、アクセス数をカウントするために、WebサイトにJavaScriptを埋め込みますが、このJavaScriptがcookieを使用するため初期設定ではCASでキャッシュが行われません。プロモーションサイトでGoogle Analyticsを利用している例は多いと思いますので、そのサイト上でログイン機能などが無いことを確認してから「cookie付きリクエスト」を「キャッシュする」に変更してください。
F5キーによる再読み込み
もう一つポイントになるのは、F5キーやブラウザのリロードボタンによる再読込です。このような操作を行うと、ブラウザはサーバに対して「キャッシュを無視して最新のコンテンツを返して欲しい」というリクエストを送ります(“no-cache”付きリクエスト)。このようなリクエストが送られると、CASはキャッシュがあってもそれを使用せず、オリジンサーバから最新のコンテンツを取得します。結果、CASによるキャッシュ効果が無く、オリジンサーバの負荷が異常に上昇してしまうことがあります。
プロモーションサイトの場合はあまり気にならないかもしれませんが、時間を決めて発表を行うようなWebサイトの場合、発表直前に多くの人がリロードを繰り返すことで、このような状態に陥る可能性があります。そのような場合、CASの設定画面から「no-cache付きリクエスト」を「キャッシュする」に変更してください。
ちなみに、このような設定を行うと、本当にWebを更新した際にその情報がCASのキャッシュに反映されない場合があります。そのような場合は、CASの管理画面から「キャッシュ削除」を行うことで、強制的に最新のコンテンツを再取得させることができます。
ご利用お待ちしています
と、いうことで「LINE砲に負けないプロモサイトを作る」お話でした。この構成で、実際にIIJmioが行った3回のLINEプロモーションメッセージ配信を無事に乗り切ることができていますので、同種のキャンペーンを行われる方は是非参考にしてください。
CASは、すでにIIJサービスをご利用の方であれば、オンラインから申し込んで20分程度で利用開始できます。まだIIJのサービスをご利用頂いたことがない方は、お手数ですがIIJインフォメーションセンターまでご連絡ください。