Kubernetes内でクラウドFaaSを実行し、Tinkoff Hackathonで優勝した方法

昨年から、当社ではハッカソンが組織され始めました。 最初のそのような競争は非常に成功した、私たちはそれについて記事に書いた。 2回目のハッカソンは2019年2月に開催され、成功を収めました。 主催者は最近、後者の目標について書いた 。



参加者には、実装に使用するテクノロジースタックを自由に選択できる、かなり興味深いタスクが与えられました。 顧客の採点機能を便利に展開するための決定プラットフォームを実装する必要がありました。これは、アプリケーションの高速フローで動作し、重い負荷に耐え、システム自体を簡単に拡張できました。



タスクは自明ではなく、参加者のプロジェクトの最終プレゼンテーションのデモンストレーションで見たように、多くの方法で解決できます。 ハッカソンには5人のチームが6つあり、すべての参加者が優れたプロジェクトを行いましたが、私たちのプラットフォームは最も競争力のあるものでした。 私たちは非常に興味深いプロジェクトを手に入れました。これについては、この記事で説明したいと思います。



当社のソリューションは、Kubernetes内のサーバーレスアーキテクチャに基づくプラットフォームです。これにより、新機能を本番環境に導入するのに必要な時間が短縮されます。 アナリストは、エンジニアや開発者が参加しなくても、自分に都合の良い環境でコードを記述し、製品に展開できます。

スコアリングとは何ですか？

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



たとえば、クライアントが私たちに彼にローンを与えるか、私たちとIPアカウントを開設するように頼みます。 私たちが彼にローンを与えることを計画しているなら、あなたは彼の支払能力を評価する必要があり、そして口座がプライベートエクイティであるなら、あなたはクライアントが不正な取引を行わないことを確かめる必要があります。



これらの決定は、アプリケーション自体のデータとストレージのデータの両方を分析する数学モデルに基づいています。 スコアリングに加えて、同様の統計的手法を使用して、顧客向けの新製品に関する個別の推奨事項を生成することもできます。



そのような評価の方法は、さまざまな入力データを受け取ることができます。 そして、ある時点で、入力に新しいパラメーターを追加できます。これは、履歴データの分析によれば、サービスの使用の変換を増加させます。



顧客との関係に関する多くのデータを保存しており、この情報の量は常に増え続けています。 スコアリングが機能するためには、データ処理にはルール（または数学モデル）も必要です。これにより、アプリケーションの承認者、拒否者、および潜在的な関心を評価するためにいくつかの製品を提供する人をすばやく決定できます。



このタスクでは、アナリスト、技術者、開発者が設定したルールに基づいて、特定の銀行商品をクライアントに承認するか拒否するかを決定する、専用のIBM WebSphere ILOG JRules BRMS意思決定システムを既に使用しています。



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

タスク

ハッカソンは2月23日に開催されました。 参加者には戦闘ミッションが提供されました。多くの条件を満たすための意思決定システムを開発することです。



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



ある夜には、確実に本番稼働するリリース可能なプロジェクトを作成することは不可能であり、システム全体をカバーするのは非常に難しいことは明らかであるため、少なくともその一部を実装するように求められました。 プロトタイプが満たす必要のある多くの要件が確立されました。 全体としてすべての要件を網羅し、開発されたプラットフォームの個々のセクションを詳細に検討することができます。



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

私たちの決定

短いブレインストーミングセッションの後、FaaSソリューションがタスクに理想的であると判断しました。



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



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

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

顧客からの初期データは、リポジトリからのデータで初期リクエストを強化するように設計された専用の強化サービスを通過する必要があります。 統一されたデータ構造を維持するために、単一のリポジトリ（分析者がルールの開発時にデータを取得するリポジトリ）で機能するような方法でこのサービスを実装することが重要でした。



ハッカソンの前でも、使用するサーバーレスフレームワークを決定しました。 今日、このアプローチを実装する市場にはかなりの数の技術があります。 最も人気のあるKubernetesアーキテクチャソリューションは、Fission、Open FaaS、およびKubelessです。 彼らの説明と比較分析の良い記事さえあります 。



すべての長所と短所を比較検討した後、 Fissionを選択しました。 このサーバーレスフレームワークは管理が非常に簡単で、タスクの要件を満たしています。



Fissionを使用するには、機能と環境という2つの基本概念を理解する必要があります。 関数（関数）は、核分裂環境（環境）がある言語の1つで書かれたコードです。 このフレームワークのフレームワーク内に実装された環境のリストには、Python、JS、Go、JVM、および他の多くの一般的な言語と技術が含まれます。



Fissionは、アーカイブにあらかじめパッケージ化されたいくつかのファイルに分割された機能を実行することもできます。 KubernetesクラスターのFission操作は、フレームワーク自体によって管理される特殊なポッドによって提供されます。 クラスターポッドとやり取りするには、各関数にルートを割り当てる必要があり、POST要求の場合は、GETパラメーターまたは要求本文を渡すことができます。



