2019年 HRBrainの技術的挑戦 / hrbain technology challenge 2019

D68ec2463959a924ada156a278743228?s=47 yudppp
December 20, 2019

2019年 HRBrainの技術的挑戦 / hrbain technology challenge 2019

D68ec2463959a924ada156a278743228?s=128

yudppp

December 20, 2019
Tweet

Transcript

  1. 2019年HRBrainの 技術的挑戦

  2. ⾃⼰紹介 @yudppp 株式会社HRBrain CTO 好きな⾔葉: 冪等性
 嫌いなモノ: 浮動⼩数点の誤差
 
 Go

    / TypeScript書いてます
  3. ⽬標評価管理クラウド

  4. HRBrainとは • ⽬標と評価を管理するクラウドSaaSを作って いる会社です。 • リリース開始からもうすぐで3年 • Horizontal SaaS (業界を問わずに導⼊されるSaaS)

  5. 2019年⼈員推移 • 1⽉ • サーバーエンジニア: 3⼈ • フロントエンジニア: 3.5⼈ •

    デザイナー: 1⼈ • 現在 • サーバーエンジニア: 7.5⼈ • フロントエンジニア: 7⼈ • デザイナー: 1⼈ • スクラムマスター: 1⼈ • QAエンジニア: 1⼈ 2.33ഒ
  6. 2019年⾏ったこと • ⽬標評価管理クラウドのリニューアル(2019/3/18) • リリース後、週1~2でリリース(合計76回) • 初めての開発合宿@館⼭(2019/08/01~02) • クラウドベンダー移⾏(2019/12/29) •

    AWSからGCPに移⾏する • ⼈事DBの仕込み • 2020年3⽉リリース予定 • 合わせてマイクロサービス化
  7. ⽬標評価管理について

  8. なぜリニューアルしたか ࢀՃऀݶఆެ։

  9. リニューアル後の技術スタック • Go • TypeScript(not strict) • React • Docker

    • REST API • PostgreSQL • Swagger • Vue/Nuxt(LP/Help) • Netlify CMS(Help) • JAM Stack(LP/Help)
  10. アーキテクチャ • マルチテナントアーキテクチャ • 1つのアプリケーションでデータベースを共 有 (最も効率的な真のマルチテナンシー)

  11. 1つのクラウドサーバーに全ての企業 اۀ" اۀ# اۀ$ اۀ"޲͚
 "1αʔόʔ اۀ"޲͚
 %# اۀ#޲͚
 "1αʔόʔ

    اۀ#޲͚
 %# اۀ$޲͚
 "1αʔόʔ اۀ$޲͚
 %#
  12. 1つのアプリケーションで異なるDBを使⽤ اۀ" اۀ# اۀ$ اۀ"޲͚
 %# "1αʔόʔ اۀ#޲͚
 %# اۀ$޲͚


    %#
  13. 1 つのアプリケーションでDBを共有 اۀ" اۀ# اۀ$ "1αʔόʔ %#

  14. DBを共有した時のメリット • インフラのコストが安い • スキーマの更新が簡単 • ⼀度のリリースで全てのテナントがリリース される

  15. DBを共有した時のデメリット • 実装難度が⾼い • DBの障害時に全テナントに影響がでる • セキュリティに不安がある • あるテナントが別のテナントのデータを⾒ れてしまう可能性がある(data

    violation)
  16. ձࣾ" ձࣾ# ձࣾ# ձࣾ$ こんな感じのusersテーブルがあった時に

  17. ձࣾ" ձࣾ# ձࣾ# ձࣾ$ 本来Where句を指定するところを 4&-&$5 '30.VTFST
 8)&3&UFOBOU@JElձࣾ#z

  18. ձࣾ" ձࣾ# ձࣾ# ձࣾ$ 本来Where句を指定するところを 4&-&$5 '30.VTFST
 8)&3&UFOBOU@JElձࣾ#z

  19. ձࣾ" ձࣾ# ձࣾ# ձࣾ$ Where句を指定忘れてしまうと 4&-&$5 '30.VTFST

  20. ձࣾ" ձࣾ# ձࣾ# ձࣾ$ Where句を指定忘れてしまうと 4&-&$5 '30.VTFST ΋ͪΖΜ શͯͷձࣾͷ ϝϯόʔ৘ใ͕

    औΕͯ͠·͏
  21. 開発確認フロー •実装のレビューを2⼈以上必ず⾒る •モック化してテスト •QAによる確認
 
 上記を⾏なっているが複雑になってくると指 定を絶対に忘れないとは限らない。

  22. PostgreSQLのRowLevelSecurity • データベーステーブル内の⾏へのアクセス を制御することで、このdata violationを 防ぐことができる。 • 詳細は「マルチテナント 銀の弾丸」でグ グってください(今年のBuildersconで話し ました)

  23. HELPページの仕様 • カテゴリーごとに記事を投稿できる • 任意のキーワードで記事本⽂検索できる • 関連記事を登録できる • エンジニアいらず(リリース作業いらず)で記事の更新が⾏える •

    弊社のサービスにログインしている⼈だけに⾒える • 公開しないのでSEOは考慮しなくて良い • リリース後の記事の更新頻度は週に1回程度の予定
  24. HELPページの構成① → Front Matter → Marked → contents/*.md contents.json ---


    id: 1
 title:ヘルプページの作り⽅ category: help
 ---
 ## はじめに
 { 
 "attributes": {
 "id": 1,
 "title": "ヘルプページの作り⽅", "category": "help"
 },
 "body": "## はじめに¥n "
 } { 
 "id": 1,
 "title": "ヘルプページの作り⽅", "category": "help",
 “body": "<h2>はじめに</h2> "
 } [{ 
 "id": 1,
 "title": "ヘルプページの作り⽅", "category": "help",
 “body": "<h2>はじめに</h2> "
 }, ]
  25. HELPページの構成② • NuxtJSを利⽤ • ①でできたcontents.jsonを⾷わせて、 nuxt generateする • contents.jsonはNustのbuild:beforeのタ イミングで⽣成させう

  26. Netlify CMS • Headless CMS • サーバーを持たないStaticなアプリケーション • Githubをbackendに指定した場合にGithubのアカウントでログ インし、GithubのAPIを叩きMarkdownや画像の書き込みを⾏う

    • 権限管理⾃体はGithubに準ずる • GithubのGUIをCMS向けに改造しただけのため、データは Githubに⼀元化される。
  27. HELPページの構成③ 1.$4 /FUMJGZ$.4
 PO/FUMJGZ (JU)VC $JSDMF$* %FQMPZFE &OHJOFFS /VYU Push

    content/*.md nuxt generate Push
  28. None
  29. None
  30. None
  31. ⽬標管理クラウドで良かったこと • ⽐較的安全にマルチテナントを作成できた • フロントエンドも型は⼤事 • Netlify/Sentryがすごく便利 • docker-compose upだけすればlocal動いて簡単(外

    部サービスをMock化) • サブプロダクト(LP/Help)のJAM Stackがイケてる
  32. ⽬標管理クラウドで気づいた課題 • ドキュメントが全然運⽤されない • 仕様が複雑で新しく⼊ってきた⼈のオンボードが⼤ 変 • SQLのマイグレーションFileでコンフリクトが⼤量 発⽣する(goose) •

    フロントエンドも型は⼤事(最初からstrictにしてお けばよかった)
  33. ⼈事DBについて

  34. ⼈事DBを作るにあたって • ⽬標管理クラウドで得た課題を解決しつつ作 るべく⾊々考えていきました。

  35. ユビキタス⾔語集 • DDDに習ってユビキタス⾔語集を作成。 • 英語もあらかじめ定義することによって表記 揺れが減りました。

  36. 開発合宿@館⼭ • ⼀泊⼆⽇で開発合宿を実施 • 通常の業務を極⼒忘れて、⼈事DBのモデリン グをサーバチーム⾏なった。

  37. DDDとCQRS • DDDとCQRSのエッセンスを取り⼊れた開発 • ドメインモデルに業務知識を凝集し、Query とCommandを分けて実装

  38. ⼈事DBのシステム概要 • Go • TypeScript(strict) • React • GraphQL •

    gRPC • sqldef • PostgreSQL
  39. Schema駆動開発 schema.graphql gqlgen ίʔυࣗಈੜ੒ ResolverҎԼΛ࣮૷͢Δ graphql-codegen ίʔυ/TSͷܕΛࣗಈੜ੒ ͦΕΒΛ࢖ͬͯը໘࡞੒

  40. Schema駆動開発 • メンテナンスのされなくなりがちなドキュメ ントがSchemaの受け渡しだけで可能に • 型が⾃動で共通化されるので安全 • 無駄なHTTPリクエストを減らせることにな るので嬉しい(GraphQL)

  41. sqldef • SQLで羃等にDBスキーマ管理ができるツール • schema.sqlとdbの状態を⽐較してよしなに ALTERしてくれる • PostgreSQLアンカンファレンスで話している ので詳細はこちら

  42. マイクロサービス化

  43. マイクロサービス • 1サービスの役割が明確になることによっ て、メンテナブルにしたい • 組織が拡⼤するにあたって技術的な責務を分 けたい。 • ユーザー情報や認証など共通化していきた い。

  44. API GateWay اۀ" اۀ# اۀ$ ໨ඪධՁ؅ཧ Front ਓࣄDB Front ೝূ

    ໨ඪධՁ؅ཧ API ਓࣄDB API ϩάΠϯը໘ REST API GraphQL Twirp REST API GraphQL gRPC gRPC gRPC gRPC
  45. マイクロサービスのルール • プロダクト間の直接のやり取りはしない • 内部のやり取りは基本的にgRPC • APIは全てAPI Gatewayを経由する

  46. API Gatewayと認証・認可 • Goで全て実装 • API GatewayはHTTP/1.1だけ使える。 • 極⼒プロダクトに依存しない設計 •

    プロダクトが増えてもスケールするように Cloud Firestoreを利⽤
  47. Kubernetes + Istio • マイクロサービスにしていくにあたってサー ビス間のネットワーク管理やスケールが容易 である • デプロイフローを⼀元化しやすい

  48. GCP移⾏について • なぜAWSに移⾏するのか • Kubernetesを使うにあたってGKEが使いやすい • Kubernetes使う上でのデファクトスタンダー ドである • 安い/ダッシュボードが標準/ログがいい感じ

  49. ⽬標評価管理のGCP移⾏ • 年末は第⼀弾として⽬標評価管理ツールの移⾏を ⾏う • アプリケーションはもともとDockerで動いてい たので細かい⼿直しのみ • DBも移管も⾏う •

    深夜にメンテナンスに振る(ご迷惑おかけします。)
  50. Infra as a Code • Terraformで全てのInfraをGithub上で管理し ている(Kubernetesも含めて) • ⼿作業の運⽤を減らすことができ安全に

  51. インフラで利⽤しているもの/概念 • GCP • Kubernetes • Istio • Helm •

    Kustomize • Flux/Flagger • Terraform • GitOps
  52. HRBrain UI Library • 各サービスで共通で使うボタンやDatepickerなど を提供するReactのComponent集 • Storybookで管理していてプロダクトからimport して利⽤する。 •

    デザイナーがSketchでカタログを作成。 • 外部正式公開予定
  53. None
  54. None
  55. None
  56. None
  57. HRBrain SDK • 各プロダクトで共通で使うモジュールのライブ ラリ • HRBrain UI Libraryと異なりHRBrain固有のもの •

    例えばプロダクト⼀覧を出すパネルなど • マイクロフロントエンドの第⼀弾?
  58. None
  59. None
  60. HRBrain SDKの技術 • Web Component • TypeScript • SkateJS(with lit-html)

    • Lit ElementでやりたかったけどIE11で上⼿く動かせ なかった。 (Vanilla Web Componentでもいいかも) • jsを読み込めば<hrb-menu/>のタグが使えるようになる
  61. 総括 • 2019年は昨年仕込み続けていたサービスリ ニューアルをリリースと、Monolithicなサー ビスからMicroServiceへと進化をするための 仕込み期間でした。 • 2020年は複数のサービスが同時に動き出すこ とにより慌ただしく楽しい1年になるかと思 います。

  62. 全 職 種 積 極 募 集 中 ! !