Recommended
More Related Content
What's hot
What's hot (19)
Viewers also liked
Viewers also liked (14)
Similar to マイクロサービス運用の所感 #m3dev
Similar to マイクロサービス運用の所感 #m3dev (20)
More from Kazuhiro Sera
More from Kazuhiro Sera (20)
Recently uploaded
Recently uploaded (9)
マイクロサービス運用の所感 #m3dev
- 2. 自己紹介 •アプリケーションエンジニア •基盤サービス、AWS 管理、コードレビュー •JSON API サーバ on the JVM、Rails 沢山 •Scala OSS メンテナ：Scalatra, json4s, Scalate, Skinny Framework, ScalikeJDBC
- 3. マイクロサービスと私
- 6. m3.com の事例
- 8. m3.com の構成 JSON over HTTP JSON over HTTP m3dev/octoparts フロントエンド JSON APIs
- 9. やってきたことと現状 •2012 年から段階的にモノリスから Service に分けるということをやってきた当事者 •モノリスから剥がすメリットは十分実感 •コンポーネントの再利用性も前より高まった •ただ、気がつけば主担当で運用するアプリが 10 以上、このまま増え続けるのか？ •リニューアルでさらに Service が増えた
- 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 の運用エンジニアにアラー ト通知も行っている
- 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 の粒度を見定めたい