【AWS】 JAWS DAYS 2025に参加してきた

イベント概要

イベント概要

JAWS DAYSは、JAWS-UG(AWS User Group – Japan)が主催し、アマゾン ウェブ サービス ジャパン合同会社の後援のもと開催される、日本最大規模のAWSユーザーコミュニティイベントです。
AWSに関する最新技術や導入事例を学べるセッションが多数用意されており、エンジニア・アーキテクト・ビジネス担当者など幅広い層が参加しました。

私は普段の業務ではAWSを直接使っていませんが、副業での活用やクラウド技術の学習の一環として参加しました。本記事では、イベントの雰囲気や印象に残ったセッションについてまとめます。

会場の雰囲気

会場は6つのトラックに分かれており、かなり広いスペースが確保されていました。

フロアマップ

また、サポーターブースやノベルティ配布エリアも大盛況で、AWS関連の企業やサービスに関する情報収集の場としても有意義でした。

フロアの様子2 フロアの様子3
フロアの様子4

「システムアーキテクト道場」に参加

今回最も興味深かったのが「システムアーキテクト道場」です。

セッション詳細

概要

このセッションは事前申し込み制で、参加者がチームを組み、講師から出された課題に対してAWSを活用したシステムアーキテクチャを設計するハンズオン形式のイベントです。
今回の課題は 「架空の水族館のオンプレミスシステムをAWSへ移行する」 というものでした。

課題の詳細(クリックで展開)

背景

  • 旧システムはオンプレ環境で、ハードウェア保守期限が2025年10月末で切れる。
  • スパイクアクセスによるサイト停止が頻発し、復旧に数時間かかる。
  • 設計書の納品を求めなかったため、保守・機能追加が不可能。
  • モバイル対応は別ページを作成する方式で、更新コストが高い。
  • コスト削減が急務(餌代・電気代・ガス代の高騰)。

ビジネス要件

  1. 入場予約システム

    • 15分間隔の予約スロットで、最終入場は閉館1時間前。
    • 予約は1ヶ月前の0時から受付開始。
    • QRコードによる非接触入場(会員:マイページ、非会員:メール)。
    • スパイク対策と混雑緩和のため、リアルタイム混雑状況表示&空き時間帯のレコメンド。
  2. リピーター向け施策

    • ファンクラブ会員向けに来館回数に応じたプレゼント企画。
    • 平日も事前予約を促進する施策。
    • 管理画面での入場者数分析(前年同月比、前月比、予約者の来館率)。
    • 決済はクレジットカードのみ。

非機能要件

  • 個人情報漏洩対策を考慮。
  • サメシャインファンクラブ登録者数:90万人、年間来場者数300万人(予約来場200万人)。
  • アクセス状況
    • スパイク時:6,000rpm、1.3GB/m
    • 通常時:2,100rpm、0.5GB/m
  • 外部システム連携
    • VPN接続を利用して、餌の仕入れ業者・獣医・お土産品業者と連携。
    • サプライチェーンリスク&ランサムウェア対策が必要。

制約事項

  • **運用コスト削減(AWS費用、作業工数)**が最重要。
  • AWS Well-Architected に沿ったモダンなアーキテクチャを推奨。
  • AWS以外のサービスも利用可能だが、なるべくAWSに寄せる。

アーキテクチャ設計の進め方

  1. プロトタイプ段階:セキュリティ考慮不要。
  2. 設計段階:セキュリティを考慮。
  3. 本番運用:セキュリティとサービスバランスを最適化。

チームでの成果物

自分たちのチームは、検討の結果以下のようになりました。

自分たちが考えたシステム図

