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のスキルアップももくろむ。
家族は妻と長男。3歳の長男がついこの前「しーしこ行くー!」と念願のオムツはずれを達成した!

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

コメント

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