Tweet
Tweet

Slide 1

Slide 1 text

Quipper のマイクロサービス化への道のり @yuya-takeyama

Slide 2

Slide 2 text

➔ 技術的にエッジな話は少なめかも... ➔ 本番運用にまつわる泥臭い話多め 今日話すこと

Slide 3

Slide 3 text

01 02 03 04 05 Agenda | 自己紹介 Quipper の紹介 Kubernetes への移行 Kubernetes の運用 Microservices 化への道のり

Slide 4

Slide 4 text

01 自己紹介

Slide 5

Slide 5 text

@yuya-takeyama ➔ 2015年9月~: Web Developer at Quipper ◆ Rails/Backone.js/React.js/React Native などなど ➔ 2018年4月~: SRE at Quipper ◆ Kubernetes への移行や Kubernetes の運用およびその効率化 ◆ Kubernetes 環境への移行に向けた開発者のサポートもミッション ◆ インフラ・SRE としてはまだまだ修行中

Slide 6

Slide 6 text

@yuya-takeyama ➔ 好きな言語は Ruby, Go, TypeScript ◆ Elixir を勉強中, Rust は挫折気味

Slide 7

Slide 7 text

02 Quipper の紹介

Slide 8

Slide 8 text

Quipper のプロダクト ➔ Quipper ◆ フィリピン、インドネシア、メキシコ、日本で展開する教育サービス ◆ 先生は宿題を出せて、生徒が問題を解くとその進捗が管理できる ➔ スタディサプリ ◆ 基本的に機能は Quipper と同じだが、日本ではスタディサプリというブラ ンドでやっている ◆ かつての受験サプリ。2016 年にリブランディング ◆ 日本では「神授業」の CM でおなじみ ◆ 漫画「ドラゴン桜2」にも登場

Slide 9

Slide 9 text

Quipper とスタディサプリ ➔ ソースコード的にはほぼ同一 ◆ 環境変数等のフラグでスタイルや機能の出しわけが行われている ◆ AWS のアカウント自体別で、別々のリージョンにデプロイ

Slide 10

Slide 10 text

Quipper SRE チームの紹介 ➔ メンバー ◆ 東京 3 名 (うち 1 名は Web Developer からのコンバート (私です)) ◆ マニラ 1 名 (Web Developer からのコンバート) ◆ ロンドン 1 名 @masatomo (CTO/Engineering Manager) ➔ 役割 ◆ Quipper のインフラに関わることは基本的に全て ◆ インフラ・クラウド周りのコスト管理、セキュリティ等

Slide 11

Slide 11 text

Quipper SRE チームの紹介 ➔ ツール ◆ 基本的にあらゆるリソースが GitHub 上でコード化されている ◆ Pull Request でのレビュー、マージによるデプロイがかなり徹底されてい る ◆ Ansible/Ansible Tower/Terraform/CircleCI/Codenize.tools

Slide 12

Slide 12 text

03 Kubernetes への移行

Slide 13

Slide 13 text

Quipper における Kubernetes 移行の位置づけ ➔ CTO の @masatomo がトップダウンで始めたプロジェクト ◆ 開発者への共有を GitHub Issues やオフライン・オフラインのセッションを 行いフィードバックを集めながら ◆ 現在はプラットフォームとしては CTO を含む SRE が中心となって進めて いる ➔ とりあえず既存のアプリケーションを Deis から Kubernetes にそのまま移行 ◆ Deis: OSS の Heroku クローン的なやつ

Slide 14

Slide 14 text

Quipper における Kubernetes 移行の位置づけ ➔ Microservices 基盤としての移行ではあるが、Microservices 化はこれから ➔ Kubernetes への移行が完了してからが本番！ ◆ Microservices 化 ◆ それに伴う様々な権限の開発者への移譲 ◆ リソースや運用の最適化 ◆ 様々な技術的チャレンジ

Slide 15

Slide 15 text

