おそらくはそれさえも平凡な日々

NatureのVP of Engineeringになっていました

Nature社は今年の頭にはスタッフが20人を超え(内ハードウェアエンジニア2人、ソフトウェアエンジニア8人)、いよいよ組織らしくなってきました。そして、この4月の期替わりから組織体制が見直され、各専門領域にVPを置くことになりました。目的としては、社内のリーダーシップの強化による組織の成長や、権限を明確化することにより、それぞれのチームが自律的に速度を落とさず動けることなどが挙げられます。

それにより、僕もCTOからVPoE (VP of Engineering) という立場になりました。テック関連のVPは以下の3つに役割分担することにしたのです。ソフトウェア開発とハードウェア開発でも分かれているところがIoT企業ならではとも言えるでしょう。

僕はVPoEということで、よりハード・ソフト両面でエンジニアリング組織にフォーカスしていきますし、コーポレート部門のいわゆるDXと言われるような領域にも取り組んで行きます。エンジニア採用でも引き続きカジュアル面談等を積極的におこなっていきますので、これをご覧になっているエンジニアの方にお声がけさせていただく事もあると思います。

ちょっと面白いのは、僕は開発エンジニアとしての役割も残しますが、そこではVP of Software Developmentの元で開発をおこなうという点です。

4月から、@soh335 がVP of Software Developmentとなりました。彼とは彼が新卒でカヤックに入る前のアルバイト時代からの付き合いです。僕はカヤック社員としては彼の先輩になりますが、カヤックスタッフとしては彼のほうが先輩でした。社会人としては僕は彼の先輩ですが、Webデベロッパとしては彼は僕の先輩くらいの存在です。

彼はNatureには僕より前から関わっていますし、その時はほぼ一人で開発を回していた時期もあり、近年のNature Remoの機能開発は彼がリードしていました。ですので、実質社内の体制面としては実は大きく変わるものでもありません。

ただ、彼の成長を見てきた身としては、組織図として明示的に彼の元で開発することになったことは楽しみです。彼は新卒の頃から抜群な技術力を持っていましたが、最近は同僚への影響の与え方を見ていても、本当に頼れる存在にもなりました。

エンジニア積極募集中です

ということで、Nature社では引き続きエンジニアを募集しているので、あなたの応募をお待ちしています。

https://nature.global/careers/

以下のような点が魅力的だと思います。興味を持って連絡していただけると嬉しいです。

Let's Encryptのルート証明書切替周り(完結編)

tl;dr

前回までのおさらい

Let's Encryptはルート証明書を自身(ISRG)の認証局のルート証明書(ISRG Root X1)に切り替えようとしています。現在は、IdenTrustのルート証明書(DST Root CA X3)が使われています。

正確に言うと、ISRGは新しい認証局なのでそのルート証明書の普及率も当然低く、中間証明書はIdenTrustのルート証明書でクロスサインされており、それが標準で使われています。標準がDSTになっているだけで、ISRGのルート証明書のチェーンの証明書も指定すれば今でも利用することができます。

それを、ISRG Root X1ルート証明書でサインされた中間証明書を標準に切り替えようとしています。経緯は以下に書いてあります。

https://letsencrypt.org/2019/04/15/transitioning-to-isrg-root.html

これはそもそも、ISRG自身のルート証明書に切り替えていくのが本命だというのと、IdenTrustのルート証明書の有効期限が2021年9月29日に迫っているというのが背景にあります。

しかし、ISRGのルート証明書がそれなりに普及してきたと思いきや、まだそれなりに利用されているAndroid7.1以前のトラストストアにはこのルート証明書が入っていません。つまり、以下の困った状況が発生しているわけです。

これまでLet's Encryptは何度かデフォルトルート証明書の変更を計画してきましたが、延期をしてきました。しかし、遂に色々動こうとしています。

驚くべき解決方法

Let's Encryptを使う限りにおいては、今年の9/29日以降はAndroid7.1以前を切り捨てざるを得ないと考えられていましたが、なんと驚くべきソリューションが編み出されます。以下のエントリーにて昨年の12月21日にアナウンスされています。

https://letsencrypt.org/2020/12/21/extending-android-compatibility.html

これは、証明書チェーンのつなぎ方を工夫することで、古いAndroidでも引き続きサイト閲覧ができるようにするものです。https://letsencrypt.org/certificates/ の図が詳しいです。(日本語訳は古いので注意)

ルート証明書をDST Root CA X3からISRG Root X1に切り替えるだけではなく、ISRG Root X1をさらに、DST Root CA X3でチェーンを繋ぐということをしている。ルート証明書にさらにルート証明書をつなぐというウルトラ技。そんなことしていいのか。

何故これが問題の解決になるのか

