マイクロサービス運用の所感について話したプレゼンテーションです。 #m3dev

1. マイクロサービス
運用の所感
Kazuhiro Sera @seratch
2015/05/22 #m3dev

2. 自己紹介
•アプリケーションエンジニア
•基盤サービス、AWS 管理、コードレビュー
•JSON API サーバ on the JVM、Rails 沢山
•Scala OSS メンテナ：Scalatra, json4s,
Scalate, Skinny Framework, ScalikeJDBC

3. マイクロサービスと私

4. #jissenscala
https://jissenscala.doorkeeper.jp/events/19660
http://www.slideshare.net/seratch/scala-jissenscala

5. マイクロサービス事例につ
いて語る瀬良氏

6. m3.com の事例

7. m3.com
・医療従事者の方々向けのポータルサイト
・多くのサブサービスを持っている

8. m3.com の構成
JSON over
HTTP
JSON over
HTTP
m3dev/octoparts
フロントエンド
JSON APIs

9. やってきたことと現状
•2012 年から段階的にモノリスから Service
に分けるということをやってきた当事者
•モノリスから剥がすメリットは十分実感
•コンポーネントの再利用性も前より高まった
•ただ、気がつけば主担当で運用するアプリが
10 以上、このまま増え続けるのか？
•リニューアルでさらに Service が増えた

10. このプレゼンテーションでは
マイクロサービス的システム群を
ある程度の期間運用してきた所感を
マイクロサービスの定義を
おさらいしつつ、紹介します

11. マイクロサービス
（Microservices）
http://martinfowler.com/articles/microservices.html

13. マイクロサービスとは？
•James Lewis 氏が提唱、2014/03 に Martin
Fowler 氏と共同で Microservices という記
事を martinfowler.com 上で公開
•モノリシック（一枚岩）な巨大なアプリケーショ
ンの運用を避けて、小さいサービス群が相互に
連携するアーキテクチャのスタイル
•SOA は ESB のソリューションの色がつきす
ぎた、Microservices はアーキテクチャスタイ
ルについて言及する用語（という私の認識）

14. Characteristics of
a Microservices

15. 1. Componentization via Services
2. Organized around Business Capabilities
3. Products not Projects
4. Smart endpoints and dumb pipes
5. Decentralized Governance
6. Decentralized Data Management
7. Infrastructure Automation
8. Design for failure
9. Evolutionary DesignArchitecture

16. 1. Componentization via
Services
•Library: プログラムにリンクされ、インメモリ
で実行可能な関数呼び出し
•Service: Web API リクエスト、RPC によっ
て連携できる独立したプロセス
•Library を一箇所で抱えずにそれぞれ Service
として独立させていこうという考え方

17. 1. Componentization via
Services
•モノリシックなアプリが多くの Library を持つ
場合、一つの Library を変更するだけで全て
の更新が必要、Library が Service に分割され
ていれば一つで済む
•Service は強制的に public interface を定義
する必要があるので不要な密結合が防げる

18. 1. Componentization via
Services
• Service 単位で適切な QA テストがされていれば、不具合
リスクはさほど高くない（ゼロではないので検知と迅速な
対応が必要）
• 全てが public interface、後方互換を維持しない変更が必
要になったときのコミュニケーションコストが高い
• API バージョンによる複数エンドポイント提供は双方に負
担がかかり、負債化しやすいのでなるべく避けている
（version はとりあえず Endpoint に入れておくが、極力
version 1 だけでいく方針）

19. 2. Organized around
Business Capabilities
•UI 担当、ミドルウェア担当、DBA のような職
能でチームを分断せず、ビジネス毎にクロスファ
ンクショナルなチームを構成すべき
•このようなチーム境界と相性がよい
• 元々、ビジネス単位のチーム構成はクロスファンクショナ
ルになっている

20. 3. Products not Projects
•開発が終わったら運用担当にお任せで Project
終了ではなく、その Product を所有する感覚
で運用にも継続的に関わるべき
• You build, you run it (Amazon)
• 自社サービスを運営する組織は元々このような考え方になっ
ているケースが多い

21. 4. Smart endpoints and
dumb pipes
•エンタープライズ向けの複雑なプロトコルより
も REST 的な HTTP API による連携を好む
•Service は UNIX の filter、request を受け、
logic を実行、response を返すだけ
•あるいは RabbitMQ/ZeroMQ のような軽量
な messsage bus を使う（非同期実行のため
の queue としての信頼性だけを求める）
• Apache Kafka を推す声があり、運用含め検討中
（まだ実戦投入はしていない）

22. 5. Decentralized
Governance
•JVM 縛り、Rails 縛りなど単一の技術プラット
フォームへの標準化を防ぎ、適材適所な技術的
な選択肢を増やすことができる
• 長く運用され続けたレガシー Java システムに JSON API
を生やして後継の Rails フロントエンドから利用し、
Service として生かし続けている事例が複数ある

23. 6. Decentralized Data
Management
•データを一箇所で管理しない、同じデータも視
点によって違う意味を持つ
•分散トランザクションは幻想、結果整合性
（Eventual Consistency）でいこう
•企業は需要に迅速に対するため、ある程度矛盾
を抱え、運用で対処できるようにしているもの、
ビジネスの実際と近いものはある

