Posts for: #Operation

また podman に苦戦する

23時に寝て何度か起きて7時に起きた。出張帰りでなんかバテててなにもせず休んでいた。少し喉に引っかかりがある。出張で飲み歩いたし、そろそろコロナ感染?の疑いをもって生活してみる。

podman と dbus-daemon とsystemd の調査

2次開発の成果物をドッグフーディングの目的で社内へ導入する。メンバーが作業していて nginx が正常に動作しないという。ログをみろとすぐにコンテナネットワーク内の dns サービスが正常に動いていないということはわかった。podman は aardvark-dns というサービスを使って dns を管理する。但し、このサービスがまだまだ安定していなくて不具合があるのを以前にも確認した。このサービスの振る舞いがよく分からなくて、意図しない状況や状態に対して正常に動作してくれない。

他にも調査をしていて rootless で podman コマンドを実行すると次の issue で書かれているようなワーニングが出力される。dbus-user-session というパッケージを導入すれば解決するとある。

dbus-daemon のサービスは systemd で動いていて、systemd のユーザーモードと dbus が正常に動いていないというところまではすぐに分かった。その状態だと rootless な podman が正常に動作しないということもすぐに分かった。ここまではすぐに調査できたが、問題はどうやれば sytemd のユーザーモードを dbus を正常に動くように復旧できるのかがまったく分からない。systemd がそもそも難しいのに、そのユーザーモードは権限管理が関係するのでさらにもっと難しい。1日調べてお手上げで他の社員さんにも相談してみた。

今日は自分の作業は進捗しなかったけど、メンバーの作業の進捗をみていて、メンバーがはまっていたところを助言して、その問題は解決してうまくいって、それだけで満足していた。

最後は人のチカラがモノを言う

2時半に寝て寝たのかどうかよく分からないながら5時頃に寝落ちして7時半に起きた。

差分比較のための機能

id 連携で運用のための非機能要件の1つとして更新された内容を確認できるようにしたい。非機能要件だから私が作るかと思ってあたためておいた issue に着手した。wikipedia によると差分という言葉には次の2つの用語があるのをみつけた。

数学やコンピューターの用語的には delta (ギリシャ語で変化を表す) という言葉を使う。os のパッケージングシステムで一部のパッケージをアップデートするようなことをデルタアップデートと呼ぶ。一方でコンピューターサイエンスにおいて2つのデータセット間の差分については diff という用語を使う。データの差分においては diff でよいのではないかと思う。そういった用語の定義から始めた。mongodb のコレクションのデータ定義をしたり、結合テストを書いて動かしてみたり、インフラのレイヤーから開発に着手した。

上司道 企業家として生き様と、人として求められること

第92回上司道 企業家として生き様と、人として求められること に参加した。なんとなくタイトルに惹かれた。上司道 に参加するのは3回目。

講師の牛島さんは昨日が誕生日だったらしく90歳だという。90歳になって zoom でオンライン勉強会の講師を務めるというのを、私はまったく想像できないけど、コンサルタントの第一線で活躍されてきた方の貫禄があった。もともとどういう主旨の勉強会だったのかよく分かっていないけれど、内容はビジネスの自己啓発セミナーに近いものになった。牛島さんが90年も生きてきて大事だと思える内容には普遍性や汎用性があるのだと思う。いくつか共感できる考え方もあった。

  • これからは頭の良い人 (IQ が高い) よりも心が豊かな人 (EQ が高い) の方が大事で組織に貢献する
  • 一番大切なのは幸せであること
  • 楽しく生きる (働く)

過去に働いた会社でも頭がよくて何でもよく理解しているのにプロジェクトにあまり貢献しない人がいることに気付いた。さぼっているわけでもない。その違いを「心が豊かな人 (EQ が高い) 人」という言葉でいくつか説明できるのではないかと思えた。新規プロジェクトのような、常に変化して、正解もわからないまま進める業務において、論理や頭のよさだけでうまくいくことはなくなってきつつあるのではないか。なんのためにそのプロジェクトをやるのか、自分はなぜここで働いているのか、といった問いに答えをもっている人は普通の社員とは行動が異なる。自身の価値観や展望と比較して、現状の課題や改善に気付くのでプロジェクトを前向きに進めていける。頭のよい人は「あれが問題」「これが問題」と問題を指摘してエスカレーションするだけで自らが課題をどう解決するかの答えをもっていない。そんなことを考えながらこの話しを聞いていた。

