현재 실무에서 많이 느낀건 서비스의 특수성이라는 영향도 있지만 응답속도가 너무 느렸다.

분명히 Redis의 Cache를 사용하고 있는데 왜 이렇게 느릴까라는 생각을 했고 그 이유를 조금이라도 더 알아 보고 다양한 Cache 중 대표적인 Caffeine과 Redis그리고 캐시를 사용하지 않는 환경까지 3개를 비교해 어느 상황에 사용하면 좋을지 정리하고자 기록을 남기고자 한다.

2 Cache란

자주 사용하는 데이터나 값을 미리 복사해 놓는 임시 장소이다.

출처 : https://www.upguard.com/blog/cache

위의 이미지의 저장공간 계층 구조에서 확인할 수 있듯이, 캐시는 저장 공간이 작고 비용이 비싼 대신 빠른 성능을 제공한다.

그렇다면 다음과 같은 상황에서 캐시를 활용하는 것이 가장 가성비가 좋다는 의미이다.

• 값이 자주 바뀌지 않고 자주 호출되는 값인지
• DB를 통해 조회해서 가져오는 응답 시간이 오래 걸리는지

값이 자주 바뀌지 않고 자주 호출되는 값은 왜 캐시를 활용하면 좋을까.

위의 상황은 결국 동일한 결과에 대해 동일한 연산이 자주 발생된다는 의미이다. 어차피 결과가 동일하기 때문에 캐시에 저장해두면, 굳이 연산을 하지 않고 해당 결과를 바로 반환하면 되기 때문이다.

DB를 통해 조회해서 가져오는 응답 시간이 오래 걸리는 상황에선 왜 캐시를 활용하면 좋을까.

응답 속도의 문제이다. 응답 속도는 여러 원인으로 인해 느려질 수 있다. 대표적으로는 외부 시스템 호출 비용이 클 때와 트래픽이 급증하는 경우가 있다. 외부 시스템 호출 비용이 크면 네트워크 왕복, 디스크 I/O, 쿼리 파싱 등 여러 단계를 거치기 때문에 수십~수백 ms씩 걸리는 반면 캐시를 통해 읽는다면 1ms 이하로도 줄일 수 있기 때문이다. 즉, 병목이 발생할 수 있는 구간을 건너뛰기가 가능하기에 캐시를 활용하는 방법을 도입할 수 있다.

트래픽이 급증하는 경우도 동일하다. 트래픽이 급증하는 상황에서 모든 요청이 백엔드에 쏟아지는 경우 과부하나 장애로 이어지기도 한다. 이 때 캐시를 통해 트래픽을 제일 앞단에서 처리하도록 한다면 백엔드에게 쏟아지는 부하를 크게 줄일 수 있다.

3 Cache의 종류

캐시의 종류는 다양한다. Caffeine, Redis뿐만 아니라 CDN 캐시, 브라우저 캐시 등등 다양하지만 이번에는 백엔드에서 자주 활용되는 캐시 중 Caffeine과 Redis에 대해서만 기록하고자 한다.

3-1 Caffeine 캐시

Caffeine 캐시는 JVM 힙 메모리 안에 데이터를 저장하는 Java 전용 캐시 라이브러리이다.

3-1-1 동작 방식

애플리케이션 프로세스 내부 메모리에 직접 저장한다. 네트워크 없이 메모리 주소 참조만으로 데이터를 읽어오기 때문에 속도가 극도로 빠르다.

3-1-2 장점

• 속도가 가장 빠름 : 네트워크 I/O가 전혀 없어 나노초~마이크로초 단위 응답
• 설정이 간단 : 의존성 추가 후 코드 몇 줄로 바로 사용 가능
• 자동 메모리 관리 : W-TinyLFU 알고리즘으로 히트율이 높은 데이터를 자동으로 유지
• 별도 인프라 불필요 : Redis 서버 없이 앱 단독으로 동작

3-1-3 단점

• 서버 간 데이터 공유 불가 : 인스턴스가 2대이면 캐시가 2개로 분리되어 일관성이 깨짐
• 앱 재시작 시 데이터 소멸 : 휘발성이라 영속성 없음
• 메모리 제약 : JVM 힙을 공유하므로 저장 용량이 제한적
• Java/JVM 전용 : 다른 언어 서버와 공유 불가

3-2 Redis 캐시

Redis 캐시는 네트워크로 접근하는 형태로 외부 독립적인 인메모리 데이터 저장소이다.

3-2-1 동작 방식

별도 Redis 서버에 데이터를 저장하고, 애플리케이션은 네트워크(TCP)를 통해 읽고 쓴다. 여러 서버가 같은 Redis를 바라보기 때문에 데이터가 공유된다.

3-2-2 장점

• 서버 간 캐시 공유 : 여러 인스턴스가 동일한 데이터를 바라봄 (일관성 보장)
• 다양한 자료구조 지원 : String, Hash, List, Set, Sorted Set, Pub/Sub 등
• 영속성 옵션 : RDB/AOF로 디스크에 저장 가능, 재시작 후 복구 가능
• 대용량 저장 가능 : 서버 메모리 한도까지 자유롭게 확장
• 언어 무관 : Node.js, Python, Go 등 어떤 스택이든 사용 가능

3-2-3 단점

• 네트워크 레이턴시 존재 : 아무리 빨라도 0.5~1ms 이상 소요
• 인프라 관리 필요 : 별도 서버 운영, 장애 대응, 모니터링 필요
• 비용 발생 : 클라우드 사용 시 인스턴스 비용 추가
• 단일 장애점 위험 : Redis 서버 다운 시 전체 캐시 영향 (Cluster/Sentinel로 완화 가능)

3-3 장단점 비교

4 캐시 밴치마크 실습

4-1 기술 스택

4-1-1 언어 & 프레임워크

4-1-2 캐시

캐시 전략은 CacheStrategy 인터페이스로 추상화하고, ProductController에서 @Qualifier로 3종을 동시 활성화하여 엔드포인트 경로(/caffeine/, /redis/, /nocache/)로 분기.

4-1-3 데이터베이스

4-1-4 직렬화

Redis 직렬화는 deprecated된 GenericJackson2JsonRedisSerializer 대신 ObjectMapper를 직접 사용하는 커스텀 RedisSerializer<Product> 구현.

4-1-5 모니터링 & 운영

4-1-6 부하 테스트

k6 스크립트는 warmup + load 6개 시나리오(전략별 각 2개)를 단일 실행으로 순차 처리.

4-1-7 인프라 & 컨테이너

4-1-8 개발 도구

4-1-9 설계 패턴

5 핵심 로직

5-1 Strategy 추상화 및 구현화

• get : 캐시에 저장된 데이터 조회

• put : 데이터 캐싱

• evict : id를 통해 캐시에서 데이터 삭제

5-1-1 CaffeineStrategy

5-1-2 RedisStrategy

5-1-3 NoCacheStratey

어느 동작도 하지 않지만, 컨트롤러의 각 API가 fetch라는 동일 메서드를 호출하기 때문에 작성하였고 get메서드에 의해 EMPTY의 데이터가 반환되어 DB에 직접 조회하도록 유도

5-2 Controller & Service

5-2-1 Controller

@Qualifer 어노테이션을 통해 3종 전략 빈을 동시 주입하고, 각 API는 fetch 메서드를 호출 fetch 메서드에서는 strategy를 통해 값을 조회하고 없다면 service를 통해 DB조회한 결과를 반환. 마지막으로 strategy.put 메서드로 캐싱

5-2-2 Service

Service의 경우 DB 조회에 대한 로직만 필요하므로 최소환의 비즈니스 로직만 작성

6 테스트

6-1 테스트 방법

테스트는 2가지를 준비했다. 첫 번째로는 Postman을 통한 API 직접 호출 두 번째는 K6를 활용한 부하 테스트를 통한 캐시 성능 밴치마크

6-2 API 호출 테스트

복잡한 비즈니스 로직이 없어 API 호출을 하는 것만으로는 성능을 확인하기 어렵기 때문에 Service 로직에서 반복문을 추가해 반환 속도를 의도적으로 늦춰서 실행한다.

6-2-1 No-Cache

No-Cache의 경우 524ms와 189ms라는 비교적 늦은 응답속도를 확인할 수 있다.

6-2-2 Caffeine

• Cache Miss

• Cache Hit

Caffeine의 경우 Cache Miss에서는 234ms를 보여주지만 Cache Hit일 때는 5ms라는 빠른 응답 속도를 나타낸다.

6-2-3 Redis

• Cache Miss

• Cache Hit

Redis의 경우도 1.27s에서 8ms로 응답 속도가 매우 빠르게 향상된 것을 확인할 수 있었다.

7 부하 테스트

7-1 K6의 부하테스트 목적

동일한 애플리케이션 인스턴스에서 캐시 전략 3종을 공정한 조건 아래 비교하여, 전략 선택이 성능에 미치는 영향을 수치로 증명하는 것이 목표였다.

7-1-1 측정 지표

TPS — 초당 처리 요청 수 (전략 간 처리량 비교) p50 — 전체 요청의 중간값 응답시간 p95 — 상위 5% 느린 요청의 응답시간 (서비스 안정성 기준) p99 — 최악 케이스 응답시간 error_rate — 비정상 응답 비율 (목표 < 1%)

7-1-2 시나리오 설계

7-2 K6 부하테스트 결과

7-2-1 Load 시나리오 기준 (vus=100, 60s)

7-2-2 서버 처리 시간 TTFB — http_req_waiting (Load 기준)

7-2-3 결론

1. Caffeine이 가장 빠름

   p50 기준 1.2ms로 3종 중 가장 빠르다. JVM 힙에서 직접 반환하므로 네트워크 비용이 전혀 없다. p99도 7.0ms로 안정적.

2. NoCache가 Redis보다 빠르게 나왔다 — H2 인메모리 특성

   NoCacheStrategy(p50 1.6ms)가 Redis(p50 4.2ms)보다 빠른 것은 이상해 보이지만, 사용 중인 DB가 H2 인메모리이기 때문이다. H2는 프로세스 내부 메모리에서 직접 조회하므로 TCP 통신이 없다. PostgreSQL 같은 외부 DB를 사용했다면 순위가 달라졌을 것이다.

3. Redis가 가장 느리게 나왔다 — TCP + 직렬화 비용

   p50 4.2ms, p95 15.3ms로 Caffeine의 3~4배 수준. TTFB 기준 avg 5.5ms는 전부 네트워크 RTT + JSON 직렬화/역직렬화 오버헤드로 보인다.

4. TPS는 셋 다 비슷 — 병목이 캐시가 아님

   TPS가 940~978로 거의 동일한 이유는 k6 스크립트의 sleep(0.1) 때문이다. vus 100 × (1/0.1) = 최대 1,000 TPS가 이론적 상한이며, 실제 수치가 이에 근접하고 있다. 즉 현재 병목은 캐시가 아닌 k6의 요청 간격이다.

5. 에러율 0% — 안정성 확인

H2를 사용했기에 원했던 결과와 차이가 나지만 그래도 어떠한 상황에서 어떠한 기술 스택을 사용하면 좀 더 좋을 수 있을지 알게되었다고 생각한다.

GitHub

https://github.com/Mungi-Cheon/Cache-Benchmark

준비 시간

1개월

개인사 및 다른 공부들도 있었기에 격일이라도 최대한 1,2시간씩 공부했다. 풀타임으로 공부를 했어도 넉넉히 1~2주면 충분하지 않을까 싶다. (같이 본 아는 동생은 3일 공부하고 합격...)

공부 방법

1주차 - 2주차

정독과 동시에 아래 내용으로 요약해 PDF파일로 만들었다.

개념 요약, 두음어 만들기, 함수 정의 및 동작 원리, 함수 예시

아래는 실제 요약한 내용의 일부이다.

네이버 스마트 스토어같은데 보면 저렴한 가격에 요약본 판매를 하는데 굳이 직접 요약한 이유는 다음과 같다.

1. 직접 요약을 하면서 내용을 외우거나 이해하고자 했다.
2. 다른 공부를 포함한 개인 스케줄이 있어 어디서든 볼 수 있게 조금이나마 시간을 활용하고 싶었다.

3주차 - 4주차

3,4주차부터는 일명 노랭이 책이라고 불리는 아래 책의 문제만 풀었다.

풀면서 모르는 문제, 헷갈리는 문제들은 해설을 보거나 PDF로 요약한 내용을 다시 보고 풀었다. 그래도 안된다면 GPT를 통해 Step별로 동작 원리를 나타내도록 한 뒤 동작 흐름을 통해서 이해했다. (사실 노랭이 해설본은.. 친절하지 않아서 응? 할 때도 있었다. 이걸 해결 해준건 갓 GPT )

그리고 틀렸던 문제들은 책에 메모한 내용이나 번호에 체크했던 걸 다 지우고 다시 푸는 식으로 했다.

시험 전날 그리고 시험 당일

시험 전날에는 미리 PDF내용을 인쇄해두고 다시 훑어 보면서 개념을 정리했다.

당일에는 프린트물을 들고가 만들어둔 두음어를 다시 암기하고 시험을 봤는데

개인적으로는 90분동안 50문제를 풀어야 한다는 것이 생각보다 시간적 부담감이 컸다.

그래서 시험 시작 5분동안 문제를 훑어보면서 지문이 많거나 Window 함수 관련 문제이거나, 복잡해보이는 문제에 체크 표시를 했다.

그리고 30분동안 체크를 안한 문제 즉, 비교적 쉬운 문제들을 빠르게 풀고 OMR 마킹할 10분을 제외한 나머지 45분은 체크한 문제를 푸는 방향으로 접근했다.

이런 시간 분배를 통해 시험을 좀 더 효율적으로 치루지 않았나 싶다.

또한 난이도는 '이걸 어떻게 풀어..?' 할 정도로 막연하게 어렵다고 느껴지는 문제들은 다행히 없었다.

조금 복잡하거나 헷갈리는 문제들은 있었지만 대부분 무난하게 풀 수 있었다. (SQLD 관련 커뮤니티에서는 난이도가 전회차 보다 어렵다고 해서 오히려 놀람..)

감상

다행히 원트에 합격했지만 나름 피말리는 한달이었던 것 같다. 개인 스케줄 처리, 개인 공부, 입사 지원 등등 물론 지금도 현재 진행형이지만.. 이제 이력서에 SQLD라고 한 줄 추가할 수 있게 된걸 위안으로 삼아보려 한다. 올해 안으로는 좋은 일이 있길 바래본다.

이전 포스트에서 Router를 구현하였다. 이제 남은 항목은 Post, Admin도메인의 Controller, Service로직만을 남겨두고 있고, 이번 포스트가 블로그 구현 프로젝트의 마지막이 될 것 같다.

2. Post Controller / Service

먼저 게시글 관련 Controller와 Service 로직을 구현하고자 한다.

2-1. postController.js

8가지의 Post API를 구현할 것이다.

• getAllPost : 전체 게시글을 조회 API
• getPostDetail : 특정 게시글을 조회 API
• getAddPostPage : 게시글 작성 페이지
• addPost : 게시글 작성 API
• editPost : 게시글 수정 API
• deletePost : 게시글 삭제 API

const postService = require("../service/postService.js");
const mainLayout = "../views/layouts/main.ejs";
const adminLayout = "../views/layouts/admin-login.ejs";
const { isAdmin } = require("../utils/authUtil");

const getAllPost = async (req, res) => {
    const layout = isAdmin(req) ? adminLayout : mainLayout;
    const locals = { title: "Home" };
    const data = await postService.fetchAllPosts();
    res.render("post/index", { locals, data, layout: layout });
};

const getPostDetail = async (req, res) => {
    const layout = isAdmin(req) ? adminLayout : mainLayout;
    const data = await postService.fetchPostById(req.params.id);
    res.render("post/post", { data, layout });
};

const getAllPostByAdmin = async (req, res) => {
    const locals = { title: "Posts" };
    const data = await postService.fetchAllPosts();
    res.render("admin/allPosts", { locals, data, layout: adminLayout });
};

const addPost = async (req, res) => {
    const { title, body } = req.body;
    if (!title || !body) {
        return res.send("'필수 항목목이 입력되지 않았습니다.'");
    }
    await postService.createPost(title, body);
    res.redirect("/allPosts");
};

const editPost = async (req, res) => {
    await postService.updatePost(req.params.id, req.body);
    res.redirect("/allPosts");
};

const deletePost = async (req, res) => {
    await postService.deletePost(req.params.id);
    res.redirect("/allPosts");
};

module.exports = {
    getAllPost,
    getPostDetail,
    getAllPostByAdmin,
    addPost,
    editPost,
    deletePost,
};

2-2. postService.js

const Post = require("../models/Post");

/**
 * 게시글 전체 조회
 */
const fetchAllPosts = async () => {
    const posts = await Post.find().sort({ createdAt: -1 }); // 내림차순으로 정렬
      // 기존 post객체에 formattedDate필드를 추가한 새로운 post객체로 만들어 반환
    return posts.map(post => ({
        ...post._doc,
        formattedDate: post.createdAt.toISOString().split('T')[0],
    }));
};

/**
 * 특정 게시글 조회
 * @param {string} id
 */
const fetchPostById = async (id) => {
    return await Post.findOne({ _id: id });
};

const createPost = async (title, body) => {
    await Post.create({ title, body });
};

const updatePost = async (id, body) => {
    await Post.findByIdAndUpdate(id, {
        title: body.title,
        body: body.body,
        createdAt: Date.now(),
    });
};

const deletePost = async (id) => {
    await Post.deleteOne({ _id: id });
};

module.exports = {
    fetchAllPosts,
    fetchPostById,
    createPost,
    updatePost,
    deletePost
};

3. Admin Controller / Service

3-1. adminController.js

5가지의 Admin API를 구현할 것이다.

• getAdminPage : 관리자 페이지 랜더링
• getAddPostPage : 게시글 작성 페이지 랜더링
• getAllPosts : 전체 게시글 조회
• login : 로그인
• logout : 로그아웃

const adminService = require("../service/adminService");
const { isAdmin } = require("../utils/authUtil");

const login = async (req, res) => {
    const { username, password } = req.body;
    const result = await adminService.login(username, password);

    if (!result.success) {
        return res.status(401).json({ message: result.message });
    }

    res.cookie("token", result.token, { httpOnly: true });
    res.redirect("/allPosts");
};

const logout = (req, res) => {
    adminService.logout(res);
    res.redirect("/");
};

