今回はセルフホストサーバーをおすすめする記事を書いていきます。
セルフホストサーバーと言えば、今まであまり利用してこなかったのですが、最近その素晴らしさに気づいたので記事を書いています。
何でもできるのが魅力
セルフホストサーバーの良いところは、まず何でもできるところですね。
例えば最近だと、Webアプリのメトリクス監視をセルフホストサーバーで構築したという話なのですが、もともとひと昔前だと、そういうのはSaaSを使ってやったり、そういう製品を導入したりするのが当たり前だったと思います。あるいはAzureやAWSの標準機能を使ったりするところです。
しかし生成AIの普及によって、そういったものを使わなくても、サードパーティのオープンソースのものを使って、自分でセルフホストサーバーにメトリクス監視の環境を構築することが簡単になってきたので、今回自分でもやってみました。
Webアプリのメトリクス監視環境を構築
今回作った監視環境は次のようなものです。
- フロントエンドから Web Vitals のメトリクスを収集
- エラーログを収集
- サーバー側からもクライアントからの通信のログを収集
- サーバー自体のメトリクス（メモリ、CPU使用率など）を収集
これらを OpenTelemetry（OTel）のプロトコルを使って OTel Collector に送り、そこから振り分けます。
- ログは Loki へ
- メトリクスは Prometheus へ
- トレース（分散トレーシング）は Tempo へ
といったミドルウェアにログを収集していき、最終的には Grafana（GUIツール）で可視化してモニタリングするという環境を作りました。
環境構築で詰まるところもいろいろありましたが、大体AIに聞けば、どういった理由で失敗しているのかも分かるので、そんなに苦戦することもなく環境を構築できました。
セルフホストのGitLabでCI/CD自動デプロイ
あとはセルフホストサーバーを使ってやったこととして、セルフホストのGitLabでソースコードを管理しています。
セルフホストしていないGitHubなどでコード管理している場合は、GitHubの機能を使ってプッシュしたらVercelとサービス上で連携しているので、Vercelにデプロイされるということができます。しかし、セルフホストでコードを管理している場合はそうもいきません。
そこでGitLabの話ですが、セルフホストサーバーに GitLab Runner を導入して、GitLabにコミット・プッシュがあったときに、Runner経由でセルフホストサーバーにCI/CDで自動デプロイをするということも、セルフホストならではできることになります。
リバースプロキシでポートを整理
そういったいろいろな通信を通していると、セルフホストサーバーってポートが穴だらけになってしまったりするんですけど、そういったところも今回、**Traefik（リバースプロキシ）**を使って、うまくポート1個に対して、サーバー側でいろんなサービスを配信するという構成にすることで、ポートが穴だらけになることを防ぎつつ、いろんなサービスをセルフホストサーバーで配信することができました。
まとめ
というところで、今回いろいろ話したセルフホストサーバー。
ひと昔前だと、ちょっと扱いづらく、何でも自分でやらなきゃいけない環境で、これができないとインフラに強くないとなかなか取り回しが難しいものでした。しかし、近年のAIの普及によってそういったところが改善されてきているので、下手にSaaSを使ったり有料のサービスを使うよりも、サーバー1台持っていれば何でもできるよという時代になったんじゃないかな、ということを言いたかった記事です。
以上。
