10 年以上開発されてきた製品には、時代遅れのテクノロジーが含まれていても、まったく驚くべきことではありません。 しかし、XNUMX か月以内に XNUMX 倍の負荷を維持する必要があり、転倒のコストが何百倍にも増加するとしたらどうなるでしょうか? この場合、優秀なハイロード エンジニアが必要です。 しかし、メイドがいないので、彼らは私に問題の解決を任せました。 記事の前半では、Redis から Redis-cluster に移行するまでの経緯を説明し、後半では、クラスターの使い始め方と使用時の注意点についてアドバイスします。

テクノロジーの選択

そんなに悪いことですか？ 個別の Redis (スタンドアロン redis) 1 つのマスターと N つのスレーブの構成ですか? なぜそれを時代遅れのテクノロジーと呼ぶのでしょうか?

いいえ、Redis はそれほど悪くありません...しかし、無視できない欠点がいくつかあります。

• まず、Redis はマスター障害後の災害復旧メカニズムをサポートしていません。 この問題を解決するために、VIP を新しいマスターに自動転送する構成を使用し、スレーブの XNUMX つの役割を変更し、残りを切り替えました。 このメカニズムは機能しましたが、信頼できる解決策とは言えませんでした。 第一に、誤警報が発生したこと、第二に、それが使い捨てであり、操作後にスプリングを充電するために手動操作が必要であったことです。

• 次に、マスターが 1 つしかないため、シャーディングの問題が発生しました。 「XNUMX つのマスターと N つのスレーブ」という独立したクラスターをいくつか作成し、これらのマシンにデータベースを手動で分散し、明日にはデータベースの XNUMX つが別のインスタンスに移動しなければならないほど膨張しないことを祈る必要がありました。

オプションは何ですか？

• 最も高価で機能豊富なソリューションは Redis-Enterprise です。 これは、完全な技術サポートが提供されるボックス化されたソリューションです。 技術的な観点からは理想的に見えますが、イデオロギー的な理由から私たちには合いませんでした。
• Redis クラスター。 すぐに使えるマスターフェイルオーバーとシャーディングがサポートされています。 インターフェースは通常版とほとんど変わりません。 有望に見えますが、落とし穴については後ほど説明します。
• Tarantool、Memcache、Aerospike など。 これらのツールはすべて、ほぼ同じことを行います。 しかし、それぞれに独自の欠点があります。 私たちはすべての卵を XNUMX つのカゴに入れないことに決めました。 私たちは他のタスクに Memcache と Tarantool を使用していますが、今後のことを考えると、実際にはそれらに関してさらに多くの問題が発生したと言えます。

使用の詳細

Redis を使用してこれまでにどのような問題を解決してきたか、またどのような機能を使用したかを見てみましょう。

• 2GIS などのリモート サービスへのリクエストの前にキャッシュする | ゴラン
  

  GET SET MGET MSET "SELECT DB"

• MYSQL の前にキャッシュ | PHP
  

  GET SET MGET MSET SCAN "パターンによるキー" "DB の選択"

• セッションとドライバー座標を操作するサービスのメイン ストレージ | ゴラン
  

  GET SET MGET MSET "SELECT DB" "ADD GEO KEY" "GET GEO KEY" SCAN

ご覧のとおり、高等数学はありません。 では、何が難しいのでしょうか？ それぞれの方法を個別に見てみましょう。

方法
説明
Redisクラスターの特徴
ソリューション

GET SET
書き込み/読み取りキー

MGET MSET
複数のキーの書き込み/読み取り
キーは別のノード上にあります。 既製のライブラリは XNUMX つのノード内でのみ複数の操作を実行できます
MGET を N GET 操作のパイプラインに置き換えます。

セレクトDB
作業する拠点を選択してください
複数のデータベースをサポートしていません
すべてを XNUMX つのデータベースに入れます。 キーにプレフィックスを追加する

スキャン
データベース内のすべてのキーを調べます
データベースが XNUMX つあるため、クラスター内のすべてのキーを調べるのはコストがかかりすぎます
XNUMX つのキー内で不変式を維持し、このキーに対して HSCAN を実行します。 もしくは完全に拒否するか

ジオ
ジオキーを使用した操作
ジオキーはシャード化されていません

