YAMAGUCHI::weblog

噛み付き地蔵に憧れて、この神の世界にやってきました。マドンナみたいな男の子、コッペです。

「実践プロパティベーステスト」という本が出版されました #pbtbook

はじめに

こんにちは、Google Cloudのオブザーバビリティ/SRE担当者です。このたび私が翻訳しました「実践プロパティベーステスト PropErとErlang/Elixirではじめよう」という書籍がラムダノート社より去る11月1日に出版されました。書店ならびに各社オンラインストアでご購入いただけます。

実践プロパティベーステスト ― PropErとErlang/Elixirではじめようwww.lambdanote.com

電子書籍についてはラムダノート社のECサイトよりご購入いただけます。

実践プロパティベーステスト ― PropErとErlang/Elixirではじめよう(電子書籍のみ)www.lambdanote.com

「実践プロパティベーステスト」はどのような本か

本書の内容に関しては、すでにラムダノート社の書籍紹介ページで十分に説明されているので、まずはそちらをご一読ください。

www.lambdanote.com

プロパティベーステスト(以下、PBT)は関数型プログラミング言語界隈で発展してきた経緯もあり、ユニットテストやファジングと比較するとあまり浸透していないのが現状です。また使い始めようと思うとプロパティを書くところで難しさを覚え、独学でマスターするのはなかなかにハードルが高いものです。実際に私もその部分がネックで、PBTを学びたいと思いつつ、何度か挫折をしていました。そんな中、本書を初めてオンライン版で読んだときに、相変わらずFredのユーモアある解説に感心しつつ、この本であれば習得できるかもしれないと思いました。

本書は、まずPBTとは何か、それ自体の解説から始まり、PBTの根幹である「プロパティ」についての解説、そして探索をうまく行うために欠かせない「ジェネレーター」のカスタマイズ方法、失敗したテストを理解しやすくするための「収縮」の解説、さらにはステートフルなシステムをテスト対象にできる「ステートフルPBT」の解説、とPBTを一通り学ぶために必要な知識を網羅しています。解説に使うサンプルコードやその結果の特性はErlang/Elixirという言語やPropErというPBTフレームワークに依存する部分もありますが、他の言語のPBTフレームワークも大なり小なり同様の機能をサポートしていますので、読み替えを行うことでPBTより深く学べることでしょう。

そもそもPBT自体があまり脚光を浴びることはありませんでした。しかし計算資源をより活用して、ステートレスPBTでユニットテストを強化することはもちろん、ステートフルPBTでe2eテストを強化すること、それこそがソフトウェアエンジニアリングではないでしょうか。もちろん、PBTの場合、プロパティやジェネレーターの実装や、テストを走らせる上での時間的なコストはあります。これは私が普段触れているオブザーバビリティの領域でも同様です。網羅的かつ効率的に探索を行うことで、仕様策定時や実装時に気が付かなかった問題を発見し、その原因を突き止められる確率が高まることの価値は、ますます高まっています。そういった文脈で、本書は皆さんの道具箱に道具を1つどころか、引き出しを1つ追加してくれる、そんな一冊です。

「実践プロパティベーステスト」が出版されるまで

本書はFred Hebertによる "Property-Based Testing with PropEr, Erlang, and Elixir" という書籍の日本語訳版です。原著は2019年1月に出版されました。

以前私は同じくFred Hebertが著した "Learn you some Erlang for great good!" の日本語訳「すごいErlang ゆかいに学ぼう!」(以下、すごいE本)という本の翻訳を行いました。

すごいE本の詳細に関しては出版時にエントリーを書きましたのでご参照ください。

ymotongpoo.hatenablog.com

すごいE本ではErlangの基礎から始まり、OTPの発展的な使用方法まで網羅していました。もちろん、その中にはテストに関する章もあり、たとえばEUnitの関する基本的なところから、静的解析(Dialyzer)まで行うのですが、それ以外のより発展的な検証については一切触れられていませんでした。Erlangのエコシステムを知りつつ、他の言語で主に開発を行っていた身としては、Erlangの達人たちが使いこなしていたプロパティベーステスト(PropEr)に関する情報がもっと出てきてほしいなあと思っていました。

そんな折、2017年の半ばにFredがまたPropErに関するテキストをウェブで公開し始めました!

propertesting.com

そこにはいままで知りたいと思っていたプロパティベーステストをPropErで実施するための考え方を、すごいE本と同様に一から紹介してくれるものでした。しかも前回とは違い、Creative Commonsではなく、All rights reservedとのこと。これは本が出るのではないか?と思いウェブ版が完成した2018年後半のある日Fredに連絡してみると出版予定とのこと。そこで、すごいE本の編集を担当し、その出版後、オーム社から独立されラムダノートを設立された鹿野さんにダメ元で連絡してみました。

「Fredが書いたプロパティベースベストに関する良書があるんですが、翻訳できませんか」

ラムダノートでこの本を出版する場合、編集作業等で割かれる時間や在庫を考えると、この本はリスクの高いものであることは明らかでした。使用言語はErlang/Elixirという、一応知られてはいる言語であるものの、まだメインストリームとは言えない言語で、さらにテーマは発展的内容のプロパティベーステスト。それだけ見ればニッチ極まりない本です。

しかし、このプロパティベーステストという手法そのものは、計算機の力を活用した素晴らしいテスト手法で、原著出版当時からメジャー言語向けフレームワークも一応存在していました。この本によって需要を起こせるかもしれない、という期待も鹿野さんは理解してくださり、プロジェクトが始まりました。翻訳権の獲得から始まり、原稿用レポジトリの用意までが整ったのは2019年4月。そこからコツコツと翻訳を続けて半分程度まで終わっていたのですが、2020年3月に新型コロナウイルスの蔓延とともに仕事や家庭の状況も一変し、なし崩し的に一時翻訳が中断してしまいました。

