SREを実践するための4ステップと、それぞれのポイントを解説
ここからはGoogle Cloudが開催したオンラインセミナー「App Modernization OnAir」にて、手塚氏が登壇した「実践 SRE ~ Google Cloud 活用した SRE の実践 ~」からエッセンスを紹介しよう。ここではSREの基本的な部分は割愛し、SREの実践のためのアプローチとそのうえでGoogle Cloudを用いる際のポイントについて解説する。
前半はSREの実践のためのアプローチ。スリーシェイクではSREロードマップをSREチームの定義、SREの開始、SRE実践、SREの発展と継続という4つの段階で分けている。
Sreake流 SRE ロードマップ
まずは「SREチームの定義」。ここは組織にSRE文化を定着させるための最初の一歩だ。このステップについて手塚氏は「システマチックではなくウェットなところもある」と話す。
SREチームに限らず、組織を組成あるいは改革する時には失敗するケースに見られる兆候がいくつかある。それは「組織の役割が曖昧で目的が浸透していない」「周囲や上層部から理解が得られていない」「非現実的な目標を立ててしまう」「新しい活動に割けるリソース（人手や時間）がなくコミット量が少ない」などだ。手塚氏は「当事者や周囲が冷めてしまったら終わりです。いかに熱量を保てるかが重要です」と強調する。
Google CloudはSREとDevOpsの違いについて、DevOpsは思想的なものであり、SREはその実装であるという表現をしている。具体的にはDevOpsの「組織のサイロ化を無くす」という思想に対して、SREでは「同じツールやテクニックを使用して、開発者とオーナーシップを共有する」という実装によって解決するということだ。よって、新しい思想や実装を取り入れる為の組織的土壌が必須となる。
また、SREは開発（Dev）や運用（Ops）だけではなく、ビジネスも含め、あらゆるレイヤーと密接に関わる。それゆえにSREへ依頼が殺到し、本質的なことに手が回らなくなるという罠もある。手塚氏は「SREはSREチームだけで成立しません。役割を明確にして理解を得るようにしましょう」と呼びかける。
続いてロードマップの2番目はSREの開始。SREの実践内容はとても幅広い。主な例だけでも、監視基盤導入、SLI/SLO定義、運用体制整備、IaC、CI/CD導入、アプリケーションのパッケージ化、パフォーマンス分析がある。これを複数のサービスにわたり、一気に全て実行するのはまず不可能と考えていいだろう。手塚氏のおすすめは「ひとつのサービスから、小さく始める」こと。できればしがらみの少ない新規サービスから小さく始めて、SREチームとして成功体験を重ねていくのが良い。
加えて、SREはデータを基に意思決定ができる世界、いわばデータドリブンな世界だ。そのためデータがそろわないと話にならない。あらゆる情報を収集し始めることが欠かせない第一歩だ。
そしてロードマップの3番目はSRE実践。SLI（サービスレベル指標）やSLOを設定し、後述のToilを削減していく。最終的には上質なSLOを目指すものの手塚氏は「最初のSLOはざっくり決めてしまうのもひとつ」と言う。SLOはサービスの成長に応じて変更してもいい。「それより大事なのがビジネスや開発を置き去りにせず、共通認識の獲得を意識しながら設定していくこと」と手塚氏は説く。
そのうえで手塚氏は「上質なSLOを目指していくためにも、データの収集が重要」と、再度強調する
またSREで大事なのがポストモーテムの実施だ。インシデント後のフォローアップアクションを書面で記録することで、振り返りから学ぶ。そのためには障害解析で追跡ができるようにしておく必要がある。SRE関連の書籍にサンプルフォーマットがあるので、流用するのがいいだろう。何よりも大切なのは「特定の個人を非難しない文化」と手塚氏は強調する。あくまでも問題はシステムや仕組みにあると考えるためだ。これは心理的安全性を保つことにもつながる。
Toilの削減にも触れておこう。Toilとは手作業、繰り返される、サービスの成長に比例して増加するといった特徴がある作業であり、具体的には開発チームからの依頼対応、障害対応、定型業務などだ。まずはこれらを全て測定することから始め、特定し、自動化で削減するというサイクルを回していく。
Toilを削減するために
ロードマップの4番目はSREの発展と継続。ひとつ成功体験を得られたら、他のサービスにも展開し、振り返りを通じてさらなる改善を重ね、自動化を促進していく。こうして文化を浸透させていく。
Google Cloudで実践するSRE、連携すべきサービスとは？
後半はGoogle CloudでのSRE実践を紹介する。クラウド活用では、エンジニアがクラウドネイティブな技術に詳しくないとサービスをうまく使いこなせず、モダナイゼーションを実現できない。場合によっては可用性や信頼性で問題を抱えてしまうこともある。一方で、エンジニアが詳しすぎて、要件に対して過剰に高度な技術を採用して複雑化してしまうこともある。手塚氏は「モダンで、オープンで、さまざまな指標が可視化され、かつ構成変更が容易なシステム構成が至高である。言うは易く行うは難しだが、ここを目指したい」と話す。
まずはワークロードについて。Google Cloudにはマネージドからアンマネージドまで、さまざまな実行基盤がある。機能要件や非機能要件を十分考慮するのが大前提だが、まずはApp Engineなどマネージドを検討した上で、Cloud Functions、Cloud Run、Kubernetes Engine Autopilot モード、Kubernetes Engine Standard モード、Compute Engineなど「アンマネージドなサービスに降りていくようなイメージでワークロードを選定するのもひとつ。いかに楽にできるかという観点も大事」と手塚氏。
続いてCI/CD。テストを自動化したい（CI）、簡単にデプロイしたい（CD）などの目的がある一方で、忘れてはならないのが「障害発生の多くは人間が手を加えた時」であることだ。「そのためCI/CDとはリリースサイクルの向上と信頼性の両方を担保するためのアプローチであるべき」と手塚氏は言う。
手塚氏はKubernetesでCD/CDを実践する場合のワークロード例を示した、まずはKanikoでイメージをビルドし、trivyでセキュリティスキャンをかけ、問題なければArtifact Registryにプッシュする。プッシュ済みのイメージはArtifact Registryのイメージスキャンを利用して、Cloud Functionsで通知する。一方、ArgoCDでGitの変更を検知したら、Argo RolloutsがPrometheusのメトリクスを見てデプロイするという流れになる。
CD/CD（Release Engineering）
モニタリングとロギングへと移ろう。Google Cloudではあらゆるサービスがデフォルトで連携され、SaaSとして監視基盤を利用することが可能なので工数を減らせるというメリットがある。Anthos Service Mesh、Istio on GKE、App Engineは自動的にSLO Monitoring対象のサービスとして検出されるため、マイクロサービス運用しているならこれもメリットとなるだろう。またプロジェクトとサービスで使用されているGoogle CloudとAnthosのアセットを全て表示、モニタリング、分析できるCloud Asset Inventoryも有効だ。
アラートとインシデント管理ではGoogle CloudとPagerDutyの組み合わせることでSREを加速させることができる。Google Cloudのオペレーション製品やCloud Functionsと連携し、オンコールやチャット通知、インシデントの履歴記録が実装できる。さらにJiraなどのチケット管理ツールとも連携できるため、Toil測定やエラー予算管理などにも役立つ。
最後に手塚氏は「GoogleのSREは素晴らしい見本となります。しかしSREにはウェットな部分も多いのが現実です。自分たちの組織やメンバー構成を考え、最適なSREを実現していきましょう」と呼びかけた。
SRE総合支援サービス「Sreake」
Sreake（スリーク）は、金融・医療・動画配信・AI・ゲームなど、技術力が求められる領域で豊富な経験を持つSREの専門家が集まったチームです。戦略策定から設計・構築・運用、SaaS提供まで、幅広い領域をサポートします。
