Go! Microservices

2016.09.30 JAWS-UG-KOBE Study meeting.
Microservice architecture ことはじめ。

digest of Microservices that published by O'reilly

Transcript

1. Go! Microservices 2016.09.30 JAWS-UG-KOBE
2. Who am I? TiNm’S( ティムズ )と読みます。 プログラマー。 Ruby On Rails、AWSが主戦場。 好きなAWS サービスは、OpsWorks。 花澤香菜ちゃん好き。 JAWS-UG-KOBE の暴走運営。
3. この資料は、 マイクロサービスアーキテクチャ の各章から、(私が） 要点 (だと思ったところ） をピックアップし、AWS で実現す るにはどうするかを簡単に紹介し ます。 (時間の関係上、すべての章は紹介していませんので、ご了承ください。 )
4. アジェンダ 1. マイクロサービスとは (1章) 2. 統合 (4章) 3. モノリスの分割 (5章) 4. デプロイ (6章) 5. 監視 (8章)
5. 1. マイクロサービスとは
6. 小さくかつ１つの役割に専念 凝集度をサービスの単位で高める。 (マイクロサービスでなくても、凝集度を高めるのはオブジェクト指向の分野でも議論される内容。これをクラス単位で高めるか、 サービス単位で高めるかだけの違い。ただし、サービス単位であるほうが、インターフェースとして制限の厳密さが要求されるた め、凝集度は高めやすい。個人的には、lambda ファンクションにクラスをゴリゴリ書き出したら、不吉な匂いを感じる。） 各サービスはAPIで連携する。 ( 素直に読めば、AWSなら API Gateway で、ということになるが、AWSの場合は、SNS、SQSなど、繋ぎこむためのマネージド サービスが存在するので、すべてAPI Gatewayがいるか？と言われればそうではない。）
7. 利点 各サービスに使う言語は何でもよい。 (極端な話、サービスAはpython、サービスBはruby、サービスCはGO みたいな構成もできる。AWSの場合は、java、 javascript(node.js)、pythonの３択） 高い変更容易性 (変更はサービス単位で行うことができる。lambda ファンクションを個別にデプロイすることで対応できる。） 高い回復性 (サービス単位が小さいため、障害の範囲が限定的に抑えることができる。設計次第なところもあるが。。。多くのマイクロサービ スを連携させている場合は、CloudWatchでの監視が超重要になる。）
8. 2. 統合
9. オーケストレーションとコレオグラフィ 目指すのはコレオグラフィ (コレオグラフィとは、いわゆるPublish、Subscribeの形。AWSでは、各サービスをSNSで連携するように組めば、まさしくこの形 を実現できる。古くはCOMの概念ですよね。当時はこの概念を理解するのに時間かかったなあ、というのと、レジストリやら、実 装のめんどくささにため息をついた。何が言いたいかというと SNSは神!! ） REST (API ベースのマイクロサービスでは、REST APIを使うことによって、URIの統一性を保ちやすい。AWS では、SQS、SNS、など他 のマネージドサービスで連携できるので、実際のデータ（ほぼjsonになると思われるが) 設計に注力することができる） つづく。
10. オーケストレーションとコレオグラフィ DRY(Don’t Repeat Youself)を徹底すべきか？ (コードの重複を避けるために、共有ライブラリを作る、というのはよくある手法だが、共有ライブラリを多くのサービスが利用する 状況は、サービス間の依存度を高める。個人的な見解ではあるが、サービスが「疎結合」であることを最優先に考え、ある程度 のコードの重複は許容してもよいと感じる。） バージョニング (破壊的変更を避けるために、APIのバージョニングは必須。V1、V2など、バージョンでサービスを管理する。V1は残したまま、 V2をリリースして、時間をかけてV2に移行してもらう。AWS では、API Gateway、lambda にデプロイ機能があるので、比較的 バージョニングは容易に実現できる。） API の バージョニングについては、apigee の web-api-design が参考になる。
11. 3. モノリスの分割
12. すべては接合部次第 少しずつやる (すでに存在しているモノリシックなシステムを分割するのは難しい。できるとこからやる。） データベースも分割対象 (マイクロサービスでは、サービスが境界なので、結局複数のサービスが１つのデータベースを参照することは癒着となる。マイ クロサービス単位でデータベースも分割することが理想。RDBMS を利用する場合は、各テーブルがデータベース化するイメー ジになる。で、進めていくとやっぱりあれもこれも検索したくなる。ここをうまく分割して考えられるかが腕のみせどころ。）
13. 4. デプロイ
14. 継続的インテグレーションのマイクロサービス へのマッピング マイクロサービスごとにリポジトリを設けるべきか？ (理想は、サービスごとにリポジトリを持つこと。これにより、リポジトリとCIプロセスが1:1になる。これができない場合は、１つのリ ポジトリを用意し、複数のCIプロセスを用意する。リポジトリ：CIプロセスが1:nになる。この場合、各CIプロセスは、リポジトリの一 部分をそれぞれ参照する。GitHubにプライベートリポジトリが無限に作れるようになったのがでかい。。）
15. 5. 監視
16. サービスついてのアドバイス インバウンド応答時間の追跡 (だれか教えてください。) 下流呼び出しの応答時間、エラー率を追跡 (CloudWatch で lambda の Duration, Errorsを監視) メトリックの収集方法と場所を標準化 (CloudWatchで lambdaのメトリクスを監視) 標準的な場所にログを格納 (CloudWatch ログをS3へ格納しておく)
17. 6. まとめ
18. • 「疎結合」の最優先で考える単位がサービス • コレオグラフィ(Publish - Subscribe)モデルを目指す • データベース統合は避ける。サービスごとにデータストアも分ける。 • 1リポジトリ／1サービス • ログだけはサービスの枠を超えて標準化。メトリクス重要！
19. ありがとうございました。