パターンごとのキー
パターンによるキーの検索
データベースが XNUMX つあるため、クラスター内のすべてのキーを検索します。 高すぎる
SCAN の場合のように、不変条件を拒否または維持します。

Redis と Redis クラスター

クラスターに切り替えると何が失われ、何が得られるのでしょうか?

• 欠点: いくつかのデータベースの機能が失われます。
  • 論理的に無関係なデータを XNUMX つのクラスターに保存したい場合は、プレフィックスの形式で松葉杖を作成する必要があります。
  • SCAN、DBSIZE、CLEAR DB などの「基本」操作がすべて失われます。
  • マルチオペレーションは、複数のノードへのアクセスが必要となる場合があるため、実装がはるかに困難になっています。
• 利点：
  • マスターフェイルオーバーの形式でのフォールトトレランス。
  • Redis 側のシャーディング。
  • ダウンタイムなしでノード間でデータをアトミックに転送します。
  • ダウンタイムなしで容量と負荷を追加および再分散します。

高レベルのフォールト トレランスを提供する必要がない場合、クラスタへの移行は簡単ではないタスクになる可能性があるため、その価値はないと私は結論付けています。 ただし、最初に個別のバージョンとクラスター バージョンのどちらかを選択する場合は、クラスターを選択する必要があります。クラスターの方が悪くなく、さらに頭痛の種が軽減されるからです。

移動の準備中

まずは移動の要件から始めましょう。

• シームレスである必要があります。 5分間の完全なサービス停止は私たちには適していません。
• できるだけ安全かつ段階的に行う必要があります。 状況をある程度コントロールしたい。 一度にすべてをダンプして、ロールバック ボタンを祈るようなことはしたくありません。
• 移動時のデータ損失を最小限に抑えます。 アトミックに移動するのは非常に難しいことを理解しているため、通常の Redis とクラスター化された Redis のデータ間のある程度の非同期を許可します。

クラスターのメンテナンス

移動の直前に、クラスターをサポートできるかどうかを検討する必要があります。

• チャート。 Prometheus と Grafana を使用して、CPU 負荷、メモリ使用量、クライアント数、GET、SET、AUTH 操作の数などをグラフ化します。
• 専門知識。 明日、あなたの責任下で巨大なクラスターが発生すると想像してください。 壊れた場合、あなた以外に直すことはできません。 彼がスピードを緩め始めたら、みんながあなたに向かって走ってくるでしょう。 リソースを追加したり、負荷を再分散したりする必要がある場合は、またお問い合わせください。 25歳で白髪にならないように、これらのケースに備え、特定のアクションでテクノロジーがどのように動作するかを事前に確認することをお勧めします。 これについては「専門知識」セクションで詳しく説明します。
• 監視とアラート。 クラスターが発生した場合、誰よりも早くそれを知りたいと考えます。 ここでは、すべてのノードがクラスターの状態に関する同じ情報を返すという通知に限定しました (はい、状況は異なります)。 また、その他の問題は、Redis クライアント サービスからのアラートによってより迅速に気づくことができます。

動く

どのように移動するか:

• まず、クラスターで動作するライブラリを準備する必要があります。 私たちは go-redis を Go バージョンのベースとして採用し、自分たちに合うように少し変更しました。 パイプラインを介してマルチメソッドを実装し、繰り返しリクエストのルールも若干修正しました。 PHP バージョンにはさらに問題がありましたが、最終的には php-redis に落ち着きました。 彼らは最近クラスターのサポートを導入しましたが、私たちの意見ではそれが良いように思えます。
• 次に、クラスター自体をデプロイする必要があります。 これは文字通り、構成ファイルに基づいた XNUMX つのコマンドで実行されます。 設定については後ほど詳しく説明します。
• 徐々に動かす場合はドライモードを使用します。 同じインターフェイスを持つ XNUMX つのバージョンのライブラリ (XNUMX つは通常バージョン用、もう XNUMX つはクラスター用) があるため、別のバージョンで動作し、クラスターへのすべてのリクエストを並行して複製するラッパーを作成するのに費用はかかりません。応答を比較し、不一致をログに書き込みます (この場合は NewRelic)。 したがって、ロールアウト中にクラスターのバージョンが壊れた場合でも、本番環境には影響がありません。
• クラスターをドライ モードで展開すると、応答の不一致のグラフを冷静に見ることができます。 エラー率がゆっくりと、しかし確実に小さな定数に向かって推移する場合は、すべて問題ありません。 なぜ依然として矛盾が存在するのでしょうか? 別のバージョンでの記録はクラスター内よりも少し早く行われるため、マイクロラグにより​​データが発散する可能性があります。 残っているのは、不一致ログを確認することだけであり、それらがすべてレコードの非原子性によって説明される場合は、先に進むことができます。
• これで、乾燥モードを逆方向に切り替えることができます。 クラスターへの書き込みと読み取りを行い、クラスターを別のバージョンに複製します。 何のために？ 来週にかけてクラスターの働きを観察したいと思います。 ピーク負荷時に問題があることが突然判明した場合、または何かを考慮していなかった場合でも、ドライモードのおかげで、常に古いコードと現在のデータに緊急ロールバックできます。
• 残っているのは、ドライモードを無効にして、別のバージョンを解体することだけです。

