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

Transcript

1. シェアリング サービスの トランザクションを支える Go 2020/09/23 株式会社スペースマーケット　齋藤 哲
2. 写真 2 自己紹介 経歴 NECソリューション イノベータ株式会社にて、 官公庁向けASPサービス事業にてソフトウェア 開発チーム リーダーとして事業拡大に貢献。 2019年に株式会社スペースマーケットへ入社。プ ロダクト開発やエンジニア組織強化に従事。 2020 年よりCTOとして全社の技術戦略を担当。 趣味 カラオケ、ギター、機械学習 齋藤 哲・株式会社スペースマーケット
3. 3 スペースマーケットのご紹介
4. 4 スペースマーケットとは？ 場所 (スペース) をシェアすることができるプラットフォーム 「働く」「遊ぶ」「暮らす」などのあらゆるシーンにおける選択肢を 広げると共に、遊休スペースの有効な活用・収益化に貢献 借りたい方や貸したい方の様々な “チャレンジ” をご支援しています
5. 5 スペースマーケットのビジネスモデル
6. 6 2020年8月にスペースマーケット WORK をローンチ 働くシーンに特化したスペースを貸し借りできるプラットフォーム 会議・テレワーク・セミナーなどスポット利用 (最短1時間15分単位) や 初期費用等不要でのオフィス レンタルでサテライトや BCP 対策など
7. 7 note で情報発信も積極的にやっています エンジニア マーケター ビジネス開発 デザイナー コーポレート
8. 8 Go の採用に至るまでの経緯と内容
9. 9 予約システムに係る課題
10. 10 従前のアーキテクチャ フロントエンド、バックエンドからなる一般的なシステム構成 フロントは Node.js、API は Ruby on Rails
11. 11 データ構造 1つのスペースに対し複数のプランが設定可能 さらにプランに対して複数の例外設定（特別営業）も可能 ※ 実際には他にもエンティティがありますが、主旨から外れるため省略しています
12. 12 従前のアーキテクチャの問題点 様々にニーズをとらえるためにプランに工夫を重ねると 計算処理にかかる時間が増える（UX 低下）
13. 13 そんな折に挙がった予約導線の改善施策 • 従前の UI ではプランを選択した上でカレンダーを表示 ◦ カレンダー表示の計算対象は1プランのみ ◦ この状態で API 処理のみで平均およそ 500 ms • 施策の一環で、カレンダーで日時を決めた後にプランを選択 ◦ 全てのプランが計算対象に ◦ 10 以上のプランをもつスペースあり ◦ 従前のまま素直に実装すると数秒かかることに・・・
14. 14 問題 • 予約直前までたどりついてくれたユーザーの体験が下がる • 予約まで進まずに途中で離脱 = コンバージョン低下 施策の目的が達成できないどころか場合によっては改悪に
15. 15 課題 予約カレンダーの応答性能向上
16. 16 目標 1. 予約カレンダーに必要な計算処理を、できるかぎりオンライン ではなく事前に計算してキャッシュする 2. キャッシュは、予約の状況にあわせてできるかぎり短時間で 更新されるようにする
17. 17 予約カレンダーのキャッシュ
18. 18 事前計算する仕組み作り スペースの営業時間や予約状況から カレンダーに表示する情報を事前計算する常駐バッチを追加
19. 19 差分更新 前回実行時からの更新レコードを検出 カレンダー情報の差分のみを更新
20. 20 キャッシュ更新時間の短縮
21. 21 キャッシュの更新時間を短縮するには？ [判断基準] • 計算処理のパフォーマンス • 並列処理の実装・保守の容易性 • 採用実績やエコシステムの充実 • 言語としてのシンプルさ（習得容易性） より効率的に計算ができる処理系を選択
22. 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 ※ 社内での比較のため独自に調査した資料であり、処理系としての優劣を示す資料ではありません
23. 23 [再掲] 事前計算する仕組み作り Go で新たにカレンダー構築ジョブを実装
24. 24 並列処理の実装 Go に備わっている軽量スレッドにより とてもシンプルに並列処理を実装
25. 25 苦労した点 • 性能最大化を図るため database/sql パッケージで SQL を直叩き • I / O スループットを高めることができたが・・・ • 並列処理も相まって接続プールの奪い合いからの実行時エラーが多発 • 以下のパラメータを調整してなんとか接続プールを循環できるように ◦ SetMaxOpenConns() ◦ SetMaxIdleConns() ◦ SetConnMaxLifetime() • ご参考：SQL ドライバ => go-sql-driver/mysql データベース接続プールの最適化
26. 26 効果と課題
27. 27 効果 • オンライン処理の応答性能 ◦ 平均およそ 500 ms から数十 ms に向上 ◦ 性能テストの結果、平常時トランザクションの約5倍まで劣化 なし • キャッシュ更新の所要時間 ◦ 差分更新に当たり平均 15 分以内
28. 28 課題 • カレンダー計算処理の重複解消 ◦ 予約確定時の在庫引当で再計算するため残存 ◦ 予約日時の範囲での計算になるため時間はかからないが保 守性が落ちるので解決したい • キャッシュ更新のさらなる短縮 ◦ さらなるスケールや計算処理の一元化に向けて
29. 29 さらなる改善後の姿
30. 30 現在の仕組み 常駐バッチを廃し、元データ更新をトリガーにイベント発火 ジャスト イン タイムでカレンダーを更新