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次関数的)に増大するのであればインスタンスを追加していけば単純でわかりやすいのですが、時間帯によって大幅に変動するような場合は需要に応じてインスタンスの数を調整したいところでもあります。
コスト節約に直結するため、IT部門にとって日々言われる命題です。しかし毎日インスタンスの起動や終了をいちいち人の手で行うのは面倒ですので、そのような場合はAuto Scalingを使いましょう。
せっかくAuto Scalingでインスタンスを動的に増減できるようにしても、エンドユーザとしてはIPアドレスではなく単一のドメイン名で接続したいと考える人が多いはずです。 となると、Elastic Load Balancer(ELB)の出番ですね。Auto Scalingで増えたインスタンスを自動的にELBへ参加させるように仕込めば、変動する負荷に最適な対応をほぼ全自動で行えるようになります。
ここでELBはHTTPSなどのセキュアプロトコルをリッスンする必要は必ずしもありません。SoftEther VPN側でVPN通信に利用すると指定したポート番号をリッスンすれば問題ないため、それと同じポート番号のTCPリスナを作成しましょう。
この方法を試す場合、VPNクライアント側はNAT-T(NATトラバーサル)を無効にする必要があります。
これを実施しないと、接続してIPアドレスが割当てられた直後にVPN接続が切断されてしまいます。ELBを間に挟むと発生するようなので、ELBの仕様に関連する現象のようです。
この連載ではクラスタ機能のない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におけるスケールアップはインスタンスタイプの変更が該当しますが、インスタンスタイプの変更はわずか数クリックで完了してしまう、非常に簡単な操作なのです。
注意点として、インスタンスタイプの変更にはインスタンスの停止が必要となる点があります。
商用環境や社内向け本番環境をスタンドアロンで動かしているパターンはそう多くないとは思いますが、そうであれば極力影響の少ない時間帯を選ぶ、あるいは作り出すなどの事前準備を行う必要が出てきます。
さて、スケールアップと言うとCPUとメモリについての議論が中心となりがちですが、ネットワークの性能についても忘れてはいけません。EC2の説明ページに次のような画面があることをご存知でしょうか。
一番右側に拡張ネットワーキングという項目があります。 これは対応インスタンスタイプを適切に利用することで、大幅にPPS(パケット毎秒)を上げることが可能という機能です。
インターネットとの通信については回線状況に大きく左右されるためボトルネックとなり、あまり恩恵を受けられないかもしれません。 しかしAWS内のインスタンス間通信には大きな効果がもたらされるため、AWS内での処理速度が向上することが期待できます。
結果として、ユーザ視点ではWebアプリケーションのレスポンスが向上するように見える可能性があります。
3.接続拠点を増やし、地理的に負荷分散を行う
「サービス提供拠点がハッキリしないのも、クラウドの特徴である」というようなフレーズを聞いた方は多いかと思います。
国内の遠隔地に多数の拠点を持ち、地域ごとにVPNサーバを持つことができる場合はこのアプローチが使えます。 が、クラウドでは拠点が地理的にどこなのか、いくつ存在するのかが不明であるため、この方法は役立ちそうにありません。
強いて言うならばアベイラビリティゾーン(AZ)を別にする、という手が該当しそうですが、そのAZがどこにあるかもやはり不明なので効果があるのかすらも判断が難しいでしょう。
ただし、海外にも拠点を持つ企業であれば話が変わってきます。 AWSは地球規模での地域ごとに「リージョン」というサービス提供拠点を持っており、自社の拠点がある国や地域ごとに利用するリージョンを選択するという方法が考えられます。
次の図のように、国内拠点であれば東京リージョン、イギリス拠点であればアイルランドリージョン、アメリカ西海岸北部の拠点であればオレゴンリージョン…というイメージです。
リージョン間はAZ間と異なり、低レイテンシ接続があるわけありません。 そのため、あるリージョン内のシステムを他のリージョンのシステムと連携させることを考えると、通信速度という問題が出てくるので工夫が必要になります。
通信するデータサイズを小さくする他、高速通信プロトコル(SkeedやAsperaなどに代表されるもの)を利用するなどの方法を検討しましょう。
4.接続ユーザごとに使用可能帯域幅を設定し、トラフィックを絞る
これはソフトウェア的な対応であり、オンプレでもクラウドでも実現可能な方法であると考えられます。
本連載で取り扱っているSoftEther VPNにはユーザアカウントごとの帯域制限機能が標準で搭載されており、GUIで設定値を変更するだけで簡単に帯域制限を適用することが可能です。
SoftEther VPNサーバ管理マネージャを開き、 仮想HUBの管理→ユーザの管理→対象ユーザを選択して編集ボタン→ウインドウ右上の「このユーザのセキュリティポリシーを設定する」にチェック→セキュリティポリシーボタンと操作します。
すると設定値リストが表示され、リストのちょうど真ん中あたりに「アップロード帯域幅」「ダウンロード帯域幅」という項目があることを確認できます。
これらの値を変更することで、ソフトウェアレベルで帯域制限を課すことが可能です。
VPNクライアント数がそこまで多くない場合であれば、帯域制限による公平な通信環境をエンドユーザに提供することで対応とするのも1つの方法でしょう。
以上、4つの方法について検討してみましたが、「意外にもオンプレと同様の対策が打てるようだ」と驚かれた方もいらっしゃるのではないでしょうか。
スケールアウトやスケールアップなどの用語はオンプレ主流の時代のものですが、それをAWSで再現しようとすれば用語と方法が変わるわけです。あとは購入対象がサービス商品であること、オンプレで新機材を導入する時のような高額な一時費用の負担がほぼ無いこと、これら2点から生まれる性能とコストについての高い柔軟性が得られることが特徴として現れます。
コストを最適化してVPN接続を自社で構築する場合、これらの点は大きなメリットとなることでしょう。
