「脱RDB」を掲げて開発が始まったHUEは、当初CassandraをRDB的な発想で利用する実装をしていました。 その結果、MSA間でのデータ不整合を防ぐためのロールバック処理が肥大化し、メンテナンス性やパフォーマンスが向上しにくい状態に。 本セッションでは「出張旅費精算が提出された」という場面のトランザクション管理に着目し、どのようにRDB脳から分散Drivenな実装に変えていったかを紹介します。 キーワード ・Point-to-point OrchestrationからChoreography ・ロールバックからロールフォワードへ We began development with Cassandra in an RDB-like way of thinking, even though AI WORKS has a concept of "Non-RDB". Roll-back processing for preventing data inconsistency between microservices made difficult to improve maintainability and performance. In this session, I will focus on transaction management of the scenario "Business trip expense report was submitted". It will introduce how we changed from RDB-mined to distributed-driven implementation through concrete examples. Keywords * From Point-to-point Orchestration to Choreography * From Rollback to Roll-forward

1. RDB脳でCassandra/MSAを始めた僕達が、
分散Drivenなトランザクション管理に
たどり着くまで
Kota Futami
AC Div. Expense Dept.
Works Applications CO., LTD
Cassandra Summit 2017

2. ざっくりどんなストーリー？

3. Season 1:不整合問題をロールバックで解決するまで
1. Cassandra使って、Monolithicなアプリ
2. (途中から) MSAだーーー！
3. MSAまたぐところで、データの不整合
4. ひとまずRollback処理を書いて回避(ここがRDB脳)

4. Season 2: 分散Drivenへ
1. Rollbackのデメリットが多すぎる、根本解決しよう
2. Rollfoward, Choreographyの方針で、再設計
3. 1サービスで実装&検証 ←今ここ
4. 別サービスに展開

5. コンテンツ紹介

6. 目次
1. 文脈の共有 3分
2. 前半: メインストーリー 15分
2.1. MSA化と不整合問題
2.2. Rollbackで止血。そのデメリット
2.3. 分散ドリブンへの移行 (概要)
2.4. Season1へのQ&A (5分以内)
3. 後半: もっと細かい話 15分
3.1. この場合どうなるの？ エラーパターンをいくつか紹介
3.2. 派生したでてきた検討すべきこと
3.3. 全体通したQ&A (時間終了まで)

7. 聞くメリット1
プロダクション開発の最前線で
起きている生々しい話が聞ける

8. 聞くメリット2
実構成に限りなく同じ内容で説明
→「うちはもっと複雑だから」が起きにくい
ゆえに後半は細かい話で眠くなるかも
「概要だけ知れればいい」という方は
前半のQAで帰ることをおすすめします

9. 1. 文脈の共有

10. Who am I?
二見 広太
株式会社ワークスアプリケーションズ
AC Div. Expense Dept.
ソフトウェアエンジニア / DBアーキテクト
2015年からビジネスアプリケーション「 HUE」の経費精算アプリの開発に参加、フロントからサーバーサイドまで手
掛ける。
RDBからの移行に苦労する人が多いなか、特に詳しくもないのに「 Cassandra Meister」を自称し始める。
徐々に知識をつけ、レビューや勉強会開催などを通じ、データモデリングの品質向上に努める。
Cassandra Summit プロフィールより

11. HUE Expense: どんなプロダクト？
BtoB BtoC CtoC

12. HUE Expense: どんなプロダクト？
freee
楽楽精算
concur
フルラインナップ
経費精算専用
チームスピリット
Workday
会計,人事,SCM...
大企業向け中小企業向け

13. 新製品
- 1300社以上での実績
- 無償バージョンアップ
- Consumerアプリと同じUX
- 圧倒的な速度

14. 技術が大きく変わった
- Monolithic
- Client: Delphi, WEB
- Server: Java
- MW: RDBMS, Tomcat
- オンプレ
- MSA
- Client: WEB
- Server: Java
- MW: Cassandra, Kafka, Elasticsearch,
Redis….
- SaaS
- Other: OCR, 自然言語処理, 機械学習...

