模擬試験で撃沈した、LambdaのIAM権限とDynamoDBのキー設計

おはようございます、YASUです。

DVAの学習を進めるにあたり、模擬試験を1回解いてみたところ、正直かなり苦戦しました。特に手応えがなかったのが、前回予告していた通り「LambdaのIAM権限設計」と「DynamoDBのキー設計」でした。今日はこの2つを重点的に整理し直します。

結論

Lambdaには「実行ロール権限」と「呼び出し権限」という、似ているようで役割が全く違う2種類のIAM許可があります。またDynamoDBでは、QueryとScanという2つの取得方法の違いを理解していないと、実務でもパフォーマンスに大きな差が出ることが、実際の検証データからも裏付けられていました。

Lambdaの2種類のIAM許可、混同しやすいポイント

調べてみて一番はっとしたのが、「実行ロール権限」と「呼び出し権限」がまったく別物だという点でした。

ある技術ブログで紹介されていた例えが分かりやすかったのですが、「DynamoDBへの書き込み権限を追加したのに、なぜ関数が動かないのか」という混乱は、実はこの2つを取り違えていることが原因のケースが多いようです。「関数の中で何ができるか」と「関数自体がそもそも起動できるか」は、別の設定で管理されている、という理解が抜けていました。

さらにややこしい、イベントソースの種類による違い

この2種類の権限は、Lambdaをどう起動させるか(イベントソースの種類)によって、必要な設定が変わってきます。

「DynamoDB StreamsはIAMロールだけで動くのに、なぜS3トリガーは別の権限設定が必要なのか」という疑問は、まさにこのプル型・プッシュ型の違いに起因していました。試験でも、どちらの方式かによって設定すべき権限が変わる、という形で問われる可能性が高そうです。

DynamoDB:QueryとScanの根本的な違い

もう一つの弱点だったDynamoDBの取得方法について整理します。

Scanは「まず全部読んでから絞り込む」という動き方をするため、テーブルのデータ量が増えるほど、パフォーマンスが劣化していきます。ある検証記事では、データが10万件を超えたあたりからUXに影響が出始め、100万件規模になると数十秒〜2分以上の遅延が発生する、という具体的な数字が示されていました。実際に0.5KBのレコード100万件で比較した実験では、Scanが16秒、Queryが10秒という結果も紹介されており、データ量が増えるほどこの差はさらに開いていくとされています。

Scanを避けるための、GSI(グローバルセカンダリインデックス)という選択肢

「パーティションキーに含まれていない属性で絞り込みたい」という場面は、実務でもよく出てきます。この時、安易にScanで対応するのではなく、GSIという「別の切り口で作る、もう1つの索引」を用意しておくことで、Queryのまま効率的に検索できるようになります。

# 例:投稿データを「公開状態」で絞り込み、日付順に取得したい場合
GSIのパーティションキー:type(例:public)
GSIのソートキー:created_at

このようにGSIを設計しておけば、Scanに頼らず、DynamoDB側で絞り込みとソートの大部分を完結できます。「Scanを使う=設計を見直すべきサイン」というくらいの意識を持っておくと良さそうです。

なぜこの2つが試験で狙われやすいのか

どちらも「一見動きそうに見えるが、実務では問題が起きる」という性質の知識です。IAM権限の設定を間違えても、エラーメッセージから原因を特定するのに時間がかかりますし、Scanを使ったコードも、少量のデータでテストしている間は問題なく動いてしまいます。本番相当のデータ量や、権限の細かい違いを問う設問に対応するには、こうした「見た目では気づきにくい落とし穴」を事前に知っておくことが、まさに実務経験の有無を測る狙いなのだと感じました。

まとめ

模擬試験で解けなかった悔しさはありますが、今回のようにピンポイントで理解を掘り下げられたので、次の演習でどう変わるか楽しみです。それでは、また明日!