シェアハウスならぬスイッチハウスを始めてみる

自分は岡山に住みながら東京の仕事をしている。
いまの仕事はずっとリモートでもできるんだけど、たまには顔合わせしたいし友人にも会いたいし、これまではコミュニティありきで仕事をとってきたところがあるので、これからも月に1週間くらい東京に滞在したいと思っている。*1
ただ、毎回ホテルをとったりウィークリーマンション借りたりするのは手続きがめんどくさいし結構お金がかかる。
そこで、同じような境遇の人と家を借りて上京時に寝床にしたい。
シェアハウスならぬスイッチハウス。
週替りで住人が入れ替わる、たまに重なって一緒に寝食をともにする。
ホテルとかと違って、「常に帰る場所がある」という安心感もある。
シェアハウスほどずっと一緒というわけではないのでストレスもそんなに溜まらない。
もちろん、人選はめちゃめちゃ大事なので気の知れた友人限定で。
めちゃめちゃ理想やん。
.
.
.
ということで、さっそく同じ状況で考えに共感してくれる友人*2がいるので、10万くらいで1LDKの家を借りて始めてみる予定。あと1人いれば3万/人で実現できる。
これからは自分みたく地方にいながら東京の仕事をする人って増えてくると思うし、こういうのが当たり前になってきたらおもしろいなー!なんて。
おしまい。
【月報】2020年5月の開発進捗や数字など

テンション高めに月報やっていくぞー!
お絵かきコラボ
apps.apple.com play.google.com5月の数字
おうち時間が減ってきた影響か、ユーザー数も減ってきてる!ナンテコッタイ!
もっと盛り上げていくぞ!💪

インタビュー公開
fluctさんのインタビュー記事が公開された!
開発メンバーの想いとか数字とかめっちゃ公開してるので見てほしい!🔍
TVデビュー
新shock感で取り上げてもらった!🙌
はじめてYouTubeライブ配信もしてみた!
配信って楽しいなぁ〜!
Firebaseの費用削減
Firebase費用がかさんでたので調査・改善した!
ブログが予想以上にバズってびっくりした!🤭
書籍通知サービス
友人のためにつくっただけなので非公開だけど!
AmazonのPA-APIで429エラーになる問題をようやく解消できた!
凡ミスだけどこれはわかりにくいぞ〜!!!🤣
PA APIのTooManyRequest問題にずっと悩まされてたんやけど、今日ふとマーケットが https://t.co/DKttEhxD2l になってることに気づいて https://t.co/qPdYr7JWlg に変更したら解決した!全然気づかんかった・・😇
— にっしー🍵個人開発 (@paranishian) 2020年5月21日
スクラッチパッド検証の時点で出鼻をくじかれてたのでよやく次に進める。やっていき!💪
Podcast
配信ペース落ちてきたけどまだ続けられてる!エラい!
5月はエピソードを2つ配信した!!
そんな有益な話はしてないけど自分が楽しければそれでヨシ!
Anchorのダッシュボード見ると、合計再生回数は2.7Kくらい!📈
まとめ
5月はお絵かきコラボの改善がメインだった!
6月からは新しいプロダクトにも着手していくぞ〜!💪
個人開発アプリのFirebase費用を30%削減した話

個人開発アプリ「お絵かきコラボ」はリリースしてもう1年半くらい経つけど、まだ結構なユーザーさんに遊んでもらっている。本当にありがたい。
バックエンドにはFirebaseを使っているんだけど、長く楽しんでもらうにつれて費用もかさんできたので、削減できるところはないか調べてテコ入れすることにした。
結果、30%ほど費用を削減することができた!わーい!👏

どんなことをしたのかさくっとまとめていく📝
Firestore
お絵かきのマッチングのたびに、お題を取得したりユーザー情報を取得したりしてるのと、毎回15分程度遊んでもらってるのでREAD数が結構多い。
・・・にしても、ユーザー数に対してREADが多すぎる。なんでーー??みたいな状態だったので、iOS/Android/サーバーのコードをすべてチェックして怪しそうなところを見つけていった。
それにしても、どこでどれだけクエリ使われてるか、みたいなのもっとわかりやすくしてほしい。 原因箇所の特定が本当にむずかしい。(実はそういうデータの取り方合ったりするのかな?)
調査の結果、特定した箇所が2つ。
TOP画面の改善
まず1つ目は、TOPページの最新の絵を取得する箇所で、毎回最新の絵をlimit(10)といった具合に取得していた。(諸事情により、表示数よりあえて多めに取得していた)

また、「もう一度遊ぶ」で毎回TOPに戻ってしまう画面遷移にもなっていた。(毎回fetchされることになるのでこれも改善した)
ユーザーの一日平均プレイ回数が10だとして、
10 limit x 10 TOP表示 x 1万DAU = 100万READ/day
という計算になる。これはバカにならない。。
今回、drawingsコレクションから複数documentを取得するのではなく、新しいコレクションtop-drawingsをつくり、クライアントからはその最新の1件だけ取得するようにした。
top-drawingsにarrayフィールドを持たせていて、そこに最新のdrawingsが10件格納されている、という流れ。(10分毎にtop-drawingsのarrayにぶちこむバッチを走らせている)
これで、limit(10) -> limit(1)になるので単純計算でREAD数が10分の1になる。
マイギャラリーの改善
2つ目はマイギャラリーの枚数表示で、実は全document取得してその数を表示していた。(なんという Bad Practice..!!)

なんと5,000枚以上描いてるユーザーさんも結構いるのでかなりインパクトが大きい。
このへんは長生きなプロダクトならではの問題かもしれない。(まあ設計時点での考慮漏れなんだけど)
描いた絵の枚数はincrementした値を使い、ページングも導入して初回から全件取得しないようにした。
結果
READ数は200万/dayほど削減できて、費用としては30%削減できた!よっしゃ!

この読みがあたってたのは結構嬉しい😙
サーバー、クライアントのコードを舐め回すように見た結果、総量を圧迫している原因の一部がわかった。200万read/dayくらい減らんかな〜、そんなうまくはいかんのやろうけどな〜
— にっしー🍵個人開発 (@paranishian) 2020年5月3日
Storage
お絵かきアプリなのでもちろん画像を扱っているんだけど、30秒や60秒で描く絵なのでシンプルなものが多い。にもかからわず画像の容量が結構多いなーという印象だった。もっと画像を圧縮して容量削減できるのでは?と思いいろいろと試行錯誤した。
結果、ファイル形式をJPEG -> PNGに変更し、imagemin + imagemin-pngquantを使ってpng圧縮することで容量削減に成功した。
また、PNGにした副次的な効果として、色合いも鮮やかになった。
このへんの画像の知識あまりなかったので良い勉強になった。

結果
Storageのグラフは積み上げなので全然差分がわからないけど、1.7GB/dayだったのが1.1G/day程度に抑えられた。 費用としては50%減!!やったね!

おわりに
まだまだ改善すべき箇所は多いけど、少しずつ対応していきたい。
子育てのほうが優先度が高いのでなかなか個人開発の時間が取れなくなってきたけど、「リソースをあえて制限することで集中できる」なんて話もあるし、これからも前向きにがんばる所存。
もっともっと経験値をためて、Firebaseマスターにおれはなる!💪
おまけ
100万read/dayくらい削減できるポイント見つけた💡
— にっしー🍵個人開発 (@paranishian) May 4, 2020
やっぱ頭使う仕事は朝に限るな〜😋
…と浮かれて計算してみたら$0.06/10万readなので$18/monthくらいのインパクトしかなかった…🥺firestore安すぎひんか…
