Nosdesk 技術的基盤と設計思想：Rust で築いた堅牢性の証言

掲載日: 2026 年 5 月 28 日

プロジェクトの現状

当初は数ファイルに過ぎなかったプロジェクトは、約一年間の開発を経て以下の規模へと成長しました。

• コード行数: 約 12 万行（Rust）
• モジュール数: 約 260 モジュール
• テスト数: 約 1,030 テスト
• 起動方法:

  docker compose up

  の一条令で、単一のバイナリとして配布
• 技術スタック:
  • Web フレームワーク: Actix-web（最上層）
  • データベース: Postgres + Diesel
  • プッシュ型ファンの配信: Redis
  • アシンクロ環境: Tokio

3 つの鉄則と設計哲学

このプロジェクトを通じて定着した習慣がすべてに共通しています。

1. 型システムへのミス転嫁
   • 「間違えないように促す」のではなく、「間違いがあればコンパイルすら通らない」ようにする。
2. ロジックと I/O の分離
   • 純粋なロジックと付随する I/O を分離することで、データベースやソケットを用意せずとも独立してテスト可能な関数として実装を分割できる。
3. 「なぜ（Why）」の記述
   • コメントで「何をするか」ではなく「なぜそうするか」を書く。
   • その理由、守るべき RFC、そしてバグから得た教訓を記述する。

データ同期のアーキテクチャ：すべてはパイプラインである

クライアント接続時のブートストラップ同期において、大量データを一度に読み込むとメモリスプライクが発生するため、ストリーム処理を採用しています。

• NDJSON 形式: 行を改行区切り JSON にシリアライズし、

  mpsc::channel(64)

  を通してプッシュする。
  • バックプレッシャーを活用し、読み込み側が遅くてもプロデューサーから溢れるのを防ぎます。
• 非同期処理:

  Diesel

  （同期）クエリを

  spawn_blocking

  で実行し、結果を

  ReceiverStream

  経由で返します。
• トランザクション保証: スナップショット全体を一つのトランザクション内で完結させ、クライアントは一貫した時点のビューを取得できます。

この「プロデューサーが消費者を上回る速度でも動けるパイプライン」視点は、コード全体に適用されています。

リアルタイム同期：Postgres を押し出すように教える

同期エンジンは**追加専用ログ（Append-only Log）**であり、

sync_actions

1. クライアント向けの HTTP デルタ同期
2. 接続中クライアント向けのリアルタイムプッシュチャネル
3. 監査証跡

リアルタイムプッシュの実装工夫

Postgres の

LISTEN/NOTIFY

tokio-postgres

• ポーリング API をストリーム化:

  let mut messages = stream::poll_fn(move |cx| conn.poll_message(cx));
  

  これにより、コールバック型の C スタイル API から

  async/await

  を橋渡ししています。
• 意図的なパヨロード（負荷）を持たせない:
  • 通知にペイロード（行 ID など）を含めず、「ウォータマーク以降の全データを受け取る」というシンプルなウェイクアップのみで行います。
  • ライサーは

    WHERE sync_id > last_seen

    でデータを取得し、失敗モードの蓄積を防ぎます。
  • 並発書き下でも正しく動作するアプローチです。ペイロードを信頼してフェッチすると、同一ウィンドウ内のコミット行を見逃すサイレントバグに陥ります。

接続維持と再プレイ：ライブレイヤー

Server-Sent Events (SSE) を使用し、接続一時停止時のギャップ埋め（Backfill）を可能にしています。

• トピック管理: ライブテール（

  tokio::sync::broadcast

  ）と、最近イベント用のリングバッファをペアづきます。
• クライアントごとのストリーム処理:
  • 購読トピックのマージ
  • 再プレイバッファのドレインおよび重複排除
  • 接続切断防止のための 15 秒間隔ハートビート挿入
  • 遅延クライアントの閉鎖（他の消費者への影響防止）
• 自動破棄:

  Drop

  実装により、登録取り消しが自動的に実行され、手動破棄のミスを防ぎます。

意図的な並行性設計

コンパイルエラーやデッドロックを防ぐために、以下のような厳格な依存関係を構築しています。

• DashMap

  : 遅くポップアップされるトピックマップ用

• tokio::broadcast

  : ファンアウト機能およびバグ検出用
• 有界 MPSC: バックプレッシャーが必要な部分用
• ロッキング戦略:

  await

  クロスしない場合は

  std::sync::RwLock

  、クロスする場合は

  tokio::sync::RwLock

  を使い分ける
• シーケンストータル:

  AtomicU64

外部ライブラリの安全性：ライブラリがパニックする時

Yjs の Rust ポート（yrs）による CRDT 共同編集機能を実装する際、以下の 2 つの設計判断を採っています。

1. 安定した ID 管理

• サーバー側で

  DocumentID

  のハッシュから決定論的にクライアント ID を導出し、53 ビットにマスキングします。
• 効果: バックエンド再起動時にも「新しい参加者」として認識されず、幻覚的な不一致（ファントム・ダイバージェンス）を防ぎます。

2. パニックの封じ込め

• yrs

  が不健全な UTF-8 を検出するとパニックするため、すべての呼び出しを

  catch_unwind

  で囲みます。

  fn safe_get_fragment_string(fragment: &XmlFragment, txn: &Transaction) -> Option<String> {
      catch_unwind(AssertUnwindSafe(|| fragment.get_string(txn))).ok()
  }
  

