システムの負荷増加にどう耐えるか: ブラック フライデーに向けた大規模な準備について話します

おい、ハブル！

2017 年のブラック フライデーでは、負荷がほぼ 2018 倍に増加し、サーバーが限界に達しました。 この XNUMX 年間でクライアントの数は大幅に増加し、慎重な事前準備がなければ、プラットフォームは XNUMX 年の負荷に耐えられない可能性があることが明らかになりました。

私たちは可能な限り最も野心的な目標を設定しました。私たちは、たとえ最も強力な活動の急増に対しても完全に備えておきたいと考え、年間を通じて事前に新しい能力を立ち上げ始めました。

当社の CTO アンドレイ・チジ (チジ・アンドレイ) では、2018 年のブラック フライデーに向けてどのように準備したか、転倒を避けるためにどのような対策を講じたか、そしてもちろん、そのような慎重な準備の結果について説明します。

今日は 2018 年のブラック フライデーに向けた準備についてお話したいと思います。大規模なセールのほとんどが終わっている今、なぜ今なのでしょうか? 大規模イベントの約XNUMX年前から準備を開始し、試行錯誤を繰り返しながら最適解を見つけました。 暑い季節に事前に対策を講じ、最もタイミングの悪いときに発生する可能性のある詐欺を防ぐことをお勧めします。
この資料は、そのような株から最大の利益を絞り出したいすべての人にとって役立ちます。 この問題の技術的な側面は、マーケティングの側面に劣るものではありません。

大セール時のトラフィックの特徴

一般的な考えに反して、ブラック フライデーは 7 年に 8 日だけではなく、ほぼ XNUMX 週間にわたって行われます。最初の割引オファーはセールの XNUMX ～ XNUMX 日前に到着します。 ウェブサイトのトラフィックは週を通して順調に増加し始め、金曜日にピークに達し、土曜日には店舗の通常レベルまで急激に減少します。

これは考慮することが重要です。オンライン ストアはシステムの「速度低下」に特に敏感になります。 さらに、メールマガジンの投稿数も大幅に増加しました。

ブラック フライデーをクラッシュなく乗り越えることは戦略的に重要です。 ウェブサイトとストアニュースレターの最も重要な機能は、プラットフォームの動作に依存します。つまり、次のとおりです。

• 製品推奨の追跡と発行、
• 関連資料の発行（例：矢印、ロゴ、アイコン、その他の視覚要素などの推奨ブロックのデザイン画像）、
• 必要なサイズの製品画像を提供します (これらの目的のために、ストア サーバーから画像をダウンロードし、必要なサイズに圧縮し、キャッシュ サーバーを通じて各製品に必要なサイズの画像を生成するサブシステムである「ImageResizer」を使用します)。各推奨ブロック)。

実際、2019 年のブラック フライデー中、サービスの負荷は 40% 増加しました。 Retail Rocket システムがオンライン ストア サイト上で追跡および処理するイベントの数は、5 秒あたり 8 リクエストから XNUMX リクエストに増加しました。 より深刻な負荷に備えていたため、そのような急増にも簡単に耐えることができました。

一般的な準備

ブラック フライデーは、特にあらゆる小売業と電子商取引にとって忙しい時期です。 現時点でのユーザー数とユーザーのアクティビティは大幅に増加しているため、私たちはいつものように、この忙しい時期に向けて徹底的に準備しました。 ここで、ロシアだけでなくヨーロッパにも多くのオンライン ストアがあり、ヨーロッパでは興奮がはるかに高く、ブラジル シリーズよりも熱意のレベルが劣っているという事実を付け加えましょう。 負荷の増加に完全に備えるには何をする必要がありますか?

サーバーの操作

まず、サーバーの能力を高めるためには何が必要なのかを正確に把握する必要がありました。 すでに 10 月に、ブラック フライデーに特化した新しいサーバーの注文を開始し、合計 XNUMX 台のマシンを追加しました。 XNUMX月までに彼らは完全に戦闘状態になった。

同時に、一部のビルド マシンがアプリケーション サーバーとして使用するために再インストールされました。 私たちはすぐに、推奨事項の発行と ImageResizer サービスの両方のさまざまな機能を使用できるように準備しました。これにより、負荷の種類に応じて、それぞれの機能をこれらの役割のいずれかに使用できるようになりました。 通常モードでは、Application サーバーと ImageResizer サーバーには明確に定義された機能があります。前者はレコメンデーションを発行し、後者はオンライン ショッピング Web サイトのレターやレコメンデーション ブロック用の画像を提供します。 ブラック フライデーに備えて、ダウンロードの種類に応じてサーバー間のトラフィックのバランスをとるために、すべてのサーバーを兼用にすることが決定されました。

