CDP:High Availability NATパターン

提供:AWS-CloudDesignPattern
移動: 案内, 検索
寄贈したアーキテクト

冗長化されたNATインスタンス

目次

解決したい課題

 システム構成をセキュアにするため、インターネットに公開する必要がないサーバーは、インターネットとの直接的な通信ができないネットワークセグメント(プライベートサブネット)に配置する構成にする場合が多い。

 この場合、プライベートサブネットから外部へのアウトバウンド通信はNATサーバーやプロキシーサーバーを経由するが、このサーバーに障害が発生すると、プライベートサブネットのサーバーからアウトバウンド通信が行えなくなり、システム全体の障害につながる。このため、単一障害点(SPOF)にならないように、冗長化が必須である。

クラウドでの解決/パターンの説明

 NATサーバー/プロキシーサーバーの冗長化を行う。障害発生時の迅速なフェイルオーバーと、より高い冗長性の確保のため、複数のデータセンターに複数のNATサーバー/プロキシーサーバーを配置し、単一障害点とならないようにする。

 また、障害が発生しフェイルオーバーする際は、ルーティングテーブルやDNS を使用したフェイルオーバーを行い、NATサーバー/プロキシーサーバーを利用しているサーバーへの接続設定を変更せずに済むように実装する。

実装

①NAT切り替え

 EC2 は通常、トラフィックの送信元と送信先がチェック(Source/DestCheck)されるため、自分宛てではない通信を受信することはない。しかし、このチェックは無効にでき、外部宛ての通信を受け付けられる。サブネットのルーティング先としてチェックを外したインスタンスを指定して、NAT機能を持つEC2インスタンス(NAT インスタンス)を構築できる。

  • インターネットと通信できるサブネット内に、NATインスタンス用AMIを元にEC2インスタンスを複数起動する(複数のAZ の利用を推奨)。
  • NAT インスタンスの"Source/Dest Check" を無効にし、Elastic IPもしくはPublic IPを付与する。
  • プライベートセグメントの0.0.0.0/0のルーティングのターゲットとして、複数あるNATインスタンスのうち1つを設定する。
  • アクティブなNATインスタンスに障害が発生した場合、APIを使用して、ルーティングのターゲットを正常なNATインスタンスに切り替える。[関連ブログ 1]
    • CorosyncやPacemakerを使用すれば、障害時に自動的に切り替えるも可能。[関連ブログ 2]


②ELBを使った冗長化

 HTTPプロキシーサーバーを内部ELB配下に配置し、プライベートセグメントの各インスタンスは内部ELBをHTTPプロキシーとして使用して、冗長化されたプロキシーサーバー経由でアウトバウンド通信を可能にする。

 このパターンの場合、使用できるプロトコルが限られ、アプリケーションレベルでのプロキシー設定も必要となるが、NAT切り替えのようにルーティング切り替えAPIを実行する必要がないため、より簡単に冗長性を確保できる。

 また、ELBのヘルスチェック機能とAuto Scalingを使用すれば、HTTPプロキシーサーバーに異常が発生した場合の自動復旧が可能となる。

  • インターネットと通信できるサブネット内にEC2インスタンスを複数起動し、Squid, ExaProxyといったHTTPプロキシーをインストールする(複数のAZ の利用を推奨)。
  • 内部ELBを起動し、HTTPプロキシーサーバーをロードバランシング対象として登録して、ヘルスチェックを有効にする
  • プライベートサブネットからアウトバウンドのHTTP通信を行う各インスタンスに対し、HTTPプロキシーとしてELBのFQDNを設定する。

構造

①NAT切り替え

ytmxmAAlDNow0uxQ-384A1.png


②ELBを使った冗長化

ytmxmAAlDNow0uxQ-75BAB.png

利点

①NAT切り替え

  • NATインスタンスに障害が発生しても、もう一方のNATインスタンスへのルーティング切り替えによって、短時間で障害復旧できる。
  • ルーティングテーブルを使った切り替えのため、切り替え時間を短くできる。

②ELBを使った冗長化

  • 一つのHTTPプロキシーに障害が発生した場合でも、ELBで冗長化されているためプロキシー全体としては障害とならない。また、障害が発生したプロキシーは自動的に再構築され、障害復旧が行われる
  • HTTPプロキシーを設定することで、接続ログの取得やキャッシング、セキュリティグループ/NACL では実現できないL7フィルタリングが実施できる。

注意点

①NAT切り替え

  • NATインスタンスはスケールアウトできないため、最大インスタンスサイズが性能上限となる。NATインスタンスの性能限界を超えた場合のネットワーク設計は留意しておく必要がある。

②ELBを使った冗長化

  • アプリ/OSレベルにてHTTPプロキシーの設定が必要になる。

その他

関連ブログ

  1. log4moto の「NATインスタンスを冗長構成にしてみた」( http://d.hatena.ne.jp/j3tm0t0/20120814/1344971491 )
  2. suz-lab - blog の「"High Availability NAT"の作成(CentOS6)」( http://blog.suz-lab.com/2013/01/high-availability-natcentos6.html )
個人用ツール
名前空間
変種
操作
CDPメニュー
ツールボックス