トップ > バックエンド > AWS re:Invent 2025 参加記と体験談 ~ 新卒視点 ~

AWS re:Invent 2025 参加記と体験談 ~ 新卒視点 ~

バックエンド ネットワーク インフラ SRE CI/CD 新卒 プラットフォーム

サムネイル

はじめに

こんにちは、こんばんは！プラットフォーム開発本部 認可チーム所属、新卒1年目の日比です。
プラットフォーム開発本部では、DMMの各プロダクトが共通で利用できるマイクロサービス群を提供しております。
私が所属する認可チームはその名の通り、マイクロサービスの認可システムを開発・運用しています。

概要

ラスベガスで開催された AWS re:Invent 2025（以下、re:Invent）に参加してきました。
世界中のエンジニアが注目し、AWSの最新技術が次々と発表される超大規模カンファレンスです。

この記事では、技術解説だけでなく、以下の2点にフォーカスします。

  • 新卒エンジニアが現地で何を感じ、どんな衝撃を受けたのか
  • 海外カンファレンスという非日常で、エンジニアとしての価値観がどう変わったのか

技術情報はもちろん、新卒が海外カンファレンスに挑戦したリアルな体験記として楽しんでください。

expo

セッション

セッション探しで意識したこと

数あるセッションから、私は次の3つを軸に選びました。

1. 現地ならではの体験

KeynoteやBreakoutはアーカイブ配信があるため、後から視聴できると考え、現地ではアーカイブに残らないかつ現地のエンジニアと直接議論できる場を探しました。

2. マルチクラウドについて

認可システムはGoogle Cloud、データベースにはTiDB Cloud on AWSを利用しています。
プラットフォーム開発本部ではマイクロサービスとAPI Gatewayパターンを採用しています。
API GatewayがGoogle Cloudで提供されているため、レイテンシーの観点からアプリケーションはGoogle Cloudで運用することにしました。
TiDB CloudのアップデートがGoogle CloudよりもAWSの方が肌感早かったため、データベースはAWSで稼働させることにしました。
アプリケーションとデータベースで別々のクラウドを利用していますが、将来的にはAWSにもアプリケーションを稼働させ、マルチクラウドで認可システムを運用する構想のため、許容しています。
そのため、アプリケーションからデータベースにはインターネット経由で通信しており、この構成特有の通信レイテンシーやタイムアウトといった課題に対し、対応策を先行事例で発表しているセッションを探しました。

3. Redis（インメモリデータベース）について

認可システムのキャッシュストアとしてRedisを利用しているので、Valkeyにダウンタイムなしで移行できるのか、移行した場合どういうメリットがあるか気になったため事例として発表しているセッションを探しました。

印象に残ったセッション Best 5

参加した中で特に技術的なインパクトがあり、チームでの活用を検討したいと感じたベスト51を紹介します。

Hassle-free multicloud connectivity with AWS Interconnect - Multicloud (NET205)

AWSと他クラウド（今回はGoogle Cloud）を物理層レベルで直接接続する新サービスAWS Interconnectが発表されました。

aws-interconnect

これまで、マルチクラウド間の通信には主に以下の選択肢がありましたが、それぞれ課題がありました。

  • パブリックインターネット経由: 手軽だが、外部要因の影響を受ける可能性がある。
  • Site-to-Site VPN: 暗号化のオーバーヘッドでスループットが出にくい。
  • コロケーションでの自前接続: 高速だが、物理構築に数ヶ月かかる。

AWS Interconnectはこれらの課題を解消し、数クリックでAWSとGoogle Cloud間の専用線接続を可能にするサービスとして紹介されていました。

MACsecによる暗号化

接続はMACsec(IEEE 802.1AE)で暗号化されるようです。
従来のIPsec VPNはCPU負荷が高く、スループットの低下もみられる傾向がありました。
一方、MACsecはレイヤー2で暗号化を行うため、回線速度を維持したままセキュアな通信が可能なようです。

考察

物理層やレイヤー2の暗号化がレイテンシー低減に有効であるという知識は持っていたのですが、その構築・運用ハードルは高いものでした。
物理的な回線品質がマネージドサービスとして手軽に利用できる点に、クラウドの進化を感じました。

