水曜日の午前9時12分、モバイルチームは生産環境でチェックアウトのバグを見つけました。Webはすぐにパッチを適用できます。iOSとAndroidは、ストアのレビューを通じては、少なくともそうではありません。サポートはチケットを集め、製品はステータス更新を求め、エンジニアは同時に3つの異なる質問に答えようとしています: 速く修正を配布できるか、ユーザーが修正を受け取るのにどれくらいの時間がかかるか、修正が効果的だったかどうかを証明できるか
クラウド アプリ パフォーマンスは、抽象的なバックエンドのトピックからリリースのトピックに変わる。JavaScript バンドル、構成、コピー、資産の更新をストア外で配信するハイブリッドモバイルチームにとって、パフォーマンスは単に「API が速いかどうか」ではなく、配信パスが更新をユーザーがいる範囲で発行、ルーティング、ダウンロード、検証、適用、観察、必要に応じてロールバックできるかどうか
Capacitor、Ionic、または他のハイブリッドスタックで働いている場合、このことはパフォーマンスの仕事の考え方を変える。マニフェストのフェッチが遅延したり、エッジ キャッシュが古いバンドルを提供したり、トレースがホットフィックスが失敗した場所を特定できない場合、すべて同じシステムの一部になります。アプリのエクスペリエンスとリリースメカニズムはつながっています。
目次
- モバイル チームが修正を配布できなかった
- クラウド アプリ パフォーマンスの本当の意味
- クラウドバックアップアプリの遅延の解剖学
- モバイルのアップデート用エッジネットワークとCDN配信
- 平均応答時間を超えるパフォーマンスとリリース結果の関連指標
- クラウドアプリの可視性をデータの沼から解放する
- SLA、エラーバックエット、チャネルベースのロールアウト
- クラウドアプリパフォーマンスの実践
修正を出荷できないモバイルチーム
実際の開発では何度も見たチームの構成は次のようになります: 1 人のモバイルリーダー、2 人のアプリエンジニア、1 人のバックエンドエンジニア、1 人のプロダクトマネージャー、そして怒ったユーザーからスクリーンショットを転送するサポート。
ネイティブシェルは変更する必要がありません。JavaScript バンドルは変更する必要があります。チームがアプリストアの提出にのみ依存している場合、現在は制御できないプロセスに待ち続けていることになります。その間、すべての会話は悪化します。サポートは影響を受けたユーザーを尋ねます。プロダクトは露出の低下時期を尋ねます。エンジニアはユーザーが修正されたcodeパスに到達しているかどうかを尋ねます。
遅延は、コードの遅延だけではありません。
このリリースの遅延を最初にフレーム化してみましょう。それは一部は本当ですが、より深い問題は クラウドで配信されるパフォーマンス 全てのアップデートパスで
live update が役に立つには、いくつかのことがうまくいく必要があります:
- デバイスがアップデートサービスに到達する必要があります: マニフェストの要求が遅い場合、または不連続的に失敗する場合、ユーザーは破損したバージョンに長く留まってしまいます。
- エッジが正しいファイルを提供する必要があります: キャッシュの無効化が遅い場合、1 つの国では修正が適用され、もう 1 つの国では古いアセットをダウンロードし続けることになります。
- アプリが安全かつ検証して適用する必要があります: サインされたバンドル、チャンネルターゲット、ロールバックルールは、rawスピードよりも重要です。
- チームは採用を観察する必要があります。 修正を送信することなく、受信したユーザーを知ることなく、単に複雑な推測の形でいるだけです。
実用的なルール: モバイルのホットフィックスは、実際にダウンロードおよび適用されたアフィクテッドデバイスが存在するときにのみ「送信」されます。
そのため、ライブアップデートのクラウドアプリのパフォーマンスは、サーバーレスポンス時間を最適化するだけでなく、実際のデバイスで、不均等なネットワーク上、異なる地理で、異なるアプリバージョンを実行しているユーザーに対するインシデントの回復時間を最適化することにもなります。
より良い質問は、アプリが遅いと感じたかどうかではなく
パフォーマンスについて話すチームは、インシデント後にしばしば、アプリが遅いと感じたかどうかを尋ねます。より有用な質問は、インシデントが広がる前に、ユーザー体験を変更するのに十分な速さで、配信システムが速かったかどうかです。
ハイブリッドアプリの場合、リリースパスは製品の一部です。チームが正しいバンドルを迅速に公開し、安全なチャンネルをターゲットし、信頼できた採用を確認することができれば、パフォーマンスはオペレーショナルになります。インシデントの際に、サポートロード、収益保護、エンジニアリングに製品がどれだけの信頼を置いているかを直接影響します。
クラウドアプリのパフォーマンスとは何を意味するか
モバイルチームが「パフォーマンス」を聞いたとき、通常はロードタイムを想像します。それはただの一部分です。 クラウドアプリパフォーマンス は、4つの質問が協力して機能する組み合わせです： 遅延、吞積、可用性、一貫性.
この概念を教える良い方法は、店のアナロジーを借用することです。
4つの質問を論理的に考えることができる
遅延 店のカウンターで待つ時間です。何かを要求し、答えが返ってくるまでの時間を数えます。
吞積 店が一度にクリーンに顧客をサービスすることができる数です。1人の速いカウンター手だけでは、交通量が増えるとすぐに列が形成されます。
可用性 店が開いているかどうかです。答えが来ないのは遅い成功ではありません。失敗したインタラクションです。
一貫性 各レジが同じ在庫数と価格を認識しているかどうかです。1つのレジがアイテムが存在すると言ってもう1つのレジが存在しないと言ってしまうと、顧客は遅延だけではなく混乱を経験します。
Aの歴史的ベンチマークは、最初の3つの用語を地面に据えるのに役立ちます。CloudOpsの分析によると、世界中の平均でHTTP要求と応答を受信するのに 426.4ミリ秒 必要でした。平均の可用性は 97.69% Google Cloud Observability によると、%で表されていました。それらの2つの数字は重要です。ユーザーは、サービスが「ほとんど稼働中」でも、遅延とダウンタイムを感じるからです。
モバイル アプリの更新配信は、すべての 4 つの要素に依存する
アプリケーションアーキテクチャが重要になります。アプリケーション__CAPGO_KEEP_0__、ストレージ、CDN、エッジロジック、リリースチャネルとの間の動く部分をマッピングする場合、実用的な
App architecture starts to matter. If you’re mapping out the moving parts between app code, storage, CDN, edge logic, and release channels, a practical primer on の概要は、配信パイプラインをユーザー体験に接続するのに役立ちます。 一般的な混乱
426.4ミリ秒
チームは、更新が遅いという一つの苦情を、4つすべてをまとめて抱えていることが多い。 しかし、それらは異なる失敗であり、異なる責任者がいる。
- 高延時: リクエストは正常に動作するが、ユーザーは待つ。
- 低吞収率: リクエストがバースト中に積み重なる。
- 低可用性: サービスが利用できない。
- 弱一貫性: ユーザーが一貫性のない状態や古いバージョンを受け取る。
それらを早く分離することで、インシデントレビューがはるかに鮮明になる。 「ネットワーク」について論争するのではなく、正確に失敗したレイヤーを特定することができる。
モバイルチームにとって、その区別は重要である。 更新システムは複数ステップのシステムであり、バンドルは小さく署名され正しくても、どれか1つの特性が劣化すると、ユーザーに遅すぎる可能性がある。
クラウドバックアップアプリケーションの延時解剖学
ユーザーが感じる遅延はほとんどが1つのものではありません。小さな待ち時間の積み重ねが原因です。ハイドレッドアプリがlive updateをチェックするとき、ユーザーはDNS、TLS、ネットワークの移動、メニューの生成、署名の検証、ファイルのダウンロード、ディスクの書き込み、JavaScriptの評価を個別のイベントとして認識しません。彼らは1つのポーズを感じます。
それがなぜ、遅延の改善は予算管理と同じように扱われるべきである理由です。 budget.
待ち時間の元となる要因はどこから来るのか
このモデルを使用してみましょう:
層
| 通常の範囲（ms） | 最適化のハンドル | DNSとTLSのセットアップ |
|---|---|---|
| 50から150 | 50 から 150 | コネクションの再利用、HTTPの長期接続、TLSセッションの再開 |
| ネットワークRTTの到着点 | 10から80 | 地域配置、CDNルーティング、エッジキャッシュヒット率 |
| 起源またはエッジ処理 | 20から300 | スリムマニフェスト生成、事前計算されたメタデータ、高速ストレージ検索 |
| デバイス側の適用とレンダリング | 100から600 | 小さいバンドル、事前温存されたJSエンジン、起動作業の減少 |
ネットワーク部分の基礎を学びたい場合は、 アプリケーションデリバリにおけるネットワーク遅延についての解説 モバイルチームの非ネットワークスペシャリストにとって役立つ
地理的情報は役に立つが、それだけでは十分ではない
広く引用されているアクセス性の研究では 世界の人口の多くが、100ミリ秒以内にクラウドのインフラにアクセスできることがわかりましたこれは、地域の展開がパフォーマンス戦略の中心になる理由を説明するのに役立ちます クラウドのアクセス性の議論の概要です。
それは励まされるものですが、ユーザーが自動的に高速のアップデートパスを得るわけではありません。 別の研究では、明らかに誤解を招くものです。.
モバイルチームはまずこれを調整するべき
エッジとクラウドのレイテンシーの分析
- モバイルチームが調整すべきものは何ですか まず、書き直す必要のないレイヤーから始めましょう:
- リリースメタデータの事前計算: リクエストごとに複雑なマニフェストを構築するのではなく、チャンネル、バージョン、署名データを事前に準備できる場合は、そこから始めてください。
- アプリの起動時間を削減する: 迅速にダウンロードできるバンドルでも、評価に時間がかかれば、ユーザーはそれが遅いと感じるでしょう。
- 可能な限り接続を再利用する: 繰り返しセットアップコストは、フラッキーモバイルネットワークで明らかにドラッグを加える。
「高速バンドルダウンロード」は、実際に新しいcodeが実行可能になるまでの待ち時間を保証するものではありません。
エッジネットワークとCDN配信のためのモバイルアップデート
内部ツールや1カ国アプリの場合、1つのクラウドリージョンがうまく機能するかもしれませんが、ユーザーが大陸をまたいでいる場合、ホットフィックスを迅速に適用する必要がある場合、状況はより難しくなります。モバイルアップデート配信の場合、エッジとCDNの設計が最初のバイトを迅速に取得するユーザー、古いコンテンツを受け取るユーザー、正確に間違った時点でオリジンにフォールバックするユーザーを決定します。
チームが通常考慮する3つの配信モデル
最も単純なモデルは 中央管理のオリジン配信デバイスは、1 つのリージョンからマニフェストとバンドルを取得します。操作は簡単で、論理的思考がしやすく、初期段階ではよく十分です。
次のステップは リージョナル デリバリー。ユーザーを近いリージョンにルーティングし、多くのユーザーにトランジット距離を下げ、負荷を均等に分散させるため、ストレージまたはアプリケーションロジックを数多くの主要リージョンに配置します。
次に、エッジ デリバリー があります。静的バンドルはユーザーに近い場所にキャッシュされ、軽量なロジックはエッジでマニフェストを書き換える、チャンネルをルーティングする、または署名関連のチェックを実行することができます。リクエストがオリジンに到達する前に。ここでは実用的な比較があります。
モデル
| Model | キャッシュ無効化の努力 | ベストフィット | ベストフィット |
|---|---|---|---|
| クラウド地域の統合 | 遠隔ユーザーにとってのパフォーマンスが向上 | 低 | 小さなフットプリント、低いリリース頻度 |
| 地域展開 | 普通 | 中 | 予測可能なユーザークラスタを持つマルチリージョンアプリ |
| CDNとエッジロジックを使用したエッジ配信 | キャッシュヒットが健全なときに最低 | 高 | グローバルアプリ、頻繁な更新、インシデントへの対応が必要なリリース |
チームが評価するメカニズムについてのガイド エッジネットワークのアプリ配信 正しい認識を与える
チームが低く見積もっている部分
キャッシュ無効化は、批判的修正が配信されるまで、解決された問題のように聞こえるが、実際にはリリースの整合性の問題である。
実際の問題である。
エッジの配置に関するテーゼでは、ユーザーに近いコンピュートを移動すると、6%から30%のアクセス遅延の改善が得られることがわかった。 また、代替ネットワークパスが、物理的に近いルートよりも40%以上のパフォーマンスを示すこともある。これは、ルーティングの質とピアリングが、ユーザー体験の尾部における物理的な近さと同等の重要性を持つことを示している。 この大規模エッジパフォーマンスのテーゼ の根拠に基づく.
A mobile team の決定マトリックス
更新配信レベルを選択する際に使用する基準:
- ユーザー分布: ユーザーが 1 つの国に集中している場合、集中配信または地域配信が十分かもしれません。
- リリース頻度: 頻繁にリリースするチームはエッジキャッシングの利点を受けるが、キャッシュの厳格な制御も受けます。
- ホットフィックスのコスト: インシデント中に古いバンドルが高価な場合、明示的な無効化とロールバックを実装する必要があります。
- 運用上の許容範囲: エッジロジックはパワーを提供しますが、ルーティングのバグ、署名一致のハンドリング、地理的な特定の驚きなど、さらに多くの場所でエラーが発生する可能性があります。
正解は「常にエッジを使用する」ではなく、リリースプロセスのスピードと爆発半径に応じた配信アーキテクチャを選択することです。
平均応答時間以外の重要なメトリック
平均応答時間はダッシュボードやユーザーの痛みについて議論するのにほとんど役に立たない。モバイルユーザーは平均リクエストを経験しない。彼らは、デバイス、ネットワーク、ユーザーがアプリを開いた直後、ホットフィックスをプッシュしたときに、リクエストを経験する。
なぜなら、尾部メトリクスがもっと重要だから。
製品マネージャーに提示する3つのビュー
冷却と温め方の遅延を開始する P95 と P99. 冷却時はアプリが新しく起動し、更新をチェックし、温め方の状態を助けることがないときに何が起こるかを知る。温め方時はアプリがすでに何らかの作業を実行した後もどれだけの抵抗が残っているかを知る。
その直下で、 Apdex を追跡する。モバイルチームが信じる閾値で。デスクトップウェブ用の閾値がハイブリッドアプリの起動パスに不正確である可能性がある。
次に追跡する エラーバイジット消費この会話は「アラートが発火したか？」から「どれくらいの時間で、信頼性のためのリリースルームを消費しているか？」にシフトします。
週間レビューで共有できるコンパクトな視覚化です。
パフォーマンスとリリースの結果を結び付けるメトリクス
ウェブチームが必要としないが、リリースごとに追加する必要がある一つのメトリクスを追加してみましょう。 採用率 リリースチャンネル別に採用率を測定します。固定バンドルが公開されたが、影響を受けるデバイスがまだ前のバージョンにいる場合、それは同時にパフォーマンスと配信の問題です。
メトリクスを次のように分割してみましょう。
- デバイスクラス: 古いスマートフォンは最初に起動と評価コストを明らかにします。
- ネットワークタイプ: Wi-Fiは、モバイルデータが即座に暴露する悪いバンドルの設計を隠すことができます。
- アプリバージョン: バージョンごとの失敗もあります。特にブリッジの動作やマイグレーションロジックに関しては。
この動画は、平均値を凝視するのではなく、パフォーマンスのテレメトリを解釈する方法を実践的に学ぶために、チームが必要な良い相談相手です。
読み物の注意
すべての小さなクラウドアプリのパフォーマンスの変化は意味のあるものではありません。AWS Kubernetesクラスタ789個に跨いだ2,366のベンチマークの長期的な研究では、 2,366のベンチマーク on 789のAWS Kubernetesクラスタ 総合的な変異性は下回っている 3.7%時点と曜日による微妙な影響があります。 クラウドアプリパフォーマンス変動調査クラウドアプリのパフォーマンスはランダムではないか？
クラウドアプリのパフォーマンスはランダムではないか？
クラウドアプリのパフォーマンスを観測する
クラウドアプリのパフォーマンスを観測する
クラウドアプリのパフォーマンスを観測する
クラウドアプリのパフォーマンスを観測する
クラウドアプリのパフォーマンスを観測する
クラウドアプリのパフォーマンスを観測する OpenTelemetry クラウドアプリのパフォーマンスを観測する
クラウドアプリのパフォーマンスを観測する アプリケーションの観測性 は、配信済みアプリケーションに適した実装例です。
第四の信号
現代のAPMガイドの最も役立つシフトの1つは、トレース、メトリクス、ログが診断のギャップを残すことを認識することです。トレース、メトリクス、ログは診断のギャップを残すことがあります。継続的なプロファイリングは、CPU、メモリ、ロック時間を消費する特定の関数を示すため、第四の信号として扱われるようになっています。この アプリケーションパフォーマンスモニタリングとプロファイリングのガイド.
は、live update ワークフローにおいて重要です。トレースは「更新を適用する」が長時間かかったことを示すかもしれません。プロファイリングは、ボトルネックがパッケージの展開、JSONのパース、ブリッジの初期化、または起動パスのロックであったかどうかを示すことができます。
2時を迎えるシステムを読みやすくする
小さく、規則正しく、簡潔なセットのビューを使用してください。
- リリースチャンネルダッシュボード: 採用、失敗、ロールバック数
- 更新トランザクショントレース: マニフェストのフェッチからバンドル評価まで
- 「トップのスタートアップのリグレッション」 アプリバージョンとプラットフォームでグループ化
- プロファイリングビュー: アップデート適用と初回レンダリング中の最も熱い関数
チームがこれらのワークフローを取り巻くより広いDevOpsおよびSRE運用モデルを改善している場合、 nexus ITグループがデバイスを提供する方法を理解するのは役に立つ なぜなら、ケーススタディでは観測性を運用慣行としてではなく、単にツールの購入として表現しているから
最も効果的なダッシュボードは、オンコールエンジニアが実際に開き、理解し、サポートがインシデントサマリーを書く前に行動するもの
SLA、エラーバックエット、チャネルベースロールアウト
SLAの言語は契約書ではきれいですが、実際の運用では汚いです。モバイルチームは、悪いリリース中にそのことを発見することが多いです。 "高可用性" は心地よい言葉ですが、ユーザーが一部の地域で現在のバンドルを取得できない場合に、更新を続けていくかどうかを決める必要があるとすると、心地よい言葉ではなくなります。
可用性目標をリリースポリシーに変換
可用性目標をロールアウトの段階を定義するものとして使用し、単に顧客の約束として使用しないようにします。
| 利用可能性目標 | 月間ダウンタイム予算 | 適切なロールアウトステージ |
|---|---|---|
| 99% | 約7時間18分 | 内部および実験チャネル |
| 99.9% | 約43分 | ベータとステージングされた生産ロールアウト |
| 99.99% | 約4分23秒 | ビジネスクリティカルパス向け広範な生産 |
ダウンタイム予算は単純な月間計算から来ますが、実際には配信チェーン全体を考慮すると実際の予算は縮小します。オリジンは健常であるかもしれませんが、DNS、エッジプロパゲーション、または悪いチャネルルールによって、デバイスが意図されたリリースを受け取ることができません。
アップデートプラットフォームがこの運用を具体的に表現する必要がある場合は、リリース配信の アップタイム保証を確認してください と比較して、独自のインシデント仮定値とします。
エラーバックボリュームは、製品と信頼性がつながる場所です。
エラーバックボリュームは、チームに許可構造を与えます。バーンが静穏であれば、リリースリスクを受け入れることができます。バーンがホットフィックス後に急上昇した場合、次のチャンネルへのプロモーションを一時停止します。
ハイブリッドアプリの強力なロールアウトランダーの例はこちらです。
- 内部: エンジニアがマニフェスト、署名、適用フローが予想どおり動作することを検証します。
- ベータ: フレンドリーなユーザーとテスターがエッジデバイスのエラーを捕捉します。
- ステージドプロダクション: 限定されたアウディエンスが最初にバンドルを受け取ります。
- フルプロダクション: アップデートがデフォルトチャンネルターゲットになります。
同じ規則が、機能フラグ、オーバー・ザ・エアのJavaScript更新、または両方を使用する場合に適用されます。
ロールバックトリガーを設定する前にそれらが必要になる前に
ロールバックルールは明確で、面白くないものでなければなりません。インシデントの際にそれらを即興で作りません。
有用なトリガーには含まれます:
- 採用が予想外に止まる: デバイスは新しいバンドルに移行していないが、チェックインしている:
- スタートアップロードタイムが尾部ユーザーで急激に悪化する: 特に古いデバイスや弱いネットワークの場合:
- 適用失敗が1つのプラットフォームまたはバージョンに集まる: よくあるのはブリッジまたはパッケージングミスマッチです。
- リアルユーザーモニタリングで体験が劣化している: シンセティックチェックはモバイル固有の痛みを逃がします。
明確な言葉で、問題を伝えましょう。失敗したことを、どのユーザーが影響を受けたか、どのチャネルが停止されたか、どのロールバックが発生したか、そして次の決定点はいつになるかを説明してください。ステークホルダーは、テレメトリのダンプが必要ではありません。彼らは、実行可能な明確さが必要です。
Cloud App Performanceを実践する
クラウドアプリのパフォーマンスを改善する最速の方法は、インフラストラクチャのヴァニティプロジェクトとして扱うのではなく、実際に改善することです。ユーザーはキャッシュヒットレートについて気にしません。ただし、キャッシュヒットレートがユーザーに感じられるものが変わる場合、気にします。製品は、オリジンCPUについて気にしません。ただし、修正が影響を受けるデバイスに到達するスピードが変わる場合、気にします。
この週にユーザーに影響を与える1つの指標を選択し、実際に実現しましょう。
1週間のチャレンジ
ユーザーに影響を与える明確な指標を選択してください。良い選択肢には、更新チェック後にインタラクティブに初回起動時間、または生産チャネル内の最も遅いユーザー向けのアップデートバンドルのダウンロード時間が含まれます。
次の4つのことを行ってください:
- 基準値を測定してください: 実際のユーザーモニタリングを使用してください。シンセティックチェックのみではありません。
- 1つのターゲットされた変更を行ってください: 例えば、バンドルサイズを縮小する、manifest出力を事前計算する、またはエッジキャッシュのルールを厳密にするなど。
- ステージチャンネルを通して配信してください: ロールアウト前のアドプションとエラーの監視。
- 同じメトリックを再測定します。 ユーザー視点の結果が改善しない場合、最適化はあまり価値がありませんでした。
このチェックリストは、ほとんどのモバイルチームにとって、優先順位の正しい順序を捉えている。
今期の優先事項
最も速くインシデントの痛みを軽減できる作業から始めましょう。
- エッジキャッシュの動作を検証します。 マニフェストの新鮮さとバンドルの無効化が、実行計画で想定しているように動作することを確認します。
- バンドルのサイズと起動コストを検証します。 配信速度と評価速度は両方とも重要です。
- 更新フローのP95ダッシュボードを作成します。 平均値に止まらない。
- エラー予算の消費をチャンネル別に追跡する: 信頼性とリリース速度は同じスコアボードで測定されるべきである。
- ロールバックの作業手順を書く: トリガー、責任者、コミュニケーション手順を含める。
このカテゴリで実際のツール例が必要なら、 Capgo CapacitorやElectronチームが署名されたライブアップデート、チャンネルベースのロールアウト制御、デバイスごとのログ、ロールバックサポートをグローバルエッジネットワークを通じて提供する必要がある場合、codeの例としては、Capacitorが挙げられる。重要なのは、ベンダー名ではなく、更新を公開、観察、逆転できるワークフローを選択することである。更新がウェブ配信されるcodeの場合、ストアレビューを待つ必要がない。
厳格な測定は英雄的なエンジニアリングを上回る。1週間で1つの目に見える指標を動かす方が、4分の1の期間をバックエンドの数字を磨くことよりも良い。
チームがCapacitorアプリを配信し、live update配信の制御、観察性、段階的なロールアウト、ロールバックの安全性を高くしたい場合、 Capgo __CAPGO_KEEP_0__アプリを配信し、__CAPGO_KEEP_1__配信の制御、観察性、段階的なロールアウト、ロールバックの安全性を高くしたい場合、__CAPGO_KEEP_0__はそのワークフローに適している。__CAPGO_KEEP_0__で署名されたJavaScript、CSS、config、資産の更新をストアレビューを待たずに配信し、採用と失敗を密かに追跡することで、クラウドアプリのパフォーマンスを実際のものから理論的なものに変えることができる。
