新世代の課金アーキテクチャ: Tarantool への移行による変革

MegaFon のような企業が請求に Tarantool を必要とするのはなぜですか? 外から見ると、ベンダーは通常、大きな箱のようなものを持ってきて、プラグをソケットに差し込み、それが請求であるように見えます。 かつてはそうでしたが、現在は古風で、そのような恐竜はすでに絶滅したか、絶滅しつつあります。 当初、請求は請求書を発行するためのシステム、つまり計数機または計算機です。 現代の通信ではこれは 契約の締結から終了までの加入者とのやり取りのライフサイクル全体を対象とした自動化システム、リアルタイム請求、支払い受付などが含まれます。 通信会社における請求業務は、大きくて強力で武器を積んだ戦闘ロボットのようなものです。

タランツールはそれと何の関係があるのでしょうか？ 彼らはそれについて話すでしょう オレグ・イヴレフ и Andrey Knyazev。 オレグは会社の主任アーキテクトです メガホン 外国企業での豊富な勤務経験を持つ Andrey は、ビジネス システムのディレクターを務めています。 彼らの報告書の転写より タランツールカンファレンス 2018 なぜ企業で研究開発が必要なのか、Tarantool とは何か、垂直方向のスケーリングとグローバリゼーションの行き詰まりがどのようにして社内にこのデータベースを導入するための前提条件となったのか、技術的な課題、アーキテクチャの変革、MegaFon のテクノスタックが Netflix とどのように似ているのかを学びます。 、グーグルとアマゾン。

プロジェクト「統合請求」

問題のプロジェクトは「統合請求」と呼ばれます。 ここでタランツールの最高の品質が発揮されました。

ハイエンド機器の生産性向上は加入者数の増加やサービス数の増加に追いついていないが、M2M、IoT、ブランチ機能主導により加入者数とサービス数の更なる成長が見込まれる市場投入までの時間の悪化につながります。 同社は、現在の 8 つの異なる請求システムの代わりに、世界クラスの独自のモジュラー アーキテクチャを備えた統合ビジネス システムを作成することを決定しました。

MegaFon は XNUMX つの会社がひとつになったものです。 2009 年に再編が完了し、ロシア全土の支店が単一会社 MegaFon OJSC (現 PJSC) に統合されました。 したがって、同社には独自の「カスタム」ソリューション、支店機能、さまざまな組織構造、IT、マーケティングを備えた 8 つの請求システムがあります。

連邦共通の製品を XNUMX つ発売する必要があるまでは、すべてが順調でした。 ここで多くの困難が生じました。料金が切り上げられる場合もあれば、切り捨てられる場合もあり、また算術平均に基づいて計算される場合もあります。 そのような瞬間は何千もあります。

請求システムのバージョンが XNUMX つ、サプライヤーが XNUMX つだけだったにもかかわらず、設定が大きく異なっていたため、まとめるのに長い時間がかかりました。 私たちはその数を減らそうと試みましたが、多くの企業によく知られている XNUMX つ目の問題に遭遇しました。

垂直スケーリング。 当時最もクールなハードウェアでもニーズを満たせませんでした。 Superdome Hi-End シリーズの Hewlett Packard 機器を使用しましたが、XNUMX つの支店のニーズさえ満たせませんでした。 多額の運用コストや設備投資を必要とせずに水平スケーリングを実現したいと考えていました。

加入者数やサービス数の増加に期待。 コンサルタントは長い間、IoT と M2M に関する話を通信業界にもたらしてきました。すべての電話とアイロンに XNUMX 枚の SIM カードがあり、冷蔵庫に XNUMX 枚の SIM カードが入っている時代が来るでしょう。 現在の加入者数は XNUMX 人ですが、近い将来さらに多くの加入者が増えるでしょう。

技術的な課題

これら XNUMX つの理由が、私たちが重大な変化を起こす動機となったのです。 システムをアップグレードするか、最初から設計するかの選択がありました。 私たちは長い間考え、真剣な決断を下し、入札を行いました。 その結果、私たちは最初から設計を行うことを決定し、興味深い課題、つまり技術的な課題に取り組みました。

スケーラビリティ

