前の記事の次に、今回は実践のユーケースを説明させて頂きます。
以下の２つのパートに分かれています。
- パート１：概要の設計（本記事）
- パート２：詳細な実行
概要
- 前提
- 背景
- 目的
- 構成・経過
- 評価
- その他
1.前提
- Node Js 20.xx
- Lambda x86_64
- sharp (os linux, cpu x86)
- AWS console 操作ため、管理権があるアカウントは必要
2.背景
SNS系アプリでよく見かけるサムネイルです。これらの処理には時間がかかりますが、たまにしか実行されません。メインのサーバーにサムネイル処理を置くと、他のサービスに影響を与える可能性があります。そこで、ラムダにサムネイル処理を移動することで、メインサーバーの負荷を軽減します。
３.目的・目標
目的：ラムダで画像を圧縮しS3にアプロードする仕組み
- 目標１：構成・処理流れを理解
- 目標２：S3とラムダの連結を理解
- 目標３：sharpライブラリで圧縮を理解
4.構成図・経過
| ステップ | 解説 |
|---|---|
| １ | クライアントから画像を一時的なバケツにアップロード |
| 2 | 一時的なバケツは画像情報を含むイベントでラムダファンクションをトリガー |
| ３ | ラムダファンクションは画像情報を通じて画像をダウンロード |
| 4 | 画像を処理 |
| 5 | 処理してから主なバケツに画像をアップロード |
S3ライフサイクルについては、元画像を保存する場合は設定が不要ですが、要らない場合は設定が必要です
？何故：バケツは二台がありますか？
Recursive invocationを避けるためです。
サークルトリガー形でラムダが繰り替えてトリガーして止まりません。したがって、利用金がすごく発生します
５.評価
| メリット | デメリット |
|---|---|
| S3はサーバーレスのため、をcpuやramなどの計算力が自動的にスケールできて重い処理が対応可能 | 頻度が多い場合は料金がすごくかかる |
| 本サーバーから他所に処理を移転するため、本サーバー負荷を共有 | 若干処理時間がかかる |
| S３言語対応の限りでは実装可能 |
処理の頻度を考慮して決定する必要があります。
6.その他
上記の概要は、全体的にS3の前処理に関するものです。そのため、これはサムネイル処理に限らず、他のユースケースにも応用可能です。
例：ウィルススキャンやデータトランスフォームなど
最後
最後までご覧いただき、ありがとうございます。
内容にご興味があれば、コメントやハートを残していただけると嬉しいです。
次のパート２もぜひご覧ください。
参考