IFの影響を最小限に、降雨レーダーの機能を改善させた話
こんにちは、ふなっこ です。ナビタイムジャパンで地図データの配信システムの開発・運用を担当しています。
今回は、公開済みのアプリへの影響を最小限にして、降雨レーダーの機能を改善させたお話ができればと思います。
開発に至るまでの経緯
元々、降雨レーダーを表示する機能は、1kmメッシュ単位でナビタイムジャパンの各サービスで使われておりました。
そして、提供会社からより精度の高い250mメッシュの情報を提供できるお話を受けたことで、導入を検討することとなりました。
また、降雨レベルを増やして欲しいといった社内要望（1mm/5mm/15mm/30mm/50mmの5段階から15段階以上の詳細に）を受け、機能拡張も検討することになりました。
要件の検討
新しいデータを導入するにあたり、必須となる要件の洗い出しを行いました。
公開済みのアプリを更新せずに降雨レーダーが機能すること
入れ替え作業によるサービス停止期間がないこと
サーバーコストの増加を最小限とすること
課題の洗い出しと対策の検討
要件を満たすために、課題を洗い出し、その対策を検討しました。
1.公開済みのアプリを更新せずに降雨レーダーが機能すること
公開済みのアプリに影響を与えないために、IF（インターフェース）を変更することなく対応する必要がありました。
検討の結果、APIのパスは変更せず、新機能を利用する場合にのみクエリを追加する対応とすることにしました。
アウトプットとなるデータフォーマットについては、幸運なことにメッシュのサイズや降雨レベルの種別等を判別できる仕組みとなっていたので、そのまま利用することとしました。
2.入れ替え作業によるサービス停止期間がないこと
入れ替え作業によるサービス停止期間が極力短くなるように、検討しました。
データフォーマットに変更はないため、DBは継続して利用することとしました。そして、配信サーバーを新・旧どちらのデータも対応できる状態でリリースしておき、データコンバータをリリースするタイミングで自動的に入れ替え作業が完了するようにしました。このように段階的にリリースすることで、不具合発生時の切り戻しを容易に行えるようにしました。
3.サーバーコストの増加を最小限とすること
上記に記載した通り、DBをそのまま利用するため、新旧システムの並行運用がなくなり、コストの増加を抑えることが可能となりました。
開発とリリース
既存の機能に手を入れるため、リリースを段階的に行うことで、不具合発生等のリスクを少なくするようにしました。
1stリリース
提供データの入れ替えから開始しました。アプリへの影響があるIFに変更を入れずに、バックエンドの改善のみを行いリリースしました。
2ndリリース
降雨レベルの改善を行いました。新機能を利用する場合にのみ既存IFにクエリを追加させました。バックエンドの改善を行ってリリースしました。そして、新しいクエリを追加したアプリから、新しい機能が利用できるようになりました。
さいごに
公開済みのアプリへの影響を最小限にするために、段階的にリリースした工夫を紹介させていただきました。
また、開発が完了した機能から、段階的にリリースすることで、より早くユーザーへ新機能を届けることができるかと思います。
最後までお読みいただきありがとうございました。