この記事は何？
タイトルの通り。
だから気をつけようね、っていう自戒を込めつつ、同じような思いをする人が少しでも減りますようにと祈りも込めて。
とりあえず、起こったことと対応したことを時系列に沿って記述していこうと思います。
時系列に沿って
2022/02/08
東海オンエアのYoutube動画に映っている聖地をみんなで登録・共有できるアプリをリリースしました。
こちらのアプリでは、以下のような機能を実装しています。
- マップ上にスポット表示
- スポット詳細ページでスポットの詳細を表示
- スポット一覧ページで一覧を見られる
2022/03/15
YoutubeAPIを用いて、Youtube動画一覧ページを追加
2022/03/17
デザインの大幅な修正を実施。
UIに重きを置いてスポット一覧ページに各スポットの画像を掲載するようにした。
2022/03/22
東海オンエアファンの方に見つけていただき、拡散される。
2022/03/23~24早朝
ユーザ数の増加に伴いPlaceAPIの呼び出し数爆増、利用料金爆増。
仕事終わりに対応し、深夜5時に修正リリースを審査に提出。
暫定対応として、GoogleMapApiの方でPlacesApiの利用を停止した。
原因
原因は大きく分けて二つある。
- その1: 地図上のスポットを表示する際、スポットの画像を毎回apiを叩いて取得して表示するようにしていた
- その2: ページングを適切に行なっておらず、全てのスポット情報を一度にレンダリングしていた
上記両方が揃った結果、毎画面描画のたびに全てのスポットに対してその画像を取得する処理が走ってしまっていた。
対応
1への対応
PlaceApiの取得回数を減らすために、スポットの画像はスポット作成時に取得して、保存しておくことにした。
画面描画時には、自分のサーバのapiを叩くだけで済むので、placeApiへのリクエストはスポット登録時だけですむ。
2への対応
1への対応をすれば十分ではあるが、スポット数が多くなるに従って描画処理が重くなってきたので、適切なページング処理を入れた。
具体的には、リスト表示の際には20件を取得しておくようにし、リスト下端に到達したら次の20件を取得する、とした。
教訓
想定リクエスト数や利用金額の概算などは大事です。
まぁ、適切な設計がなされていれば気にしなくてもいい部分ではあるかもしれませんが。