티스토리

늘

검색하기

블로그 홈

늘

giron.tistory.com/m

알고리즘 + 스프링 백앤드 공부 기록 일지 ~.~

구독자: 5

방명록 방문하기

주요 글 목록

[Event] 이벤트를 이용한 성능 개선 및 의존성 분리 경험 프로젝트를 한창 할 당시에는 몰랐었지만 추후에 학습하면서 Event처리를 통해 의존성을 끊는 방법을 알았다. 기존의 공식 프로젝트도 외부 api사용 로직을 분리하고 인터페이스를 통해서 의존성을 많이 줄였다고 생각했는데 여전히 불필요한 의존성이 엮여있었다. 프로젝트가 종료된 후, 해당 문제점을 개선하면서 경험을 포스팅을 해봅니다. 문제 정의 임시 저장 게시글을 등록할 시, 임시 저장 게시글 삭제 로직 아래는 게시글 임시 저장 -> 임시 저장된 게시글을 등록 -> 게시글은 저장되고 임시 저장 글은 제거하는 로직입니다. 해당 로직에서 구체적으로 2가지 문제를 가집니다. Article -> TempArticle의 의존성 생성 게시글을 저장하는 로직에서 임시 저장글이 어떻게 처리 되어야 하는지를 알 필요가 없다고.. 공감수 0 댓글수 2 2023. 2. 17.
[테스트 자동화 2] @AfterEachCallBack을 통해 롤백 자동화하기 이전의 게시글에서 필자의 서비스에서 테스트는 @Tansactional을 통한 롤백을 제거했다. 이후, 매번 테스트에서 아래의 사진처럼 DatabaseCleaner를 주입받아 반복적으로 @AfterEach로 테스트가 끝난 후, 롤백을 진행해 주었다. 최근에 우아한테크코스 리펙토링 미션을 진행하면서 해당 방식에 대해서 알게 되었다. 이후, Junit5의 공식 문서를 확인해봤고 해당 기술에 대해서 알게 되었다. BeforeAllCallback - @BeforeAll 적용된 메서드 전에 실행(가장 먼저 실행된다.) BeforeEachCallback - @BeforeEach 적용된 메서드전에 실행 BeforeTestExecutionCallback - 각 테스트가 실행되기 직전에 실행(@Before후에 실행된다.).. 공감수 1 댓글수 1 2022. 10. 30.
JPA(ORM)의 영속성컨텍스트에서 더티체킹이 좋은걸까? Lock을 통해 해결해보자(MVCC를 지원하는 DB를 사용할 때) 해당 글은 innodb에서 lock이 어떻게 동작하는지 어느 정도 알고 있는 상태에서 읽으면 좋을 것 같습니다! 제목에 JPA가 들어가서 주제가 JPA에 한정적으로 보일수 있겠다. 하지만 실제 해당 이슈는 JPA 뿐만 아니라 모든 곳에서 발생이 가능하다. 하지만 JPA에서는 dirty checking이라는 기능을 지원해주므로 더욱 조심해야 한다고 생각해서 제목으로 지어봤다. 본론으로 들어가자면 해당 상황이 위험한 이유는 lock과 관련이 있다. 그중에서 Lost Update 문제이다. (저희 서비스는 JPA와 MVCC를 지원하는 Mysql Innodb를 사용합니다.) QA를 진행하다 다른 팀에서 데드락이슈를 맞이했다. 우리 팀은 괜찮을까 테스트해보다가 다른 이슈를 맞이했다. 바로 동시성 이슈였는데 해당 .. 공감수 5 댓글수 0 2022. 10. 22.
캐시(2) 눈물나는 레디스 적용기 그런데 EmbeddedRedis가 아닌 TestConatiner를 활용한 테스트 격리와 함께 저번 게시글에서 레디스를 도입하기로 결정을 했고 처음으로 적용해보았다. 그런데 테스트를 하는 도중에 테스트 격리가 실패를 했다. 레디스에서 테스트 격리를 위해 일주일간 고군분투한 경험을 기록하려고 작성한다. 테스트가 돌아가지 않는 코드는 믿을 수가 없다! 필자의 팀은 테스트 코드가 돌아가지 않는 코드를 ec2에 올리지 않는다. 처음 시도하는 것들이기에 테스트 코드가 보장되지 않는다면 신뢰할 수가 없기 때문이다. 따라서 redis를 적용하고 잘 동작하는지 테스트가 필요했다. 레디스를 적용 후, 로컬에서는 정상 동작했다. 하지만 ec2의 젠킨스에서 빌드가 할 때 오류가 발생하는 문제가 발생했고 결국 레디스를 제거하였다...🤦‍♂️ 레디스 적용 후, 테스트하기 레디스를 적용한 후 테스트를 진행했다. 그런데 테.. 공감수 2 댓글수 3 2022. 10. 11.
캐시(1) Redis란? Redis(Remote Dictionary Server)란? “key-value” 구조로 데이터를 저장하고 관리하기 위한 비 관계형 데이터베이스로 모든 데이터를 메모리에서 처리하는 메모리 기반 DB이다. 메모리를 통해 사용하기 때문에 일반적인 DB보다 빠른 성능을 보여준다. 레디스는 싱글 스레드로 동작한다. 캐시 매번 디비에 접근해서 디스크를 일고 쓰는 것은 비용이 크다. 따라서 데이터를 메모리에 두어 디스크에 접근을 최소화하는 방법이다. 어떤 정보를 캐시할까 잘 안 바뀌는데, 자주 읽어오는 경우 ex) 로그인 정보 key마다 태그를 달아서 어떤 데이터가 많이 생성되는지 확인한다. 캐시 vs 버퍼 버퍼는 주로 차기를 기다려서 꽉 차면 보내주고, cache는 미리 계산하고 가져온다. 버퍼는 쓰기를 위해서 .. 공감수 3 댓글수 5 2022. 10. 9.
공식팀의 테스트코드 최적화 with 테스트 격리 현재 저희 공식팀은 인수 테스트와 @WebMvc를 통한 컨트롤러 테스트, @SpringBootTest를 활용한 서비스 테스트, 그리고 @DataJpaRepository를 활용한 레포지토리 테스트로 크게 4종류의 테스트를 진행 중입니다. 테스트 격리 테스트 격리의 방식으로는 다양한 방식이 있습니다. DirtiesContext 사용하기 가장 쉬운 방법이지만 매번 컨텍스트를 올려야 하므로 느린 방식이어서 저희 팀은 처음부터 해당 방식을 적용하지 않았습니다. @Sql을 활용한 sql문 미리 작성하기 해당 방법을 미션 하면서 적용해보았다. 그때는 규모도 작고 페어로 진행하기 때문에 크게 문제가 되지 않았다. 그런데 팀 프로젝트에 적용하기엔 아래와 같은 단점이 많았다. 따라서 이것도 적용하지 못했다. 테스트에 필요.. 공감수 1 댓글수 0 2022. 10. 8.
테스트 코드의 어노테이션을 줄여보자 그리고 테스트 컨텍스트 캐싱의 이점을 얻자 현재 프로젝트가 어느 정도 진행되면서 Test위에 붙는 Import도 늘어났다. 아래 사진처럼 매번 Repository 테스트를 할 때마다 붙여줘야 하는데 불편해서 어노테이션을 만들어서 정리를 해보았다. 사실 포스팅 할만한 정도로 대단할 건 없지만 앞으로도 프로젝트를 진행하면 자주 적용할 것 같아서 기록해두려고 한다. 메타 어노테이션을 활용하여 위와 같이 작성해주면 끝! 이제 @Repository만 작성하면 간편하게 적용이 가능하다. 또한 스프링은 테스트 시 매번 컨텍스트를 띄우지 않고 테스트가 사용하는 컨텍스트를 캐싱해서 여러 테스트가 1개의 (애플리케이션) 컨텍스트를 공유하는 방법을 제공한다. 즉, 테스트마다 동일한 컨텍스트를 사용하면 컨텍스트가 1번만 올라가므로 테스트 성능에도 좋다. 1) @Rep.. 공감수 0 댓글수 0 2022. 9. 13.
HTTP1.0 과 HTTP1.1 과 HTTP2 그리고 QUIC HTTP 1.0 기존의 HTTP 1.0은 TCP Connection당 하나의 URL만 fetch하며, 매번 request/response가 끝나면 연결이 끊기므로 필요할 때마다 다시 연결해야하는 단점이 있어 속도가 현저히 느리다. 매번 새로운 연결로 성능 저하 서버 부하 비용 증가 GET, HEAD, POST의 method가 사용된다. HEAD는 Header의 정보만 전송된다. HTTP 1.1 persistent Connection(keep-alive) 지정한 timeout 동안 커넥션을 닫지 않는다. 기본적으로 keep-alive이고 사용하지 않을 때만 헤더에 ~을추가하여 사용하지 않는다. 캐시를 두어 성능을 향상시켰고 데이터를 압축해서 보낸다. OPTION, PUT, DELETE, TRACE의 met.. 공감수 1 댓글수 2 2022. 9. 8.
토큰과 세션(3) - 선택 현재 저희 공식팀의 서비스는 지식 공유 게시판(약간 stackoverflow느낌)의 웹 플랫폼입니다. 저희 서비스에서는 세션과 토큰 중 어떤 게 적합한 인증방식일지 고민해봤습니다. 일반적인 오해 전통적으로 웹사이트는 쿠키를 사용한 세션 인증을 사용하고 모바일 앱/SPA는 Authorization 헤더와 함께 토큰 인증을 사용하지만 반드시 그런 것은 아니다. Authorization Header와 Cookies는 전송 메커니즘에 관한 것입니다. 토큰과 세션은 기본적으로 서버 측이든 클라이언트 측이든 권한 부여 상태가 처리되는 위치에 관한 것입니다. 예를 들어, 서버는 쿠키를 통해 JWT 토큰을 발행하거나 "Authorization" 헤더에 상태 저장 세션 ID가 제공될 것으로 예상할 수 있다. 출처: ht.. 공감수 1 댓글수 0 2022. 8. 29.
토큰과 세션(2) - 세션기반 인증 확장 방법 서버가 확장되어 여러 개를 갖게 된다면 요청이 들어올 때마다 로드밸런싱을 통해 부하를 나눌 수 있다. 이때 세션을 사용하면 A라는 서버로 처음에 로그인을 해서 세션 ID가 만들어지고 로그인을 성공한다. 하지만 사용자가 다시 요청을 보낼 때 이번엔 로드밸런싱에 의해 B 서버로 갔다면 B서버에는 사용자의 세션ID가 없으므로 다시 로그인을 시도하라는 요청이 올 수 있다. 이러한 세션과 로드밸런싱의 문제를 해결하기 위해 sticky session이 있다. sticky session 처음 로그인했을 때, 갔던 서버에서 세션 ID를 만들고 로그인이 성공하면 그 회원의 요청은 해당 서버로만 가도록 하는 것이다. 즉, 세션이 만들어진 서버로만 요청이 가는 것이다. 해당 방식은 cookie를 사용하는 방식으로 구현할 수.. 공감수 1 댓글수 2 2022. 8. 27.
토큰과 세션(1) - 토큰과 세션 그리고 쿠키에 대해서 HTTP의 특징 connectionless, stateless connectionless는 클라이언트에서 http request를 서버에 보내면, 서버는 알맞은 http response를 보내고 접속을 끊는 특성이 있다. 왜냐하면 여러 클라이언트와 통신을 하려면 한 커넥션이 오래 물고 있으면 성능에 좋지 않기 때문이다. 하지만 매번 연결을 끊고 다시 생성하는 비용도 만만치 않아서 (HTTP1.1에서) keep-alive를 통해서 timeout, max번 connection을 재활용하기도 한다. stateless는 통신이 끝나면 상태를 유지하지 않는 특징이다. 로그인을 성공하고 다음에 글을 적으려고 하면 다시 인증을 해야 한다. 쿠키 HTTP는 connectionless, stateless한 성격을 가진다.. 공감수 0 댓글수 0 2022. 8. 23.
소나큐브 적용기 SonarQube 란 정적 코드 분석을 자동을 수행하는 오픈 소스 플랫폼 중복 코드, 코딩 표준, 유닛 테스트, 코드 커버리지, 코드 복잡도, 주석, 버그 및 보안 취약점에 대해서 검사하고 결과를 보고서로 작성한다. 20개 이상의 언어에 대한 분석이 가능하다. 정적 코드 분석 이란 프로그램을 실행하지 않고 소스 코드나 컴파일된 코드를 분석하는 작업 프로그램을 실행하지 않고 버그나 취약점을 분석할 수 있다. 주로 개발 단계에서 코드의 구조적인 문제나 실수를 찾아내기 위해서 사용한다. 코드 작성단계에서 차후 코드를 실행했을 때 발생할 가능성이 높은 문제를 미리 찾고 대처할 수 있다. 단순이 버그나 오류를 찾아내는 것 뿐만 아니라 더 좋은 코드를 위한 개선점을 제시한다. 반대로 동적 분석에는 모니터링이나 테스.. 공감수 0 댓글수 0 2022. 8. 15.
[테스트 자동화 1] service 테스트에서 롤백 목적으로 @Transactional 사용을 지양하자! 그런데 EntityManager를 활용해서 truncate를 시켜보자 프로덕션 코드에서 게시글 조회 로직이 있었습니다. 게시글을 조회할 때, 조회수 증가(update)가 있었지만 단순히 조회하는 로직이라고 생각했고 @Transactional(readOnly=true)옵션을 설정해주었습니다. 그리고 서비스 통합 테스트에서는 @Transactional을 통한 롤백을 사용했었습니다. 그래서 테스트에서는 정상적으로 조회수가 증가해서 이상이 없었지만 실제 QA할 때, 조회수가 증가하지 않는 버그를 발견했습니다. 이러한 문제를 어떻게 해결할까 고민을 했었고, 서비스 통합테스트에서 @Transactional을 제거해서 이와 같은 실수가 재발하는 것을 방지했습니다. 문제 상황 해당 메서드를 보고 단순히 조회니깐 readOnly=true를 붙이면 되겠다고 생각했다. 그리고 Service .. 공감수 0 댓글수 0 2022. 7. 29.
HTTPS 적용하기 프로젝트 진행하면서 HTTPS 적용기 HTTP 인터넷 상에서 정보를 주고 받기위한 프로토콜(양식과 규칙의 체계) 클라이언트와 서버 사이에 이루어지는 요청/응답 프로토콜 암호화되지 않은 평문으로 데이터를 전송한다. (악의적인 감청, 데이터 변조의 가능성) HTTPS HTTP + secure 모든 HTTP 요청과 응답 데이터는 네트워크로 보내지기 전에 암호화된다. HTTPS는 HTTP의 하부에 SSL과 같은 보안계층을 제공함으로써 동작한다. 도메인 가비아에서 도메인을 구입하면 TTL을 설정할 수 있다. TTL에 대해서 학교에서 배웠는데 기억이 안나서 다시 찾아보았다.. TimeToLive의 약자로 Routing Loop를 방지하여 무한 루프에 빠지는 것을 막을 수 있다. 또한 멀티 캐스팅할 때, 라우터 범위.. 공감수 0 댓글수 0 2022. 7. 28.
커서 기반 페이지네이션 적용기 무한 스크롤 구현을 요구받아서 처리하려고 찾아본 결과 커서 기반 페이지네이션이라는 키워드가 있어서 찾아 공부해봤다. 1. 페이지네이션(Pagination) 이란? 전체 데이터에서 지정된 개수만 데이터를 전달하는 방법 필요한 데이터만 주고받으므로 네트워크의 오버헤드를 줄일 수 있다. 구현 방법에는 크게 두 가지가 있다. 오프셋 기반 페이지네이션 (Offset-based Pagination) 커서 기반 페이지네이션 (Cursor-based Pagination) 오프셋 기반 페이지네이션 - 페이징 offset만큼 읽는데 이전의 읽었던 것을 다시 쭉 읽은 후 조회해서 데이터가 많아지면 성능상 안 좋다. 데이터 중복 문제: 2페이지 끝까지 읽었는데 앞에 최신 데이터가 들어오면 3페이지 읽을 때 중복이 발생할 수 .. 공감수 3 댓글수 0 2022. 7. 27.
[JPA] cascade = CascadeType.REMOVE와 @OnDelete(action = OnDeleteAction.CASCADE)의 차이 가장 큰 차이로는, JPA에 의해 처리되느냐, DDL에 의해 cascade가 걸린 테이블이 생겨 DB단에서 처리되느냐 이다. 전자의 방식을 취할 경우, JPA에 의해 외래 키를 찾아가며 참조하는 레코드를 제거해주게 됩니다. 따라서, JPA 상에서는 참조하고 있는 레코드의 개수만큼 delete 쿼리가 생성됩니다. 후자의 방식을 취할 경우, 데이터베이스 자체에서 on delete cascade 제약조건이 걸리게 됩니다. 이를 통해 참조하는 레코드가 모두 제거되는 것입니다. cascade = CASCADE.REMOVE JPA 레벨에서 작동한다. 외래 키를 찾아 참조하는 레코드를 제거해준다. 참조하고 있는 레코드 수 만큼 delete쿼리가 나간다. 부모 테이블의 자식 컬럼에 걸어여하므로(일반적으로 @OneToM.. 공감수 1 댓글수 0 2022. 7. 24.

문의안내

티스토리
로그인
고객센터

티스토리는 카카오에서 사랑을 담아 만듭니다.