チェーンが R3 --> ISRG Root X1 --> DST Root CA X3 になると、通常の環境では、ISRG Root X1までチェーンをたどると、それがトラストストアに入っているので、そこで証明書検証が成功するわけです。ここまでは普通の話。

そして、7.1以前のAndroidの場合は、ISRG Root X1がトラストストアに入っていないため、さらにチェーンをたどってDST Root CA X3にまでたどり着きます。そして、DST Root CA X3は旧Androidのトラストストアに入っている為証明書検証が成功するわけです。

しかし、それでもDST Root CA X3は9月29日で失効するわけだから、結局それ以降はエラーになってしまうのではないかと考えるでしょう。その考えは正しいです、しかしなんとそうではないのです。

なんと、旧Androidはトラストストアに入っている証明書の有効期限検証をおこなわないため、2021年9月29日より後も証明書検証に成功するらしいのです。何ということでしょう…。

このハックにより古いAndroidも救えるようになりました。かなりDirtyなハックでもあるのでどうかと思う人もいるかも知れません…。

これで、ほとんどの環境で、何も問題は起こらないし、何もする必要はないはずだ、とアナウンスされています。

いよいよデフォルトチェーンの切替

上の12月のエントリでは、1月末から2月にデフォルトチェーンを切り替えると書かれていましたが、それが例によって延びまして、正式なアナウンスが4月1日に出ています。

https://community.letsencrypt.org/t/providing-a-longer-certificate-chain-by-default/148738

5月4日にデフォルトチェーンを切り替えるというアナウンスです。これはさすがに延期されないんじゃないでしょうか。

このアナウンスでは、この新規のチェーンをlong chainと呼んでいます。このlong chainのハックを嫌って、古いAndroidを切り捨てても良い、ということであればISRG Root X1がルートになる"short chain"を利用することも可能なようです。この場合はお使いのACMEクライアントのpreferred chainオプションに"ISRG Root X1"を指定する形になります。

ちなみに、DST Root CA X3がルートになるshort chainを発行する方法はどうも無くなってしまいそうなので、チェーン変更による影響が心配な場合は、念の為切替前に一度証明書を更新しておいても良いかも知れません。

まとめ

何事も起こらないと良いですね。

ところで、会社の方でもEngineering Blogを始めたので、そちらもご覧いただけると嬉しいです。

https://engineering.nature.global/

エンジニアも積極採用中ですので、興味ある方は是非ご連絡ください。

https://nature.global/careers/job/

マンション購入記(勢いで購入を決めるまで)

家を買うつもりはあまりなかったが、ライフステージの変更に伴い買った、という良くある話です。2016年までの昔話です。

一応今の住所はあまり積極的にはネット上では公開していません。ただ、分かる人にはどのあたりか分かってしまいそうなので、その場合はそっとしてもらえると嬉しいです。

二子新地時代の購入未遂事件

結婚当初は僕は持ち家志向は強くなく、妻の方が比較的強かった。ただ、当時住んでいた二子新地が非常に気に入っていたこともあり、一度、近くの不動産屋に行ったことがあった。2011年頃の話。

確か二子玉の再開発絡みで周辺にマンションや建売住宅が建ちはじめていて、その中で当時の近所に建設中の分譲住宅が悪くない金額で売りに出されていたことがあった。それをふらっと内見させてもらい、それが良かったため、興奮した妻に連れられて不動産屋にまでも行くことになった。

「あーこれは買わされる流れかもな」と思っていたのだが、果たしてその物件は売約済みであり、その他いくつか紹介されたもののピンとくるものはなかった。

そして「もしかしたら近々会社が上場するかもしれないんですよね」とか話したら「でしたら、それまでお待ちになったほうがローン審査も通りやすいかも知れませんね」と不動産の方も言ってくれてその場は収まり助かった。当時はカヤックに勤めており上場前だった。

その後カヤックは上場まで時間がかかり、妻の持ち家志向も段々と目減りしていったこともあり、家の購入話は出なくなった。しかし、この頃の予算感では数年後には二子新地で家を買うことなど不可能になり、同等の金額で郊外にマンションを買うことになってしまうのだから東京のマンション高騰恐るべしである。

残念に思ってはいないが「カヤックがもっと早く上場してたら二子新地に家を買えたんだけどなー」と冗談を言うことがある。

ライフステージの変化

2015年に35歳にして子供が生まれ、当時住んでいた賃貸が手狭になることが見込まれたため、引っ越しを意識し始める。ただ、たまに検索して調べるくらいで、本腰では検討はしておらず、買うつもりもなかった。妻もそう思っていた。二人目をつくる可能性もあったし、一旦もう少し広めの賃貸に引っ越して、その後、家族構成を決めたら家を買うかも知れない、という感覚だった。

とは言え、今から思うと、この頃は以前と比べて家を買うことに対して抵抗感自体は少なくなっていた。収入が安定してきて、今後も安定させられるだろうと多少は自信が持てるようになってきたからだ。

