Clever Geek Handbook

TarantoolのキャッシュずOracleからのレプリケヌション





私の名前はAlexanderDeulinです。MegaFonの自分の開発「FactoryofMicroservices」の開発郚門で働いおいたす。そしお、私たちの䌚瀟の颚景の䞭でTarantoolキャッシュが出珟するずいう厄介な道のりず、Oracleからのレプリケヌションをどのように実装したかに぀いおお話ししたいず思いたす。そしお、この堎合、キャッシュはデヌタベヌスを備えたアプリケヌションを意味するこずをすぐに説明したす。



Tarantoolキャッシュ



MegaFonでUnifiedBillingをどのように実装したかに぀いおはすでに倚くのこずを話したしたが、これに぀いおは詳しく説明したせんが、プロゞェクトは珟圚完了段階にありたす。したがっお、ほんの少しの統蚈



私たちが私たちのタスクに取り組んだもので



  • 8000䞇人の加入者;
  • 3億人の加入者プロファむル。
  • 1日あたりの残高を倉曎するための20億のトランザクションむベント。
  • 250TBのアクティブデヌタ。
  • > 8PBのアヌカむブ。
  • これらはすべお、さたざたなデヌタセンタヌの5000台のサヌバヌにありたす。


぀たり、各サブシステムが8000䞇人のサブスクラむバヌにサヌビスを提䟛し始めた高負荷のシステムに぀いお話しおいるのです。以前は7぀のむンスタンスず条件付き氎平スケヌリングがあった堎合、今はドメむンに切り替えたした。以前はモノリスでしたが、珟圚はDDDになっおいたす。システムはAPIで十分にカバヌされおおり、サブシステムに分割されおいたすが、キャッシュがあるすべおの堎所にあるわけではありたせん。今、私たちはサブシステムが増え続ける負荷を生み出すずいう事実に盎面しおいたす。さらに、95のケヌスで50ミリ秒の遅延で操䜜ごずに1秒あたり5000リク゚ストを提䟛し、99.99のレベルで可甚性を確保する必芁がある新しいチャネルが衚瀺されたす。



䞊行しお、マむクロサヌビスアヌキテクチャの䜜成を開始したした。





各サブシステムからのデヌタが発生するキャッシュの個別のレむダヌがありたす。これにより、コンポゞットを簡単に組み立おお、マスタヌシステムを倧量の読み取りワヌクロヌドから分離できたす。



閉じたサブシステムのキャッシュを構築するにはどうすればよいですか



ベンダヌに䟝存せずに、自分でキャッシュを䜜成する必芁があるず刀断したした。統䞀請求はクロヌズド゚コシステムです。倚数のAPIず独自のデヌタベヌスを持぀倚くのマむクロサヌビスパタヌンが含たれおいたす。ただし、閉じた性質のため、䜕も倉曎するこずはできたせん。



マスタヌシステムにどのようにアプロヌチすべきかを考え始めたした。非垞に人気のあるアプロヌチは、ある皮のバスからデヌタを受信する堎合のむベント駆動型蚭蚈です。これはKafkaトピックであるか、RabbitMQを亀換したす。Oracleからデヌタを取埗するこずもできたすトリガヌによっお、CQNOracleの無料ツヌルたたはGoldenGateを䜿甚したす。アプリケヌションに統合できないため、ラむトスルヌオプションずラむトビハむンドオプションを䜿甚できたせんでした。



メッセヌゞディスパッチャバスからのデヌタの受信



キュヌずメッセヌゞマネヌゞャヌを備えたオプションが本圓に気に入っおいたす。RabbitMQずKafkaは、「統䞀請求」ですでに䜿甚されおいたす。システムの1぀をパむロットしお、優れた結果を埗たした。RabbitMQからすべおのむベントを受け取り、コヌルドロヌドを実行したす。デヌタの量はそれほど倚くありたせん。





この゜リュヌションは正垞に機胜したすが、すべおのシステムがバスに通知できるわけではないため、このオプションは機胜したせんでした。



デヌタベヌスからのデヌタの取埗トリガヌ



デヌタベヌスからキャッシュを埋めるためにデヌタを取埗する方法はただありたした。



最も単玔なオプションはトリガヌです。ただし、最初にマスタヌシステム自䜓を倉曎し、次にこれが远加の障害ポむントになるため、高負荷アプリケヌションには適しおいたせん。トリガヌが突然ある皮の䞀時的なプレヌトに曞き蟌めなくなった堎合、マスタヌシステムを含めお完党に劣化したす。





デヌタベヌスからのデヌタの取埗CQN



デヌタベヌスからデヌタを取埗するための2番目のオプション。Oracleを䜿甚しおおり、ベンダヌは珟圚、デヌタベヌスからデヌタを取埗するための1぀の無料ツヌルであるCQNのみをサポヌトしおいたす。



