🙌
[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では当たり前の機能だが、リクエストの処理内容・かかった時間が可視化される



ソニーミュージックさんのテックブログで、ダッシュボードの作成に関する記事が更新されて行く予定
Tech Blog: https://tech.sme.co.jp/

可視化によって
調査確認
プロアクティブな改善
コスト削減
そして、最終的に自動化をする



 所感非エンジニアの方とどのように息を合わせるか、何を重視してプロアクティブに問題解決をしていくかという点が参考になりました。可視化によって様々な問題を少人数でもサービスを運用していけるのかなと感じました。最初に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に全てを委ねるのではなく、その機能をうまく活用しながら我々がコントロールして障害を回避することです。」

金融リファレンスアーキテクチャ日本版が参考になる
https://github.com/aws-samples/baseline-environment-on-aws-for-financial-services-institute

金融ブースでゾーン切り替えのデモ？
まとめ
マルチリージョンを活用することで、金融機関様の重要システムに必要な高いレジリエンシーを実現可能
継続的なレジリエンスをしておくことが重要



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

 [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のみの場合、削減することは可能


ここかはじめよう
候補1：ALBのdualstack化
候補2：アウトバウンド通信のIPv6化
より詳しく、IPv6 on AWSホワイトペーパーが有用
https://d1.awsstatic.com/architecture-diagrams/ArchitectureDiagrams/IPv6-reference-architectures-for-AWS-and-hybrid-networks-ra.pdf




 所感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 C: Amazon Aurora の技術とイノベーションDeep dive
以下所感。
スピーカーの方がかなり緊張されている雰囲気を感じた
リードレプリカを複数台構築する場合、インスタンスタイプを混在できることを知った。
AWS JDBCを使うと、ライターインスタンスのフェイルオーバー時にすぐに切り替えることができるのを知った。
Amazon Aurora Global Databaseというものがあるのか
switchovert / failover という機能がDRのために備えられている

Aurora Serverless
意外と即応性もあっていいのかなと思った

Managed Blue/Green Deployment
Optimized Read
pgvector
PostgreSQLのベクトル検索ちょっと面白そう


 Room O: Nintendo Switch™ 向けプッシュ通知システムのリプレイス事例
以下所感。
電源が切れていても、ネットに常時接続している
長期運用に向けて解決したい課題：
柔軟な機能追加
開発者の流動性確保
開発／運用の効率を高めたい
クラスタ構成をやめ、シンプルなアーキテクチャに、のところでどういうこと？って思った。

運用工数を削減したい
サーバーレスのFargateを活用したい


ECSのアップデートによってリプレイスができた。
TCP接続を維持するための機能のアップデート
TCP keepaliveのパラメータを変更するために、カーネルパラメータの変更が可能になった。

1 Taskあたり、数十万の同時接続
NLBのクライアントIPの保存の有効化
クロスゾーン負荷分散の設定も重要なんだと思った。


独自の仕組み
デプロイツールの自作
常時接続において、最も負荷が高いのは接続開始時で、デプロイではそれが顕著になる

負荷試験で1億台の接続を維持した状態で、挙動に問題がないことを確認しているのもすごい

仕組みを大規模に切り替えているのに、障害が無いのがすごい・・・。