WIP : DVA取得に必要(と思える)単語集

目的

講義や問題で出てきた単語/用語をまとめておく
※「勉強中」のため不定期追加。

ものくっそ自分の試験メモ用です。

書いている人

のらくらSE.多分DVAの開発系の情報が埋まっていくと期待してます。
以下の資格は取れたのでそれらの範疇のものはあまり書かないと思います。

• SAA取得済み
• SOA取得済み

だんだんわけわかんなくなったのでそのうち清書予定...

単語集じゃぁなくなっちゃったよ（ーー；

ElastiCache

キャッシュ戦略

AWSというよりは『キャッシュの使用方法をを考慮してアプリケーションを設計せよ。』とのこと。

• 遅延書き込み(lazy load) : 公式 - キャッシュ戦略
• 書き込みスルー(Write Through) : 公式 - キャッシュ戦略

コーディング

• 指数バックオフ : 簡単に言うとAPIコール時に失敗したら倍々でwaitしてコールすること。（何度もすぐにコールしないということ)

S3 & Glacier

• S3 Select : 公式 or 一般
• 名前にランダムプレフィックスを使わなくても早い(試験は未追従?): 公式

Elastic Beanstalk

実は実際はCloudFormationで構築されている

ElasticBeanstalkは実際のDeply時はCloudFormationと連携を行い、CloudFormationで環境をDeplyomentしている。

デプロイメントポリシー(all at onceって何?)

• Doc
  • 公式 - デプロイメントポリシーと設定
  • 公式 - AWS Elastic Beanstalk 環境へのアプリケーションのデプロイ
