Redisはメインリポジトリですか？ なんてこった！

Redisは、キャッシュや同様のネットワークアプリケーションアクセラレーションメカニズムに一般的に使用されるメモリベースのキーと値のストレージです。 それにもかかわらず、すべてのデータをRedisに保存します-メインデータベースに保存します。



ネットワークには、同様のアプローチに関する警告と注意書きがたくさんあります。 データの損失、メモリ不足、またはRedisでデータを効率的に管理できない人々についての恐ろしい話があります。「あなたは何を考えていますか？」 したがって、私たちの話は、なぜRedisを使用することに決めたのか、そしてこれらすべての問題をどのように克服したのかということです。



まず第一に、ほとんどのアプリケーションはこの方法で使用するために使用される松葉杖に注意を払う必要がないことを強調したいと思います。 これはユースケースにとって重要でしたが、境界ケースになることもあります。

データウェアハウスとしてのRedis

Redisは高速です。 高速とは、大文字Bの高速を意味します。これは基本的に、単なる文字列値よりも複雑なデータ型でmemcachedされます。 セットの交差、zset範囲の選択などの一部の高度な操作でも、驚くほど高速です。 アクティブにリクエストされたデータを急速に変更するためにRedisを使用する理由はすべてあります。 多くの場合、キャッシュとして使用され、バックアップデータベースのデータに従って再構築できます。 これは強力なmemcachedの代替品であり、保存するさまざまなタイプのデータに対してより高度なキャッシュを提供します。



memcachedと同様に、すべてがメモリ内にあります。 Redisはディスクに保存されますが、書き込み方法と同期してデータを保存することはありません。 メインリポジトリとしてのRedisが悪い理由は2つあります。

-すべてのデータをメモリに収める必要があり、...

-サーバーがディスクとの2つの同期の間に失敗すると、メモリ内にあったすべてのものが失われます。



これら2つの問題により、Redisは、メインデータウェアハウスではなく、犠牲にできるデータの一時キャッシュとしてコンパクトなニッチに収まりました。 頻繁に必要なデータへの迅速なアクセスを提供し、必要に応じて再構築する機能。



Redisの背後にある従来のリポジトリを使用することのマイナス面は、パフォーマンスのボトルネックです。 データをディスクに保存するには、パフォーマンスを犠牲にする必要があります。 ほとんどすべてのアプリケーションで完全に通常のバーゲン。 優れた読み取りパフォーマンスと「優れた」書き込みパフォーマンスを得ることができます。 私にとって「良い」ことは、ほとんどの人にとって非常に速い可能性が高いことを明確にしなければなりません。 最も負荷の高いアプリケーションを除いて、「良好な」記録パフォーマンスは過半数を2倍にすると言うだけで十分です。



Redisへの書き込み要求を実行し、リレーショナルストレージを使用して保存できると考えていますが、Redisがクラッシュしたり、書き込みキューのデータが失われたりするという同じリスクが残ります。

何が必要ですか？

Mootは完全に無料の製品として提供されます。 したがって、非常に少量の鉄で大きな負荷を処理できる必要があります。 1か月に数百万人のユーザーにサービスを提供するフォーラムに多数の大規模なデータベースが必要な場合、無料のサービスを継続する方法はありません。 Mootを無料で無制限にしたいので、限界まで最適化する必要がありました。



無料サービスにいくつかの制限を設定し、ページや投稿の閲覧にお金をかけることで、これを避けることができます。 私はあなたのことは知りませんが、一般的に、「あなたがそれを手に入れるまで」無料の製品は好きではありません。 フォーラムを設定すると、サイト上の何かがバイラルになります。 突然、無料レベルを超えた請求書に驚かれることでしょう。 そして、陰謀論についてのあなたのブログの突然の人気のために、娯楽として始まったものは、法案の恐怖に変わります。 あなたはあなたの成功に対して罰せられています。 これは避けたいものです。



また、広告を掲載して収益を上げることもでき、運用コストを高くすることができます。 しかし、これはビジネスとしての中核的な価値観とは完全に対立しています。 私たちの意見では、誰かがあなたのサイトに広告を出す場合、それはあなたではなく私たちである必要があります。 Mootは、条件、制限、追加なしで提供する必要があります。



上記のすべてを考慮すると、エンジニアリングの難しさに関係なく、投稿と読み取りの卓越したパフォーマンスを達成する必要があります。 これが私たちの仕事の基礎です。 高い負荷がかかっていても、大きな複雑なリストや検索が処理される場合でも、すべてのAPI呼び出しを10ミリ秒未満で処理するという当初の目標がありました。 明らかに、Redisはそのようなパフォーマンスを提供できますが、2つの大きな問題は解消されていません。

