늘

해당 글은 조금 각색해서 우아한테크코스 블로그(테코블)에 있습니다! 트랜잭션을 사용할 때, 아래의 사진처럼 private 메서드에 걸면 컴파일 에러가 나오는 것을 확인할 수가 있다. 인텔리제이가 알려주는 메시지를 보면 private 만 사용하지 않으면 된다고 한다. 이 이유에 대해서는 spring 2.5버전 이후부터는 default로 CGLIB을 사용하므로 상속을 통해 프록시를 구현한다. 하지만 private메서드는 상속이 불가능하기 때문에 프록시를 만들 수 없기 때문이다. 하지만 스프링 공식문서를 보면 public 이외의 모든 메서드는 트랜잭션이 적용되지 않는다고 한다. 실제 protected로 하면 컴파일단에선 예외가 잡히지 않는다. 왜냐하면 프록시는 만들어지기 때문이다. 하지만 스프링 공식문서를 보..

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..

jwt 토큰이란 JWT(JSON Web Token)는 당사자 간에 정보를 JSON 객체로 안전하게 전송하기 위한 토큰이다. 이 정보는 디지털 서명되어 있으므로 확인하고 신뢰할 수 있습니다. JWT는 HMAC 알고리즘을 사용하거나 RSA 또는 ECDSA 를 사용하는 공개/개인 키 쌍을 사용하여 서명할 수 있습니다. 한가지 오해 처음에 jwt를 공부할 때, 어차피 디코딩하면 헤더에서 토큰 타입이나 알고리즘을 알 수있는데 왜 서명을 하는가였다. 그이유를 설명하자면 jwt의 서명의 목적을 생각해야한다. 디지털 서명되어 신뢰할 수 있는 이유는?(서명하는 이유) JWT 토큰은 자체적으로 토큰 유효성 검사가 가능하다! 즉, HMAC또는 RSA와 같은 공개 또는 비대칭키를 통해 서명하기 때문이다. 단순히 JWT토큰을 ..

현재 저희 공식팀의 서비스는 지식 공유 게시판(약간 stackoverflow느낌)의 웹 플랫폼입니다. 저희 서비스에서는 세션과 토큰 중 어떤 게 적합한 인증방식일지 고민해봤습니다. 일반적인 오해 전통적으로 웹사이트는 쿠키를 사용한 세션 인증을 사용하고 모바일 앱/SPA는 Authorization 헤더와 함께 토큰 인증을 사용하지만 반드시 그런 것은 아니다. Authorization Header와 Cookies는 전송 메커니즘에 관한 것입니다. 토큰과 세션은 기본적으로 서버 측이든 클라이언트 측이든 권한 부여 상태가 처리되는 위치에 관한 것입니다. 예를 들어, 서버는 쿠키를 통해 JWT 토큰을 발행하거나 "Authorization" 헤더에 상태 저장 세션 ID가 제공될 것으로 예상할 수 있다. 출처: ht..

서버가 확장되어 여러 개를 갖게 된다면 요청이 들어올 때마다 로드밸런싱을 통해 부하를 나눌 수 있다. 이때 세션을 사용하면 A라는 서버로 처음에 로그인을 해서 세션 ID가 만들어지고 로그인을 성공한다. 하지만 사용자가 다시 요청을 보낼 때 이번엔 로드밸런싱에 의해 B 서버로 갔다면 B서버에는 사용자의 세션ID가 없으므로 다시 로그인을 시도하라는 요청이 올 수 있다. 이러한 세션과 로드밸런싱의 문제를 해결하기 위해 sticky session이 있다. sticky session 처음 로그인했을 때, 갔던 서버에서 세션 ID를 만들고 로그인이 성공하면 그 회원의 요청은 해당 서버로만 가도록 하는 것이다. 즉, 세션이 만들어진 서버로만 요청이 가는 것이다. 해당 방식은 cookie를 사용하는 방식으로 구현할 수..

