More than 5 years have passed since last update.

AWS認定ソリューションアーキテクト- アソシエイトレベル勉強記（１）

Last updated at 2013-07-04Posted at 2013-07-04

何回シリーズになるか分かりませんが、資格合格を目指してAWSについて勉強していきたいと思います。

必須で抑えておくべきAWSサービス

大変参考になったHP

http://dev.classmethod.jp/etc/how-to-get-a-certification-aws-architect-associate-level/

AWSは「高い可用性」と「高いセキュリティ」と「高い耐障害性」をどのように実現しているか、また、自分で実現するにはどうしたら良いか確認する問題が出る

Amazon EC2：コンピューティング
Amazon VPC：仮想ネットワーク
Amazon S3：ストレージ
IAM：アカウント認証
Auto Scaling：スケーリング
Elastic Load Balancing：ロードバランサー
Amazon EBS：ディスク
Amazon Route 53：DNS
Amazon CloudFront：コンテンツ配信
Amazon RDS：データベースサービス
Amazon SQS：キューイング
Amazon SNS：メッセージング

可用性のあるシステム構成とは

大変参考になったHP

http://dev.classmethod.jp/cloud/aws/high-availability-on-aws/

availability-zone
EC2はAWSから強制的に再起動を求められたりする。
仮想サーバのインスタンスを稼動させる物理ロケーションを明示的に指定できる
リージョンの中に、複数のAZ（データセンター）が存在している
- AZが異なると、違うデータセンター（地理的に）にマシンが設定されている
- AZ間の通信は高速回線
- リージョン間はインターネット通信
Step1.非AZ体制の場合
- 障害耐性や冗長化、負荷分散、オートスケール等の機能は完全に割り切ったミニマムなVPC構成
- VPCの中には、サブネットを2つ作成する
  - 上側のサブネットは、インターネットとやり取りするため「public subnet」
  - アプリケーションサーバはインターネットとやり取りをするため、このpublic subnetに配置する
  - ユーザからのリクエストを受け付ける為に、Elastic IPによってグローバルIPを付与します。
  - EBSを使用している
    * アプリケーションのデータファイルや、インストールするアプリケーション自身を配置するため
  - 下側のサブネットは、インターネットからは遮断
    - 内部のネットワークとのみやりとりをするため「private subnet」と呼びます。
    - DBサーバはアプリケーションサーバからアクセスされるだけなので、private subnetに配置
- DBが落ちたら、システムは正常稼働を続けられません。アプリサーバが落ちても同様
Step2. HA体制の場合
- AZ丸ごと落ちてもシステムが止まらないよう、この2台のAPをそれぞれ別のAZに配置する。
- EC2インスタンスやAZが落ちた場合、ELBの死活監視機能によって落ちたapp-serverにはリクエストが振り分けられなくなる。
- RDSの設定においてMultiAZの設定をONにするだけで、マスターDBがあるAZとは別のAZに、スタンバイDBを起動し、レプリケーションを行ってくれるようになります。
  * この設定により、マスタDBやマスタのあるAZが落ちたとしても、自動でフェイルオーバーが起こり、システムは稼働し続けるのです。

Contents Delivery Network(CDN)

静的コンテンツ配信パターンカタログ
静的なコンテンツというのは、コンテンツをリクエストに応じて生成したりせず、完成品としてのファイルが手元にある状態
近年の静的コンテンツは、動画やARのモデリングデータ、音声等…、とにかくサイズがデカい。
Step1「EC2の自動割り当てホスト名 *2をハードコーディング」
　
Step2「EC2 + EIP」
- 複数台のインスタンス体制は組めませんので、可用性の点で問題があります。
- 過大なアクセスに耐えるために、スケールアップ作業をする場合は、その間サービスをメンテナンス停止する必要がある
Step3「EC2 + ELB」
アプリにハードコードされるのはELBのDNS名
スケールアップ時にも止まりませんので可用性問題は解決.マルチAZ体制もOK
コンテンツが管理画面からのアップロードにより次々に追加されるようなケースです。
ELB配下の全てのインスタンスに、新コンテンツを届けなければなりません。
Step4「EC2 + ELB + CloudFront」
CloudFrontによりスパイク対策は基本的にはOK
- CloudFront
- 一度アクセスされたS3のオブジェクトをエッジサーバーにキャッシュします。以降のアクセス時にはそれを利用するため、比較的容量が大きく、頻繁にアクセスされるようなコンテンツに最適
- 要するに「キャッシュ」ですので、キャッシュヒット率が悪いコンテンツ *5に対しては逆効果になったりもします。
- キャッシュの入っているサーバをエッジサーバという
- 東京リージョン内では、東京と大阪にエッジロケーション（エッジサーバが置いてある場所）
- 全世界で数十拠点あり、１つのオリジンサーバから全世界に配信することができます
Step5「EC2 + Route53」
- アプリに独自ドメインを埋め込むようにして、Route53を使ってみた。
- Route53
  - DNSサーバ（IP⇒URL）
Step 6「EC2 + ELB + CloudFront + Route53」
Step7「S3 + CloudFront + Route53」
- 静的ファイルの場合は、S3を利用すると安い