システム設計

1. 容量と保持期間

読み取り値には、認証済みのメーター識別子、UTC の interval_start、流量測定値、ペイロードバージョンが含まれると仮定します。インターバルは 15 分の境界に揃えられます。論理的な識別子は (meter_id, interval_start) であり、アップロードの試行回数には依存しません。

定常状態の取り込み:

• メーター 1 台あたりの 1 日の読み取り数: 24 × 60 / 15 = 96。
• 全体の 1 日の読み取り数: 1,200,000 × 96 = 115,200,000。
• 1 秒あたりの平均読み取り数: 1,200,000 / 900 = 1,333.33。
• 生データの 1 日あたりの量: 115,200,000 × 200 = 23,040,000,000 bytes = 23.04 GB。
• 400 日間の生データ保存量: 23.04 × 400 = 9,216 GB。
• 3 レプリカの場合: 9,216 × 3 = 27,648 GB = 27.648 TB。

これらは 10 進単位を用いたペイロードのみの見積もりです。インデックス、レコードのフレーミング、一時的な重複アップロード、運用ログ、ファイルシステムのオーバーヘッドには追加の容量が必要です。400 日間のライフサイクルは、再試行のコピーすべてではなく、正規の生の読み取り値に適用します。請求台帳は、電力会社の財務保持方針に従って別途管理します。

2. 再接続のサイジングと取り込み

ストームにより 1,200,000 × 30% = 360,000 台のメーターが切断されます。各メーターは 6 × 4 = 24 件の読み取り値をバッファリングするため、バックログの読み取り数は 360,000 × 24 = 8,640,000 件になります。

アップロードを 600 秒間に分散させた場合:

• バックログのレート: 8,640,000 / 600 = 14,400 readings/second。
• 同時のライブレート: 1,333.33 readings/second。
• ピーク時の持続的な一意のレート: 15,733.33 readings/second。
• 対応するワイヤスループット: 15,733.33 × 200 = 3.1467 MB/second。

これは指定された 10 分間の持続的ピークであり、瞬間的なバッチや再試行トラフィックの上限ではありません。バックログのアップロードは再接続の時間枠全体にペース配分し、ライブの読み取り値が飢餓状態にならないよう、メーターごとの公平性を確保します。

ステートレスな認証済みゲートウェイ、メーター単位でパーティション分割された複製された永続ログ、独立したコンシューマグループ、正規ストレージ、ダッシュボードのプロジェクション、リーク処理器を使用します。ゲートウェイは少なくとも 60,000 回/秒のアップロード試行に対応できるように、下流のコンシューマは 30,000 件/秒の一意の読み取り値に対応できるように用意します。これらは再試行のヘッドルームを提供するものであり、再試行の最大数が数学的に有界であると想定するものではありません。

各読み取り値は、障害ドメインをまたぐレプリカへの耐久的なクォーラム永続化の後にのみ確認応答します。部分的なバッチの確認応答では、どのレコードが永続化されたかを正確に示します。確認応答されていないレコードは再試行の対象となります。ゲートウェイは、指定された負荷の下で 30 秒を十分に下回るように確認応答し、通常運用時の再試行の増幅を防ぎます。

バックログ自体は 8,640,000 × 200 = 1.728 GB を占め、レプリケーション後は 5.184 GB になります。追加のフレーミングのヘッドルームとして、レプリケートされたログ容量を少なくとも 100 GB 確保します。未処理で確認応答済みのレコードは決して削除しません。コンシューマが遅れた場合は、保持期間を延長するか、耐久ストレージへ退避させます。

キューはバッチとコンシューマの中断を吸収します。自動スケーリング、バックプレッシャー、優先順位付けされた受付制御により耐久性を守ります。6 時間のバックログが残っていても、メーターの上書きまでには 42 時間の猶予があります。設計された取り込み能力により、10 分間のアップロード時間枠内でバックログを解消できます。すでに上書きされた読み取り値を復旧することはできず、メーターのバッファ上限を超える停止を経た配信も保証できません。

3. 請求とダッシュボードの正確性

請求データベースは、転送機構ではなく、正確に 1 回のカウントを保証します。そのインターバル台帳には (meter_id, interval_start) に対する一意制約があります。

消費された読み取り値ごとに、1 つのデータベーストランザクションでインターバルを挿入し、挿入が成功した場合にのみ請求期間の集計値を更新します。重複は何もしない操作になります。コンシューマは、そのトランザクションがコミットされた後にのみログのオフセットをコミットします。したがって、クラッシュが発生しても安全な再生が行われます。1 つの識別子に対して競合するペイロードは、請求済みの値を黙って置き換えるのではなく、隔離されます。承認された修正は、明示的な調整台帳を使用します。

請求は、完全性の照合が完了した後にのみ締め切られます。欠落した読み取り値は、電力会社の方針が必要な例外として扱い、使用量を捏造することはありません。これにより、再試行があっても受信した有効な各インターバルが一度だけカウントされることが保証されます。

ダッシュボードは同じキーを独立して upsert します。到着から可視化までの遅延を追跡し、5 分の 99 パーセンタイル目標に向けて通常経路を用意します。ストーム時には、コンシューマをスケールアウトし、60 分以内にバックログを解消します。遅れて到着した過去の読み取り値が最新に見えないよう、測定時刻と鮮度を表示します。

4. イベント時刻に基づくリーク検知

リーク処理は到着順ではなく interval_start を使用します。重複排除された読み取り値は、メーターごとの順序付きインターバルマップに格納します。アラート候補には、正確に 15 分間隔で隣接する 96 個のインターバル開始時刻があり、それぞれの流量がゼロでないことが必要です。

遅れて到着した読み取り値によって、以前は分離していた断片がつながる場合があるため、観測されたすべての断片を即座にアラートすると、最終的に 1 つの連続した期間に対して複数の通知が発生する可能性があります。そのため、通知は確定したイベント時刻の接頭辞からのみ発行します。

