JAWS-UG情シス支部 情シスにこそStepFunctionsが強力な武器になる〜ワイはQuickSightのユーザー削除を自動化したかったんや〜 / How to automate deprovisioning QuickSight users with StepFunctions

JAWS-UG 情シス支部 第31回 クラウド女子会×札幌支部コラボ会で発表した資料です。
StepFunctionsの設定でハマったところとその回避策を中心にお話ししました。

Transcript

1. 情シスにこそStepFunctionsが 強力な武器になる 〜ワイはQuickSightのユーザー削 除を自動化したかったんや〜 JAWS-UG 情シス支部 第31回 クラウド女子会×札幌支部コラボ会 2025/5/24 山﨑 奈緒美
2. AWS SAMURAI 2015 JAWS-UGアーキテクチャ専門支部 JAWS-UG情シス支部 生活協同組合コープさっぽろ デジタル推進本部 システム企画部 インフラチーム 山﨑 奈緒美 ご挨拶と自己紹介 大阪出身。 就職で上京し、ソフトハウスでインフラエンジニア 地図情報システム開発会社でひとり情シス 旅行会社の情シス部門でクラウド担当 2020年9月に東京から札幌へ移住し10月よりコープさっぽろへJOIN。 AWSのことならなんでも担当。 @nao_spon I ♡ Route53 IAM Organizations 夏はロードバイク、冬はスノボしてます。仲間募集中！
3. 生活協同組合コープさっぽろについて （※2024年3月現在） 設立年月日 1965年7月18日 組合員数 201万人 出資金額 　　897億円 総事業高 3,186億円 店舗 1,983億円 宅配（灯油込） 　1,134億円 共済（代理店収入） 　　　22億円 その他 　　47億円 正規職員　 2,405名 契約社員 2,228名 パート アルバイト 10,110名 ※従業員数は関連会社含む 道内：247万世帯 組織率：81％
4. 北海道で生きることを誇りと喜びにする 3つのつなぐ 福祉活動 文化教室 組合員活動 葬祭事業 旅行事業 物流事業 店舗事業 移動販売 宅配事業 配食・給食 食育 食品製造 共済事業 エネルギー 子育て支援 環境活動 リサイクル フードバンク 育英奨学金 と 人 人 をつなぐ と 人 食 をつなぐ と 人 未来 をつなぐ
5. StepFunctionsってさぁ...
6. Step Functionsに対するイメージ
7. Step Functionsに対するイメージ
8. Step Functionsに対するイメージ • アプリ開発の人が触るサービス • WEBシステム/サイトの裏側で使うサービス • Lambdaをつなげていくサービス ◦ Lambdaを書かないといけない • なんか難しそう • （情シス / インフラ）な自分には関係なさそうなサービス • 開いてみたけどワケわからなくてそっ閉じした
9. Lambdaを書かなくても AWS APIを直接呼び出せる StepFunctionsのいいところ
10. IAM Identity Centerと QuickSightユーザーの プロビジョニングを Step Functionsで実装してみた という話を前にしました
11. http://bit.ly/44E52Kz 資料はこちら
12. 世の中は常にビルドアンドスクラップである 祇園精舎の鐘の声、諸行無常の響きあり。 沙羅双樹の花の色、盛者必衰の理をあらはす。 おごれる人も久しからず。ただ春の夜の夢のごとし。 たけき者も遂にはほろびぬ、ひとへに風の前の塵に同じ。 by 平家物語 盛者必衰＝「生者必滅」「会者定離」 All living things must die、we meet only to part
13. IAM Identity Centerと QuickSightユーザーの デプロビジョニングを Step Functionsで実装してみた 今回は削除の話
14. 前回の話の後...
15. 前回の話の後... 今まではアクティブなReaderのみ課金対象だったのが 2025/5/1より非アクティブなReaderも課金対象に
16. QuickSightユーザーって何人いるんだっけ Admin：10ユーザー Author：16ユーザー Reader：約2200ユーザー 2200 * $3 = $6600
17. QuickSightユーザーって何人いるんだっけ Admin：10ユーザー Author：16ユーザー Reader：約2200ユーザー 2200 * $3 = $6600 今までの倍以上になるやないかい
18. アクティブじゃない人は誰だ • 過去2ヶ月以上利用していないユーザーを削除する • Last activeの日付が2ヶ月以上前なら削除対象 • 約900ユーザーが削除対象
19. みんな大好きStep Functions Step Functionsのフロー 1. エラーログ用DynamoDBを作成 2. S3にある削除対象csvを参照 3. リストのメールアドレスからQSユーザー名生成 4. QSユーザー存在確認 a. 存在していたらユーザー削除 b. 存在していなかったらDynamoDBにログ出力 5. DynamoDBの内容をS3へファイル出力 6. DynamoDB削除 7. S3の削除対象csvファイル削除 ❶
 ❷
 ❸
 ❹
 ａ
 ｂ
 ❺
 ❻
 ❼

