やりたいこと
最近はFOSSのセルフホストできるアプリケーションサーバはもちろん、AIプログラミングによって自分用のアプリケーションが無数に出来上がっている。稼働中のアプリケーションの数は20-30くらいあるような気がする。また、複数マシンに散らばっているし、できれば今後Linux PCの検証も兼ねて、激しくサーバの移動などもさせていきたい。
そうすると、バックアップ・復元が悩ましい。現在は各マシン・各アプリケーションで個別のバックアップスクリプトやバックアップのワーカを走らせており、なにがなんだかわからなくなってきた。一元化する必要がある。
アーキテクチャ案
全体像
Geminiと「違うそうじゃないこのわからずや」などと相談しつつ、下図のような構成を考えている。
バックアップサーバにはMinIOでS3互換のオブジェクトストレージをたてる。アプリケーションサーバには、バックアップ用のワーカを走らせて、そこからS3互換APIでアプリケーション名を添えて必要なアーカイブPUTする。バックアップサーバはアプリケーション名で分類して保存する。
アーキテクチャの要点
考え方をGeminiにまとめさせた。
- アプリケーションの責務: バックアップワーカーは「何が復元に必要なデータか」を熟知しており、自らアーカイブを作成する。バックアップサーバの内部パス（
/mnt/sda1/...など）は知る必要がなく、自身の「バケット名」という抽象化された名前だけを知っている。 - バックアップサーバの責務: MinIOが受け皿となり、届いたファイルをバケットごとに整理する。ファイルシステム上の物理的な配置や、古いファイルのローテーション（ライフサイクル設定）は、サーバ側のポリシーとして一元管理する。
- 疎結合な関係: 転送は標準的なS3 APIで行われるため、将来的にアプリケーションを別のホストに移動したり、バックアップサーバの構成を変更したりしても、エンドポイントと認証情報を書き換えるだけで運用が継続できる。
Push型の考え方
大まかにわけて、考え方としてアプリケーションから動くPush型と、バックアップサーバが見に行くPull型があるかなと思う。綺麗にやるならPullかもしれないんだが（AIからはそれを提案された）、現実は汚いので管理が面倒くさいことになると思われた。
アプリケーションには固有の特徴があるものだ。その差分を吸収しようとすれば結局たいへんになる。そもそもバックアップできてなくて困るのはそのアプリケーションなのだから、Import/Exportは基本的にアプリケーションの仕事であるべきだと思う。
ただその保存場所として、よく知られたやり方の倉庫があってほしい。FTPやrsyncだとパスの指定のような倉庫の中身をアプリケーションサーバが知らなくてはいけなくなり、しんどい。ということで、S3互換APIを使えるMinIOを間に挟むのが良いだろう、という感じ。
愚直にアーカイブする理由
この構成だとResticみたいなバックアップツールを使って圧縮したり差分・増分を転送したりするということが考えられるのだが（Geminiにも勧められた）、それはやめた。まぁ使ったことがないので学習コストがかかるというのもあるのだが、原理的な面として、アプリケーションの個別の対応や復元を考えるとややこしくなりそうに思えた。
それに対して、純粋にファイルベースのバックアップならば最悪どうなってもなんとかはなるし、何よりもわかりやすい。通常はネックになる通信帯域もLAN内だから気にしなくていいし、ストレージも家のHDDを使えばいいんだから課金の心配もなく全然余裕がある。
なので、愚直にやるほうがいいかなと思った。セルフホストだからこそできるリッチ構成かもしれない。
所感
まぁやるのはこれからなんだが、頭の中ではうまくいきそうな目途は立っている。アプリケーションサーバとバックアップサーバのそれぞれの仕事と知っていることについて責務を分けたこと、できるだけファイルベースを貫いたことがポイントになる。
ただまぁ、僕が作っているアプリケーションにはAIで大量のデータが生成されるようなものもあるのだが、それについては別で考えたほうがいいかもしれない。アプリケーション自体のデータベースはあまり肥大化しないような設計が求められる。
コメント