builderscon tokyo 2018に参加してきましたので、メモ。
仕事で Kubernetes を扱っているので、その周辺技術の話を聞いてきました。 初日はサービスメッシュ関係がたくさん。
Envoy internals deep dive
Envoy 開発者の Matt Klein 氏による、開発の背景と内部アーキテクチャの解説。 Kubecon EU 2018 の拡大版（同じ？）のようで、そちらの資料は公開されていました。
- マイクロサービスが多様な言語で開発されると、サービス間通信の標準的な振る舞いをライブラリアプローチで実装するのが困難
- そこで L7/L4 プロキシとしてサービス間通信を調整する Envoy を開発
- Envoy 自体は通信処理に専念するデータプレーンで、Envoy のクラスタを管理するコントロールプレーンを別に用意する
- アーキテクチャは... 一言でいって美しい。スライドを見てください。
クラスタ運用に最適化されているので、なるほど評価が高いのも頷けるという感じ。
Building and operating a service mesh at mid-size company
クックパッド社で Envoy によるサービスメッシュを実装した話。 Envoy をサイドカーコンテナでプロキシとして挟み、サービスディスカバリなどを担わせるシンプルな組み込み方。
資料というかブログが公開されています。
The state of the art of architecting Kubernetes-based infrastructure -Towards Maximum Security and Usability
ちょっとサービスメッシュから離れて Kubernetes クラスタの運用の話。 トラブルで開始が遅れたので駆け足でした。
資料はこちら：
teleport という監査や二要素認証機能がある SSH サーバーが紹介されていて、 知らなかったので discover something new でした。
Istio: Weaving a Secure Service Mesh
GCP の中の人による Envoy を利用した高機能サービスメッシュ Istio の解説。 クックパッドの基本形との最大の違いは、クライアントサイドの Envoy だけでなくサーバーサイドにもリバースプロキシとして Envoy を配置することで、TCP/TLS/HTTP 通信をまるごと乗っ取る構成がとれる点です。
アプリケーションを一切いじることなくネットワーク認証を実装できてしまう（mutual TLS と言ってました）など、サービスメッシュの真価を味合わせてくれるデモになっていました。
Understanding Microservices with Distributed Tracing
クラウドサービスはたった一つのプログラムで動作することはほとんどなく、たいていはリクエストを複数のサービスで処理します。 障害が発生するとどこに問題があったかログなどで確認するわけですが、可視化されていないとログやメトリックをサービス別に順次確認していくことになり、手間も時間もかかる作業になってしまいます。まして、マイクロサービスで数百のサービスがあると人力では困難です。
リクエストがサービス間でどのように処理されているかを視覚化したいというわけで、Lyft の中の取り組みが解説されました。
- 追跡用のログ（instrumentation）を共通化する
- OpenTracing を使うと共通の instrumentation ライブラリが 9 言語に用意されていて良い
- jaeger で可視化・分析できる
- Envoy/Istio でクライアントとサーバー両端で仲介していれば、アプリケーションを修正する必要もなくなる
- Istion にはサービスのフロントになる Ingress (ロードバランサ)実装もあるので、リクエスト ID 発行から一気通貫できるんだろうな
と、ここまでの流れを踏まえて「サービスメッシュすげぇ！」と理解させられました。 これ、builderscon の運営が意図していたなら（意図していたと確信してます）、見事です。
一言でまとめると、最高でした！
