クリス・リチャードソン『マイクロサービスパターン』を読む

第1章 モノリシック地獄からの脱出

• モノリシックアーキテクチャはアプリケーションが巨大化すると、「モノリシック地獄」と呼ばれる困難に直面する。モノリシックアーキテクチャが直面する困難には以下のようなものが挙げられる。
  • 開発者がコードベースを理解できない
  • 開発ペースの鈍化
  • コミットからデプロイまでのハードルが高い
  • スケーリングが困難
  • 信頼性が低い
• アーキテクチャは機能要件とは無関係。しかしサービス品質要件、非機能要件、品質属性、イリティに影響を与える。
• マイクロサービスとは正確にはどのようなものなのか。
• スケールキューブ（三軸のスケーリング）
  • X軸スケーリング：水平分割、クローニングによるスケーリング
  • Y軸スケーリング：機能による分割を利用したスケーリング
  • Z軸スケーリング：データのパーティション分割によるスケーリング
• マイクロサービスはモジュール性の一形態である。マイクロサービスはモジュール性の単位としてサービスを持ち、各サービスは唯一の通信経路としてAPIを持っている。個々のサービスは専用のデータベースを持つ。
• マイクロサービスアーキテクチャとサービス指向アーキテクチャ（SOA）の間には、非常に大雑把には類似性があるが、詳しく見ていくと大きく異なる。
  • サービス間通信：SOAは高機能な通信経路（スマートパイプ）を用いるが、マイクロサービスはシンプルな通信経路（ダムパイプ）を用いる。
  • データ：SOAはグローバルデータモデル、共有データベースを用いる。マイクロサービスはサービスごとにデータモデルとデータベースを持つ。
  • 典型的なサービス：SOAのサービスは大型のモノリシックアプリケーションになるが、マイクロサービスでは比較的小型である。
• マイクロサービスアーキテクチャには以下のような利点がある。
  • 継続的デリバリー/デプロイを実現する
  • 各サービスのメンテナンスが容易、個別にデプロイ・スケーリング可能
  • チームに自主性・自律性をもたらす
  • 障害分離
  • 新規テクノロジーの実験・採用が容易
• 反対にマイクロサービスアーキテクチャには以下のような欠点もある。
  • サービスの適切な分割を発見するのが難しい
  • 分散システムは開発/テスト/デプロイが難しい
  • 複数サービスにまたがる機能のデプロイが難しい
  • マイクロサービスアーキテクチャの採用時期の決定が難しい
• パターンとパターン言語
  • パターン：特定の状況で発生する問題に対して繰り返し使える解決法
  • パターン言語：特定ドメインの問題解決のためのパターンの集合
• パターンのうち以下の3つの部分が重要
  • フォース：特定の状況のもとで問題解決のために対処する目的と制約
  • パターン適応後の状況
    • 利点、欠点、新規の問題から成る
  • 関連するパターン
    • 先行パターン：このパターンが必要とされる理由となるパターン
    • 後続パターン：このパターンが生じさせる問題を解決するパターン
    • 代替パターン：このパターンの代わりに解決をもたらすことのできるパターン
    • 汎化パターン：ある問題の汎用的・抽象的解決策となるパターン
    • 特化パターン：汎用パターンの特化した形態
• 3層のパターン
  • インフラストラクチャパターン：アプリケーション開発に関係しないインフラの問題を解決するパターン
    • デプロイ、通信パターン（ディスカバリ、外部API）
  • アプリケーションインフラストラクチャパターン：アプリケーション開発にも影響を与えるインフラの問題を解決するパターン
    • 横断的関心事、セキュリティ、通信パターン（トランザクショナルメッセージング、通信スタイル、信頼性、ディスカバリ）、可観測性
  • アプリケーションパターン：アプリケーション開発者が直面する問題を解決するパターン
    • 分解、データベースアーキテクチャ、クエリ、データ整合性、テスト、可観測性
• マイクロサービスアーキテクチャと組織
  • マイクロサービスアーキテクチャは小型で自主的なチームを可能にする。
  • 継続的デリバリ/デプロイを可能にする。
  • マイクロサービス化に伴うメンバーの感情的変化を上手くマネジメントすることが必要。