• デプロイメント種別
  • All at once(1回にすべて) : 一気に環境を更新する
    • メリット : 最も早い展開方式.
    • デメリット : 更新する際にダウンタイムが発生する。
  • Rolling(ローリング) : 一度にいくつか対象を分けて更新をする
    • メリット : ダウンタイムがほぼない。
    • デメリット : update中は古いinstanceにリクエストが飛ぶ
  • Rolling with additional batch(追加バッチとローリング) : 本番用に一番さそうなパターン
    • 流れ
      • Update前にあらかじめ最新のinstanceが構築され、その後に既存のinstanceをRollingする。
      • 最後、Rollingが終了したら初めに構築したinstanceを削除する
    • メリット
      • キャパシティ(instance数)を維持した形でRollingできる
    • デメリット
      • 一時的にでもinstanceが増えるため、費用が掛かる。ここテストにでるかも。でない？
  • Immutable(変更不可) : 本番用に適したパターン。失敗した場合ロールバックもされる【要調査】
    • 流れ
      • 新たに新しいinstanceのASGを作成する
      • その後、既存のASGに新しいASGのinstanceを移動させる。
      • 移動後、既存のinstance(versionが古い)を削除する
    • メリット
      • ダウンタイムが無い。（新しいの作成=>古いの削除)
    • デメリット
      • 時間が掛かる。
      • 費用が他と比べて掛かる。
  • Blue/Green(EBの機能としては無い) : 模擬等の試験でよく見る。
    • 新たに同じ最新の環境を作成した後、切り替え(Route53等）で行う

環境タイプ(Deployment mode)

• mode
  • 単一インスタンス(single instance) : 開発用。EIPが1つ,ASGが1つ
    • EIPが1つ作成される。アプリケーションを更新するとEIPが移る。(Deploy毎にIPが変わらない？【要調査】
  • 負荷分散 : For Production. ASG,ELB,EC2(multi) & MultiAZ

.ebextensions

ElasticBeanstalkの設定ファイル。
ウェブアプリケーションのソースコードに AWS Elastic Beanstalk 設定ファイル (.ebextensions) を追加することで、環境を設定し、環境に含まれる AWS リソースをカスタマイズできます。

注意点としては、これらはElasticBeanstalkにてリソース管理するため、「環境」が削除されたらこれらも削除される【要調査】

• doc

  • 公式

• Q&A

  • Q.拡張子は?
    • A. .config
  • Q. Formatは?
    • A. JSON or YAML
  • Q. ファイルの配置する場所は?
    • A. すべての設定ファイルを .ebextensions という 1 つのフォルダ (ソースバンドルのルート) に配置します

• 設定オプション

  • Elastic Beanstalk は、環境の動作、およびその環境に含まれるリソースの設定に使用する多数の設定オプションを定義します。

アプリケーションバージョンライフサイクルの設定

• doc
  • 公式 - アプリケーションバージョンライフサイクルの設定

ElasticBeanstalkにて管理しているアプリケーションはバージョン管理されている。
Uploadする度にバージョンが1つ増える。
本バージョンは1000までが限界であり、限界まで至った場合は、更新が行えなくなる。

アプリケーションにアプリケーションバージョンライフサイクルポリシーを適用することで、制限に到達するのを回避することが出来る。

• policy種別
  • アプリケーションバージョンの制限を合計数で設定
    • バージョン合計(limit)数を規定する
  • アプリケーションバージョンの制限を期間で設定
    • 保持期間を指定する

RDS有りのElasticBeanstalk環境からRDSなしのEB環境作成概要

前述の通り、ElasticBeanstalkのリソースとして、RDSが存在している場合、「環境」を削除した場合、共に消される。
開発時は使い方次第ではそれの方が良いが、本番環境などではそれは困る。

• 順序
  • RDSのsnapshotを取得する
  • RDSのコンソールからEBで使用しているDBの削除保護の有効化を行う
  • 新規にElasticBeanstalk(新規用）を作成する。この際、RDSのリソースは含めない様にする。
  • 合わせて、既に存在する（削除保護有効化した）RDSを使用する様に設定する
  • 最後に切り替えを行う（Route53等）
  • 切り替えが成功した後、古い環境を削除する

RDS

• 基本的に「環境」(Enviornment)を削除するとRDSは削除される。実用の場合はEBとは別にRDSを立ててEBはそれと繋げるようにした方が良さそう : 一般

CodeCommit/CodePipline/CodeDeploy

CodeCommit

Githubとは違い、Private Only.

Security

• Git 認証：
  • SSHキー： AWSユーザーは、IAMコンソールでSSHキーを設定可能
  • HTTPS： AWSCLI認証ヘルパーまたはHTTPS認証情報の生成を介して実行される
    • MFA（多要素認証）を有効にして安全性を上げることが出来る
• IAM Policy :
  • User or Role でRepositoryへの操作を制限できる
• 暗号化
  • KMSを用いて暗号化を行うことが出来る
• クロスアカウントアクセス :
  • 他のAWSアカウントに対してアクセスを有効に出来る

CodeCommit Notification

CodeCommitは通知機能を持っている。
主に２種類存在するが、各々の用途は以下。
特にCloudWatch Events ruleの通知機能は規定されている

• SNS(SimpleNotificationService)
  • Masterにpushされたとき
  • Branchが削除されたとき
  • AWS以外のシステムに通知したいとき
  • Lambdaを使用したいとき
• AWS CloudWatch Events rule
  • プルリクエストの更新イベント
    • プルリクエストの作成、更新、またはクローズ時にサブスクライバーに通知します。
  • プルリクエストのコメントイベント
    • プルリクエストに誰かがコメントしたときにサブスクライバーに通知します。
  • コミットコメントイベント
    • コミットへのコメントや返信の追加時にサブスクライバーに通知します。

CodeCommit トリガ設定

Repositryに対して規定のイベント(ここは固定)をトリガにアクションを設定出来る

• アクション種別
  • SNS
  • Lambda

CodeBuild

buildspec.yml

buildの命令はコードで表現出来る。
このコードのファイルが「buildspec.yml」

CloudWatchとの連携

buildの失敗を検出してCloudWatchからアラームを出すことが出来る。

CodeDeploy

CodeDeployはアプリケーションをDeployするものである。

CodeDeploy Agentを導入しているオンプレミス環境/EC2に対してDeploymentを行う。

CodeDeployの実行先はTagで指定できる

特定のTagのKey/Valueの組み合わせ(Eg. Deplyoment/Prod)のInstanceに対して
Deploymentすることが可能

CodePipeline

見慣れてないからまずは公式抜粋。
Source変更時に実行出来るワークフローエンジンと思えば良さそう。

AWS CodePipeline は完全マネージド型の継続的デリバリーサービスで、素早く確実性のあるアプリケーションとインフラストラクチャのアップデートのための、パイプラインのリリースを自動化します。
CodePipeline は、お客様が定義したリリースモデルに基づき、コードチェンジがあった場合のフェーズの構築、テスト、デプロイを自動化します。
これにより、機能とアップデートを素早く、信頼性の高い方法で配信できます。
GitHub やお好みのカスタムプラグインなどのサードパーティ製のサービスと、AWS CodePipeline を
簡単に統合することができます

サービスロール

CodePipeLineはS3,Beanstalk等数多のリソース(サービス)を使って成り立つ。(作り次第で)
この際、CodePipeLine自体に対して各々のリソースを操作できるロールが必要となる。
これがサービスロール。（PipeLine作成時指定したら勝手に作ってくれる)

パイプライン実行プロセスの一部に対するアクセス許可は、IAM ユーザーではなく、CodePipeline に代わって動作する他のロールタイプに付与されます。サービスロールは、アカウントのリソースを使用するための CodePipeline のアクセス許可を付与する IAM ロールです。サービスロールは、CodePipeline で初めてパイプラインを作成する場合にのみ作成する必要があります。

承認プロセス

本番環境に自動で構築等を行わせない、ある特定の段階で一旦CI/CDのプロセスを止めたい。等、
「承認」のプロセスを組むことが出来る。

Cloudwatchとの連携

Amazon CloudWatch Events でパイプラインの状態の変更を検出し対応することが可能。公式

• イベント例
  • 失敗したパイプラインのイベントを作成, SNSへ通知
  • キャンセルされたステージのイベントを作成, SNSへ通知

CloudFormation

Resource

良く試験の問題集でもある様に、Resource(リソース)は必ずTemplateの中に含まれていなければならない。
ResourceとはAWS上で実際に作成される Instance,VPC,Subnet等が其れに当たる。
リソースタイプの記述形式は以下である。
リソースは数百存在するため、以下のDocumentを見ると良い。
[公式ドキュメント](http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aw s-template-resource-type-ref.html)

AWS::aws-product-name::data-type-name

以下がInstanceの例

AWS::EC2::Instance

動的にリソースは作成できない

例えば、状況に応じてInstanceリソースの作成数を変えたい。
ということはできない。
全て宣言しなければならない。

CloudFormationは大体のリソースは作成出来るが、対応していないリソースを作成するには?

カスタムリソースで対応する。
公式ドキュメント

たとえば、AWS CloudFormation のリソースタイプとして使用できないリソースを含める必要があるとします。
それらのリソースは、カスタム リソースを使用して含めることができます。
この方法により、すべての関連リソースを 1 つのスタックで管理できます。

Parameter(入力)

CloudFormationにてスタックを作成する際にこのセクションをTemplateに入れることにより、値を入力することができる。
当該セクションを入れることにより、スタックの作成/更新時に入力画面が表示される。

Eg.

• 入力したAMI名を後続のInstance生成のリソースでReferenceさせる。
• リージョンを入力させる。
• Instance Nameを入力させる。
• Descriptionを入力させる。

オプションの Parameters セクションを使用して、テンプレートをカスタマイズします。
パラメーターを使用すると、スタックを作成または更新するたびにテンプレートにカスタム値を入力できます。

Parameterは内容を規定(一般要件)することができる

入力されたParameterに対して、型、値の上限等を規定することができる。
公式ドキュメント

擬似パラメータ

AWS側にて既に規定されているパラメータ。アカウントID等が挙げられる

擬似パラメータは、AWS CloudFormation によって事前定義されたパラメータです。テンプレートでは宣言しません。
パラメーターと同じように、Ref 関数の引数として使用します。

公式ドキュメント

Mapping(マッピング)

任意の Mappings セクションでは、キーと名前付きの一連の値とが対応付けられます。
たとえば、リージョンに基づく値を設定する場合、リージョン名をキーとして必要な値を保持するマッピングを作成します。

公式ドキュメント

使い方

Documentにも書かれているが、事前にMapを作成。(Eg. Region名毎に使用するAMIのID定義等）
当該Mapを使用する際に、FindMapを用いて指定したキー(前述の擬似パラメータのRegionId等で）から値を取得できる。

OutPut(出力)

主にクロススタック参照で使用される。
例えば、S3バケットの生成をStackAで生成。StackBにて対象のS3のバケットに対してポリシー操作をするとした場合。
StackAのTemplateにてOutputを用いてS3のバケットID等をExportする。

StackBのTemplateにてExportされた情報をImportValue等を用いて参照、指定することができる。

オプションの Outputs セクションは、他のスタックにインポートする (クロススタック参照を作成)、
応答として返す (スタック呼び出しについて記述)、
または、AWS CloudFormation コンソールで表示する出力値を宣言します。
たとえば、見つけやすいバケットを作成するスタックの S3 バケット名を出力できます。

公式ドキュメント

クロススタック参照時の制限は以下

各 AWS アカウントの場合Export、名前はリージョン内で一意である必要があります。

リージョンにわたるクロス スタックの参照を作成することはできません。
同じリージョンFn::ImportValue内では、エクスポートされた値のみインポートするのに組み込み関数を使用できます。

出力では、Name プロパティ (Export に属す) の値で、リソースに依存する Ref または GetAtt 関数を使うことはできません。

同様に、ImportValue 関数に、リソースに依存する Ref または GetAtt 関数を含むことはできません。

他のスタックから参照されている出力が存在する場合は、スタックを削除することはできません。

別のスタックで参照した出力値を変更したり削除することはできません。

conditions(条件)

オプションの Conditions セクションには、エンティティが作成または設定される状況を定義する文が含まれています。
たとえば、条件を作成し、それをリソースまたは出力に関連付けることで、
条件が true の場合にのみ AWS CloudFormation がリソースまたは出力を作成するようにできます。

公式ドキュメント

条件関数

詳細はドキュメントを参照。一般的な論理式を用いることができる

Fn::And
Fn::Equals
Fn::If
Fn::Not
Fn::Or

Eg. ドキュメントの例では「Parameter」を用いて、ユーザ側にから「prod」/「test」の２択で
Deplyomentタイプを選択させる。(値維持)
その後、以下の様に条件を用いてTrue/False(prod or test)を確認

  "Conditions" : {
    "CreateProdResources" : {"Fn::Equals" : [{"Ref" : "EnvType"}, "prod"]}
  },

以降『「CreateProdResources」がTrueの場合は、リソースを作成する』などのリソース生成を行う

    "MountPoint" : {
      "Type" : "AWS::EC2::VolumeAttachment",
      "Condition" : "CreateProdResources",
      "Properties" : {
        "InstanceId" : { "Ref" : "EC2Instance" },
        "VolumeId"  : { "Ref" : "NewVolume" },
        "Device" : "/dev/sdh"
      }

※個人的にはProdの場合は、既存RDSを。Testの場合は新規作成を。
の様なCondition設定の方がしっくりきた。

AWS X-Ray

開発者は、AWS X-Ray を使用して、本番環境や分散アプリケーション (マイクロサービスアーキテクチャを使用して構築されたアプリケーションなど) 
を分析およびデバッグできます。
X-Ray を使用すると、アプリケーションやその基盤となるサービスの実行状況を把握し、
パフォーマンスの問題やエラーの根本原因を特定して、トラブルシューティングを行えます。

これを使うと何が良いの?

• 性能のボトルネックが判る
• マイクロサービスのアーキテクチャの依存関係が視覚的に判る
• リクエストの動作確認を行える
• エラーと例外が見つけられる
• SLA(定義、範囲、内容、達成目標等)を満たしているかが判る

AWS X-Rayの導入方法

1. CodeにAWS X-Ray SDKをImportする
2. X-Rayデーモンを起動する(EC2 or オンプレミスサーバ)
   3. Lambdaの場合は既にデーモンがあるため不要
   4. 各々のリソースにはAWS-Xrayへの権限を付与する
   5. LambdaはAWS X-Rayのアクティブトレースを有効にする

用語

セグメント(segment)

アプリケーションロジックを実行しているコンピューティングリソース。

サンプリング(sampring)

全部トレースされたら判りづらい！大体を見たい！という時。

効率的にトレースを行ってアプリケーションが処理するリクエストの代表的なサンプルを提供するため、X-Ray SDK によってサンプリングアルゴリズムが適用され、トレースするリクエストが決定されます。
デフォルトでは、X-Ray SDK は 1 秒ごとに最初のリクエストと、追加リクエストの 5% を記録します。

注釈

フィルタで検索したい場合はこちら。

注釈は、「フィルタ式」で使用するためにインデックス化されたシンプルなキーと値のペアです。注釈を使用して、コンソールでトレースをグループ化するため、または GetTraceSummariesAPI を呼び出すときに使用するデータを記録します。

メタデータ

メタデータは、オブジェクトとリストを含む、任意のタイプの値を持つことができるキーと値のペアですが、フィルタ式に使用するためにインデックスは作成されません。
メタデータを使用してトレースに保存するデータを記録しますが、トレースの検索用に使用する必要はありません。

SQS

標準キュー

SAAでやったから主に復習...

基本的なやつ

• SQSへのメッセージBodyは256kbまで
• 一度に受け取れるメッセージは10件まで
• メッセージの順序は保証されていない

遅延キュー

公式ドキュメント

キューは従来０秒ですぐにコンシューマから可視出来る状態である。
キューへの新しいメッセージの配信を遅らせることが出来るのが遅延キュー。
この設定を行なった場合は全てのキューに対して働く。
最大15分遅らせることが可能。

また、メッセージ毎に遅延をさせたい場合は、メッセージタイマーの DelaySeconds 値を使用する。

可視性タイムアウト

公式

キューの特定のメッセージがポーリングされた段階でそのメッセージを他のコンシューマから規定時間見えなくする。
メッセージを処理する複数のコンシューマがいた場合、これを設定することにより、
複数のコンシューマが同じメッセージに対して処理を行うことを防げる。
**最大１２時間(デフォルト30秒)**見えなくすることが出来る。

デッドレターキュー

公式ドキュメント

例えば、キューに存在するメッセージをコンシューマが処理に失敗した場合、
対象のメッセージはそのままキューに残ったままである。
その後、他のコンシューマが同じメッセージを処理する。
しかし、メッセージが原因のため同じ様に失敗する。この場合延々とこのループが続いてしまう。
これを防ぐ方法がデッドレターキューに格納する。
キュー作成時に[Use Redrive Policy]を設定するとことにより、規定回数特定のメッセージをSQSがポーリングされたら
デッドレターキューにそのメッセージを移すことができる
（「なんかこのメッセージ何回も取られてるな。変なやつだろうからデッドレターキューに移そう」って感じ）

ロングポーリング

結構問題で見る単語なんだな

公式ドキュメント

ポーリング時間を長くすることにより、SQSへのAPIコールが減る。というメリットがある。
物によるけど1秒〜20秒くらいポーリング時間を設定するのが望ましいらしい。

SQS API

• CreateQueue/DeleteQueue : キューの作成/削除
• PurgeQueue : キューの中の全てのメッセージを削除する
• SendMessage/ReceiveMessage/DeleteMessage : キューに対するメッセージの送信/受信/削除
• ChangedMessageVisibility : メッセージの可視性タイムアウトの操作(伸ばすこともできる)

Kenesis

ここは...覚えゲーで逃げる...（ーー；

• Kinesis Streams ： 大規模な低遅延でストリーミングを取り込む
• Kinesis Analytics ： SQLを使用してストリームのリアルタイム分析を実行します。(主にフィルタ部分)
• Kinesis Firehose ： S3、Redshift、ElasticSearchにストリームをロードします。

どんな感じか

数多なIoT機器、ユーザのクリックストリーム等の大量なデータをKinesis Streamで取り込む。
取り込まれたデータwpKinesis Analyticsに渡してリアルタイムでそのデータを分析する。
それらのデータをS3/RedShiftなどに送る際にKinesis Firehoseを使用して送られる。

Lambda

ベストプラクティクス

公式ドキュメント

これは覚えておいた方がいい。

Configuration

• タイムアウト : Default 3秒, MAX 900秒(15分)
• 割り当てられるメモリ : Defualt128MB, MAX 3GB

ラムダ変数

key/valueのペアのデータ。コードから直接読み取れる。
python的にはos.getenvで取得できる。

lambdaの同期/非同期呼び出し

参考

詳細は参考を見ると判るのでざっくり。

• 同期呼び出し : lambdaを直接実行する
• 非同期呼び出し : SNSトリガで間接的にlambdaを実行する(User的にはSNS実行しておーわりパターン)

lambda関数の同時実行

主に同期呼び出しの場合。

参考ページ
lambda関数は同時に複数実行が可能である。
これらの同時実行数は制限(予約)することが可能である。
もし、同時実行数を超えた場合、超えたリクエストは実行されずにスロットリングされる。

DLQ

主に非同期呼び出し（直接Lambdaを実行していない)の場合。

lambdaは関数実行が失敗した場合、2回まで際実行するする。
全ての試行が失敗した場合、DLQに移動させることができる。

DLQに移った際のトリガとして、SNS/SQSが用意されている。

Eg1. Lambdaがうまくいってない！。SQSに移動させてメッセージを解析しよう！
EG2. Lambdaがうまく行ってない場合は、スマホにSNSで通知しよう！

バージョン & エイリアス

Lambdaはバージョンで管理することができる。
作成しているものはLatestであり、可変に対し、バージョン定義したものは不変。
つまり、Lambdaの使用メモリ量等の設定は変更出来ない。
イメージ的にはLatestに対してスナップショット的なイメージで別のバージョンとして公開することができる。

バージョンに対するイメージ

v1~v2まで公開している際のイメージは以下の様に捉えられる。

• Latest : 常に開発しているもの。公開対象は開発者向け（ガリガリ変更されていくやつ）
• v1 : お客様に現在公開しているバージョン
• v2 : テスト中のバージョン。テストが終わったらv1を非公開にしてv2を公開する。テスト中

バージョンとエイリアスを使ったイメージ

では、v3,v4...とバージョンが増えていくと毎回テスター等はそれに応じて実行先のバージョンを変えないといけないのか？
ここで登場するのがエイリアス。
エイリアスとバージョンを紐づけることにより、テスターは「TEST」、開発者は「DEV」を実行すればそれに応じたバージョンが実行され流様になる。

上記のバージョンの設定に対してエイリアスを紐づけたら以下の様なイメージ。

• DEV(latest) : 常に最新。バグもあるかも。
• v1(PROD) : 既にリリースされたやつ。
• v2(TEST) : 現在テスト中。テストが終わったらv2はPRODにエイリアスされる！

エイリアスは複数のバージョンに紐づけられる

例えば、PRODエイリアスにv2を設定したとする。
「テストは上手くいったけど、いきなり大量にアクセスされたら怖いな」ってなる。
『「安定のv1」で提供しつつv2を少しずつ提供して最後v２のみにしよう。危ないし。』となる。

この場合はPRODにv1とv2をエイリアスすることができる。
この設定の際、実行の加重を設定できる。
「心配だから10%くらいお試しでv2,９０％は安定のv1にしよう」という風にできる。

ちなみにこれがカナリアらしい。

/tmp in Lambda

最大５１２MB使える。
ただ、常に空というわけではなく、例えば一時ファイルを作成するlambda functionがあった場合、
再度実行した際にその一時ファイルが残っている場合もある（この場合は事前処理、事後処理でファイルを削除すべき）。
※同時実行された場合、一時ファイル名が一意じゃなかったら重複事故起きそう。。？

DynamoDB

キャパシティーユニット

DynamoDBは予め、使用方法に応じてキャパシティユニットをプロビジョニングしなければ使用できない
つまり、どの程度の書き込み/読み込み能力が必要であるか。を算出してそれに応じたキャパシティユニットを定義する必要がある。
尚、キャパシティユニットの数値によって料金が左右される

• 読み取りキャパシティユニット(RCU) : 1秒あたりに読み込みで必要なスループット(KB) -> 4KB/RCU
• 書き込みキャパシティユニット(WCU) : 1秒あたりに書き込みで必要なスループット(KB) -> 1KB/WCU

読み取りキャパシティが２の場合は、秒間８KBの読み込みに対応しているということになる。

バーストクレジット

しかしながら、急激な書き込みが発生する可能性は捨てきれない。
DynamoDBはこのバーストにも応じて、バーストクレジットが用意できる。
規定の処理量を超えた場合、このバーストクレジットを使用して、処理することができる。

ただし、クレジットを使い切った場合はその限りではない。（設計見直せってことだなぁ)

読み込み整合性

公式ドキュメント

以下の２種類あり、デフォルトは結果整合性となっている。
見る限り、「強力な整合性」の方が良い。デフォルトでいいんじゃないか。って思う。

RCUに影響があるからデフォルトでは「結果整合性」がデフォルトらしい。

結果整合性のある読み込み

DynamoDB テーブルからの読み込みオペレーションの応答には、
最近の書き込みオペレーションの結果が反映されていないことがあります。

強力な整合性のある読み込み

強力な整合性のある読み込みをリクエストすると、
DynamoDB は成功した以前のすべての書き込みオペレーションからの更新が反映された最新データの応答を返します。
強力な整合性のある読み込みは、ネットワークの遅延または停止があった場合には利用できなくなる可能性があります。

スロットル

許容範囲を超えた場合はProvisionedThroughputExceededExceptionsがDynamoDBから返ってくる

DynamoDBの書き込み

公式ドキュメント

putitem

データ(項目)の作成もしくは既存データの置き換え
米putitemはある意味更新も出来るということになる。(丸々置き換えだけど)

updateitem

データ(項目)の更新

条件付き書き込み

条件指定でも書き込み/更新が可能。
並列処理等で同時変更する際に役立つ。【要理解】

DynamoDBの読み込み

deleteitem

DeleteItem は指定されたキーを持つ項目を削除する

deletetable

テーブルの削除。

バッチオペレーション

1回のDynamoDBのリクエストで複数の書き込み/削除が行えるよ
更新は対象外だよ

複数の項目の読み込みや書き込みを必要とするアプリケーションのために、
DynamoDB は BatchGetItem および BatchWriteItem オペレーションを提供します。

DynamoDBの読み取り

getitem

データの読み込みが出来る。
ProjectionExpressionを使用することで属性を指定して取得が出来る。
イメージ的には「select * 」から「select user_id」みたいな感じ。
RCUの節約になる。らしい。

DynamoDBのクエリ

[公式ドキュメント] : (https://docs.aws.amazon.com/ja_jp/amazondynamodb/latest/developerguide/Query.html)

getitemは項目の取得。
こちらは項目の検索。という感じだろうか。（だんだん追いつけなくなってきた）

Amazon DynamoDB での Query オペレーションはプライマリキー値に基づいて項目を探します。
複合プライマリキー (パーティションキーとソートキー) のあるテーブルまたは セカンダリインデックス をクエリできます。

パーティションキーを指定。ソートキーとの複合で条件を満たすデータを取得することができる。
また、クライアント側でフィルタリングするものとしてFilterExpressionが存在する。

DynamoDB Streams

公式ドキュメント

DynamoDB ストリームは、DynamoDB テーブル内の項目に加えられた変更に関する情報の順序付けされた情報です。
テーブルでストリームを有効にすると、DynamoDB はテーブル内のデータ項目に加えられた各変更に関する情報を
キャプチャします。

DynamoDBに追加/更新/削除を実行した際、そのログをStreamとして取得することができる。
また、そのStreamをLambdaで読み取ることもできる。
公式ドキュメントに書かれているユースケースは以下。

- ある AWS リージョンのアプリケーションが、DynamoDB テーブルのデータを変更します。
別のリージョンの 2 番目のアプリケーションがそのデータ変更を読み込み、データを別のテーブルに書き込みます。
このとき、元のテーブルと同期されたレプリカを作成します。

- グローバルなマルチプレーヤーゲームには、データを複数の AWS リージョンに保存するマルチマスタートポロジがあります。
各マスターは、リモートリージョンで発生した変更を使用および再現することにより同期されます。

- アプリケーションは、友人の 1 人が新しい画像をアップロードするとすぐに、
グループ内のすべての友人のモバイルデバイスに通知を自動送信します。

TTL(Time to live)

カラムで指定した有効期限を過ぎると、自動でデータを消す機能がある。
これはストレージが無駄に圧迫されることへの予防、検索時の速さにつながる。

一般ドキュメント

例えば、１週間毎にデータを取得して週の終わりにそのデータを集計してS3にアップロードするワークロードがあった場合、
翌週になったら先週のデータは不要の産物になる。
この場合、予めデータ登録時にTTLを設定することにより、無駄にデータを残置することが無くなる。
SAAでも確かここら辺は出た気がする。（その時はデータの検索速度を早めるためには~とかだった）

API Gateway

ステージ

ステージは複数定義できる

大体は「Dev」（開発)/「Test」(試験)/「Prod」(本番)の様なステージの付け方が多い。
※というよりはこういう使い方しかまだ見たことない

各々のステージには独自にパラメータを設定できる

API Gateway用の環境変数。
これがステージ変数。

ステージ変数の用途

• ステージが通信するHTTPエンドポイントを構成します（dev、test、prod ...）
• マッピングテンプレートを通じて設定パラメーターをAWS Lambdaに渡す

Lambdaエイリアスとの連携

前述の通り、Lambdaエイリアスはlambdaのバージョンと紐づけることができる。
ステージ変数とLambdaエイリアスを紐づけることにより、自動的に規定したLambdaを呼び出すことができる。

マッピングテンプレート

公式ドキュメント

例えば、API Gateway経由でlambdaを実行。実行結果がlambdaより返ってきたとする。
返ってきた応答に対して「統合レスポンス」で様々な処理が行える。

•マッピングテンプレートを使用して、要求/応答を変更可能
•パラメーターの名前を変更する
•本文のコンテンツを変更する
•ヘッダーを追加する
•JSONをXMLにマッピングして、バックエンドに送信するか、クライアントに戻します
•Velocity Template Language（VTL）の使用：forループ、ifなど...
•出力結果のフィルター（不要なデータを削除）

何が面白いのか。

★箇所でレスポンスの内容を整形出来る。
つまり、クライアント側が受け取った後にResponceに対して整形しなくても良い可能性が作れる。
また、lambda側でのResponceを変更することもしなくても良い。
今回は応答の内容をxml形式に変更してみた。

Request : クライアント => API Gateway => Lambda
Response : lambda => API Gateway★ => クライアント

{"statusCode": 200, "body": "\"Fire Bird. \""}

{ 

<xml>
    <response>
        <statusCode>200</statusCode>
        <body>"Fire Bird. "</body>
    </response>
</xml>

}

APIキャッシュ

公式ドキュメント

Amazon API Gateway で API キャッシュを有効にして、エンドポイントのレスポンスがキャッシュされるようにできます。
キャッシュを有効にすると、エンドポイントへの呼び出しの数を減らすことができ、
また、API へのリクエストのレイテンシーを短くすることもできます。

キャパシティ

• Min : 0.5 GB
• Max : 237 GB

保持時間

Cache- Control: max-age= Headerでも設定可能。
例えば「0」を設定した場合は、キャッシュを使わずに直接実行される。

• default : 300 sec
• Max : 3600 sec
• set 0 : 無効

Security

IAM

いつも通り、ポリシーを作成してUserに付与もしくはRoleを使用してリソースに付与してコントロールする

SAM(サーバーレスアプリケーションモデル)

公式ドキュメント

リソース

• AWS :: Serverless::Api => HTTPSエンドポイントを介して呼び出すことができるAPI Gatewayリソースとメソッドの作成に使用
• AWS :: Serverless::Application => Amazon S3バケットからアプリケーションを埋め込むために使用
• AWS :: Serverless::LayerVersion => Lambdaレイヤード関数を作成
• AWS :: Serverless::Function => Lambda関数を作成するための設定を記述する

Step Functions

公式ドキュメント

AWS Step Functions では、AWS の複数のサービスをサーバーレスのワークフローに整理できるため、
すばやくアプリケーションをビルドおよび更新できます。
Step Functions を使用すると、AWS Lambda や Amazon ECS などのサービスをつなげて
機能豊富なアプリケーションにまとめるワークフローを設計して実行できます。

ECS

ECS概要

• ECSクラスターはEC2インスタンスの論理グループである
• EC2インスタンスは**ECSコンテナエージェント(Dockerコンテナ）**を実行する
• ECSコンテナエージェントは、インスタンスをECSクラスターに登録する
• EC2インスタンスは、ECS専用に作成された特別なAMIを実行する

container起動までの道のり

• クラスターの作成をする(やり方色々だけど、この段階でECSエージェントcontainerが起動されているEC2が作成)
• タスク定義を行い、タスクを作成する(言うなればDockerの起動方法を定義)
• タスク定義を指定してECSサービスを起動する。

タスク定義

公式ドキュメント

json形式であり、Dockerの起動方法をECSに対して定義する。

• タスクの各コンテナで使用する Docker イメージ
• 各タスクで、またはタスク内の各コンテナで使用する CPU とメモリの量
• **使用する起動タイプ。**この起動タイプにより、タスクをホストするインフラストラクチャが決定される
• タスクのコンテナで使用する Docker ネットワーキングモード
• タスクで使用するログ記録設定
• コンテナが終了または失敗した場合にタスクを実行し続けるかどうか
• コンテナの開始時に実行するコマンド
• タスクのコンテナで使用するデータボリューム
• タスクが使用する IAM ロール

タスクロール

タスクにもロールを割り当てることが出来る。
逆に言うと割り当てをしていない場合、権限が足りない理由で失敗する。
権限付与された AWS サービスへの API リクエストを行うためにタスクで使用できるオプションの IAM ロール。

タスクの実行 IAM ロール

タスクロールとは別。
コンテナイメージをプルし、コンテナログを Amazon CloudWatch に発行するタスク。

コンテナの定義

タスク定義では当然起動するコンテナの定義を行う。
主にコンテナ名、使用するイメージ(デフォルトはdockerhubに繋がっている)の設定。
ポートマッピング等、基本的にオンプレミスでdockerを使用する際に必要な情報を定義する。
その他、高度な設定も行うことは出来る。
このコンテナ定義は複数のコンテナを定義することが可能(タスク定義とコンテナ定義は１対１ではない)

ECSサービス定義

公式ドキュメント

Amazon ECS を使用すると、Amazon ECS クラスター内で、
タスク定義の指定した数のインスタンスを同時に実行して維持できます。これはサービスと呼ばれます。

タスク定義をしてもコンテナは起動されない。
あくまで、タスクとはどのImageを使用してどのネットワーク設定を行い、どのくらいCPU/RAMを使用するか。
などの、定義情報に過ぎない。

サービスタイプ

REPLICA

レプリカスケジュール戦略では、クラスター全体で必要数のタスクを配置して維持します。
デフォルトでは、サービススケジューラによってタスクはアベイラビリティーゾーン間で分散されます。

DEAMON

ーモンのスケジュール戦略では、指定したすべてのタスク配置制約を満たすクラスター内のア
クティブなコンテナインスタンスごとに、1 つのタスクのみをデプロイします。

デプロイメント

• ローリングアップデート
• Blue/Green デプロイメント (AWS CodeDeploy を使用)

動的ポートマッピング

公式ドキュメント

例えば、httpdのコンテナを1つのタスクに複数設定したい場合、ポートマッピングをずらさないといけない(8080,8081)
これらのポートマッピングを自動で行ってくれる機能。
ELBを用いて実現する。

やり方

タスク定義でホストポートをランダムへ

タスク定義内にあるコンテナ定義のポートマッピングのホストポートを空にする。
これによりポートが０（ランダム）で設定される。

この段階でサービスを起動すると、オートマッピングされた状態でEC2内にコンテナがDeployされる。
ただ、これだけだとユーザ的に困る（ぇ？どこのポート指定すれば良いの？ってことになる）

ここでALBを使用する。ということになる。

新規にサービスを作成する

既にALBを使用しない設定で、サービスを作成していた場合作り直す。
サービスの「更新」ではELBの追加は出来ないからである。（作成時に設定が可能）

ECR

Amazon Elastic Container Registry (ECR) は、完全マネージド型の Docker コンテナレジストリです。
このレジストリを使うと、開発者は Docker コンテナイメージを簡単に保存、管理、デプロイできます。

ECRはAWSの完全マネージド型のDocker ImageのPrivate Repositoryである。
IAMで制御することが出来る

ECRへのCommandline (push & pull)

- (aws ecr get-login --no-include-email --region eu-west-1)
- docker push 1234567890.dkr.ecr.eu-west-1.amazonaws.com/demo:latest
- docker pull 1234567890.dkr.ecr.eu-west-1.amazonaws.com/demo:latest

ECSでECRで管理しているイメージを使う場合

タスク定義から対象タスクの設定を変更する。
設定の「コンテナの定義」から「イメージ」をECRのコンテナイメージのURIを入力する・。
ただし、この場合、ECSにECRへの接続するためのロールが必要になる。

Fargate

ECSはEC2インスタンスを生成してDockerコンテナを構築していた。
これらの管理を行いたくない！サーバレスでいきたい。
これがFargateである。
コンテナのサーバレス（サーバ管理をしない）である。

AWS Fargate は、サーバーやクラスターの管理の必要なしにコンテナを実行するための、
Amazon ECS に対応したコンピューティングエンジンです。
AWS Fargate を使用すると、コンテナを実行するために仮想マシンのクラスターを
プロビジョニング、設定、スケールする必要がありません。

利点

• クラスター管理が不要
• シームレスなスケーリング
• AMAZON ECS との統合

タスク定義

タスク定義には種類がある。Fargateに合わせたタスク定義を作成する必要がある

ポートマッピング

ホストポートマッピングはFargateには存在しない。
自動的にポートマッピングするため不要らしい。

KMS

逃げられない。避けられない。それが暗号化...(ーー；
暗号化の問題ときたらKMSがまずでてくる。今までも。これからも。

公式ドキュメント

AWS Key Management Service (KMS) を使用することで、キーを簡単に作成・管理し、
幅広い AWS のサービスやアプリケーションで暗号化の使用を制御できるようになります。

ざっくり

データへのアクセスを制御する方法であり、AWSはキーを管理している。
以下のサービスとも統合されている。（暗号化オプションとかあったよね）
CLI/SDKでも普通に使うことは出来る。

• Amazon EBS：ボリューム暗号化
• Amazon S3：オブジェクトのサーバー側暗号化
• Amazon Redshift：データ暗号化
• Amazon RDS：デーの暗号化
• Amazon SSM：パラメーターストア

暗号化のサイズ制限

CMKを用いた暗号が最大4KBという制限がある。

LambdaからKMSを使用した簡単な例

お題： lambdaにDBのpasswordを送りたい。
手段： lambda変数を使う
問題: 確かにこれならソースコードにパスワードを書かなくて済むがlambdaのUIからパスワードモロバレじゃん

対策： lambda環境変数も暗号化出来る。UIから選択すればよし。

ざっくり流れ。

• KMSで鍵を生成する
• lambdaのUIからlambda変数を暗号化する。（作成した鍵を指定して暗号化)
• lambdaに復号化処理を入れる
• lambdaに割り付けられているroleにKMSのDecryptの権限をインラインポリシーで適用

ここでの注意点

暗号化入れたら4秒くらい処理が上がった。
毎回復号化処理入れなくても良いなら、lambdaは
ハンドラーの外に入れた方が良さそう...?
(初回だから時間掛かった。可能性も捨てきれない。捨て切れる？）

暗号化 SDK

一番わかりやすいページ

CMKを用いた暗号化は最大4KBである。
例えば、2TBのオブジェクトをS３に転送する際、コンプライアンスとして暗号化を求められたらどうすれば良いか？

この答えの1つがエンベロープ暗号であり、実現方法としてクライアント側の暗号化。
つまり、暗号化SDKを用いる。

エンベローブ暗号化のイメージ（ここまだ把握しきれてない...)

• Encryption SDKを使いKMSへ「GeneraiteKey API」を実行
• KMSではDataKeyが生成される(Plane DEK)
• KMSで生成したDataKeyに対してCMKを使用して暗号化したものを作成する(Encryption DEK)
• KMSからPlane DEKが送られる
• KMSからEnvryption DEKが送られる
• Plane DEKを用いてクライアント側はデータを暗号化する(暗号化済みファイルが出来る)
• Plane DKEはもう使わないので削除する
• 残った「暗号化済みファイル」と「Encryption DEK」がエンベローブファイル

IAM

• IAM Policy Simulator(定義したPolicyに対してリソースへのAction(GetObject等)をした場合どうなるか。を確認できる : 公式

CodeCommitのGitの認証情報

IAMのユーザ毎にAWS CodeCommit の HTTPS Git 認証情報がある。

AWS CLI

• S3 CLI Command : 公式
• STSデコード(コマンド実行時によく判らない暗号が出る場合があるそれの意味） :
  • 公式
  • 日本語

打ったコマンド

• decode-authorization-message --encode-message < messages >
  • STSメッセージ（暗号）を復号化する

---

勉強しておきたいページ(そのうち別ページへ....)