[レポート]AWS Lambda Powertools: 1000万ダウンロードへの道のりから得た教訓 #reinvent #OPN306
データアナリティクス事業本部の鈴木です。
AWS re:Invent 2022の、セッション番号OPN306の『AWS Lambda Powertools: Lessons from the road to 10 million downloads』を聴講したのでレポートです。
セッションについて
登壇者
Heitor Lessa, Principal SA, DevAx, Amazon Web Services
Session level
300 - Advanced
Session type
Breakout Session
動画
セッション概要
AWS Lambda Powertoolsは、組織がサーバーレスのベストプラクティスを早期に発見し、迅速に取り入れることを支援するオープンソースライブラリです。2年の間に、Powertoolsは小さい試験的なプログラムから急成長するプロジェクトになりました。この急成長によって、新機能と運用しやすさのバランス取り・バグ報告やRFCの対応・ドキュメントの拡大と再設計から、コントリビュートをしやすくしたり、公開ロードマップの提供したりに渡って、さまざまな課題と対応が発生しました。このセッションでは、AWSLambda Powertoolsの現状、この成長がどのように支えられたか、過去2年間で学んだ重要な教訓、そして次に何が待っているのかを学びます。
発表概要
最初にAWS Lambda Powertoolsの歴史についての説明があった後、AWS Lambda Powertoolsを開発していくにあたって発生した課題と学んだ教訓について説明頂きました。最後に、今後に向けてどのような活動をしたいか紹介がありました。この記事では簡単にですが、各々セクションを分けてご紹介できればと思います。
なお、最後に今回のセッションで紹介した資料のリンクをまとめたページの紹介があったので、QRコードを先に掲載しておきます。
AWS Lambda Powertoolsの歴史について
2020年にServerless Lensを立ち上げ、自分のアーキテクチャやアプリケーションを評価し、レビューできるツールを提供しました。
その中で特に多くのユーザーが課題を持っていたのが、トレース・ロギング・メトリクス生成だったそうです。このようなレビューはたいていリリース前に近い後ろの工程で行われがちなため、なんとかより前の工程で解決できるようにするべく、AWS Lambda Powertoolsを開発したそうです。この経緯で、AWS Lambda Powertoolsはトレーサー・ロガー・メトリクスの機能を備えています。
AWS Lambda Powertoolsは発表時点で2000万ダウンロードにまで達していますが、この過程において学んだオープンソースプロジェクトにおける教訓をご紹介頂きました。
リリースノート
まず人間によるリリースノートを作成し、だいたい5分くらいかけて、まずユースケースが明確かどうか、それが何であるかを理解できるかどうかをピアレビューするようにしました。オープンソースのプロジェクトでは、できるだけ早くリリースしようとする傾向があり、そのリリースノートは完全に自動化されがちです。もちろん一部の人には有効なものの、AWS Lambda Powertoolsはさまざまなユースケースがあるので、このようにした方がよかったようです。リリースノートにより、開発者がAWS Lambda Powertoolsのお客様のどのようなユースケースを意図しているかを確認できるようにしました。また、関係者への感謝のコメントも入れました。
曖昧さへの対応
文書化により曖昧さを減らしたのポイントでした。テナントと呼ばれる基本的な設計原則(あるいは哲学と呼べるもの)を策定しました。テナント以外にタスクの優先順位づけに使ったものなども文書化しました。
コントリビューション
過去12カ月ほどの間に公開されたすべてのIssueを調査し、複数のカテゴリーとIssueテンプレートに分けました。
コントリビューターを目指す人が自分には貢献できることがないと思ってしまったり、逆に簡単すぎるPRが大量にきてしまったりということがないよう、良い貢献とはどのようなものかを互いに理解できるようにするためでした。
pre-commit hookというプロジェクトを作成し、プロジェクトが自動で一貫性を保つように工夫しました。また、また、CIが実行されるのを待ちたくない人向けに、make prでチェックがすべて適切に実行されることを確認できるようにもしました。
コントリビューションガイドを作成し、プロジェクトの規約やどのようなペルソナを求めているのか分かるようにもしました。
テクニカルライティング
コードを書くのと同じくらいドキュメントの整備が重要なことを開発メンバーやコントリビューターと共有するため、メンタリングも行ったそうです。
ドキュメントの統一感
pre-commitを使ってドキュメントに加わった変更をチェックし、同じ人物が作ったかのようにレイアウトなどを統一しているそうです。
バランスを取ること
オープンソースの開発は、別に日々の仕事があり、副業としておこなっているケースがあるので、例えばそのような場面でバランスを取りながら進めることにも課題があったそうです。これは生活面だけではなく、どの機能を優先するかについても同様のようでした。
対応の参考例の一つとして、The Hard Parts of Open Sourceの公演ビデオを参考にしたそうです。
また、行動規範も新しく策定しました。
透明性
今取り組んでいること、残件が何か、そして助けを必要としていることは何なのかが分かるようにしました。GitHubのProjectsを使い、ロードマップやガイドラインを明示的に分かるようにして、プロジェクトの透明性を上げるようにしたそうです。
また、議論が白熱した際により安全に対処できるよう、コミュニケーションツールを変更したりもしたそうです。
リリースオーバーヘッド
リリースはリージョンの増加などで結果の見やすさや実行時間に影響があったため、現状ではGitHub Actionsにて30分程度で済むようになっているそうです。結果も整理されており、リージョンの追加も簡単になったそうです。
実行結果はaws-lambda-powertools-pythonレポジトリのActionsタブのReleaseワークフローから確認できたので興味がある方はぜひみてみてください。
エンドツーエンドテスト
実行環境がサーバーレスの場合、コントリビューターが自分でお金を払ってテスト環境を準備している可能性があります。そのようなことが起こらないようにしました。プロジェクトは以下のように構成し、ベースとなるクラスを継承するだけで使えるようにしました。
また、実際にトレースが作成されたかどうか確認するようなツールの作成や、コストダウンのために並列実行するような仕組みづくりにも取り組んだそうです。
影響力
AWS Lambda Powertoolがどの程度の影響力を持ったのか測定するため、どうしようとしたかについてです。
AWS Lambda Powertoolsでは、以下の3点を重要視したそうです。AWS Lambda PowertoolsのLambdaレイヤーを使用している件数がまず明確な値として取得ができます。また、AWS Lambda Powertoolsの40%程度はコントリビューターからの貢献によるものなので、その割合はいかにAWS Lambda Powertoolsが関心を持たれているツールなのか表しています。最後に関係者へのフィードバックで、このフィードバックにより良い影響を与えられるかどうかも重要なポイントでした。
今後に向けて
最後に今後に向けての機能の紹介でした。現在.NET向けのツールをプレビューで公開しており、セッション公開時点では最もフィードバックを必要としているそうです。
パフォーマンス測定のための取り組みや、イベントソースから渡されるデータに対してテストしやすいような工夫もしているそうです。
Lambda向けのコードとそれ以外に向けた機能を分けていくことや、テストに関する工夫にも時間を使っていきたいそうです。
終わりに
今回はre:Invent2022で行われた『AWS Lambda Powertools: Lessons from the road to 10 million downloads』のレポートでした。
AWS Lambda Powertoolsの開発を題材に、さまざまなプロジェクトで発生するであろう課題と、その対処例を学ぶことができました。私の場合は、特にGitHubを上手く使った対処についてヒントと対処例を知ることができ、とても勉強になりました。業務でもコーディングだけではなく、ドキュメンテーションにも力を入れていますが、AWS Lambda Powertoolsのような非常に人気なプロジェクトでも過去にどのような課題が起こり、その結果どのようなドキュメントを作成したのか理解できたので、紹介頂いた資料をより深く読みつつ、日頃の業務や活動に活かしていきたいと思わせられるとても素晴らしいセッションでした。
AWS Lambda Powertoolsに関心があったり、OSSのプロジェクトに関わっていたりされる方はもちろん、そうでない方も是非視聴頂ければと思います。