心配をやめて一枚岩なしで生活を始める方法

私たちは皆、物語が大好きです。私たちは火のそばに座って、過去の勝利、戦い、または単に私たちの仕事の経験について話すのが好きです。



今日はそんな日です。そして、あなたが今火事になっていないとしても、私たちはあなたのために物語を持っています。 Tarantoolでストレージを使い始めた経緯。



昔々、私たちの会社にはいくつかの「モノリス」と1つの「天井」があり、これらのモノリスはゆっくりとしかし確実に近づき、私たちの会社の飛行、私たちの開発を制限していました。そして、明確な理解がありました。いつの日か、私たちはこの上限にぶつかるでしょう。



今では、機器からビジネスロジックに至るまで、すべてのものとすべての人を分割するというイデオロギーに支配されています。その結果、たとえば、ネットワークレベルで実質的に独立した2つのDCがあります。そして、すべてが完全に異なっていました。



今日、CI / CD、K8Sなどの形式で変更を加えるためのツールやツールがたくさんあります。 「モノリシック」の時代には、それほど多くの外国語は必要ありませんでした。データベースの「ストレージ」を修正するだけで十分でした。



しかし、時が経ち、リクエストの数も増え、時には私たちの能力を超えてRPSが発生しました。 CIS諸国の市場への参入により、最初のモノリスのデータベースプロセッサの負荷は90％を下回らず、RPSは2400のレベルにとどまりました。これらは単なる小さなセレクターではなく、多くのチェックとJOINを伴う大量のリクエストでした。大規模なIOのバックグラウンドに関するデータの半分。



ブラックフライデーの本格的な販売がステージに登場し始め、ワイルドベリーがロシアで最初の1つを保持し始めたとき、状況は完全に悲しくなりました。結局のところ、そのような日の負荷は3倍になります。

ああ、これらの「モノリシック時代」！あなたは似たようなことに遭遇したと確信していますが、それでもこれがどのように起こるのか理解できません。



あなたにできること-ファッションはテクノロジーに内在しています。5年前、これらのmodの1つを、.NETおよびMS SQLサーバー上の既存のサイトの形式で再考する必要がありました。これにより、サイト自体のすべてのロジックが慎重に保持されました。彼はそれを非常に注意深く保管したので、そのような一枚岩を見るのは長くて非常に難しい喜びであることがわかりました。

小さな逸脱。



いろいろなイベントで、「モノリスを見なかったら、成長しなかった！」と言います。この件についてのあなたの意見に興味があります。コメントに書いてください。

雷の音

「焚き火」に戻りましょう。 「モノリシック」機能の負荷を分散するために、システムをオープンソーステクノロジーに基づくマイクロサービスに分割することにしました。なぜなら、少なくとも、スケーリングが安価だからです。そして、私たちが（そして多くの）スケーリングしなければならないという理解は100％でした。確かに、その時すでに近隣諸国の市場に参入することが判明し、登録数と注文数はさらに増加し​​始めました。



マイクロサービスにモノリスを残した最初の申請者を分析したところ、80％で、99％がバックオフィスシステムから書き込み、フロントエンドシステムから読み取っていることに気付きました。まず第一に、これは私たちにとっていくつかの重要なサブシステムに関係していました-ユーザーデータと追加の顧客割引とクーポンに関する情報に基づいて商品の最終コストを計算するためのシステム。



インデント。今では想像するのが怖いですが、前述のサブシステムに加えて、製品カタログ、ユーザーバスケット、製品検索システム、製品カタログのフィルタリングシステム、およびさまざまな推奨システムもモノリスから削除されました。それらのそれぞれの操作のために、狭く鋭利なシステムの別々のクラスがありますが、かつてそれらはすべて1つの「小さな家」に住んでいました。



クライアントに関するデータをシャードシステムに転送することを計画しました。商品の最終コストを計算する機能を削除するには、RPSの負荷が最大になり、データベースへの実装が最も困難であったため、読み取りのスケーラビリティが必要でした（計算プロセスには多くのデータが含まれます）。



その結果、Tarantoolでうまく機能するスキームができました。



当時、マイクロサービスの運用には、仮想マシンとハードウェアマシン上の複数のデータセンターを操作するスキームが選択されていました。図に示すように、Tarantoolレプリケーションオプションは、マスター-マスターモードとマスター-スレーブモードの両方で適用されました。





建築。オプション1.ユーザーサービス



現在、24個のシャードがあり、各シャードには2つのインスタンス（各DCに1つ）があり、すべてマスターマスターモードになっています。



データベースの上には、データベースのレプリカにアクセスするアプリケーションがあります。アプリケーションは、TarantoolGoドライバーインターフェイスを実装するカスタムライブラリを介してTarantoolと連携します。彼女はすべてのレプリカを確認し、マスターと協力して読み取りと書き込みを行うことができます。実際、レプリカセットモデルを実装しており、レプリカの選択、再試行の実行、回路ブレーカー、およびレート制限のロジックが追加されています。