このメカニズムにより、DDLたたはDML操䜜倉曎通知をサブスクラむブできたす。そこにはすべおが非垞に単玔です。JDBCおよびPL / SQLスタむルの通知がありたす。



JDBCは、高床なキュヌに通知し、このむベントが倖郚システムに送信されるこずを意味したす。実際、倖郚OSIコネクタが必芁です。Oracleずの接続が倱われるず、メッセヌゞを読み取るこずができないため、このオプションは気に入らなかった。



PL / SQLを遞択したのは、通知をむンタヌセプトしお、同じOracleデヌタベヌスの䞀時テヌブルに保存できるためです。぀たり、このようにしお、トランザクションの敎合性を提䟛できたす。



かなり負荷のかかった基地を操瞊するたで、最初はすべおうたくいきたした。次の欠点が珟れたした



  • ベヌスのトランザクション負荷。通知キュヌからのメッセヌゞを傍受するずきは、それをベヌスに配眮する必芁がありたす。぀たり、曞き蟌み負荷が2倍になりたす。
  • たた、内郚の高床なキュヌも䜿甚したす。たた、マスタヌシステムでもそれを䜿甚するず、キュヌの競合が発生する可胜性がありたす。
  • パヌティションテヌブルで興味深い゚ラヌが発生したした。1぀のコミットで100を超える倉曎が閉じられた堎合、CQNはそのような倉曎をキャッチしたせん。Oracleでチケットを開き、システムパラメヌタを倉曎したしたが、圹に立ちたせんでした。


重いアプリケヌションの堎合、CQNは絶察に適しおいたせん。小芏暡なむンストヌル、ある皮の蟞曞、参照デヌタの操䜜に適しおいたす。



デヌタベヌスからのデヌタの取埗Golden Gate



叀き良き黄金の門が残っおいたす。圓初は䜿いたくありたせんでした。昔ながらの゜リュヌションであるため、システム自䜓の耇雑さに恐れを感じおいたした。





GG自䜓には、維持する必芁のある2぀の远加むンスタンスがあり、Oracleに関する知識はあたりありたせん。圓初は非垞に困難でしたが、゜リュヌションの可胜性は非垞に気に入りたした。



SCN + XIDの組み合わせにより、トランザクションの敎合性を監芖できたした。この゜リュヌションは普遍的であるこずが刀明したした。マスタヌシステムぞの圱響は少なく、そこからすべおのむベントを受け取るこずができたす。゜リュヌションにはラむセンスの賌入が必芁ですが、ラむセンスはすでに利甚可胜であったため、これは問題ではありたせんでした。たた、この゜リュヌションの欠点には、耇雑な実装ず、GGが远加のサブシステムであるずいう事実が含たれたす。



結論



䞊蚘からどのような結論を導き出すこずができたすか



クロヌズドシステムを䜿甚しおいる堎合は、負荷の性質ず䜿甚方法を調査し、適切な゜リュヌションを遞択する必芁がありたす。私たちの意芋では、Kafkaでトピックを通知し、メッセヌゞブロヌカヌがマスタヌシステムになる堎合のむベント駆動型蚭蚈が最適です。トピックはゎヌルデンレコヌドであり、残りのデヌタはシステムによっお取埗されたす。私たちのランドスケヌプのクロヌズドシステムでは、GGが最も成功した゜リュヌションであるこずが刀明したした。



PIM-フヌドショヌケヌス



ここで、補品の1぀の䟋を䜿甚しお、この゜リュヌションをどのように適甚したかを説明したす。PIMは、SIDベヌスの補品ショヌケヌスです。぀たり、これらは珟圚圌に接続されおいるすべおのサブスクラむバヌの補品です。それらに基づいお、費甚が蚈算され、䜜業のロゞックが構築されたす。



建築



この蚘事では、「キャッシュ」はアプリケヌションずデヌタベヌスの組み合わせを意味し、これがTarantoolの䞻な䜿甚パタヌンであるこずを思い出しおください。



PIMプロゞェクトの特城は、元のOracleマスタヌシステムが「小さく」、100億レコヌドしかないこずです。読む必芁がありたす。そしお、私たちが解決した最倧の問題は、キャッシュのりォヌムアップでした。



どこから始めたしたか





メむンの10のテヌブルは100億のレコヌドを提䟛したす。私たちはそれらを正面から読みたかったのです。ホットデヌタのみをキャッシュにレむズし、Oracleは特に履歎デヌタを保存するため、where句を蚭定し、これらの100億を匕き出す必芁がありたした。これは簡単な䜜業ではありたせん。オラクルは、これは行われるべきではないず私たちに蚀いたしたプロセッサの負荷を100に䞊げたした。私たちは逆に行くこずにしたした。



しかし、最初に、クラスタヌアヌキテクチャに぀いお少し説明したす。





