出力を入力へ

プログラミングに関する自分が考えた事を中心にまとめます

2025年のふりかえりと2026年の抱負

まさか2024年のふりかえりの記事の次が2025年のふりかえり記事になるとは。

2025年のふりかえり

したこと

自宅サーバ環境の整備

もともと懸念だった自宅サーバ環境の整備に取り組んだ。 HWまわりの整備(NAS追加、2.5GbEネットワーク設置、ミニPC設置)、IaaSまわりの整備(Proxmox VEクラスタ、DNS+DHCPサーバ)、k8sクラスタの構築など。

自宅サーバ環境は、AWSを使うようになってわざわざ自宅環境を整備するモチベーションが減少して放置していた。もともとはSaaSが使えない環境での検証用途として、GitLabやJenkinsなどを構築・検証するための基盤として利用していた。これがGitHubなどのSaaSが利用できるようになり、検証環境も不要になったので自宅検証環境が不要になった。

この事情がk8sを業務で利用するようになって一変し、自分用のk8s検証環境が必要になった。k8s自体の理解度を上げる必要があるし、k8s上で実行するアプリケーション運用の経験も積む必要がある。とはいえ自分の個人検証用途にk8sクラスタをGKE等で構築運用するのはかなりお金が掛かる。検証期間だけ構築するにしてもセットアップに時間は掛かるし、運用検証ができないのが課題だった。

これを解決するために自宅k8sクラスタを構築した。Googleがカスタマイズしていないバニラなk8sが欲しいし、k8sやその上で動作するアプリケーション群を自分で検証したい。このためにはある程度リッチな環境が必要と判断した。 もちろん、ラズパイのようなシングルボードコンピュータを用いて簡易クラスタを組むのも手だが、ミニPCであれば消費電力的にもスペック的にも十分だし望ましいと判断した。

現状でも無事にクラスタが稼動して無事に検証に活用できている。 バージョンアップグレードや監視まわりの整備などまだまだ足りていないところも多いが、それも含めて2025年中に一応整備できてよかった。

Webサービス開発への着手

生成AIを活用していろいろ試せるようになったことで、自分向けのサービス開発が進んだ。

これまではフロントエンドまわりに苦手意識があり着手できなかったアイデアも、生成AIの支援により形にできるようになった。技術検証のMVPとしてのプロダクトづくり

また、前述の自宅k8sクラスタを構築したことで、とりあえずそこにデプロイして利用するという選択肢が生まれたのもサービス開発が進む1要因となった。業務でGoogle Cloudのナレッジが蓄積できて、ゼロスケールの環境としてCloud Run Serviceも選択肢に生まれたのもよかった。 従来はVercelなどが選択肢としてはあるものの、制約も多かったり、結局DBどこに立てて運用するの(お金掛けるの)という疑問が解消されなかった。ECSを使うとコンピューティングリソースのお金が掛かるのも制約だった。

一方で、結局最後までリリースできたサービスはおそらくなさそう? どれも中途半端に手を掛けてそのまま放置で終わっている。これがよろしくない。

自分に足りないものの認識

これをしたこと、に含めるのは若干違和感があるが。 転職から1年が経ち、やっと自分に何が足りないのかわかってきた。転職直後の何もかも足りないという感覚から、これは通用する、これは無くてもまだ何とかなる、これは明確に足を引っぱっている、といったグラデーションが見えてきた。

具体的にはソフトスキルとSREとしての専門性が課題に感じている。

1つ目はソフトスキルは、特に他人にわかりやすく伝える能力が足りていない。 頭の中では課題感を描けていても、これを言語や文章で相手に伝え、行動変容を引き出すことができていないでいる。特に相手の専門性が異なると顕著。 これはSREとしてエネーブリング力が特に求められるので致命的になっている。現在は相手が寄り添ってくれたり、他のSREにサポートしてもらってなんとかなっているがこれを改善する必要がある。

2つ目はSREとしての専門性が足りていない。もともとは、IaCに強みを持つと認識しており、また幅広い技術領域に一定の知見があるのでどのような技術的課題にも対処できることろは強みがあると思っていた。実際、これについてはある程度通用することがわかりなんとかなった。

一方で、IaCの強みを発揮するには対象のプラットフォームについての知見、具体的にはGoogle CloudやCloudflareなどの理解も必要で強みを発揮しずらい状況にある。この状況でIaC(terraform)の専門性を強化しても自身の価値向上としては効果が薄かった。 IaCに並ぶ別の強みや専門性を獲得する必要がある。とはいっても従来持っていたVM層の知見は今は何の価値もないので、SRE領域で専門性を磨いていきたい。隣接するDev/OpsやPlatform Engineeringも含めて専門性を獲得することも、現在の知識の幅という意味での強みを伸ばすことにはつながるが、そうではなくSREとしてSREの専門性を強化したい。 具体的にはSLI/SLO、オブザーバビリティ、アラート/モニタリング、インシデントレスポンス、キャパシティプランニングなど。

できなかったこと

2025年の目標

