マイクロサービス化に向けて

by HIRA

Slide 1

Slide 1 text

マイクロサービス化に向けて 2019.5.30 クラウド・マイクロサービス勉強会（第１回）

Slide 2

Slide 2 text

自己紹介平田憲司主な担当：アーキテクチャ設計、基盤構築

Slide 3

Slide 3 text

アジェンダ 1. はじめに 2. マイクロサービス概要 3. マイクロサービス化へのアプローチ 4. マイクロサービス化における考慮点

Slide 4

Slide 4 text

はじめに Sam Newman(2017)『マイクロサービスアーキテクチャ』オライリージャパンその他・AWSにおけるマイクロサービス・日経SYSTEMS「マイクロサービスの現実解」2017年9月号・鈴木雄介『マイクロサービス化設計入門 -AWS Dev Day Tokyo 2017」・広木大地『エンジニアリング組織論への招待』参考文献

Slide 5

Slide 5 text

アジェンダ 1. はじめに 2.マイクロサービス概要 3. マイクロサービス化へのアプローチ 4. マイクロサービス化における考慮点

Slide 6

Slide 6 text

マイクロサービス概要 • マイクロサービスとは • マイクロサービスの特徴 • モノリシックの課題 • マイクロサービスの狙い

Slide 7

Slide 7 text

マイクロサービスとは ThougthWorks社のマーチン・ファウラーとジェームス・ルイスが提唱したソフトウェアアーキテクチャ。迅速なリリース、優れた回復性やスケーラビリティを実現するためビジネス機能に沿ってサービス分割する設計思想。

Slide 8

Slide 8 text

マイクロサービスとはモノリシックアプリケーション A B C A・B・C モノリシックアーキテクチャとマイクロサービスマイクロサービスアプリケーション A A アプリケーション B B アプリケーション C C データベースデータベース

Slide 9

Slide 9 text

マイクロサービスの特徴サービスの単位境界付けられたコンテキスト（ドメイン）が、ひとつのサービスビジネスドメインを起点にサービスをモデリングする場合、DDD（ドメイン駆動設計）により境界を決定する。ユーザー情報認証分析受注管理出荷管理在庫管理

Slide 10

Slide 10 text

自律しておりデプロイが容易サービス間の依存が少なく、変更が他のサービスへ影響しない。リリースの影響とリスクが小さく、迅速なデプロイが可能。マイクロサービスの特徴 A B 改修影響しない

Slide 11

Slide 11 text

技術選択の自由サービスごとに適切な技術を採用できる。他のサービスの技術事情に影響されることがない。マイクロサービスの特徴 A B Java（Spring） C#（ASP.NET) 技術制約・要件が他サービスへ影響しない MySQL Oracle

Slide 12

Slide 12 text

〇〇システムシステム全体の可用性が高いあるサービスが停止しても、他のサービスは停止せずサービスの提供ができる停止したサービスを切り離すことができ、システム全体を継続して稼働できる。マイクロサービスの特徴 A B 障害稼働稼働

Slide 13

Slide 13 text

スケーリングの自由サービス単位でスケーリングが可能であり、特定のサービスのみを必要な分だけ負荷分散できる。マイクロサービスの特徴 A B サーバサーバサーバサーバ

Slide 14

Slide 14 text

自律的なチームサービスの所有権を持ったチームによって開発・維持される。採用する技術や開発手法などチームが決定する。マイクロサービスの特徴本番環境でのサービスの運用と保守に対しても責任を負う。（DevOps)

Slide 15

Slide 15 text

機能の再利用性が高いサービス間が疎結合であるため、サービスの機能を様々なサービスへ提供できる。マイクロサービスの特徴 A B D C

Slide 16

Slide 16 text

簡単に交換可能破棄・生成が容易であり、置き換えコストが小さい。（２週間程度で作り直せる大きさ）置き換えが容易であるため、必要に応じて書き直しができレガシー化を抑制できる。マイクロサービスの特徴サービスサービス 2週間程度で作り直せる

Slide 17

Slide 17 text

モノリシックの課題リリース時の工数が大きいシステムが巨大（一枚岩）であることからリリース対象が大きいため、一部の変更でも全体への影響度が大きくリリースのリスクが高くなる。影響調査や開発・リグレッションテストの工数が大きくなる

Slide 18

Slide 18 text

モノリシックの課題ビジネス環境の変化に素早く対応できない障害発生時の影響度が大きいことや機能の再利用性が低いためリリース頻度が低くなり、ユーザーへ価値を届けることが遅くなる。

Slide 19

Slide 19 text

モノリシックの課題障害の影響度が大きいアプリケーション A B C １つのサービスに障害が発生するとシステム全体が停止する。

Slide 20

Slide 20 text

モノリシックの課題機能の再利用性が低い機能間が密結合状態であり、強い依存関係を持っているため他機能から利用できない A B C 密結合

Slide 21

Slide 21 text

マイクロサービスの狙いリリース速度向上システムを小さなサービスに分割し疎結合で運用することで、変更時の影響範囲を小さくできる。影響調査やリグレッションテストの削減ができる。障害リスクも低い。リリース頻度が向上し、ユーザーに素早く価値を提供できる。

