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を選択する理由
Search
Atsushi Tanaka
June 15, 2024
Programming
12
2.9k
マイクロサービス基盤にフルマネージドサービスではなくKubernetesを選択する理由
https://event.cloudnativedays.jp/cnds2024/proposals/731
Atsushi Tanaka
June 15, 2024
Tweet
Share
More Decks by Atsushi Tanaka
See All by Atsushi Tanaka
Wantedly での Datadog 活用事例
bgpat
2
2.6k
KubernetesでDatadogを飼うならオートディスカバリーを使わないと損
bgpat
2
550
400万ユーザーに価値を届けるエンジニアを を支えるインフラ基盤
bgpat
3
370
Ruby製社内ツールのGo移行
bgpat
2
580
導入から5年が経って見えた Datadog APM 運用の課題
bgpat
3
1.2k
取っていてよかった Kubernetes のバックアップ
bgpat
1
620
Terraform と Kubernetes の共存による IaC の実践
bgpat
0
1.8k
Kubernetes Cluster Migration
bgpat
4
4.6k
k8sとNginxでオートスケール / Autoscaling with k8s and Nginx
bgpat
2
1.3k
Other Decks in Programming
See All in Programming
Code smarter, not harder - How AI Coding Tools Boost Your Productivity | Angular Meetup Berlin
danielsogl
0
100
Better Code Design in PHP
afilina
0
160
ナレッジイネイブリングにAIを活用してみる ゆるSRE勉強会 #9
nealle
0
140
Honoとフロントエンドの 型安全性について
yodaka
7
1.4k
CI改善もDatadogとともに
taumu
0
190
CDK開発におけるコーディング規約の運用
yamanashi_ren01
2
240
Serverless Rust: Your Low-Risk Entry Point to Rust in Production (and the benefits are huge)
lmammino
1
150
DROBEの生成AI活用事例 with AWS
ippey
0
140
PEPCは何を変えようとしていたのか
ken7253
2
140
Honoをフロントエンドで使う 3つのやり方
yusukebe
7
3.5k
PHPのバージョンアップ時にも役立ったAST
matsuo_atsushi
0
220
『テスト書いた方が開発が早いじゃん』を解き明かす #phpcon_nagoya
o0h
PRO
8
2.3k
Featured
See All Featured
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
226
22k
ReactJS: Keep Simple. Everything can be a component!
pedronauck
666
120k
A Philosophy of Restraint
colly
203
16k
Navigating Team Friction
lara
183
15k
Building an army of robots
kneath
303
45k
Optimising Largest Contentful Paint
csswizardry
34
3.1k
Fireside Chat
paigeccino
34
3.2k
The Straight Up "How To Draw Better" Workshop
denniskardys
232
140k
Building Applications with DynamoDB
mza
93
6.2k
The MySQL Ecosystem @ GitHub 2015
samlambert
250
12k
[RailsConf 2023] Rails as a piece of cake
palkan
53
5.3k
Bash Introduction
62gerente
611
210k
Transcript
© 2024 Wantedly, Inc. マイクロサービス基盤に フルマネージドサービスではなく Kubernetesを選択する理由 CloudNative Days Summer
2024 Jun. 15 2024 - Atsushi Tanaka @bgpat 1
© 2024 Wantedly, Inc. $ whoami @bgpat / Atsushi Tanaka
ウォンテッドリー株式会社 Infrastructure Engineer / Squad Leader Kubernetes / Terraform SRE / Platform Engineering 2
© 2024 Wantedly, Inc. 究極の適材適所により、 シゴトでココロオドルひとを ふやすために Wantedlyはパーパス‧共感を軸にした、⼈と会社との出会いを2012 年から創出。 はたらくすべての⼈が共感を通じて「であい」「つながり」「つなが
りを深める」ためのビジネスSNS「Wantedly」を提供しています。 1⼈でも多くの⼈がワクワクしたり、熱中してシゴトと向き合えるよ うな世界を実現するために、国境を超えて「はたらくすべての⼈のイ ンフラ」を創っていきます。 提供サービス 会社紹介 3
© 2024 Wantedly, Inc. 会社紹介 • マイクロサービスを Kubernetes 上で運⽤ ◦
⼀部サービスを2016年から本番運⽤開始 ◦ 2018年に全サービスの移⾏が完了 • Amazon EKS を利⽤ ◦ 2022年までは kOps (Kubernetes on EC2) で構成 • 2024年6⽉時点の利⽤状況 ◦ 3 clusters, 145 nodes ◦ 360 namespaces, 3.66k pods, 8.20k containers ◦ 80 microservices, 34 addons インフラ環境 4
© 2024 Wantedly, Inc. 会社紹介 約80個のマイクロサービスを運⽤ インフラ環境 5
© 2024 Wantedly, Inc. • すべてのサービスを Kubernetes 上で運⽤ ◦ ⼀部サービスを2016年から本番運⽤開始
◦ 2018年に全サービスの移⾏が完了 • Amazon EKS を利⽤ ◦ 2022年までは Kubernetes on EC2 で構成 • 2024年6⽉時点の利⽤状況 ◦ 3 clusters, 145 nodes ◦ 360 namespaces, 3.66k pods, 8.20k containers ◦ 34 addons/cluster 会社紹介 インフラ環境 6
© 2024 Wantedly, Inc. 最近よく聞かれること なぜ Kubernetes を使っているのか 7
© 2024 Wantedly, Inc. 結論 • マイクロサービス開発に Kubernetes の拡張性が必要 •
メンテナンスコストの⾼さを受け⼊れる意思決定 • 求める機能がクラウドに実装されれば移⾏を検討 Wantedly がフルマネージドサービスではなく Kubernetes を選択する理由 8
© 2024 Wantedly, Inc. アジェンダ • マイクロサービス基盤の⽐較 • 今 Kubernetes
を使う優位性 • メンテナンスコストを受け⼊れる⽅法 9
© 2024 Wantedly, Inc. コンテナ化されたマイクロサービスの基盤⽐較 10
© 2024 Wantedly, Inc. マイクロサービス基盤の⽐較 機能性 信頼性 保守性 手動構築した Kuberentes
Kubeadm, kOps, kube-aws ◎ △ ✕ マネージド Kubernetes サービス GKE, EKS, AKS ◎ ◯ △ フルマネージドサービス ECS, Cloud Run, ACA △ ◎ ◎ 11
© 2024 Wantedly, Inc. マイクロサービス基盤の分類 • ⼿動構築した Kubernetes Kubernetes に必要なコンポーネントをすべて⾃前で管理
• マネージド Kubernetes サービス control plane をクラウドが管理 • フルマネージドサービス アプリケーション以外はクラウドが管理 このセッションではコンテナ化されたマイクロサービス基盤を指す 12
© 2024 Wantedly, Inc. マイクロサービス基盤の⽐較 機能性 信頼性 保守性 手動構築した Kuberentes
Kubeadm, kOps, kube-aws ◎ △ ✕ マネージド Kubernetes サービス GKE, EKS, AKS ◎ ◯ △ フルマネージドサービス ECS, Cloud Run, ACA △ ◎ ◎ 13
© 2024 Wantedly, Inc. マイクロサービス基盤の⽐較 機能性 信頼性 保守性 手動構築した Kuberentes
Kubeadm, kOps, kube-aws ◎ △ ✕ マネージド Kubernetes サービス GKE, EKS, AKS ◎ ◯ △ フルマネージドサービス ECS, Cloud Run, ACA △ ◎ ◎ 14
© 2024 Wantedly, Inc. マイクロサービス基盤の⽐較 機能性 信頼性 保守性 手動構築した Kuberentes
Kubeadm, kOps, kube-aws ◎ △ ✕ マネージド Kubernetes サービス GKE, EKS, AKS ◎ ◯ △ フルマネージドサービス ECS, Cloud Run, ACA △ ◎ ◎ 15
© 2024 Wantedly, Inc. マイクロサービス基盤の⽐較 機能性 信頼性 保守性 手動構築した Kuberentes
Kubeadm, kOps, kube-aws ◎ △ ✕ マネージド Kubernetes サービス GKE, EKS, AKS ◎ ◯ △ フルマネージドサービス ECS, Cloud Run, ACA △ ◎ ◎ 16
© 2024 Wantedly, Inc. 過去はどうだったか 17
© 2024 Wantedly, Inc. 会社紹介 • マイクロサービスを Kubernetes 上で運⽤ ◦
⼀部サービスを2016年から本番運⽤開始 ◦ 2018年に全サービスの移⾏が完了 • Amazon EKS を利⽤ ◦ 2022年までは kOps (Kubernetes on EC2) で構成 • 2024年6⽉時点の利⽤状況 ◦ 3 clusters, 145 nodes ◦ 360 namespaces, 3.66k pods, 8.20k containers ◦ 80 microservices, 34 addons インフラ環境 18
© 2024 Wantedly, Inc. マイクロサービス基盤の⽐較 (2024年) 機能性 信頼性 保守性 手動構築した
Kuberentes Kubeadm, kOps, kube-aws ◎ △ ✕ マネージド Kubernetes サービス GKE, EKS, AKS ◎ ◯ △ フルマネージドサービス ECS, Cloud Run, ACA △ ◎ ◎ 19
© 2024 Wantedly, Inc. マイクロサービス基盤の⽐較 (2020年) 機能性 信頼性 保守性 手動構築した
Kuberentes Kubeadm, kOps, kube-aws ◎ △ ✕ マネージド Kubernetes サービス GKE, EKS, AKS ◎ ◯ △ フルマネージドサービス ECS, Cloud Run, ACA ACI ✕ ◎ ◎ 20
© 2024 Wantedly, Inc. マイクロサービス基盤の⽐較 (2016年) 機能性 信頼性 保守性 手動構築した
Kuberentes Kubeadm, kOps, kube-aws ◯ △ ✕ マネージド Kubernetes サービス GKE, EKS, AKS ◯ △ ✕ フルマネージドサービス ECS, Cloud Run GAE, ACA AAS ✕ ◯ ◯ 21
© 2024 Wantedly, Inc. マイクロサービス基盤の進化 • 2016年は全体的に基盤が整っていなかった ◦ 将来的に移⾏する可能性もあるのでロックインのリスクを⾼く⾒積もった ◦
何を選んでも⼤変だったので相対的に⼿動構築が⼀番良かった • フルマネージドサービスは2020年よりも使いやすく ◦ 機能が多く拡張性の⾼い Kubernetes でなくても運⽤できるように ⇨ 2024年に Kubernetes を使う必要はないのでは? 22
© 2024 Wantedly, Inc. 2024年に Kubernetes を使う優位性 23
© 2024 Wantedly, Inc. マイクロサービス基盤に求めるもの • マイクロサービスの運⽤ができること • マイクロサービスの開発ができること ^
クラウド上で開発まで⾏うことは考慮されていない 24
© 2024 Wantedly, Inc. マイクロサービス開発の⽣産性を上げるための要素 • 変更を素早く試せる ◦ フィードバックを早く受け取ることでリリースまでの時間を短くできる ◦
マイクロサービスに限らず⼤事な要素 • 他の変更の影響を受けない ◦ スコープを絞って開発できることがマイクロサービスのうまみ ◦ スコープ外に原因があると調査が難しくなる • 依存するサービスを意識しなくてよい ◦ 環境構築のハードルや運⽤コストが問題に ◦ 間接的に依存しているサービスがあるとより⼤変 25
© 2024 Wantedly, Inc. マイクロサービスをどこで開発‧デバッグするか • ローカル環境に構築 ◦ すぐにフィードバックが得られる ◦
環境構築が⼤変でPCのリソースが⾜りなくなることも • 既存のリモート環境にデプロイ ◦ 環境構築の必要がなく⽐較的早く試せる ◦ 他の開発者の作業と衝突することがある • 開発者ごとにリモート環境を構築 ◦ 他⼈の影響を受けることはない ◦ ⾦銭的コストが増える 26
© 2024 Wantedly, Inc. kubefork 変更する部分だけ差し替えて仮想的な⾃分専⽤のクラスタを作る 27
© 2024 Wantedly, Inc. kubefork 変更する部分だけ差し替えて仮想的な⾃分専⽤のクラスタを作る 28
© 2024 Wantedly, Inc. kubefork 変更する部分だけ差し替えて仮想的な⾃分専⽤のクラスタを作る • 誰がアクセスしているかをサービス間で伝搬 • Istio
のルーティング制御機能で開発中の pod に向ける • Telepresence によって⼿元の PC を pod として扱う • ⾜りない機能は Custom Controller で実装 ◦ フルマネージドサービスにはまだ難しい領域 ◦ kubebuilder のようなエコシステムに乗れるのもメリット 29
© 2024 Wantedly, Inc. 2024年に Kubernetes を使う優位性 マイクロサービス開発の基盤に Kubernetes の拡張性が必要
• 豊富な 3rd party 製 cluster addon が存在している ◦ 欲しいと思った機能は既に誰かが試していることが多い ◦ 既存の資産を流⽤できる • cluster addon を実装するためのエコシステムも充実 ◦ Reconciliation Loop の仕組みに乗れる ◦ Kubebuilder を使えば簡単に作れる 30
© 2024 Wantedly, Inc. メンテナンスコストを受け⼊れる⽅法 31
© 2024 Wantedly, Inc. Kubernetes のメンテナンスコストが⾼い要因 • 学習コストが⾼い ◦ 機能が多くシステムが複雑
◦ 正しく運⽤するために必要な知識が多い • リリース頻度が⾼い ◦ 3ヶ⽉に1回⼤きなアップデートがある ◦ cluster addon を利⽤している場合は互換性の確認が必要 32
© 2024 Wantedly, Inc. メンテナンスコストに対する⽅針 受け⼊れ可能なコストに抑える 1. 責務を切り出す: クラウド利⽤によりお⾦で解決 2.
運⽤フローの改善 3. 受け⼊れられるキャパシティを増やす 4. (撤退) 33
© 2024 Wantedly, Inc. メンテナンスコストに対する⽅針 受け⼊れ可能なコストに抑える 1. 責務を切り出す: クラウド利⽤によりお⾦で解決 2.
運⽤フローの改善 3. 受け⼊れられるキャパシティを増やす 4. (撤退) 34
© 2024 Wantedly, Inc. 責務をクラウドに切り出す kOps → EKS に移⾏ •
Control Plane のメンテナンスが不要に ◦ ⼿動管理時代は過去3回 etcd 関連の問題が発⽣ ◦ アップデート作業⾃体も短縮 • クラウドサービスのサポートが受けられる ◦ インフラ管理者の学習コストを削減 ◦ 並列数を上げ集合知も活⽤でき問題解決のリードタイムが改善 35
© 2024 Wantedly, Inc. メンテナンスコストに対する⽅針 受け⼊れ可能なコストに抑える 1. 責務を切り出す: クラウド利⽤によりお⾦で解決 2.
運⽤フローの改善 3. 受け⼊れられるキャパシティを増やす 4. (撤退) 36
© 2024 Wantedly, Inc. 運⽤フローの改善 • 学習コストを減らす ◦ よく使う機能を wrap
した内製ツールを⽤意 • アップデートの負担を減らす ◦ cluster addon のアップデート作業を⼀部⾃動化 ◦ アップデート作業を継続的に改善 37
© 2024 Wantedly, Inc. 学習コストを減らす エンジニア⽤の内製ツール “kube” • 簡単に k8s
を利⽤するための便利機能を提供 ◦ 開発ステップ毎に必要なコマンドを⼀つに集約 ◦ テンプレート化で優先して意識すべき項⽬に集中 • 学習コストを増やさないための設計 ◦ k8s 以前の基盤で使われていたツールのコマンド体系を採⽤ ◦ 標準ツール “kubectl” の機能はそのまま提供しトラブルシューティングを容易に 38
© 2024 Wantedly, Inc. cluster addon のアップデート作業を⼀部⾃動化 k8s を使うなら cluster
addon 管理からは逃げられない • cluster addon なしで運⽤するのは事実上不可能 ◦ ベンダー依存の処理は addon として実装されている ◦ 例: Ingress Controller, CSI Driver, ... • cluster upgrade 前に互換性のあるバージョンに ◦ addon は内部で Kubernetes API を利⽤している ◦ 新しい Kubernetes のバージョンで利⽤している API が変更‧廃⽌されることも 39
© 2024 Wantedly, Inc. cluster addon のアップデート作業を⼀部⾃動化 ⾃動化できそうな箇所 • 処理とマニフェストを⼀致させる必要がある
◦ cluster addon = container image + k8s manifest ◦ 例: RBAC の更新を忘れて API でエラーが発⽣ • cluster addon の更新で削除されたリソースの掃除 ◦ kubectl apply では削除はできない ◦ --prune は廃⽌, 後継の ApplySet も課題あり 40
© 2024 Wantedly, Inc. cluster addon のアップデート作業を⼀部⾃動化 やったこと • Helmfile
で container image と k8s manifest を同時に更新 • Renovate で pull request を⾃動作成 • Argo CD で GitHub と k8s cluster を同期 41
© 2024 Wantedly, Inc. アップデート作業を継続的に改善 アップデート作業だけでなく取り組み⾃体をマニュアル化 42
© 2024 Wantedly, Inc. メンテナンスコストに対する⽅針 受け⼊れ可能なコストに抑える 1. 責務を切り出す: クラウド利⽤によりお⾦で解決 2.
運⽤フローの改善 3. 受け⼊れられるキャパシティを増やす 4. (撤退) 43
© 2024 Wantedly, Inc. 受け⼊れられるキャパシティを増やす • (今までの運⽤経験) • Kubernetes を運⽤できる⼈の採⽤
• Kubernetes 運⽤に割くリソースを確保 44
© 2024 Wantedly, Inc. メンテナンスコストを受け⼊れる⽅法 • クラウドに責務を切り出す • ⾃動化とツールやマニュアル整備で負担を最⼩化 •
それでもまだ⾼いメンテナンスコストは組織的に対処 45
© 2024 Wantedly, Inc. まとめ 46
© 2024 Wantedly, Inc. 結論 • マイクロサービス開発に Kubernetes の拡張性が必要 ◦
サービス運⽤だけでなく開発にも使えるマイクロサービス基盤 ◦ 導⼊当時に必要だった運⽤の機能は k8s でなくても代替可能に • メンテナンスコストの⾼さを受け⼊れる意思決定 ◦ 特に頻繁に来る⼤規模アップデート対応による負担が問題 ◦ コストを受け⼊れられる仕組みを整備し組織的な体制も⽤意 • 求める機能がクラウドに実装されれば移⾏を検討 ◦ 既存の価値を維持しつつ新しい価値に注⼒したい Wantedly がフルマネージドサービスではなく Kubernetes を選択する理由 47
© 2024 Wantedly, Inc. マイクロサービス基盤の選定 • 技術選定の結果はタイミングにより異なる ◦ 登場してすぐは機能が少なく信頼性も低くなりがち ◦
クラウドサービス成熟により機能は増え信頼性も上がる • 今 Kubernetes を選択すべきユースケースは減少 ◦ クラウドベンダーが想定していない使い⽅には Kubernetes が刺さる ◦ マイクロサービス運⽤だけならフルマネージドサービスの機能で⼗分⾜りる ◦ ⾼いメンテナンスコストを払ってまで k8s を選択する価値があるか熟慮すべき 48
© 2024 Wantedly, Inc. We are Hiring! 49