「マイクロサービスアーキテクチャ」と「アーキテクチャ特性」で読み解くレバテックのこれまでとこれから

Slide 1

Slide 1 text

レバテック株式会社 CTO室 / テックリード / 河村　勇樹「マイクロサービスアーキテクチャ」と「アーキテクチャ特性」で読み解くレバテックのこれまでとこれから

Slide 2

Slide 2 text

なぜ、マイクロサービス！？全然、ハッピーじゃない！？これから、どうする！？

Slide 3

Slide 3 text

|　© Leverages inc. 3 ● 座学タイム ○ マイクロサービスアーキテクチャ ○ アーキテクチャ特性 ● レバテックのこれまで ● レバテックのこれからアジェンダ Index

Slide 4

Slide 4 text

座学タイム・マイクロサービスアーキテクチャとは・アーキテクチャ特性とは

Slide 5

Slide 5 text

マイクロサービスアーキテクチャ

Slide 6

Slide 6 text

No content

Slide 7

Slide 7 text

|　© Leverages inc. 7 ● ビジネスドメインを中心にモデル化された、独立してリリース可能なサービス ● サービス指向アーキテクチャ(SOA)の一種 ● 単一のマイクロサービスは、外部からブラックボックスとして扱われる ○ 内部実装の詳細(サービスが記述されている技術、データの格納方法など)は、外部の世界から完全に隠蔽 ○ 各マイクロサービスは必要に応じて独自のデータベースをカプセル化することを意味する。 ● 情報隠蔽の概念を採用 ○ 「情報隠蔽」は、コンポーネント内に可能な限り多くの情報を隠蔽し、外部インタフェースを介して公開する情報をできるだけ抑えることを意味する。マイクロサービスとは『マイクロサービスアーキテクチャ』 1章マイクロサービスとは

Slide 8

Slide 8 text

|　© Leverages inc. 8 ● 「サービス指向アーキテクチャ」（SOA：Service - Oriented Architecture） ○ 複数のサービスが連携して、一連の機能を提供する設計アプローチ ○ SOAにおける「サービス」は通常、完全に分離されたOSプロセスを意味する ● SOAは大規模なモノリシックアプリケーションの課題に有効なアプローチとして登場 ○ ソフトウェアの再利用の促進やメンテナンスや書き換えを容易に行えることを目的 ● マイクロサービスのアプローチは、SOAをうまく行うために、システムやアーキテクチャの理解を深めようとした、実世界の用途から生まれたもの ○ マイクロサービスをSOAのための特定のアプローチであるサービス指向アーキテクチャとマイクロサービスは違うもの? 『マイクロサービスアーキテクチャ』 1章マイクロサービスとは

Slide 9

Slide 9 text

|　© Leverages inc. 9 ● 独立デプロイ可能性 ○ 他のマイクロサービスをデプロイする必要なしに、あるマイクロサービスを変更し、デプロイし、その変更をユーザにリリースできる、という考え方 ● ビジネスドメインに基づくモデル化 ○ 新機能をロールアウトすることや、マイクロサービスを別の方法で組み合わせて、ユーザに新機能を提供することが容易になる ● マイクロサービスごとの状態の所有 ○ マイクロサービスの内部実装の詳細、外部契約を明確に分けることで、後方互換性のない変更の必要性を減らすことができる ● サイズ ○ あまり重要ではないと著者も語っているので割愛 ● 柔軟性 ○ 多くの軸(組織、技術、スケール、堅牢性)で柔軟性が生まれる ● アーキテクチャと組織の連携 ○ 次のスライドで説明マイクロサービスの重要な概念『マイクロサービスアーキテクチャ』 1章マイクロサービスとは

Slide 10

Slide 10 text

|　© Leverages inc. 10 マイクロサービスの重要な概念 - アーキテクチャと組織の連携『マイクロサービスアーキテクチャ』 1章マイクロサービスとはシステムに求められる変更のほとんどは、ビジネス機能の変更に関連。技術よりもビジネス機能の凝集度を選択する必要がある。垂直方向のビジネスラインに沿って組織やアーキテクチャを分割。ユーザ向け機能のエンドツーエンドのスライスを1チームが所有する。価値のある単一の仕事のストリームに沿って働くチーム＝ストリームアラインドチームに繋がる。

Slide 11

Slide 11 text