また、妻としては子育てや老後までの生活は日本、そして実家が近い東京近郊が良いという意向があり、そこに対して僕も強い反対意見もなかったので、その後の人生において東京近郊が拠点にはなるんだろうな、とは思うようになっていた。

逆に、ソフトウェアエンジニアとして海外で働く可能性も当時は考え始めていて(今もたまに考えている)、その選択肢は残したいとも思っていた。ただ、東京はワンホップでいろいろなところに飛べるし、例え居を構えたとしても、単身赴任なども選択肢に入れれば、身軽さがそこまで損なわれる事も無かろうとも考えていた。

モデルルーム見学と即決購入

2016年の年始、妻が実家から一枚のチラシを持ち帰ってきた。マンションのモデルルームの案内である。場所としては妻の実家からもそこそこ近い郊外エリアで、立地は良く、好みのエリアで、値段も悪くない。週末冷やかしに行ってみよう、という話になった。それで、2016年1月16日にモデルルームの見学に行ってみたのだ。

結論を言うと、モデルルームでまんまと気に入ってしまい、その場で買うことを決めた。これまでの話の通り、他にどこも比較検討していなかったが、妻も非常に気に入っていたし、周辺の相場から大きく外れているようなことがなければ、別に迷うこともなかろうという判断だった。迷い出すとキリがない気もしたので。

見学一通り終わった後に「買うので予約させてください」と言ったら、逆に販売の担当者に「え…？もう決めちゃって良いんですか？」と困惑されてしまうくらいの即決ぶりであった。あまり「毛並みの良い客」だと見られなかったというのもあるのかも知れない。ただ、この販売の方が、ガツガツしてなかったのも逆に良いポイントではあった。

で、そこからローンの仮審査申し込みで「今の会社は勤続1年5ヶ月で4社目です」と申告したら、この担当者に絶句されて「えっ…、2社目ってことになりませんか…？」と謎の反応をされたのも面白かった。「え？そういうことして良いんですか？」って聞いたら「多くの方は精々2社とかですし、仮審査ですし…」とか言われたものの、流石にまずいだろうと思って(当たり前)、素直に申告した。どう考えてもまずい。

ちなみに当時は、はてな社に勤めていたが未上場だった。実はその翌週に上場承認が発表されるのだが、それは知っていたものの、逆に言ってはいけない状況なのであった。だから見学に行った日付も覚えているのである。

なので「カヤック」だとか「はてな」だとかフザけた名前の会社が職歴に並んでいて、未上場企業勤務で勤続年数も浅い人間が怪しまれるのも最もなことであった。タイミングが悪かったし、そんなタイミングでモデルルームに行ったのだからそもそも行く前は買う気はなかったのである。

何にせよ、初めて行ったモデルルームで即決購入とか、一般的にはやってはいけないことだと思います。

仮審査通過

仮審査はいくつか出して結局全部通った。担当者の方は、ネットで僕の経歴を調べたようだ、というようなことを言っていた。

大江戸Ruby会議04に参加した時に、amatsudaさんがHacking (My) Homeという面白い発表をしていて印象に残っていたのだが、その中の "They use Internet!" / "「社会的信用」on the net" が本当にあるのだなぁと感じた瞬間でもありました。

ということで、かなり勢いでマンション購入を決めたのである。

同じソースツリーでテストが通っていたらテストをスキップする

tl;dr

git rev-parse HEAD^{tree} でツリーオブジェクトのハッシュ値が取れるので、ブランチが異なる場合でも同じソースツリーであるかどうかを判定できます。

これを利用して、すでにテストを通ったtreeのハッシュ値をどこかに記録しておいて、同一のソースツリーに対するテストをスキップできます。

本題

よく使われている、develop/mainブランチ運用をしている場合に、ちょっとした修正を本番に入れたい場合には以下のようなフローを踏むことになるでしょう。

  1. featureブランチをdevelopブランチの先頭から切って修正を作ってテストが通るのを待つ
  2. developブランチにfeatureブランチにマージしてテストが通るのを待つ
  3. mainブランチにdevelopブランチをマージしてテストが通ったらdeployする

さて、この時、他の作業が混ざらない限りにおいては1,2,3のソースツリーの内容は実は全く同じです。それなのにテストが3回も回ってしまいます。これは無駄ですし、テスト時間が長い場合にはストレスです。

ソースツリーの内容が同じであればテストをスキップしたい

なので、ソースツリーの内容が同じであればテストをスキップすれば良いでしょう。幸いGitでツリーオブジェクトのハッシュ値を git rev-parse HEAD^{tree} で取得でき、これをソースツリーの内容の高速な同一判定に利用できます。

ref. https://git-scm.com/book/en/v2/Git-Internals-Git-Objects#_tree_objects