今何をする？

したがって、これらの制限を考慮して、設計方法の研究を開始しました。 当初から、Mootのタスクと企業としての私たちの価値がどのようなものになるかを正確に理解していたため、コードの最初の行を書く前にこれらの機能について考えることができたのは幸運でした。 多くの既成のコードを使用してこのルートに進むことにした場合、これらの問題は非常に複雑になると思います。

メモリ内のすべてのデータ。 くそー

これは、2つの問題の中で最も難しいものです。 もちろん、1台のコンピューターに搭載できるメモリの量。 EC2の最大数は244ギガバイトのサーバーです。 これはまだ最終的なボリュームですが、これは最初からかなり良い制限です。 残念ながら、これにより、16コアサーバーはRedisに対して1つのコアのみを使用します。 さて、Redisの下位プロセスを各コアに追加するのはどうですか？ その後、各インスタンスに15 GBのメモリが残ります。 再びでたらめ！ これは、サーバーの電源を絞ることができる場合の悪い制限です。 これは、ホスティングサービスに十分なデータではありません。



Redisリポジトリは、最初から多くのRedisクラスターに分割して設計することにしました。 データをハッシュし、このデータセグメントに関連するすべての構造を含むブロックに分割します。 データは最初から強く分割されており、必要に応じて新しいブロックをすばやく簡単に作成できます。



データを分割するために、次のようにハッシュテーブルとアドレステーブルを保存します。

  shards.map = hash：{
                 「シャードハッシュ」：[シャードID]
             }
 
シャード[シャードID] =ハッシュ：{
                 master：[マスターIP /ポート]、
                 slave0：[スレーブ0 ip /ポート]、
                 slave1：[スレーブ0 ip /ポート]、
                 ...
             }
 
 shards.list = zset：{
                断片1：[重量]、
                 shard2：[重量]、
                 ...
             }

データが到着したら、データ接続要件に基づいてハッシュを計算し、shards.mapでブロックに割り当てられているかどうかを確認します。割り当てられている場合は、そのブロックに呼び出しを送信できます。



ハッシュがまだブロックに割り当てられていない場合、利用可能なブロックのリストを作成します。重みに応じてブロックを乗算します。 たとえば、次を実行する場合：

 redis.call（ 'zadd'、 'shards.list'、1、 'shard1'）
 redis.call（ 'zadd'、 'shards.list'、2、 'shard2'）
 redis.call（ 'zadd'、 'shards.list'、1、 'shard3'）

リストは次のようになります。

 [shard1、shard2、shard2、shard3]

その後、リストからランダムブロックを割り当て、分布マップに保存して続行します。



このようなスキームを適用すると、ブロックに入力するデータの量を簡単に制御したり、新しいブロックを追加したり、ブロックがいっぱいになった場合にブロックを考慮から除外したりできます。



実際、何百ものブロックから始めたので、サーバーの負荷とメモリの制限について心配する必要はありません。

個々のブロックは非常に小さいままです。 1台のサーバーにはRedisデータベースに多くのブロックが含まれており、これらのブロックのサイズが大きくなった場合、Redisデータベースを簡単に独立したインスタンスに分割できます。 100個のブロックを持つRedisインスタンスがあり、いくつかのブロックのサイズが大きくなっていることがわかり、Redisをそれぞれ50ブロックの2つのインスタンスに分割するとします。 重みを微調整して、ブロック間のリアルタイム分散を維持できます。



最も難しいのは、データをセグメント化する方法を正確に決定することです。 これは非常に具体的であり、セグメンテーションのバージョンであり、おそらく別の投稿のトピックです。



このようなストレージ戦略は、最初からアプリケーションで開発する必要があります。 多くの場合、人々はそのように設計されていないデータを共有しようとします。それがRedisを使用するためのキャッチです。 メモリ制限が問題になることは明らかであるため、少なくとも1行のコードを記述する前であっても、データ管理システムの中核でソリューションを設計することができました。

サーバーがクラッシュする

途方もなく、失敗に対処する方が簡単であることが判明しました。 Redisクラスターには3つの異なる役割がありました。

-マスター、ほぼすべての録音操作が行われた、

-部下、ほぼすべての測定値が発生した場所、

-データを保存するために割り当てられたキーパー。



マスターと従属は一般に、Redisクラスター内の他のすべてと同様に機能します。 これについては何も興味深いことはありません。 新しいことは、各クラスターにカストディアンとして使用される2つのサーバーがあることです。 これらのサーバー：

