プラットフォームエンジニア2年目の2021年を振り返ります。2020年にマイクロサービスのプラットフォームの開発・運用に携わり始めてから、丸2年が経過しました。2021年は、本業ではインフラからアプリケーションまで影響範囲の広い大きめのプロジェクトを担当しました。それに加え、複業ではSREに挑戦して修行しました。

2020年

駆け出しプラットフォームエンジニア1年目

2021年

2年目にやったこと

本業では、主につぎのプロジェクトに携わりました。

  • Workload Identity導入・移行
  • CIのセキュリティ強化
  • Cloud SQL IAM database authentication検証
  • GCPとTerraform本配布

Workload Identity導入・移行

クラスタ上のサービスアカウントキーを撲滅すべく、GKEのWorkload Identityを有効化し、クラスタ上の全サービスを移行するプロジェクトです。

Google Cloud Platformで学ぶTerraform 〜実践編〜を書くときに、動作検証やTerraformモジュールのクラスタ側・マイクロサービス側の実装を通じて雰囲気は把握しているつもりでした。しかし、想像よりはるかにいろいろありました。

テストクラスタ上のテンプレートマイクロサービスサービスを使った各ユースケースを検証や社内外で仕様・制約調査しながら、移行計画を含むDesign docを書いて議論スタートです。クラスタ上のほとんどのサービスがGCPにアクセスするため、移行の対象範囲はほぼ全マイクロサービスです。アクセスするにあたってApplication default credentials(ADC)を適切に利用しているかを確認するため、Sourcegraphを利用し、数百マイクロサービス分のKuberetesのマニフェストとアプリケーションの実装内容の調査を進めました。その中で、サービスアカウントキーをADC外で活用して署名しているユースケースがいくつか見つかったため、ライブラリを管理しているチームに更新を依頼したり、アプリケーションの実装の変更手順をドキュメント化したりして移行に備えました。

導入を開始するにあたっては、各組織のエンジニア向けの全体集会で背景などをプレゼンしたり、ドキュメントを整備したりしました。初期段階で移行してくれる参加チームを募り、ベータリリースステータスでフィードバックを集め、Terraformの実装、ドキュメントなどに反映します。GAさせた後は、移行に必要な作業の重さでグループ分けをして期限を定め、移行サポート専用のSlackチャンネルでサポートしながら進めていきました。

今回の導入・移行は、一括で一様に設定変更のPRを大量に作成して完結するものでなく、ほとんどのチームの多大な協力を必要としました。すでに社内で構築された仕組みで効率よく調査できた部分や、現在進行系で整備されてるしくみで今後より低コストで移行できるようになっていきそうな部分もあります。今後もプラットフォーム全体に影響ある機能の導入やそのための移行をすることはあるので、移行しやすさや技術選定が可逆的か不可逆的かなどを意識してやっていこうと思います。

CIのセキュリティ強化

これも移行を伴うものです。従来のものを検討漏れなく段階的に廃止していく難しさや、(やりづらくても)問題発生時の切り戻しをいかに実現性高く準備すべきか、できる限りの移行自動化などに学びがありました。

Cloud SQL IAM authentication検証

Cloud SQL IAM データベース認証の検証と導入手順のドキュメント準備を行いました。比較的新しい機能において、どのスコープで導入すべきか、導入と見送りに線を引く基準はなにか、見送るにしてもどういう条件が揃えば導入したいか、そのロードマップ(揃わなかった条件はいつか満たされるのか)の情報をどう得るかというところに学びがありました。

GCPとTerraform本配布

開発者がマイクロサービスを開発するにあたり、多くの必要なリソースはTerraformモジュールで作成されます。しかし、各チーム固有のリソースは書いてもらわないといけないため、それを少しでも楽にしてもらうべく2020年に2冊の本を書きました。

私がマイクロサービス開発をし始めたとき、Terraformのplanの見方や書き方がよくわからなかったり、Terraformの本はたいていAWSベースで書かれていたりで、GCPもそれほど詳しくない中キャッチアップしづらいという問題意識がありました。それを踏まえて書いたので、社内のオンボーディング資料にすべく配布しました。効果はある程度測定したかったのでGoogleフォームで申し込みをしてもらったところ、述べ130人弱のメンバーに受け取ってもらえました。

チームメンバーから「なんとなく触ってた会社のTerraform moduleがちゃんとわかるようになった。CIが出してくれる反映差分もできるようになった」というおすすめを頂いて、読んでみたいと思いました。

というメッセージ付きで申し込んでくださった方もいて、書いてよかった、配ってよかったなぁと思います。業務経験は最大限活かしつつも、外に出せる程度に簡略化・抽象化して書いたので、今後も活用していきます。

複業

2021年は「旗を立てる」をキーワードに複業に取り組みました。

旗を立てる2021年

エンジニアとしてのキャリアの中では、開発基盤やインフラに携わった期間は相対的に短めです。闘い抜く技術力を高めるためにも、本業以外でもそれらの業務に携わりたいと考えるようになりました。技術発信やその他の研鑽ではなく、業務という形式にこだわったのは、座学に偏りがちな私自身の性格を踏まえてのことです。

具体的には、2組織でつぎの業務に携わりました。

  • kustomizeの導入
  • kubernetes-external-secretsの導入
  • インフラの防災訓練
  • マイクロサービス化検討サポート
  • gRPCのprotoと生成コード管理基盤整備
  • マイクロサービスとインフラ課題整理とOKR決め
  • オブザーバビリティ整備
  • セキュリティ脆弱性対応

詳細はOffersMagazineに寄稿する形でまとめています。

複業SREとして広げる課題解決の幅と深さ。期待値以上の成果を上げるまでに何をしたか

業務時間の大半を過ごす組織への貢献最大化を主眼に置きつつも、組織に依存しない形で自分が何者かを定義し、目指す方向に歩みを進めていくことのよさを感じた1年でした。

キャッチアップとアウトプット

業務とは別に、プライベートOKRで四半期毎に身につけたいことを決めて取り組みました。キャッチアップすべきことは無限にあるので、「この四半期はこれ以外はやらない」をはっきりさせる意味合いが強いです。

OKRは、各記事でなぜそれが達成したいのかや、どの程度達成したのかなどの振り返りと合わせてまとめています。

2021年は、大学院でコンピューターサイエンスを学ぶための出願準備が多めでした。noteで振り返ったり、計画を立てたりしながら進めています。

出願の動機(本音)は、「もしいま働かなくてもいいとしたら、コンピューターサイエンスをしっかり勉強してみたい」です。しかし、いざ履修したい科目を挙げていくと、現在のプラットフォームエンジニアリングに深く関わる分散システムの理論と実装、クラウドコンピューティングの実装、OS、コンパイラなど、低レイヤーの理解を一歩深めるものが多かったです。OKRで目標に据えるのはもちろん、プラットフォームエンジニアのキャリア上も重要なものとして位置づけていくことになるでしょう。

資格

2021年は1つだけ取得しました。

GCPのネットワークとセキュリティは、資格も活用して体系的に論点をおさえておきたいと思っています。

執筆

年末にGoの本が技術評論社さんから出版されました。

自分が担当した分については、以前ソフトウェアデザインに寄稿したものを更新したのみです。技術書典でも新刊を出せないのが続いており、少しさびしいです。

技術書

チームの人のおすすめリスト(2021年2020年)を読んだりしながら、自分なりに読書リストを作って進めています。意識的にOKRに関連させるようにもしています。これら以外は読まないというわけでもないですが、読むのが速くないので特に大事なものに絞る必要があります。

Platform Engineerへの闘争🐸

リストの中で読み終わった本。

登壇

Open Policy Agent Rego Knowledge Sharing Meetupで久々に登壇しました。

2022年

2022年は、Ubieという会社にSREとして転職します。インフラまわりの技術スタックで共通していることもあれば、SREとプラットフォームチームの役割分担、組織(事業特性)毎にSREが別、プラットフォームチームが領域毎に別だったなど、メルカリの組織と性質・フェーズが異なるので、より広い役割が求められるでしょう。これまで経験のないことも、素早くキャッチアップして貢献していこうと思います。

四半期ごとの個人OKR振り返りです。

2021年10〜12月は、プラットフォームインフラ未学習分野の底上げとベストプラクティスの実装修行に取り組むという内容でした。

振り返り対象のOKRは2021年7〜9月ふりかえりと10〜12月OKR 〜ネットワークとマイクロサービス化〜で立てています。

OKRの振り返り

Objective 1: プラットフォームインフラ未学習分野の底上げとベストプラクティスの実装修行

Key Result 1 【できた】

Kubernetesのセキュリティまわりの業務比率高めなので概観する。

合格しました。

最初に受けた試験では試験官へのデスクトップシェアが機能せず、指示のままにブラウザの再設定やPCの再起動をしたら試験環境にアクセスできなくなりました。別日程で再予約するなど、時間消費が厳しかったです。

試験の準備は、UdemyのKubernetes CKS 2021 Complete Course - Theory - Practice
を見てから、KodeCloudのCKSコースで練習しました。

aquasecurity/trivyをたくさん実行した結果、実行しないといけなくなってしまったタイミングでシュッと実行できてよかったです。

Key Result 2 【できなかった】

ネットワーク関連の話題が頭に残るようになってきたので、GCP上でのネットワーク関連実務とアプリケーションレイヤーでの見え方を意識しつつ概観する。

基礎からわかるTCP/IPネットワークコンピューティング入門を読むだけで終わりました。Google Cloud Certified Professional Cloud Network Engineer Guideの発売日が2022年に延期になったのもありますが、KR3関連で空前絶後のチャンスが訪れたため、そちらに振り切ることにしました。

大学院の授業でネットワーク関連のものを履修する予定があるので、関連付けられるものはそのタイミングでやろうと思います。

Key Result 3 【微妙】

組織としての知見はあるが、自身の経験が薄い部分のチャンスをものにする。

OKRを立てた時点では、複業でマイクロサービス化支援に携われるかどうかわからない状態でした。しかし、想像以上に広いスコープでプロジェクトを任せていただいたので、モノリスからマイクロサービスへも読みつつ、マイクロサービス基盤立ち上げに全集中しました。その結果、技術書典12にサークル申し込みしたものの進捗ゼロです(KR3の自己評価を【微妙】にした理由)。

SHEさんでの複業SREの取り組みは、SHEさんの業務に携わるきっかけとなったOffersさんのOffersMagagineに寄稿する形でまとめています。

年初に立てた今年1年の目標の振り返りそのものにもなっています。
https://toshi0607.com/general/start-parallel-works-in-2021/

四半期のプライベートOKRエンジニアとして目指す方向性と別に1年単位のテーマを持つことで、期待を遥かに上回るよい機会や出会いに恵まれました。2022年からは大学院の授業もはじまり、またこれまでとは異なるあり方で臨んでいかざるを得なさそうです。その中でも、業務、エンジニアとして目指す方向性、純粋な興味の交点を見つけて爆進できたらなと思っています。

Objective 2: 持続可能な感じの人生にする

Key Result 1 【できた】

旅をする(やってみたいことリストより)

  • ミラコスタ泊まる
  • 石川でのどぐろ食べる
  • ume, yamazoe泊まる

すべて達成できました。特に、ミラコスタに宿泊するのは長年の夢だったので感慨深いです。

お金だけではどうにもならない夢もある一方で、お金(と時間)だけでなんとかなるものは積極的に計画に組み込んでいこうと改めて思いました。

以前作ったワクワクリスト(いつかやってみたいワクワクすることリスト)がなぜかどこかに行ってしまったので改めて作ろうと思います。

Key Result 2 【できた】

ジョギングか散歩の再開

8〜9月頃にバーンアウトっぽい状態になってしまい、けっこう厳しい状態でした。それを踏まえ、産業医面談を受けたりしながら取り組んだもののひとつです。木曜日・日曜日の筋トレは腹筋を割るための取り組み以来ずっと継続しているので、有酸素運動ができて朝日も浴びられるジョギングに火曜日・土曜日の朝に取り組んでいます。

Key Result 3 【微妙】

お楽しみコンテンツ

  • ゼルダの伝説 時のオカリナ
  • ゼルダ無双エキスパンション・パス第二弾
  • 葬送のフリーレン (6)
  • ✅ キングダム(prime video)
  • ✅ 勇者指令ダグオン
  • ✅ 勇者指令ダグオン 水晶の瞳の少年
  • [WIP] 絶対無敵ライジンオー
  • ✅ カードキャプターさくら さくらカード編

アニメはご飯を食べながらでも進んでいきますが、ゲームやマンガはそうはいきません。能動的に楽しむコンテンツに時間を割けない、割く気分にならない、割く気力が起きないのは、他の条件がそろうと燃え尽き状態になるというのは学んだはずです。一方で、サウナや下で書くOKR関連のMeetyのように、カレンダーで枠をおさえた楽しみの時間は相当あったのでよしとしましょう。Objective 1を大事にするのと同じように、Objective 2の枠や「何もしない」枠を明示的におさえるのを来年はより意識できるとよさそうです。

ログ

今QのOKRとしては追ってないものの、記録しておきたいことのコーナーです。

大学院

3〜7月頃にかけてとりくんだ大学院受験の結果が出ました。

「来春」が本当に文字とおり4月頃だと勘違いしていましたが、12月にはオリエンテーションと手続きを済ませ、1月には授業が始まるというスケジュールだったので、OKR観点ではノーマークで大打撃でした。

中学受験にはじまり大学受験、国家公務員試験、新卒就活など、重要な節目で選択したいものの第一候補には力及ばずすべて祈られる人生を歩んできました。結果的に選択した場所でその機会を最大限活かせるよう努力してきたものの、どういう形であれ筆頭候補に無事たどりつけたのは感慨深いです。

受験のまとめや、履修計画はnoteでまとめています。

転職

Ubieでやっていきます!記事は入社後に別途。

OKRを決めた時点では選考中だったので、選考後の過ごし方は考慮しているような、していないようなどっちつかずの状態でした。今回のOKRでは、進学、転職、複業がOKRにおよぼす影響があまりに大きかったので、途中でガッツリ見直せるとよかったのかもしれません。

Meety

前QにはじめたMeetyはトピックのバラエティを広げ、時間を見つけていろいろな方とお話しています。

トピック毎の累計マッチはつぎのとおりです。

個人OKRのトピックについては、Meety後もDMやGoogle docでフィードバックしたり、Google Meetで振り返りの壁打ち相手になったり、もはや趣味です。キャリア壁打ちでは、大学院受験相談が増えています。今後いっそうUbie文脈でお話する機会が増えていくと思いますが、どれもいい感じに続けていけたらと思います。

アニメ・映画

勇者シリーズは昨年2月にリモートが始まった頃に見始めついにすべて見終わり、グリッドマンはオリジナルの原点世代なのでエモすぎて卒倒しました。変形・合体ロボットは昔から変わらず好きです。映画はアイの歌声を聴かせてが特に響きました。とりあえず武功を挙げて中華統一していく予定です。

ソフトウェアデザイン(技術評論社)での連載をもとに、章も増え大幅にパワーアップした本が順次発売されています!最近はメモ程度のものでも技術記事を書いてないので寂しさを感じています。

OKR関連以外で読んだもの

個人OKRサポートのMeetyがコーチングっぽいなと思ったので、読んでみました。普段の業務でマネージャーとの1on1で感じる「これはコーチングの文脈でそうすることがよさそうなので、そういう風に問いかけてくれてるんだろうな」みたいなものもいろいろ書いてありました。tips的なものをそのまま適用しようとは思いませんが、伴走者としてのスタンスなど参考にできるものは取り入れていこうと思います。

新卒営業のときのパワポ作りが苦手過ぎて地獄だったり、視覚的に伝えたいことを表現したり整理したりするのがうまくできません。なにかヒントになることはないかと読んでみました。モノをシンプルに表現するのと、概念を具体化するのとでは差異がありそう(自分の中では区別できてもなかった)なものの、線の引き方にはじまり、点の配置で表現できるバリエーションや、モノとモノの関係の表現など、自分が難しく感じる視覚的表現が小さな構成要素の積み重ねとして鮮やかに説明されていたのが印象的でした。

上記以外では、Audibleを再開しました。1度だけ3ヶ月休会できる制度があったので、それを利用して筋トレ中はPodcastで英語リスニングに全振りしていました。またいろいろな本を聞いてみようと思います。

DIE WITH ZEROにしても、FIREにしても、資産形成どこまでやったら「撤退」して大丈夫なのか決める本として捉えました。インデックス投資なりなんなりで資産を積み上げていくことに躍起になることもあるとして、生涯それは必要なのか?もしフルタイム労働が好きでなく無理に取り組んでいる場合、どこまでがんばればいいのか?それを考えるために、どの程度貯まれば労働を減らすなり、完全に資産運用に委ねるなりできるのかを仮定を置きながら具体的に計算するという考えは持ち合わせていませんでした。FIREは、もっと極端に一発当てて完全仕事放棄みたいな話かと思っていましたが、意外と堅実な話でした。

宗教の考えに触れつつ、心の平安にプラスなマインドセットなり行動習慣なりを持つという類書との顕著な差異は見いだせませんでした。

英語

前Qから継続しています。大学院の授業の効率を考えると、今後もリスニング重視で鍛えていきたいです。

  • ELSA Speak: 発音矯正自体よりも、正しい発音を知り耳をよくする
  • Mikan: TOEFL 3800英単語を朝・夜に100単語ずつ復習継続
  • Podcast: Scientific AmericanのシャドーイングとNHK Worldを寝る前に聴く

サウナ

Meetyのトピックにもあるように、足立区に引っ越したのは上野、草加、錦糸町、入谷、三ノ輪、両国すべての名サウナに30分以内でアクセスできるからです。今四半期は、有給消化も活用して積極的に普段と異なるサウナに足を運びました。

  • 草加健康センター
  • サウナセンター
  • 舞浜ユーラシア
  • サウナ・アダムアンドイブ
  • ホテルゆ華
  • 金春湯
  • SaunaLab Nagoya
  • ume, yamazoe
  • THE SPA 西新井
  • サウナ&カプセルホテル 北欧

今年も一年間毎週(だいたい)月曜日の夜はサウナで過ごしました。大学院の志望理由書の内容の大半をひねり出したのもサウナです。スマホもパソコンも思考の中断もない時間を大事に、来年もまた歩んでいこうと思います。

今後の話

転職と大学院の授業の最初の授業が重なる2022年1〜3月は、生きるだけで精一杯かもしれません。そのため、Objective 1は端的に言うと「生きる」です。

Objective 1

本業における事業価値の最大化を中心に据え、学業、複業がよいバランスで継続的によい影響を与え合うあり方を見つける。KRでは、本業と複業の業務OKRや大学院の成績基準を満たすのに必要な補助的内容を便宜的におく。

KR1 データベース理解の見取り図をつくる

Cloud Spannerで戦っていける体になりたいです。マイクロサービスの開発・運用で利用していたものの、そもそもデータベース概論から弱いので、足腰鍛えます。

KR2 マイクロサービスのオブザーバビリティの見取り図をつくる

マイクロサービス基盤開発において、2022年1〜3月はマイクロサービスの死活監視の概要がわかるダッシュボードと、開発・運用のためのログ、トレーシング、(メトリクス、)エラーレポートが関連付けられている状態にします。その前提として、オブザーバビリティ関連の代表的論点を整理し、ロードマップをつくり、今回の取り組みの位置づけやつぎに取り組むべき内容を提示できる状態にします。(複業自体のOKRを優先し、無理そうならそちらに集中する)

KR3 大学院授業の週・月次の学習サイクルをつくり、主要な授業に備える

  • CS 6310の履修登録に成功する
  • OSまわりの授業の前提条件を調べ、不足を補う計画を立てる
  • 春・夏学期の履修登録に成功する

1/6から履修登録、1/10から最初の授業がはじまります。

Georgia Tech OMSCSの入学準備と履修計画

最初はCS 6310: Software Architecture and Designを履修予定です。春学期は5/7まで続くため、この四半期では1学期まるっと経験することはできません。一方で、3月末に夏・秋学期の履修登録期間がはじまるため、済ませておきたい下調べや早い者勝ちの部分はきっちりおさえたいです。

Objective 2

壊れない。目下最大の健康リスクに対処しつつ、よい人生を歩んでいきます。

KR1: ワクワクリスト

以前作成したものがなぜかなくなったので、再度まとめて目に見えるところにおいておきます。今QのO2 KR1のミラコスタと石川ののどぐろは、このワクワクリストからOKRに引っ張ってきたものです。達成することで生の実感を得ることができました。いつかやってみたいと思ったことでも忙殺されると自分の人生の外においてしまうし、それをやるタイミングが勝手にやって来るものでもありません。流れに委ねるべきは委ねつつも、可視化し、意識して組み込むのも継続してやっていこうと思います。

KR2: お金周りを整理する

  • iDeCo手続きする
  • NISA手続きする
  • 使ってないクレカ解約
  • 確定申告

持株会制度がなくなるのと、新卒の会社の企業年金をiDeCoに移さずここまできてしまった(!)ので手続きします。個別株積立投資と投信は続けているものの、NISAはノータッチなので、もしiDeCoと合わせていい感じに手続きできたらやってしまいます。また、いろいろなサービスの料金プランの見直しや解約を進めているのでその続きをします。

KR3: 目か頭痛どうにかする

  • 相談先探す
  • 目のメンテする

現在一日の生産性を圧倒的に下げる三大要因が花粉症、頭痛、眼精疲労(?)です。花粉症については、今Qに舌下免疫療法(アレルゲン免疫療法のひとつ)に取り組みはじめました。3〜5年かかりそうなので、病院とオンライン診療を併用しつつ様子を見ていきます。頭痛については、気圧が上がるときも下がるときも年々厳しくなっているので、緩和させるもしくは快方に向かわせる一手を打ちたいです。乱視や近視と左右の大きな視力差に起因する目周辺の不快感や頭痛もけっこうしんどいです。

頭痛と眼精疲労は相互に影響している部分もそうでない部分もありそうなので、どこにどういう形で相談すると全体として前進するか調べ、日常生活への影響を考慮し着手できる緩和策に着手します。

四半期ごとの個人OKR振り返りです。

2021年7〜9月は、ジョージア工科大学大学院のコンピューターサイエンスコースの出願期限が伸びたのを受け、後悔ない状態で出願するのが目標でした。