その後、2022年5月にようやく生活が落ち着いたこともあり、また並行して走っていた他の翻訳プロジェクトが区切りが付いたため、一気呵成に取り組み2022年6月には一度翻訳を終わらせました。しかし、今度はここから訳文自体の日本語をより自然にする編集作業が始まりました。一度スケジュールが崩れてしまったため、鹿野さんには別の大きなお仕事の合間に編集を行ってもらいつつ、自分は細かな修正をするという作業が続き、とりあえず識者レビューをいただける形までになったのが2022年11月でした。識者レビューを経て、もう一度巻頭から編集し直して、2度めの識者レビューを頂いたのが今年の9月。そこから細かな修正が行われ、10月半ばに無事に校了したという流れでした。

私はこれまでオライリー・ジャパンでの翻訳でお二人の担当に付いていただき、オーム社とラムダノートでは鹿野さん、高尾さんに編集いただいたわけですが、やはり皆さん様々に特徴があると感じました。ラムダノートのお二人の編集は、編集者として徹底して日本語を整えてくださる印象がありました。実際に自分でも読み返してみると、編集前後で日本語として読みやすさが向上していると感じました。

気がつけばきっかけとなったウェブサイトの公開から6年も経っているわけですが、しかしながらその技術的な内容はまったく陳腐化していません。これはPBTがそれだけ強力な概念であるということの証左ではないでしょうか。早く出版できなかったのはひとえに自分の至らなさではあるわけですが、ようやく出版できていまは肩の荷が降りた気持ちです。

他言語におけるプロパティベーステストについて

本書はErlang/Elixirを中心にPBTの解説をしているわけですが、その考え方は汎用的なもので、他のプログラミング言語でも写経しながら進められると思います。以下が自分が知っていたり、ぱっと調べた限りでの他の言語でのPBTフレームワーク一覧です。(網羅しているわけではありません。)

もちろんフレームワークによって対応の度合いは異なるので、これらを使って本書をErlang/Elixirとまったく同様に進められるわけではありません。たとえばPythonのHypothesisではジェネレーターは意図してランダム値になるように振っていて、PropErのように意図して偏らせるようなことができません*1。また上には列挙していませんがGoのgopterというフレームワークではステートレスPBTしか実現できません*2

謝辞

書籍中の謝辞でも書いていますが、あらためて、本書は次のみなさまのご協力なしには出版はありえませんでした。特にErlang/Elixirに関しては趣味レベルの私とは異なり、業務でErlangとPBTを使われていた経験がある、また今まさに現役でErlang/Elixirを書いている皆様方からいただけたレビューは本書の質を最後に押し上げてくださるものでした。あらためて感謝いたします。

レビュアーのみなさま(五十音順)

  • 上西康太さん(@kuenishi)
  • 大田健さん(@sile)
  • 大原常徳さん(@ohr486)
  • 篠原俊一さん(@shino)
  • 宮崎達矢さん(@ta_ta_ta_miya)

ラムダノートのお二方

  • 鹿野桂一郎さん
  • 高尾智絵さん

いただいたレビュー(随時更新)

*1:無理やりに実現することは可能ですが、フレームワーク作者はその方針ではない

*2:gopterは開発が3年ほど停止しているので挙げませんでした

SRE NEXT 2023でクロージングキーノートで登壇しました

はじめに

こんにちは、Google CloudでオブザーバビリティとSREの担当をしているものです。去る2023年9月29日、SRE NEXT 2023というSRE関するカンファレンスにて、僭越ながらクロージングキーノートスピーカーを拝命しましたため、その責務をまっとうして参りました。

sre-next.dev

「信頼性目標とシステムアーキテクチャー」

発表スライドと当日の録画へのリンクはこちらです。

speakerdeck.com

www.youtube.com

クロージングキーノートという貴重な機会をいただいたわけですが、自分の立場として参加者の方々に何を一番伝えたいか、何が求められているのかなど、依頼を頂いてから悩ましい時間が多くありました。SREというのはたくさんのプラクティスのまとまりですが、やはり自分が伝えたいことがあるとすればSLOに関わることだなと思い、セッションタイトルだけ思いついたので、細かな内容がまだなにも思いついていない状態で運営の方にお伝えしました。

詳細はセッションスライドと録画を見ていただくとして、この発表で伝えたかったことは

  • サービスレベル目標を決めると、自ずとシステムのアーキテクチャーや開発のプラットフォームに影響が及ぼされるということ
  • 信頼性目標にたどり着くためのアーキテクチャーは対話によって妥当な点を見出すしか無いこと

発表の中では確率を例にして検討を重ねていますが、こういった検討そのものが開発や運用のチーム全体で共通に認識されるべきもので、検討の末に必要になったもの費用も論理的に導かれることが伝われば幸いです。プラットフォームエンジニアリングという言葉もありますが、発表の中でも述べているように、ある程度以上の信頼性はプラットフォームがなければ達成できませんし、Four Keysも本来であればSLOを達成すべきプロセスの文脈で出てくるはずのものです。

このセッションをきっかけに、一人でも多くの方にSLOの有用性が伝われば幸いです。

こちらの書籍にも本セッションで話した内容が触れられていますので、ぜひご一読ください。

r9y.dev 盛り上げていきましょう!

自分のセッションの中で紹介した r9y.dev は「SREエンタープライズロードマップ」を著したSteve McGheeやJames Brookbankが始めたプロジェクトで、各信頼性目標に応じて必要になるテクノロジーを議論しながら作っているものですが、皆さんからのフィードバックやレポジトリへのプルリクエストを元に発展しているものです。ぜひdiscordに参加してコメントをいただけると嬉しいです。

discord.com

またオンラインで公開ディスカッションを行っているのですが、日本からの参加者が多くあると事前に分かればAPAC時間での開催もできると思うので、是非discordやGitHubのレポジトリで提案してください!

SRE NEXT 2023の熱気がすごかった

SRE NEXTへは初回の2020年の回から3回連続で登壇の機会をいただき、個人的には思い入れのあるカンファレンスの1つです。

sre-next.dev

sre-next.dev

