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

From AWS-CloudDesignPattern
Jump to: navigation, search

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

  • できるだけサービスを利用
    • 例えばAmazon S3というインターネットストレージのサービスを考えてみる。これは耐久性が高くて便利なオブジェクトストレージなので、Amazon EC2を使って似たような機能を実装するよりも、S3を使った方が断然いい。キューイングも、Amazon SQSというサービスがあるので、自分で実装するよりこのサービスを使った方がいい。すでに存在しているサービスのメリット/デメリットを正確に理解し、使いこなせることが大事。利用者としては、車輪の再開発はしないほうが良い。
  • 机上実験よりも実証実験
    • 机上実験に終始して「このシステムでこの負荷だと、インスタンスタイプはどれを何台使えばいいのか」と悩んで、そこで時間をかけすぎてしまう、もしくは、止まってしまう。クラウドの良さは瞬時に安く調達できることなので、その場ですぐに実際に試してみればすぐに分かるし、よりカイゼンができる。
  • スモールスタートからスケールアウト
    • クラウドは、小さなサイズのシステムから始めて、簡単にサーバを増やせる。逆もしかり。突発的なトラフィックが予想できるのなら、最初から十分にサーバを立てておいて、それで間に合ったら後で減らしていけばいい。
  • 変化に対し全レイヤで対処
    • クラウドならインフラレイヤからさまざまな選択肢がある。データベースの性能が足りないときには、チューニングで対処するだけではなく、サーバのインスタンスの大きさも変えてみる、データベースそのものを変えてみるといった、インフラも含めた対処が容易になった。
  • 故障のための設計(Design For Failure)
    • バグは出さない方がいいし、サーバは故障しない方がいい。しかしあらゆるものは壊れるのだから、壊れたときどうするかという対応品質を高めるのが大事。クラウドを使うと対応品質が上がる。例えば、サーバが落ちたらすぐ別のサーバを起動して対応し、障害復帰できる。
  • 最初だけでなく周期的なカイゼン
    • WebサービスやWebアプリケーションが完成して運用フェーズに入っても、インフラレイヤまで踏み込んで周期的に改善したほうがいい。いままでは、すでに購入してしまったサーバにまで踏み込んだ改善は難しかったけれど、クラウドではサーバの大きさにまで踏み込んで改善を検討できるようになっている。
Personal tools
Namespaces
Variants
Actions
Navigation
Toolbox