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.6k
マイクロサービス基盤にフルマネージドサービスではなく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
KubernetesでDatadogを飼うならオートディスカバリーを使わないと損
bgpat
1
400
400万ユーザーに価値を届けるエンジニアを を支えるインフラ基盤
bgpat
3
310
Ruby製社内ツールのGo移行
bgpat
2
530
導入から5年が経って見えた Datadog APM 運用の課題
bgpat
3
1.1k
取っていてよかった Kubernetes のバックアップ
bgpat
1
550
Terraform と Kubernetes の共存による IaC の実践
bgpat
0
1.6k
Kubernetes Cluster Migration
bgpat
4
4.5k
k8sとNginxでオートスケール / Autoscaling with k8s and Nginx
bgpat
2
1.3k
GCPのgemにコントリビュートした話
bgpat
0
740
Other Decks in Programming
See All in Programming
EventSourcingの理想と現実
wenas
6
2.3k
카카오페이는 어떻게 수천만 결제를 처리할까? 우아한 결제 분산락 노하우
kakao
PRO
0
110
Hotwire or React? ~アフタートーク・本編に含めなかった話~ / Hotwire or React? after talk
harunatsujita
1
120
Ethereum_.pdf
nekomatu
0
460
NSOutlineView何もわからん:( 前編 / I Don't Understand About NSOutlineView :( Pt. 1
usagimaru
0
330
Webの技術スタックで マルチプラットフォームアプリ開発を可能にするElixirDesktopの紹介
thehaigo
2
1k
ペアーズにおけるAmazon Bedrockを⽤いた障害対応⽀援 ⽣成AIツールの導⼊事例 @ 20241115配信AWSウェビナー登壇
fukubaka0825
6
1.9k
TypeScriptでライブラリとの依存を限定的にする方法
tutinoko
2
660
イベント駆動で成長して委員会
happymana
1
320
Flutterを言い訳にしない!アプリの使い心地改善テクニック5選🔥
kno3a87
1
160
シェーダーで魅せるMapLibreの動的ラスタータイル
satoshi7190
1
480
Make Impossible States Impossibleを 意識してReactのPropsを設計しよう
ikumatadokoro
0
170
Featured
See All Featured
Building an army of robots
kneath
302
43k
Designing the Hi-DPI Web
ddemaree
280
34k
A Tale of Four Properties
chriscoyier
156
23k
Typedesign – Prime Four
hannesfritz
40
2.4k
Git: the NoSQL Database
bkeepers
PRO
427
64k
Ruby is Unlike a Banana
tanoku
97
11k
Music & Morning Musume
bryan
46
6.2k
Documentation Writing (for coders)
carmenintech
65
4.4k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
4
370
The World Runs on Bad Software
bkeepers
PRO
65
11k
Large-scale JavaScript Application Architecture
addyosmani
510
110k
How STYLIGHT went responsive
nonsquared
95
5.2k
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