アーキテクチャ特性

Slide 12

Slide 12 text

No content

Slide 13

Slide 13 text

|　© Leverages inc. 13 ● システムが成功するために必要な運用と設計の基準となるもの ○ 品質特性やイリティ（-ility）などとも呼ばれる ○ 可用性（availability）や信頼性（reliability）、弾力性（elasticity）といった、システムがサポートしなければならない性質システムの成功基準ともなる ● 共通のアーキテクチャ特性を備えなければならない範囲・境界をアーキテクチャ要素（たとえばマイクロサービスにおけるサービス）として設計していくことこそが、現代のソフトウェアアーキテクチャで重要なプロセスである ● アーキテクチャ特性にはシステムの要件に現れるような明示的なものもあれば、記載されない暗黙的なものもある ○ 暗黙的なアーキテクチャ特性を事前に分析して設計に臨むのが重要アーキテクチャ特性とは『ソフトウェアアーキテクチャの基礎』 4章　アーキテクチャ特性

Slide 14

Slide 14 text

質とスピード～ソフトウェア開発の典型的な誤解を解く～

Slide 15

Slide 15 text

質とスピード～ソフトウェア開発の典型的な誤解を解く～

Slide 16

Slide 16 text

|　© Leverages inc. 16 『ソフトウェアアーキテクチャ・ハードパーツ』 1章　「ベストプラクティス」がないとどうなる? ● どれか1つのアーキテクチャ特性の実現だけに特化するのではなく、競合するすべてのアーキテクチャ特性のバランスを取ること。 ○ 決して最善のアーキテクチャを狙ってはいけない。むしろ、少なくとも最悪でないトレードオフの組み合わせを狙おう。 ● 「アジリティ」というアーキテクチャ特性は、それ自体は測定可能なアーキテクチャ特性ではない。広義のアジリティという言葉を分解してみると、実現すべきは、エコシステムやドメインの変化に対して、チームが自信を持って迅速に対応できるようになることだと分かる。そうすると、アーキテクトは、アジリティに貢献する測定可能なアーキテクチャ特性に、デプロイ性、テスト性、サイクルタイムなどを見い出せる。アーキテクチャ特性が測定できないというときには、定義が曖昧であることが多い。アーキテクチャ特性の重要な観点

Slide 17

Slide 17 text

ソフトウェアアーキテクチャの基礎

Slide 18

Slide 18 text

ソフトウェアアーキテクチャの基礎

Slide 19

Slide 19 text

ソフトウェアアーキテクチャの基礎

Slide 20

Slide 20 text

「マイクロサービスアーキテクチャ」 × 「アーキテクチャ特性」

Slide 21

Slide 21 text

|　© Leverages inc. 21 『ソフトウェアアーキテクチャの基礎』 17章　マイクロサービスアーキテクチャアーキテクチャ特性評価（レイヤードアーキテクチャ）評価（マイクロサービスアーキテクチャ）分割タイプ技術ドメイン量子数 1（モノリス） 1以上デプロイ容易性 ★ ★★★★ 弾力性 ★ ★★★★★ 進化性 ★ ★★★★★ 耐障害性 ★ ★★★★ モジュール性 ★ ★★★★★ 全体的なコスト ★★★★★ ★ パフォーマンス ★★ ★★ 信頼性 ★★★ ★★★★ スケーラビリティ ★ ★★★★★ シンプルさ ★★★★★ ★ テスト容易性 ★★ ★★★★

Slide 22

Slide 22 text

レバテックに求められるアーキテクチャ特性過去の戦略から漁ってみると...

Slide 23

Slide 23 text

© 2022 Leverages Inc.　転載･複製禁止  戦略の階層化ミッション/ビジョン中長期目標事業戦略機能戦略プログラム # 戦略紐づくプログラム群 1 人材と企業データの可用情報充実化レバテックID 新規情報取得（市場 /競合/顧客）企業・案件情報の見直しアクティビティログ 2 アジリティ&スケーラビリティを担保するシステム基盤づくり BSD 統合マスタ JFのRDB化オウンドリプレイス 3 労働集約を脱却するプロダクト開発 LTD LTP 4 営業OEを実現するSFAの構築営業アナリティクス LTSF Salesforce RPA 5 業界最大データを活用した日本一のレコメンドの実現レコメンド精度向上PoC 営業現場へのレコメンド実装プロダクトへのレコメンド実装

