『プロダクションレディマイクロサービス』
https://www.oreilly.co.jp/books/9784873118154/
この本は『マイクロサービスアーキテクチャ』（https://www.oreilly.co.jp/books/9784814400010/）のあとに読むのがおすすめです。特に「なんでも分割したい病」に罹患しかけている人は、まず『マイクロサービスアーキテクチャ』の方を読むほうがよいです。
この本の活用方法
- ＜お手軽＞興味のある章だけを読む
- ＜もう少し＞全体＋関連する章を熟読
- ＜本番対応・社内でマイクロサービスを標準化したい＞すべて熟読
最初にまとめ
巻末には本番対応のチェックリストがあるので、自分のプロジェクトについてチェックしてみるとよいかもしれません。
本書をはじめから通して読む時間がないなら（大抵の場合ないと思います）チェックが少ない章について熟読するような読み方も良いと思います。
対象読者
マイクロサービスを作りたいと考えているエンジニア、SRE。
多少の前提知識や経験があったほうが中身が頭に入りやすいと思われます。
- ステップバイステップのハウツー
- Uberの技術組織の説明
といった内容は取り上げられていません。
１章：マイクロサービス
一般的なマイクロサービスについての概要です。前提知識があるなら読み飛ばしても良いと思います。
くわえて組織とマイクロサービスの関わり方として「逆コンウェイの法則」が紹介されています。
モノリシックアーキテクチャの企業とマイクロサービスアーキテクチャの企業では異なる問題が発生します。
２章：本番対応
技術組織全体に本番対応の標準を根付かせる方法の提案です。
8つの標準が紹介されています。
- 安定性
- 信頼性
- スケーラビリティ
- 耐障害性
- 大惨事対応
- パフォーマンス
- 監視
- ドキュメント
このあとの章でそれぞれ細かく説明されています。
３章：安定性と信頼性
一元管理されたリポジトリで適切なCI/CDが行われている必要があります。
また、マイクロサービス廃止の手続きや非推奨にする手続きも用意しておく必要があります。
４章：スケーラビリティとパフォーマンス
スケーラビリティはタスクをどのようにして分割統治するかの問題、パフォーマンスはそのタスクをどのようにして効率的に実行するかの問題です。
プログラミング言語、DBなどの選定や、マイクロサービスがどのようなデータ通信を行うかを把握して対応する必要があります。
５章：耐障害性と大惨事対応
障害に耐えられるように準備していても、障害は起こるものです。
その種類や一般的なシナリオをいくつかの種類に分け、検出と修正方法などについての説明がされています。
具体的な内容については本書を参照してください。
https://ncdc.co.jp/columns/6503/
-
エコシステム（＝生態系）の障害
- 不十分な設計レビュー・コードレビュー
- 貧弱な開発プロセス
- 不安定なデプロイ手続き
-
ハードウェアで発生する障害
- ホスト・ラック・データセンター・プロバイダの障害
- サーバープロビジョニングの障害
- 構成管理・変更による障害
- 運用上のダウンタイム
-
通信レベルとアプリケーションプラットフォームレベルの障害
- DNS障害
- 不適切な負荷分散
- CI/CDの障害
-
依存関係の障害
- 下流・依存マイクロサービスの障害
- ライブラリ（内部・サードパーティ）の障害
-
内部の障害
- いわゆるバグ
- DB障害
- 適切なテストの欠如
回復性テスト
耐障害性のあるマイクロサービスを作るための最高の方法が回復性テストです。
回復性テストとは、本番環境のマイクロサービスに、積極的・反復的・ランダムに障害を起こすテストです。
いくつかのアプローチがあります。
-
コードテスト
- lintや単体、結合テスト、E2Eテストが当てはまります。
-
ロードテスト
- 一定の負荷をかけ、スケジューリングで定期的に実行します。
-
カオステスト
- 本番稼働しているマイクロサービスを積極的に停止します。
インフラストラクチャチームが自分たちのサービスやシステムは不可避的に起こる障害に耐えられるという自信を持てるようになるまで、個々のマイクロサービスやインフラストラクチャの部品を何度も繰り返し壊すようにしましょう。
インシデントと機能停止
この章では障害を処理するための組織的な対策手続きについて書かれています。
障害の対応に時間がかかることは、会社にかかる金銭的コストとして積み上がっていきます。
- 評価
アラートを受け取った開発者はまず、問題の深刻度と影響範囲を評価します。 - 調整
このインシデントについて記録し、解決できるチームに情報を提供します。 - 緩和
問題の影響範囲を小さくします。 - 解決
根本原因の解決に着手します。 - フォローアップ
サービスについての客観的事実に基づき事後分析をします。名指しの非難は行いません。
６章：監視
章末にマイクロサービスの評価基準チェックリストがあるので自分のプロジェクトについて質問してみるとよいです。例えば「ログは特定の時点におけるマイクロサービスの状態を正確に反映しているか。」などがあります。
７章：ドキュメントと組織的な理解
ドキュメントを書いてサービスの更新のたびにアップデートするべきです。
本番対応のドキュメントに書かれているべき項目
- 短く的確でわかりやすいサービスの説明
- アーキテクチャ図
- 連絡先とオンコール情報
- リンク
- オンボーディング／開発ガイド
- リクエストフロー、エンドポイント、依存関係
- オンコールランブック
- FAQ
チームのすべての開発者が本番対応についての質問に答えられる（ドキュメントを探れば答えがある）状態を目指しましょう。
最後にまとめ
読み応えのある本なので、手元においておいて時々読み返すのがよいかもと感じました。