AKAMAI ホワイトペーパー

フラッシュセールへの対応DevOps 戦略ホワイトペーパー： 商戦日に備えたトラフィック緩和

著者：Dominic Lovell、 Senior Enterprise Architect、Global Consulting Services、Akamai

フィーチャートグルとダークリリース：最新の展開手法を活かして商戦日のトラフィックに備える 1

この記事の目的は、商戦日に備えるための推奨事項を提供することにあります。この推奨事項には、組織とその DevOps チームをサポートするために、CDN、トラフィックのセグメント化、トラフィックパターンの規模と可視性の自動化などの技法を駆使して、トラフィック急増による影響を最小化することが含まれます。

• フラッシュセールに必要な準備についての知見

• セール期間の前に、ウェブサイトとアプリケーションの限界について理解する

• 大規模なトラフィック急増に対応するためのセグメント化オプション

• セール期間を通じて一貫性のある体験を確保する

• トラフィックパターンやパフォーマンス低下にリアルタイムで対応する

• リアルタイムメトリックを収集し、今後のイベントに備えてスナップショットを取得する

第 1 部 - トラフィックを理解する良好な営業サイクルの下地を作るには、このような種類のイベントの数か月前から準備に時間をかける必要があります。まず、例年の基準値と現在のトラフィックパターンに見られる傾向を把握することが開始点になります。このプロセスの一部として、営業キャンペーンについて、「誰が、何を、いつ、どのように」という点を明確にする必要があります。

それには、以下の質問に答えることから始めます。

• 前年度のセール期間に関する事後検討や成功事例をレビューできるか。

• Google Analytics や、その他のツールを使って前年度のトラフィックを分析できるか。

• 本年度のトラフィックパターンをレビューできるか。レビューできる場合は、以下について確認する。年度ごと（YOY）、月ごと（MOM）のトラフィックは、どのようになっているか。

• 前年度と比較して、ソーシャルメディアのフォロワーはどのように変化したか。ソーシャルメディアのフォロワー数が自社サイトへのトラフィック誘導に影響を与えるほど増加したか。

• CRM にあるメールアドレス数はどれぐらいか。これらの種類のキャンペーンで、標準的なクリックスルー率はどれぐらいか。

• 実店舗の店内トラフィックのうち、どれぐらいが自社のオンラインチャネルをサポートしているか。

• ホリデーの買い物客の購買層を把握しているか。その購買層は、実店舗でショッピングする前にオンラインで バーゲン品を探すベビーブーマーか。または、小売店舗に足を踏み入れないつもりのミレニアル世代の 22% であるか。3

• どのような地理的トラフィックになっているか。さまざまな国やタイムゾーンで、まんべんなく見込み客の需要に応えているか。また、それがサイトで発生するトラフィックの急増に影響を与える可能性があるか。

• デスクトップのトラフィックとモバイルのトラフィックの割合について認識しているか。

短期間の大規模なフラッシュセールで利益を上げたい小売企業では、恒例となるホリデーセール期間のトラフィック急増の管理のために、また通常の取引サイトの立ち上げなどにおいて、e コマースを利用する傾向が強まっています。現在、一部の小売企業では、Amazon のプライムデーや Alibaba のシングルデーなど、ブランドを冠したセール日を設けています。事実、Alibaba は 2017 年の 24 時間セールで 178 億ドルの収益を上げ 1、また一部のアナリストは、Amazon が 2017 年の 30 時間のセールで最大 6 億ドルの収益を上げた可能性を示唆しています 2。メキシコの El Buen Fin、インドの Diwali フェスティバルまでの期間、米国の Cyber Monday、オーストラリアの Boxing Day などの商戦期間において、世界中のオンライン小売企業には、そのオンラインチャネルで高速かつ一貫性のある体験を提供してほしいという要求が増加します。

フィーチャートグルとダークリリース：最新の展開手法を活かして商戦日のトラフィックに備える 2

• 自社サイトへのアクセスに通常使用されているデバイスの種類は何か。それらはハイエンドデバイスか、応答性の低いローエンドデバイスか。

• モバイルフレンドリーであることを確認したか。

• 1 日の特定の時間におけるトラフィック急増につながる可能性のあるコマーシャルを、テレビやラジオで発信しているか。

• セールを開催する URL をお客様に配布する方法について計画しているか。メール、ソーシャル、テレビ、またはその他のチャネルか。

