Posts for: #2022/04

壊れた cf スタックのリストアと cdk の再同期

#cdk  #infrastructure 

2時に寝て6時半に起きた。インフラエンジニアになったのでみんなが作業していない時間にインフラの保守作業をするようにしている。昼はアプリケーションエンジニア、夜はインフラエンジニアみたいな生活になっていてしんどい。

壊れた cf スタックの更新

テスト環境の cf スタックを手動で更新して壊れているのを cdk で管理できるように直した。壊れていたのは次の3つ。

  • rds をスナップショットからリストアしたので cf が管理している rds リソースが存在しない
  • iam の acl 設定が異なる
  • セキュリティグループのインバウンドルールが異なる

aws 的にもそういった状況は認識していて cdk で同期できなくなった cf スタックを更新する手順を提供している。

ざっくり手順をまとめると次になる。

  1. 対象のリソースに DeletetionPolicy=Retain にセットする
  2. テンプレートからリソースを削除して、スタックの更新を実行する
  3. テンプレート内のリソースの実際の状態を describe して、スタック内に既存のリソースをインポートする

リソースの設定ぐらいなら既存のリソースからインポートしなくても cf のテンプレートを直接書き換えたものをアップロードしてスタックを更新するのでも大丈夫だったりする。しかし、cdk もそのテンプレートにあうように修正しないといけないため、cdk のコードとテンプレートのコードの両方をチェックしながら検証する必要がある。cdk でリソース管理ができるようになったからといって、それが変更前の既存のリソースの設定と同じかどうかは人間が目でみて検証しないといけない。これがあちこちで参照されているリソースだと追跡するのが面倒くさいといった手間暇がかかる。

cdk がよいものかどうか、私はまだ判断がつかないけど、cf を抽象化して便利になっているところは認めるものの、cf のスタックが壊れたときのトラブルシューティングが必要以上に複雑で厄介というのも事実ではある。一方で壊れた cf スタックを5時間ぐらいかけて直したのではまりポイントはいくつかも学ぶことができた。しんどかったけど。例えば、あるセキュリティグループのインバウンドルールに別のセキュリティグループを関連付けるとき、1つの設定ではうまくいかなくて次の2つの設定を追加した。これが適切かどうかわからないが、この設定で cdk でデプロイしたスタックの環境と既存リソースとの環境が整合した状態 (ドリフトが解消される) になった。こういうのが cdk の抽象化による訳のわからないところの1つ。

otherSecurityGroup.addIngressRule(
  ec2.SecurityGroup.fromSecurityGroupId(this, 'my security group', mySgId),
  ec2.Port.tcp(80),
  "my inboud rule",
)
otherSecurityGroup.addIngressRule(
  ec2.Peer.securityGroupId(mySgId),
  ec2.Port.tcp(80),
  "my inboud rule",
)

cdk のメジャーバージョンのマイグレーション

#cdk  #infrastructure 

0時に寝て5時に起きた。開発者にインフラ変更の影響を出さないように6時半からインフラのお仕事してた。

cdk v1 と v2 の違い

AWS CDK Versions には v1 と v2 の2つがある。新規で作るものは v2 を選択すればよいけど、既存のスタックが v1 だとマイグレーションが必要になる。cdk は bootstrap したときに CDKToolkit というスタックを生成する。cdk をアップグレードするというのはこのスタックの設定も更新する必要がある。デフォルト設定をそのまま使っていればマイグレーションはそんなに難しくはないはずだけど、設定をカスタマイズしていたりするといくつかパラメーターを調整したりしなかったりしてややこしいかもしれない。

また v2 は v1 の experimental な機能は移行されていないため、v1 のライブラリを直接使うか、自前でその機能を実装するといったことも必要になる可能性がある。

例えば、v1 の apigwv2.VpcLink というメソッドは experimental で v2 に移行されていないため、v2 に移行されている stable な CfnVpcLink という機能を使って次のように実装した。これは v1 の cdk の実装をみて同じように実装しただけ。

