Slide 1

Slide 1 text

クラウドネイティブの 本質から考える 生産性と信頼性の両立 PagerDuty - Product Evangelist Kazuto Kusama @jacopen

Slide 2

Slide 2 text

Kazuto Kusama @jacopen Product Evangelist @PagerDuty Japan Organizer @Platform Engineering Meetup Founder @Cloud Native Innovators Association Organizer @CloudNative Days

Slide 3

Slide 3 text

PagerDutyってご存じですか?

Slide 4

Slide 4 text

1. 検知 2. トリアージ 3. 動員 4. 協⼒/解決 5. 学習/予防 ライフサイクル全体を通して、インシデントの状況をリアルタイムで可視化 インシデントを特定 ⾃動処理 運⽤改善のための 知⾒を提供 最適な担当者に通知 迅速な解決を⽀援 あらゆるツールから イベントを受信 架電、 SMS、メール Appプッシュ通知、チャット ⾃動エスカレーション スケジュール管理 診断‧修復作業の⾃動化 チーム内外と円滑に連携 クラウド コンテナ マイクロサービス ネットワーク アプリ‧サービス セキュリティ データベース サーバー ソーシャル PagerDuty Operations Cloud インシデントをより早く‧少ないリソースで解決 / 将来のインシデントを未然に防ぐ 担当者が最適な 通知⽅法を選択 対応履歴 MTTA/MTTR 分析 担当者の負荷状況 ポストモーテム 解決のヒントを提⽰ ● 過去の類似インシデント ● 直近の構成/コード変更 ...etc. 80%-99% ノイズ削減 700+ Integrations

Slide 5

Slide 5 text

インシデント対応 必要なアラートだけに絞り込み 電話やSMS、プッシュ通知、Slack など、人それぞれ適した通知 一次対応者 (応答がなければ) 二次対応者 オンコールの ローテーション

Slide 6

Slide 6 text

開発生産性?

Slide 7

Slide 7 text

クラウドとか、プラットフォームの切り口で話します

Slide 8

Slide 8 text

クラウドネイティブ技術ってありますよね • CI/CDとか • コンテナとか • Kubernetesとか • サービスメッシュとか

Slide 9

Slide 9 text

こういう質問をよく受けます うちはAWSオンリー なんだけど、 Kubernetes使った方が 良いの? コンテナのほうが 良いのかな・・・ VMじゃダメ? オンプレやめて全部 クラウドにしました。 これでクラウドネイティ ブだよね? ベンダーがクラウド ネイティブ製品売り込んで きてるんだけど、やっぱりそう いうの買った方がいい?

Slide 10

Slide 10 text

CNCFによるクラウドネイティブの定義 クラウドネイティブ技術は、パブリッククラウド、プライベートクラウド、ハイブリッドクラウドなど の近代的でダイナミックな環境において、スケーラブルなアプリケーションを構築および実行す るための能力を組織にもたらします。 このアプローチの代表例に、コンテナ、サービスメッ シュ、マイクロサービス、イミュータブルインフラストラクチャ、および宣言型 APIがあります。 これらの手法により、回復性、管理力、および可観測性のある疎結合システムが実現します。 これらを堅牢な自動化と組み合わせることで、エンジニアはインパクトのある変更を最小限の 労力で頻繁かつ予測どおりに行うことができます。 https://github.com/cncf/toc/blob/main/DEFINITION.md

Slide 11

Slide 11 text

CNCFによるクラウドネイティブの定義 クラウドネイティブ技術は、パブリッククラウド、プライベートクラウド、ハイブリッドクラウドなど の近代的でダイナミックな環境において、スケーラブルなアプリケーションを構築および実行す るための能力を組織にもたらします。 このアプローチの代表例に、コンテナ、サービスメッ シュ、マイクロサービス、イミュータブルインフラストラクチャ、および宣言型 APIがあります。 これらの手法により、回復性、管理力、および可観測性のある疎結合システムが実現します。 これらを堅牢な自動化と組み合わせることで、エンジニアはインパクトのある変更を最小限の 労力で頻繁かつ予測どおりに行うことができます。 https://github.com/cncf/toc/blob/main/DEFINITION.md ?

Slide 12

Slide 12 text

みなさん、クラウドは使ってますよね?

Slide 13

Slide 13 text

そもそもクラウドって何?

Slide 14

Slide 14 text

NISTによるクラウドコンピューティングの定義 クラウドの基本的な特徴 • オンデマンド・セルフサービス • 幅広いネットワークアクセス • リソースの共用 • スピーディな拡張性 • サービスが計測可能であること https://www.ipa.go.jp/files/000025366.pdf

Slide 15

Slide 15 text