Quipper とスタディサプリのインフラの変遷 ➔ Quipper ◆ 2012(?)年~: Heroku ◆ 2018年2月~: Deis Workflow (Deis v2 にあたる) ◆ 2018年8月~: Kubernetes (本番も含めて移行済み、絶賛運用中) ➔ スタディサプリ ◆ 2016年2月~: Deis v1 ◆ 2018年11月(?)~: Kubernetes (ステージングを移行中、本番も今月中)

Slide 16

Slide 16 text

Deis から Kubernetes へ移行する/した理由 ➔ Deis が既にメンテ終了！！！ (2018年3月) ◆ Quipper の Heroku -> Deis Workflow の移行計画は 2017 年 3 月から進 んでいた ◆ 同じく 2017 年時点で Microservices 基盤としての Kubernetes の検証も CTO による R&D プロジェクトとして平行して進んでいた ◆ 結果的に Deis Workflow EOL 直前というタイミングでの Deis Workflow 環 境のリリースになってしまった... ◆ Deis v1 (非 Kubernetes) からいきなり移行するのに比べれば、段階的移行 としての意味は十分あったと言える

Slide 17

Slide 17 text

Deis から Kubernetes へ移行する/した理由 ➔ Deis Workflow を使い続けるメリット自体薄いという判断 ◆ Hephy という fork による後続プロジェクトも存在 ◆ Deis Workflow は事実上 Kubernetes の超薄いラッパー ➔ Microservices をやる上では機能的に足りない ◆ リソース等含めた細かいコントロール・コード化 ◆ アプリケーション単体ではなく集合としての管理

Slide 18

Slide 18 text

移行の流れ ➔ 基本的にはガッツと根性！そして粛々やり続けるだけ ➔ Dockerfile を書く ◆ 元が Heroku Buildpack なので変わったイメージはそんなにない ◆ Twelve-Factor App なのでアーキテクチャ的に変なやつも基本ない ➔ 環境変数を ConfigMap に切り出し ➔ 先にテスト用のドメインを別途 Reverse Proxy に追加して確認する ➔ 前段にある Reverse Proxy で Deis から Kubernetes にひとつずつスイッチ

Slide 19

Slide 19 text

Monorepo への移行 ➔ Quipper における現役のサービスのほぼ全てを含む巨大な単一リポジトリ ➔ Web Developer の @mtsmfm の意見を元に CTO が実現 ➔ 元は個別リポジトリだったものを git subtree add でインポートしていった ◆ 便宜上元の個別のリポジトリを classic repos と呼んでいる

Slide 20

Slide 20 text

Monorepo への移行 ➔ 現状は Quipper は Monorepo で完結、移行が完了していないスタディサプリは classic repos で開発中 ➔ Classic repos で行った変更は日次で monorepo に同期 ◆ git subtree pull を全サービスに対して実行 ◆ Jenkins Job から Pull Request が作られ、マージすると同期が完了 ➔ Monorepo -> classic repos への同期はなんかうまくいかないのでできていない ➔ どうせ移行が完了したら monorepo に一本化するので放置

Slide 21

Slide 21 text

04 Kubernetes の運用

Slide 22

Slide 22 text

方針 ➔ できる限り全てを GitHub リポジトリで管理 ◆ Pull Request ベースのレビュー ◆ マージによるデプロイ (CircleCI) ➔ 大きなツールやミドルウェアの導入は本当に必要になるまで控える ◆ manifest は基本 YAML + kustomize ● Datadog Agent のようなカスタマイズがそんなにないものは Helm ◆ 負債化を避けるため (バランスは難しい)

Slide 23

Slide 23 text

方針 ➔ 移行をやりきるまでは移行に集中！ ◆ 現状は割とコスト度外視でじゃぶじゃぶ Node を投入している状態...

Slide 24

Slide 24 text

リポジトリ ➔ quipper/kubernetes-clusters ◆ kube-aws で生成したクラスタ定義ファイル (CloudFormation の Stack Template 等も含む) ◆ Quipper 用、スタディサプリ用、それぞれのステージング・本番、それらの複 数世代 ◆ Deis 用のものも現状含まれている (もうすぐ消せる) ◆ 基本的に SRE のみでメンテナンス (Pull Request は誰でもウェルカム)

