クラウドデザインパターン～インフラ方式設計のベストプラクティス集

AWSクラウドデザインパターンというパターン言語を見つけたのでメモ。

【元ネタ】
AWS-CloudDesignPattern

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

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

クラウドの本質はインフラ管理のIT化: プログラマの思索

障害を故意に起こさせるツールで耐障害性を高める: プログラマの思索

フォールト・アボイダンスからフェイルセーフ、フォールト・トレランスへ: プログラマの思索

アジャイル開発が問題点をすり替えた品質特性～機能性と信頼性: プログラマの思索

【1】AWSクラウドデザインパターンは、Webインフラの方式設計(アーキテクチャ設計)のベストプラクティス集と言える。
クラウドという概念は抽象的に分かった気になったとしても、実際にどう使えば効果的なのか、はすぐには分からない。
そこで、パターン言語という形式で、どんな問題に対して、どんな解決方法があり、どのように実装すればいいか、そしてパターンを適用した利点やトレードオフは何か、を明確にカタログ化している。
だから、料理のレシピ集のように、自分が抱えている問題や解きたい問題に当てはまるパターンをカタログから探し出せばいい。

パターンの良さは、クラウドの専門家でなくても、例えば、顧客へシステム提案する立場のSIの営業マンにはとても役立つ。
その理由は、AWSクラウドデザインパターンのAmazonの読者の感想にも書かれている。

(引用開始)
　この本は必読です。技術メンバーはもちろんですが、ITに関わるSalesは読むべきだと思います。webシステムにおいての、お客様の課題、それをクラウドがどう解決できるか、実装方法、利点などがパターン毎に纏められていて、頭が整理されます。顧客との会話の品質をあげるためにも、営業こそ読んで欲しいなあと思いました。
(引用終了)

問題(Problem)と解決(Solution)をセットにしたパターンは、クラウドによるITソリューションを売り物にするSIの営業マンにとって、ノウハウの塊のようなもの。
問題意識を持つ人ならば、AWSクラウドデザインパターンでインスピレーションが働くだろうと思う。

【2】クラウドアーキテクティング原則 - AWS-CloudDesignPatternを読むと、クラウドの本質というかクラウドの使い方について、とてもよく考えられているのが分かる。

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

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

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

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

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

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

「できるだけサービスを利用」は、SOAの本来の思想を連想させる。
サービスを一から作るのではなく、既存のサービスを流用する発想はまさにSOA。

「机上実験よりも実証実験」「最初だけでなく周期的なカイゼン」はまさにアジャイルの発想。
クラウドの本質はインフラ管理のIT化: プログラマの思索にも書いたように、クラウドとはインフラ管理をプログラマブルにすることだ。
本番環境が仮想サーバないし仮想環境として提供できるならば、机上で負荷や性能を熟考した後に1回だけ実験するよりも、実験しながらチューニングしていく方がノウハウがたまりやすい。

ウォーターフォール型開発は、開発環境や本番環境がプログラマブルでない状況という古い時代の制約で育ったように思う。
現代のようにプログラミング技術がテストや設計、インフラも凌駕するならば、アジャイル開発のように小規模リリースしていくやり方の方がより確実だ。

面白いと思ったのは「故障のための設計(Design For Failure)」。
これは、「故障しない設計よりも故障を考慮した設計を重視する」アジャイル開発の思想につながる。
また、セーフウェアに書かれているフェイルセーフ、フォールト・トレランスという品質の重視にもつながるだろう。
つまり、アジャイル開発が問題点をすり替えた品質特性～機能性と信頼性: プログラマの思索にも書いたように、信頼性の問題を「いかに壊れないシステムを作るか」から「いかに素早く直せるシステムにするか」に置き換えていることが重要だ。
バグ無しのシステムを作るのはもちろん重要だが、故障したとしてもすぐに回復できるシステム設計がより重要になってきている時代なのだ。

【3】AWSクラウドデザインパターンは40個以上もあり、全てを理解していないけれど、クラウドに依存しないインフラ方式設計の考え方も入っている。
だから、クラウドに限らず、仮想環境を作る時にとても役立つだろう。

一通り目を通して興味を引いたパターンは「CDP:Bootstrapパターン - AWS-CloudDesignPattern」。
CDP:Bootstrapパターン - AWS-CloudDesignPatternは、仮想イメージを作る時に、初期設定の値をパラメータとして外出しにして、仮想イメージを起動する時にパラメータを読み込むようにするパターン。

この手法は、Chefのrecipeを連想させる。
つまり、Webサーバーの環境を仮想イメージにした場合、DNSやIPなどのネットワーク設定、Apacheなどのライブラリのバージョンや設定ファイルなどを初期設定ファイルとしてパラメータ化し、仮想イメージの起動時に動的に作れるようにすること。
このパターンを使えば、仮想イメージのライブラリがバージョンアップした時や、FirewallやDNSなどのネットワーク設定が変わった時に、簡単に修正したりスケールアップすることができる。

そんなことを考えながらクラウドデザインパターンを眺めると、最近広く知られてきた継続的デリバリの概念を実装する時にクラウドデザインパターンの考え方が役立つように思える。
クラウドデザインパターンは今後要注目だろうと思う。

読者が好きなクラウドデザインパターンは一体何でしょうか？？