Upgrade to PRO for Only $50/Year—Limited-Time Offer! 🔥

Lecture course on Microservices : Part 2

Avatar for Etsuji Nakai Etsuji Nakai
February 06, 2024

Lecture course on Microservices : Part 2

Avatar for Etsuji Nakai

Etsuji Nakai

February 06, 2024
Tweet

More Decks by Etsuji Nakai

Other Decks in Technology

Transcript

  1. 倉化に远埓するための基本原則 • 倉曎芁求に察する凝瞮床を䞊げるこずが「モゞュヌル化」の基本 ◩ 倉曎する理由が同じものは集める → 単䞀のモゞュヌルだけを考えればよい ◩ 倉曎する理由が異なるものは分離する →

    想定倖の圱響を心配しなくおよい • 開発者の認知胜力を超えた連鎖的倉曎を防止。「容易に理解できる」範囲の倉曎 は生産性が高い 4 単䞀責任の原則 ↓ クラスを倉曎する理由は1぀以䞊存圚しおはならない 䞀蚀で蚀うず 「関係あるものはたずめる」 「関係ないものは分ける」
  2. マむクロサヌビスずビゞネス芁件の察応䟋 6 Order service Stock transaction service Fee service Market

    service 売华リク゚ストを受け付けお 倖郚システムに送信する 手数料を 匕き萜ずす 売华察象の株匏 を確保する 売华リク゚スト の情報を蚘録 売华リク゚ストを倖郚 システムに送信
  3. 必芁な機胜をサヌビスに分割する方法 • 実際には次のような方針もあわせお怜蚎する ◩ ビゞネス芁件倧たかに関連するビゞネス機胜の領域ごずにサヌビスを分割する ◩ ナヌスケヌスナヌスケヌスワヌクフロヌの䞭で実行される「アクション」をサヌ ビスずしお実装する ◩ 倉曎可胜性将来倉曎される郚分に぀いお、倉曎の単䜍ごずにサヌビスずしおたずめる

    ◩ 技術芁件実装が特定の技術に䟝存する堎合、ビゞネス芁件ずは関係なく技術芁件のみ が倉化する可胜性がある堎合など ◩ セキュリティ芁件PCI DSS 準拠が求められるサヌビスを分割するなど 7
  4. 新しい機胜を远加する䟋で考える • 「投資戊略」機胜を远加したい ◩ ナヌザヌは、事前に定矩された「投資戊 略」を遞択しお投資ができる ◩ 投資戊略ずは、耇数の投資察象資産ア セットを集めお、投資割合をアサむン したもの

    • 想定されるナヌスケヌスは右図の通り ◩ 「管理者に提䟛する機胜」ず「゚ンド ナヌザヌに提䟛する機胜」の぀のビゞ ネス芁件Business capabilityがある 8 「投資戊略」を定矩 「資産」を遞択 「投資戊略」を遞択 投資を実行 「投資戊略」に埓っお 「資産」を賌入 管理者 ゚ンド ナヌザヌ
  5. 「投資戊略」管理機胜の蚭蚈 • この「Business capability」を1぀の Strategy サヌビスずしお実装する 9 「投資戊略」を定矩 「資産」を遞択 管理者

    管理者に提䟛する機胜 管理者は「投資戊略」の 定矩を䜜成・倉曎できる ABC ・・・・ Code Search 20% DEF ・・・・ 10% Current Total30% Code Description    ratio UserAsset manager 1 Cancel Save ・・・・・ Strategy name 管理画面の モックむメヌゞ
  6. 「投資戊略」管理機胜の蚭蚈 • Strategy サヌビスの API は、「投資戊 略」の䜜成ず取埗機胜を提䟛 • 管理画面むメヌゞからナヌスケヌスを想 像するず、この他に「ナヌザヌ管理サヌ

    ビス」ず、「アセット管理サヌビス」が 必芁ずわかる 10 Strategy service Create strategy Get strategy API ゚ンドポむント むベント Strategy created Get user User service Asset service Get asset Search asset
  7. 支払い凊理ずの連携 • 支払い凊理を行う Payment service を別に甚意した堎合、 右図のようなナヌスケヌスが考 えられる • Strategy

    order service は、投 資のリク゚ストを受け付けた 埌、支払い凊理の完了を埅っお から、実際の発泚を行う 12 Strategy investment Create payment Confirm Payment details Payment completed Get strategies Client Strategy order service Payment service Strategy service Strategies Create orders Save request Process payment 耇数のアクション が混圚しおいる
  8. 投資リク゚ストサヌビスの分離 • 実際のずころ、投資のリク゚ストは既存のナヌスケヌスに存圚するので、 Strategy Order から分離しお再利甚するべき • Order service は、「API

    の呌び出し元が誰であるか」には䟝存しない実装が必芁 → サヌビスの自立性 14 Order service Create order Strategy order service 投資リク゚ストの情報 ラむフサむクルを管理
  9. 参考Orchestration ず Choreography の察比 • クリヌンアヌキテクチャヌの芳点では、ビゞネスプロセスずは、「䞀定のルヌルにした がっお゚ンティティの状態倉化を匕き起こすプロセス」であり、個々の状態倉化のロゞッ クはサヌビス内郚に隠蔜されおいる • 他のサヌビスを含めたプロセス党䜓を理解した「ワヌクフロヌマネヌゞャヌ」が存圚する

    のが Orchestration パタヌンで、プロセスの党䜓を意識しないサヌビス矀がむベントフ ロヌで自立連携するのが Choreography パタヌンず理解できる 16 Service A Service B Service C Service D API リク゚スト リク゚スト Service A Service B Service C Service D API リク゚スト むベント Orchestration パタヌン Choreography パタヌン
  10. 参考モゞュヌル分割の考え方 • モゞュヌル分割は、次の3぀の芁求の「せめぎ合い」にさらされおいる (1) 倉曎するモゞュヌルを枛らしたい関係あるものはたずめる   → ビゞネス芁件からのマッピング ◩ たずめすぎるず (2)

    に矛盟する (2) 無関係な倉曎を枛らしたい関係ないものは分ける   → 倉曎可胜性からのマッピング ◩ あらゆる可胜性を予芋するこずは䞍可胜 (3) 再利甚性を高めたい → 共通の技術芁件を切り出しおたずめる ◩ 切り出しすぎるず (1) に矛盟する 22 ここのバランスを重芖 するのがマむクロ サヌビスの考え方 ここにフォヌカス したのが SOA
  11. 新芏アプリケヌションの初期デザむン • ビゞネス課題の理解ずビゞネス芁件の決定には、 ビゞネス知識に基づいた深い分析が必芁 • サヌビスを分割すべきか刀断が぀かない堎合は、 はじめは぀のサヌビスにたずめおおく ◩ 将来の分割に備えお、コヌドのモゞュヌルやデヌ タ構造はビゞネス芁件に応じおできるだけ事前に

    分割しおおく • ビゞネス芁件の倉化に䌎う機胜远加の際は、「単 䞀責任の原則」を砎らないよう、必芁に応じお サヌビスの分割を怜蚎する 23 Micro service API 既存の API に フィヌルドを远加 API 既存のサヌビスに API を远加 Micro service API 新しいマむクロ サヌビスを远加 機胜远加のパタヌン
  12. 移行を考えた API 蚭蚈 • API 蚭蚈では、内郚構造を隠蔜しお「倖 郚に芋せる必芁のあるデヌタ」のみを公 開する ◩ 必芁最䜎限の機胜を公開するこず

    • 「倖郚」にもいく぀かのレベルがある事 に泚意が必芁 ◩ ゚ンドナヌザヌに芋せる情報 ◩ 管理者に芋せる情報 ◩ 他のサブシステムに芋せる情報 ◩ 同じサブシステム内のサヌビスに芋 せる情報 25 Get asset Search asset Asset service Risk assessment Classification 倖郚 API 内郚 API 同じサブシステム内の サヌビスにのみ公開 他のサブシステム にも公開
  13. マむクロサヌビスの具䜓䟋オンラむン投資サヌビス 27 • ナヌザヌが、株の売华リク゚ストを 出した堎合の凊理の流れ サヌビス手数料を 蚈算・匕き萜ずし Order service A

    瀟の株を 100 株売华 Stock transaction service 売华リク゚ストの 情報を蚘録 Order database Transaction database Fee service Fee rules database Market service Stock exchange 売华リク゚ストを 倖郚システムに送信 売华察象の株を ロック
  14. 29 同期凊理による Orchestration パタヌン • Order service はプロセス に含たれるすべおのサヌビ スを理解する必芁がある

    • プロセスに含たれる凊理が 倉わるごずに、Order service に倉曎が必芁 Create order Confirm reservation Charge fee Client Order service Stock transaction service Fee service Reserve stock Market service Confirm charge Place order Confirm place order Confirm order
  15. 33 Compensating アクションの導入 • Saga パタヌンでは、プロセスに含たれるそれぞれの凊理に察しお、それを取り消す Compensating アクションを甚意しおおく サヌビス アクション

    Compensating アクション Order A1: Create order C1: Cancel order A2: Update status (placed) C2: Update status (cancelled) Stock transaction A3: Reserve stock C3: Release stock Fee A4: Charge fee C4: Refund fee Market A5: Place order C5: Cancel order Order service Stock transaction service Fee service Market service Order created A1 Stock reserved Fee charged Order placed A3 A4 A5 A2
  16. 34 Compensating アクションの導入 • 各サヌビスは、「倱敗むベント」をトリガヌにし お、必芁に応じお Compensating アクションを実行 ◩ 䟋えば、トランザクションごずにナニヌクな

    ID を発行しお、各サヌビスは ID ごずに実行した アクションをデヌタベヌスに蚘録しおおく • 各サヌビスは自埋的に動䜜するため、あらゆる凊理 パタヌンにおいお、意図通りのロヌルバックが行わ れるこずを事前怜蚌するのは倧倉 • トレヌシングの仕組みを導入しお、゚ラヌ発生時の 動䜜を再珟・確認できるようにするこずが必芁  すべおのアクションを ID ず共にログに蚘録しお おく Order service Market service Order failed C1, C2 Stock transaction service Fee service C3 C4
  17. ワヌクフロヌマネヌゞャヌによるオヌケストレヌション 35 • 自埋分散プロセスではなく、ワヌクフロヌ マネヌゞャヌを導入しお、プロセスの流れ をトラッキングする方法もある。 サヌビス手数料を 蚈算・匕き萜ずし Order service

    A 瀟の株を 100 株売华 Stock transaction service 売华リク゚ストの 情報を蚘録 Order database Transaction database Fee service Fee rules database Market service Stock exchange 売华リク゚ストを 倖郚システムに送信 売华察象の株を ロック ワヌクフロヌ マネヌゞャヌ 事前に定矩した ワヌクフロヌを実行
  18. 36 Orchestrated saga • 䟋倖ケヌスを含めお、すべおのプロセス をワヌクフロヌマネヌゞャヌのゞョブず しお実装する • ワヌクフロヌマネヌゞャヌのログから、 実際のプロセスの流れが確認できるの

    で、゚ラヌ発生時の確認が容易になる Stock transaction service Fee service Market service A1: Create order A3: Reserve stock A4: Charge fee A5: Place order C3: Release stock C4: Refund fee C2: Update status (cancelled) Failed Saga log ワヌクフロヌ マネヌゞャヌ
  19. 37 Orchestrated saga • ロヌルバック甚の「Compensating トランザ クション」を別のゞョブずしお定矩する方法 もある • 正垞系のゞョブで䟋倖が発生したら、

    Compensating トランザクションを実行す る。この際、ロヌルバック察象のトランザク ションを特定する ID を指定しお実行する。 • Compensating トランザクションは、各サヌ ビスの察象ゞョブに察する凊理状況をチェッ クしお、必芁に応じお Compensating アク ションを実行する A1: Create order A3: Reserve stock A4: Charge fee A5: Place order Compensating トラ ンザクションを実行 Failed ワヌクフロヌ マネヌゞャヌ C3: Release stock C4: Refund fee C2: Update status (cancelled) Compensating トランザクション
  20. 38 Compensating アクションが倱敗した時は • Compensating アクションを含む個々のアクションは、単䞀のサヌビス内で実行されるもの なので、バック゚ンドデヌタベヌスのトランザクション機胜を利甚できる点に泚意 ◩ システム゚ラヌに察しおは、必芁に応じおロヌルバックリトラむを実行すればよい •

    それでも Compensating アクションが実行できない状況に぀いおは、察応するビゞネスプ ロセスを蚭蚈する ◩ 䟋ナヌザヌぞの Refund ができない堎合 → 手䜜業での返金プロセスを回すために、ナヌザヌず関連郚門にその旚の通知を出す ◩ 通知にも倱敗したら → オペレヌタヌにアラヌトを䞊げる、など
  21. 39 Saga の同時実行に䌎う問題 • 通垞のトランザクションず異なり、 Saga では凊理䞭の状態デヌタが 倖郚に芋える同期・非同期にかか わらず発生する問題 •

    特に、耇数の Saga が同䞀のデヌタ を倉曎する堎合の察凊が必芁 • 図は、売华リク゚ストの Saga 実行 䞭に、リク゚ストのキャンセルが発 行されおキャンセル凊理の Saga が 同時に実行される䟋 Order service A1: Create order A3: Reserve stock A4: Charge fee A5: Place order Stock transaction service Fee service Market service C3: Release stock C4: Refund fee C2: Update status (cancelled) 売华 リク゚スト リク゚スト キャンセル 
  22. 40 Saga の同時実行ぞの察応方法 • コヌヒヌショップの䟋のように、珟実の業務フロヌを想定しお察応方法を考えるずよい • Short-circuitingOrder サヌビスは、「凊理䞭」ステヌタスのオヌダヌに぀いおは、キャ ンセルリク゚ストを受け付けない •

    InterruptionOrder サヌビスは、「凊理䞭」ステヌタスのオヌダヌを「キャンセル受付枈 み」ステヌタスに倉曎しお、キャンセルリク゚ストに Ack を返す ◩ その埌、オヌダヌ凊理の Saga が完了しお、オヌダヌのステヌタスを「完了枈」に倉曎 するタむミングで、キャンセル受付枈であれば、あらためおキャンセル凊理の Saga を 実行する。オヌダヌ凊理に関䞎するサヌビスは、オヌダヌのステヌタスをチェックし お「キャンセル受付枈み」であれば、凊理を䞭止しおもよい
  23. 41 トランザクションの実装パタヌンたずめ • ACID 特性を持ったトランザクションを単䞀のサヌビス内で閉じお実行する ◩ 最もシンプルで実装が容易 ◩ サヌビスの粒床が倧きくなり「単䞀責任の原則」を満たしにくくなる •

    ワヌクフロヌマネヌゞャヌゞョブ管理ツヌルを甚いたオヌケストレヌション ◩ ロヌルバックの手順をゞョブフロヌの䞀郚ずしお実装する必芁がある ◩ トランザクションの途䞭経過が倖郚に芋えるAtomicity が担保されない • サヌビスコリオグラフィヌによる非同期連携 ◩ 「マむクロサヌビスの思想」に最も合った実装方法 ◩ 実行パタヌンが耇雑になり、問題発生時の察応が難しい ACID 特性の重芁性 高 䜎 マむクロサヌビスのメリット 䜎 高
  24. 42 トランザクションの実装パタヌン論理的な分類 オヌケストレヌタヌ を䜿甚するか サヌビス間の通信方法 同期/非同期 クラむアントから 芋た同期性 コメント Phone

    Tag Saga 䜿甚しない 同期通信 同期凊理 Order Service がオヌケス トレヌタヌになる最初の䟋 Epic Saga 䜿甚する 同期通信 同期凊理 䞊の䟋に倖郚のワヌクフ ロヌマネヌゞャヌを远加 Anthology Saga 䜿甚しない 非同期通信 非同期凊理 むベントベヌスの 完党な非同期凊理 Time Travel Saga 䜿甚しない 同期通信 非同期凊理 クラむアントを埅たせない ように実装を倉曎 Fairy Tale Saga 䜿甚する 同期通信 非同期凊理 クラむアントを埅たせない ように実装を倉曎
  25. 43 トランザクションの実装パタヌン論理的な分類 オヌケストレヌタヌ を䜿甚するか サヌビス間の通信方法 同期/非同期 クラむアントから 芋た同期性 コメント Fantasy

    Fiction Saga 䜿甚する 非同期通信 同期凊理 非同期凊理に察応した オヌケストレヌタヌを 甚いる特殊な実装 Parallel Saga 䜿甚する 非同期通信 非同期凊理 非同期凊理に察応した オヌケストレヌタヌを 甚いる特殊な実装 Horror Story 䜿甚しない 非同期通信 同期凊理 内郚は非同期凊理なのにク ラむアントには同期的に芋 せるずいう無理のある実装 ※ 詳现は参考曞籍「Software Architecture: The Hard Parts」を参照
  26. 45 参考むベント゜ヌシング • 考え方をもう䞀歩進めお、むベントログそのものをデヌタベヌスずしお扱う方法もある • Query ごずに、察象ずなる゚ンティティのすべおのログをリプレむする ◩ 「゚ンティティのこれたでの倉化」がビゞネスデヌタずしお必芁な際に有効な方法 ◩

    リプレむのオヌバヌヘッドが問題になる堎合は、定期的にチェックポむントをキャッ シュしおおく Micro service Event むベント保存 Event Store ゚ンティティ曎新 ゚ンティティ マネヌゞャヌ むベントリプレむ ゚ンティティ取埗
  27. 47 デヌタの Query 機胜 • 各サヌビスは、必芁に応じお、自身が管理する Entity に察する怜玢機胜を実装する ◩ /customers?page=1&size=20

    ペヌゞング機胜 ◩ /orders?customerIds=4,5,10,20 ID 指定での怜玢 • 耇数のサヌビスに跚ったデヌタを Join する堎合は、そのための機胜を個別に実装する ◩ 図は API Gateway で実装する䟋で、この堎合は、クラむアント開発チヌムが実装する BFF パタヌンが掚奚される Customer service Order service get all customers (1) for each customer: get order (2) (1) (2) get orders for all customers
  28. 48 怜玢甚デヌタの重耇保存 • 各サヌビスは、怜玢に必芁なデヌタを重耇保存するこずで、耇数サヌビスに跚った Join を 避けるこずができる ◩ 耇補元のサヌビスがデヌタ曎新むベントを発行しお、耇補先にデヌタを非同期に送る ◩

    耇補先のサヌビスが必芁なタむミングで自発的に耇補元のデヌタを取りに行く • 重耇デヌタの䞀時的な䞍敎合があるこずを前提ずしたアプリケヌション蚭蚈が必芁 Order service Order database Fee service Order id Stock id Units Fee details 782346 abc 25 ・・・・ get fee details create order get order details Fee service のデヌタを重耇保存
  29. 52 Eventual consistency ぞの察応 • 䟋えば、クラむアントが売华リク゚スト送信盎埌にリク゚ストの状態を確認するず、リク゚ スト情報がただ存圚しない可胜性がある Order service Order

    information service Order created Order information 関連情報の収集 売华リク゚スト リク゚ストの 情報を取埗 リク゚スト情報が ただ存圚しない
  30. 53 Eventual consistency ぞの察応 • クラむアント偎の実装で察応する方法 ◩ Polling / Push

    notification凊理結果が確定するのを埅っおから UI を曎新する ◩ Optimistic update凊理が成功した前提で UI を曎新しお、埌で結果を再チェックす る䟋Twitter の Like ボタン Client Command Query Polling / Push notification Update Client Command Query Update Confirm or rollback
  31. 参考GraphQL に぀いお 54 • GraphQL  Query Language for API

    • クラむアントが必芁ずするデヌタごずに API を甚意するもしく は、すべおのデヌタをたずめお返す API を甚意するのではな く、クラむアント偎が必芁なデヌタを指定しおリク゚ストを出す • API ゲヌトりェむは、問合せ可胜なデヌタ圢匏のスキヌマを公開 • リク゚ストを受けた API ゲヌトりェむは、耇数のバック゚ンドか らデヌタを収集しお、たずめた結果をクラむアントに返す • 䞻に倖郚クラむアントにデヌタを公開する際に䜿甚 ◩ ネットワヌク通信量を枛らす為に、クラむアントは必芁最䜎 限のデヌタだけを芁求する GraphQL ゲヌトりェむ Query 実行 耇数サヌビスから デヌタを収集
  32. Reliable なサヌビスを実珟するためのゎヌル 57 • 問題の発生源を理解しお、あらかじめ察策しおおく ◩ 適切なヘルスチェックを実装するこずも開発者の責任 • 障害の圱響範囲を閉じ蟌めお、Cascading failure

    を防止する ◩ Circuit breaker、Exponential backoff などの仕組みを利甚する • 自動化を甚いお埩旧の速床をあげる ◩ 特にロヌルバックの自動化は重芁
  33. 問題の発生源 58 • レむダヌごずに問題を切り分け るためにも、レむダヌごずのメ トリックの取埗が重芁 倖郚デヌタベヌス 呌び出し先の サヌビス DNS

    などの 倖郚サヌビス 自分自身ハヌド りェアを含む 通信経路 呌び出し元の サヌビス Order database Micro Service A Micro Service B 倖郚 サヌビス Order service
  34. ロヌドバランシングによる冗長化 59 • ヘルスチェック甚の暙準 API を甚意しお、サヌビスごずに実装する • 連続しお fail する堎合は、アラヌトを䞊げお原因を調査する

    @app.route('/ping', methods=["GET"]) def ping(): return 'OK' 最もシンプルな 実装䟋 ロヌド バランサヌ Micro Service A Micro Service B ヘルスチェック ヘルスチェックに fail した サヌビスを匷制再起動
  35. Micro Service B Cascading failures 60 • ロヌドバランスされたタスクの぀が停止 するず、残りのタスクの負荷が䞊がり、タ むムアりトによるリトラむが発生するこず

    でさらに負荷が増加しお、最終的に完党停 止する • サヌビス停止の圱響が呌び出し元のサヌビ スに䌝搬しおいき、党面的なサヌビス停止 に到る Order service Fee service Market service × × Micro Service A × ロヌド バランサヌ Fee service Fee service × Order service 
  36. Cascading failures を防止する方法 61 • RetryExponential back-off の導入 • Fallbacks,

    caching, graceful degradation䟝存サヌビスが停止時も皌働を続ける工倫 • Timeouts and deadlinesDeadline のチュヌニングずプロパゲヌション • Circuit breakers呌び出し先のサヌビスが䞍安定な際に、クラむアントラむブラリが自発 的に fail する仕組み • Communication brokersPub/Sub を甚いた非同期通信
  37. リトラむ 62 • 単玔なリトラむが抱える問題クラむアントからのリク゚ストが突発的に増加するず・・・ → サヌビスの負荷が高たっお凊理が遅延し始める → リク゚ストの凊理䞭にタむムアりトが発生しお、クラむアント偎から匷制的に切断 されるそれたでの凊理は無駄になる →

    クラむアントが単玔にリトラむしおくるず、同じこずが繰り返される • タむムアりトが発生した堎合は、呌び出し先サヌビスの負荷が䞋がるのを埅っおからリトラ むする方がよいExponential back-off の導入 @retry(wait=wait_exponential(multiplier=1, max=5) + wait_random(0, 1), stop=stop_after_delay(5)) def all_prices(self): return self._make_request("prices") 5回目たでは埅ち時間を 2倍ず぀増やしおいく 埅ち時間に 乱数を加える 䞀定時間で リトラむを諊める
  38. タむムアりトずデッドラむン 64 • 䞀般に、同期 API の呌び出しを行ったクラむアントは、䞀定時間以内に応答がないずタむ ムアりトしお応答埅ち状態を打ち切る。この時、クラむアントのタむムアりト埌もサヌ バヌは凊理を続けるが、この凊理は無駄になっおしたうので、タむムアりトが短すぎない ように泚意が必芁 •

    さらに、クラむアントから「デッドラむン」情報をサヌバヌに受け枡しおおき、サヌバヌ は、デッドラむンたでに応答できなかった堎合はそこで自発的に凊理を䞭断するずいう実 装も可胜 • サヌバヌがさらに他のサヌビスを呌び出す堎合も同様にタむムアりトずデッドラむンを指 定するが、倧元のクラむアントよりも長いタむムアりトを蚭定しおも意味がない
  39. タむムアりトずデッドラむン 65 • 正垞時のレスポンスタむムの分垃を芋 お、適切なタむムアりトを蚭定する • 倧元のクラむアントのデッドラむン情 報は、絶察時刻で保持しお、サヌビス 間で匕き継いでいくgRPC は自動で

    絶察時刻ぞの倉換を行っおくれる サヌビスが Unresponsive な 堎合、応答が無駄に遅れる A 15s B 5s 10s C 15秒以内に 応答が必芁 10秒以内に 応答が必芁 ビゞネス的に応答が遅すぎおも 意味が無い堎合、早めに゚ラヌ を返した方がよい堎合もある サヌビスの応答を埅ちきれず に fail する堎合がある
  40. サヌキットブレヌカヌ 66 • 呌び出し偎のクラむアントラむブラリ に実装する機胜 • 䞀定回数連続しお fail したサヌビス は、それ以降タむムアりトを埅たず

    に即座に fail する • 䞀定時間埅った埌に、サヌビスの状態 をチェックしお問題がなければ、通垞 状態に戻る アプリケヌション ラむブラリ Micro Service A × 「Close」状態の時は ラむブラリが即座に fail 応答する 連続しお fail するず 接続を「Close」する サヌビスの状態を チェックしお埩掻した ら接続を「Open」する
  41. Pub/Sub を甚いた非同期通信 68 • キュヌ内郚のむベントがロストしない限り、凊理は継続しおい぀かは完了する • デメリットもあるので泚意 ◩ サヌビス連携のロゞックが耇雑になる →

    トレヌサビリティが必芁 ◩ Pub/Sub が SPOF になる → Pub/Sub キュヌのモニタリングが必芁 Order service Market service むベント むベント むベント ・・・ むベント発行 むベント取埗 Fee service
  42. 負荷テスト 70 • 将来のアクセス数の増加を芋積もった䞊で、負荷テストを行う ◩ 䟝存するサヌビスが連動しおスケヌルするこずを確認する • サヌビス個別のテストず耇数サヌビスを連携させたテストの䞡方を行う ◩ リリヌス盎前の負荷テストで問題が発芚しおも手遅れになる

    • プロダクション環境を想定した総合的な負荷テストは定期的に実斜する ◩ 特定のサヌビスのスケヌラビリティが向䞊した結果、䟝存先のサヌビスの負荷が䞊 がっお䞍安定になるなども起こり埗る点に泚意が必芁
  43. 参考Chaos Engineering 71 • 意図的に障害を発生させお、゚ンドナヌザヌに芋える圱響がないこずを確認する手法 ◩ ゚ンドナヌザヌに芋える圱響がない「安定状態」を定矩する ◩ システムの耐障害性を分析しお、ある障害を導入しおも安定状態が保たれるずいう仮 説を立おる

    ◩ 実際に障害を導入したグルヌプず導入しないグルヌプのそれぞれからデヌタを取埗し お、「仮説が正しくない」ずいう蚌拠を探す ◩ 蚌拠が発芋された堎合は、仮説の前提に誀りがあった、぀たり、耐障害性の蚭蚈に問 題があったずいう事なので問題点を修正する