こんにちは、あまねです。
感想や興味のあるトピックについて、ぜひコメントしてください。
人間と科学
Revueが落ちていたこと
7月9日から7月10まで（日本時間）の間、このあまねけ！ニュースレターを提供しているRevueというサービスがほぼ丸一日ダウンしていたみたいです。大元の原因はDNSの浸透（！）に時間がかかり、24時間くらい名前解決に支障があったせいとのことで、大きめのサービスがやらかすとなかなかパワーがありますね。
An update: Revue is currently down, but a team is working to get it back running right now. Will let everyone know when the issue has been resolved.
@TwitterWrite (2022) 1545521002523680769
And we’re back! (…mostly, some DNS issues take time to fully resolve around the globe.) Apologies for the hassle and thanks for your patience.
@TwitterWrite (2022) 1545896228906491904
既に送信済み・障害後に送信予定のニュースレターに影響はなかったものの、障害期間中に配信されたニュースレターがちょっと影響を受けたみたいです（メール送信時の発信元確認が上手くいかなくなるのかな？と想像してます）。
メッセージのテキストはGistにコピーしてあります。
もちろん、Revueが落ちていても、あまねけ！ニュースレターをメールで購読していればすぐに記事を読むことができます！ メディアはメールに添付されないので、常にS3からダウンロードする必要がありますが、テキストメインのニュースレターなのであまり影響はないでしょう。購読者数が増えて僕が楽しくなるのでおすすめです。
UptimeKumaを使い始めたこと
先月の6月21日に起きたCloudflareの障害では、Cloudflareをバックエンドに持つサービスを使えなくなってしまって、あるいはサービスを提供できなくなってしまって困った方も多いと思います。
僕の方でも、Cloudflare Pagesで提供しているいくつかの静的サイトについて、障害発生中は閲覧できなくなっていました。先日の障害時点で影響を受けていたのは、主に変態美少女ふぃろそふぃ。 #電子書籍部とi am amane, amane.im、そして文フリ34の特設サイトです。他の特設サイトや小さなWebアプリはNetlifyで配信していたので無事でした。
また、あまねけ！は現在Firebase Hosting（CDNとしてFastlyが背後にいます）でサイトを配信しているので、こちらも障害の対象外です。ミラーサイトの一部（amanejp-9d3.pages.dev）は閲覧できませんでしたが、複数のホスティングサービスを利用しているのは耐障害性を向上させるためなので、1サイト程度のダウンは想定内の事態といえるでしょう。
さて、僕はこれまで自宅のサーバやクラウドなどで提供しているサービスの死活監視を行うために、UptimeRobotというサービスを使ってきました。これは、対象のサービスに対するHTTPやPing、TCPポートの応答を定期的に確認することで、サービスが利用可能か判定してアラートを飛ばしたりするものです。
このUptimeRobotも、どうやらバックエンドがCloudflareだったようで、同障害中はステータスページにアクセスできない状況が続いていました。障害の影響を受けてしまうのは仕方ないことだと思うんですが、いざインシデント明けにメトリクスを確認したところ、Cloudflare Pagesで提供しているサイト群があたかもずっとオンラインだったかのように表示されていて驚きました。
変態美少女ふぃろそふぃ。 #電子書籍部やi am amane, amane.im、あまねけ！(Cloudflare Pages)が落ちていたのは自分の目で確かめたので、おかしなデータが表示されている気がします。
UptimeRobotについては、これまでもしばしば5XXエラーでステータスページを表示できないことが多く、もともとあまり信頼性の高いサービスとは考えていませんでした。その割に課金圧が割と強くて（たとえば、監視対象を追加するたびに広告が出ます）、無料版ではかゆいところになかなか手が届かない使い勝手に困ることも多いです（監視間隔が長いとか、ステータスページのカスタマイズができないとか）。
そのため、今回の件を機にセルフホストの死活監視サービスに切り替えることにしました。現時点では、UptimeKumaという完全にUptimeRobotリスペクトのOSSを使っています。いまstatus.amane.moeで表示できるステータスページは、UptimeKumaのものです。おうちネットワークの信頼性が高いとは言い切れませんが、自己の財産におけるのと同一の注意義務くらいは果たせると思っています。
UptimeKumaに移行してよかったところは、シンプルで分かりやすいこと、利用できる設定の幅が大きく広がったこと、ステータスページの項目の順番を自由に変えられること、豊富なアラート先チャネルを利用できること、くらいでしょうか。今はntfy.shでステータスの変化を通知するように設定しています。
ntfy.shを使い始めたこと
ntfy.shを知っていますか？ 僕は先日このサービスを知ってから、いろいろな通知をスマホで受け取れるようにしています。
ntfyは、HTTP経由で任意のトピックにプッシュ通知を送ることができるOSSのサービスです。ブラウザやスマホアプリでトピックを購読しておけば、時間のかかるジョブの終了通知をcurlで投げたり、Webhookが用意されているサービスから通知を送ることができます。Androidアプリ（F-Droid版）とiOSアプリが用意されていますし、ブラウザからも利用できます。CLIで通知を処理するのも非常に簡単です。
先述の通り、UptimeKumaの通知手段にもntfyが用意されているので、ステータスの変化はプッシュ通知で確認できます。あとは、あまねけ！の「読んだ」ボタンでもプッシュ通知が届くようにしました。サーバーでPOSTするだけなので、実装はとても簡単です。これで「読んだ」ボタンは、レシートプリンターによる通知とスマホのプッシュ通知の両方で僕を応援するスーパー・リアルタイム・通知になりました。
ここまで、主に自分から自分にプッシュ通知を送って受け取る目線でntfyについて紹介しました。ntfyはトピックさえ共有すればすぐに通知を送れるので、アプリの利用者にプッシュ通知を送りたい開発者にとっても便利です。特に、AndroidアプリでGoogleのプッシュ通知サービス（Firebase Cloud Messaging）を使わずにプッシュ通知を実現するUnifiedPushは、実装の選択の幅を広げる点で魅力的といえます。
ntfyを利用する上で注意すべき点は、トピックを不用意に公開しないことと、サーバ管理者がペイロードを閲覧できる可能性を意識することでしょう。Privacy policyによればデータは安全に保たれますが、通知に含める情報は最小限に保つべきです。そして、どうしても機密情報を送信しなければならない場合は、Push APIのようにペイロードを鍵で保護するといいでしょう。
もちろん、ntfy.shが完全に信用ならないなら、自分でntfyサーバを立てて運用することも可能です！
アマネイメージズ
今回はありません。