今月、弊社の投資先より、急成長中のSaaSスタートアップ3社から各社の開発チームにお集まりいただき、その3社のデベロッパー・エクスペリエンス「DevEx」についてのウェビナーを開催しました。3社それぞれにエンジニアさんの働きやすさと開発効率をよく考えた施策や取り組みが語られた充実のセッションとなりました。

今回は、後半のセッション「DevEX x SRE」の様子を一部ご紹介します。

UPWARD 門畑さん：本日はSREの観点でDevEXを高めるエンジニアの取り組みをベースに3社で話していきます。

「SRE」という言葉は最近よく出てきていると思います。SREという単語はもともとGoogleが定義した単語です。Site Reliability Engeneering（サイト信頼性エンジニアリング）の略です。データセンターの運用、ITインフラを支え、信頼性を高めるところから発展して現在に至ります。アプリケーション開発者と運用者の隔たりをなくし、協調したシステム運用が行えるようになるものです。今回参加いただいている3社は、全社クラウドを前提としたサービスを展開しています。弊社UPWARDはAzureをメインに使っていますし、コミューンはGCP、テックタッチはAWSと三者三様のクラウドをつかっています。SREという定義自体はあるものの、中身については変わってきているのではないかと思います。そこで本日は、DevEXという観点で、クラウド時代のSREとはなんなのかについてお話しできればと思います。

UPWARDにおけるSREの役割定義

門畑さん：従来のサイト信頼性エンジニアリングを少し拡張して、どちらかというとCloud Center of Excellence (CCoE)の機能をSREの中に織り込んでいます。具体的には、我々の組織は「プロダクト制」でプロダクトマネージャー、UI/UXデザイナー、フロントエンド、バックエンドをワンセットにしています。これを横串で信頼性を高めるための標準ガイドを策定しています。標準ガイドは、信頼性の意味合いを拡張し、セキュリティやパフォーマンスなど、いわゆる非機能という観点を担保するため、標準的に守るべきガイドを設定しています。ふたつめは「プロダクト支援」です。新しいプロダクト開発時にクラウドインフラ構築を支援することです。３つめは「日々の運用監視業務」。障害が発生した時に迅速にそれをキャッチして復旧する。４点目は、プロダクトを横串でログを取得して管理することができます。コスト管理もSREが担っており、ビジネス部門もどういう機能がROIの観点で有益なのか、メトリックスを取得してインプットする役割を担っています。

SREのチームのミッションというのを掲げています。Googleが定義した「トイル（定常的に発生する手作業）」をできるだけ排除していき、自動化の仕組みを構築していくことで、より重要な検討領域でのエンジニアリングを進めていく。すなわち、セキュリティの高度化・高い可用性・高いパフォーマンスなどの非機能を高度化すること。SREとは、プロダクトチームと比較するとお客さんになかなか見えませんが、SREがきちんとしていないと、なにか問題が起きた時にプロダクトが動かなくなるので、SREは重要なミッションです。

質問（参加者）：SREチームはビジネス部門との折衝や、サービスの守護神的な役割を担う重要なポジションと理解できました。一方ですぐに手が足りなくなるチームでは？という疑問があるのですが、何名ぐらいいらっしゃるのでしょうか？その中でどのように役割分担されているのでしょうか？

門畑さん：SRE専属という人はおらず、全員兼務です。割合はそれぞれに異なるのですが、弊社の定義しているSREの業務範囲は多岐にわたります。標準ガイドラインを作るというスキルセットをもつ方も入れば、クラウド構築が得意な方、障害検知を仕組み化することが得意な方など。それぞれ得意なところが異なるので、ある方はリサーチ寄りのことをやりつつ70%はクラウド構築を担ったり、ある方はプロダクトチームに入りつつも標準化やドキュメント整備をやったりと、役割をスキルセットに応じて兼務にしています。

コミューンにおけるSREの役割定義と具体的な取り組み

川岡さん：コミューンの川岡と申します。長いことインフラをやってきて、前職ではマーケティング会社でオペレーションを回す部隊を任され、2年半ほど前にSREsとしてジョブチェンジをしてコミューンに入社しました。本日は具体的な取り組みをいくつか紹介できればと思います。

