Kubernetes 内でクラウド FaaS を作成し、Tinkoff ハカソンで優勝した方法

昨年から弊社ではハッカソンの開催を始めました。 このような最初のコンテストは大成功を収めました。それについては次の記事で書きました。 статье。 2019 回目のハッカソンは XNUMX 年 XNUMX 月に開催され、同様に成功しました。 少し前に後者を保持する目標について 私が書きました 主催者。

参加者には、実装するテクノロジー スタックを完全に自由に選択できる、かなり興味深いタスクが与えられました。 顧客スコアリング機能を便利に導入するには、アプリケーションの高速なフローに対応し、高負荷に耐え、システム自体を簡単に拡張できる意思決定プラットフォームを実装する必要がありました。

参加者のプロジェクトの最終プレゼンテーションのデモンストレーション中に私たちが確信したように、この課題は簡単ではなく、さまざまな方法で解決することができます。 ハッカソンには 6 人からなる 5 チームが参加し、参加者全員が良いプロジェクトを持っていましたが、私たちのプラットフォームが最も競争力があることが判明しました。 とても興味深いプロジェクトがあるので、この記事でお話ししたいと思います。

当社のソリューションは、Kubernetes 内のサーバーレス アーキテクチャに基づくプラットフォームであり、新しい機能を運用環境に導入するのにかかる時間を短縮します。 これにより、アナリストは、エンジニアや開発者の参加なしに、自分にとって都合の良い環境でコードを作成し、実稼働環境にデプロイすることができます。

採点とは何ですか

Tinkoff.ru は、多くの現代企業と同様に、顧客スコアリングを行っています。 スコアリングは、データ分析の統計的手法に基づいた顧客評価システムです。

たとえば、クライアントが私たちにローンを発行してほしい、または私たちに個人起業家口座を開設してほしいと依頼したとします。 彼にローンを発行する予定がある場合は、彼の支払能力を評価する必要があります。また、口座が個人起業家の場合は、顧客が不正な取引を行わないことを確認する必要があります。

このような意思決定を行うための基礎となるのは、アプリケーション自体からのデータとストレージからのデータの両方を分析する数学的モデルです。 スコアリングに加えて、同様の統計手法は、クライアント向けの新製品に関する個別の推奨事項を生成するサービスにも使用できます。

このような評価方法では、さまざまな入力データを受け入れることができます。 そして、ある時点で、履歴データの分析結果に基づいて、サービス利用のコンバージョン率を高める新しいパラメーターを入力に追加できます。

当社は顧客関係に関する豊富なデータを保有しており、この情報の量は増え続けています。 スコアリングが機能するためには、データ処理にはルール (または数学的モデル) も必要です。これにより、誰が申請を承認するか、誰が拒否するか、誰がさらにいくつかの製品を提供するかを迅速に決定し、潜在的な関心を評価できるようになります。

当面のタスクについては、すでに専用の意思決定システムを使用しています IBM WebSphere ILOG JRules BRMS、アナリスト、技術者、開発者によって設定されたルールに基づいて、顧客に対する特定の銀行商品を承認するか拒否するかを決定します。

市場には、スコアリング モデルと意思決定システム自体の両方で、既製のソリューションが多数存在します。 当社ではこれらのシステムの XNUMX つを使用しています。 しかし、ビジネスは成長し、多様化しており、顧客の数と提供される製品の数は両方とも増加しており、これに伴い、既存の意思決定プロセスを改善する方法に関するアイデアも生まれています。 確かに、既存のシステムを使用している人々は、それをよりシンプルに、より良く、より便利にする方法について多くのアイデアを持っていますが、外部からのアイデアが役立つ場合もあります。 New Hackathon は、健全なアイデアを収集することを目的として開催されました。

タスク

23月XNUMX日にハッカソンが開催されました。 参加者には、多くの条件を満たす必要がある意思決定システムを開発するという戦闘任務が与えられました。

既存のシステムがどのように機能し、運用中にどのような問題が発生するのか、開発されたプラットフォームが追求すべきビジネス目標は何かについて説明を受けました。 アナリストが作業するコードをできるだけ早く本番環境に導入できるように、システムはルールを開発して市場投入までの時間を短縮する必要があります。 そして、流入する申請の流れについては、意思決定にかかる時間を最小限に抑える必要があります。 また、開発中のシステムには、他社製品が当社によって承認され、クライアントの潜在的な関心がある場合に、クライアントに購入の機会を与えるために、クロスセル機能が必要です。

