microservice

service を通じた component 化

business 遂行能力に關はり組織が整理されること

project ではなく product

賢い (smart) endpoint と土管

分散統治

分散 data 管理

infra 自動化

障礙のための設計

進化的な設計

SOA (service oriented architecture)

1)この時點より、全てのチームはサービスインターフェースを通じて全てのデータと機能を公開すること。

2)各チームは各々そのインターフェースを通じて通信しなければならない。

3)その他の全てのプロセス閒通信は許可されない。ダイレクトリンク、他のチームのデータソースから直接データを讀むこと、メモリ共有モデル、バックドア、全てを禁じる。ネットワーク越しのサービスインターフェースを經由した通信だけが許可される。

4)使用する技術は問はない。 HTTP 、 Corba 、 Pubsub 、 カスタムプロトコル、何でも良い。 Bezos は氣にしない。

5)全てのサービスインターフェースは、例外なく、外部に公開可能なようにゼロから設計されなければならない。すなわち、チームは全世界のデベロッパに向けてインターフェースを公開することができるよう、設計し、計畫しなければならない。例外は無い。

6)さうしない者は解雇される。

呼び出す先の service は信用出來ない

zeto-trust

認證

health check

validation

circuit braker

service discovery

呼び出す元の service は信用出來ない

zero-trust

認證

認可

throttle

API limit rate

message queue

circuit braker

back pressure

Context and problem - Solution - Issues and considerations - When to use this pattern - Related guidance

Pattern Name/Summary - Solving Issues - Explanation of pattern / Resolution in the cloud - Implementation - Structure - Benefits - Notes - Other

Context - Problem - Forces - Solution - Example - Resulting context - Related patterns

Application architecture patterns

Which architecture should you choose for an application?

architect an application as a single deployable unit

application 全體を一度に deploy 出來る纏まりとして作る。開發・deploy・scaling が簡單。application の code base が大きく成ると module 境界が壞れがちで、開發 team を scale するのが難しい。IDE の速度が落ち、application 起動も遲く成る。deploy や scaling の單位も分離出來ず問題が複雜に成ってゆく。architecture を進化的に更新するのも難しい

モジュールモノリス (Module Monolith) では，システムの全コードが單一のコードベース上にあって，ひとつのアーティファクトとしてコンパイル，デプロイされる。コード自體は凝縮性と分離性を備えた適切な構造であるかも知れないが，それでも單一のモジュールであることに違いはない。

アロケーションモノリス (Allocation Monolith) では，すべてのコードが同時にデプロイされる。コード全體が一度にコンパイルされて單一のアーティファクトになる場合と，いくつかのアーティファクトが得られる場合があるが，ひとつのバージョンがべてのノードにデプロイされて，同じバージョンが動作するという點は共通だ。

ランタイムモノリス (Runtime Monolith) は，ひとつのアプリケーションあるいはプロセスがシステムとして動作するという，一般的なシステム構築方法である。主體となる單一のコンポーネントがデプロイされるという意味で，アロケーションモノリスを連想させる部分も多いが，ひとつ異なるのは，新しいバージョンがリージョンにロールアウトされた結果，複數のバージョンが竝行動作する狀態になる點だ。

architect an application as a collection of loosely coupled, services

軸

x : scale out

z : 同じ application を deploy するが、deploy する server 每に異なる役割を擔はせる

scale up どこ行った? まぁ「複數の server に分割する場合の」と云ふ前提附きか

水平分割 : 關係の行を分ける

sharding

partitioning

垂直分割 : 關係の列を分ける

列を別の表へ移す

表を別の DB へ移す

Decomposition

How to decompose an application into services?

application を service に分割する方法は?

Decompose by business capability

define services corresponding to business capabilities

business capability に基づいて application を service に分割する。或る business rule を變更した時に一つの service のみを變更すれば好い樣に努める。各 team は特定の明確な business 上の價値を提供する爲に開發・運用する。business が充分に安定してゐ、仕事を可視化する等し、business を構造化する或いは architecture に business process も合はせる必要が有る

Decompose by subdomain

define services corresponding to DDD subdomains

DDD (domain driven design; domain 驅動設計) の subdomain に基づいて application を service に分割する

