Scribble at 2022-09-07 09:42:56 Last modified: 2022-09-08 00:04:38

受託の案件で使ってる AWS Lightsail のインスタンスで走る Apache が不安定だ。ここ数か月で３回もクラッシュしているため、８月から crontab で５分おきに httpd のプロセスを強制で再起動している（こうすると、プロセスが落ちていようがいまいが httpd を起動させることになる）。

上のグラフは 400 系統の HTTP レスポンス・コードと 500 系統の HTTP レスポンス・コードの二系統だけを、５分の間に受け取ったレスポンスの何割を占めているかという比率を表している。よって、グラフがいちばん上まで届いている場合は５分のあいだずっと 400 系統か 500 系統の HTTP レスポンス・コードしか受け取らなかったという意味になる。そして、400/500 系統の HTTP レスポンス・コードというのは、長々と書いているが要するにエラーであり、とりわけ 500 系統はサーバ・プログラムである httpd (Apache) で何か処理や挙動に問題が起きているということである。ただ、少なくとも 500 系統の HTTP レスポンス・コードを〈返却している〉ということは、サーバのプロセスが停止しているというわけではないのだから、Lightsail のインスタンスで SSD のストレージに不良セクタがあるとか、そういった物理的な問題であるとは限らない。

グラフでお分かりのように、最初はウェブ・サーバに問題があることに気づかなかった。そもそも、このサーバで公開しているサイトは既に昨年の暮れで終了したキャンペーンの告知を掲載しているだけの用途しかなく、静的な１ページをレスポンスしているだけである。よって、PHP すら動かしていないため、実装したり配置したコンテンツに何か問題があるとは思えないし、ページは最初にダウンロードして、怪しいコードが埋め込まれていないかどうかも確かめた（なおコンテンツの制作は全て下請けの仕事である。僕はインフラ全般を管理している）。

メトリクスでは６月の後半ごろから急に 500 系統のレスポンスが増えている。この CloudWatch メトリクスはキャンペーンを開始する前の2021年8月から設定して、僕が（それに見合う費用なんてほとんど出てないのに）ルーチン・ワークとして頻繁にグラフを眺めているため、それまでは httpd のプロセスが 500 系統のレスポンスを返すなんて事例が起きていなかったのは確かだ。それが急にエラーを返すようになった。

ところで、グラフだけだとスケールが粗くて 500 系統のレスポンスが１回だけ起きても見た目では分からない。６月のように見た目ですぐに分かるほどの状況ならともかく、このグラフでは分からないことが多い。そして、実際にグラフではエラーが起きていないように見えていても、実際にはサイトへアクセスできなくなるという状況が何度かあった。よって、レスポンスをもっと高い頻度で見る必要があるし、そのスケールで分からない場合でもコンテンツを返せるようにサーバの設定を調整しなおす必要がある。

まず最初にやったことは、エラーが起きようと起きまいとコンテンツを返すようにサーバを復旧させることだ。これも原因と関係があるのかどうか調べなくてはいけないのだが、500 系統のエラーを返しているサーバでも、プロセスを再起動してやると正常な状態に復旧することが分かった。よって、冒頭でも書いたように httpd プロセスを cron で５分おきに再起動するよう設定した。これで、いまのところ原因は不明のままだが、サーバ（つまりウェブ・ページ）が５分以上も利用できなくなるという状況はなくなった。それでも最大で５分はページにアクセスできなくなる可能性が残る。いまのところ問題は深夜や早朝にだけ起きているが、もちろんこれから再びキャンペーンでサーバが利用されることになってから、日中に問題が起きるかもしれない。

https://philsci.info/archive/note.html?date=20220809104031

・・・という話は、実は先月にも書いた。しかし、原因がどうもわからない。わざわざ詳細な debug レベルのログを取得しても、まったく前兆も何もなくいきなりサーバが停止しているように見える。そして、エラーの種類を調べると 504 つまりタイムアウトしているため、httpd のプロセスが停止しているわけではないということも分かった（ウェブ・サーバのプロセスが停止したら、レスポンス・コードを返却するという動作すら実行不能になる）。たかが静的なページ１つをレスポンスするのにタイムアウトするようなリソースを使うとは思えないのだが、ひとまず数日前にスワップも導入した。16 GB のメモリを積んだインスタンスで、しかもアクセスだって殆どないサーバのファイル１つをレスポンスするのにスワップが必要だとは思えない。でも、他のアプリケーションの運用で必要になるかもしれないから、ひとまず 8 GB ていどの領域をスワップ・ファイルに充てた。なお、他のアプリケーションで必要だと言えば、その典型は不正アクセスのブロックという処理だ。オリジン・サーバ（表側の CDN ではなく、コンテンツを CDN に提供する元のサーバ）へ直接に不正なアクセスが加えられるとき、その大半は WordPress や phpMyAdmin といった定番のソフトウェアのファイルを、インストールされていようがいまいが手当たり次第にアクセスしてみるというリクエストだ。これは、既に20年くらいウェブ・サーバの運用を仕事として続けているからには分かっているため、敢えて気にするようなことでもない。また、その次に多いのが ssh へのログインだ。これも、パスワードで認証せず鍵認証を使っていれば何の問題もない。ただ、アクセスそのものは大抵のウェブ・サーバにやってくるだろうから、おおむね DoS 攻撃のスケールとも言えない負荷であれば放っておいてもいい。心配なら OSSEC のような IDS を導入しておけばいいだろう。Lightsail では、そこまでの対策は管理画面ではとれない。そこまで管理画面で対策したいなら、インスタンスを Lightsail から EC2 に移すことをお勧めする。

