Workflowy というアウトライナー（階層型メモアプリ）を長らく愛用しているものの、メモを書き入れるときのスピードと柔軟性に欠けるなあ、という気持ちが常々あり、非公式APIを利用した send-to-workflowy を使ったりしていたのだが、昨年（2025年）から 公式でもAPIが登場した ので、Jotflowyという自分のためだけのアプリを作ってみた。

実装としては Hono とCloudflare Workersを使っている。Worker側では、ほぼWorkflowy APIとの中継部分だけを担当しており、データの保存などは特に行っておらず、ほぼフロント側に寄せている。APIキーは初回セットアップの際にWorker側で暗号化を施し、その後はCookieを通じて暗号化されたキーをやり取りするようにしている。こういった仕組みなので、誰にでもオープンな形で使ってもらうことは想定しておらず、使いたい場合にはセルフホストを推奨としている。変な使い方をしなければ、Cloudflareの無料枠範囲内で動かせるようになっている。

機能について

基本的にはsend-to-workflowyを始めとしたこの手のツールでよくあるような、メモを送信すると、ある階層（Node）の配下に新たなNodeを作成する、という挙動をするが、もろもろ自分好みの機能を詰め込んでいる。

送信先のNodeはインタラクティブに選択できる

APIでメモを送る（Nodeを作る）ときには、どのNodeの配下に送るか、送信先NodeのIDが必要になるのだが、このアプリではNodeの一覧をUI上で表示して、どこを送信先として指定するかインタラクティブに選べるようにした。類似のツールだと、ソースコードを覗いたりしてIDを自ら調べて持ってこなければならないものが多く、それはちょっと面倒だったのと、せっかく List Nodes APIがあるので使うことにした。

送信先Nodeは複数の場所をJotflowy上に保存しておいて、メモを送信するときにどのNodeへ送信するか都度選べるようにもしている。

デイリーノートの自動作成

送信先Nodeを保存する際、デイリーノートとして扱うかどうかを選べるようにしている。この機能をonにすると、当該Node配下にその日の日付のNodeを作り（すでに存在する場合はそれを使う）、その下にメモを送信するようになる。

送信先Node
 └ New node # <-- 普通はここに送られるが

送信先Node
 └ 2026-02-15
    └ New node # <-- デイリーノート機能をonにすると、ここに送られる

なお、Workflowyには Calendar という、デイリーノート機能がすでに備わっており、アプリで「Today」ボタンを押すと指定したNode配下に自動でその日の日付が作られるようになっている。一応、これと連動を取るように実装していて、Calendarとして使っているNodeを送信先として指定すると、アプリ側で作る日付Nodeとバッティングせず共存ができるようになっている。ただし、Calendar配下に日付Nodeを直接作成するよう設定されている場合に限る（Calendarでは年月日の階層を作ることも可能だが、階層がある場合には非対応）、Jotflowyから新しい日付Nodeを作成した際は、Calendarに取り込むにあたってWorkflowy上で一手間必要（Calendar - Workflowy support）、といった制約はある。

PWAとWeb Share Target APIへの対応

PWAとしてインストールし、スタンドアローンなアプリとして使える。

PWA化した大きな理由に Web Share Target API に対応させたかった点がある。これに対応することで、いわゆる他のアプリから「共有」する操作の対象になることができる。ブラウザでウェブページを読んでいるときに、そのページについてメモしたい、といった場面が結構多いので、これは個人的にmustだった。

送信したメモの「履歴」が見られる

「履歴」が見られる……と書いたが正確には履歴ではなくて、送信先として選んでいるNodeに対して List Nodes APIを実行して、直下にあるNodeの一覧を取得、表示できるようになっている。その時点でのWorkflowy上の最新状態を取得するから、送信後に別途削除、変更したNodeは見られないわけで、正確には「履歴」ではない。

デイリーノート機能を有効にしている送信先の場合は、日付ごとに区切った形でメモが表示されるようにもなっている。深く考えずに作ったが、このUIがわりとTwitterのような感じがあって見やすくて良いな、と思ったりしている。

その他の機能

他にも細々とした機能を備えている。

• URLを送信した際はtitleの自動取得が行われ、リンク形式で記述される
• template機能を使って特定文字列を常に付与できる
  • 例えば現在時刻を埋め込むようなtemplateを設定して、「起床」と送るとWorkflowyには「07:02 - 起床」と書き込まれる、みたいな感じ
• 空行を間に挟んだメモを送ると、空行以降はWorkflowyのNoteとして扱われる

コーディングにはClaude Codeをかなり活用しており、こういう自分のための開発をやりやすくなったなぁ、と実感する良い機会だった。実は昨年の夏ぐらいに一度何日かかけて作ったことがあったのだが、当時はなかなか思い通りにいかない部分があり、頓挫していた。やり直したい気持ちはずっとあったので、軽い気持ちでOpus 4.6を使ってゼロから作り直したところ、粗削りではあるものの、1日でそれなりに動くものが出来てちょっと驚いている。AIの進歩もあると思うし、最初の構築を通じて要件が固められたのもあると思う。

余談：Workflowyと自分がメモに求めること

ここからはWorkflowyとメモというものに関して、自分がどういった考え方をしていてこのアプリを作るに至ったかを書く、完全なる蛇足。

send-to-workflowyのほかにも MemoFlowy など、「Workflowyに手早くメモを送る」という需要は自分だけが持っていたものではなく、従来から結構広く存在していると認識しているのだが、だいたい以下の2点が理由だと思っている。

• Workflowyのモバイルアプリは起動に数秒かかる
• 起動した後で、メモしたいNodeへ移動するのにもちょっと手間がある

近年このあたりは解消しつつあって、起動時間については1秒以下に収まるようになってきた。また「手早くメモを送る」という用途に対しても、そのための Quick Add という機能がAndroid版に搭載された（iOS版は把握していないが、おそらく未リリース）。

そういった状況ではあるのだが、今回のアプリに搭載したような細かなカスタマイズをやりたかったのと、メモをしたためるときには、ある程度の没入感を持てるUIが欲しいのもあり、自分で独自に作るに至った。

メモを書くことと読むことを切り離したいという欲求が自分にはある。Workflowyの画面で過去に書いたメモがたくさん並んでいるところに、追記するように新たなメモを書くよりも、まっさらな画面で没入して書いて投げ込みたいという気持ちが強い。書くときに、まったく関係ない別の言葉が並んでいるとどうにも気が削がれてしまうところがある。なので集中して何かを書きたいときは、ポメラで新しいファイルを作ったり、macOSでは stone という、集中して書くことに特化したアプリを立ち上げることが多い。これはもう完全に自分の性分だと思う。ただ、一度書いたあとのメモを過去のメモと組み合わせながら考えを進めるのは好きなので、Workflowyというアプリ自体は性に合っている。思いついたときに付箋を1枚剥がしてメモを書いておいて、あとで書いた付箋を集めて全部机の上に並べてこね繰り回すような、そういう感覚に近いものを求めているのだと思う。

そういった個人の、言うなればどうでもいいようなこだわりをスッと形にできるのは非常に体験がいい。AIによるCodingが全盛となっていくタイミングで、Workflowyが十数年来初めてAPIの公開に踏み切った、というのもとても良いタイミングでありがたかった。

つらつらと思いつくまま書いているので長いし、何かの役に立つみたいな内容ではないです。あと、話の展開上チームやらマネジメントやらという言葉が出てきますが、ここは個人ブログなので、あくまで個人としての見解です。

現時点でのAI利用状況

• 正直、エンジニアリング業よりマネージャー業の方が割合高いので、コーディングエージェントをバリバリ使えているとは言い難い
  • ただ、マネージャー業にコーディングエージェントを使ったりもしている
  • 昨年からSREとして副業を始めてもおり、そちらでエンジニアリング機会も得たりはしている
  • エンジニアリングで意識的に使わないとマズいなという感覚がヒシヒシとある
• 主に使っているのはClaude CodeとGemini
• Claude Codeがメイン
  • 法人契約のものと、副業等のために個人契約のProの2つを持っている
  • コーディング用途でもマネージャー業でもほぼこれを使っている
  • CLIでの利用がほとんどなのだが、Claude Code Webやin Excelなども興味はあるし活用できたらしていきたい
    • WebはDevinのように複数人で共有するような使い方やSlackとのIntegrationが充実してくると良いのだが……
• Geminiがサブ
  • 家族で使いたいこともあり、Google AI Proを契約して家族共有で使っている
  • 単純にチャットでAIと話したいときはGeminiを使うことが多いが、特に大きな理由はない
    • Claudeと双方に同じ話題を投げることもあるが、どちらかと言えばGeminiのほうがちょっとお節介で求めてないことまでやろうとする印象はある
  • あとはNotebookLMはだいぶ活用している
  • Gemini CLIはGoogle CloudのCloud Shellでだけ使っているけど、あれは超便利
• その他
  • ChatGPTはPay as you goで使っている
    • Readwise Reader（RSSリーダー）で記事の自動翻訳などをするのにAIのAPIキーを使いたいのだが、ChatGPTにしか対応していないので
  • 先月ぐらいからOpenCodeも触り始めているが、まだ全然
    • ツールとLLMのモデルが密結合しない方向性は歓迎したいので、そういったツールが出ては目配せしてはいる
  • 他、Cursor、Roo、Aider、Devinなど使ってきたがいずれも触らなくなってしまった

SREのコーディング作業とAIによる効率化

• いわゆるプログラミング言語を書くのに比べると、コーディングエージェントからSREが受けられる恩恵は限定的じゃない？みたいな気持ちが少しある
  • 例えばTerraformに関して言えば
    • HCL（Terraform）はGitHub上のレポジトリ数がPythonやTypeScriptなどと比べて圧倒的に少なく、AIの学習はそれら言語よりは進んでいない
    • IaCのように宣言的な記述においては、アルゴリズムを書くときのような複雑性や課題内在性負荷は生じづらい
    • HCLの書き方、対象パブリッククラウドの知識、Terraform providerの知識、社内のドメイン知識と多方面に整合せねばならない上、テスト駆動なども発達していないので、手戻りは多くなる感覚がある
    • ここまでに書いた内容はKubernetes manifestなどでも同様に当てはまると思うが、いずれにせよ仮説でありちゃんと検証したわけではないし、そういった調査結果なども見つけられてはいない
• 一方では信頼性改善のためにアプリケーション側のコードを読み、当たりをつける、といった作業では抜群に役立つ
  • SREは職能やプロダクトを越境して行く役割が強いので、こういう恩恵は大きい
  • 逆も然りで他職能の方がSREing的なことをするときにも役立つわけで、 Friction を取り除くという方向性で考えていくと良さそうに思っている
• 副次的な効果としては、AI向けのナレッジを整備するなかでチーム内で形式知化が進むよね、というのもある
• 結局のところ、よく言われる「ボトルネックが移動した」感覚であり、これまでとは時間と労力をかける対象が変わった、のが現状かなぁ、と思っている
  • The SRE Report 2025 | Highlighting Critical Reliability Trends のように、AI活用が進んでもトイルは減っていないという調査結果も読んだけど、これはもう少し長期で調査結果が出てこないと判断が難しい

マルチタスク前提の時代になってしまった

• シングルタスクに集中して如何にフローに入るか？というのが個人の生産効率の上ではベストだったはずなのに、気付けばみんな git worktree で並列開発している
• この方向性が正しいのかよくわからないけれど、今のところ「そりゃこうなるよな」という感覚ではある
• マルチタスクを前提として
  • 自分のタスクをもっと細切れに分解していかなければならない
  • あるタスクに集中するのではなく、一歩引いたところから複数のタスクを俯瞰するような形へ転換しなきゃな〜〜というマインドチェンジには結構苦労している
  • 一方で「これで本当に幸せか？」ってのも考えたいんだけど、それは哲学とかの仕事かもしれない

AIの活用と信頼性制御

• AIを「使う」のではなく、自社内でAIが「使われている」場面に対してもSREの関心というのがあり
• 1つはプロダクトに組み込まれて使われる場面
  • AIが介在する機能は、そうではない機能に比べてレイテンシに対するユーザーの期待値が下がっているはずで、信頼性の考え方も変わってくる
  • ここの信頼性をどう捉えて扱って行くのかは結構難題ではと思っているけれど、まだ案外そういう話をそこまで見かけない気がしている
• もう1つは開発用途で使われる場面
  • こちらはどちらかと言えば信頼性というよりはセキュリティとコンプライアンスの関心だと思うし、すでにいろいろな方が書いているので割愛

AIを前提として組織も職能も変化していく

• 先述したように、AIが職能やチーム間のFrictionを排除する方向へ促すのであれば、組織の構成や職種の考え方も変化するはずでは、というのが多分今一番の関心
• 例えばインシデント発生の際にトリアージを行うAI Agentを作るとして、そこにはSRE、セキュリティ、あるいは品質など様々な観点からナレッジを詰め込む必要がある
  • 各職能チームが独自にEnablingをやるのではなく、互いに連携しながら業務フロー全体のFrictionをどう抑えて行くか？と考える必要が以前より増してきているのではないか
• チームトポロジーも考え方変わりません？って思っている
  • Enablingを直接人間に対して行うんじゃなくて、Agent Skillsを充実させたほうがいいよね、とか
    • 完全にEnablingが不要になるという話ではなく、ストリームアラインドチームが機能するのに必ずしも「チームとして」能力を持つ必要がなくなってくるよね、という話
• 個々の開発者が自らの業務をAIに支援させる、というCopilot的な方向から、ある業務全体をAIが丸ごと担って複数人と協業するAgenticな方向へ変わって行くはず
  • そういう世界観になったとき、現在の職能や組織構成はそのまま通用するのか？
  • 広くワークフローを見渡してドラスティックに手を入れて行く考え方が必要ではないか
• 一方でこういった動きは専門職の消失を意味するわけではない、とも思う
  • パブリッククラウドが隆盛したときに「インフラエンジニアは死ぬ」と散々言われたが結局死ななかったように、隠蔽・抽象化された領域に対する専門性が、エンジニア組織から完全に不要となるわけではない
  • Agent Skillsが日常的な業務は代替してくれるとして、Skillsをメンテナンスする専門職は結局要る
  • 騒がれているほどには「AIが職を奪う」とは考えていないのだけど、これは自分がマネジメントに軸足を移している故という可能性もある

今年はどうしようか

• LLMのことをもっと理解しないといけないなと思うので、今年はそのあたりをインプットのメインにしたい
  • せっかく通信制大学で基礎的な数学やAIの講義も受けたので、このあたりの知識が揮発しきらないうちに積み重ねを進めたい
  • トレンドとしてすぐ廃れるようなものとは思えないし、原理を知識として押さえたほうが長期的な利が大きそう
• AIを業務と組織の中心に置けるようにしていきたい
  • 価値提供の高速化と安定のために必要な活動は変化してきている
  • AIでやれないか、AIをどう組み込むかを大前提として考えていかないとなかなか変化を起こせないなぁ、とこの1年を通して思っている
  • 自分自身の業務に対してやれることもあるし、マネージャーとしてやれることもまだまだある

効率的なメール処理を目指したクライアントアプリは他にもあるが、Notion MailのUI/UXは比較的独自性が強く感じる。そのわりに 公式Help を見ても個々の機能説明しかなく、どういった使い方をすると便利なのか、設計思想やワークフローが見えてこないので、何か良さそうな空気を覚えつつも、使いこなすまでに時間がかかるツールだと思っている。

Notion Mailの実践について書いた記事も他に見かけないので、自分なりの解を書いてみる。端的に言えば、Notion MailはInbox Zero（受信トレイのメールをトリアージして適宜分類し、受信トレイにメールがゼロの状態を保つ運用）を念頭に、以下のようなワークフローを想定したツールだと思う。

• AIを使って自動ラベル付与を行い、メールを効率的に分類、トリアージする
• 付与したラベルなどを使ってフィルタ条件を作成し、受信トレイには本当に見るべきメールだけを表示する（その他、必要に応じてViewを追加する）
• 日々の運用では受信トレイを中心にメールを処理し、Actionが必要なものはPriorityを付与して管理する

AIによる自動ラベル付与

Notion Mailの売りのひとつがこれだと思うのだが、最初に断っておくと筆者は活用していない。いくつかのメールを選択してNotion AIに依頼すると、それらのメールと類似したメールを次から自動的に仕分けてラベル付与を行ってくれるという、いまどきのLLMになら確かに任せられそうな機能だ。

活用していない理由としては、AIによる分類は確実性が保証できないからだ。誤った分類が行われて、それによってメールの見逃しが発生する事態は避けたい。Gmailのオートフィルタは管理や編集が面倒なものではあるが、確実性を重視してオートフィルタによるラベル付与を採用している。また、Notionでできるのはあくまでラベル付与のみであり、Gmailのような「ラベル付与 and 既読にする」といった自動処理はできない。

逆に「ざっくり分類できればOK」「Gmailのオートフィルタ条件を書くのが嫌い」といった理由があれば、AI auto labelは使える機能だと思う。何度か実験はしてみたが、それなりに精度はありそうだった。

本当に必要なメールだけを確認するようViewを分ける

Notion MailとGmailで体験が大きく異なる点の1つが、このViewの機能だと思う。

Gmailでメールを表示する画面は、例えば「受信トレイ」であれば「アーカイブされていないメールを表示する」といった条件が決まっており、カスタマイズ性が高くない。 マルチ受信トレイ を使えば、検索条件に基づいた追加受信トレイを作成できるが、作成できる受信トレイは5個までだったり、各受信トレイは並べて表示するしかできない、といった制約がある。

Notion Mailでは、任意の検索条件（From、To、添付ファイルの有無、ラベルの複数条件や除外条件、などなど）でメールを表示するViewを好きに追加できる。そして受信トレイもViewの1つであり、デフォルトではGmailと同様に未アーカイブのメールを表示するのだが、この条件を変更できる。

Notion Mailのキーになるのはここだと考えている。受信トレイには、優先度高く処理が必要なメールだけを表示するよう設定し、そうではないメールはViewを分けて後で処理したできるようにすることで、効率化を図ることができる。先述のAIによる自動ラベル機能でも、ラベルを作るときに「このラベルは受信トレイに残すか？　それとも除外するか？」というモーダルが表示される。つまりはAIによってメールを受信トレイに残すか残さないか、最初のトリアージを任せるのがNotion Mailだと捉えている。

Gmailでもオートフィルタを使えば受信トレイのスキップが可能だが、スキップさせるということは「アーカイブする」ことと同義だった。Notion Mailではアーカイブしないままに受信トレイから除外できるようになるので、重要度の高い、すぐ読むべきものだけを受信トレイに残し、時間をおいて読んでもよいようなものは別のViewへと分けるといったことが可能になる。

筆者の場合、カレンダー関連のメールと、Gmailの「プロモーション」カテゴリに分類されるメール（＝企業からのメーリングリストや広告）は受信トレイから除外している。いずれも緊急性は高くないが、出欠確認、情報収集、不要ならUnsubscribeといった処理は必要になるので、別のViewから確認している。

Priorityを活用してNext Actionを明確にする

メールを仕分ける際には、Notion Mail独自のプロパティ（チェックボックスや任意のテキストなど）も付与できる。Gmailにはない機能をあまり多用したくはないのだが、「Priority」については実態がGmailラベルだと言うこともあり、これを活用して分類を行っている。

Priorityはデフォルトだと「To-do」「Important」「Waiting」と言った値が用意されており、優先度と言うよりはメールの状態を表すものに近い。こういった用途では、Gmailだとスターやマルチスターを使っていたところだが、Priorityでは文字が書けるので、「返信が必要」「アクションが必要（EOL通知のような）」など、直接的にNext Actionがわかりやすくなり、重宝している。ラベルの一形態に過ぎないと言えばそうなのだが、Priorityはインジケータのように目立つ形で表示されるので、視認性も高くなる。

Priorityの正体はラベルだが自動付与はできない

Priorityの正体はGmailのラベルである。Priorityを付与したメールをGmail側で開くと、 [Notion]/Priority-xxxx というラベルが付いているのがわかる。

ならばGmail側のオートフィルタを使って、自動的にPriority付与ができるのではないか、と考えるところだが、なぜかこれはできない。オートフィルタで付与したPriorityラベルは、Notion Mail側で認識してくれない。手動で付与した場合はNotion Mailにも反映されるので、このあたりの挙動はやや謎が残る。

まぁ自動識別するより、自身でPriorityを付与するほうが意識の上にものぼりやすいので、そこまで困っているほどでもない。

StatusとPriority

なお、Priorityと似たようなプロパティとしてStatusが存在する。両者の違いはほとんどないように思えるのだが、唯一「StatusはViewのグループ化に使えない」という点が異なる。

グループ化とは、あるViewの中でさらに何らかのプロパティを使ってメールをグルーピングして表示する機能である。筆者の場合はPriorityを付与したメールのみ表示したViewの中を、Priority別でグループに分けている。Statusはなぜかグルーピング条件として使えないので、採用を見送った。

雑多な受信トレイをやめて、視界をクリアに保つ

長々書いてしまったが、要は 「ラベリングによるトリアージをAIで効率化した上で、トリアージレベルなどに応じてViewを適宜分離して、大量のメールが来ても視界をクリアに保つ」 というのがNotion Mailなんだと思う。重要な取引先からのメールだけを集めたViewだとか、数多のクラウドサービスから来る通知メールだけのViewだとか、そういったものを気軽に作れるのがいい。

とはいえ、筆者の場合は人対人の連絡ではSlackが主ということもあり、メールの総量は多くない。ただ、それ故に油断して見逃すことも多かったので、よく来る管理職としての申請/承認系のメールや請求関連のものなどは専用のViewを作り、以前より見逃しは少なくなった。雑多なメールが押し込まれたGmailの受信トレイは、それだけで開く気が失せてしまうものでもあり、Viewを分けることで精神的な負荷も和らいだ気がしている。

最後に、そのほか細かなTipsを書いて終わりにする。まだ登場から1年も経っていないこともあり、今後の発展に期待している部分も大きい。

• ⌘ + k によるコマンドパレットからほとんどの操作（Viewの移動やメールに対する処理など）ができるので、ショートカットを覚えずともこれでなんとかなる。
• ショートカットも多くはGmailと同様のものがあり、流用できる。
• GUI上には動線がなく、 ⌘ + k やショートカットのみ表示できる画面がいくつかある。例えば「すべてのメール」。
• GmailにおけるStarは、Notion Mail上だとなぜか扱いが低く、ラベルの一種としてしか認識されない（☆マークとしては表示できない）。
• 不具合がいくらか見られる。
  • バルク処理に問題がある。Notion Mailで100通近いメールへの一括ラベル付与などを行っても、Gmailにうまく反映されない。
  • 一部のメールで改行が無視される。条件は把握できていない。

Firefoxは突然使い始めたわけではなく、サブブラウザとしてはずっと使っていた。 Multi-Account Contaienrs という、「コンテナ」という単位でセッションの分離ができる機能があり、AWSコンソールを複数のアカウントに同時ログインして使うのに便利だったのだ。他のブラウザでもマルチプロファイルを活用して似たことが可能だが、Firefoxにおけるコンテナは単一プロファイル内での分離なので、ウィンドウを分ける必要もないし、ブックマークや機能拡張などはコンテナ間で共有できるので、より扱いやすい。使い勝手としては、タブグループごとにセッションが分かれている感覚に近い。また機能面の理由以外だと、Chromium一強の状況があまり好ましくない、Mozillaを応援したいという気持ちもあった。

Firefoxがそれでも「サブブラウザ」扱いだったのは、Vivaldiに比べていくつかの機能が欠落していたからだが、最近改めて見てみると垂直タブやマルチプロファイル（ローリングリリースのため、筆者のFirefoxにはまだ実装されてはいない）など、欲しかった機能にも対応していたので、メインに足ると考えた。

僕がブラウザ自体に求める機能はそれほど多くなく、垂直タブ、マルチプロファイル、あとは次点でピクチャ・イン・ピクチャがほしい。垂直タブはややマイナーめの機能とは自覚しており、Firefoxがネイティブの機能として実装してくれるとは正直考えていなかった。ニッチな需要しかないのかと思っていたが、考えてみればVivaldiやArc、Braveのような比較的新しいブラウザのほか、最近ではEdgeも採用しているので、徐々に市民権を得ている機能なのかもしれない。タブを多量に開く場合には、視認性の面で自分にとってはほぼマストになっている。

余談だが、Firefoxの垂直タブはピン留めすると少し既視感のある外観になる。さすがにこれは意識して寄せている気がするのだが、そこを意識するんだなぁというのはちょっと面白い。

ネイティブな機能以外、つまり拡張機能としては「キーボードでブラウザを操作できる」ものを何より求めているが、Firefoxでは tridactyl を使っている。何年か前にも触ったことはあるが、そのときより数段使いやすくなった印象がある。この分野の拡張では、かつてFirefoxの Vimperator が代名詞に近い存在だったが、tridactylはかなり意識的にVimperatorの機能性を踏襲しており、使用感が似てきている。

この手の拡張は、何かの操作を行うコマンド（例えば引数に与えた数字n行分ページをスクロールする scrollline ）と、そのコマンドを実行するキーバインド（例えば j で scrollline 5 ）で主に構成され、好きなキーで好きなコマンドを実行できるよう、カスタマイズすることが肝になる。tridactylではVimperatorと同様、ローカルファイルに設定を書いてそれを読み込めるので、dotfileとして管理ができる。

https://github.com/chroju/dotfiles/blob/main/dotfiles/HOME/.config/tridactyl/tridactylrc

組み込みのコマンドのみならず、任意のJavaScriptにもキーバインドできるので、他の拡張を入れずともtridactylだけで多くのことがまかなえたりする。URLとタイトルを任意の形式でコピーする、みたいな小さな機能実装もできるし、最近機能拡張からは使えなくなってしまった、Google翻訳によるページ全体翻訳も再現が可能だ。以下の設定をすれば translate コマンドで翻訳が実行されるようになる。

alias translate js let googleTranslateCallback = document.createElement('script'); googleTranslateCallback.innerHTML = "function googleTranslateElementInit(){ new google.translate.TranslateElement(); }"; document.body.insertBefore(googleTranslateCallback, document.body.firstChild); let googleTranslateScript = document.createElement('script'); googleTranslateScript.charset="UTF-8"; googleTranslateScript.src = "https://translate.google.com/translate_a/element.js?cb=googleTranslateElementInit&tl=&sl=&hl="; document.body.insertBefore(googleTranslateScript, document.body.firstChild);

先述のコンテナ操作にもtridactylは対応しており、 tabopen -c CONTAINER_NAME https://example.com という形で、任意のコンテナ上でURLを開ける。特定のコンテナでよく開くURLがあるのなら、これにaliasやキーバインドを設定しておくと便利だ。

若干変わった機能としては、 サイドバー にURLを読み込み、通常のタブと横に並べて表示する機能がある。これを普通に使おうとすると、サイドバーの開閉を切り替える sidebartoggle コマンドと、サイドバーに任意のURLを読み込む sidebaropen コマンドが分かれていてやや不便なのだが、これもキーバインドで解決できる。

bind --mode=browser <C-g> jsua browser.sidebarAction.open(); tri.excmds.sidebaropen("https://gemini.google.com/")

このように設定すれば Ctrl + g でサイドバーにGeminiが開くようになる。また、現在タブで開いているURLを、サイドバーで開き直すというコマンドも別途実装しており、2つのページを見比べながら作業したいときによく使っている。Vivaldiだと、複数タブをタイルのように並べるタブタイリングという機能があってよく使っていたが、Firefoxにおいても、2ページ併存に限定されるとは言えだいたい似たようなことができている。

動作も安定しているし、UIもシンプルなデザインで、使用上困ることはほとんどない。機能拡張はFirefox非対応のものもあり、Vivaldiからすべてを移してくることはできなかったが、最小限の拡張で使っていくのも悪くないと思っている。ネックとしては、稀にFirefox完全非対応で表示すらできないサービスがあることぐらいだろうか。

2つ目の学位記をゲットした。それぞれ学士（社会学）と学士（工学）なのだが、どちらもやたらとスコープが広くないか。

ということで、2019年春に入学した、帝京大学理工学部の通信課程をこの春に卒業した。2年次編入だったので、最短3年で卒業できるところ、働きながらとはいえ6年かかってしまった。

単位修得状況

| 評価 | 2年次 | 3年次 | 4年次 | 5年次 | 6年次 | 7年次 | 合計 | | :--: | :---: | :---: | :---: | :---: | :---: | :---: | :--: | | S | 8 | 2 | 4 | 2 | 6 | 6 | 28 | | A | 12 | 8 | 6 | 8 | 8 | 0 | 42 | | B | 4 | 4 | 6 | 4 | 2 | 0 | 20 | | C | 0 | 4 | 0 | 0 | 0 | 0 | 4 | | 合計 | 24 | 18 | 16 | 14 | 16 | 6 | 94 |

これ以外に、帝京以前に卒業していた大学の単位を32単位持ち込んでおり、合計126単位。卒業必要単位124を少しオーバーした。最終年は4単位だけ取ればよく、9月卒業も可能だったが、どうせ同じ授業料を払っているのだからと1年間在籍した。結局的に追加で修得した単位の数は多くなかったものの、単位は取らずとも資料を眺めたりした科目はいくつかあり、これはこれでよかったとは思う。

働きながら大学に通う難しさ

6年、という期間は結構かかってしまったなぁとは思うが、これ以上早められた気もしない。これぐらいが限界だったんじゃないだろうか。

帝京大学通信課程のシステムは以下の通りになる。

• 単位の修得には、ごく一部科目を除いて「科目修得試験」合格が必要になる
• 「科目修得試験」を受験するには、レポート合格かウェブ学習システム（LMS）上での課題合格が必要になる
• 「科目修得試験」の受験機会は、年間にI〜IV期の4回がある
• IとIII、IIとIV期の試験時間割は原則的に同じであり、1科目につき年2回の受験機会がある（不合格後に再受験も可能）

つまり大学は4期制であり、1期あたりの学習期間はざっくり2〜3か月程度になることが多い。例えばI期は6月頭にレポート締め切り、7月頭に試験がある。4月頭から学習を始めるとして、レポート提出まで2か月程度しかなく、おまけに科目によってはレポートA、Bの2つ提出が必要かつ、Aの締め切りは6月頭ではなくさらに1か月ほど早く設定されていたりもする。1科目あたり全15回という授業回数を考慮しても、1期あたり2〜3科目進めるのが精々というところになる。

継続的な学習は習慣化してしまうのが一番で、自分の場合は毎朝1時間半か2時間ぐらいを学習に充てることにしていた。入学間もない頃は夜をあてていたが、仕事を終えてからでは集中力がもたず、2年目ぐらいから朝へ切り替えた。ちょうどリモートワークが一般化した頃だったので、起床→朝食→勉強から、ほぼシームレスに仕事へと移ることができ、朝の時間はだいぶ有効に活用できた。卒業後も、この時間は学習時間として継続している。

当然、習慣化したところで仕事由来のインプットが必要であればそちらを優先したりもするし、家庭やプライベートの都合で時間が取れなくなることもある。試験日は予備日があるわけではないので、別の予定に重なったり、体調不良で試験自体を受けられないこともあった。90単位近くを働きながら修得するという行程は非常に長くてプレッシャーでもあり、無理なのではないか、やめてもいいんじゃないかと考えたこともあったが、どうにか卒業まで辿り着けた。今はただただホッとしている。

大学を選んだ目的と効果

大学に入学した理由は、 入学時に書いたエントリー で、「車輪の再発明をしないための学びであり、車輪を適切に応用していくための学びをしたかった」と記している。文系出身なので計算機科学や数学の基礎を知らないことへの不安があったが、その点は一定解消できたとは思っている。

よく言われる話ではあるが、大学の知識というのはすぐ実践的に役立たつとは限らない。これは計算機科学に限った話でもない。だが、ふとしたときに理解を深めたり、異なる知識をつなぐきっかけになったりする。IPAの試験がIT系エンジニアの基礎として尊ばれているのと同じロジックだと思う。

とはいえ、いわゆる「コスパ」「タイパ」が良い勉強法ではまったくない。大学の学部というところは、卒業するのに一般教養の単位も必要になる（今回は「持ち込み」により新規修得はほぼしていないが）し、必ずしも興味ある分野だけを学べばいいものでもない。逆に言えば、こんな機会でもなければ電気通信法や電子回路を深く学ぶこともなかっただろうし、最終年では卒業に必要のない地理学や日本史（近現代）も学べて楽しかった。このように知見が広がるのは大学ならではだが、シンプルに計算機系の知識だけほしいとかであれば別の勉強法のほうがいいと思う。

副次的に身についたこと

短期間で多くの知識を覚える機会や、効率的かつ綺麗なアウトプットをする機会が増えたので、それまで使っていなかったさまざまなツールを駆使するきっかけにもなった。 社会人大学生1年目を終えて、大学生活と勉強法とその困難 - chroju.dev で書いたiPad Pro、Anki、Scrapbox、LaTeX、 帝京大学通信課程での社会人大学生3年目を終えて - chroju.dev に書いたテプラやGitHub Projectなどはいずれも卒業まで使い続けた。

他に追加で使ったものには、Wolfram|Alpha がある。数学を中心として、さまざまな問題を計算し、その過程を含めて表示してくれるサービスだが、大学の参考書には「過程」が載っていない場合も多く、重宝した。全機能をアンロックするには有償のProに登録する必要があるものの、学割でほぼ半額になる。

Generative AIについてはまさに在学中に出てきたのだが、あまり活用できないまま終えてしまった。レポートをまるごと生成するのは当然論外だが、NotebookLMや各種のDeepSearchなどは学習支援として相当に役立つはずだ。なお、帝京では「AI使用が全面禁止」といったことにはなっていなかったとは思うが、記憶が曖昧なので参考程度の情報としておいてほしい。

今後の「進学」について

今のところまったく考えていないが、修士にも興味はある。それが計算機関連になるのかはわからない。今働いている会社がMBA（経営学修士）の大学院を運営しており、自身もマネージャーを務めている関係から、そちら方面への興味もある。とはいえ一旦は休みたい気持ちが強いので、また気が向いたら考えようと思う。

逆に、新しく契約したものはない。

解約したもの

Amazon Prime (Student) / 年2,450円

今は年2,950円に値上げをしたようだが、契約を開始したときは2,450円だった。いずれでも通常のPrimeと比べると破格。

Prime Studentは学生向けということで、最大でも4年間しか契約できない。通信制大学が5年目に入ったため自動的に終了となった。通常のPrimeへ移行してもよかったのだが、Prime Videoを始めとしたAmazonのサービスをそこまで使っているわけでもなかったので、いっそ解約することにした。

ネット通販のメインはヨドバシ.comに移し、ヨドバシで手に入らない場合のみAmazonを併用したりしているが、今のところ困ってはいない。というかヨドバシの配達が速すぎてびっくりする。

O'Reilly Online Learning / 年$299

こちらも年$299というのはBlack Fridayで安くなっている場合の価格で、本来は$499となかなかの金額になる。以前はAssociation for Computing Machinery (ACM)に年$99払って会員になれば、O'Reillyも特典で付いているというハックがあって、その頃から利用しており、一時その特典が終了してしまってからもBlack Fridayを活用して利用を続けていた。現在は一部内容が変わりつつACMの特典が復活している。

単純に、今年1年あまり活用できていないため、一旦やめてみることにした。このサービスに関しては、よく「年会費に見合うだけの冊数を読める気がしない」という理由で躊躇する人を見かける。個人的には1冊読み通すことにあまり重きは置いていなくて、原著、邦訳含めてオライリーを始めとした数千冊の技術書を串刺しで検索してつまみ読みできる点が一番のメリットだと思っている。当然ながらググるより情報の質は良いし、図書館などに行くより効率的にザッピングして、複数の文献を比較できる。ただ、今年はそれすらあまりやらなかったので、Black Fridayの際に悩みはしたが契約はしなかった。今はACMを活用すればBlack Fridayより安く契約もできるので、本当に必要だと思ったら復帰もしやすい。

最近は日本語書籍も発売翌月には読めるようになるし、生成AIが本を探してきてくれる機能なども付いたので、解約はしたけど非常におすすめ。

IFTTT Pro+ / 年$149.99

複数のSaaSを連携した自動化タスク（Appletと呼ぶ）を簡単に作れる、IFTTTの有料プラン。Free、Pro、Pro+の3段階があり、中間のProだと一部機能が使えなかったり、全部で20 Appletsしか作れないといった制約があるのだが、いろいろ用途を絞ることでPro+からProへと移行した。

Pro+は如何せん高い。従来からの有料プランはLegacy Proという形で安価に残っていたのだが、これが 昨年Pro+に強制移行する形になってしまった。Proであれば$34.99で、それなりに値頃感がある。

週刊少年ジャンプ電子版 / 月980円

「釘崎野薔薇の生死が明言されるまで購読する」という縛りで契約していたが、その条件を満たしたため解約。

解約しようとしたができなかったもの

ATOK Passport / 月300円

ATOKの変換精度は好きなのだが、設定まわりがあまり好きになれなくて、買い切り型や無償のIMEで代替できるのではないかと、いろいろ試したもののATOKに戻ってきた。

ATOKは変換性能の高さも然ることながら、入力ミスの自動修復が強い。入力をミスしたと気付いても、ATOKが直してくれるだろうからとDeleteをまったく押さずに突っ切るスタイルになっている自分に気付いた。ATOK特化型である。これはこれでよろしくない気もするが。

Readwise / 月$7.99

Readwise Readerで効率的にインプットする - chroju.dev などでベタ褒めしてきたFeed Reader + Read Later系サービスなのだが、この円安の折に月$7.99はちょっと考えてしまう。

しかし、こちらも移行先が見つかっていない。一時期は無償で使えるOmnivoreを使っていたが、11月いっぱいで残念ながら サービス終了 してしまった。メルマガとウェブページの双方をサクサク読めるサービスを探しているのだが、メルマガにも対応しているものがほとんどない。

Tile Premium / 年3,600円

忘れ物防止タグのTileは、実際にTileをどこかへ置き忘れてきた際に通知してくれる「スマートアラーム」などの一部機能を使うのにサブスク加入が必要となる。スマートアラームなぞマストな機能なわけで、実質的にはサブスク加入前提の製品だと思っている。

Ankerが発売しているEufyであれば、サブスク契約なしですべての機能が使えるので、一時こちらへ移ったのだが、明らかにTileより精度が悪いためTileへ戻った。Eufyの場合、電車の中など人混みにいると「落としていませんか？」と誤検知することが多く、逆に実際近くから離してみても、Tileより通知までのラグが大きい。ユーザーレビューなどを探ってもそこまで悪評はないようなので、何か僕の環境や設定に起因しているのかもしれない。

このエントリーで書いた Pleroma を建て、Fediverseに参加してから1年が経ったので、いろいろ書いてみる。

構成

始めた当時はシステム構成に言及していなかったので、改めて書き残しておく。

Pleromaは、Lightweight Kubernetesである K3s 上でDockerコンテナとして動作させている。コンテナで動かす必然性はまったくなく、検証用で建てているK3s環境を常時活用していたいという、単にそれだけの理由でこの構成にしている。データの保存にはPostgreSQLが必要だが、これもコンテナで動作させて、EFSで永続化を行っている。

Pleromaは公式のDockerコンテナを提供していないため、サードパーティの https://github.com/angristan/docker-pleroma をforkして使っている。

インターネットとの通信には Cloudflare Tunnel を利用している。いわばngrokのようなものであり、インバウンドの通信を開けなくても、Pleromaをインターネットへ公開できる。サーバの要塞化などの手間はなるべく減らしたい。

全体が載るEC2インスタンスは、t4g.smallのスポットインスタンスを利用している。お金の関係もあってだいぶ貧弱なサイズを使っているが、後述するようにフォロー／フォロワーが少ないこともあってか、そこそこ安定して稼働できている。図にある通りAuto Scalingを採用しているが、あくまで自動復旧のためであり、複数台構成を取っているわけではない。

稼働状況

定常的にメトリクスを記録してはいないが、 cpu: 200m, memory: 250Mi という limits 設定で今のところ安定して稼働している。ActivityPubの仕様上、Federationが増えれば負荷も大きくなるとは思うが、最低限の運用だとかなりリソースの消費は低い。Raspberry Piでも動作可能とうたっているだけはあると思う。

メトリクスの監視はしていないが死活監視だけは行っていて、 UptimeRobot を利用している。無料プランだと5分ごとにHTTP通信を試みる簡易な監視ができるだけだが、不意に落ちている状況には気づける。また status page が作れるのも気に入っている。

ちなみにstatus pageを見ると頻繁に落ちている期間があるが、当初は1AZ構成だったので、AZ内でのEC2キャパシティ不足で不安定になった時期があったりしていた。個人の環境ということもあり、安定性はあまり追求しない雑な運用をしているのが正直なところ。

SNSとしては活用しづらい

ステータス（投稿）が3桁にいくぐらいには投稿しているが、見ての通りフォロー／フォロワーはかなり少ない。

フォロー相手は、おひとりさまサーバを使っていると非常に見つけづらい。大勢参加しているサーバであれば、ローカルタイムラインやフェデレーションタイムラインに見知らぬ人の投稿が流れてくることもあるだろうが、ひとりでやっていると、他人を見つけるには他のサーバへと分け入っていく必要があり、手間がかかる。

知人からフォローしていきたいところではあるが、Fediverseでアカウントを持っている人はやはり少ないし、アカウントがあるとしてもそれを探す手段が限られる。仮に探し当てたとしても、すでに1年以上投稿がないということも多かった。Fediverseを常用している人は、体感やはり非常に少ない気がしている。

逆に、フォロワーがわずかとは言え増えたのが面白い。基本的には、偶然僕のPleromaへ流れ着くことはないはずである。それにも関わらず、他のSNSでまったく繋がりのない人からのフォローもあり、どこから探し当てたのか不思議に思ったりもしている。

今はもうある程度あきらめてというか、開き直って、静かなSNSとして利用している。

クライアントソフト

クライアントとしては、デスクトップではPleromaにフロントエンド（Pleroma FE）が同梱されているので、それをそのままブラウザから使っている。二要素認証もあるので安心感はある。

Androidでは Tusky を使っている。特にこだわりがあるわけではなく、なんとなく見つけて、使いやすかったので使い続けている、というぐらい。

投稿には Buffer を使い、 X (Twitter) や Bluesky とクロスポストをすることも多い。あまり広く見られる必要がない独り言などは、Pleromaだけに投稿したりもする。

https://lifehacking.jp/2024/08/buffer-threads/

自分のメインタイムラインとしての今後

Pleroma、現状はあまりSocialな場にできていないものの、むしろそれでいいと考えて、自分のメインタイムラインとしての意識はこの1年間継続している。Socialな繋がりはX (Twitter)が場としてあり、PleromaはSocial性を追求せずに、好きに投稿を垂れ流す場所としている。と言っても、別に表へ出せないネガティブなことを書きたい、というわけではないが、最近自分のXは会社の採用活動にも活用していたり、公的な性質を帯びるようにもなってきたので、それに対する私的なタイムラインとして、どうでもいいようなことを書いてもOKな場所が別にあっていいな、というか。

このブログと同様、自分の庭という感覚に近いかもしれない。APIがあるのでIFTTTなどを通じたハックもしやすいし、Xと違って、ログインしていなくとも閲覧しやすいのもいい。購読する人はまずいないだろうが、RSSの形でも吐いてくれる。総じて使い勝手としては気に入っている。

今後もX、Bluesky、Pleromaの3軸を併用するのがしばらく続くと考えている。可能であればSocialな場はBlueskyに統一したいのだが、現状だとまだまだXの存在感が大きい。ただ昨今の情勢を鑑みると、Xの先行きに対する不安感は非常に強くなっている。

一方では、Fediverseが主流になる未来というのもまず来ないだろう。分散型のSNSは、分散しているが故にフレキシブルに利用できるメリットがあるが、分散しているが故に盛り上がりが見えづらくもある。局所的な人気と、自分のような個人ユースだけで続いていくんじゃないだろうか。

当然ながらOSSであるPleromaの先行きだってわからないわけだが、現状は活発に開発されており、まだまだしばらくは使っていきたい。

イベント参加時点での筆者の状況

Platform Enginneringを朧気に把握はしているが、腑に落ちるほど理解できてはおらず、それほど積極的に導入を図っているわけではない、というような状態。以前、 Platform EngineeringとSREと「ちいとぽ」と - chroju.dev を書いたときからあまり状況は変わっていない。ただ潮流として「来そうだな」とは感じていて、腑に落としたくて参加したと言ってもいいぐらい。

Platform Engineeingは古くて新しい

よく言われることだけれど、Platform Engineeringはまったく斬新な概念と言うわけではなく、従来から「共通基盤」と言われるような形で、似たプラクティスは実践されてきた。今日のセッションを聞いていても、Team Topologiesを元に実践を始めたという話もあれば、何年も前から取り組んできていたことが、今考えるとPlatform Engineeringに当てはまるのではないか、と考えて発表している、という話もあった。

キラキラした最新の概念、という受け取り方をしなくて良いと考えている。だから過度に遠ざける必要もないし、過度に盲信する必要もない。 Class Platform Engineering implements DevOps とも言うそうだが、SREとはまた異なるベクトルでのDevOpsの変形、あるいは実装、ぐらいに捉えていいのではないか。

Platform Engineeringも小さく始める

では何がPlatform Engineering（的）なのかという話だけど、ガートナーの定義はこうなっている。

プラットフォーム・エンジニアリングは、インフラストラクチャ・オペレーションの自動化とセルフサービス機能により、開発者エクスペリエンスと生産性を向上させます。開発者エクスペリエンスを最適化し、プロダクト・チームによる顧客価値のデリバリを加速させることが期待できるため、大きく注目されています。

ここでは「自動化」と「セルフサービス」に言及されているけれど、これは手段なので、個人的には一度外してみて良い気がしている。力点が置かれるのは「開発者エクスペリエンスと生産性を向上」「開発者エクスペリエンスを最適化」「デリバリを加速」あたりではないか。

最近見かけた以下の定義が一番腑に落ちている。

開発者がデリバリに集中するには、個別最適の必要性が薄い非機能的な部分を標準化し、低コストで扱えるようにすればいい、というのがPlatform Engineeringと捉えている。

よってセルフサービスや、システムの実体を伴った「プラットフォーム」は必要条件ではない。Team TopologiesでもWikiが最小のパターンという話があるし、今日の中だと マルチクラスタの認知負荷に立ち向かう！Ubieのプラットフォームエンジニアリング で「Sentryやログ・ダッシュボードのリンク集を作るだけでも喜ばれる」という趣旨の話題があったのが印象的だった。Backstageのマネージドサービス「PlaTT」をまさに今日リリースしたエーピーコミュニケーションズの方と話していても、「最初からBackstageではなく、まずは小さく始めるので良いと思う」という話になったりした。

Platform EngineeringとSRE

立ち話のなかで「SREの人から見て、Platform Engineeringってどう捉えているか」と聞かれたりした。今日聞いたセッションのなかでも、セッションに対する質問のなかでも、このテーマは散見した。

Platform Engineering とSREの門 というこのセッションの中では、両者の目的の違いや、具体的な取り組み内容の違いなどを、様々な資料を用いて比較している。違いのみならず、共通点などを探して、組織体制をどう組むか、という点を論じた話もあった。

先の質問に自分がどう答えたかと言えば、 開発速度 と信頼性のバランシングを行っている以上、Platform EngineeringとSREには重複した領域があるということと、特に国内ではインフラチームを改組してSREとした会社が多いため、既存のSREがPlatform Engineering的な性格を帯びている場合がよく見られるのではないか、ということだった。実際にどうかは知らないが、自分はこういった背景からPlatform Engineeringに触れることになった。

またSREは組織横断的な活動を求められることも多く、少ない人数でレバレッジを効かせる必要性に駆られる。となると、Platform Engineeringの考え方と近しく、そこから学べることは多いのではないか。

どこまでがPlatformか

もうひとつ気になったことがある。

やっぱり
共通基板（共通で使えるサービス）とプラットフォームが色々と混ざってる話が色んなところで散見される気がする

あくまで、認証とか決済のマイクロサービスであって、プラットフォームと呼ぶと違う気がしてる#pek2024

— 沙南（5thVaxed:MMMFD） (@sokasanan) July 9, 2024

このポストの内容、今日セッションを聞きながら自分も考えていたことだった。Platformとはゼロからインフラやシステムを作る上での素地としてのものを指す（実体はBackstageだったりWikiだったり）と考えていたのだが、各プロダクトが共通して使う、例えば認証認可などの内部向けアプリケーション = このポストでいう「共通基盤」をPlatformとして扱っているセッションもあった。一方で、そういったシステムを取り扱うチームをStream Alignedとして整理しているセッションもあった。

結論としては、原義に照らすと認証認可等の共通システムはPlatformではないと思うものの、まぁどちらでもいいのではないかなぁ、という雑な考えに至っている。デリバリの加速、顧客へ価値を速く届けるというPlatform Engineeringの目的に照らせば、認証認可などは価値そのものではなく、これもまたPlatformとして整理して、開発者がシンプルに呼び出せるようにしよう、と考えていくのは意義がありそうと言える。

一方で、いやそれはマイクロサービスの一部だろう、という整理もわかる。そもそも先のガートナーの定義によれば、対象は「インフラストラクチャ・オペレーション」なので、共通化可能なものすべてがPlatformと言っているわけではない。認証基盤を作るのにもPlatformが必要になってくるわけで、認証基盤はあくまで社内へ価値提供するプロダクトとして、Stream Aligned Teamが扱うべきだ、という考え方もできそうだし、原義に忠実なのはこちらの整理だろう。

とはいえ、これは各社取り組みやすい整理でいいんじゃないだろうか。原理主義的になる必要はない、というよくある話に落ち着けたい。とはいえまだPlatform Engineeringがそこまで広まりきっていないなかで、すでに定義にブレが出てきているのは危うさも覚えるところではある。

暗中模索を続けていく

サイトリライアビリティエンジニアリング（Site Reliability Engineering＝SRE）の分野で私が尊敬する人々は皆、この分野自体が今もなお進化、拡張、変革、新たな発見の真っ只中にあると考えています。ある意味では私たち全員がずっと、SREを探求し続けているのです。

『SREの探求』冒頭のこの一節がとても好きなのだが、Platform Engineeringも同じだと感じる。

僕なりの解釈なので何か間違っていてどこかから怒られるかもしれないが、いずれも方法論ではなく、目的と考え方のセットであり、Howについてはある程度の自由度がある。ただ、Platform Engineeringの目的に同意する、その必要性を感じる人はどうやら多くいそうであり、僕もその一人であり、現在は各社なりの実践が無数に生まれている状況になりつつあり、それを一手に集めて話し合うような、こういったカンファレンスは非常に有意義だと感じた。 昨年のガートナーによるハイプ・サイクル だとすでにピークに達しつつあるが、となると国内だとまだ黎明期を脱したぐらいではないだろうか。これからもしばらく暗中模索が続きそうだし、是非また参加したい。

運営もとてもスムーズで楽しく過ごせました。カヌレとコーヒー、というおやつのチョイス、ゴミもあまり出ないしおなかにもわりと溜まってくれるし物珍しいしおいしいしで、とてもよかったです。

なんかカッコいいなー、とNothing Phone (1)の頃から思ってはいて、それが(2a)で49,800円というリーズナブルな値段になり、時同じくしてPixelのaシリーズ最新の8aが72,600円まで上がってしまったので、これは乗り換えてもいいタイミングかなと。もともと乗り換えるつもりはなかったが、ご覧の通りPixel 6aをバッキバキに壊した故に買い替えを余儀なくされた。Nothing Phoneの良いところはビックカメラが正規代理店になっているところであり、壊したその足でビックカメラへ向かって、少し触ってすぐに購入した。

スマートフォンで処理の重いゲームをしたり、長時間動画を見たりということをしないので、求める性能はミドルレンジでよくて、Pixelのaシリーズは「ちょうどよかった」。3a以降、同じような理由でPixelを使っていた人は結構いたんじゃないかと。余計なアプリケーションが入っていないシンプルさも良かったし、カメラの性能なども気に入ってはいたのだが、円安の余波とはいえ7万円越えてくるとやっぱり「ミドルレンジか、これは？」となってしまう。

買う決め手を「価格」にしてしまったため、Nothing Phoneも今後円安反映がないとは言い切れず、そうしたらまた出戻りするかもしれないが、とりあえず今買う選択肢ならNothing Phone (2a)は十分に「あり」だなと。

デザインがこの機種最大の特徴であり、カメラの配置と本体の材質ぐらいしか各社で差異がないんじゃないかとすら思えるなか、Nothing Phoneの遊び心は嫌いじゃない。

背面にGlyph Interfaceと呼ばれる大きめのLEDが3つ入っているのだが、これは単なる飾りではなく、通知の種類で光り方を変えたり、タイマー使用時に残り時間を表現させたりできる。実用性が高いというよりは、これも「遊び心」の範疇だとは思うが、最低限の情報量で通知に気付ける、というのはデジタルデトックス的な効果も望めるかもしれない。実際、重要な通知が来ているときだけ、Glyphを光らせっぱなしにする、という機能があって、日中はスマホを極力使わないが家族からの連絡だけはすぐ気付きたい、といった用途でわりと便利に使っている。

ミドルレンジということで性能面の期待はしていなかったものの、不満らしい不満は特にない。6.7インチのディスプレイは大きすぎるという好みの問題や、背面に指紋が付きすぎるのが気にかかるぐらいか。スマホを10年以上使ってきたが、初めて背面にも保護フィルムを貼ったぐらいには指紋が目立つ。

Pixel 6aより良い点もあり、画面内指紋認証の精度はNothing Phoneのほうが遥かに高い。Pixel 6aでは成功率5割ぐらいという感覚で使っていたが、Nothing Phone (2a)ではほぼ百発百中で、ストレスがなくなった。

写真に関して細かいことは僕にはわからないが、6aと比べて大きく劣る、という気はしていない。2枚だけだが比較で撮ってみたので貼っておく。いずれも1枚目がNothing Phone (2a)、2枚目がPixel 6aであり、加工やパラメータ調整は何もしておらず、オートで撮ったそのままのものである。

組み込みのランチャーアプリも、ウィジェットなども含めてハードウェアに沿ったデザインになっていて良い。ウィジェットはほとんど使わない主義だったが、なんとなくデザインが良いので使ってみている。

このデザインを活かすなら裸で使いたいところだし、僕はスマートフォンにケースを付けたことがこれまでで一度もなかったのだが、Pixel 6aを派手に壊した反省から、今はSpigelのケースを付けている。ケースはこの機種の弱点と言えるかもしれない点の1つで、当たり前のように種類が少ない。ビックカメラであわせて買おうと思ったが、購入店舗では置いていなかった。

ちなみにデザインのこだわりはSIMピンや、付属のUSBケーブルにまで及ぶ。だいたい付属ケーブルなどはすぐ捨ててしまう（手元に山とあるので）のだが、これについては捨てられず携帯している。

総じて、この価格でこの性能、というのは、巷の評判通りコストパフォーマンスがかなりいいと感じる。それだけに、この為替レートが継続した場合、次の(3a)が同じ価格で出ることはないかもしれないとも思う。次の買い替えのときには、またPixelとの間で悩んでいるかもしれない。スマホに変化や遊び心を求める、というのもここ数年なかったので、このタイミングでNothing Phoneを買えたのは幸運なタイミングだったようにも思う。

面白かった。タイトル通り歴史をつづった本であり、純粋な技術書というよりは読み物としての性格が強い。具体的なセキュリティインシデントも当然登場するが、その技術背景が詳しく掘り下げられるわけではない。「SQLインジェクション」「カーネル」など、専門家にとっては基本的な用語にも注釈がついているので、むしろ専門外の方でも広く読めるようにした文芸書に近いのかもしれない。ちょっと違う気はするが、『失敗の本質』情報セキュリティ版、みたいな趣だろうか。

歴史の範囲はENIACの誕生から2020年前後までであり、およそ現代における電子計算機の発展の歴史を概観する形になる。複数ユーザが1つのコンピュータを共有するタイムシェアリングシステムの確立、数多のコンピュータがネットワークで接続されたインターネットの誕生、急速にコンピュータが民間へ広まったドットコム・ブームと、コンピュータの扱い方を巡るパラダイムが変わるごとに、セキュリティの在り方も変わり、新たな問題が出現しては対策が積み重ねられてきたのだ、ということが語られる。まさに「敗北史」ではあるのだが、あまりネガティブな語り口ではなく、淡々と読める。今では当たり前になったセキュリティリスクが、歴史のどの段階で、どういった背景から生まれてきたのか、という観点で見る機会は、これまであまりなかった。

パラダイムの変化によってセキュリティの在り方が変わった、というのは技術的な要因のみならず、人間の心理的な要因も無視できない。例えば本書で「リスク補償理論」に触れられているが、これはある安全対策が導入された際、人は別のところで以前よりもリスクを冒すようになり、結果的に全体的なリスクの増減が相殺されてしまうという理論だ。これをセキュリティの文脈に当てはめると、ファイアウォールが導入されたことで安心感が生まれ、個々のクライアント側でユーザーのセキュリティ意識が低くなる、といった事象となる。6章では「ユーザブルセキュリティ、経済学、心理学」と銘打たれ、このような心理学や行動経済学の観点から見たセキュリティ問題に丸々1章が割かれているほか、7章「脆弱性の開示、報奨金、市場」や8章「データ漏洩、国家によるハッキング、認知的閉鎖」でも、人間のマクロな経済行動をベースとした話が展開される。インターネットの登場、スマートフォンの登場といった形でユーザーのコンピュータとの触れ方が変われば、当然ながらその心理にも変化が生まれ、情報セキュリティの問題も形を変えていく。さらには国家機関のサイバー戦争により、脆弱性は「武器」として扱われ、民間を巻き込んでより複雑な様相となっている。

単に「敗北史」を描いただけの諦念に満ちた本というわけではなく、最後の9章「情報セキュリティの厄介な本質」では全体を総括しつつ、今後の情報セキュリティの在り方に対して一石を投じて締めている。

セキュリティを実現する ためには特定の条件が必要であるという主張には、反証可能性がない。また、特定のセキュリティ技術、製品、または方法を採ることがセキュリティに求められるというセキュリティ製品のベンダーや セキュリティ専門家のアドバイスにも、 反証可能性は存在しない。これは情報セキュリティ分野の中心で待ち構える、実存的な危機だ。人々が意識するかしないかにかかわらず、 その実際的な影響は、何十年にもわたって蓄積されてきた山のようなセキュリティアドバイスに現れている。どのアドバイスに効果があるかを判断する方法がないため、効果のないアドバイスを破棄することができず、すべて山の中に加えられてしまう。 (p.276)

本書の帯には「愚者は経験に学び、賢者は歴史に学ぶ」という有名な格言が書かれているが、情報セキュリティはまさに歴史の集積であると、改めて気付かされる。本書によれば、バッファオーバーフローの概念が初めて公になったのは1972年のことだが、それから半世紀を経た現代においても、この問題が完全に撲滅されたというわけではない。一度現れた問題はその後もついてまわり、対策に対策を重ねて現代に至っている。

情報セキュリティ対策は終わりのあるものではないし、「敗北史」は今後も続いて行くのだろうが、そのなかで如何に最善を尽くすことができるかを知る上で、示唆に富んだ本だと思う。

Corne Cherryを約4年前に手に入れて以来はずっとこれを使っていて、もう日常的に使うキーボードを買い替える必要はなかろう、ぐらいに溺愛しているのだが、そのCorneの新版V4が出たので購入した。何が変わったのか？という点は遊舎工房の商品ページを参照されたい。

https://shop.yushakobo.jp/products/8961

一番の違いとして 「半田付けが不要になった」 という点があり、キースイッチとキーキャップを買って植えて、あとはネジ留めさえすればすぐ使えるので、半田付けを敬遠していた方にも勧められそう。

ケース付きで音が変わる

もともと使っていたのはCorne V3に IMK Corne Case というサードパーティのアルミ製ケースを合わせたものであり、この時点でもだいぶ完成度が高いと感じていた。

一方でCorne V4についても、自作キーボードで一般的なサンドイッチ構造（キースイッチを半田付けする基盤を、アクリルプレート2枚で挟み込むように構成したもの、写真左）とは異なり、ケースが搭載されている。IMK Corne Caseのような金属製ではなくプラスチック製ではあるが、非常に質感が良くて触ってて気持ちがいい。

金属製ケースだと少し甲高い音がしていたのだが、プラスチック製になって低めの静かな音に変わった。良い録音機材を持っていないので音を届けることはできないが、コトコトと良い音を立てていてすごく気に入っている。個人的にはもう少し静音性が欲しいので、遊舎工房の フォームカットサービス を使うつもりでいる。

なお、キースイッチは Kailh Deep Sea Silent Box Switch Islet を使っている。今回のために新しく購入したが、静音性も然る事ながら、ブレが少なくてこれも非常に良い。

追加された4つのキーをどう使うか

V4ではProMicroが不要となったことで、空いたスペースにキーが左右2つずつ追加された。Corneのキー数は「ギリギリ足りる」という感覚でいたので、この変更はとても嬉しく感じていたのだが、結果から言うと現状あまり活用できていない。

そもそものCorneの配列が、改めて考えると完璧だったのだ、ということに気付いている。ホームポジションから1つ隣へ指を伸ばすだけですべてのキーに届くので、とても収まりが良いのだ。これに慣れると、今回追加されたキーはホームポジションから2つ隣というだけなのだが、それでも遠く感じる。文章を打つときにここまで指を伸ばすのが意外とつらい。

そのためタイピング時以外で活用できる、マクロなどを割り当てるのが良いかなと考えている。1つは画面ロックに設定してみているが、これはなかなかいい。他も使い道を模索したいところ。

また、これも意外だったのだが、打ち間違いが増えた。今使っているキーキャップが、ホームポジションのf, jキーに突起がないこともあり、意外とキーを見ながら打っていたらしく、「右から2番目のキーがf」という具合に視覚的に認識していたのが、キーが増えたことで目算が狂うようになったらしい。ただ、慣れの問題ではあり、徐々に打ち間違いは減っている。

Vialでのキー設定

近年はQMK Firmwareをコマンドラインでビルドする、という手段を用いず、GUIからキーマップを設定できるツールが増えた。

そのなかの1つに Vial がある。これは設定変更のたびにファームウェアをフラッシュする必要がない（GUI上でキーマップを変更すると即時反映される）、Tap Dance などの若干特殊な機能もGUIから設定ができる、といった特徴があるのだが、利用するにはQMK Firmwareからforkされた、 vial-qmk というファームウェアを焼いておく必要がある。

Corne V4にデフォルトで焼かれているのはQMK Firmwareだが、ありがたいことに設計者であるfoostanさんのレポジトリ foostan/crkbd でVial向けのファームウェアが配布されているので、これを焼けばVialが使えるようになる。

Tap Danceは僕にとってCorneを使う上でのキラー機能に近い。右親指下のキーで、Single TapでIME OFF、Double TapでIME ON、Holdでレイヤー切り替えという設定をしている。トグルではない形でIMEを切り替えられるのは精神衛生にいい。従来、QMK Firmwareだとこのあたりを設定するのにちょっとしたコードを書かなければならなかったが、VialならGUIから設定できるのでだいぶ気軽になった。

Vialで1点だけ気になる点としては、Tap DanceでHoldがうまく認識されず、Single Tap扱いになることがたびたびあること。この点、調整可能なのかも怪しい気がしているが、もう少し粘ってみたい。

https://github.com/vial-kb/vial-gui/issues/108

2度目のEND GAME

自作キーボード界隈で、自分の究極の理想とするキーボードへたどり着くことをEND GAMEと言うが、2度目のEND GAMEかもしれない。

冒頭に書いた通り半田付け不要になったことで、リーチする層が広がり、分離型キーボードを買う上で市販のものに並ぶようなかなり有力な製品になったんじゃないかとすら思う。

| 評価 | 2年次 | 3年次 | 4年次 | 5年次 | 6年次 | | :--: | :---: | :---: | :---: | :---: | :---: | | S | 8 | 2 | 4 | 2 | 6 | | A | 12 | 8 | 6 | 8 | 8 | | B | 4 | 4 | 6 | 4 | 2 | | C | 0 | 4 | 0 | 0 | 0 | | 合計 | 24 | 18 | 16 | 14 | 16 |

120単位修得し、ついに卒業まで残りは4単位となった。4単位ぐらいどうにかならなかったのか、とは思う。実のところ今年度の成績開示をするまで、残る必要単位はあと8単位だと勘違いしていた。どこでどうこの勘違いが起きたのかわからないが。。期中に「あと4単位で卒業可」と気付いていたらもう少し頑張ったかもしれないし、そうでもないかもしれない。いずれにせよ今年度はあんまり余裕がなかったので難しかった気もする。蓋を開けたら昨年度より修得単位数が多かったし、成績も良かったのでびっくりしている。

残り4単位のために1年分の学費を払う、というのはもったいない感があるので、単位登録は多めに行い、学びたい科目は卒業要件抜きにして学んでみようかと思う。あとは昨年度より試験がすべてオンラインになった関係から、2年間ぐらいキャンパスに足を踏み入れていないので、どこかで遊びに行っておきたい。まぁ理工学部のキャンパスは厳密には宇都宮なのですが、板橋でもいいかな。宇都宮も機会があれば行っておこうかな。餃子を食べがてら。

受けて良かった科目

オペレーションズリサーチ

ざっくり意思決定を支援するための科学的技法、という定義でいいんだろうか。線形計画法、待ち行列理論、動的計画法とかそのあたりを学んだ。計算機科学と軍事が切っても切り離せないが、オペレーションズリサーチもまた同様の関心から生まれている。

オペレーションズリサーチという分野については、『サイトリライアビリティワークブック』1章で言及があり、その関わりから楽しみにしていた。

うまくいくとされていたベストプラクティスは、状況に大きく依存し、広く採用されているとはとても言えません。また、運用チームをうまく運営する方法についてはほとんど取り組まれていないという問題もあります。これらのトピックについての 詳細な分析は、一般に、第二次世界大戦中に連合軍におけるプロセスとアウトプットの改善に向けられた[オペレーションズ・リサーチ]（ http://bit.ly/2HeARLw ）に端を発すると考えられていますが、実際に私たちが考えていたのは何千 年にもわたって運用をうまく行う方法（ http://bit.ly/2HcEH7R ）についてでした。 （1章 SREとDevOpsの関係）

画像情報処理

よくある画像フィルタが、数学的にどのようなメカニズムで掛けられているのか知ることができる科目。このあたりは全然予備知識がない一方、ImageMagickなどで触れる機会は多かっただけに、その内実がよくわかる気がして面白かった。GNU Octaveを使って実際に処理も書くので実感が湧きやすい。

自動制御論

いわゆる制御工学の分野。主にフィードバック制御を中心として学ぶ。多くは機械などの物理的なものが対象になるものの、あるシステムのアウトプットをフィードバックし、インプットを変化させてアウトプットの安定化を狙う、みたいな考え方は応用が利くものなので、知っておいて損はない分野だな、と。

大学を卒業する前に（25年春卒業を想定）、MacBookを学割で買い替えておこうと思って待ち構えていたところ、先日M3のMacBook Airが出たので購入した。特にこの3月ごろの時期は、学割購入時にはApple Gift Cardも24,000円分もらえるのでさらにお得に。

First Impression

初めてApple Siliconを搭載した、MacBook Pro (13-inch, M1, 2020) からの買い替えなので3年ちょっとぶり。当時はまだTouch Barのあるモデルだった。いろいろ言われていたTouch Barだが、音量や明るさをスライダーで調整できる点などはわりと気に入っていたので、若干操作感の変化に戸惑いはある。

性能面の違いは然ることながら、10年ぶりぐらいにAirを買ったので、そのことによる変化が大きい。最近はAirでも24GBメモリを積めたり、十二分な性能になってきているので、あえてProを買う必要はないと判断した。Airであれば充電に必要な電力が30Wで済むので、 Anker 511 PowerBank のような、バッテリーと充電器を兼ねた機器でも充電が可能になった。充電器とバッテリーの双方を携帯しなくてよくなったのはなかなか便利。

明らかに薄さがわかる、Airの楔形ボディが好きだったので、それが失われたのは残念ではある。それでもProと比べれば明らかに薄いし軽くて取り回しはしやすくなった。バックパックに入れて背負ったときの感覚も、数百グラムの差分だが結構違う。向こう5年ぐらいはこれで戦えたらと思ってたりする。

初期設定

軽く初期設定まわりの話も書いておく。

僕は新しいPCを買ったら、以前のマシンの中身をそのまま移行するということはせず、ゼロから環境を作り直している。定期的に強制的なクリーンナップをするのは大事。初期設定については https://github.com/chroju/dotfiles にだいたい集約している。

Homebrew

Brewfileに以下のような形式でインストールするパッケージを書いておき、 brew bundle すると一気にインストールしてくれるので便利。継続的にメンテナンスとかはしていなくて、だいたいPCを買い替えたときに旧PCで brew bundle dump コマンドにより現在インストールしているものを出力し、不要なものを削除して新たなBrewfileとしている。

brew "asdf"
brew "bitwarden-cli"
brew "fzf"
...
cask "anki"
cask "bitwarden"
...

$HOME 配下のファイル群

~/.gitconfig とか ~/.ssh/config とか、 $HOME 配下に配置するファイル群。これについてはdotfilesのレポジトリに HOME というディレクトリを置いていて、例えば HOME/hoge/fuga のファイルのシンボリックリンクを $HOME/hoge/fuga に配置する、という形のシェルスクリプトを書いて対応している。今見ると2年ほど前に書いたなかなか頑張ったシェルスクリプトが出てきたけど、最近だともうちょいシュッとできるソリューションがありそうな気はする。

#!/bin/bash

function make_symlinks() {
    for f in $(ls -A $1); do
        src="$1/$f"
        dst="$2/$f"
        if [ -f $src ]; then
            if [ -e "$dst" ] && [ "$3" = '-f' ]; then
                echo "### WARN: overwrite $dst ###"
                ln -fs $PWD/$src "$dst"
            elif [ ! -e "$dst" ]; then
                echo "make symlink $dst => $src ..."
                ln -fs $PWD/$src "$dst"
            fi
        elif [ -d $src ]; then
            if [ ! -e "$dst" ]; then
                echo "make directory "$dst" ..."
                mkdir "$dst"
            fi
            make_symlinks $src $2/$f $3
        fi
    done
}

if [ "$1" = '-f' ]; then
  echo '!!! force mode'
fi

make_symlinks dotfiles/HOME $HOME $1

昔はAnsibleで頑張ったりしていた頃もあったが、もっと薄い仕組みでいいやという気分になり、シェルスクリプトに書き換えた経緯がある。

各種システム設定とdefaults

macOSの設定をターミナルから読み書きできる defaults というコマンドがある。 Macの「ターミナル」でプロパティリストを編集する - Apple サポート (日本) に記載されており、特に隠し機能というわけでもないのだが、どんなコマンドを打てばどういう設定になるのか、という情報は公式に公開されておらず、有志が確認した情報頼りの状況。

OSのアップデートに伴い、コマンドが変わることもあり得る。例えばメニューバーにバッテリーのパーセント表示をするコマンドは、Big Sur以降とその前までとで、以下のように違いがある。

- defaults write com.apple.menuextra.battery ShowPercent YES
+ defaults write /Users/$_user/Library/Preferences/ByHost/com.apple.controlcenter.plist BatteryShowPercentage -bool true

Infrastructure as Codeチックなことができるので、できる範囲で使いたいところではあるのだが、上述の経緯があるのであんまり隅々までdefaultsで賄うことにはこだわっていない。知っているコマンドだけはスクリプトに列挙しておいて、効いたら儲け物、ぐらいで考えたほうがいいものと捉えている。

システム設定、その他ではだいたい以下のところをいじっている。

• キーボード
  • 「キーボードショートカット」→「修飾キー」から、CapsLockをControlに変更する
  • 「キーボードショートカット」→「ファンクションキー」→「F1、F2などのキーを標準のファンクションキーとして使用」を有効化
  • 「キーボードショートカット」→「Spotlight」は使わないので、すべてのショートカットを無効化
• トラックパッド
  • 「ナチュラルなスクロール」を無効化
  • 「ページ間をスワイプ」を無効化
  • 「通知センター（2本指で右端から左にスワイプ」を無効化
• Dock
  • 「自動的に表示/非表示」を有効化
  • すべてのAppを削除して、使用中のAppだけが表示されるようにする
    • Appは Raycast から起動するので、Dockによく使うAppを置く必要がない
• Mission Control
  • 「最近の使用状況に基づいて操作スペースを自動的に並べ替える」を無効化
  • 「ホットコーナー」をすべて無効化
• 壁紙
  • 黒いものにする
    • メニューバーの色が壁紙を透かすので、黒い壁紙にするとメニューバーも黒くなり、ノッチが目立たなくなる

GPG key

Git commitの署名などで使うGPG key。秘密鍵はYubikeyで管理しており、公開鍵はKeybaseに上げているので、公開鍵だけ引っ張ってきてあとはYubikeyを新たなPCに挿せば終わり。

認証情報系

Cloudflareとか各種クラウドサービスについては、新たに認証し直し、旧PCからCredentialを持ってきたりはしていない。APIキーが必要な場合はローテートする。

開発環境はこれから

とりあえず全般的な設定がこんな感じで終わってきたところで、個別に必要な開発環境などはまだこれから。なるべくローカル環境を汚さずにdevcontainerとか使うことを今度のマシンでは意識していきたい。このあたりは必要に合わせて徐々にやっていこうと思う。

あと、ターミナルは長年iTerm2を使ってきたが、今回 warp を試してみている。コマンドの自動補完に用いていた Fig がちょうど開発終了を表明しており、後継のAmazon CodeWhispererに移っても良かったのだが、ちょっと趣向を変えてみようかなと。

https://www.warp.dev/

warpはターミナルアプリだが、補完機能も内包している。1回のコマンド実行とその出力が、UI上は「block」と呼ばれる区切られた範囲内で表示され、めちゃくちゃ長い出力とかでもblock内をiframeのような感覚でスクロールして見られるのがなかなかよかった。補完はFigほどではない感じがしているが、もう少しチューニングしつつ様子を見たい。

自分も若くなくなってはきたので、定期的に環境を入れ替える、ということは意識的にやっていかないといけない気がしてきている次第。

https://github.com/chroju/raycast-extensions

処理としては以下のような感じ。

1. ExtensionのPreferenceで、ユーザーが検索したいProviderを登録する（複数可）
2. Extensionを起動すると、登録されたProviderのGitHubレポジトリから、ドキュメントのmarkdownファイル一覧を取得し、その名前をUIへ表示する
3. ユーザーがmarkdownファイルを選択すると、そのファイルを読み込んで表示する

Providerは任意のものを検索可能とし、ユーザーが好きなものを登録できるようにした。Raycastではrequiredな設定項目を作っておくと、Extensionの初回起動時に設定画面を表示してくれるのが便利。デフォルト値を登録しておいてもこの画面は開くので、どのように記載すればいいかデフォルト値を通じて例示が出来るのも良い。

任意のProviderに対応可能なのは、ドキュメントがProviderのレポジトリ内の決まった場所に保存されているから。Terraform Registry - Provider Documentation | Terraform | HashiCorp Developer で、ドキュメントのディレクトリ構造が定められている。

ただ面倒なポイントとしては、ディレクトリ構造の規則が一度変更になっており、さらに従来の規則がまだ有効であること。

• 現行の規則
  • docs/resources
  • docs/data-sources
• 従来の規則
  • website/docs/r
  • website/docs/d

AWSやGoogleなどでもまだ従来の規則に則っており、双方に対応する必要がある。どちらの規則に従っているのかをあらかじめ知ることは不可能なので、現行のディレクトリ構造を探索してみて、フォルダがなければ従来のディレクトリ構造を探索するという形にしている。

最後の、ドキュメントを表示する部分はあまり難しくなくて、というのもRaycastにMarkdownを引き渡せば、いい感じに表示してくれる機能が最初から備わっている。Terraform ProviderのドキュメントもMarkdownで書かれており、Frontmatterだけ削除すればRaycastでそのまま表示できる。

体験としては結構良い感じではあるのだが、Raycastのウィンドウは閉じると初期状態に戻ってしまう点や、表示したMarkdownの全文検索するような機能がない点など、ドキュメントを読むには若干厳しいかなというところもある。うっかり画面を閉じるとまた最初から検索し直し……というのは辛いので、「最近読んだドキュメント」をキャッシュする機能は付けた。

ブラウザでドキュメントを開くオプションも付けているので、全文検索しながらじっくり読みたい場合にはブラウザから開く形で対応している。

Raycast Extensionは初めて作ったものの、リッチなUIを簡単に作れるのでモチベーションを保ちやすい。並行してTypeScriptやReactの本を読んでいるので、それらの知識を反映させながらブラッシュアップしてく予定。

定量評価

• ブログ : 13記事（昨年比 -6）
• GitHub Contributions : 266 (-109)
• 書籍 : 34冊（-3）

全部減ってますね。

ブログは書かなかったなぁ、という感覚が明確にある。インプットが技術からマネジメント寄りになり、なかなかそれを抽象化して自分の考えとして書く、というのができずにいる。技術的な記事はこうやってこうしたらこういう罠があって、こう課題をクリアしました、というのが言いやすいが、マネジメントやリーディングにおいて、そういった意識的な仮説検証のループが回せていない感じ。あとは実践が社内の話になってしまうので書きづらいのもあるし、一般化がしづらくも感じる。

GitHubはパブリックなContributionに限定した数字なので、まぁこんなものかなと。ただプライベートを含めた場合でも前年比-800ぐらいでかなり減っている。 手を動かさないマネージャーを試している - id:onk のはてなブログ という記事を読んでから、特に4Qは自分で手を動かす機会を意図的に減らすことを試していた。徐々に自チームだけではなくて、部門全体や部門をまたいだ検討をする機会が増えてきて、そういった広いレイヤーの話と、目の前で自分がこなすタスクとの間でコンテキストスイッチするのがかなりしんどく思えてきたのが一因。今の立場だと、手を動かすことからなるべく離れた方がいいと思っている。自分が本当にやるべきことにちゃんとフォーカスできる環境をつくる、というのは今後も大事にしたい。

本はもっと読みたいですね！と毎年言っている気がする。うーむ。言い訳ではないが、この読書冊数は ブクログ から取っており、つまりブクログに登録できない、ISBNのない本は換算されていない。同人誌などの類をよく読むようになるにつれ、これらもちゃんと「読書である」と換算したいな、と思ったりしている。

読んだ本でよかったのは『HIGH OUTPUT MANAGEMENT』、『97 Things Every SRE should know』、『作家の仕事部屋』、『組織戦略の考え方』、『アジャイルな見積りと計画づくり』あたり。

今年のハイライト

認知行動療法

https://chroju.dev/blog/how_to_be_a_stoic

今年最初に学んでいたのがこのあたりだった。負の感情に苛まれて落ち込むのをどうにかしたいとき、感情自体を制御はしづらいが、そのときどう考えたり行動したりしてその感情に至ったのかという「認知」と「行動」に着目してコントロールを目指す考え方。

聞きかじりで試しているので、なかなか実践が難しくも感じるが、こういった手法が存在すると知れたこと自体が財産だった。『ヒカルの碁』で伊角さんが感情のコントロールは「技術」であると気付くシーンがあるが、あれを20年越しぐらいに理解できた感じ。

採用に対してオープンになる

各種の人材系サービスで「転職活動はしていないが、話だけでも聞いてみたい」のステータスに変更し、実際に何社かとカジュアル面談する、ということをしていた。

きっかけは自分が採用活動をするなかでの気付き。採用においては、相手の転職意欲を問わずカジュアル面談などで認知を広め、「種を撒く」ことが大事になる。ならば求職側としても同じことでは？ということで、様々な会社との接点をつくることを意識し始めた。知っていたり、実際にお世話になっているあの会社やこの会社、あるいは全然知らない会社、とても良い機会を得られた。

ただ「とはいえ相手は業務なんだよなー」というのが、つい脳裏をちらついてしまい、自分の性格的に向いていないっぽい。今年後半においては、あんまりこの活動をしてはいないが、適度に続けてはいきたい。

Fediverse (Pleroma)

https://chroju.dev/blog/twitter_to_pleroma

Twitter大変動の1年であり、自分としてはFediverseに軸足を移しつつある。もうPleroma中心でいいかな、というぐらいに使い慣れてきた。サーバーも安定している。ただ、こういう年末年始とか技術系のカンファレンスに参加したときみたいに、大勢とたわむれたい場合はどうしてもTwitterになる。ブログへの流入もTwitterを無視できない。

2年目の週報

2022年から始めている週報は、NotionからWorkflowy、Pleromaと場を変えつつ、また何回か書かない時期を挟みつつ、とりあえず続いている。良い習慣になっている一方、体裁を整えればOK！みたいな、若干形式的になってきている感覚もあるので、内省の機会としてもっと活用できるようにしたい。先に書いたマネジメント面での仮説検証のループを回す軸にしたり、とか。

体重が（多少）増加

健康面では、低体重が一番の悩みだけど今年ようやく「意識的に体重を増やす」感覚が掴めた気がしている。増やすぞ！と思ってそのための施策を取るとちゃんと増えた。秋ぐらいはちょっとサボって減っているのだが、そんな簡単に減るのも勘弁してくれよ、という気持ちはある。

とりあえず標準体重の範囲内に載せるのが目標。

振り返ってみて

今年はプライベートに時間を取られることも多く、そこまで意識的な学びができていないというか、特に夏以降は自転車操業のような気分になっていた。もともと長期的に物事を考えるタイプではなく、キャリアも目の前の課題に対してアプローチを繰り返すことで積み重ねてきている感じなのだけど、それだけだと限界かもしれないとも感じている。もっと考える時間が要る。会社のことにせよ自分のことにせよ、広く遠くまで見渡して仮説立ててやってみて、調整をしながら前に進む必要がある。そのためには時間も取るべきで、大学を中心としてきた生活もそろそろ終息しつつあるので、時間の使い方を来年はガラッと変えてみたい。

技術的な動向だと、Platform Engineeringとか、先端で話題になっているテーマをあんまり楽しめていない自分がいる。Generative AIもそこまで活用できていないし、自分の生産性をこれは本当に飛躍的に変える可能性があるのか、と若干疑いつつ、単に自分が上手く使えていないだけなのだろうなと今は思ってはいる。先端をたしなむ必要性が必ずしもあるわけではないし、それならそれで今使っている技術の基礎と先端をしっかり押さえようかな、というターンが今なのかもしれない。ちなみに年末年始はReactを触っている。TypeScript (JS) に慣れたい。

一方でいろいろ変化が大きいですね、とも思う昨今。Generative AIもそうだし、OpenTofuとか。来年はChromeでの3rd Party Cookie廃止もあるし。振り回されないようにしつつ、押さえるべきは押さえつつ。

スマートロックのSESAMEから、新たに出たオプションパーツ。指紋認証とICカード認証による鍵の開閉が可能になる。写真は左から旧型のSESAME mini、SESAME 5、SESAME Touch。

もともとSESAME自体は数年単位で使っていた。開閉方法はスマホアプリから操作するか、スマホとSESAME本体がBluetoothで接続されれば解錠される「手ぶら解錠」の2択だったのだが、アプリを起動するのは面倒だし、手ぶら解錠のほうは精度がいまいちで、解錠されないときもあれば、扉に到着するよりかなり早く解錠されるときもあったりで、使っていなかった。

現在はICカード認証をメインとして、スマホのNFCタッチで開けているが、だいぶ楽になった。両手が塞がっていてもスマホを取り出してかざすぐらいならなんとかなる。指紋認証をメインにすればさらに楽だとは思うものの、精度が良くなくて使わないままになっている。おそらくは同じ指で複数回登録すれば精度が上がる気はしている（スマホの指紋認証のような丁寧な登録ではなく、1回タッチしたら登録完了、になるので、少しでも角度が違うと認識しないっぽい）。

Bellroy Melbourne Backpack

Bellroyは2021年1月にClassic Backpackを買ったのが最初。当時も 買って良かった に挙げていた。このClassicが、特にストラップの付け根あたりが裂けてボロボロになってきてしまったので、買い換えようと改めて様々なブランドを探ってはみたが、結局またBellroyになった。

Bellroyは背負い心地が良い。背面部分がClassicだと「ランバーサポート」と称されており、硬すぎず柔らかすぎずちょうどいい具合に背中とぴったり合ってくれる。PCリュックは如何に背中から離さずPCを配置できるかが、重さを感じないためのポイントであり、その点でこれ以上のものに出会えなかった。あとはストラップが下にいくほど細くなっていて、脇の下あたりで異物感を感じづらくなっているのも良い。「背負っている感覚」が非常に薄い。

背負いやすさでいえばClassicのほうが細かい点で上ではあるのだが、同じものを使うのもつまらなくて今回はMelbourneに。トップローダーがマグネット式になっていて開閉しやすい点、防水のサイドポケットがついて、スマホが取り出しやすくなった点など気に入っている。

Bellroyの難点は、国内で置いている店が少ないこと。今回探してみたところ、大きなLoftには置いていることが多かったが、扱っているラインナップは限られるようだった。Amazonで買うのが一番早い。ただ、Bellroyのバッグは色によって素材が違ったりもするので、触らずに買うのはわりと罠かも。僕は一度買っているので、写真から「この見た目だと、この素材かな……？」と推測して買う技を使っている。

Pomera DM250

買った経緯などは DM250と、書き留めるということと、わかりあえなさと。 - the world was not enough で書いている。何か書き物をするときはやっぱりポメラのほうがPCより集中できる気がする。

背面がめちゃくちゃ指紋つきやすいので、 リメイクシート を貼ってウィリアム・モリスなポメラにしている。

Anker 511 Power Bank (PowerCore Fusion 30W)

USB充電器としても使えるモバイルバッテリーの最新型。充電器として使ったときに従来だと20Wも出ない感じだったのが、今回30Wになったので、Macbook Airさえも急速充電できるようになったはず。今はバッテリーと65Wの充電器を両方持ち歩いているが、MBAに買い換えてPower Bankだけ持ち歩く生活にしたいと思っている。

無印良品 携帯用のびのびボディタオル

ホテルや旅館で風呂に入るとき、ボディスポンジがアメニティで置いていないときってどうやって身体洗います？という問題。素手でも、備え付けの普通のハンドタオルとかでも泡立てるのが難しくて洗った気にならなくて、1泊とかならいいけど連泊しているとちょっと気になっていた。

ということでこれ。携帯用ということでEVA樹脂製のケースがついているし、試しに使ったところ、タオル本体も浴室に一晩吊しておけば乾いてくれた。泡立ちもよくてGood。

無印良品 香りを楽しむ炭酸水 ライム&エルダーフラワー

またも無印。今年のベスト炭酸水。エルダーフラワーソーダはスッキリしていて若干の甘味が感じられるバランスで好きなのだが、あまり売られているのを見ない。これは今のところ夏ぐらいから恒常的に売られていて入手しやすい。炭酸は弱めなので、リラックスしたいときに飲む感じ。

Subscriptions

  * Gyazo Pro (¥4,680 / year)
  * MoneyForward プレミアム会員 (¥500 / month)
  * Nintendo Switch Online + 追加パック (¥4,900 / year)
- * Amazon Prime Student (¥2,450 / year)
- * Spotify Premium Student (¥480 / month)
+ * Spotify Permium Duo (¥1280 / month)
  * シネマシティ (¥1,000 / year)
  * Workflowy Pro ($49 / year)
  * dアニメストア (¥400 / month)
  * メールマガジン「読書日記／フヅクエラジオ」 (¥800 / month)
  * ATOK Passport (¥300 / month)
  * IFTTT Pro ($1.99 / month)
  * O’Reilly Online Learning ($299 / year)
- * Mailbrew ($59.88 / year)
- * Tile Premium (¥3,600 / year)
+ * Google One スタンダード (¥2,500 / year)
+ * Readwise ($7.99 / month)
+ * Raycast Pro ($96 / year)

解約周りだと、Amazon Prime Studentは学生向けということで最大4年間しか使えず、今年で4年を過ぎた。これを機にAmazonから少し距離を置いてもいいかなーと思って、通常のPrimeで再契約することはしていない。

Spotifyのほうはこれは自主的な解約で、家族2人で入るならPremium + StudentよりDuoのほうが安いと今更気付いたからです。。

Mailbrewは解約ではなく、無償提供に変わったという珍しいパターン。Twitter APIのゴタゴタがあった際、すぐに反応がなかったりなど継続性に不安はあるが、無償だし、ということで使ってはいる。

Tile Premium は、スマートタグのTileで置き忘れアラートを有効化するのに必要だった契約。最近、サブスク契約が不要な Anker Eufy Security SmartTrack に乗り換えた。「買ってよかった」に入れていないのは、置き忘れアラートが鳴るまでのスパンがTileよりちょっと遅かったり、まだ「良い」と言い切れない部分がある感じ。

新たに契約したものだと、Google Oneは写真の保存容量が無料枠だとまかなえなくなったため。Readwiseはすでに何度か書いている通り。

https://chroju.dev/blog/readwise_reader_is_so_good

Raycast Pro はほぼAIだけを目当てで使っている。OpenAIのChatGPTは、ブラウザをわざわざ開くのが面倒で使う習慣ができなかったが、Raycastのランチャーから呼べるとわりと気軽に使う感覚が身についてきた。Raycast AIだとプロンプトを保存しておくことができるのもいい。プロンプトには「選択中の文字列」を渡すことなどもできるので、「今選択してる文字列を和訳せよ」とかもできる。

これでOpenAIより安くGPT4も使えるから十分かな、と。Generative AIは何かしら使っていかないとマズそうだよな、という思いが強くて、もっと活用してはいきたいところ。

サブスク契約に至る閾値

単純に価格の多寡で決めてるわけでもないし、結構これは感覚だな、と今年は突きつけられた気がする。Raycast Proの年間$96は決して安くないが、Generative AIはマスト、という気持ちで契約した。一方で最近 Dash が月間210円のサブスク型へ転換したが、こちらは不思議なことに渋っている自分がいる。

ひとつあるのは、月々の課金よりannually planがあるほうが財布の紐が緩みやすい。あんまり毎月の固定費というのを作りたくなくて、払うなら一気にポンのほうが個人的には好き。

そもそも「できる限り増やしたくない」というのも当然ある。本当に必要なものだけを契約したいし、ちゃんとプラスになるようなお金の使い方をしたい。まだもう少し減らしたい気持ちが正直なところ。定期的に固定で出るお金なんて、少ないに越したことはないのだ。

そもそもReadwise Readerって何？という点は先のエントリを……というところではあるのだが、ウェブページを中心として様々なものを「読む・読み返す」ためのサービスであり、以下のようなサイクルで読んでいくことになる。

• 収集: 読むかもしれない記事を自動収集する
• 保存: 読みたい記事を保存しておく
• 閲覧: 記事を読む、読んで記録をつける
• 再読: 記事の抜粋などを読み返す

収集

Readwise Readerには、記事を集めておくところが2つある。UIの左上、「Feed」と、画像でFeedの上にあるアイコンが「Library」。「Feed」は自動的に記事を集める場所であり、「Library」は手動で記事を保存する場所にあたる。まずはFeedに記事を集め、そこから読みたいものをLibraryに送り込む。要するところ、FeedはRSSリーダーである。

tips: 重要度の低いメールもFeedに入れる

FeedとLibraryにはそれぞれ、メールアドレスが割り当てられており、それぞれメールを送って本文を保存させることができる。

個人的に、Gmail上では「必ず読むもの」だけを扱いたいと思っているので、「できたら読みたい」程度のメールはFeedに入れることにしている。メールマガジンなどを入れるのが主な使い道だが、他だと connpass のイベント開催通知もFeedに飛ばしている。connpassは一度イベントに参加すると、その主催者のグループへ自動的に参加することになり、メール通知もデフォルト有効になっているのがちょっと面倒だったりするが、全部Feedに飛ばしてしまえばメールボックスはすっきりするし、必要なタイミングで読みやすくなった。

tips: 高優先度のRSSはフィルタしておく

Readwise Readerは様々なフィルタを通したカスタムビューが作れる。登録したRSSフィードは、それぞれ任意のカスタムビューに送るよう設定することができるので、高優先度のRSSはフィルタできるようにしておくと良い。数日間Feedを消化できなったときは、高優先度のものだけ目を通して、あとは消している。

保存

Libraryに記事を保存する。Feedやメールから保存するだけではなくて、 Pocket のようにブラウザの拡張機能からも保存できるし、PDF、ePubなどのファイルも保存できる。YouTubeの動画も保存できて、文字起こしもしてくれるので動画が苦手な人には便利、というのは前回も書いた。

閲覧

Libraryに保存したら、あとは順に時間のあるときに読んでいく。ちなみに、おそらく最近の変更なのだが、Libraryに保存するとGPT3.5による要約が自動的に付加されるようになった。

記事にはハイライトをしたり、コメントを入れたりすることができる。ハイライトは頻繁に入れておくと、次に書く「再読」の行程で役に立つ。コメントは面倒なのもあってあまり入れていない。コメント入れるほどなら、Scrapboxにメモを書いている。

tips: PDFを翻訳する

PDFはファイルそのままの体裁で読むこともできるが、文字列だけを抽出して表示する「Text View」にすることもできる。これの何が便利かと言えば、ブラウザ拡張のGoogle翻訳が使えるようになること。英語のPDFでもあっという間に全文翻訳できる。PDF翻訳にはDeepLを使ったりいろいろ試みてきたが、これが一番楽。

tips: しばらく読んでいない記事をフィルタする

先述の通りカスタムビューが作れるのだが、フィルタに使える検索条件がかなり豊富で、「最近読んでいない記事」をフィルタすることもできる。これを使って、しばらく読んでいない記事をフィルタして優先的に読んだり、一気に消したりしている。

具体的には以下のようなフィルタを使っている。Readwise Readerは各記事の「読んでいる位置」を記録しており、 progress__lt:1 でフィルタとすると、まったく読み進めていない記事を抽出できる。これと saved__before:"1 month ago" のAND条件とすることで、1か月以上前に保存したがまったく読んでいない記事がフィルタされる。

progress__lt:1 AND saved__before:"1 month ago" AND in:later

ちなみに、フィルタは様々な活用例が公式の Reader Filtering Guide にまとめられている。

tips: 要らない記事は消す

Libraryの中の記事はステータス管理ができて、読み終わったら基本的にはアーカイブすることになる。

自分の場合、読んだものの再読の可能性が低そうな記事については、アーカイブではなく削除している。これはReadwise Readerの検索機能が、アーカイブを含めてLibrary内の全記事を対象としているため。検索のノイズを減らしている。

tips: 読み上げ機能がある

モバイルだと読み上げ機能がある。日本語もOK。僕は耳からのインプットが苦手なのであまり使っていないが、PodcastやAudibleが好きな人には便利かもしれない。

再読

Readwiseで最も肝になるのがこの機能だと思う。

そもそもReadwise Readerは Readwise の付随サービスであり、Readerを使う際は自ずとReadwiseのアカウントを作ることになる。このReadwiseが何かと言えば、Kindle、Pocket、物理的な本などからハイライトを集めるツールであり、Readwise Readerのハイライトも自動的に収集してくれる。

Readwiseが面白いのはDaily Reviewと言って、過去のハイライトから指定した数だけピックアップして再読する機能があること。Daily Reviewは1日1回指定した時間に作られ、メールで受け取ることもできる。

この機能は 忘却曲線 の理論に則っている。忘却曲線は簡単に言えば「覚えづらいものほど早く復習すると覚えやすくなる」ものであり、Daily Reviewにおいては、これに従って各ハイライトを早めにもう一度表示させるか、しばらく間を空けるかを選択していく。RSSは「読んだら読みっぱなし」になることも少なくないと思うが、この機能のおかげで頻繁に見返すことができるのが良い。

tips: 物理的な本のハイライトも集める

物理的な本についても、ページを写真に撮ってOCRでハイライトを取り込める。日本語でもOK。

本の場合はハイライト箇所が多かったりするので、1冊分を取り込むとDaily Reviewがしばらくその本のハイライトだらけになったりもする。そういうときにはDaily Reviewへの出現頻度を調整もできる。

そのほか、自分が取り込んでいるのはO'Reilly LearningとGoogle Play Books。ただ、いずれも自動取り込みではなくて、手動でのエクスポート/インポートになる。Kindleがamazon.co.jp版には対応していないのが残念なところ。

tips: 翻訳状態でハイライトすると、そのまま取り込まれる

先ほど書いたようにGoogle翻訳で翻訳した状態でもハイライトができ、その場合は翻訳後の文字列がReadwiseに収集される。翻訳を解除すると該当のページからはハイライトの痕跡は消えるのだが、記録としてだけは残る。もしかしたらバグなのかも？とも思える挙動だが、見返すときは日本語のほうがやはり頭に入るので、結構積極的に翻訳してハイライトしている。

tips: ハイライトをNotionに送る

Readwiseに取り込んだハイライトを、自動的にNotionへ送り込む機能がある。あんまり有効活用はできていないが、Notionだと様々にビューを作れるのが利点だと思う。Obsidian、Logseqなどにも取り込み用のプラグインがあるらしい。

Readwiseで全部読む

以上、最近はこんな感じのサイクルでインプットをしている。特に「翻訳ができる」「ハイライトを復習できる」というあたりがキラー機能で、このサイクルに載せたいがために、PDFでもePubでもとにかく全部ツッコんで集約するようになった。ハイライトすれば後でまた読めるから、ざっくり読んで気になったところだけハイライトをしておいて、後で改めてじっくり読む、みたいな感覚にもなりつつある。

別にReadwiseからお金をもらっているわけでもなんでもないのだが、2回もエントリにするぐらいには気に入っているし、日本語圏でもっと流行って欲しくてかなり細かく書いてみた。おすすめ。

https://www.hashicorp.com/blog/terraform-cloud-updates-plans-with-an-enhanced-free-tier-and-more-flexibility

2023年5月より、Terraform Cloudで新しい料金体系が導入された。多くの人が使うであろう、Free tierと真ん中のStandard tierはリソース数に応じた課金（Freeはリソース数500までの制限）、という説明になっているが、パッと見では、何のリソースのことかよくわからない。

結論から言うと、Terraform Cloudに保存しているState上に記録されたリソース数の合計ということになる。要するに terraform state list で出てくるリソースの数ということになるのだが、 null_resource や data は含まないということで、ただそのまま数えればいいというわけではない。

https://dev.classmethod.jp/articles/tfc-pricing-resource/

こちらのClassmethodの記事にそのあたりは詳しく書いてあり、Terraform CloudのGUI上における数え方も記載されている。ただ残念なのは、まだ新料金体系で契約をしていない場合、課金対象となるOrganization全体のリソース数を直接見る手段がなく、各Workspaceのリソース数を1つずつ見て足し合わせるしかないということだ。Standard tierへ移行する前に、どの程度の料金になるのか見積もりたくても、そのための手段がないというのは、ちょっと不便だと思う。

というところで宣伝にはなるが、Terraform CloudのAPIを実行する tfcloud というCLIツールを以前から作っている。これの workspace view コマンドを使えば、以下のようにリソース数を始めとした情報を取得できる。何もオプションを付けずに実行すれば、カレントディレクトリのTerraformの設定を見て、そのbackendとなっているWorkspaceの情報を取得する。

$ tfcloud workspace view
Name:               test-a
Terraform Version:  1.6.2
VCS Repo:
Working Directory:
Execution mode:     local
Auto Apply:         false
Resource count:     1
Created at:         2023-05-05 00:16:03 (UTC)
Updated at:         2023-08-02 10:42:25 (UTC)
URL:                https://app.terraform.io/app/chroju/workspaces/test-a

すべてのWorkspaceの情報を一括で取得するなら workspace list コマンドを使えばいい。 --format json を付加すれば、全Workspaceの情報が単純に配列になった形の雑なJSON構造で落ちてくるので、こういう感じでjqを使えば一発でリソース数合計も取れる。

$ tfcloud workspace list chroju --format json | jq '[.[].resource_count] | add'
122

tfcloud、ローカルからTerraform Cloudの情報を取るのには結構便利で、自分用のツールとしてちまちまと使い続けている。最近 tfc-workflows-tooling という、Terraform CloudのAPIを実行する公式のツールも出てきたので、tfcloudはお役御免になるかなと期待もしているが、こちらは plan や discard を実行する、本当にワークフロー周りのAPIしか実装しないようで、しばらくはtfcloudが必要そうだ。OpenTofuの顛末を見ていると、これも名前を変えたほうがいいのかな、とちょっと思っている。

ちなみにX（旧Twitter）を緩やかに離れたいな、みたいな気持ちは別ブログのほうに以前したためた。わりとPleromaを使っていけそうなので、今後の投稿メインはゆるゆるとPleromaのほうに移していきたいと考えている。Mastodonやmisskeyをやっていたらフォローを是非。

https://chroju.hatenablog.jp/entry/20230709/without_twitter

Twitterから心が離れる理由を掻い摘まんで書くと。フォローしていない人のツイートを目にしやすくなったとか、TweetDeckが使えなくなった、といった「見る」側の問題がいろいろあった。一方で、自分は最近こんな記事を書いて、こんなことに興味がありますよ、というのを時系列で書いて「見られる」ためのツールとしては重宝していたのだが、それも最近の仕様変更で、ログインしていない人には時系列でユーザーページを見てもらうことも困難になり、自分の活動を示すパブリックなタイムラインとしても活用が難しくなった、というのが離れたい一番の原因。

Alt-Twitterに何を求めるのか

Twitterからの避難先はThreads、Mastodon、misskeyなど群雄割拠の様相を呈している。

避難先に求めることの第一はオープンであることだった。Twitterの仕様変更で、徐々に閉鎖的になっていくのが最もしんどかった。昨今の状況を鑑みると、特にActivityPubに対応していることを求めた。よってBlueskyやThreads（今後ActivityPub対応の予定があるとのことで、アカウントは取得したが）は候補にならなかった。

また、Twitterが運営者の一声でこうなってしまったことを考えると、第三者に運営を委ねるのではなくて、セルフホストするほうがいいのではないかと考えた。とはいえリソースを多く使うものは避けたいので、軽量な実装を調べた結果、行き着いたのが Pleroma だった。もちろん実際に使ってみないことには軽量かどうかはわからないが、いくらか先駆者の話を読んでみると期待ができそうに思えた。

• Pleromaはいいぞ - PartyIX
• 軽量MastodonことPleromaインスタンスを立てたメモ - Lambdaカクテル

Wildebeestというロマン

Pleromaを立ち上げる以前、 Wildebeest も一時期セルフホストして使っていた。これはCloudflareが開発していたActivityPub対応のSNSで、大きな特徴としてCloudflare WorkersをはじめとしたCloudflareスタックだけでホスティング環境が整う点にあった。最低月額$5というかなりの少額で運用が可能だった上、構築に必要なTerraformやCloudflareのコマンド実行もGitHub Actionsで定義されており、レポジトリをforkしてAPIキーなどを設定し、Actionを実行するだけで環境が整う、という手軽さがあった。

たださすがにいろいろと厳しかったようで、使ってみると様々な部分で動作が不安定であり、最終的には2023年7月にメンテナンス停止が告知された。エッジサーバーで動くSNS、というのは2023年っぽい実装ではあって期待したかったのだが、ロマンとして終わってしまった。

Pleromaのセルフホスト

インフラ

ホスティング環境としては、Kubernetes検証用に建てていたK3sを使っている。

PleromaはDockerイメージが公式には提供されていないのだが、READMEでいくらかサードパーティでの実装が紹介されており、そのうちの1つである angristan/docker-pleroma を使わせてもらっている。このレポジトリもイメージをビルドして公開するところまではしていないため、forkしてGitHub Actionでビルドすることにした。ほぼそのまま動いたが、設定ファイルである config.exs の「その他」に対するパーミッションが、最近のPleromaだと 0 になっている必要があり、その点だけ修正している（そういえばPRしても良さそうだ）。

- COPY ./config.exs /etc/pleroma/config.exs
+ COPY --chown=pleroma --chmod=440 ./config.exs /etc/pleroma/config.exs

なお外部公開には Cloudflare Tunnel を使っている。ngrokのようなものだが、Cloudflare DNSを使えば好きなドメインを当てることができ、最近の外部公開には全部これを活用している。K3sでcloudflaredをコンテナ起動させており、常時トンネルは開通した状態にあるので、あとはCloudflareのGUI側でどのドメインをどのポートにマッピングするかの設定だけで済む。

データの永続化

データの永続化については基本的にはRDBであり、PostgreSQLを使う。これについてもコンテナでまかなっている。一方でファイルシステムに書き込むものとして、 Static Directory と uploads がある。前者はフロントエンドで使う、例えばインスタンス全体の背景画像を設定できるのだが、そういったファイルが保存される。後者はユーザーが投稿した画像などの保存先だが、これはAmazon S3に変更することもできる。現状はそこまで画像を投稿するつもりもないのでローカルのままとした。いずれもPersistentVolumeを使い、フォルダパスは設定ファイル上で指定している。

config :pleroma, :instance,
  static_dir: "/var/lib/pleroma/static"

config :pleroma, Pleroma.Uploaders.Local,
  uploads: "/var/lib/pleroma/uploads"

config.exs

設定ファイルは /etc/pleroma/config.exs というものがあり、ここに基本的なものを書く。自分のインスタンスでは以下の設定をしており、K8s環境なのでConfigMapでマウントしている。

# Shoutboxという簡易的なchat機能を無効化
config :pleroma, :shout,
  enabled: false

# UIを通じたユーザー登録の無効化
config :pleroma, :instance,
  registrations_open: false,

# 画像アップロード時のオプション
# mogrify -stripによりEXIFを削除する
# ファイル名の難読化を行う
config :pleroma, Pleroma.Upload.Filter.Mogrify, args: ["strip"]
config :pleroma, Pleroma.Upload,
  filters: [Pleroma.Upload.Filter.Dedupe,Pleroma.Upload.Filter.AnonymizeFilename,Pleroma.Upload.Filter.Mogrify]

おひとりさま用なので、新規登録を受け付けないようにするのは重要なポイント。自分のユーザーを作るにはどうするのか、という話があるが、 pleroma_ctl というCLIが内包されており、 pleroma_ctl user new hogefuga hogefuga@example.com --admin で作成できる。このとき --admin を付与すると、後述する管理者ユーザーとして振る舞えるようになる。

その他、 Configuration Cheat Sheet - Pleroma Documentation 全体をざっくり見て必要な設定を施せばよい。

Admin FE

管理者ユーザーとしてログインすると、右上にタコメーターのようなマークが表示され、ここから管理者設定を触れる。多くは config.exs で設定できる内容ではあるが、一部はおそらくここからしか設定できない、あるいはここで設定したほうが簡単な気がしている。

僕が設定しているのは Settings > Others > Term of Service ぐらい。ToSはどうも一度Admin FEで編集しないと、 Static DirectoryにHTMLが出力されないように見える。

現状と感想

ホスティングの状況

現状、スワップを有効化したt4g.small上でK3sを動作させており、そこには別のアプリケーションも載っているのだが、インスタンス全体でのCPU使用率は10％にも満たない値で推移しており、だいぶ安定している。まだフォロー/フォロワー数も投稿数も少ないというのはもちろんあるが、予想以上にリソースを食べる気配がなくて嬉しい。Gravitonのおかげというのもある。

Static FEが好き

機能的にも、一般的に想定されるものはいずれも問題なく動く。Pleroma独特のところだとStatic FEというものが好きだ。これは設定でデフォルト無効になっているのだが、有効化すると、インスタンスに登録されているユーザーやポスト（status）のパーマリンクを開いた際、JavaScriptを用いない静的なHTMLで表示してくれる。

PleromaのみならずMastodonでもmisskeyでもそうだが、ブラウザからアクセスすると、当然ながらSNSのアプリケーションとしてのUIが基本的には表示される。しかし、このPleromaはおひとりさま用で建てているがために、僕以外の人にとってはここにアプリケーションとしての価値はない。ならばSNS的な要素を削ぎ落とし、読むことに特化した静的なページとして表示すればよい、というのは良いアイデアだな、と感じた。冒頭に書いた通り、僕はこの手のSNSを「パブリックなタイムラインとしての自分の活動」を示すために使っているので、このStatic FEはまさにうってつけだった。

TLをどう構築するか

おひとり様インスタンスなので不特定な投稿が乱入してくることはない。おすすめや広告の形で、フォローしていない見知らぬ人がTLに跋扈するようになったTwitterに比べてだいぶ快適になった。

一方で、逆に投稿が少なすぎて今は苦慮している。Mastodon界隈で付きものの「誰をフォローすればよいのかわからない」問題がある。Twitterでフォローしている人のActivityPubアカウントを探す手段もないし、自分のインスタンスには誰もいないので検索で探しようもない。あまり多量のフォローをする気もないのだが、日常的な情報収集も兼ねてもう少し欲しいところではあり、どうしたものかと考えている。

みんなどうしているのか。思いつくのはmstdn.jpのような大手のインスタンスで検索してみることぐらいだが。

Elixirわからない問題

PleromaはElixirで実装されており、Dockerfileを読み解くにあたってmixコマンドぐらいは把握したが、コードは読めないし、今後学ぼうという気も現状あまりないのがどうなんだこれは、というのはある。その点だとRuby製のMastodonは敷居が低かったのかもしれない。あるいはPleromaを建てた後で知ったが、 gotosocial というGoのActivityPub実装もある。

セルフホストしているとはいえ、Pleromaは他者が開発しているOSSであり、結局のところ誰かに依存している点から抜け出せてはいない。そのことを考えても、ある程度自分でコードを読み書きできるようになっておくべきだろうとは感じている。

あるいは自分でActivityPubを実装するか。最近 このブログがFediverseに対応しました や kayamatetsu.com のように、静的なブログのようなサイトでありながら、ActivityPubに対応する例もあり、これについても興味は惹かれる。少なくともどのようなプロトコルなのかはもう少し把握したい。

X（旧Twitter）との兼ね合い

Twitterをやめるということはないだろう、とは思っている。フォロー/フォロワーの関係性にしてもそうだし、Pleromaには現状人がいないので、災害時などに不特定多数の投稿から検索して状況を確認したい、という用途だと今後もTwitterの優位性は揺らがないんじゃないか。これ以上に人が集まるリアルタイムSNSが出てくる気はしないし、Twitterがそこまでユーザーを減らすこともなさそうではある。Threadsあたりか、どこかのmastodonインスタンスが超巨大になって、十分に代替可能になる、ということはあるかもしれないが。

ただ日常的な「SNS欲」を満たしたり、何かを自分がメインで投稿する場はPleromaにしていきたい、というつもり。

先日こんな記事を読んだ。僕もPlatform Engineeringについては多少なり追ってはいるが、正直よくわかっていないというか、いまいち捉えどころがないと感じている。このエントリーは現時点における自分のPlatform Engineeringに対する認識の覚書であり、間違っている部分も多々あるかとは思う。

原義

Platform Engineeringについて調べていると、Gartnerの「先進テクノロジのハイプ・サイクル : 2022年」での登場が発端であるとする記事が多く見られる。そのGartnerにおける プラットフォーム・エンジニアリングとは何か？ | ガートナー という記事から引いてみる。

プラットフォーム・エンジニアリングは、インフラストラクチャ・オペレーションの自動化とセルフサービス機能により、開発者エクスペリエンスと生産性を向上させます。開発者エクスペリエンスを最適化し、プロダクト・チームによる顧客価値のデリバリを加速させることが期待できるため、大きく注目されています。

ソフトウェアデリバリにおいて必要なインフラの構築を単に自動化するのではなく、開発者がセルフサービスで扱えるようにするというのがポイントだと捉えている。ここでは「インフラストラクチャ・オペレーション」と書かれているので、構築部分だけではなく、その後運用フェーズに入ってからのチューニングなども同様にセルフサービスとするのだろう。

ところで、僕が最初にPlatform Engineeringという単語を見かけたのは、Honeycombによる The Future of Ops Is Platform Engineering | Honeycomb という記事だった。先の2022年ハイプ・サイクルが発表された1か月後に書かれた記事だが、もともとHoneycomb内で実践していたプラクティスをPlatform Engineeringと名付けた、としており、Gartnerの発表との前後関係はわからない。

定義に大差はなく、「これは、サードパーティ プラットフォーム プロバイダーの運用スタックの評価と組み立てに特化しており、ソフトウェア エンジニアがセルフサービスでサービスを提供し、運用環境で独自のコードを所有できるようにします（Google翻訳）」「operations engineering minus the infrastructure」と書かれている。ただ、こちらのほうが、なぜこういったプラクティスが必要なのか丁寧に書かれており、納得感はある。曰く、開発者がコアとなる機能開発に集中できるようにするため、Platform Engineeringは、開発者がコードを実行するのに必要な作業をセルフサービスかつ、認知負荷の低い形で提供する。

IDPの必要性

昨今のインフラ、特にKubernetesを巡るエコシステムが相応に複雑化しているのは確かであり、これを開発者が直接的に取り扱うのではなく、ある程度抽象化して提供する、というのは理解できる。「operations engineering minus the infrastructure」はこれをよく表していると思う。

Platform Engineeringを追っているとよく言及されるのが、このプラクティスの実現にIDP（Internal Developer Platform）が必要である、ということだ。ツールとしてはCrossplaneやBackstageが挙げられることが多く、統一的なインターフェースであらゆるインフラを払い出せるようなものが想定されている。最近Terraform Cloudでも、moduleの変数をGUIから入力して展開するno-code provisioningがGAになったが、文脈としては同じものだろう。

確かに「開発者へ認知負荷低くコード実行環境のプロビジョニングを提供する」となると、こういったツールに収束していくのは理解できる。気になるのは、先のGartnerの記事において「プラットフォーム構築の初期段階は、最も成熟度の高い社内開発者ポータル (IDP) から開始することがほとんどです」と書かれているように、半ばIDPの利用がPlatform Engineeringの実践上不可欠であるかのような印象を受けることだ。この手のプラクティスが、あるツールの利用を必要条件とするのは、あまり好ましくないように思うし、例えばマイクロサービスでバンバン環境を立ち上げるような組織でもなければ、IDPを維持管理するメリットは大きくないように思える。IDPを使わず、ドキュメンテーションやその他のツール群によるアプローチもあり得るのではないかと思うが、IDPを使わなければPlatform Engineeringを名乗るべきではないのだろうか。このあたりが掴めない。

SREとの関係性

SREとPlatform Engineeringは基本的には無関係というか、後者が前者の発展系や一類型といった類のものではないと認識している。SREは信頼性が第一に置かれ、どちらかといえばシステムの運用に比重が置かれる一方、Platform Engineeringはシステムの構築段階における工数やコストの削減に対する関心が大きい。基本的な目的はそれぞれ異なる。

ただ国内においては、事実上SREチームが横断的なインフラストラクチャチームを兼ねている場合も少なくない。以前書いたEmbedded SREとは何か - SREの組織類型についての覚書という記事で紹介した、Googleによる「SREチームの組織類型」の中にも、監視システムを含め共通的なインフラ整備を行う、Infrastructure SREという類型が存在する。

そういった役割を内包したSREチームが、インフラ構築における負荷を軽減するために、Platform Engineeringを取り込んでいく、あるいはその役割を分離していくという考え方はあり得るように思う。言ってしまえば、Platform EngineeringはEliminate toilの一環ではあり、SREと目的が交差する部分も大いに存在する。Platform Engineeringには、その構築した環境がReliableであるべきだ、という話が出てくるわけではないが、当然ながらそれは求められるわけだし、むしろ標準化を進めるのであればReliabilityやSecurityを組み込んだPlatformであることは自ずと必要になる。SREとPlatform Engineeringは同じロールではないが、協力関係にはあると見ている。

個人的には class DevOps implements SRE という言葉にあんまりしっくり来ていなかった（結果的にSREの活動はDevOpsの実装に近くはなるが、DevOpsという言葉が目指していた方向性と、SREの方向性は微妙に違う気がしている）のだが、 implements Platform Engineering であればしっくり来る感がある。

Team Topologiesとの関係性

"Platform" と言われると、Team Topologiesに登場する "Platform Team" をつい思い浮かべてしまう。Team Topologoies（＝ちいとぽ）は2年前に日本語版も出版されて話題になった、システム開発に有用な組織設計を解説した本だ。そのなかに登場する4つのチームタイプの1つが「プラットフォームチーム」であり、その役割は「横断的に内部サービスを提供し、ストリームアラインドチームが下位のレイヤーを意識する必要性を下げる」と定義される。ちなみにストリームアラインドチームとは、「他チームへ引き継ぎを行わずとも機能をリリースできる職能横断的なチーム」であり、要するところプロダクトの開発チームにあたる（のが望ましいとされる）。

Gartnerの記事にはTeam Topologiesへの言及はなく、Platform EngineeringがPlatform Teamの考え方にインスパイアされたものなのかはわからない。Team Topologiesにおける「プラットフォーム」の定義は、Evan Bottcherによる What I Talk About When I Talk About Platforms に沿っていると書かれている。この記事ではセルフサービスでのプロビジョニングに言及されており、書かれている内容はほぼPlatform Engineeringだ。どちらかと言えば、先にPlatform Engineering的な考え方が存在しており、そこからTeam Topologiesがインスパイアされているように見える。

自分の場合はTeam Topologiesを先に読んでいて、SREの役割の一部がプラットフォームチームに転嫁可能だと考えていた。ただ、そこで実体としてのプラットフォームを伴うかは別だと思っていた。Team Topologiesにも「いちばんシンプルなプラットフォームは、下位のコンポーネントやサービスについて書いた単なるWikiページ上のリストだ」とある。一方でPlatform Engineeringには先述のようにIDPが必須かのような印象があり、こちらの指すプラットフォームは実体を伴う気がしている。そういった区分け方で正しいのかはまだわかっていない。

感想

自分の「しっくりこなさ」は、結局のところ何をしていればPlatform Engineeringと呼びうるのかがわからないという点にある。実体としてのIDPがあればよいのか。IDPがなくとも、Terraform Moduleなど何らかのツールやWikiによって、開発者のセルフサービスが実現してさえいればよいのか。最悪の話として、ウェブフォームに必要事項を埋めてPOSTすれば、その裏で誰かが人力で頑張っていたとしてもすぐに環境が払い出されたらそれでもプラットフォームと考えていいのか。そのあたりがわからないので、今のところ自分ではPlatform Engineeringという語を使うことは控えることにしている。

目的や考え方に関しては賛同するというか、中央集権的にインフラ管理を行っていれば自ずとここには行き着くだろう。開発者がすべての作業をセルフサービスできる、ストリームアラインドな在り方に近づくことは工数面でも認知負荷の面でも明らかな理想だ。その実現方法についてはIDPを使おうがなんだっていいじゃないか、と自分としては思う。インフラの新規プロビジョニングが年間に数えるほどしかないような組織で、IDPを抱えても仕方ないような気がしている。

いろいろと書いてきたが、繰り返しにはなるが考え方としては賛同するのだ。だからエッセンスとしては吸収していきたい。あるいはここで書いた考えに致命的な間違いがあって、本当のPlatform Engineeringはこうなんですよ！という話があって、それならば最高だ！という展開があるなら、それもまた望ましいと思っている。新しい考え方やプラクティスが生まれたときは、そういった議論があってこそだと思うので。

働く場所としての札幌という街

いろいろな意味で「札幌」を選んだのは正解だった。

端的に、この時期だと避暑地として最適。晴れていれば30度ぐらいにはなるので、「暑くない」というイメージをしていると肩透かしを食らうが、逆に太陽さえなければ涼しいのが良い。夜になると、半袖の上に1枚羽織らなければ肌寒く感じるほどで、特に今年の関東の猛暑を知った身だと快適としか言いようがなかった。湿度は数字の上だと、関東並にあるようだったが、あまり「蒸し暑い」と感じることはなかった。

非常にコンパクトなエリアに街の機能が集中しているのもいい。綺麗な碁盤の目状の街で、北は札幌駅から、南にある歓楽街のすすきのまでだいたい2kmぐらい、そのエリアに飲食店、企業、公共施設、公園などが集中している。今回は札幌駅とすすきのの真ん中あたりにあたる、大通駅の近くに泊まっていたが、徒歩で行ける範囲内に食事処、商業施設、様々なコーヒースタンド、公園、コワーキングスペース、 平日は21時まで開いている図書館 まであって何も困ることがなかった。

大通公園は最高だと思う。あんな大都会の中心に、あれほど広い緑地があるのは精神衛生にかなり良い。今の時期だと、仕事が終わったぐらいのタイミングがちょうど夕暮れどきで、コーヒーを買ってベンチで一息つくのがルーティーンになっていった。ちょうど自分の滞在期間にビアガーデンも始まってすごいことになっていた。

旅先で働く環境をどう整えるか

働く場所としてはほぼホテルを使い、少しだけコワーキングスペースを一時利用してみた。

泊まったホテルが昼間だとWi-Fiでも200Mbpsは出るところだったので、働く上では困らなかった。難があるとすれば椅子で、何の変哲もないホテルの椅子なので、何日か経つと腰以上にお尻が痛くなってつらくなった。頻繁に立ち上がったり、部屋から出て散歩したりするようになった。

尻の痛みに耐えかねて、というのもあってコワーキングスペースを一時利用した。都内でも使ったことはあるのだが、個人的にはそもそもあまり好んでいない。どうも不特定多数がいる場所で、それなりに秘匿性のある「仕事」という行為をすることが自分は向いていないらしい。また現状だと自分はマネージャー職なのでMTGが入ることも多く、MTGスペースの数が限られているコワーキングスペースでは働きにくさを感じる。

ただ設備が整っているのは確かであり、今回3日目に初めてコワーキングスペースでサブディスプレイを借りてみて、仕事の効率がガンガンに上がるのを感じた。椅子も仕事用のものがちゃんと備えられているので、座っていて身体が悲鳴を上げることもなかった。ワーケーションという長い期間の遠隔稼働においては、適宜コワーキングスペースを用いたほうがいいんだろうと思う。あるいはワーケーションではガチめな労働をするのはそもそも諦めるか。後者が正解のようにも思う。ディスプレイが小さくても出来る、MTGや思考、意思決定系のタスクに集中したほうがいいのかもしれない。

コワーキングスペースについては、今回いくつかの場所を使ったが、SAPPORO incubation Hub DRIVE が使いやすかった。丸一日使っても2200円でそれなりに手頃であり、壁を背にする席がいくつかあったり、ボックスタイプになっていたりする席がいくつかあるので、ショルダーハックもある程度防ぎやすい。

1日の過ごし方

現職はフレックス制の会社なので労働時間は自由に決められるが、普段の労働とリズムはほぼ変えなかった。

• 7:30〜8:30 朝食、身支度
• 8:30〜10:00 個人的な勉強
• 10:00〜18:30頃 労働
• 18:30〜 大通公園あたりでコーヒー飲んだりしつつ、妻と合流次第夕食

ちなみに妻は勤め先の札幌オフィスに一時的に席を借りていたので、日中は別々に働いていた。それもどうなんだ。お昼を一緒に食べた日もあったけれども。

「個人的な勉強」の時間は普段だと大学に費やしたりしているが、前述の「ガチめな労働をそもそも諦める」の一環でワーケーション中は諦めた。代わりに普段出来ていない思考系のタスクに費やした。これはそれなりに捗ったし、資料が足りなければ先述の図書館があったので、労働後に通ったりもしていた。

ここも結局「どこまでガチめに労働するか」だと思うが、今回はそれなりに普通に働こうと思っていたのでリズムを変えなかった。労働を少なめにしてリフレッシュを優先するなら、そういうのもありだと思う。今回は「私用のついで」のような滞在で、あんまり観光する時間もなかったので、リフレッシュしよう〜みたいなのがなくて、それはちょっと失敗だったかな、みたいな感覚もある。いろいろタスクをせねばならなくて、労働後にセコマで弁当買ってホテルで書類書いたりとかしていた。

持っていってよかったもの

洗濯ネット

働いたのは4日間だが、滞在日数は土日を合わせて1週間以上だったので、途中で洗濯をした。それにあたって洗濯ネットは持って行っていた。今回はコインランドリーではなく、部屋にドラム型洗濯乾燥機のあるホテルを借りたので、これも快適ポイントだった。部屋で仕事しながら洗濯できるのは時間の節約にもなる。

Corne Chocolate

Corne Chocolate を組み立てる、40%キーボードに目覚める - chroju.dev/blog からもう4年間愛用している携帯用キーボード。ロープロキーボードは持ち運びやすいのでおすすめ。

MOFT

https://www.moftjapan.com/collections/pc/products/moft-pc-stand?variant=42378051354881

超薄型のPCスタンド。そこまで高さが出せるわけではないが、これだけでもだいぶ働くのが楽になった。とにかく軽い、薄いというのがメリット。よくあるPCの裏側に貼り付けておくタイプだと、会社貸与のPCに使うには抵抗があるが、これは非粘着タイプもあるのがいい。

結果として、こういうスタイルで働いていた。

よかった店

丸美珈琲店

https://www.instagram.com/marumi_coffee/

札幌、総じてコーヒーのレベル高くない……？というのは今回の驚きポイント。なんか謂れがあるんだろうか、どうなんだろうか。探したらBRUTUSにそんな記事があった。

https://brutus.jp/sapporo_coffee1/?heading=1

なかでも今回良かったのが丸美珈琲店。ちょっと疲れているタイミングで入ったので、無意識にラテを頼んでしまい、「初めて来たのにラテにしたら豆の味がわからなさそう」と後悔しかけたのだが、牛乳に負けない豆の香りがあり、ラテってこんなに美味いものだったのか、と驚いた。

一夜干しと海鮮丼 できたて屋

東京にも展開している回転寿司 根室花まるが展開する定食屋。焼き魚やフライが中心。四ッ谷にも店舗があるらしい。焼きも揚げも、かなり肉厚な魚で食べ応えがあってよかった。

ノースコンチネント

食事の面だと、魚介もカレーも食べたけど、今回はここのハンバーグが一番美味かった。きっちり中まで焼かれた肉が弾力あって美味い。ソースがかなり濃いめで食欲をそそる。サラダもたっぷりで、もりもり肉を食べることへの罪悪感を消してくれる。おしゃれな見た目の店だが、これは白米に載せてわしわし食べることを推奨してるだろ？と言いたくなるような肉とソース。実際フォークとナイフは出てこなくて箸で食べるのがまたいい。おかげでかきこむようにガツガツ食べてしまう。とにかく美味しいので、滞在中2回行ってしまった。

セイコーマート

北海道のインフラ。せっかくなので、コンビニ寄るときはなるべくセコマを使った。パスタが120円ぐらいで買えるのは意味がわからないし、店内調理のホットシェフはだいたいどれ食べても美味い。「道産ポテトのフライ」が甘味の強い芋で美味しかった。

総じて

よかった。の、だけど、それは僕がもともと札幌という街が好きだったのもあるし、自分と関わりのない街で生活を営む、という行為が好きだったのもあり、ワーケーション自体がよかったのか、もろもろの要因が重なって「よかった」という感想になっているのかは自分でもわかっていない。そもそも自分は旅行が好きで、特に一人旅が好きで、それは自分とまったく関わりのない土地で、生活が営まれている、多くの人の人生が流れている、ということを実感できるのが好きであり、そのなかで一時的に場所をお借りして、自分も「生活」をする、ということは、旅行以上に楽しいものがあった。

ただ、あまりに普段通り「生活」しようとしすぎた、というのはある。ワーケーション、普段通りの生産性もパフォーマンスも出るはずないし、そもそも出すものでもないので、じゃあ何をするか？　ワーケーション中だからこそ出来ることは何か？というのを考えておくと尚良いのだろうな、と思う。

札幌に行くとだいたいエスタのLoft、ビッカメ、ユニクロあたりで忘れ物や足りないものの補充を毎回していたのだけど、それも今回で最後になるというのが寂しい限り。お世話になりました。ワーケーションは機会があればまたしてみたいが、札幌以上に居心地の良い街があるのかわからないので、また避暑で来年来てしまうかもしれない。

https://learning.oreilly.com/library/view/97-things-every/9781492081487/

『97 Things Every SRE Should Know』を読んだ。言うまでもなく「97のこと」シリーズのSRE版にあたる。

Amazonでレビューを見ると、かなり漠然としていて哲学的だ、という理由で☆1つになっている投稿があった。他の「97のこと」シリーズを読んでいれば予想はできると思うが、この本もまた、確かにある種漠然としたエッセイ集であり、具体的な実践Tipsではない。自分としては、ことSREに関してはむしろ積極的にエッセイが読みたい。『SREの探求』に書かれている、この一節が象徴的だと思う。

私の経験では、SREのような分野は、その分野の人々（すなわち現実の実務担当者）が互いに話し合うことで最も望ましく成長していきます。人々が集うことで、話し合い、議論し、笑い合い、自らの経験（成功と失敗）と未解決の問題を共有するようにするのです。会話が織りなす、賢く、親切で、多様性に富み、インクルーシブで、敬意に基づくコミュニティには、ある分野を他の何物にも代えがたい方法で進化させる効果があります。

『97 Things ...』のなかでも、「93. SRE in Crisis」において近しいことが書かれている。現状のSREは『SRE book』を参考としているものの、この本もまたあくまでGoogleにおける実践、プラクティスであり、科学的に何か裏打ちされているわけではない。例えば、なぜトイルの比率は50％以下がよいのか。別の比率ではダメなのか。Googleのプラクティスをそのまま真似をする必要はないし、むしろあれほどの規模の組織で、あれだけ優秀なエンジニアを抱えたSREチームを真似できるわけがない。

だから、SREは探求が必要であり、各企業やチームの状況に合わせて、SREをどのように「インストール」したのかが重要になる。それは必ずしも客観的な根拠に基づいたものではないかもしれないし、仮説を立てて、実践検証して、また別の仮説を立てていく、常に発展途上なものでもある。そういった試行錯誤している実践や、そこから得られた教訓や、各々の「SRE観」をまとめていけば、自ずと「エッセイ」と呼ばれる、ある種漠然としたものにはなっていくだろう。それで全然いいので読みたい。SREはエッセイを書くべきだな、というのを、本書を読んで強く感じた。千差万別な実践をそれぞれに言語化していくことで、初めてGoogleに寄らない、SREというロールの抽象化ができる。Google1社による実践の手を離れ、多くの企業での具体的実践を通過することで、SREについてはさらに次の論理が生まれていくんじゃないか。日本だと主観的なエンジニアの記事に対して、「ポエム」という表現が半ば揶揄を交えつつ使われることがあるが、あれは詩ではないし、「エッセイ」と呼んだら抵抗なくなるんじゃないかと思うが、どうだろうか ^1 。

以下、印象に残った章をいくつかピックアップしておく。

2. Do We Know Why We Really Want Reliability?

信頼性というものがそう簡単に割り切れるものではないことがよくわかる一節。拡大する市場で勝負を仕掛けているのであれば、信頼性の欠落により失う顧客よりも獲得顧客のほうが多く見込め、機能開発に対するインセンティブが強く働く。このように、常に信頼性が至上命題ではないなかで、どう向き合うか。

22. SRE, at Any Size, Is Cultural

タイトルだけですべてを言い表しているし、とても同意する。 State of SRE Report 2022 でも、 "SRE is a cultural change" と書かれている。

34. Storytelling Is a Superpower

SREの行っていることは "mystical" に見えがちであり、他のチームに対するストーリーテリングをすること、そういったスキルも重要であると説かれている。技術一辺倒の技術職ではないよな、というのは自分も感じている。

76. The SRE as a Diplomat

いわゆるEmbedded SREのようなプラクティスについて書かれている。ここではDiplomat、すなわち外交官に例えられており、ロールとしては "forward-deployed SREs (fdSREs)" と呼び表されている。

87. Important but Not Urgent: Roadmaps for SREs

重要だが緊急ではない。アイゼンハワー・マトリックスにおいては、最も多くの時間をここに費やせとされているが、「緊急ではない」タスクは積まれがちであり、なかなか消化されていかないジレンマ。信頼性がひどく劣化していたりしない限りは、どのSREチームでも「重要だが緊急ではない」タスクばかりが溜まっていそうであり、それに着手できていないとすれば、トイルの比率を考え直したほうがいいのかもしれない。

92. Risk and Rot in Sociotechnical Systems

組織というのはリスクを過小評価して、信頼性への投資を怠りがちである。SREはこれを避けるように組織を仕向けていかねばならない。

93. SRE in Crisis

先に言及した通り。

情報収集のためのアプリとして最近Readwise Readerを使い始めたのだが、これが結構面白い。一言で表すと「RSS ReaderとRead it laterサービスが一体化したもの」なんだけど、独自性のある機能が非常に多くて、言うなればデジタル上における「読む」という体験がここに集約できるようになっている。

Readwise Readerではエントリーを溜め込む場所として 「Feed」 と 「Library」 の2つが用意されている。前者がRSS Readerの役割を果たすものであり、後者がRead it later的な場所となっている。FeedにはRSS以外にも、専用のメルアドを通してメルマガを送り込んだり、TwitterのPublic List経由でツイートを送り込んだりもできる。

特に面白いのがLibraryのほう。Feedから「あとで読みたい」ものを送れたり、Pocketのようにブラウザ拡張から今開いているURLを送れるのは基本。それ以外にファイルも登録して読むことができる。エンジニアをしているとホワイトペーパーなどのPDFを読む機会も少なくないが、なかなか未読管理まではできていなかったりする。これをRead it later的なワークフローで管理できるようになるのが便利だ。アップロードできるファイル形式には他にePub、CSVなどがある。ePubについては目次が設定されていれば、ちゃんとそれも読み込んで使えるようになる。

飯って同じ料理食う回のアニメ観ながら食べるよね？ - YouTube

YouTubeのURLを登録した場合も面白くて、字幕をすべて取り込んでLibrary上で表示してくれる。日本語もイケる。なので、動画を「読むもの」に変換することができる。正直、動画によるインプットが苦手な質で、適当に飛ばし読みしながらザッピングできる文章のほうが好きなのだが、この機能によりある程度動画でもインプットが進むようになった。ちなみに、字幕上の任意の箇所をクリックすれば、その箇所から動画を再生してくれるという機能も付いている。

デジタル上で「読む」ものが集約できるというのはこのあたりであり、いろんなアプリを行き来しなくても、あらかたのものはここに突っ込んでおけばよくなった。

https://readwise.io

Readwise ReaderはReadwiseというサービスの派生サービスのようなものであり、親にあたるのはReadwiseだ。ではReadwiseはどのようなサービスかというと、PocketやKindleなどと連携させ、それらのハイライトを取り込んで集約できるというもの。取り込んだハイライトはReadwise上でタグを使って整理したり、反復学習の理論に則った間隔でリマインドメールを送らせたりして、記憶の定着を図ったりすることができる。Readwiseはこのような「読んだあと」にフォーカスしたサービスだったのが、「読む」フェーズまで取り込もうとしているのがReadwise Readerだと言える。

このような成り立ちもあり、Readwise Reader上でもあらゆる記事は当然ながらハイライトしたり、メモを書いたりすることができ、Readwise側へも自動的に取り込まれる。PDFでもePubでも、形式は問わない。YouTubeの字幕にもハイライトできる。

帝京大学通信課程での社会人大学生4年目を終えて - chroju.dev/blog

さらに面白いのが、Readwise Readerのブラウザ拡張を使っている場合。拡張を入れた状態で、すでにReadwise Readerへ登録済みのページを表示すると、ブラウザで閲覧しながらそのままハイライトすることができる。ハイライト箇所はもちろん相互同期されるので、よくありがちな「過去に見たページをもう一回探し当てた」ときにも、以前読んだ箇所がすぐに見つけられる。

また、属性情報に基づくフィルタリング条件を保存しておいて、ビューを自由に作れるのも嬉しい。初期設定では「1週間以内に開いたハイライト」や、「あとで読むに保存して、1週間以内に開いて途中まで読んだもの（最後に読んだ位置を保存してくれている）」といったフィルタが作られている。PDFやYouTubeの動画だけフィルタする、なんていう基本的なものもある。

今のところ新たに作ったのは2つで、「日本語の記事でまだ読んでいないもの」と「1か月以上前に保存したが、1か月以上開いていないもの」。英語の記事はPCでGoogle翻訳にかけながら読むことが多いので、外出中にサクッと日本語の記事を読みたいときに前者を使っている。後者はありがちな「あとで読む記事読まない問題」の対処として使うつもりでいる。

Readwiseは生まれてから5年以上は経っているようだが、Readerは2022年12月にPublic Betaになったばかりのまだまだ新しいサービスであり、不満や不具合らしきものもいくつか見受けられる。全体的にCJK周りの処理が甘いような感じはあり、検索でうまく引っかからなかったり、変換確定のEnterで投稿自体が確定してしまうといったものも見られる。日本人ユーザーが増えてフィードバックが増えれば改善も速まる気がするので、日本での利用も増えて欲しいところ。

利用には月額課金が必要になる。最終的にはReadwiseに内包されるような形になるようで、現在もReadwiseの有料プランを契約すると、Readerも使えるという形式になっている。GAした後は料金は上がる見込みだそうだが、Public Betaから使っているユーザーは据え置きになる予定だそうだ [^1] 。現状、これだけの機能を月$7.99で使えるのはなかなか安いんじゃないかと思っている。なお、最初の30日間はお試しで料金がかからない。

TwitterのAPI有料化をきっかけに、従来情報収集に使っていたMailbrewが使えなくなってしまった [^2] のを受けてReadwise Readerを使い始めた。Tweetでの情報収集がだいぶ厳しくなってしまった今、情報収集においてはRSS Readerが復権するんじゃないかな、という感覚が強い。

[^1]: "Regardless, we don't intend to increase pricing on existing full subscribers at that time. This means that if you subscribe while Reader is in beta, you'll get lifetime access for $7.99/month (billed annually) as part of our current Readwise Full plan." The Next Chapter of Reader: Public Beta

[^2]: もともと開発が低調ではあったが、2023年4月28日現在、開発チームから音沙汰もない。Twitter OAuthでのログインもできなくなり、締め出されたと訴えているユーザーも出てきている。 Login is broke | Voters | Mailbrew

インシデント対応に関するリソース

インシデント対応を専門として書かれたリソースは案外少ないかも知れない、というのはこの記事を書くにあたり、手元の資料を整理していて感じた。自分がこれまでに触れてきたものとしては、主に以下のものがある。

• ITIL
• Mike Julian (松浦隼人 訳) . 入門 監視. オライリー・ジャパン, 2019, 232p.
• PagerDuty Incident Response Documentation （※リンク先は有志による日本語訳）
• John Allspaw, Jesse Robbins, (角 征典 訳) . ウェブオペレーション : サイト運用管理の実践テクニック. オライリー・ジャパン : オーム社, 2011, 255p.
• Betsy Beyer, Chris Jones, Jennifer Peto, Niall Murphy (Sky株式会社 玉川 竜司 訳) . SRE サイトリライアビリティエンジニアリング. オライリー・ジャパン, 2017, 592p.
• Rob Schnepp, Ron Vidal, Chris Hawley. Incident Management for Operations. "O'Reilly Media, Inc.", 2017, 173p.

自分にとって、特に影響が大きいのはITILかもしれない。ITシステム運用について規格化されたものでは最も知名度があるし、もともと固めの運用に従事していた経験が長いこともあり、v3の頃にCertificateも取得している。

ITILは参考になる一方、厳密に則るとそれなりに運用コストもかかる、「お堅いもの」という印象が否めないのも確かだ。『入門 監視』の中でも、「ほとんどのチームにとっては、このような正式な方法はやりすぎ」として、ITILをそのまま使うのではなく、シンプル化して導入することを促している。僕もそれが現実的な落とし所だと思っている。ITILは残念ながらリソースがオープンなものではないので、そのエッセンスを取り込むなら『入門 監視』を参考にするのがいいかもしれない（余談だが、O'Reilly Online Learningの読み放題のなかでITIL Foundationの日本語訳が読める。これだけで12000円するし、通常販売されているのは物理書籍だけのようなので、ここで電子版を読めるのはちょっとお得）。

PageDuty Incident Response Documentationは、PagerDutyが社内のインシデント対応ドキュメントを縮小して公開しているものにあたる。ITILを除けば、ここに挙げたものの中では最も具体的かつ実践的な内容にまとまっている印象を受ける。

『ウェブオペレーション』『サイトリライアビリティエンジニアリング (SRE book)』はいずれも一部、インシデント対応に言及した章がある。包括的に運用、DevOps、SREに関してまとめた本なので、記述量は他のリソースには劣る。

最後の『Incident Management for Operations (IMO)』だが、これは今回のエントリーを書くにあたって初めて目を通した。SRE bookとPagerDuty Documentationを改めて読んだところ、双方が参考にしているものとして、アメリカの災害対応を標準化したIncident Command Systemや、それに基づいて制定されたNational Incident Management System (NIMS)が挙げられていたのが目にとまった。そこでNIMSについて調べていたところ、『Incident Management for Operations』もまたNIMSを元にしたインシデント対応の方針をまとめたものとなっていたため、あわせて参考とした。少しページ数は少ないO'Reillyだが、丸1冊をインシデントレスポンスに割いているだけあって、記述は非常に詳しい。

以下では、これらのリソースを参照しつつ、最大公約数的にプラクティスをまとめていく。

インシデントとは何か

そもそもの「インシデント」という単語の定義は以下の通りとされている。表現は異なるが、ほぼ同じ意味に取れる。

• 「サービスの計画外の中断、またはサービスの品質の低下」（ITIL）
• 「計画していないサービス停止やパフォーマンス劣化」（PagerDuty）

逆に「何がインシデントではないか」だが、ITILにおいては「インシデント」と「問題」が分離されており、後者はインシデントを引き起こした潜在的な原因である。つまり、症状がインシデント、原因が問題と、別概念として捉えられている。これらの管理プロセスが分けられている意図としては、サービスの中断や劣化という「事象・症状」の復旧は第一に優先するべきであり、その根本的な原因の解決は優先順位的に劣後する、という点がある。SRE bookでも同様に、「止血」や回復を優先せよという記載がある。

また広義のインシデントを分解し、「重大インシデント」と「セキュリティインシデント」という枠を設ける場合がある。重大インシデントは、事業に重大なインパクトをもたらす（ITIL）ものであり、複数のチームの協力（PagerDuty）などが必要となり、セキュリティインシデントは攻撃の遮断といった、通常のインシデントとは別の対策が必要になるなど、いずれも「狭義のインシデント」とは別の管理フローを設けるべきとされる。

オンコール

「call」と言われると日本人としては電話を想像してしまうが、電話に限ることなく、インシデント発生の通知とその受信行為全般を「オンコール」と呼ぶ場合が多い（入門 監視、PagerDuty、SRE book）。

オンコール担当とは、その名の通り通知を最初に受ける担当者である。オンコール担当は通知を受けことするが、必ずしもそのままインシデントの解決まで担当する者を意味しない。多くのリソースでは、解決においては適切な担当者へエスカレーションすることが求められている。

誰もが、全てを知っているわけではない。 チーム全体で手助けする。 確信がもてない問題をエスカレーションすることは、恥ずべきことではないし学びもある。 私たちのモットーは「エスカレーションをためらわない」（PagerDuty）

オンコール担当がひとりぼっちだということではありません。オンコール担当が知らないことや解決できないことに対しては、エスカレーションパスが必要なのは間違いありません。（入門 監視）

通知手段

オンコールにどのような手段を用いるかについては、リソースにより少し記述が分かれる。受信箱がいっぱいになり、アラート疲れを引き起こしやすいとして『入門 監視』ではメールの使用を避けろとしているが、PagerDutyはメールを「最初の通知」として推奨している。

優先度により、通知先や通知手段は分けておくことが推奨される。即時アクションが必要であればSMS、電話などを利用し、そうではない低優先度のアラートでは人々を目覚めさせてはいけない（PagerDuty）。また高優先度のものについては、誰かが応答するまで繰り返し通知するという手法もある。

ローテーション

オンコールは基本的には忌避されるものであり、心身への負荷が高いため、担当のローテーションが推奨される。

• プライマリ、セカンダリなど常に複数人で待機する（PagerDuty、ウェブオペレーション）
  • 『入門 監視』はオンコールシフト期間が長くなるとして、これを推奨していない。プライマリ担当者がオンコールを受ける責任があるとしている。
• 対応で困った場合はためらわずエスカレーションしてサポートを請う（入門 監視、PagerDuty）
  • 場合により、最初に通知を受け付ける担当と、詳細な対応をする担当を明確に分ける。いわゆるヘルプデスク、サービスデスクの考え方（ITIL、ウェブオペレーション）
• 会社規模が大きければ、タイムゾーンにより時分割を行うFollow-the-Sunを導入する（入門 監視）
• オンコール担当への補償として、担当直後の休暇や、金銭的な手当を検討する（入門 監視）
• ソフトウェアエンジニアもローテーションに入れる（入門 監視）
  • 運用担当への「丸投げ」を避ける意図。

トリアージ

インシデントの通知を受けたあとの最初のステップとして、事象の認識と、優先度や深刻度に応じた分類、トリアージを行う（ITIL、PagerDuty、入門 監視、ICS）。これはビジネス・インパクトの大きな事象を優先的に対応できるようにするため（ITIL）である。深刻なインシデントの場合には、社内外への広い伝達や、複数人での協力体制を敷くなどの相応の対応が必要であり、そういった対応の必要性を迅速に判断するためにトリアージを行う（PagerDuty）。

インシデントの具体的な分類方法については、PagerDutyのドキュメントに端的な例があって参考となる。IMOでもどのようにインシデントを抽象化して分類するか、細かい説明がされている。いずれにおいても判断材料とするべきは症状（影響範囲や停止時間など）とされており、よりインパクトの大きいインシデントでの迅速な対応を可能にすることが求められる。そのため精緻に分類することよりも、早期に分類を判断して行動を開始することを勧めている。

役割分担

先述の通り、インシデントはオンコール担当が必ずしも1人で担当するわけではなく、必要に応じてエスカレーションして複数人で対応する。この際、役割分担を行うことが推奨される。

直感には反することですが、責任分担をはっきりと分けることによって、一人一人が自律的に動けるようになります。これは、同僚の動きを予想しなくてもすむようになるためです。（SRE book）

主な役割としては以下のものがある。

• インシデント指揮者（IC, Incident Commander）。全体の状況把握、指揮・監督、決断、委譲していないその他すべての役割（PagerDuty、入門 監視、SRE book、IMO）
• コミュニケーション調整役（Liaison）。顧客や社内のステークホルダーにインシデントの最新状況を通知する。窓口を限定することで、インシデント解決に取り組む者を集中させる目的もある（PagerDuty、入門 監視、SRE book、IMO）
  • PagerDutyでは、社内向けと社外向けで別の担当を置くことを勧めている。
• 記録係（Scribe）。発生した事象や、インシデント解決のために実行した作業を時系列で記録する（PagerDuty、入門 監視）。
• 実行担当（SME, Subject Matter Expert）。実際にインシデントの解決を担当する。英語の名称通り、ドメインエキスパートを当てる。複数人で作業が重複したりしないよう、解決作業にあたるのはSMEに限定する（PagerDuty、入門監視、SRE book、IMO）。

通常時とインシデント時の役割は一致しない

「指揮者」という性質上、ICをシニアメンバーや上長に割り当てたくなるが、その必要はなく、どの役割に誰を割り当ててもよい（PagerDuty、入門監視、IMO）。そのためにも、なるべく持ち回りでそれぞれの役割を担当したり、平時に障害訓練を実施したりして、すべての役割に慣れておく必要がある（PagerDuty、SRE book）。

インシデントの解決

解決においては、以下のようなプラクティスが推奨されている。

• リアルタイムに状況をまとめる。
  • タイムスタンプと関係者に関する情報を含める（ITIL）
  • 複数人が並行で編集できるWikiなどを用いる（入門 監視）
  • Slackに状況を書き込んでいく（PagerDuty）
• 迅速な情報共有のための通話と、記録のためのチャットの双方を用いる（PagerDuty）
• ICはSMEの助言のもと、すばやく判断することが求められる（PagerDuty、IMO）
  • 常に状況を観察し、定期的に深刻度の再評価、状況の連絡指示を行うレビュープロセスを設ける（PagerDuty、IMO）
• 優先順位は「出血を止める」、サービスを回復する、根本原因の証拠を保存する、の順である（SRE book）
  • 「出血を止める」という言い方が抽象的でわかりづらいが、『ウェブオペレーション』では、問題が起きているコンポーネントを切り離したりなどして隔離する「封じ込め」というプロセスが最優先とされており、これと同等のものと考えられる。
• パニックに陥らない、解決が困難なら追加支援を求める（PagerDuty、SRE book）

クローズ

インシデントの解決、クローズについてはあまり言及が多くない。

• インシデントの解決 = インシデント発生前の状態へ復旧したかどうか、はICが判断する（PagerDuty、IMO）
• ステークホルダーへ連絡する（PagerDuty、IMO）
• 根本的な解決ではなく、一時的な修正、復元である場合は、インシデント解決後に今後の対応を判断する（IMO）
  • またインシデントが長引く場合には、対応者を交代することがある。その際、ICは次の担当者へ適切に引き継ぎを行うことが求められる（SRE book、IMO）。

ポストモーテムプロセス、事後レビュー

インシデントの解決後、発生事象のフォローアップを行う（all）。このプロセスは、近年ではポストモーテムと呼ばれるドキュメントの作成プロセスとして扱われる（PagerDuty、入門 監視、SRE book）。単に事後レビュー（IMO）と呼んだり、ITILでは先述のとおり「問題管理」という、インシデント管理とは別プロセスとして扱われたりしている。

ポストモーテムプロセスは、発生した問題の理解を促すこと、根本原因を分析してインシデントの再発を防ぐこと、それらを通じて会社全体に学びの機会を提供することを目的としている。

ポストモーテムの記載内容

以下はPagerDutyとSRE bookによる。

• 発生事象のサマリ
• 影響（時間、ユーザー数、SLA違反状況、発生したサポートリクエスト数など、具体的数値で書く）
• 解決した方策、行った対応
• インシデントの根本原因
• タイムライン
• アクションアイテム（インシデント解決、根本原因修正のために行ったすべての対応チケットのリンク）

ポストモーテムレビュー

ポストモーテムは単に記載するだけではなく、レビューを行う。

SRE bookにおいては、下書きの状態でシニアエンジニアが評価し、その後メーリングリストなどで広範な共有を勧めている。

PagerDutyや『入門 監視』においては、同期的なミーティングによるレビューを想定している。参加者は利害関係のあるすべての人（入門 監視）であり、インシデントに関わったエンジニアや対応者、サービスオーナー、影響のあったシステムのマネージャーらが含まれる。

早期に再発防止策を採る必要があるため、レビューをいつまでに行うかあらかじめルール化することも求められる。『ウェブオペレーション』では24時間以内、それが難しければ1週間以内としており、PagerDutyでは最も深刻なSEV-1では3営業日以内、SEV-2では5営業日以内としている。

レビュー観点は以下のような点である。

• インシデントの詳細や原因が十分に分析されているか？（SRE book、PagerDuty）
• 根本原因は十分掘り下げられているか？（SRE book、PagerDuty）
• 今後のアクションプランは適切か？（SRE book、PagerDuty、入門 監視、ウェブオペレーション）

ベストプラクティス

• 誰かを非難することや、ヒューマンエラーに帰結させることを避ける（all）
• 誰が読んでも理解しやすいよう、略語などは使わないか、使う場合は説明を付記する（PagerDuty、IMO）
• 事実を正確に記述し、仮定や不正確な表現を用いない（PagerDuty、ウェブオペレーション）
• 効果的なポストモーテムを書くことは賞賛されるべきである（SRE book）
• 過去の興味深いポストモーテムの読書会などを開き、積極的に学びを広める（SRE book）

Conclusion

いずれも大きな方針としてはそれほどずれていない。オンコールの負荷に留意すること、インシデントの深刻度を適切に見極めること、役割分担を明確にすること、非難のないポストモーテムプロセスで再発を防ぐことなどはいずれのリソースでも言及のある事柄だった。一方で細かな部分では当然ながら差分があり、一部では真逆なことが書かれていたりもする。『入門 監視』がITILをシンプルな形で導入することを勧めていたように、絶対的な正解を求めずに、自分たちの状況に合わせて適切なフローを構築する必要性がある。

また、この分野で規格化されたものはITILぐらいであろうと思っていたが、NIMSを参考としているものがアメリカでは少なくない、というのは新たな発見だった。機会があれば原典にも当たっておきたい。

単位修得状況

| 評価 | 2年次 | 3年次 | 4年次 | 5年次 | | :--: | :---: | :---: | :---: | :---: | | S | 8 | 2 | 4 | 2 | | A | 12 | 8 | 6 | 8 | | B | 4 | 4 | 6 | 4 | | C | 0 | 4 | 0 | 0 | | 合計 | 24 | 18 | 16 | 14 |

順調（？）に年間の修得単位数は減ってきており、もう少し取っておきたかったのが正直なところ。ただ、今年は全4期のうち、最後のIV期は試験日程が合わずに受講しなかったため、例年の75%の期間でこれだけ取ったと思えば及第点か。

残り20単位で卒業できる。来年度でギリギリなんとかできたら嬉しいが、こう見ると若干厳しそうにも思えてくる。が、とりあえずは来年度での卒業を目標にしている。

初めて通学機会がゼロに

通信課程と言えど原則的に試験は対面実施なのだが、コロナ禍ではオンライン試験に切り替えられることが多く、2022年度はついに帝京大学への通学機会がゼロで終わる初めての年になった。正確には対面試験自体は実施されたのだが、系列の帝京平成大学中野キャンパスが会場となり、帝京大学へ行くことがなかった。なぜ会場が切り替わったのか、背景は説明されておらずわからない。ファミマでよく耳にする例の大学にまさか自分が行く機会があるとは思っていなかった。

とはいえ、22年度を通じてオンライン試験が主になったことについては良かったと思っている。もともと試験のオンライン実施については、緊急事態宣言もしくはまん延防止等重点措置が発令されていることが条件だと大学側から宣言されていたのだが、22年においては感染者数、死亡者数、病床使用率などが従来と同程度の水準になってもこれらの措置が取られることなく、客観的な条件としてはもはや意味を成していなかった。特に昨夏の第7波においては自分の周囲でも感染者がかなり増え、自身が濃厚接触者になって試験に向かえない事態になることをかなり恐れたのだが、結局のところ大学側は感染状況を踏まえて柔軟にオンライン化の判断をしてくれるようになった。思えば弊学は医学部を有し、板橋キャンパスにおいては大学病院が併設されてもいるので、感染症に敏感な部分もあったのかもしれないと想像する。

なお、23年度に関しては早々と全面オンライン試験化が発表されている（恒久的な話なのか、一旦1年間の話なのかはわからない）。このままいくと卒業まで二度と通学しなくなりそうで、さすがにそれは嫌だなぁという思いもあったりはしている。

試験日程とプライベートの兼ね合い

先述した通り、22年度は年度はじめの時点でIV期の試験日に予定が入ってしまっており、全体の4分の3の期間で単位修得を狙うしかなかった。こういった事態は4年目にして初めてだったが、社会人大学生をしていると当たり前のように生じる話ではあり、難しさを感じるところだった。例えば年末など、時期的に勉強時間を取るのが厳しい「期」というのはこれまでもあったが、試験日が空かないとなるともはやどうしようもなくなってしまう。

丸々1期分空いたのはメリットでもあって、例年年末年始休暇にレポートを頑張り、2月頭まで勉強していたのが、今年は12月頭までで大学から解放されたので、他のことにかなり時間を使えた。

とはいえ自分も若くはなくなってきており、仕事というよりはプライベートに比重を置くべき場面が増えてきてもいる。そういったことを鑑みても、早めに決着をつけたいな、と思う5年目を迎えている。

受けて良かった科目

今年は電気回路、電磁気学などの計算機関連以外の科目をかなり取っていたので、直接的に「よかった」と言えるのは以下2つぐらい。電気回路の知識などは、自作キーボードで電子工作に手を出しているので面白くはあったものの、正直1年後には忘れてそうな気がしている。

情報セキュリティ

共通鍵暗号、公開鍵暗号のような基本から始まり、ゼロ知識証明、Information Hiding、ISO/IEC 15408といった、自分がそれほど知見のない部分にまで絡む内容で純粋に勉強になった。各種暗号のアルゴリズムなどを実際に数学的知識を使って簡単に解いてみるような力も求められるので、結城浩先生の本などで「概念は知っている」という程度で済ませていた間隙を突かれた感じもあった。

システム科学

いまだに「システム科学ってなんですか？」と聞かれると答えづらくは感じるが、これも広範かつ興味をそそられる内容で楽しかった。UMLやPERTなどを用いたシステム計画技法、数理計画法などによるシステム最適化、システム信頼性、さらには複雑系の概念やゲーム理論まで取り扱った。

面白かったのはジョン・フォン・ノイマンがかなりフィーチャーされていたことで、彼の業績をまとめる課題があったので、いろいろと自主的に調べたりもしていた。この道にいればノイマンを知らないということはなかったが、ゲーム理論の確立にまで関わっていたことなど、把握できていないことも少なくなかった。システム、コンピュータというものの成り立ちを紐解くと、やはりノイマンを避けられないのだなと改めて思った。

https://blog.serverworks.co.jp/aws-services-to-be-omitted

この記事の言わんとするところはすごくよくわかる。AWSで構築したシステムの「構成図」は何度も描いてきたが、描いているうちに「どこまで描くべきかな」「ここは省略してもまぁいいか」などと独りごち、最終的にそれっぽいものが完成すれば、なんとなく背徳感を覚えつつも「これでいいか」としてしまったことは何度もある。

とはいえ構成要素を全部盛りにすればいいのかと言えば、そうも思わない。先の記事の最終形の構成図を見ると、それなりにAWSを知っている人でも一瞬ひるむんじゃないかと思う。この記事にしても、省略せず全部描け、という趣旨なわけではなくて、省略しちゃうものって実は結構ありますよね、というスタンスだ。

今後 AWS 構成図を見るとき「書いてないけど実は裏に色々なサービスがいるんだったよな」と思い出していただけますと幸いです。

要するところ、「構成図」とは何を描くものなのかの定義が現代においては曖昧になっている気がしている。

「現代においては」、と書いたが、僕の記憶を辿っていくと、昔はそんなことはなかったし、今でもオンプレであれば迷いなく「構成図」は描けると思う。僕にとって「構成図」という単語から連想されるのは物理構成図と論理構成図だ。この2つは定義がしっかりしており、確かIPAの試験でも出てきたはずだ。

一応書いておくと、物理構成図とは文字通り、システムを構成する物理的な機器の接続などを示した構成図だ。単にこのサーバとこのスイッチが繋がっているよ、という程度にとどまらず、24ポートスイッチのこのポートと、サーバの増設したほうのNIC（「NIC」って書いたの何年ぶりだろう）を繋いでますよ、というところまで図示したりする場合もある。そのために機器ベンダー各社がVisioなどで使える自社製品のイラストを配布していたりするぐらいだ。

論理構成図は論理的なネットワーク、主にはL3のIPネットワークに関して示す。物理的な結線だけを見ても、その上でどのようなIPネットワークが構成されているかはわからないので、ここでVLANが切られていて、サーバには3つNICがあるけどそれぞれ全部違うネットワークに脚が出てますよ、みたいなのを記す。

物理構成図はL1と2、論理構成図はL3を表すわけで、「何を描けばいいか」がハッキリしているし、その目的もわかりやすい。物理的な障害が起きていれば物理構成図を見ながら実際の結線を確認したりするし、機器の設定がおかしいようであれば、実機の状態と論理構成図を照らし合わせたりしていた。

オンプレの時代からクラウドの時代に移り、物理/論理という2種類の構成図は意味を成さなくなってしまった部分がある。論理構成図についてはまだ描きようがあるかもしれないが、真面目にAWSで論理構成図を描こうとすると、Lambda@EdgeはリージョナルエッジだけどCloudFront Functionsはエッジロケーションに描きわけるとか、ELBに紐つけたAWS WAFってVPC内にはないけどどこに描きましょうねとかいろいろ辛くなってくる。そもそも自分たちで構築したネットワークを把握する目的で論理構成図を描いていたわけで、AWS管理下で上手い具合にやっているところを構成図に落とし込みたいかというと、なんか目的感がズレている気にもなってくる。

ということで、クラウド時代にはクラウド時代としての「構成図」が要るんだとは思うが、物理/論理のように一般化されたクラウド向け構成図概念というものは僕の知る限りでは存在しない。各クラウドベンダーともアイコンは配布しているし、diagrams.netのようなサービスがあるぐらいで、みんな図を描いてはいるわけなのだが、物理/論理を描いていた頃に比べると何を描くのかがどうしてもふわふわしちゃうな、という落ち着かなさをずっと覚えている。

試しにググってみたが、AWS公式の AWS のアーキテクチャ図を描きたい ! でもどうすれば良いの ? - 変化を求めるデベロッパーを応援するウェブマガジン | AWS においても「アーキテクチャ図ではみなさんが「何を伝えたいか」によって図の描き方や図の粒度などの表現を自由に変えて良いと私は考えています ! 」と書かれていた。まぁそうだよね、という気はする。冒頭の記事を見ていて、どの段階の構成図がしっくりくるかは人によっても違うと思う。しっかり全部描いたほうがいいと言う人もいるだろうが、僕としてはルートテーブルやインスタンスプロファイルがそこにあるだろう、というのは経験から推測できるので、別に構成図に欲しいとは思わない。でもインフラにそれほど詳しくない人は欲しいと思うかもしれない。

だから「ここまで描きますよ」という合意の下で、みんなそれぞれの「構成図」を描いていくしかないのだろう。そして冒頭の記事の通り、「省略しているものがありますよ」という了解もまたとても重要だと思う。しかしまぁやっぱり、どこか落ち着かない。

This may introduce issues with registry and runtime support (e.g. GCR and Lambda).

という注意書きがされており、一部環境で問題が起きる可能性がある。GitHub Actionsでバージョンをマイナー、パッチバージョンまで指定せずに使っていた場合、自動的にこのバージョンが適用されるため、実際に問題になったという声もTwitterで散見され、自分も一部で引っかかった。

@GitHub Actions runner bumped @Docker buildx today, which has default provenance on. It's a nice feature, but many registries do not support it including google container registry.

All builds broke, and had to disable provenance.https://t.co/wp0TsgAJi8 pic.twitter.com/eH0uv3fkZp

— Sigurd Fosseng (@fosseng) January 20, 2023

（2023-01-31 追記）

その後v3.3.1で、 provenance オプションはデフォルト無効化に切り替えられ、改めてデフォルト有効化はv4.0.0でメジャーバージョンアップとして取り入れられた。

参考 : Disable provenance by default if not set by crazy-max · Pull Request #781 · docker/build-push-action

（追記ここまで）

SLSA Provenanceとは何か

provenance: true を設定すると、Provenance attestationなるものが出力されるようになる、と書かれている。ドキュメントとしては Provenance attestations | Docker Documentation に記載があり、ここでは SLSA Provenance schema, version 0.2 に従ったものが出力されるのだとされている。

SLSAは、Supply chain Levels for Software Artifactsの略である。ソフトウェアのサプライチェーン、つまり開発からビルドを経てデプロイされるまでの一連の過程において、外部の攻撃からその完全性を守るためのフレームワークがSLSAである。これはGoogleによって2021年に提唱されたものであり、背景などに関しては以下の記事が詳しい。例えばCI環境の汚染など、この分野での脅威は近年増加傾向にあるのだという。ちなみにSLSAの発音は「サルサ」だそうだ。

https://security.googleblog.com/2021/06/introducing-slsa-end-to-end-framework.html

SLSAには4つのレベルがあるが、このうち最も低いレベルであるSLSA 1で必要とされるのが、ソフトウェアのビルドプロセスに関するProvenance、すなわち来歴の情報をメタデータとしてアーティファクトに添付することだとされている。

Buildkit 0.11でのProvenance attestation対応

Dockerのビルドにおいては、2023年1月に buildx v0.10.0 でSLSA Provenanceへの対応が盛り込まれ、このbuildxを内包した Buildkit v0.11.0 が同じ月にリリースされた。

https://www.docker.com/blog/highlights-buildkit-v0-11-release/

このバージョンでは --provenance true オプションを docker buildx build に付与することにより、Provenanceを生成してイメージに添付できる。冒頭のdocker/build-push-action v3.3.0における provenance オプション追加は、これを受けてのものである。

なお、手元のdockerでもこのオプションを試したかったのだが、macOS上でもUbuntu上でもエラーになってしまったので、残念ながらまだ試せていない。

Attestation Storageの仕組みとレジストリ等の対応状況

Provenance attestationのイメージへの添付においては、 Attestation Storage という仕組みが使われている。

DockerやOCIによるコンテナの仕様においては、image manifestと呼ばれるイメージのメタデータを格納する仕組みがある。さらに複数のmanifestの参照情報を保存する仕組みもあり、OCIでは image index 、Dockerでは Manifest List (fat manifest) と呼ばれている。例えばmulti-platform imageの場合、各platformごとにmanifestが生成されるので、これらがimage indexの中で取りまとめられる形になる。image indexについては、 buildx imagetools inspect コマンドで確認ができる。

❯ docker buildx imagetools inspect docker/buildx-bin
Name:      docker.io/docker/buildx-bin:latest
MediaType: application/vnd.oci.image.index.v1+json
Digest:    sha256:08625f48a68bb050f54b1840b5cab728ff3f086fd00f1fb08389f4b1cb9db221

Manifests:
  Name:        docker.io/docker/buildx-bin:latest@sha256:aecb1ff186197954361752564c04e73a464f0132fa15ac31a36d70580d8eba82
  MediaType:   application/vnd.oci.image.manifest.v1+json
  Platform:    darwin/amd64

  Name:        docker.io/docker/buildx-bin:latest@sha256:3ac63f40838fb8c2170b2d96bb5fadbffb5854ad3868c117016bbe73dee9b0d7
  MediaType:   application/vnd.oci.image.manifest.v1+json
  Platform:    darwin/arm64

  Name:        docker.io/docker/buildx-bin:latest@sha256:caf1d5f0527f5a9e7ce7ac8bb0c2b065567e3cc2dee9d5c4ddf1589f4f59b959
  MediaType:   application/vnd.oci.image.manifest.v1+json
  Platform:    linux/amd64

Attestation Storageはこのmanifestを活用して保存されており、image indexにもその情報が記載される。

しかしながら、一部のコンテナレジストリなどは、Attestation Storageに対応できていない。より具体的にはmulti-platform imageに対応していない場合があるのだが、それはすなわちimage indexに対応していないことを意味しているようで、そのためAttestation Storageを使っているimageも起動できないようだ。GCPのCloud RunやAWS Lambdaが該当しており、issueが挙げられている。

https://github.com/docker/buildx/issues/1533

またAmazon ECRはmulti-platform imageに対応してはいるものの、image indexを適切に処理できていないのか、Storage部分のmanifestがイメージとして認識されてしまい、 <Untagged> という名前で表示されたり、イメージスキャンが走ったりしてしまうという問題が報告されている。

https://github.com/aws/containers-roadmap/issues/1596

https://github.com/docker/build-push-action/pull/746#issuecomment-1377806123

暫定的な対処と今後

上記のように不具合を起こす可能性があるため、自身が利用しているコンテナ環境の対応状況を見つつ、暫定的には provenance: false の指定が必要になってくる。コンテナ自体は正常に起動していても、ECRの例のようにレジストリが対応できていない場合もあるため、そちらもあわせて確認したほうが良さそうだ。

表層的には「面倒なものが追加されたな」という思いもあるが、SLSA自体の有効性は理解できる。ソフトウェアのサプライチェーンをめぐるセキュリティについては、アメリカの大統領令に盛り込まれたSBOM (Software Bill of Materials)の話題を聞くことも多くなってきているし、長期的にはより大きなトレンドになってくる可能性は小さくない。将来的には多くのコンテナレジストリや実行環境が対応し、特に気にせずデフォルトでProvenanceを生成するようになるのかもしれない。

~また今回の事例はdocker/build-push-actionの3.3.0における「破壊的な」変更がきっかけになったが、一部の環境で問題を引き起こしかねないことが事前に予見されていたのであれば、これはメジャーバージョンアップが妥当だったのではないか、という思いもある。Dockerとしては生成物が追加されるだけで後方互換性を壊すわけではないので、これはマイナーバージョンアップ相当であり、レジストリなどの対応状況については知らんよ、という言い分なのかもしれないし、それも理解できるところではあるのだが……。~ （先述した追記の通り、その後改めてこの変更はメジャーバージョンアップとして扱われることになった）

まぁGitHub Actionsを使う側としては @v3 指定で不意にアップデートされてしまった、というのはやはりよろしくないので、推奨されているcommit hashでのバージョン指定か、パッチバージョンまで固定するべきなのだろうな、とは思う。

ぼっちを救うためのストア哲学 - 本しゃぶり で紹介されていた、 『迷いを断つためのストア哲学』という本を読んだ。ストア哲学とは、古代ギリシャのゼノンに端を発する哲学であり、『迷いを〜』は後期ストア派にあたるエピクテトスの言葉をもとにした書籍だ。

ストア哲学というのはちょっとしたブームらしい。哲学と言うとどこか高尚なイメージもあるが、ストア哲学は生活のなかでの実践に重きを置いており、ビジネスの場でも応用が利くのだそうだ。僕も以前からいくらかの場所で名前を見かけたことはあった。昨年読んだ『エンジニアリングマネージャーのしごと』の中でも「13.1.1 ストア派とあなた」という章があり、そのものズバリな言及がある。他、僕の読んだところだと『反脆弱性』のなかでも触れられていた。

知的な生活とは、痛みを感じなくてすむように感情を位置づけることなのだ。そのためには、自分の財産を頭の中で帳消しにし、失う痛みを感じないようにすればいい。そうすれば、世界が変動しても悪影響を受けることはないのだ。（中略）ストア哲学とは感情をなくすことではなく、手なずけることだ。人間を植物に変えることではない。(ナシーム・ニコラス・タレブ(著/文) 望月衛(監修 | 翻訳)『反脆弱性 上』ダイヤモンド社, 2017, p.386)

『迷いを〜』のなかではストア哲学の原則を欲求、行動、受容の3つと書いている。「ブーム」になっているストア哲学の側面は、このうち「受容」の原則が強いように思う。受容というのは、自分がコントロールできるものとできないものを見極め、コントロールできないものに関しては受容して、気にかけるのをやめよ、という話だ。『反脆弱性』からの引用部分はまさにそのことを示したものだし、その他にも様々な場所で似た話を見かける。例えば有名なもので「ニーバーの祈り」がある。

神よ、変えることのできないものを静穏に受け入れる力を与えてください。変えるべきものを変える勇気を、そして、変えられないものと変えるべきものを区別する賢さを与えて下さい。

あるいは7つの習慣における「関心の輪 影響の輪」も同様の話と言っていいと思う。ストア哲学の3つの原則のうちの1つに関してだけではあるものの、確かにビジネスの現場でよく引き合いに出されるメソッドとの関連性が強いことがよくわかる。

ストア哲学の実践という点においては、認知行動療法との繋がりもある。認知行動療法とは、心の問題をケアするにあたり、客観的に観察しやすい「認知」や「行動」を変えていくことによる効果を期待するものだそうだ。

この認知行動療法は、ストア哲学に源流を持つ、というような話があるらしい。僕は認知行動療法の成り立ちに詳しいわけではないので、実際にストア哲学を下地にして生まれてきたものなのか、後付け的に共通項が見出されているだけなのかまではわかっていない。ただ、読んではいないが『認知行動療法の哲学ーストア派と哲学的治療の系譜』という本も発刊されており、『迷いを〜』の中だけで言及されている話ではなく、ある程度一般的に認知されていることではあるようだ。

確かに、ストア哲学と認知行動療法には似ている点がある。ストア哲学において、怒りや不安などの負の感情へ対処する方法として、そういった負の感情を覚える「心像」を自分と同一視せず、切り離して受け容れよとされている。

心像とは、出来事や人や誰かに言われたことに対する最初の反応である。それに対して、一歩下がって合理的な考えをめぐらせたり、軽率に感情的な反応をするのを避けたり、直面しているものがコントロールできるものか（そうであれば行動する）、できないものか（その場合は無関係のものとする）を自問したりする。

認知行動療法もまた、負の感情そのものと対するのではなく、そういった感情を覚えたときに自分がどのように考えたのか、あるいは身体にどういった反応、行動が出たのかというところを言葉で書き下して観察し、一度自分から切り離して対処する、というフローを経る。ある場面に対してどういった思考や感情が沸き起こるか、というのは 自動思考 という言葉で表されるように、パターン化して癖になっているものらしい。Pull requestに何かコメントがついた通知が来ただけで、内容を見てもいないのに身構えてしまう、というように。この「認知の癖」を客観的に観察して気付き、変えていくことで負の方向への思考を断つのだそうだ。

なお、認知行動療法の1つ、比較的新しいものとして「マインドフルネス認知療法」というものがある。これは言葉通り、マインドフルネスの実践を通じて感情や認知から一歩離れる訓練をするものとのことで、このように辿ってくるとストア哲学とマインドフルネスにも関連性が見出せてくる。マインドフルネスの実践を単に「集中力を上げたい」などと単純化するのではなく、ストア哲学の様々な考え方に繋げていくと考え方も広がっていくかもしれない。

Afterwords

僕もネガティブに考えがちな質だったり、自己肯定感が常に低いといった課題意識があり、本書でかじったストア哲学の考え方や、そこから派生した認知行動療法、マインドフルネスは実践的に活かせそうだなと感じている。自己肯定感の低さをもたらしていることの1つに、他人からの評価をそのまま受け取れないという「癖」があるのは自分でもわかっており、なぜ他己評価を受け入れられないのかについては改めて考えてみたい。こういった作業は「脳のデバッグ」のようだなと思った。

具体的実践においては、認知行動療法がメソッドとして活用できそうだと考えている。自分の思考パターンなど、当然ながら自分自身で気付くのは難しいのだろうし、本来であれば専門家の助けを借りたほうがいいのだとは思うが、それほど深刻なメンタルの問題があるわけでもないので、『Awarefy』というアプリを使って自分で学んでみることにした。

https://www.awarefy.app/

これはいくつかの質問に応える形で考えを書き下していけば、自分の認知や行動をスムーズに記録して振り返ることができる機能や、実際に療法のメソッドを1か月かけて学ぶプログラムなどが収録されたアプリだ。フル機能を使うには月額課金が必要になるが、感情や認知を切り離して考える習慣が付くまでは続けてみようと思う。

ストア哲学自体にも興味を持ったので、原典としてエピクテトスの言葉がまとめられた『人生談義』を買った。実践を進める傍らでこちらも読んでいきたい。

https://www.hanmoto.com/bd/isbn/4003360818

ライフステージが変わりました、というのと、チームのメンバーが増えたりなど、態勢が変わっていくなかでSREのチームをどう組織していくか、ということを考えて実践に落とし込もうとした、というのが大きい1年だった。

後者については Embedded SREとは何か - SREの組織類型についての覚書 - chroju.dev/blog や 地道に積み上げるSRE　目的合意から進めたSREの探求と実践｜グロービス・デジタル・プラットフォーム｜note といったエントリーにまとめてきた。他社でもSREの組織体系についてのエントリーをよく見かけるようになってきているし、どの会社でも関心領域が近いように感じている。今年1年はまだまだ模索という段階で、来年しっかり成果を残していきたい。チームリーダーという立場上、自分が思考する対象はやはり組織やチームが最も大きな位置を占める。

ライフステージについては、変わったことで生活上の優先順位が変わったり、これまでに無いタスクやイベントが入るようになってきて、この年末年始などは特にまさに、だったりというのはある。生活が変化することには慣れていくしかないし、それが苦には感じていない。ただやることはマジでいっぱいあるし、来年は引っ越しとかも考えたいし、マジでいろいろある。

定量評価

• ブログ : 19記事（昨年比 -6）
• GitHub Contributions : 377 (-22)
• 書籍 : 37冊（-12）

毎年この3つの指標を最近は見ている。GitHubの「芝」については GitHub Contributions Chart Generator というサービスを使わせてもらった。

どれも数字の上では下がっている。特にインプット、技術書をじっくり読むような経験が今年は少なくて、エッセイ的なものはいくつか読んでいたが、ガッツリ技術的なインプットができず、それがブログのエントリー数低下にも繋がっているように思う。

また後でも触れるが、週報を定期的に書くことにエネルギーを持って行かれて、アウトプットが減っているという負の側面も出てきてはいる。

GitHubはまぁこんなものかな、という具合。OSSに不具合を見つけたらPRするか、する暇やスキルがなければ取りあえずIssueを上げるというのを今年は継続的にやっていた、ぐらい。自分で何か作ったり、という機会はそれほど多くなかった。

学んでよかったこと / やってよかったこと

Cloudflare

リクエストの処理をよりエッジ側へと寄せていく考え方が主流になってくるなかで、今年はCloudflareをいろいろと触っていた。

• K3s + Cloudflare Zero Trustな環境をuser dataでシュッと建てる - chroju.dev/blog

CDNとDNSのみならず、Zero Trust、Workers、Workers KVなど、無料で触れる幅が広いことに驚いた。単純に触っていて技術的に楽しい、というのもあるし、最近は何かちょっとしたものをウェブ上にホストしたければ、まずはCloudflareで何か使えないかなと考えるようになっている。

業務用にシステムを組むときはどうしてもAWSの中だけで完結できたほうが見通しが良いと感じてしまうのだが、視界は広げておきたい。

CUE

• CUEでTerraformを書いてみる - chroju.dev/blog

つい先日書いたが、CUEも触っておいてよかった。Policy as Codeの話が案外盛り上がってこないなと感じているが、シンプルな話として、IaCツールを覚えるのにプラスして別のPaCツールに精通する必要がある、という学習コストの問題はあるわけで、CUEはこのあたりの問題を上手いこと止揚していけそうな空気を感じている。

週報

https://log.chroju.dev で公開している週報を、年間を通じて続けることができた。あまりガチガチなルールでやらないのが続けるコツだとは思っていて、忙しい週などは1週空けてもOKとしており、何度か抜けはあるのだが、2週以上途絶えてしまうことはなく、完全に習慣化した。

Publicに書いてツイートもしているのは、習慣継続のプレッシャーとして使っているだけであって、読まれることはあんまり想定していなかったのだが、予想外にいろんなところで「読んでいる」という声をいただくことがあった。なかには真似して始めてくれている人もいて、純粋に嬉しく思っている。ただ、僕自身も他のエンジニアの方々がやっているのに影響を受けて始めたのだということは一応明言しておきたい。最初に始めたときの経緯は 読んだ記事などを「週報」として notion にまとめ始めた - chroju.dev/blog に書いている。

定期的にアウトプットすることを強制的に習慣化するのはそれだけで良いことだと思っているし、普段あまり接していない人がどんなことを学んだり考えたりしているのか知れるのも楽しい。

Mailbrew

• Twitterの話題はMailbrewで収集する - chroju.dev/blog

インプットの面ではMailbrewが便利で今も続いている。メルマガをGmailを開かず読めるようになったのが一番の良い点だし、あらゆるソースの情報を集約的に見られることで、インプット上の認知負荷がかなり楽になった。

マインドフルネスと認知行動療法とストア哲学

https://www.lifehacker.jp/article/226273book_to_read-666/

マインドフルネス自体は何年か前に聞きかじって、2か月ぐらい試したけどよくわからなくてやめたのだが、今年改めて調べていて認知行動療法やストア哲学との共通点を知り、再び興味を持った。 マインドフルネス認知療法 - Wikipedia というものがあるらしく、出来事に対して自動的に感情が反応してしまうサイクルを停めて、うつ病などの回復を図るものらしい。精神疾患の状態になくとも、自分の認知の「癖」を治すことには効果がある。例えば自分は自己肯定感が低く、何か褒められてもつい謙遜しがちだが、これは「自動的な反応」に近く、マインドフルネスを通じて自分の感情的反応を変えていくことができる、らしい。「脳のデバッグ」に近いものと捉えている。

まだきちんと調べ切れていないので、ここはもう少し調べてものにしていきたい。

Afterwords

• 最後にこういうことを書くのもアレだが、「年」という単位を元に活動をしていない（四半期か年度のほうが大きい）ので、このタイミングでの振り返りってあんまり意味がないんだけど、年末ってこういうことしたくなるよね、というテンションなので今年も書いた。
  • GitHubの芝とかブクログとかは年単位でまとまるから、振り返りやすいのもあるし。
  • 月単位でこの月は何をした、とかもっとしっかり書ければいいんだけど、大きい個人プロジェクトを持ってはいないし、仕事のことは書けないしでいまいち書くことないんだよなとも思う。
• チームリーダーになって以降、ソフトスキル重点になりすぎているのが悩みだったけど、それが自分の職務なのである程度割り切るようになってきた。
  • 一方で新しい技術に手を出すことなどを意識していて、その結果がいくらか出せているのはよかった。
  • 今年は新しいことを学ぶことを意識しすぎて散らかってたのもあるので、1個深くしっかり学ぶ、みたいなのも考えていきたい。
• 週報は本当によいのだが、書くこと自体が目的かしがちで、振り返りサイクルが回せていない感覚も強くなってきたので、週報をまとめることを通じて振り返って次に繋げる、というのを来年は回したい。
• もっと本を読みたいし、もっといろいろ書きたい。
• なんかもうちょい書きたい気もするけど、紅白見ながら書いてて気もそぞろになってきたのでここらで閉じる。Vaundy知らなかったんだけど、いいですね。ではよいお年を。

スニーカーを選ぶときに「歩きやすさ」というパラメータをあまり意識していなかったのだが、 ニューバランスW880をよく歩くオタクにおすすめしたい 【買ってよかったもの2021】 - 二度漬け禁止 を読んで影響を受け、歩きやすい評判のあるスニーカーブランドを探した結果、 New Balance MW880G B4 と On Cloud5 Waterproof を買い、結果Onに軍配が上がった。

空洞を複数繋ぎ合わせたCloudTecと呼ばれるソールがかなり特徴的だが、これが名前通り「雲の上を歩くような」履き心地を生んでいるらしい。実際、悪路でも舗装路でも衝撃をうまく吸収してくれているようで、歩いている感覚が常に一定に保たれている感覚がある。旅行や街歩きが好きなので、日に1〜2万歩程度歩くことはよくあるが、足裏が痛くなるということはほぼ無くなった。あまりに良かったので、追加で THE ROGER Centre Court も買った。こちらは外見が優先されているが、実はCloudTecが控えめに導入されていて、似た系統のテニスシューズよりはかなり歩きやすかった。

BOOX NOVA Air

E-ink Androidで、電子書籍端末専用で使っている。スタイラスペンも付属しているが、こちらは使っていない。

起動時間、画面描画の速さ、使えるアプリなど、いずれも実用的で電子書籍を読むときはほぼこれになっている。別売りの音量ボタン付きスリーブケースを取り付け、Kindleなどで「音量ボタンでページめくりを行う」設定をすると、物理ボタンでかなり速いページめくりを行えるようになる。ただ、そのためだけにケースを買って全体の重量を増やすのはイマイチなのは確かで、今だと物理ボタンが本体に搭載された BOOX Leaf 2 を買うほうがいいかもしれない。

KAT Iron

買ったのはだいぶ前なのだが、Group Buyに申し込んで今年届いたキーキャップ。名前通り「鉄」をコンセプトにした渋めのカラーリングも、フェニキア文字のレジェンドも、少し厚めの素材でできているため、コトコトと気持ちのよい音をさせてくれるところもすべてが良い。これで僕のキーボードは完璧になった。

TOOL STAND DESK

https://www.kingjim.co.jp/sp/spot/toolstand/

KING JIMが販売している、自立するバッグインバッグのような製品。机上にあまりモノを置きたくないし、かと言って袖机も買いたくないのだが、作業中にすぐ使うものは近くに置きたい、というニーズを上手く満たしてくれた。見た目に反して容量はあり、付箋、測量野帳、ペン、イヤホン、BOOX、机上の掃除用具、ScanSnap iX100、クリアファイル、さらに読みかけの本など色々突っ込んでいる。机上は綺麗だけどこの中はひどい有様になったりはする。

エンジニアリングマネージャーのしごと

https://www.oreilly.co.jp/books/9784873119946/

書籍についてはこれが一番よかったかなと思う。というか今年あんまり歯ごたえのある本は読めていないのを振り返ってみて反省した。書籍の感想は 『エンジニアリングマネージャーのしごと』を読んだ - chroju.dev/blog をご参考に。

北海道富良野ホップ炭酸水 / ストロングスパークリングガラナ / 正気のサタン

飲み物部門。

仕事中は炭酸水を常飲しており、炭酸の強さから基本的にはウィルキンソンを飲んでいるのだが、たまに変わったフレーバーがあれば手を出してもいて、今年飲んだ中では 北海道富良野ホップ炭酸水 と ストロングスパークリングガラナ が特によかった。フルーツテイストのフレーバーは炭酸水はどことなく甘みを錯覚するのだけど、この2つはホップとガラナということで、そういった錯覚もなくすっきり飲める。ただただリフレッシュしたいときには良い。後者は北海道メインのコンビニチェーン・セイコーマートのプライベートブランドなので、ネット通販で買っている。前者もあまり街中で見かけることはなく（見かけるのはJR東日本の駅自販機ぐらい）、同じく通販経由。

正気のサタン は『よなよなエール』のヤッホーブルーイングが出したローアルビール。ヤッホーブルーイングのビールは好きなのだが、アルコール4%の『水曜日のネコ』ですらコンディションが完璧では無い日だと飲み干せずに頭痛と吐き気に襲われるレベルの下戸なので、自信を持って飲み干せるヤッホー製ドリンクが出たのは嬉しい。ローアルのIPA自体が現時点では珍しいし、香りも豊かで「妥協して飲む」のではなく積極的に飲みたくなる。ビールの味自体は好きで、酒は「万全に体調を整えて頑張れば飲める」という感じで飲んでいたが、これで潔く酒自体を諦められそうだなと思い始めている。

販路がまだ限定されていて、東京都内のセブンイレブンか通販でしか買えない。都内に足を運んだ際にセブンへ寄るのがルーチンになりつつある。

さんしょうの種

食べ物部門。

長野県へ旅行したときに、八幡屋磯五郎のさんしょうの種 を買ったのだがこれが手加減抜きに山椒を効かせていて最高に美味い。続けて10粒も食べると舌がビリビリしてくる。

サブスク

  * Gyazo Pro (¥4,680 / year)
- * Day One (¥2,800 / year)
  * MoneyForward プレミアム会員 (¥500 / month)
  * Nintendo Switch Online + 追加パック (¥4,900 / year)
  * Amazon Prime Student (¥2,450 / year)
  * Spotify Premium Student (¥480 / month)
  * シネマシティ (¥1,000 / year)
- * Dynalist Pro ($7.99 / month)
+ * Workflowy Pro ($49 / year)
  * dアニメストア (¥400 / month)
  * メールマガジン「読書日記／フヅクエラジオ」 (¥800 / month)
  * ATOK Passport (¥300 / month)
  * IFTTT Pro ($1.99 / month)
- * Association for Computing Machinery ($99 / year)
+ * O’Reilly Online Learning ($299 / year)
- * Netflix (Standard) (¥1,490 / month)
+ * Mailbrew ($59.88 / year)

いくつか入れ替わったり追加されたりしている。Mailbrewについては Twitterの話題はMailbrewで収集する - chroju.dev/blog で書いた。

Day One は以前からほのかにやめたい気持ちがあったが、最近一念発起してやめた。見た目のおしゃれな感じや、カレンダー形式で写真を眺めたり、x年前の今日の日記をピックアップしてくれたり、というのは好きだったが、お金を払わないとマルチデバイスで使えない、ウェブアプリはないなど、編集と閲覧の自由度が低く、俺の日記ぐらい俺の好きにさせろという気持ちが強くなった。現在は Scrapbox で日記を書いている。気が向いたらエントリーにするかもしれない。

タスク管理などで使っているアウトライナーは Dynalist から Workflowy に変更した。以前はWorkflowyを使っていたので出戻りになる。Dynalist開発チームは最近流行りの Obsidian の開発に手を取られているようで（参考 : No monthly blog update since November. Are the team ok? - 🌟Features - Dynalist Forum）、実際2021年9月以来、アップデートが停止してしまっている。この点を懸念してWorkflowyに移った。Dynalistのほうが機能は豊富なのだが、改めてWorkflowyを使うと、シンプルであるが故に考えることが少なく済む面もあり、今では気に入っている。

ACMはO'Reilly Online Learningを読める特典がなくなったので解約し、O'Reillyを直接契約することにした。なお定価は$499/yearなのだが、毎年9月頃に割引のキャンペーンがあるので、それを待って契約している。

Netflixは見たいものがなくなったために解約。これはもうフレキシブルに1か月単位で契約/解約するものだと思っている。

なお、しれっと昨年までなかったGyazo Proを追加した。これはもう何年か使っているのだが、ずっとリストに入れ忘れていた。Gyazo Proは写真やスクリーンショットで「後で使いそうなもの」をとにかく投げ込んでおけば、OCRやスクショ元のアプリ名で柔軟に検索できるので便利。またScrapboxと開発元が同じHelpfeel（旧NOTA）であり、Scrapboxは無料で使わせてもらっているので、せめてGyazoからお金を払わせてくれ、というような意味合いもある。

APIにはBulk APIとQuery APIの2種類がある。前者はあるサービスの価格情報などを文字通りまとめてダウンロードできるエンドポイントであり、APIとは言うが、実体としてはAmazon S3に保存されたJSONファイルになっている。そのため対象のサービスなどによってエンドポイント自体が異なってくる。ものによっては、例えばEC2だと4GB近い巨大ファイルが落ちてくるので扱いには注意が要る。

Query APIはクエリをかけて、あるサービスの特定条件、例えばap-northeast-1のRDSのdb.t4g.microの料金のみを取得できる。こちらは各種SDKでも対応していて、AWS CLIの pricing サブコマンドからも叩くことが出来る。APIは3種類あり、 GetProducts は料金情報の取得、DescribeServices はGetProductsでフィルタに使うことができる、あるサービスの属性情報の種類一覧を取得、 GetAttributeValues は属性情報に指定可能な値を一覧できる。

属性情報というのは例えばEC2であれば instanceType のような、価格情報の確定に関わるパラメータ。これが思った以上にたくさん指定しなくては十分に絞りきれない場合があったり、パラメータをどう指定するかわかりづらい部分がある。

Lambdaについて describe-services して属性情報を一覧すると以下のようになる。

$ aws pricing describe-services --service-code AWSLambda --region ap-south-1
{
    "Services": [
        {
            "ServiceCode": "AWSLambda",
            "AttributeNames": [
                "productFamily",
                "termType",
                "usagetype",
                "locationType",
                "Restriction",
                "regionCode",
                "servicecode",
                "groupDescription",
                "location",
                "servicename",
                "group"
            ]
        }
    ],
    "FormatVersion": "aws_v1"
}

このうち usageType に指定可能な値を get-attribute-values で見てみる。

$  aws pricing get-attribute-values --service-code AWSLambda --attribute-name usageType --region ap-south-1
{
    "AttributeValues": [
        {
            "Value": "AFS1-Lambda-GB-Second-ARM"
        },
        {
            "Value": "AFS1-Lambda-GB-Second"
        },
        {
            "Value": "AFS1-Lambda-Provisioned-Concurrency-ARM"
        },
        {
            "Value": "AFS1-Lambda-Provisioned-Concurrency"
        },

これらの値はAWSの料金明細などに記載があるが、それほど日頃見慣れているわけでもないし、AWSのドキュメントなどにも詳細な説明はない。AtributeNamesについては Product details - AWS Cost and Usage Reports に一覧されているが、その具体的な値、Valueが何を意味するかの記述はないので、手探りに考えていくしかない。

Lambdaは比較的とっつきやすくて、 usageType に APN1-Request （おそらくはap-notheast-1のリクエスト料金の意）を指定すると以下のように結果が1つに絞れる。若干妙な出力形式なのはJSONがstringで吐き出されているからで、こういった点でも癖がある。

$ aws pricing get-products --service-code AWSLambda --region ap-south-1 --filters Type=TERM_MATCH,Field=usageType,Value=APN1-Request
{
    "PriceList": [
        "{\"product\":{\"productFamily\":\"Serverless\",\"attributes\":{\"regionCode\":\"ap-northeast-1\",\"servicecode\":\"AWSLambda\",\"groupDescription\":\"Invocation call for a Lambda function\",\"usagetype\":\"APN1-Request\",\"locationType\":\"AWS Region\",\"location\":\"Asia Pacific (Tokyo)\",\"servicename\":\"AWS Lambda\",\"operation\":\"\",\"group\":\"AWS-Lambda-Requests\"},\"sku\":\"3BE8DYKG4FYSZGDW\"},\"serviceCode\":\"AWSLambda\",\"terms\":{\"OnDemand\":{\"3BE8DYKG4FYSZGDW.JRTCKXETXF\":{\"priceDimensions\":{\"3BE8DYKG4FYSZGDW.JRTCKXETXF.6YS6EN2CT7\":{\"unit\":\"Request\",\"endRange\":\"Inf\",\"description\":\"AWS Lambda - Total Requests - Asia Pacific (Tokyo)\",\"appliesTo\":[],\"rateCode\":\"3BE8DYKG4FYSZGDW.JRTCKXETXF.6YS6EN2CT7\",\"beginRange\":\"0\",\"pricePerUnit\":{\"USD\":\"0.0000002000\"}}},\"sku\":\"3BE8DYKG4FYSZGDW\",\"effectiveDate\":\"2022-12-01T00:00:00Z\",\"offerTermCode\":\"JRTCKXETXF\",\"termAttributes\":{}}}},\"version\":\"20221214183021\",\"publicationDate\":\"2022-12-14T18:30:21Z\"}"
    ],
    "FormatVersion": "aws_v1"
}

自分が試すなかで厄介だったのはEC2で、それなりに多くの属性を指定しなければ一意の情報にまで絞り込むことができなかった。日頃あまり意識していなかったが、インスタンスタイプとリージョンや、Dedicated Hostなどのテナント属性だけでなく、ソフトがプリインストールされていたり、といった要素も関わってくる。最終的に1個に絞り込むには以下の属性が必要だった。

$ aws pricing get-products --service-code AmazonEC2 --region ap-south-1 --filters '[{"Type":"TERM_MATCH","Field":"instanceType","Value":"t3.medium"},{"Type":"TERM_MATCH","Field":"location","Value":"US East (N. Virginia)"},{"Type":"TERM_MATCH","Field":"operatingSystem","Value":"Linux"},{"Type":"TERM_MATCH","Field":"tenancy","Value":"Shared"},{"Type":"TERM_MATCH","Field":"capacityStatus","Value":"Used"},{"Type":"TERM_MATCH","Field":"preInstalledSw","Value":"NA"}]'

なお、このAPIはTerraformにも対応しており、 aws_pricing_product で取得できる。このData sourceはかなりストイックで、取得結果が価格情報1つにまで絞り切れていないと plan の時点で失敗になる。

また先ほど見たとおり、結果はJSONがstringで落ちてくるので、そこから価格情報を取り出すには jsonencode() を噛ませる工夫が必要になる。いろいろとコツは要るが、使い方をマスターできればスポットインスタンスの価格設定にオンデマンドの価格を自動取得して設定する、ということもできるようになる。

data "aws_pricing_product" "ec2_instance" {
  # Price List APIはus-east-1とap-south-1しか対応していない
  provider     = aws.ap-south-1

  service_code = "AmazonEC2"
  filters {
    field = "instanceType"
    value = "t3.medium"
  }
  filters {
    field = "operatingSystem"
    value = "Linux"
  }
  filters {
    field = "preInstalledSw"
    value = "NA"
  }
  filters {
    field = "location"
    value = "Asia Pacific (Tokyo)"
  }
  filters {
    field = "tenancy"
    value = "Shared"
  }
  filters {
    field = "capacitystatus"
    value = "Used"
  }
}

resource "aws_spot_instance_request" "this" {
  spot_price = values(values(jsondecode(data.aws_pricing_product.ec2_instance.result).terms.OnDemand)[0].priceDimensions)[0].pricePerUnit.USD
}

• CUE を使用した Kubernetes マニフェスト管理 | メルカリエンジニアリング
• [DevOps プラットフォームの取り組み #4] CUE 言語の紹介 - NTT Communications Engineers' Blog
• CUE によるスキーマやバリデーションのポータビリティ | gihyo.jp

CUE とは何か、レポジトリの README から引用すると以下のように書かれている。

CUE is an open source data constraint language which aims to simplify tasks involving defining and using data. It is a superset of JSON, allowing users familiar with JSON to get started quickly.

ポイントとしては JSON のスーパーセットであることと、データの定義や利用をシンプルにすることを目的としているという点だと理解している。昨今、Kubernetes の隆盛などにより、JSON やそれと互換性を持つ YAML を用いる機会が多くなったが、これら言語の機能だけではスキーマを定義したり、制約を書いたりすることは難しい。CUE はこれを解消する機能を持っているようである。

CUE が JSON のスーパーセットであるということは、JSON と互換性を持つ HCL のスーパーセットとしても使えるはずである。筆者はそもそも CUE に触ったこと自体がなかったので、今回は CUE で Terraform の定義をどのように書けばよいのか探りながら CUE に入門してみた。

HCL と JSON の互換性

https://developer.hashicorp.com/terraform/language/syntax/json

HCL と JSON には互換性があり、Terraform の定義も JSON で書くことが可能である。 terraform コマンドの対象として、カレントディレクトリの *.tf に加えて、 *.tf.json という postfix の JSON ファイルも読み取られる仕様となっている。

変換の手順としてはシンプルに key value をそのまま JSON として起こしていくだけだが、 resource "aws_instance" "this" {} のように複数の label が連続する箇所については、JSON Object がネストする形になる。例えば以下の HCL があるとする。

resource "aws_ebs_volume" "this" {
    availability_zone = "ap-northeast-1a"
    size              = 50
}

resource "aws_s3_bucket" "this" {
    bucket = "example"
}

これは以下の JSON に等しい。

"resource" : {
    "aws_ebs_volume" : {
        "this" : {
            "availability_zone" : "ap-northeast-1a",
            "size" : 50
        }
    },
    "aws_s3_bucket" : {
        "this" : {
            "bucket" : "example"
        }
    }
}

CUE で Terraform の定義を書く

早速ではあるが、上記の JSON を CUE に起こすと以下のようになる。

resource: {
    aws_ebs_volume: {
        this: {
            availability_zone: "ap-northeast-1a"
            size: 50
        }
    }
    aws_s3_bucket: {
        this: {
            bucket: "example"
        }
    }
}

あるいは、 フィールドが 1 つだけの場合はブラケットを省略できる ので、以下も同義になる。

resource: {
    aws_ebs_volume: this: {
        availability_zone: "ap-northeast-1a"
        size: 50
    }
    aws_s3_bucket: this: {
        bucket: "example"
    }
}

JSON への変換は cue コマンドを使って行う。コマンドのインストール方法は ドキュメント では brew install cue-lang/tap/cue となっているが、12 月の現時点では homebrew-core にも入っているようである。 cue eval sample.cue でバリデーション、 cue export sample.cue で JSON への変換が行える。

これだけだと key はクォーティングしなくて良くてちょっと楽ですねとか、それぐらいなものではあり、特に魅力を感じられる気はしてこない。

スキーマ定義とバリデーション

ここからが本領、CUE でスキーマを定義したり、値のバリデーションをかけたりするフェーズに入っていく。

CUE では「型は値である」と言われる。これはあるフィールドを定義するものとして、型や制約と、具体的な値とが同じように評価されるということを意味する。数学的には Lattice、日本語で「束（そく）」の概念を取り入れている。

resource: aws_ebs_volume: this: {
    availability_zone: string
    size: <100
}

resource: aws_ebs_volume: this: {
    availability_zone: "ap-northeast-1a"
    size: 50
    encrypted: true
}

上記の CUE は成り立つ。まず、CUE では同じフィールドに対する定義を複数回書けるので、 resource: aws_ebs_volume: this: が複数存在していてもエラーにはならない。複数回記述されたフィールドは、その論理積が取られるような形になる。 availability_zone は string かつ "ap-northeast-1a" であり、 size は <100 かつ 50 、という具合である。ここにさらに size: >100 や availability_zone: "us-east-1" といった記述を追加すると論理積は空集合となってしまい、CUE の評価は失敗する。また 2 つの定義の双方で、フィールドの過不足があっても問題ない。上記の例の場合、最終的には encrypted: true が存在する形になる。

バリデーションは多様な書き方ができる。string に対しては正規表現も書けるし、論理和 | のオペランドが備わっていて、 enums のように availability_zone: "ap-northeast-1a" | "ap-northeast-1c" といった書き方もできる。また同様に論理和を使った書き方として、アスタリスクを付けるとデフォルト値を指定でき、 size: <100 | *50 とすれば、具体的に size の指定がなければ 50 として評価される。

Definition

CUE で記述されたデータを JSON に変換するには、当然ではあるが最終的に具体的な値を持つ必要がある。様々な AWS リソースのスキーマだけを書いたファイルを取りあえず用意して、このうち一部のリソースしか実際には定義しない、ということもあるだろうが、スキーマだけの状態だと値が確定できず、 cue export は失敗する。

$ cat <<EOF > sample.cue
resource: aws_ebs_volume: this: {
    availability_zone: string
    size: <100
}
EOF

$ cue export sample.cue
resource.aws_ebs_volume.this.availability_zone: incomplete value string:
    ./sample.cue:2:24
resource.aws_ebs_volume.this.size: incomplete value <100:
    ./sample.cue:3:11

このような場合は Definition を使う。頭に # を付けたフィールドは Definition として扱われ、データとしては評価されない。

$ cat <<EOF > sample.cue
#resource: aws_ebs_volume: this: {
    availability_zone: string
    size: <100
}
EOF

$ cue export sample.cue
{}

Definition を利用するときには & を使って呼び出す。上記は簡易な例として resource を Definition にしてしまったが、実際に Definition として作りたいのは aws_ebs_volume の方なので、より実践的な書き方としては以下のようになる。

$ cat <<EOF > sample.cue
#aws_ebs_volume: this: {
    availability_zone: string
    size: <100
}

resource: aws_ebs_volume: #aws_ebs_volume & {
    this: {
        availability_zone: "ap-northeast-1a"
        size: 10
    }
}
EOF

$ cue export sample.cue
{
    "resource": {
        "aws_ebs_volume": {
            "this": {
                "availability_zone": "ap-northeast-1a",
                "size": 10
            }
        }
    }
}

Terraform resource の定義は JSON だと深いネストを必要とするので、これでも少し冗長に感じる。呼び出し側の記述をもう少しシンプルにしたければ、 Definition をフル活用して以下のようにも書ける。 #resource_name は Terraform らしく、半角英字とアンダースコアしか使えない制約も追加した。

#aws_ebs_volume: {
    #resource_name: =~ "^[a-z_]+$"
    #availability_zone: string
    #size: <100
    resource: aws_ebs_volume: "\(#resource_name)": {
        availability_zone: #availability_zone
        size: #size
    }
}

#aws_ebs_volume & {
    #resource_name: "prod_instance_ebs"
    #availability_zone: "ap-northeast-1a"
    #size: 10
}

これだと非常にシンプルにはなったが、呼び出し側で aws_ebs_volume に新たなパラメータを追加できなくなっていることには注意が必要だ。頑張れば何か手段があるかもしれないが、今の時点では思い浮かばなかった。

Package / Modules の分離

Definition による型や制約は、何らかの形で切り出して、複数のプロダクトなどで使い回したくなってくる。コードの再利用を進める仕組みとして、 CUE にも Package / Modules の概念が存在している。

CUE で Modules を使うには、 module: "example.com/pkg" と記したファイルを ./cue.mod/module.cue に配置する必要がある。手動で作ってもよいが、 cue mod init example.com/pkg コマンドで自動生成もしてくれる。このあたりは Go の設計に影響を受けており、モジュール名も github.com/user/repo 形式が 原則とされている 。 cue mod init により、Go での外部パッケージ管理を彷彿とさせる cue.mod/{pkg,usr} といったディレクトリも作成されるのだが、現時点では CUE 自体の Package Management の仕組みがなく、あまり活用する機会がないように思えている。

https://github.com/cue-lang/cue/issues/851

Package を宣言するのも Go と同様で、1 行目に package main のように記述する。なお Package と Module は包含関係にあり、 Module 内に複数 Package が存在できる。 Module はディレクトリで切られるが、その中に異なる Package のファイルが複数配置可能だ。

実践してみる。先の例から、スキーマについては別の Package に切り出すとして、 ./schema/terraform に以下のようなファイルを作る。

package ebs

#aws_ebs_volume: {
    #resource_name: =~ "^[a-z_]+$"
    #availability_zone: string
    #size: <100
    resource: aws_ebs_volume: "\(#resource_name)": {
        availability_zone: #availability_zone
        size: #size
    }
}

これを ./main.cue で呼び出すときも、やはり Go のような書き方になる。ここでは仮に cue mod init github.com/chroju/cue-sandbox を実行済みとする。

package main

import (
    "github.com/chroju/cue-sandbox/schema/terraform:ebs`
)

ebs.#aws_ebs_volume & {
    #resource_name: "prod_instance_ebs"
    #availability_zone: "ap-northeast-1a"
    #size: 10
}

実際の現場で使う場合は、さらに複雑なモジュール構成になっていくのかもしれない。例えば社内標準の #aws_ebs_volume を定義した Package を設け、それを package prod で本番環境相当により厳しくした #aws_ebs_volume と掛け合わせる、といった使い方が想定できる。

Script で Terraform を実行する

今更ながら CUE という単語の意味を紐解くと、 Configure Unify Execute の略だとされている。最後の Execute についてだが、CUE には Scripting というコマンド実行の機能が備わっている。組み込みの tools/exec や tools/file といったパッケージを使って、シンプルなシェルコマンドの実行からファイルの作成削除など、様々な操作が可能だ。

CUE で Terraform を扱う場合、Terraform コマンドの実行前に CUE から JSON への変換などを行う必要があるので、これをスクリプトにまとめると便利になる。詳細は割愛するが、以下のような CUE を書いて、 cue cmd plan と実行することにより、変換から terraform plan の実行、変換後 JSON の削除までを一発で完了させることができた。

package main

import (
	"tool/cli"
	"tool/exec"
	"tool/file"
)

command: plan: {
  echo_start: cli.Print & {
    text: "Convert cue to JSON ..."
  }

  export: exec.Run & {
    cmd: ["cue", "export", "."]
    stdout: string
  }

  remove_old_file: file.RemoveAll & {
    path: "terraform.tf.json"
  }

  generate_file: file.Append & {
    filename: "terraform.tf.json"
    contents: export.stdout
  }

  echo_plan: cli.Print & {
    text: "Execute terraform plan ..."
  }

  tfplan: exec.Run & {
    cmd: ["terraform", "plan", "-out=tfplan"]
  }

  remove_file: file.RemoveAll & {
    $dep: tfplan
    path: "terraform.tf.json"
  }
}

Impression

ざっくりと型定義、バリデーションなども行いつつ、CUE を使って Terraform を実行するまでを眺めてみた。率直な感想としてはわりと使えそうかもしれないと感じた。どちらかの方向への依存関係が発生するわけではなく、複数の定義を掛け合わせて最終的なデータを作って行くという形式は柔軟性が高い。Terraform 標準の機能では module の中で module を使ったりするとかなり複雑化してくるが、CUE であれば後からパラメータを追加するといったことも簡単にできる。かなり高機能なバリデーションを、 Sentinel や OPA/Rego といった別のツールを使わず、 CUE の中で完結できるのも良い。

一方、注意点も少なくない。当然ながら HCL の機能は使えないため、 bucket = aws_s3_bucket.this.id のようなリテラルは利用できず、懐かしい "${aws_s3_bucket.this.id}" 形式を使う必要がある。また先述したとおり、Package management の仕組みがないのは少々想定外だった。個人的にはスキーマだけを切り出した Module を 1 つのレポジトリで共有して、各プロダクトでそれを import するような使い方を想定していたからだ。インポートの機能としては cue get go コマンドによって Go Module の struct を CUE の struct として読めるという機能はあるので、そう遠くないうちに CUE Module もインポートできるようになるだろうとは思う（Kubernetes のリソースは Go の struct で定義されているため、これが結構便利らしい。残念ながら Terraform resource のスキーマ自体は struct ではない）。VSCode Extension などの入力支援もまだ乏しく、良くも悪くもまだまだ発展途上にあると感じてもいる。

あとは CUE の学習コストをかけてまで移行するメリットを見出せるか次第かなと思う。Lattice の概念に基づく記述は他に経験がなく、慣れるまでに多少の時間はかかったし、ここに書いた記述法でもまだ触り程度であり、CUE の表現力は極めて高く、それなりに学習コストを要する言語ではある。ただ、一度覚えれば Kubernetes にも Terraform にも、その他 JSON や YAML を使った様々な言語も内包し得るというのは魅力に映る。冒頭に貼った NTT コミュニケーションズやメルカリが目指しているのは、おそらくそういう地平なんじゃないだろうか。

Reference

今回参考にしたサイトをいくつか貼っておく。公式の Docs を見るのであれば Tutorials と Language Specification は特におすすめである。ただ、これだけではなかなかイメージが掴めず、Cutorials に非常に助けられた。

• Documentation | CUE
• Cuetorials
• How CUE Wins | Cedric Charly's Blog
• The Configuration Complexity Curse | Cedric Charly's Blog
• CUE 言語の Kubernetes チュートリアル【和訳】 - Qiita

単なる管理職ではなくて「エンジニアリングマネージャー」に特化した本として良かった。

自分も小規模なチームのリーダーをやりつつ手は動かしているので「エンジニアリングマネージャー」に当たるはずで、ここで悩ましいのがどこまで自分で手を動かすかという線の引き方になる。本書は序盤で「マネージャーのアウトプット＝チームのアウトプット＋影響を与えた他のチームのアウトプット」という大前提を敷いており、たびたびこの方程式を持ち出しては、それにぶら下がる形で各論を述べる、という構成になっているので納得感が得やすい。注力するべきは「チームのアウトプット」を最大化することであり、自分個人のアウトプットの最大化ではない。役割を担っている以上、周囲からもマネージャーとしての仕事が期待されるわけでもある。したがって冒頭の悩みに対する解は、まずはチームのアウトプット最大化に時間を割くべきであり、自分がコーディングなどに使う時間は二の次、というのが明白になる。まぁ言われてみればそれはそうだという話でしかなくて、二足のわらじを履いているようでいながら、実際にはマネージャーのほうに軸足が強く置かれるということになる。このことを明確かつきっぱりと突きつけてくれた上で、そのために何をするべきかも具体化してくれる。

マネージャーというのは自分で直接生産するよりは、連絡をしたり調整をしたり、というような業務が多くなるので、自分が何を成したのかが曖昧になりやすくもある。また責任範囲も大きくなるので、あれこれと心配事が増えやすくもある。このあたりについてもRACIやAppleのDRI（参考 : ジョブズが会議を生産的にした3つの方法 | ライフハッカー・ジャパン）を使って責任を明確に整理したり、マネージャーの仕事を言語化して4つに分類してくれたりしているので、自分で自分の仕事を見通しやすくなったように感じる。

心配事が増えやすい点に関しては、よく言われる「コントローラブルなものとアンコントローラブルなものを区別して、後者について心配するのをやめろ」という話が出てくる。この手の話は7つの習慣の1つとして「関心の輪、影響の輪」という形で言及されていたり、「ニーバーの祈り」などの類似概念も存在する。自分が影響を及ぼし得ないものに対して関心を持っても徒労になるという点には同意する一方で、「ニーバーの祈り」にも書かれているように、「変えられないものと変えるべきものを区別する」には「賢さ」が必要になる、つまり簡単なことではない。チーム内の不文律、チームメンバー構成、社内ルール、現状のアーキテクチャなどなど、こういったものが本当に変えられないのか、変えるのが困難なだけなのか、特にマネージャーという立場においては、如何に前提を疑った上でコントロールしていけるかというのがより重要になってくると感じた。前提や枠組みを疑えるか、という点については以下のエントリーも非常に示唆に富んでいる。「関心の輪、影響の輪」を単なる諦念として扱わないようには注意したい。

https://kamiyakenkyujo.hatenablog.com/entry/2020/11/13/002402

これほどつらつらと様々な概念を連想して思考できたのは、ひとえにScrapboxのおかげで、Scrapboxにメモしながら本を読むのはやはりいいなぁ、と思ったりもしたのだった。

https://scrapbox.io/nishio/%E9%80%A3%E6%83%B3%E3%81%AE%E3%82%B9%E3%83%88%E3%83%83%E3%82%AF

Note Takingの分野だと、昨年ぐらいからは Obsidian も流行っているが、LogseqもObsidianと同じく、ローカルのファイルシステムに保存する形式を取っている。Wikiのようにページ間のリンクを容易に作れる、デイリーページの機能がある、Markdownを書ける（Logseqのほうは厳密にはMarkdown likeではあるが）というあたりも両者は似ている。大きく異なる点としては、Logseqでは各ページをアウトライナーのように編集することができ、箇条書きの前後や階層構造を入れ替えたり、特定の階層配下だけを切り出して画面に表示したり、といったことができる点だろうか。タスク管理の機能がLogseqにはデフォルトで内蔵されているが、Obsidianには内蔵されていないという違いもある。LogseqはOrg-modeに似ている気がする。使ったことはないのだが。

僕は長らく Workflowy や Dynalist といったアウトライナーを使ってデイリーページを書いてきた。デイリーページ、あるいは日記、あるいは日報。そもそもなんで日報を書くのか、という話は 日記駆動仕事術のススメ | DevelopersIO とか 日報・週報を自分の役に立てるために書く - 発声練習 とかに譲る。毎朝その日のToDoをガリガリ書き出して、それを1つずつ潰しつつ、メモを取りつつデイリーページを埋めていくのが僕の1日だ。

アウトライナーというのは箇条書きの文章のアウトラインを編集するツールであり、デイリーページのための機能があるわけではない。毎日デイリーページの階層を切って、その下につらつらと書き連ねている。そんなことをするなら、最初からデイリーページ機能のあるアウトライナーっぽいツールであるLogseqを使えばいいんじゃないか、という思いから試しているわけである。Logseqはその日初めて「journal」という場所を開くと、勝手にその日のページが作られて開くようになっている。Workflowyでその日の階層を切る、というのもそこまでの手間ではないが、勝手にその日のためのまっさらなページが用意され、前日のことは見えなくなる、というのは、試してみると結構体験がいい。

しかしながら、結局Workflowyから移行するところまでは踏み出せない。

おそらく、デイリーページとして使いたいだけならLogseqに勝るものはない気がしている。しかし自分がアウトライナーを使っている目的はデイリーだけではなく、タスク管理全般に使っている。つまるところ「その日1日の全体像の把握」と、「ここ最近自分が気にしていること、やっていることの全体像の把握」だ。今日やったこと、というのが、今日その日だけの関心であればそれでいいのだが、実際はその日にやったことは大きな全体の一部であることが少なくない。そのダイナミクスを管理したい、というのが自分の求めるタスク管理ツールになっている。

例えばWorkflowyでデイリーページをこんな感じで書いているとする。

このとき、「その仕事」はいざ取りかかってみたら案外考えなくちゃいけないことが多そうだな、という感じになっている。すると「その仕事」はこの日だけの話ではなくなる。そういうときにアウトライナーであれば、

こんな感じで「その仕事」をデイリーの枠の外に引っ張り出せる。1日1日、という枠を越えてなんか考えなくちゃいけない、ならデイリーの中じゃなく1個上の階層に置いとこ、ということができる。これはざっくりした例だが、自分が認知したいかたちに合わせて自在にメモの階層構造を変化させられるのがアウトライナーの魅力と捉えている。

人生とか生活といったものはナマモノであり、それを脳内にどう入れておきたいか、というのも日々変化していく。ならば「やること」「考えたいこと」あるいは「考えたこと」「気付いたこと」などは全部1個の階層の中に入れ込んで、ぐにゃぐにゃ動かしながら生きていくのが自分の中では自然に思えている。というか、これが出来ないと結構つらい。おそらく、僕は僕の脳の扱いがあまり上手くない。人によっては、こういうことはチラシの裏があれば上手く整理して生活していけるのだろうと思うが、自分の場合は書き下したものが脳内と上手くシンクロしないとストレスに感じてしまう。

翻ってLogseqは、ページを基本単位としたツールだ。Workflowyのように自在に上下関係が変化し、全体と個別とが入れ替わるようなツールではなく、明確な「枠」がページとして切られる必然がある。

デイリーページで今日のページが作られると、それに対応したMarkdownファイルがローカルでは生成されている。それがどうも自分の脳と合わない。毎日がブツ切れになっているように感じてしまい、毎日をゆるやかに結ぶ全体感、というものをLogseq上に見出しづらい。「全体を管理する」ためのページをLogseqに1枚設けて、それとデイリーページの間でやり取りする、という形も試してはみたが、それでも乗れなかった。どうもLogseqの「ページを作る」という動作自体が苦手らしい。日々の思考の中には「今後どうなるかはわからないけど、取りあえずメモしておきたいこと」というものもあるのだが、そういう「取りあえず」をどこに置くかがLogseqだと悩ましい。未確定なのでページを切りたいわけではない。例えば #later みたいなタグをつけて、あとからfilteringして処理することもできなくはないが、Logseqでは文章を別の任意のページへ移動させる機能が現状なく、「取りあえず」で書いたものを全体のページへ移動させたりするには、カットアンドペーストする必要がある。ここさえクリアすれば、もしかしたらフィットしてくるかもしれない、という思いもある。

ツールの選定に長時間を費やすのはバッドプラクティスとされることが多く、自分もこんなことで悩みたくはないなとも思うのだが、日々の思考を支えてくれるツールというのは自分の生産性の根幹にあるだけに、ついつい考え込んでしまう。自分はおそらくLogseqがわりと好きなのだ。ローカルにメモを保存できるという点も、OSSである点も、Advanced queries という高機能な検索クエリが使える点も。それだけに、なんとかしてLogseqに移行できないかとつい試してみては、やはりダメだと戻ってくる、を繰り返している。

その繰り返しにさすがに嫌気がさしてきたので、現時点での結論を書き記しておくために、エントリーをしたためてみた。

最近 K3s を用いることである程度形になった。K3sはワンバイナリで動作する軽量なK8s実装であり、非常に扱いやすい。またK8s APIを遠隔から実行するにあたっては Cloudflare Zero Trust を用いることにしてみた。

現在、この環境をEC2 + user dataを使って terraform apply 一発で建てる仕組みを使い始めたので、少しまとめておきたい。

K3s

https://k3s.io/

Kubedrnetes (K8s) から諸々の機能を省いて、メモリフットプリントを半分にした実装。名前もKubernetes = 10文字の半分なので5文字でK3s、ということらしい。Rancherが元々開発していたもので、2020年にCNCF入りしている。

最も簡単なインストール方法としては curl -sfL https://get.k3s.io | sh - を実行することだが、あまりスクリプトでのインストールが好きではないので、直接バイナリを落としてきて使っている。バイナリダウンロードによるインストール方法もDocsに言及があり、systemd周りの設定を自力でやらなくてはならないぐらいで、特別煩雑な手順にはならない。

# Install k3s
curl -Ls https://github.com/k3s-io/k3s/releases/download/${k3s_version}/k3s -o /usr/local/bin/k3s
chmod +x /usr/local/bin/k3s
ln -s /usr/local/bin/k3s /usr/local/bin/kubectl

cat > /etc/systemd/system/k3s.service <<EOF
[Unit]
Description=Lightweight Kubernetes
...

Environment=K3S_KUBECONFIG_MODE=644
...
ExecStart=/usr/local/bin/k3s server
EOF

systemctl daemon-reload
systemctl enable k3s
systemctl start k3s

サーバとしてK3sを起動するときのオプションとしては、 K3S_KUBECONFIG_MODE を適切に設定しなければ、rootでしか kubectl できなくなってしまう点に注意が要る。

kubectl もK3sは内包していて、 kubectl のエイリアスとして実行すると kubectl として動作してくれる。

遠隔から kubectl で繋ぎにいくにあたっては、 /etc/rancher/k3s/k3s.yaml をkubeconfigとして用いればよい。ローカルからすぐに確認できるよう、user dataの中でこれをパラメータストアへ投げさせている。

# Register kubeconfig
apt update
apt install awscli -y

KUBE_CONFIG=$(cat /etc/rancher/k3s/k3s.yaml)
aws ssm put-parameter --region ap-northeast-1 --name /chroju/k3s/kube_config --type SecureString --overwrite --value "$KUBE_CONFIG"

Cloudflare Zero Trust + kubectl

kubectl はローカルから実行したいが、APIのエンドポイントをインターネット上に開放したくはないので、 Cloudflare Zero Trustを使っている。これはCloudflareが提供するゼロトラスト関連サービスの総称であり、より具体的にはCloudflare TunnelとCloudflare Accessを使う。

Tunnel[^1]は、サーバのインバウンド通信を開放せずとも、サーバ上で稼働するデーモン（cloudflared）がCloudflareと通信を確立することにより、Cloudflare経由でサーバの公開が可能となるサービス。httpを開放してWebサイトを運用するのにも利用できるし、SSHなどもサーバのポート開放を行うことなく通信が可能となる。

Tunnelが開放したエンドポイント自体には認証の仕組みが一切ないため、アクセス制御を行うのにCloudflare Accessを用いる。これはCloudflareのDNSサーバーに登録したドメイン上の任意のパスなどに認証を付与できるサービスで、いわゆるゼロトラストの中心的なサービスにあたると捉えている。個人開発のサービスに簡単に認証が付けられるし、企業ユースならSaaSに対するSSOのようなこともできるらしい。

認証方式は様々なものが用意されているが、最もシンプルなところだとワンタイムコードのメール送信がある。指定したメールアドレスにのみコード送信を許可できるので、メールアカウントさえ守れば防御できる。これを設定すると、当該のエンドポイントへ kubectl で繋ぎに行った際、以下のような認証画面がブラウザで自動的に表示されるようになる。

Tunnelを使うにあたっては、先にTunnelを作成しておき、cloudflaredには接続するTunnelの情報を書いたJSONと、接続に必要なSecretなどが書かれたYAMLを読み込ませる形になる。TunnelはTerraformで構築できるので、先にTeraformで構築した後、必要な情報をTerraform templatefile に埋め込んでuser dataを作成している。

# Install cloudflared for kubectl (Kubernetes API)
curl -Ls https://github.com/cloudflare/cloudflared/releases/download/${cloudflared_version}/cloudflared-linux-amd64.deb -o /tmp/cloudflared.deb
dpkg -i ./tmp/cloudflared.deb

mkdir -p /root/.cloudflared
cat > /root/.cloudflared/${cloudflare_tunnel.kubectl.id}.json <<EOF
{
  "AccountTag": "${cloudflare_account_id}",
  "TunnelSecret": "${cloudflare_tunnel.kubectl.secret}",
  "TunnelID": "${cloudflare_tunnel.kubectl.id}"
}
EOF

cat > /root/.cloudflared/config.yaml <<EOF
tunnel: ${cloudflare_tunnel.kubectl.id}
credentials-file: /root/.cloudflared/${cloudflare_tunnel.kubectl.id}.json

ingress:
  - hostname: ${cloudflare_tunnel.kubectl.hostname}
    service: tcp://127.0.0.1:6443
    originRequest:
      proxyType: socks
  - service: http_status:404
EOF

cloudflared service install

config.yaml に記載の通りSOCKSによるプロキシとして開放している。あとはローカル側にもcloudflaredをインストールし、 cloudflared access tcp --hostname example.com --url 127.0.0.1:1234 で、ローカルの1234 portがKubernetes APIと繋がった形になる。

この方法はCloudflare Docsに Connect through Cloudflare Access using kubectl · Cloudflare Zero Trust docs として掲載されている内容を、ほぼそのまま使わせてもらっている。なお、プロキシ経由で kubectl を実行するにあたり、Docsでは env HTTPS_PROXY=socks5://127.0.0.1:1234 kubectl ... を使っているが、kubeconfigに書いてしまったほうが楽なのでそうしている。

apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: XXX...
    server: https://example.com
    proxy-url: socks5://127.0.0.1:1234

user dataにどこまで含めるべきか？

ここまでの内容をuser dataに書いてEC2を起動すれば、そのまますぐにローカルから kubectl で繋ぎに行けるような環境は出来上がる。これだけでも良いのだが、自分はCDにArgo CDを使っていて、そのデプロイまでuser dataで済ませるべきか少々悩んだ。

user dataは非常に便利だが、一回性のただのコマンド群なので as Code 的ではない。K8s上に展開するArgo CDに関しては、きちんとマニフェスト管理するべきという考え方もあり、ここは意見が分かれるところとも思う。

まぁしかし、個人の環境だとArgo CDのマニフェストを書き換えて、という機会もそれほどないし、作ったときにはもうArgo CDも動いていて、あとはGitOpsで全部制御できる、となっているほうが嬉しい。ということで割り切ることにした。個人開発では割り切りが大事。

Cloudflare Zero Trust + Argo CD

Argo CDのGUIもCloudflare Zero Trustで開放している。

HelmChart CRD

Argo CDの導入には、簡単なところでHelmを使いたい。K3sはHelmも内包しているのだが、しかしHelmのコマンドラインは付属していない。ならばChartをどうインストールするのか、というところだが、HelmChartというCRDを使うことになっている。

https://rancher.com/docs/k3s/latest/en/helm/

HelmChartは、HelmでインストールするChartの情報を定義できるCRDであり、これをapplyすることで helm install がJobとして自動的に走る。 helm install を手続き的に実行するのではなく、宣言的にどう管理するかは結構頭を悩ませるポイントだと思うが、こんなスマートな回答があったとは知らなかった。このCRDは k3s-io/helm-controller を導入することで、K3s以外のK8s環境でも使えるらしい。

ということで、Helmを通じたArgo CDのインストールはこのようなコマンドになった。なお、マニフェストにコメントで書いているが、Argo CD serverのHTTPSは無効化しておく必要がある。HTTP接続があるとArgo CD serverはHTTPSへ307 redirectするのだが、これをCloudflare Tunnel経由だと上手く処理できないためだ（Tunnelのエンドポイントとローカル間はHTTPSにできるので問題はない）。

cat > /tmp/argo-cd-helm-chart.yaml <<EOF
apiVersion: helm.cattle.io/v1
kind: HelmChart
metadata:
  name: argo-cd
  namespace: kube-system
spec:
  repo: https://argoproj.github.io/argo-helm
  chart: argo-cd
  targetNamespace: argo-cd
  valuesContent: |-
    server:
      extraArgs:
        - --insecure # HTTPSを無効化しないとArgo Tunnelから繋がらない
EOF

kubectl create ns argo-cd
kubectl apply -f /tmp/argo-cd-helm-chart.yaml

Cloudflare Tunnel on K8s

Argo CDのServiceをTunnelで開放するため、今度はTunnelをK8s上に展開するが、これもCloudflareが記事 Kubectl with Cloudflare Zero Trust を公開しているので、詳細は割愛する。必要なのは接続情報を書いたYAMLと認証情報を書いたJSONであるという点は変わらない。

ApplicationSetのApply

Argo CDで管理したいApplicationはApplicationSetとしてまとめてGitHubに置いているので、最後にこれを読ませてやれば、Argo CDがバシバシ必要なApplicationを展開してくれて、GitOpsがすぐに使えるようになる。

curl https://raw.githubusercontent.com/chroju/infrastructure/main/kubernetes/applicatio
n-set/application-set.yaml -o /tmp/application-set.yaml
while true
do
    # Argo CD ApplicationSet Controllerの起動を待つ
    kubectl get deployment/argo-cd-argocd-applicationset-controller -n argo-cd | grep 1
/1
    if [[ "$?" == '0' ]]; then
        break
    fi
    sleep 10
done

kubectl apply -f /tmp/application-set.yaml

大方これで上手くいくはず、なのだが、ApplicationSet Controllerだけが起動してもダメなのか、実は今のところ上手くいっていない。一応Applyはされるのだが、ApplicationSetがエラーを吐いてしまっている。Argo CDのGUIに入って、ApplicationSetを一度削除してから再度Syncすれば直るので、個人環境だし深入りはしていない。追々直すかもしれないし直さないかもしれない。

Argo CDのパスワード

GUIのデフォルトパスワード、昔はPod nameだったりしたが、最近はsecretに入っているので、これもパラメータストアに投げて、ローカルからすぐ確認できるようにしてやる。

kubectl apply -f /tmp/application-set.yaml
ARGO_CD_PASSWORD=$(kubectl -n argo-cd get secret argocd-initial-admin-secret -o jsonpath="{.data.password}" | base64 -d)
aws ssm put-parameter --region ap-northeast-1 --name /chroju/k3s/argo_cd_password --type SecureString --overwrite --value "$ARGO_CD_PASSWORD"

Impression

以上の内容を繋ぎ合わせたuser dataの全体像はGistにも上げておいた。何度か言及してきた通り、Terraformの templatefile として用いるものとして書いている。

頑張って何もかもuser dataに入れなくてもよかったかもしれないが、 terraform apply を実行するだけで、すぐにローカルから kubectl でもArgo CDでも繋ぎにいける環境がシュッと立ち上がる、というのは結構体験がいい。個人での技術検証が目的だし、これぐらいの気軽さでいいんじゃないだろうか。K8sのバージョンが上がったらサクッとスクラップアンドビルドしちまえ、ぐらいの気概でいきたい。

また、ここまでに登場したCloudflareの機能は全部無料で使えていて、昨今いろんなところで名前を聞くようになった「Cloudflare」の勢いを感じた。自分が個人開発を始めた頃は、VPSの要塞化に頭を悩ませるような時代だったので、シンプルに「インバウンドは全部塞ぐ」が最適解な時代になったのは喜ばしい。

[^1]: Argo Tunnelという呼び方をウェブ上の記事で見かけることがあるが、おそらく旧名称と思われる。

それでもTwitterを完全に見ない、というのもなかなか難しくて、あれの良いところとしては「なんとなく眺めていると今話題になっていることがわかる」という点がある。炎上ネタなどはどうでもよいのだが、少しホットになりつつあるセキュリティ事象とか、最近この技術に言及されている機会が多いな、だとか、そういったことはRSSなど他の手段だと収集が難しい。もちろん、それが本当に必要な情報なのか、という視点はあるとは思うが。

以前はこの用途で Nuzzel を使っていた。これはTLやリストで多く言及されているリンクがあると、Slackなどに通知してくれるサービスで、「話題」をキャッチする上で重宝していたのだが、残念ながらTwitterに買収されて閉鎖されてしまった。

Mailbrew

それからNuzzel Alternativeをずっと探していたのだが、2か月ぐらい前に Mailbrew に行き着き、自分の中で運用が安定してきた。月額 $4.99 の有償ではあるが、その価値はあると思う。

Mailbrewは言うなれば「いろんな情報ソースを組み合わせて自分だけのメルマガ（ Brews と呼ばれる）を作れる」サービス。昨今、SNSやらDev.toのようなブログメディアなどが様々増え、それぞれに通知の仕組みがあるわけだが、その中から必要なものを抽出して集約して1日1回だけとか受け取るようにして、情報過多な状態を脱しましょう、という狙い。 Not just what you read but how の中でDHHが言及していたことでも一時話題になったように思う。

Mailbrew自身が The best Nuzzel alternatives と称しているように、使える情報ソースの中に「Twitter Top Links」というものがあり、話題のリンクをピックアップすることもできる。Twitter連携はかなり充実していて、「あるユーザーの最新ツイートを3つだけ」、あるいは「人気のものを3つだけ」などもできるし、「自分のTLで人気のツイートを5つだけ」といったこともできる。最近はTwitterでマンガ連載するようなアカウントもあるけど、これならMailbrewだけで追えて良かったりとか。 ちいかわ なんかはほぼマンガのツイートだけ投稿されていて、日に1〜2ツイート程度なのでめちゃくちゃ相性がいい。

他にもいろいろと。RSSなんかにも対応しているのは当然として、 Hacker News などの主要なメディアサイトであれば直接的に取り込む機能もある。

SavedとNewsletter

特徴的な機能として Saved と Newsletters がある。

前者はPocketのようなRead it Later機能。MailbrewはWebブラウザからログインすると、過去のBrewsもすべて読めるのだが、ここで読むと各記事に Save ボタンが付いており、あとで読む用に保存して、Mailbrewの中で読むことができる。また chrome extension を使うとブラウザからもURLを保存できて、まさにPocketライクに使える。

Newslettersはメルマガの集約機能。Mailbrewが発行してくれるメールアドレス宛にメールを送ると、その内容がMailbrew上で読めるようになる。僕は何本かメルマガを購読しているのだが、GmailのUIだとあんまり「読み物をする」気分にはならず溜まりがちだったのが、Mailbrewだと読む頻度が上がるようになった。

ちなみにSavedとNewslettersの新着は、Brewsの中に埋め込んで表示させることもできる。

自分の運用

先のDHHの記事の中に書かれた運用を参考に、毎日朝夕 + 週末の計3種類のBrewsを作っている。

• 毎朝 : Twitter、Reddit、Dev.to、Hacker Newsなどからの技術的な話題ピックアップ
• 毎夕 : 趣味的な話題のピックアップ
• 週末 : 確実に読みたいRelease Noteなどの集約

日次で受信するBrewは忙しいと読めないこともあるので、必ずしも読まなくてもいいようなホットな話題などを中心にしている。利用しているサービスやOSSのブログの更新や、GitHub ReleasesのRSSは時間のある週末に確実に目を通したいので、まとめて週末に送っている。

この方式で難があるのは AWSのWhats'new など、日に10回も更新するようなことがあるブログなのだが、レアケースではあるのでこういったものだけは今はSlackに流している。上手いこと抽出して受信したいとは思うのだが。

目指しているのは、「WebでのインプットはすべてMailbrewを見ればよい」という状態。あちこち通知を見に行ったりするんじゃなくて、ちょっと手持ち無沙汰なときにMailbrewを開けば読むものが積んである、という状態にしていきたい。 Saved も積極的に使っていて、仕事中などに「これは読んでおこう」というものが出たら取りあえず保存している。MailbrewはPWAではあるのでスマートフォンに「インストール」はできるものの、スマホから Saved を使うことはできないのが玉に瑕ではあるのだが、今のところ非公式な手段でゴニョゴニョしてスマホからもポチポチと保存している。

難を挙げると、今書いた通りモバイルの対応がいまいちな点、Brewsの編集がGUIで若干もっさりしていて面倒な点、Savedがたまにバグって同じURLを何度でも保存できちゃう点、ぐらい。あとはAPIがあると嬉しいのは確か。

Tailwind CSS

CSSに関しては基本的な文法は知っているという程度だし、デザインの知識も修めていない門外漢なので、Bootstrapのような楽にそこそこいい感じにできるフレームワークを探したところ、Tailwindが見つかったというところ。そのためTailwindが良いのか悪いのかという判断もできる立場にはないが、とりあえず形にはなったし、使いやすかったんだろうなと思っている。

Tailwindの一番の特徴は Utility-First という考え方にあるそうだ。例えば blog-subtitle のようなclassをつくり、これに対してmarginやらfont-sizeやらという各種の要素をくっつけて、同じclass名であればサイト内どこでも同じデザインになるようにする、というのが定番のパターンだし、僕の認識していたCSSの使い方。一方でUtility-Firstは文字を大きくする text-xl や、パディングを6pxにする p-6 といったclassが最初から定義してあって、これを組み合わせて各HTMLタグにclassとして振ることにより、欲しいデザインを作って行く方式。

CSSはすでに定義済みで、そこから必要なclass名を引っ張ってきてHTMLに書き入れるだけなので、HTMLだけを見ていれば良いという点では、デザインに慣れていない人間にはとても楽だった。ドロップシャドウも shadow-hoge のように書くだけで簡単にかけられるし、CSSテクニックを知らなくてもそこそこいい感じに出来る。

ただ、個々の要素をどう組み合わせるかは結局センス頼みになるので、これだけ使っていれば必ず良い感じになるってわけでもないな、とも思う。また、Utility-Firstだと結局inlineでCSSを書くのと似た感覚になり、この規模のサイトなら良いけど、大規模になってくるとメンテナンス大変なんじゃないかなーという感想を抱いた。 Tailwind CSSのメリットとデメリット | コリス とか Tailwind CSSが私には合わなかった理由 | コリス を読んでなるほどなーと思ったりしていた。

いい感じのデザインにするために Tailblocks — Ready-to-use Tailwind CSS blocks も活用した。サンプルコードが豊富にあり、いくつか参考にさせてもらった。

before / after

改めてbefore / afterを並べると、結構間の抜けたデザインだったのがシュッとした感じになったなぁ、と思う。文字サイズが小さくなったのでリーダビリティが下がったかもしれないので、妥協点を探しながらまた徐々に改善したい。

Tailwindを使ってレスポンシブも簡単にできたのでこれも良かった。

不具合などまだまだある気がするので、何か見つけたらプルリクやissueを投げていただければ対応します。

2年ちょっと前にクラウドファンディングでバックした Astro Slide というスマートフォンがようやく届いた。本体下部に物理QWERTYを搭載していて、独特のスライド機構でクラムシェルを開いたような状態に変形させて使えるという、新しいんだけど懐かしさを感じるようなスマホ。以前から Cosmo Communicator など、この手の端末を幾度か出してきた Planet Computers の新作になる。この文章もAstro Slideで書いてみている。

当初の発送予定は2021年1月だったが、半導体不足やCOVID-19による生産拠点のロックダウンなどの影響を受け、スケジュールは遅れに遅れて現在進行形で結構燃えている。僕はEarly Bird枠だったし、先に生産が開始されたJPキーボード指定だったのでこれでも受け取れたのは早いほうらしい。

Impression

悪くない。実は物理QWERTYを搭載したスマホ自体初めてなので、10年ぐらい前まで跋扈していた先達たちと比べてどうなのかとかはわからないけど、とりあえず実用できなくはないかなという感想。

キーボード

メカニカル構造なだけあって押し心地は悪くない。押し込めばスッと入っていくリニアタイプではなく、ポコっと打ち込んだ感覚があるタクタイルに近い打鍵感。このサイズなら誤タイプを防ぐ意味でこれが正解だとは思うが、たまにちょっと堅すぎるのか打ち漏らすときもある。

配列はめちゃくちゃ独特。これはPlanetの既存端末からそうらしいが、特にハイフンがスペースキーの右かつシフトが必要なポジションにあるのが一番つらい。配列のリマップもできるそうなので改善は可能かもしれないが、まだ試していない。

記号以外に関してはブラインドタッチがそこそこできるレベル。試しに寿司打してみた結果を貼っておく。ハイフンがなぜか検知してもらえず、その分スコアは下がっている。

ちなみに普段遣いのキーボードでの結果はこう。ミスタイプがひどい。

バッテリー

むちゃくちゃ良いわけではないと思うが悪くもない。 Battery Mix でしばらく計測した結果を貼る。

オリジナルアプリ

いくつかPlanet製のオリジナルアプリが入っている。ほとんど使っていないけど、App Barはいい感じ。物理キーボードのPlanetマークを押すと、いつでもDockっぽいランチャーを呼び出せる。

スマホとして使えるか

閉じた状態でスマホとしても使える！というのが売りなわけだが使えないことはない。でも当然ながら分厚い。しばらく触ってからPixel 5aに持ち帰ると薄すぎて感動するぐらい。まぁこれは仕方ない。なので僕はこの端末だけでメインのスマホにすることはないが、やろうと思えばできなくはないんではないか。使い方にもよるとは思うが。

クラムシェルとして使えるか

まあ、使える。タイピングができるのであとはソフトウェア次第で。

多くの場合はSimplenoteを使っている。メインで使っているノートアプリはWorkflowyなのだが、どうもこれが相性悪いようで、今文字を打っている行がうまいこと画面上に表示されてくれず、使えていない。Astroの問題なのかWorkflowyの問題なのか判断もつかずあきらめている。

ソファで膝の上に広げても打てないことはないが、机上に広げるのがやはり安定して打ちやすい。ドトールのテーブルでトレイを端に寄せ、狭いスペースに広げて打ってみたが、あの小さなテーブルならだいぶ体験がよい。

よくないところ

• 指紋認証センサー。ほぼ成功したことがないぐらいにひどい。開いて使っているときはキーボードでPINを打ってしまうから気にならなくなるが。
• 画面の輝度？　ちょっとまぶしくチラチラするように感じる。輝度をかなり落として使っている。
• 出荷段階で液晶保護フィルムが貼られているが、気泡もだいぶ入っているし自分で買った方がいいと思う。幸いAmazonでわりと普通に買える。
• キーボードを収納した状態ではロックされるわけではないので、下のキーボードを指で押すと微妙にぐらつくのがちょっと怖い。大丈夫だとは思うものの。
• 充電は遅い。まだ0→100％充電したことはないが、これまでの実績ペースだと0→100に3時間ぐらいかかりそう。
• Android 12未対応。

設定

使い始めるにあたり設定した箇所をいくつか書いておく。

eSIM

メインスマホにするつもりがなかったのでSIMを挿す気もなかったんだけど、メイン回線で使っているIIJmioなら月440円でeSIMを発行できると知り、それを挿している。こんなに安価に、しかも申し込みから15分ぐらいで回線開通できるのでいい時代だなぁと噛みしめた。メインのSIMとデータ容量はシェアしているので、余るならメイン側の容量を下げればコストもさらに減る。

使い始めるにはまず設定のAstro Settingで、Use eSIM for SIM slot 2にチェックを入れる。

その後、プリインストールのeSIM walletというアプリでアクティベートする。このアプリ、SIMが1枚も挿さっていない状態だと無限にエラーをポップアップするのだが、無視してがんばって右下のアイコンを押せばアクティベートのフローに進める。ただ、1回目の試行ではFailureになってしまい、一度再起動してから2回目に試してようやくうまくいった。アクティベートできたら左下の電源アイコンを押して有効化する。その後設定から、APNの設定を入れたら通信できるようになった。

ATOK

設定の「システム」→「言語と入力」に「物理キーボード」の設定箇所があり、JPキーボードだとデフォルトで「日本語」というキーボードと「日本語 (English)」というキーボードが設定されている。この2つをCtrl + Spaceで切り替えられるのだが、前者はかな入力、後者は英数入力なので、ローマ字入力するにはIMEが別途必要となる。

Gboardをインストールするのが早いが、自分はライセンスがあるのでATOKにした。Gboardは変換候補が入力箇所のすぐ近くに表示されるのだが、これが入力中の文字を隠してしまうことがあり、実用に耐えなかった。ATOKは画面下部に候補表示してくれるのでこの点は良いのだが、変換精度がデスクトップ版と比べて著しく悪いという欠点もある。

設定としては「システム」→「言語と入力」の「画面キーボード」にATOKを追加して、「物理キーボード」から日本語を外して「日本語 (Engilish)」だけにする。これでAlt + SpaceでATOKの日本語と英数が切り替えられるようになる。

小さなQWERTYを持つこと

自分のポリシーというか方針として、小さなQWERTYを持っていたい、というのがある。外出先や旅先で考え事をしたり、ブログのように長文を認めたりするときにノートパソコンを持って行くのでは重いのだけど、スマホのフリックでは入力が遅いので、机上で打てる小さなQWERTYが欲しい。これまでにpomeraやGPD Pocketなどを買ってきていて、Astro Slideはその流れで買っている。

なのでCPUが当初予定から格下げされたことなどはあんまり気にかけていなくて、ひとえに文字を打つ端末として実用に耐えるかで評価しており、その点では及第点かな、と思う。不満点として配列の特殊性といったハードの問題もあるが、Androidの日本語入力環境の問題も結構大きい。当たり前かもしれないがデスクトップ用のIMEのようなカスタマイズができるわけではなく、例えばATOKだと文節調整に矢印キーを使うのだけど、デスクトップだと普段はこれをShift+矢印キーに割り当てているので結構戸惑っている。Android版ATOKではこのあたりのキーリマップはできないので慣れるしかない。なので十全な文字入力環境とは言い難いのだが、じゃあその不満の解消のためだけにmacbook持ち歩くかと言われるとそれも嫌なので、ちょっとカフェで考え事したい、みたいなときには今後しばらくはAstro Slideを使うと思う。

言うまでもなく極めて特殊な端末なので、もろ手を上げて最高！とはちょっと言えないし、そもそも生産出荷状況がいまいちなので、量産される見通しも現段階では立っていない。もし一般に買える段階が来たら、ガジェット好きな人なら買ってもいいんじゃないですかね、ぐらいの感覚。

APMなどを提供する Dynatrace が公開している、State of SRE Report 2022を読んだ。Dynatraceがグローバルに450社に対して調査を行った結果をまとめている。なおグローバルとはいえ調査対象の33%がアメリカでほとんどが欧米、日本は対象に入っておらず、偏りはあると考えたほうが良さそうではあった。企業規模でもグローバル企業が中心のためか、3000人未満の会社は1割程度で、3割の会社が20000人を超えており、大企業がほとんどとなっている。

このレポートではSRE発足から2年以上を経過している企業をMaturing、5年以上をAdvancedと定義しているが、前者が42%、後者が20%となっていた。『サイトリライアビリティエンジニアリング』日本語版が発刊されたのが2017年なので、5年以上SREをやっている企業は、本邦だと2割にも及ばないのではないかという感覚がある。そう考えるとSREはやはり、まだまだ探求が続けられている職種であり、こういった実情を調査するレポートがあるのはありがたい。

Apdex

このレポートで初めて知った概念の1つに Apdex があった。ユーザー満足度を示す指標であり、調べたところ2004〜5年頃よりあるものらしい。

ざっくり概要を示すと、こんな指標である。

• レスポンスタイムの閾値 T を定義し、レスポンスタイムが t のときのユーザーの満足度を以下のように考える
  • T >= t : 満足
  • 4T >= t > T : 許容
  • t >= 4T 、あるいはエラーの場合 : 不満足
• Apdexスコアは全リクエストに対する割合で0〜1の数値で示される
• 「満足」だったリクエストは1、「許容」だったリクエストは0.5としてカウントする

レスポンスタイムの閾値を設けるのはよくある話だが、満足度にグラデーションを設けている点と、エラーレスポンスを加味している点がポイントになる。確かに、単にレスポンスタイムだけを元にして考えると、素早く503を返したレスポンスもOKな扱いになってしまう。

このレポートではSLIの例をいくつかピックアップしており、その1つとしてApdexが挙げられていた。2段階の閾値を設けることになるので検討は難しくなるが、よりユーザー中心でレスポンスの満足/不満足を考える上では参考になりそうに思う。調べたところ、New RelicもDatadogもApdexの算出には対応しているらしい。

また、レポートで挙げられているSLIの例は、Business SLOsとPerformance SLOsに分類されていた。どのようなSLOを設けるにせよ、最終的にはビジネス的な価値に結びついていなくてはならないと考えているので、この分類はするっと飲み込めない部分もあった。が、SLOを考える際に、その指標は直接的にビジネス的な、ユーザーと密接にかかわる指標なのか、単なるパフォーマンス指標なのかという観点はあってよさそうに感じた。

その他

その他、気になったところをいくつかピックアップしておく。

• SREはcultural changeである。
• セキュリティは信頼性の主軸であり、DevSecOpsへより注力したいと考えているSREが過半。
• 信頼性に関するKPIを達成した際に、specific bonuses/rewardsが出る企業が76%。
  • SLOではなく KPIs around reliability と書いているので、単純に信頼性を守れたかというより、チャレンジングな指標を達成できたかではないかと思う。
  • いずれにせよ、「信頼性を守っても当たり前品質として扱われてしまう」という不満の解決策としてはアリかなと思う。
• SLOを設定するにあたり、99%のSREが何らかの困難に直面している。
  • サイロ化したチーム構成によるツールの細分化、複雑化するアプリケーションに適切なSLOを設定することなど。
• SREを採用すること、育成すること、いずれも困難と感じているSREが多く、またそのことを組織的な共通認識にすることも難しく感じている。
• 将来的にAIOpsがSREプラクティスにとって大きな鍵になるのではないか。
  • 信頼性劣化に対するプロアクティブなアプローチへの活用、など。

AWS LambdaでHTTPSエンドポイントがデフォルト利用できるようになり、API Gatewayを付与する必要がなくなった。早いもので、すでにServerless FrameworkもTerraformも対応しているのだが、せっかくなのでLambdaのデプロイには使ったことがない、Terraformで試してみた。

Terraform with AWS Lambda

AWS LambdaでTerraformを管理するというのはあまり一般的なケースではなく、僕もServerless Frameworkなどを使うことが多い。

改めて、なぜTerraformでAWS Lambdaを管理しないのか、言語化してみるとポイントはいくつかある。

Terraformはattribute差分による状態管理を行う

Terraformの基本的な考え方は、クラウドリソースのattributeについて、HCLで記述された状態と実際の状態とを比較し、差分があればそれを適用の対象とする、というものである。AWS Lambdaの場合はソースコードをデプロイするわけだが、その差分はソースコードをzip化したもののハッシュ値を用いて比較することが多い。

しかし、Lambdaでアップロードするzipには、依存ライブラリなどすべてのファイルを含めることになるので、ライブラリインストールにおいて予期せぬ差分が発生する場合がままある。その上Terraformの plan 結果で表示されるのはハッシュ値の差分だから、何が実際の差分なのかは判別ができない。

TerraformはあくまでAWS APIのラッパー

Terraformは基本的にAWS APIをラップするものでしかない。従ってAWS LambdaのFunctionを作成、変更、削除はできるが、コードの依存ライブラリをインストールして、zipに圧縮して、といった作業をうまいことお膳立ててくれるわけではない。Terraformのbuilt-inな機能を使えば実現は可能だが、Serverless Frameworkなど専用のフレームワークを使ったほうが上手いこと付随処理を隠蔽してくれる。

Example

そういったデメリットを理解しつつ、試しに書いてみたTerraformが以下の通り。

resource "null_resource" "lambda_function_pre_build" {
  triggers = {
    packages = filebase64sha256("${path.root}/function/package.json")
  }

  provisioner "local-exec" {
    working_dir = "${path.root}/function"
    command     = "npm i"
  }
}

data "archive_file" "lambda_function" {
  type        = "zip"
  source_dir  = "${path.module}/function"
  output_path = "${path.module}/lambda.zip"

  depends_on = [
    null_resource.lambda_function_pre_build,
  ]
}

resource "aws_iam_role" "iam_for_lambda" {
  name = "iam_for_lambda"
  managed_policy_arns = [
    "arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole",
  ]


  assume_role_policy = <<EOF
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Action": "sts:AssumeRole",
      "Principal": {
        "Service": "lambda.amazonaws.com"
      },
      "Effect": "Allow",
      "Sid": ""
    }
  ]
}
EOF
}

resource "aws_lambda_function" "tweet_url" {
  filename         = data.archive_file.lambda_function.output_path
  function_name    = "tweet_url"
  role             = aws_iam_role.iam_for_lambda.arn
  handler          = "index.handler"
  source_code_hash = data.archive_file.lambda_function.output_base64sha256
  publish          = true
  timeout          = 10

  runtime = "nodejs14.x"

  environment {
    variables = {
      AUTH_TOKEN = "XXXXXX"
    }
  }
}

resource "aws_lambda_function_url" "tweet_url" {
  function_name      = aws_lambda_function.tweet_url.function_name
  authorization_type = "NONE"
}

output "function_url" {
  value = aws_lambda_function_url.tweet_url.function_url
}

今回はNode.js14.xで書いたので、 null_resource を使って事前に npm install を行い、 data.archive_file によってzip化を行っている。自分で試しに書いてみると、楽ではないがやれなくはないな、というところだった。取りあえずやってみるの大事。

肝心のURLだが、 aws_lambda_function_url をfunctionに紐付けるだけで設定できる。 authorization_type は NONE か AWS_IAM の2択であり、今回は X-AUTH-TOKEN headerを読み込んで、コードの中で簡易的な認証をかける形とした。このほか、CORSの設定ができる。

なお、今回のソースコードは慣れないNode.jsで書いたためめちゃくちゃ汚い気がするので割愛する。以前から個人的に欲しかった、「URLを投げつけると、タイトルを自動取得して『Browsing : タイトル URL』形式でTwitterに投稿してくれる君」を作ってみている。

Lambda Function URLsでできること

https://docs.aws.amazon.com/lambda/latest/dg/urls-invocation.html

リクエストからのヘッダー、body、query stringなどの読み取りは一通りできるし、レスポンスにもヘッダー、bodyなどは含められるので、簡単なAPIを作りたい場合などはこれで事足りそうに感じた。

ただ、ドキュメントを読んだ限りではCloudFrontが介在するわけではなさそうだし、エンドポイントのパスを自由に設定できたりもしないので、API Gatewayの完全互換なものではないことには注意したほうがいいかもしれない。

Embedded SREとは何か

SREがプロダクトチーム内の職能横断の1つとして配置される体制をEmbedded SREと呼ぶ。これはプロダクトチーム、開発チームの外で中央集権的に組織され、各プロダクトを横断的に見るようなSREの組織体制と対置されている。プロダクトサイドとしては、チーム外にいるSREとのコミュニケーションパスを無くすことができるし、SREの側もそのプロダクト固有のドメイン知識の中で最適化された作業ができる、というメリットがある。

国内では 開発チームとともに歩むSREチームが成し遂げたいこと | メルカリエンジニアリング でメルカリが、 Topotal CTOの@rrreeeyyyさんにSREについて聞いてみました! | CyberAgent Developers Blog でCyberAgentが言及していたりと、各社取り組んでいる事例が見られる。メルカリのように、元々インフラチームであったものをSREへ改組した場合、そのままの組織体制だとSREは中央集権的になってしまう。プロダクトが増えたり、SREの業務の幅が広がる中で限界を感じ、Embedded SREに転じていく事例が多いと見ている。

SRE booksにおける「Embed」という表現

Googleが発刊しているいわゆるSRE booksと呼ばれる『サイトリライアビリティエンジニアリング』『サイトリライアビリティワークブック』、あるいは『SREの探求』においては、SREの組織体制をどうするべきか、という話題には乏しく、「Embedded SRE」という単語も直接は登場しない。

ただ、SREを「Embed」するという表現は『Site Reliability Engineering』の「Chapter 30 - Embedding an SRE to Recover from Operational Overload」において見られる。ここでは、SREチームの運用作業が過負荷になった際、その原因となっているチームへ一時的にSREを移籍させ、チームのプラクティス改善を行うというGoogleのケースが紹介されている。SRE booksの中では、SREチームがプロダクトチームからプロダクトを受け入れ、トイルやアラートが多すぎればプロダクトを差し戻す場合があると書かれている通り、GoogleにおけるSREチームはプロダクトとは別チームとしてとどまっているようである。

『SREの探求』では第10章において、少しだけ組織論への言及が見られる。ここで言及されているのは1つが先のGoogleの事例で、これは「Googleモデル」と呼称されている。もう一方は「Netflixモデル」とされている。

SRE（および他の機能別の役割）をプロダクト専用チームに参加させるものです。この方法では、サービスを開始から廃止まで所有できる機能横断型チームが作られます。開発と継続的な運用はすべて、この機能横断型チーム内で実行されます。大企業の観点からすると、これは概して、従来の組織モデルからの完全な離脱とみなされます。聞いたことがある人もいるでしょうが、このパターンはNetflixモデルと呼ばれる場合があります。

これは要するに「Embedded SRE」に相当するようと考えていいだろう。

Embedded SREという呼称を辿る

メルカリが先のエントリーの中で「Embedded SRE」の出典として引いているのがSlalom Buildによる The Many Shapes of Site Reliability Engineering | by Rob Cummings | Slalom Build | Medium というエントリーである。これが2019年1月に書かれている。

この中で書かれているEmbedded SREは、やはりプロダクトチームの中に組み込まれ、信頼性やスケーラビリティの点で専門を担うとされている。なお、EmbedというとSREを外からプロダクトチームへ埋め込む（参加させる）ような印象を受けるが、ここではプロダクトチームが専任のSREを自ら雇ってもよいとしている。

では、このエントリーが「Embedded SRE」の原典なのかと言えば、実のところこれ以前にもまだ辿っていくことができる。どうもロールとしてのEmbedded SREという呼び方は2018年以前からLinkedInが使っていたようで、 How Bad Is Your Toil?: Measuring the Human Impact of Process | USENIX や 3 Myths About the Site Reliability Engineer, Debunked の中で確認できる。ただし、いずれも「私はEmbedded SREとして働いています」という程度の使い方であり、Slalom Buildのエントリーのように、組織類型をまとめたような内容のものではない。

明確な組織論として書いているものの1つには、New Relicの SRE-iously: Defining the Principles, Habits, and Practices of Site Reliability Engineering がある。これは2018年8月のスライドであり、Embedded SREはDomain Expertsだとされている。この絵も国内でよく引用されているのを見かける。

そしてさらに遡ると、LyftのエンジニアであるMatt Kleinという方が2018年6月に書いた The human scalability of “DevOps” | by Matt Klein | Medium がある。SREをプロダクトチームの中へ組み込む必要性を説いた上で、それをEmbedded SREと呼んでいる。明確なロールとしてEmbedded SREの在り方を説明したものとしては、僕が辿れた範囲ではこれが一番古いようだった。

The goal of embedded SREs is to increase the reliability of their products by implementing reliability oriented features and automation, mentoring and educating the rest of the team on operational best practices, and acting as a liaison between product teams and infrastructure teams (feedback on documentation, pain points, needed features, etc.).

このエントリーは今回初めて目にしたが、DevOpsとは何か、なぜ必要なのか、それを組織をスケールさせながら実践する上で、SREをどのように実装するべきなのかと順序立てて説明しており、非常に読み応えがあった。

Embedded SREの対置概念

多くの記事では、SREはプロダクトチームに組み込まれるか、プロダクトチームの外で集約的に組織されるかという2つの組織類型を対置的に書いている。集約型SREについてはEmbeddedほど統一された呼称がないようで、様々に呼ばれている。先のSlalom Buildのエントリーでは、中央集権的に組織され、会社全体の信頼性コンサルティングを行うようなSREは SRE Center of Practice と呼ばれているし、New Relicのスライドでは Pure SRE と呼ばれている。

SREの元祖たるGoogleが組織類型に言及したのは SRE at Google: How to structure your SRE team | Google Cloud Blog ぐらいだと思うが、この中ではさらに細分化した6種類の分類が書かれている。なお、これが書かれたのは先のエントリー群よりも後、2019年6月になる。僕がEmbedded SREを初めて目にしたのもここだったように思う。

Kitchen Sink a.k.a Everything SRE

プロダクト横断的な中央集権のSREチーム。まだ担当プロダクトが少ない、SREの実装の初期段階にあたる。

Infrastructure

Kubernetes Clusterや監視システムのような共通で使用されるインフラ整備に携わるSRE。

Tools

開発者が信頼性を維持するのに役立つようなツール、ソフトウェアなどを構築、提供するSRE。

Product/applicaton

重要なプロダクトの信頼性向上に取り組むSRE。Embeddedのようにプロダクト専任に近い形と思われるが、まだプロダクトの内部には入り込んでいない点が相違点と思われる。

Consulting

プロダクトのコードを直接変更は行わず、コンサルティングやツールの提供に責任範囲をとどめる。最初のSREチームを実装する前に、パートタイムのSREをコンサルトとして配置するようなパターンが想定されているらしい。

Embedされていない場合において、その役割は多岐に渡る可能性があることがこのエントリーからは読み取れる。各プロダクトの信頼性向上に尽力する場合もあれば、サポート程度までしか行わない場合、あるいは完全にプラットフォームの整備へ注力する場合（個人的には、これはほぼインフラエンジニアではないかと思ったりするが）まで考えられる。SREチームとプラットフォームのインフラチームを別で用意できるほどに人員が豊富な事例というのはそれほどない気がしていて、僕としてはこのGoogleの6類型を使って、どのロールをどの程度担っているか、担っていくかと考えるのが一番しっくりきている。

なお、 Embedded SREs within the SWE team or a separate SRE team entirely? - Pros and Cons では、このGoogleの6類型をざっくりとEmbedded SRE Teamsと Dedicated (Stand-alone) SRE Teams という2つに分類し直して再度論じている。SREがプロダクトチームの内外どちらにいるか、という点だけで分類するなら、この呼び方がわかりやすいかもしれない。

単位修得状況

修得単位数はこちら。

| 評価 | 2年次 | 3年次 | 4年次 | |:--:|:--:|:--:|:--:| | S | 8 | 2 | 4 | | A | 12 | 8 | 6 | | B | 4 | 4 | 6 | | C | 0 | 4 | 0 | | 合計 | 24 | 18 | 16 |

昨年よりさらに修得単位数が減った。時間が取れていないというほどでもないのだが、単純な話として応用的な科目が多くなり、より時間をかけなければ理解できなくなってきたな、と感じている。特に数学への苦手意識がなかなか抜けない。しかし、例えばフーリエ変換はいろんな科目の基礎になってくるわけで、1つの苦手意識が様々な科目に波及することが、応用的科目が増えるにつれて多くなってきた。たまに心底しんどく思うときはある。もうやめようかな、というのは2回ぐらい今年考えた。まぁでも、今のところやめるつもりはない。

それでも少しずつ理解は進むし、それは純粋に嬉しいし、楽しんで勉強はできている。学部教養というのは基礎的な内容なので、本業にはやはり直接短期的に意味をもたらしてくれることは多くないが、それでも無駄ではないことはわかる。恥ずかしながら光ファイバの物理的な仕組みなんて、大学に通わねば知ることはなかったかもしれないな、と思う。先日拝見した 6社合同 SRE勉強会 でも「全単射」という単語が出てくる機会があったが、この単語も僕は大学で初めて知った。あるいは、学んだことをどうすれば活かしていけるか、ともっと能動的に考えてもいいのかもしれない。

残り34単位。今のペースを守りつつ、あと2年での卒業を目標とすることにした。仮に2年で卒業できなくても、まだバッファが2年ある、という計算。これぐらいならなんとかなるのではないか、いや何とかしよう、という所存。

今年の変化

履修管理はGitHub Projectに移行

1年目はスプレッドシート、2年目はNotionデータベースのカンバンを使っていて、3年目はGitHub Projectになった。

課題やレポートもGitHubのプライベートレポジトリで管理しているので、結局のところこれが一番シンプルだし自分の日々の仕事と同じペースで進められるのでしっくりきた。

テプラLiteを買った

手で自分の氏名と住所を書く機会がとにかく多い。レポートを出すときは返信用封筒と送信用封筒のそれぞれに書かねばならず、さらにレポートに貼り付ける課題票という紙にも氏名が要る。さらに昨年度からはコロナ禍で試験の自宅受験が多くなり、試験答案も封筒で送らねばならなくなった。些細な機会ではあるもののどう考えてもToilであり、自動化は大事ということでテプラを買った。

https://www.kingjim.co.jp/sp/lr30/

テプラLiteはスマートフォンアプリからBLEで通信して使うテプラで、とても手軽に扱えてちょうどいい。最初のうちは通信がうまくいかなかったり、日本語入力のバグっぽいものに捕まったりもしたが、慣れてきたらスムーズに使えるようになった。ついでに家の中のちょっとしたラベルなども作れるようになり、買ってよかったと思う。

氏名と住所のシールを大量に印刷して、レポートを出すときはそれを貼るだけで良くなったのでだいぶ楽になった。

Ankiを再開した

一昨年度、とかく「覚える」ために通勤電車内で使っていた Anki 。昨年度は通勤がなくなったのと同時に自然と使わなくなっていたのだが、今年は再開した。何かを覚える上では本当に効果的で優れたツールだと思っている。通勤は相変わらずほとんどしていないのだが、今年は隙間時間に起動して眺めるようにしていた。

わずか1回の通学機会

昨年度から試験がオンラインになり、年間数少ない大学通学の機会も消滅していたのだが、今年度は1回だけ通学できた。昨年秋頃、ちょうど第5波と第6波の間で行われた試験だけが対面開催になった。

顔を知っている学生もそれほど多くないので、だからどう、というのもあんまりないと言えばないのだが、それでも少し嬉しかった。キャンパスのある十条駅周辺は再開発の真っ最中で、入学した頃に建っていた建物は軒並み無くなってしまっていた。2024年度竣工予定だそうで、わりと自分の卒業とどちらが早いかチキンレースになりかねないなぁとか思っている（自分は最長で2026年3月まで大学にいられる）。キャンパス内では、試験の合間にイタリアントマトで一息つくのが常だったのに、それもスタバに変わってしまって、席はなかなか空かなくなっていた。駅近くの『煮干そば 流。』が美味かった。

まん延防止措置と緊急事態宣言が試験オンライン化の条件になっていたので、来年度こそは通学機会が増えてくれたらと思う。たまの気分転換にもなるし、自分が大学生であることの実感を持てるのは、悪いものではない。

今年受けてよかった科目

幾何学

これは純粋にただただ楽しかった。幾何学を学んだことがない身としては、幾何学って要するに四角形とか図形のことでしょ、ぐらいの頭でつまるところユークリッド幾何学しか想像できなかったんだけど、こんなに様々な考え方があるとは思ってもいなかった。取っ手が付いたマグカップとドーナッツは同じものなんです、とか。平行線が絶対に常に交わらないわけじゃない、とか。

ちょっと余談っぽくはあるけど、『チーム・トポロジー』（topology = 位相幾何学）を読んでしっくりきたのは、この科目を学んでいたおかげかもしれない。

ディジタル通信

光ファイバの仕組みとか。あとは標本化定理やフーリエ変換といった、他の科目で学んできたことがここで活かされて勉強を積み重ねていくことの意味というか、喜びみたいのを味わえた気がする。音声をデジタルの波形に変調する仕組みなどもまったく知らない分野だったので楽しめた。

オペレーティングシステム

IPAの資格でとか、仕事の中でとか、幾度となく学んできているOSの仕組み、これで何度目か、という感じの。最近は低レイヤー触るということもあんまりないので定期的に学び直すのも良いのだろうなと思っている。今年受けた中ではおそらくもっとも実技というか、今の仕事に直結しそうな科目。

『ライティングの哲学』は、「書くこと」を職業とする学者やライター4人が集まって、如何に工夫していつも書いているのか、あるいは如何に書けていないのかということを座談会で赤裸々に語る本だ。IT系のエンジニアは別に書くことが飯の種というわけでもないので、一見関係ない本ではありそうなのだけれど、存外に参考になることが多かった。

本書で語られる「書けない」という悩みは、いわば「仕事に向かうために重い腰を上げられない」に近い部分があり、ならば「書かないで書く」という話が出てくる。

「えーっと」とか「今日はフリーライティングしてみるわけだけど」とかもひとつひとつ全部、箇条書きにしていくんですよ。そうやって書いていると、だんだん思考が凝縮されていって、電話しないといけなかったことを思い出したり、カレンダーに入れ忘れていた用事が出てきたりと、仕事が発生してくる。文章を書くときに構えてしまうことを突破するために、ぼくは以前「書かないで書く」というキーフレーズを考えたんですが、それは要するに「規範的な仕方で書かない」という意味なんですよね。脱規範化するためには、「そんなの書いてるうちに入らない」くらいの雑な書き方であっても書いてしまえばいい。

頭の中でまとまらない思考も、実際に言語化することでまとまっていき、解決策を思いついたりすることは、ライターではなくともよくある。エンジニアリングの仕事は、1日の大半が何かを考えることで、ともすると頭の中でもやもやとただ考えがちなところを、書きながら考えるようにしてみるとよかったりする。これはつまるところ、ラバーダック・デバッグとか、「壁打ち」と言われる手法と似た話だと思う。頭の中で考えるときにも言語を使うのが人間だとは思うが、それを実際に言葉でアウトプットしてみると、意外とすんなり考えがまとまっていく。壁打ちなどは会話の形式なので音声言語が用いられるが、文字で書くことで思考は目に見える形になり、より扱いやすくなると個人的には感じている。

ライティングというのは要するに、頭の中にある思考を論理的にまとめてアウトプットする過程であり、それは極端な話、エンジニアであっても似たようなことをやってはいて、出力が日本語なのかプログラミング言語なのかが大きな違い、というだけだったりはする。なので、結構エンジニアの立場から共感できる話はこの本には多い。

エンジニアと「書く」こと

つい先日も、 日記駆動仕事術のススメ | DevelopersIO というエントリーが話題になっていたように、エンジニアの中でも「書く」ことを勧める話は少なくない。日記、日誌、日報の関連では、『 達人プログラマー 』にも「エンジニアリング日誌」という話が出てくる。これは、自身の実績を後々客観的に振り返る意味で日報を書くべきだという話であり、 日報・週報を自分の役に立てるために書く - 発声練習 でも書かれている通り、思考・研究などを生業にする人には当たり前のような習慣なのかもしれない。『数学ガール』などで知られる結城浩さんもたびたび「作業ログ」の重要性に言及しており、 有料で自身の作業ログを公開 までしている。

そのような判断をするためには「作業ログ」や「日誌」や「日報」のようなものが重要になります。自分は今日何をしたか。自分は今週何をしたか。自分は今月何をしたか。それらを淡々と振り返る手段を構築しておくことは極めて重要です。

— 結城浩 (@hyuki) July 15, 2021

僕がこの手の「エンジニアと書くこと」について初めて読んだのは 「書く」のは特別な道具 - naoyaのはてなダイアリー というエントリーだ。これは先のような振り返りの視点というよりは、『ライティングの哲学』と同じく、「書いて考える」ための話だ。このエントリーは何度も読み返している。何年か前にはSlackにおける「分報」のムーブメントもあったが、あれも書いて考える一環であり、そして一人ではなくチームでの思考を助長する面もあった。

また 様々なTODOアプリやタスク管理方法を試行した結果最終的にプレーンテキストに行き着いた話 - みんからきりまで のように、タスク管理も「書く」ことでテキストベースで行うという話もある。手法として確立された todo.txt のようなものもあるし、タスクだけではなく、一緒にメモから何から管理していこうとなれば Org mode for Emacs もある。

書くことで思考を掘り下げる、やるべきことを明確化する、やったことを記録しておくなどなど、エンジニア界隈での「書く」ことの有用性の話は数多い。

アウトライナーで書いて考える

『ライティングの哲学』では、書くツールとしてアウトライナーがピックアップされる。著者の一人である千葉雅也さんは、以前から 千葉雅也インタビュー「書くためのツールと書くこと、考えること」｜もの書きのてびき｜書く気分を高めるテキストエディタ stone（ストーン） などでもアウトライナー Workflowy の話をたびたびしているアウトライナー愛好家だし、半ば「アウトライナーの本」と言ってもいいかもしれないとすら感じる。

僕もメモを取るためのツールは QFixHowm を使ったり、シンプルにKobitoでMarkdownを書いたり点々としてきていて、その中でアウトライナーも使ってきている。アウトライナーが良いのは、文章を前後で入れ替えたり、入れ子の構造を作ったり、入れ子構造のchildだけにフォーカスして画面表示したりと、一度書いた文章を自由に切り貼りできる点にある。ざっくり「箇条書きを超柔軟に使えるツール」と言ってもいい気はしている。何かに行き詰まって、とりあえず今頭にあることを数行ガタガタガタっと書いてみる。その中で「あー、このあたり調べたほうが良さそうだな」というところがあれば、その行だけを画面に表示して、配下に文章をまた足していって……というような、思考を掘っていく過程を視覚的に再現できる。

アウトライナーのウェブサービスでは、特に Workflowy と Dynalist の2つをよく耳にする。僕も最初に触れたのは2015年に登録した Workflowy で、その後一度アウトライナーを離れてから、2019年に Dynalist を使い始めた。そして先々週ぐらいからは Legend という比較的マイナーなものを使い始めた。

僕はタスク管理 + 日報のような用途でアウトライナーを使っていることが多い。今やるべきこととか、注意を向けたいことの全体像のリストと、今日やることのリストという主に2つがあり、「全体像のリスト」から「今日やることのリスト」にタスクを持ってきて1日が始まる。日中は「今日やることのリスト」の中でメモを取りながら過ごして、その中でタスクが発生したり、今日やりきれないタスクが出てきたら、「全体像のリスト」へ送る。1日の終わりに、完了したタスクとメモが「今日やることのリスト」に残るので、それを日報として残している。このあたりの方法は、 その日付をすてろ とか色んなエントリーの影響を受けている。

ただ、ずっとカッチリとメモを残せてきたかと言うとそういうわけではない。僕は基本的には筆無精だし、頭の中で悶々と考え続けてしまう時間が大きい。それをどうにか解消したくて、ずっとメモツールにしがみついたまま生きている。

先ほど、アウトライナーは「箇条書きを超柔軟に使えるツール」と書いたが、一方で箇条書きは「文章を書こう」というモチベには繋がりにくい面も感じている。多くのアウトライナーは箇条書きのようなバレットが必ず先頭につくのだが、どうもこのUIだと細切れの単語しか書けないことが多かった。なのでゴリゴリと長文で思考を書き付けきることができず、断片的なよくわからない単語の固まりにしかならないことがあった。

Legendを使っている理由の一つは、わりと些細な話で、このバレットがキーボードショートカットで消せることにある。でもそれがすごく重要で、これだけで「文章を書こう」という気分がかなり醸成されるようになった。また、Markdownのように # を頭に付けると見出し化してくれる機能もあるのだが、このとき前の行といい感じにマージンを空けてくれて、これもまた書く気分を高めてくれる。それなら要はMarkdownエディタでいいじゃないかという話になりそうだし、それはその通りだと僕も思う。Legendを使ってみて気付いたのは、僕が欲しかったのは自在に階層構造間で文を移動できるMarkdownエディタだったんじゃないか、ということだった。クラウドでの同期ができるなら、org-modeを気に入っていた可能性もある。

もちろん他にもLegendに利点はあって（アウトライナーに興味ない人はこの段落を読み飛ばして大丈夫）、他のアウトライナーがだいたい常に1画面でしか表示できないところ、Legendは複数のタブを作ったり、タブの中にマルチペインで複数のアウトラインを並べて表示できる。僕の使い方で言えば「全体像のリスト」と「今日やることのリスト」を並べられるのがすごくいい。また日付付きのチェックリストを作ると、org-modeのAgenda Viewsのように一覧できる機能もある。アウトラインの全体像をサイドバーに表示して、クリックして好きな箇所を表示できる機能は、日報を振り返る上で重宝する。まだまだ発展途上のようで、正直バグに突き当たることもあったりはするのだが、開発も活発だし、使用感が気に入っている。ちなみに、GmailやGoogle Calendarとも連携できて、それらとアウトライナーの間で情報を行き来させ、ツールをまたいでToDoなどをOrganizeできるというのがLegend最大の売りらしいのだが、そこにはあんまり興味を持てていない。なお、今回DynalistとWorkflowyを避けた理由は、先のアニメGIFの中に書いている。

IDEやテキストエディタで好きなカラースキームを選ぶように、文章を書く上でも、気分が上がりやすい、集中しやすい環境を整えるのは重要なことだと捉えている。つい書いてしまうような環境であることが理想的だ。『ライティングの哲学』では、こういう状態を「依存によって書く」と呼んでいた。Twitterについつい何か書き込んでしまうアレだ。あの状態を、手元のアウトライナーで作る。そして脳内にあることがするするとアウトライナーの上に表現されていく。それを整理するうちに考えが整理されていき、仕事が進んでいく。そして書いたメモは、もう少し整形して文章として整えてやれば、そのままScrapboxにストックしたり、ブログなどにアウトプットできる。まだそこまでの域には達していなかったりはするが、そんな状態が理想だな、と思いながら日々書いている。

『ライティングの哲学』ではこういった流れを作り上げる話が展開されているのだが、それはライティングに限らず、考えて仕事をする人全般に応用できる話ではある。

Export cache

先のエントリーの type=gha cache は BuildKit の export cache における機能の1つ。

export cache には gha の他に、 inline 、 registry 、 local の3タイプがある。 inline は image と一緒に cahce をメタデータに書き込んでレジストリへ送る。 registry は image とキャッシュを分けて、キャッシュは cache manifest という形式でレジストリへ送る。ghaはGHA最適化であり、 local は読んでそのままローカルにキャッシュを出力する。

inline はmin modeでしか使えない制約がある。min modeは結果イメージのレイヤーしかキャッシュしないが、max modeはすべてのレイヤーをキャッシュする。

そのため registry でmax modeを使うほうがよいのだが、これについてはコンテナレジストリによってはcache manifestに対応していない場合がある。例えばAmazon ECRは対応していない。ECRを使っていて registry を使いたい場合、cache manifestに対応した、例えばGitHub Container Registryへcacheだけを送る、という荒技もあるようではある。

https://github.com/aws/containers-roadmap/issues/876

GitHub Actionsでキャッシュするなら、わりと何も考えずに使える gha が便利。ただし、現段階ではexperimentalであることは念頭に置いたほうが良さそう。その点を懸念するのであれば、 type=local を actions/cache と一緒に使うのが穏当か。

apt-get upgrade in Dockerfile

Dockerfile内で apt-get upgrade など、 base imageに含まれるパッケージを一括でアップグレードする書き方は従来非推奨になっていたが、これは現在非推奨ではなくなった。

https://github.com/docker/docker.github.io/pull/12571

非推奨ではなくなっただけで、推奨になったというわけではない。Dockerfileで apt-get upgrade を書くかどうかは是非が分かれるところだと思う。base imageのパッケージに脆弱性があった場合、それに対処できる可能性があるが、一方でコンテナビルドの冪等性は失われることになる。

僕としては apt-get upgrade して良いのではないかと考えている。理由としては先のPRを提案したItamar氏の The worst so-called “best practice” for Docker にほぼ同意するところ。昨年 Docker Hub公開イメージ400万の半数に重大な脆弱性が見つかる というレポートもあった通り、Docker Hub上のOfficial Imageであってもパッケージに脆弱性がある場合は少なくない。正攻法としてはImage提供元に連絡してアップグレードしてもらうことだが、実際にコンテナビルドしていてもそれほど早く脆弱性対応されている状況とは認識できていない。ならば apt-get upgrade してこちらで対応してしまうのはありだと思う。冪等性に関してはビルド済みのイメージに対して求めれば運用上は十分であり、「同じDockerfileからビルドすれば同じものができる」状態はあまり求めていない。

RUNを1行で書くか否か

かつては「RUNの中でコマンドを && で繋げて1行で書きましょう」というのが盛んに言われていた。マルチステージビルドの登場によりこの状況は変わりつつある。中間イメージのレイヤー数は最終イメージに影響しないので、中間イメージの中であれば RUN を1行で書かなくても良いという話。

ただ注意しなくてはならないのは、 RUN を1行にまとめていた理由はレイヤー数の問題だけではなく、レイヤーキャッシュの観点もあったということ。1行にまとめていたコマンドを複数行に分けることで、キャッシュも別々に取られることになるわけだが、それで不都合がないかは気をつける必要がある。

今回調べていてよく目にしたのが、 RUN apt-get update && apt-get install hoge も複数行に RUN apt-get update と RUN apt-get install hoge で分けられますという話だが、これを分けて嬉しい場面はそれほど多くない気がしている。例えばインストールするパッケージを追加したくて後者を install hoge fuga に変更したとする。このとき apt-get update のレイヤーは、コマンドに変更がないのでキャッシュが使われたままになり、 fuga は古いバージョンのパッケージがインストールされる可能性がある。このことは Best practices for writing Dockerfiles | Docker Documentation の中でも言及されている。

なお、 && で繋げて書く記法は煩わしいものではあるが、 docker/dockerfile:1.4 でヒアドキュメントが導入されており、こちらのほうがいくらかマシかなと感じている。

syntax = docker/dockerfile:1.4
FROM debian
RUN <<eot bash
  apt-get update
  apt-get install -y vim
eot

Dockerfile syntax

Dockerfile syntaxもどんどん新しい記法が取り入れられており、 buildkit/syntax.md at master · moby/buildkit にまとめられている。新しい記法はDockerfileのバージョンによって使用可否が変わるので、使いたい記法に合わせてファイルに # syntax=docker/dockerfile:1.3 というフラグを1行入れる必要がある。

特に RUN --mount=... 記法は非常に便利。--mount=type=hoge の hoge 部分によって機能がまったく異なるので一言ではまとめづらいのだが、すべて目を通しておくと良さそう。例えば RUN --mount=type=cache,target=/root/.cache/go-build go build ... とすると、ディレクトリ指定でのキャッシュを取ることができ、パッケージインストールなどで効果を発揮する。--mount=type=secret では、例えばビルド時に一時的にAPI実行で必要なキーなどを秘匿的に読み込み、最終イメージには焼き込まないようにできる。

Digression

AWSとかTerraformとかDatadogとかはわりと追えているんだけど、Dockerfileに関しては全然追えてね〜〜という感じだったのが身に染みた。まぁ、こういうのは気付いた段階でGitHub Releaseとか公式ブログとかをちまちまRSS Readerに突っ込んでいく他ないとは思うのだが、CloudNative界隈に携わっていると本当に追うものが多くて大変という感じ。一度調べてベストプラクティスに則った設計が出来たぞいと思っていても、1年ぐらい経つとすでにDeprecatedですなんてことはざらにある。情報をザッピング的にサクサクと仕入れていく必要性をひしひしと感じているのだが、このあたりはみなさんどうやって効率よく情報を集めているんだろうなぁ、って思う。そしてこういう「定常的な更新確認」においては、やはり2022年においてもRSSが欠かせないな、とも思う。

ストレージクラス

先述の通り、現状は8種類が存在している。 re:Invent 2021 で発表された Glacier Instant Retrieval が追加されたのが最後となっている。

https://dev.classmethod.jp/articles/reinvent2021-amazon-s3-glacier-instant-retrieval-storage-class/

本記事執筆時点だと、日本語版の S3 ドキュメント は最新の状態にはなく、まだ7種類のストレージクラスしか表記されていない。以下、 英語版 を参考にすることとする。

標準、IA、Glacier の現状

古い人間としては、ストレージクラスというと標準、IA、Glacier の3種類という認識が強い。基本的には標準 → IA → Glacier と辿るにつれて、保存料金は低くなり、一方でデータの取り出し料金は高くなる。特に Glacier についてはかなり低料金になるが、取り出しにおいては分単位での時間がかかるようになる。 IA （Infrequent Access）は名前通り低頻度のアクセスが想定されるデータの保存に適しており、 Glacier はほとんど取り出すことのない、例えば監査対応のためのログ保存などに適している。

……と、いうのが基本的な僕の認識だったのだが、これがややこしくなったのが最新ストレージクラス Glacier Instant Retrieval の登場である。これは Glacier という名を冠してはいるが、データの取り出しは標準、IA と同様に数ミリ秒のディレイで実現される。 Glacier シリーズのアイデンティティはその名の通り「氷河」のようにデータが凍結され、すぐに取り出せないことにあると考えていたのだが、現状はそのような区分け方ではなくなっている。

適切なストレージクラスを考えるにあたっては、保存料金と取り出し料金のほかにも、いくつかの観点を踏まえる必要がある。

最小ストレージ期間とデータサイズ

標準と Intelligent-Tiering 以外の各クラスは「最小ストレージ期間」の設定があり、その期間内にオブジェクトを削除すると、最小期間相当の料金が発生する。例えば「標準 IA」の最小ストレージ期間は30日であり、オブジェクトを保存開始後に5日で削除しても、30日保存したのと同等の料金になる。

似たところで、データサイズの制約も存在する。標準 IA は最小データサイズが 128KB であり、それより小さいサイズのオブジェクトを保存しても、 128KB 相当の保存料金が発生する。これも標準と Intelligent-Tiering 以外、すべてのクラスに適用されている。

クラス移行の前提条件

https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/userguide/lifecycle-transition-general-considerations.html

IA については、ストレージクラスを移行する前に、「標準」ストレージクラスで30日保存されている必要がある。 IA は標準と同じく数ミリ秒でデータが取り出せるので、取り出し頻度が多少低ければ取りあえず IA 、としたくなるところだが、ある程度長期間保存されるデータでなければ、 IA は利用できない。

ストレージクラスの考え方

ストレージクラスの使い分けは、基本的には Amazon S3 ストレージクラスを使用する - Amazon Simple Storage Service を見れば間違いがなさそうなところではあるが、先の通り最新版にはないため、現時点では英語版を見るのを勧めたい。英語版だと、ストレージクラスの比較表（以下に抜粋）において、 IA などが想定する「低頻度のデータアクセス」というのが、具体的にどの程度の頻度なのかも言及があるので、その点でも英語版を読む価値がある。

基本的にはこの表にて、アクセス頻度だけでほぼ一意にストレージクラスを決定できるようになっている。

• アクセスが頻繁 or 保存期間が1か月以内 → 標準
• 1か月に1回程度 → 1ゾーンIA or 標準IA
• 四半期に1回程度 → Glacier Instant Retrieval
• 年に1回程度 → Glacier Flexible Retrieval （旧 Glacier）
• 年に1回未満 → Glacier Deep Archive

標準以外のストレージクラスは、いずれも30日以上の最小ストレージ期間が設定されているため、アクセスが頻繁ではないとしても、30日以内に削除されるようなデータは「標準」で保存するしかない。

アクセス頻度が1か月に1回程度の場合は、1ゾーン IA と標準 IA の2つが選択肢となるが、これらは可用性、回復性の点で差分がある。1ゾーン IA は 1 AZ でしかデータを保存しないため、その分料金は下がるものの、標準 IA が可用性 99.9 % であるのに対して可用性 99.5 % にとどまり、また災害時などはデータが回復しないおそれがある。

3つの Glacier については、先述の通り Glacier Instant Retrieval 以外についてはデータの即時的な取り出しができないため、その点に注意が必要だ。

なお、アクセスパターンの予測がつかない場合は、 Intelligent-Tiering というストレージクラスを使うことにより、アクセス頻度に応じて自動的に最適なストレージクラスへオブジェクトが移行されるようになる（正確には Intelligent-Tiering 自体がストレージクラス相当の概念であり、変動するのは各ストレージクラスに相当する「アクセス階層」と呼ばれるパラメータ）。移行先には、 Glacier Instant Retrieval や Glacier Deep Archive に相当するアクセス階層も存在するが、これら階層への移行を有効化するかどうかは選択できるようになっており、気付けばデータが即時取り出しできなくなっていた、という事態は避けられる。

AWS Backup の S3 対応

https://aws.amazon.com/jp/blogs/news/preview-aws-backup-adds-support-for-amazon-s3/

S3 のバックアップ機能として、 AWS Backup が S3 をサポートすることが re:Invent 2021 で発表された。ただし、現状 preview の状態であり、 Oregon でしか利用することはできない。

機能と特徴をざっくりまとめると以下の通り。

• 利用に当たってはバージョニングの有効化が必要となる
• バックアップタイミングは、ポイントインタイムと定期の2種類がある
• 復元はバケット全体、オブジェクト単位の2種類を選択できる
• オブジェクト単位で復元する場合、一度のGUI操作で復元できるのは5個までの制限がある
• 復元先は既存バケット、もしくは新しいバケットをつくるか選べる

S3 のデータ回復という点では、従来からバージョニングの機能があり、オブジェクトを更新したり削除しても、その前の版のオブジェクトを残しておいて、後から復元させることができた。そのため、オブジェクト単位のリストアが、バージョニングにおける復元とどう違うのかがいまいち掴めていない。時間指定で戻せるのがポイントだろうか？

バケット全体のリストアについては、使いたい機会もありそうな気はしている。いずれにせよまだ本番利用できる段階にはない。

ACL の無効化

https://aws.amazon.com/jp/blogs/news/new-simplify-access-management-for-data-stored-in-amazon-s3/

re:Invent 2021 での大きな発表からもう1つ、 ACL の無効化も取り上げる。S3 のアクセス制御は、オブジェクトポリシーと ACL の2つを利用することができるために非常に複雑であったが、このうち ACL に関しては、バケット単位で機能を無効化することができるようになった。

ACL 無効化の本質

「ACL の無効化」は、より厳密には「オブジェクト所有者」を強制的に「バケット所有者」と同一とする設定であり、 GUI での設定箇所も ACL の項ではなく、「オブジェクト所有者」の項にある。このあたり、 ACL を理解していないと少々わかりにくい。

バケット所有者、オブジェクト所有者という概念が、 ACL とどう関係するのか。従来、オブジェクトの所有者は、バケット所有者とは別とすることができたのだが、このとき、バケット所有者からは、そのオブジェクトの管理ができなくなるという仕様があった。というのも、オブジェクトには「オブジェクト ACL」というアクセス権が設定されており、これがデフォルトでは、オブジェクト所有者に対してのみ許可を与える形となっていたからだ。オブジェクト所有者以外へアクセスを許可するには、オブジェクト ACL を変更しなければならなかった。

従って ACL を無効化し、使わないようにする上では、オブジェクト所有者をバケット所有者と一致させることが必須となる。

他に ACL が必要な場面はないのか？

ACL を無効化して困る場面はないのだろうか。多くの場面では、 ACL を使って実施できることはバケットポリシーで代替できるが、従来いくつかの権限制御には ACL が必須とされていた。

1つは、サーバーアクセスログを記録するにあたり、ログ配信グループへのアクセス許可を ACL で与える必要があるとされていた。これについてはバケットポリシーでの付与が可能となったため、現状 ACL は必要ではなくなった。（参考: Prerequisites for disabling ACLs - Amazon Simple Storage Service ）

日本語のドキュメントにはこの内容はまだ反映されておらず、 アクセスポリシーのガイドライン - Amazon Simple Storage Service には「バケット ACL の使用が推奨される唯一のユースケースは、Amazon S3 のログ配信グループに、バケットへのアクセスログオブジェクトの書き込みアクセス許可を付与する場合です」との記載が現時点では存在している。 英語版 では、この表記はすでに削除されている。

これ以外では、 CloudFront の標準ログを S3 へ保存する際、 ACL を使用している。

これをバケットポリシーで置き換えることは現時点ではできないらしい。回避策としては、 CloudFront のもう1つのログ機能である、リアルタイムログを使い、標準ログの使用をやめることが挙げられる。

その他では、オブジェクトレベルで権限制御したい場合などが考えられるが、ほとんどのユースケースではバケットポリシーで制御可能な「ディレクトリ」レベルの権限で十分ではないだろうか。よって多くの場合、 ACL は無効化できそうだと考えている。

原著の『Team Topoligies』を昨年、 Twitter のタイムラインで何度か見かけていて、読もうかなと興味を惹かれていたのだが、ありがたいことにそのタイミングでちょうどよく翻訳版が出てくれたのでそちらを読んだ。

興味を惹かれた理由としては、 SRE としての価値最大化を考えていると、組織論を外すことができないという問題意識が強くなっていたから。SRE は開発速度と信頼性のバランシングが責務となるはずだが、専任の SRE チームとして組織すると開発チームとの間でコミュニケーション上のロスが発生し得る。ならば開発チームの中に SRE が属すれば良いかと言えば、 SRE 間の横のつながりも必要なのでそう単純な話でもない。このあたりの SRE チームの構造に関する問題は SRE at Google: How to structure your SRE team | Google Cloud Blog にも言及があるが、ソフトウェア開発全体というレイヤーから組織論を学ぶことで、何かヒントを得たいと考えていた。

追記（2022-01-16 11:05）

https://www.tc3.co.jp/state-of-devops-report-2021-team-topologies/

昨年、原著を Twitter 上で見かけていた背景として、 State of DevOps Report 2021 で言及されていたというのが大きかったのかもしれない。

チームトポロジーとは何か

トポロジー、直訳したところの「位相幾何学」はちょうど最近大学でも学んだところだが、ネットワーク・トポロジーという言葉もあるし、動的に変化する構造、ぐらいの意味で使われているように思う。チームトポロジーとは、組織や技術の成熟、進化に合わせて、チームの構造も継続的に進化させていく動的なアプローチを指す。

チームの構造を考える上でのキーとしては、認知負荷とコンウェイの法則が繰り返し出てくる。チームの人数はダンバー数を反映して、適切な関係を保てる人数に維持しなくてはならない。またチーム間の関係性もまた、認知負荷を引き下げるべく、何かを共有するのではなく、適切に分離された状態が求められる。本書では API を模した「チームAPI」と呼ばれる仕組みを、他チームからのコミュニケーションの窓口として設けることを提唱している。

そして組織構造を考える上では、コンウェイの法則もまた考慮する必要がある。疎結合で凝集性の高いソフトウェアアーキテクチャとしたいのならば、組織構造もまた、それに倣ったものでなくてはならない。

プラットフォームチームを兼任する SRE チーム

チームの役割を曖昧で無制約なものとしないために、本書では各チームを4つのチームタイプに当てはめることを提唱している。そのうち、ストリームアラインドチームは従来フィーチャーチームなどと呼ばれていたような、あるドメインの開発からリリースまで一気通貫に実行できるチームタイプを指す。また、プラットフォームチームは、ストリームアラインドチームが下位のレイヤー（インフラストラクチャーなど）を意識する必要を減らすために、横断的な内部サービス提供を行うとされる。

SRE チームは、このストリームアラインドチームの特殊な類型の1つとされている。横断的なチームであり、各ストリームアラインドチームとコラボレーションしながら、ソフトウェアの変更が適切なストリームに則るようサポートを行う。確かに SRE book でも、 SRE は各プロダクトに常時関わり続けるわけではなく、必要になった段階でコミットし、自律的に信頼性が維持されるようになればコミットを終えるといった動的なサイクルを辿る者とされている。

ただ僕自身もそうだが、国内の SRE チーム（国外の情勢は詳しくない）はインフラチームが改組したもの、インフラチームの役割を兼ねているものが多く、チームトポロジー掲載のチームタイプで言えば、プラットフォームチームの性格を持っている場合が少なくない。言うなればプラットフォームチームと、ストリームアラインドチームの一端とを兼ねた状態になるわけだが、本書に照らし合わせればこれはあまり良い状態とは言えないのだろう。

プラットフォームチームと、ストリームアラインドチームとしての SRE を完全に分離している例としては、僕が知っている範囲では国内ではメルカリが実現している（参考 : どのようにPlatformチームの組織変更をしたか | メルカリエンジニアリング）。しかし、これは人数を必要とする構造であり、特に小さい開発組織では容易なことではない。現実的には、例えば SRE チームがプラットフォームチームとストリームアラインドチーム双方の性格を持ちうることを受け入れつつ、プラットフォームチームに関してはなるべく開発チームとの関係性を疎結合に保ち、密なコラボレーションは SRE としての責務に集中させるなど、 SRE のような横断的なチームについては、その構造とコミュニケーションパスをより深く考える必要があると感じた。

運用からのフィードバックの重要性

個人的に、本書で最も重要なポイントは組織構造を「動的」なものとして捉えるという点だと思っている。そのために、組織構造を変化させる必要のある状況に的確に気付く、「組織的センシング」の必要性が説かれている。

その1つとして、運用から開発へのフィードバックが重要だとされている。これもまた SRE の役割として考えなくてはならないことのひとつだ。 SRE は Embedded な形ではないにしても、適切に開発チームへフィードバックができる状態は保っておく必要がある。 SLO はそのものずばり、運用フェーズから開発へとフィードバックされる、客観的に可視化された指標に成り得るものだし、 SRE が積極的に開発チーム（ストリームアラインドチーム）へ介在しなくとも、アラートやレポートによって、ストリームアラインドチームが自律的にフィードバックループを回すための仕組みとして機能し得るのではないだろうか。

Conclusion

本書は必ずしも目新しい話ばかりというわけではない。ストリームアラインドチームは、自律性やオートノミーを持ったチームとしてもしばしば耳にしてきた覚えがあり、『Scaling Teams』 などでも言及されているなど、個々の概念自体は従来から存在してもいる。ただ、チームをトポロジー = 動的構造として見ること、認知負荷の観点から適切な構造を探ることなど、既存の組織論をよりもう一歩踏み込んで実践させるための書だと感じた。

いろいろと書いてはみたが、組織論である以上、個人で知見を持っていても仕方ないことであるのも事実であり、仕事の中でも必要に応じてこういった知見を共有しながら検討は進めていきたい。

ソフトウェアの複雑さに立ち向かう1つの哲学 :『A Philosophy of Software Design』 を読んだ - こまぶろ という非常に優れた感想エントリーがバズった直後なのだが、同じ書籍の感想を上げさせていただく。あの解像度の記事はちょっと書けないが。

先のエントリーに触発されたわけではなく、僕が本書を買ったきっかけは Practices for Better Terraform Module | Taichi Nakashima で Deep Module に関する一節を読んだことだった。それから1年近く積んでいたのを、2021年12月に重い腰を上げて読んでいた。従って現在の最新版である第2版ではなく、初版の感想になる。余談にはなるが、 Kindle で買う場合は初版と第2版の商品ページが分かれておらず、「すべての形式と版を表示」から選ばなければ第2版が買えないので、注意されたい。

動機

職業プログラマーの経験がないので、ソフトウェア開発のパラダイムや哲学に疎い認識が常にある。特に SRE になってからは、ソフトウェアエンジニアリングが求められる場面も増えたし、 Infrastructure as Code においても依存性をどう排除するか、各種モジュールなどをどういった観点から分離していくか、といったソフトウェア開発の原理原則は応用できる。

そんなときに先の deeeet 氏のエントリーを読み、 Terraform module 作成にこの書籍を応用しているならば、何か自分にも得られるものがあるかもしれない、と読んでみた次第。

感想

ソフトウェア開発において「複雑性」を抑制するためにはどうしたらいいか、という方法論をいくつかの観点から述べている本。英語の本なので敬遠してここまで積んでしまったわけだが、実際読んでみると英語は平易なほうで読みやすかった。また言わんとするところもかなりシンプルだなと感じる。

• 複雑性
  • システムの理解や変更を困難としてしまうような性質
• なぜ複雑性を避けるべきか
  • シンプルな変更でも複数箇所を更新しなくてはならなくなる
  • 認知負荷の増大
  • Unknown unknowns (知られていない、ということが知られていないこと) の増大
• 複雑性はなぜ発生するのか
  • 依存性
    • ゼロには出来ないが、削減し、シンプルに、明瞭にするべき
  • 不明瞭さ
    • 変数名やドキュメントの不備から発生する
  • 複雑性は徐々に増大していくもの
• どうするべきか
  • Deep Module
    • インターフェースがシンプルで、隠蔽された情報が多いモジュール
    • メソッドや変数だけではなく、例外もまたインターフェースである
  • Information Leakage
    • 別のモジュールを同じ情報に依存させない
  • メソッドは1つのことだけを完全に遂行する
    • 他のメソッドを呼ぶだけのメソッドなどは作らない
  • コメントはコードの内容をそのまま書くのではなく、抽象度を上げるか詳述するのかどちらか
  • 継承は複雑性に繋がりやすいので留意する
  • アジャイルは機能レベルで increment するのではなく、抽象のレイヤーで increment することを意識する

Terraform と複雑性

冒頭で書いた「動機」に鑑みて、 Terraform に引き寄せて少し考えてみる。

Terraform module と Deep module

Terraform では抽象化のための機能として module が存在するが、これを扱う上で、 Deep Module の観点はやはり非常に重要だと思う。

僕の場合は AWS と Terraform をセットで使うことが多いので、 AWS に関しての話になるが、例えば EC2 インスタンスを Terraform で立てる場合に記述することになる、 aws_instance のドキュメント aws_instance | Resources | hashicorp/aws | Terraform Registry を見るとパラメータが極めて多く、 Terraform を扱い慣れている自分でも、下までスクロールするのが嫌になる。

AWS を商用利用する場合、その組織内での規約に従い、いくつかのパラメータは決め打ちしたり、デフォルト値を決めておけることも多い。そういった場合に module 化を行えば、インターフェースは削減され、認知負荷の抑制が期待できる。

ただ、これだけでは単にインターフェースが減っただけであり、 Deep とは言い難いかもしれない。複数の AWS リソースを組み合わせて作成することで、何か1つの目的に供するような場合に、それらのリソースを1つの module で作成できるようになっていれば、より Deep と言えるものになる。例えば EKS Cluster はクラスターを作成し、権限管理用の IRSA を設定し、ログ出力先となる CloudWatch Log Group を作成し……と非常に手数の多い作業なのだが、これを一括して管理できる module が存在する。これは Deep な Terrform module の1つと言えそうだ。

https://github.com/terraform-aws-modules/terraform-aws-eks

注意が必要なのは、 module の中に複数のリソースを含めたとき、その一方だけを更新したり、別の用途で使用したりするのは困難になる可能性がある点だ。先の EC2 インスタンスを作成するとき、セキュリティグループも同じ module に含めて作成したとして、そのセキュリティグループを他の用途にも使い回そうとすると、不要な依存関係が発生してしまう。セキュリティグループはあるインスタンス専用に作るというよりは、ウェブサーバー用、RDS 用など汎用的に作る場合が多いと考えられるので、インスタンスの module からは切り離し、外から渡せるようにしたほうが複雑性は抑制できる。こういったことは、本書でも general purpose と special purpose を1つの module にするべきではない、という観点で書かれている。

remote state と Information Leakage

Terraform に関してもう1つ気になるのは、remote state だ。これは Terraform のある state が output した値を、別の Terraform state から参照できる機能だが、字面通りの「依存」に他ならない。 output している側で何か変更が入り、 output した値が更新されたとして、それを remote state で読み込んでいるあらゆる場所に影響が及ぶことになる。

個人的な印象にもなるが、 remote state はレポジトリをまたいだ依存にも成り得るので、 Unknown unknowns な依存になりやすい傾向にあると感じている。可能であれば data で置き換えたり、そもそも state 間で依存性が発生しないような構成を考えるべきだろう。

Conclusion

Terraform で少し考察をしてみたが、複雑性による認知負荷の増大については、 Kubernetes の YAML 地獄でも似たものを感じる。 Helm や Kustomize など、マニフェストを抽象化するためのソリューションはいくつもあるが、まだ決定打は出ていないように思うし、どのツールを使うにしても、本書で述べられている観点は参考にできるのではないかと思う。「複雑性」との戦いは、職種問わず IT でシステムを組んでいれば自ずと発生するので、どのような立場でも読んで益のある本ではないだろうか。

『達人プログラマー』 に「知識ポートフォリオ」というプラクティスの紹介がある。自分の知識の多寡を金融資産のポートフォリオのように見立てて、定期的にリバランスしたり、分散投資しながら継続的に強化していこうという話だ。これ、ずっとやってみたいと思ってはいたのだが、なかなかその機会が取れなかったのを、今回やってみることにした。自分の中の知識を一度客観的に見つめ直してから、今後何に取り組むのかを改めて考えたいと思ったからだ。なので、この記事では「知識ポートフォリオ」を書いたあと、最後に今年の展望に少し触れてみたい。

書籍の中には具体的なポートフォリオの書き方には言及がないので、似たことを実践している以下の記事を参考にさせてもらった。

• 2018年の段階で私が知らないこと — Overreacted
• 得意・苦手（技術） - fsubal

前者の記事は、 React のコアコミッターという「強い」エンジニアの方が、そんな自分でも知らないことはたくさんあるんだよ、という意味で書いたエントリーなので、知識ポートフォリオとは意味合いが異なるのだが、「知らないこと」を真摯に見つめ直すということはとても意義があると思い、常々真似してみたいと考えていた。また、後者の記事も前者の記事も、単に技術の名前をピックアップして「できる」「できない」という話だけをするのではなく、ある程度その判断の根拠を言語化しているので、この点も参考にさせてもらった。

「得意」という言葉を使うのは気が引けるし、つよつよではなくても、自分が業務で使えるレベルであればそれは肯定しておきたかったので、分類は「知っていること」「ある程度知っていること」「知らないこと」の三段階としてみた。自分に知識があると思われる領域を正確に把握しておくことは、生存バイアスの自覚など、心理的な部分にも大いに影響するはずで、軽視したくはない。ちなみにやってみてわかったのだが、どれも完全に書きだそうと思うと際限がないのと、どのレイヤーで書くべきかが悩ましい（RDBMS とするべきか MySQL とするべきか、など）ので、そのあたりは割り切って一旦書いてみている。

知っていること

SRE / DevOps プラクティス

• 『サイトリライアビリティエンジニアリング』『サイトリライアビリティワークブック』『Lean と DevOps の科学』などを読んで実践を試みている
• 現状の自身のエンジニアリングの中心課題がここになっている

Terraform

• module, for_each, 各種 function などを用いながら記述できる
• 自動実行のパイプラインを組むことができる
• 実行エラーや state にまつわるトラブルに一定程度対処できる
• terraform-provider-aws に commit 経験がある
• 同種の他ツール（Pulumi, CloudFormation など）の経験はほとんどない

AWS

• Well Architected なプラクティスを理解している
• AWS Certified Security - Specialty を取得している
• AWS Certified SysOps Administrator - Associate の取得経験がある（expire 済み）
• API 体系をある程度把握しており Terraform や CLI を通じて操作できる
• EC2, ELB, S3, EKS, ECS, Lambda, Kinesis, CloudFront, SES, SQS, CloudWatch, Aurora, RDS, Elasticache, API Gateway, Cognito, Code series などの経験がある
• ただし、まったく知らないサービスも多く、これほど「知っている」と言うのが怖いものもない
  • しかし変に謙遜するのも微妙な気がするのでここに置いた
  • 個々のサービスは置いておいて、 AWS 全体的な管理、運用、利用上のプラクティスを「知っている」の意である

bash

• 好みはしないが、ある程度複雑化したシェルスクリプトや、長時間稼働のスクリプトをシグナルハンドリングなどを考慮しながら書いたりはできる
• awk, sed, cut, tr などを使って標準出力のテキストを編集してごにょごにょする、みたいなことは好きでよくやる (awk, sed は正確には bash の域に含めるべきではないかもしれない）
• POSIX 標準で書けとか言われたら無理です

Go

• terraform-provider-aws を触ったりしているし、基本的な読み書きはほぼできる、ここ2年ぐらいの OSS commit は半分以上 Go である
• 自分で何か CLI ツールを作るときなども Go を使うことが多い
• Go を専門職とするエンジニアにはどう考えても劣るので、進んで得意と言える気もしてはいないが、一定のレベルには達していると認識している

Linux OS の概念

• 低レイヤーに詳しくはないが、メモリ、ネットワークIO、ファイルシステム、CPU、ロードアベレージ、プロセス管理など、 Linux OS の運用上把握しておくべき点は把握しており、トラブル時の対応などもできる
• Ubuntu の経験が長いが RedHat 系も触れる、それ以外のディストリビューションは趣味で Arch Linux を使っていたのと、 Amazon Linux ぐらい

ネットワーク

• プロトコルとしては ssh, http, ssl/tls, tcp, ip, icmp, dns などは概念的に理解している
• DNS サーバの設定や権威 DNS の切り替え、 TTL を考慮した設定や運用はできる
• TLS をどこで終端させるか、どの範囲を TLS 暗号化するべきかなどは関心が強い領域
• IPv6 は理解が薄い

ウェブサービスのインフラ設計、構築

• LB を設けて、ウェブサーバを立てて、アプリケーションサーバへリクエストをプロキシして、という一般的なウェブサービスの構成を一通り構築できる
• nginx と AWS を用いた場合の経験過多、という偏りは強い

Docker

• マルチステージビルドなどを活用しながら Docker コンテナの開発ができる
• docker コマンドを一通り使いこなしたり、 docker-compose を使ったりできる
• Dockerfile を記述する上でのベスト / バッドプラクティスを知っている

Ansible

• 一般的な使い方はできる、 Playbook の読み書きはできる
• 最近はコンテナを使う機会が多く、最新のトレンドなどは把握できていない

ログ管理

• fluentd や Amazon Kinesis を使ってログの永続化や各種転送、フィルタリング処理の自動化ができる
• 構造化ロギングや Twelve Factor App に基づいたロギングプラクティスを理解している
• Elastic Stack は Logstash を除いて運用経験があるが、 Elasticsearch の運用はあまり好きではない

システム監視

• アプリケーションやソフトウェアに応じた適切な監視設計、設定ができる
• Datadog, Nagios, Grafana, influxDB, Hinemos, Mackerel などの構築、運用の経験がある
• 偽陽性アラートの問題、アラート疲れへの対処、平均、中央値、パーセンタイルなど統計方法の使い分けといったプラクティスを理解している
• Prometheus は利用経験がない

CI/CD

• ほぼツールの話になってしまうので「知っている」と言っていいのか判断しづらいが、その必要性と実装方法はわかっている
• CircleCI、 AWS Code Series、 GitHub Actions の使い方をよく理解している

ある程度知っていること

Kubernetes

• Pod, Namespace, DaemonSet, ReplicaSet, Service, Deployment など一般的な概念は理解して活用できている
• 全容が広くてどのレベルまで把握していれば「知っている」と言えるのかの自信がない
• EKS などを使っていて、 etcd などコントロールプレーンのコンポーネントは正直きちんと意識はできていない
• kubectl, kustomize, helm などを用いたマニフェストの適用、設定、記述などは一通りできる

GitOps

• Argo CD と Flux の構築、設定経験がある
• CIOps とは異なり、システムの実態と設定とを自律的に sync する仕組みだと認識しており、 CIOps と使い分けることができる

RDBMS

• MySQL に関しては構築、設定、ある程度のパフォーマンスチューニングや堅牢性の確保ができる
• MySQL 以外の RDBMS は商用運用経験がない
• MySQL にしてもそこまで深く理解しているという自覚はなく、300ページの MySQL 本があるとしたら、自分が理解しているのは30ページぐらいだと思う

KVS

• redis と memcached の構築、設定経験がある
• チューニングなどはほとんど経験がない

CDN

• Amazon CloudFront は触っているが他は通じていないので、 CDN という括りだと「知っている」と言っていいのか判断がつかない
• 書籍『Web 配信の技術』は読んでいるし、ある程度の理解をしているとは思う

mail 関連

• POP3, IMAP などのプロトコルと DKIM などの認証技術、 Bounce への対処といった一連のプラクティスは理解し、対策も出来る
• とはいえ、それほど問題になる機会が多くなかったりはするので、調べながらじゃないと難しいかも知れない

JavaScript (TypeScript), Python

• いずれも Go に次いで書く機会はあり、入門はしていると自覚している
• JS はとりあえず文法はわかる、 Node.js や React などメジャーなライブラリがどう使われているかは知っている、という程度で、それぞれに適した形ですぐに書ける、読める、というレベルではない
• Python は AWS Lambda 程度でしか使わない

セキュリティ

• 旧セキュリティスペシャリストの取得経験はある
• とはいえアプリケーション開発者ではないので、いわゆる「徳丸本」に書かれているような脆弱性を生まないために、どう気をつけてプログラミングすればいいのか、などはよく知らない
• インフラのレイヤーで無駄にポート開放するなとか、暗号化の必要性、適切な権限管理などは理解して実践している

知らないこと

SRE、インフラ以外の領域

• SRE とインフラエンジニア以外の各 IT エンジニアの領域は基本的にわかっていない
• 趣味で Ruby on Rails によるウェブサービスを作ったり、 Next.js でブログを作ったりはしているが、業務レベルでそれをこなせる自信はまったくない

マイクロサービス

• 概念としては知っているが、運用経験はない
• よくマイクロサービス（というか分散システム）と付随して語られるサービスメッシュや分散トレーシング、 gRPC なども知らない

GraphQL

• REST のように URL でリソースを表現するものではなくて、リクエストに DSL を使う、というぐらいはわかっている
• 趣味含めて、開発の中で自分で実装をしてみた経験はないし、叩いたこともないかもしれない

低レイヤー

• いわゆる OS の低レイヤーにはほとんど触れたことがない
• システムコールはいくつか知っているものはあるが、知らないもののほうがほとんどだし、カーネルの知識はない
• C言語もまったく知らない、システムプログラミングの経験はない

アルゴリズム

• 雑学的に知っているものはあるが、業務に活用できたと思う機会はほとんどない

ソフトウェア開発哲学

• 断片的に SOLID やら何やらを聞いてはいるがちゃんとはわかっていない
• Infrastructure as Code のコード設計にも役立つものはあるはずで、すごく「わかりたい」と思っている領域
• 全貌がよく見えていなくて、どこから手を付けていいのかもよくわからない領域でもある

動画やゲームなど大容量の転送、負荷対策

• 経験がないので、何が必要なスキルになるのかもわかっていない
• 単純な負荷対策だけで済まないものと思っている
• 億単位の RDBMS レコードなども扱った経験がない

データパイプライン、データ分析

• パイプラインの構築経験も、データ分析を行ったこともない

HTTP3 / QUIC

• どちらも触れる機会がないまま来てしまった
• なんなら HTTP/2 すらちゃんと理解していない気がする

今年の展望

棚卸しをしてみた感想としては Kubernetes と Terraform を除くと、結構古くからの知識で食べている部分が大きい気がした。ネットワークや Linux 、ログ管理のプラクティスなどがすぐに陳腐化することはないので、それはそれでいいのかもしれないが、一方でシステム監視であれば Prometheus exporter にも対応できるようになっておくとか、よりモダンな部分を取り入れて視野を広げていくアプローチも必要かもしれない。

知らないこと、ある程度知っていることに含めたなかでは、業務上 Kubernetes とセキュリティの必要性が高まっているのと、個人的な興味としてはソフトウェア開発哲学まわりが大きい。去年もこのへんやりたいと言いながら、あんまり取り組めた感覚がないので、インプットとアウトプットを集中的かつ効率的に回していく仕組み作りが必要そう。知識ポートフォリオが少しずつ入れ替わっていくような形を目指していきたい。この記事は折りを見て chroju.dev 配下かつブログの外に移して、定期的に更新していこうと考えている。

習慣に落とし込むと、このあたりを意識することとする。

• 技術書の読むスピードを上げる、1冊2週間以内 = 年間24冊が目安
  • ものによっては1週間以内でよい
  • 熟読するより、まずインデックスを脳内に張るために読むことを考えて数をこなせるようにする
• インプット自体を増やす
  • 勉強会への出席機会が減ってきていたので、増やす
  • RSS reader でブログを読むことがなくなったので、代替手段を考える
• 言語化の機会を増やす
  • Scrapbox のメモを1日3page = 年間約1000pageは増やしたい
  • ブログを2週に1回は書きたい
  • 頓挫してしまった週報は2週間単位で途切れず書くことを目指す
• 8:30〜12:30 をディープ・ワークの時間にする
  • 10:00までプライベートの学び、10:00以降は仕事
  • プライベートの学びは大学の授業を中心、それがないときは私的なインプットをする
  • ポモドーロテクニックを使って、 7 pomodoro はこなせるようにしたい
• 一方で家族や健康は犠牲にしない
  • 家族関連のイベントが最優先
  • ディープ・ワークと仕事を終えたら、だらだら「ながら」で勉強したりしない
  • BMI が 18 を切っているので、食の見直しと筋トレで体重を 5kg 増やしたい

参考

知識の棚卸しにあたっては、以下の記事を参考にした。

• DevOps Roadmap: Learn to become a DevOps Engineer or SRE
• cncf/trailmap: 🗺TrailMap files from the cncf/landscape repo
• 各社の募集要項からSREに求められるスキルをまとめた - Qiita

定量評価

• ブログ : 25記事（昨年比 +2）
• GitHub Contributions : 445 (-21)
• 書籍 : 49冊（+12）

毎年定量評価としてこのあたりの数値を見ているけど、別に年間通じて追っているわけでもないし、あんまり意味がない気がしてきた。とりあえず今年もまとめてみたけど、まぁそんなにやっぱり変わってないな、というところ。書籍の数は ブクログの読書記録 から引っ張ったが、技術書以外も入っているし、逆に雑誌や電子書籍は含まれないのでザックリ。こちらも毎年40〜50冊ぐらいという肌感がある。

ということで、来年からはこれは見ないかもなぁ、と。 GitHub へコントリビュートすることも、ブログを書くこともそこそこ習慣化したので。いやでも、それが失われないことを確認するのがいいのかもなぁ。健康診断みたいなものかも。正常であることを確認するルーチン。

定性評価

技術領域

年始頃にこのブログを Next.js で作り直したとき、 JavaScript Primer を読んで JS について学んだりしていた。

また、 Terraform のワークフロー自動化してくれる Atlantis を初めて使って好きになり、 Terraform Advent Calendar にも Terraform を自動実行したいなら Atlantis - Qiita という記事を上げた。

今年、新たに手を出した技術領域はそれぐらい。仕事では Kubernetes にずっと取り組んでいるが、ある程度使用技術が固定化されてきたので、それほど今年1年のなかで新たな何かに手を出した、というものはなかった。 Kubernetes と AWS と Terraform が軸、という感じになっている。

何冊か本は読んでいて、このあたり面白かった。

https://www.amazon.co.jp/-/en/Heather-Adkins/dp/1492083127

https://www.amazon.co.jp/-/en/%E7%94%B0%E4%B8%AD-%E7%A5%A5%E5%B9%B3/dp/4297119250

SRE / DevOps

SRE としては、常に「何をするべきか」を考えながらずっと従事してきていて、2021年はそれなりの答えがまとまってきた。が、かなり業務内容に沿った話になるので、ここでは書かずに 会社のテックブログ に書けたらな、と思っている。

SRE としての活動を定量的に計測、評価していくことへの関心が今は高くて、本としてはこのへんを読んでいた。

https://www.hanmoto.com/bd/isbn/4295004901

https://www.amazon.co.jp/-/en/Alex-Hidalgo/dp/1492076813

ソフトスキル

いわゆるリーダースキルとか。

2020年にチームリーダーの立場になり、今年も引き続きこの分野は暗中模索していた。昨年の振り返りで、インプットがこちらに偏りすぎたので2021年は技術のほうへ傾けたいと書いていたが、結局今年もこちらのインプットが多くなった。そのわりに考えをまとめてブログなどに書けていないのは反省点。記事としては 思考のリファクタリングとしてのコーチングの技術 - the world as code ぐらい。

先述したように技術的なチャレンジが今年ちょっと控えめになってしまったのもあるので、一度きちんと考えをまとめてアウトプットして、来年は本当に技術側に傾けたい。将来的にマネジメント方向なのか、テック方面でスペシャリスト方向なのか、という二者択一というより、 SRE という職種は双方バランスよくおさめる必要があると思っている。

あと宣伝ではないんだけど、今勤めている会社が社会人教育を事業としているので、ソフトスキル方面の学習リソースが社内に豊富にあって、助かっている。逆に言えば、それに「あてられて」こちらを重視している向きもなくはない。

プライベート

取り立てて書くことはなく、2020年の延長戦のような1年だった、という感覚が強い。旅行も去年と同じで1回だけ、あとは気晴らしで近隣のホテルに泊まるぐらいだし、映画、ライブ、美術館博物館のような外出による娯楽も相変わらず少ないままとなっている。健康面も特に問題ない感じ。

来年はさすがに意識的な変化をつけていかないと、いろいろな面で保守的になってしまいそうでこわい。

やってよかったこと

今年買ってよかったものと、今年のサブスク 2021 - the world as code に書いた、珈琲豆を手で挽くのと、 nosh は取り入れてよかったです。

Pixela による習慣化

GitHub の芝のようなビジュアルデータを簡単に作れる API サービス Pixela というものがあるが、習慣化をする上でとてもよくて今年いろいろ工夫して使っていた。

GitHub のそれが、 Contirubution 回数を記録してくれるのと同様、いつ、何回その行動をしたのかを記録するのにちょうどいい。そして記録を自動化できると尚良し、と考えている。 Pixela は webhook を叩くことで、その日のカウントがインクリメントされるというシンプルな使い方ができるので、自動記録も組みやすい。

例えばこれはスマホを開いた回数の記録。 HTTP Request Shortcuts と MacroDroid を組み合わせて、スマホを開いたときに自動的に webhook を叩くように設定した。デジタルデトックスの一環で、徐々にこの芝の色が薄くなればと考えている。 iOS であれば、「ショートカット」を使って同様のことができると思う。

macOS も Monterey になってショートカットが使えるようになったので、記録できるものは増えたのではないかと思う。来年はさらに習慣化のために活用していきたい。なるべく、生活に必要なものを「習慣」にまとめてシンプルにしていきたい。

週報

読んだ記事などを「週報」として notion にまとめ始めた - the world as code に書いた通り、週報を書く試みを始めた。今のところ頓挫してしまってはいるんだけど、やろうとしたことは間違っていなかったと思うので再開したい。書く内容を少し減らしたほうがいいのだと思う。

今これを書いていても感じているが、年間など長いスパンで振り返るのは急にできるものでもなくて、週間、月間などそれなりの短いスパンで振り返り、立て直しを図っていくことは習慣化していきたい。

Slack で Release Note を読む

RSS Reader を通勤中の電車内で読む、という習慣がすっかりなくなってしまったのだが、使っている OSS などの Release Note ぐらいはちゃんと押さえておきたくて、確実に目に入る場所として Slack に流すことにした。自分1人用の workspace を設けているので、そこに GitHub Release や各種ブログの RSS を流している。 Google Calendar の予定なども流しているので、朝にその日の予定と、夜の間に出たリリースを眺めたりできてなかなかよい。

来年について

まだあんまり考えてないのだが技術〜〜〜って思っている。セキュリティ、 Cloud Native 関連、ソフトウェアデザインあたりに課題感が強い。特に Cloud Native は使っているわりにあん〜〜〜〜まり追えてないので、ちゃんと追っかけることをまずは始めていく。

なかなか時間を無限に使えるという感じでもなくなってきたので、限られた時間に集中して多量にインプットしていくようなスキルを身につけたい。

もうちょい具体的な目標とかは、また年明けたら考えます。

今年買ってよかったもの

TIMEMORE C2

コーヒーグラインダー。これを選んだ契機はあまり覚えていない。

コーヒーは長いこと電動ミル付きのコーヒーメーカーで淹れていたのだけど、コロナ禍で家にいる時間が長くなり、少しコーヒーにもこだわってみようかと思い始めて購入。初めて買ったグラインダーなので、他と比べての良し悪しとかはまったくわからないけれど、特に不便なく使えている。もっと力が要るものかと思っていたが、かなり小さな力で1分もかからずに挽き切れるので手軽。表面に凹凸があって、握ったときに滑りにくく、だいたいいつもキッチンで立ったままゴリゴリと挽いている。仕事中の気分転換にもなっていい。

他にもフィルター、ドリッパーなど「コーヒー沼」を構成する要素はいろいろあるらしいけれど、そこには至らず、現状「豆を挽く」という行為だけで一定満足できている。豆はよく行くカフェで買うことが多い。

MOONBAT urawaza

https://www.amazon.co.jp/-/ja/Moonbat-Urawaza-Folding-Umbrella-Seconds/dp/B085PW4BDM

『マツコの知らない世界』で紹介されていた折り畳み傘。定期的に見るテレビ番組ができた、というのもコロナ禍の結構大きな変化。

「3秒で折りたためる傘」というのが売り文句で、本当にその通り3秒で折りたためる。ポイントとしては開閉ボタンが付いているのが1つ、もう1つは傘の布部分が形状記憶になっているので、ひだの1枚1枚を整えたりしなくても、巻き付ける紐部分を持ってくるっと1周させるだけで形が整うということ。少し大きくて重いのが難点ではあるが、仮にこの傘が壊れてもまた同じのを買うと思う。ちなみに Amazon レビューを見ると「耐久性に難あり」という話が多いが、リモートワークも手伝って使用回数が少ないので、まだなんとも。

AfterShokz OpenComm

骨伝導ヘッドセット。

ヘッドセットはコロナ禍でリモートワークがメインになってすぐ、2020年4月に Voyager 3200 を買って使っていたのだが、自分の環境が何か悪いのか、どうも接続不良が多くて買い替えることに。 Twitter の TL でも、会社の Slack でも AfterShokz の評判をよく聞いていたので、マイク付きのこのモデルにした。

接続の問題もなくなったし、耳穴を塞がないことがこれほど快適とは思わなかったという具合で、とても気に入っている。ただ、耳は疲れないのだが、こめかみのあたりを両側から押さえつけるような形で装着するので、その部分が3時間もするとちょっと痛くなってくることがある。痛くない日もあるので、装着の仕方が悪いのかもしれない。

ちなみに、今年買ったリモートワーク関連のガジェットはこれぐらい。あと何か買うとしたら電動昇降デスクとかになりそう。

Bellroy Classic Backpack

https://ja.bellroy.com/products/classic-backpack

ベストなバックパックってずっとわからずにいる。 PC を持ち運ぶには絶対バックパックを使いたいマンなんだけど、かと言って大きすぎるのは嫌だったり、でも薄マチすぎてペットボトルも入らないようだとさすがに辛かったり、一方で腰に優しい感じのがいいなぁとか、ああでもこうでもないという感じで1〜2年おきに買い替えている。

今年の始めに買ったのがこれで、今のところはここから乗り換えたいなぁという気分にはなっていない。そこそこ厚みは薄いけれど、入れようと思えばペットボトルとオライリー1冊と PC ぐらいは全然入る。PC は背中側に設けられたスリーブに入れるようになっている上、背中に当たる部分が硬質な素材のランバーサポートになっているので、重い PC は常に背中へ密着した状態をキープできて、重さを感じにくくなっている。それでいてあまり無骨なデザインではなく、休日にも使いやすいのがいい。

ジップロック ごはん保存容器 一膳用

https://www.amazon.co.jp/-/en/Ziploc-Container-Storage-Pieces-Packs/dp/B07KWGYRMJ

地味なところで。冷凍ごはんは生まれてこのかたラップで適当に包むだけだったのだが、これを買ったところだいーぶ体験が改善した。一包みの分量が一定に保てるし、水分が適度に保たれるようで味も良くなった。

Subscriptions

例年通り差分にて掲載。

  * Day One (¥2,800 / year)
  * MoneyForward プレミアム会員 (¥500 / month)
- * Nintendo Switch Online (¥2,400 / year)
+ * Nintendo Switch Online + 追加パック (¥4,900 / year)
  * Amazon Prime Student (¥2,450 / year)
  * Spotify Premium Student (¥480 / month)
  * シネマシティ (¥1,000 / year)
  * Dynalist Pro ($7.99 / month)
  * dアニメストア (¥400 / month)
- * freee (¥1,980 / month)
  * メールマガジン「読書日記／フヅクエラジオ」 (¥800 / month)
  * ATOK Passport (¥300 / month)
  * IFTTT Pro ($1.99 / month)
  * Association for Computing Machinery ($99 / year)
+ * Netflix (Standard) (¥1,490 / month)

Nintendo Switch Online は 64 が遊びたくて「追加パック」に乗り換えた。子どもの頃に買って欲しかったけど買ってもらえなかった未練の代表格だったので。64 が。とりあえず『ゼルダの伝説 時のオカリナ』『ムジュラの仮面』はクリアしたくて、その後2年目どうするかは追加ソフトと相談かな。一気に倍額になっているけれど、まぁ1か月換算で500円にも満たないので十分許容範囲かなぁ、というところ。

Netflix は 『ゴジラ S.P』 が観たくて加入。その後1回脱退して、『ブルーピリオド』と『カウボーイビバップ』実写版が観たくて再加入して今に至る、という感じ。退会するときに引き留めるような UX が全然なくて、戻ってきた時に「おかえり！」って言ってくれるのがとても好感している。見たいものがあるときに入ってね、というスタンスのようなので、今後もそういう感じで付き合おうと思う。『TIGER & BUNNY 2』が見たいのでとりあえず来年6月ぐらいまでは継続になりそう。

freee は業務委託がなくなったので、有料会員をやめた。

番外 : nosh

厳密にはサブスクではないが nosh を今年から取り入れた。ヘルシーな冷凍宅食サービスで、2週間に1回などのスケジュールを組んで配送してもらい、配送のたびに料金が発生するのでサブスクではない。

うちは2人暮らしの共働きリモートワークが1年以上続いていて、昼食は双方とも短い昼休みで作るモチベーションはなく、かと言って買いに行くのもだんだんバリエーションがなくて飽きてきた、というところに上手くはまった感じ。冷凍庫サイズの限界もあって、2週間に1回6食を届けてもらうスローペースではあるんだけど、今日はちょっと忙しいなとか、雨で買いに行きたくないなというときにサッと使えるジャンクではない選択肢、としてはこれぐらいで十分だったりする。味も良くて、毎回いろんなメニューを試して楽しんでいる。

難点があるとすれば、本当にヘルシーで、ものによっては 200 kcal 程度だったりすること。僕は元来太りにくい体質なので、これだと摂取カロリーさすがに足りなさすぎて BMI がゴリゴリ減る時があり、間食や夕食で調整したりすることもある。ちなみに一番好きなメニューは「鶏モモ肉のディアブル」……だったんだけど、今見たら終売していて悲しくなった。「飽き」を防ぐためなんだろうけど、結構ローテーションがあって好きなメニューが消えることもあるのがちょっとつらい。でも、それを補ってメニューの種類がかなり豊富なので、「食べたいものがない！」なんてことにはならないのがよいところ。

全体的に派手なリリースはそれほど多くはないものの、地味に嬉しいものとか、サービス間の関係性が適切に見直されたものが多かったかな、という印象。

ECR Public + Docker Hub

• Docker Official Images now available on Amazon Elastic Container Registry Public | Containers
• Announcing Pull Through Cache Repositories for Amazon Elastic Container Registry | AWS News Blog

ECR 関連で2つ発表されていて、1つは Docker Hub 上の Docker Official Images が ECR Public からダウンロードできるようになったというもの。 ECR Public は AWS ネットワーク内からダウンロードする分には制限がないので、 Docker Hub のダウンロード制限をこれで回避できる。

2つ目は Pull Through Cache Repositories。 Public なコンテナイメージレポジトリと、 ECR private を同期して、 ECR private の機能を用いてパブリックイメージを管理できるようになるというもの。例えば Private Link を介してイメージをダウンロードしたり、 ECR private の脆弱性検査の機能を使ったりなど。対応しているのは ECR Public だけではなく、ローンチ時点で Quay.io も扱える。で、 ECR Public には Docker Official Images も同期されているので、実質 Docker Hub も一部対応しているような形になった。

Amazon S3 Event Notifications with Amazon EventBridge

New – Use Amazon S3 Event Notifications with Amazon EventBridge | AWS News Blog

S3 の Event Notification は従来バケットの設定の中に組み込まれていたけど、これが EventBridge で設定できるようになった。

これ、管理の面で結構嬉しくて、というのも Event Notification は何と言うのか、1個のオブジェクトのようなもので、1つのバケットに対して複数の通知を設定する場合でも Terraform でこういう書き方になる。

resource "aws_s3_bucket_notification" "bucket_notification" {
  bucket = aws_s3_bucket.bucket.id

  lambda_function {
    lambda_function_arn = aws_lambda_function.func1.arn
    events              = ["s3:ObjectCreated:*"]
    filter_prefix       = "AWSLogs/"
    filter_suffix       = ".log"
  }

  lambda_function {
    lambda_function_arn = aws_lambda_function.func2.arn
    events              = ["s3:ObjectCreated:*"]
    filter_prefix       = "OtherLogs/"
    filter_suffix       = ".log"
  }

  depends_on = [
    aws_lambda_permission.allow_bucket1,
    aws_lambda_permission.allow_bucket2,
  ]
}

この密結合な感じがすごく嫌だったんだけど、 EventBridge であれば1つずつ切り離して別々に設定を書けるはず、と認識している。

New Amazon Inspector

Improved, Automated Vulnerability Management for Cloud Workloads with a New Amazon Inspector | AWS News Blog

Amazon Inspector に新しい機能がかなり盛り込まれた。

Automated Discovery を有効化すると、EC2 と ECR repository を自動で検知して脆弱性を検査してくれる。 ECR にはもともと脆弱性検査機能はあったわけだが、 Inspector と連携すると Enhanced Scanning が使えるようになり、プログラミング言語のパッケージもスキャンできるようになる（ただしこちらは有料）。まぁアプリケーションの脆弱性スキャンはアプリケーションレポジトリ + GitHub Code Scanning とかでもっと早い段階でスキャンしていたりするだろうとは思うものの。

他にも Security Hub との連携、 AWS Organizations との連携などなど追加要素はかなり多い。

AWS Mainframe Modernization

Introducing AWS Mainframe Modernization

これは使う予定のない完全な興味。

オンプレのメインフレームのワークロードを AWS へ移行できるらしい。自分が業務でメインフレームに触れる機会は今後なさそうだが、ついに AWS もここに手を出すのか、という感慨深さがある。ざっとしか読んでいないけど、おそらく z/OS などがクラウドで動きますよ、という話ではなくて、メインフレームで動かしている COBOL などを AWS で動かすためのあれこれ、みたいなものっぽい。

S3 Glacier Instant Retrieval

Announcing the new Amazon S3 Glacier Instant Retrieval storage class - the lowest cost archive storage with milliseconds retrieval

ミリ秒単位でデータ取得が可能でありながら、標準IAよりは安価に保存が可能な Glacier の新たなストレージクラス。標準IAもミリ秒単位で取得可能なので、ならば標準IAと Glacier Instant Retrieval との違いはどこ？とちょっと疑問なのだが、おそらくデータ取り出し時の料金にコストが跳ねていると思われる。記事執筆時点で Pricing にまだ反映されていないので未確認。

これに伴い、既存の Glacier と呼ばれていたストレージクラスは Glacier Flexible Retrieval に名称変更。ここまで細かくストレージクラスが分かれる必要あるのかは若干疑問だけど、選択肢があるのはいことかな。

Control Tower が Terraform から操作可能に

HashiCorp Teams with AWS on New Control Tower Account Factory for Terraform

AWS アカウントの管理ではあんまり Terraform の出番がなかったのでこれは嬉しい。

AWS Backup for Amaozon S3

Announcing preview of AWS Backup for Amazon S3

AWS Backup が S3 に対応、バケットのスナップショットを取得できるようになったとのこと。 S3 に保存したデータが消える心配はあまりしていないのだけど、本当に重要なものは別クラウドのオブジェクトストレージにコピーしたりしていたので、これが代わりになるかな？

Amazon DevOps Guru for RDS

Announcing Amazon DevOps Guru for RDS, an ML-powered capability that automatically detects and diagnoses performance and operational issues within Amazon Aurora

Amazon Aurora のパフォーマンスの問題などを自動的に解析してくれるらしい。

Sustainability Pillar for the AWS Well-Architected Framework

New Sustainability Pillar for the AWS Well-Architected Framework

Well-Architected Framework にサステナビリティの柱が新たに追加された。 Well-Architected Framework 、全体を何年か前にザッと読んだっきりになって更新も追えてないので年末とかに読もうかな。

IP Address Manager

Amazon Virtual Private Cloud (VPC) announces IP Address Manager (IPAM) to help simplify IP address management on AWS

VPC の IP アドレスを GUI で効率的に管理できるサービス。最初に IP のプールを /8 の下に /16 をいくつか、みたいな感じで具体的なセグメントを切りつつ作っておいて、それを VPC に割り当てる、という形で使えるらしい。このあたりは確かに Excel とか Notion Database とか使って管理していたので、 AWS の中で完結できると地味に良さそう。 IP の割当状況とかも見られるらしい。枯渇しそうになったらアラート上げるとかできるかな。

Disalbe S3 access control list

Amazon S3 Object Ownership で、S3 内のデータのアクセス管理をシンプル化するためのアクセスコントロールリストの無効化が可能に

S3 の ACL を無効化して使わないようにできるらしい。ちょっと笑った。

確かに現状では ACL で出来ることはバケットポリシーでほぼ代替できるので、基本的には使わないものだし、無効化してしまったほうが認知負荷の観点でシンプルになるのはすごくわかる。一方で歴史的経緯から機能自体を廃止はできないのだと想像。これはよい落とし所だと思うし、案外神アプデでは。

AWS re:Post

AWS re:Post – A Reimagined Q&A Experience for the AWS Community | AWS News Blog

こういう言い方で正しいかわからないけど、 teratail の AWS 版的な認識。 AWS の Forum って確か従来もあったと思うけど、あんまり GitHub Issue ほど活発で活用できるような感覚がなかったし、 Community として知見が集まってくると嬉しいかも。

版元ドットコムとは

版元ドットコムとは | 版元ドットコム に詳細は譲りたいが、版元 = 出版社が寄り集まって作っている団体と、その団体が作っているウェブ上の書籍データベースを指す。

参加していない版元による書籍については、当然ながらデータが存在しないし、また検索機能があるものの、それほど強力ではない（例えばアルファベットはケースセンシティブで検索されるっぽい）など弱点も見受けられる。が、サイト内に直接的な購入導線がなく、その点で中立的な書籍データベースとして利用できる。

workflow の構成

書籍検索の API を叩いて書籍を探し、確定したらそこから ISBN-10 を抽出して https://www.hanmoto.com/bd/isbn/$ISBN に渡して開いている。同様に ISBN を URL に渡すことで書籍のページを開ける、 Amazon.co.jp と ブクログ にも対応させている。

また、書籍の情報を参考文献のフォーマットでコピーできる機能も用意した。これは大学でレポートを書く上で以前から欲しいと思っていた機能。例えば 『SRE サイトリライアビリティエンジニアリング』 をコピーすると、 Betsy Beyer, Chris Jones, Jennifer Peto, Niall Murphy (Sky株式会社 玉川 竜司 訳) . SRE サイトリライアビリティエンジニアリング. オライリー・ジャパン, 2017, 592p. となる。

書籍検索API

書籍情報を検索できる API はいくつか存在しており、今回3つほど試したがどれも一長一短だった。1つ目は版元ドットコムとカーリルが共同で提供している openBD API 、2つ目は Google Books APIs 、3つ目は 楽天ブックス系API 。

openBD API

• GET は ISBN 指定でしかできない（検索の機能はない）
• 書誌情報は版元ドットコムによるものと JPRO によるものの2つが同梱されており、充実している
  • JRPO の書誌情報は独特のフォーマットであり、 http://jpo.or.jp/topics/data/20160113a_jpoinfo.pdf で仕様を確認できる
• 認証は不要

Google Books APIs

• 検索と、 Google Books 内での ID 指定による get に対応
• 書誌情報は充実しているが、難あり
  • ISBN など基本的な項目含めてアトランダムに「抜け」が見られる
• 認証は不要

楽天ブックス系API

• 各種パラメータ（書名、著者、ISBNなど）指定により GET を行い、複数マッチすれば複数の書籍情報が返る
• 書誌情報は比較的充実しているが、難あり
  • ISBN-13 が振られている場合、 ISBN-10 の情報は抜けている
  • 著者名の姓名分かち書きなどに統一性がない
• 和書、洋書で API が分かれている
• 認証が必要

結論としては Google Books APIs を使うことにした。 openBD は検索ができない時点で用途に見合わず、楽天は和書、洋書の一括検索ができない、 ISBN-10 が取得できない場合があるなど、難が多かった。 Google については ISBN がそもそも取得できないという大きな欠点もあるものの、一旦そのような書籍は検索結果から除外する形で妥協している。

Conclusion

円城塔『プロローグ』 にこんな一節がある。

なんでも良いがいい加減このくらいの代物は、出典の URL を明記できるくらいの形でどこかに公的なテキストデータとして蓄えておいてもらいたい。『古事記』だよ。勘弁してよ。 (p.17)

今回、いくつかの書籍情報 API を調べて、なかなかこれといったものがなく悩んでいた際に、この一節を思い出した。書籍情報の絶対的なパーマリンクが欲しい。いつかこのあたり、仕事で少し噛めたらな、とはちょっと思っている。

それはそれとして、Alfred Workflow をサッと作れるようになっておくとやはり便利だな、ということを改めて感じた。この Workflow は完全に個人的なものなので、以下のリンク先で公開してはいるが、 PR などを受け付けるつもりはない。 ISBN で URL を開けるようなサイトなら、 Amazon やブクログ以外にも応用可能と思うので、もし自分なりに使いたいという方がいたら fork してみてほしい。

https://github.com/chroju/alfred-book-search

初めてこの概念に出会ったのは『ヤフーの1on1』を通してで、この本では 1on1 における相手への働きかけを、ティーチング、コーチング、フィードバックの3つに分類している。ティーチングは相手に知識を「教える」ものであり、フィードバックは評価などを「伝える」ものであるのに対し、コーチングは相手の中にある考えや思いを「引き出す」ものとされる。相手が何か課題を抱えている際に、その答えとなるアドバイスを直接話してしまうのではなく、相手の中で思考を進める支援をして、自ら回答を導く、あるいは自らが本当に考えていることを気付かせるよう促すのが「コーチング」と呼ばれる。

今回、コーチングに興味を持って4冊ほど本を読んでみた。動機としては、自分自身「上司」の立場で 1on1 を行うにあたり、この手法のなんたるかを知っておいたほうがいいと思ったからだ。

また、コーチングの手法を自分自身に応用し、自らの成長に役立てる「セルフコーチング」という概念も存在する。僕は目の前の仕事をこなしたり、自分の立場で求められることを考えて実践するのはある程度得意だが、自分自身が何をしたいのか、5年後どうなりたいのかと言ったことを考えたり言語化するのはあまり得意ではない。コーチングにおける「思考を進める」「自分自身の本当の考えに気付く」という方法論は、こういった自分の弱点克服に役立つのではないかと考えた。

改めて、コーチングとは何か

ところでいろいろと調べてはみたものの、具体的にコーチングはこれだ！と一言で言えるものではなく、捉えどころが難しい。

コーチングの不都合な真実　それは信念なのか、それとも科学なのか？ という記事によれば、アメリカでコーチングが登場してからまだ30年程度だそうで、様々な流派が存在しており、実際のところ何か明確な定義があるわけでもないらしい。最初に書いた「対話による」「人材開発」という点は共通していると思われるが、そこで具体的に何を話すのか、どういった手法が用いられるのかは、流派によるのだと思う。

したがって、ここで書く内容は、あくまで僕が読んだ4冊から抽出した内容に過ぎず、これ以外の方法論も存在しているという点は予め書き記しておく。

コーチングの過程

目標の明確化、現状分析、ギャップの調整という三段階を辿るのが基本とされる。

目標を達成する、成長を支援するならば、その行く先たる目標をまず明確化する必要がある。それも、会社から求められているような have to の目標ではなく、自分が本当にやりたいことをまず探し出すところからコーチングは始まる。

その後、現状を分析した上で、現状と目標との間にあるギャップをどう埋めていくか考え、調整していくのが一連のコーチングプロセスにあたる。

コーチングは対等な関係で行う

字面からして上下関係を想像してしまいがちだが、コーチングは対等な関係で行うものであり、そこに上下の別はない。コーチングを受けたい一方が、自分の悩み、課題をまず言語化して客体化し、それに2人で向き合うような形で進めるのが理想とされる。

具体化していく、考える材料を多く出す

冒頭に書いた「考えを引き出す」にあたっては、できるだけ多く、具体的に自分の考えを言語化していく必要がある。

コーチングの前提となる考えに、人間は自分が本当に考えていることを自覚していない、という点がある。体面、世間体、社会性などを理由に取り繕ったことを話してしまうということもあるし、言語化していない思考には自分でも気付けないことがある。ソフトウェアエンジニアリングの界隈で言えば、「ラバーダック・デバッグ」や「壁打ち」を想像するとわかりやすい。

また、ある程度具体的な経験をピックアップしなければ、抽象化に結びつけづらい。目標達成に困難を感じる出来事が1つだと、それは一過性のものかもしれないが、複数を挙げて共通点を括り出すことで、より本質的な問題に対処できる可能性がある。

コーチングであれば、うまく質問を通じて相手の話を具体化していく必要があるし、心理的安全性や信頼を確立して、相手が本当のことを多く話せる場を整える必要がある。セルフコーチングであれば、自分の考えをたくさん書き付けながら、曖昧な部分を自ら探して掘り下げていくような過程を辿ることになる。

習慣や環境へのフォーカス

コーチングは最終的に何かしら「行動の変化」を伴わなければ意味がない。

そのために、習慣や環境へフォーカスしていく。目標達成が「Go をひとりで書けるようになる」だとして、あまり勉強の時間が取れていないのであれば、どう時間を確保するかを考えたり、コーディングの対象を探すために、 Go の Good First Issue を探しやすいようにするかもしれない。あるいはそもそも別のチームに移動したほうが業務時間で Go を書けるのであれば、移動を調整して環境自体を変えることも考えられる。

コーチングは継続的に行う

コーチングは1回行って終わりではなく、継続的に行うものとされる。

1つには、なかなか1回の会話（コーチングは1回あたりだいたい30分程度）では本当の考えまで辿り着けない場合も多いことによる。何度もコーチングを行い、じっくり問いに向き合うことで、自分の目標は何か、どういったキャリアを辿りたいか日常的に考える習慣ができていき、答えも見つけやすくなる。

また、不確実性を排除する観点もある。状況が日々変化していく中で、目標はそのままでいいのか、今やっていることは目標達成の観点からずれてきていないか、新たな問題はないかなど、様々な点を洗い出しながら軌道修正していく。

conclusion

正直なところ、本を読んだだけでコーチングスキルが簡単に上がるものではないし、それなりにこれは高度なスキルだという印象が強い。そもそも、悩んでいる相手に対して、パッと何かアドバイスをしたくなる衝動は自分にもあるし、それを押さえて話を聞く、考えを促すという会話スキルにチャレンジしてはいるが、一朝一夕で身につくものではないな、と思う。

コーチング自体が万能のものでもないと思っている。世の中、特にエンジニア界隈だと、キャリアパスは特に考えず、やるべきことをこなしていただけで凄腕エンジニアになれました、という人は多くいるし、成長過程を辿る上で、こういった自問自答が必要となるかは人それぞれだ。 また、コーチングは自分の中に答えを見つける、つまり「自責」の考え方が強いので、例えばトップダウンの傾向が強いような会社だと、コーチングしたところで自分が取れる手立てがない、ということもあり得るのではないかと思う。もちろん、環境要因を変えるために、自分が何をできるか考えることが重要なのだが、過度な自責思考は、人によってはメンタルに重大な影響を及ぼす可能性もあるし、銀の弾丸のようにコーチングを用いるべきではないと考える。

その上で特に着目したいのは、コーチングにおける「考えを具体化する」「言語化して考える」「習慣にフォーカスして行動を変える」「継続的に状況を追跡する」といった方法論だ。今回、『エンジニアリング組織論への招待』もあわせて再読したのだが、その中で「思考のリファクタリング」と呼ばれる言葉がある。人間の思考はバイアスなどで認知がゆがみやすいし、言語化していないことで曖昧なものとなってしまうこともある。この本では、思考をリファクタリングすることで行動を促すために、メンタリングの技術を勧めており、これはコーチングの考え方にも近い。

僕はつい頭の中で考えを転がす悪癖があるので、書き付けて考える、あるいは具体的経験を書き留めておくことは日々の習慣にしていこうと思っている。コーチング上での実践のみにとどまらず、常に自分の思考を疑い、それを言語化、客体化してリファクタリングしながら、自分の目標や問題意識に向き合うことは、エンジニアとしても必要な技術だと捉えている。

今回読んだ5冊

新版 コーチングの基本

https://www.hanmoto.com/bd/isbn/4534056591

コーチングとはそもそも何なのか、定義付けする上ではこの本が一番よかった。先述の通り、かなり捉えどころのない概念なので、まずはこの本である程度コーチング像を固めてしまうと良いように思う。後半は組織論などになるので、前半だけでも。

新 コーチングが人を活かす

https://www.amazon.co.jp/dp/4799326104%0A

コーチングを実践する上での tips が多く書かれている本。具体的にコーチングをどう進めるべきなのか、実践イメージがつかみやすい。

エンジニアリング組織論への招待

https://www.amazon.co.jp/dp/4774196053%0A

再読。先述の通り、一部の記述がコーチングに近い話になっており、 Chapter1「思考のリファクタリング」と Chapter2「メンタリングの技術」が特に参考になった。

トリガー 自分を変えるコーチングの極意

https://www.amazon.co.jp/dp/4532320496

コーチングにおける「行動の変化」をどう促すべきかにフォーカスした本であり、コーチング自体の方法論ではない。人間の行動は「環境」というトリガーに大きく左右されているとし、習慣や行動を変えるための仕組み化を行うことを述べている。コーチングの如何を問わず、行動変容という点ではとても参考になった。

人生改造宣言

https://www.amazon.co.jp/dp/4419067845

これもコーチング自体の方法論の本ではなく、コーチングにおいて行われるアドバイスが tips のようにまとめられた本という趣が強い。ライフハック本に近いかもしれない。

利用技術

Kubernetes のインストールには kOps を使った。

そのほかのツールとしては kubeadm や kubespray などがある。 kubeadm は以前使ったこともあるのだが、サーバーの中でコマンドを実行することで Kubernetes コントロールプレーンもしくはワーカーノードとして必要な設定が施される。 kops はこれとは異なり、 AWS で必要なリソース各種の構築と、サーバー内の設定の双方をおこなってくれる。今回 kops を選んだのは、 Kubernetes Cluster 一式が一発で構築できるので kubeadm より楽だったから、という理由に尽きる。VPS を使うより AWS のほうがある程度金額面で高くはなるが、検証するなら業務でもよく使う環境のほうがいいだろうということで AWS にした。リザーブドインスタンスを適用すれば、サーバー代自体はそこまで国内主要 VPS と変わらないと認識している。

ちなみに kubespray のことはよく知らない。

また、 Kubernetes 上に manifest を適用するにあたっては Argo CD による GitOps を採用した。これは業務で使っているものに揃えた。

kops

kops は本当にザックリでよければ、 kops create cluster $NAME コマンドで初期設定を作成し、 kops update cluster $NAME --yes でクラスターの構築が終わる。構築にあたっては ~/.kube/config も自動で設定され、そのまま k8s が利用可能となる。もともと AWS で簡単にクラスターを立てることを目的としたツールだったようだが、現在はその他の各種クラウドサービス、 VPS も alpha, beta の状態でサポートされている。

kops の設定情報は create cluster コマンドにオプションで手渡す。例えば --master-size でコントロールプレーンのインスタンスタイプを設定できる。設定情報の実態は、 kops コマンドの実行時に予め KOPS_STATE_STORE 環境変数で設定した S3 バケットに保存される。

kops + Terraform

設定を宣言的に Git で管理したければ、 create cluster コマンドに --target=terraform オプションを与えることで、 Terraform の設定を出力させることができる。

$ kops create cluster kops.chroju.dev --zones=ap-northeast-1a --master-size t3.small --node-size t3.small --networking calico --ssh-public-key ~/.ssh/id_rsa.pub --out=. --target=terraform

$ terraform apply -auto-approve

これは先の S3 バケット内の設定を Terraform 形式に落とし込む形になるが、この後は S3 側の設定は必要としなくなり、 Terraform コマンドだけでオペレーションできるようになる。このほうが、 kops はあくまで設定テンプレートを出力するだけのツールとして扱うことができ、クラスター管理において kops を離れることができるという点でも利がある（ただし、 kops が自動的に etcd のバックアップなどでも S3 を使用するため、 S3 が不要になるわけではない）。

ssh 接続を ssm に切り替える

kops はデフォルトで ssh による各ノードへのアクセスを有効としているが、セキュアではないので AWS SSM による接続へ切り替えたい。 Terraform を編集して ssh の許可を塞ぎ、各ノードの IAM Role に AmazonEC2RoleforSSM policy を追加しておく。

画像は省略したが、 IPv6 の Port 22 も同様に閉じておく。

ノード内部設定変更の反映

kops が出力する Terraform では、各ノード内部の設定には user data を使用している。 Terraform では user data を編集してもインスタンスの再起動は行われないため、即時の反映はされない。この場合は kops rolling-update を実行することで、インスタンスを入れ替えることができる。

Argo CD

2021年2月から、公式の Helm Chart がリリースされているので、これを使ってインストールした。

App of apps

Argo CD による Application の管理には App of apps パターンを採用した。

Argo CD は、管理対象の Kubernetes manifests を Application と呼ばれる CRD で設定する。対象の Git レポジトリの URL やパスを Application 内で設定することで、定期的にそのレポジトリを fetch して、 Kubernetes クラスター上に apply する。

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: guestbook
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/argoproj/argocd-example-apps.git
    targetRevision: HEAD
    path: guestbook
  destination:
    server: https://kubernetes.default.svc
    namespace: guestbook

この Application 自体も Kubernetes resource なので、 Argo CD で管理したくなる。そこで Application を管理する Application（便宜的に「親 app」と呼ぶ）を作成するパターンが App of apps と呼ばれる。具体的には Helm Chart で以下のようなファイルを作成する。

.
├── Chart.yaml
├── templates
│   ├── argo-cd.yaml
│   └── namespace.yaml
└── values.yaml

Chart.yaml は適当な内容でよい。

apiVersion: v1
name: app-of-apps
version: 0.0.1

values.yaml には管理対象となる Application のデフォルト値を設定しておく。

metadata:
  namespace: argo-cd
spec:
  destination:
    server: https://kubernetes.default.svc
  source:
    repoURL: https://github.com/chroju/infrastructure
    targetRevision: HEAD

templates 内に app 1つにつき1ファイルを作成していく。ここで Application を管理していく。以下では、 chroju/infrastructure レポジトリの kubernetes/namespace 配下が Application の同期対象となる。

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: namespace
  namespace: {{ .Values.metadata.namespace }}
spec:
  project: default
  source:
    repoURL: {{ .Values.spec.source.repoURL }}
    path: kubernetes/namespace
    targetRevision: {{ .Values.spec.source.targetRevision }}
  destination:
    server: {{ .Values.spec.destination.server }}
    namespace: default
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

この Helm Chart を管理する Application をさらに作っていくとさすがに切りがないので、ここだけは argocd app create コマンドにより手動で Argo CD へ Application を作成する。すると画面上では以下のように、親 app から各 Application がぶら下がるような形になる。

今後 Application を追加したい場合は、先の Helm の template にファイルを追加していくだけでいいので、今後は Git 上の操作だけで manifest を apply できる、 GitOps の環境ができあがる。

Argo CD UI へのアクセス

なお、k8s 上のアプリケーションを expose する手段をまだ持っておらず、 Argo CD は port forward でアクセスしている。常時アクセスしたいものではないし、これでも別に良いような気もしているが、気が向いたら何か手段を講じるかもしれない。

$ kubectl port-forward argo-cd-argocd-server-XXXXXXXXX-XXXXX 8080:8080

Next

とりあえず、 k8s cluster とその上で動く resource がすべて declarative に管理できる状態がこれで出来上がった。まだまだ課題はあるので、ゆっくり育てていきたい。

• 先述の Argo CD port forward をどうするか
• Argo CD ログインを何らかの OAuth へ変更したい
• 監視を実施したい
• Reserved Instance を購入したい
• 定期的なアップデートを実施していきたい

実は1年近く前にも kubeadm + ConoHa でクラスター構築したのだが、当時の設定を何も情報残していないし、管理が頓挫したので今回が再挑戦になる。今回こそは続けていきたいところ。

AWS Certified Security – Specialty を自宅で受験して合格したのでレポート。

受験の動機

AWS のセキュリティサービスってひたすらに数が多くて訳がわからなかったので一度体系的に学び直したくて取ってみた、という感じ。 EC2 建てるときに何に気をつけなくちゃいけないかとか、 IAM の権限のベストプラクティスとか、個別の事例は理解しているけれど包括的に知りたくなった。 基本的に資格を取る、あるいは資格勉強をするときのメリットって、こういった体系立てて知識を付けることにあると思っている。

取得に向けた学習

学習期間は1週間しか取れていないのだが、あくまで数年にわたる業務経験 + 1週間の集中学習で合格できているだけなので、誰でも1週間で取れますよとは全然言わないし、自分自身にとってももう少し時間取るべきだったとは反省している（試験は合格したけど、もう少し深掘りしたかった分野がいくつもある）。

逆に業務経験だけで取れたとも思えない。後述の書籍などを読んでいて、名前さえ聞いたことがないサービスに出くわすこともあった。業務経験の知識を試験向けに洗練しつつ、業務で触れたことがない知識を補うように学習していったイメージ。

以下、使った教材を具体的に書いていく。

要点整理から攻略する『AWS認定 セキュリティ-専門知識』

https://www.amazon.co.jp/dp/B08DCLRHC7

NRIネットコムのエンジニアの方々が書いている試験対策本。試験範囲を網羅的に押さえる上で良いと思う。一番最初にこの書籍をざっくりと読み通してから、あまり詳しくない部分を個別に補う形で学習を進めた。試験に出そうなところは詳しく、あまり出題されないサービスなどはさらっとした解説になっていて、どこを重点的に学べばいいかわかりやすい。

ちなみにだが、2020年7月の発刊なので、現時点で内容が古くなっているということはほぼないものの、それでも公式に告知されている試験範囲は別途きちんと押さえるべきだと思う。例えば AWS Audit Manager は2020年12月に発表されたサービスなので、本書では当然言及がないが、公式の試験ガイドには記載されている。

Exam Readiness: AWS Certified Security - Specialty

Exam Readiness: AWS Certified Security - Specialty | AWS トレーニングと認定

公式の無料デジタルトレーニング。内容としては短いが、練習問題もいくつか付いているので、雰囲気を掴むのに良い。

AWS Black Belt & Developeres.IO

https://aws.amazon.com/jp/aws-jp-introduction/aws-jp-webinar-service-cut/

名前も知らないようなサービスは Black Belt のスライドで要点を掴むようにした。いわゆるドキュメントを読むよりはわかりやすく、短時間で読めるのでおすすめ。具体的な使い方のイメージを掴みたい場合は Developers.IO でハンズオン記事を探していた。

模擬試験

公式で模擬試験が有料で提供されており、受験はしたのだが、個人的にはあまりオススメしない。問題が本番65問に対して20問と少ない上、先のデジタルトレーニングと重複したものも多く（ランダム出題だとすれば僕の運が悪かっただけかもしれないが）、コストパフォーマンス的にいまいちだった。

重点的に学習した箇所

Active Directory 関連

仕事で Active Directory を扱ったことがなく、まったく土地勘のない領域だった上、 AWS には AD 関連のサービスが複数あり、それぞれの違いと使い方、使用するシチュエーションなどをしっかり押さえるようにした。

監査、分析系のサービス

とにかく数が多いので、こちらも使い分け方を頭にたたき込んだ。具体的には Config, CloudTrail, Trusted Adviser, Inspector, Detective, Security Hub, Shield, QuickSight, GuardDuty, Macie あたり。それぞれ何が出来るのか、どの AWS サービスと連携するのか、発見的統制なのか予防的統制なのか、複数 AWS アカウントで使いたい場合はどうすればいいのか、といったところを押さえた。

知らなかったサービス

Macie, QuickSight, CloudHSM の3つと、先の AD 関連のサービスは恥ずかしながら存在すら知らなかった。

自宅受験

自宅受験するのは初めてだったので、この部屋じゃダメだと言われないか、何かトラブルになったりしないかと、試験そのもの以上に緊張した。結果から言えば特にトラブルはなかった。

受験環境について

そこそこ広いリビングの片隅に仕事スペースを設けているのだが、そこで受験した。部屋が広いしリビングなのでいろいろとモノは置いてあるのだが、書籍類やガジェット類を片付けて綺麗にしていれば何も言われることはなかった。

中には風呂場で受験した人もいると聞いていたので、そのレベルで「何もない」場所じゃないといけないのか……？と疑心暗鬼になっていたが、そこまで厳しくはないらしい。ただ、同居の家族の関係で絶対に邪魔が入らない場所が必要だとか、そうなってくると事情は異なってくるし、不安や心配のない環境で受験するのがベターだとは思う。いろいろと余裕があればビジネスホテルなどを借りるのもアリかもしれない。

PC の再起動を求められる場合がある

一度試験準備の過程で接続の問題が発生し、試験官から PC の再起動を求められる場面があり、若干ヒヤッとした。というのも、ソフトウェアアップデートを数日放置していることが多く、再起動後にアップデートで数十分待つことになるのではないかと思ったから。幸いアップデートは適用済みだったのですぐに起動したが、試験前日までに一度再起動しておいたほうが良いと思う。

マルチディスプレイは NG

試験前に、PC が試験に適したシステム環境になっているか（カメラが使えるか、他のアプリが起動していないかなど）自動で確認するプロセスがあり、その中では警告されることはないのだが、実際にはマルチディスプレイは NG で、いざ試験問題が配信される、という最後のプロセスが一度うまくいかなかった。ちゃんとシステム要件の案内には記載があったので、読み飛ばしていた自分が全面的に悪いのだが、自動チェックで弾かれなかったので油断してしまった。他にも要件はいろいろとあるのでちゃんと読みましょう。

Impression

AWS の認定試験は何年も前に一度テストセンターで受けたこともあるのだが、自宅で想像より手軽に受けられたので、もし次回受ける機会があっても自宅でいいかな、と感じた。とはいえ最大3時間、実際には2時間問題を解いていたのだが、かなり集中力を要するので、自宅でそれだけの時間、確実に集中してパフォーマンスを出せるのか、というのも考えたほうがいい。気晴らしついでにホテル受験というのもやってみたくはある。

何にせよ、そこそこお金もかかるものだし、一発合格できてよかった。

ちなみにここでテーマにするのは「アラート戦略」であり、「監視戦略」ではない。何を「アラート」するべきかという観点で書いていく。

Kubernetes の監視レイヤー

ひとえに「Kubernetes の監視」と言ってもレイヤーが複数ある。

1. Kubernetes 自体が正常動作しているか（コントロールプレーン）
2. Kubernetes クラスタが正常動作しているか（各種ソフトウェア）
3. ワーカーノードが正常動作しているか
4. ワーカーノード上にデプロイしたコンテナが正常動作しているか
5. コンテナが正常にサービスを提供できているか

1点目はマネージド Kubernetes を利用している場合には、不要かもしれない。ただ、その場合も監査や分析用にログ、メトリクスの出力と保存は行っていたほうがいいだろう。3点目に関しても、例えば EKS の Managed Node Group で自動制御となれば、基本的にはマネージドで動作保証されるので、監視する観点は少なくなる。このように1,3点目に関しては、 Kubernetes クラスタとして何を使うかにより、必要な監視に幅が出てくる。

2点目に関しては、 Kubernetes のクラスタ動作を制御するために追加で導入するソフトウェア、例えば descheduler のようなものを想定している。このようなソフトウェアは正確には「Kubernetes」という言葉が表す範囲の外ではあるが、クラスタの動作をより低いレイヤーで制御するものであり、かつ、マネージドの領域ではないので、マネージド Kubernetes を使っていたとしても独自に監視が必要になってくる。

4点目以降は、どのようなクラスタを選んでも基本的には監視が必要になる。5点目についてはアプリケーションレイヤーの話になるので、 Kubernetes 固有の戦略というよりは、一般的な外形監視などで要件を満たせる場合も多い。

アラートの基本戦略

一般的なアラート戦略は Monitoring 101: Alerting on What Matters | Datadog の内容をよく参考にしている。

• アラートはレベル分けし、最も緊急のアラートだけを即時通知（ページング）する
• アラートは障害の原因ではなく症状に対して設定する

特に2点目が重要で、一般的なアプリケーションであれば CPU 使用率の高騰ではなく、それによって引き起こされるアプリケーションの応答遅延のほうを監視するべきだ、ということになる。なぜなら CPU 使用率高騰は、必ずしもユーザー影響を及ぼすとは限らず、偽陽性のアラートになる可能性があるからだ。

Kubernetes においては、先のようにレイヤーが複数に渡るため、「原因」と「症状」が複雑に絡み合う。例えばワーカーノードのスケーリング台数が上限に到達してしまいスケールできず、新たな Pod が起動できなくなった結果、アプリケーションが稼働しなくなったとする。この場合、 Pod が起動できなくなったことはアプリケーションレイヤーからすれば「原因」だが、コンテナレイヤーや、 Kubernetes の正常稼働という観点からすれば「症状」だ。このように、レイヤー別で監視するべき「症状」を考えていく必要がある。

また1点目に関しても、 Kubernetes には Reconcile Loop の概念があるため、何らかの症状が発生したとしても、自動的に回復する場合が少なくなく、そういったものについてはページングは必要なく、翌営業日以降対応できるようチケットを切るなり、チャットに通知するなりでよい。 Reconcile Loop が正常に動作していない場合や、 Reconcile Loop が及ばない範囲の障害が主にページングの対象となる。

レイヤー別のアラート戦略

以上を踏まえてレイヤー別のアラート戦略を考える。

ワーカーノードの正常動作

ワーカーノードに関しては、何らかのオーケストレーションを利用していない場合は、通常の Linux サーバーと同等の監視が必要になると思われるが、運用経験に乏しいので深く踏み込まないことにする。

EKS Managed Node Group のようなオーケストレーションを利用しており、 Cluster Autoscaler を導入していれば、ノードのダウンや不足は自動的に解消されるので、監視が必要な範囲は限られてはくるが、ゼロではない。

• ノード台数 / オーケストレーション最大台数
• ノードのディスク使用率

Kubernetes クラスタにアプリケーションを増やしていけば、いつかはノード台数が設定の最大台数まで達し、それ以上スケールできなくなるおそれがある。そうなる前に設定変更をトリガーできるようにしたい。また、コンテナイメージの pull が積もり、ノードのディスク使用率がかさむと、 CPU やメモリといったリソースを活用しきっていないうちにノードが利用不可になってしまう場合もありえる。いずれもページングの対象ではないだろうが、対応のためにアラートは必要になる。

Kubernetes クラスタ制御のための各種ソフトウェア

先述の descheduler のようなソフトウェアだが、これはソフトウェアの種類により監視項目も変わってくるので、一概に言えるものではない。知らぬ間に停まっていた、正常に動作していなかったということがないように、何らかの手段で監視するほうが望ましいと思われる。

主に考えられる手段としてはログに出力されるエラーによるアラート、何らかの通信を受けるソフトウェアであれば、疎通可能であるか、などだろうか。また Prometheus が scrape できるような OpenMetrics の形でメトリクスを提供しているソフトウェアもあるので、その場合は分析用にメトリクスも取得しておきたい。 descheduler であれば、 https://localhost:10258/metrics で2種類のメトリクスを提供している。

個人的にはこのレイヤーの監視が最も重要だと考えている。このレイヤーは仮にエラーであっても、クラスタ自体の稼働、アプリケーションの稼働には影響を及ぼさない可能性があり、適切に監視しなければ見過ごしやすいからだ。

コンテナの正常動作

ひとえにコンテナといっても Deployment, Job, DaemonSet など、起動方法は様々であり、それぞれに応じた監視が必要になってくる。

• Deployment の available / desired
• DaemonSet の unavailable
• Job, Cronjob の failed
• CrashLoopBackoff の発生
• ImagePullBackoff の発生
• Restart の頻発

Deployment については desired と同数の Pod が available になっていない状態が継続している場合、 Reconcile Loop が何らかの異常をきたしている可能性があるので、監視しておきたい。ただし、一時的にコンテナがダウンした場合や、 Horizontal Pod Autoscaler で desired が拡張され、一時的に available が不足するといった場合もあるので、閾値は多少ゆるめでいいと考えている。アプリケーションの提供に必要十分な数の Pod が起動していないのであれば、それはアプリケーションレイヤーで監視するべきであり、ここでは「Deployment の Reconcile Loop が長期間正常に動作していない」という「症状」に着目すればいい。

その他のリソースについても同様に、 Reconcile Loop が働いていない場合にアラートすると考える。 DaemonSet であれば unavailable >= 1 が継続している場合、 Job や CronJob であれば failed が多発している場合などだ。これらについては僕としてはページング相当と考えている。

CrashLoopBackoff や ImagePullBackoff は悩ましいところではある。 CrashLoopBackoff, ImagePullBackoff は「コンテナが起動できない」という症状に対する原因に近いと思われるからだ。しかし、例えば Deployment のローリングアップデート中、これらのエラーで新規 Pod がずっと起動できないような場合であれば、 available / desired では検知できないが、こちらの監視でカバーができるし、必要に応じてアラートを上げても良いのではないだろうか（もちろん、 CD pipeline でアラートが上げられるならそちらでも良いが）。 ImagePullBackoff の発生は多くはないだろうが、コンテナレジストリの障害など、発生するパターンがゼロではない。あるいは Restart が多発しているような場合にアラートする手もある。

アプリケーションの正常動作

このレイヤーは基本的なアプリケーション監視の考え方とほぼ同等だが、1つ考えておきたいのは、 Readiness / Liveness probe と適切に組み合わせる点だ。Liveness probe では、応答に失敗する Pod を自動的に Restart させることができるので、 Restart により修復できるような可能性があれば、 probe 側で適切に監視させ、その上で一定時間修復されないような場合に、監視ツールからアラートを上げるような仕組みにしておきたい。 Readiness probe は、何らかの原因で一時的に応答できなくなる場合のある Pod に設定することで、外部からのリクエストが受け付けられないような状態を避けることができ、結果的に外部からの監視で偽陽性アラートが発生するのを抑えられる可能性がある。

Conclusion

Kubernetes の場合も「症状についてアラートする」「対処が必要なアラートについてページングする」という原則を忘れなければ、一貫した監視戦略を練っていくことができる。気をつけなくてはならないのは、 Reconcile Loop やマネージド Kubernetes の機能により、「対処が必要」な範囲を適切に見極める必要があることと、監視に必要なログやメトリクスの収集方法が、ソフトウェアやレイヤーに応じて異なってくることであり、このあたり難しさを感じている。メトリクスであれば kube-state-metrics の全容のみならず、ホスト側のメトリクス、さらに先述のような OpenMetrics を提供しているアプリケーションもある。まずはメトリクスやログをきちんと収集して可観測性を高めた上で、手持ちの材料を踏まえた監視戦略を都度適切に考えるようにしていきたい。

参考文献

• Datadogを使用してKubernetesアラートを自動的に作成および管理する| Datadog
• Alerting on Kubernetes: How to & best practices | Sysdig

10年ぐらい前から「現金は極力使わない」「なるべく処理を自動化して認知負荷を減らす」というモットーで仕組み作ってきたけど、どこかに書き記したことはなかったので書いてみる。ここは一応技術ブログなのだが、特にプログラミング的な要素は何もない（昔はあったんだけど）し、わりとみなさん良くやっている方法だとは思っている。極力自動化する、認知負荷（運用負荷）減らす、みたいな考え方はIT系というか SRE っぽいかもしれない。

ざっくり図にすると、現状のお金の流れはこんな感じ。要素ごとに説明してみる。

銀行関連

住信 SBI ネット銀行をハブにする

https://www.netbk.co.jp/contents/

ハブとして使っている銀行。すべてのお金はここに入ってきてから、いろんなところへ流れていく。

もう10年ぐらいは使っているし、特に不満もないので乗り換える予定もない。 ATM 手数料関連で「改悪」と何度か言われてきてはいるけれど、給与受け取り口座にして、デビットを月3万円分使っていれば、毎月10回は ATM 入出金無料になるので、別に不満はない。最近は現金をあまり使わないので、毎月の出金機会は1、2回ぐらいだし。

また、SBI証券との「ハイブリッド口座」の機能があり、お金の移し替えが簡単なのも大きい。貯金に回せるお金は全部ここへ入れていて、さらに投資に回したりもしている。微々たるところではあるが、ハイブリッド口座の金利は2021年8月現在0.01%で、普通の銀行に眠らせるよりはマシになる。

他にも自動定額振り込みの機能、スマホアプリがあればキャッシュカードなしで ATM 取引ができるサービスなど、いろいろ便利に使わせてもらっている。最近はアプリだけで振り込みから何から全部完結するようになった。

銀行を使い分ける

他、何かのためにとメガバンクとゆうちょの口座は取りあえず押さえている。いずれも積極的には使っていない。

用途別で銀行口座を分けてはいて、ゆうちょのほうは現状「引き落とし用口座」になっている。毎月のクレジットカード利用料や、 iDeCo の支払いはここからになっており、 SBI 銀から手動で必要額を振り込んでいる。別に SBI 銀から直接引き落としてもいいんだよね、と感じてはいる。ほぼ惰性でこうなっている。

メガバンクのほうは、現在2人暮らしなので家のお金をストックする場所としていたが、最近後述する Kyash の共有口座を使い始めたので休眠状態になりつつある。結果、「銀行を使い分ける」必要性はあまり感じなくなってきたところではある。認知負荷のことを考えると、このあたりはそろそろ見直してよさそう。

支払い手段

支払いは基本的にキャッシュレス。優先順位は QUICPay > モバイル Suica > Kyash Card > 現金としている。

FeliCa / NFC 決済が好き

最も速い決済手段がスマホでの FeliCa / NFC 決済だと思っているのでこれが最優先。 QR 決済サービスも、友人との送金用途を考えて使ってはいるものの、支払いのときにアプリを立ち上げるのがどうにも面倒であまり使っていない。特に、バーコードをこちらで読み込んで、金額を自分で入力するタイプの支払いだと使うのにだいぶ抵抗がある。何も考えずにタッチして「ピッ」が一番楽。

優先しているのは、後述の Kyash と連携した QUICPay だが、たまに使えない店舗もあるので、その場合はモバイル Suica が次点。

クレジットカードではなくデビットを使う

クレジットカードを使わないことにして、デビットカードを代わりに使っている。 MoneyForward を使っているので、クレカの利用額がわからなくなるを気にしているわけではないのだが、使ったお金がすぐに手元から消えるほうが精神衛生的に楽。ポイント還元率などでクレカのほうが得な場合が多いのは理解していて、一時期どのクレカがお得か、みたいなことをやってもいたが、あんまりそこに時間使いたくないなという気にもなってきて、 SBI のデビットだけ使うことにした。

ただ、デビットが使えない場面というのがあるので、クレカも持ってはいる。いくつかの定期的な支払いで使っている。

Kyash で支払いを集約する

https://www.kyash.co/

SBI 銀が入金側のハブなら、支払い側は Kyash がハブになっている。 Kyash で Kyash Card と呼ばれるリアルカードを発行し、 QUICPay に紐つけてそちらをメイン決済手段に。カードのほうも持ち歩いて、 FeliCa / NFC 決済が使えないときの代替に。入金手段は SBI デビット。これで Kyash から支払えば、その場で銀行口座から引き落とされるようになる。

Kyash もまたサービス変更でいろいろ言われているが、当初「クレカやペイジーから入金できて、それを送金にも決済にも使えるし、決済時2%還元しますよ（参考：送金を身近に　リアルカードで決済シーンも拡大　「Kyash」の戦略を聞く：モバイル決済の裏側を聞く（1/3 ページ） - ITmedia Mobile）」と言っていたのに、銀行連携が中心のバンキングサービスへ趣旨換えしてしまったので、僕のようなクレカ（デビット）連携をメインとしていた初期ユーザーは、それは混乱するであろうというところ。「改悪」というよりは、サービスのターゲット自体が変わったよね、と認識している。

ただ、それでも利点は多いので使用をやめる予定はない。利点の1つは、最近「共有口座」と呼ばれる、他の Kyash ユーザーと共同で入出金できる口座機能。現在、家庭のお金はここに入れてここから払うことにしている。従来は共有用の銀行口座を設けて、デビットカードを作って支払っていたものの、デビットは複数人複数名義で持てないので、カードを持っていないほうが支払うのには使えず不便だった。 Kyash なら1つの口座から各々のカードで支払いができてすごく見通しがいい。

もう1つは、クレカ / デビットのプロキシとしての役割期待がある。手持ちのカードはなんであれ、 Kyash に紐つけておけば決済の口がここに集約されるのが気持ちとして楽であり、仮に Kyash の番号が流出だとか不正利用されても、 Kyash さえ停めれば本体側には被害が及ばない。また Kyash と連携さえすれば、どのカードであっても QUICPay 化できる。実際のところ、 SBI デビットは現状 Google Pay には対応しておらず、 Kyash 連携で初めて QUICPay 化できている。このあたりが使っている理由として大きい。

つまるところは「支払い手段の集約」というところに魅力を感じている。送金、カード決済、非接触決済、すべてが Kyash に集まっているというシンプルさが気に入っている。

投資はほったらかし

投資は大したことをしていなくて、山崎元『全面改訂 超簡単 お金の運用術』 を読んでください、それが全てです、というところ。もうそこそこ古い本になってしまっており、状況や制度が変わった部分もあるが、基本路線は同じ。

一言で言えば iDeCo と（つみたて）NISA には全振り、インデックスファンド中心に買って短期的な売り買いはせず、基本ほったらかし。個別株を買わないわけではないけれど、買うときはリターンを目的とはしていなくて、応援のつもりとか、株主優待目的とかにしている。

長期での投資しか考えていないので、基本的に路線を変えるつもりはない。とはいえまだ始めて10年経つか経たないかぐらいで、今は株高もあって儲かってはいる状態だというのはあるので、将来的に変動要素があれば何か見直しはかけるかもしれない。

集計は MoneyForward

https://moneyforward.com/

最後に、集計には MoneyForward 。昔はパスワードを渡すことを忌避していた時期もあったけど、現在は API 連携できる銀行も多いし、便利に使っている。そして一度使うと手放せない。現金を使う機会は月間で先月が5回、先々月が3回だったので、ほぼ全自動ですべてのお金の履歴がここに蓄積されている。

Conclusion

お金まわりで、ちょっとした得をする手段というのはいくつもあるんだけど、そのために労力をかけたり何か考えることは基本的に捨て去っている。その代わりに入金はSBI銀、出金は Kyash という具合に集約してシンプルにすることで、認知負荷、運用負荷を下げることに「得」を感じるというのが自分のスタイル。考えることを増やさないようにこれからも運用を続けていくつもり。

『Building Secure & Reliable Systems』は Google による SRE Books の3冊目に位置づけられており、タイトル通りセキュリティにフォーカスされている。 SRE とセキュリティの関わり方について問題意識があったので、軽くではあるが読んでみた。

最初に自身の問題意識を具体化して書いておくと、以下のような点である。

• SRE はセキュリティの責任主体となるべきなのか？
  • 仮にそうだとすれば、 SRE のスキル範囲が少々広すぎやしないだろうか？
• SRE が守るべき「信頼性」の中にセキュリティも含まれるのか？
  • なんとなく「そうだろう」という思いはあったが、きちんと考えられていない
• SRE のプラクティスの中で、セキュリティをどう取り扱っていくべきか？

セキュリティは誰の責任か

文中の表現を借りれば、本書は SRE book や SRE workbook では触れられていなかった、 SRE におけるセキュリティへの関わり方をまとめた1冊にあたる。ただ、必ずしも SRE だけに向けられた内容ではないし、ましてや SRE がセキュリティに関する最終責任を担うべきだ、といった論調でもない。

本書で繰り返されているのは、セキュリティはすべての人の責任であるということだ。専任の専門家だけではなく、すべての人がセキュリティの確保に携わるべきだとしており、 Preface においては対象読者について以下のように書かれている。

Because security and reliability are everyone’s responsibility, we’re targeting a broad audience: people who design, implement, and maintain systems. We’re challenging the dividing lines between the traditional professional roles of developers, architects, Site Reliability Engineers (SREs), systems administrators, and security engineers.

信頼性とセキュリティの共通点

本書では「セキュリティ」という概念を、 SRE における「信頼性」の概念と似た性格のものとして取り扱っている。いずれもソフトウェア開発において、速度を優先するというエクスキューズによって軽視される場合が多く、サービスが順調に運用されているうちは、不可視なものになりがちだ。しかしながら、サービスの成熟後に見直しを掛けることは困難であり、信頼性もセキュリティも、設計初期の段階から考慮するのが望ましい。

このような似た性格を負っているため、 SRE が有する信頼性確保に関するプラクティスを、セキュリティ施策にも応用できる。例えばインシデント発生を的確に検出するためには、いずれも可観測性の向上や、適切なロギングが欠かせない。実際にインシデントが発生した場合に備えた、危機対応手順を整備しておくことも必要になる。「100% 完全な状態」というのが不可能というのも両者の共通項であり、本書の中では言及がないが、 SLO の考え方をセキュリティに適用することもまた可能だろう。 eureka による Security / AuditabilityをSREチームの成果指標に加えた話 - Speaker Deck では、実際にセキュリティ関連の指標を SLI として取り入れた例が紹介されている。

セキュリティ専門家の必要性

先ほど「セキュリティはすべての人の責任である」という一節に触れたが、これは専門的なセキュリティエンジニアが必要ないということを意味しているわけではない。Chapter 20. Understanding Roles and Responsibilities において、セキュリティに誰が取り組むべきかという点に関してより踏み込んだ解説がされている。

信頼性とセキュリティが性格的に似ている、というアナロジーに今一度頼ろうと思うが、信頼性に関しても SRE だけが集中的に担うものではなく、「すべての人」が意識するべきであり、開発ライフサイクルに組み込むべきだというのが SRE book などで書かれていることだ。しかし、だからと言って SRE が必要ないわけではなく、信頼性確保のスペシャリストの立場から、開発者の作業に協力していくことになる。セキュリティエンジニアについても同様に、微妙な判断を迫られる場面などにおいて専門的見地が必要になるとしている。

では、セキュリティエンジニアを組織内のどこに配置するか。これに関してはいくつかのパターンが紹介されているが、興味を引かれたのは中央に独立したセキュリティチームを置くパターンだ。これによりセキュリティを犠牲にしてローンチを急いでしまうような場面において牽制が働くわけだが、当然ながら開発速度低下が懸念される。そこで各チームにはセキュリティチャンピオンと呼ばれるポジションを設け、セキュリティチームとのコラボレーションを促進する役割を務めることで、開発速度とセキュリティ双方のバランシングを行う。

ちなみに、この「セキュリティチャンピオン」という概念を僕は初めて知ったが、本書が初出というわけではないようで、2014年に 開発チームのなかに「セキュリティチャンピオン」を作れ――AppSec APAC 2014から | 日経クロステック（xTECH） で言及されていたりする。開発チームのセキュリティ意識を向上させる上でも、非常に良い施策ではないだろうか。

Impression

冒頭に書いた通り、僕の問題意識の発端はセキュリティの「責任主体」の所在にあったのだが、本書はそれを「全員」と言い切っていて目が覚めた思いがした。当然ながら、本書でも書いているように、専門のセキュリティエンジニアを雇い、微妙な問題などについて最終的なジャッジを下してもらえる状態を作ることがベストではある。ではあるが、高い専門性を持ったセキュリティエンジニアは国内の転職市場では不足しがちではあるし、自身でスキルを高めて、カバー可能な範囲のセキュリティには積極的に責任を負っていく姿勢が必要なのだろうと覚悟できた。

なお、 SRE がセキュリティの最終責任を担う組織体系として、国内では mixi の事例を SRE NEXT 2020で、SREとセキュリティに関するお話をします | by Isao Shimizu | mixi developers | Medium で見かけた。専門家が不在である際に、最終責任をどこに担わせるかは組織によるだろうが、 SRE はその有力候補にはなり得るだろうと認識している。ただ、やはり SRE のカバースキルが広すぎる結果にはならないか？という懸念はある。タスクとしては担いつつ、可能であればスキル面は外注するといった方策も考えられるかもしれない。

また、そもそもの話として、セキュリティ上の問題でサービスが停止したりすることがあれば、それは信頼性指標（多くの場合可用性など）を損ねる結果にも繋がってくる。そのため SRE は結局のところ、セキュリティと無関係でいられる道理はない。先に挙げた eureka の例のように、セキュリティに関する指標（例えば検知される脆弱性の数 x 個以内）を SLI として採用してしまうのも1つの手かもしれない。信頼性確保のための仕組みを開発サイクルの中に組み込んでいくための SRE のノウハウは、セキュリティに関しても極めて有効なはずだ。この点、メルカリによる DevSecOpsとは何か — 導入する組織が増加している理由 | メルカリエンジニアリング なども参考になる。

組織や文化面の問題意識から読んだため、このエントリーでもそういった記述に関して中心に取り上げたが、本書では設計、実装、保守・運用の各フェーズにおけるより具体的なプラクティスも豊富に盛り込まれている。繰り返し書いてきた通り、ポジションを問わずあらゆる人におすすめできる1冊だと感じた。

ロータリーエンコーダ付きのマクロパッドというものが欲しくなり、わりと直感的にカッコいいなというのと、必要十分なキー数だなというところで遊舎工房の Quick7 を購入した。これ自体は文字通りクイックに作れてとてもいいキットだった。慣れている人であれば1時間とかそこらで作れると思う。

さて問題はここからで、マクロパッドというものはホームポジションで固定的に使う普通のキーボードと違い、ポジションの自由度が高い。そのため使っているうちに有線が煩わしく思えてきた。幸いにして家には、使っていない BLE Micro Pro があったので、では無線化しようと思い至ったのだが、そう簡単な話ではなかった。

BLE Micro Pro との config 互換性

BLE Micro Pro (BMP) は自作キーボードでよく使われる QMK Firmware と高い互換性を持ったファームウェアを使用しているが、完全互換ではない。各種設定は QWK ではC言語で定義することになるが、 BMP ではこれを JSON 形式に変換したものを用いる。この2つが1対1には必ずしも対応していない。

Quick7 で具体的に問題となったのは、キースイッチの押下を感知する基盤のピン設定である。多くの自作キーボードでは、 MATRIX_PINS を用いる。これはキーボードを格子配列にみたてて、行列それぞれにピンを割り当てる方式だ。

簡単に言えば上図の1〜6がピン割り当てになる。1と5のピンに通電すれば「D」が押されたと検知する、という具合だ。 QMK Firmware での設定の書き方は、 crkbd (Corne Keyboard) を例にすると以下のようになる。

#define MATRIX_ROWS 8
#define MATRIX_COLS 6
#define MATRIX_ROW_PINS { D4, C6, D7, E6 }
#define MATRIX_COL_PINS { F4, F5, F6, F7, B1, B3 }

BMP の場合 は以下。

"matrix":{"rows":8,"cols":6,"device_rows":4, "device_cols":6,
	"debounce":1,"is_left_hand":1,"diode_direction":0,
	"row_pins":[7, 8, 9, 10],
	"col_pins":[20, 19, 18, 17, 16, 15],

一方 Quick7 など、一部のマクロパッドにおいては MATRIX_PINS ではなく、１キーにつき1ピンを割り当てる、 DIRECT_PINS という設定を用いている。キー数が少ない故、マトリクスの形を取らなくとも、 Pro Micro のピンが足りるためと思われる（設計者ではないので断言ができない）。そして現状、 BMP の config.json は DIRECT_PINS に対応していない。

ではどうしたか、だが、擬似的に 1x9 のマトリクスとみなすことで対処した。

実は、 MATRIX_PINS で設定している際、行列双方のピンが通電していなければ、キーを検知しないわけではない。例えば先の図で1番のピンだけが通電したとする。このときは、A、D、Gの3キーが押されたと検知する。したがって 1x9 のマトリクスとみなし、 DIRECT_PINS として設定されていた9つのピンを各列に設定すれば、各キー入力の検知は可能になる。

具体的には、 Quick7 の QMK Firmware における DIRECT_PINS は以下の設定であり、

#define DIRECT_PINS { \
      { D2, D4, F4 }, \
      { D7, B1, B3 }, \
      { E6, B4, B2 }, \
}

これに対し、 BMP をこのように設定した。ピンの表記が双方で異なるためわかりづらいかもしれないが、 DIRECT_PINS の各行のピンを横に並べ直すような形で col_pins に設定している。

"matrix":{"rows":1,"cols":9,"device_rows":1, "device_cols":9,
	"debounce":1,"is_left_hand":1,"diode_direction":0,
	"row_pins":[13],
	"col_pins":[10, 11, 14,  9, 16, 15, 2, 7, 20],

ちなみに row_pins に設定している13ピンは、 Quick7 では使われていないピンをダミーで設定した。

電池基盤格納の物理的な問題

BMP を稼働させるには、別途電池基盤を接続する必要がある。 Quick7 はかなりコンパクトな筐体であるため、これをどこに格納するかが問題になった。

多いパターンとしては、遊舎工房で販売されている電池基盤が BMP とほぼ同じ大きさのため、 BMP の裏側に載せるような形で格納するパターンだ。実は手元にあった BMP は、すでにこの形で電池基盤をはんだ付けしてあるものだった。しかし、 Quick7 はトッププレートとボトムプレートの間を 10mm のスペーサーで結んでおり、この隙間に電池基盤付きの BMP は収まらなかった。

結論としてはシンプルに、 15mm のスペーサーに換装することで対応した。電池基盤を BMP と接着せず、横に並べるような形で配置すれば、もう少し薄くすることは可能かもしれない。

Conclusion

はじめに書いたことの繰り返しだが、特にこういったやり方をおすすめする記事ではなく、技術的なメモに近い内容である。ロータリーエンコーダ付きマクロパッドでは、公式に BMP 対応している Palette1202 なども存在するので、そちらを使ったほうがスムーズかもしれない。また、 QMK Firmware や BMP に僕自身そこまで詳しいとは思っていないので、ここで書いた方法以外の何かスマートな解決策が存在する可能性もある。

とはいえ出来には満足している。普段使いは Corne Cherry で長らく落ち着いてしまったが、たまにはこうやってキーボードを作ることも続けてみたい。

今回、このブログの Lighthouse スコア改善に取り組んでみた。背景としては、 ブログを Next.js + Vercel に移行した - the world as code のときに書いた以下の一節がそのまま当てはまる。

僕はインフラエンジニア出身の SRE で、経歴を辿るとサーバーや RDB のチューニングでパフォーマンスを維持することには注力してきたけど、フロント側の知識はほぼまったくと言っていいほどない。でも SRE がサイトの信頼性、具体的にはレスポンスの最適化に責務を負っているのに、フロントを理解していないというのはダメだろうと。静的なものを可能な限り CDN に置く時代において、サーバーのインフラ的なチューニングだけの知識だけでは心許なくなった。

ということで、ウェブアプリの品質とはどのような点が見られるのか、理解を深めることを目的としている。

Before / After

最初にスコアの Before / After を貼っておく。対象は先にも挙げた ブログを Next.js + Vercel に移行した - the world as code のページである。

いずれのスコアも大幅に改善し、ほぼ満点の状態まで引き上げることができた。 Lighthouse の評価ポイントは、 Google が公開している https://web.dev/ にまとめられており、今回のスコア改善にあたっても、主にここを参考として取り組んだ。

ちなみに Best Practices がもともと100点を獲得しているが、 Next.js + Vercel という新しめのフレームワークとデプロイ環境を用いていることもあり、何も考えずともある程度自動的にチューンナップされている面はあるのだと思う。

以下、改善した点を順に見て行く。

Performance

パフォーマンスでは、主に表示速度の面でのメトリクス6種類が指標になる。表示速度というと、インフラ側の人間としては単に response time という言葉で括って考えがちなのだが、最初に DOM element が表示されるまでの時間を示した First Contentful Paint (FCP) 、 Largest Contentful Paint (LCP) など、実際にページを表示するクライアントの立場から見れば、複数の観点で速度評価が可能なのだということを知った。

画像の改善

Performance で減点材料となったものの1つが画像だった。容量が大きすぎる、あるいは次世代フォーマットである WebP を使うべきだといったものだ。たかがアバター画像で 450KiB は確かに重いかもしれない。

シンプルに WebP 化で改善を図った。 macOS であれば brew install webp でインストールされる cwebp コマンドで簡単に変換ができる。結果、これだけで効果は抜群だった。

❯ ls -l profile.*
-rw-r--r--@ 1 chroju  staff  7181  1 17 19:03 profile.jpg
-rw-r--r--  1 chroju  staff   754  6 25 19:47 profile.webp

WebP は Safari (iOS/macOS) が2020年になってから標準サポートするなど、まだまだ新しいフォーマットであり、商用のウェブサイトであればきちんと png/jpeg と表示を分けたり、手動変換ではなく ImageFlux などによる自動変換を検討するべきだろう。今回はあくまで個人サイトなので、妥協した方式を採っている。

ちなみに、このブログの画像はアバター以外は基本的に Gyazo 上のものをリンクしており、これについては現状もそのままになっている。当然ながら自ドメイン上にホストしたほうが表示は速くなるので、 Gyazo リンクをやめることも検討している（このエントリーでは試験的にやめてみている）。

Reduce initial server response time

TTFB (Time to first byte) の改善を促されている。これについてはインフラ面の改善も視野に入ってくるが、このブログではフルマネージドな Vercel を使っているので、その点での改善は望めない。また、無駄に SSR を使っている箇所があれば SSG を使えないか検討するという手もあるが、このブログは全面的に SSG で組んでいるので、その点も問題はなかった。従って打つ手が難しかったのが正直なところ。

ひとつ気になった点として、レスポンスがキャッシュからのものか否かを Lighthouse は考慮していなさそうだという点があった。というのも、一度ページにアクセスして CDN キャッシュを作ってから再度 Lighthouse に掛けると、このスコアが改善したからだ。 response time の改善においては、キャッシュ活用も含めて検討したほうがいいかもしれない。

Reduce JavaScript execution time

JavaScript 実行時間の改善も促された。最も実行時間が長いスクリプトを確認したところ、 FortAwesome/react-fontawesome であった。使っているアイコンだけではなく、横着してすべてのアイコンを読み込むような設定を書いていたので、これは明確に自分が悪い。これだけで JS の総実行時間が 1.5s -> 0.6s に改善した。

- import { fab } from '@fortawesome/free-brands-svg-icons'
- import { fas } from '@fortawesome/free-solid-svg-icons'
+ import { faGithub, faKeybase, faSpeakerDeck, faTwitter, faInstagram } from '@fortawesome/free-brands-svg-icons'
+ import { faRssSquare, faTags } from '@fortawesome/free-solid-svg-icons'

Accessibility

Contrast

Accessibility の点では、色のコントラストで警告が出ていた。エントリーの日付表記の部分はフォントカラーを薄いグレーにしていたのだが、これが背景とのコントラストが十分ではなく、視認性が悪いとのことだった。

色のコントラストは Devtools の「Elements」タブで color をクリックすることで、適切な状態を確認できる。適切なコントラストは WCAG で規定されており、最低でも 4.5:1 を確保したレベル AA 、より望ましくは 7:1 のレベル AAA を満たすべきとされている。上図、グラデーション状態のカラーパレットに波線が引かれているが、このうち上のラインがレベル AA で、下のラインがレベル AAA に当たる。今回はこれを用いてレベル AAA を満たすように文字色を改善した。

Others

その他、軽微なところで以下の2点を改善している。

• <html> に lang 属性が指定されていなかった
• Font Awesome によるリンクアイコンに text の設定がなく、スクリーンリーダーなどに対して Not friendly な状態だった

Best Practices

ここは当初より100点だったので、改善したポイントはない。主に以下のようなポイントがチェックされる。

• HTTPS を利用している
• ロード時に位置情報取得や通知の許可を求めていない
• パスワードフィールドへの「ペースト」を禁止していない
• フロントエンド JavaScript に既知の脆弱性が存在しない
• 非推奨の機能（AppCache や廃止された API）を用いていない
• charset や doctype が正しく宣言されている

SEO

Tap targets are not sized appropriately

タップ可能な要素が小さすぎるという警告。スマートフォンで表示した際の誤タップを防ぐべく、最小でも 48x48px を保つようにとされている。

具体的には、ページ最下部に設置した各種ソーシャルサービスのアイコンであり、必要とされるサイズを確保できるように CSS を書き換えた。

PWA

PWA に関しては、ここまで見てきた項目のように採点の対象というわけではなく、 PWA として動作するのに必要な設定が成されているかどうかをチェックし、その結果をアイコンで表示するというものになっている。

せっかくなので、今回 PWA 化も施した。モバイルでもデスクトップでも、対応するブラウザで開けばインストールが可能になっている。本当にただ PWA としての要件を満たす状態にしてみた、というだけなので、インストールしたところで更新通知を飛ばしたりとかはしない。オフラインの際に、専用のページへフォールバックさせる、ぐらいのことはしてみている。

Next.js における PWA 化は shadowwalker/next-pwa を使うのが簡単で、 README 内で Zero Config を謳っているが、実際のところ2、3ファイルを少し書き換えるだけで PWA 化できるようになっている。

Impression

少し意外、と言ったらよろしくないかもしれないが、 監査項目において過剰に Google Friendly にするべきだ、というようなものはなく、中立的に Web サイト（Web アプリ）としてクリアしておくべき条件のリストになっていると感じた。例えば AMP に関するチェックが入ってもおかしくはないように思うが、2021年現在においてはすでに下火になりつつあることもあってか、そういった項目はなかった（このあたりの経緯は、折しも昨日 本サイトの AMP 提供の停止とここまでの振り返り | blog.jxck.io というエントリーが出たのでちょうど読んだところだったりする）。もっとも、そうは言ってもあくまで Google の採点である、ということには留意が必要かもしれない。 Performance の項で測られている項目も、 Google が掲げる Core Web Vitals との重複が大きい。

とはいえ Lighthouse が「より良い Web サイト」を作る上で1つの指標となるのは確かだし、ここに書いた修正項目は、いずれも納得感を持って修正を加えることができた。インフラよりの技術スタックを持っていると、この中で日頃気にしているのは Performance と Best Practices の一部項目ぐらいがメインだった。しかし UX という点では単に Origin からのレスポンスを早く返すだけではなく、 JS の読み込みといった部分も考慮するべきだし、画像も数が増えてくればより優れた配信方式を検討する必要が出てくる。こういった学びは今後に活かしていきたい。

Toil とは何であるのか

定義については Google のエンジニアが書いている2冊の書籍『SRE サイトリライアビリティエンジニアリング（以下、 SRE book）』『サイトリライアビリティワークブック（以下、 SRE workbook）』が原典にあたる。これらによれば、 Toil は一言でこう、と言えるものではなく、以下のように複合的な性質を持つタスクのことを呼んでいる。

• 手作業であること
• 繰り返されること
• 自動化できること
• 戦術的であること
• 長期的な価値を持たないこと
• サービスの成長に対してO(n)であること

難しいのは、これらが AND 条件でもなければ OR 条件でもないということだ。 SRE book の5章から引く。

トイルと見なされるすべてのタスクが、必ずしもこれらの性格をすべて備えているわけではありませんが、以下の説明の1つ以上に当てはまるような仕事であれば、その仕事のトイルの度合いは高いと言えるでしょう。

つまるところ、これらは Toil であるか否かを判別する絶対的な条件というより、 Toil の持つ傾向、性格を表した言葉と考えたほうがいいだろう。 Toil と呼ばれるタスクが、結果的にこういった性格を備えている「場合がある」ということであり、その逆 = こういう性格を備えたタスクが Toil である、とは必ずしも成り立たない。

それを踏まえた上で、改めて Toil をどう定義するかだが、先の6つの性格より、同じく SRE book 5章における以下の記述がより本質を表している。

私たちがこの50%のゴールを共有するのは、トイルというものは、確認しないままにしておけば拡大し、急速に全員の時間の100%を埋め尽くしてしまう傾向があるためです。トイルを減らし、サービスをスケールさせる作業が、サイトリライアビリティエンジニアリングにおける「エンジニアリング」です。エンジニアリングの作業によって、SREの組織の規模はサービスのサイズに比例しなくなり、純粋な開発チームや運用チームに比べて、より効率的にサービスを管理できるようになるのです。

サービス（ここで言う「サービス」はプロダクトの意味というよりは、マイクロサービス的な文脈と捉えている）が拡大、もしくは数を増やしていくとき、比例的に増大して人的リソースを消費するものが Toil である。この側面から捉えたほうが Toil を考えやすいのではないだろうか。例えば、プログラムにより自動化されているタスクであっても、サービスが増えたときにプログラムの改修が常に必要なようでは、運用負荷の高い Toil に成り得る。ソフトウェア開発において、プログラマーはコードのエントロピー増大に向き合うことを求められるが、それと同じ事をソフトウェアやサービスを取り巻くあらゆるタスクに敷衍したのが Toil の考え方だと捉えている。

Toil とは何ではないのか

Toil とは何であるのかをさらに深掘りするべく、傍証として、逆に Toil は何では「ない」のかをいくつか挙げてみたい。

Toil とは運用作業全般のことではない

つまるところ Toil ＝ 運用作業（ここでは、ローンチ後のサービスを保守、維持するためのタスクを「運用作業」と呼ぶことにする）のことだと言いたくもなる。これについては若干判断が難しいところがあって、というのも SRE book と SRE workbook で若干言っていることが違うのだ。

GoogleのSREの組織では、運用作業（つまりはトイル）を、各人の作業時間の50％以下にするという目標が掲げられています。 （SRE book 5章 トイルの撲滅）

Google は、 SRE チームが運用作業（これにはトイル中心の作業もそうでない作業も含まれます）に費やす時間を50%に制限しています （SRE workbook 6章 トイルの撲滅）

SRE book では両者をほぼイコールのように書いているが、 workbook では、運用作業には「Toil 中心ではない作業」も含まれると書かれている。「中心ではない」というだけで、結局は Toil なのかもしれないが、 SRE book とは書きっぷりが明らかに違う。

僕としては運用作業 ≠ Toil だと捉えている。例えば年に1回程度発生するが、自動化にはそれなりに工数が必要そうな運用作業があったとして、これは Toil だろうか。「繰り返される」という条件には当てはまるが頻度が低いし、「自動化が可能」ではあるものの、工数的にベネフィットがそれほど得られるかはわからない。であるならば、これは運用作業ではあるが、 Toil には分類されない、と考えることもできるのではないか。

あるいは、こういった厳密な Toil / not Toil の仕分けを行うほうが手間でもあるし、 Toil は根こそぎ洗い出して消滅させなければならないものでもないので、あえて運用作業全体をざっくり Toil と扱ってしまうのも手かもしれない。その中でより Toil としての性格が強いものもあれば、そうではないものもあるわけだが、より性格の強いものや、作業時間を圧迫しているものから削減を図っていけば、運用上の支障はなさそうだ。

トイルとは「つまらない作業」のことではない

これは SRE book 5章に、明確に「No」であると書かれている。

トイルは、単なる「やりたくない仕事」ではありません。 つまらない仕事には、長期的な価値があることもあります。そうであれば、それもトイルではありません。

運用作業にはつまらないもの、大変なものも少なくない。しかし、長期的に価値があるのであれば、それは Toil = 削減対象ではなく、きちんと向き合うべきだというのが SRE book の主張だ。思いつくものとしては、ゼロデイや脆弱性への対応などだろうか。まぁ「つまらない」は主観でしかないので、個人差が大いにあるところだが。

とはいえ、つまらない作業は誰だってやりたくないし、なるべくなら減らしたいと考えるのが自然だろう。その関連で少し触れたいのだが、都内に NoOps Meetup という勉強会がある。

https://www.publickey1.jp/blog/18/noopsnoopsnoops_meetup_tokyo_1.html

名前だけ聞くとかなり過激というか、思い切ったことのようにも聞こえるが、実際には「No Uncomfortable Ops」を掲げており、システム運用作業における「嬉しくない」ことを削減することを目的としている。これは単に「やっていて嬉しくない」というだけではなく、障害のようなユーザーにとっての「嬉しくない」こと、コスト的に「嬉しくない」ことも含まれる。

SRE book では、 Toil を削減するべき理由として、士気の低下を招くということも書かれている。長期的な価値のある作業であれば、徒労感も薄くて士気は下がりにくいと言いたいのだろうが、それは人によると言わざるを得ないし、「やりたくない」ことを減らそう、なるべく自動化しようというのはモチベーションとしてわかりやすい。つまらない作業 = Toil ではないのだが、つまらないことに忙殺されているか、敏感になる必要はありそうだ。

結局のところトイルとは何か

そもそも、自分がなぜ Toil の定義にこだわっていたのかと言えば、定義できないものは見つけようがないからだ。SRE として Toil の抑制を図りたいならば、 Toil を見つけなくてはならない。 Toil を見つけるには、 Toil とは何であるのかを定義しなくてはならない。しかし、ここまで見てきたとおり、 Toil とは XXX である、と一言で言い表せるようなものではない。似た性格を持つ単語はいくらか挙げられるが、厳密な定義を考えていくと、それらとイコールで結ぶことはできなくなる。

結論としては、 Toil が何であるか厳密な定義は必要ないと考えている。「 Toil を減らしたい」という言い方をすると、「ではまず Toil なるものを屏風から出してください」という気分になってしまうのだが、どちらかと言えば「 Toil 的なもの」を減らす、ぐらいの心構えでいいのではないか。目的は Toil を厳密に見つけていくことではなく、サービス拡大を妨げるような運用コストの増大を抑制することにある。この目的にさえフォーカスできていればいいのではないか。

SRE の原則に沿ったトイルの洗い出しとトラッキング | Google Cloud Blog においては、 Toil の洗い出しの一環として、チームメンバーへのアンケート調査を勧めている。

どのくらいの時間をトイルに費やしましたか。全体に占めるおおよその割合を、過去 4 週間の平均値でお答えください。

トイルに費やした時間の長さについてどの程度満足していますか。

文面に書かれているとおり、あくまで訊かれているのは「おおよその割合」である。ここで重視されているのは客観的に定義できる Toil の量ではなく、メンバーの主観に基づく負担量やストレス、認知的過負荷といった部分だ。SRE book 『5.4 トイルは常に悪なのか？』でも言及されている通り、簡単なタスクでささやかな達成感を生んでくれるような肯定的な側面も Toil にはある。重要なのは Toil が存在すること自体より、それが無秩序に増大することによる士気の低下のほうだ。

サービスの増加、トラフィックの増大によって増えてしまう運用コストを抑制し、無闇に人員を増やすことなく、安定的なサービスのスケールを行うことが SRE には求められている。SRE にとってもう1つの大きな役割であるSLOとエラーバジェットの管理も、同じ目的に沿うものと言えるわけで、つまるところ SRE とは、サービスの安定的なスケールを、ソフトウェアエンジニアリングによって支援していくことをミッションとした職種なのだと考えている。

• export が現状できないっぽい
• 検索機能がない
• こういう用途で使っているのが自分ぐらいしかいなさそう

Zenn Scraps に読んだ記事をまとめ始めた発端は、何かウェブ記事を読んでも、どこにも記録せず霧散してしまうということが少なくなかったからで、定量的な記録として始めていた。実際のところ、読んだ記事すべてを適当に放置していたわけではなく、すぐに活用できそうなものは Scrapbox にまとめている。すぐには活用できないけど、取りあえず頭の片隅に置いておきたい、いつか使えそう、みたいな記事が記録されず「霧散」していたのが課題であり、それを記録する場が欲しかったわけなので、後からログを簡単に辿ったり、検索できたりすることは結構必須の要件だった。それができないとなると利用は難しいかな、という結論になった。

また、どうも Scraps をこういう風に使っている人が他にはいなさそうというのも気にかかった。気にしなくていいのかもしれないとは思う。ただ、Zenn はすべての記事を投稿順にチェックできる UI があり、更新するとそのトップに一時的であれ掲載されることになるので、他の人の目に入る機会がなくはない。それを考えると、あまりに自己本位の目的で、こういうパブリックなコミュニティサイトを使うのはちょっと良くないかもな、と考えるに至った（自分の感傷の問題なので、 Zenn の在り方を問うつもりはないです）。

UX 、使い勝手の面ではかなり気に入っていたので残念ではある。特に Scraps はスレッド型になっているので、あるウェブ記事に関して、補足情報を「レス」の形で追記していけたのがとても体験が良かった。

そして移行先としては notion を使ってみることにした。

https://www.notion.so/Journal-5a988ea052794b88b84d5d06e3b9d6e8

読んだものを記録する習慣を付けるならば、 GUI でサッと書ける場所がいい。検索したい。エクスポートもできるといい。そしてコミュニティサイトを間借りするのではなく、自分専用のスペースの方が気が楽、などというあたりを満たすのが notion かな、という結論。

自分専用の場になったので、技術的なことだけを書かなくてはならないわけでもなくなり、広く日誌のような使い方をしてみようと考えている。 yuuk1/logbook にインスパイアされた面も小さくない。こんな研究日誌は僕には書けないけれども。今のところは読んでいた本の記録と、 journal のトップページに貼ってある Pixela のグラフは、ポモドーロの実行回数を示している（ホットキーを押すとポモドーロタイマーが起動しつつ、 Pixela に webhook を送るような環境を整えている）。自分のコンディションを概観できる場として使っていきたい。

jounarl.chroju.dev みたいなカスタムドメイン振れると嬉しいな、というのも考えたけれど、今のところスマートに実装する方法がなさそうだし、そこまでちゃんとパブリックにしたい場所でもないので見送っている。 Super という、外部公開した Notion page にカスタムドメインや CDN を付与してくれるサービスがあるらしいが、基本有料なのでステイ。

またしばらくこれで続けてみようと思う。

なので意識的に input 増やそうと思い立ち、となると input した数をちゃんと計測して KPI として計れるようにしたいなという発想に至り、そのための手段をいろいろ考えた結果、 Zenn の Scraps を当座使ってみようということにしてみた。

Zenn についてはだいぶ話題になったのでご存知の方も多いでしょうが、IT系エンジニアのための情報共有コミュニティ。ザッと見たところ「IT系」という明記がなく、単に「エンジニア」と書かれているので、もしかしたら「IT系」じゃなくてもエンジニアリングの話であれば書いて良いのかもしれない。どうなんだろう。で、ここにいわゆるブログのようなまとまった記事を上げる以外に、 Scraps という機能がある。

スクラップは、スレッド形式で知見やメモをまとめていく機能です。最初にテーマを決めてスクラップを作成したら、あとは自分の好きな単位で、好きなときに情報を足していきます。

何か調べものをするときとか、手元でメモしながら進めていくことがよくあるけど、それをパブリックにできるイメージ。 「書く」のは特別な道具 - naoyaのはてなダイアリー という話が好きで、僕もよくアウトライナーなんかに書き下しながら考えをまとめたり、何か調べたりすることはよくやっているんだけど、それを公開して誰でも見られるようにする、というのは結構面白いな、と思う。内容は右往左往しているようなものになるので、直接的にそれが他人に「役立つ」ものになるかはわからないけど、他人の scrap を読むと他人の思考を追跡できそうな気がする。

で、ここに読んだ記事を週単位でまとめることを始めてみた。

https://zenn.dev/chroju/scraps/2cf62108a159be

こういう感じ。読んだ記事をペタッと貼り付けて、はてブや Twitter の感覚で適当に感想を何かしら書き殴る。あくまで自分用のつもりで書いているので、他人にわかりやすいかどうかは気にしないことにしている。

もちろん、はてブや Twitter でも出来ることではあるのだが、いずれも字数制限が煩わしいし、一度開くと無限に時間を吸い取られる類いのものだからあまり開きたくなかったりもする。 Zenn Scraps なら字数制限はないし、スレッド形式なので、後から追記したいことやさらなる気付きがあれば、「レス」の形で付け足せるのもいい。週単位で Scraps を閉じていけば、 input 量の定量化もわかりやすくなる。

難点としては「このページに辿り着くまでが面倒」というのはある。 Twitter であれば常に1つのパーマリンクを開けばすぐ書き込めるけど、週単位で Scraps を作ると常にリンクが変わってしまうし、 Zenn のトップからわざわざ辿るのも面倒。今は Vivaldi のウェブパネルという、よく訪問するサイトをサイドパネルに常駐させる機能を使って、すぐ開けるようにしている。毎週、これを新しいページのリンクへ更新していくということになる。

まだ始めたばかりで、今後どうなるかはわからないが、わりとイイ感じに work しそうな気はしている。

追記

続き→ 読んだ記事などを「週報」として notion にまとめ始めた - chroju.dev/blog

詳細な背景や使い方は Module Testing Experiment - Configuration Language - Terraform by HashiCorp に記載されている。これを参考に自分でも test コマンドを試してみたので、その手順と雑感をまとめてみたい。

terraform test の動作仕様

まず、 terraform test がどのように動作するのか簡単にまとめる。

このコマンドは module の root で実行する。テストはスクリプトなどではなく、純粋な Terraform の設定（HCL）で記述し、 module root からの相対パスで ./tests/ 配下にサブディレクトリを作って、その中にファイルを置く形となる。 ./tests/ 配下には複数のディレクトリを置くことができ、そのすべてがテスト対象として認識される。 module に渡す引数ごとに複数テストパターンを行いたい場合などに、複数ディレクトリを設けることになる。

テストファイル設置後、 terraform test を実行すると、各 ./test/* ディレクトリ内の Terraform ファイルに対して、以下が実行される。

1. terraform validate
2. terraform apply
3. 定義されたテストの実行
4. terraform destroy

module を使って実際にリソースを構築し、その設定が意図したものになっているかテストした上で、構築した全リソースを削除するまでが一連の流れとなる。

検証

test 検証用 module の作成

今回、 terraform test を検証するにあたり、以下の module を使用した。AWS S3 バケットを作成して、その中にオブジェクトを保存し、ウェブサイトとして公開するものとしている。

aws_s3_bucket.this で使用している policy.json.tpl の記述内容や、 provider 定義については、ここでは割愛する。

variable "bucket_name" {
  type = string
}

variable "bucket_objects" {
  type = map(object({
    object_key   = string
    filepath     = string
    content_type = string
  }))
}

resource "aws_s3_bucket" "this" {
  bucket        = var.bucket_name
  acl           = "public-read"
  policy        = templatefile("${path.module}/policy.json.tpl", { bucket_name = var.bucket_name })
  force_destroy = true

  website {
    index_document = "index.html"
  }
}

resource "aws_s3_bucket_object" "objects" {
  for_each = var.bucket_objects

  bucket       = var.bucket_name
  key          = each.value.object_key
  source       = each.value.filepath
  content_type = each.value.content_type

  etag = filemd5(each.value.filepath)

  depends_on = [
    aws_s3_bucket.this,
  ]
}

test の作成

module を用意したら、その中に ./tests/sample ディレクトリを作成してテストファイルを作成していく。先述の通り、書き方は普通の Terraform とあまり変わりはない。

まず provider 定義だが、ここで builtin の test provider を読み込む必要がある。

terraform {
  required_providers {
    test = {
      source = "terraform.io/builtin/test"
    }
    aws = {
      source  = "hashicorp/aws"
      version = ">= 3.0.0"
    }
  }
}

これで test 用の resource が使えるようになる。

続いて実際の設定を書いていくが、 module を読み込んでリソース構築するところまでは通常通り書いていく。今回、引数として渡す S3 のバケット名は、AWS の仕様上毎回ユニークなものでなければならないため、 random_string を使ってランダムなサフィックスを付加している。また S3 バケットに配置するオブジェクトは ./tests/sample/static 配下に html と JSON の2つを用意しておいた。

resource "random_string" "suffix" {
  length  = 8
  special = false
  upper   = false
  number  = false
}

locals {
  bucket_name = "chroju-terraform-test-${random_string.suffix.result}"
}

module "s3_website" {
  source = "../.."
  depends_on = [
    random_string.suffix,
  ]

  bucket_name = local.bucket_name
  bucket_objects = {
    index_html = {
      object_key   = "index.html"
      filepath     = "${path.module}/static/index.html"
      content_type = "text/html"
    }
    avater_jpg = {
      object_key   = "test.json"
      filepath     = "${path.module}/static/test.json"
      content_type = "application/json"
    }
  }
}

ここからテスト本体を書いていく。テストには先の test provider が提供する、 test_assertions resource を用いる。

data "aws_s3_bucket" "this" {
  bucket = module.s3_website.bucket_id
}

resource "test_assertions" "s3_bucket" {
  component = "s3_bucket"

  equal "bucket_id" {
    description = "bucket id is valid"
    got         = data.aws_s3_bucket.this.id
    want        = local.bucket_name
  }

  check "website_endpoint" {
    description = "website endpoint is not empty"
    condition   = data.aws_s3_bucket.this.website_endpoint != ""
  }
}

test_assertions 内で書けるテストには2種類ある。1つが equal block であり、構築したリソースから得た値を got 、その値の期待値を want に指定して、両者が文字列として一致していればテスト成功となる。ここでは data.aws_s3_bucket によって、構築した S3 バケットの設定を読み出し、その ID が指定したバケット名と一致することを確認している。

もう1つが check block。 condition に bool 値を返す任意の式や function を記述し、その評価結果が true であればテスト成功となる。 Terraform 0.13 で追加された Custom Variable Validation と、仕組みとしては同じだ。上記のサンプルでは、 S3 バケットの website_endpoint という attribute が空文字列ではないことを確認している。この attribute は、 S3 がウェブサイトホスティング設定になっているときのみ、エンドポイントのドメインが設定されるので、それを確認することでテストとしている。

data "http" "json_access" {
  depends_on = [
    test_assertions.s3_bucket,
  ]
  url = "http://${data.aws_s3_bucket.this.website_endpoint}/test.json"
}

resource "test_assertions" "json_access" {
  component = "json_access"

  equal "response_content_type" {
    description = "content type is valid"
    got         = data.http.json_access.response_headers["Content-Type"]
    want        = "application/json"
  }
}

さらにテストを書いてみる。今回の module の目的は S3 バケットを使ってウェブサイトを公開することなので、 HTTP provider を使って、実際に HTTP でアクセスできるのかまで確認をしてみた。

data.http.json_access には depends_on を設定し、先の S3 バケット自体のテストが終了後にこちらのテストを実行するようにした。これは、バケット作成が未完了の状態では、 HTTP アクセスもできないためだ。 depends_on によって、実行するテストの順序もこのようにある程度コントロールできる。実際のテストでは、アクセスした際の Content-Type が、 application/json になっていることを確認する内容とした。

test コマンドの実行

テストを書き終えたら、 module root に戻り、 terraform test コマンドを実行する。実際にリソース構築が実行されるので、環境変数などで対象 provider 向けの API キーなどの設定もあらかじめ必要になる。

無事にすべてのテストが通れば、緑の文字で Success! と表示される。

失敗したときは、以下のようにその詳細が表示される。ここでは最後の HTTP アクセス時のテストで、期待する値をあえて text/html と誤った値に設定してみた。

現時点での課題や懸念

terraform test は experimental な段階にあり、まだ安定的に動作するものではない。また、僕が行った検証は上記のもののみであって、これから書くことが一般性のある内容かは保証しないとあらかじめ断っておく。

なお experimental 段階だからか、フィードバックがあれば HashiCrop Disucuss のほうに寄せてほしいとのこと。

設定不備のデバッグが困難

設定不備により、 terraform apply 自体が失敗したり、テストがうまく動作しないこともあるが、現状ではその場合でも Failed to clean up after tests というメッセージが出力されるため、失敗の原因を掴みにくくなっている。

以下の出力は、先の検証の際に、バケット名をあえて重複した値に設定してみて、 apply をわざと失敗させたときのもの。スクショでは省略したが、実際には定義した各リソースすべてについて Failed to ... のメッセージが表示される。

destroy 失敗するとリカバリーが大変

terraform test では state を作成せずに apply / destroy を行うため、何らかの原因で destroy が失敗した場合は、作成したリソースを手動削除しなければならず、リカバリーが大変なことになる。あらかじめ手で apply / destroy だけは実行してみて、問題なく通ることは確認しておいたほうがいいかもしれない。

また、通常 terraform destroy ではリソース間の依存関係を鑑みて削除処理が行われるが、 test ではそれが上手く動いていない可能性を若干疑っている。先の検証中、 aws_s3_bucket_object と aws_s3_object には depends_on であえて依存関係を明記しているが、バケット削除が先に試みられ、エラーとなることがあったからだ。この点はもう少し確認して、バグのようなら報告しておきたい。

構築に時間がかかる場合

今回の検証対象は S3 バケットだったため、テストの実行は1分程度で完了しているが、 AWS EKS Cluster など、構築完了まで10〜数十分を要するものが対象だと実行の難易度が上がる。 CI に組み込んだりすれば、時間的にも金銭的にもかなりのコストになるだろう。

将来的なテストダブルの実装可能性には触れられているので、それを期待したい。

Conclusion

Kief Morris『Infrastructure as Code』 では、11章にて IaC のテストについてまとめられている。

ここでは「反射的テスト」と名付けて、何らかの構成定義をただ言い換えただけのテストを書くことをアンチパターンとしている。今回の検証で言えば、 S3 バケット名の確認テストがそれにあたるだろう。この種のテストは書いていても切りがないし、要するところ「Terraform が正しく動いているか」というツールの信用性を試すだけのものになってしまう。

では何をテストすれば良いのかについては、以下のように書かれている。

原則として、テストを書くのは、チェックしたいと思っているロジックにある程度複雑さが含まれている場合だけにすべきだ。（Kief Morris 著. 宮下剛輔 監訳. 長尾高弘 訳. Infrastructure as Code. 初版, オライリー・ジャパン, 2017, p.207）

確かに Terraform module は内部で Terraform Function や dynamic block を用いて複雑化している場合も多く、そういったところを中心に分岐網羅、条件網羅的にテストを書いていくのがベターな方法になるのかもしれない。また今回 HTTP provider を活用したように、直接構築されるリソース以外で副次的にもたらされる価値があれば、それについてもテストをしておきたい。 HTTP Provider 以外にも、すでに Terraform に存在している、数々の data を上手く活用できるんじゃないだろうか。

Terraform にテスト機能が内包されることで、より module 開発はやりやすくなりそうだと感じたし、 test コマンドの本実装には肯定的な気持ちでいる。

{"items": [
    {
        "uid": "desktop",
        "type": "file",
        "title": "Desktop",
        "subtitle": "~/Desktop",
        "arg": "~/Desktop",
        "autocomplete": "Desktop",
        "icon": {
            "type": "fileicon",
            "path": "~/Desktop"
        }
    }
]}

Alfred での検索画面というと下図の形でお馴染みだと思うが、これで言えばインクリメンタル検索の対象となる白い大きな文字が title 、その下に薄い文字色で書かれているのが subtitle になる。また、これら検索候補のいずれかを選択すると、それに応じて「ファイルを開く」「URLを開く」といったアクションに連携されるわけだが、そのアクションに引き渡す URL やファイルパスにあたるのが arg だ。

Alfred をきちんと使うのであれば、こういった各項目を設定していく必要が出るが、時に複数行文字列を渡せばイイ感じに検索させてほしいなと思うときがある。となると bash でシュッとスクリプトを書きたくなるのだが、 JSON の生成をシェルスクリプトで扱うのはかなり難しい。そこで、複数行文字列を渡せばざっくりと Alfred JSON Format に変換してくれるツールを作った。

https://github.com/chroju/alfrednize

例えばローカルで Git レポジトリ管理を行うツールである x-motemen/ghq と組み合わせてみると、以下のような出力を得られる。

$ ghq list | head -n 5
github.com/chroju/og-image
github.com/chroju/dotfiles
github.com/chroju/parade
github.com/miiton/Cica
github.com/chroju/homebrew-tap

$ ghq list | alfrednize | jq | head -n 18
{
  "items": [
    {
      "uid": "github.com/chroju/og-image",
      "title": "github.com/chroju/og-image",
      "subtitle": "",
      "arg": "github.com/chroju/og-image",
      "match": "github.com/chroju/og-image",
      "autocomplete": "github.com/chroju/og-image"
    },
    {
      "uid": "github.com/chroju/dotfiles",
      "title": "github.com/chroju/dotfiles",
      "subtitle": "",
      "arg": "github.com/chroju/dotfiles",
      "match": "github.com/chroju/dotfiles",
      "autocomplete": "github.com/chroju/dotfiles"
    },

見てわかる通り、 JSON の中身は妥協の産物で、各項目すべて同じ内容になっている。細かいことは何もできなくていいので、複数行文字列から候補選択し、選択した文字列をそのまま次へ渡せれば OK 、というつもりで作っている。選択した文字列の加工が必要であれば、 bash でどうとでもできるだろう。

これを Alfred Workflow で設定すると、ローカルの Git レポジトリを検索するツールがシュッと完成する。あとは選択結果を code コマンドに渡せば VSCode で開けるし、あるいはブラウザで開かせてもいい。

複数行文字列を渡すだけで Alfred Workflow が使えるのは結構便利で、junegunn/fzf にかなり近い感覚で Alfred を扱えるようになる。 JSON 生成が必要であるがために、これまでは Workflow を作るだけで何かプログラミング言語を使うことがほぼ必須だったが、 alfrednize があれば bash だけで簡単に作れるようになったのもメリットとして大きい。先の例のように何かコマンドの実行結果を渡すのでもいいし、静的な検索であれば、何かをリストアップしたファイルを作ってシンプルに cat するだけでも使える。

先日、先の記事で書いた Parade というツールのリファクタリングを通じて、 cobra を testable に使う方法を模索したので、それについて書いてみる。

example に基づいた cobra の利用

まず、何が問題なのかを明らかにするために、 cobra v1.1.3 のドキュメント記載の example を参考にコードを書いてみる。

package cmd

import (
	"fmt"
	"os"

	"github.com/spf13/cobra"
)

var (
	// Used for flags.
	userLicense string

	rootCmd = &cobra.Command{
		Use:   "cobra",
		Short: "A generator for Cobra based Applications",
		Long: `Cobra is a CLI library for Go that empowers applications.
This application is a tool to generate the needed files
to quickly create a Cobra application.`,
	}

    tryCmd = &cobra.Command{
        Use:   "try",
        Short: "Try and possibly fail at something",
        RunE: func(cmd *cobra.Command, args []string) error {
            if err := someFunc(); err != nil {
                return err
            }
            fmt.Println(args[0])
            return nil
        },
    }
)

// Execute executes the root command.
func Execute() error {
	return rootCmd.Execute()
}

func init() {
	cobra.OnInitialize(initConfig)

	rootCmd.PersistentFlags().StringP("author", "a", "YOUR NAME", "author name for copyright attribution")
	rootCmd.PersistentFlags().StringVarP(&userLicense, "license", "l", "", "name of license for the project")

	rootCmd.AddCommand(tryCmd)
}

cobra はサブコマンドのある CLI が念頭に置かれている。15行目の rootCmd がサブコマンド無しの状態のコマンドであり、ここに23行目で &cobra.Command として定義した tryCmd を、51行目で AddCommand() することにより、サブコマンドを追加している。サブコマンドである tryCmd が呼ばれた際に実行される処理は、26行目の &cobra.Command{}.RunE に渡された関数が担っている。

example に基づくとこのような実装になるわけだが、パッと見ただけでもいくつか改善したいポイントが出てくる。

• 26行目、 tryCmd の処理が無名関数であり、テストしづらい
• 30行目、関数の出力処理が fmt.Println で行われており、出力内容のテストがしづらい
• 13、45行目、 rootCmd のコマンドフラグがグローバル変数で管理されている
• 同様に、各コマンドもグローバル変数となっている

以下、順に見て行きながら改修していく。

コマンドの実行に無名関数を使うのをやめる

26行目からの無名関数内でサブコマンドの処理を実行しているが、このままではテストなどを行う場合に扱いづらいので、これをまず改修する。処理を実行する部分は別の関数に分離して、無名関数内から呼び出す形を取ってみる。

var {
    tryCmd = &cobra.Command{
        Use:   "try",
        Short: "Try and possibly fail at something",
        RunE: func(cmd *cobra.Command, args []string) error {
            if len(args) != 1 {
                return fmt.Errorf("expected 1 arg.")
            }
            return try(args[0])
        },
    }
}

func try(value string) error {
    if err := someFunc(); err != nil {
        return err
    }

    fmt.println(value)
    return nil
}

引数の validation などの処理は呼び出し関数である tryCmd のほうに寄せて、 try() は実処理だけを担うようにしたことで、これだけでもだいぶ見通しがよくなった。実処理に必要な引数も、 args []string という曖昧なものではなく、 string 型1個だということがこれで明示できる。

出力処理に fmt.Println() を使わない

さらに、改善ポイントの2つ目に上げた、「出力内容のテストがしづらい」という問題もこれで改善の余地が出た。 try() に引数を自由に設定できるようになったので、 io.Writer を受け取るようにすればよい。これにより、テストの際には &bytes.Buffer{} を生成して try() に渡すことで、出力をかすめ取ることができるようになる。

var {
    tryCmd = &cobra.Command{
        Use:   "try",
        Short: "Try and possibly fail at something",
        RunE: func(cmd *cobra.Command, args []string) error {
            if len(args) != 1 {
                return fmt.Errorf("expected 1 arg.")
            }

            out := os.Stdout
            errOut := os.Stderr
            return try(args[0], out, errOut)
        },
    }
}

func try(value string, out, errOut io.Writer) error {
    if err := someFunc(); err != nil {
        return err
    }

    fmt.Fprintln(out, value)
    return nil
}

ちなみに、自分の場合はサブコマンドの引数が長くなる場合もあったので、各コマンドの引数を構造体でまとめるようにしている。ここはお好みで。

type tryOption struct {
    Value  string
    Out    io.Writer
    ErrOut io.Writer
}

func try(o *tryOption) error {
    if err := someFunc(); err != nil {
        return err
    }

    fmt.Fprintln(o.Out, o.Value)
    return nil
}

グローバル変数をやめる

続いてグローバル変数をやめたい。まず、 rootCmd と tryCmd については関数で生成するようにする。 tryCmd について書くと、以下のようになる。

func newTryCmd() *cobra.Command {
    cmd := &cobra.Command{
        Use:   "try",
        Short: "Try and possibly fail at something",
        RunE: func(cmd *cobra.Command, args []string) error {
            if len(args) != 1 {
                return fmt.Errorf("expected 1 arg.")
            }

            out := os.Stdout
            errOut := os.Stderr
            return try(args[0], out, errOut)
        },
    }
    return cmd
}

func init() {
    rootCmd.AddCommand(newTryCmd())
}

rootCmd も同様に newRootCmd() 関数で生成する。これにより関数の中で *cobra.Command を操作可能になったので、最初のサンプルでは init() の中で func (c *cobra.Command) PersistentFlags() で行っていた Flag の付与や、同 AddCommand() によるサブコマンドの設定処理も一緒にまかなえるようになった。

func newRootCmd() (*cobra.Command, error) {
    var userLicense string

	cmd := &cobra.Command{
		Use:   "cobra",
		Short: "A generator for Cobra based Applications",
		Long: `Cobra is a CLI library for Go that empowers applications.
This application is a tool to generate the needed files
to quickly create a Cobra application.`,
	}
	cmd.PersistentFlags().StringP("author", "a", "YOUR NAME", "author name for copyright attribution")
	cmd.PersistentFlags().StringVarP(&userLicense, "license", "l", "", "name of license for the project")

	cmd.AddCommand(
		newTryCmd(),
	)

	return cmd, nil
}

tryCmd のときと同様、 rootCmd についても出力先は io.Writer を引数で与えるようにする。newTryCmd にも io.Writer の引数を追加すれば、 rootCmd に渡した io.Writer をサブコマンドへと伝播させる形が実現できる。

さらに、 *cobra.Command の func (c *Command) SetOut() と、同 SetErr() にも io.Writer を渡す。これらは *cobra.Command 自身が出力する、 Usage やエラーメッセージの出力先になる。

func newRootCmd(outWriter, errWriter io.Writer) (*cobra.Command, error) {
    var userLicense string

	cmd := &cobra.Command{
		Use:   "cobra",
		Short: "A generator for Cobra based Applications",
		Long: `Cobra is a CLI library for Go that empowers applications.
This application is a tool to generate the needed files
to quickly create a Cobra application.`,
	}
	cmd.PersistentFlags().StringP("author", "a", "YOUR NAME", "author name for copyright attribution")
	cmd.PersistentFlags().StringVarP(&userLicense, "license", "l", "", "name of license for the project")

	cmd.AddCommand(
		newTryCmd(outWriter, errWriter),
	)
	cmd.SetOut(outWriter)
	cmd.SetErr(errWriter)

	return cmd, nil
}

func Execute() error {
	o := os.Stdout
	e := os.Stderr

	rootCmd, err := NewRootCmd(o, e)
	if err != nil {
		return err
	}
	return rootCmd.Execute()
}

Conclusion

以上を踏まえると、最終形は以下のような形になる。

type tryOption struct {
    Value  string
    Out    io.Writer
    ErrOut io.Writer
}

func newTryCmd(out, errOut io.Writer) *cobra.Command {
    o := &tryOption{}
    cmd := &cobra.Command{
        Use:   "try",
        Short: "Try and possibly fail at something",
        RunE: func(cmd *cobra.Command, args []string) error {
            if len(args) != 1 {
                return fmt.Errorf("expected 1 arg.")
            }

            o.Out = out
            o.ErrOut = errOut
            return try(o)
        },
    }
    return cmd
}

func try(o *tryOption) error {
    if err := someFunc(); err != nil {
        return err
    }

    fmt.Fprintln(o.Out, o.Value)
    return nil
}

func newRootCmd(out, errOut io.Writer) (*cobra.Command, error) {
    var userLicense string

	cmd := &cobra.Command{
		Use:   "cobra",
		Short: "A generator for Cobra based Applications",
		Long: `Cobra is a CLI library for Go that empowers applications.
This application is a tool to generate the needed files
to quickly create a Cobra application.`,
	}
	cmd.PersistentFlags().StringP("author", "a", "YOUR NAME", "author name for copyright attribution")
	cmd.PersistentFlags().StringVarP(&userLicense, "license", "l", "", "name of license for the project")

	cmd.AddCommand(
		newTryCmd(out, errOut),
	)
	cmd.SetOut(out)
	cmd.SetErr(errOut)

	return cmd, nil
}

func Execute() error {
	o := os.Stdout
	e := os.Stderr

	rootCmd, err := NewRootCmd(o, e)
	if err != nil {
		return err
	}
	return rootCmd.Execute()
}

サブコマンドの生成を関数で行ったり、コマンドの出力先を io.Writer を渡すことでまかなったりするのは、いずれも mitchellh/cli では標準の機能であり、こちらを先に使っていたことで、 cobra も改修して使おうという発想に至れた。同じ目的に使える言語ライブラリが複数存在することはままあるが、それぞれの実装を比較してみると学べることは多いのだと実感した。実際改修にあたる際は、ここで書いたように「何を改善したいのか」というポイントを1つずつ解きほぐしていくと整理しやすい。

また冒頭にも書いた通り、 cobra は多くの著名なツールで使われているので、実例が豊富なのもポイントだと思う。 GitHub CLI の実装は特にここで書いたものと似た形になっており、とても参考になっている。

cli/status.go at 3ad41e3e651647236ed4ece290afb12dbdc924bf · cli/cli

従来から強力な api サブコマンドだったが、実行結果は当然ながら JSON などの形式になるので、結果を整形するには jq を通す必要があった。これが先日の 1.7.0 において、 jq のシンタックスを活用できる --jq オプションと、 Go template を活用できる --template オプションが実装されたことで、 gh コマンド単独であらゆる出力整形まで可能になった。

僕もコマンドラインツールをよく書くが、ある API を implement した CLI というのは、 API の発展に従って絶えず更新が必要だし、実行結果の出力形式をどうするかなかなか悩ましい部分も大きい。この api サブコマンドは、そういった問題を「ユーザーにぜんぶ編集可能とさせる」ことで根本的に解決している、発想の逆転がすばらしい。

いくつか僕の使っている alias の実例を挙げてみる。

watch の管理

GitHub の watch は、かねてより GUI が貧弱だ。うっかりレポジトリの多い Organization に入ると一斉に多数のレポジトリが watch 対象になるなど事故りやすいが、 GUI からでは watch 解除は「全部解除」か「1つずつ解除」のいずれかしかできず、複数の対象をチェックして解除するような操作ができない。

GitHub CLI で、 watch しているレポジトリ一覧の表示と、 watch 解除のコマンドを作ると、これがだいぶ楽になる。

$ gh alias set watches 'api /users/chroju/subscriptions --paginate --jq .[].full_name'

$ gh watches
chroju/dotfiles
chroju/todo.txt-cli
chroju/chef_web_server
...

$ gh alias set unwatch 'api -X DELETE /repos/$1/subscription'

$ gh unwatch chroju/dotfiles

あとは gh watches の結果をテキストファイルに書き出し、ファイルを開いて不要なレポジトリだけを残すよう編集し、そのファイルを cat して xargs gh unwatch していけば、一括で watch が解除できる。

gitignore の生成

GitHub API から、さまざまな言語の .gitignore の雛形を取得できる。これも alias にしておくと便利だ。

$ gh alias set gitignore 'api /gitignore/templates/$1 --jq .source'

$ gh gitignore Go
# Binaries for programs and plugins
*.exe
*.exe~
*.dll
*.so
*.dylib

# Test binary, built with `go test -c`
*.test

# Output of the go coverage tool, specifically when used with LiteIDE
*.out

# Dependency directories (remove the comment below to include it)
# vendor/

レポジトリの検索

「なんかああいう名前のレポジトリあったよな」という朧気な記憶からググったりすることがよくあるが、これもコマンドにする。

$ gh alias set search 'api -X GET search/repositories -f q="$1" --template "{{range .items}}{{.full_name}} ⭐ {{.stargazers_count | color \"yellow\"}} ({{.description}}){{\"\\n\"}}{{end}}"'

結果はこんな感じ。Go template を用いると、出力の色も変えられるのが嬉しい。

僕はレポジトリ名だけ出力するのが好きなのでそうしているが、 URL を表示するようにすれば、サクッとブラウザで開くこともできる。 fzf などを通してシュッと開けるようにしておくのもよさそう。

Atlantis の実行

Terraform の自動実行ツール Atlantis はプルリクエストベースで動作する仕組みになっており、 terraform apply を実行するには、 PR コメントに atlantis apply と書き込む必要がある。これもブラウザから書き込むのは面倒なのでコマンド化してしまう。

$ gh alias set atlantis-apply 'pr comment -b "atlantis apply"'

この alias だとカレントディレクトリ、カレントブランチの PR に対して apply が実行される、かなり簡易的な形式になっているが、より安全な形式にするならば、 PR number やレポジトリを引数に取らせてもいい。

他、ここでは取り上げていないが REST API だけではなく GraphQL API にも対応している。また gh 単体で完結しない操作であっても、 gh alias set --shell オプションを使えば、シェルコマンドを挟んだワンライナーまでも alias 登録ができる。なので本当になんでもありだ。

GitHub CLI の config をファイルで管理する

ここまで多くの設定ができるコマンドラインツールだと、 dotfile の考え方で、設定はファイル管理したくなる。現状、ドキュメントには記載がないが、 GitHub CLI の設定はデフォルトでは ~/.config/gh 配下に YAML で保存されている。なお、設定ファイルの保存先ディレクトリは、環境変数 GH_CONFIG_DIR で自由に設定することもできる。 (see: https://github.com/cli/cli/pull/2444)

ファイルは OAuth token などが書かれた hosts.yml 、 GitHub CLI のバージョン情報が書かれた state.yml 、そして alias などの設定が書かれた config.yml の3種類がある。前者2つは秘密情報や動的な値を含んでいるので、 config.yml だけ dotfile 管理すればいいだろう。

# What protocol to use when performing git operations. Supported values: ssh, https
git_protocol: ssh
# What editor gh should run when creating issues, pull requests, etc. If blank, will refer to environment.
editor:
# When to interactively prompt. This is a global config that cannot be overridden by hostname. Supported values: enabled, disabled
prompt: enabled
# A pager program to send command output to, e.g. "less". Set the value to "cat" to disable the pager.
pager:
# Aliases allow you to create nicknames for gh commands
aliases:
    watches: api /users/chroju/subscriptions --paginate --jq .[].full_name
    gitignore: api /gitignore/templates/$1 --jq .source
    unwatch: api -X DELETE /repos/$1/subscription
    search: api -X GET search/repositories -f q="$1" --template "{{range .items}}{{.full_name}} ⭐ {{.stargazers_count | color \"yellow\"}} ({{.description}}){{\"\\n\"}}{{end}}"

ウェブブラウザはつい脇道に逸れてしまったり、集中力を乱す要因になりがちなので、仕事中に触る機会は極力減らしたいと考えている。その上で GitHub CLI はかなり有意義なツールになりつつある。

単位修得状況

| 評価 | 2年次修得単位 | 3年次修得単位 | |:--:|:--:|:--:| | S | 8 | 2 | | A | 12 | 8 | | B | 4 | 4 | | C | 0 | 4 | | 合計 | 24 | 18 |

いやぁ、鈍化鈍化って感じがしますね。ただ昨年はスクーリング科目（週末2〜3日間通学し、集中的に講義を受けて単位を取得する科目）を6単位取っているので、自宅学習のペースとしては変わらずと言っていいのかもしれない。ダメかもしれない。

コロナ禍で家にいる時間が増えたのだから、大学に費やせる時間も増えてよさそうなものだけど、まぁいろいろもろもろで実際のところあまり増えなかった。これは後述。

残り50単位。頑張ればギリギリあと2年でイケそうだが無理をしなければ3年か、というところ。

コロナ禍と通信大学生

通学機会の消失

2020年度はコロナ禍により、大学生がかなり影響を受けたことは報道でも周知の通り。小中高校が対面授業を再開するなか、なぜ大学だけがオンライン授業を続けるのかという怨嗟の声もよく聞こえた。

通信課程はあまり影響なかったんじゃないかと思われそうだが、多少の影響はあった。スクーリングや科目修得試験など、年に何回かはキャンパスへ赴く機会もあるのだが、それらはすべてオンラインに切り替えられ、今年度は一度もキャンパスへ足を踏み入れることがなかった。

とはいえ、試験については本人確認の手順などが変更になったぐらいで、単に受ける場所が変わるだけなのでそれほど大きな影響はない。スクーリングに関してはグループワークなどが設けられていることも多く、孤独に勉強する通信学生が唯一ほかの学生と交流できる機会だったので、オンライン化を残念に思う人も少なくなかったのではないかと思う（僕はスクーリング科目の必要単位は取り終えているので無関係）。なお、試験は黙して実施するものなので、「三密」には該当しないのではないかという気もするが、通信制は全国に学生が分散している関係上、試験開催により都市圏と郊外間の移動がそこそこ発生する。大学側の懸念はその点だったらしい。

僕としては、試験のときに大学へ行って、学食でごはんを食べたり、併設のイタトマでケーキ食べながら勉強したりする、ちょっとした楽しみを奪われたのが残念だったぐらいで、「大変な思いをした」という気持ちはない。

学習環境の変化（マイナス面）

個人的な話としては、学習環境が多少なり変化した。昨年からの変化で書くので、良ければ冒頭に載せた1年目の記事をあわせて見てほしい。

第一に図書館が使えなくなってしまった。特に予定がない休日は東京都立中央図書館で勉強させてもらっていたが、緊急事態宣言下では来館サービスを停止しており、それ以外の期間も予約や人数制限が入ったので、今年度は一度も利用していない。調査してレポートを書くような課題が今年度はなかったのでまだ良いものの、もしもそういった機会があれば少々面倒なことになりそう。また、家で勉強するより、場所を変えたほうが気分転換になるのは確かなので、以前よりやる気が出なかった日は少なくなかったな、と思う。

また、暗記が必要な科目については「通勤電車内で Anki を使う」という学習方法を取っていたが、通勤が消滅したのでこれもできなくなった。おかげで暗記の状態がちょっとよろしくないな、と感じる機会が増えた気はする。

もちろん、いずれも個人的な環境、習慣の話で、「新しい生活様式」下に適応すればよいという話ではある。それはそう、なのだが、急な環境変化にはどうにも振り回されてしまう。2021年度もおそらくこの調子が続くのだろうし、次はもう少し適応していきたいところ。

学習環境の変化（プラス面）

ちなみに、その他なにか著しくモチベーションが下がっただとか、そういったことはなく、淡々と学習は続けられている。大学の学習を続けること自体はこの2年でだいぶ習慣化できた。

またリモートワークになったことも大きい。今勤めている会社はコアタイムのないフレックス制なので、今は朝の「出勤」を遅らせて10時にして、起床からその時間までを大学の勉強、もしくは趣味の勉強に充てることにしている。毎日の生活リズムがほぼ固定できたことは非常に良かった。一方で自炊やらの機会が増えたり、先述した図書館や Anki の件があったりもしたので、結局学習時間の総量としてはトントンという感覚でいる。

学習の進め方（2年目）

これはあんまり昨年と変わっていないので、1年目の記事を見てもらいたい。小さいところで2つほど変化はあり、1つはすでに書いているとおり Anki を使わなくなってしまったこと。

もう1つは履修科目の管理方法。ついつい10年前の大学時代の習慣に引きずられるようで、去年はあの頃のようにスプレッドシートで愚直に管理していたんだけど、今更それもどうよと気付き、今年は Notion の Board View を使ってカンバン的に管理していた。

が、普段のメモには Scrapbox をメインとしていることもあり、どうも Notion を開く習慣ができず、頓挫した。大学のレポートや課題は GitHub の Private Repository で管理しているので、来年度はそこに GitHub Project のカンバンを作って対処しようと考えている。普段見るものに寄せるの大事。

受けて良かった授業

実際の授業受けてみてどうよ？って話、特に通信大学だとあんまり流れないよなぁというのを 放送大学マイルストーン（仮）｜lumpsucker｜note を見て思ったので自分もやってみる。「マイル」（元ネタは早稲田の「マイル」でしょう）名乗れる網羅性はなく、あくまで自分の受けた科目の中だけであり、また難易度などの記述はしていない。

ちなみに2年次に受けた科目はその旨を付記しているが、特に履修年次の制限はないので、何年次でも履修はできる。

オートマトンと計算理論

内容としては『アンダースタンディングコンピュテーション』に近い。以前から興味のある分野ではあったものの、自主学習となるとなかなか腰が重く、大学で改めてさらえたのは良い機会だった。僕らの根幹に位置するような分野と捉えている。

https://www.oreilly.co.jp//books/9784873116976/

情報理論

クロード・シャノンの『A mathematical theory of communication』をベースに、情報源符号化と通信路符号化について学んでいく科目。単に概念的な学習にとどまらず、例えば通信路符号化にあたっては、サンプリングの過程を実際にフーリエ変換を使って解いていくなど、歯ごたえがかなりあった。

コンピュータアーキテクチャ

コンピュータの物理構造を紐解いていくので、シラバスにも書いてあるが「教養」に近いかもしれない。基本情報処理技術者試験を受けた人であれば、あれのハードウェア関連の内容をさらに深化させたものと考えると近いかもしれない。制御装置、演算装置、記憶装置、それぞれの歴史的変遷や概念を追えるので純粋に面白いのだが、一方で覚えることもかなり多い。

数理統計学

社会科学の大学を出ているのでこの分野は一度学んでいるのだけど、改めて。正直コンピュータに直結するのかは「？」だけど、統計知識というのは生きていく上で常に必要なんじゃないかという感覚がある。データを見る、という機会はエンジニアとしてだけではなく、日常生活のなかでも多いし。

データベース論（2年次）

データベーススペシャリストは持っていないのだけど、この科目でかなり補充できたのではないかなと感じる。ただし、ほぼ RDBMS の話であり、 NoSQL などにはあまり対応していない。

グラフ理論（2年次）

巡回セールスマン問題、木構造、有限マルコフ連鎖、なんて単語が出てくる科目。受ける前はネットワーク分野と関連しそうだな、ぐらいの印象だったけど、複数のノードをどう繋ぐか、繋ぎ方のパターン、ノード間の移動パターンなどに関する理論は、情報科学分野の様々な場面で必要になることがわかって非常に興味深かった。

技術者倫理（2年次）

シラバスの言葉を借りると、「技術者はいかにあるべきか」についての内容。実際の科学技術発展に伴う社会問題、倫理的課題などに触れながら、われわれ技術者にはどのような倫理観、社会的責任が求められるのかを追っていく科目。

個人的にはこういう科目を学べるのが大学の醍醐味のように感じる。本を読んだり、ウェブで検索したりして技術知識はいくらでも学んできたけれど、自分が技術者としてどうあるべきか、どういった社会的責任を帯びているかということに、思いを馳せる機会は非常に少なかったように思う。特に情報技術の分野は変化も速く、倫理的課題が大きくクローズアップされることも多い。そういうときに徒手空拳の議論に埋没せず、きちんとした哲学や歴史的経緯への知識を持っていることは結構重要なんじゃないだろうか。

Kubernetes Horizontal Pod Autoscler (HPA) において type: Resource を用いた場合、閾値の指定は resource requests に対する使用率パーセンテージとなる。例えば CPU の requests 合計が 100m で limits 合計が 200m の Pod に対し、以下の HPA metrics を設定したとする。

metrics:
- type: Resource
  resource:
    name: cpu
    target:
      type: Utilization
      averageUtilization: 50

この場合、各 Pod の CPU 使用量が平均で 50m になるよう HPA がスケーリングを行う。

このときふと疑問に思うのが、ならば limits を requests より高い値に設定しても無意味では無いかということだった。 HPA により、リソース使用量が常に requests より低い値になるよう動作するのであれば、 requests より高い値である limits に肉薄した使用量となる機会は少なくなる。もちろん、スケーリングが動作するまでのバースト余地としての意味はあるかもしれないが、少々動作が直観に反する気もする。

そもそも requests というのは、 Pod の起動時に最低限必要となるリソース量を設定するものだ。あまり大きい値だと、 Pod が無駄にリソースを確保してしまうため、 Node のリソース効率が悪くなるし、コンテナの数が増えてくれば、 Pod を起動する際の空きリソースが不足する事態も招きやすくなる。従って requests は、ある程度低めの値を設定しておくのが基本であり、これに対してさらに使用率パーセンテージで閾値をかけると、その値は自ずとかなり低い値になってくる。

この点、随分悩んでいたのだが、先日なんてことはない発想の転換を Horizontal Pod Autoscaler should use resource limit as its base for calculation · Issue #72811 · kubernetes/kubernetes で見かけた。

For instance, you might set request to 100m and limit to 250m. Set HPA to 200% cpu utilisation - this way the pods will scale when CPU usage hits 200m.

HPA の閾値は 100％ を超過した値にも設定できる。従って requests の値よりも高く、 limits に対しては余裕のあるところで閾値設定をする。すると requests よりも多くの CPU を普段は使いながらも、 limits が近づいてくればスケーリングによって不足したリソースを賄うことができる。

言われてみればこれしかないという回答なのだが、ついつい長年の経験から、監視閾値は 100% 未満で設定する他考えられなくなってしまっていた。また各種ドキュメントや書籍を見ても、 100% を超過している例を見なかったのも先入観に拍車を掛けていたように思う。設定や機能についてはドキュメントでいくらでも知ることができるが、こういった実態に即したユースケースというものを、もう少し知っていきたいなと思う。

1つ問題があって、このサービスでは日本語のフォントに対応しておらず、日本語のページタイトルだと文字化けしてしまう。 (中略) これを fork して書き換えて自前で運営しちゃえばいい。 こんな感じ で Google Font から Kosugi を import している。

しかし、その後フォントのインポートだけでは対応しきれていないことがわかった。ちゃんと日本語が表示できていることもあるのだが、できないこともあり、動作が不安定なのだ。特に Twitter Card として表示された際は表示できていないことが多かった。

結論から言えば、結局まだ対処しきれていないのだが、取りあえずここまででやってみた対策をメモしておく。

前提 : vercel/og-image のメカニズム

前提として vercel/og-image の動作メカニズムを最初に書く。やっていることはシンプルで、画像の元になるものを HTML で組み上げ、それを Puppeteer （正確には、その Node library 版である puppeteer-core ） を使ってスクリーンショットを撮り、画像化している。この一連の処理は AWS Lambda で動いている。

従ってこのレポジトリ自体の問題というよりは、 Lambda で Puppeteer を使った際の日本語表示に関する問題と捉えたほうがよい。 AWS Lambda の実行環境に日本語対応のフォントが含まれていないことへのノウハウは、かねてからウェブ上では散見されている。

puppeteer の言語設定

puppeteer は初めて使うので言語設定はあまり気にしていなかった。公式の言及ではないのだが、 javascript - How to specify browser language in Puppeteer - Stack Overflow を参考にいくつか設定を追加した。

export async function getScreenshot(html: string, type: FileType, isDev: boolean) {
    const page = await getPage(isDev);
    await page.setViewport({ width: 2048, height: 1170 });
    await page.setExtraHTTPHeaders({
        'Accept-Language': 'ja-JP'
    });
    await page.setContent(html);
    const file = await page.screenshot({ type });
    return file;
}

        options = {
            args: ['--lang=ja'],
            executablePath: exePath,
            headless: true
        };

また、生成する html においても、 <html> を <html lang="ja"> に書き換えている。

web font の読み込みラグ

より根本的と思われるところで、 web font の読み込みラグの問題がある。今回日本語化にあたっては、 Google Font （先のエントリー時点では Kosugi と書いていたが、現在は Noto Sans JP を使っている）を使っている。しかし web font 、特に日本語対応のものはロードにそれなりに時間がかかるため、ロードが終わらないうちにスクリーンショットが撮られれば tofu 状態になってしまう。冒頭に書いたように「日本語が表示できたりできなかったりする」という点も、ロード時間が一定ではないことで説明がつきそうだと考えた。

これについては非常に原始的な措置だが、待たせることにした。 Vercel で動かしているので CDN でキャッシュが効くとはいえ、画像生成においてはどう考えても悪手なのだが、一旦やむを得ないものとしている。

    await page.setContent(html);
    await page.waitFor(1000);
    const file = await page.screenshot({ type });
    return file;

ちなみに「そもそも web font 使わなければいいのでは？」という話はもちろんあって、これも試したのだが、「日本語が表示できたりできなかったりする」ことに変わりはなかった。同様の報告が https://github.com/vercel/og-image/issues/108#issuecomment-657078789 にも上がっている。

Conclusion

以上の対応で9割近くは日本語表示できるようになり、課題だった Twitter でも表示を確認できた。百発百中にしたいのだが。。ついでにデザインも変更して、まぁ一旦はここで妥協かなというところには来ている。

余談だが、今回調べる中で Google の Noto フォントが「No tofu」の意味であることを初めて知った。

O'Reilly Media より2020年8月に発刊された、 SLO practice のみに着目した1冊を読んだ。英語版のみで、邦訳は現時点で発刊されておらず、 O'Reilly Online Learning で読んだ。

SLO は SRE を実践するにあたっての中心的なプラクティスの1つで、いわゆる SRE book こと『サイトリライアビリティエンジニアリング』では第4章で言及されている。 SRE が「サイト信頼性」を守るにあたり、そもそもの守るべき「信頼性」とは何かを定義しなくてはならないわけで、『サイトリライアビリティワークブック』第20章では、「SREがない場合であっても、SLOを使うことによってSREのプラクティスはできます（p.407）」とさえ書かれている。

それだけ重要な実践なのだが、実際に取り組むのはなかなか難しい。まず、適切な SLO （SLI） をどう決めれば良いのか。よくあるのは「99.9%のレスポンスが一定時間内に返っていること」といった SLO だが、サービスによっては、単にレスポンスが早いことだけがユーザーからの信頼を得る材料とも限らない。また SLO practice にはエラーバジェットの考え方がある。例えば 99.9% の SLO を掲げた場合、月間で許容されるダウンタイムは約40分であり、これを「バジェット」として、底が尽きたら新機能のリリースはストップし、信頼性向上のための施策に舵を切ろう、というのが SRE book でのやり方だ。頭では理解できるが、リリースを実際に停めてしまうのはビジネス的にかなりインパクトの大きいジャッジであり、当然ながら SRE team のみならず、開発チームどころか経営層まで巻き込んでいく必要がある。

技術面だけではなく、組織運営、組織文化といった領域にまで広く踏み込む必要があるのがこのプラクティスで、その実践にあたって本が丸一冊書けてしまうというのも頷ける。この本では技術面、組織文化面、両面から如何に SLO practice を実践していくか、統計的な知識なども交えつつ、かなり細かく記述されている。 SLO の実践は、一度導入したらハイ終わりというものでもなく、絶え間なく計測、評価、改善を繰り返していくものなので、困ったときに末永く参照できる本として、手元に置いておけそうだと感じた。

以下では、印象に残った箇所をピックアップしていく。

段階を踏んで実践する

ソフトウェアエンジニアにはおなじみの「小さく始める」やり方がこの本でも踏襲されている。特にエラーバジェットについては、賛同を得て推進するには「長い道のり (long road)」になると書かれている。もちろん、だからできなくても仕方ないという話ではないが、少し安心させられた。

Thinking about your services with SLIs is the first step; thinking about how you need to be reliable for your users with SLOs is the second; calculating how you’ve performed against your target over time is the third. Actually using your error budget status to have discussions and make decisions is the fourth and final step. ( Chapter 5. How to Use Error Budgets )

まずは適切な SLI を定めて計測を始めてみること。計測して結果が出なければ、そもそも SLO を守ろうという意識自体生まれにくいのかもしれない。

エラーバジェットは意思決定の材料

エラーバジェットが枯渇した際、すべてのリリースを停止するというのが SRE book に書かれた実践だが、本書ではその判断には慎重になるべきだとされている。

Don’t freeze your pipeline unless you only have one product and believe it to be truly the best choice. ( Chapter 5. How to Use Error Budgets )

エラーバジェットを、機械的にリリースするか否かをゼロイチで判断するための指標として使うのではなく、重要なのは意思決定の材料として用いることである。大規模なリリースを行うときに、現状バジェットが残っているのかどうか、あまり残っていないのなら、今そのリリースを行うことが経営的にプラスなのかどうなのか、そういった思考プロセスを踏めることが価値になる。

SLO を元にアラートする

これは『ワークブック』にも記載がある内容だけど、いわゆる CPU 使用率の閾値監視などではなく、 SLO を元にアラートは上げるべきだとされている。

Instead of alerting on internal system states (such as CPU usage), alert on what really matters: the user experience (for example, latency, errors, correctness, and other SLO-worthy concepts). ( Chapter 8. SLO Monitoring and Alerting )

これ自体は比較的一般的な話ではあるが、具体的に SLO ベースのアラートをどう上げるかというと、エラーバジェットのバーンレートを使うのだという。つまり、急激にエラーバジェットが消費されているようなときにアラートを上げるというものであり、具体的には「1時間に2%消費」している場合にページングするという例が載っている。

考え方としては非常に理解できる一方、いくつかの困難も覚える。1つには、半死半生のような状態で、ゆるやかなバーンレートのときに即時対応を行わなくて本当に良いのか、という点。「SLOさえ守っていればOK」という価値観に自分はどうも慣れなくて、何はともあれ落ちていたらすぐ復旧するべきと考えてしまう。これは組織内での取り決めにもよるのだとは思うが。

もう1つは、ではこのバーンレートによるアラートをどう実装したらいいのか、という点。複雑な統計処理を行った上でアラートできるような監視ソフトウェア、サービスはそれほど多くないんじゃないだろうか。メジャーな監視 SaaS である Datadog には SLO の計測機能こそ存在するが、エラーバジェットの機能は有していない。このあたり、具体的なツールを交えた実践例があれば是非聞いてみたい。

QA との関係性

Chapter 6. Getting Buy-in になかなか衝撃的な一節がある。

I have seen the dedicated QA team eventually get disbanded and redistributed into the core engineering team.

決して QA スキル人材が不要になると言っているわけではない。 SLO practice を進めるうちに、各プロダクトチームが内在的に品質保証 = 信頼性維持のためのプロセスを回すようになるので、 QA 専任のチームというものから形態が変化していくということだ。

これは QA に限らず、 SRE も同様だと考えている。 SRE の考え方が浸透すれば、各プロダクト内で「SRE をする」ようになり、 SRE 専任チームの必要性は薄くなっていく。このあたりについても『ワークブック』などに言及があるので、やはりこの本は SRE 本2冊と並行で読むと学びが深くなると思う。

Appendix: 英語技術書を読むことについて

今回、英語技術書を読む習慣をつけようと考えて、その第一弾で本書を読んでみた。全文通読したわけではなく、重要そうなところや気になるところを各章拾い読みした形ではあるが、とりあえず1冊全体に目を通せたので多少自信になった。英語を読む習慣をつけるだけで、アクセスできる資料は何倍にも膨れ上がるので、今後も継続的に読み、そしてもっと読書スピードを上げていきたい。

$5,000で Let's Encryptを12時間ご利用いただけます。次の12時間で$5,000を寄付しましょう！お礼の印として、@Yubico よりSecurity Key NFCを無料でお受け取りいただけます (送料はかかりません)！https://t.co/swycXbtpSz pic.twitter.com/QJwoWKWKS8

昨年、 Let's Encrypt が寄付の返礼として YubiKey をプレゼントするキャンペーンを行っていて、以前より YubiKey には興味があったので入手していた。その後長らく放置してしまっていたのだが、前回 Macbook Pro (13-inch, M1, 2020) を購入した - the world as code で書いた通り、 PC を新調して移行するにあたり、 GPG 周りを改めて YubiKey を使ってセットアップしてみた。

なお補足すると、先のツイートの $5,000 は ¥5,000 の誤りであり、入手できた YubiKey は YubiKey 5 NFC である。

YubiKey とはなにか

機能は非常に多い。検索するとワンタイムパスワードトークンだとか、二要素認証デバイスなどと記述されている場合があるが、機能はそれだけにとどまらない。国内正規代理店である株式会社ソフト技研の記事 YubiKey 5 の機能【YubiKeyとは-part2】 からリストアップしてみる。

• FIDO U2F
• FIDO2 or WebAuthn
• OTP (One-time Password)
• TOTP (Time-based One-time Password)
• スマートカード機能（クライアント証明書の格納、 OpenPGP 秘密鍵の格納）

今回試したのは最後のスマートカード機能であり、 OpenPGP の秘密鍵を格納して、 PGP による署名、認証等に用いることができるようにした。

他の機能を概観すると、 OTP は、 YubiKey 本体のアイコン部分をタッチしたり、 YubiKey 5 NFC の場合は NFC で通信することによって生成される（ちなみに、あのアイコンをタッチすると指紋認証できるのではと勘違いしていたが、 YubiKey に生体認証の機能はない）。僕が使っているパスワードマネージャー Bitwarden のプレミアム機能と連携できるようだが、現状非プレミアムで使っているため試すに至っていない。 TOTP はいわゆる二段階認証のそれだが、スマホアプリでの認証との比較優位が見い出せなかった。 FIDO, FIDO2 については正直技術的に理解しきれていない部分があり、どこかのタイミングで勉強できればと思っている。

PGP, OpenPGP, GPG

名前が似ていて PGP, OpenPGP, GPG を混同しがちだったが、関係性をまとめると以下のようになる。

• Phil Zimmermann が開発した暗号ソフトウェアが PGP (Pretty Good Privacy)
• PGP を元にして、 RFC で定められた暗号文、デジタル署名などの規格が OpenPGP
• OpenPGP を元にして、 GNU により公開されているソフトウェアが GPG (GnuPG)

GPG には暗号関連の技術で実現する機能の多くが実装されている。公開鍵暗号、デジタル署名、一方向ハッシュ関数、鍵リングの管理など。今回はこの GPG を用いて Git commit へのデジタル署名と、 ssh key の管理を実現し、その鍵の管理に YubiKey を用いることにした。

PGP や GPG については 結城浩『暗号技術入門 第3版　秘密の国のアリス』 (2015, SBクリエイティブ) を参考として学んだ。

今回実践したこと

今回の実践にあたって、参考としたのは主に以下の資料。

1. Guides – Yubico
2. drduh/YubiKey-Guide: Guide to using YubiKey for GPG and SSH
3. GnuPG チートシート（鍵作成から失効まで） | text.Baldanders.info

1. が YubiKey を販売している Yubico の公式ガイドにあたる。基本的にはこれに従うべきとは思うが、かなりリンクが多くて目的のドキュメントが探しづらかったり、各ページの記載がコマンドを step by step で実行するだけのものが多く、そのコマンドが何を意味するのか掘り下げづらいなど、少々難を覚えた。 2. は執筆者の素性を把握していないのだが、 YubiKey + GPG についてより詳しく手順が解説されており、公式ガイドよりこちらを多くは参照していた。 GPG のコマンドチートシートとして、合わせて 3. を参照した。

先述した通り、やりたいことは「Git commit へのデジタル署名」と「ssh key の管理」の2つで、これを実現するために以下の手順で作業を行った。細かい手順は先の資料に記載があるのでここでは再説明せず、ポイントだけ書いておく。

1. GPG キー (master key x1, sub key x3) の生成
2. sub key の有効期限設定
3. 生成したキーの YubiKey への import
4. ローカルマシン側の master key と失効証明書の退避
5. keybase への鍵登録
6. Git commit への署名設定
7. ssh key として GPG キーを使用するための設定
8. 移行後のマシンで YubiKey 内のキーを使用するための設定

GPG キーの生成

GPG には master key （主鍵）、 sub key （副鍵） の概念が存在する。 master key の公開鍵は公開鍵基盤で広く公開するため、それと紐付く秘密鍵は厳重な管理が求められる。そこで実際の暗号化や署名には master key を直接は使わず、 master key が署名した sub key を用いる。sub key は署名用、暗号化用、認証用の3種類を作るのが一般的になっている。

手順は Yubico の Using Your YubiKey with OpenPGP – Yubico に従ったが、一点だけ、この中では RSA 4096 bit を用いる形となっているが、 YubiKey 5 は楕円曲線暗号 ECC P-384 に対応しているので、そちらでもよかったかもしれない。

sub key の有効期限設定

以下のコマンドで設定した。期限設定後、期限到達前に延長も可能なので、それほど強い制約を課すものではない。

$ gpg --quick-set-expire $MASTER_KEY_FINGER_PRINT 1y $SUB_KEY_FINGER_PRINT

生成したキーの YubiKey への import

GPG にスマートカードへの書き出し機能が備わっており、これを利用する。 import したキーを読み出す際には、 PIN によって制限がかかる格好となっている。これはデフォルトで 123456 という値になっているので、あわせて変更が必要となる。 YubiKey の紛失も考えると、チャレンジ回数は制限しておいたほうがよい。

ローカルマシン側の master key と失効証明書の退避

YubiKey にキーを import したら、ローカルマシン内の master key は紛失、盗難を回避するために、別のディスクなどへ退避してオフラインで保管することが推奨されている。これが結構悩みどころで、本気で保管するならばある程度冗長性のあるディスクに保存したいところだが、その手のディスクはご自宅にあるとしてもネットワーク接続された NAS の場合が多く、オフラインにならない。一旦 USB メモリに退避はしたものの、現代においてはかなりシビアな運用ではないかという気がしている。

また master key の失効証明書が、キー生成時に macOS の場合は ~/.gnupg/openpgp-revocs.d に生成されている。これも盗難された場合には悪用の危険があるため退避が必要だが、 master key の紛失時に必要となるものであるため、 master key とは別途保存が必要となる。

keybase への鍵登録

Keybase は公開鍵基盤を提供するサービスであり、ここに公開鍵を登録した。公開鍵基盤では、その鍵が誰のものであるか保証する必要があるわけだが、 Keybase は SNS などを用いて本人であることを保証できる点が特徴となっている。僕のアイデンティティはこちら。

https://keybase.io/chroju

Keybase には秘密鍵も登録可能で、その鍵を用いて Keybase の UI 上で暗号化サービスや、秘匿ファイルの共有なども行うことができる。

Git commit への署名設定

先の 2. の資料に則ったので割愛する。 GitHub 側でも　コミット署名の検証を管理する - GitHub Docs　で手順を公開している。

ssh key として GPG キーを使用するための設定

これも 2. に手順が詳細に記載されている。

移行後のマシンで YubiKey 内のキーを使用するための設定

移行後のマシンで YubiKey 内のキーを使うには、 YubiKey を挿した上で以下の手順を行った。

1. gpg --card-edit でスマートカードの操作モードに入り、 fetch コマンドで、 YubiKey に登録した URL (keybase) から公開鍵をダウンロード
2. この鍵を信用するために gpg --edit-key で鍵の操作モードに入り、 trust コマンドで信頼する
3. 新しいマシンを Keybase に登録する

インポートした鍵は、新しいマシン上では「知らない鍵」にあたるため、それを信用していいのかどうか GPG 側では「不明」のステータスになっている。これを自身の鍵であるとして信用するのが 2. の手順。自分の鍵の場合、信用度は「ultimate (究極)」になる。

❯ gpg -k            
/Users/chroju/.gnupg/pubring.kbx
--------------------------------
pub   rsa4096 2020-08-23 [SC]
      5B1586BD87F81233D5A72590B2901C02871B6CD5
uid           [  究極  ] chroju <chroju@users.noreply.github.com>
sub   rsa4096 2020-08-23 [E] [有効期限: 2022-01-17]
sub   rsa4096 2020-08-23 [A] [有効期限: 2022-01-17]
sub   rsa4096 2020-08-23 [S] [有効期限: 2022-01-17]

また Keybase はアカウントとデバイスを対応づけることが可能になっており、信頼したデバイスからでなくては操作を受け付けない場合がある。そこで新しいデバイスを導入した際には、 Keybase への登録も忘れずに行う必要がある。

Impression

これまで特に ssh 鍵は作ってはキーフレーズを忘れてしまったり何度か作り直したりしていたので、一括管理できる方法を導入してスッキリさせることができた。難点としては YubiKey がなければ ssh も commit も出来ないという点で、こういう運用をするのであれば USB Type-C 対応の YubiKey が必要になりそう。今は常に家で作業しているので、ディスプレイの USB-A ポートが使えるのだが。

また GPG の仕組み、公開鍵基盤の仕組みなどを改めて復習できたのもよかった。 FIDO など、まだ活用できていない YubiKey の機能も今後概観したい。

まったくもって買うつもりがなかったんだけど、 MBP のキーボード上にたっぷりドレッシングがかかったサラダをぶちまけてしまうアクシデントがありまして。。あの初期バタフライキーボードのうっすい打鍵感が、油が間に挟まったのか、さらにうっすくなって押しているのか押してないのだかもわからなくなり、終いには掃除しようとキーを外したところ壊してしまいまして。。泣く泣く Genius Bar に持ち込んではみたものの、過失による修理なので最大10万ぐらいかかるという話で、それならあと数万上乗せして新品買っちゃうかぁ、ということで買った次第。

なぜ M1 MBP なのか

まだまだ未知数な M1 に日和って Intel にしておこうかともちょっとだけ思ったのだが、周囲に背中を押されたのと、価格差が無視できないぐらいにあるということで M1 に。

また、ここ数年はパソコンを買い換えるたびに Linux デスクトップという選択肢も検討はしているのだが、毎度断念している。理由としては以下。

• そもそも macOS でそれほど困ってはいない
  • 散見されるデメリットとして Docker Desktop の遅さというのがあるが、 Docker で開発する際は、仕事/プライベートともに開発用の k8s へ apply する場合が多く、 Desktop でのパワーは必要としていない
  • 純粋な Linux や UNIX が Desktop として必要なわけでもない
• Alfred, Mission Control, Magic Trackpad による UX はかなり好きで依存している
• 通信制大学に通っている都合上、 MS Office が必要であり、 Linux を開発機にする場合は別途 macOS or Windows も必要になる

2点目に関しては正直なところ、あんまりベンダーロックインされたものに依存するのはよくないんだろうな、と感じてはいる。特に Mission Control が便利で、複数の仮想デスクトップを3本指でするする切り替えながらの開発にはもうだいぶ馴染んでしまった。良くないんだろうなぁ、とは思ってはいるけど、やめられずにいる。

3点目、 MS Office が必要なら WSL2 とか Linux と Windows のデュアルブートという手もあるのだが、1,2点目の理由を覆してまで Windows を買う理由にはならなかった。 WSL2 は仕事で使った経験があるにはあるんだけど、あんまり好みではなかった。

Impression

よい。とてもよい。

特に発熱しない点と、バッテリーの保ち。前代の MBP はちょっと動画を開いたり、 Docker をゴリゴリ使ったりするとすぐにファンが回り始めていたのだが、 M1 MBP は半月ほど使っていてファンが回った覚えがほとんどない。そもそもそれほどヘビーな使い方をしてもいないとは思うが、 tmux で常にステータスバーへロードアベレージを表示していたのは要らなくなったなぁ、と感じている。

バッテリーに関してはだいたい8時間で空になる。前代 MBP がどれぐらいか正確なところは測っていないが、体感4時間ぐらいだっただろうか。かなり保つようになった。今ブログをアダプタ付けずに30分ほど書いたところだが1%も減っていない。参考に1週間の使用時間と電池の使用状況を貼っておく。

M1 のソフトウェア対応状況については、 M1 Macの開発環境 - Qiita など先人の資料があるので割愛させてもらう。ざっくりと言うと、 M1 未対応のものでもそれなりに Rosetta で動くので、僕の利用範囲で「使えなくて困った」ものは今のところない。なぜか Ansible が上手く入れられていないが、 Python はもちろん arm 対応しているので自分の問題だと思う。

ただし、過渡期故の面倒くささは否めない。例えば Homebrew は 2.6.0 で arm 対応してはいるが、公式には Rosetta での使用が推奨されており、 arm 版 brew をインストールする場合は、 Intel 版とは別で /opt/homebrew というフォルダを作成して使うように促されている。これについては Homebrew on Apple Silicon — Hi, I’m Sam を真似して、 Intel 版には ibrew という alias を貼って使っている。

当然ながら既存の Brewfile もそのままは使えず、今は必要なものが出てきたら、その時々で brew install して、ダメだったら ibrew install し直すというフローになっている。長らく dotfiles として管理してきたが、 Intel Mac 用、 M1 Mac の arm 用、 Rosetta 用で Brewfile が3つに分かれる事態になってしまった 。他にも VSCode など、本リリース前のバージョンしかまだ arm 対応していないソフトウェアもあり、いちいち調べる必要がある、というのは買う前に覚悟が必要。

まぁ、とはいえ続々 M1 対応が進んではいるし、キーボードもシザーキーボードで打ちやすいし、そして前モデルから10万近く安くなっているし、かなり良い買い物だったと感じている。

• 移行前ブログから、移行後ブログへのリダイレクトを設定
• 移行前ブログでの更新は停止
• 移行前ブログの feed 更新も停止

なぜ Next.js なのか

今回の移行理由は「 Next.js を使ってみたかったから」に尽きる。

僕はインフラエンジニア出身の SRE で、経歴を辿るとサーバーや RDB のチューニングでパフォーマンスを維持することには注力してきたけど、フロント側の知識はほぼまったくと言っていいほどない。でも SRE がサイトの信頼性、具体的にはレスポンスの最適化に責務を負っているのに、フロントを理解していないというのはダメだろうと。静的なものを可能な限り CDN に置く時代において、サーバーのインフラ的なチューニングだけの知識だけでは心許なくなった。

Next.js を選んだのは、昨年後半あたりにその名を周りのフロントエンジニアから聞くことが多くなってきたのが直接的な契機だった。 Next.js は、かつて ZEIT という名前だった Vercel が提供している React.js のフレームワーク。 Vercel 自身が Next.js をデプロイできるプラットフォームを運営していて、 Next.js のコードを置いたレポジトリを連携するだけで、簡単にサイトをビルド、公開できる。

実は React.js + Netlify という組み合わせは昨年少し試してみていたこともあり、 React の知識を応用できそうで入門しやすいかなと感じた。また Server Side Rendering と Static Site Generator 双方の機能を持っているし、開発元の Vercel でデプロイすると、自動的に「サーバーサイド」（実体は AWS Lambda だが）まで構築してくれるというところに面白さを感じた。コンテナやサーバーありきのアーキテクチャの考え方から脱したかったんですよね。ついサーバー側を中心としてサービスを捉えちゃうんだけど、 Next.js だとはじめに javascript ありきで、そこから必要なサーバーサイド側のリソースが生成される形になっている。

ブログは4年間ほど hugo + github.io を使って運営していた。 Next.js を試せれば、対象はなんでもよかったんだけど、どうせなら長くサンドボックスとして使えるようにしようと、 hugo から移行を決めた。 hugo には大きな不満を覚えていたわけではないが、正直裏側をちゃんと理解していなくて、たまに手が届かない部分があったりしたので、フルスクラッチで自分でコード書いてブログ作るってのはありなんじゃない？と思った。

技術背景

フルスクラッチでコードを書く羽目になるのを覚悟していたのだが、実際のところは Create a Next.js App | Learn Next.js という公式のチュートリアルがズバリ「markdown から ssg でブログを生成するサイト」を作る内容になっていたので、このチュートリアルを完走して出来上がったコードを少し改変するだけでこのブログは出来上がってしまっている。このチュートリアル、かなり親切な内容になっていてわかりやすかったのでおすすめ。

自分で改変した部分で特筆するものとしては、以下の通り。

RSS の追加

RSS Feeds in a nextjs site | Logan's Blog を参考とした。 RSS の XML を生成できる rss - npm を使用しており、 npm build 時に一緒に XML も生成している。

トラブルとしては、どうも markdown の中に制御文字が紛れてしまっていたようで、上図のように XML にエラーがあるとブラウザから警告が出てしまった。このブラウザ側の警告、 line と column の位置にズレがあるのか、デバッグに苦労した。 W3C が W3C Feed Validation Service, for Atom and RSS という feed xml の validator を公開していて、こちらを使ったほうがデバッグしやすかった。

OGP 画像の動的生成

実は Vercel　が https://og-image.now.sh/ という、 OGP 画像の動的生成サービスを保有している。先のチュートリアルの中では、これを使って OGP 画像を link タグに設定する手順まで含まれている。だが1つ問題があって、このサービスでは日本語のフォントに対応しておらず、日本語のページタイトルだと文字化けしてしまう。

解決策としては、このサービスは OSS で vercel/og-image: Open Graph Image as a Service - generate cards for Twitter, Facebook, Slack, etc に公開されていて、おまけに Vercel へデプロイ可能になっているので、これを fork して書き換えて自前で運営しちゃえばいい。 こんな感じ で Google Font から Kosugi を import している。また Vercel の無料プランだとメモリは 1024 MB 以下、リージョンは1箇所しか使えないので、そのあたり vercel.json も書き換えてやる必要がある。

チュートリアルでは OGP 最低限の設定しか成されないので、 The Open Graph protocol を参考にいくつか追加している。

Syntax highlight の導入

Prism を使っている。 highlight.js と迷ったのだが、 Prism のほうが導入が簡単そうかなぁ、という素人の感想。 useEffect() で読み込むだけだったので。

Prism はハイライト対象の言語が選択式になっていて、必要なものだけ import して使う形になる。これについては mAAdhaTTah/babel-plugin-prismjs: A babel plugin to use PrismJS with standard bundlers. を使わせてもらった。 Prism の対応言語のみならず、プラグインやテーマも一括して babel で管理できて便利。

{
    "presets": [
        "next/babel"
    ],
    "plugins": [
        [
            "prismjs",
            {
                "languages": [
                    "javascript",
                    "css",
                    "bash",
                    "diff",
                    "docker",
                    "go",
                    "hcl",
                    "json",
                    "markdown",
                    "nginx",
                    "python",
                    "ruby",
                    "typescript",
                    "vim",
                    "yaml"
                ],
                "plugins": [
                    "line-numbers"
                ],
                "theme": "tomorrow",
                "css": true
            }
        ]
    ]
}

ifamely 対応

外部サイトをリンクする際に、ブログカードと言うのだろうか、 OGP から情報を持ってきて見栄えよい表示を実現するのに ifamely というサービスを使っている。こういうやつ。

これが上手く表示できなかった。原因としては、 markdown から生成した HTML を dangerouslysetinnerhtml に渡してレンダリングしているのだが、この関数が dangerously set と危険性の認識を示しているように、 XSS を防ぐ目的で、渡された script タグを実行しないようにしていること。 ifamely は外部 script の実行が必要になっている。

対処としては How to inject scripts using dangerouslysetinnerhtml on Client-Side Rendering? | by SunCommander | Medium を参考に、 nfl/react-helmet を使って別途必要な script だけ読み込んでいる。ただやり方的にちょっとダーティーだなという気はしている。

その他

細かくいろいろやっている。

• front matter の扱いが適当で統一されていなかったので YAML で統一した
• fontawesome を導入した
• CSS をちょっと書いた

今後

CSS はあんまりこだわりたくないのだが、もう少しだけ頑張る必要がありそう。 blockquote だけ表示がおかしい状態になっている。

それ以外は一応動く状態になっているし、明らかに移行前よりレスポンスが良くなった。が、 lighthouse によるとまだまだ全然なので、折りを見て少しずつ良くしていきたいなあと思っている。今更だけど Web の標準に強くなっていきたい。

あと Next.js は概念的にはコンポーネントと props さえわかっていれば OK という感じで飲み込めたのだが、そもそも ES2015 ちゃんとわかってないとか、チュートリアルでは js だったけど TypeScript で書き直してみたいなぁ、などということも考えている。

• 2015
• 2016
• 2017
• 2018
• 2019

昨年までは「総括」という単語を使っていたが、今年は Retrospective にしてみた。英語でかっこいいよね、という単純な理由もあるが、いま属している会社がスクラムを基軸としているので、個人の振り返りやタスクのサイクルの中でもスクラムのプラクティスを意識できればな、という思いもある。

昨年同様に定量、定性の両面で振り返る。

定量評価

ブログ

昨年比4本減の23本書いた。あんまり書いていないな、という自覚は自分でもあった。後述するけど、プライベートで技術探求やインプットがあんまり回っていなくて、学んだことをブログに書くサイクルを確立でてきていなかった。とはいえ本をそれなりに読んだりしてはいるし、単純に怠慢だとも言える。

Advent Calendar は今年も去年と同様、 Terraform と会社（グロービス）2本立て。どちらも Terraform ネタなんだけど、会社で書いたほうが LGTM とはてブをだいぶ集めてくれたのは嬉しいような微妙なような。

• Terraform Cloud を Alfred や CLI から操作する | the world as code
• Terraform について、やっていることをすべて話そう - Qiita

GitHub Contributions

Public repository で 466 。昨年が 290 なのでかなり増えたのだけど、なんで増えたのかがいまいちわかってない。が、今年も引き続き、使っている OSS で何かあれば issue や PR をちゃんと上げることを意識した。もう習慣になっていると言ってよさそう。 vuls でバグ報告したら15分で直った のがちょっと面白かった。

private のほうは会社が Kubernetes と Terraform で Infrastructure as Code が一段と進んだので 4000 越えてる。昨年比 2800 ぐらいの増加。その代わり GitHub Notification がパンクしててなんも読めてない、みたいな感じなので年末年始でどうにかしようと思ってたんだ。今思い出した。

読書

印象に残ったのをピックアップ。

• Kubernetesで実践するクラウドネイティブDevOps
• 失敗の本質―日本軍の組織論的研究
• 静かなリーダーシップ
• エンジニアのためのマネジメントキャリアパス
• 独学大全 絶対に「学ぶこと」をあきらめたくない人のための55の技法
• なぜ危機に気づけなかったのか ― 組織を救うリーダーの問題発見力

自分でもびっくりするぐらい「技術書」が少ない。理由としては Kubernetes という変化の早い分野が今年は中心だったので、本よりドキュメント読んでいるほうが多かった、というのはあったように思う。あとは O'Reilly Online で横断検索していろんな本から探っていたので、読了した本というとかなり少ない。その中でも特にいいな、と思っていたのが冒頭に上げた「Kubernetesで実践する〜」で、これが日本語で出版されたときは嬉しかった。 k8s の長期的な運用にフォーカスして、何を気にしなければならないのか、広範なエコシステムの中でどんなツールを使えばいいのか、ということを詳説した本で、右も左も分からない頃すごく役だった。

あとはチームリーダーになったために、マネジメントやリーダーシップ関連の本をよく読んでいた。結構な数は読んだと思うので、年が明けたら一旦こちらのインプットは停めて、また技術方面に軸を寄せたい。

定性評価

注力した領域

• Kubernetes
  • 会社のプロダクション環境で Kubernetes が動き始めた。
  • いまだに全然わからんと思いながらやっていっている。
  • やることが多い、知るべきことが多い、大変。学習コストすんごい。
  • でも好き。
• Terraform
  • ずっと継続。自分の中で一番コアにいるツール。
  • Terraform 自体より、自動実行とかライフサイクルを考えることが多かった。
• クラウドアーキテクチャ全般
  • サーバーは要るか要らないか、コンテナは要るか要らないか、AWSは要るか要らないか、みたいな
  • 選択肢がすごい増えているし、何がベストなのか考えるのが難しくなっている感覚
  • SPA、SSG、SSR あたりを考え始めると、 SRE と言えどフロントも無視できなくなってきた
• リーダースキル
  • 後述

ライフスタイル

激しく変化した。というか変化していない人はいないだろう。

インドアな人間なのでそこまでしんどくはないし、新しい生活様式を受け入れるのでてんやわんや、ということもなかったんだが、会社、プライベート含め「周囲はどうだろうか？」ということを考えると自分が良ければ OK とはいかなかったり。外出していいのか、あれはやっていいのか、旅行してもいいのか、みたいな、自分の行動すべてに関して是非の判断が入るような生活はとても疲れる。

おそらくこれは不可逆な変化なんだろう、とは思っている。今は転職を全然考えていないが、次に転職するとき、リモートワークを認めてくれない会社にはもう入れないだろうなと思う。コロナ禍が完全に沈静化するにはあと1年じゃ効かないと思っているが、それを終えた先に社会がどうなっているのかはまだわからない。変化にはまだまだ柔軟でいる必要がある。

リーダースキル

社会人生活10年目で、ちゃんと職責与えられてリーダーをやる経験を初めてした。名ばかりのは何度かあったが。

とはいえメンバー個々人がスキル高くて自主的にガンガン仕事するようなチームなので、マイクロマネジメントの必要もないし、リーダーが何かしなきゃって強い責務が生じているでもないのだけど、それでもリーダーって何やったらいいんだろうな？というのをずっと考え続けた1年だった。問題を解決したり、強い意見を出すというよりは、意思決定の最終決定をすることと、その決定された意思に基づいた活動を支えること、何か問題があったり、起きそうであればそれを取り除くことが職責なのかなと今は思っている。

それがちゃんと行動習慣に落ちているかというと、まだそうでもないので来年の課題。

常に疲れていた

これらの変化があったせいなのか、常に疲れているな、という感覚がある1年だった。

理由としては、ずっと家にいるが故に、家事、仕事、プライベートといったさまざまなタスクが全部常にスタックされている感覚があったのがひとつ。出勤していると、会社にいるときは仕事のことだけ考えればいいし、メリハリがあったんだけど、家で仕事をしていると昼休みのうちに洗濯できそうとか、お茶を入れているときに「このへん汚れてるから掃除しなきゃ」って気付いちゃったりだとか、そういう感じで「やること」が無限に増えるし、やろうと思えばいつでもどのタスクにも着手できる、っていう、メンタル的にはわりと地獄みたいな状態だった。

どうすればいいかな、と考えてみてもまぁどうにもならなさそうなのだが、やらなくていいことを増やしたほうが良さそうかなと思っている。長期的に考えると書斎がほしい。家の中であっても、物理的に隔離された場所で仕事をするのがベストっぽいように思う。

来年について

軽くいきたい。

がんばらない

最後に書いた「常に疲れていた」の話があるのでがんばらないようにしようかと。やることを減らす、やらなきゃって思わないようにすることを徹底したい。来年もコロナには悩まされそうだし、ちょっとギア落として、とにかく生存することを目標にする年というのがあってもいいんじゃないかと。

小さなサイクルを回す

別の言葉だとフットワークを軽くする。本を1週間ぐらいでザッと読むとか、気になる技術領域があったら、休日半日ぐらいでサッと触って感触をつかんでみるとか、それでその結果はちゃんとブログに落とし込んで、サイクルを小さく回していきたい。

やることが増えたことへの対処の1つになるとも思っている。1個1個の「やること」を小さくしてしまえば負担は軽くなる。インフラから SRE になったことで、知るべき技術領域がかなり増えたというのもある。先述したようにフロントエンドも気にしたりしているが、8年9年のキャリアで本当にフロントは一切触ってこなかったりしたので。広く浅く、サービスの信頼性を守るための知識をつけたいな、という気持ちが強い。

技術的な興味、方向性

今あんまり手を出したい技術というのがなくて。 Kubernetes が大変なのでもっとやらなきゃってのでいっぱいなのでそれでいいかなとは思っている。あとは「小さく」というところで知らない技術を触る、少しだけ触るという機会はどんどん設けたい。この年末年始も Next.js でブログを作ることをしていて、実はもう出来上がっていてあとはリダイレクト設定するだけだったりする。新しいことをやるのはやっぱり楽しいので、なんだろう。これをやるぞ！って決めるというよりは、ノリでやっていこうかな、と。

こんなとこだろうか。社会は大変な状況だけど仕事は面白くてのっている感覚はあるので、無理せず楽しく来年は生きていきたい。

Best buy 2020

WFH 関連の物品については、 WFH を始めて半年が過ぎ、調えたり諦めたりしたこと | the world as code や COVID-19 とリモートワーク - 設備だけではなくルーチンも大事 | the world as code に書いているので除外した。とはいえ、ほぼおうちグッズしかない。

デンタルフロス

https://www.amazon.co.jp/dp/B07B5CD8NY

地味だが今年一番買ってよかったかもしれない。

昨年、親知らずを抜くために歯医者へ10年ぶりぐらいに行ったところ、治療が終わっても定期検診の予約をその場で4か月後に入れさせられるタイプの歯科だったので、そのまま定期的に通う習慣ができた。そのなかで歯科衛生士に強く勧められてフロスを使い始めた。

デンタルフロス、歯と歯の間にねじ込むのが少し怖くて使うのを躊躇していたのだけど、いざ使うとびっくりするぐらい汚れが取れる。電動歯ブラシを使ったり、それなりに歯磨きに気は遣っていたけど、それでも歯間って磨ききれないのだということを理解した。なんでも日本人はデンタルケアのリテラシーが低く、フロスもあまり使われていない（僕も使っていなかったし）そうだが、これは絶対使ったほうがいいと思うようになった。

ちなみにP字型ではなくY字型のものがいいとのこと。奥歯に使うとき、どちらが使いやすいか想像するとわかりやすい。最も良いのは、常に真新しいフロスを歯に当てて使えるリールタイプだそう。

HASAMI

波佐見焼の陶磁器ブランド。実家を出てから10年ぐらい、食器は実家から持ってきたものと、1番くじなどで手に入れたものを使い続けていたのだが、ここらで統一感のあるシリーズで揃えるのもいいか、と買ってみた。

そもそも食器の知識が一切ないとこから始まったので、〇〇焼と付くような日本の焼き物は白地に青、みたいな保守的なイメージしかなく、こういうモダンなデザインがあること自体知らなくて驚いた。高いものが欲しいわけではないので、形状のバリエーションがあって、シンプルなものを探していて HASAMI をチョイスした。使い勝手は良いし、ネイビーの皿に載せるとだいたいのものが映える感じになって食事が楽しい。

最後まで比較していたのが美濃焼の SAKUZAN DAYS 。こちらもカラフルで好き。

H&F BELX のノンカフェインティー

https://www.handfbelx.com/stores/

家で仕事をするときに飲むものはコーヒー、炭酸水、ノンカフェイン or 低カフェインのお茶の3種類。コーヒーはカフェイン摂取量の都合上、1日2杯と決めているし、炭酸水はお金がかかるのでお茶が一番飲む機会が多く、いろいろと探した1年だった。

ノンカフェインのお茶が最近は増えていて嬉しい。特にこの H&F BELX はノンカフェインティー専門の店で、種類がかなり豊富で飽きない。特にルイボスをベースにフレーバーを付けたお茶が多くあり、紅茶代わりのアールグレイや、甘いものが欲しいとき用のピーチなどが気に入っている。難点は店舗数が少ないこと。

他の店だと、無印良品にもノンカフェインティーが多く、トウモロコシ茶や韃靼そば茶をよく飲んでいる。

ネスレ アールグレイポーション

https://www.amazon.co.jp/dp/B01C44IV78

お茶絡みでもうひとつ。水や氷で割るとアイスティーになる、濃縮紅茶のポーション。昔からティーソーダが好きなのだが、あれはあんまり売っているものではないので、夏場はこれをウィルキンソンの炭酸で割って飲んでいた。人工甘味料が入っているし、そこまで香りがいいわけではないのだが、僕には十分。

極 お米保存袋

https://www.amazon.co.jp/dp/B07X5FSBDP

お米を冷蔵庫で保存したいけれど、大きな容器を入れられるほど冷蔵庫に容量がないんだよな、という長年の課題が解決した雑貨。ジッパーと空気弁が付いていて、最小限の容積でお米を冷蔵庫に保存できる。レビューを見ると「すぐに破れた」「ジッパーが閉めにくい」といった声もあるけど、特に問題なくもう半年以上使っている。破れたら買い換えるのも、この価格ならいいかな、と思っている。

Subscriptions 2020

昨年との diff です。

  * Day One (¥2,800 / year)
  * MoneyForward プレミアム会員 (¥500 / month)
  * Nintendo Switch Online (¥2,400 / year)
  * Amazon Prime Student (¥2,450 / year)
  * Spotify Premium Student (¥480 / month)
  * シネマシティ (¥1,000 / year)
  * Dynalist Pro ($7.99 / month)
  * dアニメストア (¥400 / month)
  * freee (¥1,980 / month)
  * メールマガジン「読書日記／フヅクエラジオ」 (¥800 / month)
- * Online Learning with O’Reilly (about $500 / year)
+ * ATOK Passport (¥300 / month)
+ * IFTTT Pro ($1.99 / month)
+ * Association for Computing Machinery ($99 / year)

唯一解約されている O'Reilly は 一番下の ACM への乗り換えなので、実質的に今年は解約がなかった。安定してしまった。 ACM と O'Reilly の関係についてはもう有名な話なのでググってもらえると。

O'Reilly 、いくら読み放題と言っても値が張るし、そこまで読まないし、ということで長年躊躇していたが、いざ契約してみるとこれは「読み放題」であることが価値、というよりは、「数万冊のクオリティがある程度保証された技術書を横断検索できる」ことに大いに価値があった。ググる代わりに、オライリーを横断検索する権利を買う、って考えると「あ、安いかも」って思える。特に今年は Kubernetes に入門した年だったのでいろいろと悩む場面があり、そのたびにここで検索して複数の書籍から情報をピックアップして使っていた。

追加した ATOK Passport は、 Google 日本語入力の開発が滞っている、というような話を夏頃目にして、まぁ確かに、というのと、他の IME も試してみるか、というところで使ってみている。ただ正直、そこまで変換精度優れているか？という疑問がある（数学、コンピュータ系のちょっと込み入った単語になると全然変換されない）のと、設定項目が多すぎるのとで、首を傾げながら使っている節は強い。

IFTTT は突然有料化されてしまい、もう何年も使っているので急に手放すこともできず、お金を払い始めた。最初の年は自由に価格決めていいよ、ってことだったので最低価格にしている。

つい先日 「サブスク」費用を全部足し算したら、けっこうキツい - ケータイ Watch という記事が話題になっていて、まぁこの記事はモバイル回線みたいな「それ生活費じゃない？」みたいなとこまでサブスク扱いしていてもにょる部分はあるのはあるんだけど、最近なんでもサブスクというか、月額課金制になりすぎじゃないかな、という感覚は強い。経営知識がないので、買い切りから月額制に切り替えるのってどういうメリットがあるのかいまいちわからない。毎月拠出可能な固定費なんて上限があって、その中で何を契約するか選ぶわけだから、月額制にすると例えば ATOK が全然違う領域のdアニメストアと比較検討されたりするわけで、不要な競争生じてない？とか思ってしまう。どうなんだろ。消費者的にも ATOK よりdアニメストアのほうが大切なので ATOK 切ります、みたいな意味のわからない比較はあんまりしたくない。今ぐらいが限界かなぁ、とは思っている。

「問題発見」の技術、メソッドを知りたくて、 Michael A. Roberto の『なぜ危機に気づけなかったのか（原題 : Know What You Don't Know ）』を読んだ。

問題発見を学びたいと思ったきっかけはリーダー職に就いたこと。チームの問題、メンバー個々の問題というのをきちんと察知してアクションできるようになりたかったのだけど、具体的にどうすればいいのか考えあぐねていたので本に頼ってみた。

僕らソフトウェア系のエンジニアは「問題解決」が本職と言ってもいいぐらいだけど、問題を解決するにあたっては、解決するべき問題をまず的確に見つける必要がある。それがつまり「問題発見」の技術ということになる。

ところが長年、この分野に関してあまり良い本に巡り会えなかった。真っ先に名前が挙がるのは『ライト、ついてますか』だと思うのだが、この本はどちらかと言えば、何かトラブルが顕在化した後で、では解決するべき問題は具体的になんなのか、それをどう捉えて解決していくべきなのかという、「正しい問題定義」の本に近い。

https://www.amazon.co.jp/dp/4320023684

僕が求めている「問題発見」の技術はそうではなくて、可視化されていない問題、あるいは見過ごされていたり、自覚されていない問題を如何にあぶり出すか、という技術のことだ。ラムズフェルド元アメリカ国務長官の Unknown unknowns という言葉が近い。そしてこの本は原題を見ればわかる通り、僕の求めていたことにドンピシャな本だった。

本書では問題発見に必要なスキルを7つに分類していて、それぞれ実際に起きた問題事例を教訓として、具体的なプラクティスに落とし込んでいるので飲み込みやすかった。

• フィルターを避ける
• 人類学者になる

  • 人に質問するだけでなく、その行動を見守らなければならない。というのも、人の発言と行動は一致しないものだからだ。 (p.7)

• パターンを探す

  • リーダーが目前の問題を明確に把握していなければ、役に立つ類似点を見つけて、それを正しく使うことはできない。この方法を使えば、暗黙の想定を明らかにし、事実と想定の区別をつけざるを得なくなる。 (p.136)

  • 想定の検証:七つの重要な質問

  • 1. この状況における事実は何か。

  • 2. 暖味な、あるいは不明瞭なことは何か。

  • 3. 明確な想定と暗黙の想定と考えられることは何か。

  • 4. 事実と想定を混同していないか。

  • （略）

• 点を結びつける

  • 最初に自分の意見を述べるよりは、リーダーは会議のファシリテーター(進行役)に徹したほうがいい。リーダーは公開されていない情報を明るみに出すために積極的に介入し、メンバーを自由閣達な対話に引き込むべきであろう。 (p.167)

• 価値のある失敗を奨励する
• 話し方と聴き方を教える

  • 往々にして相手が話し終わらないうちに結論を出してしまうことがある。相手が話している最中に、どう答えようかと考えることがある。特定の言葉や意見の意味について、さまざまな憶測をめぐらし、話し手も自分がよく知っているのと同じ言葉づかいでしゃべっているものと早合点することが多い。 (p.216)

  • ある人が反対意見を述べても、それが多奴派の考え方をただちに変えることはないだろう。しかし、それによって異なった考え方が刺激されることが多い。 (p.227)

• ゲームの録画を見る

今は WFH で slack でのやり取りがメインになっているので、特に「フィルターを避ける」「人類学者になる」という観察を重視するスタイルは強く意識したいところだし、「点を結びつける」「話し方と聴き方を教える」に書かれているような、話し方や MTG でのコツについてはすぐにでも実践していきたい。「話し方と聴き方を教える」での指摘は結構刺さるものがあった。

Alfred Workflow とは何か

Alfred というと黒い小さな入力フィールドがスッと出てきて、そこで色んなものをインクリメンタルサーチできるもの、というイメージが強いけれど、実際のところそれだけにはとどまらない。 Alfred Workflow をざっくり言えば、あるアクションを trigger し、 input を行い、それを受けて何らかの action を実行し、 output を出す、という4段階の流れを組み合わせることで、様々なツールを実現するもの、ということになる。

trigger は読んで字のごとくトリガーで、 workflow を起動する契機になる。「黒い窓」から実行するのであれば、 trigger は設定しなくてもかまわない。 input は入力値で、あのよくある「黒い窓」での検索も input にあたる。正確に言えば、あの検索で選んだ候補が input になる。では input は何に対しての入力なのかと言えば、 action だ。 action が input から要は引数を取って、 URL を開いたり、ファイルを開いたりといったアクションを行う。 output は aciton の結果をどこかへ出力したい場合に使うもの、ということになる。そしてこれら4つは、どれも必須ではない。 action を input 無しに実行することだってできる。

例えば trigger には Hotkey というものがある。読んで字のごとく、任意のキーバインドで workflow を起動する場合に使う。そして action には Launch Apps/Files というアプリやファイルを起動できるものがある。この2つを組み合わせてみる。

これで Command + Shift + g を押すと Gyazo が起動する workflow が出来た。 OS 標準のスクリーンショットを撮るのと似た感覚で、3つのキーを押すだけで簡単に Gyazo が起動できる。

このように、 Alfred で出来ることは「黒い窓」でやることだけに縛られないし、何かを検索してフィルタリングすることも必須ではない。組み合わせ次第で非常に多くの効率化が実現できる。

Hotkey の有効活用

Hotkey を使った例をもう1つ挙げる。

Alfred Workflow は export が可能になっていて、ウェブ上で広く公開されている Workflow がいくつもある。そのうちのひとつ、 Div を重宝している。

同種のツールだと有償の Magnet が有名かもしれない。ウィンドウを画面の右半分、左下4分の1などにスナップさせてくれるツールで、 Magnet と異なるのは Alfred からのコマンド操作になるという点。

使い方は Alfred に div 800 600 とウィンドウサイズを絶対的に指定してもいいし、右半分であれば div right といったコマンドも用意されている。そしてこの Workflow 、コマンドに対して Hotkey を割り振れるよう、あらかじめ blank の領域が用意されている。

僕は Command + Shift と矢印キーの組み合わせで、最大化したり左右半分に寄せたりできるように組んでいる。この Hotkey はグローバルなキーバインドになるので、他のアプリケーションと重複しないよう、3キー程度の組み合わせにするのが無難だと思う。

webhook を飛ばす

最後にもう1つ、 Hotkey 以外での使い方も紹介する。

僕はタスクやメモに Dynalist というアウトライナー、要はツリー構造のエディタを使っている。

この Dynalist に inbox という機能がある。ツリーのある階層を inbox に指定すると、特定の webhook に投げた文字列がすべてその階層直下に保存されるというもので、例えば fav した Tweet を投げ込むフローを組んだりだとか、いろいろ応用ができる。

日頃仕事や勉強中に、わざわざ Dynalist を開いてメモするのは面倒なので、これも Alfred から投げられるようにしている。

Hotkey を trigger にしているが、その次の Keyword と書かれているのは input に当たり、要するところ、これがあの「黒い窓」を使った入力ということになる。この設定では Hotkey でもこの Workflow は起動するし、 input の上部に書かれた di というキーワードを Alfred に打つことでも起動する。

「黒い窓」の入力を受けて、次の Run Script が action に当たる。自由に bash コマンドを実行できる。

ここで入力を {query} として受けて、 webhook を飛ばしている。

最後の Post Notification と書かれているのが output に当たり、 macOS の通知に curl の実行結果を表示させている。これはあっても無くてもいい、保険のようなものではある。

これは「黒い窓」を使う Workflow ではあるが、しかし検索は行っていない。単なる入力用のフィールドとして、あの窓を使うこともできる。

Conclusion

ということで、結構いろんなことができる。ここで挙げた以外にも trigger , input , action , output には様々な種類があるし、それらを組み合わせることのできる utilities というものも存在する。まぁ、スクリプトが実行できる時点で何でもありではある。

ちなみにいわゆるよくある「黒い窓」で検索をするやつ、あれは Script Filter という input に該当する。 Script Filter の中で bash や python などのスクリプトを書き、決まった形式の JSON を出力するようにすると、あの検索が発動する。なので前回エントリーのように、動的に検索対象を引っ張ってくることもできるし、固定的な値から検索したいのであれば、 JSON を cat するだけでも OK だ。 HTTP status code の一覧を検索できるようにしたら便利かな、とか今は考えている。

alfred-terraform-cloud-workflow を alfred-tfcloud-workflow に名称変更しました。（追記ここまで）

この記事は Terraform Advent Calendar 2020 5日目の記事です。

Terraform Cloud がフルリリースされて1年あまり経過しました。僕はこの1年だいぶ便利に使わせてもらっていて、 state file の保存のみならず、チームで共有する private module の管理のほか、 Terraform の実行も現在は Cloud 上ですべて賄っており、手で terraform apply を打つ機会もほとんど無くなりました。

そんな便利な Terraform Cloud ですが、現状 UI はウェブのみとなっており、 hashicorp が得意とする CLI は用意されていません。そのため画面ポチポチクリック業がそれなりの頻度で発生しており、地味にストレスになっています。そこで macOS 用のランチャーアプリである Alfred を使って、一部機能を検索、操作できるようにしてみました。

alfred-tfcloud-workflow

Alfred には有料版 (Powerpack) 限定で、 workflow という拡張機能があります。これはデフォルトの検索機能に加えて、自分で任意の検索コマンドをスクリプトで組んで追加できるというものです。今回はこれを活用して Terraform Cloud の検索用 workflow を作成しました。 GitHub で OSS として公開しているので、手元の Alfred でも使っていただけます。

動作イメージは GIF で見てもらうと早いかと思います。

こんな感じで Alfred で検索して、該当の URL をサクッと開くことができます。検索可能なのは workspace 、 private module registry 、 run の3つです。 run はあまり耳馴染みがないかもしれませんが、 Terraform Cloud 上で実行される plan, apply がこう呼ばれます。この Alfred workflow では、実行中の run 、要するに承認待ち状態のままになっているものを検索可能としています。 Terraform Cloud 上での plan は実行に時間がかかることも多いので、いつでもサッと開けるようになっていると非常に便利です。

使い方

以下のレポジトリの Releases から、最新の .alfredworkflow ファイルをダウンロードして、 Alfred へインポートしてください。

https://github.com/chroju/alfred-tfcloud-workflow

インポート後に変数の設定が必要です。 Alfred の Preferences を開き、 organization に検索対象とする organization を設定してください。 organization はここで決め打ちとなるため、複数の organization を動的に切り替えて検索することには現在対応していません。

もう1つ、 TF_CLI_CONFIG_FILE という変数も用意されています。こちらは Terraform における同名の環境変数と同じものです。この workflow は $HOME/.terraformrc から API token を読み込んで使用しますが、別のパスのファイルを使いたい場合は、ここに設定します。パス変更が必要ない場合は空欄で大丈夫です。

これでセットアップは完了です。 tfcws で workspace 、 tfcmd で private module registry 、 tfcruns で run がそれぞれ検索できるようになったはずです。

なお、先のサンプル GIF では Terraform のロゴが設定されていましたが、配布の workflow にはライセンスの関係でロゴ画像は含めていません。お好みでご自身で設定してください。

内部実装 : tfcloud

ここからは内部実装の話をします。

とはいえ、ここで Alfred workflow の作り方を長々説明するのはアドカレの趣旨に反すると思いますので、その点は割愛します。ざっくり説明すると、 Alfred が定めるフォーマットで JSON を食わせると、あのインクリメンタル検索の候補として流れるという、それだけです。従って原始的な実装であれば、 curl で Terraform Cloud の API をたたき、結果を jq で整形するような形でも workflow は作成可能です。ただそれでは面白くないなという思いもあり、今回は go で Terraform Cloud の CLI ツール tfcloud を作って中で実行しています。

https://github.com/chroju/tfcloud

この CLI ツールは単独でももちろん利用可能です。普通に使う分には出力も human readable な形ですが、一部コマンドについて、隠れオプションを渡すことで Alfred に適合した JSON 形式で出力するようになっており、この仕組みを workflow 内部で呼び出しています。先ほど掲載した workflow は tfcloud のバイナリを内包した形で配布しているので、別途インストールは不要になっています。依存関係をあまり気にせず、ワンバイナリで配布できる Go は、こういう場面で便利ですね。

tfcloud だけの機能

tfcloud を単独でも使ってみたい場合は、 brew install chroju/tap/tfcloud でインストール可能です。

tfcloud には少しだけ、 CLI 版でしか実行できない機能も存在しています。個人的に推したいのは、 Terraform Cloud workspace の Terraform version をアップグレードする機能です。

Terraform Cloud では各 workspace 個別で Terraaform version を設定する必要があるため、メジャーバージョンアップの際などに数十の workspace を GUI でポチポチと upgrade して回らなくてはならず、かなり骨が折れます。 tfcloud workspace upgrade コマンドを実行すれば、カレントディレクトリに紐付いた workspace の Terraform version を CLI からアップグレードできます。

このように -u オプションでバージョン指定して upgrade もできますし、指定しなければ自動的に最新が当たります。ただし、 required_version と整合性がとれないバージョンには上げないようになっています。オススメの使い方は、 tfcloud workspace list で各 workspace の Terraform version が一覧できるので、これと併用してバージョンアップを進めることです。

このほかに、 remote backend の記述内容を元にして、 workspace をイチから自動作成するようなコマンドも実装を検討しています。

Terraform Cloud / Enterprise API

なお、 tfcloud がやっていることは、単純に Terraform Cloud の API を叩いて、結果を整形して出力しているだけです。

Terraform Cloud の API は、 Terraform Cloud / Enterprise API という形で提供されています。Terraform Enterprise の SaaS 版にあたるのが Terraform Cloud と言えるようで、両者の API は共通しています。 Go による API ライブラリも hashicorp から提供されており、その名も go-tfe と、 Enterprise 由来のものになっています。 tfcloud もまた、その名に反して Enterprise でも動作するはずですが、筆者は Enterprise の使用経験がないため、試してはいません。

Terraform Cloud / Enterprise API （以下、 tfe API） は GUI におけるほとんどの機能を実装していますが、1点だけ Registry Modules API のみ、以下のようにちょっと癖があります。

• tfe API は Registry Modules API を一部しか実装しておらず、一部は Registry standard API (public な Terraform Registry の方) を踏襲している。
• 残念ながら go-tfe は Registry standard API 踏襲部分については実装がない。
• Registry standard API に対する Go のライブラリは提供されていない。
• tfe API と terraform registry API では、出力フォーマットの JSON 形式が異なる。
• tfe API と terraform registry API では、 API endpoint の URL も異なる。

ということで、 registry 周りの API だけ一部自分で実装する羽目になりました。これについては issue も上がっていますが、 go-tfe で対応しないとしても、 Registry standard API 用のライブラリを別途リリースしてほしいところです。

Conclusion

以上、 Alfred や CLI から Terraform Cloud を操作できるようになるまでを簡単にご紹介しました。アドカレの〆切駆動で開発したので最後はかなりギリギリで作っており、粗もあるかと思いますが、何か気になることがあれば issue や PR をいただけるととても嬉しいです。

ただ CLI を得意とする hashicorp ですので、どこかのタイミングで公式の CLI が出てくれないかな、とはちょっと期待しています。

Caravelle-BLE という自作キーボードキットを組んだ。

昨年12月からずっと Corne Cherry に IMK corne case を合わせたものを使っていてかなり満足していて、今年買ったキーボードキットはこれが初めて。

Caravelle-BLE は昨年リリースされたキーボードキットで、当時から欲しいとは思っていた。ポイントとしては分割かつ、 Bluetooth Low Energy (BLE) を使った無線通信にデフォルトで対応していることと、3Dプリンタ製のケースが付属していること。自作キーボードキットは多くの場合、キースイッチをはんだ付けした基盤に、同サイズのプレートを表裏それぞれにネジ止めした「サンドイッチ構造」と呼ばれるつくりをしている。この構造はシンプルなのだが、基盤とプレートの間にほこりが入りやすいだとか、打鍵感や打鍵音が損なわれるという弱点がある。ケースで側面を覆えばこれは解消されるのだけど、立体造形は少し手間が要ることもあってか、キットに同梱されていることは少ない。 Caravelle-BLE はこれを同梱しているという点で珍しく、興味を持った。

昨年の初期ロットは早々に売り切れていて、それ以来諦めていたのだが、先日たまたま在庫があるのを見つけて購入した。

build log

久しぶりにキットを組むので少々手こずった。特に BLE 対応のキーボードは初めて組むこともあり、コンデンサのはんだ付けなど、慣れないことも多かった。

基本的にはマニュアル通りに進めれば難易度はそれほど高くないと思うが、1点だけ、3Dプリントされたケースのネジ穴に「バリ」と言っていいのか、些末なプリント素材が詰まっていたのがイレギュラーだった。ピンセットなどで軽く力を入れればパキパキと取れるので、ネジ止めの前に穴をきちんと確認すればつまずくほどのこともないと思う。

また、 Bluetooth 接続は出荷時にファームウェア設定済みで、マスター（左手側）とスレーブ（右手側）が同時起動した時点で双方が接続され、マスターが PC と通信する、という形を取る。マニュアルにはスレーブ、マスターの順に接続確認をするよう書かれているが、同時に電源を入れてしまうとスレーブは PC と接続できなくなってしまうので注意したい。僕は当初このあたりに手こずったが、幾度かマスター、スレーブ双方のペアリング設定をリセットすることでうまくいった。

キースイッチ

基本的にはリニア、修飾キーなどの一部だけタクタイルにするハイブリッド構成が好きで、リニアは Gateron Ink Black 、タクタイルは Zilent V2 を好んでいるのだが、今回は気分を替えて前者を Alpaca にしてみた。 Gateron Ink Black とカタログスペック上の押下圧はほぼ変わらないのだけど、打鍵感は軽めに感じられる。底打ちしたときに軽快な音がするのが心地よくてわりと好き。

ちなみにキーキャップは手元にフルで合うものがなかったので適当にはめている。 GMK Modern Dolche 2 の GB に参加しているので、届いたら差し替えたい。

印象

まだ半日しか経っていないので何とも言えないところはあるが、無線だと机上がスッキリして想像以上に気分がいい。打鍵感もかなり良く、無線通信にも目立った問題は感じていない。たまに左右で意図した順序と逆に（スレーブ側が遅れて）入力される感覚があるので、パラメータを少し調整するかもしれない。

キー数は Corne に親指部分左右1つずつ、人差し指の内側に左右2つずつの計6キーを追加した形で、まだ若干持て余している。人差し指内側のキーについては Corne でもほしい、括弧を割り当てて使いたいと思っていたので念願なのだが、まだ指が慣れずにいる。慣れれば便利ではあると思う。また、キーマップもほぼ Corne のものを使い回せたので、すぐに割り当ては終わった。

それにしても、これほど完成度が高く高機能なキットが14400円（本記事執筆時点）というのは、自分の感覚が麻痺しているわけではなくどう考えてもお買い得。購入できて本当によかったし、末永く Corne と一緒に使っていきたい。

マルチディスプレイは要らなかった

元々、部分的なリモートワークが OK な会社だったので、家に作業可能な環境は元々あるにはあったのだが、1日8時間労働を週5で続けるとなると粗が見えてくるもので、様々なものを買った。今後会社が替わっても、業種が替わらない限り WFH は長く続きそうだし、思い切ってお金を費やしていった。その中でも大きかったのがディスプレイと椅子。

ディスプレイは24インチ WQHD から、27インチ 4K に替えた。 DELL の U2720Q という、よく売れていそうなモデル。 Amazon 限定で U2720QM という、付属ケーブルだけが異なっていて少し安いモデルがあるので、そちらのほうが売れているかもしれない。僕が買おうとしたときには売り切れていたので、 U2720Q のほうを DELL 直販で買った。決め手は解像度はもちろん、 USB Type-C 1本で映像出力と給電双方が取れること。ずっと作業していると、ケーブルを少しでも減らしたい欲求が強くなり、 MBP に Type-C 1本挿せば OK という環境を整えた。

このディスプレイを買って以降、 MBP はクラムシェルモードで使っていて、マルチディスプレイはすっかりやらなくなってしまった。就職してから10年ぐらい、マルチディスプレイは必要不可欠だと思っていたのに、どうもそうではなかったらしい。解像度の高いディスプレイの中で複数ウィンドウを並べるほうが、物理的にディスプレイを並べるよりも机がスッキリするし、視線移動も少なくて済むので、集中力も削がれにくいことに気付いた。

ちなみにウィンドウの配置には Alfred の Div というプラグインを使って、キーボードだけでシュッと並べられるようにしている。

WORKAHOLIC で椅子を買った

椅子はイトーキの YL8 という3万円ぐらいのものを使っていたのだが、バロンチェアこと、オカムラの Baron に乗り換えた。

馬喰町にオフィスチェア専門のセレクトショップ WORKAHOLIC という店があり、そこで実際に試しながら買った。来店予約のときに、使っている机の高さ、天板の厚さなどを伝えると、それに合わせた状態の昇降デスクを用意して待ってくれるので、椅子と机を合わせたときにどういう状態になるか想像しやすく、体験がよかった。今は2時間の時間制になっているので、ある程度見たい椅子に目星をつけて行かないと時間が足りないかもしれない。2時間、手当たり次第に試していると、意外にすぐに過ぎる。なお、品揃えは楽天でチェックできる。

Baron の決め手は結構細かいところで、アームレストが内側60度まで曲げられるがために、机に思いっきり近づいたり、体勢の自由が利くことが大きいポイントになった。アームレストで肘を支えましょうとはよく聞くのだが、アームレストが天板とつっかえて、机と距離が離れることになり、上手くキーボードの位置と合わせて使えないのが今まで不満だったのだ。WORKHOLIC で正しい座り方を教えてもらったところ、やはりアームレストをちゃんと使って肘を支え、肩の力を抜くべきだという。そしてアームレストと机の高さを合わせることで、足裏が宙に浮いてしまうならば、フットレストを使って調整する。この座り方を徹底し始めたところ、集中力が持続しやすくなった。

以下の記事にも、この「正しい座り方」が解説されている。

https://www.itmedia.co.jp/bizid/articles/0902/19/news115.html

通勤時間による脳の GC

「脳のGC（ガベージコレクション）」という言葉は 「サウナは、脳のガベージコレクション」。エンジニア兼サウナ経営者が、サウナの魅力を徹底解説！ | アンドエンジニア から拝借した。僕もサウナや銭湯は好きで、頭の中を整理する時間に使うことがある。難点はいいアイディアを思いついても上がる頃には忘れがちなことで、裸で走ったアルキメデスは圧倒的に正しかったんだなとしみじみ感じている。

しかし風呂に行かずとも、自分にとって通勤時間がわりと「脳のGC」になっていたなと思う。勤め先は都内なので、会社から歩いて1分、10分、15分という具合に3つぐらいの駅を選ぶことができて、ちょっとモヤモヤしている日は遠めの駅まで歩きながら頭を整理することがよくあった。それでもどうにもならなさそうな日は、答えを求めてそのまま本屋に寄ったり、ノートに書き出すためにカフェに寄ったり。

WFH になって、そういう時間はすべて失われてしまった。仕事が終わるとすぐに「今日の夕食は何にしよう」という次の思考が始まってしまい、休まることがなくて、一時期は結構疲弊していた。仕事をする場所とプライベートな場所が同じなので、その間がシームレスで脳が動き続ける。通勤の時間は、緩やかに「仕事モード」から「プライベートモード」へ繋ぐ役割を果たしていた。

最近は終業後に一度散歩することを習慣化し始めた。これでまた「脳のGC」が進むようになったし、仕事を終えたことの区切りもつけられるようになった。

WFH がオフライン出社をすべて置き換えるわけではない

WFH は好きなのだけど、会社でやっていたことを全部置き換えるものではないと悟った。それは諦めた。

具体的には、複数人で意見を出し合ったり、何かを検討するような場にはあまり向いていない。例えば OKR をチームで設定するときなど、付箋で大量に意見を出して、ホワイトボードに並べながら検討することが多いのだが、これをオンラインで再現するのはなかなかに難しかった。

ということで、チームでグループワークが必要な際には基本的に物理出社するようになった。たまに物理出社して、リアルな場で MTG をすると、普段 zoom などで会話するのに比べて受け取る情報量が圧倒的に多いことを強く感じる。微妙な表情の変化やしぐさなどから、「あれ？○○さん何か納得できてない感じ？」って話を振るようなことがオフラインでは可能だけど、 オンラインだと容易ではない。あまりこういう抽象的な言葉を使うのは好きではなかったのだが、どうしても「場の空気」というものは存在するし、それはオンラインでは感じ取れないものだったりする。

もちろん、フルリモートで維持されている開発組織があるのも知っているのだけれど、自分の場合は合わなかった。ならばそこは柔軟に、「WFH を諦める」部分があってもいいんじゃないかと思っている。

WFH がすべての人に適しているわけではない

そして当然ながら、 WFH は誰もが肯定するものではない。僕は大好きだが、他の人が周りにいないとなかなか調子が出ないんだよね、って人も中にはいる。

だから WFH にせよオフィスで働くにせよ、どちらの方式でも強制はしたくないな、と強く思っているし、妥協点は常に探らなければならないと感じている。誰もが自由にしていいよ、というのもちょっと違うと思っていて、周りが誰も出社していないのに自分が出社しても仕方がない、ということもある。それであれば週に1回はチームで出社するだとか、別の方策を探さねばならない。

『リモートワークの達人』

https://www.amazon.co.jp/dp/4150505608

「リモートワークの達人」を読んだ、そして悔しい思いをした - Magnolia Tech で話題になっていたので、僕もこの本を読んでみた。たしかにリモートワークに必要なことは全部書いてある、って言いたくなるような本だった。

何より、「全部常にリモートワークで回るよ」という全肯定ではなくて、働き方をフレキシブルにするとよい、ということに力点が置かれている点がよかった。集中したい時間はリモートで、それが終わったら出社するような、ハイブリッドな働き方を認めている。コロナ禍、特に緊急事態宣言の最中では完全リモートワークがやむなしだったが、今後長く感染症と付き合う上では、ハイブリッドが妥当な選択肢になっていくんじゃないかと思う。

自分の場合では、総合的には QOL が上がったと感じている。通勤時間がなくなって、時間を自由に使える幅が広がったこと。家事を回しやすくなり、平日はほぼ毎日自炊するようになったこと。おかげで家にいる時間をもっと充実させたくなって、実家を出て10年ぐらいして、おそらく初めて食器を買ってみたりもした。買ったのは波佐見焼の食器で、 xx 焼と付くような焼き物はもっと渋いイメージをしていたのだけれど、モダンな感じですごく気に入っている。食器に関する知識が広がって嬉しかった。

今後 WFH が一般化するのかはよくわからない。 IT 系以外の業界だと、すでにその比率はかなり下がっているようにも感じるし、 IT 系であっても、コロナ禍が過ぎ去ってからも続けるかどうかはまちまちだろう。でも、僕としてはこのフレキシブルな状況が続いてほしいと思っている。そして WFH のやり方は今後もずっと模索を続けるんだと思う。もっとも、それはオフィスで働く場合と、変わらないという話でもあるけれど。

https://aws.amazon.com/jp/about-aws/whats-new/2020/05/introducing-amazon-eks-best-practices-guide-for-security/

EKS と銘打たれている通り、 Kubernetes ではなく EKS にフォーカスした記述は少なくない。例えば暗号化についての項では、 Nitro におけるトラフィックのデフォルト暗号化に触れていたりする。しかし大半は Kubernetes あるいは Docker そのもののプラクティスになっていて、 EKS に限らずとも、 Kubernetes 使用者にとって学べることは多い。内容は Identity and Access Management に始まり、 Pod や Network 、 Runtime といった各要素のセキュリティプラクティスを俯瞰し、 PCI DSS のようなコンプライアンス関係についても少し記述を割いている、かなり包括的な内容となっている。

すべてオープンソースでの公開となっており、 https://github.com/aws/aws-eks-best-practices から issue や Pull Request を出すこともできる。また、 for Security と銘打っている以上、他にも for XXX が続くのではないかと期待されるところだが、レポジトリに GitHub Project が設けられており、そこから Performance 、 Reliability 、 Cost Optimization などが計画されていることが垣間見える。つい先日は for Cluster Autoscaler が追加された。個人的に、 AWS のドキュメントを読んで組めるのは「とりあえず使える Kubernetes」であり、そこからプラスアルファで行うべきプラクティスは非常に多く、なかなか捉えどころも難しいように感じている。何年か前の状況に置き換えると、 EC2 で nginx と Rails を動かすだけならそれなりに簡単だけど、セキュリティグループや LB をきちんと扱えているか、 Scaling をどうするのかといった非機能的要件になると話が変わってくるようなイメージだ。それがオフィシャルな Best Practices としてまとまり、さらにオープンに編集可能というのは非常に嬉しいことだなと感じている。

以下、自分が読んだ中でメモした箇所をいくつか挙げておく。

• Pod Security
  • コンテナイメージに shell を入れるべきではない
    • sh ぐらいは入れていることがあるので、そこまで徹底出来る方が確かに好ましそう
  • Pod Security Policy
    • https://kubernetes.io/docs/concepts/policy/pod-security-policy/
    • root での起動を許可しないなどいくつかルールを定め、そのルールに従った Pod 以外は起動できなくするもの
    • まだ beta だが使ってみたいところ
• Multi-tenancy
  • Namespace を使った Soft multi-tenancy や、 cluster 自体分離する Hard multi-tenancy について説明されている
    • 個人的には Soft で限りなく済ませておきたい気持ちが強い
    • Kubernetes Multi-Tenancy – A Best Practices Guide | Loft Blog あたりも参考に
• Detective Controls
  • audit log の解析や監視
  • 同様に CloudTrail log も
  • 地力で監視するのはどう考えても大変なので自動化して何か考えたいが。。
• Infrastructure Security
  • aquasecurity/kube-bench: Checks whether Kubernetes is deployed according to security best practices as defined in the CIS Kubernetes Benchmark
    • CIS Kubernetes Benchmark に則っているかチェックしてくれるツール
  • Amazon Inspector の活用
• Incident response and forensics
  • 実際にセキュリティインシデントが発生したら、どう対処するか
    • Network Policy を使った通信の遮断
    • 該当 node に対して cordon を実施
    • 問題のある node や pod に label を付与してわかりやすくしてから対処する
    • などなど
• Image Security
  • 大原則として、余計なソフトウェアなどは極力入っていないことが望ましい
    • 可能であれば FROM scratch する
  • wagoodman/dive: A tool for exploring each layer in a docker image などを使ってイメージを縮小する
  • projectatomic/dockerfile_lint を使って Dockerfile に lint をかける

キャリアパスの必要性

キャリアパスの必要性を感じたきっかけとしては2つある。

• チームリーダーになった
• ストレスチェックで、キャリアパスを描くことを推奨された

1点目がもっとも直接的な動機であって、チームリーダーという立場になった。マネジメントというほど大仰なものを担っているわけでもないのだが、チームのディレクションなどが必要な立場と言える。するとチームをどうしたいのか？という命題を考える必要が出てきて、そもそもじゃあ自分は今後どうしたいのか？ということも考える必要があるんじゃないかと考えた、という具合。

2点目、会社で受けるストレスチェックというものがあると思うが、あの中で自己肯定感の低さによりストレスを受けている状態にあると診断された。自己肯定感が低いこと自体はもとより自覚はしているのだが、対策として「キャリアパスを作る」ことが挙げられていたのが目を引いた。キャリアパスと自己肯定感がどう結びつくのかいまいちわからなかったのだが、目標を明確化して、そのプロセスを辿っていることを自覚することにより、自己肯定感を高めることができるらしい。「技術書典6」で購入した『理論と事例でわかる自己肯定感』という本にも言及があった。確かに、今学んでいることや、今の業務が、自分にとって長期的に重要なことなのかどうか、思い悩むことが多く、自分の成果に自信を持てないことは少なくなかった。

「これでよい」気持ちは、結果よりもプロセスを実感していることが影響します。例えば、将来への目標を持っていると感じること、成長への努力をしていると感じていること、といったことです。 [^1]

という経緯があり、今までは技術的な興味と、実際の仕事を経て「解決したい」と考えた問題とをベースにキャリアを積んできたのだが、30歳も過ぎたことだし、キャリアパスを今一度考え直した。

キャリアパスの描き方

ソフトウェアエンジニア向けのキャリアに関する本を何冊か読んではみたのだが、正直キャリアパスはこう作ろう！みたいな本はあんまり見つからなかった。ベストセラー『SOFT SKILL』では「自分のキャリアから何を手に入れたいのか。5〜10年後の自分をどうしたいのか。少し時間をかけて、そのことについて考えてみよう」[^2]という記述にとどまり、それをどう描いていくか詳しくは言及がない。他の本などでも、だいたいは「5年後どうなりたいのか考えてみましょう」みたいな内容で、「いや、特にないんですけど」という人に対する処方箋は乏しい。

https://www.amazon.co.jp/SOFT-SKILLS-%25E3%2582%25BD%25E3%2583%2595%25E3%2583%2588%25E3%2582%25A6%25E3%2582%25A7%25E3%2582%25A2%25E9%2596%258B%25E7%2599%25BA%25E8%2580%2585%25E3%2581%25AE%25E4%25BA%25BA%25E7%2594%259F%25E3%2583%259E%25E3%2583%258B%25E3%2583%25A5%25E3%2582%25A2%25E3%2583%25AB-%25E3%2582%25B8%25E3%2583%25A7%25E3%2583%25B3%25E3%2583%25BB%25E3%2582%25BD%25E3%2583%25B3%25E3%2583%25A1%25E3%2582%25BA-ebook/dp/B01GDS0994

この観点で最も参考になったのが キャリアに関するセルフコーチングのやり方｜こばかな｜note というエントリー。詳細はリンク先を読んでもらいたいが、考え方の1つとして、「思いつく選択肢をとりあえずたくさんあげてみ」るというものがある。「5年後どうなりたいか」に答えにくいのは、これがオープンクエスチョンであるからであり、ではそもそもどんな選択肢があり得るのかをまず出してみることにより、この問いはクローズドクエスチョンに変化する。

また、選択肢を書き出すことによって、そもそも選択肢が少ない状態にあることにも気付ける。すると、まずは選択肢を増やそう、例えば世の中で自分の5歳ぐらい上のエンジニアで有名な方はどのようなキャリアを築いているのか調べてみよう、といった具体的行動に変化できる。

キャリアパス、キャリア戦略

もう1つ引きたい記事がある。

https://www.lifehacker.jp/2014/10/141030strategy.html

ここではキャリアパスではなく、「戦略」という言葉が使われている。パスを思い描くだけで完結せず、そのパスを実現するためにどういった能力を得て、どうやって戦うのかという「戦略」まで言及されている。

戦略と言うと、ルメルトの『良い戦略、悪い戦略』[^3]という本が好きだ。この本は基本的には経営的な目線ではあるが、個人や小規模なチームの活動にも応用できる内容なので、非常におすすめしたい。ざっくり言ってしまうと、良い戦略は状況の「診断」、それに基づき「基本方針」の決定、基本方針を実行するための具体的な「行動」の3つから成るという内容で、状況をきちんと分析して重大な問題を見極めることと、そこにリソースを集中的に投下する重要性を説いている。

https://www.amazon.co.jp/%25E8%2589%25AF%25E3%2581%2584%25E6%2588%25A6%25E7%2595%25A5%25E3%2580%2581%25E6%2582%25AA%25E3%2581%2584%25E6%2588%25A6%25E7%2595%25A5-%25E6%2597%25A5%25E6%259C%25AC%25E7%25B5%258C%25E6%25B8%2588%25E6%2596%25B0%25E8%2581%259E%25E5%2587%25BA%25E7%2589%2588-%25E3%2583%25AA%25E3%2583%2581%25E3%2583%25A3%25E3%2583%25BC%25E3%2583%2589%25E3%2583%25BB%25EF%25BC%25B0%25E3%2583%25BB%25E3%2583%25AB%25E3%2583%25A1%25E3%2583%25AB%25E3%2583%2588-ebook/dp/B087X4WJLR

僕のキャリアパスに関する悩みの出発点は、自己肯定感の欠如だった。それを埋めるのに必要なのは、単なるキャリアパスというより、自身の行動が確固たる戦略に基づいているという確信なのではないかと、ここまで考えていて思い至った。まぁもちろん、キャリアパスを描くだけで満足して終わる、という人もいないだろうが、方向性を作った上で、戦略を描いてそれに取り組んでみて、初めて自分の目的は達成できそうだ。

『良い戦略、悪い戦略」では、戦略とは「仮説」であるとも書かれている。つまり、短期間でその有効性の検証と修正が必要ということだ。パスや戦略を描くのがゴールではなく、それが常に自分にとって意味のあるものになっていることを確認し直す作業も必要になる。

SRE のキャリアパスを考える

ソフトウェアエンジニアのキャリアには、スキル上の選択肢と、事業上の選択肢の2つがあると捉えている。技術 or マネジメントというような、よく言われる2択や、フロントをやめてバックエンドやります、みたいな話は前者だ。その技術を持ってどの会社にコミットしたいのか、というのが後者になる。

特にプログラマーであれば、開発したいプロダクトという事業の選択も描きやすいかもしれない。 SRE はプロダクトサイドからは少し離れる（という言い方は適切ではないかもしれないが）ことも多いので、こんなサービスを作りたい、という事業的なビジョンと職務が直結させづらいと感じることもある。ただ、金融業なのか、ゲーム関係なのかなど、携わる事業によって SRE が注力するべきポイントと、求められる信頼性は大きく変化するので、事業の選択肢もまったくの無関係ではない。僕は金融系の経験が長く、ミッションクリティカルなシステムの運用には長けているが、今後もそのキャリアを積みたいかと言えば No だったりする。

また事業領域という点では、サービス運営ではなく、プラットフォーム側、つまりはクラウドサービスや CDN などの中の人になる道も、インフラ系のエンジニアには存在する。この場合は SRE という肩書きではなくなるが、 SRE から選ぶ道としては現実的な線だろう（現に知人でも何人かいる）。

実際にキャリアパスと戦略を考えてみる

最後に、ここまで書いたことを受けて、自分でもろもろ実際考えてみたキャリアのことを書き連ねて終わりたい。正直なところ、まだまとまりきってはいないのが現状だ。

• 自分の価値観
  • 自身の知識と技術を源泉として対価を得たい
    • 労働時間や年齢などを根拠とした対価を得たくない
    • 常に知的好奇心を満たしたい
    • その時代にあった知識へ常にアップデートを続けていたい
  • インターネットの自由を重要視したい
    • 使い方を狭めたり、ユーザーの自由を奪ったりする方向へは進みたくない
    • ユーザーがインターネットを通じて、情報を得られる、発信できる自由を尊重したい
• キャリアパスのスキル的な選択肢
  • SRE としてスペシャリストになる
    • SRE 方面の技術に長けた存在になる
    • SRE のプラクティス実践に長けた存在になる
  • エンジニアチームのマネジメントキャリアを進む
  • プラットフォーム側のエンジニアになる
    • AWS の中の人など
    • 経験として興味はあるが、現在は SRE でプロダクトに責務を負うほうが関心が強い
  • SRE 以外のエンジニアルートを進む
    • 現状、 SRE でいることに不満などはなく、あまりこの道は考えていない
    • 強いてあるとすれば、 SRE として必要なプログラミングスキルを磨くために、期限付きでサーバーサイド等をやる
  • 現在大学進学しているので、その道を究めて研究職へ進む
    • 現実的な道だとは捉えていない
• 事業的な選択肢
  • 文化、芸術、学術とインターネットを絡めた事業に携わっていたい
    • 現在は教育関係のサービスに携わっており、マッチしている
    • 「インターネットの自由」というキーワードを念頭に置きたい
    • まだ深掘りができておらず、具体的にどういったサービスに今後携わりたいかは常に考えたい
• 直近の方向性
  • 35歳を1つの区切りとして捉えつつ、 SRE として高いレベルに達していたい
    • 組織に SRE を導入し、立ち上げ、サイクルを回していく一連の過程を自分が再現できるようにしておきたい
      • そのスキルをもって、やりたい事業があれば SRE として瞬時にコミットできる人材になりたい
      • SRE のプラクティスを組織横断的に適用するためのヒューマンスキル
    • インプットとアウトプットをより高いレベルで行っていきたい
      • 英語の習得（英語が出来るだけで、アクセスできる情報量は格段に多くなるので、レバレッジが高い）
      • プログラミングスキルの向上、それに伴い OSS への contribution
        • OSS は「インターネットの自由」の1つでもあり、 contribution は常に続けたい

[^1]: 川鯉光起, 尾澤愛実, 福本江梨菜, 納富隆浩, 浜崎誠, 小笠原晋也. 理論と事例でわかる自己肯定感. 第2版, 教育心理学を学ぶ会, 2019, p.8. [^2]: John Z,. Sonmez. SOFT SKILLS: The software developer's life manual. Manning Publications, 2015. (ジョン・ソンメス, 長岡高弘(訳). SOFT SKILLS ソフトウェア開発者の人生マニュアル. 日経BP社, 2016, 第3章.) [^3]: Richard P. Rumelt. GOOD STRATEGY, BAD STRATEGY: The difference and why it matters. Crown Business, 2011. (リチャード・P・ルメルト, 村井章子(訳). 良い戦略、悪い戦略. 日本経済新聞出版社, 2012, 410p.)

10月1日より、 GitHub で新規レポジトリの default branch が main に変更される。この設定はオプトアウト可能であり、ユーザーや organization それぞれで必要に応じてあらかじめ設定しておく必要があるわけだが、みなさま確認はお済みだろうか。

default branch 名として master を使うことの是非の話はさておき、今後は default branch がレポジトリによって多種多様になる可能性が高い。これまでは何も考えず git switch master を打っていた操作が、レポジトリごとに「main だっけなんだっけ」みたいな思考を挟まなくてはならないのはさすがに面倒である。ということで、 default branch を少なくともローカルでは意識しない生活を送ることにした。

default branch をコマンドで取得する

端的に結論から言えば、 git symbolic-ref --short refs/remotes/origin/HEAD を打てばよい。

$ git symbolic-ref --short refs/remotes/origin/HEAD
origin/master

具体的にこれは何をしているかと言えば、 .git/refs/remotes/origin/HEAD から情報を取得している。 .git/refs は git レポジトリ内の各種参照情報が格納されたディレクトリであり、その中でも .git/refs/remotes には追跡ブランチの情報が格納されている。例えば追跡ブランチ origin/hoge が存在すれば .git/refs/remotes/origin/hoge ファイルが存在し、その内容は origin/hoge の最新 commit hash となっている。 .git/refs/remotes/origin/HEAD はリモートリポジトリの HEAD が参照するブランチの情報が格納されており、つまるところここから default branch が取得できる。

ファイルを直に cat しても値は取得できるが、安全性を鑑みて .git/refs 配下を触る場合は git symbolic-ref コマンドを使うことが推奨されている。このあたり、詳しくは以下の記事を参照した。 Git に関してはこの git book を読めばだいたい解決すると認識している。

参照 : Git - Gitの参照

default branch へ switch するサブコマンドをつくる

default branch の取得方法がわかったので、あとは好きにこれを使えばいいのだが、僕の場合は git switch master が一番よくつかうコマンドだったので、これを改め、 git default コマンドで default branch へ switch できるようにした。

git には、 PATH が通った場所に git-hoge の命名規則に沿ったコマンドがある場合、 git hoge のサブコマンド形式で実行できるようになるという性質がある（参考 : gitのサブコマンドを自分で作る - blog.ton-up.net）。これを利用して、 /usr/local/bin/git-default に以下のスクリプトを書いて保存した。

#!/bin/bash
git switch $(git symbolic-ref --short refs/remotes/origin/HEAD | cut -f 2 -d '/')

origin/master という慣れ親しんだものが絶対ではなくなる、と知ったときにはかなり同様したが、まぁ結局のところ名前なんて飾りであるとも思うし、意識しなくて済むものは意識しない形にどんどん持って行こうと思う。

追記 2020-09-22) default branch 変更の手順

そもそもの default branch 変更の手順だが、 branch -m コマンドで master からブランチ名を変更した上で、 push -u origin HEAD した後、 GitHub 側で repository settings から設定変更を行うことになる。

$ git branch -m master main
$ git push -u origin HEAD

ただ、 .git/refs/remotes/origin/HEAD は git clone した際に確定してしまっており、この手順を行っても自動的に GitHub の設定に追従することはない。 symbolic-ref コマンドで別途編集してやる必要がある。

$ git symbolic-ref refs/remotes/origin/HEAD refs/remotes/origin/main

追記2 2021-01-10)

もしくは以下のコマンドでも OK 。

$ git remote set-head origin --auto

（追記2 ここまで）

また、 git init した際の default branch については、 .gitconfig で global に設定できる。

[init]
  templatedir = ~/.gittemplates
  defaultBranch = main

default branch 変更に関しては、 github/renaming で guidance が公開されているので、こちらも合わせて参照したい。

https://github.com/github/renaming

個人で整理したい情報には何があるのか

そもそも何の情報を整理したいんだという話がある。ていうか、なんで情報整理なんてしたいんだという人もいるような気はする。特にデジタルツール使ってなくて、簡単なメモ帳だけ持っててそれで十分やっていけてます、というような人とか。

僕はわりと頭の中でごちゃごちゃと考えるタイプ、人からは時に「頭でっかち」と言われることもあるようなタイプで、あんまり脳の性能が良い気がしていない。タスクがわーっと振ってくるとてんやわんやになって、何をやればいいのかわからず、下手をするとやる気が消失する。逆に、取り組んでいるタスクが興に乗って過度に集中すると、何も書き出さず頭の中でひたすら考えては試しまくる、というようなことをやってしまい、終わって数日経ってから「あのとき何をしたんだっけ？」となることもある。従って、外からインプットした情報、自分の中で考え出した情報を書き留めておく場を常に欲している。書いて考えを落ち着ける、書いて考えをまとめる、書いて状況を整理する、それで初めて行動可能になる、というときがある。

なので、取りあえずメモリをダンプしておくところがほしいというのが1つ。今何やってんだっけ、今何しなくちゃなんだっけ、っていう現在進行形の頭の中をそのまま書き出して取っておくところがほしい。この用途で Dynalist を使っている。そうじゃなくて半永久的に保存しておくようなメモには Scrapbox を使っていて、一部だけ notion を使っている状況。

Dynalist

https://dynalist.io/

アウトライナー。アウトライナー自体それほど知られたツールでもない気がするのだが、文を並べて階層構造をつくったり、並び順を入れ替えたりして整理できるツール、と言えばいいんだろうか。エンジニア界隈で一番有名なアウトライナーは Emacs org-mode な気がする。

冒頭に書いたとおり脳内のダンプ場所という感じ。ちなみに Brain dump っていう、頭の中にあることを全部書き出して整理するメソッドがあるらしいんだけど、そういう一過性のものというよりは、頭の中にあることをここに一度書き出して、脳内の状態と差分が出たら逐次更新して同期するみたいな感じで使っている。たまに訳わからなくなると書き直したりはするけど。

やっていることとしては 様々なTODOアプリやタスク管理方法を試行した結果最終的にプレーンテキストに行き着いた話 - みんからきりまで に近いのかもしれない。結局 TODO アプリって、そのアプリの思想に則ったタスク管理を強いられる側面があるし、タスク以外のちょっとしたメモとか参考資料のリンクなどを上手く保存できるものでもない。そこで柔軟性を鑑みてアウトライナーに行き着いた感覚。僕も昔、テキストファイルでタスク管理していた頃があったけど、さすがに機能が物足りなくてやめたことがあった。 Dynalist だと繰り返しタスクの設定ができて、取り消し線を引くと1週間後に自動リスケジュールしてくれたりとか、 CSS いじれて見た目わかりやすくできたりとか、いろいろメリットを感じている。日付を付与する機能もあって、1週間後までの日付が付いた行とかを検索できて、タスク管理には便利。絵文字も積極的に使って見やすくしている。

もっと言うと その日付をすてろ に書かれていることが一番近い。今やっている、気にしなくてはならないプロジェクトを並べておいて、その中に進捗書いたり、細分化したタスクを並べたりしている。ちなみに上のスクショが現時点の実際の Dynalist で、このブログも「memo ツールのブログを書く」の階層配下に直接書いているところ。

「今日」やることは1個「Today」という階層を掘り下げてそこに並べて区別している。1日の始まりに「Today」の中にタスクを書き出す。日中はそれを見つつ、上の階層にあるプロジェクトを広げてメモを取ったりする。終わったタスクは順次取り消し線を引く。1日の終わりに、終わったタスクは消して、残ったタスクは次の日に持って行くか、さらに数日送るのあれば日付だけくっつけて一旦「icebox」階層に移動させる（Trickler file を意識している）、要らないものは消す。そういうサイクルでやっていっている。

「Today」の中はメモを放り込む場所でもあって、水平線の上はメモ扱いにしている。例えば「あとで読む」サービスの Pocket を長いこと使っていたんだけど、 Pocket を開く機会が特に通勤が無くなってからかなり減ってしまったことに気付き、今は読みたい記事も「Today」に放り込むようになった。 Dynalist には「inbox」という機能があり、ある階層を「inbox」として指定すると、 webhook に対して投げた文章を全部その中に保存してくれるようになる。これを使っている。「Today」に入れたものは1日の最後に見直して振り分けするルールにしているから、嫌でも目に入って何かしら処理されることになる。

Scrapbox

なんでも入れておくメモ。便利。本当に便利。何回か取り上げているのでもう詳しくは書かないけど便利。2017年から、もう3年以上使っているけど、乗り換えたいなとかしんどさを感じるなとかが全然なくてすごい。

最近は public にブログのような使い方をしている人も増えてきているけど、僕は private で使っている。理由としては public 状態だと「この内容は公に書いていいんだっけな」というジャッジが挟まってしまうから。メモするときに認知負荷をかけたくない。検索窓で「これ過去に書いたことあったっけ」っていうワードを探して、特に引っかからなければ何も考えずページ作って書く、という動作をスムーズにやりたい。

ただ、 public な Scrapbox というのもすごく面白そうだとは思っている。ブログのようにある程度磨かれた形ではなくて、多少生の状態の文章をどんどんアウトプットするための場所なので、スピーディかつ本音のままに近い文章が書けるし読める。最近 100DaysToOffload - hub という記事を見かけた。1年100記事という「量」の目標だけを掲げて、質などその他のことは何も考えないことで、とにかくガンガンにアウトプットしようというプラクティス。この用途には Scrapbox は最適だと思う。他人の public Scrapbox を読むのはすごく好きで、 scrapbox.io 全体における、はてなブックマーク新着人気エントリーの RSS を購読している。

ここ半年ぐらいは Pixela と連携して、 Scrapbox にどれぐらい書き込んでいるか、草を生やして可視化できるようにしてみている。別に義務感で Scrapbox やっているわけじゃないんだけど、「おー、結構書いてるな」というのがわかると純粋に楽しい。設定方法は Scrapbox への更新がどれくらい活発におこなわれているかを Pixela で可視化する - えいのうにっき で解説されている。

Gyazo

副次的に、Scrapbox を開発している NOTA が同じく運営する Gyazo も便利で、こちらはお金を払っている（月額390円）。スクリーンショットの共有サービスと思われている側面が強いけど、当然ながら画像ファイルであればなんでも格納できて、ポイントとしてはすべての画像について OCR スキャンがかかるところ。 Chrome 用の Gyazo 機能拡張を使えばウェブページまるごとスクショして、その内容を検索できるようになるし、 Kindle など電子書籍も気になったところは iPad でスクショ撮ってメモ書き込んで Gyazo に突っ込んで検索できるようにしている。 Scrapbox に貼る画像も基本的には Gyazo に上がる形になるのだが、 Scrapbox 側で Gyazo の OCR 結果までは検索できないのがちょっと残念なところ。

notion

前回の記事 で使い道は書いたので割愛。あくまで補足的な使い方。

ツールの使い分け

Dynalist と Scrapbox の2つを主に行き来しながら使っているわけだけど、たまにこれらをどっちかにまとめられないかな、というのは考える。でも結局無理だなというのが今のところの結論。 Scrapbox の、情報や知識が勝手に繋がっていく感覚は Dynalist には無理だし、 Scrapbox はアウトライナー的な使い方ができなくもないけれど、先述した日付に関する機能などはないので、 Dynalist 的に使おうとするとしっくりこない。まぁ適材適所かな、と考えている。タイトル通り、揮発性の一時的な脳内 dump ツールと、不揮発性の永続的なストレージと考えると棲み分けもスッキリする。

Scrapbox の哲学

このブログでも過去に取り上げたことがあると思うのだが、 Scrapbox には哲学がある。ただ漠然と使うより、 Scrapboxの哲学 - 橋本商会 を一度読んでから使い始めたほうがいい。

哲学の1つに 階層整理型WiKiはスケールしない - 橋本商会 というものがある。ドキュメントツールの中には階層整理の形で設計されたものも多いが、階層分類というのは「どこに分類したらいいかわからない」という、いわゆる「こうもり問題」に苛まれることが多い。それを受けて、 Scrapbox は分類のための UI を持っておらず、ノート本文内の単語を [ ] で囲ってリンクにする（ブラケティング と呼ぶ）ことにより、リンク同士が勝手につながって、勝手に整理されていくという形式を取っている。これは Wiki が昔から持っている機能ではあるが、ブラケティングをした瞬間に、リンク先、あるいはそのさらにリンク先のページが画面下部に勝手にずらずらと表示されるなど、ページ同士の繋がりがよりわかりやすく提示されるように設計されている。

この考え方が僕もとても好きで、知識の類は片っ端から Scrapbox に突っ込んでいる。過去に書いたメモのことなんて、忘れていることが大概だ。だから勝手に繋がってくれることが、確かにセレンディピティをもたらしてくれる。「この本の著者のことはよく知らないなぁ」と思いながら読書メモをしたためたら、その著者について、過去に聞いたあるスピーチの中で言及されていたことがわかった、なんてことはよくある。

階層構造への欲求

とはいえこのことが、階層型に対して Scrapbox が完全な上位互換となることを意味するとは思っていない。階層型と、 Scrapbox のような非階層型とは対立するものではなくて、一長一短で並立する関係と捉えている。

自分は ops 寄りのエンジニアである故もあり、システム関係のドキュメントを作る場合が特に多い。システムAの構成図、基本設計書、障害対応手順と作り、システムB、C、Dにも同様のものを作る。これを Scrapbox でやれるかと言うと、ちょっと厳しいなという思いが強まる。ほしいのは一覧性だ。ここに自分が管理している全システムの情報が集まっている、ということが、階層管理だとこんな感じで視覚的に認知できるのが嬉しい。

これが Scrapbox だと、各システムの様々なドキュメントがどれも同じカードの形でバラバラと一覧表示されることになる。検索をかければ欲しいドキュメントはすぐに見つかるのかもしれないが、そこに「全体感」のような感覚は生まれづらい。もちろんこれは好みもあるわけで、この手のドキュメントでも Scrapbox だとか、タグ管理でイケる人はイケるんだろう。

階層と非階層の両立としての notion

自分の考えとして階層、非階層は排他ではなくて、ある組織が管理したいドキュメントのうち、階層で管理したいものとそうでないものは併存し得ると考えている。 notion というツールに分があるのは、その双方を混在させずに管理できる点にある。

notion の基本構造は階層整理だ。すべてのページは階層のどこかに位置することを基本としており、画面左側のメニュー部分には、常に全体の階層が表示されている。一方で、階層を伴わない整理機能として「データベース」というものが存在している。これがなかなか言葉で説明しづらいのだが、本当に RDB のレコードのような形でページが保存されていて、それをテーブル、カンバン、カレンダーなど、好きなビューを切り替えながら一覧できる機能、というイメージに近い。ページにはタグなどのメタ情報を複数付加することができ、それをキーにしてビューを構成する。以下はメタ情報をカラムとしたテーブルのビューから、あるメタ情報（status）をキーにしたカンバンへと切り替えるデモとして撮ってみた。

そしてデータベースの中のページは、先の全体階層の中には表示されない。データベースの中だけで緩やかにスペースが区切られるようなイメージで、データベース内のページは、先のビューを使って一覧をする形になる。ただし、全体で検索をかければ、階層内のページも、各データベース内のページも同様にヒットする。ということで、 notion は大きな階層と、その節々でデータベースという小さな非階層を併存させた構造を取る。

この構造、なかなか使い勝手がいい。例えば先述したような、システムに関するドキュメントは階層構造で整理して、無限に増え得る技術 tips などの資料はデータベースでタグを付与しながら書き溜める、といった使い方が考えられる。 notion は階層構造のツールだとよく言われるけれど、個人的にはこのハイブリッド性こそが魅力の本質ではないかなと捉えている。従来の階層構造ツールでも、 Evernote のようにタグ対応しているものはもちろん存在していたが、すべてのページを階層の中にも位置づけるし、タグも付与できちゃうというものが多く、自分の経験からすると、結局どっちつかずになってしまうことが多かった。 notion は階層で分類するノートと、タグで分類するノート（＝データベース）を明確に分離することができるのが新鮮に感じている。

notion の使い所

というわけで notion は良いツールだと感じていて、個人でちょっと使っている。魅力を感じているところ、つまるところ使い所は他に2点ある。

PDF の保存が1つ。最近 Scrapbox もファイルアップロードに対応したが、 notion が便利なのはページの中に PDF を埋め込んでプレビューできること。別ページで PDF 開かなくていいのが良い。様々なホワイトペーパー、製品の説明書、 ScanSnap でスキャンした書類など PDF は数多くあるものの、今までは Dropbox に取りあえず突っ込んで終わり、だったのが、 notion を使うとメタ情報としてタグ付けて整理してその場で閲覧までできるようになった。

もう1つは表。正確には先のデータベース機能になるのだが、スプレッドシートは大仰、 Markdown や Scrapbox のテーブルだと表現力がちょっと弱い、というその中間あたりをうまい具合に notion が突いている。カラムごとにデータ型の指定もできるので、これまでスプレッドシートをやむなく使っていたケースをわりと notion に移行できた。

これ以外の知識や情報などのノートには引き続き Scrapbox を使っているし、メインと言えるのはあくまで Scrapbox 。 notion のデータベースはタグによる分類を実現できるものではあるけれど、Scrapbox はメタ情報としてタグを付与する、という考え方ではなくて、ノートの中の適当な単語や一文を [] で囲んでおけば、同じ単語が出てきたノート同士が勝手につながる、という思想なわけで、こちらのほうが使う上での心理的、認知的負荷は遥かに低いし、セレンディピティの恩恵も受けやすい。 Scrapbox がまだ苦手としているところを notion に担わせる形になっている。

逆に「組織」で使うとしたらどちらのツールを選ぶか、と問われたら notion を選ぶ気がしている。アイディア出しが重要になってくる開発やプロダクトデザイン、研究などの職種であれば、セレンディピティの点で Scrapbox が良いのだろうけど、ある程度固定的な情報を扱う ops の人間からすると notion のほうが組織の情報管理にはマッチする感覚が強い。このあたりは「情報をどう取り扱いたいのか」という組織のニーズによりけりなんだと思う。ドキュメントツールには、何かしら背景に設計思想があるはずなので、そこを押さえた上で、自分たちの情報管理思想とマッチするものを選ぶべきなんだろう。逆に特に設計思想が感じられず、世の中で使われているからという理由だけでタグも階層もその他いろいろ多機能になってます、みたいなツールは使いづらい場合が多い。

今回は notion に焦点を当てて書いたけど、後日 Scrapbox と notion と、あと情報管理という点でもう1つ使っている Dynalist 含め、自分のユースケースをまとめられたらと思っている。

まぁガンガン latest にしていくのも考え方によってはありかもしれないが、メジャーバージョンアップ（ Terraform の場合 0.12 → 0.13 をメジャーバージョンアップと呼びたい）までされてしまうのは抵抗がある人も多いのではないだろうか。そもそも Terraform には remote config の中にバージョン指定を出来る箇所があり、自分の場合はこんな感じで 0.12 台のみを許可している。

terraform {
  backend "remote" {
    hostname = "app.terraform.io"
    organization = "sample"

    workspaces {
      name = "sample"
    }
  }
  required_version = "~> 0.12.0"
}

望むらくは、この required version をもとにしていい感じにバージョン設定してほしい。なのでそういう GitHub Actions を作った。

terraform-cloud-updater

https://github.com/marketplace/actions/terraform-cloud-workspace-auto-update

input として最低限、対象の Terraform ファイルが保存された working_dir を指定し、環境変数 TFE_TOKEN で Terraform Cloud の API トークンを渡してあげれば動作する。

on:
  push:
    branches:
      - master

jobs:
  tf_cloud_update:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - name: check update
        id: check
        uses: chroju/terraform-cloud-updater@v1
        with:
          working_dir: ./terraform
        env:
          TFE_TOKEN: ${{ secrets.TFE_TOKEN }}
      - name: result
        run: echo "${{ steps.check.outputs.output }}"
        if: "${{ steps.check.outputs.is_available_update == 'true' }}"

デフォルトの設定だと workspace のバージョンアップまでは自動で行わず、新しいバージョンが見つかったら outputs.is_available_update の値が true になり、バージョン情報が outputs.output にセットされるだけだ。あとは is_available_update で条件分岐して、例えば slack などで通知する方式を想定している。 comment_pr という input を true にすれば、 Pull request をトリガーとして使った際にコメントで通知してくれる機能も作ってはあるが、バージョンチェックであれば cron 形式で定期実行するほうがいいだろう。

input の auto_update を true にすることで、自動的に更新まで行ってくれる。その際、 required version との整合性を確認し、整合しない場合には更新は行わず、通知だけが行われる。以下は comment_pr を true にした場合のサンプルだが、 outputs.output からも同様のメッセージが取得できる。

実装

go-tfe

https://github.com/hashicorp/go-tfe

Terraform Cloud の API ライブラリは hashicorp が公開している。名前が tfe になっているが、これは Terraform Enterprise と Cloud の共通 API ライブラリだからであって、 Cloud で特に問題なく使えた。

ちなみに Go で CLI ツールとして書いているので、この Action のもとになっているレポジトリを build すれば、ローカルで実行する CLI としても使うことができる。

$ terraform-cloud-updater -h
Usage: terraform-cloud-updater [--version] [--help] <command> [<args>]

Available commands are:
    check     Check if new Terraform version is available
    update    Update Terraform cloud workspace terraform version

required version の処理

一番面倒くさかったのが required version だった。セマンティックバージョニングはいわゆる小数ではなく、ドットを2つ挟んだ数値形式なので、単なる数値比較を行なうことができず、逐一ロジックを組んでいった。また required version を示すオペランドの中には、 ~> 0.12 （0.12.0 以上かつ 0.13.0 未満の意）といった複数の意味をはらんだものもあり、これも自前で判定ロジックを組んだ。

と、いろいろ書いた末に「セマンティックバージョニングをよろしくやってくれるライブラリあるんでは？」と思って探してみたら当の hashicorp から公開されていたわけなのだが。勉強になったのでいいか、と思いつつ、こちらも比較で見てみようと思っている。

https://github.com/hashicorp/go-version

初めての GitHub Actions

GitHub Actions 自体はよく使っているものの、自分で Action を作るのはこれが初めてだった。ここでは詳細な作り方などには触れないが、 Action を実行する Dockerfile と entrypoint.sh を書き、あとはメタ情報を定義した action.yml を設置するだけでよいので、非常にお手軽に感じた。ちなみに Action は JS か Docker で作れるのだが、後者を選んだのは単に JS が書けないから。書けるのであれば実行速度などを鑑みても JS のほうがいいと思う。

なお、 GitHub Actions は GitHub Marketplace で公開ができる。そのための操作も非常にシンプルで、レポジトリのルートに action.yml を置くと勝手に判定されて、 Marketplace で公開するためのボタンが表示されるようになっていた。

Terraform のバージョン管理という根深い問題

Terraform のバージョン管理問題はなかなか根深い。というのも Terraform の仕様上、一度使用したバージョンより古いバージョンに戻ることはできないようになっているからだ。そのため複数の Terraform レポジトリを扱っている場合、バージョンは required version に従って一括で揃えられるようにしたいという欲求が大きい。

複数の Terraform バージョンを切り替えるためのコマンドラインツール tfenv においても、 tfenv doesn't read the required_version from conf.tf · Issue #124 · tfutils/tfenv ということで、 required version に則って自動的に切り替えてほしいという issue が挙がっており、このあたりは悩んでいる人が多いのではないかと推察している。

COVID-19 の影響で僕も絶賛リモートワーク中なのだが、せっかくなのでどんな感じでやっているのか記録も兼ねて書いておく。

インフラエンジニアはリモートワークに慣れている

僕は新卒から9年間 IT インフラ領域で働いていて、当初からリモートワークの片鱗のようなものはやっていた。多くのインフラエンジニアがそうだと思うけど、夜間休日にアラート対応を行う必要があり、またデータセンターに籠もりながら仕事をすることもあるので、いつでもどこでも働ける環境を持っている人が多いのではないかと思う。

僕の場合、 BYOD 的に自分の PC を使っていいのか、会社支給の PC が必須なのかは時期によって異なるものの、いずれにせよ「常に PC を携行していつでも仕事できるようにしておく」状態が求められてきた。データセンターに行って作業して、会社に戻る時間が勿体ないので近くのカフェで仕事して帰ったりしていたし、サンライズ出雲の中で朝6時ぐらいに対応したこともあったし、山梨のワイン祭りでオープンエアーのなか、ほろ酔い状態で障害対応せざるを得なかったこともあった。

ということで、リモートワーク自体は従前からずっとやってはいた。

フルタイムのリモートワークは話が違う

だから会社以外で働くことに抵抗はあんまりなかったし、 PC 1台あればなんとかなると思ってた。それが2年ぐらい前、 初めてフルタイムでリモートワークをしたときに、そうじゃないんだとわかった。

当時、怪我が理由でやむを得ず在宅勤務を1週間やらせてもらったことがあった。その頃はデュアルディスプレイも外付けの良い感じなキーボードも持っていなかったものの、障害対応の経験から「なんとかなるだろ」と軽く考えていた。が、会社の環境との差分が徐々にストレスになってきて、1日目が終わらないうちにデュアルディスプレイがどうしても欲しくなり、仕方なくテレビと繋いでぎこちないデュアルディスプレイ環境を作っていた。その後ちょうど今から1年ぐらい前に、大学へ入ったことと転居したことを契機に「きちんとした作業環境を作ろう」と思い、机や椅子も含めてすべて準備した。今のフルリモートワークは、1年前に「たまたま」設備を整えていたから出来ているもので、これが2年前だったらやっぱり難しかっただろうと思う。

もうひとつ、設備面だけではなくて、働き方やルーチンの面も重要だと思っている。オフィスで働くことは、単に働きやすい設備が整っているだけではなくて、働くための環境、体験があることを意味するのだと思う。それは同僚が近くにいて、すぐに声を掛けられることだったり、出退勤という物理的な移動を通じて、仕事の開始終了を明確に区切れることだったり。家でひとりで働くとき、オフィスでの体験を完全には再現できない。その状態で、じゃあどうすればオフィスと同じようなパフォーマンスを発揮できるか？という視点、いわば設備というハードに対して、ソフト面の整備も重要になってくる。

特に今の状況は、リモートワークを強いられているのでストレスが強いという思いがある。今働いている会社はもともとリモートワーク OK だったけれど、それは裁量で会社に来てもいいし、来ないこともできるという意味で、今の「リモートワーク強制」とはまったく違う。今日はちょっと気分を替えてリモートワークしよう、であれば、それだけでパフォーマンスにはプラスになるかもしれない。しかし常に家で仕事をしていると、必然パフォーマンスは従来より上がりにくくなる。

てことで以下では、ハードとソフト、両面から自分のリモートワーク環境についてまとめてみる。

リモートワーク環境（ハード面）

まずハードについてだけど、正直言うともっと改善したい。超最高級の環境にはなっていない。ぶっちゃけ妥協してしまった。平日ずっとこの環境で作業をすることまで想定していたらもっと良いものを買っていたと思う。なのでこれから揃える人は、考えられる限り最高の環境を作ったほうがいいんではないだろうか。てわけであんまり参考にしないでほしさはある。

椅子 / イトーキ サリダ YL8

https://www.amazon.co.jp/%25E3%2582%25A4%25E3%2583%2588%25E3%2583%25BC%25E3%2582%25AD-%25E3%2582%25AA%25E3%2583%2595%25E3%2582%25A3%25E3%2582%25B9%25E3%2583%2581%25E3%2582%25A7%25E3%2582%25A2-YL8-GRBL-AEL-%25E3%2582%25A2%25E3%2582%25B8%25E3%2583%25A3%25E3%2582%25B9%25E3%2582%25BF%25E3%2583%2596%25E3%2583%25AB%25E8%2582%2598%25E4%25BB%2598-%25E3%2582%25B0%25E3%2583%25AC%25E3%2583%25BC%25C3%2597%25E3%2583%2596%25E3%2583%25A9%25E3%2583%2583%25E3%2582%25AF/dp/B07FCYCXDF

コストパフォーマンスに優れた椅子。3万円ぐらいだが、ランバーサポート、可動式のアームレスト、固定リクライニング、背もたれのメッシュなどが付いていて悪くない。ただあくまでコストパフォーマンスというところで、座面の硬さだとか、ヘッドレストが頭に合わないだとか、気になるところもある。フルリモート前提ならもっと高いのを選ぶと思う。

今だと後継で YL9 が出ているので、そちらのほうがいいかもしれない。

充電器 / Anker PowerPort I PD

https://www.amazon.co.jp/Anker-PowerPort-PowerIQ%25E3%2580%2590Power-Plus%25E3%2580%2581MacBook%25E3%2580%2581Galaxy-XZ1%25E3%2580%2581%25E3%2581%259D%25E3%2581%25AE%25E4%25BB%2596Android%25E5%2590%2584%25E7%25A8%25AE%25E5%25AF%25BE%25E5%25BF%259C/dp/B072KBG9W4

最大30W供給する USB Type-C 1ポートと Type-A 4ポート搭載の充電器。これに Type-C 2本と micro USB 1本、ライトニング 1本、Fitbit Versa 2 の独自充電ケーブル1本繋いで使っている。充電は1箇所でまとめてできるようにしておくとやっぱり便利。

そのまま机上に置くと見た目があまりにあまりなので、 無印良品のポリプロピレンメイクボックス に隠している。

キーボード / Corne Cherry

自作キーボード。自作じゃなくてもいいので、手に合うキーボードは必須と思う。と言いながらも、自作だとキースイッチの重さや押した感触、キー数、左右分離か否か、キーキャップの触り心地などなど隅々まで好きにできるので、冗談抜きに自作はおすすめではある。作るのも半日あればできるし、値段も HHKB 買うのとそんなに変わらない、はず。沼にはまらなければ。

その他

その他ざっくりこんなの使っている。

| 品物 | 品名 | amazon link | |--|--|--| | 机 | ノーブランドの謎のやつ | https://www.amazon.co.jp/dp/B0045XJPWM | | ディスプレイ | I-O DATA EX-LDQ241DB | https://www.amazon.co.jp/dp/B077Y79Q2V | | PCスタンド | NEXSTAND | https://www.amazon.co.jp/dp/B01HHYQBB8 | | ヘッドセット | VOYGER 3200 | https://www.amazon.co.jp/dp/B07SMR5RD2 |

リモートワーク環境（ソフト面）

ソフトと言うかルーチンというか、こんなことを気をつけている。

仕事開始のルーチン

通勤というのは結構仕事開始のルーチンとして大きかったのだと思う。それが無くなった今、何か別の手段で自分の身体と精神に「今から仕事だぞ」と言い聞かせる、スイッチの切替が必要になっている。

僕の場合はノイキャンイヤホンで音楽を聞き始めることと、ポモドーロ・テクニックのタイマーを入れることがスイッチになっている。外界からの遮断と、タイマーを入れることによる明確な時間の区切りがいい感じに作用してくれている。コーヒーを淹れるとか、「やるぞ」って声を出すとか、なんでもいいので何かしらルーチンを定めると捗る。

ちなみにノイキャンイヤホンは定番の SONY WF-1000XM3 を使っている。音楽流さず、ただ耳にはめてノイズキャンセリングしてるだけでも効果がある。

ポモドーロ・テクニック

先程言及したポモドーロ・テクニックは、タイマーをかけて25分間集中して、5分間休憩するというサイクルを繰り返すもの。人間の集中力の限界はそれほど長くないので、強制的に中断することで集中力の持続性を高めたりとか、25分という短い時間を区切ることで集中しやすくするとか、そういった効果があるらしい。

僕の場合、これはリモートワークのときに限らず導入しているのだけれど、リモートワークのときは特に集中力が削がれやすかったりもするので、相性がいいと思う。また逆の観点で、いつまでもだらだら仕事を続けてしまうのを防ぐ効果もある（リモートワークでは「帰宅」が発生しないので、仕事を際限なく続けたくなりがち）。

タイマーには Just Focus (AppStore link) を使っている。25分経つと強制的に画面をロックしてくれる強力なやつで、タイマーが鳴ったのにずるずる作業を続けたりすることがない。

昼休みは必ず外に出る

休憩時間がもったいなくて家で過ごしたくもなるのだが、昼休みは必ず外に出るようにしている。気分転換の効果がひとつと、フルリモートだと通勤がなくなるので、運動不足解消の意味がひとつ。

最近は感染症予防のこともあるので、もっぱら外食ではなく中食をしている。また「外出は1日1回にしましょう」という話もあるので、昼休みが唯一の外出機会になる日が多い。

ボイスチャットを躊躇しない

自分がやれているかは置いておいて、ボイスチャットを躊躇するべきではないと感じている。基本常に slack が開かれていて、コミュニケーションが取れる状態があるのは大前提として、文字ベースのやり取りより話したほうが早いじゃん、ということはどうしてもある。そういうとき10秒でも1分でもサクッと話すことを躊躇しないでおくとわりと捗る気がしている。

あと、「ちょっとここわかんないんだけど」ってときに作業中のコードを共有する手段として、 VSCode の Live share がすごくいい。めっちゃ快適。デスクトップ共有するぐらいならこっちのほうが絶対いい。ターミナルまで共有されるのがちょっと怖くはあるが。

Nintendo Switch

これハードじゃんって感じだけど Nintendo Switch は買ってよかったなというのが精神的に大きいのでソフト面で入れてみた。

最近だと『あつまれ どうぶつの森』がなんとなく外出欲を満たしてくれるのと、『Fit Boxing』が運動不足解消に使えるのと。『リングフィットアドベンチャー』が流行っていたけど、『Fit Boxing』ならジョイコンだけで遊べるので、ダウンロード版を買ったらサクッと始められる。

自分が最もパフォーマンスを発揮できる状態を、自分でつくる

つらつら書いたけれど、自宅はもともと仕事する場所じゃないので、そこでどうパフォーマンスを発揮できるようにするかを考えなきゃいけないよね、という話。そしてハード面ばかりに意識が向きがちだけど、ルーチンとかも見直すことで結構生産性上がったりするよ、という話。

正直、この状況がいつまで続くかわからないし、感染症が終息した後もきっとリモートワークはある程度普及したままになるだろうなと思うので、今のうちにゴリゴリ環境作りしていくのが吉だと思う。

tfmodule

事の発端としては tfmodule という CLI ツールを作ったことによる。

https://github.com/chroju/tfmodule

Terraform module を使うときは、 README などを読んで必要な変数を確認し、それに応じて設定を書いていく流れが一般的である。しかし何分これが面倒だったので、一発で module の構造をパースして、テンプレートを吐き出してくれるようなものを作れないかと考えた。

例えばこんな variable と output を定義している module があったとする。

variable "instance_type" {
  type        = string
  description = "EC2 instance type"
  default     = "t3.micro"
}

variable "instance_counts" {
  type        = number
  description = "Number of instances to create"
  default     = 2
}

output "instance_arns" {
  value = aws_instance.instance.*.arn
}

これに対して tfmodule は以下のようなテンプレートを出力する。

module "instances" {
  source = "./modules/instances"

  // EC2 instance type
  // type: string
  instance_type = "t3.micro"
  // Number of instances to create
  // type: number
  instance_counts = 2
}

output "instances_instance_arns" {
  value = module.instances.instance_arns
}

処理としては HCL をパースして構造を読み取り、 module の形に再構成して出力をしている。このツールを作る中で、 HCL の出力に関して知見を得ることができた。

HCL のデータ構造

HCL をパースするには、まず HCL の構造を理解する必要がある。これについては、今回は Terraform における HCL を解析するので、 Syntax - Configuration Language - Terraform by HashiCorp を読むと早い。正確には、このページに書かれているのは「 Terraform における HCL の使い方」でしかないので、 HCL 自体の言語仕様を知る場合には hcl/spec.md at hcl2 · hashicorp/hcl を読んだほうがよい。ちなみに Read the Docs に https://buildmedia.readthedocs.org/media/pdf/hcl/guide/hcl.pdf という URL で PDF のホワイトペーパーも置かれているのだが、こちらは一部内容が古い部分がある。

ざっくり、 HCL は Arguments と Blocks という2種類のデータ構造から構成される。

image_id = "abc123"

これが Arguments 。いわゆる key value の形を取る。

resource "aws_instance" "example" {
  ami = "abc123"

  network_interface {
    # ...
  }
}

これが Blocks 。 {} によって複数の要素を囲った形を取る。冒頭、上記で resource と書かれた部分は type と呼ばれ、その block の種別を表す。それに続くダブルクォートで囲われた2つの文字列は label と呼ばれ、 block を一意に識別する役割を持つ。 label の数は type ごとに定義することができ、 Terraform であれば resource の label は2つ、 variable や output の label は1つと定義されている。

block の {} で囲われた部分は body に当たる。そして body は中に attribute と block を内包することができる。また、ファイル全体も body と呼ばれる。 HCL のデータ構造は、このような入れ子構造になっている。

File
└── Body
    ├── Attribute
    ├── Attribute
    └── Block
        └── Body
            ├── Attribute
            └── Block
                └── ...

hclsimple / hclparse

HCL を扱うには、本家 Hashicorp が公開している github.com/hashicorp/hcl/v2 を使うのが常道である。このライブラリには、さらに用途別でいくつかのサブパッケージが含まれている。

パースをする際には hclsimple や hclparse を使うことができる。最も直感的に扱いやすいのは hclsimple で、 Go の json.Marshal() のように、 hcl を構造体へ変換できる。以下は hclsimple package · go.dev からの抜粋。

type Config struct {
	Foo string `hcl:"foo"`
	Baz string `hcl:"baz"`
}

const exampleConfig = `
	foo = "bar"
	baz = "boop"
	`

var config Config
err := hclsimple.Decode(
	"example.hcl", []byte(exampleConfig),
	nil, &config,
)
if err != nil {
	log.Fatalf("Failed to load configuration: %s", err)
}
fmt.Printf("Configuration is %v\n", config)

しかし、この方法は HCL の構造が予想可能な場合にしか使えない。不特定の構造が予期される場合には、 hclparse を使うことにより、 hcl.File という組み込みの構造体へ変換できる。一般的にパースだけの用途であれば、この2つを使えば十分と考えている。

hclwrite

tfmodule では hclwrite というサブパッケージを用いている。名前通り、これは HCL の出力に主眼を置いたサブパッケージになっている。先の hclsimple.Decode() が json.Marshal() と似ているので、 json.Unmarshal() にあたるメソッドが存在すれば嬉しいのだが、残念ながらそういった便利な機能は備わっていない。

hclwrite による HCL の出力はかなり愚直な方法を取る。以下のように、先程示した HCL のデータ構造を、頭から順に作っていくような形になる。

f := hclwrite.NewEmptyFile()

rootBody := f.Body()
moduleBlock := rootBody.AppendNewBlock("module", []string{m.Name})
moduleBody := moduleBlock.Body()

moduleBody.SetAttributeValue("source", cty.StringVal(m.Source))
moduleBody.AppendNewline()

for _, v := range *m.Variables {
        if isNoDefaults && !reflect.DeepEqual(v.Default, hclwrite.TokensForValue(cty.StringVal(""))) {
                continue
        }
        moduleBody.AppendUnstructuredTokens(v.generateComment())
        moduleBody.SetAttributeRaw(v.Name, v.Default)
}

hclwrite.NewEmptyFile() で返る hclwrite.File に、順に要素を詰め込んでいく。その後 hclwrite.File.Bytes() を呼ぶと、いわゆる terraform fmt が実行された状態の、整形された HCL が出力される。

SetAttributeXXX

上に示したように、 SetAttributeXXX() というメソッドで attribute をセットできるのだが、 key は単純に string を渡せばいい一方、 value についてはそうではなく、種別にいくつかのメソッドが用意されている。

最もよく使うのは SetAttributeValue() で、これは value として github.com/zcolconf/go-cty の cty.Value を取る。 cty をあんまり理解できていないのだが、 HCL が内部で利用している型システムで、 cty.StringVal() で文字列型、 cty.BoolVal() で真偽値型の cty.Value が返るようになっている。

また、Terraform では var.example のようなリテラルを使うことがあるが、これは SetAttributeTraversal() で埋め込むことができる。主にはこの2つのいずれかを使うことになる。もう1つ SetAttributeRaw() というものがあり、これは hclwrite.Tokens という、いわばバイト列をそのまま埋め込んだような構造体を引数に取ることができる。要するに「なんでもあり」なのだが、それ故に godoc には「出来れば SetAttributeValue() か SetAttributeTraversal() を使うように」と書かれている。

AppendUnstructuredTokens

HCL に attribute でも block でもない要素を埋め込みたいときがある。つまるところコメントなのだが、これについてはコメント埋め込み用のメソッドが hclwrite に見つからなかったので、 AppendUnstructuredTokens() というメソッドを使っている。

その名の通り構造化されていない hclwrite.Tokens を直接追加するメソッドで、コメントの追加は以下のように実装している。

...
moduleBody.AppendUnstructuredTokens(v.generateComment())
...
func (v *Variable) generateComment() hclwrite.Tokens {
        tokens := hclwrite.Tokens{
                {
                        Type:  hclsyntax.TokenSlash,
                        Bytes: []byte("//"),
                },
                {
                        Type:  hclsyntax.TokenIdent,
                        Bytes: []byte(v.Description),
                },
                {
                        Type:  hclsyntax.TokenNewline,
                        Bytes: []byte("\n"),
                },
                {
                        Type:  hclsyntax.TokenSlash,
                        Bytes: []byte("//"),
                },
                {
                        Type:  hclsyntax.TokenIdent,
                        Bytes: []byte("type:"),
                },
        }
        tokens = append(tokens, v.Type...)
        tokens = append(tokens, &hclwrite.Token{
                Type:  hclsyntax.TokenNewline,
                Bytes: []byte("\n"),
        })
        return tokens
}

hclwrite.Tokens はバイト列のようなものと先程書いたが、正確には hclwrite.Token の slice である。ではこの hclwrite.Token とは何なのか、 godoc から抜粋する。

type Token struct {
	Type  hclsyntax.TokenType
	Bytes []byte

	// We record the number of spaces before each token so that we can
	// reproduce the exact layout of the original file when we're making
	// surgical changes in-place. When _new_ code is created it will always
	// be in the canonical style, but we preserve layout of existing code.
	SpacesBefore int
}

バイト列、と書いたように、ここに Bytes でリテラルが埋め込まれる。 Type はそのリテラルの種類を示しており、例えばリテラルがドットであれば hclsyntax.TokenDot 、スラッシュであれば hclsyntax.TokenSlash といったものが用意されている。

tfmodule での実装

hclwrite にも HCL をパースするためのメソッドが存在しているので、 hclwrite だけを使っている。

src, err := ioutil.ReadFile(path)
if err != nil {
        return err
}

file, diags := hclwrite.ParseConfig(src, path, hcl.InitialPos)
if diags.HasErrors() {
        return diags
}

body := file.Body()
for _, block := range body.Blocks() {
        switch block.Type() {
        case "variable":
                variables = append(variables, parseVariable(block))
        case "output":
                outputs = append(outputs, parseOutput(block))
        case "resource":
                resources = append(resources, parseResource(block))
        }
}

参考となる OSS

長々書いてきたが、正直まだきちんと hashicorp/hcl を理解できたとは思っておらず、もう少し楽な実装がありそうな気がしている。ただ、なかなか実装例を見かけることが少ない。 shuaibiyy/awesome-terraform で Terraform 関連のツールをいくつか見てみたりもしたのだが、特に hclwrite を使っているものは見つけられなかった。今のところ参考になりそうなのは2つほど。

https://github.com/apparentlymart/terraform-clean-syntax

Terraform の開発に関わっている apparentlymart 氏の個人レポジトリ。 terraform fmt のように、 HCL を Terraform 0.12 の書式で整形し直してくれるコマンドラインツールで、がっつり hclwrite を使っている。 tfmodule での実装は、かなりこれを参考にさせてもらった。

https://github.com/hashicorp/terraform-config-inspect

この記事を書く中で見つけた、 tfmodule と似た terraform module の解析ツール。 Hashicorp の org 内にあるのだが、今まで気付いていなかった。 hclwrite は使っていないが、 terraform module をどのように解析しているか、という点で学べる点がありそうだった。

履修結果

19科目38単位を登録して、結果は以下のようになった。成績は S, A, B, C の4段階で評価されている。

• S評価 : 4科目8単位
• A評価 : 6科目12単位
• B評価 : 2科目4単位
• 単位未修得 : 7科目14単位

比較的成績は良かったのだと思うけれど、それ以上に目立つのが未修得の単位の多さである。これに関しては見積もりが甘かったとしか言いようがない。大学の単位を取るのは自分が思っていたより大変だった。この点はあとで詳述する。

ところでこのように書くと14単位も「落とした」ように見受けられそうだが、実際には不合格になったわけではなくて試験すら受けていない。何が違うのかと言うと、通信課程においては（通常課程がどうなのかは知らないが）登録した単位は2年間履修可能であるため、来年度に試験を受けて修得ができる。つまりまだ「落とした」というわけではない。ここ重要。

卒業必要単位が124単位、10年前に卒業した大学の単位を充当して修得済みと認定されているのが32単位、今年度修得したのが24単位、残り68単位。今年のペースを考えると、おそらく1年は留年することになる。

通信制大学の過ごし方

以下はあくまで帝京大学理工学部情報科学科の場合なので、他の通信制大学だとまた違う過ごし方になるはず。

授業形態

まず前提となる授業形態について書いておくと、ざっくり3種類ある。

• メディア授業
  • LMS (Learning Management System) と呼ばれるポータルサイトで公開されたビデオ、スライド等の教材を使って学習する。
• テキスト授業
  • 市販のテキストを主に使って学習する。 LMS で補助教材が公開される場合もある。
• スクーリング授業
  • キャンパスへ実際に足を運び、2〜3日間集中的に対面授業を行い、最後に試験を受験して単位を修得する。

通信制大学をよく知らない人にはスクーリングの存在が意外に思われそうだが、法令により通信制大学の卒業単位のうち30単位はスクーリングが必要となっているらしい。原則的に週末2日間を朝から夜まで集中的に講義を受け、最後に試験を受ける形になる。手軽といえば手軽なのかもしれないが、2日間終日の講義というのはなかなか集中力的に堪えるものがある。

メディア授業とスクーリング授業に関してはご想像される通りだと思う。 LMS で公開される教材の種類は授業によってまちまちなので、以下のように様々な種類の教材を使い分けていくことになる。

• 紙の書籍
• 電子書籍（指定された教科書のほとんどは紙だが、まれに電子で手に入るものもある）
• PDF 化されたスライド資料
• 動画
• LMS 内で閲覧するダイナミックなコンテンツ

単位修得の方法

単位修得には必ず単位修得試験を受ける必要がある。レポートや課題提出だけで単位修得ができるようにはなっていない。そして単位修得試験を受ける条件として、 LMS 上の小テストや課題の提出、レポートの提出などが課されることになっている。

試験は年に4回、I期〜IV期という形で受ける機会がある。このうちI期とIII期、II期とIV期で受けられる科目はそれぞれ同じになっており、1科目につき2回受験機会があるということになる（I期で不合格だった科目をIII期で受けるのはダメだったように思う）。したがって最悪の場合は全科目ガッツリ時間をかけて勉強して、III期とIV期だけ受けるということもできなくはない。逆に負荷を分散して、各期でだいたい同じ数の科目を受けるようにもできる。自分のライフスタイルにある程度あわせてプランニングできるのはありがたい。

勉強方法

勉強は主に平日だと帰宅後の1〜2時間程度と、通勤電車の中での時間を費やしていた。休日は時間を取れるだけ取るという形で、日によっては朝から夜まで費やすこともあった。

iPad Pro 12.9 + Liquid Text + GoodNotes

教材を読んだり見たりするときはだいたい iPad Pro を使っている。 Apple Pencil を使ってザクザク書き込めるし、先に書いた様々な種類の教材をだいたいなんでも扱えるのがいい。

特によく使っているのが Liquid Text で、 PDF やウェブページを取り込んで、自由に書き込みをしたり、要らない部分を見えなくしたり、文章や画像をピックアップして欄外にまとめ直したりできる。なかなか使ってみないと便利さがわからない難しいアプリだけど、資料を読みながら情報を整理して理解をしていくという過程ですごく役に立つ。保存処理がたまに分単位で時間を要するのが欠点。

単なるメモ書きの用途には GoodNotes を使っている。こちらも PDF をインポートできるので、さっくり PDF が見たいだけの場合は GoodNotes を使っていることもある。

Anki

https://github.com/ankitects/anki

いわゆる暗記カードをデジタルで作って学習できるアプリケーション。カードに LaTeX や HTML 、画像ファイルなどを埋め込める高機能な点が嬉しい。またカードを実際にめくっていく学習モードは 忘却曲線 などを踏まえて実装されていて、覚えが悪いカードは数分後、すでに覚えたと判断したカードは忘れている可能性のある数日後に再出題してくれて、効率的な暗記ができる。

カードはもちろん自作する必要があるので当初は面倒に感じていたが、カードを作る過程で一度勉強して、その後復習としてカードを使った学習ができるのはわりとよかった。 macOS 上で作ったカードデッキを Android へ移して、通勤電車の中でよく Anki していた。

Visual Studio Code + LaTeX

レポートやプログラミング課題の作成環境。詳細は VSCode と TeX で大学のレポートを書く · the world as code で書いた。

Scrapbox

https://scrapbox.io/

説明が難しいが、すごく簡単に使える Wiki のようなもの。最終的に授業全体で得た知識をまとめておくのに使っている。

東京都立中央図書館

勉強は家でする場合も多いが、特にレポートを書く際に参考資料を漁りたいときは東京都立中央図書館を使っている。

蔵書と閲覧席が極めて多いというのが大きい。特にコンピュータ書が豊富に置かれた図書館というのは知る限りほとんど存在しないので重宝している。本来であれば大学図書館が使えればいいのだが、帝京大学理工学部のキャンパスは宇都宮で、自宅から100km以上離れているため日常利用は難しい。

1年目の所感

単位修得の難しさ

冒頭に「修得できなかった単位数」の話を書いたとおり、単位修得は想定していた以上に難しいものがあった。

大学の単位1単位あたり、学習時間の目安は45時間である。ざっくり卒業に120単位必要なので、年間30単位とすると1350時間。これを1日あたりで割るとだいたい4時間になる。働いている人が確保する時間としてはなかなか厳しいものがある。

おまけにプライベートの学習時間全部を大学に当てられるわけでもない。最新の技術も追いたいし、仕事で未知の技術に触れる機会があったら、どうしてもそちらのキャッチアップが優先になる。仮に試験前の時期であったとしても、仕事より優先するのは難しい。

また暗記力の衰えも感じる。仕事のために新しい技術をインプットする場合、ざっくりとした全体感や概念に関する目録を頭の中に作るようなイメージがあって、細かいことは本やドキュメントを見ればいいので覚えないことが多い。これが結構試験を受ける上でネックになっている。対策としては先の Anki を使ったりして、意識的に暗記をしていくしかない。

授業間の関連性

シラバスなどを見ればわかることではあるが、授業間には関連性がある。ある授業を受けるにあたり、別の授業の履修が前提となっていることがあり、時にそれは暗黙的なこともある。今年度の場合で言えば微分積分2が難しくてなかなか進められなかったのだが、他の授業で微分積分が必要になる場合が少なくなく、「微分積分が出来ていない」ことを理由として修得できない科目が複数出てきてしまった。これも修得単位が少なくなった理由の1つになっている。

孤独感

スクーリングを除けば1人で授業は進める必要があるので、孤独感は強い。寂しいなどという話ではなく、教員や同級生への質問ができないので、わからないことを打破するのが難しい場合がある。

もちろんチャネルがないわけではない。教員とは LMS のメッセージ機能でやり取りができるが、しかしオフィスアワーがあるわけではないので、じっくり質問するようなことはできない。同級生とのやり取りには、大学から提供されている Office 365 内の Teams が使えるのだが、だいぶ過疎気味で積極的な連絡は取りづらい状況にある。

教材と環境構築

これは極一部の授業の話ではあるのだが、1〜2科目ほど Java Applet を題材とした授業があった。既知の通り Applet は Java 11 で廃止済みであり、使うには古い Java をあえてインストールして環境構築する必要がある。そこにどうにも躊躇いが生じ、今年はこれらの授業を断念した。

聞くところによれば Processing への移行が段階的に進んでいるらしく、一時的な問題だとは捉えている。とはいえ、一部このような古い教材が使われていることへの懸念は覚えた。

だいぶネガティブなことも書いてしまったが、1年を通じて「如何に学習を進めるべきか」という指針は立てられたように思う。別に急いで卒業したいわけでもないので、きちんと身につくような学習を2年目も続けていきたい。

https://github.com/1995eaton/chromium-vim/issues/726

Hint-a-Hint と呼ばれるコア機能がある。 f を押下するとページ内の各リンクにユニークなアルファベットが割り振られ、そのアルファベットを押下するとそのリンク先へ遷移できる（下図参照）。キーボードだけでのブラウジングを行う上で欠かせない機能なのだが、これが使えなくなってしまった。

その後有志が fork で修正バージョンを公開したり、 cVim 自体の開発引き継ぎを表明する方が現れたりもしているが、先行きが不透明であるため SurfingKeys という別の拡張へ乗り換えることにした。

SurfingKeys

https://chrome.google.com/webstore/detail/surfingkeys/gfbliohnnapiefjpjlpjnehglfpaknnc

名前に「Vim」と入っていないためか今までノーマークだった。 cVim の開発停滞を危惧する以下の issue の中で代替候補として挙げられており、それで初めて知った。

https://github.com/1995eaton/chromium-vim/issues/723

知名度の高い代替としては Vimium なども存在するが、自分の中でキラーとなっていた以下機能をいずれも搭載していなかった。逆に言えば、探した中では SurfingKeys がこれらの機能を唯一網羅していた。

Emacs Keybind

Vim じゃねーのかという話なのだが、 <input type="text"> なフォーム上で、 bash などで使える文字列編集のショートカットの話である。例えば Ctrl-w で直前の単語削除、 Ctrl-a で先頭までカーソル移動など。これが Vimperator にも cVim にも搭載されていて便利だったのだが、よくよく考えると Vim とは何の関係もないので、他の Vim like key bind 系の拡張には搭載されていなかった。

あるいはこの機能だけ他の拡張を使ってもいいのだが、それも見つからなかった。なんなら cVim からこの部分だけ抜き出して独自拡張作ろうかと思った（けど挫折した）ぐらいには依存している。

JavaScript への keymap 設定

任意の JavaScript 無名関数へ keymap を設定し、詰まるところブックマークレットをキーボードで呼び出すというもの。ブックマークレットというのも死語になった印象があるが、 Pocket にページを保存するときなどによく使う。

正直なところ、一番のコアはこれではないかという思いがある。 JavaScript を書いてそれに自在な keymap ができるのであれば、実質的にあらゆるブラウザ操作に自ら Keymap が可能ということになる。 Vimium はこのあたり「行儀がよい」という言い方でいいのか、すでに Vimium 内で搭載されている機能に対して、別の Keymap を割り当てるということしかできない。

設定の外部化

キーマッピングツールは自分で独自のキーマップを設定できるようになっているものが多い。 Vimperator はローカルのファイルを、 cVim は GitHub Gist の URL を指定することで、外部ファイルから設定を読めるようになっていた。これと同等のものが欲しかった。

設定

ということで当然ながらカスタマイズしつつ使っているのだが、そのうち目星そうなものについて書いていく。主に Vimperator や cVim に存在していた機能を再現したものが多い。

設定は GitHub Gist に書いたものを読み込ませる機能があり、それを活用している。 URL を指定する際には Gist の raw の URL を指定しなくてはならない点に注意が要る。リンクは こちら 。

p, P による URL ペースト

Vimp, cVim から引き継いだ機能。 p や P を押下したとき、クリップボードに URL が含まれていればその URL に遷移させる。文字列に http が含まれなければ検索結果を表示するようにしている。

// paste URL
mapkey('p', 'Open URL in clipboard', function() {
    Clipboard.read(function(response) {
        var markInfo = {
            scrollLeft: 0,
            scrollTop: 0
        };
        markInfo.tab = {
            tabbed: false,
            active: false
        };
        if (response.data.indexOf("http") == 0) {
            markInfo.url = "https://www.qwant.com/?r=JP&sr=ja&l=en_gb&h=0&s=1&a=1&b=0&vt=0&hc=1&smartNews=1&smartSocial=1&theme=1&i=1&donation=1&q=" + encodeURIComponent(response.data);
        } else {
            markInfo.url = response.data;
        }
        RUNTIME("openLink", markInfo)
    });
});
mapkey('P', 'Open clipboard URL in new tab', function() {
    Clipboard.read(function(response) {
        var markInfo = {
            scrollLeft: 0,
            scrollTop: 0
        };
        markInfo.tab = {
            tabbed: true,
            active: true
        };
        if (response.data.indexOf("http") == 0) {
            markInfo.url = "https://www.qwant.com/?q=" + encodeURIComponent(response.data);
        } else {
            markInfo.url = response.data;
        }
        RUNTIME("openLink", markInfo)
    });
});

Quick mark

もともとは Vim の mark を意識した Vimperator の機能だったと記憶している。任意の URL にアルファベット1文字（例えば amazon.co.jp に a ）を割り当てておいて、 goa で現在のタブに、 gna で新しいタブにその URL を開いてくれる。つまりはブックマークを素早く呼び出すものである。

これは実装されている方のブログがあったので、それをそのまま使わせていただいた。ただ最近はよく使うウェブサービスを全部 Station に載せるようにしているため、ブックマーク的によく行くページというのが GitHub ぐらいしかない状況にはなっていると今回改めて気付いた（ GitHub は複数のページを同時に開きたい場合が多く、1サービス1タブが基本の Station 上だと不便）。

https://fewlight.net/20200225/

ブックマークレット

以下の書き方で JavaScript の無名関数にキーをマッピングできる。

mapkey('<Key>', '<Description>', function(){
    // some code
});

登録しているものは先述の Pocket 登録のほか、 Amazon の URL から様々なクエリ文字列を削ぎ落として綺麗にするためのもの、 markdown 等特定形式での URL コピーなどいろいろ。

theme

ominibar と呼ばれるコマンド入力用のバーが実装されているのだが、その CSS を好きにカスタムできる。デフォルトが白いのだがダークな感じがいいな、と探していたところ、カラーテーマ Dracula にインスパイアされたものが見つかったので、使わせてもらっている。

https://gist.github.com/emraher/2c071182ce0f04f3c69f6680de335029

機能

ところでこの SurfingKeys 、恐ろしく多機能らしく全部は使いこなせていない。例えば Markdown をクリップボードに入れた状態で特定のキーを押すと HTML プレビューしてくれる機能、自動スクロールしながらページ全体のスクリーンショットを撮ってくれる機能などがあるらしい。が、そこまでは使えていなくて、 Vimperator や cVim でやっていたことが引き継げればいいかなという感覚で使っている。

EKS 全体

• Amazon EKS Workshop :: Amazon EKS Workshop
• Kubernetes on AWS/EKSベストプラクティス2019.2 #jawsdays - Speaker Deck

AWS がオフィシャルで提供する Workshop がハンズオンしながら学べてわかりやすい。ドキュメントを脇に携えつつ、まずはこれの「Beginner」にあるコンテンツを全部通すといい感じになれる。「Intermediate」「Advanced」の内容は人によって要不要が分かれるので、各項で何が学べるのか調べつつ、不要であれば飛ばしてもいいかもしれない。

2つ目に挙げている mumoshu 氏の資料が情報量多くてすごい。EKS を使う上で考えなくてはならない点がかなり網羅されている。この資料を読んで、「何言ってるかわからない」と感じるページが無くなるように学習を進めたりしていた。ただし1年前のものなので、一部内容が古くなっている点は注意。

EKS on Fargate

• 入門 EKS on Fargate - Qiita
• EKS for Fargateが出たので社内でファーストインプレッションの情報シェア会をやりました - inductor's blog
• EKS on Fargate：virtual-kubelet の違い + Network/LB 周りの調査 - @amsy810's Blog

ちょうど Fargate が EKS 対応してすぐの時期にあたり、 Fargate を採用するべきか、採用するのであればどのような場面で採用するべきかを考えた。 Fargate って Fargate 以前の EKS と比べてどうなの？という点については前者2つの URL が参考になった。最後のエントリーは Fargate とは何者なのか？ということを知る上で勉強になるのだが、まだ半分ぐらい理解できていない自覚がある。

EKS 特有の観点

Kubernetes ではなく、 EKS にしか存在しない特有の観点というものがいくつかある。

IAM Roles for Service Accounts (IRSA)

• Kubernetes サービスアカウントに対するきめ細やかな IAM ロール割り当ての紹介 | Amazon Web Services ブログ
• IAM Roles for Service Accounts を　Terraformで手軽に体験してみる - onsd’s blog

Kubernetes の権限管理の仕組みである Service Accounts と、 AWS の権限管理サービスである IAM を連携した仕組みが IRSA 。導入が2019年9月と比較的最近であり、資料はまだ少なめな印象がある。また IRSA 登場以前に書かれたエントリーでは、 kube2iam など別のソリューションがベストとされていることもあり、注意したい。現時点では IRSA を基本的には使えばいいと捉えている。

Amazon VPC CNI Plugin

• ポッドネットワーキング (CNI) - Amazon EKS
• aws/amazon-vpc-cni-k8s: Networking plugin repository for pod networking in Kubernetes using Elastic Network Interfaces on AWS
• Amazon VPC CNI Plugin for Kubernetes のアップグレード - Amazon EKS

EKS には CNI として VPC と連携するためのものがデフォルトインストールされている。あまりこれに特化して解説した資料が見つからなかったのでひたすら公式を読んでいる。 Calico の導入方法にも触れられている。

kubectl

• [アップデート]EKSを使う際にaws-iam-authenticatorが不要になりました! ｜ Developers.IO

これも2019年5月と比較的最近のリリースで、 aws-iam-authenticator を勧めるのはすでに old な方法になっている。現状は aws eks update-kubeconfig を打つだけで ~/.kube/config が更新されて kubectl が使えるようになる。シンプルで好き。

監視

• Monitoring your EKS cluster with Datadog | Datadog
• Key metrics for Amazon EKS monitoring | Datadog

EKS 特有の監視方法やプラクティスは Datadog blog を参考とした。 Datadog はこれに限らず、システム監視について体系的にまとまった記事を量産していていつもお世話になっている。

Kubernetes 自体の監視については 我々は Kubernetes の何を監視すればいいのか？ | はったりエンジニアの備忘録 を読んだりしたが、まだはっきり答えが出せていない。調べているとよく名前を見かける kubernetes-retired/heapster がすでに Deprecated になっていたり、変化も激しい。

Kubernetes 全般

Google Cloud Blog

• クラウドネイティブ アーキテクチャ、5 つの原則 | Google Cloud Blog
• Kubernetes best practices: mapping external services | Google Cloud Blog
• Kubernetes best practices: Organizing with Namespaces | Google Cloud Blog

Kubernetes 自体のプラクティスについては、やはり Google のほうが豊富に資料を用意している。特に Kubernets best practices の各記事は一読しておいて損はなさそう。どう使えばいいのか迷ったらここを読む感じにしていた。

書籍

• Cloud Native DevOps with Kubernetes
• Kubernetes Best Practices
• Kubernetes in Action
• Kubernetes: Up and Running, 2nd Edition

いずれも O'Reilly online learning で読んでいる。全部通読したわけではなくて、何か調べたいことがあったときに逐次辞書のように引いている。特に1番目の『Cloud Native 〜』は Kubernetes の初歩から始まり、 Kubernetes cluster をどのように運用していくのか、カオスエンジニアリングやシークレット管理の話、デプロイまわりなどかなり幅広くまとまっていておすすめ。1つのベンダーにとらわれることなく、各種 OSS や SaaS に少しずつ触れているので、cluster 運用に活用するツールの比較検討を進める端緒として使いやすい。最近日本語版も出ている。

https://www.oreilly.co.jp//books/9784873119014/

あとデプロイ（CI/CD）まわりもいろいろ読んだと思うのだけど、どれを読んだかちょっと思い出せなくなってしまった。

昨年末に Qiita のほうでこのようなエントリーを出した。このときは Organizations には触れていなかったのだが、その後年明けから Organizations はじめ「マルチアカウント管理のためのサービス」に触れてきたので、改めてまとめたい次第。

率直に言ってマルチアカウント管理のためのサービスは多すぎると感じている。 Organizations が代表的だが、その他にも Control Tower が近年出てきたり、 AWS SSO は使えるのかどうなのかとか。あとはサービスによってマルチアカウント制御の仕組みを独自で持っているものもあったりする。そんな中で何をどう使えばいいかがまったくもってわからんので、一旦自分なりの考えをまとめておく。あくまで自分なりの答えなのでベストプラクティスなどと呼ぶつもりはないが、一つの指針として参考になったらよいなと考えている。

なお、本記事は2020年2月時点の情報に基づく。1年も経てば状況はまたガラリと変わっているだろう。現時点で「マルチアカウント管理のためのサービス」としては、以下のものがある、という状態である。

• AWS Organizations
• Control Tower
• AWS Single Sign-On
• CloudFormation StackSets

だいぶ長いしまとまっていないので、時間がなければ最後までスクロールして Conclusion を見たほうがはやい。

マルチアカウント管理とはつまるところ何がしたいのか

そもそも「マルチアカウント管理」とは具体的に何を欲しているのか。自分の場合、まとめると以下4点になる。

• 権限管理 : IAM User を個別に作ると面倒なのでログイン管理を集約したい
• 設定管理 : 各アカウントの基本的な設定は一括で統一的に適用したい
• 監査 : マルチアカウントの利用状況を効率的に監査してガバナンスを効かせたい
• 集約化 : ログなどをアカウントごとに蓄積すると閲覧しづらいので集約管理したい

混乱が生じやすいのは、これらの目的を魔法のように解決してくれるサービスがあるわけではない点だろう。まぁ「それはそうだろ」という話でもあるのだが、それにしてもマルチアカウント管理のサービスが Organization 1つに統一されているわけでもなく、各種サービスでできることが重なっていたり微妙に違っていたりもする中、様々組み合わせなければ「やりたいこと」が実現できないので見通しづらい。

以下では、これら目的視点で各サービスを見ていく。

AWS Organizations はほぼ必須

https://aws.amazon.com/jp/organizations/

Organizations はどんな場合であれ、マルチアカウントを使うのであれば有効化してよい。というのはコストメリットが大きくなるため。1つには Reserved Instance を複数アカウントで共有する機能を利用できるようになるので、柔軟な RI 購入が実現できるようになる。もう1つは「ボリューム割引」の考え方があり、複数アカウントを Organizations で一括請求にまとめることで、価格が低くなる可能性が高まる。

また、この後で触れていくが、一部サービスについては Organizations を活用して管理を効率化できるものがある。そのため「何はなくてもとりあえず Organizations に契約アカウントはまとめておく」ようにすると、恩恵を受けられる機会は多くなる。 Organizations には、実行可能な API をアカウント単位で制御する SCP といった機能などもあるが、こういった付随機能がよくわからなくても、極論とりあえず Organizations を有効化しておくだけでもいい。

Control Tower を使う場面はかなり限られる

https://aws.amazon.com/jp/controltower/

Control Tower はそもそも何者なのかすごくわかりにくいのだが、以下の機能を持つ Organizations のメタ管理サービスみたいなものと捉えている。

• Landing Zone
• Account Factory
• ガードレール
• SSO

Landing Zone とは AWS が提唱するマルチアカウント構成のベストプラクティスを指す。以下のページに構成図が載っているので、あわせて見てもらうとわかりやすいのだが、つまるところ監査専用アカウント、ログ集約専用アカウントを設けて、それらの間を AWS SSO を使って行き来するというようなものである。 Control Tower はボタン1つでこの構成を用意してくれるというものだ。

https://aws.amazon.com/solutions/aws-landing-zone/

自動でいい感じにやってくれるなら最高じゃないか、と思いたくなるところなのだが、曲者なのがこれに付随する Account Factory という機能である。 Landing Zone で生成されたログ集約用アカウントや監査用アカウントで管理してくれるのは、この Account Factory を使って新規作成したアカウントに限られる。したがってすでに Organizations を利用済みだったり、 AWS アカウントを準備している場合に、それを Landing Zone へ組み込むということができない。そのため Control Tower を有効活用できるのは、これから AWS を使い始るような場合に限られる。

なお、ガードレールは Config Rules 等を使って Landing Zone 内の各アカウントを監査する機能であり、 SSO は先に言及した通りである。これらも自動的にセットアップしてくれるのだが、 Account Factory で作成していないアカウントはやはり制御下に追加できない。今後このあたり改善されないだろうかと期待している。

SSO vs switch role

権限管理については IAM User と switch role の仕組みを使うか、 AWS SSO を使うかの2択だろう。 switch role は、あるアカウントの IAM User から別アカウントの IAM role へ権限の切り替えを行う方法で、詳しくは ロールの切り替え (コンソール) - AWS Identity and Access Management に掲載されている。 AWS SSO は読んで字の如く、マルチアカウントでシングルサインオンを実現するサービスである。

基本的には Active Directory (AD) をすでに有している、あるいはその管理を厭わないのであれば SSO を使えばよいし、そうでなければ switch role という考え方をしている。 AWS SSO は非常に便利な機能ではあるのだが、ID ソースとして利用できるのが AD か SSO 自身の ID ストアのいずれかに限られている。そして後者は API が存在せず、 GUI 上で管理しなくてはならないので手間が大きい。そのため AD ほぼ一択という状況なのである。

switch role であれば単なる IAM の活用に過ぎないので、 Terraform 等を利用した管理が実現できる。マルチアカウントの ID 管理を Terraform に落とし込むのは若干面倒ではあるものの、一度セットアップしてしまえば難しくはない。エムスリーさんのブログに非常にわかりやすくまとめられていたので貼っておく。

ちなみに、 AWS はサードパーティの SAML IdP にも対応しているので、 G Suite などを持っているのであれば、それを活用するのも手である。

設定管理の集約化における銀の弾丸はない

マルチアカウントを管理していると、各アカウントで設定を揃えたい部分が出てくる。例えばよく使う IAM Policy を全アカウント作っておきたいとか、そういうもの。これに関しては残念ながら万能な解決策は今のところ存在しない。

https://aws.amazon.com/jp/blogs/news/new-use-aws-cloudformation-stacksets-for-multiple-accounts-in-an-aws-organization/

最も「万能な解決策」に近いのが CloudFormation StackSets だろう。もともとマルチアカウントに設定展開する機能を持っていた StackSets だが、先日 Organizations と連携して、新たに Organization へ追加されたアカウントへ自動展開が可能になった。アカウント作成時の初期設定をこれに全部任せてしまえるわけである。

しかし API の公開がまだなので、 StackSets for Organizations の設定は手作業となってしまう。まぁ、そこにこだわらなければこれが万能解に近い。すべて完全なコード化を行いたいのであれば、 Terraform を先のマルチアカウント展開させる方式で活用することになる。個人的には現時点ではこっちを選んでいる。

Organizations による一括設定

Organizations には「信頼されたアクセス」と呼ばれる機能がある。この画像のようにサービスごとに「アクセスの有効化」ボタンが用意されており、これを押すことで有効となる機能だ。

これは何なのかという話だが、サービスごとに意味するところが異なるので、それぞれ調べて使う必要がある。そして一部サービスについては（具体的には CloudTrail）、これを有効化することで Organization 内の全アカウントで機能を有効化することができる。一方、例えば Config は全アカウントの状況を集約したダッシュボードを作れるようになるだけであり、機能の有効化までは賄われていない。

これもまた直感に反しているというか、わかりにくいなと思う機能の1つではある。

自動監査系のサービスはお好みで

各種ログであったり、 AWS の使用状況であったりを AWS が自動的に監査してセキュリティ上の懸念を通知してくれるというサービスは様々ある。 GuardDuty, Config Rules, Amazon Detective, Security Hub などなどが該当するだろう。これらもマルチアカウント集約が可能であったりはする。

しかし何分サービスの数も多いので、とにかく全部使っておけばよいというものでもなくなってきている。もちろん「やるべきか否か」で言えば「やるべき」になるのだろうが、監査をすべて有効化したところで、その通知をさばいて対処するのは人間である。結局通知がさばけないのであれば通知だけされても意味はない。セキュリティ上、何を優先的に確認しなければならないのか、チームなり会社なりで方針を決めた上で活用していかなくてはならない。

各種監査系サービスのマルチアカウント管理について、調べた範囲で対応状況を記載しておく。

AWS Config

• Config Aggregater という集約機能がある
• Organization 内のアカウントからデータ集約させることができる

Amazon GuardDuty

• Organization には連携しない
• マスターアカウントとして任意のアカウントを決めて、そのアカウントから集約したいアカウントを「招待」する形で集約化できる

AWS Security Hub

• GuardDuty と同様

Amazon Detective

• GuardDuty と同様

まぁ、正直全部 Organizations と連動してほしい。

Conclusion

何もまとまらないのだが、あえてまとめるとこんな感じかと。

• Organizations をまず有効化して、 Organizations を基軸に集約化を考える
• Control Tower, SSO は最悪一旦無視してもいい
• Infrastructure as Code 過激派じゃなければ CFn StackSets は便利
• マルチアカウントを一括設定する Terraform の使い方は習熟しておくとよい
• 監査、管理系の各サービスは、個別にマルチアカウント管理の方法が異なるのでそれぞれ調べる必要がある

僕としては Organizations を中心に、もう少しシュッとした感じになってくれることを期待している。

読書するときはカラーの画面ではなくて刺激が少ない電子ペーパーを使いたい派なので、もっぱら Kindle Paperwhite を使っていた。この端末には概ね満足していたのだが、残念ながら弱点がないわけではない。「お前は一体何を言っているんだ」と思われそう（実際言われた）が、まず Kindle 以外の電子書籍は読めない。DRMフリーの電子書籍ファイルなら読むことも可能だが、ファイルを Kindle へ送るにはメールに添付して送信するという旧態依然とした手段を取る必要がある。また Software Design のような図表の多い PDF だと、ページめくりの速度がかなり重く、実用には適さなかった。

つまるところ Kindle に限らずあらゆる電子書籍を電子ペーパーで読みたいのである。ということを数年来ぼんやりと考えてはいたのだが、この何年かで Android を積んだ電子ペーパーの類がいくつか出ているということを最近知った。そして検討の結果 Likebook Ares という端末を購入してみた。

電子ペーパー Android の選択肢

言うまでもないのだがニッチ分野であり、選択肢は多くない。見たところ僕が買った Boyue というメーカーの Likebook というシリーズと、もうひとつ Onyx の BOOX というシリーズのほぼ二択に絞られる。いずれも中国のメーカーで時代を感じる。

正直性能面での違いはカタログ上だとあまり感じなかった。 Likebook を買ったのは値段が数千円安かったというただそれだけの理由である。 BOOX に利があるとすれば、東京都内のビックカメラであれば現物展示している店舗がいくつかあるので、実際に触って買えることだろうか。ビックカメラの在庫検索で確認ができる。

Likebook Ares vs Kindle Paperwhite

実のところ1日しかまだ触っていないのだが、その上で率直なところ Kindle はよく出来ていると感じた。

※ 写っている本文は『ビット・プレイヤー』（グレッグ・イーガン, 山岸真 訳, 早川書房, 2019）

だいたい同じ大きさのフォントで Likebook と Kindle Paperwhite 双方を表示して並べてみると、明らかに Kindle のほうが読みやすい。とはいえこれは Likebook が悪いというわけでもない。僕がかなり小さなフォントで読むのが好きだという関係上、いずれもフォントサイズは最小にしている。すると当然の如く字は掠れやすくなってしまうのだが、 Kidnle にはフォントの「太さ」を調節する昨日があるため、小さくてもくっきりとした文字で読みやすくなるという次第。 Likebook では Kindle の Android アプリで表示しているわけだが、このアプリでは太さ調節はできないので、どうしても見やすさには限界がある。

Kindle Paperwhite はきちんと読書用にチューニングされた端末なのだ、というのがこれで初めて理解できた。 Android の読書アプリはカラー画面での表示を前提に作られているから、電子ペーパーでは読みづらい可能性があるというのを受け入れなくてはならない。 Android 電子ペーパーならどんなアプリでも読めてウハウハじゃん、というわけでもなかったのだ。

ちなみに英語はわりと Likebook でも読みやすい。これは O'Reilly Online Learning のアプリで『Cloud Native Devops with Kubernetes』(Justin Domingus, John Arundel, O'Reilly Media Inc., 2019) を読んでみたところだが、日本語ほど線が細い印象はない。単純に自体の問題だとは思う。

Pros

とはいえ使い物にならないというレベルではないし、明らかな利点も多い。

電子書籍アプリは概ね問題なく動く

Kindle と O'Reilly のほかに Google Play Books も試したが、いずれも概ね問題なく動く。ということで「あらゆる電子書籍を電子ペーパーで読みたい」という願いは達成できそう。

「概ね」と言っているのは、挙動の面でもやはり Kindle のほうがストレスレスに感じることも少なくないため。PDF で動作が重いということもなく、 Likebook のほうが全体的にするするとは動くのだが、なぜかストレスがたまにある。これはなんかもう言語化できない感覚的なものであって、慣れれば気にならなくなるとは思っている。

端子が USB Type-C

Kindle Paperwhite は2018年発売の最新モデルでも microUSB で、日常的に使うガジェットではほぼこいつだけ microUSB で少しだけ困っている。その点 Likebook は Type-C である。

SD カードに対応している

つまり容量の拡張ができる。まぁ Kindle Paperwhite でも容量に困ったことはないのだけど、拡張可能であるに越したことはない。

Cons

先のフォントの問題以外で感じるのは以下あたり。

文字入力の精度が悪い

デフォルトで Android キーボードという QWERTY のタッチキーボードが使えるのだが、精度がよろしくない。通常の状態と、数字や記号が入力できる状態を切り替えて使うことがよくあるが、切替ボタンを押した際のタッチ判定が切替後まで残ってしまって、切替後のボタンが誤タッチされてしまう。

Google 日本語入力のような他のキーボードが入れられるのかはまだ試していないが、タッチ判定の問題とすればハードウェアの問題なので、改善はしないだろうと予想している。

アプリの切り替えは遅い

ひとつのアプリを使っている分には、動作速度は Kindle Paperwhite と同等か、多少速いかなぐらい。しかしアプリの切り替えは遅い。起動も遅い。メモリが足りていない感覚がある。

総評

概ね悪くない。が、文字掠れの問題で嫌気が差したら Kindle Paperwhite に戻るかもしれない。とりあえずしばらくは使ってみたい。

この「文字掠れ問題」は BOOX など他の端末に移行したところで解消は難しそうなので、結局のところ Kindle でもっと簡単に epub 読めるようになるのが最善の道だろうということがわかった。

なお、あくまでデータ取得のための簡単なスクレイピングであり、 E2E テストのような複雑なシナリオが想定される用途でも適用可能なプラクティスではないと思われる。また筆者が使いたい言語は第一に Go で第二が Python である。

スクレイピング用ライブラリは主に2種類

スクレイピングに活用できるライブラリは各言語様々あると思われるが、ざっくり2種類に大別できると考えている。

• 直接 HTTP アクセスするライブラリ
• Headless ブラウザを使うライブラリ

外部のツールに依存せず、ライブラリの機能だけで HTTP アクセスや DOM の解析を行うものが前者。そのライブラリさえ import すれば使うことができるので、基本的にはこの手のものを使うほうが楽だと思われる。ただしブラウザの機能を再現しているわけではなく、生の HTML をそのままダウンロードするだけなので、凝ったことはできない可能性がある。

凝ったこととはなんぞと言えば、例えばブラウザ表示した画面のスクリーンショットを撮りたい、 JS で動的に DOM 生成されるページをうんにゃらしたい、といった場合がある。こういった用途では Headless ブラウザを使うことになる。

直接 HTTP アクセスするライブラリ

個人的には PuerkitoBio/goquery を使うことが多い。 README から例を抜粋するが、 CSS クラスタの記法で取得する要素を指定できるのが好き。

  // Find the review items
  doc.Find(".sidebar-reviews article .content-block").Each(func(i int, s *goquery.Selection) {
    // For each item found, get the band and title
    band := s.Find("a").Text()
    title := s.Find("i").Text()
    fmt.Printf("Review %d: %s - %s\n", i, band, title)
  })

ライブラリを import すればいいだけなので、ビルドなども特別なことはない。

Headless ブラウザを使うライブラリ

Headless ブラウザを操作するフレームワークとしては Selenium が有名。各種メジャーな言語で実装があるのだが、残念ながら Go に対応した公式のパッケージは提供されていない。そのため Python で使うことにしている。

Selenium を使うときはライブラリのインポートだけではなく、実際にウェブアクセスするための Headless ブラウザと、 Selenium がブラウザ操作するための WebDriver も Lambda のデプロイパッケージに含める必要がある。

Headless ブラウザと WebDriver

Headless Chrome を使いたいところなのだが、そのまま AWS Lambda のランタイム上で使えるわけではない。各種 FaaS ランタイム向けに Headless Chromium をビルドした serverless-chrome というプロジェクトがあるので、これを使わせてもらう。

https://github.com/adieuadieu/serverless-chrome

WebDriver には Chrome (Chromium) 向けの ChromeDriver を Downloads - ChromeDriver - WebDriver for Chrome からダウンロードして使う。

注意しなければならないのは、 Selenium, serverless-chrome, ChromeDriver の三者で compatible な version の組み合わせが決まっているということ。任意のバージョンを好きに組み合わせて動くわけではない。現状 serverless-chrome のドキュメントがこれをアップデートしきれていないようで、以下の issue に有志が稼働確認した組み合わせを書き込んでいるのが見受けられるので参考にしている。

https://github.com/adieuadieu/serverless-chrome/issues/133

本記事執筆時点において、最新の serverless-chrome を使った Selenium for Python との compatible な組み合わせが検証済みになっていない。そのため新し目の API が使えない、ということがしばしばある。例えば自分が経験したものとしては、 element.screenshot_as_png() が利用できず、要素単位でのスクリーンショットが取得できなかった。代替策として、 Can't get the screenshot of the current element · Issue #2898 · SeleniumHQ/selenium に記載のある、要素の座標から PIL でページスクリーンショットを切り取る方式を使っている。

Lambda layer を使った Headless ブラウザ等のデプロイ

Lambda にはデプロイパッケージサイズに 50 MB の制限があるので、 Headless ブラウザと chromedriver は Lambda layer を用いてデプロイし、 Function 本体のデプロイパッケージから分離する。

Lambda layer にデプロイしたファイルは、 Lambda 実行時に /opt 配下に展開されるので、それに合わせて Selenium からパスを指定して読み込む。自分の場合は以下の Makefile で Lambda layer 向けの zip パッケージを作成しているが、この場合は /opt/bin 配下に chromedriver と chromium が配置されることになる。

layer_headless_chrome/bin:
	mkdir -p layer_headless_chrome/bin

layer_headless_chrome/bin/headless-chromium: layer_headless_chrome/bin
	wget https://github.com/adieuadieu/serverless-chrome/releases/download/v1.0.0-37/stable-headless-chromium-amazonlinux-2017-03.zip -O chromium.zip
	unzip chromium.zip
	mv headless-chromium layer_headless_chrome/bin/
	rm chromium.zip

layer_headless_chrome/bin/chromedriver: layer_headless_chrome/bin
	wget https://chromedriver.storage.googleapis.com/2.37/chromedriver_linux64.zip -O chromedriver.zip
	unzip chromedriver.zip
	mv chromedriver layer_headless_chrome/bin/
	rm chromedriver.zip

Selenium を使うときは、割愛した書き方をするとこういう感じ。

from selenium import webdriver
from selenium.webdriver.chrome.options import Options

options = Options()
options.binary_location = "/opt/bin/chromium"
driver = webdriver.Chrome(chrome_options=options, executable_path="/opt/bin/chromedriver")

日本語フォントの内包

特にスクリーンショットを撮りたい場合、 Lambda のランタイムには日本語フォントが存在しないため、デプロイパッケージに含めてやらなければ文字化けする。

これはそう面倒な問題でもなく、通常 Linux では $HOME/.fonts にフォントファイルを置けば読んでくれるので、デプロイパッケージを zip するときに .fonts 配下へ使いたいフォントファイルを置いておけばよい。僕は IPA フォントを使っているので、 Makefile だとこういう感じ。

.fonts:
	mkdir .fonts

.fonts/ipaexg.ttf .fonts/ipaexm.ttf: .fonts
	curl https://ipafont.ipa.go.jp/IPAexfont/IPAexfont00401.zip -o IPAexfont.zip
	unzip IPAexfont.zip
	mv ./IPAexfont00401/*.ttf ./.fonts/
	rm -rf ./IPAexfont00401
	rm IPAexfont.zip

Serverless Framework によるデプロイ

Lambda layer と Function を個別にデプロイするのは面倒なので、 Serverless Framework を遣う。先に書いた Makefile の例に倣い、 ./layer_headless_chrome 配下に Headless ブラウザと chromedriver が置かれているものとして、以下のようなサンプルになる。

functions:
  sample_function:
    handler: sample_function.lambda_handler
    layers:
        - { Ref: HeadlessChromeLambdaLayer }
    role: LambdaBasicExecution
    package:
      include:
        - '.fonts/**'

layers:
  headlessChrome:
	path: layer_headless_chrome

SRE NEXT 2020 に行ってきた。

SRE という職種が国内で広まったきっかけは インフラチーム改め Site Reliability Engineering (SRE) チームになりました - Mercari Engineering Blog のエントリーだと思っているのだけど、ここから4年と少し。東京とはいえ、 SRE をテーマにカンファレンスが開催される規模になってきたというのはちょっとした驚きもある。実際来場者が何人だったのかは把握していないが、使われていた4つの部屋に入り切らないのではというぐらいの人がいて、実際に SRE をやっている、あるいは社内に SRE チームがあるという人は半数ぐらいだったらしい。

発表はいずれもかなり具体的なものが多く、 SRE 本はみんな読んでいるよね？という前提の上で、あの本をこう解釈して、うちではこうやって運用しているよ、という話が多かった。最後のパネルディスカッションでも「SRE を始めるにあたり、どんなスキルがあればよいか？」というような質問があったのだが、 SRE を定義づけるのはスキルではなくてミッションなのだと思う。デプロイ頻度を上げたとき、トレードオフで劣化してしまいがちな「サイト信頼性」をどう担保するか。そのミッションに共感して携わってさえいれば SRE だと言える。むしろ特定のツールやスキルに固執して、ミッションが曖昧な状態だと SRE とは言い難い。

とはいえもちろんツールだとか、どのような資料を参考にしているのかも気になるところで、各社が実際の運用で使っている OSS やドキュメント類の話も非常に参考になった。具体的に気になったのは以下。各項目末尾の括弧は、その資料やツールの話が出てきたセッションナンバー。

• Ironies of automation - ScienceDirect (A0)
• The ironies of automation… still going strong at 30? | Request PDF (A0)
• Site Reliability Engineering: Measuring and Managing Reliability | Coursera (C4)
• Event based SLO / Monitor SLO (C4)
• argoproj/argo-rollouts: Progressive Delivery for Kubernetes (D5)
• Production Readiness Check by Production-ready Microservices (B7)

ここからは特に印象に残ったセッションを掲載する。すべて載せられればよかったのだが、結構な分量になりそうなので掻い摘んでみる。

分散アプリケーションの信頼性観測技術に関する研究

基調講演その1。

多くの SRE は基本的には既存の技術を用いてサイト信頼性の向上に貢献するけれど、より低いレイヤーからそもそも可観測性を高めるにはどうしたらいいか、レイテンシを狭めるにはどうしたらいいかというお話。自分はこの先このレイヤーで仕事をすることはなさそうに思っているけど興味深く聴けた。レイテンシ最小化のために、フォグコンピューティングのように小規模なデータセンターが点在する形になる、という方向性は、 AWS Local Zones などですでに実現しつつもあるのだろうと思う。

40000 コンテナを動かす SRE チームに至るまでの道

https://techblog.yahoo.co.jp/entry/20191222793763/

Yahoo! のような大規模なサービス企業になると、インフラチームは Private PaaS を動かして社内の開発者へ「サービス提供」する形になる。それが 40000 のコンテナで提供されているとのこと。

顧客ロイヤルティの指標である Net Promoter Score を社内に対して調査しているというあたりが面白かった。他にも社外ではなくて社内に対して SLA を定義しているという話もあった。 DevOps 以来の考え方として、アプリチームとインフラチームはなるべく境界をなくすべきというのが是のように思い込んできたけど、逆に明確な境界を引いて、 AWS の責任共有モデルよろしく、両者の責任範囲を限定してしまう方式もありなのだな、というのが気付きだった。

成長を続ける広告配信プラットフォームのモニタリングを改善してきた話

偽陽性のアラートを減らす、そのためにアラートの整理を定期的に実施するべきであるという2点と、実際に Kubernetes 環境をどのようなツールで監視しているかの話。特に Kubernetes の監視については現在目下検討中なので参考になった。 influxDB + Telegraf + Grafana （俗に言う TIG Stack ）と New Relic とのこと。

delyにおける安定性とアジリティ両立に向けたアプローチ

SRE のミッションを「プロダクト開発の速度を 安全に 高める」ことと定義して、それを如何に成し遂げていくかという話。一般的にはエラーバジェットを用いることになるのだけど、実際のところはバジェットを使い切ったときに新規デプロイを中止するのは現実的ではなかったり、導入が難しい側面がある。では、他に解決するべき、プロダクト開発速度を落とす要因はないのだろうか？と改めて問い直して、コードやシステムから「想定外の複雑さ」を取り除いていこうという結論に至る。 SRE 本に掲載されたプラクティスをただ愚直に導入するのではなくて、その目的はそもそも何か、その目的を達する手段は他にないだろうか？という良い問い直しでした。

SRE Practicies in Mercari Microservices

国内で最初期に SRE チームを発足させていたメルカリさんの SRE プラクティス。具体的な運用方法の話が出てくるので参考にしたいことだらけ。 SLO、CI/CD、On-call、Toil とテーマを分けて話をしてくれたのでとても聞きやすかった。特に SLO の振り返りの話が興味深くて、 SLO のみならず Toil の量や顧客（SRE が信頼性向上施策を提供する相手である、マイクロサービスチームのこと）満足度と絡めて評価するとのこと。例えば SLO が達成されていても、 Toil が多いし顧客満足度も低ければ、その SLO 達成にあまり意味はないということになるので、 SLO を厳しくしてみる。 SLO 達成、 Toil も少ないが、顧客満足度が低いのであれば、顧客が求める SLI は別のところにあるのではないかと考え、 SLI を変えてみる。達成 / 未達成の2択ではなく、その SLO に意味はあるのか？というところも運用を踏まえて振り返る視点は重要だと感じた。

いろんな Terraform ユーザーに話を聞いたりしてもなかなか解決しなかったこの問題だが、ようやく決定版と言えそうな解決策として mozilla/sops を使う方法を見つけた。

SOPS

https://github.com/mozilla/sops

Secrets OPerationS の略らしい。 YAML や JSON など Key/Value 形式の設定ファイルにおいて、 Value の箇所だけを暗号化できるコマンドラインツールである。 homebrew でインストールできる。

$ brew install sops

暗号化にあたり、まず鍵を指定しておく必要がある。鍵は AWS KMS や GCP KMS などの各種クラウドサービスの暗号化サービスに対応していて、環境変数で使うキーを指定する。鍵がファイルだったり手入力のパスフレーズだったりすると扱いに困りがちだが、クラウドの KMS であればキーへのアクセス権を適切に管理するだけでいいので、これは嬉しいポイント。

$ export SOPS_KMS_ARN='arn:aws:kms:ap-northeast-1:999999999999:key/XXXXXXXX-XXXX-XXXX-bd50-ac0ec6d03d63'

新しく暗号化したファイルを作る場合は、 sops コマンドに secret を保存するファイル名を引数として与えて実行する。

$ sops secrets.yaml

すると、そのファイルの編集画面が $EDITOR で開く。ファイル名の拡張子からファイル形式が自動的に判断されて、以下のようにサンプルが表示される。

hello: Welcome to SOPS! Edit this file as you please!
example_key: example_value
# Example comment
example_array:
- example_value1
- example_value2
example_number: 1234.5679
example_booleans:
- true
- false

別にこのサンプルを踏襲する必要はまったくなくて、すべて消して好きなように内容は書いてよい。そしてファイルを保存したタイミングで、 value 部分に暗号化が施される。例えば以下のような YAML を書く。

db_user: user
db_password: password

これを保存後に cat してみると以下の通り。

db_user: ENC[AES256_GCM,data:vioDUg==,iv:j7O4xlHMcfb6DzY0ptSa38tkeCFKy2e8qVGwTCG3M8k=,tag:qqcothINK6OKhJb/3jvuxw==,type:str]
db_password: ENC[AES256_GCM,data:vCo7u6AggyU=,iv:3y90FXchrZfXQ7b6JGfVJABdxk5r+mIezTf9jb19VdM=,tag:3Gq5IrDeJiz46snahFn4Og==,type:str]
sops:
    kms:
    -   arn: arn:aws:kms:ap-northeast-1:999999999999:key/XXXXXXXX-XXXX-XXXX-bd50-ac0ec6d03d63
        created_at: '2020-01-17T14:04:58Z'
        enc: AQICAHgIueX8MsuSyX/hToTAJGoN2l3ZRsFfBaJMo5aNEN6CPAG4Y2Bo1oWyGA+enYwwsaa+AAAAfjB8BgkqhkiG9w0BBwagbzBtAgEAMGgGCSqGSIb3DQEHATAeBglghkgBZQMEAS4wEQQMbbKFmXXsd1DuWI/5AgEQgDt7SbVbUUD4rsLO1mNC0MdCU5kXZt0qrL/SrCIwGWLUwFO8jYlJrgZFlOY2jKL1ODMXjfvUiM6YsQOqVw==
        aws_profile: ""
    gcp_kms: []
    azure_kv: []
    lastmodified: '2020-01-18T04:48:01Z'
    mac: ENC[AES256_GCM,data:2Rf0IgpyGXJxWCtFDn7Fl1Gv4qPMN9IXuWt+w71Iu9ngFBp4URSDCSthyxbXtt8jhiTl4IgvLkv0lyYAGa/dM+l/2OcR3LeZldv4oR3cm6LjErwKD8O65Lh7Z9J+LR/TmS7E4I0lN+JhePn8qrIGjL4x3J16mD45I2dNtlAoRus=,iv:HEttY0FACDix5plof0mP4B2lkikPcKiLEVSt7dqpql0=,tag:ZZR7witKJgZS/jf5rprXeQ==,type:str]
    pgp: []
    unencrypted_suffix: _unencrypted
    version: 3.5.0

最初の2行の通り、確かに暗号化が施されている。 sops: 以下は sops が付加するメタ情報で、見ると暗号化に使ったキーの ARN が埋め込まれている。復号には sops -d filename コマンドを使うが、このときは環境変数ではなくてこの YAML 内の ARN の指示先が復号キーとして扱われる。なのでチームメンバー内でこのファイルを共有するのであれば、該当のキーに対するアクセス権限をそれぞれが保持さえしていれば、容易に復号することができる。 ARN が割れたところで何かクラックできるわけではないので、この状態のファイルであればパブリックレポジトリに入れても良さそうな気もするのだが、気になるのであればプライベートレポジトリで commit しておけばいい。

なおこのファイルに対して再度 sops filename コマンドを使うと、複合した状態で YAML を再編集できる。編集後は編集した箇所と、メタ情報の一部だけが書き換わるので、 git diff で差分を見るときもわかりやすい。

terraform-provider-sops

本題の sops を使った Terraform での秘匿値管理だが、残念ながら HCL を直接暗号化することには対応していない。しかし community provider として terraform-provider-sops がありがたいことに存在している。

https://github.com/carlpett/terraform-provider-sops

これは data source として、 sops で暗号化されたファイルからの値読み込みを提供してくれる provider だ。先の db_user と db_password を書き入れた secrets.yaml を作成した状態で、同じディレクトリに以下のような sample.tf を作成してみる。

provider "sops" {}

provider "aws" {
  version = "~> 2.0"
  region  = "ap-northeast-1"
}

data "sops_file" "secrets" {
  source_file = "secrets.yaml"
}

resource "aws_ssm_parameter" "sensitive" {
  for_each = data.sops_file.secrets.data
  type     = "String"
  name     = each.key
  value    = each.value
}

すると terraform plan の結果は以下の通りになる。

  # aws_ssm_parameter.sensitive["db_password"] will be created
  + resource "aws_ssm_parameter" "sensitive" {
      + arn    = (known after apply)
      + id     = (known after apply)
      + key_id = (known after apply)
      + name   = "db_password"
      + type   = "String"
      + value  = (sensitive value)
    }

  # aws_ssm_parameter.sensitive["db_user"] will be created
  + resource "aws_ssm_parameter" "sensitive" {
      + arn    = (known after apply)
      + id     = (known after apply)
      + key_id = (known after apply)
      + name   = "db_user"
      + type   = "String"
      + value  = (sensitive value)
    }

Plan: 2 to add, 0 to change, 0 to destroy.

普段の Terraform の使い勝手とほぼ変わらず、簡単に秘匿値を取り扱うことができてこれはうれしい。普通に tf file を書き、秘匿したい値だけは YAML へ切り出して sops で暗号化し、一緒に git commit してしまえば管理は簡単そうだ。

Terraform Cloud での活用

sops の暗号化を AWS KMS key で行い、 aws provider を併用している場合について、Terraform Cloud 上でも正常に復号可能か試してみた。

結論から言えば復号できたのだが、若干動作が腑に落ちていない。 Terraform Cloud で aws provider を使う場合、 provider を以下のように記述して、 Terraform Cloud 側で API キーを AWS_ACCESS_KEY と AWS_SECRET_KEY の2変数に設定する形が一般的かと思う。

provider "aws" {
  version = "~> 2.0"
  region  = "ap-northeast-1"
  access_key = "${var.AWS_ACCESS_KEY}"
  secret_key = "${var.AWS_SECRET_KEY}"
}

どういうわけだが、ここで設定した API キーはあくまで aws provider でしか読み込まれない気がするのだが、そのキーに KMS の復号権限があれば、 sops の復号も動作した。設定が楽で助かるのは助かるが、どうしてこれで動くのかがよくわかっていない。気が向いたら深堀りしておきたい。

なお Terraform Cloud で community provider （GitHub の Terraform Providers org で管理されていない provider）を使うときは、あらかじめ Git repository 内の terraform.d/plugins/linux_amd64 配下に provider のバイナリを含めておく必要があり、少々面倒。このことについては Installing Software in the Run Environment - Runs - Terraform Cloud - Terraform by HashiCorp に記載されており、将来的にはより良い方法を提供したいとも書かれているので期待したいところ。

Conclusion

本当にずっと悩まされてきた課題をスマートな形で解決できてものすごいテンションが上がっている。実はもともと Kubernetes の secrets 管理の方法を調べる中で見つけたツールで、「これは Terraform にも活用できるのでは？」と調べてみたところ、なんと provider を作ってくれている人がいると気付いた、という形の出会いだった。1月から今年は幸先が良さそう。

個人の生活と OKR

OKR というのは Google が採り入れていることで名高い目標管理メソッドで、最近日本国内でもテック系企業が採用している例が増えている。改めて説明するつもりもないが、以下のような点が特徴だと捉えている。

• 目標を完遂することは求めず、達成確度 70% 程度の定性的な目標を3〜5個掲げて運用する
  • 目標の数を少なく絞り、フォーカスするべき領域を明確にする
  • 目標は数値が入った指標などではなく、人を鼓舞するような定性的な内容にする
  • あえて達成が困難な目標を掲げることで、パフォーマンスの最大化を図る
  • その性質上、人事評価に用いるのは NG とされる
• 各目標について、どのような状況があれば「達成した」と言えるのかを示す定量的な成果指標を3個程度設定する
  • 目標が Objective (O) 、成果指標が Key Result (KR) と呼ばれる
• サイクルは四半期ごとと短く設定し、さらに1週間ごとに進捗の確認を行うことで素早く行動する

基本的には組織や企業の目標管理メソッドなのだが、これをあえて個人の生活に採り入れることを昨年の第2四半期から始めた。自分が注力するべき領域をフォーカスでき、短いスパンで進捗を確認して軌道修正ができることは、個人生活においてもメリットが大きい。クリスティーナ・ウォドキーによる書籍『OKR シリコンバレー式で大胆な目標を達成する方法』（日経BP社 2018）においても、及川卓也氏の解説の中で、個人で OKR を採用するメリットについて触れられている。

個人的なタスクが失敗しがちな理由はその優先度を上げずに時間を確保しないということだけが理由ではない。進捗が見えづらいためにモチベーションが維持できないことも、タスクを継続する阻害要因だ。（中略）タスクの優先度を明確にし、継続するためのモチベーションを維持するために、実は OKR が役に立つ。

OKR（オーケーアール）

posted with amazlet at 20.01.13

日経BP (2018-03-15)
売り上げランキング: 6,481

Amazon.co.jpで詳細を見る

ちなみにこの本の原題は『RADICAL FOCUS』らしい。

具体的な運用

とはいえ組織向けに作られた本来の OKR を、そのまま個人生活に適用するのは難しい。金曜日に互いの成果を称え合う「ウィン・セッション」なんて一人じゃやりようがない。なのでいいとこ取りをしながら、以下のような運用をしている。

• 四半期の最初に OKR を作成する
  • 「O」は2つ、各「O」に「KR」は3つ設ける
    • 「O」は技術者関係で1つ、それ以外で1つ
  • 健全性指標は2つ設ける
• 毎週金曜日にウィン・セッションとチェックインミーティングを合わせたような振り返りを行う
  • その週に実行できたこと、できなかったことの振り返り
  • 各 KR の達成自信度レベルの見直し
  • 向こう4週間の予定確認
  • 翌週に OKR に関してやるべきことの設定

ツールは紙、具体的にはコクヨの測量野帳を使っていた。先の OKR 本では毎週の状況報告をメールで行うこととしていたが、チームで運用しているわけではないのでメールである必要がない。何かデジタルのメモツールというのも考えたが、しっくりくるものがなくて紙にしていた。

結果どうだったのか

ぶっちゃけあんまり上手くいっていない。

目標設定自体がなかなか難しい

具体的な OKR の内容は本当にプライベートなものも含まれていたりするのであんまり見せたくないのだが、一例として前四半期の「O」の1つは以下のような内容だった。

• O: SRE として部門の半数の人に認知される成果をつくる
  • KR: 毎週1本ブログを書いている
  • KR: 社内全インフラ構成のコードリーディングと、インフラ構成の肝を理解する
  • KR: Terraform のコードリーディングと PR で存在感を強める

目標自体はまぁ良いと思う。今の部門に配属されて3か月経ったタイミングだったので存在感を高めたかったのが理由。半数というのは少ない感じもあるが、部門内にはエンジニア以外の人も相当数いるので妥当と考えた。

ただ KR については今見直すと妥当とは言い難い。ブログを書いたところで部門の人に見てもらっているわけではないし、社内の存在感とはあんまり関係がない。3つ目の KR についても同様と言えるし、2つ目については仕事の話ではあるけれど、これで認知が高まるかというと微妙じゃないだろうか。 KR は「収益を xx% 増加させる」といった定量的な指標であるべきなのだが、どうもこれが上手いものが思いつかない。

継続できていない

昨年は第2四半期から3回 OKR を回してみたが、いずれも最後の1か月ぐらいで失速して、毎週欠かさず振り返りを継続できなかった。

あんまり前に進んでいる感触が得られなかったというのが理由として大きい。しばらくいそがしくて、何週間も OKR のためのタスクを実行できなかった頃がある。すると今週は達成できませんでした、来週やります、という中身のない振り返りが何度も続くことになる。これで嫌になってやめてしまうことが少なくなかった。

今年の運用

うまくはいかなかったが、個人で OKR を使うことが無意味だとはあまり思っていない。自由に使える時間も限られる中で、自分が何にフォーカスするべきかを定めておく意味は大きいし、短いサイクルで振り返ることで得られるものも（振り返りが継続できなかったりはしたものの）大きいのは確かだという感触はあった。今年は少し運用を替えて継続してみる。

KR は1つだけ定量的じゃなくても可とする

KR に定量的じゃない目標を1つだけ入れてもいいことにした。思いつかないものをいつまでも考えても仕方ないので、まずは回しやすいルールに替えてみる。

KR に行動を入れない

これは OKR 本に書いてあったことなのだが、昨年は KR が思いつかない末に苦しみ紛れに入れてしまった。例えば先に挙げた「毎週1本ブログを書いている」だけど、1週でもブログを書かなかったらアウトになるので達成が難しいし、毎週の振り返りが書いたか否かのゼロイチでしかなくなるので、振り返りに意味を感じづらくなる。今年は絶対に行動を入れない。

振り返りはデジタルで、毎週時間を予め確保する

振り返りはデジタルに替える。端的に言ってそのほうが書くのが早くてストレスが小さく、継続しやすそうだから。また、振り返りの時間は土曜朝に近所のパン屋で15分でやることにする。その時間が空いているかどうか、前の週の振り返りの際に確認して、空いていなければ代替の時間をあらかじめ確保するようにする。

参考資料

OKR とは何か？については市販の本がいろいろ出ているけれど、とりあえず Google re:Work - ガイド: OKRを設定する に Google 式のやり方が端的にまとまっているので、まずこれを見ると良いと思う。具体的な事例が知りたければ、国内企業ブログがいくつも引っかかる。

個人での OKR 実践については、いくつか事例を探せたので参考にさせていただいている。特に1番目に挙げたエントリーが非常に具体的かつ定量的な目標設定ができていて、目標設定後の日々の運用にも言及していてすごく参考になった。ここではダイエットという定量的に測りやすい目標を掲げているけれど、そもそも定量的評価しやすい目標を逆算的に選ぶのもありかもしれない。

• ダイエットを支える技術 - OKRとセルフマネジメントで15キロ痩せる - 未来永劫
• 2019年の個人OKRをつくってみた - これはただの日記
• 個人開発でOKRを試したいので運用方法を考える - Qiita

また目標を作るにあたっては、読書猿氏の『アイデア大全』『問題解決大全』を参考にしている。それぞれアイデア出しと問題解決のための古今東西様々な手法が掲載された本で、目標設定の上でも役に立っている。特に活用しているのが「スケーリング・クエスチョン」（今の自分を100点満点で評価し、100点に足りない点数の理由は何か、それを埋めるにはどうしたらいいかを考える）というメソッド。

アイデア大全

posted with amazlet at 20.01.13

読書猿
フォレスト出版 (2017-01-22)
売り上げランキング: 29,323

Amazon.co.jpで詳細を見る

問題解決大全――ビジネスや人生のハードルを乗り越える37のツール

posted with amazlet at 20.01.13

読書猿
フォレスト出版 (2017-11-19)
売り上げランキング: 60,500

Amazon.co.jpで詳細を見る

• 2015
• 2016
• 2017
• 2018

昨年の総括は「定量評価してみる」という話を書いていて、でも今見ると定量評価というよりはやったことの単なる羅列みたいになっちゃってたのでいい加減毎年使える KPI みたいなものを定めてみようかなという気がした。といったところで自分のようなインフラエンジニアの定量評価に使える KPI ってなんだろうというのが結構難しい。まぁアウトプットの量が一番わかりやすいのかな、とは思うのでブログ、 GitHub の Contributions 、読書した本から定量的に見てみる。その後定性評価として、数値化できないあれこれを書いていく。

定量評価

ブログ

27本書いた。月に2本以上と考えるとなかなかではないかと思う。最後の 4Q においては個人的な目標として毎週書くというのを少し意識してみたのだけど、それに遠からずな感じには書くことができた。2013年以降、ブログを継続的に書けているのは自分でも評価するべき点だと捉えている。ネタとしては Terraform に関することが多かった。

また Advent Calendar は Terraform と会社（グロービス）で2つ参加し、後者は Qiita で書いた。

GitHub Contributions

Public repository について 290 contibutions 。今年から初めて仕事でも GitHub を使うようになったので、 private 込み（仕事への commit 具合も見たいので、デフォルトの表示はこちらにしている）だと 1200 を越える。

最近何年かは terraform-provider-aws に何件かプルリク出すことはできていて今年もそれはできた。他だと tfnotify にプルリクを出してマージしてもらえたり、 terraformer に issue 立てて少し話ができたりしたのはよかった。自分はそれほどガツガツ OSS commit しているわけではなくて、普段 OSS を使っていて何か気付いたことがあったら issue やプルリクを出す、程度の活動をしている。もうちょっと貢献したいような気もするけれど、 commit 自体が目的というわけではないので現状これぐらいでいいのかなとも思っている。何か想定通りの動作をしなかったときにコードを読む、レポジトリに当たるという姿勢は大事にしたい。すでに issue 化されているときも多いのだけど、そういうときはブログに書くなどして何かしらアウトプットすることをやっていきたい。

読書

• 入門 監視
• Web API The Good Parts
• 分散システムデザインパターン
• プロダクションレディマイクロサービス
• SCRUM BOOT CAMP THE BOOK

大学の本は除いた。結構大学の教科書や参考書を読んでいることが多くて、純粋に仕事を意識した技術書はぜんぜん読めていなかった。

新しい会社で働くことになり、マイクロサービスやコンテナによるアーキテクチャを意識するようになったことと、スクラムが社内のスタンダードになっていることから、そのあたりの本を年の後半に何冊か読んだ。いずれも実践に結び付けられていないしブログに感想とかもまとめてないからすごくよくない。来年は大学で履修登録する科目数を少し減らして、仕事の比重を高めるつもりでいる。

定性評価

注力した領域

• Terraform
  • ブログに Terraform ネタが多かったように、 Terraform に一番注力していた。
  • 今年は v0.12 が公開されたり、 Terraform Cloud が GA になったりと大きなニュースも多く、今後さらに注目されそうなので引き続き注力したい。
• Serverless
  • S3 + CloudFront による SPA など、マネージドサービスだけでシステムを組む機会が増えた。
• GCP
  • 仕事で GCP を初めて扱い始めた。
  • 正直まだほとんどわかっていないので、これは今後の課題になっている。
• 大学の勉強
  • 大学の話は年度終わりに別途書くつもりなのでここでは割愛。
  • 数学やアルゴリズムの基本などを今年は学んでいた。

特に Terraform については、去年書いた「プレゼンスを上げたい」のプレゼンスを発揮できそうな分野かな〜〜〜？？という思いになりつつある。自分の技術者としての売りにできるよう昇華させていく。

勤務状況

正社員を辞めて一時的な無職を経て契約社員＋業務委託契約となったことでだいぶ生活自体が変化した。大きくは労働時間が減ったことと、リモートワークを週1日以上するようになったこと。正社員時代はちょっとした時間シフトする勤務体系もあったのだが、それが無くなったことでだいぶ心身も安定した気がしている。仕事で macOS 使うのも GitHub 使うのも slack 使うのも今年からが初めてで、まぁほんといろいろと変わった。

いろんな働き方を経験することは、時代を考えても良いことと考えている。あまり1つの働き方にとらわれず、今後も柔軟な選択ができたらよいし、柔軟な選択ができるよう力をつけておきたい。

自作キーボード

このブログでも何度か書いてきている通り、今年は自作キーボードに手を出した。3台組み立てて1台積んでいて1台注文済み発送待ちの状態。先日ザッと遣った金額を考えてみたけれど、ちゃんと数えなくても 10 万は確実に越えていて少し恐ろしくなった。

しかし趣味的な面を抜きにしても、電子工作という分野に初めて触れられたのはよかった。手先を遣うことは苦手だと勝手に思い込んできていたので、きちんとした道具を買って、きちんと手順を踏めば自分でも工作が出来ると知れたのがすごい収穫だった。さすがに自分で基板設計するところまでは踏み込まないつもりでいるけれど、興味を持った分野は臆さず手を出していきたい。

個人 OKR の導入

ブログには書いていないのだが、今年の 2Q から以下のルールで個人 OKR を回していた。

• 四半期ごとに OKR を2つ定める（仕事系とプライベート系）
• OKR の内容は達成見込み 60 %程度のものにする
• 毎週振り返りを行い、各 KR の達成見込み、先週やったこと、来週やるべきことを確認する
• 四半期が終わるときに総合的な評価を行い、次の四半期の目標を定める

基本的には Google re:Work - ガイド: OKRを設定する のやり方に則っている。昨年の総括で書いたことの1つに「インプットとアウトプットのサイクルを早めたい」というのがあって、 OKR であれば早いペースで明確な目標を立てて commit していくサイクルを回せそうだと思ったので取り入れてみた。

実際のところは四半期終盤になると振り返りの時間を取らなくなったりもして、きちんと運用できたとは言い難いのだが、毎週振り返って成果を出そうとするリズムを作れたことには結構効果があった。先述した「ブログを週1で更新する」というのもこの一貫だった。これについても来年早いうちに別途エントリーでまとめてみようと思うし、今後も続けていく。

来年について

来年は3つ最注力分野として定めている。

• コンテナ
• 英語
• チームビルディング

コンテナを仕事で使う機会に恵まれたので来年は一番注力していく。より正確には Kubernetes になるとは思うのだが、特定のツールに縛られるのではなくて、 VM をコンテナに置き換えるにあたり、どのようなワークフローを作り、どのような OSS を組み合わせていけばよいのかをゼロベースで考えていく。システムの安定性、クラウドの利用料金、開発スピードの向上などなど、考慮したいことはたくさんある。

英語は会話できればもちろんよいのだが、読み書き面をもう少し頑張りたい。英語のドキュメントを読む機会が今でもないわけではないし、そこまで苦手というわけでもないのだが、やっぱり日本語に比べると読書スピードが半分以下に落ちてしまう。 Subscriptions 2019 · the world as code でも書いた通り O'Reilly のオンラインラーニングに登録したこともあり、読解スピードの向上に努めたい。

3点目については、年齢もあるのか、いや年齢の問題というわけではないか、チームや組織というものの在り方を考えなくてはならないなと感じることが増えてきた。端的な例としてはコンウェイの法則がある。コンテナによるアーキテクチャを取り入れ、さらにマイクロサービス化を進めたほうが SRE の観点からメリットが大きいと感じたとしても、組織構造がモノリシックなままでは開発フローが最適化されないわけで、どうしても組織体制への働きかけも必要になってくる。マネージメントまではいかないけれど、チームや組織の力を最大化していく、チームとしての開発やシステム運用を効率化していくにはどうしたらいいのかという部分を考えられるようになりたい。自分はどう考えても内向型で、組織を引っ張る立場には向いていないとは自覚している。であれば、他の立場からどのようなアプローチができるかということを掘り下げていきたい。

Terraform modules for Google Cloud

https://github.com/terraform-google-modules

上記 GitHub Organization にて、現時点で 64 の module が公開されている。 Organization のメンバーを見ると GCP に属している方が多いので、どうも Google 公認で提供されているものらしい。 AWS にも Terraform AWS modules という Organization があるが、こちらは見る限り AWS 関係者ではなく有志による提供となっている。昨今のアレじゃないけど、 Google のほうが OSS コミュニティと良い関係を築こうという意思が見て取れるなぁという気がしなくもない。

公開されている module はいろいろあるが、一例として IAM に関して見てみる。 GCP の IAM に関する Terraform resources は Google: google_project_iam - Terraform by HashiCorp で触れられている通り、何種類かのものが存在するのだが、ざっくり以下2種類に気を付ける必要がある。

• google_project_iam_member : Role とメンバーを1対1で紐つける
• google_project_iam_binding : ある Role と紐付くメンバーすべてを管理する

GCP ではあらかじめ複数の権限が割り当てられた Role というものが存在し（ AWS のマネージドポリシーみたいなものと考えればいいかもしれない）、これとメンバーを紐つけて権限の割り当てを行う。前者の member は1対1対応しか作れないので、ある Role に複数のメンバーを結びつけたい場合（が大半だと思うが）はちょっと不便だ。しかし一方で binding はある Role と紐付く すべての メンバーを管理する。そのため Terraform を apply する前に、すでに Role と紐ついたメンバーがいて、 Terraform 内ではそのメンバーを宣言していなかった場合、 apply 時に除外されてしまうことになるので注意が必要となる。

という、それぞれ一長一短ある resource をうまいこと使い分けなくてはならないのだが、 GCP が module で解決策を提示してくれている。 terraform-google-iam/modules/projects_iam at master · terraform-google-modules/terraform-google-iam からサンプルを引用する。

module "project-iam-bindings" {
  source   = "terraform-google-modules/iam/google//modules/projects_iam"
  projects = ["my-project_one", "my-project_two"]
  mode     = "additive"

  bindings = {
    "roles/compute.networkAdmin" = [
      "serviceAccount:my-sa@my-project.iam.gserviceaccount.com",
      "group:my-group@my-org.com",
      "user:my-user@my-org.com",
    ]
    "roles/appengine.appAdmin" = [
      "serviceAccount:my-sa@my-project.iam.gserviceaccount.com",
      "group:my-group@my-org.com",
      "user:my-user@my-org.com",
    ]
  }
}

2つの resource の使い分けを気にする必要はなく、 bindings 変数に role と members の1対多のリストを渡せばいいだけ。既存の紐付きを置き換える ( authoritative ) のか、既存のものは触らず新たな紐付きを追加する ( additive ) のかは mode 変数で指定ができ、さらにデフォルトは安全側に倒れて additive となっている。だいぶ使いやすく抽象化されていると言っていい。

抽象化のロジックを見てみる。呼び出している module 自体はわりと簡素な内容になっている。というのも、見ればわかるのだが、ロジック部分を helper という別の module に飛ばしているからだ。ここではほぼ resource 作成だけが行われている。

module "helper" {
  source   = "../helper"
  bindings = var.bindings
  mode     = var.mode
  entity   = var.project
  entities = var.projects
}

resource "google_project_iam_binding" "project_iam_authoritative" {
  for_each = module.helper.set_authoritative
  project  = module.helper.bindings_authoritative[each.key].name
  role     = module.helper.bindings_authoritative[each.key].role
  members  = module.helper.bindings_authoritative[each.key].members
}

resource "google_project_iam_member" "project_iam_additive" {
  for_each = module.helper.set_additive
  project  = module.helper.bindings_additive[each.key].name
  role     = module.helper.bindings_additive[each.key].role
  member   = module.helper.bindings_additive[each.key].member
}

使っている resource は、やはり先程見た iam_binding と iam_member の2つだ。それぞれ for_each が使われていることから、変数 bindings で指定された role と members と project あたりをいい感じに list に変換して、選択された mode に応じて module.helper.set_authoritative か module.helper.set_additive に代入しているのだろうと想像がつく。代入されていないほうの変数は空のリストになるので、 resource の作成は行われない。

実際に helper を覗いてみると、確かにそのようなロジックになっている。 module.helper.set_authoritative について追ってみる。

  set_authoritative = (
    local.authoritative
    ? toset(local.keys_authoritative)
    : []
  )

local.authoritative による三項演算子だ。 local.authoritative は先の mode が authoritative だった場合にのみ値が代入されるようになっており、 やはり authoritative を指定した場合に限り、 set_authoritative にリストが代入されているとわかる。そして代入される値は、 keys_authoritative を set に変換したものとなっている。では keys_authoritative とは何か。

  keys_authoritative = distinct(flatten([
    for alias in local.aliased_entities
    : [
      for role in keys(var.bindings)
      : "${alias}--${role}"
    ]
  ]))

local.aliased_entities は project のリストと思ってよい。二重ループになっているため少しわかりづらいが、各 project ごとに bindings から keys, すなわち role の値を取り出し、 project 名と繋げた文字列の配列を作っている。前述したサンプルのように、 projects と role をそれぞれ2つずつ指定している場合であれば、 2 × 2 で長さ4の配列が作られることになるわけだ。 helper の別のところでは、この4つの project - role それぞれに紐つけるべきメンバーのリストが生成されている。最終的に for_each のループによって、これらを組み合わせて iam_binding が生成されている。

ここではざっくりと GCP Terraform modules の中身を見てみたが、これ以外にも非常に多くの Terraform functions を上手く使って抽象化を試みている。コメントも多く盛り込まれていて読みやすいので、各 functions はどういう場面でどのように活用できるのか、とても参考になる。

Conclusion

Terraform provider はその仕組み上、各クラウドサービスの API サービスをそのまま愚直に変換したものであり、 API の仕様を把握していなければ上手く扱えないこともある。しかし我々が欲しているのはクラウドリソースのコード化という点のみであり、 API の仕様を細部まで常に気にしなくてはならない、という状況は歓迎したくない。 GCP の modules はそういった低レイヤーな知識がなくとも、簡潔な記載でクラウドリソースを使えるようにしてくれているものが多い。 Terraform modules を作るとき、単に組織内でのデフォルト値を埋め込んでいるだけ、のような使い方になってしまうことも少なくないと思うが、 GCP のそれは「抽象化」という観点で module を作る上で、大きなヒントになりそう。

Appendix: GCP with Terraform 所感

おまけで、 Terraform で GCP を扱うときに、 AWS を扱うときとこのへんが感覚違うなーと思う点をいくつか。

• 認証に JSON が必要なのはちょっと面倒。
• 個々のユーザーでは credential json 吐き出せなくてサービスアカウントが必要なのも面倒。
• でも複数の project に横断的にリソースを作るのは AWS マルチアカウントより遥かに楽ですごい。
• 各 resource とも attibute references ( outputs で出力できるやつ) がちょっと少なめな印象を受ける。
• 一部 resoruce はドキュメントから直接 Cloud Shell で実践できるボタンがあって強い。
  • https://www.terraform.io/docs/providers/google/r/dns_managed_zone.html とか。

昨年から継続しているサービス

• Day One
• MoneyForward
• Nintendo Switch Online
• Amazon Prime ( Amazon Prime Student に変更 ¥4,900 → ¥2,450 / year)
• Spotify Premium ( 学割に変更 ¥980 → ¥480 / month)
• シネマシティ

今年から大学生になって Amazon Prime と Spotify は学生料金に変更した。なんか大人げない気もするけど、出費が年間で数十万増えているのは事実だし、多少は恩恵を受けておこうかと。

ちなみに Amazon Prime Student は正確には Prime とサービス内容が一部異なって、学生向けの特典がいくつか追加されている。が、あんまり把握していなくて、書籍を3冊以上同時購入すると 10% ポイント還元というのだけ使わせてもらっている。が、ついつい物理書籍は書店で買って持ち帰るほうがテンション上がるのでそこまで使えていない。

Spotify Premium は学生であることを証明するのに、大学ポータルサイトへのログインが必要でちょっとおもしろかった。詳しい仕組みはわかっていないけど SheerID というものらしい。

昨年以降解約したサービス

GitHub

お金を払うとプライベートレポジトリが無制限に使えていたのだけど、これが無料プランにも開放されたので有償である必要がなくなった。

Todoist

タスク管理を後述する Dynalist に移行して解約した。何か魅力がなくなったわけではなくて、リスト型のタスク管理サービスとしてはとても満足していた。単にタスク管理のやり方を替えただけ。

esa.io

昨年のエントリーにも書いていた通り、解約を1年前の時点で検討していたので。現在メモツールとしては Scrapbox と Dynalist を使っている。

新たに契約したサービス

Dynalist ($7.99 / month)

アウトライナーサービス。アウトライナーというと文章を書くときに論理構造を練る上で使うものというイメージが強いけれど、要するところ階層型の情報整理全般に活用できるので、自分の場合はタスク管理というか、今気になっていることをリストアップするのに使っている。

Todoist をはじめ、タスク管理用のサービスってほとんどが「やること」を1つずつ書いていくチェックリスト型になっているものの、実際のタスクってもっと漠然としていることも多い。例えばアドベントカレンダーを書く、というタスクがあったとして、これはさらに「ネタを探す」「ネタを決める」「x日までに下書きをする」「x日までに予約投稿する」といったサブタスクに細分化できる。また「ネタを探す」タスクが書いてあったら、その下に考えたネタを書き連ねていきたいという欲求もある。こういう感じでタスクだけではなくて、今自分の頭の中にあるものをざざっとダンプする目的で使い始めた。

メモサービスはもう1つ Scrapbox も使っている。 Dynalist がメモリダンプで Scrapbox が不揮発性のディスクみたいなイメージ。 Dynalist にとりあえず気になることをメモして、調べて具体的な情報になったら Scrapbox に移す、みたいなことをしている。

ただ、タスク管理のためにまともに使おうとすると、月額 $7.99 というそれなりの金額で Pro プランになる必要がある。 Pro だと日付を設定した項目を Google Calendar に連携してくれたり、繰り返しタスクを作ったりできるようになる。まぁ今のところは必要経費扱い。

d アニメストア (¥400 / month)

映像配信サービスは1つでいいと思っていたのに契約してしまった。同居者と折半で払ってるのでまぁという感じ。

アニメのラインナップは随一と聴いていたけど確かに強くて、『機動警察パトレイバー アーリーデイズ』みたいな古い OVA もあるし、ライブイベント『涼宮ハルヒの激奏』が入っているのを見つけたときには変な声が出た。たかだか 12 年前なのに、声優ライブイベントの様子とか、それを観覧する客席の空気とかに隔世の感があってとんでもねぇなって気持ちになったので契約者は見るのオススメ。

freee (¥980 / month)

個人事業主になったものの確定申告こわいので契約した。年払いだと安くなるけど、1年非正規雇用状態を続けるかもわからなかったので取りあえず月額課金でやっていっている。一番安いプランだけどそこそこしますね。。

Online Learning with O’Reilly ($199 / year)

ご存知アメリカのオライリーによるオンラインラーニングサービス。だいぶ前に1か月間お試しだけしたんだけど、なにせなかなかにお高いので本登録はせずに放置していて。それが今年の Black Friday に 50% OFF のプロモコード来たのでよっしゃ！って思って登録したんですね。んで決済に最初 Kyash 使ったんですよ。でも Kyash って定期支払とかで使えないことあるじゃないですか。で、弾かれて。弾かれたんでまぁしゃーないよねって思って別のデビットカードで決済し直したんですよ。そしたら定価で決済されててアレ？ってなって。どうも1回決済失敗したときにプロモコード外れてたらしくて。マジで？？？ってなったんだけどもうどうしようもなくて。いやー、やっちゃいましたね。今年最後に最大のやらかし。

だいたい月に1冊3000円の技術書を買うペースだとこれぐらいの金額を年間消費するので、そういうつもりでいればいいのかなと。さすがに使わないともったいなさすぎるので来年は英語頑張る。

メールマガジン「読書日記／フヅクエラジオ」 (¥800 / month)

http://fuzkue.com/entries/595

行きつけのカフェの店主が出してるメルマガ。 fuzkue という新宿・初台にちょっと変わったカフェがあって。本の読める店を標榜していて、私語や PC 厳禁で長時間居座り OK でガンガン本を読んでくれっていう場所で、店主さんも読書が好きな方でずっと読書日記をウェブサイトに載せていて、それがまとめられて出版されたりもしていてというおもしろい話。カフェにはそう頻繁に行けるわけでもないのでカンパの意味も込めて購読している。本当に読書の話と、店の話が主になった日記なので、匿名だけどその日のお客さんの様子なども出てきて、一度明らかにこれ俺やんけってのが出てきたときには小躍りしたりしました。

メルマガ購読ってこれが人生初めてだし、今後購読することもない気がしてます。

Terraform State （以下、本記事では tfstate と呼称します）をご存知でしょうか。 Terraform を使っていて tfstate をご存知ではない人はまぁまずいないはずだとは思いますが、直接の編集が非推奨となっているためデリケートな扱いが求められる一方で、 Terraform を使っていると折に触れて立ち向かわなくてはならない憎いやつです。

Terraform を上手く使うことは、 tfstate を上手く取り扱うこととニアリーイコールだと個人的に思っています。そんな tfstate のことをいろいろとまとめてみました。ていうかまとめすぎてえらいことになったので、年末年始のお暇なときにでも読んでみてください。

全体は以下4つに分かれています。

• tfstate 入門 : 文字通り入門的な内容です。
• tfstate 理論 : tfstate にまつわる Terraform の挙動に関して理論的な内容です。
• マクロ tfstate 論 : マクロな視点で考えた、 tfstate の運用管理プラクティスです。
• ミクロ tfstate 論 : ミクロな視点で考えた、 tfstate の編集などの話です。

tfstate 入門

本項では tfstate の基本的な性質、特徴について触れていきます。

tfstate の基礎

tfstate は Terraform が管理するインフラストラクチャーの状態をプレーンテキストで保存したファイルです。データ構造は Terraform の他の設定ファイル（以下、 tffile と呼称します）とは異なり、 JSON が用いられています。

tfstate は自動生成されるファイルであり、手動で書き換えることは非推奨とされています。具体的なタイミングとしては terraform apply コマンドが実行された際に新規作成、もしくは既存のものが更新され、 apply した結果構築、変更されたインフラストラクチャーの状態が記録されます。

また terraform plan コマンドが実行された際には、 tfstate から前回 apply 実行時のインフラストラクチャーの状態を読み取り、それと設定ファイルに記載されたインフラストラクチャー設定との差分から plan 結果を出力します。この挙動については後ほど詳説します。

tfstate の保存場所

特に設定していなければ、デフォルトの保存場所は terraform apply を実行したカレントディレクトリ上の terraform.tfstate という名前のファイルになります。しかし、先述の通りこのファイルは次回 apply 実行の際に必要となります。ローカルに置いたままでは複数人で terraform を実行できなくなってしまうため、何らかの手段で共有する必要があります。

共有する上で、 VCS を用いることは非推奨とされています。これは例えば複数人が git clone して同時に terraform apply を実行してしまった場合などに、競合が発生する可能性があるからです。 tfstate は常に唯一無二のファイルがどこかに存在し、誰もがそのファイルを参照する必要があります。

そのため tfstate の保存にはオブジェクトストレージ等を用いることになります。これを設定するのが backend という設定です。

terraform {
  backend "s3" {
    bucket = "example"
    key    = "tfstate/terraform.tfstate"
    region = "ap-northeast-1"
  }
}

上記の設定では Amazon S3 を backend として指定しています。この設定を記載した状態で terraform init を実行すると、 backend へのアクセスが可能か確認され、問題なければ plan や apply の際にこのパス上のファイルを tfstate として取り扱うようになります。

backend に指定可能なストレージは Terraform がサポートしているものに限られますが、 Azure BLOB Storage 、 Google Cloud Storage といった、メジャーなクラウドサービスの各オブジェクトストレージにはいずれも対応しています。また 2019 年からは、 Terraform を制作した hashicorp が backend サービス Terraform Cloud を公開しており、ユーザー5人までのチームであれば、無償で利用することも可能です。

tfstate は何のために存在するのか

tfstate という仕組みが設けられている理由はいくつかあり、詳しくは State - Terraform by HashiCorp に解説されています。ここでは「Terraform の管理対象を明確化する」という点について考えてみます。

すでに EC2 インタンスが 4 台動いている AWS アカウントに、 Terraform を実行してもう 1 台インスタンスを追加した場合を考えます。次に plan したとき、 tfstate があれば、前回構築したインスタンスの ID が記録されているので、そのインスタンスとの差分を確認すればよいことになります。しかし tfstate が無いとすると、 5 台のうちどれが前回構築したインスタンスかわからず、差分を取ることが困難になります。また、 Terraform は前回実行時以降に tffile から削除したリソースは、現実のリソースも削除しようとしますが、前回実行時の記録がなければ、残る 4 台のインスタンスは Terraform が構築したものなのか、そうでないのか判別ができません。

このように、 tfstate は Terraform の管理対象を明確化してくれます。逆に言えば、AWS アカウント内のすべてのリソースを1つの tfstate で管理対象とするのか、例えばサービスごとだったり、システムの構成単位ごとだったり、何かしらの単位で tfstate を分割していくのかは、個々のユースケースに併せて考えていく必要があります。

もうひとつの tfstate

ところで、あまり意識することはありませんが、 tfstate はもう1つあります。 terraform init 実行時に作成される ./.terraform/terraform.tfstate です。

このファイルにはリソースの情報ではなく、 backend の情報が含まれます。terraform init では backend との疎通確認が行われますが、その結果が問題なければ、 backend 設定がこのファイルへ出力されます。この tfstate は init 実行時に動的に生成されるため、永続的に保存しておく必要はありません。

tfstate 理論

本項では、 tfstate が Terraform によって実際どのように用いられているのか、理論的な部分（？）に触れていきます。

tfstate のファイル構造

手動で読み書きする機会が基本的には存在しないので、案外 tfstate の内容を目にする機会はないのかもしれません。改めて紐解いてみると、以下のような構造をしています。

{
  "version": 4,
  "terraform_version": "0.12.18",
  "serial": 3,
  "lineage": "XXXXXXXX-XXXX-XXXX-XXXX-f4e9614b100e",
  "outputs": {
    "example": {
      "value": "example",
      "type": "string"
    }
  },
  "resources": [
    {
      "module": "module.iam.module.core",
      "mode": "managed",
      "type": "aws_instance",
      "name": "example",
      "provider": "module.example.provider.aws.example",
      "instances": [
        {
          "schema_version": 0,
          "attributes": {
            "arn": "arn:aws:ec2::...",
            ...
          }
        }
      ]
    }
  ]
}

各項目の意味はドキュメントがあるわけではないのであんまりわかっていません。上部に書かれているのはいずれもメタ情報にあたるようで、キーになりそうなのは serial ぐらいかと思います。これは版番号を表しており、 terraform apply によって tfsate が書き換えられるタイミングでインクリメントされます。また terraform_version は、この tfstate が生成される際に用いられていた Terraform のバージョンです。これより古いバージョンの Terraform でこの tfstate を扱おうとすると警告が出て実行できません。特に手動で Terraform を実行している場合、実行者間でバージョンを合わせる必要があるので注意が必要です。

肝になるのはその後の outputs と resources です。 outputs は文字通り Terraform で outputs を設定している場合に限り、その値が記述されます。 resources が、実際に Terraform が構築したリソースの設定情報を記述したオブジェクトの配列です。各オブジェクトの主な項目は以下のとおりです。

• module : 該当 resource が module に内包されている場合、その module 名（内包されていない場合はこの項目自体存在しません）
• mode : data, managed（生成した resource）のいずれか
• type : resource type
• name : resource name
• provider : その resource 生成に使われた Terraform provider 名
• instances : 最後に terraform apply を実行した時に適用された設定情報の配列

各 resource オブジェクトには type と name が含まれますが、これによって Terraform 設定ファイルに記載している resource と紐ついています。以下の Terraform resource で言えば、 aws_instance が type で foobar が name に当たります。

resource "aws_instance" "foobar" {
  ...
}

また instances 内には、 aws_insntace であればインスタンスIDなどの、現実のリソースを一意に特定する情報が含まれます。これにより resoruce オブジェクトは Terraform resource と現実のリソースとの1対1対応を定義しています。なお、お気付きの通り instances は配列です。 for_each や count を使った場合など、1つの resource block で複数のインフラリソースを構築した場合には、複数のリソース情報が入ります。

terraform plan と tfstate

terraform plan を実行した際には、 tfstate を元にして設定ファイルと現実のインフラとの差分が導かれます。とはいえ、 tfstate に書き出された設定を、直接 terraform 設定ファイルの内容と比較して差分を出しているわけではありません。 tfstate からは、先述のように各 Terraform resource と対応する現実のリソースが存在するのかどうかを読み取るだけです。そして存在していれば、その設定情報を API などを用いて実際に取得し、設定ファイルとの比較を行うことになります（）。もしも Terraform resource に対応するリソースの情報が tfstate に存在しなければ、そのリソースは新規作成するべきものと判断されます。

2021-08-22追記 : 正確には terraform plan を実行した際、差分確認が行われる直前に、 terraform refresh が裏で実行され、 tfstate の状態が最新の設定と同期されています。 Terraform 0.15 においては、この refresh 時に実設定と state の差分が発見された際、その旨が plan 結果にも付記されるようになりました。なお、 plan 時に refresh を行いたくない場合、 -refresh=false オプションが利用できます。

つまり、 terraform plan の挙動を表にまとめると以下のようになります。

あるリソースが……

| tffile に | tfstate に | 現実のリソースと tffile の差異が | plan 結果は | |-----------|------------|----------------------------------|-------------| | ある | ある | ない | No changes | | ある | ある | ある | change | | ある | ない | 差異は確認しない | add | | ない | ある | 差異は確認しない | destroy |

従って tfstate の resources[].instances を仮に手動で書き換えても、 terraform plan の結果は変動しません（インスタンス ID のような、そのリソースを一意に特定する項目は除きます）。それでは tfstate を現実のリソース状態に合わせる terraform refresh は不要なのではないかと思われそうですが、例えば Terraform で構築したリソースを GUI から手動で削除してしまったような場合には、 refresh によって tfstate からも削除の上で、設定ファイルから削除する操作が必要になってきます。

マクロ tfstate 論

本項ではマクロに見たときの tfstate について、具体的には tfstate の運用方法などについて触れていきます。

tfstate の保存場所

「入門」で記したように、 tfstate の保存場所として利用できる backend には様々な種類のものが用意されています。それでは、この中でどれを選ぶべきなのでしょうか。

2019年末の時点においては、 Terraform Cloud がベストと考えています。その理由を1つずつ見ていきます。

フルマネージドであるということ

tfstate を保存するためだけに作られた、フルマネージドのストレージであるという特徴はやはり強みとして大きいです。 Terraform Cloud は以下の機能をもっています。

• 自動的にいつ誰が実行したか履歴を蓄積してくれる
• tfstate 保存場所をわざわざ作る必要がない
• Terraform Cloud が Terraform 自動実行の機能も備えている

1点目について。履歴を自動的に追跡し、誰がいつ apply を実行したかがわかるほか、あまり必要となる機会はないものの、各回での tfstate の差分も見ることができます。

2点目については、例えば S3 だとバケットをあらかじめ作成する必要があるわけですが、 Terraform Cloud の場合は一度アカウントだけ作ってしまえば、その後は保存場所を手で作ったりする必要がありません。3点目については tfstate 保存の問題とは直接関係しませんが、 Terraform Cloud は Terraform 自動実行の機能も備えるなど、 hashicorp が提供しているだけあって Terraform を運用する上で便利な機能が備えられています。それら機能をすぐには使わないとしても、いつでも使えるよう tfstate だけは保存しておく、というのはアリだと思います。

Remote State の利便性を活かしやすい

Terraform Cloud を使う場合の利点として、より重要なのは Remote State の利便性を活かしやすい点にあると考えています。

Remote State とは、別の tfstate が output している値を読み取り、変数として活用できる Terraform の機能です。例として、 AWS のネットワークを構築する際、以下のように output を設定しておくと、他の Terraform からこの値を読み取ることができます。

resource "aws_vpc" "example" {
  cidr_block           = "192.0.2.0/24"
}

output "example_vpc_id" {
  value = aws_vpc.example.id
}

先に少し触れましたが、 AWS アカウント全体を1つの tfstate が管理下に置くのではなく、いくつか分割する場合がありますが、その場合でもこの機能を使えば相互に値を参照し合うことができます。あるいはマルチアカウント構成の場合でも、他のアカウントから設定値を読み込むことができるのは非常に便利です。 VPC Peering を行う場合などに重宝します。

Remote State から設定値を読み出す場合、当然ながらその tfstate に対する読み取り権限が必要になります。仮に S3 に置いている場合、バケットポリシーを適切に設定して、クロスアカウントでの読み取りを許可する必要が出てきます。

これを Terraform Cloud に変えると、 Terraform 実行者は誰もが Cloud 上のすべての tfstate を参照し合うことが可能になります。 tfstate をあえて管理対象クラウドの外に引っ張り出して集めておくことにより、集約的な設定データベースのように取り扱うことができます。

ミクロ tfstate 論

本項ではミクロに見た tfstate として、ファイルの編集処理に着目します。

既存リソースの取り込み

Terraform を扱う上で鬼門になる要素の1つに、「既存リソースの取り込み」があります。 tffile を書かなくてはならないのと同時に、 tfstate にも記述を加えなくてはならない点が厄介です。

この問題を解決するために dtan4/terraforming や GoogleCloudPlatform/terraformer が開発されてきました。これらのツールで対処可能であれば、ツールを利用するのが手早いと思います。ツールが残念ながら対応していないリソースを取り込みたい場合には、 terraform import コマンドを使うことになります。

terraform import は tfstate への取り込みだけを行う機能で、 tffile は作成してくれませんが、ある程度工夫することで楽はできます。まず、 tffile に Terraform resource の枠だけ作成してから terraform import を実行します。枠とは以下のように attributes を何も書き込まない状態です。 import は、対応する resource の記述が tffile に存在していないと動作しないため、 import 実行前にこれだけは必要になります。

$ cat main.tf
resource "aws_lambda_function" "example" {
}

$ terraform import aws_lambda_function.example exampleFunction
aws_lambda_function.example: Importing from ID "exampleFunction"...

import が完了次第、 import した resource を引数にして terraform state show を実行します。するとこのように、 tfstate の記述を元にして、現在の設定情報が HCL の形で出力されます。

$ terraform state show aws_lambda_function.example
# aws_lambda_function.example:
resource "aws_lambda_function" "example" {
    arn                            = "arn:aws:lambda:ap-northeast-1:999999999999:function:exampleFunction"
    function_name                  = "exampleFunction"
    handler                        = "Handler"
    id                             = "exampleFunction"
    invoke_arn                     = ...
    last_modified                  = "2019-12-13T03:35:41.026+0000"
    memory_size                    = 512
    ...

    timeouts {}

    tracing_config {
        mode = "PassThrough"
    }
}

あとはこれをコピペして tffile を fix すれば取り込み完了です。 terraform state show が v0.12 より HCL 形式で出力されるようになったことで、取り込み処理が非常に楽になりました。注意点として、この HCL には tffile には必要のない attributes references に該当する値も含まれています。そのままにしていても害はありませんが、不要な値を持っておくべきでもありませんので削除しておきましょう。 attributes references について詳しくは、本ブログの Terraformer が import した resource は不要な属性を含む場合がある · the world as code を参照してください。

tfstate の保存場所を変更したい

tfstate を現在の保存場所から別の場所へ移したい場合があると思います。最近であれば Terraform Cloud がローンチされた際、 S3 などから移行した方は多かったでしょうし、 S3 内でファイルの key（パス）だけ替えたいといった需要もあるかと思います。

この操作は意外と簡単で、まず一度 terraform init を実行してから、 tffile の backend の部分を移行先のパスに書き換えてもう一度 terraform init を実行するだけです。 Terraform が以下のように backend の変更を検知して、 tfstate ファイルを移動させるか尋ねてくれます。これを承諾すれば、 Terraform がファイル移動を賄ってくれます。

これは「入門」の項で記載した ./.terraform/terraform.tfstate に書かれた backend 設定と、 tffile に書かれた backend 設定に差異があったとき、 backend が変更されたとみなして実行される処理です。

tfstate の編集

tfstate の編集が必要になるのは、 tffile、 tfstate、現実のリソースの三者間で乖離が発生してしまい、 terraform plan の結果が予期せぬものになってしまうような場合です。 tfstate が変更されてしまった、というケースは無いものとして考えると、 tffile を変更したか、現実のリソースを変更したか、いずれかの場合ということになります。このうち現実のリソースを変更した場合については、先にも触れましたが terraform refresh コマンドを実行すれば事足ります。

tfstate の編集 - tffile を変更（リファクタリング）した場合

最も手数を要するのが、リファクタリングなどにより tffile 上の resource name を変更したり、 module の構成を変更したりした場合です。 aws_instance.foo を aws_instance.bar にリネームした場合、 tfstate 上の foo は tffile 上に見つからないので削除対象とされ、 tffile 上の bar は tfstate 上に見つからないので新規構築対象とされてしまいます。

このようなときには terraform state mv コマンドを使って、変更前の名前から変更後の名前へと移し替えていきます。先の例で言えば

$ terraform state mv aws_instance.foo aws_instance.bar

となります。この aws_instance.foo のような記述形式は Terraform のドキュメント内で address と呼ばれています。 address の書式は resource type と resource name をドットで繋いだ形です。 module に内包された resource の場合は module.(module 名).(resource type).(resource name) の形になります。 module を入れ子にしていると、さらに module.(module 名).module.(module 名)... と数珠つなぎで繋がっていきます。

mv の対象がかなりの数に上ってくると、 address を手で書いてコマンド実行するのが面倒になってきます。こういうときは一旦 terraform plan を実行してしまいましょう。先に書いた通り、 mv 前の tfstate に残っているリソースは削除対象に、 mv 後の tffile に新しく命名されたリソースは新規構築対象になるので、 will be (destroyed|created) という文字列で grep することで、 mv 前後の address をそれぞれ取得できるはずです。

あとはいい感じに shell script にでも編集し直して実行してしまいましょう。

tfstate の編集 - リスト化した場合

注意が必要なのが、もともとバラバラに定義していたリソースを、 count などで一括処理する形へ変更した場合です。この場合、 mv 先は aws_instance.web_servers[0] のようにリストの1要素という形になりますが、この web_servers というリスト自体が tfstate にまだ存在していない状態だと、そのリストへ要素を追加するという処理は実行できません。

対処としては、一旦 count = 0 として、リストを空の状態で terraform apply を実行し、 tfstate へリストを作成した上で mv を実行することになります。

tfstate の直接編集

さて、最後に禁断の tfstate 直接編集についても少し触れておきます。禁断の、と言っても本当に手で編集してほしくなければバイナリにするでも暗号化するでも方法はあると思うので JSON で書くということはそういうことなんでしょう、とは思っています。

とは言ったものの、私は直接 tfstate 編集することはここ2年ぐらいもうやっていないような気がします。 state サブコマンドの実装でかなり状況が改善されつつはあるというのが1つ。それでも編集が必要なケースについては、もう諦めて Terraform を書き直したほうが早いと思っているのが1つ。 tfstate 直接編集はあまりに尖ったスキルすぎて、チーム内での共有などがしづらいというのが1つです。

Terraform が多少乱れたり使い物にならなくなったところで、先述したように import などを上手く使えば、ゼロから作り直すこともできなくはありません。 Martin Fowler が提唱した「犠牲的アーキテクチャー」という考え方がありますが、一旦すべて書き直したほうが結局コストも低く、クオリティも高くなる可能性はあります。 tfstate を直接編集しなければならない状況に追い込まれたら、そのように思考を転換するのも一手かと思います。

どうしても直接編集をする場合は、 terraform state pull > terraform.tfstate で一度ダウンロードしてから編集を行い、完了後に terraform state push terraform.tfstate する形を取ります。編集中は terraform plan -state=terraform.tfstate をこまめに行い、致命的な編集ミスがないことを都度確認することを勧めます。

最後に

自分の経験として、 Terraform を使っていて悩まされる機会が多いのが tfstate です。そこでいくつかプラクティスをまとめて記事にしようと思っていたのですが、いつの間にか分量が膨らみ、どうせならと網羅的な「概論」という形になってしまいました。

tfstate の挙動や背景を知ることで、 Terraform への理解も一層深まると思いますので、ここに書いていないことについても是非深堀りしてみてください。

更新履歴

• 2021-08-22 : terraform plan 時における refresh の実行に関して追記。

Terrraforrm meetup tokyo について

Terraform ユーザーグループによるイベントは月1回開催されており、この meetup と source code reading が交互に行われます。 meetup は今回が3回目の開催で、自分は前回に続き2回目の参加でした。

LT や発表枠ももちろんあるのですが、この meetup で特徴的なのは World Cafe だと思います。 World Cafe の定義について、詳しくは ワールド・カフェとは？ | ワールド・カフェ・ネット に譲りますが、 meetup ではランダムな最大6人グループで自由に議論する時間が30分×2回設けられています。 Terraform はまだ枯れきったソフトウェアとは言い難く、ベストプラクティスの模索が常に行われているような状況なので、ユーザー間でユースケースを共有し合えるこのような試みは、非常に有意義に感じています。

イベントレポート

以下、簡単に今回のレポートです。

スポンサー枠: Terraform Enterprise を導入して Terrform v0.10 から v0.12 に上げた話 / sudoyu

Terraform Enterprise の導入レポートでした。現在だと Terraform Cloud も同様の機能を持っていると認識していますが、社内のコード管理に IP アクセス制限をした GitHub Enterprise を用いており、その制約上 Cloud は導入が難しかったとのこと。気になるのは金銭面ですが、「 Terraform スペシャリストを雇うより安いと判断した」という言葉が印象的でした。

LT1: terraform vs cdk / oracle

最近新たに AWS コード化界隈に参戦した cdk と Terraform の比較の話です。 Terraform で言う hoge が cdk では fuga に対応する、というようなことがまとめられているので、概念理解の助けになりました。まだ cdk は触ったことがないので、触ってみたいところ。

LT2: GitHub Actions で Terraform を plan/apply してみた / dehio3

GitHub Actions の workflow はすでに公式で hashicorp/terraform-github-actions: Terraform GitHub Actions が公開されています。プルリクをトリガーして plan した結果をコメントに貼ってくれる、王道な workflow を簡単に導入できちゃうのがいいですね。

LT3: Deep Dive HCL / Keke

Terraform の tf ファイルを記述する際には HCL と呼ばれる言語（書式？）が使われますが、その構造や仕様について説明された LT でした。私も HCL のパースなどに使える hashicorp/hcl は少し読んだことがありますが、 仕様のホワイトペーパー が公開されていることは知りませんでした。後で読んでおきたい。

LT4: インフラ実装をUMLで設計する / Toshihiko Nozaki

Infrastructure as Code に関しても、きちんと UML を書いてコンポーネント分割して書こうというお話でした。このあたりの話はすごく興味があります。Kief Morris『Infrastructure as Code』でも、 Robert C. Martin『Clean Code』を挙げた上で、「インフラストラクチャのコーダーにも、ソフトウェアデベロッパと同じくらい重要なテーマだ」と書かれています（p.184）し、メンテしやすいコードを書くことは追求していきたい。

LT5: 各環境とRoot Module(tfstate)・workspaceの対応付けパターンを比較してみた / k_bigwheel

開発、検証、本番環境で tfstate を分けることが多いと思いますが、その際に module や workspace をどう使って分割するべきか、というお話。各パターンのメリデメを細かくまとめられた資料が印象的でした。この手の話は空中戦になりやすかったりもするので、きちんと「書いて考える」ことが重要だなーと気付かされました。

World Cafe

World Cafe では Terraform をこれから社内へ導入していきたい方、 GCP で使っている方や AWS で使っている方など、様々なバックグラウンドを持った方とお話ができました。出た話題を簡単にピックアップしておきます。

• CloudFormation や Ansible と比較した Terraform の訴求ポイントはどこか？
• provider のバージョンアップへの追随はどうしているか？
• 社内で認知度が低い場合、どう広めていったらよいか？
• Terraform Cloud をすでに利用しているか？
• Terraform レポジトリのディレクトリ構成はどんな感じ？

Additional LT: 突撃！隣の Terraform / chaspy

ここまででメインは終了ということで私は帰ってしまったのですが、その後の延長線で追加 LT があったらしいです。内容は「突撃！隣の Terraform」ということで、 Kyash とメルカリで実際どのように Terraform のディレクトリ構成を切っているか見に行った話だったようです。これは聞いてみたかった。。。

Impression

前回も今回もそうでしたが、 Terraform のファイルやディレクトリをどう構成していくかという点で悩んでいる人が結構多いという印象を受けました。ていうか私自身がそうです。そういう状況を踏まえても、やっぱり World Cafe で直接情報交換ができるというのはすごく嬉しい機会だなと改めて感じました。次回以降いらっしゃる方は、何か話したいネタ、聞きたいネタを用意してくると捗ると思います。

最後になりましたが、運営いただいた主催者の方々、フード提供いただいた HashiCorp さん、ありがとうございました。

• tmux
• fzf
• ghq
• Starship
• aws-vault

tmux

https://github.com/tmux/tmux

4年ぐらい前に一度入門したものの、 iTerm2 のタブと画面分割があれば別にいいかなという感じで使わなくなっていたのを改めて使い始めた。きっかけになった理由は実はだいぶ些細で、 macOS の全画面表示ってメニューバーを隠してしまうので時間がわからないのが困って、ステータスバーに時刻を表示したくなったというところ。実際使い始めてみるとセッションを作って長くかかるコマンドを裏で実行させたままデタッチして別のことやる、みたいなのがなかなか便利で手放せなくなりつつはある。

以前使っていた tmux.conf を引っ張り出してはみたが、 powerline 周りの設定は忘れているし、学習コストかけたくもなかったので外部プラグインへの依存はやめた。 tmux デフォルトのステータスバーを使って時刻などは表示している。

fzf + ghq

https://github.com/junegunn/fzf

fzf は以前から興味はあったけど使ってなくて、というか動作原理がよくわかっていなかったのだが、ちゃんと使ってみたらすごく便利だった。

複数行のテキストを標準入力から突っ込むと、曖昧検索ができる TUI が開き、そこで検索をして1つ結果を選択すると、その文字列を吐き出すという、日本語で書くとこういう動作をする。例えば git のブランチ切り替えだとか、複数のファイルから1つ選んで開くとか、そういう「多くの選択肢から絞りたい」操作をするのに役立つ。まぁ見たほうが早いと思う。

こういう感じ。ただ、手でこういう風に fzf コマンドをわざわざ打つのではなくて、基本的な使い方としてはよく使うコマンドを関数として定義して .zshrc などに書いておいて、必要に応じて呼び出すという形を取る。

https://github.com/motemen/ghq

これと組み合わせて使うとすごく良いのが ghq 。ローカルに置く git レポジトリを管理してくれるツールで、 .gitconfig に以下のように root となる場所を書いた上で ghq get chroju/chroju.github.io と打つと root 配下に git clone してくれる。そして ghq list で、 root 配下に置かれた git レポジトリの一覧をずらっと出力してくれる。つまり fzf と組み合わせるとこういう関数が書けるということ。これがだいぶ快適で1日100回ぐらい打ってる。

fghq() {
  local dir
  # fzf-tmux は tmux で検索用 TUI をペイン分割して表示してくれるコマンド
  dir=$(ghq list > /dev/null | fzf-tmux --reverse +m) &&
    cd $(ghq root)/$dir
}

他にも fzf はアイディア次第でいろんなことができそう。例えば AWS CLI と組み合わせて、 ec2 describe-instances 結果を食わせてインスタンス停止するとか、よくやるオペレーションを関数化しておいても便利かなと。

ghq と GOPATH

余談的な話。自分は Go を書く機会が多い。で、 Go のレポジトリは最近状況が変わってきてはいるけれど、 $GOPATH で指定したディレクトリを root として、 $GOPATH/src/github.com/chroju/... という具合の場所に置かれるというのがスタンダードになっている。

Go とそれ以外のコードでレポジトリの置き場が替わるのも嫌なので、自分は $GOPATH/src にあたるディレクトリを ghq の root として設定している。幸い Go も ghq も github.com/chroju/chroju.github.io という形でディレクトリを掘って clone してくるので、この設定によって Go でも非 Go でも気にせず同様の構成でディレクトリが管理できている。

このあたりは以下のエントリにインスパイアされている。

https://songmu.jp/riji/entry/2019-03-28-go-modules.html

Starship

http://starship.rs/

プロンプトをいい感じにしてくれる Rust 製のツール。スクショは tmux のときに貼ったものを参照。

以前までは zsh のプロンプト設定を自分で書いていたんだけど、あんまり可読性のいい記法ではないし、しばらく経つと書き方を忘れてしまうので外部ツールに頼って楽をすることにした。 Starship が良いのはシェル依存ではないので、仮に今後 Fish に移りたくなってもそのまま持っていけるということ。 brew install して eval "$(starship init zsh)" したらその瞬間からプロンプトがいい感じになる。

設定も豊富でよい。デフォルトの状態で git 関係の表示、ディレクトリ表示はやってくれるし、カレントディレクトリに go.mod があれば Go のバージョン、 requirements.txt があれば Python のバージョンを表示してくれる。設定の追加もできて、自分の場合は AWS_PROFILE を設定していたらそれを表示するようにしている。基本的には使わない環境変数だけど、たまに動作確認などでセットしたまま忘れてたりするので、事故防止になっていい感じ。

powerline font を求められることだけ面倒なんだけど、たぶん設定変更して絵文字を使わないようにしてやればそれも要らなくなる気がする。

aws-vault

https://github.com/99designs/aws-vault

macOS の Keychain と連携して AWS API のアクセスキーを管理してくれるツール。別の AWS アカウントへ switch する assume role 操作がすごく楽になるのでそれで使っている。以下は README からの引用だけど、 ~/.aws/config をこんな風に書いて aws-vault exec prod-readonly -- aws ec2 describe-instances という具合に実行すると、これで switch ができる。

[profile jonsmith]
region = us-east-1

[profile prod-readonly]
region=us-east-1
role_arn = arn:aws:iam::111111111111:role/ReadOnly
source_profile = jonsmith

重宝するのは、これで Terraform も assume role での実行ができること。以前 Terraform で AWS assume role が使用できない場合がある · the world as code で書いたとおり、基本的に Terraform は assume role に対応できていないので、この方法を使うのが一番ラクだと思う。

Conclusion

https://github.com/chroju/dotfiles

今書いたような設定は全部 dotfiles としてレポジトリにまとめているので、コードで見てもらったほうが早いのかも知れないです。 Ansible 流して会社 macOS の設定が数分で終わったときにはやるやんけ自分ってちょっと思いました。

先週開催されたこちらのイベントに参加しました。

参加の動機

Terraform の AWS provider には何度か commit 経験はあるものの、 Terraform 本体のソースコードや、本体と provider 間のやり取りに関してはあんまり読んだことがなくて、コードリーディングを進めてみたかったというのが1つ。また自分はソフトウェアエンジニア出身ではないので、そもそものコードリーディングのやり方があんまり効率良い感じがしていなくて、他の方々（特に Terraform なのでインフラ寄りの方が多そうだし）がどんな感じで読んでいるのか知りたかったのが1つという感じです。

ソースコード読んでコントリビュートもしている人が参加する勉強会となるとそれなりに強い人がいっぱいいそうでだいぶドキドキしてました。

当日の流れ

当時は20人に少し足りないぐらいの人数が参加してましたが、全員で1つのことをやるのではなく、読みたいソースコードごとにグループ分けがありました。具体的には Terraform 本体を読むグループ、 AWS provider を読むグループが2つ、その他の provider を読むグループが1つの計4グループ。私はと言えば AWS provider を読んでました（あれ？）。

で、特に当日は決められた筋書きはなし。各グループで集まった人同士でやりたいことを話し合って決めて、それぞれで進めていき、最後に全員で一言ずつ成果報告をするという形でした。

やったこと

私のグループでは issue を漁ってプルリクエストを送れそうなものがあったら送ってみようという形で進めました。4人グループで、 contribute 経験者が私含めて2人、他2人はこれからやってみたい、という感じでした。

contribute チャンスをどう見つけるか

しかし正直結構難しい。例えば OSS contribute を志し始めた人へのアドバイスとして good first issue ラベルが付いたものが取り組みやすい、というものがありますが、今日時点で2299件中17件しかありません。 もちろん絶対数で見ればそれなりの数がありますけど、比率で言うと1%未満だし、年単位で塩漬けにされている issue も多くて必ずしも手を付けやすいものではないかなという印象がありました。

当日1つ、 Pull Request のきっかけとして有力な方法かもしれないと見つけたのが、 aws-sdk-go の release を定期的に見ること。これがなかなかエゲツない頻度で更新されていて、 API が更新されれば Terraform 側にもそれを吸収しなくてはならない場合というのが当然出てきます。なので aws-sdk-go 側の更新を見張っていれば contribute チャンスも見えてくるのではないかと。

あとは自分の経験上ですけど、ドキュメントに小さな誤字があることは案外多いのでチャンスも転がってますよという話をしました。実際、当日ドキュメント修正で時間内にプルリクエストを上げられた方がいました。

Terraform のコードはとにかく膨大なので、なかなか contribute するぞ！という目的で挑んでも難しい部分がある気がしました。自分のこれまでを振り返ってもバグを踏んでから contribute に至ったのがほとんどです。

validators.go に関する知見

https://github.com/terraform-providers/terraform-provider-aws/issues/9445

これは個人的な話ですが、以前上記 issue にハマったことがありました。 aws_route resource には、ルーティング先に各種ゲートウェイを指定する nat_gateway_id や transit_gateway_id といった argument があります。本来であればゲートウェイの種類ごとに異なる argument を遣うべきところ、 gateway_id という argument が NAT ゲートウェイとインターネットゲートウェイのどっちも受け付けちゃうんですね。なので値のバリデーションをして、 NAT ゲートウェイは受け付けないようにするべきというのがこの issue です。

この issue 、私はバリデーションの実装方法に迷ったのと、すでに author が自分でやると言っていたので放っておいてました。しかし今回の勉強会でこの話をしたところ、 validators.go というファイルがあり、ここにバリデーション処理が集約されていると教えてもらいました。自分で気付けていなかったことを知ることができてとても有意義な経験でした。

これでプルリクも出せるようになったし、先の「俺がやる」と言ってる人も数か月放置してるから、もうこっちで出しちゃってもいいかなと思ってます。

感想

みんなで議論をするような形を想像していたところ、もくもく会に近い雰囲気だったのでちょっと想像とは違いました。が、具体的にコードを踏まえた話が出来たのは楽しかったです。 Terraform ユーザーグループはこの Code Reading と meetup を交互に繰り返す形ですが、いずれもただ前に出た人が発表するのではなく、参加者同士話す場を中心にしているのがとてもいいなと思いました。

ただグループ分けに関してはレベル別とか目的別とかでもいいんじゃないかなーという気はしました。読む対象レポジトリごとのグループ分けだと、メンバー間の意識や目的をなかなか揃えにくく、どうしようかと悩む、迷う時間が少なくなかったです。あるいは個々人で目的を持って読んでいくもくもく会的な感じですよ、と言い切ってしまうか、かなと。

ちなみに読んだだけで終わるのもアレだったので、後日ですが issue 1個解決を図ってみました。定期的に issue を覗いてやれそうなものにチャレンジしていくのも勉強としては良さそうです。

https://github.com/terraform-providers/terraform-provider-aws/pull/10819

以前このブログの 3rd Party tool をきっかけに Terraform のソースコードを少し嗜んだ話 · the world as code というエントリーでも取り上げた terraformer 。既存のクラウドリソースを元に terraform file を作成してくれる便利ツールなのだが、時に必要ない属性値を resource に含んだファイルを作ることがある。

resource "aws_s3_bucket" "tfer--chroju-002E-net" {
  acl            = "private"
  arn            = "arn:aws:s3:::chroju.net"
  bucket         = "chroju.net"
  force_destroy  = "false"
  hosted_zone_id = "XXXXXXXXXXXXXX"
  region         = "ap-northeast-1"
  request_payer  = "BucketOwner"

  versioning {
    enabled    = "false"
    mfa_delete = "false"
  }

  website {
    index_document = "index.html"
  }

  website_domain   = "s3-website-ap-northeast-1.amazonaws"
  website_endpoint = "chroju.net.s3-website-ap-northeast-1.amazonaws.com"
}

例えばこれは自分の S3 バケットを import してみた実際の結果（一部マスクあり）なのだけど、いくつか不要な値を含んでいる。具体的には arn , website_domain , website_endpoint の3点。ドキュメント AWS: aws_s3_bucket - Terraform by HashiCorp を見るとわかるが、これらは Attributes References 、つまり他の resource から参照可能な属性であって設定に必要な値ではない。

ではこれは余計な値でバグなのではないか、と思いたくなるところなのだけど、面白いのはこのまま terraform コマンドを打ってもエラーにはならないということ。以下、試しに ARN を hogefuga という値に変更して terraform apply して、その後再度 plan で結果を確認してみたサンプルを貼る。

ARN は AWS 側が一定の法則に則って自動採番する ID であり、当然ながらユーザーが任意で変更はできない。それなのに plan の結果として ARN の変更は予告され、そして apply も通ってしまうのが面白い。しかし apply 後に plan を実行すると、依然差分として表示はされるので、実際に apply が通ったわけではない。当たり前だけど、ちょっと挙動としては不安にもなる。

ちなみにこの状態から ARN を削除してみても、 terraform plan の結果は No Changes になり、 ARN が削除されるようなことはない（そりゃそうなんだが）。そのため Terraformer の import 結果に不要な値が含まれていたら、運用上の混乱を避ける意味でも、手で削除してしまうのが無難ではある。

原因

ではなぜこのような挙動になるのかだが、原因は Terraform の実装にある。

Terraform の各 resource にどのような attributes を含むかは、 &schema.Resource.Schema に map の形で定義されている。 AWS S3 の場合は terraform-provider-aws/resource_aws_s3_bucket.go at master · terraform-providers/terraform-provider-aws で、冒頭だけ抜き出すとこのような形。

		Schema: map[string]*schema.Schema{
			"bucket": {
				Type:          schema.TypeString,
				Optional:      true,
				Computed:      true,
				ForceNew:      true,
				ConflictsWith: []string{"bucket_prefix"},
				ValidateFunc:  validation.StringLenBetween(0, 63),
			},
			"bucket_prefix": {
				Type:          schema.TypeString,
				Optional:      true,
				ForceNew:      true,
				ConflictsWith: []string{"bucket"},
				ValidateFunc:  validation.StringLenBetween(0, 63-resource.UniqueIDSuffixLength),
            },

そしてここに並列で Attributes References に含まれる値も並んでいる。どれが Arguments （設定値）でどれが Attributes なのかを識別できるような箇所はない。そのため resource の中に Attributes にあたる値を書き入れても、エラーにはならない。

また Terraformer を使用した際の挙動としては、 Terraform の refresh コマンドに相当するメソッドを呼び出す形になる。 refresh といえば現在のクラウドリソースの状態を取得して、 tfstate を書き換えるというもの。 tfstate 側には Attributes に相当する値も含まれているため、 refresh を呼ぶ形だと Attributes も一緒に読み込んでくる形になる。だから Terraformer が作成する tf ファイルには、 Attributes が含まれるということになる。

現状、先述の通り Terraform の実装として Arguments と Attributes を識別する方法がないため Terraformer がこのような挙動をするのはやむを得ないと考えている。 Terraformer は Terraform の API を効率よく活用することで、個々のクラウドリソースの API を最小限にしか知る必要がない形で実装されている。各値が Attributes かどうかという情報は Terraform 側が持つべきであって、 Terraformer に実装させる必要はないだろう。幸い、見てきた通り Attributes を含めても Terraform はエラーにならないので、割り切ることもできなくはない。

Impression

以上、トリビアに近い小ネタを書いてみた。きっかけは実際に terraformer を使っていてこの挙動に気づいたことなのだけど、もうすぐ Terraform Source Code Reading#3 - connpass というイベントに参加することもあり、少し Terraform のコードを読む機会が欲しかった形。このイベント、それなりにレベル高いことやろうとしてるので、生きて帰れるのかむちゃくちゃ不安。

まず最初に断っておくと、2019年8月に発表された GitHub Actions をこのエントリーでは「新版」、それ以前のものは「旧版」と表記する。タイトルも「新版」にしようかと思ったが、今後またリニューアルされた場合にどれが「新」なのかわからなくなるので「(2019)」とした。GitHub は新版に対して「GitHub Actions v2」とか、何かしら旧版と識別できる名称を付けるべきだったと思う。ググラビリティが著しく低くてわりと困っている。

Actions を書いたのは以下の2レポジトリ。前者はこのブログを支える hugo の自動化で、 source ブランチに push するとビルド結果を master へ push してくれる。後者は Go の一般的なビルドで、タグを切るとテストしてビルドしてバイナリを GitHub Release に貼ってくれる。

https://github.com/chroju/chroju.github.io

https://github.com/chroju/parade

何が変わったのか

GitHub Actions 旧版については昨年末に公開されて早々に触り、このブログにも感想を書いている。

• 関連 : GitHub Actions - Dockerfile を突っ込んで自動化するという考え方 · the world as code

当時との差異として強く感じるのは2点ある。1つ目は記述言語自体変わったことで、 HCL から YAML に変わった。そもそも HCL は HashiCorp Configuration Language という名前通り、 もともと Terraform などの HashiCorp 製ツールの中だけで使われていた DSL なので、 HashiCorp と関わりの薄い GitHub がなぜ HCL を採用したのかが疑問だったし、これでよかったのではないかという気がしている。

2つ目は Action の実行環境。先のエントリーでも書いたが、GitHub Actions 旧版は一連のプロセスが Action という単位に分割され、 実行環境は各 Action で Docker コンテナが個別に起動されていくという形を取っていた。一方の新版では、 Linux / macOS / Windows の中から選んだ VM をワークフロー全体を通した実行環境として利用する。各 Action において旧版同様に Docker コンテナを立ち上げることもできるが必須ではなく、 VM 上で直にコマンドを実行させることもできる。これにより、ちょっとしたコマンドを実行したいときでさえ Dockerfile を書かなくてはならないというようなことは無くなったので、設定の柔軟性が高くなったと感じる。またワークフロー全体で1つの実行環境を共有するようになったことで、ソースを checkout してビルド、テストしてデプロイするという流れを組む、一般的な CI/CD 相当の Action を書きやすくなった。

もともと GitHub Actions は「CI/CD だけではなくて、 DevOps 全体における自動化サイクルを構築するもの」とされていた。先のエントリー内でもリンクした GitHubからワークフロー自動化ツール、Actions登場――独自サービス提供の第一弾 | TechCrunch Japan を読むとよくわかる。

誰かがリポジトリで「緊急」というタグを使った場合、Twilio を使ってメッセージを送信するという仕組みを作ることができる。レポジトリを検索する一行のコードを書いてgrepコマンドで実行することもできる。

つまり、レポジトリに直接紐付けられた FaaS に近いものを作ろうとしていたように見える。しかし実際のところユーザーが旧版でやろうとしたことの多くは CI/CD の範囲であり、今回の新版では、 CI/CD に軸足を置いた旨が明確に示されている。

https://cloud.watch.impress.co.jp/docs/news/1205405.html

Impression

自分のレポジトリ2つほどで使ってみた経験から感じたことを書こうと思うが、本職プログラマーではないためゴリゴリに重いビルドの CI で苦労した経験などが少なく、書けることは限定的だと思う、と前置きする。

CI を始めるのに必要なことが YAML を書くことしかない

YAML を書いて push すればそれだけでジョブが始まるのは体験としてすごく楽。 Circle CI にせよ AWS の開発者向けツールにせよ、何かしら GUI 操作は避けられなかったが、 GitHub Actions は完全に YAML だけで済む。 GITHUB_TOKEN という環境変数が自動的に発行されるので、自レポジトリへの操作も簡単にでき、タグを切る、 release にバイナリを添付するといった、 GitHub 上でやりたかった操作はだいたいすぐに出来るようになる。

Action を共有できる

ワークフローを組み立てる個々の Action は Docker コンテナか JavaScript で書くことができる。 Docker の Action は Dockerfile とその中で実行する処理内容を書いた entrypoint.sh 、 GitHub Actions 向けのメタ情報を書いた yaml から成るのだが、これを GitHub レポジトリで公開して、他者と共有することができる。 Circle CI の Orbs に近い。

すでに GitHub が公開する Action が https://github.com/actions にいくつか設けられており、これらは例えば Go や node.js といった言語環境構築といった、広く使われうるものが準備されている。その他 OSS などが Action を公開している場合ももちろんあって、例えば GitHub Release に Go のバイナリを添付してくれる goreleaser という CI で絶対使いたい超便利ツールがあるが、すでに Action を公開しており、簡単に導入できる。

https://github.com/marketplace/actions/goreleaser-action

Trigger が豊富

旧版の頃からそうだったけど、 Trigger が豊富なのがいい。 Git のプルリクエストや push をトリガーにする場合に、特定のファイルが変更されたのみトリガーさせることができるとか最高（インフラマンなので、インフラ用レポジトリに Ansible と Terraform 両方詰め込んでたりがあるあるなので、ディレクトリ単位で実行振り分けしたいことは多い）。

あと使い道は思いついていないが cron で定期実行できるのも興味深かった。 CI / CD を時間トリガーで実行したいケースはあまり無かろうと思うので、どちらかといえば先述のように旧版から希求していた「DevOps全体における自動化サイクルを構築する」ためのものだろうか。例えば issue の自動的なチェックだとか、レポジトリに関係する自動化タスクはここに定義しておくと見通しが良くなりそうではある。

長々と書いたけど個人的には楽、とにかく管理が楽というそれに尽きる。最近特に AWS Code 3兄弟をガチャガチャする機会が多くて Terraform 書いたり GUI ポチポチしたりというのに疲弊していたので、余計に「YAML 置けば OK」というのが魅力的に見えてるのだとは思う。もちろん他のツールのほうが利がある部分もあるわけだが、積極的に使っていきたいなとは感じている。

AWS Systems Manager のパラメータストア をよく使っている。例えば Git で管理ができない秘匿情報を SecureString の形で保存しておいたり、 Infrastructure as Code を実行する際、 Terraform で構築したリソースの設定値を Ansible に橋渡しをするために使ったり、各種ツールやアプリケーションで参照したい設定値の保管場所として便利に使うことができる。

欠点として、今どんな値が格納されていたか？　どんなキー名で格納されていたか？を確認したいときの操作が若干面倒というのがあった。マネジメントコンソールではキーの一覧から、目当てのキーをクリックしてページ遷移しなければ値を見ることができない。またキーを検索する場合も、完全一致か前方一致での検索しかできず、目的のキーをなかなか探せないことが多かった。まぁ AWS CLI を grep などと組み合わせてうまいこと使うのが解なのだろうとは思うのだけど、手を動かす題材としても良さそうだったので、 go で CLI ツールを作って対処することにした。

Parade

名前にあまり意味はない。パラメータストアなので "para" の付く英単語がいいなと適当に探して命名した。みんな OSS の名前ってどうやって決めてるのか教えてほしい。

シンプルに値を読み書きすることだけ、もっと言えば読むことだけが目的だったので、機能は少ない。コマンド体系は redis-cli を参考にしていて、 keys, get, set, del の4つのサブコマンドから成る。先述の通り、キーの検索が面倒というのが発端になっているので、特に get を強化した。何もオプションを与えなければ get hoge でキー名 "hoge" がある場合に限り値を出力するけれど、キー名の記憶が曖昧な場合などは --ambiguous あるいは -a オプションを付ければ部分一致するキー名をすべて拾ってきてくれる。このとき、一致箇所を赤字で表示するようこだわってみた。また SecureString にも対応していて、自身に復号の権限さえあれば、 -d オプションで復号した値を出力することもできる。

逆に set で値を登録するときは、任意のキーIDを指定した暗号化ができない（デフォルトのキーでの暗号化は可能）など、機能は現状最小限になっている。本当に手元でサクッとパラメーターを確認することを意図したツールにしている。

類似ツール

似たところだと segmentio/chamber が挙げられると思う。が、 chamber はあくまでシークレットマネージャーツールであることが主眼に置かれており、そのバックエンドとしてパラメータストアが使えるだけなので、パラメータストアの読み書き自体を目的とした parade とはちょっと軸足が違うかな、と思っている。

使用技術

いくつか初めて使う技術を盛り込めたのでよかった。

aws-sdk-go

AWS 関連のスクリプトを書く際は Python の boto3 を使うことが多く、今回 aws-sdk-go はほぼ初めてちゃんと使う機会になった。ドキュメントは AWS Documentation として公開されてもいるが、個人的には GoDoc のほうが慣れもあって読みやすかった。

またユニットテスト用の mock が用意されているのが嬉しい。 Parade ではパラメータストアへのアクセス部分で以下のようなコードを書いている。

type SSMManager struct {
	svc ssmiface.SSMAPI
}

func New() (*SSMManager, error) {
	sess := session.Must(session.NewSession())
	svc := ssm.New(sess)

	return &SSMManager{
		svc: svc,
	}, nil
}

func (s *SSMManager) GetParameter(query string, withDecryption bool) (*ssm.Parameter, error) {
	params := &ssm.GetParameterInput{
		Name:           aws.String(query),
		WithDecryption: aws.Bool(withDecryption),
	}

	resp, err := s.svc.GetParameter(params)
	if err != nil {
		return nil, err
	}

	return resp.Parameter, nil
}

最初に定義した構造体 SSMManager に埋め込んでいる ssmiface.SSMAPI が、各 API を呼ぶメソッドを実装した Interface になっているため、ダミー値を返すメソッドを書いた mock を用意することで、ユニットテストができるようになっている。

type mockSSMClient struct {
	ssmiface.SSMAPI
}

func NewMock() *SSMManager {
	svc := &mockSSMClient{}

	return &SSMManager{
		svc: svc,
	}
}

func (m *mockSSMClient) GetParameter(i *ssm.GetParameterInput) (*ssm.GetParameterOutput, error) {
    return &ssm.GetParameterOutput{Parameter: p}, nil
}

spf13/cobra

https://github.com/spf13/cobra

Go のコマンドラインツールを作るためのパッケージの1つ。競合として urfave/cli や mitchellh/cli もあるが、 cobra が現時点で最もスター数が多く、用例も多いのかなと勝手に思っている。作成者が Docker, Google, MongoDB あたりに関わっているゲキヤバな人であることもあってか、 kubectl や Istio などでも使われている。

使ってみた感想としてはなんでも出来る、そしてサクッと書ける良いツールではあった。が、サブコマンドのテストが書きづらい。というのも、以下のように &cobra.Command で変数として定義する方式を取るから。

var versionCmd = &cobra.Command{
  Use:   "version",
  Short: "Print the version number of Hugo",
  Long:  `All software has versions. This is Hugo's`,
  Run: func(cmd *cobra.Command, args []string) {
    fmt.Println("Hugo Static Site Generator v0.9 -- HEAD")
  },
}

func init() {
  rootCmd.AddCommand(versionCmd)
}

この点を気にする人は多いようで、検索するとワークアラウンドはいろいろと出てくる。

• Testing a Cobra CLI in Go - Brad Cypert
• Cobra の使い方とテスト — プログラミング言語 Go | text.Baldanders.info
• go - Cobra + Viper Golang How to test subcommands? - Stack Overflow

またコードを見るとわかる通り、サブコマンドが error を「戻さない」のも感覚的に慣れなかった。 cobra.Command.Run ではなく cobra.Command.RunE を使うと error を戻せるのだが、試しに戻したところ勝手に Usage をまるっと出力されてしまって、出力しないようにするにはどうしたらいいのか探すのが面倒になって諦めた。なんでも出来るツールはその分内部がブラックボックスにはなりやすいわけで、個人的には薄い実装のほうが好みなのだと思う。

GitHub Actions

Pull Request を発行したときの golint やテストの実行と、 tag を切ったときのバイナリ生成と GitHub Release への添付を GitHub Actions で書いている。初めて書いてみたけど正直まだ感覚がつかめていない。このブログを生成する hugo の実行を今 CircleCI にまかせているので、それを GitHub Actions へ移すときにもう一度学んでみて記事にしようと思っている。

GitHub Release へのバイナリ添付には goreleaser を使った。すでに GitHub Actions で使うための Action を公開してくれているので、めちゃくちゃ便利に扱えて感動した。

https://github.com/marketplace/actions/goreleaser-action

改めて SRE を定義する

SRE の職種で転職活動をしていたとき、カジュアル面接で「SREとはなんだと思うか？」と聞かれたことがあった。そのときには「ソフトウェアエンジニアリングを用いてシステム運用を行うこと」と応えているが、今から考えると「半分正解」ぐらいの応えだったように思っている。

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

posted with amazlet at 19.09.21

オライリージャパン
売り上げランキング: 79,446

Amazon.co.jpで詳細を見る

定義は原典から引くべきだと思うので、『SRE book』を確認してみると、第1章にまずこのように書かれている。

SREとは、ソフトウェアエンジニアに運用チームの設計を依頼したときにできあがるものです。

SREは、これまで運用チームが行ってきたことをソフトウェアの専門性を持つエンジニアが行い、エンジニアが人手による管理を自動化するソフトウェアを設計し実装する能力を持ち、それをいとわないということから成り立っています。

やはり運用とソフトウェアエンジニアリングを結びつける内容が書かれていて、先に挙げた私の回答が間違っているわけではない。「半分正解」と書いたのは、それではなぜソフトウェアエンジニアリングを運用業務に持ち込まなくてはならないのか、という部分まで押さえていなかったからだ。

常にエンジニアリングを行っていなければ、運用にまつわる負荷が増大し続け、負荷についていくためだけでもチームにはさらに多くの人数が必要になります。最終的には、運用に注力する旧来のグループは、サービスのサイズに比例して大きくなってしまいます。

つまり、サービスの拡大に比例して増大していく運用負荷を抑えるという目的に対して、ソフトウェアエンジニアリングによるレバレッジを利かせることによって対応する職種、それが「SREの定義」に対する完全な答えになると考えている。ソフトウェアエンジニアリングを用いることは SRE の一側面であることは確かだが、あくまでそれは手段である。 SRE の目的は、その職種名自体が表しているように、サービスの信頼性を維持することであって、そのための効率的手段としてソフトウェアエンジニアリングが位置づけられる。

また「信頼性」という言葉も定義しておかなくてはならなさそうだが、ここでは SRE book の謝辞 注釈にある、以下の文を引いておく。

ここでは、信頼性とは「［システムが］求められる機能を、定められた条件の下で、定められた期間にわたり、障害を起こすことなく実行する確率」です。

インフラエンジニアと SRE

ソフトウェアエンジニアが運用を担うということがことさらに強調されているということは、これまでシステム運用を担ってきたのはソフトウェアエンジニアではないということになる。海外での実情や職種の分かれ方はよく知らないが、日本ではインフラエンジニアが運用を兼ねる場合が多かったように思う。その後近年の SRE ブームも手伝って、インフラチームと呼ばれていた部署を SRE に改組する企業が増えてきた。国内での SRE ブームに火を点けた、 SRE という職種を初めて広めたのはメルカリだと思っているのだが、同社でも SRE チームはインフラチームから発展したものだった。

しかし SRE がソフトウェアエンジニアリングを生業とする集団であるとするならば、インフラエンジニアがそのまま「今日から SRE になります」と言って簡単になれるものではない。 SRE はインフラエンジニアが単純に次世代型へ移行したものではない。ソフトウェアエンジニア、インフラエンジニアという、技術領域を元にした職種の分類ではなく、 SRE は信頼性という責任領域を後ろ盾とした職種になる。そこで必要とされる技術はソフトウェアエンジニアリングはもちろん、信頼性を担保する上ではインフラ部分への理解も欠かせず、非常に手広いものになる。

SRE のブームが来る少し前に Infrastructure as Code のブームが始まり、インフラエンジニアもコードを書けなくてはならないという風潮は出来上がっていた。ただ、 Infrastructure as Code で実際に書くものは多くの場合 YAML や HCL といった定義ファイルであり、ソフトウェア開発に至るわけではない。「運用」という側面で一致しているとはいえ、インフラエンジニアから SRE への移行は、それなりに大きなハードルを乗り越えるジョブチェンジになる。

エラーバジェットとトイルバジェットから始める SRE の実践

僕もインフラエンジニアから SRE へ移った身だし、正直なところ現段階でソフトウェアエンジニアリングが得意だと言い切れもしないのだが、ではそういったエンジニアが SRE をやることが無意味かと言えば、そうも思わない。ソフトウェアエンジニアリングを主戦場としてこなかった人間が SRE を実践することにももちろん意味はあると思っている。

冒頭で書いたようにソフトウェアエンジニアリングは SRE に求められる「半分」の側面であり、もう「半分」はサービスの信頼性確保という大目的の部分である。 SRE ではこれを「エラーバジェット」という考え方を導入することにより実現している。100％の可用性を闇雲に目指すのではなく、そのサービスに必要な可用性を SLO として定めた上で、その可用性目標を1から引いた値をエラーバジェットとして設けることにより、バジェットが満たされるまではリスクを取ってサービス開発しても良いものとして運営する。これにより、ただただ「守る」ことを考える従来の運用メソッドとは異なり、サービス開発のベロシティとサービスの信頼性確保という両輪のバランスを、明確な数値目標によって確保できる。株式会社はてなで SRE に従事していた yuuki 氏は、これを「サイト信頼性を制御する」と表現していた。

手段としてソフトウェアエンジニアリングを高いレベルでこなすことができないとしても、まずこの考え方を導入し、信頼性の「制御」に責任を持ったチームとして SRE を設置することは意義があると考えている。特にサービスの拡大、成長が著しく見込まれている場合には、エラーバジェットという考え方がもたらす効用は大きい。

また、もうひとつ SRE の責務として重要な点として、サービス拡大に伴って増加する運用業務、いわゆる「トイル」の抑制が存在する。サービスが急激に拡大する際に足を引っ張りがちなのが、この信頼性確保と、トイルの増大という2点になる。SRE book において、 Google は「トイルを業務量全体の50%に抑える」という目標値を提示しているが、Google が公開しているもう1冊の SRE 関連書籍『The Site Reliability Workbook』では、これをエラーバジェットに対して「トイルバジェット」と呼んでいる。

Workbook では「class DevOps implements SRE」という言葉も出てくる。 DevOps は、すばやくリリースを行いたい開発担当者と、システムの可用性を守りたい運用担当者を対立関係に置くのではなく、両者を協力させていこうという、少々曖昧な部分のある一種の運動だったが、 SRE はこれにエラーバジェットとトイルバジェットという概念を持ち込むことで、両者の協力状況を可視化した。まずはこれを、自社の運用の現場に持ち込んでみることから始めてみてもいいのではないだろうか。まずは自社のサービスにとって、必要な「信頼性」とは具体的にどのような値であり、どの程度の数値を目標にするべきか SLO を考えなくてはならない。シンプルにサービスの稼働率だけ確保できればいいのかもしれないし、レスポンスタイムが一定値以下であることが求められるかもしれない。その数値も99.9%なのか、もうひとつ9を増やすべきなのか、あるいは繁忙期と閑散期、日中と夜間で目標を変えるべきなのかなど、考えることは山のようにある。そしてそれをどう測定するのか。レスポンスタイムはトップページだけで考えていいのか、全リクエストなのか、平均値なのか、パーセンタイルで考えるのか。トイルの計測はより難しいと感じていて、どの仕事をトイルと分類して、どのように所要時間を測るのかを決めなければならない。

ここでは SLO の策定と、それに基づく「測定」から SRE の実践を始めることを書いたが、 SRE を如何に実践していくかについては、 Google がチェックリストを公開している。

このチェックリスト内でもやはり、 SLO の策定はいの一番に上げられている。 SLO 策定 → 計測の開始 → 計測結果を踏まえた問題改善 というサイクルがあってこそ、 SRE は効果的に問題解決に当たれるのではないだろうか。

自分のキャリアと SRE

とはいえソフトウェアエンジニアリングを得意としていないことに甘んじ続けるわけにもいかない。特にトイルを抑制するには、手作業を自動化したり、システムが自律的に動作するようにしたりする上で、何かしらソフトウェアを書く機会というのはほぼ確実に生まれてくる。

SRE としてやっていくにあたって、自分には何が足りないのか。自分のキャリアを改めて振り返ると、専門性を持っていると言えるのは以下の領域と考えている。

• システム監視と復旧手順の作成
• ドキュメンテーション
• Infrastructure as Code
• 種々の自動化

アーキテクチャの知識の必要性

これまで2社務めてくるなかで、構築よりも運用よりのエンジニアとして仕事に従事してきたがために、特にシステムの監視設計と実装、アラートを受信したときの対応手順、復旧手順の作成や、それらのドキュメンテーションといった部分に多く時間を割いてきた。しかしこれらはリアクティブな対応であって、 SRE の文脈ではトイルに分類される部分が多い。そもそも障害を起こさない、あるいは障害が起きても自律的にシステムが復旧するようなアーキテクチャを考えることが、 SRE には求められるはずだ。自分にはそれが圧倒的に足りていない。マイクロサービスアーキテクチャの知識はほぼゼロに等しいし、システムの自律的な動作において不可欠な技術になりつつある Kubernetes にもそれほど詳しくはない。 AWS のマネージドサービスを用いてある程度可用性の高い仕組みを整えることはできるが、まだまだ知らないことも多い。

ソフトウェアエンジニアリングの知識の必要性

またトイルの抑制にあたる業務もやってこなかったわけではなく、特に Terraform や Ansible を用いた Infrastructure as Code の導入や、手作業を AWS Lambda や自前のコマンドラインツールを用いて自動化していくことにも務めてきた。これらの経験はそのまま SRE としても役立つはずだし、実際この3か月の間でも、いくつか自動化の仕組みを整えてきた。これに関しては今後も継続的に伸ばしていきたい。

ただ、改めて思うのは Infrastracture as Code の効果的な実践が難しいということ。 IaC は何が嬉しいのかと言えば、サービスがスケールしたときに、一度コード化したリソースであれば瞬時に環境を準備できるという点が上げられる。しかしその利点を享受するには、再利用性の高いコードを書く必要がある。 Terraform には module 、 Ansible には role という形で、コードをパッケージ化して再利用するための仕組みが用意されている。これを上手く作っていかなくては、新たなサービスや環境が必要なときに、また一からコードを書かねばならず、結局のところ手作業でインフラを構築したほうが早いという結論になりかねない。これでは IaC はトイルと化してしまう。

SRE はソフトウェアエンジニアによるシステム運用の方法論だが、それは直接的にソフトウェアエンジニアリングを行うことを想定しているのみならず、ソフトウェアエンジニアリングの知識が、トイルの抑制のための自動化などに役立つという意味でもあると考えている。100回実行が見込まれる作業Aを自動化することはもちろん意味がある。しかしより意味のある自動化コードとは、それが作業A'や作業A''にも応用できるものである。そのためには業務を適切に抽象化する必要がある。これはソフトウェアエンジニアリングの方法論に近しい。例えば単一責任原則を知っていれば、より変更に強い Terraform module が書けるかもしれない。

問題発見の技術

もう1つ、これまで重視してこなかったが今後重要になるだろうと考えているのが「問題発見」の技術。トイルの抑制、信頼性の確保、いずれも的確にそれらを阻害している要因 = 問題をあぶり出して対処することが求められる。つまりは問題発見の技術である。安宅和人の『イシューからはじめよ』において、ただ闇雲に問題解決に当たり、大量の仕事をこなすことで目的を達成しようとする行為は「犬の道」と呼ばれている。ここではより生産性の高い問題 = イシューを見つけた上で仕事に当たることの重要性が説かれている。

「限界まで働く」「労働時間で勝負する」というのは、ここでいうレイバラーの思想であり、この考えでいる限り、「圧倒的に生産性が高い人」にはなれない。冒頭で書いたとおり「同じ労力・時間でどれだけ多くのアウトプットを出せるか」というのが生産性の定義なのだ。

トイルの抑制を目指す SRE にもこの考え方は必要だ。先に書いたことにも重なるが、闇雲に自動化をしたり、何か改善を加えたりするのではなく、いま本当に必要な自動化や改善はどれなのかを正しく見極めていく必要がある。 SLO の策定と計測も、対処するべき問題を正しく見極めるためのメソッドの1つと言える。

イシューからはじめよ――知的生産の「シンプルな本質」

posted with amazlet at 19.09.21

安宅和人
英治出版 (2010-11-24)
売り上げランキング: 197

Amazon.co.jpで詳細を見る

Conclusion

以上、自分が SRE としてやっていくにあたり、大きく3点の学びを進めていきたい。

• アーキテクチャの知識の獲得
• ソフトウェアエンジニアリングの知識の獲得
• 問題発見の技術の獲得

差し当たっては読みたい本がいくつか上げられたので読んでいこうと思う。ただアーキテクチャの知識という点についてはしっくりくる本が見つかっていない。『大規模サービス技術入門』など非常に良い本ではあるのだが、さすがに古くなっている部分もあり、この本の現代版がほしいなと思っているところ。 ISUCON の過去問なども有益ではないかと考えている。ほか2点に関しては以下の本を候補としている。

Clean Architecture 達人に学ぶソフトウェアの構造と設計

posted with amazlet at 19.09.21

Robert C.Martin
KADOKAWA (2018-07-27)
売り上げランキング: 4,607

Amazon.co.jpで詳細を見る

良い戦略、悪い戦略

posted with amazlet at 19.09.21

リチャード・P・ルメルト
日本経済新聞出版社
売り上げランキング: 29,863

Amazon.co.jpで詳細を見る

3点の中に実際のソフトウェアエンジニアリング、コーディングを入れなかったのは自分でもちょっとおもしろいなと思うのだが、どちらかと言うとソフトウェアエンジニアリングを効果的に行うための方法論のほうが今は重要だと考える故ではある。もちろんソフトウェアエンジニアリングも並行して進めるべきだとは考えていて、 GitHub で Terraform 関係など、 issue に対して PR を投げたり、自分なりのツールを書いたりしていきたい。

考えれば考えるほど難易度が高くて気が遠くなりそうな職種なのだが、それだけ挑戦しがいもあるので、食らいついていきたい。

これまで特に不具合もなく使っていたのだが、 Ubuntu 18.04 を初めて使うにあたり、 DHCP オプションセットに設定できる domain-name をスペース区切りで複数指定したところ、スペースが「032」という文字列で置換された状態で設定されてしまい、 DNS が正常に機能しないという事象が起きた。以下は実際の設定ではないが、こういうイメージ。

$ cat /etc/resolv.conf
nameserver 127.0.0.53
options edns0
search ap-northeast-1.compute.internal032example.com

DHCP オプションセットのドキュメント を見ると、たしかに domain-name の複数指定は「一部の Linux オペレーティングシステム」でしか動作しないとある。しかし「一部」と言われても、ディストリを替えたら動きませんでした、だとわりと困る（今回の場合は 16.04 なら複数指定が動作したが、 18.04 では NG だった）ので、そもそもなぜこの項目が「一部」の Linux ディストリでしか有効にならないのか、 DHCP オプションの仕様から調べ直してみた。

DHCP Options を定義する RFC

そもそも DHCP Options とはなんぞ？という話だが、これは RFC 2132 で定義されている。

Configuration parameters and other control information are carried in tagged data items that are stored in the 'options' field of the DHCP message.

DHCP message の中には 'options' field が設けられており、ここに各種設定パラメータを載せることができる。 DHCP というと IP アドレスやデフォルトゲートウェイの配布というのが主な機能ではあるが、それ以外の様々な設定値がここに載ってくる。

DHCP Options はなんでも情報を載せられるわけではなく、何を載せられるのかが RFC 内で定義されており、それぞれのオプションを表す Code と呼ばれる整数値が割り当てられている。また 2132 以外の RFC で定義されている DHCP Options も存在している。以下は一例。

• RFC 2241 : DHCP Options for Novell Directory Services
• RFC 3397 : Dynamic Host Configuration Protocol (DHCP) Domain Search Option
• RFC 4833 : Timezone Options for DHCP

AWS オプションセットと RFC

さて、それでは AWS オプションセットで設定可能な各値は、 RFC で言うとどのコードに当たるのかという話になる。結論から書くと以下の通りだった。Section というのは RFC2132 で記載のあるセクション番号を指す。

| Code | Section | Option name | |------|---------|----------------------| | 6 | 3.8 | domain-name-servers | | 15 | 3.17 | domain-name | | 42 | 8.3 | ntp-servers | | 44 | 8.5 | netbios-name-servers | | 46 | 8.7 | netbios-node-type |

問題の domain-name は Code 15 に当たる。

This option specifies the domain name that client should use when resolving hostnames via the Domain Name System. The code for this option is 15. Its minimum length is 1.

記載の通り、想定されているのは単数形の "domain name" である。他の、例えば先の表にもある Code 6 のように、複数の値を取ることが想定されている場合は　"a list of ~" という書き方がされていることから考えても、 Code 15 のこの記載は、複数の値を想定していない。

AWS DHCP オプションセットにおいて、 domain-names にスペース区切りで複数のサフィックスを指定した場合、一部の Linux ディストリビューションによってはそのまま複数の値として扱われるのは言い方がよくないが「たまたま」ということになる。おそらくスペース区切りの文字列をそのまま resolv.conf に書き入れるような実装になっており、複数のサフィックスがそのまま適用されるということになる。一方で Ubuntu 18.04 などはスペースが "032" に書き換わる、これは ASCII printable characters において 32 がスペースなので、おそらくはそのような変換が噛まされているのだと思われる。

対処

以上のように RFC 上そうなっているから、というのが冒頭の「不具合」の理由になるため、対処はしようがない。そもそもドキュメントに注意書きがされているのだし、 16.04 で複数指定できていたのがむしろラッキーだったんだろう。 DHCP に頼らず別の方法で設定するしかない。

望むらくは domain-names の実装を AWS に変更してもらえないものかなとは思う。 domain name を複数指定できる DHCP Option は実は別にあって、 RFC3397 に載っている Code 119 がそれに当たる。こちらを採用してもらえれば、憂いなく domain name の複数指定が実現できるようになる。

余談

ちなみに冒頭に載せた Ubuntu 18.04 と DHCP オプションセットを巡ってはもう1つ問題があって、先の resolv.conf のイメージにもあるように、 nameserver が 127.0.0.53 で設定されてしまうという事象が発生する。

これに関してはまったく別の問題で、Systemd のバグらしい。 DHCP なんぞ基本的かつ根幹の部分だと思うのだが、意外にハマりどころがあって難儀している。

• Bug #1624320 “systemd-resolved appends 127.0.0.53 to resolv.conf...” : Bugs : systemd package : Ubuntu

そこに来て、最近始めた仕事でかなり　BYOD というべきか、会社の PC からでも家の PC から（要するにリモートワーク）でも会社で使っているサービスにログインして仕事をする、というスタイルが求められる場合が増えた。従って会社と家の PC でパスワードを共有したいのだが、会社の PC に私用で使っている Dropbox をインストールするのも気が引けるなどして、いい機会だしということで　KeePass に代わるサービスを探すことにした。使い始めたのは Bitwarden 。

https://bitwarden.com/

基本的には 1Password と同様にクラウドでパスワード管理してくれるサービスなのだが、パスワード管理サーバーのソースが GitHub で公開されており、サーバーをセルフホストして使うことができるようになっている。よってクラウド型パスワードマネージャーのメリットである「どの端末からでもインターネットに繋がればパスワードを取得できる」というメリットは享受しつつ、第三者にパスワードを預けるという形を回避できる。

Bitwarden サーバーの Deploy

デプロイ方法は公式にやり方が書いてあるので難しくない。

https://help.bitwarden.com/article/install-on-premise/

プロセス1つ上げればいいのかと軽く考えていたのが、 Docker コンテナ6個上げる必要があるのはちょっと予想していなかったが、 docker-compose コマンドでサクッと上げられるので手間は少なかった。サーバーはコンテナ6個と言うことでミニマムなものを使うわけにもいかず、 AWS EC2 の t3.small を1台手配している。従ってコスト的には全然美味しくなくて、ぼちぼちリザーブドインスタンスを買うつもりでいる。当初は VULTR で立てていたのだが、セキュリティに関して安物のサーバーを使うのも微妙だし、後述する各種運用のことを考えると使い勝手に懸念もあったので EC2 へ移した。

また https を使うために Let's Encrypt が組み込まれており、証明書も作成できるのだが、そのために独自ドメインが必要になる。やはりコスト的には全然旨味はない。

Bitwarden サーバーの運用

監視

停まると困るので Mackerel で死活監視している。まだ運用開始から1か月ちょっとなので落ちたことはないが、 EC2 だしたまに落ちる可能性は考慮するべきとは思っている。

セキュリティ

当然ながらセキュリティが気になるところなのだが、自宅だけから使うわけでもないので、 80/443 ポートの全開放は致し方なしというところ。それ以外のポートはすべて閉じている。メンテナンスのために ssh したくなる機会はあるが、 AWS Systems Manager を使うことにして、穴は閉じた。

https://dev.classmethod.jp/cloud/aws/session-manager-launches-tunneling-support-for-ssh-and-scp/

マスターパスワードはかなり長めにして、もちろん2段階認証をかけている。併せて Mackerel のログ監視を使って、400番のエラーが出た場合は Slack に通知させるようにした。挙動を見たところ、パスワードや2段階認証の誤りで弾かれた場合には 400 を返すらしいのだが、パスワード認証を終えて2段階認証をこれから行う、という場合でも400が出るようで、自分がログインするときにも通知されてしまってはいる。今の所已む無しと言うことで許容した。

ポート開放の話は、自分が使いたいときだけ Slack からスラッシュコマンドで穴を開ける、というようなやり方もできそうだし、検討はしたい。

バックアップ

Bitwarden のドキュメントにバックアップするべきファイルの情報は書かれているが、横着して AWS Backup で日次バックアップを EBS まるごと取得している。

使い勝手

肝心の使い勝手の面は、今のところ満足している。 KeePass をはじめ各種類似ツールがエクスポートした情報を読めるようになっているので、移行は一瞬で済んだ。

ツールは各 OS 向けのデスクトップアプリ、各モバイルアプリ、 Chrome 拡張、コマンドラインツールと豊富に用意されているが、デスクトップに関しては Chrome 拡張だけで事足りている感じ。パスワードに URL を紐つけて登録しておくと、そのドメインのサイトにアクセスした際、自動でサジェストしてくれたり、上手くいけば自動入力までやってくれるのでストレスが少ない。

なんかプレミアム会員 $10.00/年 を買ってコード入れて機能開放すると、 YubiKey 使った2段階認証とかも使えるようになるらしくて、それはそれで興味がある。が、有償でやるまでもなーーとか考えたり、いやでも t3.small 常時稼働させてるならもう $10.00/年 ぐらい誤差じゃん、、、という気もして、ちょっと悩んでる。

TeX とは

正直 TeX が何なのかがわかっていない。調べると「組版システム」と出てくるのだが、システムという単語が多義的すぎてよくわからない。言語の名前なのか TeX 記法で書いたテキストを PDF などに変換するソフトウェアなのか何なのか。

取りあえず理解しているのは元々の TeX はオープンソースであり様々な拡張（ディストリビューション）が出ており、そのうち1つに LaTeX と呼ばれるより手軽に扱える実装があること。日本語対応の TeX, LaTeX もまた拡張の1つという形であったこと、程度。

クラウドの TeX エディタ

始めは Google Docs からの乗り換え検討という形だったので、クラウドエディタがあればいいと発想していた。探してみたところ、2つほど見つかった。

• Cloud LaTeX | Build your own LaTeX environment, in seconds
• Overleaf, Online LaTeX Editor

Cloud LaTeX は国内のポスドク向け就転職サイトを運営するアカリクという会社が管理していて、使っている学生も多いように見受けられた。一方の Overleaf は海外のサービスだが、やりようによっては日本語も使えるらしい。

しかしよくよく考えると Visual Studio Code で書きたいし、普通に手元で書いて GitHub で管理すればええやんという結論になって、いずれも採用を見送った。

Visual Studio Code の TeX 環境構築

MacTex のインストール

macOS の場合は MacTeX というものがあるので Homebrew Cask でインストールする。

$ brew cask intall mactex

MacTeX は TeX Live というディストリビューションを含んだ macOS 向けの GUI などの集合らしい。ということで TeX Live としての初期設定を行う必要がある。まず、各種コマンド群に対して PATH を通す。

$ export PATH=$PATH:/usr/local/texlive/2019/bin/x86_64-darwin

続いて TeX Live 内の各種パッケージを管理する tlmgr コマンドで、 TeX Live を最新にアップデートしておく。

$ sudo tlmgr update --self --all

これで使えるようになった。 TeX ファイルをコンパイルするには ptex2pdf コマンドを使えばいい。

$ ptex2pdf -l example.tex

VSCode の設定

拡張機能 LaTeX Workshop を使う。

https://github.com/James-Yu/LaTeX-Workshop

デフォルトの状態でもシンタックスハイライトやサジェストの機能が使えるが、 VSCode 内でコンパイルしたりするには settings.json にコンパイル用のコマンドを記入したりする必要がある。自分の場合は以下のように設定している。

"latex-workshop.latex.tools": [
    {
        "name": "ptex2pdf",
        "command": "ptex2pdf",
        "args": [
            "-l",
            "-ot",
            "-kanji=utf8 -synctex=1",
            "%DOC%"
        ]
    }
],
"latex-workshop.latex.recipes": [
    {
        "name": "ptex2pdf",
        "tools": [
            "ptex2pdf"
        ]
    }
],
"latex-workshop.message.log.show": true,
"latex-workshop.message.badbox.show": true,
"latex-workshop.latex.autoClean.run": "onBuilt",
"latex-workshop.latex.autoBuild.run": "onFileChange",
"latex-workshop.view.pdf.viewer": "tab",

ビルド用のコマンドを定義するのは latex-workshop.latex.tools と latex-workshop.latex.recipes の部分。 tools で実行するコマンドを定義する。VSCode のコマンドから呼べるのが recipe と呼ばれ、 recipe と tools を紐つけるための設定が latex-workshop.latex.recipes になる。ここでは tools と recipes いずれも同じ名前にしてしまったのでわかりづらいが、 VSCode のコマンドパレットで ptex2pdf という recipes を実行すると、 tools の ptex2pdf で定義したコマンドが実行される、という形になる。

コマンドは先述の通り ptex2pdf で、 -l は LaTeX フォーマットを使うことを明示するオプション、　-kanji=utf8 は漢字を使う上で必要なオプション、 -synctex=1 は TeX のエディタと PDF ビューアを一緒に開いているとき、相互に位置ジャンプできるようにしてくれるらしい。 -kanji と -synctex は TeX の追加オプションなので、これらを使うために -ot が必要になる。

その他の設定は Wiki を見ればわかるが、順に以下の意味。

• エラーメッセージがエディタ内に表示されるようになる
• エラーメッセージが「問題」パネルに表示されるようになる
• TeX のコンパイル時に自動生成される .aux ファイルなどをビルド時に自動削除する
• ファイルに変更を加えたときに自動でコンパイルする
• TeX からコンパイルした PDF を VSCode のタブで表示する

これでこんな感じで PDF プレビューを見ながらレポートが書けるようになった。

左側のメニューに「TeX」アイコンも追加されるので、ここから各種コマンドを実行することもできる。コンパイルが上手くいかなかった場合はここから Terminate current compilation を実行すれば、コンパイルを一旦中止できる。

GitHub での管理

TeX ファイルは GitHub のプライベートレポジトリで管理している。これはまぁ、普通に管理するだけなので難しいことはない。

ワープロソフトを使っていると、印刷したときに正しく表示できるよう装飾面にも気を遣わなくてはならなくて面倒だったんだけど、 TeX だとマークアップさえしておけばいい感じの見た目にしてくれるので、本文を書くことに集中できてとてもいい。数式を書くための組版システム、という位置付けだとは思うが、文系でも使って利があるものだと思う。

きっかけは 3rd Party tool をきっかけに Terraform のソースコードを少し嗜んだ話 · the world as code という記事で触れたように、 Terraform 0.12 で Terraform Core と Provider が gRPC で通信するようになったため。知ってなてくは Terraform を使えないわけでも Provider を書けないわけでもないのだが、昨今よく聴く単語だし、 microservices などにも必要な要素技術なので入門してみた。

教材

ちょうど WEB+DB PRESS の最新号で特集されていたので、主にこれを使った。

WEB+DB PRESS Vol.110

posted with amazlet at 19.06.21

藤村 大介 森田 リーナ 渡邉 祐一 市原 創 板倉 広明 高橋 征義 笹田 耕一 大原 壯太 新倉 涼太 末永 恭正 久保田 祐史 牧 大輔 東 邦之 星 北斗 池田 拓司 竹馬 光太郎 はまちや2 竹原 八谷 賢
技術評論社
売り上げランキング: 13,606

Amazon.co.jpで詳細を見る

あとは公式のドキュメント。英語で簡単な Tutorial が書かれているほか、 gRPC のレポジトリ内にある examples というフォルダに言語別の実装例が書かれていて参考になった。

学んだこと

写経

gRPC とは何か、などとここで改めてまとめても仕方ない感があるので、それについては割愛する。 WEB+DB PRESS を読もう。

当該号の特集では、 gRPC の4種類の通信方式（Unary, Server streaming, Client streaming, Bidirectional streaming）それぞれの簡単な実装サンプルと、実践例として gRPC を用いたタスク管理サービスの作り方が掲載されており、これを適宜写経しながら進めた。コードはいずれも GitHub で公開されている。

https://github.com/vvatanabe/go-grpc-basics

https://github.com/vvatanabe/go-grpc-microservices

Ruby での再実装

単に写すだけというのもつまらないので、ちょっとした応用もやってみた。 gRPC には遣り取りするデータのシリアライズフォーマットを定義した Protocol Buffers (protobuf) を元として、サーバ / クライアントの実装を様々な言語で生成することができるという特徴がある。そこで、誌面のサンプルはサーバ / クライアントともに Go で書かれていたが、クライアント側を Ruby で書いてみることにした。

対象にしたのは Server streaming gRPC のサンプルコード。主に公式の Ruby 向け Tutorial を見つつ、先の examples 内の実際のコードも見ながら進めたが、以下の記事も参考にした。

https://qiita.com/yururit/items/bc7c0eda63d5fa30289a

まず、必要な gRPC 関連の gem をインストール。

$ gem install grpc
$ gem install grpc-tools

続いて protobuf から Ruby 用のクライアントコードを生成しようと思ったのだが、サンプルコードでは protobuf の package が file という名前で定義されており、これをそのまま Ruby のコードに変換すると、 File class と衝突する形になってしまった。そのため package 名を filedl という名前に変更してからコード生成を実行している。ネーミングセンスは気にしないことにした。なお、このコマンドは元のサンプルコードの downloader というフォルダ内に ruby フォルダを掘り、その中で実行している。

$ mkdir lib
$ grpc_tools_ruby_protoc -I ../proto --ruby_out=lib --grpc_out=lib ../proto/filedl.proto

Ruby のコードは以下のようになった。元々の Go によるサンプルコード（go-grpc-basics/main.go at master · vvatanabe/go-grpc-basics）とだいたい同じ動きをするようにしている。

this_dir = File.expand_path(File.dirname(__FILE__))
lib_dir = File.join(this_dir, 'lib')
$LOAD_PATH.unshift(lib_dir) unless $LOAD_PATH.include?(lib_dir)

require 'grpc'
require 'filedl_services_pb'

def main
    stub = Filedl::FileService::Stub.new('localhost:50051', :this_channel_is_insecure)
    filename = ARGV[0]
    resps = stub.download(Filedl::FileRequest.new(name: filename))
    blob = ""
    resps.each do |r|
        blob << r.data
    end

    p "done " + blob.size.to_s(10) + " bytes"

    file = File.open(filename,"w")
    file.puts blob
    file.close
end

main

これで ruby client.rb test などと実行することで無事に動作が確認できた。異なる言語間でシリアライズされたデータの遣り取りがだいぶ簡単に実装できてなるほどねぇという感じはした。あと Ruby を3年ぶりぐらいに書いたのでところどころ文法にビビったりした。 << 演算子とか。

成果物はすべて chroju/learning_grpc に上げておいた。

Terraform と gRPC

一通りドキュメントを見てはみたが、正直そんなにガッツリ gRPC 使ってどうこうみたいなことは書いていないような気がする。 RPC 使ってますよ（これは Terraform 0.11 以前から同様）という話と、 "Although technically possible to write a plugin in another language, almost all Terraform plugins are written in Go." という一文が Writing Custom Providers - Guides - Terraform by HashiCorp にあるぐらい。将来的に Go 以外でも書けるようにするんですかね。どうなんですかね。

コードで言えば terraform/docs/plugin-protocol · hashicorp/terraform に protobuf の定義ファイルがある。また、 Provider は terraform/plugin の Serve という関数を main.go に書く必要があり、この関数が Terraform Core に Provider を渡しているようなのだが、 この実装 を見ると、現時点では gRPC 向けに既存のメソッドを変換したりする処理が入っているみたい。 Provider を書く際には、 gRPC を意識する必要は基本的にはなさそう。

大学生

大学は2011年に一度出ているので、今回が再入学になる。いわゆる一般教養にあたる単位は取得済みとみなされ、2年次編入となった。

なぜ大学に再入学したのか

先に出ている大学は社会学部で、計算機科学や情報学の学問的な知識をきちんと学んだことがなかったから、というのが直接の動機になる。いわゆる文系コンプレックスに近かったんだと思う。この職業をやっていく中で、そういったことをなんとなくのもやっとした感覚として抱いていたのだが、実際進学してしまおうと決意した契機は SRE book だと思う。

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

posted with amazlet at 19.06.14

オライリージャパン
売り上げランキング: 5,126

Amazon.co.jpで詳細を見る

Googleは、さまざまな問題に関してあえて一から考えることをいとわない会社であり、多くの博士号所有者を含む最高の人材を雇用しています。ツールはプロセス中で一連のソフトウェアや人々、データと共に動作する要素に過ぎません。ここでは、万能の解決策を教えてくれるものはありませんが、それこそが本質なのです。（序文より）

この2, 3年ぐらいはレガシーな環境の運用設計を見直したり、改善したりといった仕事を主に担当していたのだけど、この「あえて一から考える」ということに難しさを覚えることが多くあった。例えばシステムからのアラートが多いので改善をしたい、という話になったとき、一から考えるのであれば何故アラートを発報しているのか、そもそもこの監視の設計で、このシステムに対しては適切な監視になっているのか、システムを監視するとはどういうことなのか、という点から問い直す作業になるのだと思う。しかし実際には、プロジェクトメンバーの経験から「オーソドックスな監視設計」と思われるものをこねこねと作り上げて、それをパッチのように継ぎ宛てて対処するだけに終わってしまうことも少なくなかった。なぜ経験を引っ張り出してくるのかと言えば、他に依拠できる客観的な知識体系を持っていないからであって、その知識体系の候補となりうるのが学問的な知識なのかもしれないな、ということを考えた。車輪の再発明をしないための学びであり、車輪を適切に応用していくための学びをしたかった。

もちろん、市販されている技術書などで賄うこともできるとは思うけど、この業界であと30年はやっていくことを考えると、3年間費やせば取得できる学士ぐらい持っていて損はないと思っている。学士があれば、その後修士、博士に進むということもなくはないかもしれないしれないし、可能性を広げておく意味で決断した。ちなみにいきなり修士からというのも考えはしたが、基礎的な知識体系を獲得したい、という目的からすると学士からきちんと押さえるべきだと考えた。

なぜこの大学学部学科なのか

こういう言い方をすると申し訳ない部分もあるが、わりと消去法に近い。東京近郊でスクーリング可能な情報系の通信制大学、という時点でわりと絞られる。最も有名であろう通信制大学である、放送大学という手もあったのだけど、学部が教養学部になってしまうので、それよりは理工学部の卒業歴を持っておきたいとか、理工学研究科を有している大学のほうが安堵感があるかな、みたいなふわっとした思いもあったりする。

2か月半ほど通ってみての感想

思っていたより大変。というのも、試験を受ける時期が1年間に4回あり、そのうち最も早いのが7月初旬にあるのだが、その試験を受けるには6月初旬にレポートを出さなくてはならなかったりしたため。通信制の新入生は4月末ぐらいに履修登録の期限が設けられていたので、GW明けぐらいから本気出せばいいかと安易に考えて連休は遊びまくったのがよろしくなかった。連休明けに初めて日程に気付き、5月はだいぶヒーヒー言いながら勉強していた。

ただ、4回の試験のうち、1回目と3回目、2回目と4回目で受けられる科目は同一であるため、基本的に時期が遅いほうで受けるよう日程を組めば、勉強期間も長めに取れて余裕が出そうということがわかったので、これから調整すればもう少しマシかもしれない。最短の3年間で残る90単位近くを取りきれるかは少し自信がない。15回ぐらいある授業を自力で進めてレポート書いて試験、って、思った以上に力が要る。最近こちらにかかりきりで、技術動向を追うようなことができてなかったりするのも芳しくなくて、しばらくはリズムを調整していきたい。

余談めいた部分だと学割が使えるようになった。さすがに収入がそれなりにある身で使うのは大人げない気がするのでほとんど使ってはいないが、 Spotify（半額）と Amazon Prime（半額、書籍や文房具購入時に還元）だけは「まぁいいか」と思って使わせてもらってる。一度だけ美術館でも使ったが普通に使えた。

パラレルワーカー

具体的には先月で正社員契約をやめ、今月から週1で業務委託の仕事をしていて、来月からはそれに加えて別の会社で週4契約社員として働くことになった。フリーランサーに近くはあるし、税制の面を考えて開業届も出しているけど、いわゆるフリーランスの働き方ともちょっと違うのでパラレルワーカーと名乗ってみている。

業務委託を始めるにあたり、税のこととか何もわからなかったので、技術書典6できりみんちゃんさんの『フリーランスを完全に理解できる本』を買って参考にさせてもらった。他にも何冊か読んでみたけど、これがかなりコンパクトにまとまっていてめちゃめちゃわかりやすかったです、ありがとうございます。

なぜパラレルワーカーになったのか

あんまりパブリックに書きたい理由でもないのでやめておく。別に働き方改革したいとか、会社勤めが嫌になったとかではないし、学業があるから仕事減らしたいでもない（そのうち、そう思うかもしれんが）。そもそも自分は仕事以外の人脈でIT系のエンジニアとの繋がりをほぼ持っていないので、よくある「知人伝いに仕事をもらう」ということは出来そうにないし、著名人ってわけでもないのでフリーランサーに向いているとも思っていない。なんか結果的にこうなってしまった。ただ、それほど嫌な気持ちはなくて、経験として面白そうだとは感じている。

前職をやめた理由というのは存在していて、少し固めな BtoB 中心の事業領域の中で、自分がやれることの天井が見え始めたから、というのが近いと思う。よりベロシティが高い環境に身を置きたかったとも言えるし、もっと個人的な話だと SRE にクラスチェンジしたかった、というのもある。抽象的な書き方でアレだけど。

どうやって仕事を探したのか

転職ドラフト、forkwell、Wantedlyなどなど、最近はIT系のエンジニアお仕事系サイトも多いので、いろいろと駆使して全部合わせると10社ぐらい会わせていただき（選考に進まなかった会社も多い）、あとは少ない知人経由の会社も受けたりして、最終的に契約に至った。前回の転職のときはエージェントを使ったので、今回の仕事探しでは使わないでみようという考えが強かった。結果的に、 GitHub やブログの URL を貼ったレジュメを送って、自分はこれができます、とアピールし、相手もそれを見た上で、この人にならこれが任せられるかもしれない、という気持ちで話してくれるという形になったので、話しやすいなと感じることが多かった。どこかが取ってくれるだろう、ではなくて、自分はこれができるから御社で働かせてほしいと売り込む、能動的な姿勢も養えたように思う。

ちなみに職種は SRE で探した。流行りの仕事だからか、システム運用かつソフトウェアエンジニアリングというスキル領域を満たす人材がまだ少ないのか、求人は結構な数があるような感触を受けた。 SRE はシステムのコアな部分に関わるので、業務委託だとどうなんだろうという気がしていたが、わりと正社員に近い役割でやらせてもらえる会社さんもあった。なお、業務委託で探していたのだけど、最終的に「契約社員はどうか」と言ってもらえる会社さんがあったので契約社員＋業務委託という2契約になっている。

働き方は変わるのか

2社パラレルになる以外はあんまり変わらないと思う。リモート可能でフレックス制がだいぶ積極的に使われてるっぽい会社さんということもあり、労働時間は減りそう（前職はそこそこ残業してた）というぐらい。収入も前職でそこそこもらっていたのだが、同等な額が入りそうなので困窮する心配もなさそう。

ということで

2つの話を一緒に書いたので長くなったけど、来月から肩書き3つでやっていく感じでコンテキストスイッチ大変そうだけど頑張っていこうと思う。仕事探しの話、学生の話など、個々の部分にフォーカスした具体的なことはまた別途書くかもしれない。

従来の仕組み

従来の仕組みは以下の Qiita のエントリーにまとめていた。

https://qiita.com/chroju/items/827dbb9e820f41820e14

やりたかったのは、プロフィールの中に自分のブログの最新記事リストを自動的に埋め込むこと。紆余曲折を経て、あらかじめ jinja2 でテンプレートを作っておき、ブログの更新を RSS と IFTTT 経由で hook して Lambda を叩いて、その Lambda がテンプレートから html を生成して S3 に設置、という形をこのときは取っている。つまり動的チックだが、実際にアクセスが来るのは静的な HTML ではある。ページ内に書いてある通り、各サービスの仕様がその後変わっているので、現時点でこのメカニズムを採用するのはモダンではなくなっている。

なお、 chroju.net のドメインはもう失効したが、このページ自体はまだ生きている。気まぐれに消すと思うので、動いていなくてもあしからず。

https://chroju-profile.s3-ap-northeast-1.amazonaws.com/index.html

今回の仕組み

シンプルに、 URL へアクセスがあったときにサーバーサイド（実際にはサーバーレスだけど）で RSS から最新記事のタイトルとリンクを読み込んで、テンプレートに埋め込んで HTML を返す、というメカニズムに変えることにした。

Netlify Functions はコードを書いた GitHub レポジトリと連携を設定すると、それを自動的に AWS Lambda にデプロイして URL から実行できるようにしてくれる仕組み。つまり Lambda と API Gateway の設定を面倒見る必要なく、コードを書くことだけに集中ができる。基本的には API を作ったりするのが主な用途だと思うけど、もちろん text/html を返しても良いので、今回はそれを利用している。言語は JavaScript と Go が使えるが、自分のスキルを鑑みて Go にした。

実装

HTML のテンプレートには Go の標準ライブラリの html/template を使った。また RSS の読み込みとパースには https://github.com/mmcdole/gofeed を利用している。最新のコードは https://github.com/chroju/portfolio に置いている。

package main

import (
	"bytes"
	"html/template"
	"io"
	"log"

	"github.com/aws/aws-lambda-go/events"
	"github.com/aws/aws-lambda-go/lambda"
	"github.com/mmcdole/gofeed"
)

func handler(request events.APIGatewayProxyRequest) (*events.APIGatewayProxyResponse, error) {
	fp := gofeed.NewParser()

	feed, _ := fp.ParseURL("https://chroju.github.io/atom.xml")
	ghitems := feed.Items[:3]
	feed, _ = fp.ParseURL("https://chroju.hatenablog.jp/feed")
	hbitems := feed.Items[:3]

	tmpl := template.Must(template.New("index.html").Parse(htmlTemplate))
	buf := new(bytes.Buffer)
	w := io.Writer(buf)

	err := tmpl.ExecuteTemplate(w, "base", struct {
		GitHubIOEntries   []*gofeed.Item
		HatenaBlogEntries []*gofeed.Item
	}{
		GitHubIOEntries:   ghitems,
		HatenaBlogEntries: hbitems,
	})
	if err != nil {
		log.Fatal(err)
	}

	return &events.APIGatewayProxyResponse{
		StatusCode: 200,
		Body:       string(buf.Bytes()),
	}, nil
}

func main() {
	lambda.Start(handler)
}

先述の通り裏側は AWS Lambda なので、 Lambda の書き方に沿うことになる。 Lambda の実行時に呼び出す関数は handler と呼ばれる。この handler は特に API Gateway から呼ばれることになるので、 API Gateway とやり取りするために *events.APIGatewayProxyRequest を受け取り、 *events.APIGatewayProxyResponse を返すように実装する必要がある。今回はそのなかで html を Response Body に入れて返している。

テンプレートは行数も多くなるので、本来であれば別ファイルに切り出したいところなのだが、 Netlify Functions でコード以外のファイルを一緒にデプロイする方法がわからなかった。そのため今はテンプレート全行を定数に代入する形でべた書きしている（上述のコードの中では省略した）。

あとは build 用のコマンドを Makefile に書いておく。これで functions というフォルダ内にバイナリが置かれることになる。

build:
	export GO111MODULE=on
	go get ./...
	go build -o functions/profile ./...

設定したコマンドと、バイナリの在り処を netlify.toml に書き、このレポジトリを Netlify Functions に連携することで、レポジトリの push を検知して自動的に build してデプロイしてくれるようになる。とても手軽。

[build]
    command = "make build"
    functios = "./functions"

misc

コード以外の設定をいくつか。

Font Awesome

SNS のアイコンを表示するために何年かぶりに Font Awesome を触ったところ、設定方法が替わっていたように思うのだが、以前の記憶が曖昧ではある。従来は CDN 上の CSS を link タグで直接読み込む形を取っていたと思うのだが、現状この形式は推奨されておらず、ユーザー登録すると個別の ID が払い出され、その ID に紐ついた js を読み込んで使う、という形になったらしい。

管理画面上で使用するプランや、 Web Font か SVG かの選択などを行えるようになっているので、おそらくそれを反映して、 js が適した css を動的に読み込むようになっているのだと思われる。 Font Awesome がバージョンアップした場合にも自動的に latest を読み込んでくれるようなので、メンテナンスの手間は減って便利になっている。

DNS

chroju.dev は Google Domains で取得したが、 Netlify Functions を使うにあたって Netlify の Managed DNS を使うと CDN を噛ませて速くしてくれるみたいな話だったので、名前解決は Netlify にまかせている。

https://www.netlify.com/docs/dns/

残念ながら API がまだ無いようで、 chroju.net の時代は Route53 に乗せて API 経由でゴニョゴニョしていたことが出来なくなってしまったのでどうしようかな、という課題が残された。まだ Beta 扱いのようではあり、今後に期待したい。

Redirect

Netlify Functions はカスタムドメインは使用できるものの、個々の Function を実行するパスの自由度はなくて、デフォルトだと /.netlify/functions/ 配下に置かれる。しかし https://chroju.dev へアクセスが来たときに Functions を実行して返したいわけなので、 netlify.toml でリダイレクトを設定した。 200 で返すことにより、ユーザーのアドレスバーには https://chroju.dev/ が表示されたままでリダイレクトさせることができている。

[[redirects]]
    from = "/"
    to = "/.netlify/functions/profile"
    status = 200

go mod

今回初めて go mod を利用したけど便利だった。利用にあたっては公式のドキュメントと以下のエントリーを参考にした。

• 最近のGo Modulesプラクティス ~ ghqユーザーの場合も添えて | おそらくはそれさえも平凡な日々

Conclusion

すごく簡単に AWS Lambda と API Gateway が使えて楽しかった。対応言語が Go と JS だけなど制約もあるが、単発で動かす Lambda とエンドポイントがほしいだけの場合であれば、 AWS ではなく Netlify Functions でデプロイしたほうがいろいろと不便がなさそう。

前回の記事で書いたとおり Corne Chocolate を買って、無事に組み立てが完了した。

Corne Chocolate

Corne Chocolate は foostan 氏が設計、販売している自作キーボード。

• 分割型
• 42キーのいわゆる40%キーボード
• Cherry MX 対応と Kailh Choc (Low Profile) 対応の2バージョン、それぞれホットスワップ
• オプションでフルカラー LED 実装可能

といった特徴がある。私がこれを買ったのは Lily58 Pro を使うなかで数字列が要らないのではないか、つまり40%キーボードで良いのではないかと悟ったからであり、40%の分割型で Kailh Choc 対応という3つの希望を満たしてくれるのがこれだった。ちなみに Cherry MX 対応のほうは Corne Cherry と呼ばれる。略して crkbd と表記されることもあるみたい。

購入、組み立て

Lily58 Pro と同じく遊舎工房さんの実店舗で購入して組み立てた。組み立ては Lily58 Pro とわりと似ているというか、ダイオードが表面実装タイプで、キーソケットも同じ Kailh Choc のスワップタイプのものだったので、はんだ付けの工程はまったく同じで手間取ることがなかった。最初に使えるようになるまでは5時間ぐらい。

大変だったのは LED 。 Corne に関して他の方のビルドログを探ってみても、一様に LED のはんだ付けが難しいという話が出てくるが、確かに難しかった。LED は PCB 基板の裏側からはんだ付けする必要があるのだけど、裏側にそのまま表面実装ではんだ付けする Underglow 用のものと、基板に空いた穴に LED をはめ込んではんだ付けする Backlight 用のものとの2種類がある。難しいと言われるのは Underglow 用のものの方みたいなんだけど、はんだ付け初級者としてはどちらも難しかった。

Backlight LED

写真でわかりづらいかもしれないが、 Backlight LED はこのように穴のなかにはめこんで、基板側のランドと繋ぐ必要がある。

ただ、基板のランドと LED とが平らに並ぶ（「ツライチ」と呼ぶらしい）わけではなく、少し段差があって、その間をうまくはんだでブリッジさせることが難しかった。ただ、上手くいかなければ一度はんだ吸い取り線で一度はがしてやり直せるので、確かに Underglow よりは楽だと思う。

Underglow LED

表面実装なので、何も考えずランドに予備はんだを盛ってから取り付ける方式でやってみたんだけど、それだと LED が浮いてしまってうまくいかず、一度外してやり直そうと思っても LED の裏側にまではんだが入り込んでしまっているので外せなくて終いにはランドを剥がしてしまった。

その後いろいろと調べてみたところ、 Corne Chocolateビルドログ - nokの雑記 に図解されているように、予備はんだを盛るのではなくて、 LED を先に基板に置いてしまって、端子部分に横からはんだを差し入れるようにするのが良いらしいとわかった。その後気づいたけれど、これは Corne Chocolate ではなくて、前バージョンにあたる Corne Classic のビルドガイド にも載っている方法だった。

幸いにも遊舎工房さんで Corne の PCB 単体での販売があったので、それで1枚追加で購入して改めてやり直した。やり方を変えてそれなりにスムーズに実装できるようになったが、この方法はちゃんとはんだが盛れているか目視では確認しづらくて、頻繁に通電してちゃんと光るか確認しながら進めた。ビルドガイドにもある通り、 LED はすべて接続されていて、1つがダメだとその先のものがすべて光らなくなるので、番号順に実装を進めていった。わからなかったのが、光らない LED があるものの、その先の LED は光っており、しかし色がおかしい、という事態。これがどうにも克服できなかった。電気的な部分はまったくわからないなりに コルネキーボードを作りました ～LED取り付けに四苦八苦記～ | キオクノロンダリング などを参考に、どの端子がどういう働きをしているかなどを確認してみて、導線で上手いことジャンパすれば直らないかなと四苦八苦した結果、原理はわからないけれど、光らない LED と、その1つ手前の LED の DOUT 同士を繋いでみたところ、光らない LED は光らないままだけど色はちゃんと出るようになった。 Underglow が1つ光らないのは諦めて、いまのところこれで妥協している。

キーキャップとキースイッチ

キースイッチは前回の Lily58 Pro で茶軸を買っていたので、今回は赤軸を買ってみた。軽くサクサク打ててとてもよかったんだけど、小指で押さえるキーや、一定時間押しっぱなしにする修飾キーはタクタイルのクリック感があったほうが押し込みやすかったので、今は以下のようなハイブリッドにしてみている。

キーキャップは monksoffunk 氏が DMM.make で販売しているものを買ってみた。

https://make.dmm.com/item/1009205/

DMM.make では3Dプリント用のデータをアップロードして出品することができる。ユーザーがそのデータに対して注文をかけると、 DMM で実際にプリントして物品を送ってきてくれる仕組み。3Dプリントされた物品を手に持ったことがないのでどんなものかと思ったけど、手触りはさらさらしているものの程よいざらつきもあって、とても打ち心地のいいキーキャップだった。Kailh Choc 用のキーキャップは、遊舎工房にも置かれている Kailh 自身が販売しているものぐらいしか出回っていないと思うのだけど、それと比べても見た目、打ち心地ともに上回って満足している。

ちなみにプリントする素材が選べるのだが、PA12GB ブラック磨きを選択している。販売ページの断り書きに「破損の恐れがあるためキャンセルを促される連絡があるかもしれません」とあるけれど、これはこのキーキャップが DMM 側の規定サイズを満たさず、品質保証ができないためのようで、実際に一度は DMM 側から強制的にキャンセルされた。その後サポートから「破損の可能性を受け入れた上で再注文したい」と申し出たところ無事に購入することができ、再注文から9日で到着した。確かに1個だけ軸が折れたものが混ざっていたけれど、キットには予備のキーキャップがいくつか入っているので問題はなかった。

キーマップ

まだ適宜変更は入ると思うけど、いまのところ以下のようになっている。

const uint16_t PROGMEM keymaps[][MATRIX_ROWS][MATRIX_COLS] = {
  [_QWERTY] = LAYOUT_kc( \
  //,-----------------------------------------.                ,-----------------------------------------.
        TAB,     Q,     W,     E,     R,     T,                      Y,     U,     I,     O,     P,  BSLS,\
  //|------+------+------+------+------+------|                |------+------+------+------+------+------|
     CTLGUI,     A,     S,     D,     F,     G,                      H,     J,     K,     L,  SCLN,  QUOT,\
  //|------+------+------+------+------+------|                |------+------+------+------+------+------|
     SFTESC,     Z,     X,     C,     V,     B,                      N,     M,  COMM,   DOT,  SLSH,  RALT,\
  //|------+------+------+------+------+------+------|  |------+------+------+------+------+------+------|
                                   LGUI, LOWER,SPCALT,      ENT,RASLNG,  BSPC \
                              //`--------------------'  `--------------------'
  ),

  [_RAISE] = LAYOUT_kc( \
  //,-----------------------------------------.                ,-----------------------------------------.
       LRST,    F1,    F2,    F3,    F4,    F5,                     F6,    F7,    F8,    F9,   F10,   F12,\
  //|------+------+------+------+------+------|                |------+------+------+------+------+------|
       LTOG,  LHUI,  LSAI,  LVAI, XXXXX, XXXXX,                   LEFT,  DOWN,    UP, RIGHT,  VOLU,  BRIU,\
  //|------+------+------+------+------+------|                |------+------+------+------+------+------|
       LMOD,  LHUD,  LSAD,  LVAD, XXXXX, XXXXX,                  XXXXX, XXXXX, XXXXX,  MUTE,  VOLD,  BRID,\
  //|------+------+------+------+------+------+------|  |------+------+------+------+------+------+------|
                                   LGUI, LOWER,SPCALT,      ENT,RASLNG,   CAD \
                              //`--------------------'  `--------------------'
  ),

  [_LOWER] = LAYOUT_kc( \
  //,-----------------------------------------.                ,-----------------------------------------.
       EXLM,     1,     2,     3,     4,     5,                      6,     7,     8,     9,     0, XXXXX,\
  //|------+------+------+------+------+------|                |------+------+------+------+------+------|
       TILD, XXXXX, XXXXX, XXXXX, XXXXX, LCBRS,                  RCBRS,  MINS,   EQL, XXXXX, XXXXX, XXXXX,\
  //|------+------+------+------+------+------|                |------+------+------+------+------+------|
        GRV,    AT,  HASH,   DLR,  PERC, XXXXX,                   ASTR,  UNDS,  PLUS,  CIRC,  AMPR,  ASTR,\
  //|------+------+------+------+------+------+------|  |------+------+------+------+------+------+------|
                                   LGUI, LOWER,SPCALT,      ENT,RASLNG,  BSPC \
                              //`--------------------'  `--------------------'
  )
};

デフォルトでは RAISE と LAWER を同時押しすることで変更できる ADJUST レイヤーも含む4レイヤー用意されているが、3レイヤーでなんとか収まった。LOWER が記号や数字、RAISE がファンクションキーや LED の調整などの操作系のキーという振り分けになっている。

42キーとだいぶキー数が減ったことで、1つのキーに Tap Dance や Mod-Tap によって複数の役割をもたせている箇所も増えている。左側の「SFTESC」や、親指部分の「SPCALT」はいずれも Mod-Tap で同時押ししたときと単推しのときで役割を変えている。また LOWER レイヤーの左右それぞれ一番内側中段にある「LCBRS」「RCBRS」は Tap Dance によって [, (, { の3種類の括弧を切り替えられるようにしたものなんだけど、3回タップするのはわりと手間で、ちょっと今見直そうか迷っている。

渾身のキーが右親指の「RASLNG」。これは長押しすると RAISE、単推しで IME 無効化、2回連続押しで IME 有効化という3種類の役割を担っている。IME の on/off 切り替えは1つのキーでトグルさせるのではなく、別々のキーに割り当てたほうが冪等な操作ができて良い、と私も思っているのだけど、例えば左親指で off で右親指で on のように振り分けるとどちらがどっちだったか覚えるのが煩わしいという問題と、同じ IME 操作をするのに意識が左右に散らばってしまって不快という問題があり、1つのキーを押した回数で冪等に切り替える方式を採用した。 Tap Dance の設定を以下のように書いており、1回押したときに LANG2 と F13 、2回押したときに LANG1 と F16 を発行するようにしている。LANGの各キーコードによる IME の切り替えは macOS にしか対応しないので、 Windows では IME の設定により、ファンクションキーで IME の有効無効を切り替えられるようにした形。

enum {
  SINGLE_TAP = 1,
  SINGLE_HOLD = 2,
  DOUBLE_TAP = 3,
};

typedef struct {
  bool is_press_action;
  int state;
} tap;

int lang_dance (qk_tap_dance_state_t *state) {
  if (state->count == 1) {
    if (!state->pressed) return SINGLE_TAP;
    else return SINGLE_HOLD;
  }
  else if (state->count == 2) {
    return DOUBLE_TAP;
  }
  else return 6;
}

static tap xtap_state = {
  .is_press_action = true,
  .state = 0
};

void x_finished_1 (qk_tap_dance_state_t *state, void *user_data) {
  xtap_state.state = lang_dance(state);
  switch (xtap_state.state) {
    case SINGLE_TAP:
        register_code(KC_F13);
        register_code(KC_LANG2);
        break;
    case SINGLE_HOLD:
        layer_on(_RAISE);
        break;
    case DOUBLE_TAP:
        register_code(KC_F16);
        register_code(KC_LANG1);
        break;
  }
}

void x_reset_1 (qk_tap_dance_state_t *state, void *user_data) {
  switch (xtap_state.state) {
    case SINGLE_TAP:  
        unregister_code(KC_F13); 
        unregister_code(KC_LANG2);
        break;
    case SINGLE_HOLD: 
        layer_off(_RAISE);
        break;
    case DOUBLE_TAP:
        unregister_code(KC_F16);
        unregister_code(KC_LANG1);
        break;
  }
  xtap_state.state = 0;
}

これは自分で思いついたわけではなくて、実装にあたっては以下の記事を大いに参考にさせていただいた。

• 変わり種ErgoDox紹介 + IME話 - Qiita
• QMK Basics: Tap dance, or how to let a key do more with one, two, three – Thomas Baart

Impression

記号キーがどこにあるかはまだ全然覚えていないし、特にパスワードを打つときすごく苦労しているけれど、見込んでいたとおり、すべてのキーがホームポジションから1キーだけ離れたところに収まっているというのは無茶苦茶快適で大満足している。早いけれど、とりあえずはこれで End Game と考えていいんじゃないかなぁと感じているぐらい。40%キーボードが実用に足るとは1か月前にはさらさら考えていなかったのが嘘のように「40%でキー数は十分」と思うようになってきている。 LED についても要らないでしょと思っていたし、実用上の意味はまったくないんだけど、実際光ってみるとカッコよく見えてしまい、作り直しまでしてこだわってしまったので、やってみないとわからないことって多いなぁと。

End Game っぽいとは言え、自作キーボード周りの買い物や工作がこれで終わりではなくて、まだ買いたいものもある。IMK Corne Case — KeyHive で今アルミ製のケースのグループバイが始まっていて、ちょっと高いけど買おうかなぁと思っている（実際の購入は遊舎工房さんの日本プロキシを用いる予定）。あとせっかくなので Kailh Choc の他のキースイッチも Novelkeys から個人輸入で買ってみようかな、と。はんだ付け工具一式も揃ったんだし、また興味を引かれるキーボードを見かけたら買ってみたい。今回 PCB を追加で買ったときに、足りなくなった部品を買いに秋葉原の秋月電子通商やら西川電子部品やらにも初めて足を踏み入れて、今まで知らなかった領域の知識が増えるのがとても楽しかったし、この経験は今後も活きるといいなと思っている。

• 転職ドラフトに5回参加した結果について

転職ドラフトに5回参加した

転職ドラフトというサービスがありまして、何かというと隔月で2週間に渡りドラフトが開かれ、そのときにレジュメと希望年収を登録した上でドラフト参加登録をしておくと、企業がそれを見て「こいつほしいわ」と思ったら想定年収込みで採用のお誘いをかけてくれるというものです。もちろん、それで採用確定になるわけじゃなくて、そこから通常の採用フローを経て実際の入社となるわけだけど、転職ドラフト上で提示した年収の90%を下回る金額で採用することは禁止されているので、いろいろとこう安心感があるみたいなそういうもの。これに昨年夏から5回ほど参加した。転職絶対するぞみたいな感じというより、今の自分の GitHub アカウントや Qiita やこのブログを載せたレジュメを見て、おいくら万円なら雇ってくれる会社あるんだろうか、という市場価値を少し測ってみたいという興味から参加した。幸い、参加した回はいずれも指名がもらえて、何度かカジュアル面談という形で話をさせてもらったりもした。

結果

最近金額公表が流行っているし金額載せても別にいいんだけど、自分のような無名の人間が載せて意味があるのか知らんし、仮に需要あるなら有料 note とかで販売したほうが良さそうだしってことで、指名金額はこちらの希望年収にプラマイいくらで来たかという形で載せる。希望年収は今もらっている金額を元にしていて、まぁざっくり同世代平均年収よりはウン百万かは高いぐらいで、そんなに謙虚な額にはしていない。

第13回

• 希望年収ジャスト 3件
• +20万円 1件
• -40万円 1件

うち3社とカジュアル面談

第14回

• 希望年収ジャスト 1件

第16回

• 希望年収ジャスト 2件

うち1社とカジュアル面談

第17回

• 希望年収ジャスト 6件
• -50万円 1件

うち1社とカジュアル面談

第18回

• 希望年収ジャスト 2件

指名は想定よりもらえた

正直言って想定より指名が来たという感覚だった。 GitHub にコードを載せたりしてはいるけど、最大で星もらってるレポジトリでも 4 Stars とかだし、自分としては特に強い自覚はないし、5回のドラフトを経た今でもそれは変わらない。ただ、たまに Twitter で「GitHub にコードを上げている IT エンジニアは全体のx割」みたいな結構少ない数字を見かけることがあるけれど、あれが実際そうなのだろうなという気はしている。カジュアル面談をしていても GitHub に上げているコードの話やブログのエントリーに関する話題を出してもらえたりして、アウトプットをしていてよかったというのはすごく実感した。あとは SRE という職種を自分は希望しているけれど、この職種で採用市場に出回っている人材自体、現状少ないんではないかなという気はしている。インフラエンジニアはもちろんそれなりの数がいるだろうし、コードを書くエンジニアもそうだろうけど、その双方に興味を持つことで、多少なり希少価値が出せてるんではないかなと思う。

カジュアル面談ってなんなんだ

会いに行った企業はいずれも選考なしのラフな面談、いわゆるカジュアル面談という形で会わせてもらったが、企業によって形式はまちまちだった。参加者としては、指名されて初めてその企業を知るという場合も多いので、まずは企業のことを知ってもらう機会として設けられているのだと思うけど、実際に時間いっぱいほとんど説明だけに費やされる企業さんもあれば、すべてこちらからの質問だけの時間を取ってくれてなんでも聞いてくださいという感じの企業さんもあり、また逆に、選考ではないのだがかなりの時間質問攻めにされてタジタジになったりした企業さんもあったりした。ただ、あくまで選考ではないので、その結果を突きつけられたりなどということはなかった（その企業の選考には進まなかったので、もし進んでいたら一瞬でお断りにされるとかあったのかもしれないが）。企業側としても「カジュアル面談って何すればいいんですかね？」と悩まれていたりもするようで、そのままその言葉を面談の場で投げられることもあった。俺も聞きたい。

企業側のスタンスも本当にまちまちで、こちらのブログをだいぶ読んでくれていて恥ずかしくなるぐらいにその話をしてもらうようなこともあれば、どうもこれは人手がとにかく欲しくて青田買いのように声かけまくって知名度を上げようという意図っぽいかな？ということもあった。別にそれが悪いとかそういうことではなく、職や金がほしいエンジニアと、人がほしい会社とのマッチング機会としてわりといい感じに機能しているんではないかなこのサービスは、と思った。こちらとしても、事前に自分の考えなりを読んでもらえているというのは、ミスマッチの可能性が抑えられそうで良かった。

エンジニアとお金と評価について

何か月か前に Google 退職者による年収公開が散発的に起きたりとか、昨今 IT 系のエンジニアとお金の話をよく見かけるようになった気がしていて、まぁ自分が30代になったので、観測範囲がそうなっただけかもしれないけれど、以前はタブー視されることも多かった「お金の話」がわりとラフにされるようになったんじゃないかみたいな感触は覚えている。それは自分としてはいいことだと思うし、私はこれだけしかもらえていなかった、という話に周囲の人がもっともらうべきだというアドバイスをしたり、あの会社はこれしか払わないのかみたいな話が回ったりとかして、界隈全体で適正な給与が払われるようになればいいなという想いがあるし、俺がお金ほしいというよりは、みんなでお金もらおうぜみたいなことは感じている。

今回のドラフトで実際に何度か指名を得たことで、なるほど自分はこれぐらいの金額を払ってもいいと評価してもらえるのか、と客観的な確認ができたことは、ある程度の自信につながった。ただ、必ずしもその金額はスカウターのように自分の能力を表す指標ではないということも思っている。先に書いたように、希少価値のある、ニッチな領域を攻めれば技術力はそこそこでも高給がもらえるチャンスは広がるだろうし、そもそもあくまでウェブ上でのアウトプットや自己申告のレジュメだけでの評価額なので、実際に選考に進んだら「やっぱこいつねーわ」ってなる可能性もある。また先日バズっていた 仕事と給与と評価の関係 - Speaker Deck という記事でも書かれている通り、会社の体力によって払える金額も当然変わる。給与は様々な要因によって決まるものであり、その人物の客観的な評価指標としては機能しないので、多ければ多いほど良いのは確かだけど、それをエンジニアとしての自分の戦闘力みたいに考えない、自惚れないようには注意が必要だなと思う。

なので、転職ドラフトは参加する分には無料だしリスクもないので、お金がそんなにもらえていないと感じるエンジニアは、これぐらい欲しいという額を多少背伸びしてもいいので希望してみて、とりあえず参加してみるといいんじゃないかなと思う。これぐらいお金が欲しいです！と表明して、それを複数の企業にアピールできる機会なんてのは早々ないので。自分も今は一旦不参加状態にしているけれど、今後また転職意欲の有無に関わらず、ふらっと参加してみたりするんじゃないかなーと今は思っている。

• 第1弾 購入編 : Lily58 Pro または私は如何にして市販品を探すのをやめて分割キーボードを自作するようになったか · the world as code
• 第2弾 作成編 : 電子工作初心者が Lily58 Pro を買ってから作って持ち運ぶまで · the world as code

自作キーボードの大きな魅力の一つが自由なキーマップを作れる点で、市販のキーボードのキーマクロ機能の比ではなく、本当にすべてのキーを自由にアサインできる。 Dvorak ももちろん可能だし、「俺が考えた最強の配列」を作ることもできる。また Lily58 をはじめ多くのキーボードはフルキーボードを比較してキー数が少なく設定されていることが多いため、レイヤーの概念などを駆使して、1つのキーに複数の機能をアサインすることも必要になってくる。どのキーにどの役割をいくつ与えるか、という組み合わせも考えていくと、途方もないほどに自由度が高い。

QMK Firmware

https://github.com/qmk/qmk_firmware

例の Ergodox 含め、多くの自作キーボードがファームウェアとして QMK Firmware という OSS を活用している。自作キーボード制作者は自身のキーボードを作成したら、そのキーマップ設定を追加して Pull Request を送ることで QMK Firmware 本体のレポジトリに merge されるようで、現在買えるような自作キーボードであれば、基本的には上記レポジトリから clone すれば、すぐにデフォルトキーマップを焼き込めるようになっている。もちろん、そこから自分でキーマップを変えていくこともできる。

QMK Firmware では単にキー配置を司るだけではなく、多くの付随的な機能を提供している。

レイヤー

shift キーのように、レイヤー切り替えキーを押下している間のみ、キーアサインが別のものに変換される機能。キー数が少ないキーボードではほぼ必須の機能であり、多くの場合 LOWER と RAISE の2つのレイヤーキーがデフォルトでアサインされている。

Tap Dance

1回押した場合と、すばやく複数回押した場合でキーアサインを切り替える機能。複数種類の括弧を1つのキーでまかなえるようにしたり、欧米圏でウムラウト付きのアルファベットなどを出す際に使われているのをよく見る印象。

Mod-Tap

他のキーと同時に押した場合は Modifier key = shift や control などの修飾キーに、単独で押した場合は別のキーに切り替える機能。確かに修飾キーというのは同時押しが基本なので、同時に押さない場合は別のキーとして扱う、というのはなんだか頭いいな、と思う発想だった。

Modifier Keys

修飾キー + 他のキーを押した状態を、1つのキーにアサインしてしまえる機能。どちらかと言えばキー数に余裕がある場合に、よく使うキーボードショートカットをアサインする、などの利用をするっぽい。

One Shot Keys

通常、修飾キーを使う際は同時押しが必要になるが、一度押すとそのキーが押された状態になり、別のキーを押すと押された状態が解除される、という機能。 Windows の固定キーに近い。

他にもマウス操作をキーにアサインできるとか、 Unicode のアサインも可能なので :thinking_face: を1キーで出せるとかいろいろできる。つまり 単純なキーの配置だけではなく、どの機能を使うと自分の理想的な運指になるか ということを考える必要があり、沼と呼ぶに非常にふさわしい。

なお Lily58 は対応していないが、キーボードにありがちな LED を光らせる設定も QMK Firmware でまかなうことができる。一部機能に関しては rules.mk というファイルに有効化の設定を書かなくてはならないため、ドキュメントを読みながら対応する必要がある。機能を有効化すると、その機能に関するコードがファームウェアに内包されるようになる仕組みと思われる。私の rules.mk はこんな感じ。

# Build Options
#   change to "no" to disable the options, or define them in the Makefile in
#   the appropriate keymap folder that will get included automatically
#
BOOTMAGIC_ENABLE = no       # Virtual DIP switch configuration(+1000)
MOUSEKEY_ENABLE = no        # Mouse keys(+4700)
EXTRAKEY_ENABLE = yes       # Audio control and System control(+450)
CONSOLE_ENABLE = no         # Console for debug(+400)
COMMAND_ENABLE = no         # Commands for debug and configuration
NKRO_ENABLE = no            # Nkey Rollover - if this doesn't work, see here: https://github.com/tmk/tmk_keyboard/wiki/FAQ#nkro-doesnt-work
BACKLIGHT_ENABLE = no       # Enable keyboard backlight functionality
MIDI_ENABLE = no            # MIDI controls
AUDIO_ENABLE = no           # Audio output on port C6
UNICODE_ENABLE = no         # Unicode
BLUETOOTH_ENABLE = no       # Enable Bluetooth with the Adafruit EZ-Key HID
RGBLIGHT_ENABLE = no        # Enable WS2812 RGB underlight.
SWAP_HANDS_ENABLE = no      # Enable one-hand typing
TAP_DANCE_ENABLE = yes

# Do not enable SLEEP_LED_ENABLE. it uses the same timer as BACKLIGHT_ENABLE
SLEEP_LED_ENABLE = no    # Breathing sleep LED during USB suspend

# If you want to change the display of OLED, you need to change here
SRC +=  ./lib/glcdfont.c \
        ./lib/rgb_state_reader.c \
        ./lib/layer_state_reader.c \
        ./lib/logo_reader.c \
        ./lib/key_count.c \
        ./lib/uptime.c \

Lily58 デフォルトキーマップ

すべて自分で考えて配置するのは大変なので、デフォルトキーマップを元に編集することにした。本記事執筆時点で、デフォルトキーマップは以下の通りになっている。

/* QWERTY
 * ,-----------------------------------------.                    ,-----------------------------------------.
 * | ESC  |   1  |   2  |   3  |   4  |   5  |                    |   6  |   7  |   8  |   9  |   0  |  `   |
 * |------+------+------+------+------+------|                    |------+------+------+------+------+------|
 * | Tab  |   Q  |   W  |   E  |   R  |   T  |                    |   Y  |   U  |   I  |   O  |   P  |  -   |
 * |------+------+------+------+------+------|                    |------+------+------+------+------+------|
 * |LCTRL |   A  |   S  |   D  |   F  |   G  |-------.    ,-------|   H  |   J  |   K  |   L  |   ;  |  '   |
 * |------+------+------+------+------+------|   [   |    |    ]  |------+------+------+------+------+------|
 * |LShift|   Z  |   X  |   C  |   V  |   B  |-------|    |-------|   N  |   M  |   ,  |   .  |   /  |RShift|
 * `-----------------------------------------/       /     \      \-----------------------------------------'
 *                   | LAlt | LGUI |LOWER | /Space  /       \Enter \  |RAISE |BackSP| RGUI |
 *                   |      |      |      |/       /         \      \ |      |      |      |
 *                   `----------------------------'           '------''--------------------'
 */

 [_QWERTY] = LAYOUT( \
  KC_ESC,   KC_1,   KC_2,    KC_3,    KC_4,    KC_5,                     KC_6,    KC_7,    KC_8,    KC_9,    KC_0,    KC_GRV, \
  KC_TAB,   KC_Q,   KC_W,    KC_E,    KC_R,    KC_T,                     KC_Y,    KC_U,    KC_I,    KC_O,    KC_P,    KC_MINS, \
  KC_LCTRL, KC_A,   KC_S,    KC_D,    KC_F,    KC_G,                     KC_H,    KC_J,    KC_K,    KC_L,    KC_SCLN, KC_QUOT, \
  KC_LSFT,  KC_Z,   KC_X,    KC_C,    KC_V,    KC_B, KC_LBRC,  KC_RBRC,  KC_N,    KC_M,    KC_COMM, KC_DOT,  KC_SLSH,  KC_RSFT, \
                             KC_LALT, KC_LGUI,LOWER, KC_SPC,   KC_ENT,   RAISE,   KC_BSPC, KC_RGUI \
),
/* LOWER
 * ,-----------------------------------------.                    ,-----------------------------------------.
 * |      |      |      |      |      |      |                    |      |      |      |      |      |      |
 * |------+------+------+------+------+------|                    |------+------+------+------+------+------|
 * |  F1  |  F2  |  F3  |  F4  |  F5  |  F6  |                    |  F7  |  F8  |  F9  | F10  | F11  | F12  |
 * |------+------+------+------+------+------|                    |------+------+------+------+------+------|
 * |   `  |   !  |   @  |   #  |   $  |   %  |-------.    ,-------|   ^  |   &  |   *  |   (  |   )  |   -  |
 * |------+------+------+------+------+------|   [   |    |    ]  |------+------+------+------+------+------|
 * |      |      |      |      |      |      |-------|    |-------|      |   _  |   +  |   {  |   }  |   |  |
 * `-----------------------------------------/       /     \      \-----------------------------------------'
 *                   | LAlt | LGUI |LOWER | /Space  /       \Enter \  |RAISE |BackSP| RGUI |
 *                   |      |      |      |/       /         \      \ |      |      |      |
 *                   `----------------------------'           '------''--------------------'
 */
[_LOWER] = LAYOUT( \
  _______, _______, _______, _______, _______, _______,                   _______, _______, _______,_______, _______, _______,\
  KC_F1,   KC_F2,   KC_F3,   KC_F4,   KC_F5,   KC_F6,                     KC_F7,   KC_F8,   KC_F9,   KC_F10,  KC_F11,  KC_F12, \
  KC_GRV, KC_EXLM, KC_AT,   KC_HASH, KC_DLR,  KC_PERC,                   KC_CIRC, KC_AMPR, KC_ASTR, KC_LPRN, KC_RPRN, KC_TILD, \
  _______, _______, _______, _______, _______, _______, _______, _______, XXXXXXX, KC_UNDS, KC_PLUS, KC_LCBR, KC_RCBR, KC_PIPE, \
                             _______, _______, _______, _______, _______,  _______, _______, _______\
),
/* RAISE
 * ,-----------------------------------------.                    ,-----------------------------------------.
 * |      |      |      |      |      |      |                    |      |      |      |      |      |      |
 * |------+------+------+------+------+------|                    |------+------+------+------+------+------|
 * |   `  |   1  |   2  |   3  |   4  |   5  |                    |   6  |   7  |   8  |   9  |   0  |      |
 * |------+------+------+------+------+------|                    |------+------+------+------+------+------|
 * |  F1  |  F2  |  F3  |  F4  |  F5  |  F6  |-------.    ,-------|      | Left | Down |  Up  |Right |      |
 * |------+------+------+------+------+------|   [   |    |    ]  |------+------+------+------+------+------|
 * |  F7  |  F8  |  F9  | F10  | F11  | F12  |-------|    |-------|   +  |   -  |   =  |   [  |   ]  |   \  |
 * `-----------------------------------------/       /     \      \-----------------------------------------'
 *                   | LAlt | LGUI |LOWER | /Space  /       \Enter \  |RAISE |BackSP| RGUI |
 *                   |      |      |      |/       /         \      \ |      |      |      |
 *                   `----------------------------'           '------''--------------------'
 */

[_RAISE] = LAYOUT( \
  _______, _______, _______, _______, _______, _______,                     _______, _______, _______, _______, _______, _______, \
  KC_GRV,  KC_1,    KC_2,    KC_3,    KC_4,    KC_5,                        KC_6,    KC_7,    KC_8,    KC_9,    KC_0,    _______, \
  KC_F1,  KC_F2,    KC_F3,   KC_F4,   KC_F5,   KC_F6,                       XXXXXXX, KC_LEFT, KC_DOWN, KC_UP,   KC_RGHT, XXXXXXX, \
  KC_F7,   KC_F8,   KC_F9,   KC_F10,  KC_F11,  KC_F12,   _______, _______,  KC_PLUS, KC_MINS, KC_EQL,  KC_LBRC, KC_RBRC, KC_BSLS, \
                             _______, _______, _______,  _______, _______,  _______, _______, _______ \

これに対する自分の意見は以下。

• 右GUI、右Shiftは不要
• Backspace が右親指の位置にあるが、最初は慣れないと思うので右上にも配置したい
• LOWER レイヤーにすべての記号がアサインされているが、 Lily58 は数字キーも存在するのでいくつかは重複アサインとなっており、不要
• ファンクションキーは数字キーと同じ列にそれぞれ配置するとわかりやすそう（F11とF12は諦める）
• 矢印キーは Vim の感覚から hjkl にあると覚えやすそう

これを踏まえてキーマップを作成した。

現時点で最強のキーマップ

自作キーボードは親指を駆使させ、小指を使わなくさせる傾向にあることが多い。　Ergodox の親指用キーの多さなどは顕著である。多くの人は小指より親指のほうが動かしやすいと思うので理に適った話ではあるが、しかし使い慣れたキー配置からの移行コストもあるわけで、一旦折衷的なキーマップとした。 まずはデフォルトのレイヤー。

/* QWERTY
 * ,------------------------------------------.                    ,-----------------------------------------.
 * | ESC   |   1  |   2  |   3  |   4  |   5  |                    |   6  |   7  |   8  |   9  |   0  |BackSP|
 * |-------+------+------+------+------+------|                    |------+------+------+------+------+------|
 * | Tab   |   Q  |   W  |   E  |   R  |   T  |                    |   Y  |   U  |   I  |   O  |   P  |  -   |
 * |-------+------+------+------+------+------|                    |------+------+------+------+------+------|
 * |CTL/GUI|   A  |   S  |   D  |   F  |   G  |-------.    ,-------|   H  |   J  |   K  |   L  |   ;  |  '   |
 * |-------+------+------+------+------+------|   [   |    |    ]  |------+------+------+------+------+------|
 * |LShift |   Z  |   X  |   C  |   V  |   B  |-------|    |-------|   N  |   M  |   ,  |   .  |   /  |CTL+Sp|
 * `------------------------------------------/       /     \      \-----------------------------------------'
 *                    | LAlt | LGUI |LOWER | /Space  /       \Enter \  |RAISE |BackSP| ESC  |
 *                    |      |      |IMEon |/       /         \      \ |IMEoff|      |      |
 *                    `----------------------------'           '------''--------------------'
 */

 [_QWERTY] = LAYOUT( \
  KC_ESC,           KC_1,   KC_2,    KC_3,    KC_4,    KC_5,                                KC_6,           KC_7,    KC_8,    KC_9,    KC_0,    KC_BSPC,      \
  KC_TAB,           KC_Q,   KC_W,    KC_E,    KC_R,    KC_T,                                KC_Y,           KC_U,    KC_I,    KC_O,    KC_P,    KC_BSLS,      \
  TD(TD_CTL_GUI),   KC_A,   KC_S,    KC_D,    KC_F,    KC_G,                                KC_H,           KC_J,    KC_K,    KC_L,    KC_SCLN, KC_QUOT,      \
  KC_LSFT,          KC_Z,   KC_X,    KC_C,    KC_V,    KC_B,            KC_LBRC,   KC_RBRC, KC_N,           KC_M,    KC_COMM, KC_DOT,  KC_SLSH, LCTL(KC_SPC), \
                                     KC_LALT, KC_LGUI, LT(1, KC_LANG1), KC_SPC,    KC_ENT,  LT(2,KC_LANG2), KC_BSPC, KC_ESC  \
),

Backspace と ESC は右親指で押すことを目指すが、現時点では一般的な位置にも配置している。最左列、下から2番目のキーは Tap-Dance により、1回押すと ctrl、2回押すと GUI とした。これは macOS でキーボードショートカットが GUI（⌘）に割り当たっている一方、 GNU Readline の各種ショートカットが ctrl と位置がバラけるのが嫌だったため。これも移行措置として、通常の位置にも GUI を置いている。

なお、 Tap-Dance はどのキーを何回押したときにどう動作させるか、という定義を書く必要があり、キーマップ以外に以下のようなコードを追加している。

enum {
  TD_CTL_GUI = 0
};

qk_tap_dance_action_t tap_dance_actions[] = {
  [TD_CTL_GUI] = ACTION_TAP_DANCE_DOUBLE(KC_LCTRL, KC_LGUI)
};

LOWER、RAISEの各キーは Mod-Tap により、単独で押した場合に KC_LANG1 と KC_LANG2 というキーをそれぞれ割り当てている。ドキュメントに記載はないのだが、これらは macOS のかな/英数に相当するらしく、 IME の切り替えが Toggle ではなく一発で出来るようになる。 US キーボードを使っていると IME 切り替えは ctrl + space などで Toggle させるしかなかったため、このアサインが出来るのは嬉しかった。

参考 : 変わり種ErgoDox紹介 + IME話 - Qiita

最右最下は正直余ってしまったので、 ctrl + space を割り当てた。 Windows での IME 切り替えに現在使っているが、 Windows でも OS 側の設定で KC_LANG 各キーを IME 切り替えに割り当てられるらしいので、後日対応の予定。

LOWER

/* LOWER
 * ,-----------------------------------------.                    ,-----------------------------------------.
 * |      |      |      |      |      |      |                    |      |      |      |      |      |      |
 * |------+------+------+------+------+------|                    |------+------+------+------+------+------|
 * |      |      |      |      |   ~  |      |                    |      |      |      |  _   |  +   |      |
 * |------+------+------+------+------+------|                    |------+------+------+------+------+------|
 * |      |      |      |      |   `  |      |-------.    ,-------|      |      |      |  -   |  =   |      |
 * |------+------+------+------+------+------|   (   |    |    )  |------+------+------+------+------+------|
 * |      |      |      |      |      |      |-------|    |-------|      |      |      |      |      |      |
 * `-----------------------------------------/       /     \      \-----------------------------------------'
 *                   | LAlt | LGUI |LOWER | /Space  /       \Enter \  |RAISE |BackSP| RGUI |
 *                   |      |      |      |/       /         \      \ |      |      |      |
 *                   `----------------------------'           '------''--------------------'
 */

[_LOWER] = LAYOUT( \
  _______, _______, _______, _______, _______, _______,                     _______, _______, _______, _______, _______, _______, \
  _______, _______, _______, _______, KC_TILD, _______,                     _______, KC_UNDS, KC_PLUS, _______, _______, _______, \
  _______, _______, _______, _______, KC_GRV,  _______,                     _______, KC_MINS, KC_EQL,  _______, _______, _______, \
  _______, _______, _______, _______, _______, _______,  KC_LPRN, KC_RPRN,  _______, _______, _______, _______, _______, _______, \
                             _______, _______, _______,  _______, _______,  _______, _______, _______ \
),

LOWER は記号キー用とした。通常配置で盛り込みきれていない記号キーだけに絞っている。

当初はハイフンを9に割り当てるなど、一般的配列と近い位置に配置していたが、わざわざ遠くへ押しに行く必要もないと考え直し、左右とも人差し指近くに集中させた。

RAISE

/* RAISE
 * ,-----------------------------------------.                    ,-----------------------------------------.
 * |      |      |      |      |      |      |                    |      |      |      |      |      | DEL  |
 * |------+------+------+------+------+------|                    |------+------+------+------+------+------|
 * | F11  |  F1  |  F2  |  F3  |  F4  |  F5  |                    |  F6  |  F7  |  F8  |  F9  | F10  | F12  |
 * |------+------+------+------+------+------|                    |------+------+------+------+------+------|
 * |      |      |      |      |      |      |-------.    ,-------| LEFT | DOWN |  UP  |RIGHT |      |      |
 * |------+------+------+------+------+------|   [   |    |    ]  |------+------+------+------+------+------|
 * |      |      |      |      |      |      |-------|    |-------| BRID | BRIU | VOLD | VOLU | MUTE |      |
 * `-----------------------------------------/       /     \      \-----------------------------------------'
 *                   | LAlt | LGUI |LOWER | /Space  /       \Enter \  |RAISE |BackSP| CAD  |
 *                   |      |      |      |/       /         \      \ |      |      |      |
 *                   `----------------------------'           '------''--------------------'
 */
[_RAISE] = LAYOUT( \
  _______, _______, _______, _______, _______, _______,                   _______, _______, _______, _______,  _______, KC_DEL,  \
  KC_F11,  KC_F1,   KC_F2,   KC_F3,   KC_F4,   KC_F5,                     KC_F6,   KC_F7,   KC_F8,   KC_F9,    KC_F10,  KC_F12,  \
  _______, _______, _______, _______, _______, _______,                   KC_LEFT, KC_DOWN, KC_UP,   KC_RIGHT, _______, _______, \
  _______, _______, _______, _______, _______, _______, _______, _______, KC_BRID, KC_BRIU, KC_VOLD, KC_VOLU,  KC_MUTE, _______, \
                             _______, _______, _______, _______, _______, _______, _______, LCTL(LALT(KC_DEL)) \
),

RAISE は機能的なキー担当。先述の方針通りにファンクションキーと矢印キーを並べている。

また Macbook に搭載されている輝度や音量調節のキーをよく使っていたので、それらも割り当てた。 Windows でも動いてくれるとうれしいのだが、いまのところ動かないので要調整。

右親指あたりにある「CAD」というキーは ctrl + alt + delete の同時押しに相当している。 Windows 最悪のあのキーバインドが簡単に打てて QOL がだいぶ上がった。右上の Delete は Windows で使うことがあるかもしれない、ということで念の為配置している。今のところ必要になったことはない。

Conclusion

この配置になるまで5回ぐらいはキーマップの変更を経ているが、ようやく安定したかなというところ。自作キーボードは組み立て終わってからが沼だとはよく言ったものだなと思う。

なるべく親指の役割を増やす、ホームポジションから手を動かさず済むようにする、というのは実際にやってみると確かに負荷が少ない。もともと自分は「腕を動かすのが嫌」という理由でトラックパッドとトラックボールを愛用してもいるので、キーボード上で指の移動距離を減らす、という考え方にもハマりこんでしまった。

そしてその結果、自分でも面白い変化だと思うが、「数字列」が遠いと思うようになってきた。指を動かす範囲は上下左右1キー以内に現状ほぼ収まってきたので、たまに数字列だけ2キー分指を伸ばさなくてはならないのがどうにも気持ち悪い。

この投稿をInstagramで見る

corne chocolate 買っちった

@ chrojuがシェアした投稿 - 2019年 5月月23日午前5時17分PDT

つまりこういうことである。 Lily58 から数字列をザックリ削ったような形状の Corne Chocolate を買ってしまった。キーマップを見てもらってもわかる通り、58キーだとちょろちょろ余ることもわかったし、42キーでも案外イケそうな気はしている。願わくば、これで End Game に至るといいのだが。

今回あんまりまとまった話でもなくて、いろいろ調べていたら手元のメモがだいぶ長くなったのでせっかくだし公開してみよう、程度のものです。正直文章化が上手くできているとも思えなくて、読みにくいと思いますしスルー推奨です。一応3行でまとめておきます。

• terraformer に issue を上げたら Terraform の内部実装に絡めた返答をもらったが、すぐに理解できなかった。
• そこで terraformer と Terraform のコードリーディングをしてみて、その過程を書いてみた。
• Terraform 内で使われている gRPC の勉強が必要とか、コードリーディングの効率を上げたいといった課題も見つかり、良い機会になった。

terraformer

terraformer というツールをご存知でしょうか。

https://github.com/GoogleCloudPlatform/terraformer

既存のクラウドリソースの状態を読み解き、 tf ファイルと tfstate ファイルを生成してくれるツールです。同様のツールとしては dtan4/terraforming が著名で、 terraformer の README.md 内でも言及があるほどですが、この2つにはそこそこ差異が見られます。

まず機能面においては、 terraforming が指定したリソースの tf ファイル、 tfstate ファイル相当の情報を愚直に標準出力に出す、非常にシンプルな実装をしているのに対し、 terraformer は tf ファイルと tfstate ファイルを同時生成するほか、 provider.tf や、terraform apply したときに動的に生成される、インスタンス ID のような computed な値を出力するための outputs.tf まで生成してくれる至れり尽くせりなツールになっています。また、例えば terraformer import aws --resources=route53 を実行すると Route53 に関するすべての情報を取得する、つまり aws_route53_zone と aws_route53_record 双方が生成される形になります。先のコマンドで生成されるファイルは以下のとおりです。

$ tree
.
├── outputs.tf
├── provider.tf
├── route53_record.tf
├── route53_zone.tf
└── terraform.tfstate

0 directories, 5 files

そして実装面でもだいぶアプローチが異なるのですが、それについては最後に触れようと思います。

発端となった issue

本題に入りますが、 先日 Route53 Records の import を terraformer で行ったところ、エイリアスレコードに関してちょっとした問題が起きたため、 issue を上げました。

https://github.com/GoogleCloudPlatform/terraformer/issues/65

何を言っているかというと、 Route53 の DNS Record には当然ながら TTL の設定ができるのですが、そのレコードがエイリアスレコードである場合は TTL の設定ができない（Terraform 的な言い方をすると、2つの要素が競合 = Confilict した状態）はずなのに、 terraformer は ttl = "0" として設定を入れてしまっている、という話です。この状態で terraform plan を実行すると、競合する要素が定義されているよ、というエラーになります。

これに対して開発者の sergeylanzman 氏が返答してきたのが、以下の文です。

It's know issue(#25) terraformer can't get today details about each field.

これだけではいまいちわからなかったので、ここで言及されている #25 の issue を引用してみると、このような内容になっています。

Today terraformer use terraform.ResourceProvider interface for get ProviderSchema with Attributes. In other interface we can get more Attributes from providers(like deprecation options) Need use schema.Schema from github.com/hashicorp/terraform/helper/schema

どうも terraformer が使っている terraform 側の interface の都合が絡んでいるようです。現在は terraform.ResourceProvider を使っているが、これを schema.Schema に変更したほうが、より詳細な情報を取得できる、という内容に読み取れます。私は Terraform の動作、ソースコードを広く把握できているわけではないので、この返答をもらっても飲み込むことができず、ソースコードにあたってみることにしました。

terraformer と Terraform を読み解く

まず terraformer の動作原理を少し確認しました。 import コマンドの実装部分は terraformer/cmd/import.go 内の func Import() にあります。ここではコマンドのオプション --resources で与えられたリソース名（Route53, S3 など）に対し、 for 文でそれぞれ以下のような処理が実行されています。

		err = provider.InitService(service)
		if err != nil {
			return err
		}
		err = provider.GetService().InitResources()
		if err != nil {
			return err
		}

		if len(options.Filter) != 0 {
			provider.GetService().ParseFilter(options.Filter)
			provider.GetService().CleanupWithFilter()
		}

		refreshedResources, err := terraform_utils.RefreshResources(provider.GetService().GetResources(), provider.GetName(), provider.GetConfig())
		if err != nil {
			return err
		}
		provider.GetService().SetResources(refreshedResources)

見たところ provider.InitService() で各サービス（Route53など）に対する初期化処理を行い、さらに provider.GetService().InitResources() で、各サービス内の個別リソース（Route53 Record や Zone など）に対する初期化を行い、その上で terraform_utils.RefreshResoures() というメソッドを呼ぶ、と何段階かを経ているのが読み取れます。ここの provider とはいわゆる Terraform Provider ではなく、 terraformer 内の terraform_utils.ProviderGenerator という interface を指しており、AWS、GCP等の各 Provider 向けにこれを実装しています。例えば AWS に関しては terraformer/providers/aws/aws_provider.go 内の AWSProvider が該当し、この中に func InitService() が定義されています。InitService で行われる処理は文字通り初期化処理で、例えば terraformer はすべての AWS サービスに対応しているわけではないので、ここで対応非対応の判定を行っていたりするようです。

続いて provider.GetService().InitResources() ですが、 Route53 の場合は terraformer/providers/aws/route53.go で定義されており、まずホストゾーンの情報をすべて取得してから、各ホストゾーンに対してレコード情報の取得を行う、という実装になっています。以下に、レコード情報を取得する部分を担っているメソッドである createRecordsResources() のソースを引用してみます。

func (Route53Generator) createRecordsResources(svc *route53.Route53, zoneID string) []terraform_utils.Resource {
	resources := []terraform_utils.Resource{}
	listParams := &route53.ListResourceRecordSetsInput{
		HostedZoneId: aws.String(zoneID),
	}
	recordSet, err := svc.ListResourceRecordSets(listParams)
	for _, record := range recordSet.ResourceRecordSets {

		resources = append(resources, terraform_utils.NewResource(
			fmt.Sprintf("%s_%s_%s", zoneID, aws.StringValue(record.Name), aws.StringValue(record.Type)),
			fmt.Sprintf("%s_%s_%s", zoneID, aws.StringValue(record.Name), aws.StringValue(record.Type)),
			"aws_route53_record",
			"aws",
			map[string]string{
				"name":    aws.StringValue(record.Name),
				"zone_id": zoneID,
				"type":    aws.StringValue(record.Type),
			},
			route53AllowEmptyValues,
			route53AdditionalFields,
		))
	}
	if err != nil {
		log.Println(err)
		return []terraform_utils.Resource{}
	}
	return resources
}

AWS の API を呼んで、実際に情報を取得しているのがここの6行目の箇所で、取得した list を格納した recordSet 変数に対して for を回し、必要な情報を格納した resources 変数を返り値として戻す、という構成になっています。しかし resources に情報を格納するコードを読んでみると、 API から取得した情報を格納しているのは14行目からの map[string]string を作っている箇所だけで、 name, zone_id, type という3つの要素しか格納されていません。これでは Route53 Record の情報としては当然ながら不足しています。

どうもこれを補うのが terraform_utils.RefreshResources() の箇所と見受けられます。「見受けられます」とぼかした書き方をしましたが、すみません、ここから先はちょっと追いきれませんでした。ここからいくつかのメソッドを呼び出す過程があり、長くなりそうなので説明は省きますが、ここで最終的に terraform.ResourceProvider に行き着くことができます。 goroutine を使って並行に terraform.ResourceProvider.Refresh() というメソッドを呼んでいるようです。

追いきれなかったのは、この Refresh() メソッドが何をやっているのかわからなかったためです。以下に terraform/resource_provider.go at master · hashicorp/terraform から引用します。

func (p *ResourceProvider) Refresh(
	info *terraform.InstanceInfo,
	s *terraform.InstanceState) (*terraform.InstanceState, error) {
	var resp ResourceProviderRefreshResponse
	args := &ResourceProviderRefreshArgs{
		Info:  info,
		State: s,
	}

	err := p.Client.Call("Plugin.Refresh", args, &resp)
	if err != nil {
		return nil, err
	}
	if resp.Error != nil {
		err = resp.Error
	}

	return resp.State, err
}

p.Client.Call という箇所がありますが、この Client というのは RPC Client です。 Terraform は本体とプロバイダ間の通信に RPC を用いているのですが、私自身 RPC 周りの知識が一切ないため、今回はここでストップと相成りました。ただ、ある程度の推測は可能です。この Refresh() メソッドの戻り値である terraform.InstanceState は terraform/state.go at master · hashicorp/terraform で定義されており、この構造体の中にある Attributes というフィールドが Attributes are basic information about the resource とドキュメントされています。ここから推測するに、 terraformer の import 処理は、 terraform.ResourceProvider.Refresh() により terraform.InstanceState としてクラウドリソースの情報を取得している、と考えてよさそうです。

だいぶ回り道をしてようやく本題に戻りますが、

Today terraformer use terraform.ResourceProvider interface for get ProviderSchema with Attributes. In other interface we can get more Attributes from providers(like deprecation options) Need use schema.Schema from github.com/hashicorp/terraform/helper/schema

この1行目については、これまでの過程で確認できました。3行目で、これに代わって使うべきとされている schema.Schema を見てみようと思いますが、これについては Terraform の Developer 向けガイド を見たほうがわかりやすそうでした。

// Provider returns a terraform.ResourceProvider.
func Provider() terraform.ResourceProvider {
    // Example Provider requires an API Token.
    // The Email is optional
    return &schema.Provider{
        Schema: map[string]*schema.Schema{
            "api_token": {
                Type:        schema.TypeString,
                Required:    true,
            },
            "email": {
                Type:        schema.TypeString,
                Optional:    true,
                Default:     "",
            },
        },
    }
}

このように、 schema.Schema は Terraform の Provider や Resource などの形式を定義する際に用いる構造体で、その要素が Required なのかオプションなのか、また他の要素と競合し得るのか、といった詳細な情報を持たせることができるものです。一方、現状 terraformer が使用している terraform.InstanceState.Attributes は単に Terraform Resource の要素をキーバリュー形式で格納した map に過ぎず、各要素がどのような意味を持つのかまで判断する材料にはなりません。そのため schema.Schema を使う形に変更すれば、私が指摘した Route53 Record で競合してしまっていた要素の検出も実装することができる、という、そういう意図だったようです。

terraformer の実装を解釈する

今見てきたように、 terraformer の import は以下のような実装となっています。

1. 対象のクラウドサービスの API を呼び出し、 import 対象である resource の ID など、最低限の情報だけをまず読み込む。
2. 取得した ID 等を元に、 Terraform Provider から terraform.ResourceProvider.Refresh() を呼ぶことで、 import に必要なすべての情報を取得する。

これは terraforming のアプローチとは大きく異なります。というのも、 terraforming はクラウドサービスの API を呼び、最初から必要なすべての情報を取得して書き出す実装となっているからです。 terraformer があえて処理を2段階に分けたのは、 Terraform resource はクラウドサービス側の仕様変更に伴って内実が頻繁に変わる可能性があるため、 Terraform resource の定義に関する処理を Terraform Provider 側へ任せる意図があったと思われます。 Terraform resource として必要な情報を取得する処理は Terraform Provider に任せてしまうことで、 terraformer は最初の初期化処理と、 tf, tfstate ファイルを書き出す処理に集中することができており、これは疎結合で良い実装だなと感じました。ただ、一方で Terraform Provider をあらかじめダウンロードしておく必要があったり、処理が増えるために少々動作が遅いと感じることがあったり、というデメリットも見られます。

Conclusion

今回、サードパーティツールが直接 Terraform や Terraform Provider のコードを呼び出していたため、それをきっかけとして Terraform に対する理解を深める良い機会になりました。ただ知識不足によりすべてが読み解けたわけでもなかったため、特に RPC については勉強してみようかと思っています。ちょうど Terraform 0.12 から gRPC を用いた実装に変更されますが、 gRPC と言えば昨今の microservices を追う上でも欠かせないプロトコルのようですので、その意味でも押さえておきたいところです。

また今回コードリーディングには VSCode を使って頑張って検索したり F12 で定義ジャンプしたりしていたのですが、もっと効率の良いやり方がありそうだなという気もしてます。1日作業になってしまったので、もう少しコードリーディングには慣れていきたいです。

前提を再度書いておきますが、中学校の授業以外でハンダ付けしたことがない超ビギナーが Lily58 Pro という自作キーボードを組み立てたお話です。このエントリーも Lily58 Pro で書きました。

買ったもの

お買い物ですが、キーボードキットは遊舎工房さんの実店舗、はんだ付け関連の工具は Amazon とダイソー（？！）を使いました。

キーボードキット

Lily58 Pro は必要なものがキットになった状態で売られていますので、それを買います。私はロープロファイルである Choc 用のものを買いましたが、 Cherry MX 軸用のバージョンもあります。基盤は共通で、キーソケットを変更することでどちらにも対応するようなキットになっています（一度キーソケットをはんだ付けしたら変更はできないです）。

• Lily58 Pro | 遊舎工房

他に必要なものはキースイッチ、キーキャップ、左右のキーボードを結ぶ TRRSケーブル 、パソコンと接続するための micro USB ケーブルです。いずれも遊舎工房さんに置いていて、店員さんが必要なものをピックアップしてくれたので助かりました。

キースイッチは、現在遊舎工房さんに取り扱いがあるのは赤軸（リニア）、茶軸（タクタイル）、白軸（クリッキー）の3種類で、私が行ったときには赤軸が在庫切れになっており、白軸はオフィスで使うには適さないため茶軸としました。結果的に快適に使えているので、他の軸に替える必要もなさそうです。荷重はいずれも 50g ですが、もっと重いものが欲しい場合には海外通販になりますが、 NovelKeys などで購入できます。

https://novelkeys.xyz/products/novelkeys-x-kailh-low-profile-heavys

工具

Amazon で以下のものを購入しました。はんだごては温度調節機能があったほうがよいという話だったので、それを満たす上で高すぎないものとしています。作業マットは正直よくわからなかったものの、難燃性っぽいものを買っています。少しゴムの匂いが強くてしんどかったです。ボンドガン（グルーガン）については後述します。

白光 ダイヤル式温度制御はんだこて FX600

posted with amazlet at 19.04.27

白光(HAKKO) (2012-01-18)
売り上げランキング: 145

Amazon.co.jpで詳細を見る

goot はんだこて台 ST-11

posted with amazlet at 19.04.27

太洋電機産業(goot)
売り上げランキング: 343

Amazon.co.jpで詳細を見る

エンジニア 卓上導電マット A4サイズ 230×330×2mm ZCM-05

posted with amazlet at 19.04.27

エンジニア(ENGINEER)
売り上げランキング: 16,687

Amazon.co.jpで詳細を見る

goot はんだ吸取り線 CP-2015

posted with amazlet at 19.04.27

太洋電機産業(goot)
売り上げランキング: 2,543

Amazon.co.jpで詳細を見る