「クラウドアーキテクティング原則」。クラウドデザインパターンの背後にある、システム設計の原則とは

Amazon Web Serviceのエバンジェリスト 玉川憲氏は、先週開催されたイベント「JAWS Summit 2012」の「AWSクラウドデザインパターン」（略称CDP）を紹介するセッションで、「シナリオに沿ってデザインを適用していく、ということを考えていく中で大事な原則に気がついた」と話しています。

その大事な原則をまとめたものが「クラウドアーキテクティング原則」です。

クラウドアーキテクティング原則

玉川氏はセッションの中でそれぞれの原則について口頭で説明しています。ここではその内容をまとめてみました。

できるだけ既存のサービスを利用する

例えばAmazon S3というクラウドストレージのサービス。これは耐久性が高くて便利なオブジェクトストレージなので、Amazon EC2を使って似たような機能を実装するよりもS3を使った方がいい。キューイングも、Amazon SQSというサービスがあるので、自分で実装するよりこのサービスを使った方がいい。

机上実験よりも実証実験

机上実験に終始して「このシステムでこの負荷だと、インスタンスタイプはどれを何台使えばいいのか」と悩んで、そこで止まってしまう。クラウドの良さは瞬時に安く調達できることなので、その場ですぐに試してみればすぐに分かる。

スモールスタートからスケールアウト

クラウドは、小さなサイズのシステムから始めて、簡単にサーバを増やせる。逆もしかり。突発的なトラフィックが予想できるのなら、最初から十分にサーバを立てておいて、それで間に合ったら後で減らしていけばいい。

変化に対して全レイヤで対処する

クラウドならインフラレイヤからさまざまな選択肢がある。データベースの性能が足りないときには、チューニングで対処するだけではなく、サーバのインスタンスの大きさも変えてみる、データベースそのものを変えてみるといった、インフラも含めた対処が容易になった。

故障のための設計をする

バグは出さない方がいいし、サーバは故障しない方がいい。しかしあらゆるものは壊れるのだから、壊れたときどうするかという対応品質を高めるのが大事。クラウドを使うと対応品質が上がる。例えば、サーバが落ちたらすぐ別のサーバを起動して対応し、障害復帰できる。

周期的に改善していく

WebサービスやWebアプリケーションが完成して運用フェーズに入っても、インフラレイヤまで踏み込んで周期的に改善したほうがいい。いままでは、すでに購入してしまったサーバにまで踏み込んだ改善は難しかったけれど、クラウドではサーバの大きさにまで踏み込んで改善を検討できるようになっている。

玉川氏のクラウドアーキテクティング原則の話は、下記の動画の16分30秒あたりから始まります。