小規模基幹系システム¶
図に使用される表記の凡例
想定するシステム¶
「小規模基幹系システム」を想定したソリューション例について解説します。
「小規模基幹系システム」とは、主に企業内のユーザーが利用する「業務系、財務/会計系システム」のうち、以下のような特徴を持つシステムを対象としています。
- 24時間365日稼働。メンテナンス時にはサービス停止することが許容される。
- SPOF（Single Point of Failure、単一障害ポイント）は極力存在させないが、サーバーは仮想環境でのHA（High Availability、高可用性）を想定した冗長構成を前提とする。
- RPO（Recovery Point Objective、目標復旧時点）は 1日程度が可能。（1日以内の場合、アーカイブログを日に数回バックアップしておきロールフォワード回復程度）
- ある程度重要なシステムであるが、DR（Disaster Recovery、災害復旧）対策はフルバックアップデータを退避しておき、DR後にシステム再構築のRTO（Recovery Time Objective、目標復旧時間）レベル。
システム構成¶
本システムは、DR対策を想定して、地理的に離れたメインサイトとDRサイトの2拠点から構成されます。以下では、メインサイトのシステム構成とDRサイトのシステム構成について説明します。
注釈
DRサイトとして利用できるリージョンについては、各リージョンで提供しているサービス を参照してください。
メインサイトのシステム構成¶
メインサイトでは、平時に稼働する基幹系システムを収容しており、以下のような構成を想定しています。
- すべてのサーバーは低コストの共有仮想基盤で構成。
- 外出ユーザーがインターネット経由でアクセスするRemote Desktop（リモートデスクトップ、RD）ゲートウェイをDMZセグメントに構築。
- 本番、検証、開発の3面構成。
システム構成図は以下の通りです。
続いて、構成上のポイントをご説明します。
データベース オフィシャルテンプレートの利用¶
サーバーインスタンス上にデータベースサーバーを構築する場合、オフィシャルテンプレートからOracle DatabaseまたはMicrosoft SQL Serverを利用してサーバーインスタンスを構築することが可能です。
お客さまが購入されたライセンスをクラウド環境上へ持ち込み利用いただく場合は、各ソフトウェアが定めるライセンスおよび技術的な規約・要件に従ってください。
例えば、Microsoft SQL Serverについては、一般的に共用環境上での利用に制約があります。サーバーインスタンスも共用基盤上で動作していますが、NTTコミュニケーションズ株式会社はMicrosoft社の「認定モビリティパートナー」です。そのため、SA（ソフトウェアアシュアランス）のライセンスモビリティ特典を利用することができます。具体的には、以下の方法によりMicrosoft SQL Serverライセンスを持ち込み利用することができます。
- お客さまがMicrosoft社のリセールパートナー（販売店）よりMicrosoft SQL Serverのボリュームライセンスを購入する
- 上記のボリュームライセンスに対して、お客さまがSA（ソフトウェアアシュアランス）を追加契約する
- SA（ソフトウェアアシュアランス）特典の「ライセンスモビリティ」に基づき、お客さまのMicrosoft SQL Serverのボリュームライセンスをサーバーインスタンスサービス上に持ち込む
- 持込み後10日以内に「ライセンス確認フォーム」に記入いただき、リセールパートナー（販売店）経由でMicrosoft社に提出する
注釈
サーバーインスタンス上へのOracle製品の持込みには対応していませんので、ご注意ください。Oracle製品を持ち込み利用する場合は、ベアメタルサーバー上での利用をご検討ください。
データベースのデータ領域用ストレージ¶
サーバーインスタンスは、システム領域用のボリューム(内蔵ディスク)がアタッチされています。本例では、データベースのデータ領域を保存するためのストレージとして、サーバーインスタンスのボリューム（内蔵ディスク）を追加でアタッチして利用しています。
商用環境においては、ボリューム（内蔵ディスク）のパフォーマンスでは不足することがあります。この場合には、ブロックストレージが提供するボリュームを外部ディスクとしてマウントして、データ保存領域として利用することもできます。
データベースのバックアップ¶
論理障害、物理障害に備えたデータベースのデータバックアップは、小規模なシステムでも重要です。
今回の例では、バックアップ用のファイルサーバー（バックアップサーバー）をサーバーインスタンスとブロックストレージを組み合わせて構築し、DBMS（DataBase Management System、データベース管理システム）のバックアップコマンドやツール(SQL Server Management Studioなど)を利用し、フル/差分バックアップやトランザクションログといったバックアップファイルをバックアップサーバーに出力することを想定して います。サーバーインスタンス（インスタンスおよびボリューム）は、収容される設備群（グループ）を指定することができます。例えば、DBサーバーをグループAに、バックアップサーバーをグループB上に構成することで、万一どちらかのサーバーに物理障害が発生した場合でも、データが完全に消失する事態を回避することができます。
RDS User CALの持ち込み利用¶
共有基盤でWindows ServerのRemote Desktop環境を構築する際には、RDS(Remote Desktop Service)アクセスライセンスが必要となります。本サービスでは、お客さまがお持ちのRDS User CAL(Client Access License)に対してSA（ソフトウェアアシュアランス）を追加いただくことで、ライセンスモビリティ特典を利用することができます。具体的には、以下の方法によりRDS User CALをクラウド環境上に持ち込んで利用いただくことができます。
- お客さまがMicrosoft社のリセールパートナー（販売店）よりRDS User CALのボリュームライセンスを購入する
- 上記のボリュームライセンスに対して、お客さまがSA（ソフトウェアアシュアランス）を追加契約する
- SA（ソフトウェアアシュアランス）特典の「RDS User Client Access License (CAL) の拡張された権利」に基づき、お客さまのRDS User CALをサーバーインスタンスサービス上に持ち込む
- 持込み後10日以内に「ライセンス確認フォーム」に記入いただき、リセールパートナー（販売店）経由でMicrosoft社に提出する
商用/検証/開発環境の3面構成と低コスト運用¶
多くのケースでは小規模であっても、基幹系とされるシステムでは本番環境とは別に検証環境と開発環境を用意します。
サーバーインスタンスにおいては、使用しない間はインスタンスを停止状態しておくことで起動時に比べて課金額を低減することができます。さらなるコスト低減方法として、インスタンスを削除し、ボリューム部分だけを残したり、ボリュームイメージ化したりすることで、インスタンスおよびライセンスサービスに対する課金を停止することができます。しかしながら、起動時にインスタンスの作成とボリュームのアタッチ作業が必要となるなど、サーバー起動までの時間・手間がかかることになります。
検証用・開発用サーバーの利用頻度に応じて、コストと時間のバランスを取った運用をすることができます。
DRサイトのシステム構成¶
メインサイトの災害発生時には、メインサイトからDRサイトにシステムを切り替えが必要です。この例では、RTOが長くてもよいので低費用でDRサイトの準備をしておくことを目標とします。そのため、DRサイトには通常時はインスタンスは起動しておらず、災害発生時に再構築を容易に行い、データ復旧させるモデルとなっています。
システム構成図は以下の通りです。
続いて、構成上のポイントをご説明します。
DRサイトでのサーバーのホットスタンバイ/コールドスタンバイ¶
DRサイトでは、各サーバーを構築した上で、待機させておきます。
例えば、ADサーバーのように、常に同期が必要な特性を持つサーバーについては、DRサイトでも常に起動した状態にしておき、メインサイトからレプリケーションを実施する必要があります（ホットスタンバイ）。サイト間のレプリケーション用トラフィックについては、クラウド/サーバー リージョン間接続の利用をお勧めします。クラウド/サーバー リージョン間接続は、ベストエフォート型で遠隔地にあるデータセンター間を接続するメニューです。無償で利用することができるため、DR費用を低減することができます。
レプリケーションが不要なサーバーについては、DRサイトでサーバーを構築した上で、停止状態にしておきます（コールドスタンバイ）。停止状態にしている間は、インスタンスに対する課金として割安な停止時料金が適応されるので、コストを削減することができます。
注釈
サーバーに対してパッチ当てなどのメンテナンス作業を行う際には、メインサイトの本番系サーバーだけでなく、DRサイトの待機系サーバーでも同様の作業を行うことをお勧めいたします。
さらに、前述のとおり、インスタンスを削除し、ボリュームやボリュームイメージだけを残す方法もあります。この場合は、コストを抑えられる一方で、サーバー起動までに時間・手間がかかります。サーバーの用途に合わせて、RTO要件とコスト要件からより適した方法をお選びください。
データベースバックアップのサイト間コピー¶
DRサイトのデータベースサーバーのデータには、DR発動時には最新のデータが反映されていません。そこで、フル/差分バックアップデータからの復旧に加えて、トランザクションログを用いたロールフォワード処理を行ってRPOの短縮を図ります。
まず、通常時のバックアップとして、メインサイトバックアップサーバーにフル/差分バックアップやトランザクションログを定期取得しておきます。これらのデータをクラウド/サーバー リージョン間接続を通じてメインサイトからDRサイトへ定期的なコピーを実施しておきます。これにより、常に最新のバックアップデータをDRサイトで保持する ことができます。
DR発動時には、待機していたデータベースサーバーに対して、フル/差分バックアップからリストアを行います。フル/差分バックアップ取得以降のデータについては、トランザクションログ用いたロールフォワード処理によって最新の状態まで復旧を行います。
ユーザーアクセス経路の切替¶
DRサイトへのデータ移行とリストア処理が完了したら、ユーザーからのアクセス経路を切り替える必要があります。特に、基幹系システムにおいてはVPNを経由したアクセスが想定されるため、VPNのアクセス経路を円滑に変更することが必要となります。この切り替えには、以下の2つのパターンを用いることができます。
- 平時からDRサイトの各ノードには新たなプライベートIPアドレスを割り振っておき、予めVPNを接続しておきます。DR発動時には、社内で利用されている内部用のDNSレコードを変更し、ユーザーからの接続先をメインサイトからリカバリサイトへの切り替えます。切り替え先のプライベートIPアドレスが確定しているので、ゾーンファイルや変更スクリプトを平時から予め準備しておくことで、切り替え作業をスムーズに実施することができます。
- 事前に、DRサイトで、サービス面にメインサイトと同じプライベートIPアドレスを割り振った、レプリカ構成を構築しておきます。この時、DRサイトでは経路広告をしていないため、メインサイト/DRサイトそれぞれで同一アドレスが割り振られていても、通信に異常をきたすことはありません。メインサイトの異常時には、予め用意しておいたAPIを用いて、DRサイトから経路を広告することにより、通信をDRサイトへ誘導することができます。
また、インターネット接続も、10Mbpsベストエフォートメニューであれば無料または安価に利用することができるため、事前にインターネット接続を行っておきます。あわせて、必要な数のグローバルIPアドレス（有料）を確保しておくことで、グローバルIPアドレスを含めたパラメータを確定することができます。これにより、DR発動の際の切替手順を事前に作成することが容易になります。