三人それぞれの強みを活かし、サンクコスト効果に負けず適切な解決策を実現

高いサービスレベルを維持するには、「今、サービスは健全な状態にあるかどうか」の計測が欠かせません。しかし以前の仕組みでは、Webdevs（アプリケーションエンジニア）が保守をするには技術的な難易度と負荷が高いという課題がありました。Webdevsだけでも、SRE(Site Reliability Engineer)だけでも解決が難しかったこの課題にチャレンジし、大きな方針転換をしながら、最終的にDatadog APMを活用した計測基盤への移行を実現したSLO計測基盤リニューアルチームの皆さんに、お話を伺いました。

Q：それぞれの業務を教えてください。

石塚：私はWebdevsで、岩田さんと清水さんはSREです。私は前職でインフラ担当が退職したことをきっかけにインフラの保守・運用もするようになり、AWS（Amazon Web Services）の資格取得をはじめ、多くのノウハウを積んできました。Webdevsとしての知識だけでなくSREの知識も活かすことで付加価値を出せるような環境を求め、今の職場に転職してきました。自分の価値を活かせるようチャレンジさせてくれる社風があり、日々楽しく仕事をしています。

清水：私は以前、アプリケーションエンジニアとしてソフトウェア開発に従事していました。その後、前職で偶然SREの仕事を任され、それをきっかけにSREの面白さに気づきました。そして、SREとしてのスキルを高めるために、現在の組織に転職してきました。入社してすぐのメンターが岩田さんで、現在も一緒に仕事ができていることを嬉しく思っています。2023年10月からスタディサプリ小中高SREグループのマネージャーとして任用され、チームの生産性を高め、成果を最大化するための取り組みを行っています。

Q：SREの面白さってどこにあるのでしょう。所謂インフラエンジニアとは違うのでしょうか。

清水：インフラエンジニアの主な目標は、サービスの信頼性を可能な限り高めることであるケースが多いと思います。その場合は、サービスが常に100%正常に稼働し続けるための運用に重点を置かれるはずです。一方、SREの役割は、アジリティと信頼性のバランスを取ることにあると私は考えます。またスタディサプリ小中高のSREは、開発者により良い開発体験を提供するためのプラットフォーム開発も重要な役割です。いずれも面白いところだと感じています。

岩田：私は、前職ではバックエンドの開発やインフラエンジニアを経験していました。現職では、多くのマイクロサービスがある環境で、信頼性を維持しながら、開発生産性の高いプラットフォームを提供する、という仕事にチャレンジしています。

Q：スタディサプリの基盤は、マイクロサービス化がかなり進んでいるのでしょうか。

岩田：そうですね。年々増えており、今の時点では約60のマイクロサービスが動いています。
スタディサプリのサービスは大きく分けると高校生向け、中学生向け、小学生向けのシステムになるのですが、それぞれが独立して開発を進められると生産性を高く保つことができます。このような組織やシステムの構造を考慮しながらマイクロサービスの導入が進んでいるという特徴があると思います。一方で、モノリシックな部分も大きいため、両方においてうまく開発や運用をしていくところに難しさがあります。

Q：部署の異なるお三方が、一緒に業務をしているのはなぜですか。

石塚：私たちの組織には社内短期留学という取り組みがあります。自分のスキルアップのために、三ヶ月間SREチームの業務にチャレンジする機会をもらったのが、三人で一緒に仕事をするようになったきっかけです。その後は毎週定例で時間を作り、Webdevs、SRE、どちらかだけでは解決しにくい課題を横断的に協力して取り組んできました。今回MVP表彰をいただいたEnvoyの廃止もそういった課題の一つです。

Q：では、これまでEnvoyがどのような役割を果たしていて、そこにどのような課題があったのかを教えてください。

石塚：先ほど説明した通り、スタディサプリでは多くのマイクロサービスが立ち上がっていますが、各マイクロサービス間でどこの通信が失敗しており、どこに問題があるか、どのくらい時間がかかっているのかが可視化できていませんでした。それを計測し、「今、サービスは健全な状態にあるか」を観測できるようにするため導入したのがEnvoyでした。

Q：オブザーバビリティを確保して障害に至る前に通常とは異なる状況を把握し、SLO（Service Level Objective）を高めるための仕組みですよね。では、なぜその仕組みを移行する必要があったのでしょう。

石塚：Envoyを運用する技術や知識を持っているのはSREで、Webdevsにはそうした知識はあまりありません。一方で、数多くあるマイクロサービスを全てSREが運用するのは難しいため、各チームが運用のオーナーシップを持っていました。この結果、Envoyに関する知識を持つ人たちと実際に運用する人たちが違ってしまい、日々の運用やバージョンアップなどのメンテナンスがうまくできない、といった問題が浮上してきたため、Webdevsでも運用できる別の技術を検討し始めました。