• リピート購入者、高額購入者、その他の重要な価値セグメントのグループにお客様を分類できるか（サードパーティによる分析や、A／ B テストなどのターゲティングツールによって、高価値となる購入者を追跡または区別できるか）。

これらの質問により、地域ごとにユーザーの拠点、オーディエンス数、サイトへのアクセス方法、アクセスに使用されているデバイス、アクセス時間帯などを詳細に把握することができます。

第 2 部 - イベント開催前の準備手順 1 - キャッシング - 基礎優れた営業戦略の一部として、基本から始める必要があります。まず、「キャッシングは適切か、オフロードは適切か」を確認します。CDN によって、トラフィックに関するレポートを入手、または静的および非静的コンテンツのトラフィックをセグメント化できるのであれば、オフロードの量を確認し、キャッシングに関して改善すべき点があるかどうかを判断できます。一般的なアップセル、クロスセル、行動のきっかけなどが、すべて最適な度合いでキャッシュされているかどうかを確認することが重要です。このコンテンツは、最初はキャッシュが不可能に思えますが、実は常に可能であり、一定期間でオフロードできます。ウェブサイトの読み込みが 100 ミリ秒遅れると、コンバージョン率は 7% 下がります。4 一般的な推奨事項として、以下の経験則に従う必要があります。

• 画像、CSS、JS ファイルなどの静的コンテンツ - 7 日以上の高い TTL 値

• ログインページなど、準動的な非パーソナライズ化コンテンツ - 1 日の中程度の TTL

• パーソナライズされたコンテンツ - 1 対多数 - 1 時間の低い TTL

• 価格や在庫などの動的コンテンツ - 10 分の低い TTL

• カスタマイズされたコンテンツ – 1 対 1（お勧めの製品など）- 0 秒の TTL

手順 2 - ランディングページの最適化 SOASTA の調査によると、2017 年の時点では、訪問者にとってサイトの初体験がプロモーションキャンペーンページかもしれないにもかかわらず、これらの種類のページは他のページよりパフォーマンスが低いことがわかりました。事実、これらのページの読み込み時間は、通常のページより平均で 30 ～ 60% 低速でした。5また、ページの重量化、多すぎる追跡タグやサードパーティのスクリプト、事前のパフォーマンステストの不実施、急ごしらえのランディングページなど、いくつかの要素も明らかになりました。これに留意して、ランディングページとキャンペーンコンテンツは、すべてテストと立ち上げのパイプラインにしっかり組み込む必要があります。また、これらのページの重さや読み込み時間を調べて、パフォーマンス上のボトルネックがないことを確認し、問題があれば前もって対処します。

手順 3 - モバイルフレンドリーであることを確認する Akamai の調査では、モバイルデバイスの利用時間のうち、Web の利用時間が最も多く、モバイルデバイスを利用する合計時間の 60% に達することがわかっています。Akamai では、2021 年までに、Web を介して配信されるデータの 90% にスマートフォンが利用されると予測しています。また、Google による 2017 年の報告書では、スマートフォンユーザーがスマートフォンを使用しているときはすぐに何かを購入するという行動が、前年と比較して 50% 増加しているとして、マイクロモーメントの時代と呼んでいます。6

この点を考慮して、開発者や設計者は、サイトがモバイルフレンドリーであり、第 1 部で確認したデバイスタイプがサポートされていることを確認する必要があります。Google は、レスポンシブ・ウェブ・デザイン（RWD）技法 7 を使用してサイトを実装することによって、ユーザーがデスクトップでもモバイルでも同じ体験が得られるようにすることを推奨しています。Akamai で確認された RWD に関する最も大きな懸念は、大きい画像をモバイルデバイスに適切なサイズと解像度に縮小する機能がサイトに備わっていないことです。往々にしてモバイルデバイスにはデスクトップサイズの画像が提供され、ブラウザで表示されますが、それによって配信バイト数が多くなりすぎ、ビューポートに適したサイズに画像を縮小するために、本来は不要な処理がデバイスで必要になります。

フィーチャートグルとダークリリース：最新の展開手法を活かして商戦日のトラフィックに備える 3

第 3 部 - 限界を把握する最適なキャッシング戦略を策定し、セールサイトにアクセスすると思われる種類のデバイスに最適化したら、次は既存のシステムの限界を把握します。トラフィックの急増対策としてオートスケールを考慮するのであれば、多数のインスタンスのプロビジョニング、適切なインスタンスタイプの選択、アイドルインスタンスの実行など、オートスケールには関連する課題があります。オートスケールとリソースの過剰消費との間には、最適なバランスがあります。しかし、前年度の需要を満たしても、本年度のトラフィックを処理できるとは限りません。第 1 部のデータ収集は、最近のトラフィック、一般的なトラフィックパターン、エントリーポイントなどを把握するために役立ちます。このデータを使用して、サイトの読み込みテストやストレステストを実行し、基盤になっているインフラストラクチャの限界を明らかにします。