原因については、前後に起きた変化という点だけで言えば、もちろん Apache のアップデートだろう。CVE-2022-31813 の報告により、2022年6月に Apache は 2.4.54 にアップデートしている。ちょうど問題が起き始める前にあった大きな変化といえば、これくらいだ。しかし、このバージョンで不具合が頻発しているという話は聞かないので、いま使っているインスタンスの物理的な問題という可能性も残る。

[追記] とかなんとか書いているあいだに、またサーバが落ちていたらしい。スワップを設定したら、余計に不安定になったようだ。これでは正式に再びキャンペーンで利用するときも不安が残る。なので、もう Lightsail での運用は諦めて EC2 にインスタンスを作り、そちらへ現状の静的ページに使うコンテンツだけ移設して、CloudFront のオリジンを EC2 に向けることとした。CloudFront も不要と言えば不要だが（せいぜい１日に10アクセスもない）、CloudFront に SSL サーバ証明書や Route53 の DNS 設定が連携しているため、ここを変えるとさらにややこしくなるため、今回はオリジンだけを変更することにした。

[追記：2022-09-07] さきほど23:35から組み換えの作業を開始した。ちなみに、IaaS 側の調整やアップデートやセキュリティ対策や運営の全般は僕に全権が委託されているため、この作業は広告代理店にもトップクライアントにも通知はしていない。そもそも、そんなことをしたら最初から素人相手に AWS の仕組みからインターネット（DNS）の仕組みやら、いちいちパワポで解説資料を作り、相手のさらに無知なジジイどもの決裁を待つという途方もない時間がかかるし、たいていは（リスクがなければ）我々の好きなようになって結果は同じだ。同じ結果を引き出すのに数か月と大勢の判子が必要なのがリスク管理というものだから、僕も ISMS やプライバシーマークの実務家としてアイデアはわからなくもないが、上場企業の無能どもというのは、要するにそれを自分の仕事として切実に理解もしていないし、自分が何について決裁しようとしているかもわかっていない。それなら、黙ってわれわれ有能な人間に最初から全権をゆだねればいいのだ。それで結果がよくても悪くても、おまえたち離散数学や確率論の勉強から IT について学ぶ意欲も能力もない無能が社内政治と金勘定だけでものを考えるよりはマシである。

ということで、まずは Lightsail 側のインスタンスを停止する。この時点でサイトの表示ができなくなるので、いかに深夜の作業とは言っても時間をかけてはいけない。CloudFront では、このインスタンスを対象として「ビヘイビア」を定義していたため、ビヘイビアの対象を EC2 の新しいインスタンスがもつパブリック DNS 名に変更し、Lightsail のオリジン（ロードバランサのパブリック DNS 名）設定を削除した。ビヘイビアが従来の DNS 名を向いていると、まだ使ってるオリジンだと判断されて削除できないので注意したい。これで、ビヘイビアが全て新しいインスタンスへ向いたので、ひとまずサイトの表示は復旧した。ここまでで５分である。

あとは、Lightsail のロードバランサから同じく Lightsail で建てた旧ウェブ・サーバのインスタンスをデタッチして、ロードバランサそのものも破棄する。旧ウェブ・サーバのインスタンスは、コンテンツをバックアップしなくてはいけないので、これはキャンペーンで応募してもらったデータから合成した大量の画像ファイルが保存されていて、MySQL のデータベース・ファイルもあるため、全てダウンロードするには時間がかかるから、別の日に改めてインスタンスを起動して WinSCP でアクセスすることにしたい。それが済めば、旧ウェブ・サーバも破棄して、Lightsail は全く使わないようになる。今後、再びキャンペーンでサーバを使うという話はあるのだが、そのときは新しい方のサーバで外注さんには作業を依頼したい。