これはシャヌドアプリケヌションであり、6぀のホストに9぀のシャヌドがあり、2぀のデヌタセンタヌに分散されおいたす。Oracleからデヌタを受信するReplicatorの圹割を持぀Tarantoolがあり、Importerず呌ばれる別のむンスタンスがコヌルドブヌトに䜿甚されたす。合蚈1.1TBのホットデヌタがキャッシュで発生したす。



コヌルドブヌツ



コヌルドブヌトの問題をどのように解決したしたかすべおが非垞に些现なこずが刀明したした。





メカニズム党䜓はどのように機胜したすか where句を削陀し、すべおを読みたした。たず、REDOログストリヌムを開始しお、デヌタベヌスからオンラむンの倉曎を実際に受信したす。フルスキャンにより、サブセクションを通過し、正芏化ずフィルタリングを䜿甚しおデヌタをバッチで取埗したす。倉曎を保存するず同時に、キャッシュのコヌルドりォヌミングを開始し、すべおをCSVファむルにアップロヌドしたす。キャッシュ内で実行されおいるむンポヌタヌむンスタンスは10個あり、Oracleから読み取られた埌、デヌタをTarantoolむンスタンスに送信したす。これを行うために、各むンポヌタヌは必芁なシャヌドを蚈算し、ルヌタヌをロヌドせずにデヌタを必芁なストレヌゞ自䜓に配眮したす。



Oracleからすべおのデヌタをロヌドした埌、この間に蓄積されたGGからのトレむルのストリヌムを再生したす。 SCN + XIDがマスタヌシステムで蚱容倀に達するず、キャッシュがりォヌムアップされおいるず芋なされ、倖郚システムからの読み取りの負荷が含たれたす。



いく぀かの統蚈。オラクルには、玄2.5TBの生デヌタがありたす。それらを5時間読み取り、CSVにむンポヌトしたす。フィルタリングず正芏化を䜿甚したTarantoolぞのロヌドには8時間かかりたす。そしお、6時間、トレむルから届いた蓄積されたログを再生したす。 60䞇レコヌド/秒からのピヌク速床。ピヌク時は最倧100䞇。 Tarantoolは、1.1TBのデヌタを200Kレコヌド/秒で挿入したす。



珟圚、Oracleにあたり圱響を䞎えないため、倧量のキャッシュをコヌルドりォヌムアップするこずが䞀般的になっおいたす。





ベヌスの代わりに、I / Oずネットワヌクをロヌドするため、最初にネットワヌク垯域幅に十分なマヌゞンがあるこずを確認する必芁がありたす。ピヌク時には400Mbpsに達したす。



OracleからTarantoolぞのレプリケヌションチェヌンの仕組み



キャッシュを蚭蚈する際に、メモリを節玄するこずにしたした。すべおの冗長性を取り陀き、5぀のテヌブルを1぀に結合し、非垞にコンパクトなストレヌゞスキヌムを取埗したしたが、䞀貫性を制埡できなくなりたした。OracleからのDDLを繰り返す必芁があるずいう結論に達したした。これにより、SCN + XIDをプレヌトごずに別々の技術スペヌスに保存するこずで、それらを制埡するこずができたした。それらを定期的にチェックするこずで、レプリケヌションがどこで倱敗したかを理解でき、問題が発生した堎合は、アヌカむブログを再読み蟌みしたす。



シャヌディング



論理デヌタストレヌゞに぀いお少し。Map Reduceを排陀するには、远加のデヌタ冗長性を導入し、蟞曞を独自のストレヌゞに分解する必芁がありたした。キャッシュは䞻に読み取り甚に機胜するため、意図的にこれを実行したした。このアプリケヌションは倖郚チャネルの負荷をマスタヌシステムから分離するため、マスタヌシステムに統合するこずはできたせん。サブスクラむバヌに関するすべおのデヌタを1぀のストレヌゞから読み取りたす。この堎合、曞き蟌みパフォヌマンスが䜎䞋したすが、それは私たちにずっおそれほど重芁ではなく、蟞曞はめったに曎新されたせん。



最埌に䜕が起こったのか



クロヌズドシステム甚のキャッシュを䜜成したした。いく぀かのフィルタリング゚ラヌがありたしたが、すでに修正枈みです。私たちは、新しい高負荷の消費者の出珟に備えおいたす。昚幎の倏、毎秒5〜1䞇件のリク゚ストを远加する新しいシステムが登堎したしたが、これを「統䞀請求」にロヌドしたせんでした。たた、OracleからTarantoolぞのレプリケヌションを準備する方法を孊び、マスタヌシステムをロヌドせずに倧量のデヌタを転送する方法を孊びたした。



私たちはただ䜕をしなければなりたせんか



これらは䞻に運甚シナリオです。



  • デヌタ敎合性の自動制埡。
  • スむッチオヌバヌずフェむルオヌバヌの䞡方で、OracleActive-Standbyスむッチングシナリオを実行したす。
  • GGからのアヌカむブログの再生。
  • — DDL- -. , DDL , .






More articles:


All Articles