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

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

# 結局なに？
## 出展
https://martinfowler.com/articles/microservices.html

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

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

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

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

# マイクロサービス間の通信の方法は？
[Building Microservices, 2nd Edition](https://learning.oreilly.com/library/view/building-microservices-2nd/9781492034018/)によれば、

* 同期ブロッキング通信パターン
    * Request & Response
        * [RPC](https://ja.wikipedia.org/wiki/%E9%81%A0%E9%9A%94%E6%89%8B%E7%B6%9A%E3%81%8D%E5%91%BC%E5%87%BA%E3%81%97)  
        RFC1057，1831
        * REST Over HTTP（REST通信）  
            HTTPでRESTで縛る。
* 非同期ノンブロッキング通信パターン
    * Request & Response
        * Queue-based brokers（[MQ](https://ja.wikipedia.org/wiki/%E3%83%A1%E3%83%83%E3%82%BB%E3%83%BC%E3%82%B8%E3%82%AD%E3%83%A5%E3%83%BC)）  
        キューで処理。
        * [RPC](https://ja.wikipedia.org/wiki/%E9%81%A0%E9%9A%94%E6%89%8B%E7%B6%9A%E3%81%8D%E5%91%BC%E5%87%BA%E3%81%97)  
        RFC1057，1831
    * Event Driven
        * Topic-based brokers
            * Pub-Subパターン。
        * REST over HTTP([Atom](https://ja.wikipedia.org/wiki/Atom_(%E3%82%A6%E3%82%A7%E3%83%96%E3%82%B3%E3%83%B3%E3%83%86%E3%83%B3%E3%83%84%E9%85%8D%E4%BF%A1)))
    * Common Data（データ共有）
        * Database
        * File system


# マイクロサービスを跨ったトランザクションはどうするの？
結果整合性で代替する。
最後が帳尻あっていれば良いという考え。
つまり、間違った情報で永続化される時間帯が存在する。

# [補償トランザクション](https://docs.microsoft.com/ja-jp/previous-versions/msp-n-p/dn589804(v=pandp.10))て何？
複数のマイクロサービスに対して永続化を伴う処理を行う手続きがあった場合、
従来型のモノリシックアーキテクチャならば、DBトランザクションを宣言してその中で手続きを遂行し、
失敗した場合は、ロールバックすることで途中まで進んだ手続きを簡単に無かったことに出来た。

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



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

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

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

# 分割の戦略は？
* ビジネス
    * アジリティを担保できるかどうか
* システム
    * トランザクション分断を起こさない単位  
      基本的にマイクロサービス間のトランザクションは複雑でテストも難しい→バグりやすい＋バグが見つけづらい
* [マイクロサービス　４つの分割アプローチ(増田　亨さん)によると](https://www.slideshare.net/masuda220/ss-146325870)
    * 業務機能
    * 動詞／ユースケース
    * 名詞／リソース
    * 境界付けられたコンテキスト
  
# サービスメッシュとは？
サービスメッシュとは、言葉の通り、マイクロサービス間の通信経路を俯瞰すると網の目上になることを指している。
網の目を実現するためのアーキテクチャを指している文脈もある。

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

* マイクロサービスコンテナ
* サイドカーコンテナ

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

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

* 通信の最適化（流量制御・サーキットブレーカーの発動制御）
* ログエージェントの稼働

## サービスメッシュサービス
* Istio
* Aws App mesh

# 参考資料
## アジャイルとマイクロサービスは最悪な組み合わせ
https://dbconcept.hatenablog.com/entry/2022/03/16/131543

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