テストが通ったツリーのハッシュ値を記録する

後はテストが通った後に、テストをパスしたハッシュ値をどこかに保存しておいて、テスト実行前にそれを確認し、すでに通っていればテストをスキップすればよいでしょう。

Nature社では、CIにはCircleCIを使っているため、少し大げさな気がしますがハッシュ値の保存にはS3を使うことにしました。他に良いアイデアがあれば教えて欲しい！

ハッシュ値の保存

ハッシュ値をそのままファイル名として0byteのファイルをS3にputしています。

store-success-hash:
  docker:
    - image: cimg/base:stable
  steps:
    - checkout
    - run:
        name: install awscli v2
        command: |
          curl -s https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip -o aws.zip
          unzip aws.zip
          sudo ./aws/install
    - run:
        name: stores a hash of the tree object that has been successfully tested
        command: |
          set +e
          repotree_hash=$(git rev-parse HEAD^{tree})
          touch ${repotree_hash}
          aws s3 mv ${repotree_hash} s3://${treehash_bucket}/${repotree_hash}
          true # This step is always considered a success because it doesn't matter if it fails.

テスト前の確認

S3のpublic accessを開けておき、curlで取得して200が返ってきたらテストをスキップします。

test:
  docker:
    - image: golang:1.16.0
    - checkout
    - run:
        name: go test
        command: |
          repotree_hash=$(git rev-parse HEAD^{tree})
          set +e
          curl -f https://${treehash_bucket}.s3.amazonaws.com/${repotree_hash} 2>/dev/null
          status=$?
          set -e
          if [ $status = "0" ]; then
            echo 'skip testing because the test for the same source tree has already passed'
            exit 0
          fi
          go test ./...

public accessを空けておくのは乱暴ですが、bucket上にはハッシュ値ファイル名の空ファイルしか存在しないので大きな問題はなかろうという判断です。

またbucket上のファイルは3日でexpireする設定にしています。

まとめ

ちょっとした修正をリリースしたい時の待ち時間が減って最高です。ただ、store-success-hashの時間が地味にかかるので、短縮したいのですが、これも良いアイデアあれば募集です。

ちなみに、gitの状態に依存したテストを実施している場合等、この方法を避けたほうが良いケースもあるでしょう。hackishなテクニックでもあるので、自分の環境に適しているかどうかを確認してからご活用ください。

Thanks to

git rev-parse HEAD^{tree} でtreeのハッシュが取れるというのは @k_hanazuki さんに教えてもらいました！ありがとうございます！

関係ないボヤキ

採用情報

Natureでは一緒に高速にソフトウェア開発をするエンジニアを募集しています！

https://nature.global/careers/

GoでSQLにトレーシングコメントを埋め込んで実行する

アプリケーションが発行するSQLにコメントが埋め込めると便利です。例えば、 /* path/to/logic.go:334 */ SELECT ... のようにSQLに発行元の情報をコメントとして埋め込んでからExecすれば、DB側のログ(general log等)にも記録されるため、SREやDREサイドからも、負荷の高いSQLがアプリケーションのどこから発行されているかが分かりやすくなります。

Goには github.com/shogo82148/go-sql-proxy という、SQL実行をトレースし、フック処理を差し込める便利なライブラリがありますが、今回それにpull requestを送って、SQL実行前にクエリの書き換えができるようにしました。

これらの変更により、SQLにコメントを埋め込んでから実行できるようになりました。例えば、以下のように、PrePrepareとPreExecとPreQueryを定義してクエリ発行前にフックしてSQLを書き換えます。

ここで呼び出されている sqlComment 関数にコメントを埋め込む処理を定義します。PreExecやPreQueryで if stmt.Stmt == nil の判定をしているのは、事前にPrepareされている場合にはそこでコメントが埋め込まれているため二重にコメントが埋め込まれるのを避けるためです。

sqlCommentの実装は例えば以下のようになります。stmt.QueryString を書き換えることで発行するSQLを事前に書き換えられるという寸法です。

ここで、呼び出し元のファイル名と行番号を埋め込むために findCallerという関数を呼び出していますが、この処理は例えば以下のようになります。これは go-sql-proxyのソースコードからコピペして調整したものです。skipForSQLCommentでそこまで遡るかの調整ができますが、中身は利用者側で調整してください。

ということでSQLに呼び出し元のソースコードのファイル名と行情報を埋め込めるようになりました。それ以外にもトレーシングIDなどをコメントに埋め込めると便利です。Hook関数にcontextが渡ってきているためそこから取得すれば良いでしょう。

最近本番にも投入して、非常に便利に使っています。まだ導入のための記述量が多いので、ライブラリとしてもっと簡単に導入できるようになると良いとは思っていますが、便利だと思うので、ぜひ同様に活用してみてください。

余談

