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

https://hrbrain.connpass.com/event/157875/ でお話しした内容です

スライド内で紹介している記事
https://speakerdeck.com/yudppp/row-level-security-is-silver-bullet-for-multitenancy
https://speakerdeck.com/yudppp/sqldef-introduction-for-psql-users

会社紹介資料
https://speakerdeck.com/hrbrain/introduction

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αʔόʔ اۀ$޲͚
 %#
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@JE
    
    lձࣾ#z
18. ձࣾ" ձࣾ# ձࣾ# ձࣾ$ 本来Where句を指定するところを 4&-&$5
    
    '30.
    VTFST
 8)&3&
    UFOBOU@JE
    
    lձࣾ#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
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でカタログを作成。 • 外部正式公開予定
57. HRBrain SDK • 各プロダクトで共通で使うモジュールのライブ ラリ • HRBrain UI Libraryと異なりHRBrain固有のもの • 例えばプロダクト⼀覧を出すパネルなど • マイクロフロントエンドの第⼀弾？
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. 全 職 種 積 極 募 集 中 ! !