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がつくようなら続きを書こうかな...なんて