YAMAGUCHI::weblog

海水パンツとゴーグルで、巨万の富を築きました。カリブの怪物、フリーアルバイター瞳です。

YAMAGUCHI::weblogの2021年を振り返る

misc

はじめに

こんにちは、Cloud Operations担当者です。2021年も最後日です。更に重要なのは本日は私の誕生日であることです。例のやつを貼りました。よろしくお願いします。

www.amazon.jp

1年を通じてコロナ禍だった年となりました。相変わらずオミクロン株やさらなる新種株が出てくるなど、予断を許さない状況ではありますが、来年こそは何かしら光明が見えるといいなと思います。

関連エントリ

ymotongpooの2021年

去年立てた目標

去年の振り返りでは次のような目標を立てていました。これをベースに振り返っていこうと思います。

  • オブザーバビリティ関連の展開
    • OpenTelemetryは安定版がでるので、イベントを行っていきたい
    • Collector関連でOSSを出したい
    • Go関連だとPBTの知見をもう少し深めて、オブザーバビリティに絡めていきたい
  • 執筆・翻訳・監訳をすすめる
    • 執筆はラフでもいいので書いてしまおうと思う
    • 翻訳はコツコツ
    • 監訳の原著レビューを早めに終わらせて、早く監訳プロセスに入れるよう企画を通す
  • FP業の展開
    • 今年は一切できなかったので、ファイナンシャル・プランニング関連でなにかしたい
  • 自作キーボード
    • お店の赤字の改善
    • 自分でキーボードの基板を設計する

2021年はコロナ禍において終始在宅勤務の1年でした。*1 2020年に比べたときの変化で言えば、社会もようやく恒常的に在宅勤務を行うことに対しての覚悟や諦めがついたのか、在宅勤務が当たり前になり、また在宅勤務が常態化してから2年目になったということで生活リズムも安定しました。

仕事

勤続10年

2011年4月にGoogleに転職して勤続10年となりました。細かな話は下のエントリーで書いたので割愛。

ymotongpoo.hatenablog.com

とりあえず勤続10年でなにかあるかなと思ったけど会社からはDoodleの印刷されたものが送られてきただけで、賞与も休暇もない感じでした。さすがにちょっとそれはないんじゃないの、と思ったけど、まあいいや。*2

オブザーバビリティ関連の展開

OpenTelemetryは2020年の予定ではトレース、メトリクスともに安定版リリースがされる予定だったのですが、相変わらずの楽観的な計画だったのでトレースだけが安定版リリースで、メトリクスの安定版リリースは2022年上半期に順延されました。というわけで、イベントは安定するまで先送りにしてきました。来年はOpenTelemetryのメトリクスの安定版のリリースは確実なので、来年こそはOpenTelemetryイベントをやっていきたいですね。

仕事では外に出て活動をすることよりもOpenTelemetry関連の機能をGoogle Cloud内で充実させていく方向の仕事が増え、またコードを書く仕事よりも、製品の方向性に関しての提案や、Google Cloud内の製品のOpenTelemetry対応などの調査と今後の計画を立てたりと、PdMと製品開発チームの間での業務が多かったように思います。Collector関連のOSSはGPU周りのものを本体に入れようと試みたのですが、メンテナーと意見が合わず、とりあえず自社のOrganizationで出していく方向で仕切り直すことにしました。

対外的にはおかげさまでSRE関連やオブザーバビリティ関連でお呼びいただくことが何度かあり、国内外のいくつかのイベントやポッドキャストでゲストに呼んでいただきました。

forkwell.connpass.com

e34.fm

dev.to

今年は社内仕事がだいぶ多かったので、来年はもう少しブログ等も含めて露出を行っていければと思っています。

Go関連

今年はGo関連は春にGo Conference 2021 Spring Onlineの開催に関わりました。

gocon.jp

少しずつスタッフが増えてきて、本当にありがたい限りです。秋にはkyoto.goとumeda.goの方々を中心に開催していただいて、成功裏に終わり今年もGoConが無事に開催されたことにほっと胸をなでおろしています。

来年の4月23日にGo Conference 2022 Spring Onlineが開催されることは決定しているわけですが、それと前後して良いお知らせが他にもできれば良いなと思っています。

gocon.jp

来年も引き続き @tenntennや @micchiebear を始め、多くの方たちと一緒に楽しく運営できるといいなと思います。

執筆・翻訳・監訳

このカテゴリーでいうと、去年から監訳を進めていた「SREの探求」が9月に出版されました。

SREの探求 ―様々な企業におけるサイトリライアビリティエンジニアリングの導入と実践

SREの探求 ―様々な企業におけるサイトリライアビリティエンジニアリングの導入と実践

Amazon

本書の出版の経緯に関しては下記エントリーで書きました。

ymotongpoo.hatenablog.com

他にも並行していくつか案件があるのですが、相変わらず進捗は芳しくないので時間を見てやっていくしかないですね。来年も最低1冊監訳中の本が出せると思いますので、ぜひお楽しみに。それとは別に翻訳のほうが一向に進まなかったのでこちらは少しずつでもやっていかないと。

趣味

自作キーボード

お店の赤字は改善して、プラスマイナスゼロくらいにはなったのですが、結局また仕入れなどがあるので恒常的にプラスに転じるのはなかなか難しいなと感じています。また世界的な半導体不足がまさか自分にも直接的に影響するとは思わなかったのですが、キーボードの制御に使うマイコンも大幅に値上がりし、仕入れ値が一昨年の倍近くに上がっています。こうなってくると販売価格をかなり上げなければ売れば売るだけ赤字になる状況になってしまうので厳しい限りです。おそらく値上げをすることになると思います。

しかしおかげさまで1年間ほそぼそとでもECサイトの運営をすることで小規模小売事業者の様々な苦労であったりコスト感がわかりました。自分が通販で何かを購入するときにはどれくらいの原価がかかっているのかなど、なんとなく想像できるようになって、より販売者を身近に感じられるようになりました。

今年は本業のほうの業務が増えたのでなかなかキーボードの設計ができなかったですが、今年はなんとか一つ設計したいと思っています。

キャンプ

