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

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

Mackerel? 

Slide 4

Slide 4 text

No content

Slide 5

Slide 5 text

No content

Slide 6

Slide 6 text

No content

Slide 7

Slide 7 text

今日のお話 

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

Mackerelにおける  Kubernetes導入の目的 

Slide 10

Slide 10 text

コンテナ運用のキャッチアップ  ● MackerelはVM(EC2)ベースでシステム構築されている ● コンテナの監視手段は提供しているがコンテナによるシステム運用における監視ついてのプラクティスを提供できていない ● これを提供できるよう積極的にキャッチアップしてしていきたい

Slide 11

Slide 11 text

ドッグフーディング  ● Mackerelそのものをコンテナで運用してそれを監視する ● Mackerelコンテナエージェントの動作確認 ○ ECS(EC2/Fargate)、Kubernetesに対応

Slide 12

Slide 12 text

インフラ管理コストの削減  ● 複雑なサーバープロビジョニング・管理からの脱却 ○ 社内サーバ管理システムとの連携、複数のリポジトリを参照 ○ サービスを横断した共通の仕組みのため複雑 ○ アプリケーションのデプロイまで含めると手順が多く煩雑 ● コンテナイメージによるアプリケーションの構成管理でこれを解決したい

Slide 13

Slide 13 text

Kubernetesを選定した理由 

Slide 14

Slide 14 text

デファクトスタンダード  ● コンテナオーケストレーションのデファクトスタンダード ● サービスとしてKubernetesクラスタ監視のキャッチアップが必要 ● 社内でのKubernetesの運用事例はなかった。ECSの運用事例がほとんど。

Slide 15

Slide 15 text

運用の効率化    ● セルフヒーリング ● 効率的なリソース利用 ● オートスケーリング ● Services, Secrets, ConfigMap, Jobs, PV, etc.

Slide 16

Slide 16 text

自前クラスタ or マネージドサービス 

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

Kubernetesクラスタの設計 

Slide 19

Slide 19 text

Mackerelのシステム構成 

Slide 20

Slide 20 text

Kubernetesの導入範囲 

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

Kubernetesクラスタ構成 

Slide 23

Slide 23 text

Kubernetesクラスタの導入 

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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 /

Slide 26

Slide 26 text

2. CI/CD  ● 稼働中のサービスのためのCI/CDパイプライン(Jenkins + Capistrano)に影響を与えずに並行してコンテナ運用を行う必要があった ● Skaffold + kustomize でこれを実現 ● 詳しくはブログを参照

Slide 27

Slide 27 text

3. ORCHESTRATION  ● マネージドサービスを利用できない理由は前述のとおり ● クラスタ構築に kubespray +Terraform を採用 ○ Ansibleを利用するため構築ステップが追跡しやすい ○ インスタンスはTerraformで作成し、テンプレートでAnsibleのインベントリを生成

Slide 28

Slide 28 text

本番の一部で利用開始！ 

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

高い学習コスト  ● そもそもKubernetesは複雑 ○ 多くのオブジェクトやクラスタを構成するコンポーネント ● チーム全体で運用に取り組むための学習プランを用意できなかった ○ ハンズオン、書籍、ドキュメント、口伝、etc ○ 個人の学習意欲に依存していた ● そのためクラスタ構築に関わったメンバー以外はほぼさわれない状況が続いていた

Slide 31

Slide 31 text

膨大なエコシステム  https://github.com/cncf/landscape#current-version  

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

チームとしても徐々に運用が困難に... 

Slide 34

Slide 34 text

運用リソース不足  ● クラスタの運用開始時期とチームメンバーの退職・異動が重なり、運用リソースが圧倒的に不足 ● また優先度の高い機能のリリースに注力する時期だったため、クラスタが放置気味になっていた

Slide 35

Slide 35 text

クラスタアップデートに失敗  ● kubesprayがkubeadm対応の過渡期だったため、Masterのアップデートうまくいかずクラスタのアップデートが困難になっていた ○ このため脆弱性への対応が遅れていた ● ツールの特性から特定のMaster/Nodeのインスタンスを作り直すことが難しくメンテナンスが手間だった ● クラスタの再構築も検討したが運用リソースが足らず中止

Slide 36

Slide 36 text

Kubernetesクラスタの撤退を決断 

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

ふりだし(VM運用)にもどる 

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

これからの取り組み 

Slide 41

Slide 41 text

コンテナによるシステム運用の実現を優先する  ● まずはコンテナによるシステム運用を実現することを優先させる ● 社内で構築・運用実績のあるECSへ移行する ○ 比較的短期間で移行できる(はず) ○ すでに一部システムはECS(Fargate)化して本番運用中

Slide 42

Slide 42 text

最終的にEKSへ移行  ● サービスにとってKubernetesクラスタの運用知見を得ることも必須 ● ECSを腰掛けとして、最終的にEKSへソフトランディングさせる ○ マネージドサービスを利用することでKubernetesクラスタの運用負荷を軽減する ○ EKSへの移行で失敗してもコンテナによるシステム運用は担保

Slide 43

Slide 43 text

サービス系以外のコンテナをKubernetesで運用  ● 運用系ツールなどのサービスに直接関わらないコンテナを載せる Kubernetesクラスタを構築・運用 ● EKSへ移行するまでのKubernetesクラスタ運用知見の劣化を防ぐ

Slide 44

Slide 44 text

まとめ 

Slide 45

Slide 45 text

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

Slide 46

Slide 46 text

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

Slide 47

Slide 47 text

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

Slide 48

Slide 48 text

curl -sIL mackerel.io | grep career 