今回、仮想デスクトップのディザスタリカバリ環境における通常運用コストを最小限に抑えるため、AWS のオンデマンドインスタンスを選びました。事前の支払いが発生せず、利用時間に応じて課金されるという料金體系は當社のニーズに非常に適してたと思っています。

ただしオンデマンドインスタンスの場合、利用するサーバーは起動時に確保されるという制限があります。したがって、起動時に必要なサーバー數を確保できないというリスクを迴避するため、メインリージョン(シンガポール)のほかにセカンダリリージョン(オレゴン)を利用することにしました。被災時にメインリージョンの 2 つのゾーンでも必要なサーバー數が起動できなければ、セカンダリリージョンで起動する仕組みです。セカンダリリージョンに Amazon Machine Image (AMI)を事前格納していないため、追加費用はいっさいかかっていません。

オンデマンドインスタンスだけでもかなりコストを削減できましたが、さらに最小化するため、通常時は Amazon EC2 インスタンスを停止させておき、マシンイメージである AMI のみを Amazon EBS に儲存しする方法を取っています。こうすることで、通常時は Amazon EBS 上に AMI を保管する料金を支払うだけでよく、被災時には AMI から複數の Amazon EC2 インスタンスを起動することができます。また監視システムも同時に AWS クラウド上に構築しましたが、ロードバランサーに選んだElastic Load Balancing も監視用の Amazon CloudWatch も通常時は起動させないので料金は発生していません。

処理能力に関しては通常時の 75 % に設定しました。理由は首都圏が被災した場合、稼働できる社員の數が相當數減ることが予想できるからです。それを踏まえると 75 % 程度の処理能力は現実的な數字だといえますし、ここを抑えた設定にしたことでさらなるコストカットが実現できています。

このシステム構築において最も懸念していた點が、シンガポールリージョンを採用したことによるレイテンシーでした。一般的に仮想デスクトップシステムで許容可能なレイテンシは 120 - 150 ミリ秒と言われています。しかしシンガポールでも約 80 ミリ秒、セカンダリリージョンのオレゴンでも 200 ミリ秒程度で、デスクトップの操作には大きな支障がないことが検証段階で判明しました。予想以上に高いパフォーマンスに非常に満足しています。また RTO に関しても、被災時に約 100 臺のサーバーを起動するのにかかる時間が心配されていましたが、起動の自動化を図ったことで當初の目標の 85 分を大幅に上回る 63 分での起動を実現しています。少なくともメールの処理などを行うにはまったく問題のない體感速度だといえます。

他の BCP 対策と並行しながら進めていたこともあり、本番稼働は 2015 年 2 月からでしたが、このシステム自體は 2014 年 11 月に環境構築/テストが済んでいました。このシステム構築にかかった初期費用は 1 億円ほどですが、本番稼働後の通常運用では、Amazon EC2 インスタンスも ELB も停止しており、ネットワーク通訊も発生しないため、月額 1 萬円程度のランニングコストで済んでいます。専任の運用擔當者も置いていないため、人的リソースという面でもコストを大きく削減できていると実感しています。もし仮にオンプレミスでこの環境を構築していたら初期費用 4 億円、年間 7,000 萬円のランニングコストが発生したはずですから、コスト削減効果は本當に大きい。もちろん被災時には相応の費用が必要になりますが、通常時に月額 1 萬円のランニングコストを実現できたのは AWS クラウドならではだと思います。