最近ブログをリニューアルしたついでにアクセス解析も始めることにした。宗教上の理由でGoodle Analytics には頼らずなるべくセルフホスティングで動かしたい、ということで、OSSのPlausibleを試すことにした。
デフォルトの設定で起動するだけなら簡単だったが、自分の構成ではいくつかトラブルがあったので、それについて。
要約
- 普通に動かすなら公式の
docker-compose.ymlで簡単に起動できる - PostgresqlをDocker外のホスト上で動かしてアクセスするには…
-
localhostの代わりにホストのインターフェースのIPを指定する。 - データベースは事前に作成、設定をしておく
-
docker-compose.yml上のデータベースの作成のコマンドは削除しておく
-
- メールが送信できない環境では（アカウントの認証ができないため）Postgresql上で直接認証済みに書き換える
- LightsailのCPUは1コアのうち常用できるのはさらにその一部。持続可能ゾーン（Sustainable zone）に収める必要がある。CPUバーストキャパシティーが尽きるまでは問題なく動くので注意。
要件
- Access解析ツールとしてPlausibleをVPSで動かす
- VPSはAWS Lightsailで最も安価な3.5USDのUbuntuインスタンス
- 結局パワー不足だったので5USDのプランに上げた
- Postgresqlはすでにホスト上で稼働しているのでこれを利用する
公式のdocker-compose.ymlにpostgresqlも含まれているが、これは利用しない。
バージョン情報
$ uname -a
Linux <略> 5.11.0-1022-aws #23~20.04.1-Ubuntu SMP Mon Nov 15 14:03:19 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
$ psql --version
psql (PostgreSQL) 12.9 (Ubuntu 12.9-0ubuntu0.20.04.1)
$ docker -v
Docker version 20.10.11, build dea9396
$ docker-compose -v
docker-compose version 1.25.0, build unknown
plausible/hostingのコミットidは以下1
$ git log -n 1 --oneline origin/master
f768205 (origin/master, origin/HEAD) Merge pull request #40 from oscartbeaumont/master
Plausible について
OSSのGoogle analyticsの代替の一つ。いくつか選択肢があった2が、今回は
分散処理が得意3らしいelixir製のplausibleを導入することにした。
なお、分散処理でアクセス負荷に強いからといって、貧弱なサーバで動かせるくらいにアイドル状態での負荷が少ないわけではないことは後から知った。4
起動
Getting started | Plausible docs
起動自体は公式のドキュメント通り、公式のdocker-composeで簡単に動かせる。
データベースの設定
公式の docker-compose.yml ではDocker内で専用のpostgresqlを動かしている。しかし今回の公開用のサーバはすでにpleroma用のpostgresqlが動いているため、これを利用したい。
データベースの初期化
Dockerコンポーズでは起動時にデータベースの作成等も行っている。今回は共用のpostgresqlを使うため、当然だが、管理者権限でのアクセスはさせない。
ということで、先にユーザーとデータベースは作っておく。
ユーザの作成
$ sudo -u postgres createuser -P plausible #パスワードありでユーザーを作成
$ sudo -u postgres createdb -O plausible plausible
データベースの設定に関して、管理者権限が必要な設定もあるので、これもやっておく。
$ sudo -u postgres psql plausible
postgres-# CREATE EXTENSION citext;
Postgresqlのアクセス制限の設定
デフォルトではpostgresqlはローカルホストからのアクセスしか受け取っていないので、他のホストからのアクセスを可能にする。
ipの制限についてはFWや次に設定するpg_gba.confなどでもできるので、ここでは管理をシンプルにすることを優先し全体に公開する
- listen_addresses = 'localhost'
+ listen_addresses = '*'
pg_hba.conf でplausibleユーザにプライベートネットワーク（Docker含む）からのアクセスを許可する。
# TYPE DATABASE USER ADDRESS METHOD
<中略>
# IPv4 local connections:
host all all 127.0.0.1/32 md5
+ host plausible plausible 172.16.0.0/12 md5
外部データベースの指定
plausibleでの外部データベースの指定を以下のように設定
- ユーザ名: plausible
- ホスト名: postgres
- 宛先ポート: 5432
- データベース名: plausible
#中略
#DATABASE_URL=postgres://localhost:5432/plausible_dev （デフォルト）
+ DATABASE_URL=postgres://plausible:<password>@postgres:5432/plausible
この段階ではpostgresという名前のホスト名はIPと紐づいておらず、動かない。
紐付けはdocker-compose.ymlの方で設定する。
docker-compose.ymlの修正
起動時にデータベースの作成をしないようにする。
postgresql の削除
- plausible_db:
- image: postgres:12
- restart: always
- volumes:
- - db-data:/var/lib/postgresql/data
- environment:
- - POSTGRES_PASSWORD=postgres
plausible:
#中略
depends_on:
- - plausible_db
- plausible_events_db
- mail
データベースの作成の省略
plausible:
image: plausible/analytics:latest
restart: always
- command: sh -c "sleep 10 && /entrypoint.sh db createdb && /entrypoint.sh db migrate && /entrypoint.sh db init-admin && /entrypoint.sh run"
+ command: sh -c "sleep 10 && /entrypoint.sh db migrate && /entrypoint.sh db init-admin && /entrypoint.sh run"
#中略
ホスト名 postgres とIPの紐付け
plausible:
#中略
env_file:
- plausible-conf.env
+ extra_hosts:
+ - "postgres:<サーバのIPアドレス>"
IPアドレスについては、ip -aで出した一覧のうち、eth0のプライベートIPを使用した。
あらためて起動
$ sudo docker-compose up -d
これで期待通りにホストのpostgresを使うようになった。
メール認証のスキップ
最初の管理ユーザーはplausible-conf.envで指定したユーザ名、メールアドレス、パスワードを元に起動時に作られる。しかしこの管理ユーザでも初回ログインの前にメール認証が必要となっている。
今回の環境ではメールが受け取れず5、ログインまで進めない。
ここによると、メール認証の無効化は設定できないが、データベース上で無理やり認証済みに書き換えるという荒技で解決できるとのこと。
早速試す。
sudo -u postgres psql plausible
postgres-# UPDATE users set email_verified=true;
これでログインできた。
CPU負荷の異常への対応
問題の発生
起動後ある程度たつとsshでのアクセスが非常に遅くなるという問題が発生。
plausibleのリソースの問題かと思い、docker statsで確認してみる。
$ sudo docker stats
CONTAINER ID NAME CPU % MEM USAGE / LIMIT MEM % NET I/O BLOCK I/O PIDS
7ebcd86ab89f hosting_plausible_1 260.15% 17.65MiB / 465.7MiB 3.79% 3.21GB / 3.81GB 1.84GB / 3.87MB 24
31cf05c8ffb3 hosting_plausible_events_db_1 200.14% 13.85MiB / 465.7MiB 2.97% 1.15GB / 2.03GB 4.52GB / 106kB 46
93581f2dd30e hosting_mail_1 0.00% 932KiB / 465.7MiB 0.20% 33.3kB / 89.2kB 1.59GB / 655kB 1
CPUの使用率がやばい。
LightsailでCPUを増やすにはかなりプランを上げる必要があるが、予算的に現実的ではない。諦めて別の手段を検討しようとした時、ふとLightsailにはバーストという、一時的に計算リソースを増やす機能があったことを思い出す。
これは起動直後は問題なかったという状況的にも関係していそう、ということで調べてみた。
持続可能ゾーンの確認
AWSのCPUはバーストという、上限付きで計算資源を増やせるという機能がある。てっきりオーバークロック的な上限突破的なイメージがあって勘違いしていたのだが、実態としては通常状態が著しく速度制限されるというのが近い模様。
今回の$3.5のインスタンスだと5%が持続可能ゾーンの上限であり、CPUバーストキャパシティーの貯金がある間は問題なく動くが、これが切れた段階で5%に制限される模様。
AWSコンソールで確認したところ、バースト中の消費は5%以上10%以下といったところ。
CPU数と違い、持続可能ゾーンの上限はメモリ同様、プランごとに緩和され、今回であれば月$5のひとつ上のインスタンスで10%になり、足りるはず。これなら予算的に許容範囲ということで、早速アップグレードする。
結果
$5に上げた後の様子が以下。
ちゃんと10%のラインに収まっている。
実際のPlausibleのダッシュボードはこんな感じ
こんな雑なブログに一日10人弱の来客があることが分かり、うれしいやら恥ずかしいやら複雑な気持ち。