TechBear

XSS란 무엇이며 어떻게 방어할 수 있을까?

베어_ — Fri, 29 Dec 2023 15:14:01 +0900

XSS란 무엇인가?

크로스 사이트 스크립팅(Cross-Site Scripting, 이하 XSS)은 웹 보안 취약점 중 하나로, 공격자가 사용자의 웹 브라우저에 악의적인 스크립트를 주입할 수 있게 하는 공격 방식입니다.

이 취약점은 웹 애플리케이션에서 사용자 입력을 적절히 검증하거나 이스케이프 처리하지 않을 때 발생합니다. XSS 공격은 사용자의 세션 토큰, 쿠키, 개인 정보 등을 탈취하거나 사용자를 대신하여 특정 행위를 수행하게 만드는 등 다양한 형태로 이루어질 수 있습니다.

XSS는 왜 등장했는가?

XSS 취약점은 웹 애플리케이션의 발전과 함께 등장했습니다. 초기 웹 사이트들은 주로 정적인 정보를 제공하는 데 초점을 맞췄지만, 시간이 지나면서 사용자 상호작용과 개인화된 콘텐츠의 필요성이 증가했습니다. 이러한 변화로 사용자 입력을 받아서 처리하는 기능이 필수가 되었고, 이 과정에서 입력값에 대한 충분한 검증과 적절한 처리가 이루어지지 않아 XSS와 같은 취약점이 발생하게 되었습니다.

XSS 공격의 작동 원리

✏️ 비 지속적 기법 (non-persistent)

사용자가 특정한 링크를 클릭할 때 발생합니다. 링크에는 악의적인 스크립트가 포함되어 있으며, 사용자가 링크를 클릭하면 웹 애플리케이션은 이 스크립트를 웹 페이지에 반영해 사용자의 브라우저에서 실행합니다.

http://example.com/?query=<script>alert('악의적인 스크립트')</script>

✏️ 지속적 기법 (persistent)

악의적인 스크립트가 웹 서버에 저장되는 경우입니다. 예를 들어, 사용자가 댓글, 게시물, 사용자 프로필 등에 스크립트를 삽입하면, 이 스크립트는 다른 사용자들이 해당 콘텐츠를 볼 때마다 실행됩니다.

<!DOCTYPE html>
<html>
<head>
    <title>XSS 공격 시뮬레이션</title>
</head>
<body>
    <h1>댓글 섹션</h1>
    <div id="comments">
        <!-- 사용자가 입력한 댓글 -->
        <p>사용자 댓글: 
	        <script>alert('XSS 공격입니다!');</script>
		</p>
    </div>
</body>
</html>

✏️ DOM based XSS

DOM 기반 XSS는 웹 애플리케이션의 클라이언트 측 코드에서 발생합니다. 이 경우, 악의적인 스크립트는 페이지 자체에는 저장되지 않지만, 페이지의 DOM을 조작하여 실행됩니다.

// URL의 파라미터를 통해 입력된 값을 페이지에 반영
const input = window.location.href.split('input=')[1];
document.getElementById('output').innerHTML = decodeURIComponent(input);

XSS 공격 방지 방법

✏️ 이스케이핑

<!DOCTYPE html>
<html>
<head>
    <title>XSS 방지 예시</title>
</head>
<body>
    <form id="myForm">
        <label for="userInput">입력:</label>
        <input type="text" id="userInput" name="userInput">
        <button type="submit">제출</button>
    </form>
    <div id="result"></div>