振り返り対象の個人OKRはこの記事2021年4〜6月ふりかえりと7〜9月OKR 〜大学院出願2と夏休み〜で立てています。

OKRの振り返り

Objective Georgia Tech OMSCSに出願する

Key Result 1 【できた】

Build a Modern Computer from First Principles: Nand to Tetrisの修了

それぞれ無事終了しました。

Part 1では論理ゲートにはじまり、加算器、ALU、RAM、CPUを作り、Part 2ではJavaをめちゃくちゃ簡略化した言語Jackを題材に、それをVMコードに変換するcompiler、VMコードをアセンブリ言語に変換するVM translator、JackでOS機能をいじるライブラリを書くという内容を扱っていました。Jackでミニゲームを開発するのも含まれていて、入門にはうってつけでした。

この本の翻訳元がテキスト(授業も作者同じ)なのでご存じの方も多いかもしれません。

コンピュータシステムの理論と実装 ―モダンなコンピュータの作り方

積んでいるこっちもやろうと思います。

Go言語でつくるインタプリタ

Key Result 2 【できた】

出願書類を仕上げる

締切の8/10よりも少し早めの7/24に出願を終えました。

合否結果はメールで10/15までに順次届くそうです。ただ、当初8/31までに開始される予定だったのが9/22に延期(実際にはじまったのは9/16)されたり、Redditを眺める限りけっこうな割合が待ってそうです。受かったらめでたいし、だめならCSのオンライン授業を積みまして3月に再挑戦するだけなので、気にしすぎず気長に待つことにします。

ログ

OKRとしては追ってないものの、記録しておきたいことのコーナーです。

ゲーム

ゼルダのスカイウォードソードを終えました。ブレスオブザワイルドからゼルダをはじめた勢としてどんな感じになるかなぁ…と思っていましたが、ゼルダシリーズの系譜の原点としてクリアしたら寂しくなる程度に楽しかったです。マスターソードとの出会い特によかった。

新刊発売が楽しみな本が増えて本当によかったです。

何書いてるかさっぱりわかりませんでした。

Twitter的なフィードやWebクローラー、チャットなどの典型的なシステムを要件に合わせいかにスケールするように設計するべきかを学べる本。典型チューニンポイントや代表的アルゴリズム、事例文献へリンクも豊富でかなり面白かったです。具体的なクラウド、言語、ライブラリなどでどう実現できるかを考えるとなお面白いです。

Linuxの基礎があるか?と言われてLinuxの基礎がなにかわからなかったので読んで見ました。自分の「シェルスクリプトが書けない」は個々のコマンドもそうですが、Linuxの基礎を学んだことがないというのも多く含んでいることがわかったのでよかったです。

「ネットワーク系をがっつり見ているわけではないが、インフラを見る上でネットワークは不可避。しかし、目の前の小さなタスク単体ではなかなか知識・経験が積み重なっていく感じがしない」という問題意識があり入門することにしました。体系的、分量少なめ、図多めはなかなかなじめない分野にうってつけでした。

LinuxのNetwork NamespaceをつかってTCP/IPを学ぶというコンセプトでめちゃくちゃよかったです。OSI参照モデルやTCP/IPの図で各層の役割を説明されるだけでははかなか頭に残りませんでしたが、ip、tcpdump、iptables、ping、dig、ncなどを叩きながら説明されるとだいぶ実感がわきました。

Audibleでどこまで洋技術書頭に残るか試しています。

みんなやっとるな!

初版との差分のみ読みました。

アニメ

リモートワークになってから幼稚園ぶりにみはじめた勇者シリーズも、残すところ勇者指令ダグオンのみになりました。中でも一番好きだったマイトガインは、変形・合体ロボット好きの原点なので心揺さぶられるものがあります。中古DVDも高騰している作品しか残っていなかったり、prime videoにない作品が見たかったりでバンダイチャンネルを契約しました。

雑談1on1

楽しかったので継続したいです。

これまで取り組んだ個人OKR一覧とMeetyでの1on1

あまり肩肘はりたくないものの、コーチング系の本を読んだらどうなるか試してみたいです。

新 コーチングが人を活かす

大学院やサウナなど、順次トピックを増やしていこうと思っています。

英語

短期戦モード(TOEFLで大学院出願に必要なスコアを確保する)から長期戦モードになったので、1日にやることを決めて継続しています。

  • ELSA Speak: 発音矯正自体よりも、正しい発音を知り耳をよくする
  • Mikan: TOEFL 3800英単語を朝・夜に100単語ずつ復習継続
  • Podcast: Scientific AmericanのシャドーイングとNHK Worldを寝る前に聴く

アクティビティ

精神的にけっこう参ってしまったので、2回目のワクチンを終えてしばらくから自然に触れるようにしてました。あとマリトッツォけっこう食べました。

今後の話

Objective 1

プラットフォームインフラ未学習分野の底上げとベストプラクティスの実装修行

KR2を重視し、KR3は次四半期も継続する前提。

Key Result 1

Kubernetesのセキュリティまわりの業務比率高めなので概観する。

昨年買ったCKSの受験期限が12月上旬というのが大きいです。

Key Result 2

ネットワーク関連の話題が頭に残るようになってきたので、GCP上でのネットワーク関連実務とアプリケーションレイヤーでの見え方を意識しつつ概観する。

Key Result 3

組織としての知見はあるが、自身の経験が薄い部分のチャンスをものにする。

  • 技術書典12(2022年1月22〜30日)の新刊章立て、検証(Cloud Run + マイクロサービス)

Objective 2

持続可能な感じの人生にする

Key Result 1

旅をする(やってみたいことリストより)

  • ミラコスタ泊まる
  • 石川でのどぐろ食べる
  • ume, yamazoe泊まる

ミラコスタは1つの夢なので、お金払って叶う夢は時期を定めて叶えていきたいです。

石川はふるさと納税の宿の期限を1年伸ばしてもらっているのでそろそろいこうと思います。

ume, yamazoeはクラウドファンディングのチケットの期限切れてる気がするけれど果たして…

Key Result 2

ジョギングか散歩の再開

有酸素運動の習慣がないと厳しそうです。

Key Result 3

お楽しみコンテンツ

ゼルダ35周年ということでマリオの3Dコレクションのように、過去3作品コレクションがSwitchで出ると思っていました。なんとそうではなく、Switchオンラインで64系ソフトも楽しめるようになるとのことで課金していこうと思います。ムジュラの仮面も追加されるとのこと。僕は64買ってもらえなかった勢なので思い入れはないですが、ゼルダファンの時のオカリナとムジュラの仮面への強い思いはひしひしと感じるのでとても楽しみです。

四半期ごとの個人OKR振り返りです。

2021年4〜6月は、ジョージア工科大学大学院のコンピューターサイエンスコースに出願するのが唯一の目標でした。

振り返り対象の個人OKRはこの記事2021年1〜3月ふりかえりと4〜6月OKR 〜大学院出願夏の陣〜で立てています。

OKRの振り返り

Objective Georgia Tech OMSCSに出願する

Key Result 1 【できた】

TOEFL 100点

  • 5月 90点
  • 6月 100点

「できた」に矛盾するようですが、5月に94点をとってから6月にもう一度受けたものの振るわず。そこから再度受験して100点超えを目指すのはいったんなしにしました。

調べるかぎり90点台で受かるのと、KR3(コンピューターサイエンス系のコースを修了する)を当初設定した目標より積みましたほうがよさそうだったので、そちらに時間を割きました。

ただ、出願準備文脈でなんとかなったにしても、英語力自体の向上は働く上でも気持ち的にもいろいろ思うところがあります。TOEFLの試験は長くつらいので二度と受けたくはないですが、やるならやるで100点以上とってからやめたいです。折に触れて個人OKRに盛り込んだり、試験勉強をやめても続けていることがあるので、より細かい話はnoteに書いたりすると思います。

Key Result 2 【できた】

出願書類の準備

  • 4月
    • 履歴書
    • 志望理由書初稿
    • 推薦書依頼
    • 成績・卒業証明書申請
  • 5月
    • 履歴書ブラッシュアップ
    • 志望理由書ブラッシュアップ
  • 6月 資格系入力

出願書類をひととおり準備したり、推薦状を依頼したりしました。

志望理由書と履歴に関する文書(Personal statement、Background essay)は、ひととおり書いてから添削サービスに出しました。Grammarlyなどのツールである程度直してから出してもそこそこ直されるし、変更すべき理由もちゃんと書かれていてよかったです。ただ、事実の伝わり方はそこまで変わらないように感じます。それでも添削サービスを利用したモチベーションは、受験プロセスでとれるオプションをとってみる、きっと将来MBAもとる!とか言い出すと思うのでどこまで期待できるものか見ておくくらいの位置づけでした。Background essayと別に提出するレジュメは、内容を入力すると適当に体裁を整えられるWebサービスを活用しました。

出願に必要なGPAは3(推奨3.2)とそこまで高くないし、日本の大学で+-のない成績だとWESなどの評価機関を経てだいたいは上がると思います。どの程度上がるか試すべくWESのツールを使ってみたら壊れてる(意図的かも)し、問い合わせの返答が究極に鬱陶しかったので、換算はせず大学から取り寄せた成績・卒業証明書をそのまま提出することにしました。

推薦状はこれまでにお世話になった/なっている3人のマネージャーに依頼しました。快く引き受けていただいて感謝しかないです。

書類系の準備過程の詳細は、ひと段落してからnoteに書くと思います。

Key Result 3 【できた】

Data Structures and Algorithms

4つあるうちの3つまで終わらせられたらいいなと思っていましたが、終わらせないとヤバそうだったので全部終わらせました。4/16にGeorgia techから、上記コースとプログラミング系の2コースを終わらせたら学部相当のCSの基本知識があるとみなす旨が明言されたためです。

Georgia TechのOMSCSは、オンキャンパスでのコースと異なり、すべてオンラインで実施されるため他の大学院のコースでは考えられないような高い合格率で寛大に生徒を受け入れています。しかし、それは学部でCSを修めた人に対する話です。IT、システム、数学など関連するような学部でなければ、職業経験やCS授業(大学の授業 > 越えられない壁 > オンラインのコース)の履修状況に鑑み個別に判断されます。そのため、CS学部卒でない人はコミュニティカレッジ(OaktonFoothillなど)やブリッジプログラム(NYUなど)に通った上で単位を取得し、授業を担当してもらった教授に推薦状をもらうのが王道とされてきました(主観)。ただ、地理的・金銭的・時間的に厳しい人も多く、有名なCouerseraのコースでなんとかする迂回策(けっこう不安)で凌ぐのもよくある作戦でした(主観)。この状況に一石を投じたのが前述の発表です。3コースすべて終えたら受かるというものではないものの、終わらせるのに越したことはないでしょう。

プログラミング系のコースは、別大学のコースでPythonとJavaを含むものを3月に受講していたので、Data Structures and Algorithmsを最優先に取り組みました。

そして6月にまだ進められそうだったので、離散数学のコースも終えました。

当初は7/1出願締切の前提で進めていましたが、今年から8/10締切に変更があったのと、Data Structures and Algorithmsも思ったより早く終わったのでさらに受講することにしました。

3コースが明言される前に、CS基礎で受講すべきものとして挙がっていたのはつぎの科目です。

  • Discrete math
  • Linear algebra
  • Calculus
  • Programming (Object-oriented, Java, Python)
  • Data structures & Algorithms
  • Computer Organization

これらのうち、数学系は線形代数と微積は大学で必修だった(かつ良い成績でもなかった)ため、いま足すなら離散数学だろうという判断です。7月いっぱいかける予定がこれも6月中に終わったので、出願までに残りのComputer Organization関連のコースを受講しようと思います。

そういうわけで、例年通りなら出願し終わっているはずが、出願締切が変わったので8/10までは引き続き受験生です。

最近は落ち着いてきましたが、TOEFLの勉強中やData Structures and Algorithmsを受けきるまでは、それなりのプレッシャーがあり体力的にも精神的にかなりもきびしかったです。しかし、喉元を過ぎてしまったのでだいたいしんどさは忘れました。

現在の準備状況で出願しても悔いはない程度に準備はしたので、残り期間は授業を楽しみつつ進められたらなと思います。

今後の話

残りのCS授業を進めて出願を完了し、あとは夏休みします。

Objective Georgia Tech OMSCSに出願する

Key Result 1

Build a Modern Computer from First Principles: Nand to Tetrisの修了

Computer Organization系の位置づけにぴったりな、論理ゲートにはじまりひととおり機能するコンピューターを作ろうというコースです。出願までにPart1 (ハードウェア編)を終わらせ、仮想マシン、コンパイラー、OSなどの入門としてそのままPart2 (ソフトウェア編)を受講しようと思います。

https://www.coursera.org/lecture/build-a-computer/unit-0-2-from-nand-to-hack-Y1MVe

Key Result 2

出願書類を仕上げる

書類自体は直したい部分はないものの、入力したもののうち各資格や勤務先の説明など、少し丁寧にしておきたいところがあります。それらを書き直して提出!

合格発表は8月中旬から9月下旬にかけて審査が終わった順です。

その他

出願後はKR1の続きをしつつ、ちょっと休もうかなと思います。CKS、英語、複業に戻る、喉の治療、ピアノなど集中して取り組みたいことはあるものの、仕込みにとどめます。ゼルダのスカイウォードソードも楽しみです。

出願が終わる頃には2回目のワクチン+2週間も終えることになるので、ちょっとした旅行もいいかもしれません。

四半期ごとの個人OKR振り返りです。

2021年1〜3月は、旗を立てるべく複業を開始するというのが主な目標でした。

振り返り対象の個人OKRはこの記事2020年10〜12月ふりかえりと1〜3月OKR 〜旗を立て始める〜で立てています。

OKRの振り返り

3段階で見ていきます。

  • できた
  • 微妙
  • できなかった

Objective 1

旗を立てるための学習を継続し、実績を積み始める

Key Result 1 【できた】

「旗を立てる」宣言をする

  • 旗を立てるの趣旨ややることをまとめた記事を書く
  • TODOを作る

旗を立てる2021年

Key Result 2 【できた】

複業の開始

  • 企業にアプローチする
  • GCP・コンテナ関連の仕事を月30時間くらいからやっていく

2社でインフラ、SRE、バックグランドあたりを見るお仕事をいただきました。ただ、諸事情により計画が大幅に変わりしばらくお休みさせていただくことになりました。よいタイミングで戻れたらと思っています。

本業では異なる形で解決したものをその組織に合う形でどう提案・解決するのか。また、その知見をどう本業に活かすのか。短い期間ながら、どうやって自分が提供できる価値を最大化できるかに関する期待どおりのインプットが得られました。

Key Result 3 【できた】

コンテナの基礎を学ぶ

  • 『Container Security』を読む

Key Result 4 【できた】

留学先と基本要件リストアップする

これは1月当初は設定していませんでした。しかし、2月頃に気づいたら受験生になっていました。いろんな観点で「理由付け」はできるはずですが、本質は闘争という趣味です。理由をつけてやらないといけないものは、理由をつけてやらないこともできるので、その枠外で本気になれそうなものは人生において特に大事にしたいです。

7月1日出願を目指すものの、受かるまで受けるので1年くらい準備するかもしれません。趣味の話はnoteに書きたいので、興味がある方はそちらをぜひ!

Objective 2

新居をととのえる

Key Result 1 【できた】

ルンバを週3かけられる状態にする

  • 捨てる仕分けをしてない箱があるので終わらせる
  • 新居用家具・家電の箱を仕分ける
  • 集中部屋のカラーボックスを撤去する

結果として週2稼働させるようになりました。つぎの理由でi7+を選びました。

  • 家の構造マップを作って、選択した部屋だけ掃除できる
  • ゴミ収集も自動でしてくれるので、本体のメンテ頻度が減る

だいたいルンバだけで事足りますが、たまにカーペットの隙間をダイソンで掃除したり、フローリングをクイックルワイパー的なものでふいたりします。補助的な掃除は想像以上に不要で大満足です。

Key Result 2 【できた】

植物を迎える

  • リビングにビカクシダを迎える
  • ガジュマルを大きい鉢に移す
  • 集中部屋にパキラを迎える
  • 間違って買った造花のパキラを社会に循環させる

植物のある暮らし、よいです!たまに猫たちがリビングのエバーフレッシュをいじめますが、それでもめちゃくちゃよく育ちます。冬にもかかわらず。

ガジュマルはのびのび育ってくれるとよいなぁ。

集中部屋は日当たりよくないので、パキラを迎えました。

ビカクシダは元気かどうかよくわからず少し心配です。

Key Result 3 【できた】

  • 自動掃除してくれるトイレにチャレンジしたい

これは今年買ってよかったものベスト3に入りそうです!人間が毎日数回のトイレ掃除から、基本数週間に一度の砂捨てとそうじをするだけでよくなります。

さらに、トイレのあとに本体が回転してきれいな状態が保たれるので、一番猫たちがうれしそう!もとのトイレから移行する際、小さいタイプに変更した猫砂を食べたりはしたものの、もとのトイレにもすぐ行かなくなり無事使ってくれるようになりました。

商品はこのよくわからない名前のオートメーテッドペットケア キャットロボット オープンエアーというやつです。値段に見合う価値がありました。

12月の中旬に引っ越した新居は、全体としていい感じに整いました。日がしっかり入るのも精神によさそうです。引っ越す前はリビングで仕事してたこともあり、リモートワークで発狂してましたがそういうのも完全になくなりました。

家事の自動化も進み、いっそう集中すべきものに集中できる環境が整ったので、諸々よい決断ができたと思っています。

ログ

OKRとしては追ってないものの、記録しておきたいことのコーナーです。

読書

複業をどういうスタンスでやるのか考える上で読み参考になりました。あえて「副業」でなく「複業」と表記するスタンスの源泉でもあります。今あるスキルを切り売りするのは、自分にとっても自分の顧客にとっても割に合わないです。

会計ソフト開発してた割に会計のことなんも知らんなwwwwww

オーディブルに来てたので聴きました。これなんでスタートアップの経営者的な人々読むんやろ?

たぶんリモートワークで人との雑談が減った人生をどう生きるのかという観点で手にとったはずですが、広々とした家、集中できる部屋、熱中できる趣味(大学院留学準備)で解消しました。単に紛らわせているだけとも言います。

積立投資とロボット投信などに寄せ、なぜか税金観点で一番大事な部分が抜けていました。

複業先がAWSということでざっと読みました。ベンダーや機能名は変われど、エッジのある機能を使わない限りは、ある程度気持ちを察することができる気がしました。

TOEFL初回はあえて丸腰で受験すると言いつつ、どの程度しんどいのかを把握する目的で読みました。80点の人が100点を取得するのに必要な勉強時間は600時間ということで、いろいろと覚悟できました。そこまでかけません。

オーディブルで聴きました。ご本人はさることながら、彼女の両親の子を育てる気概からすごいですね。

10年前、コンサルやろう、MBAとりに行こうと思っていた頃に買った本を再び引っ張り出してくる日がくるとは思っても見ませんでした。

受験生モードなので、つぎの3ヶ月一切本読まなさそうです。

英語

NativeCampで続けていた「カランメソッド」がようやくレベル10までひととおり終わりました。

2月末の初TOEFL後は、複業も徐々におやすみさせていただくことにし、英語のスコアメイクに仕事以外のほとんどの時間を費やし始めていました。

大学院出願英語スコア準備計画

3月は、巷ではあまり見かけない(しかしもっとも筋が通っていて合理的に感じる)文法を教える予備校の授業を受けて英語そのものの足腰を鍛えたり、朝晩にmikanで単語を覚えたり、昼休みなどにTOEFLリスニング教材でシャドーイングしたりしていました。

4月は、それらをもとに問題演習と、スピーキング・ライティングの対策をします。5/3に模試、5/10に2回目の本試験を受ける予定です。

コースの出願要件にはTOEFLスコア100/120点とは書いているものの、調べる限りは90点台で大丈夫そうです。2回目の試験でなんとかそのラインに載せて少し安心したいものです。

Computer science

出願予定のジョージア工科大学のOMSCSは、学部でCSを学んでいれば、あまり不合格になることはなさそうです。しかし、そうでなければ、一般的にコミュニティカレッジで単位を取得したり、あの手この手で「CS修士のコースでやっていくだけの学力がある」ことを示す必要があります。コンピュータ関連の業務経験単体では代替にならないそうです。英語のスコアに並ぶ不安要素ですが、いまではこちらのほうが心配です。

履歴書、志望理由書、大学の成績、IT系資格、推薦書のうち、書類は基本的に4月からしっかり準備するとして3月は資格・単位っぽいものを増やしました。

2月末時点では、講座を提供していたペンシルバニア大学のMCITに出願しようと考えていました。受講して書類で触れるとプラスになると明記してあったので受けました。7月時点で出願するコースではないので、4月以降はData Structures and Algorithmsを受けます。

今後の話

4〜6月はいったん完全に受験生をやります。

Objective Georgia Tech OMSCSに出願する

Key Result 1

TOEFL 100点

  • 5月 90点
  • 6月 100点

Key Result 2

出願書類の準備

  • 4月
    • 履歴書
    • 志望理由書初稿
    • 推薦書依頼
    • 成績・卒業証明書申請
  • 5月
    • 履歴書ブラッシュアップ
    • 志望理由書ブラッシュアップ
  • 6月 資格系入力

Key Result 3

Data Structures and Algorithms

このコースは終わらせられない想定ではあるものの、実際受けて大丈夫そうなら終わらせたいし、英語のスコアが万一早く仕上がったらコンピューターアーキテクチャー系か数学系のコースを積み増したいです。

つぎの振り返りでは、もう出願が済んでいるなんて想像がつかないですね。

技術書典10に関わられたすべてのみなさんお疲れ様でした。

つぎの出展に備えて振り返りたいと思います。

出展した本の内容についてはこちらにまとめています。

技術書典10で新刊『Google Cloud Platformで学ぶTerraform 〜実践編〜』を含む6冊+αを出展します #技術書典

技術書典オンラインマーケットでも、BOOTHでも引き続き販売中です!

手にとってくださった方は、こちらのページで変更内容をお知らせしていくのでぜひ見てみてください。

『Google Cloud Platformで学ぶTerraform 〜実践編〜』

『Google Cloud Platformで学ぶTerraform 〜実践編〜』の正誤表と増補改訂情報 #技術書典

『Google Cloud Platformで学ぶTerraform 〜基礎編〜』

『Google Cloud Platformで学ぶTerraform 〜基礎編〜』の正誤表と増補改訂情報 #技術書典

『KnativeとIngress Gateway』

『KnativeとIngress Gateway 〜Ambassador、Contour、Gloo、Kourier、Istioの比較〜』の正誤表と増補改訂情報 #技術書典

『Knativeソースコードリーディング入門』

『Knativeソースコードリーディング入門 〜Knativeで学ぶKubernetesのカスタムリソースとカスタムコントローラー〜』の正誤表と増補改訂情報 #技術書典

『Knativeの歩き方』

『Knativeの歩き方 〜KubernetesからServerlessを訪ねて〜』の正誤表と増補改訂情報 #技術書典

『Goで学ぶAWS Lambda』

『Goで学ぶAWS Lambda』の正誤表と増補改訂情報 #技術書典

振り返り

Good

諦めなさ

技術書典10が発表されたのが10月28日。今年の2月くらいだろうと油断していたところ、12月26日まで2ヶ月弱しかありませんでした。

去年3回目の技術書典(= 締切)だったことや、12月に入っても検証が終わらなかったことで何度か折れそうになりました。それでも、実践編はいつ出るのか何人か問い合わせていただいたこともあり、なんとか間に合わせられました。

実践

仕事で得た知見を最大限活かせたと思います。資産として、会社のメンバーに対するオンボーディングに活かそうと思います。

表紙絵

妻に大感謝です。ついでに、ツイッターのアイコンも新しく作ってもらいました。

Challenge

改訂版

すでにいくつか指摘をいただいているので、改訂版を出そうと思います。コマンド間違いの訂正や、説明補足、Terraformのバージョンアップなどです。

ネットワークまわりで、デフォルトのVPCでなくShared VPCを利用するのもあったほうがいいかなぁとは思います。

紙本

前回の振り返りでも、紙本を検討しようとしていました。しかし、まったく時間がなかったので手つかずでした。

次回出展するとしたら、GCP Terraform本を改定するのと、基礎編と実践編を合わせたバージョンを出したいと思っています。

需要を調べ、もしあるようなら紙本を出します。

Zenn

基礎編と実践編を合わせたバージョンを作る段階で、Zennでも出そうと思います。ブラウザで全部読めると楽なのかもしれません。

数字の整理

売上

技術書典オンラインマーケット

12/26〜1/7分

  • Google Cloud Platformで学ぶTerraform 〜実践編〜: 46冊
  • Google Cloud Platformで学ぶTerraform 〜基礎編〜: 6冊
  • JavaScriptとSEO: 2冊
  • KnativeとIngress Gateway 第2版: 1冊
  • Knativeソースコードリーディング入門: 1冊
  • Knativeの歩き方 第2版: 2冊
  • Goで学ぶAWS Lambda 第2版: 4冊

1000円 × 60冊 + 500円 × 2冊 = 61,000円

BOOTH

12/26〜1/7分

  • Google Cloud Platformで学ぶTerraform 〜実践編〜: 20冊
  • Google Cloud Platformで学ぶTerraform 〜基礎編〜: 6冊
  • JavaScriptとSEO: 0冊
  • KnativeとIngress Gateway 第2版: 2冊
  • Knativeソースコードリーディング入門: 2冊
  • Knativeの歩き方 第2版: 4冊
  • Goで学ぶAWS Lambda 第2版: 6冊

1000円 × 40冊 = 40,000円

原価

過去分

前回の売上は、リモートワークに不可欠ないすと、実践編の前提になったProfessional Data Engineerの受験費用と、『Official Google Cloud Certified Professional Data Engineer Study Guide』の購入費用に充てました。

今回は妻用のいすを購入しようと思います。

近年は1年単位の目標は立てず、3ヶ月単位でプライベートOKRを作って振り返るのを繰り返してきました。一方で、方向性なしにその時点の興味だけで突き進むのも積み重なる感じがしないので、ロードマップ的なものも作りました。

それらの点は変わらないのですが、2021年は「旗を立てる」という1年単位のテーマを設けます。

旗を立てる

「旗を立てる」を具体的に言うと「GCPのコンテナ/サーバーレスワークロードで、個人に仕事の依頼がくること」です。

会社の看板ベースではなくて、提供できる価値を明確にした個人宛に相談、開発、執筆、監訳などの仕事がくる状態を目指します。本業を続ける前提で、その知見を活かして実績を積み、さらに本業を加速させる良いフィードバックループをイメージしています。

そうしようと思ったきっかけはこれです。

反応皆無でした。最終的には、Coral Communityに登録した日にいただいたお誘いの中から、現状のスキルセットで一番貢献できそうな企業で複業することにしました。

複業からでも…というお誘いが普段からないわけではないです。ただ、いざ動けるになって発信したときに、何ができる人なのかを認知され、それを裏付ける実績があり、いい形でコラボレーションできる状態でありたいと強く思いました。

提供したい価値

「GCPのコンテナ/サーバーレスワークロード」では、つぎのような価値提供を念頭においています。

  • マイクロサービスたくさんあって大変!をどうにかする
  • そういう系の基盤をこれから作ろうとしているチームのサポート
  • GKEワークロードの管理
  • Cloud Runワークロードの管理
  • マイクロサービス開発(Go)
  • マイクロサービス開発・運用を支えるツール開発(Go)
  • Terraformによるインフラのコード管理

GKEやCloud Runを使ってサービスを提供するチームが直面する課題を解決したいです。もちろん、起こりうるあらゆる問題を解決する知見や経験はないです。

本業では、深さ的にも幅的にもいろいろなプロジェクトに取り組めると思うので、特にやったことのないことに臆せず挑戦するマインドセットをもって強くなります。それを複業での問題解決に活かしたり、(よりよく)再現できる形に文章化したりすることで、さらに本業で新たな問題を解決する力にできると信じています。

提供できる価値をどう示すか

どのような価値が提供できるのかを、さまざまなメディアで伝えたいと考えています。すでにこれまで取り組んできたものでも、より活用しやすいメディアを活用していきます。たとえば、技術書であればZennのようなWebで読んだり、手を動かしたりしやすいサービスを利用するなどです。

  • ポートフォリオ or 事業サイト
    • GCP関連で静的サイトのホスティング
  • 技術書
    • ZennやWebで読めるサービスの活用
    • 技術書典出展継続
  • 技術記事
    • 会社のテックブログ
    • 寄稿
    • Zenn
  • サンプルリポジトリ
  • OSS
  • 音声?
  • 動画?

直近の予定

本業で強くなることが大前提です。それに加えて、今期のOKRにもあるとおりまずは複業をはじめます。

2020年10〜12月ふりかえりと1〜3月OKR 〜旗を立て始める〜

取り組んだこと、解決した課題を再現可能な状態にするための言語化と発信もこれまで以上に行っていきます。そのため、上に書いたメディア関連のTODOを作ってやっていくことを整理します。

もしピンとくることがあれば、ぜひお声がけください!!

プラットフォームエンジニア1年目の2020年を振り返ります。大変だったこと、うれしかったこと、キャッチアップを加速させるためにやったことなど。

2020年

異動

2020年に、マイクロサービスを開発するためのプラットフォームを開発・運用するチームに移りました。

Software Engineer, Microservices Platform

2019年までは、そのプラットフォーム上で稼働するマイクロサービスを開発・運用していました。2018年9月の入社当初、GCP、Kubernetes、Goの業務経験がなかった状態で設計〜リリースまでを担う中で、プラットフォームが提供する機能に大いに助けられました。

一方で、サーバーレスなテクノロジーが好きだったり、Kubernetesを学ぶ中でKnativeに出会ったりしたことで「マイクロサービス開発者から見たプラットフォームの利便性」はもっと向上できるのではないかと思い、Microservices Platformチームに参加させてもらうことにしました。

1年目にやったこと

列挙するとつぎのようプロジェクト・役割に携わりました。

  • オンサポート(複数回)
  • Istioワークショップ
  • Network Policyの導入
  • Disaster recoveryテスト
  • リライアビリティ強化

6週間毎に、担当が変わります。

オンサポート

最初はオンサポート(とオンボーディング)でした。マイクロサービス開発者から寄せられるサポート依頼に対応します。オンボーディング観点では、アーキテクチャやリポジトリなどには馴染みがあったので、KubernetesクラスターやTerraform周りのオペレーションや、プラットフォームチームが開発・運用しているコンポーネントのキャッチアップが中心でした。

Terraformは何も知らなかったり、KubernetesのオペレーションはマイクロサービスのデバッグやCKADで出てくる範囲くらいしかわかりませんでした。そのため、

検証環境でやるのを見せてもらう -> 開発環境や本番環境でついてもらってやる

というペアオペレーションが多かったです。フィードバックも毎日夕方に1on1してもらって、改善の日々でした。

マイクロサービス開発時に自分もわからなくて頼っていたエラー対応が、チームを移ったからといって即座にわかるようになるわけがありません。間をおいて何度かオンサポートを担当したり、他のプロジェクトに取り組むなかで理解を深めました(今もなお。アサインに配慮を感じつつ)。

Istioワークショップ

Istioワークショップは、Istio何もわからんの状態からいろいろキャッチアップして、マイクロサービス開発者向けに「サービスメッシュとは何か」を話したり、マイクロサービスのテンプレートとなるマイクロサービスで実際にIstioの機能を試すハンズオンセッションです。

外出自粛直後の3月の開催だったので、慣れないながらもSlackでコミュニケーションしつつ、Google Meetでスライドやターミナルをシェアしながらがんばりました。マイクロサービス開発者目線では、どんな便利なプラットフォームの機能も、機能開発が忙しいときには導入やキャッチアップ自体がかなりのハードルです。こういう試みは大事と思いつつ取り組みました。

つぎの本、Udemyの講座、登壇が特に役立ちました。

ドキュメメントは読みますが、最初にDemoを含む動画で概要をつかむと捗りました。

Network Policy

Network Policyの導入は、KubernetesのNetwork PolicyをTerraformモジュールも利用しつつマイクロサービス開発者が利用できるようにするものです。

今回は利用しない機能、デフォルトで有効にすべきポリシー、サポートするユースケース、段階的な移行方法などを議論しながらDesign Docを書きました。議論のスコープに、Network Policyに限らずプラットフォームコンポーネント全体に影響する事柄もあったことから、シュッと決めきれず難しさを感じました。しかし、ユーザーインターフェースとしてのTerraform variableや、設計議論の進め方など、学ぶことが多かったです。

また、導入にあたり希望マイクロサービスのベータテストを行い、フィードバックをもらって改善するプロセスなどは「プロダクトとしてのプラットフォーム」を強く感じました。

会社のテックブロクは書きませんでしたが、技術的にはつぎの記事のようなイメージです。

Terraform Kubernetes Providerとkindで試すNetworkPolicy

こういうユースケースのテストにこそTerratestを使ってみたかったです。最近出した本中のモジュールで、はじめて使いました。

Disaster Recoveryテスト