HTTP의 특징 connectionless, stateless connectionless는 클라이언트에서 http request를 서버에 보내면, 서버는 알맞은 http response를 보내고 접속을 끊는 특성이 있다. 왜냐하면 여러 클라이언트와 통신을 하려면 한 커넥션이 오래 물고 있으면 성능에 좋지 않기 때문이다. 하지만 매번 연결을 끊고 다시 생성하는 비용도 만만치 않아서 (HTTP1.1에서) keep-alive를 통해서 timeout, max번 connection을 재활용하기도 한다. stateless는 통신이 끝나면 상태를 유지하지 않는 특징이다. 로그인을 성공하고 다음에 글을 적으려고 하면 다시 인증을 해야 한다. 쿠키 HTTP는 connectionless, stateless한 성격을 가진다..

SonarQube 란 정적 코드 분석을 자동을 수행하는 오픈 소스 플랫폼 중복 코드, 코딩 표준, 유닛 테스트, 코드 커버리지, 코드 복잡도, 주석, 버그 및 보안 취약점에 대해서 검사하고 결과를 보고서로 작성한다. 20개 이상의 언어에 대한 분석이 가능하다. 정적 코드 분석 이란 프로그램을 실행하지 않고 소스 코드나 컴파일된 코드를 분석하는 작업 프로그램을 실행하지 않고 버그나 취약점을 분석할 수 있다. 주로 개발 단계에서 코드의 구조적인 문제나 실수를 찾아내기 위해서 사용한다. 코드 작성단계에서 차후 코드를 실행했을 때 발생할 가능성이 높은 문제를 미리 찾고 대처할 수 있다. 단순이 버그나 오류를 찾아내는 것 뿐만 아니라 더 좋은 코드를 위한 개선점을 제시한다. 반대로 동적 분석에는 모니터링이나 테스..

프로덕션 코드에서 게시글 조회 로직이 있었습니다. 게시글을 조회할 때, 조회수 증가(update)가 있었지만 단순히 조회하는 로직이라고 생각했고 @Transactional(readOnly=true)옵션을 설정해주었습니다. 그리고 서비스 통합 테스트에서는 @Transactional을 통한 롤백을 사용했었습니다. 그래서 테스트에서는 정상적으로 조회수가 증가해서 이상이 없었지만 실제 QA할 때, 조회수가 증가하지 않는 버그를 발견했습니다. 이러한 문제를 어떻게 해결할까 고민을 했었고, 서비스 통합테스트에서 @Transactional을 제거해서 이와 같은 실수가 재발하는 것을 방지했습니다. 문제 상황 해당 메서드를 보고 단순히 조회니깐 readOnly=true를 붙이면 되겠다고 생각했다. 그리고 Service ..

프로젝트 진행하면서 HTTPS 적용기 HTTP 인터넷 상에서 정보를 주고 받기위한 프로토콜(양식과 규칙의 체계) 클라이언트와 서버 사이에 이루어지는 요청/응답 프로토콜 암호화되지 않은 평문으로 데이터를 전송한다. (악의적인 감청, 데이터 변조의 가능성) HTTPS HTTP + secure 모든 HTTP 요청과 응답 데이터는 네트워크로 보내지기 전에 암호화된다. HTTPS는 HTTP의 하부에 SSL과 같은 보안계층을 제공함으로써 동작한다. 도메인 가비아에서 도메인을 구입하면 TTL을 설정할 수 있다. TTL에 대해서 학교에서 배웠는데 기억이 안나서 다시 찾아보았다.. TimeToLive의 약자로 Routing Loop를 방지하여 무한 루프에 빠지는 것을 막을 수 있다. 또한 멀티 캐스팅할 때, 라우터 범위..

무한 스크롤 구현을 요구받아서 처리하려고 찾아본 결과 커서 기반 페이지네이션이라는 키워드가 있어서 찾아 공부해봤다. 1. 페이지네이션(Pagination) 이란? 전체 데이터에서 지정된 개수만 데이터를 전달하는 방법 필요한 데이터만 주고받으므로 네트워크의 오버헤드를 줄일 수 있다. 구현 방법에는 크게 두 가지가 있다. 오프셋 기반 페이지네이션 (Offset-based Pagination) 커서 기반 페이지네이션 (Cursor-based Pagination) 오프셋 기반 페이지네이션 - 페이징 offset만큼 읽는데 이전의 읽었던 것을 다시 쭉 읽은 후 조회해서 데이터가 많아지면 성능상 안 좋다. 데이터 중복 문제: 2페이지 끝까지 읽었는데 앞에 최신 데이터가 들어오면 3페이지 읽을 때 중복이 발생할 수 ..