去年は一年中家にいて外出もろくにできず、本当に精神衛生に良くなかったので、今年は一念発起して車を購入し、時間と状況が許す限りキャンプに行っていました。初期出費はかなり大きかったですが、自分の精神衛生だけでなく、家族の精神衛生やコミュニケーションのためにすごく良い趣味になったなと感じています。この状況なので相変わらず海外に行くことはできず、国内旅行をするにも移動手段や場所が限られる中で、キャンプは人との距離が保たれつつ、自然が多い場所に行けるとても良い気分転換になっています。

初期出費は大きかったものの、ある程度道具が揃ったあとは交通費と食費、キャンプ場代ぐらいしかかからないので家族で行くにしても普通の旅行と比べるとだいぶ安上がりで済んでいるのもありがたいです。来年もこの熱は冷める気がしないのと、気軽に他の形式の旅行ができる状況にはならないと思っているので、引き続きキャンプを楽しんでいきたいと思います。

語学

今年の頭からまたDuolingoを復活してコツコツと続けています。

以前Duolingoを試したときは日本語ベースで他の言語を学ぶ教材を見たときにあまり品質が良くないなと思ったので、英語ベースで中国語とスペイン語を勉強しています。言語によってコンテンツの量や品質に差があり、英語ベースだとスペイン語とフランス語のコンテンツはものすごく多く、中国語も悪くはないのですがHSK3級程度のコンテンツで終わってしまうので、ここから先のレベルの内容がほしいなと感じています。中国語は一通りコースを終えてしまったので今は復習しかしていません。一方でスペイン語は先にも述べたとおりコンテンツが充実していて、今はもっぱらスペイン語をメインに勉強しています。さらに遊びでフランス語、ロシア語、韓国語も簡単には読めるようになっておきたいと思い、スペイン語に飽きたときにどれかの言語をちまちまと進めています。

Duolingoは隙間時間でできるのが本当に素晴らしく、1日1レッスンでも達成感を得られるのが良くできているなと感じます。来年にはDELEかHSKを受けてみたいなと思います。

来年に向けて

というわけで来年はこんな感じでやっていきたいと思います。（一部去年からの続き）

  • オブザーバビリティ関連の展開
    • OpenTelemetryは安定版がでるので、イベントを行っていきたい
    • Collector関連でOSSを出したい
  • Goコミュニティ関連
    • Go Conference 2022 Springの運営を無事終わらせる
    • Gophers Japanの運営体制を確立する
  • 執筆・翻訳・監訳をすすめる
    • 翻訳はコツコツ
    • いま行っている監訳を終わらせる
  • 自作キーボード
    • 自分でキーボードの基板を設計する
  • キャンプ
    • 引き続きキャンプ道具の洗練をさせていく
    • 悪天候キャンプに慣れる（雨キャンプは未経験）
    • ソロキャンプの充実
  • 語学
    • DELEかHSKを受ける

*1:最後の2ヶ月は多少オフィス勤務はあったものの、同僚含め在宅勤務がメインだった

*2:昔はサバティカル休暇1ヶ月もらえたんだけど、その後に辞める人が多すぎるってことでいつの間にかそれも消滅してた

Go製アプリケーションのコンテナ化にはkoを推したい

Go

はじめに

こんにちは、Google Cloudでオブザーバビリティを担当しているものです。Cloud Operations suiteをよろしくおねがいします。（宣伝終わり）

この記事はGo Advent Calendar 2021 その1の22日目の記事です。昨日は @sago35tk さんの「ESP32 向けに TinyGo をセットアップする」でした。TinyGoのコアな情報を日本語で教えてくれるtakasagoさんには本当にいつも感謝しています。

さて、今日はGo製のアプリケーションをdockerlessでコンテナ化できるkoの紹介をします。koは本当にイチオシのツールで、みんなに使ってもらいたいのでぜひ使ってください。

github.com

DockerによるGo製アプリのコンテナ化

まず最もポピュラーと思われるDockerを用いた場合のGo製アプリケーションのコンテナ化の方法についておさらいします。Go製のアプリケーションで最もシンプルな構成の場合、go build をして特定のパスに置いた後、アプリケーションが使うポートを EXPOSE して、CMD もしくは ENTRYPOINT でそのパスを指定してあげる、というような形になります。

具体的には、次のような簡単なGoのアプリケーションがあった場合

package main

import (
    "log"
    "net/http"
)

const port = "8888"

func main() {
    http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
        w.Write([]byte("Hello, world!"))
    })
    log.Println("starting server on :" + port)
    if err := http.ListenAndServe(":"+port, nil); err != nil {
        log.Fatalf("error running server: %v", err)
    }
}

Dockerfileとして次のようなものを用意する、ということです。

FROM golang:1.17.5-bullseye as builder
WORKDIR /dist
RUN go build -o server

FROM gcr.io/distroless/base-debian11
WORKDIR /app
COPY --from=builder /dist/server /app/server
EXPOSE 8888
CMD ["/app/server"]

koを使った場合

しかしながら、これだけのためにわざわざDockerをいれたいかと言われたら、自分は入れたくありません！そこでkoを使います。

github.com

本日二回目の埋め込みリンクです。koはGo製アプリケーション専用のDockerlessコンテナビルドツールなのですが、たとえば上のアプリケーションの場合は、go build を叩くかのように、設定ファイル等用意する必要なく、この ko publish コマンド一発でコンテナが作れます。

$ ko publish --local --base-import-paths .
2021/12/22 01:08:18 Using base gcr.io/distroless/static:nonroot for test
2021/12/22 01:08:19 Building test for linux/amd64
2021/12/22 01:08:20 Loading ko.local/test:4a9444968723e9d5d24d25b07aaaa504c9ea8a1921273a3753028e5e6d9f5dc9
2021/12/22 01:08:20 Loaded ko.local/test:4a9444968723e9d5d24d25b07aaaa504c9ea8a1921273a3753028e5e6d9f5dc9
2021/12/22 01:08:20 Adding tag latest
2021/12/22 01:08:20 Added tag latest
ko.local/test:4a9444968723e9d5d24d25b07aaaa504c9ea8a1921273a3753028e5e6d9f5dc9

いろいろオプションが付いていますが、これは気にしないことにして、このコマンドによって ko.local/test というイメージができました。これは go.mod でモジュール名を test にしているからです。また ko.local はレジストリ名が自動でprefixになっているということです。（ --local オプションをつけたことによる。）

