AWS Summit Tokyo 2023参戦感想ブログ

2023年4月23日 22:36

概要

4/20、4/21に行われたAWS Summit Tokyo 2023に参加してきましたので、その参加レポートを書きました。
先に書いておくのですが、AWSの最新情報、それも正確なものを必要とされている場合は、公式なりクラメソさんのブログなりを参照してください。

この記事では私が参加したセッション、回ったブースの感想と、サミット初参加で失敗したポイントを幾つかご紹介します。

セッション感想

Resilience at AWS回復力のあるシステムを作る為の設計指針

認定教科書に乗っているレベルのDR戦略から始まり、それを実際のシステムに組み込む場合の取捨選択、コスト最適化のための設計についてまで言及されていたので、初心者向けと言いつつ濃い目のセッションでした。

Amazonの事例から学ぶObservability 活用におけるベストプラクティス

Observabilityとは何なのか、という話を最初にされていたのが印象的です。
曰く「どこで、なにが、なぜ起きているか動作状況を把握できている状態」であるということ。その実現のためにはまず質問から始める事であると言い、抽象度の高い質問から始まって段々とドリルダウンしていく様子を見せて貰えました。
そのために必要なAWSの機能、特にX-RayとCloudWatchのダッシュボードについて細かく解説があり、最後にブースでの展示で実際に画面でメトリクスを紹介している事も教えて貰えました。

ECS Service ConnectでECS上のマイクロサービスの耐障害性と可観測性を高めよう

タイトル通りECS Service Connectの機能紹介だったのですが、ECS間で通信する他の機能との比較、選定基準などを含んでおり面白く聞けました。
私個人の経験としてECS同士の連携が必要なマイクロサービスを組んだ事はないのですが、組む機会には思い出したいセッションでした。

NoSQLをいかに組み込み課題へ対処するか

具体的なデータの課題について、AWSのどのようなDBサービスが向いているのかという事を紹介頂きました。
個々の問題についてRDBMSでも解決可能であるがこんなペインが伴う、と言及されていたのが印象的です。実際そのペインを飲み込んでいる現場も多く見るということだと思います。
複数のデータベースを取り扱う事は一見複雑に見えるが、TotalCostで見てみると最適化された運用であるという話でした。
私も何だかんだRDBMSばっかり使いがちなので、選択肢には常に入れておくようにしたいです。慣れたい。

アーキテクチャ道場2023

実業務に近いお題をAWSを使って解決する流れを見せてくれるセッションでした。人気セッションらしく人が多かった。
お題がオンラインゲームと既存のミッションクリティカルシステムのモダナイズの2種類あって、どちらも自分は体験したことの無い複雑なシステムだったのですが、なんとか思考自体にはついていけたと思います。
進行された方のまとめが素晴らしく、抽象化した学びとして短くまとめられたのでメモしておこうと思いました。

- 複雑な問題を分割し個別に解決案を見出してから、個々の解決策でコンフリクトしない所を選ぶ
- シンプルな解決案をまず用意して、想定される問題点を解消していく
- 最初から実装案、AWSありきで考えるのではなく、「こんな機能を持つコンポーネントが必要」というレベルのモデルを考える

ブース感想

AWSブース

色々見ましたが、特に面白かった所に絞って書きます。

CodeCatelyst

CodeCatelystという名前をこのイベントで初めて知りました。CI/CDつきの統合開発環境という、プロジェクト開始の環境構築を最速で出来る強みがありそうでした。
Cloud9のようにAWS内部で動くものの、VSCodeなどでリモートSSHで接続する事も出来るのも良さそう。
Github連携も出来るそうです。
残念ながらまだAWS CodeWispererと繋ぐ事は出来ないらしく（当然Github Copilotも無理）、それらを使いたいのならGithubにpushしたリポジトリをローカルにcloneしてくるしか無いそうです。
個人的にはソースコードをリモートに起きながら開発する事に特殊な環境を除いてそこまで欲しい要件であないため、ローカルマシンでCopilotを使いつつ、CICDなどを使える分だけCodeCatelystにやってもらうのが良さそうに思いました。
（リモートマシン分お金も掛かりそうだし）

