KubeCon North America 2024から、P2P決済のCash Appがマルチクラスター実装を解説するセッションを紹介

KubeCon＋CloudNativeCon North America 2024から、P2P決済のCash Appが解説したマルチクラスター実装のセッションを紹介する。プレゼンテーションを行ったのはCash Appの開発元であるBlockのプラットフォームエンジニア、Rachel Sheikh氏だ。

プレゼンテーションを行うRachel Sheikh氏

Cash Appは個人間の送金やQRコードによる決済などを行うアプリケーションで、決済サービスのBlockが開発を行っている。Blockは2021年にSquareが社名を変更した後の名称だ。セッションの動画は以下のURLから参照して欲しい。

●動画：Cash App's Journey Into a Multi-Cluster Ecosystem

Cash AppのプラットフォームはKubernetesであり、マルチクラスターに移行する前は6つのクラスター、4600ノード、49000コアという規模だったものが、マルチクラスターに移行後は12クラスター、4000ノード、55000コアという規模になっている。サービスの数は変わらないもののユーザーの増加に従って規模が拡大していることがわかる。

マルチクラスターに移行前と移行後のプラットフォームの規模を説明

Cash Appのユーザー数は2022年時点では5100万、2023年に5500万、2024年には5700万という数値で推移しており、ほぼすべてのユーザーが北米をベースにしているという状況である。Cash Appがマルチクラスターに移行を決定した要因について解説したスライドでは、単一障害点の排除などが挙げられている。

Cash Appがマルチクラスターに移行した背景

個々のサービスが各々のクラスターを使うという構成ではどうしても単一障害点が発生してしまい、プラットフォームとしての耐障害性が損なわれるというのが大きな要因として書かれているが、リソースの有効活用という観点でもマルチクラスターにしてノードのリソースを有効活用したいという発想になるのは、Cash Appが主にAWSを利用していることにも関係しているだろう。またSquareのデータセンターも使っていることがこの後のスライドでも明らかにされている。

マルチクラスター実装のチャレンジとは

ここではマルチクラスター実装に対して解決しなければいけない問題点を列挙している。特に運用のために複数のクラスターで利用されるクレデンシャルの管理などに加えて、AWSとSquareのデータセンターに対するネットワークトラフィックの分配やクラスターの規模が増えても運用のコストを増やさないなどが挙げられている。

マルチクラスターの構成をどうするのか？ に関する考察

そしてマルチクラスターの構成に関してはいくつかのアイデアを検討したとしてその例を説明。ここではアプリケーションの重要性に応じて階層（Tier）を設定し、その階層ごとに必要とする稼働率を設定してリソースを割り当てるというものだ。他にもリージョンごとのAvailability Zoneにクラスターを割り当てる方法などを紹介した。

マルチクラスターのためのツール群とは

マルチクラスターを実装するためには、単一のクラスターでは必要のなかったツールも必要になるとして、KarpenterやIstio、KEDAなどを挙げていた。KarpenterはAWSが開発し、オープンソースとして公開しているクラスターのノードリソースを有効活用するためのプロビジョニングツールだ。

ツールが果たす役割について解説

そしてマルチクラスターにおいて必要な機能について解説。バッチで実行されるミラーリングや監視のためのツールなどが紹介された。最後に記されているExternal Secrets Operatorは、Kubernetesのカスタムリソースを使って外部のシークレット管理のツール（Vaultなど）を統合するためのツールだ。

●参考：External Secrets Operator

IstioのVirtualServiceを使ってクラスター間のトラフィック分配を実施

複数のクラスターへのトラフィックの分配にはIstioが使われており、クラスターごとに重み（Weight）を設定することでトラフィック管理がシンプルになったと説明。さまざまな監視のためのメトリクスも取得できるようになったと語った。IstioをPod間のサービスメッシュではなくクラスター間のトラフィック分配のツールとして使っているというのが興味深い。

クラスターのTierに関する解説

このスライドではアプリケーションの重要性に応じたクラスターのTier分けが設定されていることを解説。重要度に応じた稼働率が設定されることを説明した。Tier1と2が主なボリュームを占め、Tier0とTier3が少数となるというベルカーブに従った正規分布の形でクラスターが構成されることが理想であると説明した。モニタリングにおいてもTierごとに必要な要件の設定が行われているというのも興味深い。重要なアプリケーションが稼働するクラスターは、より細かなモニタリングが必要となると言うことだろう。

