MackerelにおけるKubernetes利用の取組みとこれから / Kubernetes Meetup Tokyo #22

Transcript

1. Mackerelにおける
 Kubernetes利用の取組みとこれから
 Kubernetes Meetup Tokyo #22

2. • 今井隼人(id:hayajo_77/@hayajo) • 株式会社はてな(2017/11〜) • Mackerelチーム • SRE 自己紹介
 https://developer.hatenastaff.com/entry/2019/06/10/120000
3. Mackerel?

7. 今日のお話

8. • MackerelにおけるKubernetes導入の取り組み ◦ Kubernetes導入の目的 ◦ Kubernetesクラスタ構築の道のり ◦ Kubernetesの運用と課題 ◦ 今後の取り組み 今日のお話

9. Mackerelにおける
 Kubernetes導入の目的

10. コンテナ運用のキャッチアップ
 • MackerelはVM(EC2)ベースでシステム構築されている • コンテナの監視手段は提供しているがコンテナによるシステム運用におけ る監視ついてのプラクティスを提供できていない • これを提供できるよう積極的にキャッチアップしてしていきたい
11. ドッグフーディング
 • Mackerelそのものをコンテナで運用してそれを監視する • Mackerelコンテナエージェントの動作確認 ◦ ECS(EC2/Fargate)、Kubernetesに対応
12. インフラ管理コストの削減
 • 複雑なサーバープロビジョニング・管理からの脱却 ◦ 社内サーバ管理システムとの連携、複数のリポジトリを参照 ◦ サービスを横断した共通の仕組みのため複雑 ◦ アプリケーションのデプロイまで含めると手順が多く煩雑 • コンテナイメージによるアプリケーションの構成管理でこれを解決したい
13. Kubernetesを選定した理由

14. デファクトスタンダード
 • コンテナオーケストレーションのデファクトスタンダード • サービスとしてKubernetesクラスタ監視のキャッチアップが必要 • 社内でのKubernetesの運用事例はなかった。ECSの運用事例がほとん ど。
15. 運用の効率化
 
 • セルフヒーリング • 効率的なリソース利用 • オートスケーリング • Services, Secrets, ConfigMap, Jobs, PV, etc.
16. 自前クラスタ or マネージドサービス

17. EC2上に自前Kubernetesクラスタを構築
 • コンテナによるシステム運用への移行を検討した当初はEKSが日本のリー ジョンに提供されていなかった • Mackerelでは多くのAWSリソースを利用するため、AWS以外ではネット ワークのオーバヘッドが大きく運用は難しいと判断
18. Kubernetesクラスタの設計

19. Mackerelのシステム構成

20. Kubernetesの導入範囲

21. Crawlerのアーキテクチャ /w Kubernetes

22. Kubernetesクラスタ構成

23. Kubernetesクラスタの導入

24. 詳しくはこちら
 https://developer.hatenastaff.com/entry/leading-kubernetes-at-hatena 

25. 1. CONTAINERIZATION
 • アプリケーションのDockerイメー ジを準備 ◦ マルチステージビルド ◦ Buildkitの `--mount=type=cache` # syntax=docker/dockerfile:experimental # Stage: prepare go test and build FROM golang:1.12 AS prepare RUN go get github.com/golang/dep/cmd/dep && \ go get golang.org/x/lint/golint RUN mkdir -p /app ADD Gopkg.toml Gopkg.lock /app WORKDIR /app RUN --mount=type=cache,target=/go/pkg/dep \ dep ensure --vendor-only ADD . /app # Stage: build go application FROM prepare AS build RUN go build -ldflags=$(BUILD_LDFLAGS) -o ./app # Stage: build container image FROM debian:stretch-slim RUN apt-get update -yq && \ apt-get install -yq ca-certificates && \ rm -rfv /var/lib/apt RUN mkdir -p /app COPY --from=build /app/app /
26. 2. CI/CD
 • 稼働中のサービスのためのCI/CDパイプライン(Jenkins + Capistrano)に 影響を与えずに並行してコンテナ運用を行う必要があった • Skaffold + kustomize でこれを実現 • 詳しくはブログを参照