• 予期せぬパニックを接続全体に波及させず、呼び出し元のみで処理を止めます。

クラッシュ耐性：不幸なパスのための耐久型設計

メールサブシステム（約 14,000 行）は、「幸せなパス」ではなく「不幸なパス（エラーハンドリング）」のために構築されています。

• シルクトブレーカー:
  • ローリングウィンドウベースの失敗検知。
  • プロバイダーが失敗し始めるとブレーカーが開き、攻撃を停止します。
  • 追加のタスクなしで状態遷移（ハーフオープン）を実現しています。
• フル・ジッター（全乱数）バックオフ:
  • AWS Builders' Library の式を純粋関数として実装。
  • オーバーフロー処理を含み、99 回試行してもパニックしないことが保証されています。
• 理論上「少なくとも一度」の配信:
  • FOR UPDATE SKIP LOCKED クエリでバッチ化し、5 分のリース期間を設定。
  • ワーカーが死亡してもリース切れで再試行可能。
  • 送信途中で死亡しても

    Message-ID

    で重複削除をサーバー側で行うため、二度送りを許容しつつ確実に配信します。

アクター方式の監督システム

• 登録レジストリは長寿タスクが所有し、HTTP ハンドラーは共有マップではなくチャンネルを通じてコマンドを送ります。
• パニックしたワーカーはログに記録され停止され、無限ループへの再起動は行われません（バグとして扱います）。

間違えないように不可能にする：型システムとアクセス制御

Nosdesk はマルチテナントシステムであり、以下の厳格な制約を設けています。

• クエリのスコープ強制:
  • ハンドラーには生の DB コネクションを与えず、以下の extractor のいずれかを使用させます。

  1. TenantConn

     : Row-Level Security (RLS) を自動的にワークスペースコンテキストでフィルタリングします。

  2. PlatformConn

     : クロステナント操作のため特別ロールへ昇格するもの（稀）。
• 型による宣言:

  • PlatformConn

    を取ることで「テナント境界を超えている」と型シグネチャで宣言し、レビュー時に可視化されます。
• プラグインシステムのセキュリティ:
  • 署名されたサードパーティコードのみを実行します。

  • InstallToken

    （Ed25519）を必要とし、検証済みモジュール内のみの構築を強制しています。
  • Allowlist ループが存在せず、型システム自体がチェック回避を不可能にします。

攻撃耐性のための微小構造防衛

コードベース全体にパラノイアを増す順序で以下の防御策を実装しています。

• SSRF 安全なアウトバウンド HTTP:
  • カスタム DNS リゾルバーを埋め込み、アドレスフィルタリングを行います。
  • 非ルーティング範囲の列挙や IPv4-mapped-IPv6 のトリック対策を含みます。
• 等価作業によるログイン防御:
  • 存在しないメール、SSO アカウントなど、全ての失敗パスをダミーハッシュに対する bcrypt 検証に集約します。
  • プリウォームにより、最初の実行でも一回限りのコストで済みます。
• ドメイン分離付き暗号化:

  • ring

    を介した AES-256-GCM で、コンテキスト文字を認証タグにバインドします。
  • 同一マスターキーでも用途ごとに封じ込め、出力時にバッファをゼロクリアします。

テスト戦略：現実を見守り、再検証する

約 1,030 のテストは、コードが間違えやすい箇所に集約されています。

• 対象: マニフェスト検証、IMAP パース、メールスレッド化など。純粋関数として、DB やソケットなしで実行可能です。
• 意図的ではないもの: DB 呼び出しのスタックなどはマスキが機能するかしか証明しないため、カバー率は薄く保ちます。

特に重視する二つのテストスイート

1. データベーステスト: トランザクション内でロールバックし、残滓を残さず並列実行します。
2. Lint-as-tests:
   • テストがリポジトリを巡回し、書き込み関数が同步イベントを発行するか確認します。
   • マーカーがない場合、ビルド自体を失敗させます。

v1 リリースに向けた課題

v1 に向けて以下の点に注意が必要です。

• モノリシックな構造:

  main.rs

  は約 1,900 行の巨大ファイルですが、機能動作は保たれています（将来的に分離する計画あり）。
• グレースフルシャットダウン: スキャフォールドはあるがワイヤリング未完成。シグナルハンドラー未実装で、デプロイ時に強制停止となることがあります。
• unsafe コード: 検索サービス内の

  unsafe impl Send/Sync

  は信頼性が低く、将来的に危険なフィールドを隠蔽するリスクがあります。
• エラー型: プラグインプロキシとメールワーカーの SMTP コード処理が文字列型エラーにフォールバックしており、ここはクリーンタイピングが緩んでいます（v1 で改善予定）。

結論：遅くても正しく構築する

Rust の徹底した精度が設計を支え、コンパイラがこの規模のバックエンドを正直に構築できる唯一の理由です。

• 時間配分: 「失敗クラスを再現不可能にするための努力を上流に費やすこと」よりも、「後でデバッグするための時間を使うこと」を好みます。
• 設計思想: コンパイラが強制してくれる方法で成果を得る一方で、一年間の取り組みは容易な道では耐えられない場所でもシステムを持続させる方法を教えました。
• 価値観: 肥大化して忘れられるものを出すよりも、自分が守りたいものを作るのに時間をかけるほうが好きです。

ソースコードは読むために公開されています。