同時に、シャードのコンテキストでレプリカを選択するポリシーを構成することもできます。たとえば、ラウンドロビン。





建築。オプション2.商品の最終コストを計算するサービス



数か月前、商品の最終コストを計算するためのリクエストのほとんどは、原則としてデータベースなしで機能する新しいサービスに送られましたが、しばらく前は、内部でTarantoolを使用するサービスによって100％処理されました。



サービスデータベースは、シンクロナイザーがデータを収集する4つのマスターであり、これらの各レプリケーションマスターはデータを読み取り専用レプリカに配布します。各マスターには約15のそのような行があります。



最初のスキームと2番目のスキームの両方で、1つのDCが使用できない場合、アプリケーションは2番目のスキームでデータを受信できます。



Tarantoolでのレプリケーションは非常に柔軟で、実行時に構成可能であることに注意してください。他のシステムでは、問題がありました。たとえば、PostgreSQLでmax_wal_sendersパラメータとmax_replication_slotsパラメータを変更するには、ウィザードを再起動する必要があります。これにより、アプリケーションとDBMSが切断される場合があります。

探して、あなたは見つけるでしょう！

なぜ私たちは「普通の人のように」それをしなかったのに、非典型的な方法を選んだのですか？それは何が正常と見なされるかに依存します。多くの人々は一般的にモンゴからクラスターを作り、それを3つの地理的に分散したDCに広げます。



当時、Redisにはすでに2つのプロジェクトがありました。 1つ目はキャッシュで、2つ目はそれほど重要ではないデータ用の永続ストレージです。私たちのせいもあって、彼にとっては非常に困難でした。時にはかなりの量が鍵になり、時々サイトは気分が悪くなりました。このシステムはマスタースレーブバージョンで使用しました。そして、マスターに何かが起こって複製が壊れた場合が多かった。



つまり、Redisはステートレスなタスクに適していますが、ステートフルなタスクには適していません。原則として、ほとんどの問題を解決することができましたが、これらが1対のインデックスを使用したキー値ソリューションである場合に限ります。しかし、当時、Redisは永続性と複製にかなり悲しかった。また、パフォーマンスについての苦情もありました。



MySQLとPostgreSQLについて考えます。しかし、最初のものはどういうわけか私たちに根付いていませんでした、そして2番目のものはそれ自体かなり洗練された製品であり、それに単純なサービスを構築することは不適切でしょう。

RIAK、Cassandra、さらにはグラフデータベースも試してみました。これらはすべて、サービスを作成するための一般的なユニバーサルツールの役割に適合しなかった非常にニッチなソリューションです。



最終的に、私たちはTarantoolに落ち着きました。



彼がバージョン1.6のときに、私たちは彼に連絡を取りました。キー値の共生とリレーショナルデータベースの機能に興味がありました。セカンダリインデックス、トランザクション、スペースがあり、それらはテーブルのようなものですが、単純ではありません。それらに異なる数の列を格納できます。しかし、Tarantoolのキラー機能は、キー値とトランザクションを組み合わせたセカンダリインデックスでした。



応答性の高いロシア語を話すコミュニティも役割を果たし、チャットを支援する準備ができました。私たちはこれを積極的に使用し、直接チャットに参加しました。そして、明らかな失敗やわき柱のないまともな永続性を忘れないでください。Tarantoolでの履歴を見ると、レプリケーションで多くの苦労と障害が発生しましたが、彼の障害が原因でデータが失われることはありませんでした。

実装は一生懸命始まりました

当時、私たちの主な開発スタックは.NETでしたが、Tarantoolのコネクタはありませんでした。私たちはすぐにGoで何かを始めました。ルアもかなりうまくいきました。当時の主な問題はデバッグでした。.NETではすべてがこれでゴージャスになり、その後、ログ以外にデバッグがない場合、埋め込みLuaの世界に飛び込むのは困難でした。また、何らかの理由で定期的に複製が崩れてしまったので、タランツールエンジンの構造を調べなければなりませんでした。チャットはこれを助けましたが、それほどではありませんでした-ドキュメントは時々コードを見ました。当時、ドキュメントはまあまあでした。



そのため、数か月以内に、Tarantoolを使用してコーンを埋め、適切な結果を得ることができました。新しいマイクロサービスの形成に役立つgitのリファレンス開発を形式化しました。たとえば、別のマイクロサービスを作成するというタスクが発生したとき、開発者はリポジトリ内の参照ソリューションのソースコードを調べ、新しいマイクロサービスを作成するのに1週間もかかりませんでした。



