블로그으으

[cursor] 갑자기 spring boot 실행 안될 때(기본 클래스를 찾거나 로드할 수 없습니다. ClassNotFound)

rangrangerang — Wed, 21 May 2025 13:24:47 +0900

종종 cursor 에서 스프링 부트가 돌지 않는 경우가 생기는데 그때마다 시간을 많이 쓰는 것 같아 기록으로 남겨둔다

오류 상황들

실행(f5)을 했을 때 아래와 같이 터미널에 오류 메세지가 뜨면서 실행이 안된다

오류: 기본 클래스 src.main.java.com.xxx.XXX (를) 찾거나 로드할 수 없습니다.
원인: java.lang.ClassNotFoundException: src.main.java.com.xxx.XXX

Spring Boot Dashboard에 프로젝트가 안 뜸
프로젝트를 열었는데 Spring Boot Dashboard에서 프로젝트가 보이지 않는다.

Run and Debug 에서 실행(F5) 을 해보지만 아래 오류가 발생하며 안된다

❗해결 방법

clean java

ctrl + + shift + p 를 눌러 Java: Clean Java Language Server Workspace 를 한다

좌하단에 아래와 같은 경고 메세지가 뜨는데 Reload and delete 를 해준다

jdk 경로 설정

settings.json 에 jdk 경로가 잘 설정되어 있는지 확인 해보자

"spring-boot.ls.java.home": "C:\\Users\\xxx\\.jdks\\azul-11.0.24"

위의 방법으로 해결되지 않으면 아래 작업들도 해보자.

cursor 재시작
Spring Boot Dashboard 재설치
launch.json 삭제
clean & build

최후의 수단

정 안 되면 그냥 프로젝트를 새로 clone 받아서 열자. 그게 제일 빠를 수도 있다

cursor 에 postgres MCP 연동하기(대화로 쿼리 날려보기!)

rangrangerang — Thu, 15 May 2025 10:43:07 +0900

요즘은 Intellij 대신 Cursor를 사용해보는 중인데, 오늘은 여기에 PostgreSQL MCP를 붙여서 AI와 채팅으로 DB 쿼리를 날려보는 작업을 해봤다.

MCP(Model Context Protocol)란?

MCP(Model Context Protocol)는 AI 모델이 외부 시스템(예: GitHub, Notion, SQL DB 등)과 쉽게 통신할 수 있도록 만들어진 오픈소스 표준 프로토콜이다. 쉽게 말하면, AI 모델과 외부 시스템 간의 연결 방식과 데이터 형식을 USB-C처럼 표준화한 규격이다.

이 영상을 한번 보자! 짧고 쉽게 설명해준다 → https://www.youtube.com/watch?v=-b0IEN4JAGE

❓ Cursor란?

VS Code 기반의 AI 개발 환경이다.
GitHub Copilot보다 더 깊은 코드 컨텍스트를 이해하고, 자연어로 코드 수정·리팩토링·디버깅 요청을 할 수 있다.

Copilot이 자동완성이라면, Cursor는 진짜 AI 개발 도우미에 가까움!

️ Postgres MCP 붙이기

0. node, npm을 설치한다
설치 안 되어 있다면 Node.js 공식 사이트를 참고하자

node -v
npm -v

1. Cursor에서 MCP 서버 추가

Cursor Settings > MCP > Add new global MCP server 을 클릭한다

2. mcp.json 설정 추가

아래처럼 PostgreSQL MCP 서버를 등록한다.

{
  "mcpServers": {
    "postgres": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-postgres",
        "postgresql://{username}:{password}@{host}:{port}/{database}"
      ]
    }
  }
}

{} 부분은 본인의 DB 정보로 채워준다.
예: postgresql://admin:1234@localhost:5432/mydb

3. MCP 탭에서 Postgres 활성화 확인
MCP 탭을 열면 postgres가 보일 것이다.
왼쪽에 초록색 불이 들어와 있으면 연결 성공!
(시간이 조금 걸릴 수 있음. 조금 기다려도 안되면 새로고침 눌러보기)

실제로 쿼리 날려보기

이제 실제로 잘 되는지 확인해보자

1. Cursor 우측 챗 영역을 Agent 모드로 바꿔준다. 쿼리로 확인해야할 내용을 작성해보자.

2. 그러면 MCP가 자동으로 쿼리를 생성해준다. 확인해보고 맞다면 Run tool 을 클릭해준다

3. 그럼 아래와 같이 실행 결과를 보여준다

말로만 듣던 MCP를 실제로 써보니까, 진짜 잘만 쓰면 할 수 있는 게 무궁무진 할 것 같다는 생각이 들었다. 나중엔 진짜로 AI한테 "피그마 기획부터 프론트, API, DB까지 다 해줘" 하면, 말만으로 개발이 끝나는 시대가 올지도 모를 것 같다. 요즘 이런 도구들 잘 써먹는 게 결국 진짜 개발 생산성으로 이어지는 것 같아 더 공부해봐야 겠다.

같은 쿼리인데 결과가 다르게 나온다면? – MyBatis 1차 캐시

rangrangerang — Sun, 13 Apr 2025 17:12:39 +0900

이번에 꽤 흥미로운 이슈를 하나 겪었다. 동일한 쿼리, 동일한 파라미터로 MyBatis 쿼리를 두 번 실행했는데, 첫 번째 쿼리의 결과와 두 번째 쿼리의 결과가 달랐다. (p6spy를 통해 확인했을 때 두 번째 쿼리는 로그조차 안 찍힘)

결론부터 얘기하자면, MyBatis의 1차 캐시 때문에 발생한 문제였다.

트랜잭션과 1차 캐시

트랜잭션 내에서 1차 캐시가 동작한다는 점을 이해하는 것이 중요하다. MyBatis에서 1차 캐시는 SqlSession 단위로 관리되며, 하나의 트랜잭션 내에서 같은 SqlSession을 사용하기 때문에 트랜잭션 동안 캐시된 데이터는 계속 유지된다. 이 말은 트랜잭션 내에서 같은 쿼리와 파라미터로 데이터 조회 시, 쿼리가 실행되지 않고 1차 캐시에서 결과를 가져온다는 의미다.

따라서 트랜잭션 내에서 같은 데이터를 여러 번 조회하는 경우, 1차 캐시로 인해 의도치 않은 데이터 오염이 발생할 수 있다. 예를 들어, 위의 경우에서는 빈 리스트를 처음 조회하고, 그 리스트를 수정했는데, 다시 조회 시 1차 캐시에서 수정된 리스트를 그대로 가져와 DB에는 없는 데이터가 포함된 리스트를 반환하게 되는 상황이 발생했다.