Q：現在の構成を保ったまま、これ以上Webdevsが運用をし続けるのは難しかったのでしょうか。

清水：バージョンアップが行われない状態が続き、セキュリティリスクの増大に繋がっていました。
また、私たちのマイクロサービスは、Kubernetesというコンテナオーケストレーションツールの上で動いています。今日、サービス間通信にEnvoyを利用する場合は、おおよそIstioを始めとするサービスメッシュと一緒に導入するケースがほとんどだと思います。しかしながら、私たちがサービス通信にEnvoyを導入した時期は、まだ本番でのサービスメッシュの運用はかなり難しいとされていた時期でした。そのため、Envoyを直接サイドカーコンテナとして定義して導入としました。そのような経緯もあり、Kubernetes上でのEnvoyを安全に扱うための設定やkustomizeというツールとの組み合わせで、徐々に複雑性が増していき、本来抱え込む必要のない認知負荷がのしかかる結果となりました

岩田：普段の開発ではEnvoyに関する設定を変更する機会は少ないと思います。一方で、新しいマイクロサービスの立ち上げや問題の調査などではEnvoyの存在を意識する必要があります。Kubernetesの設定でアプリケーションとEnvoyを正確に設定するのは難しい作業です。例えば、アプリケーションの起動時にEnvoyが起動していないと通信が切れてしまうため、ユーザ体験に影響があります。そのためにはコンテナの起動順序を設定する必要がありますが、普段は変更する機会がないので負担が大きいと思います。また、複数のコンテナを設定する必要があるため、アプリケーションとEnvoyでリソースの割り当てが逆になってしまい、問題が起きたこともありました。本来はサービスの信頼性を計測するために導入したツールですが、皮肉にもサービスの信頼性に影響を及ぼしてしまうことがありました。
SREの人数はWebdevsに比べると少ないので、SREがすべてのマイクロサービスのEnvoyをメンテナンスすることは現実的ではありません。また、SLOはマイクロサービスの健全性を把握する指標なので、マイクロサービスのオーナーシップを持つWebdevsが自分たちで必要なコンポーネントをメンテナンスしていける世界を目指したいと考えました。

Q：どんな解決策を検討したのでしょうか。

石塚：まず、Webdevsにも使える技術で運用できるようにするか、それともSREがまとめて管理できるようにするか、二つの方向性を検討しました。
最初はサービスメッシュと呼ばれている技術を導入し、SREが全部まとめて管理できる方法を導入しようと考えました。最近の流れに乗っている技術でもあり、やってみたかったのですが、検証してみると期待と違ってSREだけで作業を完結できず、結局Webdevsに負担をかけてしまうことが判明しました。
その時ちょうど別のプロジェクトで「Datadog APM」の導入が進んでいました。Datadog APMではサービス間の通信だけでなく、アプリケーション内部の処理も含めて一貫して追跡することができます。Datadog APMを使えば、サービス間通信のSLO計測に必要な情報を取得できる上に、Webdevsにとっても馴染みのある各言語のライブラリという形で導入することができるため、元々Webdevsが持っている知識でうまく運用できるのではないかと考え、そちらに舵を切りました。

Q：明確な締め切りのない仕事に、推進力を持たせるのは大変ではありませんでしたか。

清水：技術的課題・負債をコントロール下に置くことを目標とし、組織横断で活動している「技術戦略横断ワーキンググループ」に持ち込み、課題について組織に認識してもらえたこと、フィードバックをもらえたことが助けになりました。また、技術的な負債に対する姿勢というのも組織文化に根付いています。これらの理由から、ビジネス上の要求がなくても進みやすかったと思います。

Q：苦労したところはありましたか。

清水：全てのチームがDatadog APMを用いたSLO測定を適切に運用するためには、利用するメトリクスの性質上、一定のルールに則った計装が必要でした。移行にあたり、当初は、私たち三人で導入ガイドをまとめ、実際の作業を各マイクロサービスのオーナーとなるチームにお任せする予定でした。しかし、その方向性で本当に負荷なく迅速にサービス全体に導入できるか、やや不安でした。そこでまず、ある一つのチームの協力を得て「ドキュメントをベースに効率よく作業をすることが可能か」を、実際に作業してもらった上で、フィードバックしてもらいました。結果、ドキュメントをベースに作業するのは、想定より大きい負荷がかかってしまうことが分かりました。ただ、今回のケースかつ私たちの組織規模において、移行のためのツールを整備して展開するのはややオーバーエンジニアリングでもありました。そこで、私たち三人で各サービスへの変更を行い、各チームにその変更をレビューをしてもらう形に落ち着きました。

