3月やりたかったことはあんまりできてない。途中から本格自粛になっちゃったねえ。できてないことと関係ないけど。
あんまりやっていくことが定まらない。どこに向かうべきかちょっと見失ってしまった。英語もゾンビ英会話は続けてるし仕事でもちょいちょい英語ミーティングはあるがモチベーションを失いつつある。
4月は次の1年の方向を定める月としたい。
1年後に転するつもりで（するとは言っていない）いろいろ考えたい。カジュアル面談はぼちぼちしていきたい。少なくとも1年以内はないという前提でよければ keep in touch カジュアル面談声かけてください。
いのちだいじにしつつ、少しずつ、少しずつ。進む速度より進む方向をていねいに考えたい。
弊社には以前 Shadow Proxy というものがいた。
当時のモチベーションとして Database への Index 追加等をぶつけでなく事前にやりたい、ということだった。現状は Production database の Snapshot から Develop database を毎晩リストアしており、事前にそちらで実行するようにしている。
2020年の今やるなら Envoy かな、と。
で、ここでモチベーションとしてあげている負荷テストとは特に、Database の Migration のことを考えている。
現状 EC2 上に MongoDB をセルフホストしている。そのためインスタンスのスケールアップが必要なときにはいろいろあって1日ほどかかる。マネージドサービスの Atlas にすればスケールアップも容易で早くなるし、パフォーマンスに関する分析も提供してくれるようだ。
この Atlas に本番環境を移行する前に、Prodcution と同様の Query を実行しても Performance に問題がないことを事前に確認できればいい。
最近、一部のサービスで、Rails Application から MongoDB への接続の間に Envoy を経由するようにした。
admin: access_log_path: /dev/stdout address: socket_address: { address: 127.0.0.1, port_value: 9901 } static_resources: listeners: - name: listener_0 address: socket_address: { address: 0.0.0.0, port_value: 10000 } filter_chains: - filters: - name: envoy.http_connection_manager config: stat_prefix: ingress_http codec_type: AUTO route_config: name: local_route virtual_hosts: - name: service_http domains: ["*"] routes: # Envoy admin endpoints - match: { prefix: "/ready" } route: { cluster: envoy_admin } - match: { prefix: "/stats" } route: { cluster: envoy_admin } http_filters: - name: envoy.router config: {} - name: mongo_proxy address: socket_address: { address: 0.0.0.0, port_value: 27017 } filter_chains: - filters: - name: envoy.mongo_proxy typed_config: "@type": type.googleapis.com/envoy.config.filter.network.mongo_proxy.v2.MongoProxy stat_prefix: mongo_proxy - name: envoy.tcp_proxy typed_config: "@type": type.googleapis.com/envoy.config.filter.network.tcp_proxy.v2.TcpProxy stat_prefix: mongo_tcp_proxy cluster: mongo_proxy clusters: - name: mongo_proxy connect_timeout: 0.25s type: strict_dns lb_policy: round_robin load_assignment: cluster_name: mongo_proxy endpoints: - lb_endpoints: - endpoint: address: socket_address: address: mongodb-0 port_value: 27017 - endpoint: address: socket_address: address: mongodb-1 port_value: 27017 - name: envoy_admin connect_timeout: 0.250s type: LOGICAL_DNS lb_policy: ROUND_ROBIN hosts: - socket_address: protocol: TCP address: 127.0.0.1 port_value: 9901
MongoProxy filter で metrics をとりつつ、基本的には TCP で proxy しているだけである。そもそも普段、アプリケーションやコマンドラインでは、MongoDB Wired Protocol で MongoDB と通信している。
Cluster を Load Balancing しているのは Primary と Secondary Node である。
さて、このような状態でどうするか？複数の Cluster を定義し、Mirror したものを別の Cliuster (Atlas) に送り、レスポンスは棄却する、ということがやりたい。
request mirror policies が使えそうだが、これは http だ。
残念ながら TCP Layer でこれらは実現できそうにない。
Envoy Slack で "The upstream envoy filter is only for http right now" という回答を得た。やむなし。
とすると http でやるしかない。
こういう例。
どこでミラーするのかあらためて考える。
graph TD A[Nginx] -->|http://service-a.quipper.com| B[k8s service] subgraph Kubernetes B[Nginx] -->|http://service-a| C[k8s service] C -->D[Rails Application Pods] subgraph Pod D -->|mongo://localhost:27017| E[Envoy] end end E -->|mongo://mongo-fqdn:27017| F[MongoDB]
Front Proxy 相当の動きをしている、Kubernetes 内の Nginx でやるしかあるまい。
その場合、この Nginx を Envoy にすぐに置き換えることは難しいので、これまた Sidecar として Envoy を使うことになるだろう。
こうなる。
graph TD A[Nginx] -->|http://service-a.quipper.com| B[k8s service] subgraph Kubernetes subgraph Pod-Nginx B[Nginx] -->|http://localhost| C[Envoy] end C[Envoy] -->|http://service-a| D[k8s service a] D -->E[Rails Application Pods] subgraph Pod-Rails-a E -->|mongo://localhost:27017| F[Envoy] end C -->|Mirroring| H[k8s service b] H -->I[Rails Application Pods] subgraph Pod-Rails-b I -->|mongo://localhost:27017| J[Envoy] end end F -->|mongo://mongo-fqdn:27017| G[MongoDB] J -->|mongo://mongo-fqdn:27017| K[Managed MongoDB]
次回は具体的にどういう config でやるのかを試す。
Envoy を使えば rate limiting, retries, timeouts を実装しなくて済むようになります。この記事では client が障害と backpressure をどう扱うかを示します。
まぁだいたいは Envoy での設定（rate limiting, retries, timeouts）でなんとかなるが、失敗し続けた際にどう振舞うかを client に実装する必要がある。
へー。Envoy が Downstream(client)に、それらが失敗したときに返却する一覧。
x-envoy-overloaded: true header をつける。x-envoy-overloaded: true header をつける。Back Pressure って問題起きた時に Envoy が Downstream に何を伝えるかって意味だったのね。
まぁでもどういうレスポンスコードが帰るかを知れるのは有益だった。
この時点ではよくわかんないけど、Kubernetes の上に Gateway 層(Istio とか他) がいて、その上に Knative がいるようだ。
Knative が利用する Gateway というのは Envoy とかでよく説明される Front Proxy - North / South traffic のこと。この手段がいくつかある。
いずれも Envoy を Proxy に利用している。
その代表として Istio の説明。
結局イマイチ Knative いれるのになんで Istio(Gateway?)がいるのかがよくわかってない。
Typo をみつけたけど PR 投げられない。
3.5 Istio のコンポーネント つぎは主要なコンポーネントのインストールです。ここでは Helm を使って kubectl で apply する YAML ファイルを生成して apply います。
Istio で gateway つくって、それを外部から Knative に流すためにいるんかな。そのために Istio はヘビーじゃない？と思うが。
基本的に north-south トラフィック を制御するためのプロダクトです。east-west トラフィックの制御は Istio、Consul、 Linkerd とのインテグレーションを提供しています。
ほーん
.... よくわからんかった
おぉ、これは試そうと思ってたやつ。
Ingress を HTTTPProxy というカスタムリソースで表現するらしい。
Knative 用の Ingress らしい。
ほう
うちは Type LoadBalancer Service で AWS の LB で受けて、Node Port で受けて中にある Nginx に流してそこから各 Service に Proxy するというアーキテクチャをとっている。
いわゆるここの Front Proxy が将来どうなるか。Ingress を使う、Envoy を使う可能性は十分あると思う。
例えばこの Front の部分で path base routing なり header みてどうなり、percent base で canary をやるなりするなら Service Mesh があったほうが多分楽なのかなあ。
それとも Canary とかはその先の、Istio だったら Virtual Service 層でできるのかな、多分。
いずれにしろ、今は Service Mesh Control Plane は決着がついてない状況なので、Solution Base で、最小の構成で試して価値を出しつつ、学んでいきたいと思う。
Knative はどうなんだろうなあ、今のところ Layer 増えるジャンっていうイメージしかもってなくて、それでどんだけ幸せになれるかピンときてないです。Platform やる側だからかな。
Active と Passive の Healthcheck があり、まぁ Passive Health check が場合によっては便利な場面があるんやなーと思いました。
Retry も重要。このへんが Application によってしてくれたりしてくれなかったりするのを Envoy がしてくれると助かるよね。
まぁ simple な retry 設定はこんな感じ
retry_on: "5xx" num_retries: 3 per_try_timeout_ms: 2000
ふむ。
それぞれ default 値がある。 per_try_timeout_ms は retry のときの timeout, default は通常の request のときの timeout。
リトライを設定するときには呼び出し側がどのようにリクエストするかを考慮する必要がある。
parameter としては timeout_ms , per_try_timeout_ms , num_retries とある。 per_try_timeout_ms * num_retries は timeout_ms を超えられない。retry ははやめに fail させたほうがよい。
また、global timeout がない場合で、timeout も長く retry がある場合はパフォーマンスは大きく低下する。このような高ファンアウト処理は retry をするべきではない。
最後に、retry と合わせて circuit breaking を同時に設定したほうがいい。retry は cascading failure を招きかねない。それを防ぐためにも必要。
このへん、最終的にはチューニング必要なんだなと思いつつ、前提としての考え方はめっちゃ重要だと思った。
もう10日も過ぎてしまっている。
1月いっぱいかなり忙しくて、よーし2月はゆっくりする！生活をする！となったはいいが、それはそれでいろいろ行き先迷子になってしまったので、せめて短期的に、今月何するかだけ羅列しておく。