次の2つは最近の私の人生観や働き方と重なるところがある。私はもう無理してがんばったりしないし、自分が嫌なお仕事も一切しないように決めている。一般的にいう「働きたくない」という生き方を目指している。もちろん実際には働いているわけだけど、それはなるべく働く時間を、遊んでいる時間に置き換えられないかと模索している。その過程で辛いことやしんどいことも避けようと考えている。

なぜそれができるかというのも、20代30代と約20年働いてきて自身の価値観を育ててきたからだと捉えている。私はなにが楽しくて、なにが辛くて、なにをやりたくないか。これは人それぞれに違う。私には私にしかない価値観をもっている。それがわかってきたから、いま自分の会社を経営していて、毎日がとても楽しいし、自分の価値観にあわないことはすべて断るという判断基準も明確になっている。そんな勝手気ままでやっていけるの?という懸念を抱く人も多いと思う。ダメかもしれない。仮にやっていけなかったとしても、いまの自分は幸せで楽しいのだからそれでいいんじゃないかと思う。無理をしていまがしんどくても将来がよくなる保証なんてどこにもない。

牛島さんはマザーテレサとインドで実際に会って10日間ほど一緒に過ごしてその体験がその後の人生を大きく変えたように話されていた。マザーテレサに「社員を大事にしていますか?」と聞かれたときに「しています。」と答え、その後に「社員全員の名前を覚えていますか?」と聞かれたという。当時の牛島さんの会社の社員は300人以上いて全員は覚えていなかった。それで「愛情の反対は無関心なのですよ。」とマザーテレサに指摘されて大きな衝撃を受けたという。その後、帰国してから300人以上の社員全員の名前を覚え、日々の業務で社員の行動などに気を配ってすべての社員に声をかけたりするようになったという。このエピソードもなかなか私には効く話しで、私は他人にかなりのレベルで関心がない。もし自分の会社で社員を雇うことになったら待遇がどうとか以前に、その人そのものに関心をもつという姿勢を覚えておこうと思う。

1行のミスによる1行の修正

0時に寝て何度か起きて6時半に起きた。朝から外はめっちゃ暑い。冷房をつけっぱなしのオフィスも朝からやっぱり暑い。根本的な空調の問題。

agent アプリケーションのメモリリーク正体

先週のメモリリーク調査 の続き。本当は週末にやればよかったんだけど、遊んでたりさぼってたりして放置してた。先週時点でリークしているのは go-zeromq/zmq4 側だというのはわかっていたが、何が原因でリークしているのかは分からなかった。一通りソースも読んでみたけど、いまひとつよく分からない。仕方ないから動的デバッグでソースコードに手を入れながら調査していて、すぐにみつけた。socket 構造体が保持しているコネクションの map がどんどん肥大化していく。なにも使っていない map にコネクションの値を保持して解放する処理がないことに気付いた。

sck.ids[uuid] = c

修正するかと思ってリポジトリの最新ブランチをみてもそのコードが見当たらない。すると次の pr で4月に修正されていた。まだリリースされていないからうちらのアプリケーションで使っているリビジョンにはその修正が含まれていなかった。

Additionally, remove sck.ids, which is unused and leaks *Conn.

メモリリークの調査を始めたときに github issues/pr を leak で検索して一通りチェックしているので、先週もこの pr をみかけているはずだが見逃してしまった。タイトルが全然違うし、ほんの1行の typo に近いミスなので修正内容をみて気付かなかったのだと思う。自分の観察力の無さに気付いた。leak で検索ヒットしているのだから、それが自分たちのアプリケーションで使っているコードに入っているのかどうか、その内容をもっと注意して調べるべきだった。そうすればこの調査時間を数時間は短縮できた。これは私のミスだと認めて Postmortem のラベルを付けた。次回の定例会議でふりかえりに使う。

メモリリークに遭遇

