最近の生活

最近の生活は、なにかぽっかりと穴が空いてる感じがしている。普通というかむしろ良好なんだけど、なにか物足りなさがある。

改善したい！とか、うおー〇〇したいという感情になりにくい。まったりしててこれはこれでよいと思うのだけど。

よくよく考えてみると本を読めていないので、活字にどっぷりする習慣を取り戻そう。あとはなんだか体が疲れてるので鍼に行こうかな。

最近は飛行機乗るペースがゆっくりになってきてるので、季節による疲れかなと思う。

最近ブログ全然書けてなかったのでリハビリ用の吐き出しでした

ファクトフルネスを読んだ感想

じゅーんさんが読んだと書いていて気になっていた、ファクトフルネスという本を読んだ。

june29.jp

思い出してみると本能に支配されていたなというエピソード

本書のなかに、「焦り本能」というものがある。焦り本能を抑えるには小さな一歩を重ねようとある。ここからは自分の過去の話だ。IT系のエンジニアとして、あるいは一人の人間として、上京したてのころは焦っていたように思う。「コードを書くことを毎日続けるのが良い」と言っている人を見て、自分がそんなにコードを書けないこともわかっていながら、ただただ焦っていたことを思い出した。でも、最近を振り返って見るとそこそこコードを書く仕事を続けているし、毎日とは言わずともだいたい毎日に近くコードを書くことと向き合えている。自分のモチベーションと向き合えるようになったからか焦りも消えた。

もう一つある。分断本能についてハッとしたことがあった。これはチームメンバーの発した言葉が、まさに分断を意識させる言動だったことがあって気が付かされた。あちら、こちらと分断して人や組織をカテゴライズすることは、分断本能によるものだとそのときに思った。もちろん、悪く言うつもりはないので、気が付かせてくれてありがとうと感じたエピソードだった。

感想

【FACTFULNESS(ファクトフルネス)　10の思い込みを乗り越え、データを基に世界を正しく見る習慣/ハンス・ロスリング他】とても良い本だった。10の本能それぞれの説明をしている本文もよかっ… → https://t.co/fNrhqDdiGR #bookmeter

— hokkai7go (@hokkai7go) March 21, 2019

ファクトフルネスの謝辞やあとがき良すぎて、ちょっと泣いたわ…。本文が淡々としているなか、最後にエモーショナルなところを持ってきていてやられた

— hokkai7go (@hokkai7go) March 21, 2019

どのような人にもおすすめしたい。読んでみたらあなたの感想を聞いてみたいと思う。

割れ窓理論をWebインフラの改善に活用し、チーム内の知識共有を促進している話というタイトルでSRE Lounge #8に登壇します

こんにちは id:hokkai7go です。掲題の通りですが、3/13にクックパッド社にて行われるSRE Lounge #8に登壇します。

sre-lounge.connpass.com

id:Soudai さんへのリスペクトなのですが、登壇前に登壇予告の記事を書いておきます。以前書いた下記の記事は、2018年12月時点での割れ窓タイム運営について書いています。

blog.hokkai7go.jp

その後いくつかのアップデートがありました。今回のSRE Lounge #8 登壇に際して、割れ窓タイム自体のご紹介と最新のアップデートについてお話します。資料はこちらです。

speakerdeck.com

SREの扱う領域はとても広範なものであると認識しています。過去の経緯や特定分野に詳しい人からの知見を吸収したり、自分が教える側にまわるといった知見共有の課題を常日頃から感じており、このような取り組みと発表につながりました。当初の記事公開タイミングからいくつかの運営改善を行ったので資料に盛り込みました。同僚の皆さんと、発表の機会をいただいたSRE Lounge運営のみなさんに感謝しています。ありがとうございます。

誰かの心理的安全性が低いことがベースとなる心理的安全性について

ややこしいタイトルですみません。

最近少しずつ思うようになってきたことです。

心理的安全性というのは全員の安全性がベースにあるというよりは、実は誰かの心理的安全性を（実は）脅かす形で確保されているのではないかという仮説が僕の中であります。

個人的には、最近スクラムマスターとなり、このようなことを考えるようになりました。エンジニアリングマネージャー界隈が盛り上がっているのは、もしかしたらこのような背景があるのかな？よくわかっていません。

全員の欲求を最大限に満たすことはできないわけで、各自ストレスはあるし、ストレスの様子にはグラデーションかかった感じがあるなと思いました。もう少しまとまったらまたアウトプットしたいと思います。

Apache/Nginxによるリバースプロキシ(歴史的経緯が満載)をALBによって再実装した話

概要

