『メルカリ』 アプリの画面描画を高速化する技術、バックエンド・iOS・Androidの基本設計

多くのユーザーに愛されるフリマアプリ『メルカリ』ですが、そのスムーズな画面描画はどのような技術で生み出されているのでしょうか。同アプリの高速表示の秘密を、バックエンド、iOS、Androidの3方向からメルカリ社のエンジニア4人に聞きました。

『メルカリ』 アプリの画面描画を高速化する技術、バックエンド・iOS・Androidの基本設計

2013年の登場以降、すさまじい勢いでユーザーを増やしているフリマアプリ『メルカリ』。バリエーション豊かな商品や直感的で使いやすいUIなど、ユーザーを惹きつける要素は数多くあります。

そのなかでも特に、心地よいユーザー体験を生み出している重要な要素があります。画面の描画が非常にスムーズなことです。その体験を支えるのは、高速表示を実現するための高い技術力です。

『メルカリ』の開発者たちは、どんな技術を用いて“使い勝手の良いアプリ”を作り出しているのでしょうか。そして、いかなる観点のもとにツールやアーキテクチャの改善を続けているのでしょうか。バックエンド、iOS、Androidなど幅広い領域のエンジニアの方々に、その秘密を語っていただきました。

1「フリマアプリ-メルカリ フリマでかんたんショッピング」をApp Storeで

2フリマアプリ「メルカリ」

3
久保達彦(くぼ・たつひこ) 4@cubicdaiya (写真・右上)
Webサービスや組込みソフトウェア、広告配信システムの開発を経て、2014年よりメルカリに加わる。ソフトウェアエンジニアとして、サービスの信頼性やパフォーマンスの向上に必要なソフトウェアの開発・運用に携わる。
高山征大(たかやま・もとひろ) 5@mootoh(写真・右下)
2016年にソフトウェアエンジニアとしてメルカリに入社し、現在は Androidチームのエンジニアリングマネージャー。それ以前は iOSアプリ開発や並列プログラミング言語の研究開発などに従事。
Tim Oliver(ティム・オリバー) 6@TimOliverAU (写真・左下)
メルカリJPプロダクトチームのiOSエンジニアでオーストラリア出身。メルカリ入社前は、San FranciscoのRealmというモバイル・フレームワークのスタートアップでCocoaの開発を担当。Edith Cowan大学でデジタル・メディアを専攻。
Israel Ferrer Camacho(イスラエル・フェレール カマチョ) 7@rallat (写真・左上)
メルカリAndroidチームのソフトウェアエンジニアとしてアプリのアーキテクチャと開発者の生産性向上に従事。 メルカリ入社以前は、TwitterのAndroidエンジニアとしてTwitter、Periscope、Fabricなどを担当。Barcelona LaSalle大学でコンピューターサイエンスを専攻。

バックエンドの高速化を支える技術

【Tips1】 画像のファイルサイズを最適化し、アプリ全体の通信量を抑える

──『メルカリ』の商品一覧画面は、非常に多くの画像を表示していますが描画が非常に高速です。何か特別な技術が使われているのでしょうか?

久保 画像をたくさん使用するモバイルアプリをなめらかに動かすためには、データ通信量を抑える工夫が重要になります。

『メルカリ』ではアプリで使用する画像のサイズを最適化するために、クラウド画像変換サービスの『ImageFlux』を使用しています。これはURLに画像変換用のパラメータを組み込むことで画像データの拡大・縮小やオーバレイ、フォーマット変換などが可能になるサービスです。

アプリ上で表示される画像をオンザフライでリサイズしたり、フォーマットをWebPに変換する、といった処理を『ImageFlux』によって実現しています。これにより、画像変換処理を自社のサーバーで行う必要もなくなるので開発工数も抑えられます。

8

『ImageFlux』はピクシブ株式会社とさくらインターネット株式会社が共同で開発・運用しているクラウド画像変換サービスだ。画像データをサーバや既存のクラウドから移すことなく、『ImageFlux』を中継して呼び出すだけで最適化された画像を配信してくれる。

──他の種類の画像フォーマットと比べて、WebPはどんな点が優れていますか?

久保 WebPは画質の劣化を極力抑えつつ、ファイルサイズを大幅に削減できるメリットがあります。

