mcrouter を使用して memcached を水平方向にスケーリングする

どの言語でも高負荷のプロジェクトを開発するには、特別なアプローチと特別なツールの使用が必要ですが、PHP でのアプリケーションに関しては、状況がさらに悪化して、たとえば次のような開発が必要になることがあります。 独自のアプリケーションサーバー。 このノートでは、memcached での分散セッション ストレージとデータ キャッシュに関するよくある問題と、これらの問題を XNUMX つの「ward」プロジェクトでどのように解決したかについて説明します。

今回の主役は symfony 2.3 フレームワークをベースにした PHP アプリケーションですが、これは更新するビジネス計画にはまったく含まれていません。 このプロジェクトでは、非常に標準的なセッション ストレージに加えて、 「すべてをキャッシュする」ポリシー memcached: データベースおよび API サーバーへのリクエストへの応答、さまざまなフラグ、コード実行を同期するためのロックなど。 このような状況では、memcached の故障はアプリケーションの動作にとって致命的になります。 さらに、キャッシュの損失は、DBMS が継ぎ目でバーストし始めたり、API サービスがリクエストを禁止し始めたりするなど、深刻な結果をもたらします。 状況が安定するまでに数十分かかる場合があり、その間はサービスが非常に遅くなるか、完全に利用できなくなる可能性があります。

提供する必要がありました ほとんど労力をかけずにアプリケーションを水平方向にスケーリングできる機能、つまりソースコードへの変更は最小限に抑えられ、完全な機能が維持されます。 キャッシュを障害に耐性のあるものにするだけでなく、キャッシュによるデータ損失を最小限に抑えるようにしてください。

memcached 自体の何が問題なのでしょうか?

一般に、PHP の memcached 拡張機能は、すぐに使える分散データとセッション ストレージをサポートします。 一貫したキー ハッシュのメカニズムにより、多くのサーバーにデータを均等に配置し、グループ内の特定のサーバーに各特定のキーを一意にアドレス指定できます。また、組み込みのフェイルオーバー ツールにより、キャッシュ サービスの高可用性が確保されます (ただし、残念ながら、 データなし).

セッション ストレージを使用すると状況が少し良くなります。構成できるようになります。 memcached.sess_number_of_replicasその結果、データは複数のサーバーに同時に保存され、XNUMX つの memcached インスタンスに障害が発生した場合、データは他のサーバーから転送されます。 ただし、サーバーがデータなしでオンラインに戻った場合 (通常は再起動後に起こります)、一部のキーはサーバーに有利に再配布されます。 実際、これは次のことを意味します セッションデータの損失失敗した場合に別のレプリカに「移動」する方法がないためです。

標準ライブラリツールは主に以下を目的としています。 横型 スケーリング: キャッシュを巨大なサイズに増やし、別のサーバーでホストされているコードからキャッシュにアクセスできるようにします。 ただし、私たちの状況では、保存されるデータの量は数ギガバイトを超えることはなく、XNUMX つまたは XNUMX つのノードのパフォーマンスで十分です。 したがって、有用な標準ツールは、少なくとも XNUMX つのキャッシュ インスタンスを動作状態に維持しながら、memcached の可用性を確保することだけです。 しかし、この機会さえも活用することはできませんでした... ここで、プロジェクトで使用されたフレームワークの古さを思い出してみる価値があります。そのため、アプリケーションをサーバーのプールで動作させることが不可能でした。 セッション データの損失も忘れてはなりません。ユーザーの大量ログアウトに顧客の目がけいれんしたのです。

理想的にはそれが必要でした memcached 内のレコードのレプリケーションとレプリカのバイパス 間違いや間違いがあった場合。 この戦略の実施に協力してくれました マルーター.

マルーター

これは、Facebook の問題を解決するために Facebook が開発した memcached ルーターです。 memcached テキスト プロトコルをサポートしています。 memcached インストールをスケールする 非常識なプロポーションに。 mcrouter の詳細な説明は、次の場所にあります。 この発表。 とりわけ 幅広い機能 必要なことを実行できます。

• レコードを複製する。
• エラーが発生した場合は、グループ内の他のサーバーにフォールバックします。

原因のために！

マルーター設定

すぐに設定に進みます。

