【AWS】試験を受けた結果不合格になりました。
先日、試験を受けました。
総合評価は57%でした。
1.0 Designing highly available, cost-efficient, fault-tolerant, scalable systems: 57%
2.0 Implementation/Deployment: 66%
3.0 Data Security: 45%
4.0 Troubleshooting: 75%
データセキュリティが特に弱いですね・・・。
試験中に失敗したなと思ったのはEC2のAMIの種類やIAMポリシーの種類などを調べなかった事です。
問題の中には、あるAMIで動いているEC2インスタンスを停止した場合データがどうなるか？適切な保存方法などの問題がありました。これらは各AMIを調べて、EBS-blockedインスタンスなのか、instance store-blockedインスタンスなのかを知っていれば簡単に答えられる問題です。
IAMポリシーも同じで、新規でIAMユーザを作成したときに、開発者に適用する権限はどれか？というような問題がでたので付与できる権限の種類などを一通りさらっておけばこちらも簡単に答えられる問題です。
どちらもブラックベルトの資料の中に詳しく書いてある内容だと思うので（少なくともEC2のAMIの一覧は書いてあった気がします）これらの読み込みが足りないと思いました。
大体2週間くらいで勉強した内容は以下となります。
こちらの本を3回ほど読みました。
最初に1回通しで読み、次に各単語を知らべながらもう1回よみました。
模擬試験を受けた後に読み直すことで、ここに書いてあることはこの部分を指していたのかと気づかされることもありました。
試験直前には章末問題を読んで解いたりしました。
AWSの各サービスの内容でよく問われる部分がコンパクトにまとめられていて、読みやすいですし、この本で大体のサービスを把握したことによって、ほかのAWSの各種資料が読めるようになりますし、試験中の問題にも大体答えられます。
ただ、この本だけでは少し踏み込んだ内容の問題やユースケース問題に対応できない部分があると思います。
なのでAWS公式の各種資料を追加で読み込むのが大事であると思いました。
ブラックベルトと呼ばれる資料スライドです。
スライドの内容は合格対策本を読むと大体の内容がわかるようになります。
サービス別資料の特に試験で出てきやすいサービスについての資料はすべて目を通したほうが良いです。
合格本で説明されたサービスの特徴や、それに付随したユースケースの説明がとても役に立ちます。
私はこれを前日に1度読んだだけだったため、内容の把握をし切れていませんでした。
スライドとブラックベルトの資料を交互に読んで理解を深めるのは必須だと思いました。
ちなみに、私は今回AWSのサービスを実際に触らなかったのですが、ここもできれば触ったほうがいいと思います。
実際にどんなUIでどんな風に構築していくのかというようなことをわかっていたほうが絶対に有利です。
再試験は14日間は受けられないと書かれていました。
再試験を受けるかまだ分かりませんがチャンスがあれば挑戦したいです。
【AWS】模擬試験を受けてみる＆試験対策
模擬試験をうけてみました。
正確には模擬試験は一度、勉強を始める前にうけており、今日は再度問題を見直した感じです。
問題は全部で20問。内容は公開が禁止されているので書きませんが、今回見直してみた結果です
自信をもって答えられた問題 5問
問題は理解できたが答えの自身がない問題 6問
問題が理解できない、出てきた単語がわからない問題 9問
でした。
ダメですね。
明日はわからなかった問題を復習しつつ、ブラックベルトを読み進めていきます。
【AWS】途中経過と予定
今回でAWS試験対策本のまとめが一通り終了しました。
試験対策本は一度通しで読んだ1回と今回のまとめのために再度読み直した1回で通算2回読みました。
理解不足のため、まとめられていない場所や、間違っている場所があると思います。
特に、ELB,AutoScaling,SQS,SWF,Route53のあたり（思いっきりインフラ回りですね・・・）があやふやなまま進んだので、そこは重点的に見直したいと思います。
基本自分のまとめメモを貼っただけなので、ブログとして読める状態になっていないこともあり、改めて記事と本を読み直します。記事は随時更新していきます。
今後の予定
3月15日にAWSソリューションアーキテクトアソシエイトの受験申込をしました。
それまでに、もう一度対策本を読み直したいと思います。
特に補足として当時は稼働していなかったが現在稼働中のサービスや料金形態を調べたいと思います。
さらに、一度模擬試験を受けたいと思います。
模擬試験は問題文を掲載することは禁止されているため、理解できた問題と理解できなかった問題から自分の弱点をしり、補足していく予定です。
【AWS】EC2の料金モデル
オンデマンドインスタンス
EC2インスタンスのデフォルトの課金方式
EC2インスタンスが起動している時間だけ1時間単位で支払いが発生する
長期契約は不要
必要な時に必要なだけEC2インスタンスを利用することでコストを抑え、負荷の軽減ができる
オンデマンドインスタンスはリージョン、インスタンスタイプ、OSなどで料金が変動する
開発、検証環境、AutoScalingで増減するサーバなど常時稼働はしないサーバに向いている課金形態
リザーブドインスタンス
1年あるいは3年の長期契約を結ぶことにより、オンデマンドインスタンスよりも割安でEC2インスタンスやRDSインスタンスElasticCacheノードやRedShiftノードを利用できる課金形態
RI（ReservedInstance）と呼ばれる
DynamoDBやCloudFrontなどのキャパシティを事前に予約する事で同様に割引できる方式があるが、こちらはリザーブドキャパシティと呼ばれる
長期間動作しつづけるサーバ向け
料金の割引だけでなく、ITリソースの予約（リザーブ）にもなり、いつでも確実に起動できるメリットもある
スポットインスタンス
入札形式のEC2インスタンスの利用・支払い方式で需要と供給のバランスによって決まるスポット価格を入札価格が上回るとEC2インスタンスを利用できます
スポット価格はAZ、インスタンスタイプ、OSによって設定されている
需要と供給のバランスによるが、最大でオンデマンドの90%近い割引価格になる
入札価格がスポット価格を上回るとインスタンスが起動し、利用できる
入札価格をスポット価格が上回るとターミネート（終了）される
そのため、いつ、突然終了してもいいように内部のデータを不揮発性のストレージに書き出しておく必要がある
スポット価格の高騰によってターミネートされた場合、最後の1時間分の利用料金は発生しない
【AWS】AWSサービスのプロビジョニング、デプロイ、管理構成
CloudForation
プロビジョニングサービス
テンプレートと呼ばれる設定ファイルに沿ってAWSサービスのプロビジョニングを行う
テンプレートをもとにプロビジョニングされたリソースの集合をスタックと呼ぶ
スタック単位のリソースの更新、削除が可能
ある時点のスタックを定義するテンプレートや現時点のスタックを定義するテンプレートなど
テンプレートのバージョン管理ができ、インフタストラクチャをソフトウェアのようにコード化、バージョン管理できる
CloudFormer
テンプレートを作成するツール
AWSが提供しているサンプルテンプレートを利用者が編集して作成するが
CloudFormerを利用することで利用者のアカウントで現在利用されているAWSリソースを元にしてテンプレートを作成する事ができる
Elastic Beanstalk／OptWorks
Elastic Beanstalk
デプロイツール
開発者が自身で開発環境をAWS上に構築しアプリケーションをデプロイする事ができる
構築可能なAWSリソースはELB、EC2、S3、RDSなど
ElasticBeanstalkでアプリケーションのバージョンを管理でき既存の環境を以前のバージョンに戻すなどができる
OptWorks
AWS上のアプリケーションサーバの構成管理ツール
ELBやEC2を作成し、そのあとにChefのレシピを実行してソフトウェアのインストールや設定を自動化できる
【AWS】DNSとコンテンツ配信
エッジロケーション
リージョン、AZ以外にエッジロケーションと呼ばれるデータセンタが世界に50か所以上ある
ここではRoute53、CloudFront、AWS WAFなどが動作している
Route53
マネージド型のDNSサービス
53番ポートを利用するためRoute53と名づけられた
ゾーン・ドメイン情報を登録すると4か所のエッジロケーションに登録され、エンドユーザに最も近いDNSサーバが応答してくれる
ELBでは実現できないリージョンレベルの負荷分散や冗長構成を実現できる
加重ラウンドロビン
各レコードに重み付けをし、ある名前に対するクエリに指定された比率で異なる値を応答する
複数リージョンで世界的にサービス展開しているコンテンツなどを想定
クライアントが接続してたとき、レコードの対してレイテンシーが小さくなるリージョンのELBのDNSを返す事ができる
位置情報ルーティング
クライアントのIPアドレスをもとに地理データベースでクライアントの接続元地域を特定し、地理的に近いレコードの値を返す
特定のコンテンツを地理情報ルーティングを利用して特定の地域のみに配信することもできる
CloudFlont
CDNサービス
S3バケットやEC2インスタンス、ELB、またはオンプレのサーバなどをオリジンサーバとし、
格納されているコンテンツのキャッシュをエッジロケーションに格納することでレイテンシーを小さくすることができる。
大量のアクセスがエッジサーバに分散されることで、オリジンサーバの負荷が減少リソースを削減する事ができる
【AWS】AWSにおける拡張性と分散並列処理
オンプレミス環境でお互いのIPアドレスを登録するなど密接につながっている構成を密結合と呼ぶ
AWSでは機器に障害が起きた場合、即座に自動で危機を交換できる伸縮自在性を大事にしているので密結合はいろいろな面で不便である
なので、できるだけ疎結合になるように構成を行う
ELB
Elastic Load Nalancing
マネージド型の負荷分散サービス
受信したトラフィックを配下のEC2インスタンスに分散する役割を持つ
複数のAZにまたがって負荷分散できる
EC2インスタンスのヘルスチェックを行っており、異常を検知したEC2インスタンスにはトラフィックを送信しない
マネージド型サービスなので高負荷時は自動スケーリングする
自動スケーリングするので接続するときは基本的にはドメイン名でないとならない
SSLのオフロード→SSL通信をしたいとき、ELBに証明書を設置することで配下のEC2インスタンスすべてに接続できる
アクセスログ記録機能があり、S3バケットなどに送って記録する事が可能
Connection Draining→EC2インスタンスをELB配下から切り離すとき、新規のトラフィックは送信しないように、すでに処理中だったら終わるまで待機するようになる。
スティッキーセッション→接続認証ができたらそのクライアントとEC2インスタンスを紐づけるセッションを用意するこで、別EC2インスタンスに接続して再度認証手続きが発生するのを防ぐ
ただしスティッキーセッションを利用すると密結合化するため（認証が通ったEC2を覚えておかなければならないため）セッション情報を別な場所（ElastiChace等）に保存するなどしてEC2をステートレスな状態に保つ必要がある
負荷分散と並列処理
あるインスタンスの性能不足を場合、以下の方法をとることで解消できる
スケールアップ→PCの性能をアップ
スケールアウト→同じ性能のPCを用意して並列処理する
スケールアップはサーバーが1台しかない業務を一旦停止する必要がある
さらに、ハード性能の限界があるため頭打ちになることがある
ということで高負荷時の負荷分散としてスケールアウトしやすい構成をつくる
Auto Scaling
AWSのベストプラクティスとして伸縮自在な構成を組むのに必要
EC2でAutoScalingグループを作成して設定に従って自動的にEC2インスタンスの数を増減できる
CloudWatchのアラームなどをトリガーにして実行可能
→AutoScalingについてもうちょっと深堀が必要
SQS
Simple Queue Service
マネージド型のメッセージキューサービス
とあるパッチ処理を複数のEC2で並列で処理をする場合、EC2インスタンス同士がつながっていると密結合となり伸縮性がなくなってしまう
間にSQSを挟む事でこの問題を回避できる
SWF
Simple Workflow
マネージド型のタスクコーディネータ
商品の発注・請求処理のワークフローのような
重複が許されない厳密に1回限りで順序性が求められる処理のコーディネータとして利用する
