Microservices Advent Calendar 2017 22日目の記事です。
14日目の記事の最後に、
https://qiita.com/seikoudoku2000/items/9d54f910d6f05cbd556d
ちなみに、先日、Austinで開催されていたkubeconでもIstioに関する発表があったようなので、そちらも期待ですね！
ということを書いたら、丁度、先週末に動画が大量にアップされたので、
https://www.youtube.com/channel/UCvqbFHwN-nwalWPjPUKpvTA
ちょこちょことチェックしたのですが、残念ながらIstioに関するクールなプレゼンは見つけられず、、、
今日はIstioのことを調べている中で知ったMonzo というイギリスの銀行(本当の銀行の業務ライセンスを有している)が使っている Linkerdのことを書きたいと思います。
tl;dr
- Monzoというイギリスの銀行は、Kubernetes + Linkerd という最新のスタックで銀行のど真ん中のシステムを作っている。
- Envoy/IstioとLinkerdはよく似た思想/レイヤーのプロダクト
- 誰かに徹底比較してもらいたいw
Linkerdとは？
公式ベージ (https://linkerd.io/) の説明によると、
とのこと。
Envoyの作者の方のEnvoyの説明(というか理念?)を見てみると、
https://www.slideshare.net/datawire/lyfts-envoy-from-monolith-to-service-mesh-matt-klein-lyft/11
とあります。
transparent という言葉が共通して出てきていて、プロダクトの思想がとても似ていることが感じ取れます。また、先述の14日目のアドベントカレンダーでEnvoyを詳しめに紹介していますが、これってLinkerdの説明がピタッとハマるよねという感じなので、２つはよく似たプロダクトであるということが言えそうです。
違いそうな点をあげるとすると、Envoyを作ったMattさんが、EnvoyのService DiscoveryはEventual Consistentなのでscaleしやすい、他の会社はetcdやconsuleを管理するための人間がいて大変なんだよってのを強調されていたので、
https://www.slideshare.net/datawire/lyfts-envoy-from-monolith-to-service-mesh-matt-klein-lyft/16
機能としては同じだけど、バックエンドの仕組み/scaleに対する考えが違う、ってのがありそうです。が、その辺は調べきれていません。
MonzoでのLinkerd
- When Failure is Not an Option: Processing Real Money at Monzo with Kubernetes and Linkerd
動画: https://www.youtube.com/watch?v=wBgBwNZo_EE
資料: https://speakerdeck.com/olix0r/when-failure-is-not-an-option-processing-real-money-at-monzo-with-kubernetes-and-linkerd - Building a Bank with Kubernetes
動画: https://www.youtube.com/watch?v=YkOY7DgXKyw
資料: https://speakerdeck.com/obeattie/building-a-bank-with-kubernetes-kubecon-2016
前者の方がLinkerd中心な話で、後者はMonzoのシステム全体っていう感じ。
どちらのプレゼンでもTwitter云々の話が出てきたり、後者の方ではFinagle のロゴもあったり、元Twitterの人たちが結構いるのかな？
Linkerd の機能
先に書いた通り、基本的にはEnvoyとよく似たプロダクトなので、基本的な所は省いて、気になったポイントだけ上げていきます。そもそも、この辺のツールって何者？？って感じの人は14日目のアドベントカレンダーを是非ご覧ください。
deadlines
- timeout/retryの設定が各所にあると、後ろの方の処理は続いてるのに、フロントがタイムアウトしちゃってることってあるよね？ (確かにめっちゃあるw)
- なので、(フロントのtimeout - 既に消費された時間) を引き回し、後続の各serviceでどれくらいの時間が残されているのかを分かるようにして、もし、途中でフロントのタイムアウトを迎えたら、そこで処理を打ち切る。
budgets
- retryを入れると、本当に不具合が発生している時に、そのサービスに対してretry倍の負荷をかけてしまい、復旧を送らせてしまう/自動復旧が出来ない状態になる恐れがある。ので、retry用にどれくらいの追加負荷を許容するかを設定する。
- (ここはcircuit breaker / back pressureの方が良さそうな？ そこの使い分けは調べきれていないです。)
KubernetesのIngressとして設定可能
既にkubernetesを使っている場合、各serviceの手前に、容易にLinkerdを差し込むことができる。
https://github.com/linkerd/linkerd-examples/tree/master/k8s-daemonset
Ingressの説明
https://kubernetes.io/docs/concepts/services-networking/ingress/#what-is-ingress
(Ingressとして設定するという方法がある中で、Envoyはなぜにこの方式ではなく、Istioという別レイヤーのプロダクトを挟む方向に進んでいるのかなーと思ったり。各cloudベンダーで透過的に使いたいというのが目的なのかな？まだよく分かっていない。)
その他のLinkerd事例
- Credit Karma (こっちは先日のAustinのkubecon)
動画: https://www.youtube.com/watch?v=PoGUI74TimM
資料: https://schd.ws/hosted_files/kccncna17/39/Monolith%20to%20Microservices%20-%20Kubecon%202017.pdf
k8sを導入する前から、しかもオンプレの環境でLinkerdを導入していたという話。
今見ると、だいぶ遠回りしたなーと思ってしまいますが、逆にツールが整っていないところで、ガンガンと挑戦していたわけであり、そういった会社がLikerdに落ち着いたってのは、注目すべき点な気がします。
(他に見つけたら適宜追記します)
まとめ
LinkerdとEnvoy/Istioの比較という所では、事例ベースのLinkerdに対し、今回のkubeconではまだ事例は出て来なかったけど、IBMやMicrosoftの人たちがこぞって推していたIstio (Envoy自体はLyftでガンガン使われてはいるわけですが)。
現場主義なLinkerdが勝つのか、ベンダ一押しのIstioが勝つのか、両方進化を続けるのか、それとも他の何かが出てくるのか、、、Container management systemとしてはk8sが覇権を取ったような感じがありますが、次はその上で動くMicroservice用proxyのレイヤーの戦いが始まっていますね。誰かにこの２つの徹底比較をしてもらいたい。。。
そして、Monzo、銀行というどエンプラなシステムをLinkerd on Kubernetesで作るという、とてもチャレンジングなことをやっていて、めちゃ面白そうです。web系とかエンプラ系とか関係なく、最新の技術でいいものを作る。格好いいですね。どうやって会社が始まって、どうやってこんな開発チームが出来上がったのか、その辺の話も聞いてみたいです。これからも要注目な会社と思いました！