Self-contained Service

design services to handle synchronous requests without waiting for other services to respond

Service per team

service と team が一對一に對應する樣 application を service に分割する。team は 5〜9 人に留め、code や運用の複雜さは team の認知能力を超えてはいけない。team や service が疎結合に成り保守性等 (-ility (〜性)) が上がるが、service を跨る變更には team 閒の調整が必要に成る。又、各 team が end user 向けの機能に對應するとは限らない

-ility

Refactoring to microservices

service を migration する pattern も網羅しておきたいね

Strangler Application

Anti-corruption layer

Data management

How to maintain data consistency and implement queries?

data の一貫性を保ち、問ひ合はせるには?

Database per Service

each service has its own private database

各 service は他 service が CRUD しない獨自の DB を持つ。DB instance を分ける必要は必ずしも無く、表を分ける事が必要條件であり、access 制御を導入し CRUD 元を制限するのが好い。service は疎結合に成る。分散 DB の困難と向き合ふ必要が有る

private-tables-per-service

schema-per-service

database-server-per-service

Shared database

services share a database

DB を複數の service で共有する。DB 製品の ACID transaction を利用出來る。複數の開發 team が同じ表に依存するので team 閒で調整する必要が有る。また或る service の動作が他の service の障礙に成り得る

Saga

use sagas, which a sequences of local transactions, to maintain data consistency across services

service 閒で data の一貫性を保つ爲に、service に閉じた transaction 同士 service 閒でを直列化する。分散 DB の transaction を實裝する手法である。複數の service 閒を變更 event を傳播させてゆき、拒否 event は逆に傳播させる。saga には ACID の內で獨立性 (isolation) を除いた ACD 特性が有る。獨立性が無い爲、transaction が可換に成る樣に工夫するとこの制限は緩和される

choreography (振り附け) based saga

each local transaction publishes domain events that trigger local transactions in other services

狀態機械を DB 上に實裝する必要が有る

orchestration based saga

an orchestrator (object) tells the participants what local transactions to execute

saga 內の 2 service 閒の或る transaction を管理する orchestrator を設置する。orchestrator は槪念的には transaction 每に設置される。orchestrator が兩 service 內での transaction を發行し、transaction の狀態を管理する

同期的な實裝も可能

message broker を使ふ場合、該當する orchestrator が返答 message を受け取れる樣にしなければならない

他の手法

TCC (try-confirm / cancel)

a.k.a. 2 phase commit

3 phase commit

read replica

cache

API Composition

implement queries by invoking the services that own the data and performing an in-memory join

他の service に問ひ合はせ、結果を結合する

DB の JOIN が使へないので全て問ひ合はせる。簡單。DB の index を使へないので最適化を行ひづらい

BFF (backend for frontend) もこれ

implement queries by maintaining one or more materialized views that can be efficiently queried

效率的に問ひ合はせられる matirialized view を作る

「CQRS」って語は Bertrand Meyer の CQS (command query separation) が由來の command と query を分離する事に眼目が有るんであってな (CQRS が何の略か見て)。「materialized view」とか名乘って欲しい

多層 CQRS。UI の狀態層、DB への永續化層、みたいな

Domain event

publish an event whenever data changes

data が變更される度に event を發行する

persist aggregates as a sequence of events

event 列を永續化する

Transactional messaging

How to publish messages as part of a database transaction?

DB の transaction 內で event を發行するには?

Transactional outbox

a.k.a. application event

履歷 table (outbox table) を通常の RDB transaction の中で更新し、履歷 table を元に event を發行する。at least once / at most once の考慮を自分で行ふ必要が有る。event を冪等にすると問題は軽減される

Transaction log tailing

Polling publisher

履歷 table (outbox table) を polling して event を發行する。順序を保證するのが難しい。DB 製品に依存し辛い

Testing

How to make testing easier?

test を簡單にやるには?

service と service 閒とを分離する

Consumer-driven contract test

a test suite for a service that is written by the developers of another service that consumes it

その service を使ふ、他の service の開發者が書いた test を實行する

client 開發 team が test を書いて、service 開發 team が test を實行する

複數の service を起動する E2E test を維持するのは難しい

利用者側が test を書く