-単純なレプリケーションを除いて、着信接続を受け入れず、Redisリクエストの負荷を一切行いません

-2番目のモードでのAOFの保存

-RDBの1時間ごとのスナップショット

-S3でAOFとRDBを同期する



ストレージのパフォーマンスパラメータはわずかに異なる場合があるため、1人のサーバーガーディアンが異なる数のブロックを処理できます。 保存する必要があるブロックごとに1つのインスタンスを実行するだけです。 つまり、ブロックとガードロールを持つサーバーとの間に1対1の関係は必要ありません。



これらのサーバーのうち2つは異なるアクセシビリティゾーンに配置されているため、ゾーンの1つに障害が発生しても、実際に機能するサーバーキーパーが存在します。



したがって、データを失うためには、EC2でかなり大きな障害が必要になりますが、それでもデータが失われるのは約1秒だけです。



ネットワーク接続違反のシナリオを検討している場合、マスターを部下から分離できる場合、部下のレプリケーションをチェックすることで中和できます（任意のキーを任意の値に設定し、部下からのデータが更新されるかどうかをチェックします）マスターが分離された場合、記録を停止します：一貫性と抵抗可用性による接続の損失。 Redis Sentinelもこれを支援してくれますが、Sentinelはシステムのほとんどを実装した後にリリースされました。 Sentinelがどのように方程式に適合するかについては調査しませんでした。

最終結果

最終的に、負荷がかかった状態で約2ミリ秒でAPI呼び出しを行うシステムを構築することができました。



2ミリ秒の値は、最も重いAPI呼び出しである初期化API呼び出しを処理する場合です。

リクエストの多くははるかに高速に処理されます（たとえば、多くの場合0.6〜0.7ミリ秒で処理されます）。 1つのAPIサーバーで1秒あたり1000個のAPIリクエストを実行できます。 また、ページを作成するには、1回のAPI呼び出しが必要です。 すべてのデータチェック、ブロック管理、認証、セッション管理、接続管理、JSONシリアル化などが計測に含まれています。



このような負荷で作業できるAPIサーバーは月額わずか90ドルであるため、非常に低コストで非常に大きな負荷をサポートおよびスケーリングできます。 大きく分割されたデータのもう1つの利点は、水平スケーリングが簡単なことです。



この多くは、Redisのこれらのソリューションだけではありません。 システムが高い並列負荷の下で生産的に動作するためのいくつかのトリックがあります。 倫理的なトリックの1つは、コードのほぼ半分がLuaで記述され、Redisで直接動作することです。 これは、一般的にしないと言われている別のことです。 何千行ものLuaコードがある方法と理由については、Redisの使用に関する次の投稿をお待ちください。



私たちの実際のパフォーマンスを見てみましょう。数日前に始めました。 1秒あたり50回のAPIコールを処理し、メインAPIサーバーのプロセッサ（すべてのトラフィックを1つに送信します）は完全にアイドル状態でした。 以下は、ローンチから投稿の執筆までのグラフです。

負荷のピーク時には、すべてが静かです。 修正プログラムをリリースしたときに、いくつかのバーストが発生する場合がありますが、それ以外の場合は音がしません。 その後の発生は、システムの更新、パッチ、およびその他の進行中のシステム作業に対応します。 総負荷には、初期ベータテスト中に実施したロギングのオーバーヘッドの増加も含まれます。

説明：アプリケーションサーバーとRedisサーバーは同一であるため、APIサーバーを測定対象と呼びます。 APIサーバーには、アプリケーションだけでなくいくつかのブロックが含まれています。 その考えは、Unixソケットを使用してRedisに接続するために、このブロックが主に配置されているサーバーにトラフィックをルーティングすることでした。 これにより、過剰なネットワークトラフィックが回避されるため、アプリケーションサーバー、Redisマスター、Redisスレーブの間に特に違いはありません。 APIサーバーはすべてのリクエストを処理できますが、関連するデータセグメントのマスターサーバーにはるかに高い優先順位を与えるだけです。 すべてのサーバーはアプリケーションサーバーであり、すべてのサーバーは一部のブロックのマスターであり、他のブロックの下位です。



tl; dr

ハードドライブのメインストレージとしてRedisを使用しない理由は数多くありますが、何らかの理由でユースケースでこれが必要な場合は、最初から開始する必要があります。 データを個別に設計し、専用ストレージサーバーの追加コストを覚えておく必要があります。



修正

別のサーバーのコストを計算し、リザーブドインスタンスの償却された1回限りのコストを追加するのを忘れたことがわかりました。 213ドルである必要があります。