Kitabisa が Google Cloud で募金プラットフォームを再構築し、「大きな規模の思いやり」を推進した方法

※この投稿は米国時間 2022 年 7 月 7 日に、Google Cloud blog に投稿されたものの抄訳です。

Kitabisa という名前はインドネシアの公用語であるインドネシア語で「we can（私たちはできる）」を意味し、インドネシアで最も人気のある募金プラットフォームとして当社の向上心あふれる精神を表現しています。2013 年以来、Kitabisa は有事や自然災害の際に寄付を集め、困っている何百万人もの人々を支援してきました。「大きな規模の思いやりをつなげる」というミッションを達成するために、AI アルゴリズムをデプロイしてシンプルかつ透明性をもって東南アジアの慈善の精神を育んでいます。

ブラック フライデー期間など需要の急増を予測できる e コマース プラットフォームとは異なり、地震などの災害発生時に資金を調達するという Kitabisa のミッションは本質的に予測不可能です。そのため、シームレスなスケールアップとスケールダウンを可能にすることが当社の社会事業にとって不可欠です。

2020 年、インドネシアの COVID-19（新型コロナウイルス感染症）の大流行はラマダンと重なりました。聖月（ラマダン）の期間中は慈善活動が多く行なわれるため、平時でもこの時期にピークを迎えます。しかし、パンデミック時には寄付が殺到し、システムが限界に達してしまいました。インドネシアの寄付精神が最高潮に達したと同時に当社のプラットフォームが数分間停止し、ユーザーは不満を募らせました。

新しいクラウドの始まり

この経験により、モノリシック システムからマイクロサービスをベースとした新しいクラウドへの移行を開始する必要があることを認識しました。これにより、需要の急増時にはスケールアップし、寄付の波が収まったときにはスケールダウンすることが可能になります。また、有事の際にシステムに殺到する膨大なデータを取り込んで処理できるような、より柔軟なデータベースも必要でした。

これらの要件から、当社は Google Cloud でプラットフォーム全体を再設計することになりました。プロアクティブな Google Cloud チームの指導のもと、コンテナ化されたコンピューティング インフラストラクチャ全般を Google Kubernetes Engine（GKE）に、そしてマネージド データベース サービスを Amazon RDS から Cloud SQL for MySQL と PostgreSQL に移行しました。

その結果は当社の期待を上回りました。翌年のラマダンの時期にはコンピューティング リソースを 50% 増強し、高まるクラウドファンディングの需要に簡単に対応できるようになりました。これは、GKE のシームレスなスケーリングと、ProxySQL を使用した Cloud SQL インスタンスのデプロイと最適化に関する Google Cloud パートナー チームからの推奨の両方により、当社のマネージド データベース インスタンスが最適化された結果です。

大きな規模の思いやりに向けた漸進的なシナリオ

Kitabisa のミッションが揺らぐことは決してありませんでしたが、パフォーマンスを最適化するために最終的に Google Cloud での現在のアーキテクチャにたどり着くまでにはいくつかの段階を経ました。

起点のモノリシック プロバイダ

Kitabisa は当初 DigitalOcean でホストされており、仮想マシン（VM）とステートフル マネージド データベースに基づいたモノリシック アプリケーションしか実行できませんでした。つまり、手作業で 1 台ずつ VM を追加するため、災害をきっかけに寄付が急増した際に VM やコアメモリをスケールアップさせるという課題につながりました。

逆に、募金活動のサイクルが終了すると、手動でプロビジョニングした VM の高スペックから自動的にスケールダウンすることができず、人手と予算のリソースに負担がかかりました。

コンテナへの移行

スケーラビリティを向上させるために、Kitabisa は DigitalOcean からアマゾン ウェブ サービス（AWS）へ移行しました。この移行でロードバランサをデプロイすることで、当社のネットワークのニーズを満たすのに十分な自動スケーリングが提供されることを願いました。しかし、手動の構成により引き続き費用と労力がかかりすぎることが判明しました。

そこで、マイクロサービス ベースのアーキテクチャに切り替えることで、自動化の向上を図りました。しかし、Amazon Elastic Container Service（Amazon ECS）では、アプリケーションを起動する際にデプロイで CloudFormation と互換性があるようにする必要があり、ベンダーのロックインによりソリューション構築の柔軟性が低下するという新たな課題に直面しました。

当社は、よりアジャイルなコンテナ化ソリューションである Kubernetes への移行は「遅すぎることはない」と判断しました。すでに AWS を利用していたこともあり、マイクロサービスを Amazon Elastics Kubernetes Service（Amazon EKS）に移行するのは自然な流れに見受けられました。しかし、EKS を使用した Kubernetes クラスタのプロビジョニングは引き続き手動プロセスで、デプロイのたびに多くの構成作業が必要であることにすぐに気づきました。

