ブラックフライデーのためにオンラインストアインフラストラクチャを準備する10の明らかなステップ

クラウドネイティブ分野のマイクロサービス、 Kubernetesなどについて書くことを好むという事実にもかかわらず、私たちは別の世界をよく知っています。たとえば、オンラインストア（非常に成功したものでも）を「まとめて」見れば、より現実的です。 自動プロビジョニングとスケーリング、複雑な負荷分散、その他の美しい技術ソリューションはありません。 しかし、すでに明日である「ブラックフライデー」があります。つまり、準備の時間はほとんどありません。 もちろん、品質の準備のための私たちのレシピNo. 1（そして同時に多くの追加の利点を得るため）は、マイクロサービスアーキテクチャとKubernetesへの移行ですが、何らかの理由でこのオプションが機能しないと仮定します（明日まではまだ実装されません） ）



この記事は、高負荷に備えてオンラインストアの典型的なインフラストラクチャ（nginx、Apache、PHP、MySQLの例を検討）を最適化するための多かれ少なかれ迅速な手順のリストです。 これらは経験豊富なシステム管理者には非常に明白ですが、これらの問題にまだ深く突入していない人にとっては確かに有用であり、その関連性は急速に高まっています。 そのため、インフラストラクチャにあるものを最大限に活用するか、少なくとも次の負荷が集中する前に対処する必要がある主要な問題に注意してください。

1.インフラストラクチャを破壊し、監視を設定する

基本的な負荷インジケータ （CPU、メモリ、ディスクI / O、インターネットチャネル占有率など）を追跡する手段がなければ、最適化アクションはほとんど「盲目的に」実行されます。



主要なサービス（Webサーバー、DBMS、補助サービス）が個別のサーバー/仮想マシンに分割されていない場合、インフラストラクチャ全体が1つの耐え難いモノリスであると思われる場合、対応する再編成から開始する必要があります。 これにより、収集された統計がより視覚的かつ有用になります。異なる仮想マシンのメイングラフを切り替えると、どのインフラストラクチャコンポーネントにプロセッサまたはメモリが不足しているかが明らかになります。



注 ：このような区別の追加の利点の例は、DBMSのリソースが使い果たされると、サイトに完全にアクセスできなくなること （Webサーバーがまったく応答しない場合）ではなく、情報エラー（または最小限の機能スタブ-詳細については以下を参照）につながることです。 ただし、これを行うには、アプリケーション/ WebサーバーとDBMSとの相互作用を正しく構成する必要があります。DBMSへの接続とデータの受信が長すぎてはいけません。 そうしないと、Webサーバーの（予想される）多くの「ハング」プロセスが発生し（場合によっては、そのプロセスの最大数を超えて）、対応するサーバー/ VMのリソースが詰まります。

主要なシステムインジケータの統計および監視のための明白で準備の整った（展開が迅速で、十分に文書化された）オープンソースソリューション（少なくともリソースの不足について迅速に調べる必要がある） -Zabbix 他のすべての製品と同様に、それは理想的ではなく、多くの選択肢（たとえば、）がありますが、解決されるタスクに完全に適合します（そして、おそらく、事実上標準として強化されたと言えるでしょう） 。







もちろん、一般的なシステムインジケーターのグラフに加えて、良い方法で、ビジネスにとってより有益な値を構成すると便利です（処理された要求の数から動的コンテンツ、注文数まで）。



別の方法として、既製のサービスがあります。これはインストールと使用がより簡単で便利ですが、料金を支払う必要があります（例はロシアで開発中のokmeterです） 。



選択したシステムによって収集された主要な値を監視するには、キーストアのアクセス可能性 （Webサーバーの正しい応答と妥当な応答時間）の追跡を追加して、販売が低下するまでオンラインストアの機能の問題を見つけることが役立ちます。 前述のZabbixでは、そのような機能はもちろん提供されています。

2.負荷を確認する

監視および統計システムの実装の論理的な結果は、その「戦闘チェック」、つまり ストレステスト。 これらの目的のために、多くのオープンソースツールもあります：古典的で最も単純なabからApache JMeterのようなより複雑なソリューションまで（それらのいくつかの簡単な概要です ） 。 最も簡単で迅速なテストのために、前述のabユーティリティに頼ることができます。より普遍的で包括的なツールとして、ロシアの開発-Yandex.Tankをお勧めします（作成者の使用例を参照） 。



理想的には、オンラインストアビジネスにとって本当に重要なすべてのものをテストする必要があります。メインページ、カタログセクション、製品の表示、注文（ユーザー登録あり）などです。 単一のページ（たとえば、メインページ）をテストすると、グローバルな問題（一般的に使用されるSQLクエリ、または動的なページレンダリングが原則的に機能しなくなるほど負荷が高いという事実）を特定するのに役立ちますが、SQLクエリに関連するより頻繁な問題を非表示にします特定のテーブル（または特定の要求のみ）、コードで追加のメカニズムとサービスを使用する（たとえば、ユーザーへの電子メールの送信、サードパーティのサービス/キャッシュからのデータの受信など）



