VTB の IT 部門は、システムの負荷が何倍にも増大する緊急事態に何度も対処しなければなりませんでした。 したがって、重要なシステムのピーク負荷を予測するモデルを開発してテストする必要がありました。 これを行うために、銀行の IT スペシャリストはモニタリングを設定し、データを分析し、予測を自動化する方法を学びました。 どのツールが負荷の予測に役立ったか、またそれらのツールが作業の最適化に役立ったかどうかについて、短い記事で説明します。
高負荷サービスに関する問題は、ほぼすべての業界で発生しますが、金融部門にとっては重大です。 X 時間には、すべての戦闘ユニットが準備が整っている必要があるため、何が起こるかを事前に把握し、負荷が急増する日とどのシステムがそれに遭遇するかを判断することさえ必要でした。 障害には対処し、防止する必要があるため、予測分析システムを導入する必要性については議論すらされませんでした。 監視データに基づいてシステムを最新化する必要がありました。
膝の上で分析を行う
給与計算プロジェクトは、失敗した場合に最も敏感なプロジェクトの XNUMX つです。 予測するのに最もわかりやすいので、これから始めることにしました。 接続性が高いため、負荷のピーク時にリモート バンキング サービス (RBS) などの他のサブシステムで問題が発生する可能性があります。 たとえば、入金のSMSを受け取って喜んだ顧客は、SMSを積極的に利用するようになりました。 負荷は一桁以上跳ね上がる可能性があります。
最初の予測モデルは手動で作成されました。 過去 1 年間のアップロードを取得し、最大ピークが予想される日 (たとえば、15 日、25 日、XNUMX 日、および月の末日) を計算しました。 このモデルは多大な人件費を必要とし、正確な予測を提供しませんでした。 それにもかかわらず、ハードウェアの追加が必要なボトルネックを特定し、アンカークライアントと合意することで送金プロセスを最適化することができました。給与を一度に支払わないように、異なる地域からのトランザクションは時間をかけて分散されました。 現在では、銀行の IT インフラストラクチャが失敗することなく「処理」できる部分に分けてそれらを処理しています。
最初の肯定的な結果を受け取った後、私たちは予測の自動化に移りましたが、さらに XNUMX の重要な領域が順番を待っていました。
統合アプローチ
VTB は、MicroFocus の監視システムを実装しています。 そこから、予測のためのデータ収集、ストレージ システム、レポート システムを導入しました。 実際、モニタリングはすでに導入されており、あとはメトリクスと予測モジュールを追加して、新しいレポートを作成するだけでした。 この決定は外部請負業者である Technoserv によってサポートされているため、プロジェクトの実装に関する主な作業はその専門家が担当しましたが、モデルは自分たちで構築しました。 この予測システムは、Facebook が開発したオープンソース製品である Prophet に基づいて作成されました。 使いやすく、インストールされている統合監視ツールや Vertica と簡単に統合できます。 大まかに言えば、システムは負荷グラフを分析し、フーリエ級数に基づいてそれを外挿します。 モデルから取得した特定の係数を日ごとに追加することもできます。 メトリクスは人間の介入なしで取得され、予測は週に XNUMX 回自動的に再計算され、新しいレポートが受信者に送信されます。
このアプローチでは、年次、月次、四半期、週次などの主要な周期性を特定します。 給与と前払いの支払い、休暇期間、休日、売上など、これらすべてがシステムへの呼び出し数に影響します。 たとえば、いくつかのサイクルが互いに重なり、システムの主な負荷 (75%) が中央連邦管区から来ていることが判明しました。 法人と個人は異なる行動をします。 「物理学者」からの負荷が曜日にわたって比較的均等に分散されている場合 (小規模なトランザクションが多数ある場合)、企業の場合、99,9% が労働時間に費やされ、トランザクションは短時間で完了するか、数日以内に処理できます。数分、あるいは数時間。
得られたデータに基づいて、長期的な傾向が決定されます。 新しいシステムにより、人々が一斉にリモート バンキング サービスに移行していることが明らかになりました。 このことは誰もが知っていますが、私たちはこれほどの規模になるとは予想しておらず、最初は信じていませんでした。銀行支店への電話の数は急速に減少しており、リモート取引の数もまったく同じだけ増加しています。 したがって、システムの負荷も増大しており、今後も増大し続けるでしょう。 現在、2020 年 3 月までの負荷を予測しています。 通常日は 10% の誤差で予測でき、ピーク日は XNUMX% の誤差で予測できます。 これは良い結果です。
落とし穴
いつものように、これには困難が伴いました。 フーリエ級数を使用した外挿メカニズムはゼロをうまくクロスしません。法人が週末に生成するトランザクションがほとんどないことはわかっていますが、予測モジュールはゼロから遠く離れた値を生成します。 強制的に矯正することも可能ですが、松葉杖は私たちの方法ではありません。 さらに、ソース システムからデータを簡単に取得するという問題も解決する必要がありました。 定期的な情報収集には大量のコンピューティング リソースが必要となるため、レプリケーションを使用して高速キャッシュを構築し、レプリカからビジネス データを受信します。 このような場合、マスター システムに追加の負荷がかからないことがブロッキング要件となります。
新たな課題
ピークを予測するという単純な課題は解決されました。今年 30 月以来、銀行では過負荷に関連した障害は発生しておらず、新しい予測システムがこれに重要な役割を果たしました。 はい、それだけでは不十分であることが判明しました。現在、銀行はピークが銀行にとってどれほど危険であるかを理解したいと考えています。 負荷テストのメトリクスを使用した予測が必要ですが、重要なシステムの約 XNUMX% についてはすでに機能しており、残りは予測を取得中です。 次の段階では、ビジネス トランザクションではなく、IT インフラストラクチャの観点からシステムの負荷を予測します。つまり、XNUMX つ下のレイヤーに進みます。 さらに、ダウンロードに対処しないように、指標の収集とそれに基づく予測の構築を完全に自動化する必要があります。 特別なことは何もありません。世界的なベスト プラクティスに沿ってモニタリングと負荷テストを横断しているだけです。
出所： habr.com