2021-02-06

CockroachDB壊れちゃった話

概要

社内で使っていたツールのDatabaseに実験用途でCockroachDB(v20.1.3)を使っていた。構成は以下となる。

「AWS EKS1.6上にStatefuleSetで3Podで運用。StorageClassはEBS gp2（kube masterのin treeの中にある実装）のPVでデータを保存」

実はこの構成はそこそこ問題があって、Nodeの入れ替えなどでPodの再配置が起きた際に過去のPVと新しく配置されたPodのAZが一致しないとStatusがPendingになりコンテナが作られない。これはAWSのEBSがAZを跨げないためであるが、 kube1.7以降の環境でVolume Binding Modeを WaitForFirstConsumer にして、CSI Driverがいい感じであればうまく行くという説がある（参照：Storage Classes | Kubernetes）これは、あんまり興味がない点だったので認識が間違っていて嘘の可能性もある。

そんなこんなで、PendingになったPodを動かすためには以下の２通りのオペをする必要がある。

Podを削除して、過去のPVと同じAZに配置されることを祈る
PVかPVCを消すなりして、新しいPodに新しいPVが作られるようにする。

ただ、2のオペレーションをした場合はデータが消えるので、CockroachDBの新規のNodeとしてClusterにJoinすることになる。

経緯

実は詳細な原因が特定できていないので、省かせてもらうがNodeの入れ替え作業中に """いろいろあって"""Clusterが起動しなくなってしまった

以下は現在わかっていること

X日の15:00(JST)ごろに入れ替え作業をして一旦は動いていた

16:00ごろまで以下のログが出始める。

W210126 07:17:43.388615 906 server/node.go:830  [n2,summaries] health alerts detected: {Alerts:[{StoreID:2 Category:METRICS Description:ranges.underreplicated Value:11}]}

上記のWarningが出ている状態でなんらかの原因で再起動がかかり、

server drained and shutdown completed

おそらく正常に終了はしたが、他のPodも以下の状態になってしまう

W210126 07:18:57.177231 201 kv/kvserver/node_liveness.go:488  [n2,liveness-hb] failed node liveness heartbeat: operation "node liveness heartbeat" timed out after 4.5s

17:00(JST)ごろアプリケーションが動いていないことで気づく

エラー内容はこれに近いように感じた。

forum.cockroachlabs.com

色々と修正しようと頑張っている内に以下のエラーを吐くようになった。

W210126 13:32:11.928294 156 kv/kvserver/store.go:1631  [n2,s2,r6/3:/Table/{SystemCon…-11}] could not gossip system config: [NotLeaseHolderError] r6: replica (n2,s2):3 not lease holder; lease holder unknown
W210126 13:32:12.743191 127 kv/kvserver/replica_range_lease.go:554  can't determine lease status due to node liveness error: node not in the liveness table

現在振り返って考えると17:00ごろはなんとかなったかもしれないが、21:00ごろから上のエラーがで始めた時点で厳しい感じがする。（＝よくない操作をした）

データ復旧に関して

CockroachDBは様々な方法でバックアップやデータのdumpができるようになっているが、Clusterが起動している状態でないできない。

上のVersionでは内部のストレージ部分にRocksDBを使っているので（最近のVersionはPebbleになっている）RocksDBと向き合いながら頑張ればデータを復旧できるという説がある。自分の認識では理屈上2Nodeのデータがあればいいはず

今回はデータは捨てる判断にしたが、大事なデータを保存していてバックアップもとっていない人はチャレンジするための資料を置いておく

Goを使ってRocksDBから復旧を試みる

sudonull.com

データ構造に関しては、以下のスライドが参考になる

ccvanishing.hateblo.jp

以下のソースコードのコメントもデータ構造に関してわかるかもしれない

github.com

余談

ちなみにcockroach debug rocksdb でデータを直接操作することができる。

cockroach debug rocksdb scan でK/Vっぽいものを取得できるが、cockroach debug rocksdb get KEY_NAME にscanした結果のkeyを使うことができない。

あまり理解していないが、cockroach debug rocksdb scan は CockroachDBの内部でてくるKey (例：/Local/Store/gossipBootstrap) で、RocksDB側で使われているKeyは別のbinary表現のkeyに変換しているようだ。RocksDBの私が理解していない機能を使っている気がする。

なので、 cockroach debug rocksdb scan と cockroach debug rocksdb scan --hex のvalueを比較することで、同一のkeyを取得することができ、cockroach debug rocksdb get --hex HEX_KEY_NAME でCLIから値を操作することができる。

cockroach debug rocksdb scan はほとんどデータがないはずのDBから数GBのファイルを生成してくるので、地獄みたいな作業になる。

RocksDBの操作はかのブログで雰囲気を察することをお勧めする

www.jianshu.com

2020-10-18

CloudFrontが更新前の証明書を返す

事象

なんか会社のテックブログ的な存在の証明書が切れた？？

.@herp_inc https://t.co/PTPR2HARfi の証明書の有効期限が切れています
— 青木華絵 (@aereal) 2020年10月17日

が、しかし普通に繋がる人もいるようで

f:id:hiroqn:20201018194746p:plain

gyazo.com

しかし私のiPhoneからは繋がらない...

f:id:hiroqn:20201018195343p:plain

上記のブログはCloudFront+S3で構成されているので、AWSの管理コンソールを見に行ったところ、ACMとCFの設定は特に問題はなさそう

どうやら証明書ガチャ（厳密にはCloudFrontのEdgeガチャ）が起きている？？

経緯

確かに、現在の証明書の設定は問題ない、問題はないが実は10/2に証明書の更新に一度失敗している

