はじめに
読んだ。
意識だけ大気圏超えて高めていくスタイルなので、イキってSafari契約しました。月39ドル分読むんだよな？読むんだよ！
まーまじめな話、一次情報をちゃんと英語から得ないといけないというのは感じているので少しずつやっていく足がかり。技術書はまぁまぁ読んできたほうだと思うけどなんやかんや翻訳まで2年とかかかること考えるとね。
まだ英語版もEarly Releaseでもあるので本文の引用は控えて、メインな部分や気になった部分だけをざっくりまとめるにとどめるので興味を持ったひとは原文へGoです。
メモ的な
- マイクロサービス、バズってるよね
- 信頼性エンジニア（SRE）はマイクロサービスに関する問題で大変だよね
- networking
- observability
- 考えていくぞ
Ready to Get Rid of the Monolith?
- マイクロサービスの話する前にモノリシックなアプリから考えていくよ、だいたいこんな感じのコンポーネントからなるよね
- 相対的にシンプルと言われてるモノリスでもNetworkingとobservilityが大事やし、十分複雑なんよ
Current State of Microservice Networking
- マイクロサービスの現状を見ていくよ
- Observabilityが一番大事やけんね
Service Mesh to the Rescue
- 開発者の選択肢は2つ
- 使われる言語数を制限し、一貫した方法で、必要な機能を全て内包した複雑なライブラリを導入する
- sidecar proxyの導入
The Benefits of a Sidecar Proxy
- sidecar proxyのメリットってあるの？
- Out-of-process architecture、アプリから独立できる
- High-performance code base、C++とか性能が高い言語でかく
- Pluggability、プラガブルにすることでいろんなプロトコルともしもしできる
- Advanced protocol support、HTTP / 2、QUIC、TLS 1.3
- Service discovery and active/passive health checking
- Advanced load balancing
- retry
- timeouts
- circuit breaking
- rate limiting
- shadowing
- outlier detection
- Observability
- 何度も言うけど一番重要やけんね
- Additional use as an edge proxy
- Ease of deployment and upgrade
Eventually Consistent Service Discovery
- まぁいろいろあるよね、静的設定したIPアドレスからDNSからZookerperから
- service discoveryのcheckは2段階でやって、どっちもfailだとrouteを閉ざすよ
- 外部からの（例えば）/healthcheck endpointを叩く
- 内部的に（例えば）503 responseを3回返してるとか
- 前者がOKだと後者がNGでも通すし、どっちもダメならrouteから消す
Observability and Alarming
- 本当に何度も言うけど一番大事よ
- sidecar proxyが提供する機能は以下
- Consistent statistics for every hop
- A persistent request ID that can join logs and traces across the entire system
- Consistent logging for every hop
- Distributed tracing for the entire system
- Consistent system-wide alarming
Sidecar Performance Implications
- 性能大丈夫なん？
- sidecar proxyは諸刃の剣
Thin Libraries and Context Propagation
- 結局アプリケーションレイヤーでContext Propagationは必要
- いろいろライブラリはあるとはいえ、どう実装するかは悩みどころ
Configuration Management (Control Plane versus Data Plane)
- これまでService meshの利点語ってきたけど、実際どうやって設定配るかの話してなかったね
- Data Plane：実際のsidecar proxy。地下鉄でいえば電車。
- Control Plane：ルートテーブルやトラフィックルールを持って、データに配る。地下鉄でいえば路線切り替え。
- 実際にどう動くかというと
- データプレーンに変更が必要な、グローバルシステムの変更を探索
- システム内のすべてのプロキシへの新しい設定を生成
- すべてのプロキシに設定変更をデプロイ
- 各プロキシに設定をリロードさせる
The Service Mesh in Practice
- proxyのソリューション：HAProxy、NGINX、Linkerd、Traefik、Envoy
- 完全なソリューション：
- SmartStack（HAProxy上に構築）
- Istio（Envoy上に構築され、現在Linkerdもサポートしています）
The Origin and Development of Envoy at Lyft
- LyftにはSREと呼ばれるポジションはない
- envoy作ったらすっごい役に立った
- アプリケーション構築にネットワーク意識することなくなった
Operating Envoy at Lyft
- もう一度言うがLyftにはSREポジションはなく、すべての開発者がそれをかねる
OPERATIONAL LEARNINGS
- デフォルトのダッシュボード、トレース、ログ、アラームの自動生成
- ドキュメント
- めっちゃ重要よ
- みんなのスキルはそれぞれ。ネットワークにあまり詳しくないひとに役立つ
- テンプレート化された設定生成
- Hot restart for easy roll-forward and rollback：ローロバックやロールフォワードが行えるホットリスタート
- Administration endpoint for on-node debugging：人間が読めるようなデバッグノード
DEVELOPMENT LEARNINGS
- Decoupled sidecar deploy process
- アプリケーションから独立してsidecar proxyをdeployできる
TECHNICAL LEARNINGS
The Future of the Service Mesh
- Service Mesh開発はこれからしばらく多額の投資が必要だと思う
- ただ、サービスメッシュがうまいこといってるアプリケーションに対して開発者はデプロイしたくなくなるだろう（なんで？ここの訳がわからず）
Recommended Reading
（読んでいません）
Istio service mesh（どのページかわからず）
おわりに
英語の技術書の読み方に関して。まずざざーっと英語読んで、わかんないところは翻訳ぶち込んで、また英語読んで、ってのを小分けに何度かやって、またまとめながら書いた感じ。日本語技術書の解釈と似たようなプロセスだけど、時間が3、4倍（もっとか？これ1章分だしなぁ）かかるのがつらい。慣れかな。とりあえず自分なりのいいやり方があると思うので続けたい。
サービスメッシュに関して。とにかくObservabilityが大事ということはとても伝わった。実際envoy/istioは今導入検討している会社が多いので今後触ってみたいのと、本当にその解決が必要なのか、課題は何なのかは十分に考えたい。
Observability、結局のところ、logging, alarting, tracingあたりだと思う、一番大事なのは分散トレーシングだよねーこれは欲しいよねーというのはわかるなぁ。ただ本章で触れられている通り、リトライなりロードバランシングなりはproxyに持たせることはできたとしても、一貫したトレースIDはアプリからつけてあげなきゃいけない気がするし、その実装がさっぱりなので知りたい。opentracingっていう仕様に従うのが良いのかな。よくわかってない。
ただでさえ複雑でつらいMicroservices、そもそもそれにする必要があるのか、さらにService meshを導入する必要があるのか、その損益分岐点はどこだ？みたいな話が聞きたいし、試してみたいところです。