Q：やはり、いきなり「この方法でやります」と押し付けても難しいんですね。

清水：実は、今回のSLO計測基盤リニューアルの前に担当したとある大きなプロジェクトで、事前に移行方法について検証をせずに、Webdevsに対して作業を依頼してしまい、ハレーションを起こしてしまった経験がありました。その反省を活かし、こういったアクションに繋げてみました。

石塚：それぞれのチームがそれぞれの案件を進めている中で作業をお願いすることになるため、どうやってコミュニケーションを取ると気持ちよく作業をしてもらえるのか考えたり、どこまで作業をお願いできるか調整するのが難しかったなと思います。依頼する前に各チームのマネージャーに相談したり、依頼する際のスケジュールに余裕を持たせたり、作業の目的ややることをまとめてから依頼するように務めました。

Q：そうした際に、アプリ開発に携わった経験は役立ちましたか。

石塚：そうですね。私はWebエンジニアのチームに所属しているため、どんな体制で開発をしているのか、誰にどう相談をするとスムーズに進むのかを知っていたことは大きかったと思います。

岩田：石塚さんはRubyが得意で、清水さんと私はGoが得意だったため、スタディサプリで採用している主要な言語を網羅できたこともよかったですね。

清水：SLO計測基盤リニューアルの取り組みのうち、特に後半について言及してきましたが、関連して取り組みの前半についても触れさせてください。前半はAppMeshというAWSが提供するサービスメッシュ実装の検証に時間を費やしました。その際にはKubernetesやサービスメッシュに多くの知見を持つ岩田さんが、調査や、実際の運用にかなり踏み込んだ検証についてリードしてくれました。後半のDatadog APMの計装では、石塚さんはRubyの実装を、岩田さんと自分はGoの実装を担当しました。

岩田：Datadog APMに関しては石塚さんが本当に詳しくて助かりました。また、分かりやすいドキュメントを作ることがとても上手で、SLO計測基盤の必要性や移行方法をWebdevsに分かりやすく伝えるという意味で大きな貢献を果たしたと思います。例えば、サービス間通信のSLOを計測するためになぜEnvoyやDatadog APMが必要なのか、今回の移行で解決される課題は何か、といった内容が整理されていました。SLO計測基盤だけでなくいろいろなドキュメントを書いてくれるので、とても助かっています。

石塚：逆に僕は、Kubernetesの細かな設定やログの見方といった知識については二人にまったく敵わないので、素晴らしいスキルを持つSREの二人がいたことで、壁にぶつかってもどんどん進めていけました。

Q：どなたが欠けていても難しかったんですね。

石塚：この三人のチームではEnvoyの廃止以外にもいろんなタスクをやってきました。Envoyの廃止は三年前に一度チャレンジしたときには解決が難しく諦めていたのですが、三人で課題解決する取り組みを長い間続ける中で状況が変わって、今回の課題解決につながったと言えます。一つのチームが継続して課題意識を持ちながら周囲の情報をウォッチし、「今ならできる」という形で動けたのが大きいのかなと思います。

岩田：週に二回、30分ずつのミーティングで三人が集まり、モブプログラミングを行う形をとっています。三人のうち誰か一人が作業しながら、他の二人が画面を見てサポートするというスタイルです。なるべく三人で同期的に作業を進めることで、全員で同じ知識や経験を共有できるように進めています。また、今回の取り組みではEnvoyの設定を何十個も直さないといけない場面もありましたが、毎週の時間を確保していたので心が折れずに継続できましたね。

石塚：明確な役割分担やプロジェクト管理がなくても、みんなで集まって話し合っていく中で「ここは得意分野だから僕がやります」と進めたり、その都度判断しながら進めていったのが良かったのかもしれません。

Q：EnvoyからDatadog APMへの移行によって、バックエンドエンジニアの負荷が減り、開発生産性が向上したそうですね。

岩田：Envoyに関する設定がなくなったため、Kubernetesのマニフェストの記述量が大きく減りました。また、通信経路がシンプルになったため、通信に関する問題が起きにくくなり、ユーザ体験も改善されたのではないかと思います。

清水：関連するSREへの問い合わせもなくなりましたね。その分SRE側は改善に集中できますし、Webdevsも問い合わせの返答を待つ必要もなくなりました。

石塚：それまで、Envoyに関することは毎回SREに問い合わせていたためWebdevsとSREの両方に負担があったのですが、改善後は問い合わせが無くなって負担が減りました。