observabilityの運用設定について

observabilityについて学んだセッションで紹介されていたので行きました。CloudWatchを使ったメトリクスとダッシュボードを展示していて、何をどのように監視対象とすべきかの相談に乗ってもらえそうでした。
私が業務で監視を組む事をしてこなかったので、これから監視について学びたいという話をさせて貰った所、色々教材を教えていただけました。
セッションでも話がありましたが、コンポーネント毎のメトリクス、例えばCPU使用率などを見て異常値が出るというだけでなく、ALBがリクエストを受けてからクライアントにレスポンスを返すまでの時間のような、ユーザー体験を可視化出来るメトリクスを取得すべきであるという事を学べました。

後注）「オブザーバビリティ」と「モニタリング」「監視」は違うよ、という指摘を頂きましたが、現時点でまだ良くわかっていないのでこの時点のスナップショットとしてはこのまま残させてください。

Mini Stage RoomClipの10年間継続的開発を可能にしたAWSアーキテクチャ

ある程度の規模の開発を、部屋のレイアウトに例えたツカミが印象的でした。

とりあえず「これでいい」
だんだんと「あわなくなってくる」
必ずしもマッチしない「トレンド」
結局「知恵と工夫でなんとかし続ける」
うっすらとした課題をずっと抱えながら、、、

SaaSを使う場合でもLambdaでRDSにデータを持ってきて、データを使った開発をAWSの機能を使ってやられている話もあり、miniでやるには少し勿体ないくらい濃いセッションでした。

DataDogさん

どんなメトリクスが取れるかなどデモをしていたので見てきました。
案件で使ってはいるもののあんまり機能に詳しくなかったのですが、結構いろんな所と連携できるのと、監視対象のメトリクスも標準で色々ついていることを知りました。
エンジニアの方がひっきりなしにデモをしていて話しかけられなかったのが心残りです。AWS標準機能で実現する場合の差分とか、独自機能とか聞きたかった、、、

失敗談

参加時間に失敗

2日目は朝から参加したのですが、9時過ぎに会場入りしました。
自分の予定としては基調講演までブースを見て回る予定だったのですが、9時開場はしていてもブースは開いておらず、基調講演のセッション会場に誘導され座るしかありませんでした。
基調講演が始まるまで1時間ほど暇過ぎたので、次回は参加時間を調整するか、暇潰しする覚悟を決めていくかします。

セッションの難易度選択に失敗

今回初参加という事もあり、日和って初心者向けのセッションばかり登録したのですが、上級者向けでも聞けば分かる事が今回分かりました。
次回からは日和らず聞きたい所に飛び込もうと思います。

ブースの回り方、特にBiz向け情報の選別に失敗

AWS Summitは開発者に限ったイベントではない事は把握していましたが、特に企業のブースの殆どはBiz向けのものであり、見るべきものを見損ねて疲弊してしまったなという印象があります。
ブースを出している会社の事前チェックは数的に厳しいですが、Biz向けブースはさっと素通りするつもりで、ブースを回る巡回ルートでも決めておけば良かったと思います。

なにかテーマの１つか２つを決めておけば良かった

今回漠然とAWS最新情報をキャッチアップすることと、AWSのオフラインイベントに初参戦することを目的にしていたのですが、AWSのSAやエンジニアと直接話せる機会として、もっと掘り下げたいテーマを持っていけば良かったです。

特典目当てに認定者ラウンジ行くなら早めに

別にどうでもいいレベルですが、あらかた見て回った後休憩ついでに認定者ラウンジ行くかと思ったら、特典（ステッカーとか飲み物とか）は品切れでした。
その辺を求めて行くのなら早めに行くべきでした。
でも流石にAll Certified Tシャツは残ってた。

総じて

地方民として東京の勉強会は腰が重いのですが、行って損は無い学び多き会でした。
6月にはDev Dayがあるので、できればまた参加したいです。

この記事が気に入ったらサポートをしてみませんか？