ブラックフライデーとサイバーマンデー：データの準備はできていますか？

ブラックフライデー、サイバーマンデー、さらにはグリーンマンデー（「グリーン」を節約するための最後の月曜日で、クリスマスに最適な出荷日）は、今年のこの時期に確かに大きな話題になります。最も一般的な公開会話のトピックは、お得な情報を探すこと、切望されたホリデーギフトを買うこと、そして消費者が費やす驚異的な金額についてです。

2018年ブラックフライデーの売上レポートによると、オンライン売上は62億ドルで、前年比23.6％増加しました、 サイバーマンデーは2018年の年間最大の販売日であり、オンライン収益は79億ドルで、2017年に比べて19.3％増加しました。

しかし、もう1つの非常に重要な並行会話も現在進行中であり、その1つは、オンラインショッピングの円滑な流れ、クレジットカード番号の安全性、およびオンラインとオンサイトの両方の販売プロセスの不具合を維持するために必要な大規模なテクノロジーとデータ管理の取り組みに関するものです。自由。ほとんどの買い物客はおそらく立ち止まって買い物を可能にするテクノロジーの量や複雑さ、または価格の設定と購入の処理方法について考えることはありませんが、買い物体験の背後にあるデータテクノロジーに生計を依存している私たちにとって、これは最も重要です年間の計画と実施時間。

したがって、あなたが商人であるか、商人をサポートしている場合、またはとにかくeコマースや金融に携わっている場合は、おそらく今は本当に忙しく、携帯電話を常に近くに置いています。今こそ、データベース、サポートインフラストラクチャ、およびアプリケーションを、ショッピングシーズン中に耐えられる可能性のある高負荷に備えて準備するときです。

このブログでは、ブラックフライデーが近づく中で検討したいデータテクノロジースタックの主要な領域のいくつか、準備方法、およびObjectRocketチームがブラックフライデーとサイバーマンデーの準備をするためにどのように協力できるかについて説明します。

データスタックを準備するための一般的な手順

使用するデータベースに関係なく、準備するために実行する必要のあるいくつかの手順があります。これらには、データストアをスムーズに実行し続けるための標準的なベストプラクティスが含まれていますが、ブラックフライデーとサイバーマンデーの準備をする際には特別な緊急性があります。

• 大量のトラフィックに備える ：容量計画、成長予測、データ安定性、高可用性、レプリケーション、フェールオーバークラスターは、増加するトラフィック負荷に耐えるための主要な概念です。準備するときは、次の項目を考慮してください。
  • シャーディングされたクラスターの場合は、シャードを追加して、そのようなピーク時にスペースが不足しないようにすることを検討してください。ここObjectRocketでは、通常、ディスクがいっぱいになったために停止するのを防ぐために、約60％の使用率で大幅な成長が見込まれる顧客を維持したいと考えています。
  • Elasticsearchクラスターバージョン6.x以降では、より小さなプランサイズを使用する場合、急速な成長の可能性、特に読み取り専用ロックを回避するために、ディスクサイズを95％未満に維持します。キャパシティプランニングの際は、各シャードに512MBまで拡張できるトランスログがあり、最大12時間その状態を維持できることを覚えておいてください。
  • 自動スケーリングを使用しない、より小さくシンプルなレプリカセットの場合は、成長予測に基づいて同時実行性と成長性を処理できるプランサイズに移行することを検討してください。
  • トラフィックが増加すると、データベースへの接続要求も増加します。アプリケーションチームのメンバー/顧客に確認して、正しい接続プール設定と正しいOS設定（ ulimits など）が設定されていることを確認します。 、ユーザーのリソース制限を表示および設定できます）。アプリケーションでは、単一のレプリカセットまたは当社が提供する4つのデフォルトのモンゴ（シャードクラスター上の接続をリッスンする特別なノード）よりも多くの接続を開く必要がある場合があります。この場合、お客様と協力して、接続を処理するためにより多くのモンゴを割り当てることがよくあります。
  • oplogのサイズが正しく設定されていることを確認することは、もう1つの注目すべき領域です。 oplogは、すべての作成、読み取り、および削除操作の上限付きコレクション（固定サイズ）であり、そこからセカンダリノードが同期ソースからデータを複製します。セカンダリノードは、同期元のノードのoplogサイズが小さく、特にピーク時に操作に追いつくことができない場合、同期が外れる可能性があります。 oplogが大きいほど、セカンダリノードがダウンした場合でもプライマリノードのアクティビティと同期する時間が長くなります。