たとえば KO_DOCKER_REPO という環境変数で gcr.io/foo/bar を指定して、アプリケーションのモジュール名を github.com/xxx/yyy とした場合には、コンテナイメージ名は gcr.io/foo/bar/github.com/xxx/yyy としてくれる、ということです。

koのコマンドがGo製のアプリケーションをビルドした後、よしなにそれをコンテナ内に配置し、エントリーポイントの設定をしてくれ、設定したコンテナレジストリ向けの名前でイメージを作成してくれます。簡単ですね！

ko のインストール

さて、koは簡単そうだ、という雰囲気がわかったところで、ko自体のインストール方法ですが、これも超簡単です。ko自体もただのGo製ツールですので、Goが手元にインストールされている人であれば

go install github.com/google/ko@latest

これでおしまいです。Dockerも必要ありません。macOSな環境では本当にこれは便利ですね！

当然バイナリ配布もされているので、手元にダウンロードしてくればそれで終わりです。各種方法は公式ドキュメントを見てください。

ko の挙動のカスタマイズ

とりあえず最低限動かせるコマンドを紹介したので、次に ko の挙動を変えたい場合にどうするかを紹介します。たとえば、koで作るコンテナのベースイメージを変更したい場合にはどうしたらいいでしょうか。（デフォルトは gcr.io/distroless/static:nonroot ）あるいはGoのビルドの際に必要な環境変数を渡したい場合にはどうしたらいいでしょうか。こうしたカスタマイズは .ko.yaml というYAMLファイルで設定します。例えば次のような具合です。

defaultBaseImage: gcr.io/distroless/base-debian11

builds:
  - id: main
    dir: .
    main: .
    env:
      - CGO_ENABLED=0

ko とコンテナランタイムとの連携

さらに ko が便利なのはコンテナランタイムと連携する場合です。たとえば Kubernetes の deployment のYAML内でコンテナのイメージを指定しますが、そこを ko の記法を使ってコンテナを指定しておくことができます。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-deployment
spec:
  replicas: 3
  ...
  template:
    spec:
      containers:
      - name: my-app
        image: ko://github.com/my-user/my-repo/cmd/app

これを ko resolve -f deployment.yaml で渡してあげると、まず github.com/my-user/my-repo/cmd/app にあるアプリケーションを ko でビルドして、環境変数 KO_DOCKER_REPO で指定しているコンテナレジストリにプッシュして、さらに ko://... の文字列をそのイメージのパスで置き換えるということをした deployment.yaml の値を返してくれます。これを kubectl apply にパイプで渡してあげたりするわけです。

apply をするだけであれば ko apply というショートカットも用意してくれています。とにかく雑にGo製アプリケーションをコンテナ化してどこかにデプロイするのがとても簡単になります。

Dockerに投げる場合でも

docker run --rm -p 8888:8888 $(ko publish --local .)

というようなワンライナーで上げられたり、Cloud Runに投げるときは

gcloud run deploy --image=$(ko publish --local .)

という具合にできます。

ko とツールの連携

さきほどちらりと kubectl との連携させるための ko resolve というコマンドを紹介しましたが、Kubernetesを扱う場合、たとえば自分は skaffold を使ってテスト環境を上げたりしています。

skaffoldでは最近 ko がサポートされたので、skaffold.yaml にkoを指定するだけで一気通貫でコンテナのビルドからKubernetesクラスタへのデプロイまでいけます！

build:
  artifacts:
  - image: my-simple-go-app
    ko:
      fromImage: gcr.io/distroless/base-debian11
      labels:
        org.opencontainers.image.licenses: Apache-2.0
        ...

おわりに

大変雑にkoを紹介しましたが、これは概ね ko の公式ドキュメント（=README）に記載されているものです。

github.com

ただいかんせんぱっと見が分かりづらいと思われるので「本当に簡単に使えます！」ということだけにフォーカスして紹介しました。来月にはDocker Desktopの有料化も始まります。コンテナ化を行うだけであれば、いまや選択肢は数多くありますので、koもその一つとして知っておいて損はないと思います。ぜひ試してみてください。

Goのリリースプロセスとブランチ戦略

Go

はじめに

こんにちは！Google Cloudでオブザーバビリティの担当をしているものです。CVE-2021-44228のおかげでバタバタしていますがみなさんはお元気ですか？

このエントリーはpyspa Advent Calendar 2021の15日目の記事です。昨日は @moriyoshit さんの「Goのロギングライブラリ 2021年冬」でした。めちゃめちゃ調べてあって良い記事でした。Goでログライブラリの選定をする際にはこちらをまず読むと良さそうです。

2021.12.21 追記: 穴が空いていたのでGo Advent Calendar 2021 その1の14日目の記事にもしました。

さて、今日は本当は「Goならわかる確定申告第三表」という記事を書こうと思ったのですが、まだ確定申告の時期ではないのでそれは辞めにします。そのかわり、今日はGo 1.18がめでたくベータ版リリースとなったので、Goのリリースプロセスとブランチ戦略の紹介をしようと思います。

TL;DR

Goは2月と8月にメジャーリリースを行います。リリースに際してはメインブランチから各バージョン用リリースブランチをフォークしてリリースします。概ねGoのレポジトリのWikiに説明が書いてあるので興味があったらこれを読んでください。

リリース

新規バージョンのリリーススケジュール

リリーススケジュールに関してはGoのGitHubレポジトリのWikiに詳細に書いてあるので、これを読めばすべてわかります。

github.com

英語を読むのが面倒という方向けに簡単に要約をするとこうなります。（この図を見ながら読んでください。図は上のWikiから引用。）

https://github.com/golang/go/wiki/images/release-cycle.png

  • メジャーリリース*1は半年ごとのサイクルで行われ、毎年2月と8月にリリースされる
  • リリースサイクルは3ヶ月ごとに前半（緑の部分）と後半（青の部分）に分けられ、前半は新規機能開発含めたすべての開発、後半はバグ修正とドキュメント更新のみとなる
  • リリースサイクル後半の2ヶ月めでベータ版（Beta）、3ヶ月めでリリース候補版（Release Candidate, RC）がリリースされる
    • ベータ版は早めに実環境で利用してもらい、バグの発見とその修正を行う意図でのリリース
    • リリース候補版はほぼリリース版と機能的には同様で大きなバグはないという想定で、リリースまではドキュメント修正が主
    • リリース候補版で修正が入る場合は相当致命的なバグがあった場合のみ
    • ベータ版もリリース候補版も多く版を重ねないように多くても2週間に1度しか出さないようにする
  • リリース候補版で無事に致命的なバグがないと確認できたら正式リリース版をリリース

