ハイブリッドクラウドの効率的構築法

Amazonが、AWS Outpostsというサービスを出している。オンプレミスのアプライアンスだが中身はAWS、というものだ。つまり、ソフトウェア的にはAWSと同じように使えるが、ローカルにハードウェアがあるため、高速レスポンスが可能であったり、データをローカルに置くことができたりする。これはもちろん本家AWSとつながっており、同じAWSコンソールから管理できる。Googleも似たようなものを出している。

さて、ハイブリッドクラウド、つまりパブリッククラウドとオンプレミスローカルを併用するシステムにおいて、ローカルをこのようなクラウドアプライアンスで作り、負荷分散やDR/BCMを自由に出来るように設計しておく、というのは、今後のシステムの在り方として妥当だろう。

つまり、高負荷の時や災害時だけに何か特別のことをするのではなく、普段から負荷調整をオンプレミスとクラウドの間でやり取りしておき、障害が起きたときの負荷移動は、普段の調整の一パターンに過ぎない、という運用だ。これには、ローカルを入れ替えたい時、ローカルが故障した時、クラウドにトラブルがあった時、何れもクラウドの機能で対応できるため、SIが簡単になるし、普段の運用も楽になる。

この際、もうひと手間掛け、常にローカルがフル稼働になるように構築する、というのが今回のアイデアだ。

AWS Outpostsをそのまま使うと料金体系を握られてしまうので、似て非なるOutpostsモドキを作っておいて、AWSコンソールと連携ができる外部システムとして構築しておく。そして、ローカルが常にフル稼働になるように設定すると、当然ローカルの資源使用効率が最大になる。もちろん手に余る負荷はAWSに逃がすわけだ。

こうする目的は費用の節約だ。従来の構成では、耐障害性や冗長性が必要だったが、AWSと連動して負荷を移動できるのであれば、この構成では不要である。また、AWSの品質基準を満たす必要はないので、安い部品を使ったり、保証を外すなどして、価格低減策が図れる。極端な話、UPSは不要か、ごく最低限(異常信号送出とシャットダウンができれば良い)で十分である。更に、これを最大負荷で安定して廻すことによって、掛けたハードウェアのコストを余すこと無く回収することができる。

この場合、クラウド側にトラブルがあった時に備え、リージョンを複数設けておく。また、最悪縮退運用できるように設計しておく必要は残される。

ピーク性能ではなくベース性能を元にオンプレミスを構築し、余剰は全てAWSにする、というのでも良いが、多くの場合は負荷曲線によって最適なオンプレミスの計算能力が計算できる。そういう計算方法とアプライアンス、そして配置ポリシーをセットで売れば、ヒットすること間違いない。