Google Home Vitals（クラウド）

このダッシュボードとアラートのスイートを使用すると、Google Home エコシステムとの高品質な統合をプロアクティブに維持できます。Google は、すべてのユーザーに高品質なエコシステムを提供できるよう、パートナー様をサポートすることに尽力しています。

ダッシュボードは 3 つのセクションで構成されており、それぞれが統合全体の品質に影響する重要な部分をカバーしています。

  1. Google to Partner Metrics - Google からクラウド バックエンドへの呼び出しの健全性を測定します。

  2. System Health - Partner to Google Metrics - システムから Google への呼び出しの健全性を測定します。

  3. デバイスの健全性 - 状態の精度 - ユーザーのクエリの処理に使用される Google システムに保存された状態の精度を測定します。

指標が目標値を満たしていない場合は、ユーザー エクスペリエンスに影響する可能性のある問題を示すために、赤色でハイライト表示されます。次の情報では、各ターゲットの詳細と、それがユーザーにとって重要な理由について説明します。

以下のボタンでダッシュボードに直接移動できない場合は、[概要] ページを選択し、[ダッシュボード] を選択します。次に、[マイ ダッシュボード] リストから [Google Home Vitals Dashboard (Cloud)] を選択して、ダッシュボードを表示します。

[ダッシュボード] に移動

Google からパートナーへの指標

クエリ/実行の成功率が 99.5%以上の指標は、ユーザーのコマンドが正しく実行される頻度を測定します。これにより、「デバイスにアクセスできません」などのアシスタントの応答や、実行されなかったコマンドを誤って確認することを回避できます。

「成功」の定義は何ですか？

Google Home プラットフォームが、意図したアクションが実行されたこと、またはリクエストされた状態が取得されたことを示す有効なレスポンスを受信した場合、トランザクションは成功としてマークされます。

実行をブロックしない例外（lowBattery 例外を伴う SUCCESS ステータスなど）を含むレスポンスは、成功したトランザクションとしてカウントされます。警告は表示されたものの、コマンドはデバイスに届き、インテントは満たされました。

「失敗」の定義

一般的なプラットフォーム エラーコードに記載されているエラーのうち、パートナーが対応可能とマークされているものは、QUERY と EXECUTE の成功率を計算する際に「失敗」とみなされます。

Query/Execute Latency (p90) <= 1000ms 指標は、リクエストされたアクションの待ち時間を測定し、ユーザーが長時間待つことがないようにします。たとえば、ライトが消えるまで数秒待つなどです。

レイテンシの指標

レイテンシは、統合の応答性がエンドユーザーにどのように感じられるかを示す重要な指標です。ダッシュボードでは、90 パーセンタイル（P90）レイテンシが追跡されます。これは、最も「遅い」ユーザーのエクスペリエンスを表します（たとえば、P90 が 800 ミリ秒の場合、リクエストの 90% が 800 ミリ秒以内に確認されたことを意味します）。

Google は、技術的な精度を確保するため、ステータス チェックとデバイス コマンドでレイテンシの測定方法を変えています。

1. クエリのレイテンシ（疑問文）

これは、Google がデバイスの現在の状態をリクエストしたときの Cloud-to-cloud の往復時間を測定します。

  • 開始: Google がフルフィルメント URL に action.devices.QUERY リクエストを送信します。
  • 測定ウィンドウ: クラウドが完全な HTTP レスポンスを受信、処理、Google に送信するのにかかる時間。
  • 終了: Google がサービスから最終レスポンス ペイロードを受信して確認します。

2. EXECUTE Latency（アクション）

これは、Google がデバイスに制御リクエストを送信したときのコマンド確認時間を測定します。

  • 開始: Google がフルフィルメント URL に action.devices.EXECUTE リクエストをディスパッチします。
  • 測定ウィンドウ: クラウドがコマンドを受信して確認応答を返すまでに要した時間。
  • 終了: Google が SUCCESS、PENDING、または OFFLINE のステータス レスポンスを受信します。
  • 技術的な範囲: この指標は、Google のクラウドとユーザーのクラウド間の「応答確認」時間を測定します。物理ハードウェア（電球など）が物理状態の変化を完了するまでの時間は測定されません。これは、多くの場合、クラウド間のパス外のローカル メッシュ ネットワークのレイテンシが関係するためです。

レイテンシの低減オプション

地理的ルーティングに関するアーキテクチャの推奨事項

エニーキャスト IP の実装が実現できない場合は、ユーザーが最も近いリージョン データセンターからサービスを受けられるように、次の費用対効果の高い代替手段をおすすめします。

  1. グローバル ロード バランシング（GLB）

    静的ルーティングの代わりに、グローバル アプリケーション ロードバランサ（ほとんどの主要なクラウド プロバイダから利用可能）を使用します。

    • 仕組み: ネットワーク エッジに配置される単一のグローバル エントリ ポイント（URL）を構成します。ロードバランサは、Google のフルフィルメント クラスタからのリクエストの地理的な送信元を自動的に検出し、最も近いリージョンの正常なバックエンドにトラフィックを転送します。

    • メリット: 構成の複雑さとコストを大幅に削減しながら、エニーキャストのパフォーマンスを実現します。

  2. 位置情報認識 DNS（GeoDNS）

    • 仕組み: DNS クエリの地理的位置に基づいて、フルフィルメント URL を異なる IP アドレスに解決するように DNS プロバイダを設定します。

    • 実装: DNS プロバイダが Google の下り（外向き）ポイント向けに最適化されていることを確認します。Google の地域別フルフィルメント サービス（米国、EU、アジアなど）がドメインを解決すると、その特定の地域のデータセンターの IP アドレスが返されます。

