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

はじめに

読んだ。

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

SRE本を読んだあとぐらいに発売されて、買ってはいたんですがなかなか読めてなかった。なかなかコンパクトなのでわりとすぐ読み終えた。しかしいい本です。

この本はマイクロサービスを本番環境に提供するための準備、"本番対応(Production Ready)"のためのガイドです。本番対応のために何が必要なのか？体型的にまとめっています。

順に復習しておきます。

1章 マイクロサービス

この章ではマイクロサービスはどのようなもので、モノリシックなアプリケーションをどのようにマイクロサービスするかについて説明されています。なかでも興味深かったのは1.4 組織的な課題ですね。

1.4.1 逆コンウェイの法則

コンウェイの法則、"システムのアーキテクチャは、コミュニケーションと企業の組織構造によって決まる(p26)"というものがありますが、その逆、すなわち"企業の組織構造はシステムのアーキテクチャによって決まる"ということもまた真です。(これを逆コンウェイの法則と呼ぶ)

当然、マイクロサービスアーキテクチャでサービスを作る場合は、小さなチームがたくさんできることになります。しかも、マイクロサービスである前提から、各組織は単一(あるいは狭い範囲の)責任を持ち、他のチームとは独立してしまうことになります。

もちろん、インフラストラクチャチームと(マイクロな)開発チームも別ですし、仮にDevとOpsが別のチームであれば、Opsも別のチームとなるでしょう。

以下は本書で言及されているものではありませんが、僕はSREこそが開発、インフラ、運用の橋渡しとなる存在になるべきだと思います。協力するのはもちろんですが、SREは技術的な運用、リリース、開発の解決に加えて、サービス全体の信頼性のために、各チームに対して仕組みを提供する、そういう役割もあると思っています。技術的解決以外にも、組織/人間/チームに対するアプローチも必要な、大切な役割だと思います。

1.4.2 技術的スプロール

スプロール現象が、"都市が無秩序に拡大していくこと"であるので、技術的スプロールは、拡大していく組織が、(使用技術に関して)無秩序になってしまうさまでしょう。

スプロール現象 - Wikipedia

マイクロサービスの性質上、各チームは好きな言語を使ってもいいでしょうし、好きなツールを使ってもいいでしょう。これはマイクロサービスの利点としてよく語られます。

しかし、これまたサービス全体で見たときに不利益が出てきます。（極端な話)100のマイクロサービス、100種類の別の言語を使っていれば、組織間の人材流動は容易ではなくなってしまいますし、メンテナンスコストもあがってくる。

いろんな会社の方と話しても、やっぱり使用言語は統一させたいと聞きますね。メイン言語と、サブ言語の2つぐらいにするところが多いようです。

上記いずれも、マイクロサービスで組織が分断されたとき、1サービスとして考えると課題になってくる点だと思います。

2章 本番対応

この章では今後の章で出てくる5つの観点の説明と、それを標準化することの必要性を説いています。

開発者は反対するかもしれませんが、サービス全体で標準化を進め、サイトの信頼性を高めていく必要があります。

3章 安定性と信頼性

この章ではマイクロサービスの安定性と信頼性が書かれていますが、何も運用中に限った話ばかりではありません。

CI/CDやDevOpsまわりで語られることが多い開発サイクル(ブランチ戦略や各種テスト、自動化)からはじまり、本番へのデプロイパイプライン(カナリアデプロイ、ステージング環境)、そして各マイクロサービスの依存関係の追跡(おそらく後のドキュメント化のところでされるんでしょう)。あとは障害検出(健全性チェック)を備えること(そして健全ではない場合はトラフィックを正式にルーティングしないこと)、APIに関してはユーザに対して非推奨と廃止を通告することですね。よくdeprecated、と書かれてしばらく様子見されますよね。

開発環境や本番デプロイまわりの整備はまずやるとして、個人的に一番難しいのは依存関係だと思います。私もマイクロサービスの開発をしていて、普段は自分のサービスだけに閉じたことだけを気にしていればいいですが、たちまち自分のサービスが停止しないといけないときに、その追跡調査に非常に苦労しました。何せ依存関係はどこにもドキュメント化されておらず、各チームにヒアリングした結果を自分自身でまとめなければなりませんでした。

安定性、信頼性のために重要なことだと思います。

4章 スケーラビリティとパフォーマンス

この章で興味があったのは成長の判断基準に"質"と"量"を区別している点。

RPS(Request Per Sec)といった性能基準は量的な判断基準。そうではなくビジネスサイドから見たユーザ数、契約数といったものを質的な判断基準と呼んでいます。マイクロサービスは様々な依存関係を含んでいるので、大きいものであれば複雑系とも言えるぐらい、内部の単一性能だけを見て評価することは難しいんでしょう。

重要かつ難しいのはキャパシティプランニングですよね。ハードウェア調達ってなかなか稟議降りず、結果キャパシティオーバーなんてことも。

スケーラブルで、同時平衡性にすぐれる言語、もしくはそういったフレームワークをサポートできる言語かという点も興味深いですね。(4.8.1 プログラミング言語の限界)

5章 耐障害性と大惨事対応

SPOF(単一障害点)を取り除くこと、障害は必ず発生するので、各レイヤー(ハードウェア、ソフトウェア、依存関係、マイクロサービス内部)での起こりうる障害の例、テスト(特に負荷テストをしておくこと)、そしてnetflixで有名なChaosテスト。そして障害発生時の対処についてまとまっています。

これはかなり大事な本番対応ですね。ほんと起きてからじゃ遅いからな、、、

www.publickey1.jp

6章 監視

監視に必要な主要なメトリック、ロギングの方法や注意点、一目で状況がわかるダッシュボード、そして監視した結果あげるアラート(必ずすべきアクションが定義されていること)、オンコールローテーション。

言うまでもなく重要な本番対応です。

7章 ドキュメントと組織的な理解

ドキュメントは僕がもっとも強い関心を持つ部分です。

冒頭のカラマーゾフの兄弟を引用している点がいいですね。"いつでも葱を与えよ(p148)"。

すべてのマイクロサービスに包括的で最新の状態に合わせて更新されたドキュメントを用意することの重要性は、いくら強調しても足りません。

なぜか開発者ってドキュメントに関心ないですよね、、、僕のまわりだけでしょうか。

ドキュメントがないとひとに聞かないといけない、聞く方もしんどいし聞かれるほうもしんどい、コミュニケーションコストが増大しているのになぜ解決しようとしないんだろう、と思ったこともありますが、ドキュメントもスキルの一種なんですよね。簡単ではない。

書かれるべきドキュメント。

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

関係するあらゆるひとへ葱を与えましょう、そのためにドキュメントは重要です。

おわりに

本書はマイクロサービス・アーキテクチャを採用したサービスを本番にデプロイするために必要な準備をコンパクトに、5つの観点でまとまっています。どれも欠かすことない、重要な点と言えると思います。

マイクロサービスは開発者にとっては自由だけども、ここで述べられた最低限の標準化だけは守ろうな、そしてみんな自分のことだけ関心を向けるんじゃなく、1サービスの信頼性向上のために協力しようね(葱を与えようね)という感じです。

付録にはチェックリストがあり、ここだけ見て本番対応ができているかどうか確認することができます。よい！

今後自分がサービスを作るときにこの本をまた見返したいです。

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

Sre in Practice