マイクロサービス
巨大なシステムを見直すために考案された考え方。
特徴
- ビジネスロジックを機能単位で分割します。
- 機能ごとにサーバーを分けます。
- 機能ごとが疎結合になっているので機能ごとにリリースが可能です。
- 機能が小さいのでソースの見通しが良くなる。
- 「結果整合性」になるので考慮は必要になる。
- リソースの増強も機能ごとにできるので柔軟
- ネットワーク負荷や、どのサービスが連携しているかの管理負荷は増大する。
- アジャイル開発との相性が良いです。
モノリス
「マイクロサービス」と対極に位置する考え方です。
特徴
- ビジネスロジックをプログラム単位で分割します。
- 全てのビジネスロジックが一つのサーバーに置かれます。
- プログラム間の関連が強いためリリース時に同期を取る必要があります。
- リソースの増強はアプリケーション全体で行う必要がある。
向く事業
新規事業よりもドメイン境界がはっきりした成熟した事業にマイクロサービスは向く。
アセスメント
事業の目的や目標を明文化する。マイクロサービスも「銀の弾丸」ではないので採用する中でたくさんの課題が発生する。本当に採用するメリットがあるのかを検討すること。
一般的なマイクロサービス化の事業目的
- 早くリリースしたい。
- 障害発生率を下げたい。
組織/体制の変革
「レビンの変革プロセス」という考え方に沿って進める。
抵抗勢力への対処は「ジョンコッターの抵抗勢力に立ち向かう6つの対処法」に沿って進める。
Conwayの法則
「組織=システムアーキテクチャ」で組織が巨大化すると開発効率も悪くなる。
マイクロサービスと相性の良いコンテナ
マイクロサービスは一つ一つの単位が小さいためコンテナとの相性が良くなります。
分割単位
明確な定義はない。
個人的な感覚で「大きすぎると感じないサイズ」がちょうど良い分割単位とされます。
定義例
2週間で全てのコードを書き直せるレベルで分割するのが良いという人もいる。
注意点
全てのコードが書き直しになるわけではないので、不必要に何でもかんでもマイクロサービス化する必要性はないと思われます。
また、影響範囲が特定できるレベルで分割するのも望ましいとされます。
サービスとは？
何かしらの機能を実現する単独動作、単独デプロイ/リリースできるコンポーネント
含めるもの
- API
- サービス
- データ
特にデータを含めるのは画期的と言えるでしょう。
マイクロサービスの課題
サービスの適切な分割範囲を見極めるのが難しい。
分割範囲を間違うとリリース時の複数サービス間の調整が必要になってしまう。
アプリケーションの設計が複雑になる。
複数サービスを同時修正しないといけない場合はリリースデプロイの調整が必要
分割範囲の見極めとも関わってくる話です。
アプリケーション全体のテストが難しい。
アプリの移行方法
一気にモノリシックからマイクロサービスに移行するのではなく徐々に移行していくことが推奨されている。
段階的な分割/再構築
ストラングラーパターンに沿って段階的に機能を移行していく。
共通の仕組み作り
DevOpsツールは何にするか、共通機能の導入（APIゲートウェイ）、開発準備（ドキュメント化ルール）
プロキシを活用する。
プロキシを挟んで古いサービスと、これから作成するマイクロサービスを振り分けるようにします。
メリット
モノリスに対する修正を減らせる。
デメリット
URL単位である程度機能として分割できている状態じゃないと使えない。
使用ソフト
NginxやKong
I/F定義を利用した分割
オブジェクト指向のストラテジーパターンを適用してインターフェースを使って分割します。別サービスを呼び出すときは、必ずインターフェース経由で呼び出すようにします。新サービスと旧サービスをインターフェースで切り替えます。
新旧の切り替えが終わったらモノリスな旧サービスは削除します。
メリット
複雑化してしまったコードでも分割ができる。
デメリット
モノリスに対する修正が必要になる（ストラテジーパターンを適用するために）のでリリースや調整が必要になってくる。
DBの移行
DBを物理分割する。
メリット
サーバーが物理的に分かれていると障害時の影響を下げることができます。
デメリット
データベースのライセンス費用がサーバーごとにかかってしまいます。もし、SQLServer、OracleなどライセンスがかかるRDBMSを活用しているのであれば、お金がかからないMySQL、PostgreSQLなどに置き換えることを検討します。
DBを論理分割する。
サーバーは同じでDBのスキーマだけ分ける手法です。
メリット
同じライセンスでいけるのでライセンス費用は抑えられる。
デメリット
1台のサーバーに対してコネクション数が増えることになるので注意が必要。
分割手法
データから分割
- 論理分割する。（新スキーマは書き込むだけ、旧スキーマは読み書きを行う。）
- 真とするデータの切り替え（CQRS、サーガなどを使う。）
- アプリや機能を移してあげる。
メリット
データに対して分割に問題ないか最初の段階で整合性確認がしやすい。
デメリット
マイクロサービスの効果を体感しづらい。（裏側から変えていくのでユーザーからしたら何も変わってないかのように見える。）
アプリから分割
- 新しいサービスを作る。
- 新スキーマを作る。
- 少しずつ新スキーマに処理を移していく。
メリット
マイクロサービスの効果を体感しやすい。
デメリット
意識的にデータ分割を行わないと潜在的なリスクを抱えたままになる。（早い段階で効果を感じるゆえにデータ分割が蔑ろになりかねない）
アプリとデータを同時に分割
- 論理分割（旧スキーマは読み書きを行い、新スキーマは書き込みだけ行う。）
- アプリも同時に分割する。
メリット
マイクロサービスの理想系にいきなり到達できる。
新機能はこの手法を取りやすいです。なぜなら新機能の場合は新しくスキーマ定義から行うことになるためです。（旧スキーマの実装が不要）
デメリット
修正コード量が増える。
この記事へのコメントはありません。