特に日本でSREに関するトピックだけを扱った(SREをカンファレンス名に冠した)数百人規模のカンファレンスというのはSRE NEXTしかなく、その点で個人的にとても応援しているカンファレンスでした。そして今年はオンサイトイベントとして復活した回だったわけですが、セッションの内容が「SREのプラクティスを実践してきての学びや振り返り」に関するものが多く、明らかにコミュニティのSREに対する理解や実践度合いが進んできていると思いました。また会場の雰囲気も活気があり、これからが本当に楽しみなカンファレンスだなあと感じました。

自分はSREcon APACの20222023でProgramme Committeeに参加したのですが、SREcon APACのセッション内容と比較しても、SRE NEXTは実践的な内容が多く、日本のSREコミュニティの質の高さが伺えました。SREconの場合はグローバルサービスの運用に関する発表が多いですが、SRE NEXTは日本ローカルならではの小中規模の組織での実践の話が聞けるのが貴重だなと感じます。

個人的に好きだったもの

セッションに参加したりブースを回ったりして面白かったものを、Xに投稿されていた写真をお借りして振り返ろうと思います。

私が翻訳や監訳に関わった3冊(「SLO サービスレベル目標」「オブザーバビリティ・エンジニアリング」「SREの探求」)の途中率が高いので、読了率を上げる企画をなにかしたい!(アイデア募集中)

セッションの合間に流れるこの映像とかセッション開始時のティザー動画とか、めちゃくちゃかっこよく作られてて、ただ感心していました。

わざわざ広島からいらして運営にも参加してくださっていた @okash1n さんの「ワキヤコーヒー」さんのコーヒーは美味しかった!

オライリー・ジャパンさんのブースはありがたいことに私の翻訳、監訳に関わった書籍(上記の3冊に加えて「Go言語による並行処理」も)を販売してくださっていました。こういうところで自分の本を紹介できるのは嬉しい!

ホールウェイトラックも大いに盛り上がって、新しいイベントの企画とかその場で決まっちゃう感じがコミュニティの勢いを感じました!写真に写っている逆井さんにも登壇してもらうOpenTelemetryのイベントが今月半ばにあります!

opentelemetry.connpass.com

Topotalのインシデント管理ツールのWaroomのデモを見せてもらいました。オープンベータが出たときに触らせてもらったときから、すごく進化していてこれからどうなっていくのか楽しみです!

おわりに

また来年も開催されることを願っています。今年の後半は自分はだいぶSLOを中心にメタな登壇が多かったので、来年は少し技術を深ぼった内容の登壇にまた戻していきたいという気持ちになったカンファレンスでした。運営の皆様、お疲れ様でした!

関連リンク

togetter.com

冬キャンプのほうが好きな理由

はじめに

先日、友人家族とデイキャンプをしたんだけれども、まだ友人家族は宿泊するキャンプをしたことがなく、色々とハードルがないか調べているところだったそう。なにかを決めるときは色々な制約があるわけだけれども、様々な理由から自分は冬キャンプのほうが好きなので、理由とともにそれをお伝えしました。

せっかくなのでメモとして自分が冬キャンプのほうが好きな理由を説明していこうと思います。なお、前提として自分は東京在住で、冬キャンプは主に南関東道志村〜富士周辺、山梨県北杜市の南側などに行くことがほとんどです。

TL;DR

自分はおおよそこういった理由で冬キャンプのほうを好んでいます。

  • 虫が出ない
  • 日焼けしない
  • 暑くない
    • 熱中症の心配がない
    • お風呂に入らなくてもなんとかなる
    • 食べ物が腐らない
    • 冷たいものは冷たいまま飲める
    • 寝やすい
  • 人が少ない
  • 大気が安定していて天気が予想しやすい
  • 星が綺麗
  • おこもりキャンプがしやすい
  • 焚き火のしがいがある
    • 焚き付けの木を拾いやすい

冬キャンプが好きな理由

虫が出ない

自分は虫一般は好きなので、気がついたらテントの中にバッタやカマキリが居たりするのはむしろキャンプの醍醐味だと思っているのですが、蚊やアブは嫌いです。刺されたら痒いを通り越して、アブなんかだとめちゃくちゃ腫れます。最悪です。あまり頻度は高くないですが、夏はムカデやスズメバチなんかも出てきます。「虫が苦手なのでキャンプをしたくない」という方がいう「虫」がどこまで含まれるのかは人によると思うのですが、昆虫好きでも蚊やアブに喜んで刺される人は相当マニアックな人だと思います。

害虫対策として

  • 長袖を着る
  • 虫除けスプレーをかける
  • 強力な蚊取り線香太巻き蚊取り線香やパワー森林香など)をいくつも焚く
  • ヤブ蚊バリアといったスプレー剤を地面に撒く
  • 虫取りUSBランタンを点ける
  • オイルランタンに虫除けパラフィンオイルを使う

などさまざまにありますが、100%防げるわけではありません。冬は害虫含め、虫全般はほぼ活動していないため、こういった懸念をする必要がありません。

日焼けしない

夏は暑さから半袖を着がちで、風通しのいいオープンタープの下などで過ごしがちとなります。日も長いため、日に当たる確率はかなり高くなります。日焼け止めを塗ったりはしますが、汗をかいたり、それを拭いたりするなかでどんどん取れてしまい、塗り忘れなどで日焼けをすることも多くあると思います。虫対策とあわせて、可能であれば長袖をを着るのが賢明でしょう。自分はこうした理由から夏は日差しを避けられる林間サイトを選びがちです。もちろん、その分虫は増えるのですが。

しかし冬であればそもそも防寒のため長袖を着ています。また寒さ対策のため、サイドやフロントの跳ね上げはするにしても、テントの中で過ごすことも多いため、日焼けを気にすることはありません。

暑くない