以前だったら、言ってみましょう、言ってみましょう 8 万人の加入者に対して 15 回の請求、そして今はうまくいくはずです 加入者数100億人以上 - 負荷は一桁大きくなります。

私たちの規模は、Mail.ru や Netflix などの大手インターネット プレーヤーに匹敵する規模になりました。

しかし、負荷と加入者ベースを増加させるさらなる動きにより、私たちに深刻な課題が課せられています。

私たちの広大な国の地理

カリーニングラードとウラジオストク間 7500km、10のタイムゾーン。 光の速度は有限であり、そのような距離では遅延がすでに顕著になります。 最もクールな最新の光チャネルでの 150 ミリ秒は、特に現在のロシアの通信では、リアルタイムの請求には長すぎます。 さらに、XNUMX 営業日以内に更新する必要があり、タイムゾーンが異なるとこれが問題になります。

当社はサブスクリプション料金でサービスを提供するだけではなく、複雑な料金体系、パッケージ、さまざまな修飾子を用意しています。 加入者の通話を許可または拒否するだけでなく、加入者に一定の割り当てを与える必要があります。つまり、加入者が気付かないように通話とアクションをリアルタイムで計算します。

耐障害性

これは中央集権化の裏側です。

すべての加入者を XNUMX つのシステムに集めた場合、緊急事態や災害はビジネスに壊滅的な影響を与えます。 したがって、事故による加入者全体への影響を排除するようシステム設計を行っております。

これもまた、垂直方向のスケーリングを拒否した結果です。 水平方向にスケールした場合、サーバーの数は数百から数千に増加しました。 これらは管理され、交換可能であり、IT インフラストラクチャを自動的にバックアップし、分散システムを復元する必要があります。

私たちはこのような興味深い課題に直面しました。 私たちはシステムを設計しましたが、その時点で、私たちがどの程度トレンドに乗っているか、どの程度先進技術を追随しているかを確認するために、世界的なベストプラクティスを見つけようとしました。

世界の経験

驚いたことに、世界的な通信に関する参考文献は XNUMX つも見つかりませんでした。

欧州は加入者数と規模の点で劣り、米国は料金の均一性の点で劣っている。 中国でもいくつかを検討し、インドでもいくつかを見つけて、ボーダフォン インディアの専門家を雇いました。

アーキテクチャを分析するために、私たちは IBM をリーダーとするさまざまな分野のアーキテクトからなるドリーム チームを編成しました。 これらの人々は、私たちがやっていることを適切に評価し、私たちのアーキテクチャに特定の知識をもたらすことができました。

目盛り

説明のためにいくつかの数字を示します。

私たちは次のようなシステムを設計します。 加入者数は80万人、予備金はXNUMX億人。 このようにして、将来のしきい値を削除します。 これは中国を征服しようとしているからではなく、IoT と M2M の猛攻撃によるものです。

300 億のドキュメントをリアルタイムで処理。 当社には 80 万人の加入者がいますが、売掛金を回収する必要がある場合には、潜在的な顧客と離別した顧客の両方と協力します。 したがって、実際の体積は著しく大きくなります。

2億トランザクション 残高は、支払い、請求、通話、その他のイベントによって毎日変化します。 200 TB のデータが活発に変化しています、少しゆっくりと変化します 8 PB のデータ、これはアーカイブではなく、単一請求のライブデータです。 データセンターごとの拡張 - 5 サイトに 14 台のサーバー.

技術スタック

アーキテクチャを計画し、システムの組み立てを開始したとき、最も興味深く先進的なテクノロジーを導入しました。 その結果、インターネット プレーヤーや高負荷システムを作成する企業には馴染みのあるテクノロジー スタックが誕生しました。

このスタックは、Netflix、Twitter、Viber などの他の大手プレーヤーのスタックと似ています。 6つのコンポーネントで構成されていますが、短縮して統一したいと考えています。

柔軟性があるのは良いことですが、大企業では統一しないとどうしようもありません。

同じ Oracle を Tarantool に変更するつもりはありません。 大企業の現実では、これは理想郷、あるいは結果が不透明な 5 ～ 10 年の聖戦です。 しかし、Cassandra と Couchbase は Tarantool に簡単に置き換えることができ、それが私たちが目指していることです。

