1 MackerelにおけるCloudNativeへの継続的な 取り組み 〜オンプレからCloudNativeまで〜 2019/11/28 CloudNative Days Kansai 2019 古川 雅大 (id:masayoshi)

2 自己紹介 - 古川 雅大(id:masayoshi/@yoyogidesaiz) - ネットワークが好き - 株式会社はてな(2016年〜) - システムプラットフォーム部 SRE (2016年〜) - Mackerelチーム リードSRE (2019年6月〜)

3 今日のお話 - Mackerelを例に、既存サービスのCloud Nativeへの移行についてお話 - サービス開始からの大まかな移行の流れを見ながら、 既存サービスをCloud Nativeに移したい人たちの参考や励みになれば

4 伝えたいこと - Cloud Nativeは組織(チーム)を「いい感じ」にすること - Cloud Nativeへの移行は、段階的に試行錯誤しながらやっていくとよい - チーム状況やツール、サービス状況に応じて変化していく必要がある - 一つ一つの改善の積み重ねでCloud Nativeになっていく - Mackerelもオンプレから始まり、現在Cloud Nativeへ自然と向かっている - 時間の関係で話さないこと - ツールや詳細、移行の具体的な説明 (発表資料などを参考)

5 クラウドネイティブ技術は、 パブリッククラウド プライベートクラウド ハイブリッドクラウドなどの近代的でダイナミックな環境において、 スケーラブルなアプリケーションを構築および実行するための能力を 組織にもたらします。 Cloud Native ? https://github.com/cncf/toc/blob/master/DEFINITION.md

6 - スケーラブルなアプリケーションを構築および実行するための能力を組織にもたらす - 組織(例えば開発チームなど)にもたらすところが重要 - ツールやサービスを導入して、組織にもたらすところまで - 特定のツールなどを指しているわけではない - CNDF2019の「飛び込もう、Cloud Nativeの世界」という発表がわかりやすい Cloud Native ????? *1 Kazuto Kusama “飛び込もう、Cloud Nativeの世界” https://speakerdeck.com/jacopen/fei-biip-mou-cloud-nativefalseshi-jie

7 Mackerel? - 2014年リリースの「サーバ監視サービス」 - サービス運用をサポートする監視サービス - リリース時はオンプレ環境、現在はAWSを中心に構築 - 現在はメインのシステムがEC2(VM), 一部のサブシステムはECS(Fargate)

8

9

10

11 Mackerelのインフラ構成の変遷

12 Mackerelのインフラ構成の変遷 On-premises Cloud First Cloud Native 2014 2017 2019 2015 2016 2018 2020 2021 ・Compute VM Xen Hypervisor ・Time Series Database ioMemory Graphite ・Relational Database PostgreSQL ・Compute VM EC2 ・Time Series Database Redis DynamoDB S3 ・Relational Database RDS(PostgreSQL) ・Compute Container ECS Kubernetes ・Time Series Database ElastiCache DynamoDB S3 ・Relational Database RDS(PostgreSQL)

13 On-Premises => Cloud First

14 クラウドを利用したダイナミックな環境への移行 On-premises Cloud First 2014 2017 2019 2015 2016 2018 ・Compute VM Xen Hypervisor ・Time Series Database ioMemory Graphite ・Relational Database PostgreSQL ・Compute VM EC2 ・Time Series Database Redis DynamoDB S3 ・Relational Database RDS(PostgreSQL) 物理サーバ+高速なストレージ+OSS ⇓ マネージドサービスを組み合わせた スケーラブルな時系列DBを実装 物理サーバ+高速なストレージ+OSS ⇓ マネージドサービスにお任せ *1 移行当時はTimestreamのようなTSDBマネージドサービスがなかった *1 チーム状況 とにかくデータストアの運用が大変 スケールできるようにしたい

