【ITニュース解説】Your self-hosted AI stack probably needs one process, not six

システムエンジニアを目指す方々にとって、ソフトウェアのアーキテクチャ設計は非常に重要な学習テーマである。特に最近注目を集めるAI関連システムを自分で構築する「自己ホスト型」のケースでは、最適なアーキテクチャ選択が運用負荷とパフォーマンスに大きく影響する。

多くの人が自己ホスト型AIアシスタントを構築しようとすると、その構成ファイルを開いて驚くかもしれない。そこには通常、アプリケーション本体を動かすコンテナ、キュー管理のためのRedis、状態を保存するためのPostgres、実際の処理を行うワーカー、さらにはベクトルデータベースやリバースプロキシといった、複数のサービスが羅列されていることがある。例えば、たった5人の家族で使うようなシステムなのに、これら6つものサービスが動いている、という状況は珍しくない。

しかし、冷静に考えてみてほしい。このようなアーキテクチャは、その規模で本当に必要なものだろうか。例えば、キュー（メッセージブローカーとも呼ばれる）は、処理がシステムの再起動後も失われないようにするためや、処理を行うワーカーを複数台に増やして並行処理能力を高めるために存在する。また、複数のサービスが同じイベントを共有する必要がある場合にも役立つ。これらは、膨大な量の処理を安定してさばく必要のある大規模システムにおいては非常に重要な機能である。

だが、もしあなたがデスクの下に置かれた一台のマシンで、たった数人のユーザーのためにAIアシスタントを動かしているとしたらどうだろう。ワーカーを水平にスケールさせる必要はほとんどないだろうし、そもそもシステムが頻繁に再起動して処理が失われる事態を前提とする必要性も低い。つまり、このキューは、あなたが直面していない問題を解決するために導入されていることが多いのだ。

メッセージブローカーがその価値を発揮するのは、データの生産者と消費者が独立してスケールする必要がある場合、ある処理がそれを受け付けたプロセスが停止しても生き残る必要がある場合、あるいは複数のサービスが同じイベントを必要とする場合である。これらは、まさに大規模なシステムにおいて現実的に発生する問題である。しかし、たった5人のユーザーでは、これらの問題はどれ一つとして当てはまらない。それにもかかわらず、あなたはこれら全ての機能に対するコストを支払っていることになる。

6つのサービスが動いているということは、6つの異なる箇所で障害が発生する可能性があり、6種類の異なるログファイルを監視し、それぞれ異なるバージョンアップに対応する必要があるということだ。そして、もしUI上で何らかの症状が発生した場合、その根本原因を突き止めるために、普段見ていないコンテナのログを3段階も辿る必要がある、といった複雑なデバッグを強いられる可能性もある。これは、運用する上で非常に大きな負担となる。

TencentCloudが提供するOctopというサービスは、これとは全く異なるアプローチを取っている。Octopでは、Webダッシュボード、コマンドラインインターフェース（CLI）のバックエンド、全てのチャットチャンネル、そして定期的な処理を行うcronスケジューラが、たった一つのプロセスで稼働する。ここにはメッセージブローカーは存在しない。全ての要求は、この単一プロセス内のハンドラーを経由して処理される。そして、システム全体の実行時状態は、起動時にSQLiteデータベースから再構築される仕組みになっている。

この「起動時にデータベースから状態を再構築する」という点が非常に重要である。一般的に、システムを再起動しても処理が安全に継続されるようにするためには、耐久性のあるキューを使ったり、シャットダウン時に慎重に状態を保存したりする必要がある。しかし、Octopのアプローチでは、プロセス自身は権威ある状態（システムの状態を最終的に決定する情報）を一切保持しない。メモリ上に保存しておく価値のあるものが何もない、と考えることができる。これによって、プロセスがいつ強制終了されても問題なく、起動時にはデータベースから最新の状態を読み込んで再構築できるという、非常に強力な耐障害性を実現している。何かを「うまく保存する」のではなく、「保存する価値のあるものを持たない」という思想だ。

ここで「SQLite」という言葉が出てくると、「それは小規模な開発用のデータベースで、いずれはより本格的なデータベースに移行するものだろう」と反射的に思うかもしれない。しかし、単一のマシン上で、多くの読み込みと比較的少ない書き込みが同時に発生するようなワークロードにおいては、SQLiteは単に正しい選択肢となる。接続プールを管理する必要がなく、PostgresやMySQLのような別のデータベースデーモンを動かす必要もない。チューニングの手間もほとんどかからず、バックアップもデータベースファイルをコピーするだけで簡単にできる。

OctopがPostgresをデフォルトではなくオプションとして提供していることからも、彼らが実際のワークロードを深く分析し、単なる既存の参考アーキテクチャを模倣するのではなく、最適な選択肢を真剣に検討したことが伺える。

もちろん、この単一プロセスアーキテクチャにも限界は存在する。この限界をはっきりと理解しておくことは重要だ。単一プロセスは、まさしく一つの障害ドメインである。つまり、チャットのゲートウェイを一台のサーバーに置き、AIエージェントの処理を別のサーバーで行う、といった分散構成はできない。そして、ある程度のユーザー数を超えると、この単一プロセスはシステムのボトルネックとなり、巧妙な設計ではなく、むしろ問題となる。

例えば、家庭内や5人程度のチームで使うのであれば、この性能の限界はほとんど理論上の話であり、日々の運用におけるシンプルさが大きなメリットとなる。しかし、もし50人ものユーザーが同時にシステムを利用するような状況であれば、単一プロセスは明らかに不適切な設計である。

実用的な側面として、リモートアクセスを伴う自己ホスト型サービスを運用する場合、まず自宅のインターネットのアップロード帯域幅が、そのサービスが実際に使えるかどうかを決定する。これは、実際にシステムを構築して後から問題に気づくよりも、事前に速度テストで確認した方がはるかに早く解決できる問題である。

結論として、システムを設計する際には、常に「そのアーキテクチャが解決しようとしている問題は何なのか」「現在の利用規模や将来の計画に対して、本当にその複雑性が必要なのか」を深く考えることが重要である。安易に大規模システム向けの複雑な構成を模倣するのではなく、シンプルで運用しやすいアーキテクチャを検討することから始めるべきだ。