なぜタランツールなのか？

このデータベースを選択した理由は 4 つあります。

スピード。 MegaFon 産業用システムの負荷テストを実施しました。 タランツールが勝利し、最高のパフォーマンスを示しました。

これは、他のシステムが MegaFon のニーズを満たしていないと言っているわけではありません。 現在のメモリ ソリューションの生産性は非常に高いため、同社の予備は十分すぎるほどです。 しかし、私たちが関心があるのは、負荷テストを含め、遅れをとっている人ではなく、リーダーとの付き合いです。

Tarantool は、長期的にも企業のニーズをカバーします。

TCO コスト。 MegaFon ボリュームでの Couchbase のサポートには天文学的な金額がかかりますが、Tarantool を使用すると状況ははるかに快適になり、機能も似ています。

私たちの選択にわずかに影響を与えたもう XNUMX つの優れた機能は、Tarantool が他のデータベースよりもメモリでより適切に動作することです。 彼が示しています 最大効率.

信頼性。 MegaFon は、おそらく他の誰よりも信頼性に投資しています。 そこで、Tarantool を検討したときに、それを要件を満たすようにする必要があることがわかりました。

私たちは時間と資金を投資し、Mail.ru と協力してエンタープライズ バージョンを作成し、現在他のいくつかの企業で使用されています。

Tarantool-enterprise は、セキュリティ、信頼性、ロギングの点で私たちを完全に満足させました。

パートナーシップ

私にとって最も重要なことは 開発者との直接コンタクト。 これはまさにタランツールの人たちが賄賂を受け取ったものです。

あなたがプレーヤー、特にアンカー クライアントと連携しているプレーヤーのところに来て、これ、これ、これを実行できるようにするにはデータベースが必要だと言うと、彼は通常次のように答えます。

- わかりました、要件をその山の一番下に置いてください - いつか、おそらくそれらに到達するでしょう。

多くは今後 2 ～ 3 年のロードマップを持っており、そこに統合することはほぼ不可能ですが、Tarantool の開発者は、MegaFon だけでなく、そのオープンさに魅了され、自社のシステムを顧客に適応させます。 クールでとても気に入っています。

Tarantool を使用した場所

いくつかの要素で Tarantool を使用します。 最初のものはパイロット版にあります、アドレスディレクトリシステム上に作成しました。 かつては、Yandex.Maps や Google Maps に似たシステムにしたいと考えていましたが、結果は少し異なりました。

たとえば、販売インターフェイスのアドレス カタログなどです。 Oracle では、目的のアドレスの検索に 12 ～ 13 秒かかります。 -不快な数字。 Tarantool に切り替え、コンソールで Oracle を別のデータベースに置き換え、同じ検索を実行すると、200 倍の速度向上が得られます。 XNUMX 番目の文字の後に都市が現れます。 現在、これが最初のインターフェースの後に起こるようにインターフェースを調整しています。 ただし、応答速度はまったく異なり、秒ではなくミリ秒です。

XNUMX 番目のアプリケーションは、ツースピード IT と呼ばれる流行のテーマです。 企業はそこに行くべきだと各方面のコンサルタントが言っているからです。

インフラストラクチャ層があり、その上に、通信などの請求システム、企業システム、企業レポートなどのドメインがあります。 これは触れる必要のない核心です。 もちろんそれは可能ですが、企業にお金をもたらすため、偏執的に品質を確保することになります。

次に、マイクロサービスの層が来ます。これは、オペレーターや他のプレーヤーを区別するものです。 特定のキャッシュに基づいてマイクロサービスを迅速に作成し、そこにさまざまなドメインからデータを取り込むことができます。 ここ 実験用のフィールド — 何かがうまくいかない場合は、XNUMX つのマイクロサービスを閉じて、別のマイクロサービスを開きました。 これにより、市場投入までの時間が大幅に短縮され、企業の信頼性とスピードが向上します。

MegaFon における Tarantool の主な役割はおそらくマイクロサービスです。

Tarantool を使用する予定の場所

