AWSにおけるマイクロサービスとNoSQLの活用 /microservice architecture with NoSQL on AWS

AWSにおけるマイクロサービスとNOSQLの活⽤ © 2023, Amazon Web Services, Inc. or its affiliates.
© 2023, Amazon Web Services, Inc. or its affiliates. Atsushi Fukui Senior Solutions Architect Developer Specialist - DevAx Amazon Web Services Japan AWSにおけるマイクロサービスと NoSQLの活⽤ D E V E L O P E R X N O S Q L N I G H T

⾃⼰紹介 v名前 v福井厚（ふくいあつし）twitter: afukui@ v所属 vアマゾンウェブサービスジャパン合同会社 vシニアソリューションアーキテクト vDeveloperスペシャリスト - DevAx v関⼼領域 vソフトウェアアーキテクチャ、オブジェクト指向設計、アジャイル開発 v好きなAWSサービス vサーバーレステクノロジー全般、 AWS Code シリーズ

セッションを始める前に • このセッションはマイクロサービスを推奨するものではありません • 他のすべてのアーキテクチャと同様に、マイクロサービスも選択肢のひとつであり、メリット、デメリットがあります • マイクロサービスアーキテクチャもシステムの⽬的と要件を踏まえた上で、ひとつの選択肢としてお考えください

Agenda • マイクロサービスとは • なぜマイクロサービスアーキテクチャを採⽤するのか • マイクロサービスのアンチパターン • どうやってサービスを分割するのか • Amazon DynamoDBの活⽤ • まとめ

マイクロサービスとは • ビジネスドメインに基づいて分割された、独⽴してデプロイ可能なサービス映画情報サービス料⾦サービス通知サービス予約サービス発送サービス課⾦サービス料⾦情報の問い合わせ上映⽇イベント予約情報問い合わせ

マイクロサービスの重要な概念『マイクロサービスアーキテクチャ第2班』オライリー・ジャパン、2022

マイクロサービスの性質疎結合で、独⽴性が⾼い • 独⽴してデプロイ可能 • つまり各サービスが疎結合 • ビジネスモデルの境界に沿って分割 • Web 三層 ⇔ ドメインモデル • 技術的な境界に沿って分割しない • 変更要求に対し、複数のサービスを横断してデプロイすることになる • 各サービスが⾃⾝でデータを所有する • データベースを共有しない • データはWeb APIやイベントなどで受け渡す『マイクロサービスアーキテクチャ第2班』オライリー・ジャパン、2022

『』 “…innovation is now recognized as the single most important ingredient in any modern economy…” イノベーションこそが近代経済において最も重要な要素と考えられている。競合よりも早く、新しい波を創っていくことが重要

イノベーションがビジネスを進化させる新たなマーケット新たな顧客価値 New economics 新たなデジタル製品とサービス

Listen Idea Experiment Innovation Flywheel 実験がイノベーションを加速する

マイクロサービスに変更する理由アジリティ各機能を他の機能のリリースを調整せずにリリースできるようになるチームの⾃律性チームの規模が⼩さくなることでコミュニケーションコストが減る⾃⾝のサービスを完全にコントロールでき、⾃律的⾃発的な機能改善に繋がるスケーリング負荷が⾼い機能のみをスケーリングすることができる堅牢性負荷が⾼まったとき、リリースによる障害などの影響が単⼀のサービスにとどまり、アプリケーション全体としての堅牢性が⾼まる採⽤技術の柔軟性各サービス毎に異なる⾔語やアーキテクチャ(VM/コンテナ/サーバーレス/etc)を採⽤できる

マイクロサービスのトレードオフ分散システムに伴う複雑性ネットワーク呼出による連携となり、モノリシックシステムでメソッドを呼び出すときには発⽣しなかった考慮点が発⽣するネットワークのエラーや遅延、呼出先のダウン、障害発⽣時のトラブルシューティングなど整合性の担保モノリシックなシステムではトランザクションで容易に強⼒な整合性を担保できるマイクロサービスで同様の整合性は担保できないマイクロサービスの統廃合やリファクタリングが困難モノリスではIDEの機能で⾃動的にインターフェースやクラスの分割、抽出、統合が可能で、データスキーマも整理可能マイクロサービスでは、そのような統廃合は複数のサービスチームの調整やデータの移管が必要

