インタビューのご快諾ありがとうございます。早速ですが、Topotal にお問い合わせいただいた背景からお聞かせください。

問い合わせしたのは2021年の12月ごろですね。開発チームのメンバーが増え、開発効率と開発体験の向上に取り組むと効果が出やすい規模になったので、 SRE チームの発足を検討していました。

インフラ周りの対応をできるメンバーも多く、社内のメンバーで SRE チームの発足を検討しました。しかし、社内のメンバーは機能開発を最優先とし、「開発効率と開発体験の向上」を一緒に手伝って進めてもらえるパートナーを探すことにしました。その中で Topotal さんを知りました。

Topotal を選んだ主な理由を教えてください。

企業規模は気にせず、SRE の支援サービスをいろいろ比較しました。比較したポイントは、「自分たちのニーズに合っているか」と「どれだけ課題に向き合ってくれるか」の2つです。

「自分たちのニーズに合っているか」について、具体的には継続的な改善をしてもらえるかを重視していました。プロジェクト単位で支援をする会社さんがある一方で、Topotal さんは継続的な支援を前提にしていました。 また、「どれだけ課題に向き合ってくれるか」については、1つの課題に対してなぜこの課題に打ち込むかをディスカッションを通じて深掘りし、一緒に考えてくれるかを重視していました。

Topotal さんと打ち合わせをしたときに、課題ごとの重要度を深く理解いただき、一緒にディスカッションしながら伴走するイメージが持てましたし、実際にプロジェクトを進めていくときにも納得感を持って進めたところがとてもよかったです。

実際の支援が始まってからの印象はいかがでしたか。

当時の会議録をさかのぼってみたところ、初手として「本当に解きたい課題は何か」「解決には何をすべきか」「どういう順序ですべきか」を検証して絞り込むフェーズがあり、その期間は1〜2週間程度でした。検証した内容は、社内の誰もが分かるドキュメントにまとめていただいて、とても助かりました。

そうなんです。Topotal さんは、「どうしてこのようなアーキテクチャにしたか」「なぜこのような構成を今から作ろうとしているか」という背景や思想を、 SRE チームに新規加入した人や SRE 活動に興味はあっても把握ができていない人が理解できるドキュメントに仕上げてくれました。

実は Topotal さんと一緒にプロジェクトを始めるとき「SRE チームはまだ活動も人も少ないが、活動を増やしたいし巻き込んでいく人を増やすことも考えていきたい」と話していました。その意図を汲んでもらえてとてもよかったです。

ディスカッションを通じて最初に支援に着手したのは、モニタリング基盤でした。モニタリング基盤を優先した背景を教えてください。

ディスカッションを通じて、私たちが本当にやりたかったのは「リリースやデプロイの頻度をもっと加速して、より安全にかつ効率よくリリースやデプロイをしていきたい」ということだと見えてきました。

この目的を達成するためには、現状の基盤は安定稼働しているのかどうかを把握をする必要があります。現状を把握することで、目的を達成するための課題と打ち手を考えられます。そういった背景もあり、モニタリング基盤に着手してもらいました。

監視実装の部分は骨が折れる作業も多く、単純に AWS の1リソースを直すだけにとどまらず全体的な修正が必要になるという難しさがありました。 Topotal さんに実態をお伝えし、コストや効率を勘案して打ち手の順序の筋道を立ててもらいました。

しかも単純に作業をするだけでなく、打ち手にどんなメリット・デメリットがあるのかを説明したうえで進めてくれました。 SRE の専門家としてロードマップを立て、社内のメンバーが納得感を持ったうえで進めてもらえたので、すごく安心できましたし、やりやすかったです。

一緒に仕事を進めていて安心感もありましたし、知見のある人から筋道を立ててもらえて最短ルートを取ることができたと思います。

モニタリング基盤後の次は、Amazon ECS の移行を予定していましたが、 SLI/SLO の整備の優先順位を上げる判断をされました。

