◎はじめに
- 今更ながら大量アクセスを捌けるシンプルなインフラ構成って、なんじゃらほい。
というわけで考えてみました。
01. 前提
- モデルは定期的に大量流入があるポータルサイト
- 第一にアクセスを捌けること、第二に運用保守のことも(少し)考慮
02. 構成図
- それで考えてみた構成がコチラ(※1)
→ 利用ツールはCacoo。直感で書くことが出来便利、いつもお世話になっております。
(※1) 社内にある事例を参考にしておりますmm また、先輩に相談しながら作成しました。多謝！
→ けれど、この構成に矛盾や不備があれば私の責任ですmm
03. 説明
- 上記構成図の簡単な補足になります。
03-1. CloudFrontってそんなに便利だったんですね。。
- 画像や動画などコンテンツの配信はキャッシュサーバでもあるCloudFrontを使うのが定石。
ただITリテラシーの低い私は当初、CFへアクセスを振り分けるためにはHAProxyなどのリバースプロキシーが必要と考えていました。
が、不要でした。
シンプルにCloudFrontのDistributionにDNSを向け、アクセス毎に振り分け先を変更できるマルチオリジン機能があったからです。(※2)
これで画像や動画を指すURI(例: /img/、 /.mp4 など)を判別し適切なオリジン(今回は用途毎に別けたS3 bucket)へ振り分けてくれるようです。
その判別ルールに該当しなかったリクエストはELBに渡し、web/appサーバ側で処理するようにしています。
▽参考
- AWS Documentation – Amazon CloudFront
(※2)ははっ、最近実装された機能なんでしょ（汗）と思ったら、2012/05のAWSブログに当該機能の記載がありました。。反省
03-2. RDS(見たままです)
- RDSの便利な機能でRead Replicaを参照用として作成。
MasterのDBはMulti-AZにより冗長構成としています。
この構成にはありませんが、DBへの参照が頻繁にある場合は ElastiCache(Redis / Memcached)を構成に組み込むのも手かと思います。
03-3. 運用(ログ)
- アクセスログを取得したい場合
本構成ですと、CloudFront、ELB、Webサーバいずれからも取得が可能になります。
今回はELB と 各Webサーバ側でアクセスログを収集し、S3へ集約しています。
この2つとしたのは、
ELB側は固定のフォーマットになるのに対し、Webサーバ側は出力内容やフォーマットをカスタム出来るからです。
Webサーバ側からのログ転送には、Fluentdを使っているのをよく見掛けます。
03-4. 運用(スケールアウト)
- 大量のアクセス流入が予想される場合
この構成ですと対処としてフロントサーバの台数を増やすことが考えられるかと思います。
その際、日々更新されるであろうサーバ内のアプリケーションやファイルをどうするかという問題がありますが、
こちらでは定期backupとは別に、大きな更新が行われた場合などにスケールアウト用のAMIを取得しておき、そちらからスケールアウトすることを想定しています。
ちなみにAuto Scalingを導入している場合は、このAMIを都度ASGに設定しておくといいかと思います。
– 断りを入れておきますと、場合によって最適解は変わってくるかと思います。
以下に例を挙げてみます。
- GitHubなどSubversionを利用してソースコードを一元管理、Launch時にそちらから最新のソースを取得する。
→ ソースが大きい場合、Launch/deployに時間が掛かりそうです。該当ソースが小さい場合はいい方法かもしれません。 - コールドスタンバイさせたインスタンスを利用する。
→ 定期的、もしくは起動後にサーバ内を同期処理などによって最新にする必要があるため、時間が掛かりそうです。こちらも更新内容がそれほど無ければいい手段かと思います。 - 最新サーバのコピーから等
03-5. 監視/セキュリティ対策
- 構成図の隅にちょこんと記載していますが、外部の Datadog と DSaaSを想定しています。
理由は導入が楽だからです。
上述のスケールアウト時には、監視対象のインスタンスに事前に組み込んでおいたAgent主導により、自動で監視対象となります。
どちらも他の監視ソフト同様、設定は難しいですが、一度設定が確立すれば運用が楽になるかと思います。
◎おわりに
今回は脳内の想定したものをアウトプットしてみました。
PDCAもしくはTry & Errorが大切だと思いますので、近いうちに実際に手を動かし試し体感してみたいと思います。
以上になります。
