インフラエンジニアのためのLambda実践入門
 1 2023.11.6
 
 JAWS-UG朝会 #51


2 自己紹介 ★ ハンドルネーム ○ つくぼし ★ 所属 ○ AWS事業本部コンサルティング部 ○ ソリューションアーキテクト ★ 最近ハマっているAWSサービス ○ AWS Lambda ○ AWS CDK ★ SNS/ブログ ○ Twitter(@tsukuboshi0755) ○ DevelopersIO(つくぼし)

3 Lambdaを一から 新規開発した事はありますか？

4 インフラエンジニアの方にも Lambdaを解決手段の一つとして持って欲しい

5 今日話す事 1. Lambdaのおさらい 2. Lambdaのポイント①：技術選定 3. Lambdaのポイント②：アーキテクチャ設計 4. Lambdaのポイント③：コーディング規約 5. 最後に

6 Lambdaのおさらい

7 Lambdaとは？ AWS Lambda は、サーバーレスでイベン ト駆動型のコンピューティングサービスで あり、サーバーのプロビジョニングや管理 をすることなく、事実上あらゆるタイプのア プリケーションやバックエンドサービスの コードを実行することができます。 参考：AWS Lambda（イベント発生時に コードを実行）

8 サーバレスって言うんだから、 サーバの事を全く考えなくても良いって事？

9 サーバレスって言うんだから、 サーバの事を全く考えなくても良いって事？

10 Lambdaのメリット(所感含む) ● L4以下のネットワークを基本意識しなくて良い ○ VPC/Subnet/Gateway各種/Endpoint各種/SG等の設定がいらないの最高！ ○ どうしても必要であればVPC Lambdaもあるけど... ● OSを意識しなくて良い ○ OS仕様を気にしなくて良いのは楽！ ○ ECS Fargateも同様 ● 大量のリクエストがなければ想定外の高額利用につながりにくい ○ EC2やECSは使用せず放置するだけでもお金がかかる... ○ Lambdaはリクエストがなければ放置してもお金がかからない！

11 Lambdaのデメリット(所感含む) ● 制限事項が結構多いので事前確認が必要 ○ メモリは10GBまで ○ エフェメラルストレージは10GBまで(VPC LambdaであればEFSを使用可能) ○ 実行時間上限は15分間まで ○ 同時実行数は東京リージョンの場合1000回まで ● ステートフルは苦手 ○ 状態の保持が必要なシステムの基盤には向いてない ● カスタムレイヤーを作るとモジュールを意識する必要がある ○ 結局ミドルウェア/ソフトウェア運用が必要になる場合が多い

12 ネットワークやOSは、ほぼ考える必要なし！

13 一方でメモリやストレージ、モジュール等は引き 続き検討する必要があります

14 Lambdaのポイント①：技術選定

15 Lambdaを採用するべきなのはどんな時？

16 アプリケーション実行基盤の比較 EC2 ECS Fargate Lambda OS管理 必要 不要 不要 ネットワーク管理 必要 必要 (L4以下)不要 メモリ 最大24TB 最大120GB 最大10GB エフェメラル ストレージ 最大 24 x 13980 GB 最大200GB 最大10GB

17 Glue Python Shellという選択肢 ● Lambdaと似たような使い方ができるサーバレスサービス ○ (L4以下の)ネットワークを意識する必要なし ○ OSを意識する必要なし ● Lambdaよりも以下の点で優位 ○ メモリは16GBまで ○ エフェメラルストレージはローカルディスクで20GBまで ○ 実行時間は上限なし ● 使用する際は以下の点に注意 ○ 言語はPythonのみ ○ 一般的にLambdaより利用料金が高くなりやすい(メモリ及び処理時間による)

18 Lambdaのポイント②：アーキテクチャ設計

19 Lambdaを採用する場合でも アーキテクチャ設計は必要です

