StrimziCon 2024からブラジルのネットバンクにおけるKafkaクラスター移行のセッションを紹介

StrimziCon 2024のセッションから、ブラジルの新興ネットバンク、Nubankのセッションを紹介する。Nubankは2013年に創業されて以来、ブラジル、コロンビア、メキシコなどで約1億人の加入者を集めて急成長を続けている。ネット専業のNubankの登場と合わせたようにブラジルの中央銀行が提供するP2Pの支払いプラットフォームであるPIXも拡がりを見せている。南米ではスマートフォンを活用した金融サービスのデジタルトランスフォーメーションの真っ只中ということだろう。その中心的存在であるNubankのエンジニアが、創業以来使い続けてきたKafkaの現状と未来を解説するセッションとなった。プレゼンテーションを行ったのはJulio Turolla氏とRoni Silva氏、どちらもNubankのシニアエンジニアだ。

Nubankのエンジニア、Julio Turolla氏（左）とRoni Silva氏（右）

セッションの動画は以下のURLから参照可能だ。

●動画：Modernizing Nubank's Kafka Platform For The Next 10 Years Starting at 1 Trillion Messages per Month

過去10年間のNubankでのKafkaについて解説するというセッション

Nubank自体の創業が2013年で、当時はクレジットカードのビジネスから始まったというが、銀行業にビジネスを拡大することは想定されていたのだろう。そのためには大規模な分散システムの構築が必須であろうし、そのためのプラットフォームとしてKafkaが選択されたのも必然だと思われる。

Nubank創業からのKafkaをシステム間コミュニケーションのプラットフォームとして利用

ブラジルで創業したNubankはメキシコ、コロンビアにもビジネスを拡大し、直近では約1億人の利用者がいることを解説。日本ではイーバンク改め楽天銀行が2000年創業、楽天に買収されてから成長しているとは言え、2021年の段階で約1000万口座であることを考えると、ブラジルの人口約2億人の半分に相当する口座数を10年余りで達成したというのは驚異的な成長と言えるだろう。

Nubankの利用者数の推移。2020年から急成長を遂げている

そしてブラジルで2019年から試験的に開始されたペイメントのためのシステムPIXによって、多くのトランザクションが発生したことをスライドで示した。

PIXの導入によって多くのトランザクションが発生

そしてPIX経由のトランザクションを処理するためのNubank側のシステムを支えているのがKafkaである。

PIXと接続されたNubankのKafkaクラスター

Kafka内部のメッセージも増大しており、約3500億のメッセージが処理されていることを週次の統計情報から紹介した。

Kafkaが処理するメッセージ数の推移。3500億を超えるメッセージ数

Kafkaクラスターについては国ごとに分離されているようで、Globalという共通部分とデータと称されるクラスターがあるのがわかる。そしてクラスターの中ではKafkaがシャーディングされて分割されていることを示している。

NubankのKafkaクラスター。ブラジル、メキシコ、コロンビアと国ごとに分かれている

システムの当初の形について解説するスライドを見ると、クラスター内の構造としてはインフラストラクチャーの管理にAWSのCloudFormation、EC2上で実行されるKafkaはDockerのコンテナの中で実装されていたようだ。

AWS上のインフラストラクチャーとKafkaの実装の概要

このスライドでは、拡大するメッセージの処理のためにAWS上のインフラストラクチャーの状態とKafka自体の状態を管理しながらオートスケーリングを使いたかったという意図があったようだ。しかし実際にはそれが連係されておらず、ソフトウェア全体のライフサイクル管理が上手くいっていなかったことを説明した。

クラスター数が少なければブルーグリーンデプロイも可能だが数が増えると管理は困難に

そして単にメッセージの増大に合わせてインスタンス数を増やすと、結果としてコストも増えてしまうのと同時に実際にはNubankが必要としているスケールアウトの速度を実現できないと語った。

クラスターの数とコストは比例してしまう

より詳細にシャーディングによるリバランスについて解説したスライドでは、PIXのトランザクションが新しいブローカーにリバランスされる場合の処理時間とその他のトランザクションの場合では1時間から7日という大きな差があることを説明。またこの状況に関する追加の問題として、ノイジーネイバーによってレイテンシー問題が大きく影響していることを示している。