このサービスは現在の課題に対する有効な解決策になり得ると感じました。
Google Cloud上のアプリからAWS上のTiDB Clusterへの通信ボトルネック解消に向け、実弾演習場2で検証をしようと思いました。
AWS側のAmazon Elastic Kubernetes Service(EKS)上に検証用TiDB Clusterを構築し、Google Cloudからのレイテンシーを測定しようと思いました。

Moving to Valkey without downtime (OPN406)

このセッションは、Valkeyコミュニティーの方がValkeyについての歴史と機能紹介を行い、RedisからValkey3への移行提案を紹介していたものです。
移行後の比較表では、ElastiCache for Valkeyへ移行することで、Redisと比較してコスト33%削減、パフォーマンス最大230%向上が見込めると発表されました。

redis-migrate-for-valkey-architecture

特に、Valkey 8.0よりマルチスレッドI/Oが導入されたようです。
Redisの制約だったシングルスレッドから脱却し、バックグラウンドスレッドを活用することで大幅な性能向上を実現しているようです。

考察

実際のデモを見て、コード変更なしにエンジンの置き換えだけでこれほどの恩恵が得られる点は魅力的だと思いました。
技術的な優位性はもちろん、AWSがLinux Foundationと連携して本気で推進している姿勢から、OSSライセンス問題への回答としてのスピード感も大きな学びでした。

ダウンタイムなしでの切り替えが可能であるため、実弾演習場で検証してみようと思いました。
AWSのRedisクラスタの一部をValkeyに置き換え、アプリとの互換性確認やパフォーマンス計測、コスト削減効果の試算ができるか調査しようと思いました。

Master KRMOps: Declarative resource management with Amazon EKS and kro (CNS407)

特に興味深かったのが、OSSであるKube Resource Orchestrator(kro)を紹介するセッションです。

KRMOps-architecture

Goを書かずにAPIを作る

例えば、組織独自の認可ポリシーというカスタムリソースを作りたいとします。

従来であればGo言語でOperatorを実装する必要がありましたが、kroを使えばYAMLを書くだけで完結します。
ResourceGraphDefinitionという定義ファイルに、ポリシーに必要なフィールド（許可するユーザーや権限レベルなど）と、裏側で作成されるAWSリソースのマッピングを記述するだけです。

kroがそれを読み取り、動的に認可ポリシーAPIを生成してくれます。
これをKRMOps（Kubernetes Resource Model Operations）と呼んでおり、インフラ定義の抽象化が進んでいることを実感しました。

考察

プラットフォーム開発本部ではSuper Terraform4やマイクロサービス基盤5などインフラ管理の効率化が進んでいます。
複雑なロジックを書かずに宣言的なYAMLだけでAPIを拡張するkroのアプローチは、Kubernetesネイティブな運用の理想形に近いと感じました。

TerraformとKubernetesを併用せずにKubernetesマニフェストで完結させるKRMOpsがどの様に便利になるのか検証してみようと思いました。

Accelerate platform engineering on Amazon EKS (CNS301-R1)

プラットフォームエンジニアリングの文脈で、AWSが提供するEKS BlueprintsやアップデートしたEKS Auto Modeが紹介されました。

platform-engineering-architecture

ノード管理やパッチ適用をAWSにオフロードすることで、Kubernetesの運用負荷を下げ、開発者体験の向上にリソースを割けるようになるようです。

考察

インフラ運用における運用コストの削減は重要だと理解していましたが、AWSがここまでネイティブな機能としてサポートし始めたことに時代の変化を感じました。
自前で構築する領域とマネージドに任せる領域の境界線を見極める重要性を感じました。

新機能としてNetwork PolicyとAmazon EKS Capabilitiesがリリースされた点に興味を持ったため、個人的に検証してみようと思いました。

The New York Times: From Google Cloud Platform to AWS (MAM337)

かつてGoogle Cloudの事例として有名だったThe New York Timesが、なぜAWSへ移行したのか。
そして、クラウド間でダウンタイムなしにNoSQLデータベースをどう移行したのかについて語られました。

彼らがAWSを選んだ理由ってなに？

機能比較だけでなく、ミッション達成のためのAWSパートナーシップを重視した結果とのことでした。
特に、過去のAmazon Connect導入の成功体験が、マネージドサービスへの信頼になったようです。

彼らが実践した取り組みは？

共有EKS基盤と標準化

