インターネットGWシステム¶

図に使用される表記の凡例

想定するシステム¶

「インターネットGWシステム」を想定したソリューション例について解説しています。

「インターネットGWシステム」とは、企業内のユーザーがクラウドに用意したインターネット接続環境を利用するシステムであり、以下のような特徴を持つシステムを対象としています。

インターネット接続するWebブラウジングのアクセスに対して、Proxyサーバーを配置したり、各種セキュリティ対策を実施する。
VPNが接続されないような小規模なオフィスに対して、インターネットVPN（IPsec）を用いて、クラウド環境/VPN内へ接続する。
SSL-VPNを用いて、インターネットからクラウド環境およびVPN内へのリモートアクセスを行う。

システム構成¶

本システムは、DR（Disaster Recovery、災害復旧）対策を想定して、地理的に離れたメインサイトとDRサイトの2拠点から構成されます。以下では、メインサイトのシステム構成とDRサイトのシステム構成について説明します。

注釈

DRサイトとして利用できるリージョンについては、各リージョンで提供しているサービスを参照してください。

メインサイトのシステム構成¶

メインサイトでは、平時に稼働するシステムを収容しており、以下のような構成を想定しています。

DMZセグメントに配置したシステムの停止時間を最小化するために、物理配置を意識して各種サーバーを配置
外部との通信時のセキュリティ対策としてUTM を適用
無償/安価なVPN接続サービスを用いた多数の拠点との接続
VPNを設置しない小規模拠点に対するIPsecを用いたサイト間接続

システム構成図は以下の通りです。

続いて、構成上のポイントをご説明します。

利用状況に応じたVPN/インターネット接続¶

本サービスで提供するクラウド環境は、VPNサービスであるArcstar Universal OneとVPN接続（Arcster Universal One クラウド接続オプション）を通じて直接接続が可能です。お客さま拠点にインターネット通信を行う必要のあるサーバーが存在する場合や、数千にわたる店舗からインターネットアクセスが必要な場合など、クラウドに用意したインターネット接続から通信を行うことができるため、インターネットアクセスをクラウド環境に集約する構成が取れます。これは、コスト面だけでなく、企業内のインターネットアクセスを一元的にコントロール可能という点で、運用面でも非常に有用な構成です。

IPsecによるサイト間VPNの終端¶

閉域網を引き込んでいない小規模拠点や臨時の拠点との接続に用いるIPsecによるサイト間インターネットVPNは、ファイアウォールが提供するIPsec VPN機能によって終端することが可能です。ファイアウォールは任意の場所に設置できるため、この構成では、外部用のファイアウォールとは別に、IPsec終端用のファイアウォールを内部セグメントにも分離配置し、IPsecの終端を行っています。また、インターネット接続は複数接続できるので、Webブラウジング用のインターネットとは別に、拠点とのIPsec接続用のインターネットを分けて、通信影響を受けない構成とすることも可能です。

なお、特定の拠点がインターネットダウンロードしたファイルで帯域を占有するといったことを防ぐために、ファイアウォールのIF Based Performance Control機能を利用して、帯域制御をインターフェース単位で行うことができます。

注釈

ファイアウォールにて、IPsec通信を許可するためのNAT Traversalの設定が必要です。

セキュリティ対策の強化¶

セキュリティのUTMメニュー（Managed UTM）は、ファイアウォール機能、IDS/IPS機能、アンチウイルス機能、ウェブフィルター（URLフィルタリング）機能、スパムフィルター機能（スパムメール判定）を提供します。Managed UTMは、ファイアウォール機能も含まれるため、トラフィック量に応じて、FirewallとUTMを1台にまとめた構成も可能です。また、トラフィック量が多い場合は、任意のロジカルネットワーク間に設置することができるため、トラフィックを検査したいセグメント間の通信を絞って設置することができます。検査が不要なセグメント間の通信にUTMの処理能力が消費されることを回避できるため、スループットを高めることができます。この例では、外部とつながる通信のみにUTMを配置していますが、必要に応じてさらに複数箇所にUTMを配置することも可能です。

サーバーの物理レベルでの冗長構成¶

現在、インターネットは企業業務の重要な位置を占めるため、DMZセグメントに配置するProxyやメールリレー等の各種サーバーは、高い信頼性が求められます。

一般に、クラウドサービスが提供するサーバーインスタンスは、収容される物理ホストを指定することができません。そのため、複数のサーバーインスタンスで冗長化していても、同一の物理ホストに収容される可能性があります。この時に物理ホストの障害が発生した場合、冗長化しているサーバーインスタンスが同時にダウンし、サービス停止が発生することとなります。サーバーインスタンスは、作成時にサーバーインスタンスが収容される物理ホストの設備群（グループ）を指定することができます。そのため、異なるグループ上にサーバーインスタンスを作成し、冗長構成をとることで、収容物理ホストの分散を担保した物理レベルの冗長化が図れます。

大容量・低価格・高信頼のデータアーカイブ¶

