꿀잠

프로젝트에 알림 기능이 요구 사항이 생겨 기능 구현을 하고 있었다.
Spring WebSocket Config 코드 작성과 프론트단에서 서버에 웹소켓 연결을 요청하는 코드를 완성한 후 테스트를 하였다.

클라이언트에서 소켓 연결 로그, 서버에서의 CONNECT 로그 모두 잘 찍혔다. 그러나 클라이언트에서 연결이 후 subscribe 를 설정하는 callback 함수 실행이 되지 않았다. 서버쪽에서도 API 로그가 전혀 찍히지 않았다.

엔드 포인트에 오타는 없는지, 문법이 잘못되지는 않았는지 한참을 찾았으나 원인을 찾지 못하다 원인을 찾게 되었다. 예상치 못한 부분이었기에 한참을 걸려 찾게 되었다. 

원인은 새로 작성한 코드 부분이 아니라 기존에 존재하던 스프링 설정에 있었다. 프로젝트의 구조 및 성능을 위해 Spring Bean을 Lazy Init 하도록 설정이 되어있는 부분이 있었고 해당 부분이 원인이었다. 

WebSocket 연결을 위해 WebSocket Config 에 웹소켓을 통해 subscribe 및 publish 를 위한 엔드포인트의 prefix를 설정하는 부분 및 여러가지 설정을 하는 부분이 있다. 엔드포인트를 설정하는 부분이 스프링이 실행될 때 Bean이 생성되며 설정되어야 하지만 Lazy Init 을 할 경우 해당 Bean이 웹소켓 엔드포인트 설정이 되어야하는 시점이 지난 이후 생성되는 것이었다. 

결국 lazy init 하는 부분에서 Websocket 관련 Bean 은 lazy 하지 않게 변경한 이후 정상적으로 테스트가 성공적으로 되는 것을 확인하였다.

요약: WebSocket 관련 Bean은 LazyInit 하면 안된다.

@Test 어노테이션의 패키지를 확인해주자

import org.junit.jupiter.api.Test; // jupiter package, JUnit 5

@SpringBootTest

import org.junit.Test; // JUnit 4

@SpringBootTest
@RunWith(SpringRunner.class)

org.junit.jupiter.api.Test 패키지는 JUnit 5 를 사용하며 해당 어노테이션을 쓰지 않아도 동작하지만
org.junit.Test 패키지는 JUnit 4 를 사용하며 @RunWith(SpringRunner.class) 가 필수이다.

사이드 프로젝트 중 @Test 어노테이션 만으로도 동작하는 것을 확인하고 새로운 테스트 클래스를 만든 후에
스프링 빈이 주입되지 않아 당황하였다.
스프링 버젼 자체를 최신으로 해서 RunWith 어노테이션이 필요하지 않아진줄 알았지만
Test 어노테이션의 패키지가 영향을 준다는 사실을 확인했다.

이전글 - 개발을 위해 Local, Dev Server WAS 환경 분리하기 1 - Intellij 환경 변수 이용하기 :: 꿀잠 (tistory.com)

WAS 환경을 분리하기 위해 axios 의 base url 을 분리하였고, 문제는 해결되어진 것으로 보았다. 그러나 그 이후 더 큰 문제가 발생하였다. 개발 WAS 에서 Session ID 가 요청마다 새로 생기는 문제였다. 우리의 로그인 방식이 세션 방식이었기에 이 문제는 크게 작용하였다.

로컬 WAS 환경에선 문제 없었으나 개발 WAS 에선 로그인 이후에 바로 다음 요청시 세션이 초기화 되어 로그인 인증을 할 수 없는 것이었다.

이것은 CSRF 방지를 위한 브라우저의 보안 정책 때문이었다. 세션 ID를 담은 쿠키를 보내려면 적절한 SameSite 정책이 포함되어야 하는 것이었다. Dev WAS 와 Local WEB으로 분리된 프로젝트 환경이기에 기본적으로 같은 사이트(SameSite)가 아닌 상황이었고, 서버는 SameSite 가 아닌 WEB 프로젝트의 쿠키를 폐기하고 새로 생성하였던 것이다.

