[Day 1: B-8] Microservices Maturity Model on Rails


yhirano55

登壇者: 株式会社FiNC 森 久太郎 氏

マイクロサービスに関連する話題は技術論・組織論など多岐にわたるため、組織がその全ての能力を一朝一夕にして獲得することは不可能であり、段階的に習得していく必要があります。本セッションでは、FiNC社においてRuby on Railsを利用したマイクロサービスを構築してきた実践例(失敗も含む)に基づき、マイクロサービスの「成熟度モデル」を捉え、各ステージによってどのような能力を獲得していくべきか、をいろいろな側面から論じます。これからマイクロサービスの導入を検討している・導入し始めた、という方を主な想定リスナーとしています。

https://techplay.jp/event/639872


  • このセッションに関する質問を募集中です
  • 事前に聞きたいことがあれば、何でも書き込んでください。
  • 質問への回答はお約束できません。あらかじめご了承ください

Like(1)

Questions and feedbacks (6)

qsona
qsona commented over 1 year

@yhirano55 会場でも一部お答えできましたが、もう一度自分なりに整理して回答してみます。

現在、Lv3だとすると、Lv4の条件を満たすのに何が必要ですか? (技術的と組織的の2面で)

まず技術面から。

Day 2でCookpadの小野さんのObservability engineergingの話がまさに該当しそうです。サービスメッシュの話などは正直自分も余り追えていなくて、うかつなことは言えない情勢ですw

1つあげるなら、レジリエンス(回復性)です。 Stable Dependencies Principle (SDP), 安定依存原則, というのがありますが、マイクロサービスにおいても、自分より安定しているサービスに依存するか、そうでなければ相手のサービスが不安定だったりするときのことを考えて適切に対処する必要があると思います。サーキットブレーカーを導入するなどの話もありますが、それ以上に、プログラミング上で適切に例外を処理していくことが難しいところになります。単純にサービス開発において考えることが増えるし、細かい仕様の詰めなど、(広義の)技術レベルが要求されます。

組織面については、横断的なことに対しても対処するチームが必要になってくると思います。横断技術基盤みたいなチームはなかなかワークさせにくいので、現場とのつなぎ方や目的の設定の仕方などに工夫が必要だと思います。この辺は試行錯誤しています。ただちょっとLv.4の組織については自分も未知なことが多いですね、そんな組織になったと胸を張れるようになったらまた発表したい。

Like(1)

yhirano55

現在、Lv3だとすると、Lv4の条件を満たすのに何が必要ですか? (技術的と組織的の2面で)

Like(1)

yhirano55

@qsona ご回答ありがとうございます。セッションでも触れていただけることありがたく思います(体系的な話が聴けそうで楽しみです)。サービス間での依存関係も発生しそうなので、デプロイもひと工夫必要そうですね。

いまのところほぼ全てRails

ある程度使う道具を統一していた方が、コードレビューする際にコンテキストスイッチが発生しなくてよさそうですね。

セキュリティパッチが当たったgemを全部上げる、みたいなケース

PR作るところまでは自動化できそうですが、急ぎの場合に、それをレビューして取り込むのも大変そうですね

Like(1)

qsona
qsona commented over 1 year

すいません、長すぎて切れたようなので分割します。

  • 2桁以上のrailsアプリケーションを保守する場合、アップグレードや依存ライブラリの定期アップデートに骨が折れそうな印象ありますがどのような工夫をしていますか?
    • はい、これは絶賛困ってます。Railsのメジャーバージョンアップとかそういうのは、影響範囲が見切れるので逆に楽なんですけど、セキュリティパッチが当たったgemを全部上げる、みたいなケースで面倒を感じますね。エンジニアの頭数とサービス数のバランスが良ければ、そんなに問題ではなさそうなのですが。(いまのところエンジニアの数 < サービス数なので)

追記: 長さではなく < 文字の前にスペースを入れてなかったのが原因でした、失礼しました 🙇

Like(1)

qsona
qsona commented over 1 year