23時に寝て何度か起きて5時に起きてからだらだらネットしながら記事を読んだりしていて7時に起き上がった。

agent アプリケーションのメモリリーク調査

qa テストの一環として先月からテスト環境で毎分 agent アプリケーションにリクエストを投げる長時間稼働テストを実行している。なんとなく気になるところがあったからやったわけではあるけれど、長時間稼働テストによってメモリリークを検出できてしまった。自分を過信せずちゃんと検証しないといけないなと思えた。top コマンドの実メモリー (RES) を1ヶ月前と比較して増えているからメモリリークだと気付いたところ。これからメモリプロファイリングをしながら原因を追求していく。私が書いた (レビューした) go のコードでメモリリークはないだろうと高をくくっていただけにちょっとショックではあった。

go は標準ライブラリに pprof というプロファイラがあるので簡単にデバッグできる。プロファイラで昨日から調査していたところ、go-zeromq/zmq4 の処理でメモリリークしていることはわかった。それがライブラリの使い方が誤っているのか、潜在的な不具合なのかはまだこれから調査するところ。

ライブラリ側の問題を調査するので厄介ではあるけど、私が書いた (レビューした) go のコードでメモリリークしているわけじゃないことがわかって少しほっとした。

go の generics 勉強会

先日準備した資料 を使って勉強会を開催した。

この勉強会はある意味、うちのチームのメンバーが理解しておくべき内容なので go のプログラミングをやっていないメンバーが聞いてもあまり関心をもてない内容となっている。そういうお断りもした上で最悪2-3人ぐらいの参加者になるかと思ったもののプログラミングに関心がある人たちは参加してくれて5-6人ぐらいの規模にはなった。一方で内容も難しいし、私の説明がどれだけわかりやすかったか、私自身にはわからないのでなんとも言えない。質問も一切なかったので喋りきって疲れたという疲労感と、伝わったのか伝わらなかったのか分からない消化不良感と、金曜日だから今日はもういいや感でどっと疲れたというのが率直な感想になる。

とはいえ、私もずっと generics の仕様をちゃんと追いかけたいと思いながら先送りしていたものではあるので私の中では自分が go の generics の理解度をあげて実際の開発の中で使い分けるだけの判断基準をもてたことが収穫だったと言える。

厄介なインフラ問題をやっつけた

2時に寝て6時に起きて7時に起きた。夜に作業していたら遅くなった。

厄介なインフラの問題 解決編

運用のトラブルシューティング の続き。アプリケーションアカウントを作って compose 環境を構築したら nginx のコンテナが起動して即時終了する状態になったという。これまで起きていた現象とまた違う問題が発生してさらに混迷をもたらすかに思えたが、私の中では nginx のコンテナでなにかがおかしいと問題の発生箇所を局所化できたのでそこからの調査はそんなに時間を必要としなかった。

結論からいうと podman の aardvark-dns の不具合だった。なんらかのトリガーでコンテナネットワーク内の名前解決が不整合な状態に陥る。

vagrant@bookworm:$ podman-compose exec proxy /bin/bash
...
root@3742c45c7c60:/# dig app

; <<>> DiG 9.16.37-Debian <<>> app
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56696
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 8, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 37ff0fd63315d70e (echoed)
;; QUESTION SECTION:
;app.				IN	A

;; ANSWER SECTION:
app.			86400	IN	A	10.89.0.36
app.			86400	IN	A	10.89.0.36
app.			86400	IN	A	10.89.0.136
app.			86400	IN	A	10.89.0.136
app.			86400	IN	A	10.89.0.146
app.			86400	IN	A	10.89.0.146
app.			86400	IN	A	10.89.0.156
app.			86400	IN	A	10.89.0.156

;; Query time: 4 msec
;; SERVER: 10.89.0.1#53(10.89.0.1)
;; WHEN: Thu Jun 22 02:45:26 UTC 2023
;; MSG SIZE  rcvd: 172

podman 4.0 から aardvark-dns がコンテナネットワーク内での dns を提供する。nginx が app を名前解決したときに起動しているコンテナの ip アドレスではなく、削除された過去のコンテナの ip アドレスが返される状況が発生する。app という名前に対して複数の ip アドレスが返る。

