クラウドネイティブの本質から考える、生産性と信頼性の両立

開発生産性カンファレンス2024でお話しした資料です

Transcript

1. クラウドネイティブの 本質から考える 生産性と信頼性の両立 PagerDuty - Product Evangelist Kazuto Kusama @jacopen
2. Kazuto Kusama @jacopen Product Evangelist @PagerDuty Japan Organizer @Platform Engineering Meetup Founder @Cloud Native Innovators Association Organizer @CloudNative Days
3. PagerDutyってご存じですか？
4. 1. 検知 2. トリアージ 3. 動員 4. 協⼒/解決 5. 学習/予防 ライフサイクル全体を通して、インシデントの状況をリアルタイムで可視化 インシデントを特定 ⾃動処理 運⽤改善のための 知⾒を提供 最適な担当者に通知 迅速な解決を⽀援 あらゆるツールから イベントを受信 架電、 SMS、メール Appプッシュ通知、チャット ⾃動エスカレーション スケジュール管理 診断‧修復作業の⾃動化 チーム内外と円滑に連携 クラウド コンテナ マイクロサービス ネットワーク アプリ‧サービス セキュリティ データベース サーバー ソーシャル PagerDuty Operations Cloud インシデントをより早く‧少ないリソースで解決 / 将来のインシデントを未然に防ぐ 担当者が最適な 通知⽅法を選択 対応履歴 MTTA/MTTR 分析 担当者の負荷状況 ポストモーテム 解決のヒントを提⽰ • 過去の類似インシデント • 直近の構成/コード変更 ...etc. 80%-99% ノイズ削減 700+ Integrations
5. インシデント対応 必要なアラートだけに絞り込み 電話やSMS、プッシュ通知、Slack など、人それぞれ適した通知 一次対応者 (応答がなければ) 二次対応者 オンコールの ローテーション
6. 開発生産性？
7. クラウドとか、プラットフォームの切り口で話します
8. クラウドネイティブ技術ってありますよね • CI/CDとか • コンテナとか • Kubernetesとか • サービスメッシュとか
9. こういう質問をよく受けます うちはAWSオンリー なんだけど、 Kubernetes使った方が 良いの？ コンテナのほうが 良いのかな･･･ VMじゃダメ？ オンプレやめて全部 クラウドにしました。 これでクラウドネイティ ブだよね？ ベンダーがクラウド ネイティブ製品売り込んで きてるんだけど、やっぱりそう いうの買った方がいい？
10. CNCFによるクラウドネイティブの定義 クラウドネイティブ技術は、パブリッククラウド、プライベートクラウド、ハイブリッドクラウドなど の近代的でダイナミックな環境において、スケーラブルなアプリケーションを構築および実行す るための能力を組織にもたらします。 このアプローチの代表例に、コンテナ、サービスメッ シュ、マイクロサービス、イミュータブルインフラストラクチャ、および宣言型 APIがあります。 これらの手法により、回復性、管理力、および可観測性のある疎結合システムが実現します。 これらを堅牢な自動化と組み合わせることで、エンジニアはインパクトのある変更を最小限の 労力で頻繁かつ予測どおりに行うことができます。 https://github.com/cncf/toc/blob/main/DEFINITION.md
11. CNCFによるクラウドネイティブの定義 クラウドネイティブ技術は、パブリッククラウド、プライベートクラウド、ハイブリッドクラウドなど の近代的でダイナミックな環境において、スケーラブルなアプリケーションを構築および実行す るための能力を組織にもたらします。 このアプローチの代表例に、コンテナ、サービスメッ シュ、マイクロサービス、イミュータブルインフラストラクチャ、および宣言型 APIがあります。 これらの手法により、回復性、管理力、および可観測性のある疎結合システムが実現します。 これらを堅牢な自動化と組み合わせることで、エンジニアはインパクトのある変更を最小限の 労力で頻繁かつ予測どおりに行うことができます。 https://github.com/cncf/toc/blob/main/DEFINITION.md ?
12. みなさん、クラウドは使ってますよね？
13. そもそもクラウドって何？
14. NISTによるクラウドコンピューティングの定義 クラウドの基本的な特徴 • オンデマンド・セルフサービス • 幅広いネットワークアクセス • リソースの共用 • スピーディな拡張性 • サービスが計測可能であること https://www.ipa.go.jp/files/000025366.pdf
15. NISTによるクラウドコンピューティングの定義 クラウドの基本的な特徴 • オンデマンド・セルフサービス • 幅広いネットワークアクセス • リソースの共用 • スピーディな拡張性 • サービスが計測可能であること https://www.ipa.go.jp/files/000025366.pdf 使った分だけ課金 低い初期費用 スケールしやすい 運用を肩代わり リソースの 調達が早い
16. NISTによるクラウドコンピューティングの定義 クラウドの基本的な特徴 • オンデマンド・セルフサービス • 幅広いネットワークアクセス • リソースの共用 • スピーディな拡張性 • サービスが計測可能であること https://www.ipa.go.jp/files/000025366.pdf 使った分だけ課金 低い初期費用 スケールしやすい 運用を肩代わり リソースの 調達が早い APIでコントロール出 来る
17. APIがあると何が出来る？ • プログラムから叩ける • 自動化出来る • サービス間連携がしやすい ⇨ IaCツールで構築、CI/CDツールからのデプロイ、オートス ケール、etc..
18. クラウドで 高速化したよ 数分で 環境作れるよ 数msで 処理終わるよ 前の処理が 終わったら 自動で動くよ
19. クラウドで 高速化したよ 数分で 環境作れるよ 数msで 処理終わるよ 前の処理が 終わったら 自動で動くよ
20. Latency Numbers Every Programmer Should Know https://gist.github.com/jboner/2841832 https://colin-scott.github.io/personal_website/research/interactive_latency.html
21. Latency Numbers Every Programmer Should Know https://gist.github.com/jboner/2841832 上司の許可取ってサーバー 1台構築　 259,200,000,000,000 ns
22. クラウドで 高速化したよ 数分で 環境作れるよ 数msで 処理終わるよ 前の処理が 終わったら 自動で動くよ
23. 承認待ち 3日 他チームの 返事待ち6時間 稟議◦週間 意思決定 3時間
24. 承認待ち 3日 他チームの 返事待ち6時間 稟議◦週間 意思決定 3時間 クラウドネイティブの時代では 人間の存在自体がボトルネック
25. 設定ミス 伝達漏れ 見落とし 機密情報を 間違って コミットする
26. 設定ミス 伝達漏れ 見落とし 機密情報を 間違って コミットする あなたが居ない方が、仕事は早く回る
27. 人間を挟まない 仕組み作り API API API API API API API API API API
28. CNCFによるクラウドネイティブの定義 クラウドネイティブ技術は、パブリッククラウド、プライベートクラウド、ハイブリッドクラウドなど の近代的でダイナミックな環境において、スケーラブルなアプリケーションを構築および実行す るための能力を組織にもたらします。 このアプローチの代表例に、コンテナ、サービスメッ シュ、マイクロサービス、イミュータブルインフラストラクチャ、および宣言型 APIがあります。 これらの手法により、回復性、管理力、および可観測性のある疎結合システムが実現します。 これらを堅牢な自動化と組み合わせることで、エンジニアはインパクトのある変更を最小限の 労力で頻繁かつ予測どおりに行うことができます。 https://github.com/cncf/toc/blob/main/DEFINITION.md
29. CNCFによるクラウドネイティブの定義 クラウドネイティブ技術は、パブリッククラウド、プライベートクラウド、ハイブリッドクラウドなど の近代的でダイナミックな環境において、スケーラブルなアプリケーションを構築および実行す るための能力を組織にもたらします。 このアプローチの代表例に、コンテナ、サービスメッ シュ、マイクロサービス、イミュータブルインフラストラクチャ、および宣言型 APIがあります。 これらの手法により、回復性、管理力、および可観測性のある疎結合システムが実現します。 これらを堅牢な自動化と組み合わせることで、エンジニアはインパクトのある変更を最小限の 労力で頻繁かつ予測どおりに行うことができます。 https://github.com/cncf/toc/blob/main/DEFINITION.md APIで叩けるインフラ
30. CNCFによるクラウドネイティブの定義 クラウドネイティブ技術は、パブリッククラウド、プライベートクラウド、ハイブリッドクラウドなど の近代的でダイナミックな環境において、 スケーラブルなアプリケーションを構築および実行す るための能力を組織にもたらします。 このアプローチの代表例に、コンテナ、サービスメッ シュ、マイクロサービス、イミュータブルインフラストラクチャ、および宣言型 APIがあります。 これらの手法により、回復性、管理力、および可観測性のある疎結合システムが実現します。 これらを堅牢な自動化と組み合わせることで、エンジニアはインパクトのある変更を最小限の 労力で頻繁かつ予測どおりに行うことができます。 https://github.com/cncf/toc/blob/main/DEFINITION.md
31. CNCFによるクラウドネイティブの定義 クラウドネイティブ技術は、パブリッククラウド、プライベートクラウド、ハイブリッドクラウドなど の近代的でダイナミックな環境において、 スケーラブルなアプリケーションを構築および実行す るための能力を組織にもたらします。 このアプローチの代表例に、コンテナ、サービスメッ シュ、マイクロサービス、イミュータブルインフラストラクチャ、および宣言型 APIがあります。 これらの手法により、回復性、管理力、および可観測性のある疎結合システムが実現します。 これらを堅牢な自動化と組み合わせることで、エンジニアはインパクトのある変更を最小限の 労力で頻繁かつ予測どおりに行うことができます。 https://github.com/cncf/toc/blob/main/DFINITION.md APIを活用して、人間の関与を減らしつつ、大 量のリソースを自動化できる仕組み作り
32. つまり、クラウドネイティブの本質とは 全ての活動において 『コンピュータの力でコンピュータを動かす』 『人間の関与を無くす』 を実践していくこと。 クラウドネイティブ技術はこれが出来るポテンシャルを持ってい る https://github.com/cncf/toc/blob/main/DEFINITION.md
33. こういう質問をよく受けます うちはAWSオンリー なんだけど、 Kubernetes使った方が 良いの？ コンテナのほうが 良いのかな･･･ VMじゃダメ？ オンプレやめて全部 クラウドにしました。 これでクラウドネイティ ブだよね？ ベンダーがクラウド ネイティブ製品売り込んで きてるんだけど、やっぱりそう いうの買った方がいい？
34. 人を挟まない仕組みを作れるかどうかが全て コンテナを使っても、人が挟まったらメリットは消え去る docker build docker push mvn package kubectl apply VMを使っても、クラウドネイティブは実現出来る git push
35. 留意すべき点
36. 真のDevOps 開発者が、アプリをエンドツーエンドでデプロイし、実行する ただし、多くの組織にとって現実的ではない Kubernetes Buildkit Helm Dockerfile Grafana Prometheus GitHub Actions React Next.js Security Node.js Terraform ArgoCD APM Compliance 認知負荷が 高すぎる これをやり切れ る人材は少ない
37. 認知負荷の増大 https://www.infoq.com/articles/platform-engineering-primer/ より引用
38. 認知負荷を低く、生産性を高めるプラットフォーム • クラウドネイティブな自動化基盤作りを、開発者自身が担うこ とによる認知負荷の高まりが問題になりつつある • 仕組み作りを担うPlatform Teamと協力し、認知負荷を高め ずにクラウドネイティブ技術を取り込んでいく • Platform Engineeringという分野が発展中
39. 抽象化した機能の提供 Platform Engineering https://tag-app-delivery.cncf.io/whitepapers/platforms/ より和訳 プロダクトチーム プラットフォームチーム インター フェース 提供 機能 ドキュメント GUI (ポータル) プロジェクトテンプレート APIとCLI 環境とリソースの提供 インフラリソース データ保管 メッセージング ID管理と認証 CI/CD サービス連携 成果物管理 セキュリティ 可観測性
40. こんな話も
41. 一方でこんな話もあります “障害のほとんどはデプロイによって引き起こされる。した がって、デプロイが増えると障害も増え、結果としてインシ デント管理、軽減策、ポストモーテムが必要となる ” エレガントパズル　エンジニアのマネジメントという難問にあなたはどう立ち向かう のか より引用
42. 生産性と信頼性をどう両立していくか • 生産性を高めていくことはとても重要 • 一方で、高速に回せるようになるとその分障害の可能性が高くなる
43. 信頼性を高めるための大方針 基本的にはクラウドネイティブ思考を尊重 • 『コンピュータの力でコンピュータを動かす』 • 『人間の関与を無くす』
44. 顧客影響 予測可能 予測不可能 なし あり 計画メンテナンス インシデント 通常運用 優先度低 システム障害
45. 顧客影響 予測可能 予測不可能 なし あり 計画メンテナンス インシデント 通常運用 優先度低 システム障害
46. 顧客影響 予測可能 予測不可能 なし あり 計画メンテナンス インシデント 通常運用 優先度低 システム障害 ✅ 素早く気づく ✅ 素早く直す ⇨インシデント対応
47. オンコール 必要なアラートだけに絞り込み 電話やSMS、プッシュ通知、Slack など、人それぞれ適した通知 一次対応者 オンコールの ローテーション
48. + だと Past Incidents 過去の類似インシデント一覧と、 発生時期・回数のヒートマップを表示。 Related Incidents 他サービスで現在発生している、 関連性の高いインシデントを表示。
49. 顧客影響 予測可能 予測不可能 なし あり 計画メンテナンス インシデント 通常運用 優先度低 システム障害 軽減策 アーキテクチャの 改善 自動化
50. 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
51. アラートに応じた自動化 アラートを受信 インシデントを起票 切り分けのための タスクを実行 自動修復 軽減策のタスクを 実行
52. 顧客影響 予測可能 予測不可能 なし あり 計画メンテナンス インシデント 通常運用 優先度低 システム障害
53. 顧客影響 予測可能 予測不可能 なし あり 計画メンテナンス インシデント 通常運用 優先度低 システム障害 予測できないものを自 動化するのは困難
54. 顧客影響 予測可能 予測不可能 なし あり 計画メンテナンス インシデント 通常運用 優先度低 システム障害 ポストモーテム 継続的な学び
55. ポストモーテム SREのプラクティスでおなじみ • インシデントのインパクト • 緩和や解消のために行われたアクション • 根本原因 • インシデントの再発を避けるためのフォローアップ きちんと纏めておくことで、組織としての成長に繋がる。
56. + だと Postmotems ポストモーテムの作成を支援。受信したイベント、ステータスアップデート、インシデント ノート、Slackの会話などからタイムラインを作成
57. マニュアル リアクティブ レスポンシブ 積極的 予防的 問題は社内チームではなく 顧客によって特定される。 オペレーションプロセスはレガ シーシステムに依存しており、イ ンシデントは手動で発生し、チ ケットシステムなどのキューイン グワークフローを使用して処理 される。 緊急時に専門家に迅速にアク セスするための仕組みがほとん どない。 常に消火モード 初期の技術投資により、クラウ ドホスティングやアプリケーショ ンの成熟度に応じてリアルタイ ムでの可視化と動員が可能に なる。 分散型チームのアプローチが 見られるが、スキルはサイロ 化されている。 インシデントを管理するための 明確なプロセスがない。 問題が発生する前に先回り 優れた顧客体験が常に維持さ れる。 機械学習に基づく予測的な修 正が行われる。 組織全体で一貫したベストプラ クティスが実施される。 高度に自動化されたプロセスに より、雑務やエスカレーションが 排除される。 継続的な学習、改善、予防が技 術的でない関係者を含む組織 全体で行われる。 チームは変更の将来的な影響 を予測できる。 問題が発生するたびに解決 チームは顧客に影響を与える 問題をより迅速に把握できる。 機械学習を使用して潜在的な 問題を特定し、誤検知を減ら し、ノイズを低減する。 問題は自動的に特定され、専 門家によって対応されるが、適 切なチームを編成することは 依然として課題である。 分散型チームがマイクロサー ビスの完全な責任を持つよう になる。 シームレスで協調的な 問題管理 問題は顧客が気付く前に技術 チームによって検出・修正され る。 問題に関する情報は、ビジネス のステークホルダーを含む適切 な人物に提供される。 プログラム学習と最適化の機会 の特定が一般化している。 分散型チームは、サービス変更 の影響を理解し、運用の責任を 完全に負う。 チームとして対応し、運用の成熟度を上げていく
58. まとめ • クラウドネイティブの時代においては、『コンピュータの力でコンピュータを動 かす』『人間の関与を無くす』の意識が大事 • そうすることで、コンピュータの速度で物事を動かし、生産性を高める • その分インシデントが起きる確率も高くなるので、信頼性を高める取り組みも 大事 • PagerDutyを活用して、継続的な学びを行うことで生産性と信頼性を両立させ る