株式会社スリーシェイク 手塚 卓也 Sreake流 SREの始め方

Copyrights©3-shake Inc. All Rights Reserved. 2 自己紹介 自治体やデータベースマーケティング会社でのインフラ設計 /構築 /運用を主に経験し、2018 年 10 月に 3-Shake に Join。 3-Shake Join 後は Google Cloud / AWS / kubernetes / ServiceMesh など様々な技術的アプローチを駆使し、 大手からベンチャー等規模を問わず様々な組織に対して SREの コンサルティングや実践を行っている。 趣味はボクシング観戦 ※ 日曜日の昼間は一人で WOWOW 見ながら一人で熱狂してます ... 手塚 卓也

Copyrights©3-shake Inc. All Rights Reserved. 3 1. About 3-shake 2. SRE を開始するための Roadmap 3. SRE 始めるにあたっての3要素 4. SRE 実践例 5. まとめ アジェンダ

1. About 3-Shake

Copyrights©3-shake Inc. All Rights Reserved. 5 About 3-Shake SRE 支援 / 技術支援 サービス Sreake セキュリティ脆弱性診断 サービス Sreake Security クラウド型 ETL / データ パ イプライン サービス Reckoner ハイスキル フリーランス紹 介サービス Relance Reckoner はクラウド型 ETL / データパイプライン サービスで す。 データベース・ストレージ・アプリ ケーションなど、あらゆるデータを 統合・連携することで、データを活 用したビジネス変革に貢献しま す。 Sreake Security は経験豊富な セキュリティ専門家が貴社の課題 に合わせたセキュリティ対策を支 援するサービスです。 Sreake は金融・医療・動画配信 ・AI・ゲームなど技術力が求めら れる領域で豊富な経験を持つ SRE が集まったチームによる 技 術支援サービスです。戦略策定 から設計・構築・運用、 SaaS 提供 まで、幅広い領域をサポートしま す。 Relance は、プロの現役エンジニ ア集団が最適なエンジニアを紹介 するフリーランス エンジニア紹介 サービスです。 技術支援や、 1on1 での定期フォ ローなど、参画後も高いパフォー マンスを維持し続けられる体制 を 提供しています。

Copyrights©3-shake Inc. All Rights Reserved. 6 Sreake のエンジニアによる技術支援 技術戦略から設計、構築、運用までワンストップ支援する 技術支援サービス 技術戦略 コンサルティング システム 設計 構築 / 実装 支援 アセスメント （パフォーマンス / セキュリティ） 運用支援 Multi Cloud や Cloud Native な先進的技術及び大規模なサービス運用に強みを持つエンジニアによる技術 支援 ベンダー的な役割ではなく「お客様の チームメンバー」という立ち位置で最新技術の提案から運用支援までをトータ ルご支援

Copyrights©3-shake Inc. All Rights Reserved. 7 Sreake SRE 導入 / 定着化支援 Enterprise を中心に様々な業種/業界で SRE を実践してきたナレッジを活かした SRE チームの導入及び定着化を行います お客様の組織に適合した SRE の導入を支援 SRE の組成/SRE 文化の定着化の為の支援

Copyrights©3-shake Inc. All Rights Reserved. 8 バグバウンティ の運用代行始めました 世界初！「intigriti」社と提携、バグバウンティ運用代行サービス 「Bugty」をリリース 欧州を代表するバグバウンティプラットフォーム「 intigriti」と世界で初めて提携。 SRE総合支援など高い技術力を持ったスリーシェイクのセキュリティエンジニアが、専門的なトリ アージ・英語でのコミュニケーションなど運用を代行。 セキュリティ領域の専門家がいない、社内のリソースをかけられない企業もバグバウンティプログラ ムを展開できます。

Copyrights©3-shake Inc. All Rights Reserved. 9 本日お話する内容 SRE の概念に関するお話 私達が展開している SRE の始め方について 話すこと 話さないこと 詳細なシステムアーキテクチャ