15 - On-premisesのときのTSDB(Graphite) - Mackerelを支える時系列データベース技術 On-premises Cloud First の歴史(公開資料) https://blog.yuuk.io/entry/high-performance-graphite - Cloud First(AWS移行後)のTSDB(diamond) - 時系列データベースという概念をクラウドの技で再構築する - AWSで実現した Mackerel 時系列データ1分粒度長期保存の裏側 - On-premisesからAWS移行のお話 - Mackerel インフラ基盤 AWS 移行の舞台裏 - Mackerel をオンプレミスから AWS に移してからの1年半を振り返る https://speakerdeck.com/kizkoh/mackerel-inhuraji-pan-aws-yi-xing-falsewu-tai-li https://blog.astj.space/entry/2018/02/06/175902 https://blog.yuuk.io/entry/the-rebuild-of-tsdb-on-cloud https://blog.astj.space/entry/2019/03/07/110234

16 - マネージドサービスになり運用が楽になった - キャパシティプランニングやバックアップ、AZ冗長化など - VM 調達のリードタイムや難易度自体も EC2 で楽になった - 近代的でダイナミックな環境を手に入れた - アプリケーションがシームレスにデプロイ、実行できるようになった わけではない - オンプレ時代とEC2時代ではCI/CDが大きくは変わらず - 例えば、GitOpsなどはEC2へのデプロイなどを作り込まないと実現が難しい Cloud Firstになって

17 Cloud First => Cloud Native

18 Cloud FirstからCloud Nativeへ Cloud First Cloud Native 2017 2019 2018 2020 ・Compute VM EC2 ・Time Series Database Redis DynamoDB S3 ・Relational Database RDS(PostgreSQL) ・Compute Container ECS Kubernetes ・Time Series Database ElastiCache DynamoDB S3 ・Relational Database RDS(PostgreSQL) チーム状況 CI/CDがあるもののリリース手順が複雑 インフラ側とアプリケーション側の境界が曖昧 サービスの機能も増えてきた コンテナ化でCI/CDを改善したい コンテナ実行環境も検討が必要

19 - 移行は段階的に試行錯誤しながら実施 - Cloud Native Trail Mapを元に、既存サービスの Containerization、OrchestrationをCI/CDを元に段階的移行 - ツール、サービスの選択 - 直近1年間のMackerelのOrchestrationのツール、サービスの選択の事例 - k8sの選択と撤退(2018) - ECS、EKSの選択(2019) - チームの変遷 - Cloud Nativeへの移行に適したチーム変遷 Cloud Nativeへの移行

20 Cloud Native Trail Map (移行) https://github.com/cncf/trailmap A. CI/CD (既存システム用CI/CD) B. Containerization (ビルド環境などのコンテナ化 ) C. CI/CD (ビルドステージをコンテナベースにする ) D. Orchestration & Application Definition (ツールの選定) E. CI/CD (リリースをOrchestrationにあったCI/CDにする) F. Observability & Analysis (最低限のログ保存や監視など ) G. B ~ F を検証環境で、本番切り替えに耐えられるまで回す H. 本番環境の切り替えへ 既存サービスの移行の場合 - 既存のCI/CDを維持しながら移行 - 段階的に移行するために、 CI/CDも段階毎に追加 - Containerization, CI/CD, Orchestrationは試行錯誤段階で何 回か回すとよい

21 MackerelのOrchestrationの選択(2018) - 課題 - デプロイ手順を容易にしたい、GitOpsなどCI/CD周りの改善をしたい - 「サーバー監視サービス」として、k8sに対応したい - k8s運用して運用知見がほしい(ちょっと特殊) - チームで制御可能 - チーム規模を考えると、k8sを自前でやるのは難しいかもしれない? - チーム規模 = エンジニアが10名前後 (SRE 2〜3名) - 現在はAWS中心なので、GCPなどマルチクラウドを同時にはやりたくない AWSでEC2上にKubernetesを構築、運用にチャレンジ *1 当時はEKSが東京リージョンがなかった *1

22 Mackerelのk8s導入 導入したが...撤退！