実際に『メルカリ』のタイムライン、検索結果に表示される商品画像のサムネイルに対して『ImageFlux』によるリサイズやWebPへの変換を行い、1画像あたり最大で40~50%ほどサイズを削減できました。タイムラインや検索結果に表示される画像のトラフィックはかなり多いので、これは非常に効果的でした。

画面描画も速くなりますし、アプリのデータ通信量を減らすことで、いわゆる“ギガが減る”ことも軽減できます。

──40~50%とはすごい! 『メルカリ』のように画像が一面に並ぶようなUIでは、画像の通信容量が減るメリットは本当に大きいですね。

【Tips2】データセンター間通信のレイテンシを抑える

──『メルカリ』のバックエンドでは複数のクラウドサービスを活用しているそうですね。そこにもアプリを高速に動かすための工夫はありますか?

久保 はい。メルカリのインフラはマルチクラウド構成になっているため、異なるクラウドやデータセンター間での通信がたびたび発生します。

その際のレイテンシを最小限に抑えるために、別のクラウドやデータセンター側との接続を維持したままにするプロキシサーバをGoで開発して投入しています。

9

プリンシパルエンジニア 久保達彦さん

──複数のクラウドサービスは、どのように使い分けているのでしょうか?

久保 メルカリのコアとなるシステムの多くはさくらの専用サーバ上で稼働していますが、一方で、ストレージにはAmazon S3Google Cloud Storageを、マシンラーニングやマイクロサービスの基盤にはGKE(Google Kubernetes Engine)を採用していたりと、用途や要件に応じて使い分けています。例えば「感動出品<1」という機能はGCPにあるマシンラーニングの基盤上で稼働していますが、利用している画像データがAmazon S3にあるので、AWSのサービスも一部利用しています。

「感動出品」のシステムアーキテクチャ。

【Tips3】アプリのありとあらゆる挙動を常にモニタリングする

久保 サービスの可用性やパフォーマンスをチェックするのにモニタリングも重視しています。

──モニタリングでは何をチェックしていますか?

久保 例えば、API等のアプリケーションのレスポンスタイムです。平均値のほかに95(99)パーセンタイル2の値もチェックしています。

──モニタリングツールは何を導入しているのでしょうか?

久保 複数のツールを導入していて、『Mackerel』や『Datadog』、『New Relic』などを主に用いています。

──それぞれを、どう使い分けていますか?

久保 『Mackerel』では各ホストの死活監視やアプリケーションの稼働状況の監視、さらにURL外形監視や、出品機能をはじめとした各種機能が正常に動いているかの監視をしています。例えば、「平常時と比べて出品の数が極端に少ない」「一定時間あたりのエラーの数が極端に多い」などをトリガーにしてアラートを飛ばし、異常を検知しています。

『Datadog』は主にマイクロサービス関連コンポーネントのモニタリングに利用しています。

さらに、『New Relic』ではアプリのパフォーマンスの細部をモニタリングしています。例えば、Webサーバー内でのPHPの処理に何ミリ秒、MySQLからのデータ取得に何ミリ秒、memchachedの処理で何ミリ秒かかっている、というように各レイヤーの詳細な応答情報を解析できるのが『New Relic』の大きな特徴です。

──アプリケーションの処理が遅くなっていることが判明したら、次は何をしていきますか?

久保 これまでに挙げたようなツールやサービスを駆使して関係がありそうな箇所やメトリクスを調査したり、プロファイリングを行って原因を調べます。原因が判明したら、そのままコードを修正することもあります。

iOSアプリの高速化を支える技術

【Tips4】Objective-CからSwiftへの移行 & アーキテクチャの刷新

──次に、iOSアプリについての話を聞かせてください。現在、『メルカリ』ではObjective-CからSwiftへの移行を進めているそうですね。

ティム iOS版『メルカリ』の開発は2013年に始まりました。Swiftが発表されたのは2014年ですから、当然ながらアプリはObjective-Cによって作られています。

今後は、iOSアプリの全コードをSwiftに移行していく予定です。新しい機能は最初からすべてSwiftで開発し、古いObjective-Cのコードも徐々にSwiftに変更していきます。

10

ソフトウェアエンジニア ティム・オリバーさん