主な目的は、システムの最大容量を把握し、ダウンタイムの発生を防ぐことですが、同時にアプリケーションの速度が低下し始めるポイントを把握することも必要です。事実、SOASTA によれば、ウェブサイトの速度低下は、サイト停止の 10 倍の頻度で発生することがわかっています。読み込みが遅いページは、1 回のサイト障害のみの場合と比較して、収益に対する悪影響が 2 倍に上る可能性があります。8

少なくとも、次のタイプのテストを実施することをお勧めします。

• スパイクテスト - 短時間における高負荷のバースト

• ピーク時の負荷テスト - 最も負荷が高い時間帯のシミュレーション

• ソークテスト - 長時間の高負荷テスト

• 最大容量テスト - アプリケーションがハードウェアの限界に到達するポイントの把握

自社の CloudTest ツールを使用した SOASTA は、サイトをテストするときに以下の負荷レベルを推奨しています。

• 10 名の仮想ユーザー - 最初にパフォーマンスをテストするためのスモークテスト

• 100 名の仮想ユーザー - 最小トラフィックの負荷をバックエンドが処理できるか

• 1,000 名の仮想ユーザー - 現在のアプリケーションの動作が良好かどうか、接続、データ、応答を待つかどうか

• 最大仮想ユーザー - 予想されるピークを満たすポイントまでテストを拡大

• 最大仮想ユーザーの 2 倍、3 倍、10 倍 - ストレステストを実施し、最大トラフィックのシナリオで、アプリケーションが停止するポイントを把握する

図 1 - 負荷テスト戦略

フィーチャートグルとダークリリース：最新の展開手法を活かして商戦日のトラフィックに備える 4

最大ユーザー数、1 秒あたりの最大リクエスト数（RPS）が不明な場合は、現在のインフラストラクチャで使用可能な CPU とメモリーの制約に基づいて、ウェブサーバーの限界を確認します。たとえば、NGINX は稼働中の HTTP および HTTPS 接続における RPS と 1 秒あたりの接続数（CPS）の限度の背後にある具体的な指標を発表しました。9留意しなければいけないのは、このような種類のリクエストは、たとえばカートやチェックアウト情報など、Edge ではキャッシュできないカスタマイズされたコンテンツや極めて動的なコンテンツであるということです。事前に最適なキャッシング設定を用意しておくことで、可能な限り CDN へのオフロードが確保できます。

負荷テストが完了したら、次に以下の質問に答える必要があります。

• 目標とする応答時間の条件をアプリケーションが満たすか。

• ピーク時のトラフィック後に、アプリケーションが問題なく回復し、通常の動作を継続できるか。

• 目標とする応答時間の条件をアプリケーションが満たさなくなるポイントはどこか。

• どこかの時点で、サーバーがエラーを生成したり、接続を拒否したりするか。

• これらの仮想ユーザーテストのいずれかで、サーバーがクラッシュしたか。最大しきい値を確認できたか。

第 4 部 - 大規模なトラフィックの管理1.トラフィックの初期スパイクの管理大規模小売企業の多くは、サイバーマンデーの前にサイバー・マンデー・セール・キャンペーンの広告を開始します。10 Rubicon による 2016 年の調査では、購買者の 22% がサイバーマンデーを早めに調べ始めることがわかっています。3

購買者はセールにいち早く参加して欲しいものを手に入れたいと考えるため、この時点で増大するトラフィックは予想が困難です。

一方、早めにセールを開始すると、競合他社が同一製品の価格を同じにしたり、下げたりする機会を与えることになります。通過する大規模なトラフィックを処理できる戦略を策定することによって、競合他社に対する競争優位性を確保でき、初めてフラッシュセールに参加した購買者に対して可能な限り最高の体験を提供できます。そのために、すべてのバーゲンハンターは、セール期間の開始日時が明記されたメッセージが表示されるランディングページにリダイレクトされる必要があります。

図 2 - ピーク時のユーザーのデモグラフィック

フィーチャートグルとダークリリース：最新の展開手法を活かして商戦日のトラフィックに備える 5

