映画「Our Secret Universe: The Hidden Life of the Cell」の静止画

投資ビジネスは、銀行業界で最も複雑な分野の XNUMX つです。融資、借入、預金だけでなく、有価証券、通貨、商品、デリバティブ、および仕組み商品の形であらゆる種類の複雑さが存在するためです。

最近、国民の金融リテラシーの向上が見られます。 証券市場での取引に参加する人がますます増えています。 個人の投資口座が登場したのはそれほど前のことではありません。 これにより、証券市場で取引を行ったり、税金の控除を受けたり、税金の支払いを回避したりすることができます。 そして、私たちを訪れるすべてのクライアントは、自分のポートフォリオを管理し、リアルタイムでレポートを見たいと考えています。 さらに、ほとんどの場合、このポートフォリオは複数の製品にまたがっています。つまり、人々はさまざまな事業分野の顧客です。

さらに、ロシア国内外の規制当局のニーズも高まっています。

現在のニーズに応え、将来のアップグレードの基礎を築くために、当社は Tarantool に基づいた投資ビジネス コアを開発しました。

いくつかの統計。 アルファバンクの投資事業は、個人および法人にさまざまな証券市場で取引する機会を提供する仲介サービス、有価証券を保管するための保管サービス、個人資本および大規模資本を持つ個人に信託管理サービス、他社に有価証券発行サービスを提供しています。 。 Alfa-Bank の投資ビジネスには、さまざまな取引プラットフォームからダウンロードされる 3 秒あたり 300 を超える相場が含まれます。 営業日中に、銀行またはその顧客に代わって市場で 5 万件を超える取引が行われます。 外部および内部プラットフォーム上で XNUMX 秒あたり最大 XNUMX 件の注文執行が行われます。 同時に、社内外のすべてのクライアントは、自分のポジションをリアルタイムで確認したいと考えています。

背景

2000 年代初頭から、当社の投資ビジネス分野は、為替取引、仲介サービス、為替取引、有価証券の店頭取引およびさまざまなデリバティブなど、独自に発展してきました。 その結果、私たちは機能井戸の罠にはまってしまいました。 それは何ですか？ 各事業部門には、それぞれの機能を重複させる独自のシステムがあります。 各システムは独自のデータ モデルを持っていますが、トランザクション、商品、カウンターパーティ、相場などの同じ概念で動作します。 そして、それぞれのシステムが独立して進化するにつれて、多様なテクノロジーの動物園が出現しました。

さらに、一部の製品は 1990 年代半ばに誕生したため、システムのコード ベースはすでにかなり時代遅れになっています。 また、一部の領域ではこれにより開発プロセスが遅くなり、パフォーマンスの問題が発生しました。

新しいソリューションの要件

企業は、さらなる発展には技術革新が不可欠であることを認識しています。 私たちに与えられた課題は次のとおりです。

1. すべてのビジネス データを単一の高速ストレージと単一のデータ モデルに収集します。
2. この情報を紛失したり変更したりしてはなりません。
3. いつでも規制当局が過去数年の統計を要求する可能性があるため、データをバージョン管理する必要があります。
4. 新しい流行の DBMS を導入するだけではなく、ビジネス上の問題を解決するためのプラットフォームを構築する必要があります。

さらに、当社のアーキテクトは独自の条件を設定します。

1. 新しいソリューションはエンタープライズクラスである必要があります。つまり、一部の大企業ですでにテストされている必要があります。
2. ソリューションの動作モードはミッション クリティカルである必要があります。 これは、複数のデータ センターに同時に存在し、XNUMX つのデータ センターが停止した場合でも冷静に生き残る必要があることを意味します。
3. システムは水平方向に拡張可能である必要があります。 実際のところ、現在のシステムはすべて垂直方向にしか拡張できず、ハードウェアの能力の伸びが低いため、すでに頭打ちになっています。 したがって、生き残るためには水平方向に拡張可能なシステムが必要な時期が来ています。
4. とりわけ、ソリューションは安価でなければならないと言われました。

私たちは標準的なルートに従い、要件を策定し、購買部門に連絡しました。 そこから、一般的にこれを行う準備ができている企業のリストを受け取りました。 私たちは全員にこの問題について話し、そのうちの XNUMX 人から解決策の評価を受けました。

銀行では、誰の言葉も鵜呑みにせず、自分たちですべてをテストすることを好みます。 したがって、私たちの入札競争の必須条件は、負荷テストに合格することでした。 私たちは負荷テストのタスクを策定し、すでに XNUMX 社中 XNUMX 社が、インメモリ テクノロジに基づくプロトタイプ ソリューションをテストするために自費で実装することに同意しました。

