AWS DVA デベロッパー　メモ１

AWS DVA デベロッパー　メモ１

AWSを使ったことがなく、用語が全然わからない人向けのサイトです。正確性に欠ける可能性がありますが、わかりやすさ重視で書いていきます。
デベロッパー　アソシエイトの範囲です。
今回は頻出の単語を書いていきます

---

DynamoDBのデータ操作。すべてAPIで行われる。

Putltem　新規項目の追加

UpdateItem　更新目的の操作

ConditionExpression　条件をつける。オプティミスティックロックという。

オプティミスティックロック　同時アクセスによるデータの不整合を防ぐ排他制御の手段。
データを取得してから更新するまでの間、データが変更されていないことを確認することで整合性をたもつ。

DynamoDBはBatchGetItem操作による読み取り処理によって、複数のデータをまとめて読み取るバッチ処理が実行できる。
DynamoDBにアクセスする回数を減らすことができる。制限は、100このデータまでで、取り出される項目の数は、１MBのサイズ制限を受ける。

DynamoDBのテーブルを抽象化して、開発を容易にするためにJavaにはDynamoDBMapper
.NET(C#)にはオブジェクト永続性モデルがある。

◉DynamoDBテーブルに何か書き込まれた時、Lambdaを関数を実行したい。
→DynamoDBストリームを用いて、トリガーする
→Lambda側の設定も必要で、DynamoDBストリームのARN（リソースネーム）を関連づけることも必要。


ElasticBeantalkとX-Rayを統合したい
⇨ElasticBeantalkコンソールにおいて「X-ray統合」を有効化
⇨設定ファイルを使用して、X-rayデーモンを設定する必要ある。（.ebextensions/xray-daemon.config  ソースコードの.ebextensionsディレクトリにxray-daemon.config構成ファイルを含めることが必要）

MySQLのログ

スロークエリログ

　実行に要した時間が「long_query_time」秒を超え、少なくとも「min_examined_row_limit」行を検査する必要があったSQLステートメントで構成される。

エラーログ

　（デフォルトで実行）

一般ログ

　クライアントのアクセス、クライアントから受け取ったSQLステートメントをログに記録する。


◉ElasticBeantalkはアプリケーションの他にワーカー環境を作ることができる。

ElasticBeantalkはIAMロールが必要。IAMポリシーをアタッチしないといけない。
→デフォルトの場合についているポリシー
・ElasticBeantalkEnhanceHelth　インスタンスや環境の正常性確認のためのポリシー
・ElasticBeantalkService　環境を作成、更新するためのポリシー


ElasticBeantalkで新バージョンを無停止でリリースしたい場合
→現環境のテンプレートのクローンを作成して、新しい環境に新バージョンのソフトウェアをデプロイする。Blue/Greenを使用


◉ElasticBeantalkはCLIコマンドからもアプリケーション・環境構築ができる。

eb init アプリケーションを作成する。パラメータの指定ができる。

eb create　環境名を指定して、アプリケーション環境を作成する。

eb deploy　環境の更新デプロイを実行する

デプロイ方法の種類

All at once　全てのサーバーで同時にIn-Place更新をする。

Rolling　サーバーをいくつかのグループに分けてグループごとにIn-Placeを更新する。
一部のインスタンスは古いバージョンでリクエストを処理し、デプロイが完了するまでに新しいインスタンスでもリクエストを処理できる。

Immutable　現バージョンとは別に新バージョンサーバーを構築する。

In-Place　稼働中の環境を新しいアプリケーションで更新する。

Liner(線形)　毎分10%づつ割合を増やす

Canary　最初は10%のみ。割合を段階的に増やしていく。

Blue/Green　検証環境をそのまま本番環境として利用することで、システムの停止時間を最小にするデプロイ手法。リクエストの送信先を変更することで実現。
クローンを作成して、そこで編集を加える。本番環境にリリースしたい時にURLの入れ替えを行う。

Cognitoオーソライザー 　ユーザープール（認証情報のディレクトリ）に認証許可を出す。APIの実行を許可することができる。
Lambdaオーソライザー 　Lambdaを利用して、APIへのアクセスを制御するAPI Gatewayの機能。APIの実行を許可することができる。独自の認証APIを利用する際に使用する。ポータルサイトで使用される。
・トークンベース　JSONトークンなどのベアラートークンで発信者のIDを取得する方式
・リクエストパラメータベース　ヘッダー、クエリ文字列パラメータ、stageVariable、$context変数の組み合わせで発信者IDを受け取る。
ユーザープール 　Cognitoのユーザーディレクトリ 。認証基盤を作成するよりも簡単に開発することができる。MFA認証をつけることができる。
Cognito IDプール 　ゲストユーザー（未認証）を認証して、一時的な認証情報をAWSに提供する。サインインなしで操作できる。IDプールはアカウントに固有のユーザーIDデータストア。認証していなくても、IAMロールを設定することができる。
Redis AUTH　Redisのコマンドを実行する前にパスワードを要求するように設定する機能。 「rawメッセージの有効化」サブスクリプションのメッセージを送る際に、メッセージの属性情報をつけなくてもよくなる。本文のみで良い。
◉特定のサブスクライバーにメッセージを送信したい場合は、フィルターポリシーを使用する。メセージ属性にフィルターポリシーを記載する。


◉SQSで何度も同じ処理のエラーを起こしてしまっている場合。デッドレターキューにぶち込めばいい。
SQSの最大メセージ容量は256KBだが、Extended Client Libraryを使用することによって、最大２GBまで拡張可能。
Extended Client Library 　SQSのメッセージを常に Amazon S3 に保存するか、メッセージのサイズが 256 KB を超える場合のみ保存するかを指定する。


Lambda関数の同時実行数を超えてリクエストを受けた場合、RateExceeded>エラーを受け取る。
Throttlesメトリクス で確認することも可能。
対応：クオータ引き上げリクエストを行う。

◉CodeCommitにアクセスするためには、パブリックキーが必要。事前にIAMにアップロードしておく。


ECSでロードバランサを利用する場合、ALBを利用する。
ALBはHTTP/HTTPSを使用するため、TCPポートが必要となる場合はNLBを利用する。

アプリケーションをコンテナで運用する際、スケージュールで定期実行したい処理はどのように実現するべきか
⇨ECSスケジュールドタスクを使用する。


マッピングテンプレート　API Gatewayを利用する際のテンプレート。簡単にカスタマイズできる。→API Gatewayの本文マッピングテンプレートを理解する


Lambdaレイヤー　複数のLambda関数で外部ライブラリやビジネスロジックを共有できる仕組み。外部ライブラリーなどの依存関係を共有化することができる。レイテンシを抑えることができる。
Lambdaエイリアス　関数の特定のバージョンに対するポインタのようなもの。
Lambda環境変数　変更の可能性があるパラメータを環境変数にしておけば、コードの変更をすることなく更新できる。
『チームでコードを共有しあいたいが、セキュリティを万全にしたい＝大事なところは変数にして自身で管理』最大512KBしかないので、それ以上の暗号化したい場合は、暗号化SDKを使う。
暗号化ヘルパー　環境変数の値をLambdaに送信する前に、クライアント側で暗号化できる（暗号化多すぎ！）
Lambdaで同期処理にしておくことで、Lambdaでエラーが起こったことを呼び出し元で検知できる。
Lambdaプロキシ統合　APIへのリクエストに含まれる情報をそのままLambda関数に渡すことができる。
Mock　テスト環境でバックエンドの処理を持たないAPIを作成する「モックは試作品という意味」
◉Lambda関数にLambda関数を重ねると再帰的な実行が行われるので、マジで気をつける。（莫大なコストがかかる）