2.最適な日時にセールを開始する

図 3 - トラフィック全体の監視

- ローリング・セール・ウィンドウというアプローチ第 1 部で述べたトラフィックパターンの分析では、トラフィックソース、トラフィックが多い時間帯、ユーザーの場所などに関する知見が得られるはずです。この知見によって、新しいセールページへのアクセスを許可するタイミングを決定する、セグメント化戦略が提供されます。この方法では、EDM キャンペーンやソーシャルメッセージも、関連のある国やグループのユーザーのみに広告していくというモデルに従う必要があります。

たとえば、オーストラリアやニュージーランドなど、最初に朝を迎える国では、セール日の朝の間に、対象を絞ったメールを受け取ります。必要に応じて、これらのユーザーを州、州ごとに異なるタイムゾーン、数時間の距離にあるウェストコーストの市とイーストコーストの市などにセグメント化できます。同様に、Facebook などのソーシャルネットワークでは、対象のユーザーのみにセールに関する投稿が表示されるように、ユーザーのタイムゾーンや国に基づいて対象を絞った広告を指定することができます。

時間に基づいたターゲットの絞り込みとして、他にモバイルデバイスを早朝に使用するユーザーのコンバージョンが高い場合は、それらのユーザーをターゲットにすることも考慮します。事実、2017 年の Google によるスマートフォンユーザーに関する調査では、スマートフォンユーザーの場所に基づいてサイトやアプリの情報をカスタマイズした企業から購買する可能性が顕著に高いことが示されています。11ユーザーの日常習慣を把握していれば、このような流れに関連するトラフィックを対象にして、誰がいつセールのメッセージを目にするかを決定できます。

広告を発信したら、見込み客のセグメント化ツールを利用して、関連のある場所にいるユーザーや、対象セグメントのユーザーだけが新しく配信された広告を目にするようにできます。ネットユーザーがリンクを共有したり、メールを転送したりする場合、これらのセグメントや国の場所に含まれないユーザーには、まだローリング・セール・ウィンドウが表示されません。これらのユーザーには、セールの告知メッセージのみが表示されるようにするか、サイトの適切なランディングページにリダイレクトして、これらのセグメントのユーザー向けのメッセージとして、そのセグメントのセール開始日にサイトをチェックするよう案内します。これらのランディングページをクラウドのファイルストレージに配置することで、バックエンドのインフラストラクチャから切り離して、CDN にキャッシュできるため、現在サイトで取引を行っているユーザーが着信トラフィックによって影響を受けることはありません。

日が進んでいくと、最初のほうのセグメントや早いタイムゾーンの国からのトラフィックは、夕方遅くまでは増加し続けます。通常、夕方遅くには、これらのセグメントからのトラフィックはゆっくり落ちていきます。この時点で、これらのユーザーが午前零時を迎えたら、再びランディングページにリダイレクトするか、これらのユーザーもサイトで取引を継続できるようにするかを選択できます（この場合は、次のセクションで説明する方法を利用します）。

適切なセグメント化 cookie を使用することで、セールサイトへのアクセスが許可されたユーザーは、割り当てられたセールウィンドウが終わった後も、ブラウジングを継続している場合はチェックアウトまでできるように、セッションの有効中はアクセスを許可します。他の国や地理的場所のユーザーがオンラインになったら、CDN 内の自動化プロセスを利用して、このトラフィックをサイトにプッシュし、別のセグメントにセールコンテンツが表示されるようにします。

フィーチャートグルとダークリリース：最新の展開手法を活かして商戦日のトラフィックに備える 6

3.一貫性のある体験の確保前述のローリング・セールス・ウィンドウという方法を使用すると、1 日中どの時間帯も、すべての地理的場所の 3 分の 2 がセールコンテンツにアクセスできることになります。この間、サイト訪問中のユーザーの優先順位付けを行い、特定の訪問者のみが利用できるコンテンツを提供できます。