単なるリホストではなく、プラットフォーム自体を刷新したようです。

  • Shared Kubernetes: サービスごとのクラスタ乱立をやめ、アカウント戦略を見直して共有EKS Clusterへ集約。
  • レイテンシー: 米国東部の障害時、自動的に西部リージョンへスケールする構成。
  • スタック: ネットワーク分離にCilium、高速スケーリングにKarpenter、ポリシー管理にOpen Policy Agent(OPA)を採用。

結果、開発チームのサービス立ち上げ時間が90%短縮されたようです。
基盤はプラットフォームチームが整備し、プロダクトチームは価値提供に集中するという思想が徹底されているようです。

NoSQL移行のダブルライト戦略

Cloud DatastoreからAmazon DynamoDBへのリアーキテクチャです。
ゼロダウンタイム実現のため、以下の手順でダブルライトを行ったようです。

  1. Google Cloud上のアプリがCloud Datastoreに書き込む際、同時にPub/Subへイベントを送信。
  2. AWS Lambdaがイベントを拾い、Amazon DynamoDBへ書き込み。
  3. コンバート後も、今度はAWSからGoogle Cloudへ逆方向にデータを同期し続ける（切り戻し用）。

new-york-times-re-architecture

また、Cloud DatastoreとAmazon DynamoDBの仕様差（400KB制限など）は、S3を経由するクレームチェックパターンやデータ分割で対応し、制約を回避しながら移行したようです。

考察

単なる成功事例ではなく、逆方向同期まで実装して安全性を担保する点に、エンジニアとしての堅実さを感じました。
計画と検証の徹底が成功の鍵であると再認識しました。

この事例で学んだ逆方向同期による安全策の手法に興味を持ち、認可システムで再現できないか個人的に検証してみようと思いました。
まずは実弾演習場で、GKEとEKS間のワークロード同期と切り戻し手順を検証しようと思います。

re:Inventで得た知見の実証実験

re:Inventで得た知見を元に、アプリケーションをGKEからEKSへゼロダウンタイムで移行できるか考察してみます。

前提条件

検証環境6は以下の前提で構築されています。

  • Google Cloud実弾演習場: GKEとMemorystore for Redisがすでに構築済みで、アプリケーションが提供されている状態を想定
  • AWS実弾演習場: TiDB Cloudは契約しないと利用できないためTiDB Clusterを構築している
  • シークレット管理: External Secrets Operator(ESO)を利用してGoogle Cloud Secret ManagerのシークレットをAWS Secrets Managerにコピーしています。
    GKEはGoogle Cloud Secret Managerを参照し続けます。
    新たに構築したEKS上のPodはESOを利用してAWS Secrets Managerに接続し、TiDB Cloudなどにアクセスできるようにしています。

aws-gcp-migration-architecture

検証の方向性

ダウンタイムゼロ

Moving to Valkey without downtime (OPN406)のセッションで学んだ知見を活かし、Memorystore for RedisからElastiCache for Valkeyへの移行を検討しています。
ダウンタイムなしでの切り替えが可能な手法を採用し、サービス継続性を保ちながら移行を進める構想です。

検証では、アプリとの互換性確認やパフォーマンス計測、コスト削減効果の試算を実施する予定です。

マルチクラウド接続

Hassle-free multicloud connectivity with AWS Interconnect - Multicloud (NET205)で紹介されたAWS Interconnectを利用する構想です。
専用線接続によりマルチクラウド間の通信レイテンシー低減とセキュリティ向上を実現し、ダウンタイムをなくす構成として検証する予定です。

検証では、AWS Interconnectとインターネット通信の違いを、レイテンシーとダブルライト時のパケットロスなどの観点から比較する予定です。
TiDB ClusterとEKSはAWS PrivateLinkで接続し、Google Cloud上のアプリケーションとTiDB Clusterの接続については、インターネット通信とAWS PrivateLinkの両方でパフォーマンスを確認する。

運用負荷

Accelerate platform engineering on Amazon EKS (CNS301-R1)のセッションで学んだEKS Auto Modeを採用し、運用負荷の削減を検討しています。
ノード管理の自動化により、運用の負荷を軽減し、開発にリソースを割けるようにする構想です。

検証では、運用モードを比較検討し、ノード管理の自動化による運用負荷の削減効果を評価する予定です。

検証の進捗

現時点では、GKEとEKS間の基本的な同期処理の動作確認が完了しています。
AWS Interconnect経由での通信品質や、Valkeyへの移行によるパフォーマンス向上も確認できています。
本番環境への適用に向けて、より複雑なシナリオでの検証を継続しています。

