この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
発表の要点
サーバーレスアプリケーションで成長するビジネスを支えるために、開発者として何ができるか？を議論しました。このセッションでは、案として
- Lambda Funciton のコードを構造化する
- ユニットテストよりもE2E テストに振り切る
- ログを一箇所に集める
ということを実践し、そのときの具体的な手順と結果を話しました。
コードを構造化する
Lambda Function のコードを ハンドラ、ドメイン、インフラストラクチャにレイヤ化します。ただし、Lambda Function の "Function" の側面をないがしろにしないよう、ガチガチに分類するのではなく、コード置き場の方針として考える程度にします。ビジネスが成長するにつれドメインも育っていくので、その過程で繰り返し振り分けていくのが良いです。
E2Eテストする
AWSマネージドサービスは日々進化を続けています。そんな状況では、サーバーレスアプリケーションを手元でテストすることにこだわりモック化・ダミーサービスの用意に奔走するよりかは、最初からE2Eテストに振り切ってしまったほうがお得ではないか？という話です。E2Eテストをするにあたって、Lambda Function で使う環境変数のをパラメータストアを介して共有する方法や、事前条件を達成するための pytest @fixture の使い方を述べました。
ログを出す
「当たり前だよねー」となりがちですが、アプリケーションにとっての必要十分なログというのはかなり難しいです。サーバーレスアプリケーションの場合は Lambda Function が別でもログフォーマットを統一してしまい、AWS Athena や CloudWatch Logs の専用グループに出していく方針が良さそうだと考え、実装してみました。
まとめ
サーバーレスの「アプリケーション」としての特性に注目し、これまでWebアプリケーションでも実施されてきた設計、テスト、ロギングを適用しました。良かったところとしては、これら3つの要素が満たされている場合、追加・修正のハードルが大幅に下がったところがあります。一方難しいなと思うところは、あまり重厚にやりすぎてもかえってかえって足かせとなるため、どこまで設計やテストを忠実に行いどこを切り捨てるか、落とし所の判断が必要だという点です。これからもサーバーレスアプリケーションで構築されたアプリはどんどん世の中に出てくると思うので、どんな設計方針か、積極的にインプットしていきたいと思います。
会場の様子
スクリーンの使い方うまい @AWS 西谷さん
#ServerlessConfTokyo pic.twitter.com/XqccvXtSlY
— yamada kohei (@kooooooooohei) 2018年9月29日
ところどころに出る会場の昭和臭
昭和フォント #serverlesstokyo pic.twitter.com/JKGXiYi8iW
— Yusuke Wada 和田祐介 (@waddy_u) October 1, 2018
Aibo かわいい
Aiboとたわむれた pic.twitter.com/Lt9M5QvMvq
— Yusuke Wada 和田祐介 (@waddy_u) October 1, 2018
吉田さん、スタッフの皆様
とても楽しかったです。ありがとうございました。
すべての皆さんに、圧倒的感謝！！ #serverlessconf #serverlesstokyo #serverlessconftokyo pic.twitter.com/vAimyhFyCW
— 吉田真吾 / CYDAS & Section-9 (@yoshidashingo) September 29, 2018
14