20 構築手法のオススメ ● IaCツールを使う必要がなければ、コンソールでの構築でもOK ● IaCツールを使う必要がある場合、Lambda初心者であればAWS SAMが オススメ(個人的所感) ○ CloudFormationの拡張ツールなので、CloudFormationの公式ドキュメントやブロ グの情報をそのまま使えて、習得難易度も低い ○ ビルド環境をローカル/Dockerコンテナのいずれか選択した上で、レイヤーの作成を 自動化できる ○ 無料で使用可能 ● LambdaにNode.jsを採用する場合は、CDK(TypeScript)もあり ○ 言語をTypeScriptで統一できるため、開発コストを下げられる

21 IaCツールの比較 Cloud Formation SAM CDK Terraform Serverless Framework 開発会社 AWS AWS AWS HashiCorp Serverless 料金 無料 無料 無料 無料 一部有料 レイヤー 作成自動化 公式対応 未サポート サポート済 サポート済 未サポート サポート済 難易度 (所感含む) 低 低 中 低 低

22 ランタイムのオススメ ● 慣れ親しんだ言語があれば、その言語を採用する形でOK ● 特にこだわりがない場合、Lambda初心者であればPythonがオススメ(個 人的所感) ○ 公式ドキュメント、ブログともに情報が一番充実している印象 ○ 途中からGlue Python Shellに乗り換える選択肢も視野に含められる ● IaCツールにCDK(TypeScript)を採用する場合は、Node.jsもあり ○ 言語をTypeScriptで統一できるため、開発コストを下げられる

23 CPUアーキテクチャにおけるarm64という選択肢 ● 従来のx86_64の代わりに、arm64を選択する事も可能 ● x86_64よりも以下の点で優位 ○ 処理時間が短くなる傾向がある ■ 参考：AWS Lambda x86_64とarm64で処理速度どれだけ違うか調べてみた ○ 実行時間あたりの料金が安い ■ 参考：AWS Lambda 料金 ● x86_64で動作するコードをarm64に移行したい場合、必要なモジュール がarm64でも使用できるか互換性に注意

24 シークレット管理サービスの比較 SSM Parameter Store (Secure String) Secrets Manager 料金 APIコールのみ シークレット+APIコール 自動ローテーション 未サポート サポート済 コンプライアンス検証 未サポート サポート済 →シークレットの運用方法に応じて使い分けると良い。

25 エラー通知手法の比較 ● 大まかに分けると以下の5種類のパターンがある ○ 直接Publishパターン：コード内でSNS Publish APIを呼び出し通知 ○ DLQパターン：Lambdaのデッドレターキューサービスを設定し通知 ○ 失敗時送信先パターン：Lambdaの失敗時送信先を設定し通知 ○ メトリクスフィルターパターン：Lambdaのログからメトリクスフィルターでエラーを検知し、 CloudWatch Alarm経由で通知 ○ サブスクリプションフィルターパターン：Lambdaのログからサブスクリプションフィルターでエ ラーを検知し、通知用のLambdaを呼び出して通知 ● 詳細は以下の記事を参照 ○ 参考：Lambda でバッチ処理を構築する際のエラー通知パターン 5選 ○ 参考：Lambdaの例外エラーの通知方法を考える

26 Lambdaのポイント③：コーディング規約

27 Lambdaの開発を始める前に 一通りコーディング規約を定めておこう

28 リンター/フォーマッターとコメントの統一 ● リンター/フォーマッターは最初に有効化しよう ○ Pythonであれば、Flake8 / Black / isort / mypy あたりがあると良さそう ○ 参考：Pythonのリンター・フォーマッターをしっかりと理解する（Flake8, Black, isort, mypy） ● コメントを入れる基準を事前に決めておこう ○ 大まかにはデータ構造やアルゴリズムの説明、及び変数宣言や判定式に対してコ メントを入れる ○ ブロックコメントとインラインコメントの使い分けを定めよう