これはモニタリング基盤を先に着手したおかげで判断できました。今の環境をモニタリングすると、システム基盤の安定性はそこまで問題になっていないことに気づきました。この気づきは非常に大きかったです。

もちろん、メンテナンス性や運用の観点ではもともとの基盤よりも Amazon ECS へ移行した方がよいのですが、今の基盤でもデメリットがないと分かったので SLI/SLO の整備を優先しました。

SLI/SLO の整備は、モニタリング基盤で計測している情報をより広い範囲に共有していきたいという考えから着手しました。特に経営層や営業系の方にも EventHub のシステムの状況を共有できる指標について、 Topotal さんと話しながら定義していきました。

具体的には、どのような指標を決めたのですか？

そうですね、一般的に用いられる「稼働率」のほか、弊社のサービスは「レスポンス」の2点を計測しています。特に稼働率は計測してみるとかなりよい数値でした。安定性の高さが指標として提示できるようになったので、攻めたリリースができそうだという結論になりました。

SLI/SLO の整備によって、リリースを積極的にやっていこうという姿勢を開発チームが持てた実感があります。また、営業の方からの新機能のリクエストに対して「やってみましょう」と応えられる雰囲気にもつながったと感じています。

開発チームがいい雰囲気になるのは大切ですよね。話が変わりますが、毎週の定例会でさまざまな相談をいただく中で印象的だった点はありますか？

ユーザーから要望が高かったログの取得の話ですね。先に話した Amazon ECS の移行を見越すと、いずれ使わなくなる今の基盤に対してなるべく手を入れず、費用をかけない形で実現できないかと考えていました。

Topotal さんとの定例会で相談したところ、「設定変更で実現したい内容の90点くらいは満たせるのでこの方法で乗り切ってみませんか」という提案をしてもらいました。要求されているログを全部取得できるうえに最低限のコストで実現できる、ちょうどいいバランスの提案で助かりました。

モニタリング基盤の導入以外に印象に残っている支援内容はありますか？

インフラをコード化したいという要望があり、数ある Infrastructure as Code ツールから何を採用するか相談しました。その相談を重ねていく中で、 SRE チームを加速させるためには「SRE チーム内で運用できるか」「リリースやデプロイをより積極的に行うために必要不可欠なコードのメンテナンス性が高いか」の2点を基準に Infrastructure as Code ツールの選定した結果、 Terraform を使うことに決めました。

Terraform 導入にあたっては、現在運用している基盤を Terraform 化するという、かなり骨が折れる作業を Topotal さんに実施してもらいました。当初は、 Terraform 導入完了まで半年くらいかかるとイメージしていました。

現在のコードの依存関係の整合性を1つずつ確認し、それを Terraform のコードにしたうえで適用・差分の削除を繰り返す……という手のかかる工程を順序立てて1つ1つクリアしながら、新たに出てきた課題についても綿密に連携してもらいました。そのおかげでわずか3カ月ほどで Terraform 導入が完了し、スピーディーさと的確さを感じることができました。

もうひとつ、 Topotal さんのすばらしいところとして挙げたいのが、常に SRE チームの内製化を考えてくれていた点です。

例えば、請け負ってもらったタスクがあると、どのように考えたのかをドキュメント化してくれたり、構成に対しての ER 図を用いて説明してくれたりと、内製化したあとのことを考えてくれました。現在、社内の SRE チームだけで Terraform を使ったインフラ構築や設定変更もスムーズに行えているのも、 Topotal さんの支援とドキュメントのおかげだと思っています。

最後に Topotal へ一言お願いします

Topotal さんは課題解決に向けて最短距離で進む方法を、本当に私たちと一緒の目線で真摯に考えてくれました。課題解決への真摯な姿勢を持つという文化醸成にもポジティブな影響があったと感じています。 Topotal さんと一緒に仕事ができて、個人的にも本当によかったと思います。

SRE チーム構築のフェーズで Topotal さんに力を発揮していただいて、我々もなんとかスタートダッシュがうまくできました。おかげで Terraform は自分たちで運用できるレベルになりました。

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