最初に使用する優先順位付けの技法では、指標を決定する必要があります。たとえば、カートにアイテムが入っているユーザーなど、サイト訪問中のすべてのユーザーに高い優先順位を付けます。次にこの指標を訪問者の優先順位付けメカニズムで利用して、カートにアイテムが入っているユーザーは、常にサイトを優先的に閲覧できるようにします。たとえば、カートにアイテムが入っているユーザーには、サイトへのフルアクセスが許可される購買者というフラグが付けられた cookie を配布します。その他のターゲット絞り込みオプションとして、特定のクリックスルー URL の UTM クエリーパラメーターや、以前 cookie を配布したリピートユーザーが戻ってきて、リピート購買者としてチェックアウトが見込める場合などがあります。その他のユーザーは、構成可能な設定に基づいて、Yes または No で単純に分類できます。Yes ユーザーは、cookie で確立された設定済みの時間枠に基づいて、無制限にサイトにアクセスできますが、No ユーザーにはサイトへのアクセス待ち行列に入っていることが示された保留ページが表示されます。この保留ページで、動画を表示したり、クーポンを提供したりすることで、これらのユーザーがサイトから移動しないようにします。

第 3 部の負荷テストとプロセスによって、容量の限界、事前定義されたオートスケールパラメーター、現在のインフラストラクチャに影響を与えるハードウェアの限界などがすべて明らかになっています。次にこれらの指標を CDN へのフィードバック信号として使用して、高負荷のサーバー間の負荷分散や、インフラストラクチャ関連のトラフィック移動に役立てることができます。インフラストラクチャへのアクセスを許可するユーザーに優先順位を付けることによって、チェックアウトやコンバージョンページに移動するまで、適切な種類のトラフィックフローが確保されます。ウィンドウショッピングをしているだけで、コンバージョンファネルに進行しないユーザーには、サイトの優先順位付けをしません。

図 4 - バックエンドのインフラストラクチャへのアクセスを許可するトラフィックへの優先順位付け

他の優先順位付け技法には、ユーザーではなくコンテンツに優先順位を付けることができるものもあります。このような技法では、システム内のエンドポイント、または特定の条件下でのみアクセスする API データを定義します。たとえば、多数のボットが設置されているサイトで、これらのボットがシステム全体の負荷を押し上げている場合、正常なセールを実行しようとするユーザーが使用できるリソースの量に悪影響を与える可能性があります。また、コンテンツが検索インデックスに表示されるまでにセール期間が終わってしまうので、これらのボットには、フラッシュセールのコンテンツのインデックスは設定しません。したがって、自律システム番号（ASN）やユーザーエージェント文字列などの値を対象にして、ボットには、キャッシュ済みコンテンツを配信したり、サイトの別の場所にリダイレクトする対応ができます。この API Prioritization 技法を使用すると、他のすべてのユーザーに最新のコンテンツが表示され、リアルタイムでセール情報にアクセスできるようになります。

フィーチャートグルとダークリリース：最新の展開手法を活かして商戦日のトラフィックに備える 7

最善の計画や予測をもってしても、特にフラッシュセールの期間中やストレスの増大時などには、インフラストラクチャが停止したり、予想外の動作を開始したりすることがあります。このようなときは、一貫性のあるブランド体験を確保することが重要になります。「503 Service Unavailable」メッセージが表示されたり、何の説明もなく空白画面が表示されたりすると、ユーザーはサイトを去り、セール期間中は戻って来なくなります。ランディングページやサイトの静的コピーにフェイルオーバーする、フェイルオーバーメカニズムを配置すべき理由はここにあります。このようなイベント発生時には、キャッシュ済みコンテンツの配信を続けるか、クラウドのファイルストレージ場所からサイトの静的コピーを配信する必要があります。サイトのチェックアウトやその他の取引領域を無効にするか、ランディングページなどの別の場所に強制的にリダイレクトすることで、サイト上にいる間はユーザーがそれまでと同じようにサイトを閲覧し、製品情報を見ることができます。この間、アプリケーションの復旧やバックアップの適用が完了したら、ユーザーがバックエンドや取引ページにアクセスできるように、CDN によって自動的にフェイルオーバースイッチを実行するか、事前に設定した手動スイッチでフェイルオーバーを実行します。

Visitor Prioritization や API Prioritization 技法と合わせてこれらのフィードバックメカニズムを使用することによって、顧客に一貫性のある体験を提供できます。この方法では、ユーザーにはセールコンテンツへのアクセス権を取得できる事前定義された機会が提供され、サイトにログインして取引を開始すると、チェックアウトまで優先的にアクセスできます。他のユーザーや、ボット、スクレイパーなどのサードパーティによるアクセスでは、キャッシュされている古いコンテンツのみが表示されるため、システムへの負荷が増大しません。システムが過負荷になると、フェイルオーバーメカニズムが機能して、一貫性のあるブランド体験が確保されます。インフラストラクチャにボトルネックや使用不可の状態が発生した場合も同様です。DevOps 戦略によって実現できる重要なメリットの 1 つは、時間がかかり、ロールアウトに手動による操作が必要なタスクを自動的に実行するシステムを配置できることです。規模やパフォーマンスに関する指標と、トラフィックの優先順位付けや拡大に必要な API を使用することで、手動による操作なしでこれらのメカニズムを運用できます。