このSQLに呼び出し元の情報を埋め込むというテクニックは、日本のPerl界隈ではポピュラーで、TengやDBIx::Sunnyでは大昔に実装されていたテクニックです。Goでもかねてから実現したかったのですが、この度やっと追いつくことができたと感じています。

また、Google、ORMが生成するSQLが遅いときの調査を容易にする「sqlcommenter」をオープンソースで公開。Rails、Spring、Djangoなど主要なフレームワークに対応 という記事が公開されて話題になりそうだったので、焦って(?)このエントリを公開しました。

database/sqlのDB接続パラメータをアプリケーション内で明に指定する

tl;dr

Goのdatabase/sqlのDSN内のsql_modeやLocation等、固定したほうが良いパラメータ設定は、設定値に持たせるのではなく、アプリケーション内部で決め打ちしたほうが安全です。

本論

社内でMySQLを使っているので、それを例にとって書きます。

いわゆる、DSN(dataSourceName)呼ばれる、sql.Open に渡すDB接続文字列があります。これは、環境変数 DATABASE_URL 等に入れてアプリケーション内で読み出してDBに接続するでしょう。

DSNにはホスト名、ユーザー名、パスワードなどの接続先情報の他に、様々なオプションパラメータを記述することができます。以下にDSNの例を出しますが、この中の?以降がオプションパラメータです。

user:pass@tcp(myhost:3306)/dbname?collation=utf8mb4_unicode_ci&parseTime=true&loc=UTC&sql_mode=%27TRADITIONAL,NO_AUTO_VALUE_ON_ZERO,ONLY_FULL_GROUP_BY%27

しかしサービス開発において、それらのパラメータの全てを環境変数に直に設定することはおすすめしません。柔軟に色々設定できすぎてしまうことが逆に危険だからです。

DB Driverのライブラリレベルでは利用者の環境に合わせて柔軟に設定できて然るべきですが、Driverを利用する側のアプリケーションレベルでは決め打ちにした方が安全な項目も多いため、全てを設定可能にしておく必要はありません。

例えば、parsetime=trueが期待されているアプリケーションはそのパラメータが無いと動かないのでそもそも設定させる必要がないとか、sql_modeでkamipo TRADITIONALを強制したい、loc(Location)は決め打ちにしておきたい、などの要件があります。

この辺りは、開発環境、CI環境、ステージング、本番環境で揃っていたほうが変な事故も少なくなるため、設定させる余地を与えないほうが安全です。それらを設定可能にしておいて、ひょんなタイミングでずれたら怖い。特に本番運用中のDBにつなぐLocation設定が突然変わってDBの時刻がずれたら大事故です。

ですので、アプリケーションレベルでそれらを揃えてしまうのが良いでしょう。例えば以下のような具合です。

func DatabaseURL() (string, error) {
    databaseURL := os.Getenv("DATABASE_URL")
    c, err := mysql.ParseDSN(databaseURL)
    if err != nil {
        return "", err
    }
    c.Loc = time.UTC
    c.ParseTime = true
    c.Collation = "utf8mb4_general_ci"
    if c.Params == nil {
        c.Params = map[string]string{}
    }
    c.InterpolateParams = true
    // enforce kamipo TRADITIONAL!
    c.Params["sql_mode"] = "'TRADITIONAL,NO_AUTO_VALUE_ON_ZERO,ONLY_FULL_GROUP_BY'"
    return c.FormatDSN(), nil
}

値を決め打ちにするのではなく、おかしな値が設定されていたらエラーを返す手もあるでしょうし、os.Getenv を内部で呼び出すのではなくパラメーター渡しにしたほう良いという指摘も出てきそうですが、その辺りはお好みで。

これを以下のようにして使えばよいだけです。

dsn, err := DatabaseURL()
if err != nil {
    // エラー処理
}
db, err := sql.Open("mysql", dsn)
...

コードにしておけば以下のようなテストコードを書くことができ、設定されて欲しいオプションが間違いなく設定されていることが担保できるため、その点でも安心です。

func TestDatabaseURL(t *testing.T) {
   orig := os.Getenv("DATABASE_URL")
   defer os.Setenv("DATABASE_URL", orig)

   os.Setenv("DATABASE_URL", "root@tcp(localhost:3306)/testdb")
   expect := "root@tcp(localhost:3306)/testdb?parseTime=true&interpolateParams=true&sql_mode=%27TRADITIONAL,NO_AUTO_VALUE_ON_ZERO,ONLY_FULL_GROUP_BY%27"
   dsn, _ := DatabaseURL()
   if e, g := expect, dsn; e != g {
       t.Errorf("got %s, expect: %s", g, e)
   }
}