メーターのアップロード完全性プロトコルを追加します。メーターは、それ以前のすべてのインターバルが耐久的に確認応答されたか、期限切れのために利用不可と明示的に宣言されたあとにのみフロンティアを報告します。サーバーは、それらの確認応答された読み取り値が正規ストレージに到達した後にのみ処理フロンティアを進めます。保留中の再試行と処理中のバッチは、早すぎる前進を防ぎます。フロンティアとギャップ宣言は永続化します。

「48 時間経過している」という事実だけでは完全性が証明されないことに注意してください。送信と処理によって遅延が生じ得るためです。切断されたメーターはフロンティアを進められないため、そのアラートは照合が完了するまで待機します。アラートの遅延要件は指定されていません。

欠落したインターバルは、ゼロでも非ゼロでもなく、未知です。 それをまたぐ 96 インターバルのウィンドウはすべて資格を失います。未解決の間は、確定も妨げられます。利用不可として明示的に確定されると、水が流れていないと断定することなく、検証済みの連続期間を断ち切ります。

確定したインターバルを時系列順に処理し、連続した非ゼロのカウントと通知済みフラグを保持します。カウントが 96 に達したら、メーターと検証済みの期間開始時刻をキーとする通知アウトボックスのエントリを、トランザクションにより 1 件だけ作成します。その後の非ゼロのインターバルは、フラグを保持します。確定したゼロまたは利用不可のインターバルは、その検証済み期間を終了させます。耐久的な通知識別子と冪等な配信エンドポイントにより、再生によって論理的なアラートが別途作成されることを防ぎます。

5. 正確に 3 つのトレードオフ

1. 採用: 耐久ログ優先の確認応答。 不採用: 永続化前の確認応答。 クォーラム書き込みは遅延とインフラコストを増やしますが、再試行は安全なままであり、確認応答された読み取り値はゲートウェイの障害を生き延びます。

2. 採用: 請求のためのトランザクション型インターバル台帳。 不採用: 転送レベルの正確に 1 回配信への依存。 データベースの一意性と原子的な集計値の更新には書き込み容量が必要ですが、再生やクラッシュをまたいで金銭的なカウントの不変条件を直接保護します。

3. 採用: 確定したイベント時刻のリークアラート。 不採用: 後から訂正する到着順の即時アラート。 完全性の追跡は、特に切断後に通知を遅らせますが、遅れてバッファリングされたデータが、独立して通知された断片を 1 つの連続期間に統合することを防ぎます。

設計とキャパシティ

メーター側のゲートウェイと下流サービスの間に、耐久性のあるレプリケーション済みの取り込みログを置きます。ゲートウェイはメーターを認証し、インターバルのタイムスタンプとペイロードを検証したうえで、(meter_id, interval_start) をキーとして検針値を発行します。ログはメーターIDでパーティション分割します。これにより、1台のメーターのレコードは順序が保たれ、メーター全体は複数のパーティションに分散されます。アップロードに対する確認応答(ACK)は、レコードが必要なレプリカへ耐久的にレプリケートされた後にのみ返します。ACKが失われた場合、メーターが再送することがあります。システムは、データ損失のリスクを負うよりも、重複を受け入れます。

定常状態のレートは次のとおりです。

• 1,200,000 meters ÷ 900 seconds per interval = 1,333.3 readings/second。
• 1,200,000 × 96 intervals/day = 115,200,000 readings/day。
• 115,200,000 × 200 bytes = 23,040,000,000 bytes/day = 23.04 GB/day。
• 400日間では、23.04 GB × 400 = 9,216 GB = 9.216 TB の生の検針値になります。3レプリカでは、9.216 TB × 3 = 27.648 TB です。

これらの数値は、指定されたワイヤ上のレコードサイズと10進単位を使用しており、インデックス、ストレージ形式のオーバーヘッド、運用上の余裕分は含みません。生データの全履歴は、レプリケートされた時間パーティション方式のアーカイブに保存します。取り込みログは、400日間のアーカイブとして使うのではなく、コンシューマーの通常の復旧をカバーできる期間だけ保持します。

想定されるストームでは、30% × 1,200,000 = 360,000 台のメーターが影響を受けます。6時間には 6 × 4 = 24 インターバルが含まれるため、再接続したメーターは 360,000 × 24 = 8,640,000 件のバッファ済み検針値をアップロードします。これを10分間に分散すると、8,640,000 ÷ 600 = 14,400 readings/second になります。これに全メーターからのライブトラフィック 1,333.3 readings/second を加えると、名目上のピークは約 15,733 readings/second です。10分間に到着するペイロードは、ライブ検針値約800,000件を含めて、約 9.44 million × 200 bytes = 1.888 GB です。

ゲートウェイとログ書き込みのキャパシティは、計算上のピークの約2倍にあたる、少なくとも 32,000 readings/second の持続 で確保してください。キューの容量は、少なくとも9.44百万レコードの到着ウィンドウ全体を確保し、さらに再試行と処理遅延のための余裕を加えて予約します。レプリケーション済みログがバーストを吸収する間に、コンシューマーが追いつきます。独立してスケールできるコンシューマーが、アーカイブ、課金ストア、ダッシュボードビュー、アラート状態へ書き込みます。このキャパシティにより、記載したバーストを、受理済みの検針値を落とすことなく吸収できます。メーターの48時間上書き制限は上流の制約です。再接続前に上書きされた検針値は、バックエンドでは復元できません。

正確性と提供

課金は、(meter_id, interval_start) にデータベースが強制する一意制約を持つ正規の検針テーブルを使用します。そのシンクは insert-or-conflict 操作を行います。最初のコピーが検針値を挿入し、同じキーでの再試行や繰り返しのアップロードは、課金対象のインターバルを新たに作りません。課金は、この正規テーブルのみを集計します。シンクは、検針値とログコンシューマーの進捗をトランザクションとしてコミットするか、リプレイに安全な書き込みを使用します。これにより、クラッシュとリプレイで二重計上されることはありません。値が食い違う重複は、別のインターバルとして黙って計上するのではなく、調査のためにフラグを立てます。

