AI時代こそ求められる設計力- AWSクラウドデザインパターン3選で信頼性と拡張性を高める-

2025年10月11日に開催されたJAWS Festa 2025での登壇資料です。
AI時代に設計力が求められる理由をお話しし、設計に使う知識の一つとしてAWSが公開しているクラウドデザインパターンの紹介を行いました。

Transcript

1. Classified as Confidential AI時代こそ求められる設計力 - AWSクラウドデザインパターン3選で信頼性と拡張性を高める- 2025/10/11 JAWS Festa 2025 in Kanazawa 株式会社オルターブース クラウドソリューション部 木村健一郎 Copyright © Alterbooth Inc. All Rights Reserved. 1
2. Classified as Confidential 自己紹介 株式会社オルターブース クラウドソリューション部 副部長 木村 健一郎(Kenichiro KIMURA) 大学院在籍中に未踏ソフトウェア創造事業に 採択され、その成果を元に設立したスタート アップに20年在籍。 2014年頃からクラウドの世界に触れる中で サーバレスとIoTに魅せられ、JAWS-UG福岡 やSORACOM UG九州のコアメンバーとして コミュニティ活動を行っている。 2020年にオルターブースにジョイン。テッ クリードとしてお客様の支援やプロダクトの 開発に従事している。 家に帰ると8歳の娘と戯れる日々。 AWS Samurai2019受賞 AWS APJ Community Award 2023受賞 SORACOM MVC2020/2023受賞 Copyright © Alterbooth Inc. All Rights Reserved. 2
3. Classified as Confidential • AI時代こそ求められる設計力 • AWSが公開しているパターンから3つを厳選して紹介 • 「抽象化された高レベルレイヤーでの理解」が重要 本日のアジェンダ Copyright © Alterbooth Inc. All Rights Reserved. 3
4. Classified as Confidential AI、特にAIエージェントが自律的にコードを書く時代の到来 • この流れは恐らく止めることはできない • これまでの技術革新の歴史を見ても、よほどのことがない限り人の意志で止めることは不可 能 • コーディングの単純な速度や単位時間の処理量(スループット)でAIに勝つこと は不可能 • 相手は機械 • 24時間365日休まず働き続ける • 圧倒的なスケールアウトが可能 • ならばこれから人にはどんなスキルが求められるのか？ AI時代に求められるスキルとは？ Copyright © Alterbooth Inc. All Rights Reserved. 4
5. Classified as Confidential AIを使ったとしても、ソフトウェア開発ライフサイクル(SDLC)は変化しない • 基本的に「作ったものを改善し続ける」 • 人は自分の欲しいものを1回で100％言語化することはできない • 人の要求も環境も変わり続ける • そもそも「変化に強い」というのがハードウェアと比較したときのソフトウェ アの重要なアドバンテージ • 変化するのが前提といってもいい • 本質的に「変更に強く、壊れにくいようにしたい」という要求が存在する ソフトウェア開発ライフサイクル Copyright © Alterbooth Inc. All Rights Reserved. 6
6. Classified as Confidential 変更に強く、壊れにくいソフトウェアを支えるのは「良い設計」です これまでに多くの枠組みや設計論が生まれ、実践されています 例： • オブジェクト指向 • SOLID原則 • クリーンアーキテクチャ • ドメイン指向設計 • デザインパターン • テスト駆動開発 ソフトウェア設計 Copyright © Alterbooth Inc. All Rights Reserved. 7
7. Classified as Confidential 変更に強く、壊れにくいソフトウェアを支えるのは「良い設計」です これまでに多くの枠組みや設計論が生まれ、実践されています 例： • オブジェクト指向 • SOLID原則 • クリーンアーキテクチャ • ドメイン指向設計 • デザインパターン • テスト駆動開発 ソフトウェア設計 Copyright © Alterbooth Inc. All Rights Reserved. 8
8. Classified as Confidential • AWSが提供する、モダンなアプリケーション設計の設計パターン集 • マイクロサービス化、水平スケーラビリティ、多様なデータストアなど、近代 的なシステムアーキテクチャでよく直面する課題に応える設計思想 • 各パターンには「問題・考慮事項」、「高レベルなアーキテクチャ実装」、お よびAWS サービスを使った具象例が含まれている • 設計のベストプラクティスを使って、信頼性・セキュリティ・コスト・パ フォーマンスをバランスよく実現することを目的としている https://docs.aws.amazon.com/prescriptive-guidance/latest/cloud- design-patterns/introduction.html Cloud design patterns, architectures, and implementationsとは Copyright © Alterbooth Inc. All Rights Reserved. 10
9. Classified as Confidential 紹介されているパターン • 腐敗防止層 • APIルーティングパターン: • ホストネームルーティング • パスルーティング • HTTPヘッダルーティング • サーキットブレーカー • イベントソーシング • ヘキサゴナルアーキテクチャ • パブリッシュ-サブスクライブ • バックオフリトライ • Sagaパターン: • Sagaコレオグラフィ • Sagaオーケストレーション • Scatter-gather • ストラングラーフィグ • トランザクショナルアウトボックス Copyright © Alterbooth Inc. All Rights Reserved. 11
10. Classified as Confidential 紹介されているパターン • 腐敗防止層 • APIルーティングパターン: • ホストネームルーティング • パスルーティング • HTTPヘッダルーティング • サーキットブレーカー • イベントソーシング • ヘキサゴナルアーキテクチャ • パブリッシュ-サブスクライブ • バックオフリトライ • Sagaパターン: • Sagaコレオグラフィ • Sagaオーケストレーション • Scatter-gather • ストラングラーフィグ • トランザクショナルアウトボックス Copyright © Alterbooth Inc. All Rights Reserved. 12
11. Classified as Confidential 障害波及を防ぐ安全弁 • 他のシステム呼び出しでタイムアウトや障害が繰り返し発生する際にリトライ を遮断 • リトライの繰り返しの影響が他のシステムに多段に影響を及ぼさないようにする • 分散システムでは常に相互の呼び出しが失敗することを想定して備える必要が ある • 発生した場合にシステム全体に及ぼす影響を最小限に抑え、早期の正常回復を目指す サーキットブレーカー Copyright © Alterbooth Inc. All Rights Reserved. 13
12. Classified as Confidential リモートサービス呼び出しの間にプロキシーとして挟まり、close状態(＝回路の 線がつながった状態)ならそのまま通信できる サーキットブレーカーの高レベルアーキテクチャ Copyright © Alterbooth Inc. All Rights Reserved. 14 Order service Payment service Circuit breaker close
13. Classified as Confidential サービス呼び出しで規定以上のタイムアウトを検知したらopen状態に遷移し、 通信をサービス側に転送しない サーキットブレーカーの高レベルアーキテクチャ Copyright © Alterbooth Inc. All Rights Reserved. 15 Order service Payment service Circuit breaker open
14. Classified as Confidential サーキットブレーカーは定期的にサービスへのリトライを行い、復旧したかを確 認する(half open状態) リトライに成功したらclose状態に戻る サーキットブレーカーの高レベルアーキテクチャ Copyright © Alterbooth Inc. All Rights Reserved. 16 Order service Payment service Circuit breaker half open
15. Classified as Confidential • サービスに依存しない実装 • コードの肥大化を防ぐために、マイクロサービスに依存しないAPI駆動型で実装する • 呼び出し元によるサーキットクローズ • 目標復旧時間(RTO)が必要な場合は、呼び出し先が障害から復旧した場合にサーキットをク ローズに変更できる拡張を検討する • マルチスレッド呼び出し • 有効期限タイムアウト値は、サービスの可用性を確認するために呼び出しが再度ルーティ ングされるまでに回路がオープンになっている期間として定義する • 呼び出し先サービスを複数のスレッドで呼び出す場合、最初に失敗した呼び出しによって有 効期限タイムアウト値を定義する • サーキットの強制開閉 • システム管理者がサーキットの状態を強制変更できるようにする • オブザーバビリティ • サーキットブレーカーがオープン状態の時、失敗する呼び出しを識別するためのログが必要 サーキットブレーカーの問題点と考慮事項 Copyright © Alterbooth Inc. All Rights Reserved. 17
16. Classified as Confidential ステートをDynamoDB、ステートの遷移をStep Functions、呼び出し先サービ スをLambdaで実装 サーキットブレーカーのAWSでの実装例 Copyright © Alterbooth Inc. All Rights Reserved. 18
17. Classified as Confidential 非同期イベント駆動 • コンポーネントを疎結合に保ち、効率的な通信を実現する • メッセージ配信をメッセージインフラに移管することで送信者はメッセージの 内容のみに注力でき、スケーラビリティと応答性が向上する パブリッシュ-サブスクライブ Copyright © Alterbooth Inc. All Rights Reserved. 19
18. Classified as Confidential 定義済みメッセージ形式でイベントを発行する入力チャンネルをプロデューサー に提供する。サブスクリプション毎に個別の出力チャンネルを作成し、コン シューマーを接続する。 プロデューサーがイベントを発行すると、メッセージブローカーは入力チャンネ ルからメッセージを全てのコンシューマーの出力チャンネルにコピーする。 パブリッシュ-サブスクライブの高レベルアーキテクチャ Copyright © Alterbooth Inc. All Rights Reserved. 20 Producer Consumer 1 Subscription 1 Subscription 2 Subscription 2 channel Consumer 2 Consumer 3 メッセージブローカー
19. Classified as Confidential • サブスクライバの可用性 • パブリッシャーはサブスクライバーの状態を認識しない • メッセージはドロップされることもある • メッセージ配信の保証 • メッセージが確実に到達するかはサービスに依存する • 生存期間(TTL) • メッセージには生存期間があり、この間に処理されない場合メッセージはドロップされる • 結果整合性 • パブリッシャーがメッセージを発行してサブスクライバーが受信するまでは遅延が生じるの で、リアルタイム性が求められる場合結果整合性が問題となる場合がある • 単方向通信 • 同期的な双方向通信が必要な場合はリクエスト-リプライパターンを検討 パブリッシュ-サブスクライブの問題点と考慮事項(1) Copyright © Alterbooth Inc. All Rights Reserved.
20. Classified as Confidential • メッセージの順序 • 順序は保証されない • 順序保証が必要な場合は、保証されるサービスを選択する • メッセージの重複 • メッセージが重複してコンシューマーに届く可能性がある • コンシューマーがべき等性を考慮するか、重複送信のないサービスを選択する • メッセージフィルタリング • トピックやコンテンツフィルターなどを提供し、サブスクライバーが受信メッセージを選択 できるようにする • メッセージ再生 • メッセージ再生機能はメッセージングインフラに依存する • ユースケースに応じてカスタム実装を提供することも可能 • デッドレターキュー • 到達できないメッセージのためのキュー(DLQ)の設置を検討 パブリッシュ-サブスクライブの問題点と考慮事項(2) Copyright © Alterbooth Inc. All Rights Reserved.
21. Classified as Confidential Payments LambdaがパブリッシャーとしてSNSのPayments topicにメッセー ジを送信し、サブスクライバーのCustomer LambdaやSales Lambda、メール 送信が実行される パブリッシュ-サブスクライブのAWSでの実装例(1) Copyright © Alterbooth Inc. All Rights Reserved. 23
22. Classified as Confidential より複雑なルーティングが必要な場合はEventBridgeを用いる パブリッシュ-サブスクライブのAWSでの実装例(2) Copyright © Alterbooth Inc. All Rights Reserved. 24
23. Classified as Confidential 分散処理での一貫性の担保 • オーケストレーターを使用して、複数のサービスにまたがる分散トランザク ションのデータ完全性を維持 • 異なるデータストアにサービスがデータを保存する場合、これらのデータスト ア間でデータ整合性を維持するのが難しい場合がある • 必要に応じて補償トランザクションを実行して、システム全体の一貫性を保つ • トランザクションの可視性と集中管理が必要な場合 Sagaオーケストレーション Copyright © Alterbooth Inc. All Rights Reserved. 25
24. Classified as Confidential 注文サービス、在庫サービス、支払いサービスの3つに対してT1～T3の3つのト ランザクションを順に実行。T3が失敗した場合は補償トランザクションC1,C2 を実行してトランザクションT1,T2を初期状態に戻す Sagaオーケストレーションの高レベルアーキテクチャ Copyright © Alterbooth Inc. All Rights Reserved. 26 Order service Payment service Inventory service Update Inventory Create Order Make Payment Update Inventory Compensate Inventory Compensate Order Sagaオーケストレータ T1 T2 T3 C2 C1
25. Classified as Confidential • 複雑さ • 補償トランザクションやリトライでアプリケーションが複雑になり、メンテナンスのオーバ ヘッドが発生する可能性 • 結果整合性 • 各トランザクションを順次実行することで結果整合性を保つが、強い整合性が必要なシステ ムでは問題が生じる可能性 • べき等性 • 予期しないクラッシュやオーケストレーターの障害が発生した場合に繰り返し実行できるよ うにべき等性が必要 • トランザクション分離 • トランザクションのオーケストレーションで古いデータが発生する可能性があるのでセマン ティックロックを使用することを推奨 Sagaオーケストレーションの問題点と考慮事項(1) Copyright © Alterbooth Inc. All Rights Reserved. 27
26. Classified as Confidential • オブザーバビリティ • 実行とオーケストレーションの問題をトラブルシューティングするために詳細なログ記録と トレースを取得する • レイテンシー • 補償トランザクションがシステム全体の応答時間にレイテンシーを追加する可能性 • 同期呼び出しを避ける • 単一障害点(SPoF) • オーケストレーターが単一障害点になる可能性 • Sagaコレオグラフィが望ましい場合もある Sagaオーケストレーションの問題点と考慮事項(2) Copyright © Alterbooth Inc. All Rights Reserved. 28
27. Classified as Confidential Step Functionsの標準ワークフローで実装 SagaオーケストレーションのAWSでの実装例 Copyright © Alterbooth Inc. All Rights Reserved. 29
28. Classified as Confidential Step Functionsのワークフロー SagaオーケストレーションのAWSでの実装例 Copyright © Alterbooth Inc. All Rights Reserved. 30
29. Classified as Confidential • AI時代こそ求められる設計力 • 「作ったものを繰り返し修正する」ソフトウェア開発ライフサイクルは変わらない • 変化に強く、壊れにくいソフトウェアを作る必要性 • AWSが公開しているパターンから3つを厳選して紹介 • サーキットブレーカー、パブリッシュ-サブスクライブ、Sagaオーケストレーション • 「抽象化された高レベルレイヤーでの理解」が重要 • AWSのサービスを起点に考えない • 具体的なサービスで設計をすると、サービスの特性に設計が縛られる • 必ず高レベルレイヤーで要件を整理し、しかる後にサービスにマップする コードサンプル、ワークショップへのリンクなどもあるので是非オリジナルのド キュメントも読んでください 本日のまとめ Copyright © Alterbooth Inc. All Rights Reserved. 31
30. Classified as Confidential • AWS公式ドキュメント https://docs.aws.amazon.com/prescriptive-guidance/latest/cloud- design-patterns/introduction.html • 「AWS 規範ガイダンス ～クラウドデザインパターン、アーキテクチャ、 および実装の解説～」 • AWSJ シニアデベロッパースペシャリストソリューションアーキテクト 福井 厚(@afukui)さんの、AWS Summit Tokyo 2025でのセッション • 資料 : https://t.co/e14YmYxkE7 • セッション動画：https://t.co/mzAGrFJOBp 参考文献 Copyright © Alterbooth Inc. All Rights Reserved. 32
31. Classified as Confidential