🙌

[AWS Summit Tokyo 2024]参加レポート

2024/06/20に公開

AWS Summit 2024に参加しました

2019年、2023年に続いて3回目の参加になります!2024年は1日目(6/20)のみ参加しました。

朝早くに出発して、海浜幕張駅に着いたのは9時過ぎでした。会場入れたのは9時30分ごろでその頃には基調講演のメイン会場は埋まっていて、サテライト会場に案内されました。入場時にはクッションがもらえるか不安だったのですが、お弁当券とともにもらえました。


クッションと弁当券

前回(AWS Summit Tokyo 2023)の参加を踏まえての改善点

以下、前回のAWS Summitに参加しての反省点と今回の結果です。概ね前回の反省が活かされていると思います。

  • もらった座布団でお尻への負荷が軽減されたので再度持って行く
    • 結果→ 再度配られるとのことだったので、持って行くのをやめた
  • スライドはいずれ公開されるので、公演中はスライドを撮影せずに集中する
    • 撮影しても結局見返すこともなく、写真撮るよりセッションに集中したほうが有益なため
    • 結果→ この記事を作成しながらのスタイルはとてもよかった
  • 事前に参加票を印刷しておく
    • 前回もそうして楽に・すぐに入場できたため
    • 結果→ 受付時に印刷したものを強制的に渡してくれたため事前の印刷は不要だった
  • 会場で借りるイヤホンは耳が痛くなる
    • ヘッドフォンを持って行く(プラグが対応するかは不明)
    • 結果→ ヘッドフォンを利用するセッションは2つしか取っていなかったが、耳への負担が減ってよかった

参加した目的

AWS Summitへ参加したのは以下が目的になります。

  • AWSのイベントに参加したい
  • 去年も参加して楽しかった
    • ウェルカムパフォーマンスのDJがかなりよかった
  • Claudeの基調講演を聞きたい
  • 他社事例を聞いてみたい

AWS Summit 2024の全体的な印象

  • 基調講演のサテライトオフィスでは、同時通訳の方がいた
    • 日本語はありがたかった反面、英語の声を聞きたかった
  • AWS Summit 2023と比べて
    • 入場者数がかなり多くなった気がする。発表だと5万人以上らしい
    • セッション中にカメラで撮影する人が少なくなった気がしたが、そうでもなかった
  • お弁当の選択肢が2つになっていた
    • 塚田農場のお弁当がとても美味しかった。
  • 聞いたセッションが前年と比べて面白いのが多かった気がする
    • 生成AIに関するセッションは聞かなかったが、生成AIに関するトピックはすごく多かった


生成AIに関するブース

各種セッションとその所感

以下、参加したセッションのまとめと所感です。まとめの文章に関してはChatGPTを用いて要約したものを編集しています。

[10:00 - 11:30] 基調講演 AWS と創る次の時代

まとめ

AIの歴史を振り返り、自動化の考えは3000年前からあり、AIが進化する中で「機械は考えることができるか」との問いが重要でした。AIは現在、持続可能な未来や高齢化社会への対応、農業やヘルスケアでの活用が進んでいます。AIを善(for good)に使うにはデータの民主化が必要で、良いAIには良いデータが不可欠です。

箇条書き内容。

ハイミ バレス(Amazon Web Services Inc. APJ バイスプレジデント & マネージングディレクター 兼 日本マネージングディレクター)

「13回目になりました。ようこそお越しくださいました」
登録は5万人を超える。

AWSの日本に対するコミットメント
日本への投資とBedrockの2番目の解放について。

ヴァーナー ボーガス(Amazon.com, Inc. 最高技術責任者(CTO)兼バイスプレジデント)

「こんにちは、東京!(東京の皆さん、こんにちは)」

