今更ながらマイクロサービスアーキテクチャを読んだので読書メモ

所感

日本語で「マイクロサービスアーキテクチャ」を学ぶにはどうしたらよいか？と思ったらまずこの本が一番最初にでてくるのではないだろうか。
業務中や勉強会でも頻繁に聞くようになったマイクロサービスだが、自分は「コンポーネント分割して別のサーバインスタンス上でプロセス立ち上げればいいんでしょう？」くらいの雑な理解だったので形式化された理解をしようとやっと本に手を取った。
結論としては今まで単体の技術として聞いたり学習したりしていたコンテナ・分散システムの技術がどのように背景・課題解決のために産まれてきたきたのかなんとなくわかった。最近のWebサービスで話題になる設計パターンや技術の基礎となる考えを知るには良い本だった。マイクロサービスとはいえ監視や認証にはガバナンス（共通化）が必要であること、モノリスのままのほうがときもあることについてもしっかり言及されているのも良かった。

読書メモ

以下は自分用のメモ。

• マイクロサービスに分割するためにはドメインモデルの理解が不可欠
• ビジネス概念のモデルに沿った分割をすることで、安定したインターフェースとビジネスモデルの変化を迅速に反映できる
• 各マイクロサービスは独立したデプロイ・イミュータブルなサーバ（コンテナ）構成で成り立つのが望ましい
• 複雑なアーキテクチャの実現には自動テスト・継続的デリバリーが不可欠
• テストは保証範囲と実行速度のトレードオフ
  • 単体テストからE2Eテストまでそれぞれの粒度のテストを用意する
  • 複数のマイクロサービスを横断したテストは必要だが、テスト実行時間との兼ね合い
• 複数に分かれたマイクロサービスをどのように監視するのか。
• 中央に集約する。共通IDを生成して複数サービスから分散して出力されるログを可視化する
• マクロサービスでも各自で好き勝手してよいわけではない。ログなどの監視は標準化が大事
• サービスの文書化
  • 増大するAPIは自動でドキュメント化して可視化されているのが望ましい(Swagger/HAL)
• 多数のサービス/多数のトラフィックの上で防げないことを防ごうとするのに費やす時間を減らす
• 何事も失敗する可能性があるという前提に立つ。
• 安全にデグレードさせる。一つのマイクロサービスの障害でサービス停止状態になってはいけない。
  • これにはドメインとマイクロサービスの関連を理解していないと対処できない。あるマイクロサービスが機能不全のときにサービスとしてはどのようなステータスになるのか理解しないといけない。1マイクロサービスの機能不全の全体への影響を最小限に抑える
  • 例:ECサイトで認証サービスが落ちても、商品カタログの閲覧くらいはサービス持続可能
• CAP定理
  • 整合性 複数のノードで同じ結果が得られること
  • 可用性 すべてのリクエストがレスポンスを受け取ること。
    • 整合性を優先するとリクエストを拒否しないといけないときがある（分散データの同期が失敗しているときなど）
  • 分断耐性 システムの部分間の通信ができなくても対処できること

終わりに

関連してプロダクションレディマイクロサービスも読んでおきたいと思っている。
会社の先輩がこちらのほうがより実業務、実例よりとおっしゃっていた気がするので、もっと具体例をとおして学びたいならプロダクションレディ…から読んだほうがいいのかもしれない。