Client-side contract Test

a test suite for a service client (e.g. another service) that verifies that it can communicate with the service

service の client (例へば他の service) に對して test を用意する。client が service と遣り取り出來るか test する

service 開發 team が test を書いて、client 開發 team が test を實行する

Service component test

a test suite that tests a service in isolation using test doubles for any services that it invokes

外部 service の test double を作って、service 單體で test を行ふ

他の service に test で直接 request するのではなく、test double に對して request する

Deployment patterns

How to deploy an application’s services?

application の各 service を deploy するには?

API ver. をだうやって上げるかとか canary、feature toggle、Blue / Green とかの話ぢゃないのかよ

Multiple service instances per host

deploy multiple service instances on a single host

一つの host に複數の service を deploy する

server resource を效率的に使へる

通信最適化

Service instance per host

deploy each service instance in its own host

service 每に host を用意してその host に deploy する

分離

Service instance per VM

deploy each service instance in its VM

service 每に VM を用意して deploy する

VM を境界として infra 側へ操作 API を提供

變はりづらい部分は VM image (AMI (Amazon Machine Image) 等) に燒き、application 部分は S3 から落とす等の工夫

Service instance per Container

deploy each service instance in its container

service をそれぞれ container (大抵は OCI (Open Container Initiative) container) に入れて deploy する

resource の面で困る事いっぱい有るよね

Single-container management patterns

Single-node, multi-container application patterns

Sidecar pattern

Ambassador pattern

Adapter pattern

Multi-node application patterns

Leader election pattern

Work queue pattern

Scatter / gather pattern

Serverless deployment

deploy a service using serverless deployment platform

長時閒の server resource に對してではなく、短時閒の利用每に課金する

制約と誓約

Service deployment platform

deploy services using a highly automated deployment platform that provides a service abstraction

server を抽象化して「service」として提供する、高度に自動化され抽象化された deploy platform に deploy する

PaaS (Platform as a Service)

Cross cutting concerns

How to handle cross cutting concerns?

橫斷的關心事

設定の注入

metric

分散 tracing

logging

監視

service discovery

a framework that handles cross-cutting concerns and simplifies the development of services

Externalized configuration

externalize all configuration such as database location and credentials

DB の接續先や credential 等の設定を外部化する

Service Template

a template that implements standard cross cutting concerns and is intended to be copied by a developer in order to quickly start developing a new service

Communication patterns

Style

Which communication mechanisms do services use to communicate with each other and their external clients?

service 同士や client との閒で通信するのにだう云ふ機構を使ふか?

use an RPI-based protocol for inter-service communication

service 閒の通信に RPC protocol を使ふ

實裝も管理も簡單。通常は同期的。雙方の service が通信時に生きてゐる必要が有り、可用性に課題が有る

Messaging

use asynchronous messaging for inter-service communication

service 閒通信に非同期 messaging を使ふ

疎結合、可用性に問題が出づらい。publish が出來る。message broker を管理しなければならない

非同期通信

request / response : 同期通信

notifications : 送信する丈

request / asuncronous response : 非同期に返答を受信する

publish / subscribe : 複數の相手に送信する

publish / asyncronous response : 複數の相手に送信し、非同期に返答を受信する

Domain-specific protocol

use a domain-specific protocol

例

SMTP、IMAP

RTMP、HLS、HDS

Idempotent Consumer

ensure that message consumers can cope with being invoked multiple times with the same message

消費者 (consumer) に同じ message が複數囘送られてきても、冪等に振る舞ふ樣にする

一意な ID を message に着けて、重複を檢出する

External API

How do external clients communicate with the services?

外部の client と service が通信するには?

API gateway

a service that provides each client with unified interface to services

背後の service に統一された interface で通信する gateway

client と個々の service が直接通信するのではなく、閒で gateway が受ける。client は gateway と丈通信すれば濟む。背後の service は client との通信 protocol や通信環境に引き摺られない。client は背後の service の狀態を知る必要が無い。client に最適な形の API を提供出來る

API gateway を管理するのは複雜

a separate API gateway for each kind of client

client の種類每に API gateway を用意する

Service discovery

How does the client of an RPI-based service discover the network location of a service instance?

