Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

yudppp
December 20, 2019

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

yudppp

December 20, 2019
Tweet

More Decks by yudppp

Other Decks in Technology

Transcript

  1. 2019年HRBrainの
    技術的挑戦

    View Slide

  2. ⾃⼰紹介
    @yudppp
    株式会社HRBrain CTO
    好きな⾔葉: 冪等性

    嫌いなモノ: 浮動⼩数点の誤差


    Go / TypeScript書いてます

    View Slide

  3. ⽬標評価管理クラウド

    View Slide

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

    View Slide

  5. 2019年⼈員推移
    • 1⽉
    • サーバーエンジニア: 3⼈
    • フロントエンジニア: 3.5⼈
    • デザイナー: 1⼈
    • 現在
    • サーバーエンジニア: 7.5⼈
    • フロントエンジニア: 7⼈
    • デザイナー: 1⼈
    • スクラムマスター: 1⼈
    • QAエンジニア: 1⼈
    2.33ഒ

    View Slide

  6. 2019年⾏ったこと
    • ⽬標評価管理クラウドのリニューアル(2019/3/18)
    • リリース後、週1~2でリリース(合計76回)
    • 初めての開発合宿@館⼭(2019/08/01~02)
    • クラウドベンダー移⾏(2019/12/29)
    • AWSからGCPに移⾏する
    • ⼈事DBの仕込み
    • 2020年3⽉リリース予定
    • 合わせてマイクロサービス化

    View Slide

  7. ⽬標評価管理について

    View Slide

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

    View Slide

  9. リニューアル後の技術スタック
    • Go
    • TypeScript(not strict)
    • React
    • Docker
    • REST API
    • PostgreSQL
    • Swagger
    • Vue/Nuxt(LP/Help)
    • Netlify CMS(Help)
    • JAM Stack(LP/Help)

    View Slide

  10. アーキテクチャ
    • マルチテナントアーキテクチャ
    • 1つのアプリケーションでデータベースを共
    有 (最も効率的な真のマルチテナンシー)

    View Slide

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

    "1αʔόʔ
    اۀ"޲͚

    %#
    اۀ#޲͚

    "1αʔόʔ
    اۀ#޲͚

    %#
    اۀ$޲͚

    "1αʔόʔ
    اۀ$޲͚

    %#

    View Slide

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

    %#
    "1αʔόʔ
    اۀ#޲͚

    %#
    اۀ$޲͚

    %#

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  17. ձࣾ"
    ձࣾ#
    ձࣾ#
    ձࣾ$
    本来Where句を指定するところを
    4&-&$5'30.VTFST

    8)&3&[email protected]ձࣾ#z

    View Slide

  18. ձࣾ"
    ձࣾ#
    ձࣾ#
    ձࣾ$
    本来Where句を指定するところを
    4&-&$5'30.VTFST

    8)&3&[email protected]ձࣾ#z

    View Slide

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

    View Slide

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

    View Slide

  21. 開発確認フロー
    •実装のレビューを2⼈以上必ず⾒る
    •モック化してテスト
    •QAによる確認


    上記を⾏なっているが複雑になってくると指
    定を絶対に忘れないとは限らない。

    View Slide

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

    View Slide

  23. HELPページの仕様
    • カテゴリーごとに記事を投稿できる
    • 任意のキーワードで記事本⽂検索できる
    • 関連記事を登録できる
    • エンジニアいらず(リリース作業いらず)で記事の更新が⾏える
    • 弊社のサービスにログインしている⼈だけに⾒える
    • 公開しないのでSEOは考慮しなくて良い
    • リリース後の記事の更新頻度は週に1回程度の予定

    View Slide

  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": "はじめに "

    }
    [{ 

    "id": 1,

    "title": "ヘルプページの作り⽅",
    "category": "help",

    “body": "はじめに "

    }, ]

    View Slide

  25. HELPページの構成②
    • NuxtJSを利⽤
    • ①でできたcontents.jsonを⾷わせて、
    nuxt generateする
    • contents.jsonはNustのbuild:beforeのタ
    イミングで⽣成させう

    View Slide

  26. Netlify CMS
    • Headless CMS
    • サーバーを持たないStaticなアプリケーション
    • Githubをbackendに指定した場合にGithubのアカウントでログ
    インし、GithubのAPIを叩きMarkdownや画像の書き込みを⾏う
    • 権限管理⾃体はGithubに準ずる
    • GithubのGUIをCMS向けに改造しただけのため、データは
    Githubに⼀元化される。

    View Slide

  27. HELPページの構成③
    1.$4 /FUMJGZ$.4

    PO/FUMJGZ
    (JU)VC $JSDMF$*
    %FQMPZFE
    &OHJOFFS /VYU
    Push content/*.md
    nuxt generate
    Push

    View Slide

  28. View Slide

  29. View Slide

  30. View Slide

  31. ⽬標管理クラウドで良かったこと
    • ⽐較的安全にマルチテナントを作成できた
    • フロントエンドも型は⼤事
    • Netlify/Sentryがすごく便利
    • docker-compose upだけすればlocal動いて簡単(外
    部サービスをMock化)
    • サブプロダクト(LP/Help)のJAM Stackがイケてる

    View Slide

  32. ⽬標管理クラウドで気づいた課題
    • ドキュメントが全然運⽤されない
    • 仕様が複雑で新しく⼊ってきた⼈のオンボードが⼤

    • SQLのマイグレーションFileでコンフリクトが⼤量
    発⽣する(goose)
    • フロントエンドも型は⼤事(最初からstrictにしてお
    けばよかった)

    View Slide

  33. ⼈事DBについて

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  42. マイクロサービス化

    View Slide

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

    View Slide

  44. API GateWay
    اۀ" اۀ# اۀ$
    ໨ඪධՁ؅ཧ Front ਓࣄDB Front
    ೝূ
    ໨ඪධՁ؅ཧ API ਓࣄDB API
    ϩάΠϯը໘
    REST API GraphQL Twirp
    REST API GraphQL
    gRPC
    gRPC gRPC
    gRPC

    View Slide

  45. マイクロサービスのルール
    • プロダクト間の直接のやり取りはしない
    • 内部のやり取りは基本的にgRPC
    • APIは全てAPI Gatewayを経由する

    View Slide

  46. API Gatewayと認証・認可
    • Goで全て実装
    • API GatewayはHTTP/1.1だけ使える。
    • 極⼒プロダクトに依存しない設計
    • プロダクトが増えてもスケールするように
    Cloud Firestoreを利⽤

    View Slide

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

    View Slide

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

    View Slide

  49. ⽬標評価管理のGCP移⾏
    • 年末は第⼀弾として⽬標評価管理ツールの移⾏を
    ⾏う
    • アプリケーションはもともとDockerで動いてい
    たので細かい⼿直しのみ
    • DBも移管も⾏う
    • 深夜にメンテナンスに振る(ご迷惑おかけします。)

    View Slide

  50. Infra as a Code
    • Terraformで全てのInfraをGithub上で管理し
    ている(Kubernetesも含めて)
    • ⼿作業の運⽤を減らすことができ安全に

    View Slide

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

    View Slide

  52. HRBrain UI Library
    • 各サービスで共通で使うボタンやDatepickerなど
    を提供するReactのComponent集
    • Storybookで管理していてプロダクトからimport
    して利⽤する。
    • デザイナーがSketchでカタログを作成。
    • 外部正式公開予定

    View Slide

  53. View Slide

  54. View Slide

  55. View Slide

  56. View Slide

  57. HRBrain SDK
    • 各プロダクトで共通で使うモジュールのライブ
    ラリ
    • HRBrain UI Libraryと異なりHRBrain固有のもの
    • 例えばプロダクト⼀覧を出すパネルなど
    • マイクロフロントエンドの第⼀弾?

    View Slide

  58. View Slide

  59. View Slide

  60. HRBrain SDKの技術
    • Web Component
    • TypeScript
    • SkateJS(with lit-html)
    • Lit ElementでやりたかったけどIE11で上⼿く動かせ
    なかった。 (Vanilla Web Componentでもいいかも)
    • jsを読み込めばのタグが使えるようになる

    View Slide

  61. 総括
    • 2019年は昨年仕込み続けていたサービスリ
    ニューアルをリリースと、Monolithicなサー
    ビスからMicroServiceへと進化をするための
    仕込み期間でした。
    • 2020年は複数のサービスが同時に動き出すこ
    とにより慌ただしく楽しい1年になるかと思
    います。

    View Slide

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

    View Slide