おはようございます。AWSエンジニアの山口です。
本記事は個人ブログの再掲載です。オリジナルは https://shimakaze.hatenablog.com/entry/2022/12/22/170349 になります。
本記事は「Japan AWS Ambassador Advent Calendar 2022」22日目の記事です。
AWS Ambassadorのアイレット株式会社 高橋 修一 さんからバトンを受け取りました。筋トレ好きな同志エンジニアからのバトンをしっかりと大切に次の方へ繋げたいと思います。
Amazon Web Services が開催する最大のラーニングカンファレンス re:Invent 2022 で発表された Amazon.com CTO Werner Vogels の Keynoteについて振り返りながら、私が感じたことを書いていきます。
re:InventのKeynoteを含むセッションはアーカイブ視聴が可能となっていますので、視聴を希望の方は下記のサイトにアクセスみてください。
Introduction
新型コロナウィルスによる海外渡航制限などの影響があり、3年ぶりにラスベガス現地でre:Inventに参加してきました。 現地参加で見聞きしたことは、体験したこと、オンライン参加の時と比較にならないほど多いと感じています。
これは現地参加することによって、re:Inventにどっぷり浸かれる環境を用意できることが強く影響しています。
オンライン参加の場合、ただでさえ時差のあるセッション配信に通常業務がある中で集中することは難しいこと、セッションの録画アーカイブ公開も見る時間を捻出することをせずに時が過ぎ去ってしまうということがあります。そして、2月、3月と過ぎる時間に比例し熱量も引いていってしまいます。
現地参加でre:Inventに集中できる時間を考えると、その差は想像に難しくないと思います。
今回は、re:Inventの中で最も楽しみにしているプログラムであるAmazon.com VP & CTO Werner Vogles の Keynote に現地参加でどっぷり浸かって感じたことを書いていきます。（アーカイブ視聴も繰り返した見たことも添えておきます）
Werner Vogles の Keynote にフォーカスする理由ですが、re:Capイベント、参加レポートなどアウトプットの多くは発表された新サービスにフォーカスしたものです。
Werner Vogles の Keynote で参加者に伝えられたメッセージは、見る人の立場によって受け止め方がさまざまであると考えています。受け止めた結果、その内容は登壇者が伝えたかった本質と異なるのかも知れませんし、その本質は受け止め方によって形を帰るものかも知れません。
そうであれば、私が受け止めた内容を共有し、フィードバックを得られるのであれば、私だけではなくAWSに関わるエンジニア全てにとって価値のあるアウトプットになるのではないかという考えに基づいたものです。
なお、Werner Vogles の Keynote はいくつかのパートに別れていましたが、この記事では イベント駆動型アーキテクチャ にフォーカスして書いていきます。
前置きが長くなりましたが、最後まで読んで頂ければ幸いです。
Asynchrony（非同期なシステムであることの必要性）
AWSのトレーニングを受けたり、Blackbeltnなどの動画をみたことがある人は良く耳にするキーワードが「非同期」です。 なぜ、非同期なシステムである必要があるのか？ 改めて例を添えて丁寧に説明しているシーンがとても新鮮でした。
要約された根本は下記のように受け止めています。
- 現実の世界は非同期
- 自分に何があっても地球は回り続ける、世界は動き続ける、宇宙は存在し続ける
- 利用する現実世界が非同期であれば、システムも非同期であるべき
- 自分に何があっても地球は回り続ける、世界は動き続ける、宇宙は存在し続ける
- Amazon S3 Design Principles(設計原則) にも Asynchrony が定義されている
Asynchrony と Parallel（並列性）
スループットとレイテンシーを両立させるには、並列処理に関する制御が必要だが、それらは同期処理では実現が困難。（ブロックポイントの存在で破綻する）
Synchroyな状況からスループットの向上とレイテンシーを抑えることを考えてみる。
同期処理：１つずつシーケンシャルに処理が進むため、スループットは１でレイテンシーは処理時間と処理連携に依存する
同期 + 並列処理：同期処理を並列で実行した場合、スループットは上がるかもしれないが、共有リソースなどブロックポイントが存在した場合は遅延がクリティカルになる可能性がある
並列処理だけでは十分ではなく、非同期かつ並列処理でなければ、スループットとレイテンシーを両立させるのは難しい。
Amazon S3 Design Principles では、非同期に加え、並列処理関わる原則も定義されている。Controlled concurrency と Controlled parallelismである。この２つはそのシステムのブロッキングポイントがどこにあるかを考えられていることを意味する。
Asynchrony 実例としてのオペレーティングシステム
OSは本質的には全てのデバイスを管理し、それらを抽象化している。デバイスは決められたタイミングでのみ動作するものではない、そのためOSとデバイスの間は、割り込み・つまりイベントドリブンに動作している。
ただ、元からOSは非同期であったのではない。ディスクへの書き込みなど処理を待たなければいけないものであった、つまり大きなレイテンシーが存在する状態だった。その状態から非同期なシステムに変わっていった。
それは非同期な現実世界で利用されるにあたり、非同期であることが求められているからである。（つまり人間は同期的に使うことの待ち時間にストレスをもつ）
Asynchrony と Decoupled systems(分散システム)
分散システムにおいて同期性は何を意味するか、それは密結合である。
上記の図では、ショッピングカートが後続の処理に密結合している。ショッピングカートの処理が失敗すると...システム全体が失敗となる。つまり、密結合なシステムは１つの処理の失敗がシステム全体の失敗を意味する。
重要なことは非同期であり疎結合であるということは、１つの処理の失敗がシステム全体の失敗を防ぐことだけではなく、それにより機能の追加、すなわちシステムの進化が容易になるということ。システム全体を変更することなく機能を追加できる恩恵を享受できる。
進化的アーキテクチャ（Evolutionary Architechture）
システムを開発する際、最終的な理想系に全て一気に開発できるものではない。（不確実な理想を求めすぎるが故に業務にマッチせず、エンハンスを意識してないため修正も難しいという悪夢のようなシーンを想像してしまった）
継続的なエンハンスがある前提として、小さなシステムから始めて、利用しながら理想的なシステムを作り上げていく。疎結合なシステムの大きなベネフィットは、機能の追加を容易にする進化的アーキテクチャであること。
（超巨大な分散システムの代表格でもある）Amazon S3は、進化的アーキテクチャであり、8つのマイクロサービスから現在は 235以上のマイクロサービスに進化している。その根本はシステムを停止することなく、他のサービスに影響を与えることなく、サービスを追加することができるから。
Appendix: Distributed Computing Manifesto
Amazon.com がアーキテクチャを進化させることができなかった事実にぶつかったとき、それらを解決するための考えをまとめた文書
なぜ、非同期で疎結合なシステムは進化的アーキテクチャなのか
- コンポーネントが独立しているため、機能の追加が容易
- 他のコンポーネントを意識する必要がない
- 失敗の影響範囲を極小化
- 失敗時の再実行処理を可能とする
- コンポーネント間のイベントブローカーにキューを利用する
世界はイベント駆動である
現実世界は発生した事象（イベント）によって動作する大規模かつ非同期な世界である。（雨が降る、土に水が染み込む、植物が水を吸い込む など）
世界は非同期であり不確実、その不確実性に対処するために最善の方法は、事象（イベント）をトリガーとしたイベント駆動であること。
イベント駆動なシステムはグローバルにスケールするシステムも作ることができる。
DynamoDB グローバルテーブルは 10兆リクエスト/日、レイテンシは1桁ミリ秒をSQSをブローカーにしたイベント駆動型アーキテクチャで実現している。
イベント駆動型アーキテクチャは自動的に疎結合へとつながる
イベント駆動型アーキテクチャは、イベントブローカー/イベントバスを境界にコンポーネント間は独立して動作している。（その効果作用を最大限動作するためには、そのように作るものであるとも言える）
下記の２つの図はいずれもイベント駆動型アーキテクチャを示しているが、イベントブローカー/イベントバスを境界にキューを使った Point-to-point、ファンアウトによるPub/sub、ComsumerによるEventrseamingでコンポーネント間が連携している。
１つのことをうまくやらせる
ゴールの法則
“正常に動作する複雑なシステムは、例外なく正常に動作する単純なシステムから発展したものである”
最初から完全なシステムを構築する場合、それは単純なシステムはなく、進化的なシステムでもなくなる。複雑なシステムだからこそ、コンポーネント間が独立し、それぞれのコンポーネントは自分の仕事に集中すべきである。
Amazon の Two Pizza ルールは、１つのチームが１つのコンポーネントに集中し、全体像を意識する必要がないようにするもの。
コンポーネント間をつなぐもの、それがイベント。イベントは構成可能であり、イベントをつなぎ合わせることで大きなアプリケーションを構築できる。
それを体現しているのがUNIXであり、UNIX Pipeが（複数のコンポーネント間すなわちプログラムの入出力を繋ぐことを）とても簡単にしている。４０年、５０年経った現在も非常に協力が概念。
余談 re:Invent 2021 の Werner Vogels の Keynote では、AMが５億リクエスト/秒をさばく分散システムであることが説明された。この説明を受け、私は下記のメッセージを受け取った。
認証認可の鍵、トークン管理、そしてキャッシュなど、シンプルなコンポーネントがうまく繋がることでなりたっているシステムであること、すなわち「１つのことをうまくやらせる」UNIX哲学を実行しているサービスであることを暗に伝えているのだと理解していた。
JAWS-UG CHIBA re:Invent 2021 re:Cap with Werner Vogels's Keynote - Speaker Deck より
昨年に受け取ったメッセージから、今年 Amazon EventBridge Pipe がリリースされた時、UNIXの根幹の１つであるUNIX pipeをAWSがサービスとして提供したという事実に鳥肌がたった瞬間を今も鮮明に覚えている。
閑話休題。
イベント駆動型アーキテクチャによって実現するグローバルスケールなシステム
AWSリージョンは世界に３０、これにより顧客により近い環境でアプリケーションを構築できる。どうやってグローバルスケールで動作するアプリケーションを実際に構築できるのか。もっとも便利に、もっとも簡単に実現するもの、それがイベント駆動型アーキテクチャである。
AmazonはそれをDynamoDBでもそれを実現してきた。
- 1日10兆のリクエスト、レイテンシは1桁ミリ秒。このような規模をグローバルテーブルを含めて、実際にサービスとして展開している
- ローカルリージョンのDynamoDBに書き込むとグローバルテーブルでは自動的の他のリージョンにレプリケートする
- さらにマルチリージョンでマルチアクティブなDBを提供している
- アクティブ・アクティブアーキテクチャで同期性はない
- コントローラーが中央的に管理してサブスクライバーに情報を提供する方法もあるが信頼性のあるアーキテクチャではない
- DynamoDBストリームとSQSがコーディネーターとなってレプリケーターとの非同期なイベント駆動型アーキテクチャを構成できる
- 障害があった場合もキューを読み直せば良い。レプリケーターは必要な数スケールすれば良い
- イベント駆動型アーキテクチャでこれらを機能させる場合に必要なパターンは３つ
- Change Data Captue
- 他のリージョンに伝える必要があるデータの変更を確認できること
- Asynchronous Coupling
- 障害復旧性、スケーラビリティをもっと処理できるためには非同期であること
- Self-healing replicators
- キューを利用することでレプリケーターが再処理することを可能にする
- Change Data Captue
宇宙（自然）は最も身近で最大なシステム
※ 宇宙を自然に置き換えた方が個人的に理解しやすかった
宇宙（自然）は私たちの周りに存在する最大のシステムである。宇宙（自然）は非常に壊れやすく、非常に高い耐障害性、弾力性、堅牢性をもっている。
とてもよくできた原理で出来上がっている。宇宙（自然）から原理から学びを得て、コンピューターシステムにそれを適用しない理由はない。
考察
なぜ様々な例を用いてキーノートでイベント駆動型を説明しているのか？
AWSにおける実例の他、ケン・トンプソン、デニス・リッチー、Martin Fowlerらを取り上げてイベント駆動型アーキテクチャは進化的アーキテクチャであることの説明を補強している。より説得性をもって参加者に伝えたいことであったのではないか。
イベント駆動型アーキテクチャは、AWS DevAx::connect の初回テーマとしても取り上げられていた。ワークショップもイベント駆動をテーマにしたものが多い。イベント駆動はこのキーノートで初めて触れられた技術ではない。
なぜ、re:Invent の Keynote で1時間超の時間をとってイベント駆動に触れたのか、いくつかの仮説を立ててみた。
・AWSが提供するプリミティブもイベント駆動での活用を期待するサービスが多いのか？ ・顧客からの相談の多くがイベント駆動型アーキテクチャで解決する課題が多いのではないか？
AWSの提供するサービスはプリミティブであり、それらをつなぐためにStep Functions や EventBridge というサービスが提供されエンハンスされている事実はあるが、いずれの仮説も実証が難しいものである。
Wernerが私たちに伝えたかったことは何か？
重要なことは、Werner Vogels が AWS の最重要イベントである re:Invent の Keynoteで 1時間超を使ってイベント駆動型アーキテクチャ の必要性を説いている事実、そして、私たちが多くのクラウドサービスの中から選択し利用しているAWSはそのサービスを稼働するためにイベント駆動型アーキテクチャを採用しているということである。
システムは自分たちの活動（ビジネス）に必要となり作っていくもの。不確実な世界では活動に求められる要件も変わってくる。 視点を変えると必要なことを実現するためのチャレンジが求められる。この課題とチャレンジはイノベーションの源泉ではないか？
この求められる進化を適用するチャレンジが行えるシステムは何なのか？その１つの答えがイベント駆動型アーキテクチャで構築されたシステムである。
Wernerは、イベント駆動型アーキテクチャが生まれた背景をre:Inventのキーノートで共有することにより、車輪の再発明をせずに、私たちもイノベーションを生み出すチャレンジができるように説いてくれたのだと受け止めた。
イベント駆動型アーキテクチャは万能ではないと理解しているが、これからシステムを構築する際には、意識するアーキテクチャとして頭に刻んでおこうと思う。
最後に
この記事がどなたかの役に立てば幸いです。そしてフィードバックなど、ぜひTwitterで @kinunori まで連絡してもらえると嬉しいです。
さて、明日は AWS Ambassadors を代表する画家 Big Bambooこと日本電気株式会社の大竹 孝昌さんです。お楽しみに！
