朝日ネットでのインフラ設計・構築を担当しているラピー・ステファンです。 前回は、ソフトウエア・ロードバランサーの技術紹介をしましたが、 サービスの具体的な構成については触れていませんでした。 今回は、段階的に行ってきた構成と設計の変更について紹介したいと思います。
pfSense導入前：旧サービス設計
サービスの実際のドメイン名は伏せておきますが、ご了承ください。
共通の設計の欠点：
- OSが持っているSSLライブラリのバージョンに引っ張られてしまう
- 特定のTLSバージョンが使えない等
- SSLライブラリを更新したことで、特定ソフトの互換性が失われる
- 脆弱性が晒される
- SSL設定・SSL脆弱性対応はサーバーごと、個別にしなければならない
- ファイヤーウォールに保護されているとはいえ、サーバー本体が直接インターネットに出ているので、危険に晒されている
サービス「service1.example.jp」について
「service1.example.jp」について説明します：
- 通常のコンテンツ参照は、ワイルドカードDNSで行い、ラウンドロビンDNSで分散する設計になっていた
- 管理画面「admin.service1.example.jp」が2台のうち、専用ホストを使っていた
設計の欠点：
- 負荷分散の仕組みはDNSラウンドロビンであるため、サービスを全部落とさないと安全なメンテナンス作業の実施が不可能
- 管理画面だけはSSL化されていたが、OSが持っているSSLライブラリのバージョンに引っ張られてしまう
- 一貫性のあるSSL化等のマイグレーションの実施も不可能
サービス「service2.example.jp」について
「service2.example.jp」について、下記の通り分かれています：
- 静的コンテンツを公開する「www.service2.example.jp」
- 動的コンテンツを公開する「app.service2.example.jp」
設計の欠点：
- いずれのサーバーもOSがバラバラでSSL対応が困難
- いずれも単一障害点
- 当時は、ワイルドカード証明書を手配するか、バラバラの証明書を手配する方法しかなかった
その他の問題：
- www.service2.example.jp の方は静的コンテンツしか公開しないので、冗長化は可能だが、アクセスを分散させる方法が必要
- app.service2.example.jp は別のOSで稼働していて、アプリケーションの制約により冗長化は困難
サービス「service3.example.jp」について
「service3.example.jp」について、下記の通り構成されています：
- dynamic.service3.example.jp というホスト名がハードウエア・ロードバランサーが持つ仮想IPアドレスに向いている
- ロードバランサーの後ろ、L7チェックを実施して、DSRでサーバーの実機を設定している
- ロードバランサーはセッションを持続させるsticky設定をしている
- 初期設計に加えて、セッションをサーバー間で共有させる仕組みを導入している
- 複数のホスト名をSSLで公開している
- SSLv3に対応する必要があった時代だったため、ホストごとに仮想IPアドレスを立てる必要があった
- ロードバランサーでバックエンドが被ってはいけない制約があったため、ホストごとに実機用に2個のIPを更に確保しなければならない
- つまり、4個のホストに対応するために： サーバーの本来の実機IPアドレス 2個＋仮想ホスト用IPアドレス 4個 ＋仮想ホストごとの実機用IPアドレス8個 = 合計 14個 のIPアドレスが必要
設計の欠点：
- すべての複雑なURL転送はウェブサーバー内でやらなければならない
- 設定変更・SSL証明書の更新は2台を入れ替えながらやる必要がある
- IPの利用に無駄がある
- ハードウエア・ロードバランサーの制限に引っ張られ、EOL時の再実装・置き換えが困難
pfSense導入後：新サービス設計 第一弾
メリット
- SSL機能をpfSenseにオフロードすることで、アプリサーバーは暗号化に処理を割かなくてもいい
- バックエンドに影響を及ぼさずにSSL機能のみの更新・脆弱性対応が可能
- 例：バックエンドの本体を再構築せず、TLS1.2の対応が可能
- 証明書がクラスター間で共有されているので、サーバーに配る必要がなく管理が一元化される
- システムごとの移行がやりやすくなるよう再設計して依存関係を明確にし、システムをマイクロセグメント化しやすくなった
デメリット
仮想基盤上のCARPの運用は：
- 通常時にこそ問題ないが、設定や構成変更が生じた時、無差別モード等のポリシー適用が保たれるかどうか、注意しなければならない
- 無差別にトラフィックが仮想基盤に流れてしまうため：
- 高帯域・高パケット数のトラフィックの種類には向いていない
- 要求の高いサービスが同じセグメントに集中すると、一斉に性能の劣化が発生する恐れがある
次回予告
次回はpfSenseの構築について具体的に説明すると共に、 上記のCARP+VMware構成のデメリットに対応するための設計改善案を紹介していきます。
採用情報
朝日ネットでは新卒採用・キャリア採用を行っております。