これまでに終了したサービスなどの事情によりデータセンター上でApacheやNginxを使って、はてなで所有している様々なドメインに対するリバースプロキシを構成していました。簡単に言うとリダイレクトするだけなのですが、 48個程度のドメインとリダイレクト先の対応関係がありました。歴史的経緯というやつですね。これらのリバースプロキシの利用状況を調査し、統合方針の策定、ALBで再実装し、Route53でALBに切り替え、つい先日データセンター上のリバースプロキシたちを退役させることができました。今回はこの一連の対応での苦労ポイントについてご紹介します。

利用状況調査

2つのロール、合計5台のXen DomUでこれらのリバースプロキシは動作していました。幸運なことにWebサーバで読み込まれていた設定ファイルは1つのファイルにまとまっており、利用状況調査で難航することはありませんでした。またすべての設定がバージョン管理されていたことも良かったです。

調査項目は、

• HTTPリクエストを受ける際のHost
• リダイレクト先のURIパターン
• ALBで実現可能か
• リダイレクト内容(ホスト変更のみ/ホスト変更とプロトコル変更/ポート番号変更とホスト名変更)

としました。もし設定ファイルが複数のファイルにまたがっていたり、正規表現などを利用した複雑な条件でのrewrite設定などが入っていたら調査にかかる工数が膨れ上がっていたことや手戻りが発生していた可能性があります。ゾッとしますね。ここまで調査を終えた時点でチームに共有し、ALBで実現可能かどうかを最低限のテストパターンで実験することにしました。テストパターンの組み合わせは以下のようになりました。これ以外はもともとのリバースプロキシで実現されていなかったためテストパターンとしていません。

• リスナー80、ホスト変更のみ
• リスナー80、プロトコル変更のみ
• リスナー80、ホスト変更とプロトコル変更
• リスナー443、ホスト変更のみ
• リスナー80/443以外のポート、ポート番号変更とホスト名変更

すべてのパターンをALBで実現可能ということと、リダイレクト先がIPアドレスの場合は対応できないことがわかりました。また後述しますが、この時点での実験内容はAWSのWeb画面であるマネジメントコンソール上で行っているという前提があります。はてなではCloudFormationによる構成管理が行われていることや、aws-cdk利用の機運の高まりもあるので今回のALBに関する設定全てをコードで管理したい欲求はチーム内で共有できていました。

統合方針の策定

• 今回作成するALBは多くのFQDNを収容することが想定されるのでCloudFormationなどを使ってメンテナンスしやすい状態で構築するという
• 2つのロールで実現されていたリバースプロキシたちを1つのALBにまとめる

などの方針策定をテックリードが行いました。終了サービスに関するリダイレクトを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で書くことで手作業を避けました。

Route53でALBに切り替え

これらの再実装がうまくいったことをどのように確認したらいいのか悩ましいところでした。しかし、はてな社内においてはRSpecを利用したDNSのクエリテストの仕組みが存在しています。infratasterのinfrataster-plugin-dnsを使用したものです。今回の再実装においてもこの仕組みを利用しました。リポジトリのREADMEには以下のように書かれています。

クエリテストで infrataster を使用する利点は以下のとおりです。

• 毎回、同じテストを実施することで、予期しない RR 削除/変更に気づける
• dig などの手動テストではなく、機械的にテストすることで属人性を極力排することが可能

背景について補足説明をしておくと、はてなでは基本的にRoute53を利用してDNSのリソースレコード(RR)を管理しており、CloudFormation経由でこれらを管理しています。リバースプロキシに向いているトラフィックをRoute53でALBに切り替える作業も、CloudFormationのYAMLを書いて反映するのみで終えることができました。変更前後でクエリテストを行い、意図した結果になることを確認できたので安心して変更を行うことができました。

退役

切り替えが無事に済んだので、これまで仕事をしてくれていたリバースプロキシはめでたく退役することになりました。しかし、アクセスが来ていないことを確認してから退役したいという話になるのも当然の流れでした。アクセスログを確認、分析してみたものの判断に困ることとなりました。微妙にちょろちょろアクセスがあったのです…。この問題に関しては、アクセスログに記録されているIPアドレスとUser Agentごとに分類し、IPアドレスを逆引きしてどこからのアクセスがどのくらい多いのかを分析し、日本語で状況をまとめて判断をテックリードやプロダクトオーナー、チームメンバーに仰ぐことで捨てる勇気を持つに至ることができました。

まとめ