Disaster Recoveryテストは、GCPのTokyoリージョンが利用できない状態になったら…を想定して、すでに用意していたDisaster Recovery計画に基づきOsakaリージョンでサービスを一時的に立ち上げるものです。

クラスター内のリソースバックアップにVeleroを利用し、復旧用スクリプトを用意するなどしました。チーム横断的にとりくむプロジェクトだったので、あえて議論の枠を準備したり、定例や振り返りをリードしてみたりに挑戦しました。

リライアビリティ強化

リライアビリティ強化は、Datadogのモニター、ダッシュボードなどを見直たりしていい感じにアラート対応できるようにする取り組みです。

数百あるDatadogのモニターをすべてリストアップし、Playbookがないものを洗い出して追加したり、よくアラートが鳴るものの原因を調査したり、絶賛年末大掃除みたいな感じでした。

メンバーが増えて、再現可能な状態でオンコールにオンボーディングするには、適切な閾値でアクションのとれるアラートが鳴るのは大前提です。

その他

インターンメンバーの面接・メンターも担当しました。これまで、中途メンバーの面接やメンターはやったことはあったものの、インターン関連でははじめてです。

これがすべてです。

メンターという形ではなくても、プロジェクトのリードとして新しく入ってくる方のサポートをする機会もたくさんありました。学びの機会にあふれています。

キャッチアップとアウトプット

もちろん、業務中も必要なキャッチアップ時間やサポートはありました。しかし、僕は闘争する民族なので、これまでもやっていたプライベートOKRで四半期毎に身につけたいことを決めて取り組みました。キャッチアップすべきことは無限にあるので、「この四半期はこれ以外はやらない」をはっきりさせる意味合いが強いです。

OKRは、各記事でなぜそれが達成したいのかや、どの程度達成したのかなどの振り返りと合わせてまとめています。

2019年10〜12月の振り返りと2020年 〜YAML Engineerとしての闘争〜

2020年1〜3月ふりかえり 〜HCLエンジニアとしても闘争〜

2020年4〜6月ふりかえり 〜より抽象的なプラットフォーム仕草を身につける〜

2020年7〜9月ふりかえりと10〜12月OKR 〜プラットフォームエンジニア設計譚〜

2020年10〜12月ふりかえりと1〜3月OKR 〜旗を立て始める〜

資格

1年と少しで、KubernetesとGCP関連の試験をいくつか受け合格しました。

  • 2019/12: Certified Kubernetes Application Developer (CKAD)
  • 2020/3: Certified Kubernetes Administrator (CKA)
  • 2020/6: Google Certified Professional Cloud Architect
  • 2020/9: Google Certified Professional Cloud DevOps Engineer
  • 2021/1: Google Certified Professional Data Engineer

Kubernetes関連のものは、テストでも準備でも実技不可避だったので取り組みました。Kuberneteクラスターのバージョンアップなどでかなり役立ちました。

GCP関連のものは、それぞれ動機が異なります。Cloud Architectは、Terraformの本を書こうとしたらGCPの基礎理解がなさすぎて書けなかったからです。執筆を一時中断し、あわてて『Official Google Cloud Certified Professional Cloud Architect Study Guide 』を読みました。模試Webサービスつきなことや、物心ついてからクラウド概論に触れてなかったこともあったりで役立ちました。文章に品があって良いです。

Cloud DevOps Engineerは、SREの原理・原則を理解したかったタイミングで確認テストとして受けました。テキストは『サイトリライアビリティワークブック ―SREの実践方法』です。

Professional Data Engineerは、GCPのDBまわりをざっくり知りたかったのと、Terraform本にデータパイプラインの例を足したかったので勉強しました。安定の『Official Google Cloud Certified Professional Data Engineer Study Guide』が教材です。

極論資格として取得できてなくてもよかったですが、どの時期に何を勉強していたかがわかりやすくていいですね。

執筆

1年で3冊の本を執筆・改定しました。毎Q締切があってきつい1年でしたが、取り組んでよかったです。

Knative本は、同僚に「なぜIstio(VirtualService)を使わずにKnativeはトラフィックスプリッティングのような機能を実現できるのか」と質問されて答えられなかったのがきっかけで調べることにしました。ちょうどIstio関連のプロジェクトに取り組んでいたタイミングで、ネットワークまわりをいろいろ調べられました。

Terraform本は、GCPでTerraformを体系的に学ぶための情報がないという問題意識に基づき書きました。

特にオンサポートをやる上では、Terraformのデバッグは必須です。また、何かプラットフォームとして機能を提供する際には、Terraformモジュール設計が大体必要です。自分が実務に取り組む前に知っておきたかったことをまとめました。

さらに、マイクロサービスの開発者にとっても、有益な情報であると考えました。たとえプラットフォームがモジュールを提供しても、マイクロサービス独自に利用するリソースについては、現状Terraforを書かなくてはいけません。エラー調査をプラットフォームチームに依頼する際も、大まかな仕組みや原因がある程度わかった方が容易です。プラットフォームのエンジニアとしては、困ったら頼ってほしいと思いつつ、マイクロサービス開発者としては、頼っていいものなのか自分たちでなんとかできるものなのか切り分けできたかったという思いがありました。そういうものを意識しなくても、開発に集中できるプラットフォームを目指しているのは言うまでもありません。

(前年比)業務に密接に関連した執筆は「あ、これ昨日検証したやつや!」の連続で、本業に活きていている感がすごかったです。

ついでに、売上で椅子が得られたりしたのでとてもよかったです。

7〜9月のKRのひとつに掲げていたのが「学び方の改善」です。

学び続ける生き物は、その学び方を改善することで得られるメリットが計り知れないほど大きいです。

エンジニアの知的生産術 ―効率的に学び、整理し、アウトプットする』を読んだり、チームの人のおすすめリストを読んだりしながら自分なりに読書リストを作って進めています。意識的にOKRに関連させるようにしています。これら以外は読まないというわけでもないですが、読むのが速くないので特に大事なものに絞る必要があります。

Platform Engineerへの闘争🐸

読み終わった本。

こういうのも親身に相談に乗ってもらえるので、安心して闘争できるのがうれしいです。

複業

サーバーレスコミュニティのつながりもあり、複業にも取り組みました。以前いったんは始めたものの結局タイミングやフェーズ合わなかったり、執筆や寄稿もある意味複業とは思いますが、案件に入っていくのは初めてです。

いつか一緒になにかできたら…と思ってた方々と一緒に仕事できてよかったです。一方で、あまり案件に深く入れないまま終わってしまったので残念でした。SlackでGCPの質問に答える係を3ヶ月担当しました。

フロントと認証・認可まわりは課題っぽいです。

2021年

2021年のことも書こうとしたのですが、思ったより長くなったので別記事にします。

業務的には、引き続きPlatform Engineerへの闘争を進め、プラットフォームエンジニアとしての運用ももっと楽にできるようにしたり、マイクロサービス開発者向けにサーバーレスで想起されるような体験を提供していきたいです。

四半期ごとの個人OKR振り返りです。

2020年10〜12月は、設計のプラクティスを念頭に置いて、より実践的な設計・開発のアウトプットをするのが主な内容でした。

振り返り対象の個人OKRはこの記事2020年7〜9月ふりかえりと10〜12月OKR 〜プラットフォームエンジニア設計譚〜で立てています。

OKRの振り返り

3段階で見ていきます。

  • できた
  • 微妙
  • できなかった

Objective 1

設計よくしていこうな

今年学んできた個々の技術を組み合わせて、保守性と信頼性が高いサービス設計を学び、実践する。

Key Result 1 【できた】

・12月の技術書典10で『Google Cloud Platformで学ぶTerraform 〜実践編〜』を執筆する
・『サイトリライアビリティワークブック ―SREの実践方法』を読む
・Professional Data Engineerを受ける
・『Official Google Cloud Certified Professional Data Engineer Study Guide』を読み、模試を解く
・『A Philosophy of Software Design』を読む

このKRがも最重要なため、KR2、KR3が厳しく感じたら迷わずKR1を選ぶ。


技術書典10では、新刊『Google Cloud Platformで学ぶTerraform 〜実践編〜』を無事出すことができました。

技術書典10で新刊『Google Cloud Platformで学ぶTerraform 〜実践編〜』を含む6冊+αを出展します #技術書典

本のメインテーマとなるモジュールやCI/CDの検証ではまりにままり、終わったのが12月6日。何度か折れそうになりましたが、なんとか間に合ってよかったです。

前Qから読んでいたSREワークブックは読み終わりました。サービスの運用やSREの原理・原則を意識して働かざるをえない以上、不可欠な知見に目を通せた気がします。

さらに、Googleの分散システムや、GCPのアーキテクチャを例に説明している部分も多く、純粋に面白かったです。

特に、Non-Abstract Large System Design(NALSD)は、ある設計をするとどういう問題が発生するのかを具体的に計算しながら段階的に設計改善していく話で、特に身につけたいなと思いました。AdWordsを例に解説されています。

https://sre.google/workbook/non-abstract-design/

これもよさそう。

SRE Classroom: 非抽象的な大規模システム設計の演習

ある程度実務経験も増えると、原理・原則の話をされても腹落ちすることが増えると思います。そういうものに意識的に触れて、成長にレバレッジをかけたいものです。

Professional Data Engineerは、技術書典10脱稿後すぐに『Official Google Cloud Certified Professional Data Engineer Study Guide』の模試を解き、点のよくない章から勉強し、1月2日に合格しました。2週間の冬休みは、原稿とテスト勉強で終わりました。

本当は、いい感じのデータパイプラインのアーキテクチャ例を『Google Cloud Platformで学ぶTerraform 〜実践編〜』に盛り込みたかったです。でも間に合いませんでした。

詳細は各サービス使ってみなわからん、みたいな部分が多かったです。それでも、気持ちは十分に学べたので、今後の業務や複業などで肉付けしていこうと思います。

A Philosophy of Software Design』は、文字通りソフトウェアを設計する上で意識すべき指針について書かれたものです。具体的に名前がついている設計パターンよりも抽象的なもの。

設計手法を適用するよりも、「こう設計したらどう困るだろう?」と考えるための言葉がたくさん散りばめられているので、何にでも適用できそうです。『Google Cloud Platformで学ぶTerraform 〜実践編〜』でも、Terraformモジュール設計に活きました。原則に沿って、地に足のついた問いかけを積み重ねていくとよさそうです。

Key Result 2 【できなかった】

Cloud Runのユースケース集を世に送り出す

・Serverlessなカンファレンスがあればワークショップ、なければZennなどで出す
・『Building Serverless Applications with Google Cloud Run


なにもできませんでした。EAPのときに読んだ『Building Serverless Applications with Google Cloud Run』にざっと目を通したくらいです。

きっとこれからもっと使うサービスだと使うと思うので、気長に…

Key Result 3 【微妙】

KompalWeatherをGAに

  • production用のプロジェクトに移す
  • BigQuery MLで混雑状況予測
  • UIを生やす
  • ログ・エラーレポート周り改善

このサービスの混雑状況監視対象サウナがある地域から引っ越したので優先度が…というのはおいといて、KR1との兼ね合いで、ほとんど時間が避けませんでした。

BigQuery MLは、クエリ書くノリでモデル作成できてすごい…!という感じでした。技術として。

このサービスを作った目的は、より空いてるタイミングでサウナに入りたいというものでした。しかし、「混雑」状態で入店しても同時にサウナに入る人が少ないときは少ないし、「空いてる」状態で入店してもサウナでぎゅうぎゅうになることがあって「混雑状況見ずに行きたいときに行けばよい」が結論になりました。検証できてよかったです。

この登壇も含め、Cloud Runにしっかり触り、Terraformも積極的に活用したのはよかったです。

UIは思うところがあるので、別の文脈でなにか書きます。

Objective 2

Key Result 1 【できた】

嫁氏のストレスを軽減する


Fitbit Senseをプレゼントして、ストレスを定量的に把握することからはじめました。

家事一覧とそれの分担・自動化度を表にしたりしました。引越も大きい。今回に限らず続けていく所存です。

Key Result 2 【できた】

ミファーを護り抜き、あの頃のように遊びに行く


去年出会って一番よかったのは、ダントツでゼルダの伝説 ブレス オブ ザ ワイルドです。日々プライベートOKR達成に向けて腐心し、それ以外の事柄に手放しで身を委ねることができなくなっていました。そんな中で、OKR達成のための時間を削ってでも、夢中になって取り組みたいと思える楽しみ。それがこのゲームでした。

続編がこのゼルダ無双 厄災の黙示録。体験版も済ませ、発売日にゲームソフトを買うのも小学校ぶりかもしれません。

ただ、技術書典10の準備も佳境だったので、2日間集中してメインストーリーを終わらせました。ひたすらエモかったです。1月以降もう少しやり込もうと思います。

Key Result 3 【できた】

旅行する

ふるさと納税奴で石川県に行くか、GoToの波に乗るか、それともシー=>ミラコスタ=>ランドの夢を叶えるか…日常の物理的範囲が狭まる中、非日常を得たいです。


GoToの波に乗り、新宿のパークハイアットホテルに宿泊しました。目的は、宿泊者は滞在中何度でも入れるサウナ「クラブ オン ザ パーク」です。贅沢とは何かを知りました。

感想

一昨年のふるさと納税で石川県の宿の宿泊券をもらったのですが、結局行けずじまい。状況が状況なので電話してみたところ、期限を1年延長してもらえました。今年は満を持して訪問したいものです。

Key Result 4 【できた】

(不確定要素はある中で)もし居住エリアに職場の制限がないなら、どこにどう住むのがよいか?みたいな話を最近よくします。その中で今の家はよいという話や、もっと広い家に住みたいという思いがあります。よい椅子を買ったのでもう十分という気持ちもあります。

更新タイミングも近いので、どうするか2020年時点の結論を出します。


引っ越しました。去年の物件では、間取り的に夫婦でMTG時間がかぶると厳しかったのが最大の要因です。

キャッツ、サウナ、間取り、広さを最大限考慮したことで、最高の生活を得ました。引越については、別途noteで書こうかなと思っています。

ログ

OKRとしては追ってないものの、記録しておきたいことのコーナーです。

読書

ここまでで書いたもの以外です。

感性が限りなく鈍ってる感じがしたので、読んでみました。これを読まなかったら、集中部屋はモノトーンになっていたはずです。はずれのない色で埋め尽くすより、ちょっとせめて楽しんでみようと思うようになりました。

この記事を読んだのがきっかけです。

明治時代に東大農学部の教授をやられてた方の投資・人生哲学です。経験、資産、信頼の積み重ね方が尋常でなくてすごかったです。

このツイートを見たのがきっかけです。OKRを追いかけるのがわたしの人生か?は常々思ってるんですが、ここまで振り切れたら(「人生最大の幸福とは、職業の道楽化である」の部分)立派やなぁと思います。

最近聞き始めて、途中です。タイトルに対して正直に答えると、楽しくはないんですよね。人生に対して構えすぎてる感がある。

幸せは人との関わり合いの中で見出すもの(よく覚えてない)的な話の中で、去年はほんとうに雑談減ったなぁと思ったし、プライベートでの人との関わりがなさすぎて余計につまらなかった気もしました。

勉強会のあとの懇親会ていどの絡みもほとんどなかったです。片手で数えるほどですが、オンラインで他社のエンジニアと話したのは楽しかった。

今年はもう少し人間味のある活動しようかなぁと思います。

やーこれは売れるわ(事実)。世界中でベストセラーになる。

コンマリ先生の本はじめてよみました。片付けのハウツー本ではなく、人生哲学です。ものを捨てるのも、(引っ越ししたのも、)より好きなものに出会い、そういうものに囲まれて暮らすため。引っ越しタイミングでかなりいろんな本、服、小物などなどを捨ててすっきりしました。

あとコンマリ先生の人生がロックで、めちゃくちゃかっこよかったです。ここまでこだわりもって生きられたらかっこいい。

何書いてたか何も覚えてないです。

引っ越したら観葉植物も家族に迎え入れるか〜と思って読みました。ふるさと納税でエバーフレッシュパキラをもらい、パキラは造花で萎えました。

ビカクシダを迎えるための壁を用意したりもしてます。

本ではないです。寝る前には紙の本を読むのですが、紙本はもっと減らしたいので目が覚めない端末を確保しました。もともと電子書籍はFire HDで読んでたのですが、ちょっと明るすぎたので。

サイズも気にならないし、ページもめくりやすいし、明るさも調節できるのでいい感じです。

英語

10〜12月の英会話(NativeCamp)の受講状況はこんな感じでした。

  • 10月: 32回、13時間21分
  • 11月: 27回、11時間15分
  • 12月: 28回、11時間40分

引き続き「カランメソッド」を中心に受講しています。10分冊の9冊目がもう少しで終わりそうです。

12月からは、特定のトピックに関してされる質問に答える「5分ディスカッション」というのをはさむようになりました。週8レッスン(火、木、土、日に25分×2)のうち、2回を充てています。

以前であれば原稿の締切や引越など、大きなイベントがあると途絶えてそれきりだったと思うのですが、ちゃんと持続する習慣は作れるようになったのかなぁと思います。特にカランメソッドは話題を自分で作らなくていいのでペースを作りやすいです。

一方で、仕事で話す英語も定型的なMTGでは「全文スクリプト」とか作らなくても話せるようになった気がするものの、オンライン飲み会(英語)はまだまだきついです。きつさの内訳が全部英語能力ということはない(話題提示とか)ものの、関心の強いテーマ(猫、サウナ、技術書執筆)を振ってもらうのに対し、自由に表現できてないなぁとも感じます。

いまの学習スタイルを継続するべきか、テコ入れすべきか判断できないのが困ります。

今後の話

今年は「旗を立てる」をやります。プラットフォームエンジニアとしてのキャリア、それを支える技術・考え方の学習は引き続き。詳しいことはきっと別記事で書きます。

2021年1〜3月のOKRです。OKRなしでいこうかなとも思っていたのですが、ゆるめに置くことにしました。

Objective 1

旗を立てるための学習を継続し、実績を積み始める

Key Result 1

「旗を立てる」宣言をする

  • 旗を立てるの趣旨ややることをまとめた記事を書く
  • TODOを作る

Key Result 2

複業の開始

  • 企業にアプローチする
  • GCP・コンテナ関連の仕事を月30時間くらいからやっていく

Key Result 3

コンテナの基礎を学ぶ

Objective 2

新居をととのえる

Key Result 1

ルンバを週3かけられる状態にする

  • 捨てる仕分けをしてない箱があるので終わらせる
  • 新居用家具・家電の箱を仕分ける
  • 集中部屋のカラーボックスを撤去する

Key Result 2

植物を迎える

  • リビングにビカクシダを迎える
  • ガジュマルを大きい鉢に移す
  • 集中部屋にパキラを迎える
  • 間違って買った造花のパキラを社会に循環させる

Key Result 3

  • 自動掃除してくれるトイレにチャレンジしたい

2020年12月26日(土)〜2021年1月6日(水)に開催される技術書典10で6冊出展します!

カエルと空というサークルで、このページから出展しているのでぜひのぞいて行ってください!

カエルと空のサークルページ

出展する本を紹介します。

『Google Cloud Platformで学ぶTerraform 〜実践編〜』

前回出した基礎編の続きです。基礎編の内容理解を前提とし、モジュールの設計、リント、バリデーション、テスト、CI/CDなどのより実践的な内容をお届けします。

正誤表・増補改訂情報はこちらのページで公開しています。

『Google Cloud Platformで学ぶTerraform 〜実践編〜』の正誤表と増補改訂情報 #技術書典

すでにBOOTHで電子版をご購入いただける状態になっています。

https://toshi0607.booth.pm/items/2629085

登場するほとんどのサンプルコードも、GitHub上で公開予定です。

目次です。

第1章 はじめに

第2章 環境構築
2.1 GCPアカウント
2.2 GCPプロジェクト
2.3 Google Cloud SDK
2.4 tfenv
2.5 Hashi CorpTerraform
2.6 まとめ

第3章 2層アーキテクチャ
3.1 アーキテクチャの概要
3.2 アーキテクチャの詳細
3.3 Terraform化
3.4 安全な変更
3.5 まとめ

第4章 アーキテクチャの全体像
4.1 アーキテクチャの概要
4.2 Terraformモジュール
4.3 まとめ

第5章 Projectモジュール
5.1 モジュールの機能
5.2 組織の作成
5.3 モジュールの開発
5.4 まとめ
[コラム]GCPプロジェクトのクオータ緩和申請

第6章 Clusterモジュール
6.1 モジュールの機能
6.2 モジュールの開発
6.3 まとめ
[コラム]モジュールのパス
[コラム]モジュールの埋め込みとコンポジション

第7章 Microservicesモジュール
7.1 モジュールの機能
7.2 モジュールの開発
7.3 まとめ

第8章 リントとバリデーション
8.1 terraform fmt
8.2 terraform validate
8.3 TFLint
8.4 Conftest
8.5 まとめ

第9章 テスト
9.1 Terratest
9.2 Projectモジュール
9.3 Microservicesモジュール
9.4 まとめ
[コラム]テストの磨き込み

第10章
10.1 Cloud Build
10.2 事前準備
権限付与
Step実行用のコンテナイメージ
CloudBuildとGitHubの連携
10.3 ソースコードと変更差分の取得
10.4 Terraformの検証‧実行
10.5 モジュールのテスト
10.6 まとめ
あとがき

『Google Cloud Platformで学ぶTerraform 〜基礎編〜』

僕は、マイクロサービスを開発するためのプラットフォームを開発・運用するチームで2020年から働き始めました。それ以前の仕事は、バックエンドエンジニアとしてのマイクロサービス開発です。プラットフォームチームが開発したTerraformモジュールに設定を渡し、GCPやKubernetesのリソースを作成していました。

いざそのモジュールを作成したり、エラーのデバッグをする立場になってみると何もわかりません。つぎのような疑問がわきました。
・モジュールとは何か
・複数のリソースから構成されるアーキテクチャはどう組み立てるのか
・なぜ Terraform の状態と実際のクラウドリソースの状態はずれるのか

Terraformの概念や個々のリソースの使い方、GCPを利用したサンプルのモジュールはたくさんあります。Terraformに関する書籍もあります。
しかし、Terraformの具体的な説明に登場するクラウドは、ほとんどがAWSです。クラウドアーキテクチャの設計経験も多くはない著者にとって、AWS ベースで説明された内容をGCPに置き換えながら学ぶのはとても大変でした。そこで、この本を書くことに決めました。