ティム また、Objective-CからSwiftへの移行と同時期に、iOSアプリのリアーキテクチャ(アーキテクチャの変更・再構築)を行いました。既存のアーキテクチャをどのように変更すれば、開発効率性が向上するかを考えたんです。

──旧アーキテクチャの問題点とは何だったのですか?

ティム かつて、iOS版の『メルカリ』ではMVCモデルを採用していました。iOSアプリのMVCモデルでは、ViewControllerがModelとViewを持つような構成になっており、ロジック部分は基本的にViewControllerに記載されます。

そのため、MVCモデルではアプリが大きくなるにつれて、ViewControllerがどんどん肥大化してしまう傾向にあります。iOSエンジニアはよくジョークで「MVCモデルとはMassive(大規模な)ViewControllerの略だ」と言ったりします(笑)。

『メルカリ』でも、特定の画面のViewControllerが数千行もの行数になってしまうという状態でした。その状態ではコードがとにかく読みづらいですし、テストコードを書くことも困難です。

リアーキテクチャのプロジェクトにおいては、それを解消するためMVCモデルからMVVMモデルへの移行を行いました。

肥大化したViewControllerを別々のClassに分割し、一つひとつが適切な粒度になるよう小さくしていきました。これにより、各Classの役割が分かりやすくなり、新しい機能を追加することも、テストコードを書くことも容易になったんです。

──iOSアプリ開発において、MVCモデルとMVVMモデルはどのような基準で使い分けるべきだと思いますか?

ティム ロジックが限られている小規模なアプリであれば、MVCモデルでも全く問題はありません。むしろ、モジュールを細かく分割する必要がなければ、特定のViewControllerにロジックをすべて記載できるMVCモデルの方が、実装がシンプルになる場合もあるでしょう。

ですが、アプリの規模が一定以上大きくなるならば、MVVMモデルの方がより適していると思います。機能ごとにモジュールを適切な粒度に分けやすいですし、データの流れも整理しやすくなるからです。

11

MVCアーキテクチャのモデル図。

12

MVVMアーキテクチャのモデル図。

【Tips5】『UIStackView』を活用し、UIの描画をより滑らかにする

──他に、iOSアプリの「画面描画を滑らかにする」という観点で実施したことはありますか?

ティム 『UITableView』から『UIStackView』への変更です。

かつて、iOS版の『メルカリ』では情報をリスト表示する際などにAppleが提供している『UITableView』という機能を使用していました。これはiOSのバージョン2からある機能で一般的にもよく使われていますが、技術的な問題をいくつか抱えています。

例えば、メモリ消費が多く処理が重くなりやすい、ユーザーにとって違和感のある挙動(ユーザーが何か操作をすると、画面に表示されていたキーボードが消えるなど)が起こりやすい、などです。

そこで、リアーキテクチャに伴い、『UITableView』ではなくAppleが提供する新しい機能である『UIStackView』を用いてUIを描画するように刷新しました。

これは、Micro ViewControllerという設計思想を導入した機能です。画面内にある各要素を、非常に小さな単位のViewControllerによってコントロールします。例えば、画面内にある1つのボタンに対し、1つのViewControllerが対応するようなイメージです。

各要素を別々のViewControllerによって操作するため、ユーザーが画面の要素に対して特定の操作をした際、別の要素に対して影響が出にくいという長所があります。また、ViewControllerが行う仕事もシンプルになるため、設計も分かりやすくなります。

読者のなかには、「ViewControllerのClass数が増えることで、パフォーマンスが悪化するのでは」と気になる方もいるかもしれませんが、たくさんの要素を画面に表示しても動作は全く遅くなりません。画面の要素数が多いアプリを開発する上では、かなり役に立つ技術だと思います。

高山 さらに言えば、Micro ViewControllerの設計を導入することで1つの画面を複数のエンジニアで並行開発しやすくなるというメリットもあります。各要素のコンポーネント化が進み、分業が容易になるからです。

──まさに、メンバーの数が右肩上がりで増えているメルカリに適した設計というわけですね!

Androidアプリの高速化を見据えた技術

【Tips6】 よりスケール可能でスピーディーな開発を実現するため、アーキテクチャを刷新

エンジニアHubに会員登録すると
続きをお読みいただけます(無料)。
登録のメリット
  • すべての過去記事を読める
  • 過去のウェビナー動画を
    視聴できる
  • 企業やエージェントから
    スカウトが届く