日本の夏は暑いです。特にここ10年は最高気温が35度を超えることも多く、ひどいときには40度近くにもなります。標高1000m近いキャンプ場でも日中は30度を超えることがざらにあります。*1熱中症の懸念がいつもあるので、標高の高い場所でかつ日陰が多い林間サイトや風が涼しい川沿いの涼しいキャンプ場でないと行きたくないと感じています。冬であれば当たり前ですが暑くはありません。寒くはありますが後述するように防寒対策で十分対応できます。

熱中症とまでいかなくとも、結構汗をかいたりするので、夜寝る前にお風呂に入りたくなります。高規格キャンプ場でお風呂やシャワーが併設されていたり、近くに温泉があるキャンプ場なら良いですが、そうでなければ汗拭きシートなどでお茶を濁して寝ます。場所によっては寝苦しい夜にもなります。日の出が早いので朝早くから気温が上がります。1泊で帰るとしても撤収する頃にはもう汗だくです。冬は汗をかくこともなく、自分だったらキャンプなら2日くらいだったらお風呂に入らなくてもいいかなあ、という感覚で過ごしています。また翌日に日中温泉に行くときも、冬の露天風呂など風情があって良いです(好みによる)。寝るときも装備があれば暖かい寝袋でぐっすりと眠れます。

夏は気温が高いので、外で食材を扱うときも注意が必要です。肉などは特に注意が必要で放っておけば腐ってしまいます。また夏の暑いときに限って飲みたいのは冷たい飲み物です。僕は自然の中で飲む冷たいビールは夏キャンプの醍醐味の一つだなと思うわけですが、一方でそれを実現するには保冷を頑張る必要があります。キャンプを続ける中で、2泊3日程度であれば前日の買い出しのみで冷たいビールを2日目夜まで維持するテクニックを獲得しましたが、やはり面倒です。食材も腐らせないようにテクニックを駆使したりします(例: そもそも食材自体を凍らせて持っていくなど)。しかし、冬はそんなことを気にしないでもそもそも気温が冷蔵庫なみの温度なので、特にビールの温度や食材の傷みなどは気にしないでも問題ありません。むしろ凍らせたくない食材をクーラーボックスに入れます。現代のテクノロジーでは冷やすよりも温めるほうが圧倒的に簡単なので、キャンプは気温が低いほうが何かと便利です。

人が少ない

キャンプは世間一般だと夏のアクティビティだと認識されているせいか人も少なく、冬はキャンプ場もオフシーズン価格になっていたりします。人気のキャンプ場も冬ならば予約が容易だったりします。人が多いキャンプ場、特にフリーサイトのキャンプ場だと、車を駐めるのも一苦労、テントの設置も限られたスペースで行わなければならないこともあったりします。また洗い場やトイレも混雑していたりします。人が少ない冬の時期では、そういった人の多さに起因するストレスはあまりありません。

大気が安定していて天気が予想しやすい

夏は気温が高いため雲が発達しやすく、近年ではゲリラ豪雨と呼ばれるような、突発的な雨も増えています。キャンプの懸念事項として挙げられやすいのは雨ですが(個人的には人が少なくなるのであえて雨キャンプに行くということもしますが)、キャンプに慣れてある程度対応できるならまだ良いですが、あまり準備もできておらず、また設営も不慣れなうちに大雨に降られてテントの浸水体験などをすると心が折れかねません。ここ数年はTC素材のテントも流行っていますが、雨に対してはTC素材は弱いため、悲惨な結果になる人もいます(吸水して重さで最悪テントが潰れる)。また台風でそもそもキャンプの予定自体を諦めなければいけないというリスクもあります。設置や撤収の際の雨もスピードが問われ、慣れていないと荷物がずぶ濡れになるなど大変な思いをします。

その点冬は大気が安定していて、かなりの確率で予報通りになることが多いです。もちろん予想外の雨が降った場合の備えは持っては行きますが、概ね杞憂で終わることが多いです。また予想外に降られたとしても夏のような大雨になることはあまりなく、テントの中にいれば快適に過ごせます。

星が綺麗

これは夏冬関係なく、晴れていれば見える場所ではきれいに見えるわけですが、冬は乾燥しているため特に星が綺麗に見えます。星にあまり興味がない人であっても、少し山に近い明かりの少ないキャンプ場で夜にテントから出たときに、空一面に広がる星を見たときは思わずため息が出るのではないでしょうか。冬は夜の時間が長いためこうした星空を長く楽しめるのも良いですね。

おこもりキャンプがしやすい

夏はとにかく日光が強く気温も高いため、テントの中は蒸し暑くなってしまいます。これはベンチレーションを開けてサーキュレーターを回したとしてもどうにもなりません。夏キャンプの場合は寝る直前までオープンタープで過ごして、寝るときだけテントに入るということになります。私は一人で行くときはもはやそれに耐えられず、夏はハンモック泊やタープ泊をしています。(夏はこの装備になれるとその手軽さや涼しさから辞められなくなりましたが、それはまた別の話)

冬は逆に寒さを凌ぐために囲いがあるテントの中が快適空間になります。布一枚でも囲いがあるだけで随分違うものです。また最近はキャンプ用家電も充実しているので、ポータブル電源やモバイルバッテリー接続で電気毛布などを使うと、随分暖かくなります。自己責任で注意深く使う必要はありますが、灯油ストーブなどを点けると、換気用にベンチレーションを開けていても、ダウンなしで十分暖かく過ごせたりします。わざわざキャンプ場に行ってテントにこもるというのは矛盾しているように聞こえるかもしれませんが、テントの中で煮炊きをしてゆっくりと過ごすというのはそれはそれで楽しいものです。特に何かアクティビティをしたいわけではないけれど、自然に近いところでのんびりしたいオートキャンパーにはおすすめのスタイルです。

焚き火のしがいがある

焚き火をするという行為そのものはオフィス勤務の自分には非日常感があって、キャンプならではのアクティビティです。しかし夏は暑い。暑さに加えて焚き火の熱が来るとこれはもうたまりません。外で熾火や炭火で焼いた肉は格別に美味しいのですが、とはいえ暑い。暑いのです。

