アプリのAPI呼び出し回数を計測する工程を導入する

タクシーアプリ『GO』の iOS アプリを開発している古屋です。

本記事では、アプリのAPI呼び出し回数を計測し、過剰に呼び出していないかチェックする工程を開発のプロセスに入れたことについて紹介します。

きっかけ

『GO』ではリアルタイムにタクシーの動態を表示したり、配車までの目安時間を表示したり、配車依頼の状態を表示したりするために、ユーザー操作によらないAPI呼び出しがあったり、そもそものAPI呼び出し回数が多かったりします。

それに加え機能の複雑さもあり、意図せぬAPI呼び出し回数の増加を引き起こしてしまうことがありました。

急激なAPI呼び出し回数の増加は、サーバーの負荷を高めサービスを不安定にしてしまうため、サーバー側の対応だけでなく、アプリ側でも事前に検知する仕組みを導入することにしました。

APIの呼び出し回数を計測する工程を導入する

なにを計測すべきか

チーム内で話した中で計測すべき項目としてこのようなアイデアが出ました。

• 全APIの総呼び出し回数
• 各APIごとの総呼び出し回数
• 一定秒数ごとの呼び出し回数
• 通信データ量

ただ

• 直近は手動で確認するため作業者によって実施速度に差が出る
• 『GO』では動画などの大きいデータのやり取りはしていない

等のこともあり、結果として以下の2項目を計測する項目としました。

• 全APIの総呼び出し回数
• 各APIごとの総呼び出し回数

また各項目はデバッグメニューから確認できるようにしています。

デバッグメニュー は『GO』の開発時に使う便利機能をまとめた画面になります。

詳細についてはこちらにまとめていますので、よければご覧ください。

どの範囲を計測の対象とするか

どの範囲まで計測の対象とするかですが、まずは小さくでも始めることを優先し、『GO』のメイン導線である、Top~配車依頼~探車~実車~降車~Top のフローを一周してAPIの呼び出し回数を計測することにしました。

『GO』では GPS精度によってもアプリの挙動が変わるため、GPSの精度を落とす目的で実機かつアプリ起動後10秒間バックグラウンドで待機するといったような、アプリの特性に即した手順も追加しました。

また初期は工数観点でUITestを使った自動テストではなく手動でテストすることにしたので、結果のブレを抑えるためにも、確認手順を明確にしました。

開発フローにおけるどの過程で実施するか

UITest等で自動化できるようになれば日次で確認するのが理想ですが、現状は手動テストなので修正する時間を確保するためにも、以下の2タイミングとしました。

• 開発完了時
• QA完了時

結果はこのようにアプリのバージョンごとに管理し、リリース予定のバージョンで劇的に増えてないかを比較します。

さいごに

APIの呼び出し回数をチェックする工程を導入してみて、ただ前のバージョンと比較するだけでなく、そもそもの呼び出し回数を減らせないか？iOSとAndroidと結構差分があるのはなぜなのか？といった議論もでてくるなど、副次的な効果もありました。

今後もこのような取り組みを続けていき、アプリの安定稼働に貢献していきたいです。

We're Hiring!

興味のある方は 採用ページ も見ていただけると嬉しいです。

Twitter @goinc_techtalk のフォローもよろしくお願いします！