Scribble at 2021-01-22 11:39:28 Last modified: 2021-01-22 14:12:41

今日は朝から、自社運営のサイトを公開してるウェブサーバで極端に負荷が上がっていた。Zabbix では CPU 負荷のグラフは更新が遅いので分からなかったのだが、ちょうど yum でパッケージを 700 個くらい更新していたあいだに fail2ban server のメモリ利用率が 80% を超えてきて、"ksqapd0" というプロセス（メモリ・スワップの管理プロセス）が CPU の負荷をどんどん上げてきた。結局、Tera Term Pro で top コマンドの画面を眺めているあいだに、あれよあれよと load average が 25.0 なんて値になってしまい、ターミナルで何かコマンドを打とうにもキーの入力シグナルがサーバ側に届いてターミナル側にも反映されるのが遅くなり、対処できなくなってしまった。

こういうときでも、機械的にずっと DoS 攻撃されているわけでもないなら、たまに負荷が下がるタイミングがある。そのときにログなどを調べてみると、もちろん ssh に対する攻撃で secure のログ・ファイルが巨大になっており、しかも logrotate で week の更新だから１週間分のログとなっていた。これを、ひとまずは daily の大きさとして更新するように改めてローテーションしなおし、fail2ban も再起動した。そのあいだも、公開しているサイトを見ながら作業していたのだが、サイトの表示には全く影響ないんだよね。WordPress で動いているサイトだが、プライム・ストラテジー社の KUSANAGI を OS としているため、最初からページのキャッシュが効いていて、ページの表示はキャッシュをレスポンスしている限りは全く問題ない。ただし、キャッシュを捨てて表示し直そうとすると、かなりキャッシュの作成に時間がかかるようだ。

そもそも、アクセスされていないサイトということで、途中から CPU 1 x メモリ 1GB というスペックにスケール・ダウンしているため、まぁ重いと言えば重い。こんな具合に、作ってはロクに運営せずに放置されてゴースト・タウンと化してゆくサイトがたくさんあって、数年ほどすると整理の対象となる。ただし、このサイトは外部のベンダーと共同で有料サービスのサイトとして設計し直しているらしいから、そのベンダーが構築する新サイトは AWS を使うらしいので、どのみちこのサイトはそれまでの〈仮組み〉みたいなものである。よって、動作が重くなってもインスタンスをスケール・アップするつもりはない。ただ、攻撃されるのは困るので、酷い場合はこうして対処（本質的な解決ではないし、そもそも DoS 攻撃だろうとブルートフォースだろうと、攻撃されることに「解決」などない）はする。