re:Invent 2024: MetaがAWS Device Farmで実施する高度なモバイルアプリテスト手法
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Optimizing the world's top apps: How Meta tests using AWS Device Farm (FWM204)
この動画では、AWS Device FarmのプリンシパルソリューションエンジニアであるNikhil DebareとMetaのソフトウェアエンジニアJacobが、モバイルアプリのテストと最適化について解説しています。AWS Device Farmの実機テスト環境の特徴や、Metaでの活用事例が詳しく紹介されています。特に、Metaがパフォーマンステストにおいて、CPU周波数の制御やバックグラウンドプロセスの管理、温度管理など、Root化されたデバイスを活用して行っている高度な最適化手法は注目に値します。また、XCUIテストプランのサポートや、リモートアクセスの36%のレイテンシー改善、テストホストマシンの33%の高速化など、AWS Device Farmの最新の改善点についても言及されています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
AWS Device Farmを活用したモバイルアプリ最適化の概要
皆さん、いかがお過ごしですか？照明が眩しいですが、もう一度お聞きしましょう。皆さん、いかがお過ごしですか？そうですね。本日はセッションFWM 204「世界のトップアプリの最適化とMetaによるAWS Device Farmの活用」についてお話しします。もし間違った部屋に入ってしまった方がいらっしゃっても、ぜひ残っていただければと思います。価値のあるセッションにしますので。
始める前に、こんな経験はありませんか？私たちには、一日中何度も確認してしまうお気に入りのアプリが1つか2つありますよね。時には頻繁すぎるくらい。そのアプリのことをよく知っているので、普段と少しでも違う動きがあれば気づいてしまいます。例えば、銀行アプリや株式アプリで、画面がぐるぐる回ったり、読み込まれなかったり、エラーメッセージが表示されたりすると、様々な感情が湧き上がってきます。「インターネットは大丈夫？」「アプリは最新版？」「スマートフォンの調子が悪いのかな？」そして最悪の場合「アプリが危険にさらされた？」「アカウントが危険にさらされた？」といった具合に。こういった経験がある方はいらっしゃいますか？
はじめまして、私はNikhil Debareと申します。AWS Device Farmのプリンシパルソリューションエンジニアとして、お客様や開発者、そして皆様のような意思決定者の方々のアプリの品質向上と最適化をサポートしています。本日は特別ゲストとしてMetaからJacobさんにもお越しいただいています。「皆さん、こんにちは。私はMetaでソフトウェアエンジニアをしているJacobです。」ありがとうございます。
今日この部屋を出る時には、アプリのパフォーマンスに影響を与える要因について理解していただけることを願っています。最適化とは具体的に何を意味するのでしょうか？単なる読み込み時間のことでしょうか？それともネットワークの呼び出しでしょうか？これは非常に広い概念なので、具体的な内容に踏み込んでいき、そしてAWS Device Farmがこの全体像の中でどのように位置づけられるのかを探っていきます。AWS Device Farmとは何か、そしてMetaのような顧客がどのようにして目標を達成しているのかについてお話しします。
では、アジェンダを確認させていただきます。パフォーマンスと最適化に関する情報を単に投げかけるのではなく、まずモバイルテストの領域全般について基礎から見ていきましょう。モバイルテストの領域が何を含むのか、そしてローカルマシンやCI/CDパイプラインで作業する開発者がどのような課題に直面しているのかを探ります。次に、AWS Device Farmとは何か、そしてこの全体像の中でどのように適合するのかを見ていきます。3番目に、MetaがAWS Device Farmをどのように活用しているかを検証します。特にJacobから、この取り組みをどのように始め、Metaがどのようにアプローチし、様々な最適化においてどの時点で価値を見出したのかについての洞察を共有していただきます。最後に、AWS Device Farmの新機能と今後の展開、この1年間で達成したこと、そして皆様が始めるためのリソースについてお話しします。
モバイルアプリテストの課題と実機テストの重要性
では、モバイルアプリのテストにおける一般的な課題から始めましょう。あなたがアプリ開発者やチームリード、あるいはアプリのリリースを任された担当者だとしましょう。誰かがアプリをリリースするように指示した場合、あなたはそれをビルドし、テストし、デプロイする必要があります。ローカルマシンでのビルドの部分は解決済みとして、次はテストが必要です。ここで疑問が生じます：何でテストすべきか？実機でやるべきか？それともエミュレーターでやるべきか？これは深いトピックで、Jacobが後ほどMetaのデータポイントと考え方について触れる予定です。しかし、AWS Device Farmがローンチされてからの過去10年間、すべての顧客に共通する一つのテーマがあります - 実機で一度も動作確認していないアプリをリリースするリスクを取りたいと考える顧客は一人もいないということです。もちろん、エミュレーターにも正当な使用例があります。スピードが速く、場合によっては実機よりも多くの設定オプションを提供できます。しかし、実機で一度も起動したことのないアプリをリリースしたいと思いますか？それはリスクが高すぎます。そこで簡単に言えば、両者にはそれぞれの役割があり、「どちらか」ではなく「両方」の解決策だと理解して進めましょう。
実機に関しては、どの端末を購入するかを検討する必要があります。画面サイズ、GPU、メーカーやモデル、OSバージョン、バリエーション、CPUなど、考慮すべき変数は多岐にわたります。しかし、頭の良い人なら何とかなると思うかもしれません。
一つのアプローチとして、アナリティクスを見て、メーカーやモデルに基づいてターゲットとすべき端末を決定する方法があります。ただし、現在では端末が数週間おきにリリースされ、アナリティクスも頻繁に変化する可能性があるため、数ヶ月ごとにこの作業を繰り返す必要があるかもしれません。つまり、多くのフラグメンテーションがあり、それに追いついていく必要があるのです。共有可能な端末を備えた自前のラボを設置する場合、顧客フィードバックに基づく一貫したパターンが浮かび上がってきます - 5〜10台の端末という理想的な数に近づき、それを超えていくと、そのインフラを維持するための専任リソースが必要になってくるのです。
これにインフラと保守が必要だと聞いて驚くかもしれませんが、あなたのポケットにある端末と同じように、デバイスは予期せぬ動作をすることがあります。WiFi接続が切れたり、予期せぬポップアップが表示されたりすることがあります。時には、位置情報へのアクセスを継続して許可するかどうかを尋ねるアプリの位置情報ポップアップが表示されることもあります。自動化の最中にこれが起こると、パイプラインが完全にブロックされてしまいます。そのため、端末を維持管理するためのメンテナンスレイヤー、マネジメントレイヤーが必要になってきます。しかし、それを解決してローカルの端末でテストを実行できたとしても、それで十分でしょうか？
例えば、何百台もの端末でテストを実行し、ちょうど30台の端末で失敗が見つかったとしましょう。これらの端末は、異なるメーカーや機種にまたがっている可能性があります。運が良ければ、特定のメーカーの端末の特定のOSバージョンに限定されているかもしれません。本当に必要なのは、どの端末で、どの程度のテストが失敗しているかを示すシグナルやパターンです。最終的な目標は、迅速かつ確実にリリースすることなので、より早くデバッグするためのアクショナブルな結果が必要なのです。
AWS Device Farmの機能と利点
ここで AWS Device Farm の出番となります。ご存知ない方のために説明しますと、AWS Device Farm は実機デバイスとデスクトップブラウザを使って大規模なテストを可能にする、フルマネージド型のアプリケーションテストサービスです。これらの実機デバイスへの安全なアクセスを提供します。ここで「実機」という言葉を強調していることに注目してください。これらは エミュレータでも、シミュレータでも、仮想マシンでもありません。ハードウェア、ネットワーク、ソフトウェアのレベルで一切改変されていない、市販の一般消費者向けデバイスなのです。これを設計原則として維持している理由は、アプリをリリースする際に、エンドユーザーが実際にアプリを使用する時と全く同じ体験が得られることを確実にしたいからです。
AWS Device Farm では、管理する必要があるのはアプリとテストだけで、それ以外は本当に何も必要ありません。出力結果の保存用のインフラも含め、すべての基盤は AWS Device Farm が管理し、ストレージは無制限です。料金に関しては、お客様からよくすぐに質問を受けます。従量課金制のオプションがあり、一定の使用量に達すると、無制限テストやサブスクリプションモデルの方が合理的になる場合があります。これは二者択一ではなく、これらのオプションを組み合わせることができます。例えば、CI/CD パイプラインでは、すべての Pull Request に対して無制限テストを利用することができます。
それでは、機能セットの概要を見てみましょう。その後、詳細に入り、Yacob が実際のユースケースについて説明します。大まかに見ると、Device Farm テストにおけるお客様の導入プロセスは3つの段階に分かれています。
ほとんどのお客様は Remote Access から始めます。これは最初のフェーズで、デバイスでの手動操作が必要な特定のユースケースに対して、手動テストを社内で行う段階です。そこから通常、手動テスト機能を拡張していきます。最終的には、数百台のデバイスで並行してテストを実行できる自動化テストへと進化していきます。
デスクトップブラウザについては、Chrome、Firefox、Edge の複数バージョンを提供しており、これらは一定期間のウィンドウで更新されています。新しいバージョンがリリースされると、それらのサポートを開始し、デスクトップブラウザはフルマネージド型の Selenium グリッドを通じて提供されます。モバイルフォンとデスクトップブラウザの両方で機能をテストしたいウェブアプリケーションのお客様は、Device Farm を使用することで、ソリューションを分散させることなく両方のテストを実施することができます。
自動テストを実装する際、Stagingの環境へのアクセスや、パブリックインターネットに公開されていないCI/CDパイプライン、オンプレミスのエンドポイントが必要になるケースがあります。Device Farmは、iPhoneやAndroidデバイスをお客様のVPCに配置できるVPC Device Farmを通じて、これらの接続に関する課題に対応しています。VPNクライアントやMDMプロファイルなどの既存のソリューションをサポートしながら、シンプルな設定でiPhoneをVPC内に配置することができます。
テストホストとデバイスの両方でカスタマイズが可能です。例えば、アプリのインストールや初回起動時にデバイス上でポップアップを消したり、CPUサイクルを制御するためにADBコマンドを実行したりする必要があるかもしれません。Device Farmはこれらのカスタマイズ機能を提供しています。さらに、Root化されたAndroidデバイスもサポートしています。これは、Androidのエコシステムには、Androidの公式ドキュメントに記載されているバッテリー使用量モニタリングツールなど、Root化されたデバイス向けに特別に設計されたプロファイリングツールが存在することが分かったときに重要になりました。
ここで、Device Farmが提供する機能を総括してみましょう。 大きな特徴として、このサービスは印象的なスケーラビリティを提供します。複数のユーザーが同時にログインでき、各ユーザーが様々な機種やモデルで複数のセッションを開始できます。スケーラビリティは垂直方向と水平方向の両方で、デバイスタイプに制限はありません。フルマネージドサービスとして、特にグローバルチームにとって価値のあるサーバーサイド実行を提供しています。
サーバーサイド実行は、異なる地域で作業する分散チームが直面する課題に対応します。CI/CDパイプラインを使用せずにローカルマシンからテストを実行する場合、レイテンシーの違いによって一貫性のない結果が生じる可能性があります。私たちのソリューションは、場所に関係なく、全員に同じインフラストラクチャとソフトウェアスナップショットを提供することで、これらの不一致を解消します。Device Farmはリフト＆シフトモデルに従っており、実機でローカルマシンで動作するものは、Device Farmでも動作し、ローカルで得られるすべての情報を取得できます。
Device Farmは、ビデオ、ログ、スクリーンショット、パフォーマンスやネットワークデータなどの追加のアーティファクトを提供します。これにより、問題を素早く解決するという本来の目的に集中できるため、より迅速なデバッグが可能になります。カスタマイズのためにオン・オフを切り替えられる設定可能なアーティファクトを提供しています。デバイスやアプリにネットワーク位置に依存する機能がある場合は、緯度と経度の座標を提供することで位置情報をモックできます。なお、AWS Device Farmのデバイスは現在US West 2リージョンでのみ利用可能ですが、位置情報のモックにより、位置情報を利用する機能の課題を克服できます。
また、ネットワークエミュレーション機能も備えています。アプリが低品質のWi-Fiネットワークや2G、3G、5Gネットワークでどのように動作するかをテストしたい場合、動的に切り替えることができます。例えば、5Gで実行中にトンネルに入った時の状況をシミュレートすることができます。これらは一つずつ手動で実行するものではありません - 成熟したリリースサイクルでは、CI/CDフローに組み込む必要があります。サービス開始以来10年間で、統合できなかったCI/CDシステムは一つもありません。これは、Device Farmチームが開発したJenkinsプラグインやGradleプラグイン、AWS CLIやAWS SDKを通じて公開される機能など、様々なファーストクラスのプラグインを提供しているからです。
Device Farmには、2つのデバイス提供オプションがあります。まず、セキュアな共有デバイスである公開デバイスがあります。お客様がテストを実行すると、成果物やビデオが生成されたり、設定が変更されたりする可能性がありますが、各お客様の実行が完了すると、ブラウザ設定、履歴、Cookie、MDMプロファイル、VPNプロファイル、信頼証明書など、すべてを削除します。完全にクリーンアップできるか確信が持てない機能はロックしています。公開デバイスモデルでは、継続的に新しいデバイスを追加し、各デバイスの複数のインスタンスを維持することで、幅広い選択肢と深い検証が可能です。
Private deviceは、その名の通り、お客様のアカウント専用のデバイスです。1つまたは複数のAWSアカウントでのみ利用可能で、VPC接続への安全なアクセスを提供します。Private deviceでは、VPNプロファイルのインストール、セッション間のデバイス状態の維持、デバイスの再起動など、高度なシナリオを実行できます。
Yakupに引き継ぐ前に、フローの概要をご説明しましょう。Device Farmでテストを実行するには3つの要素が必要です - 厳密には2つで、3つ目は選択です。まず、ネイティブアプリ、ハイブリッドアプリ、純粋なWebアプリなど、アプリが必要です - IPAファイル、APKファイル、またはブラウザで開くWebアプリです。次に、一般的なテストフレームワークや完全にカスタマイズされたフレームワークなど、テストフレームワークが必要です。3つ目は、Device Farmでデバイスを選択することで、数百から数千のデバイスから選べます。
実行をスケジュールすると、Device Farmは各デバイスに対してホストマシンを起動します。例えば、100台のデバイスを選択した場合、Device Farmは100台のホストマシンを起動します。Androidデバイスの場合はEC2 Linuxマシン、iOSデバイスの場合はMacマシンが使用されます。マシンとデバイスは1対1で対応しており、完全な分離を提供します。各ホストは専用のデバイスを持ち、各デバイスは専用のネットワークを持ちます。
この分離は非常に完全で、データセンター内の近接した場所にあるデバイス同士でさえも、お互いを認識できません。Wi-Fiを検知することもできず、同じサブネット上に存在することすら分かりません。これが、同一アカウント内の複数セッションでも提供される分離レベルです。これが概要となります。では、Jacobに引き継ぎたいと思います。
Metaにおけるモバイルアプリのリリースプロセスと正確性テスト
ありがとうございます。本題に入る前に、簡単に自己紹介をさせていただきます。私はAWS Device FarmをMetaのインフラに統合する責任者を務めていました。以前は、リリース前のモバイルアプリケーションのパフォーマンスを測定するプラットフォームに携わっていました。現在も引き続きデバイステストの大きな推進役として、Metaの他のチームがAWS Device Farmを活用できるようサポートしています。まず最初に、Metaにおけるモバイルアプリケーションのリリースプロセスについて簡単にお話しします。その後、デバイステストが特に有用な2つの領域である、正確性とパフォーマンスについてお話しします。最後に、なぜデバイステストが重要だと考えているのか、そしてAWS Device Farmがどのようにそれを実現しているのかについて、簡単にまとめたいと思います。
では、Metaでのモバイルアプリケーションのリリースについて見ていきましょう。Metaは毎週、世界で最も人気のあるアプリケーションの一部をリリースしています。皆さんもご存知のアプリケーションも多く、おそらく今この瞬間もスマートフォンにインストールされているでしょう。これらのアプリケーションはそれぞれ、世界中に何億人ものユーザーを抱えています。このような規模では、どんな問題も数百万人のお客様に影響を及ぼす可能性があります。小さなバグでも、ところどころで影響が出ますが、大きなバグの影響は全く異なるレベルになります。
それでは、開発者の頭の中にあるコードが、皆さんのスマートフォンに届くまでの道のりを見ていきましょう。Metaではコードがどのようにデプロイされるのでしょうか？いくつかのステップはご存知かもしれません。これは実際にはかなり簡略化されたリリースフローですが、皆さんの会社でのリリースも似たようなものではないでしょうか。すべては開発者が開発マシンでコードを入力することから始まります。IDEはコードの型チェックに関する豊富なフィードバックを提供し、コンパイルエラーを表示します。この段階でUnit Testを実行する開発者もいれば、次のフェーズまで待つ開発者もいます。機能の複雑さに応じて、開発者はEmulatorテストを実行し、場合によってはEnd-to-Endテストやユニットテストを追加することもあります。
コードに満足したら、レビュー用にDiffを提出します。他のメンバーがDiffとコードの変更をレビューしている間、シンプルなEnd-to-EndテストとUnit Testを実行します。すべてのテストにパスし、承認が得られたら、メインブランチに統合します。メインブランチに統合されると、より高度なテストを実行して、何も壊れていないことを確認します。これらのテストは通常より長時間実行されるため、開発の初期段階でこのような長いテストによって中断したくありません。これらのテストはより複雑であったり、限られたリソースを使用したりする場合があります。すべてが問題なく見えたら、そのビルドはリリース候補としてプロモートされ、QAチームによる手動テストに送られ、Meta内部の開発者のマシンにデプロイされます。
バグがなく、すべてが良好に見える状態になったら、そのビルドはリリース可能な状態となります。御社でも採用されていると思われるこのフローには、私が指摘したい重大な欠陥がいくつかあります。 まず、最終段階のテストで人間に依存している点です。これは本来、自動化されるべきものです。人間は間違いを起こすものですし、その代償が高くつくことについては既にお話ししました。それに、私たち開発者は自動化が大好きです。5分の作業を自動化するのに5時間かけるとよく言われますが、私自身もその通りだと感じています。もう一つの問題は、基本的なバグがリリースパイプラインの後半になって発見されることです。QAチームがテスト用のビルドを受け取ったところ、基本的な機能が動作していない - メッセージを送信できないとか、最悪の場合、アプリケーション全体がクラッシュするといった状況に遭遇します。これには2つの問題があります。1つ目は、アプリが起動しないためQAチームが他の機能をテストできずブロックされてしまうこと。2つ目は、その機能を書いた開発者が既に別の作業に移っているため、Context Switching Taxとでも呼ぶべきコストを払って戻ってきて修正しなければならないことです。最後に、このパイプラインではパフォーマンステストが考慮されていません。
人間は小さなパフォーマンスの低下を検出するのが非常に苦手です。20ミリ秒程度のパフォーマンス低下は気付けないものですし、私たちはそういった低下を含んだアプリをリリースしてしまい、後になって気付くということがありました。 最初に話したいのは正確性の分野についてです。後ほど話すパフォーマンスの話題と比べると、これは少しシンプルです。なぜなら、正確性に関しては出力が二値的 - つまり動作するか、しないかのどちらかだからです。もちろん、今日は触れませんがメモリリークの問題は除外します。
正確性の具体例に入る前に、私たちのスマートフォンについて話したいと思います。ポケットやバックパック、財布の中に入れて持ち歩いているスマートフォンは、非常に高性能なデバイスです。多くの処理をこなすことができます。しかし、私たち開発者も負けてはいません - 開発しているアプリはそれらのスマートフォンの可能性を最大限に引き出し、その限界に迫っています。これらの限界は、デバイスによって異なります。AndroidとiOSの違いだけでなく、実機とエミュレータの間でも異なります。
コードが実行される環境に基づいた条件付き実行は、私たちのコードベースでよく見られるケースの1つです。皆さんのコードベースにもこの2つのようなコードがあるのではないでしょうか。コードが実行される環境に応じて、異なる処理を実行したい場合があります。これは非常に便利な機能です。特に、共有ライブラリが一方の環境でのみ利用可能な場合や、機能が環境によって異なる場合、あるいはエミュレータ上で実行する際に追加のログを取りたい場合などに役立ちます。
次に話したいのはGPUについてです。エミュレーションが特に問題となる分野です。スマートフォンとエミュレータの違いにより、GPUに関連する多くの問題が発生する可能性があります。特定のCPUとGPUの組み合わせで問題が発生する実際のケースに遭遇することがあります。幸いなことに、AWS Device Farmの助けを借りて、そういったデバイスを入手し、デバイスプールに追加することができます。アプリで何らかの動画処理にGPUを使用している場合、デバイスで可能な限界に既に到達している可能性が高く、そしてデバイスで可能なことはエミュレーションで可能なことと異なります。これらの違いにより、GPUのパフォーマンス低下やクラッシュ、その他多くの問題が発生する可能性があります。そのため、アプリが高度なGPU処理を使用している場合、実際の物理デバイスでテストすることが極めて重要です。
では、私のバックグラウンドにも関係するパフォーマンスについて話しましょう。これは私の心により近い分野であり、より挑戦的だと感じている部分でもあります。人間は10〜20ミリ秒程度の微細なパフォーマンス低下を認識することはできません。0.5秒なら気付きますが、ほとんどの場合、パフォーマンスの低下はとても小さいものです。私たちソフトウェア開発者がデバイスの限界に挑戦しているのと同じように、MetaもAWS Device Farmの限界に挑戦しています。誤解しないでいただきたいのですが、私たちがその限界に達したとき、通常はAWS Device Farmと協力してその限界を突破してきました。良い例が、これから話すRootedデバイスです。2〜3年前にNikhilと仕事を始めた時、AWS Device FarmにはRootedデバイスがありませんでした。これは私たちの要件の1つだったのです。Nikhilは計画の途中でチームに戻り、計画の半分を破棄して、私たちの要望を取り入れなければなりませんでした。
まず簡単なところから始めましょう。パフォーマンスをどのように測定するのでしょうか？ご存知かもしれませんが、タイムスタンプを取得し、コードを実行し、再度タイムスタンプを取得して、その差分を計算すれば所要時間が分かります。簡単そうに見えますが、大きな問題が1つあります。それは、システムにノイズが多く存在することです。 Metaでノイズを最小限に抑えるために使用しているテクニックについて詳しく説明する前に、ノイズの影響について話したいと思います。
Metaのパフォーマンステスト手法とノイズ最小化の取り組み
上のグラフでは、ノイズ最小化テクニックをすべて適用していない場合のパフォーマンスへの影響を示す信号が見えます。ちなみに、無効化が難しかったものについては、まだ一部適用されています。下のスクリーンショットを撮影した時、すべてのノイズ最小化テクニックを適用したグラフが得られました。ご覧の通り、グラフはよりスムーズになり、より小さなパフォーマンスの低下も検出できるようになっています。
ノイズは内部と外部の2つの領域に分類できます。内部はスマートフォンから、外部は外からのノイズです。私たちのアプリケーションは単独で動作することはほとんどありません。通常、設定やユーザー詳細、カスタム設定、その他アプリケーションをスムーズに動作させるために必要なものを取得するため、多数のサーバーコールを実行します。これらのサーバーコールは、同じリージョンや大陸のサーバーにヒットしているか、サーバーがビジー状態か、ピーク時間帯か閑散時間帯か、データベースのメンテナンスによってリクエストに時間がかかっているかなどの要因によって、300ミリ秒から数秒かかることがあります。5〜10秒で実行されるテストで、5、10、20ミリ秒の低下を検出しようとする奇妙な状況に陥っています。サーバーコールの影響を最小限に抑えるため、MetaではアプリからのすべてのリクエストをローカルのRecording Proxyを通してプロキシし、記録しています。サーバーへのリクエストとレスポンスを記録し、後でパフォーマンステストを実行する際に、記録したレスポンスを再生します。これがAWS Device Farmとそのカスタマイズが私たちの成功を可能にする最初の領域です。
デバイスについて話すとき、誰もが同じデバイスは同じように動作すると考えます。しかし、私たちが発見したのは、同じメーカーが製造し、同じモバイルCPUとOSバージョンを持つデバイスでも、わずかに異なるパフォーマンスプロファイルを持つ可能性があるということです。これは、10〜20ミリ秒の低下を検出しようとする場合、それらが正確な測定を妨げる可能性があることを意味します。理想的には、同じテストを常に同じデバイスで実行したいところですが、現実的にはそれは不可能です。デバイスが故障したり、アップグレードやその他の変更が必要になったりすることがあります。
これは次のトピックへの完璧な導入になりますね。アプリが遅いとか速いとは、一体どういう意味なのでしょうか？実際に問うべき質問は、「以前と比べて遅くなったのか、それとも速くなったのか？」ということです。そのため、Metaでは過去のデータと性能値を比較するのではなく、同一デバイス上で変更前と変更後の測定を行っています。これはAWS Device Farmのカスタマイズが役立つもう一つの領域です。というのも、テストの途中でアプリを再インストールする必要があるからです。変更前と変更後でアプリケーションを実行し、性能テストを行い、その後、パーセンテージの差を計算して10%遅くなったのか、5%速くなったのかを判断します。このように、常に同じデバイスで実行することで、異なるデバイスモデルからのノイズを減らすことができます。
次のトピックは、おそらく皆さんの多くが既に知っていて実践していることでしょう。データを多く収集すれば収集するほど、より正確な結果が得られます。理想的には、測定データから正規分布が得られることを期待します。Metaでは現在、少なくとも50回のトライアルを実行することを目標としています。なぜ50回なのかと疑問に思われるかもしれません。変更前に50回、変更後に50回実行して差を比較するのですが、各トライアルの間にアプリの再インストールや準備作業を行い、データを収集し、サマリーを作成する必要があります。すべてのテスト実行が終わる頃には、AWS Device Farmが設定している2.5時間の制限に既に達しています。この2.5時間という制限は絶対的なものではなく、変更可能だということは承知しています。
しかし、私たちの性能テストにおいて、必要なシグナルを得るにはちょうど良い時間だと考えています。 ここで、スマートフォンについて詳しく見ていきましょう。テスト実行中、スマートフォンはテストの実行だけでなく、多くの処理を行っています。バックグラウンドでプロセスが実行され、CPUを占有しており、これは性能テストから奪われているリソースです。これらのバックグラウンドタスクは、メンテナンス作業を行ったり、アップグレードの有無を確認したり、さらには性能テスト中に新しいアップグレードをダウンロードしたりすることもあります。
Metaでは、スマートフォン上で実行されているタスクとプロセスを分析し、どれだけCPUを使用しているかを確認します。それらを終了できるかどうか、終了後もスマートフォンが使用可能かどうかを評価します。答えは必ずしもイエスではありませんが、すべてが問題ない場合は、各性能テストの前にこれらのプロセスを終了します。これにより、スマートフォン自体からのノイズを低減できます。これは、Root化されたデバイスを使用する最初の領域でもあり、AWS Device Farmでの作業を開始した際にRoot化されたデバイスが必要だった理由です。
アプリケーションが実行されると、その状態はメモリとディスクに保存されます。終了時には通常、メモリの状態をディスクにダンプするため、次回起動時にはそこから読み込むことになります。このディスク上の状態には、アプリケーションの設定、ユーザー設定、ユーザー情報、キャッシュオブジェクトなどの情報が含まれています。アプリケーションが起動するたびに、このディスク上の状態を読み込み、それが初期状態に影響を与えます。これにより、性能測定において異なる条件で比較することになってしまいます。Metaでは、最初のトライアル後にアプリケーションのディスク上の状態のスナップショットを取得し、その後の各トライアルの前にそれを復元します。このアプローチにより、異なるディスク状態からのノイズを最小限に抑え、より小さな性能の低下も検出できるようになります。
温度は最も興味深いノイズの要因の1つであり、ここで取り上げることを予想していなかったかもしれません。私たちのスマートフォンのCPUは非常に高性能なユニットで、短時間で多くの処理を実行し、内蔵バッテリーで1日中持続することができます。しかし、これらは継続的な高負荷作業のために設計されているわけではありません。2時間にわたってパフォーマンステストを実行することは、まさに継続的に大量の作業を行うことに該当します。このような作業を行うと、スマートフォンはCPUの周波数を上げ、より多くのエネルギーを使用して熱を発生させます。スマートフォンが過熱し始めると、損傷を防ぐためにCPUの周波数を下げます。
これにより、テストの初期段階ではCPUが高い周波数で動作し、残りの部分では低い周波数で動作するという興味深い状況が生まれます。テストの順序によって、常に古いアプリケーションを先にテストするか、新しいアプリケーションを先にテストするかによって、一貫して改善や性能低下が見られる可能性があります。Metaでは、CPU周波数の変更による影響を最小限に抑えるため、CPUを手動でダウンクロックして過熱しない値に設定しています。CPUの周波数を、過度なエネルギー消費なしで長時間の実行が可能なレベルに設定します。周波数の変更がないことを確認するため、テストの前後でCPU周波数の変更回数を比較し、これらの値が一致しない場合はテストを無効としています。
これは、AWS Device Farmがroot化されたデバイスで役立つもう1つの領域です。CPUの周波数を操作するには、rootアカウントへのアクセスが必要です。 パフォーマンスの低下に対処するシステムを構築する際、誤検知との戦いは避けられません。これらの誤報は時間がかかり、イライラの種となりますが、システムに固有の部分です。そのため、Metaでは速度よりも精度を重視するアプローチを取っています。
単一のデータポイントで性能低下が見られた場合でも、すぐにアラートを発することはありません。代わりに、特定のテストの傾向と履歴を分析します。通常、実際にパフォーマンスの低下を確認するまでに時間がかかります。アラートの発信、オンコール担当者への通知、原因の特定といった性能低下後のワークフローを開始するまでに、より長い時間がかかる可能性があります。より慎重なアプローチを取ることで、システムが生成するノイズを減らし、シグナル対ノイズ比を改善します。これにより、オンコール担当者は本物のパフォーマンス低下に集中でき、チームはより効果的かつ効率的に活動できます。
実機テストの必要性とAWS Device Farmの役割
デバイステストが重要である理由と、AWS Device Farmがどのように役立っているかを簡単にまとめてみましょう。 今、皆さんの多くが自問していることは、実際に物理デバイスが必要なのかということでしょう。物理デバイスは購入や維持にコストがかかります。スケーラビリティも低く、多くの場合、起動や不具合時の再起動には物理的な操作が必要です。データセンターにデバイスを設置するための設備は標準では用意されておらず、rootアクセスができないなどの制限もあります。確かに、Emulatorは95%、あるいは99%のケースをカバーできるでしょう。
しかし、ここで考えなければならない質問があります。デバイスで一度も実行せずにアップをリリースしますか？Emulatorでは問題なかったアプリが、実機でクラッシュしたらどうなるでしょうか？クラッシュするアプリが、あなたのブランドにどれだけのダメージを与えるでしょうか？私は実機でのテストを保険に例えるのが好きです。誰もが保険に加入していますが、使うことは望んでいません。朝、車に乗るときに「今日は事故を起こして保険を使えたらいいな」なんて思う人はいませんよね。保険は、必要なときのために加入しているのです。実機でのテストもまさにこれと同じです。デバイスで問題を見つけたとき、テストしておいて本当に良かったと思うはずです。なぜなら、それがブランドに重大なダメージを与えていたかもしれないからです。
では、AWS Device Farmはこれらのケースをどのようにサポートしているのでしょうか？まず、非常に多様なデバイスを提供しています。実は、AWS Device Farmでは10年前のデバイスも現在稼働しているんです。同じタイプのデバイスを何百台も用意することと、何十種類もの異なるタイプのデバイスを何百台も用意することには大きな違いがあります。新しいタイプやモデルのデバイスを追加するたびに、管理が複雑になっていくことがわかるでしょう。デバイスの可用性も高く、故障の早期兆候を検知するためにデバイス上やその周辺で様々なメトリクスを監視しています。これらのメトリクスが許容レベルを下回ると、テストの最中にデバイスが故障しないよう、バックグラウンドで静かにデバイスを交換します。Root化されたデバイスは、私たちにとって特に有用な領域です。CPUを大量に使用するプロセスの終了やCPU周波数の操作について説明しましたが、これらはRoot化されたデバイスがなければできないことです。そして最後に、カスタマイズスクリプトによって多くの異なる操作が可能になります。アプリとサーバー間のすべての通信を記録するためのProxyの設定や、それをMockしたり、テストの途中でアプリを再インストールしたりするのは、その良い例です。
AWS Device Farmの最新の改善点と今後の展望
ありがとうございました。Unicoにお返しします。Jacob、ありがとうございました。まず最初に、お礼を申し上げたいと思います。Metaチームと一緒に仕事をするたびに、お客様がどのようにサービスを使用し、モバイルアプリテストの可能性を広げているのかについて、新しい発見がありました。長年にわたるご意見やご指摘に感謝しており、これからも素晴らしいものを一緒に作っていけることを願っています。
Jacobと長年一緒に仕事をしてきた中で、私の大好きな言葉の一つがあります。あるとき、Jacobは電話の最初はとても静かでしたが、突然「フィードバックがあります」と言いました。何かと尋ねると、「これは本当に動くんですね」と。私は彼らのシステムを見ていたので動くことは知っていると答えましたが、彼は「いや、これこそが最高の褒め言葉なんです。チームの誰かが初めて使ってみて、『これは本当に動く』と言ったんです」と説明してくれました。これが最も嬉しい経験でした。昨日も彼とこのことについて話していたのですが、彼はSteve Krugの「Don't Make Me Think」という本に情熱を持っていました。Device Farmが目指していることとこの本の考え方がとてもマッチしているからです。デバイスのことを考えなくていい、インフラのことを考えなくていい、この問題をどう解決するか考えなくていい。アプリとテストに集中してください、残りは私たちが対応します。
これまでの取り組みと、皆様のために解決しようとしている課題についてお話ししたいと思います。 Device Farmをすでにご利用の方もいらっしゃると思いますが、初めての方のために説明させていただきますと、Device Farmは標準で、XCTestやさまざまなバージョンのAppiumなど、多くの人気のあるテストフレームワークをサポートしています。これらのフレームワークは時間とともに進化し、より多くの機能が追加され、デバイスでの可能性が広がっています。例えば、XCUIは現在、テストプランの実行や、複数のエミュレーターやデバイスを起動して並列でテストを実行する機能を備えています。現在では、XCUIテストプランやより高度なシナリオに対して、すぐに使える環境を提供しています。IPAファイルだけでXCUIテストプランを実行できるようになり、ソースコードは不要で、plistファイルを提供するだけでよくなりました。また、これまでは不可能だった環境ファイルの受け渡しもできるようになっています。
Device Farmの設計原則は「エコシステムと戦わない」ということです。つまり、ローカルマシンで慣れている方法があるなら、Device Farmで実行するからといって新しいことを導入する必要はありません。ワークフローをDevice Farmにそのまま移行できます。手動テストのためのリモートアクセスの改善については、オーストラリアやアジア地域のユーザーがUS West 2リージョンのデバイスにアクセスする際に、レイテンシーが発生することを確認しました。Androidデバイスでは許容範囲でしたが、特定のiOSモデルと特定のOSバージョンの組み合わせで遅延が顕著になることがありました。この2週間で、リモートアクセスのパフォーマンスを改善し、iOS 18のレイテンシーを36%改善することができました。
高速化について言えば、Androidのテストホストマシンもアップデートしました。Device Farmでテストを実行する際には、デバイスとホストマシンの両方が必要です。これらのアップデートされたホストマシンでは、全顧客のエンドツーエンドテストが33%速く実行されるようになりました。また、事前にインストールされる依存関係の選択肢も広がりました。例えば、Xcode 14.0が必要な場合や、テストによってはXcode 13が必要な場合、あるいは特定のAndroid Platform ToolsやPython 3.16が必要な場合があります。
さらに一歩進んで、ローカルでの苦労を忘れてしまえるようにしました。たった1行で - 「device ph C use Python 3.16」と指定するだけで、環境全体の依存関係を処理してくれます。ローカル環境よりもさらにシンプルにしようとしているのです。移行する際に、環境での依存関係のインストールなどを避けることができる可能性があります。
コンソールの改善と使い勝手の向上は、特にAWS Device Farmを初めて使用するお客様にとって重要です。最初の体験までの時間が大幅に短縮され、より早く始められるようになりました。最初のテストをより早く実行できるように、多くのコンソールの改善が行われています。より速いエラーデバッグに関しては、単に「失敗した」という通知以上のことを目指しています。何か問題が発生した場合、実行可能なガイダンスを提供したいと考えています。より速いデバッグは、これまでの一般的なアプローチを超えて、テストが失敗した理由や実行がスケジュールされなかった具体的な理由を顧客に伝え、その修正方法についての提案を提供するアプローチを取っています。
リモートアクセスの改善により、現在ではiOSとAndroidの両方で25フレーム/秒でビデオをストリーミングできるようになりました。これはネットワーク速度に応じて自動的に調整されます。例えば、ネットワーク速度が4Mbps程度の場合、完全にフリーズするのではなく、ネットワーク速度に基づいてフレームレートを下げるなどの調整を行います。本日のご説明は以上となります。皆様、お時間を取ってお越しいただき、誠にありがとうございました。お持ち帰りいただいて、ぜひご検討いただければ幸いです。フィードバックもお待ちしております。このように顧客の皆様とお会いしてご意見を伺える機会を持てることは、私たちにとって大変貴重です。本日は、お時間をいただき、ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion