UPSIDERのアプリケーションを支える、高セキュリティ・高可用・高スケーラブルなプラットフォーム #CNDW2024 イベントレポート

こんにちは！UPSIDERでHRをしていますNarisaです。 VP of Engineering 泉が『CloudNative Days Winter 2024』に登壇しましたので、イベントレポートをまとめます！

CloudNative Daysとは

CloudNative Daysは、クラウドネイティブ技術に関心を持つ開発者を対象としたカンファレンスです。毎年、シーズンやエリアを変えて、複数回にわたり開催されることで、最新技術の共有やコミュニティの活性化を目的としています。

本イベントは「クラウドネイティブ技術の普及と活用促進」をテーマに掲げ、Kubernetes、マイクロサービス、DevOps、Observabilityなど、クラウドネイティブに関連する多様なトピックが取り上げられます。

基調講演や技術セッションに加え、実務的なハンズオンやネットワーキングの機会も用意されており、参加者が実践的な知識を深められる場となっています。

UPSIDERのアプリケーションを支える、高セキュリティ・高可用・高スケーラブルなプラットフォーム

『CloudNative Days Winter 2024』（以下CNDW2024）のテーマは、”小さな一歩、大きな飛躍〜クラウドネイティブを継続する〜” でした。

”小さな一歩、大きな飛躍〜クラウドネイティブを継続する〜” とは

クラウドネイティブをこれから始める人、今まさに取り組んでいる人、一定の成果を達成して次のステップに迷っている人、CloudNative Daysには様々な人が集まります。

エンジニアも組織も、そしてシステムもクラウドネイティブから実りを得るには、一度きりではなく、学びと改善を何度も繰り返す継続的な取り組みが重要です。

小さな一歩を踏み出すのをためらわないでください。小さくても歩みを止めないでください。

継続することをやめなければ、変化と経験の蓄積がやがて大きな飛躍をもたらします。そしてコミュニティが知見とモチベーションの交換を通してあなたの一歩を後押しします。

CloudNative Daysは、クラウドネイティブへの小さな一歩を踏み出し、大きな飛躍へと前進するエンジニアと共に歩んでいきます。

出典：イベント当日スライドより引用

CNDW2024は2日間にわたり、TrackA〜Dと4つのエリアで登壇が披露されていました。イベントブースも多く出展し、懇親会やLTイベントも開催されるなど、とても盛り上がっていました！

2日間の様子がまとめられていますので、ぜひこちらをご覧ください。 https://togetter.com/li/2471982 https://togetter.com/li/2471983

UPSIDERが登壇した際のまとめは以下にまとめていただいています。 https://togetter.com/li/2471984?page=6#h135_0

CNDW2024のテーマをもとに、UPSIDERのVPoE泉は「UPSIDERのアプリケーションを支える、高セキュリティ・高可用・高スケーラブルなプラットフォーム」をテーマに登壇しました。

speakerdeck.com

登壇した資料を掲載しつつ、当日に口頭でお話しした内容の一部をご紹介します。

What’s Happening in Financial Systems around the world!?

泉：他領域に比べると「金融」って「地味な領域」「堅い領域」と思われがちですが、実際、主に台帳管理に使われる「メインフレーム」と呼ばれる基幹システムはカスタムのプロセサーを利用した基盤に独自のSystem/360や、zSystemと呼ばれるOSを搭載して、COBOLをベースにアプリケーションが書かれるようなアーキテクチャーが主流です。いまも多くの銀行やカード会社など、いわゆる「取引台帳」を業務の中心に置く会社ではまだぜんぜん現役のシステムです。

泉：なぜこれらのシステムが現役のシステムなのかというと、金融において最も重要な情報資産は「残高」と「取引履歴」です。これらは絶対に破損できないデータです。その正確性が絶対担保されないと、金融システムそのものが破綻します。（入金したのに残高が変わらなかったら、その瞬間に信用なくなりますよね？）

（特筆するまででもないですが）金融取引は、シンプルにいうと取引のINSERTと、残高のUPDATEを常にアトミックな処理で行う必要があります。

泉：例えばクレジットカードだと、100万円の与信がある会社が、20万円の決済をおこなったとします。すると20万のINSERTをするとともに、Balanceである100万を80万にするというアップデート処理を必ず一つの切り離せない処理にする必要があります。

泉：エンジニアの皆さんは多分「あーなんだ、そんなのTransactionをしかけりゃいいだけの話じゃないか」と思うかもしれませんが、それは今の話しで、昔はハードウェアの故障や磁気ストレージの外界からの電磁波からの影響、あるいは電源さえ不安定な時代なので、その背景を考えるとこの処理を確実に、しかも大規模に行う、ということが如何に大変だったか、少しご理解いただけるのではないかと思います。

メインフレームの筐体自体が日本においては、免震フロアに設置されないといけない、とか含めとんでもなく大変なことでした。（この対策が当時の強固な安全性を担保したシステムの実現であり、この構造を作った先人たちをリスペクトしています！）

