fbpx

【事例】顧客数400%増&ダウンタイム70%減(コロナ禍で急増したオンラインバンキングへのニーズに対応) #Mirantis #kubernetes #k8s #コンテナ #金融 #仮想化からコンテナ化へ #フィンテック

この記事は1年以上前に投稿されました。情報が古い可能性がありますので、ご注意ください。

本記事は、Mirantis Case Study(事例)「Mirantis helps Asian bank scale mobile banking for millions of customers during COVID-19 pandemic」を翻訳したものです。

会社概要

業種:商業および消費者向け金融機関
顧客数:数百万人
拠点:アジア

事業内容

数百万の顧客を有する、アジアを拠点とするある銀行は、その国でトップクラスの商業金融機関です。大半の国民にサービスを提供しており、国内で数百もの支店を展開し、モバイルバンキング、インターネットバンキング、デジタルアプリケーション、店頭端末など、多くのフィンテックをいち早く市場に導入した銀行でもあります。高い財務実績と信頼性で顧客から信頼されており、同銀行のサービスは多くの業界で賞を獲得しています。

急増する顧客のニーズ

世界中の多くの金融機関に見られるように、同銀行でも支店でのヒューマンエラーや、長い待ち時間の原因となる手作業を軽減するためDXに投資してきました。同銀行はデジタルバンキングサービスの導入に伴い、VMwareを使用してオンプレミスのデータセンターのベアメタル上に、モノリシックなバンキングアプリケーションを展開し始めました。しかし従来の仮想化では、急増する顧客のニーズに対応できるだけのスケーラビリティを確保できませんでした。さらに同銀行ではサービスのダウンタイムを短縮したいと考えていました。

「当行の伝統的なITインフラにおける難点は、増大する負荷に対応できないことでした」と述べるのは同銀行のDevOpsチームを率いる自動化担当の上級エンジニアです。「何百万もの顧客がアクセス可能なサービスを提供するには、非常に高い拡張性と可用性を備えたシステムが必要であり、この問題を解決する方法の1つがクラウドネイティブへの移行でした」と同氏は述べます。

エンタープライズ向けKubernetes

同銀行は複数のKubernetesベンダーとPOC(proof of concept)を実施し、MKE(Mirantis Kubernetes Engine/旧Docker Enterprise)がそのニーズに最も適しており、特にMirantis社の提供するエンタープライズサポートオプションは最適であると判断しました。MKEは環境を選ばず、クラウドネイティブアプリケーションを大規模にデプロイするための最速かつ最もシンプルな方法を提供する、エンタープライズ向けKubernetesプラットフォームです。同銀行はMKEを、ソース管理のためのAzure DevOps、ビルドの自動化のためのJenkins、セキュリティ分析と脆弱性スキャンのためのJFrogと統合しました。そしてすぐにレガシーアプリケーションのコンテナ化を開始し、マイクロサービスへと移行し始めました。

多くの組織に見られるように、仮想化からコンテナ化への移行は大きな文化的変化を伴うものでしたが、切迫したビジネスニーズに応えるため、経営陣は変化を受け入れることを余儀なくされました。

前述の上級エンジニアは言います。「ほとんどの役員は伝統的な思考を持っており、このように大きな変化を受け入れることには躊躇していました。しかし彼らを納得させたのは、予想される顧客数の急増と、それに伴って実際にすでに起きているダウンタイムという問題でした。従来のインフラストラクチャでは、急増する顧客のニーズに対応できないことは明らかでした。」

新型コロナウィルス感染拡大によって加速したデジタル化

同銀行がMKEを導入してから数か月後、新型コロナウイルスの感染拡大が始まりました。顧客は支店に直接足を運びづらくなり、モバイルサービスやオンラインサービスへのニーズが急増しました。政府がロックダウン規制を行う中、同銀行の開発チームはクラウドネイティブ技術の採用により、急変するニーズにも迅速に対応することができました。モバイルバンキングやインターネットバンキング、コールセンター、店頭端末の新サービスや新機能などをいち早く全国展開しました。また2021年にはデジタル戦略を見直し、すべてのビジネスプロセスのデジタル化を推し進め、数千台のATM、数百の簡易銀行、数百台の店頭端末などのネットワークの整備を成し遂げました。

コロナ禍で同銀行が直面した最も大きな困難は、政府が数百万人の国民に救済金を支給したときでした。支給日当日は、数千人の顧客が現金の引き出しに殺到し、トラフィックは平常時の300%に急増しました。しかしアプリケーションはすでにコンテナ化してありました。これによりピーク時のニーズに対応するためにリソースを迅速に拡張することができたのです。

「救済金の支給日はATMや支店に大行列ができ、インフラストラクチャには膨大な負荷がかかりましたが、無事対応できました」と前述の上級エンジニアは述べています。

「Kubernetesとコンテナを使えば、特定のサービスに通常より多くのリソースを必要とする場面でも、そのサービスに使用するリソースを増加させる一方で他のサービスを少ないリソースで済むように調整でき、インフラストラクチャ全体を安定させることができます」と同氏は付け加えます。

コロナ禍でもサービス提供を継続

同銀行ではすでにアプリケーションの約90%をコンテナ化し、IT部門全体でKubernetesを使用しています。現在ではMKE上で数百の共有マイクロサービスを持つ数十のアプリケーションを本番稼動させています。これには、送金、融資依頼、eコマース、クレジットカード/デビットカード取引などビジネスクリティカルなアプリケーションが含まれます。またコンテナの利用により、不正検知のための機械学習や小口融資の承認を自動化するなど、新しいユースケースも採用することが可能になりました。

仮想マシンでは、通常1~2週間に1度しかアプリケーションをデプロイできませんでした。今ではダウンタイムなしに毎日デプロイできる技術力を備えています。コンテナとKubernetesを導入して以来、同銀行がサポートするサービスは大幅に増え、顧客数は400%に激増したにもかかわらず、ダウンタイムは約70%削減に成功しています。

新規CTA