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