Servicesクラウドみなさん、こんにちは!フリューでモバイルサイト開発を行っている鷲見といいます。現在、あるソーシャルプラットフォーム上のアプリケーションを構築するプロジェクトでの、クラウド環境の導入の進行状況をそのまま記事にしています。Servicesを利用することを決定し、データベースにはSimpleDBを利用するところまで決定しました。今回のテーマはアーキテクチャ設計です。AWSを利用したアプリケーションの全体的なアーキテクチャを検討していきたいと思います。今回構築するシステムに求められる要件とアーキテクチャ設計手法について、比較検討しながら最終的な構成を決定していきます。Japanのエバンジェリスト・玉川憲さんらがWebで行われたセミナーの資料があるので、私が紹介するまでもなく、そちらを参考にするのがよいでしょう。ベストプラクティスAWSを用いた耐障害性の高いアプリケーションの設計このWebセミナーを実は社内でヘッドフォンしてノートPCを凝視しながら受講していました。周りの視線が痛かったというのは多分気のせいです。上記Webセミナーを受講して、私が特に印象に残ったのは以下の2点です。トレードオフよくよく考えれば当たり前のことなのですが、クラウドで環境構築をしたからといって止まらないシステムになるわけではありません。『残念ながらAWSを含むクラウドは銀の弾丸ではありません。』とうぜんながらクラウドでも耐障害性の強い環境を構築するのにはお金がかかります。そのあたりの要件とお金のすり合わせの重要性というところはクラウドでも変わらないという点を再認識できたという点で印象に残りました。『全てが故障する前提で設計する。』なんかとても深い言葉です。いままでの耐故障性をあげるために故障を起きないようにしていたのに、故障はするから故障に備えて設計するようにというのはとても印象的でした。AWSでのアーキテクチャ設計はなんといってもここに尽きるんじゃないだろうかと思います。各コンポーネントを疎結合にしておく(サーバ台数が減っても動くように)故障が発生するような高負荷状態が発生した場合、負荷を分散できるようにする高負荷状態のモニタリングオートスケール各コンポーネントを疎結合にしておく(サーバ台数が増えても動くように)という対応がとれるのだと思います。どちらのアプローチをとるのであっても、各コンポーネントを疎結合にしておき、コンポーネントを構成する要素が減っても、増えても稼働することというのは、耐障害性の高いアプリケーションを構築すうる上で重要なところだと思います。今回のアプリケーションの要件としては、ソーシャルアプリケーションなので、サービスのダウンタイムが売上減に直結するので、出来る限りサービスを落としたくありません。要件としてはSPOFは作らないWeb/APサーバはスケールアウトし負荷分散できることWeb/APサーバは全Web/APサーバがダウンしない限りサービスを提供し続けられることなどが挙げられます。上記の要件と設計手法を考慮した結果、以下のようにアーキテクチャ設計を行いました。日本国内向けのサービスのため、Regionは東京リージョンとする。Web/APサーバは単一でも複数でも稼動可能な構成とし、サーバ数の増加で負荷分散できるようにする。AvailabilityZone(AZ)全体の障害に備えて、複数のAZにEC2のインスタンスを配置する。ELBを利用してロードバランシングする。障害に備えEBSのスナップショットをS3に保存する。Route53を利用する。データを自動的に複数AZにコピーし、負荷分散・スケーリングも自動で行うSimpleDBを利用する。この設計結果の構成を図にするとこのようになります。※この図はCacooを使って作成しています。実際のアーキテクチャ設計を行いました。大事な点は『全てが故障する前提で設計する。SimpleDBの詳細について紹介していきたいとおもいます。