トレードオフの対策分散システムに伴う複雑性⾮同期なイベント駆動で連携したり、同期API呼出の場合はサービスメッシュを利⽤する整合性の担保整合性が必要な単位でマイクロサービスを分割しないどこで整合性が必要なのか、ビジネスのモデリングが必要サーガパターンなど、結果整合性を担保するデザインパターンを利⽤するマイクロサービスの統廃合やリファクタリングが困難統廃合がなるべく発⽣しないよう、ビジネスのモデリングが必要

チーム内に意思決定する権限がない • ビジネス的な価値を提供するために、どの機能を優先的にリリースするかをチームで決定できない • ユーザーからのフィードバックを受けて何をどのように改善するかを決定できない • チームが⾃律的に⾏動できる組織になっていない

開発メンバーの数がサービスより少ない • 開発者3⼈で20以上のマイクロサービスを開発しているなど • 開発者がボトルネックとなってリリースや改善の頻度が低下

バックエンドのデータベースを各サービスで共有 • マイクロサービスではない • 密結合になっておりマイクロサービスのメリットが活かせない

サービス単位ではなく機能単位のチーム構成している • UI、アプリケーション、データベースなど機能単位にチームが分かれている「マイクロサービスアーキテクチャ第2版」オライリージャパン 2022

ドメインをまたがって密結合になっている • ビジネスドメインの境界に従ってサービスが分割されていない • 境界づけられたコンテキスト間はドメインイベントで疎結合にする • 分散システムでは、⾮同期、結果整合を許容する必要がある

明確な⽬的もなくマイクロサービスを選択している • 銀の弾丸ではない • 「流⾏っているから」「新しい⼿法だから」という理由でマイクロサービスアーキテクチャを選択しない • マイクロサービスのもたらす価値と複雑性のトレードオフを考慮

ドメイン駆動設計 (DDD) とは • ⾼品質なソフトウェアモデルを設計するためのソフトウェア開発⼿法 • ユビキタス⾔語ービジネスドメインエキスパートと開発者の間の意思疎通として利⽤される⽤語によってモデリングと設計を⾏う • 戦略的な設計のためのガイドラインー境界づけられたコンテキスト、蒸留、⼤規模な構造の考察 • 戦術的な設計 – 集約、エンティティ、値オブジェクト、ドメインサービス「エリック・エヴァンスのドメイン駆動設計」：エリック・エバンス著 2011/4/9 翔泳社「実践ドメイン駆動設計」：ヴォーン・ヴァーノン著 2015/3/16 翔泳社

戦略的設計 • 境界づけられたコンテキスト • コンテキストマップ • ⼤規模な構造 26

境界づけられたコンテキスト • 境界づけられたコンテキストは特定の • モデルを適⽤できる限定された範囲。 • コンテキストの境界を定めることで、 • チームメンバーは何を⼀致させるべきで何を独⽴して開発できるのかについての理解を明確化し、共有できる。 https://www.martinfowler.com/bliki/BoundedContext.html Customer Ticket Product Product version Customer Product Territory Opportunity Pipeline Salesperson Defect Sales context Support context

コンテキストマップ Sales context Support context Marketing context 境界つけられたコンテキストだけでは、ドメインの全体像を⽰すことはできない。コンテキストマップは、境界づけられたコンテキストを統合することにより、異なるが関連するユビキタス⾔語のマッピングを処理する。 DDDでは境界づけられたコンテキストを統合するための７つのパターンを説明 • 共有カーネル (Shared Kernel) • 顧客/供給者の開発チーム (Customer/Supplier Development Teams) • 順応者 (Conformist) • 腐敗防⽌層 (Anticorruption layer) • 別々の道 (Separate ways) • 公開ホストサービス (Open/Host service) • 公表された⾔語 (Published language)

戦術的設計 • 集約、値オブジェクト、エンティティー • ドメインイベント 29

モデル駆動設計を構成する⾔語のナビゲーションマップモデル駆動設計サービスエンティティ値オブジェクトファクトリ集約リポジトリ利⼝なUI モデルを表現するのに使⽤するモデルを表現するのに使⽤するモデルを表現するのに使⽤する排他的な選択アクセスするのに使⽤する整合性を保つのに使⽤するアクセスするのに使⽤するルートとして機能するカプセル化するのに使⽤するカプセル化するのに使⽤するカプセル化するのに使⽤するカプセル化するのに使⽤するレイヤ化アーキテクチャドメインを隔離するのに使⽤する

