サービス指向アーキテクチャ

原則

サービス指向アーキテクチャはシステムやプロダクトをサービスとして分割して組み立てるシステムの設計方針また組織論。

実際のシステムやアプリケーション要件は複雑だけど色々な問題が繋がっている。それらの問題領域を分離して個別のサービスとして提供する。

影響

Proc: コードベースが大きくなり同時に考えるべきことが増大することを防げる

関連: 戦略的なDDDで設計しても似た対応できる (サービス境界を設けて厳格化するという方向に見える)

Proc: 相互依存など低減できる

関連: コードベースの分離でも循環参照をCIに含めることで対応できる

サービス分離してしまうと自動的に循環参照を禁止できるだろうか?

Proc: 機能の再利用ができる

関連: 連携に必要な知識が増える

関連: 連携が複雑かして把握できなくなると辛い

関連: 誤った利用が発生することを防ぐ必要がある

関連: システムとしての一貫性の提供が難しい

Cons: サービスごとにデプロイなどの運用が伴うため運用負荷が高まる

CI/CDを簡単にする仕組みを事前に準備する

build, test, deploy, monitoring, relase

プロダクト色々: Argo CD, Spaenaker, kubeflow, ...

Cons: 責任の所在を作りにくいユースケースが発生すると悩む

闇雲に分割するところから始めない

Cons: サービスが小さくなりすぎて必要な修正箇所が増える可能性がある

闇雲に分割するところから始めない

Cons: 連携に必要な知識が増える

標準的な方法を決めておく

gRPC: 初手

OpenAPI: 古いシステムとREST通信が必要

GraphQL: 柔軟なビューを提供したい

websocket: 古いシステムにPushしたい

ログベースストリーミング(Kafka, NATS Streaming, Kinesis): イベント駆動の初手

MQTT: 頻発する軽量な通信が必要

WebRTC: P2Pなアプリの実現

Cons: 連携が複雑化して把握できなくなると辛い

対策

サービスメッシュ

分散トレージング

ログ集約

監視(メトリック・アラート)

Cons: 誤った利用が発生することを防ぐ必要がある

基本的なセキュリティ方針の準備

取り扱うデータの種別・責任

標準ガイドラインへのリンクと確認プロセス

相談先

システムの基本的な方針

RBAC

ネットワーク分離

成果物に署名

クライアント署名

ペネトレーションテスト(OWASP, nmap)

認可基盤

Cons: システムとしての一貫性の提供が難しい

各サービスは下を提供する

回復トランザクション

連携が必要なサービスは以下を利用する

分散TX

イベントソーシング

サーガジョブの実装

実装方針

各サービスはコードごと分離する

分離したサービス間の連携の標準的な手法を定めておく

通信プロトコル

認可

分離したサービスへの不正な通信路を残さない

やみくもに分割しない、単一サービスでスタートしていいじゃない

CI/CDを簡単にする仕組みを事前に準備する

build, test, deploy, monitoring, relase

プロダクト色々: Argo CD, Spaenaker, kubeflow, ...

サービスサイズは最大でもチームで目が届く

言い換え: 1人で分析して1日で問題箇所や修正箇所を特定できる