AI for good.
AIをどのように善として使うか。
ジョンマッカー氏「AIが機能し始めたら、もはや誰もAIと呼ばなくなるだろう」

  • AIの歴史を振り返ってみる
    • 3000年前から自動化は考えられていた。
    • アランチューリング「機械は考えることができるのか?という問いに真剣に取り組もうではないか」
      • トップダウンの潮流
        • エキスパートシステム
      • ボトムアップの潮流
        • 具現化されたAI、日常からの感覚を使って実現しようとする。
  • (感想:AIの定義を拡大しようとしている気がする。)
  • 「今後数年で急速に進展すると思う。」
  • AI for now.
    • ここで今話したいのは、今後ではなく今の話。
  • AI for hard human problems.
    • 大きな問題とは?
      • 2050年には、97億人になると言われている。経済的にも暮らしていける未来を。
      • 持続的な未来を考える必要がある。
      • 日本に関して言えば、高齢化社会に取り組んでいる。
      • インドネシアのHARAの例。小規模農家のIDを作成して、農地などのデータを取得・AIで活用した。
  • AI for food.
    • コメに関して研究しているところがある。
    • 品種改良を積極的に進めていかなければいけない。
    • 世界中から送られてくるタネを仕分けるのが大変だが、AIを活用している。
    • (感想:「すでに利用されているAIは存在している」といいたそうだけれど、それは本当にAIだけなのか?AIを過大評価してない? )
    • What about protein ?
      • 主食ではなく、たんぱく質に着いて考える。
      • 魚類の養殖が効果的。1kgの資料から1kgのタンパク質を得られる。牛は7kgの資料が必要。
  • AI for healthcare
    • マンモグラフィーの画像を多く学習して、危険を察知できる。
    • (感想:各種領域において、AIを活用しようとしているように見える。)
    • ドローンを活用してワクチンを配達(他の方法だとダメなの?)
    • 疾患の予防をすることが今後の方針になると思う。
  • Data. The foundation for all AL.
  • Data is a privileged asset.(データはみんなには解放されてない。)
    • 例として、OpenMapはみんなにデータを提供している。
    • 善を行いたければ、データの民主化が必要。
  • 構造化データから非構造化データへ。
    • To find a needle in haystack, ML is the magnet. (you need the magnet)
    • Good AI needs good data
    • Good data needs good AI
    • Good work needs good people

恒松 幹彦(アマゾン ウェブ サービス ジャパン合同会社 執行役員)

  • 10年後に変わらないものを見つけることが大事。
    • 85%はオンプレで、まだまだクラウドは拡大して行くことを予想している。
  • 最近の導入例
    • docomoがクラウドと合わせて5Gを展開して行くことを決めている?
    • JPXのカーボン市場?を3.5ヶ月で構築した。
    • 関西電力では標準クラウドとしてAWSを利用。
    • 小売業回において、イオンファイナンシャルは、セキュリティ強化を目的に16システムをAWSに移行しており、基幹システムの以降も考えている。
    • 盛岡市は、ガバメントクラウドの先行例として、参加している。

ジャレッド カプラン氏(Anthropic)

  • AIはまだ変革が始まったばかりで、拡張が始まると従来の技術と比べて拡張し続けると予想している。

    • どのようにして責任をはたしながら生成AIモデルを考えるか?
  • 原則(憲法)に基づいて学習していく。

    • ポリシーを明確に定義している。
  • 変革的な未来に向けて今日から準備を始めることが必要!
    (ここのスライドは重要そう!)

  • Claude 3を東京リージョンで利用可能に!

3層のスタックとして定義している。

1: Trainumなど
2: Bedrock
3: Amazon Q

変化の激しい中で、最も大切なのは適応力。

小寺 剛 氏(ソニーグループ株式会社)

ソニーグループの生成AIの取り組み。
「人に近づく」というのが経営の方向性。

Sony内では社員一人ひとりが生成AIにアクセスできる社内ツールを作成している。

  • 生成AI搭載型アプリケーション

企業内のデータには以下の内容がある。

  • データレイク
  • データベース
  • データ統合
  • ガバナンス

ビジネスの中核に組み込むためには。

  • ユースケース
  • モデル選択
  • 責任あるAI
  • カスタマイズ
  • アプリ統合

所感

Anthropicの発表は意外とあっさりしていました。各国の広義のAIを使った事例紹介は面白かったです。

[11:50 - 12:30] Dive deep on Amazon S3

「経験を積むための圧縮アルゴリズムは存在しない」

まとめ

S3はピークトラフィックは1PB/secを超えている。フリート全体にリクエストを分散させるための対策として、multi-value answerを実装している。通常はS3をマウントするのはバッドプラクティスだが、Mountpoint S3を使うことで解消できる。インデックスの管理では、prefixを利用しキーの命名の仕方でTPS(Transaction Per Second)を最大化することができる。S3のストレージ層では冗長性を確保し、99.999999999%の耐久性を実現している。誤削除対策としては、S3 Versioning、Replication、Object Lock、Backupsが提供されている。