Copyrights©3-shake Inc. All Rights Reserved. 10 SRE について詳しく知りたい方は以下がおすすめです SRE をわかりやすく理解出来るコンテンツ Google Cloud Days SRE の基本と組織への導入 〜 サービスレベル目標やエラー予算などサー ビスの信頼性に対する考え方〜 https://cloudonair.withgoogle.com/events/google-cloud-day-digital-21?talk=d3-infra-01 3-shake SRE Tech Talk #2 (Google Cloud 篠原様による登壇) https://youtu.be/g-WMeetjoRM?t=218 Google App Modernaization On Air 実践 SRE ~ Google Cloud 活用した SRE の実践 ~ https://cloudonair.withgoogle.com/events/solution-app-modernization?talk=app-session13 sre.google に掲載されている SRE Book https://sre.google/sre-book/table-of-contents/ https://sre.google/workbook/table-of-contents/

2. SRE を開始するため の Roadmap

Copyrights©3-shake Inc. All Rights Reserved. 12 Sreake 流 SRE Roadmap SRE チームの定義 組織にあった SRE を定義しよう SRE の開始 まずは小さく。 効果が最大限に出るところ からコツコツと始めよう SRE実践 Toil 削減 (自動化推進) SLI・SLO の設定 SRE の発展と継続 SREの文化が浸透する Error Budget を元に 業務をコントロールしていく

Copyrights©3-shake Inc. All Rights Reserved. 13 Sreake 流 SRE Roadmap SRE チームの定義 組織にあった SRE を定義しよう SRE の開始 まずは小さく。 効果が最大限に出るところ からコツコツと始めよう SRE実践 Toil 削減 (自動化推進) SLI・SLO の設定 SRE の発展と継続 SREの文化が浸透する Error Budget を元に 業務をコントロールしていく このあたりにフォーカスを置いてお話します

3. SRE 始めるにあたって 大事なこと

Copyrights©3-shake Inc. All Rights Reserved. 15 SRE 関連で見かける言葉たち SRE とは、ソフトウェアエンジニアに運用チームの設計を依頼したときにできあがるものです。 class SRE implements DevOps SLI / SLO の定義 Postmortem の実施 Toil の削減 自動化の促進 エラーバジェット サイト信頼性エンジニアリング インシデント管理 適切なリリースエンジニアリング 適切なオンコール

Copyrights©3-shake Inc. All Rights Reserved. 16 SRE 関連で見かける言葉たち SRE とは、ソフトウェアエンジニアに運用チームの設計を依頼したときにできあがるものです。 class SRE implements DevOps SLI / SLO の定義 Postmortem の実施 Toil の削減 自動化の促進 エラーバジェット サイト信頼性エンジニアリング インシデント管理 適切なリリースエンジニアリング 適切なオンコール で、結局 SRE って何が美味しいの？

Copyrights©3-shake Inc. All Rights Reserved. 17 システム運用において起きている問題 Ops の現場で抱えている問題 煩雑で繰り返しの多い 愛のこもった手動の運用 作業 日々追われる障害対応 とメンバーへの過負荷 守りを重視するが故に リリーススピードが遅い

Copyrights©3-shake Inc. All Rights Reserved. 18 システム運用において起きている問題 SRE を実践すると解決！！ 煩雑で繰り返しの多い作 業を自動化の推進によっ て削減する 適切なオンコールや Error Budget による業務ハンドリングを通じてメン バーの過負荷を削減する 信頼性を担保しつつ、 素早いリリースサイクルを 実現する

Copyrights©3-shake Inc. All Rights Reserved. 19 システム運用において起きている問題 煩雑で繰り返しの多い作 業を自動化の推進によっ て削減する 適切なオンコールや Error Budget による業務ハンドリングを通じてメン バーの過負荷を削減する 信頼性を担保しつつ、 素早いリリースサイクルを 実現する 運用にまつわるこれらの問題を「ソフトウェアエンジニアリング」という手法を使って解決出来ることに美味しさ がある。逆にここに美味しさを感じないのであれば、 SRE なんて意味がない。 SRE を実践すると解決！！

