令和元年USERGRAMレガシー脱却! オンプレからクラウドネイティブへ ~beBitインフラ奮闘記~
こんにちは、ビービットのインフラをやっている那珂です。初投稿が2019年最終日になってしまいました。テックブログを書く言ってたのにずっと書いてないので、来年からもっと書いていけるように2019年の最後に一本書いておきたいと思います。
2019年の課題
beBitはUSERGRAMというWebやAppの行動データからユーザの状況を捉えるサービスを提供していますが、今までオンプレで運用されていたため、急なスケールができないことが大きな課題で、プロダクト展開のボトルネックがシステムにありました。
この課題を解決するために、2019年の初めからクラウド移行とデータ処理部分の大規模リファクタリングがこの1年間のメインプロジェクトとなっていました。
結果として、2019年12月末ぎりぎりにすべてのクラウド移行を完了し、オンプレ脱却を達成し、もともとの課題「システムがボトルネック」を解消しました。
取り組んだこと
オンプレからクラウドへの移行。時系列順に簡単に紹介していきたいと思います。
2018年後半 コンテナ化
オンプレ時代はコンテナを利用していなかったのですが、ローカル開発環境を構築するのも大変だったので、アプリケーション部分はコンテナ化がクラウド移行プロジェクト前から始まっていました。
ミドルウェア部分のコンテナ化などは2019年のクラウド移行プロジェクト開始の段階ではじめました。
2019年1月 Kubernetes導入
なぜKubernetesにしたかはこの記事では深くは言及しませんが、今回はクラウド移行が基本はリフト＆シフト (といいつつデータ処理部分の大規模リファクタリングをしている‥) なため、基本構成を変更せずに移行できるものとして選択しました。選択した大きな理由はStatefulSetでした。フルマネージドサービスでカバーできないステートを持ったミドルウェアを管理するのに、KubernetesのStatefulSetが役立つと考えました。
また、導入当時は、Kubernetesを自分たちでマネージしようとしていましたが、有識者が不在だったため、最終的にはマネージドを使用することでコントロールプレーンの運用コストを削減することが出来ました。
2019年1月 ミドルウェア構築
既存のミドルウェアをKubernetes上での構築することに加えて、データ処理部分のリファクタによりミドルウェア自体の変更もあったために、新しいミドルウェア構築とパフォーマンス検証なども必要となりました。クラウド移行の範囲がかなり大きくなってしまったことは今回の反省点です。
2019年3月 VPC見直し
VPC設計に問題が発覚し、まだリリースしていない段階で見つけた問題は、早いうちに解決しておこうということで、当初の設計から大規模な変更を行いました。その結果、Kubernetesクラスタ自体の引っ越しの必要もになりました。その時点で準備稼働していたミドルウェアや移行してしまったデータなどステートフルなものも含めて移行することになりました。
今考えてみると、リリースしてからクラスタの引っ越しをする前に、事前にクラスタの引っ越しの練習ができてKubernetesの運用経験としてはよかったかなと思います。(が、VPCの設計で手戻りしないようにもともとやっておくべきだったというのが本質的なところではあります)
2019年6月 アプリケーション移行
アプリケーションのコンテナ化、ミドルウェア構築、試験運用が一通り完了し、本番アプリケーションをオンプレからクラウドへ移行しました。ここで、クラウドでの本番運用がスタートしました。
2019年2月~7月 データ移行
データ移行はかなり難航しました。オンプレ時代にデータベースに問題があり、なかなかメンテナンスが出来ない状況だったため、マイグレーションツールを使って簡単にデータ移行が出来ない状況となっていました (あとから考えると本当にそうだったのかもう少し検討する余地はあったかもしれない) 。
そのため、既存のデータの新しいデータベースへの移行とリアルタイムで流れてくるデータの反映を同時に行う必要があり、移行手順がかなり複雑化しました。
移行先のデータベースをまるごとコピーして、現行システムをそのデータに対して動かして問題なく稼働するかどうかのシステムテストを行ったりしました。
2019年7月 データストア切り替え
データ処理の向き先をオンプレデータベースから移行先のデータベースへ切り替え、アプリケーションの参照先も切り替えました。
この時点でクラウド移行が半分終了。
データの受け口と処理の部分はオンプレで、データストアから先はクラウド上となりました。
2019年8月 CD導入
6月にアプリケーションをKubernetes上で本番運用するようになってからは、クラウド移行中ではあるものの運用に関して改善が必要な課題が沸き起こってきました。導入時、CI/CDの知見がしっかりなかったため運用にマニュアルな部分が多く全くCloud Nativeになれていませんでした。2019年後半からKubernetes meetupなどに参加するようになり、自分たちが抱えてる問題をどう他の人達が解決しているのかをインプットして、そこから自分たちの現状の課題を解決できるものを導入してきました。
その中でも、Meetupで紹介されていた Argo CD は、Kubernetesに特化したCDツールで導入もとても簡単だったので、軽い試験運用後すぐに自分たちの要件を満たしていると判断し導入しました。
また、ArgoCDの導入後、社内で共有会をやって開発者に普及することができました。
2019年10月 データ処理部分のリファクタリングリリース (リプレース + マイグレーション)
データ処理部分のリファクタは、現行のシステムのスケーラビリティ問題を解決する非常に重要な部分でした。
同時に、クラウド移行の一部でもあり、
「オンプレ上の旧システム」→ 「Kubernetes上の新システム」
の移行となっていて、全てが異なるものの比較チェックが必要となりました。
クラウド移行に伴い、監視ツールもオンプレで使っていたZabbixからDataDogへの移行したり、Circle CIとArgo CDを利用したデプロイへの変更だったりと変更点は多々ありました。
2019年11月 開発環境構築自動化
オンプレ時代には、開発環境やステージング環境がほぼなく新規機能開発やリリースが困難でした。
クラウド移行中にも別のプロジェクトで新規機能開発が進んでいたので、テスト環境の構築要望も移行プロジェクト中に、対応することとなりました。
8月にArgoCDを導入後、Template EngineのKustomizeを利用することで簡単に環境を簡単に複製できるようになっていたので、開発環境を提供し、開発者が自分たちでDocker イメージの更新をして開発サイクルを回せるようにしました。
2019年12月 データ収集部分の移行
USERGRAMはWEBのトラッキングも行っていて、データ収集部分が最後の移行コンポーネントとなりました。
オンプレ側にトラフィックの一部をクラウドの移行先へ向け段階的に移行を行うことで、リスクを抑えて移行を遂行しました。
これですべてのコンポーネントの移行が完了し、Cloud Nativeの第一歩を踏み出せることができました。
解決できたこと
スケーラビリティ
スケールできる構成になり処理できるトラフィック量が格段に増えました。
開発スピード向上
テスト環境の整備とCI/CDの導入により、テスト環境本番環境への反映の自動化がチームへ浸透したことで、開発のサイクルが早くなりました。クラウド移行の副産物。
課題
- 監視体制がまだ未熟で利用ツールも分散している
- システム全体のボトルネック検証がしっかりできていない
- システム復旧演習ができていない
- Kubernetesの機能で使いこなせていない部分がある
など、まだまだ課題はたくさんあります。
最後に
2019年は「サービスをスケールするためのボトルネックがシステムにある」を解消できたので、2020年では、さらにCloud Nativeなシステムにして、自動化、可観測性を上げ、最小限の労力で継続的に開発を行っていける環境を目指したいと思っています。
そして、beBitではこれからもっとサービスを強くするエンジニアを募集しています。
興味がある方は、是非御覧ください。https://www.wantedly.com/companies/bebit/projects/contract