Whitepaper
12
minutes

Robin Zhang(北米担当マーケティングディレクター)

Brian Dempsey(北米担当パートナーシップディレクター)

Fabian Siddiqi(クラウドエンジニアリングディレクター)

September 1, 2021

クラウドネイティブなコアバンキングの真実

クラウドコンピューティングの利点を最大限に活用するには、コアシステムをクラウド上で、かつクラウドのために構築する必要があります。

クラウド技術の進歩、急速に変化する顧客の期待、そして競争の激化が従来の銀行モデルに圧力をかけており、銀行業界は激動の時代を迎えています。

一方で、金融取引をオンラインで行う顧客はますます増えており、パンデミックによってこの傾向はさらに加速しました。銀行利用におけるこの世代交代は、あらゆるチャネルとサービスに影響を及ぼしています。実店舗、オンライン、モバイル、リテール、そして法人向け銀行サービスに至るまで、競争が激化する環境下で成果を出し、革新を続けることが求められています。消費者の行動における根本的な変化が、銀行の商品やサービスに対する新たな期待を生み出しています。顧客は、使いやすさ、24時間365日の可用性、リアルタイムのデータと分析、卓越したカスタマーサポート、すべての銀行商品に対する完全な可視性などを求めているのです。

本ホワイトペーパーシリーズの第1弾、 銀行を変革し、コアを変革するにおいて、私たちはデジタル時代を生き抜き、競争力を維持するために銀行は直ちに行動を起こさなければならないという結論を導き出しました。未来を切り拓くための重要なステップは、コアバンキングシステムをクラウドへ移行することです。

続く第2弾では、クラウドネイティブ技術の主要な構成要素とその利点であるスケーラビリティ、柔軟性、可用性、弾力性などについて解説します。これらの利点を最大限に活用するには、コアバンキングシステムをクラウド上で、かつクラウドのために構築する必要があります。これは多くのテクノロジー企業によって「クラウドネイティブ」と呼ばれています。

クラウドネイティブとは何か?

クラウドネイティブ技術は、パブリッククラウド、プライベートクラウド、ハイブリッドクラウドといった現代的で動的な環境において、スケーラブルなアプリケーションを構築・実行する力を組織に与えます。コンテナ、サービスメッシュ、マイクロサービス、イミュータブル(不変)インフラストラクチャ、宣言型APIは、このアプローチを体現するものです。

これらの技術により、回復力があり、管理しやすく、可観測性に優れた疎結合なシステムが実現します。堅牢な自動化と組み合わせることで、エンジニアは最小限の労力で、頻繁かつ予測可能な形でインパクトの大きい変更を加えることが可能になります。

出典:Cloud Native Computing Foundation (CNCF)

CNCFの定義にある通り、クラウドネイティブシステムはスピードと俊敏性、そして多様なクラウド環境で実行できる柔軟性を提供します。これらの利点を享受するためには、クラウドネイティブなコアバンキングシステムを構築する際、イミュータブルインフラストラクチャ、マイクロサービスアーキテクチャ、コンテナ化といった主要な機能を念頭に置く必要があります。

イミュータブルインフラストラクチャ

イミュータブルインフラストラクチャでは、各アプリケーションインスタンスが仮想マシンまたはコンテナとして機能します。スケーラビリティは自動化によって実現され、インスタンスはオンデマンドで作成され、不要になると破棄されます。いずれかのインスタンスが機能しなくなった場合は、自動的に新しいインスタンスがプロビジョニングされ、置き換えられます。

クラウドネイティブシステムはイミュータブルインフラストラクチャを採用しており、自動スケーリング、自己修復、ゼロダウンタイムを実現します。顧客が24時間365日のアクセスと取引データのリアルタイム同期を求める現代の銀行業務において、これらの機能は不可欠です。

マイクロサービスアーキテクチャ

マイクロサービスベースのアーキテクチャは、クラウドコンピューティングの基盤です。Amazonはマイクロサービスを次のように定義しています。「マイクロサービスアーキテクチャでは、アプリケーションは独立したコンポーネントとして構築され、各アプリケーションプロセスをサービスとして実行します。これらのサービスは、軽量なAPIを使用した明確に定義されたインターフェースを介して通信します。サービスはビジネス機能に基づいて構築され、各サービスは単一の機能を実行します。独立して実行されるため、各サービスはアプリケーションの特定の機能に対する需要に合わせて更新、デプロイ、スケーリングが可能です。」

マイクロサービスベースのアーキテクチャで構築された基幹系システムは、モノリシックなレガシーシステムの硬直性から銀行を解放します。レガシーシステムでは、システムを少し更新するだけでも長いソフトウェア開発サイクルや耐え難いダウンタイムが発生し、莫大なコストがかかる可能性がありました。

マイクロサービスを中心に構築されたシステムでは、ソフトウェアは相互運用および通信を行う機能コンポーネントの集合体で構成されます。各マイクロサービスは特定のビジネス要件に対応し、独立して実行可能です。これらが組み合わさることで、現代の銀行業務のニーズを満たすために不可欠な柔軟性、相互運用性、移植性を備えた基盤システムが形成されます。