別のコンシューマーが、顧客向けのマテリアライズドビューを維持します。同じインターバルキーでアップサートし、表示する最新の検針値は、到着順ではなくインターバルの時刻に従って更新します。到着からビューまでのエンドツーエンドのレイテンシを監視し、通常運用の目標である99%が5分以内に表示されるよう、コンシューマーとパーティションをスケールします。指定されたバーストの間は、ビューが最大60分遅れることがあります。その間も、耐久ログとアーカイブは損なわれず、ビューが追いつくのを待ちます。顧客には鮮度情報を表示できるため、遅延したビューを現在の検針値と取り違えることはありません。

漏水検知は、メーターをキーとし interval_start で順序付けるイベント時間の計算です。各インターバルは、評価する前に重複を排除します。インターバルの結果は保持しておき、遅れて届いた検針値が状態を更新し、影響を受けるインターバル連続区間を再計算できるようにします。後のインターバルが先に届いたというだけで、インターバルが欠落していると判断してはいけません。完全性ウォーターマークは、該当する取り込み時刻までに受信したすべてのログレコードを処理し終えた後にのみ進め、取り込み時刻より少なくとも48時間後ろに設定し、キュー遅延のための運用上の猶予を追加します。これは、メーターが保持する最大のバッファ期間を考慮したものです。

欠落したインターバルは、ゼロでない流量を示していないものとして扱います。 そのウォーターマークより後ろにあり、かつ検針値が存在しない場合、連続区間は途切れます。それまでは、ゼロではなく未解決です。確定した連続96インターバルがすべてゼロでない流量を示した時点で、その連続区間に対して1件のアラートを発行します。メーターと連続区間に基づくアラート識別子を永続化し、冪等な通知アウトボックスを使用して、リプレイによって同じ連続区間に別のアラートが送られないようにします。完全性を待つことで、アラートは最大で遅延許容期間の分だけ遅れることがありますが、遅れて届いた順序外の検針値が誤った結果を生むことは防げます。

ちょうど3つのトレードオフ

1. 採用:コンシューマーの前にレプリケーション済みログを置く。却下:ゲートウェイからすべての宛先への同期書き込み。 ログはインフラを増やし、いくらかのレイテンシを加えますが、再接続バーストを緩衝し、取り込みを低速な課金サービスやダッシュボードサービスから切り離します。
2. 採用:非同期に更新されるダッシュボードのマテリアライズドビュー。却下:取り込み中の同期的なダッシュボードへのファンアウト。 結果整合的な更新で、定められた通常時5分とバースト時60分の目標を満たしつつ、顧客のクエリを高速に保てます。同期ファンアウトでは、メーターの受理がダッシュボードの可用性とバースト負荷に結び付いてしまいます。
3. 採用:ウォーターマークに基づく、遅延データに対応した漏水アラート。却下:到着順に基づく即時アラート。 限定された遅延ウィンドウを待つ分、アラートの速度は犠牲になりますが、インターバルに基づく連続区間の正しい判定と、欠損データの明示的な扱いが可能になります。

1. 容量の見積もり

定常レート

• 1,200,000 メートル ÷ 900 秒/間隔 = 1,333 件の読み取り/秒
• 1,333 × 200 B ≈ 267 KB/秒

1日あたりの生データ量

• 1日あたりの読み取り件数: 1,200,000 × 96 間隔 = 115.2 M
• 1日あたりのバイト数: 115.2 M × 200 B = 23.04 × 10^9 B = 23.04 GB/日

保持期間分の生データストレージ

• 1コピー: 23.04 GB × 400 日 = 9,216 GB = 9.216 TB
• 3レプリカ: 9.216 TB × 3 = 27.65 TB

インデックスとコンパクションのオーバーヘッドはこれに加わります。列指向圧縮によって、容量はかなり削減される見込みです。

2. 再接続時のバースト

ピークレート

• オフラインのメーター: 30% × 1.2 M = 360,000
• メーターごとのバッファ済み読み取り: 6 時間 × 4 間隔/時 = 24
• 未送信データの合計: 360,000 × 24 = 8.64 M 件の読み取り
• 全メーターが 600 秒以内に均等に分散して再接続: 8.64 M ÷ 600 = 14,400 件の読み取り/秒
• ライブトラフィックを加算: 14,400 + 1,333 = 15,733 件の読み取り/秒。これは定常時の約 11.8 倍、つまりおよそ 3.15 MB/秒に相当します。
• 確認応答が遅延した場合、再試行によってこれが 2 倍になる可能性があるため、約 32,000 件の読み取り/秒分を用意します。

設計による吸収の仕組み

1. ステートレスなゲートウェイ（ロードバランサーの背後にある MQTT/HTTPS）が、メーターの認証情報とペイロードのスキーマを検証します。容量は 32k/秒に加え、N+1 の予備容量で設計します。
2. 永続ログ（Kafka、レプリケーション係数 3、acks=all、meter_id でパーティション分割）。ゲートウェイは、ログへの書き込みが確認された後にのみ、メーターへ確認応答を送ります。したがって、確認応答された読み取りはすべて永続化され、確認応答されなかった読み取りはメーターによって再試行されます。いずれの場合も、データが失われることはありません。数 MB/秒は Kafka にとって負荷が小さいため、書き込みは高速なままで、確認応答は 30 秒のタイムアウトよりも十分に早く返り、再試行はまれに保たれます。
3. 2 つのトピック。 ゲートウェイは interval_start が過去 30 分以内の読み取りを live に送り、それより古いものはすべて backfill に送ります。コンシューマーは live を優先して処理するため、嵐の最中でもライブデータに対する 5 分のダッシュボード目標が維持されます。
4. 下流のコンシューマーがバックログを吸収します。 コンシューマーはピークに追いつく必要はありません。5,000 件の読み取り/秒であれば、8.64 M 件のバックログは約 29 分で処理され、緩和された 60 分のダッシュボード制限内に収まります。Kafka の保持期間は 7 日間なので、コンシューマーが停止しても、データが失われることはありません。
5. メーター側のジッター。 ファームウェアは、再接続時と再試行時にランダムなバックオフを追加し、バーストをさらに平滑化します。

3. 正確に 1 回だけの課金

課金台帳データベースが、正確に 1 回だけのカウントを保証します。主キー (meter_id, interval_start) を使用します。