Slide 22

Slide 22 text

メリット・デメリットのまとめマイクロサービスモノリシックメリット・運用後の開発が容易・サービスごとに適切な技術を採用できる・必要に応じて一部のサービスの差し替え（作り直し）が可能・一部の障害が全体に影響しない・開発の初期コストが低い・技術が統一されており学習コストが低く、生産性が高くなる・ボトルネックを見つけやすいデメリット・開発の初期コストが高い（特にインフラコスト）・サービスをまたがる改修のコストが高い・ボトルネックを見つけにくい・技術的負債がたまりやすく、作り直しが困難・チームが大きいためコミュニケーションコストが高い・運用後、開発速度が低下していくシステム導入を目的とした場合モノリシックの方がメリットが大きい一方、運用後のリリースサイクルの高速化を目的とした場合マイクロサービスのメリットが大きい

Slide 23

Slide 23 text

アジェンダ 1. はじめに 2. マイクロサービス概要 3.マイクロサービス化へのアプローチ 4. マイクロサービス化における考慮点

Slide 24

Slide 24 text

マイクロサービス化へのアプローチサービスのモデル化疎結合システムの他の部分を変更する必要なしに、あるサービスを変更してデプロイできる。あるサービスを変更しても別のサービスを変更する必要がない。高凝集性関連する振る舞いを一緒にして、関連のない振る舞いは別の場所に配置する。リリース時に関連のない振る舞いを同時にリリースする必要がなくなる。

Slide 25

Slide 25 text

マイクロサービス化へのアプローチサービスのモデル化コンテキストの境界特定のモデルを定義・適用する境界を明示的に示したもの。 EricEvansのDomain-Driven-Design（ドメイン駆動設計）のドメインのモデル化。境界の検出に役立つ。コンテキストの境界を見極めるのは難しい。はじめはモノリシックではじめドメインの理解ができるようになった段階でマイクロサービスとして分離させる。

Slide 26

Slide 26 text

マイクロサービス化へのアプローチサービスのモデル化コンテキストの例受注出荷在庫生産計画販売コンテキスト売上生産コンテキスト請求生産技術工程大きさによって更に分解していく

Slide 27

Slide 27 text

マイクロサービス化へのアプローチ統合サービス間の連携方法がマイクロサービスにおいて最も重要 • APIを技術非依存にする • データベース共有しない • オーケストレーションとコレオグラフィを選択 • フロント向けのバックエンドを用意

Slide 28

Slide 28 text

マイクロサービス化へのアプローチ APIを技術非依存にするサービスごとの技術スタックを自由にするため、サービス提供側の技術事情が利用側に影響しないようにする。 RPC（リモートプロシージャコール）ではなく、RESTによるHTTP通信にする。 HTTP通信であればクライアントとAPI側の技術に左右されない。

Slide 29

Slide 29 text

マイクロサービス化へのアプローチ機能機能 DB DB ファイルデータ共有/ETL連携 DB DB API連携機能機能 http CSVなど例えば、ファイル連携をAPIによる連携へ

Slide 30

Slide 30 text

マイクロサービス化へのアプローチデータベース共有しないデータベースを共有すると疎結合と高凝集性を失う。サービス間でのデータ共有が容易だが、サービスロジックの変更に伴いスキーマ定義情報の変更が必要になった際は、他機能への影響が大きい。〇〇マスタ Aサービス Bサービス Cサービス変更変更

Slide 31

Slide 31 text

マイクロサービス化へのアプローチオーケストレーションよりもコレオグラフィを選択オーケストレーションでは同期処理になってしまう。時間のかかる非同期処理ではコレオグラフィ手法を採用する。イベントを各サービスがサブスクライブする。（AWSなどのクラウドサービスではイベントをサブスクライブする形式が主流）

Slide 32

Slide 32 text

マイクロサービス化へのアプローチオーケストレーションアカウントサービス認証サービス認可サービスメールサービス１つの処理が複数の処理を実行。同期処理となる。認可情報作成認証情報追加ようこそメールを送信 ECサイトへのアカウント登録の例

Slide 33

Slide 33 text

マイクロサービス化へのアプローチコレオグラフィアカウント作成イベント認証サービス認可サービスメールサービス時間のかかる非同期処理ではコレオグラフィ手法を採用する。サブスクライブイベントを各サービスがサブスクライブする。アカウントサービスパブリッシュ MQなど

Slide 34

Slide 34 text

マイクロサービス化へのアプローチフロント向けのバックエンド１つのAPIゲートウェイを使ったサービス呼び出しでなく、各フロント向けのバックエンドを用意してサービス呼び出しを行う。

Slide 35

Slide 35 text

マイクロサービス化へのアプローチ APIゲートウェイに全てのリクエストを任せた場合１つのAPIゲートウェイを使ったサービス呼び出しの場合、処理の制御がゲートウェイに集中。あるクライアントの変更が全体に影響してしまう。 APIゲートウェイ API API API IOS アプリ Android アプリ WEB アプリ

