ツナワタリマイライフ

日常ネタから技術ネタ、音楽ネタまで何でも書きます。

生きているだけでえらい

4月が終わった。

自分の人生で好きなことは4つあって、好きなひとと会うこと、旅に出ること、本を読むこと、お酒を飲むことで、そのうち半分がコロナで消えてしまい、メンタルに支障をきたしていた。

仕事そのものは特にリモートでも問題なく、意図したものも意図してないものもあるが、チーム内のコミュニケーションに関しても以前より増えている。まぁそれとは別にオンラインラーニングの需要が高まっていてSite Realiabiltiy 担当としては非常にカオスな状況ではあるのはそれでしんどいけど。

あとは自律神経のバグりかたも酷くて、もともと夜遅く作業することも結構あったんだけど、通勤がなくなることでそれが酷くなって、22時−2時とかに気絶してしまいそのあと眠れない、そして昼眠くなるみたいなことになっていた。そのせいで、もはや惰性となっていてよくなかったのではあるが、英会話を DMM の1日の最終の時間(25:30)にすることが多かった状況だったので、英会話自体もできなくなってしまった。短期間で築きあげた習慣や生活は崩れるのも一瞬だ。

なんとか自律神経バグに関しては後半には修正することができた。太陽を浴びる、太陽が出てる時間にジョギング、夜お風呂に浸かって読書、そして何より"がんばらない"こと。

今月は徹底的にがんばらないと決めた。せっかく続けていた英会話も、上記の事情もあったが、正直伸びが逓減していたのもあったので思い切って休会した。仕事も、仕事に必要な勉強も、とにかく生きているだけでえらいということで休んだ。

そうすると23時頃にぼーっと何もしないをしていると、お風呂につかって副交感神経が優位になっているからか眠くなり、そのまま一度朝方4時とか5時には起きつつも、二度寝したり。あるいは5時に起きて早朝の6時から9時に作業して、みんなが起き始める9時−11時とかをジョギングや風呂の時間にしたりなどすることで、つまり生活のリズムを正しくし、仕事の時間を他のメンバーとずらすことで仕事を効率的に進められるなどのメリットも見えてきた。

一方で、Stay Home な"生活”をなんとか辛抱することはできても、生きている意味を失いつつあり、いまや仕事と食事しかない。なんとかプライベートで会話できる友人と少なくない時間ビデオチャットをすることでなんとか生きる意味をつないでいる。

正直本音で言うなら「接触」を気をつけてること、自衛を気をつけること、免疫を高めること、などを気をつければ外出していいんじゃないの?と思っている。一方でこれを社会に政府がメッセージとして出すとカオスになり感染拡大するのもまたわかる。旅がしたい。まぁ1人で旅をしてもなんだかんだひととは接するので、やはりよくないといえばそうなのだろう。

趣味で半年ほど前にはじめたカメラも、もともとひとが好きで、ひとを撮るのが好きではじめたこともあって、その機会が事実上消滅してしまい一切の興味がなくなってしまい、これまたお金の使い先もなくなってしまった。グッバイレンズ沼

そして登山も。これからは毎週登るぞと友人に触発された矢先にこの流れだったので結局行けていない。ソフトウェアエンジニアリングという意味ではインドアだが、(そしてそれはプライベートと言えなくもない地続きな存在ではあるが)プライベートでは自分はアウトドアだったのだなと実感する。

じゃあ家でたくさん飲酒してるのかというと意外にそんなこともなくて、そんなに量は飲んでいない。もともと依存症だと思うので毎日飲んでいるのは変わらず、でも外で飲んでた分がまるまるなくなり、家で飲んでた分も特段増えていない、むしろ減っているかもしれない。酒に関してはもちろん酒の味そのものもおいしくて好きだけれど、やっぱり酒とともにあるひととの会話が好きだったりして、その楽しさが飲酒量を増やすという側面はあったのだろう。まぁこれからの在宅、量より質を極めていくのは悪くないが。

こうやって結構自分はダメージを受けているし、この状況が1年や2年続くことにも絶望しているが、人間の適応能力はすごいものなので、これがまた当たり前になって、なんとか生きていくのだろうとは思う。

家にいる良い点としては、ひたすら部屋が片付いていき、収納の工夫を少しずつ進めているのはいい点だ。自炊をしているのもあり、キッチンまわりの収納をはじめて工夫したりしている。この家にはもうすぐ4年で6月に契約更新だが、在宅中心になった今、特に引っ越すインセンティブがなくなったのでもう2年更新することに決めた。まぁ部屋の快適さを追求していくなら引っ越したくなるのいかもしれないが、とりあえずは。

そういえば4月の前半は左手首が痛かったんだが、キーボートとリストレスト、MAgic Trackpad、PC スタンドを購入し、自宅での作業環境を充実させると驚くほどになくなった。良質なキーボードというものは偉大だし、リストレスト以外は会社の補助で購入できてありがたいばかりである。