ところで最近は、秘匿情報を保管場所を分けて管理することが一般的になり、それ自体は良いことだと思いますが、逆にそれらの値がvalidかどうかのテストが難しくなっているようにも感じています。昔は各環境の設定ファイルをテストコード内で読み込んで正しいかどうかの確認などをしていましたが、それが難しくなったと感じています。その辺り何か工夫している方がいれば教えて下さい。

閑話休題。この方法で嬉しい副作用として設定値が見やすくなることがあります。オプションパラメーターを環境変数に長々と書く必要がなくなるため、例えば以下のようにDATABASE_URLを設定するだけで良くなります。

DATABASE_URL=user:pass@tcp(myhost:3306)/dbname

DSNが長くなりすぎて何を設定しているかわかりづらくなるとか、実はtypoしてパラメーター指定が誤っていたなどの事故も防げるので安心です。

実はその昔、Perlで似たような話を書いていましたが、今回はGoでのお話でした。

採用情報

Natureでは、バックエンドエンジニア、スマートフォンアプリエンジニア、その他職種を絶賛募集中ですので、ご応募お待ちしています!

https://nature.global/jp/careers

bashのシグナルハンドラ内でシグナルを特定する

シェルスクリプトのシグナルハンドラ内で受け取ったシグナルが何なのか知りたいことあると思います。しかし、単純に trap cleanup INT TERM ERR EXIT PIPE とするだけでは、cleanup関数内で受け取ったシグナルの種類を知ることができません。そこで、以下のようにすればシグナルの種類を知ることができます。

#!/bin/bash
set -Eeuo pipefail

cleanup() {
    echo "Trapped signal: $1"
    # script cleanup here
}

trap_sig() {
    for sig ; do
        trap "cleanup $sig" "$sig"
    done
}

trap_sig INT TERM ERR EXIT PIPE

# your script below

ループを回してtrapしたいシグナル毎にtrapを呼び出しています。

bashのテンプレートが話題になっていたのでなんとなく思い出したので書いてみました。

このテクニック自分で編み出したわけではなくて、出典を思い出してみると以下のstackoverflowで知ったようでした。

https://stackoverflow.com/questions/9256644/identifying-received-signal-name-in-bash

GoのWebアプリケーションでステータスコード499を記録する

この記事は、Go 4 Advent Calendar 2020の16日目の記事です。

さて、ある日、Goで書かれたHTTP APIサーバーのdeployをしたところ、急に500エラーの発生率が上がったことがありました。しかし幸いにもユーザー影響は出ていません。どうしたのでしょうか？

ALBログの調査

このシステムはAWSのApplication Load Balancer(ALB)からプロキシされていますが、エラーリクエストに対応するALBのログを調べるとステータスコード460が記録されていました。460を調べると以下のように書いてあります。

The load balancer received a request from a client, but the client closed the connection with the load balancer before the idle timeout period elapsed.
https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-troubleshooting.html

「ははぁ、これはNginxの499だな」とピンときました。サーバーがレスポンスを返す前に、クライアントが接続を切ってしまっている。例えば、スマートフォンが地下鉄など電波の届かないところに急に入ってレスポンスを受け取る前に切れてしまう等です。だからユーザー影響は出ていなかったのでした。

ところで、何故ALBはNginxと同様にクライアント断を499にしなかったのだろうと思ってしまいます。確かに499自体もそもそもは独自httpステータスコードではあるのですが、昨今4xx系のステータスコードも空きが減ってきているので、あまり独自ステータスコードを増やすのはお行儀が良くないのではないかと。ALBのエラー画面などは以前はNginxぽい感じでしたし、かなりNginxを意識して作られたサービスだと思うので余計にそう思います。

500エラーの原因判明

閑話休題。このシステムが500を返すのは、ハンドルできないerrorが上位に上がってきた場合なのですが、エラーログを確認すると果たして"context canceled"というログが記録されていました。つまり、contextのキャンセルエラーが伝播されてきて、それがハンドリングできていなかったということです。

このシステムでは、http handler内部でメインの処理に req.Context() を受け渡しています。近年GoでWebアプリケーションを書く場合には一般的なプラクティスでしょう。

ではこの req.Context() がキャンセルされるのはどの様な場合でしょうか？もちろんちゃんと公式ドキュメントに書かれています。

For incoming server requests, the context is canceled when the client's connection closes, the request is canceled (with HTTP/2), or when the ServeHTTP method returns.
https://golang.org/pkg/net/http/#Request.Context

クライアントが接続を切ったか、ハンドラーが終了したときにキャンセルされると書いてあります。今回の場合はハンドラー内部でキャンセルエラーを受け取っているため、クライアントが接続を切ったと考えると良さそうです。ALBに460が記録されているという事実とも合致します。

つまり、クライアントの接続断が起因でcontextがキャンセルされ、ハンドラー内部の処理もキャンセルされて、エラーが上がってきたというわけです。

実際、当該deployには、処理の内部でcontextを引き回せてない部分をちゃんと引き回すようにする修正が入っていました。それが原因でした。

