Actionbase – いいね、最近見た、フォローのためのデータベース
(github.com/kakao)いいね、最近見た商品、フォロー機能のためのデータベース Actionbase をオープンソースとして公開しました。
こんにちは、カカオで Actionbase を一緒に作っている開発者です。
昨夜8時（27日）に Hacker News（Show HN）へ Actionbase を投稿し、投稿から約1時間30分でトップページ1位になりました。実は目標はトップページに残ることだったのですが、予想以上に良い反応をいただきました。
なぜ作ったのか
いいね、最近見た商品、フォローのような機能は、サービスごとに形は少しずつ違っていても、似たようなデータ構造と処理方式を繰り返し作ることになります。
問題は、チームごとに順方向／逆方向リスト、カウント、インデックスを少しずつ異なる形で実装している点です。リトライやイベント順序の処理方式もばらばらだったため、データが微妙にずれることがあり、いいね数のような集計データを作る方法も統一されておらず、運用が難しくなっていました。
どのように動くのか
Actionbase はこれを 誰が（actor）何に対して（target）何をしたか（action） という関係モデルとして定義し、書き込み時点ですべてを事前計算します。読み取りは単純な参照だけなので、高速で予測可能です。
本番適用
最初の本番適用は カカオトーク ギフトのウィッシュ でした。当時は足りない点も多くありましたが、その期待に応えるために多くの改善を重ね、その経験がプロジェクトを成長させるきっかけになりました。
👉 ストーリーを見る
現在は複数のカカオサービスで、毎分100万件を超えるリクエストを数年にわたって処理しています。ストレージは HBase ベースで、さまざまな規模に対応できるよう軽量ストレージ（SlateDB ベース）も準備中です。
はじめる
Docker ですぐに実行できます:
docker run -it ghcr.io/kakao/actionbase:standalone
- 📦 GitHub: https://github.com/kakao/actionbase
- 🚀 クイックスタート: https://actionbase.io/quick-start/
質問、フィードバック、スターのいずれも歓迎します。
Q&A
Q: Redis でもできるのでは？
できます。私たちもホットデータ向けに Redis をキャッシュとして使っています。ただ、規模が大きくなるにつれてチームごとの重複実装が増え、イベント順序が乱れることでデータが不整合になる問題を経験しました。
Q: PostgreSQL/MySQL をシャーディングすればいいのでは？
多くのチームがそうしています。私たちが直面した問題は、ホットエンティティ、クロスシャード参照、そしてサービスごとに異なるキャッシュ戦略でした。毎回シャーディング戦略を設計しなくても水平スケールできるモデルが必要でした。
Q: Write-time precompute はどのように動きますか？
書き込み時点で WAL 記録 → ロック → 状態遷移 → カウント／インデックス計算 → 保存 → CDC 発行、という流れです。読み取りは単一の GET か SCAN を行うだけです。
Q: イベント順序が乱れたら？
各 mutation に version（通常はタイムスタンプ）を付けます。イベントが like(t=100) → like(t=300) → unlike(t=200) の順で到着しても、version 基準で最終状態が正しく収束します。同じイベントをリプレイしても同一の状態に収束することを目指しています。
Q: 実際の性能は？
カカオトーク ギフトの本番環境で毎分100万件以上を継続的に、ピーク時には約200万件を処理しています。読み取りレイテンシは p50 約2〜3ms、p99 約10ms です。重要なのは絶対的な数値よりも、レイテンシが bounded である点です。読み取りは集計ではなく事前計算済みのルックアップなので、データが大きくなっても性能が低下しません。
Q: どんなユースケースに適していますか？
いいね／リアクション、フォロー／フォロワー、最近見た商品が主要なユースケースです。レコメンド／ML 特徴量については CDC を通じて学習データを提供できますが、レコメンド自体を直接サービングするものではありません。チャットメッセージはおそらく最適な選択ではありません。ページネーション、検索、スレッディングといった別のアクセスパターンが必要だからです。EC カートもトランザクションが必要ですが、Actionbase はクロスエッジトランザクションをサポートしていません。
Q: オーバーエンジニアリングでは？ / 大企業だけに必要なのでは？
その可能性はあります。正直に言えば、小規模であればよくチューニングされた PostgreSQL + Redis が正解です。Actionbase が解決する問題、つまりシャーディングの複雑さ、キャッシュ無効化、チーム間の重複は、かなりの規模になったり複数チームが似た機能を作ったりすると現れます。私たちはその壁に何度もぶつかったため、これを作りました。そのため、小規模なデプロイでも使えるよう軽量バックエンド（SlateDB）も準備しています。
24件のコメント
おお…軽量バックエンド版も期待しています!!
ありがとうございます！ 軽量バックエンドは、S3 だけあればよい SlateDB ベースで進める方向性は固めているのですが、まだ本格的には着手できていません。
もしよければ、どのような環境で使う想定なのか気になります。サイドプロジェクトでしょうか？ それとも小規模な本番環境でしょうか？ 優先順位を決める際の参考にしたいです。
お時間があれば、HBase/SlateDB の投票もお願いします。コミュニティの意見が方向性を決める助けになりそうです: https://github.com/kakao/actionbase/discussions/144
とても実用性のあるプロジェクトだと思います。
素晴らしいです！
ありがとうございます！ Show HNでは得られなかった関心への未練を、ここで晴らしています。
もしどのあたりを実用的だと感じられたのか、お聞きできればうれしいです。似たような問題を経験されたことがありますか？ それとも、その機能の実装が必要な状況なのでしょうか？
それから、コメントする機会ができたので言いたかったことがあるのですが、ドキュメントには unbounded traversal はやらないと書いてあるものの、bounded multi-hop は今年の計画に入っています。たとえば「友だちがいいねした商品」のような 2-hop クエリです。 https://actionbase.io/ko/stories/unified-graph/
どんな点が実用的だと感じたかというと、
私自身も似たような悩みをした経験があり、Redis のような KV ストアをベースにコードレベルで抽象化レイヤーを実装してみたことがあるので、ドキュメントが目指している目標や方向性、そして全体的な構成まで、どれも非常に実用的だと思いました。
そして、複数のチームのニーズや課題を反映してまとめ上げ、社内向けの内部プロダクトを作り、それをオープンソースとして公開したというのが素晴らしいと思います。
最後に、あえて付け加えるなら、使う方にとっては今のドキュメントでも十分だと思いますが、コピー＆ペースト感覚でそのまま試せるデプロイ例や、推奨されるユースケース、インフラのリファレンスを example として盛り込めば、さらに魅力的になると思います。
頑張ってください！
同じような悩みをお持ちだったとのことで、心からうれしく思います。そして、「素晴らしい」と言っていただき本当にありがとうございます。
おっしゃる点には共感します。私も、ツールとして使う部分は気軽にセットアップして、自分が解くべき問題に集中したいと思っているからです。
ただ、現時点ではまだオープンソースの初期段階であり、限られた時間の中でこのコアバリューをどう伝えるかに焦点を当ててきました。伝わらなければ、実際に問題を解ける方々もそうできなくなってしまうからです。これからは、おっしゃっていた方向で進めようと考えています。ただし、内部スタックの HBase + Kafka にするのか、新規開発の工数がかかっても SlateDB + S2 にするのかについては、フィードバックをいただきたいです。私たちは HBase エンジニアが運用してくれているので気軽に使えていますが、そうではない環境も多いはずです。ご意見をいただけるとありがたいです（投票だけでも大丈夫です）：
https://github.com/kakao/actionbase/discussions/144
おっしゃっていた 2-hop クエリのようなロードマップもとても魅力的だと思いますが、
今あるドキュメントで伝えたいことを、コードのような例でうまく落とし込めば、はるかに爆発的な反応があると思います。
同意します。"良い例としてうまく溶け込ませること"ですね。ですが、これは見た目ほど簡単ではないんですよね…… さまざまな面から考えてみます。ありがとうございます！
もしよろしければ、私たちの同僚が一生懸命準備した https://actionbase.io/guides/build-your-social-media-app/ インタラクティブガイドをご覧になったか気になります。これがそうした試みだったのですが。おっしゃっていた方向性に合っているのか、改めて振り返るきっかけになります。引き続き努力していきます。
あっ、それから新しく付いたコメントで見落としていた点ですが、ガイドだけでなく、全体的なドキュメント構成にも工夫の跡が感じられます。
ただ、先ほど申し上げたように、サンプルとして用意された構成を
git cloneで簡単に追試できるようにできれば、さらに良くなると思います。以下のコメントにあわせて返信します。
コメントしたつもりだったのに見当たらなかったので、最初から書き直します……（しくしく）
軽い気持ちで付けたコメントだったのに、とても丁寧に返答していただきありがとうございます……（笑）
とにかく私が言いたかったのは、これを導入してみたい小さなチームと大きなチームでは、それぞれの環境がかなり異なるだろうということです。そして、軽い気持ちで「これ、ちょっと導入してみようか？」となったときに、いちばん説得しやすい形は、チームで使っている言語で書かれたサンプルプロジェクトだと思います。
まずメジャーな言語でサンプルプロジェクトを作り、それをベースにクイックスタートを構成すれば、もっと気軽に読めるようになるでしょうし、
git cloneでサッと試せるのが魅力だと思うんです。そして、この方式がベストプラクティスを説明するのにもいちばん良いと思います。
もちろん、プロジェクトの性質上それが簡単ではないことは分かっていますが、それでもやはりそれがいちばん魅力的だと思います。
あわせて、可能であれば pulumi や terraform のようなツールと一緒にサンプルを構成すると、さらに良いと思います。
まったく思いもよらなかった視点です。このような提案を本当にありがとうございます。コミュニティで得られる素晴らしい経験ですね。
おっしゃっていただいた方向性をどう実現するか、考えてみます。pulumi や terraform の例も含めてです。もしかすると方向性を整理して、コミュニティに支援をお願いすることもあるかもしれません。その際に貢献していただけたら、さらにありがたいです。
加えて、バイブコーディングの時代に、どうすればその基盤になれるのかを考えています。「アプリケーションを作って」と言えば React や Svelte などで書いてくれますよね。それと同じポジションです。「いいね機能を追加して」と言ったときに、Actionbase がその役割を担うような状況のことです。
この部分もずっと頭の中を巡っています。だからこそ、AI ツールが読めるようにドキュメント化にかなり気を配ってきましたし、最近はその可能性も見えてきています。
参考:
llms.txt - https://actionbase.io/llms-txt/
Anthropic ハッカソン優勝者レシピの試み - https://github.com/kakao/actionbase/discussions/90
似たようなユースケースを持つところでうまく使えそうですね。公開してくださってありがとうございます！
ただ、ingestionでLockを使う部分で問題はなかったのか気になります。データのWriteについては、トラフィックはどの程度だったのでしょうか？ Lock競合などによって問題になるケースはなかったのか気になります。
ご質問ありがとうございます！
Lock は edge（source, target）ペア単位で取得します（例: Alice→Phone）。同じ edge に同時に書き込む場合にのみ競合が発生しますが、実際には 1 人のユーザーが同じ対象に同時に「いいね」を押すケースはほとんどないため、競合は少ないです。これが私たちのデータベースのユースケースの特徴です。
Write トラフィックはピーク時で 1 分あたり数十万件程度です。読み取りは 100万+ で、書き込みはそれより少ないです。
ベンチマーク参考（読み取り 85%、書き込み 15%）- https://actionbase.io/ko/operations/benchmarks/
ホットエンティティ（人気商品など）では lock 競合が発生する可能性がありますが、これは count 更新のためです（HBase Increment）。この部分は別途最適化して処理しています。高頻度書き込み関連: https://actionbase.io/ko/stories/kakaotalk-gift-recent-views/
おお.....
ありがとうございます！ ご関心があれば、次の方向性についてもぜひご意見をお寄せください: https://github.com/kakao/actionbase/discussions/144
わあ、これはすごく役に立ちそうです。
ありがとうございます！ もし同様の機能を実装する中で困ったことがあれば、ぜひお聞きしたいです。次に何を優先して進めるべきかについて、コミュニティのご意見を募っています: https://github.com/kakao/actionbase/discussions/144
開発者向けドキュメントが本当によく整備されていますね。storiesで見せてくれるユースケースやクイックスタート、FAQは、技術ブログと言っていいほど内容が充実していました。
わあ、本当にありがとうございます。1月5日のオープンソース公開から27日のコミュニティ公開まで、ドキュメントにかなり力を入れたので、気づいていただけてうれしいです。
オープンソース初期なので「これは何か、なぜ必要なのか」に集中した結果、こうした成果物になったのだと思います。ドキュメントをご覧になっていて気になる点があれば、気軽にお知らせください！
ちなみに https://actionbase.io/llms-txt/ を活用すると、思いがけない結果が得られるかもしれません。最近、Actionbase をよくご存じない方がこのプロンプトで複雑なニーズに対する最適な結論にたどり着くのを見て、改めて時代が変わったのだなと感じています。
ChatGPT、Claude、Gemini などで次の内容を試してみてください。
疑われても仕方ないと思います。でも、やらせじゃありません。
最初のコメントにリンクを4つ入れたら、30分間 shadowban されました。その間は文脈の説明が見えないので、人々はそのまま通り過ぎていったんです。そのときは本当に不安でした。埋もれてしまうんじゃないかと。リンクを外してもう一度投稿したら、ようやく1位まで上がって、そのコメントにも返信がつきました。
おっしゃっていたあのコメント主、私も確認しました。登録してからまだそれほど経っていないという点です。それでもありがたかったです。反応があるだけでもうれしいので。なので丁寧に返信しました。
why not redis?これは事前に用意していました。DB関連なら必ず出る質問だからです。まさか、こんなに真剣に準備したのにそんな質問がつくわけないだろう、と思っていました。でも前日の s2-streamstore のときに分かりました。TCPでやればという返信がついたので。準備しておきました。ちなみに、チームメンバーには絶対にアップボートやコメントをしないよう頼んでいました。うっかりしないよう、ログインも解除しておいてくれと伝えました。HN がそういう点に敏感なのは前もって分かっていたので。
とにかく、説明しても信じてもらえないかもしれないので……私たちのリポジトリを一度だけ見てください。生き残ったコードです。一緒に働いた仲間たちがこの文章を見て傷つくかもしれないと思い、詳しく書いています。https://github.com/kakao/actionbase/discussions/32 一度だけ見てください。ありがとうございます。
そして、
https://actionbase.io/ko/stories/kakaotalk-gift-wish/ こちらもです。大規模システムについて考えたことがあるなら、役に立つかもしれない内容を誠意を込めて書いてみました。
あ、それから下の私のXを見ればお分かりのとおり、1位はそのコメントを付ける前のことです。そのコメントはおそらく2〜3位に落ちた時に付いたのでしょう。おやつを食べるスペースでトゥチョンクケースから取り出した瞬間にコメントが付いたので、走って行ってコメントしました。その後12時間で30位まで押し下げられ、今は2ページ目にあります ;_;
Xにも投稿しました: https://x.com/enmskim/status/2016412136482996689
x: https://x.com/enmskim/status/2016941043628097965