タダです。
AWS認定試験に向けて準備しています。
その中でホワイトペーパーの資料を読んでいて、内容が頭に一瞬はいってもすぐ抜けるので、
内容を自分なりにまとめていきます。
今回読んだのは、「AWS クラウド向けのアーキテクチャ: ベストプラクティス（日本語）」です。
http://media.amazonwebservices.com/jp/wp/AWS_WP_Cloud_BestPractices_JP_v20110531-3.pdf
クラウドのビジネスメリット
クラウドを利用することによるビジネス上のメリットは以下の通り。
・ほとんだ投資ゼロでインフラリソースを得られる。
ハードウェアやデータセンターへお金を投資する必要無くインフラリソースを使うことができる。
・必要な時に必要なインフラリソースを得られる。
・オンデマンドでインフラリソースをコントロールできる。
・使った分だけ費用が発生する。
・インフラリソースをコントロールできるため、市場へのアプリ投入の時間を短縮できる。
クラウドのテクニカルメリット
クラウドを利用することによる技術的なメリットは以下の通り。
・インフラリソースの自動化。
・自動スケールアップ/スケールダウン。
・積極的なスケーリング。
・本番、STG、開発環境を簡単に用意できるから効率的な開発ができる。
・テスト時にインフラリソースが足らなくなることはない。
・DRと事業継続性。
・トラフィックのオーバーフローを防止する。
弾力性
弾力性とは、最小限の労力でコンピューターリソースを容易にスケールアップ/スケールダウンする能力。クラウドの特性のひとつ。
クラウドのベストプラクティス
設計で大切なのは、Design for failure。
故障することを想定して故障から自動的に回復するための設計、実践、導入を実行する。これによりクラウドに最適化された耐故障性の高いアーキテクチャを構築できる。
AWSにて実現するための戦略としては以下の通り。
・Elastic IPを使ってフェイルオーバー
主系サーバーが落ちても従系サーバーへEIPを付け替え、フェイルオーバーすることでトラフィックを新サーバに送れる。
・複数AZで構成する。
データセンター自体が落ちても良いようにAZも複数で構成する。
・AMIを保持し、別のAZに展開できるようにする
・CloudWatchを使って可視的にハードウェアの故障やパフォーマンスの劣化が生じた場合に適切な対処を講じる
・EBSスナップショットをとる
・RDSでは、バックアップの保存期間を設定して自動バックアップを行う
コンポーネントの分離
システムのコンポーネントを疎結合にすればするほど、スケーリングが大規模にうまく行える。
互いに過度に依存し合わないコンポーネントを構築し、あるコンポーネントが構築され、故障が生じていないのように作業を継続すること。
AWSを使った戦略は以下の通り。
・SQSをつかってコンポーネントを独立させたり、コンポーネント間のバッファとして使う
・コンポーネントは非同期でインタラクションを行う
・AMIにコンポーネントの論理的な構造をバンドルし、更に頻繁にデプロイできるようにする
・アプリケーションはキョクリョクステートレスにして、セッションの状態はコンポーネントの外に保存する
インフラリソースの自動化
AWSを使ったインフラ自動化する戦略は以下の通り。
・EC2をAuto Scalingを使って異なるクラスタに自動スケーリングポリシーを定義する
・CloudWatchを使って、システムメトリックス(CPU,メモリー,ディスク I/O,ネットワーク I/O)をモニタリングし、適切な処理を講じるか又は通知を送信する
・マシンのコンフィギュレーション情報をダイナミックに保管、取り込む
・Chefなどをつかってインフラリソースの展開を自動化
・Just Enough Operating Systemとソフトウェアの依存情報をAMIにバンドルしておき、管理・維持をしやすくする
・EBSスナップショットを作成し、適切なアカウント間で共有する
・故障時に自動フェイルオーバーするようにする