前の段階で構成された統計/監視システムは、負荷テストの実行にも役立ちます。 リソース消費のグラフを見て（そしてこれらのデータに基づいて、最大トラフィックのインフラストラクチャの可能性を評価する）、状況が重大になったときに監視がトリガーされることを確認できます。



次の手順の関連性は、ストレステストの結果に大きく依存します。

3.静力学に対処する

突然すべてのリクエストが条件付きApacheによって処理された場合（実際にはこれが実際に発生することを示しています）、軽量のWebサーバーを（フロントエンドとして）追加します-たとえば、もちろんnginx-静的コンテンツ（画像、JS、 CSS、フォントファイル、動画など）。



すべてがすでに設定されていると思われる場合でも、アプリケーションWebサーバー（Apache）のアクセスログを表示して確認してください。 原則として、成功したステータス（404ではない）のGETリクエストを選択し、動的コンテンツ（たとえば、 /



または.html



で終わる、または最後でなく）で受信したURLを遮断するgrep



またはegrep



を使用した簡単な構成が十分にあります- \.[^.]{2,4}



ようなもの）。 多くの場合、 すべてのnginxがすべてのstaticを解放するわけではありませんが、これらはApacheの絶えず実行されているプロセス（ MaxClients



制限に近づいている）と消費される追加リソースです。



統計のもう1つのニュアンスは、サイトのインターネットチャネルの規模でのボリュームです。 この指標は、統計（ネットワークトラフィックのグラフ）のデータを使用して確認されます。 既存のチャネルの予想される（高い）負荷ですべての統計を返すのに十分である場合でも、少なくともオンラインストアのキーページで画像ファイルを最適化し、JS / CSSファイルを最小化することをお勧めします 。 Google PageSpeed Insightsは、これらの問題やその他の「クライアント」問題の検出/確認に役立ちます。



大量のトラフィックが発生し、チャネルを拡張できない場合（または面倒で高価な場合）、CDNを導入するオプションを検討する価値があります。

4.ボトルネックを見つける

Webアプリケーション自体の操作における問題領域に対処する時間。 ここでの簡単な方法は、 New Relicにトライアルアカウントを登録し（2週間無料で発行）、Webサーバー側にエージェント部分をインストールし、負荷データの初期収集（このプロセスは負荷テストを実行することで加速できます。 ）およびその分析。



最も遅いトランザクション（特に最も一般的なトランザクション）に注意してください。







それらの中で具体的に遅くなるものは何ですか（他の部分よりもはるかに時間がかかります）？ これらが特定のコードである場合、どのように最適化できますか？ SQLクエリの場合、DBMSを使用します（段落6を参照） 。 外部サービスの場合-使用を最小限に抑え、可能な場合は結果をキャッシュします（アプリケーションコードでユーザーリクエストを直接使用するか、サービスから必要なデータを定期的に受信してローカルに保存する追加スクリプトを使用してcronを呼び出します）。

5. Webサーバーを最適化する

PHPのアクセラレータなどの補助ツールは、コードの全体的なパフォーマンスを向上させることができます。その原則は、アプリケーションの実行可能ファイルのコンパイル済みコード（オペコード/バイトコード）をキャッシュすることです。 古いPHP（5.x）の場合、 APCはまだ関係があり（公式には「デッド」と認識されていますが）、より新しいバージョン（7.x）の場合は組み込みのZend OPcacheも設定する必要があります。



PHPの場合のグローバル最適化のもう1つの領域は、 セッションです。 それでも、多くは標準設定session.save_handler = files



使用します。つまり、セッションをファイルに保存します。 多数のサイト訪問者（セッションとファイルの両方を意味します）を使用すると、ディスクに不合理な負荷がかかります。これは、memcachedなどのNoSQLストレージに切り替えることで奇跡的に削除され、すべてのセッションがRAMに配置されます。



Webサーバーの動作を最適化する最も根本的な方法は、プログラミング言語のインタープリターによって生成されたページをn分に1回キャッシュすることです。 この機能は、次のようなページに関連します。1）少なくともしばらくは変更できません（たとえば、「ランダムな商品」のブロックは、すべてのユーザーに対して1〜2分間に1回エンジンによって生成されます）、2）すべてに対して同じですユーザー。 2番目の条件は、認証されたユーザーを単に除外するようにキャッシュを構成できるという意味でそれほど重要ではありません。 この場合、完成した（キャッシュされた）ページがすべての訪問者に表示されます-「ゲスト」（さらに、ほとんどの場合、通常は圧倒的です）、認証されたページの場合、「動的」ページが生成されます。 キャッシュはnginxで設定できますが、これらのニーズにより特化したオープンソースソリューションであるVarnish HTTP Cacheもあります。



