はじめに
この記事はAWS Summit 2023の4/21(金)に発表された[AWS-28]アーキテクチャ道場 2023！のレポートです。
私はAWS Summitのコンテンツの中でアーキテクチャ道場が一番好きなのですが、今年のSummitでもやはり学びが多かったです！
熱が冷めないうちに今後の自分に向けた備忘録として残しておこうと思います。
今回のアーキテクチャ道場 2023！の中では2つのお題(マルチプレイ可能なオンラインゲーム、モバイル通信事業者のユーザー管理サービス)があり、それぞれについてAWSのソリューションアーキテクトの方が設計し、レビューワーの方がフィードバックする、という形式を取っています。
そして、セッションの最後にレビューワーのAWSチーフテクノロジスト内海さんの総評がAWSアーキテクチャを考える上で非常に重要なこととして私に刺さりまくったので、今回はそこにフォーカスして共有します。
いきなりですが、まずは結論です。
結論
1. 良い設計の流れ
まずはシンプルな設計をしてから、問題を考えてそれを解決できるアーキテクチャにブラッシュアップしていく
2. 二段階で設計してみる(抽象度の高い設計->具体的な設計)
まずはAWSサービスなど特定の実装方法に依存しない抽象度で骨組みとなるアーキテクチャを作る
次にAWSサービスを利用した場合の具体的な実装方法を反映したアーキテクチャを作る
詳細
以下、２つの詳細です。
1. 良い設計の流れ
- まずはシンプルな設計をしてから、問題を考えてそれを解決できるアーキテクチャにブラッシュアップしていく
利点
- 必要最低限のところからスタートして、想定課題とその解決策を反映するとオーバーエンジニアリングが起きにくい
- アーキテクチャ決定の背景や流れが説明しやすい
例
- まずは左側のようにシンプルなアーキテクチャからスタートする。
- そこから可用性・応答性能などの想定課題を出していって、それらの解決策を反映していき、左側のようなアーキテクチャにブラッシュアップしていく
2. 二段階で設計してみる(抽象度の高い設計->具体的な設計)
- まずはAWSサービスなど特定の実装方法に依存しない抽象度で骨組みとなるアーキテクチャを作る
- 次にAWSサービスを利用した場合の具体的な実装方法を反映したアーキテクチャを作る
利点
- 実装に依存しない抽象的なアーキテクチャがあることで、設計意図が明確になり、変化が速いAWSサービスのアップデートに追従しやすい
例
まずは左側のアーキテクチャのように特定のサービスに依存しないような設計を考える。
思ったこと・感じたこと
- 個人的には2つ目の内容、2段階で設計してみることは特に重要だと感じました。変化が速いAWSサービスのアップデートの中でも自分たちが取り入れるべきものが明確になるためです。
- また、どんなところにアンテナを張ってアップデートを追っていくかの指針にもなるため、自分たちのチームで実装したサービスに対して後追いでも抽象度の高いアーキテクチャを作ることもとても意味があると感じました。
- 自分の心にすごく余裕があったり、冷静に考えられるときは無意識にやっていたこともありますが、必要に迫られて効率的にやろうとすると大事なことをすぐ忘れて目の前のタスクに取り組んでしまいがちです。アーキテクチャを考えるときには何度もこの記事を見返して一度立ち止まって落ち着いて取り組もうと思います。
- やはりアーキテクチャ道場!は最高に楽しい＆学びがある！