Slide 25

Slide 25 text

リポジトリ ➔ quipper/kubernetes-clusters ◆ Jaeger や Datadog Agent のような各クラスタで共通となるコンポーネントの manifest ● 素の YAML, Helm, kustomize, envsubst ◆ それらを CD するためのデプロイスクリプト (Bash) ◆ Pull Request ベースでクラスタの構築や manifest の apply が行える

Slide 26

Slide 26 text

リポジトリ ➔ quipper/monorepo ◆ 前述の「Quipper における現役のサービスのほぼ全てを含む巨大な単一リ ポジトリ」 ◆ 基盤としては SRE が中心に構築しているが、中での開発は全ての開発者で 行っていく ● Dockerfile/Kubernetes manifest 等は GitHub の CODEOWNERS に より SRE のレビューを必須とする

Slide 27

Slide 27 text

リポジトリ ➔ quipper/monorepo ◆ Dockerfile ◆ 各サービスの Kubernetes manifest 及び kustomize overlays ◆ それらを Pull Request ベースで CI/CD するためのデプロイスクリプト (Bash)

Slide 28

Slide 28 text

リポジトリ ➔ その他にも Ansible/Terraform/Codenize.tools 等のためのリポジトリがそれぞ れ存在

Slide 29

Slide 29 text

クラスタ内のアプリケーションの配置 ➔ 本番クラスタ ◆ 基本全サービスが単一の production Namespace 内に存在 ◆ production 内には service-router と呼ばれるコンポーネントも存在 ● 中身はただの Nginx ● 各サービスのアプリレイヤに近い部分の Reverse Proxy 的役割 ● これまで SRE がメンテしてきた Reverse Proxy (Kubernetes 外) の一 部を切り出して Web Developer に移譲していくため

Slide 30

Slide 30 text

No content

Slide 31

Slide 31 text

