はじめに
こちらはSRE Advent Calendar 2022の14日目の記事になります。
Googleが"イノベーション加速"と"信頼性担保"を両立するための新しい運用プラクティスとして SRE(Site Reliability Engineering) を提唱してからしばらく経ちました。
"Site Reliability Engineering(通称:SRE本)"からはじまり、O'ReillyからはいくつかSREの派生本が生まれています。
その中の"SREの探求"という本では、様々な経歴の方々が"SRE"のキーワードのもとにどのようにSREを実践していくのかやなぜSREが進まないのかなど、SREを実践する上での成功事例や課題が語られています。
この本を読むと、SREの導入や推進においてはまだ決められた枠組みはなく、どの企業も手探りで推進されていることがわかります。ページ数も600越えということから、いかにSREというプラクティスの奥が深く、みな試行錯誤しながら組織を組成・変革しているのかが伺えます。
つまりSREとはいまだ発展途上の考え方であり、導入する組織の状態や扱うアプリによって適切なアプローチは異なります。
その中でも日本のエンタープライズ企業では特にSREの導入が難しいとされています。
そこで今回は、私なりに エンタープライズ企業におけるKubernetesを使ってSREを導入するまでのステップ をまとめてみました。
様々な方法がある中のひとつの参考として、お手隙の際に読んでいただければと思います。
エンタープライズ企業でSREの導入が困難な理由
チームミッションとフェーズの分断
これまでのエンタープライズ企業では、だいたいの場合開発フェーズと運用フェーズが明確に分断されており、一度アプリを構築してしまえばほとんど変更が加わらないため、アプリ・インフラを含め運用チームが運用フェーズの対応を行っていました。
しかし昨今のビジネスニーズの変化に追随すべく、イノベーションの加速の優先度が上がり、アジャイル開発やコンテナの導入を全社施策として掲げる企業も増えてきました。
しかしこのアジャイル開発は開発フェーズのみに適用されることが多く、スクラムでそれっぽく作ったはいいものの、一度リリースしてしまうとその後は運用フェーズとして運用チームに引き継がれていくケースが多いです。
するとイノベーションの加速というミッションを持たず、信頼性の担保やコスト削減をミッションとしている運用チームは、従来の運用手法を踏襲しようとします。
その結果、アジャイル開発しているのにイノベーションの加速ができないどころか、従来(VMベースのアーキテクチャ)とは異なる運用を強いられいたずらに信頼性の低下やコスト増が発生する可能性があります。
このような状態では、イノベーションの加速と信頼性の担保を両立しようとするSREの考えは浸透せず、結果だけを見た上層部は「我々にアジャイル開発は適さなかった」という結論に至ってしまいます。
アプリチームにSREの一部を担当してもらう
そこで従来の運用チームの負担を和らげ、共にイノベーションと信頼性を両立するために、アプリチームにSREの業務の一部を担ってもらうことを考えます。
ここで言うSREの一部の業務とは、アプリケーションのセキュリティやコンテナのリリースサイクル、アプリ起因の障害の検知・対応といったアプリに関する非機能まわりの運用のことを指します。
一方で従来の運用チームは、信頼性の担保の範囲をプラットフォームレイヤまで下げ、その代わりに複数のアプリが載る共通的な基盤の運用や、自動化・自律化を活用したコスト削減を実施します。
そうすることで、運用チームの業務が逼迫してリリースに対応できないという事象を回避し、イノベーションの速度を維持することができます。
エンタープライズ企業が目指す体制
つまり、担当するアプリケーションごとに、よりアプリに特化した運用担当がいる、以下の図のような体制を目指すことになります。
それぞれの担当は以下の役割を担います。
-
アプリ開発担当
- スクラム導入による迅速・柔軟な機能実装
- コンテナ特性を活かしたCI/CDで開発スピード向上
-
アプリ運用担当
- アプリケーションライフサイクルの自動化に伴うビルド、テスト、リリースプロセスの最適化
- アプリのSLOの担保
-
インフラ運用担当
- アプリを横断したプラットフォームの提供
- 信頼性を担保しつつ開発機能の共通化で開発チームの立ち上がりをサポート
- プラットフォームとしてのSLOの担保
そして、アプリ運用担当とインフラ運用担当の2者でSREのプラクティスを実現していきます。
チームの成長フェーズ
エンタープライズ企業でコンテナ/Kubernetes環境を扱うにあたり、いくつかのフェーズが存在します。
ここでは便宜上、以下の３つのフェーズで考えていきます。
- スタートフェーズ
- アクションフェーズ
- スケールフェーズ
ぞれぞれのフェーズについて具体的に検討してみます。
スタートフェーズ
まずは一番最初にスクラムやコンテナ開発の導入を検討するフェーズになります。
体制
ここでは運用担当と開発担当がワンチームをつくり単一のアプリケーションをリリースすることで、コンテナ環境の一連の開発・運用業務を実践することが目的です。
そのため、開発の立て付けとしてはアジャイル開発の有効性の検証やKubernetesの開発・運用体験といったテーマのPoCという形をおすすめします。
その中でアプリ担当はコンテナを活用した開発手法でスピード向上を図ったり、運用者は開発を支える周辺機能の構築や商用環境の準備を行います。
アプリ／インフラ構成
アプリは簡易なWebアプリや社内システムなどを対象にすることをおすすめします。
いきなり大規模だと、マイクロサービス化やそれに伴うトレーサビリティの確保など難しい要素がでてくるため、Web3層くらいの規模のアプリがいいかと思います。
インフラは、作成・削除が簡単なパブリッククラウドを利用するとスムーズです。
これは商用運用に必要な要素(DBの冗長化、バックアップ、ドメインなど)をすぐに揃えやすいことが大きな理由です。
あとはスクラムに必要なコミュニケーションツール（Wiki/チケット管理ツール)やCICDツールを導入して開発スピード向上を実施してみてください。
なおここでの選定ツールは、この先の横展開を気にせず、このプロダクト特化のものでも構いません。
また一般的な非機能の要素は押さえましょう。
ここには6つほど要素を書いていますが、これらをKubernetes環境で実装するにはどうすればいいのか、そういう点をこのフェーズで体験してみてください。
そうすることで、コンテナによる開発と運用がどのように従来と違うのかを理解することができ、SRE導入のための土台ができてきます。
Role & Responsibility
スタートフェーズでは、先述した3つのロールではなく、アプリ運用とインフラ運用をひとつのチームで実行します。
ここで気を付けるべきは、開発時点で運用チームも巻き込んで設計・構築を行うことです。開発段階・運用段階に関係なく役割を分担します。
アプリ開発者は、主に開発スピードの向上やアプリの品質担保にフォーカスします。スクラムの導入やコンテナベースの開発、Git/CICDの活用など、従来とは異なる開発手法を採用するため、一時的に開発スピードが低下する可能性はあります。そういった点でもPoCの位置付けで行うことを推奨します。なおPoCの評価の際は、"慣れ"の問題によるスピード低下をそのまま開発手法の評価として受け止めないようにしてください。
インフラ運用者は、コンテナ・Kubernetesを使った開発をサポートする業務と、アプリが求める非機能要件を満たすことの2つにフォーカスします。
可用性の担保やモニタリング、セキュリティなど、さまざまな観点で従来とは異なる考え方が必要になるため、柔軟な思考を持つことが求められます。
またCICDパイプラインの実装もできれば巻き取れると良いかと思います。
テストコード自体はアプリ開発者が行うものの、ビルド→デプロイ→テストなどの一連のワークフローは運用者側で考えられると、後のフェーズへの移行がスムーズになります。
目指すゴール
スタートフェーズでは、以下のような目標を達成できれば次のフェーズに進めるかと思います。
- コンテナ／Kubernetes環境における運用業務を理解する
- Kubernetesクラスターの構築方法
- Kubernetesの各コンポーネントの概要と設定内容
- KubernetesにおけるCI/CD
- Kubernetesにおける最低限の非機能要件の実装方法
- Kubernetesにおける監視方法
なお、そのほかは以下の状態でもOKです。
- アプリ開発担当との役割分担が曖昧
- まずは必要なタスクを検討して実装することがメイン
- 作業の自動化が部分的
- 手動でできて初めて自動化ができる
アクションフェーズ
無事にアプリのリリース、運用まで経験できたら、次に複数アプリの運用に向けて、横展開を見据えた本格的な環境を整えるフェーズに入ります。
体制
ここでは１Stプロダクトの実績をもとに参画PJをつのり、複数アプリの運用に挑戦していきます。
ここでの運用担当は複数のチームのアプリ開発にまたがる形で構成しましょう。
そうすることで、今後の横展開を見据えた環境構築がスムーズになります。
構成例
複数プロダクトの搭載に向けて、ある程度の役割や構成を定義していきます。
- プロダクトごとにクラスターを作成していきます。よくひとつのクラスターで複数プロダクトを載せてNamespaceで区切る運用（マルチテナント）を行うユーザーが多いですが、アプリごとのSLOが異なるとアップグレードやバックアップなどのメンテナンスがうまくスケジュールできないといった事象が発生することがあるので、トータルコスト的にはアプリごとにクラスターを分割した方が良いと思います。
- 無論、アプリの特性や社内規約の関係からクラスターを共用する必要もあるかと思います。その場合は上記のようなプラットフォームのメンテナンスウィンドウをきちんと定義しておくことをおすすめします。
- 複数のプロダクトを運用するにあたり、個々のアプリならではの機能を活用するシーンもでてきます。ここではService MeshやServerlessを例としていますが、こういった特定のプロダクトで使うような機能はプロダクト個々で検討を進めます。
- CICDやモニタリングなど、明らかに他の案件でも共通的に活用できそうな機能は、あらかじめ横展開を見据えたツールを選定します。なおここではスタートフェーズに使ったツールにとらわれず、あらためて最適なツールを検討するプロセスを踏むことをおすすめします。
- 自動化もこのフェーズから段階的に始めていきましょう。部分的なIaC化や、Operatorを活用して将来の運用コストを削減していく取り組みを進めていきます。
- 上記のように、このフェーズあたりからだんだんとSREっぽい動きがでてきます。アプリごとにチームサイロ化しないよう、自身のプロダクトで得た知見を積極的に横展開し、コンテナ環境の開発・運用を促進します。
Role & Responsibility
このフェーズでは、運用チームが今後のSREとしてプラットフォームを展開していくにあたって必要なタスクをこなしていきます。
具体的には、マルチクラスターの設計や共通化を前提としたツール選定などがそのタスクにあたります。
そのほかにも、自動化・自律化によるトイルの削減やスタートフェーズ時にあがった課題の解決なども並行して行います。
目指すゴール
アクションフェーズでは以下のような状態を目指します。
-
複数チーム／複数クラスターにおける運用を理解する
- 権限管理やキャパシティ管理など、チーム拡大に応じた検討
- SREプラクティスの部分的な導入（Observability確保、Toil削減など）
- チーム間のコラボレーションの実現
- アプリ開発者との役割分担(案)の策定
なお、そのほかは以下の状態でもOKです。
- 役割分担はv0.1で良い
- 明確な分担よりもタスクを取りこぼさないことを優先
- SLOの導入は個々のプロダクトで個別に検討
- プロダクト個別に必要なメトリクスを収集
スケーリングフェーズ
横展開を考えて本格的な環境の構築を行い、複数のアプリが搭載されるようになったら、最終フェーズとして共通基盤としてのスケーリングを狙っていきます。
体制
これまではアプリの運用や開発環境のチューニングをインフラ運用担当の人が兼業で見ていましたが、ここからは各アプリ担当の中でSREの営みを推進してもらうように取り組みます。
具体的にはアプリ運用担当を配置し、アプリの信頼性向上、イノベーション加速に向けた取り組みを実施してもらいます。
SREはその業務をサポートしつつ、大規模な共通基盤へのスケールにそなえプラットフォーム機能の本格的な共通化を行います。
構成例
全体的には以下のような構成を目指します。
・・・といってもかなり複雑にみえるので、ポイントごとに図を分けながら説明していきます。
プラットフォームのテンプレート化
大規模なプラットフォーム提供者として、SREはクラスター構成だけでなく、CICDやモニタリング、セキュリティなどの共通的な機能をテンプレートとして準備しておきます。そして新しいアプリのオーダーがきたら、そのテンプレートからKubernetesクラスターを払い出します。テンプレートの中身については後述します。
また、新しいアプリのチームからアプリ運用者（Release Engineer）を配置してもらい、SREチームからコンテナ環境での開発方法やアーキテクチャの考え方をレクチャーしながら、アプリの非機能要件を満たすための検討を一緒に行います。
この役割はSREの中でも1〜2人程度担当者をアサインし、プロダクトSREとして対応することをおすすめします。
Release Engineerとの連携
アプリ運用者（Release Engineer）との連携を検討します。
アプリ運用者はSREからデリバリーされた環境上で開発環境の整備や商用リリースに向けた非機能要件の定義、および実装方法について検討を行います。
非機能要件を満たすための機能はテンプレートで補われている範囲もありますが、もし足りない点がある場合は案件個々に導入を検討します。この機能実装はSREとの連携が必要です。
プラットフォームテンプレートの改善
プロダクト個々で導入した各種プラットフォームの機能は積極的に共通化を図ります。
例えば、あるプロダクトでService Meshを導入した場合、その際の構築ノウハウや推奨設定、要注意事項などを振り返り、テンプレートに落とし込みます。こうすることで、次にService Meshが必要となるプロダクトが出てきた際にも検討の省力化が見込めます。このように、プラットフォームとしての仕様を横通しで見る部隊をテクニカルSREとして配置します。このプロダクトSREは、既存仕様の更なるブラッシュアップや先進技術の調査なども請け負います。
マルチクラスターの統合管理
最後に、多数のクラスターの状態を統合管理する運用SREを配置します。
この部隊はマルチクラスター管理ツールや統合監視ツールを活用して、SREが提供するプラットフォーム自体の健全性を担保する役割になります。
時にセキュリティの規約の変更だったりSREの運用ポリシーの変更によって、既存の全クラスターに対して何らかの処置を施す必要が出てきます。その際に各プロダクトが適切に処置が完了しているかの確認を行うのがこのチームに当たります。
モニタリング・セキュリティに長けた有識者を配置し、プロダクトSREやアプリ運用者と連携して運用設計やモニタリングダッシュボードの作成支援などを行います。
Role & Responsibility
このフェーズでは主にアプリ運用者（Release Engineer）とSREの役割をどう定義するのかが注目ポイントになります。
ここでは冒頭でも述べた通り、考え方としてはアプリ運用者がリリースプロセスの向上やアプリとしての信頼性担保の責任を負い、インフラ運用者（SRE）はインフラやプラットフォームとしての信頼性担保およびアプリの信頼性担保に関する支援を行う責任を負います。詳細なタスク分担は以下の図を参照ください。
プラットフォームテンプレートの提供
さて、先ほど触れたプラットフォームのテンプレートですが、具体的にどんなものになるのかを考えていきます。
これは開発プロジェクトが立ち上がった際に提供する開発環境と、それに付随する開発機能をパッケージとして提供する手法です。ここでのポイントは、単なるツール群の初期構築だけを行うのではなく、サンプルとなる素材も合わせて提供することです。
たとえばWeb３層の簡単なサンプルアプリ用のDockerfileやk8sマニフェスト、テスト自動化のためのCICDパイプラインのサンプルコードを提供することで、これからコンテナ開発を始めるPJがより早期に立ち上がりやすい環境を作っていきます。そしてアプリ運用担当者はそれをカスタマイズして自分たちのアプリに特化したマニフェストを作成していきます。
こうすることで大規模なクラスター運用でもきちんと役割を分担して業務遂行が可能になります。
SREプラクティスの本格導入
洗練されたプラットフォームを提供することで十分にイノベーションの加速に貢献でき、またノウハウが十分に溜まっているため、このタイミングで本格的にSREのプラクティスを導入することができます。
ソフトウェアエンジニアリングによる環境の改善を進めていったり、あるいはSRE導入の効果を最大化するために組織の文化を変革していく、そういう営みにもしっかり取り組めるかと思います。
このように、コンテナ導入＝即SRE導入ではなく、SREの要素は意識しつつもしっかりとSREを導入できるだけの土台をここまでで作り上げることが、エンタープライズ企業における重要なステップだと思います。
おさらい
ここまでフェーズごとの取り組みを細かく述べてきたので、いったんざっくりとまとめます。
SREの導入においても、小さく初めて大きくしていくプロセスが重要です。
開発者と運用者をワンチームとしてスタートし本格的な環境構築を経て本格的なSREのプラクティスを導入していく。そういうステップがエンタープライズ企業においては有効かと思います。
おわりに
ここで取り上げた導入ステップはあくまで一例ですが、何もない状態からSREの導入を検討することはかなり難しいかと思いますので、こういったプロセスを参考にしていただきつつ、SREチームを組成してみてください。