箇条書き内容。
  • はじめに
    • 生成AIというセッションがたくさんある
    • 「経験を積むための圧縮アルゴリズムは存在しない」という考えが大事!
      • There is no compression algorithm for experience
    • 3つの歩み
      • リアクティブ -> 脅威モデルイング -> プロアクティブ
      • リスク障害の経験をして、ドキュメントにまとめてサービスに反映する
      • プロアクティブでは、未知の脅威
    • カルチャーがどのようにサービスに反映されるか?
  • Amazon S3 とは?
  • フロントエンドの理解
    • Webサーバ、DNSなど
    • ピークトラフィックは 1[PB/sec]を超える
    • スケールするように実装している
      • 緩和策を対応している
    • フリートに渡ってリクエストを分散させる
      • nslookup s3.amazonaws.comでmulti-value answerを実装している
    • Common Runtime (CRT)
      • コード実装済みのペストプラクティス
    • Mountpoint S3
      • S3をマウントするのはバットプラクティスではなかったの?
        • HTTPでやり取りするのがベストプラクティスなため
        • ファイルの処理をHTTPに、相互翻訳している。
        • つまりCSIドライバー対応
        • どちらかというと機械学習で簡単にアクセスするためのサービス
  • インデックスの理解
    • ストレージ層へのKey/Valueマップ
      • 350兆のオブジェクト
    • UsageとCapacityのグラフ
    • S3の裏側もオートスケールしている
      • prefixの概念を用いることが重要
      • prefixとは、バケットの後ろに続く文字
        • sample-bucket/p などのp
        • たくさんのオブジェクトがあっても性能が下がらない
        • 3,5000PUT [req/s] 5,500 GET [req/s]
          • これを超えるようなリクエストがあった場合には503を返す
          • prefixの配置によってこれらの制約を乗り越えることができる
          • prefix単位でリクエストが大きくなって行くため、
      • キーの命名によるTPSの最大化
        • カーディナリティは左に寄せておく
        • 日付は右側に寄せておくのが良い
        • BAD: sample-bucket/day1
          • この場合、/day2のprefixがあると、day1で用意された環境がうまく使われたない
          • ただし、わかりにくさもあるので、ユースケースに応じて考えること
  • ストレージ層の理解
    • 媒体でのデータの冗長性確保
    • 駅さバイトのデータ何百万ものストレージ
    • 99.999999999 %
      • イレブンナイン, 11 9s
    • 11 9sの耐久性の実現のために複数の生合成チェクをしている
      • リクエストの整合性チェック 送信するしあのチェックサムを取得し、最後のチェックサムをのチェックサムも取得している。
      • データは常に冗長化されたデバイスに格納される
        • いれーじゃーコーディング?
        • 大規模に実現している
    • AZ障害に対して
      • マルチAZがデフォルトになっている
        • PUTリクエストの場合には全てのリージョンに配置されたことを確認して200を返す
  • Amazon S3 Express One Zone ストレージクラス
    • General purpose bucketと異なり、Directory bucketはシングルAZで運用されている
    • 該当のAZで障害があった際にはデータを失う可能性がある
    • なぜ、開発された?
      • Amazon S3自体は多くのリクエストを処理できる
        • レイテンシを低減したいアプリケーションがあり、それに対応できていない
      • どのように高パフォーマンスを実現している?
        • 2つの考慮事項
          • AZへの配置によってネットワークレイテンシに影響がある、EC2と同一のAZに立てるなど
          • One Zoneのストレージには異なる耐久性能がある
        • Directory bucketsは、バケット単位でスケーリングしている
      • セキュリティモデル
        • バケットポリシーにセッションの認可を付与する
          • 通常のS3とこなり、オブジェクト単位で認可が入らない
    • 誰が使うか?
      • 機械学習のため
  • 誤削除への対策
    • S3 Versioning
      • ゴミ箱機能
    • S3 Replication
      • 別のリージョンにコピーを取る
    • S3 Object Lock
      • 法務機能
      • 削除を許さない
    • Backups
      • Vaultというところにしまうことができる

所感

