モジュラモノリスにおいてトランザクションはどうあるべきなのかについて整理している資料が少ない気付きがあったので「簡易的に」整理しました
この記事はUbie Engineering Advent Calendar 2023の一日目です。よろしくお願いします。 背景 ユビーのシステムは言語が多様化してきたことにより、認知負荷の増加や運用負荷の増加、開発支援に仕組みづくりかけるコストの増加などの問題が発生していました。この課題を解決するためにNode.jsとGoに言語を絞っていくという意思決定をしたのが昨年です。これについては以下の記事で詳しく解説しています。 ちょうど去年のアドベントカレンダーの記事なのでこれから一年経ちました。ここでは以下のように述べられています。 Server-Side Kotlin などで書かれている既存サービスを、この技術選定の文脈でリプレイスすることは今のところ考えていません。 ただし、多くの既存サービスはドメインたくさん抱えすぎ問題があったり、色々とレガシーだったりして、徐々に別サービスに切り出して
「【ハイブリッド開催】Rubyで追求するモジュラモノリスの可能性」は、バックエンドにRubyを採用している株式会社タイミー、hacomono社、ワンキャリア社が、Rubyにおけるモジュラモノリスの可能性や良い点、悪い点を共有する勉強会です。ここで株式会社タイミーの須貝氏が登壇。まずは、Railsでモジュラモノリスを実現する3つの代表的パターンと、各パターンの評価について話します。 須貝氏の自己紹介 須貝俊 氏:では、「RailsでModular Monolithを選択された御社に質問したいN個の疑問」というタイトルで発表をしたいと思います。 (スライドを示して)まずは自己紹介をしたいと思います。須貝と申します。タイミーには、2022年1月からジョインしています。スポットワークシステム領域というところで、チーム名がIronBank Squadという、企業さま向けの請求や、ワーカーさまへの給与
「【ハイブリッド開催】Rubyで追求するモジュラモノリスの可能性」は、バックエンドにRubyを採用している株式会社タイミー、hacomono社、ワンキャリア社が、Rubyにおけるモジュラモノリスの可能性や良い点、悪い点を共有する勉強会です。ここで株式会社hacomonoの志賀氏が登壇。まずは、モジュラモノリスを導入する前の状況と、モジュラモノリスを選んだ理由について話します。 志賀氏の自己紹介 志賀誠氏(以下、志賀):みなさん、こんにちは。 会場:こんにちは。 志賀:うれしい、返事がきた(笑)。オフラインで話すのが久々すぎて声が出るかちょっと心配だったんですが、なんとかなりそうなのでやっていきたいと思います。 今日お話しする内容ですが、「hacomono TECH BLOG」で事前に書いた内容と若干かぶるところがあるので、もし読んだ方がいたら、おさらい程度だと思って目をとおしてもらえると幸
「【ハイブリッド開催】Rubyで追求するモジュラモノリスの可能性」は、バックエンドにRubyを採用している株式会社タイミー、hacomono社、ワンキャリア社が、Rubyにおけるモジュラモノリスの可能性や良い点、悪い点を共有する勉強会です。ここで株式会社hacomonoの志賀氏が登壇。続いて、モジュラモノリス実現のための取り組みについて話します。前回はこちらから。 モジュラモノリスを導入に向けて境界分けをどうするか 志賀誠氏:じゃあ今度は、モジュラモノリスの実現の方法について説明します。(スライドを示して)Railsでモジュラモノリスを導入するにあたって、パッと思いつくもので、このスライドにあるような問題があるかと思います。 1個は、やはりRailsはRubyなので、なんでも書けちゃうということがあると思います。もうやろうと思ったらいくらでも越境できちゃう境界区域とかがあると思います。 も
ビジネス開発部のバックエンドエンジニアの伊藤です。主にトクバイのビジネスサイドの開発を担当しています。 Shopify記事の影響もありしばらく前からモジュラモノリスが注目されるようになりました。 我々が開発しているトクバイではモノリシックに構築されており、各機能が密結合になりメンテナンスしづらくなっています。 今回、新機能プロジェクトを担当する上で各機能をモジュール分割・コンポーネント化することを試してみました。 Packwerk PackwerkはShopifyが開発しているGemで、Railsアプリケーションをモジュール分割する手助けをしてくれます。 USAGEに書かれていることを要約すると、大規模なアプリケーションは境界を作り境界間の依存関係をコードレベルで最小にしようということだと考えています。 後述しますが幾つかのエコシステム導入する事で、よりモジュラモノリス化を促すことができま
STORES 予約 でエンジニアリングマネージャーをしている Natsume です。 STORES 予約 は10年モノの45万行、380テーブルある大きなモノリスの Rails アプリケーションです。 業種にとらわれない汎用的な予約システムであり、それらに対応するように複雑なコードベースになっています。また、ここ 1~2 年はプロダクト間連携を進めており、各基盤やアプリケーションともつなげていく開発を進めています。今後も新規プロダクトとの連携や機能開発を進めるには、少しでも認知負荷を上げずに開発しやすい状態を保ち続けるか、が重要だと感じました。 その課題感の中で、今回はモジュラモノリスを選択し導入をしましたので、そちらのお話をしたいと思います! 現状の課題感 私が入社した3年前から STORES 予約 の開発メンバーは3倍になり比較的新しいメンバーが多く、また古くからいるエンジニアも少数な
初めまして、株式会社スマートラウンドCTOの小山(@doyaaaaaken)です。 昨年末Startup CTO of the year 2022というイベントに出場して優勝し、その際のピッチ内容について解説する連続記事をこれまで書いてきました。 今回の記事はその4本目の記事となります。 もうじき今年のStartup CTO of the yearが開催されようとしている中、このシリーズが3本で止まっていた事実を思い出し、 「今年中にしか出せないネタなので書かねば!」 という気持ちになり急遽駆け込みで書きました。 拙い部分があればご容赦ください。 なお優勝ピッチ解説シリーズの他の記事は以下リンク先で公開しています。👇 🔗【優勝ピッチ解説(1)】スマートラウンドの開発体制ではスクラムをどう改変したか? 🔗【優勝ピッチ解説(2)】スマートラウンドでISMS認証を取得した背景および得た知見
背景 著者が開発に携わるサービスは拡大期にあり、リアーキしてモノリスからモジュラーモノリス化しようと計画している。 著者はモジュラーモノリス化することで著書・チームトポロジーで描かれるようなストリームアラインドチームができていく、という理想を抱いていたのだが、どうもそれにはハードルがあるように感じたので、課題感を言語化し、それにどう対処していくかを考えた。 チームトポロジー的理想と、それに対する課題 ▼理想 逆コンウェイ戦略によりモジュール分割され、そこに必要な職能のメンバーが集まってストリームアラインドチームができる。エンジニアの認知負荷は減少し、コミュニケーションや意思決定はチーム内で完結し、アウトカムが最大化される。 ▼課題 「PMによる日々の施策立案は、現在想定しているモジュールに閉じた形ではなされていない」という現実がある。このままでは、モジュール分割を達成しても、各プロジェクト
「【ハイブリッド開催】Rubyで追求するモジュラモノリスの可能性」は、バックエンドにRubyを採用している株式会社タイミー、hacomono社、ワンキャリア社が、Rubyにおけるモジュラモノリスの可能性や良い点、悪い点を共有する勉強会です。ここで株式会社タイミーの須貝氏が登壇。続いて、タイミーがどうやってモジュラモノリス化を進めているかについて話します。前回はこちらから。 タイミーが抱えていた課題 須貝俊 氏:続いて、タイミーがどうやってモジュラモノリス化を進めているかというところをより具体的に話していきたいと思います。 (スライドを示して)課題としてはスライドに示したようなものがあって、コード上で何が何に依存しているのか把握しきれない状態になっていました。上記に伴う変更による影響範囲がわからない。また、エンジニアの増加に伴ってチームも増えていくため、チームの責任範囲を明確にしていく必要が
PHPカンファレンス2023「Symfony+Doctrine ORMで始める安全なモジュラモノリス」のスライドです。 ## トーク概要 モノリス全盛期〜マイクロサービスブームを経て、近年、両者のいいところ取りができるアーキテクチャとしてモジュラモノリスが話題になることも増えてきました。PHPでも流行のLaravelフレームワークでのやり方やハマりポイントの記事がありますが、基本的に密結合を指向しているLaravelをベースにかなり無理をして実現している事例を見かけます。 私が数年にわたってSymfony+Doctrine ORMをベースにモジュラモノリスでアプリケーションを開発してきた経験から、Laravelベースで開発するよりも数段楽にモジュラモノリスを実現できることを証明したいと思います。
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く