Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

# 社内勉強会
「マイクロサービスアーキテクチャ」と「アーキテクチャ特性」を元に振り返り

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

Tech Leverages

March 25, 2024
Tweet

More Decks by Tech Leverages

Other Decks in Technology

Transcript

  1. | © Leverages inc. 3 • 座学タイム ◦ マイクロサービスアーキテクチャ ◦ アーキテクチャ特性

    • レバテックのこれまで • レバテックのこれから アジェンダ Index
  2. | © Leverages inc. 7 • ビジネスドメインを中心にモデル化された、独立してリリース可能なサービス • サービス指向アーキテクチャ(SOA)の一種 • 単一のマイクロサービスは、外部からブラックボックスとして扱われる

    ◦ 内部実装の詳細(サービスが記述されている技術、 データの格納方法など)は、外部の世界から 完全に隠蔽 ◦ 各マイクロサービスは必要に応じて独自のデータベースをカプセル化することを意味する。 • 情報隠蔽の概念を採用 ◦ 「情報隠蔽」は、コンポーネント内に可能な限り多くの情報を隠蔽し、外部インタフェースを介して 公開する情報をできるだけ抑えることを意味する。 マイクロサービスとは 『マイクロサービスアーキテクチャ』 1章 マイクロサービスとは
  3. | © Leverages inc. 8 • 「サービス指向アーキテクチャ」(SOA:Service - Oriented Architecture) ◦

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

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

    システムに求められる変更のほとんどは、ビジネス機能の変更に関連。 技術よりもビジネス機能の凝集度を選択する必要がある。 垂直方向のビジネスラインに沿って組織やアーキテクチャを分割。 ユーザ向け機能のエンドツーエンドのスライスを1チームが所有する。 価値のある単一の仕事のストリームに沿って働くチーム=ストリームアラインドチームに繋がる。
  6. | © Leverages inc. 13 • システムが成功するために必要な運用と設計の基準となるもの ◦ 品質特性やイリティ(-ility)などとも呼ばれる ◦ 可用性(availability)や信頼性(reliability)、弾力性(elasticity)と

    いった、システムがサポートしなければならない性質システムの成功基 準ともなる • 共通のアーキテクチャ特性を備えなければならない範囲・境界をアーキテク チャ要素(たとえばマイクロサービスにおけるサービス)として設計していくこ とこそが、現代のソフトウェアアーキテクチャで重要なプロセスである • アーキテクチャ特性にはシステムの要件に現れるような明示的なものもあれ ば、記載されない暗黙的なものもある ◦ 暗黙的なアーキテクチャ特性を事前に分析して設計に臨むのが重要 アーキテクチャ特性とは 『ソフトウェアアーキテクチャの基礎』 4章 アーキテクチャ特性
  7. | © Leverages inc. 16 『ソフトウェアアーキテクチャ・ハードパーツ』 1章 「ベストプラクティス」がないとどうなる? • どれか1つのアーキテクチャ特性の実現だけに特化するのではなく、競合する すべてのアーキテクチャ特性のバランスを取ること。 ◦

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

    技術 ドメイン 量子数 1(モノリス) 1以上 デプロイ容易性 ★ ★★★★ 弾力性 ★ ★★★★★ 進化性 ★ ★★★★★ 耐障害性 ★ ★★★★ モジュール性 ★ ★★★★★ 全体的なコスト ★★★★★ ★ パフォーマンス ★★ ★★ 信頼性 ★★★ ★★★★ スケーラビリティ ★ ★★★★★ シンプルさ ★★★★★ ★ テスト容易性 ★★ ★★★★
  9. © 2022 Leverages Inc. 転載・複製禁止
 戦略の階層化 ミッション/ビジョン 中長期目標 事業戦略 機能戦略 プログラム

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

    # 戦略 紐づくプログラム群 1 人材と企業データの可用情報充実化 レバテックID 新規情報取得(市場 /競合/顧客) 企業・案件情報の見直し アクティビティログ 2 アジリティ&スケーラビリティを担保するシ ステム基盤づくり BSD 統合マスタ JFのRDB化 オウンドリプレイス 3 労働集約を脱却するプロダクト開発 LTD LTP 4 営業OEを実現するSFAの構築 営業アナリティクス LTSF Salesforce RPA 5 業界最大データを活用した日本一のレコ メンドの実現 レコメンド精度向上PoC 営業現場へのレコメンド実装 プロダクトへのレコメンド実装
  11. © 2023 Levtech Department All Rights Reserved. コア要素『D-POS』のAsis-Tobe
 コア要素 Data

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

    Product Operation System Tobe • 構造化データ • DB/マスタの統合 • 高いデータ更新性 • 新規データの収集と活用 • プロダクト間をシームレスに • WEB+ネイティブアプリ • 認証/エントリーのUX向上 • 各プロダクトのUX向上 • 競争優位のコア以外は既製 • データと機械でOEを担保 • システム起点で業務を設計 • 千人規模の営業組織管理 要は何するべきか • データの収集と蓄積のあり方から 再設計したほうがいい • プロダクト間の役割とつながりを 再設計する • 各プロダクトの改善余地大きすぎ る(けど改善しづらい) • 既製SFAに合わせてオペレー ション再設計し、データと機械で 勝っていく • 上記Data/Product/Operation の理想を実現しうるシステムを設 計 • 変更容易性の高い設計 • システム負債を解消しやすい環 境/文化 • 速い開発速度
  13. | © Leverages inc. 27 『ソフトウェアアーキテクチャの基礎』 17章 マイクロサービスアーキテクチャ アーキテクチャ特性 評価(レイヤードアーキテクチャ) 評価(マイクロサービスアーキテクチャ) 分割タイプ

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

    技術 ドメイン 量子数 1(モノリス) 1以上 デプロイ容易性 ★ ★★★★ 弾力性 ★ ★★★★★ 進化性 ★ ★★★★★ 耐障害性 ★ ★★★★ モジュール性 ★ ★★★★★ 全体的なコスト ★★★★★ ★ パフォーマンス ★★ ★★ 信頼性 ★★★ ★★★★ スケーラビリティ ★ ★★★★★ シンプルさ ★★★★★ ★ テスト容易性 ★★ ★★★★
  15. | © Leverages inc. 33 • 事業成長にシステムが追いつくための課題 ◦ 相互依存する、複数の巨大モノリシックサービス ◦ 標準化の欠乏

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

    ◦ 自動化の欠乏 • 導入技術がどのように課題を解決するか ◦ マイクロサービス化とレイヤードアーキテクチャを主体とした分割統治 ◦ TypeScript、gRPC, GraphQLなど型システム技術導入によるチー ム間コミュニケーションの円滑化 ◦ CI/CD、コード生成、BDD/ATDDの活用による品質の担保 ◦ IaCによるインフラの既製化とDevOps推進 ◦ 便利さによる標準化の浸透 なぜ、マイクロサービスを選択したのか? マイクロサービス化を中心においた技術刷新とその狙い
  17. | © Leverages inc. 35 なぜ、マイクロサービスを選択したのか? • プログラムの設計において分割統治という考え方があります。大きな問題を 小さな問題に分割して、小さな問題をすべて解決することで全体を解決する という考え方です。 サービスのフロント、BFF、バックエンドの3層への分割、

    ビジネスドメインを再整理しドメインに分割しマイクロサービス化、一つのマイ クロサービス内でのレイヤードアーキテクチャによる分割を行っています。 • メリット ◦ プログラム変更の影響範囲が限定される ◦ 開発者が知る必要があるドメイン知識が減る ◦ ユニットテストが容易になる • 結果 ◦ 長期に渡り開発効率を高い状態で維持することが期待できる。 マイクロサービス化を中心においた技術刷新とその狙い
  18. | © Leverages inc. 40 マイクロサービスの特徴 レバテック 補足 独立デプロイ可能性 ❌ 完全な分離ができていないため、依存するサービスや

    システムが存在する。 ビジネスドメインに基づくモデル化 🔺 ビジネスドメインの分析不足により、ビジネス機能の凝 集度は高くない。 マイクロサービスごとの状態の所有 🔺 共有データベースを持っているサービスは少ない。 サイズ ー 柔軟性 ❌ むしろ、柔軟性が低下している。 アーキテクチャと組織の連携 ❌ ビジネスドメインに基づくモデル化ができていないため 組織も連携ができていない。 なぜ、ハッピーじゃないのか!?
  19. | © Leverages inc. 41 • 独立デプロイ可能性 ◦ 必要な機能がマイクロサービスに委譲されていない ◦ オーナーシップがマイクロサービス側に委譲されていない

    • ビジネスドメインに基づくモデル化 ◦ 各プロダクトが必要な機能だけをマイクロサービス化しただけにすぎない ◦ ビジネスドメインの分析が行えていないことにより、サービス境界が不安定 • 柔軟性 ◦ 上記2つの不十分なことで、柔軟性はむしろ低下してしまっている マイクロサービスになりきれていない
  20. | © Leverages inc. 43 • 大前提としてレバテックはまだマイクロサービスを実現できているわけではない ◦ マイクロサービスの特性を享受できているわけではない • アーキテクチャ特性からみてもレバテックと相性が悪いわけではない

    ◦ 今後、求められる「プロダクトの変更容易性」とも相性が良い • すべての機能をマイクロサービスに移行するのは膨大なコストがかかる ◦ リソースが潤沢というわけでもない ◦ 今のシステムの改修・運用・保守も存在する マイクロサービスが良くないというわけではない
  21. | © Leverages inc. 44 • 大きな問題を小さな問題に分割して、小さな問題を解決することで全体を解決する ◦ ビッグバンリリースにもならないためにも大事な思考 ◦ 大きな問題を解決するには時間とコストもかかり、リスクも大きい

    • そのために必要なのは「選択と集中」 ◦ 大きな問題を小さな問題に分割して、緊急度と重要度が高いものから解決する 分割統治による進め方は重要な思考である
  22. | © Leverages inc. 47 • マイクロサービスに移行できるならそれが一番理想に近いとは思う ◦ アーキテクチャ特性からみてもレバテックと相性が良い • 「全体的なコスト」と「シンプルさ」は捨てきれない

    ◦ システムが増えるとリソース不足になってしまう ◦ 「シンプルさ」を捨ててしまうと、システムの複雑性が上がってしまう ▪ さらに人を増やしづらくなってしまう要因にもなり得る • マイクロサービスの良いところだけを享受できないか? ◦ 「分割統治」「ビジネスドメインに基づくモデル化」「アーキテクチャと組織の連携」 やっぱり、マイクロサービスが良いのか!?
  23. | © Leverages inc. 48 • 「分割統治」 ◦ 大きな問題を小さな問題に分割して、小さな問題を解決することで全体を解決する • 「ビジネスドメインに基づくモデル化」

    ◦ ビジネスドメインの分析して、ビジネス機能の凝集度を高くする • 「アーキテクチャと組織の連携」 ◦ 価値のある単一の仕事のストリームに沿って働く マイクロサービスの良いところだけを享受できないか?
  24. | © Leverages inc. 49 • 当たり前ですが、全部を理想形にするのは難しい ◦ 「選択と集中」を行い、緊急度と重要度が高いものから行う • 緊急度と重要度が高いもの

    ◦ 経営・事業戦略から紐づく目標 ▪ 保有案件数の最大化 ▪ SQL化率(カテゴリ回収~面談実施)の向上 ▪ etc.. ◦ つまり、コアドメインにあたるものは理想形に近づけていきたい • 緊急度と重要度が低いもの ◦ 基本的には後回し ◦ 外部ツールに置き換えてしまうのも1つの手段 部分的に理想形に近づけていきたい
  25. | © Leverages inc. 50 • コアドメインとなるものを理想形に近づける ◦ どこから「分割統治」を行うべきかを戦略に基づいて決定 ▪ そこに合わせて「ビジネスドメインに基づくモデル化」を行う

    • これらを実現するため「アーキテクチャと組織の連携」ができる組織作り • 理想形に近づいているかを評価するための仕組み作り ◦ プロダクトの変更容易性を向上させるために必要な6つの特性 ▪ 「デプロイ容易性」「耐障害性」「モジュール性」「信頼性」「スケーラビリティ」「テ スト容易性」 ◦ これら6つを評価できる仕組みの構築 ▪ ”Four Keys”も上記を評価するための一部としたい 今後、レバテックでやるべきこと(と考えていること)
  26. | © Leverages inc. 52 • マイクロサービスとレバテックに求められるアーキテクチャ特性の相性が良い ◦ 価値のある単一の仕事のストリームに沿って働くシステム(チーム)を構築 • 今のレバテックはマイクロサービスの特性を享受できているわけではない

    ◦ 本来のマイクロサービスになりきれていないため • マイクロサービスの良いところだけを享受していきたい ◦ 「分割統治」「ビジネスドメインに基づくモデル化」「アーキテクチャと組織の連携」 • 今後、レバテックでやるべきこと(と考えていること) ◦ コアドメインとなるものを理想形に近づける ◦ 理想形に近づいているかを評価するための仕組み作り まとめ