# books # microservice

「モノリスからマイクロサービスへ」を読んだ

「モノリスからマイクロサービスへ」を読みました。今の仕事で抱えているシステムでマイクロサービスにしていく話が出ているのですが、どのような粒度で分割していくかの答えが自分の中でも見えてきてないので、その考えのヒントが得られればと思い読み始めました。

目次

  • 1章 必要十分なマイクロサービス

    • 1.1 マイクロサービスとは
    • 1.2 モノリス
    • 1.3 結合と凝集
    • 1.4 必要十分なドメイン駆動設計
    • 1.5 この章のまとめ

  • 2章 移行を計画する

    • 2.1 目的を理解する
    • 2.2 マイクロサービスを選択する理由
    • 2.3 マイクロサービスが悪いアイデアのとき
    • 2.4 トレードオフ
    • 2.5 みんなを連れていく
    • 2.6 組織を変革する
    • 2.7 段階的に移行していくことの重要性
    • 2.8 変更のコスト
    • 2.9 どこから始めればよいか？
    • 2.10 ドメイン駆動設計
    • 2.11 組み合わせモデル
    • 2.12 チームを再編成する
    • 2.13 うまくいってるかどうかを分かるには？
    • 2.14 この章のまとめ

  • 3章 モノリスを分割する

    • 3.1 モノリスを変更すべきか
    • 3.2 移行パターン
    • 3.3 ストラングラーアプリケーション
    • 3.4 機能を移行しながら振る舞いを変える
    • 3.5 パターン：UI合成
    • 3.6 パターン：抽象化によるブランチ
    • 3.7 パターン：同時実行
    • 3.8 パターン：デコレーティングコラボレーター
    • 3.9 パターン：変更データキャプチャ
    • 3.10 この章のまとめ

  • 4章 データベースを分割する

    • 4.1 パターン：共有データベース
    • 4.2 しかし、できない！
    • 4.3 パターン：データベースビュー
    • 4.4 パターン：データベースをラップするサービス
    • 4.5 パターン：サービスのインターフェイスとしてのデータベース
    • 4.6 所有権を移す
    • 4.7 データ同期
    • 4.8 パターン：アプリケーションでのデータ同期
    • 4.9 パターン：トレーサー書き込み
    • 4.10 データベースを分割する
    • 4.11 データベースとコードのどちらを最初に分割するか
    • 4.12 スキーマ分割の例
    • 4.13 パターン：テーブルの分割
    • 4.14 パターン：外部キーのコードへの移動
    • 4.15 トランザクション
    • 4.16 サーガ
    • 4.17 この章のまとめ

  • 5章 成長の痛み

    • 5.1 サービスが増えれば痛みも増える
    • 5.2 所有権のスケール
    • 5.3 破壊的変更
    • 5.4 レポーティング
    • 5.5 監視とトラブルシューティング
    • 5.6 開発者体験
    • 5.7 あまりにも多くのものを実行している
    • 5.8 エンドツーエンドテスト
    • 5.9 全体最適と局所最適
    • 5.10 堅牢性と回復性
    • 5.11 孤児サービス
    • 5.12 この章のまとめ

  • 6章 終わりに

1章 必要十分なマイクロサービス

最初の章ではマイクロサービスについて歴史にも触れながら説明されています。

マイクロサービスとはビジネスドメインに基づいてモデル化された独立してデプロイ可能なサービスであると。この「ビジネスドメインに基づいて」と「独立してデプロイ可能」という2点はこれ以降何度も話が出てきます。

システムを分解するには色んな方法があるが、どんな方法をとるかはそのシステムがどんな課題を解決したいかによって違ってくる。そして何かシステムを作り替えるときにマイクロサービスにしようという流れが出がちだが、マイクロサービスはあくまで手段であることを忘れてはいけないと。なぜマイクロサービスにしたいのかをしっかり考えないといけないという言葉にハッとしました。
今までしっかりと考えることなくマイクロサービスにしよう、APIで切り出そうという話をしてしまっていたなと反省。