참고로 Mybatis에는 1차 캐시와 2차 캐시가 있다(https://codingdreamtree.tistory.com/92)

상황 정리

케이스를 간단히 요약해보면 아래와 같다

1. mapper를 통해 name=aaa인 데이터를 가지고 온다 -> 결과없음(0개)
2. 1을 통해 가지고 온 데이터를 리턴하고 이후 로직에서 1에서 리턴한 객체에 add 한다
3. aaa 유저를 다시 mapper를 통해 가지고 온다 -> 쿼리 로그 찍히지 않음, 결과는 1개

처음엔 이게 뭔가 싶었는데, 알고 보니 MyBatis는 동일한 쿼리와 동일한 파라미터로 요청이 들어오면 1차 캐시(Local Cache)에서 결과를 꺼내 반환하기 때문에 생긴 현상이었다. 문제는 1차 조회 결과(빈 리스트)를 그대로 반환해서, 이후 로직에서 그 리스트를 수정했다는 거다.

결국 3번 조회 시에는 쿼리를 날리지도 않고, 캐시에 있던 조작된 리스트를 그대로 반환해버린 것이다.
당연히 DB에는 없는 데이터인데도, 있는 것처럼 처리되는 상황이 되어버린 셈이다.

아래는 상황을 코드로 간략하게 재현해본 코드이다:

    @Test
    public void testFirstLevelCacheIssueWithLoop() {
        String notExistUser = "notExistUser";

        for (int i = 0; i < 2; i++) {
            List<User> users = getUserListAndModify(notExistUser);
            System.out.println("Loop " + i + " - users.size() = " + users.size());
            users.add(new User()); //  add() 수행
        }
    }

    /**
     * 유저 데이터를 조회하고, 내부에서 add() 수행
     * 동일 쿼리와 파라미터 사용 시 1차 캐시 영향 받음
     */
    private List<User> getUserListAndModify(String name) {
        List<User> users = userMapper.getUserByName(name); // 1차 캐시 대상
        return users;
    }

로그를 확인해보면, 3번 쿼리는 아예 실행조차 되지 않는다.
1차 캐시에 의해 생략됐기 때문이다.

즉, users 리스트는 같은 객체고, add가 누적되면서 사이즈가 계속 증가한다.
실제로 DB엔 아무것도 없지만, 코드상에선 계속 유저가 생겨나는 상황이 된 것이다

해결 방안

1. 1차 캐시를 끈다(비추)

MyBatis에서는 SqlSession 단위로 1차 캐시를 사용한다.
필요하다면 아래처럼 캐시를 직접 초기화할 수도 있다:

sqlSession.clearCache();

아니면 설정에서 캐시 범위를 좁힐 수도 있다:

<settings>
  <setting name="localCacheScope" value="STATEMENT"/>
</settings>

아니면 해당 쿼리에서만 캐싱을 하지 않을수도 있다:

<select id="selectUser" parameterType="int" resultType="User" flushCache="true">
    <!-- Your SQL statement here -->
</select>

하지만 이건 근본적인 해결책이라기보다는, 그때그때 문제점만 막는 것에 가깝고, 이로인해 어떤 사이드 이팩트가 발생할지 모른다.

2. 조회한 데이터를 직접 수정하지 않도록 한다(추천 )

내가 겪은 이슈의 핵심은 "조회한 데이터를 로직에서 수정했다"는 데 있다.
1차 캐시는 동일한 객체를 리턴하기 때문에, 해당 객체를 수정하면 캐시도 같이 오염된다.

그렇기 때문에 가장 깔끔한 방법은, 조회한 데이터를 DTO 등으로 변환해서 리턴하는 것이다.

private List<User> getUserListAndModifySafely(String name) {
    List<User> users = new ArrayList<>(userMapper.getUserByName(name)); // 복사본 생성
    return users;
}

이렇게 하면 원본 엔티티나 리스트를 직접 수정하지 않고, 캐시 오염을 막을 수 있다.

사실 이 코드도 문제가 있다 만약 users 의 결과가 있고, 그 데이터를 리스트에서 가져다 수정한다면 캐시에 있는 데이터는 또 오염될 것이다!
따라서 user도 deepcopy를 해야한다

private List<User> getDeepCopiedUsers(String name) {
    return userMapper.getUserByName(name).stream()
            .map(user -> new User(user)) // 복사 생성자
            .collect(Collectors.toList());
}

최근엔 JPA로 개발을 진행하다 보니 MyBatis 쓸 일이 줄어들고 있다. 신입 친구들 중에는 MyBatis 한 번도 안 써봤다는 경우도 있어서 놀랐던 적도 있다. 내가 개발 중인 서비스는 오래된 MyBatis 기반의 코드와 새로 작성한 JPA 기반 코드가 공존하고 있는데, JPA에선 익숙했던 캐시 개념이 MyBatis에도 있다는 걸 새삼스럽게 다시 알게 된 계기였다.

실제 운영 중인 서비스에서 이런 캐시 오염 문제가 발생하면 꽤 위험할 수 있기 때문에, 조회한 데이터를 왠만하면 복사해서 리턴하는게 좋다는 교훈을 얻은 경험이었다.

JPA @Transactional 과 1차 캐시

rangrangerang — Sun, 2 Feb 2025 20:26:38 +0900

문제

JPA에서는 1차 캐시를 사용하기 때문에 같은 엔티티에 대해서는 동일성(주소값이 같음)을 만족한다고 알고 사용해왔다. 그래서 나는 객체를 비교할 때 id가 아닌 객체 그 자체로 비교해 왔다. 그런데 어느 날 id로 가지고 온 객체를 이용해 fetch join을 통해 가지고 온 객체 중 하나를 찾는 로직을 작성했는데, 하나도 못 찾는 문제가 발생했다. 확인해보니 id를 통해 가지고 온 객체와 fetch join을 통해 가지고 온 객체의 주소값이 달랐다. 결론부터 말하자면 원인은 @Transactional을 붙이지 않아 발생했다.

테스트1. @Transactional 없이 조회

아래 코드는 테스트를 위해 작성한 코드로, findByIdPerson은 personRepository에서 id를 이용해 person을 가지고 왔고, entityGraphPerson 객체는 team을 가져올 때 fetch join으로 거기에 속한 멤버도 함께 가져오도록 해서 person 객체를 조회했다.

    @Test
    public void jpaFirstCacheTransactionalTest() {
        // id 로 사람 조회
        Member findByIdMember = personRepository.findById(1L).get();

        // team과 사람 한번에 조회(패치 조인)
        Team teamWithMember = teamRepository.findWithPersonById(1L).get();
        Member entityGraphMember = teamWithMember.getMembers().get(0);

        assertEquals(findByIdMember.getId(), entityGraphMember.getId(), "id가 다릅니다");
        assertEquals(findByIdMember, entityGraphMember, "주소값이 다릅니다");
    }

데이터는 아래와 같이 들어있다

첫 번째 테스트인 id 값 비교는 성공하지만, 두 번째 테스트인 주소값 비교는 실패한다.

테스트2. @Transactional 추가 후 조회

그럼 이번에는 @Transactional을 추가해서 테스트해보자.

    @Test
    @Transactional	// 추가**
    public void jpaFirstCacheTransactionalTest() {
        // id 로 사람 조회
        Member findByIdMember = personRepository.findById(1L).get();

        // team과 사람 한번에 조회(패치 조인)
        Team teamWithMember = teamRepository.findWithPersonById(1L).get();
        Member entityGraphMember = teamWithMember.getMembers().get(0);

        assertEquals(findByIdMember.getId(), entityGraphMember.getId(), "id가 다릅니다");
        assertEquals(findByIdMember, entityGraphMember, "주소값이 다릅니다");
    }

성공이다!

JPA 1차 캐시 조건

JPA 의 1차 캐시의 조건에는 아래와 같은 내용이 있다.

1. 트랜잭션이 종료되거나, flush()될 경우 캐시는 초기화
2. 캐시에서 값을 가져오는건 PK를 기반으로한 find (entity manager를 쓸때 find() 메서드 혹은 data-jpa의 findById)에서만 동작
3. EntityManager 단위에서 1차 캐시가 관리됨

지금까지 테스트해본 문제는 1번 조건이 적용되지 않아 동일 트랜잭션이 아니었던 조회에서 1차 캐시가 공유되지 않았고, 그래서 엔티티의 동일성이 보장되지 않았던 것이다.

테스트3. id로 조회후 name으로 조회

여기서 2번의 경우 쿼리가 몇번 날라가는지 테스트를 해보자. 만약 id로 조회한 후 name로 조회하면 쿼리는 몇 번 실행될까?

    @Test
    @Transactional
    public void jpaFirstCacheOrderTest() {
        // id 로 사람 조회
        Member findByIdMember = personRepository.findById(1L).get();

        // name으로 동일한 사람 조회
        Member findByNameMember = personRepository.findByName("YR").get();

        assertEquals(findByIdMember.getId(), findByNameMember.getId(), "id가 다릅니다");
        assertEquals(findByIdMember, findByNameMember, "주소값이 다릅니다");
    }

여기서 테스트는 성공하지만 중요한건 쿼리가 2번 나간다. 어떻게 동작하는지 생각해보면 첫번째 id로 조회했을 때 1차 캐시에 아래와 같이 데이터가 저장됐을 것이다. 하지만 name으로 조회할 땐 2번 조건에 따라 1차 캐시가 아닌 db에서 다시 가지고 오기 때문에 쿼리가 한번 더 나간다.

1차 캐시
@Id	Entity
1	Member(YR)

테스트4. name으로 조회 후 id로 조회

이번에는 name으로 먼저 조회하고 id 로 조회해보자

    @Test
    @Transactional
    public void jpaFirstCacheOrderTest() {
        // name으로 동일한 사람 조회
        Member findByNameMember = personRepository.findByName("YR").get();
        
        // id 로 사람 조회
        Member findByIdMember = personRepository.findById(1L).get();
        
        assertEquals(findByIdMember.getId(), findByNameMember.getId(), "id가 다릅니다");
        assertEquals(findByIdMember, findByNameMember, "주소값이 다릅니다");
    }

이번에는 쿼리가 한번만 나갔다. 첫번째 name으로 조회했을 때 첫번째 테스트에서와 마찬가지로 1차 캐시에 아래와 같이 데이터가 저장됐을 것이다 그 이후에 pk 로 조회했을 때 1차 캐시에서 id로 1번 데이터를 찾았을 거고, 첫번째 조회에서 저장된 엔티티가 있으니 쿼리는 날라가지 않은 것이다.

1차 캐시
@Id	Entity
1	Member(YR)

이번 문제를 통해 JPA에서 @Transactional의 중요성을 다시 한번 깨달았다. 보통 나는 service 단에 @Transactional(readOnly=true) 를 붙여놓고 데이터 저장,수정,삭제 등이 필요한 메서드에만 @Transactional 를 따로 붙여주는데 이 서비스는 기존에 있던 서비스에 내용을 추가하다보니 놓친 것 같다.. 앞으로는 간단한 내용만 추가한다고 해도 서비스를 꼼꼼히 살펴보고 추가하는게 좋을 것 같다.

스레드 동기화와 volatile, synchronized 키워드

rangrangerang — Mon, 11 Nov 2024 21:38:03 +0900

우리 팀에서는 사용자의 조작에 따라 카프카의 특정 토픽을 구독하거나 구독 취소하는 기능을 구현하고 있다. 이 과정에서 topicList라는 리스트를 통해 구독할 토픽을 관리하고, 해당 리스트의 사이즈를 체크하여 구독할 대상이 있는 경우에만 로직을 실행하도록 개발했다. 그런데 topicList에 데이터가 하나도 없을 때 무한루프에 빠져 새로운 토픽이 추가되어도 무한루프를 빠져나오지 못하는 현상이 발생했다.

문제의 원인

아래는 대략적인 코드이다. 코드를 살펴보면, topicList의 사이즈가 0일 때 while문 안에서 continue가 호출되어 무한루프에 빠지는 것을 알 수 있다. 사실 이 코드는 애초에 잘못 짜여진 코드이다. 토픽이 없는 경우에도 무한루프에 빠지가 코드를 짜면 안된다. 하지만 그렇다고 하더라도 사용자가 새로운 토픽을 추가하면 이 조건을 통과해 다음 로직을 실행해야 할 것 같은데, 실제로는 그렇지 않았다.

@Log4j2
public class TestConsumer implements Runnable {

    private List<String> topicList = new ArrayList<>();

    @Override
    public void run() {
        log.info("[{}] start consumer!!", Thread.currentThread().getName());
        while (true) {
            if (topicList.size() == 0) {
                continue;
            }

            log.info("[{}] ======= topicList is not null! logic start! size:{} =======", Thread.currentThread().getName(), topicList.size());
            try {
                Thread.sleep(1000 * 10L);
            } catch (InterruptedException e) {
                throw new RuntimeException(e);
            }
        }
    }

    public void addTopic(String topic) {
        topicList.add(topic);
        log.info("[{}] add topic : {}", Thread.currentThread().getName(), topicList);
    }
}

아래의 메인 코드를 실행해보자. topic_init을 우선 추가 후 5초 이후 topic_new를 추가하는 코드이다.

public class Main {

    public static void main(String[] args) throws InterruptedException {
        TestConsumer testConsumer = new TestConsumer();
        testConsumer.addTopic("topic_init");
        Thread thread = new Thread(testConsumer, "testConsumer");
        thread.start();

        // 사용자가 topic을 추가.
        Thread.sleep(1000 * 5L);
        testConsumer.addTopic("topic_new");
    }
}

topicList 에 topic_init 이라는 토픽이 이미 존재하는 경우 실행된 로그를 확인해보면 정상적으로 이후 로직이 실행되는 것을 확인해볼 수 있다.

하지만 아래 코드처럼 토픽에 대한 초기화를 안하면

public class Main {

    public static void main(String[] args) throws InterruptedException {
        TestConsumer testConsumer = new TestConsumer();
//        testConsumer.addTopic("topic_init");
        Thread thread = new Thread(testConsumer, "testConsumer");
        thread.start();

        // 사용자가 topic을 추가.
        Thread.sleep(1000 * 5L);
        testConsumer.addTopic("topic_new");
    }
}

토픽 추가를 해도 이를 인지하지 못하고, 이후 로직이 실행되지 않는다. topicList에 topic_new 라는 토픽을 추가해줬지만 여전히 topicList 의 사이즈는 0이라고 인식하고 있는 거다.

스레드 덤프를 떠보면 더 확실히 확인할 수 있는데 토픽이 추가된 이후인데도 여전히 if(topicList.sizer() == 0) 를 빠져나가지 못하고 있는것을 확인할 수 있다.

CPU 캐시

이런 현상이 나타나는 원인을 알기 위해서는 cpu캐시에 대해 알아야 한다. JVM에서는 스레드는 실행되고 있는 CPU 메모리 영역에 데이터를 캐싱 한다. (CPU Cache) 따라서 멀티 코어 프로세서에서 다수의 스레드가 변수를 공유하더라도 캐싱 된 시점에 따라 데이터가 다를 수 있으며, 서로 다른 코어의 스레드는 데이터 값이 불일치하는 문제가 생긴다.

임의로 데이터를 갱신해 주지 않는 이상 캐싱된 데이터가 언제 갱신되는지 또한 정확히 알 수 없다.

따라서, topicList에 새로운 토픽이 추가되더라도, 추가한 스레드의 캐시와 메인 메모리는 업데이트 되지만, 기존 스레드가 가지고 있는 캐시된 데이터가 업데이트되지 않을 수 있어 무한루프에 빠지게 되는 것이다.

해결 방법 : volatile 키워드

이런 경우 volatile 키워드를 사용하여 CPU 메모리 영역에 캐싱 된 값이 아니라 항상 최신의 값을 가지도록 메인 메모리 영역에서 값을 참조하도록 할 수 있다.
-> 즉, 동일 시점에 모든 스레드가 동일한 값을 가지도록 동기화한다.

쓰레드가 변경한 값이 아직 메인 메모리에 기록되지 않았기 때문에 다른 쓰레드가 변수의 최신 값을 볼 수 없는 문제를 "가시성" 문제라고 한다.

그럼 topicList에 volatile 키워드를 추가 후 테스트해보자

@Log4j2
public class TestConsumer implements Runnable {
    // volatile 키워드 추가
    private volatile List<String> topicList = new ArrayList<>();

    @Override
    public void run() {
        log.info("[{}] start consumer!!", Thread.currentThread().getName());
        while (true) {
            if (topicList.size() == 0) {
                continue;
            }

            log.info("[{}] ======= topicList is not null! logic start! size:{} =======", Thread.currentThread().getName(), topicList.size());
            try {
                Thread.sleep(1000 * 10L);
            } catch (InterruptedException e) {
                throw new RuntimeException(e);
            }
        }
    }

    public void addTopic(String topic) {
        topicList.add(topic);
        log.info("[{}] add topic : {}", Thread.currentThread().getName(), topicList);
    }
}

성공이다 초기화를 해주지 않았지만 정상적으로 실행되는것을 확인할 수 있다.

synchronized 키워드

하지만 volatile 을 붙여주더라도 문제가 생길 여지는 있다 바로 여러 스레드에서 한번에 해당 리스트에 topic을 추가하는 경우이다. 사실 우리 서비스는 해당 영역을 개발자 혹은 담당자 한명 정도만 만지기 때문에 동시에 동일한 토픽에 대한 수정을 할 일은 극히 적지만, 만약 동시에 토픽을 수정한다고 하면 이상한 결과가 나올수도 있다

이런경우 synchronized 키워드를 사용해주면 문제는 해결된다

그럼 그냥 모든 공유 변수에 synchronized를 사용하면 되지 않을까?
-> synchronized 는 volatile 보다 성능이 좋지 않다(락을 획득해야 하기 때문)

✔ 결론 : 여러 쓰레드에서 참조하는 변수의 경우 volatile 키워드를 붙여주자.
만약 여러 쓰레드에서 해당 값을 수정한다면 synchronized 키워드를 붙여주자.

참고
https://rachel0115.tistory.com/entry/Java-%EB%A9%80%ED%8B%B0-%EC%8A%A4%EB%A0%88%EB%93%9C-%ED%99%98%EA%B2%BD%EC%97%90%EC%84%9C-%EB%B0%9C%EC%83%9D%ED%95%A0-%EC%88%98-%EC%9E%88%EB%8A%94-%EB%8F%99%EC%8B%9C%EC%84%B1-%EC%9D%B4%EC%8A%88%EC%99%80-%ED%95%B4%EA%B2%B0-%EB%B0%A9%EB%B2%95

https://programmer-chocho.tistory.com/82

GitHub pull request 발생 시 Mattermost 에 메세지 전송하기(AWS lambda, api gateway)

rangrangerang — Thu, 20 Jun 2024 23:30:13 +0900

전체적인 로직

깃허브에서 pull request 를 만들면 api gateway로 요청을 보낸다 api gateway 는 lambda의 함수를 호출하고 lambda 의 함수 로직에서 mattermost를에 메세지를 전송한다

api gateway : API 만들어주는 친구. 외부 클라이언트로부터 요청을 받아 람다 함수로 연결해줌
lambda : 서버리스 컴퓨팅 플랫폼(메서드만 작성해서 실행시킬 수 있음)

1. Mattermost에 webhook 추가하기

먼저 mattermost에 외부 메세지를 받을 수 있도록 webhook을 추가해 준다

좌상단 > 통합
전체 Incoming Webhook
Incoming Webhook 추가하기
내용 입력
생성된 URL → 람다에서 메세지 전송할 URL 로 사용

2. aws lambda 함수 만들기

2-1. 함수 생성

aws lambda > 함수 생성
언어는 python 3.11 사용
- 자바의 경우 코드 수정 시 로컬에서 빌드 후 jar 업로드 필요
- 파이썬의 경우 aws 웹에서 바로 수정&배포&테스트가 가능함

2-2. 코드 > 코드 작성

github json을 받아 원하는 데이터 추출
해당 데이터를 Mattermost에 보낼 형식에 맞게 변환
1에서 생성한 Mattermost url로 전송
Mattermost 전송 형식 참고 : https://developers.mattermost.com/integrate/reference/message-attachments/

import requests
import json

def lambda_handler(event, context):
    try:
        # Slack 메시지 전송
        send_slack_message(event)
        
        return {
            'statusCode': 200,
            'body': json.dumps('send message mm')
        }
    except Exception as e:
        return {
            'statusCode': 500,
            'body': json.dumps(f'error : {str(e)}')
        }
    
    
def send_slack_message(event):
    # mm url : 메터모스트 webhook url
    url = 'https://~~~~~'
    
    # github json 에서 필요 데이터 추출
    title = event["pull_request"]["title"]
    pr_url = event["pull_request"]["html_url"]
    user_id = event["pull_request"]["user"]["login"]
    branch = event["pull_request"]["head"]["ref"]
    task_url = f'https://app.clickup.com/t/25540965/{branch}'
    
    
    # 메세지 형식 지정
    text = f'Task: {title}\nMR: {pr_url}\nTASK: {task_url}\nUSER: {user_id}\n'
    message = {
        # "text": title,
        "attachments": [
            {
                # "pretext": "test",
                "text":text
            }
        ]
    }
    
    # mm 에 메세지 전송
    headers = {'Content-Type': 'text/plain'}
    payload = {"text" : message}
    response = requests.post(url, headers=headers, data=json.dumps(message))
    
    # 응답 확인
    print('Response:', response.status_code)
    print(response.text)

2-3. requests 계층 추가

파이썬 라이브러리를 사용하는 경우 직접 람다에 추가해줘야 함
라이브러리 파일 준비 & 세팅 : https://ottl-seo.tistory.com/181

2-4. 배포

Deploy 버튼 클릭

2-5. (참고) 테스트

람다에서는 테스트 코드를 생성해 간단하게 테스트가 가능하다
Test > Configure test event
이벤트 JSON에 github 결과 예시 추가 및 저장
더보기
테스트 데이터 가지고 오는 법

기존의 webhook 데이터를 긁어오거나 람다에서 event를 print 해서 사용해도 됨

아래 내용은 기존 webhook 데이터 긁어오는 방법
1. github의 Settings > Webhooks > 이미 만들어져 있던 webhook 클릭
2. Content type 이 application/json 인 webhook 선택 필요
3. 우리가 원하는 pull request 관련 데이터의 Payload 복사

3. Api Gateway API 생성

3-1. API 생성(API base url을 만드는 작업)

aws api gateway > API 생성
REST API > 구축
API 이름 작성 후 API 생성

3-2. 리소스 생성(API 상세 url을 만드는 작업)

리소스 이름 작성 후 리소스 생성

3-3. 메서드 생성(GET, POST 등을 결정)

메서드 생성

메서드 세부 정보 작성
- 메서드 유형 : POST(github에서 POST 로 전송해줌)
- 통합 유형 : Lambda 함수
- Lambda 함수 : 2에서 생성한 lambda 함수 선택
메서드 생성 버튼 클릭

3-4. 외부에서 접근 가능하도록 API 배포

API 배포
스테이지 : prod(보통은 개발은 dev, 운영은 prod를 사용함 여기서는 운영 개발 상관없기 때문에 그냥 prod로 함)
URL 호출 : pull reqeust 발생 시 github 에서 호출하는 api

(참고) 로그 확인 방법

모니터링 탭
하단 CloudWatch Logs > Recentinvocations
예시

4. github Webhooks 추가

Settings > Webhooks > Add webhook
API Gateway에서 생성한 api url을 입력 & Content type : application/json 선택
Which events would you like to trigger this webhook?
→ Let me select individual events. 선택
- 하위 내용에서 Pull Requests 선택(pull request 관련 작업이 있을 때만 알람을 전송)
하단 Add webhook 클릭
정상적으로 생성 시 아래와 같이 pull_request 만 대상임을 알 수 있음
실제로 전송한 데이터와 결과를 Recent Deliveries에서 확인 가능

결과

상태가 open 인 경우 초록, closed 인 경우 보라

참고

https://velog.io/@parksangwon0610/Slack-Github-Webhook을-이용한-슬랙-PR-자동-Mention#api-gateway-를-사용하여-람다-호출

[Spring Boot] Multiple Datasource with Clickhouse

rangrangerang — Mon, 17 Jun 2024 00:03:05 +0900

최근에 DL(Data Lake) 데이터 저장소를 Logpresso에서 ClickHouse(+Nifi)로 전환하는 작업을 진행했다. 이에 따라 API 서버(Spring Boot)에서도 Logpresso에서 가지고 오던 데이터를 ClickHouse에서 가져오도록 전환을 진행했다. 이를 위해 하나의 프로젝트에 다중 데이터소스(pg, ClickHouse)를 연결해야 했다. 이 글은 그 내용을 다룬다.

1. build.gradle 에 clickhouse jdbc 추가

ClickHouse JDBC를 사용하기 위해 build.gradle에 의존성을 추가해준다.

2. yml 에 clickhouse 접속 정보 추가

application.yml 파일에 ClickHouse 접속 정보를 추가해준다.

datasource 위의 postgres depth 추가
clickhouse 접속 정보 추가

3. Configuration 파일 작성

두 개의 데이터베이스를 연결하기 위한 설정 파일을 작성해준다. 데이터베이스가 하나일 때는 Spring Boot에서 자동으로 설정해주지만, 두 개 이상일 때부터는 수동 설정이 필요하다.

3-1. Postgres Configuration

먼저 기존에 사용하던 Postgres의 설정부터 해보자.

우리는 디폴트로 Postgres를 사용하기 때문에 @Primary 어노테이션을 붙여줬다.
Postgres는 MyBatis와 JPA를 같이 사용하고 있기 때문에 두 설정을 모두 해줘야 한다.

1. 클래스 어노테이션 설정

@EnableJpaRepositories: JPA 리포지토리를 스캔하고 Spring 컨텍스트에 등록
- basePackages: JPA 리포지토리 인터페이스가 위치한 패키지를 지정
- entityManagerFactoryRef: 사용할 EntityManagerFactory의 빈 이름을 지정
- transactionManagerRef: 사용할 TransactionManager의 빈 이름을 지정
@MapperScan: MyBatis 매퍼 인터페이스를 스캔하고 Spring 컨텍스트에 등록
- sqlSessionFactoryRef: 사용할 SqlSessionFactory의 빈 이름을 지정
- basePackages: MyBatis 매퍼 인터페이스가 위치한 패키지를 지정

@Configuration
@EnableJpaAuditing
@EnableJpaRepositories( // jpa
        // repository 위치
        basePackages = {"repository 위치", "여러개를", "적을수도", "있음"},
        entityManagerFactoryRef = "pgEntityManagerFactory",	// entityManagerFactory의 이름
        transactionManagerRef = "pgTransactionManager"		// transactionManager의 이름
)
@MapperScan(    // mybatis
        sqlSessionFactoryRef = "sqlSessionFactory",
        // mapper 클래스 위치
        basePackages = {"mapper 클래스 위치", "여러개를", "적을수도", "있음"}   
)
public class PostgresDataSourceConfiguration {

2. 데이터 소스 설정

dataSourceProperties(): DataSourceProperties 빈을 생성
- spring.postgres.datasource로 시작하는 설정을 사용
dataSource(): HikariDataSource 빈을 생성
- spring.postgres.datasource.hikari로 시작하는 설정을 사용

    @Primary
    @Bean
    @ConfigurationProperties("spring.postgres.datasource")
    public DataSourceProperties dataSourceProperties() {    // datasource 관련 설정
        return new DataSourceProperties();
    }

    @Primary
    @Bean
    @ConfigurationProperties("spring.postgres.datasource.hikari")
    public HikariDataSource dataSource(DataSourceProperties properties) {   // hikari 커넥션 풀 관련 설정
        return properties.initializeDataSourceBuilder().type(HikariDataSource.class).build();
    }

3. JPA 설정

pgEntityManagerFactory(): JPA 엔티티 매니저 팩토리 빈을 생성
- packages: JPA 엔티티 클래스가 위치한 패키지를 지정
pgTransactionManager(): JPA 트랜잭션 매니저 빈을 생성

    @Primary
    @Bean(name = "pgEntityManagerFactory")
    public LocalContainerEntityManagerFactoryBean pgEntityManagerFactory(EntityManagerFactoryBuilder builder,
                                                                         DataSource dataSource,
                                                                         HibernateProperties hibernateProperties,
                                                                         ConfigurableListableBeanFactory beanFactory) {
        LocalContainerEntityManagerFactoryBean entityManagerFactoryBean = builder
                .dataSource(dataSource)
                .packages("entity 위치" // entity 위치
                        , "여러개"
                        , "작성"
                        , "가능")
                .properties(hibernateProperties.determineHibernateProperties(
                        new HashMap<>(),
                        new HibernateSettings()))
                .build();
        entityManagerFactoryBean.getJpaPropertyMap().put(AvailableSettings.BEAN_CONTAINER, new SpringBeanContainer(beanFactory));
        return entityManagerFactoryBean;
    }

    @Primary
    @Bean(name = "pgTransactionManager")
    public PlatformTransactionManager pgTransactionManager(EntityManagerFactory pgEntityManagerFactory) {
        return new JpaTransactionManager(pgEntityManagerFactory);
    }

4. MyBatis 설정

sqlSessionFactory(): MyBatis SQL 세션 팩토리 빈을 생성
- setMapperLocations: MyBatis 매퍼 XML 파일의 위치를 지정
sqlSessionTemplate(): MyBatis SQL 세션 템플릿 빈을 생성

    @Primary
    @Bean
    public SqlSessionFactory sqlSessionFactory(DataSource dataSource, ApplicationContext applicationContext) throws Exception {
        SqlSessionFactoryBean bean = new SqlSessionFactoryBean();
        bean.setMapperLocations(applicationContext.getResources("classpath:mybatis/postgres/**/*.xml"));	// xml 위치
        bean.setDataSource(dataSource);
        return bean.getObject();
    }

    @Primary
    @Bean
    public SqlSessionTemplate sqlSessionTemplate(SqlSessionFactory sqlSessionFactory) {
        return new SqlSessionTemplate(sqlSessionFactory);

    }

전체 코드는 아래와 같다

@Configuration
@EnableJpaAuditing
@EnableJpaRepositories( // jpa
        // repository 위치
        basePackages = {"repository 위치", "여러개를", "적을수도", "있음"},
        entityManagerFactoryRef = "pgEntityManagerFactory",	// entityManagerFactory의 이름
        transactionManagerRef = "pgTransactionManager"		// transactionManager의 이름
)
@MapperScan(    // mybatis
        sqlSessionFactoryRef = "sqlSessionFactory",
        // mapper 클래스 위치
        basePackages = {"mapper 클래스 위치", "여러개를", "적을수도", "있음"}   
)
public class PostgresDataSourceConfiguration {

    @Primary
    @Bean
    @ConfigurationProperties("spring.postgres.datasource")
    public DataSourceProperties dataSourceProperties() {    // datasource 관련 설정
        return new DataSourceProperties();
    }

    @Primary
    @Bean
    @ConfigurationProperties("spring.postgres.datasource.hikari")
    public HikariDataSource dataSource(DataSourceProperties properties) {   // hikari 커넥션 풀 관련 설정
        return properties.initializeDataSourceBuilder().type(HikariDataSource.class).build();
    }


    /////////////////////// jpa ///////////////////////
    @Primary
    @Bean(name = "pgEntityManagerFactory")
    public LocalContainerEntityManagerFactoryBean pgEntityManagerFactory(EntityManagerFactoryBuilder builder,
                                                                         DataSource dataSource,
                                                                         HibernateProperties hibernateProperties,
                                                                         ConfigurableListableBeanFactory beanFactory) {
        LocalContainerEntityManagerFactoryBean entityManagerFactoryBean = builder
                .dataSource(dataSource)
                .packages("entity 위치" // entity 위치
                        , "여러개"
                        , "작성"
                        , "가능")
                .properties(hibernateProperties.determineHibernateProperties(
                        new HashMap<>(),
                        new HibernateSettings()))
                .build();
        entityManagerFactoryBean.getJpaPropertyMap().put(AvailableSettings.BEAN_CONTAINER, new SpringBeanContainer(beanFactory));
        return entityManagerFactoryBean;
    }

    @Primary
    @Bean(name = "pgTransactionManager")
    public PlatformTransactionManager pgTransactionManager(EntityManagerFactory pgEntityManagerFactory) {
        return new JpaTransactionManager(pgEntityManagerFactory);
    }

    /////////////////////// mybatis ///////////////////////
    @Primary
    @Bean
    public SqlSessionFactory sqlSessionFactory(DataSource dataSource, ApplicationContext applicationContext) throws Exception {
        SqlSessionFactoryBean bean = new SqlSessionFactoryBean();
        bean.setMapperLocations(applicationContext.getResources("classpath:mybatis/postgres/**/*.xml"));	// xml 위치
        bean.setDataSource(dataSource);
        return bean.getObject();
    }

    @Primary
    @Bean
    public SqlSessionTemplate sqlSessionTemplate(SqlSessionFactory sqlSessionFactory) {
        return new SqlSessionTemplate(sqlSessionFactory);

    }

}

위 설정을 완료하고 기존 기능들이 잘 동작하는지 확인해보자.

3-2. Clickhouse Configuration

Postgres 수동 설정이 정상적으로 끝났다면 이제 ClickHouse 설정을 해보자. ClickHouse에서는 JPA를 사용하지 않기 때문에 MyBatis에 대한 설정만 해주면 된다.

대부분의 설정이 Postgres 설정과 같고, 자바 클래스에서는 카멜케이스를 사용하고 있어 아래 설정을 추가해줬다.
configuration.setMapUnderscoreToCamelCase(true) : 데이터베이스의 언더스코어(_)가 포함된 컬럼명을 자바의 카멜 케이스(camelCase) 필드명으로 자동 변환하도록 설정.

@Configuration
@MapperScan(
        sqlSessionFactoryRef = "chSqlSessionFactory",
        basePackages = {"com.company.mapper.clickhouse"}   // mapper 클래스 위치
)
public class ClickhouseDataSource {

    @Bean(name = "chDataSourceProperties")
    @ConfigurationProperties("spring.clickhouse.datasource")
    public DataSourceProperties chDataSourceProperties() {    // datasource 관련 설정
        return new DataSourceProperties();
    }

    @Bean(name = "chDataSource")
    @ConfigurationProperties("spring.clickhouse.datasource.hikari")
    public HikariDataSource chDataSource(@Qualifier("chDataSourceProperties") DataSourceProperties properties) {   // hikari 커넥션 풀 관련 설정
        return properties.initializeDataSourceBuilder().type(HikariDataSource.class).build();
    }

    /////////////////////// mybatis ///////////////////////
    @Bean(name = "chSqlSessionFactory")
    public SqlSessionFactory sessionFactory(@Qualifier("chDataSource") DataSource datasource, ApplicationContext applicationContext) throws Exception {
        SqlSessionFactoryBean bean = new SqlSessionFactoryBean();
        bean.setMapperLocations(applicationContext.getResources("classpath:mybatis/clickhouse/**/*.xml"));  // xml 위치 설정
        bean.setDataSource(datasource);

        // MyBatis Configuration 생성
        org.apache.ibatis.session.Configuration configuration = new org.apache.ibatis.session.Configuration();
        configuration.setMapUnderscoreToCamelCase(true); // underscore를 camelCase로 변환 설정
        bean.setConfiguration(configuration); // 설정 적용

        return bean.getObject();
    }

    @Bean(name = "chSessionTemplate")
    public SqlSessionTemplate secondSqlSessionTemplate(@Qualifier("chSqlSessionFactory") SqlSessionFactory chSqlSessionFactory) {
        return new SqlSessionTemplate(chSqlSessionFactory);
    }

}

4. clickhouse 쿼리 실행

여기까지 설정이 끝났다면 거의 다 끝이다! 이제 쿼리를 직접 날려보자. 사용 방법은 기존 MyBatis 사용 방법과 동일하고, 인터페이스와 XML의 위치만 Configuration에서 설정해준 위치로 맞춰주면 된다.

아래는 쿼리 예시이다

설정하면서 잘 안됐던 부분

문제 1. clickhouse mybatis mapper 를 못찾는 문제

→ 잘못된 설정(Postgres)을 연결하고 있었다. ClickHouse 설정의 경우 아래와 같이 @Qualifier 키워드로 명시적으로 어떤 빈을 주입받을지 설정해줬다.

문제2. yml 에 설정한 커넥션 풀 개수가 적용되지 않음

기존에는 URL 관련 설정만 있는 dataSourceProperties()만 정의했었다. 쿼리의 실행은 정상적으로 됐는데 문제는 yml에 설정한 커넥션 풀 개수가 제대로 적용되지 않았다.

확인해보니 dataSourceProperties() 설정은 spring.postgres.datasource에 있는 설정만 가지고 와서 그 하위에 있는 spring.postgres.datasource.hikari 설정은 불러오지 못한 것이었다. 그래서 데이터소스 설정을 먼저 한 후 그 설정을 받아 추가로 Hikari에 대한 설정을 해주는 방식으로 해결했다.

// as-is
//    @Primary
//    @Bean
//    @ConfigurationProperties(prefix = "spring.postgres.datasource") 	// application.properties에서 사용한 이름
//    public DataSource dataSource() {
//        return DataSourceBuilder.create().build();
//    }

// to-be
    @Bean
    @Primary
    @ConfigurationProperties("spring.postgres.datasource")
    public DataSourceProperties dataSourceProperties() {
        return new DataSourceProperties();
    }

    @Primary
    @Bean
    @ConfigurationProperties("spring.postgres.datasource.hikari")
    public HikariDataSource dataSource(DataSourceProperties properties) {
        return properties.initializeDataSourceBuilder().type(HikariDataSource.class).build();
    }

사실 이전에 멀티 데이터소스 설정 내용을 포스팅한 적이 있는데, 그때는 스프링을 해본 지 한 달도 안 된 때여서 깊이 이해하지 못했던 것 같다. 이번 기회에 다시 설정해보면서 조금 더 이해할 수 있었다. 3년 전과 지금을 비교해보면 당시에는 MyBatis의 비중이 컸지만, 이제는 대부분의 쿼리를 JPA로 전환 완료했다. 또한, JPA 엔티티의 위치도 중구난방이었는데 하나의 패키지로 정리했고, 멀티 프로젝트를 도입하는 등 그때보다 우리 프로젝트가 많이 성장한 것 같아 뿌듯하다.

https://rangerang.tistory.com/70

[spring boot] mybatis + jpa multi datasource 설정하기

스프링 부트 프로젝트를 개발하며 2개의 데이터베이스를 연결해야하는 이슈가 생겼다. 기존 프로젝트는 mybatis와 jpa를 섞어서 사용하는 구조이고, multi datasource를 설정하기 위해서는 수동설정이

rangerang.tistory.com

참고

https://clickhouse.com/docs/en/integrations/java
https://jsijsi99.tistory.com/9
https://velog.io/@ghkvud2/Multiple-DataSource-적용하기
https://velog.io/@dongvelop/Spring-Boot-Hikari-CP-커스텀으로-성능-최적화하기
https://github.com/ClickHouse/clickhouse-java
https://github.com/lewis-ing/clickhouse-native/tree/master/src
https://clickhouse.com/docs/en/interfaces/jdbc

nexus3 파일 보관 주기 설정

rangrangerang — Sun, 16 Jun 2024 00:00:12 +0900

우리 팀에서는 브랜치에 push 될 때 마다 jar를 넥서스에 올려놓는 형식으로 사용중이다

넥서스를 설치한 이후 보관주기를 설정한적이 없어 서버용량의 99% 를 사용중이었고 nexus 의 기능을 이용해 cleanup 설정을 걸어줬다

1. Cleanup Policies 설정

정리 정책 설정

Nexus Repository Manager에 로그인한다
Administration > Repository > Cleanup Policies로 이동한다

기본적인 정보들을 적어준다

Cleanup Criteria 설정:

Component Age: 게시일로부터 설정한 날짜가 지났을 경우
Component Usage: 설정한 날짜 동안 다운로드되지 않았을 경우
Asset Name Matcher: 삭제할 대상 이름의 정규식 설정

조건을 설정한 후 레포지토리를 선택하고 Preview를 클릭하여 삭제 대상 파일을 확인한다
대상이 맞다면 Save를 눌러 저장한다

2. 정책을 레포지토리에 적용

Repositories 에 들어가 원하는 레포지토리를 선택해준다

가장 하단에서 Cleanup Policies를 선택하여 원하는 정책을 설정하고 저장한다

여기까지 설정하면 내부에서 자동으로 스케쥴링이 돌면서 대상들을 정리한다

3. Cleanup Policies 수동 실행

서버의 용량이 99%인 상황에서는 설정한 정책이 실행되길 기다릴수가 없었다 바로 실행하는 방법을 알아보자
System > Tasks 에 들어가 Cleanup Service 를 선택해준다

다음 실행 일정, 마지막 실행 일자 등의 정보가 나온다

상단의 Run 버튼을 눌러 바로 실행한다

그럼 우상단에 팝업이 뜨면서 실행됐음을 알린다

실제로 실행된 로그는 Support > _Logs 에서 확인할 수 있다

어떤 파일이 지워졌는지 등의 로그를 확인할 수 있다

여기까지 하고 넥서스의 폴더에서 파일들이 삭제되는것을 확인했는데 서버의 용량을 확인해봤는데 전혀 줄어들지 않았다

그래서 찾아봤더니 공식 문서에 아래와 같은 내용이 있다

You can create cleanup policies and assign them to one or more repositories so that a scheduled cleanup task (Admin - Cleanup repositories using their associated policies) will automatically soft delete artifacts from the repository. A soft delete means that artifacts are only marked for removal and not yet deleted from the disk. Disk space is not reclaimed until the Admin - Compact blob store task runs.

이 내용을 보면 cleanup policies 는 단지 어떤 파일이 삭제될 지 표시만하고(soft delete) 실제로는 Compact blob store task 가 실행될 때 지워진다고 설명하고 있다

4. Compact Blob Store Task 실행

그렇다면 Compact blob store 하는 방법을 알아보자

Tasks > Create Task 로 태스크를 생성해주자(사진에는 이미 생성된 태스크가 있는데 무시하자..)

compact 라고 검색하면 Admin-Compact blob store 태스크가 검색된다
이 친구를 클릭해주자

아래 내용을 채워주고 Create task 해주자!

Task name: 태스크 이름
Notification email: 실패 또는 성공/실패 시 메일을 보낼 이메일
Send Notification on: 메일을 실패 시 보낼지 성공/실패 시 보낼지 선택
Blob Store: 정리할 레포지토리 설정
Task Frequency: 태스크 실행 주기 설정 (매일, 매주, 매달 등)

그럼 태스크가 생성되고 Run을 클릭해 실행시킨다

실행 로그는 cleanup 과 마찬가지로 logs 에서 확인할 수 있다

서버를 확인해보면 /data 의 용량이 99% -> 64% 로 줄어든 것을 확인할 수 있다

참고

https://help.sonatype.com/en/cleanup-policies.html

Cleanup Policies

NoteImportant Impact for Those Migrating to H2 or PostgreSQLIn OrientDB environments, the Asset Name Matcher uses Lucene regular expressions; in H2 or PostgreSQL environments, it uses Java regular expressions. The major difference is that the Lucene regula

help.sonatype.com

CentOS7에 Jeus8 설치 및 실행

rangrangerang — Mon, 12 Feb 2024 01:07:50 +0900

✔ 목표 : centOS7에 제우스8 설치하고 띄워보자

0. 설치 파일 다운로드 - 아래 링크에서 진행

https://technet.tmax.co.kr/ko/front/download/findDownloadList.do

TmaxSoft Technical Network [technet-01]

데모라이선스 신청 데모라이선스는 제품구입 전 테스트 및 검토를 위하여 제한 된 기간 동안 발급받아 사용가능한 라이선스 입니다.

technet.tmax.co.kr

다운로드 된 제우스 설치파일

1. jeus8500_unix_generic_ko.bin 파일이 위치한 디렉터리로 이동 후 설치 파일을 실행

./jeus8500_unix_generic_ko.bin

1)소개

-> ENTER

2) 라이센스

