KUBERNETES 上に GO 言語と NOSQL で、独自のマイクロサービスフレームワークを構築した話

Slide 1

Slide 1 text

Slide 2

Slide 2 text

自己紹介岩崎英俊 / Hidetoshi Iwasaki ⚫ 株式会社Hexabase 代表取締役 CEO ⚫ 文系学部出身、システム開発会社でSE経験後、販売・会計・人事システムなどの企業開発プロジェクトなどに参加 ⚫ SaaS/IaaS事業の企画・立ち上げ・事業運営などを経験 ⚫ 2016 年に起業～クラウドバックエンドのど真ん中にチャレンジ中 ⚫ エンタープライズ BaaS「Hexabase」を提供中 Copyright 2021 Hexabase, Inc

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Slide 9

Slide 9 text

Slide 10

Slide 10 text

Slide 11

Slide 11 text

Slide 12

Slide 12 text

Slide 13

Slide 13 text

Slide 14

Slide 14 text

Slide 15

Slide 15 text

Slide 16

Slide 16 text

Slide 17

Slide 17 text

Slide 18

Slide 18 text

Slide 19

Slide 19 text

Slide 20

Slide 20 text

Slide 21

Slide 21 text

技術的な特徴 Copyright 2021 Hexabase, Inc 1. Kubernetesによるマイクロサービス管理 2. アプリケーションフレームワークを nodejs/Goで独自開発 3. 技術トレンドにあわせて.NET C#, Pythonなども活用 4. NoSQL の組み合わせでデータストアを実現 5. FaaS(Function as a Service)を組み合わせてバックエンド拡張も可能

Slide 22

Slide 22 text

Slide 23

Slide 23 text

Slide 24

Slide 24 text

Slide 25

Slide 25 text

KUBERNETESで運用を最適化 Copyright 2021 Hexabase, Inc はオートスケールによる拡張例 dev staging, production Clusters Node Pools Pods Zone: northeast1 (TOKYO) Zone: northeast1 (TOKYO) mongodb mysql elasticsearch dd-agent(※) redis (minio) configctl nginx-ingress beee-lp web-ui apicore importer notificator linkerProxy sentinel(※) Persistent Disks Persistent Disk 1TB Persistent Disk 10GB SSD Persistent Disk 500GB Persistent Disk 10GB (postfix) (nsq)

Slide 26

Slide 26 text

Slide 27

Slide 27 text

Slide 28

Slide 28 text

マイクロサービスをどのように分割したか？ Copyright 2021 Hexabase, Inc • 受注登録 • ユーザ登録サービス • 決済サービス • 認証サービス • ： • 通常のリクエスト処理 • 大量データ投入 • データの一括更新（遅延処理） • キューイングされた重い処理（順番待ち） • Timer起動される（定期処理） • 外部サービスとのやりとり • 拡張プログラムの実行 • マイクロサービス間通信Hub Function（処理の特性）単位提供サービス（目的）単位 Hexabaseはこちらを選択

Slide 29

Slide 29 text

Slide 30

Slide 30 text

Slide 31

Slide 31 text

Slide 32

Slide 32 text

グラフDBで、権限管理 Copyright 2021 Hexabase, Inc A G1, G2, G3, G4, G5, G6, G7, G7, G8 R1 A B workspace ワークスペース事業部門顧客 ClientA ClientB Sales DevOps customers staff A B C H システム管理 admin A members G1 G2 G3 G4 R1 R2 R3 R4 G5 G6 G7 G8 B G2, G3, G4 R1, R2 ユーザAがもつアクセスキーユーザBがもつアクセスキーユーザアクセスキーグループアクセスキーロールアクセスキー

Slide 33

Slide 33 text

NOSQLの組み合わせでRDB機能を実現 Copyright 2021 Hexabase, Inc 一般的なRDB Hexabase 論理設計（ER表記）どちらも、概念的には同様の表記が可能関連の保持双方でテーブルのキーフィールドを指定し、論理的に関連をもつ。関連データの実体を持たない。それぞれのデータアイテムごとに関連の実体データ（Item_links)を持つ。テーブル間の結合検索 SQL発行時に、各テーブルデータを検索してJOINする。データ量や構造によってパフォーマンスが劣化するケースがある。クエリ実行時に、実体の関連データをたどってJOINするため、高速。データ登録・更新・削除時の挙動テーブルデータのみを更新し、関連情報の更新は発生しない。更新データをもとに、関連データをUpdateする。リアルタイム性 ACID特性 ACIDによるデータ整合が完全に担保される。関連データが作成されるまでの間に多少のタイムラグが発生