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

クラウドの特性を考えると、これまでのシステムアーキテクティングと異なった視点が必要となる。それをクラウドアーキテクティング原則として整理している。

• できるだけサービスを利用
  • 例えばAmazon S3というインターネットストレージのサービスを考えてみる。これは耐久性が高くて便利なオブジェクトストレージなので、Amazon EC2を使って似たような機能を実装するよりも、S3を使った方がいい。キューイングにしても、Amazon SQSというサービスがあるので、EC2にキューイングソフトを入れて自分で管理するよりも、このサービスを使った方が良い。すでに存在しているサービスのメリット/デメリットを正確に理解し、使いこなせることが大事。利用者としては、車輪の再開発はしないほうがいい。

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

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

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

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

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