専門知識

まず、クラスターの設計について簡単に説明します。

まず、Redis はキーと値のストアです。 任意の文字列をキーとして使用します。 数値、文字列、構造全体を値として使用できます。 後者は非常に多くありますが、一般的な構造を理解するためには、これは重要ではありません。
キーの次の抽象化レベルはスロット (SLOTS) です。 各キーは 16 スロットの 383 つに属します。 各スロット内には任意の数のキーを含めることができます。 したがって、すべてのキーは 16 の素のセットに分割されます。

次に、クラスター内に N 個のマスター ノードが存在する必要があります。 各ノードは、クラスター内の他のノードに関するすべてを認識する個別の Redis インスタンスとして考えることができます。 各マスター ノードには多数のスロットが含まれています。 各スロットは XNUMX つのマスター ノードにのみ属します。 すべてのスロットはノード間で分散する必要があります。 一部のスロットが割り当てられていない場合、スロットに保存されているキーにアクセスできなくなります。 各マスター ノードを個別の論理マシンまたは物理マシンで実行するのが合理的です。 また、各ノードは XNUMX つのコア上でのみ実行されること、および同じ論理マシン上で複数の Redis インスタンスを実行する場合は、それらが異なるコア上で実行されることを確認してください (これは試していませんが、理論的には動作するはずです)。 。 基本的に、マスター ノードは定期的なシャーディングを提供し、マスター ノードを増やすことで書き込みおよび読み取りリクエストを拡張できるようになります。

すべてのキーがスロットに分散され、スロットがマスター ノードに分散された後、任意の数のスレーブ ノードを各マスター ノードに追加できます。 このような各マスター/スレーブ リンク内では、通常のレプリケーションが機能します。 スレーブは、読み取りリクエストをスケールしたり、マスター障害が発生した場合のフェイルオーバーのために必要です。

次に、できるようになったほうがよい操作について説明します。

Redis-CLI 経由でシステムにアクセスします。 Redis には単一のエントリ ポイントがないため、どのノードでも次の操作を実行できます。 それぞれの時点で、負荷がかかった状態で操作を実行できる可能性に個別に注意を向けます。