-> ENTER

라이센스 이어서

-> ENTER

3) 플랫폼 선택

-> (우리는 리눅스 64비트를 사용하므로) 9 혹은 그냥 ENTER

4) 설치 폴더

-> 설치하고 싶은 위치를 적어준다 디폴트 설치위치가 마음에 들면 그냥 ENTER

5) JDK 위치 설정

→ 디폴트 설정이 맞게 되어 있으므로 ENTER

6) 설치 타입

-> ENTER

7) 설치 모드

-> ENTER

8) 제우스 도메인 이름

-> ENTER ( 디폴트 값인 jeus_domain 사용)

9) DAS 서버 이름

-> ENTER(디폴트 값인 adminServer 사용)

10) 포트

-> ENTER(디폴트 값인 9736 사용)

11) admin 유저명

-> ENTER(디폴트 값인 administrator 사용)

12) 패스워드 설정

-> 원하는 패스워드 작성 후 엔터

13) 노드 매니저 설정

-> ENTER(디폴트 값으로 설정)

14) 샘플 디렉토리

-> ENTER(샘플디렉토리 만듦 사실 별로 필요는 없는데 나중에 필요없으면 지우면 됨)

15) 설치 요약

-> 확인 후 ENTER

16) 설치 완료

-> ENTER

17) 쉘에서 bash_profile 수정