module.exports = {
    login,
    logout,
};

3-2. adminService.js

const User = require("../models/User");
const bcrypt = require("bcrypt");
const jwt = require("jsonwebtoken");
const jwtSecret = process.env.JWT_SECRET;
const jwtAccessTtl = process.env.JWT_ACCESS_TTL;

const login = async (username, password) => {
    const user = await User.findOne({ username });
    if (!user) {
        return { success: false, message: "일치하는 사용자가 없습니다." };
    }

    const isValidPassword = await bcrypt.compare(password, user.password);
    if (!isValidPassword) {
        return { success: false, message: "일치하는 사용자가 없습니다." };
    }

      // jwt에 .env에 지정한 SecretKey와 TTL을 설정해서 발급
    const token = jwt.sign({ userId: user._id }, jwtSecret,  { expiresIn: jwtAccessTtl });
    return { success: true, token };
};

const logout = (res) => {
    res.clearCookie("token");
}

module.exports = {
    login,
    logout
};

4. 마무리

처음 다뤄본 Node.js였지만 기본 베이스가 JavaScript이라 그런지 비교적 이해하기 쉬웠다.

특히, 이제껏 Java&Spring을 주로 써왔기에 가장 크게 체감된건 Node.js & Express가 Java&Spring보다 프레임 구조나 애플리케이션 시작 등 많은 부분이 가볍다 라는 점이다.

아마 그만큼 규모가 큰 서비스나 복잡한 연산이 많이 필요한 상황에서는 Java&Spring이 더 안정적이지 않을까 라는 생각이 든다.

그래서 Node.js의 경우는 빠르게 개발하고자 할 때 사용하기엔 편할것 같다는 느낌이다.

다만, 아직까진 기본적인 문법과 express 프레임워크를 맛보는 단계로 수행했기에 깊이 있는 이해는 못했기에 다른 분들의 블로그들이나 공식 문서를 찾아보면서 Express의 동작원리도 보고 실제 배포까지 해볼 수 있는 프로젝트도 고민해봐야 할 듯 하다.

물론.. 구직활동과 자격증 공부도 꾸준히 해야하기 때문에 프로젝트는 당장 실행하는건 여건상 힘들겠지만 천천히라도 하고자 한다.

이전 포스트에서는 DB연동, View 및 Layout을 구현했다. 이제 남은 항목들은 도메인의 Router, Controller, Service 로직만을 앞두고 있다. 이번 포스트에서는 다음과 같이 작성한 Router 로직을 기록하고자 한다.

• routes
  • postRouter.js : 게시글 관련 Router
  • adminRouter.js : 관리자 관련 Router

2. postRouter.js

postRouter에서는 요청 받은 endpoint에 맞춰 알맞은 게시글 관련 데이터를 보내줄 수 있도록 연결한다.

요청 받는 endpoint는 다음과 같다.

• /, /home
  • GET : 메인 페이지에 표시할 게시글 리스트 조회
• /posts/:id
  • GET : 특정 게시글의 상세 조회
• /allPosts
  • GET : 게시글 조회 API
• /add
  • GET : 게시글 작성 페이지로 랜더링
  • POST : 게시글 작성 API
• /edit/:id
  • GET : 게시글 수정 페이지로 랜더링
  • PUT : 게시글 수정 API
• /delete/:id
  • DELETE : 게시글 삭제 API

const express = require("express");
const asyncHandler = require("express-async-handler");
const router = express.Router();
const postController = require("../controllers/postController");
const { checkLogin } = require("../utils/authUtil");
const adminLayout = "../views/layouts/admin-login.ejs";

router.get(["/", "/home"], asyncHandler(postController.getAllPost));

router.get("/posts/:id", asyncHandler(postController.getPostDetail));

router.get("/allPosts", checkLogin, asyncHandler(postController.getAllPostByAdmin));

router.route("/add")
    .get(checkLogin, (req, res) => {
        const locals = { title: "게시물 작성" };
        res.render("admin/add", { locals, layout: adminLayout });
    })
    .post(checkLogin, asyncHandler(postController.addPost));

router.route("/edit/:id")
    .get(checkLogin, async (req, res) => {
        const locals = { title: "게시물 수정" };
        const data = await postService.fetchPostById(req.params.id);
        res.render("admin/edit", { locals, data, layout: adminLayout });
    })
    .put(checkLogin, asyncHandler(postController.editPost));

router.delete("/delete/:id", checkLogin, asyncHandler(postController.deletePost));

module.exports = router;

3. adminRouter.js

adminRouter에서 요청 받는 endpoint는 다음과 같다.

• /admin
  • GET : 로그인 페이지로 랜더링
  • POST : 로그인 API
• /logout
  • GET : 로그아웃 API
• /about
  • GET : About 페이지로 랜더링

const express = require("express");
const router = express.Router();
const asyncHandler = require("express-async-handler");
const adminController = require("../controllers/adminController");
const { checkLogin } = require("../utils/authUtil");
const adminLoginLayout = "../views/layouts/admin-login.ejs";
const adminNoLoginLayout = "../views/layouts/admin-nologin.ejs";
const mainLayout = "../views/layouts/main.ejs";

router.route("/admin")
    .get((req, res) => {
        const locals = { title: "관리자 페이지" };
        res.render("admin/login", { locals, layout: adminNoLoginLayout });
    })
    .post(asyncHandler(adminController.login));

router.route("/logout").get(adminController.logout);

router.route("/about").get((req, res) => {
    const layout = isAdmin(req) ? adminLoginLayout : mainLayout;
    const locals = { title: "About" };
    res.render("admin/about", { locals, layout: layout });
});

module.exports = router;

4. Util 클래스 작성

현재 상황에서 URL로 직접 관리자 페이지로 접속을 시도하면 어떠한 인증도 없이 관리자 페이지에 접속이 될 것이다. 당연히 NG인 상황이기에 인증을 거쳐야만 관리자 페이지에 접속할 수 있도록 해야한다. 다만, 현업에서 사용하는 방법은 훨씬 다양하고 복잡하므로 아래의 인증 로직은 어디까지나 참고정도로만 하면 될 것 같다.

• utiles
  • authUtil.js

4-1. authUtil.js

const jwt = require("jsonwebtoken");
const jwtSecret = process.env.JWT_SECRET;

const checkLogin = (req, res, next) => {
    const token = req.cookies.token;
    if (!token) {
        return res.redirect("/admin");
    }
    try {
        const payload = jwt.verify(token, jwtSecret);
        req.userId = payload.userId;
        next();
    } catch (error) {
        return res.redirect("/admin");
    }
};

const isAdmin = (req) => {
    const token = req.cookies?.token;

    if (!token) {
        return false;
    }

    try {
        jwt.verify(token, jwtSecret);
        return true;
    } catch (e) {
        return false;
    }
};

module.exports = { checkLogin,isAdmin };

이번 포스트에서는 View를 작성하고자 한다. 인프런의 Do it! Node.js 프로그래밍 입문 강의에서 제공하는 HTML를 EJS로 변환해 View를 작성되었다.

2. EJS란

EJS는 Embedded JavaScript Template의 약어로 템플릿 엔진 모듈이다. 템플릿 엔진 모듈은 서버에서 DB 혹은 API에서 가져온 데이터를 미리 정의된 Template에 맞춰 대입하고, html를 랜더링해 클라이언트에 원하는 정보를 전달해주는 역할을 한다.

3. Layout 작성

메인 페이지, 관리자 페이지의 Header와 Footer를 보여줄 레이아웃을 views/layouts 폴더에 작성한다. 작성해야할 레이아웃의 목록은 다음과 같다.

• main.ejs : 메인 페이지의 레이아웃
• admin-login.ejs : 관리자 페이지의 레이아웃
• admin-nologin.ejs : 로그인 페이지의 레이아웃

3-1. main.ejs

<!DOCTYPE html>
<html lang="ko">

<head>
    <meta charset="UTF-8">
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title><%= locals.title %></title>
    <meta name="description" content="My first application using Node.js, Express and MongoDB">
    <link rel="stylesheet" href="/css/style.css">
</head>

<body>

    <div class="container">

        <!-- 헤더 : 로고, 상단 메뉴, 로그인 -->
        <header class="header">
            <!-- 로고 -->
            <a href="/" class="header-logo">c.mungi의 블로그</a>

            <!-- 상단 메뉴 -->
            <nav class="header-nav">
                <ul>
                    <li>
                        <a href="/home">Home</a>
                    </li>
                    <li>
                        <a href="/about">About</a>
                    </li>
                </ul>
            </nav>

            <!-- 관리자 로그인 -->
            <div class="header-button">
                <a href="/admin">관리자 로그인</a>
            </div>
        </header>

        <!-- 메인 : 실제 내용이 들어갈 부분 -->
        <main class="main">
            <%- body %>
        </main>
    </div>

</body>

</html>

3-2. admin-login.ejs

<!DOCTYPE html>
<html lang="ko">

<head>
    <meta charset="UTF-8">
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title><%= locals.title %></title>
    <meta name="description" content="My first application using Node.js, Express and MongoDB">
    <link rel="stylesheet" href="/css/style.css">
</head>

<body>

    <div class="container">

        <!-- 헤더 : 로고, 상단 메뉴, 로그인 -->
        <header class="header">
            <!-- 로고 -->
            <a href="/" class="header-logo">Admin Page</a>

            <!-- 상단 메뉴 -->
            <nav class="header-nav">
                <ul>
                    <li>
                        <a href="/home">Home</a>
                    </li>
                    <li>
                        <a href="/about">About</a>
                    </li>
                    <li>
                        <a href="/allPosts">Admin</a>
                    </li>
                </ul>
            </nav>

            <!-- 관리자 로그아웃 -->
            <div class="header-button">
                <a href="/logout">관리자 로그아웃</a>
            </div>
        </header>

        <!-- 메인 : 실제 내용이 들어갈 부분 -->
        <main class="main">
            <%- body %>
        </main>
    </div>

</body>

</html>

3-3. admin-nologin.ejs

<!DOCTYPE html>
<html lang="ko">

<head>
    <meta charset="UTF-8">
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title><%= locals.title %></title>
    <meta name="description" content="My first application using Node.js, Express and MongoDB">
    <link rel="stylesheet" href="/css/style.css">
</head>

<body>

    <div class="container">

        <!-- 헤더 : 로고, 상단 메뉴, 로그인 -->
        <header class="header">
            <!-- 로고 -->
            <a href="/" class="header-logo">Admin Page</a>

            <!-- 상단 메뉴 -->
            <nav class="header-nav">
                <ul>
                    <li>
                        <a href="/home">Home</a>
                    </li>
                    <li>
                        <a href="/about">About</a>
                    </li>
                </ul>
            </nav>
        </header>

        <!-- 메인 : 실제 내용이 들어갈 부분 -->
        <main class="main">
            <%- body %>
        </main>
    </div>

</body>

</html>

4. View 작성

View들은 각 views/post, views/admin에 다음과 같이 작성한다.

• views/post
  • index.ejs : 메인 페이지
  • post.ejs : 상세 페이지
• views/admin
  • login.ejs : 로그인 페이지
  • allPosts.ejs : 관리자 페이지
  • add.ejs : 게시글 작성 페이지
  • edit.ejs : 게시글 수정 페이지
  • about.ejs : About 페이지

4-1. 게시글 페이지 관련 View

4-1-1. index.ejs

<!-- 상단 소개글, 히어로 이미지 -->
<div class="top">
    <h1 class="top-heading">하루하루 스터디</h1>
    <p class="top-body">매일 1시간씩 공부한 내용을 기록하고 있습니다.</p>
</div>

<img src="/img/top-hero.jpg" alt="노트에 기록하는 모습" class="hero-image" width="840" height="400">

<!-- 최근 게시물 -->
<section class="articles">
    <h2 class="articles-heading">최근 게시물</h2>
    <ul class="article-ul">
        <% data.forEach( post => { %>
        <li>
            <a href="/posts/<%= post._id %>"> 
                <span><%= post.title %></span>
                <span class="article-list-date"><%= post.createdAt.toDateString()%></span>
            </a>
        </li>
        <% }) %>
    </ul>
</section>

4-1-2. post.ejs

<h1><%= data.title%></h1>
<article class="article">
    <%= data.body %>
</article>

4-2. 관리자 페이지 관련 View

4-2-1. login.ejs

<h3>로그인</h3>
<form action="/admin" method="POST">
    <label for="username"><b>사용자 이름</b></label>
    <input type="text" name="username" id="username">

    <label for="password"><b>비밀번호</b></label>
    <input type="password" name="password" id="password">

    <input type="submit" value="로그인" class="btn">
</form>

4-2-2. allPosts.ejs

<div class="admin-title">
    <h2><%= locals.title%></h2>
    <a href="/add" class="button">+ 새 게시물</a>
</div>

<ul class="admin-posts">
    <% data.forEach(post => { %>  <!-- Post 데이터들을 표시 -->
        <li>
            <a href="/posts/<%=post._id%>">
                <%= post.title %>
            </a>
            <label><%= post.formattedDate %></label>
            <div class="admin-post-controls">
                <a href="/edit/<%=post._id%>" class="btn">편집</a>
                <form action="/delete/<%=post._id%>?_method=DELETE" method="POST">
                    <input type="submit" value="삭제" class="btn-delete btn">
                </form>
            </div>
        </li>
    <% }) %> <!-- 여기 까지 -->
</ul>

4-2-3. add.ejs

<a href="/allPosts">&larr; 뒤로</a>
<div class="admin-title">
    <h2><%= locals.title %></h2>
</div>

<form action="/add" method="POST">
    <label for="title"><b>제목</b></label>
    <input type="text" placeholder="게시물 제목" name="title" id="title">

    <label for="body"><b>내용</b></label>
    <textarea placeholder="게시물 내용" name="body" id="body" cols="50" rows="10"></textarea>

    <input type="submit" value="등록" class="btn">
</form>

4-2-4. edit.ejs

<a href="/allPosts">&larr; 뒤로</a>
<div class="admin-title">
    <h2><%= locals.title %></h2>
    <form action="/delete/<%=data._id%>?_method=DELETE" method="POST">
        <input type="submit" value="삭제" class="btn btn-delete">
    </form>
</div>

<form action="/edit/<%= data._id %>?_method=PUT" method="POST">
    <label for="title"><b>제목</b></label>
    <input type="text" name="title" id="title" value="<%=data.title%>">

    <label for="body"><b>내용</b></label>
    <textarea name="body" id="body" cols="50" rows="10">
        <%=data.body %>
    </textarea>

    <input type="submit" value="수정" class="btn">
</form>

4-2-5. about.ejs

<h1>About</h1>

<b>이 블로그는 Node.JS 학습을 위해 제작되었습니다.</b>

이전 포스트를 끝으로 약 2개월정도 시간이 흘렀다. 2개월동안은 재취업 준비겸 자격증 공부를 주로 했다.(정처기 실기 1회.. 극악..)

그래도 Node.js를 더 까먹기 전에 빠르게 마무리 하고자 블로그를 구현하는 프로젝트를 시작하고자 한다.

다만, Node.JS와 Express에 대한 지식이 낮은 관계로 인프런의 Do it! Node.js 프로그래밍 입문를 보면서 구현하였고, 그 과정을 블로그에 녹여보고자 한다.

2. 블로그 구현 내용

아래와 같은 기능들을 구현하고자 한다.

• 메인 화면 (비 로그인)
  • 최신 작성 게시글 리스트 조회
  • 게시글 상세 조회
• 로그인 화면
  • 아이디, 비밀번호를 통한 관리자 로그인 기능
• 관리자(User) 화면
  • 게시글(Post) 작성
  • 게시글(Post) 수정
  • 게시글(Post) 삭제

관리자 계정에 대한 등록 기능은 필요하지 않아 임시로 로직을 작성해서 등록했다.

3. 사용 기술 스택

• Back-end
  • Node.js
• F/W
  • Express
• Template
  • EJS : HTML에 JS문법이 삽입 가능한 템플릿 엔진
• Library
  • dotenv : .env의 환경변수를 process.env로 로드 가능한 라이브러리
  • express-async-handler : 비동기식 요청 핸들러를 처리하기 위한 미들웨어
  • express-ejs-layouts : EJS 템플릿에서 레이아웃 기능을 지원
  • method-override : form에서 PUT과 DELETE 메소드를 사용할 수 있게하는 라이브러리
  • mongoose : Mongo DB와 연동하는 ODM 라이브러리
  • bcrypt : 비밀번호 암호화 및 해시 비교 라이브러리
  • cookie-parser : Node.js 환경에서 쿠키를 쉽게 사용할 수 있도록 도와주는 미들웨어
  • jsonwebtoken : JWT

4. 프로젝트 구성

• config : DB 연동 설정 관리
• controllers : Admin, Post 도메인 Controller 레이어 관리
• models : DB Schema 관리
• public : css, image 등 정적 파일 관리
• routes : Admin, Post 도메인의 Route 레이어 관리
• service : Admin, Post 도메인의 Service 레이어 관리
• utils : Util 로직 관리
• views : ejs 파일 관리
  • admin : Admin 페이지 관련 ejs 파일 관리
  • layouts : Admin, Post 페이지 관련 레이아웃 ejs 파일 관리
  • post : Post 페이지 관련 ejs 파일 관리
• .env : 환경 설정 파일
• app.js : 엔트리 포인트 파일

5. app.js 로직 작성

app.js 파일을 생성한 후 다음과 같은 로직을 작성한다. 아래의 로직은 완성본의 일부분이므로 이후 db 및 layout 설정 등에 따라서 로직이 추가될 예정이다.

require("dotenv").config();
const express = require("express");

const app = express();
const port = process.env.PORT || 3000;

app.use(express.static("public"));

app.listen(port, () => {
    console.log(`App listening on port ${port}`);
});

6. DB 연동 ( MongoDB )

6-1. .env 환경 변수 설정

기본적인 MongoDB 연동 방법은 이전 포스트에 적었으므로 링크만 살짝..

Node.js : DB Connection

먼저 아래와 같이 MongoDB 플러그인에서 커넥션을 대상으로 우클릭을 한 뒤, Copy Connection String을 클릭하면 DB_URI가 복사한다.

.env파일을 생성하고 다음과 같이 설정한다. (본인의 경우 MONGODB_URI라는 Key로 설정했으나 Key 이름은 마음대로 정해도 상관없다.)