2章 移行を計画する

どのようにマイクロサービスの移行計画を立てていくのが良いか、その具体的な考え方や方法について書かれています。

まず1章で触れられていたようにマイクロサービスはあくまで手段であるということ。なので自分達のシステムが今どのような課題を抱えているのか、その課題解決にマイクロサービスが適切かをどうやって判断したら良いかのヒントが多く記載されています。
そして実行していく場合、なるべく小さく進めていくようにすると、最初考えていた時には気づけなった影響に気づけたり、考慮不足に気づけて、場合によっては軌道修正もできるようになると。これは普段の開発でも同じですね。

あとトレードオフの話もすごく今後の参考になる話でした。移行したいというメインの目的と二次的な利益を切り離して考えた方が良いと。既存のサービスを書き直すとき、新しい技術や開発手法を使うことを検討することはよくあると思いますが、自分達は何を一番解決したいのかを考え、それ以外の要素はメインの目的から遠ざけるものなら後回しにすべきだと。
この話をするためにも、最初になぜマイクロサービスにしたいのかを明確にしておくのはとても重要なことなんだと感じました。

そしてすごく心に響いた言葉を以下に引用させていただきます。

答えではなく、問いを模倣しよう

3章 モノリスを分割する

マイクロサービスに移行するためのさまざまな方法（パターン）が紹介されています。付録Aのパターン一覧にはパターンの名前とそのパターンで何ができるかがまとめられているのが親切だ。
自分達のシステムではどのパターンが使えそうかを考えて適用したり、組み合わせて使っていくことができそうだ。

パターン紹介の前に、移行しながら機能も変えるという話が挟んである。この話も結構ありがちなんじゃないかな〜と感じました。ここでも前章のトレードオフの考え方が活かせそうですね。わたしたちは何を解決しようとしているのかを考えて判断していかないといけない。

本書では移行しながら機能を変えることは阻止せよと書かれています。これは既存のシステムも対象です。新旧のシステムで変更の同期が取れていない場合不具合が起きることになりますし、新しいシステムで何か問題があって切り戻すときに、機能変更も一緒に切り戻されることになってしまうからです。

4章 データベースを分割する

データ編です。ここでもコードと同様にさまざまな方法がパターンとして紹介されています。 どのパターンもコードに比べるとやっぱり難易度は高くなるな〜と感じました。それでも少しずつやり続けないといけないことなんですよね。
データベースの適した分割を考えていかないと、将来に向けての問題を抱えていくことになるということも書かれています。

コードとデータベースどちらを先に分割するか？という問いに対しては、現状パフォーマンスやデータの部分で問題を抱えている場合はデータベースから、それ以外はコードから分割すると良いと説明されています。
コードから進めるとデータベースにどんな影響が発生するかを理解することが理解できるからです。コードの変更ならもし途中で軌道修正したい場合もやりやすいですしね。

5章 成長の痛み

サービスを分割していき、サービスが増えていった先の話になります。

増えていったサービスをいかに管理していくか、運用保守をしていくかのヒントが書かれています。k8sの話も出てきます。

どんな問題が起きるかは自分達がどれくらいサービスを抱えているかの数が関係してくると書かれつつ、ただそれもあくまで指標の一つで、どのような問題が起きているのかを自分達のシステムから読み取っていかないといけないと。
自分達のシステムときちんと向き合って、フィードバックを得られるようにし、どのような警告が出ているか、どのような問題が起こりそうかに注意を向けて問題が起きる前に解決していく。そのための方法が紹介されています。

6章 終わりに

割愛。

まとめ

マイクロサービスを進めるための手段の話だけではなく、自分達のシステムにマイクロサービスを適用すべきかを考え方についても最初に書かれているのがとても良かった。自分がマイクロサービスを実際に進めるとき、チームにも是非話しておきたい内容がたくさんありました。今後、何度も読み直す本になりそうです。