vi ~/.bash_profile

제우스 8_5의 홈이 안잡혀있으면 잡아주고, 두번째 체크된 내용이 잘 들어가 있는지 확인한다(정상적으로 깔렸다면 자동으로 들어가있음)

18) bash_profile 수정 후 적용

source ~/.bash_profile

확인

echo $JEUS_HOME
>>> /home/p/jeus8_5

제우스 설치 완료!

3. 제우스 8.5 실행

DAS(Domain Admin Server)

-> Jeus Webadmin에 접속하기 위한 관리자용 서버 ( 이 서버는 죽더라도 MS만 멀쩡하면 서비스에는 지장이 없다)

Domain Admin Server(DAS)를 시작한다.

startDomainAdminServer -u administrator -p {비밀번호}

확인

> http://{서버ip}:9736/webadmin/login

NM(NodeManager)

-> DAS 가 MS 를 관리하기 위해 사용하는 프로세스

NM을 시작한다

nohup startNodeManager &

확인 http://{서버ip}/webadmin/login 에 접속 후 Node 설정 클릭

Under Control 이 Y 면 정상

참고1) 제우스 주요 명령어

### das
# start
startDomainAdminServer -domain jeus_domain -u administrator -p {비밀번호}
# stop
stopServer -host 127.0.0.1:9736 -u administrator -p {비밀번호}