Copyrights©3-shake Inc. All Rights Reserved. 20 SRE が美味しくなるか否かが決まる重要な3要素のバランス SRE 始めるにあたってはこの3要素について考えよう システムの性質 組織文化 どの程度ミッションクリティカ ルな性質を持つのか？ システムの規模はどの程度 なのか？ SRE に必要な文化は受け入れ られるか？ Biz / Dev / Ops それぞれのパ ワーバランスはいかほどか？ チームのスキル SRE を実現するためのチームのス キルは十分か？

Copyrights©3-shake Inc. All Rights Reserved. 21 システムの性質と SRE の相性 ❖ システムの性質として、「信頼性」をどこまで担保する必要があるのか は非常に大事なポイント。 ❖ これは Biz 的な観点もあるし、サービスの規模や成長具合にも応じる かと思われる。 ❖ なお SRE としては SLO 100% を目指すのはアンチパターン。また必要 以上に可用性を求めてそこに労力を割きすぎるのも良くないとされて いる。 ❖ 大胆に言い換えると、SRE では顧客が満足するだけの「ある程度の信 頼性」と「効率」のバランスを求めている システムの性質 によって大きく変わる「信頼性」 ユーザー数 / トラフィック量 ビジネスインパクト

Copyrights©3-shake Inc. All Rights Reserved. 22 組織文化的な側面について DevOps SRE Reduce organization silos 組織のサイロ化を無くす Share ownership with developers by using the same tools and techniques across the stack 同じツールやテクニックを使用して、開発者とオーナーシップを共有する Accept failure as normal 失敗を当たり前のように受け入れる Have a formula for balancing accidents and failures against new releases 事故や失敗と新製品とのバランスをとるための公式を持つ Implement gradual change 徐々に変化させる Encourage moving quickly by reducing costs of failure 失敗したときのコストを減らすことで、迅速な行動を促します。 Leverage tooling & automation ツールと自動化の活用 Encourages "automating this year's job away" and minimizing manual systems work to focus on efforts that bring long-term value to the system システムに長期的な価値をもたらす取り組みに集中するために、「今年の仕事を自動化する」ことを奨励 し、手作業によるシステム作業を最小限に抑える Measure everything すべてを測定する Believes that operations is a software problem, and defines prescriptive ways for measuring availability, uptime, outages, toil, etc. オペレーションはソフトウェアの問題であると考え、アベイラビリティー、アップタイム、アウテージ、トイルな どの測定方法を規定しています。 参照: https://cloud.google.com/blog/products/gcp/sre-vs-devops-competing-standards-or-close-friends class SRE は DevOps を実装するとありますが ... ※ SRE には、必ずしも DevOps インターフェースの一部ではない、追加のプラクティスや推奨事項が含まれている場合があります。

Copyrights©3-shake Inc. All Rights Reserved. 23 組織文化的な側面について DevOps SRE Reduce organization silos 組織のサイロ化を無くす Share ownership with developers by using the same tools and techniques across the stack 同じツールやテクニックを使用して、開発者とオーナーシップを共有する Accept failure as normal 失敗を当たり前のように受け入れる Have a formula for balancing accidents and failures against new releases 事故や失敗と新製品とのバランスをとるための公式を持つ Implement gradual change 徐々に変化させる Encourage moving quickly by reducing costs of failure 失敗したときのコストを減らすことで、迅速な行動を促します。 Leverage tooling & automation ツールと自動化の活用 Encourages "automating this year's job away" and minimizing manual systems work to focus on efforts that bring long-term value to the system システムに長期的な価値をもたらす取り組みに集中するために、「今年の仕事を自動化する」ことを奨励 し、手作業によるシステム作業を最小限に抑える Measure everything すべてを測定する Believes that operations is a software problem, and defines prescriptive ways for measuring availability, uptime, outages, toil, etc. オペレーションはソフトウェアの問題であると考え、アベイラビリティー、アップタイム、アウテージ、トイルな どの測定方法を規定しています。 参照: https://cloud.google.com/blog/products/gcp/sre-vs-devops-competing-standards-or-close-friends class SRE は DevOps を実装するとありますが ... ※ SRE には、必ずしも DevOps インターフェースの一部ではない、追加のプラクティスや推奨事項が含まれている場合があります。 こういった手法を受け入れるだけの組織的土壌がありますか？ なければ作れますか？ 他チームから理解を得て協働が可能ですか？