Slide 36

Slide 36 text

マイクロサービス化へのアプローチフロント向けのバックエンドを用意した場合各フロント向けのバックエンドを用意してサービス呼び出しを行う。 iOS バックエンド API API API Android バックエンド Webアプリバックエンド IOS アプリ Android アプリ WEB アプリフロント事情を各バックエンドが吸収し、変更が他フロントに影響しないようにする

Slide 37

Slide 37 text

マイクロサービス化へのアプローチレガシーアーキテクチャへの処方箋腐敗防止層腐敗防止層の設置で新アーキテクチャとの通信を可能にするレガシーアーキテクチャ新アーキテクチャレガシー内部を書き換えずに通信できるようにI/Fを用意

Slide 38

Slide 38 text

マイクロサービス化へのアプローチモノリスの分割データベースアクセス DB 受注出荷売上請求リポジトリリポジトリリポジトリリポジトリアプリケーションフレームのリポジトリレイヤを活用して、データベースアクセスを分割。外部参照が必要な場合は、別リポジトリを経由して取得する。

Slide 39

Slide 39 text

マイクロサービス化へのアプローチモノリスの分割データベースリファクタリング段階的な分割モノリシックサービスモノリシックスキーマ A B モノリシックサービス A B A スキーマ B スキーマ A サービス B サービス A スキーマ B スキーマ単一スキーマスキーマを分割アプリをサービスに分割

Slide 40

Slide 40 text

マイクロサービス化へのアプローチモノリシックサービス A B A スキーマ B スキーマモノリスの分割複数のトランザクションへの対応個別のトランザクション境界一貫性が必要となる処理で複数のトランザクションが発生し、一方が失敗した場合の対処リトライ失敗した処理をリトライできるようMQ（キューイング）を利用。リトライにより処理を完了させる。結果整合性不整合な状態から最終的に整合性がとれる状態にすること。分散トランザクションの制御は非常に困難。結果整合性を受け入れる必要がある。

Slide 41

Slide 41 text

マイクロサービス化へのアプローチコンウェイの法則システムを設計する組織は、その構造をそっくりまねた構造の設計を生み出す。コンウェイの法則とは？アーキテクチャ組織設計がアーキテクチャへ影響

Slide 42

Slide 42 text

マイクロサービス化へのアプローチ逆コンウェイ理想アーキテクチャ理想とするアーキテクチャ像を元に、組織設計（チーム）を作る。マイクロサービスを構築する場合、サービスのチームは自ずと小さくなるコンウェイの法則

Slide 43

Slide 43 text

マイクロサービス化へのアプローチ Amazon「two-pizza-teams」 2枚のピザで足りる人数でチームを構成するルール。人数が多いとコミュニケーションコストが増大する。エンジニアだけでなく、Amazon社内のあらゆるチームに適用されているルール。コンウェイの法則

Slide 44

Slide 44 text

マイクロサービス化へのアプローチチームを小さくして権限を委譲した場合の利点 • チームが小さいとコミュニケーションコスト（オーバヘッド）が小さくなり、コミュニケーション頻度が向上する • サービスを所有すると責任感が生まれ自律性とデリバリの速度が向上する • チーム構造が技術境界に沿わない。メンバー全員が全てのレイヤを担当チームがデプロイ・保守の責任を負うとデプロイしやすいサービスを作ろうとするため、結果サービスの保守性が向上する。DevOpsの文化が生まれる。アプリ・DB・インフラというような技術ドメインでなくビジネスドメインに合わせてチームができると顧客中心の姿勢を維持でき、サービスに関連するすべての技術を全体的に理解して所有するため、より多くの機能開発をやり遂げることができる。コンウェイの法則

Slide 45

Slide 45 text

アジェンダ 1. はじめに 2. マイクロサービス概要 3. マイクロサービス化へのアプローチ 4.マイクロサービス化における考慮点

Slide 46

Slide 46 text

マイクロサービス化における考慮点進化的アーキテクチャを受け入れるビッグバン型の書き直しでなく、システムを徐々に変更していって柔軟性を保つ。部分的にマイクロサービス化していく。

Slide 47

Slide 47 text

マイクロサービス化における考慮点マイクロサービスを使用するべきではない場合サービスのコンテキストが見つけられない。サービスの境界を定義できていない内は採用しない。新規開発時に定義できない場合は、モノリスから始め、徐々に分割を検討する。

Slide 48

Slide 48 text

マイクロサービス化における考慮点サービス間連携による性能問題サービスを連携して処理を進めるため、サービスの呼び出し、プロセスの起動、サービス間通信のレイテンシーといった問題により性能劣化が起こる。いかに連携のオーバヘッドを無くすかが課題。

Slide 49

Slide 49 text

理論は分かった。で、実際どうなんだ！？すいません。これから実践してく中で知見を増やし、経験を元に課題や解決のアプローチをより現実的な方法で今後お伝えしていきたいと思います。みなさんも情報共有お願いします。

Slide 50

Slide 50 text

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