2025年の目標として掲げた「1つ1つ学ぶ」「データと仲良くなる」「強みを伸ばす」にはほとんど取り組めなかった。目標設定が自分に足りないものとズレていて、この目標に合った行動を取れなかった。 本来は目標をすぐに修正して取り組むべきだったが、目標修正というアクションを取れずにずるずると過ごしてしまった。 これは目標設定が若干形骸化していた面もある。自分が今後どのように成長すべきかキャリアの迷子感が出ており(だからこそ転職したという面もある)、具体的に何をすればよいかわかっていなかった。

この1年掛けて自分に足りないこと、やりたい事がより明確になったので新しい目標を定めて取り組みたい。少なくとも、目標が変わったら修正できるようにしたい。

インプット/アウトプットの減少

インプット/アウトプットは質・量ともに減少した1年だったなと感じる。

インプットについて、読んだ書籍も少ないし、勉強会に参加する頻度も減った(オンラインですら参加しなくなった)。ポッドキャストやブログなんかのインプットもだいぶ減った気がする。 ここは適量となる定量的な閾値は存在しないので感覚的なものになるが、少なくともこの1年はどれも足りていない印象。 別に数を計測する必要はないけれど、意識して情報を取り入れていく。

インプット以上に深刻なのがアウトプットの低下。 ブログ記事はメインブログが1件、サブブログが10件、Zennが3件で合計14件だった。また、ソフトウェアとしてもリリースできたといえるものが挙げられない。これはアウトプットとしてはだいぶ少ない。

「1つ1つ学ぶ」という2025年の目標においても、学んだことをアウトプットしたかったができなかった。 これは、時間確保の問題とアウトプット対象となる課題選定に問題があると感じている。

  • 生活の質低下による時間不足
    • 睡眠の質が悪く、生活が崩れがちだった
    • 業務で疲れてプライベートでの研鑽の時間を確保できなかった
    • 時間の使い方が下手でメリハリをつけられなかった
  • 取り組む技術課題のミスマッチ
    • 業務と関連性の高い課題、低い課題の混在
    • やりかけタスク増に伴うフロー効率の低下

時間確保不足については、生活の質が低下したと実感しておりその影響かと感じる。 単に机に向かう時間が確保できていない。ぐったりしている、だらだらしている時間が多い。休むなら休むべきだし、取り組むなら集中するべきだった。 これはもう睡眠の質が一番の原因であることがわかっているのでこれの改善は引き続き行っていく。 年齢からくるやつだから、ある程度はしょうがないにしてもできるだけ改善したい。

一方で費やした時間も無駄(?)なことに掛けてしまった実感がある。 これは生成AIのおかげで今までできなかったことができるようになったので、いろいろ手を伸ばし過ぎた印象。せめてその成果をきちんとアウトプットにまとめることができたらよかったのだけど、それもできなかった。 どうしても作業が並列化しがちで、その結果ある程度まで成果が出たら次のタスクを着手してしまい、結果やりかけのプロジェクトが多数できてしまった。中にはいつかはやりたいな、みたいな実験的なプロジェクトも含まれており、それはそれでいいのだけれど今やるべきことではなかった。 もっと重要度・緊急度に合わせた作業優先度レーンを意識して、優先度が高いものを最後までやり切る、優先度が低いものは空いた時間で対応できるようにしたい。

その他

技術以外に使った時間としては、zwiftと雀魂がある。

zwiftは1年で 167時間 / 4209.9km だった(バーチャルライド以外も多少含まれている)。これは2024年の 231時間 / 5783.1km に比べるとだいぶ減少している。その実感はあり、全然走れていない。 時間と強度の両面でもっと取り組みたい。継続した運動は今後の生活の質向上および体力維持に必要不可欠なので、もうひと頑張りしたい。 レースへの参加もグループライドへの参加も減っているのでこれらの継続が必要。

雀魂は1年で682局打った。ちょっと打ち過ぎでは? 1日1半荘を目標に、豪3から傑3まで行ったりきたりで現在は豪1で停滞している。 2024年ごろから打つようになり、覚えることたくさんで楽しく打てていた。モチベーション的にもひと段落した感があり、2026年はもう少し見直すかも。

2026年の抱負

ソフトスキルの改善

業務上でも一番の課題となっており、ここにプライベートでも時間を掛けたい。

対人スキルについては業務を通して学ぶことが大半かもしれないが、プライベートでも学ぶべきことはたくさんありそう。 具体的には、スタッフエンジニアリングの文脈でのリーダーシップ、ドキュメントライティングの文脈での文書作成術、アジャイル文脈でのコラボレーションなど。これらのインプットについては力を入れたい。

また、ブログ執筆という形で実践したい。短い時間でわかりやすく伝えるという意味ではブログ記事の作成はまさに実践的なテーマ。 1つ1つの記事に時間を掛け過ぎずにわかりやすい記事を書けるようになりたい。

SREに関する専門性の獲得

IaCだけでなく、それに並ぶ専門性を獲得する。具体的な領域はまだ定まっていないので目標としては弱いが、基本的にはどれか1つしか身に付けないのではなく、SREとしてのスキルの底上げとして全体的に伸ばしながら特定の領域で強みを発揮できるようにしたい。 現状ではSLI/SLO、オブザーバビリティ、アラート/モニタリング、インシデントレスポンス、キャパシティプランニングなどが候補だが 専門技術として学ぶ余地が大きいという意味ではオブザーバビリティにはぜひ取り組んでみたい。

時間の使い方の改善

技術的なテーマではないが、影響が大きいので意識して取り組みたい。 睡眠の質を改善し、生活リズムを改善する。メリハリをつけた時間の使い方を意識して、集中した時間を確保できるようにする。

睡眠と生活リズムは、運動・食事・睡眠の取り組み改善を継続する必要があると思うのでこれを意識する。

時間の使い方について、現状だとポモドーロぐらいしか仕組みによる改善方法が無い。 ポモドーロの利用は継続しつつ、それ以外の選択肢や仕組みを取り入れてみたり、作業時間以外の時間の使い方を意識できるようにしたい。

2024年のふりかえりと2025年の抱負

2024年のふりかえり

したこと

転職

10月に転職した。 求められる役割としては大きく変わらないけど、普段利用する技術スタックや会社規模、バリューやカルチャーなどが大きく変化した。

これによってだいぶ大きくコンフォートゾーンから抜け出して苦労している。狙っていた苦労であり毎日が学びなのでよいのだけれど、若干パニックゾーンに足を踏み込んでいた感触がある。 3ヶ月経過しだいぶ業務にも慣れ始めてきたけど、まだまだ自分のスキル不足を実感することが多い。

当面はいかにキャッチアップしていくか、わからないときに上手く対処できるようになるかが重要。 特にわからないときの対処が重要で、今後もすべてを理解して上手く対応できるようになるとは思えない。わからないことがある前提の対処が下手な実感があるのでこのあたりを改善していきたい。

アウトプット

2024年も細々と開発は続けてきたけど、2023年に比べてアウトプット(アウトカム)はだいぶ減った。 2023年にひたすらたくさんコミットすることを意識した結果無駄も多かったのでその反省を踏まえてなのだけど、2024年としては上手くいかなかった。

やはり成果目標と行動目標の両方が必要だった。特に自分は成果目標を掲げれば自然と達成できる人ではないので、成果目標と行動目標の両方が必要だった。 毎日コミットのような行動目標は無駄も多く生じていたけど、それなりに成果にも繋がったので良い行動目標だったのだなと再認識した。

ブログ記事執筆は、メインブログが7件、サブブログが29件、Qiitaが1件、Zennが7件だった。

これはだいたい2023年と同等のペースだろうか。まだまだブログ記事化せずに終わらせたネタが多い印象なのでもっと細かく書いていきたい。 特にメインブログにて自分が感じたこと考えたことを残していきたい。特に今は新しい環境にて考えることも多いので書くネタはたくさんある。

できなかったこと

2024年の目標だった「行動と思考をアウトプットする」および「アウトカムベースで個人開発に取り組む」はどちらも上手くいかなかった。

アウトカムベースでの個人開発は前述の通り、成果目標だけではだめで行動目標が必要だった。 これはOKRを考慮し、KRの設計が必要。2025年は個人開発でもOKR再導入するとよいかも。

行動と思考のアウトプットも前述の通り書き切れていない。 実際に手を動かした内容であればQiita/Zenn/サブブログに、考えたことはメインブログに記録したい。

その他

読んだ本

2024年もたくさん積読したけど、読み切れた本は少ない。 ここはだいぶ危機感がある。インプットも少ないしアウトプットも少ない。

絶対的な読書時間の確保が必要。

購入したもの

ガジェット系で購入したものとしては以下がある

Google Pixel Tablet

Androidのタブレット難民になっており、ミドルスペック以上のものが欲しいなと探している中でホルダーが別売になったので購入。 概ね期待通りで満足しているがやはり11インチは大きい。引き続きミドルスペック以上の8インチタブレットを探している。

Majestouch Convertible 3 (茶軸、テンキーレスー日本語配列)

MacBookPro 用途にも外部キーボードとして欲しいなと思い、既存のMajestouch 2に追加して購入。 ただし、外部キーボードと合わせて外部マウスを使うときは外部マウスのみスクロール方向を逆にするために Scroll Reverser を導入するなどひと工夫が必要だった。結果だいぶ満足している。

コンピューティングリソース

業務として利用するインフラもAWSからGoogle Cloudに変化したことに合わせて、個人での開発の場も少しずつGoogle Cloudに寄せ始めている。 ただし、単に会社と同様の技術スタックを採用するとGKEのコストなどが無視できなくなる。

こういった問題を回避するために、自宅サーバの機運が高まっている。 個人開発や検証用途には高い可用性は不要なので、自宅サーバでKubernetesクラスタやelasticsearchを構築・運用したい。 ただし自宅サーバの運用を再開するなら解決したい問題もいろいろあるので、そのあたりをどこまで対処するか悩みどころ。

2025年の抱負

1つ1つ学ぶ

転職して求められる技術スタックが大きく変化した。日々の学びが多い一方でどうしても目の前の課題解決だけで済ませている感触がある。 せっかく取り組んだのなら理解を深めていきたい。

そのため1つ1つの学びを確実に昇華できるようにしたい。 ブログ記事のような形で学んだことをアウトプットしたり、学んだ技術を個人のソフトウェア開発やプロダクトに落とし込んでいきたい。

データと仲良くなる

これは2022年の目標でもあった。

当時よりも構造・非構造なデータの取り扱いやパフォーマンスの考慮などが求められそうになっている。 以前も業務で取り組んだがあまり機能・非機能の両面で求められることも少なく、自前のプロダクトでも活用できずで軽く触るだけで終わってしまった。 今は単に構築するだけ、設定するだけでは終われないのでより深く関わる必要があるのでよいチャンス。

また、MySQLではなくPostgreSQLが求められたり、業務外でもデータ分析基盤としてDuckDBやIcebergなどの面白そうなプロダクトが見えているのでいろいろキャッチアップしたい。 単にデータレイクを構築するのではなくデータパイプラインなどの処理・活用は業務でも個人開発でも取り組みたい。

まだまだデータと仲良くなるとは何か、具体化できていないので取り組む中でもっと課題を具体化したい。

強みを伸ばす

優秀な人が多い(そもそもエンジニアの数が多い)現職において、自分の強みは何かを考えた上でその技術を伸ばしていく必要がある。

現時点で見えているのは terraform でこれは十分リードして行けそう。 ただし、terraformは単体ではスキルとして発揮しずらく、Google CloudなりCloudflareなり他の技術との組合せが必要。こういったterraformと組み合わせる技術についても伸ばしてリードできるようになる必要がある。 terraform単独で伸ばしていくならTerragruntやAtlantisといったterraformの実行環境まわりや、trivy、tflint、OPA/Regoなどのlintおよびポリシー系について習熟していく必要がある。 実行環境まわりは今までHCP Terraformに強く依存していたし、OPA/Regoのようなポリシー構築も今まで不要だったので伸びしろがたくさんある。

またterraform以外の強みも身に付けていく必要がある。 隣接領域を踏まえた候補としては、Google Cloud、Kubernetes、DBREなどがポイントか。

Google Cloudは前述の通りterraformのスキルを活かすという意味でも大切。少なくとも業務で利用しているサービスは知見を深めておきたいし、今後利用見込みのあるサービスについても把握しておきたい。 Kubernetesについては直接terraformのスキルを活かすという意味では効果は薄いがプラットフォーム寄りのスキルは必要不可欠なので学んでおきたい。特にKubernetesのエコシステムについては以前より学びたかったし、よいチャレンジになりそう。 DBREは前述のデータと仲良くなる、の目標と通ずるところがある。これは現時点では自分の強みではないが今後の強みとして発揮できるように伸ばしていきたい。

「チームトポロジー」を読んだ

もともと発売当初に購入して流し読みだけしていたけど最後まで読み切れていなかった。 あらためて内容を詳細に把握しておきたいということで読み切った。

概要

チームトポロジー本については訳者の紹介記事やfukabori.fm が詳しい。 自分はfukabori.fmで強く興味を持って購入した(気がする)。

www.ryuzee.com

fukabori.fm

副題にある通り、ソフトウェアの素早いデリバリを実現するためにチームをどのように設計すべきか、について書かれている。

よかったところ

この書籍の内容は、逆コンウェイ戦略や4つのチームタイプと3つのインタラクションモードのような組織設計が主眼ではなく、 認知負荷にどのように対処すべきかが主なトピックであると理解した。 認知負荷に対処するために不要なコミュニケーションを制限するアプローチとして、これらの組織設計を活用するという話が単に紹介記事を読むだけでは理解できていなかった。
このあたりの誤解を解くためにも実際に本書を読んでよかった。

この書籍でも何度も参照・引用しているが、「LeanとDevOpsの科学」に触れて逆コンウェイ戦略の必要性などを語っている。 LeanとDevOpsの科学を読んだ当時は、自分も逆コンウェイ戦略を活用して組織をどうするべきか会社で話をした記憶はあるが、認知負荷にここまで焦点を当ててはいなかった気がする。 そういう意味で、LeanとDevOpsの科学から次の具体的なアクションに進める上で認知負荷への対処が重要なファクターであるということを言語化・再確認できた。これを認識する上で読んでよかったと感じた。

チームタイプのような組織設計みたいな話になると「ユニコーン企業のひみつ」で紹介されているようなSpotifyモデルが有名。 チームに自律性を持たせたマトリックス型の組織を構成することで、高いアジリティをイノベーションを実現できるととが説明されている。 一方で、単なる組織構造だけ真似しても上手くいかず、マインドセットなどが重要であることも知られている。加えてSpotifyも早々にSpotifyモデルから変更したことも知られている。
本書では特にチーム間のコラボレーションに焦点を当てている点が大きく異なる。 チーム間で必要なコラボレーションの量とそのチームの特性に応じてインタラクションモードを選択することで、チームやチーム間の認知負荷を削減して素早いリリースを実現しようとしている。 また必要なイノベーションに応じてインタラクションモードを変更することでコラボレーション量を調整し、チーム間の関係を適応的に変更していく動的組織の重要性を説明している。 このように、チーム間の関係がチーム特性や状況によって異なること、それは動的に変更していかないといけないと明確に認識できたことがよかった。

agile.quora.com

組織設計の話を扱う書籍のうち本書で触れていない書籍としては「エンジニアリング組織論への招待」などがある。 エンジニアリング組織論への招待では主に不確実性を扱っており、不確実性とは何かに焦点を当てて解説している。 一方で社内の共通言語として問題を認識するためには有効でも、具体的にどのように解決していくのかまでは距離があると感じていた(だからこそ「組織論への招待」なのかもしれない)。
本書では4つのチームタイプと3つのインタラクションモードという、実践的なパターンに落とし込んでいるのでより具体的なイメージを描くことができる。 特にこのパターンは実際のソフトウェア開発組織に非常に近いので、自社であればこのように適用できる、と具体的な解決策の提案まで考えることができるところがよかった。

リリースを最適化するというアプローチとしては「This Is Lean」を思い出した。 こちらはリーンの説明としてリソース効率ではなくフロー効率を重視することで、素早い価値提供を実現する方法について説明している。 This Is Leanはソフトウェア開発だけでなくあらゆる業界に適用できるためソフトウェア開発特有の事情には触れていない。またチーム(リソース)よりもプロダクト(フローユニット)に着目している。
チームトポロジーはプロダクトファーストよりチームファーストのアプローチに着眼している点が大きく異なると感じた。 組織におけるフローを良くするという目的は同じでも、本書はソフトウェア開発を行うチームファーストアプローチを採用している。 また、ソフトウェア開発という不確実性(変動)が高い状況においてはリーンのようなフロー効率を高める方法には限界がある。 このようなケースへの対処としてチームファーストでコラボレーション量を調整することで、イノベーションを実現するというアプローチを知れたとこがよかった。

疑問点

この書籍の問題なのかよくわからないが、本書を読み進めるのに苦労した。なぜ読み進めるのに苦労したのかは上手く言語化できていない。 訳書だからかもしれないし(あまり表現にひっかかることは無かったと思うが)、組織論のような分野があまり得意では無いからかもしれない。LeanとDevOpsの科学やエンジニアリング組織論への招待も苦労したので。

また、書籍の肝である適応的に組織を変更するところは腑に落ちていない。 もちろん、コラボレーションが不足していたらインタラクションモードを変更するとか、必要に応じてチーム構成やチームタイプを変更するという考え方はわかる。 またChapter8に記載されているチームトポロジーを再設計するきっかけとなるシグナルの例もなんとなくわかる。
しかし実際に業務においてこれらのシグナルを観測したとしても、それはチームトポロジー再設計のタイミングだとは気付けない気がする。 チームトポロジーの変更は数ヶ月掛けて変更するものと説明があるので、シグナルを受け取ってその場で判断するのではなく他の施策にいろいろ取り組んでそれでもだめならチームトポロジーの変更を検討するのかもしれない。 これは実際にチームトポロジーを実践して考えてみたい。

Kubernetes The Hard Wayをやった

Kubernetsを学ぶ上での鉄板教材であるKubernetes The Hard Wayをやった。 Kubernetes関連の書籍は数冊読んでいるが、運用経験は無く、もう少し内部コンポーネントについて理解を深めたかった。 以前(5年以上前)はいつかやりたいなで終わってしまったので、今回時間を取って取り組んでみた。

やったこと

基本はチュートリアルの通り(写経)。 ただし、条件として以下を変更している。

  • VMとして自宅ラボを利用
  • jumpboxマシーンとして常用の開発サーバを利用
  • サーバホスト名にprefix khw-を付与

VMはQEMU on Ubuntu 22.04(x86_64)を利用して構築した。 このUbuntu上に64-bit Arm System emulatorを利用してDebian (arm64)のVMを構築した。 これ自体は特に後続手順に影響は無く、qemu-system-arm パッケージをインストールすること、インスタンス作成時に aarch64 を選択することくらいしか違いが無かった。 しかしarm64エミュレーションのせいか処理が若干重く感じた。 今まであえて arm64エミュレーションでVMを実行してこなかったのでよい経験になった。
VM構築にisoから手動でインストールセットアップしたので、実はこのVM構築がおそらくチュートリアル中で一番時間が掛かった(単に待つ時間が長いだけだが)。

jumpboxサーバはDebian / arm64 でなくても良いとのことだったので、普段利用しているUbuntu 22.04 (x86_64)を流用する形にした。 当然この影響でトラブルに遭遇したのだが(後述)、良いトラブルシューティング程度で済んだ。特に影響なし。

サーバホスト名として、チュートリアル中では server node-0 node-1を推奨していたが、自宅検証環境の関係からprefixに khw-を付与し、khw-server khw-node-0 khw-node-1とした。 こちらも良い感じのトラブルを引き起こすことになったが(後述)、あまりKubernets関連の理解向上に寄与したわけではないので何ともいえないところ。

遭遇したトラブル

openssl1.1.1によるTLS証明書の作成失敗