### nm
# start
nohup startNodeManager &
# stop
stopNodeManager -host 127.0.0.1 -port 7730

### ms
# start
startManagedServer -dasurl 127.0.0.1:9736 -domain jeus_domain -server server4  -u administrator -p {비밀번호}
# stop 포트는 http 포트
stopServer -host 127.0.0.1:9748 -u administrator -p {비밀번호}

참고2) 주요 제우스 로그 위치

nodeManager 로그

$JEUS_HOME/nodemanager/logs/JeusNodeManager.log

서버 로그 → 위치 조금 다를수도..?

$JEUS_HOME/domains/jeus_domain/servers/{서버이름}/logs/JeusServer.log

war 위치 → 조금씩 다를수도..

$JEUS_HOME/domains/jeus_domain/.applications/{어플리케이션이름}

ThreadPoolExecutor RejectedExecutionException 오류 - SynchronousQueue

rangrangerang — Tue, 11 Jul 2023 09:24:21 +0900

우리 프로젝트에서는 여러개의 쓰레드를 이용하여 작업을 실행하기 위해 ThreadPoolExecutor를 이용하고 있다 쓰레드 풀의 개수는 고정적으로 사용하고 있으며, 해당 쓰레드를 실행하는 부분에서 쓰레드의 개수를 관리하며 쓰레드 풀 이상의 요청은 하지 않기 때문에 이론적으로는 쓰레드 풀이 터지는 경우는 없어야 했다. 하지만 여러 프로젝트를 진행하며 종종 쓰레드 풀이 터지곤 했는데 이번에 조금 더 깊이 파봤다

