【ITニュース解説】Why my habit tracker gives you a 1.5 multiplier for showing up 11 days straight

このニュース記事は、ゲームのような要素を取り入れた習慣トラッカーアプリ「Gamified Tracker」の裏側で動くシステムについて解説している。単に活動を記録するだけでなく、ユーザーの行動に経験値（XP）を与え、レベルアップやランキング変動といったゲーム的な報酬を提供するシステムが、どのように構築され、どのような課題を乗り越えてきたのかが詳細に語られている。

このシステム開発の出発点となったのは、初期バージョンが抱えていた深刻なバグだった。活動ログの記録と、それに対する経験値の計算（ゲーミフィケーション処理）が同じタイミングで実行される「同期処理」だったため、もしゲーミフィケーションサービスが一時的に停止してしまうと、ユーザーが記録した活動ログ自体が保存されず、完全に失われてしまうという問題があった。この致命的な問題を解決し、システムの堅牢性を高めることが、新しいアーキテクチャ設計の最大の目的となった。

この問題の解決策として採用されたのが、「マイクロサービスアーキテクチャ」という設計思想だ。これは、一つの大きなアプリケーションを、それぞれが独立して機能する小さなサービスに分割する考え方で、これにより、あるサービスに問題が発生しても、他のサービスへの影響を最小限に抑え、システム全体の堅牢性を高めることができる。

具体的には、このシステムは以下の主要なサービスで構成されている。 まず、ユーザーからのすべてのリクエストを受け付ける「API Gateway」がある。これはシステムの「玄関」のような役割を果たし、ユーザーの認証（誰がリクエストしているかを確認）、アクセス制限、そしてリクエストを適切なサービスへ振り分ける役割を担う。 次に、ユーザーの活動記録（例えば、「45分勉強した」という情報）を保存する「Activity Service」がある。このサービスは活動ログをデータベースに記録し、経験値付与のきっかけとなるイベントを生成する。 そして、経験値の計算、レベルアップ、ランキング更新といったゲーム的な要素を管理する「Gamification Service」がある。このサービスはActivity Serviceから送られてきたイベントに基づいて、ユーザーの経験値やレベルを更新する。

これらのサービスは、共通のデータベースである「PostgreSQL」にデータを保存する。さらに、サービス間の連携をスムーズにするために「Eureka」というサービスディスカバリ（サービスの発見・登録）システムが使われており、各サービスが互いの場所を固定的に設定することなく通信できるようになっている。 最も重要なのは、「RabbitMQ」というメッセージキューの存在だ。これは、Activity ServiceとGamification Serviceの間で情報を「非同期」にやり取りするための仕組みだ。Activity Serviceは活動ログをデータベースに保存した後、すぐにGamification Serviceに直接処理を依頼するのではなく、RabbitMQに「こんな活動がありました」というメッセージを一旦預ける。Gamification Serviceはそのメッセージを後で読み取って処理する。 この「アウトボックスパターン」と呼ばれる非同期処理の導入により、Activity ServiceはGamification Serviceの応答を待つ必要がなくなった。つまり、Gamification Serviceが一時的に停止していても、Activity Serviceは活動ログを確実に保存できるようになり、初期の致命的なバグが解消されたのだ。Gamification Serviceは後でメッセージキューからイベントを読み取り、処理を再開できるため、ユーザーは少し遅れて経験値が加算されたり、レベルアップしたりすることになる。

ゲーミフィケーション処理の堅牢性を高めるため、このシステムでは「冪等性（べきとうせい）」という考え方も採用されている。メッセージキューを使った非同期処理では、ネットワークの状況などにより、同じイベントが複数回送られてしまう「重複配信」が発生する可能性がある。しかし、同じイベントを何度処理しても結果が一度だけ適用されるように、イベントIDを使って「このイベントはもう処理済みか？」と確認し、処理済みであればスキップすることで、経験値が重複して加算されるのを防いでいる。

システム全体の技術スタックとしては、Javaというプログラミング言語と、Webアプリケーション開発を効率化するSpring Bootというフレームワークを中心に構築されている。API GatewayにはSpring Cloud Gateway、認証にはSpring SecurityとJWT（認証情報を安全にやり取りするためのトークン）が使われている。データベースのスキーマ（データの構造）変更はFlywayというツールで管理されており、各サービスがそれぞれ自分のスキーマを持つことで、データ管理の独立性を保っている。そして、これらのサービス全体はDocker Composeというツールを使って、開発者のローカル環境で簡単に起動・実行できるようになっている。

設計上の重要な判断として、データベースの利用方法がある。マイクロサービスでは、サービスごとに専用のデータベースを持つのが理想的とされることが多いが、このシステムでは1つのPostgreSQLインスタンス内に、API Gateway、Activity Service、Gamification Serviceがそれぞれ異なるスキーマを持つ形でデータベースを共有している。これは、データベースの運用コストを抑えつつ、各サービスが自分のデータ構造を独立して管理できるというメリットがある。この方式は、障害時には共有データベースが全体のボトルネックになる可能性はあるものの、論理的な分離は保たれているため、将来的にサービスごとにデータベースを物理的に分けることも比較的容易にできる、という戦略的なトレードオフに基づいている。

このプロジェクトを通じて、いくつかの重要な教訓が得られた。まず、最初の大失敗から、システムの一部がダウンしても他の部分が動き続ける「非同期処理」の重要性を痛感した。また、非同期処理にしたことで、レベルアップの通知がリアルタイムに表示されなくなったというユーザー体験（UX）上の課題も生まれた。これは、システムの堅牢性とユーザーへの即時フィードバックの間で、どのようにバランスを取るべきかという、開発における難しい問いを示している。 さらに、サービス間で共有するデータ（例えば、メッセージキューでやり取りするイベントの型定義）は、独立した「共有モジュール」として一元的に管理することが、不整合やバグを防ぐ上で非常に重要だということも学んだ。Spring Securityのような複雑なフレームワークを使用する際は、その内部動作を深く理解していないと予期せぬ挙動に遭遇することや、開発環境で動作したものが必ずしも本番環境で動くとは限らないため、Dockerのようなコンテナ技術を使って実行環境を標準化することの重要性も再認識された。

この習慣トラッカーのシステムは、単なる機能の実装に留まらず、堅牢性、拡張性、そして将来の変更への対応を考慮した設計、さらには開発の過程で得られた貴重な教訓の集大成であると言える。システムエンジニアを目指す上で、このような設計思想や課題解決のアプローチは非常に参考になるだろう。