ようへいの日々精進XP

よかろうもん

2018 年 08 月 26 日 (日)

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

ジョギング

  • 香椎浜 x 2 周
  • 右足の股関節から太腿に強い張り
  • 引き続き, 暑さが堪える...

日課

  • (腕立て x 50) x 3

九州新喜劇

blogs.yahoo.co.jp

九州新喜劇を観てきた. テレビで見るのと違ってすごい熱が伝わってきて本当に心から笑えた. 奥さんも元気よく笑っていて, 芸人さん達に本当に感謝.

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

公開されているサンプル試験問題を解く. なぜ, その答えになるのかをちゃんと理解する必要がある. 尚, 今回は英語版のサンプル問題である為, 翻訳には Google 翻訳を利用している.

Q7. DynamoDB において, 別プロセスからの書き込みを保護する方法

設問

Your web application reads an item from your DynamoDB table, changes an attribute, and then writes the item back to the table. You need to ensure that one process doesn't overwrite a simultaneous change from another process.

Webアプリケーションは, DynamoDBテーブルから項目を読み取り, 属性を変更して, その項目をテーブルに書き戻. あるプロセスが別のプロセスからの同時変更を上書きしないようにする必要がある

How can you ensure concurrency?

A) Implement optimistic concurrency by using a conditional write.
B) Implement pessimistic concurrency by using a conditional write.
C) Implement optimistic concurrency by locking the item upon read.
D) Implement pessimistic concurrency by locking the item upon read.

どのようにして並行性を保つか.

A） 条件付き書込みを使用して楽観的な同時実行を実装する
B） 条件付き書込みを使用して悲観的な同時実行を実装する
C） 読み込み時に項目をロックすることにより, 楽観的同時実行を実装する
D） 読み取り時に項目をロックすることにより, 悲観的な並行性を実装する

解答

A) Implement optimistic concurrency by using a conditional write. (条件付き書込みを使用して楽観的な同時実行を実装する)

メモ

解答より引用.

Optimistic concurrency depends on checking a value upon save to ensure that it has not changed. Pessimistic concurrency prevents a value from changing by locking the item or row in the database. DynamoDB does not support item locking, and conditional writes are perfect for implementing optimistic concurrency.

  • 楽観的な並行性は, 保存時に値をチェックして変更されていないことを確認することに依存する
  • 悲観的な並行処理は, データベース内の項目または行をロックすることによって値が変更されることを防ぐ
  • DynamoDB はアイテムロックをサポートしておらず, 条件付き書き込みは楽観的同時実行の実装には最適である

楽観的ロックと悲観的ロックの違いについて.

  • https://qiita.com/NagaokaKenichi/items/73040df85b7bd4e9ecfc より引用させて頂いた
  • 楽観的ロック (楽観的排他制御)
    • データそのものはロックせず, 更新対象のデータがデータ取得時と同じ状態であることを確認してから更新することでデータの整合性を保証する方式
  • 悲観的ロック (悲観的排他制御)
    • 更新対象のデータを取得する際にロックをかけることで, 他のトランザクションから更新されないようにする方式
    • DynamoDB はアイテムロックをサポートしていない = 悲観的ロックは出来ない (ということで良いのかな？？)

DynamoDB の条件付き書き込みについて.

Q8. SQS や SNS を利用したアプリケーションの実装

設問

Your application triggers events that must be delivered to all your partners. The exact partner list is constantly changing: some partners run a highly available endpoint, and other partners’ endpoints are online only a few hours each night. Your application is mission-critical, and communication with your partners must not introduce delay in its operation. A delay in delivering the event to one partner cannot delay delivery to other partners.

  • アプリケーションは, すべてのパートナーに配信する必要があるイベントをトリガーする
  • 正確なパートナーリストは絶えず変化している
  • 一部のパートナーは可用性の高いエンドポイントを実行し, 他のパートナーのエンドポイントは毎晩わずか数時間オンラインである
  • あなたのアプリケーションはミッションクリティカルであり, パートナーとのコミュニケーションが操作を遅らせてはならない
  • あるパートナーにイベントを配信するのが遅れても, 他のパートナーへの配信が遅れることはない

What is an appropriate way to code this?

A) Implement an Amazon SWF task to deliver the message to each partner. Initiate an Amazon SWF workflow execution.
B) Send the event as an Amazon SNS message. Instruct your partners to create an HTTP. Subscribe their HTTP endpoint to the Amazon SNS topic.
C) Create one SQS queue per partner. Iterate through the queues and write the event to each one. Partners retrieve messages from their queue.
D) Send the event as an Amazon SNS message. Create one SQS queue per partner that subscribes to the Amazon SNS topic. Partners retrieve messages from their queue.

これをコード化する適切な方法はどれか？

A） 各パートナーにメッセージを配信する Amazon SWF タスクを実装して, Amazon SWF ワークフローの実行を開始する
B） イベントを Amazon SNS メッセージとして送信する. パートナーに HTTP を作成するように指示する. HTTP エンドポイントを Amazon SNS トピックに登録する
C） パートナーごとに 1 つの SQS キューを作成する. キューを繰り返し, 各イベントにイベントを書き込む. パートナーはキューからメッセージを取得する
D） イベントを Amazon SNS メッセージとして送信する. Amazon SNS トピックにサブスクライブするパートナーごとに 1 つの SQS キューを作成する. パートナーはキューからメッセージを取得する

