最近、ITアーキテクトがどのように機能するかについて書きました。次に、私たちのケースの1つについて詳細を説明し、システムのスキームを示します。このプロジェクトでは、「ボックス」バンキングアプリケーションをマイクロサービスRBSに置き換えると同時に、リリースのクイックリリースを平均して週に1回確立するのを支援しました。
: , , -. NDA – , , , -.
«»
中小企業の間では、独自のロゴを使用してカスタマイズおよびリリースできる既製のITソリューションが求められています。短所-「すぐに使用できる」アプリケーションの機能は制限されており、更新は多くの場合、ベンダーを通じてのみ長期間にわたって行われる必要があります。
私たちのクライアントの1つは、まさにそのようなリモートバンキングサービス（RBS）の「ボックス」システムを使用していました。オンラインバンクは、機能のセットがかなり少ないモノリシックアプリケーションでした。
競合他社に劣らないようにするために、銀行は常に改善と新機能を導入する必要がありました。ただし、アプリケーションのボタンを移動するだけでも、ベンダーに連絡する必要がありました。アップデートは平均して四半期に1回リリースされました。
したがって、いくつかの制限のために製品を開発することは困難でした。
- , «» .
- - «» -.
- , .
- , . .
- , .
- - , , , .
その結果、銀行は、機能の開発を加速し、ユーザーに利便性とセキュリティを提供するために、「ボックス」を徐々に放棄し、マイクロサービスアーキテクチャを備えた独自のリモートバンキングシステムを開発することを決定しました。
どこから始めましたか
オンラインバンクの作成は、トップレベルアーキテクチャの設計、開発者の採用、専任チームの接続から始まりました。同時に、将来の拡張を考慮して、アーキテクチャは安全性のマージンを持って敷設する必要がありました。
当初、バックエンド開発チームは、送金などの特定の基本機能の実装に従事していました。しかし、私たちはオンラインバンクでの作業にかなりの経験を積んでおり、この時点でのプロジェクトの1つがMarkswebbの業界評価に入ったため、建築設計で銀行の支援を提供し、青信号を受け取りました。
建築
製品の所有者と一緒に、マイクロサービスアーキテクチャを実装するために必要なすべての機能を提供するSpring Cloudを使用することにしました。これは、サービス検出-Eureka、Api Gateway-Zuul、Configサーバーなどです。銀行のインフラストラクチャがこのツール用に強化されたため、OpenShiftがDockerイメージのコンテナシステムとして選択されました。
また、古い「ボックス」のどの機能がユーザーの作業を複雑にする可能性があるかを分析しました。主な欠点の1つは、システムがデータバスを介して同期して動作し、すべてのユーザーアクションによってバスへのアクセスが発生することでした。負荷が大きいため、バスに障害が発生することが多く、アプリケーション全体が機能しなくなりました。さらに、多くの古い銀行製品と同様に、レガシーが蓄積されています。これは、古くて重いCORE ABSの形での「レガシー」であり、書き換えが困難で費用がかかります。
私たちはいくつかの改善を提案しました：
- バージョン管理
以前は、「ボックス」は1つのバージョンしかサポートしていませんでしたが、新しいオンラインバンクでは、複数の異なるバージョンを同時にサポートし、必要に応じてそれらを置き換えることができる新しいアーキテクチャを提案しました。
バージョン管理スキームは次のとおりです。サービスのマイナーバージョンが変更された場合、サービスは自動的に再構築およびデプロイされ、古いバージョンが置き換えられます。メジャーバージョンを配置すると、新しいバージョンのサービスの新しいコピーが展開されます。したがって、サービスAPIを変更した新機能の開発は、モバイルアプリケーションに影響を与えませんが、テスト時間は短縮されます。このようなシステムにより、ユーザーが更新する機会がない場合でも、古いバージョンのモバイルアプリケーションのサポートを提供することが可能になりました。
- 非同期性
非同期作業が必要なサービスで使用できるライブラリを実装しました。ライブラリは非同期タスクの実行を実装し、サービスの任意の数のコピーでの使用に適しており、相互に干渉しません。異なるコピー間の同期は、Kafkaメッセージキューを使用して行われます。
このソリューションは、アプリケーションの安定性を向上させるのに役立ちました。モバイルアプリケーションはバスに依存しなくなりました。サービスでユーザーに必要なデータを複製し、銀行バスにアクセスできるときにバックグラウンドで更新します。すべてのユーザーアクションは実行のためにキューに入れられ、準備が整うとすぐに、結果に関するPUSH通知が受信されます。
- キャッシング
アプリケーションを高速化し、内部バンキングリソースの負荷を軽減するために、Redisを使用したデータキャッシングが編成されています。KeyDBはキャッシュとして機能し、良好な結果を示し、Redisを使用する多くのシステムと互換性があります。データは、ユーザーの要求後ではなく、ユーザーデータが変更されたときにキャッシュされます。これにより、内部の銀行システムとは独立してデータにアクセスできます。
システムの変更点
上記のように、古いオンラインバンクでは、バックエンドはモノリシックアーキテクチャで実装され、アプリケーションは別のマシンにデプロイされていました。負荷が増加するにつれて、新しいサーバーを展開する必要がありました。サーバーがクラッシュしたとき、モバイルアプリケーションは一部のユーザーに対して機能しませんでした。
新しいソリューションはマイクロサービスアーキテクチャを使用しており、特定の機能に必要な数のサービスのコピーを展開できます。 KeyDBベースのデータキャッシングを追加して、情報の取得速度を上げるだけでなく、データベースの負荷を軽減しました。
新しいアーキテクチャでユーザーアカウントのデータを取得する例を見てみましょう。モバイルアプリケーションからのユーザーの要求は、バランサーを経由してゲートウェイに送られます。ゲートウェイは、要求を送信するサービスを理解します。次に、アカウントサービスAPIにアクセスします。サービスは最初に、キャッシュに実際のユーザーデータがあるかどうかを確認します。成功した場合はデータを返し、そうでない場合はミドルアカウントサービスにリクエストを送信します。
サービス内のデータの更新は、さまざまな場合に発生する可能性があります。たとえば、ユーザーからの直接の要求に応じて、サービスは非同期で実行されるデータ更新タスクを作成し、ESBから受信したデータが更新されます。また、サービスはメッセージキューからメッセージを受信し、それらに応答します。たとえば、サービスは、アプリケーションにログインしているユーザーに関するメッセージを受信し、すぐにアカウントデータを更新し、他のサービスからアカウントトランザクションに関するデータを受信し、そのデータを更新します。したがって、ユーザーは常に自分のアカウントの最新データを見ることができます。
最も重要な変更は次のとおりです。
- スケーリングの柔軟性
システムの耐障害性を高めるために、サービスはさまざまなサーバーに分散されます。これにより、いずれかが落下した場合でも、システムを正常に機能させることができます。非標準的な状況にタイムリーに対応するために、監視システムを導入しました。これは、必要に応じて、サービスを時間どおりにスケールアップするのに役立ちました。DevOpsを接続して、クライアントサーバーでCI / CDを最初から構成し、複数のサーバーで将来のアプリケーションの展開およびサポートプロセスを構築しました。
- バージョン管理によるリリースの加速
以前は、モバイルバージョンを更新するときに、一部のユーザーはすでに新しいバージョンを適用し、他のユーザーは適用していませんでしたが、後者の数は最小限でした。新しいRBSを開発する際に、バージョン管理と、アプリケーションが大部分の顧客で機能しなくなるリスクなしにリリースをリリースする機能を実装しました。現在、新しいバージョンで個々の機能を実装するときに、古いバージョンを壊すことはありません。つまり、後退する必要はありません。これにより、リリースの頻度が少なくとも15倍高速化されました。現在、リリースは平均して週に1回リリースされています。バックエンドチームとモバイルチームは、同時に独立して新しい機能に取り組むことができます。
まとめ
この例では、「ボックス化された」モノリシックソリューションに代わる銀行のマイクロサービスアーキテクチャの設計について説明しました。分散チームがこのプロジェクトに取り組み、社内の開発者とアウトソーサーの両方が参加しました。
オンラインバンクを開発する際、ボックス版と同じ範囲の機能を新しいアプリケーションに実装し、徐々に開発していきました。
顧客離れを防ぐために、障害やダウンタイムのない、問題のないアプリケーションの操作を確立し、リリースとアップデートを定期的にリリースする必要がありました。これは、アーキテクチャの改善のおかげで達成されました。特に、データベースの負荷を軽減した後、アプリケーションの一定の可用性を実現し、バージョン管理により、テスト時間を短縮し、機能に関する独立した作業と週に1回のリリースのリリースの可能性を確保しました。
アプリケーションのアーキテクチャは、銀行の社内チームが使用する製品および開発ツールのさらなる成長に基づいているため、製品の所有者はRBSを独自に改善できます。アルファ版の積極的な開発期間は約1年で、さらに3か月後に、すべてのユーザー向けにベータ版がリリースされました。
説明されている作業スキームが、他のフィンテック製品を作成するときに役立つことを願っています。
清聴ありがとうございました！