【宅鯖×電子書籍配信】いろいろ試したけどKavitaで妥協した

「サーバーで動かしているツールを見直そう」プロジェクトのトリとして、今日は電子書籍配信サーバーを考えてみようと思います。

今動いているのは Komga です。もともとはcalibre-webを使っていたのですが、本を手動で追加する必要があるのが面倒で乗り換えていました。

ただこのKomga、めちゃくちゃリソースを食います。メモリ使用量はなんと1GBオーバー！うちで動かしている中では１、２を争うレベルの重量級です。これほどのリソースほんとに必要なのか…？

全然納得いかなかったので、セルフホスト電子書籍配信サービスをいくつか試してみました。その結果…気に入るものはありませんでした。
が、いろんな端末から電子書籍が読める環境はどうしても必要だったので、しかたな〜く Kavita を使うことにしました。

このカテゴリのツールはDockerを使っても構築が面倒なやつが多く、試してみるのも大変なので後続の人たちのために簡単な使用感とリソース消費を記しておきます。

比較
セットアップ

比較

Komga

クリックするとデモにとびます（ユーザー:demo@komga.org / パスワード:komga-demo）

JVM言語のKotlin製です。昔Androidアプリの開発にKotlinを使っていた経験から軽量なイメージがあったのですが、PCで動かすと一番の重量級でした。よくよく考えるとAndroidのJava/Kotlinはネイティブコードに変換されているわけで、そりゃ軽いですよね。対してPC上のJava/KotlinツールはJVM上で動くように書かれているので、アイドル状態でも結構なリソースが必要になります。

操作感は悪くなかったです。指定フォルダにいれた本は自動でスキャンされますし、ビューワーも使いやすいというほどではなくともまぁ使えるレベルでした。

CONTAINER ID   NAME           CPU %     MEM USAGE / LIMIT    MEM %     NET I/O           BLOCK I/O        PIDS
381d23d013bc   komga          0.64%     1.488GiB / 3.88GiB   38.34%    732kB / 2.72MB    366MB / 2.33MB   53

この凄まじいメモリ使用がなければなぁ

Caribre Web

Caribre Webをブラウザで開いたところ

だいたい200〜400MBくらいのリソースを消費して速度もそれほどなツールが多いPython製

動かすためには手動でdbファイルをダウンロードしてくる必要があり、本も手動でアップロードする必要があったりとユーザー体験がよくないです。

CONTAINER ID   NAME           CPU %     MEM USAGE / LIMIT    MEM %     NET I/O           BLOCK I/O        PIDS
d2150a5ef076   calibre-web    0.01%     211.4MiB / 3.88GiB   5.32%     912MB / 5.5MB     950MB / 1.72GB   22

Calibre Webもご多分に漏れずなメモリ消費量でした。ただこれでも今回試したやつだと一番軽量だったんですよね。世の開発者たちはメモリがありあまってて省リソース追求の動機が薄いのでしょうか？

Stump

Stumpをブラウザで開いたところ

軽量なイメージのあるRust製

ページデザインはすっきりしていて非常に好みですし、ファイルの階層構造に基づいてシリーズ化して表示してくれるのも嬉しいです。ただビューワーの出来は非常にお粗末。操作感も悪いですし画質がものすごく荒いです。一昔前のFLASHみたいなガビガビ具合なのでさすがにキビしい

CONTAINER ID   NAME           CPU %     MEM USAGE / LIMIT    MEM %     NET I/O           BLOCK I/O        PIDS
f6fc3d1bdcbe   stump          0.00%     356.5MiB / 3.88GiB   8.97%     1.69MB / 78.8MB   200MB / 0B       9

Rustなのにメモリ消費はちょっと多いですね〜

Kavita

クリックするとデモにとびます（ユーザー:demouser / パスワード:Demouser64）

Unityと.NETのイメージが強いC#製

ファイル階層構造は最小単位のフォルダをシリーズとして認識するだけで、「漫画」とか「技術書」とかフォルダ分けしていても展開されてしまいます。ビューワーの使い勝手は及第点といったところですかね。

CONTAINER ID   NAME           CPU %     MEM USAGE / LIMIT    MEM %     NET I/O           BLOCK I/O        PIDS
28d8ea0460ba   kavita         0.66%     282.6MiB / 3.88GiB   7.11%     1.32MB / 46MB     395MB / 1.99MB   51

C#製なのでやっぱりリソース消費はちょい大きめです。メモリだけじゃなくCPU使用率が高いのも気になるところ

全体

	CPU	RAM（MiB）	本の自動スキャン	ビューワーの使い勝手
Komga	0.64%	1488	○	○
Caribre Web	0.01%	211.4	×	○
Stump	0.00%	356.5	○	×
Kavita	0.66%	282.6	○	○

全体のリソース消費と使い勝手をまとめるとこんな感じ

正直どれも満足いくレベルではないですが、致命的な欠点がないKavitaでひとまず妥協することにしました。が、たぶん近いうちに自分で作っちゃうと思います。お楽しみに

追記 (2025/8/5)：

つくりました！アイドル時20MiBでいい感じ↓

セルフホストできる軽量な電子書籍配信サーバーをつくった

セットアップ

services:
  kavita:
    image: jvmilazz0/kavita:latest
    container_name: kavita
    ports:
      - "50080:5000"
    volumes:
      - /Volumes/HDD/public/books:/manga
      - ./config:/kavita/config
    restart: unless-stopped

docker-compose.ymlを作成し、書籍フォルダへのパスをよしなに変更して
docker-compose up -d すればOK

あとはwebでアクセスすれば初期設定が始まります。

アプリなどを作ったりしています! よかったらみていってください→ つくったもの
今のイチオシ↓

DVDプレーヤーの待機画面を再現するアプリをつくったよ