ブラックフライデーが明日で、サーバーの準備ができていない場合の対処方法

ブラックフライデーは、マーケティングに夢中になった人やストリームに参入したばかりの人にとって、誇大広告、狂気の注文、そして大勢の顧客です。



流入に備えてインフラストラクチャを事前に準備しておくのは良いことですが、そのようなことを事前に誰が考えますか？ しかし、時々、参加の決定は前日に行われます。



したがって、消費主義の休日が始まり、オンラインストアのサーバーが陽気に点滅し始め、コールセンターが過熱し、配信サービスが1月のどこかに配信を提供します。

何をすべきか、リラックスして哲学的にファカプを見るか、勇敢に戦うか？







ブラックフライデーの間にオンラインストアのサーバーインフラストラクチャに同行しましたが、事前に連絡することはなく、準備の時間も与えませんでした。 私は私の経験を今日同じ注文を受け取る人々と共有します。



（幸運なことに、数か月でモニタリングを設定し、トラフィック、ボトルネック、プロジェクトアーキテクチャを分析し、ストレステストを実施し、必要に応じて開発者とアーキテクチャを再構築し、追加のサーバー容量を事前に接続してください。正しい対策については改めて説明します。ここでは火災対策について）。

監視を設定します

いずれにせよ、監視が主要だと思います。 まだ問題はありますが、スケジュールの監視のおかげで、ボトルネックがどこにあるのかを理解できます。



可能であれば、Zabbix / Prometheus / ELK（アーキテクチャによって異なります）などのソリューションを使用します。そうでない場合は、okmeter.ioのようにSaaSをすばやく接続します。 セールが1日しか続かない場合でも、Zulusの1日が連続するように、モニターでたくさんのインジケーターを見ることはできません。



プロファイリング用のblackfire.io/newrelic.com、一般的な「スローダウン」ページの分析用のpinba.orgは、まだ素晴らしいツールです。



blackfire / newrelicは特定のページの問題を解析するのに役立ちます、pinbaはどのページが最も頻繁にロードされ、最も長く実行されるかを確認するのに役立ちます（たとえば、これはBitrixのすべての箱から出していますが、サーバーとサイトはすでに非常に悪いです）。

過剰を切り捨てる

オフにできるすべてのものをオフにします。現時点では、条件付きで不要なモジュール、あらゆる種類の可愛さなどです。



販売は簡単なプロセスであり、多くの製品を大幅に割引します。 燃えるような目を持つ訪問者は、売り切れるまで商品を選択し、注文し、割引を受け、支払いをしたいと考えています。

ニュースレターの購読、サイトへの登録、サービスの質についてのポーリング-これらはすべてクライアントに興味がありません。これらのモジュールは無効化または簡素化できます。 サイトが数日間静かに動作できるようにするために、すべてをオフにします。



ケーススタディ：ブラックフライデーの間に、トラフィックの多い稼働中のサーバーでデバッグしましたが、2時間後に配信サービスモジュールが非常に遅く、外部サービスにアクセスし、各注文の送料を自動的に計算しました。 トラフィックが数百倍に増加したとき、これらの外部サービスは対処しなくなりました。



あなたはただ座って考えることができ、あなたのサイト/モバイルアプリケーション/などに何が落ちるでしょうか？

落下させる

とにかくサービスが落ちるという事実に備えています。 この場合、訪問者に少なくとも何かを表示する必要があります。



たとえば、非稼働中の配送サービスモジュールまたは支払いフォームが注文全体をブロックすることはありません。ユーザーは明日戻って注文を完了することができます。



50年代のエラーのページに、営業部門のメールまたは電話番号を表示します。

error_page 500 502 503 504 /50x.html; location = /50x.html { root /srv/www/yourwebsite.com/htdocs/sale-contacts/; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

サイトのコピーを作成する

変更をテストするためにサイトのコピーを作成できる場合、これは非常に良いことです。 私は確立された展開システムの話ではありません:)



ところで、ファッショナブルなクラウドサービスを使用すると、バトルサーバーのコピーをすばやく簡単に作成できます。



ケーススタディ：開発者による最適化（一部は外出中）、リソースの追加、ソフトウェアの最適化の後、ブラックフライデーの間にインフラストラクチャを維持した1つのサイトは、トラフィックが多い場合でも多少許容範囲内で機能し始めましたが、注文時に速度が低下しました。 ユーザーは注文が送信されていないと考え、念のためチェックアウトボタンを数回押しました。 いくつかの人物がボタンを300回押しました！ 素晴らしいストレステスト:)何百倍もの訪問者、そしてさらに約300件の注文！ :)

