#Motivation
クラウドアーキテクチャの流行りであるMSA(Micro Service Architecture)やサービスメッシュであるIstioとSidecar-proxyでありIstioのコアコンポーネントであるEnvoyのはじめの一歩の話です．

MSA(Micro Service Architecture)がこんなに流行っている理由は??

すべてのサービスが疎結合だから

疎結合だと何がいいの?
それぞれのサービスが独立しているのでクラウドのメリットであるスケールやレプリケーションがより容易になります．
これについては以下の論文が詳しくまとめています．
Evaluating the monolithic and the microservice architecture pattern to deploy web applications in the cloud

図を引用すると

モノリシックなサービス

これをスケールしようとすると...?

こうなります．　つまりWEBサーバーごと増やす形ですね．
たとえばS1のリソースは余っているけれども，S2のリソースが足りないよ！というときにはどちらもリソースが足りるまでS1S2のセットで増えていきます．

次にMSAでの単体のデプロイを見てみましょう

Internetとサービスの間にgatewayというのが挟まっています．
すべてのアクセスはgatewayを介してサービスにアクセスされます．
そしてサービスS1とS2はそれぞれリソースが独立しています．
ではこれをスケールするとしたらどうなるでしょう？

答えはそれぞれが必要なだけ独立してレプリケーションできるということです．
そしてこれはコスト面において大きく影響があったり，大量のアクセスが有った際に適切にピンポイントで増やせるので，最近のクラウドアーキテクチャの中では流行りですね！
ほかにも耐障害性などのメリットもありますが，そちらについては後日！とさせてください！

サービスメッシュとは...

さて，MSAのメリットを見てきたわけですが，Istioを始めとしたサービスメッシュが今トレンドです
https://istio.io/

Istioは大きく２つのパートに別れます

Control plane
Data plane
です．

かんたんに言うとさっきのS1,S2のコンテナと抱合せでproxyをおいてあげて，proxyを通るときにControl planeに報告しようね！という感じです．

MSAは大規模になればなるほどサービスのログトラッキングが複雑かつ別のサービスのログとの関連性については宝探しのような状態になります．

なのでそれらをIstioで統一してあげて，MSA内で共有しよう！というのがサービスメッシュです.

もしLGTMがつくようなら続きを書こうかな...なんて