インターネットGWシステムでは、Proxyサーバーのアクセスログなどデータを保存することが重要になります。日々発生するログデータは肥大化していきますが、IT監査等への対応目的として確実にデータを保存する必要があります。これらのアーカイブデータの保存先として、Cloudn Object Storageの活用をお勧めします。Cloudn Object Storageはインターネット経由で利用することができます。データの分散書き込みを実施しており、99.999999999％（eleven nine）という高い信頼性を誇ります。

注釈

Cloudn Object Storageは、日本国内のみの提供です。

DRサイトのシステム構成¶

災害等により、メインサイトがダウンした場合、インターネットを利用した業務が停止することとなります。そのため、災害対策としてDRサイトを構築し、迅速に業務を再開するシナリオを検討する必要があります。ここでは、低コストでDRを実現するために、以下のような特徴を持つシステム構成例をご紹介します。

災害発生時までは、DRサイトは必要最小限のサーバーを起動し、他はテンプレートなどの形で保持する。
インターネット接続で使用するグローバルIPアドレス、VPN接続設定はDR切り替えを迅速に行えるように事前に設定しておく。
災害発生後は、保持しておいたサーバーのテンプレートやファイアウォール等の設定情報を利用して、DRサイトのシステムを構築する。

システム構成図は以下の通りです。

続いて、構成上のポイントをご説明します。

サーバーインスタンスのイメージ事前取得¶

メインサイトで利用しているサーバーインスタンスのインスタンスやボリューム等のイメージファイルを事前に取得（テンプレート作成）しておきます。作成したボリュームは、メインサイトのイメージ保存領域に格納されますが、APIもしくはポータルから持ち出し（エクスポート）することができます。また、エクスポートしたボリュームは、DRサイトのイメージ保存領域に持ち込み（インポート）することもできます。このエクスポート/インポート作業を事前に行っておきます。DRサイトでは、事前に転送したボリュームイメージからサーバーインスタンス（インスタンス+ボリューム）を作成・起動し、DRサイト用の各種設定を行います。

注釈

ライセンスサービスが紐づいたボリュームは、エクスポートすることができません。

サーバーインスタンスへの設定の完了後、

サーバーの特性として平時からデータ同期等が必要な場合、インスタンスを起動したまま待機させておきます（ホットスタンバイ）。
データ同期が不要な場合には、平時にはインスタンスを停止した状態にしておき、災害発生後にサーバーインスタンスを起動します。この場合、インスタンスに対する課金は停止時料金が適応されるため、起動時料金と比べてランニングコストを削減することができます（コールドスタンバイ）。
ある程度の切り替え時間が許容される場合には、インスタンスを削除して、ボリュームだけの状態にしておきます（ディスク保存）。災害発生後に、保存しておいたボリュームをもとにインスタンスを作成します。これにより、ボリューム料金のみが課金され、インスタンスに対する課金は発生しないため、さらにランニングコストを削減することができます。

事前のインターネット接続¶

インターネット接続メニューの10Mbpsメニューは無償もしくは安価に利用できるため、DRサイトへ事前に接続しておきます。また、グローバルIPアドレスについても必要な数だけ事前に契約しておき、アドレスを確保しておきます。これにより、事前にDRサイトのアドレス設計を行っておきます。例えば、外部用のファイアウォールやDNSについても、事前に払い出したグローバルIPアドレスを用いて設定パラメータを事前に確定させておき、DR発動時に速やかに変更作業に移ることができます。なお、DR発動後に10Mbpsでは帯域が不足する場合、必要な帯域まで拡張を行います。

ユーザーアクセス経路の切替¶

DRサイトへのデータ移行とリストア処理が完了したら、ユーザーからのアクセス経路を切り替える必要があります。この切り替えには、以下の2つのパターンを用いることができます。

平時からDRサイトの各ノードには新たなプライベートIPアドレスを割り振っておき、予めVPNを接続しておきます。DR発動時には、社内で利用されている内部用のDNSレコードを変更し、ユーザーからの接続先をメインサイトからリカバリサイトへの切り替えます。切り替え先のプライベートIPアドレスが確定しているので、ゾーンファイルや変更スクリプトを平時から予め準備しておくことで、切り替え作業をスムーズに実施することができます。
事前に、DRサイトで、サービス面にメインサイトと同じプライベートIPアドレスを割り振った、レプリカ構成を構築しておきます。この時、DRサイトでは経路広告をしていないため、メインサイト/DRサイトそれぞれで同一アドレスが割り振られていても、通信に異常をきたすことはありません。メインサイトの異常時には、予め用意しておいたAPIを用いて、DRサイトから経路を広告することにより、通信をDRサイトへ誘導することができます。

また、インターネット接続も、10Mbpsベストエフォートメニューであれば無料または安価に利用することができるため、事前にインターネット接続を行っておきます。あわせて、必要な数のグローバルIPアドレス（有料）を確保しておくことで、グローバルIPアドレスを含めたパラメータを確定することができます。これにより、DR発動の際の切替手順を事前に作成することが容易になります。