<script>
	document.getElementById('myForm').addEventListener('submit', function(event) {
	    event.preventDefault();
	
	    // 사용자 입력 값 가져오기
	    var userInput = document.getElementById('userInput').value;
	
	    // XSS 방지를 위한 이스케이핑
	    var safeInput = escapeHtml(userInput);
	
	    // 결과를 안전하게 페이지에 표시
	    document.getElementById('result').innerText = safeInput;
	});
	
	function escapeHtml(unsafe) {
	    return unsafe
	             .replace(/&/g, "&amp;")
	             .replace(/</g, "&lt;")
	             .replace(/>/g, "&gt;")
	             .replace(/"/g, "&quot;")
	             .replace(/'/g, "&#039;");
	}
</script>
</body>
</html>

✏️ 사용자 입력 검증

function validateInput(input) {
    let pattern = /<script.*?>.*?<\/script>/gi;
    return input.replace(pattern, '');
}

✏️ CSP 헤더 설정

CSP(Content-Security-Policy) 헤더는 웹 서버가 클라이언트에 보내는 HTTP 응답 헤더 중 하나로, 웹 페이지에서 사용할 수 있는 리소스의 종류를 제한합니다.

Content-Security-Policy: <policy-directive>; <policy-directive>

다음은 자신의 주소와 google.com의 스크립트 리소스만 허용하는 것을 의미한다.

Content-Security-Policy: script-src 'self' *.google.com;

✏️ Vue, React와 같은 프레임워크 이용하기

기본적으로 Vue, React, Angular와 같은 웹 프레임워크는 일부 XSS 공격을 방지하는 메커니즘을 제공합니다.

자동 이스케이프

<h1>{{ userProvidedString }}</h1>
// 값이 '<script>alert("hi")</script>' 일 때

// 다음과 같이 이스케이프 된다.
&lt;script&gt;alert(&quot;hi&quot;)&lt;/script&gt;

참고

위키백과 - 사이트 간 스크립팅
Cloudflare
CSP란?
Vue Guide

디자인패턴을 이용한 장바구니 기능 구현 - 레디스와 스프링부트 활용

베어_ — Sat, 16 Dec 2023 22:52:11 +0900

이커머스 프로젝트를 진행하면서 장바구니 기능에 추가 요구사항이 생겨 리팩토링 하는 과정을 기록합니다. 이번 리팩토링을 위해 전략 패턴과 팩토리 메소드를 사용하였습니다.

팩토리 메서드 패턴은 객체 생성을 위한 패턴으로, 객체를 생성하는 역할을 서브클래스에 위임하여 유연성을 제공합니다.
전략 패턴은 행위를 캡슐화하고 런타임에 행위를 변경할 수 있는 패턴입니다. 이 패턴은 애플리케이션의 일부를 동적으로 교체하고 다양한 전략을 적용할 수 있도록 도와줍니다.

기존 로직

Redis 저장소에 제품을 저장하는 기존 로직을 살펴보겠습니다.

@Service
class BasketItemService(
	...
) {

    fun addBasketItem(basketItemRequest: BasketItemRequest) {
		// redis 저장 로직
    }

}

기존의 컨트롤러는 다음과 같이 작성되었습니다. 그러나 addBasketItem 의 세부 로직이 추가되었습니다. 여기서 토큰이 있는 경우 .addBasketItem()은 데이터를 데이터베이스(DB)에 저장하는 로직을 수행하고, 토큰이 없는 경우 세션에 데이터를 저장하는 로직을 수행해야 합니다.

class BasketItemController(  
    private val basketItemService: BasketItemService,  
) {  
  
    @PostMapping  
    fun addBasketItem(@RequestBody basketItemRequest: BasketItemRequest, request: HttpServletRequest): ApiResponse {  

		// 토큰과 세션의 여부에 따라 로직이 달라짐.
        val response = basketItemService.addBasketItem(basketItemRequest, request)  
        return ApiResponse.of(HttpStatus.CREATED, response)  
    }  
}

전략 패턴 적용

변경되는 부분과 변경되지 않는 부분 분리

애플리케이션에서 변경되는 부분(addBasketItem)과 변경되지 않는 부분(basketItemService)을 분리해보겠습니다. 여기서 변경되는 부분이 전략에 해당합니다.

변경되는 부분 캡슐화

먼저, 변경되는 부분을 캡슐화하기 위한 인터페이스를 만들겠습니다. 이렇게 달라지는 부분을 캡슐화함으로써 시스템의 유연성을 향상시킬 수 있습니다.

interface BasketItemStrategy {  
  
    fun addBasketItem(basketItemRequest: BasketItemRequest, request: HttpServletRequest): BasketItemDTO  
  
}

구체적인 전략 구현

캡슐화된 전략을 구체적으로 구현하는 클래스를 만듭니다. Redis 저장 클래스와 DB 저장 클래스를 만들겠습니다.

Redis 저장 로직 구현

@Service  
class BasketItemRedisStrategyImpl(  
    ...  
): BasketItemStrategy {   
  
    override fun addBasketItem(  
        basketItemRequest: BasketItemRequest,  
        request: HttpServletRequest  
    ): BasketItemDTO {  
		... // Redis 저장 로직
    }  
}

DB 저장 로직 구현

@Service  
class BasketItemDBStrategyImpl(  
	...
): BasketItemStrategy {  

    @Transactional  
    fun addBasketItemToDB(
	    basketItems: MutableMap<String, Any>, 
	    httpSession: HttpSession
	): MutableList<BasketItem> {  
        ...// DB 저장 로직
    }  
}

BasketItemService 업데이트

마지막으로, BasketItemService가 상황에 따라 동적으로 전략을 선택할 수 있도록 수정해주겠습니다.

@Service  
class BasketItemService(  
	// 빈에 접근하기 위해 ApplicationContext를 주입받습니다.
    private val applicationContext: ApplicationContext,  
) {  
  
    fun addBasketItem(basketItemRequest: BasketItemRequest, request: HttpServletRequest): BasketItemDTO { 
    // 토큰의 존재 여부에 따라 적절한 전략을 선택합니다.
    val strategy: BasketItemStrategy 
        if (hasToken(request)) {  
            strategy = applicationContext.getBean(BasketItemDBStrategyImpl::class.java)  
        } else {  
            strategy = applicationContext.getBean(BasketItemRedisStrategyImpl::class.java)  
        }  
		strategy.addBasketItem();
    }  
  
    private fun hasToken(request: HttpServletRequest): Boolean {  
        val token = request.getHeader("Authorization")  
        return token != null  
    }
}

이렇게 전략 패턴을 사용하여 애플리케이션의 일부분을 추상화하고, 유연하게 확장 가능하게 만들었습니다. 이처럼 전략 패턴은 변화하는 부분을 캡슐화함으로써 코드의 수정을 줄이고 동적으로 다양한 전략을 수행할 수 있도록 도와줍니다.

팩토리 메소드 패턴

전략을 동적으로 선택하는 것은 addBasketItem의 역할을 벗어나며, 각 전략이 생성될 때마다 변경될 수 있습니다. 따라서 이를 팩토리 메소드 패턴을 통해 분리해보겠습니다.

@Service  
class BasketItemService(  
    private val basketItemStrategyFactory: BasketItemStrategyFactory,  
) {  
  
    fun addBasketItem(basketItemRequest: BasketItemRequest, request: HttpServletRequest): BasketItemDTO {  
        val strategy = basketItemStrategyFactory.getStrategy(request)  
        return strategy.addBasketItem(basketItemRequest, request)  
    }  
}

@Component  
class BasketItemStrategyFactory(  
    private val applicationContext: ApplicationContext,  
) {  
  
    fun getStrategy(request: HttpServletRequest): BasketItemStrategy {  
        return if (hasToken(request)) {  
            applicationContext.getBean(BasketItemDBStrategyImpl::class.java)  
        } else {  
            applicationContext.getBean(BasketItemRedisStrategyImpl::class.java)  
        }  
    }  
  
    private fun hasToken(request: HttpServletRequest): Boolean {  
        val token = request.getHeader("Authorization")  
        return token != null  
    }  
}

이렇게 함으로써 addBasketItem은 장바구니에 상품을 추가하는 로직에만 더 집중할 수 있게 됩니다.

결론

전략 패턴을 사용하여 프로그램의 변경되는 부분을 캡슐화하고 동적으로 전략을 교체할 수 있도록 했습니다.
팩토리 메서드 패턴을 사용하여 전략 선택 로직을 분리함으로써 서비스 레이어가 비즈니스 로직에 더 집중할 수 있도록 하였습니다.
전략 패턴과 팩토리 메서드 패턴을 통해 코드의 가독성과 유지 보수성이 향상되었습니다.

스프링 세션 적용하기 (feat. filter)

베어_ — Wed, 13 Dec 2023 23:13:30 +0900

Session 정보 이용하기

✏️ 1. 컨트롤러에서 HttpSession 클래스 이용하기

HttpSession 클래스를 파라미터로 받으면 session 정보를 사용할 수 있다.

✏️ 2. 필터 또는 인터셉터 이용하기

필자는 세션 정보를 거의 모든 요청 API에서 확인해야 한다. 따라서 Controller에서 session 정보를 불러오는 중복을 해결하기 위해 필터를 이용하였다.

@Component   class SessionFilter(       private val redisSessionRepository: RedisSessionRepository,   ): OncePerRequestFilter() {          val log = logger()          override fun doFilterInternal(   	    request: HttpServletRequest,   	    response: HttpServletResponse,   	    filterChain: FilterChain   	) {      	    val session = getSessionFromCookie(request)          --- 1 	    if (session == null) {   	        val sessionId = request.getSession(true).id      --- 2 	    }      	    filterChain.doFilter(request, response)   	} }

쿠키에 세션에 대한 정보가 있는지 확인한다.
세션이 없다면 새로운 세션을 생성한다. (세션이 생성될 때 저장소에 저장된다)

MyRedisSessionRepository는 다음처럼 되어 있다.

class MyRedisSessionRepository( 	... ) { 	private val SESSION_PREFIX = "kmall:sessions:"   	private val PRODUCT_PREFIX = "product:"      	fun setSession(sessionId: String) {   	    stringRedisTemplate.opsForSet().add(SESSION_PREFIX, sessionId)   	    stringRedisTemplate.expire(SESSION_PREFIX, 3, TimeUnit.DAYS)   	} }

트러블 슈팅

SrpingSession Redis 트러블 슈팅
SpringBoot + vue.js를 이용한 커스텀 쿠키 받기

스프링 세션 - 이중 발급과, 인코딩된 세션

베어_ — Wed, 13 Dec 2023 23:11:51 +0900

트러블 슈팅

✏️Key가 두 개 생성되는 문제

세션을 저장하는 로직은 다음과 같다.

@Component  
class SessionFilter(  
    private val redisSessionRepository: RedisSessionRepository,  
): OncePerRequestFilter() {  
  
    val log = logger()  
  
    override fun doFilterInternal(  
	    request: HttpServletRequest,  
	    response: HttpServletResponse,  
	    filterChain: FilterChain  
	) {  
  
	    val session = getSessionFromCookie(request)          --- 1
	    if (session == null) {  
	        val sessionId = request.getSession(true).id      --- 2
	        myRedisSessionRepository.setSession(sessionId)   --- 3
	    }  
  
	    filterChain.doFilter(request, response)  
	}
}

1. 쿠키에 세션에 대한 정보가 있는지 확인한다.
2.세션이 없다면 새로운 세션을 생성한다.
3.새로 발급받은 세션을 레디스에 저장한다.

결과를 보면 세션이 두 개가 저장되었음을 확인할 수 있다. 첫 번째는 위의 코드에 의해 발급된 것이고 2번 세션은 왜 발생한 것일까?

이를 해결하기 위해 디버깅 모드로 코드를 하나씩 따라 가 봤다.

getSession()을 호출하면 HttpServletRequestWrapper의 getSession이 호출된다.

class HttpServletRequestWrapper {
	@Override  
	public HttpSession getSession(boolean create) {  
	    return this._getHttpServletRequest().getSession(create);  
	}
}

SessionRepositoryFilter가 동작한다.

@Override  
public HttpSessionWrapper getSession(boolean create) {  
	 // 1. Session이 있는지 확인합니다.
    HttpSessionWrapper currentSession = getCurrentSession();  
    if (currentSession != null) {  
       return currentSession;  
    }  

	 // 2. Session을 생성하고 등록합니다.
    S session = SessionRepositoryFilter.sessionRepository.createSession();  
    session.setLastAccessedTime(Instant.now());  
    currentSession = new HttpSessionWrapper(session, getServletContext());  
    setCurrentSession(currentSession);  
    return currentSession;  
}

RedisSessionRepository가 동작한다.

public RedisSessionRepository {
	@Override  
	public RedisSession createSession() {  
	    MapSession cached = new MapSession();  
	    cached.setMaxInactiveInterval(this.defaultMaxInactiveInterval);  
	    RedisSession session = new RedisSession(cached, true);  
	    session.flushIfRequired();  // 
	    return session;  
	}
}

여기서 flush모드가 yes라면 곧바로 캐시에 업데이트 된다… 아니라면 응답을 보내기 전에 DispatcherServlet에서 save() 메서드를 호출하여 저장하는 작업을 거친다. 즉, 세션을 새로 발급하면 SessionRepositoryFilter가 동작하여 Redis에 세션을 저장해준다.

✏️ 쿠키와 Base64 인코딩

웹 브라우저에서 확인해보면 SESSION이 인코딩되어서 들어간 것을 확인할 수 있다. (세션이 두 개 있는데 위의 글을 읽으면 해결할 수 있다.)

configuration에서 session 생성을 false로 두면 된다고 하는데 잘 동작 되지 않았다.(스프링이 자동으로 넣어주는 기능을 끄니까 아마 제대로 동작했다면 위의 문제도 같이 해결되었을 것이다.) 다음 링크에서 힌트를 얻어 DefaultCookieSerializer부터 디버깅 모드로 하나씩 찾아나갔다.
https://stackoverflow.com/questions/51517246/whats-the-difference-between-cookie-session-and-session-id-in-database-for-spri

val sessionId = request.getSession(true).id 다음 코드를 호출하는 순간 RedisSessionRepository에서 세션을 생성하고 이를 현재 세션으로 넣은 다음 헤더에 추가해준다. 즉, 추가적으로 header에 담는 로직이 필요 없다. 실제로 세션이 2개가 들어왔지만 하나는 base64로 인코딩 한 값이다.

이를 추적하면서 뽑아낸 중요한 코드 리스트다.

Session이 있는지 확인한다.

@Override  
public HttpSessionWrapper getSession(boolean create) {  
    HttpSessionWrapper currentSession = getCurrentSession();  

	// 현재 세션이 존재하면 return 
    if (currentSession != null) {  
       return currentSession;  
    }  
    
	// 캐시되어 있는 세션이 있는지 확인
    S requestedSession = getRequestedSession();  
    if (requestedSession != null) {  
       if (getAttribute(INVALID_SESSION_ID_ATTR) == null) {  
          requestedSession.setLastAccessedTime(Instant.now());  
          this.requestedSessionIdValid = true;  
          currentSession = new HttpSessionWrapper(requestedSession, getServletContext());  
          currentSession.markNotNew();  
          setCurrentSession(currentSession);  
          return currentSession;  
       }  
    }

	// create의 속성이 fasle라면 세션을 생성하지 않는다.
	if (!create) {  
	    return null;  
	}

	// create = true라면 새로운 세션을 생성한다.
	S session = SessionRepositoryFilter.this.sessionRepository.createSession();  
	session.setLastAccessedTime(Instant.now());  
	currentSession = new HttpSessionWrapper(session, getServletContext());  
	setCurrentSession(currentSession);  
	return currentSession;
}

지정한 스토리지에서 Session을 생성한다. (flush모드에 따라 저장 시점이 다르다)

@Override  
public RedisSession createSession() {  
    MapSession cached = new MapSession();  
    cached.setMaxInactiveInterval(this.defaultMaxInactiveInterval);  
    RedisSession session = new RedisSession(cached, true);  
    session.flushIfRequired();  
    return session;  
}

이후 Response 보내기 전에 세션을 Base64로 인코딩하여 header에 저장한다.

@Override  
public void setSessionId(HttpServletRequest request, HttpServletResponse response, String sessionId) {  
    if (sessionId.equals(request.getAttribute(WRITTEN_SESSION_ID_ATTR))) {  
       return;  
    }  
    request.setAttribute(WRITTEN_SESSION_ID_ATTR, sessionId);  
    this.cookieSerializer.writeCookieValue(new CookieValue(request, response, sessionId));  
}

@Override  
public void writeCookieValue(CookieValue cookieValue) {  
    String value = getValue(cookieValue);   // getValue()에서 인코딩함.
	...
    response.addHeader("Set-Cookie", sb.toString());  // 헤더에 저장
}

✏️ 결론

스프링 세션을 적용하면 session이 생성되는 시점에 데이터를 저장해준다.
세션을 쿠키로 반환할 때는 Base64로 인코딩하면 반환한다.

스프링 세션의 이해 - 등장 배경과 그 원리

베어_ — Wed, 13 Dec 2023 22:41:20 +0900

HttpSession

✏️ 세션이 왜 필요한가요?

웹에서 데이터를 전송하는 데 기본적으로 사용되는 HTTP는 본질적으로 상태가 저장되지 않는다. 즉, 동일한 사용자로부터 여러 요청이 들어와도 이를 인식하지 못한다. 그러나 웹 애플리케이션에서 사용자 인증, 장바구니 등과 같은 상태를 유지하는 것이 중요한 시나리오가 있다. 세션은 웹 애플리케이션이 특정 기간 동안 사용자를 인식하고 구분할 수 있게 함으로써 이러한 한계를 극복하는 데 중요한 역할을 한다.

✏️기존 세션의 문제점

전통적인 HttpSession은 컨테이너(ex. Tomcat) 에 종속되어 사용된다. 즉 컨테이너가 세션을 생성하고 애플리케이션에 세션 ID를 제공한다. 이런 방식은 기본적으로 클러스터링 환경에서 실행되는 경우 각 컨테이너가 자체 HTTPSession을 관리한다는 것을 의미한다. 즉, 세션 정보는 다른 서버 간에 공유 되지 않는다는 문제가 있다.

고정 세션

이를 해결하기 위해 고정 세션 접근 방식을 사용할 수 있다.

로드밸런서 또는 웹 서버가 클라이언트와 앱 서버 간에 매칭을 한다.
이 작업은 로드 밸런서가 식별을 위해 클라이언트에 쿠키를 할당함으로써 수행된다.
로드 밸런서는 세션이 진행되는 동안 클라이언트의 각 요청을 동일한 애플리케이션 서버로 라우팅 한다.

고정 세션 방식은 다음과 같은 문제점을 가지고 있다.

특정 서버에 과부하가 걸릴 수 있다.
A서버가 다운되면 B서버는 A서버의 세션에 대한 정보를 얻지 못한다.

이러한 문제를 해결하기 위해 Spring에서는 HTTP Session을 중앙에서 관리하도록 도와준다.

Spring Session

이러한 문제를 해결하기 위해 Spring에서는 HTTP Session을 중앙에서 관리하도록 도와준다.

Session Storage 방식을 사용하면 다음과 같은 장점을 가질 수 있다.

애플리케이션 재시작 시 세션 복원이 가능하다.
로드 밸런서에서 세션을 고정할 필요가 없다. -> 특정 서버에 과부하를 주지 않고 독점적으로 분산할 수 있다.

단점

Session Storage에 장애가 발생하면 모든 세션을 잃어버려 세션을 사용하는 모든 서버에 영향을 미친다. 이를 해결하기 위해 마스터-슬레이브 복제 방법을 사용할 수 있다.
네트워크 I/O가 발생하기 때문에 로컬 메모리보다는 성능적인 면에서 떨어진다.

✏️ 원리

Spring Session은 애플리케이션과 Session management간의 추상화 계층을 제공함으로써 NoSQL, RDBS 등과 같은 영구 저장소에 저장할 수 있도록 도와준다. 따라서 어떤 데이터베이스를 사용하든 Spring Session이 제공하는 API를 통해 똑같은 방법으로 관리가 가능하다. 사용할 수 있는 저장소로는 다음 JDBC, Redis, MongoDB 등이 있다.

Spring Session은 HttpSession을 필터와 Wrapper로 감쌈으로써 기능을 제공한다.

SessionRepositoryRequestWrapper를 이용하여 기본 HttpSession을 커스텀 세션으로 바꾼다.

public class HttpServletRequestWrapper extends ServletRequestWrapper implements HttpServletRequest {

	public HttpServletRequestWrapper(HttpServletRequest request) {  
	    super(request);  
	}
}

public class SessionRepositoryRequestWrapper extends HttpServletRequestWrapper {

	public SessionRepositoryRequestWrapper(HttpServletRequest original) {
			super(original);
	}

	public HttpSession getSession() {
			return getSession(true);
	}

	public HttpSession getSession(boolean createNew) {
			// create an HttpSession implementation from Spring Session
	}

	// ... other methods delegate to the original HttpServletRequest ...
}

HttpServlet 요청을 세션 리포지토리 요청 래퍼로 대체한다.

public class SessionRepositoryFilter implements Filter {

	public doFilter(ServletRequest request, ServletResponse response, FilterChain chain) {
			HttpServletRequest httpRequest = (HttpServletRequest) request;
			SessionRepositoryRequestWrapper customRequest =
					new SessionRepositoryRequestWrapper(httpRequest);

			chain.doFilter(customRequest, response, chain);
	}

	// ...
}

놀라운 점은 스프링 부트를 사용하면 Auto-Configuration 기능 덕분에 다음과 같은 의존성을 추가하고 yml파일에 설정해주는 것만으로 위의 작업을 자동화해준다.

implementation("org.springframework.boot:spring-boot-starter-data-redis")

spring.session.store-type=redis # Session store type.

이렇게 하면 Filter를 구현하는 springSessionRepositoryFilter라는 이름의 Spring 빈이 생성되며, 이 필터는 스프링 세션이 지원하도록 HttpSession 구현을 대체하는 역할을 담당한다.

#스프링세션 #springsession #웹개발 #httpsession #세션관리 #세션스토리지

https://docs.spring.io/spring-session/reference/guides/boot-redis.html
https://docs.spring.io/spring-session/reference/guides/java-redis.html
https://docs.spring.io/spring-session/reference/configuration/redis.html

2차 캐시를 이용한 최적화 기록

베어_ — Thu, 7 Dec 2023 01:14:09 +0900

개인 프로젝트에 2차 캐시를 적용하면서 데이터 최적화를 시도한 기록을 기록합니다.

자바의 표준 캐시 (JCache)

JCache는 자바 애플리케이션을 위한 표준화된 캐싱과 매커니즘을 제공합니다. 캐싱 표준으로 설계되었기 때문에, 벤더 중립적입니다. 즉, JCache API를 사용하여 애플리케이션을 개발하면 다른 캐시 API로의 전환이 용이합니다.

JCache는 다음과 같은 표준 인터페이스를 제공하고 공급자를 제공받음으로써 벤더 중립적인 개발을 가능하게 도와줍니다.

CacheManager - 캐시 설정, 구성 및 종료를 담당하는 인터페이스
CachingProvider
- CacheManager의 생명 주기를 생성하고 관리하는 인터페이스
- 대표적인 공급자로 Ehcache, Hazelcast, Caffeine, Redis 등이 있다.

Ehcache와 JCache

JCache를 청사진이라고 하면 Ehcache는 청사진을 기반으로 한 건축물이라고 할 수 있다. 즉, JCache의 구현체가 Ehcache인 것이다.

Ehcache

EhCache 3.x부터 JCache를 완벽하게 호환한다.
hibernate와 CacheProvider(ehcache) 사이의 중간 역할을 담당한다.
Hibernate에서 JCache를 사용하고 싶다면 다음 의존성을 추가해주면 된다.

implementation("org.ehcache:ehcache:3.10.0:jakarta") 
implementation("org.hibernate.orm:hibernate-jcache:6.4.0.Final")

hibernate-jcache 포함 클래스들

Ehcache vs Redis

최근에는 Redis를 더 많이 사용하는 것 같다. 필자는 다음 글을 참고하고 Ehcache로 정하였다.
https://stackoverflow.com/questions/33123633/redis-or-ehcache

[Redis or Ehcache?

Which is better suited for the following environment: Persistence not a compulsion. Multiple servers (with Ehcache some cache sync must be required). Infrequent writes and frequent reads. Relatively

stackoverflow.com](https://stackoverflow.com/questions/33123633/redis-or-ehcache)

요약하면 다음과 같다.

Redis는 공유 데이터 구조이고, Ehcache는 직렬화된 데이터 개체를 저장하는 메모리 블록이다.
만약 Java만 사용하는 프로젝트라면 Ehcache가 쉬운 선택이다.

실습

springboot(3.1.5), kotlin, Jpa 사용

yml 설정

jpa:  
  properties:  
    hibernate:  
      generate_statistics: true  ## 캐싱 정보를 확인할 수 있다.
      javax.cache:  
        provider: org.ehcache.jsr107.EhcacheCachingProvider   ## --- 2
        uri: ehcache.xml  ## --- 3
      cache:  
        use_second_level_cache: true   ## 2차 캐시 활성화
        region.factory_class: jcache   ## --- 1

Hibernate는 org.hibernate.cache.spi.RegionFactory 인터페이스를 통해 높은 추상화를 구현했다. 따라서 해당 구현체만 제공하면 된다.
공급자로 JSR107(JCache) 표준을 구현한 EhcacheCachingProvider를 선택했다.
Hibernate는 각 엔티티 클래스를 2단계 캐시의 개별 영역에 저장하기 때문에, 캐시할 데이터에 대해서 설정을 해주어야 한다.

[ehcache.xml] // resources 폴더 밑에 생성하면 된다.

<config
        xmlns='http://www.ehcache.org/v3'
        xmlns:jsr107='http://www.ehcache.org/v3/jsr107'>

    <service>
        <jsr107:defaults default-template="default">
            <jsr107:cache name="category" template="categoryCache"/>
        </jsr107:defaults>
    </service>

    <cache-template name="default">
        <expiry>
            <ttl unit="days">90</ttl>
        </expiry>
        <heap unit="entries">10</heap>
    </cache-template>

    <cache-template name="categoryCache">
        <key-type>java.lang.Long</key-type>
        <value-type>com.example.commerce.entity.ProductCategory</value-type>
    </cache-template>

</config>

캐시할 데이터 정하기

Product - ProductCategory 구조의 엔티티에서 ProductCategory는 삽입, 수정, 삭제 등이 이루어지지 않기 때문에 캐싱하기로 하였다.

데이터는 5개 조회하였다.
@Cacheable을 사용하여 캐시할 데이터라고 표시한다.

@org.hibernate.annotations.Cache.Cacheable  
@Entity  
class ProductCategory(  
    @Column(unique = true, nullable = false)  
    val categoryName: String,  
) {  
...
}

@Entity  
class Product(  
    @ManyToOne  
    @JoinColumn    var category: ProductCategory,    
    ) {  
    ....
}

결과

[1차 조회]

Product를 조회하면 지연 로딩을 설정하지 않았기 때문에 ProductCategory 쿼리도 같이 나가게 된다. 빨간색 쿼리를 보면 JDBC 문장(쿼리)이 2개가 실행된 것을 확인할 수 있다.
2차 캐시에 정보를 찾을 수 없어(miss), 이를 저장한다.(put)

2차 캐시 첫 조회

[2차 조회]

2차 캐시에서 필요한 데이터를 찾았다.(cache hit)
쿼리문이 하나만 나갔음을 확인할 수 있다.
속도가 조금 빨라졌다.

2차 캐시 2차 조회

[더 많은 데이터 조회]

2000개의 데이터 조회

2000개 데이터 조회

3000개의 데이터 조회

3000개 데이터 조회

이전 Fetch-Join이랑 데이터 조회를 비교했을 때, Fetich-Join방식이 2차 캐시에 비해 결과를 반환하는 시간 변동 폭이 훨씬 컸다.

https://brightmango.tistory.com/entry/프로젝트-기록-fetch-join을-이용해-쿼리-최적화하기?category=1079515

[프로젝트 기록] fetch-join을 이용해 쿼리 최적화하기

프로젝트를 진행하면서 쿼리 최적화한 과정을 기록하려고 한다. SpringBoot3.x , JPA를 사용한 프로젝트이다. 연관관계 기본적으로 JPA를 사용하여 프로젝트를 진행하면 Delete, Update, 맵핑관계가

brightmango.tistory.com

결론

JCache를 이용하면 벤더 중립적인 코드 작성이 가능하다.
자주 사용되지만 잘 바뀌지 않는 데이터에 대해서 캐싱을 함으로써 최적화할 수 있다

[참고]
https://www.baeldung.com/hibernate-second-level-cache
https://thorben-janssen.com/hibernate-ehcache/#using-ehcache-3x](https://thorben-janssen.com/hibernate-ehcache/#using-ehcache-3x)

[프로젝트 기록] fetch-join을 이용해 쿼리 최적화하기

베어_ — Sun, 3 Dec 2023 23:16:01 +0900

프로젝트를 진행하면서 쿼리 최적화한 과정을 기록하려고 한다. SpringBoot3.x , JPA를 사용한 프로젝트이다.

연관관계

기본적으로 JPA를 사용하여 프로젝트를 진행하면 Delete, Update, 맵핑관계가 설정되어 있는 조회 로직에서 쿼리를 확인하고 최적화를 진행하고 있다. 이번에는 일대다 관계를 가진 엔티티를 조회할 때의 쿼리 최적화를 진행하였다.

@AllOpen  
@Entity  
class Product(  
    @ManyToOne  
    @JoinColumn    
    var category: ProductCategory,  

    ) {  

    @Id @GeneratedValue(strategy = GenerationType.IDENTITY)  
    val id: Long? = null  
}

@Entity  
class ProductCategory(  
    @OneToMany(mappedBy = "category")  
    val products: MutableList<Product>  
) {  

    @Id  
    @GeneratedValue(strategy = GenerationType.IDENTITY)  
    val id: Long? = null  
}

문제의 쿼리

검색어를 기준으로 Product를 조회하는 쿼리를 확인해보자

fun findBySearchWord(searchWord: String): List<Product> {  
    return queryFactory  
        .selectFrom(product)  
        .where(product.productName.contains(searchWord)) 
        .limit(10)  
        .fetch()  
}

쿼리 로그

쿼리가 여러개 나갔음을 확인할 수 있다. 기본적으로 @ToOne관계에서는 fetch 속성의 기본값이 Eager이기 때문에 Product를 조회하면 ProductCategory를 조회하는 쿼리가 한 번 더 나가게 된다. 기본적으로 Product를 사용하는 곳에서 ProductCategory가 항상 같이 사용된다면 fetchJoin()을 이용해서 쿼리를 최적화하는 것이 좋다.

Fetch-join을 활용한 최적화

fun findBySearchWord(searchWord: String): List<Product> {  
    return queryFactory  
        .selectFrom(product)  
        .join(product.category, productCategory).fetchJoin()  // 이 부분 추가됨
        .where(product.productName.contains(searchWord))  
        .limit(2000)  
        .fetch()  
}

fetch-join 쿼리

Fetch-Join을 사용하면 쿼리가 하나만 나가기 때문에 최적화가 된다고 하는데 프로젝트가 간단해서 그런지 이를 느끼기는 쉽지 않은 것 같다.

개인적으로 Fetch-Join을 쓰는 경우가 한 가지 더 있는데 트랜잭션 밖에서 관련 엔티티를 지연로딩 할 때이다.

https://brightmango.tistory.com/entry/OSIV-필터와-지연로딩-에러

OSIV 필터와 지연로딩 에러

관련 포스팅 OSIV와 필터 OSIV란? (Open Session In View) 스프링의 트랜잭션 범위는 Service, Repository 레이어에서만 유지된다. 보통 JPA의 영속성 컨텍스트는 트랜잭션의 생명주기를 따라가는데, OSIV

brightmango.tistory.com

fetch-join의 단점

모든 기술에는 장,단점이 있듯이 fetch-join에도 단점과 한계가 존재한다.

둘 이상의 컬렉션에는 적용할 수 없다.
1. B와 C 모두에 대해 가져오기 조인을 적용하면 B와 C의 각 조합이 중복되는 결과 집합이 생성된다.
페이징을 적용할 수 없다.
1. 데이터 수를 예측할 수 없다.

이런 한계를 극복하기 위해 batch-fetch-size를 지정해줄 수 있다.

[JPA] JPA의 장점과 그 원리

베어_ — Mon, 27 Nov 2023 15:40:32 +0900

이전 포스팅에서 객체지향프로그래밍과 데이터베이스간 패러다임 불일치로 발생하는 문제들을 알아봤다. 이번에는 JPA가 이런 문제를 어떻게 해결하는지 알아보자.

새로운 계층: JPA 레이어

JPA는 데이터베이스와 애플리케이션 사이에서 동작한다. 계층이 하나 더 있기 때문에 최적화 관점에서 시도해 볼 수 있는 것이 많다.

애플리케이션 안에서의 JPA

1. 지연 로딩

Customer를 조회할 때 Orders속성에 명시적으로 액세스할 때까지 SELECT 쿼리가 나가지 않는다.

@Entity
public class Customer {
	@OneToMany(mappedBy = "customer")
	private List<Order> orders;
}

2. Batch Fetching

관련 엔티티를 일괄적으로 로드하여 쿼리 수를 최소화한다.

@Entity  
public class Customer {  
    @OneToMany(mappedBy = "customer", fetch = FetchType.LAZY)  
    @BatchSize(size = 10)  
    private List<Order> orders;  
}

3. 캐싱

반복되는 데이터베이스 쿼리의 필요성을 줄이기 위해 자주 엑세스하는 데이터를 메모리에 저장할 수 있다. 특정 엔티티에 대한 캐싱은 @Cacheable을 사용할 수 있다.

@Entity  
@Cacheable  
public class Product {  
    // fields...  
}

4. 트랜잭션 관리

트랜잭션의 옵션 값 readOnly = true로 설정함으로써 읽기 전용 쿼리로 만들 수 있다. 이를 통해 실수로 인한 데이터 저장, 수정을 막을 수 있고 분산환경에서 읽기 전용 데이터베이스만을 이용하도록 할 수 있다.

@Service  
@Transactional(readonly = true)
public class CustomerService {  

	// @Transactional 을 붙이지 않으면 업데이트 되지 않는다.
    public void updateCustomerDetails(Customer updatedCustomer) {  
        // ... update customer details ...  
    }  
}

5. 데이터 접근 추상화

추상화를 통해 개발자는 데이터베이스 독립적인 코드를 작성할 수 있다. MySQL을 기준으로 개발을 진행해도 중간에 Oracle로 쉽게 바꿀 수 있다.

이런 기능을 제공할 수 있는 이유는 JPA가 있는 새로운 계층에서 영속성 컨텍스트라는 것을 이용하기 때문이다.

영속성 컨텍스트

영속성 컨텍스트란 엔티티를 영구 저장하는 환경을 말하며 다음과 같은 구조를 가지고 있다.

영속성 컨텍스트의 구성

이런 영속성 컨텍스트를 이용하면 다음과 같은 장점을 가질 수 있다.

1차 캐시 : 영속성 컨텍스트 내부에는 캐시를 가지고 있으며 데이터를 영속화(persist())하면 데이터가 1차 캐시에 저장된다.
쓰기 지연 : 1차 캐시에 데이터가 저장되면 쓰기 지연 저장소에 SQL 쿼리를 만들어 저장했다가 트랜잭션이 커밋되는 시점에 데이터베이스에 동기화 한다. 이 기능을 활용하면 모아둔 쿼리를 데이터베이스에 한 번에 전달해서 성능을 최적화할 수 있다.
변경 감지 : SQL 중심의 개발을 하다보면 수 많은 업데이트 쿼리가 생기게 된다.

UPDATE CUSTOMER
SET
	NAME=?
	PHONE_NUMBER=?
WHERE
	ID=?

UPDATE CUSTOMER
SET
	NAME=?
WHERE
	ID=?

이렇게 SQL에 의존적인 개발을 해결하기 위해 JPA는 변경 감지 기능을 제공한다. 변경 감지의 동작 순서는 다음과 같다.

JPA는 데이터를 영속화시킬 때 최초 상태를 복사하여 저장해둔다. 이를 스냅샷이라고 한다.
데이터베이스에 플러쉬할 때 최초 상태와 Entity 상태를 비교하여 UPDATE쿼리를 날린다.

퀴즈

영속성 컨텍스트를 이해하기 위해 다음 문제에 대한 답을 예측해보자.

1. 다음 코드에서 변경 감지가 동작할 지 예측해보자.

@PostMapping("/")  
public Student saveStudent() {  
    Student student = studentService.save();  
    student.name = "changed";  
    return student;  
}

public class StudentService {  
  
    public Student save() {  
        Student student = Student.builder()  
                .name("mango")  
                .grade("30")  
                .sn("1")  
                .build();  
        return studentRepository.save(student);  
    }  
}

다음에서는 변경 감지가 동작하지 않는다. 스프링에서 트랜잭션은 기본적으로 서비스-레포지토리까지만 유지되기 때문에 Controller에서 데이터를 변경해도 데이터베이스에는 적용되지 않는다.

업데이트가 되지 않았음을 확인할 수 있다.

2. 다음 코드는 잘 동작할까? 쿼리문은 어떻게 나갈지 예측해보자

public class StudnetController {    
    @PostMapping("/")  
    public Student saveStudent() {  
        return studentService.save();  
    }  
}

public class StudentService { 
	public Student save() {  
	    Student student = Student.builder()  
	            .name("mango")  
	            .grade("30")  
	            .sn("1")  
	            .build();  
	    studentRepository.save(student);  
	    student.name = "changed";  
	    return student;  
	}
}

INSERT와 UPDATE 쿼리가 한 번씩 나가게 된다.

결과 쿼리

그런데 UPDATE 쿼리를 보면 조금 이상하다. name필드만 업데이트가 되어야 하는데 모든 필드에 대해서 업데이트하고 있다. 즉, JPA는 엔티티의 모든 필드를 업데이트한다. 이렇게 함으로써 데이터베이스에 보내는 전송량이 증가하는 단점이 있지만 다음과 같은 장점이 생긴다.
1. 수정 쿼리가 항상 같기 때문에 애플리케이션 로딩 시점에 수정 쿼리를 미리 생성해두고 재사용할 수 있다.
2. 데이터베이스에 동일한 쿼리를 보내면 데이터베이스는 이전에 한 번 파싱된 쿼리를 재사용할 수 있다.
- 쿼리를 처음 실행하면 JPA가 쿼리 구문을 분석하고 컴파일한다. 이 때, 컴파일된 표현은 JPA 공급자에 의해 캐시 된다.

마지막 문제로 다음 상황에서 쿼리를 예측해보자.

1. Student Entity를 저장한다.
2. 데이터베이스에 flush()한다.
3. findById를 이용해 studnet객체를 조회한다.

@Transactional  
public Student save() {  
    Student student = Student.builder()  
            .name("mango")  
            .grade("30")  
            .sn("1")  
            .build();  
    studentRepository.save(student);  
    studentRepository.flush();  
  
    Student student1 = studentRepository.findById(student.getId()).orElseThrow();  
    System.out.println(student1);  
  
    return student;  
}

Flush는 동기화이지 데이터를 비우지 않는다. 따라서 조회 쿼리가 나가지 않고 영속성 컨텍스트의 1차 캐시에서 값을 가져온다.

조회 쿼리가 나가지 않았음을 확인할 수 있다.

JPA는 장점만 있을까? 단점도 알아보자.

JPA의 단점

1. 일괄 작업에는 적합하지 않다
객체 관계형 매핑 계층과 같이 JPA에서 제공하는 추가 추상화로 인한 오버헤드 때문에 대규모 배치 작업에서 성능이 중요하다면 JPA는 적합하지 않다.

2. 메모리 소비
엔티티 개체 및 해당 관계를 관리하는 특성으로 인해 JDBC에 비해 더 많은 메모리를 소비한다.

3. 러닝 커브
JPA를 이해하기 위해서는 SQL과 객체지향 프로그래밍 그리고 Hibernate에 대해서 이해해야 하기 때문에 러닝 커브가 크다.

[JPA] JPA의 필요성: 객체와 데이터베이스 간의 격차 해소하기

베어_ — Sun, 26 Nov 2023 14:46:38 +0900

객체 지향 프로그래밍의 도전 과제

객체 지향 프로그래밍의 영역에서는 추상화, 상속, 다형성이라는 3박자가 복잡한 시스템의 제어를 조율한다. 그러나 이러한 원칙을 데이터 저장으로 확장하면 수많은 과제가 발생한다. JDBC API 사용 시 불편한 점을 고려하여 그 복잡성을 자세히 살펴보자. 예를 들어 User객체를 조회해보자.

// 저장
class UserJdbcTemplate {
    public User findUserByUsername(String username) {  
    String sql = "SELECT * FROM users WHERE username = ?";  

    return jdbcTemplate.queryForObject(sql, new Object[]{username}, (resultSet, rowNum) ->  
            new User(  
                    resultSet.getLong("id"),  
                    resultSet.getString("username"),  
                    resultSet.getString("email"),  
            )  
    );  
}
}

여기서는 데이터베이스와 상호 작용하는 데 JDBC API를 사용하여 어느 정도 추상화 수준을 제공한다. 그러나 School와 같은 새로운 요소를 도입하면 문제가 발생한다.

public User findUserByUsername(String username) {  
    String sql = "SELECT u.*, s.school_name FROM users u " +  
            "LEFT JOIN schools s ON u.school_id = s.id " +  
            "WHERE u.username = ?";  

    return jdbcTemplate.queryForObject(sql, new Object[]{username}, (resultSet, rowNum) ->  
        new UserWithSchool(  
                resultSet.getLong("id"),  
                resultSet.getString("username"),  
                resultSet.getString("email")  
                new School(  
                        resultSet.getLong("school_id"),  
                        resultSet.getString("school_name")
                )  
        )  
);

이를 위해서는 UserJdbcTemplate의 코드와 SQL쿼리가 어떻게 나가는지 확인해야 한다. 즉 비즈니스 요구사항을 모델링한 객체인 엔티티를 신뢰할 수 없게 된다. 또, 물리적으로는 추상화가 되어있지만 논리적으로는 강한 연관관계를 맺고 있기 때문에 요구사항이 바뀌면 SQL도 같이 바뀌어야 한다.

정리하면 다음과 같은 문제가 있다.

엔티티를 신뢰할 수 없다.
SQL과 객체가 강한 의존관계를 갖고 있어 OCP원칙을 지키기 어렵다.

원인 분석

이러한 문제는 데이터 중심 데이터베이스와 객체 지향 프로그래밍의 원칙 사이의 불일치에서 비롯된다.

1. 상속

데이터베이스에는 상속 개념이 없어 객체 지향 모델과의 원활한 통합에 장애가 된다.

2. 연관관계

객체는 연관된 객체를 조회할 때 참조를 사용하지만 데이터베이스는 외래 키를 사용한다.
객체 참조의 단방향 특성은 외래 키의 양방향 특성과 충돌한다.

// 객체지향 기준
class User {
    Long id;
    String username;
    School school;
}

class School {
    Long id;
    String schoolName;
}

// 데이터베이스 기준
class UserDB {
    Long id;
    String username;
    Long schoolId; // Fk
}

class SchoolDB {
    Long id;
    String schoolName;
}

데이터베이스 쿼리를 이용해서는 schoolId를 통해 UserDB와 SchoolDB모두 조회가 가능하지만, 객체지향 개념에서는 UserDB만 School을 조회할 수 있다.

3. 모델링

모델링 할 때도 큰 차이가 있다. 데이터베이스는 기본적으로 컬럼 값을 기본으로 외래 키 관계를 맺는다.

데이터베이스 기준 모델링

class User { Long id; Long schoolId; }

객체 기준 모델링

class User { Long id; School school; }

이런 모델링 방식은 객체 그래프를 탐색할 때 큰 차이를 보인다. 예를 들어 User클래스에서 user.school을 통해 School객체를 참조할 수 있다. SQL에서는 SQL 실행 시점에 참조할 객체들이 지정된다. 하지만 JPA에서는 지연로딩 이라는 개념을 통해서 원하는 시점에 select 조회를 함으로써 객체 조회가 되기 때문에 이러한 차이가 생긴다.

비교

데이터베이스에서는 같은 ID의 객체를 두 번 조회하면 이는 서로 다른 객체가 된다.

User user = getUser(1L);
User user2 = getUser(2L);
System.out.println(user == user2) // false

기본적으로 == 비교는 참조 주소를 기준으로 비교하기 때문이다. 데이터베이스적으로 같은 인스턴스를 반환하도록 하는 것은 쉽지 않다. JPA에서는 같은 트랜잭션일 때 같은 객체가 조회되는 것을 보장한다.

결론

관계형 데이터베이스의 사용은 데이터 중심이기 때문에 객체지향프로그래밍이 어려워진다. 그래서 다음과 같은 문제를 가진다.

추상화를 했음에도 불구하고 강한 의존관계가 생긴다.
비즈니스 로직을 모델링한 엔티티를 신뢰할 수 없다.

JPA에서는 지연로딩, 객체 그래프 탐색, 동일성 보장 등의 방법을 이용하여 이러한 문제점을 중간에서 해결해준다. 다음 포스팅에서는 JPA가 데이터베이스에 데이터를 저장할 때 겪는 문제점을 어떻게 해결하는지 자세히 알아보자.

[프로젝트 기록] Redis 메인/레프리카 서버 만들기

베어_ — Sun, 12 Nov 2023 01:36:31 +0900

[ Redis 레프리카 서버 만들기 ]

이용하고 있던 Redis EC2의 이미지를 복제하여 새로운 인스턴스를 생성해주었다.

두 개의 레디스를 생성한 모습

복제한 레디스의 정보를 확인해보자.

redis-cli info

replica 서버의 info

Role설정이 master로 되어있는 것을 확인할 수 있다. 이를 replica로 설정해주자.

replicaof (사설 IP) (포트번호)
Ex ) replicaof 172.1.1.1 6379

다시 info를 입력하여 확인해보면 slave로 바뀐 것을 확인할 수 있다. 하지만 master_link_status: down임을 확인할 수 있다.

Slave로 설정한 뒤 info

/var/log/redis/redis-server.log의 기록을 살펴보면 다음과 같이 Connection refused가 발생하고 있음을 알 수 있다.

3291:S 11 Nov 2023 16:26:32.165 * Connecting to MASTER 172.31.43.174:6379
3291:S 11 Nov 2023 16:26:32.165 * MASTER <-> REPLICA sync started
3291:S 11 Nov 2023 16:26:32.165 # Error condition on socket for SYNC: Connection refused

이를 해결하기 위해 메인 서버의 /etc/redis/redis.conf 파일을 수정해주어야 한다.

// redis.conf의 bind 코드를 수정한다.
bind 127.0.0.1 (사설 IP 주소)

service redis restart // 실행하고 레프리카 서버의 로그를 확인해보자

메인/레프리카 서버의 연결 성공

[ 힘들었던 점 ]

사설 IP, 공인IP를 bind에 적음에도 불구하고 메인/레프리카 서버 연결이 안되었다. bind 0.0.0.0으로 설정하면 해결되었지만 보안에 문제가 생기기 때문에 적절한 해결책이 아니었다. 뭐가 문제인지 파악하기 위해 예상되는 문제점을 모두 검증해보았다.

1. 방화벽 설정 유/무 - 방화벽 설정이 되어있는지 확인해보니 inactive로 설정되어 있었다. 문제의 원인이 아니었다.

2. ec2의 inbound 설정 - 디버깅을 위해 모든 TCP, 모든 IP에 대해서 설정해놓고 연결을 확인해보았다. 여전히 문제가 발생했다.

3. bind의 의미를 잘 못 알고 있는지 확인했다. 처음에는 요청한 IP주소를 허락해준다는 의미로 사용했는데 알고보니 이 주소로 들어온 요청은 처리한다는 의미였다.... 그것도 모르고 나는 계속 레프리카 서버의 사설 IP주소를 메인 서버의 redis.conf에 설정해주고 있었다.