
皆さんが日々当たり前のように使っているサイト検索、Gmail、Map、Youtube。これらのサービスがいつでも使える状態に保つためにはこれまでとは違った開発・運用のアプローチがGoogleには必要だったのです。
そしてそれこそが今回お話するSRE(サイト・リライアビリティ・エンジニアリング)なのです。
コース全体の資料としてリソースにPDF版を添付しましたのでそちらをご利用ください。
ここでは、最初にコースのミスマッチを防ぐために、どのような方にとって必要となるコースかを説明いたします。
ここではなぜSREという考え方が生まれたかに関してご説明したいと思います。
ここでは、なぜSREがGoogleに必要だったかを理解することにより、SREの本質に迫ります。
Googleのように毎日何百、何千のサービスをリリース、もしくは既存のサービスのバージョンアップをしなければいけない場合、その都度両者集まり利害関係を調整などという流暢なことは言っていられません。いわゆるDevOpsという「開発担当者と運用担当者が連携して協力する開発手法」という概念が出てきたのも、もともとはこのような状況があったと考えてもいいでしょう。
このコラムでは、プログラマ、SE、コンサルタントを経験した私の個人的なお話をしたいと思います。今回のコースには直接関係しないお話もあるので、コースの休憩時間としてリラックスして聴いていただければ幸いです。
Googleには10x(テンエックス)という考え方があります。営業利益を110%増やすことを考えるより、10倍にするためにはどうすればいいかを考えるようにしましょうというものです。そうすれば今のやり方では到底達成できないので、全く違ったアプローチを考えるようになるというものです。
ここではGoogleのテンエックスに関する私のエピソードをお話しします。
ここではなぜSREという考え方が生まれたかに関してご説明したいと思います。
SREを理解するために重要な「可用性」に関してご説明します。
SREを理解するために重要な「信頼性」に関してご説明します。
SREを理解するために重要な「SLI/SLO/SLA」に関してご説明します。
SREを理解するために重要な「Critical User Journey(CUJ)」に関してご説明します。
SREを理解するために重要な「パーセンタイル」に関してご説明します。
SREを理解するために重要な「エラーバジェット(エラー予算)」に関してご説明します。
SREを理解するために重要な「ポストモーテム」に関してご説明します。
SREを理解するために重要な「トイル」に関してご説明します。
ここからは前の章でご説明した「SREを理解するための用語解説」を使って、実際のサービスを例にとってSREを具体的に導入してみます。
YouTubeというサービスのビジネス状況をSRE観点で整理し、SREとして考慮すべき事項は何になるかを考えてみます。
ここでは先に定義したYouTubeのビジネス状況からどのようなSLIが妥当かを考えてみます。
今回のYouTubeをサービスとして捉えた場合、そのサービスの中でもっとも重要なCUJは何になるでしょうか?
CUJに対するSLI項目としては何を選択するのがよいでしょうか?
SLIをどのように評価するかを決めます。
今回は最終的にSLOを設定します。
設定されたSLOを実際に監視するための実装方法を考えます。
SLI、SLOからSLAをどのように設定したらいいかを考えます。
ここで今回の各サービスレベルに関してまとめたいと思います。
ここではSREを理解するために必要となる開発環境がどのようなものなのかを理解するために必要となる用語を解説していきたいと思います。
クラウドネイティブアーキテクチャ
CI/CD(Continuous Integration/Continuous Delivery)
ソースリポジトリ、イメージ、レジストリ
IaC(Infrastructure as Code)
ロールバック、ブルーグリーンデプロイメント、カナリアリリース
イミュータブルインフラストラクチャ
コンテナとkubernetes
今なぜ多くの企業がクラウドネイティブアーキテクチャをDX推進の重要課題と考えているのでしょうか?
CI/CDを導入することによりクラウドネイティブアーキテクチャでも推奨されているような各種オープンソースツールであるGitHubやJenkinsなどを導入し、可能な限り自動化することが必要なのです。
ソースリポジトリは複数の開発者による修正の重複を防いだり、他の人が作成したライブラリやソースコードを再利用する際に導入します。
イメージはアプリケーションを実行するために必要となるすべてのソフトウェアをパッケージしたものです。
レジストリにイメージを登録して必要に応じてそのイメージを利用してアプリケーション実行に必要なすべての情報をコンピュータもしくは仮想環境上にデプロイするために利用されます。
クラウド環境ならではの手法としてこのIaCは重要な項目です。
ロールバック、ブルーグリーンデプロイメント、カナリアリリースに関して分かりやすく説明します。
イミュータブルインフラストラクチャはサーバーを構築したらその後はその環境を変更するのではなく別途用意したバージョンで環境ごと置き換える、といった仮想化やクラウドを基盤としたインフラの考え方です。
コンテナとkubernetesに関して例やスライドを使って分かりやすく説明します。
クラウドネイティブアーキテクチャで推奨されているマイクロサービスアプリケーションとは
どのような根拠によりSLI、SLO、SLAなどを設定すべきかをこれまでご説明してきました。SREとして検討すべき各項目に関して、理解できたでしょうか。
DevOpsは継続的な開発、デプロイ、運用をするためのひとつの組織論つまりコンセプト的な開発運用方法です。
SREやSLOを検討する前提としてクラウド環境によるアジャイル開発が必須なのでしょうか?
SREは、システムの信頼性だけでなく、セキュリティにも重要な役割を担っています。ここではそのうちのいくつかのトピックに関して説明いたします。
DX推進の目的の一つとしてアジャイル開発の導入·推進によるサービス投入サイクルの短縮と安定したリリースサイクルの実現があります。そしてサービス投入サイクル短縮、安定したリリースサイクルの実現を目指し、クラウドネイティブアーキテクチャでも推奨されているコンテナ化、CI/CDなどによる開発環境もクラウドインフラをベースとしたアジャイル開発にシフトしてきています。
IaCはパブリッククラウド利用の大きなアドバンテージと言えます。
SREとしてのセキュリティを自分たちですべて行うのではなく、ソリューションを導入検討することも視野に入れるためには。
Google Cloudの特徴としてグローバルでの負荷分散におけるアドバンテージん関して解説します。
システムでのキーとなるコンピュータの選択肢に関して解説いたします。
PaaS導入のメリット、留意点に関して解説いたします。
インシデント発生時にSREとして重要と思われる項目に関してご説明したいと思います。
対応手順の明示的な提示
一人で責任を背負い込まない
ポストモーテムによる学びを記録し再発を防ぐ
早めの行動を心がける
ツールの話
Googleではどのようにこのような状況に対応するのかを参考にすることにより、SREとしてインシデント対応のベストプラクティスを学びます。
Googleで定義するSREの作業内容は大きく分けて2つあります。1つは比較的想像しやすい、オンコールという作業です。ここではそのオンコールの割合に関してGoogleの事例をお話しします。
多くの企業は自社のエンジニアを再教育してSRE人材を育成するとこも視野に入れないといけない状態です。それではSREngに必要とされるスキルとはどのようなものなのでしょうか。
SREngに必要とされるスキルを考える前に、まず本家のGoogleのSREng採用情報を見てみましょう。
SREは今後特にクラウドでの開発手法のひとつとして注目されてくると考えます。GoogleやAmazonが自社のクラウド環境をGCPやAWSにより一般の人にも開放し、社会全体のITシステムの仕組みをクラウドという集約型のインフラ環境にシフトさせようとしています。
Google Cloudプロフェッショナル認定資格の中からSREに関連する問題をご自身の理解度確認のためにご用意しました。ここで紹介している模擬試験のSRE以外のすべての内容にご興味のある方は是非以下のリンクよりDevOps認定コースを受講していただければ幸いです。
https://www.udemy.com/course/google-certified-professional-devops/?referralCode=59666597E1EFA27B2924
近年、企業でもSRE(サイトリライアビリティエンジニアリング)の導入の検討、もしくは既に導入してそのビジネスに効果を見出すところも出てきています。SREは元々Google社が自分たちのサービス投入サイクルを安全かつ迅速にするために開発された手法のひとつです。SREはクラウドを利用して開発、リリース、保守管理をしている企業やエンジニアにとっても非常に参考になる考え方です。現在DevOpsなどを担当もしくはリードしている方はもちろん、実際にコードを書きアプリケーションを開発しているエンジニアの方、またプログラミングや開発経験のない方にもわかりやすくSREという新しい考え方を理解していただける内容になっています。