私たちの成功した請求プロジェクトと、ドイツテレコム、スヴィヤズコム、ボーダフォン・インディアの変革プログラムを比較してみると、驚くほどダイナミックで創造的です。 このプロジェクトを実装する過程で、MegaFon とその構造が変更されただけでなく、Tarantool-enterprise が Mail.ru に登場し、当社のベンダー Nexign (旧 Peter-Service) - BSS Box (ボックス化請求ソリューション) も登場しました。

これはある意味、ロシア市場にとって歴史的なプロジェクトだ。 これは、フレデリック・ブルックスの著書「The Mythical Man-Month」で説明されているものと比較できます。 その後、60 年代に、IBM はメインフレーム用の新しい OS/360 オペレーティング システムを開発するために 5 人を雇用しました。 私たちの保有数は 000 未満ですが、ベストの中にあり、オープンソースと新しいアプローチの使用を考慮して、より生産的に作業しています。

以下は、請求、またはより広義にはビジネス システムのドメインです。 企業の人々は CRM をよく知っています。 誰もがすでに他のシステム、Open API、API Gateway を持っているはずです。

オープンAPI

もう一度数字と Open API が現在どのように機能しているかを見てみましょう。 その負荷は 10 秒あたり 000 トランザクション。 今後もマイクロサービス層の開発やMegaFonパブリックAPIの構築を積極的に行っていく予定であるため、この部分は今後さらなる成長が期待されます。 間違いなく100万件のトランザクションが発生するでしょう.

SSO における Mail.ru と比較できるかどうかはわかりませんが、彼らは 1 秒あたり 000 件のトランザクションを行っているようです。 彼らのソリューションは私たちにとって非常に興味深いものであり、Tarantool を使用して機能的な SSO バックアップを作成するなど、彼らの経験を採用する予定です。 現在、Mail.ru の開発者が私たちのためにこれを行っています。

CRM

CRM の購読者は 80 万人と同じですが、300 億人に増やしたいと考えています。これは、XNUMX 年間の履歴を含むドキュメントがすでに XNUMX 億件あるためです。 新しいサービスを本当に楽しみにしています 成長ポイントはコネクテッドサービス。 サービスもどんどん増えていくので、これから伸びるボールです。 したがって、ストーリーが必要になりますが、これでつまずいてはいけません。

請求書の発行、顧客の売掛金の処理などの請求自体 別のドメインに変換される。 パフォーマンスを向上させるには、 適用されたドメイン アーキテクチャ アーキテクチャ パターン.

システムをドメインに分割し、負荷を分散し耐障害性を確保します。 さらに、分散アーキテクチャにも取り組みました。

それ以外はすべてエンタープライズレベルのソリューションです。 通話ストレージ内 - 2日あたりXNUMX億, 月あたり60億。 場合によっては XNUMX か月以内にカウントしなければならない場合もありますが、そのほうが早いほうが良いでしょう。 財務モニタリング - これは、絶えず増加し続ける 300 億とまったく同じです。加入者は事業者間を行き来することが多く、この部分が増加します。

モバイル通信の最も通信コンポーネントは、 オンライン請求。 これらは、電話をかけるかどうか、リアルタイムで決定を下すことを可能にするシステムです。 ここでは、負荷は 30 秒あたり 000 トランザクションですが、データ転送の増加を考慮して、 250 件のトランザクションしたがって、Tarantool に非常に興味があります。

前の図は、Tarantool を使用するドメインです。 もちろん、CRM 自体はより広範であり、中核自体で CRM を使用する予定です。

加入者数 100 億人という TTX の推定値は、アーキテクトとして私を混乱させます。101 億 XNUMX 万人だったらどうなるでしょうか? もう一度すべてやり直さなければなりませんか？ これを防ぐために、キャッシュを使用し、同時にアクセシビリティを高めます。

一般に、Tarantool を使用するには XNUMX つのアプローチがあります。 初め - すべてのキャッシュをマイクロサービス レベルで構築する。 私が理解している限り、VimpelCom はこの道をたどり、クライアントのキャッシュを作成しています。

