More than 1 year has passed since last update.

マイクロサービスアーキテクチャ疑問点メモ

Last updated at 2022-06-21Posted at 2020-11-14

まとめようにも膨大・広大すぎるため、QAメモ風で残すことにする。

結局なに？

プロセス間通信などで担っていたマルチスレッドプログラミングをコンテナレベルに適用したもの。
だから、キューメッセージングとかキャッシュ共有とかの話が出てくる。
ただ、CI/CDとかはこの範疇を超えている概念なので、マイクロサービスの構成概念は広い。
結構腑に落ちたサイト様の説明

メモリ間の共有の話だった点は、ネットワーク間の共有の話になるため、ネットワーク接続の検討も必要になる。

マイクロサービス　＝　
マルチスレッドプログラミング
＋ネットワーク
＋CI/CD
＋DevOps
＋DDD
＋スケーラビリティ
＋体制

って感じでもう全部入り。ありえない難しさになっている。
みんなちゃんと分かってます？？？って感じ。

結果整合性で代替する。
最後が帳尻あっていれば良いという考え。
つまり、間違った情報で永続化される時間帯が存在する。

複数のマイクロサービスに対して永続化を伴う処理を行う手続きがあった場合、
従来型のモノリシックアーキテクチャならば、DBトランザクションを宣言してその中で手続きを遂行し、
失敗した場合は、ロールバックすることで途中まで進んだ手続きを簡単に無かったことに出来た。

マイクロサービス化することで、DBの機能に依存したトランザクションは利用できない。
一つ一つの手続きは常にDBへコミットされることになるため、
失敗したタイミングに応じて、その確定してしまったデータを無かったことにする必要がある。
それが補償トランザクション。

例えば、ある一連の手続きにおいて、パフォーマンスが劣化しているということをどうやって観測するのか。
α、β、γのサービスがあり、ある手続きAでα、β、γを利用した場合に、処理時間が一番遅い箇所がボトルネックとして判断してよいのか。

マイクロサービスはあるまとまりのサービスであるため、エンドポイント別の処理時間は一定となることが多いはず。
α、β、γのサービスを横断した手続きのボトルネックがαの場合、多くの場合はαの処理に問題があるor制約があると考えられそうである。

IFの内容について、削除や大きな変更があった場合は、現バージョンの廃止＋新バージョンの公開が必要。影響は大きい。
基本、後方互換性は考えない模様。サービスによりそうだが。

サービスメッシュとは、言葉の通り、マイクロサービス間の通信経路を俯瞰すると網の目上になることを指している。
網の目を実現するためのアーキテクチャを指している文脈もある。

マイクロサービスはコンテナ上で稼働させることが一般的。
アプリケーションの関心事とマイクロサービスの横断的な関心事は異なる。
マイクロサービスの横断的な関心事を平易に扱うためにサービスメッシュという枠組みに、

を用意する。サイドカーコンテナは、マイクロサービスへのプロキシサービスであり、そこでは、AOP的な立ち位置で共通的な関心事の対応を行う。

サイドカーコンテナでは、以下を行う。

基幹業務システムをマイクロサービスアーキテクチャで作ることへの警鐘。