Slide 24

Slide 24 text

Slide 25

Slide 25 text

© 2023 Levtech Department All Rights Reserved. コア要素『D-POS』のAsis-Tobe  コア要素 Data Product Operation System Tobe ● 構造化データ ● DB/マスタの統合 ● 高いデータ更新性 ● 新規データの収集と活用 ● プロダクト間をシームレスに ● WEB+ネイティブアプリ ● 認証/エントリーのUX向上 ● 各プロダクトのUX向上 ● 競争優位のコア以外は既製 ● データと機械でOEを担保 ● システム起点で業務を設計 ● 千人規模の営業組織管理要は何するべきか ● データの収集と蓄積のあり方から再設計したほうがいい ● プロダクト間の役割とつながりを再設計する ● 各プロダクトの改善余地大きすぎる（けど改善しづらい） ● 既製SFAに合わせてオペレーション再設計し、データと機械で勝っていく ● 上記Data/Product/Operation の理想を実現しうるシステムを設計 ● 変更容易性の高い設計 ● システム負債を解消しやすい環境/文化 ● 速い開発速度

Slide 26

Slide 26 text

Slide 27

Slide 27 text

|　© Leverages inc. 27 『ソフトウェアアーキテクチャの基礎』 17章　マイクロサービスアーキテクチャアーキテクチャ特性評価（レイヤードアーキテクチャ）評価（マイクロサービスアーキテクチャ）分割タイプ技術ドメイン量子数 1（モノリス） 1以上デプロイ容易性 ★ ★★★★ 弾力性 ★ ★★★★★ 進化性 ★ ★★★★★ 耐障害性 ★ ★★★★ モジュール性 ★ ★★★★★ 全体的なコスト ★★★★★ ★ パフォーマンス ★★ ★★ 信頼性 ★★★ ★★★★ スケーラビリティ ★ ★★★★★ シンプルさ ★★★★★ ★ テスト容易性 ★★ ★★★★

Slide 28

Slide 28 text

|　© Leverages inc. 28 『ソフトウェアアーキテクチャの基礎』 17章　マイクロサービスアーキテクチャアーキテクチャ特性評価（レイヤードアーキテクチャ）評価（マイクロサービスアーキテクチャ）分割タイプ技術ドメイン量子数 1（モノリス） 1以上デプロイ容易性 ★ ★★★★ 弾力性 ★ ★★★★★ 進化性 ★ ★★★★★ 耐障害性 ★ ★★★★ モジュール性 ★ ★★★★★ 全体的なコスト ★★★★★ ★ パフォーマンス ★★ ★★ 信頼性 ★★★ ★★★★ スケーラビリティ ★ ★★★★★ シンプルさ ★★★★★ ★ テスト容易性 ★★ ★★★★

Slide 29

Slide 29 text

「マイクロサービスアーキテクチャ」とレバテックとの相性が良い？？

Slide 30

Slide 30 text

No content

Slide 31

Slide 31 text

レバテックのこれまで本当にレバテックとマイクロサービスアーキテクチャの相性は良いのか？

Slide 32

Slide 32 text

|　© Leverages inc. 32 レバテックにおけるマイクロサービスの歴史

Slide 33

Slide 33 text

|　© Leverages inc. 33 ● 事業成長にシステムが追いつくための課題 ○ 相互依存する、複数の巨大モノリシックサービス ○ 標準化の欠乏 ○ 自動化の欠乏 ● 導入技術がどのように課題を解決するか ○ マイクロサービス化とレイヤードアーキテクチャを主体とした分割統治 ○ TypeScript、gRPC, GraphQLなど型システム技術導入によるチーム間コミュニケーションの円滑化 ○ CI/CD、コード生成、BDD/ATDDの活用による品質の担保 ○ IaCによるインフラの既製化とDevOps推進 ○ 便利さによる標準化の浸透なぜ、マイクロサービスを選択したのか？マイクロサービス化を中心においた技術刷新とその狙い

Slide 34

Slide 34 text