• 課金コンシューマーは INSERT … ON CONFLICT (meter_id, interval_start) DO NOTHING で書き込みます。
• 再送されたアップロード、ゲートウェイによる再送、クラッシュ後のコンシューマーによる再処理は、いずれも競合に当たるだけで、何も変更されません。
• Kafka のオフセットは、データベースへの書き込みが成功した後にのみコミットされます。これにより、冪等なシンクへの少なくとも 1 回の配信が実現し、実質的には正確に 1 回と同じ結果になります。
• 重複が 異なる 値で到着した場合、最初に保存された値が保持され、競合は調整キューに送られます。値が加算されることは決してありません。
• 課金の合計は、この重複排除されたテーブルからのみ計算されます。
• ダッシュボードのストア（時系列データベース）も同じキーを upsert で使用するため、そのグラフにも重複はありません。

4. イベント時刻による漏水アラート

meter_id をキーとするステートフルなストリーム処理系（例: Flink）が両方のトピックを読み込み、到着時刻ではなくイベント時刻（interval_start）で動作します。

メーターごとの状態

• 直近 296 間隔（48 時間 + 24 時間の履歴 + 余裕）にわたるビットマップ。各スロットは 非ゼロ、ゼロ、または 不明 のいずれかです。
• 現在の連続区間。それぞれ最初の間隔で識別されます。
• 各連続区間について、すでにアラートを発行したかどうかを記録するフラグ。

ルール

• 遅延して到着した読み取りは、その位置にかかわらず、対応するスロットを埋めます。到着順序は問題ではなく、重複は何もしません。
• アラートは、96 個の連続するスロットがすべて存在し、かつすべて 非ゼロ である場合にのみ発行されます。すべてのスロットは確認済みデータで埋められている必要があるため、後から到着したデータによって、すでに発行されたアラートが無効になることはありません。
• 欠損間隔。 スロットが 48 時間未満（猶予 1 時間を加えた期間）の間は 不明 です。連続区間を延長することも途切れさせることもなく、アラートは単に保留されます。interval_start + 49 h が過ぎると、その読み取りが届くことはあり得ないため、スロットは 欠損、これにより連続区間が途切れる として確定されます。未検証のデータに基づいてアラートが発行されることは決してありません。
• 連続区間ごとに 1 件のアラート。 アラートレコードは (meter_id, streak_start) をキーとして、一意制約を持つアラートテーブルに保存されるため、再処理されたイベントが 2 件目のアラートを送信することはありません。連続区間は ゼロ の読み取りまたは確定した欠損で終了します。遅延した読み取りが欠損を埋めて 2 つの連続区間を結合した場合、結合された連続区間は最も早い streak_start を保持し、「アラート済み」フラグを引き継ぐため、依然として 1 件のアラートしか発行されません。
• 状態は永続ストレージにチェックポイントされます。再起動後、処理系はコミット済みのオフセットから再生し、同じ状態を再構築します。

5. トレードオフ

1. 読み取りに確認応答を返すタイミング

   • 採用: 複製されたログへの書き込み後に確認応答を返す。これにより読み取りが失われないことが保証され、確認応答ごとのコストは数ミリ秒です。
   • 不採用: 受信時にメモリから確認応答を返す。これは高速ですが、ゲートウェイがクラッシュすると、メーターがバッファから既に削除した読み取りが静かに失われます。

2. 重複の除去方法

   • 採用: 課金台帳の一意キーによる冪等な書き込み。これはシンプルで検証しやすく、どのソースからの再生にも耐えられます。
   • 不採用: エンドツーエンドの Kafka 正確に 1 回トランザクション。これらは、確認応答が失われた後にメーターが再試行するなど、Kafka の前 で発生した重複を検出できません。また、調整コストが増え、運用も困難です。

3. 漏水検出における欠損間隔の扱い

   • 採用: 確定した欠損は連続区間を途切れさせる。これにより、推測されたデータに基づく誤アラートが発生せず、すべてのアラートを顧客に対して裏付けることができます。代償として、48 時間の接続欠損がある実際の漏水は、発見が遅れる可能性があります。
   • 不採用: 欠損を連続区間の継続とみなす、または隣接する読み取りから補完する。これにより、より多くの漏水を検出できますが、実在しなかった読み取りに基づいてアラートが発行され、「連続区間ごとに 1 件のアラート」というルールも不明確になります。

まとめ

• 容量: 定常時 1,333 件の読み取り/秒、23.04 GB/日、3 レプリカで 27.65 TB を保存。
• バースト: ピーク 15,733 件の読み取り/秒。確認済みの書き込み後にのみ確認応答を返す永続ログと、ライブデータの優先処理によって吸収。
• 課金: 台帳の一意キーによって、正確に 1 回だけのカウントを保証。
• 漏水アラート: イベント時刻で計算し、未検証のデータに基づいて発行することは決してなく、連続区間ごとに 1 件に制限。

1. 容量の見積もり

定常状態

• 1日あたりの計測間隔数: 24 h × 4 = 96。
• 1秒あたりの計測値数: 1,200,000 / 900 s = ≈1,333 件/s。ネットワーク上では約 267 KB/s になります。
• 1日あたりの計測値数: 1,200,000 × 96 = 115.2 M。
• 1日あたりの生データ量: 115.2 M × 200 B = 23.04 GB、つまり ≈23 GB/日。
• 保持: 23.04 GB × 400 日 = 9,216 GB ≈ 1コピーあたり 9.2 TB。
• 3レプリカの場合: 9.216 TB × 3 = ≈27.6 TB(27,648 GB)。
• これにはインデックスと圧縮が含まれていません。約30%の余裕を加えると、確保すべき容量は約36 TBになります。

2. 再接続時のバースト

• 影響を受けるメーター: 30% × 1.2 M = 360,000。
• メーターごとのバッファ済み計測間隔数: 6 h × 4 = 24。
• バックログ: 360,000 × 24 = 8.64 M 件の計測値、つまり 1.73 GB。
• アップロード時間枠: 10 分 = 600 s、均等に分散されるとして、バックログのレートは 8.64 M / 600 = 14,400/s。
• リアルタイムのトラフィックは 1,333/s で継続します。
• ピーク = 14,400 + 1,333 ≈ 15,733 件/s。定常状態の約11.8倍、または約3.1 MB/s です。

