中国のカンファレンスで自社プロダクトを英語で発信してきた
2020/12/20（日）に、中国の「TOP 100 Summit 2020」というカンファレンスで、私たちのチームの新プロダクト「Testable Infra」についてお話させていただきました。
こちらが、カンファレンスの情報になります。
同カンファレンスは、プロダクトマネジメント・テスト・DevOps・SREなど、ソフトウェア開発の幅広い領域の事例を100個集め、それらを4日間かけて発表し合うという、なかなか大規模でガチ幻想をかき立てられるものです。
私のセッションの情報はこちらです。
（バナーは上と同じに見えますが、きちんと個別ページにジャンプします）
こちらが、私の発表資料になります。
今回は、登壇の経緯と、登壇に際して工夫した点を、今後海外で英語でプレゼンしたい！という日本の方むけに説明させていただきます。
加えて、今回発表させていただいた「Testable Infra」のポイントを、アジャイル・テスト自動化・Kubernetesのいずれかに興味ある方むけに説明させていただきます。
1. 登壇の経緯
過去に同カンファレンスに登壇したことのある、台湾の同僚からの紹介がきっかけでした。カンファレンス主催者から彼のもとに「スピーカー候補いませんか？」という打診があり、ちょうど登壇予定だったアメリカのAgile2020がキャンセルになって力を持て余していた私に白羽の矢が立ちました。
※ちなみにAgile2020についての詳細はコチラです
今回は、以下の要因が組み合わさって、登壇の機会を得ることができました。
- 私自身、社内外・国内外での登壇経験があること
- カンファレンスでの登壇経験のある、外国籍の同僚が身近にいたこと
- 登壇に関心がある者同士として、「類友」の関係を築けていたこと
2. 登壇に際して工夫した点
今回は、特に以下の3点を工夫しました。
1) 英語のプレゼン動画での反復練習
特にカンファレンスでのプレゼンならではの英語の言い回しのレベルを高めようと、Youtubeなどにあがっているプレゼン動画を何度も観て、そこで気がついた点を反復練習して、自身の発表に取り入れました。加えて、今回の発表はKubernetesの比率が高かったため、KubeCon（Kubernetesのグローバルカンファレンス）の動画を特に観ました。
2) 関連トピックの会話に慣れる
プレゼンだけではなく、関連トピックのカジュアルな会話や語彙にも慣れようと、特にこちらのPodcastを頻繁に聴いていました。
3) 社内で素振り
本番前に、社内の所属部署で「事例紹介」と称して、発表練習をさせてもらいました。素振りなので失敗しても安心ですし、発表経験自体も積めるので、メリットが非常に大きいです。
また、機会をくれた同僚に対して、お礼と準備万端であることの両方を伝える意図も兼ねました。
3. 「Testable Infra」のポイント
ここでは、発表させていただいた「Testable Infra」のポイントを、3つ紹介させていただきます。
1) テストのし辛さを生み出す3つの要素
これまで長年、様々な会社・プロダクトで、「テストがし辛くてバグを見逃して障害を起こしてしまった」事例と向き合ってきました。それらを整理・分析すると、大体次の3つのいずれか／どれもが原因であることが多いです。
- テスト環境：環境自体がない、準備が面倒、環境ごとの差分が大きすぎてテストを信頼できなくなる
- テストデータ：他の人と共有するとテストを壊す／壊される恐れが高い
- 外部システム：準備しづらい、環境ごとの接続設定の変更が面倒
2) 「Immutable Infrastructure」をCloud-nativeに実現
様々な試行錯誤を繰り返した結果、「Immutable Infrastructure」の考え方を、Docker・Kubernetes・Istioなどを組み合わせることで、上記の問題を解決できるのでは？との考えに至り、「Testable Infra」を構築してみました。
具体的には、Pull Requestが作成されたら、それをテストするために必要なDockerコンテナを作成し、それらをテスト用に作成したKubernetesのnamespace上にdeployし、そこに対してE2E Testを実行する仕組みをまず構築しました。
3) 構築・運用の際の工夫
新規の試みだったことから、以下の手法を組み合わせることで、構築・運用をより「効果的」にしました。
- 開発初期からDevOpsの仕組みを構築し、必要な時に最新の動作するソフトウェアを見せられるようにした
- 「Product Discovery」や「Design Sprint」を活用して、仮説設定・検証を繰り返した
- 失敗を学習機会として積極活用し、プロダクト・プロセスの改善につなげた
※「Testable Infra」の概要については、こちらもご覧ください。
さいごに
日本での登壇も工夫する点や面白いことは多いですが、海外で母国語以外で登壇するとなると、その国の文化や言語ならではの言い回しなどにも工夫の余地が出て面白いです。
また、昨今はコロナの影響もあって、「Zoomなどのビデオ会議システムで時差さえ埋められれば国籍を超えて登壇しやすい」という状況でもあります。
コロナには最新の注意を払っていく必要がありますが、一方で新たに生まれた機会は、積極的に利用しても良いと思います。
アジャイルコーチ同士のスクラムガイド雑談会2020
2020年11月18日（水）に、スクラムガイドの最新版がリリースされました。
それを受けまして、アジャイルコーチの中村 洋さんからお声がけいただき、11月23日（月）朝に同ガイドの内容に関する雑談（1 on 1）をさせていただきました。
1時間半を超える熱のこもった内容になりましたので、せっかくですので内容を備忘録として書き出してみました。同ガイドの読み方・解釈方法の1意見として読んでいただければ幸いです。
ちなみに、中村さんは日本語版を、私は英語版を読んだ上での雑談です。その違いも含めて楽しんでいただければ〜
1. スクラムガイドの目的
スクラムの核となるデザインやアイデアを変更したり、要素を省略したり、スクラムのルールに従わなかったりすると、問題が隠蔽され、スクラムの利点が制限される。 （日本語版 1ページ）
- （中村）この「問題が隠蔽され」という点は、スクラムに取り組む理由の一つとして（自分自身がコーチ先のチームなどに）説明することがある。
- （伊藤）この記述を含め、今回のガイドは全体的に透明性・検査・適応とその相関関係とを強調している印象。
2. スクラムの定義
スクラムとは次の環境を促進するためにスクラムマスターを必要とするものである。 （日本語版 4ページ）
- （中村）スクラムマスターの必要性を明記している点が興味深い。単なる会議のファシリテーターとかではないことを強調する必要が出てきたのかも？
- （伊藤）それは確かにありそう。一方で、各ロールとその相関関係を含め、文字通りここで「スクラムの定義」を簡潔にまとめ、全体の見通しを良くしようという著者の強い意図を感じた。
スクラムフレームワークは意図的に不完全なものであり （日本語版 4ページ）
- （中村）「不完全」の解釈が分かれそう。自分は、1) プロダクトバックログの書き方や使用ツールといった、実践方法の詳細を明示していないという意味合いと、2) 仮説設定・検証やマーケティングなど、スクラムの「外側」のプロセスを明記していないことと捉えた。
- （伊藤）自分は、「イノベーションのチャンス」と解釈した。スクラムはフレームワークのベースラインだけの定義にとどめているため、実践時は各ドメイン・プロダクトに合わせた肉付けが必要。そこに各実践者の工夫や、スクラム自体を豊かにする余地があるのだと捉えた。
3. スクラムの理論
「リーン思考」の「リーン」は、「ムダを省き」という記述があるので、「リーンスタートアップ」ではなく「リーンソフトウェア開発」を指すだろう。
4. スクラムの価値基準
スクラムチームのメンバーは、スクラムのイベントや作成物を用いながら、これらの価値基準を学習および探求する。 （日本語版 5ページ）
- （中村）日本だと、（確約・集中・公開・尊敬・勇気といった）価値基準及びそれらの学習・探求の必要性をあまり明言していない印象。
- （伊藤）確かに日本では、これらを明示的に話していないかも。そういえば、Kubernetes Podcast from Googleなどを聞いていると、海外の団体・コミュニティなどでは、これらの重要性を明言していることが多いかも。
- （中村）日本のSIer所属のアジャイルコーチをみていると、こうした発想自体を持っているのか疑問に思うこともある。
- （伊藤）日本のSIerだと、一定期間過ぎたらチームが解散する「プロジェクト」の思考に馴れていることが多くて、中長期的思考を持ちづらいということはあるかも。
5. スクラムチーム
自己管理型であり、誰が何を、いつ、どのように行うかをスクラムチーム内で決定する。 （日本語版 6ページ）
自己「組織化」から自己「管理型」に記述が変更されている。意思決定の責務を、（POを含む）スクラムチームとして持つことを明示したのでは？
スクラムチームは、ステークホルダーとのコラボレーション、検証、保守、運用、実験、研究開発など、プロダクトに関して必要となり得るすべての活動に責任を持つ。 （日本語版 6ページ）
- （中村）「すべての活動」とはどこまでを指すのか？例えば「検証」は、リサーチャーが行うプロダクトの仮説設定・検証を指すのか？
- （伊藤）仮説設定・検証も含めて「すべて」ではないか？ちなみに（会社の）自分のチームでは、大変ではあるがこれらをすべてやっている。
- （中村）「責任を持つ」の記述が重要。他チームなどに助けを求めてでも「活動に責任を持つ」という意味であって、自分たちが実施する責任（＝自力でやらなければならない）という意味ではないと思う。
- （伊藤）ですね〜
5.1. 開発者
完成の定義を忠実に守ることにより品質を作り込む。 （日本語版 6ページ）
「完成の定義」という言葉がここに出てくるようになったことは、大きな変化だと思う。プロダクトの「作り込み」を強調する意図があるのかも。
一方で「品質の作り込み」は、スクラムガイドだけでは情報不足。ソフトウェア開発ならば、XP・CI/CD・DevOpsなどを取り入れる必要がある。
5.2. プロダクトオーナー
プロダクトゴールを策定し、明示的に伝える。 （日本語版 7ページ）
- （中村）「プロダクトゴール」を明記するようになったのは、スプリントだけを回して結果プロダクトのゴールを見失いがちになるスクラムチームが多かったからかも？
- （伊藤）それはありそう。書籍『A Scrum Book』でも、プロダクトバックログのインプットとしてのVisionやProduct Roadmapに多くの記述を割いていた。
A Scrum Book: The Spirit of the Game
- 作者:Sutherland, Jeff,Coplien, James O.,Heasman, Lachlan,den Hollander, Mark,Ramos, Cesario Oliveira
- 発売日: 2019/09/03
- メディア: ペーパーバック
5.3. スクラムマスター
スクラムマスターは、スクラムチームと、より大きな組織に奉仕する真のリーダーである。 （日本語版 7ページ）
- （中村）「組織へのリーダーシップ」を明示したことは、大きな変化だと思う。チーム内だけに留まって、本来の価値を発揮していないスクラムマスターが多かったのでは？
- （伊藤）それはありそう。私たちはJames Coplienさんの認定スクラムマスター研修を一緒に受講して、Red Pill、既存の枠組みを外れてでも貢献する重要性を叩き込まれたので、「組織へのリーダーシップ」が当たり前になっている。それを全員が持っているわけではないので、明示には意味があると思う。
6. スクラムイベント
6.1. スプリント
スプリントゴールの達成を危険にさらすような変更はしない。 （日本語版 8ページ）
- （中村）「危険にさらすような変更」には、どのようなものがあるか？
- （伊藤）（考慮不足の）APIの破壊的変更など、スプリント内では対応しきれないようなうっかり追加作業。CI/CDをやっていると予防はできる。やはりスクラムガイドだけでは不足かも？
すでに発生したことだけが、将来を見据えた意思決定に使用できる。 （日本語版 9ページ）
- （中村）一連の文章で言いたいことはなんだろうか？（日本語の文章がやや複雑）
- （伊藤）メトリクスなどの「過去の」実績情報をベースに、経験主義的に行動しましょうという程度の意味では？（英語で読んだから詰まらなかった？）
6.2. スプリントプランニング
キャパシティ （日本語版 10ページ）
- （中村）「キャパシティ」は、時間・日数の意味か？
- （伊藤）Capability、学習の要素なども含む、広い意味での「能力」の意味合いではないか？自分がコーチングをする場合は、これを伸ばすタスクを意図的に追加したりしている。
6.3. デイリースクラム
プロダクトオーナーまたはスクラムマスターがスプリントバックログのアイテムに積極的に取り組んでいる場合は、開発者として参加する。 （日本語版 10ページ）
- （中村）これは、（本来は禁止されているはずの）ロールの兼任をしろという意味なのか？
- （伊藤）帽子の被り直し程度の意味では？デイリースクラムの参加者を開発者に限定している旨の、前段の記述とも符合する。
6.4. スプリントレトロスペクティブ
スプリントレトロスペクティブの目的は、品質と効果を高める方法を計画することである。 （日本語版 11ページ）
「効果」は、プロダクトとプロセスの両方を指す。
スクラムチームを迷わせた仮説があれば特定し、その真因を探求する。 （日本語版 11ページ）
「仮説」は、プロダクトとプロセスの両方を指す。
スクラムチームは、自分たちの効果を改善するために最も役立つ変更を特定する。最も影響の大きな改善は、できるだけ早く対処する。 （日本語版 11ページ）
- （中村）「最も」と明記しているのは、改善項目をたくさん実施しても無駄が多いなどの点を指摘している？
- （伊藤）おそらくそう。TOC（Theory of Constraints、制約理論）の、「多くの問題は、少数の原因による」という考え方と同じではないか？
7. スクラムの作成物
プロダクトゴールは、スクラムチームの⻑期的な目標である。次の目標に移る前に、スクラムチームはひとつの目標を達成(または放棄)しなければならない。 （日本語版 12ページ）
- （伊藤）「達成または放棄」とは、プロダクトのPivot（方針変換）のことを指すのではないか？
スプリントゴールはスプリントの唯一の目的である。 （日本語版 12ページ）
- （中村）スプリントゴールは、1つにした方が良いでは？
- （伊藤）同意。もし複数必要になる場合は、ゴール間の優先度設定が重要。
7.1. インクリメント
また、すべてのインクリメントが連携して機能することを保証するために、徹底的に検証する必要がある。 （日本語版 13ページ）
- （中村）「徹底的に」という言葉が興味深い。リグレッションテストの重要性と、技術的プラクティスを軽視する近年の風潮への警鐘の意味合いがあるのでは？
- （伊藤）同意。技術的プラクティスがあって初めて、スクラムガイドが示す「徹底的な検証」ができる。
8. 全体
自分たちのような経験を積んだ実践者にとっては読みやすくなった一方で、初学者にとっては曖昧すぎて読みづらい内容になっているかも？
- 経験のあるコーチが、初学者とペアないしモブを組んで教えることを「前提」としないと辛いかも？
- 一方で、コーチの知識・経験を活かして初学者を導くスキームが想定されているかも
- 聖書と牧師さんの関係が似ているかも
最後に
同じアジャイル実践者でも、積んできた経験の差でこれだけ解釈が割れるのかという驚きと、その解釈の差を共有し合うことでさらに理解を深められる面白さの両方を体感できました。
このような雑談は、是非皆さんにもお勧めしたいです。
機会をくださった中村さんに感謝です！
Coderetreatに齢45にして初参加
2020年11月7日（土）に、こちらのイベントに参加させていただきました〜
ここ最近の週末は、GolangでLeetCodeの問題を解くか、Kubernetesのclient-goのソースリーディング・動作確認を続けています。一方で、ずっとひとりで学習を続けているので、たまには違った視点が欲しいなと思い、腕試しを兼ねて同イベントに参加してみました。
イベント概要
平たくいうと、ライフゲームというお題をみんなで実装してみましょうというものです。
但し、以下のようなルール・制約があります。
- 実装45分、振り返り15分の計60分のサイクルを、6回繰り返す
- 使用する言語・開発環境は自由
- 基本はペアプロ、慣れたり気分転換したくなったらモブプログラミングで！
- 45分経ったら、そのコードは破棄！
45分ごとに頭も気持ちもコードもリセットするため、いろいろなチャレンジができるチャンスでもあります。
自身の行動記録
覚えている範囲でメモ。ちなみに開発環境は、TDDのトレーニングで有名なcyber-dojoを主に使用しました。
Iteration 1 : まず慣れる
まずはTDDを忠実に実施することで、ライフゲームの仕様の理解とイベントのルールへの慣れを優先しました。ちなみに、言語・テストツールはJavaScript + Jestでした。
Iteration 2 : 設計を考える
次はJava + JUnitで、オブジェクト指向の観点から設計を意識して進めました。このあたりでライフゲームの実装イメージが掴めた感じ。
Iteration 3 : Golangでやけど
配列操作の都合と、自身が最近学んでいることを試してみたいことから、Golang + testingをチョイス。しかしながら、人数の都合でトリオを組んだメンバーが初Golangだったため、言語の勝手で詰まってしまい、私が言語仕様を説明している間にタイムアップ (´・ω・)
Iteration 4 : Golangおかわり
Iteration 3を受けて、Golangを試したい！という方が他にもいたため、再度チャレンジ。
最初の5分は、時間の節約と言語仕様の説明を兼ねて、私がIteration 3での実装内容を復元し、残りの時間でみんなでワイワイする形に。完了のイメージがはっきりと見えてきたところでタイムアップ。45分はかなり短い。
Iteration 5 : Clojureに散る
なぜかClojureをやろうということになって、モブプログラミングで試したものの… そもそも書き方が分からない、知りたいことがまるで検索で引っかからない（ググラビリティの低さ）、説明を読んでも意味が分からないと、文字通りの完敗。
Iteration 6 : Pythonで完成
最後は全員でモブプログラミング。リスト内包実装など様々なテクニックを皆さんから教えてもらい、時間内についに完成！
ちなみに私は、純粋に体力が尽きてしまい、このiteration途中でコーディングから離脱してアイデア出し係に。6 iterationはかなりハード。
感想
- 参加者と運営の皆さんのホスピタリティのおかげで、45歳でも多くのことを学べました。感謝。
- Golangの独習内容は、他者に説明できるレベルになっていたことを確認できました。
- 久々に会社以外のIT系の人と直に話せたため、かなりのリフレッシュになりました。
おまけ
株式会社アトラクタ様のおかげで、美味しいハンバーガーをいただきました。本当に感謝です。
お店はこちら。
Kubernetes Novice Tokyo #5でLTをさせていただきました
自身のKubernetes力を磨こうと、9/29（火）に「Kubernetes Novice Tokyo #5」というイベントでLTをさせていただきました。
Kubernetes関連のコミュニティ・イベントでは、初の登壇になります。
発表資料は、コチラになります。
私たちのチームが現在絶賛構築・運用しているKubernetesベースのテスト用インフラである「Testable Infra」について、自身の情報整理とコミュニティからのフィードバックを得ることを目的にお話させていただきました。
ちなみに、10分という発表時間と、CNCF系OSSのコミッターから「Kubernetesをそういう目的で使うという発想はなかった」と以前言われたことがあったことから、今回は概要レベルの説明にとどめています。
このイベントで得たもの
1) 大将さんから教えていただいた、1つのLoadBalancerを用意して配下のクラスタ群を切り替え可能にするアイデアを早速活用して、Kubernetesリソースの削減とTestable Infra自体のパフォーマンス向上につなげられています。
2) mikiさんの発表を参考に、私もKubernetesのclient-goのソースリーディングを始めました。
さいごに
別イベントから登壇依頼が届きまして、Testable Infraの技術詳細や構築・運用時のTipsなどを現在絶賛整理中です。近々みなさまにも共有できると思います。
RSGT2021に登壇できます！
多くの方の応援をいただき、Regional Scrum Gathering℠ Tokyo 2021（以下「RSGT2021」）のプロポーザルが通りました〜！
ちなみに、私のプロポーザルは↓コチラ↓になります。
Regional Scrum Gathering Tokyo 2021 - Tips of Product Management for Internal Tools／社内ツール・サービス・プラットフォームにおけるプロダクトマネジメントの勘所 | ConfEngine - Conference Platform
さて今回は、このプロポーザルの狙いを、簡潔に5分以内で読めるようにまとめてみました。
1. 自身のプロダクトマネジメントの知見を整理しフィードバックを得たい
ここ1年ほど、特に社内ツール・インフラの設計・開発に加えて、プロダクトマネジメントもやる必要が出てきました。
その際にぶつかった課題、試行錯誤して失敗した点／うまくいった点を整理し、みなさまからのフィードバックをいただいて洗練していきたいと思っています。
もちろんその結果として、現在担当している社内ツール・インフラをより確かなものに育てていく所存です。
2. 世界的な知見不足を埋めたい
今年5月に公開された、ThoughtWorks社のIT業界トレンドレポート『Technology Radar (Vol.22)』を読んだところ、以下の記述に特に目が止まりました。
要点としては、
- 社内ツール・インフラにプロダクトマネジメントの考え方を適用するトレンドが世界的にみられること
- 一方で、社内ツール・インフラならではの知見・方法論などの整理はこれから
というものです。
私は基本、スペースを見つけて走り込むタイプ（ゴールを決められるかはまた別）なので、これはチャンスだと思い、このレポートを読んだ直後からこのプロポーザルを書き始めていました。
3. Agile2021の公募にも挑戦したい
今年のRSGT2020で試したところ「行けた」ので、今回も狙ってみようと思います。
昨年は、Regional Scrum Gathering Tokyo 2020 - 特殊部隊SETチームの日常 - 技術と実験を融合した実践アジャイル術 - | ConfEngine - Conference Platformと題してお話させていただきました。
そこで皆様からいただいたフィードバックを活かして、Agile2020にプロポーザルを出したところ、なんとかacceptされました。
- 倍率は、7-8倍ほどでした。
- ちなみにイベントは、新型コロナの影響で中止となりました。結果として幻のスピーカー扱いに。
発表資料はコチラです。
せっかく資料を作ったので、日本国内で発表をした際の内容を、ログミーさんにまとめていただきました。
ちなみに、Agile2020の公募の経緯については、コチラもご覧ください〜
さいごに
新型コロナで鬱屈した気持ちを、少しでもみなさまとともにカンファレンスの場で発散できれば！
ウィズコロナ＆ニューノーマルな生活の過ぎたるイチ事例
在宅勤務とストイックな生活をしすぎて体調を崩していると、先日医師に診断されました。
ただ、症状的に何が原因でどう対処すれば良かったのかが分かりづらいものだったので、似たような症状で困っている方のプラスになればと思い、症状・原因・対応策をまとめてみました。
症状
- 7月頃から、左手の人差し指・中指に痛み・違和感が出てきました。
- 7-8月頃から、肩こりが慢性的になり、どんなにストレッチをしても効かない状況になりました。
- 8月中旬頃から、両耳、特に右耳が聴こえなくなってきました。
- 特に右耳は、カパカパするような違和感に悩まされています。
- ギターなどの弦を弾いたような、謎の異音が聴こえるようになっていました。
- 9月以降、めまいと吐き気も出てきています。
めまいと吐き気の段階で「何かマズイ」と判断し、急ぎ鍼灸院と耳鼻咽喉科を受診しました。
原因と対策
- 背骨がねじれた状態になっていて、全身、特に首回りに大きな負荷が掛かり、結果肩や指を含む全身の痛みにつながっていることが分かりました。
- 生まれつき猫背だったことに加え、在宅勤務の長期化で、負担のかかる姿勢で長時間PCに向かい過ぎたことが原因とのことでした。
- 背骨を整体的に矯正し、現在も継続的に鍼・マッサージを続けています。
- 「耳管」という器官に障害が起きていて、めまい・吐き気につながっていると思われるとのことでした。
- これは、急激に体重を減らしたりすると、たまに起きる症状とのことです。（確かに今年に入ってから10kg以上減量している最中でした）
- ちなみに、脳は健康とのことでした。
- 右耳に1cm強の髪の毛が刺さっていて、これが異音につながっていました。（すぐに除去してもらいました）
- 在宅勤務で外出を避け続けたこと、また仕事に集中し過ぎてしまったため、メンタルが気付かぬ間にダメージを受けていたとのことでした。
- 確かに半年ほど、新型コロナ対策を忠実に守って、自宅近辺以外の外出を一切していませんでした。結果的に、仕事だけを突き詰めるライフスタイルになり、思考・メンタルの幅を狭めてしまっていました。
- 早速今日、無理やり外出をして、気分転換を始めています。
さいごに
ウィズコロナ＆ニューノーマルな生活には、新しいメリットもたくさんある一方で、未知というか気付きづらい心身のダメージもあるようです。それらの原因と対策を見つけて集めて共有し合うことは必要だと、文字通り痛い目にあって痛感した次第です。
参考情報
鍼灸院で使っているストレッチポールです。背骨・首回りの痛みを、以前よりも軽減できています。
- メディア: スポーツ用品
気分転換を意識して行うことの重要性とそのテクニックが、詳細にまとめられている一冊です。
サーチ・インサイド・ユアセルフ ― 仕事と人生を飛躍させるグーグルのマインドフルネス実践法
- 作者:チャディー・メン・タン,一般社団法人マインドフルリーダーシップインスティテュート
- 発売日: 2016/05/17
- メディア: Kindle版
怒りやストレスの原因を見つけて解消するための技術が、簡潔にまとめられています。
おまけ：半年ぶりの外出
虎ノ門ヒルズ駅。まだ絶賛工事中。
虎ノ門ヒルズ本体。発展はこれからな模様。
愛宕神社にあった龍の像の出来栄えが見事
"Kubernetes the Hard Way"を完走しました
同僚に勧められて、GW早々"Kubernetes the Hard Way"を全てやりきりました！
"Kubernetes the Hard Way"とは
Dockerなどのコンテナの管理ツールとしてデファクトスタンダードになりつつあるKubernetesを、インストーラー任せにせずに、自力で必要なコンポーネントやクラスタ全てをセットアップして動作させるようにするという、一種の学習ツールです。
Google Cloud Platform (GCP)とGoogle Cloud SDKを使用して、インスタンス作成やネットワーク設定などを行う必要があるため、これらの学習教材としても有用です。
動機
大きく3つあります。
1. 実務でのKubernetesの利用が普通になってきた
ここ数年、社内でDockerの普及が進み、これらの管理のためにKubernetesの利用が普通になってきたことがあります。であれば、詳しく知りたくなりますよね〜
2. 書籍や公式ドキュメントだけでは理解しきれないところがあった
これは私だけの可能性がありますが、Kubernetesの書籍や公式ドキュメントを読んで動かし続けていたのですが、いまいちピンとこないところが多々ありました。 例えば、KubernetesのControl Planeは
で構成されていると公式ドキュメントにはありますが、これらには具体的にどのような設定が必要なのか？どのように連携し合って全体としての機能を提供できるのか？といったレベルまで理解しきれず、悶々としていました。
3. 以前から試してみたいことがあった
加えて、以前からDockerとKubernetesとを活用して、既存のテスト環境を（テストデータ込みで）必要な時に複製・破棄できる仕組み（チーム内では「Testable Infra」または「Testable and Disposable Infrastructure」と呼称しています）を作ろうと画策していまして、その実装やトラブルシューティングに、Kubernetesの内部構造の詳細な知識が必要だったこともあります。
やってみて分かったこと
1. 内部の詳細を体得できた
実際に手を動かすことで、以下のことを理解もとい「体得」することができました。（個人的な動機に叶うものでした）
- 各コンポーネントを動かすために、どのような設定ファイルが必要で、どのクラスタのどのディレクトリに置けば良いか？
- 各コンポーネントをLinuxのサービスとして動かすために、それぞれどのような設定が必要か？
- 各コンポーネント・クラスタ間の通信で、認証や暗号化がどう関わっているのか？またそのためにどのような設定が必要か？
2. トラブルシューティングができた
指示通りに設定したにも関わらず、kube-apiserverの起動に失敗するトラブルに遭遇し、原因究明およびトラブルを解決するという経験ができました。
トラブルシューティングの詳細は、下記GitHub Issueとしてまとめておきました。
「ツール系の学習にはトラブルシューティングが最適だ」と、昔会社の先輩に言われたことがありましたが、まさにそうでした。トラブルシューティングは、課題発見・解決力を磨く強力なツールです。
3. GCPの費用と節約方法が分かった
"Kubernetes the Hard Way"のREADMEには、GCPの費用の目安として
$0.23 per hour ($5.46 per day)
とありますが、必要時以外にGCPの各種リソースを停止・削除しておけば、1日あたり200-300円程度に抑えられました。
（インスタンスやネットワーク設定は、停止しているだけでは課金されるんですね〜）
まとめ
完走した感想ですが、Kubernetesのドキュメントやコードを追うことや、日々の業務で活用することももちろん有益ですが、より理解を深めるためにこれを試すのは、大いにありだと思います。 GW & Stay Homeなこのタイミング、実はこうしたことを試す／学ぶ良い機会かもしれません。