弊社のアーキテクチャについてご紹介します。弊社はGoogle Cloudを使っています。アプリケーションはCloud Runというサーバーレスのコンテナ実行環境をつかっています。アプリケーションはTypeScriptで開発をしています。CI/CDはGithub ActionsとCloud Buildを使っています。

DevEX向上の施策①クラウド権限に関する課題

クラウドの権限に関する課題がありました。SREチームが権限を管理し、開発者が必要な時にSREチームヘ権限依頼をするフローでした。SREチームが作業できる時にしか権限付与できず、SREチームがボトルネックになっていました。一方、開発者に強めの権限を渡しすぎるとセキュリティの課題や、開発者へのストレスを与えてしまう。そこで、SREの作業を待たずに一時的な権限を付与できるセルフサービスを導入しました。なんの権限をどれくらいの時間誰がなぜ必要なのか、を入力し申請すると、そのユーザーに権限が付与され、Slackに通知がされる仕組みです。Slackに記録が残るので監査の観点でも良いと考えています。この仕組みは、マネーフォワード出身のエンジニアがSREチームではなかったのですが導入してくれました。この仕組みは、Money Forward Kessaiのパブリックなリポジトリで公開（https://github.com/mfkessai/granter_core）されているので、Google Cloudをお使いの方で同じことに困っていたら使ってみると良いのではないかと思います。多くあったやりとりが簡潔になり、SREチームにリクエストがこず開発者だけで完結できるようになりました。

DevEX向上の施策②CI/CDに関する課題

CI/CDの課題がありました。ビルド・デプロイの時間が長かったり、パイプラインに冗長なステップがあり、見直しが必要でした。解決方法のひとつめは、ビルド時間を見直して時間を短くしました。大体15分から半分に減らすことができました。もうひとつは、パイプラインを見直して無駄なステップを削除しました。この場合で言うと、ビルドが不要だったので一回無くして時間を短縮することができました。この二つの事例は弊社の技術ブログに載っていますので、ご興味があればご覧ください。

これによる効果としては、開発ブランチをデプロイする動作確認環境と本番環境の両方の環境で「Build」「Deploy」「Release」を行うためトータル40分かかっていましたが、現在は開発環境では10分、本番環境では3分でリリースできるようになりました。具体的にはCloud Runを使っているので、開発環境へのBuildの際に本番環境のコンテナもDeployしてしまい、リリースの際は作ったコンテナにトラフィックを流すだけにしました。よって劇的に時間を短縮できました。

DevEX向上の施策③Google Cloudのリソースに関する課題

開発者がGoogle Cloudのリソースを作成する時の課題がありました。権限付与と同じようにSREチームの待ちが発生するというものでした。開発者がインフラのコードを書いて、SREチームにPRをだすということで解決しました。例えば開発者がオブジェクトストレージのバケットを作成したい、Cloud Runに環境変数を定義したいといったリクエストがあった場合に、それまではSREチームに依頼し作業を待っていました。コミューンはインフラの一部をCDK for Terraformで管理しているので、クラウドのリソースが必要な場合は開発者がコードを書いてPRをだすだけ、となりました。SREチームは開発環境と本番環境へのDeployはやりますが、動作確認をするだけのfeature環境に関しては、開発者がDeployできるようになっています。CDKTFもTypeScriptで書いているので、アプリケーションエンジニアにとっては自分の使える言語でインフラのコードが書けるというところでメリットがあります。CDKTFについても技術ブログがありますのでご覧ください。

そのほかにも、開発者が気軽に負荷テストをできる環境をつくったり、開発者向けのドキュメントを充実させたり、コードのセキュリティチェックを簡単にできる外部サービスを使ったり、エンジニアの福利厚生としてオライリーサブスクとGitHub Copilotを使えます。DevEX向上にはこれが一番効果的かもしれません。