Amazon S3 Express One Zoneを詳しく知らないのもあってかなり有益なセッションでした。そのほかにもインデックスとリクエストの仕組みなどを知れてよかったです。この話を聞けて今日のAWS Summitに来てよかったと感じました。

[13:30 - 14:00] 1,000 を超える Web サイトを少人数で運用するソニーミュージックソリューションズ様のオブザーバビリティ実現例

まとめ

7人で60以上のAWSアカウントを管理し、1000を超えるサービスを運用している。日々の運用対応が大変で、特にモノリシック構成ではサイトごとに異なるリソース使用状況の調査が困難であった。改善活動をうまく進められなかったので、Dynatraceを採用し非エンジニアでも使えるダッシュボードとアプリケーションレイヤーの可視化で、プロアクティブな改善やコスト削減、最終的な自動化を目指していく。

箇条書き内容。
  • 「音楽は好きですか?」という質問
  • 60以上のアカウントの管理を7人で対応している
    • 1000を超えるサービスを運用している
  • 運用における悩み
    • 日々の運用に時間が割かれ、改善活動がしづらい
  • モノリシック構成が抱える悩み
    • サイトによってリソースの使われ方が異なるため、調査がしづらい
  • プロアクティブな対応ができていない
    • サイトごとの負荷のかかり方が異なってしまうので、障害が発生するまで問題が表面化しにくい
  • dynatraceの採用について
    • なぜ選んだのか?
      • 1: 非エンジニアが使えるダッシュボード
        • エンジニア以外でも調査でき、処理時間を中心とした指標で共通の目線で会話できる
          • ダッシュボードがみやすいかどうかを確認することが大事
        • 知識のばらつきをなくせる情報と可視化
      • 2: アプリケーションレイヤーの可視化ができること
        • APMでは当たり前の機能だが、リクエストの処理内容・かかった時間が可視化される
  • ソニーミュージックさんのテックブログで、ダッシュボードの作成に関する記事が更新されて行く予定
  • 可視化によって
    • 調査確認
    • プロアクティブな改善
    • コスト削減
    • そして、最終的に自動化をする

所感

非エンジニアの方とどのように息を合わせるか、何を重視してプロアクティブに問題解決をしていくかという点が参考になりました。可視化によって様々な問題を少人数でもサービスを運用していけるのかなと感じました。最初にDynatraceの会社の人が出ていたので、どういうことかと少しだけ心配になりました。

[14:20 - 14:50] イオン生活圏を支えるシステム基盤と決済を担う当社の取り組み

まとめ

イオングループの金融サービスは約6000万人のユーザーを持ち、100以上のシステムで支えられています。2023年からクラウド基盤へ移行し、セキュリティ強化とコスト競争力を追求。システム統合とマルチクラウド化を進め、物理マシンと仮想環境を統一。現在、クラウドシフトによるコスト削減と運用課題に取り組みつつ、キャッシュレス推進などDXの取り組みを進行中。

箇条書き内容。
  • 大量のシステムをどのようにクラウドに載せるかの話
  • フィナンシャルサービスについて
    • イオングループ:店舗数17,887、従業員数約59.9万人、営業収益9兆円
      • グループをまとめて、「イオン生活圏」としている
    • イオンフィナンシャルサービスは金融業をまとめるサービス
      • 実際には6000万人くらいのユーザーがいる
      • 100を超えるシステムでささており、サーバーは1,000台以上
  • システム基盤の高度化
    • 2023年からクラウド基盤へ
      • セキュリティ強化とベンダー価格競争力を創出する
      • 2017年までは、ベンダーロックインが強く、サービスごとにバラバラだった。
      • 2018年から3年かかって基盤を統一して載せ替えた。
      • 本当は2022年からクラウド基盤へ移行したかったが、社内からの親切なお言葉のおかげで、1年間モノゴトが進まなかった。
      • 今日はこのクラウド基盤移行の話が中心で、ただAWS中心にしているわけではない
    • STEP1: 統合基盤化
      • システム単位で品質標準や工程管理がバラバラだったのを統一化
      • 物理マシンと仮想環境を統一
    • STEP2: クラウド化・運用統合
      • マルチクラウド化
      • オンプレの環境と3クラウドの環境をしっかり繋げている
      • 統合運用基盤に、DataDogとservicenow(ほかにも色々なサービス)を利用している
        • こだわり:オンプレも含めて管理している、クラウドを横断して利用できるサービスを
      • 150システムをシステム状況・特性に応じて計画・クラウドシフトする
      • VMWare系のライセンス体系変更問題によって、クラウドシフトを加速したい
      • 3クラウドにしたのは、コストの限界だったため。
      • クラウドシフトって課題も多い
        • コスト削減はできない
          • 価格はオンプレト比較してとんとん
        • Oracle問題
          • だいたいOracleで全て作成しており、別DBにしようとするとアプリケーションにも手が入り大変
        • メンテナンスによる停止
          • アメリカのメンテナンス時間が日本の繁忙期に当たって辛い
        • オートスケール問題
          • 意外とすぐにオートスケールしてくれない
    • STEP3: グループ統合
      • 今後の方針
      • 整備したクラウドを展開する
  • イオンフィナンシャルシステムのDXの取り組み
    • キャッシュレス推進
      • 年々上がってきているが、諸外国と比べると以前として低い水準
      • 逆にいうと、伸びしろ・チャンスはある
      • 新しい決済基盤を作成している

