サービス間通信でVPN（仮想プライベートネットワークで拠点間を暗号化接続する仕組み）や中央ブローカーの運用負荷に悩んでいるインフラ担当者、あるいはマイクロサービス間のRPC（遠隔手続き呼び出し）経路をどう設計するか検討中のアーキテクトに向けた内容です。
MaculaはErlang/OTP（電話交換機由来の並行処理プラットフォームで、Elixirの基盤としても知られる）で構築されたメッシュネットワークです。2025年後半から開発が続き、コアSDKであるmaculaはhex.pm（Erlangエコシステムのパッケージレジストリ）上でv10.14.1に達しています。クライアント側に受信ポートを一切開かず、VPNも中央ブローカーも要らない通信基盤という設計思想が、既存のサービスメッシュやAPIゲートウェイとどう違うのか整理します。
Maculaとは何を解決する仕組みか
従来型のクライアント・サーバー構成では、サーバー側が受信ポートを開けて待ち受け、クライアントが接続しにいきます。
マイクロサービス間通信の場合、これがサービスメッシュ（Istioなどでサービス間通信を制御する専用インフラ層）やAPIゲートウェイの前提になっています。
Maculaはこの前提を反転させます。
ノードは「リレーステーション」と呼ばれる中継局に対して常に発信（dial out）する側になり、受信ポートを持ちません。
RPC呼び出しもpub/sub（発行・購読型のメッセージング）イベントのファンアウトも、コンテンツやストリームの転送も、すべてこのステーション経由で行われます。
発想としては「自分のサーバー用クライアントライブラリ」ではなく「インターネットを一つの巨大な分散イベントバスとみなし、そこへの接続方法を定義したもの」に近いとされています。
技術要素を段階的に見る
Maculaの構成要素は大きく5つに分解できます。順番に見ていきます。
1. QUICトランスポート
通信の土台はQUIC（HTTP/3の基盤となる、UDP上に構築されたトランスポート層プロトコル）です。
すべての接続がクライアント側からの発信のみで完結するため、受信ポートが不要になります。
QUICは独立したストリーム多重化を持っており、1本のストリームが遅延してもTCPベースのHTTP/2で起きていたヘッドオブラインブロッキング（先頭のパケット詰まりが後続全体を止める現象）を回避できます。
さらにコネクションマイグレーション機能により、スマートフォンがWi-Fiからモバイル回線に切り替わってもセッションが継続します。
TLS 1.3が後付けでなく標準搭載されている点も、後述するセキュリティ設計に直結します。
このトランスポート層はRust製のNIF（Erlangからネイティブコードを呼び出す仕組み、Native Implemented Function）として実装され、内部ではQuinnというRust製QUICライブラリを使っています。
2. Kademlia DHTによるルーティング
「このサービスはどのステーション経由で到達できるか」を解決するのがKademlia DHT（分散ハッシュテーブルの一種で、P2Pファイル共有技術BitTorrentのDHTでも使われる方式）です。
広告・エンドポイント・在席情報は署名付きでTTL（有効期限）が設定された状態で保持され、複数ラウンドの反復探索で解決されます。
一度DHTで解決すれば、あとは該当ステーションに直接ダイヤルするだけで、以降の通信経路にリレーが介在し続けることはありません。
3. SWIM-Lifeguardによる障害検知
メンバーシップ管理と障害検知には中央のハートビートサーバーを置かず、SWIM（Scalable Weakly-consistent Infection-style Process Group Membership、ゴシップ型の分散障害検知プロトコル）を採用しています。
直接・間接プロービングとゴシップ型の伝播が基本のSWIMの仕組みで、Lifeguardは適応的な疑念タイムアウトを追加し、負荷が高いだけのノードを誤って「死んだ」と判定するのを防ぎます。
4. HyParView + Plumtree
コアSDKのバージョン9.2.0から10.5.0あたりで追加された比較的新しい層です。
HyParViewは全ステーションが全ステーションを知る必要をなくし、レルム（realm、論理的な区画単位）ごとに限定された部分ビューだけを保持します。
Plumtreeはそのビュー上にエピデミック型のブロードキャストツリーを構築し、メッシュ全体にフラッディングせずとも情報が行き渡る仕組みを作ります。
これがメッシュの規模が拡大しても、pub/subのファンアウトやマルチホップRPCの中継が「全対全問題」に陥らないようにする鍵です。
5. コンテンツアドレッシングと認可
コンテンツはBLAKE3（高速な暗号学的ハッシュ関数）でハッシュ化され、MCIDという識別子でチャンク単位のput/getが可能です。
キャンセル操作はローカルで諦めるだけでなく、QUICのRESET_STREAMとして相手側にも見える形で伝播します。
認可はEd25519鍵ペアとUCAN（User Controlled Authorization Networks、呼び出し元が提示する能力トークンによる認可方式）に基づいており、セッションやアカウントをステーション側が都度照会する必要がありません。
既存のアーキテクチャとの比較で見る立ち位置
サービスメッシュ（IstioやLinkerd）は、既存のKubernetesクラスタ内でサイドカープロキシがトラフィック制御を担う設計です。
信頼境界は基本的にクラスタ内に閉じており、外部との接続にはIngress/EgressやVPNが別途必要になります。
Maculaはこの前提を持たず、ノード同士がクラスタの内外を問わず対等にメッシュへ参加する設計です。
VPNとの比較では、VPNが「ネットワーク層でのトンネル接続」を提供するのに対し、Maculaは「アプリケーション層でのRPC・pub/sub・コンテンツ転送」を提供します。
中央ブローカー型のメッセージング基盤（Kafkaのような）と比較すると、Maculaは単一の運用者が制御するブローカーを置かない設計を明確に打ち出しています。
Erlang/OTPを選んだ背景も無視できません。
OTP（Open Telecom Platform）はプロセス監視ツリーによる障害分離と自己復旧を前提にした設計で、電話交換機のような常時稼働システム向けに磨かれてきました。
日本の開発現場ではElixir/Phoenixの文脈でOTPに触れた方もいるかもしれませんが、Maculaはそのプロセスモデルをメッシュ全体の可用性設計に転用している形です。
relayステーション自体は「レルムに依存せず、アプリケーションデータを一切保持しない」設計とされ、1プロセス・1つのEd25519アイデンティティを持ち、他のステーションと発信ベースでピアリングしてメッシュを構成します。
導入検討時に確認すべきポイント
この種のインフラを検討する際、次の観点でチェックリストを作ると判断しやすくなります。
- 言語サポート: Erlangに加えGo、Rust、PHP、.NETの4言語向けポートが存在するか、自社の主要スタックがカバーされているか確認する
- 成熟度: hex.pm上のmaculaのバージョン履歴とコミット頻度を見て、マルチホップRPCやストリーミングリレーが実運用でどの程度の期間・トラフィック量で検証されているか確認する
- 可観測性: DHTの解決失敗率、SWIMの誤検知率、HyParViewのビュー更新頻度など、非機能要件として何を監視できるか、ステーション側のメトリクス出力を事前に確認する
- 障害時の挙動: マルチホップRPC（ステーション間を直接ピアリングせずに経由する呼び出し）で途中のステーションが落ちた場合の再ルーティング挙動をテスト環境で検証する
- 認可モデルの移行コスト: 既存システムがセッション・アカウントベースの認可であれば、UCANという能力ベース認可への移行設計が別途必要になる
実際にコードを触る前提であれば、hex.pmでmaculaパッケージのドキュメントとchangelogを確認し、HyParView/Plumtree層が「supervised OTPラッパーがまだない、追加的な実装」である点に留意してください。
本番導入の可用性設計においては、この層が既存のSWIM/DHT層とどう共存するか、障害時にどちらの系が優先されるかをドキュメントまたはソースで確認しておくと安全です。
また、既存の実運用例としてhecate-servicesという別組織がRAG（検索拡張生成）、LLMゲートウェイ、DNS、git、メールなど複数サービスをMaculaクライアントとして実装しており、共通の基盤ライブラリhecate-omで identity・health・capability-advertisingの定型処理を共有しています。
リアルタイム共同編集ホワイトボードのhecate-whiteboardのように、Macula経由でクロスノード同期を行うアプリケーションの実装例を見ておくと、自社ユースケースへの適合性が判断しやすくなります。
まとめ
MaculaはQUIC・Kademlia DHT・SWIM-Lifeguard・HyParView+Plumtreeという既存の分散システム理論を組み合わせ、受信ポート不要・VPN不要・単一運用者に依存しないメッシュ通信基盤を実現しています。
既存のサービスメッシュがクラスタ内の信頼境界を前提にするのに対し、Maculaはノードが対等にメッシュへ参加する点が構造的な違いです。
導入検討時は、まずhex.pmでバージョンとコミット履歴を確認し、HyParView/Plumtree層がまだ監視付きOTPラッパーを持たない追加実装である点を踏まえたうえで、マルチホップRPCの障害時挙動を検証環境で試すところから始めると、自社の非機能要件との適合性が見えてきます。