8
4

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

0.はじめに

NTTデータの鶴ヶ崎です。
公共分野の技術戦略組織に所属しており、普段はクラウド(主にAWS)を用いたシステム構築等を行っています。
 
この記事は「2025 Japan AWS Jr. Chanpions 夏のQiitaリレー」の11日目の記事です!
過去の投稿(リンク集)は以下からご覧ください!!
【宣伝&リンク集】2025 Japan AWS Jr. Champions 夏のQiitaリレーを行います!
 
本題ですが、先日AWS Summit Japan 2025の1日目に人生初参戦しましたので、AWS Summitの満喫方法をまとめようと思います。また、公共分野に所属してるため、公共機関におけるクラウドレジリエンス ~障害からより早く回復するシステムの作り方~(AWS-37)の参加レポートもまとめようと思います。
 
AWS Summit Japan 2026以降に参戦する方の参考になれば幸いです。

目次

1.AWS Summit Japan 2025とは

AWS Summit は、共に未来を描くビルダーが一堂に会して、アマゾン ウェブ サービス (AWS) に関して学習し、ベストプラクティスの共有や情報交換ができる、クラウドでイノベーションを起こすことに興味がある全ての皆様のためのイベントです。

image.png

クラウドをこれから検討される方も、すでに導入されている経験者の方も、ビジネス層の方も、技術者の方も、クラウドに興味があるすべての皆様を対象としています。AWS Summit Japan では新しい発見、学びがあり、インフラストラクチャとアプリケーション、生成 AI をデザイン、デプロイ、オペレーションするための情報収集およびスキルの習得に役立つよう設計されています。

AWS Summit Japan 2025の概要は以下です。

開催日時 2025 年 6 月 25 日(水) 10:00 - 18:30
2025 年 6 月 26 日(木) 10:00 - 17:00
会場 幕張メッセ
ライブ配信
オンデマンド配信期間 6 月 26 日(木) - 7 月 11 日(金)19:00
参加費用 無料
主催 アマゾン ウェブ サービス ジャパン合同会社

会場のマップは以下です。(参考)
image.png

2.体験記

2.1.会場の雰囲気

  • AWS Summit Japan 2025に参加された企業名が記載されたブラックボード
  • JAPANの"N"の隣にNTTデータの名前もありました!!
    image13.jpeg
     
  • 先着4,000名のお弁当受け取れました!!(会場到着時間は後述)
    image9.jpeg
     
  • AWS Expo(AWS Village、Industries Pavilion)の様子
    image11.jpeg
    image12.jpeg
     
  • Partner Solution Expoの様子
  • NTTデータの展示もありました!!
    image14.jpeg
     
  • AWS Outpostsを初めて見ました!!
    (入社以来AWSしか触ってこなかったため、サーバ自体を初めて見ました)
  • オンプレ環境に設置することで、低遅延・データレジデンシー要件を満たせるようです
    image3 (2).jpeg
    image7.jpeg
    (AWS Outpostsの裏側も初めて見ました)
    image5.jpeg
     
  • 会場参加型のAWS 早押しクイズ対決に、QuizKnockの4名(伊沢拓司さん、須貝駿貴さん、falconさん、Ziphilさん)がいらっしゃってました
    image2 (1).jpeg

2.2.おすすめの立ち回り

個人的に感じた、AWS Summitのおすすめの立ち回りポイントは以下です。

  • 9:20頃までに会場につく
  • 重視することを決めておく
  • 9:20頃までに会場につく
    • 来場者に先着でプレゼントがあります。筆者は9:10頃に到着し両方ゲット出来ました
    • 周りの方の話を聞いていると、9:30頃にはなくなっていたようです
      • 先着5,000名:AWS Summit Japan限定クッション
      • 先着4,000名:お弁当
        image.png

 

  • 重視することを決めておく
    • 160を超えるセッション、270を超える展示があり全て見ることは難しいため、自身が重視することを事前に決めておくことをおすすめします
      image.png

    • 筆者はオンデマンド配信期間があることを考慮し、セッション中心でなく展示中心に回り各担当者と会話することを重視しました
      (参加セッション数は、後続レポートの1セッションのみです)

2.3.swag

  • 展示中心に回った結果たくさんの企業からswagをいただきました!!
    image3 (1).jpeg
     
  • AWS認定ステッカー含め、各社のステッカーもたくさんいただきました!!
    image0 (2).jpeg

3.セッションレポート

普段は公共分野の技術戦略組織に所属してるため、公共分野におけるセッションに参加しました。
image.png