29 ロギングの実装 ● Lambdaはログ出力を明示的にコードに記述しない限り、CloudWatchに ログを吐き出してくれないので注意 ● Pythonであれば、loggingモジュールを用いて以下のロギング設定用 コードを記述しておけばOK ○ 通常はINFOレベル以上のログを出力 ○ Lambdaに環境変数LOG_LEVELを設定する事で、ログレベルの変更が可能 ● Powertools for AWS Lambda (Python)を使う選択肢もある ○ 参考：Python の AWS Lambda 関数ログ作成 logger = logging.getLogger() logger.setLevel(logging.getLevelName(os.getenv("LOG_LEVEL", "INFO")))

30 例外処理の実装 ● 機能要件を満たすのに満足してしまい、意外と例外処理の実装を忘れる 事があるため注意 ● 例外処理を実装する際、事前に以下の認識を統一しておく ○ 検知するエラーの定義 ○ 実装対象の関数 ○ 出力するエラーメッセージ def lambda_handler(event, context): try: # 処理内容を記述 except Exception as e: logger.exception("Exception occurred: %s", e) raise e

31 Lambdaコードの分割 ● Lambdaのコードが肥大化してきた場合、コード分割がオススメ ○ まとまった関数毎にファイル単位で分割すると、コード全体が見やすくなる from libs import download_log, process_log, upload_log def lambda_handler(event, context): # libs/download_log.pyのmain関数を呼び出し、生ログをダウンロード raw_log = download_log.main() # libs/process_log.pyのmain関数を呼び出し、生ログを加工 processed_log = log_process_log.main(log) # libs/upload_log.pyのmain関数を呼び出し、加工済ログをアップロード upload_log.main(processed_log)

32 テストコードの開発 ● テストコードは、Lambdaコード本体と同時に開発を進めよう ○ Lambdaコード本体の実装後にテストコードを実装しようとすると、テスタブルなコー ドにするためのリファクタリングが必要になり余計に時間がかかる ● 事前にテストする範囲を定めておこう ○ Pythonコードの単体テストを行うだけであれば、pytestの導入で十分 ○ AWSリソースの結合テストを行いたければ、各種AWSサービスをモックする LocalStackやmotoを追加で導入しよう ● 詳細は以下の記事を参照 ○ 参考：サーバーレス開発環境とテスト ○ 参考：AWS x Pythonで自動テストを書いていくあなたに

33 余談：AI開発支援ツール(超オススメ！！！) ● AI開発支援ツールを使用すると開発効率が段違いに上がるため、業務使 用に支障がなければぜひ導入をオススメしたい ● オススメのツールはChatGPTとGitHub Copilot ○ ChatGPT：プログラムのサンプル作成や、トラブルシューティングに使用。GPT3.5 でも十分役立つが、個人的にはGPT4がオススメ。 ■ 参考：【ChatGPT】個人的お気に入りプロンプトまとめ ○ GitHub Copilot：VSCodeを使用する全エンジニアが入れるべき(超個人的所感)。 コーディングはもちろん、ドキュメント作成やブログ執筆にも役立つ。 ■ 参考：VSCodeでGitHub Copilotを使ってみた

34 最後に

35 まとめ ● そもそもLambdaを採用すべきか、他と比較して技術選定をしよう ○ EC2 / ECS や Glue Python Shellという選択肢もあるよ ● Lambdaを採用する場合でも、アーキテクチャ設計は必須です ○ 構築手法、ランタイム、CPUアーキテクチャ、シークレット管理、エラー通知周りは最 低限検討しておこう ● Lambdaの開発を始める前に、コーディング規約を定めよう ○ リンター/フォーマッター、コメント、ロギング、例外処理、コード分割、テストコード周り は、開発を始める前に認識を合わせるべき ● AI開発支援ツールを制する者はLambda開発を制す！

36 インフラエンジニアにこそ 恐れずLambdaの世界に飛び込んで欲しい！

37