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

Slide 1

Slide 1 text

情シスにこそStepFunctionsが強力な武器になる〜ワイはQuickSightのユーザー削除を自動化したかったんや〜 JAWS-UG 情シス支部第31回クラウド女子会×札幌支部コラボ会 2025/5/24 山﨑奈緒美

Slide 2

Slide 2 text

AWS SAMURAI 2015 JAWS-UGアーキテクチャ専門支部 JAWS-UG情シス支部生活協同組合コープさっぽろデジタル推進本部システム企画部インフラチーム山﨑奈緒美ご挨拶と自己紹介大阪出身。就職で上京し、ソフトハウスでインフラエンジニア地図情報システム開発会社でひとり情シス旅行会社の情シス部門でクラウド担当 2020年9月に東京から札幌へ移住し10月よりコープさっぽろへJOIN。 AWSのことならなんでも担当。 @nao_spon I ♡ Route53 IAM Organizations 夏はロードバイク、冬はスノボしてます。仲間募集中！

Slide 3

Slide 3 text

生活協同組合コープさっぽろについて（※2024年3月現在）設立年月日 1965年7月18日組合員数 201万人出資金額　　897億円総事業高 3,186億円店舗 1,983億円宅配（灯油込）　1,134億円共済（代理店収入）　　　22億円その他　　47億円正規職員　 2,405名契約社員 2,228名パートアルバイト 10,110名 ※従業員数は関連会社含む道内：247万世帯組織率：81％

Slide 4

Slide 4 text

北海道で生きることを誇りと喜びにする 3つのつなぐ福祉活動文化教室組合員活動葬祭事業旅行事業物流事業店舗事業移動販売宅配事業配食・給食食育食品製造共済事業エネルギー子育て支援環境活動リサイクルフードバンク育英奨学金と人人をつなぐと人食をつなぐと人未来をつなぐ

Slide 5

Slide 5 text

StepFunctionsってさぁ...

Slide 6

Slide 6 text

Step Functionsに対するイメージ

Slide 7

Slide 7 text

Step Functionsに対するイメージ

Slide 8

Slide 8 text

Step Functionsに対するイメージ ● アプリ開発の人が触るサービス ● WEBシステム/サイトの裏側で使うサービス ● Lambdaをつなげていくサービス ○ Lambdaを書かないといけない ● なんか難しそう ● （情シス / インフラ）な自分には関係なさそうなサービス ● 開いてみたけどワケわからなくてそっ閉じした

Slide 9

Slide 9 text

Lambdaを書かなくても AWS APIを直接呼び出せる StepFunctionsのいいところ

Slide 10

Slide 10 text

IAM Identity Centerと QuickSightユーザーのプロビジョニングを Step Functionsで実装してみたという話を前にしました

Slide 11

Slide 11 text

http://bit.ly/44E52Kz 資料はこちら

Slide 12

Slide 12 text

世の中は常にビルドアンドスクラップである祇園精舎の鐘の声、諸行無常の響きあり。沙羅双樹の花の色、盛者必衰の理をあらはす。おごれる人も久しからず。ただ春の夜の夢のごとし。たけき者も遂にはほろびぬ、ひとへに風の前の塵に同じ。 by 平家物語盛者必衰＝「生者必滅」「会者定離」 All living things must die、we meet only to part

Slide 13

Slide 13 text

IAM Identity Centerと QuickSightユーザーのデプロビジョニングを Step Functionsで実装してみた今回は削除の話

Slide 14

Slide 14 text

前回の話の後...

Slide 15

Slide 15 text

前回の話の後... 今まではアクティブなReaderのみ課金対象だったのが 2025/5/1より非アクティブなReaderも課金対象に

Slide 16

Slide 16 text

QuickSightユーザーって何人いるんだっけ Admin：10ユーザー Author：16ユーザー Reader：約2200ユーザー 2200 * $3 = $6600

Slide 17

Slide 17 text

QuickSightユーザーって何人いるんだっけ Admin：10ユーザー Author：16ユーザー Reader：約2200ユーザー 2200 * $3 = $6600 今までの倍以上になるやないかい

Slide 18

Slide 18 text

アクティブじゃない人は誰だ • 過去2ヶ月以上利用していないユーザーを削除する • Last activeの日付が2ヶ月以上前なら削除対象 • 約900ユーザーが削除対象

Slide 19

Slide 19 text

みんな大好きStep Functions Step Functionsのフロー 1. エラーログ用DynamoDBを作成 2. S3にある削除対象csvを参照 3. リストのメールアドレスからQSユーザー名生成 4. QSユーザー存在確認 a. 存在していたらユーザー削除 b. 存在していなかったらDynamoDBにログ出力 5. DynamoDBの内容をS3へファイル出力 6. DynamoDB削除 7. S3の削除対象csvファイル削除 ❶  ❷  ❸  ❹  ａ  ｂ  ❺  ❻  ❼ 

Slide 20

Slide 20 text

みんな大好きStep Functions ハマった点 • IAM Identity Centerユーザー削除をトリガーにできない • Map Stateの中にあるStateのCatcherでMapを抜けられない • DynamoDB のフルエクスポートに非常に時間がかかる • 作ったばかりのDynamoDBは消せない • APIがすぐスロットリングする • エクスポネンシャルバックオフの罠

Slide 21

Slide 21 text

IAM Identity Centerユーザー削除でのトリガー不可背景と原因 • GoogleグループとIAM Identity Centerでユーザー同期 • IAM Identity Centerに同期されたユーザー情報で QSユーザープロビジョニング • Googleグループから外されたユーザーは IAM Identity Centerで削除されるのでそれをトリガーにState Machine起動したかった