4.トラフィックパターンとパフォーマンス上の課題への対応オンライン小売企業の多くは、消費者の満足に関係がある指標がアップタイムだけではないことや、ホリデー商戦に対する準備ではパフォーマンスを重視しなければならないことを認識し始めています。これは Akamai による調査 12

でも裏付けられています。サイトに二度と戻らないユーザーの割合は、ダウンタイムが発生したサイトでは平均で 9% であるのに対して、低速なパフォーマンスを体験したサイトでは 28% です。

ロードの指標とフロントエンドのパフォーマンスは、コンバージョンの向上に不可欠な役割を果たします。Google の調査では、1 ページのロードにかかる時間が 1 秒から 7 秒に増加すると、モバイルサイトの訪問者の直帰率が 113% に増加します。13また、Google の報告書によれば、モバイルサイトにおいて、1 ページのロードに 3 秒以上かかると、すべてのユーザーの半分以上が離脱し、さらに遅延 1 秒ごとに 20 % が離脱します。14したがって、リアルタイムでロード時間を把握できる測定方法と、これらのトラフィックパターンに応じて規模を拡大できる自動化プロセスを配置することが肝要です。

ユーザーやトラフィックのパフォーマンス動向について知見を得るには、リアルタイムの運用ダッシュボードが必要です。これには、すべての地理的場所でトラフィックの分散、エラー、一般的なパフォーマンスを監視するリアルタイムアラートが含まれます。ある地理的場所やセグメントのトラフィックのパフォーマンスが低下したり、パフォーマンス目標を達成できなかったりした場合は、手動による操作によって、ユーザー体験に悪影響を与えている可能性があるトラフィックの移動やサードパーティによるサービスの無効化などが必要になるでしょう。

このような理由により、ロードの指標をリアルタイムで把握し、トラフィックセグメントのパフォーマンスが通常より低下しているかどうかの知見を提供するリアル・ユーザー・モニタリング（RUM）システムが必要になります。たとえば、ユーザーデータを地理的条件で分析した SOASTA によれば、オーストラリアのユーザーは、米国の訪問者と比較して、ロード時間が遅いことに慣れており、サイトのロードが低速でも直帰率が低いことがわかっています。この結果を受けて、ページのレンダリングやロードの所要時間に敏感な見込み客には高い優先順位を付けることを推奨しています。

これらのしきい値がどのようなものであるかを事前に理解することが重要です。これにより、自動化した DevOps トリガーにこれらの基準を組み込むことができます。

たとえば、このような指標には以下があります。

• バックエンドの応答時間（または最初のバイトが到達するまでの時間）

• キャッシングやオフロードの戦略が効果的に機能しているか。

• フロントエンドの応答時間

• ボトルネックの原因になっているサードパーティのリソースやフロントエンドの特定のアセットがないか。

フィーチャートグルとダークリリース：最新の展開手法を活かして商戦日のトラフィックに備える 8

• 必要に応じて、このようなサービスを無効にできるメカニズムを配置しているか。

• アプリケーションからのエラー応答コード

• インフラストラクチャからレポートされる 4xx または 5xx エラーの全体的な割合はどれぐらいか。

• 問題が発生しそうなリクエストを特定するために、トランザクショントレースを実装できるか。

• CDN からリアルタイムでメトリックを取得できるか。

• アプリケーション内の問題が発生しそうなトランザクションをトレースするメカニズムがあるか。

• ソーシャルチャネル全体の意見はどのようであるか。

• 1 つか 2 つユーザーの不満があるだけか、あるいは大きな問題が出現しているか。

一部の RUM システムはウェブフックやアラートシステムを提供するため、このようなシステムを使用すれば、DevOps チームはこれらのしきい値に到達したことを認識できます。たとえば、地理的条件のせいでフロントエンドのロード時間が低速になり、ユーザー体験が低品質である場合、Slack で開発者へのアラートを発信するウェブフックを設定できます。これらのウェブフックは、特定のクラスタや使用可能なゾーンに移動するトラフィックの量を DevOps ワークフローにフィードバックできます。開発者には、これらの自動化された変更が通知されるため、それ以降も監視する必要があるかどうか、リアルタイムで修正すべき大きな問題があるかどうかを判断できます。