次に、Kafka (Apache Kafka) 用に 5 つの大規模サーバーを追加し、XNUMX つの強力なマシンからなるクラスターを作成しました。 残念ながら、すべてが期待したほどスムーズにはいきませんでした。データ同期プロセス中に XNUMX 台の新しいマシンがネットワーク チャネルの幅全体を占有したため、追加プロセスを迅速かつ安全に実行する方法を緊急に見つけなければなりませんでした。インフラ全体。 この問題を解決するには、管理者は果敢にも週末を犠牲にする必要がありました。

データの操作

サーバーに加えて、負荷を軽減するためにファイルを最適化することを決定しました。私たちにとって大きな一歩は、静的ファイルの変換でした。 以前サーバー上でホストされていたすべての静的ファイルは、S3 + Cloudfront に移動されました。 サーバーの負荷が限界値に近かったため、長年これを実現したいと考えていましたが、絶好のチャンスが到来しました。

ブラック フライデーの 3 週間前に、ImageResizer がクラッシュした場合に以前にキャッシュされた画像が cdn から取得されるように、画像のキャッシュ時間を XNUMX 日に増やしました。 また、画像の保存期間が長くなるほど、サイズ変更にリソースを費やす必要が少なくなるため、サーバーの負荷も軽減されました。

そして最後になりましたが、ブラック フライデーの 5 日前に、新機能の導入およびインフラストラクチャでの作業の一時停止が発表されました。負荷の増加に対処することにすべての注意が向けられています。

困難な状況に対応するための計画

準備がどれほど高品質であっても、ファカップは常に可能です。 そして、起こり得る重大な状況に備えて 3 つの対応計画を策定しました。

• 負荷の軽減、
• 一部のサービスを無効にする、
• サービスの完全なシャットダウン。

プラン A: 負荷を軽減します。 負荷の急増により、サーバーが許容可能な応答タイミングを超えた場合にアクティブ化する必要がありました。 この場合、すべてのリクエストに対して単純に「200 OK」で応答し、空の応答を返すトラフィックの一部を Amazon サーバーに切り替えることで、徐々に負荷を軽減する仕組みを用意しました。 これがサービス品質の低下であることは理解していましたが、サービスがまったく機能しないのか、トラフィックの約 10% に対して推奨事項が表示されないのかの選択は明らかです。

プラン B: サービスを無効にする。 サービスの部分的な低下を暗示します。 たとえば、一部のデータベースや通信チャネルをアンロードするために、個人的な推奨事項を計算する速度を低下させます。 通常モードでは、推奨事項がリアルタイムで計算され、訪問者ごとに異なるバージョンのオンライン ストアが作成されますが、負荷が増加した状況では速度を下げることで、他のコア サービスが引き続き動作できるようになります。

プランC: ハルマゲドンの場合。 完全なシステム障害が発生した場合、当社はお客様との接続を安全に切断できる計画を準備しています。 店舗の購入者は推奨事項を表示しなくなるだけであり、オンライン ストアのパフォーマンスには何の影響もありません。 これを行うには、新しいユーザーがサービスとの対話を停止するように、統合ファイルをリセットする必要があります。 つまり、メインのトラッキング コードを無効にし、サービスはデータの収集と推奨事項の計算を停止し、ユーザーには推奨ブロックのないページが表示されるだけになります。 以前に統合ファイルを受け取ったすべてのユーザーに対して、DNS レコードを Amazon と 200 OK スタブに切り替えるオプションを提供しました。

結果

追加のビルド マシンを使用しなくても、負荷全体を処理できました。 また、事前の準備のおかげで、策定された対応計画は必要ありませんでした。 しかし、行われた作業はすべて、予想外の大量のトラフィックの流入に対処するのに役立つ貴重な経験です。
2017 年と同様に、ブラック フライデーにはサービスの負荷が 40% 増加し、オンライン ストアのユーザー数が 60% 増加しました。 すべての困難と間違いは準備期間中に発生し、そのおかげで私たちとクライアントは予期せぬ事態から救われました。

ブラックフライデーをどう乗り越えていますか？ クリティカルな負荷にどのように備えていますか?

出所： habr.com