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

Slide 1

Slide 1 text

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Classified as Confidential AI、特にAIエージェントが自律的にコードを書く時代の到来 • この流れは恐らく止めることはできない • これまでの技術革新の歴史を見ても、よほどのことがない限り人の意志で止めることは不可能 • コーディングの単純な速度や単位時間の処理量(スループット)でAIに勝つことは不可能 • 相手は機械 • 24時間365日休まず働き続ける • 圧倒的なスケールアウトが可能 • ならばこれから人にはどんなスキルが求められるのか？ AI時代に求められるスキルとは？ Copyright © Alterbooth Inc. All Rights Reserved. 4

Slide 5

Slide 5 text

Classified as Confidential AIを使ったとしても、ソフトウェア開発ライフサイクル(SDLC)は変化しない • 基本的に「作ったものを改善し続ける」 • 人は自分の欲しいものを1回で100％言語化することはできない • 人の要求も環境も変わり続ける • そもそも「変化に強い」というのがハードウェアと比較したときのソフトウェアの重要なアドバンテージ • 変化するのが前提といってもいい • 本質的に「変更に強く、壊れにくいようにしたい」という要求が存在するソフトウェア開発ライフサイクル Copyright © Alterbooth Inc. All Rights Reserved. 6

Slide 6

Slide 6 text

Classified as Confidential 変更に強く、壊れにくいソフトウェアを支えるのは「良い設計」ですこれまでに多くの枠組みや設計論が生まれ、実践されています例： • オブジェクト指向 • SOLID原則 • クリーンアーキテクチャ • ドメイン指向設計 • デザインパターン • テスト駆動開発ソフトウェア設計 Copyright © Alterbooth Inc. All Rights Reserved. 7

Slide 7

Slide 7 text

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

Classified as Confidential 紹介されているパターン • 腐敗防止層 • APIルーティングパターン: • ホストネームルーティング • パスルーティング • HTTPヘッダルーティング • サーキットブレーカー • イベントソーシング • ヘキサゴナルアーキテクチャ • パブリッシュ-サブスクライブ • バックオフリトライ • Sagaパターン: • Sagaコレオグラフィ • Sagaオーケストレーション • Scatter-gather • ストラングラーフィグ • トランザクショナルアウトボックス Copyright © Alterbooth Inc. All Rights Reserved. 11

Slide 10

Slide 10 text

Slide 11

Slide 11 text

Classified as Confidential 障害波及を防ぐ安全弁 • 他のシステム呼び出しでタイムアウトや障害が繰り返し発生する際にリトライを遮断 • リトライの繰り返しの影響が他のシステムに多段に影響を及ぼさないようにする • 分散システムでは常に相互の呼び出しが失敗することを想定して備える必要がある • 発生した場合にシステム全体に及ぼす影響を最小限に抑え、早期の正常回復を目指すサーキットブレーカー Copyright © Alterbooth Inc. All Rights Reserved. 13

Slide 12

Slide 12 text

Classified as Confidential リモートサービス呼び出しの間にプロキシーとして挟まり、close状態(＝回路の線がつながった状態)ならそのまま通信できるサーキットブレーカーの高レベルアーキテクチャ Copyright © Alterbooth Inc. All Rights Reserved. 14 Order service Payment service Circuit breaker close

Slide 13

Slide 13 text

Classified as Confidential サービス呼び出しで規定以上のタイムアウトを検知したらopen状態に遷移し、通信をサービス側に転送しないサーキットブレーカーの高レベルアーキテクチャ Copyright © Alterbooth Inc. All Rights Reserved. 15 Order service Payment service Circuit breaker open

Slide 14

Slide 14 text

Classified as Confidential サーキットブレーカーは定期的にサービスへのリトライを行い、復旧したかを確認する(half open状態) リトライに成功したらclose状態に戻るサーキットブレーカーの高レベルアーキテクチャ Copyright © Alterbooth Inc. All Rights Reserved. 16 Order service Payment service Circuit breaker half open

Slide 15

Slide 15 text

Classified as Confidential • サービスに依存しない実装 • コードの肥大化を防ぐために、マイクロサービスに依存しないAPI駆動型で実装する • 呼び出し元によるサーキットクローズ • 目標復旧時間(RTO)が必要な場合は、呼び出し先が障害から復旧した場合にサーキットをクローズに変更できる拡張を検討する • マルチスレッド呼び出し • 有効期限タイムアウト値は、サービスの可用性を確認するために呼び出しが再度ルーティングされるまでに回路がオープンになっている期間として定義する • 呼び出し先サービスを複数のスレッドで呼び出す場合、最初に失敗した呼び出しによって有効期限タイムアウト値を定義する • サーキットの強制開閉 • システム管理者がサーキットの状態を強制変更できるようにする • オブザーバビリティ • サーキットブレーカーがオープン状態の時、失敗する呼び出しを識別するためのログが必要サーキットブレーカーの問題点と考慮事項 Copyright © Alterbooth Inc. All Rights Reserved. 17

Slide 16

Slide 16 text

Slide 17

Slide 17 text

Slide 18

Slide 18 text

