何回シリーズになるか分かりませんが、資格合格を目指して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に配置
- 上側のサブネットは、インターネットとやり取りするため「public subnet」
- DBが落ちたら、システムは正常稼働を続けられません。アプリサーバが落ちても同様
-
Step2. HA体制の場合
- AZ丸ごと落ちてもシステムが止まらないよう、この2台のAPをそれぞれ別のAZに配置する。
- EC2インスタンスやAZが落ちた場合、ELBの死活監視機能によって落ちたapp-serverにはリクエストが振り分けられなくなる。
- RDSの設定においてMultiAZの設定をONにするだけで、マスターDBがあるAZとは別のAZに、スタンバイDBを起動し、レプリケーションを行ってくれるようになります。
- この設定により、マスタDBやマスタのあるAZが落ちたとしても、自動でフェイルオーバーが起こり、システムは稼働し続けるのです。
- この設定により、マスタ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を利用すると安い
AWS試験全体について
http://dev.classmethod.jp/etc/how-to-get-a-certification-aws-architect-associate-level/
http://www.seeds-std.co.jp/seedsblog/1055.html
上記ページを読んでいて気になったポイントを上げます。
-
疎結合
- AWS社が提供するサービス/プロダクトの数と同時多発的にアップデートされる機能は、彼らが社内で疎結合なプログラミングを行っているからだと思います。
-
ステートレス
- サーバが落ちてしまったら、ユーザが入力中の情報が消えて無くなってしまいます。
- 状態を保持したくないので、クラスタ化されたElastiCacheに保存します。これで負荷に応じてEC2インスタンスをいくらでも増減させることができます。
-
推奨のサーバ構成
- Route53+ELB+EC2x2+ElastiCachex2+RDSMultiAZ/DynamoDB+S3
- ElastiCacheはインメモリなのでRDSよりも負荷に強いです。
- RDSはMultiAZ指定して、同期レプリケーションと自動フェイルオーバーによる早期復帰を実現します。
- DynamoDBであればIOPSを指定して高速なI/O性能を使うことが出来ます。
-
分散環境
- 読み取り一貫性と結果整合性
- 「更新はそのうち全体に反映される」
- １つのファイルをアップロードすると順次分散用のコピーが始まります。これにより障害時にファイルが消える確率を最小化することができます。
- 常に最新を表示する必要がないデータを扱う用途にはピッタリ
- ロックやトランザクション処理は行われない
課題
- Route53について調べておく
- Amazon VPCについて