たぶん2ヶ月ぶりくらいにボルダリングをした。結果としてとてもよい体験だった。最近気持ち的にアグレッシブさが足りないなと思っていた。これはボルダリングに行けていないことに起因していそうだと感じた。
ボルダリングの良さはこんなところにあるんじゃないかと思った
できないことと向き合わないと、ボルダリングジムにいる体験がどんどん悪くなってしまうのだ。むきなおりなのではないか。挑戦の気持ちを取り戻した。
自重を感じると、いかに自分の体重に無駄があるかがわかってくる。こんなに体重いらないって思えてくるのだ。この感覚があるかどうかは、食べるものや日々の運動にとても効果的であることは自分がよくわかっていた。
このように2つほど忘れていたものを取り戻すことができた。よかったですね。
最近の生活は、なにかぽっかりと穴が空いてる感じがしている。普通というかむしろ良好なんだけど、なにか物足りなさがある。
改善したい！とか、うおー〇〇したいという感情になりにくい。まったりしててこれはこれでよいと思うのだけど。
よくよく考えてみると本を読めていないので、活字にどっぷりする習慣を取り戻そう。あとはなんだか体が疲れてるので鍼に行こうかな。
最近は飛行機乗るペースがゆっくりになってきてるので、季節による疲れかなと思う。
最近ブログ全然書けてなかったのでリハビリ用の吐き出しでした
じゅーんさんが読んだと書いていて気になっていた、ファクトフルネスという本を読んだ。
本書のなかに、「焦り本能」というものがある。焦り本能を抑えるには小さな一歩を重ねようとある。ここからは自分の過去の話だ。IT系のエンジニアとして、あるいは一人の人間として、上京したてのころは焦っていたように思う。「コードを書くことを毎日続けるのが良い」と言っている人を見て、自分がそんなにコードを書けないこともわかっていながら、ただただ焦っていたことを思い出した。でも、最近を振り返って見るとそこそこコードを書く仕事を続けているし、毎日とは言わずともだいたい毎日に近くコードを書くことと向き合えている。自分のモチベーションと向き合えるようになったからか焦りも消えた。
もう一つある。分断本能についてハッとしたことがあった。これはチームメンバーの発した言葉が、まさに分断を意識させる言動だったことがあって気が付かされた。あちら、こちらと分断して人や組織をカテゴライズすることは、分断本能によるものだとそのときに思った。もちろん、悪く言うつもりはないので、気が付かせてくれてありがとうと感じたエピソードだった。
【FACTFULNESS(ファクトフルネス) 10の思い込みを乗り越え、データを基に世界を正しく見る習慣/ハンス・ロスリング他】とても良い本だった。10の本能それぞれの説明をしている本文もよかっ… → https://t.co/fNrhqDdiGR #bookmeter
— hokkai7go (@hokkai7go) March 21, 2019
ファクトフルネスの謝辞やあとがき良すぎて、ちょっと泣いたわ…。本文が淡々としているなか、最後にエモーショナルなところを持ってきていてやられた
— hokkai7go (@hokkai7go) March 21, 2019
どのような人にもおすすめしたい。読んでみたらあなたの感想を聞いてみたいと思う。
こんにちは 
id:hokkai7go です。掲題の通りですが、3/13にクックパッド社にて行われるSRE Lounge #8に登壇します。
id:Soudai さんへのリスペクトなのですが、登壇前に登壇予告の記事を書いておきます。以前書いた下記の記事は、2018年12月時点での割れ窓タイム運営について書いています。
その後いくつかのアップデートがありました。今回のSRE Lounge #8 登壇に際して、割れ窓タイム自体のご紹介と最新のアップデートについてお話します。資料はこちらです。
SREの扱う領域はとても広範なものであると認識しています。過去の経緯や特定分野に詳しい人からの知見を吸収したり、自分が教える側にまわるといった知見共有の課題を常日頃から感じており、このような取り組みと発表につながりました。当初の記事公開タイミングからいくつかの運営改善を行ったので資料に盛り込みました。同僚の皆さんと、発表の機会をいただいたSRE Lounge運営のみなさんに感謝しています。ありがとうございます。
ややこしいタイトルですみません。
最近少しずつ思うようになってきたことです。
心理的安全性というのは全員の安全性がベースにあるというよりは、実は誰かの心理的安全性を（実は）脅かす形で確保されているのではないかという仮説が僕の中であります。
個人的には、最近スクラムマスターとなり、このようなことを考えるようになりました。エンジニアリングマネージャー界隈が盛り上がっているのは、もしかしたらこのような背景があるのかな？よくわかっていません。
全員の欲求を最大限に満たすことはできないわけで、各自ストレスはあるし、ストレスの様子にはグラデーションかかった感じがあるなと思いました。もう少しまとまったらまたアウトプットしたいと思います。
これまでに終了したサービスなどの事情によりデータセンター上でApacheやNginxを使って、はてなで所有している様々なドメインに対するリバースプロキシを構成していました。簡単に言うとリダイレクトするだけなのですが、 48個程度のドメインとリダイレクト先の対応関係がありました。歴史的経緯というやつですね。これらのリバースプロキシの利用状況を調査し、統合方針の策定、ALBで再実装し、Route53でALBに切り替え、つい先日データセンター上のリバースプロキシたちを退役させることができました。今回はこの一連の対応での苦労ポイントについてご紹介します。
2つのロール、合計5台のXen DomUでこれらのリバースプロキシは動作していました。幸運なことにWebサーバで読み込まれていた設定ファイルは1つのファイルにまとまっており、利用状況調査で難航することはありませんでした。またすべての設定がバージョン管理されていたことも良かったです。
調査項目は、
としました。もし設定ファイルが複数のファイルにまたがっていたり、正規表現などを利用した複雑な条件でのrewrite設定などが入っていたら調査にかかる工数が膨れ上がっていたことや手戻りが発生していた可能性があります。ゾッとしますね。ここまで調査を終えた時点でチームに共有し、ALBで実現可能かどうかを最低限のテストパターンで実験することにしました。テストパターンの組み合わせは以下のようになりました。これ以外はもともとのリバースプロキシで実現されていなかったためテストパターンとしていません。
すべてのパターンをALBで実現可能ということと、リダイレクト先がIPアドレスの場合は対応できないことがわかりました。また後述しますが、この時点での実験内容はAWSのWeb画面であるマネジメントコンソール上で行っているという前提があります。はてなではCloudFormationによる構成管理が行われていることや、aws-cdk利用の機運の高まりもあるので今回のALBに関する設定全てをコードで管理したい欲求はチーム内で共有できていました。
などの方針策定をテックリードが行いました。終了サービスに関するリダイレクトをALBで実装しない判断もこのタイミングで行われました。
方針は決まったものの、実際実現できるのだろうかと不安になった点がありました。ALBのリダイレクト設定をCloudFormationなどで扱えるのかどうかがわからなかったからです。実際、再実装のタスクに取り掛かろうとしたタイミングではCloudFormationからはALBにおけるRedirect Actionの設定を行えない状況にあることがサポートへの問い合わせでわかりました。そのため一旦タスクを塩漬けにしました。
しかし、下記の記事の通りCloudFormationで実現できる見込みが立ちました。ありがたいアップデートでしたね。 https://dev.classmethod.jp/cloud/aws/aws-cloudformation-update-support-resource-and-using-elbv2-listener/
塩漬けにしていたタスクに再び着手しましたが、48個程度のドメインとリダイレクト先の対応関係をCloudFormationのYAMLファイルに落とし込む必要がありました(結果的にYAMLファイルは1000行を超えました)。これを手作業で行うことはできないと判断しました。なぜなら間違えが発生しそうであること、実装者である自分には集中を切らさずに手作業できる自信がないからなどの理由がありました。筆者はRubyが好きです。pryで処理を止めてデバッグできたり、漸進的にコードを書くことができる点が好きです。こうした利点を生かしてCloudFormationのYAMLファイルを部分的に自動作成するプログラムをRubyで書くことで手作業を避けました。
これらの再実装がうまくいったことをどのように確認したらいいのか悩ましいところでした。しかし、はてな社内においてはRSpecを利用したDNSのクエリテストの仕組みが存在しています。infratasterのinfrataster-plugin-dnsを使用したものです。今回の再実装においてもこの仕組みを利用しました。リポジトリのREADMEには以下のように書かれています。
クエリテストで infrataster を使用する利点は以下のとおりです。
背景について補足説明をしておくと、はてなでは基本的にRoute53を利用してDNSのリソースレコード(RR)を管理しており、CloudFormation経由でこれらを管理しています。リバースプロキシに向いているトラフィックをRoute53でALBに切り替える作業も、CloudFormationのYAMLを書いて反映するのみで終えることができました。変更前後でクエリテストを行い、意図した結果になることを確認できたので安心して変更を行うことができました。
切り替えが無事に済んだので、これまで仕事をしてくれていたリバースプロキシはめでたく退役することになりました。しかし、アクセスが来ていないことを確認してから退役したいという話になるのも当然の流れでした。アクセスログを確認、分析してみたものの判断に困ることとなりました。微妙にちょろちょろアクセスがあったのです…。この問題に関しては、アクセスログに記録されているIPアドレスとUser Agentごとに分類し、IPアドレスを逆引きしてどこからのアクセスがどのくらい多いのかを分析し、日本語で状況をまとめて判断をテックリードやプロダクトオーナー、チームメンバーに仰ぐことで捨てる勇気を持つに至ることができました。
apache/nginxによるリバースプロキシ(歴史的経緯が満載)をALBによって再実装し退役に至るまでの技術的判断や技術的実装の概要を説明しました。レガシーシステムとの闘いは苦痛のように語られがちですが、計測・合意を行いながら進めることで現代的な形に生まれ変わることができると思います。むしろチャンスと捉えることもできそうです。今回はありがたいことに再実装に成功することができました。今後は可能な限り失敗についてのヒストリーも何かしらの形で共有したいなと思っています。
アラートレベルで分類してみた。これを見た人の何かの参考になるといいな