6-2. DB Config 설정

config 폴더에 db.js 파일을 생성하고 다음과 같이 DB 연결 로직을 작성한다.

const mongoose = require("mongoose");
const asyncHandler = require("express-async-handler");
require("dotenv").config();

const connectDb = asyncHandler( async () =>{
    const connect = await mongoose.connect(process.env.MONGODB_URI);
    console.log(`DB Connected: ${connect.connection.host}`);
})

module.exports = connectDb;

6-3. app.js 로직 작성

다음과 같이 db관련 로직을 추가 작성한다.

require("dotenv").config();
const express = require("express");
const connectDb = require("./config/db"); // 추가

connectDb(); // 추가

const app = express();
const port = process.env.PORT || 3000;

app.use(express.static("public"));

app.listen(port, () => {
    console.log(`App listening on port ${port}`);
});

문제없이 연동된다면 어플리케이션을 실행했을 때 다음과 같은 로그가 출력된다.

6-4. DB Schema 작성

관리자(User) 도메인과 게시글(Post) 도메인에 대한 스키마를 models 폴더 내에 다음과 같이 작성한다.

User 스키마

const mongoose = require("mongoose");

const userSchema = new mongoose.Schema({
    username: {
        type: String,
        required: true,
        unique: true
    },
    password: {
        type: String,
        required: true
    }
});

module.exports = mongoose.model("User", userSchema);

Post 스키마

const mongoose = require("mongoose");

const PostSchema = new mongoose.Schema({
    title: {
        type: String,
        required: true
    },
    body: {
        type: String,
        required: true
    },
    createdAt: {
        type: Date,
        default: Date.now()
    }
});

module.exports = mongoose.model("Post", PostSchema);

1-1. https://mongodb.com/ 에 접속해 회원가입/로그인을 하고 Clusters를 생성한다.

1-2. Connect 버튼을 누르고 MongoDB for VS Code을 누른다.

1-3. Connect to your MongoDB deployment의 내용을 복사한다.

1-4. VS Code로 돌아와 MongoDB확장 프로그램을 설치한다.

1-5. MongoDB를 선택하고 Connection String의 Connect를 클릭한다.

1-6. VS Code의 위에 입력폼이 나타나는데 3에서 복사한 내용을 붙여넣는다.

1-7. 붙여넣은 내용 중에 라는 문장을 1번에서 생성한 Clusters의 패스워드를 입력하고 Enter키를 누른다. 문제없이 성공했다면 DB Connection이 추가되어 있을 것이다.

2. MySQL Connection

2-1. mySQL Connection의 경우 npm으로 설치해야한다.

npm install --save mysql2

2-2. 설치가 완료되면 package.json의 dependencies항목에 mysql2가 추가된다.

2-3. MySQL Connection할 코드를 작성하고 모듈화한다.

const mysql = require('mysql2/promise');
require('dotenv').config();

// async/await 으로 DB 연결을 비동기 처리
const dbConnect = async () => {
  try {
    const connection = await mysql.createConnection({
      host: process.env.DB_HOST,
      user: process.env.DB_USER,
      password: process.env.DB_PASS,
      database: process.env.DB_NAME,
    });
    console.log("MySQL Connected.");
    return connection;
  } catch (err) {
    console.log(err);
  }
};

module.exports = dbConnect;

.env

DB_HOST=localhost
DB_USER=root
DB_PASS=password
DB_NAME=schema

2-4. app.js 또는 index.js에 모듈화한 dbConnection을 인스턴스 생성해 함수를 호출한다.

2-5. 결과 확인

Express는 웹 및 모바일 애플리케이션을 위한 일련의 강력한 기능을 제공하는 간결하고 유연한 Node.js 웹 애플리케이션 프레임워크이다.

Node.js는 표준 웹서버 프레임워크로 불려질 만큼 많은 곳에서 사용하고 있다.

2. Node.js와 Express의 관계

Node.js는 Chrome의 V8엔진을 이용하여 JavaScript로 브라우저가 아니라 서버를 구축하고, 서버에서 JavaScript가 작동되도록 해주는 런타임 환경 플랫폼이다.

3. 그래서 왜 사용하는가?

• 미들웨어 기반 프레임워크로, 기존의 Node.js의 HTTP 모듈보다 훨씬 간결하게 서버를 구축할 수 있다.
• 간단한 라우팅 시스템을 제공하여 URL 별로 적절한 처리를 쉽게 설정할 수 있다.
• 미들웨어 시스템을 통해 요청과 응답을 중간에 가공할 수 있다.
• 다양한 서드파티 미들웨어와 함께 사용할 수 있으며, JWT 인증, 세션 관리, 보안, CORS, 파일 업로드 등을 쉽게 구현할 수 있다.
• RESTful API 개발에 최적화되어 있어, 프론트엔드(React, Vue, Angular)와 연동하여 백엔드 API 서버를 쉽게 구축할 수 있다.

4. Express 사용하기

4-1. Express module 설치

npm i express

console에 위의 명령어를 실행하면 node_modules이 생성된다.

또한, pakage.json의 dependencies항목에 express가 추가된다.

4-2. 기본 사용 방법

const express = require("express"); // require모듈로 express모듈을 import한다.

const app = express(); // express instance 생성

app.use(express.json()); // json type의 body를 파싱하도록 미들웨어 설정
app.use(express.urlencoded({extended:true})); // HTML 폼에서 전송된 데이터를 해석하는 미들웨어 설정

app.get("/", (req, res)=>{
    res.send('Hello, Node!');
});

app.listen(3000, () => {
    console.log('서버 실행 중');
});

4-3. 실행 결과

이번 포스트는 Open API를 통해 숙박 정보를 Json으로 받아 간략하게 가공한 뒤, DB에 저장하는 Batch 실습을 정리해보고자 한다.

사용한 숙박 정보API는 아래 공공API를 사용했다. https://www.data.go.kr/tcs/dss/selectApiDataDetailView.do?publicDataPk=15101578

신청만 하면 바로 승인되니 기다릴 필요도 없고 가이드도 잘 나와있어서 사용하기 편했다.(다만,, response의 field값이 없는 경우가 좀 많다..)

1. 개발 환경

• Language

• Java 17
  • Framework
• Spring Boot 3.4.3
• Spring Batch 5.2.0
  • Library
• Spring Data JPA
• Lombok
  • DataBase
• MySQL 8.0.37
  • OS & IDE
• Windows 11
• IntelliJ 2024.3.5

2. 개발 기간

• 2025.03.12 - 2025-03-27 (2주) 원래 목표는 3일이었다.. (1일 공부, 1일 구현 및 테스트, 1일 리팩토링) 하지만 이력서 준비와 개인사로 인해 2주나 걸리고 말았다..🥲

3. 다중 DB 연결

spring.batch.job.enabled=false
spring.batch.jdbc.initialize-schema=never
spring.batch.jdbc.schema=classpath:org/springframework/batch/core/schema-mysql.sql

spring.datasource-meta.driver-class-name=com.mysql.cj.jdbc.Driver
spring.datasource-meta.jdbc-url=jdbc:mysql://localhost:3307/meta_batch
spring.datasource-meta.username=DB유저
spring.datasource-meta.password=패스워드

spring.datasource-data.driver-class-name=com.mysql.cj.jdbc.Driver
spring.datasource-data.jdbc-url=jdbc:mysql://localhost:3307/stay_info
spring.datasource-data.username=DB유저
spring.datasource-data.password=패스워드

3-1. DB Config

3-1-1. Meta DB Config

@Configuration
public class MetaDBConfig {

    @Primary
    @Bean
    @ConfigurationProperties(prefix = "spring.datasource-meta")
    public DataSource metaDbSource(){
        return DataSourceBuilder.create().build();
    }

    @Primary
    @Bean
    public PlatformTransactionManager metaTransactionManager(){
        return new DataSourceTransactionManager(metaDbSource());
    }
}

스프링 부트에서 2개 이상 DB를 연결하려면 Config클래스 작성이 필수적이다. 그리고 충돌을 방지하기 위해 다중 DB를 연결하게 되면 어느 DB를 우선 해야하는지 정해야한다.

그렇지 않으면 어느 DB에 데이터를 저장하거나 읽거나 하는 등 작업을 할 수 없기에 에러가 발생하게 된다.

우선 순위를 지정하기 위해서는 @Primary 어노테이션을 사용하면 된다.

@ConfigurationProperties는 prefix로 지정해둔 경로의 값을 불러오는 어노테이션이다. 여기선 위에서 작성한 application.properties의 spring.datasource-meta 로 시작하는 변수의 값들을 불러오게 된다.

읽어온 값들을 DataSource로 반환하면 Meta 테이블의 스키마에 대한 데이터소스가 Bean으로 등록된다.

PlatformTransactionManager도 동일하게 충돌을 방지하기 위해 @Primary 어노테이션을 붙히고 metaDbSource를 매개변수로 지정해 생성해준다.

3-1-2. Data DB Config

@Configuration
@EnableJpaRepositories(
    basePackages = "com.study.stay.repository",
    entityManagerFactoryRef = "dataEntityManager",
    transactionManagerRef = "dataTransactionManager"
)
public class StayDBConfig {

    @Bean
    @ConfigurationProperties(prefix = "spring.datasource-data")
    public DataSource dataDBSource(){
        return DataSourceBuilder.create().build();
    }

    @Bean
    public LocalContainerEntityManagerFactoryBean dataEntityManager(){
        LocalContainerEntityManagerFactoryBean em = new LocalContainerEntityManagerFactoryBean();
        em.setDataSource(dataDBSource());
        em.setPackagesToScan(new String[]{"com.study.stay.entity"});
        em.setJpaVendorAdapter(new HibernateJpaVendorAdapter());

        HashMap<String, Object> properties = new HashMap<>();
        properties.put("hibernate.dialect", "org.hibernate.dialect.MySQLDialect");
        properties.put("hibernate.hbm2ddl.auto", "update");
        properties.put("hibernate.show_sql", "true");
        em.setJpaPropertyMap(properties);
        return em;
    }

    @Bean
    public PlatformTransactionManager dataTransactionManager(){
        JpaTransactionManager transactionManager = new JpaTransactionManager();
        transactionManager.setEntityManagerFactory(dataEntityManager().getObject());
        return transactionManager;
    }
}

Meta DB Config와 달리 설정해야할 내용이 조금 더 많다. 먼저 실제 Data가 저장되거나 하기 때문에 @EnableJpaRepositories 어노테이션을 붙히고 repository의 경로와 참조할 EntityManager와 TransactionManager의 메서드명을 지정한다. 해당 메서드 명은 Bean으로 만든 메서드이다.

DataSource는 MetaDBConfig와 동일하게 작성한다. 다만 prefix만 맞게끔 수정하면 된다.

LocalContainerEntityManagerFactoryBean은 위의 @EnableJpaRepositories에 작성했던 EntityManager와 동일한 이름의 메서드를 만들면된다.

em.setPackagesToScan(new String[]{"com.study.stay.entity"});

위의 내용은 해당 경로의 Entity Class들을 스캔한다.

아래 properteis의 경우, 다중 DB로 연결하게 되면 변수 설정으로는 어떠한 DB에 대한 설정인지 알 수 없기에 이 Config에 등록한다.

PlatformTransactionManager의 경우 JpaTransactionManager를 초기화 해서 반환해준다.

4. Batch 작성

(※ Batch 작성에 앞서 Entity의 내용들은 따로 적지 않습니다. 보고 싶으신 분들은 GitHub의 Repository를 봐주시면 감사하겠습니다. GitHub )

JobBuilder를 통해 stayInfoJob 이름을 가지며 stayInfoStep이라는 Step을 실행하는 형태의 Job을 생성한다.

incrementer는 작업이 여러번 실행될 때마다 고유한 실행 ID를 증가시키기 위해 사용한다.

    @Bean
    public Job stayInfoJob(JobRepository jobRepository, Step stayInfoStep) {
        return new JobBuilder("stayInfoJob", jobRepository)
            .incrementer(new RunIdIncrementer())
            .start(stayInfoStep)
            .build();
    }

    @Bean
    public Step stayInfoStep(
        JobRepository jobRepository,
        PlatformTransactionManager transactionManager,
        StepExecutionListener stayInfoStepListener,
        RepositoryItemWriter<StayInfo> stayInfoWriter
    ) {
        return new StepBuilder("stayInfoStep", jobRepository) // Step 이름 지정
            .<OpenApiResponse, StayInfo>chunk(10, transactionManager) // Chunk 기반 10개씩 나눠서 실행
            .reader(apiResponseReader()) // reader 지정
            .processor(stayInfoProcessor()) // processor 지정
            .writer(stayInfoWriter) // writer 지정
            .listener(stayInfoStepListener) // listener 지정 필요없으면 안해도 됨.
            .build();
    }

Step의 read - processor - writer단계이다. 아래 Processor와 Writer와 함께 대부분 익명함수를 사용한다고 한다. 로직이 길거나 복잡하면 클래스로 만들어서 사용하면 좋다. 자세한 코드 내용은 후술하겠다.

    @Bean
    public ItemReader<OpenApiResponse> apiResponseReader() {
        return new StayInfoReader();
    }

    @Bean
    public ItemProcessor<OpenApiResponse, StayInfo> stayInfoProcessor() {
        return new StayInfoProcessor();
    }

    @Bean
    public RepositoryItemWriter<StayInfo> stayInfoWriter() {
        return new RepositoryItemWriterBuilder<StayInfo>()
            .repository(stayInfoRepository)
            .methodName("save")
            .build();
    }

    @Bean
    public StayInfoStepListener stayInfoStepListener() {
        return new StayInfoStepListener(); // Open Api의 request에서 pageNo 필드 값을 증가시키기 위해 지정
    }

4-1. Reader

@Component
@Slf4j
public class StayInfoReader implements ItemReader<OpenApiResponse> {

    @Value("${api.uri}")
    private String apiUri;
    @Value("${api.auth-key}")
    private String authKey;
    @Autowired
    private ObjectMapper objectMapper;
    @Autowired
    private RestTemplate restTemplate;
    private static final String KEY_PAGE_NO = "pageNo";
    private int pageNo = 1;

  /*
   * Listener과 관련된 내용으로, pageNo값을 증가 시키기위해 ExceutionContext를 사용했다. 
   * context에 Key가 존재하면 해당 Value를 pageNo에 대입해 사용한다.
   */
    @BeforeStep
    public void beforeStep(StepExecution stepExecution){
        ExecutionContext context = stepExecution.getExecutionContext();

        if(context.containsKey(KEY_PAGE_NO)){
            pageNo = context.getInt(KEY_PAGE_NO);
        }else{
            context.put(KEY_PAGE_NO, pageNo);
        }
    }

    @Override
    public OpenApiResponse read() throws Exception{
        return getAllStayInfo();
    }

   /*
    *아래 내용은 OpenApi를 통해 Response를 읽어오는 내용이다.
    */
    public OpenApiResponse getAllStayInfo(){

        log.info("stay info read start.");

        try {
            URI uri = new URI(apiUri + "?serviceKey=" + authKey
                + "&numOfRows=" + 1000 + "&pageNo=" + pageNo + "&MobileOS=AND&MobileApp=TestApp&_type=json");

            ResponseEntity<String> responseEntity = restTemplate.getForEntity(uri, String.class);

            if(responseEntity.getStatusCode() == HttpStatus.OK){
                log.info("stay info read complete.");
                return objectMapper.readValue(responseEntity.getBody(), OpenApiResponse.class);
            }
        } catch (URISyntaxException | JsonProcessingException e) {
            throw new RuntimeException(e);
        }
        return new OpenApiResponse();
    }
}

4-2. Processor

Processor는 필요없으면 안해도 상관없지만 Open API의 Response에 사용하지 않을 값들을 삭제하는 가공 처리를 하고 Entity의 형태로 반환했다.

@Slf4j
public class StayInfoProcessor implements ItemProcessor<OpenApiResponse, StayInfo> {

    private Iterator<StayInfo> stayInfoIterator;

    @Override
    public StayInfo process(OpenApiResponse response) {
        log.info("process start.");
        List<Item> itemList = response.getResponse().body().items().item();

        stayInfoIterator = itemList.stream()
            .map(item -> StayInfo.from(
                item.title(),
                item.addr1(),
                item.addr2(),
                item.areacode(),
                item.sigungucode(),
                item.firstimage(),
                item.firstimage2(),
                item.mapy(),
                item.mapx(),
                item.mlevel(),
                item.tel(),
                item.likeCount(),
                item.rating()
            ))
            .iterator();

        log.info("process complete.");

         if( stayInfoIterator.hasNext() ){
          return stayInfoIterator.next();
        }
        return null;
    }
}

4-3 Listener

StepExecution의 경우 Step간의 정보 공유는 되지 않지만 아래 내용은 같은 Step 내부에서 동작하기에 pageNo를 증가 시킬 수 있다.

public class StayInfoStepListener implements StepExecutionListener {

    @Override
    public void beforeStep(StepExecution stepExecution) {
    }

    @Override
    public ExitStatus afterStep(StepExecution stepExecution) {
        ExecutionContext executionContext = stepExecution.getExecutionContext();
        int pageNo = executionContext.getInt("pageNo", 1);
        executionContext.put("pageNo", pageNo + 1);
        return ExitStatus.COMPLETED;
    }
}

5. Scheduler

아래는 스케줄러로 1분마다 Batch를 실행시키는 형태이다. @Scheduler 외에도 quartz scheduler로 Batch를 자동 실행할 수 있다.

@Slf4j
@Component
@RequiredArgsConstructor
public class BatchScheduler {

    private final JobLauncher jobLauncher;
    private final Job stayInfoJob;

    @Scheduled(cron = "0 0/1 * * * ?")
    public void runJob() {
        try {
            log.info("Batch job started.");

            SimpleDateFormat dateFormat = new SimpleDateFormat("yyyy-MM-dd HH-mm-ss");
            String date = dateFormat.format(new Date());

            JobParameters jobParameters = new JobParametersBuilder()
                .addString("date", date)
                .toJobParameters();

            log.info("Batch job is start.");
            jobLauncher.run(stayInfoJob, jobParameters);

            log.info("Batch job completed.");
        } catch (Exception e) {
            log.error("Batch job failed.", e);
        }
    }
}

6. 실행 결과

7. 회고