すべてをどのようにテストしたか、どのくらいの時間がかかったのかについては説明しませんが、要約します。負荷テストで最高のパフォーマンスが得られたのは、Mail.ru Group 開発チームの Tarantool をベースとしたプロトタイプ ソリューションでした。 契約を締結し、開発を開始しました。 Mail.ru Group からは XNUMX 名、Alfa-Bank からは開発者 XNUMX 名、システム アナリスト XNUMX 名、ソリューション アーキテクト、プロダクト オーナー、スクラム マスター XNUMX 名でした。

次に、私たちのシステムがどのように成長し、どのように進化し、何をし、なぜそうなったのかについて説明します。

開発

私たちが最初に自問したのは、現在のシステムからデータを取得する方法でした。 現在のすべてのシステムは HTTP 経由で XML または JSON を送信することによって相互に通信するため、HTTP が当社にとって非常に適していると判断しました。

SSL セッションを終了する必要がなく、パフォーマンスも十分であるため、Tarantool に組み込まれている HTTP サーバーを使用しています。

すでに述べたように、私たちのすべてのシステムは異なるデータ モデルで動作しており、入力ではオブジェクトを自分たちで記述したモデルに取り込む必要があります。 データを変換できる言語が必要でした。 私たちは命令型 Lua を選択しました。 すべてのデータ変換コードはサンドボックス内で実行されます。これは、実行中のコードがそれを超えて移動しない安全な場所です。 これを行うには、必要なコードをロードストリングするだけで、何もブロックしたりドロップしたりできない関数を備えた環境を作成します。

変換後、データが作成中のモデルに準拠しているかどうかをチェックする必要があります。 私たちは、モデルがどうあるべきか、それを記述するためにどのような言語を使用するべきかについて、長い間議論しました。 Apache Avro を選択したのは、言語がシンプルで、Tarantool によるサポートがあるためです。 モデルとカスタム コードの新しいバージョンは、負荷がかかっているかどうかに関係なく、XNUMX 日に数回、いつでも運用できるため、変更に非常に迅速に対応できます。

検証後、データを保存する必要があります。 これは vshard を使用して行います (シャードのレプリカが地理的に分散されています)。

さらに、その特異性は、データを送信するほとんどのシステムが、データを受信したかどうかを気にしないほどです。 そのため、最初から修復キューを実装しました。 それは何ですか？ 何らかの理由でオブジェクトのデータ変換または検証が行われない場合でも、受信を確認しますが、同時にオブジェクトを修復キューに保存します。 これは一貫性があり、メインのビジネス データ ウェアハウスに配置されています。 私たちはすぐに、その管理者インターフェイス、さまざまなメトリクス、アラートを作成しました。 その結果、データが失われることはありません。 ソースに何か変更があったとしても、データモデルが変更されていれば、すぐに検出して適応できます。

次に、保存されたデータを取得する方法を学ぶ必要があります。 私たちはシステムを注意深く分析したところ、Java と Oracle の従来のスタックには、データをリレーショナルからオブジェクトに変換するある種の ORM が必ず含まれていることがわかりました。 それでは、なぜすぐにオブジェクトをグラフの形でシステムに提供してはいけないのでしょうか? そこで私たちは、すべてのニーズを満たす GraphQL を喜んで採用しました。 データをグラフ形式で受け取り、今必要なものだけを取り出すことができます。 非常に柔軟に API をバージョン管理することもできます。

抽出したデータが十分ではないことにすぐに気づきました。 モデル内のオブジェクト、つまり計算フィールドにリンクできる関数を作成しました。 つまり、平均見積価格を計算するなど、特定の関数をフィールドに付加します。 そして、データを要求する外部消費者は、これが計算フィールドであることさえ知りません。

認証システムを導入しました。

その後、私たちの決定にはいくつかの役割が具体化されていることに気づきました。 ロールは、機能の一種の集合体です。 通常、役割にはさまざまな機器使用プロファイルがあります。

• T-Connect: 着信接続を処理します。CPU は制限されており、メモリ消費量は低く、ステートレスです。
• IB-Core: Tarantool プロトコル経由で受信したデータを変換します。つまり、テーブルを操作します。 また、状態を保存せず、スケーラブルです。
• ストレージ: データを保存するだけであり、ロジックは使用しません。 このロールは、最も単純なインターフェイスを実装します。 vshard のおかげでスケーラブル。

つまり、ロールを使用してクラスターのさまざまな部分を相互に分離し、相互に独立してスケーリングできるようにしました。

