Lunar Web Engineering

月面で、Webを
動かすということ。

光速、真空、宇宙線。
地球で当たり前だった3つの前提が崩れたとき、
私たちのコードは何を要求されるのか。

体感する →

Chapter 01

光は、間に合わない。

地球—月の片道 384,400 km。光速で往復しても 2.56 秒。
強一貫性(Raft / Paxos)はこの壁の前で凍りつきます。

$$RTT_{\min} = \frac{2L}{c}$$
$L = 3.844 \times 10^{8}\,\text{m}$、$c = 2.998 \times 10^{8}\,\text{m/s}$ を代入: $RTT \approx 2.56\,\text{s}$
Raft の確定までに最低3往復必要: $3 \times 2.56 = $ $7.68\,\text{s}$
起きること

「在庫を1個確保する」だけのボタンに 7.7秒 かかる。Web の体感閾値(2秒)を3倍以上超え、ユーザーは離脱する。 強一貫性(Strong Consistency)は仕様の問題ではなく、物理的に成立しない。

この章で試せる打ち手
  • 右のターミナルで Strong / Eventual を切り替え、体感レイテンシがどう変わるか観察する
  • 合意形成(Raft/Paxos)は 地球側のクラスタに閉じる。月面ノードは読み取りキャッシュ+書き込みプロキシに徹する
  • 書き込みは CRDT でローカル先行更新 → 地球と非同期 gossip。UI は楽観的更新で 0.02 秒に
  • TCP のタイムアウトは $\geq 5\,\text{s}$、HTTP リトライは指数バックオフで 3 回まで
checkout.minne.lunar

RTT: 2.56s / 往復1回あたりの待ち時間

Chapter 02

熱は、逃げない。

真空には対流も伝導もありません。
排熱はステファン=ボルツマンの放射のみ。冗長なループは融解への直行便です。

$$Q = \epsilon \sigma A (T^{4} - T_{0}^{4}) \quad \Longrightarrow \quad T = \left(\frac{P}{\epsilon \sigma A} + T_{0}^{4}\right)^{1/4}$$
放射率 $\epsilon = 0.9$、$\sigma = 5.67 \times 10^{-8}\,\text{W/m}^2\text{K}^4$、月夜の背景 $T_{0} = 120\,\text{K}$、放熱面積 $A = 2\,\text{m}^2$
消費電力 $P = 2{,}000\,\text{W}$ → $T \approx 374\,\text{K} \approx $ $101°\text{C}$
同じ負荷を $O(n^{2})$ で書くと処理量は $\times 200$ 倍に膨らみ → $T \approx $ $1{,}403°\text{C}$(シリコン融点 1414°C 寸前)
起きること

対流も伝導もない真空では、計算によって生まれた熱は 放射でしか逃げない。アルゴリズムの計算量はそのまま消費電力=発熱量として基板に積もり、シリコンの融点を超えれば機器は止まる。

この章で試せる打ち手
  • 右のスライダーで 処理量放熱面積を動かし、コアの色がどう変わるかを観察する
  • O(n) ↔ O(n²) を切り替えると、同じリクエスト数でも温度がどれほど跳ねるかが見える
  • 計算量を $O(n^{2}) \to O(n \log n)$ に落とすことを「冷却設計」として評価する。N+1 クエリ・空ループ・無駄な再レンダリングは即削除
  • 放熱面積 $A$ を物理的に拡大できないなら、TDP 上限ベースの動的スロットリングとジョブ優先度キューで負荷自体を平準化する
  • アイドル時は sleep ではなく halt。実行していなくても消費される電力をゼロに近づける
Core Temperature
Power Draw — W
200
6.0

Chapter 03

ビットは、勝手に反転する。

銀河宇宙線がメモリを撃ち抜きます。
「フラグが0→1に変わる」物理確率は、もう無視できません。

$$R(t) = e^{-\Gamma t}, \quad \Gamma = \lambda \cdot N_{\text{bits}}$$
月面でのSEU率はおおよそ $\lambda \approx 10^{-7}\,\text{errors/bit/day}$(地上の数百〜数千倍)
16 GB の RAM = $N = 1.28 \times 10^{11}\,\text{bits}$ → 1日あたり約 $1.28 \times 10^{4}$ 回のビット反転
そのうちの1ビットが「在庫数」「所有権フラグ」「課金額」の上位ビットに当たる確率は 毎日数十回オーダー
起きること

銀河宇宙線がメモリセルを撃ち抜き、ビットが勝手に反転する。エラーログには残らず、ドメインの所有者フラグや在庫数が 原因不明のまま書き換わる。地上ではほぼ無視できる事象が、月面では毎日数十回の規模で発生する。

この章で試せる打ち手
  • 右のスライダーで 宇宙線フラックスを上げ、Raw / Hamming / TMR の3列がどう壊れ・どう直るかを観察する
  • Hamming(7,4): 25% の冗長で 1 ビット訂正。Redis や K-V ストアのソフトウェアレイヤーに組み込む
  • TMR (3冗長 + 多数決): 200% の冗長だが「絶対に反転して欲しくない値」(所有権・課金・在庫)に限定して使う
  • 定期的な scrubbing(読み出し→訂正→書き戻し)でエラーの累積を防ぐ
  • 「全データを冗長化する」のではなく、反転した時の損害額で優先度を決めるのがコスト最適化の第一歩

Raw(無防備)

integrity: 100%

Hamming(7,4)

corrected: 0

TMR (×3)

recovered: 0

20