例 – オークションの集約 31 オークション競売参加者オークション品 1 * 1 ⽀払い⽅法配送⽅法 * 1 1 1 集約ルート在庫 1 1 競売⼈ 1 1 *

境界づけられたコンテキストとドメインモデル在庫オークション支払い台車ピッカー配送サービス倉庫商品棚位置サイズ重さ配送顧客配送先入札落札商品 SKU 画像価格入札顧客 ID 検索サービス落札顧客クレジットカード支払い

データソースをサービスの所有ごとに分割⽀払いオークション在庫共有されているモノリシックデータベースモノリシックシステム⽀払いオークション在庫商品や顧客などもサービスによって利⽤する属性が異なるので、それぞれのサービスの所有するデータへ移⾏する。データソースの移⾏計画も検討。顧客マスタ配送顧客⼊札顧客⽀払顧客

マイクロサービスでデータソースに対して考慮すべき点 • サービスごとにデータソースを所有するコスト • ⼀部のサービスにリクエストが集中した場合のデータソースへの負荷 • サービスの特性に応じたデータソースの選択 § ポリグロットパーシスタンス

Amazon SQS メッセージ 2000件 Amazon RDS MySQL (max_conn = 100) AWS Lambda 従来の RDB コネクション

︙ 従来の RDB コネクション Amazon SQS メッセージ 2000件 Amazon RDS MySQL (max_conn = 100) AWS Lambda

︙ 従来の RDB コネクション Amazon SQS メッセージ 2000件 AWS Lambda Amazon RDS MySQL (max_conn = 100)

Amazon RDS Proxy セキュリティの向上シームレスなフェイルオーバーコネクションプール

︙ RDS Proxy RDS Proxy を使った DB コネクション Amazon SQS メッセージ 2000件 AWS Lambda Amazon RDS MySQL (max_conn = 100)

︙ Amazon DynamoDBを使⽤ Amazon SQS メッセージ 2000件 AWS Lambda

⼀般的なデータモデルとユースケースリレーショナル参照整合性、 ACID トランザクション、スキーマオンライトリフト・アンド・シフト、ERP、 CRM、ファイナンスキーバリュー⾼スループット、低レイテンシーの読み取り/書き込み、スケーラビリティリアルタイム⼊札、ショッピングカート、ソーシャル、製品カタログ、お気に⼊りドキュメントドキュメントを保存し、あらゆる属性のクエリにすばやくアクセスコンテンツ管理、パーソナライズ、モバイルインメモリミリ秒のレイテンシでのキーによるクエリリーダーボード、リアルタイム分析、キャッシンググラフ各データの関連性の素早く簡単な⽣成とその間の移動不正検出、ソーシャルネットワーキング、レコメンデーションエンジン時系列時間的に連続したデータの収集、保存、処理 IoT アプリ、イベント追跡元帳アプリケーションデータに対するすべての変更の完全で不変で検証可能な履歴システム記録、サプライチェーン、ヘルスケア、登録、ファイナンス⼀般的な使⽤事例データモデルワイドカラムスケーラブル、⾼可⽤性、マネージド Apache Cassandra ̶ 互換サービス低レイテンシーのアプリを構築し、オープンソースを活⽤し、 Cassandra をクラウドに移⾏する Amazon Aurora Amazon RDS Amazon DynamoDB Amazon documentDB Amazon Timestream Amazon Neptune Amazon ElastiCach e Amazon QLDB Amazon キースペース (Apache カサンドラ⽤) Redis ⽤ Amazon MemoryD B

Amazon DynamoDB SQL-ストレージに最適化 NoSQL-コンピューティングに最適化正規化/リレーショナル⾮正規化/階層アドホッククエリインスタンス化されたビュー垂直⽅向にスケール⽔平⽅向にスケール OLAPに適している⼤規模な OLTP* 向けに構築 (*) DynamoDBについて。分析ワークロード⽤の NoSQL データベースも⼀部ある

本⽇は時間の関係で割愛。以下のセッションを参照 https://www.youtube.com/watch?v=DIQVJqiSUkE Alex DeBrieさんの re:Invent 2019のセッションがとても分かりやすいのでぜひこちらをご覧ください。

DynamoDB ̶ 追加機能 • Auto Scaling ̶ 予想によるプロビジョニングが不要に • オンデマンドキャパシティ ̶ リクエストに合わせてDDBの料⾦を⽀払うことができ、事前のキャパシティ計画が不要 • TTL ̶ 有効期限による⾃動削除 • アダプティブキャパシティ ̶ 不均質なアクセスに⾃動的に対応 • DAX ̶ DynamoDB アクセラレータ

