Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Lambda(Python)の リファクタリングが好きなんです
Search
komakichi
April 21, 2025
Programming
5
320
Lambda(Python)の リファクタリングが好きなんです
Event: Toranomon Tech Hub 第三回
Event URL:
https://toranomon-tech-hub.connpass.com/event/344781/
komakichi
April 21, 2025
Tweet
Share
More Decks by komakichi
See All by komakichi
JAWS DAYS 2025 re_Cheers: WEB
komakichi
0
170
JAWS Days 2025のインフラ
komakichi
1
510
Amazon Bedrock + AWS Chatbot ノーコードでAIボット作成
komakichi
0
130
マルチエージェントで AWSサービスと会話がしたい
komakichi
1
62
Amazon BedrockとIoTで 実家情シスを卒業する
komakichi
3
130
もう実家に手頃な情シス娘は不要!Bedrockでもう一人の娘を作る
komakichi
2
280
AWS SAMとX-Rayで Lambdaの遅延を可視化
komakichi
0
69
CloudWatch Logs Insightsで 定期業務をスマートに
komakichi
1
640
AWSの生成AI活用事例集GenUを使い倒す
komakichi
1
1.5k
Other Decks in Programming
See All in Programming
#kanrk08 / 公開版 PicoRubyとマイコンでの自作トレーニング計測装置を用いたワークアウトの理想と現実
bash0c7
1
770
Google Agent Development Kit でLINE Botを作ってみた
ymd65536
2
250
dbt民主化とLLMによる開発ブースト ~ AI Readyな分析サイクルを目指して ~
yoshyum
3
1k
ソフトウェア品質を数字で捉える技術。事業成長を支えるシステム品質の マネジメント
takuya542
2
13k
地方に住むエンジニアの残酷な現実とキャリア論
ichimichi
5
1.5k
Code as Context 〜 1にコードで 2にリンタ 34がなくて 5にルール? 〜
yodakeisuke
0
130
A full stack side project webapp all in Kotlin (KotlinConf 2025)
dankim
0
120
なんとなくわかった気になるブロックテーマ入門/contents.nagoya 2025 6.28
chiilog
1
270
Azure AI Foundryではじめてのマルチエージェントワークフロー
seosoft
0
170
なぜ「共通化」を考え、失敗を繰り返すのか
rinchoku
1
650
git worktree × Claude Code × MCP ~生成AI時代の並列開発フロー~
hisuzuya
1
570
技術同人誌をMCP Serverにしてみた
74th
1
650
Featured
See All Featured
Raft: Consensus for Rubyists
vanstee
140
7k
Documentation Writing (for coders)
carmenintech
72
4.9k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
29
1.8k
A Modern Web Designer's Workflow
chriscoyier
695
190k
Making Projects Easy
brettharned
116
6.3k
For a Future-Friendly Web
brad_frost
179
9.8k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
251
21k
Art, The Web, and Tiny UX
lynnandtonic
299
21k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
34
3.1k
Building Adaptive Systems
keathley
43
2.7k
Testing 201, or: Great Expectations
jmmastey
43
7.6k
Connecting the Dots Between Site Speed, User Experience & Your Business [WebExpo 2025]
tammyeverts
6
300
Transcript
Lambda(Python)の リファクタリングが好きなんです Toranomon Tech Hub 第三回 Kumi Komaki 2025/04/21
WHO AM I ? X:@komakichidev 6 所属:某SIer (ご近所ですf 6 職種:
Webエンジニア(バックエンドメインf 6 最近ハマってること: テトリス。むずい。 小巻 玖美(こまきち) 実は AWS と Figma が一番好きなサービス このスライドもFigmaの機能で作成
早速ですが…
早速ですが… バックエンド開発しているよ!!! という方
Lambdaを使って絶賛開発中だぞ!! という方
AWS Lambdaのリファクタリングについて ver. Python 今回コードベースの話、というよりはマインド的な話の方が多めです 今日のお話
AWS Lambdaのリファクタリングについて ver. Python 今日のお話 結論 日々の開発の中で、Lambdaをリファクタリングしましょう 今回コードベースの話、というよりはマインド的な話の方が多めです
ざっくりアジェンダ GC なぜリファクタリングをした方がいいの0 2C AWS Lambda のリファクタリングの具体 C リファクタリングしましょ( @C
まとめ 「あーリファクタリングってやっぱり大事だな」って思ってもらえたら嬉しい
あるプロジェクトの課題 (アーキテクチャにはLambdaがあると仮定) この機能開発して欲しい。どのくらいでできますか? え、そんなにかかるんですか? xxヶ月かかってしまいそうです 既存のコードの改修が辛くて、 単純な機能追加でも多くかかってしまう
リファクタリングはいつやる? 来たときよりもきれいにして終わる 「リファクタリングしなきゃ」とは思っており、一部やっている部分もあるが 負債が多く取り除けていない状態 → リファクタリングは、いつやるのが適切か? A. 駄目なコードを見かけるたびに、少しずつ改善していく 機能の追加やバグ修正の最中にリファクタリングをする
どうやって顧客に説明すべきか? “管理者や顧客によっては、コードの健康状態 が生産性にどれだけ影響を与えるのか、技術的 に認識できないこともあるでしょう。 そうしたときのために、いささか問題発言的な アドバイスをしておきます。 「彼らにはだまってリファクタリングする」で す。” Martin Fowler
著, 児玉公信・友野晶夫・平澤章・梅澤真史 訳, 『リファクタリング(第2版):既存のコードを安全に改善する』p55 OBJECT TECHNOLOGY SERIES, 2019年12月1日
最初のスライド この機能開発して欲しい。どのくらいでできますか? え、そんなにかかるんですか? xxヶ月かかってしまいそうです 既存のコードの改修が辛くて、 単純な機能追加でも多くかかってしまう
最初のスライド この機能開発して欲しい。どのくらいでできますか? え、そんなにかかるんですか? xxヶ月かかってしまいそうです 既存のコードの改修が辛くて、 単純な機能追加でも多くかかってしまう こういう場合、 大抵他の問題も併発している
6@ FatなLambda関数になってい$ "@ テストコードが無く、修正後に不具合が出ることがある WR デプロイ/ロールバック手順が複雑 課題を整理する なぜ既存のコードの改修が辛いのか? それによる他への影響 k@
Lambdaのパフォーマンスが悪い s~ 開発速度の低下でリリースまでのリードタイム増加
FatなLambda関数になっている 50 デプロイ/ロールバック手順が複雑 Y テストコードが無く、修正後に不具合が出ることがある 課題を整理する なぜ既存のコードの改修が辛いのか? それによる他への影響 m
Lambdaのパフォーマンスが悪い u 開発速度の低下でリリースまでのリードタイム増加 コード出てくるのこの1だけです
1-1 FatなLambda関数改善 A 関数分割して意味付けす7 A docstringもつければ、関連づいた関数 から概要を確認することもできる
1-1 FatなLambda関数改善 handler の見通しが少しだけ良くなった
環境変数は関数外で取得する(パフォーマンス対策) Lambdaの初期化時にのみ実行される (コールドスタート時のみ) コールドスタート / ウォームスタート 関係なく毎回実行される 1-2 FatなLambda関数改善 環境変数とクライアントの初期化などは関数外に
1-2 FatなLambda関数改善 パフォーマンスの対応したら、コードも 少し読みやすくなった
1-3 よりパフォーマンスや運用を意識するなら Powertools for AWS Lambda (Python) を検討する (CloudWatchの費用はかかるので注意) Powertools
for AWS Lambda とは? AWS Lambda関数の開発を効率化するためのユーティリティライブラリのセット 簡単にトレース、構造化ロギング、カスタムメトリックスなどの導入可能 https://docs.powertools.aws.dev/lambda/python/latest/ Á Lambdaのコンテキストログなどを自動で含め¶ Á X-Rayへの自動キャプチË Á コールドスタート時にカスタムメトリクスを仕込む
1-4 コールドスタートを削減するなら in Python 関数側の改善を進めても、最終的にコールドスタートが壁になる でも、今は試せる方法がたくさんある(以下一例) https://tmokmss.hatenablog.com/entry/analyze-and-improve-lambda-python-coldstart あまり使わないimportは関数内で使用す q
Lambda SnapStart を使用す s Provisioned Concurrency を設定す コンテナLambdaに変え j Rustバインディングをしてみる 個人的には上から順に 考える
1-4 ざっくり紹介 )( あまり使わないimportは関数内で使用する 頻繁に使わないが、初期化時に読み込むと時間がかかるライブラリを内部で定義
1-4 ざっくり紹介 ' Lambda SnapStart を使用する 名前から察せるように Lambda の SnapShot
を裏側で作ってくれる機能 2024年11月 に Python (Python 3.12 以降) に対応! ' Provisioned Concurrency を設定する 決めた数(同時並行数)で Lambda を事前に立ち上げておく機能 使用にはプラスで費用がかかるので、コストは注 コンテナランタイムでは使えない 使用にはプラスで費用がかかる (リクエスト数、メモリ、同時実行数次第でコスト増加)
1-4 ざっくり紹介 % Rustバインディングをしてみる Rust の関数やロジックを Python から直接利用可能にする仕組み (他の言語からも可能) Python
と Rust を組み合わせて、良いとこどりみたいにできるらしい (私はまだ実際には試したことがない②) l% コンテナLambdaに変える キャッシュやデータ転送を効率化し、コールドスタートの時間が短縮される仕組み。 pandasなどの大きめのライブラリをimportしている時などに特に有効。 (私はまだ実際には試したことがない①) https://developers.cyberagent.co.jp/blog/archives/44067/ https://qiita.com/dera_p/items/477292201a36e0859f0f
FatなLambda関数になっている 50 デプロイ/ロールバック手順が複雑 Y テストコードが無く、修正後に不具合が出ることがある 課題を整理する なぜ既存のコードの改修が辛いのか? 話は戻り それによる他への影響
q Lambdaのパフォーマンスが悪い y 開発速度の低下でリリースまでのリードタイム増加
# テストコードが無く、修正後に不具合が出ることがある これはテストを少しずつ増やしていくしかない じゃあ、どうやって増やしていくか?
# テストコードが無く、修正後に不具合が出ることがある これはテストを少しずつ増やしていくしかない じゃあ、どうやって増やしていくか? 不具合が発生した処理のテストコードから 追加することを徹底する 不具合が出たときに、 該当箇所だけ修正して終わりにしていないか?
FatなLambda関数になっている 50 デプロイ/ロールバック手順が複雑 Y テストコードが無く、修正後に不具合が出ることがある 課題を整理する なぜ既存のコードの改修が辛いのか? それによる他への影響 m
Lambdaのパフォーマンスが悪い u 開発速度の低下でリリースまでのリードタイム増加 リファクタリングに絞った話
Lambdaのパフォーマンスが悪い リファクタリングの優先度が下がった結果、修正しづらいコードが残り パフォーマンスチューニングがしにくい状態 リファクタリング ≠ 他に優先したいことがたくさんある 量が多いので特別期間を取って対応する、となると足踏みしてしまう 未来への投資? 息をするのと同じように
リファクタリングすることの大切さ
今後の機能追加や開発の選択肢を持てるようにTidyへ “「次にどのような振る舞いを実装できるか」 は、実装する前から、それ自体に価値がある。 これには驚いた。終わらせたことに対して対価 が支払われるのだと思っていた。そうではな かったのだ。次にできることに対して支払われ ることがほとんどだった。” Kent Beck 著,
吉羽龍太郎・永瀬美穂・細澤あゆみ 訳 『Tidy First?―個人で実践する経験主義的ソフトウェア設計』, p90 System/Network, 2024年12月発行
まとめ 5 AWS Lambda のリファクタリングは、小さい対応から大きい対応ま 5 開発しながら少しずつリファクタリングしましょう 見たときよりもきれいにして終わる
Thank You