こんにちは 
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によって再実装し退役に至るまでの技術的判断や技術的実装の概要を説明しました。レガシーシステムとの闘いは苦痛のように語られがちですが、計測・合意を行いながら進めることで現代的な形に生まれ変わることができると思います。むしろチャンスと捉えることもできそうです。今回はありがたいことに再実装に成功することができました。今後は可能な限り失敗についてのヒストリーも何かしらの形で共有したいなと思っています。
アラートレベルで分類してみた。これを見た人の何かの参考になるといいな
これです yapcjapan.org
はてながスポンサーになっていたのでスポンサーチケットで参加させてもらった。誰か行きませんかと社内で募集があったので手を挙げた感じ。同僚の id:papix が運営を頑張っているとJPA方面の方からも聞いていたので、行かない選択肢がなかった。社内に共有したメモから抜粋して感想等を書いておく。
Perlは勉強中で、最低限さくさく読めるようになろうとしているところ。
Rakudoとか、MoarVMとかわからん
資料: ２つのDXと技術的負債-YAPC Tokyo 2019 - Speaker Deck
2つのDX - 開発者体験 - 企業のデジタル化
ダンバー数 https://ja.wikipedia.org/wiki/%E3%83%80%E3%83%B3%E3%83%90%E3%83%BC%E6%95%B0
こういったことを考えていると、ポエムでしょ？と言われる
★ 要求インスペクション、よくわからんかった
資料
エラーメッセージを身近に感じてほしいとのこと。調べ方のためにもソースコードやドキュメントを読んでおくのは良さそうと思った。
tokuhirom
perldoc.jpの翻訳作業をやる人が一人しかいない。コントリビュートチャンス
いい刺激をもらえた。onkさん、Songmuさんの発表の両方で感じたが、Rubyなど他言語のよいところを輸出入するという考え方はとてもよい。何の言語やツールかはわからんけど、なにかコードやドキュメントを書くことでの貢献をもう少しできそうかもという思いを持った。小さく始めて継続できる感じを探ってみたい。LOCAL学生部の人達に学生交通費支援制度あるってーと宣伝しておいたら本当に北海道から数人来てくれていて最高だった。学生同士でもワイワイしていたし、そこらへんにいたバリバリやっているエンジニアたちとも交流していたようだったのでとてもよかった。尊い。
はい。それは私です。S.O.Sって曲最高だし、MAHO EMPiRE最高だよねと話した。尊い。
「それ EMPiRE パーカーだよね？」って声をかけられたのが本日のハイライト #yapcjapan
— 大沢和宏 (@Yappo) January 26, 2019
LOCAL Community Summit 2019(以後LCS2019と表記します)というイベントを1/19(土)に行いました。 これです。
過去に2回実施しており、2年ぶり3回目の開催となりました。
一般社団法人LOCAL(以下、LOCAL)という、「北海道の技術者コミュニティを盛り上げよう」という目的の団体の理事をやっていて、東京でもイベントやろうよ！って趣旨のものです。
イベントの説明はこんな感じです。
LOCAL Community Summit (LCS) は、 地方のエンジニアやコミュニティの取り組みを、地元だけではなく東京でも発表してみよう！ 私達の地域の楽しさを、他の地域のエンジニアにも伝えよう！ 地元を離れ首都圏で活躍しているエンジニアや、いろんな地域のコミュニティと繋がろう！ というテーマのもと、一般社団法人LOCALが北海道を飛び出し、東京で開催しているIT系勉強会イベントです。 今回は札幌地域へのU・Iターン促進イベント #みんなの札幌移住計画4 との同時開催で、「コミュニティ運営とエンジニアとしての成長」などをキーワードに、多彩なゲストをお招きして開催します。
札幌市への移住イベントとの同時開催という形でした。ちなみにLOCALは北海道の技術コミュニティに着目しており、札幌だけが北海道ではないと日々思いながら活動しています。もちろん、札幌は大好きです。
今回は、明確には募集ページには書いてないのですが、セッションごとにそれぞれセッションオーガナイザー的な人を置き、テーマぎめから登壇者確保までをやってもらう形にしました。後述する941さんの登壇内容から聞いたのですが、MANABIYAさんのカンファレンスでは、明確にセッションオーガナイザーが置かれていてオーガナイザーごとにその枠の取りまとめを行う形になっているそうです。それ、いいな。主催者の負担はできるだけ下げたい。
僕は実行委員長役とSession1,2を担当していて、僕がどうしても直接聞きたかった人たちにお願いすることにしました。そーだいさんの「私とコミュニティと生きる道」という話と、941さんによる「エンジニアに愛される技術イベントを運営するために必要なもの、それは愛」という話です。どちらも自分の思っていたとおりにいい感じになって開催者冥利に尽きる感じでとてもありがたいですね。
ブログにも書いてもらっていました。激エモですね。私信ありがとうございます。真面目なことも書くと、LOCALという仕組みは先駆者が作ってくれた良い仕組みだと思っていて、他の地域でもあると良さそうと思っています。簡単に言うと北海道における技術コミュニティをつなぐというメタなコミュニティです。コミュニティ同士をつなげるというの、その地域を盛り上げるために意味があると思うんですよね。そのうえで、北海道と他地域をつなげようというのがLCSのやりたいことなのでした。京都に移住したこともあり、関西コミュニティとの出会いが少しずつあるので、また何かやりたいかもなと思い始めています。
それな。すごくわかります。そーだいさんの「恩返しと恩送り」の話、めっちゃ好き。
— Shoco Sato (@satoshoco) January 19, 2019
#lcs2019
そう。コミュニティって、あなたなんですよね。この話を明確に説明しているとても良い記事があります。るびまという、Rubyist向けのマガジンには巻頭言があり、このようなことが書いてあります。とても好きな一文です。「コミュニティはあなた自身」 #lcs2019
— nasa9084@某某某某(0x19歳) (@nasa9084) January 19, 2019
コミュニティとは誰か。もちろん、あなたのことだ。あなたがコミュニティであり、 それ以外にコミュニティはいない。あなたのような人々の集まりを、コミュニティと呼ぶのだ。
コミュニティの新陳代謝についても触れられていて、思うところが多いセッションでした。コミュニティから学んだこと。多様性と世代交代。環境は人を育てるが、逆にずっといると染まってしまう。 世代交代大事ってのもめちゃくちゃわかるなー。この人しかできないってのはコミュニティでも健全じゃない#lcs2019
— hokkai7go (@hokkai7go) January 19, 2019
941さんはこうおっしゃってるんですが、実際少し早めに終わったものの会場も盛り上がっていて質問がじゃんじゃん出てきていてとてもよい空間でした。何を思って、どういう苦労をして技術イベントをやっているかという話を、まさにイベントを主催している最中に聞けてとてもよかったです。重大なお知らせ👉 @941 さん😂#lcs2019 pic.twitter.com/pfsAEK9Bva
— Shoco Sato (@satoshoco) January 19, 2019
過去のアンケートをよく見返して少しずつ改善すること
— hokkai7go (@hokkai7go) January 19, 2019
他のイベントとの満足度を分けるもの。それは最後の細やかさ。やる必要がないと思われることをやり切る優しさ。それは愛。
#lcs2019
イベント得意だしやりましょうか？と言ってYAPC::AsiaもISUCONもやりはじめた #lcs2019
— hokkai7go (@hokkai7go) January 19, 2019
エンジニアに愛されるイベントのために必要なこと
— hokkai7go (@hokkai7go) January 19, 2019
・信頼できるエンジニアと関係性を構築しておくこと
・ターゲットとしたい層のエンジニアに相談すること #lcs2019
このtweetがいちばんきれいにまとまっていてありがたい感じです。絵文字って大事。
「エンジニアに愛される技術イベントを運営するために必要なもの、それは愛」by 941さん
— Shoco Sato (@satoshoco) January 19, 2019
😊まとめ😊
👉まずは小さな飲み会の幹事から始めてみよう
👉エンジニア向けイベントの企画が決まったら売れているエンジニアに相談しよう
👉一人でできないことも協力してもらえれば出来る
#lcs2019
飲み会の幹事から始まり、1000人以上の規模にもつながるとはすごいですね。飲み会の幹事には学びが詰まっている #lcs2019
— そーだい@初代ALF (@soudai1025) January 19, 2019
はい！わかりました。◆イベント運営者に心がけて欲しいこと◆
— Shoco Sato (@satoshoco) January 19, 2019
👉時系列でやることリストを作る
👉想定できるものは対応
👉準備が8割（これ大事）
👉明確にレスポンスを早く
（LINE,Slack,Facebook,et）⁰👉情報はわかりやすくまとめる
👉ネガティブと向き合う（結構大事）
by @941 さん
#lcs2019
ほかセッションについては、onodesとT_akmsが担当してくれました。 suzukiさん、jkudoさん、T_akmsの三人はよく知っていると思っていたけど、全然知らない興味深い話がでてきていて面白かった。特に、エンジニアのためのマネジメントキャリアパスを読んだ後だったからか、suzukiさんのキャリアパスに興味津々だった。
LCS2019 Session 3. 「北海道、コミュニティと私の繋がり」
— LOCAL (@local_hokkaido) January 19, 2019
1人目は、道民では？の呼び声も高い @suzuki さん による「普通のエンジニアに戻った人生と コミュニティと」#lcs2019 pic.twitter.com/0IyCSHsZDq
プレイングマネージャーをやろうとしたが技術担当取締役としてはマネージメントにしぼった。技術面はコミュニティに関わりを #lcs2019
— でこびす (@decobisu) January 19, 2019
富良野から来ている、@tomio2480 (FuraIT)の話は年々凄みを増していて良すぎました。旭川や富良野で学生さん向けのIT勉強会をやっている方です。
やっぱり後から見直しても何を言っているかわからないが、技術よりも場と人脈をつないでいくのが大事というのはとてもよくわかります。豚汁でわかるコミュニティ活動の意義
— hokkai7go (@hokkai7go) January 19, 2019
後から見直してもぜったいわからんツイートだこれ… #lcs2019
はー、とみおめちゃくちゃ考えていいことやってるなぁ。技術よりも場と人脈をつないでいくというの大事 #lcs2019
— hokkai7go (@hokkai7go) January 19, 2019
知見がループする場をつくる
— hokkai7go (@hokkai7go) January 19, 2019
若い人が挑戦したり、いろんなことを知ることができる場が一番面白い。これは学生にプログラミング教室をやっているからわかる。とのこと #lcs2019
話のつかみで豚汁の話が飛び出して、どんどんコミュニティの話になっていき、気がついたらめちゃくちゃ示唆のある話が押し寄せてきて、なるほどこれは現代落語のようなセッションだなと思いました。
「僕は明日いなくなる。」
— そーだい@初代ALF (@soudai1025) January 19, 2019
本質だよな。今のこの楽しい場所は誰かが支えてる。
その支えてる人が居なくなった時にその場所がなくなってほしくないなら自分が頑張るしかないんだよな。 #lcs2019
学生に対しても、「僕は明日いなくなる。」と伝えてコミュニティ運営をしているのってすごいことだと思いませんか。常に属人性排除に向けて手を打つことを言っているわけでしょう。なかなか真似できない。この話を聞けて本当に良かった。
OSC北海道参加者の方々は知っているかも知れない、sakuraさんがとてもありがたいLTをしてくれました。月並みかもしれないけど、自分の言葉で感謝を伝えられるのって大事なことだなと思いました。
はてなブログに投稿しました #はてなブログ
— sakura (@818uuu) January 19, 2019
LOCAL Community Summit 2019に参加した #lcs2019 - 検索ブログhttps://t.co/TSQjiHzbbQ
LT枠埋まるかどうか心配だったのですが、結局5枠すべて埋まりありがたかったです。
#みんなの札幌移住計画4合同企画「とことん、私とあなたの札幌移住計画」 #みんなの札幌移住計画4合同企画「仮想札幌市長選」
という2セッションを、合同でやっていただきました。実際に移住した人がLOCAL理事にもいて、彼らも登壇して移住についての質問に答えるというセッションがありました。実際の声が聞けるのはやはりとてもいいことですね。そのうえで、失敗についても語られていて良かったです。
大規模イベントではないものの、やはりイベント運営はとても不安になることを思い出しながらやっていました。でも当日を迎えてみると、準備しっかりしたことや、人に任せることが少しずつうまくなってきたのか負担が下がったこともあり、やってよかったという気持ちがギュンギュンと出てきているところです。2018年末の引越から、ここまでの破滅したスケジュールをなんとか事故無く終えることができてとても安心した気持ちです。次回があれば参加したいとか、これまでやってきたことへの感謝をもらえるとか思っても見なかったので、続けてみるものだなーと思ったのでした。何より、参加者や関わった人たちが楽しそうにしている様子を見られたのがよかった。
これです。 https://sre-lounge.connpass.com/event/114005/
とてもよいイベントでした。SREって、そうだよねーと思うところが多かった。SREがカバーする範囲が広いということと、すべてをカバーできる人はいないからお互いにリスペクトして多様性がある状態にしておくのがいいんじゃないかという話があってわかりみが深かった。ここまでが仕事なんでと責任範囲を区切ってしまうことは、DevOpsの考え方的にも自分は違うと思っている。オーバーラップしていくしかないと思う。
ここから先は自分やみんなのツイートを引用したい
そうですね。
プロダクトによってはSREsいるとかいないとかあるよなぁ。アプリケーションエンジニアだけどインフラもできる人がSRE的なことやってる場合もあるしそこそこで違う #srelounge
— hokkai7go (@hokkai7go) January 18, 2019
toilの話は何度も出ていた。ゆううううううううううううううううううううううき氏のブログは何度も言及されていた。次世代Webカンファレンスがあってすぐだしタイムリーだったのもありそう。
Toilの計測が難しいならベロシティの計測をすればいいじゃないという内容が書かれているのがこれですねhttps://t.co/rYPKKLHRBE #srelounge
— hokkai7go (@hokkai7go) January 18, 2019
50%がいいのはわかるんだけど、割り込みの緊急度や重要度でトリアージした結果やる必要があるものも多いから制御に躍起になってもしゃあないのではと思うのだよな。ベロシティ下げないように何ができるかという方を大事にしたいと思っている #srelounge
— hokkai7go (@hokkai7go) January 18, 2019
Toilとの闘いの内面についてはこのブログに書かれていることが、なんかすごくすんなりきた。 chroju.github.io
自分が思っているのはこれです。
toilあることはわかるんだけど、それをみんなどう制御しているのか気になっている。 #srelounge
— hokkai7go (@hokkai7go) January 18, 2019
Toilとの向き合い方についての自分の中での答えは、今の所割れ窓タイムによって継続的に技術的負債や、暗黙的な運用に対して光を当ててみて、長くいるメンバーから歴史的経緯を聞いて改善案を話し合ったりするというものです。下記の記事にまとまっています。他の人達がどうToilと向き合っているのかを知りたい。Toilの計測ももちろん大事だけど、どう制御しているのか。
まあぶっちゃけると、正直Toilとの向き合い方だよねと思って始めたわけではないんだけど、やってみるとじわじわと良さを感じているところでした。
SREは自身がボトルネックにならないよう、事業成長を積極的に支援する集団である。SREにしかできないことを減らすようにして、スピードを優先するってのめちゃくちゃわかるーーーー。権限絞るのが仕事じゃなくて、信頼してサクッとやってもらうの良い #srelounge
— hokkai7go (@hokkai7go) January 18, 2019
ドキュメント整備でユビキタス言語に注意しとくの大事だなー！新しく入った人がキャッチアップしやすくしとくに越したことがないと思う。変な略語オンパレードだとわかるものもわからない。 #srelounge
— hokkai7go (@hokkai7go) January 18, 2019
マイクロサービスについての失敗まで含んだ重要な示唆は、クックパッドの記事にたくさんありましたねhttps://t.co/d2VnnyVy8o
— hokkai7go (@hokkai7go) January 18, 2019
#srelounge
SREのこと、みんなわかってくれていないけど、それは自分たちがうまく伝えられていないからでは？という話へのリアクション
雑な認知されて、自分たちがうまくSREのことを伝えられていないんだなと思うのすごく同意できる。理解されたいもんな #srelounge
— hokkai7go (@hokkai7go) January 18, 2019
これはまじでありそうですね。エンジニアがエンジニア採用をやる意味もこういうところにあると思う。
転職エージェントさんにSREが分かってもらえない問題#srelounge
— かつひささん (@katsuhisa__) January 18, 2019
SRE自身がほか組織に働きかける職種である以上、変化に閉じているのはよろしくないですよね。わかるー #srelounge
— hokkai7go (@hokkai7go) January 18, 2019
技芸というのはなんだか少し違和感があり、体系化されておらずエンジニアリングの前段階にあるという説明ならすんなり来る。そう思うと大学の講義を復習したくなってきた
— hokkai7go (@hokkai7go) January 19, 2019
なんかこんな感じです。次は登壇したいなと思っています。