いろいろまずかった

おそらく8月下旬から、本日19時頃までにかけて、ブログサイトがダウンしてました。お恥ずかしい話、気づいたのが本日の昼。まぁよくぞ気づかなかったもんだと思いました。

実は自宅からの管理用経路と外部からの経路が違うため、ほとんど気づかずにいました。ざっくり現象について、下図のとおりまとめてみました。

ここ最近、体調が悪かったこともあり、かなり監視周りはおざなりになってました。まさにとほほな話です。病院帰りの食事処で、ちょっと心配でいろいろいじってたんですが、その間にどんどん体調が悪くなり、家に帰る頃にはボロ雑巾状態になってまして・・・・
泣く泣くとりあえず横になって休みまして、19時からトラブルシュート開始と相成りました。

とりあえず、繋がるようにしよう。

原因追求はやりません。とりあえずロードバランサーが逝きました、それが直接原因ってことで納得することにしました。ただ、ここ最近DoSチックなアクセス増大が目立っていたので、それが原因だったりしないかなーと少し気になっていたりします。

というわけで、いくつか見直しもしつつ、復旧優先で下図の構成にしました。

変更箇所は以下のとおりです。

• BIG-IPを外し、MastodonやPleromaインスタンスを統括してるリバースプロキシ（Nginx)を通すよう変更
• CDNをVerizonからMicrosoftへ変更
• SSL終端はCDN(KingSSL)とNginx(Let’s Encrypt)にて行う。
  • フローとしては、「ユーザ->[HTTS]->CDN->[HTTPS]->RevProxy」
• CDN配信元となるUTMはSophos XGからSophos UTMに変更。理由は以下。
  • IPSの感度が高い
  • 比較的まっとうにDoS検知ができる
  • ポートスキャンのガード・通知がしっかりできる

ただ、これまでのロードバランサーとは異なり、単純なラウンドロビンしかできないので、プールメンバがダウンしたときのアクセス除外ができない点は留意したほうが良さそうです。
とは言え、Kubernetesのオートヒーリング機能があるので、あまり気にしなくても良いのかな？という気がしないでもないです。

苦戦したポイント

とにかく当時組んだノウハウが頭から吹き飛んでいて、概要レベルは理解していたのですが、細かいところでポート番号の関連性や、通信フローなどが分かってなくて、そこを紐解くのに苦労しました。

特に、AzureCDNの設定に苦戦していて、配信元サーバの定義やそのFQDN、ポート番号、オリジン側の定義についてはだいぶ画面をウロウロするはめになっています。

設定もかなり頻繁に変える状況が発生したので、Azure CDN Verizon Standardよりも反映に時間がかからないAzure CDN Microsoft Standardに戻しています。Azure CDN Verizon Standardは設定変更から反映に最大90分かかると言われてますが、Azure CDN Microsoft Standardは最大10分と、反映に時間がかからない点はメリットかなと思います。

ページルールが構成できない点はデメリットですが、まぁ、外部から設定をするようなことは想定してないので、キャッシュしようがしまいが別に構わないかなーというお気持ちで。

五体満足って大事

私自身、こうして趣味でいろんなものを自宅で組み上げて動かしてるわけですが、それをやるにも体力って必要だなぁと。こんなに心身ぼろぼろになると、トラブルシュートもままならんなぁと思いました。

精神的につらいのも相当ですが、肉体的な辛さはそれをあっさり凌駕するなぁと感じています。今年いっぱいかなり厳しい闘病を強いられるっぽいんですが、ちょっと仕事のペースについて（今でもだいぶ落とさせてもらってるけど）、更に落とさないといけないのかなぁ・・・つうか、入院ぐらいしたほうが良いのだろうか・・とちょいと悩ましい状況にはなっています。

とはいえ、おそらく今月の鍋底状態は今なんだろうから、そこを基点として今後の戦略を考えていきたいですね、はい。