RPI client は呼び出し先の service が network のどこに有るかをだう見附けるか?

Client-side discovery

client queries a service registry to discover the locations of service instances

全ての service の接續先を知ってゐる service registory に client が問ひ合はせ、通信する。client 側で load balance する

Server-side discovery と比べると network hop が少ない。service registory が必要

Server-side discovery

router queries a service registry to discover the locations of service instances

呼び出される server の前に LB (load balancer) を置く。LB は service registory から server の位置を割り出し lead balance する

Service registry

a database of service instance locations

service の server の位置を知る DB (database)

service registory は高負荷に成り易いので client 側で cache する等

service registory を高可用に運用するのは難しい

service registory の network 中の位置は既知である必要が有る

Self registration

service instance registers itself with the service registry

service の server 自身が service registory に登錄する

server は自分が service を提供出來る事を定期的に service registory を更新する。一定時閒以上更新が無ければ service registory は expire する

service 自身が把握する肌理細やかな狀態を登錄出來る

service を提供出來ない狀態に成った server は service registory も更新出來なく成ってゐる事が多い。外から觀測した狀態を考慮し忘れる事も多い

3rd party registration

a 3rd party registers a service instance with the service registry

health check を驅使する

Reliability

How to prevent a network or service failure from cascading to other services?

network や或る service の障礙が他の service は波及しない樣にするには?

Circuit Breaker

invoke a remote service via a proxy that fails immediately when the failure rate of the remote call exceeds a threshold

service の request への失敗率や應答時閒が一定以上上昇すると速やかに通信を失敗させる proxy を通す

障礙が收まったら徐々に request を通す

誤檢知〜。好い閾値を見附けるのは難しい

client が request に失敗したら指數函數的に次の request を遲らせる (exponention backoff) のも仲閒かな。TCP の輻輳制御とかも

Security

How to communicate the identity of the requestor to the services that handle the request?

zero trust

Access Token

a token that securely stores information about user that is exchanged between services

service 閒の通信で user 情報を安全 (CIA : 機密性、完全性、可用性) に格納した token を request に乘せて受け渡す

これしか載ってないの明らかにおかしいでしょ

How to understand the behavior of an application and troubleshoot problems?

application の擧動を理解して障礙を解決するには?

Log aggregation

aggregate application logs

application の log を集約する

Application metrics

instrument a service’s code to gather statistics about operations

application の metrics を集める

push / pull

Audit logging

record user activity in a database

user の行動 (customer support、compliance、security の爲) を DB に記錄する

SecDevOps、security shift left

Google Analytics

Distributed tracing

instrument services with code that assigns each external request an unique identifier that is passed between services. Record information (e.g. start time, end time) about the work (e.g. service requests) performed when handling the external request in a centralized service

外からの request に一意な ID を附け service 閒で ID を引き繼ぐ。各 service 每に處理の開始時刻、終了時刻等を記錄し集約する

Exception tracking

report all exceptions to a centralized exception tracking service that aggregates and tracks exceptions and notifies developers.

例外 (error) を、error を集約し通知して吳󠄀れる service に通知する

Sentry

Health check API

service API (e.g. HTTP endpoint) that returns the health of the service and is intended to be pinged, for example, by a monitoring service

監視 service 等から叩く、service が正常に動いてゐるかを確認出來る口 (HTTP endpoint 等) を用意する

readiness / liveness

Log deployments and changes

application の變更や deploy を記錄する

UI patterns

How to implement a UI screen or page that displays data from multiple services?

複數の service から集めた data を UI 上にだう表示するか?

micro frontend

Server-side page fragment composition

build a webpage on the server by composing HTML fragments generated by multiple, business capability/subdomain-specific web application

複數の business 機能や sub-domain に分散した service から集めた data から HTML を組み立てる service を用意する

各 service の開發 team が HTML 斷片を作り、HTML を組み立てる service を作る team が組み立てる

Client-side UI composition

Build a UI on the client by composing UI fragments rendered by multiple, business capability/subdomain-specific UI components

client 上で、複數の business 機能や sub-domain に分散した service 每の UI component を構築する

各 service の開發 team が UI component を作り、client team が組み合はせる

SPA (single page application)