• テスト、微調整、さらにテスト ：データベースをテストすればするほど、データベースを知っていることがわかります。これは、顧客が買い物を始めるかなり前に、ストレステストとパフォーマンステストを実行し、変更を適用するときです。
  • 過去の一時的な中断/データ障害、弱点の領域を調べて、強化が必要なものがあるかどうかを判断します（ただし、BFの直前に大きな修正を適用しないでください）。 。
  • 準備期間の早い段階だけでなく、年間を通じて負荷とパフォーマンスのテストを実行し、これらのタイプのテストを継続的インテグレーションプロセスに組み込みます。
  • 可能であれば、テスト環境でトラフィックパターンと負荷の長さをシミュレートします。
• 分析を活用する ：過去数か月にわたって交通流やその他のパタ​​ーンを調べてきた場合は、「通常」のことをよく理解している必要があります。
  • ビッグデータの前に解決できる最適ではないと思われるパフォーマンスまたは入出力の問題を探し始めます。
  • トラフィックパターンを調査します。最も混雑している時間の最大接続数を確認してから、容量を20％増やす計画を立てます。
  • Elasticsearchの場合、CPU使用率/GC時間/クエリ時間を提供するNewRelicなどのサードパーティのメトリックコレクターを使用できます。これらの統計はすべて、ブラックフライデーのビッグウィークの計画に役立ちます。
• 必ず主要な修理やアップグレードを控えてください 大切な日に近すぎます！そして、このモラトリアムをチーム全体に伝えてください。
• セキュリティをもう一度見てください 対策を講じ、それらを知り、理解し、他の人にそれらを説明する能力について準備し、自信を持ってください（必要が生じた場合）。少なくとも、データ侵害の「ソフトターゲット」ではないことを確認してください。
• プライバシー規制 、セキュリティの問題と同様に、ますます重要になっています。 GDPRの方法を検討してください 要件は、販売キャンペーン（および関連するCookie）の使用と、顧客のデータの使用/保存方法に影響を与えます。
• 将来を見据えた継続的な改善 ：ブラックフライデー/サイバーマンデーのたびに回顧会議（retros）を開催して、次回改善できる領域を特定することをお勧めします。

データベース固有の考慮事項

ObjectRocketがサポートするいくつかのデータベースに関するいくつかのプロのヒントを次に示します（または、3つのデータベースすべてを実行します（ポリグロット永続性）！

MongoDBProのヒント

MongoDBは、eコマース用のNoSQLデータベースの中でますます人気が高まっており、速度とスケーラビリティが主な利点です。多くのマーチャントは、MongoDB製品カタログを使用して、製品の提供、価格設定、出荷、および在庫を管理しています。 MongoDBエキスパートからのプロのヒントは次のとおりです。

• レプリカセットの3つのホスト名すべてが、レプリカセットの接続文字列に追加され、シャードクラスターの場合は4つのモンゴすべてが追加されていることを確認します。
• データベースへの不要な接続が多すぎないように、接続プールを使用していることを確認してください。
• トラフィックと読み取り/書き込みがどれだけ増加するか（成長予測）を検討し、MongoDBの自動スケーリング機能を利用します。
• 大規模なショッピングの前と最中の両方で、パフォーマンスの調整（メモリ使用量、接続処理、レプリカセットの状態）を常に把握します。

ElasticsearchProのヒント