|　© Leverages inc. 34 ● 事業成長にシステムが追いつくための課題 ○ 相互依存する、複数の巨大モノリシックサービス ○ 標準化の欠乏 ○ 自動化の欠乏 ● 導入技術がどのように課題を解決するか ○ マイクロサービス化とレイヤードアーキテクチャを主体とした分割統治 ○ TypeScript、gRPC, GraphQLなど型システム技術導入によるチーム間コミュニケーションの円滑化 ○ CI/CD、コード生成、BDD/ATDDの活用による品質の担保 ○ IaCによるインフラの既製化とDevOps推進 ○ 便利さによる標準化の浸透なぜ、マイクロサービスを選択したのか？マイクロサービス化を中心においた技術刷新とその狙い

Slide 35

Slide 35 text

|　© Leverages inc. 35 なぜ、マイクロサービスを選択したのか？ ● プログラムの設計において分割統治という考え方があります。大きな問題を小さな問題に分割して、小さな問題をすべて解決することで全体を解決するという考え方です。サービスのフロント、BFF、バックエンドの3層への分割、ビジネスドメインを再整理しドメインに分割しマイクロサービス化、一つのマイクロサービス内でのレイヤードアーキテクチャによる分割を行っています。 ● メリット ○ プログラム変更の影響範囲が限定される ○ 開発者が知る必要があるドメイン知識が減る ○ ユニットテストが容易になる ● 結果 ○ 長期に渡り開発効率を高い状態で維持することが期待できる。マイクロサービス化を中心においた技術刷新とその狙い

Slide 36

Slide 36 text

|　© Leverages inc. 36 ビジネスドメインを再整理して分割統治するとは？『マイクロサービスアーキテクチャ』 1章マイクロサービスとは価値のある単一の仕事のストリームに沿って働くシステム（チーム）技術よりもビジネス機能の凝集度を選択する必要がある。

Slide 37

Slide 37 text

|　© Leverages inc. 37 ビジネスドメインを再整理して分割統治するとは？『マイクロサービスアーキテクチャ』 1章マイクロサービスとは価値のある単一の仕事のストリームに沿って働くシステム（チーム）技術よりもビジネス機能の凝集度を選択する必要がある。案件 MS 人材 MS サブシステム

Slide 38

Slide 38 text

これでハッピーになったのか！？全然、ハッピーじゃないですよね？笑

Slide 39

Slide 39 text

なぜ、ハッピーじゃないのか！？

Slide 40

Slide 40 text

|　© Leverages inc. 40 マイクロサービスの特徴レバテック補足独立デプロイ可能性 ❌ 完全な分離ができていないため、依存するサービスやシステムが存在する。ビジネスドメインに基づくモデル化 🔺 ビジネスドメインの分析不足により、ビジネス機能の凝集度は高くない。マイクロサービスごとの状態の所有 🔺 共有データベースを持っているサービスは少ない。サイズー柔軟性 ❌ むしろ、柔軟性が低下している。アーキテクチャと組織の連携 ❌ ビジネスドメインに基づくモデル化ができていないため組織も連携ができていない。なぜ、ハッピーじゃないのか！？

Slide 41

Slide 41 text

|　© Leverages inc. 41 ● 独立デプロイ可能性 ○ 必要な機能がマイクロサービスに委譲されていない ○ オーナーシップがマイクロサービス側に委譲されていない ● ビジネスドメインに基づくモデル化 ○ 各プロダクトが必要な機能だけをマイクロサービス化しただけにすぎない ○ ビジネスドメインの分析が行えていないことにより、サービス境界が不安定 ● 柔軟性 ○ 上記２つの不十分なことで、柔軟性はむしろ低下してしまっているマイクロサービスになりきれていない

Slide 42

Slide 42 text

レバテックのこれから

Slide 43

Slide 43 text

|　© Leverages inc. 43 ● 大前提としてレバテックはまだマイクロサービスを実現できているわけではない ○ マイクロサービスの特性を享受できているわけではない ● アーキテクチャ特性からみてもレバテックと相性が悪いわけではない ○ 今後、求められる「プロダクトの変更容易性」とも相性が良い ● すべての機能をマイクロサービスに移行するのは膨大なコストがかかる ○ リソースが潤沢というわけでもない ○ 今のシステムの改修・運用・保守も存在するマイクロサービスが良くないというわけではない

Slide 44

Slide 44 text

