ようへいの日々精進XP

よかろうもん

2018 年 08 月 17 日 (金)

日々 2018_ジョギング 今日の AWS

ジョギング

  • 香椎浜 x 2 周
  • 涼しくてだいぶん走りやすかった...けど, やっぱり汗だくにはなった

日課

  • 引き続き, 腰と腰に痛みがあるので止めといた

父の 70 回目の誕生日

プレゼントに Web カメラを送ったら, 早速, 喜んでくれて接続テストがてら zoom.us した. 顔が見れるのが良い.

JAWS-UG 福岡もくもく会 #5

近日中に Developer アソシエイトとか受けるのでその勉強をした.

その後, 懇親会で俺たちの「家康」で.

もくもくの後, ワイワイで楽しい会だった. 次は再来週くらいを考えているけど, ま, 無理の無い程度にゆるーくなが～く続けられればなあ.

今日の AWS ~ AWS 認定デベロッパー – アソシエイトレベルサンプル試験を解く (2) ~

公開されているサンプル試験問題を解く. なぜ, その答えになるのかをちゃんと理解する必要がある.

Q4. S3 仕様について

設問

...Amazon S3 で US‐STANDARD リージョンにオブジェクトを格納したところ、正常に格納できたという確認メッセージ を受信しました。その直後に、別の API を呼び出して、このオブジェクトを読み込もうとしました。しかし S3 から、オブ ジェクトが存在しないというメッセージが返されました。どのような原因が考えられますか?

A. US‐STANDARD で結果整合性を使用していて、バケットでオブジェクトが読み込み可能になるまでに時間がかかることがある。
B. Amazon S3 のオブジェクトは、第 2 のリージョンに複製されるまでは表示されない。
C. US‐STANDARD では、新しいオブジェクトが読み込み可能になるまでに 1 秒の遅延が課されている。
D. バケットのオブジェクト制限を超えたため。この制限を増やすと、オブジェクトが表示される。

正答

  • A (US‐STANDARD で結果整合性を使用していて、バケットでオブジェクトが読み込み可能になるまでに時間がかかることがある。)

メモ

  • US‐STANDARD リージョンは新規オブジェクト作成については結果整合性 (書き込み後の読み込み整合性もサポートされている)
  • 他のリージョンについては, 新規オブジェクト作成については書き込み後の読み込み整合性となる

Q5. CloudFormation の仕様について

設問

リージョンの CloudFormation スタックの数についてのアカウント制限に達しました。制限を増やすには、どうすればよいですか?

A. API を呼び出す。
B. AWS に連絡する。
C. マネージメントコンソールを使用する。
D. 制限を増やすことはできない。

正答

  • B (AWS に連絡する。)

メモ

  • CloudFromation のスタック数の上限 200 個
  • AWS サポートに上限緩和申請を行う

Q6. DynamoDB の仕様について

設問

DynamoDB について正しいことを述べている文はどれですか?（正解を 2 つ選択）

A. DynamoDB では、ペシミスティックロックモデルを使用する。
B. DynamoDB では、楽観的オプティミスティック同時実行制御を使用する。
C. DynamoDB では、一貫性を実現するために条件付き書き込みを使用する。
D. DynamoDB では、読み込み時の項目アクセスを制限する。
E. DynamoDB では、書き込み時の項目アクセスを制限する。

正答

  • B (DynamoDB では、楽観的オプティミスティック同時実行制御を使用する。)
  • C (DynamoDB では、一貫性を実現するために条件付き書き込み (Consistent Read) を使用する。)

メモ

  • AWS Black Belt Online Seminar 2017 Amazon DynamoDB
  • DynamoDB の結果整合性モデル
    • Write
      • 少なくとも 2 つの AZ で書き込み完了が確認された時点で Ack となる
    • Read
      • デフォルト
        • 結果整合性のある読み込み
        • 最新の書き込み結果が即時読み取り処理に反映されない可能性がある
      • Consistent Read オプションをつけた場合
        • GetItem, Query, Scan では強力な整合性のある読み込みオプションが指定可能
        • Read リクエストを受け取る前までの Write が全て反映されたレスポンスを保証
        • Capacity Unit を 2 倍消費する

Q7. EBS-backed インスタンスと Instance store-backed インスタンスの違い

設問

Amazon EBS‐backed インスタンスと Instance store‐backed インスタンスの違いは何ですか?

A. Instance store‐backed インスタンスは停止と再開ができる。
B. Auto Scaling には Amazon EBS‐backed インスタンスを使う必要がある。
C. Amazon EBS‐backed インスタンスは停止と再開ができる。
D. Virtual Private Cloud には EBS‐backed インスタンスが必要である。

正答

メモ

こちら より引用.

すべての AMI が Amazon EBS-Backed と Instance Store-Backed のいずれかに分類されます。前者は、AMI から起動されるインスタンスのルートデバイスが、Amazon EBS スナップショットから作成される Amazon EBS ボリュームであるということです。後者は、AMI から起動されるインスタンスのルートデバイスが、Amazon S3 に格納されたテンプレートから作成されるインスタンスストアボリュームであるということです

さらに, こちら から引用.

Amazon EC2 のサービス開始当初は、すべての AMI が「Amazon EC2 インスタンスストア backed」でした。つまり、AMI から起動されるインスタンスのルートデバイスは、Amazon S3 に格納されたテンプレートから作成されるインスタンスストアボリュームです。Amazon EBS の導入後は Amazon EBS を基にした AMI も導入されました。つまり、AMI から起動されるインスタンスのルートデバイスが、Amazon EBS スナップショットから作成される Amazon EBS ボリュームであるということです。

ﾌﾑﾌﾑ.