NISTによるクラウドコンピューティングの定義 クラウドの基本的な特徴 • オンデマンド・セルフサービス • 幅広いネットワークアクセス • リソースの共用 • スピーディな拡張性 • サービスが計測可能であること https://www.ipa.go.jp/files/000025366.pdf 使った分だけ課金 低い初期費用 スケールしやすい 運用を肩代わり リソースの 調達が早い

Slide 16

Slide 16 text

NISTによるクラウドコンピューティングの定義 クラウドの基本的な特徴 • オンデマンド・セルフサービス • 幅広いネットワークアクセス • リソースの共用 • スピーディな拡張性 • サービスが計測可能であること https://www.ipa.go.jp/files/000025366.pdf 使った分だけ課金 低い初期費用 スケールしやすい 運用を肩代わり リソースの 調達が早い APIでコントロール出 来る

Slide 17

Slide 17 text

APIがあると何が出来る? • プログラムから叩ける • 自動化出来る • サービス間連携がしやすい ⇨ IaCツールで構築、CI/CDツールからのデプロイ、オートス ケール、etc..

Slide 18

Slide 18 text

クラウドで 高速化したよ 数分で 環境作れるよ 数msで 処理終わるよ 前の処理が 終わったら 自動で動くよ

Slide 19

Slide 19 text

クラウドで 高速化したよ 数分で 環境作れるよ 数msで 処理終わるよ 前の処理が 終わったら 自動で動くよ

Slide 20

Slide 20 text

Latency Numbers Every Programmer Should Know https://gist.github.com/jboner/2841832 https://colin-scott.github.io/personal_website/research/interactive_latency.html

Slide 21

Slide 21 text

Latency Numbers Every Programmer Should Know https://gist.github.com/jboner/2841832 上司の許可取ってサーバー 1台構築  259,200,000,000,000 ns

Slide 22

Slide 22 text

クラウドで 高速化したよ 数分で 環境作れるよ 数msで 処理終わるよ 前の処理が 終わったら 自動で動くよ

Slide 23

Slide 23 text

承認待ち 3日 他チームの 返事待ち6時間 稟議○週間 意思決定 3時間

Slide 24

Slide 24 text

承認待ち 3日 他チームの 返事待ち6時間 稟議○週間 意思決定 3時間 クラウドネイティブの時代では 人間の存在自体がボトルネック

Slide 25

Slide 25 text

設定ミス 伝達漏れ 見落とし 機密情報を 間違って コミットする

Slide 26

Slide 26 text

設定ミス 伝達漏れ 見落とし 機密情報を 間違って コミットする あなたが居ない方が、仕事は早く回る

Slide 27

Slide 27 text

人間を挟まない 仕組み作り API API API API API API API API API API

Slide 28

Slide 28 text

CNCFによるクラウドネイティブの定義 クラウドネイティブ技術は、パブリッククラウド、プライベートクラウド、ハイブリッドクラウドなど の近代的でダイナミックな環境において、スケーラブルなアプリケーションを構築および実行す るための能力を組織にもたらします。 このアプローチの代表例に、コンテナ、サービスメッ シュ、マイクロサービス、イミュータブルインフラストラクチャ、および宣言型 APIがあります。 これらの手法により、回復性、管理力、および可観測性のある疎結合システムが実現します。 これらを堅牢な自動化と組み合わせることで、エンジニアはインパクトのある変更を最小限の 労力で頻繁かつ予測どおりに行うことができます。 https://github.com/cncf/toc/blob/main/DEFINITION.md

Slide 29

Slide 29 text

CNCFによるクラウドネイティブの定義 クラウドネイティブ技術は、パブリッククラウド、プライベートクラウド、ハイブリッドクラウドなど の近代的でダイナミックな環境において、スケーラブルなアプリケーションを構築および実行す るための能力を組織にもたらします。 このアプローチの代表例に、コンテナ、サービスメッ シュ、マイクロサービス、イミュータブルインフラストラクチャ、および宣言型 APIがあります。 これらの手法により、回復性、管理力、および可観測性のある疎結合システムが実現します。 これらを堅牢な自動化と組み合わせることで、エンジニアはインパクトのある変更を最小限の 労力で頻繁かつ予測どおりに行うことができます。 https://github.com/cncf/toc/blob/main/DEFINITION.md APIで叩けるインフラ

Slide 30

Slide 30 text

CNCFによるクラウドネイティブの定義 クラウドネイティブ技術は、パブリッククラウド、プライベートクラウド、ハイブリッドクラウドなど の近代的でダイナミックな環境において、 スケーラブルなアプリケーションを構築および実行す るための能力を組織にもたらします。 このアプローチの代表例に、コンテナ、サービスメッ シュ、マイクロサービス、イミュータブルインフラストラクチャ、および宣言型 APIがあります。 これらの手法により、回復性、管理力、および可観測性のある疎結合システムが実現します。 これらを堅牢な自動化と組み合わせることで、エンジニアはインパクトのある変更を最小限の 労力で頻繁かつ予測どおりに行うことができます。 https://github.com/cncf/toc/blob/main/DEFINITION.md