DynamoDB ローカル ̶ 開発者向け • ネットワーク接続や AWS へのアクセスは不要 • 完全な DynamoDB API をサポートするクライアント側データベース • 実⾏可能な Java アーカイブ (JAR) ファイルとして利⽤可能 • Windows、Mac、および Linux システムのサポート AWS.config.dynamodb ={ endpoint: config.debug.dynamoDBLocalEndpoint, region: config.region };

Lambda 関数から変更したレコードへアクセス DynamoDB Streamsと AWS Lambda Invocation role ユーザーアプリテーブルデータストリーム Execution role DynamoDB

Lambda 関数他のシステムへの変更通知テーブルの更新 Amazon OpenSearch Service Amazon ElastiCache DynamoDB Streams トリガー

パーティション 1 1000 WCU ⼈気のある候補 A ⼈気のある候補 B 50,000/ 秒 200,000 WCU のプロビジョニングキーは「ホット」になり、パーティションで使⽤可能な WCU を使い切る 70,000/ 秒「Votes」テーブルリアルタイム投票の例パーティション K 1000 WCU パーティション M 1000 WCU パーティション N 1000 WCU 有権者 200⼈の候補に投票する

Adaptive Capacityの利⽤

Candidate A_2 Candidate B_1 Candidate B_2 Candidate B_3 Candidate B_5 Candidate B_4 Candidate B_7 Candidate B_6 Candidate A_1 Candidate A_3 Candidate A_4 Candidate A_7 Candidate B_8 Candidate A_6 Candidate A_8 Candidate A_5 任意の ID （ただし決定論的）をパーティションキーに追加して、書き込みをシャード UpdateItem:「CandidateA_」+rand(0, 10) 投票に 1 を追加書き込みシャーディング有権者「Votes」テーブル

Candidate A_2 Candidate B_1 Candidate B_2 Candidate B_3 Candidate B_5 Candidate B_4 Candidate B_7 Candidate B_6 Candidate A_1 Candidate A_3 Candidate A_4 Candidate A_5 Candidate A_6 Candidate A_8 Candidate A_7 Candidate B_8 定期的なプロセス候補 A 合計 :2,500M 1.Sum 2.保存集計結果を読み取る「Scatter&Gather」有権者「Votes」テーブル

製品 A 製品 B 70,000/ 秒⼈気商品による不均等なアクセスパターン製品カタログ - ⼈気商品 Shoppers ProductCatalog テーブルパーティション 1 2000 WCU パーティション K 2000 WCU パーティション M 2000 WCU パーティション N 2000 WCU

人気商品による不均等なアクセスパターン

フルマネージド、⾼可⽤性、インメモリキャッシュ Java, .NET, Python, Go & Javascript をサポートクラスターベース、マルチ AZ クエリとアイテムのキャッシュを分離 DynamoDB Accelerator (DAX)

従来のサイドキャッシュとの⽐較キャッシュアプリ

従来のサイドキャッシュとの⽐較 DynamoDB Accelerator (DAX) アプリキャッシュアプリ

⾼いキャッシュヒット率

まとめ • マイクロサービスは変化に素早く対応し、フィードバックを得て改善を重ねるビジネスにマッチしている • マイクロサービスにはトレードオフがあり、マイクロサービスに適した組織にする必要がある • マイクロサービスは機能や技術スタックによる分割ではなくドメインによる分割を⾏う • マイクロサービスではデータソースの選択もポイントのひとつ • Amazon DynamoDBを活⽤するためにはRDBMSの概念を捨てることも必要

マイクロサービスの組織とチームビルディング • ⾃律的で意思決定する権限と責任を持つチーム • 開発したチームが運⽤も⾏う（You build it, you run it） • Two Pizza Team • すべてを所有

