プロダクションレディマイクロサービスを読んだ
はじめに
プロダクションマイクロサービスを読みました。学んだことの内容を整理をするために書評を書きたいと思います。
全体を通して
以前、マイクロサービスアーキテクチャという似たような名前の書籍を読んだことがあるのですが、こちらに比べてかなり読みやすく感じました。（そもそも語っている内容が違うというのもあるのですが）
マイクロサービスアーキテクチャではどちらかというとマイクロサービスをやっていく上でのアーキテクチャやCI/CD、監視といった実装やアーキテクチャの観点での話が多かったのですが、
プロダクションレディマイクロサービスはもっと組織的な話やサービスのメリデメ、マイクロサービスの評価方法、緊急時の対応方法、など、技術的な話よりはマイクロサービスを運用していく上で必要な知見や原則によった観点でプロダクションレディなマイクロサービスの条件やプラクティスなどが紹介されています。
基本的は読みやすく、これからマイクロサービスを始める人にとって良い本だと感じましたがプロダクションレディネスを本番対応と訳しているところだけは個人的にはすごく違和感がありました。本番対応という言葉に対して、本番でしなければ行けない対応等の意味合いで捉えていたため混乱したのが正直なところです。（多分僕だけかも...）
このブログでは、書籍に習って本番対応という言葉を追加います。
目次
目次の大項目は以下のようになっています。
- マイクロサービス
- 本番対応
- 安定性と信頼性
- スケーラビリティとパフォーマンス
- 障害対応と大惨事対応
- 監視
- ドキュメントと組織理解
全7章で、本編は163pぐらいのもので、比較的短めの書籍となってます。
各章のまとめ
1章 マイクロサービス
この章ではモノリスとの対比を用いて、マイクロサービスの概要を紹介し、マイクロサービスを導入した際の組織的な課題を引き起こす法則として、逆コンウェイの法則（マイクロサービスが組織構造に影響を与える）などが紹介されていました。逆コンウェイの法則で組織の単位が小さくなっていくことでサイロ化とスプロールを引き起こすことが書かれていました。
2章 本番対応
この章では最初にマイクロサービスにおける標準化にまつわる問題が取り上げられられています。技術の採用の自由度に利点を持つマイクロサービスですが、それぞれのサービスが協調してシームレスにコミュニケーションを取ることが必要となるため、標準が必要であることを述べています。また、その標準化を行なう上でのマイクロサービスを評価する方法の1つとしてSLA（サービスレベルアグリーメント）とナイン記法が紹介されていました。本番対応されたマイクロサービスでは以下の観点での標準化と評価を行なう必要があると書かれています。
- 安定性
- 信頼性
- スケーラビリティ
- 障害耐性
- パフォーマンス
- 監視
- ドキュメント
3章 安定性と信頼性
本章では本番対応されたマイクロサービスは安定性と信頼性を持っていると書かれています。安定しているマイクロサービスとは新しい技術の導入、デプロイ、開発や依存関係にあるコンポーネントの非推奨などがマイクロサービス全体に影響を与えないことを言います。また、信頼性のあるマイクロサービスは他のマイクロサービスが安心して依存できるマイクロサービスであると書かれています。
安定し、信頼のおけるマイクロサービスを作るために開発プロセスの標準化、様々なレイヤでのテストの自動化、CI/CD環境の構築、デプロイパイプライン（部分ステージング、完全ステージング、カナリアリリース）、障害児の対応機構（フォールバック機構、キャッシュ）などの重要性が書かれています。
4章 スケーラビリティとパフォーマンス
本番対応されたマイクロサービスではスケーラブルでパフォーマンスに優れている必要があることが述べられています。
まずはマイクロサービスがどのようにスケーリングするかを把握することが重要で、以下の二つの観点が挙げられていました。
- 質的な判断基準
- 各マイクロサービス単体での判断基準（PRS/QPS等）では表しきれない
- 現在のマイクロサービス単体でのトラフィックレベルを見て、キャパシティプランニングを行なうと誤りの可能性が高くなる。
- 「ユーザ数」、「携帯アプリを開く人」、「発注数」等の高いレベルな基準を持つ
上記の高レベルなメトリクスとスケーラビリティを紐付けることで、より高解像度なキャパシティプランニング等を行なうことができます。
量的な判断基準
- 質量的な判断基準を念頭に置いて、PRS/QPSなど実際の計測可能な値に変換する
- 質的な判断基準（ユーザ数、携帯アプリを開く人等）に対して、どのくらいのリクエストが行われるかを算出しスケーラビリティを考える。
- PRS、QPSなどが二大メトリクスになる
上記の成長の判断基準を持った上で、リソースの競合やボトルネック等を考えることが重要だとこの章では述べられていました。上記の基準を持つことで、サービス全体の限界等を知ることができます。
5章 耐障害性と大惨事対応
本番対応のマイクロサービスは耐障害性があり、大災害などにも耐えられるようになっている必要があると記述されています。
まず大前提として、障害は起こり、そこから逃れられるマイクロサービスは存在しないということが述べられています。その中で以下のことが重要であると述べられています。
- 単一障害点(SPOF)を作らない
- 障害発生の一般的なシナリオを用意しておく
- 障害の検出と修正方法を定めておく
- ロードテスト、コードテスト、カオステスト等を徹底して行なう
また、障害発生時の対応作として以下の5段階が存在することが述べられていました。
評価 ⇨ オンコールエンジニアは、起こった障害を評価し問題の深刻度とスコープを評価し、トリアージ（対応の優先順位付け）する。
調整 ⇨ 障害発生に対して、実際に他のエンジニアなどのとの調整を行います。その際に情報伝達の記録を残しておくことで後の解決に役立つような情報を残します。
緩和 ⇨ 緩和では、根本原因の解決ではなく、問題の影響の最小限化を行なう必要があります。サービスとクライアントの可用性が損なわれなくなるまで、緩和を行なう必要があります。
解決 ⇨ 緩和を行われたあと、エンジニアは根本原因の解決に取り組むことができます。
フォローアップ ⇨ 発生した障害の分析し理解するための文書を書き、公開する。
6章 監視
本番対応のマイクロサービスは、適切に監視されている必要があることが述べられています。その中で本章では必要なメトリクスやログの収集方法、また、アラートへのアプローチについて述べラてています。
まず、適切な監視が無い場合開発者は機能停止するまで、問題の発生に気がつくことができず、また、メトリクスが残されていないことにより障害発生時の問題特定までの時間が長引くことが指摘されています。本番対応のマイクロサービスには以下の4つの構成要素があると述べられています。
- ロギング
- ダッシュボード
- アラート
- オンコールローテーション
また、監視の主要メトリクスとして以下のようなものが挙げられていました。
- ホスト、インフラのメトリクス
- CPU
- RAM
- スレッド
- ファイルディスクリプタ
- データベース接続
- マイクロサービスのメトリクス
- 言語特有のメトリクス
- 可用性
- SLA
- レイテンシ
- エンドポイントのヘルスチェック
- エンドポイントのレスポンス時間
- クライアント
- 依存関係
- エラーと例外
7章 ドキュメントと組織的な理解
最後の章では、本番対応のマイクロサービスは適切にドキュメントされているべきだと述べられています。包括的なドキュメントが存在し、定期的にメンテナンスされていることが重要であると述べられています。そのためにドキュメントの作成が開発プロセスに組み込まれていることが重要であると書かれています。
また、ドキュメントを作成するときに以下のようなことが書かれていると良いというティップが書かれていました。
- 説明
- マイクロサービスの説明を完結に書いておきます
- アーキテクチャ図
- オンコール情報
- リンク
- 開発をする上で必要そうなリンクをすべて貼っておく（ダッシュボード、Issue等）
- オンボーディング、開発ガイド
- コードをチェックアウトし、環境を設定し、サービスを起動し、動作確認を行えるようになるまでの説明を記述しておく
- リクエストフロー、エンドポイント、依存関係
- 上記のそれぞれに関する概要をまとめる
- オンコールランブック
- トリアージ、緩和、解決の方法をステップ・バイ・ステップで記述する。また、サービスアラートの一覧を記述します。
- FQA
感想
最初はマイクロサービスのアーキテクチャの本課と思って読み始めたのが正直なところでしたが、マイクロサービスを支える知見としてこのような本の内容のものの非常に大切だと感じました。
