こんにちは、SmartHRでプロダクトエンジニアをしているkureです。 SmartHRでは2023年から一部パッケージでモジュラモノリス化の取り組みが始まり、2024年にコードベース全体での推進が決まりました。本記事では、私たちがなぜモジュラモノリス化に取り組んだのか、どのような成果と課題があったのかを、現場の実体験を通じてお伝えします。 モジュラモノリスという手法は近年注目を集めていますが、実際に導入・運用してみると理想と現実のギャップに直面することがあります。私たちの経験が、同様の課題を抱える開発チームの参考になれば幸いです。 直面していた課題とその背景 なぜモジュラモノリスを選択したのか モジュラモノリス化への道のり 推進体制の変遷 2024年〜2025年上期: 推進決定から体制構築まで 2025年下期：技術検証と知見の蓄積 2026年上期：イネイブリングフェーズへの転換 各フェー
重要なのは所有権です。各テーブル、またはスキーマ単位で明確な所有者が存在し、所有者のみが書き込みを行います。他のサービスは読み取りのみです。この点が「何でもありのDB共有」とは決定的に異なります。 なぜAPI通信ではなくDB直接参照なのか // サービス間API呼び出し const user = await userService.getUser(userId); // DB直接参照 const user = await db.query( 'SELECT * FROM directory.users WHERE id = $1', [userId] ); 以前、サービス間をAPI経由でデータ参照していた時期がありましたが、DNSキャッシュの問題でレスポンスが不安定になった経験があります。API呼び出しはネットワーク障害による連鎖障害のリスクを常に抱えています。 DB直接参照であれば、ネッ
はじめに UL Systems Advent Calendar 2018の10日目です。 マイクロサービスアーキテクチャでシステムを構築した際、更新対象が複数のサービスをまたがる場合は、トランザクションの扱いが途端に難しくなります。なかでも、障害発生時に各サービス間の処理をロールバックするためには補償(補正)トランザクションが必要になり、複雑なトランザクション制御が求められます。補償トランザクションとは、処理の途中で失敗した場合に、それを取り消すことで実行結果を打ち消す処理のことです。補償トランザクションの実装は、打ち消す処理を提供するサービスと、それを呼び出すサービスの双方に負担があり、設計や実装が複雑になりがちです。 トランザクションには、1つのトランザクション内で1つのリソース(DBなど)処理のみ行うローカルトランザクションと、1つのトランザクション内で複数のリソース処理を行うグロー
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