ところがこれが冬になると、焚き火も立派な暖房器具となります。スチール製のリフレクターで囲うと、防風できるだけでなく、輻射熱により焚き火の前は非常に暖かくなります。また薪も乾燥しているため、よく燃えます。寒い季節は、焚き火を見ながら暖かい飲み物を飲むという事自体で幸せを感じます。コーヒー、ココア、ホットワインウイスキーや焼酎のお湯割り。どれも想像しただけで過去のキャンプのリラックスした時間を思い出します。

またキャンプ場によってはサイト内に落ちている枯れ木を焚き木や薪にして良いのですが、冬はそういった枯れ枝や松ぼっくりがよく落ちていて、また乾燥もしているため、焚き火に困ることがありません。

夏キャンプのメリット

これまで夏キャンプが苦手だという話ばかり書いてきましたが、それでも夏にもキャンプをします。夏キャンプの好きなところも当然あります。

  • 装備が軽くて良い
    • 軽装で過ごせる
    • 凍死する心配がない
  • 川や海のアクティビティが楽しめる
  • 山が気持ちいい
  • テントがすぐに乾く

装備が軽くて良い

よっぽど標高の高い山にでも行かないかぎり、薄手の長袖(パーカーやウィンドブレーカー)を持っていれば、まず夜に寒くて寝られないということもなく、まして凍死する心配などをすることなど無いでしょう。虫よけのためであっても必要な長袖は薄手で良く、また防寒対策等も必要ありません。寝心地さえ確保できれば寝られます。寝袋すらいらず、自分はブランケットだけで寝ることもよくあります。

大型のドームテントは使わずに、日中はタープの下で過ごし、寝るときだけ1.5人〜2人用テントで寝ます。特にソロキャンプのときはタープの下でフライシートを外して蚊帳代わりにインナーテントだけで寝ることもよくあります。また最近は蚊帳付きハンモックとタープだけの装備で行くこともよくあります。装備がとにかく軽く設営や撤収も10分程度で終わるので本当に快適です。

ウォーターアクティビティが楽しめる

キャンプにあわせてアウトドアアクティビティもするときは、水辺の活動ができるのが夏ならではです。単純に川や海に入って涼んでも良いですし、湖や海でSUPやパックラフトをするのも気持ちいいものです。特に日の出直後の人気が少ない時間帯に水辺を散歩するのは気持ちが良いものです。

山が気持ちいい

避暑に行く場合には標高が高い場所にあるキャンプ場に行くことが多く、そういうところでは東京では夜中でも30度を超えるようなところでも、林間サイトなどでは20度前後まで下がったりすることもあります。夜は静けさの中に風の香り、虫や鳥の声などが聞こえ、心地よい時間が流れます。また朝は涼しさと同時に霧や靄が立ち込めて、山の朝独特の雰囲気があり、そういった時間にホットサンドを食べたり、朝から炊いた白米を頬張ったりするのはなんともいえない満足感があります。

テントがすぐに乾く

たとえ夜に雨に降られても、サイトの水はけがよく、日がよく当たる場所であれば、撤収する頃にはテントが乾いていたりします。これは特に夏は日の出が早いので日光に当てて乾かす時間も長く取れるのが良いです。

冬キャンプのデメリット

最初の方では冬キャンプが好きな理由としてメリットをたくさん挙げましたが、当然デメリットもあります。デメリットとは言っていますが、準備をすれば解決できることもあったりしますし、またそれを克服するのが楽しみでもあったりするところではあります。

  • 装備がかさばる
    • 準備をしないと凍死しかねない
  • CB缶の燃焼力が下がる
  • 液体が凍る
  • テントが乾きづらい
  • 開いているキャンプ場が少なくなる
  • 風が強い

装備がかさばる

夏キャンプの逆です。当然寒いので防寒対策をしっかりしないとただただひたすら寒さと戦うだけのつらい時間を過ごすことになります。服装は上下防寒着、できれば靴もスキー場に行くつもりで厚い靴下やブーツを履くのが望ましいです。寝具もしっかりしたマットや寝袋、暖房器具(湯たんぽ、ホッカイロ、電気毛布、ストーブ等々)が必要になってきます。マットは安いクローズドセルマットでも重ねると断熱性能は足し算できるので、たくさん持っていけばなんとかなります。

CB缶の燃焼力が下がる

キャンプで調理をする際はバーナーを使うことが多いですが、私は主にオートキャンプをしているため、バーナーはCB缶のみで過ごしています。しかしCB缶の主成分である液化ブタンは沸点が-0.5度なので、100均で売っているCB缶だと火力が弱かったりつかなかったりすることがあります。

そのため冬キャンプに行くときは、少し高級なCB缶を使っています。OD缶用バーナーやアルコールストーブも万が一のため携行していますが、最低気温-10度くらいまでのキャンプでは普通のCB缶とこういった少し高めなCB缶のみで過ごせています。

こういった高いCB缶には液化イソブタンや液化プロパンが入っていて、沸点が低め(それぞれ -11.7度、-42度)なので、オートキャンプに行くような場所では問題なく過ごせています。OD缶はそもそも高山でも使えるように中身が液化イソブタン、液化プロパンがメインになってくるため、こういった心配はほぼありません。(安いOD缶でも液化イソブタンと液化ブタンの混合で、CB缶のように液化ブタンのみということはありません)

液体が凍る

メリットで触れていた外気温の低さですが、気をつけないと凍ってしまいます。うっかり凍らせてはいけない容器に液体が入っていると、朝起きたときに容器が変形したり割れてしまっているということがあります。また容器が壊れるまで行かなくても、朝起きて水を使いたいのに凍ってしまっていて使えないということもあります。凍らせたくないものは寝る前にクーラーボックス等に入れておくなど注意が必要です。

開いているキャンプ場が少なくなる

