<style>
h1, h2, h3, h4, h5, h6 { text-transform: none !important }
h1 { font-size: 2.4em !important; color: #33B490 !important }
h2 { color: #33B490 !important }
h3 { color: #EC5D57 !important }
.no-margin { margin: 0 !important }
.small-text { font-size: 0.8em !important }
.ex-large-text { font-size: 4em !important }
.red { color: red }
li { margin-bottom: 0.5em }
</style>
# Microservices 回答抜粋
---
## 開発/運用体制
- DevOps
- コンウェイの法則
---
## 基盤
- CI/CD
- 障害発生を前提とした設計
- ログ/トレース機能
- サーバーやネットワークを含めたメトリクス監視
- タイムリーな障害検知と対応
---
## Cons
[MicroservicePremium](https://martinfowler.com/bliki/MicroservicePremium.html)
-> Next Page
---
![[productivity.png]]
---
## トランザクション管理
- ローカルトランザクションの利用を推奨
- グローバルトランザクション
- 2 フェーズコミット
---
## データベース間の同期
### Saga
- 補償トランザクション
- 各データベースの整合性が取れるには待ち時間が発生
- 「結果整合性」が許容できる場合に利用
- ドメインエキスパートを巻き込んで本当に必要とされる要件を洗い出す
---
## データの結合
### API Composition
- In-memory join
- パフォーマンスやスケーラビリティに懸念
---
![[ApiBasedQueryBigPicture.png]]
---
### CQRS & Event sourcing
#### Command Query Responsibility Segregation : CQRS
- データアクセス処理を更新系処理と参照系処理に二分
- （例）オーダー
- オーダーサービスによる更新系処理
- カスタマーサービスによる参照計処理
---
#### Event sourcing
- Event source
- 対象のビジネスにとってただ1つのデータストア
- Messaging Oriented Middleware : MOM
- 非同期メッセージング
---
![[QuerySideService.png]]
---
## サービス間連携
- REST
- Messaging
---
## 失敗事例からの学び
> サービス化は大きく始める
> モノリスファースト
---
## セッション永続化
### Sticky session
- ロードバランサ
- Kubernetes の Ingress も提供
### ステートのサービス化
- （例）ショッピングカート
---
## マイクロサービスパターン
- [What are microservices?](https://microservices.io)
- Chris Richardson
- [A pattern language for microservices](https://microservices.io/patterns/)
---
![[MicroservicePatternLanguage.jpg]]
---
## データベース配置パターン
### Database per service
- ローカルトランザクション
- Saga, API Composition, CQRS, Event sourcing
---
![[databaseperservice.png]]
---
### Shared database
- DB 設計変更の影響が大きくなる
- 悲観的ロック
- データ量増加に対してはデータベースサーバーのスケールアップでの対応
---
## データ同期パターン
### Saga
#### Choreography
- シンプル
- 各サービスの中にサービス関連系のフロー制御のロジックを組み込んでいる
- 全体の見通しが悪い
- トランザクション実行時の進捗確認やトレースがしにくい
- 関心事の分離を阻害
---
![[Create_Order_Saga.png]]
---
#### Orchestration
- Saga Orchestrator
- orchestrator がファットサービスにならないよう注意が必要
---
![[Create_Order_Saga_Orchestration.png]]
---
## トランザクショナルメッセージングパターン
### Transactional outbox
- outbox テーブル -> Message Relay -> Message Broker (MOM)
- Polling publisher
- Message Relay が outbox テーブルをポーリング
- outbox テーブルのメンテナンス
---
![[ReliablePublication.png]]
---
### Transaction log tailing
- DBMS のトランザクションログへのログエントリーを利用
- DBMS 依存
---
![[TransactionLogMining.png]]
---
## 外部 API パターン
### API Gateway
- ユースケースごと
- Order API Gateway など
- 非機能要件は API Gateway 製品を利用
---
![[apigateway.jpg]]
---
### Backend for Frontends : BFF
- クライアントごと
---
![[bffe.png]]
---
## 他の選択肢
### Modular Monoliths
- Shopify は Modular Monoliths に移行
- [Deconstructing the Monolith](https://shopify.engineering/deconstructing-monolith-designing-software-maximizes-developer-productivity)
- 特徴
- デプロイ単位が一つのアプリケーション
- ある機能（コンテキスト）単位でモジュールの境界を分ける
- 越境するにはお互いの公開APIを介する（ことで依存関係を明らかにする）
---
- メリット
- モノリスとマイクロサービスのデメリットを軽減
- 将来的にマイクロサービス化することが比較的簡単
- デメリット
- 境界を適切に維持し続けるコストがかかる
- 容易に境界違反できてしまう
---
![[MonolithvsMicroservicesbySimonBrown.jpg]]
---
## Wrap up
- 初期段階からマイクロサービスを採用するのはお勧めしません
- マスタデータの参照を切り出すだけであれば取り組みやすいと思います
- 普通に参照系 API を作るイメージ
- 更新系 API もローカルトランザクションで解決するのであれば切り出しやすいと言えます
- 将来的なマイクロサービス化に向けてモジュール間の境界を適切に設計することにコストをかけると良さそうです
---
- マイクロサービスと組織構造は切り離せない関係です
- マイクロサービスを採用せずとも DevOps を進めることにはメリットがあります