クラスタ内のアプリケーションの配置 ➔ ステージングクラスタ ◆ Develop, release, pr-*** といった複数の Namespace 内に、全サービスが それぞれ存在 ● これらを便宜上 Service Environment と呼ぶ (Quipper 独自の用語) ● develop: devlop ブランチをデプロイする環境 ● release: release` ブランチをデプロイするリリーステスト環境 ● pr-***: Pull Request を作るたびに作られるステージング環境

Slide 32

Slide 32 text

クラスタ内のアプリケーションの配置 ➔ ステージングクラスタ ◆ branch-router というコンポーネントが branch-router Namespace に ◆ URL を元に適切な Service Environment の Namespace 内の service-router に橋渡し ◆ これも中身はただの Nginx ● service-router から先は本番クラスタとほぼ変わらない ◆ Jaeger や Datadog Agent 等のコンポーネントについても本番クラスタと同 様

Slide 33

Slide 33 text

No content

Slide 34

Slide 34 text

クラスタのアップグレード ➔ 実は現状ほぼできていない (！！) ➔ ようやくアップグレードのための仕組み・運用方針が今週 (！！) 出来上がったとこ ろ ◆ クラスタ毎に kube-aws のバージョンを変えて CD する仕組み ◆ クラスタに世代の概念を導入し、複数世代を並行して構築・デプロイ

Slide 35

Slide 35 text

クラスタのアップグレード ➔ クラスタの世代 ◆ クラスタ名の末尾に 01, 02 といった連番を付加 ◆ クラスタ名の例: quipper-staging ◆ 世代番号を含む完全クラスタ名の例: quipper-staging-01 ➔ サービスごとに前段の Reverse Proxy から切り替えたりする予定

Slide 36

Slide 36 text

現状の課題 ➔ クラスタの継続的アップグレード ➔ Audit ありで Rails Console を解放するための仕組み (heroku run 的な) ➔ CI/CD パイプラインの改善 ◆ デプロイスクリプト壊れやすい問題 ◆ Spinnaker? ◆ 秘密情報の管理の改善

Slide 37

Slide 37 text

現状の課題 ➔ リソースの最適化 (特にステージング) ◆ オートスケーリング ◆ ステージングデプロイ時、変更のないサービスは develop Namespace に Forward ➔ Service Mesh ◆ Observability の向上、認証・認可、Canary Release、Circuit Breaker、 Fault Injection などなど...

Slide 38

Slide 38 text

@mumoshu (Yusuke Kuoka) さんが Technical Advisor に！ ➔ kube-aws をはじめとした、Kubernetes エコシステムの数多くのOSSに貢献 ➔ 世界に 5 人、日本に 1 人しかいない AWS Container Heroes の 1 人 ➔ Kubernetes に関するあらゆることの相談、議論、レビュー ➔ Quipper では珍しい副業という関わり方でバリューを 出してもらっている

Slide 39

Slide 39 text

@mumoshu (Yusuke Kuoka) さんが Technical Advisor に！ ➔ とはいえまだまだ深いところを議論していきたい！という話をご本人ともしている ◆ まずは移行を終わらせて時間と余裕を確保しなくては...

Slide 40

Slide 40 text

05 Microservices 化への道のり

Slide 41

Slide 41 text

組織構成 ➔ Service Unit ◆ 主にビジネスごとに分割されたチーム (B2C, B2B2C, 拠点ごとのビジネス) ◆ Service Owner (= mini CEO), Product Manager, Developer, Designer ◆ Service Unit ごとに裁量を持つ ➔ Technical Project ◆ Data Restructure (データ処理基盤)

Slide 42

Slide 42 text

組織構成 ➔ 現状は結局それぞれのチームが共通のコードベースをさわっている ◆ 分断されたモノリス

Slide 43

Slide 43 text

分断されたモノリス ➔ Quipper VPoE の @kyanny が Rails Developers Meetup 2018 において提唱し た概念 ◆ Quipperにおける「関心の分離」の歴史 https://docs.google.com/presentation/d/1ZNDGuDQGbq2TliUukExUmUi cKUJXjWejBD2zd_E8SFU/edit#slide=id.g357c6cbf64_0_63

Slide 44

Slide 44 text

分断されたモノリス ➔ 用途毎に (マイクロではない) サービスに分割されてはいるが... ◆ 学習者用サービス、先生用サービス、コンテンツ制作者用サービス、カスタ マーサポート用サービス... ➔ データベースは基本的に単一の巨大な MongoDB にそれぞれのサービスが依存 している ◆ データベースを抽象化するモデル層も同様 (private な gem になっている) ➔ 分割が適切でないため、技術的負債および組織的課題となっている

Slide 45

Slide 45 text

Microservices 化の状況 ➔ Kubernetes 移行と同時に実験的にいくつかのサービスの切り出しを行った ◆ grpc-ruby による Microservices と、それを集約する API Frontend (Rails) ◆ 一部の API を新旧両方のレスポンスを比較しつつ移行 ◆ GitHub の Scientist を用いて結果を比較、データベースに残してダッシュ ボードで見える化

Slide 46

Slide 46 text

No content

Slide 47

Slide 47 text

No content

Slide 48

Slide 48 text

Microservices 化の状況 ➔ Kubernetes 移行と並行して進む Technical Project ◆ Data Restructure ● サービスと分析の双方に信頼性の高い学習データを用意するための処 理基盤 ● Elixir/OTP/Amazon Kinesis/Amazon Aurora ◆ Kubernetes 移行として進む新規事業プロジェクト ● 前述のマイクロサービスを GraphQL で集約して API として利用

Slide 49

Slide 49 text

まだまだ採用中 ➔ Kubernetes や、AWS をはじめとしたパブリッククラウドに強い SRE・インフラエン ジニア ➔ Microservices やアーキテクチャのスペシャリスト ➔ その基盤上で最高の教育サービスを作っていきたい開発者 (Web・モバイル) ➔ Twitter で @yuya_takeyama まで DM くれれば話をしたり適切な人に繋いだりし ます

Slide 50

Slide 50 text

No content