아래와 같이 Spring Boot 의 CookieSerializer Bean을 새로 등록하는 방식으로 SameSite 정책을 None으로 변경해주었다.

@Bean
public CookieSerializer cookieSerializer() throws MalformedURLException {
    DefaultCookieSerializer serializer = new DefaultCookieSerializer();
    serializer.setSameSite("None");
    serializer.setUseSecureCookie(true); // None 일 경우 필수
    return serializer;
}

위와 같이 None 설정을 하여 진행하였지만 이후에 추가적인 문제가 생겼다. 바로 Secure 옵션을 반드시 주어야 한다는 점이다. 프로젝트에 HTTPS를 적용하여야 했다. Local 환경에 SSL 인증서를 설치하는 방법도 있지만 개발 환경에서 serve 명령어를 변경하여 간단히 해결하는 방법도 있다. package.json 에서 npm run serve 명령어를 아래와 같이 옵션을 주는 형태로 해결하였다.

 "serve": "vue-cli-service serve --https true",
 "serve-local": "vue-cli-service serve",

Dev Server WAS 환경을 바라 볼 때는 npm run serve 명령어를 사용하고, Local WAS 를 바라볼 때는 npm run serve-local를 사용하면 된다. Local 에서는 SameSite 인 상황이기에 쿠키의 새로운 생성을 걱정하지 않아도 되었기 때문이다.

분리 방법을 요약 하자면 아래와 같다.

1. 환경 변수를 이용한 axios base url 분리
2. Local Web -> Server Was 환경에서 Session 이 초기화 되면 안되는 환경일 경우 SameSite None, SecureCookie 설정
3. Local Web Https 적용(로컬 SSL 인증서 설치 또는 실행 명령어로 해결)

이로써 로컬 및 서버 WAS 인지에 따른 개발환경 분리를 완료할 수 있었다.

추가내용

CookieSerializer Bean 을 새로 등록하는 방법 외에도 방법이 있어 변경하여 적용후 남긴다.

개발 환경에서만 필요한 옵션이었기에 개발서버 기준application.properties 로 분리하였다.

server.servlet.session.cookie.same-site=none
server.servlet.session.cookie.secure=true

오늘은 개발시 프론트엔드(WEB) 프로젝트와 백엔드(WAS) 프로젝트로 분리되어 있을 시 LOCAL WAS 또는 배포되어진 WAS로 환경을 분리한 경험을 기록하고자 한다. 

현재 진행중인 프로젝트에서 HTML, CSS에 관한 부분을 타 회사 팀에서 맡게 되어 환경을 분리해야 하는 상황이 생겼다. 퍼블리싱을 담당한 회사는 우리 회사에서 만들고 있는 SpringBoot 프로젝트 환경이 없다 보니 이에 대한 부분을 제공해야 했기 때문이다. 퍼블리싱 이외의 javascript 관련 코드도 우리 팀이 맡은 상황이다 보니 ajax 코드가 추가될 시 퍼블리셔 업체에서 동작을 확인할 수 있도록 해주어야 했다. 

우리 팀은 WEB과 WAS 모두 개발하기 때문에 WAS 환경을 LOCAL 에서 실행하며 테스트 해야했고, 퍼블리셔를 위한 서버 WAS를 배포해주어야 했다. 이때 두 환경의 axios base url을 분리하여 이 부분을 해결하였다.

우리팀: Local Vuejs 개발 -> Local Was
퍼블리셔: Local Vuejs 개발 -> Dev Server Was

