CTO 藤村がホストとなって、技術や技術にまつわることについてざっくばらんに話すPodcast、論より動くもの.fmの第3回を公開しました。今回は、CTO 藤村とSREの藤原で、SREやDevOpsについて話しました。
論より動くもの.fmはSpotifyとApple Podcastで配信しています。フォローしていただくと、新エピソード公開時には自動で配信されますので、ぜひフォローしてください。
テキストで読みたい方は下記からどうぞ。
なぜ変更容易性が重要なのか
藤村：みなさん、こんばんは。論より動くもの.fmです。論より動くもの.fmはheyのCTO 藤村が技術や技術にまつわることについてざっくばらんに話すPodcastです。今日はheyのSREの藤原さんに来てもらいました。藤原さん、よろしくお願いします。
藤原：よろしくお願いします。
藤村：まずは簡単に自己紹介をお願いします。
藤原：藤原涼馬といいます。2011年から新卒で製造業系のSIerに研究員として入社、その後リクルートに転職して、新規プロダクトの開発を担当しました。成長の場を求めて、2021年6月にheyに入社しました。今はプロダクト基盤本部で、IdP周りのSREとして活動しています。
藤村：藤原さんとは、面談や面接をしている時にも意気投合して話が盛り上がった印象があります。SREやDevOpsと呼ばれているジャンルの話を長々としてしまうことが多いので、今日は「SREってなんでしたっけ」というのと、最近はあまり使われてないけど、僕は重要な言葉だと思う「DevOpsについて」聞いてみようと思います。
SREって教科書的な定義だと、何なんですかね。
藤原：教科書的な定義でいくと、システムの信頼性を高めていくために、過去だとハードウェアに設定をいれたり、ネットワーク系だったらCiscoのネットワークの冗長化設定にconfigを入れたりみたいなことだったと思います。それも残ってはいるんですけど、それとは別に設定やシステムの構成をコード化していって、ソフトウェアエンジニアリングの手法を使って、システムやサービスの信頼性を確保していくのが教科書的な定義におけるSREかなと思います。
藤村：SREってSite Reliability Engineeringで、SiteがWebサイトやWebサーバ、Reliabilityが信頼性ってことですもんね。信頼性ってどんなものがあるんですか？
藤原：これが難しいんですよね。古く言えばRASISみたいな概念とか、Reliability、Availabilityみたいな話もでてくるんですけど。その軸でいくと、信頼性ってそもそもハードウェアが壊れないことみたいな話になっていて、ちょっと違うよなと。ここにおけるReliabilityってなると、非機能要件全般っていうほうが手っ取り早いんですよ。
藤村：ふむ。
藤原：個人的な意見になりますが、Reliabilityや非機能要件ってすごい広い範囲の話で、プロダクト固有のコードレベルとは別で、サービスのパフォーマンス、冗長性、冗長性は可用性ともつながるんですけど、ひいてはデプロイ容易性の確保であったりと、かなり広い範囲にまたがる話かなと思っています。
藤村：一般の人が思うSREって、サーバの負荷が高くなっても大丈夫なようにする人みたいな感じじゃないですか。それ以外にも結構ありますもんね。デプロイ容易性とかもそうだし。藤原さん個人として力を注いでいる、気にしている部分はありますか？
藤原：運用性はかなり意識していますね。SREとして考えた時に、ひとつめはシステムの冗長性、可用性、信頼性を高めていくためにシステムアーキテクチャはどうあるべきか。そこに対して、アプリケーションや新規のインフラを追加でデプロイしていく運用設計をどう考えていくか。静的にかたまっている、現在稼働しているアーキテクチャに対して、新しい仕組みをスムーズに入れていくにはどうすればいいのか。アプリケーションでいうと、拡張性、変更容易性。そういった部分を、インフラレイヤーでも実現するにはどうしたらいいのかを予め考えた構成にしておくのがSREとしては重要だと思います。
藤村：いわゆるインフラエンジニアと呼ばれているものと、SREと呼ばれているものの仕事の違いって、藤原さんが話していた変更容易性だと思うんですよね。変更容易性のために、さまざまなテクノロジーが用意されているし、プラクティスが用意されている。なんで変更容易性って重要なんでしょうね。
藤原：Webサービスの世界に閉じた話をすると、競争が激化しているから。新しい機能を競合他社よりも早く作って、積み上げていく。それによって競争優位をつくり、お客さまに対して高い価値を提供していくことが要求されるようになった。
そうなると、インフラの構成の変更なしにどんどん機能を追加できるのが最良ではありますが、インフラの構成を変更した方が新しい機能を実現しやすいこともある。以前だとオンプレミスでカチッとした構成でやっていたけど、それに対してクラウドの世界だと新しいインフラのリソースやインフラのサービスを動的に投入していけるような仕組みにするのが重要になってきた。アプリケーションレイヤーで競争していた部分が、インフラレイヤーでも同じようなアジリティが求められるようになってきたのが現状かなと思います。
藤村：Immutable Infrastructureって言葉がありましたよね。それを思い出しました。最近、Slackの自分のtimesチャンネルでThe Twelve-Factor Appについて書いたんです。Herokuの作者が提唱した、今Webプロダクトをオペレーションするためには、こういうのを守るといいよっていうベストプラクティス集みたいなものなんですね。10年前以上のものだけど、未だにすごく重要だなと僕は思っていて。その頃はSREって言葉はまだそんなに言われてなくて、DevOpsでしたよね。
藤原：そうですね、DevOpsを実装するひとつの形がSREだと言われることはあります。ですが、自分もまだ整理しきれていない部分があって。少なくともDevとOpsに関して言えるのは、DevとOpsって対立した概念という話があります。ただDevもOpsも同じ組織、同じ会社で働いている限りは、お金を儲けないといけない、お客さんに貢献しないといけないというところで、同じメトリクスを持っているはず。共通KPIを持てば一緒に協力して仕事ができるはず。それに対して注力していくにはどうしたらいいのかを考えると、役割分担としてDevとOpsで切るのではなく、プロダクト開発をする人、そのサービスを支える組織としてのSREという話がでてきたのかなと思います。
藤村：もう今、運用部隊って言葉、われわれの業界でほとんど聞かないですもんね。運用フェーズに入ったから触らないって、たまにありますけど、そんなにないというか。結局何かを作ったら更新し続けないといけない。
藤原：そこにとどまるためには走り続けないといけないですよね。運用って観点でいくと、投資判断としてここの部分はしばらく新規開発はしません、ただ維持するだけですというのはあると思っていて。そういったところで、オペレーションのみになる可能性はあるんですが、今時あまりないかなぁというのが個人的な感触ですね。
藤村：自分が直接触っているプロダクトでそういう状態になるのであれば、「あ、運用フェーズなので触らないんですね」という判断にはならないですよね。定期メンテナンスでデプロイできるようにしておこうとなる。運用フェーズと言いつつも、継続的デプロイメントを維持しようという気持ちになります。
藤原：使っているモジュールの新しい脆弱性が見つかったり、言語のサポートが切れてしまって言語のバージョンアップをしないといけないことも起きる。なので、開発がコードにもインフラにもまったく手を入れないことが続くかというと、そういう世界ではないですね。
藤村：10年前に比べると、さまざまなシステムやプログラムを動かすためのコンポーネントがアップデートされる頻度も高いし、EOLも早くなっている感覚がありますね。
アプリケーションエンジニアとSREのコミュニケーションプロトコルが整ってきている
藤村：これは邪推ですけど、GoogleやAmazonではオペレーションに関して進んでいる部分が多いと思っていて、GoogleのSRE本が出ていたりする。そういう彼らのプラクティスに、僕らが使っているテクノロジーの大きいコンポーネントもある種あわせて作られていくようになっていき、結果的にそれに従うことで僕らのオペレーションのアジリティもあがっていくこともありますよね。
藤原：それは間違いなくあると思います。Oracleは典型的な例ですよね。今、Oracleのデータベースを作るとなったら、AWSでOrcleのRDSインスタンスをあげてもいいし、Oracle Cloud Infrastructureの部分でOracleのRACでも何でも、お金さえ払えば自由に使えるじゃないですか。私がIT業界に入った2010年頃やそのちょっと前は、Oracleのデータベースのインスタンスを1個インストールしてあげるだけで、うん十万円というのが業界として存在していた。でも今はそうじゃないなと思っていて、アジリティとか要求されるスピード感は変わっていないように見えて、めちゃくちゃ変わっている。
藤村：当時に比べると、全然違うゲームになった感がありますよね。今から15年後先にソフトウェアを作って、使ってもらうために必要なオペレーションがどういう姿になってるか想像がつかないですね。
藤原：自分は元々インフラエンジニアとして動いていたんですけど、どんどんパブリッククラウドに寄っていきました。ハードウェアを直接触ることがなくなった。結果としてパブリッククラウドの仕事をするようになったんですが、ボタンひとつでデータベースもあがるし、インスタンスもあがる。
じゃあ、おれたちの仕事って一体なんだろうね、てなる。いきなりアプリケーション固有のコードを書くにはちょっと遠い。自分たちがやれるところは何か、となったら、複雑になっていくインフラを管理していく、そのインフラにアプリケーションをのせるためのパイプラインを整備するみたいなことをやっていかないと、ご飯が食べていけなくなる。危機感ベースで動いているのは、私に限らず、元々インフラをやっていた人たちに結構いるのかなと感じますね。
藤村：その危機感の結果、SREという仕事だったり、重心低めのアプリケーションエンジニアのやっていることって、IaCを使って、どれだけコンピュータをぶん回せるかじゃないですか。このコンピュータをぶん回せるかはむちゃくちゃ重要な考えだなと思っているんですよね。ここはあのクラウドベンダーのこのプロダクトを使うと解決するみたいな感覚とか。かつては、サーバを立てて、cronで何かを定義して実行するみたいなのを手で組んでた時代からハードルは下がったじゃないですか。逆にその分、色んなことを知らないといけなくなった。このクラウドベンダーのこれを使うと何ができるみたいなのをどれだけ手触り感をもって知っているか、もしくは使えるかっては重要になってくるんだろうなと。
そして、それを誰がやるんだってなると、SREが100％一致しているわけではないなというのが、最近の僕のSRE、インフラエンジニアに関する悩みですね。
藤原：難しいなと思うのが、GoogleやAWSにおけるSREと、heyにおけるSREは根本的にレイヤーがずれると思っていて。GoogleやAWSにおけるSREは、個別のプロダクトを維持することもありますが、実際にはその裏側の基盤になっている、AWSだったらNitroのシステムの維持など、我々とは違うレイヤーでの仕事に関わっているSREの方もたくさんいる。我々はその基盤の上で踊っている側なので、SREの仕事のレイヤーをひとつ上に移動して、ここは俺らSREに任せてプロダクトのエンジニアは先に行けみたいな。
藤村：ふむふむ。
藤原：個人的にSREをやっていて常々思うのは、プロダクトの開発者はプロダクトのコードだけを気にしてほしい。プロダクトのコードを介してお客さんに機能を提供して、それによってお客さんに経済的な価値や、それ以外の価値をどんどん提供してほしいんですよね。それをするための下回りは我々の方でまるっと面倒をみるから、全体のアーキテクチャの設計部分から関わらせてもらって、コードを書く部分以外になるべく頭を使わないでほしい。どうお客さんに機能を提供していくか、その機能はどうあるべきかをもっと注力してほしい気持ちがあります。
藤村：その分業って僕はポジティブに捉えているというか、今のソフトウェアを作っていくにあたってのひとつの理想だと思うんですけど、いい意味でアプリケーションエンジニアへの要求は高くなっていると思う。クラウドベンダーなり、色んなベンダーでできることの詳細や内部を知らずに、こういうことをやりたいという要求をクリアに考えないといけないじゃないですか。
藤原：うんうん。
藤村：例えば、SendGridのこのAPIを使って、こうできるから、こうやろう、みたいなのじゃなく、メールを送りたいという要求から高い抽象度で考えないと、適切な責任分解点みたいなのがぐちゃぐちゃになるというか。SREの仕事とアプリケーションエンジニアの仕事の責任分界点がぐしゃっとしそうだなと思いました。
藤原：SREがソフトウェア・エンジニアリングの手法を使って課題に対処していくのが大事だと思っている。1番確実、かつ齟齬がないのは、コードベースで会話することだと思っている。
藤村：そうですね。
藤原：最近出てきているIaCのツール、広く捉えるとKubernetesのYAMLとかもそうなんですけど、あそこに書いてあることがすべて。そこをインターフェースとして、自分みたいなインフラエンジニアあがりのSREとアプリケーションエンジニアがああでもない、こうでもないとアーキテクチャ面でどうあるべきかと会話ができるようになった。そういう意味で、共通言語的な部分が整備されてきた。今のタイミングはいい形かなと思っています。
藤村：アプリケーションエンジニアとSREエンジニアのコミュニケーションプロトコルが少しずつ整ってきている感覚はありますね。
藤原：例えば、アプリケーションエンジニアの人がCiscoのスイッチのconfigの話をされてもちんぷんかんぷんな世界じゃないですか。でも、もう少し抽象化されて、コードベースでVPCのルーティングをこういう風に設定するみたいな話になるとわかりやすい。
藤村：そうなるとIaCツールの設計思想や作りの個性をよく知っておくのが、両サイドにとって重要なことですね。
藤原：どっちがリードするのかにも依存するとは思います。そういう意味でいくと、SREのポジションって魅力的な仕事だなと。基本的にSREが担当する部分ってドメイン固有の情報は入ってこないんですね。純粋なソフトウェアエンジニアリングの世界。そうなると、SREはソフトウェアコードの再利用性、モジュールの共通化部分に正面切って取り組みやすいなと痛感しています。
藤村：たしかに、アプリケーションエンジニアに比べると、成果物のポータビリティは高そう。
藤原：heyに入社してから、STORES 決済やプロダクト基盤の仕事をしたり、CIT WG（クラウド利用をとりまとめるワーキンググループ）でSSOの整備をしたりと、色々と関わっているんですが、その中でIaCベースで書いていくと、このコード実はあのサービスにある程度、汎用化したら持っていけるよね、というのがわかってきて。これをやるかやらないかで5年後のheyが変わってくるだろうなと思いつつも、ここの勘所はすごく難しいので悩ましい。
藤村：このプロダクトとあのプロダクト、同じやつ使っていいのか悩ましいみたいなやつですよね。
藤原：はい、最悪フォークしてしまえばいいんですけどね。
藤村：理想的なのは、さまざまなアプリケーションエンジニアから見たコンピューティングリソースの使い方みたいなのが、だんだんいくつかの形に収斂していくみたいになるといいんでしょうね。
藤原：そうですね。
藤村：でも、そこで収斂させる方向に舵を切りすぎると、共通ツールを使っているんだが、共通ではないみたいな風になっちゃうというか。さじ加減が難しいですよね。
藤原：大きい視点でいくと、深くする方の深化と、新規技術の探索みたいなところにもハマるかなと思っていて。共通化していくとどうしても探索の部分が弱くなっちゃうんで。バランス取るのが難しいなと思いますね。あまり深化が進みすぎると、急激な環境変化に対応できない。
藤村：そうですよね、10年前はIaCのツールは何を使ってましたかと言われると、Puppetみたいな。10年前ならPuppetよりもっと古いか。
藤原：10年前はIaC自体を使ってなかったですね。パラメーターシートベースでがんばって作っていたので。
藤村：「シェルスクリプトひとつでWebサーバとRailsが動くインスタンスができる君」とか作ってましたね。
藤原：半年後に動かなくなるやつですね。
藤村：もちろんです。集中していくことで変化に取り残されるっていうのは、CTOとしてめっちゃ怖いもののひとつですね。そして、今使っているテクノロジーの中で必ず発生することは確率的には間違いないことなので悩ましい。
藤原：そういう風に考えると、最近出てきたスタートアップをいくつかみていると、そんなに規模が大きくなくてもR&D的な組織をつくって探索していこうとしている。そこに対しての危機感があるんだろうなと。
藤村：うまくいってるプロダクトの寿命って、3年、5年、10年みたいな感じだと思う。ポートフォリオを組んでやるには、なにかしら新しいことを試して、それを3年、5年寝かせて、寝かせた結果、業界でもスタンダードになっている。ポートフォリオを組まないといけない。今、1番使われている便利な技術だけでやり続けていると、うまくいかない。そのプロダクトの運用が3年、5年と続いたときに、今はこのテクノロジースタックで作らないだろうっていう感じのシステムがズラッと並んでしまうことになっちゃうと思うんで。それを避けるのも重要ですよね。
藤原：自分がよくやっているパターンとしては、基本的に以前うまくいった構成と同じような構成でやる。ただしその中でチャレンジをすべき項目を、5人いたら5人、それぞれテーマを持って、新しい領域をちょっとだけやってみて、それがうまくいったかいかなかったかを振りかえる。どこでチャレンジをして、どこを保守的にしていくのか、都度テーマを定めていくのはすごく大事。八方美人的に全方向でやっていくのは、結果が相互作用でポジティブかネガティブなのかが判断しづらくなる。どこを攻めて、守るのかを明確にするのが大事だと感じますね。
藤村：アーキテクチャを新しくする上でも段階的リリースが重要みたいな話かもしれないですね。
藤原：アジャイルであるじゃないですか、いきなり車を作ってだんだん豪華にしていくんじゃなくて、始めは車輪だけ作ってそれで済むかチェックして、次はキックスケート作ってみたいな。あれと似たようなものかなと。
藤村：こういうのってイノベーションとは言わないと思うんですよね。新しい技術に入れ替えていくみたいなのって。イノベーションとは言わないけど、なんていうんだろうな。「新しい技術を入れていくことOps」みたいな世界はありますね。それをどううまくやっていくかみたいな。
藤原：新しい技術といっても、まったくゼロからイチを作っているわけじゃなくて、ほとんどの場合って、世の中を見ていても、新しい技術を使ったといっても、実際にはOSSで公開されている尖ったものを先行者としてチャレンジしてみたとか。0→1で作っている会社ももちろんあるとは思いますが。我々よりも先進的な取り組みをしている企業やうまくいっている企業に、そこで使われている技術を都合よくつまみ食いするのがいいかなと思っていて。
藤村：最近のインターネットインフラを作っている会社も、そういうことをすごくやっている。Fastly、Cloudflareとかもそう。うまくいっていることを真似するのってすごくやりやすいですよね。だいたいコードも公開されているし。
藤原：コードベースだけじゃなくてプロセスも、この会社のフェーズと我々のフェーズってどう違うんだろうとか、組織の規模の違いを見た上で、本当にこのまま試してみてもいいんだろうかと調整かけていく、そのあたりの勘所をつかんでいくのは大事だと思いますね。流行っているから食らいついていくのは危険だと思っていて、その前に組織にフィットするのか維持できるのかを考えてやっていくのが大事かなと思いました。
藤村：Podcastなのか、藤原さんとのディスカッションなのか、わからなくなってきましたね。
藤原：笑
藤村：藤原さんとディスカッションしたいことはまだまだありますが、今日はこの辺でおわろうかと思います。藤原さん、ありがとうございました。
藤原：ありがとうございました。
藤村：では、論より動くもの.fm、終わろうと思います。みなさん、ありがとうございました。（完）
次回の更新をお楽しみに！