再送がこれに加わります。確認応答が30秒を超えて遅れると、メーターは再送します。そのため、取り込み経路は ピークの2倍、約32,000/s を基準に設計します。実際には、1ノードあたり約5,000/s の、ステートレスな取り込みノードを8台用意し、N+2 の予備を備えます。

データを失わない仕組み

1. 取り込みゲートウェイは計測値を検証し、Kafka などの永続化されたパーティション分割ログに追記します。acks=all、レプリケーション係数 3、min.insync.replicas=2 を使用します。追記が成功した後にのみ、メーターへ確認応答を送ります。
2. ログは meter_id をキーとする 48 パーティションを持ち、7日分のデータを保持します。バーストは約 3 MB/s であり、ログにとっては問題になりません。コンシューマは、データを失うことなく数分から数時間遅れても構いません。
3. ゲートウェイまたはログが過負荷になった場合、503 または確認応答なしを返します。メーターは計測値を保持して再試行します。その 48 時間のバッファは、6時間の停止と復旧をカバーし、約42時間の余裕が残ります。したがって、バックプレッシャーによってデータが失われることはありません。
4. 下流のコンシューマ(課金ライター、ダッシュボードのプロジェクタ、漏水プロセッサ)は、それぞれ別のコンシューマグループを持ちます。書き込みが成功した後にのみオフセットをコミットするため、クラッシュしても損失ではなく再生が発生します。
5. コンシューマは約 30,000/s を処理できるよう設計します。そうすると、8.64 M 件のバックログは約5分で解消され、60分の緩和されたダッシュボードの予算内に十分収まります。通常運転時には遅延は秒単位にとどまり、計測値の 99% で5分の目標を満たします。

3. 正確に1回の課金

配信は、メーターの再試行、ゲートウェイの再試行、ログの再生のすべての段階で、少なくとも1回です。正確に1回の効果は、1つのコンポーネントによって保証されます。それが 計測値ストア で、meter_id によってシャーディングされたレプリケーション済みの SQL ストア(3レプリカ)です。このストアは 主キー (meter_id, interval_start) を持ちます。

• 課金ライターは INSERT … ON CONFLICT DO NOTHING を実行します。重複は何もしない操作となり、それがメーターの再試行、再生、コンシューマの再起動のいずれから来たものであっても同じです。
• 課金合計は、このテーブルへの問い合わせによって計算されます。二重にインクリメントされうるストリームのカウンターとして保持されることは決してありません。
• interval_start はメーターが設定し、15分グリッドに揃えられます。ゲートウェイは位置がずれた値を拒否し、隔離します。
• 同じキーに異なるペイロードの重複が届いた場合、最初の書き込みが優先されます。その競合はレビュー用の不一致テーブルに書き込まれるため、課金が黙って変更されることはありません。
• 下流のコンシューマは、挿入によって新規作成されたと報告された行に対してのみ動作します。したがって、ダッシュボードと漏水プロセッサも重複排除されます。

このストアは生データのストアでもあります。その 27.6 TB は、上で計算したレプリケーション後の数値です。

4. 遅延データおよび順序が前後したデータの下での漏水アラート

ルールは interval_start によって判定されるため、プロセッサは イベント時刻を使用し、到着時刻に基づくウィンドウを一切持ちません。これは meter_id をキーとするステートフルなストリームジョブで、新規に挿入された計測値のみを消費します。

メーターごとの状態(約70バイト):

• 直近288間隔(72時間)を覆う、間隔ごとに2ビットのリング。3つの値は 不明、ゼロ、非ゼロ です。
• 直近にアラートを出した連続期間の alerted_range = [start, end]。

計測値を受け取るたび、間隔 t について:

1. t のスロットを設定します。
2. それが非ゼロであれば、t から左右に走査し、t を含む 非ゼロ 間隔の最大連続区間を求めます。
3. 区間の長さが 96 以上で、かつ alerted_range と重ならない場合、アラートを1件発行します。その後、alerted_range を当該区間に設定します。
4. 区間が alerted_range と重なる場合、alerted_range を拡張し、何も発行しません。

状態は計測値の集合のみに依存し、その順序には依存しないため、逆順で到着したバッチも、順序どおりに到着した場合と同じ結果になります。隙間を埋める遅延計測値によって、2つの短い区間が結合されて96長の区間になることがあり、その時点でアラートが発火します。ゼロの計測値は連続期間を終了させます。次に該当する区間は新しい連続期間であり、再度アラートを出すことがあります。

アラートは alerted_range と同一トランザクションでアウトボックスに書き込まれ、一意キー (meter_id, streak_start) がこれを補強します。したがって、再生や再起動によって2件目のアラートが送られることはありません。

欠損間隔。 欠損間隔は 不明です。ゼロでも非ゼロでもなく、補間されることも決してありません。 それは連続性を断ち切るため、隙間をまたいでアラートが発生することはありません。欠損した計測値が後から到着した場合、その連続期間は自動的に再評価されます。これは間隔から最大48時間後に起こりえます。48時間が経過すると、その間隔は永久に失われ、連続期間は途切れたままになります。これは誤報を避ける方針であり、長期停止の後にアラートが遅延するか、見逃される可能性があるというコストを伴います。見逃しアラートの方が誤報よりも悪いと判明した場合、別個の「データ欠損」通知を追加できます。

72時間より古い状態は退避されます。48時間の上限より古い計測値は、正当には到着しえないため、記録のうえ無視されます。

5. トレードオフ

1. メーターへいつ確認応答するか。

• 採用: 永続ログへの追記後に確認応答する。
• 却下: SQL ストアへの書き込み後に確認応答する。
• 理由: ログへの書き込みは高速な追記であり、データベースの負荷の影響を受けません。したがってバーストによって確認応答の遅延が 30 秒を超えて伸び、再試行の嵐を引き起こすことがありません。
• コスト: 確認応答の時点では、データはまだ照会できません。課金は遅延を許容し、バースト時にはダッシュボードが 60 分を許容するため、これは受け入れられます。