解答

D) Send the event as an Amazon SNS message. Create one SQS queue per partner that subscribes to the Amazon SNS topic. Partners retrieve messages from their queue. (イベントを Amazon SNS メッセージとして送信する. Amazon SNS トピックにサブスクライブするパートナーごとに 1 つの SQS キューを作成する. パートナーはキューからメッセージを取得する)

メモ

解説より引用.

There are two challenges here: the command must be “fanned out” to a variable pool of partners, and your app must be decoupled from the partners because they are not highly available. Sending the command as an SNS message achieves the fan-out via its publication/subscribe model, and using an SQS queue for each partner decouples your app from the partners. Writing the message to each queue directly would cause more latency for your app and would require your app to monitor which partners were active. It would be difficult to write an Amazon SWF workflow for a rapidly changing set of partners.

  • パートナーのさまざまなパートナーにコマンドを fanned out する必要がある
  • アプリケーションは高可用性ではない為, パートナーから切り離さなければならない
  • コマンドを SNS メッセージとして送信すると, そのパブリケーション/サブスクライブモデルによって fanned out が達成される
  • パートナーごとに SQS キューを使用することで, パートナーからアプリが切り離される
  • 仮に, 各キューにメッセージを直接書き込とアプリケーションは, どのパートナーがアクティブであるかをアプリケーションに監視させる必要がある
  • 急速に変化するパートナーのために Amazon SWF ワークフローを作成するのは難しい

Q9. CloudFormation のスタック数が上限に達したけど...どうする？

設問

You have reached your account limit for the number of CloudFormation stacks in a region

リージョンのCloudFormationスタック数のアカウント制限に達した.

How do you increase your limit?

A) Use the AWS Command Line Interface.
B) Send an email to limits@amazon.com with the subject “CloudFormation.”
C) Use the Support Center in the AWS Management Console.
D) All service limits are fixed and cannot be increased.

どのようにして制限を増加させるか.

A） AWS コマンドラインインターフェイスを使用 する
B） limits@amazon.com に件名「CloudFormation」で電子メールを送信する
C） AWS 管理コンソールでサポートセンターを使用する　
D） すべてのサービス制限は固定されており, 増額することはできない

解答

C) Use the Support Center in the AWS Management Console. (AWS 管理コンソールでサポートセンターを使用する)

メモ

解説より引用.

The Support Center in the AWS Management Console allows customers to request limit increases by creating a case.

AWS Management Console のサポートセンターでは, ケースを作成することによって制限の増加をリクエストすることが出来る.

CloudFormation の各種制限.

Q10. アプリケーション層とデータベース層で疎通が取れないのはなんでや？

設問

You have a three-tier web application (web, app, and data) in a single　Amazon VPC. The web and app tiers each span two Availability Zones, are in separate subnets, and sit behind ELB Classic Load Balancers. The data tier is a Multi-AZ Amazon RDS MySQL database instance in database subnets. When you call the database tier from your app tier instances, you receive a timeout error.

  • 1 つの Amazon VPC に 3 層の Web アプリケーション （Web 層, アプリケーション層, データ層） がある
  • Web 層とアプリケーション層はそれぞれ 2 つの Availability Zone にまたがり, 別々のサブネットにあり, ELB Classic Load Balancerの背後に位置する
  • データ層は, データベースサブネット内の複数 AZ Amazon RDS MySQL データベースインスタンス
  • アプリケーション層インスタンスからデータベース層を呼び出すと, タイムアウトエラーが発生する

What could be causing this?

A) The IAM role associated with the app tier instances does not have rights to the MySQL database.
B) The security group for the Amazon RDS instance does not allow traffic on port 3306 from the app instances.
C) The Amazon RDS database instance does not have a public IP address.
D) There is no route defined between the app tier and the database tier in the Amazon VPC.

これを引き起こす原因は何か？

A） アプリケーション層インスタンスに関連付けられた IAM ロールには, MySQL データベースに対する権限がない
B） Amazon RDS インスタンスのセキュリティグループは, アプリケーションインスタンスからのポート 3306 のトラフィックを許可していない
C） Amazon RDS データベースインスタンスにパブリック IP アドレスがない
D） Amazon VPC のアプリケーション層とデータベース層の間に定義された経路がない

解答

B) The security group for the Amazon RDS instance does not allow traffic on port 3306 from the app instances. (Amazon RDS インスタンスのセキュリティグループは, アプリケーションインスタンスからのポート 3306 のトラフィックを許可していない)

メモ

解説より引用.

Security groups block all network traffic by default, so if a group is not correctly configured, it can lead to a timeout error. MySQL security, not IAM, controls MySQL security. All subnets in an Amazon VPC have routes to all other subnets. Internal traffic within an Amazon VPC does not require public IP addresses.

  • セキュリティグループは全てのトラフィックを既定でブロックする為, 正しく構成されていないと, タイムアウトエラーが発生する可能性がある
  • IAM ではなく MySQL のセキュリティが MySQL のセキュリティを制御する
  • Amazon VPC の全てのサブネットには, 他のすべてのサブネットへのルートがある
  • Amazon VPC 内の内部トラフィックにはパブリック IP アドレスは不要

ﾌﾑﾌﾑ.