このとき nginx は複数の ip アドレスのうちの1つに接続しようとするが、正しい ip アドレスでない場合、リクエストがタイムアウトする。タイムアウトした後に fallback で他の ip アドレスに接続しにいく。このときに正しい ip アドレスがみつかればクライアントにレスポンスが返る。この fallback のリトライの回数分だけリクエストのレイテンシの時間がかかっていた。

vagrant@bookworm:$ podman logs -f proxy
...
2023/06/22 02:46:26 [error] 15#15: *41 connect() failed (113: No route to host) while connecting to upstream, client: 10.89.0.38, server: ucidmsv1-app, request: "GET / HTTP/1.1", upstream: "http://10.89.0.136:3000/", host: "localhost:4430"
2023/06/22 02:46:29 [error] 15#15: *41 connect() failed (113: No route to host) while connecting to upstream, client: 10.89.0.38, server: ucidmsv1-app, request: "GET / HTTP/1.1", upstream: "http://10.89.0.156:3000/", host: "localhost:4430"
2023/06/22 02:46:32 [error] 15#15: *41 connect() failed (113: No route to host) while connecting to upstream, client: 10.89.0.38, server: ucidmsv1-app, request: "GET / HTTP/1.1", upstream: "http://10.89.0.136:3000/", host: "localhost:4430"
10.89.0.38 - - [22/Jun/2023:02:46:32 +0000] "GET / HTTP/1.1" 200 2864 "-" "curl/7.88.1"

ワークアラウンドとして、次のファイルに複数の app の ip アドレスが登録されていれば不整合な状態なのでネットワークを削除して、このファイルも手動で削除してしまえばよい。

$ cat /run/user/$(id -u)/containers/networks/aardvark-dns/mynetwork

ファイルを監視していると、どうやら mynetwork ファイルから名前と ip アドレスの情報が削除されるのは該当のコンテナが削除されるタイミングになる。なんらかのエラーにより、コンテナ削除時にマッピングの削除が実行されないと、古いコンテナのマッピング設定が残ったままとなり、compose サービスを起動したときに複数の ip アドレスの名前解決できる状態になってしまう。ちょっと調べても aardvark-dns に関する issue はたくさん登録されている。

コワーキングのオンラインイベント

月例のカフーツさんのオンラインイベントに参加した。先月の所感はここ 。今日はもともと予定していた話しをする参加者が急遽参加できなくなってしまったので他の参加者での雑談会になった。

いとうさん曰く、これまで外国人のデジタルノマドは自分で業務時間を選べるフリーランスの、さらにお金に余裕をもった人たちが多いと考えられていた。しかし、実際にコワーキングスペースに来られている外国人にキャリアを伺うと、大企業の普通の社員であることがわかってきた。グローバルな会社だと、働く場所に制限のない会社もあって、ただ日本へ行ってみたかった的な理由で日本へ来られて数ヶ月滞在して普通に会社のお仕事をするといったデジタルノマドもいるという。過去に私が働いていた職場の同僚も、コロナのときに会社がフルリモートワークの体制を設けて、airbnb で全国を旅しながら1年ほど働いていた。日本でもそういう社員はいるのだから外国人はなおさらという感じ。

そういった外国人のデジタルノマドが要求することが3つある。

  • 24時間利用できること (勤め先の会社と時差があるから)
  • セカンドモニターがあること
  • ・・・ (あともう1つあったが、忘れてしまった)

コワーキングスペースに外国人のデジタルノマドを呼び込むにはどうすればよいか。実際にコワーキングスペースへ来られた外国人に理由を伺うと英語のホームページをみて来ましたということらしい。至極、当たり前の話し。英語のホームページをちゃんと作ろうねみたいな話題で話していた。

運用トラブルの調査

0時に寝て5時に起きて7時に起きた。もう暑くて家でもエアコンを解禁した。エアコンがあると寝心地が違う、快適。

運用のトラブルシューティング

