今年もアドベントカレンダーの季節がやってきたので、1年ぶりにQiitaで記事を書こうと思います！
12月1日〜12月5日にAWS re:Invent 2025が開催され、現地参加させていただきました！（初参加です）
そこで、今回は現地で参加したセッションのメモ的なものを書こうと思います！
ちゃんとしたものはZOZO公式のTechblogで後日公開される予定なのでぜひご覧ください！
普段はZOZOTOWNのマイクロサービス基盤をEKSで構築・運用しているSREです。そのため、書いている内容もかなりEKSやPlatform Engineeringに寄っているのでそれを前提に見ていただけると幸いです。
セッションまとめ
AWS re:Inventには様々なセッションのタイプがあります！
KeynoteやBreakout sessionの多くはYoutubeにアップロードされ後でいつでも見ることができます。
そのため、せっかく現地参加しているということで、今回は手や口を動かせるworkshop系を中心に参加しました！
特に気になったものを数個紹介します！
Opening Keynote with Matt Garman (KEY001)
毎年巨大な会場でCEOが新サービスの発表などをしてくれる基調講演です。
一応いろんな場所で中継されるみたいですが、せっかくならいい場所で見たい！ということで朝5時半から並びに行きました！
気になった新サービスをいくつか紹介します！
AWS DevOps Agent
AWS DevOps AgentはSREチームの一員として振る舞ってくれるAgentです。
例えば下記のことができるみたいです。
- インシデントの根本原因を特定して通知
- アプリケーションのログやメトリクス、ソースコードなどを分析し、運用改善を提案
previewなのでラフにPoCなどできると良さそうです！
弊チームではDatadog Monitor -> slack通知で異常に気づく仕組みを作っているので、DevOps Agentがslack通知されたリプ欄でトラブルシューティングするような使い方を試したい！と思ったりしました。
Database Savings Plans
これが発表された時一番盛り上がっていました。
データベースコストを最大35%削減することができるらしいですが、EC2 Instanceだと最大70%程度下がる例もあるので、DBがお高いのは変わりませんがあるだけ良いという感想です。Databaseのリザーブドインスタンスだともっと割引率がいいので、リザーブドインスタンスよりも柔軟性が欲しいケースで選択肢になりそうです！
The future of Kubernetes on AWS (CNS205)
こちらも毎年開催されている、Amazon EKSの新リリースやこれからについて語ってくれるBreakout sessionです。
今年は主に下記のような発表がありました。
ECRのアーカイブストレージ機能
やっていることはS3のintelligent-tieringに似たものかと思います。
Kubenetes Control Planeのプロビジョンモード追加
最大6800APIリクエストの処理能力で、突発的なrequestスパイクへの対応が可能です。
現状弊チームは困っていなさそうなのですが、いずれ必要になってくる時のために頭の片隅に入れておきます。
EKS Ultra Clusters
大規模なAIワークロード向けのクラスター。最大100,000ノードまで起動することができるらしいです。
EKS Capabilities
マネージドのArgo CDが利用できるようになりました🎉
SecretやNetworkなどAWS側がネイティブに統合してくれます。
特にマルチクラスターだと運用負荷が大幅に下がるのではないかと思いました。
今年の発表は、AIワークロードへの対応力向上とPlatform Engineerの運用負荷軽減が強調されていた印象でした。
Running compute efficient workloads on Amazon EKS Auto Mode (CNS322)
次はEKS Auto Modeのworkshop（ハンズオン）です！
EKS Auto Modeとは、一部エコシステムやDataPlaneなどの運用負荷をAWS側に任せることができる新しいモードです。（公式）
チーム内でも何回か話題に上がる内容だったので参加してきました。
最初からEKS Auto Modeがworkshop環境にデプロイされており、要件に基づいてマネージドなKarpenterを触りながら、コンピューティング効率化について学ぶという内容でした。
コンピューティング効率の可視化には、eks-node-viewerというツールを使いました！余談ですが、eks-node-viewerはAWS公式に認められているツールだと知らなかったです
karpenterのNodeは下記のコマンドで確認できます。
eks-node-viewer --node-selector karpenter.sh/nodepool
手動スケールインを行なうとConsolidationしてくれたり、NodePoolでSpotインスタンスを優先的に使用する設定も試しました。
弊チームでは現在セルフマネージドのKarpenterを運用していますが、移行するためにはコストと瞬断リスクが懸念となっているので現地の講師に質問してみました。ただ、もちろんいけると即答されたのであまり英語が伝わっていなかったかもしれません...
移行については引き続きチーム内で議論が必要そうです。
AWS GameDay - Winning the DDos Game
AWSカンファレンス定番のGameDayも予約できたので参加しました！
Winning the DDos Gameは毎年開催されているっぽく、内容をあまり書きすぎるとネタバレになってしまうので、詳細は記載しないでおきます。
まず、会場に入ると同時に4人でチームを組んで席に座ります。開場待ちで並んでいた前後3人が全員日本人だったので、自動的にJapanese Onlyチームで組むことになりました。
開始すると、各チームに課せられたミッションをクリアしたり、DDos攻撃を回避できているとポイントが加算され、順位とそれぞれのチームのポイントが常に表示されるので緊張感があります。
（開始5分くらいでとんでもないポイントの伸びを見せているチームが何個かあったので、やはり例年内容は一緒かもしれません）
各コンポーネントのログやメトリクスを見ながら、既存のトラフィックを遮断せずに攻撃対象だけブロックするにはどうすればいいか？などをチーム内で議論しながら進めていきました。
また、講師は各チームの進捗を把握しているので、チーム内で議論が進まない状態になったときは講師から解決の糸口を教えてくれることもありました。
結果優勝はできませんでしたが、普段触らないサービスを深く考えたり、実測に基づいた適切なソリューションの導き方はすごく勉強になりました。
Using Amazon Q to Cost Optimize Your Containerized Workloads (CMP348)
こちらはAmazon Qを活用してEKSワークロードをGravitonに移行し、コスト最適化を行うworkshopです！
サンプルのチャットボットアプリケーション（Java、Python、Go、.NET Coreから選択）をx86からGravitonへ移行する流れを体験しました。（自分はGoを選択して進めました）
特徴的だったのは、Amazon QがGraviton移行の専用agentがすでに組み込まれている点です。
Amazon Qに質問しながら、移行の分析から実装までを進めていくスタイルでした。
まず、Amazon Qに現状のEKSインフラがGraviton移行可能かを分析してもらいました。
Q. Analyze the EKS infrastructure for Graviton readiness
すると、Karpenter NodePoolの設定やアプリケーションマニフェストの問題点、コンテナビルドの準備状況などを詳細に分析してくれます。
さらに、コスト分析もAmazon Qにやってもらいます。
Q. Perform EKS Graviton migration cost analysis for my go app
現在のx86コストとGraviton移行後の予測コストを比較したレポートを生成してくれました。
月額約14%の削減、年間では約$600の削減が見込めるという結果でした。
workshopでは事前に用意されていた負荷試験ツールを実行して、Graviton移行前後のパフォーマンスを比較しました。
Graviton移行前（x86）
#[Mean = 2192.524, StdDeviation = 47.983]
Requests/sec: 0.45
Amazon Qから言われた通りにGraviton移行で必要な下記の変更を加えてから負荷試験を行います。
- nodepool：
kubernetes.io/archにarm64を追加 - instance-familyを
c7gに変更
#[Mean = 1593.935, StdDeviation = 57.964]
Requests/sec: 0.63
レイテンシが約27%改善、スループットは約40%向上という結果になりました🎉
Gravitonはコスト最適化のイメージでしたが、パフォーマンスもかなり向上していることを知れました。
また、topologySpreadConstraintsを利用して、段階的な移行も体験しました。
topologySpreadConstraints:
- labelSelector:
matchLabels:
app.kubernetes.io/name: goapp
maxSkew: 1
topologyKey: capacity-spread
whenUnsatisfiable: DoNotSchedule
弊社でもマイクロサービスごとに使っている言語が違うので、環境ごと、nodepoolごとの段階リリースは必須だと思います。
Accelerate platform engineering on Amazon EKS (CNS301-R1)
帰国日に参加した最後のworkshopです。最後だからなのかわかりませんがかなり人が多く、予約していない人はほとんど入れていませんでした。
内容はBackstageやArgoCDなどの最先端ツールやKiroを駆使して、爆速で開発プラットフォームを構築するという、人の多さ通りの面白さでした。
workshopで使用したプラットフォームは、EKS Auto Mode上に構築されており、非常に豪華な構成でした。
主なコンポーネントは以下の通りです。
- Backstage - 開発者ポータル
- ArgoCD：GitOpsエンジン
- Argo Workflows：CI/CDワークフロー
- Argo Rollouts：Progressive Delivery
- KubeVela：OAM（Open Application Model）ベースのアプリケーション管理
- kro：Kubernetes Resource Orchestrator
- Kargo：環境間のプロモーション管理
- Amazon Q：生成AIアシスタント
また、The Future of Kubernetesで触れましたが、今年発表されたEKS Capabilitiesについてもここで紹介がありました。
ArgoCDだけでなくACK（AWS Controllers for Kubernetes）、kroがマネージドで提供されるようになり、運用負荷が大幅に下がりそうです。
詳しくは下記のbreakout sessionで紹介されているのでご覧ください。
https://www.youtube.com/watch?v=Wl12hmjFh5E!
ワークショップ前半では、Backstageを使ってプラットフォーム基盤を構築していく内容でした。
Backstageはサービスカタログ、API一覧、ドキュメント、CI/CDパイプラインの状態などを一元管理できます。
Application Name、AWS Region、EKS Cluster Nameなどを入力して「CREATE」を押すだけで、GitLabリポジトリの作成からArgoCDの設定まで自動で行ってくれます。
また、KubeVelaを使うと、マイクロサービスを1つのファイルで定義できます。
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
name: first-app
spec:
components:
- name: express-server
type: webservice
properties:
image: oamdev/hello-world
ports:
- port: 80
containerPort: 8000
expose: true
Deployment、Service、Ingressなどを個別に書く必要がなく、開発者にとっての認知負荷が大幅に下がります。
workshopの後半では、Progressive Deliveryを体験しました。設定したProgressive Deliveryは下記のフローで進みます。
- 開発者がGitにコードをプッシュ
- Argo Workflowsがビルド・イメージプッシュ・マニフェスト更新
- ArgoCDがデプロイ
- Rolloutが新バージョンを20%に展開し、機能テスト実行
- 40%、60%、80%と段階的に展開し、パフォーマンステスト実行
- テスト失敗時は自動ロールバック
実際にわざとエラーになる変更を入れてテストしてみました。
自動でロールバックされていることがわかります。
修正を入れてre-deployすると、無事Successfulになります。
また、Kargoを用いて先ほどデプロイしたimageをPRDに昇格させてみます。
このworkshop内ではDEVへのデプロイは自動で行われ、PRDへの昇格は手動で「Promote」をクリックする運用がされています。imageが完全に同一なので、CI/CDを手動で組むより環境間の差異による問題を防ぎやすいです。
また、これらの流れはDORAメトリクス（デプロイ頻度、変更リードタイム、変更失敗率、復旧時間）で自動計測・可視化されています。
弊チームでは現在FluxCDを使ってGitOpsを運用しているので、ArgoCDへの移行となるとなかなかハードルが高いな...というのが正直なところです。
今回のre:Inventの発表を見る限りArgoCDがかなり推されている印象だったので、中長期的にはArgoCD移行も視野に入れて検討していく必要がありそうです。
workshopのソースコードはGitHubで公開されているので、興味のある方はぜひ試してみてください！
さいごに
今回初参加でかつ初海外だったのですが、その割にすごく満喫できたのではないかと思います。
セッションだけではなく、世界的な企業がブースを出していて、そこでアンケートに答えたりゲームをクリアするとSWAG（ノベルティ）がもらえます。
名前を目の前で印字したパーカーをもらえたり、自分は時間がなくて行けませんでしたが香水を作るところもあり、どの企業もブースやSWAGに力が入っていました。
集めるのがつい楽しくなってしまい、半日くらいずっと回って大量にかき集めていました。持って帰るのがかなり大変でした。
機会があればまた現地で参加して、モチベーションを上げていこうと思います💪