人が少なくなるのはいいのですが、冬は閑散期になるため、冬期は運営しないというキャンプ場もしばしばあります。特に標高が高いキャンプ場は、キャンプが好きな人であっても、よっぽどしっかり準備しないと凍死のリスクがあるために閉鎖しているという場合もあります。またキャンプ場自体は開いていても、たどり着くまでの山道が凍結や積雪で通行困難になっていることもしばしばあります。スキー場に行くときと同様、スタッドレスタイヤやチェーンなどの装備はしっかり整えていく必要があります。

風が強い

小学校や中学校の理科でも習う通り、冬は西高東低の気圧配置になることで偏西風が強化されて強い風が吹きます。(冬から春かけてが強い)特に冬は気温も低く、空気中の水蒸気量も減るため同じ風速でも風を強く感じます。キャンプをしていて、雨よりも怖いのは風です。風速5m以上を超えると、テントやタープが煽られてペグが勢いよく抜けて人や車に当たったり、ポールが折れてテントが建てられなくなったり、焚き火の熾が飛んでいくなど、危険です。これは定常的な風速ではなく、瞬間最大風速で起きえるリスクなので、キャンプ場の立地にもよりますが、設営時には特に気をつける必要があります。

ゆるキャン△でも取り上げられたふもとっぱらキャンプ場は遮るものがないだだっ広いフリーサイトで、冬は通称「テントの墓場」と言われています。その凄まじさの例として次の動画をご覧ください。


www.youtube.com

とはいえ、いまは天気予報も発達していて、風速予報なども結構正確に出ていたりするので、事前に調べておくことでできる対策もあります。

おわりに

以上はいま装備がすべてある状態で考えたときに手間やコストを考えると、自分は冬キャンプが好きです、という記事でした。もちろん装備を揃えるにはそれなりに費用がかかりますし、また収納するにも場所を取ります。このあたりは趣味への投資という点と、家族の理解などがあるので一概にどちらが良いと言えるものではないですし、どの季節もキャンプは楽しいと思うので、興味がある人は是非一緒に行きましょう!

散々「冬が良い」と書いてきておいてなんですが、キャンプのベストシーズンは晩秋だと思います!

*1:オートキャンプで行くような場所では標高が100m高くなるごとにおよそ0.6度気温が下がりますが、それでも1000mで6度程度までしか違いがありません。

「SLO サービスレベル目標」という本が出版されました #slobook

はじめに

こんにちは、Google Cloudのオブザーバビリティ担当者です。このたび私が翻訳ならびに監修として関わった「SLO サービスレベル目標」という本がオライリー・ジャパン社より出版されました。本日より書店ならびに各社オンラインストアでご購入いただけます。

電子書籍版についてはオライリー・ジャパンのサイトよりePub、PDFの各種フォーマットにてご購入いただけます。

www.oreilly.co.jp

SLOがなぜ重要なのか

まず本書の意義について解説する前に、サービスレベル目標(Service Level Objective; SLO)がなぜ重要なのかについて改めてお伝えしたいと思います。

サイトリライアビリティエンジニアリング(SRE)において、その手法の名称にもあるように、「ユーザーの信頼性」というのは、その原理に根ざす重要な考え方です。システム運営に関わる人間および会計のリソースは有限であるため、サービスの品質もどこかで妥協しなければいけません。しかしその妥協がユーザーがシステムに期待する品質*1未満ではユーザーはサービスを利用してくれなくなってしまいます。そのためユーザーの満足度との相関が強い指標(サービスレベル指標)を発見し、その目標値(サービスレベル目標)を決める、というのがサービスレベル目標の考え方です。この目標は内部的なものであり、ユーザーとの契約ではないので、SLAと違い何度でも自由に見直し、より適切な値を探していくことになります*2

これは、システム運用の観点から見たビジネス的に重要な指標にもなり得るもので、SREというものが広く認知される以前から、データ駆動型経営をされている企業では名前こそ違えど、この観点から目標値を決めて運用してきたところもあるでしょう*3。SREではこれらの概念に対してSLI、SLO、さらにエラーバジェットやバーンレートといった名称と定義を与えて、さらにそれを継続的に運用していくという枠組みを作ったことに価値があると思います。一方で、こうした概念がSREとともになければならないかというとそんなことはありません。肝心なのは「自分たちが行っていることがSREかどうか」ではなく「自分たちのサービスがユーザーを満足させているのか」どうかであり、その文脈においてSLOという概念は各ビジネス指標のKPIと同様にいかなるビジネスにおいても考慮されるべきであるはずです。特にサービスの収益がシステムに依存している度合いが強ければ強いほど、このSLOという指標はビジネスにインパクトを与えているはずです。

2020年代において、たいていのビジネスはITシステムに依存していますから、このSLOという概念は会社組織の中で役職問わず理解されるべきものであると、私は考えています。「SLOをもっと使っていきましょう」という話に関しては次の文章でもう少し掘り下げて書きましたので、ご興味あればあわせてご一読ください。

zenn.dev

「SLO サービスレベル目標」はどのような本か

昨日SLO本出版イベントを開催いただきまして、書籍の内容もお話しました。お時間ある方はこちらもご覧ください。

www.youtube.com

本書はAlex Hidalgoが主著者として執筆し、また多くの共著者の寄稿を編集した "Implementing Service Level Objectives" という書籍の日本語訳版です。原著は2020年8月に出版されました。

本書は、同じくオライリー・ジャパンより出版されているSRE関連書籍のシリーズを補完する書籍だと思います。Google SREシリーズや「SREの探求」がSREの各種プラクティスを幅広くカバーしている総論であるのに対して、本書はタイトルにもあるとおり、サービスレベル目標(SLO)の実装と導入のみに焦点を当てて、その概念の説明から実装方法、さらに背景となる統計や確率の基礎知識、SLOに基づく運用を根付かせるための方法論や文化の構築など、SLOに関する各論を掘り下げて解説しています。

またその意味では、やはり私が翻訳に関わった書籍「オブザーバビリティ・エンジニアリング」にも近いですが、こちらはインシデントの解決に関連したオブザーバビリティの技術要件などに多くの焦点があたっている一方で、「SLO サービスレベル目標」はより前段階の開発と運用の判断を決定する部分に焦点を当てています。

