AWS re:Invent 2024に現地参加しました。
前回投稿からまた間が空いてしまいましたが、引き続き参加したセッションの感想や現地の熱気などを私なりにレポートしていきたいと思います。
前回の記事はこちら。
今回は3日目の内容をお届けします。
3日目：12/4(水)
3日目に参加した主なセッションやアクティビティは次の通りです。
- ACT093 | AWS re:Invent 5K Race
- IOT314 | Generative AI recommendations for effective alarm management
- SUP305-R | Unleashing gen AI to scale cloud operations with AWS best practices [REPEAT]
- SVS207-R1 | Effectively model costs for your serverless applications [REPEAT]
- AIM395-NEW | [NEW LAUNCH] Amazon Nova understanding models
この中から抜粋して4つ取り上げます。
ACT093 | AWS re:Invent 5K Race
水曜朝一は、恒例となっている5K Raceに今年も参加しました。
ラスベガス市街の道路(ストリップ通り西にある州間高速道路15号線の側道)を封鎖して、5kmマラソン専用コースにしてしまう結構大掛かりなイベントです。
ラスベガスに来ることも滅多にない機会ですが、街を走ることは更に珍しい機会なので、頑張って早起きして経験しておきたいところです。
参加者の定員が決まっているので、興味のある方は早めにエントリーしてゼッケンを受け取っておきましょう。
体力消耗と睡眠不足が顕著になってきた水曜日ですが、5時頃に起きてから眠い目をこすりながら会場行きの特別ダイヤで運行されているシャトルバスに乗り込みました。
6時頃にバスの終点Mandalay Bayに着くと、すでにランナー達がチェックイン場所のMichelob Ultra Arenaまで長蛇の列を作っていました。
アリーナに入ってからの雰囲気はこんな感じです。テーブルの上に並んでいるのは走った後にもらえるSWAG(靴下)です。
水やバナナなどの軽食が提供されていたので、レース前にお腹が空いていても安心でした。
チェックイン場所では荷物を預けること(ギアドロップ)ができます。ただ、預けるまでに結構並ぶので荷物はない方がよいです。
終わった後セッションに直接向かいたい場合は、そもそも近くのホテルを取るか覚悟して並ぶしかなさそうです。
スタート時刻(6時30分)が近くなりガイドに従ってストレッチをした後、いよいよ競技開始です。
レクリエーションイベントではありますが、ゼッケンにはICチップも埋め込まれていて、しっかりとタイムも計測されます。
また、早いペースで走る人、それなりのペースで走る人、歩く人に分かれてスタートするので、本気度に応じて楽しむことができます。
レース中の雰囲気はこんな感じです。
日の出(6時36分)直後ということもあって、空もきれいで走っていて清々しいですね。
気温もレース中は半袖半ズボンでも問題ありませんでした。
私は自分なりのペースで走り続け、無事25分20秒でゴールすることができました。
競技中も音楽が鳴っていたり、応援があったりして朝から盛り上がっていました。
走り終わった後は、ブリトーやスムージーなどが提供され、おいしくいただきました。
朝から頑張った自分へのご褒美です。
レースの結果はこちらで確認できます。
聞いた話では、2位は日本人のエンジニアの方だそうです。
ちなみに当社のre:Invent参加メンバーで参加を意気込んでいた人のうち、実際に起きて走れたのは半分ぐらいだったようです。
IOT314 | Generative AI recommendations for effective alarm management
こちらは、AWS IoT SiteWise、AWS IoT Events、Amazon Bedrockを利用した、工場の生産ラインのセンサーデータから上がってくるアラームに対して、人がどう対処すべきかを生成AIで支援する仕組みを構築するWorkshopです。
普段の業務で触らないAWS IoTと流行りの生成AIを組み合わせるとどんなものかと思って受講してみました。
Workshopは、セッションごとに決まったテーマ設定・シナリオに沿って手順を見ながら環境を構築して、サービスの活用方法を学べるセッションです。
基本的には最初に全体の説明を受けた後、手順に従って黙々とぽちぽち作業する流れです。
GameDayと同様に作業するためのAWS環境が提供されますが、GameDayと違って基本的に個人で作業を進めるので環境も個人ごとです。
なお、会場では最大7人で1つのテーブルを囲み、分からないことがあれば手を挙げるとAWSのソリューションアーキテクトの方が駆けつけてくれる体制でした。
このWorkshopでは、参加者は全米に醸造所を持つ醸造会社のソリューションデベロッパーとして作業します。
これまで製造工程で上がってきたアラームへの対応が不十分だったために損失を出し続けてきたことを解決するため、生成AIを活用して迅速かつ適切な処置を誰でも講じられるようなアラーム対応ソリューションを開発するというシナリオです。
今回構築したシステムのアーキテクチャはこちら。
センサーデータの投入、アラームの設定、ダッシュボードの確認などは、AWS IoT SiteWiseを利用して構築しました。
その後アラームに応じた対処方法を支援できるよう、製造装置のマニュアルを基に生成されたナレッジベースを使用した生成AIのワークフローを構築します。
そして、アラームが上がった時に、生成AIによってまとめられた対処方法の情報が記載されている通知メールが現場の作業員に送信されるという流れです。
ダッシュボードはこんな感じ。障害シミュレート時には緑の部分が赤くなります。
SNSで自分宛ての通知を有効にすると、通知メールを受け取ることができます。
実際に受け取ったメールはこちら。Repair Planとして対処方法が記載されています。
これなら、熟練でない作業員でも何をすればよいかすぐに分かりそうです。
Alarm Message:
A high temperature alarm has been triggered for the MashTun100 mash tun, currently in an ACTIVE state on June 6, 2023 3:42:42 PM PT. The current temperature reading of 209.34°C (408.81°F) exceeds the configured high limit of 200°C (392°F).
The mash tun is currently in the "RampingUp1" stage of production run PR-A112044245 for Red Ale wort. Immediate attention is required to prevent potential product quality issues.
Data Summary:
| Parameter | Min | Max | Average |
|-----------------------|--------|--------|---------|
| Temperature_PV | 179.33 | 209.34 | 193.84 |
| Level_PV | 58.7 | 58.7 | 58.7 |
| SteamValve_PV | Closed | Opened | - |
| Agitator_PV | Stopped| Started| - |
Repair Plan:
1. Check the heating system and steam valve to ensure they are functioning properly. Refer to section "18. Troubleshooting" in the "Brewiks_UserManual_v2.pdf" for operating the heating controls.
2. Close the steam valve (currently "Opened") to stop adding more heat. Refer to the "SteamValve_CLS" and "SteamValve_OLS" properties showing the valve has opened.
3. Increase the agitator speed (currently "Started") to improve heat distribution and cooling. Refer to section "11. Showing main pump speed of mixing..." in the "Brewiks_UserManual_v2.pdf".
4. As a last resort, you may need to initiate an emergency cooldown by adding cooling water. Ensure the WaterValve is open (currently "Closed") and monitor the Level_PV. Refer to sections on water addition in "2020_TC-MashTun__product_guide-092020.pdf".
5. Once the temperature drops below 200°C, adjust heating and agitation to maintain the desired 179°C set point for the remaining hold time.
6. Review system parameters like PID values (section "41. Brewiks_UserManual_v2.pdf") if tighter temperature control is needed going forward.
Please provide updates on the temperature trend and any additional actions taken. Let me know if you need any other assistance.
受講した感想としては、ものづくりの現場でもアラート対応などで生成AIを活用できる場面は多いと感じました。
特にAWSのBedrockはLambdaから呼び出すことで、IoTなども含めた様々なサービスと連携が取れて便利だと思いました。
セッションの最後でこのWorkshopの内容は後日公開するとアナウンスされていましたが、実際に次のページで公開されていました。
ただし、現時点で演習内容の公開のみで、ユーザーのAWS環境での実行はまだサポートされていません。
SUP305-R | Unleashing gen AI to scale cloud operations with AWS best practices [REPEAT]
このChalk Talkでは、AWSのベストプラクティスを用いてクラウド運用を強化するためにいかに生成AIを活用するか議論しました。
最初にクラウド運用における課題を聴講者から募り、オブザーバビリティ、マイグレーション、インシデント対応、脆弱性管理、リアーキテクティング、コスト最適化など、あるあるな課題が列挙されました。
さらに、個別の課題を掘り下げてその原因を探り、例えばオブザーバビリティならサイロ化された監視や文脈情報の欠如などを原因として整理していきました(ホワイトボードの赤字)。
ちなみにホワイトボードは、スクリーンにも投影されるので遠くからでも意外と見やすいです(文字の読みやすさは別の話…)。
また、登壇者からは生成AIがクラウド運用において果たす役割を整理した情報が提供され、デプロイの前と後、運用時の各ステップで有効活用できることが示されました。
クラウド運用における生成AIの具体的な活用場面としては、デプロイ前のコードレビュー、デプロイ後の修正、運用時のインサイトの取得などが取り上げられました。
さらに、生成AIの効果を最大化するには、運用情報のRAGを構築するためにもドキュメントやランブックの整備が重要だと指摘されていました。
ドキュメントやランブックの形式はJSONやMarkdownが望ましいとしつつも、まずは情報を集積することが大事なためPDFや画像でも構わないとのことです。
ホワイトボード右側のブロック図は、コード、コードレビュー、パイプライン、デプロイ先環境(EC2、Lambda、EKSなど)の一連の流れでどこに生成AIを活用するかを議論したものです。
特に登壇者が重点的に語ったコードレビューとデプロイ先環境の運用の部分から線が伸びています。
コードレビューに関しては、AWSのWell-Architectedフレームワークやドキュメント、内部規則、過去のレビューコメントを取り込むことで、詳細な技術背景や最新のベストプラクティスに基づきレビューの質を高めることができるとのことです。
環境の運用に関しては、これまでTrusted Advisor、Config、Security Hubなどのツールは多くあっても、問題を自動で修復するツールはほとんどなかったことから、生成AIを活用して修復を自動化することが省力化にもつながるので、ぜひトライしてほしいとのことでした。
また、登壇者によれば最新の基盤モデルを使うことも重要ですが、それだけでは一般的なアドバイスに留まるのでAmazon KendraなどのRAGの利用がより重要だとのことです。
課題を一通り整理してからどこに生成AIを適用して問題を緩和していくか検討するという流れは、生成AIの活用を進める上で重要な手法だと思いました。
いずれの課題においても様々な原因が眠っていますが、組織ごとに当てはまる原因をよく見極めた上で、解決策を考えていく流れは今後取り入れていきたいです。
SVS207-R1 | Effectively model costs for your serverless applications [REPEAT]
このChalk Talkでは、サーバーレスアプリケーションを構築する上で、いかに効率的にコストを見積もるかを議論しました。
コストに関係するビジネス側の関心項目を確認した後、コストに影響する技術的な要素をリストアップし、API GatewayやLambdaなど具体的なサービスでどの項目が該当するかを整理しました。
登壇者がホワイトボードにどんどん書き出していきます。
登壇者がまとめたコスト見積もり時の原則は以下の5点です。
- ビジネス要件から始めること
- コストの期待値を文書化すること
- アーキテクチャ構築時には鍵となるメトリクスを特定し収集すること
- スケーリングの影響を把握すること
- コストの再計算を簡単にできるようにすること
コスト見積もり時には、前提条件が大きくずれると、算出結果が大きく変わってしまいます。
何が鍵となる要素か、その変動幅はどれくらいでコストは合わせてどう変動するか、この辺りをしっかりと把握できるとコスト試算の有効性が増すと思いました。
また、ビジネス要件を重要視する話はこの手の話でよく出てきますが、システムを構築するときは機能的な要件だけでなく、それを使っていかにビジネスとして成立させるか(ビジネスとして成立できる範囲でどう動かすか)を考えることも忘れないようにしたいところです。
会場の雰囲気として、技術要素をリストアップする際には、会場の聴講者で思いついた人から次々と発言があり、活発な議論となりました。
海外の方は、こういう場面で積極的に、時には前の人を遮る勢いで発言しているのをよく見かけます。
こういう場面で単語1つでも言って議論に食い込めるようにしたいというのは今後の課題です。
おまけ
re:Inventでホテルをどこに取るか問題ですが、やはりメイン会場近くが便利で体力も温存できるのでおすすめです。
今回私はHarrah'sに宿泊しましたが、Venetian、Wynn、Caesars Forumまで地上に降りずに行くことができ、モノレール駅直結のためMGM Grandにも行きやすかったです。
5K Race会場までのシャトルバスはセッション会場からしか出ていませんでしたが、最寄りのCaesars Forumからすぐに乗ることができました。
宿泊費も安すぎず高すぎず、快適でちょうどよいです(もともとラスベガスのホテルは高いですが)。
あえて気になる点を挙げると、ベッドメイキングがある日とない日があったこと(法則は不明)と、コンセントやUSBの充電口がぐらついていて一部使いづらかったことでしょうか。
内観はこちらです。
Ariaに宿泊した前回と比べて、会期中の歩数が1日当たり5千～1万歩減りました。
改めて地図を見ても、Ariaは会場から遠すぎますね…。
おわりに
re:Inventの山場、3日目の内容をお伝えしました。
本当はもう1つセッションを聴講する予定だったのですが、セッションの合間でうとうとしていたところ、起きたらセッション開始時刻ちょうどで予約枠が流れてしまいました…。
やはり朝早くから活動していると体力の限界はありますね。
それでも、早朝から夕方まで充実した1日だったと思います。
4日目、5日目に体験したり感じたりした内容も今後記事にまとめていきたいと思います。