Principles Of Microservices by Sam Newman を１年前に見たかった。

会社でshareされて流れてきた動画。かなり勉強になると同時に、耳の痛い所が色々とあったw。１年前に見たかったな〜としみじみと思った。ただ、後悔していても始まらないので、とりあえず、忘れないように内容のメモ。


Principles Of Microservices by Sam Newman

() 内は自分での補足や感想。

  • Microservicesの定義 -> Autonomous services that work together. 一緒に動く自立したサービスの集まり。

なぜprincipleの話をするかというと、Microservicesをやるにあたっては多くの選択/決定をしなければならないので、軸となるルールを持っておくことが大事だから。herokuのthe twelve factors的な感じ。
(これは本当そうだよな〜と。とりあえず、Microservicesだ〜と色々と分けて作ることは出来るけど、変な分け方をした所はボディブローのように苦しくなってくるし、かといって、作る前から完全に見通すのはとても難しいので、ルールに沿ってるかをチェックすることで、大きな設計ミスが防げるのはとてもいいと思うし、そこからはみ出るにしてもしっかりとした理由づけができそう。また、そういう軸があることで、設計に関する議論も、抽象的なものから、もう一歩踏み込んだ所で議論しやすいように思う。)

以下、Microservicesの原則。

  • Modelled Around Business Domain
    • Domain Driven Design is a good place to start
    • (エリック・エヴァンスの本を読み直した方が良さそう。)
  • Culture or Automation
    • Infrastructure Automation, Automated Testing, Continuous Delivery
    • 初期コストはかかるが、最初の仕組みが整えば、加速的にサービスを増やすことが可能になる。
  • Hide implementation details
    • Hide your database. 例えば、複数のアプリケーションを同じテーブルにアクセスさせると、カラムの変更が複数アプリケーションにまたがってしまうのでNG。代わりに１つのアプリケーションにだけサクセスさせ、他のアプリケーションからはAPIでデータを取得できるように。
    • 隠してる情報/フィールドをexposeするのは簡単だが、その逆は大変なので、最初はできるだけ隠す。
  • Decenterize All The Things
  • Deploy Independently
    • Most important!!!! あなたのシステムがこれができている状態なら、結構、いい感じだよ。
    • そして、これが守られていないなら、新しいサービスを足す前に、その状況を直す必要がある。 (耳がとても痛い。。)
    • 複雑性を避けるため、大体の人がone hostにmultiple application ではなく、one host, one applicationに帰結していく。 ただ、one host, one applicationは効率的なリソースの使い方とはいえないので、one host, multiple applicationを容易にする点が、dockerが人気を集めている一つの要因。
    • consumer driven contract. consumerからのserviceの使い方を両者間の契約とみなし、service側の変更では、その契約に違反していない事をルールづける。
    • https://github.com/realestate-com-au/pactcom
    • (consumer driveの話はこの記事に詳しく書いてて分かりやすかった。 サービス分割時の複雑性に対処する: テスト戦略の話 - クックパッド開発者ブログ )
    • (後でユニークIDは導入コスト高いみたいな話があったけど、これもかなり導入コスト高そうだなと思った。)
    • consumerをservice側の変更と同時にデプロイすることを強要することはNG。service側は破壊的な変更はせずに新しいAPI end-pointを用意し、consumerのupgradeを待って、古いエンドポイントを削除。 ただし、bug fixとかのservice側のメンテナンスはちょっと大変。
    • ( publicなAPIはどうすんだろう？と思ったけど、この記事で出てきたAPIs are foreverという言葉を思い出した。 10 Lessons from 10 Years of Amazon Web Services - All Things Distributed )
  • Consumer First
  • Isolate Failure
    • much easier to make less resilient, more machines, more network boundaries which can timeout. microservicesにすると、システムが堅牢になると思いがちだが、むしろ脆くなりやすい。マシンは増えるし、ネットワーク越しのやり取りも増えるから。
    • あるモノリシックな１つの巨大システムを12個に分割したけど、そのどれか１つでも止まると、全部が上手く動かなくなるという分割をした会社があった。私なら、１個の巨大サービスに戻す事をオススメする！
    • ↑のことをdistributed single point of failure って名づけた人がいた。 (この言葉は言い得て妙で、気に入ってしまった。他人事ではないがw。)
    • strangler app (level 7の振り分けのproxy layer?) を入れるパターンはあるあるだけど、そこがSPOFになりがち。一個のapplicationがthread poolを食いつぶしてしまうことで、全部のシステムがアクセス不可能になってしまう。
    • まずは妥当なtimeoutを設定しよう。
    • thread poolをapplication単位で準備するとなお良し。一つのアプリケーションがハングしても、他のアプリケーションには問題なくアクセスできるように。bulk head pattern
    • circuit breakers。エラーが繰り返される場合、timeoutを待たせるのではなく、素早くerrorを返してしまう。それにより二次災害を防ぐ。databaseアクセスにも使える。
    • (この辺は見事に踏んでた所なので、凄く納得。microservicesにすることで、異常系のパターンは増えるし、こういった仕組みも含めてしっかりとテストしないといけないな〜と。)
  • Higly Observable
    • log aggreation
    • passing through correlation ids. 処理が始まった所でユニークなIDを発行し、全てのサービスのログで記録する。逆引きして、サービス間の依存関係をvisualizeするというお洒落なことをやってる人もいた。
    • ただし、correlationが欲しくなった時にはこれを導入するコストも高いよ。デバッグが大変なくらいシステムが育ってるから必要になる訳で、ある意味必然。
    • GitHub - openzipkin/zipkin: Zipkin is a distributed tracing system


今の会社でもmicroservicesな感じで、色々分けだしているけど、障害につながったポイントや、ここ上手くいってないな〜と感じるポイントが、見事に指摘されていて、結構感動してしまった。いやー、ほんとに１年前に見たかった。。

違うイベントのだけど、多分ほぼ一緒なスライド。

www.slideshare.net

この発表者の方は、自分もちょっと前に読んだこちらの本の作者で、勿論、本のほうもとてもいいんだけど、結構なボリュームで、現在地を見失いがちになってしまったので、先にこの動画を見て、全体を把握してからこの本に出会いたかったな〜と思った。とりあえず、microservices怖くない。(ちゃんとやれば。)

Building Microservices

Building Microservices

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

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