高負荷下のクラウドサービス。 カックル体験

みなさんこんにちは！ Cackleは、2011年からWebサイト向けのクラウドSaaSソリューションを開発しています。 当社の製品は10,000以上のサイトにインストールされており、毎日平均6500万のユニークヒットを処理しています。 ピーク時の帯域幅は780メガビット/秒に達し、データベースは1日あたり最大1億2000万件の読み取り要求と最大30万件の書き込み要求を受信します。 このようなワークロードは、私たちが共有したい難しいソリューションを発明することを困難にします。









最初に、私たちが一般的に開発したもの、すべての技術とアーキテクチャが基づいているもの、高負荷の原因について少し説明します。 さらに-この負荷に対処するために適用する5つの基本的な決定。

コメントシステム

Cackle Commentsは、2011年に発表された最初の製品です。



匿名、ソーシャル、サイトとの統合など、便利な承認によりコメントのプロセスを簡素化します。 検索エンジンでのインデックス作成、ソーシャルネットワーク（VK、マイワールド、Facebook、Twitter）の壁へのコメントのブロードキャスト、新しいコメントと回答の購読により、より多くのトラフィックを集めることができます。 サイトからの独立性による負荷を軽減します。

オンラインストアのフィードバックシステム

Cackle Reviewsは2013年にリリースされたレビューシステムです。 主にオンラインストアで使用されていますが、どのサイトでも問題なく動作します。



主な機能：

• Yandex.Marketからレビューをダウンロードします。
• 「すぐに使える」マイクロマーキング（ 検索結果でのランキング ）によるGoogleのインデックス作成。
• 購入後にフィードバックを残すために招待状を送信するフォローアップ。
• 便利な匿名、ソーシャル、単一の承認;
• ソーシャルネットワークでのレビューのブロードキャスト：VK、My World、Facebook、Twitter。
• レビューのリアルタイムモデレーション。
• レビューに関するコメント。
• スパム保護。
• CMSプラグイン： 1C-Bitrix 、 Joomla（K2、Virtuemart、Zoo） 、 OpenCart 、 PrestaShop

オンラインコンサルタント

Cackle Live Chat - 2013年にリリースされたサイト訪問者向けのオンラインチャット 。



機能のうち、クイックインストール、操作パネルはブラウザに実装されているため、デスクトップクライアントのインストールに時間を浪費する必要はありません。 オペレーターがクライアントに関する情報（名前、写真、電子メール、プロファイルへのリンク）を受信して​​いる間のユーザーの社会的承認。

調査ウィジェット

Cackle Polls-同じく 2013年にリリースされた、ソーシャルネットワーク、IPまたはCookieを介して投票する機能を持つ投票。



調査はGoogleによって自動的にインデックス化され、追加のトラフィックを集めます。 画像をアップロードできます。YouTubeおよびVimeoのビデオ認識があります。

テクノロジー

Cackleの理解におけるフロントエンドはJavaScriptです。 バックエンドはデータおよびロジックサーバーです。

フロントエンド

フロントエンドはウィジェットで構成されています。 ウィジェットは、他の共有JavaScriptライブラリに基づく実行可能なJavaScriptライブラリです。 共有ライブラリの例：

• DOMを操作するためのライブラリ：jQueryは非常に遅く、いくつかのモバイルプラットフォームでは動作しなかったため、彼らはVanilla JSでソリューションを作成しました。 その結果、一部の操作では、速度が600倍に増加しました。このソリューションは、AndroidおよびiOSのすべてのバージョンで機能します。
• 統合認証ライブラリ（匿名、ソーシャル、SSO）;
• 対話プロトコル（WebSocket、EventSource、Long-Polling）をスマートに選択できるリアルタイムモードサポートライブラリ。
• クロスドメインGET / POSTリクエストライブラリ。
• その他：日付、ブラウザデータベース（cookie、localstorage）、json、画像の読み込み、ビデオ認識（YouTube、Vimeo）、通知トレイ、ページネーションなどを操作します。

すべてのウィジェットはiframeなしで機能します。これにより、CSSをWebサイトのスタイルに合わせて変更できます。



