AWSとソフトウェアVPN(6) – 高負荷な状況を考える

Katoです。第5回までで、AWSとのソフトウェアVPN接続を確立しました。AWSではNICのプロミスキャスモードが使えないということ、それ故に複数のSoftEther VPN Serverを拠点間接続することができないということは序盤で説明した通りです。この制約はソフトウェアVPNにとって天敵とも言えるのですが、そんな状況下でも多数のVPN接続を確立して複雑なネットワークや高負荷な状況を考慮することは可能なのでしょうか。今回はVPN接続数を増やすためにどう対応すべきか、考えてみましょう。

本来であれば…

本来であれば：つまりオンプレであればの話ですが、ソフトウェアVPNを用いてサーバ:クライアント=1:膨大の接続を確立する場合の負荷対策として、例えば次のようなアプローチを試みます。もちろんAWSはオンプレではありませんので、オンプレでの常識が全て通用するとは言えません。しかしオンプレが持つ機能をある程度再現できることも事実なので、まず「オンプレだったら」を考え、そこから有効な手段を模索すると良いでしょう。

1.VPNサーバをスケールアウトする

2.VPNサーバをスケールアップする

3.接続拠点を増設し、地理的にトラフィック分散を行う

4.接続ユーザごとに使用可能帯域幅を設定し、トラフィックを絞る

ひとまずこれら4つについて検討してみます。

1.VPNサーバをスケールアウトする

これは割と現実的な案と言えましょう。オンプレではWebサーバなどでありがちな対応方法ですが、この方法はAWSがクラウドであるメリットを最大限に活かせるものです。オンプレでは物理サーバを追加することに繋がるため、サーバハードウェア調達予算と納期、構築にかかる工数、トラフィック予測など多くの項目を試算したり検討したりする必要があります。しかしAWSであればインスタンスを作成するだけでサーバハードウェア調達が完了するため、納期考慮と構築の手間が大幅に軽減されます。予算についても、高額な一時費用を負担する代わりに低額な毎月費用となるため予測しやすくなります。さらに既存の稼働中インスタンスをAMIとして保持しておけば、それを使ってインスタンスを作成することで構築の手間すらほぼ無くすことも可能です。

図1 AMIの作成と利用

図2 Auto Scalingを適用する

図3 Auto ScalingとELBを組合わせる

図4 NAT-T無効化をチェック

この連載ではクラスタ機能のないSoftEther VPNを利用することを前提としていますので、ELBで対処してみました。有償版であるPacketiX VPNにはクラスタ機能が用意されているため、そちらを利用すればELBに頼らずとも単一ドメイン名で任意のVPNサーバへ接続できるようになるはずです。なお、この実験を行うとSoftEther VPNサーバはELBからのヘルスチェックpingをDOS攻撃と誤認することがあります。もともとSoftEther VPNはDOS攻撃を検知して接続を遮断する機能を備えており、誤認が発生するとVPNクライアントから接続に失敗するようになります。このDOS攻撃自動検知機能を無効化することで回避できましたが、ヘルスチェックpingの発信インターバルを長めに設定することでも回避可能かもしれません。詳しくはこちらをご覧ください。

インスタンスが増えると管理が手間と考えがちですが、AWSには管理を支援するサービスももちろん用意されています。Cloud WatchとSNSの組み合わせが最も有名で、追加のソフトウェアを導入せずとも監視通知システムに近い機能を実現することが可能です。「Auto Scalingで生成されELBに参加したEC2インスタンスに何らかの障害が発生し、動作不良に陥った場合はそれをCloud Watchで検出してインスタンスを終了させ、かつメールでそれを通知する」といった動作が具体例と言えます。

2.VPNサーバをスケールアップする

これも現実的な案と考えられます。オンプレではDBサーバに代表される、少数精鋭な役割を持たせるサーバの負荷対策で定番の手法です。が、オンプレで行おうとするとこれまた時間も手間もかかるのが常です。やはりスケールアウトと同様で、新たにサーバや増設部品を調達する必要が出ることから予算と納期、構築の手間などが影響してきます。AWSにおけるスケールアップはインスタンスタイプの変更が該当しますが、インスタンスタイプの変更はわずか数クリックで完了してしまう、非常に簡単な操作なのです。

図5 インスタンスタイプ変更の画面

さて、スケールアップと言うとCPUとメモリについての議論が中心となりがちですが、ネットワークの性能についても忘れてはいけません。EC2の説明ページに次のような画面があることをご存知でしょうか。

図6 インスタンスタイプマトリクス抜粋

3.接続拠点を増やし、地理的に負荷分散を行う

「サービス提供拠点がハッキリしないのも、クラウドの特徴である」というようなフレーズを聞いた方は多いかと思います。国内の遠隔地に多数の拠点を持ち、地域ごとにVPNサーバを持つことができる場合はこのアプローチが使えます。が、クラウドでは拠点が地理的にどこなのか、いくつ存在するのかが不明であるため、この方法は役立ちそうにありません。強いて言うならばアベイラビリティゾーン(AZ)を別にする、という手が該当しそうですが、そのAZがどこにあるかもやはり不明なので効果があるのかすらも判断が難しいでしょう。

ただし、海外にも拠点を持つ企業であれば話が変わってきます。AWSは地球規模での地域ごとに「リージョン」というサービス提供拠点を持っており、自社の拠点がある国や地域ごとに利用するリージョンを選択するという方法が考えられます。次の図のように、国内拠点であれば東京リージョン、イギリス拠点であればアイルランドリージョン、アメリカ西海岸北部の拠点であればオレゴンリージョン…というイメージです。

図7 リージョンごとに独立したシステム

4.接続ユーザごとに使用可能帯域幅を設定し、トラフィックを絞る

これはソフトウェア的な対応であり、オンプレでもクラウドでも実現可能な方法であると考えられます。本連載で取り扱っているSoftEther VPNにはユーザアカウントごとの帯域制限機能が標準で搭載されており、GUIで設定値を変更するだけで簡単に帯域制限を適用することが可能です。SoftEther VPNサーバ管理マネージャを開き、仮想HUBの管理→ユーザの管理→対象ユーザを選択して編集ボタン→ウインドウ右上の「このユーザのセキュリティポリシーを設定する」にチェック→セキュリティポリシーボタンと操作します。すると設定値リストが表示され、リストのちょうど真ん中あたりに「アップロード帯域幅」「ダウンロード帯域幅」という項目があることを確認できます。

図8 ユーザの帯域制限設定画面

以上、4つの方法について検討してみましたが、「意外にもオンプレと同様の対策が打てるようだ」と驚かれた方もいらっしゃるのではないでしょうか。スケールアウトやスケールアップなどの用語はオンプレ主流の時代のものですが、それをAWSで再現しようとすれば用語と方法が変わるわけです。あとは購入対象がサービス商品であること、オンプレで新機材を導入する時のような高額な一時費用の負担がほぼ無いこと、これら2点から生まれる性能とコストについての高い柔軟性が得られることが特徴として現れます。コストを最適化してVPN接続を自社で構築する場合、これらの点は大きなメリットとなることでしょう。