厄介なインフラの問題 のクリティカルな方から着手し始めた。podman-compose を使って rootless な環境構築をやってみたところ、nginx を tls 終端としてリバースプロキシとするアプリケーションサーバーとの通信が数回に1回ぐらいの頻度で遅くなる。通常は 100msec 程度でレスポンスが返るのが数秒から数十秒かかる。

もともと podman-compose はサポート対象外なのでそんながんばる必要はない。しかし、これも調査の過程でコンテナの技術を学ぶ1つだと考え再現環境を構築しようとした。vagrant の debian 12 と podman-compose をインストールして同様に環境構築してみたが、仮想環境では再現しない。どうやら環境要因のようだ。そこで問題が発生しているマシンで私のアカウントで環境構築してみたが、やはり再現しない。なんと個人アカウントの違いによって起きる現象のようだ。また質が悪いのは私のアカウントでは再現しないが、メンバー2人のアカウントでは再現している。一般ユーザーから他人のユーザーのプロセスやコンテナの情報にアクセスできるわけがないので調査ができない。個人アカウントで compose 環境を構築するのは諦めてアプリケーションアカウントを作ってやりましょうという話しにした。アプリケーションアカウントで再現すれば調査するし、再現しなければこんな環境要因のトラブルシューティングの優先度を下げてもいいかなぁとも考えている。どうなるかなぁ。

サイトデザインのサンプルページ

サイトデザイン打ち合わせ の続き。実際のサンプルが出てきたのでデザインの雰囲気やコードも含めて確認していく。ざっとサンプルページを確認した。デザインはとても気に入っている。あとは私が hugo のテーマとしてテンプレートの組み込めるかどうか次第。今週末には実家帰らないといけないし、毎日やることがいっぱいいっぱい。

簡単な現象の組み合わせ障害

0時に寝て6時に起きた。

eks クラスター障害の原因判明

過去に2回発生していた eks クラスター障害 の原因がようやくわかった。テスト環境も本番環境は5日ごとに再現していて、datadog で k8s のダッシュボードでそれぞれの pod 単位のメモリ使用量をみると datadog-agent の pod がメモリリークしていることに気付いた。そこから当たりをつけて datadog-agent の issue を調べると次のバグに遭遇していた。

ゾンビプロセスが生成されて、それが os のプロセス数上限に達してしまい、それによってプロセス (スレッド) が生成できなくなって、その結果として aws/amazon-vpc-cni-k8saws-node という eks クラスターの管理アプリケーションが動かなくなって、それが動かないと k8s ノードのステータスが NotReady になってしまって、通常の pod のアプリケーションも動かなくなってしまうという現象が発生していた。datadog-agent のアップグレードは私が行ったものだし、その後の k8s ノードの監視や調査で気付きが足りなかったと反省した。

  • datadog-agent の新しいバージョンをテスト環境でもうしばらく検証してもよかった
  • datadog-agent をリソースリークの可能性を私の中の調査対象から外していた
    • 世の中で使われているものに致命的なバグが起きないだろうという先入観があった
  • プロセスを生成できない原因として考えられる背景を調査すべきだった
    • ulimit を確認してリソース制限はないようにみえた
    • プロセス数やゾンビプロセスを調べていなかった
    • kernel に /proc/sys/kernel/pid_max という上限設定があることを知らなかった
  • テスト環境と本番環境で5日程度で落ちるという周期性から気付くべきだった
    • たしかにテスト環境から1日遅れて本番環境で障害が発生していた
    • 周期性があることでリソースリークの可能性は高いとすぐに調査すべきだった
  • datadog で k8s のダッシュボードを調べるべきだった
    • すでに用意されているものがあったのでみようと思えばみえた
  • aws のインフラ要因ではないかと疑っていた
    • ごめんなさい

これは悔しい。自分の無能さや気付きの低さを実感した事件だった。私が注意深く観察していればもう1週間早く気付けた。そのせいで余分な障害と調査に時間を費やした。1つ1つは全く難しくない現象が巧妙に絡みあって隠蔽された結果としての状況に気付けなかった。注意して1つずつ観察して追跡していけばすぐに気付けた。本当に悔しい。

1つだけ言い訳をさせてもらうと、私は本番環境にアクセスできない。だからテスト環境と本番環境で発生している現象が同じかどうかを判断できず、調査を進める確証をもてなかった。