ベンダーへの依存度が低くなり、BSS コアを変更しているため、すぐに使用できるクライアント ファイルは XNUMX つだけです。 しかし、私たちはそれを拡大したいと考えています。 したがって、私たちは少し異なるアプローチを採用します - システム内にキャッシュを作成する.

この方法では同期が少なくなり、XNUMX つのシステムがキャッシュとメイン マスター ソースの両方を担当します。

この方法は、更新に関連する部分、つまりデータ変更のみが更新される場合、トランザクション スケルトンを使用した Tarantool アプローチによく適合します。 それ以外のものはすべて別の場所に保存できます。 巨大なデータレイクや管理されていないグローバルキャッシュは存在しません。 キャッシュは、システム、製品、クライアント、またはメンテナンスを容易にするために設計されています。 加入者が電話をかけてきてサービスの品質に不満を感じた場合、あなたは質の高いサービスを提供したいと考えます。

RTO と RPO

IT には XNUMX つの用語があります - RTO и RPO.

目標回復時間 障害後にサービスを復元するのにかかる時間です。 RTO = 0 は、何か障害が発生した場合でもサービスが動作し続けることを意味します。

目標復旧時点 - これはデータ回復時間であり、一定期間内にどれだけのデータが失われる可能性があるかということです。 RPO = 0 は、データが失われていないことを意味します。

タランツールタスク

Tarantool の問題を解決してみましょう。

与えられた: たとえば Amazon やその他の場所にある、誰もが理解できるアプリケーションのバスケット。 必須 そのため、ショッピング カートは 24 時間年中無休、つまり 7% 稼働します。 加入者の接続をランダムにオンまたはオフにすることはできないため、私たちに届く注文は順序どおりに保たれなければなりません。すべてが厳密に一貫していなければなりません。 以前のサブスクリプションは次のサブスクリプションに影響を与えるため、データは重要です。欠落するものは何もありません。

ソリューション。 この問題を正面から解決しようとしたり、データベース開発者に問い合わせたりすることはできますが、問題を数学的に解決することはできません。 定理、保存則、量子物理学は覚えられますが、それは DB レベルでは解決できないからです。

ここでは古き良きアーキテクチャのアプローチが機能します。主題領域をよく理解し、それを使ってこのパズルを解く必要があります。

私たちのソリューション: Tarantool 上にアプリケーションの分散レジストリを作成する - 地理的に分散されたクラスター。 この図では、これらは XNUMX つの異なるデータ処理センター (ウラル山脈の手前に XNUMX つ、ウラル山の向こうに XNUMX つ) があり、すべてのリクエストをこれらのセンター間で分散します。

現在 IT 業界のリーダーの 2012 つと考えられている Netflix は、24 年までデータセンターを XNUMX つしか持っていませんでした。 カトリックのクリスマスの前夜、XNUMX 月 XNUMX 日、このデータセンターはダウンしました。 カナダとアメリカのユーザーは、お気に入りの映画が見られなくなって非常に動揺し、そのことについてソーシャル ネットワークに書きました。 Netflix は現在、西東海岸に XNUMX か所、西ヨーロッパに XNUMX か所のデータセンターを持っています。

私たちは最初に地理的に分散されたソリューションを構築しています。私たちにとって耐障害性は重要です。

クラスターはありますが、RPO = 0 および RTO = 0 の場合はどうでしょうか? 主題にもよりますが、解決策は簡単です。

アプリケーションで重要なことは何ですか? XNUMX つのパート: バスケット投げ TO 購入の決定を下し、 後に。 電気通信の DO 部分は通常、次のように呼ばれます。 注文の取り込み または 注文交渉。 テレコムでは、これはオンライン ストアよりもはるかに難しい場合があります。なぜなら、テレコムではクライアントにサービスを提供し、5 つのオプションを提供する必要があり、これはすべてしばらくの間行われますが、バスケットはいっぱいになるからです。 現時点では失敗する可能性がありますが、人間の監視下で対話的に発生するため、それほど怖いものではありません。

モスクワのデータセンターに突然障害が発生した場合でも、自動的に別のデータセンターに切り替えることで業務を継続します。 理論的には、0 つの製品がカート内で失われる可能性がありますが、それが表示されたら、再度カートに追加して作業を続行します。 この場合、RTO = XNUMX。

