AWS Summit Japan 2024(2日目)を終えて

おつかれさまです
2日間の熱い熱い AWS Summit Japan 2024が終わりましたね。

ライブ配信でも十分に情報は得られますが、やっぱりオフラインだと、オフィスと違って集中して見られるし、配信がないミニセッションが聞けたり、登壇者の方やAWSのエキスパートの方に業務の悩みなどを聞けたり、メリットが多かったように思います。（その反面、脚へのダメージが深刻でしたが。）

2日目はアーキテクチャに関するセッションを中心に受講しました。
会社の業務をほったらかして来たので、忘備録をかねて残しておこうと思います。

安全なリリース方法とは

大きく分けて2パターンある。

・線形デプロイ / Canaryデプロイ
・機能フラグ

「線形デプロイ / Canaryデプロイ」では、現行コンテナと新プログラムを適用した新コンテナを並行稼働させ、ロードバランサで一定割合(=10%)を新コンテナにルーティングさせる。線形では10% → 20% → 30%…と上げるのに対し、Canaryでは10% → 90% → 100%とする。

「機能フラグ」では、機能フラグをONにしたら新機能がONになるようにプログラムを実装する。AppConfigに機能フラグを設定し、サイドカーとしてAppConfigエージェントコンテナを起動させる。AppConfigエージェントで機能フラグを定期的に取得させることで、アプリ側にキャッシュなどを意識させないようにする。

この2つの方法のどちらを選んでもロールバックが簡単である。CloudWatchにアラートを設定しておくことで、自動ロールバックを行うことも可能である。ただし、不可逆な修正を含めないことに留意すること。

非同期のススメ

セッションでは様々な企業様の非同期構成の例が挙げられました。
Amazon SQSやAmazon SNS、Dynamo Stream、Lambda、Amazon S3トリガーなどを使用して、非同期にサービスを呼び出す。原則としてTrafficの終端をなるべくNorth側(=Clientに近い側)に寄せていく。

なお、クライアントとWebsocketを確立しておき、非同期処理が完了したら処理結果をサーバーサードPushする。

キャッシュの仕組みを導入する場合は、ランキングやリコメンドなどの厳密な最新さを求められないことを確認する。

モノリスアプリケーションを分割する方法

ドメイン駆動開発が実際の開発現場にキレイに落とし込まれてました。

Event Stomingを行って、ドメインエキスパートと開発者がビジネスイベントを洗い出し、ドメインを決定する。ドメインを論理アーキテクチャへマッピングする。実装にはクリーンアーキテクチャを適用し、各層でインタフェースを実装する（依存性逆転の原則）。

クリーンアーキテクチャの図が秀逸で、原本の図をうまく開発現場に紐づけているな〜、と感心しました。

アーキテクチャ道場で実力を見せつけられる

「こういう課題があるので、どうする？」をソリューションアーキテクトの方がアーキテクチャを考えて、その構成になるまでの道筋や考え方を解説してくれました。

聞いてると、そうだよね、ってなるんだけど、APIのリクエストを受け取るプロキシサービスの考え方は、さすがと思いました。ただ、サイドカーのコンテナにするとはいえ、構成が複雑なのでプロキシサービス自体がバグりそうだな、と思ってしまった。

終わりに。

個人的に、仕事で悩んでるアーキテクチャを聞いてもらえたのは良かったです。DBの代わりにOpenSearchを使用するのは新しい視点だった。

というか、1日目のミニセッションで「なんでもできるは、なんにもできないと同じ」という言葉が心に刺さっているので、オライリーの「プログラミング Rust」を買って読み始めたのが一番の成果かも。では！！！