マルチクラウド接続における課題
AWS、Google Cloud、そしてオンプレミスのデータセンターに分散したサーバー群を管理するのは、往々にして悪夢のような作業です。以前、私は3つの異なるリージョンにまたがるKubernetesクラスターのプロジェクトに携わったことがあります。
当初はOpenVPNを使用した標準的なハブ・アンド・スポーク型のVPNを導入しましたが、2週間も経たないうちにレイテンシ（遅延）が深刻な問題となりました。フランクフルトのウェブサーバーからシンガポールのデータベースへの通信が、わざわざニューヨークの中央ハブを経由しなければならなかったのです。この「ヘアピン現象（ヘアピンニング）」は、アプリケーションの動作を重くするだけでなく、不要なデータホップによってデータ転送（エグレス）コストを30%近くも増大させました。
DevOpsエンジニアにとって、この問題の解決は避けては通れない道です。仲介役を介さず、ノード同士が直接通信できる環境が必要になります。Tailscaleはこの問題を解決する「手軽な」選択肢ですが、SaaS製品であるため、厳格なプライバシーポリシーや予算の制約に抵触する場合があります。Netmakerは、そのセルフホスト型の代替案を提供します。カーネルレベルのWireGuardを使用することで、月額のユーザー課金なしで圧倒的なスループットを実現できます。
従来のVPNがモダンなスタックで遅延する理由
パフォーマンスが低下する主な原因は、古いアーキテクチャにあります。IPsecやOpenVPNのような従来の構成は、ハブ・アンド・スポーク型に依存しています。ノードAがノードBにファイルを送信したい場合、必ずハブを通過しなければなりません。これは単一障害点（SPOF）を生むだけでなく、帯域幅の大きなボトルネックとなります。私のテストでは、これによりリージョン間リクエストに150ms以上の不要な遅延が発生しました。
さらに、オーバーヘッドの問題もあります。OpenVPNはユーザー空間で動作します。パケットが暗号化されるたびに、Linuxカーネルとアプリケーションの間を行き来します。このコンテキストスイッチがCPUサイクルを消費し、通信速度を抑制してしまうのです。現代のワークロードには、ピア・ツー・ピア（メッシュ）アプローチが必要です。暗号化は、最も高速なLinuxカーネル内で直接行われるべきです。
VPNの選択肢を比較する
最終的な解決策を決定する前に、3つの異なるスタックを検証しました。
- Tailscale: 優れたUIを備えていますが、独自のコーディネーションサーバーを使用します。特定のティアでは1ユーザーあたり20ドルかかるため、100ノードのクラスターではコストが急速に膨れ上がります。
- 手動のWireGuard: 非常に高速で軽量です。しかし、50以上のノードに対して公開鍵やIPテーブルを手動で管理するのは、深夜の障害発生の元です。設定ファイルのタイポ一つでネットワーク全体がダウンしかねません。
- Netmaker: これはWireGuardに欠けていたコントロールプレーンです。ギガビット回線で800Mbpsを超えることもあるWireGuard本来の速度を維持しつつ、中央のダッシュボードですべてを管理できます。ピアの交換を自動化してくれるため、手動の手間がかかりません。
Netmakerがユニークなのは、データの所有権を100%保持できる点です。メタデータのルーティングを他社のインフラに依存する必要がありません。
Netmakerのセットアップ：プロフェッショナルなアプローチ
Netmakerコントローラーをホストするには、パブリックIPを持つLinuxサーバー（Ubuntu 22.04が最適）が必要です。このサーバー自体はノード間の実際のデータトラフィックを中継せず、接続を調整する「頭脳」としてのみ機能することに注意してください。
1. コントローラーのデプロイ
最も素早く開始する方法は、公式のインストールスクリプトを使用することです。Docker、Nginx、APIのセットアップを自動で行います。クラウドのファイアウォールでポート80、443、およびUDPレンジ51821-51830を解放しておいてください。
# クイックインストーラーを実行
wget -qO - https://raw.githubusercontent.com/gravitl/netmaker/master/scripts/nm-quick.sh | bash
スクリプトが完了したら、ダッシュボードにログインし、「prod-mesh」というネットワークを作成します。既存のVPCとのルーティング競合を避けるため、10.50.0.0/16のような重複しないIPレンジを使用してください。
2. Netclientによるノードの接続
次に、ワーカーノードをメッシュに参加させます。メッシュに加えたいすべてのLinuxサーバーにnetclientエージェントをインストールします。このエージェントが、ローカルのWireGuardインターフェース設定という重労働を担います。
# エージェントをインストール
curl -sL https://rpm.netmaker.org/install.sh | sudo bash
# ネットワークに参加
sudo netclient join -t <アクセストークンを入力>
参加すると、ノードは即座にUI上に表示されます。ノードは自身の鍵を生成し、公開鍵をコントローラーと共有して、ネットワーク内の他のすべてのノードへの到達方法を自動的に学習します。
本番環境向けのパフォーマンス・チューニング
インストールして終わりではありません。特に負荷の高いデータベースレプリケーションなどを行っている場合、いくつかの微調整が安定性に大きな違いをもたらします。
MTUの最適化
WireGuardは各パケットに小さなヘッダーを付与します。クラウドプロバイダーが標準の1500 MTUを使用しており、WireGuardがフルサイズの1500バイトパケットを送信しようとすると、ネットワークで断片化（フラグメンテーション）が発生します。これはパフォーマンスを著しく低下させます。Netmakerの設定でMTUを1420に設定することをお勧めします。これはほとんどのクラウド環境において最適な値（スウィートスポット）です。
IPフォワーディングの有効化
特定のノードをインターネットやローカルオフィスのLANへのゲートウェイとして機能させたい場合は、Linuxにトラフィックの通過を許可するよう設定する必要があります。以下のコマンドを実行してください。
