■ 自己紹介
はじめまして、ブラジル出身のエンジニア、Thiagoです。
エンジニア歴は14年で、React Native / Expoを中心としたモバイル開発と、Node.js・Java(Spring Boot)によるバックエンド開発を担当しています。
日本には3年以上住んでいたことがあり、日本の開発チームで働いた経験もあります。
今回は、本番運用中のアプリで起きた「配信基盤の終了」という問題に、どう向き合ったかをお話しします。
■ 何が起きたのか
担当していたアプリでは、CodePushという仕組みを使って、ストア審査を通さずにアプリを更新(OTAアップデート)していました。
緊急のバグも、数分でユーザーに修正を届けられる、とても重要な仕組みです。
しかし、その基盤であるMicrosoftのApp Centerが提供終了することになりました。
何もしなければ、小さな不具合の修正でも毎回ストア審査を待つことになり、ユーザーに修正が届くまで数日かかってしまいます。
■ どう判断したか
移行先として、主に2つの選択肢を検討しました。
・CodePushのサーバーを自分たちで運用する
・ExpoのEAS Updateに移行する
判断の基準にしたのは、次の4つです。
1. 移行にかかる時間
2. 移行後の運用コスト
3. チームの負担
4. セキュリティ
自前でサーバーを運用すれば既存のコードはほぼそのまま使えますが、サーバーの保守という新しい負担が生まれます。
一方、EAS Updateは運用が楽なうえに、「署名付きアップデート」でアプリに届くコードの改ざんを防げます。
OTAアップデートは便利な反面、「外部からアプリのコードを差し替える仕組み」でもあり、攻撃の入り口になりえます。
長期的に安全に運用できることを最優先に考え、EAS Updateを選びました。
■ 結果
・OTAアップデートを止めることなく、新しい基盤へ移行できました
・バグ修正の配信時間:[移行しなかった場合の想定 → 移行後の実績]
・移行後に配信したアップデート:[N]件
・署名付きアップデートにより、配信経路の安全性も向上しました
■ 学んだこと
一番の学びは、「外部サービスへの依存はリスクでもある」ということです。
便利なサービスほど、終了したときの影響は大きくなります。
また、技術選定では「今すぐ動くか」だけでなく、「数年後も安全に運用できるか」を考えることが大切だと改めて感じました。
リードエンジニアとしてチームを率いた経験もあるので、こうした判断の理由をドキュメントに残し、チーム全体で共有することも意識しています。
■ これから
今後も、モバイルアプリのパフォーマンスとセキュリティを軸に、ユーザーが安心して使えるプロダクトづくりに関わっていきたいと考えています。
日本の開発チームとの協働にも、引き続き挑戦していきたいです。
■ 技術的な詳細はこちら
具体的な移行手順やハマったポイントは、Qiitaにまとめています。
https://qiita.com/thiagovpaz/items/518e753e039435bf35e7