SREを導入しようとしている、あるいはSREの導入を始めたが実践に苦労しているという人々と会話すると、やはり最も難しいと言われるのが、SLIの発見とSLOの設定です。そこから更にエラーバジェットを管理して、エラーバジェットのバーンレートを元にしたアラートで運用を行うレベルまでできているという組織はまだまだ多くありません。この理由の一つとしては、SLOという概念が難しい、ということではなく、その仕組みは単純だけれども、実際に機能させようとすると巷に手引きが少なく、各々が手探りで行っている部分が多いからだと思います。先の節でも書いたように、SLOはそれ単独でも十分に存在しうる重要な概念であるにも関わらず、です。また他にも改善を継続的に行うことに慣れるまでに時間がかかるということもあるかもしれません。

そんな中、私が本書が出版されたという知らせを目にしたとき、「Go言語による並行処理」を初めて読んだとき以上に興奮しました。本書の目次と内容を大まかに読んで、その興奮は本書は絶対に日本語でも出版されるべき書籍であるという確信へと変わりました。SREの実践において、最も重要だと思われるSLOに基づく運用を行うための手引きとして、これほどまとまっている資料は2023年現在、本書以外ありません。SRE本を読んだり、多くの企業がSREを導入しているという情報を耳にして、SREに興味を持ってSLOの導入を始めようと思っている方々、またSLOの導入から次の一歩を踏み出したいと思っている方々には必携の一冊であると思います。本書はSRE本を読んだことがなくても通して読めるようにできていますので、SREのプラクティスのすべてを実践するわけでなくても、非常に有益な内容となっています。また、先にも述べたようにSLO自体はSREとは離れて、単独で実践しうるものです。変化の早い時代において、ビジネス指標の1つとしてSLOを活用するためにも、有意義な一冊となっています。

本書は3部構成となっています。第1部はSLOの開発です。SLI、SLO、エラーバジェットといった概念を一から説明しています。初めてこれらの概念に触れる方は必ず第1部の章は通して読んでください。もしSRE本等でとこれらの概念をすでに理解している人であれば読み飛ばせるかもしれませんが、そのような場合でも念の為第1部は通して読まれることをお勧めします。特にSLOやエラーバジェットの計算に関する具体例を見ることで、自分の理解が合っているかを確認しながら振り返りができます。

第2部はSLOの実装です。第2部は第1部の理論を実際に導入する上で必要なプロセスに触れています。SLOを導入することへの各部署からの同意の獲得、SLOを支えるデータベースの仕組み、アラートの設計方法、SLIやSLOの計算のための数学的基礎知識、SLIとして使える指標、具体例を通したSLO設計の流れの確認、など、より実践的な内容が数多く紹介されています。特に9章は数学や統計の基礎知識を前提としていて、一瞥しただけで拒否反応が出てしまう人もいるかもしれませんが、安心してください。9章でも説明されているように、すべてがわからなくてもまったく問題ありません。個人的にはこの章は付録Bと同様に付録にしても良かったのではないかと思います。しかし、SLOの定義を厳密に行なおうと思えば、より細かな定義ができる、ということだけでも感じていただけたらと思います。

第3部はSLOに基づいた運用手法が実際に回り始めた後、それを維持し持続するために必要な内容が多く紹介されています。ここに書かれている内容は第1部と第2部を読み、実践を進めていく中でより理解が深まることでしょう。現在すでにSLOに基づいた運用を行っている方々には、非常に親しみのある内容になっていると思います。社内でより広くSLOを普及させるためのヒントになるような情報が多くあります。

関連書籍との関係性について

「SRE サイトリライアビリティエンジニアリング」と「サイトリライアビリティワークブック」

SREに関心を寄せる多くの方々がお持ちであろう書籍が上記の2冊です。前者は網羅的である反面、個々のSREのプラクティスに関する説明は個別のケースの説明にとどまるようなものであったように思われます。後者は書籍名が「ワークブック」とあるように、演習形式で代表的なプラクティスを少し掘り下げるもので、実際にSLOに関しては第2章〜第5章で解説されていますが、様々な場面でSLOを設定するための詳細、というよりは、SLOを活用するための一連の流れを体験するための入門という趣が強いです。

その観点で、「SLO サービスレベル目標」はSLOを中心として、理論的な側面、実践的な側面、文化的な側面など、SLOの導入と運用に関連するあらゆるトピックを網羅的に扱っています。実際に主著者であるAlexは、上記2冊のSLO関連の章の著者でもあり、「SLO サービスレベル目標」はそのテーマを掘り下げるために別途執筆されたものでした。

「オブザーバビリティ・エンジニアリング」

こちらは今年1月末に出版されたばかりの書籍ですが、こちらは書籍のタイトル通り「オブザーバビリティ」を自システム内に備えるための書籍です。本書の第12章と第13章においてSLOとの関連性を解説していますが、これはオブザーバビリティからの観点での解説です。こちらがオブザーバビリティをシステムに備えるための実装に関する解説を行っているのに対して、「SLO サービスレベル目標」ではシステムが計装すべきテレメトリーシグナルの決定に影響を与えるSLOの設定や、その可視化やそれに基づいたアラート設定に関する解説をしています。

また「SLO サービスレベル目標」が、どちらかと言うとユーザーの信頼性を維持するための施策(すなわち、インシデントが起きる前の施策)に重点を置いているのに対して、「オブザーバビリティ・エンジニアリング」では、インシデントも含めて、必要なときにシステム内部の必要なテレメトリーデータを分析できることを主眼としています。

したがって「オブザーバビリティ・エンジニアリング」と「SLO サービスレベル目標」はかなり相互補完的な書籍であると考えています。

「入門 監視」

「入門 監視」の原著 "Practical Monitoring" は2017年11月に発行された書籍です。本書は、まだSREがそこまで広く普及していなかった時期に、従来のシステム監視の視点から見た、現代的な監視に関して著した良書だと思います。本書では直接はSLOという言葉を使って解説はしていませんが、関連する話題はたくさん出てきています。