自動化されたスケーラビリティの活用

COVID-19 危機の真っただ中にシステムに対する要求が高まり、当社は Google Kubernetes Engine（GKE）を試すときが来たと判断しました。Kubernetes は Google が設計したソリューションであるため、GKE が最も柔軟なマイクロサービスのデプロイを提供するとともに、新機能にも簡単にアクセスできる可能性が高いように見受けられました。

AWS と直接比較すると、Kubernetes クラスタのプロビジョニングから新しいアプリケーションのデプロイまで、すべてが完全に自動化され、最新のアップグレードが適用され、手動によるセットアップが最小限になったことがわかりました。GKE に切り替えたことで、予期せぬ寄付金の急増にも対応できるようになり、エンジニア チームの規模を拡大することなく新しいサービスを追加できるようになりました。2021 年 11 月にスマトラ島で大洪水が発生し、25,000 人が被災した際、GKE の革新的価値が明らかになりました。寄付金が 30% 急増しても、当社のシステムで簡単に対処できました。

Cloud SQL と ProxySQL への移行

Kitabisa は需要が多くなるとクラッシュしやすいモノリシック データベース システムにも束縛されていました。この問題を解決するために、DigitalOcean のステートフルなデータベースからステートレスな Redis データベースに移行しました。これにより単一サーバーへの依存から解放され、アジリティとスケーラビリティが向上しました。

しかし、この戦略では依然としてデータベースを自己管理する必要があったため、大きな課題が残りました。さらに、Google Cloud 以外のデータベースから BigQuery へのデータ移転を実行する必要があるため、データベースの下り（外向き）費用が高くなっていました。

2021 年 12 月、Amazon RDS を Cloud SQL for MySQL に移行したところ、直ちに下り（外向き）費用を月あたり 10% 削減できました。しかし最大のメリットの一つは、Google Cloud チームが、データ パイプラインのスケーラビリティと安定性を向上させるために、MySQL のオープンソース プロキシの使用を推奨してくれたことです。

Cloud SQL の互換性により、ProxySQL のような接続プーリング ツールを使用してアプリケーションのロード バランシングを改善できました。これまで、モノリシック データベースへの直接接続を確立することは単一障害点であり、クラッシュに終わる可能性がありました。Cloud SQL と ProxySQL を使用すると、データベース インスタンスの前にレイヤが作成されます。これは、プライマリ インスタンスとリードレプリカ インスタンスを作成し、複数のデータベース インスタンスに同時に接続できるようにするロードバランサとして機能します。これで、読み取りクエリが発生するたびに、プライマリ インスタンスではなくリードレプリカ インスタンスにクエリをリダイレクトできるようになりました。

この構成により、複数のデータベース インスタンスを同時に実行し、すべてのインスタンスで負荷を分散させることができるため、データベース環境の安定性が変革されました。マネージド データベースとして Cloud SQL に切り替え、ProxySQL を使用するようになってから、大きな危機が訪れたときでも、募金プラットフォームのダウンタイムはゼロになりました。

また、費用の節約も実現しています。異なる Kubernetes クラスタごとに別々のデータベースを持つのではなく、複数のデータベース インスタンスを 1 つのインスタンスに結合しました。これにより、データベースをサービスごとではなくビジネス ユニットごとにグループ化することで、データベースの費用を 30% 削減できるようになりました。

Terraform のデプロイによる合理化

Google Cloud マネージド サービスによって環境を最適化することができたもう一つの重要な方法があります。それは、新しいアプリケーションやプラットフォームのアップグレードを作成するための Infrastructure-as-a-Code ツールとして Terraform を使用することです。

また、Terraform のコードを Google Cloud にデプロイする際も、Cloud Build を利用することで人手をかけることなく自動化することができました。つまり、開発チームはクリエイティブな作業に集中できると同時に、Cloud Build によって Kitabisa に次々と継続的に新機能がデプロイされます。  

シームレスなスケーラビリティ、復元性のあるデータ パイプライン、クリエイティブな自由度の組み合わせによってプラットフォームの未来が推進され、他のアジア地域にもミッションを拡大して、人々の「思いやりのある世界を築きたい」という思いを鼓舞できます。

Google Cloud をインフラストラクチャのバックボーンに持つことは、エキサイティングな新しいインシュアテック機能を追加することを含め、当社の今後の発展にとって非常に重要な要素になると考えています。Google Cloud 上にしっかりと確立されたことで、激動の時代を乗り越えるための募金活動の未来を形作るためにさらに先に進むことができるようになりました。