2022年10月状況
近況報告です
続きを読む【読み物】2022年にJenkinsのジョブ管理を自動化するには時代が追いついていない
完全に理解したから何もわからないに突入したので2022年現在の状況をまとめておこうと思います。 Jenkins自動化完全に理解したの人向けのメモなので、Jenkinsfileをまだ触ったことがない、ちょっと触っていて便利かもって人向けではないです。
先に結論だけ書いておくと、個人的にはジョブが少ないなら JCasC + jobDSL + Jenkinsfile のパターンで管理できると思います。
ただし、Jenkinsfileは一度評価しないとパラメータやトリガーなどが設定されず、JenkinsfileとjobDSLは機能が競合するため、癖のある運用になる点は注意が必要です。簡単な方法として、jobDSLでジョブを作成する際に triggers を設定し、jobDSLのジョブ実行後に自動的にJenkinsfileのジョブをトリガーする方法があります。可能であればJenkinsfile側では when を設定しておき、 UpstreamCause の場合にジョブ実行を早期終了すると良いでしょう。
このやり方は以前も書いた通りで、Jenkins自体を小さく保つことでインスタンスのアップグレードなどの管理面やコードレビューの責務を分解できる点でも有利なので、可能であればこの方法は (多少の癖はあるものの) 有効であろうと思われます。
続きを読むISUCON12お疲れ様でした
ISUCON12お疲れ様でした
久しぶりに帰ってきた鍋部で参加させていただきました。 細かない話は色々ありますがとりあえず先出しということで。
序盤
開発環境が作れなくて泣く Dockerを剥がす > 早々に docker-compose を外したのは良しとしてビルドが通らず
中盤
SQLiteのIOがおバカすぎたので tmpfs に載せて iowait 消したらsyscallが高くなりすぎてこれはダメだなってなり、博打でMySQLに移し替える戦略に出る それはいいとして結局スコアが上がらない。結局 N+1 を消せないのでスコアが落ちる落ちる。
終盤
initializeがいつまで経っても終わらないので無理矢理シャーディングする構成を取る、一応初期化リクエストは通るようになるが時間がなさすぎることに
3台あったのに3台構成にする時間もなくて辛い。
久しぶりのISUCON参加になりましたが、あまりいい感じにできた感じはないですねー。 コード変えずにスコア上げられるのは割とすぐ終わってしまうのでしまうのでアプリケーション側をいい感じにしていく必要がありますが、 コードの意図を読み取れなかったですねー。CGIみたいなflockもあったし。
いつか来ると思ったWriteが支配的な問題なのがちょっと面白かったです。
改めてどこかで反省会しますねー
AWSでAZ障害が起きたので困ったことを書いておく
前にも似たようなこと書いたなと思ったけどもう一年半も前のことになるのか
ご存知の通り昨日 2021/02/19 23:20頃 AWSにて東京リージョンの一つ apne-az1 にて大規模な障害が発生。多くのAWSを利用していたサービスで影響があった。
そんな私はいつものように アラストリリィ アサルトリリィ ラストバレット というゲームを呑気にプレイしていたのだけど、23:25 から緊急メンテに入ってしまった。
どうしたんだろうと思っていたら、社内SlackにてAWSを利用しているサービスがたまに応答しなくなる、Elasticacheが切り替わったなどなどの報告が入り、もしかすると面倒ごとかなと思いながら対応することになった。
起きていたこと
既にAWSからも公開されていることであるが、今回は2019年8月に起きた障害と類似するタイプの障害だった。
東京のAZの一つ、apne-az1 にてサーバ冷却装置の電力供給にトラブルがあり、EC2の機能が縮退したというもので、影響を受けたのはEC2とEC2に乗っている多くのサービスであった。
前回、ブログにてAZ障害が起きた場合のことについて呑気に書いていたが、今回の対応ではこのタイプのAZ障害では困ったことが起きることがわかった。
一番困ったのは、EC2が縮退しているのに、アラートが上がってこないことだった。 AWSで構築しているサービスはEC2やEC2を使って組まれたサービスに乗っているものが多く、例えば最近だとECSをFargateで動かして、ALBを使ってサービス提供する、みたいな構成をとっている。
Fargateは自動的にサービスを起動する仕組みを持っていたり、ALBもマネージドなロードバランサーでよしなに動いてくれると思っていたが、今回のトラブルではAWS側の仕組みではうまく切り離しができていなかったように思える。要はAZは死んでいるにも関わらず、サービスとしてはまだ「生きている」判定がされており、切り離しがうまくいっていないような動作をしていた。
これは大変困った。普段利用しているCloudwatchなどでは死んだサーバやサービスが判別ができず、ALBについては自分たちの管理下ではないので、死んだALBに当たることを避けるのは容易ではなかった。
仕方がないので、 apne-az1 に属しているすべてのEC2ベースで動いている、と思われるサービスを使わないようにしていくしかなかった。
しかしこれは全くもって簡単ではなかった。というのはAZ障害の場合は当然綺麗に自動切り離しが行われる前提で設計をしていたので、今回みたいに自動的に切り離しができないことを想定していなかった。
これはTerraformやCloudFormationを使っていたとしても容易ではないと思う。切り離し方がサービスによってかなり違うので多くのリソースを使っているほどきり替えが難しかったはず。 ALBなどはSubnetを指定する設定があるし、Fargate は placement constraints を設定する必要があった。また、ENIなどもZoneに依存している。RDSはMaster昇格をする？それは大変だ。 もちろん一気にすべてのリソースがパタパタ切り替わったらそれはそれで困ったかもしれないが、死んでいるのか生きてるのか判別かつかないというのは相当参った。中途半端に生きているサービスを綺麗に切り替えるは相当難しい。
今回の反省
サービスは綺麗に死ぬとは限らないことを見落としていたこと
AWSで構築するときにはMulti-AZ構成を取っていたし、自動で切り替える仕組みも設定していたが、自動で切り替わらない場合にどう切り離すかまで考慮していなかった。 Terraformで構築は自動化していたが、AZの一つだけを切り離すにはどうすればよいか、俯瞰して見ていたわけでもなく、実際の切り離し作業にはかなり手間取ってしまった。 というより、AZの一つが死んだ場合にTerraformなどで隔離できるように書いておくというのはかなり難しい気がしている。 これはまだ考えていないが、多分今更書き直すのは難しい気がしている。最初から切り離せるように書いておかないと難しいが、そんなところまで考えてはなかったというのが正直なところだ。
マイクロサービス化を進める過程でアカウントを分割したことで対応が煩雑になった
これはそれはそうだろうという話だが、権限やコスト分割の観点からアカウント分割をしてきたことで、分割したアカウントの数だけ同じことをする羽目になってしまった。 アカウント単位で閉じない、広範囲のトラブルに対しては複数アカウントに分けたことで対応箇所がばらけてしまい、設定反映に手間取ることになった。 実際このようなケースを想定してすべてのアカウントに対してAZを切り替えられるように設定を書くのはかなり困難と思われるが、毎年起こるような問題であれば対応しなければならない。
終わりに
前回書いた記事でいうと「問題がおきたマシンの切り離しの仕組みがうまく動かない」ケースに該当して大変な目にあった。 こう一年半に一回くらいの確率で起きる問題だと、対処できるようにしておかないといけないし、今回の件を踏まえて自動切り離しとは別の観点で手動でAZ切り離しができるように仕組み化していく必要があるかもしれない。
今回AZ障害だからMultiAZだから影響がないっていうのは間違いで、中途半端に死んだ結果切り離しがうまく行かず、MultiAZ構成を取っていても影響が出てしまうというトラブルだったということだけ書いておきたい。
死ぬときは綺麗に死んでくれないってのは物理時代もスイッチやNICでよくあったし、こういうのが一番困るね。やれやれ
おまけ
プリンセス・プリンシパル Crown Handler 超良作だから観てね