23 - 導入方法と撤退の詳細は以下参照 - Blog - 発表資料 - 記事 Mackerelのk8s導入と撤退(公開資料) https://developer.hatenastaff.com/entry/leading-kubernetes-at-hatena https://speakerdeck.com/hayajo/kubernetes-meetup-tokyo-number-22 https://www.atmarkit.co.jp/ait/articles/1911/08/news009.html

24 Mackerelのk8s撤退 - k8sクラスターのMasterの運用まで含めるとチーム規模にあっていなかった - Masterを含めたkubernetesクラスターのバージョンアップの難しさ - チームをいい感じにするところまでいけなかった(CI/CDやk8sの有効活用など) - 辛いなら一回やめてみてもいいのでは - k8s周りのツールの変化、チーム状況の変化 - kubesprayの変更やEKSの東京リージョン対応など - チームメンバーの人数が減った (SREが3名 => 1名) - k8sの運用知見は溜まった - アプリケーションのビルドはDockerに統一された - 段階的移行をしたのでContainerizationのCI/CDは成果として残っている

25 MackerelのOrchestrationの選択(2019) - チーム状況の変化 - 人数が増えた (SREが1名 => 3名、アプリケーションエンジニアも2名追加) - 課題の再整理 - GitOpsなどCI改善によりサービス開発をスケールさせたい(Cloud Native的) - 運用負荷が低いコンテナ実行環境が欲しい (ECS、k8sでもなんでもよい) - 「サーバー監視サービス」として、k8sに対応したい(サービス開発) - k8sのMasterやNodeの運用知見が欲しい(k8sである必要がある) 別々に検討することで、それぞれ段階的に移行

26 MackerelのOrchestrationの選択(2019) - ステージング環境、本番環境のOrchestrationはECS(Fargate) - 既に一部本番環境がECS(Fargate)で稼働中 - Containerizationができている箇所は比較的スムーズに移行 - ECSのデプロイはJenkinsからCloudFormationでタスク定義を更新してデプロイ - EC2がなくなり全てECSになったら、コンテナ前提のCI/CDに変更 - 運用ツールなどのOrchestrationはEKS(k8s再導入への布石) - EKSでMasterの運用を楽にしつつ、Nodeのみの運用知見をまず貯める - EKSはCI/CDの前に、eksctlによるEKSクラスタアップデートへの対応を固める - ノードグループ、EKSクラスタのBlue/Green環境を構築 - 運用ツールの一部はGKEも？ - ネットワークレイテンシーなどが気にならなくなるので選択の幅は広がる

27 チーム構成の変遷(時間があれば)

28 チーム構成の変遷 On-premises Cloud First Cloud Native 2014 2017 2019 2015 2016 2018 2020 2021 infraチーム Mackerelチーム SREs AppEngineer infraチーム Mackerelチーム SREs AppEngineer SREs ?

29 Mackerelのチーム構成 - On-Premisesのころは、横串のinfraチームとMackerelチームでは役割が違った - Mackerelチームは物理サーバやネットワークなどinfraを触りにくかった - Cloud First, Cloud Native移行時期は、AppEnginerとSREsの連携が必要 - スケーラブルなアプリケーションを構築および実行するには、Infra, App両方の知識 が必要 - 開発チーム内にSREsがいることで、コミュニケーションパスを少なくし、より移行、変 化しやすいチームに

30 まとめ

31 まとめ - Cloud Nativeでは組織(チーム)が「いい感じ」になっているかどうかが重要 - そのためには - 常に変化するチームの状況に合わせたツールを選択する - サービスやツールの利用状況や変化に応じたチーム構成を選択する - そのためには - 小さく段階的に、撤退可能な状態で移行する - 検証、挑戦してダメだったら戻す判断を容易にし、試行錯誤しやすくする - これらのサイクルをできるだけ回してチームの経験値を上げていきたい - それにより、変化に強いチームが出来上がり、変更速度を上げていける - つまり、チームが「いい感じ」になる

32 Cloud Nativeでいいチームを作っていきましょう