こういう背景を知っていると、たとえばGo 1.11でのベータ版がbeta 3まで行ったときに「今回はバグが多いな」といったニュアンスが読み取れます。

既存バージョンのメンテナンス

基本的にリリース版は「新規機能とその追加によって起きたバグの修正がなされた」と判断された状態でリリースされるので、本来であれば修正が必要ないはずです。しかしながらバグがないソフトウェアというのは通常はありえないので、だいたい正式リリース後にバグが発見されます。

このリリース後のバグの修正、というのは各正式リリース版のブランチ（release-branch.go1.x）で行われるわけではなく、メインブランチ（＝次バージョン用の開発ブランチ）で行われた修正をcherry pickで各ブランチにバックポートする形で行われます。この対応が行われるのは最新2バージョンのみです。（例えばいま1.17がリリースされているので、バックポートは1.17と1.16に対して行われる。）

おおよそマイナーリリースは1ヶ月ごとに行われるので、パッチバージョンは5前後まで行くのが目安だということがわかります。（ただし後述のとおりセキュリテイ修正リリースが行われる場合はその限りではありません。）

またパフォーマンスや挙動ではなく、セキュリティに関する修正の場合はポリシーが異なります。セキュリティ関連のバグは3種類に分けられていて

  • PUBLIC: 影響が大きくない、あるいはすでに知られているバグで、修正は公開した状態で行われる
  • PRIVATE: セキュリテイ観点で問題があると思われるもので隠したほうがいいと判断したもの。修正は非公開で行われ、その内容はリリースの3日〜7日前にアナウンスされる。
  • URGENT: ゼロデイなどGoのエコシステム全体に影響を及ぼすような深刻なバグ。修正は非公開で行われる。

PUBLICとPRIVATEに分類されたものは他のセキュリティ関連ではないバグの修正とまとめられてマイナーリリースで行われます。URGENTに分類されたものは、その修正のみのマイナーリリースが行われます。以前はセキュリティ修正リリースは分類に関係なく単体でリリースされていたのですが、今年の3月に提出された提案によってプロセスが改められました。（過去のリリースを見るとパッチバージョンの番号がすごく多いのはセキュリテイ修正が多かったことによるものだとわかります。）

詳細はこちらを参照してください。 go.dev

修正と新規機能の作成

さてリリーススケジュールとその中身がわかったところで、次は開発による変更がどのように行われているか、というところです。開発は大きく分けて2つの種類があります。一つは機能改善やバグの修正、もう一つは新規機能開発です。

修正

セキュリティ関連でない修正はまず問題をIssue Trackerに登録します。

github.com

Issue Trackerに登録するとトリアージが行われます。トリアージが行われた際には次のどれかのラベルが付与されることになります。

  • NeedsInvestigation: 問題の原因がよくわからないので原因究明のための調査が必要
  • NeedsDecision: 問題の原因はわかっているもののどう対応するか判断しかねているもの
  • NeedsFix: 問題の原因はわかっていて、対応方法もわかっているもの

NeedsFixにラベルされたものはいつでもコードを書いて修正して良いもので、基本的には開発のメインブランチに送られているパッチはこのラベルがついた問題に対するものです。

パッチを提案するためにはコントリビューションのワークフローに則らなければいけません。現在は大きく分けて2つの方法でパッチを送ることができます。一つはGitHub経由、もう一つはGerrit経由です。*2

GitHub経由でパッチを送る場合はいわゆるGitHub Flowに沿って行います。golang/goをforkしてブランチを切ってPull Requestを作成です。コードレビュー自体はGerrit上で行われ、そこでのコメントがGitHubのPull Requestにミラーされます。

Gerrit経由でパッチを送る場合はChange (Change List) というものを作成します。Gerritの解説をするとそれだけで終わってしまうので、ここではGitHubでのPull Requestに相当する単位だと理解してください。

どちらもコードレビューが終わり修正が承認されると1コミットとしてメインブランチにpushされます。

新規機能

一方で1.18に入ったGenericsのように、言語の機能自体の大きな変更はProposalが必要になります。まずは簡単に提案の概要をIssue Trackerで起票します。起票するとGitHubのプロジェクトで管理されていきます。

まずはIncomingとなり、Goチームのレビューが始まるのを待ちます。そして週次のProposalレビューの対象になると、ラベルがActiveに変更になります。（どれが取り上げられたかはGoチームの議事録に記録されます）レビューの対象の提案はIssue Tracker上やgolang-devのメーリングリストで議論が行われます。もし大きな設計書がなくてもコードが書けそうな提案であればその場でLikely Acceptになります。

もし詳細が必要であると判断された場合にはDesign Docを書くように依頼されます。どのような機能か、その機能を提案する背景、実装例含む設計案を説明したDesign Docを作成し、再度レビューが始まります。Design Docは専用のレポジトリで管理されています。（GitHubにもミラーがある）

たとえばGo 1.18に入ったtype parameterでの例はこのような形です。

Design Docを含めた深い議論の末、晴れてLikely Acceptになったのちに、1週間特に異論が見られないようであれば、めでたくAcceptedとなり、いよいよ実際にその実装を行うためのマイルストーンが設定されます。Proposalはマイルストーンの単位となり、実装は細かな修正としてバグの修正のときと同様のプロセスでパッチが作成されます。

なお、Declineの場合はパッチが作成されないので、ここではそのプロセスは割愛しましたが、Declineの場合はその理由と共に決定がなされ、チケットが閉じられます。またHoldという状態もあり、これは議論が止まってしまって判断がつかないような状況です。議論が再開すればActiveに戻ります。

ブランチ戦略

基本

パッチがどのように作成されるかがわかったところで、いよいよブランチ戦略です。まず単発で取り込まれるような通常の修正の場合です。

go.googlesource.com

すでに上の節でも触れていますが、Goのレポジトリのブランチは基本的に master が常に最新です。そしてすべての修正はこの master に対して行われます。