工夫したポイント

  1. スパイクアクセス対策(CloudFront + Lambda)

    • Amazon CloudFront を導入し、リクエストをキャッシュ。
    • AWS Lambdaを活用し、バックエンドの負荷を軽減。
    • API Gatewayとの連携により、スパイク時の安定した処理を実現。
  2. セキュリティ対策

    • AWS WAFを導入し、ボットや不正アクセスを防止。
    • AWS Shield を活用し、DDoS攻撃対策を強化。
    • Amazon Cognitoによる認証基盤を構築。
    • AWS Config & GuardDuty を利用し、設定の適用状況や脅威を監視。
  3. AI活用(Bedrock)

    • AWS Bedrockを導入し、レコメンドエンジンを構築。
    • ユーザーの行動データを元に、来館の最適な時間帯を提案。
  4. サーバーレスアーキテクチャ

    • DynamoDBを採用し、フルマネージドなデータベース運用を実現。
    • AWS Lambdaを活用し、スケーラビリティを確保。
    • Amazon SESを利用し、メール配信を効率化。

他のチーム

他のチームは、以下のような形でした。

他のチームのシステム図1
他のチームのシステム図2
他のチームのシステム図3

キューを挟むことでスパイク対策する発想が自分たちのチームでは出なかったので勉強になりました。

まとめ

講師の方が最後に説明されていた、

  1. セキュリティを考えずにプロトタイプを作る
  2. セキュリティをガチガチに固める(メンテナンス経路を考慮する)
  3. サービスとセキュリティとコストのバランスをとってみる

というステップで考えるというのが、すごくしっくりくるようになりました。

面白かったセッション

ここがつらいよ分散SQLデータベース

セッション詳細

AWS DAYS 2025での「ここがつらいよ分散SQLデータベース」のセッションでは、TiDBのアーキテクチャについて詳しく説明されました。

TiDBの概要

OLTP(オンライン・トランザクション処理)とOLAP(オンライン・分析処理)の両方をサポートするデータベースとして、TiDBの内部構造がどのようになっているのかに興味がありましたが、今回のセッションで詳細を聞くことができ、とても面白かったです。

TiDBのアーキテクチャ図
TiDBのコンポーネント図

TiDBはSQLインターフェースを提供するTiDB Serverがクエリを解釈し、分散ストレージ層にリクエストを振り分けるアーキテクチャを採用しています。ストレージ層は、

の2種類があり、ユーザーのワークロードに応じて最適なストレージを利用できる設計になっています。

TiFlashがTiKVのデータを自動的に同期・変換し、OLAP向けのクエリを効率よく処理できるようになっています。 これにより、TiDBはHTAP(Hybrid Transactional and Analytical Processing)データベースとしての特性を持ち、リアルタイム分析を可能にしています。

また、タイムスタンプを用いたマルチバージョン同時実行制御(MVCC)を採用しており、TiFlashからデータを取得する際にもレプリケーションが完了してから結果を返すため、一貫性を保てるという点も印象的でした。

セッションでは、TiDBのパーサーの仕組みやレプリケーションの詳細についても触れられ、技術的な理解を深めることができました。

NewSQL

NoSQLの進化を振り返ると、BigTable、Cassandra、Dynamoといった分散データストアが発展してきた中で、NewSQLの流れが強まり、Aurora DSQLやTiDBのような分散SQLデータベースが注目される時代になっていると感じました。

このセッションは、TiDBを開発しているPingCAP社の方が登壇されており、企業ブースも出展されていました。直接お話を伺う機会もあり、とても有意義な時間を過ごせました。

分散SQLデータベースの課題として、パフォーマンスチューニングやデータの一貫性確保の難しさが指摘されましたが、TiDBのようなHTAPアーキテクチャを持つシステムが、今後どのように進化していくのか楽しみです。

恒例!AWSエンジニアたちの怒涛のLT

セッション詳細

こちらのセッションではAWSのクラウドサポートエンジニアが、一人3分ずつLTをしていくというものでした。

AWSのクラウドサポートエンジニアによる3分LTの連続セッションで、さまざまなトピックが紹介されました。

印象に残った話

システムプロンプトのTips

テンポよく次々と発表されるので聞きやすかったです。

その他

企業サポーターのブースでスタンプラリーをしていて、せっかくなのでフルコンプしてみました。(記念のステッカーがもらえました。)

スタンプラリー ゲットしたノベルティ

懇親会の抽選でワイヤレス充電器もいただきました。

良い機会をありがとうございました。

Tags: