株式会社スリーシェイク Sreake事業部 部長 手塚卓也氏
信頼性向上のためにGoogleが作りあげたSRE、その現在地とは
――まずはこれまでのご経歴や現在の役割について簡単にお聞かせください。
手塚：2016年にインフラ系ベンチャー企業に就職しインフラエンジニアとしてキャリアをスタート、スリーシェイクには2018年に入社し顧客企業へのSRE立ち上げ支援などを行ってきました。現在はSRE総合支援やセキュリティサービスを展開しているSreake事業部の部長としてチーム全体を見ています。
山口：前職は外資系パッケージベンダーで製品やソリューションの検証環境構築および運用をしていました。2011年にGoogleに転職し、YouTubeの技術営業を経て、デベロッパーリレーションズエンジニアとしてさまざまな技術領域を担当してきました。2018年からはオブザーバビリティ領域を担当し、Google Cloud Operation Suite（旧：Stackdriver）の普及、オープンソースではOpenTelemetryプロジェクトの推進などに関わっています。
――SRE（Site Reliability Engineering）について、 改めて誕生の経緯や概要を教えてください
山口：かつてGoogleではシステムアドミニストレーション（運用）と開発の部署が分かれていましたが、サイトの信頼性を高めるために新しい手法で取り組もうと、新しい部署が立ち上がったのがSREのはじまりです。Googleの外ではDevOpsも発展していく中で、GoogleはゼロからSREのプラクティスを作りはじめ、後に書籍にあるように体系化し、アプローチを定着させてきました。
――GoogleがSREを始めてから長い時間が過ぎました。これまでに起きた変化や現状をどうご覧になりますか？
手塚：SRE本と呼ばれる『SRE サイトリライアビリティエンジニアリング――Googleの信頼性を支えるエンジニアリングチーム』（オライリージャパン）の原著が出たのが2016年4月、日本語版が2017年8月でした。最初はバズワード的なものでしたが、近年では国内でもさまざまなイベントが開催されるようになり、より実践に焦点があたるように変化したと感じます。
運用やインフラ担当で、日々アラートや障害対応に追われていた身からすると、SRE本を読んだときに「SREで全部解決できる」と期待してしまいたくなるのですが、実際はそうではありません。本にあることはあくまでGoogleさんの中でのプラクティスなので、当然そのまま適用できるとは限らないですし、実際には泥臭い部分も多くあります。その中で近年では実践にまつわる事例も増えてきた印象があります。スリーシェイクもエンタープライズからスタートアップまで幅広く経験しながら、いろいろと見出しているところです。
山口：最近ではSREに関するカンファレンスや記事、SRE組織を立ち上げたという発表も見るようになりました。Google社内では長らく実践する中でツールや手法の変化はありますが、「ユーザーの信頼性が大事」という原則はぶれずに守られています。
一方、外部の話を見ていると「自組織においてユーザーの信頼性をどうとらえるか」というようなSREの原則にあたる部分があまりフォーカスされていないのが気がかりです。
手塚：SLO（Service Level Objective：サービス提供側が達成すべき目標）を決めるのは監視ではなくユーザーだというフレーズを見ましたが、そういったユーザー目線を基本にして運用を回していくのがSREの実践に求められる肝の部分だと感じます。その中で、「SREは組織を作れば解決する」という考えには少し違和感があります。本来の目的はSREに求められている原則を実践することだと思うので、究極的には組織はあってもなくてもいいというのが個人的な考えです。また、それは必ずしも単一組織の中で行われるものではないと思います。
Google合同会社 シニアデベロッパーリレーションズエンジニア 山口能迪氏
開発効率と開発者体験の向上に繋がるSREのプラクティス
――現在システムやアプリケーションは作って終わりではなく、頻繁に改善を繰り返して育てていくようになりました。こうした開発サイクルを回すだけではなく、開発生産性を高めることも求められています。
山口：SREにはたくさんプラクティスがありますが、中でもSLO設定やエラーバジェットに基づいて開発することは効率性において重要だと思っています。ユーザーの信頼性さえ満たせていれば、その先の品質は不必要な改善になってしまうからです。SREのプラクティスでも、ユーザーの信頼性を満たす必要最低限の範囲で投資して、余った部分は改善プロセスに投資することが定式化されています。ですので、SLOに基づいて開発していくだけでもだいぶ変わるかと思います。
他にも、非難のないポストモーテム（失敗や障害から学び、再発防止に繋げる）もあります。開発効率というとプロセスやツールに目が向きがちですが、現場で働いている人が安心して働けることは非常に重要なことです。SRE本でも、従業員が安心して働けて、十二分に力を発揮できる状況を作る重要性が説かれていて、一つ一つのプラクティスをよく見ていくと、それぞれが効率化に繋がっているのです。
手塚：よく分かります！ 開発現場では、経営・ビジネスサイドの鶴の一声によって突如方針が変わってしまうケースは度々散見されます。当然、事業運営において一定程度そういった「ビジネスの事情」の優先度が高くなるというのも分かりますが、頻繁に変えられると、開発側はたまったものではないというのが本音なのかなと思います。そうした状況に対して、SLOやエラーバジェットといったツールを駆使してロジカルに意思決定できる仕組みを導入すると、全員にとって納得度が高く開発者にとっても快適な環境になるのではないかと思います。
山口：ビジネス側にはいろいろなKPIがあるかと思います。アプリケーションならデイリーアクティブユーザーとかリテンションとか。そうした指標はプロダクトの開発側や運用側と共有されていて、アクションに繋がります。一方、ビジネス側はアプリケーションでビジネスをしているにもかかわらず、こうした指標をあまり重要視していないと感じることがあります。そうした中で、SLOはとてもいいKPIになると思います。システムの状態がユーザーの満足に直結する指標となり、ビジネス側と開発側が共通の言語で会話できるようになります。それよりコミュニケーションロスが減り、効率改善にも繋がります。
――実際にSLOを設定するときに、押さえておくべきポイントはありますか。
手塚：GoogleさんではCUJ（Critical User Journeys）に基づいて、ユーザーが体験したい一連のインタラクションを見定めるというプロセスがあります。ただしCUJはシステム側だけでは判断できないので、ビジネス側からお客様に提供したい機能とか、達成したいことなどを挙げてもらい、協調して定めていくプロセスが大事になります。
最近は、チームトポロジーをSREのメソッドに組み合わせることでより本質的なSREが実現できるなと思っています。SREを実践するにあたって、チーム間の連携は切っても切り離せないので、そのあたりのコミュニケーション設計についても深く入り込みながらご支援するようにしています。
――チームトポロジーは昨年書籍も出ましたね。どのようなところが関連性が高いのでしょうか。
手塚：チームトポロジーの中で面白いと思ったのは、チームタイプだけではなく、チーム間のコミュニケーション方式（インタラクションモード）をどう設計するかにフォーカスしているところです。例えばAPIのように会話するとか、互いにファシリテーションするとか、さまざまなインタラクションモードがあります。
また、フェーズなどに合わせて、チーム間のコミュニケーションを適切に設計する重要性を説いているところにポイントがあると思いました。このメソッドをSREや開発組織と組み合わせることによって、組織全体においてのSREの立ち位置や支援方法を明確にできるため、より活動を推進しやすくなり、開発効率も向上するのではないかというのが、個人的な仮説です。
山口：たしかに、SLOとか各種定式化されたものは結局、人間のコミュニケーションを円滑にするために定義されているものが多いので、うまくはまるのではないかと思います。
――SLO以外に心理的安全性を醸成していく点で何か工夫されていることはありますか？
手塚：ポストモーテムは可能な限り実施しています。（障害が起こると）批判やいじめが起きてしまいがちですが「そうじゃないよね」と。物事の解決が一番大事です。エラーを人ではなくシステムでとらえて問題解決するという姿勢がとても重要だと考えています。
開発者も「ユーザーの信頼性」に着目して、開発を効率的に進めよう
――SREというと「インフラエンジニアに任せておけばいいのでは」と考えがちなアプリケーション開発者もいるかと思います。アプリケーション開発者が主体的に関わることで得られるメリットとかありますか？
山口：開発しているアプリケーションにおいてSLOが緩ければ緩いほど、求められる品質は低くなります。つまりそこまで高品質でなくとも許されるということです。そうなると、アプリケーション開発者にとっては、新機能でリスクを取った開発をしてもSLOに違反する確率が減るというメリットがあります。またSLO違反が起きそうなとき、開発者の立場からでも何が起きているかや原因の切り分けがしやすくなります。
今まではプロダクトを運用側にデプロイしてもらい、CPUやメモリの使用率などのシステムメトリクスやアプリケーションのログなどから勘と経験で推測することが多かったかと思います。しかしSLOを設定し、アプリケーションのテレメトリーを積極的に取得するようになると、自ずとアプリケーション開発者が自分で解決できる確率が高くなってきます。例えばリクエストが来たときにレイテンシが遅くなれば、どの部分が影響しているかはアプリケーション開発者なら分かるので、運用に関わる良さもあるかと思います。
手塚：（SREというより）インフラ側からすると、メトリクスくらいしかフォローできないと思っています。APMなどは開発側が意識して実装しないと……インフラ観点からすると、改善しようがないのが現実です。
インフラエンジニアならインフラのメトリクスやログを監視できますが、アプリケーションレイヤだとケアしきれないので、オブザーバビリティはアプリとインフラで一緒に作る必要があります。実はこのあたりが、明確な線引きがされているケースが多い企業の支援で困るところだったりします。「これはアプリのここを見ないと分からないでしょ」とか「大事なのにデータが取れない」とか。
山口：アプリケーション開発者が自分たちでやるとなると「何をすれば良いのだろう？」と戸惑ってしまいます。そういうときにSREやプラットフォームエンジニアリングなど（呼称は企業によりまちまち）の部署がテンプレートやガイドラインを用意することがあります。最近ではテレメトリー収集に関して、アプリケーション開発者の負担が減りつつあるようです。
――それでは最後に「明日からSRE的な視点で開発を効率良く進めよう」と気づいた読者向けにメッセージをお願いします。
山口：SREは原則が大事であることを改めて認識していただけたらと思います。そうすると自ずとプラクティスも理解しやすいかと思います。興味があればSRE本も読んでみてください。インフラエンジニアやオペレーション経験者なら理解しやすいかと思います。
SREはインフラチームだけではいけないので、それぞれのロールに合わせて理解していただけるといいと思います。例えばCUJを理解していないと、指標の設定ができません。ではCUJを決めるのは誰かというと、会社によりプロダクト責任者、UXデザイナー、ビジネスサイドなどに分かれますが、そうした方々の協力がないと優先度をつけることが難しくなります。ぜひ興味を持ち、ユーザーの信頼性について考えていただけるとSREを導入しやすくなるかと思います。
手塚：SREの中に信頼性は非機能要求ではなく、機能要求だというメッセージがあったかと思いますが、その通りだと思います。いくら素晴らしい機能を開発したとしても使えなければ意味がありません。SREはこうしたときのエンジニアリングの一種のメソッドです。そして信頼性について、エンジニアだけではなく組織全体が向き合ってほしい。そういう組織を一緒に作っていけたらと思います。
SRE総合支援サービス「Sreake（スリーク）」
「Sreake」は、SRE（Site Reliability Engineering）による設計及び構築支援から人材育成まで、クライアント組織に深く入り込んだコンサルテーションを提供しています。AWS/GCPなどのマルチクラウドの導入や、KubernetesやIstioを始めとしたクラウドネイティブに特化した技術に強みを持っております。金融・医療・動画配信・AI・ゲームといったさまざまな業界業種・領域での実績から、最適な課題設定と解決策を提示し、最新技術で、競争力のあるインフラ環境を構築、また維持できるチーム作りをご支援します。