AWSからGCPへの翻訳をせず、クラウドの設計やTerraformをGCPを通じて学べる本。半年前の僕が欲しかった本です。この本を通じ、Terraform をより身近に感じる人が増えたら幸いです。

正誤表・増補改訂情報はこちらのページで公開しています。

『Google Cloud Platformで学ぶTerraform 〜基礎編〜』の正誤表と増補改訂情報 #技術書典

すでにBOOTHで電子版をご購入いただける状態になっています。

https://toshi0607.booth.pm/items/2354817

登場するほとんどのサンプルコードも、GitHub上で公開しています。

toshi0607/Learning-Terraform-with-GCP

目次です。

第1章 はじめに

第2章 Terraform の概要
2.1 Terraformの意義
2.2 Terraformのアーキテクチャ
2.3 まとめ

第3章 環境構築
3.1 GCPアカウント
3.2 GCPプロジェクト
3.3 GoogleCloudSDK
3.4 tfenv
3.5 vscode-terraform
3.6 まとめ

第4章 リソースとterraformコマンド
4.1 リソース
4.2 terraformコマンド
 init
 plan
 apply
 destroy
4.3 ライフサイクル
 create_before_destroy
 prevent_destroy
 ignore_changes
4.4 まとめ

第5章 Configurationの書き方
5.1 関数
 join
 length
 contains
 values
 file
 その他の関数
5.2 変数
 variable
 output
 locals
 データソース
5.3 ループ
 count
 for_each
 for
 dynamic
5.4 条件式
5.5 バージョンの明示
5.6 モジュール
 子モジュールの定義
 ルートモジュールの定義
5.7 まとめ

第6章 ステート管理
6.1 ステートの構造
6.2 リモートバックエンド
6.3 管理単位
 ワークスペース
 バックエンド
6.4 参照
6.5 ズレと直し方
 定義あり、ステートあり、リソースあり
 定義あり、ステートあり、リソースなし
 定義あり、ステートなし、リソースあり
 定義あり、ステートなし、リソースなし
 定義なし、ステートあり、リソースあり
 定義なし、ステートあり、リソースなし
 定義なし、ステートなし、リソースあり
 定義なし、ステートなし、リソースなし
6.6 リファクタリング
6.7 まとめ

あとがき

『KnativeとIngress Gateway 〜Ambassador、Contour、Gloo、Kourier、Istioの比較〜 第2版』

初版から大幅に加筆した第2版です!

2019年末同僚に「なぜIstio(VirtualService)を使わずにKnativeはトラフィックスプリッティングのような機能を実現できるのか」と質問されて答えられなかったのがきっかけで調べることにしました。

Knativeは当初Ingress GatewayにIstioを採用(依存)しましたが、後にGlooをはじめ様々なコンポーネントで代替可能になりました。代替できる事実は知りつつも、なぜ代替できるのか、代替できるとはどういうことなのかを調べることはありませんでした。

しかし、「プラットフォームを開発・運用する」ことへの関心が高まり、(何層もある)Knativeより下のレイヤーを学びたい気持ちが強くなりました。本書はその一環です。Knative = Kubernetes Networkingとも説明されるKnativeのIngress Gateway周りの調査はKubernetesが提供しているService、Ingressの特徴や課題、そもそもロードバランサーとは何かのか、サービスメッシュやEnvoyとはどういう関係があるのか、といったネットワーク関連の入門にもうってつけでした。

「KnativeはなぜIngress Gatewayを交換できるのか?」という問いに答えることは、Envoyの設定をどう表現し、どう配信するかというデザインパターンを見い出すことに繋がります。

90ページ弱の自由研究に付き合っていただけたら幸いです!

すでにBOOTHで電子版をご購入いただける状態になっています。

https://toshi0607.booth.pm/items/1882118

目次です。

第1章 Knative
1.1 概要
1.2 Serving
1.3 Eventing
1.4 まとめ

第2章 Gateway
2.1 ServiceとIngress
2.2 Gateway と Service Mesh
 [コラム]APIGatewayとサービスメッシュの違い
2.3 Envoy とコントロールプレーン
2.4 コントロールプレーンの実装例(Istio)
2.5 まとめ
 [コラム]IngressAPIの進化
 [コラム] L4 から L7 ロードバランサーへ

第3章 Istio
3.1 概要
3.2 KnativeのCRD
3.3 Knativeのコンポーネント
3.4 IstioのCRD
3.5 Istioのコンポーネント
3.6 localgateway
3.7 Gateway
3.8 まとめ

第4章 Ambassador
4.1 概要
4.2 Knativeのコンポーネント
4.3 Ambassadorのコンポーネント
4.4 AmbassadorとEnvoy
4.5 まとめ

第5章 Contour
5.1 概要
5.2 Knativeのコンポーネント
5.3 Contourのコンポーネント
5.4 まとめ

第6章 Kourier
6.1 概要
6.2 Knativeのコンポーネント
6.3 Kourierのコンポーネント
6.4 まとめ
 [コラム] Kourier の活用事例

第7章 Gloo
7.1 概要
7.2 Knativeのコンポーネント
7.3 Glooのコンポーネント
7.4 まとめ
 [コラム]Envoyとgo-control-planeの今後

第8章 まとめ
8.1 Gateway
8.2 Ambassador
8.3 Contour
8.4 Gloo
8.5 Kourier
8.6 Istio
8.7 最後に

Appendix

『Knativeの歩き方 KubernetesからServerlessを訪ねて 第2版』

こちらはKnativeのコンポーネントの説明やユースケースを中心に説明した本です。実際にKnativeが利用されたプロダクトの図解も掲載しています。

こちらもすでにBOOTHで電子版、紙本 + 電子版がBOOTHで購入できる状態になっています。

https://toshi0607.booth.pm/items/1309468

正誤表や増補改訂情報ページはこちらです。

『Knativeの歩き方 〜KubernetesからServerlessを訪ねて〜』の正誤表と増補改訂情報 #技術書典

目次です。

第1章 Knativeの概要
1.1 Knativeの構成要素
1.2 Serving
1.3 Build
1.4 Eventing

第2章 Kubernetes環境の準備

第3章 KubernetesとKnativeの関係
3.1 Kubernetesの基本的思想
3.2 Kubernetesのオートスケール
3.3 Kubernetesの拡張機能

第4章 Knative Serving
4.1 Knativeのインストール
4.1.1 Istioの設定
4.1.2 Knativeの設定
4.2 Configuration
4.3 Revison
4.4 Routes
4.5 Service
4.6 オートスケールの仕組み

第5章 Knative Build
5.1 Build
5.2 BuildTemplate
5.3 Servingと組み合わせる

第6章 Knative Eventing
6.1 Sources
6.2 BrokerとTrigger
6.3 ChannelとSubscription

第7章 Knative のユースケース
7.1 FaaS プラットフォームの構築
7.1.1 イベントやリクエストを Function に渡すサーバー
7.1.2 サーバーとFunctionのパッケージング
7.1.3 CLI
7.2 イベント pull 型の FaaS 〜Knative Lambda Runtimes の利用例〜
7.2.1 AWS Lambda の Function(Go)
7.2.2 AWSLambdaとRuntimeInterface
7.2.3 knative-lambda-runtime
7.2.4 triggermesh/aws-custom-runtime
7.2.5 bootstrap
7.2.6 Tekton で生成するコンテナイメージ
7.3 イベント push 型の FaaS 〜OpenFaaS の Watchdog の利用例〜
7.3.1 WatchdogによるFunction制御
7.3.2 WatchdogとFunction同梱のDockerfile
KnativeのCLI

『Knativeソースコードリーディング入門 Knativeで学ぶKubernetesのカスタムリソースとカスタムコントローラー』

Knativeの仕組みをより深く追おうとするときに、Kubernetesのカスタムリソースやカスタムコントローラーの枠組みを知っておくと追いやすくなります。本書では、Knativeはもちろん、Kubernetes自体の様々なソースコードを追いながらそれを解説しています。

以前mercari.goで発表した内容をより詳細に紹介したものです。

目次です。

第1章 KnativeとKuberentesの関係
1.1 Kubernetesの概要
1.2 Kubernetesの拡張方法
1.3 Knative の概要

第2章 KubernetesのAPI
2.1 APIサーバーの責務
2.2 Kind
2.3 APIグループ
2.4 バージョン
2.5 リソースとサブリソース
2.6 APIリクエストの処理フロー

第3章 APIクライアント
3.1 client-go
3.2 Object
3.2.1 TypeMeta
3.2.2 ObjectMeta
3.2.3 Spec
3.2.4 Status
3.3 ClientSet
3.4 Informer
3.5 APIMachinery
3.5.1 Scheme
3.5.2 RESTMapper

第4章 カスタムリソース
4.1 CR
4.2 CRD
4.2.1 categories
4.2.2 shortNames
4.2.3 subresources
4.2.4 additionalPrinterColumns

引き続き電子版、紙本 + 電子版がBOOTHで購入できる状態になっています。

https://toshi0607.booth.pm/items/1568456

正誤表や増補改訂情報ページはこちらです。

『Knativeソースコードリーディング入門 〜Knativeで学ぶKubernetesのカスタムリソースとカスタムコントローラー〜』の正誤表と増補改訂情報 #技術書典

『Goで学ぶAWS Lambda 第2版』

技術書典5で出展したAWS Lambdaのユースケースに関する本も引き続き。

AWS Lambda周辺のエコシステムはこの本の最終更新後に大きな変更がありました。Amazon RDS Proxy with AWS Lambda、AWS Lambda VPC接続の改善、Provisioned Concurrency for Lambda Functionsは本の中でも触れられている課題の決定的な解決策です。少し本の内容が古くなってしまったものの、AWS Lambda(とSAM)をGo言語で学ぶ入門の1つとしては依然として有効ではないかと思います。

お陰様で商業版を出版したり、こちらもすでに第2版がBOOTHで購入できる状態になっています。

https://booth.pm/ja/items/1034858

GoとSAMで学ぶAWS Lambda

目次です。

第1章 環境構築
1.1 anyenv
1.2 anyenvupdate
1.3 goenvとGo
1.4 pyenvとPython
1.5 aws-cli
1.6 aws-sam-cli
インストールトラブルシューティング
1.7 saw
1.8 direnv
1.9 dep
1.10 gig

第2章 S3 イベントの活用
2.1 概要
2.2 S3
2.3 シーケンス
2.4 フォルダ構成
2.5 ソースコード
2.6 テスト
2.7 デプロイ
2.8 削除

第3章 SNS と SQS によるファンアウト
3.1 概要
3.2 SQS
3.3 SNS
3.4 シーケンス
3.5 フォルダ構成
3.6 ソースコード
3.7 テスト
3.8 デプロイ
3.9 削除
CloudFormationトラブルシューティング

第4章 API Gateway と DynamoDB を使った URL 短縮サービス
4.1 概要
4.2 APIGateway
4.3 DynamoDB
4.4 シーケンス
4.5 フォルダ構成
4.6 ソースコード
4.7 テスト
4.8 デプロイ
4.9 削除
DynamoDBのテーブル定義変更
LambdaとAPIGatewayのローカル実行