Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Kubernetes がない世界の CloudNative ジャーニー
Search
athagi
March 12, 2021
0
340
Kubernetes がない世界の CloudNative ジャーニー
20210312 に行われた CloudNative Days Spring 2021 ONLINE のスライドです
athagi
March 12, 2021
Tweet
Share
More Decks by athagi
See All by athagi
社内でAWS GameDayを開催しよう
athagi
2
380
petなEC2をまとめて監視してみた
athagi
1
190
既存の仕組みを棄てる技術
athagi
0
710
冴えない開発環境の育てかた
athagi
0
72
GitLab-CI でPrivate Registry を利用する話
athagi
0
1.3k
ゆるキャンはじめました。
athagi
0
1.5k
Windows Server にAnsibleを使ってみた話
athagi
2
2k
Featured
See All Featured
Unsuck your backbone
ammeep
669
57k
It's Worth the Effort
3n
183
28k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
330
21k
10 Git Anti Patterns You Should be Aware of
lemiorhan
PRO
656
59k
Product Roadmaps are Hard
iamctodd
PRO
50
11k
Documentation Writing (for coders)
carmenintech
67
4.5k
Learning to Love Humans: Emotional Interface Design
aarron
274
40k
Statistics for Hackers
jakevdp
796
220k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
159
15k
The MySQL Ecosystem @ GitHub 2015
samlambert
250
12k
For a Future-Friendly Web
brad_frost
175
9.5k
Agile that works and the tools we love
rasmusluckow
328
21k
Transcript
Kubernetesがない世界のCloudNative ジャーニー あさぎ(@_athagi) CloudNative Days Spring 2021 ONLINE (#CNDO2021)
古き良き導入 LB AP AP AP DB DB Dev git push
Ops
古き良き導入 Dev git push LB AP AP AP DB DB
Ops
これからの時代は だ! SaaS クラウド
を使おう!
クラウドネイティブへのアプローチ • 0からクラウドネイティブに作り直す:夢のある方針 ◦ 新規に作り始めるならこっち ◦ 既存システムがある場合はビックバンリライトになる ▪ 保証されるのはビッグバンだけ(Martin Fowler)
• リフト&シフトして徐々に最適化する:現実的な方針 ◦ 長期的な観点で計画を立てる必要がある ◦ クラウドリフト後に最適化するためにリファクタリングしないと単 なるリホストになってしまう
クラウドネイティブとは クラウドネイティブ技術は、パブリッククラウド、プライベートクラウド、ハイブリッドクラウドなどの近代的でダイナミック な環境において、スケーラブルなアプリケーションを構築および実行するための能力を組織にもたらします。このアプ ローチの代表例に、コンテナ、サービスメッシュ、マイクロサービス、イミュータブルインフラストラクチャ、および宣言 型APIがあります。 これらの手法により、回復性、管理力、および可観測性のある疎結合システムが実現します。 これらを堅牢な自動 化と組み合わせることで、エンジニアはインパクトのある変更を最小限の労力で頻繁かつ予測どおりに行うことがで
きます。 Cloud Native Computing Foundationは、オープンソースでベンダー中立プロジェクトのエコシステムを育成・維持し て、このパラダイムの採用を促進したいと考えてます。 私たちは最先端のパターンを民主化し、これらのイノベーショ ンを誰もが利用できるようにします。 CNCF Cloud Native Definition v1.0 : https://github.com/cncf/toc/blob/main/DEFINITION.md
クラウドネイティブとは クラウドネイティブ技術は、パブリッククラウド、プライベートクラウド、ハイブリッドクラウドなどの近代的でダイナミック な環境において、 スケーラブルなアプリケーションを構築および実行するための能力を組織にもたらします。このアプ ローチの代表例に、コンテナ、サービスメッシュ、マイクロサービス、イミュータブルインフラストラクチャ、および宣言 型APIがあります。 これらの手法により、 回復性、管理力、および可観測性のある疎結合システム
が実現します。 これらを 堅牢な自動 化と組み合わせることで、エンジニアは インパクトのある変更を最小限の労力で頻繁かつ予測どおりに行うこと がで きます。 Cloud Native Computing Foundationは、オープンソースでベンダー中立プロジェクトのエコシステムを育成・維持し て、このパラダイムの採用を促進したいと考えてます。 私たちは最先端のパターンを民主化し、これらのイノベーショ ンを誰もが利用できるようにします。 CNCF Cloud Native Definition v1.0 : https://github.com/cncf/toc/blob/main/DEFINITION.md
クラウドネイティブのメリット 素早く継続的にユーザに価値を届ける • スケーラブル • 堅牢な自動化 • 回復性 • 管理のしやすさ
• 可観測性 • 疎結合 変更を最小限の労力で頻繁かつ予測どおりに行う
じゃないとクラウドネイティブにはなれない?
がある世界とない世界
のある世界
K8s のある世界 CI Container Registry Dev Ops/SRE git push image
push manifest
K8s のある世界 CI Container Registry Dev Ops/SRE git push image
push manifest
特徴 • コンテナの恩恵 ◦ どの環境でも同じように動く • K8s の恩恵 ◦
宣言的な構成管理 ◦ 開発と運用の関心ごとを分離 ◦ 自動化されたロールアウト/ロールバック ◦ 自己修復 • 組織としてK8s をキャッチアップしていく必要性
のない世界
K8s のない世界 Golden Image git push Artifact Dev Ops/SRE
Deploy script CI
K8s のない世界 Golden Image git push Artifact Dev Deploy
script Ops/SRE CI
特徴 • 以前の組織構造をそのまま持っていける ◦ 組織の役割を大きく変えずにクラウドリフトできる ◦ 最終的にはクラウドに適応した組織構造に変える • 元々の構成をそのままツールに乗せるので理解しやすい ◦
局所的に作業を自動化できる • K8s の学習コストを払うことを避けられる
クラウドネイティブのメリット 「クラウドネイティブになりました!」という プレスリリース
クラウドネイティブのメリット ではなく
クラウドネイティブのメリット 素早く継続的にユーザに価値を届ける
K8s のある世界とない世界の差分 • K8s がある世界 ◦ 宣言的 ◦ コンテナイメージという単一の成果物 ◦
インフラ・K8s・アプリを管理 • K8s がない世界 ◦ 命令的 ◦ Artifact と Golden Image の組み合わせ ◦ インフラ・OS・アプリを管理
共通な部分 • テストを書いてCICDを頻繁に回すことが必要 ◦ CIで仕様と実装のズレを検知 ◦ 環境への継続的なデプロイ • 常にデプロイ可能な成果物 •
IaC は必須 • 自動化によってレバレッジを効かせていく • 分散モノリスになる可能性
K8s がない世界の落とし穴
K8s がない世界の落とし穴 Dev git push LB AP AP AP DB
DB Ops
AWS Cloud K8s がない世界の落とし穴 Golden Image git push Artifact
Dev Deploy script SRE
K8s がない世界の落とし穴 • 一つのチームで開発のサイクルが回せない ◦ 組織間のオーバーヘッドが発生し、素早くサイクルを回せない • クラウドシフトして局所的な自動化で満足してしまうため、組織の境界が 変わる力学が働かない •
アドホックな自動化による業務の硬直化 • K8s やコンテナが解決している問題を自分たちで実装する必要あり • チーム間の技術スタックが異なり、組織内で共有可能なナレッジが蓄積さ れない可能性
対応策 • プロダクト開発チームがセルフサービスで運用していける状 態を目指す • オプションとして運用のベストプラクティスを導入できるように するためのある程度の共通化 • 局所最適にならないためのプロダクト全体のデザイン
対応策 • Stream-aligned team ◦ ユーザに価値を届けることが可能な チーム • Enabling team
◦ Stream-aligned team をサポートして出 来るようにする • Platform team ◦ セルフサービスなプラットフォームを Stream-aligned team に提供 Team Topologies: Organizing Business and Technology Teams for Fast Flow
クラウドネイティブの時代 Stream-aligned team • プロダクト開発 • ビルド・デリバリー・デプロイ • テスト環境の管理 •
本番環境の運用 Enabling team(SRE) • プロダクトチームの補助 ▪ 運用やCICDのプラクティスの提供 Platform team • セルフサービスのプラットフォーム 対応策 古き良き時代 Dev • プロダクト開発 • ビルド・デリバリー Ops • テスト環境の管理 • 本番環境へのデプロイ • 運用 • 監視
対応策 Golden Image git push Artifact Deploy script CI
でも、そもそも
でも、そもそも...... • K8s の学習コストを払わない代わりに、自分たちで作りこまなくてはなら ない ◦ 仕組みに乗ることで落とし穴を避けられる ▪ Kubernetes ▪
マネージドサービス • 変化に対応できる組織になる必要がある ◦ 組織レベルで古き良き時代から変わる必要がある • (クラウドリフトも大変だけど)クラウドジャーニーに終わりはないという マインドが必要
まとめ • クラウドネイティブのメリットを最大化 ◦ テストやCICDを整備することの必要性 ◦ 独立したチームで開発サイクルをまわす • K8s がなくてもクラウドネイティブのメリットを受けることは可能
• K8s があると向かっていくべき方向が見えやすくなる • クラウドジャーニーに終わりはない