발생한 오류 는 아래와 같다

RejectedExecutionException: Task cohttp://m.xxx.xx.TrainWorker rejected from java.util.concurrent.ThreadPoolExecutor[Running, pool size = 16, active threads = 2, queued tasks = 1, completed tasks = 167]

오류가 발생한 스레드 풀을 만드는 코드는 아래와 같다 우리는 corePoolSize와 maximumPoolSize를 같은 값으로 사용하고 있다
-> 풀 사이즈는 고정이다(생성되거나 줄어들지 않는다)

    workerExecutor = new ThreadPoolExecutor(poolSize, poolSize, 10, TimeUnit.MINUTES, new LinkedBlockingQueue<>(1));
    workerExecutor.setRejectedExecutionHandler(new ThreadPoolExecutor.AbortPolicy());   // 작업큐가 꽉 찼을 때 Reject된 task가 RejectedExecutionException을 던짐

ThreadPool을 생성하는 코드를 파악해보자

>> workerExecutor = new ThreadPoolExecutor(poolSize, poolSize, 10, TimeUnit.MINUTES, new LinkedBlockingQueue<>(1));

인수의 의미를 모른다면 밑에 더보기를 클릭하자

인수의 의미(순서대로)

corePoolSize – 유휴 상태인 경우에도 풀에 유지할 스레드 수입니다.
maximumPoolSize – 풀에서 허용할 최대 스레드 수입니다.
keepAliveTime – 스레드 수가 코어보다 많은 경우 유휴 스레드가 새 작업을 기다리는 최대 시간입니다.
unit– keepAliveTime 인수 의 시간 단위 .
workQueue– Runnable 작업이 실행되기 전에 보관하는 데 사용할 대기열 .