apache/nginxによるリバースプロキシ(歴史的経緯が満載)をALBによって再実装し退役に至るまでの技術的判断や技術的実装の概要を説明しました。レガシーシステムとの闘いは苦痛のように語られがちですが、計測・合意を行いながら進めることで現代的な形に生まれ変わることができると思います。むしろチャンスと捉えることもできそうです。今回はありがたいことに再実装に成功することができました。今後は可能な限り失敗についてのヒストリーも何かしらの形で共有したいなと思っています。

自分の状態をつかむ方法と良くないときの対処方法

アラートレベルで分類してみた。これを見た人の何かの参考になるといいな

critical

• 好きな音楽を落ち着いて聞けず、曲をスキップしまくってしまう
• 音楽を聞くと気持ちが落ち着くことすら忘れてしまって、音楽から遠ざかってしまう
• 楽しい想像ができなくなっている
• 拍動性頭痛や吐き気がする等明らかな体調不良

warning

• 気圧変化に敏感になり、たまに頭痛がする
• 歩くのが面倒になる
• ワイガヤを騒音に思うようになる
• 家でシャワーをしていて思い出し怒りをしてしまう
• 肌の乾燥対策とかに気を向けられなくなる
• 集中できる時間が短くなる

対処方法

• 肉を食べる
• 魚を食べる
• 野菜を食べる
• あたたかいものを飲む
  • コーヒーやカフェラテ、烏龍茶、スープ
• しょっぱいものか、甘いものを少しだけ食べる
• 好きな音楽を聞く
• ドラムを叩く
• そこそこにお酒を飲む
• 散歩をする
• 人と話す
• マッサージや鍼に行く
• 早寝
• ジムに行く
• サウナや銭湯や温泉に行く
• 進行方向を向いて座れる電車に乗る
• slackやDiscordのどうでもいいチャンネルを見てそっと閉じる
• アイドルの動画を見る

あわせて読みたい

blog.hokkai7go.jp

YAPC::Tokyo 2019に参加してきた

はじめに

これです yapcjapan.org

はてながスポンサーになっていたのでスポンサーチケットで参加させてもらった。誰か行きませんかと社内で募集があったので手を挙げた感じ。同僚の id:papix が運営を頑張っているとJPA方面の方からも聞いていたので、行かない選択肢がなかった。社内に共有したメモから抜粋して感想等を書いておく。

Perlは勉強中で、最低限さくさく読めるようになろうとしているところ。

冬のPerl

Perl 5.28

• perl -i が安全に？ファイルが壊れにくくなった？ファイルディスクリプタを使い潰す問題を5.28.1で解消
• Babble (App::sigfix) https://metacpan.org/pod/App::sigfix
• サブルーチンシグネチャの新旧切り替えコードを一般化
• コードの置換にはPPRを使用 https://metacpan.org/pod/PPR

Perl 5.30

• 多少のパフォーマンス改善
• Unicode11
• なんかいっぱいエラーになるものがあるらしい

Perlを取り巻く状況

• cpanのactive authorはだいぶ減っている
• CPAN Pull Request Challengeが4年以上続いていた
• Perl::LanguageServer
• Perl 6.d がリリースされました

2019年の開発予定

• MoarVMの最適化、部分的エスケープ解析
• 高速化
• 並行・並列処理

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

• 明晰な言語化という意味だと、立法行為と同じことをしているのでは
• 我々エンジニアはコミュニケーションそのものをしている
• 学習を促す心理状態になれば、本能を克服できる
• 心理的安全性と責任の両方が高ければラーニングゾーンに行ける
• 本能的機能は組織にも適応される: ゲシュタルト原則
  • ゲシュタルトの法則 – イディア：情報デザインと情報アーキテクチャ
  • 地理的に近いと仲間だと思う
  • 似ている種類の集まりを仲間と思う
  • 個々人は個性的だと思っているのに集団で捉えてしまう
• 問題は、構造にこそあるのではないか。構造をリファクタリングする
• ソフトウェアづくりはコミュニケーションそのもの

• こういったことを考えていると、ポエムでしょ？と言われる

  • ソフトウェア開発を誤解した反応だと思うとのこと

• ★ 要求インスペクション、よくわからんかった

  • 懇親会で聞いた: ペアプロ/モブプロも品質改善をするが、プロダクトオーナーと要求インスペクションをやることで、より上流工程での品質改善ができて効果も高いよってことだった。
• コード解析より組織構造解析によるバグ予測のほうが成績がいいこともある
• QCDのトリレンマを超える

よいチームの傾向

• 関わる人数が最小限度
• チームが本能的な恐怖を克服する方法を知っている ★これもよくわからなかったな
  • 懇親会で聞いた: →チームが組織学習できる心理的安全性があるとわかっている状態になっているかということ。なるほどね。