確実に本番環境に入る、すぐにリリースできるプロジェクトを一夜にして書くのは不可能であることは明らかであり、システム全体をカバーするのは非常に困難であるため、少なくとも一部を実装するように求められました。 プロトタイプが満たさなければならない多くの要件が確立されました。 すべての要件を全体的にカバーすることと、開発中のプラットフォームの個々のセクションに詳細に取り組むことの両方を試すことができました。

テクノロジーに関しては、すべての参加者に完全な選択の自由が与えられました。 データ ストリーミング、機械学習、イベント ソーシング、ビッグ データなど、あらゆる概念やテクノロジーを使用することが可能でした。

私たちのソリューション

少しブレインストーミングを行った結果、このタスクを完了するには FaaS ソリューションが理想的であると判断しました。

このソリューションでは、開発中の意思決定システムのルールを実装するための適切なサーバーレス フレームワークを見つける必要がありました。 Tinkoff はインフラストラクチャ管理に Kubernetes を積極的に使用しているため、Kubernetes に基づいた既製のソリューションをいくつか検討しました (これについては後ほど詳しく説明します)。

最も効果的なソリューションを見つけるために、私たちはユーザーの目を通して開発中の製品を調べました。 私たちのシステムの主なユーザーは、ルール開発に携わるアナリストです。 ルールは、その後の意思決定のためにサーバーに展開するか、この場合のようにクラウドに展開する必要があります。 アナリストの観点から見ると、ワークフローは次のようになります。

1. アナリストは、ウェアハウスからのデータに基づいてスクリプト、ルール、または ML モデルを作成します。 ハカソンの一環として、Mongodb を使用することにしましたが、ここではデータ ストレージ システムの選択は重要ではありません。
2. 開発したルールを履歴データでテストした後、アナリストはコードを管理パネルにアップロードします。
3. バージョン管理を確実にするために、すべてのコードは Git リポジトリに保存されます。
4. 管理パネルを通じて、コードを別の機能的なサーバーレス モジュールとしてクラウドにデプロイすることが可能になります。

クライアントからの初期データは、ウェアハウスからのデータで初期リクエストを強化するように設計された特殊な強化サービスを通過する必要があります。 統一されたデータ構造を維持するには、単一のリポジトリ (アナリストがルールを開発するときにそこからデータを取得します) と連携できる方法でこのサービスを実装することが重要でした。

ハカソンの前から、使用するサーバーレス フレームワークを決定しました。 現在、このアプローチを実装するテクノロジーが非常に多く市場に出ています。 Kubernetes アーキテクチャ内で最も人気のあるソリューションは、Fission、Open FaaS、および Kubeless です。 さえあります 説明と比較分析を含む優れた記事.

メリットとデメリットをすべて考慮した結果、私たちが選んだのは、 核分裂。 このサーバーレス フレームワークは管理が非常に簡単で、タスクの要件を満たしています。

Fission を使用するには、機能と環境という XNUMX つの基本概念を理解する必要があります。 関数は、Fission 環境が存在する言語の XNUMX つで書かれたコードです。 このフレームワーク内で実装される環境のリスト Python、JS、Go、JVM、その他多くの一般的な言語やテクノロジーが含まれます。

Fission は、アーカイブに事前にパッケージ化された複数のファイルに分割された機能を実行することもできます。 Kubernetes クラスターでの Fission の動作は、フレームワーク自体によって管理される特殊なポッドによって保証されます。 クラスター ポッドと対話するには、各関数に独自のルートを割り当てる必要があります。このルートには、POST リクエストの場合は GET パラメーターまたはリクエスト本文を渡すことができます。

その結果、エンジニアや開発者の参加なしに、アナリストが開発されたルール スクリプトを展開できるソリューションを取得することを計画しました。 説明されているアプローチにより、開発者がアナリスト コードを別の言語に書き直す必要もなくなります。 たとえば、現在使用している意思決定システムでは、高度に専門化されたテクノロジと言語でルールを作成する必要があり、その範囲は非常に限られており、また、すべての銀行規則草案はアプリケーション サーバーに強く依存しています。単一の環境にデプロイされます。 その結果、新しいルールを展開するには、システム全体をリリースする必要があります。

私たちが提案するソリューションでは、ルールをリリースする必要がなく、ボタンをクリックするだけでコードを簡単にデプロイできます。 また、Kubernetes のインフラストラクチャ管理を使用すると、負荷やスケーリングについて考える必要がなくなり、そのような問題はすぐに解決されます。 また、単一のデータ ウェアハウスを使用することで、リアルタイム データと履歴データを比較する必要がなくなり、アナリストの作業が簡素化されます。