RequireJSに似た、より単純な汎用ウィジェットローダー（widget.js）があります。 ブートローダーには、develとprodの2つの操作モードがあります。 最初は開発中に使用され、ライブラリをループでロードします。 2番目の実動では、アセンブルされたバンドル（バンドル）をロードします。 prodモードでは、ウィジェットはランダムに選択されたさまざまなサーバーからダウンロードされ、その結果、バランスが取れます（これについては後で説明します）。

バックエンド

これは、Nginxサーバーの外側にラップされたApache Tomcatコンテナーのクラスターです。 この場合のNginxはプロキシとしてだけでなく、負荷の「シンク」としても機能します。 複数のスレーブへのストリーミングレプリケーションを備えたPostgreSQLデータベース。



すべてのバックエンドは、ロシアとヨーロッパの複数のデータセンター（DPC）に分散されています。 私たちの経験では、すべてのサーバーを1つのデータセンターでホストするのは危険すぎるため、3つの異なるデータセンターに接続しています。

リアルタイム

ブラウザ側でのリアルタイム更新（コメント、いいね、編集、モデレーション、プライベートメッセージ、チャット）のサポートは、サポートされているテクノロジーのいずれかを通じて行われます：WebSocket、EventSource、Long-Polling。 つまり、最初にWebSocketがあるかどうかを確認し、次にEventSource、Long-Pollingを確認します。 切断（エラー）の場​​合、通信はsetTimeoutで接続ステータスを監視する機能によって自動的に復元されます。



サーバーでは、Nginxクラスター+ プッシュストリームモジュールを使用します。 サーバーは3台のみです。2台は共有、1台はオンラインコンサルタント用です。 バックエンド（Tomcat-s）からのリアルタイムメッセージは、すべてのサーバーに送信されます。 また、ブラウザでウィジェットから接続すると、任意のサーバーが（ランダムに）選択されます。 その結果、バランスのようなものが得られます（残念ながら、プッシュストリームはそのまま使用できるバランスをサポートしていません）。



さらに、次のものがあります。

• サーバーの画像の読み込み、処理、保存。
• SMTPサーバー。

建築

PG-PostgreSQL。

RT-リアルタイム。

DPC（1,2、...、N）-さまざまなデータセンター。

RMI-リモートメソッド呼び出し用のJavaテクノロジ（ ウィキペディア ）。



理解を深めるため、ウィジェットのロードシーケンス図は次のとおりです。

負荷

以下は、ウィジェットおよびAPI呼び出しに関する統計の要約です。



1日あたりのユニークヒット数：6,000〜7000万

ピークリクエスト/秒：2700

同時リアルタイムセッションのピーク：300,000

ピーク帯域幅：780 Mbps

1日あたりのトラフィック：1.6 TB

Nginx日次要約ログ：102 GB



データベースへのリクエストの読み取り（1日あたり）：80〜120百万

記録のためのデータベースへのリクエスト（1日あたり）：300,000



登録サイトの数：32,558

登録ユーザー数：8 220 681

投稿されたコメント：23,840,847

1日の平均コメント増加率：50,000

毎日の平均ユーザー成長：15,000

問題

高負荷は2つの問題を引き起こします。



まず、ほとんどすべてのホスティング事業者は、デフォルトで100 Mbpsのサーバー帯域幅を持っています。 上記のすべてが削減されるか、せいぜい追加の帯域を購入するように求められます（価格はサーバー自体のコストよりも数倍高くなります）。



2番目の問題は負荷そのものです。 物理学を欺くことはできません。サーバーがどれほどクールであっても、サーバーには独自の制限があります。

»ソリューション1：JavaScriptでのバランス調整

負荷分散の標準的な方法は、サーバー上の入力要求の分散について説明します。 これにより2番目の問題は解決されますが、最初の（帯域幅）は解決されません。発信トラフィックは同じサーバーを通過するためです。



2つの問題を同時に解決するために、ローダー自体（widget.js）でJavaScriptのバランスをとり、バックエンドをランダムに選択します。 その結果、サーバーウィジェットのクラスターからサーバーにトラフィックをリダイレクトし、それらの間で帯域幅を分割し、負荷を分散します。



この方法のもう1つの大きな利点は、JavaScriptキャッシュです。 ページが更新されると、すべてのライブラリ（widget.jsローダーを含む）がブラウザーキャッシュから受信され、サーバーは新しいリクエストを静かに処理し続けます。