セッション名 公共機関におけるクラウドレジリエンス ~障害からより早く回復するシステムの作り方~
セッションID AWS-37
セッション概要 デジタル社会の実現に向け、政府・地方自治体・医療・教育など様々な公共機関の重要システムがクラウド上で稼働し、国民の生活を支える基盤として日々重要度が高まっています。
システム障害は国民生活に大きな影響を及ぼすため高い可用性が必要であり、障害から可能な限り早く回復するレジリエンス(回復力)を持ったシステムを構築することが重要です。
本セッションでは、公共機関におけるレジリエンスライフサイクルフレームワークを始めとするレジリエンス強化の具体的な考え方について解説します。
セッション資料 https://pages.awscloud.com/rs/112-TZM-766/images/AWS-37_Public-Sector_AWS-Summit-JP-2025.pdf
登壇者 讃岐 和広さん
アマゾン ウェブ サービス ジャパン合同会社 パブリックセクター技術統括本部 CSM・パートナー・スケールソリューション技術本部 パートナーソリューション部 シニアパートナーソリューションアーキテクト
  1. 公共システムとレジリエンス
    • 公共システムは国民の豊かな社会生活のために、なくてはならない社会基盤
    • 障害に強いシステムは、「壊れない」システムから「壊れてもすぐ回復する」システムへと解釈が変化しており、その変化に対応することが重要な課題
      image.png
       
    • IPA非機能要求グレードのうち、公共システムでは特に「可用性」「性能・拡張性」が重要視される
    • クラウドレジリエンスは「可用性」「性能・拡張性」を高めるためのアプローチ
      image.png
       
    • レジリエンス:インフラストラクチャ、依存サービス、負荷の急上昇などに関連する中断に耐えたり、中断から回復する能力
    • クラウドレジリエンス:クラウド特性を生かしてレジリエンスを確保すること
      image.png
       
    • 堅牢性:障害を防ぐこと
    • レジリエンス:障害から回復すること
    • 要件が変化する環境では、当初設計で作りこまれた堅牢性でも、その後脆くなる可能性がある =障害が起きることを前提に備えることが重要
      image.png
       
  2. レジリエンスライフサイクルフレームワーク
    • AWS規範ガイダンス Resilience lifecycle framework:AWSが開発したレジリエンス向上のための5ステップから成るフレームワーク
      image.png
       
    • ステップ1:目標を設定
      • RPO (目標復旧時点)、RTO (目標復旧時間)、SLO (サービスレベル目標)を設定
        image.png
         
    • ステップ2:設計と実装
      • ステップ1の⽬標に従い、システムがどのように障害を起こす可能性があるか理解し、迅速に回復するための技術的方式を決定し実装する
      • 「システムが静的な状態で動作し、依存関係に障害が発生したり利用できなくなったりしたときに、変更を加える必要なく、通常通り動作し続けることができる性質」である静的安定性を取り入れることが重要
        image.png
         
      • AWSサービスは、コントロールプレーン障害時でもデータプレーンは安定動作するよう設計されている
        =EC2利用者に影響が出ない
      • 障害回復において、コントロールプレーンに依存しない設計が重要
        =AZ障害時のAutoScalingによるインスタンス作成はコントロールプレーン動作のため、可用性の低い対処(アンチパターン)となる
        image.png
         
      • 3AZ構成において、2つのAZがワークロード負荷の100%を処理できるよう、十分なEC2キャパシティをあらかじめプロビジョニングしておく
        =障害回復時にインスタンス起動に依存しない(=コントロールプレーンに依存しない)設計となる
      • すべての業務で静的安定性を確保するとコスト面で見合わないため、重要業務においてサービスレベル目標に合わせて静的安定性の確保を検討することが重要
        image.png
         
    • ステップ3:評価とテスト
      • 実装したワークロードの回復力を確認するためのテスト手法を特定し、結果を評価
      • 従来の「ユニットテスト」「インテグレーションテスト」等の既知の事象に対するテストに加え、未知の事象に対するテストの「カオスエンジニアリング」も有効
        = AWS Resilience Hub の AWS Fault Injection Serviceで実現
        image.png 
         
    • ステップ4:運用
      • アプリケーションを本番環境にデプロイし、カスタマーエクスペリエンスを管理
      • 障害を検出、調査、解決するために収集すべきデータは以下
        image.png
         
      • Amazon CloudWatch Syntheticsにより、一定間隔でエンドポイントに対してトラフィックを送信(外形監視)可能で、人間よりも早くサービスの健全性をチェック可能
        image.png
         
    • ステップ5:対応と学習
      • 実際のインシデントから学び、システムとプロセスの両面でレジリエンスを継続的に強化する方法を特定
      • AWS Systems Manager Incident Managerにより、インシデント対応を一元管理・継続的に改善
        image.png
         
  3. 継続的なレジリエンスに向けたアクション
    • テクノロジーは常に変化するため、合わせてレジリエンスも変化・適応させる必要がある
    • AWS Resilience Hubによる改善サイクルを通じ、継続的な追跡・クラウドレジリエンス確保が可能
      image.png

4.おわりに

余談ですが、この度2025 Japan AWS Jr. Championsに選出いただきました!!昨年以上に頑張る1年としたいです!!

初AWS Summitでしたがとても満喫出来ました!!
AWS Summit Japan 2026以降に参戦する方の参考になれば幸いです。

※本ブログに記載した内容は個人の見解であり、所属する会社・組織とは関係ありません。また、誤った情報が含まれる可能性もありますのでご留意ください。

8
4
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
8
4

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?