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

私たちは皆、物語が大好きです。 私たちは暖炉の周りに座って、過去の勝利や戦い、あるいは単に仕事の経験について話すのが好きです。

今日はまさにそんな日です。 たとえあなたが今火のそばにいないとしても、私たちはあなたに向けたストーリーを用意しています。 Tarantool でストレージを使い始めた経緯。

かつて、当社にはいくつかの「一枚岩」と XNUMX つの「天井」があり、これらの一枚岩がゆっくりと、しかし確実にそこに近づき、当社の飛行と発展を制限していました。 そして、いつかこの天井に大きくぶつかることになるという明確な理解がありました。

現在、機器からビジネス ロジックに至るまで、あらゆるものを分離するというイデオロギーが蔓延しています。 その結果、たとえば、ネットワーク レベルで実質的に独立した XNUMX つの DC が存在します。 そして、すべてがまったく違っていました。

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

しかし、時間は進み、リクエストの数もそれに伴って増加し、時には私たちの能力を超える RPS を達成しました。 CIS 諸国の市場参入により、最初のモノリスのデータベース プロセッサの負荷は 90% を下回らず、RPS は 2400 のレベルに留まりました。そして、これらは単なる小さなセレクターではなく、大量のクエリでした。大規模な IO を背景にデータのほぼ半分に対して実行される可能性のある大量のチェックと JOIN。

本格的なブラックフライデーセールが現場に現れ始めたとき、ワイルドベリーズはロシアで最初にブラックフライデーセールを開催したうちのXNUMXつであったが、状況は完全に悲しいものになった。 結局のところ、そのような日の負荷はXNUMX倍になります。
ああ、この「一枚岩の時代」！ あなたも同じようなことを経験したことがあると思いますが、なぜ自分にこんなことが起こり得るのか、まだ理解できていません。

あなたにできること - ファッションはテクノロジーに内在しています。 約 5 年前、私たちはこれらの MOD の XNUMX つを、サイト自体のすべてのロジックを慎重に保存した .NET および MS SQL サーバー上の既存のサイトの形で再考する必要がありました。 私はそれを非常に注意深く保管していたので、そのようなモノリスを鋸で切るのは長くて決して簡単な喜びではないことがわかりました。
小さな余談。

私はさまざまなイベントで「一枚岩を見なければ成長しない！」と言います。 この件に関するあなたの意見に興味があるので、コメントに書いてください。

そして雷が鳴った

「焚き火」の話に戻りましょう。 「モノリシック」機能の負荷を分散するために、オープンソース テクノロジーに基づいてシステムをマイクロサービスに分割することにしました。 少なくとも、スケールするのにコストがかからないからです。 そして、私たちは（そして多くの）規模を拡大する必要があることを100%理解していました。 結局のところ、その時点ですでに近隣諸国の市場に参入することが可能であり、登録数と注文数はさらに強力に増加し始めました。

モノリスからマイクロサービスへの移行の最初の候補を分析したところ、それらへの書き込みの 80% はバック オフィス システムからのものであり、読み取りはフロント オフィスからのものであることがわかりました。 まず第一に、これは私たちにとっていくつかの重要なサブシステム、つまりユーザーデータと、追加の顧客割引やクーポンに関する情報に基づいて最終的な商品原価を計算するシステムに関係していました。

インデントあり。 今では想像するのも恐ろしいですが、上記のサブシステムに加えて、製品カタログ、ユーザー ショッピング カート、製品検索システム、製品カタログのフィルタリング システム、および各種レコメンデーション システムもモノリスから削除されました。 それぞれを操作するために、厳密に調整されたシステムの別のクラスがありますが、かつてはすべてが XNUMX つの「家」に住んでいました。

私たちはすぐに、クライアントに関するデータをシャード システムに転送することを計画しました。 最終的な商品原価を計算する機能を削除するには、読み取りに優れたスケーラビリティが必要でした。これは、最大の RPS 負荷が発生し、データベースへの実装が最も困難であったためです (計算プロセスには大量のデータが関与します)。

その結果、Tarantool によく適合するスキームを思いつきました。

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

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

現時点では 24 個のシャードがあり、それぞれに 2 つのインスタンス (DC ごとに XNUMX つ) があり、すべてマスター/マスター モードになっています。

データベースの上には、データベースのレプリカにアクセスするアプリケーションがあります。 アプリケーションは、Tarantool Go ドライバー インターフェイスを実装するカスタム ライブラリを通じて Tarantool と連携します。 彼女はすべてのレプリカを確認し、マスターと連携して読み取りと書き込みを行うことができます。 基本的に、レプリカ セット モデルを実装し、レプリカの選択、再試行の実行、サーキット ブレーカー、およびレート制限のためのロジックを追加します。

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

建築。 オプション 2. 最終的な商品原価の計算サービス

数か月前、最終的な商品原価の計算リクエストのほとんどは、原則としてデータベースなしで動作する新しいサービスに送られましたが、少し前には、すべてが内部に Tarantool を備えたサービスによって 100% 処理されていました。

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

最初の方式でも XNUMX 番目の方式でも、XNUMX つの DC が利用できない場合、アプリケーションは XNUMX 番目の方式でデータを受信できます。

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

検索して見つけてください！

なぜ私たちは「普通の人と同じように」やらずに、非典型的な方法を選んだのでしょうか? それは何が正常とみなされるかによって異なります。 通常、多くは Mongo からクラスターを作成し、地理的に分散された XNUMX つの DC に分散させます。

その時点で、すでに XNUMX つの Redis プロジェクトがありました。 XNUMX つ目はキャッシュで、XNUMX つ目はそれほど重要ではないデータ用の永続ストレージでした。 彼にとっては、私たちのせいもあり、かなり困難でした。 場合によっては、キーに非常に大きなボリュームが含まれており、サイトの状態が悪化することがありました。 マスタースレーブバージョンではこのシステムを使用しました。 また、マスターに何らかの問題が発生してレプリケーションが停止するケースも多くありました。

つまり、Redis はステートフルなタスクではなく、ステートレスなタスクに適しています。 原理的には、ほとんどの問題を解決できましたが、それはインデックスのペアを使用したキーと値のソリューションである場合に限られていました。 しかし、当時の Redis は永続化とレプリケーションに関して非常に残念でした。 さらに、パフォーマンスに関する苦情もありました。

MySQL と PostgreSQL について考えました。 しかし、最初のものはどういうわけか私たちには受け入れられず、XNUMX つ目はそれ自体かなり洗練された製品であり、その上に単純なサービスを構築するのは不適切でしょう。
RIAK、Cassandra、さらにはグラフデータベースも試しました。 これらはすべてかなりニッチなソリューションであり、サービスを作成するための一般的な汎用ツールの役割には適していません。

最終的にはタランツールに落ち着きました。

バージョン 1.6 のときにこれに注目しました。 私たちは、キーと値の共生とリレーショナル データベースの機能に興味を持ちました。 セカンダリ インデックス、トランザクション、スペースがあり、これらはテーブルに似ていますが、単純ではなく、さまざまな数の列を格納できます。 しかし、Tarantool のキラー機能は、キー値とトランザクション性を組み合わせたセカンダリ インデックスでした。

ロシア語を話すコミュニティの対応力も高く、チャットですぐに助けてくれることも役割を果たしました。 私たちはこれを積極的に使用し、チャットに直接参加しました。 そして、明らかな失敗や間違いをせずに、きちんとした粘り強さを忘れないでください。 Tarantool の使用の歴史を見ると、レプリケーションで多くの苦労や失敗がありましたが、Tarantool のせいでデータが失われたことは一度もありませんでした。

導入は厳しいスタートを切った

当時、私たちの主な開発スタックは .NET でしたが、Tarantool 用のコネクタはありませんでした。 私たちはすぐに Go で何かを始めました。 Luaでもうまくいきました。 当時の主な問題はデバッグでした。.NET ではこれですべてがうまくいきましたが、その後、ログ以外にデバッグができない場合、組み込み Lua の世界に飛び込むのは困難でした。 さらに、何らかの理由でレプリケーションが定期的に失敗するため、Tarantool エンジンの構造を詳しく調べる必要がありました。 チャットはこれに役立ち、程度は低いですがドキュメントが役立ち、コードを確認することもありました。 当時のドキュメントはまあまあでした。

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

特別な時間でした。 従来であれば、次のテーブルの管理者に「仮想マシンをください」と頼むことができました。 約XNUMX分後、車はすでに到着しました。 自分で接続し、すべてをインストールすると、トラフィックが送信されました。

