こんにちは、inadyです。
今回は、弊社SREチームで管理しているAWS Lambdaのテストコード運用ルールについてご紹介します。
背景
SRE(インフラ)チームでは、様々な用途にAWS Lambdaを活用しています。
たとえば、ログを変換する関数や、ECSのイベントを検知してSlackに通知する関数などがあります。
現在のところ、合計すると約50種類ありました。
さらに、その関数を最大で20環境ほどで使っているため、リソース数は膨大になります。
1つ1つのコードは小さなものがほとんどなのですが、やっているタスクは多種多様という感じです。
これらは、主に運用で使われている関数であるため、頻繁にコードを変更するということはありません。
一方で、AWS Lambda PythonバージョンのEOL対応や、使用しているパッケージのセキュリティアップデートなどで、年に数回だけメンテナンスする必要があります。
バージョンをあげた後は、問題なくコードが動くかどうか確認する必要があります。そのためにはテストコードが用意されていると安心ですよね？
一方で、コストパフォーマンスの観点から、 50種類、全てのLambdaにテストコードを記述するのは現実的ではありません。
テストコードの重要性と工数のバランスを考える
テストコードの重要性
テストコードがない場合、「AWS環境で実際に動かしてみて動作確認する」という手法を取らざるを得ません。
しかし、Lambda関数の種類が多いと、この手法での動作確認は工数が大幅に増加してしまいます。
ユニットテスト、または結合テストのテストコードがあれば、簡単に動作の確認ができます。
また、網羅的に動作検証ができるため、バグが混入するリスクを大幅に減らすことができます。
テストコードを書く工数
一方で、テストコードを書くには時間と労力が必要です。
SREチームで管理しているLambda関数は、1つ1つのコードは小さなものがほとんどなのですが、やっているタスクは多種多様です。
つまりテストの実装方法も、その都度どうやってテストを実装するかを考える必要があります。
また、テストコードの保守も考慮する必要があります。
コードが変更されるたびに、テストコードも更新する必要があるため、その工数も見積っておく必要があります。
バランスの取れたアプローチ
テストコードの重要性と工数のバランスを取るために、サービスレベルに応じたテストコード運用ルールを考えてみることにしました。
Lambda関数サービスレベルの設定
まず、Lambdaごとに重要度に応じたサービスレベルを設定します。
HIGH: 重要なLambda
ユーザへのサービス提供や本番環境の運用に使用しているLambdaで、停止すると重大な影響があるものです。
当社の例だと、リリース時にアプリをメンテナンスモードに入れるLambdaがあります。
このLambdaが動かないと、リリースを開始できないため非常に重要です。
MID: やや重要なLambda
ユーザへのサービス提供や本番環境の運用に使用しているものの、停止しても重大な影響がないLambdaです。
当社の例だと、バッチの実行時間監視をしているLambdaが該当します。
このLambdaが壊れるとバッチの実行時間が超過したときにアラートが発報されないことになりますが、直ちにユーザ影響が出るわけではありません。
LOW: その他のLambda
本番環境で使っていないLambdaです。
開発環境の構築や保守に使っているLambdaが該当します。
サービスレベルごとのテストコードルール
次にサービスレベルごとに、テストコードを書くか？ 書かないか？のルールを定めます。
サービスレベル:HIGH
テストコードの記述を必須としました。
運用中のシステムの信頼性を確保するためには、テストコードが不可欠と判断しました。
サービスレベル:MID
テストコードの記述は開発者の任意としました。
実装者が、テストコードの開発コストとリスクを鑑みて、テストコードを書くかどうかを考えます。
サービスレベル:LOW
こちらも、テストコードの記述は開発者の任意としました。
開発者が必要と判断した場合にのみ、テストコードを記述します。MIDよりもさらにテストコードを書く優先度が下がります。
(補足)Lambdaの廃止活動
そもそもLambdaがなくなれば、テストも不要になります。
例えば、Amazon Kinesis Data Firehoseの新機能により、CloudWatch Logsのログを変換するLambdaが不要になったため、これを削除しました。
積極的にLambdaを廃止するという活動も行っています。
おわりに
今までは、正直「テストコードが整備されていなくてアップデートが怖い」「Lambdaの数が多くてテストコード開発に手がつけられない」という状況でした。
サービスレベルの観点からテストコードを書くべきLambdaを限定することで、「Lambdaの数が多くてテストコード開発に手がつけられない」という課題を解決しました。
サービスレベルが高いものは、テストコードがあるので、安心してアップデート作業を実施できます。
またサービスレベルが低いものは、テストコードがないパターンがありますが、「テストが無いせいで壊れても、(ユーザ影響もないし)仕方がないよね」と整理できたことで、「テストコードが整備されていなくてアップデートが怖い」という問題も解消できました。
今後も、運用を最適化し、より安定したサービス提供を目指していきます。
Discussion