인수의 의미만 봤을 때는 pool이 차는 순서가 아래와 같을꺼라고 오해하기 쉽다.

corePoolSize -> maximumPoolSize -> workQueue

하지만 실제로는 아래와 같이 workQueue를 먼저 채운다.

corePoolSize -> workQueue -> maximumPoolSize

공식 문서 참고

이전에도 동일한 오류가 터졌었는데 이 코드를 디버깅하면서 acative threds 가 아직 꽉 차지 않았는데 queued tasks가 채워졌다는게 의문이었다 오류의 원인은 execute를 동시에 해서 그런가보다! 하고 execute 하는 메서드에 synchronized를 걸었다.
-> 잘못된 선택..

ThreadPoolExecutor.execute() 함수 분석

아래 함수는 threaPoolExecuter의 execute 함수이다. 대충 확인해보면 새로운 command가 들어왔을 때 아래와 같은 로직으로 진행된다.

1. worker의 개수가 corePoolSize 보다 작으면 thread를 그냥 추가한다.

2. 아니라면 워커큐에 저장하려고 command를 저장하려고 시도한다
-> 우리 코드의 경우 워커큐 사이즈 이상의 요청은 하지 않는다 따라서 이 코드는 무조건 성공해야 한다

3. 만약 2의 작업이 실패하면 최대 Thread 수 보다 작을 때 Thread를 추가
-> 이 코드는 타는일이 없어야 한다

 public void execute(Runnable command) {
        if (command == null)
            throw new NullPointerException();
            /*
         * Proceed in 3 steps:
         *
         * 1. If fewer than corePoolSize threads are running, try to
         * start a new thread with the given command as its first
         * task.  The call to addWorker atomically checks runState and
         * workerCount, and so prevents false alarms that would add
         * threads when it shouldn't, by returning false.
         *
         * 2. If a task can be successfully queued, then we still need
         * to double-check whether we should have added a thread
         * (because existing ones died since last checking) or that
         * the pool shut down since entry into this method. So we
         * recheck state and if necessary roll back the enqueuing if
         * stopped, or start a new thread if there are none.
         *
         * 3. If we cannot queue task, then we try to add a new
         * thread.  If it fails, we know we are shut down or saturated
         * and so reject the task.
         */
            
        int c = ctl.get();
        if (workerCountOf(c) < corePoolSize) {	//최저 Thread 수 보다 작다면 Thread 추가 -> pass
            if (addWorker(command, true))
                return;
            c = ctl.get();
        }
        if (isRunning(c) && workQueue.offer(command)) {	//Queue 에 저장(offer)하려고 시도 -> 여기서 실패하고 아래로 넘어감 왜? 
            int recheck = ctl.get();
            if (! isRunning(recheck) && remove(command))
                reject(command);
            else if (workerCountOf(recheck) == 0)
                addWorker(null, false);
        }
        //위의 offer가  false를 리턴해야만, 최대 Thread 수 보다 작을때 Thread 추가한다. 
        // ***-> 우리는 core의 개수와 max의 개수가 동일하기 때문에 쓰레드 추가하려면 무조건 터짐!! 여기로 넘어오면 안됨
        else if (!addWorker(command, false))
            reject(command);
    }