⚠️ 補足：検証では、データベースのダブルライトは実施していません。

参加を経て得たもの

最後に、セッションの内容から離れて、私自身の心境の変化についてお話しします。

弊社DMMには、技術力向上のためカンファレンス参加費や渡航費を全額支援する制度7があります。
それを利用して私もイベントに参加させていただきました。

「100万円の投資」の重みと、新卒としての覚悟

ここからは私個人の考察ですが、現地ラスベガスで日本から参加している新卒エンジニアは、私の肌感覚では非常に少数でした。
現地で交流した他社の方々からは、「1人あたり約100万円のコストがかかるため、確実に高いレベルのアウトプットを持ち帰れるベテランやマネージャー層を優先して派遣する」というお話を多く伺いました。
企業経営の視点で見れば、そうなるのも当然だと思いました。

しかし、DMMはあえてそこに、まだ実績のない新卒も送り出します。

この事実に直面した時、私は「単なるラッキーな海外出張」という甘い認識から、一気に身の引き締まる思いへと変化しました。
会社は現在の私のスキルに対してではなく、「この経験を糧に成長してくれるはずだ」という未来に対して、100万円という安くはないコストを先払いしてくれたのだと思ったからです。

「新卒だから、勉強させてもらう」ではない。
「新卒だけど、この投資以上の価値を会社に還元できるエンジニアにならなければならない」

この経験を通じて、エンジニアとしての視座が変わりました。

DMMという環境の魅力

実際に参加した私なりに解釈すると、これは単なる福利厚生ではないとあらためて感じました。
実際、1週間で受けた刺激は凄まじく、技術に対する姿勢も、エンジニアとしての視座も、帰国後の私は以前とは一皮も二皮もむけたと自負しています。

コスト対効果という短期的な指標だけにとらわれず、新卒の伸びしろと可能性に本気で100万円を投資してくれる。　 DMMはそんな懐の深さと挑戦的な文化を持つ、エンジニアにとって最高にエキサイティングな環境だとあらためて実感しました。

何が変わったのか

re:Inventという巨大な「渦」の中心に身を置いたことで、私の中で確実に何かが音を立てて変わりました。

言語の壁と課題

正直に告白すると、現地では楽しいことばかりではありませんでした。
Workshopでコードは書けても、その後のQ&Aで周りのエンジニアがメンターと繰り広げる熱い議論に入っていけない。
Chalk Talkで飛び交う生の知見を、あと一歩のところで聞き取れない。

「技術的には理解できているのに、言葉の壁だけで議論の輪に入れない」

この強烈な悔しさは、日本でオンライン学習をしているだけでは絶対に味わえないものでした。
英語は単なるテストの科目ではなく、世界中のエンジニアと知見をぶつけ合うための必須プロトコルなのだと痛感しました。
帰国した今、英語学習へのモチベーションは、かつてないほど「必要に迫られたハングリーなもの」に変わっています。

新卒という意識の払拭

これが一番大きな変化かもしれません。
現地のエンジニアたちと接する中で、誰も私のことを1年目の新人としては扱ってくれませんでした。
一人のプロとして対等に意見を求められ、技術の話をします。
そこには「新卒だからわからなくていい」「新卒だから教えてもらう」という甘えが許される空気はありませんでした。

これからは「新卒」という言葉を言い訳にせず、今回得た知見やノウハウをチームに還元し、いちエンジニアとしてDMMの認可システムをより強いものに進化させていきます。

まとめ

本記事では、re:Inventで得た技術的な知見と、参加を通じての変化について紹介しました。

AWS Interconnectやkroなどは、さっそくチームに持ち帰り、認可システムの改善に向けた検証を進めています。

DMMには、年次に関係なく手を挙げればチャンスを掴める環境があります。
この記事を読んで、少しでもDMMのエンジニア文化や、大規模なプラットフォーム開発に興味を持っていただけたら嬉しいです。

最後までお読みいただき、ありがとうございました！

