microservicesとSRE (第２回 SRE Lounge)
•Download as PPTX, PDF•
0 likes•3,153 views
第２回 SRE Loungeでの発表スライド。 microservicesとSREの繋がり、チャットワークでの取り組みについて話しました。
Recommended
More Related Content
Similar to microservicesとSRE (第２回 SRE Lounge)
Similar to microservicesとSRE (第２回 SRE Lounge) (20)
microservicesとSRE (第２回 SRE Lounge)
- 3. © ChatWork ●microservicesとSRE ●microservicesのpros / cons ●チャットワークSREの取り組み 目次
- 4. © ChatWork ●microservicesとSRE ●microservicesのpros / cons ●チャットワークSREの取り組み 目次
- 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. © ChatWork microservices と SRE ●microservicesは組織が大きくなった時に選ばれやすい ●microservicesを全体として運用する手法が整っていない ●SREというポジションだと、避けては通れない問題では？ ○全体障害を防ぐReliability ○問題の特定/解消を早くするReliability ○サービス全体がscaleできる基盤としてのReliability
- 8. © ChatWork ●microservicesとSRE ●microservicesのpros / cons ●チャットワークSREの取り組み 目次
- 9. © ChatWork microservicesのpros ●巨大アプリケーションの複雑性への対処 ○レガシー(レジェンド) アプリケーション問題 ○開発スピードの上昇 / コミュニケーションコストの削減 ●新しいプログラミング言語 / フレームワークの採用 ○ChatWork ではscalaを使い始めた RDBMS vs NoSQL的なトレードオフ。 組織/システムが大きくなったらtrade-offのポイントが変わる。
- 13. © ChatWork ●microservicesとSRE ●microservicesのpros / cons ●チャットワークSREの取り組み 目次
- 17. © ChatWork ● デプロイメント / ロギング / モニタリングの一元化 ○ 諸々の共通基盤はSREの集権管理で不要な技術的スプロールは作らない ○ 絶賛全サービスのk8s移行推進中 ● アプリケーション実装の技術選択の自由度は維持 ○ 今はscalaしか動いてないけど、PHPでも他の言語でも、同じフローに乗 れば管理コストは増えない。 ○ “技術選択の自由”と”運用の責任” のセット ● DBはどういう管理がいいのか？ DBREという概念。 ○ 皆さんはどうされてますか？？？ 技術的スプロール vs kubernetes
- 21. © ChatWork ● microservices用sidecar ○ サービス全体としての耐障害性を高めやすい / 全体のobservability ○ サービス横断で必要なものなので、一元管理しちゃう方が楽 ○ NetflixのHystrixやLINEのArmeriaのように、実装言語に紐づいたパターン もある。 ○ (まだ全然実践できていない....) ○ (container management 覇権争いに続いて、service mesh覇権争いが勃発 中のようで、何を使うといいのかが.... Envoy / Istio / Linkerd etc….) 障害の種類の増加 vs sidecar (container)
Editor's Notes
- SRE部の発足にあたり、私なりに色々と考えてブログを書いた & 今回、この場に参加するきっかけともなったのですが、これを書く前に読んどきたかったなーっていう本が最近あったので、今日はブログの内容とこの本の内容をミックスするような形で、発表したいと思います。 ちなみにこの本を既に読んだーっていう方はどれくらいいますか？ microservices的なのもの / どんどんスケールするシステムを上手く運用したいってのが、私の大きなモチベーションとしてあり、全体の内容が理想に向けて少し偏っていますが、SRE本でのトイル的なもっと泥臭いことも勿論色々やってますし、時間の関係で紹介しきれませんが、他にも色々な取り組みが検討/進んでいますので、その辺は懇親会などでお話できればと！
- ということで始めたいと思います。こちらが今日話す内容の目次になります。 SRE Loungeなのにmicroservices? と？？になっている可能性もあるかと思いますので、まず、この２つの繋がりに関して私なりの考えを説明したいと思います。 そのあと、microservicesのpros/consを改めて振り返った後に、 最後にチャットワークがどのような取り組みを行なっているか / 行っていこうとしているかを紹介したいと思います
- では、まず、microservicesとSREの繋がりについてです
- 経験ある人同士でしか中々伝わりづらいものがありますが、microservicesは難しいです。 前職からmicroservices的なシステムな運用をしてたり、 ChatWorkでも基幹のメッセージング部分を切り分けるというのが入社した頃に丁度リリースされたり、 とそれなりの付き合いはあるんですが、上手くできてる！って感触はまだ味わったことがありません。 例えばこんなような問題があります。 ：
- 皆んなはどうやってるんだろうなーとあれこれと勉強したり、他社の事例を見ていく中で、 ある日、このプレゼンテーションに出会いました。 この問題に対処するため、Envoyというものを作ったというプレゼンテーション。LyftのMattさんという人。 エンジニアとして、真っ向から問題に立ち向かい、microservicesなシステムを上手く運用するためのミドルウェアを作った。 泥臭い運用をずっとやっていた中で、改善策としてこれを作り出したようです。 SREというかエンジニアとしてのあるべき姿を見せつけられた感じで、これに結構な衝撃を受けて、自分の問題意識というか、姿勢が少し変わりました。
- この後も少し触れますが、組織/システムが大きくなっていく中で、microservicesってのは選ばれやすい選択肢であり、だからこそ多くの企業が採用していわけですが、それをどのように効率的にソフトウェアを使って運用していくのか。 それをしっかり考えて実践したいなーというのが、今の私の大きな課題/モチベーションであり、また、逆説的ではありますが、microservicesが必要なっくらい大きな組織だからこそ、SREというポジションがあると思うので、となれば、SREチームがここに立ち向かうことは不可避ではないかと思っています。 というようなところから、今日の発表のタイトルがmicroservicesとSREにしてみました。
- ここで少し話を変えて、次にmicroservicesについてさらっと振り返りたいと思います。
- microservicesとは〜？ や、microservicesのprosについてのは、多くの情報があり皆さんご存知なことも多いと思いますし、 また、これはこれで色々と議論に繋がってしまう所で、そこは今回の本題では無いので、この場ではさらっと流してしまいますが、ざっくり、こちらに挙げているような強みがあると思います。 １つ目は、、、 ちなみに、レガシーアプリケーションじゃなくて、長い間使われ続ける価値を生み出して来たアプリケーションなんだから、レジェンドアプリケーションとよぼうってのをどっかのtweetで見かけていいなーと思ったので、ここで紹介しておきます。 ２つ目は、、、 チャットワークではメッセージのデータベースをAuroraから、少し複雑にはなるけどscale outに強いHBaseに移行するというプロジェクトがありましたが、ここのトレードオフに近いことがシステム全体としても起こるポイントがあるのではないかと思います。
- とはいえ、microservicesも１つのアーキテクチャであり、そこには必ずtrade-offがあります。 先に紹介した「プロダクションレディマイクロサービス」では、こちらの４点がconsとして挙げられていて、上手くまとまっているなと思ったので引用しました。 目次では書籍の目次としては、”組織的な課題” という章にまとめられていましたが、システム的な課題として捉えられる部分もあるなと思いました。 ざっくりと紹介していくと、 ・逆コンウェイの法則 -> microservicesにコンウェイの法則を割り当てるならば、各開発者は自分のサービスのみを気にしとけばよいという状態にあるべきだけど、実際のサービスは他のサービスとして連携して動くものであり、システム全体として無駄なくfunctionalであるためには、密に頻繁にコミュニケーションをとる必要がある。が、実際は各サービス毎にOKRなどが設定されてしまうため、実際は達成が難しい。という話です。 ・技術的スプロール -> サービスが増えてくる毎に利用する技術スタックが増えてしまって大変だよね。。という話。これは新しい技術を使えるという所と表裏一体なので、うーんっていう気持ちも少しあるけど、まあ、なんでもかんでも投入しまくればいいってわけではないよねと。ここに関しては後ほど少し触れます。 ・障害の種類の増加 -> ここにいる方々であればイメージ共有しやすいと思いますが、サービス分けることに、おー、ここで落ちるか。。。とか、ここがダメになると、こうなるんかーみたいのってありますよね。。人の数だけ障害パターンがあるんじゃないかと思いますw。ここに関しても後ほど少し触れます。 ・リソースの奪い合い -> サーバリソースや人のリソースの奪い合いが起きるよねと。。microservices的にシステム上のレイヤーではなく、サービスレイヤーで人を割り当てていくと、確かにこれは起こりますよね。。ちょっと話はそれますが、そういえば、Amazonのmeeupに出た時、採用自体もチーム毎になっていたことを思い出しました。”Amazon point” で採用がある。その時は何にも思いませんでしたが、その辺の権限/責任の割り当て方もドラスティックだなと〜、改めて考えてみると凄いです。
- このように、microservicesにはたくさんのconsがありますが、、 映画化で日本人のメークの人がアカデミー賞をとって話題になっている、チャーチルが民主主義をこのように称したように、
- システムが巨大化していく時、microservicesもそれ以外に解がないというのが実際の所と思います。
- チャーチルが民主主義を最悪と言いながらもその中でより良い政治/世界を目指したように、我々もより良いmicroservicesを目指す必要があります。 最後にチャットワークのSREの取り組み / 取り組んでいきたいことをいくつか紹介したいと思います
- 少し戻って、さっきあげた4つのconsをもう一度みてみましょう。 ４つの項目が挙げられていましたが、”技術的スプロール” と “障害の種類の増加” に関しては、技術的な取り組みから軽減できるポイントと思っています。ここに対する取り組みに対して、ChatWorkのSREチームとしてやっていること / やろうとしていること を簡単に紹介したいと思います。
- 技術的スプロールに対する取り組みの１つはkubernetesの導入です。 ・どんなアプリケーションが乗せられることになっても、追加するのは均一なworker node ・デプロイメント / ロギング / モニタリングの一元化 (デプロイはconcurse/helm、ロギングはstackdriver, メトリクスはdatadog) ・その上で動くアプリケーションに関しては (基本的には) 関わらない / 気にしない ということで、統合できる部分は統合して不要な技術的スプロール(デプロイの方法、何個も要らないよね？的な)は避けると共に、各アプリケーションの運用自体は各チームである程度面倒をみるという前提で、アプリケーションの実装に関する自由度は残すことができます。自由と責任は表裏一体の存在であるので、何か、自由を得ることで責任も追加されるという、とても健全な状態と言えると思います。 現状、scalaのアプリケーションは全てk8s上で動いていますが、PHPのアプリケーションの移行計画もすでにあり、早く全サービスをk8sで一元管理できるようにしたいと思っています。 また、kubernetesの運用に関して深く話す時間はありませんが、弊社では１年以上、サービスの真ん中にkubernetesを置いて本番運用してきていて、本日出席している坂本が色々とネタを持っていますので、話を聞きたい方や、他にイベントを企画している方など、ぜひ、この後、お話いただければと思っています。
- 技術選択の文脈から少し派生して、ChatWorkではAurora RDSに加えて、HBaseやkafkaといったデータストレージの運用も行っています。 厳密には、データ構造/中身は各サービスに帰属するものなので、各サービスに意思決定/運用を任せたい気はするけど、データストレージの運用としては、どこかが一括管理する方が効率的であったりもします。これまでの経緯からChatWorkではSREチームがここも担当しています。 が、例えば、データ設計は適切かといったレビュー、重いクエリが流れていないかといった調査 / kafkaをもっとガンガン使いたい、データストレージの種類増やしたいといったような要望等は、各サービスのコンテキストによる所も大きいと思うし、どうなって行くのがいいのかなーというのは、限られたリソースの中で全てのデータストレージに対しての指標を出すってのは現実的に厳しく、どのような方向性がいいのか試行錯誤中です。 ここに対する一つの解として、”Database Reliability Engineering” のような概念も出てきていたりもしますが、ここは皆さんどのように区分けされているのか是非伺ってみたいです。
- 文字でまとめてみました。 (ここはまあ適当に)
- 次は”障害の種類の増加”に関してです
- こちらは２つの取り組みを考えています。前者は進行中で後者はまだまだこれから、、、といった感じです。 前者の方は実際、今日参加している尾崎、大阪にいる安達が元々はPHPのアプリケーション側の部署のメンバーであることから、実際にソースコードベースでの調査をしたり、Sscalaのアプリケーションに関してはまだガッツり見れるメンバーがいないので工数を確保して、開発チームのソフトウェア改善スプリントに参加するという形で、dev <-> SREの垣根をなくしつつも、耐障害性に関する改善はSRE部だけで独立で行えるようにという、チームの機動力を高めるということを行いたいと思っています。 scalaのメッセージング部分はfalconと呼ばれるサブシステムになっているので、falconを扱える人、という意味でfalconistになる！っていうのを個人OKRに掲げていたりします。
- “障害の種類の増加” に対するもう一つの解はsidecar containerの導入です。 sidecarパターンはmicroservicesのデザインパターンの一つで、cacheやリバースプロキシのためにnginxを色んなアプリケーションサーバのフロントに置くってのが、みなさん経験・聞いたことある事例かと思いますが、nginxの代わりに、microservicesに特化した機能を持ったproxyをアプリケーションの入口/出口に置こうよという感じです。 こちらは正直、調査中というステータスで、まだ諸々の情報を収集しているだけ、、というステータスですが、 microservicesを運用するにあたって必要な機能を持たせたsidecarを色んなアプリケーションの入口/出口に立てて、適切なtimeout / circuit breaker / 分散tracing 等々の機能を持たせることで、各サービス開発の人は全体としての耐障害性をそこまで意識することなく各サービスに集中してもらいつつ、microservicesの強みを引き出した & observabilityの高いシステムを最小限のコストで作れるのでは？ と考えています。 ちなみにEnvoyの作者であるMattさんによると、UberはDBアクセスにもEnvoyを通すという形になっているそうです。こうすることでDBが不調になった時のエラー判定が早くなり、サービス全体への影響の波及を防げたり、リトライ等により、DBを過負荷にすることを防げると。webアプリケーションであれば、フロントにnginx等を立てて受け側でこういった対応を入れることも可能ですが、データストレージにそれを求めるのは厳しいので、アクセスする側で後ろのリソースの状況に応じたアクセス制御するってのはとても良さそうです。 microservicesの波にのってサービス分けてみたけど、結局どっかが落ちると、全部落ちゃった、、、みたいのはよくある(?)パターンな気がしますが、耐障害性の高いシステムを作る上で、こういったレイヤーを透過的に一元管理で導入することができれば、システムのレベルを上げることに繋がると思っています。 また、ここのレイヤーを分けてSREで管理することで、各サービスの開発者は耐障害性というところはあまり気にせずに、各機能を作りこむってところに注力、、、ってことが出来るといいなーと思っています。
- 文字でまとめてみました (適当に振り返りつつ) ちなみに、LineのArmeriaは先日、別イベントで紹介されているのを聞いてきましたが、microservicesに止まらない、色んな機能盛り盛りの凄いフレームワークでした。 sidecar 概念としてはとても魅力的 / 合理的に思えますが、まだまだ発展途上中ということで、手の出し方を迷っています。積極的に情報交換したいところです。。 私自身は、Envoyの作ったLyftのMattさんのプレゼンを聞いて、おー、これぞSREの鏡だなーと深く感銘したので、できればそれに乗っかりたい気持ちではいます。ちなみにこのMattさん９月のbuildersconというイベントにいらっしゃるそうで、それまでに最低でも検証は終わらせてMattさんと握手したいという個人的(?)目標もあります。
- 最後にまとめです。 microservicesとSREという観点からあれこれと話して、 チャットワークとしての取り組みをいくつか紹介しました。 microservicesな組織面の課題に関しては、時間の関係もあり、あまり触れませんでしたが、正直、試行錯誤な部分も多く、また、皆さん色々と悩まれている所もあると思うので、この後、色々とお話や取り組みを伺ってみたいです。 今回の発表は、microservicesに偏った内容になっていますが、SRE本でのトイル的なもっと泥臭いことも勿論色々やってますので、その辺のお話も色々としたいです！ ありがとうございました。