AWS Lambdaとサーバーレスのシナリオ判断

画像処理や注文処理を例に、通常のLambda関数の適用条件を判断します。時間制限、権限不足、イベントの重複、外部サービスの能力を分けて考える演習です。

この単元で学ぶこと

1. イベントに合う仕事画像が追加されたときだけ変換する処理は、イベントで実行するLambdaの例です。通常の関数実行として、イベント接続、処理コード、対象S3への権限を揃えます。利用者がホストOSを自由に管理したいという要件とは切り分けて選びます。

2. 何秒かかるか処理の平均が短くても、大きいファイルや接続先の遅延で時間が延びることがあります。通常の一回の関数は最大900秒なので、実測条件を確認してタイムアウトを設定します。仮に720秒の処理なら上限内ですが、上限内というだけで要求性能や余裕を満たすわけではありません。

3. 権限不足を調べる関数は呼べるがS3へ書けない場合、実行ロールの許可や対象資源の条件を確認します。呼出し利用者のパスワードを変更しても、実行中の書込み権限が増えるわけではありません。必要な操作に絞って許可し、エラーの理由と対象を確かめます。

4. イベントが重複したら同じ注文を二回受けたとき、注文ID等を使って処理済みを判定する設計を検討します。単に実行回数を減らす設定と、業務結果を一度にする仕組みは違います。外部の支払処理等にも重複防止の条件を合わせ、途中で失敗した場合を試します。

5. 状態が見つからない前回メモリへ置いた結果が次回見つからなくても、同じ実行環境が使われる前提が誤りかもしれません。必要な状態は外部へ保存します。再利用できたときだけ速くするキャッシュと、なくなれば業務が壊れる唯一の記録を区別します。

6. DBが先に限界になる関数の同時実行が増えてDBの接続数を超える場合、関数だけを増やし続けると失敗が増えます。同時実行の制御や適切な接続管理、処理の緩衝等を検討します。計算資源が自動で増えることと、依存先の能力は別の話です。

7. 費用と時間を同時に測る仮に1GBで2秒の処理が2GBで1秒なら、単純なメモリ×時間はどちらも2GB秒です。ただし実際の料金は要求数やアーキテクチャ、追加機能等にも関係するため、これだけで最終請求が同じとは断定しません。性能と料金条件を両方比較します。

8. 再試行を確認する同期の呼出し、非同期イベント、キュー等からの処理ではエラーと再試行の扱いが異なります。処理が失敗した場合に誰が再試行し、どこへ失敗情報を残すかを確認します。検証では重複・タイムアウト・権限不足を切り分け、再試行だけで副作用が取り消されるとは考えません。

教材データに登録された参考リンクです。リンク先の内容や更新日は提供元でご確認ください。

確認問題の出題・採点や学習履歴の保存にはログインが必要です。