アラートトリガーが組み込まれた RUM ダッシュボードは、パフォーマンスやロード時間に関する定量的な指標を提供します。ソーシャルチャネルを通じた定量的なフィードバックのリアルタイム監視と組み合わせることによって、自動化されたトラフィックおよび拡張の全ライフサイクルにわたってサイトがサポートされ、必要な場合は DevOps チームが介入することができます。

図 5 - 地理的条件ごとのリアルタイムのパフォーマンス監視

5.イベント終了後フラッシュセールが終了し、アクセスページが閉じられたら、事後分析用の指標を収集する必要があります。これには、最大ユーザーセッション数、ピーク時のロード時間、トラフィックの地理的詳細、オフロード指標、オリジンサーバーからの応答コードの集約、トラフィック量のレポート、最も閲覧数が多かったページに関するレポートなどがあります。可能な場合は、イベント中もこれらの指標を収集することが重要ですが、イベント後にも重要な指標を収集する必要があります。なぜなら、ほとんどのレポートシステムは、一定期間しかデータを保持しないため、トラフィックパターンを把握する必要に迫られたときや、次のフラッシュセールの準備期間に、これらの指標がシステムにない可能性があるからです。

今後のセールで参照できるように、すべてのプロジェクトとテクニカルチームがイベント後やプロジェクト中に気が付いたことをまとめて整理しておきます。これにより、次回改善すべき問題や機会に関する知見だけでなく、成功した方法に関する知見も得られます。今後のセールで担当者が変わる可能性もあるため、チーム全員がこの資料にアクセスできるようにしておきます。

フィーチャートグルとダークリリース：最新の展開手法を活かして商戦日のトラフィックに備える 9

必要に応じて、このイベント用に設定したランディングページやその他のセールカテゴリの URL からのリダイレクト先を作成して、セールが終了したことを通知するランディングページにトラフィックをリダイレクトします。これらのランディングページは、適切なカテゴリまたは製品のページや、一般的なセールページやホームページなど、サイト上の場所にもリンクします。これにより、セール後にこれらの URL にアクセスしたユーザーが、サイトを閲覧し、チェックアウトできるページに送られます。オフロードを最大化するには、これらのリダイレクトをバックエンドのインフラストラクチャではなく、Edge にキャッシュする必要があります。ランディングページは、必要に応じてクラウドのファイルストレージ場所に格納できます。

第 5 部 - まとめ

フラッシュセールを成功させるには、準備が重要になります。DevOps チームは、トラフィック分析技法により、どこでトラフィックの急増が発生するかを把握し、予測できます。この分析では、最後にトラフィックのデモグラフィックとサイト上のユーザーの行動に関連する質問に答えます。この分析により、規模拡大と負荷テストを計画する際に使用できる基準線が提供されます。

負荷テストを実施する前に、展開されている既存のキャッシング戦略のレビュー、ランディングページのコンテンツ最適化などを含めた、一連の最適化を実行することによって、これらのページが重量超過にならずに良好なロード指標を示す状態を確保します。また、このコンテンツをモバイル向けにも最適化して、コンテンツにアクセスして即座に購入するユーザーを取り込む必要があります。

キャッシングとページのコンテンツが最適化されたら、負荷テストを実行して、現在のインフラストラクチャやキャッシング設定が予想されるトラフィックに対応できるかどうかを把握できます。何種類かの負荷テストを実行して、特定の条件下におけるシステムの動作を確認します。これらのテスト結果から、ユーザートラフィックの拡大を自動化するために使用する指標が得られます。

トラフィックのデモグラフィックを把握することによって、国、タイムゾーン、デバイスタイプ、およびその他の要素ごとにユーザーをセグメント化できます。これにより、セールキャンペーンの事前開始やサイレントローンチの実施をしなくても、セールのトラフィックの初期スパイクを管理でき、重要なセール期間中にすべてのユーザーがシステムを利用できます。そのような技法の 1 つであるローリング・セールス・ウィンドウは、ユーザーを場所でセグメント化し、セール期間中、ユーザーがセールコンテンツにアクセスする時間帯や方法をターゲットにします。

他のセグメント化技法を使用すると、カートにアイテムが入っているユーザーなど、特定のユーザーにサイトへのアクセスが中断されない優先順位を付与することができます。また、フェイルオーバー計画を策定することによって、インフラストラクチャ停止などのイベント発生時にも、一貫性のあるブランド体験を提供することができます。これらの技法と当社の負荷テスト指標を組み合わせて使用することによって、アプリケーションインフラストラクチャが受信するトラフィックが、どんなときでも対応できる適切なレベルに保たれます。