現在、これは機能しません。サービスに監視とログを追加し、テストで機能をカバーし、仮想マシンを注文したり、Kuber に配信したりする必要があります。 一般的には、この方法の方が良いでしょうが、時間がかかり、面倒になります。

分裂とルール。 ルアとの関係はどうなったの？

深刻なジレンマがありました。一部のチームは、Lua の多くのロジックを含むサービスへの変更を確実にロールアウトできませんでした。 これには、サービスが機能しないことがよくありました。

つまり、開発者は何らかの変更を準備しています。 Tarantool は移行を開始しますが、レプリカには古いコードが残ったままです。 何らかの DDL またはその他のものがレプリケーションを介してそこに到着しますが、それが考慮されていないため、コードは単純にバラバラになります。 その結果、管理者向けの更新手順は、レプリケーションを停止、これを更新、レプリケーションをオン、ここをオフ、あそこを更新というように A4 シートにレイアウトされました。 悪夢！

その結果、現在では Lua では何もしないようにすることがほとんどです。 iproto (サーバーと対話するためのバイナリ プロトコル) を使用するだけです。 おそらく開発者の知識不足なのかもしれませんが、この観点から見るとシステムは複雑です。

私たちは常にこの脚本に盲目的に従うわけではありません。 今日では白か黒かという区別はありません。すべてが Lua で行われるか、すべてが Go で行われるかのどちらかです。 私たちは、後で移行の問題が発生しないように、これらをどのように組み合わせればよいかをすでに理解しています。

タランツールは今どこにありますか？
Tarantool は、「プロモーター」とも呼ばれる、割引クーポンを考慮して最終的な商品原価を計算するサービスで使用されます。 先ほども述べたように、彼は現在退職しており、価格が事前計算された新しいカタログ サービスに置き換えられていますが、XNUMX か月前はすべての計算が Promotizer で行われていました。 以前は、ロジックの半分が Lua で書かれていました。 XNUMX 年前、割引の仕組みが少し変更され、サービスのパフォーマンスが不足していたため、このサービスはストレージ施設になり、ロジックが Go で書き直されました。

最も重要なサービスの 50 つはユーザー プロファイルです。 つまり、すべての Wildberries ユーザーは Tarantool に保存されており、その数は約 XNUMX 万であり、ユーザー ID によってシャード化されたシステムが、Go サービスに接続された複数の DC に分散されています。
RPS によると、プロモーターはかつてリーダーであり、6 件のリクエストに達しました。 ある時点では50～60部ありました。 現在、RPS のリーダーは約 12 人のユーザー プロファイルであり、このサービスはユーザー ID の範囲ごとに分割されたカスタム シャーディングを使用しています。 このサービスは 20 台を超えるマシンに対応していますが、これは多すぎます。4 ～ 5 台のマシンの容量で十分であるため、割り当てられるリソースを減らす予定です。

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

Web サイトとモバイル アプリケーションにさまざまなバナーを表示するサービスは、Tarantool 上で直接リリースされた最初のサービスの 6 つです。 このサービスは 7 ～ XNUMX 年前から存在し、まだ稼働しており、一度も再起動されていないという事実で注目に値します。 マスター間レプリケーションが使用されました。 何も壊れたことはありません。

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

待機リスト、クライアントのサブスクリプション、現在流行のストーリー、および据え置き商品のサービスも Tarantool で動作します。 メモリ内の最後のサービスは約 120 GB を占有します。 上記サービスの中で最も包括的なサービスです。

まとめ

セカンダリ インデックスとキー値およびトランザクション性を組み合わせたおかげで、Tarantool はマイクロサービス ベースのアーキテクチャに最適です。 しかし、Lua の多くのロジックを含むサービスへの変更をロールアウトするときに、サービスが動作を停止することがよくあるという問題に遭遇しました。 私たちはこれを克服できず、時間が経つにつれて、Lua と Go のさまざまな組み合わせにたどり着きました。私たちは、ある言語をどこで使用し、どこで別の言語を使用するかを知っています。

このトピックに関して他に何を読むべきか

• Tarantool を使用して高負荷アプリケーションを最初から作成する habr.com/ru/company/mailru/blog/510440
• Tarantool カートリッジの信頼できるリーダーの選択 habr.com/ru/company/mailru/blog/513912
• 製品に関するニュースを掲載する電報チャンネル Tarantool t.me/tarantool_news
• コミュニティチャットでTarantoolについて話し合う t.me/タランツール

出所： habr.com