2. どこで重複排除するか。

• 採用: 冪等な挿入を伴うデータベースの主キー制約。
• 却下: ストリーム段階での重複排除、すなわち Kafka トランザクション、またはインメモリもしくは Bloom フィルタによる「既読」キャッシュ。
• 理由: Kafka トランザクションが扱うのはログ区間のみで、新しいメッセージを生成するメーターの再試行は対象外です。キャッシュは容量に上限があり、再起動時に失われることがあります。Bloom フィルタには偽陽性があるため、課金対象の計測値を捨ててしまうおそれがあります。
• コスト: 重複のたびに、低コストな競合挿入が1回発生します。ピークの2倍の負荷でも、ストアの容量には十分余裕があります。

3. 漏水をどのように評価するか。

• 採用: 新しい計測値のたびに評価する、イベント駆動のメーターごとのビットマップ。
• 却下: 定期的なバッチスキャン、またはウォーターマークで閉じるウィンドウ。
• 理由: ビットマップは順序に依存せず、ウォーターマークによる遅延なしに48時間の遅延に耐えられるため、最後の欠損間隔が到着した時点でアラートが発火します。ウィンドウでは48時間のウォーターマークが必要になり、すべてのアラートが遅延するか、後で修正が必要な誤った結果を出すことになります。
• コスト: 約 85 MB のキー付き状態(1.2 M × 約 70 B)と、チェックポイントからの慎重な状態復旧が必要になります。

地域スマート水道メーター取り込みアーキテクチャ

1. 容量見積もりと計算

定常状態の毎秒読み取り数

• メーター群: $1,200,000$ 台のメーター。
• 間隔: 15分ごと（$15 \times 60 = 900$ 秒）。
• 計算:
  $$\text{定常スループット} = \frac{1,200,000\text{ 読み取り}}{900\text{ 秒}} = 1,333.33\text{ 読み取り/秒}$$

1日あたりの生データ量

• メーター1台あたりの1日の読み取り数: $\frac{24\text{ 時間} \times 60\text{ 分}}{15\text{ 分}} = 96\text{ 読み取り/日}$。
• 1日の合計読み取り数: $1,200,000 \times 96 = 115,200,000\text{ 読み取り/日}$。
• ペイロードサイズ: 通信上 $200\text{ バイト/読み取り}$。
• 計算（$1\text{ GB} = 10^9\text{ バイト}$ の10進単位を使用）:
  $$\text{1日の取り込み量} = 115,200,000 \times 200\text{ バイト} = 23,040,000,000\text{ バイト} = 23.04\text{ GB/日}$$

400日保持のための生ストレージ（3レプリカ）

• 1コピーの400日分ストレージ:
  $$400\text{ 日} \times 23.04\text{ GB/日} = 9,216\text{ GB} = 9.216\text{ TB}$$
• 3重レプリケーション時のストレージ:
  $$9,216\text{ GB} \times 3 = 27,648\text{ GB} = 27.648\text{ TB}$$

2. 再接続バーストのサイジングと吸収

バーストピークの計算

• 影響を受けるメーター: $30% \text{ of } 1,200,000 = 360,000\text{ 台}$。
• 停電時間: 6時間 = メーター1台あたり累積 $6 \times 4 = 24\text{ 間隔}$。
• バッファされた読み取りの合計: $360,000 \times 24 = 8,640,000\text{ 読み取り}$。
• 再接続ウィンドウ: 10分 = $600\text{ 秒}$（均一に分散）。
• バックログからのバースト到着率:
  $$\text{バースト率} = \frac{8,640,000\text{ 読み取り}}{600\text{ 秒}} = 14,400\text{ 読み取り/秒}$$
• 同時に発生するライブの定常トラフィック: $1,333.33\text{ 読み取り/秒}$。
• 合計ピークスループット:
  $$\text{ピーク率} = 14,400 + 1,333.33 = 15,733.33\text{ 読み取り/秒} \approx 15,734\text{ 読み取り/秒}$$
• ピーク取り込み帯域幅:
  $$15,734\text{ 読み取り/秒} \times 200\text{ バイト} = 3,146,800\text{ バイト/秒} \approx 3.15\text{ MB/秒 (25.2 Mbps)}$$

吸収戦略

1. エッジでの終端と高速ACK: 水平スケールするステートレスなAPIゲートウェイ群が取り込みエンドポイントの前段に配置されます。メーターはACKを30秒受け取れないと再試行するため、ゲートウェイはバッチ構造を検証し、ペイロードを分散コミットログ（Apache Kafka）に直ちに追加してから、50ミリ秒未満でHTTP 202/200を返します。これにより、未確認のクライアントタイムアウトと連鎖的な再試行を排除します。
2. キューによる疎結合化: Kafkaは永続的な衝撃吸収材として機能します。パーティションは meter_id のハッシュで厳密に分割されます（最大 $50,000\text{ メッセージ/秒}$ を余裕をもって処理するため64パーティションを使用）。バースト中に下流のコンシューマ処理が遅くなっても、取り込み経路はエッジゲートウェイに背圧をかけることなく、3.15 MB/秒のデータストリームを直接ディスクに永続化します。
3. ダッシュボード・コンシューマのスロットリング: 顧客ダッシュボードの投影ワーカーは取り込みの消費を絞り込み、緩和された60分のバーストSLOを容易に満たしつつ、重要な請求およびアラートのストリーム処理装置に専用の消費能力を確保します。

3. 厳密に一度だけの請求取り込み

ネットワーク再試行は必然的に、同一の (meter_id, interval_start) を持つ重複メッセージを生成します。本設計では、冪等なアップサートとリレーショナルの主キー制約の組み合わせにより、**請求ストレージ読み込み層（請求取り込みパイプライン）**で厳密に一度だけのカウントを強制します。

メカニズム