CDNサービス

CDNがなくても実行できますが、サーバーが適切な量の静的な戻り値に客観的に対処できない場合は、必要です。



1C-Bitrix 、 Wordpressなどの一般的なCMSのCDNをすばやく接続できます。 ただし、外出先でCDNを設定することはできません。事前に注意する必要があります。

AntidDoS

また、AntiDDoSサービスを接続することをお勧めします。そうしないと、突然の負荷がかかると、通常のトラフィックに適応せず、正当な訪問者をブロックし始める可能性があります。



一定の期間、これは無料で行うことができます。

• qrator.net、Bitrixがあれば10日間無料-https://www.1c-bitrix.ru/ddos/
• DDoS-Guard、無料の関税があります-https://ddos-guard.net/en/store/web
• cloudflare.comには無料の料金があります（ただし、ここでは少なくとも最初に支払った料金をお勧めします。ロシア連邦ではIPアドレスがブロックされることが多いことを覚えておいてください）

サーバー機能を追加する

リソースを追加する機会を予見しています。 メインサーバーにリソースを追加したり、クエリを並列化するための新しいノードを作成したり、mysqlのノードを作成したりできます。 あなた自身ではない場合、側で雇われたアウトソーシング業者は、あなたにそのことに感謝します。

プロバイダーが物理サーバーとクラウドサーバー（Selectel.ru、Servers.com）をホストできる場合は便利です。

ふう、行こう

最も危険なことは、ニュースレターの最初の数分です。 キャッシュはまだウォームアップされておらず、統計情報はほとんどありません。システムの機能はまだわかりません（事前に深刻なテストを実行していない場合）。

いくつかの設定

nginxでのキャッシュ

注文ページを除くすべてのページに3時間500 MBのキャッシュを作成します。

 proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=blackfriday_cache:180m max_size=500m inactive=7d; #  blackfriday_cache,  180  proxy_cache_key "$request_method$scheme$host$request_uri"; proxy_cache_use_stale error timeout invalid_header http_500; map $uri $cookie_nocache { #     ,   ; 1 - , 0 -  "/order" "1"; "/bitrix" "1"; default "0"; } location / { .... proxy_hide_header "Set-Cookie"; #       proxy_ignore_headers "X-Accel-Expires"; proxy_ignore_headers "Expires"; proxy_ignore_headers "Cache-Control"; proxy_ignore_headers "Set-Cookie"; add_header X-Cache $upstream_cache_status; ... proxy_no_cache $cookie_nocache; #  ,   map;  1 -   proxy_cache blackfriday_cache; #    proxy_cache_valid 180m; #  180  proxy_cache_valid 404 1m; # 404  -   1  .... proxy_pass http://backend; #     } location @backend { .... #   }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

追加資料、リンク：

• habr.com/post/124684
• nginx.org/ru/docs/http/ngx_http_proxy_module.html

100メガビットチャネルでは、1秒間に1 MBの重量の12ページを提供できます。これは1時間あたり43千です。 nginxは、安価なサーバー上でもそのようなボリュームを配信できます。

リクエストを複数のノードに分散します（サイトは複数のWebノードで動作する準備ができている必要があります）

ラウンドロビンDNS経由

（ここで注意してください、この方法は多くのDNSプロバイダーによって正しくサポートされなくなりました）

 $ dig lifehacker.ru +short 136.243.37.180 136.243.37.178
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

nginxアップストリーム経由

 $ cat nginx.conf upstream backend { server backend1.yoursite.com; server backend2.yoursite.com; } server { server_name yoursite.com; location / { proxy_pass http://backend; } } location @backend { .... #   }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Cloudflare、Qratorなどを介して

パネルから複数のバックエンドを直接設定する機能があり、通常、設定の更新は即座に行われます。

落ち着いて

完璧な仕事を提供することは不可能ですが、ビジネスの主なことは、システムが基本的に機能することです。 遅くしますが、ユーザーがF5キーを押し続けることなく注文できるようにする必要があります。 「貧弱で、抑制力があり、みんなの神経を分割する」何千人もの顧客が同時にそれを使用しており、彼らは注文を行い、作り、注文し、それぞれが貴重です。 ある日、店が6か月の転換期を迎えた例を見ましたが、結果はすべての神経に値するものでした。



あなたへの成功した販売:)