アプリケーション レイヤでの最適化戦略

インフラストラクチャ レベルのルーティングに加えて、アプリケーション レイヤで次の戦略を実装して、リクエスト処理のレイテンシを短縮できます。

  1. 「トランポリン」プロキシ メソッド

    プライマリ データセンターを維持する必要がある場合は、リージョン ライトウェイト プロキシ サーバー（トランポリン）を使用して初期ハンドシェイクを処理します。

    1. Google がグローバル URL にアクセスします。

    2. リージョン プロキシ（軽量の Nginx や Lambda 関数など）がリクエストを受信します。

    3. プロキシは、内部の高速バックボーンを介してプライマリ データベースにペイロードを転送します。

    メリット: これにより、長距離リクエストのレイテンシの最大の原因となることが多い「TCP ハンドシェイク」の時間を短縮できます。

  2. アクセス トークン リージョン ヒント

    アカウント リンク（OAuth）プロセス中に、ユーザーのホーム リージョンを特定できます。

    実装: Google に発行される access_token にリージョン ID をエンコードします。Google がフルフィルメント リクエストを送信すると、ゲートウェイはトークンをすぐに検査し、データベース ルックアップを必要とせずにリクエストを正しいリージョン クラスタに転送できます。

システム健全性 - パートナーから Google への指標

成功率が 99.5%以上を維持することで、Google Home でデバイスのステータスが正しく表示され、デバイスの追加と削除、自動化のトリガー、履歴イベントの Google Home app (GHA) の [アクティビティ] タブへの表示が確実に行われるようになります。

成功率は、クラウドが状態の更新をプッシュしたときに Google から返される HTTP レスポンス コードに基づいて計算されます。Google 側のインフラストラクチャの問題でパートナーがペナルティを受けないようにするため、この指標では Google 内部エラーが失敗回数から除外されます。計算に含まれる API 呼び出しは、HomeGraph API リファレンスで確認できます。

「成功」の定義は何ですか？

  • 2xx（成功）: 状態の更新が Home Graph によって正常に受信され、処理されました。

「失敗」の定義

  • 4xx（パートナー エラー）: 失敗を表し、クラウドから送信されたリクエストに問題があることを示します。一般的なコードは次のとおりです。
    • 400 Bad Request: 構文が無効なため、サーバーがリクエストを処理できませんでした。一般的な原因としては、不正な形式の JSON や、文字列値に "" でなく null を使っていることなどが挙げられます。
    • 404 Not Found: リクエストされたリソースが見つかりませんでした。このエラーは通常、リクエストされたデバイスが見つからないことを意味します。ユーザー アカウントがリンクされていないか、無効な agentUserId を受け取った可能性もあります。agentUserId が SYNC レスポンスで提供された値と一致していること、DISCONNECT インテントが適切に処理されていることを確認してください。
    • 429 リソース不足: インテグレーションが割り当てられた割り当てを超過しました。割り当ての管理については、ダッシュボードの上部にある「ステップ 1」の手順をご覧ください。

デバイスの稼働状況 - 状態の精度

状態の精度が 99.5%以上を満たすことで、ユーザーがデバイスの状態を確認したり、ホームに質問などの AI 機能を使用したりする際に、正しい結果が表示されるようになります。状態の精度が低い場合、自動化が実行されず、履歴エントリが GHA の [アクティビティ] タブに適切なタイミングで表示されないことがあります。詳細については、レポートの状態をご覧ください。

品質ダッシュボードでは、全体的な精度と最低のタイプ/特徴の組み合わせという 2 つの異なる指標を使用して、このデータを 1 時間ごとに追跡します。

1. 精度コンポーネント

この指標は、報告された状態を既知のインテントの結果と照合できる「サンプル」から導き出されます。

2. ダッシュボードの指標（1 時間ごとの計算）

ダッシュボードでは、1 時間間隔に基づいて精度が計算されます。1 時間の合計サンプル数が 100 未満の場合（S_Total < 100）、その時間の精度は N/A に設定されます。

ビュー 1: 全体的な精度（グローバル平均）

これは、すべてのデバイスタイプとトレイトを組み合わせた統合の合計精度を表します。エコシステム全体の健全性の加重平均が表示されます。

  • 計算: すべてのデバイスの合計状態精度 / すべてのデバイスの合計状態合計。

ビュー 2: 最も低いタイプ/特性の組み合わせ

これにより、統合で最も信頼性の低い特定のカテゴリが特定されます。これにより、高品質の大音量デバイスが低品質の小音量デバイスを隠すのを防ぎます。たとえば、99.5% を超える状態精度でライトの数が多く、状態精度の低いスイッチの数が少ない場合、平均値では見過ごされる可能性のあるスイッチの改善が必要であることがわかります。

  • 計算: すべての特性 / デバイスの組み合わせにおける状態の精度/状態の合計の最小値。
次へ
Cloud Monitoring