本記事はその書籍を通してえられた事についてまとめた。本記事の対象者マイクロサービスに興味を持っている人プロダクションレディマイクロサービスに興味を持っている人なぜ読もうと思ったか4月からマイクロサービスで動いている共通基盤チームを担当することになり、今まではなんとなくマイクロサービスについて理解はしていたが、きちんと書籍を通して学んだ事がなかったので、比較的時間の作りやすいゴールデンウィークの課題図書として読み、ブログを記載する事で理解を深めようと思った。本書を通して何を得られたかマイクロサービスのメリットはそれなりに知っていた。大きなところだと、システムを疎結合にする事により、変更の容易性を得られる事にあると思っていた。その前提の状態から本書を読み、得られたポイントは以下の通り。ドキュメントマイクロサービスを導入すると技術的負債が増える傾向がある。本書によると、一種のトレードオフとされてある。その対処法を要約すると、ドキュメントの維持・管理とメンバーの理解にあるという。組織的に明確化され、構造化されていれば技術的負債を引き起こす混乱や、意識の欠如、アーキテクチャの理解の欠如を払拭する事ができるとのこと。確かに、自分もドキュメントはマイクロサービスでなくても重要であり、しかし更新が後手後手になってしまい陳腐化してしまうプロジェクトやチームを多数見てきた。ドキュメントを最新にしチームで共有するというのが必要になりそうだ。ドキュメントのポイントは以下の通り包括的か定期的に更新されているかマイクロサービスの説明、アーキテクチャ図、連絡先、オンコールの情報、重要情報へのリンク、サービスのリクエストフロー、エンドポイント、依存関係、FAQなど盛り込まれているかドキュメントがチーム内でよく理解されているか簡単に検索できるか注意すべきはREADME。これは本番対応のドキュメントではない。組織的な理解チーム内の全ての開発者がマイクロサービスの本番対応についての質問に答えられ事ができるかが重要になる。マイクロサービスのレビュー、監査は頻繁に行われる必要がある。本番対応の監査プロセスも確立されている必要がある。成長の判断基準サービスがサポートできるRPS(毎秒平均リクエスト数)、QPS(毎秒平均クエリー数)を尺度とする。将来サービスに必要とされるRPS/QPSがどれくらいになるかを予想する。この指標は量的な成長の判断基準を決めるときの判断材料になる。RPS/QPSの情報は、成長の判断基準を初めて計算した時のマイクロサービスの状態に左右される事が多い。マイクロサービスは単独で動いているわけではなく、大きなエコシステムの一部として動いているという事を念頭に置く事が重要。マイクロサービス内のプログラムは何でも良いのか並行性とパーティション分割(タスクがただ小さな部品に分割されているだけではなく、並列処理できるようにする事)を実現しようとし、非同期フレームワークを使いたい場合、並行性とパーティション分割のために構築された言語である、C++、Java、Goなどが望ましい。仮にPythonでサービスを書くと、スケーラビリティやパフォーマンスを妨げる無数のボトルネックが作られ、それらの悪影響を緩和するのが困難になる。並行性とパーティション分割は、相乗効果でマイクロサービスのスケーラビリティとパフォーマンスに影響を与える。上記の通り、マイクロサービス単体の外形監視が特に必要になる。これらをダッシュボードにまとめれば、チーム内で共有しやすくする。ダッシュボードは、わかりやすいか、主要メトリックがまとまっており、ダッシュボードを見ただけでマイクロサービスが正しく動作しているか、などが表現されているかが重要になる。担当しているマイクロサービス基盤チーム内対応できてないポイントが、すべき理由とともに明確になった。全ては難しいので、優先順位を決めてチーム内で話し合って、現実的な所から改善して行く必要がある。本書はどの現場でも利用できそうな、汎用的なチェックリストも用意されており、チェックリストから読んでいっても、読者の環境をベースにイメージする事ができると思う。スタートアップ向けの極力コストを抑えた設計まで提案から運用まで担当することが多い。最近はAWSやContainerを用いたWebサービスの設計から運用。趣味はマラソン、トライアスロン。