사용만 하던 Batch를 간략하게나마 정리할 수 있는 시간이 되었다. FastCampus에서 OpenAPI를 활용했을 때 Batch를 사용할까 라는 생각을 하긴 했었지만 담당 업무부터 팀장 대리역할을 하느라 Batch라는 생각이 바로 사라졌던 기억이 좀 아쉽다.

조만간 Batch 전략들에 대해 조금 더 알아보고자 한다. 수많은 데이터들을 일괄처리 하는 만큼 분명 성능 저하 등 개선이 필요한 이슈들이 있을텐데 어떻게 개선하면 좋을지 고민을 해보면 실무에서도 좋은 결과를 낼 수 있지 않을까 싶다.

실무에서 특정 테이블에 있는 레코드를 읽어와 재가공해 이력 테이블로 삽입하는 업무를 맡아 Batch를 활용해 처리한 경험이 있습니다. 하지만 당시에는 빠르게 처리하는 것만 생각해서 Batch 구조와 원리에 대해 신경을 쓰지 않았습니다.. 이제라도 Batch에 대해 공부하고 기록을 남기고자 합니다.

1. Spring Batch란

위의 첨부내용처럼 Batch는 일괄 처리 라는 단어적 의미를 갖고 있다. Spring Batch는 Batch Processing을 기반으로 로깅, 추적, 트랜잭션 관리, 작업 처리 통계, 작업 재시작, 건너뛰기, 리소스 관리를 포함하여 대량의 레코드를 처리하는 데 필수적인 재사용 가능한 기능을 제공한다. (출처 : https://spring.io/projects/spring-batch)

2. Spring Batch 구조

Flow를 확인해보면 Job Scheduler에서 지정된 일정에 맞춰 JobLauncher를 실행한다. JobLauncher에서는 Job을 실행시키고 Job에서는 Step을 실행한다. Step은 Tasklet과 Chunk기반으로 이루어져 있다. (위의 Flow는 Chunk기반이다.) Read ~ Write의 처리가 완료된 이후 다음 Step이 있다면 작업을 시작하고 없는 경우 Batch 작업을 종료한다.

2-1. Job

배치 처리 과정을 담은 하나의 단위로 즉, 배치 작업 자체를 의미한다. Job에는 1개 이상의 Step이 포함되어야 한다. 구현체로써는 SimpleJob과 FlowJob 등이 제공된다.

2-1-1. JobLauncher

• Job과 JobParameter를 사용해 Job을 실행시키는 객체.
• Batch 처리를 완료한 후 Client에 JobExecution을 리턴한다. (비동기도 가능)

2-1-2. JobInstance

• Job의 논리적 실행 단위 객체로 고유하게 식별 가능한 작업 실행.
• Job Name, Job Parameter 조합으로 인스턴스를 생성
• 동일한 Job Name, Job Parameter의 조합은 단 1개의 인스턴스만 생성 가능
• Job : JobInstance는 1:N의 관계

2-1-3. JobParameters

• Job 실행 시 사용되는 Parameter
• 여러 개의 JobInstance를 구분하기 위한 용도이다.
• JobParameters : JobInstance는 1:1의 관계

2-1-4. JobExecution

• JobInstance의 실행 시도 객체
• JobInstance의 실행 상태, 시작 및 종료, 생성 시간 등 정보를 저장
• ExitStatus가 FAILED일 경우 재실행 가능, COMPLITED인 경우 재실행 불가
• JobInstance : JobExecution은 1:N의 관계

2-1-5. JobRepository

• 모든 Batch 정보를 가지고 있는 메타 데이터 저장소
• Job이 실행되면 JobRepository에 JobExecution과 StepExecution을 생성한다.
  • 이후 JobRepository에서 Execution의 정보들을 DB에 저장 및 조회해 사용한다.

Job에 대한 자세한 내용은 아래 블로그를 참조하면 좋을 듯합니다. https://hoestory.tistory.com/40

2-2. Execution Context

• Framework에서 Execution의 상태를 저장하고 공유하는 객체
• Job의 재시작 시 이미 처리된 데이터는 스킵하고 이후 수행할 때 상태 정보를 활용한다.
• 종류로는 JobExecution과 StepExcution이 있다.
  • JobExecution : 각 Job에 생성되고 Job간의 공유는 불가능하다. 단, Job내부의 Step간의 공유는 가능하다.
  • StepExcution : 각 Step에 생성되고 Step간의 공유는 불가능하다.

2-3. StepExecution

• Step의 실행 시도 객체
• Step별로 StepExecution이 생성된다.
• JobExecution에 저장되는 정보 외에 Read, Write, Commit 수 등의 정보가 저장된다.
• Job이 재시작 되더라도 이미 성공한 Step은 스킵, 실패한 Step만 실행된다.
• Step의 StepExecution이 하나라도 실패한다면 JobExecution은 실패 처리가 된다.

2-4. Step

• Batch Job을 구성하는 하나의 실행 단위
• 하나의 Job은 여러 개의 Step으로 구성될 수 있다.
• Step은 Reader, Processor, Writer로 구성되어 있다.
• StepExecution을 통해 실행 상태 및 결과를 관리한다.
• 구현체로는 다음과 같다.
  • TaskletStep : 가장 기본이 되는 클래스. Tasklet 타입이 구현체를 제어
  • PartitionStep : 멀티 스레드 방식으로 Step을 여러 개 분리해서 실행
  • JobStep : Step 내에서 Job을 실행
  • FlowStep : Flow를 실행하는 Step

2-4-1 Tasklet

• Tasklet기반 Step은 Batch의 Step단계에서 단일 Task를 수행한다.

• TaskletStep에 의해 반복 실행되며 반환 값에 따라 실행 및 종료된다.
  • RepeatStatus.CONTINUABLE : 반복
  • RepeatStatus.FINISHED : 종료
• 단일 Task를 수행하기 때문에 Step과 Tasklet은 1:1의 관계를 가진다.

2-4-2 Chunk

• Chunk기반 Step은 Batch의 Step단계에서 처리할 레코드(한 덩어리)를 n개씩 나눠 수행한다.

• ItemReader, ItemProcessor, ItemWriter를 사용하며, ChunkOrientedTasklet가 제공된다.

2-4-2-1. ItemReader

ItemReader는 Chunk기반에서 처리할 데이터를 읽어오는 Interface이다. 구현체로는 다음과 같다.

• JDBC
  • Cursor : JdbcCursorItemReader
  • Paging : JdbcPagingItemReader
• JPA
  • Cursor : JpaCursorItemReader
  • Paging : JpaPagingItemReader
• Txt, CSV 등 : FlatFileItemReader
• Json : JsonItemReader
• 복수의 파일 조합 : MultiResourceItemReader
• Thread : SynchronizeditemStreamReader
• Custom : CustomItemReader

위의 JDBC와 JAP에서 Cursor와 Paging은 데이터를 조회하는 방식이다.

• Cursor

• 현재 행에 Cursor를 유지하며 다음 데이터를 호출할 시, 다음 행으로 Cursor를 이동하며 데이터 반환을 이루는 형태의 Streaming I/O

• DB Connection이 연결되면 Batch가 완료될 때까지 데이터를 읽어온다.

  • 따라서, DB Connection과 메모리가 충분해야 한다는 제한이 있다.

• Thread-safe하지 않다.

  • Paging

• 페이지 단위로 데이터를 조회하는 방식이며, Page Size만큼 한번에 데이터를 가지고 온다.

• 한 페이지를 읽을 때마다 DB Connection을 맺고 끊음

• Cursor와 다르게 페이지 단위로 가져오기 때문에 메모리 사용량이 적다는 이점이 있다.

• 다만, 데이터 정렬이 되어 있어야 문제 없이 사용할 수 있다.

• Thread-safe하다.

  정리한 걸 보았을 때는 Cursor보다 Paging방법이 여러모로 장점이 많아보인다. 하지만, DB Connection과 메모리가 충분하다면 Paging보다 Cursor방식이 더 빠르기도 한다.

2-4-2-2. ItemProcessor

ItemProccessor는 Chunk 단위로 읽어온 데이터를 필요에 따라 가공을 하는 단계이다. 가공을 통해 원하는 타입으로 데이터를 변환하거나 필터링하여 전달 가능 하다.

2-4-2-3. ItemWriter

ItemWriter는 Batch에서 출력 작업을 담당한다. Processor에서 가공된 데이터를 DB에 저장하거나, 원하는 포맷(TXT, CSV, JSON 등)에 맞춰 출력도 가능하다.

출력이 완료되면 Transaction이 종료되고 새로운 Chunk 단위의 프로세스로 이동해 작업을 이어한다.

구현체로는 다음과 같다.

• TXT, CSV 등 파일 : FlatFileItemWriter

• Json : JsonFileItemWriter
• JDBC : JdbcBatchItemWriter
• JPA : JpaItemWriter
• Custom : CustomItemWriter

2-5. Meta Table

위의 내용도 매우 중요하지만 이번 공부에 있어서 개인적으로 Meta Table이 Spring Batch에서 가장 중요하다고 생각했다. 사실상 위의 내용들은 개념 정도로 알고 Batch 전략에 맞춰서 또는 해야할 작업에 맞춰서 활용하면 된다. 하지만 작업을 실패하더라도 다시 실행한다던지, 이미 처리된 내용을 스킵하는 등 이러한 정보를 어디에 저장하고 어디서 가져오는지 이런 판단 요소들이 저장된 곳이 바로 Meta Table이기 때문이다.

2-5-1. Meta Table이란

스프링 배치 메타데이터 테이블은 Java에서 이를 나타내는 도메인 객체와 밀접하게 일치합니다. 예를 들어, JobInstance, JobExecution, JobParameters, StepExecution은 각각 BATCH_JOB_INSTANCE, BATCH_JOB_EXECION, BATCH_JOB_EXECION_PARAMS, BATCH_STEP_EXECION에 매핑됩니다. ExecutionContext는 BATCH_JOB_EXECONT와 BATCH_STEP_EXECONT에 매핑됩니다. JobRepository는 각 Java 객체를 올바른 테이블에 저장하고 저장하는 역할을 합니다. 이 부록에서는 메타데이터 테이블을 만들 때 내린 많은 설계 결정과 함께 자세히 설명합니다. 이 부록에서 설명하는 다양한 테이블 생성 문장을 볼 때, 사용되는 데이터 유형은 가능한 한 일반적이라는 점에 유의하세요. 스프링 배치는 많은 스키마를 예시로 제공합니다. 각 데이터베이스 공급업체가 데이터 유형을 처리하는 방식의 차이로 인해 모두 다양한 데이터 유형을 가지고 있습니다. 다음 이미지는 여섯 개의 테이블에 대한 ERD 모델과 그들 간의 관계를 보여줍니다 - Spring Boot 공식 문서 -

2-5-2. Meta Table ERD

BATCH_JOB_INSTANCE

• 특정 Job 인스턴스의 고유성 관리
  • Job Name, Job Parameter 조합으로 인스턴스를 생성
  • 동일한 Job Name, Job Parameter의 조합은 단 1개의 인스턴스만 생성 가능

BATCH_JOB_EXECUTION

• Job의 실행 정보를 저장
  • Job 생성 시간, 시작 시간, 종료 시간, 실행 상태, 실패 메세지 등을 관리
  • Job이 실행될 때마다 생성

BATCH_STEP_EXECUTION

• 각 Step의 실행 정보를 저장

BATCH_JOB_EXECUTION_PARAMS

• Job과 함께 실행되는 JobParameter의 정보를 관리

BATCH_JOB_EXECUTION_CONTEXT

• Job의 각 Step 실행 상태를 저장
• 모든 Step의 상태를 통합 관리

BATCH_STEP_EXECUTION_CONTEXT

• 각 Step의 실행 상태를 저장
• 스탭 실행의 메모리 상태를 직렬화하여 저장

SAGA Pattern을 설명하기 이전에 기존 모놀리식 아키텍처에서는 트랜잭션을 어떻게 처리를 했는지 또 마이크로 서비스 아키텍처에서 널리 사용되는 패턴 중 하나인 2PC에 대해 짚고 넘어가겠습니다.

1. 모놀리식 아키텍처에서의 트랜잭션 처리

이미지 출처 : https://blog.bitsrc.io/distributed-transactions-in-microservices-d07aba281f90

이와 같이 모놀리식 아키텍처에서는 요청을 보내면 DB에서 트랜잭션이 생성해 상태 확인이나 요청처리를 수행합니다. 수행이 정상적으로 이루어졌다면 해당 리스폰스가 반환이 되겠지만 이 과정에서 실패하게 된다면, 해당 트랜잭션은 롤백됩니다.

2. 마이크로 서비스 아키텍처에서의 트랜잭션 처리

MSA에서는 독립된 서비스들은 각자 별도의 DB를 구성되어 있습니다. 그렇기에 요청을 보내면 2개 이상의 서비스가 호출이 필요할 수 있는 상황이 생기고 각 DB에서 해당 요청 사항에 대한 처리를 해줘야 합니다.

하지만 독립된 서비스인만큼 ACID 트랜잭션을 유지하기 힘듭니다.

특히, transaction-1이 실패한 경우 transaction-2는 어떻게 처리할지 등 고려해야 합니다.

이러한 고려점에 대한 방안으로 2PC, SAGA Pattern이 있습니다.ㅣ

2-1. 2PC

이미지 출처 : https://timilearning.com/posts/mit-6.824/lecture-12-distributed-transactions/ 원본 출처 : Martin Kleppmann - 데이터 중심 애플리케이션 설계

Two-Phase Commit(2PC)는 분산 트랜잭션에서 원자성을 보장하는데 사용되는 프로토콜입니다. 분산 트랜잭션의 경우 2PC는 다음과 같이 동작합니다.

• DB는 트랜잭션을 담당하는 트랜잭션 코디네이터 라는 또 다른 엔티티를 추가합니다.
• 트랜잭션에 참여하는 다른 모든 서버를 참가자 라고 합니다.
• 트랜잭션 코디네이터는 먼저 트랜잭션의 쓰기 권한을 참여자에게 위임합니다. 각 참여자는 원래 트랜잭션에서 중첩된 트랜잭션을 만들고, Lock을 유지해야 할 수 있는 작업을 실행하고, 코디네이터에게 확인을 보냅니다.
• 코디네이터가 확인 메시지를 받으면 프로토콜의 첫 번째 단계가 시작됩니다. 이 단계에서 코디네이터는 참가자에게 PREPARE 메시지를 보냅니다. 그런 다음 각 참가자는 중첩된 트랜잭션의 결과에 따라 트랜잭션을 커밋하거나 중단할 준비가 되었는지 코디네이터에게 알려서 응답합니다.
• 참가자 중 누구라도 중단 메시지로 응답 하면 코디네이터는 전체 트랜잭션을 중단하기로 결정합니다. 코디네이터는 모든 참가자가 커밋할 준비가 된 경우에만 트랜잭션을 커밋합니다. 두 번째 단계는 코디네이터가 이러한 조건에 따라 전체 트랜잭션에 대한 COMMITTED 또는 ABORTED 레코드를 생성하고 해당 결과를 내구성 있는 로그에 저장할 때 시작됩니다. 그런 다음 해당 결정을 전체 트랜잭션의 결과로 참가자 노드에 전달합니다.

여기서 2PC는 다음과 같은 약속이 있습니다. 이러한 약속을 통해 2PC의 원자성이 보장됩니다.

1. 참가자가 YES를 응답했을 때 이후엔 반드시 커밋을 해야한다.
2. 코디네이터가 결정을 하면 반드시 결정을 강제해야한다.

단점

2PC의 가장 큰 단점은 코디네이터가 참가자에게 결과를 전달하기 전에 실패하면 참가자가 대기 상태에 갇힐 수 있다는 것입니다. 커밋할 준비가 되었다고 표시한 참가자는 다른 참가자가 중단할 준비가 되어 있을 수 있으므로 스스로 트랜잭션의 결과를 결정할 수 없습니다. 또한, 갇힌 참가자는 코디네이터가 충돌하기 전에 다른 참가자에게 커밋 메시지를 보냈을 수 있으므로 스스로 트랜잭션을 중단할지 결정할 수 없습니다.

이 방법은 참가자가 대기 상태에 갇혀 있는 동안 공유 객체에 대한 Lock을 유지할 수 있으므로 이상적이지 않습니다. 이로 인해 다른 트랜잭션이 진행되지 못할 수 있습니다.

2-2. SAGA Pattern

SAGA는 일련의 로컬 트랜잭션입니다. 각 로컬 트랜잭션은 익숙한 ACID 트랜잭션 프레임워크를 사용하여 로컬 데이터베이스를 업데이트하고 이벤트를 게시하여 사가의 다음 로컬 트랜잭션을 트리거합니다. 로컬 트랜잭션이 실패하면 사가는 일련의 보상 트랜잭션을 실행하여 이전 로컬 트랜잭션에서 완료한 변경 사항을 취소합니다.

이는 비동기적이며 일관된 트랜잭션 방식으로, 분산 트랜잭션이 관련 마이크로서비스의 비동기 트랜잭션에 의해 실행되는 전형적인 마이크로서비스 애플리케이션 아키텍처와 매우 유사합니다.

SAGA 메시지의 비동기적인 특성의 큰 장점은 SAGA의 일부 참가자가 일시적으로 사용 불가능하더라도 모든 단계가 실행되도록 보장한다는 점입니다. 또한, 다른 마이크로서비스나 객체를 방해하지 않고 장기적인 트랜잭션도 처리할 수 있습니다.

또한 SAGA Pattern에는 Orchestration과 Choreography 2종류가 존재합니다.

2-2-1. Orchestration SAGA Pattern

이미지 출처 : https://medium.com/cloud-native-daily/microservices-patterns-part-04-saga-pattern-a7f85d8d4aa3

Orchestration SAGA Pattern은 분산 트랜잭션을 관리하는 방식으로, 중앙 조정자(Orchestrator)가 각 서비스의 작업을 순차적으로 지시하고 관리하는 패턴입니다. 중앙 조정자가 트랜잭션의 전체 흐름을 제어하며, 각 서비스는 중앙 조정자로부터 명령을 받아 수행합니다.

그림에서 볼 수 있듯이, Micro service 01에 구현된 SAGA Orchestrator가 SAGA 트랜잭션(예: 주문 생성 SAGA)을 시작합니다. 앞서 설명한 것처럼, 상호작용 방식은 비동기 요청/응답 방식이며, 요청은 "명령 메시지"로 전달됩니다. 비동기 요청/응답 방식을 사용하기 때문에, 메시지 브로커 내에서 별도의 요청 및 응답 채널을 사용합니다.

Micro service 01이 create() 요청을 받으면, SAGA Orchestrator가 생성됩니다. 이 Orchestrator는 전체 승인이 완료될 때까지 서비스 요청을 PENDING 상태로 설정합니다. 이 과정에서 SAGA Orchestrator는 Micro service 2와 3에 명령 요청을 보내고, 메시지 브로커의 SAGA Orchestrator 응답 채널을 통해 응답을 받습니다. 두 응답의 결과에 따라 Orchestrator는 요청을 승인하거나 거부하게 됩니다.

장점

• 더 간단한 의존성: Orchestrator가 항상 SAGA 참가자들을 호출하고, 그 반대는 발생하지 않으므로 순환 의존성이 없습니다.

• 결합도 감소: Choreography SAGA Pattern과는 달리, 다른 SAGA 참가자들이 발행하는 이벤트나 구현된 비즈니스 로직에 대해 알 필요가 없습니다. 이렇게 하면 결합도가 낮아지고 비즈니스 로직이 훨씬 단순해집니다.

단점

• Orchestrator 수준에서의 비즈니스 로직 감소: SAGA 오케스트레이터 내에 비즈니스 로직을 포함하지 않도록 하여 더 낮은 결합도를 유지하는 것이 좋습니다. 관련 서비스 외부에 비즈니스 로직을 두는 것은 바람직하지 않으며, Orchestrator 비즈니스 로직을 포함하는 것은 권장되지 않습니다.

• 격리성 부족: 전반적으로 마이크로서비스 아키텍처는 전통적인 ACID 트랜잭션에 비해 격리성이 부족합니다. 이는 SAGA 참가자들이 전체 트랜잭션이 완료되기 전에 로컬 트랜잭션으로 변경 사항을 커밋하기 때문에 발생합니다. 이로 인해 데이터베이스 레벨에서 불일치가 생길 수 있습니다.

• 단일 장애 지점: 중앙 조정자가 실패하면 전체 트랜잭션 흐름이 중단될 수 있습니다.

2-2-2. Choreography SAGA Pattern

이미지 출처 : https://medium.com/cloud-native-daily/microservices-patterns-part-04-saga-pattern-a7f85d8d4aa3

Choreography SAGA Pattern의 방식에서는 Orchestration SAGA와 달리, SAGA 참가자들에게 무엇을 해야 할지 지시하는 중앙 조정자가 없습니다. SAGA 참가자들은 서로의 이벤트를 구독하고 그에 맞게 대응합니다. 이에 따라 롤백에 대한 책임도 각 SAGA 참가자들에게 있습니다.

장점

• Orchestration SAGA Pattern에 비해 로직을 구성하기 편합니다.

• 비즈니스 흐름의 자연스러운 표현: 이벤트 기반의 상호작용을 통해 비즈니스 흐름을 자연스럽게 표현할 수 있어, 시스템의 가독성이 향상됩니다.

단점

• 흐름 이해의 어려움: 일반적으로 이 방식은 SAGA 구현을 서비스 간에 분산시킵니다. 따라서 SAGA 흐름을 정의할 중앙집중적인 장소가 없습니다.

• 서비스 간 순환 의존성: SAGA 참가자 간에 순환 의존성이 발생할 가능성이 있으며, 예를 들어 Micro service 01 → Micro service 02 → Micro service 01과 같은 형태가 될 수 있습니다.

• 높은 결합도의 위험: 자신들에게 영향을 미치는 모든 이벤트를 구독해야 하므로 서비스 간 결합도가 높아질 위험이 있습니다.

정리

Chreography나 Orchestration중 어떤게 좋냐 라기보단 상황에 맞춰서 적용하는 것이 가장 좋습니다.

Chreography는 다음과 같은 이유로 규모가 작은 애플리케이션에 적용하기 좋습니다.

• 규모가 작으면 흐름을 읽기 힘들정도로 복잡해지는 경우가 없습니다.

• 서비스들의 이벤트를 서로 구독하고 이벤트 처리를 해주면 되기에 로직자체는 비교적 간단합니다.

Orchestration의 경우는 대규모 애플리케이션이 좀 더 적용하기 좋습니다.

• Orchestrator가 트랜잭션의 흐름을 관리하게 되므로, 복잡한 비즈니스 로직을 효과적으로 관리할 수 있습니다.

• Orchestrator가 오류를 중앙에서 처리할 수 있어 일관된 오류 처리가 가능합니다.

Choreography SAGA Pattern 적용하기

저의 경우 위에 언급했듯이 규모가 작은 애플리케이션이기에 Chreography SAGA Pattern을 적용하기로 했습니다. 그외의 이유로는 Orchestrator를 구현할 만큼 시간적 여유가 많지 않다라는 점과 당장 적용하기에는 Orchestration SAGA Pattern의 학습 곡선이 높다는 이유가 있었습니다.

Producer

1. Configuration 작성

@Configuration
public class KafkaProducerConfig {

    @Value("${spring.kafka.producer.bootstrap-servers}")
    private String bootstrapServers;
    @Value("${spring.kafka.producer.key-serializer}")
    private String keySerializer;
    @Value("${spring.kafka.producer.value-serializer}")
    private String valueSerializer;

    @Bean
    public ProducerFactory<String, Object> producerFactory() {
        Map<String, Object> configMap = new HashMap<>();
        configMap.put(ProducerConfig.BOOTSTRAP_SERVERS_CONFIG, bootstrapServers);
        configMap.put(ProducerConfig.KEY_SERIALIZER_CLASS_CONFIG, keySerializer);
        configMap.put(ProducerConfig.VALUE_SERIALIZER_CLASS_CONFIG, valueSerializer);
        return new DefaultKafkaProducerFactory<>(configMap);
    }

    @Bean
    public KafkaTemplate<String, Object> kafkaTemplate() {
        return new KafkaTemplate<>(producerFactory());
    }
}

2. Dto 작성하기

ReservationMessageResponse.java

public record ReservationMessageResponse(@JsonProperty("reservationId") Long reservationId,
                                         @JsonProperty("status") ReservationStatus status,
                                         @JsonProperty("message") String message) {

} ,

ReservationStatus.java

@Getter
@AllArgsConstructor
public enum ReservationStatus {

    PENDING("예약 대기"),
    SUCCESS("예약 성공"),
    CANCEL("예약 취소"),
    FAILURE("예약 실패");

    private final String message;
}

3. Producer 관련 클래스 작성하기

@Component
@RequiredArgsConstructor
public class TransactionProducer {

    private static final String TOPIC_RESERVATION_TRANSACTION_RESULT = "reservation-transaction-result";
    private final KafkaTemplate<String, Object> kafkaTemplate;
    private final ObjectMapper objectMapper;

    public void sendTransactionResult(final ReservationMessageResponse responseMessage)
        throws JsonProcessingException {
        final String message = objectMapper.writeValueAsString(responseMessage);
        kafkaTemplate.send(TOPIC_RESERVATION_TRANSACTION_RESULT, message);
    }

}

4. 기존 Consumer 로직 수정

@Component
@RequiredArgsConstructor
public class ReservationConsumer {

    private final RoomService roomService;
    private final TransactionProducer transactionProducer;
    private final ObjectMapper objectMapper;

    @KafkaListener(topics = "room-reserve", groupId = "reservation-group")
    public void consumeReservationEvent(final String reservationMessage)
        throws JsonProcessingException {
        final ReservationMessage message = objectMapper.readValue(reservationMessage,
            ReservationMessage.class);

        try {
            roomService.decreaseCountByOne(message.roomId(), message.checkInDate(),
                message.checkOutDate());
            final ReservationMessageResponse response = new ReservationMessageResponse(
                message.reservationId(), ReservationStatus.SUCCESS,
                StringUtils.EMPTY);
            transactionProducer.sendTransactionResult(response);

        } catch (Exception e) {
            final ReservationMessageResponse response = new ReservationMessageResponse(
                message.reservationId(), ReservationStatus.FAILURE,
                e.getMessage());
            transactionProducer.sendTransactionResult(response);
        }
    }

    ...

}

5. room-dev.yml

## msa server-dev
server:
  port: 8084

## db
spring:

    ...

  kafka:
    ## kafka consumer
    consumer:
      bootstrap-servers: localhost:9092
      group-id: reservation-group
      key-deserializer: org.apache.kafka.common.serialization.StringDeserializer
      value-deserializer: org.apache.kafka.common.serialization.StringDeserializer

    ## kafka producer
    producer:
      bootstrap-servers: localhost:9092
      key-serializer: org.apache.kafka.common.serialization.StringSerializer
      value-serializer: org.apache.kafka.common.serialization.StringSerializer

Consumer

1. Configuration 작성

@Configuration
public class KafkaConsumerConfig {

    @Value("${spring.kafka.consumer.bootstrap-servers}")
    private String bootstrapServers;
    @Value("${spring.kafka.consumer.group-id}")
    private String groupId;
    @Value("${spring.kafka.consumer.key-deserializer}")
    private String keyDeserializer;
    @Value("${spring.kafka.consumer.value-deserializer}")
    private String valueDeserializer;

    @Bean
    public ConsumerFactory<String, Object> consumerFactory() {
        Map<String, Object> configMap = new HashMap<>();
        configMap.put(ConsumerConfig.BOOTSTRAP_SERVERS_CONFIG, bootstrapServers);
        configMap.put(ConsumerConfig.GROUP_ID_CONFIG, groupId);
        configMap.put(ConsumerConfig.KEY_DESERIALIZER_CLASS_CONFIG, keyDeserializer);
        configMap.put(ConsumerConfig.VALUE_DESERIALIZER_CLASS_CONFIG, valueDeserializer);
        return new DefaultKafkaConsumerFactory<>(configMap);
    }

    @Bean
    public ConcurrentKafkaListenerContainerFactory<String, Object> kafkaListenerContainerFactory() {
        final ConcurrentKafkaListenerContainerFactory<String, Object> factory = new ConcurrentKafkaListenerContainerFactory<>();
        factory.setConsumerFactory(consumerFactory());
        return factory;
    }
}

2. Dto 작성하기

ReservationMessageResponse.java

public record ReservationMessageResponse(@JsonProperty("reservationId") Long reservationId,
                                         @JsonProperty("status") ReservationStatus status,
                                         @JsonProperty("message") String message) {

}

ReservationStatus.java

@Getter
@AllArgsConstructor
public enum ReservationStatus {

    PENDING("예약 대기"),
    SUCCESS("예약 성공"),
    CANCEL("예약 취소"),
    FAILURE("예약 실패");

    private final String message;
}

3. Consumer 관련 클래스 작성하기

@Slf4j
@Component
@RequiredArgsConstructor
public class TransactionConsumer {

    private final ReservationRepository reservationRepository;
    private final ObjectMapper objectMapper;

    @Transactional
    @KafkaListener(topics = "reservation-transaction-result", groupId = "reservation-transaction-result-group")
    public void consumeReservationTransactionResultEvent(final String roomResponseMessage)
        throws JsonProcessingException {
        final ReservationMessageResponse response = objectMapper.readValue(roomResponseMessage,
            ReservationMessageResponse.class);

        if (response.status() == ReservationStatus.FAILURE) {
            reservationRepository.updateStatusToFailureById(response.reservationId());
            log.info("Reservation transaction failed with Id And Message. ID : {}, MESSAGE {}",
                response.reservationId(), response.message());
            return;
        } else if (response.status() == ReservationStatus.CANCEL) {
            reservationRepository.deleteById(response.reservationId());
            log.info("Reservation cancel transaction with Id And Message. ID : {}, MESSAGE {}",
                response.reservationId(), response.message());
            return;
        }
        reservationRepository.updateStatusToSuccessById(response.reservationId());
    }
}

4. reservation-dev.yml

## msa server-dev
server:
  port: 8083

## db
spring:

  ...

  kafka:
    ## kafka producer
    producer:
      bootstrap-servers: localhost:9092
      key-serializer: org.apache.kafka.common.serialization.StringSerializer
      value-serializer: org.apache.kafka.common.serialization.StringSerializer

    ## kafka consumer
    consumer:
      bootstrap-servers: localhost:9092
      group-id: reservation-transaction-result-group
      key-deserializer: org.apache.kafka.common.serialization.StringDeserializer
      value-deserializer: org.apache.kafka.common.serialization.StringDeserializer

Kafka는 실시간으로 기록 스트림을 게시, 구독, 저장 및 처리할 수 있는 분산형 데이터 스트리밍 플랫폼입니다. 여러 소스에서 데이터 스트림을 처리하고 여러 사용자에게 전달하도록 설계되었습니다.

Kafka는 전통적인 엔터프라이즈 메시징 시스템의 대안입니다. 하루에 1조 4천억 건의 메시지를 처리하기 위해 LinkedIn이 개발한 내부 시스템으로 시작했으나, 현재 이는 다양한 기업의 요구 사항을 지원하는 애플리케이션을 갖춘 오픈소스 데이터 스트리밍 솔루션이 되었습니다.

이미지 출처 : https://securityboulevard.com/2024/01/what-is-kafka/

Kafka 적용하기

패스트 캠퍼스 기업연계 파이널 프로젝트를 드랍하고 개인 프로젝트로 진행을 했기에 아쉽게도 서버비용 지원이 없습니다. 맘같아선 Kafaka Cluster로 구현해 좀 더 제대로 사용해보고 싶었지만 싱글 노드로나마 구축했습니다.

Producer

1. 의존성 추가

dependencies {

    ...

    // kafka
    implementation 'org.springframework.kafka:spring-kafka'
    testImplementation 'org.springframework.kafka:spring-kafka-test'
}

tasks.named('test') {
    useJUnitPlatform()
}

tasks.register("prepareKotlinBuildScriptModel") {}

bootJar {
    enabled = true
}

jar {
    enabled = false
}

2. Configuration 클래스 작성

@Configuration
public class KafkaProducerConfig {

    @Value("${spring.kafka.producer.bootstrap-servers}")
    private String bootstrapServers;
    @Value("${spring.kafka.producer.key-serializer}")
    private String keySerializer;
    @Value("${spring.kafka.producer.value-serializer}")
    private String valueSerializer;

    @Bean
    public ProducerFactory<String, Object> producerFactory() {
        Map<String, Object> configMap = new HashMap<>();
        configMap.put(ProducerConfig.BOOTSTRAP_SERVERS_CONFIG, bootstrapServers);
        configMap.put(ProducerConfig.KEY_SERIALIZER_CLASS_CONFIG, keySerializer);
        configMap.put(ProducerConfig.VALUE_SERIALIZER_CLASS_CONFIG, valueSerializer);
        return new DefaultKafkaProducerFactory<>(configMap);
    }

    @Bean
    public KafkaTemplate<String, Object> kafkaTemplate() {
        return new KafkaTemplate<>(producerFactory());
    }
}

환경 변수로 받아온 값들을 ConfigMap에 저장해 KafkaProducerFactory를 생성하고 KafkaTemplate Bean에 담아 반환하도록 합니다.

3. Dto 클래스 작성

아래 Dto는 Producer와 Consumer 동일하게 작성합니다.

public record ReservationMessage(@JsonProperty("reservationId") Long reservationId,
                                 @JsonProperty("roomId") Long roomId,
                                 @JsonProperty("checkInDate") LocalDate checkInDate,
                                 @JsonProperty("checkOutDate") LocalDate checkOutDate) {

}

객실 서비스에서 데이터 조회 및 처리를 하기위해 해당 객실ID와 체크인, 체크아웃으로 특정 할 수 있도록 지정했습니다.

4. Producer 관련 클래스 작성

@Component
@RequiredArgsConstructor
public class ReservationProducer {

    private static final String RESERVATION_TOPIC = "room-reserve";
    private static final String CANCEL_TOPIC = "room-cancel";

    private final KafkaTemplate<String, Object> kafkaTemplate;
    private final ObjectMapper objectMapper;

    public void sendReservation(final Long reservationId, final Long roomId,
        final LocalDate checkIn,
        final LocalDate checkOut) throws JsonProcessingException {
        final ReservationMessage message = new ReservationMessage(reservationId, roomId, checkIn,
            checkOut);
        kafkaTemplate.send(RESERVATION_TOPIC, objectMapper.writeValueAsString(message));
    }

    public void sendCancelReservation(final Long reservationId, final Long roomId,
        final LocalDate checkIn,
        final LocalDate checkOut) throws JsonProcessingException {
        final ReservationMessage message = new ReservationMessage(reservationId, roomId,
            checkIn,
            checkOut);
        kafkaTemplate.send(CANCEL_TOPIC, objectMapper.writeValueAsString(message));
    }
}

Producer에는 두 가지 토픽(예약, 예약 취소)에 대한 이벤트를 발행합니다.

이 때 ReservationMessage Dto에 필요한 내용을 담아 토픽을 설정한 후 메세지로 보내줍니다.

5. 예약 서비스 - Service 로직 추가

@Slf4j
@Service
@RequiredArgsConstructor
public class ReservationService {

    private final ReservationProducer reservationProducer;

    @Transactional
    public ReservationResponse reserve(ReservationRequest request,
        Long memberId) throws JsonProcessingException {

        ...

        Reservation saved = reservationRepository.save(reservation);

        reservationProducer.sendReservation(saved.getId(), request.getRoomId(), checkInDate,
            checkOutDate);

        return ReservationResponse.from(saved);
    }
}

예약 서비스 레이어에서 ReservationProducer를 의존성 주입해 전역변수로 선언하고 reserve 메서드에서 sendReservation 메서드를 호출해 처리했습니다.

6. application.yml

spring:
  application:
    name: ${RESERVATION_APP_NAME}
  profiles:
    active: ${APP_PROFILE}
  config:
    import: optional:configserver:${CONFIG_SERVER_URI}

7. accommodation-dev.yml ( Config Server )

## msa server-dev
server:
  port: 8083

  ...

  kafka:
    ## kafka producer
    producer:
      bootstrap-servers: localhost:9092
      key-serializer: org.apache.kafka.common.serialization.StringSerializer
      value-serializer: org.apache.kafka.common.serialization.StringSerializer

Consumer

1. 의존성 추가

dependencies {

    ...

    // kafka
    implementation 'org.springframework.kafka:spring-kafka'
    testImplementation 'org.springframework.kafka:spring-kafka-test'
}

tasks.named('test') {
    useJUnitPlatform()
}

tasks.register("prepareKotlinBuildScriptModel") {}

bootJar {
    enabled = true
}

jar {
    enabled = false
}

2. Configuration 클래스 작성

@Configuration
public class KafkaConsumerConfig {

    @Value("${spring.kafka.consumer.bootstrap-servers}")
    private String bootstrapServers;
    @Value("${spring.kafka.consumer.group-id}")
    private String groupId;
    @Value("${spring.kafka.consumer.key-deserializer}")
    private String keyDeserializer;
    @Value("${spring.kafka.consumer.value-deserializer}")
    private String valueDeserializer;

    @Bean
    public ConsumerFactory<String, Object> consumerFactory() {
        Map<String, Object> configMap = new HashMap<>();
        configMap.put(ConsumerConfig.BOOTSTRAP_SERVERS_CONFIG, bootstrapServers);
        configMap.put(ConsumerConfig.GROUP_ID_CONFIG, groupId);
        configMap.put(ConsumerConfig.KEY_DESERIALIZER_CLASS_CONFIG, keyDeserializer);
        configMap.put(ConsumerConfig.VALUE_DESERIALIZER_CLASS_CONFIG, valueDeserializer);
        return new DefaultKafkaConsumerFactory<>(configMap);
    }

    @Bean
    public ConcurrentKafkaListenerContainerFactory<String, Object> kafkaListenerContainerFactory() {
        final ConcurrentKafkaListenerContainerFactory<String, Object> factory = new ConcurrentKafkaListenerContainerFactory<>();
        factory.setConsumerFactory(consumerFactory());
        return factory;
    }
}

Producer와 다르게 Consumer에서는 Group에 대한 내용이 등장하는데 동일한 토픽을 구독하고 있는 컨슈머의 집합입니다. 예를들어 어느 상품의 주문이 생성되었다는 이벤트가 발행되면 해당 상품 주문이라는 토픽의 컨슈머 그룹에 속해 있는 재고 관리 서비스, 결제 서비스 등이 각자 비즈니스 로직을 수행할 수 있습니다.

3. Dto 클래스 작성

Consumer에서도 Producer와 동일한 내용의 Message Dto를 작성합니다.

public record ReservationMessage(@JsonProperty("reservationId") Long reservationId,
                                 @JsonProperty("roomId") Long roomId,
                                 @JsonProperty("checkInDate") LocalDate checkInDate,
                                 @JsonProperty("checkOutDate") LocalDate checkOutDate) {

}

4. Consumer 관련 클래스 작성

@Component
@RequiredArgsConstructor
public class ReservationConsumer {

    private final RoomService roomService;
    private final TransactionProducer transactionProducer;
    private final ObjectMapper objectMapper;

    @KafkaListener(topics = "room-reserve", groupId = "reservation-group")
    public void consumeReservationEvent(final String reservationMessage)
        throws JsonProcessingException {
        final ReservationMessage message = objectMapper.readValue(reservationMessage,
            ReservationMessage.class);

        try {
            roomService.decreaseCountByOne(message.roomId(), message.checkInDate(),
                message.checkOutDate());
            final ReservationMessageResponse response = new ReservationMessageResponse(
                message.reservationId(), ReservationStatus.SUCCESS,
                StringUtils.EMPTY);
            transactionProducer.sendTransactionResult(response);

        } catch (Exception e) {
            final ReservationMessageResponse response = new ReservationMessageResponse(
                message.reservationId(), ReservationStatus.FAILURE,
                e.getMessage());
            transactionProducer.sendTransactionResult(response);
        }
    }

    @KafkaListener(topics = "room-cancel", groupId = "reservation-group")
    public void consumeReservationCancelEvent(final String cancelMessage)
        throws JsonProcessingException {
        final ReservationMessage message = objectMapper.readValue(cancelMessage,
            ReservationMessage.class);

        roomService.increaseCountByOne(message.roomId(), message.checkInDate(),
            message.checkInDate());
        final ReservationMessageResponse response = new ReservationMessageResponse(
            message.reservationId(), ReservationStatus.CANCEL, StringUtils.EMPTY);
        transactionProducer.sendTransactionResult(response);
    }
}

이벤트가 발행되어 메세지를 수신하게 되면 해당 메세지를 해석하고 관련된 비즈니스 로직을 수행하도록 합니다.

로직에서 소개하지 않은 내용들이 일부 있는데 이는 SAGA Pattern과 관련된 이야기로 이후에 다루도록 하겠습니다.

5. application.yml

spring:
  application:
    name: ${ROOM_APP_NAME}
  profiles:
    active: ${APP_PROFILE}
  config:
    import: optional:configserver:${CONFIG_SERVER_URI}

6. room-dev.yml ( Config Server )

## msa server-dev
server:
  port: 8084

  ...

  kafka:
    ## kafka consumer
    consumer:
      bootstrap-servers: localhost:9092
      group-id: reservation-group
      key-deserializer: org.apache.kafka.common.serialization.StringDeserializer
      value-deserializer: org.apache.kafka.common.serialization.StringDeserializer

마무리

다음은 Choreography SAGA Pattern과 적용법에 대해 포스팅해보겠습니다.

Spring Cloud OpenFeign은 Spring Cloud 프로젝트에 포함된 동기 통신 클라이언트로, 선언적 REST 클라이언트로서 웹 서비스 클라이언트 작성을 보다 쉽게 할 수 있습니다.

직접 RestTemplate을 호출해서 대상 서버에게 통신을 요청하는 기존 방식과는 달리 인터페이스로 선언만 해두면 자동으로 구현체가 생성되는 형식입니다.

OpenFeign을 사용하는 이유

프로젝트 기획상 숙소 조회시 체크인, 체크아웃, 인원수 등을 조건으로 조회하는 경우 객실 데이터가 필요합니다. 이 경우 어떻게 결합도를 낮춘 상태로 다른 서비스의 정보를 조회가 가능할까 고민을 했고, 그 결과 다음과 같은 방법들이 존재한다는 것을 알게 되었습니다.

• 동기 방식

  • OpenFeign
  • RestTemplate

• 비동기 방식

  • Spring WebClient

이 중 OpenFeign을 고른 기준은 다음과 같습니다.

• 애플리케이션의 규모가 크다 / 작다 -> 작다
• 당장 적용할 수 있을 정도로 학습 곡선이 낮은가 / 높은가 -> 낮다

이외에는 Spring Cloud환경에서 MSA를 구축하고 있는데 OpenFeign의 경우 Spring Cloud와의 통합을 지원하여 마이크로서비스 아키텍처에서 유용하다는 점에 선택을 했습니다.

OpenFeign 적용하기

1. 의존성 추가

 dependencies {

    --- 중략 ---

    // spring cloud openfeign client
    implementation 'org.springframework.cloud:spring-cloud-starter-openfeign'

}

tasks.named('test') {
    useJUnitPlatform()
}

tasks.register("prepareKotlinBuildScriptModel") {}

bootJar {
    enabled = true
}

jar {
    enabled = false
}

숙소 서비스에 openfeign client 의존성을 주입합니다.

2. 숙소와 객실간을 통신할 Dto 작성

아래 작성된 ResponseDto의 경우 객실 서비스에도 동일한 Response가 필요합니다.

@Getter
@AllArgsConstructor
@NoArgsConstructor
public class RoomDetailResponse {

    private Long id;

    private String name;

    private String accommodationName;

    private String description;

    private int totalPrice;

    private int price;

    private int numberOfStay;

    private int standardNumber;

    private int maximumNumber;

    private int roomCount;

    private String type;

    private List<String> roomImageList;

    private RoomOptionResponse productOption;
}

3. OpenFeign Client 클래스 작성

 @FeignClient(value = "room-service", url = "${spring.cloud.openfeign.dest-room-url}")
public interface RoomClient {

    @GetMapping("/api/accommodation/{accommodationId}/room-details")
    List<RoomDetailResponse> getRoomDetailList(
        @PathVariable Long accommodationId,
        @RequestParam(required = false) LocalDate checkInDate,
        @RequestParam(required = false) LocalDate checkOutDate,
        @RequestParam(defaultValue = "2") int personNumber
    );
}

${spring.cloud.openfeign.dest-room-url}은 해당 서비스의 host:port이므로 http://localhost:8084 와 같이 해당 서비스의 port까지 적으면 됩니다.

그리고 getRoomDetailList 메서드의 경우 객실 서비스에 실제 존재하는 API이고 숙소 서비스에서 해당 API에 요청을 보내 필요한 정보를 RoomDetailResponse Dto로 반환받게 됩니다.

4. Service 로직 작성

@Service
@RequiredArgsConstructor
public class AccommodationService {

    private final AccommodationRepository accommodationRepository;
    private final AccommodationImageRepository accommodationImageRepository;
    private final RoomClient roomClient;

    --- 생략 ---
    private boolean hasValidRooms(Accommodation accommodation, LocalDate checkInDate,
        LocalDate checkOutDate, Integer personNumber) {
        List<RoomDetailResponse> roomEntityList = roomClient.getRoomDetailList(
            accommodation.getId(), checkInDate, checkOutDate, personNumber);

        return roomEntityList.stream()
            .anyMatch(room -> room.getRoomCount() > 0);
    }
}

3에서 작성한 Client를 Service에 의존성 주입을 하고 해당 인터페이스의 메서드를 호출하면 됩니다.

※ 실제 사용되는 내용에 비해 Response에 담기는 정보가 많습니다만.. 이후 재사용 또는 확장을 염두해두고 작성했으니 양해바라겠습니다.

5. OpenFeign 활성화

@EnableFeignClients
@EnableDiscoveryClient
@SpringBootApplication
public class AccommodationServiceApplication {

    public static void main(String[] args) {
        SpringApplication.run(AccommodationServiceApplication.class, args);
    }

}

OpenFeign을 사용하기 위해선 메인 클래스에서 @EnableFeignClients 어노테이션을 추가해 활성화하면 됩니다.

동작 확인

아래와 같은 조건으로 숙소 조회 API를 호출하겠습니다.

숙소 조회 API가 호출되었을 때 OpenFeign Client 로직 결과를 확인해보면 정상적으로 통신이 되어 해당 Response Dto를 반환받은 것을 확인 할 수 있습니다.

숙소 조회 API의 결과 입니다.

마무리

다음은 Kafka에 대해 포스팅해보겠습니다.

Spring Framwork가 제공하는 라이브러리로 Spring WebFlux 또는 Spring WebMVC에 API Gateway를 구축하기 위해 사용됩니다. Spring Cloud Gateway는 API로 라우팅하고 보안, 모니터링/메트릭, 복원성과 같은 횡단적 관심사를 제공합니다.

이미지 출처 : https://kyhslam.tistory.com/entry/Spring-Cloud-Gateway-Load-Balancer

Spring Cloud Gateway 구축

클라이언트가 서비스를 이용하게 될 때 해당 유저가 인증된 유저인지 또는 특정 서비스를 이용할 권한을 가졌는지 판단을 하고 그 이후 서비스로 연결해주게 됩니다.

그래서 저는 Filter를 구현하고 Cookie로 내려보낸 Access Token을 가져와 유효성 검사를 실시 후 정상인 경우 memberId를 추출합니다. 추출한 memberId는 header에 member-id라는 이름으로 저장해 회원 정보가 필요한 서비스에서 해당 member-id를 이용할 수 있게 했습니다.

Gateway service에서 작성할 내용은 다음과 같습니다.

• 필터 관련

  • Global Filter
  • AuthorizationFilter

• Cookie & JWT 관련

  • CookieProvider
  • JwtProvider

• 예외 관련

  • GlobalExceptionHandler
  • ExceptionHandlerConfig
  • AuthException

• API Limiter 관련

  • TokenKeyConfig

1. 의존성 주입

build.gradle

ext {
    set('springCloudVersion', "2023.0.3")
}

dependencies {

    // jwt
    implementation 'io.jsonwebtoken:jjwt-api:0.11.2'
    implementation 'io.jsonwebtoken:jjwt-impl:0.11.2'
    implementation 'io.jsonwebtoken:jjwt-jackson:0.11.2'

    // spring cloud config
    implementation 'org.springframework.cloud:spring-cloud-starter-config'

    // spring cloud gateway
    implementation 'org.springframework.cloud:spring-cloud-starter-gateway'

    // spring cloud eureka
    implementation 'org.springframework.cloud:spring-cloud-starter-netflix-eureka-client'

    // dev
    compileOnly 'org.projectlombok:lombok'
    annotationProcessor 'org.projectlombok:lombok'

}

dependencyManagement {
    imports {
        mavenBom "org.springframework.cloud:spring-cloud-dependencies:${springCloudVersion}"
    }
}

tasks.named('test') {
    useJUnitPlatform()
}

tasks.register("prepareKotlinBuildScriptModel") {}

bootJar {
    enabled = true
}

jar {
    enabled = false
}

application.yml 설정

spring:
  application:
    name: ${GATEWAY_APP_NAME}
  profiles:
    active: ${APP_PROFILE}
  config:
    import: optional:configserver:${CONFIG_SERVER_URI}

3. 필터 관련

3-1. Global Filter

솔직히 Global Filter의 경우는 이번 프로젝트에선 없어도 되는 기능이었지만 전체적인 기능을 파악하자는 의미로 억지로 추가해보았습니다. 그래서 특별히 무언가를 한다기 보단 어떠한 리퀘스트가 발생했는지 리스폰스의 스테터스는 어땠는지 로그로 남기는 정도로만 사용했습니다.

@Slf4j
@Component
public class GlobalFilter extends AbstractGatewayFilterFactory<Config> {

    public GlobalFilter() {
        super(Config.class);
    }

    @Override
    public GatewayFilter apply(Config config) {
        return (exchange, chain) -> {
            ServerHttpRequest request = exchange.getRequest();
            ServerHttpResponse response = exchange.getResponse();

            log.info("Global Base Message: {}", config.getBaseMessage());

            if (config.isPreLogger()) {
                log.info("Global Filter Start. request id : {}, request path : {}", request.getId(),
                    request.getPath());
            }
            return chain.filter(exchange).then(Mono.fromRunnable(() -> {

                if (config.isPostLogger()) {
                    log.info("Global Filter End: response status code -> {}",
                        response.getStatusCode());
                }
            }));
        };
    }

    @AllArgsConstructor
    @NoArgsConstructor
    @Data
    public static class Config {

        private String baseMessage;
        private boolean preLogger;
        private boolean postLogger;
    }
}

3-2. AuthorizationFilter

@Component
public class AuthorizationFilter extends AbstractGatewayFilterFactory<Config> {

    private final CookieProvider cookieProvider;
    private final JwtProvider jwtProvider;

    @Autowired
    public AuthorizationFilter(CookieProvider cookieProvider, JwtProvider jwtProvider) {
        super(Config.class);
        this.cookieProvider = cookieProvider;
        this.jwtProvider = jwtProvider;
    }

    @Override
    public GatewayFilter apply(Config config) {
        return (exchange, chain) -> {

            ServerHttpRequest request = exchange.getRequest();
            String token = cookieProvider.getTokenFromCookies(request.getCookies());

            jwtProvider.validateToken(token, TokenType.ACCESS);

            Long memberId = jwtProvider.getMemberIdByToken(token, TokenType.ACCESS);

            ServerHttpRequest newRequest = request.mutate()
                .header("member-id", String.valueOf(memberId)).build();

            return chain.filter(exchange.mutate().request(newRequest).build());
        };
    }

    public static class Config {

    }
}

request가 가지고 있는 Cookie에서 token을 추출해 해당 token에 문제 없는지 체크를 합니다. 문제가 없다면 token에 저장된 memberId를 추출해 header에 저장하고 request로 재생성합니다.ㅣ 이후 다음 filter에 재생성한 request를 담아 보내줍니다.

4. Cookie & JWT 관련

4-1. CookieProvider

@Component
public class CookieProvider {

    public String getTokenFromCookies(MultiValueMap<String, HttpCookie> cookies) {
        if (cookies.isEmpty()) {
            return null;
        }
        return cookies.get(TokenType.ACCESS.getName()).stream().map(HttpCookie::getValue)
            .findAny()
            .orElse(null);
    }
}

CookieProvider에서는 Cookie의 이름을 특정해 해당 토큰을 반환하는 로직만 작성했습니다.

4-2. JwtProvider

@Component
@Slf4j
@RequiredArgsConstructor
public class JwtProvider {

    @Value("${jwt.access-secret}")
    private String ACCESS_SECRET;
    @Value("${jwt.refresh-secret}")
    private String REFRESH_SECRET;

    private Key accessKey;
    private Key refreshKey;

    @PostConstruct
    public void init() {
        byte[] accessKeyBytes = Decoders.BASE64.decode(ACCESS_SECRET);
        byte[] refreshKeyBytes = Decoders.BASE64.decode(REFRESH_SECRET);
        this.accessKey = Keys.hmacShaKeyFor(accessKeyBytes);
        this.refreshKey = Keys.hmacShaKeyFor(refreshKeyBytes);
    }

    public void validateToken(String token, TokenType type) {
        Key key = type.equals(TokenType.ACCESS) ? accessKey : refreshKey;
        try {
            Jwts.parserBuilder().setSigningKey(key).build().parseClaimsJws(token);
        } catch (ExpiredJwtException | UnsupportedJwtException | MalformedJwtException |
                 SignatureException | IllegalArgumentException ex) {
            throw new AuthException(ErrorType.TOKEN_AUTHORIZATION_FAIL);
        }

        validateTokenExpired(token, type);
    }

    private void validateTokenExpired(String token, TokenType type) {
        Date expiredDate = getExpired(token, type);
        if (expiredDate.before(new Date())) {
            throw new AuthException(ErrorType.TOKEN_EXPIRED);
        }
    }

    public Date getExpired(String token, TokenType type) {
        return getClaimsFromJwtToken(token, type).getExpiration();
    }

    public Long getMemberIdByToken(String token, TokenType type) {
        return getClaimsFromJwtToken(token, type).get("memberId", Long.class);
    }

    private Claims getClaimsFromJwtToken(String token, TokenType type) {
        Key key = type.equals(TokenType.ACCESS) ? accessKey : refreshKey;
        return Jwts.parserBuilder().setSigningKey(key).build().parseClaimsJws(token).getBody();
    }
}

JwtProvider에서는 Token의 내용을 가져오거나 Token의 유효성 검사를 실시합니다.

5. 예외 관련

5-1. GlobalExceptionHandler

@Slf4j
@Component
@RequiredArgsConstructor
public class GlobalExceptionHandler implements ErrorWebExceptionHandler {

    @Autowired
    private ObjectMapper objectMapper;

    @Override
    public Mono<Void> handle(ServerWebExchange exchange, Throwable ex) {
        exchange.getResponse().getHeaders().setContentType(MediaType.APPLICATION_JSON);

        Map<String, Object> responseBody = new HashMap<>();
        if (ex instanceof HttpStatusCodeException statusEx) {
            exchange.getResponse().setStatusCode(statusEx.getStatusCode());
            responseBody.put("status", statusEx.getStatusCode());
            responseBody.put("message", statusEx.getMessage());
        } else {
            exchange.getResponse()
                .setStatusCode(ErrorType.TOKEN_AUTHORIZATION_FAIL.getStatusCode());
            responseBody.put("status", ErrorType.TOKEN_AUTHORIZATION_FAIL.getStatusCode());
            responseBody.put("message", ex.getMessage());
        }

        DataBuffer wrap = null;
        try {
            byte[] bytes = objectMapper.writeValueAsBytes(responseBody);
            wrap = exchange.getResponse().bufferFactory().wrap(bytes);
        } catch (JsonProcessingException e) {
            log.error("fatal error : {}", e.getMessage());
        }

        return exchange.getResponse().writeWith(Flux.just(Objects.requireNonNull(wrap)));
    }
}

GlobalExceptionHandler에서는 예외가 발생한 경우 responseBody를 생성해 결과를 반환하게 했습니다.

5-2. ExceptionHandlerConfig

@Configuration
public class ExceptionHandlerConfig {

    @Bean
    public ErrorWebExceptionHandler errorWebExceptionHandler() {
        return new GlobalExceptionHandler();
    }
}

5-1에서 작성한 GlobalExceptionHandler를 Configuration에 Bean으로 등록했습니다. 필터링중 예외가 발생하게 된다면 Bean으로 등록한 GlobalExceptionHandler가 해당 예외를 캐치해 ResponseBody를 생성해 클라이언트로 반환하게 됩니다.

5-3. AuthException

public class AuthException extends HttpStatusCodeException {

    public AuthException(ErrorType errorType) {
        super(errorType.getStatusCode(), errorType.getMessage());
    }

    @Override
    public String getMessage() {
        return getStatusText();
    }
}

커스터마이징한 Exception입니다. 의도적인 예외가 발생한 경우 AuthException으로 throw되고 GlobalExceptionHandler를 통해 ResponseBody로 생성됩니다.

6. API Limiter

6-1 TokenKeyConfig

@Configuration
public class TokenKeyConfig {

    @Bean
    public KeyResolver tokenKeyResolver() {
        return exchange -> {
            var cookies = exchange.getRequest().getCookies().getFirst(TokenType.ACCESS.getName());
            if (cookies != null) {
                return Mono.just(cookies.getValue());
            } else {
                String clientIp = Objects.requireNonNull(exchange.getRequest().getRemoteAddress())
                    .getAddress()
                    .getHostAddress();
                String hashedIp = DigestUtils.sha256Hex(clientIp);
                return Mono.just(hashedIp);
            }
        };
    }
}

쿠키가 있는 경우 쿠키값을 Mono로 감싸서 반환하고 없는 경우 클라이언트의 IP를 해싱처리해 Mono로 감싸 반환했습니다. 이를 통해 API Limiter에서 중복된 요청 등 과도한 트래픽을 일정 부분 제한할 수 있도록 합니다.

7. Eureka Client 활성화

@EnableDiscoveryClient
@SpringBootApplication
public class GatewayServiceApplication {

    public static void main(String[] args) {
        SpringApplication.run(GatewayServiceApplication.class, args);
    }

}

Eureka Client로 등록하기 위해 @EnableDiscoveryClient 어노테이션을 붙여줍니다.

8. Config Server의 설정 파일 작성

gateway-dev.yml

server:
  port: 8080

spring:
  cloud:
    gateway:
      default-filters:
        - name: GlobalFilter
          args:
            baseMessage: Spring Cloud Gateway Global Filter
            preLogger: true
            postLogger: true
        - name: RequestRateLimiter
          args:
            key-resolver: "#{@tokenKeyResolver}"
            redis-rate-limiter.replenishRate: 5
            redis-rate-limiter.burstCapacity: 30
            redis-rate-limiter.requestedTokens: 3
      globalcors:
        cors-configurations:
          '[/**]':
            allowedOrigins:
              - 'http://localhost:8081'
              - 'http://localhost:8082'
              - 'http://localhost:8083'
              - 'http://localhost:8084'
            allowedMethods:
              - GET
              - POST
              - PUT
              - DELETE
              - OPTIONS
            allowedHeaders: '*'
            allow-credentials: true
      routes:
        - id: accommodation
          uri: lb://ACCOMMODATION
          predicates:
            - Path=/api/accommodations/**

        - id: member
          uri: lb://MEMBER
          predicates:
            - Path=/api/auth/**

        - id: reservation
          uri: lb://RESERVATION
          predicates:
            - Path=/api/reservation/**
          filters:
            - name: AuthorizationFilter

        - id: room
          uri: lb://room
          predicates:
            - Path=/api/accommodation/{accommodationId}/rooms/**

jwt:
  access-secret: # access secret key
  refresh-secret: # refresh secret key
  issuer: test
  access-token-expired-time: 86400000
  refresh-token-expired-time: 604800000

eureka:
  client:
    register-with-eureka: true
    fetch-registry: true
    service-url:
      defaultZone: http://${eureka-username}:${eureka-password}@localhost:8761/eureka

이 위에서부터 하나씩 설명을 하자면 다음과 같습니다.

      default-filters:
        - name: GlobalFilter
          args:
            baseMessage: Spring Cloud Gateway Global Filter
            preLogger: true
            postLogger: true
        - name: RequestRateLimiter
          args:
            key-resolver: "#{@tokenKeyResolver}"
            redis-rate-limiter.replenishRate: 5
            redis-rate-limiter.burstCapacity: 30
            redis-rate-limiter.requestedTokens: 1

GlobalFilter 라는 클래스를 디폴트로 등록하고, arguments로써 baseMessage와, preLogger, postLogger라는 변수에 각각의 값을 지정합니다.

RequestRateLimiter는 서버가 클라이언트의 시간당 요청 횟수를 제한하는 것으로 서버 과부하를 막기위해 사용했습니다.

replenisRate : 초당 채워지는 Token의 수 burstCapacity : 최대 허용되는 버스트 요청 수 requestedTokens : 요청을 처리할 때 소모되는 토큰의 수

      globalcors:
        cors-configurations:
          '[/**]':
            allowedOrigins:
              - 'http://localhost:8081'
              - 'http://localhost:8082'
              - 'http://localhost:8083'
              - 'http://localhost:8084'
            allowedMethods:
              - GET
              - POST
              - PUT
              - DELETE
              - OPTIONS
            allowedHeaders: '*'
            allow-credentials: true

이 부분은 CORS에 해당되는 이야기로, localhost의 8081~8084에에서 GET, POST, PUT등 메서드들의 요청을 허가 하겠다는 의미입니다.

      routes:
        - id: accommodation
          uri: lb://ACCOMMODATION
          predicates:
            - Path=/api/accommodations/**

        - id: member
          uri: lb://MEMBER
          predicates:
            - Path=/api/auth/**

        - id: reservation
          uri: lb://RESERVATION
          predicates:
            - Path=/api/reservation/**
          filters:
            - name: AuthorizationFilter

        - id: room
          uri: lb://room
          predicates:
            - Path=/api/accommodation/{accommodationId}/rooms/**

각 predicates의 값 이하의 path가 들어오면 해당 id의 uri로 라우팅해준다는 의미입니다. 그리고 reservation의 경우 filters가 추가되어 있는데 특정 서비스에만 filter를 추가하는 의미로 인증/인가 filter를 추가했습니다. jwt와 eureka는 생략하겠습니다.

동작 확인

먼저 Config Server, Eureka Server를 실행한 뒤 Gateway Service를 실행합니다

Gateway Service가 정상 실행하고 Eureka Server에 등록이 되어있다면

http://localhost:8761 에 접속해 Eureka Server의 username과 password를 입력해 로그인합니다.

그러면 아래와 같이 GATEWAY 서비스가 등록이 되어 있는 것을 볼 수 있습니다.

이제 라우팅이 정상적으로 동작하는지 확인해보겠습니다.

저는 현재 Member Service의 port를 8082로 설정한 상태입니다. Gateway가 없다면 Member Service를 이용하기 위해 localhost:8082로 요청을 해야하지만 Gateway가 라우팅을 해주므로 localhost:8080으로 요청을 보내면 됩니다.

마무리

다음은 OpenFeign에 대해 포스팅하겠습니다.

Eureka란

Nefilx에서 제공하는 OSS Service Registry로 Eureka Server와 Eureka Client로 이루어져있습니다. 이 중 Eureka Server는 마이크로 서비스들의 정보를 발견해 Registry에 등록하고 로드밸런싱을 제공하는 미들웨어 서버입니다.

이미지 출처 : https://www.dineshonjava.com/implementing-microservice-registry-with-eureka/

Eureka Server 구축

Eureka Server는 위에 언급했듯이 마이크로 서비스들의 정보를 Registry에 등록합니다. 이 때의 마이크로 서비스들은 Eureka Client로 정의됩니다.

Eureka Server는 Eureka Client의 Heartbeat를 수신해 해당하는 Eureka Client가 정상적으로 수행중인지 체크합니다. Heartbeat가 정상적으로 수신되지 않는다면 Eureka Server는 Eureka Client가 수행 중이 아니라고 판단해 해당 Eureka Client의 정보를 Registry에서 삭제합니다.

1. 의존성 주입

build.gradle

ext {
    set('springCloudVersion', "2023.0.3")
}

dependencies {

    // security
    implementation 'org.springframework.boot:spring-boot-starter-security'
    testImplementation 'org.springframework.security:spring-security-test'

    // dev
    compileOnly 'org.projectlombok:lombok'
    annotationProcessor 'org.projectlombok:lombok'

    // spring cloud config
    implementation 'org.springframework.cloud:spring-cloud-starter-config'

    // spring cloud eureka server
    implementation 'org.springframework.cloud:spring-cloud-starter-netflix-eureka-server'
}

dependencyManagement {
    imports {
        mavenBom "org.springframework.cloud:spring-cloud-dependencies:${springCloudVersion}"
    }
}

tasks.named('test') {
    useJUnitPlatform()
}

tasks.register("prepareKotlinBuildScriptModel") {}

bootJar {
    enabled = true
}

jar {
    enabled = false
}

위와 같이 저는 Eureka Server 의존성 외에 Security와 Spring Cloud Config를 추가로 의존성 주입했습니다. 이유는 다음과 같습니다.

Spring Security : config server와 마찬가지로 Eureka Server에는 각 마이크로 서비스들의 정보가 등록이 되므로 보안상 중요 정보들이 다뤄지기 때문에 Security 의존성이 필요했습니다.

Spring Cloud Config : Config Server를 통해 Eureka에 필요한 환경 변수들을 가져올 예정이므로 필요했습니다.

2. application.yml 수정

application.yml

spring:
  application:
    name: ${EUREKA_APP_NAME}
  profiles:
    active: ${APP_PROFILE}
  config:
    import: optional:configserver:${CONFIG_SERVER_URI}

${EUREKA_APP_NAME} : Eureka Server의 이름입니다. ${APP_PROFILE}과 조합해 설정 파일을 특정합니다.

${APP_PROFILE} : dev 또는 prod와 같은 프로파일 이름입니다. ${EUREKA_APP_NAME}과 조합해 설정파일을 특정합니다.

${CONFIG_SERVER_URI} : 설정 파일을 관리하고 있는 Config Server의 URI입니다.

ex ) http://${CONFIG_USERNAME}:${CONFIG_PASSWORD}@localhost:8888

CONFIG_USERNAME과 CONFIG_PASSWORD는 이전 포스트를 확인해주세요.

3. 로직 작성

SecurityConfig.java

@Configuration
@EnableWebSecurity
public class SecurityConfig implements WebMvcConfigurer {

    @Value("${eureka.username}")
    private String username;

    @Value("${eureka.password}")
    private String password;

    @Bean
    public BCryptPasswordEncoder bCryptPasswordEncoder() {

        return new BCryptPasswordEncoder();
    }

    @Bean
    public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
        return http
            .csrf(AbstractHttpConfigurer::disable)
            .authorizeHttpRequests((auth) -> auth.anyRequest().authenticated())
            .httpBasic(Customizer.withDefaults())
            .build();
    }

    @Bean
    public UserDetailsService userDetailsService() {

        UserDetails user = User.builder()
            .username(username)
            .password(bCryptPasswordEncoder().encode(password))
            .roles("ADMIN")
            .build();

        return new InMemoryUserDetailsManager(user);
    }

Security의 구조는 Config Server와 동일하고 이전 포스트에서 말씀드렸듯이 프로젝트 기획에 따라 DB와의 연동해도 무방합니다.

EurekaServerApplication.java

아래와 같이 메인클래스에 @EnableEurekaServer 어노테이션을 붙혀 활성화합니다.

@EnableEurekaServer
@SpringBootApplication
public class EurekaServerApplication {

    public static void main(String[] args) {
        SpringApplication.run(EurekaServerApplication.class, args);
    }
}

4. 동작 확인

Eureka Server를 실행하기 위해선 Config Server가 먼저 실행되어야 합니다. 그 후 Eureka Server를 실행했을 때 문제가 없다면 아래와 같이 8761 포트 번호로 실행이 되는 것을 확인할 수 있습니다.

이후 웹에서 http://localhost:8761 로 접속해 User name과 Password를 입력하면 다음과 같은 페이지가 뜨면 정상적으로 Server가 동작하고 있는 것입니다. 다만 현재로썬 마이크로 서비스를 등록하지 않았기에 Instances currently registered with Eureka 부분이 공란인 것을 확인할 수 있습니다. 등록하게 된다면 해당 마이크로 서비스의 정보를 볼 수 있습니다.

다음은 게이트웨이 서비스에 대해 포스팅하겠습니다.

Config Server란

스프링 클라우드 구성은 분산 시스템에서 외부화된 구성을 위한 서버 및 클라이언트 측 지원을 제공합니다. 
Config 서버를 사용하면 애플리케이션의 환경 변수들을 관리할 수 있는 중앙 위치를 확보할 수 있습니다. 
클라이언트와 서버의 개념은 스프링 환경 및 속성소스 추상화와 동일하게 매핑되므로 스프링 애플리케이션과 
매우 잘 맞지만 모든 언어로 실행되는 모든 애플리케이션에서 사용할 수 있습니다. 
애플리케이션이 배포 파이프라인을 통해 개발자에서 테스트 및 프로덕션으로 이동할 때 해당 환경 간의 구성을 관리하고 
애플리케이션이 마이그레이션할 때 실행하는 데 필요한 모든 것을 갖추고 있는지 확인할 수 있습니다. 
서버 스토리지 백엔드의 기본 구현은 git을 사용하므로 레이블이 지정된 버전의 구성 환경을 쉽게 지원할 뿐만 아니라 
콘텐츠 관리를 위한 광범위한 도구에 액세스할 수 있습니다. 
대체 구현을 추가하고 스프링 구성으로 쉽게 연결할 수 있습니다.

Config Server를 사용함으로써 애플리케이션들의 환경 변수를 한 곳에서 집중 관리가 가능하다고 공식 문서에 언급되어 있습니다. 이를 통해 각 애플리케이션이 기동할 때 Config Server로 요청을 하고 Config Server는 해당 애플리케이션의 환경 변수들을 보내줌으로써 애플리케이션의 실행을 지원하게 됩니다.

자세한 내용은 Spring Config 공식 문서 를 참고바랍니다.

Config server 구축

이전 포스트에서 하위 모듈들을 구축하셨다면 아래와 같은 config-server 모듈이 존재할 것이고 오늘은 이 config-server를 구축해 이후 각 서비스들이 config-server를 통해 환경 변수를 조회 및 관리를 할 수 있도록 하겠습니다.

구축해야 할 내용은 다음과 같습니다.

1. 의존성 주입 ( build.gradle )
2. 로직 작성
3. config server용 git repository 생성
4. application.yml 수정
5. 동작 확인

1. 의존성 주입

의존성은 lombok, Spring Cloud Config Server, Spring Security 3가지가 필요합니다.

build.gradle

dependencies {
    implementation 'org.springframework.boot:spring-boot-starter-security'
    implementation 'org.springframework.cloud:spring-cloud-config-server'
    compileOnly 'org.projectlombok:lombok'
    annotationProcessor 'org.projectlombok:lombok'
}

tasks.register("prepareKotlinBuildScriptModel") {}

bootJar {
    enabled = true
}

jar {
    enabled = false
}

Security를 사용하는 이유는 다음과 같습니다.

각 애플리케이션의 환경 변수들을 관리하는 만큼 민감한 정보들을 다루게 됩니다. 민감한 정보들이란, DB 정보, 외부 API의 키 등입니다.

이처럼 보안이 중요한 요소가 있기에 Spring Security를 활용해 인증된 애플리케이션만 환경 변수들을 가져가도록 합니다. 또한 만일에 대비해 누가 언제 어떠한 설정에 접근했는지 추적을 할 수도 있습니다.

2. 로직 작성

로직은 Security에 대한 작성이 대부분입니다. SecurityConfig를 작성하겠습니다. username과 password는 보안적인 대책이 필요하므로 따로 환경변수로 입력받게끔 했습니다. 필요하다면 프로젝트 기획에 따라 외부 인증서버와 연결해 관리자 계정을 관리하도록 하는 방법도 있지만 학습용이기에 확장하지 않고 사용하는 형태로 작성했습니다.

SecurityConfig.java

@Configuration
@EnableWebSecurity
public class SecurityConfig implements WebMvcConfigurer {

    @Value("${config.username}")
    private String username;

    @Value("${config.password}")
    private String password;

    @Bean
    public BCryptPasswordEncoder passwordEncoder() {
        return new BCryptPasswordEncoder();
    }

    @Bean
    public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
        return http
            .csrf(AbstractHttpConfigurer::disable)
            .authorizeHttpRequests((auth) -> auth.anyRequest().authenticated())
            .httpBasic(Customizer.withDefaults())
            .build();
    }

    @Bean
    public UserDetailsService userDetailsService() {

        UserDetails admin = User.builder()
            .username(username)
            .password(passwordEncoder().encode(password))
            .roles("ADMIN")
            .build();

        return new InMemoryUserDetailsManager(admin);
    }
}

Security에 대한 작성은 여기까지가 전부이고 ConfigServer를 활성화하기 위해 main클래스에 @EnableConfigServer 어노테이션을 추가해야 합니다.

@EnableConfigServer
@SpringBootApplication
public class ConfigServerApplication {

    public static void main(String[] args) {
        SpringApplication.run(ConfigServerApplication.class, args);
    }
}

3. git repository 생성

본래 Config Server에서 환경 변수들을 관리하는 방법은 여러가지 있습니다.

이미지 출처 : https://medium.com/javarevisited/centralized-configuration-for-microservices-using-spring-cloud-config-c7845cbccc34

위의 이미지와 같이 여러 방법들이 존재 하지만 Git 서비스를 가장 많이 사용한다고 합니다.

먼저 GitHub에서 다음 이미지와 같이 리포지토리를 생성을 하는데 꼭 Private로 만들어야 합니다. 위에서 언급했듯이 민감한 정보들을 다루니 Public 리포지토리를 만들어선 안됩니다. 이후, 비대칭 키를 통해서 리포지토리로 접속 할 예정입니다.

3-1. SSH Key 생성

Private로 만들어진 리포지토리를 외부에서 접속할 수 있도록 SSH Key를 생성해 위에서 생성한 리포지토리에 등록을 해야 합니다.

이때 쉘 환경에서 다음 명령어를 통해 생성하면 되는데 Windows 환경의 경우 git bash, Mac 환경의 경우 Terminal을 사용하면 됩니다.

다만 Key를 생성할때엔 많은 사람들이 rsa알고리즘을 사용하기도 하는데 Github에서는 rsa 알고리즘에 대한 보안 취약점이 있어 SHA-1 Error가 발생한다고 합니다. 그래서 저는 ecdsa 알고리즘을 사용하고자 합니다.

ssh-keygen -m PEM -t ecdsa -b 256 -C "임의의 코멘트"

명령어를 실행하면 /사용자/.ssh 경로에 생성 됩니다.

.ssh 경로가 어딘지 모르겠다면 아래 명령어를 실행하면 됩니다.

Mac의 경우

echo $HOME/.ssh

Windows의 경우

echo %userprofile%\.ssh

생성된 SSH Key 중 pub 확장자의 파일에 저장된 키 내용을 복사해주세요.

이후 리포지토리의 Settings > Security 탭의 Deploy keys > Add deploy key 버튼 클릭해주시고 임의의 제목을 입력한 후 Key 란에 복사했던 내용을 붙여넣어 주세요.

저는 이 리포지토리에 설정 파일들에 대한 작성 및 수정이 있을 예정이라 아래 Allow write access 체크박스에 체크를 했습니다. ( 체크를 하지 않는다면 IDE에서 파일 작성, 수정하고 PUSH하게 되면 작성 권한이 없어 에러가 발생합니다. )

Add key 버튼을 누르면 다음과 같이 키가 등록된 것을 확인 할 수 있습니다.

이후, Terminal 또는 Git bash에서 아래의 명령어를 실행하면 해당 SSH Key가 출력이 되는데 설정 파일(yml, properties)에 입력해야하니 현 단계에선 준비까지만 해주세요.

# ex) cat id_ecdsa
cat 생성한 SSH Key 이름

명령어를 실행하면 아래와 같은 값들이 출력이 됩니다.

4. application.yml 수정

프로젝트 또는 모듈을 생성하면 src/main/resoruce 경로에 application.properties 라는 파일이 생성되어 있을텐데 편의상 application.yml로 수정했습니다.

server:
  port: ${CONFIG_SERVER_PORT} # 일반적으로 8888 포트가 많이 사용됩니다.

spring:
  application:
    name: ${CONFIG_APP_NAME}
  cloud:
    config:
      server:
        git:
          uri: ${CONFIG_GIT_URI} # Github의 ssh uri를 복사해서 붙여넣습니다
          search-paths: config-file/**
          default-label: main
          ignore-local-ssh-settings: true
          privateKey: |
            -----BEGIN EC PRIVATE KEY-----
            3번에서 cat 명령어로 출력한 값을 여기에 붙여넣습니다
            -----END EC PRIVATE KEY-----
          host-key: ${GIT_HOST_KEY}
          host-key-algorithm: ${GIT_HOST_ALGORITHM}
config:
  username: ${CONFIG_USERNAME}
  password: ${CONFIG_PASSWORD}

${CONFIG_SEVER_PORT} : 일반적으로 8888 포트 번호를 많이 사용합니다.

${CONFIG_APP_NAME} : 임의의 문자열을 넣으셔도 되고 이름 설정을 하고 싶지 않으시다면 해당 설정을 삭제 하셔도 무방합니다.

${CONFIG_GIT_URI} : 아래와 같이 SSH의 URI를 복사해 붙여넣습니다.

${GIT_HOST_KEY} : 아래 명령어를 실행해서 출력된 값을 base64로 인코딩해 붙여넣습니다.

ssh-keyscan -t ssh-rsa github.com

${GIT_HOST_ALGORITHM} : ecdsa 알고리즘으로 키를 생성했기 때문에 ecdsa-sha2-nistp256 를 적습니다.

${CONFIG_USERNAME}과 ${CONFIG_PASSWORD} 의 경우는 필요에 따라 설정을 하셔도 되고 Security 로직 작성 내용에서 언급했듯이 프로젝트 기획에 따라 대응하면 됩니다.

5. 동작 확인

위에서 작성한 내용이 잘 실행 되는지 로컬 환경에서 Config Server 애플리케이션을 동작해본 결과는 다음과 같습니다.

그리고 실제 웹에서 접속하게되면 입력한 경로에 맞는 설정 파일 내용들을 조회할 수 있습니다. (※ 아래 이미지는 추후 서비스 애플리케이션의 설정파일들을 Config Server용 리포지토리에 등록하게 되면 확인 가능합니다.)

추가

동작 확인에서 언급했지만 각 서비스 애플리케이션의 설정파일들을 Config Server용 리포지토리에 등록을 해야하는데 다음과 같은 파일명 규칙에 맞춰 push해야만 합니다.

저장소 이름-저장소 환경.properties 또는 저장소 이름-저장소 환경.yml 일것.

위와 같은 규칙에 맞춰 설정 파일 이름이 되어야 아래와 같이 주소 변환이 이루어져 서버에서 동작됩니다.

http:HOST:PORT/저장소 이름/저장소 환경

예를들어 localhost:8888이고 yml의 이름을 accommodation-prod.yml인 경우 http:localhost:8888/accommodation/prod 로 접속이 가능하고 설정 내용들을 조회할 수 있습니다.

미니 프로젝트에서는 프론트 3명, 백엔드 5명이 하나의 팀이 되어 프로젝트 수행을 했습니다. 아래는 당시 프로젝트의 구조이고 모놀리스 애플리케이션입니다.

- 회원 도메인
  - 로그인
  - 회원 가입
  - 회원 탈퇴

- 숙소 도메인
  - 전체 조회( 조건 O )
  - 전체 조회( 조건 X )
  - 숙소 상세 조회

- 객실 도메인
  - 객실 조회 ( 조건 O )
  - 객실 상세 조회

- 예약 도메인
  - 예약 하기
  - 예약 조회
  - 예약 취소

- 찜 도메인
  - 찜 누르기
  - 찜 취소하기

- 장바구니 도메인
  - 장바구니 추가
  - 장바구니 조회
  - 장바구니 취소

- 리뷰 도메인
  - 리뷰 추가
  - 리뷰 조회
  - 리뷰 수정
  - 리뷰 삭제

Spring Cloud 프로젝트 구성

이번 프로젝트에서는 이벤트 기반 MSA가 중점이니 최소한의 필요 서비스들로만 구성했습니다.

- Config 서비스

- Eureka 서비스

- Gateway 서비스
  - 로드 밸런스
  - 시큐리티 ( JWT 인증 / 인가 )

- 숙소 서비스
  - 숙소 전체 조회
  - 숙소 상세 조회

- 객실 서비스
  - 객실 전체 조회
  - 객실 상세 조회

- 회원 서비스
  - 회원 가입
  - 로그인
  - 로그아웃
  - 회원 탈퇴

- 예약 서비스
  - 예약 하기
  - 예약 조회
  - 예약 취소

멀티 모듈 프로젝트 생성

1. 루트 모듈 생성

일단 루트 모듈이될 프로젝트 부터 생성을 하고 기존 코드들은 모두 하위 모듈로 구성할 것이기에 루트 모듈은 아래 작업만 진행합니다.

• 새 프로젝트 생성
• src 폴더 삭제
• 루트 모듈의 build.gradle 설정
• settings.gradle에서 하위 모듈 추가

루트 모듈을 담당할 프로젝트 생성 후 src폴더 등을 삭제해 위와 같은 파일들만 존재하면 됩니다.

build.gradle

plugins {
    id 'java'
    id 'org.springframework.boot' version '3.3.2'
    id 'io.spring.dependency-management' version '1.1.6'
}

allprojects {
    group = 'com.fp'
    version = '0.0.1-SNAPSHOT'

    repositories {
        mavenCentral()
    }
}

subprojects {

    apply plugin: 'java'
    apply plugin: 'org.springframework.boot'
    apply plugin: 'io.spring.dependency-management'
    apply plugin: 'java-test-fixtures'

    java {
        toolchain {
            languageVersion = JavaLanguageVersion.of(17)
        }
    }

    configurations {
        compileOnly {
            extendsFrom annotationProcessor
        }
    }

    ext {
        set('springCloudVersion', "2023.0.3")
    }

    dependencyManagement {
        imports {
            mavenBom "org.springframework.cloud:spring-cloud-dependencies:${springCloudVersion}"
        }
    }
}

tasks.named('test') {
    useJUnitPlatform()
}

bootJar {
    enabled = false
}
jar {
    enabled = false
}

setting.gradle

rootProject.name = 'msa'
include 'config-server'
include 'eureka-server'
include 'gateway-service'
include 'accommodation-service'
include 'member-service'
include 'reservation-service'
include 'room-service'

2. 하위 모듈 생성

서비스를 담당할 하위 모듈들은 의존성을 제외하자면 설정이 동일하기 때문에 accommodation-service 모듈로 예시를 적겠습니다. 추후 추가 기능등을 위해 의존성이 추가될 예정 입니다.

build.gradle

dependencies {

    // boot
    implementation 'org.springframework.boot:spring-boot-starter'
    implementation 'org.springframework.boot:spring-boot-starter-web'
    testImplementation 'org.springframework.boot:spring-boot-starter-test'

    // dev
    compileOnly 'org.projectlombok:lombok'
    annotationProcessor 'org.projectlombok:lombok'
    implementation 'org.springframework.boot:spring-boot-starter-validation'

    // db
    implementation 'org.springframework.boot:spring-boot-starter-data-jpa'
    runtimeOnly 'com.mysql:mysql-connector-j'
}

tasks.named('test') {
    useJUnitPlatform()
}

tasks.register("prepareKotlinBuildScriptModel") {}

bootJar {
    enabled = true
}

jar {
    enabled = false
}

위 처럼 필요 의존성을 추가한 하위 모듈들을 생성하게 되면 다음과 같은 구성이 만들어집니다.

다음 포스트는 config-server를 구축해 각 서비스들의 환경변수들을 관리하고 각 서비스들을 기동할 때 config-server가 관리하고 있는 환경변수들을 조회하는 내용을 적어보도록 하겠습니다.

패스트 캠퍼스 파이널 프로젝트의 RFP가 가고자 하는 방향과 달라 개인 프로젝트로 전환..🥲

개인 프로젝트를 어떠한 주제로 할지 고민하던 차에 미니 프로젝트의 결과물을 MSA 환경으로 마이그레이션을 한 후 Kafka를 통해 서비스간 통신을 구현하는 프로젝트 주제를 멘토님께 제안받아 시작되었습니다.

Monolith Architecture란

모놀리스 아키텍처란 MSA의 반대 되는 개념으로 이제껏 우리가 해왔던 방식을 뜻합니다.

여러 도메인(서비스)를 하나의 통합된 소프트웨어 시스템 내에서 관리를 하고 특정 도메인(서비스)를 수정하더라도 전체 시스템을 대상으로 배포를 해야 합니다.

MSA란

Micro Service Architecture 의 약자로 다음과 같이 설명이 가능합니다.

소프트웨어 시스템을 여러 작은 독립적인 도메인(서비스)로 분할하여 개발하고 배포하는 방식

MSA는 각 도메인(서비스)별 소스 코드 수정 및 관리가 쉽고, 독립적이기 때문에 수정한 도메인(서비스)만 배포가 가능하며, 배포 시 전체 서비스 중단이 없다라는 특징을 지니고 있습니다.

또한, 독립적이기에 예기치 못한 장애가 발생하더라도 해당 도메인(서비스)에 국한되고, 전체적인 장애로 확장될 가능성이 매우 낮습니다.

마지막으로 시스템의 규모가 확장되더라도 해당 도메인(서비스)만 추가하면 되기에 스케일 아웃이 용이합니다.

MSA와 Monolithic의 비교. 출처 - https://metanetglobal.com/bbs/board.php?bo_table=tech&wr_id=38

MSA 마이그레이션시 고려해야할 점

모놀리스 아키텍처라면 하나의 시스템에 각 도메인(서비스)들을 모아둔 형태이다 보니 의존성 주입을 하면 사실상 고민할 이유가 없는 내용이지만 MSA는 각 도메인(서비스)가 독립되어 있고 모놀리식 아키텍처와 같이 의존성 주입을 하게 된다면 주입한 의존성의 서비스에 장애가 발생할 시에 다른 서비스 또한 영향을 받게되므로 다음과 같은 사항에 대해 고려를 해야했습니다.

1. 외부의 요청에 대한 서비스 라우팅

   • MSA에서는 도메인(서비스)별로 독립적인 시스템이 되었기에 외부 요청에 대한 처리가 필요합니다.
   • 외부 요청이 발생하면 어느 도메인(서비스)의 요청인지 분기 처리를 해야하기 때문입니다.

Spring Cloud Routing의 GateWay 의존성을 통해 분기 처리 가능.

2. 도메인(서비스)간의 통신

   • A도메인(서비스)에서 B도메인(서비스)의 정보에 대한 CRUD 처리가 필요할 때 Request의 전달 방법이 필요합니다.

   여러 기술 스택이 존재하지만 Kafka의 비동기 이벤트 Pub/Sub을 통해 구현 가능.

풀이 과정

• 탐색에 관한 문제이기 때문에 BFS/DFS를 고려
  • 최단 거리를 찾아야 하는 문제이기에 BFS를 선택
    • DFS의 경우 얻어진 해가 최단 경로가 된다는 보장이 없기 때문.
• 먼저 이동할 4방향에 대한 이동 거리를 상수로 표현
• 맵의 행과 열의 길이를 추출
• boolean 2차원 배열을 생성해 방문했는지 체크
• queue를 돌려 탐색

작성 코드

import java.util.*;
class Solution {
    private final static int[][] DIRECTIONS = new int[][]{{0,1},{0,-1},{1,0},{-1,0}};
    public int solution(int[][] maps) {

        int rowLength = maps.length;
        int colLength = maps[0].length;

        Queue<int[]> queue = new LinkedList<>();
        boolean[][] visited = new boolean[rowLength][colLength];

        // 첫번째 vertex 방문
        visited[0][0] = true;
        queue.offer(new int[]{0,0,1}); // 0,0 : 위치 | 1 : 카운트

        while(!queue.isEmpty()){
            int[] cur = queue.poll();

            if(cur[0] == rowLength - 1 && cur[1] == colLength - 1){
                // 맵의 (n,m)위치에 도달한 경우 이동한 칸 수를 반환
                return cur[2];
            }

            for(int i = 0; i < DIRECTIONS.length; i++){
                int nextRow = DIRECTIONS[i][0] + cur[0];
                int nextCol = DIRECTIONS[i][1] + cur[1];

                if(isValid(rowLength, colLength, nextRow, nextCol)){
                    if(!visited[nextRow][nextCol]&& maps[nextRow][nextCol] == 1){
                        queue.offer(new int[]{nextRow,nextCol, cur[2]+1});
                        visited[nextRow][nextCol] = true;
                    }
                }
            }
        }

        return -1;
    }

    // 이동할 위치가 맵의 밖으로 이동하지 않는지 체크
    private boolean isValid(int rowLength, int colLength, int nextRow, int nextCol){
        return nextRow >= 0 && nextRow < rowLength && nextCol >= 0 && nextCol < colLength;
    }
}

실행 결과

풀이 과정

• 참가 선수가 완주자 명단에 있는지 확인해야하므로 HashSet과 HashMap을 고려
  • HashSet의 경우 참가 선수를 Value로 담으면 되지만 제한사항의 참가자 중에는 동명이인이 있을 수 있습니다.라고 명시되어 있기에 HashSet으로 한다면 동명이인에 대한 체크가 불가능
  • HashMap의 경우 참가 선수를 Key로 담고 제한사항의 참가자 중에는 동명이인이 있을 수 있습니다.를 고려해 Value에 인원 수를 카운트한 정수를 담으면 동명이인에 대한 체크가 가능
• 완주자 명단의 선수를 Key로 HashMap의 값을 추출해 1씩 빼기
• HashMap에서 Value가 0이 아닌 선수가 완주하지 못한 선수로 판단해 반환.

작성 코드

import java.util.*;
class Solution {
    public String solution(String[] participant, String[] completion) {
        String answer = "";

        HashMap<String, Integer> playerMap = new HashMap<>();
        for(String player : participant){
            // 동명이인이 없는 경우 디폴드 값(0) + 1
            // 동명이인이 있는 경우 저장된 값 + 1
            playerMap.put(player, playerMap.getOrDefault(player, 0)+1);
        }

        for(String player : completion){
            // 완료된 선수가 있는 경우 저장된 값 -1
            playerMap.put(player, playerMap.get(player)-1);
        }

        return playerMap.entrySet()
            .stream()
            .filter(entry -> entry.getValue() != 0)
            .findFirst()
            .orElseThrow()
            .getKey();
    }
}

실행 결과