こんにちは、3月までSREチームのマネージャーをしていた和田です。今回は、私がSREチームを担当した２年間で考えてきたことをご紹介します。
背景
SREチームは2019年度まで、AI・IoTプラットフォームサービス「OPTiM Cloud IoT OS」の運用を担っているチームでした。当初から「SRE」と銘打っていたものの、実際上は案件対応やリリース・インシデント対応などの運用作業に追われる日々で、なかなか改善活動にパワーを割けない状態が続いていました。そこで、改善活動に一定のリソースを割り当て続けるために、2020年度からの挑戦として、インフラ運用チーム（案件対応やプロダクト運用を担う）と、SREチーム（中期的な改善活動に専任で取り組む）とにチームを分けて改善活動に取り組んできました。
インターネットに接続するデバイスが世界で450億台に到達すると言われる時代の中で、オプティムは様々な産業向けのキラーサービスを通してその全てのデバイスに価値を提供すべく、新サービスを投入し続けることを戦略としています（社内では「バッターボックスに立ち続ける」と言ったりしています）。
このような背景の中で、2020年度にSREチームを個々のプロダクト運用から少し離れた立ち位置で建て付けるにあたっては、オプティムが新サービスを次々と生み出すことを支えるチームとしたいと考えました。そこでSREチームとして「オプティム提供サービスの早い・安い・安心をエンジニアリングの力で実現する！」というミッションを掲げました。
- 早い: インフラ基盤や開発・リリースのプロセスなどの標準化・共通化を行い開発のリードタイム短縮と運用の効率化
- 安い: 売上とコストをリアルタイムに可視化しコストを最適化
- 安心: プロダクトのフェーズにあったサービスレベルの定義と達成のサポート（セキュリティ、稼働率、性能、運用体制など）
- エンジニアリングの力: トレードオフ関係はあるが、複数の課題を突破できるのは技術の力。オーバーエンジニアリングしないのも技術力。
（なお、株式会社メルカリ様のテックブログ記事によると、SREの類型を示した記事では、SREチームのこういうあり方を "Center of PracticeとしてのSRE" と分類しているそうですが、私は当時はこの言葉は知りませんでした）
取り組みテーマ
この２年間の取り組みテーマは、大きく３点あります。
- Production Ready活動
- コスト最適化活動
- OPTiM Cloud IoT OSのリリース改善活動（平日日中リリースに向けた取り組み）
そして、唐突に告知ですが、「OPTiM Cloud IoT OSのリリース改善活動」については、AWS Summit Online 2022の5/26 事例セッションにて「Amazon EKS への大規模移行を実現した「OPTiM Cloud IoT OS」のいまとこれから」というタイトルで紹介しますので、ぜひそちらもご覧ください！
今回の記事では、「Production Ready活動」「コスト最適化活動」について紹介します。
また、本テックブログの過去記事でも、個々の取り組みの詳細をご紹介していますので、ぜひご覧ください。
Production Ready活動
Production Ready活動は、各プロダクトのサービス品質を標準化していく取り組みとして推進しました。
- 共通のドキュメント（Service Docs）で、プロダクトの状態/特性/品質が誰でもわかるように
- プロダクトのフェーズに応じて適正なサービス品質を実現（品質底上げ（+過剰品質防止））
- プロダクトを横串でみて、改善活動の優先順位をつけて、また改善活動の成果を測定
社内説明用にSREチームのメンバーと作成した資料を発掘したので、キャプチャを貼ってみます。
この取り組みに際して、プロダクトの「フェーズ」の言語化に取り組みました。
オプティムは、新サービスを投入し続けることを戦略としており、ローンチまでのスピードを重視しています。2021年度は７つの新サービスをリリースし、企画検討が本格化してからβ版リリースまでは半年程度というサービスも少なくありません。
一方で、過去には、リリースしたサービスの品質への期待値が社内で擦りあっていなかったことにより、悲しい思いをしたケースもありました。
そこで、プロダクトのフェーズと到達品質基準を定義して、マネジメント・ビジネスサイド・エンジニアを超えた共通言語化することで、品質の期待値を合わせることを目指しました。逆の目線では、過剰品質に陥らずに各フェーズまでの到達リードタイムを短縮する、試しに限定公開してみることを可能にする試みでもあります。
全社的な運用定常化は道半ばではあり、サービス品質基準の項目や各フェーズでの到達基準もブラッシュアップを続けていますが、この１年間でもプロダクトのフェーズという考え方は浸透してきたように感じます。
各サービス品質項目に対してフェーズごとの到達基準を定義し、各プロダクトにアンケートを取ることで、実際の到達度の可視化にも取り組んでいます。こういった可視化も継続的な改善活動を支える土台になってきていると感じます。まだまだ課題もありますが、実際に2021年度の下期では、延べ30項目程度（プロダクトx 改善項目）の改善実績が確認されました。
また直近では、下記にも取り組んできています。これらについても、またどこかの機会で紹介できればと思います。
- SLI（特に可用性と性能）の測定方法の標準化およびDatadogダッシュボードを活用した一元化
- セキュリティについて、サービス品質と同様にチェックリストを作成して、各プロダクトの状況を可視化
コスト最適化活動
コスト最適化活動は、下記KPIを可視化して、各チームでコスト最適化の営みが自律的に運営される状態を目指して取り組んできました。
吹き出しにも検討当時の気持ちが現れていますが、このKPIには下記のような思いを込めています。
- 社内でさまざまなフェーズのプロダクトが存在する中で、同じ基準で比較できるように
- プロダクトが軌道に乗り始めたことを判断する基準の一つが、単月黒字（単月ライセンス売上（MRR） - 単月保守運用費 ※投資は除く）としているのでそれ自体をKPI化
- ※軌道に乗り始めた段階のプロダクトは、プロダクトによっては投資を加速していて、投資を含めたプロダクト収支は赤字の状態が続くこともあります。
- 保守運用効率を向上するマネジドサービスや有償ツールを積極的に導入できるKPI設計（費用対効果を判断しやすいKPIに）
そして、コスト可視化DBの構築に取り組んできました。
目指す姿は上記の通りですが、まだまだ要改善項目も多い状況です。
- 各コスト要素（ex. AWSアカウントやAzureサブスクリプションなど）とプロダクトとの紐付け運用の効率化
- 各プロダクトの開発マネージャーに聞いて回らないと判断つかないものも多く、運用負荷が高い
- 支払い先ごとに締めタイミングがバラバラなため、月次フィックスまでのリードタイムが長い（精度より早さを重視したデータ取得方法の確立）
- インフラ共通基盤のコストの各プロダクトへの按分ロジックの確立
- Amazon EKSのWorker Node、セキュリティ製品のライセンス費用、モニタリングツールなど
- Reserved Instancesなどを適用した際の、前払い費用の利用期間への配賦
- 配賦以外に、移動平均などで見る選択肢も考えられる
- サービスの成長によるコスト増を切り離して、コスト最適化施策の成果（コスト削減幅）を測定する方法
２年間の活動を通して、データを見ながら、コスト最適化し続ける文化は少しずつ育ってきたように感じます。2021年度を通しても、運用作業面では月次作業の効率化、インフラコスト面でもReserved InstancesやSavings Plansの適用、RDBダウンサイジング、不要環境クローズなどによるコスト最適化が各プロダクトで進んできました。
下記は、とあるプロダクトでの労務費の投資と保守運用の比率の実績です。このプロダクトでは、保守運用が安定してコストグリップ力が高まり、リソースを投資に振り分けられる比率が大きくなってきていることが分かります。
ふりかえり
ここまで、私がSREチームを担当した２年間で考えてきたことをご紹介しました。
この２年間をふりかえってみると、、、
- 「測定できないものは改善できない」ということで、KPI設定や可視化に注力。
- サービス品質もコスト最適化いずれも、一定の成果が挙がっており、その成果を可視化もできている。２年間の活動を通して、皆が同じデータを見ながら、各プロダクト/チームで自律的に改善活動を進めていく文化を少し前に進めることができた。
- Service Docsなどの運用も定着しつつある。
- SREと開発・運用チームとでローテーションをかけるのも良いかもしれない。
- 何を標準化し、何は各プロダクト/チームの自治とするかは悩ましい（悩み続けるしかない）。
- Docker Imageを責任境界として、Containerの中は自治、Containerの外側（外側からの観測手段含めて）は標準化、というのは一つの分かりやすい線引きではあるが。
- 開発基盤（ツール類）、開発プロセスも、どこまで標準化すべきか悩ましい。SREチームが開発プロセスのどのフェーズからどう関わるべきか悩ましい。
- SREチームとしては、辛さを感じる場面も。。
- プロダクトの運用そのものから遠ざかることで、だんだんと課題の肌感が掴みづらくなってきた。
- 横串活動をファシリテートするチームの辛さを感じる瞬間も多い。
- 基本的にお願いして回ることになり、各プロダクトの中でその時々の緊急度の高いテーマと比較して優先度が上がりづらい
- プロダクトへの貢献の実感や、SREとして掲げたミッションに対する責任を持ちづらかった。
- この２年間の注力テーマや選択したアプローチに起因し、「エンジニアリング」できている感覚が乏しい。
- 自動化や構成管理の標準化などをもっと進めたい。
- サービス品質・セキュリティ・コストなどの可視化も、手作業に頼る部分が多く、自動化に取り組めている領域が少ない。
上記で、私がSREチームを担当「した」２年間と記載しましたが、上記のふりかえりも鑑みて、この４月からSREチームは再度インフラ運用チームと統合し、各自がプロダクト運用を担って信頼性に責任を持ちながら、バーチャルチームで改善活動に取り組むことにしました。この先のSRE取り組みについても紹介していきたいと思いますので、ぜひ引き続きご期待ください！
さいごに
前述のように、オプティムは新サービスを投入し続けることを戦略としています。私は、そのために、各サービス固有の価値・技術の外側にある横断的関心事を共通化・底上げしていくことが重要だと考えています。
OPTiMでは、SREに興味がある方、あらゆる横断的関心事の強化に興味がある方、そしてもちろん各プロダクトの開発・運用に興味がある方を、職種を問わず幅広く募集しています。
