# べき等性 ## 定義 べき等性(idempotency)とは、同じ操作を複数回実行しても結果が一度の実行と変わらない性質。GPU カーネルの文脈では、再実行しても出力が変わらないカーネルを指し、フォールトトレラントなチェックポイント省略やプリエンプティブスケジューリングの前提として使われる。[[@2024__arXiv__Microsecond-scale Dynamic Validation of Idempotency for GPU Kernels]](PICKER)は、GPU カーネルが入力に応じてべき等インスタンスと非べき等インスタンスの両方を持ちうる「条件付きべき等(conditional idempotency)」を発見し、実アプリの 547 カーネル中 490 が条件付きべき等だと報告する。([[@2024__arXiv__Microsecond-scale Dynamic Validation of Idempotency for GPU Kernels]]) ## 横断的知見 - **「カーネルをべき等/非べき等に二分する」先行研究の前提が崩れる**: PICKER は条件付きべき等の広汎な存在(547 中 490)を示し、カーネル単位の静的二分がべき等ベースシステムの正しさ・効率を損なうと主張する。べき等性は静的属性でなく**インスタンス(起動引数)依存の動的属性**として扱う必要がある。(Source: [[@2024__arXiv__Microsecond-scale Dynamic Validation of Idempotency for GPU Kernels]]) - **べき等性は観測性ツールの上に成り立つ正しさ判定**: PICKER は GPU 動的計装(NVBit 系の SASS 解析)で全メモリアクセスを追跡してべき等性を検証する。[[GPU観測性]]・[[動的計装]]が性能診断だけでなく正しさ検証の基盤になる一例で、起動引数のみから実行前にマイクロ秒スケール(全インスタンス 5µs 以内)で判定する。(Source: [[@2024__arXiv__Microsecond-scale Dynamic Validation of Idempotency for GPU Kernels]]) - **手動コード規約によるべき等性確保の先例**: 1960年代の Apollo Guidance Computer は、動的計装のような自動検証手段を持たなかったため、非べき等な更新(`X = X+1` 型の逐次代入)がリスタートで二重実行されないよう、開発者が「waypoint」を手作業でコードの前後に配置する規約でべき等性を確保していた(→ [[リスタート保護]])。PICKER のような自動・動的な条件付きべき等判定が存在しない環境では、べき等性は静的コード規約(人間による設計)として実現するほかなく、これは動的検証(PICKER)と静的規約(Apollo)というべき等性確保の二つの極を示す。(Source: [[@2004__AAS__Tales from the Lunar Module Guidance Computer]]) - **「べき等性を要求する」設計と「べき等性を検証する」設計という2つの対応方針**: GPU カーネル(PICKER)と Apollo Guidance Computer の事例は、いずれも「実行主体(カーネル・コード)自体がべき等かどうかを判定・確保する」問題を扱う。対して [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 5 Encoding and Evolution]] が論じる分散システムの RPC 再送・[[Durable Execution]] の文脈では、呼び出し先(外部サービス・決済ゲートウェイ等)のべき等性は所与ではなく、**呼び出し元が一意な ID を付与して呼び出し先にべき等性の実装を要求する**という運用契約(idempotency key)によって実現される。前者2件は「対象を検証・判定する」アプローチ、DDIA の事例は「対象にべき等性の実装を要求する」アプローチであり、べき等性の確保責任がどちらの当事者にあるかで設計の重心が変わることを示す。(Source: [[@2024__arXiv__Microsecond-scale Dynamic Validation of Idempotency for GPU Kernels]], [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 5 Encoding and Evolution]]) - **べき等性が必要になる理由も「再実行」の意味も領域で異なる**: GPU カーネルはプリエンプティブスケジューリングでの再実行、Apollo はリスタート時の再実行、DDIA の RPC/Durable Execution はネットワーク再送(応答ロスト時の重複呼び出し)とワークフロー再実行時のリプレイという、3つの異なる「再実行」トリガーに対してべき等性が要求される。いずれも「同じ操作の複数回実行が一度の実行と区別できない」という定義自体は共通するが、べき等性が守るべき境界(メモリ状態 / レジスタ・変数 / 外部サービスの副作用)は領域ごとに異なる。(Source: [[@2024__arXiv__Microsecond-scale Dynamic Validation of Idempotency for GPU Kernels]], [[@2004__AAS__Tales from the Lunar Module Guidance Computer]], [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 5 Encoding and Evolution]]) - **同一書籍内で「べき等性で分散トランザクションを代替する」という設計判断が繰り返される**: DDIA 第5章は RPC 再送の重複排除としてべき等性キーを紹介したが、第8章「Exactly-Once Message Processing Revisited」はこれをさらに具体化し、メッセージブローカーとデータベースにまたがる分散トランザクション(2PC)なしで厳密に一度だけの処理を実現する手段として提示する。手順は「メッセージ ID を処理済みテーブルに記録 → 同一トランザクション内でメッセージ処理の書き込みも行う → コミット後にブローカーへ確認応答 → 確認後に ID を削除」の 4 段階で、ユニーク制約が同時リトライでの二重挿入を防ぐ。この設計は「べき等性は外部サービス側に実装を要求するもの」という第5章での位置づけ(→ 既存の横断的知見)を一歩進め、**べき等性の実装責任を呼び出し元(データベーストランザクション内の重複検出)に引き取ることで、分散トランザクションという座標コストの高い仕組み自体を不要にする**という、コスト回避の具体的な設計パターンを示す。(Source: [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 8 Transactions]] "Exactly-Once Message Processing Revisited", [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 5 Encoding and Evolution]] "The problems with remote procedure calls") - **同一書籍内で「メッセージ ID による重複排除」が、外部データベース書き込みという第3の適用先へ具体化される**: 第5章はRPC再送の重複排除、第8章はメッセージブローカーとデータベースにまたがる分散トランザクション代替として、それぞれ一意なIDによるべき等性キーを論じた(→ 既存の横断的知見)。[[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 12 Stream Processing]] "Idempotence" 節はこれをストリーム処理の文脈へさらに具体化し、Kafka の各メッセージが持つ永続的で単調増加するオフセットを外部データベースへの書き込みに添えることで、そのオフセットに対応する更新が既に適用済みかを判別し二重適用を避ける手法を示す。第8章のメッセージIDテーブル方式(処理済みIDをデータベーストランザクション内で記録・削除)と本質的に同じ発想だが、第12章はさらに前提条件を明示的に列挙する——(1)失敗タスクの再起動が同じメッセージを同じ順序で再生すること(ログベースメッセージブローカはこれを満たす)、(2)処理が決定的であること、(3)他ノードが同じ値を並行更新しないこと——であり、これらはいずれもストリーム処理特有の分散実行環境で成立を要求される制約として、RPC 再送(第5章)より厳しい。ノード切り替え時にはフェンシング(→ [[分散ロックとリース]])も要求される。(Source: [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 12 Stream Processing]] "Idempotence", [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 8 Transactions]] "Exactly-Once Message Processing Revisited") - **第13章は、第5・8・12章が個別に導入してきた「一意なIDによる重複排除」を、TCP・データベーストランザクション単体では実現できないという一般原理(エンドツーエンド論)のもとに統合する**: 第5章(RPC再送)・第8章(メッセージブローカー×データベース間)・第12章(Kafkaオフセット×外部データベース)は、いずれも異なる技術的文脈で「一意なIDを添えて重複を判別する」という同型のパターンを個別に導入してきた。[[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 13 A Philosophy of Streaming Systems]] "Uniquely identifying requests" はこれをさらに一段上流(エンドユーザーのブラウザからのHTTP POSTリクエスト)へ拡張し、`request_id` にユニーク制約を張ったテーブルへ`INSERT`することで重複トランザクションを`INSERT`失敗として機械的に弾く実装(Example 13-2)を示した上で、「TCPの重複抑制・データベーストランザクション・ストリームプロセッサのexactly-onceセマンティクスのいずれも単体では、クライアントとサーバの間のネットワークで生じる重複を防げない」という[[エンドツーエンド論]]の帰結として位置づけ直す。すなわち第5・8・12章が積み上げてきた具体的な実装パターンは、第13章によって「なぜこの設計でなければならないか」という理論的根拠を事後的に与えられたことになる。(Source: [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 8 Transactions]] "Exactly-Once Message Processing Revisited", [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 13 A Philosophy of Streaming Systems]] "Uniquely identifying requests", "The end-to-end argument") - **『詳説 データベース』第8章は、DDIAが応用レイヤー(RPC・メッセージブローカー・ストリーム処理)で扱う一意ID方式より一段下のリンク層で、同じ「重複への対処」問題をシーケンス番号によって解いている**: DDIA各章(第5・8・12・13章)はいずれもアプリケーション層(RPC再送・メッセージブローカー・Kafkaオフセット・HTTPリクエスト)での重複排除を扱うのに対し、Database Internals第8章§8.3.1.4〜§8.3.1.5は、より低レイヤーの通信リンク抽象化(フェアロスリンク→パーフェクトリンク)の文脈でべき等性を導入する。再送によってメッセージが重複しうるという問題は共通だが、Database Internalsは単調増加するシーケンス番号による`n_consecutive`/`n_processed`の追跡で重複排除を実装するのに対し、DDIAの各章はアプリケーション固有の一意ID(idempotency key・メッセージID・Kafkaオフセット・request_id)を使う。両者は「一意な連番/IDで重複を判別する」という同型のパターンをリンク層とアプリケーション層それぞれで独立に採用しており、この設計パターンがネットワークスタックの複数の抽象化レイヤーに渡って繰り返し出現することを示す。またDatabase Internals第8章は「すべての操作が冪等であったら…完全に消極的な方法でシステムを構築することになる」と述べ、[[エンドツーエンド論]]が主張する「単体のレイヤーだけでは重複を防げない」という帰結を、リンク層の側から補強する具体例にもなる。(Source: [[@2021__OReillyJapan__詳説 データベース - Chapter 8 基本事項の紹介と概要]] §8.3.1.4, §8.3.1.5, [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 13 A Philosophy of Streaming Systems]] "The end-to-end argument") - **cfengine の収束的意味論は、「べき等性を検証する」「べき等性を要求する」に続く第3の実現方針——「言語設計そのものでべき等性を保証する」——を示す先行例である**: 既存の横断的知見は、べき等性の確保方針を「対象を検証・判定する」(PICKER の動的計装、Apollo の手動コード規約)と「対象にべき等性の実装を要求する」(DDIA の idempotency key、呼び出し元が一意な ID で重複排除を契約として求める)の2つに整理してきた。*Principles of Network and System Administration* 第7章§7.4・§7.11が記述する cfengine は、これらとは異なる第3の方針を取る——宣言的言語(cfengine)で「最終状態(理想状態)だけ」を記述させ、言語自身の実行系が毎回の実行時に「差分がなければ何もしない」という冪等な収束操作を自動的に行うため、個々の設定記述者がべき等性を意識してコードを書く必要も、外部から検証する必要もない。べき等性は個々の操作の性質としてではなく、**言語処理系のアーキテクチャそのものに組み込まれた不変な性質**として実現される。1990年代の設定管理ツールが、2000年代以降の GPU カーネル動的検証や分散システムの idempotency key 契約に先立ち、「言語設計によるべき等性の保証」という設計思想に到達していたことは、べき等性確保の方針が特定の時代・領域に限られないことを示す。(Source: [[@2004__Wiley__Principles of Network and System Administration - Chapter 7 Configuration and maintenance]] §7.4, §7.11) - **SRE Book 第24章の分散cronは、「対象を検証する」「対象に実装を要求する」「言語設計で保証する」という既存の3方針のいずれとも異なる第4の方針——「操作自体をべき等にできないなら、外部状態を曖昧さなく照会できるようにして、べき等性の要件自体を回避する」——を示す**: 本ページはこれまで、べき等性の確保責任を「検証する側」(PICKER・Apollo)、「要求する側」(DDIA の idempotency key)、「言語処理系」(cfengine)のいずれかに置く3つの方針を蓄積してきた。[[@2016__OReilly__SRE Book - Chapter 24 Distributed Periodic Scheduling with Cron]]が扱う分散cronは、給与計算やニュースレター配信のようにそもそも操作自体をべき等にできないジョブを前提とし、「(1) 継続する外部操作の全てがべき等であること、または (2) 外部システム上の全操作の状態を曖昧さなく照会できること、のいずれかを満たす」という要件をOR条件で提示する。具体的には、Borg上のジョブ名をミューテーションなしに事前計算し全レプリカへ配布しておくことで、リーダー再選出後に新リーダーは名前の状態を照会するだけで再開でき、操作自体のべき等性は一切要求されない。これは、DDIAのidempotency key(呼び出し先にべき等性の実装を要求する)とは異なり、**呼び出し先の状態を外部から観測可能にすることで、べき等性という性質そのものを不要にする**という第4の設計軸である。(Source: [[@2016__OReilly__SRE Book - Chapter 24 Distributed Periodic Scheduling with Cron]], [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 5 Encoding and Evolution]]) - **本ページが記録する「べき等性が要求される理由(再実行のトリガー)は領域で異なる」というリストに、分散cronは「リーダーフェイルオーバー後の引き継ぎ」という5つ目のトリガーを追加する**: GPUカーネルのプリエンプション・Apolloのリスタート・RPC再送・ワークフロー再生に続き、SRE Book第24章は「分散合意システムのリーダーが交代したとき、新リーダーが前リーダーの未完了作業(オープンな起動)を引き継ぐ」という固有のトリガーを示す。この引き継ぎは[[分散コンセンサス]]のリーダー選出プロトコルと直結しており、他の4つのトリガー(単一プロセス内の再実行、あるいはネットワーク境界をまたぐ再送)とは異なり、**合意システム自体の可用性メカニズム(フェイルオーバー)がべき等性要求の発生源になる**という点で新しい。またこの章は「二重起動よりスキップを優先する(fail closed)」という明示的な設計方針を示しており、べき等性を確保できない場合の次善策として「起動しない」ことを選ぶという、本ページがこれまで記録してこなかった第3の選択肢(べき等性の確保でも検証でもなく、実行そのものを控える)を提示する。(Source: [[@2016__OReilly__SRE Book - Chapter 24 Distributed Periodic Scheduling with Cron]], [[@2024__arXiv__Microsecond-scale Dynamic Validation of Idempotency for GPU Kernels]], [[@2004__AAS__Tales from the Lunar Module Guidance Computer]], [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 5 Encoding and Evolution]]) - **ネットワーク機器の config 適用は、cfengine の「言語処理系が収束を保証する」方針とも DDIA の「呼び出し先に idempotency key を要求する」方針とも異なる、運用者側が明示的な diff-dry run-apply パイプラインを組み立てる第5の方針を示す**: [[SAKURA internet Inc]]の[[SONiC]]運用事例([[@2025__SpeakerDeck__SONiCで構築・運用する生成AI向けパブリッククラウドネットワーク]])では、当初 Before として shell script による config command と config replace を併用し、新規コンフィグ投入のたびに Container 再生成が発生して冪等性 0・通信断を招いていた。After では新規コンフィグを既存設定と jsondiff で突き合わせて差分ファイルを生成し、Dry run(apply patch を frr-reload まで通す構文チェック)を経てから Apply する 3 段構成へ切り替え、Container 再生成なしに設定を反映できるようにした。これは cfengine のように言語処理系が自動で「差分がなければ何もしない」収束操作を行うのではなく、**運用者が明示的に diff 生成・検証・適用の 3 ステージへ操作を分解することでべき等性を作り出す**点で異なる。またこの分解自体が SONiC の YANG スキーマ未整備という制約(RDMA 設定の apply patch 失敗・CPU 100% 化)への対処を兼ねており、べき等性の実現とハードウェア依存の構成管理課題の解決が同じ自動化ツール刷新の中で不可分に結びついている。(Source: [[@2025__SpeakerDeck__SONiCで構築・運用する生成AI向けパブリッククラウドネットワーク]] p.21-22, [[@2004__Wiley__Principles of Network and System Administration - Chapter 7 Configuration and maintenance]] §7.4, §7.11) - **同一発表者の続編資料は、config冪等性パイプラインを単体テストの試作段階から本番Clos環境のCI組み込みへと一段進める**: 前項(SONiC Workshop Japan 2025)のjsondiff→Dry run→Applyパイプラインは、単一クラスタでのconfig冪等性確保にとどまっていた。同一発表者による続編([[@2026__JANOG57__HPCネットワークの多様化に挑む - マルチベンダー×マルチOSで支えるHPCネットワーク運用の実際]] p.24-26)は、これをさくらONEの本番Clos Topology環境(スイッチ38台)に適用し、Ansibleによる約40,000行のconfig自動生成(全台セットアップ30分)と、GitHub PR起点でcEOS Container(containerlab)へのDry-run&Applyを5分で回すCIパイプラインへと統合した。個々のconfig適用操作がべき等であることに加え、「変更のたびに自動でテストする」というワークフロー自体をCIに組み込むことで、べき等性の確保(操作の性質)と検証の自動化(運用プロセス)が一体化した実例になる。これはp.83の既存知見が示した「第5の方針」(運用者が明示的にdiff-dry run-applyパイプラインを組み立てる)が、単発の運用改善ではなく継続的なCIとして定着した後続事例である。(Source: [[@2026__JANOG57__HPCネットワークの多様化に挑む - マルチベンダー×マルチOSで支えるHPCネットワーク運用の実際]] p.20, p.24-26, [[@2025__SpeakerDeck__SONiCで構築・運用する生成AI向けパブリッククラウドネットワーク]] p.21-22) - [[@1998__LISA__Bootstrapping an Infrastructure]] のHostkeeperは、makeをステートエンジンとして使い、各パッチスタンザ末尾の`touch`コマンドでスタンプファイルを作ることで同一パッチの再適用を防ぐ、cfengine以前のmake流用による冪等パッチ適用の具体例を示す(Source: [[@1998__LISA__Bootstrapping an Infrastructure]]) - **べき等性の確保が「簡潔さとのトレードオフ」として明示的に忌避される事例**: 本ページはこれまで、べき等性を確保する方針(検証・要求・言語処理系への組み込み・状態照会による回避・明示的パイプライン)を蓄積してきたが、いずれも「べき等性を確保すること自体は望ましい」という前提を共有していた。[[@2003__LISA__ISconf - Theory, Practice, and Beyond]](Luke Kanies, LISA 2003)は、[[cfengine]] とは対照的に make をエンジンとする ISconf の stanza(コマンド列)について、途中で失敗すると部分的に適用された変更が残り人手による復旧が必要になる(atomicity の欠如)ことを認めつつ、「stanza をべき等に書くことでこの問題を緩和できるが、それは ISconf が提供する簡潔さを損なう」と述べ、べき等性の確保を意図的に見送っている。これは、cfengine が「言語処理系そのものでべき等性を保証する」設計(既存の横断的知見)を取ったのとは対照的に、ISconf は「べき等性はアトミック性の代替になりうるが、簡潔さとのトレードオフゆえに要求しない」という、べき等性を積極的に回避する第6の立場を示す。(Source: [[@2003__LISA__ISconf - Theory, Practice, and Beyond]]) - [収束的エージェントの4条件] Couch, Hart, Idhaw, Kallas の「クロージャ」理論(LISA 2003)は、Cfengine由来の収束性(convergent)に加え、一貫性(consistent: 他エージェントの変更を元に戻さない)・気づき(aware: 変更失敗を検知できる)・原子性(atomic: 失敗時は完全に無変更)の3条件を明示的な公理(Axiom 1)として要求し、単なる「収束すること」と「エージェント集合として安全に組み合わせられること」を区別した。(Source: [[@2003__LISA__Seeking Closure in an Open World - A Behavioral Agent Approach to Configuration Management]]) ## 未解決の問い - cfengine のような「言語設計によるべき等性の保証」は、宣言的 IaC ツール(Terraform・Ansible)の reconciliation ループでどこまで踏襲されているか。DDIA の idempotency key(要求方針)と cfengine の言語内蔵方式(設計方針)は、現代の IaC ツールでは併用されているのか、どちらか一方に収斂しているのか。SONiC の diff-dry run-apply パイプラインは、この問いに対する「収斂していない」側の実例(明示的パイプラインで代替する)と見なせるか。 - 条件付きべき等という入力依存の判定を、LLM 訓練のような巨大カーネル群でも µs スケールで成立させられるか([[耐障害LLM訓練]]のチェックポイント削減と直結)。 - 決定的実行を要する正しさ判定(PICKER の SASS 解析)を、クローズドソース/動的生成カーネルへどこまで一般化できるか。 - べき等性に基づく省略([[チェックポイント]]不要・プリエンプション高速化)を、訓練系の周期チェックポイントと組み合わせられるか。 - DDIA が言う「一意な ID による重複実行防止」(idempotency key)は、PICKER のような動的検証と組み合わせて、外部サービス呼び出しのべき等性を実行前に自動判定する方向へ拡張できるか。 - 第8章のメッセージ ID テーブル方式(処理済み ID の記録・削除)は、GPU カーネルの条件付きべき等判定(PICKER)のようなインスタンス単位の動的検証と比べ、判定コストという点でどちらが軽量か。前者は O(1) のテーブル照合、後者はマイクロ秒スケールの SASS 解析であり、コスト構造の異なる 2 つのべき等性検証アプローチとして比較する価値があるか。 - 第13章のend-to-end論に照らすと、GPUカーネル(PICKER)・Apollo Guidance Computerの事例は「単一コンポーネント内の再実行」を扱うのに対し、DDIAの事例は「複数のネットワーク境界をまたぐ再実行」を扱っており、後者だけがエンドツーエンド論の対象になる。この境界の違いは、べき等性確保の設計思想(検証 対 要求)の違いとどこまで対応しているか、体系的に整理する価値がある。 - Database Internals第8章のリンク層シーケンス番号方式と、DDIA各章のアプリケーション層一意ID方式は、どちらも「重複を判別する」という同型のパターンだが、実装コスト・保持期間・障害時の状態復元のしやすさという点でどちらが有利かは本ページではまだ比較できていない。TCPの実装(両者の中間に位置する)を参照点に、レイヤーごとのコスト構造を整理する価値があるか。 - 分散cronの「事前計算した名前で外部状態を照会する」方式(第4の方針: べき等性要件の回避)は、DDIAのidempotency key方式(要求)やPICKERの動的検証方式(検証)と比べて、実装コスト・適用範囲(名前による一意照会が可能なインフラに限られるか)の面でどう位置づけられるか。名前による状態照会という手段自体が、実質的には「idempotency keyによる重複排除」の変種(名前をキーとして使っている)と見なせるのか、それとも別カテゴリなのかは本ページではまだ整理できていない。 ## 関連 - ソース: [[@2024__arXiv__Microsecond-scale Dynamic Validation of Idempotency for GPU Kernels]] / [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 5 Encoding and Evolution]] / [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 8 Transactions]] / [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 12 Stream Processing]] / [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 13 A Philosophy of Streaming Systems]] / [[@2021__OReillyJapan__詳説 データベース - Chapter 8 基本事項の紹介と概要]] / [[@2004__Wiley__Principles of Network and System Administration - Chapter 7 Configuration and maintenance]] / [[@2016__OReilly__SRE Book - Chapter 24 Distributed Periodic Scheduling with Cron]] / [[@2025__SpeakerDeck__SONiCで構築・運用する生成AI向けパブリッククラウドネットワーク]] / [[@1998__LISA__Bootstrapping an Infrastructure]] / [[@2003__LISA__Seeking Closure in an Open World - A Behavioral Agent Approach to Configuration Management]] / [[@2003__LISA__ISconf - Theory, Practice, and Beyond]] - 概念: [[チェックポイント]] / [[耐障害LLM訓練]] / [[GPU観測性]] / [[動的計装]] / [[Durable Execution]] / [[分散トランザクション]] / [[ストリーム処理の耐障害性]] / [[エンドツーエンド論]] / [[収束型システム管理]] / [[分散cron]] / [[分散コンセンサス]] - エンティティ: [[PICKER]] / [[Asymmetric Resilience]] / [[Chimera]] / [[NVBit]] / [[Temporal]] / [[Apache Kafka]] / [[cfengine]] / [[Borg]] / [[Štěpán Davidovič]] / [[SONiC]] / [[SAKURA internet Inc]] / [[黒澤潔裕]] / [[SAKURAONE]] / [[Luke Kanies]] - 関連 MOC: [[AI Infra Telemetry - MOC]] ## 出典 - [[@2026__JANOG57__HPCネットワークの多様化に挑む - マルチベンダー×マルチOSで支えるHPCネットワーク運用の実際]](jsondiff→Dry run→ApplyパイプラインのCI統合、Ansible約40,000行config自動生成、containerlabによる5分CI) - [[@2024__arXiv__Microsecond-scale Dynamic Validation of Idempotency for GPU Kernels]](条件付きべき等の発見・インスタンス単位動的検証・5µs・偽陽性 0/偽陰性 18.54%) - [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 5 Encoding and Evolution]]("The problems with remote procedure calls", "Durable Execution and Workflows") - [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 8 Transactions]]("Exactly-Once Message Processing Revisited" — メッセージ ID テーブルによる分散トランザクション代替) - [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 12 Stream Processing]]("Idempotence" — Kafka オフセットによる外部データベース書き込みの重複排除) - [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 13 A Philosophy of Streaming Systems]]("Uniquely identifying requests", "The end-to-end argument" — エンドツーエンド論としての一般化) - Alex Petrov, *詳説 データベース*, オライリー・ジャパン, 2021, 8章, §8.3.1.4「再送の問題」, §8.3.1.5「メッセージの順序」. - Mark Burgess, *Principles of Network and System Administration*, Second Edition, John Wiley & Sons, 2004, Chapter 7, §7.4, §7.11(宣言的言語の設計によるべき等性の保証)。 - Betsy Beyer, Chris Jones, Jennifer Petoff, Niall Richard Murphy (eds.), *Site Reliability Engineering: How Google Runs Production Systems*, O'Reilly, 2016, Chapter 24(ジョブ名の事前計算による状態照会・fail closedのスキップ優先方針・リーダーフェイルオーバー引き継ぎ)。 - [[@2025__SpeakerDeck__SONiCで構築・運用する生成AI向けパブリッククラウドネットワーク]](jsondiff差分生成→dry run→applyの3段パイプラインによるSONiC config冪等性の実現) - [[@1998__LISA__Bootstrapping an Infrastructure]](makeのtouchスタンプファイルによる冪等パッチ適用、cfengine以前の実装例) - [[@2003__LISA__ISconf - Theory, Practice, and Beyond]](Luke Kanies, USENIX LISA 2003。ISconf stanza のべき等化を「簡潔さとのトレードオフ」として意図的に見送る立場)