15. もとからDB寄りではない
Base
Technolog
y
Product
- 技術選定
- フレームワーク実装
- アーキテクチャ設計
- etc.
- AC
- HR
- SCM
- EC
- etc.
基本この辺の人間
ごりごりDBな人はこっち

16. Fullstack
Front side
Server side
CI
UIデザイン
設計
実装 etc.
×

17. 余談:
Cassandra はキャリアの面で、
投資効率のいいトピックだったなー、
という話

18. 最初は「なんかCassandraとか詳しくなっとけばお
得かも」くらいなノリで、
Cassanra Meisterってアダ名もらう

19. 知識のキャッチアップに使った時間は、
大して多くない

20. の割には、けっこうデカイ顔できるようになった

21. データベース以外にも、
● 他の人があんまり興味持っていない
● けど重要
というトピックあるはず

22. そういうのを探して、
「◯◯大臣」とか自称してみるといいよ

23. 2. 前半: メインストーリー

24. 目次
1. 文脈の共有 3分
2. 前半: メインストーリー 15分
2.1. MSA化と不整合問題
2.2. Rollbackで止血。そのデメリット
2.3. 分散ドリブンへの移行 (概要)
2.4. Season1へのQ&A (5分以内)
3. 後半: もっと細かい話 15分
3.1. この場合どうなるの？ エラーパターンをいくつか紹介
3.2. 派生したでてきた検討すべきこと
3.3. 全体通したQ&A (時間終了まで)

25. 最初期はMonolithic (2015年あたりまで)
ひとつのAP Server
Expense
Talent
SearchTimeline
Cassandra
ESS

26. (途中から) MSAにするぞーーー！
Expense Service A
Service B
Cassandra
Cassandra
Cassandra
2016年春あたり
Expenseがそれを始めた歴史的 MR
http://product-ci/company/hue-ac-expense/commit/c15dac05a5d8e58b311b1211952e49a44166d00d

27. 「出張旅費精算」って・・・
出張時に
立替えた領収書をまとめ
て提出
会社からお金を返しても
らう

28. 出張旅費精算書を1枚提出したとき
Expense
承認
ワークフロー
仕訳
Cassandra
Cassandra
Cassandra
支払い予定 Cassandra
メール送信 SMTP
INSERT
POST

29. 単純に呼ぶだけだと
Expense
承認
ワークフロー
仕訳
Cassandra
Cassandra
Cassandra
支払い予定 Cassandra
メール送信 SMTP
INSERT
Timeout
データ無
し

30. エラーが起きると、申請したのに・・
- 支払い予定日が決まらない
- 出張者にお金が返ってこない
- 仕訳が立たない
- 決算の数字が正しくない

31. 会計システムとして
致命的な不具合

32. 目次
1. 文脈の共有 3分
2. 前半: メインストーリー 15分
2.1. MSA化と不整合問題
2.2. Rollbackで止血。そのデメリット
2.3. 分散ドリブンへの移行 (概要)
2.4. Season1へのQ&A (5分以内)
3. 後半: もっと細かい話 15分
3.1. この場合どうなるの？ エラーパターンをいくつか紹介
3.2. 派生したでてきた検討すべきこと
3.3. 全体通したQ&A (時間終了まで)

33. 最低限
不整合が起きないようにしよう

34. エラーが起きたら
Rollbackしよう

35. (これがRDB脳・・)

36. Rollbackを実装して止血
Expense
承認
ワークフロー
仕訳
Cassandra
Cassandra
Cassandra
支払い予定 Cassandra
メール送信 SMTP
DELETE
Timeout
データ無
し
Rollback
DELETE 削除
削除

37. これでめでたしめでたし？

38. NO

39. Rollback実装のデメリット
1. 関わるmicroserviceが増えるほど、速度が遅くなる、可用性が下
がる
2. Rollbackの質は、各プロダクトの開発者の腕任せ
3. 不整合が起きるパターンが引き続き残り、手動リカバリが必要