• 多様性のある状態から認識を揃える力がある

組織構造とリファクタリング

• 社内にも取引コストはある
• 変えようとするとコストが非常にかかるものと簡単にできるものは、取引コストによって変わる
• 組織設計とアーキテクチャの関係
  • 相互に影響を与え合う
• システムは時間を経ると交換可能性を失ってコントロールを喪失する
• ホールドアップ問題 - Wikipedia
• なぜ多くのエンジニアは「技術的負債現象」と表現せざるを得なかったのかという論点
• 見えてしまったら技術的負債ではないのかもしれない
• 両利きの経営

結論と感想

• エンジニア以外の職種においても情報の非対称性が解決され、エンジニアのDX(開発者体験)と、会社としてのDX(デジタルトランスフォーメーション)が同一になること
• すごく納得した。どういうこと？と思われる方がいれば、エンジニアリング組織論への招待を読んでみることをおすすめする
  • https://amzn.to/2FN5taI
• 併せて読みたい: 「チームが機能するとはどういうことか」を読んだ感想 - 実はhokkai7go](https://blog.hokkai7go.jp/entry/2017/02/07/090655)

Dive into MySQL Error

資料

t.co

MySQLのエラー

• エラーの分類
  • MySQLサーバのエラー
  • クライアントネガティブ応答
  • クライアントライブラリの異常
• ネガティブな応答
• 余談
  • deadlock のエラー、1213 はデッドロックしそうになってロールバックしてくれた
• MySQLエラーパケット
• 先頭FF固定

エラーコード分類

• 1000系がサーバ
• 2000系がクライアントサイドエラー
• 3000番台 5.7から
• それ以上は8から

エラーコード分類による切り分け

• 1000番台ならサーバ系
• 2000番台ならクライアント
• という切り分けはできる。まずはこれらと、3000番台なのかどうかを見る
• syntaxのバリデーションはクライアントサイドではしない。

perror

• perror というツールで調べられる
• 2003番のエラーでも、どこでタイムアウトするかによってちょっと違う
• MySQL has goneとか、サーバサイドの問題も一部2000番台に含まれている
• 2059番 デフォルトの認証プラグインが変更された。古いクライアントから接続しようとすると、このエラーが出る
  • 5.7からは接続できるが、5.6以下はこれが出る
• slaveはクライアント
  • エラーを起こすと、1000, 2000番台のエラーに従う
• エラーメッセージ実は日本語にできる
  • 3000番台以降は日本語対応されていないからプルリクチャンスかもしれない
• perror
  • 引数にエラーコードを受けて、内容を返す
• 1593は、Fatal errorだけが決め打ちで、それ以降は状況次第で出し分けている。ググりにくい
• エラー番号が分かれば、grepしやすい
• プラガブルストレージエンジンのログ
  • 別のファイルに吐いたり、標準エラー出力に吐くことも

まとめ

エラーメッセージを身近に感じてほしいとのこと。調べ方のためにもソースコードやドキュメントを読んでおくのは良さそうと思った。

Keynote

tokuhirom

• PSGI/Plack
  • HTTP:Engineのリプレースプロジェクト
  • 他言語だと仕様と実装が分離されている。たとえばRack
  • 徹夜して書いたライブラリの話をフルセッションでやるのが許された牧歌的な時代
• Amon2
  • Web Application Framework
  • Sledge に対するアンチテーゼ
    • オン・ザ・エッヂの社内リポジトリには修正が入ってるがOSSにバックポートされない問題
• Teng
  • O/R Mapper
  • 当時kamipoさんが言うところのクソクエリが話題になっていた
• Furl

perldoc.jpの翻訳作業をやる人が一人しかいない。コントリビュートチャンス

さいごに

いい刺激をもらえた。onkさん、Songmuさんの発表の両方で感じたが、Rubyなど他言語のよいところを輸出入するという考え方はとてもよい。何の言語やツールかはわからんけど、なにかコードやドキュメントを書くことでの貢献をもう少しできそうかもという思いを持った。小さく始めて継続できる感じを探ってみたい。LOCAL学生部の人達に学生交通費支援制度あるってーと宣伝しておいたら本当に北海道から数人来てくれていて最高だった。学生同士でもワイワイしていたし、そこらへんにいたバリバリやっているエンジニアたちとも交流していたようだったのでとてもよかった。尊い。

はい。それは私です。S.O.Sって曲最高だし、MAHO EMPiRE最高だよねと話した。尊い。

「それ EMPiRE パーカーだよね？」って声をかけられたのが本日のハイライト #yapcjapan

— 大沢和宏 (@Yappo) January 26, 2019