Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

microservicesとSRE (第2回 SRE Lounge)

1,892 views

Published on

第2回 SRE Loungeでの発表スライド。
microservicesとSREの繋がり、チャットワークでの取り組みについて話しました。

Published in: Engineering
  • Be the first to comment

  • Be the first to like this

microservicesとSRE (第2回 SRE Lounge)

  1. 1. microservicesとSRE
  2. 2. © ChatWork SRE部が発足しました http://creators-note.chatwork.com/entry/2018/01/18/080000 プロダクションレディマイクロサービス https://www.amazon.co.jp/dp/4873118158
  3. 3. © ChatWork ●microservicesとSRE ●microservicesのpros / cons ●チャットワークSREの取り組み 目次
  4. 4. © ChatWork ●microservicesとSRE ●microservicesのpros / cons ●チャットワークSREの取り組み 目次
  5. 5. © ChatWork microservices って難しい ●1つのサービスが落ちた時の全体としての影響の極小化 ○部分障害のはずが全部落ちちゃう。。。 ○全開発者が他のサービスが落ちたら、、と意識するのは難しい。 ●問題発生時のデバッグ ○1人で全部の構成を理解できるキャパシティを超える ●色んなモノを運用しないといけなくなる いやー難しい、、と言いながら場当たり的な対応に追われる日々。。
  6. 6. © ChatWork Lyft's Envoy: From Monolith to Service Mesh https://www.slideshare.net/datawire/lyfts-envoy-from-monolith-to-service-mesh-matt-klein-lyft/
  7. 7. © ChatWork microservices と SRE ●microservicesは組織が大きくなった時に選ばれやすい ●microservicesを全体として運用する手法が整っていない ●SREというポジションだと、避けては通れない問題では? ○全体障害を防ぐReliability ○問題の特定/解消を早くするReliability ○サービス全体がscaleできる基盤としてのReliability
  8. 8. © ChatWork ●microservicesとSRE ●microservicesのpros / cons ●チャットワークSREの取り組み 目次
  9. 9. © ChatWork microservicesのpros ●巨大アプリケーションの複雑性への対処 ○レガシー(レジェンド) アプリケーション問題 ○開発スピードの上昇 / コミュニケーションコストの削減 ●新しいプログラミング言語 / フレームワークの採用 ○ChatWork ではscalaを使い始めた RDBMS vs NoSQL的なトレードオフ。 組織/システムが大きくなったらtrade-offのポイントが変わる。
  10. 10. © ChatWork microservicesのcons ●逆コンウェイの法則 ●技術的スプロール ●障害の種類の増加 ●リソースの奪い合い
  11. 11. © ChatWork 民主主義は最悪の政治といえる。 これまで試みられてきた、民主主義以外の 全ての政治体制を除けばだが by チャーチル
  12. 12. © ChatWork microservciesは最悪のarchitectureといえる。 これまで試みられてきた、microservices以外の 全てのarchitectureを除けばだが by id:cw-tomita
  13. 13. © ChatWork ●microservicesとSRE ●microservicesのpros / cons ●チャットワークSREの取り組み 目次
  14. 14. © ChatWork microservicesのcons ●逆コンウェイの法則 ●技術的スプロール ●障害の種類の増加 ●リソースの奪い合い
  15. 15. © ChatWork デプロイ 中でpodが動いていることは保証するが、 何が動いているかは気にしない
  16. 16. © ChatWork データの構造、中身はサービスに依存するが、 全体の運用は統一した方が効率的
  17. 17. © ChatWork ● デプロイメント / ロギング / モニタリングの一元化 ○ 諸々の共通基盤はSREの集権管理で不要な技術的スプロールは作らない ○ 絶賛全サービスのk8s移行推進中 ● アプリケーション実装の技術選択の自由度は維持 ○ 今はscalaしか動いてないけど、PHPでも他の言語でも、同じフローに乗 れば管理コストは増えない。 ○ “技術選択の自由”と”運用の責任” のセット ● DBはどういう管理がいいのか? DBREという概念。 ○ 皆さんはどうされてますか??? 技術的スプロール vs kubernetes
  18. 18. © ChatWork microservicesのcons ●逆コンウェイの法則 ●技術的スプロール ●障害の種類の増加 ●リソースの奪い合い
  19. 19. © ChatWork 障害の種類の増加に対する取り組み ●アプリケーションに直接手を入れれるチームに ○元々ソフトウェアエンジニア寄りなメンバーがいる ○そのための工数も確保 (Falconist計画) ●sidecar(コンテナ)の導入
  20. 20. © ChatWork https://github.com/kprabhak/Talks/blob/master/Kubernetes-NYC-Meetup-June2017/Calico-Istio-Envoy.pdf https://www.slideshare.net/datawire/lyfts-envoy-from- monolith-to-service-mesh-matt-klein-lyft/15 拡大
  21. 21. © ChatWork ● microservices用sidecar ○ サービス全体としての耐障害性を高めやすい / 全体のobservability ○ サービス横断で必要なものなので、一元管理しちゃう方が楽 ○ NetflixのHystrixやLINEのArmeriaのように、実装言語に紐づいたパターン もある。 ○ (まだ全然実践できていない....) ○ (container management 覇権争いに続いて、service mesh覇権争いが勃発 中のようで、何を使うといいのかが.... Envoy / Istio / Linkerd etc….) 障害の種類の増加 vs sidecar (container)
  22. 22. © ChatWork まとめ ●microservicesとSREのつながり ●チャットワークSREの取り組み ●組織面での弱みにどう取り組むか.... 皆さんの取り組みを 聞いてみたい ●もっと泥臭い話も勿論色々あるよ!

×