ステップ4の ca.confによるTLS証明書の作成ステップにはいくつかのトラブルに遭遇した。 1つはopensslのバージョン影響による複数オプションが動作しないこと。自分の開発環境では、Ruby 2.7利用のためopenssl 1.1.1を利用していた。openssl 3.0からは -noenc-section -copy_extensionsなどのオプションが追加されている。 これはopenssl 1.1.1では利用できないのでTLS証明書の作成に失敗した。

Ruby2.7環境は今後不要になること、仮にruby2.7がまた必要になってもrbenvが対処してくれて自前でopenssl1.1.1のセットアップは不要になることから、openssl1.1.1は無効化してopenssl 3.0を利用することで解決した。 openssl1.1.1をまだ利用していたことを認識しておらず、このあたりのセットアップ手順はansible化していなかったので1つ自分の開発環境の負債を解消することができた。

blog.noellabo.jp

www.hsbt.org

とはいえ、opensslのオプション詳細やcnfファイルについては詳しくない。何となくやりたい事はわかる、くらいの感覚なのでもう少し理解を深める必要がある。 必要な情報は openssl-reqのman (web版はこちら)にあるので、これを読み解いていく必要がある。

ホスト名変更をca.confに反映する

TLS証明書を作成する上では接続先のホスト名変更についても考慮する必要がある。 単にssh先を変更するだけであればほぼ影響ないが、TLS証明書を作成する上でホスト名が間違っていると正しく接続できないので ca.confファイルを修正する必要がある。 とはいえ単にセクション名の変更やDNS設定の変更だけなのであまり迷わずに修正できた(これで正しいのかはあまり自信は無い)。

$ git diff ca.conf
diff --git a/ca.conf b/ca.conf
index eb17657..4f90131 100644
--- a/ca.conf
+++ b/ca.conf
@@ -46,7 +46,7 @@ CN = service-accounts
 # that identifies them as being in the `system:nodes` group, with a username
 # of `system:node:<nodeName>`.
 
-[node-0]
+[khw-node-0]
 distinguished_name = node-0_distinguished_name
 prompt             = no
 req_extensions     = node-0_req_extensions
@@ -57,17 +57,17 @@ extendedKeyUsage     = clientAuth, serverAuth
 keyUsage             = critical, digitalSignature, keyEncipherment
 nsCertType           = client
 nsComment            = "Node-0 Certificate"
-subjectAltName       = DNS:node-0, IP:127.0.0.1
+subjectAltName       = DNS:khw-node-0, IP:127.0.0.1
 subjectKeyIdentifier = hash
 
 [node-0_distinguished_name]
-CN = system:node:node-0
+CN = system:node:khw-node-0
 O  = system:nodes
 C  = US
 ST = Washington
 L  = Seattle
 
-[node-1]
+[khw-node-1]
 distinguished_name = node-1_distinguished_name
 prompt             = no
 req_extensions     = node-1_req_extensions
@@ -78,11 +78,11 @@ extendedKeyUsage     = clientAuth, serverAuth
 keyUsage             = critical, digitalSignature, keyEncipherment
 nsCertType           = client
 nsComment            = "Node-1 Certificate"
-subjectAltName       = DNS:node-1, IP:127.0.0.1
+subjectAltName       = DNS:khw-node-1, IP:127.0.0.1
 subjectKeyIdentifier = hash
 
 [node-1_distinguished_name]
-CN = system:node:node-1
+CN = system:node:khw-node-1
 O  = system:nodes
 C  = US
 ST = Washington
@@ -187,7 +187,7 @@ DNS.1 = kubernetes.default
 DNS.2 = kubernetes.default.svc
 DNS.3 = kubernetes.default.svc.cluster
 DNS.4 = kubernetes.svc.cluster.local
-DNS.5 = server.kubernetes.local
+DNS.5 = khw-server.kubernetes.local
 DNS.6 = api-server.kubernetes.local
 
 [kube-api-server_distinguished_name]

encryption-config.yamlファイルが存在しない

secretsをetcdに保存するときにrest側で暗号化して保存するための設定としてEncryptionConfigurationがある。 チュートリアル中ではこの設定を有効にするためにリポジトリ中のencryption-config.yamlファイルを参照しているが、実際にはこのファイルは存在しない。 これについては既にIssueとして報告されている。
Issueに記載の通りの設定をコピーして利用したところ問題なく動作した。

github.com

EncryptionConfigrationについては知らなかったので以下を参考にした。

kubernetes.io

sotoiwa.hatenablog.com

全体を通して

Kubernetes The Hard Wayはもっと何十時間も掛かる壮大な内容かと思っていたのでちょっと肩透かしをくらった感じ。 正直これならもっと早く取り組んでおけばよかったとも思った。これが最近のKubernetesの進化により構築が簡単になったおかげなのかはよくわからない。