24. 6. Decentralized Data
Management
• とはいえ DBA 的な存在、リーダーシップを発揮して全体
の整合性に口を出す存在の必要性を感じる
• HTTP 経由の連携が増えたが、エラーリカバリ想定は重要
視している（最悪手動でもよい、できないは NG）
• 記事にも書かれているが、最終的には運用コストと得られ
るメリットの天 で判断する必要があるはず

25. 7. Infrastructure
Automation
•AWS をはじめとするインフラの自動化が近年
発展してきた背景から Microservices はやり
やすくなった
•モノリスで継続的デリバリーをすでにやれてい
るなら、もっと多くのアプリケーションで同じ
ことをやるのは何も恐れる必要がない
• オンプレミス中心、Ansible が好まれている

26. 8. Design for failure
•連携する別の Service のいずれかに障害が発
生したケースを想定した設計が求められる
•Microservices ではすべての Service への透
過的なリアルタイムモニタリングが障害対応の
ために非常に重要になる
•Circuit Breaker の状態、スループット、レイ
テンシーを見られるダッシュボードがあるとよ
い

27. 8. Design for failure
• 「実戦での Scala」以降、Zipkin でのトレーシングをさ
らに充実させて、フロントエンド -> Octoparts -> 会員情
報 Service まで横断で処理時間が追えるようになった
• 当初は Redis をデータストアにしていたがデータ量の増
加に対応できなくなり Cassandra に切り替えた
• https://blog.1q77.com/2015/04/setup-cassandra-
zipkin-server/
• Octoparts は Hystrix の Circuit Breaker の状態を可視
化する UI を提供、各 Service の運用エンジニアにアラー
ト通知も行っている

28. Zipkin
ここからドリルダウンして
メソッド単位まで追える

29. Hystrix Circuit

30. 9. Evolutionary Design
•リリースサイクルのアジリティを失うことなく、
アプリを変更し続けたい、モノリスのリリース
プロセスは鈍重になりがち
•期間限定のものはモノリスよりも Service と
して実装して、終わったら捨てる方が合理的
•進化的設計は XP の文脈で Martin Fowler が
計画的設計（Planned Design）に対して
2004 年に提唱した概念

31. 9. Evolutionary Design
• リリース日が固定されているモノリスから Service として
切り出したシステムはそれよりも早いサイクルでリリース
できるようになった
• 期間限定と思っていたはずが、結果的には長期間運用する
ことになるのはありがちなパターン、長期運用できない
Service にはならないようにすべき

32. いくつかの問題意識

33. 手段と目的
• しがらみなく手っ取り早く仕事を始められるのはよいこと
• 中長期的にはコミュニケーションコストを中心に運用のコ
ストが増える傾向がある、小規模な組織には重たい
• 2 年後の運用が想像できそうか？
• 再利用性の向上、共通化によるメンテコスト削減など実利
がなく、単に「開発効率が高まる」という理屈は長い目で
見ると正しくないケースが多そう
• →Service にすべきか・粒度・設計など事前に議論する

34. オーナーシップ
• 「3. Products not Projects」の「所有者として運用に関
わる」はうまくやらないと難しくなるケースがある
• モノリスと向き合うチームのメンバは戦友かつ共犯者（コー
ドベースの中に自分が関わった場所がある）
• 全くコードをいじったことのない Service にどこまでオー
ナーシップを持てるか？チーム構成が重要になる
• メンバの入れ替わりを経て片隅のあの Service の責任者、
実はあやふやになっていた？
• →Service の一覧、主担当を明確にする

35. ブラックボックス化
• 内部実装がブラックボックス化するリスクがある
• 新規立ち上げ時にカウボーイスタイルになるリスク（特に
新しい技術導入時）
• Service に局所的な対処に陥っていないか？（例：同じよ
うなことを別の Service でもやっていたと後で知る）
• 障害時のトラブルシューティングが難しくなっていないか？
適切なログ出力やモニタリングの強化がより重要になる
• →Service 立ち上げ時に設計レベルでレビュー

36. テスト
• 他の Service との結合テストで初めて動作検証ができる
• 場合によっては異常系のテストパターンの洗い出しが複雑
になる（例：重要度の高い Service とそうでない Service
とでエラー処理の方針が違う）
• 自信を持って大丈夫だと言い切れるのは E2E テスト
• →テストエンジニアによる Selenium テストの取り組み

37. コミュニケーション
• 「コード読め」がそもそもどこの処理かすぐには り着け
なくなる（例：呼んだ Service のその先で呼んでる
Service にロジックがあってそこのレアパターンだった）
• 誰に聞けばいいかすぐにわかるようになっているか？チー
ム間のコミュニケーションコストが上がっていないか？
• コストをかけず、陳腐化しないドキュメントの整備・運用
（Swagger をある程度使っているがまだまだ）
• 全体像を把握している人（必要な情報にもれなくアクセス
する方法を知っていて意思決定できる人）がいるか？
• →問い合わせ先を整理、ドキュメントの整備

38. まとめ
•SOA がエンタープライズな話題に寄り過ぎて
いる間 Microservices 的な実践は既にあり、
それがうまく言語化された
•中規模以上の組織での問題解決の手法である
•自分たちの組織を冷静に見つめ、合うやり方と
適切な Service の粒度を見定めたい