|　© Leverages inc. 44 ● 大きな問題を小さな問題に分割して、小さな問題を解決することで全体を解決する ○ ビッグバンリリースにもならないためにも大事な思考 ○ 大きな問題を解決するには時間とコストもかかり、リスクも大きい ● そのために必要なのは「選択と集中」 ○ 大きな問題を小さな問題に分割して、緊急度と重要度が高いものから解決する分割統治による進め方は重要な思考である

Slide 45

Slide 45 text

|　© Leverages inc. 45 ● 今、システムが求められていることの把握 ○ 経営・事業戦略から求められていることの把握 ● その上で、システムにおける課題はどれなのか？ ○ 経営・事業戦略を実行するために欠けていることはどれなのか？「選択と集中」をするために必要なこと

Slide 46

Slide 46 text

Slide 47

Slide 47 text

|　© Leverages inc. 47 ● マイクロサービスに移行できるならそれが一番理想に近いとは思う ○ アーキテクチャ特性からみてもレバテックと相性が良い ● 「全体的なコスト」と「シンプルさ」は捨てきれない ○ システムが増えるとリソース不足になってしまう ○ 「シンプルさ」を捨ててしまうと、システムの複雑性が上がってしまう ■ さらに人を増やしづらくなってしまう要因にもなり得る ● マイクロサービスの良いところだけを享受できないか？ ○ 「分割統治」「ビジネスドメインに基づくモデル化」「アーキテクチャと組織の連携」やっぱり、マイクロサービスが良いのか！？

Slide 48

Slide 48 text

|　© Leverages inc. 48 ● 「分割統治」 ○ 大きな問題を小さな問題に分割して、小さな問題を解決することで全体を解決する ● 「ビジネスドメインに基づくモデル化」 ○ ビジネスドメインの分析して、ビジネス機能の凝集度を高くする ● 「アーキテクチャと組織の連携」 ○ 価値のある単一の仕事のストリームに沿って働くマイクロサービスの良いところだけを享受できないか？

Slide 49

Slide 49 text

|　© Leverages inc. 49 ● 当たり前ですが、全部を理想形にするのは難しい ○ 「選択と集中」を行い、緊急度と重要度が高いものから行う ● 緊急度と重要度が高いもの ○ 経営・事業戦略から紐づく目標 ■ 保有案件数の最大化 ■ SQL化率（カテゴリ回収～面談実施）の向上 ■ etｃ.. ○ つまり、コアドメインにあたるものは理想形に近づけていきたい ● 緊急度と重要度が低いもの ○ 基本的には後回し ○ 外部ツールに置き換えてしまうのも１つの手段部分的に理想形に近づけていきたい

Slide 50

Slide 50 text

|　© Leverages inc. 50 ● コアドメインとなるものを理想形に近づける ○ どこから「分割統治」を行うべきかを戦略に基づいて決定 ■ そこに合わせて「ビジネスドメインに基づくモデル化」を行う ● これらを実現するため「アーキテクチャと組織の連携」ができる組織作り ● 理想形に近づいているかを評価するための仕組み作り ○ プロダクトの変更容易性を向上させるために必要な6つの特性 ■ 「デプロイ容易性」「耐障害性」「モジュール性」「信頼性」「スケーラビリティ」「テスト容易性」 ○ これら6つを評価できる仕組みの構築 ■ ”Four Keys”も上記を評価するための一部としたい今後、レバテックでやるべきこと（と考えていること）

Slide 51

Slide 51 text

まとめ

Slide 52

Slide 52 text

|　© Leverages inc. 52 ● マイクロサービスとレバテックに求められるアーキテクチャ特性の相性が良い ○ 価値のある単一の仕事のストリームに沿って働くシステム（チーム）を構築 ● 今のレバテックはマイクロサービスの特性を享受できているわけではない ○ 本来のマイクロサービスになりきれていないため ● マイクロサービスの良いところだけを享受していきたい ○ 「分割統治」「ビジネスドメインに基づくモデル化」「アーキテクチャと組織の連携」 ● 今後、レバテックでやるべきこと（と考えていること） ○ コアドメインとなるものを理想形に近づける ○ 理想形に近づいているかを評価するための仕組み作りまとめ

Slide 53

Slide 53 text

さいごに

Slide 54

Slide 54 text

この資料は6時間ぐらいかかりました笑なんだかんだ言語化してみると見えてくることもあるのでよかったですｗ

Slide 55

Slide 55 text

ご清聴ありがとうございました！！！