また前述の通り、基本的にはkubernetes関連ではトラブルは発生せず、その下回りのLinux関連でのみトラブルが発生した。 内部で動作させるコンポーネント(kubeletやkube-apiserverなど)についてはイメージが具体化できたが、Kubernetesの理解が深まったかは怪しく感じたのでもう少しいろいろ取り組んでいる。 こういった検証を気軽に行える環境を得たことは1つのメリットだが、もっと手軽にKubernetesのクラスタ検証環境を構築できる手順が欲しいところ。 RancherKubespray? (Kubernetes The Easy Wayもあった)。 このあたりも試してみたい。

SRE NEXT 2024(オンライン)に参加しました

2024-08-03(土) - 2024-08-04(日)で開催されたSRE NEXT 2024にオンライン参加した。

気になったセッション

試聴したセッションのうち、特に気になった/記憶に残ったセッションは以下の通り

資料まとめは 以下にある。発表アーカイブも後日配信されるとのこと。

zenn.dev

組織的なインシデント対応を目指して〜成熟度評価と改善のステップ〜

インシデント対応に組織的な取り組みを実現する上で、成熟度モデルを作成したという取り組み。 インシデント対応の組織的な取り組み方を改善したいと思っても、具体的にどこから着手すればよいのか難しく感じていたのでこのような成熟度モデルを利用することで組織での対話を促し改善の足掛りにするのは非常に有効な取り組みに思えた。

speakerdeck.com

miro.com

Central SREとEmbedded SREのハイブリッド体制で目指す最高のSRE組織

1つの会社でCentral SREとEmbedded SREという複数SREタイプを構成する場合の取り組み。 マルチプロダクトで各チームの裁量を大きくする上ではEmbedded SREの役割の比重が大きくなるという分担のバランスには納得。とはいえ、各チームに2-4名のSREが配置されているというはだいぶすごい気がする。 Central SREとEmbedded SREの役割分担についてベースラインを設定したいか、という判断軸を持つのも納得。一方で、知見や利用ツールが共有できないという課題もまあそうだよなという印象。

コミュニケーション活性化は現在強化中で今後も改善していく様子なので、具体的にどのように改善していくのか気になる。 また、ベースラインを設定するためにCentral SREが集中管理しつつ、特定チームではよりカスタマイズしたい場合にどのように対応していくのかはよく発生しそうなケースとして考えられるので気になる。

speakerdeck.com

SLO を満たせなくなったら

障害によりSLIがSLOを割り込んだとき、特にポストモーテムなどでリスク分析する方法の発表。 障害検知時間や障害復旧時間などのインシデントの要因に着目して改善する、ポストモーテム時に人を責めず心理的安全性を担保する、といった取り組みや、 リスクごとの年間停止時間を見積りリスク分析するという方法を提示している。

特に年間停止時間の見積りから想定リスクについてコミュニケーションを取り、インシデント対応時に利用するplaybookを作り込んでいくというアプローチはよさそう。 なかなか再利用性の高いplaybookを作成することに課題を感じているものの、想定されるリスクについて関係者間で認識を共有するためのステップとしては有効に思える。

プロダクト全体で取り組むSREing:イシューから始める信頼性/生産性向上の実践

SRE活動に取り組む上で、闇雲にプラクティスを導入するのではなく、イシューからはじめて解くべき課題を見極めようという話。 信頼性の階層をベースとしたアプローチや、VSMによる可視化と問題の特定、事業特性を踏まえた優先度付けなど、具体的なアプローチが参考になる。

自分もSRE導入で上手くできなかった経験があるので、このように解くべき課題を見極めることは重要だと実感するし、今後再導入するときの大きな助けになりそう。

speakerdeck.com

敵対的SRE: 300個のジョブをAIチーム全員で支える技術

SREと開発メンバが良いフィードバックループを作成することで、多様かつ大量のジョブの監視を実現する取り組み。 SREが監視を作成し、メンバが運用する中でよいフィードバックを互いに与えながら信頼性を実現している。

このような取り組みは、Embedded SREとしてチームの垣根が無く質の高いフィードバックを与えやすいチーム構成だからこそ実現可能に思えた。 チーム外のEnabling SREが監視項目を作成するとどうしても作成のフィードバックループが遅くなるし質の高いフィードバックを得ることが難しくなりそう。

speakerdeck.com

その他

オフライン参加について

人が多い場所が苦手なこととオフライン参加の手軽さから、オフライン参加を選択した。 実際、会場への移動や会場内での移動が省略できて、快適にオンライン試聴できたことはよかった。このあたりはオンライン参加の手段を提供してくれた運営に感謝しかない。

とはいえ、現地で他の参加者や発表者とのコミュニケーションが取れないことは明確なデメリット。 このあたりもっとSREの経験を積み、自身の考えを蓄積して意見をぶつけたい、または発表したいという考えが強くなったらオフライン参加にするだろうか。

次回のSRE NEXT2025のテーマが「Talk NEXT」ということでイベントでも会話を促す仕組みがあればオフライン参加するのも面白そう。

SREタイプ

オフラインでやっていたアンケートボードにあるSREタイプや発表内容から、SREタイプとしてEmbedded/Enabling/Platform とう分類は一般的になっていることが読み取れた。 特にEmbedded SREについては少数派でEnabling/Platformが大多数だと思い込んでいた。これはどこかでEmbedded SREの要員確保と各開発チームへの配置が困難なのでEnablingチームやPlatformチームとして配置する、という話をどこかで聞いた記憶があったから。

