移す前に経路を整理する
ブラウザー収集、サーバー送信、送信先への転送は引き続きあり得ます。Consent Modeは状態を伝えて一部の動作を調整しますが、それだけで選択バナーや法的検証を提供しません。
| 段階 | 確認 | 求める証拠 |
|---|---|---|
| ブラウザーまたはアプリ | 収集項目と選択。 | 実際に送った要求。 |
| 収集サーバー | 検証、フィルター、アクセス。 | 受理・拒否イベント。 |
| 送信先 | 実際の転送データ。 | 本文と同意規則。 |
| 運用 | 保存、権限、回復。 | 削除、障害、アクセス試験。 |
実際の送信を試験する
- 目的ごとに許可フィールドと受領先を定義します。URL、パラメーター、識別子、ログを転送前に調べ、既定のフィルターを前提にしません。
- 承諾、拒否、選択変更を端から端まで試験します。ブラウザー、サーバーコンテナ、各送信先を確認します。
- 受信、受理、転送イベントを照合します。重複、欠落、障害、回復を試し、サーバー費用と負荷も測定します。
利点と義務を別に評価する
同等の経路で性能を確認します。初期ブラウザー収集が必要な場合もあります。自社ドメインは免除を意味しません。フランスの一部アクセス解析の免除は条件付きで、広告タグを自動的には含みません。
一次資料
- Google Tag Manager — Server-side tagging introduction [EN]
- Google Tag Manager — Server-side Consent Mode [EN]
- CNIL — Cookies et mesure d’audience [FR]
サーバーサイドのタグ付けには、フローテストが必要です。
タグをサーバーに移行しても、測定基準が自動的に準拠または最小限になるわけではありません。実際の展開環境で、送信されたリクエスト、受信者、識別子、および拒否後の動作を検査してください。
- ブラウザ、収集サーバー、ベンダー、および送信フィールドをマッピングしてください。
- 選択前、拒否後、および同意撤回後にテストを実施してください。
- 設定を宣言された目的および関連するCNIL条件と比較してください。
一次資料：CNIL — Outils de mesure d’audience et traceurs. 関連する方法：実践ガイドを読む.
API割り当てと制限
制限は容量、再試行、利用者間の配分に影響します。
- 制限がアカウント、キー、対象のどれに適用されるか、同時実行をいくつ許可するかを記録します。平均頻度が低くても、無制限の待ち行列は過負荷を招きます。
- 429でRetry-Afterがあれば解釈し、次の要求まで待ちます。待機時間の増加とクライアント間の分散を、試行回数と全体期限の上限と組み合わせます。
- 書き込み応答が失われたら、再試行前に状態を確認します。模擬試験で制限、遅延応答、中止を組み合わせ、重複した効果なく行列が終了するか確認します。
再現できる受け入れ事例
架空の例です。顧客や実際の観測結果を示すデータではありません。
事例の入力を見る
{
"http_status": 429,
"retry_after_seconds": 30,
"workers": 20,
"retry_budget": 3,
"retry_budget_scope": "per_worker_retries_excluding_initial_request",
"scheduling_example": {
"response_received_at_seconds": 0,
"illustrative_retry_seconds": [
30,
31,
32,
33,
34
],
"workers_per_second": 4,
"alternative_deadline_seconds": 25,
"total_attempts_if_all_retries_used": 80
}
}期待される判断
30秒待ち、20ワーカーの再試行を分散し、回数を制限します。
20クライアントの再試行を分散し、回数を数える
架空の例：20ワーカーが +0 s にそれぞれ 429 と Retry-After: 30 を受信します。時刻は分散例であり、サーバー容量を保証しません。各ワーカーは初回要求に加えて3回再試行できます。
| 方針 | 計算または時刻 | 変化と限界 |
|---|---|---|
| 一斉に再試行 | 20 × 1 = 20 @ +30 s | 30秒待てば指定の待ち時間は守れますが、20件が同時に戻るため、負荷の集中が再発し得ます。 |
| 再試行を分散 | 4 × 5 = 20 @ +30…+34 s | 毎秒4件を5秒間に分けると、20件の再試行を分散できますが総数は減りません。この例示スケジュールは、ランダムな揺らぎを加えたバックオフ方針の代わりにはなりません。 |
| 期限が25秒後 | 25 s < 30 s → 0 | 残り時間が指定の30秒未満なら、契約に従って中止または延期します。期限に合わせて待ち時間を短縮しません。 |
| 最大試行数 | 20 × (1 + 3) = 80 | すべて使うと、初回20件と再試行60件で合計80件です。上限があっても成功や安全な繰り返しは保証されません。 |
検証手順
- 割当範囲と再試行予算を記録します。
- 許可された試験だけで枠を使い切ります。
- 429、Retry-After、制限付き時系列を残します。 技術的な制限と業務結果を区別します。クォータの枯渇を在庫ゼロという応答に変換しないでください。
- 外部負荷のない模擬環境で四層各三回の総呼出しを数えます。
- 架空のキュー仕事を期限切れにし、新しい操作が始まらないことを確認します。
- 模擬障害後に許可された仕事を段階再開し、呼出し、期限、一意な結果を保存します。
429は以前の書き込みが未実行だった証拠ですか？
いいえ。応答が失われた操作を別途照合します。別の試行への応答から状態を判断しません。
一次資料：IETF — RFC 6585, HTTP 429. 関連する方法：実践ガイドを読む.
炭素測定の境界
比較には共通の境界と機能単位が必要です。
- 構成要素、地域、期間、機能単位を示します。例えば完了した処理一件です。同じサービスを提供する条件で比較します。
- エネルギー、排出係数、ハードウェアの配分を記録します。測定と推計を区別し、除外を排出ゼロとみなしません。
- 架空例：(12 + 3) gCO2e / 5件 = 1件あたり3 gCO2e。不確かな仮定を変え、総排出量も比較します。
再現できる受け入れ事例
架空の例です。顧客や実際の観測結果を示すデータではありません。
事例の入力を見る
{
"functional_unit": "accepted_task",
"energy_kWh": 2,
"intensity_gCO2e_per_kWh": 100,
"embodied_gCO2e": 50,
"accepted_tasks": 100,
"SCI_gCO2e_per_task": 2.5
}期待される判断
(2 × 100 + 50)/100 = 1タスクあたり2.5 gCO2eです。宣言した範囲に限ります。
検証手順
- 境界、機能単位、係数を定めます。
- 電力、機器由来排出、成果を分けます。
- 根拠と暗黙の相殺なしの計算を残します。
一次資料：Green Software Foundation — Software Carbon Intensity. 関連する方法：実践ガイドを読む.
API：層をまたぐ再試行の増幅を防ぐ
アプリ、SDK、プロキシ、サービスが同じ呼出しを再試行する場合があります。架空の四層が各三回の総試行を行うと、障害依存先へ最大81回届きます。既存の割当て管理に共通予算と有用な期限を加えます。
- アプリ、SDK、プロキシ、依存先の自動試行を整理します。責任層を選び、契約に応じ追加再試行を無効化または調整します。最初の試行も予算に含めます。操作IDを保存し、非冪等操作の再試行前に不明な作用を確認します。
- クライアントの実際の制約を踏まえ、待機、接続、処理を含む期限を設定します。期限切れをキュー受入れ前に拒否します。ローカル取消しはサーバー停止を証明しないため状態を照合します。全キューを同時再開せず段階的に復旧します。
各層三回は全体三回ですか？
いいえ。架空の四層で各三回なら最終依存先へ最大3⁴ = 81回です。
期限切れは遠隔作用を取り消しますか？
必ずしもそうではありません。新しい不要な仕事を止め、開始済み操作は状態確認と可能な補償が必要です。
一次資料：AWS — Timeouts, retries, and backoff with jitter. 関連する方法：実践ガイドを読む.