所感

統一した言葉で、進めて行くことはとても重要だと再認識しました。ただ、規模が大きすぎて、自分が関わっている業務の参考にはならなかったなと思いました。ただOracle問題など、裏側や苦労した箇所が聞けて楽しかったです。

[14:50 - 15:30] 金融機関様のマルチリージョン事例からクラウドのレジリエンスを紐解く

「100%の可用性は達成できない」

まとめ

国内の155金融機関の93%がレジリエンス確保を主題においています。Capital Oneでは、カード決済処理においてマルチリージョンやオーバープロビジョニングを活用し、迅速な回復力を確保しています。住信SBIネット銀行も顧客視点でマルチリージョンを選択し、AWS機能を活用しながら障害回避を実現しています。

箇条書き内容。
  • 国内の金融機関様の利用状況(国内155行)
    • 93%の銀行が利用
  • レジリエンス:回復力・抵抗力・弾力性
    • ITシステムの迅速な回復など
  • レジリエンス確保に向けたメンタル帆デルの変化が必要
    • 特に利用者の目線に立って、影響軽減の仕組みが必要
    • チームや組織の障害対応力の強化に繋がり、それらのメンタルモデルが今後重要になってくる
  • レジリエンスにおける責任共有モデル
  • Capital Oneの事例
    • カード決済処理は1日70億件以上
    • レジリエンスの議論はどこから?
      • ビジネスチームを起点に考えた
        • お客様に提供したい体験と満たすべき内容
      • その後、各プロダクトチームとSLAを議論
    • リージョンレベルで並列化する
    • アーキテクチャについて
      • コンピューティング:Lambda, ECS, Fargate
      • データ連携:SQS, SNS, AppSync, StepFunctions, Amazon EventBridge
      • データストア:RDS, DynamoDB, S3
    • なぜマルチリージョンが必要か
      • 非常にレアなケースでも重要業務が継続できるよう回復力を高めるため
    • Disaster Recoveryの目標の検討
      • RPO
      • RTO
    • Active/Standby と Active/Active構成
      • カード限度引き上げ処理にはActive/Standby
      • カード決済にはActive/Active
    • レジリエンしを高めるために、リソースをオーバープロビジョニングを実施し、20%余裕を持って準備しておく。
    • 性的安定性
      • 依存先が利用できなくなった場合でも、追加の変更を加える必要性がなく、システムは通常通り動作し続けること
  • 住信SBIネット銀行の事例
    • 158万口座
    • 顧客視点からマルチリージョンを選択
    • 「クラウドでは我々がコントロールできない障害も発生します。大事なのはAWSに全てを委ねるのではなく、その機能をうまく活用しながら我々がコントロールして障害を回避することです。」
  • 金融リファレンスアーキテクチャ日本版が参考になる
  • 金融ブースでゾーン切り替えのデモ?
  • まとめ
    • マルチリージョンを活用することで、金融機関様の重要システムに必要な高いレジリエンシーを実現可能
    • 継続的なレジリエンスをしておくことが重要

所感

レジリエンスの定義・そこからサービスの落とし込みなどの確認をした方がいいと思いました。メンタルモデルの話は参考になりました。イオンの事例でもあったのですが、金融系はマルチクラウドが当たり前なんだなと思いました。