この認識は古くなっており、SREの認知も拡大している中でEmbedded SREというキャリアも一般的になってきたのかと感じた。あるいはSRE NEXTという母集団が偏っている可能性もあるが。 どちらにせよ、SREの中でもEmbedded SREという取り組み方に魅力を感じていたので、こういった取り組み方が普遍化していくことはナレッジの共有や自身のキャリア形成においても大きな選択肢になりうるので嬉しく思う。

書評: 入門 監視

過去に一度目は通していたけど精読していなかったし、今後改めて監視強化したいと考えたので読み直した。

気になったところ

「監視の原則」の重要性

監視の原則や基礎を伝える上ではよい本だと改めて感じた。 特に第1部の監視の原則については今後も通用する内容であり、今後も記憶に留めておいた方がよいと感じた。

「デザインパターン2: ユーザ視点での監視」は自分の中では理解できていても、社内への周知が十分でないと感じるケースが多々ある。 「3章 アラート、オンコール、インシデント管理」は自分も実践できていない項目が多々あり、特にオンコール対応やインシデント管理の取り組みは改善の余地がたくさんある。

先日 Incident Response Meetup vol.1 に参加したとき、PagerDutyのインシデントレスポンス対応ドキュメントへのリンクがインシデント管理の章に掲載されていることを再認識した。

response.pagerduty.com

クラウドベースのサービス監視への取り組み

第2部の監視戦略について、監視対象に関する説明や取り上げている内容はオンプレミス環境を想定しているのか若干内容が古くなっている。 原則自体は変わっていないが、パブリッククラウドベースだったりコンテナベースのサービスを想定するとすぐに活用できる内容ではなくなってきている。

特に「8章 サーバ監視」や「9章 ネットワーク監視」は知っておくとパブリッククラウドにおける監視にも活用できるが、直接取り扱う情報ではなくなってきている。 「10章 セキュリティ監視」もパブリッククラウドにおいてはこれ以外にも重要な監視項目はたくさんある。

この書籍の内容は参考にしつつも、パブリッククラウド上において実践する上ではどのように取り組むべきか再考する必要がある。

情報の解像度が低い

そもそもが原則を伝える本であり、タイトルの通り監視の入門(原題ではPractical Monitoring)である。このため、この書籍だけでは具体的に監視に取り組むには情報が不足する。

「3章 アラート、オンコール、インシデント管理」よいアラートの仕組みを作るための6つの方法や、オンコール対応やインシデント管理の取り組み方が挙げられているが、実践しようとすると考えるべきことがたくさんある。付録Aには手順書の例が記載されているが、これが何かしらの問題解決に繋がるようには見えない。 「7章 アプリケーション監視」はパブリッククラウドベースのサービスにおいても重要な内容ではあるが、この章は20ページ程度と情報は足りていない。 また、この書籍では取り上げられていない、オブザーバビリティやSLI/SLOといったSREに関するプラクティスも非常に重要になってきている。

各章や節の内容が1冊の本になる程度には深いトピックを扱っているので、この書籍を起点に監視の取り組みを具体化していく必要がある。

第1回 AWSコスト削減 天下一武道会 に参加しました

コスト削減は永遠のテーマだし、これから注力しないといけないトピックでもあるので改めて情報収集のために参加した。

100社のコスト診断から見えてきた、コスト削減の王道とケモノ道

コスト削減をサービスとして提供しているdelta社の取り組み。

みんなでやることが重要であり、CTO/経営陣がタスクとして認識すること、モブコスト分析などでお祭りムードで取り組む、というのはなるほどと。 AWSコストに明るくない人にコスト感覚を養ってもらうのは非常に難しく感じており、モブコスト分析は面白い取り組みに思える。実際に取り組んでみたい。

また、取り組むなら根本的に安くするというのも非常に納得。サービスがスケールしたときにコスト増加の傾きを抑えるとか、ドメインと繋げて考えるとか、このあたりはコスト削減に取り組む上で意識しておきたい。

speakerdeck.com

節約は技術!削減は芸術!何より必要なものは覚悟!

スニダンのサービスを開発・運営するSODA社の取り組み。 NAT GatewayやCloudWatch Logs、CloudFrontなどで実践した事例。

speakerdeck.com

どこかで聞いたことのある話だな、と思ったらStartup Dayでも発表したのを聞いていたのだった。

zenn.dev

パネルディスカッション

コスト削減に取り組むタイミングとして、違和感を感じたらとか、具体的に100万円程度のコスト削減余地が生じたら、みたいな話があった。 これは身に覚えがあり、自分たちも定期的に請求詳細を確認して金額の増減に違和感があったらとか、獲得MRRに比べて削減余地が比較的大きくなってきたら、みたいな感覚がある。 また、他社事例を通してコスト削減の勘所を養うというのもまさに経験したことがあり(自分たちはAWS Configについてだった)、やはり他社事例で学ぶのも取り組みを公開するのも重要だと再認識できた。