You have an SSL/TLS certificate from AWS Certificate Manager in your AWS account that expires on Oct 17, 2020 at 12:00:00 UTC. This certificate includes the primary domain herp.co.jp and a total of 2 domains.

で、諸々対応した結果、 10/7に更新された旨の連絡がきて、確かにACM上は更新されていた

This is to notify you that AWS Certificate Manager (ACM) has completed the renewal of an SSL/TLS certificate that certificate includes the primary domain herp.cloud and a total of 2 domains.

対応

これは、CloudFrontの裏側のインスタンスというかエッジロケーション的なSomethingの証明書が更新された場合と更新されていない場合があるぞい、という排中律的な感じがしてきたので裏側をエスパーして対応を考えてみる

まず、Cache Invalidationを /* を対象にやってみる

結果、駄目

次に、同じドメインを対象とした新しいCertificateを作ってCloudFrontの証明書を変えてみる。

結果、会社のメンバーのうち見れてなかった人が「見れるようになった」と報告

う〜ん、直ったんじゃね？

感想

俺たちは悪くないという自信がそこそこあるんですが、AWSさんどうなんでしょう？？？？

これはCFの正常な動作だよ的なことを知っている人がいたら連絡お願いします

2020-09-11

はてなサマーインターン行ってきました

はじめに

まず最初にdisclaimerを書かせてもらうと2015年の話です。この記事はインターンに参加したあと5年の月日が流れた30歳の労働者が書いている。ちょうどはてなインターンが終わって「今から就活だな〜」みたいに考えている人が書いた記事ではない。

なぜ書いたか

事の発端といえば、何の因果か、今ははてなインターンのチームで同じだった id:SWIMATH2 と働いている。

別に急な話ではなくてもう3年以上一緒に働いているのだが、逆に3年働いていると世間話をする機会が出てくる。そこで急に当時のインターンの話になったので過去サイトを見ながらを振り返っていたら、「（インターンの）参加記録を書いてくれると思ってたのに〜」と言われてしまった。

hatenacorp.jp

最初、自分の記事リンクされてね〜〜〜って思ったけどそもそも書いた事実がなかった。疑ってすみませんでした。

そして、懐かしさを感じながら当時のチームメイトのブログを読んだ。

swimath2.hatenablog.com

自信がないからといってはてなインターンに応募しないというのは絶対にやめましょう

結構いいことが書いてあって、普通にいいことが書いてあった。

私は当時に25才だったので少し参加を迷ったりしてはいたんだよなぁ、そういう人間にも参加した方がいいと伝えるためにも今からでも参加記事を書いた方が良いな、という優しい気持ちになった。

　振り返って

振り返ってみるといろんなシーンを断片的ながら結構覚えていた、自分は結構記憶力ある方なんで。ただ、上記のブログを読むとなんか大体書かれてて、当時の自分も書くことないな〜ってなって書かなかったのかもしれない、これはおそらく言い訳だが。

以下インターン良かったことリスト

研修
ペアプロ（これは本当に良いメソッド）
実際のプロダクトへの参加
perlのhash
カマルのカレー
hatena社員の個性(特にid末尾に数字がつく人)

振り返ってみると、やっぱ研修がちゃんとしてるのがすごいんだなぁ。 Perl書いたことがなかったけど、なんだかんだ何とかなる（という気持ちにさせてくれる）というのは研修がよく出来ているということだ。

つまり参加ハードルが実質0なんだよ。あと、5年たっても参加記録を書くというハードルも0だ。

謝辞

当時ののメンターの id:t_kyt id:shiba_yu36に感謝を。

あと過去を含めインターン参加者へ,

時間がたったからと言ってはてなインターン参加記事を書かないのは絶対にやめましょう

そういえば完全に私事だけど印象深いことがあって、当時デパスを飲んでたがなんか覚えてないけどインターン中に飲まなくなった。そのあと今までベンゾジアゼピンは摂取してない。あれは働きながら飲むもんじゃないなって思ったし、今もそう思っている。

2019-10-20

Static Named Directoryの話

abst

Static Named Directoryの話をします。historyに../../とかが入って嫌な人は解決する可能性があります。

困り

おおよそのケースでcwdに依存したビルドは開発体験が悪くなる傾向にあると言われている（私に）

うまくMakefileを書いている場合はそれはまぁ最高なんだけど、適当にcdしてcommandを打っていると引数の中に ../ が混じってきたりする。

混じると何が困るかってhistoryの再利用性が低くなる。怠惰寄りの人間なので過去に打ったcommandを手で打ちたくないのだ。

提案手法

shellの ~ みたいにいい感じにしてぇ~って思って調べたら ~ はexpansionと呼ばれる機能らしい。

zshにはexpansion周りの機能が複数あって、Static named directoriesを使うことにした。

static named directory

zsh: 14 Expansion

~hoge のようなものがparameterにあった際にzshは hoge と呼ばれるnamed directoryを探して展開しようとする。

named directoryは以下の方法で定義される

/ から始まる shell のvariable
hash commandを使う (ex. hash -d hoge=/hoge/fuga)

example

今回は git のtop levelをnamed directoryにした。

なので chpwd のhookを使いながらnamed directoryを変えていくことになる。

    chpwd_static_named_directory() {
      local gitroot=$(git rev-parse --show-toplevel 2>/dev/null)
      if [ ! "$gitroot" = "" ]; then
        hash -d "git=$gitroot"
        return
      else
        hash -d git=
      fi
    }
    chpwd_static_named_directory

    add-zsh-hook chpwd chpwd_static_named_directory