Webサイト上のページのメイングループのキャッシュを適切に構成すると、リクエストの主要な部分に対する答えが静的（Webサーバー（プログラミング言語のインタープリターを使用）およびDBMS）を使用せずにRAMからデータを発行することになるため、素晴らしい結果が得られることがよくあります。 キャッシングサーバーをセットアップした後、負荷テストの助けを借りてこれを確認しますが、オンラインストアの重要な機能（バスケットへの製品の追加、その後の注文、ユーザー登録など）が中断しないように、キャッシング条件の準備に特に注意してください。

6. DBMSを最適化する

DBMSのパフォーマンスの最適化は、2つの部分に分けることができます。1）DBMS自体の一般的な構成、2）独自のスキーマとクエリでの作業。



最初の項目には、DBMSでのバッファおよびその他のグローバルパラメータの設定が含まれます 。 MySQLにとって最も重要なものは、Peter Zaitsev （CEO Percona）のプレゼンテーションからのこの素晴らしいスライドで見ることができます。







これらのシステム変数およびその他のいくつかの詳細な分析（MySQL / MariaDBのパフォーマンスの問題にとって重要）は、たとえばMariaDBのこのノートに記載されています。



2番目の領域であるデータベーススキーマと使用されるSQLクエリは、通常、スロークエリ （MySQLのスロークエリログ ）または前述のNew Relicなどのパフォーマンスの問題を検出するための専用ツールの分析から始まります 。 問題の大部分は、原則として、SQLクエリの正しいインデックスと思慮深い分析（その後の最適化またはスキーマの変更を含む）を追加することで解決されます。



DBMSから抜け出すのにまだ時間がかかるデータをすばやく取得するための追加のソリューションは、NoSQLストレージなどの頻繁な/複雑な操作の結果をキャッシュすることです 。 他の場合と同様に、キャッシュ内のデータの関連性を監視することを忘れてはなりません。

7.エンジンを最適化する

オンラインストアが一般的なフレームワークまたはエンジンを使用している場合、これは、製造元またはユーザー/マニアのコミュニティとドキュメントを持っていることを意味することに注意してください。 ソリューションを最適化するためのオンラインベストプラクティスを見つけて、可能な限り実装します。 このようなプラクティスで提案されるヒントは、通常、エンジン/アプリケーションの調整や既成のツール（パフォーマンスパネル、プラグインの最適化など）の使用からインフラストラクチャの変更まで、さまざまな分野をカバーしています。



エンジンがサーバーまたはDBMSに顕著な負荷をかける2次機能を使用している場合は、ピーク時にオフにします。ユーザーが何も取得しないで、いくつかの機能を取得できるようにします。

8.アイロンを更新する

統計システムのデータ、負荷テストの結果、継続的な最適化（たとえば、DBMSの問題を分析した後、巨大なバッファーが必要であることが判明しました）-リソースの追加：CPUコアの数とRAMの量を増やし、ディスク集中型パーティション（DBMS）を変換します）SSDで、個々のコンポーネントを個別のサーバー/仮想マシンに移動し、チャネルを拡張します（問題は静的なものだけではないため、CDNが高価な場合や役に立たない場合）。

9.有能なスタブを作成する

他のすべてが失敗した場合（すべての最適化が完了しなかった、または十分ではなかった、十分なハードウェアアップグレードオプションがない、トラフィックの量が妥当な予想を超えた）-基本的な製品、連絡先の詳細を含む有益なプラグインをユーザーに表示するデータなど Webサーバーの設定に書き込み、場合によっては、アプリケーションでの復帰を提供します（タイムアウトやその他の問題の場合）。



もちろん、これは、静的として表示される可能性のある認証されていないユーザーのキャッシュページよりもはるかに悪いですが、接続できないことや多くの人への悲しいおなじみのエラーに関するブラウザメッセージよりもはるかに優れています：

10.専門家に電話する

これらすべてを何らかの理由で定性的に実装できない場合（または希望どおりに役に立たない場合）、問題の技術的な側面を超える機会を忘れないでください-必要な事項についてより有能な人（友人/知人または関連分野に特化した企業。 これは、より効果的なビジネスソリューションになる場合があります。

まとめ

いくつかの特定の技術的指示がありますが、この記事は概要であり、ブラックフライデーと同様のイベント。 ちなみに、特定された問題のいくつかについては、 RIT ++ 2017の一部として開催されたHighload Junior 2017会議で詳細に話しました（Andrei PolovovとAndrei Kolashtovによる「 インフラストラクチャの高負荷を妨げるトップエラー 」を報告）。



これらのヒントの少なくとも一部が、今後のテストに合格するのに役立つことを願っています。 人気のある知恵が言うように、「前もって警告されている」。 また、別の知恵では、「夏にそりを準備する」ことを推奨しています。今週の金曜日でなければ、正月とクリスマスセールの期間中、間違いなく適切に準備する時間をとることができます。



あなたは明日を待ちます！ すべてのあなたに最高、良い販売！

PS

ブログもご覧ください。

• 「 2018年ワールドカップの高負荷 。」