LINEヤフーを退職します

本日社内発令とのことで、退職エントリを書きます。

3/2発令、4/15退職です。退職理由は出社頻度の増加が急すぎて家庭側の負荷を吸収しきれないと判断したのが7割で、残りはノリです。

以下は「僕、大分頑張ったな〜」っていう振り返りなので、そういうノリが苦手な人は読まない方がいいかもしれません。

やってきたこと

2019年に当時ヤフーと合併前だったLINEに入社して、社内のプライベートクラウド基盤の開発、運用をやってきました。

(LINEに入るまでの経緯は https://manji0.hatenablog.com/entry/20190615/1560553200 参照)

入社した直後に部署内にSREチームが立ち上がり、当時急拡大していた社内クラウド(以後Verda)でパンクしかけていたデプロイシステムや監視システムを頑張って書き直していたらそのまま3年くらい経過してました。

大量の物理サーバをAnsibleでどう管理するか
JenkinsでAnsibleを実行するときのfork待ちによる長時間デプロイをどう解決するか
膨れ上がる単一Prometheusの負荷をどう軽減するか
散逸するログ/メトリクスのストレージをどう統一するか
年々厳しくなるセキュリティ的な要請に準拠したデータ収集、保存
etc…

のような課題に取り組み、これらを解決した基本的なアイデアや具体的な実装は後日LINEとヤフーの合併後に新しく作られた新クラウドでも多くが流用されています。

最終的には物理サーバで1万台規模、VMなどの仮想リソースを含めると数十万インスタンスという破格の規模での運用になりました。このような取り組みを日々スケールアップし続ける環境で運用まで取り組めたことは大きな経験であり、LINEおよびLINEヤフーのような限られた環境でしか巡り会えない貴重な機会だったなと改めて思います。

LINEでの仕事

入社してしばらくはリリースマネジメントやデプロイコードの改善、監視コンポーネントの開発や運用などを細々としていましたが、しばらくするとSREチームの韓国側の体制が向こうの別チームに完全に吸収されることとなり、主にIaaSが管理していた監視システム全体の面倒を見ることになりました。

当時はVerda全体が急速に拡大していた時期であり、PaaSやDBaaSなどの基盤になっていたIaaS部分の規模は加速度的に広がっていました。日ごとにパンクの予兆が増えていく各種監視コンポーネントに対し、日次でよりスケーラブルな仕組みを考えてデプロイする…みたいなことをやっていた時期もあったなあ。これはいい思い出です。

その頃には組織全体でオンコールを導入したいという議論もあり、上司からすべてを任されてPagerDutyの導入をしたのも印象的な記憶です。

人事制度作りから社用携帯の貸与ルールに至るまで整備し、ネットワーク系のVerdaサービスには自分でローテーションに入りながらアラートの見直しや通知周りのリクエスト対応などを実施していました。

当時はメンバーの全員が裁量労働であり、基本的には深夜対応をする個人的なインセンティブは人事制度上は存在しなかったので、大分頑張って上を説得して待機手当付きの制度を作ったことを覚えています。ちゃんと待機することにインセンティブのある制度設計を通せたのは我ながらいい仕事だったと思います。

LINEに入って2年ほどたったころ、たまたまマネージャー層の辞職が相次いた時期があり、そこでSREチームのマネージャーに任命されました。あまりポジティブな理由ではないですが、まあこうなったらやるしかないです。多分当時では社内でも最も低い年齢層でのマネージャー任命だったと思います。

さて、マネージャーになったタイミングではSREチームは合計で4名しかおらず、できることは限られていました。

前任のマネージャーはSREチームの前身であるOperation Unit…つまるところ組織全体の雑用、調整役という重要であるがテーマを持ち辛い組織運営を継承しており、SREを導入するための基礎を整えるようなスタートラインまで手が回っていなかったという背景もあり、まずは現状の組織名とは異なる期待などを覆せるような大玉を軸に据え、それはそれとして現状抱えていて放置できない仕事は粛々と進められるような組織設計をしなければと感じたことを覚えています。

結果的にはそこから1年弱かけて組織全体のメトリクス、ログのストレージとインターフェースを統一することができ、それぞれのVerdaサービスが個別で運用していたパイプラインの多くの削減を達成しました。

Verdaのあらゆるサービスのメトリクス、ログの形態と量を分析し、貯蔵可能な社内サービスを探したり自分たちで作る場合のコスト試算やPoCをしたり、忙しくもやりがいのある日々でした。

ただ、その過程で当時のシニアマネージャーとのコミュニケーションミス、上に捻じ曲げられたプロジェクトゴールとそれに合わせた方針転換、国を越えた必死の説得…などがあり、その苦労から2年ほど睡眠薬を飲む生活になったりなど、失ったものも多かったです。別に今となってもいい思い出ではないですが、酒の肴にできる程度には飲み込めています。

統合が完了したころ、上司から良くない話を聞くことになります。理由は明確化されませんでしたが、恐らく前任のマネージャーが引き受けていた期待を覆すほどの成果ではなかったのか、それともトラブルによってシニア層から良くない目で見られたのか。

「もはやこのチームはチームを構成する最低人員を満たしていないので解散する」とまで言われましたが、なんとか追加採用にこぎつける&後任のマネージャーに引き継いでチームを存続させることができ、ICとして引き続き監視周りの地道な開発と改善を続けていくことができました。

Verdaの独立したドキュメントサイトを社内に立ち上げたのも確かマネージャー期間だった記憶があります。当時はVerdaのドキュメントが他のあらゆる社内ドキュメントと一緒にオンプレのConfluenceに蓄積されていたのですが、古い情報が消されず山積みになっていたり、執筆のレビュープロセスが整備されていなかったり、そもそものConfluenceの検索機能がとても使い辛かったりしていたのを解消したいという思いから企画したことを覚えています。

Web技術については全く詳しくなかったのですが、Verdaのプロダクトマネジメントチームから大量の指摘を受けて死んだ目でCSSをググりながら調整する日々が続きました。これも結果的には社内に浸透し、今となってはMarkdownで蓄積されたドキュメント資産としてAI活用の重要なユースケースになっているようです。

会社合併の話が本格化していく中、Verdaの新規リージョンを立ち上げるという仕事があったことを覚えています。確か、丁度僕が結婚したくらいの時期だったはずです。

新しいOpenStackのバージョンを使うということでPython2を基本に書かれた既存のデプロイコードがほとんど使えないということが明らかになり、Python3ベースのデプロイコードを2ヶ月で作ることを強行することになり、入籍してから同居開始までの期間はあんまり寝ずに働いていたことを覚えています。

恐らく、k8s manifest含めて2ヶ月で0から3万行も手書きしたことがある人は社内でほとんどいないでしょうし、今後もそんなに書くことはもうないだろうなと思います。

LINEヤフーでの仕事

社内クラウド基盤は合併後のファーストプロダクトとして早急に作り上げないといけないという組織の使命感から、かなりの速度で検討と実装が進められてきました。

僕が具体的に関わり始めたのは確か合併後であり、とにかく監視の仕組みを作ろう、ただし合併後にLINEとヤフーそれぞれのストレージサービスの何を使えるかは定かではない、というところからのスタートでした。

マネージャー時代にLINE側のメトリクスストレージ基盤のチームとは親交が深まっていたので、彼らに協力をお願いしつつ合併会社としての監視統括部署との会議で根回し、クラウド組織側では実装を進めていきました。

Verda時代に監視システムを1から作ったりデプロイコードを死ぬ気で書いた甲斐もあり、かなりの速度でリリースまで進められたと思います。新しいアイデアによって必要なサーバ数はVerdaの実装より1/10くらいに減らすことができました。リリース後の細かな改善もあり、1リージョンで1万HVくらいの規模であれば問題なくスケールするはずです。きっと未来に残ってくれるでしょう。

新クラウドのドキュメント基盤もセットアップを担当し、試験的にAIでのドキュメントレビューを取り入れたりもしました。当時としては新しめの試みだったと思います。ただし、当時組んだレビュー用Github Actionは今思うと出来が微妙なので、誰か直してくれるといいな。

AIに関係するものだと、複数のAI Agentを使って役割を分離する思想とその実装を作ったりもしました。自分のアイデアの後に似たような論文が人気になったりすると気分がいいですね。需要があるものを自発的に検討できたというのは自信になります。

これは若手に引き継いだので、うまく仕上げてくれることを楽しみにしてます。

振り返り

6年強勤めましたが、総じていい労働ができたと思います。振り返ると自分が作ったもので最終形となったものは数年経っても残ってるものがほとんどで、当時却下されたものも結局は提案通りに落ち着いたものもいくつかありますね。ここに書いていないものも沢山作り、沢山残っています。

常に正解を引けたとまでは言いませんが、会社、組織、技術の進歩のフェーズが変わってもそれらがある程度合理的な実装であるとして残り続けているというのは、自分が取り組んできた分野のスコープの設定と自分の考えた結果が肯定されているようで、内心の確かな勲章になっています。

次の職場でも同じかそれ以上にしっかり考えて、長く残る思想や実装を作っていきたいです。

追記 (書きたいことがあったら逐次追記されます)

書いてなかった中で一番の功績はVerdaの半分くらいのサービスでSLIを取るための実装をしたこと & Verda全部のSLOの定義をレビューしたことかもしれないです。
- HTTP method & pathベースで記録を取るために、ほぼすべてのサービスのopenapiスキーマを手書きしました。
組織で最初にAIだけで作ったコンポーネントをリリースしたのも僕が最初だったと思います。1万台くらいのHV * 200個以上のVM flavorに対する容量計算を1秒程度で返すexporterを作りました。
次の職場は入社後にまた記事を書こうと思いますが、裁量労働+フルリモートです。年収はちょっと上がる予定。
- 去年の源泉徴収は育休2ヶ月分を差し引いて1100万くらいでした。入社時が750万だったので、いいペースで上がってたと思います。
第一子が今6ヶ月で、夜泣きもかなりあります。21時~2時くらいまで僕が面倒を見てそこから寝るので、非常に朝が弱い僕には午前中出社はかなり厳しい。おそらく第二子以降も似たようなリズムになるでしょうし。
- 週1出社くらいから段階的に進めてくれてたら転職しなかった可能性はかなり高いです。
有給消化中なので、3~4月頭くらいでの飲み会のお誘いは歓迎です。