さて頑張らないといったものの、いつまでも頑張らないままでいるのもそれはそれで死と同義なので、5月は少しがんばりを再開しようと思っている。それは別のエントリーで書こうと思う。

HashiCorp Certified: Terraform Associate を取った

はじめに

とった。多分日本人初。

  • 試験は問題、試験官との会話ともに英語
    • まぁわかんなかったら chat できるから大丈夫
  • 受験は自室等からどこでも。
  • Exam を Purchase(77USD ぐらい)したあと、任意のタイムスロットを予約する
    • どうも PDT あたりのタイムゾーンでの活動時間が選べたよう
    • というわけで 2020-04-22 JST 23:30 から受けた
  • 部屋に1人だとか机がきれいだとか受験のルールはここにのっってる Online proctoring: Candidate portal FAQ | Questionmark
    • 試験は Question Mark という外部サイトで行われる
  • スケジュール登録すると案内のメールがくる
    • ちなみに初回登録遺jにはこなかったので一度キャンセルして再登録したらきた
    • キャンセルはペナルティはなし
  • 基本的には選択かテキストボックスに入れる形式で、問題形式はここにある通り。長い記述なんかはない。Sample Questions - Terraform Associate Certification | Terraform - HashiCorp Learn
  • 15分前になるとメールで送られてくる url から試験管に接続できる。ほぼジャストぐらいに入ったが5分ぐらい待たされた
    • つながると zoom が起動する。試験は zoom で行われる
  • 最初は身分証明書(パスポートか運転免許書)の提示、ディスプレイ切ったか、部屋やデスクをカメラで確認などして、同意項目みて同意するみたいなんをする
  • 試験は60分だが、まぁ25分ぐらいで終わった
  • 終わるとすぐに結果が出る。なんと結果はは70% て pass ボーダーラインは不明。ギリだったかもね。
    • 体感は 85% ぐらいいったと思うんだけどなぁ
    • なお分野別の正答率は開示されるが、どの問題が間違ったかはわからない
  • 事前勉強は馴染みのない Terraform Cloud のところ Understand Terraform Cloud and Enterprise capabilities Review Guide をみた Exam Review - Terraform Associate Certification | Terraform - HashiCorp Learn
    • あとは Accociate やしまぁいけるやろうと踏んだ
    • 結果ギリ
  • 終わったあと、今後の改善のためか Survey があるが、ここで採点サイトの不具合で Next button あ表示されずオペレーター刃盥回し、待たされまくりで40分ほど余計2時間を使ってイライラした

まとめ

今はあんまりオススメしないかも。とりあえず試験までなら問題なくいけると思うが、ちょっともろもろの試験のための Web サイトが不安点がチラホラ見える。 難易度は Associate としては妥当。一応2年仕事で terraform 使ってる人間であれば Cloud や Enterprise のところだけ抑えれば突破できる 一方初級者がこれをクリアするのはそれはそれで難しそうなので、この試験対策が基礎の勉強になるみたいになればいいねと思った まぁ AWS の Associate みたいな感じなんじゃないかなあ(AWS 資格受けたことないから知らんけど。。。) ドヤ顔するためのバッヂは10日以内に届くらしい。はよ。

結果

といいつつギリギリ(ボーダー知らんけど)というていたらくである。まぁダメでもともとの人柱チャレンジだったので。。。通ってよかった。

f:id:take_she12:20200423030023p:plain

Learn Envoy - Incremental Blue/Green Deploys

www.envoyproxy.io

ゆっくり読んできたが実は最後である。

  • header based routing で、header をみてこっちに流す、みたいなことができる例
  • Weighted Load Balancing の例。そのまんま、割合に応じて流す cluster を振り分けられる
  • Best Practice: deploy と release を分離すること
    • CI/CD によって Deploy はするが、(その新バージョンのアプリには)トラフィックを流さない、というアプローチをとる
    • これにより、徐々に / Gradually に試すことができるし、もし障害があっても影響を少なくし、ロールバックを簡単にできる
  • Header based routing を行うことで、Production 環境でテストができることも意味する

おわりに

ujihisa さんすごいなあと思いました。

www.youtube.com

4月

3月やりたかったことはあんまりできてない。途中から本格自粛になっちゃったねえ。できてないことと関係ないけど。

あんまりやっていくことが定まらない。どこに向かうべきかちょっと見失ってしまった。英語もゾンビ英会話は続けてるし仕事でもちょいちょい英語ミーティングはあるがモチベーションを失いつつある。

4月は次の1年の方向を定める月としたい。

1年後に転するつもりで(するとは言っていない)いろいろ考えたい。カジュアル面談はぼちぼちしていきたい。少なくとも1年以内はないという前提でよければ keep in touch カジュアル面談声かけてください。

いのちだいじにしつつ、少しずつ、少しずつ。進む速度より進む方向をていねいに考えたい。

Envoy の Trafic Mirroring による負荷テストを考える

弊社には以前 Shadow Proxy というものがいた。

qiita.com

当時のモチベーションとして 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 と通信している。

docs.mongodb.com