リバランスに多くの時間がかかっていたことを示すスライド

これらの問題を解決するための選択肢として挙げられたマイグレーションに関するオプションを解説。ここではKafkaをセルフホストする、パブリッククラウドのサービスを使う、Kafkaのホスティングをしている会社を選択する、Kafka以外のメッセージングシステムを使うなどが挙げられている。最後にIBMのMQが代替案として挙げられているが、これは検討に値しないジョークという扱いだった。

増大するKafkaの負担を減らすための選択肢。セルフホストからIBMのMQまで

Nubankが要求する仕様としては金融業であるために法規制が当然存在するが、それ以外にもセキュリティ関連の仕様も現代の社会では必須となる。それらの仕様を満足させるために最適だったのはセルフホストという選択だ。

セルフホストでKafkaをリニューアルする選択

これによってセキュリティに関する仕様も満足でき、パブリッククラウドや専業のホスティング会社に依存することなく柔軟なインフラストラクチャーを構築できると説明した。

そしてその柔軟性を維持するためにKubernetesは必須として、その運用のためにStrimziを選択したと語った。

その他のオペレータと比較してStrimziを選択

ここではCRD（Custom Resource Definitions）が安定していること、AWSのブロックストレージのサポート、障害時の自動復旧のシナリオが用意されていることなどを挙げている。またCNCFが支援しているコミュニティであるということも、ポイントとしては大きいと思われる。Strimziの競合として比較したソフトウェアの名前は明らかにされていないが、Canonicalが開発するオペレータなどが存在している。

●参考：Strimziの競合となるオペレータ：https://github.com/canonical/kafka-k8s-operator

他にもCiscoが2021年に買収したBanzai Cloudのオペレータも公開されている。

●参考：https://github.com/banzaicloud/koperator

リバランス問題を解決するための選択肢

増大するリバランスのための処理時間を解決するために挙げられた解決策について解説しているスライドでは、Mirror Maker v2、Fusing ClusterそしてConcurrent Clusterという3つの選択肢を挙げている。

Mirror Makerについては、Red HatのDeveloperサイトに詳細な説明があるのでそれを参考にして欲しい。

●参考：Demystifying Kafka MirrorMaker 2: Use cases and architecture

3つの中からNubankとしてはConcurrent Clusterという方式を採用したことが説明された。その後に新旧のクラスター間でリバランスを行う手順が解説された。

新旧のクラスター間でリバランスを行う手順の一部

Nubankが利用するKafkaには50を超えるクラスターに16万を超えるトピックが存在し、パーティションのレプリカが350万超、データストアとしては2ペタバイトを超える容量になるという。それをマイグレーションするために一日平均1000のトピックを対象にマイグレーションを行ったと説明。

その結果をまとめたのが次のスライドだ。

マイグレーションのまとめ。クラスターの作成は1時間で完了

マイグレーションの結果、インスタンスを削除するのが苦労ではなくなり、クラスターの作成も1週間から1時間に短縮、Kafkaも最新バージョンを使えるようになり、またGitOpsの導入など多くの改善点を得られたと解説した。新しいセルフホストのKafkaはAWSで実装されているが、毎年倍のスピードで拡大するNubankとPIXのメッセージ処理をスケーラブルに行っていると説明。

未来に関するスライド。KRaftを既に実装中

最後のスライドでNubankのKafkaの未来について解説を行った。ここではStrimzi、EKS、Kafkaのアップデートに対応できるようになったこと、リバランスはオペレータで実施すること、トピックの管理もオペレータによって管理すること、ZooKeeperではなくKRaftを使うこと、安価で階層型のストレージを使うことなどが挙げられている。

全体としてKafkaのヘビーユーザーがレガシーなKafkaの実装からよりクラウドネイティブなKafkaに移行した際の要点をまとめたセッションとなった。ZooKeeperを使わないKRaftモードも視野に入れて、これからもKubernetesとKafkaを使って金融サービスのデジタルトランスフォーメーションを進めていく意図が見えた内容となった。日本の金融業界も、これまでのしがらみを一度捨ててスマートフォンを最大限に活用した金融システムをオープンソースでゼロから共同開発したらどうなるのか、実験としてやってみて欲しいと感じさせられた。