f:id:ymotongpoo:20211215230908p:plain

上の図は上から下に時間が流れていると解釈してください。一番上ではまさにバージョン1.xのための開発を行っています。（リリースサイクルの前半）

先に紹介したように、すべての修正はGerritでレビューされます。Gerritの線上にある四角はGerritでのChange（GitHub上ではPull Requestに見える）を表しています。区別するために新規開発や新規実装のためのChangeは紫色に、バグ修正、ドキュメント更新、セキュリティ修正のためのChangeは水色にしています。

Changeの中の三角はPatch Set（GitHub上ではPull Request内のコミット）です。開発者は原則としてコミットは必ずGerritに対して行うような形になります。そしてレビューによってChangeが承認されると、ChangeはGit内の1コミットとして master にpushされます。（GitHubでPull RequestしたとしてもGerrit経由でpushされるためGitHub上ではforce closedしたように見える）

そして、リリースサイクルの後半に入るときにRelease freezeがアナウンスされ、新規開発や新規実装の新しいChangeはいったん受け入れを停止し、バグ修正、ドキュメント修正、セキュリティ修正のみが master に入ります。次のメールは1.18のためのRelease freeze宣言時の例です。

そしていよいよベータ版リリースとなったときに release-branch.go1.x のブランチが切られます。しかしすべての修正は相変わらず master に送られ、必要なものは都度 cherry-pick しながら release-branch.go1.x に取り込まれます。

そのまま開発を続けていって、リリース候補版が出され、そして晴れてバージョン 1.x のリリースとともに、次バージョン 1.(x+1) の開発がスタートします。このタイミングで新規機能や新規実装のChangeが取り込み可能になります。

もちろん次バージョンの開発を続ける中で、現バージョンにも影響するセキュリティ修正やバグ修正もあるので、その場合はまた cherry-pick で release-branch.go.1.x と release-branch.go.1.(x-1) の各ブランチ（最新2バージョン）にバックポートして、マイナーリリースの際にパッチバージョンを上げてリリースしていきます。（ここでバージョン名でGitのTagを打つ）

大きな新機能の開発

上記が基本的な流れなのですが、Goのレポジトリを覗くとその規則からは外れたブランチが見られます。ざっと一覧で表示してみましょう。

dev.cc
dev.cmdgo
dev.debug
dev.fuzz
dev.garbage
dev.gcfe
dev.go2go
dev.inline
dev.link
dev.power64
dev.regabi
dev.ssa
dev.tls
dev.typealias
dev.typeparams
dev.types

すべて dev.foobar という命名規則になっていることがわかります。これらのブランチの後半の単語をよく見てみると見覚えがあるような単語ばかりです。これらのブランチは大きな新機能のために作られた特別な開発用ブランチで、このブランチは master とは違い Release freeze 期間においても新規開発を取り込めるブランチとなっています。

例えばFuzzingの開発ブランチである dev.fuzz の、あるコミットを見てみます。

4651d6b267 - go - Git at Google

commit 4651d6b267818b0e0d128a5443289717c4bb8cbc
Author: Katie Hockman <katie@golang.org>
Date:   Wed Dec 2 14:37:49 2020 -0500

    [dev.fuzz] internal/fuzzing: handle and report crashers
    
    Change-Id: Ie2a84c12f4991984974162e74f06cfd67e9bb4d7
    Reviewed-on: https://go-review.googlesource.com/c/go/+/274855
    Trust: Katie Hockman <katie@golang.org>
    Run-TryBot: Katie Hockman <katie@golang.org>
    Reviewed-by: Jay Conrod <jayconrod@google.com>

日付を見ると去年の12月となっています。12月は上のリリースサイクルで説明したように Release freeze 期間ですね。このようにして、Goでは安定したリリースを行いつつ、重要な新規機能の開発は止めないようなプロセスになっています。

おわりに

というわけで、Goのリリースプロセスとブランチ戦略について大まかに説明しました。本記事によって、Goチームからのアナウンスがより身近に感じられていただけたら幸いです。今日話さなかった内容はまだまだあって、たとえば次のような話題があります。

  • dev ブランチの master へのマージプロセス
  • Gerritにpushされた際に行われるテストとそのインフラ
  • リリースの際のアーティファクトビルドプロセス

これらはまた触れる機会があれば紹介したいと思います。

オープンソースプロジェクトは様々な点で勉強になることがありますが、あまり注目されていない（と思われる）リリース戦略もその一つだと思います。もしGo以外のプロジェクトのリリースプロセスの解説記事があればぜひ読んでみたいので、ご存知でしたら教えてください。

ところでPythonでのリリースといえばパッケージングですね。明日は世界でも指折りにPythonのパッケージングに詳しい @aodag です。*3

参照

*1:Goはまだ1系しか出していないので、マイナーバージョンが更新されるリリースをメジャーリリースと呼んでいる

*2:当初はGerritのみだったのですが、Gerritに不慣れな方が多く、多くの要望があったためGitHubとGerritを同期するbotを導入して、どちらでも取り込めるようにしています。現在でもGerritが正であることは変わっていません。

*3:本人が出たがらないから勝手に宣伝するけど、いままで@aodag以上にPythonのパッケージングに詳しい人は海外のカンファレンスや会社の同僚を含めて会ったことがない。

キャンプを始めるにあたって買ってよかったもの

misc

はじめに

こんにちは、Google Cloudのオブザーバビリティ担当です。Google Cloud Operations suiteとかOpenTelemetryとかやってます。コロナ禍でなかなか気軽に街や観光にいけなくなり、ソーシャルディスタンスを保ちつつできる新しい趣味をということで今年の頭からキャンプを始めました。皆考えることは同じで折しも世の中はキャンプブーム。キャンプを始めるにあたって友達と一緒にグループキャンプなどはできませんでしたが、家族との時間は楽しく過ごせました。キャンプをはじめるにあたってはインターネットで多くの情報を知ることができました。キャンパーは相対的に見てインターネットで情報発信をしている人が多いように感じます。おかげでほぼネット通販で道具を揃えることができたわけですが、使い始めるまでそこまで重要だと思ってなかったけどあってよかったものがたくさん出てきました。そうした細かなものも含めて、本記事では初心者目線で「これがあって良かったな」と思ったものを書いていきたいと思います。