Slide 22

Slide 22 text

IAM Identity Centerユーザー削除でのトリガー不可背景と原因 • IICのDeleteUserログを確認するとuserIdがUUIDチックな... • QuickSight側のユーザー情報にはIICのユーザーIDが関連づけられていない • userIdからIICユーザー名を確認しようにも既に削除されてるので確認できない

Slide 23

Slide 23 text

IAM Identity Centerユーザー削除でのトリガー不可解決・回避策・工夫した点 • 削除対象者はわかっているのでcsvファイルにしてS3に置く • 削除対象リストをMap Stateで読み込んで処理するようにした • 削除タイミングは月1回程度なのでState Machineの起動はマネコンから手動実行するようにした • 作業者はAWSに詳しくないのでマネコン利用想定で画像付きのわかりやすい手順書を作成

Slide 24

Slide 24 text

Map Stateの中のCatcherでMapを抜けられない背景と原因 • 削除対象csvを作るのは人間なので間違いは起きる • QuickSightユーザー名はメールアドレスを元にしている • csv中のメールアドレスのタイプミス・全角 • csvを作ってからQS管理画面で手動で消してるかも • QSユーザー削除前に存在確認をしたい • 存在確認OKの場合にQS:DeleteUserをしたい

Slide 25

Slide 25 text

Map Stateの中のCatcherでMapを抜けられない背景と原因 • CatcherのFallback stateのプルダウンに Map Stateの外のStateが出てこないので選べない

Slide 26

Slide 26 text

Map Stateの中のCatcherでMapを抜けられない解決・回避策・工夫した点 • 存在確認できなかったユーザーは作業者に伝えたいのでログとして残す必要がある • CloudWatch LogsやStep FunctionsのMap Run Executionsを作業者に確認してもらうのは厳しい • 存在確認できなかったユーザー情報とエラー内容を DynamoDBに貯めて最後にS3へファイル出力させる • Map State内では貯めるだけにしてS3出力は最後に • Map内なのでDynamoDB:PutItemのStateへFallback可能

Slide 27

Slide 27 text

背景と原因 • 存在しないユーザーを3ユーザー用意してテストしたら... • エクスポートするのに30分くらいかかった...💤 • 一発目の約900名削除時にどこまで間違えるか...？ DynamoDB のフルエクスポートに非常に時間がかかる

Slide 28

Slide 28 text

解決・回避策・工夫した点 • 諦めてLambdaでエクスポートするようにした • プログラミングは苦手なので全力で他人に頼るムーブ • クラメソさんの記事で良さそうなのがあったので参考にさせていただきましたありがとうございます！！ DynamoDB のフルエクスポートに非常に時間がかかる https://dev.classmethod.jp/articles/aws-lambda-dynamodb-csv/

Slide 29

Slide 29 text

背景と原因 • テストで初回の大量削除後の月次削除時の想定で 10ユーザー程度の削除パターンを試したら... • DynamoDb.ResourceInUseExceptionが発生 • DynamoDB:PutItemがないパターンでも発生するので作成直後に削除はできなさそう作ったばかりのDynamoDBは消せない

Slide 30

Slide 30 text

解決・回避策・工夫した点 • Retrierでインターバルを2秒→30秒にした • リトライ回数やバックオフレートはデフォルトのまま作ったばかりのDynamoDBは消せない

Slide 31

Slide 31 text

背景と原因 • 一発目の削除は約900ユーザーで大量なので 1ユーザーずつ処理はしたくない • Map Run内で並列実行すると100並列程度でも API実行がスロットリングする • LambdaはTooManyRequestsException • QuickSightはThrottlingException APIがすぐスロットリングする

Slide 32

Slide 32 text

解決・回避策・工夫した点 • Retrierでエクスポネンシャルバックオフさせた • リトライ間隔を指数関数的に伸ばしていく APIがすぐスロットリングする

Slide 33

Slide 33 text

背景と原因 • 本番一発目の削除時に3日経っても終わらなかった • リトライ時にスロットリングが発生し18回リトライ • Map Runで実行中のもののリトライ時刻と前回実行時との時間差を算出した結果次回リトライ予定時刻が3日後さらに次は6日後となる計算エクスポネンシャルバックオフの罠中略 

Slide 34

Slide 34 text

解決・回避策・工夫した点 • Retrierのエクスポネンシャルバックオフにジッター処理 • リトライ間隔をランダム化することで再スロットリングを防ぐ • Map Stateの並列実行数の上限を設定 • 並列実行数をMAX100にして何度もリトライが発生するようなことにならないようにしたエクスポネンシャルバックオフの罠

Slide 35

Slide 35 text

Reader約2200ユーザーを約1200ユーザーへ削減無事に大量削除完了

Slide 36

Slide 36 text

5/1にAWSから届いたお知らせ

Slide 37

Slide 37 text

みんな大好きStep Functions まとめ • API実行時にはスロットリングに気を付ける • CatcherとRetrierでのエラーハンドリングは大事 • APIではどうしても無理な場合はLambdaがんばる • 最近は生成AIに書いてもらうこともできますし... • Map Stateでは並列実行数の上限を設定する • API実行時のスロットリング誘発を防ぐ • エクスポネンシャルバックオフは過信しない • Jitterを付けるとリトライのタイミングが集中しない • プログラミングが苦手な人でも遜色のないものを作れる