そこで、管理インターフェイスを備えた非同期トランザクション データ フロー記録と修復キューを作成しました。 ビジネスの観点から見ると、記録は非同期です。どこにでもデータを自分自身に書き込むことが保証されている場合は、それを確認します。 確認されない場合は、何か問題が発生したため、データを送信する必要があります。 これが非同期録音です。

テスト

私たちはプロジェクトの開始当初から、テスト駆動開発を導入しようと決めていました。 単体テストは tarantool/tap フレームワークを使用して Lua で作成し、統合テストは Python で pytest フレームワークを使用して作成します。 同時に、開発者とアナリストの両方が統合テストの作成に参加します。

テスト駆動開発をどのように使用するのでしょうか?

何か新しい機能が必要な場合は、まずその機能のテストを作成しようとします。 バグを発見した場合、必ず最初にテストを作成し、それから修正するようにしています。 最初はこのように作業するのが難しく、従業員側に誤解があり、「すぐに修正して、何か新しいことをしてからテストでカバーしましょう」という妨害行為さえあります。 この「後で」だけはほとんど来ません。

したがって、最初に自分でテストを作成し、他の人にテストを依頼する必要があります。 信じてください、テスト駆動開発は短期的にもメリットをもたらします。 生活が楽になったと感じるでしょう。 コードの 99% がテストでカバーされていると感じています。 これは大変なように思えますが、問題はありません。テストはコミットごとに実行されます。

しかし、私たちが最も気に入っているのは負荷テストであり、それが最も重要であると考えており、定期的に実行しています。

最初のバージョンの 4 つで負荷テストの第 XNUMX 段階をどのように実行したかについて少しお話します。 開発者のラップトップにシステムをインストールし、負荷をオンにしたところ、XNUMX 秒あたり XNUMX 件のトランザクションが発生しました。 ラップトップとしては良い結果です。 これを、本番環境よりも弱い XNUMX 台のサーバーからなる仮想ロードベンチにインストールしました。 最小限に展開されています。 これを実行すると、XNUMX つのスレッドでラップトップよりも悪い結果が得られました。 衝撃の内容。

私たちはとても悲しかったです。 サーバーの負荷を調べましたが、アイドル状態であることがわかりました。

私たちが開発者に電話すると、Java の世界から来た私たちに、Tarantool はシングルスレッドであると説明されました。 負荷がかかっている場合、14,5 つのプロセッサ コアによってのみ効果的に使用できます。 次に、各サーバーに可能な最大数の Tarantool インスタンスをデプロイし、負荷をオンにしたところ、すでに XNUMX 秒あたり XNUMX のトランザクションを受信しました。

もう一度説明させてください。 リソースを異なる方法で使用するロールに分割されたため、接続とデータ変換の処理を担当するロールはプロセッサーのみに負荷をかけ、負荷に厳密に比例しました。

この場合、メモリは受信接続と一時オブジェクトの処理にのみ使用されました。

逆に、ストレージ サーバーではプロセッサの負荷は増加しましたが、接続を処理するサーバーよりもはるかに遅くなりました。

また、メモリ消費量は、ロードされるデータ量に正比例して増加しました。

サービス

特にアプリケーション プラットフォームとして新製品を開発するために、サービスとライブラリをデプロイするためのコンポーネントを作成しました。

サービスは、いくつかのフィールドで動作する単なる小さなコードではありません。 これらは、クラスターの一部であり、参照データをチェックし、ビジネス ロジックを実行して応答を返す、非常に大規模で複雑な構造になる場合があります。 また、サービス スキーマを GraphQL にエクスポートすると、コンシューマーはモデル全体に​​わたるイントロスペクションを備えたデータへのユニバーサル アクセス ポイントを受け取ります。 とても快適です。

サービスにはさらに多くの機能が含まれているため、頻繁に使用されるコードを移動するライブラリが必要であると判断しました。 私たちは、それが何かを壊さないことを事前に確認した上で、それらを安全な環境に追加しました。 そして、追加の環境をライブラリの形式で関数に割り当てることができるようになりました。

私たちはストレージだけでなくコンピューティングのプラットフォームも持ちたいと考えていました。 そして、すでに多数のレプリカとシャードがあったため、一種の分散コンピューティングを実装し、元のマップ リデュースと同様の結果になったため、それをマップ リデュースと呼びました。

古いシステム

プロトコルはサポートされていますが、すべてのレガシー システムが HTTP 経由で呼び出して GraphQL を使用できるわけではありません。 したがって、これらのシステムにデータを複製できるメカニズムを作成しました。

何かが変更されると、ストレージ ロールで固有のトリガーがトリガーされ、変更を含むメッセージが処理キューに入ります。 これは、別のレプリケーター ロールを使用して外部システムに送信されます。 このロールは状態を保存しません。