thankyou

  1. 今回、私が足を運んだセッションは以下のとおりです。

    • Keynote
      • Opening Keynote with Matt Garman (KEY001)
      • The Future of Agentic AI is Here (KEY002)
    • Breakout
      • The New York Times: From Google Cloud Platform to AWS (MAM337)
      • Red Team vs Blue Team: Securing AI Agents (DEV317)
      • Hassle-free multicloud connectivity with AWS Interconnect - Multicloud (NET205)
    • Chalk talk
      • Moving to Valkey without downtime (OPN406)
      • Amazon EKS: Infrastructure as code, GitOps, or CI/CD (CNS401-R2)
      • Zero to production: Simplify AI deployments with Amazon EKS Auto Mode (CNS357)
      • Rethinking DevSecOps with Platform Engineering That Actually Works (SEC204-R1)
    • Workshop
      • Accelerate your hybrid network with AWS Direct Connect SiteLink (NET310-R)
      • Multicloud networking best practices (HMC321)
      • Accelerate platform engineering on Amazon EKS (CNS301-R1)
    • Builders
      • Securing and observing Amazon EKS clusters (CNS331-R)
      • Master KRMOps: Declarative resource management with Amazon EKS and kro (CNS407)
    ↩
  2. 実弾演習場↩
  3. ValkeyはRedisからフォークしたオープンソースのインメモリデータストアで、Redisとの高い互換性を持ちながら、マルチスレッドI/Oなどの機能強化が行われているもの。↩
  4. マイクロサービス環境におけるToilを削減するTerraformの活用 in DMMプラットフォーム↩
  5. マイクロサービス開発を効率化するテンプレート戦略↩

  6. 使用技術

    • 開発者ポータル
      • Backstage: 開発者ポータルを構築するためのオープンソースプラットフォーム (公式)
    • Kubernetes基盤
      • EKS Blueprints: プラットフォームエンジニアリングを加速するためのAmazon EKS向けの構成テンプレート (公式)
      • EKS Auto Mode: ノード管理やパッチ適用をAWSにオフロードし、Kubernetesの運用負荷を下げるEKSの運用モード (公式)
      • Cilium: ネットワーク分離を実現するKubernetes向けのContainer Network Interface(CNI)プラグイン (公式)
      • Karpenter: Kubernetesクラスタの高速スケーリングを実現する自動スケーラー (公式)
      • ESO: Kubernetesのシークレットを外部のシークレット管理システム (公式)
    • リソース管理
      • kro: 宣言的な構成を通じてカスタムKubernetesリソースの作成と管理を簡素化するKubernetesリソースオペレーター (公式)
      • ACK: インフラストラクチャリソースを管理するための統合APIを提供することでプラットフォームの機能を拡張するオープンソースのKubernetesアドオン (公式)
    • 認証・認可・ポリシー
      • Keycloak: IdPに統合された堅牢なオープンソースのアイデンティティおよびアクセス管理（IAM）ソリューション (公式)
      • OPA: ポリシー管理を実現するオープンソースの汎用ポリシーエンジン (公式)
    • 監視・可視化
      • Datadog: システムやサービス全体のメトリクス、ログ、パフォーマンスデータを監視プラットフォーム (公式)
    • CI/CD・デプロイメント
      • ArgoCD: 宣言型のGitOpsベースの継続的デプロイメントツール (公式)
      • Argo Workflows: 複雑なCI/CDとデータパイプラインのオーケストレーションを可能にする強力なワークフローエンジン (公式)
      • Argo Rollouts: Kubernetesのブルーグリーンやカナリアデプロイメントなどの高度なデプロイメント戦略を提供するプログレッシブデリバリーコントローラー (公式)
      • Kargo: GitOpsの原則を使用してマルチステージのアプリケーションプロモーションを合理化することでArgo CDを補完する継続的なプロモーションオーケストレーションレイヤー (公式)
    • アプリケーションモデル
      • Open Application Model(OAM): クラウドネイティブアプリケーションを記述するための仕様 (公式)
      • KubeVela: OAM仕様を実装したKubernetes上に構築されたアプリケーション配信プラットフォーム (公式)
    • ネットワーク・接続
      • AWS Interconnect: AWSと他クラウド（Google Cloud）を物理層レベルで直接接続するサービス。マルチクラウド間の通信レイテンシー低減とセキュリティ向上を実現 (公式)
      • AWS PrivateLink: VPC内のサービスと他のVPCやオンプレミス環境をプライベートに接続するサービス。TiDB CloudとEKSはAWS PrivateLinkで接続 (公式)
    ↩
  7. 技術者向けサポート制度｜福利厚生｜採用情報｜DMM Group↩