KDOC 491: 『マイクロサービスアーキテクチャ』

この文書のステータス

  • 作成
    • <署名>
  • レビュー
    • <署名>

概要

メモ

  • マイクロサービスはサービス指向アーキテクチャ(SOA)の一種である。サービス境界の引き方については意見が分かれるが、独立してデプロイできるのが重要である(p3)
  • 独立デプロイ可能性を実現したい場合、データベースの共有は最悪なことの1つである(p9)
  • システムのすべての機能をまとめてデプロイしなければならない場合、モノリス、だという(p15)
  • モジュラモノリス: 各モジュールで独立して作業できるが、デプロイするにはすべてを結合する必要がある。多くの組織で優れた選択肢で、マイクロサービスアーキテクチャの課題を回避しながら高度な並列作業ができる(p17)
    • 課題の1つとして、コードレベルで行われるような分解が、データベースにおいては行われない傾向がある(p17)
    • モジュラごとに分解したデータベースを使うモジュラモノリスもある
  • 人々はモノリスを避けるべきもの、本質的に問題があるもの、と考えるようになっている。モノリシックアーキテクチャは1つの選択肢であり有効である(p19)
  • 100万行のモノリシックアプリケーションのうち1行を変更したら、その変更をリリースするためにアプリケーション全体をデプロイする必要があるようなデプロイは、影響が大きく危険性の高いものになる可能性がある(p26)
  • 分散システムでは複数プロセスが異なるデータベースで状態を管理する。データ一貫性の観点で課題が発生する可能性がある(p33)
  • 安定したサービス境界を定義することの重要性を考えると、マイクロサービスアーキテクチャは新製品やスタートアップにとって向いてないことが多い。開発するにつれて、作業するドメインが大きく変更されるのが一般的である。ドメインモデルがじゅうぶん安定するまで待ってからサービス境界を定義するほうが適切である(p33)
  • 凝集を説明する簡潔な定義: 一緒に変更され、一緒に存在するコード(p40)
  • 状態が正しく変更されるようにする1つの方法は有限状態機械を作成することだが、複数のマイクロサービスが状態機械を管理する責任を共有していると問題になる。単一のマイクロサービスが状態を管理するとよい(p51)
  • データベースのCRUD操作の軽量ラッパーのようなマイクロサービスは低凝集、密結合の兆候である。そのサービスにあるべきデータを管理するロジックがシステムの別の場所に分散している(p51)
  • マイクロサービス境界を探すためのメカニズムはドメイン自体を中心としたものであり、ドメイン駆動設計を利用してドメインモデルを作成する(p55)
    • (感想)ドメイン駆動設計がマイクロサービスのためのものなのを知った
    • ユビキタス言語: ユーザが使っているのと同じ用語をコード内でも使うように努めるべきであるという考え方。実世界のドメインのモデル化がより簡単になり、コミュニケーションも改善する、という考え方(55)
  • アグリゲートの意味がわからない(p62)
    • アグリゲートはより幅広いシステムとの明確に定義されたインターフェースを備えた、凝集ユニットとなる。アグリゲートはシステム内の単一のドメイン概念に焦点を当てた自己完結型の状態機械である
  • システムに実装する変更は多くの場合、ビジネス側がシステムの振る舞いに関して行いたい変更に関するものである。顧客に公開している機能を変更する(p65)
  • ドメインの理解があいまいなままマイクロサービスを作成するのは危険である。最初からマイクロサービスを目指すよりも、マイクロサービスに分解したい既存のコードがあるほうがかんたんである(p78)
  • 多くの企業が、バックエンド機能を分割する利点にだけ目を向け、過度にサイロ化したアーキテクチャ再構築を行っている(p80)

関連

なし。

Backlinks