シェアリングサービスのトランザクションを支えるGo

Slide 1

Slide 1 text

シェアリングサービスのトランザクションを支える Go 2020/09/23 株式会社スペースマーケット　齋藤哲

Slide 2

Slide 2 text

写真 2 自己紹介経歴 NECソリューションイノベータ株式会社にて、官公庁向けASPサービス事業にてソフトウェア開発チームリーダーとして事業拡大に貢献。 2019年に株式会社スペースマーケットへ入社。プロダクト開発やエンジニア組織強化に従事。 2020 年よりCTOとして全社の技術戦略を担当。趣味カラオケ、ギター、機械学習齋藤哲・株式会社スペースマーケット

Slide 3

Slide 3 text

3 スペースマーケットのご紹介

Slide 4

Slide 4 text

4 スペースマーケットとは？場所 (スペース) をシェアすることができるプラットフォーム「働く」「遊ぶ」「暮らす」などのあらゆるシーンにおける選択肢を広げると共に、遊休スペースの有効な活用・収益化に貢献借りたい方や貸したい方の様々な “チャレンジ” をご支援しています

Slide 5

Slide 5 text

5 スペースマーケットのビジネスモデル

Slide 6

Slide 6 text

6 2020年8月にスペースマーケット WORK をローンチ働くシーンに特化したスペースを貸し借りできるプラットフォーム会議・テレワーク・セミナーなどスポット利用 (最短1時間15分単位) や初期費用等不要でのオフィスレンタルでサテライトや BCP 対策など

Slide 7

Slide 7 text

7 note で情報発信も積極的にやっていますエンジニアマーケタービジネス開発デザイナーコーポレート

Slide 8

Slide 8 text

8 Go の採用に至るまでの経緯と内容

Slide 9

Slide 9 text

9 予約システムに係る課題

Slide 10

Slide 10 text

10 従前のアーキテクチャフロントエンド、バックエンドからなる一般的なシステム構成フロントは Node.js、API は Ruby on Rails

Slide 11

Slide 11 text

11 データ構造 1つのスペースに対し複数のプランが設定可能さらにプランに対して複数の例外設定（特別営業）も可能 ※ 実際には他にもエンティティがありますが、主旨から外れるため省略しています

Slide 12

Slide 12 text

12 従前のアーキテクチャの問題点様々にニーズをとらえるためにプランに工夫を重ねると計算処理にかかる時間が増える（UX 低下）

Slide 13

Slide 13 text

13 そんな折に挙がった予約導線の改善施策 ● 従前の UI ではプランを選択した上でカレンダーを表示 ○ カレンダー表示の計算対象は1プランのみ ○ この状態で API 処理のみで平均およそ 500 ms ● 施策の一環で、カレンダーで日時を決めた後にプランを選択 ○ 全てのプランが計算対象に ○ 10 以上のプランをもつスペースあり ○ 従前のまま素直に実装すると数秒かかることに・・・

Slide 14

Slide 14 text

14 問題 ● 予約直前までたどりついてくれたユーザーの体験が下がる ● 予約まで進まずに途中で離脱 = コンバージョン低下施策の目的が達成できないどころか場合によっては改悪に

Slide 15

Slide 15 text

15 課題予約カレンダーの応答性能向上

Slide 16

Slide 16 text

16 目標 1. 予約カレンダーに必要な計算処理を、できるかぎりオンラインではなく事前に計算してキャッシュする 2. キャッシュは、予約の状況にあわせてできるかぎり短時間で更新されるようにする

Slide 17

Slide 17 text

17 予約カレンダーのキャッシュ

Slide 18

Slide 18 text

18 事前計算する仕組み作りスペースの営業時間や予約状況からカレンダーに表示する情報を事前計算する常駐バッチを追加

Slide 19

Slide 19 text

19 差分更新前回実行時からの更新レコードを検出カレンダー情報の差分のみを更新

Slide 20

Slide 20 text

20 キャッシュ更新時間の短縮

Slide 21

Slide 21 text

21 キャッシュの更新時間を短縮するには？ [判断基準] ● 計算処理のパフォーマンス ● 並列処理の実装・保守の容易性 ● 採用実績やエコシステムの充実 ● 言語としてのシンプルさ（習得容易性）より効率的に計算ができる処理系を選択

Slide 22

Slide 22 text

22 処理系の比較結果 Go が最適と判断判断基準 Go Java Node.js Rust C++ 計算処理のパフォーマンス 3 2 1 5 4 並列処理の実装・保守の容易性 5 4 3 1 2 採用実績やエコシステムの充実 2 5 3 1 4 言語としてのシンプルさ 5 3 2 4 1 合計 15 14 9 11 11 ※ 社内での比較のため独自に調査した資料であり、処理系としての優劣を示す資料ではありません

Slide 23

Slide 23 text

23 [再掲] 事前計算する仕組み作り Go で新たにカレンダー構築ジョブを実装

Slide 24

Slide 24 text

24 並列処理の実装 Go に備わっている軽量スレッドによりとてもシンプルに並列処理を実装

Slide 25

Slide 25 text

25 苦労した点 ● 性能最大化を図るため database/sql パッケージで SQL を直叩き ● I / O スループットを高めることができたが・・・ ● 並列処理も相まって接続プールの奪い合いからの実行時エラーが多発 ● 以下のパラメータを調整してなんとか接続プールを循環できるように ○ SetMaxOpenConns() ○ SetMaxIdleConns() ○ SetConnMaxLifetime() ● ご参考：SQL ドライバ => go-sql-driver/mysql データベース接続プールの最適化

Slide 26

Slide 26 text

26 効果と課題

Slide 27

Slide 27 text

27 効果 ● オンライン処理の応答性能 ○ 平均およそ 500 ms から数十 ms に向上 ○ 性能テストの結果、平常時トランザクションの約5倍まで劣化なし ● キャッシュ更新の所要時間 ○ 差分更新に当たり平均 15 分以内

Slide 28

Slide 28 text

28 課題 ● カレンダー計算処理の重複解消 ○ 予約確定時の在庫引当で再計算するため残存 ○ 予約日時の範囲での計算になるため時間はかからないが保守性が落ちるので解決したい ● キャッシュ更新のさらなる短縮 ○ さらなるスケールや計算処理の一元化に向けて

Slide 29

Slide 29 text

29 さらなる改善後の姿

Slide 30

Slide 30 text

30 現在の仕組み常駐バッチを廃し、元データ更新をトリガーにイベント発火ジャストインタイムでカレンダーを更新

Slide 31

Slide 31 text

No content