27. 3. ORCHESTRATION
 • マネージドサービスを利用できない理由は前述のとおり • クラスタ構築に kubespray +Terraform を採用 ◦ Ansibleを利用するため構築ステップが追跡しやすい ◦ インスタンスはTerraformで作成し、テンプレートでAnsibleのインベント リを生成
28. 本番の一部で利用開始！

29. しかしKubernetesクラスタの運用には課題 が...

30. 高い学習コスト
 • そもそもKubernetesは複雑 ◦ 多くのオブジェクトやクラスタを構成するコンポーネント • チーム全体で運用に取り組むための学習プランを用意できなかった ◦ ハンズオン、書籍、ドキュメント、口伝、etc ◦ 個人の学習意欲に依存していた • そのためクラスタ構築に関わったメンバー以外はほぼさわれない状況が続 いていた
31. 膨大なエコシステム
 https://github.com/cncf/landscape#current-version 

32. クラスタアップデートへの対応
 • Kubernetesのマイナーリリースはおよそ3ヶ月ごとに実施され、3リリースブ ランチをサポート ◦ 機能追加や変更が多く、アップデートを先送りにするほど検証に時間 がかかる ◦ リリースに追従しつづけるには体制づくりが大事 • アップデートに失敗すると復旧が難しい ◦ クラスタのBlue/Green的な運用をしたくなる
33. チームとしても徐々に運用が困難に...

34. 運用リソース不足
 • クラスタの運用開始時期とチームメンバーの退職・異動が重なり、運用リ ソースが圧倒的に不足 • また優先度の高い機能のリリースに注力する時期だったため、クラスタが 放置気味になっていた
35. クラスタアップデートに失敗
 • kubesprayがkubeadm対応の過渡期だったため、Masterのアップデートう まくいかずクラスタのアップデートが困難になっていた ◦ このため脆弱性への対応が遅れていた • ツールの特性から特定のMaster/Nodeのインスタンスを作り直すことが難 しくメンテナンスが手間だった • クラスタの再構築も検討したが運用リソースが足らず中止
36. Kubernetesクラスタの撤退を決断

37. 撤退手順
 • 本番環境 ◦ 既存システムと並行運用だったためロードバランサからNodePortを外 すだけで撤退完了 • ステージング環境 ◦ すべてのサブシステムをKubernetesクラスタへ移行済だった ◦ そのため従来のVMによる実行環境を再構築してから撤退
38. ふりだし(VM運用)にもどる

39. しかしMackerelにとってコンテナによるシステ ム運用の知見を得ることは必須

40. これからの取り組み

41. コンテナによるシステム運用の実現を優先する
 • まずはコンテナによるシステム運用を実現することを優先させる • 社内で構築・運用実績のあるECSへ移行する ◦ 比較的短期間で移行できる(はず) ◦ すでに一部システムはECS(Fargate)化して本番運用中
42. 最終的にEKSへ移行
 • サービスにとってKubernetesクラスタの運用知見を得ることも必須 • ECSを腰掛けとして、最終的にEKSへソフトランディングさせる ◦ マネージドサービスを利用することでKubernetesクラスタの運用負荷 を軽減する ◦ EKSへの移行で失敗してもコンテナによるシステム運用は担保
43. サービス系以外のコンテナをKubernetesで運用
 • 運用系ツールなどのサービスに直接関わらないコンテナを載せる Kubernetesクラスタを構築・運用 • EKSへ移行するまでのKubernetesクラスタ運用知見の劣化を防ぐ
44. まとめ

45. まとめ
 • 構築できる ≠ 運用できる
 • クラスタ運用を見据えた体制を整えることが大事
 ◦ 学習プランの整備、ドキュメントの充実
 ◦ 軌道に乗るまでは専任エンジニアが2人以上ほしい（肌感覚）
 • スモールスタート、並行運用、撤退可能な設計を心がける
 ◦ とくに既存システムからの移行において

46. 個人的なコンテナ運用所感
 fargate運用物語 / Fargate-Story | https://speakerdeck.com/soudai/fargate-story?slide=85 

47. 【宣伝】コンテナを学ぶのにオススメの記事
 https://employment.en-japan.com/engineerhub/entry/2019/02/05/103000 

48. curl -sIL mackerel.io | grep career