同時に、0 番目のオプションがあります。「送信」をクリックしたときに、データが失われないようにする必要があります。 この瞬間から、自動化が機能し始めます。これは RPO = XNUMX です。これら XNUMX つの異なるパターンを使用すると、ある場合には、単に XNUMX つの切り替え可能なマスターを持つ地理分散クラスターになり、別の場合には、ある種のクォーラム レコードになる可能性があります。 パターンは異なる場合がありますが、問題は解決します。

さらに、アプリケーションの分散レジストリがあるため、すべてを拡張することもできます。このレジストリにアクセスする多くのディスパッチャとエグゼキュータが必要です。

カサンドラとタランツールが一緒に

別のケースもあります - 「天秤の展示」。 Cassandra と Tarantool を共同使用した興味深い事例を次に示します。

Cassandra を使用するのは、2 日あたり XNUMX 億件の呼び出しが制限ではなく、さらに多くなるからです。 マーケティング担当者はソースごとにトラフィックを色分けすることを好みます。たとえば、ソーシャル ネットワークにはますます多くの詳細が表示されます。 すべてが物語に加わります。

Cassandra を使用すると、水平方向に任意のサイズに拡大縮小できます。

私たちは Cassandra に快適さを感じていますが、Cassandra には 30 つ問題があります。それは、Cassandra が読むのが苦手であるということです。 録画はすべて問題ありません。000 秒あたり XNUMX 回でも問題ありません - 読解問題.

そこで、キャッシュに関するトピックが登場し、同時に次の問題を解決しました。Cassandra に読み込むファイルに、オンライン請求からの切り替えによる機器が混入するという古い伝統的なケースがありました。 IBM のファイル転送マネージャーのアドバイスを借りながらも、これらのファイルを確実にダウンロードするという問題に苦労しました。たとえば、TCP ではなく UDP プロトコルを使用して、ファイル転送を効率的に管理するソリューションがあります。 これは良いことですが、まだ数分です。まだすべてを読み込んでいません。コールセンターのオペレーターは、顧客の残高に何が起こったのか答えることができません。待たなければなりません。

このようなことが起こらないようにするために、私たちは 並行機能予備を使用します。 Kafka 経由でイベントを Tarantool に送信し、リアルタイムで集計を再計算すると、たとえば今日の場合は次のようになります。 現金残高、たとえば、100 秒あたり 2 万件のトランザクションと同じ XNUMX 秒間など、任意の速度で残高を転送できます。

目標は、電話をかけた後 2 秒以内に、変更された残高だけでなく、変更された理由に関する情報も個人アカウントに表示されることです。

まとめ

これらは Tarantool の使用例です。 Mail.ru のオープンさと、さまざまなケースを検討する意欲がとても気に入りました。

BCG やマッキンゼー、アクセンチュアや IBM のコンサルタントが何か新しいもので私たちを驚かせることはすでに困難です。彼らが提供するものの多くは、私たちがすでに行っているか、行っているか、または計画しているかのいずれかです。 Tarantool は当社の技術スタック内で正当な位置を占め、多くの既存の技術を置き換えると思います。 私たちはこのプロジェクトの開発の活発な段階にあります。

オレグとアンドレイによる報告書は、昨年のタランツール会議で最も優れた報告書の一つであり、17月XNUMX日にはオレグ・イヴレフ氏が講演する予定である。 T+ カンファレンス 2019 報告書付き 「Tarantool がエンタープライズに導入される理由」。 MegaFon からは Alexander Deulin 氏もプレゼンテーションを行います 「Tarantool のキャッシュと Oracle からのレプリケーション」。 何が変わったのか、どのような計画が実施されたのかを見てみましょう。 参加 - カンファレンスは無料です。あなたがしなければならないことは次のとおりです。 登録。 全て 報告書が受理されました そして、新しいケース、Tarantool の使用における新しい経験、アーキテクチャ、エンタープライズ、チュートリアル、マイクロサービスなどのカンファレンス プログラムが形成されました。

出所： habr.com