クラウド時代の運用保守に求められるSREの考え方とは
スリーシェイクは2015年創業。社名はインターネットで接続を確立する手順「three-way handshaking」を由来とし、クラウドネイティブな技術に強い。なかでもSREを熟知したエンジニアが多いのが特徴で、SREの戦略策定から構築や運用までを支援するサービス「Sreake」を提供している。スリーシェイクのSRE領域に対する知見の確かさは、その提唱者であるGoogle CloudのオンラインセミナーでSREの解説をしていることからも伺い知ることができる。
あらためてSREの背景にあるIT基盤の運用保守に目を向けてみると、ここには長らく難しい問題が内在している。特に、作業に繰り返しが多いこと、属人化してしまいがちで誰かに作業が偏ってしまうことなど、読者のみなさんも多かれ少なかれ感じたことがあるのではないだろうか。また、システム障害の発生の起因としては、何らかの更新が加わったタイミングが最もリスクが高いということもある。運用保守の現場では、大小さまざまな困難を日々乗り越えつつも、何らかの懸念や危うさのようなものがうまく可視化されないまま常に横たわっている。
手塚卓也氏は運用保守の実状について「2000年代など、古い時代に構築されたシステムはいわば“塩漬け”を前提としていました」と指摘する。一度構築したら問題がない限り、変更を加えることなくそのまま運用を続けるのが当然のような感覚だ。しかしインフラをクラウドに移し、頻繁にアプリケーションを更新することが求められる現在では、そういうわけにもいかなくなってくる。こうした課題感に「SREの考え方が参考になり、生きてきます」と手塚氏は言う。
例えば金融機関の基幹システムもかつては塩漬けが多かった。しかし今ではスマートフォンアプリを介したQRコード決済やポイント払いなど、決済サービスが多様化している。塩漬けした基幹システムだけを保守すればいいなんてことはない。「それでは時代に追いついていけません」と手塚氏。
とはいえアプリケーションやインフラで更新を加えれば、前述の通りリスクも増加する。そのために今はリリースサイクルを早めながらも、サービスの信頼性を維持していくことが求められている。だからこそSREが重要になってくるのだ。
もともとSREはソフトウェアエンジニアが担うものと考えられている。というのも、SREとは運用保守に関するものをソフトウェアエンジニアに依頼する時に生まれる仕事が多いからだ。しかし日本においては、SREは運用保守の領域にあるためかインフラエンジニアが担当するケースが多いのが実状だ。
手塚氏は「ソフトウェアエンジニアでもインフラエンジニアでも、SREはどちらのルート出身でもいいと思います。いずれにしても1人で担えるものではないですから。SREが担う領域は広いため、いろんな挑戦があります。そこはキャリアの視点から見ると魅力的に映るのではないでしょうか」と話す。
また、サービスが維持できていれば、具体的なところは「ふわっと」曖昧に済ませているところもあるかもしれないが、後述のようにSLO（サービスレベル目標）やさまざまな統計値を使いこなせるようになると、経営やビジネスのメンバーと会話しやすくなる。
このようにSREは多くの価値をもたらすことができるものの、その実現には広範にわたる技術が求められることから奥が深く、導入も単純ではない。そこで、スリーシェイクのような専門家集団が求められる。手塚氏は「私たちが持つ数多くの事例やノウハウが一番の価値だと思います。言い換えれば引き出しの多さです。あらゆる環境や状況でも最良の解決策を提案できます」と話す。
SREの導入はそう簡単ではない。最初はプロフェッショナルの知見を参考にしながら進めることが一番の近道ではないだろうか。
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提供まで、幅広い領域をサポートします。
