こちらの記事から約一年。
8/03 : 契約、初期設定（UFW / fail2ban）
とあることから、実質丸一年が経過。その1年での振り返りを行ってみたいです。
2026年8月時点でのリソース使用量
--- 💻 サーバーのCPU状態 ---
稼働時間 (Uptime): 8 days
ロードアベレージ (Load Avg): 0.22, 0.22, 0.19
CPU名 (Model): AMD EPYC-Milan Processor
スペック (Speed): 2.00 GHz (1996.250 MHz)
コア数 (Cores): 4 threads
--- メモリとスワップ ---
[物理メモリ（Physical Memory）]
total used free shared buff/cache available
Mem: 5.8Gi 3.7Gi 447Mi 163Mi 2.1Gi 2.1Gi
Swap: 4.9Gi 1.1Gi 3.8Gi
[zRAM の展開状況]
NAME DISKSIZE DATA COMPR ALGORITHM STREAMS ZERO-PAGES TOTAL MEM-LIMIT MEM-USED MIGRATED MOUNTPOINT
/dev/zram0 2.9G 1.1G 254.4M lzo-rle 4 50834 261.6M 0B 948.3M 199K [SWAP]
--- ストレージ（Storage Status） ---
Filesystem Size Used Avail Use% Mounted on
/dev/vda1 145G 62G 83G 43% /
/dev/vda16 881M 222M 598M 28% /boot
/dev/vda15 105M 6.2M 99M 6% /boot/efi
s3fs 4.0G 0 4.0G 0% /mnt/wasabi2
s3fs 4.0G 0 4.0G 0% /mnt/wasabi
--- CPUを利用しているプロセス: CPU Consumers (Top 10) ---
%CPU %MEM PID USER UNIT COMMAND
------------------------------------------------------------------------------------------
8.0 4.3 796409 www-data apache2.service Passenger RubyApp:
4.4 6.8 621372 mysql mysql.service /usr/sbin/mysqld
2.8 3.6 796362 www-data apache2.service Passenger AppPreloader:
1.1 2.0 789277 www-data apache2.service /usr/sbin/apache2 -k start
0.7 2.1 784299 www-data apache2.service /usr/sbin/apache2 -k start
0.6 2.0 784297 www-data apache2.service /usr/sbin/apache2 -k start
0.6 3.9 622142 root growi.service node --import
0.6 1.8 620879 mongodb mongod.service /usr/bin/mongod --config /etc/mongod.conf
0.5 0.4 784275 root apache2.service Passenger core
0.5 0.2 622750 www-data apache2.service /usr/sbin/apache2 -k start
--- メモリを利用しているプロセス: Memory Consumers (Top 10) ---
%CPU %MEM PID USER UNIT COMMAND
------------------------------------------------------------------------------------------
0.4 11.2 479114 elastic+ elasticsearch.service /usr/share/elasticsearch/jdk/bin/java -Des.network
4.4 6.8 621372 mysql mysql.service /usr/sbin/mysqld
8.0 4.3 796409 www-data apache2.service Passenger RubyApp:
0.0 4.1 786930 www-data apache2.service Passenger RubyApp:
0.6 3.9 622142 root growi.service node --import ./bin/runtime/env-preload.mjs dist/s
0.0 3.8 796066 www-data apache2.service Passenger RubyApp:
2.8 3.6 796362 www-data apache2.service Passenger AppPreloader:
0.0 3.2 990 root mnt-wasabi.mount
0.2 2.9 789814 www-data php8.3-fpm.service php-fpm: pool www
0.4 2.8 794701 www-data php8.3-fpm.service php-fpm: pool www 何というか
- Growi
- Nextcloud
- Redmine
というメモリを食いまくるサイト（そのほかLaravel Stack）を運営していてOoM Killerが発生しなかったものだと思っています。
なぜメモリが枯渇しなかったか
アクセスを絞っている
これが一番のポイントです。筆者は広告が嫌いなので、自分のサイトにも作っていません。そのため、SEOや広告料収入によるアクセスアップを狙っていません。
「これは俺のメモ帳だ。節度を持ってアクセスする分にはかまわないがそれ以外は容赦しない」
というスタンスを貫いています。
クローラーや迷惑ボットの排除
- 一度でも不審な攻撃/その兆候を見せたら次のアクセスを禁じる「ONE OUTS」システム
- 雑なクローラーを別サイトへと転送。その推論モデルを破綻させるような文言を随所に仕込み、Webアプリの重い処理に到達させない「Jailhouse Lock」システム
更に、tcpレベルでの嫌がらせをやらかす相手にはipsetで防御。
https://barrel.reisalin.com/books/one-outs/page/ipsetddos
zRamによるメモリ圧縮
先にあった、Swapにブロックデバイスを追加することにより、スワップアウトが更に効率化しています。
https://barrel.reisalin.com/books/linux/page/ubuntuzram
AIとの対話によるセキュリティ案強化
これが一番です。Mod_Securityを「偽陽性を踏んだから単にそれをRemoveしよう」という雑な運用から
「偽陽性を踏みがちなアクション（記事の投稿、ファイルのアップロード）だけを無視する」というリアルタイム外科手術的な技法へと変換。
これにより
「攻撃は防ぐ 偽陽性は排除する おまえごときに『両方』やるのは そうそう難しいことじゃあないな」
と言えるようになったのが極めて大きいです。
結局のところ
「4GB→6GB」にスペックアップしたとしても普通に運用したらOoM Killerやアクセス過多に陥ったであろうシステムを
- 自分のサイト運営方針に則って数を絞り
- 不穏なアクセスを防ぐことが第一歩と考えた
AIの力を借りての運用という形でした。
コメントを残す