先にも述べましたが、SLOというのはSREを実践している人だけのものではありません。「入門 監視」では「ビジネスKPI」というビジネス側の目標値を監視する話がありますが、現代のサービスにおいてはシステム側のKPIもビジネスに十分影響を及ぼしていると思います。両者でしっかりと目標値を持った監視ができれば、より充実したシステム運用ができると思います。その観点で、本書と「SLO サービスレベル目標」を読むと、従来のシステム監視を行っているシステムにおいてもSLOが十分に有用であることが理解いただけると思います。

「入門 監視」の発刊当初の私の書評に関してはこちらにあります。 ymotongpoo.hatenablog.com

謝辞

本書のまえがきでも触れましたが、あらためて編集者の編集者のオライリージャパンの髙恵子さんに感謝いたします。そもそも本書の翻訳の企画は私から髙さんへの持ち込みで、当初は別企画が走ろうとしていたところを無理を言ってこちらに変えさせていただきました。また今回は当初は監訳のみという予定だったのですが、翻訳の品質に納得が行かなかったことやプロセスに問題があると感じ、私からはかなり要望を出す結果となりましたが、できる限りのことをしていただきました。諸々とストレートに意見したりと、髙さんには苦労をおかけしたことも多々ありました。また思わぬ予定変更でスケジュールがずれたりとトラブルもあり、結果2021年2月から始まった企画が、2年半近くかかりましたが、その分思い出深い企画となりました。*4 またpyspaの方々を始めとするオンラインコミュニティの皆様には、翻訳修正に苦労する中、多くの励ましをいただきました。一人でも黙々と作業を行う中でも、チャットであってもねぎらいの言葉をかけてもらえるだけで慰めとなりました。みなさま本当にありがとうございました。

おわりに

本書にも書かれている通り、本書の内容は1つのモデルでしかありません。本書を読めばすべてが解決する銀の弾丸ではありませんが、なにもない場所から始めるよりも遥かに優れた出発点になることは間違いないでしょう。本書のいたるところで繰り返し述べているように、本書を元に、組織内で多くの議論を交わしながら、SLOの導入を行う企業が少しでも増えることを願っています。

また本書に関するイベントを7/25にForkwellさんに開催いただきます。オンライン開催ですので、お時間あればご参加ください。

forkwell.connpass.com

*1:ここはさらに注意して考える必要があって、ユーザーの期待値にも幅があり、中には非常に厳しい要求をする人もいます。自分たちのビジネスがユーザーに価値を提供するために必要な品質、と考えるほうが良いかもしれません。

*2:もちろんSLOを公開しても構いません。実際にどの程度のサービスレベルを提供しようと考えているかの透明性を高めることになります。

*3:SREの語源にもなったような信頼性工学、あるいは安全工学に関連する領域では、たとえば工場における生産効率等に関する多くの指標が提示されています。

*4:この紆余曲折に関しては、要望があればどこかに記録を残そうと思います。

2022年版のState of DevOps Reportの日本語訳が公開されました

はじめに

こんにちは、Google CloudでオブザーバビリティとSREの担当をしているものです。毎年公開されると多くの方に参照いただいているState of DevOps Reportの最新版である2022年版が、日本語を含む10ヶ国語に翻訳されました。こちらのページで言語設定を日本語に設定いただいた上でPDFを申請すると日本語版がダウンロード出来ます。

cloud.google.com

これまでもすでに英語版が広く紹介されていたと思いますが、改めて日本語版が出たことで、より多くの方々におすすめできるようになったと思います。(次のスクリーンショットはfour keysに加えて、5番目の指標として信頼性が加わったことを解説しているページ)

State of DevOps Reportとは

あらためて、State of DevOps Report(以下、SODR)とはGoogle Cloudの一組織であるDORA(DevOps Research and Assessment)が2014年より行っている、DevOpsの業界動向に関する年次調査レポートです。DORAは書籍『Accelerate』(日本語訳版は『LeanとDevOpsの科学』というタイトルで出版されています)の著者陣が中心となって設立された調査機関で、2018年にGoogle Cloudの一部となりました。それ以降も、ベンダーに中立な調査機関として、継続して調査を行っています。

SODRは多くのDevOps系の記事やプレゼンテーションで参照されているのでもしかしたらどこかで目にしたことがあるかもしれません。(たとえば次の @t_wada さんのスライドのp.18以降から紹介されています。)

speakerdeck.com

上の『LeanとDevOpsの科学』は非常に有名なのでよく参照されていますがSODRはそこからのトレンドの変化を追っていくのに非常に役立つ資料となっています。まだ上の書籍しか読んだことのない方は、ぜひSODRも読んでみてください。上にありますように2022年版は日本語版が出ましたので、それを眺めるだけでも面白いかと思います。

2023年版向けの調査が始まっています

SODRが成立しているのは多くの企業の方々に調査に参加いただいているからこそです。

goo.gle

毎年多くの企業に参加いただいた結果、年次の追跡調査が可能となり、結果トレンドの変化などがさまざまに分かってきました。一方で、これまで英語のみで調査を行い、調査結果としてのSODRも英語版のみしかなかったためどうしても英語圏に偏った調査となっていました。(下図はSODR 2022のp.63より抜粋。日本からの参加者は全体の1%でした。)

今年の調査もすでに開始していますが、今年は調査の多言語化にも取り組んで、近々日本語でも調査が可能となります。*1多くの国からの調査が集まることで、各地域でのトレンドなどが見えてくることと思います。(追記 2023.06.02 日本語版のサーベイが公開されましたのでリンクを挿し換えました)

昨今もDevOps、SRE、Platform Engineeringなど、さまざまなキーワードが飛び交っています。しかし、その実態として、業界全体の各組織でどのような取り組みがなされているのでしょうか。それを明らかにしていこうという取り組みがSODRです。少しお時間かかる調査ではありますが、ぜひご協力ください!よろしくお願いします。

*1:公開され次第追って紹介します