Scribble at 2022-07-20 12:40:45 Last modified: 2022-07-21 11:05:55
AWS Lightsail のインスタンスでオリジンのウェブ・サーバを構築し、とあるキャンペーンのサイトで使ってきた。もう昨年の８月から１年近くも動いているのだが、キャンペーンそのものは昨年のうちに終わっているため、現在は次のキャンペーンまでの休止期間というわけである。
ところで、今月に入ってから 50x 系統のエラーが頻発するようになっている。原因を調べているところなのだが、Lightsail の「メトリクス」画面で確認できるステータス・グラフは非常に見辛いし、表示できる項目が少ないので参考にならない。でも、いまの案件では CloudFront をオリジン・サーバの前面に繋いでいるため、パフォーマンスのモニタリングは CloudWatch を使っていて、ここでステータス・グラフを見たりアラームを設定している。もちろん、ふだんは専用のダッシュボードをカスタマイズして定義し、アラートのメールが届いていなくても共有のページとして作成したダッシュボードを眺めるのが日課となっている。それにしても、どこのウェブ・サーバであっても WordPress や phpMyAdmin への〈お試し攻撃〉というか斥候のようなリクエストは、ひっきりなしにやってくるものだ。もちろん、このサーバに WordPress や phpMyAdmin は存在しない。
さて、50x のエラーはサーバの設定とか挙動が原因で起きるわけだが、特定のディレクトリやファイルではなくサイト全体となると、やはり httpd や php の挙動や設定を疑わなくてはいけない。もちろん、httpd を再起動すると再びサイトが表示されるため、DSO モジュールとしての php ではなく httpd に問題があると考えて原因を調べるのが、ひとまず妥当だろう。ただし、httpd の場合は、エラーに記録されるような段階での兆候がプロセスの停止よりも前に起きていない限り、httpd 自体のエラー・ログを見たところで原因は何も分からない。また内部の異常を詳しく記録するには、httpd のエラー・ログのレベルを debug などに引き下げる必要があるため、アクセスが多いサイトではログ・ファイルの肥大化にも注意が必要となる（１日のリクエストが数万や数十万になるサイトだと、ログ・ファイルはすぐに何ギガバイトにもなる）。
いまのところ、サーバのハードウェアに問題が起きている様子はない。この手の話題を検索すると、よく「WordPress が落ちる」というブログ記事が見つかるのだが、そういう事例はたいてい月額３ドルとか５ドルとかの貧弱なサーバを使っていて、リソース不足でサイトが重くなったり落ちてしまうことが多いらしい。その点、案件で使っているインスタンスは月額80ドルのハイ・スペックなモデルなので、もちろん高額だから故障しないなんて保証はないが、リソースが不足するということはない。現にキャンペーンを実施していたときも、多い時で１日に数十万のアクセスはあったが、たいてい CloudFront で捌いて終わっていたし、それどころか CloudFront で使っていたファンクションの挙動がおかしくなった時に、いったん CDN を外して直にオリジン・サーバでリクエストを処理する状況が起きたときですら、バーストの必要すらなく余裕で処理していたくらいだ（なら、なんで CloudFront なんて使ってるのか。これは、負荷分散だけが目的ではなく、S3 のバケットへ放り込んでオリジン・サーバへ貯めたくないログの収集や、FW としても使っていたからだ）。
ということで、Apache の設定とかモジュールの互換性とか、あるいは crontab で定期的に yum を動かしてアップデートしていた影響とか、もちろんサーバに侵入されている可能性も考慮して調べているのだが、どうも原因が分からない。そういうわけで、いまのところは対処療法として httpd のプロセスを５分おきに再起動している。インスタンス、つまりサーバ自体にネットワークやハードウェアや OS としての問題が起きておらず、httpd というアプリケーション単独の問題だと仮定すれば、これでひとまず落ちたまま数時間ほど気づかないということは防げる。もちろん、CloudWatch からのアラートはメールで受けているが、メールを読むまで放置しておくわけにもいかないため、当社のサーバに cURL 接続でターゲットとなるサイトへリクエストして、サーバのステータス・コードだけをもらってくる PHP のスクリプトを置いて、これを cron で毎分ごとに実行している。サーバのステータスが 200 以外を返して来たら、同じく cURL 接続の Webhook を使って Google Chat の「サーバ監視用」という名前のスペースにメッセージを投げるようにした。（cron を毎分実行するとログ・ファイルのサイズがどれくらいになるのか心配するかもしれないが、1,440分＝１日で 200kB ていど、１か月で 5MB にしかならない。）
もちろんだが、ゼニや人員や時間配分の問題から言って、３チームで３交代制でも敷けるチームが部下に配属されてるわけでもない個人が、いくら20年近くも一人でナショナル・クライアント案件の開発やサーバ構築をやってきた distinguished なエンジニアであろうと、24時間体制でサーバの監視とか対応作業なんてやるわけないんで。工数計算から言っても、３チームをもらったところで、キャンペーンが始まってもいないサーバの監視に月額で2,000万円とか出せる会社が日本に残ってるとは思えないね。
それから原因については、単純に AWS や Lightsail のインスタンスについて検索すると、WordPress が落ちるという話が多いと書いたが、それに関連してか Bitnami というツールにかかわる話題も多い。このところ Docker だの Kubernetes だの Bitnami だの、子供向けの遊び場を用意する福祉事業みたいなサービスがどんどん出来ているわけだけど、これって「中間段階」なんだという自覚が必要だよね。結局、この「中間段階」を越えたところにあるのは自動化なんであって、こういうツールでしか仕事ができなくなってロック・インされてしまったブルー・カラーなんて、後は履いて捨てるだけの人材となる。しょせん、国や IT ゼネコンが「コーディング学習」だの「プログラミング教育」だので育てようとしてるのは、そういう使い捨ての（安い）鉛筆みたいなものにすぎないのだという理解が必要だ。力を加えすぎると「折れる」わけだが、なーに、使えなくなった鉛筆なんて、折ったことについて労基からお小言を言われるのは困るが、適当な手切れ金を払って精神病院なり福祉施設に捨てたらいいだけだ。