得たもの

私たちは（空想の中で）既製のソリューションを持ってハッカソンに参加したため、私たちがしなければならなかったのは、すべての考えをコード行に変換することだけでした。

ハッカソンの成功の鍵は、準備とよく練られた計画です。 したがって、私たちが最初に行ったのは、システム アーキテクチャをどのようなモジュールで構成し、どのようなテクノロジを使用するかを決定することでした。

私たちのプロジェクトのアーキテクチャは次のとおりです。

この図は、アナリスト (システムの主なユーザー) とクライアントの XNUMX つのエントリ ポイントを示しています。

作業工程はこんな感じで構成されています。 アナリストは、モデルのルール関数とデータ エンリッチメント関数を開発し、コードを Git リポジトリに保存し、管理者アプリケーションを通じてモデルをクラウドにデプロイします。 デプロイされた関数がどのように呼び出され、クライアントからの受信リクエストを決定するかを検討してみましょう。

1. クライアントは Web サイト上のフォームに記入し、リクエストをコントローラーに送信します。 決定を下す必要があるアプリケーションはシステムに入力され、元の形式でデータベースに記録されます。
2. 次に、必要に応じて、生のリクエストがエンリッチのために送信されます。 外部サービスとストレージの両方からのデータで最初のリクエストを補足できます。 結果として得られる強化されたクエリもデータベースに保存されます。
3. アナリスト機能が起動され、強化されたクエリを入力として受け取り、ソリューションを生成します。ソリューションはストレージにも書き込まれます。

元のリクエストを含むエンリッチメント サービスが REST コントローラーを通じてすべてのデータを集約するため、JSON ドキュメントの形式でデータをドキュメント指向でストレージするため、システム内のストレージとして MongoDB を使用することにしました。

したがって、プラットフォームの実装には XNUMX 時間かかりました。 私たちは役割をうまく分散し、各チームメンバーがプロジェクト内で独自の責任領域を持っていました。

1. アナリストの作業用のフロントエンド管理パネル。これを使用して、記述されたスクリプトのバージョン管理システムからルールをダウンロードし、入力データを強化するためのオプションを選択し、ルール スクリプトをオンラインで編集できます。
2. フロント用の REST API および VCS との統合を含むバックエンド管理者。
3. Google Cloud にインフラストラクチャをセットアップし、ソースデータを強化するためのサービスを開発します。
4. その後のルールの展開のために、管理アプリケーションをサーバーレス フレームワークと統合するためのモジュール。
5. システム全体のパフォーマンスをテストし、最終的なデモンストレーションのために受信アプリケーション (決定) の分析を集約するためのルールのスクリプト。

順番に始めましょう。

私たちのフロントエンドは、バンキング UI キットを使用して Angular 7 で作成されました。 管理パネルの最終バージョンは次のようになります。

時間がほとんどなかったので、主要な機能のみを実装してみました。 Kubernetes クラスターに関数をデプロイするには、イベント (ルールをクラウドにデプロイする必要があるサービス) と、意思決定ロジックを実装する関数のコードを選択する必要がありました。 選択したサービスのルールを展開するたびに、このイベントのログが書き込まれました。 管理パネルでは、すべてのイベントのログを確認できます。

すべての関数コードはリモート Git リポジトリに保存されており、これも管理パネルで設定する必要がありました。 コードをバージョン管理するために、すべての関数がリポジトリの異なるブランチに保存されました。 管理パネルには、記述されたスクリプトを調整する機能も用意されているため、関数を運用環境にデプロイする前に、記述されたコードを確認するだけでなく、必要な変更を加えることができます。

ルール関数に加えて、エンリッチメント関数を使用してソース データを徐々に強化する機能も実装しました。そのコードは、データ ウェアハウスに移動し、サードパーティ サービスを呼び出し、予備計算を実行できるスクリプトでもありました。 。 私たちのソリューションを実証するために、リクエストを残したクライアントの星座を計算し、サードパーティの REST サービスを使用してその携帯電話会社を特定しました。