コンテナ化

CNCFは、クラウドネイティブへの取り組みを開始する企業向けのガイドである「Cloud-Native Trail Map」の第一歩として、マイクロサービスのコンテナ化を挙げています。

コンテナは、クラウドネイティブソフトウェアを実現する強力なツールです。

Cornelia David
クラウドネイティブパターン

コンテナは、マイクロサービスとその実行に必要な依存関係をパッケージ化するために使用されます。その目的は、移植性と一貫性を提供し、マイクロサービスがプラットフォームに依存せず、あらゆる基盤インフラストラクチャ上で機能できるようにすることです。また、コンテナ化は、ランタイム環境の設定コストを排除し、オペレーティングシステムやホストリソースを共有することで、コストとリソースの効率化を実現します。

コンテナの管理と実行にはコンテナオーケストレーターが必要であり、その中で最も普及しているのがKubernetesです。コンテナオーケストレーションは、スケーラビリティと移植性を提供する上で重要な役割を果たします。

サービスメッシュ

クラウド上でマイクロサービスアーキテクチャを実行する場合、多数のデプロイされたコンテナ間のネットワーク管理が複雑な課題となります。解決すべき一般的な問題には、以下のようなものがあります。

  • 冪等性のあるリクエストの自動再試行機能
  • パフォーマンス向上のためのマイクロサービス間の持続的な接続の確立
  • トラフィックシェーピングおよびリクエストのスロットリング
  • TLSによるセキュアな接続の確立と自動証明書ローテーション

アプリケーションレベルでこれらの課題に対処するのは煩雑でミスも起こりやすく、特に複数のプログラミング言語を使用している場合には困難です。そこで登場するのがサービスメッシュです。サービスメッシュは、クラスター内のマイクロサービス間に、より高度なネットワークトポロジーを構築します。これにより、開発者はネットワークの分断や、複数のバックエンドにわたる加重負荷分散といった一般的なシナリオを個別に考慮する必要から解放されます。

CNCFプロジェクトであるIstioサービスメッシュは、Kubernetesデプロイメントにサイドカーを付加することで、言語に依存しない方法でコンテナ化されたアプリケーションをサービスメッシュの一部に組み込むことを可能にします。

API通信

マイクロサービスは疎結合で自己完結しているため、相互の通信にはAPIが不可欠です。マイクロサービスの新しい世界では、従来の命令型アプローチに代わり、宣言型アプローチを採用するAPIが増えています。命令型APIが手順を追って指示を出すのに対し、宣言型APIは最終的な結果に焦点を当て、そこに至るまでのプロセスはマイクロサービス側に任せるため、現在主流となっています。

宣言型APIを実装するために、開発者はRESTを採用するケースが増えています。RESTはAPI開発における一連のアーキテクチャ制約です。RESTful APIは標準化されたステートレスなアーキテクチャを提供し、マイクロサービスの統合や自動化を容易にします。

クラウドネイティブ環境の課題

規模の拡大と弾力性の管理には課題が伴います。クラウドネイティブシステムはAPIを通じてサービスを公開し、コンテナを活用するため、銀行は「Infrastructure as Code(コードとしてのインフラ)」という概念を採用しています。これにより、インフラのトポロジーを単純なスクリプトとしてコード化し、必要な時にいつでも実行できるようになります。コードの要素を少し変更するだけで、実質的に無限の同一インフラを即座にプロビジョニング可能です。しかし、インフラごとにプロビジョニングモデルが異なるという問題があります。銀行は、各クラウドプロバイダー独自の機能を活用しつつ、インフラの種類を問わず一貫したプロビジョニングワークフローを実現する戦略を策定しなければなりません。

多くの組織が直面するもう一つの問題は、すべての資産を把握することです。これはマルチクラウド環境で特に深刻化します。サービスが異種混在しており、管理を一元化する単一のインターフェースが存在せず、さらにInfrastructure as Codeによって社内のあらゆるエンジニアが容易にデプロイできてしまうためです。

前述の2つの課題は、エフェメラル(一時的)なコンピューティング環境に共通するものです。最終的に銀行は、利用しているクラウドプロバイダーに関係なく、エンタープライズシステムにデプロイされているすべての資産を検出し、識別、分類、可視化する手段を必要としています。そのためには、クラウドネイティブシステムにおいて、インフラ資産とその関係性をデータベースに統合し、直感的なグラフィカルユーザーインターフェースで管理できる機能が不可欠です。

結論

クラウドネイティブは、コアシステムを含む次世代システムにとって避けては通れない道です。これには慎重な計画が必要であり、レガシー技術からクラウドネイティブ技術への移行を単なる「リフト&シフト」として扱うことはできません。クラウドコンピューティングの利点を最大限に活用するには、コアバンキングシステムをクラウドコンピューティングのあらゆる特性を考慮して構築する必要があります。

強固な基盤さえ築けば、可能性は無限に広がります。クラウドネイティブなコアシステムを導入することで、銀行はコストをより適切に管理し、顧客や規制当局の要求にこれまで以上に効果的に対応できるようになります。