JAWS UG 函館勉強会 Vol12
徹底解説マイクロサービス 〜マイクロサービスのメリット、デメリット、なぜマイクロサービスを選択するのか〜
© 2023, Amazon Web Services, Inc. or its affiliates.© 2023, Amazon Web Services, Inc. or its affiliates.徹底解説マイクロサービスAtsushi FukuiJ A W S U G 函 館 勉 強 会 V O L . 1 2Senior Solutions Architect, Developer SpecialistAmazon Web Services Japan〜マイクロサービスのメリット、デメリット、なぜマイクロサービスを選択するのか〜
View Slide
© 2023, Amazon Web Services, Inc. or its Affiliates. All rights reserved. Amazon Confidential and Trademark⾃⼰紹介v名前v 福井 厚（ふくい あつし）twitter: afukui@v所属v アマゾン ウェブ サービス ジャパン合同会社v シニアソリューションアーキテクト• Developerスペシャリスト - DevAxv関⼼領域v ソフトウェア アーキテクチャ、オブジェクト指向設計、アジャイル開発v好きなAWSサービスv サーバーレステクノロジー全般、 AWS Code シリーズ
© 2023, Amazon Web Services, Inc. or its affiliates.Agenda• マイクロサービスとは• なぜマイクロサービスアーキテクチャを採⽤するのか• マイクロサービスに適した組織• マイクロサービスのアンチパターン• どうやってサービスを分割するのか• ドメイン分割のためのEvent Storming• まとめ
© 2023, Amazon Web Services, Inc. or its affiliates.© 2023, Amazon Web Services, Inc. or its affiliates.マイクロサービスとは
© 2023, Amazon Web Services, Inc. or its affiliates.マイクロサービスとは• ビジネスドメインに基づいて分割された、独⽴してデプロイ可能なサービス映画情報サービス料⾦サービス通知サービス予約サービス発送サービス課⾦サービス料⾦情報の問い合わせ上映⽇イベント予約情報問い合わせ
© 2023, Amazon Web Services, Inc. or its affiliates.マイクロサービスの重要な概念『マイクロサービスアーキテクチャ第2班』オライリー・ジャパン、2022
© 2023, Amazon Web Services, Inc. or its affiliates.マイクロサービスの性質疎結合で、独⽴性が⾼い• 独⽴してデプロイ可能• つまり各サービスが疎結合• ビジネスモデルの境界に沿って分割• Web 三層 ⇔ ドメインモデル• 技術的な境界に沿って分割しない• 変更要求に対し、複数のサービスを横断してデプロイすることになる• 各サービスが⾃⾝でデータを所有する• データベースを共有しない• データはWeb APIやイベントなどで受け渡す『マイクロサービスアーキテクチャ第2班』オライリー・ジャパン、2022
© 2023, Amazon Web Services, Inc. or its affiliates.© 2023, Amazon Web Services, Inc. or its affiliates.なぜマイクロサービスアーキテクチャを採⽤するのか
© 2022, Amazon Web Services, Inc. or its Affiliates.7割33 年企業を取り巻く環境の変化1964 年 ⽼朽システムが、DXの⾜かせになっていると感じているS&P 500 の企業の平均寿命12 年2027 年出典: Innosight 「2018 Corporate Longevity Forecast」 出典:経済産業省 「DX レポート」https://www.meti.go.jp/press/2018/09/20180907010/20180907010-2.pdfレガシーが⾜かせ
© 2022, Amazon Web Services, Inc. or its Affiliates.書店︖ タクシー︖ DVD︖業界の再定義ホテル︖気分や⽬的に合わせた宿泊体験不安、⾯倒のないタクシー移動いつでもどこでも娯楽を提供世界最⼤の宿泊サービス提供世界最⼤規模の配⾞事業世界有数のエンターテイメント世界最⼤規模の EC で品揃え･低価格･利便性を提供Amazon Account を使⽤し⾳楽･映画等のサービス提供
© 2022, Amazon Web Services, Inc. or its Affiliates.『』“…innovation is now recognized asthe single most important ingredientin any modern economy…”イノベーション こそが近代経済において最も重要な要素と考えられている。競合よりも早く、新しい波を創っていくことが重要
© 2022, Amazon Web Services, Inc. or its Affiliates.イノベーションがビジネスを進化させる新たなマーケット新たな顧客価値New economics新たなデジタル製品とサービス
© 2022, Amazon Web Services, Inc. or its Affiliates.ListenIdeaExperimentInnovationFlywheel実験がイノベーションを加速する
© 2023, Amazon Web Services, Inc. or its affiliates.マイクロサービスに変更する理由チームの⾃律性チームの規模が⼩さくなることでコミュニケーションコストが減る⾃⾝のサービスを完全にコントロールでき、⾃律的⾃発的な機能改善に繋がるアジリティ各機能を他の機能のリリースを調整せずにリリースできるようになるスケーリング負荷が⾼い機能のみをスケーリングすることができる堅牢性負荷が⾼まったとき、リリースによる障害などの影響が単⼀のサービスにとどまり、アプリケーション全体としての堅牢性が⾼まる採⽤技術の柔軟性各サービス毎に異なる⾔語やアーキテクチャ(VM/コンテナ/サーバーレス/etc)を採⽤できる
© 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved.© 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved.© 2023, Amazon Web Services, Inc. or its affiliates.マイクロサービスに適した組織
© 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved.© 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved.マイクロサービスの組織とチームビルディング• ⾃律的で意思決定する権限と責任を持つチーム• 開発したチームが運⽤も⾏う（You build it, you run it）• Two Pizza Team• すべてを所有
© 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved.© 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved.参考︓チームトポロジーストリームアラインドチームストリームアラインドチームストリームアラインドチーム共有サービスプラットフォームチーム内部プラットフォームチーム][セキュリティコミュニティ・オブ・プラクティス(CoP)プラットフォーム + ツール)()(フィールドチーム (サポート、ソリューションアーキテクト、営業)O製品機能のリクエストストリームアラインドチームビジネスに沿った⽬標を持つチームイネーブリングチームストリームアラインドチームが障害を克服するのを⽀援。コンプリケイテッド・サブシステムチーム専⾨性が必要な機能を担当する専⾨スキルを持つチームコラボレーションファシリテーションO)(フェデレーションサービス(X-as-a-Service)][データサイエンスチームサービスとしてのプラットフォームキー:)()(][* マシュー・スケルトン,マニュエル・パイス. チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計 (Japanese Edition). Kindle Edition.
© 2021, Amazon Web Services, Inc. or its Affiliates. All rights reserved. Amazon Confidential and Trademark© 2021, Amazon Web Services, Inc. or its Affiliates. All rights reserved. Amazon Confidential and Trademark1994-2001 2002+モノリシックアーキテクチャ +階層化組織サービスの分割 + Two-pizzaチーム1000+マイクロサービス100+ purpose-built databasesAmazonにおけるデプロイメント変遷︓2001-2002
© 2021, Amazon Web Services, Inc. or its Affiliates. All rights reserved. Amazon Confidential and Trademarkコンポーネントの分割原則• 可能な限り⼩さなユニットにする（プリミティブ）• データドメインの作成• 関数単位ではなくスケールファクタによる分割• 個々のサービスは独⽴して運⽤組織間の連携による待ち時間の発⽣を抑える• サービス間はAPI（契約）で連携これにより組織の変更が導かれました
© 2021, Amazon Web Services, Inc. or its Affiliates. All rights reserved. Amazon Confidential and Trademark© 2021, Amazon Web Services, Inc. or its Affiliates. All rights reserved. Amazon Confidential and Trademark組織の再編成の開始“Two-pizza” teams• サービスを所有• 制約を最⼩化（コンウェイの法則）• 意思決定のための⾃⽴した組織
© 2021, Amazon Web Services, Inc. or its Affiliates. All rights reserved. Amazon Confidential and Trademark© 2021, Amazon Web Services, Inc. or its Affiliates. All rights reserved. Amazon Confidential and Trademark組織の再編成の開始ひとつのチームでどうやって実⾏するのか?すべてを所有• 計画• セキュリティ• パフォーマンス• スケーラビリティ• デプロイメント• 運⽤• バグ• ⽂書化• テスト…
© 2021, Amazon Web Services, Inc. or its Affiliates. All rights reserved. Amazon Confidential and Trademark専任のシングルスレッド化されたチームでフローを最適化専任の商品担当チーム商品開発商品化商品マネージャープロジェクトマネージャー開発者テスト担当者インフラ担当者運営とサポート商品チーム B商品チーム A商品チーム Cバックログ A• ストーリー 1• ストーリー 2• ストーリー 3• ストーリー 4バックログ A• ストーリー 1• ストーリー 2• ストーリー 3• ストーリー 4バックログ A• ストーリー 1• ストーリー 2• ストーリー 3• ストーリー 4
© 2021, Amazon Web Services, Inc. or its Affiliates. All rights reserved. Amazon Confidential and Trademarkスクラムロール例スクラムマスター、開発者、プロダクトオーナーチームにアジャイルな⽅法論を適⽤スクラムボード例
© 2021, Amazon Web Services, Inc. or its Affiliates. All rights reserved. Amazon Confidential and Trademark組織内の “サイロ” 化が勢いを無くす要因オペレーションデータベースチーム品質保証アプリケーションセキュリティソフトウェア開発チーム“開発環境のセットアップを待機するため作業を中断"“新しいテーブルや SQL スクリプトを待機するため作業を中断"“パフォーマンステストを待機するために作業を中断"“ ソースコードの⼿動検査を待機するため作業を中断 "“データベースセキュリティの承認待機するため作業を中断"“セキュリティテストの完了を待機するため作業を中断"“セキュリティ証明書の作成を待機するため作業を中断"“データベースホストのセットアップを待機するため作業を中断"“新しいテストのホストを待機するために作業を中断 ”
© 2021, Amazon Web Services, Inc. or its Affiliates. All rights reserved. Amazon Confidential and TrademarkマイクロサービスはDevOpsのスタイルで運⽤すべきオペレーションデータベース管理者品質保証(テスト担当者)アプリケーションセキュリティソフトウェア開発チーム“共働"
© 2023, Amazon Web Services, Inc. or its affiliates.© 2023, Amazon Web Services, Inc. or its affiliates.マイクロサービスのトレードオフ
© 2023, Amazon Web Services, Inc. or its affiliates.マイクロサービスのトレードオフ分散システムに伴う複雑性ネットワーク呼出による連携となり、モノリシックシステムでメソッドを呼び出すときには発⽣しなかった考慮点が発⽣するネットワークのエラーや遅延、呼出先のダウン、障害発⽣時のトラブルシューティングなど整合性の担保モノリシックなシステムではトランザクションで容易に強⼒な整合性を担保できるマイクロサービスで同様の整合性は担保できないマイクロサービスの統廃合やリファクタリングが困難モノリスではIDEの機能で⾃動的にインターフェースやクラスの分割、抽出、統合が可能で、データスキーマも整理可能マイクロサービスでは、そのような統廃合は複数のサービスチームの調整やデータの移管が必要
© 2023, Amazon Web Services, Inc. or its affiliates.トレードオフの対策分散システムに伴う複雑性⾮同期なイベント駆動で連携したり、同期API呼出の場合はサービスメッシュを利⽤する整合性の担保整合性が必要な単位でマイクロサービスを分割しないどこで整合性が必要なのか、ビジネスのモデリングが必要サーガパターンなど、結果整合性を担保するデザインパターンを利⽤するマイクロサービスの統廃合やリファクタリングが困難統廃合がなるべく発⽣しないよう、ビジネスのモデリングが必要
© 2023, Amazon Web Services, Inc. or its affiliates.© 2023, Amazon Web Services, Inc. or its affiliates.マイクロサービスのアンチパターン
© 2023, Amazon Web Services, Inc. or its affiliates.チーム内に意思決定する権限がない• ビジネス的な価値を提供するために、どの機能を優先的にリリースするかをチームで決定できない• ユーザーからのフィードバックを受けて何をどのように改善するかを決定できない• チームが自律的に行動できる組織になっていない
© 2023, Amazon Web Services, Inc. or its affiliates.開発メンバーの数がサービスより少ない• 開発者3人で20以上のマイクロサービスを開発しているなど• 開発者がボトルネックとなってリリースや改善の頻度が低下
© 2023, Amazon Web Services, Inc. or its affiliates.バックエンドのデータベースを各サービスで共有• マイクロサービスではない• 密結合になっておりマイクロサービスのメリットが活かせない
© 2023, Amazon Web Services, Inc. or its affiliates.サービス単位ではなく機能単位のチーム構成している• UI、アプリケーション、データベースなど機能単位にチームが分かれている「マイクロサービスアーキテクチャ 第2版」オライリージャパン 2022
© 2023, Amazon Web Services, Inc. or its affiliates.ドメインをまたがって密結合になっている• ビジネスドメインの境界に従ってサービスが分割されていない• 境界づけられたコンテキスト間はドメインイベントで疎結合にする• 分散システムでは、非同期、結果整合を許容する必要がある
© 2023, Amazon Web Services, Inc. or its affiliates.明確な目的もなくマイクロサービスを選択している• 銀の弾丸ではない• 「流行っているから」「新しい手法だから」という理由でマイクロサービスアーキテクチャを選択しない• マイクロサービスのもたらす価値と複雑性のトレードオフを考慮
© 2023, Amazon Web Services, Inc. or its affiliates.© 2023, Amazon Web Services, Inc. or its affiliates.どうやってサービスを分割するのか
© 2023, Amazon Web Services, Inc. or its affiliates.マイクロサービスの性質（再掲）疎結合で、独⽴性が⾼い• 独⽴してデプロイ可能• つまり各サービスが疎結合• ビジネスモデルの境界に沿って分割• Web 三層 ⇔ ドメインモデル• 技術的な境界に沿って分割しない• 変更要求に対し、複数のサービスを横断してデプロイすることになる• 各サービスが⾃⾝でデータを所有する• データベースを共有しない• データはWeb APIやイベントなどで受け渡す『マイクロサービスアーキテクチャ第2班』オライリー・ジャパン、2022
© 2023, Amazon Web Services, Inc. or its affiliates.ドメイン駆動設計 (DDD) とは• 高品質なソフトウェアモデルを設計するためのソフトウェア開発手法• ユビキタス言語 ー ビジネスドメインエキスパートと開発者の間の意思疎通として利用される用語によってモデリングと設計を行う• 戦略的な設計のためのガイドライン ー境界づけられたコンテキスト、蒸留、大規模な構造の考察• 戦術的な設計 – 集約、エンティティ、値オブジェクト、ドメインサービス「エリック・エヴァンスのドメイン駆動設計」：エリック・エバンス著 2011/4/9 翔泳社「実践ドメイン駆動設計」：ヴォーン・ヴァーノン著 2015/3/16 翔泳社
© 2023, Amazon Web Services, Inc. or its affiliates.境界づけられたコンテキスト• 境界づけられたコンテキストは特定の• モデルを適⽤できる限定された範囲。• コンテキストの境界を定めることで、• チームメンバーは何を⼀致させるべきで何を独⽴して開発できるのかについての理解を明確化し、共有できる。https://www.martinfowler.com/bliki/BoundedContext.htmlCustomerTicketProductProductversionCustomerProductTerritoryOpportunityPipelineSalespersonDefectSales context Support context
© 2023, Amazon Web Services, Inc. or its affiliates.コンテキストマップSales context Support contextMarketing context境界つけられたコンテキストだけでは、ドメインの全体像を⽰すことはできない。コンテキストマップは、境界づけられたコンテキストを統合することにより、異なるが関連するユビキタス⾔語のマッピングを処理する。DDDでは境界づけられたコンテキストを統合するための７つのパターンを説明• 共有カーネル (Shared Kernel)• 顧客/供給者の開発チーム (Customer/SupplierDevelopment Teams)• 順応者 (Conformist)• 腐敗防⽌層 (Anticorruption layer)• 別々の道 (Separate ways)• 公開ホストサービス (Open/Host service)• 公表された⾔語 (Published language)
© 2023, Amazon Web Services, Inc. or its affiliates.モデル駆動設計を構成する⾔語のナビゲーションマップモデル駆動設計サービスエンティティ値オブジェクトファクトリ集約リポジトリ利⼝なUIモデルを表現するのに使⽤するモデルを表現するのに使⽤するモデルを表現するのに使⽤する排他的な選択アクセスするのに使⽤する整合性を保つのに使⽤する アクセスするのに使⽤するルートとして機能するカプセル化するのに使⽤するカプセル化するのに使⽤するカプセル化するのに使⽤するカプセル化するのに使⽤するレイヤ化アーキテクチャドメインを隔離するのに使⽤する
© 2023, Amazon Web Services, Inc. or its affiliates.© 2023, Amazon Web Services, Inc. or its affiliates.どうやって境界づけられたコンテキストを定義するのか
© 2023, Amazon Web Services, Inc. or its affiliates.© 2023, Amazon Web Services, Inc. or its affiliates.ドメイン分割を導くのためのEvent Storming
© 2023, Amazon Web Services, Inc. or its affiliates.Event Stormingの概要• ⾼品質なモデリングのための簡単なワークショップ• ドメインエキスパートと開発者が協⼒して実施• 業務から、境界づけられたコンテキストとモデルを導き出す
© 2023, Amazon Web Services, Inc. or its affiliates.Event Stormingの流れ - Big Picture• Eventの洗い出し、時系列化• Pivotal Event (分割点になるEvent )をマーク• スイムレーン(並行処理、分岐点) の発見• 関係者/外部システムを洗い出し• 上記完了後に、ナレーション/ウォークスルー
© 2023, Amazon Web Services, Inc. or its affiliates.Event Stormingの流れ – Process Modeling• 洗い出したイベントをつなぎプロセスに§ コマンド§ ロール§ リードモデル§ ポリシー§ システム§ ホットスポットhttps://www.slideshare.net/ziobrando/software-design-as-a-cooperative-game-with-eventstorming/27
© 2023, Amazon Web Services, Inc. or its affiliates.Event Stormingの流れ –Software Design• 集約を見つける、名前をつける• 境界づけられたコンテキストを見つける• 設計の詳細に入り、コーディングに進められるようにする
© 2023, Amazon Web Services, Inc. or its affiliates.境界づけられたコンテキストとドメインモデル在庫 オークション支払い台車ピッカー配送サービス倉庫商品棚位置サイズ重さ配送顧客配送先入札 落札商品SKU画像価格入札顧客ID 検索サービス落札顧客クレジットカード支払い
© 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved.© 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved.データソースをサービスの所有ごとに分割⽀払いオークション在庫共有されているモノリシックデータベースモノリシックシステム⽀払いオークション在庫商品や顧客などもサービスによって利⽤する属性が異なるので、それぞれのサービスの所有するデータへ移⾏する。データソースの移⾏計画も検討。顧客マスタ配送顧客 ⼊札顧客 ⽀払顧客
© 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved.© 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved.戦術的設計• 集約、値オブジェクト、エンティティー• ドメインイベント50
© 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved.© 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved.値オブジェクト• 構成要素の値によって識別されるオブジェクト• 識別⼦（ID）を必要としない• 例えば「⾊」値オブジェクト• イミュータブルで変更する場合は全体を置き換えclass Color {private _red:number;private _green:number;private _blue:number;constructor(red:number, green:number,blue:number){this._red = red;this._green = green;this._blue = blue;}//...other methods}
© 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved.© 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved.エンティティ• 明確な識別⼦（ID）を必要とする• エンティティーはライフサイクルを持つ• エンティティーは更新可能• 例えばPersonエンティティclass Person {private _id:string;private _name:string;constructor(id:string, name:string){this._id = id;this._name = name;}//...}
© 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved.© 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved.集約• 同⼀のトランザクション境界に属するエンティティと値オブジェクトの組み合わせ• 集約もエンティティなのでIDが必要• 集約がトランザクションの単位集約のルートエンティティ値オブジェクトエンティティ10…*1…*1ID
© 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved.© 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved.例 – オークションの集約オークション競売参加者オークション品1 *1⽀払い⽅法配送⽅法*11 154集約ルート 在庫11競売⼈11*
© 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved.© 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved.集約のルール• 集約はシンプルに⼩さく保つ• 集約の状態はパブリックインターフェイスでのみ変更可能• 集約はトランザクション境界、集約の状態変更はアトミックな操作としてコミットする必要がある• 集約内のエンティティや値オブジェクトを表現する集約ルートを選択
© 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved.© 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved.集約の関連• 他の集約への参照としてIDを利⽤• 他の集約の更新はドメインイベントを利⽤した結果整合境界づけられたコンテキスト 1境界づけられたコンテキスト 2ドメインイベント集約 1集約 2
© 2023, Amazon Web Services, Inc. or its affiliates.作成したモデルをコードに反映• 戦術的DDD§ ドメインモデルを実装に反映する§ モデルと実装は繰り返し改善する§ ドメインモデルがビジネスロジックに対する責務を持つ§ ドメインモデルとインフラストラクチャを分離する– 依存関係逆転の原則により、ドメイン層をシステム的な関⼼ごとから分離– ヘキサゴナル/オニオン/クリーンアーキテクチャ
© 2023, Amazon Web Services, Inc. or its affiliates.参考︓ヘキサゴナルアーキテクチャDomainModelPortsAdaptersPrimary Actor SecondaryActorHTTP RequestEvent MessageQueue…File StorageDatabaseQueue…
© 2023, Amazon Web Services, Inc. or its affiliates.参考︓ヘキサゴナルアーキテクチャDomainModelPortsAdaptersPrimary Actor SecondaryActorHTTP RequestEvent MessageQueue…File StorageDatabaseQueue…アプリケーションはポートによって接続されるアダプタは外界との糊の役⽬を果たすドメインモデルはビジネスロジックを実⾏し、モデルの外側についての知識を持たない
© 2023, Amazon Web Services, Inc. or its affiliates.参考︓ヘキサゴナルアーキテクチャのサンプルコード• ヘキサゴナルアーキテクチャを利⽤したLambda関数のドメインモデルの実装Live§ 動画︓ https://www.youtube.com/watch?v=whQ-P05QeDQ§ 資料︓ https://pages.awscloud.com/rs/112-TZM-766/images/DEV-09_LiveCoding_with_hexagonal_architecture.pdf• ヘキサゴナルアーキテクチャを利⽤した AWS Lambda のドメインモデルオブジェクトサンプルコードhttps://github.com/aws-samples/aws-lambda-domain-model-sample
© 2023, Amazon Web Services, Inc. or its affiliates.© 2023, Amazon Web Services, Inc. or its affiliates.まとめ
© 2023, Amazon Web Services, Inc. or its affiliates.まとめ• マイクロサービスは変化に素早く対応し、フィードバックを得て改善を重ねるビジネスにマッチしている• マイクロサービスにはトレードオフがあり、マイクロサービスに適した組織にする必要がある• マイクロサービスは機能や技術スタックによる分割ではなくドメインによる分割を⾏う• ドメイン分割はドメイン駆動設計を活⽤する• ドメインエキスパートと開発者によるEvent Stormingによって境界づけられたコンテキストとドメインモデルを定義し実装に反映する
fatsushi
sansantech
devops_vtj
ogugu9
yuhattor
n1ru4l
ahrkrak
sadonosake
nagix
oracle4engineer
matsuihidetoshi
shotatsuge
ddemaree
swwweet
kneath
aleyda
chriscoyier
dougneiner
holman
lauravandoore
tmm1
dotmariusz
tenderlove
shpigford