Skip to content

Instantly share code, notes, and snippets.

@hypermkt

hypermkt/マイクロサービスアーキテクチャ.md

Last active September 16, 2020 04:46
Show Gist options
  • Star 3 You must be signed in to star a gist
  • Fork 1 You must be signed in to fork a gist
  • Save hypermkt/c803699432d5f6a6279fc96834c04fd0 to your computer and use it in GitHub Desktop.
Save hypermkt/c803699432d5f6a6279fc96834c04fd0 to your computer and use it in GitHub Desktop.
Download ZIP
マイクロサービスアーキテクチャの読書メモです
Raw
マイクロサービスアーキテクチャ.md

マイクロサービスアーキテクチャ 読書メモ

1章 マイクロサービス

  • マイクロサービスは、協調して動作する小規模で自律的なサービスである
    • 小さく、かつ１つの役割に専念する
    • 独立したシステムで、サービス間はAPIで通信をする
  • メリット
    • サービス毎に異なる技術を使用できる、迅速に技術を採用できる
      • 但し複数の技術の採用はオーバーヘッドが伴う
    • システムのあるコンポーネントに障害が発生しても、その障害が連鎖しなければ、問題を分離してシステムの残りの部分は機能し続けることができる
    • 小さいサービスでは、必要なサービスだけをスケールできる
    • デプロイが容易。１つのサービスに変更を加えて、残りのシステムとは独立してデプロイができる。
  • 他の分解テクニック
    • 共有ライブラリ
      • ライブラリによって、チームやサービス間で機能を共有できる
      • 欠点として技術的多様性が失われる

2章 進化的アーキテクト

  • 本章は、ビジネス戦略・全体的な設計・技術選定を行う人（アーキテクト)の行動指針についてのお話。
  • チームの構築
    • アーキテクトは、システムの技術ビジョンの責任を担う主要人物である
    • そのビジョンを実行するには、単に技術的な判断を下すだけでは足りない
    • 技術リーダーの役割は、チームの開発者の成長を促し（ビジョンの理解を促し）、ビジョンの具体化と実装に積極的に参加できるようにすること
    • マイクロサービスとの関連では、モノリシックシステムでは開発者たちが向上した何かを得る機会がないが、マイクロサービスであれば可能
    • 各自のキャリアを実現させるための優れた方法であり、同時に責任者の負荷を軽減する
  • 本章ではまとめがとても分かりやすい
    • 進化的アーキテクトの主な責務とは
      • ビジョン
        • システムが顧客や組織の要件を満たすのを助けるシステムの技術ビジョンを、明確に伝えるようにします
      • 共感
        • 顧客や同僚に対する自分の判断の影響を理解します
      • 強調
        • できるかぎり多く仲間や同僚と関わり、ビジョンの定義、改良、実行に役立てます
      • 適応性
        • 顧客や組織の要求により技術ビジョンを変更するようにします
      • 自立性
        • チームに対して標準化と自律性の実現との間の適切なバランスを見出します
      • ガバナンス
        • 実装しているシステムを技術ビジョンに合わせます

3章 サービスのモデル化方法

  • マイクロサービスの境界について
  • 優れたサービスにするには、疎結合と高凝集性の概念に注目する
  • Eric Evansの著書「Domain-Driven Design」の境界づけられたコンテキストにもとづき、モデルを定義すると良い
  • 新規システムはよりモノリシックになるようにする。新しいドメインに着手する際は、事態が安定するまで待つのが懸命。早期にマイクロサービスに分割すると失敗する。

4章 統合

  • マイクロサービスの世界におけるDRYとコード再利用のリスク
    • マイクロサービス間で共有ライブラリを利用すると、それを利用している全マイクロサービスに影響が出るので危険
    • 1つのマイクロサービス内ではDRYは守るが、全サービスにおけるDRYの違反は寛大になるべき

5章 モノリス(一枚岩)の分割

  • 境界づけられたコンテキストが接合部にある。疎結合な境界。
  • MusicCorpを例にすると４つのコンテキストがある
    • カタログ
    • 経理
    • 倉庫
    • レコメンデーション
  • 分解の手順
    • コンテキストを表すパッケージを作成し、既存コードをそれらのパッケージに移動する
    • どの部分がデータベースに対する読み書きを行っているか確認する
    • 外部キーの削除。例えばAサービスとAテーブル、BサービスとBテーブルの関係があった場合に、AサービスはBテーブルを直接閲覧してはいけない。Bサービス経由でデータ取得をする。
    • 国情報など各サービスが共通に使う静的データがあった場合は、各サービスごとに静的データを持っても良い。
  • データベースリファクタリング
    • サービスごとにアクセスするテーブルを分割できたら、データベースも分割できる
    • 但し課題として単一トランザクションで管理できなくなる。各々でトランザクションをしてもどちらが失敗したら不整合が起きる。
    • そのような場合はリトライ処理で整合性を保つ

6章 デプロイ

7章 テスト

8章 監視

9章 セキュリティ

  • 認証と認可
    • 認証: ある関係者が確かに名乗っている本人であることを確認するプロセス
      • 認証対象の人やものをプリンシパル（主体）と呼ぶ
    • 認可: プリンシパルとプリンシパルに許される動作をマッピングすメカニズム
  • SSO
    • １つのIDとパスワードで一度認証を行うことで、複数のウェブサービスやクラウドサービスにアクセスする仕組み
  • サービス間の認証と認可
  • APIキー
    • APIキーにより、サービスは呼び出し元を特定し、実行できることに制限を設けることができる
  • ロギング
    • ログに格納する情報に注意する。機密情報はログ出力しない。

参考資料

10章 コンウェイの法則とシステム設計

11章 大規模なマイクロサービス

12章 まとめ

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment