前回の記事で なぜ 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 ファイルは 定期バックアップ対象 に。
アップデートも、
- 停止
- jar 置換
- 起動
これだけで済むので、
ひとり情シス運用との相性はかなり良いと感じています。
今のスタンス
正直、BI ツールは「大げさ」になりがちですが、
Metabase は ちょうどいい。
- 構築は簡単
- 見た目はそれなり
- 修正は UI 操作
このバランスが、
中小企業 × ひとり情シス には刺さりました。
高機能 BI を入れても、
結局使われず、Excel に戻るケースを何度も見てきたので、
「これくらいで十分」という判断に、今はかなり納得しています。
まとめ
簡単に構築できて、
見栄えもよく、
システム修正も減った。
Xserver VPS ビジネスプラン（12GB）なら、
SQL Server Express と同居させても、業務利用で特に問題は出ませんでした。
楽をするために、ちゃんと作る。
この構成は、
その考え方にかなりフィットした形になっています。
この環境の構成まとめ
次の記事
