AppSignalが実践するシタデル（Citadel）アーキテクチャのすべて

DHH（David Heinemeier Hansson）が「シタデル（Citadel）」という言葉を提唱しました。これは、AppSignalが技術面で採用しているアプローチを表現するのに、まさにうってつけの用語です。「おっ、これは私たちのことだ！私たちのやり方についに名前が付いた」というのが率直な感想でした。

「マジェスティック・モノリスに加えて、『ザ・シタデル』というパターンについても誰か書いてくれるといい。単一のマジェスティック・モノリスがアプリケーションの大部分を担い、高度に専門化された特殊なニーズに対応するための少数の補助的なアウトポストアプリが配置される構成だ。」

— DHH（@dhh）2020年4月7日

AppSignalがどのようにシタデルパターンを実践しているのかを説明するために、私たちのシステムの仕組みについて少し紹介しましょう。AppSignalは監視（モニタリング）製品であり、ユーザー向けアプリケーションと、監視エージェントがデータを送信するAPIで構成されています。送信されたデータは処理され、グラフやインサイトへと変換されます。

モノリス：アプリケーションの中核

顧客が直接操作するアプリケーションはモノリシックなRailsアプリで、フロントエンドの一部はReactで書かれています。バックエンドは完全にRubyで実装されており、複数のデータベースと連携しています（スケーリングの都合上、顧客ごとのデータを別々のクラスタに分割しています）。このRailsアプリは、外部サービスへのアラート送信など、さまざまなタスクも担っています。

創業当初は、このRailsアプリ自体が監視エージェントからの受信データも処理していました。しかし、データ取り込みがボトルネックになると予見したため、サブドメイン上で動作するSinatraアプリでデータを受け付け、Sidekiqジョブを生成してRailsアプリ側で処理する方式に切り替えました。

成長の痛み：限界との遭遇

このアーキテクチャは長年にわたり安定して機能していました。ところが事業の成長に伴い、エージェントからの受信データを処理するという特定のタスクには特別な対応が必要であることが明らかになりました。何十億という規模のリクエストを監視すると、どうしてもハードな限界に行き当たります。

最大の制約要因は、Rubyが遅いためではありません（遅くないことは周知の事実ですね 😉）。本当の問題は、当時のアーキテクチャ設計が原因で、データベースに過度のロックが発生していたことにありました。

アウトポストの設置：RustとKafkaの採用

いくつかの選択肢を検討した結果、私たちの状況にはKafkaが最適だと判断しました。また、私たちは以前からRustでの開発経験があり、その高速性と信頼性はこのシステムにぴったりだと考えていました。そこで、データの取り込みと処理の仕組みをRustで書き直し、Kafkaをキューとストレージの両方の役割で活用することにしました。

Railsアプリから移行したのは、受信データの処理部分だけです。システムの残りはモノリシックなアプリという形でうまく機能し続けています。私たちはこのコードベースを深く理解しており、シンプルさを保つことを大切にしています。モノリスは今でもロジックの大部分を担い、Kafkaと密接に連携しています。さらに、モノリスを維持したいという思いから、メインアプリがアウトポストと簡単に通信できるよう、独自のKafka gemを開発しました。

AppSignalにおけるKafkaの仕組みについて詳しく知りたい方は、筆者がRailsConfで行った講演をご覧ください。

シタデルでの暮らし

こうして現在の姿に至りました。私たちは今、シタデルでの暮らしにとても満足しています。DHHの言葉を借りれば：

「単一のマジェスティック・モノリスがアプリケーションの大部分を担い、高度に専門化された特殊なニーズには少数の補助的なアウトポストアプリが対応する。」

私たちの場合、高度に専門化されたニーズに応えるアウトポストサービスは1つだけです。もし今年RailsConfが開催されていたら、この構成に名前を付けてくれた感謝を込めて、DHHにもっとストループワッフルを差し上げたことでしょう。🍪