Copyrights©3-shake Inc. All Rights Reserved. 24 組織文化とチーム間のパワーバランス Biz Dev SRE DevOps の 「実装者」 としての役割をもつ SRE は当然 開発 や これまでの運用といったものと密接に関わります。 また、SLO の定義や SLA の定義を行うためには当然 SRE のみで終 止するものでは無いため、ビジネスサイドとも密接に関わります。 SRE は単一組織として自分たちのタスクに終始すれば良いものでは なく、様々な組織や役割と密接に連携し合いながら実践していく必要 があると考えています。

Copyrights©3-shake Inc. All Rights Reserved. 25 SRE はインフラエンジニアの進化系!???? インフラエンジニア サイト・リライアビリティ・エンジニアリング・ エンジニア しんか? SRE の実体あるある

Copyrights©3-shake Inc. All Rights Reserved. 26 SRE はインフラエンジニアの進化系!???? インフラエンジニア サイト・リライアビリティ・エンジニアリング・ エンジニア しんか? SRE の実体あるある 本来はこうではない

Copyrights©3-shake Inc. All Rights Reserved. 27 サイト・リライアビリティ・エンジニアリング・エンジニアに求められること ? 参考: https://roadmap.sh/devops 1. プログラミング言語の習得 2. 異なるOSのコンセプトを理解する 3. ターミナルを使いこなす 4. ネットワーク、セキュリティ、プロトコルへの理解 5. ミドルウェアのセットアップとは何か、どのように行うか 6. IaC のスキル 7. CI/CD ツールの習得 8. ソフトウェアとインフラの監視を学ぶ 9. クラウド・プロバイダーの知識 DevOps Roadmapを見てみると... 凄い「勇者」を求められている感

Copyrights©3-shake Inc. All Rights Reserved. 28 SREは 勇者のパーティみたいなイメージ ちなみに、例えるとこんな感じ ....? ➢ 魔法使い = ソフトウェアエンジニア ➢ 戦士 = インフラエンジニア ➢ 僧侶 = ネットワークエンジニア ➢ 勇者 = 全部デキる人 Team SRE SRE に求められることは非常に多い。 その為、自分たちのシステムの規模、やりたい事に応じ て、メンバーを構成したり、チーム全体で成長していく必 要がある。 ※ Google の場合は ソフトウェアエンジニアが 40% ~ 50% で構成され、残りはそれ以外に必要なメンバーとし ている。

Copyrights©3-shake Inc. All Rights Reserved. 29 SRE 始めるにあたってはこの3要素について考えよう システムの性質 組織文化 どの程度ミッションクリティカ ルな性質を持つのか？ システムの規模はどの程度 なのか？ SRE に必要な文化は受け入れ られるか？ Biz / Dev / Ops それぞれのパ ワーバランスはいかほどか？ チームのスキル SRE を実現するためのチームのス キルは十分か？ SRE が美味しくなるか否かが決まる重要な3要素のバランス

Copyrights©3-shake Inc. All Rights Reserved. 30 ひとつのサービスから小さく始める そのためには、多数のシステムを一気に対象としないこと。 まずはひとつのサービスを対象に SRE を始めて徐々に広げていきま しょう。 なお且つ、出来れば新規サービスや手がつけやすいサービスを対象 に取り組みを始めるのが望ましい。 理由 ➢ 新しく SLI / SLO 設定する元となる情報を取得する為の基盤導入が難し い。 ➢ 既存の運用がある為、新しい活動への導入が難しいケースがある ➢ そもそも手を加える前提で作られていない ... 小さく始めて SRE チームとして成功体験を得よう System A ひとつのサービスと それに関わるチームから SRE の活動を始める