[16:50 - 17:30] IPv6 on AWS ~Public IPv4 アドレス削減に向けてできることできないこと~

まとめ

IPv4アドレスの枯渇と取引価格の上昇(2014年に$7から2022年に$60)により、AWSでは料金変更が生じました。IPv6の普及率は50.54%で、AWSでIPv6を利用するにはセキュリティグループやルートテーブルなどを別途設定する必要があります。AWSのIPv6対応には、Internet GatewayやNAT Gatewayなどがあり、IPv6導入によるコスト削減の可能性もありますが、ALBのdualstack構成が現実的な選択肢です。

箇条書き内容。
  • IPv4アドレスの動向とAWSにおける影響
    • IPv4の枯渇問題
      • これまで割り当てられていなかったアドレス帯や、返却されたアドレスを際割り当て
    • IPアドレスとの取引価格の上昇
      • 2014年は$7だったが、2022年は$60
    • AWSへの影響:料金変更
      • Amazon VPC IP Address Managerで確認可能
      • 導入背景
        • 調達コストが過去5年間で300%以上増加
        • 使い続けないといけない場面もあるが、並行利用を検討してほしいという意図
    • AWSでIPv6を使うには、2つのネットワークについてそれぞれ設計・設定・管理・運用が必要になる。
      • セキュリティグループやルートテーブル・ゲートウェイも別途設定が必要
    • IPv4とIPv6のDualstack構成
      • カプセリングやアドレス変換
    • IPv6の普及率:50.54%
      • システム・アプリケーション側が対応すればいい。
  • AWSのIPv6対応
    • IPv6でInternet通信する際に関連するGateway
      • Internet Gateway
      • Egress-only Internet gateway
        • 片方向通信が可能
      • NAT Gateway - DNS64
      • NAT Gateway - NAT64
    • ユースケース
      • EC2はIPv4なしを選択できる
      • コンテナへの対応
        • EKSはpodごとにIPアドレスを消費する
  • IPv6導入よってコスト削減が可能なこと
    • 移行することでコスト最適化は可能?
      • YesとNo
    • ALB:IPv4を廃止してIPv6に移行することは現時点では難しい
      • dualstack構成をとるのが現実的
      • やるとしたら、ALBの共有
    • NAT Gateway
      • Egress-only internet Gatewayは無償
      • 通信相手がIPv4のみの場合、削減することは可能
  • ここかはじめよう

所感

IPv6の基礎・前提がわかっていないと、途中からついて行くのが難しかったです。ALBのdualstack化は普段あまり意識していなかったのですが、重要なんだなと感じました。AAAAは「クアッドAレコード」と呼ぶことを知りました。あと、Public Subnetが単一AZの中に2つあって、1つにNAT Gateway、1つにALBを割り当てている図がありベストプラクティス的にはそうなのかと疑問に思いました。

ネットワーク周りの話は知らないことも多く、コスト削減に繋がることも多いのでとても学びのあるセッションでした。

気になったブースとその所感

空いている時間はセッションなどを聞きに行っていたため、あまり多くのブースを回ることはできませんでした。加えて、ブースに行ってもすでに話を聞いている人でいっぱいだったりすることもあり、あまり多くのブースを回れませんでした。

数少ないですが、回ったブースの中で気になったブースについて軽くまとめます。

AWS Villageの中の生成AI活用事例ブース

生成AIで特定のログのエラーをサマリーでまとめて、Slackなどに投げる仕組みが紹介されていて比較的簡単に実装できそうなのと、アプリのエラー検知・修正が楽になりそうと思いました。
フロントエンドとバックエンドのログはバラバラのところに置かれているため、それらを横断して参照するのも有用そうだなと思いました。

AWSで妄想してみたブース


AWSで妄想してみたのブースイメージ

8つの実現したい内容と、AWSを使っての解決案が紹介されていました。実現可能性もパーセンテージで表示されており、参考になるものもありました。

来年度に向けて改善した方がいいなと思ったこと

前回も思ったのですが、Ask an Expertを活用したいと思いました。せっかく、セッションもしてもらって聞ける機会があるので有効活用したいなと思いました。それに備えて、日々疑問に思ったことなどはまとめておくと良いなと思いました。