20. みんな大好きStep Functions ハマった点 • IAM Identity Centerユーザー削除をトリガーにできない • Map Stateの中にあるStateのCatcherでMapを抜けられない • DynamoDB のフルエクスポートに非常に時間がかかる • 作ったばかりのDynamoDBは消せない • APIがすぐスロットリングする • エクスポネンシャルバックオフの罠
21. IAM Identity Centerユーザー削除でのトリガー不可 背景と原因 • GoogleグループとIAM Identity Centerでユーザー同期 • IAM Identity Centerに同期されたユーザー情報で QSユーザープロビジョニング • Googleグループから外されたユーザーは IAM Identity Centerで削除されるので それをトリガーにState Machine起動したかった
22. IAM Identity Centerユーザー削除でのトリガー不可 背景と原因 • IICのDeleteUserログを確認するとuserIdがUUIDチックな... • QuickSight側のユーザー情報にはIICのユーザーIDが 関連づけられていない • userIdからIICユーザー名を確認しようにも 既に削除されてるので確認できない
23. IAM Identity Centerユーザー削除でのトリガー不可 解決・回避策・工夫した点 • 削除対象者はわかっているのでcsvファイルにしてS3に置く • 削除対象リストをMap Stateで読み込んで処理するようにした • 削除タイミングは月1回程度なのでState Machineの起動は マネコンから手動実行するようにした • 作業者はAWSに詳しくないのでマネコン利用想定で 画像付きのわかりやすい手順書を作成
24. Map Stateの中のCatcherでMapを抜けられない 背景と原因 • 削除対象csvを作るのは人間なので間違いは起きる • QuickSightユーザー名はメールアドレスを元にしている • csv中のメールアドレスのタイプミス・全角 • csvを作ってからQS管理画面で手動で消してるかも • QSユーザー削除前に存在確認をしたい • 存在確認OKの場合にQS:DeleteUserをしたい
25. Map Stateの中のCatcherでMapを抜けられない 背景と原因 • CatcherのFallback stateのプルダウンに Map Stateの外のStateが出てこないので選べない
26. Map Stateの中のCatcherでMapを抜けられない 解決・回避策・工夫した点 • 存在確認できなかったユーザーは作業者に伝えたいので ログとして残す必要がある • CloudWatch LogsやStep FunctionsのMap Run Executionsを 作業者に確認してもらうのは厳しい • 存在確認できなかったユーザー情報とエラー内容を DynamoDBに貯めて最後にS3へファイル出力させる • Map State内では貯めるだけにしてS3出力は最後に • Map内なのでDynamoDB:PutItemのStateへFallback可能
27. 背景と原因 • 存在しないユーザーを3ユーザー用意してテストしたら... • エクスポートするのに30分くらいかかった...💤 • 一発目の約900名削除時にどこまで間違えるか...？ DynamoDB のフルエクスポートに非常に時間がかかる
28. 解決・回避策・工夫した点 • 諦めてLambdaでエクスポートするようにした • プログラミングは苦手なので全力で他人に頼るムーブ • クラメソさんの記事で良さそうなのがあったので 参考にさせていただきましたありがとうございます！！ DynamoDB のフルエクスポートに非常に時間がかかる https://dev.classmethod.jp/articles/aws-lambda-dynamodb-csv/
29. 背景と原因 • テストで初回の大量削除後の月次削除時の想定で 10ユーザー程度の削除パターンを試したら... • DynamoDb.ResourceInUseExceptionが発生 • DynamoDB:PutItemがないパターンでも発生するので 作成直後に削除はできなさそう 作ったばかりのDynamoDBは消せない
30. 解決・回避策・工夫した点 • Retrierでインターバルを2秒→30秒にした • リトライ回数やバックオフレートはデフォルトのまま 作ったばかりのDynamoDBは消せない
31. 背景と原因 • 一発目の削除は約900ユーザーで大量なので 1ユーザーずつ処理はしたくない • Map Run内で並列実行すると100並列程度でも API実行がスロットリングする • LambdaはTooManyRequestsException • QuickSightはThrottlingException APIがすぐスロットリングする
32. 解決・回避策・工夫した点 • Retrierでエクスポネンシャルバックオフさせた • リトライ間隔を指数関数的に伸ばしていく APIがすぐスロットリングする
33. 背景と原因 • 本番一発目の削除時に3日経っても終わらなかった • リトライ時にスロットリングが発生し18回リトライ • Map Runで実行中のもののリトライ時刻と前回実行時との 時間差を算出した結果次回リトライ予定時刻が3日後 さらに次は6日後となる計算 エクスポネンシャルバックオフの罠 中略

34. 解決・回避策・工夫した点 • Retrierのエクスポネンシャルバックオフにジッター処理 • リトライ間隔をランダム化することで 再スロットリングを防ぐ • Map Stateの並列実行数の上限を設定 • 並列実行数をMAX100にして何度もリトライが 発生するようなことにならないようにした エクスポネンシャルバックオフの罠
35. Reader約2200ユーザーを 約1200ユーザーへ削減 無事に大量削除完了
36. 5/1にAWSから届いたお知らせ
37. みんな大好きStep Functions まとめ • API実行時にはスロットリングに気を付ける • CatcherとRetrierでのエラーハンドリングは大事 • APIではどうしても無理な場合はLambdaがんばる • 最近は生成AIに書いてもらうこともできますし... • Map Stateでは並列実行数の上限を設定する • API実行時のスロットリング誘発を防ぐ • エクスポネンシャルバックオフは過信しない • Jitterを付けるとリトライのタイミングが集中しない • プログラミングが苦手な人でも遜色のないものを作れる
38. みんな大好きStep Functions まとめ • API実行時にはスロットリングに気を付ける • CatcherとRetrierでのエラーハンドリングは大事 • APIではどうしても無理な場合はLambdaがんばる • 最近は生成AIに書いてもらうこともできますし... • Map Stateでは並列実行数の上限を設定する • API実行時のスロットリング誘発を防ぐ • エクスポネンシャルバックオフは過信しない • Jitterを付けるとリトライのタイミングが集中しない • プログラミングが苦手な人でも遜色のないものを作れる