マイグレーションをゼロダウンタイムで実施するための考察

単一クラスターからマルチクラスターに移行する際に、クラスターをダウンさせずに行うためにサービスのオーナーとの十分なコミュニケーションが必須であることを指摘。ツールの観点からはKeda、Kuberhealthy、Kyvernoなどについても触れた。KuberhealthyはKubernetesのオペレータでクラスターが定義した通りに稼働しているかを監視し、Prometheusにメトリクスとして送信するツールだ。

●参考：Kuberhealthy

スライドではクラスター内のトラフィックのヘルスモニタリングがスクリーンショットとして掲載されている。

マルチクラスター移行に関する問題点

このスライドでは移行において発生した問題点について考察。ツールの整合性や移行時のクラスターの状況の監視、特殊なアプリケーションやサービスに対する対応などを挙げている。

移行におけるコストについても考察

Cash Appが主にAWSを使って実装されていることを考えると、クラスターのコストを削減したいと思うのは当然だろう。ここでは移行時においてコストをどう考えるかを解説している。それぞれのポイントはCash App固有の要因だろうが、どのような日程で行うのか、ビジネス上の必要性などを考えて行うべきだという当然の結論だろう。

移行後のクラスターのスケールダウンに関する解説

前のスライドで移行時にはクラスターの稼働率を意図して100％に近づけることを説明しているが、移行後はそれをどのようにスケールダウンさせるか？ というポイントについて解説をしている。オートスケーリングのツールの構成情報からレプリカの数を調整し、トラフィックの分配を変更することなどがリストアップされている。特にオープンソースのツールであるKarpenterとVirtical Pod Autoscaler（VPA）についても触れ、公開されているツールを活用してスケールダウンを実施したことを解説した。

プラットフォームエンジニアとアプリケーションエンジニアの違い

Sheikh氏はプラットフォームエンジニアとしてCash Appの実装を行っているが、それぞれのエンジニアが重要と考えるポイントが異なることを説明。プラットフォームエンジニアとしてはコストと自動化に注力していることがわかる。アプリケーションエンジニアにとっては難解なKubernetesを抽象化すること、実装を簡単にすることなどが要点だと説明。

プロダクト（サービス）をシンプルにするためのポイントを整理

プラットフォームエンジニアの観点からサービス実装をシンプルにするためには定常的なコミュニケーションが必須であることを強調。バッチツールが重要というのも自動化と合わせて考えるべきポイントだろう。

プラットフォームエンジニアとしての重要なポイントを整理

プラットフォーム側のポイントはインフラストラクチャー実装のフローが整備されていること、インフラストラクチャー自体のバックアップが可能であること、そして新規のクラスターを実装するための時間を短縮することなどが挙げられている。興味深いのは最後のポイントにカオスエンジニアリングのゲームデイの要素が盛り込まれていることだ。AWSが最初に考案したChaos MonkeyやAWSのFault Injection Simulator（FIS）などが挙げられている。ここではAWSの耐障害性を挙げるために必須な要点ということだろう。

クラスター運用に関する将来的な構想

マルチクラスター運用についてはクラスターをゼロから1、1からゼロにする変更に関してCrossplaneの利用を検討していること、クラスター管理におけるバッチツールの利用、クラスターに利用されるオペレータのテストのためにKyvernoのサブプロジェクトであるChainsawの利用を検討していることなどを説明した。またKuberhealthyの利用も拡大する予定だという。この辺りのツールは、マルチクラスターを検討しているエンジニアであればチェックしておくべきだろう。

カオスエンジニアリングのゲームデイについて説明

カオスエンジニアリングのゲームデイに関するスライドでは、AWSのFault Injection Simulator（FIS）を使ってクラスターをゼロから立ち上げるために必要な時間を短縮することを計画していることを説明。何を自動化すべきか、どの程度のマニュアル操作が必要かなどの点を、検討すべき点として挙げている。

全体としてCash Appがマルチクラスター移行を行った概要とツールなどについての考察が盛り込まれたセッションで、これからマルチクラスターへの移行を検討しているエンジニアにとっては有益な内容となっているといえる。カオスエンジニアリングについても、クラスター運用に関する要な要点として挙げられていることも注目すべきだろう。