1) if (isRunning(c) && workQueue.offer(command)) { //Queue 에 저장(offer)하려고 시도한다.
-> 여기서 실패하고 아래로 넘어간다 왜?

위 코드가 문제같음 이 코드에서 넘어가면 안됨 우리는 corePoolSize 이상의 요청은 하지 않기 때문에 workerQueue(대기열)는 항상 비어있어야하지 않나?

디버깅 해보니 위 코드에서는 workerQueue의 개수가 1인데 다음로직인 아래 코드로 내려가니 workerQueue가 0이다

2) else if (!addWorker(command, false)) //위의 offer가 false를 리턴해야만, 최대 Thread 수 보다 작을때 Thread 추가한다.
-> 우리는 corePoolSize = maximumPoolSize = poolSize로 같기 때문에 queue를 사용하게 되면 maximumPoolSize를 초과하기 때문에 무조건 터진다!! 여기로 넘어오면 안됨

-> workerQueue가 1일 때 또 넣으려고 하니까 터지나보다!?

그래서 예상 시나리오를 아래처럼 생각했다

1. 1) 코드 실행할 때는workerQueue에 1개 있음(곧 쓰레드에서 가져갈 것)
2. workerQueue에서 빠짐
3. 2) 코드 실행 중 터짐(지금은 workerQueue가 비어있음)
-> 사실 여기까지 내려오면 안됨

해결 방법 : SynchronousQueue 전략

1. LinkedBlockingQueue(우리가 사용하던 전략)

LinkedBlockingQueue(1) : 1개의 큐를 두고 사용

2. SynchronousQueue

task를 큐에 들고있지 않고, 바로 스레드로 넘겨버린다
-> 대기하는 쓰레드와 매칭만 사켜줌. 내부적으로 저장하는 공간이 없음
=> 우리가 원하는 전략

✔ 우리는 사실 SynchronousQueue 를 써야 했던 상황이었다!

따라서 코드를 아래와 같이 바꿨고, 한달에도 여러번 터지던 쓰레드풀은 더 이상 터지지 않는다

    workerExecutor = new ThreadPoolExecutor(poolSize, poolSize, 10, TimeUnit.MINUTES, new SynchronousQueue<>());
    workerExecutor.setRejectedExecutionHandler(new ThreadPoolExecutor.AbortPolicy());   // 작업큐가 꽉 찼을 때 Reject된 task가 RejectedExecutionException을 던짐