マイクロサービス運用の所感 #m3dev
TRANSCRIPT
マイクロサービス 運用の所感
Kazuhiro Sera @seratch 2015/05/22 #m3dev
自己紹介
•アプリケーションエンジニア •基盤サービス、AWS 管理、コードレビュー • JSON API サーバ on the JVM、Rails 沢山 • Scala OSS メンテナ：Scalatra, json4s, Scalate, Skinny Framework, ScalikeJDBC
マイクロサービスと私
#jissenscala
https://jissenscala.doorkeeper.jp/events/19660http://www.slideshare.net/seratch/scala-jissenscala
“マイクロサービス事例について語る瀬良氏”
m3.com の事例
m3.com
・医療従事者の方々向けのポータルサイト・多くのサブサービスを持っている
m3.com の構成
JSON over HTTP
JSON over HTTP
m3dev/octoparts
フロントエンドJSON APIs
やってきたことと現状
•2012 年から段階的にモノリスから Service に分けるということをやってきた当事者
•モノリスから剥がすメリットは十分実感 •コンポーネントの再利用性も前より高まった •ただ、気がつけば主担当で運用するアプリが 10 以上、このまま増え続けるのか？
•リニューアルでさらに Service が増えた
このプレゼンテーションでは マイクロサービス的システム群を ある程度の期間運用してきた所感を
マイクロサービスの定義を おさらいしつつ、紹介します
マイクロサービス （Microservices）
http://martinfowler.com/articles/microservices.html
マイクロサービスとは？• James Lewis 氏が提唱、2014/03 に Martin Fowler 氏と共同で “Microservices” という記事を martinfowler.com 上で公開
•モノリシック（一枚岩）な巨大なアプリケーションの運用を避けて、小さいサービス群が相互に連携するアーキテクチャのスタイル
• SOA は ESB のソリューションの色がつきすぎた、Microservices はアーキテクチャスタイルについて言及する用語（という私の認識）
Characteristics of a Microservices
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
1. Componentization via Services
• Library: プログラムにリンクされ、インメモリで実行可能な関数呼び出し
• Service: Web API リクエスト、RPC によって連携できる独立したプロセス
• Library を一箇所で抱えずにそれぞれ Service として独立させていこうという考え方
1. Componentization via Services
•モノリシックなアプリが多くの Library を持つ場合、一つの Library を変更するだけで全ての更新が必要、Library が Service に分割されていれば一つで済む
• Service は強制的に public interface を定義する必要があるので不要な密結合が防げる
1. Componentization via Services
• Service 単位で適切な QA テストがされていれば、不具合リスクはさほど高くない（ゼロではないので検知と迅速な対応が必要）
• 全てが public interface、後方互換を維持しない変更が必要になったときのコミュニケーションコストが高い
• API バージョンによる複数エンドポイント提供は双方に負担がかかり、負債化しやすいのでなるべく避けている（version はとりあえず Endpoint に入れておくが、極力 version 1 だけでいく方針）
2. Organized around Business Capabilities
• UI 担当、ミドルウェア担当、DBA のような職能でチームを分断せず、ビジネス毎にクロスファンクショナルなチームを構成すべき
•このようなチーム境界と相性がよい• 元々、ビジネス単位のチーム構成はクロスファンクショナルになっている
3. Products not Projects
•開発が終わったら運用担当にお任せで Project 終了ではなく、その Product を所有する感覚で運用にも継続的に関わるべき
• “You build, you run it” (Amazon)• 自社サービスを運営する組織は元々このような考え方になっているケースが多い
4. Smart endpoints and dumb pipes
•エンタープライズ向けの複雑なプロトコルよりも REST 的な HTTP API による連携を好む
• Service は UNIX の filter、request を受け、logic を実行、response を返すだけ
•あるいは RabbitMQ/ZeroMQ のような軽量な messsage bus を使う（非同期実行のための queue としての信頼性だけを求める）
• Apache Kafka を推す声があり、運用含め検討中（まだ実戦投入はしていない）
5. Decentralized Governance
• JVM 縛り、Rails 縛りなど単一の技術プラットフォームへの標準化を防ぎ、適材適所な技術的な選択肢を増やすことができる
• 長く運用され続けたレガシー Java システムに JSON API を生やして後継の Rails フロントエンドから利用し、Service として生かし続けている事例が複数ある
6. Decentralized Data Management
•データを一箇所で管理しない、同じデータも視点によって違う意味を持つ
•分散トランザクションは幻想、結果整合性（Eventual Consistency）でいこう
•企業は需要に迅速に対するため、ある程度矛盾を抱え、運用で対処できるようにしているもの、ビジネスの実際と近いものはある
6. Decentralized Data Management
• とはいえ DBA 的な存在、リーダーシップを発揮して全体の整合性に口を出す存在の必要性を感じる
• HTTP 経由の連携が増えたが、エラーリカバリ想定は重要視している（最悪手動でもよい、できないは NG）
• 記事にも書かれているが、最終的には運用コストと得られるメリットの天秤で判断する必要があるはず
7. Infrastructure Automation
• AWS をはじめとするインフラの自動化が近年発展してきた背景から Microservices はやりやすくなった
•モノリスで継続的デリバリーをすでにやれているなら、もっと多くのアプリケーションで同じことをやるのは何も恐れる必要がない
• オンプレミス中心、Ansible が好まれている
8. Design for failure
•連携する別の Service のいずれかに障害が発生したケースを想定した設計が求められる
•Microservices ではすべての Service への透過的なリアルタイムモニタリングが障害対応のために非常に重要になる
• Circuit Breaker の状態、スループット、レイテンシーを見られるダッシュボードがあるとよい
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 の運用エンジニアにアラート通知も行っている
Zipkin
ここからドリルダウンしてメソッド単位まで追える
Hystrix Circuit
9. Evolutionary Design
•リリースサイクルのアジリティを失うことなく、アプリを変更し続けたい、モノリスのリリースプロセスは鈍重になりがち
•期間限定のものはモノリスよりも Service として実装して、終わったら捨てる方が合理的
•進化的設計は XP の文脈で Martin Fowler が計画的設計（Planned Design）に対して2004 年に提唱した概念
9. Evolutionary Design
• リリース日が固定されているモノリスから Service として切り出したシステムはそれよりも早いサイクルでリリースできるようになった
• 期間限定と思っていたはずが、結果的には長期間運用することになるのはありがちなパターン、長期運用できない Service にはならないようにすべき
いくつかの問題意識
手段と目的
• しがらみなく手っ取り早く仕事を始められるのはよいこと • 中長期的にはコミュニケーションコストを中心に運用のコストが増える傾向がある、小規模な組織には重たい
• 2 年後の運用が想像できそうか？ • 再利用性の向上、共通化によるメンテコスト削減など実利がなく、単に「開発効率が高まる」という理屈は長い目で見ると正しくないケースが多そう
• →Service にすべきか・粒度・設計など事前に議論する
オーナーシップ
• 「3. Products not Projects」の「所有者として運用に関わる」はうまくやらないと難しくなるケースがある
• モノリスと向き合うチームのメンバは戦友かつ共犯者（コードベースの中に自分が関わった場所がある）
• 全くコードをいじったことのない Service にどこまでオーナーシップを持てるか？チーム構成が重要になる
• メンバの入れ替わりを経て片隅のあの Service の責任者、実はあやふやになっていた？
• →Service の一覧、主担当を明確にする
ブラックボックス化
• 内部実装がブラックボックス化するリスクがある • 新規立ち上げ時にカウボーイスタイルになるリスク（特に新しい技術導入時）
• Service に局所的な対処に陥っていないか？（例：同じようなことを別の Service でもやっていたと後で知る）
• 障害時のトラブルシューティングが難しくなっていないか？適切なログ出力やモニタリングの強化がより重要になる
• →Service 立ち上げ時に設計レベルでレビュー
テスト
• 他の Service との結合テストで初めて動作検証ができる • 場合によっては異常系のテストパターンの洗い出しが複雑になる（例：重要度の高い Service とそうでない Service とでエラー処理の方針が違う）
• 自信を持って大丈夫だと言い切れるのは E2E テスト • →テストエンジニアによる Selenium テストの取り組み
コミュニケーション• 「コード読め」がそもそもどこの処理かすぐには辿り着けなくなる（例：呼んだ Service のその先で呼んでる Service にロジックがあってそこのレアパターンだった）
• 誰に聞けばいいかすぐにわかるようになっているか？チーム間のコミュニケーションコストが上がっていないか？
• コストをかけず、陳腐化しないドキュメントの整備・運用（Swagger をある程度使っているがまだまだ）
• 全体像を把握している人（必要な情報にもれなくアクセスする方法を知っていて意思決定できる人）がいるか？
• →問い合わせ先を整理、ドキュメントの整備
まとめ
•SOA がエンタープライズな話題に寄り過ぎている間 Microservices 的な実践は既にあり、それがうまく言語化された
•中規模以上の組織での問題解決の手法である •自分たちの組織を冷静に見つめ、合うやり方と適切な Service の粒度を見定めたい