本記事の位置づけ
下記書籍を用いた輪読会の資料として作成しています。
https://amzn.asia/d/bC6DhKi
今回の対象範囲は、下記のとおりです。
I.Foundation and Building Blocks > 3.Designing Good Data Architecture >
Major Architecture Concepts > Tight Versus Loose Coupling:Tiers, Monoliths, and Microservices
概要
- Monolith = tightly coupled, Microservices = loose coupled
- Microservicesがおすすめだけど、Monolithの方がプロトタイプ作るのは向いている。
本編
Data architectureの種類
- tightly coupled：相互に依存している "centralized,中央集権化されている"
- loose coupling：お互いに強く依存していない"decentralized,中央集権化されていない"
- common standards, ownership, 責任、説明可能性を設定(assign)することが大切。
Architecture tiers
Architectureとはデータ、アプリケーションなどの層のこと。理解することが大切。
- Single tier : データベースとアプリが強く結合されている(tightly coupled)
- databaseなどが落ちればすべてが落ちる。
- プロトタイプには向いているが、本番環境には向いていない。
- Multitier : n-tierともいう
- 層が独立している。
- lower layerはupper layerに依存しないが、upper layerはbottom layerに依存する。
- e.g. three-tier-architecture
- リソースの競合がなくなる。
- shared-nothing architecture : 一つ一つのリクエストを一つのnodeが担当。リソースを共有しない。
- shared disk architecture :同じdisk,メモリに全てのnodeがアクセスする。
Monolith
- 一つのcodebase,一つのマシンでアプリとUIを提供する
- Technical coupling : Architecture tiersを指す
- Domain coupling : ドメインの結合方法を指す
- tight couplingはモジュール化の不足を伴う。コンポーネントの再利用が難しいor不可能になる。
- データチームは複雑化するMonolithを解決することを無視し、大きな泥の塊（big ball of mud）してしまう。
- chap4でmonotlith/distributed technologiesの議論をする。またdistribuetd monolithもある
- (感想)Monolith = tightly coupled. distribuetd monolithは両刀使い？
Microservices
- Monolithの反対
- Microservicesは、分かれていて、一元化されておらず、loosely coupledである。
- それぞれのサービスは特定のfunctionがあり、それぞれ結合していない。
- Monolithを分解できない場合は、並行してmicroservices-friendly のarchitectureを作り始めましょう。
- Monolithを分解する場合は、ステークホルダーからも賛同を得ましょう。
Considerations for data architecture
- 理想としては、現実に合う（pragmatically）loose couplingを使いましょう。ただし限界などを認識しましょう。
- モジュール化、loose couplingするようなreversible technologyも選択しましょう。
- Single vs Multitiered : domainをどうやってarchitectureから分けるか検討しましょう。
- centralization : 一つにすべてのドメインのデータを集約
- data mesh: それぞれのソフトウェアチームがデータの準備に責任がある。
- Monolithは必ずしも悪いわけではない。早く実装したいならMonotlithの方が簡単だが、次第に分けていくことも踏まえておいてね。
英語で困ったこと
英訳で困った
- keeping them agnostic of data (kindle P159周辺)
- "データに関係なく"
- Schema on write, Schema on read - Monolith 一枚岩？
- ";"の役割 e.g.Monolithの1文目
技術面で困った
- Figure3-5下、build in redundancy(冗長性)とは具体的にどのような状況？またその後"For instance~"の例もあまりイメージ的なかった
- function, domain, tier, layerのそれぞれの違いは？（domainの例として、sales,inventoryと記載がある）
- tierとlayerは同じでは。DatabaseやFunctionの単位のこと。