MackerelにおけるCloud Nativeへの取り組みについてお話します
1MackerelにおけるCloudNativeへの継続的な取り組み〜オンプレからCloudNativeまで〜2019/11/28 CloudNative Days Kansai 2019古川 雅大 (id:masayoshi)
View Slide
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
7Mackerel?- 2014年リリースの「サーバ監視サービス」- サービス運用をサポートする監視サービス- リリース時はオンプレ環境、現在はAWSを中心に構築- 現在はメインのシステムがEC2(VM), 一部のサブシステムはECS(Fargate)
8
9
10
11Mackerelのインフラ構成の変遷
12Mackerelのインフラ構成の変遷On-premises Cloud First Cloud Native2014 2017 20192015 2016 2018 2020 2021・ComputeVMXen Hypervisor・Time Series DatabaseioMemoryGraphite・Relational DatabasePostgreSQL・ComputeVMEC2・Time Series DatabaseRedisDynamoDBS3・Relational DatabaseRDS(PostgreSQL)・ComputeContainerECSKubernetes・Time Series DatabaseElastiCacheDynamoDBS3・Relational DatabaseRDS(PostgreSQL)
13On-Premises => Cloud First
14クラウドを利用したダイナミックな環境への移行On-premises Cloud First2014 2017 20192015 2016 2018・ComputeVMXen Hypervisor・Time Series DatabaseioMemoryGraphite・Relational DatabasePostgreSQL・ComputeVMEC2・Time Series DatabaseRedisDynamoDBS3・Relational DatabaseRDS(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-lihttps://blog.astj.space/entry/2018/02/06/175902https://blog.yuuk.io/entry/the-rebuild-of-tsdb-on-cloudhttps://blog.astj.space/entry/2019/03/07/110234
16- マネージドサービスになり運用が楽になった- キャパシティプランニングやバックアップ、AZ冗長化など- VM 調達のリードタイムや難易度自体も EC2 で楽になった- 近代的でダイナミックな環境を手に入れた- アプリケーションがシームレスにデプロイ、実行できるようになったわけではない- オンプレ時代とEC2時代ではCI/CDが大きくは変わらず- 例えば、GitOpsなどはEC2へのデプロイなどを作り込まないと実現が難しいCloud Firstになって
17Cloud First => Cloud Native
18Cloud FirstからCloud NativeへCloud First Cloud Native2017 20192018 2020・ComputeVMEC2・Time Series DatabaseRedisDynamoDBS3・Relational DatabaseRDS(PostgreSQL)・ComputeContainerECSKubernetes・Time Series DatabaseElastiCacheDynamoDBS3・Relational DatabaseRDS(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への移行
20Cloud Native Trail Map (移行)https://github.com/cncf/trailmapA. 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は試行錯誤段階で何回か回すとよい
21MackerelのOrchestrationの選択(2018)- 課題- デプロイ手順を容易にしたい、GitOpsなどCI/CD周りの改善をしたい- 「サーバー監視サービス」として、k8sに対応したい- k8s運用して運用知見がほしい(ちょっと特殊)- チームで制御可能- チーム規模を考えると、k8sを自前でやるのは難しいかもしれない?- チーム規模 = エンジニアが10名前後 (SRE 2〜3名)- 現在はAWS中心なので、GCPなどマルチクラウドを同時にはやりたくないAWSでEC2上にKubernetesを構築、運用にチャレンジ*1 当時はEKSが東京リージョンがなかった*1
22Mackerelのk8s導入導入したが...撤退！
23- 導入方法と撤退の詳細は以下参照- Blog- 発表資料- 記事Mackerelのk8s導入と撤退(公開資料)https://developer.hatenastaff.com/entry/leading-kubernetes-at-hatenahttps://speakerdeck.com/hayajo/kubernetes-meetup-tokyo-number-22https://www.atmarkit.co.jp/ait/articles/1911/08/news009.html
24Mackerelのk8s撤退- k8sクラスターのMasterの運用まで含めるとチーム規模にあっていなかった- Masterを含めたkubernetesクラスターのバージョンアップの難しさ- チームをいい感じにするところまでいけなかった(CI/CDやk8sの有効活用など)- 辛いなら一回やめてみてもいいのでは- k8s周りのツールの変化、チーム状況の変化- kubesprayの変更やEKSの東京リージョン対応など- チームメンバーの人数が減った (SREが3名 => 1名)- k8sの運用知見は溜まった- アプリケーションのビルドはDockerに統一された- 段階的移行をしたのでContainerizationのCI/CDは成果として残っている
25MackerelのOrchestrationの選択(2019)- チーム状況の変化- 人数が増えた (SREが1名 => 3名、アプリケーションエンジニアも2名追加)- 課題の再整理- GitOpsなどCI改善によりサービス開発をスケールさせたい(Cloud Native的)- 運用負荷が低いコンテナ実行環境が欲しい (ECS、k8sでもなんでもよい)- 「サーバー監視サービス」として、k8sに対応したい(サービス開発)- k8sのMasterやNodeの運用知見が欲しい(k8sである必要がある)別々に検討することで、それぞれ段階的に移行
26Mackerelの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 Native2014 2017 20192015 2016 2018 2020 2021infraチームMackerelチームSREsAppEngineerinfraチームMackerelチームSREsAppEngineer SREs?
29Mackerelのチーム構成- On-Premisesのころは、横串のinfraチームとMackerelチームでは役割が違った- Mackerelチームは物理サーバやネットワークなどinfraを触りにくかった- Cloud First, Cloud Native移行時期は、AppEnginerとSREsの連携が必要- スケーラブルなアプリケーションを構築および実行するには、Infra, App両方の知識が必要- 開発チーム内にSREsがいることで、コミュニケーションパスを少なくし、より移行、変化しやすいチームに
30まとめ
31まとめ- Cloud Nativeでは組織(チーム)が「いい感じ」になっているかどうかが重要- そのためには- 常に変化するチームの状況に合わせたツールを選択する- サービスやツールの利用状況や変化に応じたチーム構成を選択する- そのためには- 小さく段階的に、撤退可能な状態で移行する- 検証、挑戦してダメだったら戻す判断を容易にし、試行錯誤しやすくする- これらのサイクルをできるだけ回してチームの経験値を上げていきたい- それにより、変化に強いチームが出来上がり、変更速度を上げていける- つまり、チームが「いい感じ」になる
32Cloud Nativeでいいチームを作っていきましょう
masayoshi
kentosuzuki
sbtechnight
doradora09
iwashi86
konboi
asazutaiga
sue445
oracle4engineer
takakuni
smashingmag
afnizarnur
hannesfritz
zakiyama
jonyablonski
mza
addyosmani
ufuk
pedronauck
thoeni
bluesmoon
moore