gRPC調査

特性

API仕様を強制的に明文化
違う言語での高速で堅牢な通信を可能にする。

マイクロサービスとの相性

James Lewis/Martin Fowlerの"Microservices"日本語訳

サービスが切り分けられている。
- サービス間の結合部分は疎にする必要がある。
- そして、その結合部分の仕様は明確に定義したい => gRPC!!
- サービス間は高速に通信したい => gRPC!!
サービスによって目的が違う
- 適したプログラミング言語を使い分けたい => gRPC!!

REST とか GraphQL じゃだめなの？

gRPCはルールが明確に決まっている。マイクロサービスを構築する時に、連携部分が明確なのはメリット！また、通信速度は一番早い。ちなみに、双方向通信が可能！

gRPCの大きな問題点

HTTP2通信でないといけない。 ALB（AWS） => EC2 間の通信は、HTTP2は使えないので無理

マイクロサービスの大きな問題点

監視、管理の複雑性が増す

どうする？

最近流行ってそうなのが、Kubernetes + Envoy + Istio

Kubernetes

コンテナ環境を本番運用する際に必要な機能を提供してくれる。
アプリのスケーリングや、デプロイを容易にしてくれる。
NATS（queueサービス）などの、CNCFのプロジェクトと相性がいい。
- GKEでNATS Operatorを試してみる
これやりたいなーと思ったら誰かが実装してくれてる！

Envoy

nginxをマイクロサービス用に使いやすくしたみたいな認識でOKっぽい。 https://speakerdeck.com/mpon/envoywofen-kariyasukuli-etutuapp-meshfalsehua-wosimasu いろいろ機能持ってる。 - HTTP2のサポート - URLによって振り分け先のサーバを切り替えられる - 自動リトライ, CircuitBreaker, リクエスト制限 - ヘルスチェック - 動的な設定変更、サービスディスカバリー

Istio

Pod間の通信にEnvoyを挟むことで、トラフィックのモニタリングや、コントロールを行う。 - トラフィックの90%をAで、10%をBに送るとかできる。 - カナリヤリリースや、ABテストもできる！ - 特定の端末だけ、違うサービスに送るとかもできる！ - サービスや、URL毎にリクエストのエラーレート / レイテンシ / コネクション数のモニタリング - サービス間の通信を暗号化できる。

個人的なまとめ

サービスが拡大していくに連れて、マイクロサービス化の流れになり、スキル毎でなく、プロダクト毎にチームが分かれていきそう。その際に、データの結合部分は明確であるべきで、そこにgRPCはぴったり。ただ、マイクロサービスを進めると、デプロイやスケーリング、モニタリング等が別の問題が出てくる。そこで、効果的なのがDocker & Kubernetes。ただ、それだけだとシステム全体の監視（どこで障害がおきたのかとか）や、サービス間のルーティング制御が難しい。そこを解決してくれるのが、サービスメッシュ（Istion、Envoy）であって、これらを適切に利用していくこと複雑なマイクロサービスを管理できそう。

多分今までだと、準備として、ansible使ってAMI作って、それをAutoScalingGroupに登録して、それをALBに紐づける。その後、CodePipeline & CodeDeployに登録して、githubのpushをhookにして、CodeDeployを実行する。これを環境毎に行っていた。それが、DockerFileとkubernetesのyamlファイルを書いて、CI/CD実行時にDocker build して、kubectl apply を行う感じになるのかなと思う。