rsyncスクリプトの過保護はもう卒業しよう
2つ以上のサーバーを管理していると、設定ファイルやログ、あるいはユーザーのアップロードファイルを同期させるという特有のストレスに直面します。かつて私は、シンガポールにプライマリノード、フランクフルトにバックアップを配置した構成を運用していました。ユーザーが5MBのプロフィール画像をアップロードするたびに、地球の裏側へ即座にミラーリングする必要がありました。最初の解決策は、5分おきにcronジョブで実行される基本的なrsyncスクリプトでした。
しかし、その5分という「窓」は災厄でした。トラフィックが急増した際、セカンダリノードに切り替わったときにファイルが存在せず、画像で404エラーが発生してユーザーを困らせることになったのです。ラグの問題だけでなく、クラスタを拡張するたびにSSHキーを手動でローテーションする手間もありました。それはもはや「システム」ではなく、いつ爆発してもおかしくない「時限爆弾」でした。
現在の同期戦略がなぜ脆弱なのか
手動に近い手法が失敗するのには、3つの明確な理由があります：
- レイテンシのギャップ： Cronジョブはリアルタイムではありません。たとえ60秒間隔であっても、フェイルオーバーが発生した際にデータ不整合が生じる大きな隙間を残してしまいます。
- 単一障害点（SPOF）： 「マスター」サーバーを使用する構成はボトルネックを生みます。その中央ノードがオフラインになれば、同期パイプライン全体が停止してしまいます。
- ファイアウォール管理の疲弊： データセンターを跨いでrsyncやscpを実行するには、特定のポートを開放し、煩雑な
known_hostsファイルを管理し続ける必要があります。これは拡張性のないメンテナンスの負担です。
DropboxやGoogle Driveのようなパブリッククラウドは、本番サーバーの用途には適しません。1TBを超えるとコストが高くつくだけでなく、データのプライバシーを他社に委ねることになります。エンジニアとして、自分たちの境界線（ペリメータ）内で動作するツールが必要です。
対抗馬の比較：実際に使えるツールはどれか？
私はいくつかの主要な選択肢を徹底的に検証し、最終的な勝者を選びました：
1. rsync + lsyncd
lsyncdはファイルシステムイベントを監視してrsyncをトリガーします。これはcronのラグ問題を解決しますが、依然として一方通行の仕組みです。rsyncで双方向同期を構成しようとするのは、誤ってデータが削除されてしまう「スプリットブレイン」シナリオを招くレシピのようなものです。
2. Nextcloud
Nextcloudはオフィス文書の共有には素晴らしいツールです。しかし、サーバー間で/var/www/uploads/を同期させるにはあまりに肥大化しています。フルウェブスタックとデータベースを要求し、小さなVPSではアイドル時だけで512MBのRAMを簡単に消費してしまいます。
3. Resilio Sync
かつてのBitTorrent Syncです。非常に高速で、NATトラバーサルもプロのようにこなします。難点は、クローズドソースであることです。特に機密性の高い設定ファイルを扱う場合、私は中身を監査できるツールを好みます。
4. Syncthing
SyncthingはオープンソースのP2P（ピア・ツー・ピア）の強力なツールです。クラッシュの原因となる中央サーバーは存在しません。Go言語で書かれているため軽量で、数千もの小さなファイルも難なく処理します。すべてがTLSで暗号化されるため、パブリックなインターネット経由でもデータはプライベートに保たれます。
ワークフロー：LinuxへのSyncthing導入
過去数年間で15以上のVPSインスタンスを管理してきた中で、私はこのデプロイ方法を洗練させてきました。ここではUbuntu/Debianを例に説明しますが、論理的な手順は他の現代的なディストリビューションでも同様です。
ステップ 1：公式リポジトリの取得
Ubuntu/Debianのデフォルトリポジトリにあるバージョンは数ヶ月古いことが多いため、使用しないでください。最新の安定版を直接取得しましょう。
# リリースPGPキーを追加:
sudo mkdir -p /etc/apt/keyrings
sudo curl -L -o /etc/apt/keyrings/syncthing-archive-keyring.gpg https://syncthing.net/release-key.gpg
# APTソースに "stable" チャンネルを追加:
echo "deb [signed-by=/etc/apt/keyrings/syncthing-archive-keyring.gpg] https://apt.syncthing.net/ syncthing stable" | sudo tee /etc/apt/sources.list.d/syncthing.list
# アップデートとインストール
sudo apt update && sudo apt install syncthingステップ 2：Systemdによる自動化
サーバーの起動と同時にSyncthingが開始されるようにします。セキュリティ上の脆弱性があった際の影響範囲を最小限に抑えるため、rootではなく標準ユーザーアカウントで実行します。
# 'webadmin' を実際のLinuxユーザー名に置き換えてください
sudo systemctl enable [email protected]
sudo systemctl start [email protected]ステップ 3：リモートアクセスの保護
GUIはポート8384で待機しますが、デフォルトではlocalhostからしかアクセスできません。このポートをパブリックに開放するのは大きなリスクです。SSHトンネルを使用して、自分のPCから安全にアクセスしましょう。
# ローカルマシンで実行してください
ssh -L 9999:127.0.0.1:8384 webadmin@your-server-ipブラウザでhttp://localhost:9999を開きます。最初の作業は、**Settings > GUI**で強力なパスワードを設定することです。これを決して飛ばさないでください。
ステップ 4：メッシュの構築
各Syncthingインスタンスには固有の「Device ID」があります。**Actions > Show ID**から確認できます。サーバーAとサーバーBの間でこのIDを交換してペアリングします。SyncthingはNATを突破し、サーバー間の最速ルートを見つけ出します。ギガビットのバックボーンであれば、50-100MB/sの速度に達することも珍しくありません。
ステップ 5：ファイアウォール設定
ノード間で通信を許可する必要があります。UFWで同期および検出用のポートを開放します。
sudo ufw allow 22000/tcp
sudo ufw allow 21027/udp本番環境に向けた堅牢化
基本的な設定はテスト環境用です。本番環境では、.stignoreファイルを使用して.DS_Storeやnode_modulesなどの一時ファイルをスキップしましょう。これにより帯域を節約し、同期の競合を防ぐことができます。
フォルダ設定で「段階的バージョン管理（Staggered Versioning）」を有効にすることをお勧めします。私は削除されたファイルを30日間保持するようにしています。以前、不適切なクリーンアップスクリプトが200GBのメディアを削除してしまった際、ピアノードの.stversionsフォルダからすべてを復旧させることで救われました。Syncthingは単なる同期ツールではなく、データアーキテクチャのセーフティネットなのです。