呑み

あまりに悔しかったのと調査してたら遅くなって晩ご飯食べる気力もなかったので気分転換に仲のよい焼き鳥屋さんに寄ってみた。あとから常連客のセブンイレブンの店長さんも来られて、私は初対面かなと思ってたんだけど先方は知っていると言ってたから以前にもカウンターでご一緒していたみたい。何気はなしに3人で2時前ぐらいまで雑談していた。

その店長さんがロレックスを購入しようと考えているという話しになって、資産または投資商品としてのロレックスの話しになった。たまたまヒカキンが1億円で買ったロレックスがいま2億円になっているといった話しがあったそうで、いまがバブルな状態らしいが、ロレックスをはじめとした高級時計の資産価値が上がっているらしい。私は腕時計を身につけないし高級時計もまったく興味はないが、投資商品の1つなんだというところに関心がもてた。

中小企業の社長の一般的な節税方法の1つに外車を買ったり売ったりするという話しがある。儲かったときに経費で外車を買って、赤字のときに外車を売って雑所得に変える。車は社用車として経費で落とせるから可能なことだが、高級時計はどうなのだろうか? 結論から言うと、普通の会社では高級時計は経費にできない。経費の原則は売上を上げるために必要な支出を経費とできる。普通の会社は高級時計で売上を上げることはできない。一方で経費として認められる職業もある。芸能人がそうだという。それは番組のために必要だという理屈で経費で落とせる。おそらくヒカキンも経費で高級時計を購入して、そのことを動画にしているのも仕事で必要だという言い訳作りの目的もあるのだと推測する。

vuejs の template 調査

0時に寝て6時に起きた。

連日のサービスイン作業

引き続きサービスインの運用対応は大変そうでちゃんと検証していない修正を慌ててマージしようとしているからテスト環境まで壊れてて関係ない開発にも影響が出ていた。今日も別の施設のサービスインだったらしくて、ある機能がないとそのサービスインの切り替え作業ができないという話しだったそうで、当日に慌てて pr を作ってマージしてた。先週からわかっていた必要な機能を実装してなくて、週末は残業も休出もしてなくて、今日になって慌てて修正してマージしてた。昔の開発と比べてがんばっててできないのではなくて、いまの開発はがんばってないからできないという雰囲気になったなという印象。

vuejs の template と expression

あるフォームのコンポーネントを作ろうと思って interface を定義していてデフォルト値をテンプレート側に指定できるといいんじゃないかと考えた。というのは typescript の interface のメンバーは値を保持できないから。例えば、次のようなコードで :cols="item.col ?? 2" のように表現できたら嬉しいように思う。

<v-row dense v-for="item in conditions" :key="item.label">
  <v-col :cols="item.col ?? 2">
    {{ element }}
  </v-col>
</v-row>

余談だけど、?? は null 合体演算子という名前は知っていたけど、これを英語で何と呼ぶのか知らなかった。Nullish coalescing operator と言う。ググってみると vuejs の issue でもそこそこ議論されていて vue3 からサポートするとしながら、根強い要望があるのか? vue2 でも 2.7 でサポートしたらしい。こういうモダンな javascript の expression を ESNext syntax と呼んだりするみたい。それすらも知らなかった。

たまたまうちで使っているのは vue 2.6.14 なので vue 2.7 で動くのかどうか検証できないけど、いま使っている nuxtjs2 との依存関係があるのでそれ次第で vue 2.7 にアップグレードの可否が決まるらしい。全然フロントエンドの開発がわからないので、こういう基本的なところで引っかかると背景を調べるのに時間がかかる。

週明けのサービスイン

0時に寝て7時に起きた。

3つ目のサービスイン

またまた私は勘違いしていて明日だと思っていたら今日が3つ目のサービスインだった。約1ヶ月ぶりのサービスイン になる。もう3回目なので要領よく切り替え作業やるのかなと眺めてたけど、新たなトラブルもいくつかあって、これまで同様、ドタバタしているようにみえる。私は本番環境にアクセスできないので何かトラブルがあっても聞いた内容から類推で助言を述べるしかできず、とはいえ、何かあったら質問がくるかもしれないからハドルに入って成り行きを見守ってないといけない。とくに手伝うこともないのにメンバーの作業が完了するまで待ってないといけない。この切り替え作業や運用対応をやっていると要件定義やコードレビューなどは放置されるのでまた作業のスケジュールが先送りになる。私は別に困らないけど、しばらくだらだらした開発が続く。

