GitHub qsona
Comment13
Like
Created atMarch 21, 2018 12:04
Updated atMarch 21, 2018 12:04

Questions and feedbacks (13)

qsona
qsona commented about 1 year

FiNCでマイクロサービスを作るときは、最初から新規サービスとして作るパターンと、既存アプリケーションから分割するパターンがありますが、 初期の10個くらいまではすべて新規で作られています。 既存アプリケーションからの分割は、分割のみ(システムの純粋なリファクタリング)を目的としてやったケースは今までは全くなく、何らかのビジネス的な目的がある場合に行っているので、「通常の施策開発の中で行っている」が回答になります。 また、その開発は最初のリリースまでに2週間〜2ヶ月くらいが多いです。

アプリケーションの境界分割にあたり開発チーム - ビジネス陣両者でのコミュニケーションで苦労した箇所はあったか ビジネス上の境界とアプリケーションの境界でズレが発生しないようにするのが肝なところがあると思っていて

これが重要であることに大変同意で、実際に多くコミュニケーションを取っています。苦労することがあるとすれば、ビジネス側も考えが決まりきってない/詰まってない場合で、結果進んでみると少し境界をミスったなということがあります(このような場合は本来は無理してサービス化しないほうが良いと思います)。

Like(0)

qsona
qsona commented over 1 year

すでに多くのサービスが存在する場合、Envoyを少数のサービスから徐々に導入していくことは可能でしょうか?

Like(0)

qsona
qsona commented over 1 year

Service meshはcookpad製ライブラリのGarageと一部役割がかぶるように思うのですが、(それが正しければ・・)今後どう役割の移行を進めていくかを聞きたいです。

Like(0)

qsona
qsona commented over 1 year

10xの規模を見据えた場合、中央で全体をマネジメントしているチーム自体もスケールさせていく必要があるように思います。例えば200個のサービスの依存関係を1つのリポジトリにしてGitHubでレビューするのは難しくなる気がしますが、どうなのでしょうか?

(追記ですが、20-30個の段階で全体の依存関係が俯瞰できない問題はかなり自分にとっても身近なので、中央管理できるのは良いなと思いました。)

Like(0)

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)

qsona
qsona commented over 1 year

AMA素晴らしいです。僕もイベント運営者として使いたいのでSaaS化に期待しています。

Like(2)

qsona
qsona commented over 1 year

Step4が完了したあとにもAdapterは使い続けるのでしょうか。直接ActiveRecordの呼び出しに変える予定はありますか?

Like(0)

qsona
qsona commented over 1 year

テナントごとにDBを論理的に分けているということですが、Auroraの物理的なインスタンス自体は(どう)分けているのでしょうか?

Like(0)

qsona
qsona commented over 1 year

(なんちゃってのprefixがありつつもw、)マイクロサービスにしているということですが、学校向けのサービスということで、使うユーザの種別がたくさんありそうなのが難しそうに思います(生徒、保護者、先生など?)。例えば生徒向けのサービスと先生向けのサービスで同じデータを使うことはあるのでしょうか。そのような場合、マイクロサービスはどういう単位で分けられているのでしょうか?

Like(0)

qsona
qsona commented over 1 year

docker build中にbundle installしない理由と、どういう方法でやっているかが知りたいです!

Like(0)

qsona
qsona commented over 1 year

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

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

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

Like(1)

qsona
qsona commented over 1 year

Wantedlyさんは、ネイティブアプリも途中からかなり分割していっている印象があるのですが、バックエンドのマイクロサービス化とネイティブアプリ・フロントアプリの関係についてもできればお聞きしたいです。 (当日は裏で司会をしている予定なので、リアルタイムでは聞けない可能性が高いのですが... >< )

Like(3)

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)

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