プラットフォームのバックエンドは Java で書かれ、Spring Boot アプリケーションとして実装されました。 当初は Postgres を使用して管理データを保存する予定でしたが、ハッカソンの一環として、時間を節約するために単純な H2 に限定することにしました。 バックエンドでは、クエリ エンリッチメント機能とルール スクリプトをバージョン管理するために Bitbucket との統合が実装されました。 リモート Git リポジトリとの統合には、 JGitライブラリこれは CLI コマンドの一種のラッパーであり、便利なソフトウェア インターフェイスを使用して git 命令を実行できます。 そのため、エンリッチメント関数とルール用に XNUMX つの別個のリポジトリを用意し、すべてのスクリプトをディレクトリに分割しました。 UI を通じて、リポジトリの任意のブランチのスクリプトの最新のコミットを選択することができました。 管理パネルからコードを変更すると、変更されたコードのコミットがリモート リポジトリに作成されます。

私たちのアイデアを実現するには、適切なインフラストラクチャが必要でした。 私たちは、Kubernetes クラスターをクラウドにデプロイすることにしました。 私たちが選んだのは Google Cloud Platform でした。 Fission サーバーレス フレームワークは Kubernetes クラスターにインストールされ、Gcloud にデプロイされました。 当初、ソース データ エンリッチメント サービスは、k8s クラスター内のポッドにラップされた別個の Java アプリケーションとして実装されました。 しかし、ハッカソンの途中でプロジェクトの予備的なデモンストレーションを行った後、受信アプリケーションの生データを強化する方法を選択する機会を提供するために、強化サービスをより柔軟にすることが推奨されました。 そしてエンリッチメントサービスもサーバーレスにするしかありませんでした。

Fission を使用するには、Fission CLI を使用しました。これは、Kubernetes CLI の上にインストールする必要があります。 k8s クラスターへの関数のデプロイは非常に簡単です。クラスター外部のアクセスが必要な場合に、内部ルートと関数へのイングレスを割り当てて、受信トラフィックを許可するだけです。 通常、10 つの機能のデプロイには XNUMX 秒もかかりません。

プロジェクトの最終プレゼンテーションと総括

私たちのシステムがどのように機能するかを示すために、銀行の商品のいずれかの申し込みを送信できる簡単なフォームをリモート サーバーに配置しました。 リクエストするには、イニシャル、生年月日、電話番号を入力する必要がありました。

クライアント フォームからのデータはコントローラーに送られ、利用可能なすべてのルールに対するリクエストが同時に送信され、指定された条件に従って事前にデータが強化され、共通ストレージに保存されます。 合計で、受信アプリケーションを決定する 4 つの機能と XNUMX つのデータ エンリッチメント サービスをデプロイしました。 申請書を提出した後、クライアントは次の決定を受け取りました。

クライアントは、拒否または承認に加えて、当社が並行して送信した他の製品のリストやリクエストも受け取りました。 このようにして、プラットフォームでのクロスセールの可能性を実証しました。

合計 3 つの架空の銀行商品が利用可能でした。

• クレジット。
• おもちゃ
• 抵当。

デモンストレーションでは、サービスごとに用意された機能とエンリッチメント スクリプトをデプロイしました。

各ルールには独自の入力データのセットが必要でした。 そこで、住宅ローンを承認するために、顧客の星座を計算し、これを太陰暦のロジックと結び付けました。 おもちゃの承認には顧客が成年に達しているかどうかを確認し、ローンを発行するには携帯電話会社を決定するためのリクエストを外部のオープンサービスに送信し、決定が行われました。

私たちはデモンストレーションを面白くインタラクティブなものにするよう努めました。参加者全員が私たちのフォームにアクセスして、架空のサービスが利用できるかどうかを確認できるようにしました。 そしてプレゼンテーションの最後には、受信した申請の分析をデモンストレーションし、何人がサービスを利用したか、承認数、拒否数を示しました。

オンラインで分析を収集するために、オープンソースの BI ツールを追加で導入しました メタベース そしてそれを保管ユニットにねじ込みました。 Metabase を使用すると、関心のあるデータを分析する画面を構築できます。データベースへの接続を登録し、テーブル (この場合は MongoDB を使用したためデータ コレクション) を選択し、関心のあるフィールドを指定するだけです。 。

その結果、意思決定プラットフォームの優れたプロトタイプが得られ、デモンストレーション中に各リスナーがそのパフォーマンスを個人的にチェックすることができました。 興味深いソリューション、完成したプロトタイプ、およびデモンストレーションの成功により、他のチームとの激しい競争にもかかわらず、当社は勝利することができました。 各チームのプロジェクトでもきっと面白い記事が書けると思います。

出所： habr.com