『効率的なGo』という本が出版されました #efficient_go
はじめに
こんにちは、Google Cloudのオブザーバビリティ/SRE担当者です。出張中で発売日にきちんとした記事が書けなかったのですが、去る2月24日に私が翻訳しました『効率的なGo―データ指向によるGoアプリケーションの性能最適化』という書籍がオライリー・ジャパン社より出版されました。書店ならびに各社オンラインストアでご購入いただけます。
電子書籍版はオライリー・ジャパンのサイトにPDFおよびEPUBでの提供がありますので、そちらよりご確認ください。
『効率的なGo』をなぜ翻訳しようと思ったのか
私は業務において、SREやオブザーバビリティに関わる各種プラクティスの啓蒙や、それらの各種製品（Google Cloudのプロプライエタリ製品やオープンソースソフトウェア、その他関連製品なんでも）を使った実践などを解説したりしています。ここ数年でのオブザーバビリティに対する注目が高まったこともあり、計装やAPMに関する情報はだいぶ増えてきたように思います。一方で、ボトルネックの究明を行った後の最後の一歩、ボトルネックの改善をどう行うのかについては、アプリケーション開発の文脈に渡されてしまい、あまり一般的な解説が得難い領域でした。
そんな中、『オブザーバビリティ・エンジニアリング』の翻訳の第2校がちょうど終わる頃に、原著 "Effecient Go" の出版が決まり、急いでその内容を確認したところ、まさにその解説が得難い領域をテーマとした書籍であったこと、そして内容もGoに限らない、アプリケーション性能改善一般に触れる書籍であったことから、翻訳の企画をオライリー・ジャパンへと持ち込みました。
ここ最近私が関わったオライリー・ジャパンでの翻訳書籍は、企画が立ち上がった順序で言うと、『SLO サービスレベル目標』『オブザーバビリティ・エンジニアリング』の順だったのですが、ちょうどこの順序でサービス全体のマクロな視点の目標設定から始まり、それを効率よく観察するためのオブザーバビリティの獲得、そして問題がある場合の原因の究明までは理解ができますが、最後の性能改善の部分が足りないとと考えていました。そこにおあつらえ向きに本書が出版され、まさに福音でした。
また本書がGoで解説していたことも大きいです。自分が最も使う頻度が高く、長らく関わっているプログラミング言語なので、『Go言語による並行処理』と同様に、内容の理解は他の言語で解説されたものよりもできるからです。
こういった偶然が重なり、本書を翻訳する機会を得ることとなりました。
「効率的なGo」はどのような本か
本書は次のような読者に有益であると考えています。
- Goによって開発されたプログラムのパフォーマンスを改善したいと考えているエンジニア
- 他の言語でのパフォーマンス改善方法を知っているが、Goでの方法を知らないエンジニア
- パフォーマンス改善一般について理解したい方
- Goがどのようにリソースを使うか、理解を深めたいエンジニア
本書は書籍タイトルにもあるとおりGo製のプログラムを中心として、そのパフォーマンス改善手法について解説していますが、Goに限らない、プログラムのパフォーマンス改善において汎用的な考え方が紹介されています。
また本書はGoのランタイムからOSまでという、これまであまり解説がまとまった形で得られなかった低レイヤーの解説にもある程度のボリュームが割かれている書籍なので、初級者向けの書籍では刺激が得られないエンジニアにも、非常に興味深い内容になっていると思います。
関連図書
本書の関連図書として私からいくつか挙げてみます。
まず先にも紹介しましたし、本書の訳者まえがきにも書いたのですが、『SLO サービスレベル目標』『オブザーバビリティ・エンジニアリング』は真っ先に挙げたい書籍です。
もちろん自分が翻訳に関わったからでもありますが、先にも紹介した通り、一連のオブザーバビリティの獲得と性能改善というシナリオを大局的に理解するために必要な情報はこの3冊で網羅されています。
そしてプログラムの性能問題の調査に関しては『詳解 システム・パフォーマンス』を外すわけにはいきません。非常に分厚く、また価格も高いので購入がためらわれるかもしれませんが、逆にこの内容の充実ぶりで7000円を切る価格で販売されているというのは破格と言っても過言ではありません。内容も、非常に丁寧に解説されていますし、頭から通して読まなくても、辞書的に使えるところが素晴らしいです。一人一冊とまでは言わないまでも、一社に一冊は備えておくことをおすすめしたいです。
本書にならんでGoの内部挙動を紹介する書籍として紹介したいのは『Goならわかるシステムプログラミング』です。本書より少しだけ上のレイヤーで広くGoのランタイムの解説をしています。システムコールのレベルでGoのランタイムとOSの関係性を知りたい場合にはおすすめの書籍です。
また本書で解説されている内容の中で、GoプログラムとCPUに関する章（第4章）がありますが、そちらに興味を持たれた方は『プログラマーのためのCPU入門 』をおすすめします。より一般的な立場からプログラムとCPUはどう連携して動くのかを深く解説されている書籍です。
おわりに
私は職業柄、システム全体、サービス単体、関数1つと様々なレベルでの性能最適化に関わる話をすることがありますが、一貫して広まってほしいと思っている考え方は「性能を改善するためには計測し目標を立てること」です。本書が、その普及の一助になることを期待しています。
YAMAGUCHI::weblogの2023年を振り返る
はじめに
こんにちは、Cloud Operations担当者です。2023年も最後日となりました。そして私の誕生日です。だんだんと歳を重ねることが億劫になる年齢となってきました。例のやつを貼りました。よろしくお願いします。
2020年3月から始まった新型コロナウイルスの猛威により様々な制限を設けることによって経済的な影響を抑えつつなんとかやってきた数年間でしたが、今年のゴールデンウィークを境に季節性インフルエンザと同じ5類感染症に分類されることとなりました。その是非はさておき、これにより様々な生活への変化が訪れ、私も数多くのオフラインイベントに登壇する機会が増え、仕事や生活が大きく変わった1年でした。
過去の年次の振り返りはこちら。
- YAMAGUCHI::weblogの2007年を振り返る - YAMAGUCHI::weblog
- YAMAGUCHI::weblogの2008年を振り返る - YAMAGUCHI::weblog
- YAMAGUCHI::weblogの2009年を振り返る - YAMAGUCHI::weblog
- YAMAGUCHI::weblogの2010年を振り返る - YAMAGUCHI::weblog
- YAMAGUCHI::weblogの2011年を振り返る - YAMAGUCHI::weblog
- YAMAGUCHI::weblogの2012年を振り返る - YAMAGUCHI::weblog
- YAMAGUCHI::weblogの2013年を振り返る - YAMAGUCHI::weblog
- YAMAGUCHI::weblogの2014年を振り返る - YAMAGUCHI::weblog
- YAMAGUCHI::weblogの2015年を振り返る - YAMAGUCHI::weblog
- YAMAGUCHI::weblogの2016年を振り返る - YAMAGUCHI::weblog
- YAMAGUCHI::weblogの2017年を振り返る - YAMAGUCHI::weblog
- YAMAGUCHI::weblogの2018年を振り返る - YAMAGUCHI::weblog
- YAMAGUCHI::weblogの2019年を振り返る - YAMAGUCHI::weblog
- YAMAGUCHI::weblogの2020年を振り返る - YAMAGUCHI::weblog
- YAMAGUCHI::weblogの2021年を振り返る - YAMAGUCHI::weblog
- YAMAGUCHI::weblogの2022年を振り返る - YAMAGUCHI::weblog
ymotongpooの2023年
去年立てた目標
先に述べたように、新型コロナウイルスの分類が変更されたことによって生活が大きく変化し、当初考えていたようなことができなかったり、逆に思わぬ成果が多かった1年でした。
仕事
今年は社内の仕事で、技術的な仕事とプロジェクトリード的な仕事の割合ではだいぶ後者が増えてきたので、なかなか思うように時間が取れなかったのですが、いろいろとチャレンジングな仕事が多く出来たかなと思います。
イベント登壇
今年も去年に引き続き登壇が多かった1年でしたが、特にオフラインイベントでの登壇が増えた1年でした。ざっと記録を見てみましたが、今年だけでオンライン、オフライン含めて30イベントに登壇したようです。今年は意識してSLOに関する話を何度も繰り返し行っていました。少しはSREのプラクティスの普及に貢献できたのではないでしょうか。
主な登壇の記録は一旦こちらにまとめてあります。
イベント運営
自分でイベント運営をすることがかなり減ってきましたが、今年はGo Conference 2023とOpenTelemetry meetup 2023-10の運営に関わりました。
Go Conferenceは2代目座長の @tenntenn が今回で座長を退任し、来年は @sivchari さんが座長となります。2013年に勢いだけで始めたイベントが10年続いたのも、ひとえに毎年メンバーは違えど、一緒に運営してくださる皆様と、スポンサーや登壇者、そして毎回応援してくれる参加者などの、支えてくださる皆様のおかげに他なりません。これからもGo Conferenceが続くことを願っています。
OpenTelemetry meetupに関しては、3年くらいずっとやりたいという話を @katzchang としていて、今回オフィス移転前のCARTA HOLDINGSさんのイベントスペースをお借りして実現できました。2023年はOpenTelemetryに対する注目度が一段と高まった年だったので、良いタイミングで実施できたと思います。盛り上がりです。
執筆・翻訳・監訳
つぎのような目標を立てていました。
- 執筆・翻訳・監訳をすすめる
- 新たな翻訳企画
今年の頭に昨年末に校了した「オブザーバビリティ・エンジニアリング」が出版されました。
その半年後に、紆余曲折を経て数年越しで「SLO サービスレベル目標」が無事出版に至りました。2年強、コロナ禍でリモートワークが前提の中での翻訳作業でしたが、編集の高さんを始め、関係者のみなさまとは結局一度も直接お会いすることなく出版となりました。来年、機会があれば、今度こそご挨拶できればと思います。
また同じく、コロナ前から始まっていた企画であった「実践プロパティベーステスト」も無事に出版に至りました。鹿野さんには長年にかけてご迷惑をおかけしただけでなく、編集作業においては私の翻訳から、日本語として格段に上質なものにしていただき、本当に感謝しています。
2冊は単純に作業が滞った結果今年出版になってしまったというだけではあるのですが、1年に3冊出版というのはなかなかタフな仕事ではありました。特に「SLO サービスレベル目標」と「実践プロパティベーステスト」に関しては、今年を逃すともう出版できないかもしれないというプレッシャーにより無理にでも作業を進めたというのが本当のところではあります。
いずれにせよ、担当編集者のみなさまにも恵まれ、非常に充実した1年となりました。現在、また別の本の翻訳にすでに取り掛かっていて、そちらは早ければ来年第1四半期には出るのではないかと思います。そちらも楽しみにしていてください。
出張／旅行
新型コロナ禍以降、久々に出張などが復活し、海外への移動が多くあった1年でした。写真は初めて行ったクアラルンプールにあるペトロナスツインタワー。
スペインは旅行でしたが、それ以外はすべて出張でした。シンガポールやマレーシアは時差が1時間しかないこともあり、本当に気持ちが楽な出張でした。歳を取るにつれて時差ボケが本当にきつくなってきて、サンフランシスコもバルセロナもどちらも本当に疲れました。
来年もすでに海外出張がいくつか決まっているので、現地の人々との交流がいまから楽しみです。
趣味
キャンプ
キャンプに関しては次のような目標を立てていました。
- 1年を通じたハンモック泊の充実
今年は年の後半は後述する住宅購入やら、イベントやらで思ったほど時間が取れず、ハンモック泊に行けたのは年のはじめだけでした。合計で2回ではありましたが、3月と6月に行ったので、季節としてはだいぶ快適で、防寒対策はクローズドセルマットを用意する程度で、あとは寝袋の性能で十分でした。ハンモック泊での外の空気に直接触れながら寝る感覚は何度行っても爽快感があります。まだ雨のハンモック泊は経験したことがないので、来年はタイミングを見計らって実施したいです。
語学
去年に引き続きDuolingoを1年継続できました。毎日コツコツできるものは得意です。
今年も1年お疲れ様でした ▶ Look how much I learned on Duolingo in 2023! How did you do? #Duolingo365 pic.twitter.com/5nsQUe6abE
— Yoshi Yamaguchi (@ymotongpoo) 2023年12月5日
去年は「DELEを受けるぞー」と息巻いていましたが、11月はCloud Next Tokyoの準備やら、家族旅行やらなにやらでまったく受験とか無理でした！早く受けられるようにしたいところです。いまの感じだと、受験をするとなるとリスニングが明らかに不得意なので、もう少し音声インプットを増やしたいと感じています。家族旅行で行ったスペインも、こちらが話しかけたり、あるいは文章の読み書きをするのはわりかしできるようになっていると実感できましたが、リスニングは他の3つの技能に比べるとレベルが低いように思います。来年は何かしら対策したいところです。
ところで、クアラルンプールに12月頭に行ったことで、思いがけず始めたインドネシア語およびマレー語ですが、文法がかなりわかりやすいので、このまま続けて行こうと思います。
その他
家を買った
去年奨学金を完済して負債がゼロになったばかりでしたが、今年はそれよりもずっと大きな住宅ローンという負債を抱えることとなりました。少し事情が特殊な形で家を購入したので、住宅ローンの審査がなかなか通らず、13行に審査を出してようやく2行から承認を得たという感じでした。ネット銀行は本当にテンプレートから外れると審査が厳しいということを学びました。
本当にこの図のとおりでした。（引用元: 住宅ローンの基本 | モゲチェック）
紆余曲折ありましたが、無事に住宅ローンが組め、物件を購入できたので、あとは淡々と返していくだけです。新しい家は築浅の中古戸建てなので、大きなリノベーションが必要ないのが助かります。家具などはいま使っているものがだいぶ年季が入ってしまっているので、これを機に一新しようと思います。
普通自動二輪の教習
前述した物件は地方都市にあり、家の周りを移動するのに車だけだと個人的には不便だと思ったので、一旦原付一種を適当に買おうと思っていました。しかし他の地方都市に漏れず、家の周りは車社会のため、原付一種は馬力の低さゆえに発進や坂道で不満に感じそうだと思い、原付二種を買うことに決めました。とはいえ自分は中型自動車免許しか持っていない（歳がバレる）ので、原付二種には乗れません。こうした事情から、新しいことにも挑戦してみたかったのものあって、勢いで普通自動二輪の免許を取ることにして、年末に通い始めました。
まだ今の段階では卒業検定には至っていなくて、あと1時間第2段階の見きわめをしたあとに卒業検定という状況です。年明けの検定でどうなるか、まったくわかりませんが、合否は一旦置いといて、いままでちゃんと動かし方を知らなかった乗り物を動かせるようになるというのは単純に楽しいです。またこの歳になると、人に教えてもらえることのありがたさをしみじみと感じます。
原付二種を買うと決めてから通い始めた教習ですが、すでに今の時点で普通に中型バイクが欲しくなってるので、おそらくいずれ買うことになると思います。まずは免許を取ってから、いろいろとレンタルバイクで試してみます。
来年に向けて
来年はこんな感じでやっていこうと思います。
マレーシアに行ってきた
はじめに
こんにちは、Google CloudでオブザーバビリティやSREを担当しているエンジニアです。先日バルセロナに家族旅行に行ってきましたが、今年最後の出張として12月初旬にクアラルンプールに出張に行ってきました。
バルセロナに行くときはアムステルダムまで13時間、そこから乗継便で3時間強と体力的に疲れるフライトでしたが、それと比べたらクアラルンプールまでは直行便で7時間程度なので余裕でした。
旅程
| 日程 | アクティビティ |
|---|---|
| 11/30 | NRT→KUL |
| 12/1 | マレーシアオフィスで仕事＆登壇者懇親会 |
| 12/2 | DevFest KL 2023 |
| 12/3-4 | 少し観光＆KUL→NRT |
気付きと感想
Malaysia Digital Arrival Card（MDAC）
マレーシアは90日間の滞在でパスポートの残存期間が半年以上あればビザなしで入国できますが、それ以外にMDACというデジタル入国カードを記入して、入国審査自動化ゲートを使うことを推奨されました。
これは今月1日から義務化されたそうなので、これからマレーシアに行く場合には事前に登録する必要があります。12/8からは登録していないと出発できないそうです。登録自体はパソコンでやればすぐにできるので、これから行くときは気をつけないといけないですね。
KLIA Ekspressを使って市内へ楽々接続
クアラルンプールの中心地はクアラルンプール国際空港（KLIA）から60kmくらい離れているのですが、KLIA Ekspressという特急を使うと一駅でKL Sentral駅まで着きます。乗車時間は30分ぐらいで料金も55MYR（2023年12月現在で1700円くらい）なので、一旦KL Sentralまで移動したい人にはとても便利でした。
会社のオフィスがまさにKL Sentral駅のすぐそばで、自分はKL Sentral周辺のホテルを取ったため、とても便利でした。
現金かQRコードでしか支払えないところがある
日本もそうですが、個人商店のような規模のお店だとクレジットカードを受け付けてくれません。そのため、現金かQRコード決済を用意しておく必要があります。最低限のセーフネットになる現金を用意しておくのが安全でしょう。
自分は海外に行った際にはソニー銀行のキャッシュカードを使って現地ATMから引き出しています。ソニー銀行は為替レートがかなりお得で、手数料もそんなに高くないと思うので便利に使っています。
ネットの情報によると普通に過ごすだけなら1日50MYRもあれば十分とのこと。だいたい3日しか滞在しないし、カードが使えるところにも行くので、200MYR程度ATMから引き出した。
Grab超便利
シンガポール出張は度々あるため、現地での移動のためにGrabのアカウントはすでに持っていましたが、マレーシアでも配車サービスといえばGrabなので同じアカウントを便利に使えました。料金もだいぶ安く、KL SentralからSunway周辺まで20km近く、35分の乗車で34MYR弱でした（日本円で1000円程度）。
また先のQRコードでの支払いに関しても、Grab PayというのがあってGrabアカウントに旅券番号を登録すればすぐに使えます。
電車は券売機の機嫌を知るのが難しい
Grabは便利なんですが、基本的に公共交通機関を無理なく使える場合は乗りたい主義なので、電車も活用します。Rapid KLという鉄道がKL Sentral駅を中心にクアラルンプール市内をさまざまに接続しているので、ちょっと乗ってKLCCのほうへ行ってみました。
まず切符売り場で切符を買います。日本のSUICA的なTouch'n Goというカードもあるのですが、券売機を使ってみたかったので切符にしました。
これが券売機です。
この券売機がなかなかに曲者で、まずカードを使おうと思ったら「調子が悪いのでクレジットカードはやってません」という感じで使えませんでした（券売機右上の赤くステッカーで隠してある部分）。まあでも現金が余ってたので特に気にせず買います。路線を選んで、行き先の駅を選ぶと支払いの画面になります。
ここが完全にトラップで、券売機によって使える現金がまちまち！写真を見てわかるように、使えない紙幣には大きくバツ印が書いてあります。この券売機は5MYR紙幣まで使えますが、別の券売機を使ったときは紙幣が一切使えませんでした。小銭をそんなに持ってなかったので、そのときは仕方なく別の券売機に並びなおすわけですが、最終的な支払いの画面までこのステータスがわからないので、ちょっとしたギャンブル気分でした。
マレーシア国産車がとても多い
マレーシアは長年首相を務めたマハティール元首相が国産車構想を打ち立て、1985年にプロトン社を三菱自動車・三菱商事との合弁で作ったあとに、それをうけてダイハツ・三井物産との合弁でプロドゥアというコンパクトカーメインの会社が立ち上がった、という話を、マレーシア滞在中に大量のプロトン車、プロドゥア車を見かけて調べてみて初めて知りました。
おそらくGrabで配車を頼むと、結構な確率でこの2社の車が来ると思います。
商業施設のCフロアの意味がよく分からなかった
クアラルンプール市内のビル施設には当然いくつも階があるわけですが、その中でフロア名が「C」となっているところがチラホラありました。ヨーロッパ文化圏、北米文化圏の国にそれぞれそれなりに行ったことがありますが、C階という区分けを見かけた記憶がないのでなんだろうと思っていました。
特定の階がC階になるわけではなく、ビルによってその階の位置はまちまちで、ただ共通項としては他の施設と繋がっている階がC階になっていたので、おそらくConnectionとかそんなような意味合いの言葉の頭文字だろうと思っていました。
これはKLCCの階。
こちらはNU Sentralの階。
で、NU Sentralのフロアマップを見て「Concourse」と書いてあったので、なるほどと思いました。実際英語版Wikipediaには次のような説明がありました。
C for "Casino" or "Concourse"
もしかしたら他の国でも見かけているかもしれないけれど、この頻度で見かけるのはクアラルンプールの特徴かなあと思いました。
Duolingoのインドネシア語コースが予想以上に役立つ
せっかくマレーシアに行くので、多少現地語がわかったほうがいいと思い、行く2日前から付け焼き刃でDuolingoでインドネシア語のコースを取り始めました。「え、マレー語じゃないの？」という疑問を持つのは当然で、本当はマレー語のコースを取りたかったんですが、Duolingoにはインドネシア語しかなかったので、そちらを始めました。
インドネシア語とマレー語は文法や語彙などは近しいものがあるため、知っているとある程度現地で看板などが読めたりします。
インドネシア語、マレー語はダイアクリティカルマークを使わないアルファベットを使い、発音もほぼローマ字読み（eやcがわかりやすく音が違う）で、文法はわりとシンプルで覚えやすい感じなので、学びやすいなと思いました。
現地で現地語を理解するというのは、この上なく楽しいものなので、出張や旅行に限らず、なるべく様々な言語を習得していきたいものです。
早朝にNEXがない
成田に朝6時に到着したのはおそらく初めてでした。
到着してみてから初めて気がついたのですが、成田エクスプレスの始発が7時40分とかで、せっかく早く成田に着いたのに1時間くらい暇な時間ができてしまいました。
ちょっとだけ始発が早く、かつ山手線までの所要時間はとりあえず短い京成スカイライナーに乗るという手もありましたが、なにせ山手線に着く頃には通勤ラッシュとぶつかる時間帯だったので、疲れた体で荷物を持ってその中を移動するのもためらわれたため、成田線快速逗子行きで品川まで行きました。結局座れはしたものの品川まで1時間半くらい千葉方面からの通勤混雑に遭遇したため、次はこのあたりのスケジュールも考慮して帰ろうかと思います。
参照
スペインに行ってきた（2回目）
はじめに
こんにちは、Google CloudでオブザーバビリティやSREを担当しているエンジニアです。この記事はpyspa Advent Calendar 2023の6日目の記事です。昨日はしろうさんの「2023に有った無なこと」でした。
今年は本当に公私ともに疲れたので、11/19-27の日程でバルセロナに家族旅行をしてきました。そのときに気づいたこととか感想を書いてみます。
旅程
| 日程 | アクティビティ |
|---|---|
| 11/19 | NRT→AMS→BCR |
| 11/20 | 散歩、フラメンコライブ |
| 11/21 | サンパウ病院＆サグラダ・ファミリア |
| 11/22 | モンセラット |
| 11/23 | 市内バスツアー、外食 |
| 11/24 | バルセロナ水族館、外食 |
| 11/25 | バルセロナ動物園、外食 |
| 11/26-27 | BCR→AMS→NRT |
スペイン旅行と言いつつ、全日程バルセロナのみの旅行です。
気付きと感想
スペインは7年前に一度行っていて今回が2回めでしたが、前回は大人だけでの旅行で、今回は子どももいる旅行だったので勝手がだいぶ違いました。特に夜に気軽に遊びに行けないのは、バルセロナの旅行においてはだいぶ勝手が変わります。1度行ってる場所だからそんなに新しい気付きは無いだろうと思っていたら、前回と同行者も異なれば、自分のスペイン語力も違うこともあって、多くの気付きがありました。
シベリア上空通れないのきつすぎる
ロシアのウクライナ侵攻開始以降でヨーロッパに行くのが初めてでしたが、事前にわかっていたとはいえ13時間超のフライトはなかなか堪えました。シベリア上空が通れないので、行きは北極圏ルート、帰りは中国上空ルートで帰ってきました。
しかし、北極圏ルートなんて冷戦時代の過去の話と思っていたので、まさかこうしてそのルートを使う羽目になるとは思ってもみませんでした。昔と違ってアンカレジで給油しないで済むようになっただけマシとは言えますが、体が大きいのでエコノミーシートに13時間はなかなかにハードでした。またいろいろと国同士のいざこざはありますが、中国も上空を通してくれていることは助かりました。ここを通れないとなるとユーラシア大陸上空は中東経由とかにするしか無くなります。
またスペインは旅行当時の2023年11月には日本からの直行便が存在せず、今回はアムステルダムでの乗り換えにしましたが、乗継便の待ち時間も含めて片道20時間くらいかかったので、移動で相当体力持っていかれました。多少親バカになりますが、うちの子どもは長時間フライトにも関わらず移動中ぐずりもせず、iPadや機内エンターテインメントなどで静かに過ごしてくれて、本当に助かりました。これで13時間未満の直行便であれば余裕を持って家族旅行に行けるという自信にもなりました。
スペイン語で畳み掛けられる
新型コロナ禍に入ってからDuolingoでスペイン語の勉強を始めたんですが、3年位続けているといよいよ実際にスペイン語圏に行って試してみたいという気持ちになり、今回のバルセロナ旅行は個人的に修学旅行の意味も込めて行ってきました。毎日少しずつでも続けているだけあって、読み書きに関してはかなり分かるようになっていて、街頭の看板や文章、お店のメニューなんかはそのまま理解できることが多かったです。
また店員との挨拶や注文なんかのやり取りでは、こちらがスペイン語で話す分には普通に理解してもらえました。一方で、聞き取りはだいぶ難しいと感じました。こちらがゆっくりでもスペイン語を話すと、相手は普通のスピードでスペイン語で返してくるため、それを理解するのに苦労することがしばしばありました。「ゆっくり話してほしい」といっても結局0.95倍速くらいの速度で返されることが何度かあったため、ゆっくり話してもらうことは早々に諦めました。
英語のリスニングがまだ苦手で、全然聞き取れなかった頃の感覚を思い出して新鮮でしたが、最終的にスペイン語で意思疎通できなかったときは英語でやり取りできる事が多いので、安心感はだいぶ違いました。英語は国際語とはいえ、前回来たときの学びのとおりやはりスペイン語が話せるに越したことはないなと実感しました。
カタルーニャ語優先だけどスペイン語は全然使える
バルセロナ含むカタルーニャ自治州は、近年でも独立に関して住民投票が行われたりと、歴史的経緯から長らく中央政府との確執が強い地域です*1。独自の文化も持っていて、地域の言語であるカタルーニャ語を地域公用語としています。スペインの国家としての公用語はスペイン語ではあるので、公共施設などではカタルーニャ語、スペイン語、英語の3カ国語が併記してあるのがよく見かけられます。
これは動物園内の禁煙に関する注意書き。右側に太字で大きくカタルーニャ語、左側に太字でスペイン語、細字で英語が書いてあります。
これは水族館内の案内。上からカタルーニャ語、スペイン語、英語。
これは駅の路線案内。左から太字で大きくカタルーニャ語、普通のウェイトでスペイン語、斜体で英語
そんなバルセロナですが「カタルーニャ語を話さなければ疎まれて無視される」というようなことはまったくなく、むしろスペイン語で話すのであれば歓迎されるようなことばかりでした。自治州として確執はあるものの、外国人旅行者がその国の言語を話そうとする姿勢を示すだけでだいぶ歓迎されているように思います。
バイクが多い
バルセロナ市街に長期滞在して気がついたのですが、市内を走っているバイクが非常に多かったです。
特にビッグスクーターを多く見かけました*2。目にしたもので多かったのはヤマハのXMAXやスズキのBurgmanでした。警察も白バイにBMWのビッグスクーターを採用したりしているくらいでした。
バイクが多いので、当然バイク駐輪場も充実しています。こちらはバルセロナ市街中心地のカタルーニャ広場の端にあるバイク駐輪場です。
他にも町中にバイク駐輪場がいたるところに設置されていました。
タクシーが多い
良くバルセロナの観光ガイドには「タクシーが多いから普通に手を挙げて捕まえましょう」みたいなことが書いてありますが、実際に観光にいってみて改めて意識してみると、どこを歩いていてもタクシーを見かけました。
この黄色と黒のペイントがしてあって、車両の上にTAXIという光るサインと緑ランプがあり、どこかに登録番号が書いてあるタクシーは正規タクシーなので安心して乗れます。料金は自治州が公表していて、記載のある何段階かのレートが適用されます。
| 料金 | 時間 | 初乗り | km毎 |
|---|---|---|---|
| T-1 | 平日昼間（8:00-20:00） | €2.30 | €1.21 |
| T-2 | 休日終日 or 平日夜（20:00-8:00） | €2.30 | €1.45 |
他にあとT-3とT-4という料金体系がありますが、前者はタクシーアプリ（後述）経由での固定料金、後者はクルーズ船に乗るときの固定料金なので、流しで乗るときは上の2つの料金体系だけ気にしていれば大丈夫なようです。（空港など入るのに別料金が追加されることもあります）
タクシースタンドもあって、このような黄色でギザギザが書いてあるところで「TAXI」という看板がある場所で手を挙げて待っていればタクシーが来てくれます。
なお、Uberはバルセロナでは使えませんが、上記のように流しのタクシーがたくさん走ってるのであまり困ることはありません。それでも自分の場合は、復路の飛行機が朝6時で、朝3時半には出なければならず、かつコンドの管理会社もタクシーの予約の手伝いはできないとのことだったので、仕方なくタクシー配車アプリを使いました。
FREE NOWというアプリが一番使われているとのことだったので、そちらを使ったのですが、最初だけSMS認証をしなければならず、使っていた海外SIMがSMSに対応していなかったので、その設定のためだけに日本のSIMを一瞬だけ使いました。日本でアクティベートしてから行くことをオススメします。使い方はUberとかと変わらず簡単で、かつちゃんと事前に予約した通りの時間に来てくれたので良かったです。料金も事前に提示してくれていたので安心でした。（おそらく上のT-3に該当する料金）
朝3時半でもちょっと移動して待っていれば捕まえられそうなくらいにはタクシーが走っていたので、一人で旅行している場合にはあまり必要ないと思います。
公共のゴミ箱が多い
上のタクシーが並んでる写真の手前部分に黒いゴミ箱があると思うんですが、あんなゴミ箱が街中にありました。町中でコーヒー飲んだりチュロス食べたあとのゴミなんかをそこに捨てられて便利でした。
そしてそれとは別にめちゃくちゃでかい分別ゴミ箱がところどころにあって「このでかいゴミ箱はどういう扱いなんだ...？」と疑問に思っていました。家庭ごみなんかもここに捨てに来るそうです。満杯になるとゴミ収集車がいい感じに集めてくれるそうです。
スーパーのレンチン食材も美味しい
「スペインはご飯が美味しい」というのはもはや説明の必要のないほどの周知の事実ですが、スーパーで売っているレンチンの食材も日本に引けを取らないほど美味しかったです。これはある日のもう疲れ切ってしまってコンドの中で食べることにした夕食の食卓ですが、ムール貝、イカスミパエリア、スパニッシュオムレツ、ズッキーニスープのいずれもただ買ってきたものをレンジなりコンロで温めただけです。どれも満足でした。地元ビールはあまり好みではありませんでした。
スーパーといえば、生ハムにかける本場の熱意を感じました。
自転車専用道はあるにはある
日本では自転車は原則車道ということになって、急場しのぎで車線の端に自転車マークや走行帯を表す青い印を描いただけのところがほとんどですが、バルセロナ市街では一応専用道らしきものが確保されている場所がチラホラありました。
とはいえすべての道路がこうなっているわけではなく、ない場合は日本と同じように車道の端を走れという感じでした。日本と比較して思ったのは自転車に乗る人がアグレッシブで、連結バスの横を自転車がすり抜けようとしたけれど、車幅の狭さのせいでバスの窓にぶつかってる人が一人二人ではありませんでした。
観光バスは初手で乗っておくと便利
子どもが時差ボケで眠い中歩くのは嫌だからバスに乗りたいというので、到着3日目は一日市内観光バスに乗りました。バルセロナ市内観光をしてくれる観光バスは2種類あって、紫のほうがバルセロナ市が運営しているもの、赤いのが民営です。公共機関にお金を落としたほうがいいと思ったので自分たちは市が運営するものに乗りましたが、民営に乗っても大差はないと思います。
3日目で乗ることにしましたが、一番最初にこれに乗っておいたほうが良かったなと乗ってから思いました。理由としては「バルセロナ市街の全容を楽に大まかに知れる」「主要観光地のクーポンがもらえる」からです。
バルセロナは南東にある海岸から北西の山際の高級住宅街まで南北に高低差があるんですが、それを効率よく回るのはなかなか難しいです。特に南側の地区はあまり便が良くないので、さーっと流して主要な施設を様子だけ眺めたいという場合には観光バスは便利だなと思いました。
またバスに乗る際にもらえるクーポンを使うと主要な観光地がまあまあ割引される（家族全員分だとお茶するくらいは割り引かれる）ので、観光地に多く行く場合にはおすすめです。（オンラインで予約する場合に使えるクーポンコードも書いてある）
おわりに
まだ気付きはあったような気もしますが、気がついたらまた追記します。
スペインは今回が2回目でしたが、前回も今回もとても楽しく過ごせました。特に今回はスペイン語をある程度使えるようになってから行ったのでより楽しめました。やはり語学は楽しい。長時間フライトは大変ではありますが、また機会があれば、次はマドリードやマラガなんかに行ってみたいです。明日は渋川さんです。
参照
「実践プロパティベーステスト」という本が出版されました #pbtbook
はじめに
こんにちは、Google Cloudのオブザーバビリティ/SRE担当者です。このたび私が翻訳しました「実践プロパティベーステスト PropErとErlang/Elixirではじめよう」という書籍がラムダノート社より去る11月1日に出版されました。書店ならびに各社オンラインストアでご購入いただけます。
実践プロパティベーステスト ― PropErとErlang/Elixirではじめようwww.lambdanote.com
電子書籍についてはラムダノート社のECサイトよりご購入いただけます。
実践プロパティベーステスト ― PropErとErlang/Elixirではじめよう（電子書籍のみ）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本の詳細に関しては出版時にエントリーを書きましたのでご参照ください。
すごいE本ではErlangの基礎から始まり、OTPの発展的な使用方法まで網羅していました。もちろん、その中にはテストに関する章もあり、たとえばEUnitの関する基本的なところから、静的解析（Dialyzer）まで行うのですが、それ以外のより発展的な検証については一切触れられていませんでした。Erlangのエコシステムを知りつつ、他の言語で主に開発を行っていた身としては、Erlangの達人たちが使いこなしていたプロパティベーステスト（PropEr）に関する情報がもっと出てきてほしいなあと思っていました。
そんな折、2017年の半ばにFredがまたPropErに関するテキストをウェブで公開し始めました！
そこにはいままで知りたいと思っていたプロパティベーステストを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フレームワーク一覧です。（網羅しているわけではありません。）
- Java: jqwik
- JavaScript/TypeScript: GitHub - dubzzz/fast-check: Property based testing framework for JavaScript (like QuickCheck) written in TypeScript
- Haskell: QuickCheck: Automatic testing of Haskell programs
- Python: Welcome to Hypothesis! — Hypothesis 6.88.1 documentation
- Go: GitHub - flyingmutant/rapid: Rapid is a modern Go property-based testing library
- Rust: Introduction - Proptest
- Kotlin: Kotest | Kotest
- Scala: GitHub - scalaprops/scalaprops: property based testing library for Scala, ScalaCheck
- Ruby: prop_check | RubyGems.org | your community gem host
もちろんフレームワークによって対応の度合いは異なるので、これらを使って本書をErlang/Elixirとまったく同様に進められるわけではありません。たとえばPythonのHypothesisではジェネレーターは意図してランダム値になるように振っていて、PropErのように意図して偏らせるようなことができません*1。また上には列挙していませんがGoのgopterというフレームワークではステートレスPBTしか実現できません*2。
謝辞
書籍中の謝辞でも書いていますが、あらためて、本書は次のみなさまのご協力なしには出版はありえませんでした。特にErlang/Elixirに関しては趣味レベルの私とは異なり、業務でErlangとPBTを使われていた経験がある、また今まさに現役でErlang/Elixirを書いている皆様方からいただけたレビューは本書の質を最後に押し上げてくださるものでした。あらためて感謝いたします。
レビュアーのみなさま（五十音順）
- 上西康太さん（@kuenishi）
- 大田健さん（@sile）
- 大原常徳さん（@ohr486）
- 篠原俊一さん（@shino）
- 宮崎達矢さん（@ta_ta_ta_miya）
ラムダノートのお二方
- 鹿野桂一郎さん
- 高尾智絵さん
いただいたレビュー（随時更新）
SRE NEXT 2023でクロージングキーノートで登壇しました
はじめに
こんにちは、Google CloudでオブザーバビリティとSREの担当をしているものです。去る2023年9月29日、SRE NEXT 2023というSRE関するカンファレンスにて、僭越ながらクロージングキーノートスピーカーを拝命しましたため、その責務をまっとうして参りました。
「信頼性目標とシステムアーキテクチャー」
発表スライドと当日の録画へのリンクはこちらです。
クロージングキーノートという貴重な機会をいただいたわけですが、自分の立場として参加者の方々に何を一番伝えたいか、何が求められているのかなど、依頼を頂いてから悩ましい時間が多くありました。SREというのはたくさんのプラクティスのまとまりですが、やはり自分が伝えたいことがあるとすればSLOに関わることだなと思い、セッションタイトルだけ思いついたので、細かな内容がまだなにも思いついていない状態で運営の方にお伝えしました。
詳細はセッションスライドと録画を見ていただくとして、この発表で伝えたかったことは
- サービスレベル目標を決めると、自ずとシステムのアーキテクチャーや開発のプラットフォームに影響が及ぼされるということ
- 信頼性目標にたどり着くためのアーキテクチャーは対話によって妥当な点を見出すしか無いこと
発表の中では確率を例にして検討を重ねていますが、こういった検討そのものが開発や運用のチーム全体で共通に認識されるべきもので、検討の末に必要になったもの費用も論理的に導かれることが伝われば幸いです。プラットフォームエンジニアリングという言葉もありますが、発表の中でも述べているように、ある程度以上の信頼性はプラットフォームがなければ達成できませんし、Four Keysも本来であればSLOを達成すべきプロセスの文脈で出てくるはずのものです。
このセッションをきっかけに、一人でも多くの方にSLOの有用性が伝われば幸いです。
こちらの書籍にも本セッションで話した内容が触れられていますので、ぜひご一読ください。
r9y.dev 盛り上げていきましょう！
自分のセッションの中で紹介した r9y.dev は「SREエンタープライズロードマップ」を著したSteve McGheeやJames Brookbankが始めたプロジェクトで、各信頼性目標に応じて必要になるテクノロジーを議論しながら作っているものですが、皆さんからのフィードバックやレポジトリへのプルリクエストを元に発展しているものです。ぜひdiscordに参加してコメントをいただけると嬉しいです。
またオンラインで公開ディスカッションを行っているのですが、日本からの参加者が多くあると事前に分かればAPAC時間での開催もできると思うので、是非discordやGitHubのレポジトリで提案してください！
SRE NEXT 2023の熱気がすごかった
SRE NEXTへは初回の2020年の回から3回連続で登壇の機会をいただき、個人的には思い入れのあるカンファレンスの1つです。
特に日本でSREに関するトピックだけを扱った（SREをカンファレンス名に冠した）数百人規模のカンファレンスというのはSRE NEXTしかなく、その点で個人的にとても応援しているカンファレンスでした。そして今年はオンサイトイベントとして復活した回だったわけですが、セッションの内容が「SREのプラクティスを実践してきての学びや振り返り」に関するものが多く、明らかにコミュニティのSREに対する理解や実践度合いが進んできていると思いました。また会場の雰囲気も活気があり、これからが本当に楽しみなカンファレンスだなあと感じました。
自分はSREcon APACの2022と2023でProgramme Committeeに参加したのですが、SREcon APACのセッション内容と比較しても、SRE NEXTは実践的な内容が多く、日本のSREコミュニティの質の高さが伺えました。SREconの場合はグローバルサービスの運用に関する発表が多いですが、SRE NEXTは日本ローカルならではの小中規模の組織での実践の話が聞けるのが貴重だなと感じます。
個人的に好きだったもの
セッションに参加したりブースを回ったりして面白かったものを、Xに投稿されていた写真をお借りして振り返ろうと思います。
途中率が高い書籍が可視化されてるのおもろい #srenext pic.twitter.com/qImCvF5o00
— EG (@EGMC) 2023年9月29日
私が翻訳や監訳に関わった3冊（「SLO サービスレベル目標」「オブザーバビリティ・エンジニアリング」「SREの探求」）の途中率が高いので、読了率を上げる企画をなにかしたい！（アイデア募集中）
続いて基調講演 #srenext_a#srenext pic.twitter.com/My1vbaZj4D
— 西から来た馬づらの男 (@beppu01) 2023年9月29日
セッションの合間に流れるこの映像とかセッション開始時のティザー動画とか、めちゃくちゃかっこよく作られてて、ただ感心していました。
一生コーヒーとどらやきとクッキーとチョコをデプロイし続けるマンしてる#srenext #ワキヤコーヒー #nifty #bitkey #DMM pic.twitter.com/e1d4Lf7huL
— おかしん | 岡村慎太郎 (@okash1n) 2023年9月29日
わざわざ広島からいらして運営にも参加してくださっていた @okash1n さんの「ワキヤコーヒー」さんのコーヒーは美味しかった！
#srenext でオライリーさんブースで書籍買って2024年カレンダーもらえちゃう！#newrelic pic.twitter.com/DpRIJURukV
— Tsuyoshi Shimizu @New Relic (@photographed) 2023年9月29日
オライリー・ジャパンさんのブースはありがたいことに私の翻訳、監訳に関わった書籍（上記の3冊に加えて「Go言語による並行処理」も）を販売してくださっていました。こういうところで自分の本を紹介できるのは嬉しい！
トレーシングとプロファイルの雑談ができたので嬉しかった🤩 #srenext pic.twitter.com/RUKWVXdLFx
— 逆井(SAKASAI) (@k6s4i53rx) 2023年9月29日
ホールウェイトラックも大いに盛り上がって、新しいイベントの企画とかその場で決まっちゃう感じがコミュニティの勢いを感じました！写真に写っている逆井さんにも登壇してもらうOpenTelemetryのイベントが今月半ばにあります！
Topotalブースでwaroomのデモを @nari_ex さんに見せてもらった！ #srenext pic.twitter.com/h1EM0AEBu8
— Yoshi Yamaguchi (@ymotongpoo) 2023年9月29日
Topotalのインシデント管理ツールのWaroomのデモを見せてもらいました。オープンベータが出たときに触らせてもらったときから、すごく進化していてこれからどうなっていくのか楽しみです！
おわりに
また来年も開催されることを願っています。今年の後半は自分はだいぶSLOを中心にメタな登壇が多かったので、来年は少し技術を深ぼった内容の登壇にまた戻していきたいという気持ちになったカンファレンスでした。運営の皆様、お疲れ様でした！
関連リンク
冬キャンプのほうが好きな理由
はじめに
先日、友人家族とデイキャンプをしたんだけれども、まだ友人家族は宿泊するキャンプをしたことがなく、色々とハードルがないか調べているところだったそう。なにかを決めるときは色々な制約があるわけだけれども、様々な理由から自分は冬キャンプのほうが好きなので、理由とともにそれをお伝えしました。
今日は「特に近年はキャンプは冬の方がいい」という話を力説してきました
— Yoshi Yamaguchi (@ymotongpoo) 2023年9月18日
せっかくなのでメモとして自分が冬キャンプのほうが好きな理由を説明していこうと思います。なお、前提として自分は東京在住で、冬キャンプは主に南関東、道志村〜富士周辺、山梨県北杜市の南側などに行くことがほとんどです。
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缶のみで過ごせています。
![ソト(SOTO) パワーガス 3本パック ST-760 [HTRC 2.1]](https://m.media-amazon.com/images/I/41ysFTImO0L._SL500_.jpg "ソト(SOTO) パワーガス 3本パック ST-760 [HTRC 2.1]")
こういった高いCB缶には液化イソブタンや液化プロパンが入っていて、沸点が低め（それぞれ -11.7度、-42度）なので、オートキャンプに行くような場所では問題なく過ごせています。OD缶はそもそも高山でも使えるように中身が液化イソブタン、液化プロパンがメインになってくるため、こういった心配はほぼありません。（安いOD缶でも液化イソブタンと液化ブタンの混合で、CB缶のように液化ブタンのみということはありません）
液体が凍る
メリットで触れていた外気温の低さですが、気をつけないと凍ってしまいます。うっかり凍らせてはいけない容器に液体が入っていると、朝起きたときに容器が変形したり割れてしまっているということがあります。また容器が壊れるまで行かなくても、朝起きて水を使いたいのに凍ってしまっていて使えないということもあります。凍らせたくないものは寝る前にクーラーボックス等に入れておくなど注意が必要です。
開いているキャンプ場が少なくなる
人が少なくなるのはいいのですが、冬は閑散期になるため、冬期は運営しないというキャンプ場もしばしばあります。特に標高が高いキャンプ場は、キャンプが好きな人であっても、よっぽどしっかり準備しないと凍死のリスクがあるために閉鎖しているという場合もあります。またキャンプ場自体は開いていても、たどり着くまでの山道が凍結や積雪で通行困難になっていることもしばしばあります。スキー場に行くときと同様、スタッドレスタイヤやチェーンなどの装備はしっかり整えていく必要があります。
風が強い
小学校や中学校の理科でも習う通り、冬は西高東低の気圧配置になることで偏西風が強化されて強い風が吹きます。（冬から春かけてが強い）特に冬は気温も低く、空気中の水蒸気量も減るため同じ風速でも風を強く感じます。キャンプをしていて、雨よりも怖いのは風です。風速5m以上を超えると、テントやタープが煽られてペグが勢いよく抜けて人や車に当たったり、ポールが折れてテントが建てられなくなったり、焚き火の熾が飛んでいくなど、危険です。これは定常的な風速ではなく、瞬間最大風速で起きえるリスクなので、キャンプ場の立地にもよりますが、設営時には特に気をつける必要があります。
ゆるキャン△でも取り上げられたふもとっぱらキャンプ場は遮るものがないだだっ広いフリーサイトで、冬は通称「テントの墓場」と言われています。その凄まじさの例として次の動画をご覧ください。
とはいえ、いまは天気予報も発達していて、風速予報なども結構正確に出ていたりするので、事前に調べておくことでできる対策もあります。
おわりに
以上はいま装備がすべてある状態で考えたときに手間やコストを考えると、自分は冬キャンプが好きです、という記事でした。もちろん装備を揃えるにはそれなりに費用がかかりますし、また収納するにも場所を取ります。このあたりは趣味への投資という点と、家族の理解などがあるので一概にどちらが良いと言えるものではないですし、どの季節もキャンプは楽しいと思うので、興味がある人は是非一緒に行きましょう！
散々「冬が良い」と書いてきておいてなんですが、キャンプのベストシーズンは晩秋だと思います！
*1:オートキャンプで行くような場所では標高が100m高くなるごとにおよそ0.6度気温が下がりますが、それでも1000mで6度程度までしか違いがありません。
「SLO サービスレベル目標」という本が出版されました #slobook
はじめに
こんにちは、Google Cloudのオブザーバビリティ担当者です。このたび私が翻訳ならびに監修として関わった「SLO サービスレベル目標」という本がオライリー・ジャパン社より出版されました。本日より書店ならびに各社オンラインストアでご購入いただけます。
電子書籍版についてはオライリー・ジャパンのサイトよりePub、PDFの各種フォーマットにてご購入いただけます。
SLOがなぜ重要なのか
まず本書の意義について解説する前に、サービスレベル目標（Service Level Objective; SLO）がなぜ重要なのかについて改めてお伝えしたいと思います。
サイトリライアビリティエンジニアリング（SRE）において、その手法の名称にもあるように、「ユーザーの信頼性」というのは、その原理に根ざす重要な考え方です。システム運営に関わる人間および会計のリソースは有限であるため、サービスの品質もどこかで妥協しなければいけません。しかしその妥協がユーザーがシステムに期待する品質*1未満ではユーザーはサービスを利用してくれなくなってしまいます。そのためユーザーの満足度との相関が強い指標（サービスレベル指標）を発見し、その目標値（サービスレベル目標）を決める、というのがサービスレベル目標の考え方です。この目標は内部的なものであり、ユーザーとの契約ではないので、SLAと違い何度でも自由に見直し、より適切な値を探していくことになります*2。
これは、システム運用の観点から見たビジネス的に重要な指標にもなり得るもので、SREというものが広く認知される以前から、データ駆動型経営をされている企業では名前こそ違えど、この観点から目標値を決めて運用してきたところもあるでしょう*3。SREではこれらの概念に対してSLI、SLO、さらにエラーバジェットやバーンレートといった名称と定義を与えて、さらにそれを継続的に運用していくという枠組みを作ったことに価値があると思います。一方で、こうした概念がSREとともになければならないかというとそんなことはありません。肝心なのは「自分たちが行っていることがSREかどうか」ではなく「自分たちのサービスがユーザーを満足させているのか」どうかであり、その文脈においてSLOという概念は各ビジネス指標のKPIと同様にいかなるビジネスにおいても考慮されるべきであるはずです。特にサービスの収益がシステムに依存している度合いが強ければ強いほど、このSLOという指標はビジネスにインパクトを与えているはずです。
2020年代において、たいていのビジネスはITシステムに依存していますから、このSLOという概念は会社組織の中で役職問わず理解されるべきものであると、私は考えています。「SLOをもっと使っていきましょう」という話に関しては次の文章でもう少し掘り下げて書きましたので、ご興味あればあわせてご一読ください。
「SLO サービスレベル目標」はどのような本か
昨日SLO本出版イベントを開催いただきまして、書籍の内容もお話しました。お時間ある方はこちらもご覧ください。
本書は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さんに開催いただきます。オンライン開催ですので、お時間あればご参加ください。
2022年版のState of DevOps Reportの日本語訳が公開されました
はじめに
こんにちは、Google CloudでオブザーバビリティとSREの担当をしているものです。毎年公開されると多くの方に参照いただいているState of DevOps Reportの最新版である2022年版が、日本語を含む10ヶ国語に翻訳されました。こちらのページで言語設定を日本語に設定いただいた上でPDFを申請すると日本語版がダウンロード出来ます。
これまでもすでに英語版が広く紹介されていたと思いますが、改めて日本語版が出たことで、より多くの方々におすすめできるようになったと思います。（次のスクリーンショットは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以降から紹介されています。）
上の『LeanとDevOpsの科学』は非常に有名なのでよく参照されていますがSODRはそこからのトレンドの変化を追っていくのに非常に役立つ資料となっています。まだ上の書籍しか読んだことのない方は、ぜひSODRも読んでみてください。上にありますように2022年版は日本語版が出ましたので、それを眺めるだけでも面白いかと思います。
2023年版向けの調査が始まっています
SODRが成立しているのは多くの企業の方々に調査に参加いただいているからこそです。
毎年多くの企業に参加いただいた結果、年次の追跡調査が可能となり、結果トレンドの変化などがさまざまに分かってきました。一方で、これまで英語のみで調査を行い、調査結果としてのSODRも英語版のみしかなかったためどうしても英語圏に偏った調査となっていました。（下図はSODR 2022のp.63より抜粋。日本からの参加者は全体の1%でした。）
今年の調査もすでに開始していますが、今年は調査の多言語化にも取り組んで、近々日本語でも調査が可能となります。*1多くの国からの調査が集まることで、各地域でのトレンドなどが見えてくることと思います。（追記 2023.06.02 日本語版のサーベイが公開されましたのでリンクを挿し換えました）
昨今もDevOps、SRE、Platform Engineeringなど、さまざまなキーワードが飛び交っています。しかし、その実態として、業界全体の各組織でどのような取り組みがなされているのでしょうか。それを明らかにしていこうという取り組みがSODRです。少しお時間かかる調査ではありますが、ぜひご協力ください！よろしくお願いします。
*1:公開され次第追って紹介します
「オブザーバビリティ・エンジニアリング」という本が出版されました #o11yeng
はじめに
こんにちは、Cloud Operations担当者です。このたび私が翻訳として関わった「オブザーバビリティ・エンジニアリング」という本がオライリー・ジャパン社より出版されました。本日より書店ならびに各社オンラインストアでご購入いただけます。
電子書籍版についてはオライリー・ジャパンのサイトよりePub、PDFの各種フォーマットにてご購入いただけます。
また上記書籍情報ページに質問は報告を行うための連絡先も記載されておりますので、なにかありましたらそちらよりお問い合わせください。
TL;DR
「オブザーバビリティ・エンジニアリング」はオブザーバビリティの概念を理解し、それを実際にシステムに備えるために必要な技術要件を知り、実践につなげるための書籍です。オブザーバビリティを実践いる方やこれからオブザーバビリティを活用していく方には必携の書籍になると思います。ぜひご一読ください。
「オブザーバビリティ・エンジニアリング」のおすすめの読み方
本書は350ページ程度の中型本で、技術書としてはちょうどよいボリュームだと思います。したがって、オブザーバビリティに関して包括的に理解を深めたいという方であれば頭から通して読み進めていただければと思います。本書は「オブザーバビリティ」と呼ばれるシステムの性質に関して、その技術的な要件や具体的な実装方法、導入の際の文化的側面などを扱った書籍です。そのため、オブザーバビリティの大局観が得られずなにか参照したい方、これからオブザーバビリティを導入していくための考慮事項を把握したい方、オブザーバビリティの技術要件を理解することで既存のシステム監視との差異を理解したい方におすすめです。
本書を読むにあたって、関連書籍として同様にオライリー・ジャパンから出版されている「入門 監視」をご覧いただけると、オブザーバビリティと監視の関連についてより深い理解が得られると思います。また「SRE サイトリライアビリティエンジニアリング」「サイトリライアビリティワークブック」などのサービスレベル目標やアラートの設定に関する章も、本書のテーマと大きく関連しているので、SREの推進としてオブザーバビリティの実践や導入をされている方は、そちらも参照いただくのが良いと思います。
いわゆるSRE本はSREをテーマに横断的にプラクティスを紹介しているのに対し、本書はオブザーバビリティをテーマに概念的な話から具体的な実装の話までを一気通貫で紹介しているので、併読することでオブザーバビリティがSREの中でどこに位置しているのか、何を可能にするのかの理解が明確になると思います。
一点、私のあとがきにも書きましたが、本書はHoneycomb.ioというオブザーバビリティSaaS企業のエンジニア3名によって著されているので、その点に留意して読み進める必要があります。本書の具体例がどうしても彼らの製品の機能や実装による説明になっていので、その背景にある技術や思想を常に意識しながら読みすすめると、皆様が利用しているツールやシステムにおいてどのように適用できるか、何が達成されているかの理解が進むかと思います。
出版に至るまでの話
本書はCharity Majors、Liz Fong-jones、George Mirandaによって著された、 "Observability Engineering" の日本語訳です。
本書が出版されたのは2022年6月だったのですが、本書はEarly Releaseの対象になっていたのと、著者の一人であるLiz Fong-Jonesが元々Googleで同じチームでの同僚だったこともあり、出版以前に最初の数章が公開されてからすぐに読み始めていました。本書が解説しようとしている内容は、SREがだいぶ普及してきた現在において、サービスレベル目標をもとにした運用をする上で切っても切り離せないオブザーバビリティの獲得を行う方法であり、正式版の出版をかねてより期待していました。実際に正式版が出版され、改めてその内容は「オブザーバビリティ」の定義を解説し、本来の監視（モニタリング）と技術的にどのように異なる要件が必要なのかを解説した素晴らしい書籍であると感じました。「オブザーバビリティ」という用語が本来の意味合いから離れて、監視系ツールのマーケティング用語として濫用され、ただ「監視」という用語の置き換えとして用いられるケースが散見される中で、利用者側がその用語の意味を正しく理解するということは非常に重要であると考えています。当たり前ではありますが、そもそも別の言葉が導入されたということは概念として異なるからです。
こういった背景から、日々コミュニティで親しく、また「Java開発者のための関数プログラミング」「Go言語による並行処理」での編集としてお世話になった、オライリー・ジャパンの瀧澤さんに本書を日本語化する意義を紹介したところ、2022年7月半ばには早速企画にしていただき、そのまま翻訳の流れとなりました。また同様にいくつかのコミュニティでかねてよりオブザーバビリティやOpenTelemetryに関する情報を共有している大谷さん（以後、かっちゃん @katzchang）も翻訳に興味があるとのことだったので、半分ずつ担当して共訳することとなりました。
前述の通り、かっちゃんとは以前からオブザーバビリティに関して意識合わせがだいぶされていたこともあり、共訳の作業は大変スムーズでした。私自身が共訳をするのが初めてだったこともあって、訳語の統一などの点で難しさを感じた点もありましたが、自分の担当箇所の初校分に関しては9月中には終わらせることが出来ました。ただ、その後本業がだいぶ立て込んでしまい、見直しの時間があまり取れなかったので、レビュワーの方々にはだいぶ負担をおかけしてしまいました。
謝辞
訳者あとがきにおいても掲載いたしましたが、本業の合間を縫って、年末のお忙しい中、短い時間にもかかわらず有意義なレビューを数多くくださったレビュワーの皆様に感謝致します。
レビュワーの皆様（五十音順）
- 大谷天音さん
- 小林良太郎さん（@ryota_hnk）
- 瀬尾直利さん（@sonots）
- 橋本和宏さん
- 馬場俊彰さん（@netmarkjp）
- 松浦隼人さん（@dblmkt）
- 吉川竜太さん（@rrreeeyyy）
- 若山史郎さん（@r_rudi）
- 瀧澤昭広さん（@turky）
レビュワーの皆様にはエンジニアとしての観点から多くのコメントを頂き、また解釈が不明瞭な部分に関しては、より明瞭になるように対案をいただくなど、非常に有益なコメントを頂きました。中でも何名かには多大なレビューを頂きました。瀬尾さんには、レビューが少なくなりがちな後半からレビューをいただくなど、訳者としてありがたかったです。松浦さんは「入門 監視」を始め多くの翻訳をされていることもあり、訳に関して良い対案をいただきました。馬場さんには、文章として説明が甘くなって部分（原文に原因があるものも多かったのですが）の的確な指摘をいただきました。若山さんには細かな解釈に関して指摘を数多くいただきました。
瀧澤さんに、Sphinxを使った執筆環境を用意いただいたことで、私は大変執筆しやすかったです。「Go言語による並行処理」を翻訳したころから、更にパワーアップして、瀧澤さん側でSphinxが生成するXMLからInDesignへの流し込みを自動化するスクリプトを作成されていたことで、依頼してから1日程度で組版された原稿をいただけるというのは、レビューを行う際に非常に有益でした。実際に執筆をされたことがある方は実感されると思うのですが、原稿のレビューを行う際に、フォーマット（テキストファイル、PDF、紙など）が異なるだけで見え方がまったく異なります。様々なフォーマットでの確認を手早く数多く行えるということは、ソフトウェアのレビューと同様、非常に有用です。ラムダノートの鹿野さんもそうでしたが、編集担当者がポストプロダクションの領域も担当されていることの心強さを感じました。
またかっちゃんとは本書の翻訳に関して、そもそもの本の立ち位置やその価値の認識、背景技術の理解など、息があっていたので、チャットで大きな反対意見でぶつかって議論になることはなく、ツーカーで作業を進めてこれたのはとても気持ちのいい体験でした。翻訳作業はこれまで割と孤独に行っていたので、息のあった共訳者がいる頼もしさを感じました。また機会があったら一緒にやりたいです。
あらためて、みなさまありがとうございました。
おわりに
手前味噌にはなってしまいますが、私が今現在で「SREおよびオブザーバビリティに関して読むべきN冊」という書籍を挙げるとするならば、確実にそのリストの上位に入るべき一冊だと考えています。ぜひ多くの方のお手にとっていただき、日本においてもオブザーバビリティに関する議論がより活発になることを願っております。