Classified as Confidential 定義済みメッセージ形式でイベントを発行する入力チャンネルをプロデューサーに提供する。サブスクリプション毎に個別の出力チャンネルを作成し、コンシューマーを接続する。プロデューサーがイベントを発行すると、メッセージブローカーは入力チャンネルからメッセージを全てのコンシューマーの出力チャンネルにコピーする。パブリッシュ-サブスクライブの高レベルアーキテクチャ Copyright © Alterbooth Inc. All Rights Reserved. 20 Producer Consumer 1 Subscription 1 Subscription 2 Subscription 2 channel Consumer 2 Consumer 3 メッセージブローカー

Slide 19

Slide 19 text

Classified as Confidential • サブスクライバの可用性 • パブリッシャーはサブスクライバーの状態を認識しない • メッセージはドロップされることもある • メッセージ配信の保証 • メッセージが確実に到達するかはサービスに依存する • 生存期間(TTL) • メッセージには生存期間があり、この間に処理されない場合メッセージはドロップされる • 結果整合性 • パブリッシャーがメッセージを発行してサブスクライバーが受信するまでは遅延が生じるので、リアルタイム性が求められる場合結果整合性が問題となる場合がある • 単方向通信 • 同期的な双方向通信が必要な場合はリクエスト-リプライパターンを検討パブリッシュ-サブスクライブの問題点と考慮事項(1) Copyright © Alterbooth Inc. All Rights Reserved.

Slide 20

Slide 20 text

Classified as Confidential • メッセージの順序 • 順序は保証されない • 順序保証が必要な場合は、保証されるサービスを選択する • メッセージの重複 • メッセージが重複してコンシューマーに届く可能性がある • コンシューマーがべき等性を考慮するか、重複送信のないサービスを選択する • メッセージフィルタリング • トピックやコンテンツフィルターなどを提供し、サブスクライバーが受信メッセージを選択できるようにする • メッセージ再生 • メッセージ再生機能はメッセージングインフラに依存する • ユースケースに応じてカスタム実装を提供することも可能 • デッドレターキュー • 到達できないメッセージのためのキュー(DLQ)の設置を検討パブリッシュ-サブスクライブの問題点と考慮事項(2) Copyright © Alterbooth Inc. All Rights Reserved.

Slide 21

Slide 21 text

Classified as Confidential Payments LambdaがパブリッシャーとしてSNSのPayments topicにメッセージを送信し、サブスクライバーのCustomer LambdaやSales Lambda、メール送信が実行されるパブリッシュ-サブスクライブのAWSでの実装例(1) Copyright © Alterbooth Inc. All Rights Reserved. 23

Slide 22

Slide 22 text

Slide 23

Slide 23 text

Classified as Confidential 分散処理での一貫性の担保 • オーケストレーターを使用して、複数のサービスにまたがる分散トランザクションのデータ完全性を維持 • 異なるデータストアにサービスがデータを保存する場合、これらのデータストア間でデータ整合性を維持するのが難しい場合がある • 必要に応じて補償トランザクションを実行して、システム全体の一貫性を保つ • トランザクションの可視性と集中管理が必要な場合 Sagaオーケストレーション Copyright © Alterbooth Inc. All Rights Reserved. 25

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

Classified as Confidential • 複雑さ • 補償トランザクションやリトライでアプリケーションが複雑になり、メンテナンスのオーバヘッドが発生する可能性 • 結果整合性 • 各トランザクションを順次実行することで結果整合性を保つが、強い整合性が必要なシステムでは問題が生じる可能性 • べき等性 • 予期しないクラッシュやオーケストレーターの障害が発生した場合に繰り返し実行できるようにべき等性が必要 • トランザクション分離 • トランザクションのオーケストレーションで古いデータが発生する可能性があるのでセマンティックロックを使用することを推奨 Sagaオーケストレーションの問題点と考慮事項(1) Copyright © Alterbooth Inc. All Rights Reserved. 27

Slide 26

Slide 26 text

Classified as Confidential • オブザーバビリティ • 実行とオーケストレーションの問題をトラブルシューティングするために詳細なログ記録とトレースを取得する • レイテンシー • 補償トランザクションがシステム全体の応答時間にレイテンシーを追加する可能性 • 同期呼び出しを避ける • 単一障害点(SPoF) • オーケストレーターが単一障害点になる可能性 • Sagaコレオグラフィが望ましい場合もある Sagaオーケストレーションの問題点と考慮事項(2) Copyright © Alterbooth Inc. All Rights Reserved. 28

Slide 27

Slide 27 text

Slide 28

Slide 28 text

Slide 29

Slide 29 text

Classified as Confidential • AI時代こそ求められる設計力 • 「作ったものを繰り返し修正する」ソフトウェア開発ライフサイクルは変わらない • 変化に強く、壊れにくいソフトウェアを作る必要性 • AWSが公開しているパターンから3つを厳選して紹介 • サーキットブレーカー、パブリッシュ-サブスクライブ、Sagaオーケストレーション • 「抽象化された高レベルレイヤーでの理解」が重要 • AWSのサービスを起点に考えない • 具体的なサービスで設計をすると、サービスの特性に設計が縛られる • 必ず高レベルレイヤーで要件を整理し、しかる後にサービスにマップするコードサンプル、ワークショップへのリンクなどもあるので是非オリジナルのドキュメントも読んでください本日のまとめ Copyright © Alterbooth Inc. All Rights Reserved. 31

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

Classified as Confidential