意外な原因の発見からはじまった、オブザーバビリティの実践
そのような背景の中、実際どうなっているのかをNew Relicのモバイルアプリ用エージェントを使って分析した画面が以下である。アプリの各画面の処理にかかる時間を見ることができる。分析の結果、位置情報取得以外に、画像に関する処理時間の割合が高いことがわかった。
さらに、画像処理という観点で確認を進めたところ、時間ごとの天気を構成するビューが最終的に一つの画像になるケースがあることが判明したため、Collection Viewを使って書き換えを行った。また、天気アイコンの生成をUIイメージnamedで行っていた工程を、UIイメージコンテンツをファイルに置き換えるというキャッシュを作らない書き方に変えて、生成を速くした。
「自動で上がるデータはメソッドごとの単位で上がってくるので、さらに掘り下げていく必要がありますが、これまで認識していなかった原因に気づきがあるのが良い点だと感じました」
このように各時間を見比べると、時間がかかっていると思っていた位置情報の待ち時間はそれほどかかっておらず、現在地の地名APIのレスポンスの待機時間が原因だとわかった。そこで地名は天気APIに含めるようにして時間短縮を図った。
「カスタムのラップタイム計測は、可視化する際にそのデータ用テーブルを作ってスケジュールしておく作業があるのですが、New Relicでは不要になります。送信したデータをすぐグラフにしてリアルタイムに確認できることは、大きなメリットだと思いました」
サーバーについては、オンプレからAWSへの移行を進めてスケールし、高いトラフィックを捌けるように開発を行った。ECS、AutoScaling、Golangによる実装や、負荷に強いサービスを活用している。
その上でパフォーマンスを監視するため、New RelicのAPMを使い、ECSの監視を行った。例えば、ECSからAPI、AWSリソースへの参照は期待通りのパフォーマンスかどうか。また、大雨、地震時のパフォーマンスは問題ないかといったところを見ている。
また、New RelicのSytheticsを活用して、エラーがあった場合はSlackで通知する、またPageDutyと連携して電話をかけるシステムも構築した。
この事例に対し、本セッションのファシリテータを務めたNew Relic社のオブザーバビリティ技術本部 担当部長である佐々木千枝氏は、このように感想を述べている。
「急激なアクセスがあるアプリの特性上、柔軟なスケーリングができるサーバレスという環境が積極的に使われている。その中で、New Relicを活用し、サーバー環境とはまた異なった新しい運用の仕組みを作っていただいた。まさにモダンアーキテクチャにおけるオブザーバビリティを実践されていると思います」
アプリの起動スピードを2倍に！ 高評価に繋げる
その他の取り組みとして、起動時に必要ではない初期化処理を、必要になるタイミングの前に実行。「ピンポイント天気」のデータロード中に、前回起動時のキャッシュデータを表示することで待ち時間を短く感じさせる工夫も行った。
その結果、なんとアプリの起動スピードを2倍高速化することができたという。まさに、「スピードは正義」を実現した結果を出すことに成功したのである。
「アプリの起動を1秒以内にすることを目標に着手しましたが、天気を描画するまでの時間はかなり目標に近づく結果となりました。またアプリのレビューでも、パフォーマンスに関する好意的な内容が増え、評価のアップに繋げることができました」
今回の取り組みを通して、邉見氏は以下のような考察をしている。
＜アプリ＞
- 可視化して定量的に評価することの大切さを実感
- 仕方がないと思っているところにこそ、改善の余地がある
＜サーバー＞
- APMはエラーがなくてもモバイルでエラーになるケースがある。この現象はトラフィックが捌き切れていないときに発生するため、APMでエラーがなくても安心せず、モバイルやSyntheticsでの監視が重要になる
今後の取り組みとして、邉見氏が挙げたのは「雨雲レーダーなど人気コンテンツのUI/UX改善」。「例えば描画が重くならず、サクサクと動いて快適に使えること。コンテンツが増えても見たい情報にすぐアクセスできるようにする。また地震などの緊急情報も、いざというときに役立つコンテンツとして強化していきたい」と力強く語り、セッションは終了した。