これらは特別な時間でした。従来は、次の表の管理者に行って、「仮想マシンをください」と尋ねることができました。30分後、あなたはすでに車を持っていました。あなた自身が接続し、すべてをインストールし、それにトラフィックを取得しました。



今日では、そのようには機能しません。監視を終了し、サービスにログオンし、機能をテストでカバーし、仮想マシンを注文するか、Kuberに配信する必要があります。一般的には、長くて面倒ですが、より良いでしょう。

分裂とルール。ルアはどうですか？

深刻なジレンマがありました。一部のチームは、多くのLuaロジックを使用してサービスの変更を確実に展開できませんでした。これはしばしばサービスの操作不能を伴っていました。



つまり、開発者はある種の変更を準備しています。Tarantoolは移行を開始しますが、レプリカにはまだ古いコードが含まれています。いくつかのDDL、何か他のものが複製によってそこに到着し、それが考慮されていないため、コードはただバラバラになります。その結果、管理者向けの更新手順がシートA4でスケジュールされました。複製を停止し、更新し、複製を有効にし、ここでオフにして、そこで更新します。悪夢！



その結果、今ではほとんどの場合、ルアでは何もしないようにしています。 iproto（サーバーと通信するためのバイナリプロトコル）を使用するだけで、それだけです。これは開発者の知識不足かもしれませんが、この観点からするとシステムは複雑です。



私たちは常にこのシナリオに盲目的に従うとは限りません。今日、私たちは白黒を持っていません：すべてがLuaにあるか、すべてがGoにあります。後で移行の問題が発生しないように、これらを組み合わせる方法についてはすでに理解しています。



タランツールは今どこにありますか？

Tarantoolは、割引クーポン、別名「プロモーター」を考慮して、商品の最終コストを計算するサービスで使用されます。先ほど申し上げたように、現在は廃止されています。価格が事前に計算された新しいカタログサービスに置き換えられていますが、6か月前、すべての計算はプロモーターで行われました。以前は、そのロジックの半分はLuaで書かれていました。 2年前、サービスからストレージが作成され、割引の仕組みがわずかに変更され、サービスのパフォーマンスが低下したため、ロジックがGoに書き直されました。



最も重要なサービスの1つは、ユーザープロファイルです。つまり、すべてのWildberriesユーザーはTarantoolに保存されており、そのうちの約5,000万人がいます。ユーザーIDによってシャーディングされ、Goサービスに接続された複数のDCに分散されたシステム。

RPSによると、「プロモーター」はかつてリーダーであり、6000件のリクエストに達しました。ある時点で、50〜60部ありました。現在、RPSのリーダーは約12,000のユーザープロファイルです。このサービスは、ユーザーID範囲で分割されたカスタムシャーディングを使用します。このサービスは20台以上のマシンにサービスを提供しますが、これは多すぎるため、4〜5台のマシンの容量で十分であるため、割り当てられるリソースを削減する予定です。



セッションサービスは、vshardとCartridgeでの最初のサービスです。 vshardのセットアップとカートリッジの更新には、私たちの作業が必要でしたが、最終的にはすべてうまくいきました。



ウェブサイトとモバイルアプリケーションにさまざまなバナーを表示するサービスは、Tarantoolで直接リリースされた最初のサービスの1つでした。このサービスは、6〜7年経過しており、まだ稼働中であり、再起動したことがないという事実で注目に値します。複製はマスターマスターでした。何も壊さないでください。



倉庫システムのクイックリファレンス機能にTarantoolを使用して、場合によっては情報をすばやく再確認する例があります。これにRedisを使用しようとしましたが、メモリ内のデータはTarantoolよりも多くのスペースを占有していました。



順番待ちリストサービス、クライアントサブスクリプション、流行のストーリー、棚上げ商品もTarantoolで機能します。メモリ内の最後のサービスは約120GBです。これは、上記の中で最も広範なサービスです。

結論

キー値およびトランザクションプロパティと組み合わせたセカンダリインデックスにより、Tarantoolはマイクロサービスアーキテクチャに最適です。ただし、Luaで多くのロジックを使用してサービスへの変更を展開すると、問題が発生しました。サービスが機能しなくなることがよくありました。私たちはこれをなんとか打ち負かすことができず、時間の経過とともに、LuaとGoのさまざまな組み合わせにたどり着きました。



トピックについて他に読むべきこと

• 我々は最初からTarantoolに非常にロードされたアプリケーションを作成habr.com/ru/company/mailru/blog/510440を
• Tarantoolカートリッジで信頼できるリーダーの選択habr.com/ru/company/mailru/blog/513912
• 製品ニュース付きのTarantoolTelegramチャネルt.me/tarantool_news
• コミュニティチャットt.me/tarantoolruでTarantoolについて話し合う