ローダーコードの継続（widget.jsパート2）：

 var Cackle = Cackle || {}; Cackle.protocol = ('https:' == window.location.protocol) ? 'https:' : 'http:'; Cackle.host = Cackle.host || 'cackle.me'; Cackle.origin = Cackle.protocol + '//' + Cackle.host; //   (a.cackle.me, b.cackle.me, c.cackle.me): Cackle.cluster = ['a.' + Cackle.host, 'b.' + Cackle.host, 'c.' + Cackle.host]; //  , .  widget.js  1 Cackle.getRandInt = function(min, max) { return Math.floor(Math.random() * (max - min + 1)) + min; } Cackle.getRandHost = function() { return Cackle.cluster[Cackle.getRandInt(0, Cackle.cluster.length - 1)]; }; Cackle.initHosts = function() { //getRandHost     var host = Cackle.getRandHost(); for (var i = 0; i < cackle_widget.length; i++) { cackle_widget[i].host = Cackle.protocol + '//' + host; } }; //cackle_widget -      , //      (  ). //: cackle_widget.push({widget: 'Comment', id: 1}); Cackle.main = function() { Cackle.initHosts(); for (var i = 0; i < cackle_widget.length; i++) { var widget = cackle_widget[i].widget; if (!Cackle.Bootstrap[widget].isLoaded) { Cackle.Bootstrap[widget].load(cackle_widget[i].host); } } }; Cackle.main();
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

プロのCDNはどうですか？

これはすごい！ 唯一の問題は、CDNを使用するには、現在の売上高を維持しながら、価格を少なくとも3倍上げる必要があることです。

»ソリューション2：Nginx Microcache

マイクロキャッシュは、非常に短い寿命（たとえば3秒）のキャッシュです。 毎秒何千もの同一のGET要求が送信されるピーク負荷時に非常に便利です。 私たちにとって、これはJSON形式のウィジェットデータです。 メインバックエンド（Tomcat）を保護するためにNginxなどのプロキシサーバーでマイクロキャッシングを行うことは理にかなっています。



