この記事は個人ブログと同じ内容です
最近インフラ関連のことで学んだり、初めて知ったことをまとめました。
ECSサービス間の通信
サービスコネクト
同じECSサービス間でのみ通信する場合に使用する。
呼び出す側の場合は「クライアント側のみ」、呼び出すかつ呼び出される側は「クライアントとサーバー」。 CloudMapの名前空間に「APIのみ」で作成される。
terraformではaws_service_discovery_http_namespaceリソースとなる。
サービス検出（サービスディスカバリ）
ECSサービスだけではなく、Lambdaからなど同じネットワークでもECSサービス以外から呼び出される場合に使用する。
S3、SQS、Lambdaの非同期構成
S3へのJSONファイルアップロードをトリガーに、SQSにイベントを送り、それをLambdaが処理する構成。
この構成を使った理由としては以下である。
- LocalStackなどのエミュレーションツールを使用しないでローカル環境を構築できる。
- エミュレーションツールを使った開発はローカル環境での動作が重い。
- エミュレーションツールのため、実際のAWS環境と動きが違うところがあり、もし不具合などがあった場合にコントロールしにくい。
- JSONファイル連携にすることで、キューのエミュレーションを使わなくてもローカル環境を動作させることができる。
ECSからDatadogにログを送信する時
AWS FireLensを使用して、ECSにFluent Bitのコンテナを追加することにより、このコンテナがDatadogにログとトレースを送信します。
S3で事前署名付きURLのときに、発行するIAMのポリシーでIP制限をかけられる
以下のようにIAMポリシーでS3のGetObjectをするときにIPアドレス制限をかけることができる。
S3の事前署名付きURL（Pre-signed URL）を発行した元のIAMポリシーが適用される。
{ "Statement": [ { "Action": "s3:GetObject", "Condition": { "IpAddress": { "aws:SourceIp": [ "192.0.2.0/24" ] } }, "Effect": "Allow", "Resource": "arn:aws:s3:::sample/*", "Sid": "S3ObjectAccess" } ], "Version": "2012-10-17" }
バケットポリシーの複数の否定条件の罠
https://dev.classmethod.jp/articles/s3-bucket-policy-multi-condition/
以下のバケットポリシーだと、特定のIPまたは特定のVPCのみのアクセスを許可する。
「特定のIP以外」かつ「特定のVPC以外」を拒否=「特定のIP」または「特定のVPC」を許可
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Deny", "Principal": "*", "Action": "s3:GetObject", "Resource": "arn:aws:s3:::sample/*", "Condition": { "NotIpAddress": { "aws:SourceIp": [ "192.0.2.0/24" ] }, "StringNotEquals": { "aws:SourceVpc": [ "vpc-12345678901234567" ] } } } ] }
特定のIPかつ特定のVPCからのアクセスのみを許可する場合は、以下のようにstatementを分割する。
「特定のIP以外」または「特定のVPC以外」を拒否=「特定のIP」かつ「特定のVPC」を許可
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Deny", "Principal": "*", "Action": "s3:GetObject", "Resource": "arn:aws:s3:::sample/*", "Condition": { "NotIpAddress": { "aws:SourceIp": [ "192.0.2.0/24" ] } } }, { "Effect": "Deny", "Principal": "*", "Action": "s3:GetObject", "Resource": "arn:aws:s3:::sample/*", "Condition": { "StringNotEquals": { "aws:SourceVpc": [ "vpc-12345678901234567" ] } } } ] }
Lambdaの予約した同時実行数とSQSのイベントソースの同時実行数は違う
Lambdaの予約された同時実行数を10、イベントソースの同時実行数を9→SQSからはLambdaが最大で9個までしか同時実行されない→スロットリング発生しない
Lambdaの予約された同時実行数を10のみ設定→SQSからLambdaは10個以上同時で実行される可能性がある→スロットリングの可能性あり
DatadogモニターでDLQのメトリクスにキューの数の変更量を設定できる
DLQのDatadogモニターを作成するときに、Choose the detection methodをChange Alertに設定することにより期間内のキューの変化量でアラートすることができる。
Choose the detection methodがThreshold Alertだと、キューの数を参照しているので、DLQが残っている限りアラートがなり続けるため、Change Alertを使って期間内にキュー数の変化量を参照した方が良い。
SQSとLambdaでリトライについて
SQSとLambda構成で、Lambda処理が失敗してリトライするときは、Lambdaが終了しても可視性タイムアウト時間が終わらないとリトライされない。
「イベントソースマッピングのバッチ項目の失敗を報告: はい」に設定すると、バッチの失敗したメッセージのみがリトライされる。 デフォルトでこの設定は「いいえ」になっているため、バッチの中の1件でも失敗するとバッチ全体がリトライされる。
https://dev.classmethod.jp/articles/update-aws-lambda-partial-failures/