新しい改善点

覚えているとおり、ビジネスの観点から、私たちは非同期レコーディングを行いました。 しかしその後、それだけでは十分ではないことに気づきました。操作のステータスに関する応答をすぐに受け取る必要があるクラスのシステムがあるからです。 そこで、GraphQL を拡張し、ミューテーションを追加しました。 これらは、データを扱う既存のパラダイムに有機的に適合します。 私たちにとって、これは、別のクラスのシステムの読み取りと書き込みの両方を行う単一のポイントです。

また、XNUMX 日、XNUMX 週間、XNUMX か月に XNUMX 回作成する必要がある非常に重いレポートがあるため、サービスだけでは十分ではないことにも気づきました。 これには長い時間がかかる可能性があり、レポートによって Tarantool のイベント ループがブロックされる場合もあります。 したがって、スケジューラーとランナーという別々の役割を作成しました。 ランナーは状態を保存しません。 彼らは、私たちがその場で計算できない重いタスクを実行します。 また、スケジューラーの役割は、構成で説明されているこれらのタスクの起動スケジュールを監視します。 タスク自体はビジネス データと同じ場所に保存されます。 適切な時間が来ると、スケジューラがタスクを受け取り、ランナーにタスクを渡し、ランナーがタスクをカウントして結果を保存します。

すべてのタスクをスケジュールに従って実行する必要があるわけではありません。 一部のレポートはオンデマンドで読む必要があります。 この要件が到着するとすぐに、タスクがサンドボックス内に作成され、実行のためにランナーに送信されます。 しばらくすると、ユーザーは、すべてが計算され、レポートの準備ができたという非同期応答を受け取ります。

当初、私たちはすべてのデータを保存し、バージョン管理し、削除しないというパラダイムを遵守しました。 しかし、人生においては、何かを削除しなければならないことがあります。ほとんどの場合、生の情報や中間の情報です。 有効期限切れに基づいて、古いデータからストレージをクリーンアップするメカニズムを作成しました。

また、遅かれ早かれ、メモリにデータを保存するのに十分なスペースがなくなる状況が訪れることも理解していますが、それでもデータは保存する必要があります。 これらの目的のために、私たちは間もなくディスクストレージを作成する予定です。

まとめ

私たちは単一のモデルにデータをロードするタスクから開始し、開発に 30 か月を費やしました。 データ供給システムはXNUMXつありました。 Lua では、単一モデルへの変換コード全体は約 XNUMX 万行になります。 そして、作業のほとんどはまだ先のことです。 場合によっては、近隣チームのモチベーションが低下したり、作業を複雑にするさまざまな状況が発生したりすることもあります。 同様のタスクに直面した場合は、その実行にかかる通常の時間を XNUMX 倍、さらには XNUMX 倍にしてください。

また、ビジネス プロセスの既存の問題は、たとえ生産性が非常に高い DBMS であっても、新しい DBMS を使用して解決することはできないことにも注意してください。 私が意味したのは？ プロジェクトの開始時に、私たちは新しい高速データベースを導入し、今後も存続するという印象を顧客に与えました。 プロセスはより速く進み、すべてがうまくいきます。 実際、ビジネス プロセスは人間であるため、テクノロジーはビジネス プロセスが抱える問題を解決しません。 そしてテクノロジーではなく、人々と協力する必要があります。

テスト駆動開発は、初期段階では苦痛と時間がかかる場合があります。 しかし、回帰テストを実施するために何もする必要がない場合でも、そのプラスの効果は短期間であっても顕著になります。

開発のすべての段階で負荷テストを実施することは非常に重要です。 アーキテクチャの欠陥に早く気づくほど、修正が容易になり、将来的には大幅な時間を節約できます。

ルアなら何も問題ないよ。 Java 開発者、JavaScript 開発者、Python 開発者、フロントエンドまたはバックエンドなど、誰でも記述方法を学ぶことができます。 当社のアナリストもそれについて書いています。

SQL がないという事実について話すと、人々は恐怖を感じます。 「SQL を使わずにどうやってデータを取得するのでしょうか? これは可能でしょうか? 確かに。 OLTP クラス システムでは SQL は必要ありません。 何らかの言語の形式で、すぐにドキュメント指向のビューに戻る代替手段があります。 たとえば、GraphQL。 そして、分散コンピューティングという形での代替手段もあります。

スケーリングが必要であることを理解している場合は、数十の Tarantool インスタンスで並行して実行できるように、Tarantool でソリューションを設計します。 Tarantool は XNUMX つのプロセッサ コアしか有効に使用できないため、これを行わないと、後々大変で苦痛になります。

出所： habr.com