40. 目次
1. 文脈の共有 3分
2. 前半: メインストーリー 15分
2.1. MSA化と不整合問題
2.2. Rollbackで止血。そのデメリット
2.3. 分散ドリブンへの移行 (概要)
2.4. Season1へのQ&A (5分以内)
3. 後半: もっと細かい話 15分
3.1. この場合どうなるの？ エラーパターンをいくつか紹介
3.2. 派生したでてきた検討すべきこと
3.3. 全体通したQ&A (時間終了まで)

41. 基本的なアイデア
経費申請書のデータがDBに入ったら、
自動仕訳や支払い予定って、
ちょっと経った後でインサートされてもいいじゃん

42. Rollback から Roll-forward へ

43. 非同期でPOST + リトライ
Expense
承認
ワークフロー
仕訳
Cassandra
Cassandra
Cassandra
支払い予定 Cassandra
メール送信 SMTP
INSERT
全部非同期
でPOST
クライアントには
すぐ成功で返す

44. これでOK?

45. NO

46. 非同期でPOST + リトライ のデメリット
1. 成功するまでスレッドを専有し続ける
2. Expenseのサーバー落ちたら復旧できない

47. 直接HTTPで呼ぶことに限界

48. orchestration with point-to-point から
Choreography へ

49. Source: Introduction into Microservices by Oliver Wolf
https://specify.io/concepts/microservices#choreography

50. Kafkaを間にはさむ
Expense
承認
ワークフロー
仕訳
Cassandra
Cassandra
Cassandra
支払い予定 Cassandra
メール送信 SMTP
INSERT
PRODUCE
CONSUME

51. 目次
1. 文脈の共有 3分
2. 前半: メインストーリー 15分
2.1. MSA化と不整合問題
2.2. Rollbackで止血。そのデメリット
2.3. 分散ドリブンへの移行 (概要)
2.4. Season1へのQ&A (5分以内)
3. 後半: もっと細かい話 15分
3.1. この場合どうなるの？ エラーパターンをいくつか紹介
3.2. 派生したでてきた検討すべきこと
3.3. 全体通したQ&A (時間終了まで)

52. 3. 後半: もっと細かい話

53. 目次
1. 文脈の共有 3分
2. 前半: メインストーリー 15分
2.1. MSA化と不整合問題
2.2. Rollbackで止血。そのデメリット
2.3. 分散ドリブンへの移行 (概要)
2.4. Season1へのQ&A (5分以内)
3. 後半: もっと細かい話 15分
3.1. この場合どうなるの？ エラーパターンをいくつか紹介
3.2. 派生したでてきた検討すべきこと
3.3. 全体通したQ&A (時間終了まで)

54. 3.1.1 成功パターン

55. ブラウザ
経費AP
Kafka
topic=仕訳呼ぶ
Kafka
topic=支払い予定呼ぶ
経費Cassandra
1 申請処理開始
2 Produce
3 Produce
Kafka
topic=仕訳作成
仕訳AP
仕訳Cassandra
Kafka
topic=支払い予定作成
支払い予定AP
支払い予定
Cassandra
4 Insert
5 「申請成功したぜ」
1 Consume
3 Produce
4 Consume
5 INSERT
支払予定も仕訳と同様
なので省略
2 SELECT

56. 3.1.2 呼び先のAPがダウン

57. ブラウザ
経費AP
Kafka
topic=仕訳呼ぶ
Kafka
topic=支払い予定呼ぶ
経費Cassandra
1 申請処理開始
2 Produce
3 Produce
Kafka
topic=仕訳作成
仕訳AP
仕訳Cassandra
Kafka
topic=支払い予定作成
支払い予定AP
支払い予定
Cassandra
4 Insert
5 「申請成功したぜ」
1 Consume
3 Produce
4 Consume
5 INSERT
復旧したタイミングで
Consumeされる
2 SELECT
この期間ダウン

58. 3.1.3 Kafkaがダウン

59. ブラウザ
経費AP
Kafka
topic=仕訳呼ぶ
Kafka
topic=支払い予定呼ぶ
経費Cassandra
1 申請処理開始
2 Produce
Kafka
topic=仕訳作成
仕訳AP
仕訳Cassandra
Kafka
topic=支払い予定作成
支払い予定AP
支払い予定
Cassandra
3 「システムエラーだよ・・」
Error

