自社ECサイトの自動スケーリング：トラフィック急増への対応、拡張戦略、コスト管理と監視

自社ECサイトの自動スケーリング：トラフィック急増への対応、拡張戦略、コスト管理と監視

1. 自社ECサイトのトラフィックピークとはどんなものか

自社ECサイトのトラフィック曲線はToCアプリとはまったく異なります。ToCアプリのピークはランダムです。バズった動画やトレンド入りで、10分でアクセスが10倍になります。自社ECサイトのピークはほぼ予測できます。業界展示会の1週前に広告を出稿する、新商品の発売日、海外顧客が欧米の平日午前にメールから公式サイトへアクセスする、といった具合です。つまり終日自動スケーリングする必要はなく、予定されているイベントの前にマシンを増やせばよいのです。

判断基準は一つです。過去3か月のピーク発生時間をカレンダーに書き出せるならスケジュールスケーリングを使います。ピークが完全にランダムで、通常の5倍を超えるなら、リアクティブスケーリングを保険として併用します。B2Bサイトの現実は前者が90%です。CDNの静的キャッシュでピークトラフィックの70%はさばけます。詳しくはCDNグローバル高速化。

2. リアクティブスケーリング：閾値をどう設定すれば安定するか

リアクティブスケーリングで最もよくある問題は”振動”です。CPUが60%を超えたので1台追加し、2分後にトラフィックが落ちて削減し、3分後にまた増えて、1日に十数回増減を繰り返します。これを解決するには3つのパラメータを使います。起動閾値、継続時間、クールダウンです。自社ECサイトの推奨値は、CPUが60%を3分間超えたらマシンを追加、拡張のクールダウン5分、削減のクールダウン15分です。

もう一つの鍵は最大インスタンス数の上限設定です。上限のない自動スケーリングでは、クローラーやDDoS攻撃を受けると、クラウドの請求書を見るまでインスタンス数が増え続けます。最大5台に設定し、それを超える分はサーバーを増やすのではなくCDNとWAFで対応します。監視アラートとレート制限の連携についてはサイト監視とアラート。

三、スケジュールスケーリング：自社ECサイトに最もお得な戦略

展示会前日の夜にcronを設定し、2時間前にインスタンスを1台から3台に増やし、展示会終了の2時間後に1台に戻します。これがリアクティブスケーリングより安上がりな理由は2つあります。新しいマシンはコールドスタートからトラフィックを受け付けるまで5分かかり、リアクティブスケーリングはCPUアラートが出てから起動するため、マシンが準備できる頃にはピークの半分が過ぎています。スケジュールスケーリングはピークが来る前にマシンを用意するので、ユーザーの待ち時間はゼロです。

実行可能なスケジュール例：月曜から金曜の朝8時（ヨーロッパの顧客の出勤時間に合わせて）に2台へ増やし、午後5時に1台へ戻す。展示会の日は2時間前に3台へ増やす。週末は1台を維持。このスケジュールルールで自社ECサイトの予測可能なピークの80%をカバーでき、月のコスト増は300元以内に抑えられます。多言語サイトのトラフィック時間帯の違いについては多言語GEO。

四、コスト管理：スケーリングで本当にコストが下がるのか

自動スケーリングのコストモデルはシンプルです。時間単位の課金で、4コア8GのVPS1台は1時間あたり約0.5元。昼間に3台へ増やし、夜に1台へ戻すと、1日あたり約4元、月に約120元の追加です。スケーリングをせずピークに備えて常時3台にすると、月のコストは600元増えます。スケーリングで節約できるのはこの480元です。

ただし直感に反するコストの落とし穴があります。新しいマシンの起動には時間がかかり、イメージの取得が遅かったり依存関係の初期化に時間がかかったりすると、増やしたマシンは最初の10分間空回りします。イメージを小さくし（参照Dockerイメージの最適化）、ウォームアップスクリプトを事前に実行することで、1台あたりのコールドスタート時間を10分から2分に短縮でき、この節約もコストになります。

五、監視：オートスケーリングは動いていることを知る術が必要

オートスケーリングを導入したら、必ず監視ダッシュボードを用意しましょう。そうしないと、いつ拡張しているのか、なぜ拡張したのか、上限を超えていないかが分かりません。見るべき指標は4つです。現在のインスタンス数、拡張イベントの回数、平均CPU使用率、インスタンスあたりのエラー率。イベントログは毎日、コスト曲線は毎週確認しましょう。

判断の目安はこうです。1週間でリアクティブ拡張が5回を超えたら、定時ルールが実際のトラフィックパターンをカバーできていない証拠なので、そのイベントを定時スケジュールに加えましょう。逆に1回も発動しなければ、リアクティブルールのしきい値を緩めるか停止して、深夜にアラートで起こされないようにしましょう。監視アラートの完全なリストはこちらサイト監視とアラート。

FAQ よくある質問

最後に

自動スケーリングは自動化すればするほど良いわけではありません。自社ECサイトのようにトラフィック曲線が予測できるビジネスでは、カレンダー上で把握済みのピークを2時間前に拡張しておく方が、どんなスマートアルゴリズムよりもコストを抑えられ、信頼性も高くなります。リアクティブ拡縮はあくまで保険で、まったく予想外の突発トラフィックに対応するためのものです。

実行は3ステップ：まず過去3か月のトラフィック曲線を集計し、把握済みのピークをすべて洗い出します。次にそのピークをスケジュールタスクとして登録し、2時間前に拡張、2時間後に縮小します。最後に保険としてリアクティブルールを1つ追加し、CPUが60%を超えた状態が3分続いたら発動、最大5台で上限とします。この3ステップで、月額コストは常時3台より半分節約でき、ピーク時もユーザーは何も気づきません。関連する監視はこちらサイト監視とアラート。

覚えておきたい一言：自社ECサイトのピークはサプライズではなくカレンダーです。スケジュールタスクに書き込む方が、CPUアラートを待ってから対応するより10倍安く済みます。