이러한 환경 분리를 위해 환경 변수를 이용하였으며 인텔리 제이에서 npm 실행 환경을 설정할 시 환경 변수를 주어 구분하였다. Edit congirutaion -> Environment 에서 간단히 가능하였다. 처음에 환경 변수를 설정하였는데도 불구하고 값이 제대로 읽혀지지 않아 이유를 찾아보니 명명법을 지켜야 제대로 읽을 수 있었다. 
Vue의 경우 "VUE_APP_" 이란 접두사를 붙여주어야 했다. React 의 경우 REACT_APP_ 이란 접두사를 붙여주어야 한다고 한다.

이를 통하여 axios 의 base url 을 분리하였고, 문제는 해결되어진 것으로 보았다. 그러나 그 이후 더 큰 문제가 발생하였다. 개발 WAS 에서 Session ID 가 요청마다 새로 생기는 문제였다. 우리의 로그인 방식이 세션 방식이었기에 이 문제는 크게 작용하였다. 

이것에 대한 내용은 다음 링크에 이어 쓰도록 하겠다.

다음글 - 개발을 위해 Local, Dev Server WAS 환경 분리하기 2 - SameSite란 :: 꿀잠 (tistory.com)

운영 서버에서 로그를 확인해 보아야 하는 일이 생겼다.
그런데 왜인지 로그 파일을 저장하는 경로가 보이지 않는 것이다. 운영 서버 리눅스 계정이 root 계정이 아니었기에 권한의 문제로 보이지 않는 것으로 처음엔 생각하였다.

고객사 개발자분께 해당 경로의 로그 파일 확인을 요청하고 DevOps에 빠삭하신 차장님께 상의 하였다. 운영 서버를 한동안 체크하였고, 애초에 로그가 저장되지 않았다는 사실을 깨달았다. 고객사 개발자 분도 파일이 아예 존재하지 않는다고 연락을 주셨다. 전임자 분이 담당할 때 부터 지금까지 운영 서버 이슈는 DB쪽 체크를 하는 정도에서 문제를 해결할 수 있었기에 로그가 저장되고 있지 않다는 사실을 몰랐던 것이다.

로그가 보이지 않았던 이유는 읽기 권한이 없는 것의 문제가 아니라 쓰기 권한의 문제였다. Spring 서비스가 당시 제공 받은 계정으로 실행되고 있었고, 쓰기 권한이 없던 계정의 서비스이다 보니 로그 라이브러리에서 로그 파일을 쓰지 못하였던 것이다. 로그 파일 경로를 해당 계정의 하위 경로로 바꾸어 문제를 해결하였다.

요약: Spring 로그가 남지 않는다면 로그 경로에 대한 서비스의 실행 계정의 쓰기 권한을 확인해야 한다.

ArrayList 의 contains 함수는 해당 값이 현재 List 에 있는지 확인하는 함수이다.
그런데 알고리즘 문제를 푸는 중 int[] 타입을 Arrays.asList를 이용하여 변환 후 ArrayList의 contains 함수를 이용하여 int 타입의 값이 확인이 안되는 것이었다. 확인해본 결과 contains 내부에서 값을 체크할 시 equals 함수를 사용하고 있었다.

public boolean contains(Object o) {  
    return indexOf(o) >= 0;  
}

public int indexOf(Object o) {  
    return indexOfRange(o, 0, size);  
}  

int indexOfRange(Object o, int start, int end) {  
    Object[] es = elementData;  
    if (o == null) {  
        for (int i = start; i < end; i++) {  
            if (es[i] == null) {  
                return i;  
            }  
        }    } else {  
        for (int i = start; i < end; i++) {  
            if (o.equals(es[i])) {   // 바로 이곳
                return i;  
            }  
        }    }    return -1;  
}

LinkedList 의 경우 Node 의 next 노드와 equals 함수를 이용해서 contains 상태를 확인하고 있었다. Arrays.asList 함수의 경우 int[] 타입을 변환 시킨 것이다 보니 값들이 원시타입이어서 equals 함수를 이용할 수 없어 false 가 리턴된 것으로 예상된다.

// int[] arr 일 경우
List<Integer> list = Arrays.stream(arr).boxed().collect(Collectors.toList());