Slide 31

Slide 31 text

CNCFによるクラウドネイティブの定義 クラウドネイティブ技術は、パブリッククラウド、プライベートクラウド、ハイブリッドクラウドなど の近代的でダイナミックな環境において、 スケーラブルなアプリケーションを構築および実行す るための能力を組織にもたらします。 このアプローチの代表例に、コンテナ、サービスメッ シュ、マイクロサービス、イミュータブルインフラストラクチャ、および宣言型 APIがあります。 これらの手法により、回復性、管理力、および可観測性のある疎結合システムが実現します。 これらを堅牢な自動化と組み合わせることで、エンジニアはインパクトのある変更を最小限の 労力で頻繁かつ予測どおりに行うことができます。 https://github.com/cncf/toc/blob/main/DFINITION.md APIを活用して、人間の関与を減らしつつ、大 量のリソースを自動化できる仕組み作り

Slide 32

Slide 32 text

つまり、クラウドネイティブの本質とは 全ての活動において 『コンピュータの力でコンピュータを動かす』 『人間の関与を無くす』 を実践していくこと。 クラウドネイティブ技術はこれが出来るポテンシャルを持ってい る https://github.com/cncf/toc/blob/main/DEFINITION.md

Slide 33

Slide 33 text

こういう質問をよく受けます うちはAWSオンリー なんだけど、 Kubernetes使った方が 良いの? コンテナのほうが 良いのかな・・・ VMじゃダメ? オンプレやめて全部 クラウドにしました。 これでクラウドネイティ ブだよね? ベンダーがクラウド ネイティブ製品売り込んで きてるんだけど、やっぱりそう いうの買った方がいい?

Slide 34

Slide 34 text

人を挟まない仕組みを作れるかどうかが全て コンテナを使っても、人が挟まったらメリットは消え去る docker build docker push mvn package kubectl apply VMを使っても、クラウドネイティブは実現出来る git push

Slide 35

Slide 35 text

留意すべき点

Slide 36

Slide 36 text

真のDevOps 開発者が、アプリをエンドツーエンドでデプロイし、実行する ただし、多くの組織にとって現実的ではない Kubernetes Buildkit Helm Dockerfile Grafana Prometheus GitHub Actions React Next.js Security Node.js Terraform ArgoCD APM Compliance 認知負荷が 高すぎる これをやり切れ る人材は少ない

Slide 37

Slide 37 text

認知負荷の増大 https://www.infoq.com/articles/platform-engineering-primer/ より引用

Slide 38

Slide 38 text

認知負荷を低く、生産性を高めるプラットフォーム • クラウドネイティブな自動化基盤作りを、開発者自身が担うこ とによる認知負荷の高まりが問題になりつつある • 仕組み作りを担うPlatform Teamと協力し、認知負荷を高め ずにクラウドネイティブ技術を取り込んでいく • Platform Engineeringという分野が発展中

Slide 39

Slide 39 text

抽象化した機能の提供 Platform Engineering https://tag-app-delivery.cncf.io/whitepapers/platforms/ より和訳 プロダクトチーム プラットフォームチーム インター フェース 提供 機能 ドキュメント GUI (ポータル) プロジェクトテンプレート APIとCLI 環境とリソースの提供 インフラリソース データ保管 メッセージング ID管理と認証 CI/CD サービス連携 成果物管理 セキュリティ 可観測性

Slide 40

Slide 40 text

こんな話も

Slide 41

Slide 41 text

一方でこんな話もあります “障害のほとんどはデプロイによって引き起こされる。した がって、デプロイが増えると障害も増え、結果としてインシ デント管理、軽減策、ポストモーテムが必要となる ” エレガントパズル エンジニアのマネジメントという難問にあなたはどう立ち向かう のか より引用

Slide 42

Slide 42 text

生産性と信頼性をどう両立していくか • 生産性を高めていくことはとても重要 • 一方で、高速に回せるようになるとその分障害の可能性が高くなる

Slide 43

Slide 43 text

信頼性を高めるための大方針 基本的にはクラウドネイティブ思考を尊重 • 『コンピュータの力でコンピュータを動かす』 • 『人間の関与を無くす』

Slide 44

Slide 44 text

顧客影響 予測可能 予測不可能 なし あり 計画メンテナンス インシデント 通常運用 優先度低 システム障害

Slide 45

Slide 45 text

顧客影響 予測可能 予測不可能 なし あり 計画メンテナンス インシデント 通常運用 優先度低 システム障害

Slide 46

Slide 46 text

