マイクロサービス基盤にフルマネージドサービスではなくKubernetesを選択する理由

by Atsushi Tanaka

Embed

Start on current slide

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

© 2024 Wantedly, Inc. 究極の適材適所により、シゴトでココロオドルひとをふやすために Wantedlyはパーパス‧共感を軸にした、⼈と会社との出会いを2012 年から創出。はたらくすべての⼈が共感を通じて「であい」「つながり」「つながりを深める」ためのビジネスSNS「Wantedly」を提供しています。 1⼈でも多くの⼈がワクワクしたり、熱中してシゴトと向き合えるような世界を実現するために、国境を超えて「はたらくすべての⼈のインフラ」を創っていきます。提供サービス会社紹介 3

Slide 4

Slide 4 text

© 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

Slide 5

Slide 5 text

Slide 6

Slide 6 text

© 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

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Slide 9

Slide 9 text

Slide 10

Slide 10 text

Slide 11

Slide 11 text

Slide 12

Slide 12 text

Slide 13

Slide 13 text

Slide 14

Slide 14 text

Slide 15

Slide 15 text

Slide 16

Slide 16 text

Slide 17

Slide 17 text

Slide 18

Slide 18 text

Slide 19

Slide 19 text

Slide 20

Slide 20 text

Slide 21

Slide 21 text

Slide 22

Slide 22 text

© 2024 Wantedly, Inc. マイクロサービス基盤の進化 ● 2016年は全体的に基盤が整っていなかった ○ 将来的に移⾏する可能性もあるのでロックインのリスクを⾼く⾒積もった ○ 何を選んでも⼤変だったので相対的に⼿動構築が⼀番良かった ● フルマネージドサービスは2020年よりも使いやすく ○ 機能が多く拡張性の⾼い Kubernetes でなくても運⽤できるように ⇨ 2024年に Kubernetes を使う必要はないのでは？ 22

Slide 23

Slide 23 text

Slide 24

Slide 24 text

Slide 25

Slide 25 text

© 2024 Wantedly, Inc. マイクロサービス開発の⽣産性を上げるための要素 ● 変更を素早く試せる ○ フィードバックを早く受け取ることでリリースまでの時間を短くできる ○ マイクロサービスに限らず⼤事な要素 ● 他の変更の影響を受けない ○ スコープを絞って開発できることがマイクロサービスのうまみ ○ スコープ外に原因があると調査が難しくなる ● 依存するサービスを意識しなくてよい ○ 環境構築のハードルや運⽤コストが問題に ○ 間接的に依存しているサービスがあるとより⼤変 25

Slide 26

Slide 26 text

© 2024 Wantedly, Inc. マイクロサービスをどこで開発‧デバッグするか ● ローカル環境に構築 ○ すぐにフィードバックが得られる ○ 環境構築が⼤変でPCのリソースが⾜りなくなることも ● 既存のリモート環境にデプロイ ○ 環境構築の必要がなく⽐較的早く試せる ○ 他の開発者の作業と衝突することがある ● 開発者ごとにリモート環境を構築 ○ 他⼈の影響を受けることはない ○ ⾦銭的コストが増える 26

Slide 27

Slide 27 text

Slide 28

Slide 28 text

Slide 29

Slide 29 text

© 2024 Wantedly, Inc. kubefork 変更する部分だけ差し替えて仮想的な⾃分専⽤のクラスタを作る ● 誰がアクセスしているかをサービス間で伝搬 ● Istio のルーティング制御機能で開発中の pod に向ける ● Telepresence によって⼿元の PC を pod として扱う ● ⾜りない機能は Custom Controller で実装 ○ フルマネージドサービスにはまだ難しい領域 ○ kubebuilder のようなエコシステムに乗れるのもメリット 29

Slide 30

Slide 30 text

© 2024 Wantedly, Inc. 2024年に Kubernetes を使う優位性マイクロサービス開発の基盤に Kubernetes の拡張性が必要 ● 豊富な 3rd party 製 cluster addon が存在している ○ 欲しいと思った機能は既に誰かが試していることが多い ○ 既存の資産を流⽤できる ● cluster addon を実装するためのエコシステムも充実 ○ Reconciliation Loop の仕組みに乗れる ○ Kubebuilder を使えば簡単に作れる 30

Slide 31

Slide 31 text

Slide 32

Slide 32 text

Slide 33

Slide 33 text

Slide 34

Slide 34 text

Slide 35

Slide 35 text

Slide 36

Slide 36 text

Slide 37

Slide 37 text

Slide 38

Slide 38 text

© 2024 Wantedly, Inc. 学習コストを減らすエンジニア⽤の内製ツール “kube” ● 簡単に k8s を利⽤するための便利機能を提供 ○ 開発ステップ毎に必要なコマンドを⼀つに集約 ○ テンプレート化で優先して意識すべき項⽬に集中 ● 学習コストを増やさないための設計 ○ k8s 以前の基盤で使われていたツールのコマンド体系を採⽤ ○ 標準ツール “kubectl” の機能はそのまま提供しトラブルシューティングを容易に 38

Slide 39

Slide 39 text

© 2024 Wantedly, Inc. cluster addon のアップデート作業を⼀部⾃動化 k8s を使うなら cluster addon 管理からは逃げられない ● cluster addon なしで運⽤するのは事実上不可能 ○ ベンダー依存の処理は addon として実装されている ○ 例: Ingress Controller, CSI Driver, ... ● cluster upgrade 前に互換性のあるバージョンに ○ addon は内部で Kubernetes API を利⽤している ○ 新しい Kubernetes のバージョンで利⽤している API が変更‧廃⽌されることも 39

Slide 40

Slide 40 text

© 2024 Wantedly, Inc. cluster addon のアップデート作業を⼀部⾃動化⾃動化できそうな箇所 ● 処理とマニフェストを⼀致させる必要がある ○ cluster addon = container image + k8s manifest ○ 例: RBAC の更新を忘れて API でエラーが発⽣ ● cluster addon の更新で削除されたリソースの掃除 ○ kubectl apply では削除はできない ○ --prune は廃⽌, 後継の ApplySet も課題あり 40

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

© 2024 Wantedly, Inc. 結論 ● マイクロサービス開発に Kubernetes の拡張性が必要 ○ サービス運⽤だけでなく開発にも使えるマイクロサービス基盤 ○ 導⼊当時に必要だった運⽤の機能は k8s でなくても代替可能に ● メンテナンスコストの⾼さを受け⼊れる意思決定 ○ 特に頻繁に来る⼤規模アップデート対応による負担が問題 ○ コストを受け⼊れられる仕組みを整備し組織的な体制も⽤意 ● 求める機能がクラウドに実装されれば移⾏を検討 ○ 既存の価値を維持しつつ新しい価値に注⼒したい Wantedly がフルマネージドサービスではなく Kubernetes を選択する理由 47

Slide 48

Slide 48 text

© 2024 Wantedly, Inc. マイクロサービス基盤の選定 ● 技術選定の結果はタイミングにより異なる ○ 登場してすぐは機能が少なく信頼性も低くなりがち ○ クラウドサービス成熟により機能は増え信頼性も上がる ● 今 Kubernetes を選択すべきユースケースは減少 ○ クラウドベンダーが想定していない使い⽅には Kubernetes が刺さる ○ マイクロサービス運⽤だけならフルマネージドサービスの機能で⼗分⾜りる ○ ⾼いメンテナンスコストを払ってまで k8s を選択する価値があるか熟慮すべき 48

Slide 49

Slide 49 text