• 最初に必要な最も重要なことは、クラスター ノードの操作です。 クラスターの状態を返し、ノードのリスト、その役割、スロットの分布などを表示します。 クラスター情報とクラスター スロットを使用すると、さらに詳しい情報を取得できます。
• ノードの追加と削除ができると便利です。 この目的のために、クラスターのミート操作とクラスターの忘却操作があります。 クラスターの削除は、マスターとレプリカの両方のすべてのノードに適用する必要があることに注意してください。 また、クラスター会議は XNUMX つのノード上でのみ呼び出す必要があります。 この違いは混乱を招く可能性があるため、クラスターを実際に使用する前に、この違いについて理解しておくことをお勧めします。 ノードの追加は戦闘中に安全に行われ、クラスターの動作にはまったく影響しません (これは論理的です)。 クラスターからノードを削除する場合は、そのノードにスロットが残っていないことを確認する必要があります (そうしないと、このノード上のすべてのキーにアクセスできなくなる危険があります)。 また、スレーブを持つマスターを削除しないでください。削除すると、新しいマスターに対する不必要な投票が実行されます。 ノードにスロットがなくなった場合、これは小さな問題ですが、最初にスレーブを削除できるのに、なぜ追加の選択肢が必要になるのでしょうか。
• マスターとスレーブの位置を強制的に交換する必要がある場合は、クラスター フェールオーバー コマンドを使用します。 戦闘中に呼び出す場合、操作中はマスターが使用できないことを理解する必要があります。 通常、切り替えは XNUMX 秒以内に発生しますが、アトミックではありません。 この間、マスターへの一部のリクエストが失敗することが予想されます。
• クラスタからノードを削除する前に、そのノードにスロットが残っていないようにしてください。 これらは、cluster reshard コマンドを使用して再配布することをお勧めします。 スロットはあるマスターから別のマスターに転送されます。 転送されるデータの量によっては、操作全体に数分かかる場合がありますが、転送プロセスは安全であり、クラスターの操作にはまったく影響しません。 したがって、可用性を気にすることなく、負荷がかかっている状態ですべてのデータをあるノードから別のノードに直接転送できます。 ただし、微妙な点もあります。 まず、データ転送には受信ノードと送信ノードに一定の負荷が伴います。 受信ノードがすでにプロセッサーに高負荷になっている場合は、新しいデータを受信することでノードをロードしないでください。 第 XNUMX に、送信側マスターにスロットが XNUMX つも残らなくなると、そのすべてのスレーブは直ちにこれらのスロットが転送されたマスターに移動します。 そして問題は、これらすべてのスレーブが一度にデータを同期しようとすることです。 完全な同期ではなく、部分的な同期であれば幸運です。 これを考慮して、スロットの転送とスレーブの無効化/転送の操作を組み合わせてください。 あるいは、十分な安全マージンがあることを願っています。
• 転送中に、どこかでスロットを紛失したことに気付いた場合はどうすればよいでしょうか? この問題が影響しないことを願っていますが、影響がある場合は、クラスターの修正操作が行われます。 少なくとも、スロットをランダムな順序でノード全体に分散します。 最初に分散スロットを持つノードをクラスターから削除して、その動作を確認することをお勧めします。 未割り当てのスロット内のデータはすでに利用できないため、これらのスロットの可用性に関する問題を心配しても手遅れです。 また、この操作は分散スロットには影響しません。
• もう XNUMX つの便利な操作はモニターです。 これにより、ノードに送信されるリクエストのリスト全体をリアルタイムで確認できます。 さらに、grep して必要なトラフィックがあるかどうかを確認することもできます。

マスターフェイルオーバー手順についても言及する価値があります。 つまり、それは存在しており、私の意見では、それはうまく機能します。 ただし、マスター ノードを備えたマシンの電源コードを抜いても、Redis はすぐに切り替わり、クライアントは損失に気付かないとは考えないでください。 私の実践では、切り替えは数秒で起こります。 この間、一部のデータは利用できなくなります。マスターが利用できないことが検出され、ノードが新しいノードに投票し、スレーブが切り替えられ、データが同期されます。 この計画が機能していることを自分自身で確認する最善の方法は、現地で演習を行うことです。 ラップトップ上のクラスターを起動し、最小限の負荷を与え、クラッシュをシミュレートし (ポートをブロックするなどして)、スイッチング速度を評価します。 私の意見では、この方法で XNUMX ～ XNUMX 日プレイして初めて、テクノロジーの操作に自信が持てるようになります。 まあ、インターネットの半分が使用しているソフトウェアがおそらく機能することを願っています。

設定

多くの場合、ツールの使用を開始するために最初に必要なのは構成であり、すべてが機能するようになると、構成には触れたくなくなります。 強制的に設定に戻って慎重に検討するには、ある程度の努力が必要です。 私の記憶では、構成に不注意が原因で少なくとも XNUMX 回重大な障害が発生しました。 次の点に特に注意してください。

• タイムアウト0
  非アクティブな接続が閉じられるまでの時間 (秒単位)。 0 - 閉じない
  私たちのすべてのライブラリが接続を正しく閉じることができたわけではありません。 この設定を無効にすると、クライアント数の制限に達する危険があります。 一方、そのような問題があった場合、失われた接続の自動終了によって問題が隠蔽され、気付かない可能性があります。 また、永続的な接続を使用する場合は、この設定を有効にしないでください。
• xy を保存して追加のみ はい
  RDBスナップショットを保存します。
  RDB/AOF の問題については、以下で詳しく説明します。