RUM システムを使用すると、自動化されたトリガーによってウェブフックやその他のアラートを起動し、自動化されたトラフィック管理ワークフローにフィードバックを送ることができます。自動化されたこれらのプロセスが発信するアラートや通知により、必要に応じて DevOps チームが手動で介入できます。リアルタイムの RUM ダッシュボードは、ユーザーの満足度やアプリケーションの健全性に関する完全なスナップショットを提供します。

図 6 - 地理的条件ごとのリアルタイムのパフォーマンス監視

フィーチャートグルとダークリリース：最新の展開手法を活かして商戦日のトラフィックに備える 10

セールが終わったら、セール指標を収集して事後分析レポートを作成し、今回のイベントから得た知見を将来のセール担当チームに提供し、今後も適切に最適化できるようにします。

要約すれば、初期トラフィックデータとコンテンツ最適化が完了したら、セグメント化技法とエンドユーザーのパフォーマンスに関するリアルタイムのフィードバックにより、トラフィック管理の自動化が可能となり、アプリケーションインフラストラクチャが大量のトラフィック流入に対応できるようになります。これらのプロセスを自動化することによって、DevOps チームがシームレスかつストレスフリーに、大量のセール、大規模なトラフィック急増、サイト全体のイレギュラーなトラフィックパターンに対応できます。

ご不明な箇所があれば、詳しくご説明いたします。また、貴社固有のユースケースに応じた最善のオプションについてもお話しさせていただきます。ぜひ Akamai アカウントチームにお問い合わせください。または E メールで consulting@akamai.com までご連絡ください。

出典

1） https://www.forbes.com/sites/franklavin/2016/11/15/singles-day-scorecard-a-day-in-china-now-bigger-than-a-year-in-

razil/#615aad921076

2） http://www.practicalecommerce.com/amazon-prime-day-2017-smashes-sales-record

3） http://go.rubiconproject.com/rs/958-XBX-033/images/Rubicon%20Holiday%20Poll%202016%20--%20FINAL.pdf

4） https://www.soasta.com/press-releases/akamai-online-retail-performance-report-milliseconds-are-critical/

5） https://www.soasta.com/blog/marketing-campaign-performance-optimization/

6） https://www.thinkwithgoogle.com/consumer-insights/micro-moments-consumer-behavior-expectations/

7） https://developers.google.com/search/mobile-sites/mobile-seo/responsive-design

8） https://www.soasta.com/blog/downtime-vs-slowtime/

9） https://www.nginx.com/blog/testing-the-performance-of-nginx-and-nginx-plus-web-servers/

10） https://www.fool.com/investing/2016/11/25/what-wal-mart-target-and-amazon-are-doing-on-cyber.aspx

11） https://www.thinkwithgoogle.com/consumer-insights/micro-moments-consumer-behavior-expectations/

12） https://www.soasta.com/blog/downtime-vs-slowtime/

13） https://www.thinkwithgoogle.com/intl/en-aunz/advertising-channels/mobile/au-mobile-page-speed-new-industry-benchmarks/

14） https://www.thinkwithgoogle.com/advertising-channels/mobile/consumer-behavior-mobile-digital-experiences/

Akamai は世界で最も信頼された世界最大のクラウド配信プラットフォームを提供しています。使用するデバイス、時間、場所を問わず、お客様が安全性に優れた最高のデジタル体験を提供できるようにサポートします。Akamai の大規模な分散型プラットフォームは、世界 130 か国に 20 万台を超えるサーバーを擁する比類のない規模を誇り、お客様に優れたパフォーマンスと脅威からの保護を提供しています。Akamai のポートフォリオに含まれる、ウェブおよびモバイルパフォーマンス、クラウドセキュリティ、エンタープライズアクセス、動画配信の各ソリューションは、卓越した顧客サービスと 24 時間体制の監視によりサポートされています。大手金融機関、EC リーダー企業をはじめ、メディアおよびエンターテイメントプロバイダー、政府機関が Akamai を信頼する理由について、www.akamai.com/jp/ja/ または blogs.akamai.com/jp/ および Twitter の @Akamai_GK で詳細をご紹介しています。全事業所の連絡先情報は、https://www.akamai.com/jp/ja/locations.jspをご覧ください。2017 年 10 月発行。