60. 3.1.4 二つ目のProduce時に
Kafkaがダウン

61. ブラウザ
経費AP
Kafka
topic=仕訳呼ぶ
Kafka
topic=支払い予定呼ぶ
経費Cassandra
1 申請処理開始
2 Produce
3 Produce
Kafka
topic=仕訳作成
仕訳AP
仕訳Cassandra
Kafka
topic=支払い予定作成
支払い予定AP
支払い予定
Cassandra
4 「システムエラーだよ・・」
1 Consume
精算書データがないので、
仕訳データを作りに行かない
2 SELECT
Error
No
data

62. 3.1.5 申請書データの
INSERTが遅延

63. ブラウザ
経費AP
Kafka
topic=仕訳呼ぶ
Kafka
topic=支払い予定呼ぶ
経費Cassandra
1 申請処理開始
2 Produce
3 Produce
Kafka
topic=仕訳作成
仕訳AP
仕訳Cassandra
Kafka
topic=支払い予定作成
支払い予定AP
支払い予定
Cassandra
4 Insert
5 「申請成功したぜ」
1 Consume
3 Produce
4 Consume
5 INSERT
2 SELECT
No
data
成功するまでリトライ
→ ということは3.1.4のパターン
でもリトライが発生する

64. リトライに関する補足
1. 当然有限回数しかリトライしない
2. リトライ中にAPが落ちた場合、MessageをCommitしていないので
復旧後再実行される
3. 有限回数内ですべてエラーになった場合は別途リカバリが必
要

65. 目次
1. 文脈の共有 3分
2. 前半: メインストーリー 15分
2.1. MSA化と不整合問題
2.2. Rollbackで止血。そのデメリット
2.3. 分散ドリブンへの移行 (概要)
2.4. Season1へのQ&A (5分以内)
3. 後半: もっと細かい話 15分
3.1. この場合どうなるの？ エラーパターンをいくつか紹介
3.2. 派生したでてきた検討すべきこと
3.3. 全体通したQ&A (時間終了まで)

66. リトライがすべて失敗した場合
- リカバリバッチが必要
- 直近の申請データをつってきて、突き合わせ？
- ここは現在設計中

67. 2重Consume問題
- Kafkaのキューは「1度しかConsumeされない」保証無し
- 冪等性の確保が必要
- LWT
- Counterカラムは使わない
- 既存のAPIがすでに使っているので改修必要

68. 仕訳データを作る前にバリデーションしたい
- 仕訳作成APIの呼び出しが非同期になった
- 不正なデータだったら仕訳作らず、エラーにしたい
- 確認画面に行くときに、予めバリデーションが必要

69. すべてのサービスを同時に直す余裕がない
Expense
承認
ワークフロー
仕訳
Cassandra
Cassandra
Cassandra
支払い予定 Cassandra
メール送信 SMTP
INSERT
POST
ひとまずこの2つから置き換え
残りはロールバックのまま

70. KafkaのConsumeが極端に遅れた場合は？
- 仕訳など作成期限ある
- リカバリバッチでなんとかする
- あるいは、何かトリガーがあるなら、そこで同期実行

71. デバッグしにくい
- 今のところ妙案なし・・・
- いい案知ってる方教えてください

72. リグレッションテストが大変
- 自動テストなども遅延込みで見直す

73. 他のサービスは？
- どこまで同様のパターンでいけるのか調査必要
- ドキュメントに落とす
- 社内エバンジェリストをたて、啓蒙してもらう

74. まだまだ戦いは続く・・

75. 目次
1. 文脈の共有 3分
2. 前半: メインストーリー 15分
2.1. MSA化と不整合問題
2.2. Rollbackで止血。そのデメリット
2.3. 分散ドリブンへの移行 (概要)
2.4. Season1へのQ&A (5分以内)
3. 後半: もっと細かい話 15分
3.1. この場合どうなるの？ エラーパターンをいくつか紹介
3.2. 派生したでてきた検討すべきこと
3.3. 全体通したQ&A (時間終了まで)