顧客影響 予測可能 予測不可能 なし あり 計画メンテナンス インシデント 通常運用 優先度低 システム障害 ✅ 素早く気づく ✅ 素早く直す ⇨インシデント対応

Slide 47

Slide 47 text

オンコール 必要なアラートだけに絞り込み 電話やSMS、プッシュ通知、Slack など、人それぞれ適した通知 一次対応者 オンコールの ローテーション

Slide 48

Slide 48 text

+ だと Past Incidents 過去の類似インシデント一覧と、 発生時期・回数のヒートマップを表示。 Related Incidents 他サービスで現在発生している、 関連性の高いインシデントを表示。

Slide 49

Slide 49 text

顧客影響 予測可能 予測不可能 なし あり 計画メンテナンス インシデント 通常運用 優先度低 システム障害 軽減策 アーキテクチャの 改善 自動化

Slide 50

Slide 50 text

GUI/CodeによるJob定義と管理 50 50 柔軟なJob起動⼿段 認証 120を超える インテグレーション PagerDuty GenAI によるJob作成⽀援 オンプレ環境にも セキュアにアクセス Enterprise Runner - Event-Driven - Human-in-the-Loop - スケジューリング Web GUI API CLI Webhook PagerDuty Runbook Automation

Slide 51

Slide 51 text

アラートに応じた自動化 アラートを受信 インシデントを起票 切り分けのための タスクを実行 自動修復 軽減策のタスクを 実行

Slide 52

Slide 52 text

顧客影響 予測可能 予測不可能 なし あり 計画メンテナンス インシデント 通常運用 優先度低 システム障害

Slide 53

Slide 53 text

顧客影響 予測可能 予測不可能 なし あり 計画メンテナンス インシデント 通常運用 優先度低 システム障害 予測できないものを自 動化するのは困難

Slide 54

Slide 54 text

顧客影響 予測可能 予測不可能 なし あり 計画メンテナンス インシデント 通常運用 優先度低 システム障害 ポストモーテム 継続的な学び

Slide 55

Slide 55 text

ポストモーテム SREのプラクティスでおなじみ • インシデントのインパクト • 緩和や解消のために行われたアクション • 根本原因 • インシデントの再発を避けるためのフォローアップ きちんと纏めておくことで、組織としての成長に繋がる。

Slide 56

Slide 56 text

+ だと Postmotems ポストモーテムの作成を支援。受信したイベント、ステータスアップデート、インシデント ノート、Slackの会話などからタイムラインを作成

Slide 57

Slide 57 text

マニュアル リアクティブ レスポンシブ 積極的 予防的 問題は社内チームではなく 顧客によって特定される。 オペレーションプロセスはレガ シーシステムに依存しており、イ ンシデントは手動で発生し、チ ケットシステムなどのキューイン グワークフローを使用して処理 される。 緊急時に専門家に迅速にアク セスするための仕組みがほとん どない。 常に消火モード 初期の技術投資により、クラウ ドホスティングやアプリケーショ ンの成熟度に応じてリアルタイ ムでの可視化と動員が可能に なる。 分散型チームのアプローチが 見られるが、スキルはサイロ 化されている。 インシデントを管理するための 明確なプロセスがない。 問題が発生する前に先回り 優れた顧客体験が常に維持さ れる。 機械学習に基づく予測的な修 正が行われる。 組織全体で一貫したベストプラ クティスが実施される。 高度に自動化されたプロセスに より、雑務やエスカレーションが 排除される。 継続的な学習、改善、予防が技 術的でない関係者を含む組織 全体で行われる。 チームは変更の将来的な影響 を予測できる。 問題が発生するたびに解決 チームは顧客に影響を与える 問題をより迅速に把握できる。 機械学習を使用して潜在的な 問題を特定し、誤検知を減ら し、ノイズを低減する。 問題は自動的に特定され、専 門家によって対応されるが、適 切なチームを編成することは 依然として課題である。 分散型チームがマイクロサー ビスの完全な責任を持つよう になる。 シームレスで協調的な 問題管理 問題は顧客が気付く前に技術 チームによって検出・修正され る。 問題に関する情報は、ビジネス のステークホルダーを含む適切 な人物に提供される。 プログラム学習と最適化の機会 の特定が一般化している。 分散型チームは、サービス変更 の影響を理解し、運用の責任を 完全に負う。 チームとして対応し、運用の成熟度を上げていく

Slide 58

Slide 58 text

まとめ • クラウドネイティブの時代においては、『コンピュータの力でコンピュータを動 かす』『人間の関与を無くす』の意識が大事 • そうすることで、コンピュータの速度で物事を動かし、生産性を高める • その分インシデントが起きる確率も高くなるので、信頼性を高める取り組みも 大事 • PagerDutyを活用して、継続的な学びを行うことで生産性と信頼性を両立させ る

Slide 59

Slide 59 text

No content