マイクロサービス化を促進させたく、また今我々がマイクロサービス化に向けてとっているアプローチが正しいのかを確認する上で本書を読むことにした。
事前にいくつか言葉の定義をしっかりしておく必要がある。
代表的な登場人物として、マイクロサービスと、モノリスだ。
それぞれの定義と、メリット、作り出す問題は以下の通りだ。
マイクロサービスについて
マイクロサービスの定義
ビジネスドメインに基づいてモデル化された独立してデプロイ可能なサービス
サービス同士が疎結合である必要がある。
マイクロサービスのメリット
各サービスの作業を並行して行えるため、多くの開発者がお互いの作業を意識する必要がなく作業を行うことができる。
マイクロサービスが作り出す問題
マイクロサービスが作り出すのはメリットだけではない、
ネットワーク通信によりサービス間の通信が発生することになり、今までの処理以上にレイテンシーはかかってしまう。
また、サービスをまたいだデータベースのトランザクションも非常に難しい。
マイクロサービスによるメリットをきちんと享受しないと、デメリットだけ発生する可能性もある。
この問題に対して以下の問いに対し明確になっている必要がある。
- 達成したいことは何か
- マイクロサービスの他に代替案はなかったのか
- どうすれば移行がうまく行くか分かっているか
モノリスについて
モノリスの定義
マイクロサービスを語るとき、しばしばその対義語として使われることがあるが、この本ではデプロイの単位として捉えている。
システム内の全ての機能を一緒にデプロイする必要があった時、モノリスとして表現している。
全てのコードが単一プロセスとしてデプロイされているシステム。
モノリスのメリット
マイクロサービスと比べてしまうとモノリスで
- 監視
- トラブルシューティング
- エンドツーエンドテスト
などを行うのは容易と感じる。とにかく１個に集約されている状態は開発運用するのにメリットも確かにあった。
これはマイクロサービスを運用していると、このモノリスの当たり前がいかに我々に染み込んでいたかを感じる。
モノリスが作り出す問題
そもそもマイクロサービスに舵を切る理由である。
モノリスはさまざまなサービスが１つに集約されている。そのため長年運用していると機能拡張が難しくなる。
マイクロサービス化を始める時の大切なポイント
マイクロサービスに踏み切る際考えるべきポイント
- 自分たちにはどれくらいの数のマイクロサービスを扱えるか
- マイクロサービスの境界線をどのように定義するべきか。
この辺が重要になる。
マイクロサービスへの移行計画
茨の道になることもある。ビジョンと戦略を生み出す必要がある。
ビジョンとは・・・仲間を集めてどのような変化をもたらすことを望んでいるのか
戦略とは・・・そこに到達する方法
これらをメンバーと共有する必要がある。一人では到底難しいプロジェクトになる。
サービスのインターフェースを定義する際に重要になるのが
サービスがどのように利用されているかというサービス利用者の観点からサービスをデザインしていくところである。それがマイクロサービスへの道のりの一歩になる。イベントストーミングがそれになる。
イベントストーミングとは
技術的なステークホルダーと非技術的なステークホルダーが一緒に共有ドメインを定義する共同で行うべき作業。
イベントストーミングはボトムアップで行う。
システム内に発生する「ドメインイベント」を定義することから始め、
イベントを集約にまとめ、集約を境界づけられたコンテキストへまとめていく。
移行に於けるチェックポイントとして
時折立ち止まって振り返るための時間を組み込むことが重要
情報を分析し、軌道修正が必要かどうかを判断する
マイクロサービスでのトランザクション
ACID トランザクション（DB の一貫性を保つトランザクション）は全てのデータベースが持っているわけではない。
解決策が２つある
２フェーズコミット
投票フェーズと、コミットフェーズの２つに分ける。
- 投票フェーズで状態の変更が可能かを確認し、レコードにロックをかける。
- コミットフェーズで確定させる。
サーガ
複数の状態変更を調整できる。レコードをロックさせない。
各ステップのビジネスを明確にモデル化させる。
ロールバックするにはロールバック用の処理を用意する必要がある。（開発コストもリスクも高くない？）
以上、メモ。良いマイクロサービス移行の旅を。