💻 Service/Briefing

[Briefing] nGrinder로 성능 테스트 해보기

💡 성능 테스트의 종류 성능 테스트는 시스템이나 애플리케이션이 요구되는 표준 내에서 얼마나 효과적으로 작동하는지 확인하는 과정입니다. 다양한 유형의 성능 테스트가 있으며, 각각은 시스템 성능의 다른 측면을 측정합니다. 1. 부하 테스트(Load Test) 일정시간 동안 부하를 가하여 애플리케이션이 예상 사용량을 처리할 수 있는지 확인하기 위해 실시합니다. 이 테스트는 애플리케이션의 반응 시간, 처리량 및 리소스 사용량을 측정하여 성능 문제를 식별합니다. 2. 스트레스 테스트(Stress Test) 애플리케이션의 한계를 결정하기 위해 비정상적으로 높거나 예상치 못한 부하를 적용합니다. 목적은 시스템이 과부하 상태에서 어떻게 실패하는지 관찰하고, 최대 용량을 파악하는 것입니다. 3. 지속성 테스트(Endur..

[Briefing] Facade로 계층 구조 개선하기

🔥 Controller → Service → Repository 계층 구조의 문제점 2.0.0 버전 업데이트 이슈 대응 이후, 서버 업무가 한가해진 타이밍에 기존 설계를 점검해보았습니다. Briefing 팀에서는 전형적인 Controller → Service → Repository 구조를 바탕으로 개발이 되어있었고, 기존 설계에서 여러 문제점을 찾을 수 있었습니다. 먼저, Command 요청에 대한 처리과정 중 DTO ↔ Entity간 변환을 예시로 문제점을 살펴보겠습니다. [기존] DTO ↔ Entity 변환 과정 (Command) Layer Problem-1 Problem-2 Controller Service로 부터 Entity를 반환받습니다. → Controller가 테이블의 세부 구현을 알게 됩니..

[Briefing] API 응답 캐싱을 통한 조회 속도 개선

🚀 API 응답 캐싱의 필요성 Briefing 앱에서는 홈화면에서 타입(사회, 과학, ...)별로 브리핑 목록을 조회하고 있었습니다. 스크랩을 하거나 취소하였을 때, DB에 새로운 브리핑 목록이 추가되었을 때를 제외하면 동일한 응답을 계속 내려주고 있었습니다. 그래서 서버팀에서는 해당 API응답을 캐싱하기로 했으며, 아래와 같은 요구사항을 정의했습니다. 캐시를 도입하기 전/후로 API 응답 속도를 측정해보고 개선된 지표를 확인한다. 100명의 사용자가 10번 요청하는 것을 기준으로 속도를 측정한다. 운영서버와 스펙이 동일한 개발서버(겸 스테이징 서버)에서 속도를 측정한다. 캐시 이름은 메소드명과 동일하게 정하고, 키는 브리핑 타입으로 한다. 스크랩 개수의 정합성을 보장하기 위하여 스크랩 개수 변경시, 캐..

[Briefing] Spotless로 코드 포맷 유지하기

🚀 코드 Formatter의 필요성 코드 Formatter의 필요성은 소프트웨어 개발의 여러 측면에서 중요합니다. 주요 이점은 다음과 같습니다. 일관성 유지 Formatter는 팀 내의 모든 개발자가 동일한 코딩 스타일을 유지하도록 도와줍니다. 가독성 향상 일관된 코드 포맷팅은 코드의 가독성을 크게 향상시킵니다. 이는 코드의 이해를 돕고, 디버깅 및 유지보수를 용이하게 만듭니다. 시간 절약 자동화된 포맷팅으로 수동으로 코드 스타일을 맞추는 데 소요되는 시간을 줄여줍니다. 협업 효율성 일관된 코드 스타일은 팀원들이 서로의 코드를 이해하고 협업하는 데 도움이 됩니다. 💡 Spotless란? https://github.com/diffplug/spotless GitHub - diffplug/spotless: K..