분류 전체보기 (46) 썸네일형 리스트형 카프카를 통한 Pub/Sub 구현 및 분산 트랜잭션 사용기 A. MS간 통신에서 생기는 이슈들1. 비동기/논블로킹MSA(MicroService Architecture)를 사용하게 되면 관리의 범위가 작아져서 배포가 쉬워지며 복잡한 서비스에서 모놀리식 구조(Monolithic Architecture)보다 변경이 쉬워 집니다.그렇지만 이런 MSA의 장점을 온전히 이용하려면 MS간 의존도가 낮아 느슨한 결합(Loose Coupling)이 이루어져 있어야 합니다.기존의 동기 방식의 통신을 적용시 MS간 의존도가 생기기에 정합성이 매우 중요한 경우가 아니라면 비동기/논블로킹 방식을 이용하여 MS간 의존도를 낮추는 것이 권장 됩니다. 비동기/논블로킹 방식은 WebClient같은 HTTP클라이언트를 이용할 수도 있고 중간에 브로커 서버를 두는 메시지 큐(Message Que.. 서버 성능을 테스트하기 위한 부하테스트 프로젝트가 마무리에 다가오고 있어서 서버의 성능을 테스트해보기로 했습니다. 실제 환경과 최대한 비슷하게 테스트를 하기 위해 Naver Cloud를 이용하여 서버와 클라이언트 각각 EC2를 만들어서 클라이언트에서 서버로 요청을 받는 방식으로 테스트 하였습니다. A. 성능 테스트의 종류 (SK C&C, DCube-Team Merlin) 1. 부하테스트(Load Test)유저의 수와 초당 API 요청등을 증가시키며 시스템의 임계점(Peak Load) 을 찾기 위한 테스트입니다. 부하 상황에서 시간이 지남에 따라 성능을 확인하는 것으로 어플리케이션이 장시간의 부하 상황에서 어떤 퍼포먼스를 보여주는지 테스트 합니다. 30-1시간 정도 진행 됩니다. 2. 스모크 테스트(Smoke Test) 1-3명 정도의 최소.. DDD 도메인 모델링 개념 다시 잡기 A. Help와 Progress의 관계 문제처음에는 JPA 연관관계로 만들어야 하니 Progress를 엔티티로 만들고 Progress도 Progress만의 리포지토리가 있었습니다.Progress도 하나의 서브도메인이고 트랜잭션을 만드는 애그리거트라 생각하여 스스로의 리포지토리가 필요하다고 생각했습니다. 그렇지만 이렇게 되면 Help의 상태를 표현하는 Progress가 스스로 변경 요청을 받는 것이 가능해 Help가 자신의 상태의 일관성을 관리하지 못하게 됩니다. 이 문제를 해결하며 DDD의 각 개념들에 대해 혼동이 생겨 다시 개념 정리를 하며 Help와 Progress의 관계에 대해 고민해 보았습니다. B. DDD의 도메인 모델링 개념 다시 잡기.1. 도메인(Domain)비즈니스의 한 부분을 의미하며 전.. 응답속도 향상을 위한 캐싱 적용기 (+ 언제 캐싱을 쓰는게 좋을까?) A. 캐싱을 언제 사용하면 좋을까? 레디스를 이용해서 캐싱을 사용하게 되면 RAM에서 캐싱된 데이터를 가져오게 됩니다. RAM에서 가져오는 데이터는 HDD나 SSD같은 보조 기억장치에서 가져오는 것보다 속도가 월등히 빠르기에 RAM에 캐싱된 정보는 매우 빠르게 가져올 수 있습니다. 하드디스크에서 가져오는 것과 RAM에서 데이터를 가져오는 것은 속도가 50배 정도의 속도 차이가 생깁니다(Gecko & Fly). Memcached와 Postgre SQL의 db cache와 비교한 실험에서는 읽기 속도가 3배까지 차이가 난다고 합니다. (Kreitech) 이런 차이가 생기는 이유는 CPU와의 근접도도 있지만 데이터 조회 동작에 우선순위를 둔 DRAM의 설계와 저장에 우선 순위를 둔 SSD의 NAND .. AOP를 사용한 로그인 확인 구현 A. AOP란AOP(Aspect Oriented Programming)이란 Aspect라는 종단 관심사(Crosscutting Concerns)를 담은 모듈을 기반으로 프로그래밍을 하는 것입니다OOP에서 모듈의 관심사가 Class이듯이 AOP에서는 Aspect 입니다.Aspect는 기본적으로 어드바이스와 포인트 컷으로 이루어 집니다.포인트컷은 적용 위치를 선별하고 어드바이스는 부가 기능을 추가합니다.Aspect를 통해 핵심 관심사(핵심 비즈니스)와 부가 기능을 분리할 수 있고 반복되는 부가기능은 재사용 가능합니다.예) 트랜잭션, 로깅등B. AOP의 원리 및 발전1. Proxy 패턴부가 기능을 추가하는 AOP의 Aspect는 프록시 패턴에서 시작합니다.기능타깃과 같은 메소드를 구현하고 있다가 메소드 호출.. 결국 상속 구조를 포기 하기까지. (상속 구조 사용시 주의점) A. 상속을 사용 했던 이유.현재 프로젝트에서 사용자는 3가지 종류(체크인 요청, 줄서기 요청, 기타 요청)의 요청을 할 수 있습니다.이 요청들은 조금 다른 점도 있었지만 대부분이 중복되는 필드와 매서드였습니다.그래서 이들은 is-a 관계라고 생각해서 상속으로 구현하였습니다.조회를 할 때도 이들을 Help 라는 부모로 묶어서 다형성을 통해 전체를 조회할 수도 있었기에 상속의 단점들에도 불구하고 괜찮은 선택이라고 생각했습니다. 요약하자면 '코드 재사용'과 '다형성 활용'을 위해서 상속을 사용하였습니다. B. 객체지향에서 상속을 사용하기 애매한 이유. 상속은 객체지향에서 아이러니한 위치에 있는 기능이라고 생각합니다.처음 자바와 객체지향을 배울 때는 객체지향의 4가지 특징 중 하나로 배울만큼 상속은 주요 기.. Stub 사용기 (런던파 vs. 고전파) 테스트 코드를 작성하며 Fixture들을 만들 때 실제 값을 사용 못하기에 Test Double을 사용해야 하는 때도 있습니다. JUnit + Mockito 조합으로 하는 테스트에 익숙하다 보니 처음에는 모킹을 위주로 유닛 테스트를 작성하였습니다. 그렇지만 과연 모킹이 실제 동작을 보장할 수 있을까 항상 고민이 있었습니다. 그래서 간혹 유닛 테스트와 함께 통합 테스트를 작성하거나 통합 테스트만 작성하려고 하던 시기도 있었습니다. 모킹을 하거나 스텁 클래스를 사용하는 등 여러가지 방법으로 스터빙 해보고 또 고민해 본 현재 사용하는 방식까지의 여정을 관련 내용과 함께 정리해 보려고 합니다. A. Test Double 이란 우선 테스트 더블(Test Double)의 종류를 알아보겠습니다. Test D.. 나에게 맞는 Fixture 생성법을 찾는 여정 A. Fixture란. Fixture는 테스트가 실행하는 환경을 위해 필요한 설정을 완료해 주는 것입니다. 소프트웨어 테스트에서는 테스트에 쓰일 수 있도록 필요한 환경과 설정을 완료 해 준 객체라고 할 수 있을 것 같습니다.Fixture 라는 용어는 소프트웨어 테스트에서만 쓰이지 않고 회로나 디바이스 테스트에서도 쓰이며 전기 신호를 일정하게 컨트롤 하거나 물리적 장치를 고정하는 용도로 쓰이는 것을 말합니다. 즉, 테스트 할 수 있는 환경을 만들어 놓은 것입니다.Fixture는 Test Double을 만들어서 사용할 수도 있고 실제 값을 가진 객체를 사용할 수도 있는데 목에서 실제 값을 가진 객체를 이용하는 방법까지의 개인적인 여정을 다뤘습니다. Fixture를 셋업하는 방식은 3가지 방법이 있습니다.I.. JPA는 레이어드 아키텍처에서 어디에 속할까? *상위 문서: 코드 리뷰: 불완전한 객체에서 나타난 문제들 JPA를 사용하던 중 도메인 모델링의 규칙과 JPA의 규칙이 상충하는 일이 생겼습니다. Progress라는 Help가 가진 값객체에서 Optional한 필드를 만들고 싶었지만 값객체가 JPA의 @Embeddable로 구현되어 있어 JPA 오류가 생겼습니다. A. 문제가 생긴 이유 JPA를 처음 배울때 객체지향 방식을 따라서 데이터 베이스에 영속화 시켜주기에 도메인의 엔티티들과 자연스럽게 같이 프로젝트에서 사용되었습니다. 그러나 프로젝트는 꼭 JPA를 영속화도구로 이용하지 않을 수 있습니다. Mapper를 이용한 MyBatis, iBatis를 사용할수도 있고 preparedstatement나 statement를 이용하거나 JdbcTemp.. DDD관점에서의 레이어드 아키텍처 *'레이어드 아키텍처(Layered Architecture) feat.DDD' 에서 이어지는 아티클입니다. A. 기존 아키텍처에서 생길 수 있는 문제점. (도메인 레이어의 중요성) '레이어드 아키텍처' 아티클의 '레이어드 아키텍처의 계층' 파트를 보시면 계층간 높은 결합도 외에도 유지보수를 어렵게 만드는 것이 하나 더 있습니다. 아래는 문제의 파트인 레이어드 아키텍처의 Business Layer 에서 나타날 수 있는 문제들입니다. 문제 1. 하나의 도메인 서비스가 너무 많은 책임을 가지고 있습니다.문제 2. Application Layer가 과도한 책임을 가져서 빈약한 도메인 모델(Anemic Domain Model) 안티패턴이 나타납니다. 둘다 결국 도메인 모델링의 문제인데, 도메인.. 이전 1 2 3 4 5 다음