その結果、エンジニアや開発者の参加なしに、開発者が開発したルールスクリプトを展開できるソリューションを取得することを計画しました。 また、説明したアプローチにより、開発者が別の言語でアナリストのコードを書き換える必要がなくなります。 たとえば、現在使用している意思決定システムの場合、すべてのドラフトバンクルールが単一の環境に展開されているため、適用範囲が非常に限られている狭いプロファイルのテクノロジと言語でルールを記述する必要があります。また、アプリケーションサーバーへの依存度も高くなります。 その結果、新しいルールを展開するには、システム全体をリリースする必要があります。



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

何を得たの

（空想の）既製のソリューションでハッカソンに到着したので、すべての考えをコードの行に変換するだけです。



ハッカソンで成功するための鍵は、準備と適切な計画です。 したがって、まず、システムアーキテクチャを構成するモジュールと使用するテクノロジを決定しました。



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









この図は、アナリスト（システムのメインユーザー）とクライアントの2つのエントリポイントを示しています。



ワークプロセスはこのように構成されています。 アナリストは自分のモデルのルール関数とデータエンリッチメント関数を開発し、コードをGitリポジトリに保存し、管理者のアプリケーションを介してモデルをクラウドにデプロイします。 拡張された関数がどのように呼び出されるかを検討し、クライアントからの着信要求を決定します。

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

システムのストレージとして、JSONドキュメント形式のデータのドキュメント化されたストレージを考慮してMongoDBを使用することにしました。これは、初期リクエストを含むエンリッチメントサービスがRESTコントローラーを介してすべてのデータを集約したためです。



そのため、プラットフォームを実装する日がありました。 私たちは役割を非常にうまく分散し、各チームメンバーは私たちのプロジェクトで自分の責任範囲を持ちました：

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

順番に始めましょう。



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









あまり時間がないので、重要な機能のみを実装しようとしました。 Kubernetesクラスターに関数をデプロイするには、イベント（クラウドにルールをデプロイする必要があるサービス）を選択し、決定ロジックを実装する関数のコードをコーディングする必要がありました。 選択したサービスのルールの展開ごとに、このイベントのログを作成しました。 管理パネルでは、すべてのイベントのログを確認できます。



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









ルールの機能に加えて、エンリッチメント関数を使用してソースデータの段階的なエンリッチメントの可能性も実現しました。エンリッチメント関数のコードは、データウェアハウスに移動し、サードパーティサービスを呼び出し、予備計算を実行できるスクリプトで構成されていました。 ソリューションを実証するために、アプリケーションを離れたクライアントの星座を計算し、サードパーティのRESTサービスを使用してモバイルオペレーターを決定しました。



プラットフォームバックエンドはJavaで記述され、Spring Bootアプリケーションとして実装されました。 管理データを保存するために、もともとPostgresを使用する予定でしたが、ハッカソンの一環として、時間を節約するために単純なH2に制限することにしました。 Bitbucketとの統合は、クエリ強化機能とルールスクリプトをバージョン管理するために背面に実装されました。 リモートGitリポジトリーと統合するために、 JGitライブラリーが使用されました 。これは、便利なプログラム・インターフェースを使用してgit命令を実行できるCLIコマンドの一種のラッパーです。 したがって、機能とルールを強化するための2つの別個のリポジトリがあり、すべてのスクリプトはディレクトリに配置されています。 UIを介して、任意のリポジトリブランチの最後のコミットスクリプトを選択することができました。 管理パネルからコードを変更すると、変更されたコードのコミットがリモートリポジトリに作成されました。



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



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

プロジェクトの最終ショーと要約

システムの動作を実証するために、銀行の製品のいずれかを申請できる簡単なフォームをリモートサーバーに配置しました。 リクエストには、イニシャル、生年月日、電話番号を入力する必要がありました。



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









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



合計で、3つの発明された銀行商品が利用できました。

• クレジット
• おもちゃ
• 住宅ローン

各デモンストレーション中に、準備された機能と各サービスの強化スクリプトを展開しました。



各ルールには、独自の入力データのセットが必要でした。 そのため、住宅ローンを承認するために、顧客の星座を計算し、これを旧暦のロジックに関連付けました。 おもちゃを承認するために、クライアントが法定年齢であることを確認し、ローンを発行するために、モバイルオペレーターを決定するために外部のオープンサービスにリクエストを送信し、それについて決定しました。



私たちは、デモンストレーションを面白くインタラクティブにしようとしました。出席した全員がフォームにアクセスして、彼への架空のサービスの可用性を確認できました。 そして、プレゼンテーションの最後に、受け取ったアプリケーションの分析を実演し、私たちのサービスを使用した人数、承認数、拒否を示しました。



オンラインで分析を収集するために、 MetabaseオープンソースBIツールをさらにデプロイし、リポジトリにねじ込みました。 メタベースを使用すると、関心のあるデータに基づいた分析で画面を構築できます。データベースへの接続を登録し、テーブル（この場合はMongoDBを使用しているため、データコレクション）を選択し、関心のあるフィールドを指定するだけです。



その結果、意思決定プラットフォームの優れたプロトタイプを入手し、デモでは各リスナーがそのパフォーマンスを個人的にテストできました。 他のチームとの激しい競争にもかかわらず、興味深い解決策、既製のプロトタイプ、成功したデモンストレーションが勝利をもたらしました。 各チームのプロジェクトでは、興味深い記事を書くこともできます。