全体のまとめ

AWS Summit 2023と比べて、体感的にはなるのですが入場者数が多いような気がしました。


AWS Summit 2024のメインステージ

お弁当を今年ももらいました。今回は2種類から選べたので前回は無かった(はずの)「塚田農場」のお弁当をいただきました。とても量も多く美味しかったです。お茶も無料でもらえて大変ありがたかったです。天気も曇りだったので外で食べました。


お弁当券でもらった弁当

色々なブースをもらってお菓子をもらいました。Fortienetでもらったビックリマンチョコは特製らしくすごいなと思いました。new relicではガラガラを回してTシャツをもらえました。


ブースを回ってもらったノベルティ

今回のAWS Summitも非常に有益だったので来年もまた行きたいなと思いました。

AWS Summit終了後

AWS Summitのマイページにて、2024年7月5日まで視聴できます。単なる記録して視聴したセッションと所感を書いていきます。

Room A: Amazon EC2最新情報

所感:Amazonの専用設計チップのおかげでAWSそのものの開発スピードが上がっていると聞いてすごいなと思った。

Room A: チームのつながりをInfrastructure as Codeでデザインする

所感:比較的規模が大きめのチーム・チーム間の課題解決のために、IaCを用いるとよい、という内容だった。セッション中で言及されていた、インフラエンジニアが多言語を学ぶきっかけとしてIaCに取り組むというのは、自分がTypeScriptを取り組み始めたきっかけと一致していてすごいなと思った。

Room B: アーキテクチャ道場 2024 !

以下所感。

  • テーマはレジリエンスで、それに関するアーキテクチャに関するお題を2つ出されていた。「グレー障害:観測される状態を見方・視点によってエラーが起きているように見える状態」、「ブラウンアウト:機能は正常だが性能の低下やエラーレートが上昇している状態のこと」などの単語を知った。
  • 事例1から、場合によってはAZの切り外しやAZ間の独立性を高めることも重要だと知った。
    • クラスタ内通信やDBのリードエンドポイントはAZ間で独立しているが、DBのライターエンドポイントは共有にしている
    • CW Logsの複合メトリクスを利用して、AZ内だけでエラーが起きているか、リージョン全体ではないかなどを検知する
    • AZの切り離しはRoute 53 ARCを利用している
    • プライマリのDBがあるAZ障害の場合は、RDSを別AZに移す
  • 事例2は「依存性障害への対処」として、信頼性が低いサードパーティのAPIへ接続する場合を考慮している
    • 同期書き込み方式・非同期書き込み方式・ダイレクト読み込み方式・キャッシュ読み込み方式で対応する
    • AWSサービスを使った実装例も参考になった
      • プロキシをコンテナのサイドカーとして実装するのもアリ
    • 設計に関して、論理モデルから物理モデルに段階的に進めているので良い
  • クラウド上では、障害の原因を取り除くのは本質的に難しいので、障害をコントロールする方が大切
    • 船舶でいうと、船底にあるバルクヘッドと同じ

Room O: Nintendo Switch™ 向けプッシュ通知システムのリプレイス事例

以下所感。

  • 電源が切れていても、ネットに常時接続している
  • 長期運用に向けて解決したい課題:
    • 柔軟な機能追加
    • 開発者の流動性確保
    • 開発/運用の効率を高めたい
      • クラスタ構成をやめ、シンプルなアーキテクチャに、のところでどういうこと?って思った。
    • 運用工数を削減したい
      • サーバーレスのFargateを活用したい
  • ECSのアップデートによってリプレイスができた。
    • TCP接続を維持するための機能のアップデート
      • TCP keepaliveのパラメータを変更するために、カーネルパラメータの変更が可能になった。
    • 1 Taskあたり、数十万の同時接続
      • NLBのクライアントIPの保存の有効化
      • クロスゾーン負荷分散の設定も重要なんだと思った。
  • 独自の仕組み
    • デプロイツールの自作
      • 常時接続において、最も負荷が高いのは接続開始時で、デプロイではそれが顕著になる
    • 負荷試験で1億台の接続を維持した状態で、挙動に問題がないことを確認しているのもすごい
  • 仕組みを大規模に切り替えているのに、障害が無いのがすごい・・・。
GitHubで編集を提案

Discussion