• 自然キー: 請求ステージング台帳の主キーは (meter_id, interval_start) です。
• 重複排除の境界: トランザクション型のバッチローダーがKafkaからイベントを取得し、決定的なアップサート意味論（INSERT ... ON CONFLICT (meter_id, interval_start) DO NOTHING）を用いて、追記専用の不変な請求台帳データベースに書き込みます。
• 二段階の冪等性:
  1. ステージングの前に、ステートフルなストリームプロセッサ（例: Apache Flink）が、RocksDBに裏打ちされた状態テーブルを使用し、スライディングする48時間の重複排除フィルタ（メーターの最大48時間のバッファに一致）を保持します。このウィンドウ内で発生した重複するネットワーク再試行は直ちに破棄されます。
  2. フィルタを迂回する再試行、またはワーカーの再起動後に再読み込みされる再試行は、(meter_id, interval_start) のデータベース一意インデックス制約に当たります。請求集計クエリはこの重複排除済みの台帳のみを合計するため、過剰計上は数学的に不可能です。

4. 順序外れ・欠損読み取りを伴う漏水アラートエンジン

検知ロジック

連続した漏水は、15分間隔が96回連続（24時間連続）で非ゼロの流量と定義され、interval_start によって厳密に判定されます。

ストリーム処理パイプライン

1. ウォーターマークと許容遅延: ストリーミングトポロジー（Apache Flink）は、メーターごとのキー付き状態を保持し、連続する間隔を追跡します。メーターは最大48時間までバッファできるため、ストリームジョブは48時間の許容遅延しきい値を設定します。遅れて到着した読み取りは破棄されず、キー付きのメーター状態へ再度振り分けられます。
2. 連続性ビットセット / 範囲木: 各メーターは、interval_start で並べられた最新の評価済み間隔を含む間隔状態構造を維持します。順序外れのバーストが到着すると、各間隔は時系列上の対応するスロットを埋めます。
3. 欠損間隔の扱い:
   • 間隔がパケット損失、クロックのずれ、または48時間のメーターバッファ上書き上限の超過により欠損した場合、それは不明/途切れた連続フローとして扱われます。
   • 仕様では確認済みの非ゼロ流量が 連続 96間隔であることが求められるため、欠損間隔は有効な連続記録をゼロにリセットします。エンジンは欠損データについて、流量があるともゼロ流量であるとも決して仮定しません。
4. 単一アラートの保証:
   • ステートマシンは streak_count と、ブール値のフラグ alert_emitted_for_current_streak を追跡します。
   • streak_count が96に達すると、エンジンは alert_emitted_for_current_streak が false かどうかを評価します。false の場合、漏水アラートを発行し、フラグを true に設定します。
   • その後の連続した非ゼロ間隔は streak_count を増加させますが、新たなアラートは抑制されます。ゼロの読み取り（または欠損間隔）によって連続が途切れた場合にのみ、streak_count がクリアされ、alert_emitted_for_current_streak が false にリセットされます。

5. アーキテクチャ上のトレードオフ

トレードオフ1: 取り込みの確認応答のタイミング

• 選択した方式: 生の読み取り値が分散メッセージキュー（Kafka）にコミットされた時点で、受信を確認応答します。
• 却下した方式: 長期の履歴データベースおよび請求テーブルへの書き込みがコミットされた後にのみ、受信を確認応答します。
• 根拠: 15,734 rpsの再接続ストームの最中に、エンドツーエンドの完全なACKを待つと、データベースのI/Oボトルネックに達するおそれがあります。応答がメーターの30秒タイムアウトを超えると、メーターは再試行し、取り込み負荷が指数関数的に増大します。キューレベルのACKは、ミリ秒単位での永続化を保証し、再試行を直ちに抑え込みます。

トレードオフ2: 漏水検知の計算アーキテクチャ

• 選択した方式: ステートフルなイベント時刻ストリーミング処理装置（RocksDB状態バックエンドを用いたApache Flink）。
• 却下した方式: 分析データベースのテーブルに対する定期的なバッチSQLクエリ（例: 15分ごとに実行）。
• 根拠: 順序外れの遅延到着を伴う数百万台のメーターに対するバッチSQLスキャンでは、ギャップと連続記録を再構築するために、数十億行にわたる数日分のスライディングウィンドウを照会する必要があります。ステートフルなストリームエンジンは到着時に逐次的にスライディング状態を評価するため、遅延を最小限に抑え、テーブルの反復スキャンを不要にします。

トレードオフ3: 顧客ダッシュボードのデータストレージ

• 選択した方式: 事前集計された読み取り最適化の時系列/NoSQLストア（例: Apache Cassandra / ScyllaDB）。
• 却下した方式: 正規化された請求リレーショナルデータベースに対するオンデマンドのクエリ。
• 根拠: ダッシュボードのクエリは高い読み取り同時実行性と緩やかな一貫性要件（バースト時には最大60分の遅延を許容）を示します。ダッシュボードの読み取りを請求ストアから切り離すことで、顧客のクエリの急増から金融取引を保護し、1日23GB以上での水平スケーリングをサポートします。

スマートメーター取り込みアーキテクチャ

1. 容量の見積もりと計算

120万台のスマートメーターに対応する堅牢なバックエンドを構築するため、まず決定的な容量とストレージの規模を算出します。

• 定常状態の毎秒読み取り数: 各メーターは15分ごと(900秒)に1件の読み取りデータを送信します。120万台の場合、平均取り込みレートは $1,200,000 / 900 = 1,333.33$ 件/秒です。
• 1日あたりの生データ量: 1,333.33件/秒では、1日の読み取り総数は $1,333.33 \times 86,400 = 115,200,000$ 件/日となります。通信上の各読み取りデータが200バイトである場合、1日の生データ量は $115,200,000 \times 200 \text{ bytes} = 23,040,000,000 \text{ bytes/day}$(すなわち23.04 GB/日)です。
• レプリケーションを含む保持期間全体の生ストレージ: データは3つのレプリカを持った状態で400日間保持する必要があります。総ストレージの計算は $23.04 \text{ GB/day} \times 400 \text{ days} \times 3 \text{ replicas} = 27,648 \text{ GB}$(すなわち27.64 TB)です。

2. 取り込み経路と再接続時のバースト規模の算出

