@hihihiroroのLog

ダラダラと。本ブログは、個人の意見であり、所属会社とは関係がありません。

「プロダクションレディマイクロサービス」を読んだ

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

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

マイクロサービスを標準化するためにガイドにする本だと思う。この本の中では、プロダクションレディには以下の項目を備えている必要があると書かれている。付録に各項目についてのチェックリストと評価基準が纏まっているので使えそうだった。

安定性
信頼性
スケーラビリティ
耐障害性
パフォーマンス
監視
ドキュメント
大惨事(カタストロフィ)対応

第1章でマイクロサービス入門がまとめられている。アーキテクチャの基礎、モノリス→マイクロサービス二分割する際の問題について、マイクロサービスエコシステム、マイクロサービスアーキテクチャを導入する際の組織として課題などがまとまっている。

その後の章ではマイクロサービスを作る際の原則をそれぞれの目的毎にまとめられている。

  • 安定性と信頼性を備えたマイクロサービスを作るための原則(3章)
  • スケーラブルでパフォーマンスの高いマイクロサービスを作るための原則(4章)
  • 大惨事に対する備えができたタイ障害性のあるマイクロサービスを構築するための原則(5章)
  • マイクロサービスの監視についての原則(6章)
  • マイクロサービスの適切なドキュメント、アーキテクチャと組織運営の原則(7章)

この中だととても気になって関心を持って読んだのは、監視とドキュメント。

監視

監視すべきものが何かが決まってないと見れているかどうかもわからない。本書ではマイクロサービスが健全性か見分けれる監視項目と主要メトリックとしてまとめている。主要メトリックにはアプリケーションだけではなくホストレベルのメトリックも含まれている。
また、ロギングについてロギングするべきもののガイド、ロギングしてはならないもののまとめがされている。
主要メトリックをダッシュボードにまとめて表示することを必須としている。ダッシュボードを見ただけでマイクロサービスが正しく動作していることがわかることが大事だ。
すべての主要メトリックニは、正常、警告、危険の3種類のしきい値を決め有効なシグナルが送れなければいけない。また、危険のシグナルが送られてきた場合、すぐにアクションができることが必須とされていた。アクションするためには次のドキュメントにも続いていた。

ドキュメント

途中のコラムで「READMEとコードのコメントはドキュメントではない」と書かれている。マイクロサービスのドキュメントは一元管理、共有、かんたんにアクセスできるが必須とのこと。アプリケーションが回収された際にドキュメントが更新漏れがないように開発サイクルに更新することも含めるのが大事だ。まったくもってその通りだと思った。後で直そうと思っても、忘れたり面倒くさくなったりで、結局更新しないことを何度も経験しているのでルールとして置くことが大事だと思った。

ドキュメントに書かれるべき項目は以下。

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

連絡先、オンコールランブック(トラブル時の対応方法、デバッグ方法)、FAQ(サービスについて聞かれることは何でも)はあると便利だなと思った。特にランブックの「午前2時の眠い開発者でも理解できるように書く」はそりゃそうだと思った。夜中でアラート対応などの際にいちいちドキュメントやコードをしっかり読んで対応方針考えてとか辛い。

まとめ

  • マイクロサービスだけではなくモノリスでも、サービスを運用するときに必要なポイントが原則としてまとまっていた
  • 最低限本書に書かれている原則は守って信頼性向上をするためにみんなで頑張ろうと思った
  • 各章終わりや付録にチェック項目がついているので自分のサービスに対してできてる、できてないを洗い出して良くしていきたい
  • Mesos がよくでてきたな

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

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

マイクロサービス入門 アーキテクチャと実装

マイクロサービス入門 アーキテクチャと実装