인프런 커뮤니티 질문&답변
작성한 질문수
[2주차] 곁다리 질문
해결된 질문
작성
·
62
0
1. 현재 학습 진도
몇 챕터/몇 강을 수강 중이신가요?
2주차 성능 테스트 챕터까지 수강했습니다.
제목처럼 강의 주요 내용은 아니지만 궁금한 점이 생겨 글 작성하였습니다.
질문에 악의가 없는데, 쓰다보니 공격적인 말투로 느껴지네요... 죄송합니다. 공격이 아니고 제가 공부한 부분과 달라서 어떤 게 맞는지를 여쭙고자 작성한 질문입니다.
작성해주신 포트폴리오 코드를 보면, A Service에서 A Repository, B Repository, C Repository 등을 주입받아 사용하셨는데 이게 올바른 구조인가요??
상황: 현재 저는 계층형 폴더 구조(Controller, Service, Repository 등)가 아닌 도메인형 폴더 구조(User, Post, Tag 등)를 가져가고 있습니다. 계층형과 도메인형 모두 자신의 도메인이 아닌 다른 도메인의 다른 레이어 파일을 주입받기 보다는 Service는 Service끼리 주입을 받는 게 결합도를 낮추고 리팩토링하기 편한 방향이라고 생각했습니다. 이러다보니 Controller에서 호출하는 함수는 DTO로 통신을 하고, Service끼리 사용하는 함수는 Entity로 통신을 하게 되었습니다. 주석으로 "Interal method"라고 명시를 하였지만, 응답 형식만 다를 뿐 같은 일을 하는 함수도 많아져서 이게 맞는건가 싶은 고민이 있었습니다. 애초에 Repository를 쓰는 것도 여러 파일에서 쉽게 불러쓰기 위해서라는 말도 봤던 것 같아서 뭐가 맞는지 정답이 궁금합니다.
TPS 기준이 궁금합니다.
현재 쿠폰 시스템 비슷한 프로젝트를 하고 있는데, "우리 서비스의 TPS가 몇이다"라고 할 때는 가장
주요한 로직 기준으로 측정한 결과일까요? 아니면 모든 API 중 가장 낮은 TPS가 기준이 될까요? 또한
TPS 300이 되기 위해서, 400이 되기 위해서 이런 식으로 말씀해주셨는데, Insert 또는 Update 작업이
포함된 경우 어느정도 TPS가 나오면 적지 않은 수준일까요?
감사합니다.
답변 2
0
안녕하세요 수환님!! 좋은 질문 넘넘 감사드립니다!!
한번 질문 주신 내용에 대해 답변드려보겠습니다. 그리고 표현에 대해서도 미리 말씀 주셔서 전혀 전혀 전혀!!! 불쾌하지 않았습니다!! 구조적인 고민을 깊이 하시는 것 같아 오히려 인상적이었습니다!! 더 맘껏 질문해주세요 ㅎㅎㅎ
서비스에서 여러 Repository를 주입받는 구조
말씀하신 것처럼 도메인 기반 구조에서는 자신의 도메인이 아닌 다른 도메인의 내부 구현(예: 다른 도메인의 Repository)에 직접 접근하는 것이 바람직하지 않다고 보는 시각이 많습니다. 이 관점에서는 각 도메인의 Service끼리 협력하는 구조가 더 느슨한 결합을 유지할 수 있는 방향입니다.
다만, 실제 운영되는 서비스에서는 아래와 같은 이유로 Repository를 여러 개 직접 주입하는 경우도 있습니다 복잡한 비즈니스 로직 없이 간단한 쿼리 조합만 필요한 경우 그러합니다. (저희 서비스의 경우에도 그러했스빈다)
즉, 이 구조가 절대적으로 잘못되었다기보다는 상황에 따라 타협하는 부분이 많습니다. 다만, 리팩토링 가능성이나 테스트 용이성을 생각하면, 서비스 간 의존을 통해 협력하도록 구성하는 것이 더 일반적인 방향이고, 그렇게 구성하는 것이 더 좋다고 판단되는 경우가 많습니다!!
이번 프로젝트에서는 DDD 관점의 아키텍쳐 보다는, 코드 자체의 흐름을 이해하기 쉽게 만들기 위해서 어느정도의 중복을 허용한 상태로 코드를 작성했기에 충분히 수환님과 같은 생각을 하실 수 있을 것 같습니다!!
말씀해주신 것처럼 DTO/Entity 기준으로 인터페이스를 구분하고, 서비스 간 협력을 재정비하거나, 역할 분리를 다시 점검해보는 편이 더 좋을 것 같습니다 좋은 질문 감사드립니다!!
TPS 기준에 대해
TPS를 이야기할 때 기준이 모호할 수 있는데, 보통은 서비스에서 가장 중요하거나 병목이 될 가능성이 높은 경로(주요 API나 비즈니스 로직 기준)로 측정합니다.
예를 들어, 쿠폰 시스템이라면 "쿠폰 발급"이나 "쿠폰 사용 처리"와 같이 Insert 또는 Update가 발생하고 동시성이 중요한 작업을 기준으로 삼는 경우가 많습니다. 단순 조회 API 기준 TPS는 참고로 보되, 기준점으로 잡지 않는 경우가 일반적인 것 같습니다!!
그리고 TPS가 어느 정도면 “적지 않은 수준”인지에 대해 제 주관적인 기준을 말씀드려볼게요!! 일반적인 CRUD 기반 웹서비스에서는 Insert/Update 포함 100~200 TPS만 되어도 꽤 많은 동시 처리를 의미합니다. 대규모 플랫폼 서비스라면 300~500 TPS 이상, 경우에 따라 수천 TPS 이상도 요구되지만, 이는 주로 고도화된 시스템이나 캐시, 비동기 처리 등을 통해 달성되는 것 같습니다!!
수환님 좋은 질문 감사합니다!! 언제든 편하게 질문해주세요 ㅎ.ㅎ
0
안녕하세요, 인프런 AI 인턴입니다. 정수환님.
강의를 수강하시면서 백엔드 개발 구조와 성능 지표 측정에 대한 궁금증이 생기신 것 같습니다. 두 가지 질문에 대해 하나씩 답변드리겠습니다.
1. 서비스와 레포지토리 구조
서비스와 레포지토리를 어떤 방식으로 결합할 것인지는 프로젝트의 성격과 팀의 설계 방침에 따라 다를 수 있습니다. 기본적으로 두 가지 설계 접근법이 있습니다:
계층형 폴더 구조: 서비스는 필요한 레이어로부터 의존성을 주입받아서 사용합니다. 이는 전통적인 계층형 아키텍처를 따르는 방식으로, 각 레이어가 명확히 분리되어 있어 이해하기 쉽습니다.
도메인형 폴더 구조: 도메인별로 관련 클래스를 그룹화하여 조직화를 돕습니다. 이 구조에서는 서로 다른 도메인 간의 강한 결합을 피하고, 서비스에서 다른 도메인의 서비스를 주입받아 상호 작용하는 것이 일반적입니다.
다른 도메인의 레포지토리를 직접 사용하기보다는, 동일한 도메인의 서비스끼리 주입받는 방향이 더 결합도를 낮출 수 있습니다. 이를 통해 개별 도메인 간의 변경에 대한 영향을 최소화할 수 있습니다. 다만, 이는 일반적인 가이드라인이므로 특수한 경우나 프로젝트의 요구 사항에 따라 조정이 필요합니다.
2. TPS 기준
TPS(초당 처리 건수)는 성능 테스트에서 중요한 지표입니다. 측정해야 할 기준은 다음과 같습니다:
주요 로직 기준: 보통 TPS는 서비스의 주요 로직 중심으로 측정합니다. 가장 빈번히 호출되거나 중요도가 높은 API를 중심으로 분석합니다.
통합적인 접근: 전체 서비스의 평균 TPS를 고려하거나, 개별 API의 최고 및 최저 TPS를 동시에 고려하여 전반적인 성능 지표를 마련하는 것이 좋습니다.
Insert/Update의 영향: 데이터 변형 작업이 있는 경우 TPS를 측정할 때 처리 속도가 달라질 수 있습니다. 보통의 웹 어플리케이션에서는 TPS 300 이상이 비즈니스로직 속도에 중간 정도의 성능을 의미합니다. 하지만 이는 데이터베이스 설계, 네트워크 대역폭, 서버 자원 상황에 따라 달라지기 때문에 적절한 수준을 파악하기 위해 여러 환경에서 테스트를 진행해야 합니다.
백엔드 아키텍처 설계와 성능 최적화에 대한 더 많은 정보를 원하시면 아래의 자료를 참고해 주세요.
- 질문 제목: API 구조 설계와 서버 성능 테스트 설명
저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다.
현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏
추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.