update.◎はじめに・今更ながら大量アクセスを捌けるシンプルなインフラ構成って、なんじゃらほい。いうわけで考えてみました。利用ツールはCacoo。直感で書くことが出来便利、いつもお世話になっております。先輩に相談しながら作成しました。・上記構成図の簡単な補足になります。CloudFrontってそんなに便利だったんですね。・画像や動画などコンテンツの配信はキャッシュサーバでもあるCloudFrontを使うのが定石。ITリテラシーの低い私は当初、CFへアクセスを振り分けるためにはHAProxyなどのリバースプロキシーが必要と考えていました。シンプルにCloudFrontのDistributionにDNSを向け、アクセス毎に振り分け先を変更できるマルチオリジン機能があったからです。bucket)へ振り分けてくれるようです。その判別ルールに該当しなかったリクエストはELBに渡し、web/appサーバ側で処理するようにしています。CloudFront(※2)ははっ、最近実装された機能なんでしょ(汗)と思ったら、2012/05のAWSブログに当該機能の記載がありました。Replicaを参照用として作成。MasterのDBはMulti-AZにより冗長構成としています。Memcached)を構成に組み込むのも手かと思います。本構成ですと、CloudFront、ELB、Webサーバいずれからも取得が可能になります。各Webサーバ側でアクセスログを収集し、S3へ集約しています。この2つとしたのは、ELB側は固定のフォーマットになるのに対し、Webサーバ側は出力内容やフォーマットをカスタム出来るからです。Webサーバ側からのログ転送には、Fluentdを使っているのをよく見掛けます。運用(スケールアウト)・大量のアクセス流入が予想される場合この構成ですと対処としてフロントサーバの台数を増やすことが考えられるかと思います。その際、日々更新されるであろうサーバ内のアプリケーションやファイルをどうするかという問題がありますが、こちらでは定期backupとは別に、大きな更新が行われた場合などにスケールアウト用のAMIを取得しておき、そちらからスケールアウトすることを想定しています。Scalingを導入している場合は、このAMIを都度ASGに設定しておくといいかと思います。・断りを入れておきますと、場合によって最適解は変わってくるかと思います。以下に例を挙げてみます。GitHubなどSubversionを利用してソースコードを一元管理、Launch時にそちらから最新のソースを取得する。ソースが大きい場合、Launch/deployに時間が掛かりそうです。該当ソースが小さい場合はいい方法かもしれません。コールドスタンバイさせたインスタンスを利用する。定期的、もしくは起動後にサーバ内を同期処理などによって最新にする必要があるため、時間が掛かりそうです。こちらも更新内容がそれほど無ければいい手段かと思います。DSaaSを想定しています。理由は導入が楽だからです。上述のスケールアウト時には、監視対象のインスタンスに事前に組み込んでおいたAgent主導により、自動で監視対象となります。どちらも他の監視ソフト同様、設定は難しいですが、一度設定が確立すれば運用が楽になるかと思います。◎おわりに今回は脳内の想定したものをアウトプットしてみました。Errorが大切だと思いますので、近いうちに実際に手を動かし試し体感してみたいと思います。見習うべきところは見習いたいと常々思っています。あと、ON/OFF(Dancin')大事にしています。upLoginユーザーは見つかりませんでした。