AWSデベロッパーアソシエイト資格を受講し、今回さまざまな知識を得ることができました。いつもなら試験に合格して、「ハイ終わりー！」だったんですが、せっかくBlogを始めたので、自分の知識の定着として使ってみようと、まとめてみることにしました。
なので、今回の対象読者は誰でもない自分のためのものです。ちっともPV伸びないことでしょう。でもそういうBlog記事も良いかなと思いました。
今回は、何を知ることができてよかったのかを記載していこうと思います。
ElasticCache for Redis
PubSubで利用できる
現場であまり使うことがないResisですが、PubSubとして使うことができるとテキストにありました。
ここで言うPubSub機能とは、Publisherからオンデマンドで、Subscriberにメッセージが送信されるサービスです。
Redisには「subscribeコマンド」で、接続しっぱなしにして、Subscriberにする機能があるようです。
レプリケーションと分散ノード
Redis自体に、レプリケーションがあるので、分散ノードを構築することができるようです。
DynamoDB
パーティションキーのみでも一意にできるとプライマリキーにできる
DynamoDBは、プライマリキーを必ず設定する必要があります。プライマリキーは。一意にできればパーティションキーだけでも設定することが可能です。
プロビジョンング済みキャパシティモードでのRSU・WSU計算
デフォルトはプロビジョニング済みのキャパシティモードで立ち上げることになります。RCUやWCUの計算が必要なのはこのためです。
RSUは、「結果整合性」では4KBで2回読み込み、「強い整合性」では、4KBで1回読み込みの計算になります。
WSUは。1KBで1回の書き込みとなります。Cloud WatchアラームでWCU・RCUをオートスケーリング可能です。
オンデマンドモードは選択して有効できますが、予想外のリクエスト過多になれば、コストがかかることになります。
セカンダリインデックスはクエリを実行するための手段
Scanでもレコードを検索することができるが、全テーブルをScanするハメになりコスト・パフォーマンスが非効率になります。1回のScanで1MBしか読めないので、巨大なテーブルになれば、Scanは返答が帰ってこなくなるのではないかと思います。
Queryで実行するには、「プライマリーキー」か「セカンダリインデックスのキー：に対して、実施する必要があります。
セカンダリインデックスも2種類あり、「パーティションキー」と「もうひとつのキー」で作成する、「ローカルセカンダリインデックス」と
「パーティションキー以外の2つのキー」で作成する「グローバルインデックス」があります。
「ローカルセカンダリインデックス」は、後づけできませんが、「グローバルセカンダリインデックス」は後づけできます。
現場のDynamoDBを見直してみようと思います。
PutItemとUpdateItem
「PutItem」「UpdateItem」は、新規追加と更新が可能です。Condition（SQLでいうところのWhere句）で条件式を作ることで更新処理にできます。「UpdateItem」でも新規追加できることを知らなかったです。
バッチ処理やトランザクション処理
「BathGetItem」、「BatchWriteItem」でバッチ処理のAPIを実行できます。UnprocessedItemに失敗ログが表示されるそうです。先日仕事で、DynamoDBのデータパッチ作業がありましたが、1レコードずつ、「PutItem」してました＾＾；知っていればもっと早く処理が終わったことでしょう・・・。
「TransactGetItems」「TransactWriteItem」でトランザクション処理も可能だそうです。
SQS
「SQS」と「SNS」、「Kinesis」3つの違いにイマイチピンと来てませんでした。似たようなサービスだったからです。
まず。「SQS」と「SNS」はメッセージングサービスということです。端的に言うと遅れるサイズが小さい（256Kbyte）ということでした。かたや、「Kinesis」は大きなデータを送信できます。「Kinesis」と「SQS」は、ポーリングしてデータを取得するPULL型のサービスに対し、「SNS」はデータを一方的に送信する、PUSH型のサービスであるということでした。自分の中で整理ができました。
SNS＋SQSのファウンアウト処理
SNSでメッセージをSQSに分散して、キューイングさせるユースケースがあるそうです。これを「ファンアウト」というそうです。
SQSをポーリングしている、Lambdaの並列実行が可能になってパフォーマンスが向上しそうです。改善に使ってみたいアーキテクチャですね。
各パラメーターのメモ
SQSのチューニングに必要なパラメーターをまとめます。
- 「Visibility Timeout」で、Subscriber同士の重複取得の排除できる。
- 「RecieiveMessage WriteTimeout」でロングポーリング読み込みし、余分なコストを減らせる。
- FIFOキュー設定することで、「順番補償」「1回だけ送信」の要件があるアプリケーションに対応できる。
BeansTalk
デプロイ種類
デプロイの種類で、「Rolling」と「Canary」、「BlueGreen」の違いを理解してなかったので、次のとおりまとめます。
- Rolling 除々に（グループごとににin-Place）
- トラフィック分割 新しい方を10％とか？段階的（Canaryデプロイ）
- Blue/Green クローンに新アプリをデプロイし、URLスワップ
lambda
ほとんど引き上げ不可
「同時実行数」以外引きあげ不可は、知りませんでした。現場で、900secタイムアウトするLambdaがありましたが、引き上げ要求してもだめなんですね＾＾；
ALBのターゲット指定
ALB→lambdaで複数ヘッダーALBのターゲットとしても指定可能なんですね。脊髄反射で「API Gateway」配下だと思ってました。レスポンスで「複数値のヘッダー」オプションを有効にすることがよいようです。
API GatwayでLambdaプロキシ統合する
RAWデータのまま、Lambdaにわたすオプション。ほぼ必須パラメーターという認識ですが無効にした場合のユースケースはあるのでしょうか？どうやら、無効にしてパラメーターを加工する場合に使うようです。
必要なポリシー
PUSH系かPULL系かで、Lambdaに必要なポリシーが変わって来ます。
- PUSHは「S3イベント」「API Gateway」「Lambda」のリソースベースポリシーにする
- PULLは「kinesis」「SQS」「DynamoStream」は、Lambda関数に割当てるポリシー（アクセス権）
レイヤーで依存ライブラリを保存
Lambdaレイヤーで依存ライブラリをデプロイします。現場では、ZIPファイルに固めてデプロイしているイメージでした。確認したいと思います。
エイリアス（dev.prod）でロールバック管理
デプロイバージョンにエイリアスをつけることができ、ロールバックなどに役立ちそうです。
Cognito
現場では、認証サービスとしてAuht0を使っているため、あまり馴染みがありません。とくによくわかってないサービスでした。
ユーザプールとIDプールの違い
ユーザプールは、アカウントパスワードを保持するサービス。その中に、「Facebook」などの外部認証基盤が使える、WebIDフェデレーションができる機能もあるようです。クライアントには、認証後にアクセスキートークンをかえす仕組みであると理解しました。
IDプールは、「Facebook」などの他のサイトのアカウントのみを保持するサービス。モバイルアプリやクライアントJavaScriptで利用可能であり、IAMロールと、認証プロバイダー両方使えて、STSのアクセスキーとシークレットアクセスキートークンをかえす仕組みと理解しました。
Secrets Manager
現場では、「System Manager」によるパスワード管理しているので、「Secrets Manager」の存在意義が、いまいちピンときてませんでした。
Lambdaを実行してパスワードを変更し、「Secrets Manager」に保持することで、パスワードローテができることを学べたのは有意義でした。
こちらも現場で改善検討してみたいと思います。DB認証にも使ってみたいですね。KMSやデフォルトキーで両方暗号キーとして使えます。
IAM
リソースベースポリシーいろいろ
実装は割愛します。
- S3のcloudfront（OAI文字列）
- API Gatewayで他のAWSアカウントからアクセス
- SQSで他のAWSアカウントからアクセス
- KMSを他のAWSアカウントから利用
サービスロールとは信頼されたロール
EC2ロールには、コンソールで設定するとインスタンスプロファイルが自動設定されます。Terraform管理していると「このプロファイルって何？」となってましたので学べて良かったです。
conditionあるある
実装は割愛します。
- AWS:Source IPでしぼる
- ${aws:username}を使う
- ArnLike:で呼びだし元をぼるlambda
KMS
必要なキーポリシー（リソースベースポリシー）
「GenerateDataKey」は、カスタマーマスターキー (CMK) で生成されるデータキーなんですね。
なので必要なキーポリシーは次のとおりになるそうです。
{
"Sid": "",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::000000000000:user/iam_user_name"
},
"Action": [
"kms:Encrypt",
"kms:Decrypt",
"kms:ReEncrypt*",
"kms:GenerateDataKey*",
"kms:DescribeKey"
],
"Resource": "*"
},API GateWay
クライアント証明書を使った接続制限
バックエンドのサーバー証明書からクライアント証明書で通信し、通信の機密性を高めます。
メソッド認可の選択肢
メソッド認可で、「IAMユーザー」か「Cognitoオーソラライザー」「Lambdaオーソライザーを」選択可能となります。現場では、「Lambdaオーソライザー」で、Auht0を呼び出してます。
流量制限
流量制限についてまとめました。
- APIステージごとに流量制限 MAX1万リクエスト/sec（引上げ可）
- 使用量プランAPIごとの使用制限、流量リクエスト/sec（レート）、月回数（クォータ）
- 使用量プランとAPIキーを紐付け
他使える機能
API Gatewayで使えるさまざまな機能をまとめました。
- パラメーターのマッピング
- GETのキャッシュ
- ステージ変数 lambdaの呼ぶエイリアスを指定可
まとめ
以上個人的に有益な情報をまとめてみました。発信することで、誤った知識の修正ができたことはなによりでした。
ただ途中で力尽きた感もあったので、リライトできればしていきたいと思います。
コメント