休日の本番障害

夕方から寝ていて何度か起きたものの、そのままずっと寝ていた。あまりないことなんだけど、珍しくたくさん眠れた。

ストレッチ

今日の開脚幅は開始前160cmで、ストレッチ後163cmだった。計測の仕方がややいい加減だった気もしたが、先週より少しよくなったということにしておく。右腰の張りが強いのと肩が前に入りがちなので肩を開いて姿勢を保つように心がけるとよいとアドバイスをいただいた。もう通い始めて1年半ぐらい経つ。トレーナーさんも大半が入れ替わっていて通い始めたときに話しかけてくれた私が知っているトレーナーさんはほとんどいない。1年半も経つと人は変わっていくなというのを実感している。私の最初のトレーナーさんは社内制度で別の店舗の助っ人に行っているのでいなくなった人たちが辞めているわけでもないとは思うけど、1-2年で人が入れ替わってもサービスは継続していかないといけないし、会社ってそういうものだなと実感する機会でもある。

aws インフラの調子が悪い?

1-2週間ぐらい前からテスト環境を含めると複数回発生している eks クラスターの障害 がたまたま土曜日の夜という休日に発生した。いま eks クラスターのインフラの振る舞いを把握しているのは私だけなので、気付いてから指示を出して問題が発生している k8s ノードの削除 (ec2 インスタンスの削除) で復旧させるワークアラウンドで復旧させた。私は本番環境にアクセスできないので詳しい調査はできない。状況を正しく把握できてはいないけれど、k8s ノードが死んだり生き返ったりする不安定な状況に発生しているらしく、k8s ノードを削除して新規に作り直すと復旧することがわかっている。NotReady と Ready を繰り返したりしてアプリケーションの振る舞いが不安定になる。NotReady,SchedulingDisabled になれば、おそらく drain して k8s ノードが入れ替わってくれるのだけど、そうならない不安定な状況があるみたい。これ以上の調査は aws のサポートに問い合わせないとわからない。

k8s ノードの削除方法がわからない

1時に寝て7時に起きた。寝冷えしてお腹痛い。

eks クラスターの障害

日曜日にテスト環境の eks クラスターで障害が発生していた。k8s ノードが NotReady になっていて、しばらくすると NotReady,SchedulingDisabled に変わって、それから新しい k8s ノードが起動して古いものが削除されて置き換わった。おそらくエラーが発生し始めてから1時間ほどはかかっていたと思う。わりと時間がかかるので明らかに k8s ノードが不調だと人間が判断しているなら ec2 インスタンスの切り替えを早くやりたい。k8s の公式ドキュメントの Use kubectl drain to remove a node from service では次の手順で行うように書いてある。

$ kubectl drain <node name>

drain が正常終了すれば安全に k8s ノードを削除してよいのかな?

$ kubectl delete node <node name>

eks クラスターで障害が発生していたときに drain を実行するとエラーになったのでそのまま delete node したら k8s ノードは削除されたものの、自動的に新しい k8s ノードが起動しなかった。aws のマネジメントコンソールから ec2 インスタンスを調べたら起動したままだったので強制的に ec2 インスタンスを終了させたところ、オートスケールの設定から ec2 インスタンスが起動してきて復旧した。但し、このやり方は k8s が意図した手順ではないようにも思える。軽く調べた範囲では k8s ノードの正しい削除方法 (置き換え方法?) がみつからなかった。そんなことを日曜日に確認していたら月曜日にほぼ同じ現象が本番環境の eks クラスターでも発生した。私は一度経験していたので同僚に指示して経過を観察していた。ここで書いたのと同じような手順で復旧した。おそらく aws 側のなにかのメンテナンス作業でうちの eks クラスターだと k8s ノードが死んでしまうような作業があったのではないか?と疑いをもっている。