マイクロキャッシュを使用したNginx構成の一部：

 ... location /bootstrap { try_files $uri @proxy; } ... location @proxy { # (Tomcat) proxy_pass http://localhost:8888; proxy_redirect off; #      Nginx , # -   ,        proxy_ignore_headers X-Accel-Expires Expires Cache-Control; set $no_cache ""; #  GET|HEAD if ($request_method !~ ^(GET|HEAD)$) { set $no_cache "1"; } if ($no_cache = "1") { add_header Set-Cookie "_mcnc=1; Max-Age=2; Path=/"; add_header X-Microcachable "0"; } if ($http_cookie ~* "_mcnc") { set $no_cache "1"; } proxy_cache microcache; proxy_no_cache $no_cache; proxy_cache_bypass $no_cache; proxy_cache_key $scheme$host$request_method$request_uri; #  3  proxy_cache_valid 200 301 302 3s; proxy_cache_use_stale error timeout http_500 http_502 http_503 http_504 http_403 http_404 updating; default_type application/json; } ...
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この設定の理解に問題がある場合は、 ngx_http_proxy_moduleを読む必要があります。

»ソリューション3：Tomcat、Javaキャッシュの調整

Tomcat

特にTomcat Tomcatでは動作しません。 実務経験から：

• コネクタ（Http11Protocol、Nio、4月）の選択にだまされないでください。 負荷が高い場合、これは役割を果たしません。
• connectionTimeoutをできるだけ小さく、できれば5秒以内にしてください。
• maxThreadsを大きくしすぎないでください。助けにはならず、状況によっては大きな害を及ぼすだけです。 ロードされたプロジェクトの標準は300〜350です。 これで十分でない場合は、新しいTomcatサーバーを追加します。
• ただし、acceptCountは数千（2000〜4000）にすることができます。 値が低いと、接続が切断され（接続が拒否されます）、キューに追加されます。 同時に、OSで同じまたはそれ以上のバックログを設定することを忘れないでください。

Javaキャッシュ

一般に、負荷の高いプロジェクトのデータベースは弱点であると受け入れられています。 本当にそうです。 たとえば、サーバーは要求を受け入れ、サービスレベルに送信します。サービスレベルでは、サービスがデータベースにアクセスして結果を返します。 この場合のリンク「サービス-データベース（リレーショナル）」はすべての中で最も遅いため、サービスをキャッシュでラップするのが一般的です。 したがって、データベースからの結果はサービスキャッシュに入れられ、次にキャッシュから取得されます。



キャッシングサービスについては、独自のキャッシュを開発しました。これは、標準のキャッシュ（Ehcacheなど）の動作が遅く、特定のタスクを必ずしもうまく解決できないためです。 特定のタスクのうち、単一の値に対して複数のキーをサポートするキャッシングです。 org.apache.commons.collections.map.MultiKeyMapを使用します。



これはどのタスクに必要です。 たとえば、ユーザーはコメント付きのページにアクセスします。 たくさんのコメントを言ってみましょう、300個。 それらはそれぞれ3ページ（ページネーション）に分割され、それぞれ100ページです。 最初の呼び出しで、最初のページがキャッシュされ（100コメント）、ユーザーが下にスクロールすると、2ページと3ページが順番にキャッシュされます。 ユーザーがこのページにコメントを公開したら、3つのキャッシュをすべてリセットする必要があります。 MultiKeyMapを使用すると、次のようになります。

 MultiKeyMap cache = MultiKeyMap.decorate(new LRUMap(capacity)); cache.put(chanId, "page1", commentSerivce.list(chanId, 1)); //chanId - id    cache.put(chanId, "page2", commentSerivce.list(chanId, 2)); //commentSerivce.list -     (chanId)   (2) cache.put(chanId, "page3", commentSerivce.list(chanId, 3)); cache.removeAll(chanId); //  3      
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

以下は、高負荷で正常に動作するキャッシュコアコードです。

»ソリューション4：さまざまなデータセンターへのレプリケーションをストリーミングするPostgreSQL

私たちの意見では、PostgreSQLは負荷の高いプロジェクトに最適なソリューションです。 今ではNoSQLを使用するのが流行していますが、ほとんどの場合、適切なアプローチと適切なアーキテクチャを備えているため、PostgreSQLの方が優れています。



PostgreSQLでは、ストリーミングレプリケーションは非常にうまく機能し、同じサブネット上でも、異なるネットワーク上でも、異なるデータセンターでも問題になりません。 たとえば、いくつかの国にデータベースサーバーがあり、深刻な問題はありませんでした。 唯一の注意点は、リリースの大規模なベース変更（ALTER TABLE）です。 一度にすべてのUPDATEを実行しないように、断片的に作成する必要があります。



複製を設定するための多くのリソースがありますが、これはハックされたトピックなので、追加する特別なものはありません：

• フェイルオーバー（マスターのクラッシュ）の場合は必ず計画（構成）を作成し、実際にテストしてください。
• WALの原理を理解してください。スレーブとマスターが同期していない場合、アーカイブが必要な理由とアーカイブの場所を知る必要があります。
• ウィザードのHDD上の場所を追跡します。突然消えると、PostgreSQLがクラッシュする可能性があり、レプリケーションでは大きなトラブルが発生します。

»ソリューション5：OSのチューニング

OSのカーネルパラメーターを調整することを忘れないでください。これがないと、NginxまたはTomcatの一部の設定が単に機能しません。



たとえば、どこにでもDebianがあります。 OSのカーネル設定（/etc/sysctl.conf）では、特に次のことに注意する必要があります。

 kernel.shmmax = 8000234752 //   PostgreSQL,      shared_buffers (6 - 8GB) fs.file-max = 99999999 //   Nginx,     "Too many open files" net.ipv4.tcp_max_syn_backlog=524288 //       net.ipv4.tcp_max_orphans=262144 //       TCP net.core.somaxconn=65535 //     net.ipv4.tcp_mem=1572864 1835008 2097152 //     TCP net.ipv4.tcp_rmem=4096 16384 16777216 //     TCP net.ipv4.tcp_wmem=4096 32768 16777216 //  ,      TCP
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

まだ解決されていない問題

むしろ、1つの問題はデータベースのサイズです。 もちろん、シャーディングはありますが、パフォーマンスを低下させないPostgreSQLの標準的なソリューションはまだ見つかりません。 誰かが実際の経験を共有できる場合-ようこそ！



ご清聴ありがとうございました。 私たちのシステムに関する質問や提案は大歓迎です！