• stop-writes-on-bgsave-error いいえ & スレーブサーブ-古いデータ はい
  有効にすると、RDB スナップショットが破損すると、マスターは変更リクエストの受け入れを停止します。 マスターへの接続が失われた場合でも、スレーブはリクエストに応答し続けることができます (はい)。 または応答を停止します (いいえ)
  私たちは、Redis がカボチャに変わってしまう状況に満足していません。
• repl-ping-スレーブ-期間 5
  この時間が経過すると、マスターが故障し、フェイルオーバー手順を実行する時期が来たのではないかと心配し始めます。
  誤検知とフェイルオーバーのトリガーとの間のバランスを手動で見つける必要があります。 私たちの実践では、これは 5 秒です。
• repl-backlog-size 1024mb & epl-backlog-ttl 0
  障害が発生したレプリカのバッファーには、ちょうどこれだけの量のデータを保存できます。 バッファが不足した場合は、完全に同期する必要があります。
  実際には、より高い値を設定する方がよいことがわかります。 レプリカが遅延し始める理由はたくさんあります。 遅れている場合は、マスターがすでに対応に苦戦している可能性が高く、完全な同期は最後の手段になります。
• 最大クライアント 10000
  ワンタイムクライアントの最大数。
  私たちの経験では、より高い値を設定することをお勧めします。 Redis は 10 個の接続を問題なく処理します。 システムに十分なソケットがあることを確認してください。
• maxmemory-policy volatile-ttl
  使用可能なメモリ制限に達したときにキーが削除されるルール。
  ここで重要なのは、ルールそのものではなく、これがどのように起こるかを理解することです。 Redis は、メモリ制限に達した場合でも正常に動作する機能を賞賛できます。

RDB と AOF の問題

Redis 自体はすべての情報を RAM に保存しますが、データをディスクに保存するメカニズムもあります。 より正確には、次の XNUMX つのメカニズムがあります。

• RDB スナップショット - すべてのデータの完全なスナップショット。 SAVE XY 構成を使用して設定し、「少なくとも Y キーが変更された場合、X 秒ごとにすべてのデータの完全なスナップショットを保存する」と表示されます。
• 追加専用ファイル - 実行された順序での操作のリスト。 X 秒ごと、または Y 操作ごとに、新しい受信操作をファイルに追加します。
• RDB と AOF は、前の XNUMX つを組み合わせたものです。

すべての方法には長所と短所がありますが、すべてを列挙するつもりはありません。私の意見では、明白ではない点に注意を払うだけです。

まず、RDB スナップショットを保存するには、FORK を呼び出す必要があります。 大量のデータがある場合、すべての Redis が数ミリ秒から 8 秒間ハングする可能性があります。 さらに、システムはそのようなスナップショットにメモリを割り当てる必要があるため、論理マシン上で 16 倍の RAM を確保する必要があります。Redis に XNUMX GB が割り当てられている場合、仮想マシンでは XNUMX GB が利用可能である必要があります。それ。

次に、部分的な同期には問題があります。 AOF モードでは、スレーブが再接続されたときに、部分同期の代わりに完全同期を実行できます。 なぜこんなことが起こるのか、私には理解できませんでした。 しかし、これは覚えておく価値があります。

これら XNUMX つの点は、すべてがすでにスレーブによって複製されている場合、ディスク上にこのデータが本当に必要かどうかを考えるきっかけになります。 データが失われる可能性があるのは、すべてのスレーブに障害が発生した場合のみであり、これは「DC での火災」レベルの問題です。 妥協策として、データをスレーブにのみ保存することを提案できますが、この場合、これらのスレーブが災害復旧中に決してマスターにならないようにする必要があります (このため、構成にはスレーブの優先順位設定があります)。 私たち自身も、具体的なケースごとに、データをディスクに保存する必要があるかどうかを考えますが、ほとんどの場合、答えは「いいえ」です。

まとめ

結論として、redis-cluster についてまったく聞いたことのない人に redis-cluster がどのように機能するかについての一般的なアイデアを与えることができ、また、redis-cluster を使用している人にはいくつかの不明瞭な点にも注意を向けることができれば幸いです。長い間。
お時間をいただきありがとうございます。いつものように、このトピックに関するコメントは大歓迎です。

出所： habr.com