この記事はキャンプアドベントカレンダーの1日目です。

adventar.org

メイン

まずはネットで検索したら色々と事例が出てくるメインのキャンプ道具についてです。

テント

なにはともあれテントです。最初は普通のドームテントとタープを買おうかな、と思っていたのですが、すでにキャンプベテランである id:a2c に「初心者で家族で行くならツールームがいい」と勧められて、ちょうどスノーピークがエントリー用のツールームを出していたので購入しました。

スノーピーク(snow peak) エントリー２ルーム エルフィールド TP-880R

スノーピーク(snow peak) エントリー２ルーム エルフィールド TP-880R

Amazon

スノーピーク(snow peak) エントリー2ルーム エルフィールド マットシートセット マルチ TP-880-1

スノーピーク(snow peak) エントリー2ルーム エルフィールド マットシートセット マルチ TP-880-1

Amazon

1張り目でグランドシートと専用インナーマットで10万円コースは少し緊張しましたが、買ってみてこれは本当に良かったと思いました。このテントで良かったのはまず設営で迷うことがないことです。テントの設営自体が初めてだったときでもガイロープの本体への取り付けも含めて1時間半程度でできましたし、いまは慣れやガイロープの取り付けをカラビナで行うように変えたこともあって全部で30分程度で設営が終わるようになりました。テントの設営が早く終わるのは何よりも良いですね。

つい先日も最低気温3度の中キャンプをしましたが、前室で灯油ストーブをつけていたら、室内は15度くらいまで上がり、とても快適に過ごせました。雨が降るキャンプでも普通の雨程度では問題なく過ごせましたし、良い買い物だったと思います。幕がポリエステルなので雨の後の手入れも楽なのがいいですね。

いまはタープを張るのも簡単にできるようになりましたが、やはりとりあえずこれさえ建てたら寝て雨が降っても過ごせる場所ができるというのは屋外にいて何より心強いものです。夏の室内の暑さなどは考慮に値する懸念事項ではありますが、全体的に見て私のような 初心者に使いやすいテントだなと思います。

マットと寝袋

キャンプで寝れないと肝心の日中がまったく楽しめないし、それは本当に嫌だったのでマットと寝袋はお金をかけました。

Coleman(コールマン) キャンパーインフレーターマットハイピーク/シングル 2000036153 198×68×9.7

Coleman(コールマン) キャンパーインフレーターマットハイピーク/シングル 2000036153 198×68×9.7

  • コールマン(Coleman)
Amazon

モンベル（mont-bell）寝袋 ダウンハガー800＃1オレンジ（OG） R/ZIP #1121358

モンベル（mont-bell）寝袋 ダウンハガー800＃1オレンジ（OG） R/ZIP #1121358

Amazon

マットと寝袋のおかげで、これまで寝心地が悪くて寝られなかったということはありませんでした。リフレッシュをしにキャンプに行くわけですから、これは本当に用意して良かったなあと毎回思います。

少し失敗だったと思ったのはダウンシュラフは冬に結露で表面が濡れると残念なことになるというところで、ここは今後シュラフカバーを用意するなり、現状応急措置としてやっている毛布の外掛けを続けるなりしようと思います。

バーナー

キャンプを始めようと思い立って調べるまでは焚き火台で調理をするのがメインだと思っていましたが、よくよく調べてみたら焚き火は火力を安定するまでに時間がかかるし、火力の安定も難しいのでバーナーが必要と知り、なるほどなと思いました。で、以前花見などで鍋をしたときに普通のカセットコンロでは難しかったことを思い出して調べてみると、やはりキャンプ用のバーナーは違いますね。ちゃんと風防があって感心しました。

ユニフレーム ツインバーナーUS-1900 610305

ユニフレーム ツインバーナーUS-1900 610305

  • UNIFLAME(ユニフレーム)
Amazon

で、このツインバーナーを買ったわけですが、いまのところ安定して使えていて、かつ専用キッチンスタンドを使っても使わなくても、いい感じに調理しやすいので大変重宝しています。もはや逆に焚き火がおまけでこのバーナーがあるだけでキャンプが成立する気すらします。ステンレスで汚れを落としやすいのもいいですね。

椅子

自分は体格が大きいため、背もたれでちゃんと頭まで支えられるものがなかなかなく、かつ色や座面の素材感が好きだったのがコールマンのレイチェアしかなかったので、まずはこれを購入しました。

コールマン(Coleman) チェア レイチェア オリーブ 約3.7kg 2000033808

コールマン(Coleman) チェア レイチェア オリーブ 約3.7kg 2000033808

  • コールマン(Coleman)
Amazon

はじめは持っていたヘリノックスのチェアワンを使っていたのですが、自分はこの背もたれでずっと過ごすのは姿勢が厳しいなと感じたので、背もたれ付きを買いました。またチェアワンは出先でちょっとだけ座りたいという用途ではよかったのですが、長時間座るときに軽量すぎて安定感に欠けるなと思ったのも理由でした。

小物

次は別になくてもまったく問題なく過ごせるけど、あってとても便利だった小物です。これらは主に100円ショップや雑貨店で買ったものがメインです。

鍋敷き（兼焚き火テーブル）

IKEAの鍋敷きです。焚き火台で調理したてのコンボクッカーとバーナーで調理したスープをそのまますぐにテーブルの上に置く、といったことができるようになります。雑に熱いものをテーブルに置けるのは思いの外便利ですよ！

www.ikea.com

しかもこの鍋敷きはステンレス製である程度強度があるので、これと鍛造ペグを組み合わせて簡易的な焚き火テーブルを作ることも可能です。

https://camp-quests.com/wp-content/uploads/2020/04/%E3%82%BD%E3%83%AA%E3%82%B9%E3%83%863.jpg （画像はこちらより引用）

他にも灯油ストーブの上に五徳代わりに置いたりするなど、雑に便利に使っています。

ゴミ箱

ゴミ箱代わりに使っているのが、100円ショップで買ったランドリーバッグです。

ランドリーバッグjp.daisonet.com

普段は薄く畳んでしまっておけますし、キャンプ場に付いたらこれをぱっと広げて中にゴミ袋を入れるだけですぐにゴミ箱になってくれます。また白いメッシュも意外と中のゴミを目隠ししてくれます。これを色違いで持っていて、ゴミの分別をしています。一目でわかるので、非常に便利です！

