プロダクト成長を加速させる_共通機能のサービスの分離

2022年4月19日に「成長中の2社が語る、複数プロダクトを跨ぐデータ活用を実現するためのアーキテクチャーとは」で登壇した内容です。
https://potentialight.connpass.com/event/243833/

マイクロサービス化の1種である共通サービスの分離をテーマに発表しています。

Transcript

1. プロダクト成長を加速させる 共通機能のサービス分離 江上
2. 2 Copyright © 2022 by Link and Motivation Inc. All rights reserved. リンクアンドモチベーション 江上 真人 役割: テックリード&EM - モチベーションクラウドシリーズおよび共 通サービスの設計 - プラットフォームチームのマネージャー twitter: @MasatoEgami 自己紹介
3. 3 Copyright © 2022 by Link and Motivation Inc. All rights reserved. リンクアンドモチベーション 会社 モチベーションエンジニアリングを基幹技術として 「従業員のエンゲージメント向上」を支援してる会社
4. 4 Copyright © 2022 by Link and Motivation Inc. All rights reserved. ミッション P/LやB/Sなどの事業面だけで企業が評価されるのではなく、組織面も評価される社会！ 働きがいを持って活動する人を増やしたい！！！
5. 5 Copyright © 2022 by Link and Motivation Inc. All rights reserved. 外部環境の変化 ①米国で先んじて人的資本の開示が義務化 ②人的資本開示に関するガイドラインの公表や取得 ③大手企業の人的資本公表・企業目標として明文化 「人的資本開示」に合わせて従業員エンゲージメントへの関心が爆上がり
6. 6 Copyright © 2022 by Link and Motivation Inc. All rights reserved. 外部環境の変化 ①米国で人的資本の開示が義務化 ②人的資本開示に関するガイドラインの公表や取得 ③大手企業の人的資本公表・企業目標として明文化 エンゲージメントの情報が 世間的にも価値あるデータに！ 「人的資本開示」に合わせて従業員エンゲージメントへの関心が爆上がり
7. 7 Copyright © 2022 by Link and Motivation Inc. All rights reserved. エンゲージメントチェーン 弊社の戦略 エンゲージメントに関わる組織・個人のデータを統合することで 新しい価値を提供する プロダクトを跨いだデータ統合や、他サービスとの連携が必須
8. 8 Copyright © 2022 by Link and Motivation Inc. All rights reserved. 課題と解決策 人・組織のデータがサービスを跨いで統合されてない（ =guidがない）
9. 9 Copyright © 2022 by Link and Motivation Inc. All rights reserved. 認証・組織管理・契約管理を共通サービスとして分離 自社プロダクト間でデータを統合中 TEAMWORK CLOUD 組織 認証 契約 現在地 共通サービス群
10. 10 Copyright © 2022 by Link and Motivation Inc. All rights reserved. マイクロサービスには主に2種類ある 今回のサービス切り出しの特徴 使い所が限定的な（= 依存されてない） 処理を切り出す - 認証処理 - メール送信処理 - pdfファイルの作成処理 - ユーザーデータとその CRUD処理 - 組織データとそのCRUD処理 - 契約データとそのCRUD処理 頻繁に利用する（= 依存されてる） データや処理を共通的に使える様に切り出す
11. 11 Copyright © 2022 by Link and Motivation Inc. All rights reserved. 処理の切り出しは、サードパーティーを活用して実施済み 今回のサービス切り出しの特徴 - 認証処理 - メール送信処理 - pdfファイルの作成処理 - ユーザーデータとその CRUD処理 - 組織データとそのCRUD処理 - 契約データとそのCRUD処理 Auth0 SendGrid AWS Lambda 使い所が限定的な（= 依存されてない） 処理を切り出す 頻繁に利用する（= 依存されてる） データや処理を共通的に使える様に切り出す
12. 12 Copyright © 2022 by Link and Motivation Inc. All rights reserved. 今回はコアデータを切り出す 今回のサービス切り出しの特徴 - 認証処理 - メール送信処理 - pdfファイルの作成処理 - ユーザーデータとその CRUD処理 - 組織データとそのCRUD処理 - 契約データとそのCRUD処理 使い所が限定的な（= 依存されてない） 処理を切り出す 頻繁に利用する（= 依存されてる） データや処理を共通的に使える様に切り出す
13. 13 Copyright © 2022 by Link and Motivation Inc. All rights reserved. 今回のチャレンジ、実は ... 3回目のチャレンジ
14. 14 Copyright © 2022 by Link and Motivation Inc. All rights reserved. - どこまでリアルタイムにデータを反映するの？ - どこまで手をいれるの？ - 構成どうする？セキュリティってどこまでやるの？ どこまでやるの？との戦い やっていく中で見えた課題（設計）
15. 15 Copyright © 2022 by Link and Motivation Inc. All rights reserved. - どこまでリアルタイムにデータを反映するの？ - どこまで手をいれるの？ - 構成どうする？セキュリティってどこまでやるの？ どこまでやるの？との戦い やっていく中で見えた課題（設計） 対象と時間をそれぞれ考える
16. 16 Copyright © 2022 by Link and Motivation Inc. All rights reserved. 対象と時間をそれぞれ考える 特に、「組織情報の更新」は長い戦いがあったw データ・処理によって要件はまちまち データ種別 反映速度 対象プロダクト 処理方法 パスワードの更新 リアルタイム 全プロダクト 同期更新 特定プロダクトの契約更新 できるだけ早く （数分は許容） 特定プロダクト 非同期更新 特定プロダクトの契約参照 早く （最悪の場合、数時間前のものでも許容） 特定プロダクト キャッシュ参照 組織情報の更新 ユーザーの任意のタイミングでできるだけ早く （量によっては数十分は許容） 全プロダクト 同期的にキック 非同期更新
17. 17 Copyright © 2022 by Link and Motivation Inc. All rights reserved. 組織情報の更新 他サービスの都合で更新された組織情報をどのタイミングで反映するか？ - 組織サービスで情報をいつでも編集したい　 が　人事発令前にプロダクトに反映されては困る - あるプロダクトで使う組織情報を変更したい　 が　他プロダクトでは変更されてほしくないときもある - プロダクト間で有効なデータは異なる状態にしたい　 が　組織データの履歴は統一したい 組 織 組織変 更分 組織 組織 組織変 更分 1. 無効なデータとして連携 2. 各プロダクトで データを有効に ユーザーの任意のタイミングで 全プロダクトに無効なデータとしてデータ反映 反映された無効データを各プロダクトで有効化
18. 18 Copyright © 2022 by Link and Motivation Inc. All rights reserved. - どこまでリアルタイムにデータを反映するの？ - 影響範囲どこまでひろげるの？ - 構成どうする？セキュリティってどこまでやるの？ どこまでやるの？との戦い やっていく中で見えた課題（設計） 対象と時間をそれぞれ考える
19. 19 Copyright © 2022 by Link and Motivation Inc. All rights reserved. - どこまでリアルタイムにデータを反映するの？ - 影響範囲どこまでひろげるの？ - 構成どうする？セキュリティってどこまでやるの？ どこまでやるの？との戦い やっていく中で見えた課題（設計） 対象と時間をそれぞれ考える スモールサクセスを積み上げるため、広げすぎない
20. 20 Copyright © 2022 by Link and Motivation Inc. All rights reserved. 組 織 APIで共通サービスからいい感じでデータ引っ張ってきて、各アプリの DBはスリムに！ ・組織関連のモデル参照している箇所全部修正 ・JOINも解いてうまいことやる ・性能要件満たすために別途工夫必要 組織 APP データ スモールサクセスを積み上げるため、広げすぎない 最初考えてた形 ORマッパー使ってると、コードとテーブル構造が密になってるので、剥がそうとすると大変 すぎる
21. 21 Copyright © 2022 by Link and Motivation Inc. All rights reserved. データのキャッシュ先がたまたま今まで使ってたテーブルと同じ構造をして、 同じデータストアに格納されているという考え方にした ・各アプリ側のテーブル・ロジック変更はほぼ不要 ・性能についてもほぼ気にしなくて良い スモールサクセスを積み上げるため、広げすぎない 最終的な形 組 織 組織 APP データ 組織 1. 変更通知 2.データを取得 デプロイ頻度あげるって発想自体が大事 3. キャッシュ更新
22. 22 Copyright © 2022 by Link and Motivation Inc. All rights reserved. - どこまでリアルタイムにデータを反映するの？ - 影響範囲どこまでひろげるの？ - 構成どうする？セキュリティってどこまでやるの？ どこまでやるの？との戦い やっていく中で見えた課題（設計） 対象と時間をそれぞれ考える スモールサクセスを積み上げるため、広げすぎない 他社の具体事例を仕入れる
23. 23 Copyright © 2022 by Link and Motivation Inc. All rights reserved. 具体の細かいところを本や勉強会スライドで仕入れるのは大変 他社の具体事例を仕入れる 弊社でも出てきた論点 - セキュリティどうやる？ - security group? 鍵認証? app mesh? - どこまでログ取る？ - VPCフローログは？SQS APIコールログは？ - サーバーどこまで分ける？ - private APIはサーバー分ける？ - キューって何で実現する？ - SQS? SNS+SQS? EventBridge?
24. 24 Copyright © 2022 by Link and Motivation Inc. All rights reserved. awsさんがめちゃくちゃ頼もしい 他社の具体事例を仕入れる ・他社で多い事例を教えてくれる ・新しいサービスなど選択肢を増やしてくれる おすすめされて 採用したもの おすすめされたけど 採用しなかったもの - セキュリティどこまでやる？ - どこまでログ取る？ - サーバーどこまで分ける？ 一応内緒w 基本的に全部とる様に設定。特に通信部分 APIサーバーはpublicとprivateで別にした - キューって何で実現する？ 複数の方法のメリデメを教えてもらい、社内 の実績なども考慮して SNS+SQSを採用 最後決めるのは自分
25. 25 Copyright © 2022 by Link and Motivation Inc. All rights reserved. - mockやseedをちゃんと作らないと、他の人が開発できない - ドキュメントちゃんと作らないと、マジで使ってもらえない - 連携確認を手元でするのが思ったよりめんどくさい - テストの境界を決めるの大変 - 連携先・連携元両方の知識が必要なので、オンボーディング大変 開発効率の悪化を防ぐの思ったより難しい プラットフォームチームが連携部分も作ることで、運用の課題をまだ洗い出してる ところ。ナレッジ溜まったらまた共有したい やっていく中で見えた課題（運用）
26. 26 Copyright © 2022 by Link and Motivation Inc. All rights reserved. やってよかったこと - ミッション・ビジョンをチームで定期的に確認する - 最初の繋ぎ込みはプラットフォームチームがアプリチームに入ってやる - プラットフォームの設計は使われる側のデータ設計まで含めてやる - 落ちそうなものは積極的に拾う - プラットフォームチームの方から、アプリチームのマイルストーン切りに行く プラットフォームチームのスタンス おまけ（だけど、 LMが大事にしてること）