⚖️

【CLUSTERPRO × AWS】NLB方式とDNS方式を比較検討！オンプレミス連携を見据えた最適な構成選び

に公開
AWS
インフラ
ha
clusterpro
tech

こんにちは、AWSクラウドエンジニアの鈴木（@KouShinri）です。

最近、オンプレミスからAWSへの移行案件が増えていますよね。その中でCLUSTERPROをAWS上で設計・構築する機会がありました。

AWS内で閉じている環境であれば、VIP（仮想IP）方式でフェイルオーバーする構成だけでも済む話ですが、オンプレミスとの通信が残る場合、ネットワーク構成上そう簡単にはいかない場合も多いです。

そこで今回は、私が設計フェーズで悩み、検証で詰まった「NLB方式とDNS方式の比較情報」について、自分自身の備忘録も兼ねてご紹介したいと思います！

想定読者

  • CLUSTERPROをAWSで構築予定の方
  • NLB方式とDNS方式で迷っている方
  • オンプレHA構成をクラウドへ移行しようとしている方

今回の最大の壁：接続先をどう切り替えるか？

オンプレミスで HA クラスターを組む場合、VIP（仮想IP） による構成が一般的かと思います。

最初、私も一般的な構成の VIP を使おうとしたのですが、これには注意が必要です！
というのも、オンプレミスと AWS をDirect Connect Gateway や VPN で接続する構成の場合、VPC CIDR外のVIPアドレス宛にルーティングさせることができずに通信できない状況になるからです。

もちろん、Transit Gatewayを使えばVPC CIDR外のIPアドレス宛にルーティングさせることは可能です。しかし、すでに構築されている環境は、VPN で接続されていました。

そこで現実的な選択肢として浮上するのが、以下の 2 つになります。

  1. NLB 方式：Network Load Balancer のヘルスチェック機能を利用する
  2. DNS 方式：Route 53 のレコードを書き換える（AWS DNS リソース）

上記2つであれば、Direct Connect Gateway や VPN で接続する構成であっても、通信していくことは可能になっていきます。

AWSの内部挙動を考慮すると、どちらの方式にも特有の『明確な強み』と『意外な弱点』があります。設計時に迷いやすいポイントですので、順番に深掘りしていきましょう！

1. NLB方式について

NLB方式は、クライアントからの通信を常に NLB（Network Load Balancer）で受け、背後の EC2 インスタンスへ振り分ける構成です。

ただし、HA クラスターはアクティブ／スタンバイ構成なので、両方にトラフィックを流してはいけません！
そこで、CLUSTERPRO 側でアクティブなサーバーのみ特定のポート（プローブポート）をリッスンさせ、NLB のターゲットグループのヘルスチェックにそのポートを指定していきます。（NECのブログでは12345番を指定していましたが、業務に関わらないポート番号であれば、自由に設定可能です）

気を付けたいフェイルオーバーの時間について

フェイルオーバーして通信が復旧するまでにどれくらい時間が掛かっていますか？
NLB を作成した直後のデフォルト設定のままテストを実施すると、1 分近くかかってしまう なんてこともあるかもしれません。

なぜそうなるかというと、NLB のターゲットグループのヘルスチェック設定が関係しています。
デフォルトでは、ヘルスチェック間隔が「30秒」、非正常のしきい値が「3回」だったりします。つまり、アクティブサーバーがダウンしてから NLB が「ダウンした」と認識するまでに、最大 90 秒近く待たされる可能性があるわけですね。

解決策：ヘルスチェックのシビアなチューニング

フェイルオーバー時間を短縮するには、業務要件と相談の上、ターゲットグループのヘルスチェック設定をできる限り短くする必要がありますね！

# ヘルスチェックチューニングの目安
HealthCheckIntervalSeconds: 10
HealthyThresholdCount: 2
UnhealthyThresholdCount: 2

このようなチューニングを施すことで、トータルの切り替え時間を「30〜40秒程度」に収めることができました！

セキュリティグループ設計の違い

NLB 方式の場合、EC2 のセキュリティグループには「クライアントからの業務ポート」だけでなく、「NLB のプライベート IP からのヘルスチェック用ポート（例：12345 など）」のインバウンド許可を追加する必要があります。
NLB（ターゲットグループ）でクライアント IP の保持を有効にするか無効にするかで、EC2 のセキュリティグループに設定すべきソース IP が変わる点にも注意が必要ですね！

2. DNS方式について

もう一つの選択肢が DNS 方式です。
こちらは NLB を置かず、クライアントは Route 53 に登録されたレコード名（例：app.cluster.local）にアクセスします。

障害が発生すると、CLUSTERPRO の「AWS DNS リソース」が AWS CLI を実行し、Route 53 の A レコードの IP アドレスを待機系サーバーのものに書き換えてくれます。

DNS方式で気を付けたい「クライアントキャッシュ」

構成図だけを見ると、NLB が不要なのでシンプルで美しく見えますよね。
私も最初は「こっちの方がコストもかからないし良いのでは？」と思いました！

