プロダクションレディなマイクロサービスを実装するための標準化を学べる「プロダクションレディマイクロサービス」を読んだ

オライリーから出版されている「プロダクションレディマイクロサービス」を読んだ．「プロダクションレディ」という秀逸なタイトルに惹かれただけじゃなく，章ごとのテーマも非常に惹かれる内容になっていた．仕事でアーキテクチャを考えたり，アーキテクチャレビューを担当する場面も多いけど，ベストプラクティスなアーキテクチャをもっと上手に言語化したいなと思っていて，プロダクションレディなマイクロサービスの標準化を学べる本書に興味を持った．

• 1章 マイクロサービス
• 2章 本番対応
• 3章 安定性と信頼性
• 4章 スケーラビリティとパフォーマンス
• 5章 耐障害性と大惨事対応
• 6章 監視
• 7章 ドキュメントと組織的な理解
• 付録A 本番対応のチェックリスト
• 付録B マイクロサービスの評価基準

プロダクションレディマイクロサービス ―運用に強い本番対応システムの実装と標準化

小さなモノリス

「マイクロサービスアーキテクチャ本」にもモノリスを分割する話が載っていたけど，本書でも「モノリスを分割することが1番難しい」と書かれていた．コンテキストの見極めに失敗すると「モノリスを数個の小さなモノリスに分割するだけ」になってしまうと書かれていて，「小さなモノリス」という失敗パターンの表現は刺さった．確かに「小さなモノリス」って言われたらツライ...！

マイクロサービスアーキテクチャ

逆コンウェイの法則

マイクロサービスの文脈でよく聞く「コンウェイの法則」に対して，本書では「逆コンウェイの法則」というパワーワードが出てきた．意味としては，マイクロサービスを積極的に採用していくと，必然的に独立した小さなチームが多くできるということだけど，さらに「逆コンウェイの法則」は組織構造だけじゃなく，個々のエンジニアにも当てはまるという話が興味深かった．ようするに，担当するマイクロサービスに特化した責任とドメイン知識が強まるため，全体を把握したエンジニアがいなく「集合的に全体を把握する」ことになるということだった．良し悪しを決めるというよりは，法則の納得感があるところが良かった．

インシデント発生時の「緩和」と「フォローアップ」

インシデント（障害）発生時には，以下の5種類の段階があり，モノリスと比較するとマイクロサービスだと「調整」と「フォローアップ」が必要になるという話だった．個人的には「緩和」と「フォローアップ」の重要さがまとまっているのが素晴らしいと感じた．

• 評価
• 調整
• 緩和
• 解決
• フォローアップ

「緩和」というのは「インシデントの影響を小さくする」ことを意味していて，インシデント発生時にすぐバグを直すのではなく，まずはユーザー影響を考えるべきと言い換えることができる．サービスを運用していて「インシデント対応が上手だな」と感じる人は緩和が上手だと思うし，SIer 時代から意識するようにしている．個人的には「緩和」という言葉が定義されていることに意味があるので，仕事でも積極的に使っていこうと思う．また，3章では「ホットフィックスはアンチパターン」という話もあり，すぐに直すのではなく，まずは安定バージョンに切り戻すことで「緩和」できるということにも繋がる．

「フォローアップ」は SRE の文脈で出てくる「ポストモーテム」と同じだった．仕事でも最近はポストモーテムを書くようにしていて，重要なのは「インシデントから学ぶ」姿勢と言える．

SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム

オンコールローテーションの定義

マイクロサービスの監視には4種類の構成要素があり，ポイントがまとまっていた．内容的にはマイクロサービスに特化しているようには感じなくて，モノリスでもサービスを運用する上で重要な話だった．

• ロギング
• ダッシュボード
• アラート
• オンコールローテーション

その中でも「オンコールローテーション」はマイクロサービスだと特に設計が難しそうで，定義が載っているのは参考になった．よくあるのが「1番詳しい人が常にオンコールを受けている状態」だったりするので，マイクロサービスでも，モノリスでも，サービスを運用する前にオンコールローテーションは決めておくべきだと感じた．個人的には，オンコールローテーションを運用しているチームも，運用していないチームも経験があるけど，やはりオンコールローテーションという責任が明確に与えられている方が良かった．

• 1度にオンコールを受けるのは2名以上
• オンコールシフトは1週間未満
• 次のオンコールシフトまで1ヶ月以上の間隔を空ける

マイクロサービスのドキュメント

7章に「リポジトリの README もコードコメントもドキュメントではない」という話があり，刺さった．目指す方向性としては，全てのマイクロサービスのドキュメントが一箇所に集まっていることが重要とのことだった．そして，マイクロサービスのドキュメントとして，まとめるべき項目が整理されているのが目から鱗だった．確かにここまで書けば，包括的で実用的なドキュメントになりそう．特に「オンコールランブック（インシデント発生時の対応方法）」と「FAQ（よく聞かれることならなんでも）」は，めちゃめちゃ良かった．

• 説明
• アーキテクチャ図
• 連絡先とオンコール情報
• リンク
• オンボーディング／開発ガイド
• リクエストフロー／エンドポイント／依存関係
• オンコールランブック
• FAQ

まとめ

「付録A 本番対応のチェックリスト」も便利で，今回記事にまとめたところ以外にも学びが多く，マイクロサービスを作る前に必読な良書だった．標準化として満たすべき項目が非常に多く「お前のマイクロサービスはマイクロサービスじゃねぇ！」と叱咤激励されているような気分にもなり，気持ちが引き締まる思いだった（笑）

また，マイクロサービスに特化しすぎていなく，モノリスだとしても，サービスを運用するときに必要なポイントがうまく言語化されているのが良かった．オススメ！

（今回も付箋だらけになった...！）

関連記事

やはり「マイクロサービスアーキテクチャ本」と合わせて読んだり，「マイクロサービスアーキテクチャ本」の筆者 Sam Newman の登壇動画を合わせて見ると，より理解が深まると思う．

www.youtube.com

kakakakakku.hatenablog.com