Metabase 構築ログ|Excel集計地獄から抜けるために VPS 上に BI 環境を作った実録

前回の記事で なぜ Metabase を選んだか について書きましたが、今回はその続きとして、実際の 構築ログ をまとめておきます。

業務で使う以上、
「とりあえず動けばいい」ではなく、
安定して、迷わず、再現できる形 にしておきたい。

その前提で、VPS 上に Metabase を構築した記録です。


そもそも構成の考え方

今回の環境は、
SQL Server Express + Metabase を 同一 VPS 上で同居 させています。

正直、最初は少し迷いました。

  • SQL Server と BI ツールを同居させて大丈夫か
  • メモリや CPU が足りなくならないか
  • 運用が複雑にならないか

このあたりを考えた結果、
Xserver VPS のビジネスプラン(12GB) なら、十分耐えられるだろう、という判断に落ち着きました。

実際にこの構成を検証・運用しているのが Xserver VPS です。
SQL Server Express のメモリ制限(1.4GB)が、逆にリソース暴走を防ぐ形になっていて、結果的にバランスがよくなっています。

「全部盛り」にしない、というのも、ひとり情シス運用では大事な判断ポイントだと思っています。


Java のインストールと Metabase の配置

まずは Java の準備。

apt install openjdk-21-jdk
java -version

最新版で安定している 21 系を使用。

Metabase 本体は、公式サイトから JAR ファイルを取得し、SCP でアップロード。

mkdir /bi
mv /home/admin/metabase.jar /bi/
adduser biuser
chown biuser:biuser /bi
chown biuser:biuser /bi/metabase.jar

専用ユーザーを作成し、
業務用サービスは root で動かさない という、いつものルールを踏襲しています。


systemd で常駐サービス化

単発起動だと、再起動のたびに手動起動が必要になるため、systemd でサービス登録。

vi /etc/systemd/system/metabase.service
[Unit]
Description=Metabase Service
After=network.target

[Service]
ExecStart=/usr/bin/java -Xmx4g -jar /bi/metabase.jar
WorkingDirectory=/bi
Restart=always
User=biuser
Environment="MB_JETTY_PORT=3000"

[Install]
WantedBy=multi-user.target

起動と自動起動設定。

systemctl daemon-reload
systemctl enable metabase
systemctl start metabase

ここまでで、
http://localhost:3000 で Metabase が立ち上がります。


nginx 経由 + 自己証明書で SSL 化

社内利用とはいえ、
平文通信は避けたい ので nginx を挟んで SSL 化。

証明書は自己証明書で十分と判断しました。

SAN に IP アドレスと localhost を入れておくことで、ローカル検証でも警告やエラーが起きにくい実務上のメリットがあります。

apt install nginx
openssl req -x509 -nodes -days 36500 -newkey rsa:2048 \
  -keyout /etc/ssl/private/metabase-selfsigned.key \
  -out /etc/ssl/certs/metabase-selfsigned.crt \
  -subj "/C=JP/CN=xxx.xxx.xxx.xxx" \
  -addext "subjectAltName = DNS:localhost, IP:127.0.0.1, IP:xxx.xxx.xxx.xxx"

nginx の設定例:

server {
    listen 31274 ssl;
    server_name xxx.xxx.xxx.xxx;

    ssl_certificate /etc/ssl/certs/metabase-selfsigned.crt;
    ssl_certificate_key /etc/ssl/private/metabase-selfsigned.key;

    location / {
        proxy_pass http://localhost:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

SAN 対応も入れて、最近のブラウザ警告も最小化。

この構成で、
https://サーバIP:ポート/ で安全にアクセスできるようになります。


初期セットアップと SQL Server 接続

初回アクセス後、管理者情報を登録。

DB 追加では SQL Server を指定。

  • ホスト:localhost
  • ポート:1433
  • DB名:業務DB
  • SSL:OFF(ローカル接続のため)

ここは特に迷うポイントもなく、
素直に設定すれば問題なく接続できました。


運用してみた正直な感想

一番感じたのは、

「想像以上に軽い」

という点。

SQL Server Express と同居していても、

  • CPU 使用率:常時 10% 前後
  • メモリ:全体で 4〜5GB 程度

という状態で安定。

Express のメモリ制限があるおかげで、
Metabase 側がリソースを食い潰すこともなく、
結果的に非常にバランスが良い構成 になりました。


Excel 集計が激減した

ここが一番大きな成果です。

以前は、

  • 月次
  • 週次
  • 会議前

のたびに Excel 集計。

SQL を書いて → CSV → Excel → グラフ → 修正 → また SQL

正直、
何回同じことをやるんだ… という気分でした。

Metabase 導入後は、

  • ダッシュボードを1回作る
  • 条件変更は UI で操作

これだけ。

「集計作業」という作業自体が、
ほぼ消えました。


運用を楽にするために意識したこと

構築そのものよりも、意識したのはこの2点です。

  • 再起動しても迷わない構成
  • 壊してもすぐ戻せる状態

Metabase は内部 DB に設定情報を保存するため、

内部 DB ファイル(metabase.db.mv.db)をバックアップしておけば、同じバージョンの metabase.jar を用意することで、ほぼ完全に環境復元が可能です。

よって、内部 DB ファイルは 定期バックアップ対象 に。

アップデートも、

  1. 停止
  2. jar 置換
  3. 起動

これだけで済むので、
ひとり情シス運用との相性はかなり良いと感じています。


今のスタンス

正直、BI ツールは「大げさ」になりがちですが、
Metabase は ちょうどいい

  • 構築は簡単
  • 見た目はそれなり
  • 修正は UI 操作

このバランスが、
中小企業 × ひとり情シス には刺さりました。

高機能 BI を入れても、
結局使われず、Excel に戻るケースを何度も見てきたので、
「これくらいで十分」という判断に、今はかなり納得しています。


まとめ

簡単に構築できて、
見栄えもよく、
システム修正も減った。

Xserver VPS ビジネスプラン(12GB)なら、
SQL Server Express と同居させても、業務利用で特に問題は出ませんでした。

楽をするために、ちゃんと作る。

この構成は、
その考え方にかなりフィットした形になっています。


この環境の構成まとめ

WireGuard + SQL Server + Metabase を同居させた全体構成
― 現場判断ベースで作った業務環境の実例ログ ―業務環境を刷新しよう、という大きな構想が最初からあったわけではない。目の前にあったのは、何となく残り続けていたFTP構成Excelベースの集計運用老朽化したオンプレサーバという、よくある 「現...

次の記事

なぜ WireGuard を選んだか|「頑張って直す」より VPN 化したほうが早かった話
これまでの記事で、業務用のデータベース(SQL Server 2022)とBI 環境(Metabase)を VPS 上に同居させた構成について書いた。今回は、その構成の中で VPN をどうするか悩んだ末に WireGuard を選んだ理由 ...