解決方法

ユーザー影響は出ていないとは言え、この様なときに500エラーを返しっぱなし、正確に言うとクライアントには返っていないので記録しっぱなしにしておくのは、オペレーションの観点からもよろしくありません。ここは、Nginxに倣って、499を記録することにしましょう。

参考のため再掲: https://httpstatuses.com/499

errors.Is(err, context.Canceled) とチェックをしてその場合に、499を返せばよいと思うかも知れませんが、そう単純ではありません。処理内部で内部で context.WithCancel が使われるなどして、そのキャンセルエラーが上がってくる可能性があるためです。つまり、context.Canceledであっても必ずしもreq.Context() 自体がキャンセルされたとは限らないのです。

req.Context() がキャンセルされたかどうかを判断するためには、req.Context()が完了しているかどうかを判定すればよいでしょう。以下のように select と default を使うと良さそうです。リクエストが完了していない場合はdefaultに入るため、その下の処理に流れていきます。

select {
case <-req.Context().Done():
    w.WriteHeader(499)
    return
default:
}

まとめると、メインの処理が返してきたerrorをハンドリングして、必要な場合に499を記録するコードは以下のようになるでしょう。

const httpStatusClientClosedRequest = 499

func(w http.ResponseWriter, req *http.Request) {
    if err := mainProcess(req.Context()); err != nil {
        if errors.Is(err, context.Canceled) {
            select {
            case <-req.Context().Done():
                w.WriteHeader(httpStatusClientClosedRequest)
                return
            default:
            }
        }
        http.Error(w, "Internal Server Error!", http.StatusInternalServerError)
        return
    }
    ...
}

これで、500エラーが出なくなったためアラートも収まり、安心して眠れるようになりました。めでたしめでたし。

採用情報

ということで、スマートリモコンNature RemoなどのIoT製品を開発している、Natureでは、このように細かい割れ窓も素早く察知し、詰めをしっかり実装できるエンジニアを募集しています。興味のある方はぜひご応募ください。

https://nature.global/jp/careers

あなたは本当に文章を書くのが遅いのか

このエントリーは、Mackerel Advent Calendar 2020 5日目の記事です。

さて、多くの人が「自分は文章を書くのが遅い」と思っているのではないでしょうか。僕もそう思っていました。

ブログエントリーを書き出すと得てして思っていた以上の時間がかかります。書くことがだいたい決まっているちょいネタのつもりであっても書き出してみたら数時間かかってしまう、大作であれば丸一日潰れてしまったり、しばらく寝かして数日がかりになることも珍しくありません。そして「ああ、自分は文章を書くのがなんて遅いのだ」と嘆いてしまうのです。

そして、見事な大作ブログ記事をバンバン投稿している人を見ると「書くのが速い人は羨ましいなー」と羨望してしまいます。また故栗本薫氏が、一時間に原稿用紙96枚分を書いたなどの伝説を聞くに、圧倒されて唖然としてしまい、やる気を失ってしまいそうになります。

しかし果たして本当にあなたは文章を書くのが遅いのでしょうか？

「時速1000字で書く技術」という本があります。A4一枚がだいたい1000文字程度であり、それを1時間程度で仕上げる技術の身につけ方などについて書かれています。また、筆者本人の例を取り、プロの文筆家であっても、長い文章を書く場合、均せば大体時速1000字くらいであるということも書かれています。

つまり、時速1000字で書ければ充分に速いのです。これは意外に少なく感じるのではないでしょうか？

結局、たくさん文章を書いているように見える人は、一部の例外を除き、それだけの時間を使っているのです。実際、一時期毎月圧倒的なブログエントリーを書いていたエンジニアが元同僚にいましたが、彼が実はブログを書くために毎月有給を取って休んでいたことを僕は知っています。

推測するな計測せよ

そういえば、これはMackerel Advent Calendarなのでした。ということで「遅い」と推測するのではなく、実際に速度を計測してみましょう。

Macをお使いなのであれば非常に簡単に実現できます。mackerel-agentをhomebrewでインストールし、以下の様なシェルスクリプトをプラグインとし、mackerel-agent.conf に設定するだけです。