門畑さん：非常に興味深いですね。権限は、セキュリティを担保しつつ開発効率をあげるという、いわゆるトレードオフの関係をどう解決するか。アプローチは違うけれどやりたいことは似ていることに挑戦しているなと思いながら伺っていました。

テックタッチにおけるSREの役割定義と具体的な取り組み

伊藤さん：テックタッチの伊藤です。私はアプリケーションを作っていた経歴が長く、現在は全体のアーキテクチャを把握していることを強みにSREをやっています。テックタッチでのSREの役割は、DevEX向上はもちろんのこと、プロダクトのセキュリティ、インフラのコスト、信頼性の担保にどんどんタッチしています。具体的な事例を紹介します。

DevEX向上の施策①リリース時手順自動化

ひとつめは、「リリース時の手動手順をパイプラインに統合」しています。一定リリース時には自動化をしていると思いますが、どうしても自動化できず手動でカバーしているところがありますが、得てして開発者の端末上で実行されてしまったり、そもそも設定として投げ込むものが適切か都度確認の必要があるなど、冗長な手順で残ってしまうものもありました。これをしっかりパイプラインを統合したり、レポジトリで管理しているものが自動で反映し、リリース手順を自動化していけるよう取り組んでいます。

DevEX向上の施策②サービス・ツールをSSO化

「開発に利用するサービス・ツールをSSO化」というところで、リモートワークをしているといろんなツールを使って開発が進んでいると思いますが、ツールやサービスが異なると認証もそれぞれ必要になります。テックタッチはGoogle Workspaceの認証を通せば、すべてのアプリケーションが使える状況をつくりだしました。シームレスにいろいろな環境が使えるようになりました。若干エンジニアリングが必要なところも、SREチームとして対応しました。

DevEX向上の施策③distrolessコンテナの導入

続いて紹介するのは「distrolessコンテナの導入」です。テックタッチのバックエンドアプリケーションは、基本的にアプリケーションコンテナとしてまとめられるようになっているのですが、そのベースのコンテナを、distrolessという不要なものが一切入っていないコンテナに入れ替えるようにしています。コンテナイメージに含まれる、使っていないライブラリもセキュリティチェックの対象になってしまい、そこに脆弱性が含まれるとセキュリティスキャン時にノイズになってしまうのを避けるために導入しました。コンテナ自体も軽くなるので、スケール性能にも寄与するなど導入してよかったと思います。

DevEX向上の施策④アクセスキーを利用しない
「アクセスキーを利用しない」ようにしています。AWSについて、CircleCIからアクセスしたい場合にアクセスキーを設定することが多いと思いますが、これを一切やめました。
OIDCの認証を使い、外部のサービスに権限を与え、アクセスキーなしに使えるようにしました。アクセスキーを外部に持ってしまうと、ずっと置いておくわけにはいきません。例えばAWSのWell-Architected Frameworkでも90日ごとにアクセスキーをローテーションすることが推奨されてますが、90日ごとに更新するとなると運用負荷が上がります。この運用をなくすことができるので、アクセスキーをなくし、適切なものに適切な権利を付与することができます。

DevEX向上の施策⑤安心して開発できる状態を保つ

Githubに運用上有益な情報があるのですが埋もれてしまうので、これをSlackに集約し可視化するようにしています。危ない設定があったら直そうと通知がきたり、危険な設定に対してアラートをあげたりしています。

DevEX向上の施策⑥かゆいところに手が届くモニタリング

テックタッチはDatadogを使っていますが、アプリケーションの開発エンジニアに見てもらう価値があるようなAPM (Application Performance Monitoring) を導入しています。また、ECSあるあるかもしれませんが、コンテナが不意に停止したときにその理由が表示されます。これが数十分経つと揮発してしまい、あとから確認できなくなります。これを防ぐためログを残す施策などを組みました。

SRE業務の難しさ

門畑さん：SREの業務はクラウド構築から障害が発生した時に迅速に検知しリカバリーするなど、作業範囲が広いと思うのですが、課題や苦労したことがあったら教えていただければと思います。

