RM-BLOG

IT系技術職のおっさんがIT技術とかライブとか日常とか雑多に語るブログです。* 本ブログに書かれている内容は個人の意見・感想であり、特定の組織に属するものではありません。/All opinions are my own.*

ひなっちのおはっちのサイトをsunsetする

GCP IT人の雑談

はじめに

ひなっちのおはっちのサイトを停止することになった（停止せざるを得なくなった）。その辺りの記録と、サイト開発までの振替りをしていきたいと思う。

経緯

3/30に発表されたTwitter APIの新プランでは、Freeプランにおいては、TweetのPOST（書き込み）とUserのlookupのみが許可されるという形になった。ひなっちのおはっちのサイトのデータ更新は、Cloud Functions内で、Twitter APIを実行してデータを参照する処理がガリガリに組み込まれており、書き込みだけでなく参照の権限も必要である。新Freeプランでは、書き込みの権限は与えられても読み込みの権限は与えられないため、現状の機能性は維持できない。正確に言うとお金払えば読み込みの権限付きのプラン（Basic）を使えるんだけど、月$100はこのシステムを維持するには個人的には高すぎる。このためsunsetせざるを得ないという運びになった。
…とかそんなことを考えていたら、2023/4/3の夜間（日本時間）くらいから、IFTTTのTwitter連携のアプレットが根こそぎ全部Failedになっているのを確認した。どうやら新Twitter APIの方針に従い、IFTTTがbanされたようだ。（同じつぶやきをしている人をTwitterで多く見つけた）。IFTTTがCloud Functionsをコールする仕組みになってるんだが、出発点となるIFTTTがコケているので、懸念していたCloud Functionsまでたどり着くことなく死んでいたらしい。IFTTTが動いていたしてもCloud Functionsで死亡していたのだろう。IFTTTが死亡するのは個人的に想定していなかったが、よく考えれば当たり前か。。こうなる前にIFTTTを手動で止めようと思っていたんだが、そんなことするまでもなく自然に死んで連携が止まってしまったようだ。そういうわけで、4/3朝の分を持ってデータ更新は（意図した形ではなかったが）ストップした。一応、IFTTTのアプレットもdisconnectした。
なお、IFTTTの停止は応急措置であり、完全にsunsetするなら、将来的にはこのサイト自体を完全に閉鎖する必要があるとは考えている。ただ、一応2年くらい動かしてたサイトなので、すぐにsunsetというのもなんかちょっとアレかなと思い、今はまだその作業には着手していない。そういうわけで、4/2以前に更新された過去のデータに関しては、画面を通じて見ようと思えば見える。完全なサイト閉鎖をいつにするかはまだ決めてないのだが、一応そのうちやる予定ではある。

将来的にやらなきゃいけないこと

これは日記に書くような内容ではないというか、単に自分のためのToDoみたいな色が強いが、サイトの完全閉鎖に向けては、将来的には以下の作業を実施していかなければならない。

  • Firestoreのデータ削除
  • GAEのサービスの削除（staging、production両プロジェクト）
  • GitHubリポジトリのArchive化
  • ドメイン(www.hinatch-ohatch.com)の解放

うち、ドメインの解放が一番重要だ。この中で唯一期間的な縛りがある。次の更新前までに片づけないと無駄な更新料が発生しちまうからだ。まあ1000円前後だし別にいいんだけどね。。

結果

最終更新日時は2023/04/03 04:53:29。ただしこれは4/3朝のひなっちのオリジナル「おはっち」の処理分なので、1番～5番おはっちリプの分が処理された結果ではない。しかしまた凄い時間におはっちしてるんだなひなっち。。1番～5番おはっちのランク付けが実施されたという意味での最終更新は4/2 10:48頃になる。

最終的な「1番おはっちまでの平均秒数」は11.99秒となった。ただ、2023年1月中旬くらいに、それまでと大幅に異なる300秒～3000秒くらいのデータが飛んできており(一部抜粋；画像参照)、これが平均秒数を大きく狂わしている。staging環境に移行した2022年6月当時のデータをもとにすると、その時点では6.12秒だった。前述した2023年1月のおかしなデータが来るまで、ほぼ2年間ずっとこの辺の数値で推移していたので、概ね「6秒ちょっと」というのが実体だと思う。

「2023年1月中旬くらいに、それまでと大幅に異なる300秒～3000秒くらいのデータが飛んできており…」の部分については、当時考察しており、以下スレッドにて独り言を呟いているので参考にしていただきたい。（どうでもいいが…）

