syntax

2014年1月27日月曜日

AWS全体構成を図にした

構成図

enter image description here

今現在ステージング環境をこの構成で動かしています。
最初この構成内のサービスの機能や役割についてだらだらと書いていたら、やたらかったるい長文になってしまったので書き直しました。
思う事がある所だけ書き留めておきます。

VPC環境下に構築する

用意されたAWSのアカウントでログインするとすでにVPCが設定されていたのでそのままVPC内に作ります。
サブネットもアベイラビリティゾーンA(AZ-A),AZ-Bでそれぞれ1つずつ作られてたのでそのまま使用します。
WEB、DBという用途役割でのサブネットは作りません。(細かいネットワークアドレスでの制御等はしないと思うので)

セキュリティーグループ(SG)は用途役割に応じて作成する

WEB,DB,ADMINといった大体の用途役割別にSGをつくりインスタンスを属させます。複数のSGに属することも可能ですが、この案件ではそうしません。
セキュリティーグループ間の通信は下記のような簡単なパケットフィルタリングで管理します。

staging-appsグループはstaging-proxyグループからくるtcp80(nginx)のパケットは受け入れる。

staging-dbグループはstaging-appsとstaging-backgroundグループからくるtcp3306(mysql),tcp6379(redis)のパケットは受け入れる。

AZ-Aにインスタンスを寄せる

インスタンスをA,B両方に配置して耐障害性を高めるのが推奨かと思いますが、あえてAZ-Aに寄せました。
どうもアプリサーバとDBサーバがA,Bでまたぐ場合、レスポンスが遅くなる問題が頻発するのです。
解決もできないし一旦あきらめました。AZ-Aが崩壊しないことを祈りながら運用することにします。
AZ-Aが全く使えなくなった場合は、その時点からAZ-Bにリストアすることを検討します。

インスタンスのマシンイメージ,DBのバックアップはS3に確保されてるから大丈夫として、mongodb,redisのデータはAZ-Aにしか存在しないので、
これらはAZ-A以外のところにバックアップを退避させておきます。

Written with StackEdit.

0 件のコメント:

コメントを投稿