#!/bin/bash
export LANG=ja_JP.UTF-8
export LC_ALL=ja_JP.UTF-8
chars=$(cat /path/to/*.md | wc -m)
echo "chars.writing.manuscript $chars " $(date +%s)

値の取得に1行、出力に1行と、実質2行のシェルスクリプトで実現できてしまいます。ちなみに、LANG等の環境変数設定を入れないと wc の -m (multibyte) オプションが効いてくれなかったのでこうしています。こういうちょっとした計測をサクッと作れるのはMackerelの良いところですね。

更に乱暴なハックとして、mackerel-agent.confに直接書いてしまう手もあります。

[plugin.metrics.chars]
command='''
    export LANG=ja_JP.UTF-8;
    export LC_ALL=ja_JP.UTF-8;
    chars=$(cat /path/to/manuscript.md | wc -m);
    echo "chars.writing.manuscript $chars " $(date +%s)
'''

実際、たまに書籍や雑誌の執筆依頼をお受けすることがありますが、そんな時はこんな感じで計測しています。

さて、このエントリーを書くのにもこのプラグインを使ってみました。結果はどうだったでしょうか？

時速1000字以上のスピードで書けています。やや速めに思われてしまうかも知れませんが、プラグインのコードがあるのでそれで文字数を稼げてしまっているというのがあります。ちなみに途中、山が出てから凹んでいるのは、アフィリエイトコードを貼り付けたら跳ねてしまったので、それは執筆中は削ったという経緯です。

ということで、どうやら僕自身の文章を書く速度は特別速いわけではありませんが、決して遅いわけではないということが分かってしまいました。そして、多少なりともブログ記事などを書いたことのある人であればそれくらいの速度は出るのではないかと思っています。つまり、おそらくあなたの文章を書く速度は残念ながら遅くありません。

結局、文章を書く世界でも、圧倒的な天才に惑わされず、時間を使って地道に頑張る。そうすれば、超一流にはなれずとも、それなりのレベルにはなれる、というどの世界でもよくある話でしかないのだな、と思うようになりました。

余談

「800字を書く力」という同じく字数がタイトルに含まれる、文章の書き方を扱った書籍があります。この本の中の「文章は、書くと書ける」という表現が気に入っています。つまりプロの文筆家も、書きながら考えていて、書く文章が全て最初から頭の中に入っているわけではなく、試行錯誤しながら内容を固めていく、というようなことが書かれていました。

意外に感じたのですが、考えてみればこれは我々ソフトウェアエンジニアも同じです。多くの場合書きながら設計して最終形を固めていくわけです。これも、それを専門としない人たちからすると意外に感じられることもあるのだろうな、と思っています。

そして「書くと、書ける」。これは文章にせよソフトウェアにせよ肝に銘じたいものです。

ECSのScheduled Taskを管理するツールを作った

その名もecschedule。だいぶ前から作っていたのだが、この度実戦投入した。

https://github.com/Songmu/ecschedule

Nature社では、ECS上でGoのサービスを動かしており、バッチ系の定期実行タスクもECS Scheduled Taskを利用している。

最近バッチの本数が増えてきて管理したくなり、このツールを導入しました。

便利だとは思うが、かなり社内事情にべったりであるため、フィードバック歓迎です。具体的には以下の制約を前提としています。

ecspressoにかなり影響を受けており、ECS Scheduled Task用のecspressoのような作りになっています。

インストール

% brew install Songmu/tap/ecschedule
# or
% go get github.com/Songmu/ecschedule/cmd/ecschedule

導入方法

以下のコマンドで設定をダンプします。

% ecschedule dump --cluster clusterName --region us-east-1 > ecschedule.yaml

これを、環境変数を変数化するなどして調整すると以下のようになります。must_env あたりにecspressoリスペクトが感じられます。

region: us-east-1
cluster: clusterName
- name: taskName1
  description: task 1
  scheduledExpression: cron(30 15 ? * * *)
  taskDefinition: taskDefName
  containerOverrides:
  - name: containerName
    command: [subcommand1, arg]
    environment:
      HOGE: foo
      FUGA: {{ must_env `APP_FUGA` }}
- name: taskName2
  description: task2
  scheduledExpression: cron(30 16 ? * * *)
  taskDefinition: taskDefName2
  containerOverrides:
  - name: containerName2
    command: [subcommand2, arg]

変更の適用

設定ファイルを編集して、ルールの変更を適用したい場合には、apply サブコマンドを利用します。

% ecschedule -conf ecschedule.yaml apply -rule $ruleName

事前に diff サブコマンドを叩いておくと変更差分が確認できるので便利です。

% ecschedule -conf ecschedule.yaml diff -rule $ruleName

全部のルールを一斉に適用したい場合には apply サブコマンドに -all オプションを付与します。差分があるものだけが適用されます。

% ecschedule -conf ecschedule.yaml apply -all

弊社ではこの-allオプションをdeploy時に自動適用するようにしています。一斉自動適用最初はちょっと怖かったのですが、特に問題なく動いています。

goccy/go-yamlは神

このツールを作り始めた頃に、既存のGoのYAMLライブラリが理想の挙動にならなくて困り果てており、自分で作るかという沼にハマりかけたところに、goccyさんが颯爽とイケてるyamlライブラリを作り始めてくれて助かりました。皆さん使いましょう。

https://github.com/goccy/go-yaml

ということで、ecschedule も便利ですのでぜひご利用ください。