Cluster を Load Balancing しているのは Primary と Secondary Node である。

さて、このような状態でどうするか?複数の Cluster を定義し、Mirror したものを別の Cliuster (Atlas) に送り、レスポンスは棄却する、ということがやりたい。

request mirror policies が使えそうだが、これは http だ。

www.envoyproxy.io

残念ながら TCP Layer でこれらは実現できそうにない。

Envoy Slack で "The upstream envoy filter is only for http right now" という回答を得た。やむなし。

とすると http でやるしかない。

こういう例。

blog.markvincze.com

どこでミラーするのかあらためて考える。

f:id:take_she12:20200404104139p:plain

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 を使うことになるだろう。

こうなる。

f:id:take_she12:20200404105626p:plain

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]

何が問題になりそうか

  • 外部サービスもすべて同様に用意する必要がある。Redis とか PostgreSQL とか。めんどい。
  • Mirroring をはじめるタイミング。どこかでうんしょと MongoDB のデータを同期した状態からはじめる必要があるが、Production のデータは常に変わりはじめるので、完全に同期はできない。そのためデータ不整合等のエラーが出る可能性は高い。割り切るしかない?

良い点

  • 何より現実のトラフィックと同じものを用意できる点。なんだかんだ自前で負荷テストをやろうとすると Application の知識も必要だし、「これは本当に実際の負荷を再現できているのか?」という永遠に解決しない悩みと向き合い続ける必要がある。それがなくなる点が大きい。
  • Kubernetes Cluster を別に作る必要がない点。単純に Deployment が増えているだけなので、下の Node が Cluster Autoscaler で倍増するだけのはずだ。
  • 段階的に試せる。ミラーリングはパーセンテージを指定できるので、最初は 1% とかで、本番リソース全体を枯渇させる、みたいなリスクを回避できる。

次回は具体的にどういう config でやるのかを試す。

LEARN ENVOY - Back Pressure

www.envoyproxy.io

Envoy を使えば rate limiting, retries, timeouts を実装しなくて済むようになります。この記事では client が障害と backpressure をどう扱うかを示します。

A Guide to Envoy’s Backpressure

まぁだいたいは Envoy での設定(rate limiting, retries, timeouts)でなんとかなるが、失敗し続けた際にどう振舞うかを client に実装する必要がある。

Envoy Failure Modes

へー。Envoy が Downstream(client)に、それらが失敗したときに返却する一覧。

  • Rate Limiting Failure: 429 を返す
  • Timeout Failure: 504 を返す
  • Empty Cluster: 503 を返す
  • Unresponsive Upstream: 503 を返す
  • Circuit Breaker Failed Open: 503 を返し、x-envoy-overloaded: true header をつける。
  • Maintenance mode:503 を返し、x-envoy-overloaded: true header をつける。
  • Domain or Route not found: 404 を返す
  • Upstream Connection Closed: downstream がデータを受信しはじめたかによって、reset か 503 になる
  • Envoy is Overloaded: エラーなしでコネクションがブロックされる

おわりに

Back Pressure って問題起きた時に Envoy が Downstream に何を伝えるかって意味だったのね。

まぁでもどういうレスポンスコードが帰るかを知れるのは有益だった。

「KnativeとIngress Gateway」メモ

techbookfest.org

Knative

  • Serving
    • Revision
    • Configuration
    • Route
    • Service(Kubernetes の Service とは違う)
  • Eventing
    • Sources
    • Broker

この時点ではよくわかんないけど、Kubernetes の上に Gateway 層(Istio とか他) がいて、その上に Knative がいるようだ。

Gateway

  • Ingress は L7 Load Balancer
    • Type LoadBalancer Service や
    • Type NodePort Service もクラスタ外に公開するが

Knative が利用する Gateway というのは Envoy とかでよく説明される Front Proxy - North / South traffic のこと。この手段がいくつかある。

  • Ambassador
  • Contour
  • Gloo
  • Kourier
  • Istio

いずれも Envoy を Proxy に利用している。

その代表として Istio の説明。

Istio

結局イマイチ Knative いれるのになんで Istio(Gateway?)がいるのかがよくわかってない。

Typo をみつけたけど PR 投げられない。

3.5 Istio のコンポーネント つぎは主要なコンポーネントのインストールです。ここでは Helm を使って kubectl で apply する YAML ファイルを生成して apply います。

Istio で gateway つくって、それを外部から Knative に流すためにいるんかな。そのために Istio はヘビーじゃない?と思うが。

Ambassador

基本的に north-south トラフィック を制御するためのプロダクトです。east-west トラフィックの制御は Istio、Consul、 Linkerd とのインテグレーションを提供しています。

ほーん

.... よくわからんかった

Contour

おぉ、これは試そうと思ってたやつ。

Ingress を HTTTPProxy というカスタムリソースで表現するらしい。

Kourier

Knative 用の Ingress らしい。

Gloo

エンタープライズ版の API Gateway

ほう

おわりに

うちは 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 やる側だからかな。