3. SRE 実践例 (さらっと)

Copyrights©3-shake Inc. All Rights Reserved. 32 SRE の実践内容 (例) ● 監視基盤導入 ○ Logging ○ Monitoring ○ APM ● SLI / SLO の定義 ● 運用体制整備 ○ インシデント対応・管理 ○ 効果的なアラート ● IaC (Infrastructure as Code) ○ 構成管理の品質チェック ○ GitOps ● CI/CD 導入 ○ デプロイの自動化 ○ コード品質・脆弱性の検査 ○ DevSecOps ● アプリケーションのパッケージ化 ○ コンテナ ● パフォーマンス分析 ○ 分散トレーシング ○ 負荷試験 ○ カオスシナリオ試験

Copyrights©3-shake Inc. All Rights Reserved. 33 SRE の実践内容 (例) ● 監視基盤導入 ○ Logging ○ Monitoring ○ APM ● SLI / SLO の定義 ● 運用体制整備 ○ インシデント対応・管理 ○ 効果的なアラート ● IaC (Infrastructure as Code) ○ 構成管理の品質チェック ○ GitOps Cloud Operations Cloudwatch

Copyrights©3-shake Inc. All Rights Reserved. 34 SLI・SLO・SLA について ❖ SLI (Service Level Indicator) サービスレベル指標 ➢ 何をもとにシステムの良し悪しを判断するかの指標となるもの ➢ SLO を定義する時に利用する ❖ SLO (Service Level Objective) サービスレベル目標 ➢ サービスレベルに対する内的な目標値 ❖ SLA (Service Level Agreement) サービスレベル保証 ➢ サービスレベルに対する対外的な保証値

Copyrights©3-shake Inc. All Rights Reserved. 35 SLI・SLO・SLA について ❖ SLI (Service Level Indicator) サービスレベル指標 ➢ 何をもとにシステムの良し悪しを判断するかの指標となるもの ➢ SLO を定義する時に利用する ❖ SLO (Service Level Objective) サービスレベル目標 ➢ サービスレベルに対する内的な目標値 ❖ SLA (Service Level Agreement) サービスレベル保証 ➢ サービスレベルに対する対外的な保証値 上質な SLO を設定するためにもまずは あらゆる指標となりうるあらゆるメトリクスを収集 し、可視化ができるようにしよう

Copyrights©3-shake Inc. All Rights Reserved. 36 SRE の実践内容 (例) ● 監視基盤導入 ○ Logging ○ Monitoring ○ APM ● SLI / SLO の定義 ● 運用体制整備 ○ インシデント対応・管理 ○ 効果的なアラート ● IaC (Infrastructure as Code) ○ 構成管理の品質チェック ○ GitOps Slack 等の Chat 運用体制構築

Copyrights©3-shake Inc. All Rights Reserved. 37 ポストモーテムの実施 ポストモーテムとは、インシデント、その影響、インシデントを軽減または解決するために取られたアクショ ン、根本原因、およびインシデントの再発を防止するためのフォローアップアクションを書面で記録すること です。 参考: https://sre.google/sre-book/postmortem-culture/ https://sre.google/sre-book/example-postmortem/ ❖ 振り返りから学ぶ文化を作る為にポストモーテムを行います。 ❖ その為には障害解析に対して追跡 が出来るようにしておかな ければなりません。 ❖ フォーマットについてはまずは SRE 本にて提示されている Example を流用するのがおすすめ。 ❖ それと何よりも大切なのが 特定個人を非難しない文化 であるこ とです。 ※ あくまで、システムや仕組みの問題であると考えます。

Copyrights©3-shake Inc. All Rights Reserved. 38 SRE の実践内容 (例) ● 監視基盤導入 ○ Logging ○ Monitoring ○ APM ● SLI / SLO の定義 ● 運用体制整備 ○ インシデント対応・管理 ○ 効果的なアラート ● IaC (Infrastructure as Code) ○ 構成管理の品質チェック ○ GitOps

