2021年プラットフォームエンジニア2年目のふりかえり

0 Shares

プラットフォームエンジニア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が別、プラットフォームチームが領域毎に別だったなど、メルカリの組織と性質・フェーズが異なるので、より広い役割が求められるでしょう。これまで経験のないことも、素早くキャッチアップして貢献していこうと思います。

0 Shares

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です