ソフトウェアエンジニアがシステムNW冗長化を実現するまで

アドベントカレンダー2025

はじめに

この記事は BBSakura Networksアドベントカレンダー2025 の9日目の記事です。

本記事は、今までソフトウェアエンジニアとして、システム開発を主に担当してきた私が、オンプレミスサーバのNW冗長化を行った時の実体験を紹介します！

自己紹介

はじめまして、BBSakura Networks株式会社の姜（カン）です。

2023年4月にBBIX株式会社に中途入社し、BBSakura Networksに兼務で勤めています。 普段の業務ではBBIXのカスタマーポータルと、共通認証部分の開発、BBIX HPのサーバ管理を担当しています。

BBIX、BBSakuraに中途入社するまでは、前職としてWEBアプリケーション開発をAWS等既存のクラウドサービスを利用して、システム開発を行っていました。 そのため、オンプレミスサーバの運用とVMのNWに関する知識はほとんど無い状態でした。

システムのNW冗長化を実現するまでの流れ

そもそも、冗長化とは

基礎的な知識かもしれませんが、各役割（WEBサーバ、APPサーバ、DBサーバ等）ごとに1台の構成だと、VM故障、アプリの停止等なにか障害が起きた際にシステムの継続利用ができません。それを防ぎ、システムの耐久性を向上させるため、予備の機器や機能などをあらかじめ多重に組み込んでおいて可用性と信頼性を高めるための重要な設計のことです。

なぜソフトウェアエンジニアがNW冗長化に挑むことになったか

ネットワークの会社であることもあり、システム開発メンバーとしても、単純にアプリケーションの開発補修だけではなく、そのアプリケーションとDBが動いているVMの運用全般を担当することになっています。

既存NWの問題点

既存のシステム構成でも一般的なオンプレミスネットワーク内のNW冗長化を行っていましたが、全てのサーバが同じネットワーク内である場合、ネットワーク網の障害時にシステムが利用できないことから、別のネットワーク網との冗長化を計画することになりました。

一般的なシステムNW構成図
一般的なシステムNW構成図

今回のNW冗長化構成の変更案

さくらのクラウド上にサーバを増設してインターネット経由でのNW冗長化を実現することに決めました。 これによって、BBIXのネットワーク網に障害が発生しても、さくらのクラウドにあるバックアップサーバでシステムが継続利用できるようになります。

NW冗長化対応後イメージ
NW冗長化対応後イメージ

工夫した部分

通信の方法

異なるネットワーク間の通信を連携させるためには一般的にインターネット経由でのGlobal IP解放でも良いですが、セキュリティ的にリスクがあるため、今回の冗長化対応としてはVPNを構築しての通信にすることにしました。 そこで採用したのが WireGuardです。その理由としては以下が挙げられます。

  • 「速い！」: カーネル内部で動作し、他のプロトコル（IPsec/OpenVPNなど）と比較してオーバーヘッドが極めて少ないため、体感できるほどの通信速度の向上が期待できる。
  • 「安全！」: 採用している暗号技術が最新かつ強固であり、セキュリティを専門としないユーザーでも安全性が担保されていること。
  • 「簡単！」: 設定ファイルが非常に短く、数行でセットアップが完了するため、従来のプロトコルよりも大幅に容易。
データベースのデータ同期の方法

さくらのクラウド側とのデータ同期のため、オンプレミス側のネットワークにMySQL Router（クライアントからのDB接続を仲介・ルーティングするミドルウェア）のVMを増設し、構築したVPN経由でレプリケーションを張ることにしました。

また、データの同期整合性を確保するため、DBの構成を大きく変更しました。

  • マルチプライマリーからシングルプライマリーへ： 以前の構成では書き込み競合（コンフリクト）のリスクがあったため、MySQL InnoDB Clusterを構築し、オンプレミス側をシングルプライマリー構成に一本化しました。

  • レプリケーション：オンプレミスのPrimary DBサーバと、さくらのクラウド側のDBサーバ間に非同期レプリケーションを構築。これにより、アプリケーションは常にオンプレミスのPrimaryを参照し、データはさくらのクラウド側へ流れ続ける状態を実現しました。

NW障害復旧時のデータ同期の方法

BBIX網でNW障害が発生し、さくらのクラウド側へ切り替わった（フェールオーバー）場合、さくらのクラウド側のDBが一時的にMasterとなり最新データが書き込まれます。しかし、NW復旧時にそのままオンプレミス側に戻すと、オンプレミス側のDBが最新データを持っていない（さくら側がMasterになっているため）という問題がありました。

BBIX網でNW障害時にが発生した際にはさくらのクラウド内でシステムが完結して問題ありませんが、復旧時にオンプレミス側のDBサーバがさくらのクラウド側の最新データの情報を取得していないことがわかりました。（障害時にさくら側にフェールオーバーしてDBのMasterになってるため） そのためオンプレミスのAPPサーバ内部に通信の障害&復旧を監視する仕組みを導入し、NW障害が発生した際にオンプレミス側のシステムからさくら側にあるDBサーバを参照するように向き先自動変更のツールを導入しました。

NW冗長化を実現してからのふりかえり

システムは開発フェーズも重要ですが、運用フェーズ、特に障害時の挙動こそがサービスの継続性を支えると痛感しました。今回の経験から、特に以下の2点を強く意識するようになりました。

  • 自動復旧の追求: 障害発生時、人手を介する手順を極力減らし、復旧までのスピードを意識した自動化の重要性。

  • IaaSの裏側を知る: 普段、AWSやGCPといったクラウドサービスで「当たり前」に提供されているロードバランサやマネージドDBの自動フェールオーバー機能が、裏側でどのような仕組み（監視、レプリケーション、Master切り替えなど）で動いているのかを、オンプレミス環境で自ら構築することで深く理解することができました。

これからも、お客様が支障なく継続利用できるような「止めないシステム」の仕組みを追求し、この貴重な経験を活かして開発・運用に取り組んでいきたいです。

おわり

ここまで読んでいただきありがとうございます。

初のBBSakura Networksアドベントカレンダー投稿で、読み返すと未熟なところもありますが、自分の経験を共有しつつ、改めて整理したことも良い経験になりました。 こういった互いの経験や情報、さまざまな場面を共有する場に積極的に参加していきたいと思います！ これからもBBIX、BBSakuraの一員として社会のインフラを支えていくエンジニアとして成長していきます。よろしくお願いします！