岩田：SLOで取得しているメトリクスを変更したい場合はDatadog APMライブラリの設定で対応できるため、Webdevsが自己完結で改善できるようになりました。

石塚：Datadog APMは別件で入れたものですが、結果的に今取得しているメトリックス以外にいろいろなものが見られるようになったという効果もありました。

清水：多くのマイクロサービスのSLIには、レスポンスタイムのp99などのパーセンタイル値が採用されていました。しかし、Envoyがメトリクスとしてexportするときに、クライアント側でパーセンタイル値を計算していたため、そのSLOは正確性に欠けていた部分があります。DatadogのメトリクスのタイプのうちDISTRIBUTIONに該当する、Datadog APMがサポートするレスポンスタイムのメトリクスを利用することによって、より正確な指標を私たちは手にすることができました。また、Envoyでは発見できていなかった通信の失敗を、Datadog APMが提供するメトリクスでの計測に載せ替えたことでトレースできるようになり、より正確なSLOになったと思います。
かなり本腰を入れて、サービスメッシュの検証を実施し、時間と労力を投資していたので、やはり解決策としてサービスメッシュを採用したい気持ちがありました。ですが、それぞれの方法のトレードオフをきちんと整理し、サンクコスト効果に負けず、Datadog APMでの計測の導入に決めることができました。このように合理的な判断ができたのは、立場やバックグラウンドが少しずつ違うこの三人での議論の結果だと思います。サービスメッシュ導入に関する取り組みは無駄ではなく、本番運用を前提とした運用方法など、多くの知見を組織として獲得することができました。今後、別の目的でサービスメッシュを導入したい場合に、このナレッジが十分に活かせるはずです。

石塚：ドキュメントも作り、本格導入の一歩手前まで行ったところで撤退を決めたのは、けっこう勇気のある選択でしたね。

岩田：我々が本当に必要なものは何かという問いをきちんと振り返り、正しい判断ができたのはよかったことだと思います。

Q：個人としてはどんな手応えを感じていますか。

石塚：WebdevsでありながらもSREの業務にも関わり、課題解決ができるというのは自分の強みを活かせていると思いますし、やりがいも感じています。

岩田：SREの仕事では直接プロダクトコードに触れる機会はあまりないのですが、私自身はDatadog APMの導入を通してマイクロサービスの構成に詳しくなれたことが良かったと感じています。その経験は、SREでWebdevsをサポートする際の前提知識としてもすごく役立っています。

Q：この先はどんなことに取り組んでいきますか。

石塚：開発環境に取り込む本番データが、きちんとマスキングされているかを自動的にチェックするといった改善作業に取り組んでいます。現状でもカラムやテーブルを追加する際に警告を出すことで対策していますが、万一の事態があると個人情報漏洩といったセキュリティインシデントに繋がりかねないため、人の注意に頼るのではなく、機械的にもれなく気付けるような仕組みを作っています。

Q：運用でカバーするのではなく、仕組みにするということですね。

岩田：そういう課題を発見する場としても、この三人のチームがとても役に立っていると感じます。SREだけでは気づかない課題、Webdevsだけでは解決できない課題もあるのですが、それを一緒の目線で議論できることがこのチームの強みだと思います。

Q：この先、SREとWebdevsの役割分担はどのようになっていくのでしょう。一人で何でもできる人が求められるのでしょうか。

石塚：逆にそれぞれ強みを持った人たちが集まることによって新しい価値を提供できるのだと思います。SREとWebdevsも、それぞれ違う強みを持っているからこそ、助け合うために距離感が近くなるのではないかと感じます。

岩田：スタディサプリのコードベースも非常に大きくなり、たくさんのマイクロサービスが動いているため、全てを理解している人はおそらくなかなかいないでしょう。SREが提供するプラットフォームも非常に幅広く、複雑になっているため、得意な分野を持ち寄って課題解決に取り組むことが求められると思います。

Q：そういう意味ではこの会社は、いろんな強みを持った人がいて、自分も成長できる環境ですよね。

清水：そう思います。役割は確かにチームごとに分かれていますが、必要な時にコラボレーションしやすい組織だと思います。

石塚：いろんな会社で、SREとの距離が遠くて声をかけづらかったり、互いに何をしているかわからない、という話を聞きますが、うちはそういうのが全然なく、SREに相談しやすい空気がありますよね。新しいチームが立ち上がる時にもSREから専任を一人決め、積極的にコミュニケーションを取るようにしてもらっています。

岩田、清水：そう言ってもらえるとすごく嬉しいですね。

記事中で紹介した事業（名称や内容含む）や人物及び肩書については取材当時のものであり、現時点で異なる可能性がございます。