Elasticsearchの専門家チームから、ブラックフライデーとサイバーマンデーのデータベースを準備するためのプロのヒントをいくつか集めました。 Elasticsearchは、主にストリーミングログデータの視覚化と分析に使用される場合でも、検索の重要なオンラインショッピング機能（自動完了、ファセット検索、同義語を使用）に使用される場合でも、eコマーステクノロジースタックの重要な部分であることがよくあります。

• ブラックフライデーの2日前に、スナップショットを撮る頻度を増やします。ショッピングの週末を通して1日2〜3回スナップショットを撮り、サイバーマンデーの後に通常のバックアップスケジュールに戻すことをお勧めします。これらのスナップショットを、トラフィックのピーク前に発生し、トラフィックのピーク後に再度発生するようにスケジュールすることをお勧めします。また、選択した時間に別のスナップショットを作成することをお勧めします。 Elasticsearchのバックアップは差分として実行されるため、スナップショットを1日3回実行すると、スナップショットの期間が非常に短くなります。
• 主にログファイルの視覚化にElasticsearchを使用する場合：
  • イベント中のデータ消費量の増加を計画します。
  • Kibanaダッシュボードが、最も重要なログとイベントを分析するための適切な設定で最新であることを確認してください。
  • スパイクや問題を特定できるように、アグリゲーション/ダッシュボードのベースラインを把握してください。一部のユースケースでは、Elastalertとの統合により、さまざまなイベントについてアラートを受け取ることができます。
• 主に検索機能にElasticsearchを使用する場合：
  • これらは読み取りが多い日になる可能性が高いため、次のことを行います。
    • ノード数を増やして、アクティブなスレッドプールを追加します
    • レプリカの数を増やして、読む場所を増やします
• ElasticsearchのツールRallyを使用してベンチマークテストを実行し、現在のElasticsearchクラスターが現在計画されている検索スループットを処理できるかどうかを確認します。
• Elasticsearchログでスローされる可能性のある追加のエラーがないか確認してください。
• すべてのアプリケーションが4つの接続エンドポイントすべてを使用していることを確認してください。
• 現在の遅いクエリを確認し、クエリの分析または改善についてサポートが必要な場合は、ObjectRocketチームに連絡してください。

RedisProのヒント

Redisは通常、非常に一時的なデータに使用されます。これはもちろん、キャッシュ（クエリ、セッション、フルページキャッシュ）を意味します。ブラックフライデーとサイバーマンデーのトラフィックが多い間、キャッシュはアプリケーションのパフォーマンスを最高に保つための鍵となります。 Redisの専門家は、次のヒントを提案しています。

• セッションストアまたはキャッシュとしてRedisを使用している場合、ブラックフライデーのトラフィックが増えるとメモリまたは帯域幅の制限に達する可能性があると思われる場合は、サイズを大きくすることを検討してください。
• 自動的に期限切れになる可能性があり、自動的に期限切れになるはずのキーにTTL（「存続時間」がキーの有効期限を決定します）を設定していることを確認します。
• maxmemory-policyを確認します メモリが不足した場合に備えて、が適切に設定されます。インスタンスでこの設定を変更する必要がある場合は、ObjectRocketサポートに連絡してください。
• 本番インスタンスの場合、トラフィックが急増する前に、メモリの断片化率が正常であることを確認してください。
• ジョブキュー管理フレームワークのバックエンドとしてRedisを使用している場合は、このフレームワークのダッシュボードを用意して確認し、ジョブのステータスを監視することを強くお勧めします。このようなダッシュボードの例としては、resque-web、arena、sideqikがあります。
• 聞こえるかもしれませんが、 flushdb、flushallを実行しないでください。 、またはキャンペーン直前の他の大規模な削除操作。代わりに、SCANおよびDELスクリプトを記述してください。
• COMMANDSTATSログとSLOWLOGログで現在のエントリを確認し、最適化できるパターンを確認して、ブロッキング操作が発生しないようにします。 「キー*」の使用は避けてください 」およびその他の長期にわたる操作。
• 開発インスタンス（本番ではありません！）で、MONITORコマンドからの出力を監視しながらストレステストを実行して、パターンを分析します。
• サンプルデータを含む開発インスタンスでは、 rdb-toolsを使用します 、 redis-cli –bigkeys 、および redis-cli –memkeys データの分散とメモリ使用量を分析します。
• インスタンスの監視を既存の統計プラットフォームに統合するエージェントをセットアップします。例：Datadog、New Relic、Prometheus。