最終的なランキングは以下の通りになった。上位3人は俺が見てる範囲ではほぼ不動だった。このまま続けて行っても恐らくしばらくは同じ傾向だったと思われる。

IFTTTのコール回数は6370回となった。ただこれは、「IFTTTがひなっちのツイートのポーリングしてWebhook（Cloud Functions）をトリガーしたした回数」なので、おはっちorおはっち認定した回数ではない。「運用期間中にひなっちが（リツイを含めて）ツイ―トした回数」というのが妥当なところだろう。

2021/4/1の分からデータの蓄積を始め、2023/4/2分を処理するまで、ほぼ約2年。この間の日数は731日。通常、「ひなっち自身の『おはっち』」が1回、それに対する「おはっちリプ」が1番～5番で認定されて5回、で、1日に6件のデータ処理がある。「おはっち」しない日や、しても認定しない日などもあるので一概には言えないが、単純計算だと6×731＝4386件のデータが作成されたことになる。…そう考えると別に大したことないな…まぁ子オブジェクトの数が多い構造のJSONデータだし、UTF-8のテキストがガンガンに含まれているので、実際のデータ容量という意味ではそこそこガッツのある感じ（？）になると思うが。

とはいいつつ

せっかく2年近く集めたデータなんだし、これはこれで残しておいてもいいかもな、とは思っている。今はFirestoreに入ってるが、別にFirestoreに拘る必要はないし、例えばS3とかのObject Storageに置いてもいいだろうし。残すにしたら、まあお値段の安いほうかな。
あと、GAEに乗ってるNext.jsのアプリに関しても、過去の記録を見るためのアプリとして、このまま残しておいても良いのではないかと思う部分がある。ただその場合、データの保存場所をFirestoreから別に移す場合、Next.jsで画面に描画するデータを取得するAPIを改造しなければいけなくなるが。（まあやるにしてもそんな大した話ではないけど）
ついでに言うと、Cloudflareのキャッシュの保持期間を目いっぱい長くすれば、極論いうとこのまま放置でも別に問題はあるまい。まぁそうなるともはやNext.jsとかそんなかっこつけたモンである必要は全くなくなるのだが。。
ドメインの更新料だけはネックなので、次の更新前には少なくともドメインは手放すことにはなるだろう。既存のドメインのどれかのサブドメインに紐づかせる形で存続させるかどうか、を検討してもいいかもしれない。

思い出

