AWSデベロッパーアソシエイト資格のふりかえりと知識定着メモ

AWS

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の呼ぶエイリアスを指定可

まとめ

以上個人的に有益な情報をまとめてみました。発信することで、誤った知識の修正ができたことはなによりでした。

ただ途中で力尽きた感もあったので、リライトできればしていきたいと思います。

とつ

某SIer企業勤務。サーバーインフラ系でキャリアを伸ばしつつ、2020年からAWS運用にシフト。
老け顔から、「とっつあん」とあだ名で呼ばれ、それが「とつ」といつしか略されるようになったのがハンドルネームの由来。
「リベラルアーツ大学」をきっかけに、稼ぐ力を養いたいとBlogサイト運営を開始。Blogの成長とともにAWSのスキルアップももくろむ。
家族は妻と4歳長男と0歳次男。
次男の産後クライシスを乗り越えるための妻への対策と予防を模索する。

とつをフォローする
AWS
スポンサーリンク
とつをフォローする
とつブログ

コメント

タイトルとURLをコピーしました