ランタン

キャンプと言えばランタンですが、ガスランタンや灯油ランタンは危なかったり手入れが大変なので、まずは便利に使えることを重視して次のようなLEDランタンを複数用意しました。

MOTTERU (モッテル) LEDランタン モバイルバッテリー USB充電式 6,700mAh 防水 防塵 IP65 9パターンの色モード マグネット PSE認証済 日本メーカー エアリーホワイト MOT-MBLED6701-WH

MOTTERU (モッテル) LEDランタン モバイルバッテリー USB充電式 6,700mAh 防水 防塵 IP65 9パターンの色モード マグネット PSE認証済 日本メーカー エアリーホワイト MOT-MBLED6701-WH

Amazon

高いLEDランタンはより明るいものもありますが、キャンプであまりに明るいLEDランタンは興ざめになるのと、広い範囲で程よく明るいほうが諸々便利という話を聞いたので、このランタンを4つ持っていっています。それが大正解でほんのり広い範囲が明るくなり、サイトの雰囲気はいいまま、物が暗くて見えないということがなく、夜でも便利に過ごせています。このランタンの場合、明るさが弱なら冬で2晩使っても持つので、とても重宝しています。

ランプ掛け（キャンピング用）jp.daisonet.com

ところでランタンハンガーがダイソーに売っているので、これでポールにもランタンが設置できます。本当に100円ショップのキャンプ道具の充実具合は素晴らしいですね。

スキレット

なぜかキャンプ道具が豊富な100円ショップ界隈ですが、調理器具周りも豊富で、たとえばスキレットもあります。

スキレット Ｍjp.daisonet.com

アヒージョや目玉焼きなど、ちょっとした調理をするのにちょうどよいサイズで、何より安いのが最高です！スキレット以外にもメスティンやフォーク、スプーンなど、100円ショップで揃えられる調理器具がたくさんあるのは本当に助かっています。

おわりに

キャンプ好きな人と話をすると、すぐキャンプ道具の話になるのですが、はじめてみてその理由がようやくわかるようになりました。キャンプサイトはただの空き地なので、そこに自分が持っていった道具でそこでの数日間をいかに快適にするか、という工夫が必要になります。その工夫を助けてくれるのがキャンプ道具であるからこそ、キャンパーは常に道具に関心があるのだなと、実感しています。今日挙げたものよりさらに便利な道具などがあればぜひおしえてもらいたいです。例えば最近関心があるのは使いやすいキャンプ用の包丁です。

わざわざ不便なところに不便な生活をしにいく、という自己矛盾がある趣味だとは思いますが、空き地から快適な空間を作り上げるというプロセスは、日々無意識に享受している便利さを実感できる良い機会となっています。キャンプを終えて家に帰ってくると、ふかふかの布団やベッド、温かくて気持ちの良いお風呂、気温を気にすることなく物を冷やせる冷蔵庫、安定して強力な火力を保てるガスコンロ、夜でも明るく過ごせる蛍光灯、などそれらすべてが便利に感じられます。

まだこれから色々なキャンプ場で様々なトラブルを経験することになると思いますが、長く不便を楽しんでいこうと思います。

明日は世界の山下さん（@pyama86）です。

「SREの探求」という本が出版されました #seekingsre

SRE Book

はじめに

こんにちは、Cloud Operations担当者です。このたび私が監訳者として関わった「SREの探求―様々な企業におけるサイトリライアビリティエンジニアリングの導入と実践」という本がオライリー・ジャパン社より出版されました。本日より書店ならびに各社オンラインストアでご購入いただけます。

SREの探求 ―様々な企業におけるサイトリライアビリティエンジニアリングの導入と実践

SREの探求 ―様々な企業におけるサイトリライアビリティエンジニアリングの導入と実践

Amazon

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

www.oreilly.co.jp

TL;DR

「SREの探求」はGoogle以外の企業でSREの導入がどのように行われているのかを記したエッセイ集です。スタートアップからエンタープライズまで、多くの事例を楽しみながら読める一冊だと思います。ボリュームに圧倒されるかもしれませんが、短編集なのでどの章からでも気軽に読み始められます。ぜひご一読ください。

「SREの探求」のおすすめの読み方

SRE本と同様、非常に分量がある書籍になっていますので圧倒されがちですが、本書は一つの技術に関しての入門やハンズオンを行う類の書籍ではありません。本書の執筆に参加した各社のSREが自らの経験を語ったエッセイ集です。したがって、まずは面白そうだと思う章を読んでみる、というのが良いかと思います。どの章から読んでも構わないと思いますし、読む順番も順不同で構わないと思います。一応、下記にあるように、大まかに4部構成になっていて、各部にある章は関連性が高いものになっているので、読む対象を選ぶときの参考になると思います。

本書を読むに当たって、副読本として同じくオライリーより出版されている「SRE サイトリライアビリティエンジニアリング（以下、SRE本）」が手元にあるとより読みやすいかもしれません。もちろんすでにSRE本を読まれていて内容をある程度把握されている方は必要ないと思いますが、他のSRE関連書籍を読んだことがない、という方は各章に登場するSRE関連用語がわからない可能性があります。Google SREのサイトで原著を無料で閲覧可能になっていますが、日本語の資料があったほうが読みやすいという方はぜひご用意ください。

「SREの探求」はどのような本か

本書はDavid N. Blank-Edelmanが編集し2018年9月に出版された "Seeking SRE" の日本語訳書籍です。

Seeking SRE: Conversations About Running Production Systems at Scale (English Edition)

Seeking SRE: Conversations About Running Production Systems at Scale (English Edition)

Amazon

この本は、すでに同じくオライリー・ジャパンより刊行されているSRE本、「サイトリライアビリティワークブック（以下、ワークブック）」「データベースリライアビリティエンジニアリング」に続くSRE関連日本語訳書籍の第4弾となります。

SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム

SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム

Amazon

サイトリライアビリティワークブック ―SREの実践方法

サイトリライアビリティワークブック ―SREの実践方法

Amazon

データベースリライアビリティエンジニアリング ―回復力のあるデータベースシステムの設計と運用

データベースリライアビリティエンジニアリング ―回復力のあるデータベースシステムの設計と運用