Copyrights©3-shake Inc. All Rights Reserved. 39 SRE の実践内容 (例) ● CI/CD 導入 ○ デプロイの自動化 ○ コード品質・脆弱性の検査 ○ DevSecOps ● アプリケーションのパッケージ化 ○ コンテナ ● パフォーマンス分析 ○ 分散トレーシング ○ 負荷試験 ○ カオスシナリオ試験

Copyrights©3-shake Inc. All Rights Reserved. 40 適切な リリースエンジニアリングのための CI/CD CI/CD を行う目的とは? 障害発生の多くは人間が手を加えたとき （新しいバージョンのリリース時 ）に起きると言われています。 CI/CD は リリースサイクルの向上と信頼性の両方を担保する為のアプローチであるべきだと考えています。 ❖ CI ➢ テストを自動化したい ➢ コードの品質を高めたい ➢ Release Ready な状態にしたい ❖ CD ➢ 簡単にデプロイ出来るようにしたい ➢ 何かあればすぐ切り戻したい ➢ 承認など段階を踏んだデプロイをしたい

Copyrights©3-shake Inc. All Rights Reserved. 41 CI/CD (Release Engineering) Git Delivery Metrics Prometheus Artifact Registry Kubernetes Engine ArgoCD Argo Rollouts CD CI Security Scan Progressive Delivery GitOps Push Image Gatekeeper Run Pipeline Lint Source & Scan Vulnerability Build Image Gitlab Kubernetes での CI/CD の実践

Copyrights©3-shake Inc. All Rights Reserved. 42 SRE の実践内容 (例) ● CI/CD 導入 ○ デプロイの自動化 ○ コード品質・脆弱性の検査 ○ DevSecOps ● パフォーマンス分析 ○ 分散トレーシング ○ 負荷試験 ○ カオスシナリオ試験

Copyrights©3-shake Inc. All Rights Reserved. 43 とにかく情報を収集し、分析できるようにする事が大切 SRE を始めるにあたっては、元となるあらゆるデータが揃ってい ることが前提です。 結局はデータドリブンな世界にする必要があり、データがない状 態では SLI / SLO の設定やそもそもどういった作業が Toil なのか であったりを特定するのは不可能です。 とにかくまずはデータを収集し、可視化出来るところまで持ってい きましょう。 データを元に意思決定が出来る世界へ 闇雲に戦う世界から

まとめ

Copyrights©3-shake Inc. All Rights Reserved. 45 SRE 始めるにあたってはこの3要素について考えよう システムの性質 組織文化 どの程度ミッションクリティカ ルな性質を持つのか？ システムの規模はどの程度 なのか？ SRE に必要な文化は受け入れ られるか？ Biz / Dev / Ops それぞれのパ ワーバランスはいかほどか？ チームのスキル SRE を実現するためのチームのス キルは十分か？ SRE が美味しくなるか否かが決まる重要な3要素のバランス

Copyrights©3-shake Inc. All Rights Reserved. 46 ひとつのサービスから小さく始める そのためには、多数のシステムを一気に対象としないこと。 まずはひとつのサービスを対象に SRE を始めて徐々に広げていきま しょう。 なお且つ、出来れば新規サービスが望ましい。 理由 ➢ 新しく SLI / SLO 設定する元となる情報を取得する為の基盤導入が難 しい。 ➢ 既存の運用がある為、新しい活動への導入が難しいケースがある ➢ そもそも手を加える前提で作られていない ... 小さく始めて SRE チームとして成功体験を得よう System A ひとつのサービスと それに関わるチームから SRE の活動を始める

Copyrights©3-shake Inc. All Rights Reserved. 47 まとめ ❖ そもそも SRE じゃないと駄目なことは何なのか。何を目的とするのかは理解して始めよう ❖ 敵を知り己を知れば百戦殆うからず。 「組織文化」、「システムの性質」、「チームのスキル」それぞれ を理解した上で SRE を始めていこう ❖ SRE を始める時はなるべく小さく、手を付けやすいところから

Thank you