大規模な嵐が発生すると、メーターの30%(360,000台)が6時間にわたって通信不能になります。6時間の間に、切断された各メーターは $6 \times 4 = 24$ 件の読み取りデータをバッファリングします。通信が復旧すると、360,000台すべてのメーターが、10分(600秒)のウィンドウに均等に分散させながら、バッファリングした24件の読み取りデータをアップロードします。

• バッファリングされたアップロードレート: バースト中の過去の読み取りデータのレートは、$(360,000 \text{ meters} \times 24 \text{ readings}) / 600 \text{ seconds} = 8,640,000 / 600 = 14,400$ 件/秒です。
• 同時のライブレート: 同時に、120万台すべてのメーターが $1,333.33$ 件/秒で通常のライブ読み取りデータの送信を継続します。
• ピーク取り込みレート: ピーク時の合計レートは $14,400 + 1,333.33 = 15,733.33$ 件/秒(約15.7k rps)です。

読み取りデータを一切失うことなくこの急増を吸収するため、取り込み層では、64パーティションに分割された水平スケーラブルな分散メッセージブローカー(Apache Kafkaなど)を使用します。ロードバランサーの背後にあるAPIゲートウェイ群がTLSを終端し、高速なスキーマ検証を行ったうえで、メッセージブローカーに直接書き込みます。Kafkaのパーティションが取り込みと下流処理を分離するため、急増はディスクバックアップされたコミットログに安全にバッファリングされます。コンシューマワーカーはコンシューマラグに基づいて動的にスケールし、データを失うことなく一時的な急増を処理します。

3. べき等性と正確に1回の課金

メーターは30秒以内に確認応答を受け取らないとアップロードを再試行するため、重複データは必ず到着します。課金が各 (meter_id, interval_start) を正確に1回だけカウントすることを保証するため、課金ストリームプロセッサ内でべき等性を適用します。

受信する各読み取りペイロードには、複合自然キーが含まれています。すなわち meter_id と interval_start です。課金ストリームプロセッサは、メッセージブローカーから読み取りデータを消費し、分散列指向データストア、または重複排除用の状態ストア(Apache Flinkに統合されたRocksDBなど)に対してアトミックなupsert操作を実行します。

読み取りデータが到着すると、プロセッサは (meter_id, interval_start) のレコードがすでに処理・課金済みかどうかを確認します。キーが存在する場合、重複ペイロードは安全に破棄されるか、重複としてマークされ、二重計上がゼロであることが保証されます。キーが存在しない場合、課金テーブルが更新され、確認応答が取り込みブローカーに返送されます。

4. 遅延到着データと漏水アラート

漏水検知では、メーターが(全24時間にわたる)連続する96の15分間隔のすべてで非ゼロの流量を示しているかどうかを特定する必要があり、到着時刻ではなく interval_start で厳密に評価します。バッファリングされた読み取りデータが遅延して順不同に到着しても漏水アラートが正しく保たれるよう、ウォーターマークを用いたイベント時間ストリーム処理を採用します。

• 遅延データの処理: ストリームプロセッサは、meter_id をキーとする状態ウィンドウを維持します。メーターは最大48時間データをバッファリングできるため、ストリーム処理ウィンドウは48時間の許容遅延しきい値で構成されます。これにより、遅延または再接続後のバッチアップロードが到着した際、それらのデータが interval_start のタイムスタンプに基づいて、正しい時系列の15分ビンに遡及的に割り当てられます。
• 欠損間隔: 15分間隔がストリームから完全に欠落し、そのデータを受信しないまま48時間の遅延ウィンドウが閉じた場合、その間隔はゼロ流量(または連続した連続性を断ち切る欠損データ)として明示的に扱われます。欠損した読み取りデータは非ゼロ流量の連続を途切れさせ、そのメーターの96間隔連続カウンタをリセットします。
• アラートの発報: メーターが96の連続した非ゼロ間隔を蓄積すると、システムは連続期間ごとに正確に1件のアラートを発報します。同じ連続した実行内の後続の非ゼロ読み取りデータは、アクティブな連続カウンタとともに保存される状態を持つ重複排除フラグにより、重複アラートを生成しません。

5. アーキテクチャ上のトレードオフ

システム設計を確定するため、3つの重要なアーキテクチャ上の選択肢を評価します。

1. 取り込みプロトコル: 採用案(TLS上のJSONを用いたHTTP/REST)対 不採用案(MQTT / カスタムTCPソケット). カスタムTCPソケットやMQTTはペイロードのオーバーヘッドが軽量ですが、HTTP/RESTとJSONはセルラーおよびIoTゲートウェイモジュールで広くサポートされており、デバッグが容易で、既存のAPI管理ファイアウォールとネイティブに統合され、専用のファームウェアプロトコルスタックを必要とせずに200バイトの通信サイズ要件を容易に満たせます。
2. ストレージのパラダイム: 採用案(コールドデータ用のオブジェクトストレージParquetファイル + ホットデータ用の分散ログ)対 不採用案(従来の分散リレーショナルSQLクラスタ)。 従来のリレーショナルデータベースクラスタで400日分の履歴時系列データと3つのレプリカを保持すると、法外なインフラコストと複雑な水平シャーディングの制約が生じます。圧縮された生の読み取りデータを、オブジェクトストレージ(例: AWS S3)上の列指向Parquetファイルに格納し、サーバーレスクエリエンジンで照会することで、アクティブな運用経路の高速性を維持しつつ、費用対効果の高い長期保持を実現します。
3. ダッシュボードの整合性: 採用案(読み取りモデルのプロジェクションによる結果整合性)対 不採用案(同期的なリードスルーのデータベース照会)。 大規模な再接続バースト(15.7k rps)の最中もダッシュボード照会の応答性を保証するため、通常の負荷時には5分以内に顧客ダッシュボードを更新する(嵐の期間中は60分まで緩和する)非同期の読み取りモデルプロジェクションを採用しました。同期的なリードスルー照会は、ピーク時の取り込みバースト中にプライマリのトランザクションストアをロックまたは照会すると、連鎖的なタイムアウト、データベース接続プールの枯渇、そして取り込み失敗の可能性を招くため、不採用としました。