-    const apiGwVpcLink = new apigwv2.VpcLink(this, 'ApiGwVpcLink', {
-      vpc: vpc,
-      vpcLinkName: 'my-vpc-link',
-      securityGroups: [mySecurityGroup]
+    const apiGwVpcLink = new  apigwv2.CfnVpcLink(this, 'ApiGwVpcLink', {
+     name: 'my-vpc-link',
+     subnetIds: vpc.privateSubnets.map(sb => sb.subnetId),
+     securityGroupIds: [mySecurityGroup.securityGroupId]

ecs の draining とタスクの停止時間

#infrastructure 

0時に寝て4時に起きた。なんか起きてから sns のタイムラインを眺めてた。6時半にはオフィスについて cdk のコードを読み始めた。

ecs の draining に時間がかかる？

cdk でインフラのデプロイをしていて、ecs のタスクの置き換えにやたら時間がかかっているのに気付いた。調べてみると、aws のドキュメントがすぐにヒットした。デフォルトでは停止するまでに5分ぐらいかかってしまうようだけど、それを調整したかったらいくつかパラメーターがある。

ecs サービスの deployment configuration

  • minimumHealthyPercent: 同時に停止できるタスクの割合設定
  • maximumPercent: draining されるタスクが停止するまで置き換えるタスクを開始するかどうかの設定？

ロードバランサーの deregistration delay

  • deregistrationDelay: elb(nlb) が登録解除処理が完了するまでに待つ時間。タスクが draining の状態になってこの時間が過ぎた後に登録解除して target が未使用になる

ecs タスク定義の stop timeout

  • stopTimeout: コンテナーが正常終了しないときに ecs が強制的にプロセスを kill するまでの待ち時間

それぞれのインフラの状況にあわせて適切なパラメーターを変更すればよい。私が管理しているのは次の2つを変更した。

  • maximumPercent: 100 -> 200 (%)
  • deregistrationDelay: 300 -> 30 (秒)

これで18分ほどかかっていたデプロイ時間を8分ぐらいまで短縮できた。テスト環境の設定なので多少のエラーが発生したとしても速い方がよい。

再びのインフラエンジニア

#infrastructure 

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

インフラタスクに専念

本当はインフラ担当者が別途いるのだけど、多忙過ぎて、インフラタスクが1ヶ月近く遅延していて、プロジェクト内で合意を得て私がすべて巻き取ることにした。内容の如何に依らず、その一切合切をすべて巻き取ると宣言した。過去に働いた会社でも他の担当者ができなかった業務を後からリカバリするのはよくやってたのでそれ自体は構わない。ただ他人のタスクを肩代わりしても評価されないことも多くて、もともと私のタスクではないから誰がやったかなんか忘れてしまうんよね。私もとくにアピールしないからそう認識されても構わないのだけど、そういう業務が増えてくるとその職場を辞めるきっかけにもなってた。

インフラ担当者や他の社員さんにヒアリングしながら現時点でも十数個のタスクがある。過去のインフラの負債も含めて2-3週間ぐらい、私が集中的にやればすべて片がつくのではないかと考えている。今日たまたまスクラムのリファインメントやってて、業務の人から他の機能開発が遅れているのに2-3週間もインフラ作業に専念するってどういうこと？インフラタスクってインフラ担当者にやってもらえないんですか？と質問を受けて、できるんならその方が望ましいけど、過去の実績からまったく進捗しないのでこちらでやるざるを得ない状況というのを説明した。業務の人からみたらインフラなんか何をやっているかわからないからそんなもんよね。これから2-3週間経って蓄積したインフラタスクをすべて解決した後で少し時間が経つとインフラ担当者が全部やったように外部からはみえてしまうというのを、過去に何度も経験した。

契約更新の打ち合わせ

#subcontract 

0時に寝て5時過ぎに起きて7時半に起きた。

契約更新

4月末が3ヶ月契約の区切りなので契約更新の打ち合わせをした。更新はするのだけど、契約条件が現状の働き方とあわなくなってきたのでその調整のための打ち合わせ。いくつか私の懸念やプロジェクト管理について話していて認知の歪みが起きている箇所を特定できた。いま開発の計画がストーリーポイントから見積もったスケジュールになっていて、これが私からみてデタラメな計画になっている。チームが習熟すれば精度が上がっていくというスクラムマスターの説だが、現時点ではデタラメな計画だから想定外のタスクや進捗遅れが起きてもそれが直接的に反映されない。タスクは増えるが、計画は何も変わらないということがすでにいくつも発生していて、それをおかしいと言っているのがメンバーの中で私だけという状況になっている。前に勤めていた会社でも全く同じことがあった。私だけが開発スケジュールの遅延を2ヶ月前に察していて、他のメンバーは締め切りの2週間前になって気付くということが過去にもあった。

いまのプロジェクトが納期に対して実際に遅れるかどうかは納期が来ないとわからないが、少なくともタスクが増えて納期が固定なら残業して終わらせるしかないと私は考えていた。しかし、開発のトップは計画を延期すべきだと考えていることがわかった。延期してよいのだ。プランニングをしていてどんなに遅延があっても計画を絶対に変えようとしないので期限が必達なのだと私が勘違いしていた。おそらく単純にストーリーポイントから見積もっているスケジュールだから、個々のタスクが増えたり遅れたりしても、それらを全体の計画にどう調整していいのかが誰もわからないのだと推測する。これもストーリーポイントの弊害の1つではあるが。

カスタムドメインの設定

#economy  #blog  #dns  #github 

3時に寝て7時半に起きた。前日の深夜にオフィスの掃除をしてた。シェアオフィスなので掃除機をかけると音がうるさくて周りに迷惑なので誰もいない時間帯を見計らって行う必要がある。

逆イールド

会社を経営する上で経済の状況は大きな影響を受けるので機をみて経済の勉強もしている。直近40年近くの統計では、米国債金利において、2年債の金利が10年債の金利を追い越してしまう現象が発生した場合、その1年後ぐらいに景気後退期がやってくる。この現象を 逆イールド と呼ぶ。

なぜ逆イールドが発生すると景気後退となるのか。国債とは政府の借金。金融機関、年金、個人、海外などが貸している。金利は複雑で様々な要因で決まるので一概に言えないが、大雑把にまとめると経済の力や金融政策、世のおカネの量で決まる。政策金利によって3ヶ月債や2年債は大きく影響を受ける。利上げを急ぎでやろうとしている理由は高いインフレがある。米国は約40年ぶりの高インフレとなっている。FRB は約2%のインフレを目標としているが、現状は遥かに高い水準になるので金利を上げてインフレを抑制しようとしている。FRB は次の2つの使命を負っている。

  • 物価の安定
  • 雇用の最大化

いま物価が急上昇しているため、このまま金融緩和を続けるとさらに物価が上昇して悪い影響を及ぼしてしまう。いまは金融緩和を縮小して利上げをしていく必要がある。しかし、利上げは景気に対して悪影響となる可能性がある。どのぐらい利上げすればよいのかは実際には誰もわからない。最悪の状況として次がある。

  • スタグフレーション: 高インフレのまま景気が減速する現象

スタグフレーションが発生すると経済対策や金融政策で対応しづらい非常にまずい状況となる。経済学者によっても意見が分かれるので、まだスタグフレーションが起こるとは限らない。しかし、起こる可能性があるという見方も出てきているらしい。

英語のテックブログ開設

先日作った backlog-github-integration-action の記事を書くことにした。会社のプロダクトとして作ったツールで汎用的なものや業務として保守していくものは積極的にアピールしていきたい。基本的に私は日本市場をあてにしていないのと、せっかく会社を作ったのだし、海外の会社と取り引きできるようになりたいという野望もある。プロダクトの情報発信は英語が基本で、余裕があったら日本語も書くといった優先度でやっていく。

少し前にたまたま hashnode がイケてるというのをタイムラインでみかけたのを思い出した。せっかくなので調べてみたら、どうも Custom Domain を無償、且つお手軽に設定できるのが訴求点になっているらしい。カスタムドメインを使うと、url に統合性があってカッコいいという以外にも信頼できるドメインに対して SEO が行われるため、優良な記事を書いていると自社ドメインの信頼があがっていくといったメリットがある。コストがかからないならカスタムドメインを使わない理由は何もない。そして設定したものが次になる。

ネームサーバーにカスタムドメインの設定をしていて間違って少しはまった。

間違った設定

cname blog hashnode.network

正しい設定

cname blog hashnode.network.

最後にドット . が必要になる。これで blog.kazamori.jp の名前解決が hashnode.network として解決される。

$ dig blog.kazamori.jp
...
;; ANSWER SECTION:
blog.kazamori.jp.	198	IN	CNAME	hashnode.network.
hashnode.network.	46	IN	A	76.76.21.21

CNAME レコードを滅多に設定しないのでドットで終わらないといけない規則を忘れてた。設定後、dns の propagation に最大24時間ほどかかる。世界のどこからでもアクセスできるようになるには24時間ぐらいかかるかもしれないけど、ローカルで動作検証するなら数分で反映されてた。

jjug の cfp に応募した

#life  #java  #event 

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

ストレッチ

今日の開脚幅は開始前161cmで、ストレッチ後164cmだった。先週とあまり変わらずといったところ。今日は腰の張りが強かった。トレーナーさんは左の張りが強いと言ってたんだけど、私は右の方が体感的に張りが強いように感じた。もう1年以上担当してくれたトレーナーさんが4月いっぱいで転勤になるらしい。社内制度で広島に最低でも半年間は転勤になるという。広島が終わっても神戸に戻ってくるとは限らず、また別の地域へ転勤になる可能性もあるという。きっと優秀な社員だから転勤するんだろうなと思えた。20代後半ぐらいの若もので個人でも筋トレが好きでボディービルダーの大会などにも参加していると聞いた。趣味と業務が近いのでトレーナーとしてのパフォーマンスも高いのだろうと推測する。若い人はなんでも挑戦して経験した方がよいと私も応援した。5月から後任で別のトレーナーに変わる。新しいトレーナーさんに変わることで前のトレーナーさんとの相対評価もできる。これはこれで楽しみでもある。

JJUG CCC 2022 Spring の cfp 応募

本当は締め切りが先週末だったんだけど、募集期間が1週間伸びたのでちょうど作ったばかりのツールで応募してみた。今回はオンラインイベントなので事前にビデオを撮って送るらしい。当日は質疑応答の時間 (10分間) だけオンラインで参加すればよいという感じ。地方在住で物理的に東京に行けないという開発者にも発表しやすいと言えるかもしれない。内容的には初心者向けなので GitHub Actions というネタがいまどきどのぐらい参加者の関心を集めるか、他のプロポーザルとの競争がどのぐらいか次第かな。

生田川公園のお花見予定

cfp を投稿して14時頃に気分転換がてら生田川公園に再訪した。今日は絶好のお花見日和なのでどのぐらい人がいるかを調べるために行ってきた。昨日の夜よりはたくさん人がいて、そこそこ賑わっていた。だいたいの桜の木の下は集団にスペースをとられていた。とはいえ、お花見をするためのスペースが全くないというわけでもないのでよい場所を気にしないなら普通に10人ぐらいの集団でお花見はできそう。個人的には川に入って川遊びしているのが楽しそうにみえた。公園管理者に怒られないならちょっとやってみたい。

帰ってきてから 三宮.dev のすみよしさんと連絡をとって4月10日(日) 11:00 - 16:00 で開催することに決めた。来週中には大半が散ってしまうかも？だけど、実際にやってみてイベント開催の経験値を積むリハーサルの意図もある。bizpy はもはや全く神戸のコミュニティではなくなってしまったけれど、またいつか盛り返す可能性もあるかもしれない。その日のために素振りはしておきたい。

お花見の場所探し

#spring boot  #security  #life 

0時に寝て5時過ぎに起きた。

spring framework の脆弱性対応

起きてタイムライン眺めてたら spring framework の脆弱性の公式アナウンスが出ていたのですぐに準備してオフィス行って7時前から脆弱性対応の作業をしてた。

大学の研究室にいた頃、root staff と呼ばれるシステム管理者をやっていた。研究室のネットワークをすべて freebsd で自分たちで構築していたので os の脆弱性が公表されると研究室のすべての os のパッチ適用をやっていた。具体的にはパッチの当たった kernel をビルドして再起動するといった作業。

それを2年間やっていたせいか、脆弱性情報が公開されるとすぐに対応する癖みたいなものがついた。7時前から作業して検証して7時11分に PR を作成した。レビューアは誰も作業を始めてないけど。金曜日は非稼働日なので私が作業しなくてもよいのだけど、ここまでやったら安心して他の作業に移ることができた。

生田川公園の桜

地元のコミュニティでオミクロン株の感染が落ち着いてきたのでリアルお花見をしたいねという話題があがっている。私自身、お花見に毎年参加するような人間でもないけれど、たしかにコロナ禍になってからはお花見やってないだろうし、個人的にも数年はお花見やってないからやってもいいかなという気持ちにはなった。近場だと 生田川公園 という場所があり、特筆するほど桜がとてもきれいという場所ではないが、一応は桜があって、お花見するスペースもあって、形としては成り立つようなところ。お仕事を終えてから自転車で開花状況を見に行った。19時頃に行って寒くても何組かはお花見している集団はいた。開花状況は7-8割といったところかな。今週末から来週にかけてぐらいが見頃だと思う。