しかし、アプリ担当者と交えたテスト中に問題が生じました。
フェイルオーバー自体は成功し、Route 53 のレコードも数秒で書き換わっているのに、クライアントからの通信がいつまで経っても新しいサーバーに向かないのです。

原因は クライアント側の DNS キャッシュ でした。
Route 53 側でレコードの TTL（Time To Live）を「10秒」のように短く設定しても、OS（Windows/Linux）や Web ブラウザ、あるいは Java などのミドルウェア側で DNS キャッシュを長く保持してしまうことがあります。

「クライアント側の環境（OS、ミドルウェア、ブラウザ）をすべて自前でコントロールできるか？」
この問いに「Yes」と答えられない場合、DNS 方式の採用は避けた方が良いでしょう。

比較表とコスト試算

ここで一度、両方式を比較してみましょう！

比較項目 NLB方式 DNS方式
切り替え時間 30〜40秒程度（チューニング必須） Route53更新（数秒）＋ クライアントのキャッシュ保持時間
クライアントへの依存 なし（DNS名が変わらないため） あり（DNSキャッシュの制御が必要）
AWS環境のコスト 高め（NLBの稼働費用） 安い（Route 53のホストゾーンとクエリ費用のみ）
構成の複雑さ ヘルスチェックとSGの連携が必要 EC2からRoute53への更新権限（IAM）とインターネットへの経路が必要（※もしくはRoute53 Endpoint）
推奨ユースケース クライアント環境を制御できない場合 クライアントが内部で、設定を完全に統制できる場合

月額コストの試算（概算）

NLB 方式のコスト
NLB は起動しているだけで料金がかかります。
・時間単価：約 0.024USD/時間 → 月額 約 17.5USD
・LCU（Load Balancer Capacity Units）料金：トラフィック量に依存しますが、社内システムなら月数ドル程度。
合計：約 25〜30USD/月（約 4,000〜4,500円）

DNS 方式のコスト
Route 53 のプライベートホストゾーンを使用した場合はとても安価です。
・ホストゾーン維持費：0.50USD/月
・クエリ料金：100万クエリあたり 0.40USD
合計：1〜2USD/月（数百円）

コストだけ見れば圧倒的に DNS 方式が有利ですね！
しかし、ここでもう一つの大きな問題があります。

オンプレミスからの通信がある場合の落とし穴

今回の私の案件では、AWS 上の VPC だけでなく、AWS Direct Connect を経由して オンプレミスの社内ネットワークからも HA クラスターにアクセスする必要がありました。

ここで DNS 方式を採用しようとすると、致命的な問題が発生します。
オンプレミスの端末から、AWS VPC 内にある「Route 53 のプライベートホストゾーン」を直接名前解決することはできないのです。（AWS公式ドキュメント参照）

これを解決するには、AWS 側に「Route 53 Resolver インバウンドエンドポイント」を構築し、オンプレミスの DNS サーバーからフォワーディングしてあげる必要があります。

このインバウンドエンドポイント、なんと 1つの ENI（Elastic Network Interface）あたり月額約 90USD かかります。可用性を考慮して 2 つの AZ に配置すると、月額約 180USD（約 27,000円）です！
「DNS 方式の方が安い」という前提は構成次第で大きく変わりますね。

あなたの環境ではどうでしょうか？オンプレミスからのアクセス要件、見落としていませんか？

実際にどちらを選んだか？選定フローチャート

では結局、今回の要件ではどちらがよいでしょうか？

最終的に私が選んだのは 「NLB 方式」 でした！

理由は以下の 2 点です。

  1. 不確実性の排除：クライアント OS やアプリ側の DNS キャッシュという、インフラ側からコントロールしきれない要素にフェイルオーバー時間を依存させたくなかった。
  2. オンプレ通信のコスト：Route 53 Resolver のコストを計算した結果、NLB を立てた方がトータルで安上がりだった。

選定フローチャート

これから方式を選ぶ方は、以下のフローチャートを参考にしてみてください！

  1. アクセス元にオンプレミスや別 VPC が含まれるか？
  • Yes -> 2へ
  • No -> 3へ
  1. Route 53 Resolver の月額費用（約 180USD）を許容できるか？
  • Yes -> 3へ
  • No -> 【NLB方式を採用】
  1. クライアント（OS・アプリ・ブラウザ）の DNS キャッシュ保持時間を確実に制御（TTL通りに破棄）できるか？
  • Yes -> 【DNS方式を採用】
  • No（分からない・制御できない） -> 【NLB方式を採用】

インフラ設計において、「安いから」という理由だけで構成を選ぶと、今後の運用フェーズに大きな代償を払うことになりますね。

まとめ

今回は、「CLUSTERPRO × AWS における接続先切り替え方式（NLB方式 vs DNS方式）」について、自分自身の検証も兼ねてご紹介しました！

AWS というクラウドの常識と、CLUSTERPRO という HA クラスターの常識。
この 2 つを融合させる設計は、想像以上に検証は必要で、考慮すべきパラメータも多いですね。

この記事が、これから AWS 上に CLUSTERPRO で HA 環境を構築したい方にとって、少しでもお役に立てられていれば嬉しい限りです！

Discussion