はじめに
AWS re:Invent 2024に現地参加しました。
前回に引き続き参加したセッションの感想や現地の熱気などを私なりにレポートしていきたいと思います。
時間が空いてしまいましたが、数か月たった今改めて振り返ります。
前回の記事はこちら。
今回は4日目の内容をお届けします。
4日目：12/5(木)
4日目に参加した主なセッションやアクティビティは次の通りです。
- KEY005 | Dr. Werner Vogels Keynote
- COP345-R1 | Building an effective observability strategy [REPEAT]
- GHJ302 | AWS GameDay: Generative AI (sponsored by Datadog)
- ACT159 | re:Play party
それぞれ取り上げていきます。
KEY005 | Dr. Werner Vogels Keynote
木曜朝一はAmazon.comのCTOでお馴染みのWerner Vogels氏のKeynoteです。
同じKeynoteでも新サービスの発表が多いCEOとは毛色が異なり、自身のAmazonでの開発経験を踏まえた、サービスやシステムの設計・開発において何を大事にするべきかやありたい姿といったどちらかというと哲学的でメッセージ性のある話が語られます。
システム開発や運用では何を大切にすべきか、今一度原点に立ち返る示唆を与えてくれる内容だと思います。
一部の熱心なファンの方が最前列の席を確保しようと毎年朝早くから並ぶことでも少し有名です。
前回のre:Invent 2023では、コストを意識した持続可能でモダンなアーキテクチャを組むために「The Frugal Architect」の法則を唱えていました。
冒頭・導入
今回はAmazon S3の開発ストーリーをもとに描いたコミカルな寸劇の映像を皮切りに、単純さと複雑さの関係性を示すSimplexityをキーワードに話が進められました。場面場面で会場から笑いが巻き起こる映像でしたが、笑えるポイントを理解できるような英語力を身に付けたいとも思いました。
好ましくない複雑さ
システム開発では機能追加などにより、知らず知らずのうちに構造が複雑化するものですが、Werner氏は好ましくない複雑さの兆候として以下の7点を取り上げ、早期に対処することが重要だと指摘していました。
- Declining feature velocity（機能追加の速度低下）
- Frequent escalations（頻繁なエスカレーション）
- Time-consuming debugging（時間のかかるデバッグ）
- Excessive codebase growth（コードベースの過剰な増加）
- Inconsistent patterns（一貫性のないパターン）
- Dependencies everywhere（散逸した依存関係）
- Undifferentiated work（差別化されていない作業）
例えば、2つ目の「頻繁なエスカレーション」は、開発と運用の連携不足であったり、必要な部隊への権限移譲が不十分であったりすると発生するように思います。
また、6つ目の「散逸した依存関係」は、使用しているOSSやライブラリの最新バージョンの確認や脆弱性の管理をするとなると、気が重くなる状況ですね。
Simplexityから得られた教訓
また、Simplexityから得られた教訓として以下の6点が紹介されました。
- Make evolvability a requirement（進化可能性を要件とする）
- Break complexity into pieces（複雑さを細分化する）
- Align organization to architecture（組織の編成をアーキテクチャに合わせる）
- Design predictable systems（予測可能なシステムを設計する）
- Organize into cells（組織やコンポーネントをセルに整理する）
- Automate complexity（複雑さは自動化して対処する）
特に1つ目の「進化可能性を要件とする」は、設計の着手時点でSimplexityを意識しておく必要があるということであり、後から考えればよいものではないということが重要だと感じました。システム開発の要件定義では初版リリース時点で必要な機能・非機能だけを定義しがちですが、後の機能追加を見込んだ設計にすることでメンテナンス性にも優れると思います。
また、3つ目の「組織の編成をアーキテクチャに合わせる」に関しても、組織や制度に合わせたシステムを作るという日本企業がとってしまいがちなパターンと対照的であり、DX推進の潮流の中でエンジニア側からも組織・制度側の変革も訴えていきたいと思いました。
ゲストスピーカー
KeyNoteの後半では、以下の3名がゲストスピーカーとして登壇しました。
- Andy Warfield氏（Amazon S3開発チームのVP兼Distinguished Engineer）
- Brendan Humphreys氏（デザインツールCanvaを提供するCanva社のCTO）
- Robert Christiansen氏（食品ロス問題に取り組むマッチングサービスToo Good To Goを提供するToo Good To Go社のVP of Engineering）
Amazon S3開発チームのAndy氏は、S3の開発チームでシステムの複雑さに対しどう取り組んでいるか以下の2つの内容を共有しました。
- 成功しているチームは常に間違いを恐れている傾向があり、常に間違いを探していること
- チームにオーナーシップを持たせること
完成したものを完璧だと思わず、常に間違いがないかを探す習慣は真似したいところです。
また、Canva社のBrendan氏、Too Good To Go社のRobert氏からは、シンプルなシステムの構成にしたためにスケーラビリティや機能追加の面で成功したことが紹介されました。
特にToo Good To Go社では、1つのリージョンで始めたサービスの構成がパターン化可能であったために、速やかに他リージョンにもデプロイしてサービス提供地域を拡大できたとのことです。
総評
Werner氏の主張をまとめると、単純さと複雑さのバランスの重要性を指摘したうえで、以下の点を意識することが機能に柔軟性や拡張性を生みだすことにつながると強調していたと思います。
- 単純さを目指すことは非常に重要であるが、その維持には継続的な努力が不可欠であること
- 単純さだけでなくマイクロサービスなどの手法を用いて局所的な複雑さを管理すること
ちなみに、2023年と同様に最後にいくつかの新サービス・新機能が発表されることを期待していましたが、今回はセッション中に新サービスの発表はありませんでした。ただ、CEOのKeynoteで発表された新サービスへの言及はありました。
Simplexityという言葉をこれまで知らず、聞いた当初はWerner氏の造語かと思ったのですが、Wikipediaによると1924年にはすでに使われていた言葉のようです。
COP345-R1 | Building an effective observability strategy [REPEAT]
このChalk Talkでは、効果的なオブザーバビリティの戦略を立てるためには何が必要かを議論しました。普段の業務で監視や運用を考えることが多いため、参加するセッションも関連するものを選んでいます。
まず最初に、オブザーバビリティとはシステムやサービスからのシグナルを集めてインサイトを得る能力であると定義しました。鍵となるのは、シグナルからインサイトを得る行動であると強調していました。
そして、この能力に対して投資対効果を測るにはどうすればよいかという質問が投げかけられました。参加者からはKPIを決めて測定するという意見が挙がり、登壇者も同意のうえで、オブザーバビリティのソリューションを組織目標とKPIに合わせる重要性を強調しました。
顧客体験を計測するにはSLO(サービスレベル目標)をベースとした戦略を立てることを推奨するそうです。システム中心ではなく顧客中心の考え方がポイントです。
オブザーバビリティで気になるのがコストですが、計画段階から経営層やビジネス関連のステークホルダーを巻き込んで議論することを提案していました。必要なコストとして最初から認識することが重要ということですね。
AWSオブザーバビリティ成熟度モデルも紹介されました。
成熟度は以下の4段階で構成されます。前半と後半でmonitoringとobservabilityというように言葉が使い分けられていますね。相関に関しては、生成AIの活用が有効だとも言及していました。
- Foundational monitoring（テレメトリーの収集のみ）
- Intermediate monitoring（テレメトリーの分析と洞察）
- Advanced observability（相関と異常検知）
- Proactive observability（自動で積極的な真因の特定）
成熟度モデルは日本語でも公開されています。
続いて、オブザーバビリティにおいて注目すべき4つのゴールデンシグナルが紹介されました。レイテンシー、トラフィック、エラー、可用性の4つです。
ゴールデンシグナルと言えばGoogleが提唱したレイテンシー、トラフィック、エラー、飽和度の4指標が有名ですが、今回紹介されたものは最後が飽和度ではなく可用性でした。
また、CloudWatch ServicesのApplication Signalsなどを用いて、サンプル用アプリケーションに対してこれらのメトリクスを確認するデモもありました。
APIごとにSLOのベースとなるSLI(サービスレベル指標)が設定されています。
クロスアカウントのオブザーバビリティについても紹介がありました。
複数のアカウントにまたがってデプロイされ依存関係のあるアプリケーションでも、中央にログを集積することで迅速に問題を特定できる利点があるとのことです。
監視運用や障害対応において生成AI活用するのは定番ネタとなりつつありますが、このセッションでも例が紹介されました。
ログなどを解析して、障害原因がどこにありそうか可能性の度合いとともに提示してくれます。
おもしろかったのは、SNSで障害を告知する時の文章を考えさせるという使い方です。障害の特定の後は告知も必要ですが、その過程も効率化できそうです。
セッションの最後は、"If you cannot Measure it, you cannot Manage it. Measure what Matters."という言葉とともに締めくくられました。
「着目していることを観測しよう」というのは、オブザーバビリティを進めるうえでのスローガンですね。
GHJ302 | AWS GameDay: Generative AI (sponsored by Datadog)
期間中3回目となるGameDayの参加です。3回目ということもあり、完全に日本人1人で乗り込み、アメリカのエンジニアの方3名と無事チームを組むことができました。
お題は流行りの生成AIですが、初心者でもBedrockなどAWSの生成AIサービスの活用方法を学べる機会となる内容でした。また、コンテナなど生成AI以外のスキルを活用できるクエストも多くありました。
今回のスポンサー企業はDatadogで、Datadogを活用するクエストも用意されていました。
Come leverage and build skills in prompt engineering and foundation model evaluation while connecting applications to LLMs, building with agents, and more. Whether you’re a seasoned cloud professional or just starting your journey, this generative AI AWS GameDay is an opportunity to put your theoretical knowledge to the test and gain invaluable experience.
クエストは10題あり、チームで手分けして9題完答しました。
私個人では、3題前後解くことができ、チームに大いに貢献できたと思っています。生成AI以外の分野のクエストもあり、ちょうど私の経験のあるサービスであることも幸いしました。メンバーからは、「彼が結構解いている」と褒められたことも記憶に残っています。
最終スコアは799,736点で、56チーム中5位の好成績です！スコアボードを見ると3位以降は比較的僅差ですね。4位には行けたかも。
途中でやけにクエストが少ないと思いつつ全てを解き終わったとほっとしていたら、しれっと新しいクエストが追加される場面もありました。
GameDay中は獲得スコアが少し犠牲になりますが、ヒントを確認できるので、詰まったら悩みこむよりヒントを使うことをお勧めします。
クエストによっては何回も回答を受け付けるものの、誤答のたびに減点されるものもありました。
クエストの合間には、仕事内容や日本からのフライト、おすすめのハンバーガー屋など雑談をしたほか、日本から持ってきたお菓子を配るなどして交流することもできました。
今回も友好の印に記念撮影しました。
GameDayのポータルやスコアボードはセッション中にしかアクセスできないので、本記事のように後から見返したい場合はスクリーンショットやページを保存しておくことをおすすめします。
ACT159 | re:Play party
翌日に最終日を残していますが、re:Inventの後夜祭ともいえるイベントがre:Playパーティです。
通常のセッション会場エリアよりさらに北にあるLas Vegas Festival Groundsに場所を移し、みんなで音楽に乗ったり、体を動かしたり、食べたり飲んだりと日付が変わるまでのお祭りでフェスのような雰囲気です。
この時だけシャトルバスの臨時便が出て、近くのモノレール駅まで参加者のパスで乗ることもできます。おかげでラスベガスモノレールを完乗できました。
なんといっても注目は参加するアーティストです。
今回は世界的なバンドWeezerとDJのZeddがメインステージに登場しました。
と言っても私は洋楽に詳しくないので彼らを知らなかったのですが、同僚曰く「日本にもなかなか来てくれないぐらいだから今回はヤバい」とのことでした。ご存じの方はさぞテンションが上がったことでしょう。
食事に関しても飲み食い自由でベンチがたくさんあるので座って好きなように取ることができます。
同僚らと座って食べていたところ、ドイツ人とアメリカ人の方に話かけられました。その後マンガの話などで盛り上がって意気投合し、終盤まで一緒に行動するといった思いがけない出会いもありました。
知らない人にもどんどん話しかけられる積極的な国民性は見習いたいです。
それ以外にも、ローラースケートで遊べたり、大きな滑り台があったり、なぜか車が宙づりされていたりと、とにかくエキサイティングな空間でした。
最後の写真は「Digital Mirror」というブースで撮影したものです。
前に立つと生成AIでリアルタイムにアート風に仕上げられた自分の姿がディスプレイに映し出されます。動きやタイミングによって色合いや画風が変わるので、いろいろ試しながら見入ってしまいました。
おまけ
re:Invent期間中のディナーは、re:Playパーティ以外では提供されないため、現地でレストランなどを見つける必要があります。
もともとアメリカの物価が高いうえに強烈な円安のせいで、現地では食事を取るにしても少し身構えてしまいます。それでもVenetianなどのホテルのフードコートを利用すると、比較的安く(といっても20～30ドル)済ませることができます。
社内の参加者で集まったときは、日本人参加者にはおなじみのヌードルアジアで食卓を囲みました。その他にもステーキを食べるべくOutback Steakhouseに行きましたが、日本にも品川などにあるようです…。
他にも夜の自由時間には、Sphereやシルクドソレイユを鑑賞しました。
Sphereの演目は1年たっても増えていないんですね…。
シルクドソレイユは、少しマイナーですがMystèreを鑑賞しました。サーカスらしい曲芸にユーモアも交えられていて、個人的にはKAよりも素直に楽しめました。
おわりに
re:Inventのフィナーレも近づいた4日目の内容をお伝えしました。終盤にふさわしい充実した1日になったと思います。
CTOのSimplexityの話は特に部署内でも共有し、設計・開発で忘れないようにしたい話であるといった声がありました。最新技術・サービスに目が行きがちですが、このような原則や精神もエンジニアとして意識し続けていきたいところです。
また、初めて日本人1人で乗り込んだGameDayも良い刺激となりました。上位に食い込めたこともあって自信につながりました。
次回は最終日5日目の内容をお伝えしたいと思います。