こんにちは、ラーニングサービス本部の山下です。
昨年行ってまいりましたAWS re:Invent 2022のWerner Vogels さんキーノートについて感じたことをレポートします。

並列、非同期、イベント

キーノートの冒頭にイメージムービーが流れました。
Wernerさんはハンバーガーショップに並んでいます。このお店どうやら満席ではなさそうですが、お客さんは1人入って出てくる、それを待ってから次の人が入れます。
ようやくお店に入れたWernerさんは 「ハンバーガーとフライドポテト」を注文しようとします。でもウェイターさんに「1つずつ」と言われます。ウェイターさんは1つ聞いて1つ伝票にメモして、次の注文を聞いてまた伝票にメモします。

注文を受けたウェイターさんは、バンズを並べパティを焼きトマトをカットしてハンバーガーを作ります。作り終えると次にポテトをフライヤーで揚げ始めます。1本ずつカットしてフライヤーに入れ、揚げ終わってまた次のポテトをカットしてフライヤーに入れます。
冗談のような極端に非効率な、順序が守られた同期の世界です。

実世界にも同じような制約が設けられていることはあります。
並列や同時に行ったほうが効率的なのことでも、なぜか実行、チェック、実行、チェックを小さな単位で繰り返して非効率な作業手順を変えさせない。
または、システムがそのような手順でしか処理できないようになっているので仕方がない。
システム設計が現実のイベントとあっていない。
その極端な例をまざまざと見せられたオープニングムービーでした。

現実の世界に同期など存在しない

Wernerさんはステージで一言めで「この世に同期など存在しない」と言い放ちます。
システムを構築する際には現実の世界に目を向けなければならず、その現実の世界は非同期なイベントが同時多発的に発生しています。それなのになぜ業務の仕組みを同期にするのか。この課題を真っ向からテーマとして捉えたところかキーノートは始まりました。

なぜ同期にするのか？同期が簡単だからかもしれない。ミスを恐れる人ほど非効率な同期を求める傾向にあるように思う。ミスが良いとは思いませんが、何一つ効率化も改善もできない前進できない状態に留まってまでミスを恐れる必要はあるのだろうかと考えました。そして非同期にしてもそれほどミスは実際には起こらないのでより良い非同期な設計をすればいい。

1人のウェイターが順番に注文を取って、作って、運んで、決済しているから非効率になりお客様を待たせています。
注文を取る人、作る人、運ぶ人、決済する人、それぞれがそれぞれの役割をし、それぞれが個別にスケールすれば、非同期なイベントをそれぞれのスタータスに応じて並列処理できます。

疎結合

非同期に動作できるコンポーネントたちは、そのコンポーネントの変化のためにほかのコンポーネントには影響を与えません。追加の機能が必要な場合にもシステム全体を変更することなく追加できます。それぞれのサービスやコンポーネントを疎結合することで依存性を減らせます。

Wernerさんは「疎結合する理由はそれが自然だから」と言います。
障害を切り分ける自然な方法であり、そしてアーキテクチャを簡単に進化できることが、疎結合の最大のメリットです。

その例としてS3をあげていました。
S3は2006年に最初8のマイクロサービスから構成されていて、現在は235を超えるマイクロサービスで構成されています。
確かに、暗号化、アクセスポイント、オブジェクトロック、ストレージクラスなど様々な機能が今でも追加され進化し続けています。

25年前のアーキテクチャ

25年前にAmazonが直面していた課題を解決し、今後の開発の方向を示していた文書のAmazon's Distributed Computing Manifesto, 1998を最近公開したことを発表しました。

この文書を読んで理解したことや思ったことを以下に書き留めておきます。

最初は2層のモノリシックアプリケーションだったAmazonのアーキテクチャを、1998年にビジネスロジック、データを分離しながら見直すための基礎として提案された分散コンピューティング宣言です。まず大きく3層(クライアントインターフェイス、ビジネスロジックサービス、データ)に分けることが提案されていますが、この各層でも分散させていることが読み取れます。
サービスは同期メソッドと非同期メソッドにそれぞれ分けられ、キューメッセージで疎結合してポーリングモデルが推奨されています。SQSがAmazonとAWSにとって重要なサービスであることが伺えます。

2層時代の課題として、クライアントが直接データベースにアクセスしていることが挙げられています。変更やスケーリングによりクライアントインターフェイスに直接的な影響があることを示しています。データベースに対してアクセスするモデルとしてサービス層が必要であるとしています。データベースのテーブルや列の変更をサービス層で吸収して、クライアントによって依存されないように設計するべきとしています。

ECサイトの注文処理はワークフローベースのモデルとして扱うことに適しています。注文パイプラインによって注文から出荷までの処理が流れていきます。しかしこの注文パイプラインの各処理を1つのデータベースと単体のプロセスに集中させているため、過負荷になり持続できなくなります。
この課題を解決するためにワークフロー処理を分散させ、個別にスケールさせる設計を提案しています。そしてキューモデルだけではなく、状態遷移の記録についても触れています。この時点でStep Functionsに通じる考え方があったのですね。
データベースの集中については、例として顧客、ベンダー、カタログをそれぞれ別のデータに分割すること、各データにアクセスするためのデータサービスを開発することで解決しています。

顧客の属性変更にはパブリッシュ/サブスクライブで複数のアクションへ反映するファンアウトなど、今も引き継がれる設計の基本が網羅的に記載されています。
​​​​​​​

マイクロサービスとイベント

疎結合で進化できるワークフローが必要です。順番に実行したりリトライしたり並列で実行したり分岐したりをどのように構築するか。AWSにはStep FunctionsとEventBridgeがあります。

大量データの並列実行が必要なときにEMRがありますが、もっとシンプルなソリューションを求めますね。1つの処理はシンプルなのに実行環境が複雑なのは避けたいです。1つの処理にLambdaを実行して並列処理をしたいだけです。
ということでStep Functions Distributed Mapが発表されました。
S3バケットのオブジェクトやCSV、JSONリストを対象に大規模な並列処理が実行できます。
Mapの中で例えば配列データに対してLambda関数を実行し、Mapを抜けたあとにそれぞれのアウトプットを集約するLambda関数で処理します。
1つ1つのLambda関数は小さな処理として、全体で大規模な分散集計処理が実行できます。
これを大規模な環境を用意せずにサーバーレスで実行できます。

世界ではいつ起こるかわからない不確実なイベントが発生しています。シンプル性もありません。
これに対応するためにはイベント駆動型のシステムを構築することです。
そしてEventBridge Pipesが発表されました。
さまざまなAWSサービスからのメッセージを簡単に次のAWSサービスへ渡すことができます。フィルタリングして必要なメッセージだけを抽出することもできるようです。

ほかにもCodeCatalystやApplication Composerが発表されました。
このキーノートでは、Amazon、AWSの設計基本である非同期、並列、疎結合、マイクロサービス、イベントドリブンについて改めてわかりやすくユースケースとあわせて紹介されていました。AWSが推奨するAWSのよりよい使い方を知る上でも、とても良い教材にもなりますのでおすすめです。