ObjectRocketがあなたと提携するために行うこと

多くの顧客にとって、ホリデーシーズンは年間のビジネス量の大部分を占めています。賭け金が最も高く、稼働時間が最も重要なのはこの期間です。私たちは、お客様がこれらの季節的な交通イベントに備えるのを助けるために多くの仕事をしています。

ObjectRocketチームが行うことのほんの数例を次に示します。

• 遅いクエリ分析 ：最適よりも時間がかかるクエリについてアドバイスを提供できます（たとえば、Elasticsearchでは、1秒より長くかかるクエリは最適ではありません）。
  • 低速クエリのログ記録をクラスターで有効にする必要があります（お客様はこれをリクエストできます）。その後、1日か2日のデータが得られたら、数値を確認します。定義された最適な秒数よりも長くかかったクエリの数を、クエリの最も高価な部分を識別するクエリプロファイラーを介して実行します。その後、お客様と相談し、クエリ時間を短縮する方法についてアドバイスを提供します。
• パフォーマンスの調整：これは、お客様の最適化されていない操作の調整に時間を費やす傾向があるもう1つの領域です。特に、次の点に注意してください。
• • 正規表現クエリが不適切な場合、データベースのクロールが遅くなる可能性があります。正規表現クエリに対して行うことができるいくつかの最適化については、ブログ投稿を参照してください。
  • コレクションスキャンが必要なクエリ。これらの操作は、多くの場合、多くのドキュメントをスキャンして少数しか返さないため、非常にコストがかかる可能性があります（つまり、インデックスを使用しません）。
  • パフォーマンスの低い演算子を使用する操作では、多くのドキュメントとインデックスキーが検査されることが多いため、可能な場合は、 $ ne、$ examples：trueなどの演算子の使用を避けてください。 、$nin。

• インデックス作成：適切なインデックスを設定することは、多くの場合、最も重要なタスクであり、ほとんどのお客様がブラックフライデーを生き延びてきた方法です。インスタンスのプロファイルを作成して、ほとんどの操作に適切なインデックスが設定されていることを確認できます。追加のインデックスが必要な場合は、お客様と協力してインデックスを作成します。
• 負荷テストとスケーリング —要求に応じて、負荷テストを調整して、予想されるトラフィックの増加が発生する前にシミュレートできます。これは、予想される成長とトラフィックの急増の際にアプリケーションのパフォーマンスを最適な状態に保つために不可欠です。
• メンテナンスモラトリアム—この間、お客様は私たちに大きく依存しており、メンテナンスモラトリアムを実装していることを理解するようになりました。これは、インフラストラクチャのメンテナンス作業のソフトフリーズが11月上旬から1月上旬にかけて実施されていることを意味します。この期間中は、綿密な承認プロセスを経た緊急メンテナンスのみが許可されます。
• 24x7x365サポート — ObjectRocketサポートチームは、お客様のニーズを満たすために24時間体制でスタッフを配置しています。 DBAとデータテクノロジーの専門家のチームは、ブラックフライデーとサイバーマンデーの狂気のベテランです。彼らはこの危機的な時期の前、最中、そして後にあなたのためにここにいます！

いつものように、ObjectRocketサポートに連絡する最良の方法は、support@objectrocket.comまでメールでお問い合わせいただくことです。私たちがどのように手助けできるか、そしてハッピーブラックフライデーを教えてください！