なぜTopotal に興味をお持ちいただいたか、その背景を聞かせてください。

2020年前半から SRE の人材採用を進めていましたが、なかなか採用できず SRE の活動を推進するリソースが不足して困っていました。その時に社内から紹介されたのがきっかけです。当時の SRE チームは3名いましたが、緊急かつ重要なものを進めるので手一杯の状況で、急ぎではない重要なタスクを進められていませんでした。

この急ぎではない重要なタスクの1つは、Terraform によるインフラリソースの一括管理です。当時利用していた Terraform のバージョンが古く機能が少なかったため、一部のインフラリソースは管理できず、代替として自前のスクリプト等で対処していました。Terraform の新しいバージョンで提供している新機能を利用するとインフラリソースの一括管理ができることは分かっていましたが、破壊的な大きな変更を伴うバージョンアップだったため、手を付けられていませんでした。 もう1つは、小さな課題が複数積み上がった影響で、インフラリソースの変更に必要以上の工数が掛かることの解消でした。

Topotal さんとの初回の打ち合わせで、創業当初から SRE の領域にフォーカスしていること、SRE としての経験とエンジニア組織作りの経験を伺い、Topotal さんなら任せても大丈夫と感じてお願いすることに決めました。

最初に Terraform のバージョンアップに取り組んだのはなぜですか？

ROBOT PAYMENT の開発チーム全体の方向性として、SRE のリソースが足りない状況のため、開発チームにインフラの構築・運用を積極的に権限移譲するような組織モデルにしていきたいと考えていました。

その方向性の実現には、Terraform のバージョンの古さが大きな障壁となっていました。新しいバージョンであれば容易に管理できることも、古いバージョンのため無理に複雑な仕組みで動かしていました。また、Terraform で管理できる範囲も狭く、開発チームに権限移譲できない状況でした。

Terraform のバージョンアップは後方互換性のないバージョンアップだったため、まとまった多くの工数が必要でした。本番環境や各開発環境の設定状況を変えずにコードを更新する必要があるため、付随する変更すべきポイントを検証し、各環境に対して問題がないかを確認しながら実装していかなければいけません。また、Terraform 化できていないリソースを Terraform の管理下に置く作業も必要でした。

バージョンアップやメンテナンスに集中してリソースを使えばよいのですが、優先度の高い他の業務に追われてしまい、まとまった作業時間を確保するのが難しく手を付けにくい作業でした。

このような背景から、開発チームに移譲できる状況へ進めるために、まず必要となる Terraform のバージョンアップを Topotal さんにお願いしました。

重要性は認識していたものの、負担が大きすぎて手が出しにくい点だったんですね。

実施したい自動化や改善がいろいろありましたが、何をするにもまずバージョンアップという手間の掛かる作業が大きな壁になっていました。

Tearaform のバージョンを最新にしたことで、インフラリソースを Terraform で一括管理できるようになりました。さらに terraform plan の自動化とTerraform のバージョンアップの自動化を実現してもらいました。これに伴い、デプロイ処理も大幅に改善することができました。

この状況まで進んでくると、インフラ構成もコードもデプロイ処理もシンプルになりました。これによって、コードを見れば誰でも分かる状況にできました。バージョンアップからこの数ヶ月で開発チームに移譲できる環境へ近づくことができたのは大きな変化でした。

次に AWS マルチアカウント化に着手していますよね。

はい。ROBOT PAYMENT も開発チームの拡大に合わせて、権限設定の問題や事故防止の観点から、AWS のアカウントの分離を実現したいと考えていました。ですが、デプロイフローで Jenkins を使っていたため、マルチアカウントにしにくい状況がありました。

そのため、Jenkins から CodeBuild や CodePipeline に移行してもらった上で、各 AWS アカウントに横展開できるように Terraform 化を進めています。

話は変わるのですが、毎週の定例会で技術的な雑談が盛り上がっていると聞いています。

私も技術的な雑談で盛り上がるのは楽しいです（笑）。私1人でプロダクトを担当している状況なので、施策の方針や考えを誰かに相談したくなることがあります。そんな時には定例会で壁打ちやアドバイス、レビューをしてもらっています。Topotal さんの手厚く内容の濃いレビューは特に助かっています。

他にも、その週に発生した課題やその調査・対策について相談しています。その際、Topotal さんの持っている知見を共有してもらっています。自社以外の事例を知るという意味ではパブリックな勉強会でもいいかもしれませんが、事例を踏まえた上で「当社に合った対策は何か」という点で話ができるので、とても参考になっています。

SRE チームや社内には変化がありましたか？

プロダクトの観点から見ると、SRE のチームが実現したかったことが進んだ結果、可用性と信頼性が向上しています。

Topotal さんの作業と並行して、社内では SLO の設定や可視化を進めていました。SLO の設定や可視化を進めたことで、プロダクトの信頼性を向上していく施策を開発全体で取り組めるようになりました。その結果、プロダクトの価値が向上していることを感じています。他にも、セキュリティ対策やインシデント対策も計画を立てて進められています。

社内では重要かつ緊急度が高い作業を行い、Topotal さんに手間の掛かる作業を並行して進めてもらえているので、どんどんよくなっている実感があります。

Terraform のバージョンアップを Topotal さんに任せたおかげで、サービスやプロダクトに近い課題、よりやるべきことに集中できました。特に SLO の策定は最も大きなトピックで、これを進めることができて本当によかったです。

Topotal さんに対する印象の変化もありました。はじめは、外の組織というようなニュアンスが強いかなと思っていたので、システムのコアとなるような部分、特に挙動や仕組みを把握しておく必要がある部分については社内で行う方針でした。ですが、Topotal さんが実装したものをこちらでレビューするという分担でやりとりを続けているうちに、社内外の区別を意識する必要はないなと思いました。

理由は、実装の意図やレビュー、Topotal さんの知見などの様々な情報をドキュメントという残るかたちで提供してもらっているためです。このドキュメントのおかげで、社内での知見の共有もしやすくなりました。

最後に Topotal へひとことお願いします。

全体的な感想でいうと、非常に助かっています。定例での議論や雑談などのコミュニケーションに加えて、SRE のスペシャリストと日々開発を一緒に進められること自体が SRE チームの底上げにつながっています。何よりも、楽しく仕事をやらせてもらっているのが私としてはすごくうれしいです。今後もこの関係を続けたいと思っています。

私としても非常に助かっています。Topotal さんに期待してることは、Topotal さんならではの他社事例も踏まえた経験や知見を共有してもらうことです。それによって私たちだけでは得られない「それぞれの現場の課題感」を知見として取り入れていきたいと思っています。また、当社の事業の成長にインパクトを与える SRE の活動にフォーカスしてどんどん提案をいただきたいです。

本日はありがとうございました。