Amazon

本書は、GoogleだけでなくSREを実践している（しようとしている）多くの企業がその経験を様々な観点から語り、それらを4部に分けて編纂したエッセイ集です。私はこれまで、業務上あるいはコミュニティ関連のイベント等で多くのエンジニアや経営層の皆様と関わる中で、SRE（サイトリライアビリティエンジニアリング）の導入について質問をいただいたときに私が社内のSREの方々から学んだ知見を共有してきました。多くの方々が異口同音にその価値に共感しつつも、その実践となるとハードルがあり、難しいと感じている様子を目にしてきました。

私自身は他社へSREの導入の支援を直接行ったことはない*1ので、実際に各社がどのように導入を行ってきたかは各社の公開情報を断片的に集めてきて学んできました。そうした公開情報はブログ記事であったり、カンファレンスの録画やスライドだったりするのですが、まとまった形で参照できる書籍は本書が出るまでは存在しませんでした。私が2018年にGoogle Cloudのチームへ異動しオブザーバビリティの担当をすることになってからそうした情報を活発に調べるようになったのですが、ちょうど異動した直後に本書が発刊され、これは福音と手に取ったのでした。目次に並ぶ社名を見たあと、実際に各社がSREの導入を試行錯誤した様子を見て、共感をするとともに、苦労が偲ばれました。SREの導入には銀の弾丸は無いと改めて確認するとともに、Google以外でももちろんSREは実践できるのだと、あらためて確信できようになる、そんな一冊でした。

第1部はよく耳にする「SREの導入」についてです。たとえば第6章や第7章ではSoundCloud社がProdEngチームを組織するにいたるまでの経緯、そしてSpotifyでのOps-in-Squadsの内容が詳細に語られていますが、その経験は多くの企業、特にスタートアップ企業に当てはまるのではないかと思います。彼らは専任のSREチームなしでSREを実践してきているわけですが、この例はまさに「SREというタイトルやチームがSREを実践する」ということではなく、会社全体としてその実践を行うことが大事であるということが伺いしれます。また逆に第8章や第10章では大企業でのSREの導入について語られています。これらの章は想像通り鮮やかな解決方法などはありません。特に大企業で発生する組織の問題をどう乗り越えていくのか、という点について生々しい経験を見ることができます。

第2部は「SRE本」や「ワークブック」で触れきれなかったSRE関連の各種手法についての紹介です。カオスエンジニアリング、セキュリティ、データベースリライアビリティなど、「SRE本」「ワークブック」以降に出版された各種書籍につながる内容になっているので、まずはここで概要を抑えてから、必要に応じてそれぞれをテーマとした専門書籍を読むと読みやすいことと思います。*2

第3部はSREにおけるソフトスキルとアーキテクチャーの紹介をしています。個人的には重要なソフトスキルであるドキュメントに関する19章は技術書の中ではなかなか語られないドキュメントの重要性を知れる章です。また23章のアンチパターン集も軽快に読め、気晴らしに読むにはもってこいの章です。

第4部は見過ごしてはならない文化的な側面です。SREに寄った文章にはなっていますが、SREのみならず組織全般に言えるような文化的側面についての考察が広くカバーされています。心理的安全性やバーンアウト（燃え尽き）、はてはソーシャルアクティビズムとの関連性など、広く「人間の組織活動」における懸念事項などを深く突っ込んでいます。心理的にネガティブになるような事象はできる限り起きてほしくないのは常だと思いますし、なかなかソーシャルアクティビズムについてこの文脈で書かれた文章は少ないと思うので、そうした経験を書籍で知れることは意義があると感じます。重い話もありますが、おすすめです。

読んでいただければわかるとおり、どの章も「正解」というわけではなく、現組織が試行錯誤の末にたどり着いた最適解であるということがわかります。それと同時にどの章においてもSRE本やワークブックで何度も語られているような、ユーザーに対する信頼性を獲得するための手法や組織作りを行うことに尽力していることが読み取れると思います。こうした経験の共有が読者の皆さまのヒントになることを期待してやみません。

謝辞

監訳者まえがきでも触れさせていただきましたが、あらためて編集者のオライリー・ジャパンの高恵子さん、翻訳者の渡邉了介さんに感謝いたします。

高さんには全体の進行をしっかりと管理いただき、また私と渡邉さんのコミュニケーションが円滑になるように様々な配慮をいただきました。本書の翻訳原稿はすべて各章ごとにGoogle Docsでいただき、その上に私が「提案」の形でコメントを追加し、それを渡邉さんに再度確認してもらい、良ければ承認、認識のズレがある場合には追加でコメントをいただくという形のワークフローを用意していただきました。会社で日常的にこの形式でドキュメントのレビューを行っているため、私としては大変進めやすかったです。

翻訳者の渡邉さんにはただただ感謝するばかりです。600ページ超の本、しかもエッセイが中心でコードや図表が少なく、かつ技術要素が多い書籍の翻訳を、入念な下調べとともにすばらしい品質で行っていただきました。おかげで私が監修する際にはどこに着目すればよいかが分かりやすく、私の負担が大きく軽減されました。また英語そのもののニュアンスが読み取りづらかった文章も文化的背景から調べていただいた上でいくつかの訳の候補を提案いただいたりと、多くの配慮をいただきました。結局コロナ禍にあって、プロジェクト進行中は直接お会いすることは叶わず、またスケジュールの都合等でビデオ会議もできなかった中で、これほどまでスムーズに共同作業ができたのは、渡邉さんの柔軟性と配慮のおかげだと思います。またこうした機会がいただけるのであれば、ぜひご一緒させていただきたいです。

読者の感想など

レビューエントリー

（更新予定）私の方で確認次第随時追加していきます

blog.hiroakis.net

note.com

e34.fm #7で取り上げていただきました！1:04:00頃から @deeeet さん、@rrreeeyyy さんの注目の章の紹介があります。

e34.fm

speakerdeck.com

ツイート

その他

良い香りがするそうです。

しない場合もあります

*1:ところで、Google CloudではCREやPSOといった組織がSREの導入支援を行っていますので、ご興味あればご連絡ください。

*2:セキュリティに関してはBuilding Secure & Reliable Systemsがありますし、データベースリライアビリティについては先に上げた書籍があります。