{
 "pools": {
   "pool00": {
     "servers": [
       "mc-0.mc:11211",
       "mc-1.mc:11211",
       "mc-2.mc:11211"
   },
   "pool01": {
     "servers": [
       "mc-1.mc:11211",
       "mc-2.mc:11211",
       "mc-0.mc:11211"
   },
   "pool02": {
     "servers": [
       "mc-2.mc:11211",
       "mc-0.mc:11211",
       "mc-1.mc:11211"
 },
 "route": {
   "type": "OperationSelectorRoute",
   "default_policy": "AllMajorityRoute|Pool|pool00",
   "operation_policies": {
     "get": {
       "type": "RandomRoute",
       "children": [
         "MissFailoverRoute|Pool|pool02",
         "MissFailoverRoute|Pool|pool00",
         "MissFailoverRoute|Pool|pool01"
       ]
     }
   }
 }
}

なぜプールが XNUMX つあるのでしょうか? サーバーが繰り返されるのはなぜですか? それがどのように機能するかを見てみましょう。

• この構成では、mcrouter は request コマンドに基づいてリクエストの送信先のパスを選択します。 その男は彼にこう言います OperationSelectorRoute.
• GET リクエストはハンドラーに送られます RandomRoute配列オブジェクト間でプールまたはルートをランダムに選択します children。 この配列の各要素は順番にハンドラーになります。 MissFailoverRouteこれは、データを含む応答を受信するまでプール内の各サーバーを通過し、その応答はクライアントに返されます。
• 独占的に使用した場合 MissFailoverRoute XNUMX つのサーバーのプールがある場合、すべてのリクエストは最初に最初の memcached インスタンスに送信され、残りのインスタンスはデータがないときに残りのリクエストを受信します。 このようなアプローチは、 リストの最初のサーバーに過剰な負荷がかかっています, そこで、異なる順序のアドレスを持つ XNUMX つのプールを生成し、それらをランダムに選択することにしました。
• 他のすべてのリクエスト (これはレコード) は次を使用して処理されます。 AllMajorityRoute。 このハンドラーは、プール内のすべてのサーバーに要求を送信し、少なくとも N/2 + 1 台のサーバーからの応答を待ちます。 使用から AllSyncRoute この方法では、からの肯定的な応答が必要であるため、書き込み操作を中止する必要がありました。 すべて グループ内のサーバー - それ以外の場合は返されます SERVER_ERROR。 mcrouter は利用可能なキャッシュにデータを追加しますが、呼び出した PHP 関数は エラーが返されます そして通知が生成されます。 AllMajorityRoute はそれほど厳密ではなく、ユニットの半分までは上記の問題が発生することなくサービスを停止することができます。

メインマイナス このスキームは、実際にキャッシュにデータがない場合、クライアントからのリクエストごとに memcached への N 個のリクエストが実際に実行されるというものです。 すべて プール内のサーバー。 たとえば、プール内のサーバーの数を XNUMX 台に減らすことができます。ストレージの信頼性が犠牲になります。оリクエストからキーの欠落までの処理速度が向上し、負荷が軽減されます。

NB: mcrouter の学習に役立つリンクも見つかります。 Wiki のドキュメント и プロジェクトの問題 （閉鎖されたものを含む）、さまざまな構成の倉庫全体を表します。

マルーターの構築と実行

私たちのアプリケーション (および memcached 自体) は Kubernetes で実行されます。したがって、mcrouter もそこにあります。 のために コンテナの組み立て を使用しております ワーフ、その構成は次のようになります。

NB: 記事に記載されているリストはリポジトリで公開されています フラント/マルーター.

configVersion: 1
project: mcrouter
deploy:
 namespace: '[[ env ]]'
 helmRelease: '[[ project ]]-[[ env ]]'
---
image: mcrouter
from: ubuntu:16.04
mount:
- from: tmp_dir
 to: /var/lib/apt/lists
- from: build_dir
 to: /var/cache/apt
ansible:
 beforeInstall:
 - name: Install prerequisites
   apt:
     name: [ 'apt-transport-https', 'tzdata', 'locales' ]
     update_cache: yes
 - name: Add mcrouter APT key
   apt_key:
     url: https://facebook.github.io/mcrouter/debrepo/xenial/PUBLIC.KEY
 - name: Add mcrouter Repo
   apt_repository:
     repo: deb https://facebook.github.io/mcrouter/debrepo/xenial xenial contrib
     filename: mcrouter
     update_cache: yes
 - name: Set timezone
   timezone:
     name: "Europe/Moscow"
 - name: Ensure a locale exists
   locale_gen:
     name: en_US.UTF-8
     state: present
 install:
 - name: Install mcrouter
   apt:
     name: [ 'mcrouter' ]

(werf.yaml)

...スケッチしてみます ヘルムチャート。 興味深いのは、レプリカの数に基づいた構成ジェネレーターのみがあることです。 (誰かがもっと簡潔でエレガントなオプションを持っている場合は、コメントで共有してください):

{{- $count := (pluck .Values.global.env .Values.memcached.replicas | first | default .Values.memcached.replicas._default | int) -}}
{{- $pools := dict -}}
{{- $servers := list -}}
{{- /* Заполняем  массив двумя копиями серверов: "0 1 2 0 1 2" */ -}}
{{- range until 2 -}}
 {{- range $i, $_ := until $count -}}
   {{- $servers = append $servers (printf "mc-%d.mc:11211" $i) -}}
 {{- end -}}
{{- end -}}
{{- /* Смещаясь по массиву, получаем N срезов: "[0 1 2] [1 2 0] [2 0 1]" */ -}}
{{- range $i, $_ := until $count -}}
 {{- $pool := dict "servers" (slice $servers $i (add $i $count)) -}}
 {{- $_ := set $pools (printf "MissFailoverRoute|Pool|pool%02d" $i) $pool -}}
{{- end -}}
---
apiVersion: v1
kind: ConfigMap
metadata:
 name: mcrouter
data:
 config.json: |
   {
     "pools": {{- $pools | toJson | replace "MissFailoverRoute|Pool|" "" -}},
     "route": {
       "type": "OperationSelectorRoute",
       "default_policy": "AllMajorityRoute|Pool|pool00",
       "operation_policies": {
         "get": {
           "type": "RandomRoute",
           "children": {{- keys $pools | toJson }}
         }
       }
     }
   }

(10-mcrouter.yaml)

これをテスト環境に展開し、以下を確認します。

# php -a
Interactive mode enabled

php > # Проверяем запись и чтение
php > $m = new Memcached();
php > $m->addServer('mcrouter', 11211);
php > var_dump($m->set('test', 'value'));
bool(true)
php > var_dump($m->get('test'));
string(5) "value"
php > # Работает! Тестируем работу сессий:
php > ini_set('session.save_handler', 'memcached');
php > ini_set('session.save_path', 'mcrouter:11211');
php > var_dump(session_start());
PHP Warning:  Uncaught Error: Failed to create session ID: memcached (path: mcrouter:11211) in php shell code:1
Stack trace:
#0 php shell code(1): session_start()
#1 {main}
  thrown in php shell code on line 1
php > # Не заводится… Попробуем задать session_id:
php > session_id("zzz");
php > var_dump(session_start());
PHP Warning:  session_start(): Cannot send session cookie - headers already sent by (output started at php shell code:1) in php shell code on line 1
PHP Warning:  session_start(): Failed to write session lock: UNKNOWN READ FAILURE in php shell code on line 1
PHP Warning:  session_start(): Failed to write session lock: UNKNOWN READ FAILURE in php shell code on line 1
PHP Warning:  session_start(): Failed to write session lock: UNKNOWN READ FAILURE in php shell code on line 1
PHP Warning:  session_start(): Failed to write session lock: UNKNOWN READ FAILURE in php shell code on line 1
PHP Warning:  session_start(): Failed to write session lock: UNKNOWN READ FAILURE in php shell code on line 1
PHP Warning:  session_start(): Failed to write session lock: UNKNOWN READ FAILURE in php shell code on line 1
PHP Warning:  session_start(): Unable to clear session lock record in php shell code on line 1
PHP Warning:  session_start(): Failed to read session data: memcached (path: mcrouter:11211) in php shell code on line 1
bool(false)
php >

エラーのテキストを検索しても結果は得られませんでしたが、クエリ「マイクロルーターphp「最前線にあったのは、プロジェクトの最も古い未解決の問題でした - サポートの不足 memcached バイナリ プロトコル。

NB: memcached の ASCII プロトコルはバイナリ プロトコルよりも遅く、一貫したキー ハッシュの標準手段はバイナリ プロトコルでのみ機能します。 ただし、これは特定のケースでは問題を引き起こしません。

コツは袋の中にあります。ASCII プロトコルに切り替えるだけですべてが機能します。 ただし、この場合、答えを探す習慣は、 php.net のドキュメント 残酷な冗談を言った。 そこには正しい答えは見つかりません...もちろん最後までスクロールしない限り、セクションのどこにありますか 「ユーザー投稿メモ」 忠実になるだろうし、 不当に反対票を投じられた回答.

はい、正しいオプション名は次のとおりです。 memcached.sess_binary_protocol。 これを無効にする必要があります。無効にすると、セッションが機能し始めます。 残っているのは、mcrouter を備えたコンテナを PHP を備えたポッドに配置することだけです。

まとめ

したがって、インフラストラクチャの変更だけで問題を解決できました。memcached フォールト トレランスの問題が解決され、キャッシュ ストレージの信頼性が向上しました。 アプリケーションにとって明らかな利点に加えて、これによりプラットフォーム上で作業する際に操作の余地が生まれました。すべてのコンポーネントに予備があると、管理者の作業が大幅に簡素化されます。 はい、この方法には欠点もあります。「松葉杖」のように見えるかもしれませんが、お金を節約し、問題を埋め、新たな問題を引き起こさないのであれば、なぜそうしないのでしょうか？

PS

私たちのブログもお読みください:

• 「dappで練習」 (例として symfony-demo を使用): パート 1 (単純なアプリケーションの構築) и パート 2 (Helm を使用して Docker イメージを Kubernetes にデプロイする);
• «Kubernetes との生活から: HTTP サーバーがスペイン人に有利ではなかった理由'。

出所： habr.com