「Amazon Q DeveloperワークショップとスタートアップなLT大会」参加レポート
2025年5月17日にAmazon Q DeveloperワークショップとスタートアップなLT大会に参加したので、参加レポートを書きました。
Application Signals 紹介セッション
最初に、AWSのDeveloper Advocateの山口さんのセッションがありました。
初めて聞く単語ばっかりだったので、一旦メモした単語を壁打ちして噛み砕いてみます。というか、単語の噛み砕きがメインです。
SLI (Service Level Indicator)
サービスの品質やパフォーマンスを数値で示す指標のこと。
- ちゃんと使える状態だったか？
- 過去30日間のHTTPリクエストのうち、ステータスコードが200台だった割合
- 速く反応しているか？
- 全リクエストのうち、95%が300ms以内にレスポンスされた
- レスポンスは間違ってなかったか？
- リクエストに対して、結果が0件でなかった割合
みたいな、ユーザー体験がどうだったかを数値化するのがSLI。
他にもエラーレートとかスループットとかがあるけど、SLI自体は
SLI = 良いイベント・時間/全イベント・時間
で計算できる。
SLO (Service Level Objective)
サービスの目標値（信頼性の基準）のこと。
SLIで測った実際の数値に対して、「これくらいを目指そう」という目標ラインを設定するのがSLO。
実数値がSLIで、目標値がSLO！
実数値がわからないまま目標値を決めると、「このサイトの稼働率は99.999999999%とする！！！」みたいな非現実的な目標になっちゃうから、まず「実際どれくらい出せてるのか（SLI）」を見てから、「目指すべき水準（SLO）」を決める。
エラーバジェット
SLOをもとに、「このWebサイトは年間何回（or何時間or何日）落ちて良いか」を具体的に数値化すること。
なんでこの数値が大事かって言うと、サービスのバランスをとるため。
信頼性100%だと、機能追加やリリースのためのリソースがなくなるし、逆に低すぎると「このサービスよく落ちるな………使うのやめとこ………」ってユーザーが離れていく。
つまり、エラーバジェットは「これくらいまでなら壊してもOK！」という開発の自由度を与える仕組み。
稼働率99％の場合、3日半はエラーが起きててもよいということ。
この3日半がどれくらいのペースでなくなるのか？が大事で、
- 5月時点で「あと半日分しかないんだよね・・・」←やばい
- もう冒険してる場合じゃない。今すぐ即刻不具合をなおすぞ
- 11月末の時点で「あと2日しかない・・・」←寝言？それまでの消化ペース考えたら余裕
- 逆に言えば、ちょっと攻めたリリースしてもよいかも。技術負債返すとか、リファクタリングをしてみるとか。
という判断ができる。この予算消化の速度のことを、バーンレートという。
バーンレート
「壊れすぎてないかのスピードメーター」がバーンレート。
バーンレート = 実際に使ったバジェットの割合 ÷ 経過時間の割合
| バーンレート | 意味 |
|---|---|
| 1.0 以下 | よい感じ。ペース通り。 |
| 1.0 ～ 2.0 | ちょっと速い。注意。 |
| 2.0 ～ 3.0 | 危ない。エラーバジェット使い切る可能性あり。 |
| 3.0以上 | やばい。リリース止めて信頼性改善を優先すべき。 |
のように計算できる。
これを指標にすることで、今の障害のやばさをスピードで測れる。
超軽微な障害も込みでガンガンアラート出まくってたら、「どうせあれでしょ？」ってみなくなる（アラート疲れ）が起きるけど、バーンレートから算出すれば、本当にやばいときだけ通知がくるから疲れにくい（かもしれない）。
ただ、バーンレートアラームを自分で実装するには多少手間がかかる………。
この計算を自分で計算してくれたらありがたいな〜っていうのが、今回紹介されていたApplication Signalsの機能のようです。
アプリケーションの状態を把握・分析するための情報を自分で収集・可視化してくれるのだとか。すごい、便利。
ただ、
サポートされている言語とアーキテクチャ
Application Signals は、Java、Python、Node.js、.NET アプリケーションをサポートしています。
Application Signals は、Amazon EKS、Amazon ECS、および Amazon EC2 でサポートされ、テストされています。Amazon EKS クラスターでは、サービスとクラスターの名前が自動的に検出されます。他のアーキテクチャでは、Application Signals に対してそれらのサービスを有効にするときに、サービスと環境の名前を指定する必要があります。
Amazon EC2 で Application Signals を有効にする手順は、CloudWatch エージェントと AWS Distro for OpenTelemetry をサポートするすべてのアーキテクチャで機能する必要があります。ただし、この手順は Amazon ECS と Amazon EC2 以外のアーキテクチャではテストされていません。
とのことなので、私がやってる領域では使えなさそうでちょっと残念。
SLIとかSLOとかの概念に初めて触れたセッションでした！面白かったです。
Amazon Q Developerの紹介セッション
ワークショップ前にパートナーセールスソリューションアーキテクトのKatz Uenoさんによるセッションがありました。
Amazon QはAWSの専門家。AWS環境の最適化に精通しているそう。
IDEsだけじゃなく、Slackやコンソールでも使えるので、「ベストプラクティスを知りたい」とか「AWS使ってあれしたいこれしたい」っていう質問にはまさに最適のもよう。
主な機能
- AWSに関する質問を聞くと返してくれる。ドキュメント調べなくてもAmazon Q Developerに聞けばいい
- ユニットテスト作成・セキュリティスキャン・最適化のサジェスチョン。
- コード読んでREADME作らせるもできる。コード変更があれば探知してREADME更新してくれる
- コーディングエージェントの機能の開発が盛ん。MCPサポートも追加
ワークショップ
AWSビルダーIDを使って、Amazon Q Developerを試しました。
チャット機能等はCursorやClineと同じ感じで触れるので、使うのに苦労はなかったです。
/review コマンドがすごかった。
脆弱性のあるコードや低品質なコードをずらっと列挙してくれて、Accept Fixボタンをぽちっとするだけで修正してくれました。
今回のワークショップではjavaを使用しました（私自身javaは何もわからない）が、バージョンの更新とかもやってくれました。
ちなみに色々やりすぎてワークショップじゃこれ以上試せないよ！って言われてｷｬｯｷｬｯてスクショ撮ったのはこちら。右下にアラート出てます。
私自身、今回「なんかAWSについてちょっと知れたらいいなあ」っていうノリで参加したので、置いてけぼりにならず楽しく参加できて嬉しかったです。
またJAWS-UG DE&I、時間が合えば参加したいなと思っています！
Discussion