事前質問ありがとうございます。参考にさせていただいて本編でも触れさせていただきますが(ほとんどが自然に取り込めそうです)、先に簡単に返答させていただきます。

  • どのような粒度でサービスを分割していますか?(あるいはどのような粒度で分割するのが良いですか?)
    • 一言でいうと、ビジネスとして独立できる単位、なのですが、分割の単位は非常に重要だと思っているので本編でもメインで触れる予定です。
  • 言語やフレームワークが異なる場合、メンテしにくくなりそうですが、そこはどのように対応していますか?
    • いまのところほぼ全てRailsです。これはRails以外を使うインセンティブがそこまで強いケースがいまのところないからです。ただ、いつでも他の言語を使ったサービスを作れるような状態を維持しています。これも関連する話ができそうです。
  • 現在刊行されているマイクロサービスに関する書籍で、これからマイクロサービスに取り組むチームに薦めたい一冊はありますか?
  • サービスとデータストアは1:1になっているのですか?
    • はい、1:1 (もしくは 1:n) で、サービス間での共有はしていません。「いかなる場合でもデータベースを共有しない」は、マイクロサービスをやるときに最も重要なPrincipleだと思っています。過去1度だけですが共有してしまって、今つらい、という話もあるんですが、時間があれば本編で触れたいです。
  • テストはモックすればなんとかなりそうですが、ローカルで立ち上げるの辛そうに見えますがどのように対応していますか(特に非エンジニア職でローカルでの動作環境を作らないと作業ができない場合はしんどそう)
    • これは難しいですよね・・・本当に難しい。前提としては、全サービスを詰め込んだdocker composeを作るみたいなアプローチは厳しい(ローカルで動かすにはメモリが足りなくなる)ので、作業に必要な単位でのdocker composeを用意する、みたいな感じになると思うんですが、今のところそこまで必要性がなくて私はやっていないです。
  • 1リポジトリに複数サービスを同居させて管理しているのでしょうか(repoとサービスが1:1?)
    • 弊社では1:1です。まずデプロイは分離するべきなので、リポジトリの単位もそれに従って分けるのが自然だと思います。1チームが複数のマイクロサービスを管理する場合はくっつけておいたほうが管理しやすいこともあると思いますが、チームとマイクロサービスのマッピングが変わったりすることもあるので逆に面倒そうな気はします。
  • railsはapiモードで利用していますか?
    • apiしか使わないならapiモードでrails newするが、apiモードにこだわるべきでは決してない、というのが私の意見です。似たような話題を触れる予定だったのですが、apiモードを使う/使わない、というテーマでよりrails的な話にできるので、良い視点をいただきました。
  • 多くのサービスでrailsを利用している場合、rails newすることが多いと思うのですが、そのセットアップの手間を省くための工夫として、何か取り組みはされていますか?(テンプレートなど)
    • application templateを作ってようやく使われるようになってます。これも触れる予定でしたが onkさんの Application Templateのススメ という発表の特に後半の話がすごく好きです。

Like(2)

yhirano55

マイクロサービス初学者の視点で、ちょっと気になっていることです。

  • どのような粒度でサービスを分割していますか?(あるいはどのような粒度で分割するのが良いですか?)
  • 言語やフレームワークが異なる場合、メンテしにくくなりそうですが、そこはどのように対応していますか?
  • 現在刊行されているマイクロサービスに関する書籍で、これからマイクロサービスに取り組むチームに薦めたい一冊はありますか?
  • サービスとデータストアは1:1になっているのですか?
  • テストはモックすればなんとかなりそうですが、ローカルで立ち上げるの辛そうに見えますがどのように対応していますか(特に非エンジニア職でローカルでの動作環境を作らないと作業ができない場合はしんどそう)
  • 1リポジトリに複数サービスを同居させて管理しているのでしょうか(repoとサービスが1:1?)
  • railsはapiモードで利用していますか?
  • 多くのサービスでrailsを利用している場合、rails newすることが多いと思うのですが、そのセットアップの手間を省くための工夫として、何か取り組みはされていますか?(テンプレートなど)
  • 2桁以上のrailsアプリケーションを保守する場合、アップグレードや依存ライブラリの定期アップデートに骨が折れそうな印象ありますがどのような工夫をしていますか?

実際に自分が携わることになったとき、参考にしたく、ご意見を聞かせていただけたら幸いです

(実践を通してチームが段階的に得られたことを、失敗の体験を含めて聴かせていただけることを楽しみにしています)

Like(3)

Create Comment

Please sign in to comment.

Sign in with GitHub
This software is available as open source under the terms of the MIT License.
Copyright © 2018 Yoshiyuki Hirano