伊藤さん：Googleが初めにSREを定義し、我々もSREを名乗って仕事をしています。その根本にあるのは「信頼性」だと思っています。これをいかに開発組織の中に定着させるかというところがSREの大きな役割ではないかと思っています。そのために自分達がエンジニアリングを行うことで安定性を高め、周りの開発者も含めて信頼性に関心をもってもらえるように、様々な仕組みを整えることがSREの根幹ではないかと考えています。「SREは文化だ」という方もいらっしゃいます。そういう雰囲気を開発組織全体に広げていくかが、一番おもしろく、一番難しいところだと思い、頭を悩ませています。

門畑さん：非常に共感します。SREはプロダクトチームと比較すると見えづらい。セキュリティ施策をやっても、セキュリティインシデントを起こさないことが大前提。起きてしまった時はもうアウト。顕在化しないとありがたみがわからない。啓発活動を行ったりガバナンスを効かせていくところは重要ですね。

川岡さん：セキュリティ周りは大変ですね。弊社の募集要項は「SRE/Cyber Security」となっています。要するに、セキュリティもやってくださいという募集です。SREの本質は信頼性そのものより、サイトの信頼性を「エンジニアリング」することだと思います。言葉のあやのようにも聞こえますが、信頼性ということだけを切り抜いたときによくありがちなのが、信頼性を拡大解釈して「セキュリティもSREにお願い」というのが日本企業に多いと思います。「SREに対する意識調査（メタップス調べ）」の結果で、SREの業務の3割が「セキュリティ脆弱診断などの対応」でした。SREへの期待値の約7割も同じく「セキュリティ脆弱診断などの対応」でセキュリティがついて回ります。しかし、いわゆるSRE本（SRE サイトリライアビリティエンジニアリング -Googleの信頼性を支えるエンジニアリングチーム）の中には信頼性という文脈においてセキュリティが語られている箇所はあまりないと思っています。セキュリティエンジニアという、そのプロがいるなかで、それをSREが担うのは大変だと思います。

門畑さん：おっしゃる通りですね。UPWARDでもSREのなかでセキュリティの高度化の役割を担っています。セキュリティだけでも奥が深い中で、非常に大変な役割を担っていると思います。

SREのやりがい

門畑さん：最後にSREのやりがいを伺っていきたいと思います。

まずは私からですが、SREの業務は多岐に渡ります。Googleの定義したトイルをできるだけ削減するという点は共感しており、手作業で定常的に発生する業務を、頭を使ってエンジニアリングで解決して仕組み化してスケールさせる。それにより、より重要なエンジニアリング業務に注力していきます。いわゆるコンサルティング業務のような課題を発見し、体系化・文書化し、またエンジニアリングし解決するといった多岐にわたる業務範囲が面白いと思います。また、プロダクトを横串で俯瞰して見れるところがSREならではの魅力だと思います。

川岡さん：私が思うやりがい。昨年のサッカーワールドカップで、大量のトラフィックを難なく対応したAbemaTV。ユーザーはそれを気にせず使えた。あれはやりがいもあるしかっこいいと思いました。一時のスパイクを捌くのもそうですが、組織が拡大期に入って、人数が増えてシステムが増えてもなんなくスケールできる仕組みを作ることがやりがいでありかっこよさだと思います。

伊藤さん：同じように、テックタッチでもいかに大量のリクエストを捌けるかというのもひとつのSREの役割です。たとえば実際大手のお客様が導入してくださってリクエストがどんどんくるぞという状況でも、当たり前にこれを捌いていくことが求められます。SREなのでいろいろなメトリクスを眺めながら、自分たちのやっていることがワークしているかを見ていきます。そして、その結果を実際にメトリクスの形でチーム・組織にも共有することができます。表に出にくい仕事でありつつ、メトリクスで見える形にして全社共有することで、SREとして業務に貢献できることも実感できます。インフラも見つつ、結果を見るところまで自分たちで考えていけるところが面白さではないかと思います。

門畑さん：自分たちが考えた仕組みが、いざトラフィックが集中したときに問題なく動作しているのを確認できたときはSREの喜びであり、醍醐味だと思いますね。

（文・上野なつみ）