원시타입이 아닌 Integer 타입으로 위와 같이 변환하여 사용하는 것으로 해결하였다.

프로젝트에서 인터페이스 관련한 부분을 유지보수 할 때 알게된 내용이다.
정해진 데이터를 순서대로 테이블에 INSERT 해야 하는 상황이었다.

그런데 자꾸 하나의 트랜잭션에서 for문 돌면서 순서대로 insert 하는 데이터가 순서대로 들어가지 않는 것이었다.

대략 위와 같은 데이터를 INSERT 하는 상황이었다고 가정하고 설명하겠다.
분명히 순서대로 데이터를 INSERT 문을 실행하였고, Spring 로그에 찍힌 ISNERT 문도 A 데이터 기준으로 1,2,3 순서대로 되었는데 말이다.

당시 입력되는 순서를 보고 테스트해주시던 분이 다른 데이터 기준으로 입력되는 것 같다고 말씀해주셨다. A 데이터 기준으로 말하자면 3->1->2 순서로 입력되고 있었다.

도대체 어찌된 일인지 테이블의 구성을 살펴보던 중 예상되는 이유를 발견하였고,
해당 부분을 수정하고 테스트한 결과 원하는 순서대로 INSERT 할 수 있었다.

그 이유는 바로 테이블 키에 있었다. 당시 해당 테이블엔 별도의 PK 는 없었고, 유니크 키만 B,C,D의 복합키로 걸려있었다.

데이터가 실제로 입력되던 3->1->2(A 기준) 이 B -> C -> D 의 키 순으로 정렬되어 INSERT 되고 있다면 딱 설명이 되는 상황이었던 것이다.

실제로 해당 테이블의 키 설정을 A 컬럼을 PK로 하여 다시 설정한 후에는 원하는 순서대로 INSERT 할 수 있게 되었다.

해당 상황은 인덱스와 관련이 있지 않을까 생각된다. 인덱스 관련하여 학습 했을 때 데이터베이스는 인덱스를 기준으로 정렬한 테이블을 저장된다는 내용을 본 적이있다. 트랜잭션에서 데이터들을 해당 테이블에 INSERT 할 때 PK 값이 없다보니 유니크키에 걸린 인덱스를 기준으로 정렬해서 INSERT 된것으로 예상된다.

PK는 설정시 인덱스를 기본적으로 생성한다. 따라서 테이블에 PK를 설정한 이후에는 PK 인덱스를 기준으로 순서대로 INSERT 된 것으로 판단된다.

얼마전에 DBeaver 툴을 이용해서 데이터를 수정하는데 자꾸 다른 row가 수정되는 것이었다.
분명히 나는 한 row를 수정했는데 테이블 전체의 데이터가 자꾸 변경되는 것이었다.

그랬던 이유를 결국 찾게 되었는데 바로 키때문이었다. 당시 테이블에 키 설정을 새로 하려고 기존에 있던 키를 제거한 상황이었다. 테이블 전체에 아무런 키 설정이 되어있지 않다보니 DBeaver 툴에서 Update를 실행할 때 내가 수정한 row가 어느 row 인지 인식을 못하는 것이었다. 새로운 키를 다시 생성하자 정상적으로 Update가 되었다.

DBeaver 최초 설치시 JDBC 드라이버를 설정해주는 걸 생각해보면, 결국 DBeaver 툴이 데이터를 수정할때는 DB 자체를 수정하는 것이 아니라 JDBC를 통해 DB를 조작하는 것으로 예상된다. 

내부적으로 where 1=1 + key를 이용한 조건을 쓰는걸까? ㄷㄷ..
DBeaver 툴 무료 버젼으로도 상당히 편하게 잘 쓸 수 있지만 키 식별이 안되어 update row를 확인할 수 없다면 update가 안되어야 하는 것이 아닌가 생각이 든다.

좋은 툴이지만 조심해서 써야겠다.