参考︓チームトポロジーストリームアラインドチームストリームアラインドチームストリームアラインドチーム共有サービスプラットフォームチーム内部プラットフォームチーム ][ セキュリティコミュニティ・オブ・プラクティス(CoP) プラットフォーム + ツール )( )( フィールドチーム (サポート、ソリューションアーキテクト、営業) O 製品機能のリクエストストリームアラインドチームビジネスに沿った⽬標を持つチームイネーブリングチームストリームアラインドチームが障害を克服するのを⽀援。コンプリケイテッド・サブシステムチーム専⾨性が必要な機能を担当する専⾨スキルを持つチームコラボレーションファシリテーション O )( フェデレーションサービス (X-as-a-Service) ][ データサイエンスチームサービスとしてのプラットフォームキー: )( )( ][ * マシュー・スケルトン,マニュエル・パイス. チームトポロジー価値あるソフトウェアをすばやく届ける適応型組織設計 (Japanese Edition). Kindle Edition.

1994-2001 2002+ モノリシックアーキテクチャ + 階層化組織サービスの分割 + Two-pizzaチーム 1000+マイクロサービス 100+ purpose-built databases Amazonにおけるデプロイメント変遷︓2001-2002

コンポーネントの分割 • 原則 • 可能な限り⼩さなユニットにする（プリミティブ） • データドメインの作成 • 関数単位ではなくスケールファクタによる分割 • 個々のサービスは独⽴して運⽤組織間の連携による待ち時間の発⽣を抑える • サービス間はAPI（契約）で連携これにより組織の変更が導かれました

組織の再編成の開始 “Two-pizza” teams • サービスを所有 • 制約を最⼩化（コンウェイの法則） • 意思決定のための⾃⽴した組織

組織の再編成の開始ひとつのチームでどうやって実⾏するのか? すべてを所有 • 計画 • セキュリティ • パフォーマンス • スケーラビリティ • デプロイメント • 運⽤ • バグ • ⽂書化 • テスト…

77 専任のシングルスレッド化されたチームでフローを最適化専任の商品担当チーム商品開発商品化商品マネージャープロジェクトマネージャー開発者テスト担当者インフラ担当者運営とサポート商品チーム B 商品チーム A 商品チーム C バックログ A • ストーリー 1 • ストーリー 2 • ストーリー 3 • ストーリー 4 バックログ A • ストーリー 1 • ストーリー 2 • ストーリー 3 • ストーリー 4 バックログ A • ストーリー 1 • ストーリー 2 • ストーリー 3 • ストーリー 4

スクラムロール例スクラムマスター、開発者、プロダクトオーナーチームにアジャイルな⽅法論を適⽤スクラムボード例

組織内の “サイロ” 化が勢いを無くす要因オペレーションデータベースチーム品質保証アプリケーションセキュリティソフトウェア開発チーム “開発環境のセットアップを待機するため作業を中断" “新しいテーブルや SQL スクリプトを待機するため作業を中断" “パフォーマンステストを待機するために作業を中断" “ ソースコードの⼿動検査を待機するため作業を中断 " “データベースセキュリティの承認待機するため作業を中断" “セキュリティテストの完了を待機するため作業を中断" “セキュリティ証明書の作成を待機するため作業を中断" “データベースホストのセットアップを待機するため作業を中断" “新しいテストのホストを待機するために作業を中断 ”

マイクロサービスはDevOpsのスタイルで運⽤すべきオペレーションデータベース管理者品質保証 (テスト担当者) アプリケーションセキュリティソフトウェア開発チーム “共働"

作成したモデルをコードに反映 • 戦術的DDD § ドメインモデルを実装に反映する § モデルと実装は繰り返し改善する § ドメインモデルがビジネスロジックに対する責務を持つ § ドメインモデルとインフラストラクチャを分離する – 依存関係逆転の原則により、ドメイン層をシステム的な関⼼ごとから分離 – ヘキサゴナル/オニオン/クリーンアーキテクチャ

参考︓ヘキサゴナルアーキテクチャ Domain Model Ports Adapters Primary Actor Secondary Actor HTTP Request Event Message Queue … File Storage Database Queue …

参考︓ヘキサゴナルアーキテクチャ Domain Model Ports Adapters Primary Actor Secondary Actor HTTP Request Event Message Queue … File Storage Database Queue … アプリケーションはポートによって接続されるアダプタは外界との糊の役⽬を果たすドメインモデルはビジネスロジックを実⾏し、モデルの外側についての知識を持たない

参考︓ヘキサゴナルアーキテクチャのサンプルコード • ヘキサゴナルアーキテクチャを利⽤した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

AWSにおけるマイクロサービスとNoSQLの活用 /microservice architecture with NoSQL on AWS

AWSにおけるマイクロサービスとNoSQLの活用 /microservice architecture with NoSQL on AWS

More Decks by Atsushi Fukui

Other Decks in Technology

Featured

Transcript