増えるエンジニアに求められる役割、「いい塩梅」を実現するには？
――SREに関する開発現場の課題として運用負荷、スキルセットの違い、プロダクトの成長に合わせた技術選定などが出てきました。
手塚：あとは責任分解点をどうしていくか。例えば「APIで会話しろ」というのは、大規模組織であれば、コミュニケーションという最もオーバーヘッドの大きい作業を省略できるため効率がいい方法だと考えます。だからといって小さいチームでこれを実施しようとするのは非現実的ですし、逆にスピード感を下げてしまう要因にもなりうると思います。プロダクトとチームの成長を考えて、意識的に設計していく必要があると考えています。
塚越：「自分が作ったものは自分で運用しなさい」という考え方が広まってきている一方、エンジニアに求められるものが増えてきているとも感じていて、どんなフェーズでどんな選択をするかという意味で「いい塩梅」が大事だと思います。まじめ過ぎるとオーバーヘッドで遅くなってしまうので。
手塚：たしかに、プロダクトの技術選定でも「いい塩梅」って大事ですね。私の領域で言うと、SREにおいて信頼性のレベルを捉えて技術選定を行うことは非常に重要だと思っています。信頼性がないと顧客が離れてしまう可能性が高いためプロダクトは売れません。しかし仮に高度な信頼性を極めたからといってプロダクトが売れるとも限りません。
信頼性や拡張性ばかり意識して技術選定しても、プロダクトが成長するかどうかは別問題。一方で将来のための技術選定がないと後のフェーズで不利になることもあります。その「いい塩梅」を見極めることが大切です。それが難しいところではあるのですが。
――これまで出てきた課題にSRE的なアプローチをすることでどう解決できるでしょうか？
手塚：SREで私が好きなエッセンスはユーザー視点とデータドリブンです。SLO（Service Level Objective：サービス提供側が達成すべき目標）を定義してその数値というデータを基に開発と信頼性を高める活動を進めるやり方はGoogleさんらしいかもしれません。例えば運用負荷の課題に対して、ユーザー視点でSLOを定義して、開発や運用に必要なものを整理していくアプローチは短期では効果はわからないかもしれませんが、長期的に続けていく中で効果が発揮されるものかもしれません。
塚越：まさにそうですね。サービスによりSLOやどこが「いい塩梅」なのかも異なってきます。そこでユーザーを見ずにSLOを設定してしまうと、全く意味がありません。「いい塩梅」を決める際に、ユーザー視点で決めると良いのではないでしょうか。
――「FaaS負債」など、マネージドサービスが増えすぎて運用負荷が上がってしまう場合はどうでしょう？
塚越：個人的にはマネージドサービスを使った設計をする際にDDD（ドメイン駆動開発）を組み合わせると相性がいいと思います。ドメイン単位で機能を閉じていくと、機能を小分けにしやすい。それに伴い、機能に求められるSLOも変わってくるので、1つのサービス下に大量にサービスがあるよりは、ドメインごとに機能がある形にすると多少はマシになるのでは。
手塚：確かにクラウドの恩恵は手軽さと捨てられることに凝縮されると思っています。DDDだとその手軽さを十分に活用できますね。
――技術選定とプロダクトの成長についても、SLOやユーザーストーリーが決め手となりそうですね。責任分解点はどうでしょう？
手塚：繰り返しになりますが、マネージドサービスやサーバーレス系を使うと、アプリケーションとインフラの境界が無くなりますので、そのパラダイムに合わせて組織を設計していく必要があると思います。
塚越：それってコンウェイの法則の発想ですよね。ちょっと本筋からずれてしまいますが、最近はシフトレフトの流れもあると思います。テストにしても、セキュリティにしても、早めに取り組むような流れ。開発が終わってからテストをするのではなくて、最初にテストコードを書いて、早めに失敗して、早めに見直すようなプロセスです。SLOや ユーザーストーリーに加えてこういったことも重要なんじゃないかなと思います。
――組織を変えていくことについては？
手塚：かつて関わったプロジェクトではゼロから組織を立ち上げました。既存組織に手を加えるのではなく新しい箱を作り、そこに合う人を増やして文化を作って行くという方法をとりました。既存の形を変えることは相当に難しいため、新しい箱で新しい風を吹かせたうえでその流れを作ることのほうが大規模な組織の場合には有効に思えます。
塚越：最近大手企業でもよく聞くようになりましたね。一方で、そういう足かせがないスタートアップは有利で、一気に先駆者になることもできるんじゃないでしょうか。
SRE的なアプローチの実践は難しい？ Google Cloudの便利な機能とは
――明日から開発者がマネージドサービスやコンテナを活用する時、Google CloudだとCloud Runなどが相性良さそうに思えるのですが。
塚越：まさにピッタリだと思います。加えて「まずは使ってみて」と言いたいです。本当に難しくないので。一度試したら感覚がつかめるとおもいます。オススメは、まずはサンプルコードのデリバリーを試してみて、少しずつ機能を追加していく。そして、そこにデータベースを追加するという進め方なら覚えやすいと思います。
――便利な機能やおすすめの機能はありますか？
塚越：最近機能がいろいろ追加されています。例えばGitHubのリポジトリがあれば、Cloud Runからリポジトリを指定すれば、5分くらいでCI/CDパイプラインができあがるので自動化を組みやすいと思います。後はSLOモニタリングの機能もついているので簡単にSRE的なアプローチも始めやすいです。
――運用負荷が高まるケースでも役に立ちそうですか？
塚越：フルマネージドサービスなので、コンテナを乗せればスケールします。ミドルウェア以下を気にしなくていいので、開発に集中できるかと。
手塚：元々インフラエンジニアをやっていた身からすると、今までのミドルウェアまでの管理はしんどかったです。Cloud Runだとそれを管理しなくてすむのは圧倒的な差になると思います。あと一通りの監視が入っているところもいいですね。ログもメトリクスも標準で拾ってくれます。もちろんそこからチューニングする必要はあるのですが、60点くらいまでやってくれるのはすごくいいなと思います。
塚越：あとはSLOモニタリングも便利。
手塚：そうですね。2ステップで設定できるので、初めて触るのであればよいのでは。
――ユーザーストーリー観点で便利な機能はありますか？
塚越：アプリケーションデプロイ周辺だと、簡単にロールバックできるようになったことかな。デリバリーして失敗したら、1つ前のリビジョンに戻せばいいので、新しいものをすぐに世の中に出すためにも切り戻しが楽というのはメリットになると思います。
手塚：あと観点が変わってしまいますが、サービス運営で後からつらくなるのがデータ活用分野です。それを考慮しないアーキテクチャでアプリケーションを組んでしまうと後々苦労してしまう。Google CloudならBigQueryが強いので、使いこなせるアーキテクチャにしておくといいですね。
塚越：あとエンジニア育成の観点だと、セキュアなサンドボックスを提供できるといいと思います。最近はConfig ControllerでYAMLを使ってリソース管理がでできるようになってきていて、プロジェクトの払い出しとか、フォルダ作成、ポリシーもYAMLで宣言的に管理できるようになるのです。
エンジニア育成には好きに使える環境を提供することが大事です。好きに作れて、好きに壊せる。しかし仲間と共有していると、下手に壊したら怒られる。だから冒険しない。そうすると学ぶ機会がなくなってしまいます。ですのでポリシーを効かせて、すぐに払い出せるような、セキュアなサンドボックスがあるとエンジニア育成に役立つのではと思いました。
手塚：共有環境でネームスペースとか間違えてしまったら大変ですからね。
――最後に読者にメッセージをお願いします。
塚越：アーキテクチャをデザインする際に、ユーザー視点やユースケースは大事かと思います。当たり前に聞こえるかもしれませんが、技術に集中してると意外と忘れやすいポイントです。あと何よりも、行動することが大事ですね。ぜひCloud Run 動かしてみてください。（笑）
手塚：作業とエンジニアリングは違うということだと思います。技術的な課題を解決することも大事ですが、プロダクトの成長を考え、価値あるエンジニリングをすることも大事です。そうしたことを意識してもらえればと思います。