泉：一方でこの10年くらいで、海外でもBREXやRampなど、スタートアップ企業がOSSやクラウドネイティブなテクノロジーを駆使して、独自に決済システムを作っています。ブラジルのNubankはカードではないですが銀行システムを基本Cloud-Native Technologyで実現しており、Clojureでマイクロサービスを作ったり、パーシステンスにはDatomicやCockroachDB等を利用して非常にResilientでスケーラブルなアーキテクチャーを実現しています。

しかもこれがメインフレームの初期導入コストに比べると100分の1とはいかないものの、10分の1くらいのコストで実現できていることは非常にすごいことです。

このように金融領域にもかなりCloud Native Technologyが広がっている、ということを頭の片隅において、UPSIDERが実際どういう仕組みを作っているのかをご紹介したいと思います。

金融システムに求められるScalability, Security, Resiliencyの実体

泉：システムの全体像からご紹介します。これでもまだシンプルにしたのですが、少し細かいですね。

まずUPSIDERのシステムは主に大きく２つの機能がある、と見ていただければ良いかなと思います。

一つは、「決済領域」で加盟店からVISAのネットワークを経由して入ってくる決済電文の処理を行う領域と、「管理業務領域」でカードの発行や失効、あるいは会員情報や請求回収などのカードにまつわる情報や取引の管理を行う領域が別々に分かれています。

参考：プロダクトの性質から考えるシステムと組織のアーキテクチャー

それぞれThemisとChronosと呼んでいますが、決済領域をThemis、管理領域をChronosと呼んでおります。今、Node数でいうと130、Workloadの数でいうと現在500近い規模のマイクロサービスアーキテクチャになっております。

泉：例えば交際費の支払いで飲食店でカード決済をするとします。するとその瞬間、加盟店の端末からVISAのネットワークを通じて、最終的にUPSIDERのGCP上のネットワークにメッセージが入ってきます。いわゆる「オーソリ」と呼ばれる電文です。その処理を行うのがこのThemisという決済領域になります。

文字にするとシンプルに見えますが、このオーソリ電文を受け取ると、我々のシステムの中でまず電文のカテゴリーを調べ、どのコンポーネントにその処理を任せればよいか、という分岐が行われます。

その後、

カード番号が有効なものであるのか？
これから行う決済は利用可能額の範囲に収まるのか？
カード自体の不正利用ではないのか？*1

の確認を行なったあとにVISAにこの決済はOK、この決済はNG、というレスポンスを返す仕組みになっています。

これ以外にもオンライン取引であれば不正利用対策でもある、3DセキュアのプロンプトをSlackやアプリ通知、メール等で行ったりすることもあります。

これ以外にも、最も重要な部分の一つですが、「利用可能残高から決済金額分を引く」といった作業も行います。

これらの一連の処理はまさにこの図にあるようなマイクロサービスが連鎖して最終的な決済の処理を行い、ピーク時では一日約10万件以上の決済を処理しております。

例えばこれがマイクロサービスではなく、すべての処理がモノリシックになってしまうと、一つの変更ですべてが動かなくなってしまう可能性もあります。あるいはボトルネックがある一部に集中しているだけなのに、すべてをスケールアップさせないといけなかったりします。

なので、この決済の仕組みをマイクロサービス化して分割し、必要な場所だけReplicaを作って増殖させていくことで、ホリゾンタルスケーリングを可能にします。新しい機能をリリースする際は、全体の一部だけアップデートし、決済トラフィックの一部をルーティングして、問題ないことを確認しながらリリースするといった、Canaryリリース的なことが可能になっています。

泉：これらのシステムの分離は、基本的にはクラスター単位の分離であり、GCPのプロジェクトレベルでも分離しています。その背景としては、クレジットカード業界には「PCI-DSS」という割と有名な情報セキュリティスタンダードが存在します。

基本的にカードの発行を行う信販会社も取引を扱うマーチャントも、VISA自体も、クレジットカードの番号やPIN番号、CVV等を扱う業種はほぼすべからくPCI-DSSの認証を受けないと業務ができません。

PCI-DSSは、約250件くらいのセキュリティ要件に加えて、細則が400件近くあります。いわゆるISMSのような、自分たちでセルフガバナンス（つまり規律を自分たちで作って自分たちで守る）といったセキュリティマネジメントシステムではなく、厳密にこのようにシステムを実装しなさい、といった細則があります。

例えば「この種のデータは、データベース丸ごと暗号化するのではなく行レベルで暗号化しないといけませんよ」といったイメージです。

他にも内部ペネトレーションテストや、外部脆弱性試験などの要件などもあります。

これらの要件が、管理領域のシステムも含めて、システム全体に適用されてしまうと、そのセキュリティ要件を満たすのにかなり苦労することになります。

そのため、実際のカード番号を扱うような領域とカード情報が不要な領域を分けることによって、PCI-DSSの監査対象になるシステム領域をぐっと小さくしてその中で対応しております。

実際これをやることで、８チームある開発チームのうち、５チームくらいはPCI-DSSの要件を気にせずに開発ができる、というメリットがあります。

