Growi運用サーバーをEC2(t3.micro)からIndigoの2GBインスタンスに移行した話

AWS
2023.11.13

Growiは重い

MITライセンスで自由に使えるWikiツールであるGrowiはDockerイメージを活用したセルフホスティングの手厚いサポートがあり、私も利用しているのですが、Growi5系から利用できるページツリー機能や、ページ数の増大に伴って快適性が損なわれてきたのでサーバー構成の見直しを行いました。
現状t3.micro(1GB)を使っているのですが、topコマンドでメモリの仕様状況を確認すると500MBほどSWAPに乗っている状態…そりゃ重いわってことで。
なれば2GBメモリにすれば…と思いつつ、t3.smallだと月額費用が倍増してしまうので前から気になっていたWebArena IndigoでGrowiをインストールしてみた、という話。

特定ページを読み込むのに時間が掛かっている、の図。

IndigoでUbuntu22を立ち上げる

Indigoの場合、メモリ2GBのインスタンスが月額上限814円とのことで、昨今の円安事情も鑑みるとAWSの1GBインスタンスであるt3.microよりも安く、倍のメモリが確保できます。Indigoがローンチされてすぐの頃に安いVPSが出たぞと界隈でかなり話題になり、当時は会員登録出来てもインスタンスの在庫が無くて始められない、というまさかのログインゲームをVPSでも味わう事になったのですが、最近は在庫状況も安定しているためか、気軽に始められそうな感じです。

SSH～Growiの構築

Growiはバージョンによって破壊的なオペレーションの変更も考えられるので、オフィシャルの資料を確認しながら進めます。

$ ssh -i {作成した秘密鍵}.pem ubuntu@{IPアドレス}

まずIndigoの立ち上げたサーバーにSSHして、スワップを作っておきます（念のため）

sudo su -
dd if=/dev/zero of=/swapfile bs=1M count=2048 && chmod 600 /swapfile
mkswap /swapfile
swapon /swapfile
echo "/swapfile  swap   swap    defaults   0 0" >> /etc/fstab

スワップは2GBほどディスク容量を食いますが、Indigoの2GBインスタンスは40GBのストレージが割り当てられるので余裕です。何があるか分からないのでメモリの少ないインスタンスを立てる時は必ずスワップを設定しておきましょう。

apt install docker-compose
git clone https://github.com/weseek/growi-docker-compose.git growi

Gitはすでに入っているので、docker-composeだけは入れておきます。
growiディレクトリに移動してdocker-compose.ymlを編集。

/root/data/growi_data:/data <- バックアップとデータ永続化のためにvolumeに絶対パスを付けておく

とりあえずportsだけドキュメントの通り開放しておけば良いと思います。

CodiMD連携

複数人同時編集にも対応したいのでこのへんのテキストをもとに作業します。

cp examples/integrate-with-hackmd/docker-compose.override.yml .
vim docker-compose.override.yml

ここでライフハックなのですがCodiMDの面倒を見る気がないので、CodiMDで使うMySQLのperformance_schemaを無効化します。
※多分200MBくらい減る
ただでさえメモリがカツカツな場合、MySQLに余計なリソースを割かないために以下は有効だと思います。

--docker-compose.override.yml
      - ./mysql:/etc/mysql/conf.d <- 最終行に追記

--mysql/my.cnf
[mysqld]
performance_schema=off

HTTPS化(Let’s Encrypt)対応

cp examples/https-portal/docker-compose.override.yml ./docker-compose.override2.yml
vim docker-compose.override2.yml

DOMAINS: 'wiki.◯◯.net -> http://app:3000, hackmd.◯◯.net -> http://hackmd:3000'
# 運用するドメインに合わせて適宜書き換え

ここまで終わったらwiki、hackmdドメインの向き先をサーバーのIPアドレスに設定してdockerを起動

docker-compose -f docker-compose.yml -f docker-compose.override.yml -f docker-compose.override2.yml up -d

いい感じに動いてくれるはず。

移行後。だいたい倍以上早くなった

そんなこんなで起動を確認したらデータ移行を行う。
基本的な戦略としては移行前のインスタンスと以降後のインスタンスのバージョンが同一の場合はバックアップデータをscpなりで移行すれば良いし、違うなら設定ファイル消失回避のためにエクスポート機能でjsonでデータをエクスポートしつつ、移行前のGrowiを最新版まで上げてデータディレクトリをzipにまとめてscpすればOK。私の場合はGrowiを5系から6系に上げるオペレーションで何故かSSOやS3連携周りが全て空欄になってしまったので、バックアップは入念に取っておいたほうが良さそう。

移行後、hackmdのセッションを繋いだ状態のtop

移行後の状態。ちょっとswap乗ってますがほとんどオンメモリで処理しているので良い感じですね。

費用は月額814円と抑えつつ高速化したGrowi環境が手に入るので、Indigo、かなりオススメです

t3.largeとIndigo 8GBインスタンスの価格比較

じゃあ3年RI全額前払と比較してどっちが安いのよ、と調べてみるとt3.largeの場合36ヶ月で1075ドル（1ドル150円換算で約16.1万円）。
Indigo 8GBインスタンスは月額3410円、36ヶ月で12.2万…と、転送量その他コストがバンドルされていると考えると異常な安さが見られるが、やはり美味しいものには理由があるということで、本サービスには高負荷に対する利用制限のガイドがあります。

引用：https://web.arena.ne.jp/indigo/spec/guide.html

PVやHit数あたりで見るとぶっちゃけWordpress運用なんか不可能では？っていう指標が提示されていて、「高負荷で悪さをすると制限掛けるで！」っていうのは当たり前にしても、この指標はあまりにアレなんじゃないかと。
昨年末にはKusanagiのOSテンプレートを提供開始したPRも出ているし、極端にDisk I/OやCPUのロードアベレージが高い構成にしなければ怒られることは無い気もしますが、計算資源や常に回り続けるバッチ目的で利用するのは注意が必要。
Growiはメモリを食う割に他のリソースに対しては優しめなので、そのへんもまあIndigoのサービス特性と相性が良いんじゃないかなと。
一方、エンタープライズ向けのIndigoProは8GBインスタンス（ハイメモリプラン）で月額7,300円(36ヶ月26.2万)と、既存クラウドからわざわざ足を伸ばすには動機が薄くなってくる。

補足：障害頻度について

サービス開始の初期は結構アレだった

Indigo初期からアカウント自体は持っていたので過去の障害メールとかも全部見れるのですが、ざっと見た感じ最近はほとんど障害報告も無さそうで、インフラ面もある程度安心できそう（とはいえSLAは提供無し。）
VPSという性質上、パブリッククラウドのような柔軟なネットワークのルーティングは組めない点もあるのですが、セキュリティや安定性を許容できる用途で、例えばステージング環境のDBなりRedisなり疎結合なサービスをVPSで運用したり、Mattermost(Slack代替のOSS)やn8nのセルフホスト版等、万が一のユーザー影響を許容できる限りで色々使い道のアイデアは出てきそう。

ただエンタープライズとして見ると安定性を得るためにIndigoを見れるインフラエンジニアが別途必要になったり、そもそも高可用性を満たすためのサポート機能は薄いので、ざっくり運用コストを削減したい中小企業向けとしてならまぁアリかなあといった所です。
※オンプレ運用の知見に長けた大企業ならこういうVPSでも上手いこと使いこなせるのかもしれないけど、私にはその知見が無い