このアプリケーションの構造自体は古く、大本をたどると2017年まで遡る。

  • ひなっちがTwitter上で毎日「おはっち」ってツイートして、それに対してファンの人が「おはっち」ってリプして、ひなっちが後からその順番をリプするという「遊び」が、日々行われているのは、前々から見ていて知っていて、こういう、（暗黙の）「ルール」にしばられた中で行われている「遊び」は、そのルールに沿う形で処理すれば、恐らく面白いデータが取れるだろうな、とは薄々思っていた。この時点で少しずつTwitter APIを触り始め、データを観察して遊んでいた。最初は後述するように「遊び」で終わっていて、実際自分もそれで満足していたので、本格的に「仕組み化」しようとは考えてはいなかった。この気持ちが明確に行動になって現れるのは本当に直近数年の話である。
  • 2017年の段階では、Twitter4jを使って直近の期間の分のデータを参照し、「1番おはっちまでの平均秒数」を求めたりして遊んでいた。文字通り、このときはまだ単発の遊びだった。この時点ではそれで終わっていて、「これを自動的に処理する仕組みを作ってデータ蓄積していったら面白いだろうなあ」とはボンヤリ考えてはいたものの、本格的に始動するのは数年後になる。
  • 2021年になってから、GCP（Firebase）・Firestore・Cloud Functions、及びIFTTTと、フロントフレームワークとしてNext.jsを使って、データを自動処理してそれを表示する仕組みとして作り上げた。今考えるとこのときは、生のJavascriptで書いてたし、CSSも自前の適当な（？）やつだったし、開発中でもワーニング出たまま放置して作ってたりと、エンジニア的にはよろしくない開発作業をしていたが、アプリケーション化するまでの構想、シンプルな作りを目指したアーキテクチャの検討等は、自分的には上手い感じにできたなと思っているし、またこのときのNext.jsやGCPを使った開発体験は面白かったし、個人開発としてはなかなか良い体験をできたと思っている。
  • 2022年になってからこのサイトを新たにリメイクした。このときの残課題の対応でその後も色々手を加えたりもした。このときはFirebaseからGAEにプラットフォームを移行したり、今まで自分が持ってるドメインの一つにサブドメインとして紐づけていたのを独立したドメインに変えたり、Next.jsのバージョンアップ、Tailwindcssの利用、Typescriptへの移行など、諸々いろんなことをやった。このときリメイクに使用したTech Stackは、現在も自分の開発の主要になっていて、この開発が体験できたのは個人的に良かったと思っている。
  • このアプリケーションは、IFTTTがひなっちのツイートをポーリングしてCloud Functionsに投げ、あとはCloud Functionsが画面で表示するデータを全部用意してくれるので、基本的に手放しで運用可能なシステムなのだ。このため、最初の頃は注視していたが、そのうち完全手放しで更新状況を見守るくらいになって、俺自身によるサイトへのアクセスも1週間に1回くらいの頻度になっていった。「俺の手が離れたところで勝手にデータが用意されて更新されていく」という仕組みはとてもユニークで、かつ俺本人の運用負荷を極端に下げてくれ、これ自体をつくった開発体験も相まって、本当によい個人開発をしたなと思った。残念ながらサイトはsunsetになるが、これ自体は今も同じ気持ちで、良い開発体験をしたなと本当に思っている。作って良かったITのオモチャ。
  • とはいいつつも、2年間の運用で、色々課題や障害もあった。そもそもひなっちはおはっちしない日があるとか、空リプで「1番おはっちおめでとう！」ってやってるとか、1番おはっちが鍵垢で俺から見れなくてエラーになるとか、どう見ても違う人に1番おはっちリプしてて「1番おはっちまでの平均時間」が狂うとか、ユーザー名にUnicodeの制御文字いれてるせいで表示が変になるとか、IFTTTの障害でデータがバグるとか、Cloudflareのキャッシュ設定変えたせいで意図せず落ちたとか。バグは直せばいいんだが、バグって書き込まれたデータや、ひなっちの誤操作等により発生した異常データに関しては、後から手修正するしかなく、これが若干面倒だったのは確かだ。しかし、IFTTTから呼ばれるCloud Functionsを冪等で動作する思想で作ったため、多くのケースでは、下準備したのちにこのCloud Functionsを一度コールするだけでリカバリできた。この点においては、2021年に最初に作った段階でのアークテクチャリングが功を奏したといえる。やはりシステムはシンプルが最強なのだと実感した。

システムのアーキテクチャoverviewを今一度載せておきたい。2022年のリメイク時に、使うGCPのサービスを微妙に変えたりはしたが、基本的な流れは当時から変わっていない。

おわりに

総合的に見て、このアプリケーションを作ったことは自分にとってとても良い経験になった。願わくばこのままずっと生かしておきたいくらい。上述した通り、作った後は基本的には手放しの放任主義運用スタイルだったわけだがｗ、ある程度時間をかけて作り上げ、そして運用してきたのも事実なので、それなりに愛着もある。
それに、このままデータが増えてくると、恐らくそれに応じて別の課題も見えてきたはずで、それにどう対処するか考えるのも楽しかったに違いない。そう考えると、それが叶わないのは残念というのは本心だ。
今回のsunsetのきっかけが、「Twitter APIの方針転換」にあるという点で、Elon Musk新体制におけるこの戦略には、当然利用者として思うところはあるし、正直ネガティヴな反応しかない。これはTwitter APIの方針転換により意図せずサ終を余儀なくされている多くの個人開発者にとって同様だろう。2年程度の運用期間のシステムにすらこうして寂しさを感じるのだから、10年以上もサービスを続けてきた人からするとその思いの強さは計り知れない。まぁ、思いの強さは関係なく、本質的なところはみんな同じ気持ちなのだろうが。
とはいえ、形あるものはいつか滅するものだ。このまま続けていたら際限なくずっと生き続けた可能性もあるし、実際どこをこのシステムの「終わり」にするかという点について、自分は答えを持っていなかった。ある意味この辺で強制的に幕引きされて良かったかもしれない。そういう風にポジティブに捉えようと思う。

2年という短い期間でしたが、見てくれたみなさんありがとうございました。
そして何よりもひなっちへ、こんな楽しい遊びを提供してくれてありがとうございました！
ライブではまだまだ俺を遊ばせてね！