なので確かに１つのクラスターを用意すれば、全部カバーできるという考え方もありますが、あえてマルチクラスター化することによって利用者の情報をより強固に守ることが可能です。

泉：次にScalabilityの話を少ししたいと思います

ちょうど先週水曜日に154億円の調達のプレスリリースが出ましたが、事業の立ち上がりからここまで、利用者や取引数はどんどん増加傾向にあります。とりわけDay 1を1とすると約1000倍くらいには成長しています。このようなScalingを可能にしているのはまさにこCloud Native Technologyが理由です。

GoogleのシステムアーキテクトのJeff Deanさんが「10倍、 20倍は予測してデザインするべき。しかし、ほとんどの場合そのアーキテクチャでは100倍には適さない」と言ってますが、つまり100倍になったらアーキテクチャは見直さないといけません。

UPSIDERはこれまで1000倍の成長をしていますが、ベースのアーキテクチャは変わっていません。（まさに今回のテーマ「小さな一歩から大きな飛躍」！）

もちろん、自前でEC2みたいなComputingリソースを構築して、そこからスケールアップのたびにインスタンスを増やして、LBとかの設定などをやりくりしながら、しかもアプリケーションもどんどん拡大していく…を行なっていたら Jeff Dean さんの予想通りに「これもう無理や」となり、1年くらい新規開発を止めてリアーキテクチャをしないといけない状況が起こり得る可能性はあると思います。

「金融は堅い！」というイメージをお持ちの方もいらっしゃると思いますが、「僕らが愛して止まないOSSだけで、ここまで事業が作れる」あるいは「堅そうな金融もCloud Native Technologyでどんどん生まれ変われる」という印象を持っていただけたのではないかと思っております。

泉：というところで、ここまでが、KeyNoteのメインの話しでCloud Native Technologyの持つ、Scalability、Security, Resiliencyという特性が、如何に我々の事業で生きているかという美しい話をさせていただきましたが、

もちろん、まぁまぁ厄介なこともあるので、ここからはもう赤裸々に我々まだまだ課題だらけの現状をお話しできれば、と思います。

泉：まずひとつは、これだけの事業成長を伴って発生するスケーラビリティに関する課題です。

他社の事例はわからないのですが、当社の決済領域では季節性の波がでてきています。特に某社のスマートフォン発売のタイミングになると予約が受付開始になったタイミングで注文が一気に決済されて、洪水のようにリクエストが押し寄せてくるといったことが起きております。

このようなスパイクによって我々の決済システムが予期せぬトラフィックに耐えられず、一部データベースのTransactionのロックが開放するのをまったりして、タイムアウトを起こすという事象が発生したこともありました。

このようなことが行われると何が起きるかというと、突然決済が通らなくなるわけではなく、VISAのStand-In-Process、通称STIPと呼ばれる仕組みが作動して、これまでの決済の可否の実績をもとに機械学習ベースのシステムが、決済を通すか通さないかを判断する仕組みを発動してくれます。それ自体は非常にありがたい仕組みなのですが、いかんせんさっき説明した様々な細かい制限設定が無視される可能性が出てきてしまうので、不正利用の取引が混じっても弾くことができず、結果お客様の迷惑になってしまいます。

なのでここはKubernetesのHPAの設定をチューニングして、特に繁忙期のタイミングではより瞬時にスケールできるようにPodのスケーリングポリシーを見直したり、瞬時に増加するリクエストに対応できるようにしております。

あと、単純にPodを増やすだけでは不十分で、背後にあるデータベースのボトルネックなども解消する必要があり、そもそもSpannerのロック待ちみたいなこともあり得るので、ロックがおきる前に書き込みの処理を非同期にするなど、そのような対応もアプリケーションレベルで対応する必要があるので、すべてがホリゾンタルスケーリングで解消できるわけでもない、というのが現状です。

これ以外にもローカルで開発したものをCluster上でテストしたいとかでmirrordを使ってみたかったり、Prometheus辞めてOpenTelemetryに寄せるのにGrafana Alloy使ったり、いろいろアジェンダは山の様にあります。

CloudNative Technologyの恩恵

泉：今日のまとめですが、やはりCloud Native Technologyは、事業をスケールさせるためのテクノロジーとして作られたものですが「金融」という領域にもめちゃくちゃ滲み出てきており、今後どんどんこの領域でも活躍していくことが予想されます。

ライトなウェブアプリケーションを構築したいだけならCloudRunとかを使ってサーバーレスにやるほうが圧倒的に早いしコストも抑えられます。

が、今日話したような基幹システム、とくにミッションクリティカルな領域においてこそ、CloudNative Technologyの良さが生きると思っており、まさに冒頭話した数百億したシステムがオープンソースでここまで作れるようになったことは本当に時代の恩恵だし、これが回り回ってより利用者が安全・安心して使える経済インフラに発展することができたことは、本当にコミュニティによる貢献から成り立っているとしみじみ思っているので、皆さんへの感謝とともに本Keynoteを締めたいと思います。