こんにちは。アドベントカレンダー 10日目の記事です。
dodaサイト開発にてシニアエンジニアをしている中澤です。独立系SIerにてエンジニアをスタートして、現場ガチャを転々として2018年からパーソルキャリアにジョインしています。
気が付けば古株になっています。
データモデルの変更
いくつかの技術系のイベントでも発表している通り、dodaのアプリケーションのアーキテクチャ刷新が完了しつつあります。クリーンアーキテクチャによりDBの複雑さを内包したものになりますが、これによりデータモデルのリファクタリングができるようになります。
一度作ったデータモデルは変更しにくく、アプリケーションにも大きな負担をかけます。
せっかくデータモデルをリファクタリングするなんてエンジニアでもなかなか経験できないことがまっているので、改めてデータモデルについていろいろ学んでみました。
その中で興味を持ったイミュータブルデータモデルについてご紹介します。
イミュータブルデータモデル
UPDATEが複雑さの根源であるという考え方の元、更新による複雑性を回避するための設計手法です。業務自体が複雑であってもそれをデータモデリングの見地からひも解いて、どう立ち向かうか？が鍵となります。そういった際に複雑さを分析し、シンプルな設計とすることで業務が本当に何をしたいのか？質の高い対話にて深く業務要求を分析し、顧客やチームの本質的な価値を上げるために有効な手法の一つです。
ここまでの情報をネット上で記事を見つけて気になった手法だったので、WEB＋DB PRESSを購入してみました。読みながら実際に開発していて感じた課題とその解決方法について記載していきます。
当たり前に隠された複雑性
過去のdodaのTABLE設計ルールに「登録/更新/削除日時を持つこと」「論理削除フラグを持つこと」がありました。
イミュータブルデータモデルではこれがそもそもの複雑性とみなされます。
「いつどんなイベントで更新するのかわからない」＝「業務の複雑さをそのままシステムに落とし込んでいる」
例えば論理削除フラグについて考えてみます。
一般的に会員登録サイトで論理削除フラグが付く場合はどのような場合でしょうか？
- ユーザがサービスに退会したとき
- ユーザからのクレームにより事務局で削除したとき
- ユーザの不正利用により事務局で削除したとき
一般的には①かと思いますが、②および③のケースも削除という同じイベントとして表現されます。
また、論理削除フラグのUPDATEの場合、ユーザが復活するということもUPDATEで行うのかを判定しないとなりません。
またビッグデータで解析する際に退会ユーザは論理削除していても参照したいことがあり、本来解析に使いたい「サービスの利用をやめたユーザ」が複雑な情報を持ったまま実装されています。
こうしたデータモデルの複雑さをリソースとイベントという概念でシンプルな設計に変えていきます。
会員情報というエンティティがあるとします。会員情報には氏名や住所が入っており、これらはリソースとしてシステム上でデータとして保存されます。
このリソースに更新を行うエンティティをイベントエンティティとして定義し、リソースはイベントによって更新されます。このイベントは過去に起きた事実の記録であり不変のものとなります。イベントエンティティがイミュータブルとなり、リソース自体は更新され参照されていきます。
イベントエンティティとリソースエンティティ
実際にイミュータブルデータモデルに従ってデータ更新のイベントを分けてモデリングすると、とてつもない数のエンティティが出来上がります。
dodaは職業紹介と求人広告の2つの事業を1サイトで行っていることから、原稿情報のパターンで考えても多くのエンティティが発生してしまいます。
実際にイベントとして記載すべき項目は「お金になるもの」「記録しないと何かを失うリスクとなるもの」に絞って設計すべきですが、それでも多くのイベントを管理することとなります。
そのため全てのデータモデリングをRDBのみで実装しようとする場合には性能問題などが新たに発生する可能性があります。
あくまで論理データモデリングの手法であり、業務の複雑さに対抗する手法となります。
そのため実際実装する場合はRDBのみではなく、アプリケーションを含めてデータモデルの表現をしていくことが効果的です。
実際にイミュータブルデータモデルを保ったままアプリケーションを運用するならば、性能問題に直面することが想定されます。キャッシュ処理や非正規化などによるイベントエンティティのとりまとめを行う場面もありそうです。
dodaではアーキテクチャ刷新によりクリーンアーキテクチャが導入できているため、論理データモデリング→物理設計の落とし込みがうまくいく土壌があります。
業務の複雑性への対応
ビジネスは成長し複雑性はどんどん増していきます。
もしシステムエンジニアがなんの手も打たない場合は、年々開発スピードは落ちてシステム起因でビジネスの成長阻害になります。
イミュータブルデータモデルを利用すると、各登録のイベントを明確にすることが必須になるため、ビジネスの複雑性の可視化ができます。
こうした複雑性を可視化することで業務をシステムに落とし込んだ場合でも、負債がたまりにくい開発になると思います。
システムの価値
パーソルキャリアに入って、ビジネス成長に合わせてシステム開発をしていて本当にこれを痛感しております。
実際にビジネスと合わせてシステム開発をできるのが事業会社エンジニアの醍醐味です。
データモデリングリファクタリングをやりながら、実際にビジネスの成長に寄与できるのか？を検証しこれからも開発を進めていきます。
事業会社エンジニアは開発～保守まで見れるので、リファクタリングが将来のビジネスに寄与できているかまで確認できるので、価値のあるコードをを書きたいエンジニアにおススメです。
ありがとうございました。
中澤 勝 Masaru Nakazawa
プロダクト開発統括部 グロース開発部 dodaサイト開発1グループ シニアエンジニア
2018年6月にパーソルキャリアへ中途入社。
※2024年12月現在の情報です。
