이 때, 라이더들의 위치가 실시간으로 변하므로 기존에 구현한 DB에서 조회하는 방식은 성능 저하가 발생할 것으로 예상하였다. 이에 Redis GEO 도입후 Jmeter를 통해 성능을 비교해보고자 한다.

테스트 시나리오

환경

테스트 도구 : Apache JMeter 라이더 수 : 50 / 100 (실시간 위치 업데이트) 조회 요청 스레드 수 : 100 / 200 (동시 조회 요청)

라이더 수와 조회 요청 스레드 수를 조절하며 3가지 테스트 케이스를 진행하고 비교한다.

시나리오

Thread Group 1 : Rider 위치 변경 API 부하 → 랜덤 라이더 ID 선택 후 랜덤 좌표를 생성하여 실시간으로 위치 업데이트

Thread Group 2 : 라이더 조회 API 부하 → 가게 좌표 반경 내 10km 이내의 라이더들을 조회 → 50% DB 조회 / 50% Redis 조회 → 동시 실행하여 같은 환경에서 비교

실시간으로 변하는 라이더 위치를 업데이트 해야하고 배달 주문이 하나 들어올 때 마다 가게 주변의 라이더를 매번 새롭게 조회해야 하므로 위와 같이 두 개의 테스트 그룹을 설정하여 진행한다.

측정 지표

•    Average Response Time (ms)
•    P50 / P90 / P95 / P99 Response Time (ms)
•    Error %
•    Throughput (TPS)

테스트

Case 1.

• 라이더 수 : 50
• 조회 요청 스레드 수 : 100
• 지속 시간 : 10분

Case 2.

• 라이더 수 : 50
• 조회 요청 스레드 수 : 200
• 지속 시간 : 10분

Case 3.

• 라이더 수 : 100
• 조회 요청 스레드 수 : 100
• 지속 시간 : 10분

인사이트

P95는 95%의 요청이 몇 ms안에 처리되는지 나타낸 지표로 실사용자 경험과 가장 가깝기 때문에 이를 기준으로 세가지 테스트 케이스에 대한 속도 개선을 비교해보도록 하자

결과를 보면, DB를 통한 조회 방식보다 Redis GEO를 활용한 방식이 평균적으로 55%의 속도 개선 을 이루었음을 확인할 수 있다. 특히나 조회 요청 스레드가 2배 많은 케이스에서 DB 조회 방식이 눈에 띄게 느려진 것을 확인할 수 있고 이 경우 Redis GEO가 80% 빠른 것을 확인할 수 있었다.

다만 TPS는 모든 테스트 케이스에서 거의 동일한 수치를 보였다. 또한 에러율은 모든 테스트 케이스에서 0.01% 미만으로 안정적인 수치를 보였다.

리스트는 가변, 튜플은 불변이다. 튜플은 딕셔너리 키로 사용할 수 있다.

lst = [1, 2, 3]
tpl = (1, 2, 3)

lst[0] = 9       # 가능
tpl[0] = 9       # TypeError 발생

GIL이란?

GIL(Global Interpreter Lock)은 하나의 스레드만 파이썬 바이트 코드를 실행하도록 하는 락이다. 멀티 스레딩의 성능을 제한하지만, IO-bound 작업에는 유리하다. 파이썬은 스레드에 대해 안정성 있는 접근을 보장하기 위해 GIL을 사용한다.

global과 nonlocal의 차이

global은 전역 변수를 참조, 수정할 때 사용한다. nonlocal은 중첩 함수에서 상위 함수의 지역 변수를 참조, 수정할 때 사용한다.

x = 0

def outer():
    y = 1
    def inner():
        nonlocal y
        y = 10
    inner()
    print(y)  # 10

def change():
    global x
    x = 100

outer()
change()
print(x)  # 100

데코레이터란?

데코레이터는 기존의 함수를 수정하지 않고 기능을 확장하는 함수이다.

def logger(func):
    def wrapper(*args, **kwargs):
        print(f"Calling {func.__name__}")
        return func(*args, **kwargs)
    return wrapper

@logger
def greet():
    print("Hello")

greet()

# 결과
Calling greet
Hello

예외 처리 실행 순서

Q. try-except-else-finally의 실행 순서는?

try : 예외 발생의 가능성이 있는 코드 except : 예외 발생시 실행 else : 예외가 없을 때 실행 finally : 예외와 무관하게 실행

컴프리헨션의 장점

리스트, 딕셔너리 컴프리헨션은 간결하고 효율적으로 새로운 컬렉션을 생성 할 수 있도록 한다. 반복문보다 빠르고 직관적이다.

squares = [x*x for x in range(5)]
evens = {x: x%2 == 0 for x in range(5)}

call by

함수의 파라미터를 받을 때, call by value는 변수에 담긴 값 자체를 스택에 복사하여 넘겨준다. call by reference는 변수가 가리키는 메모리 주소(참조) 값을 전달한다. 파이썬은 Call by Object Reference 또는 Call by Assignment 방식을 사용한다. Call by Object Reference란 함수에 객체의 주소를 전달하되, 그 참조 자체는 값처럼 복사되는 것이다. 이로 인해 가변 객체는 함수 내부에서 변경이 원본에 반영되어 변경 가능한 것이고, 불변 객체는 그렇지 않은 것이다.

def change(x):
    x = x + 1
    print("inside:", x)

a = 10
change(a)
print("outside:", a)

# 결과
inside: 11        # 새로운 int 객체를 생성하여 x에 바인딩
outside: 10        # int는 불변 객체이므로 outside의 a는 변경되지 않음

---

def modify(lst):
    lst.append(4)
    print("inside:", lst)

my_list = [1, 2, 3]
modify(my_list)
print("outside:", my_list)

# 결과
inside: [1, 2, 3, 4]
outside: [1, 2, 3, 4]    # list는 가변 객체이므로 outside에 수정 사항이 반영됨

OhDelviery 프로젝트의 라이더 알림 기능을 구현하던 중 주변의 라이더를 조회하는 로직에 대한 성능 테스트를 진행해보기로 하였다. 해당 로직은 배달 이벤트 발생 시 가게 반경 10km이내의 라이더들을 조회해오는 로직으로 1. DB에서 현재 상태가 배달 가능인 라이더들을 모두 조회한 뒤, 가게에서 라이더의 현재 위치까지의 거리를 각각 계산하고 필터를 걸어 최종 결과 리스트를 반환하는 방식과 2. 배달 가능한 라이더만 올려놓은 Redis에서 Redis GEO를 통해 설정한 거리 이내의 라이더 리스트를 반환하는 방식으로 구현하였다. 유의미한 결과의 테스트를 위해서 가게 위치 주변에 3000명의 라이더가 있는 것으로 가정하고 mock 데이터를 만들어서 테스트하였다.

테스트

1. DB

private List<Rider> getRidersWithDB(Double sLat, Double sLon) {
    // 상태가 AVAILABLE인 라이더 DB에서 전체 조회
    List<Rider> riders = riderRepository.findAllByStatus(RiderStatus.AVAILABLE);

    // 조회해온 라이더 중 현재 위치가 가게에서 반경 10KM 이내인 라이더 필터링 (위경도로 계산)
    riders = riders.stream()
        .filter(rider -> {
          double dis = calculateDistance(sLat, sLon, rider.getLatitude(), rider.getLongitude());
          return dis <= 10.0;
        })
        .toList();

    return riders;
}

2. Redis Geo

Redis Geo로 반경 10km 이내의 라이더 조회 후, 조회한 라이더 ID 리스트로 DB에서 라이더 정보 조회

private List<Rider> getRidersWithRedis(Double sLat, Double sLon) {
    // Redis GEO로 라이더 조회
    GeoResults<RedisGeoCommands.GeoLocation<String>> results = redisRiderLocRepository
        .searchByLoc(sLon, sLat);

    List<Long> riderIds = results.getContent().stream()
        .map(geoLocation -> geoLocation.getContent().getName())
        .map(Long::valueOf)
        .toList();

    // 조회한 라이더 ID 리스트로 DB에서 라이더 정보 조회
    return riderRepository.findAllByRiderIdIn(riderIds);
  }

public GeoResults<GeoLocation<String>> searchByLoc(Double lon, Double lat) {
    return redisTemplate.opsForGeo().search(
        RIDER_LOC_PREFIX,
        GeoReference.fromCoordinate(lon, lat),
        new Distance(10.0, RedisGeoCommands.DistanceUnit.KILOMETERS)
    );
  }

Redis Geo를 활용하는 것이 DB 조회보다 빠를 것이라고 예상했는데 반대의 결과가 나옴. 라이더 id 리스트로 다시 DB에서 조회해오는 로직 때문일 것이라고 생각하고 라이더의 정보도 레디스에 저장한 뒤 테스트를 진행해보기로 함.

Redis Geo로 반경 10km 이내의 라이더 조회 후, 조회한 라이더 ID 리스트로 Redis에서 라이더 정보 조회

private List<Rider> getRidersWithRedis(Double sLat, Double sLon) {
    GeoResults<RedisGeoCommands.GeoLocation<String>> results = redisRiderLocRepository
        .searchByLoc(sLon, sLat);

    List<String> riderIds = results.getContent().stream()
        .map(geoLocation -> geoLocation.getContent().getName())
        .toList();

    // 라이더 정보를 DB가 아닌 Redis에서 조회
    List<Rider> riders = new ArrayList<>();
    for (String riderId : riderIds) {
      Rider rider = redisRiderLocRepository.getRiderInfo(riderId);
      riders.add(rider);
    }

    return riders;
  }

라이더 테이블을 한 번 밀고 다시 저장했더니 위치가 조금 달라져서 조회해오는 라이더 수도 좀 달라졌지만 30명 차이라 별로 상관없을듯

근데 이 로직은 조회 시간이 엄청나게 늘어버리는 문제 발생... 로직을 다시 살펴보면

public Rider getRiderInfo(String riderId) {
    String riderInfo = redisTemplate.opsForValue().get(RIDER_INFO_PREFIX + riderId);

라이더 한 명마다 매번 조회를 하고 있어서 사실상 3000번의 조회가 일어나고 있으므로 당연히 성능 저하가 발생한다...

mget을 통해 멀티 조회를 하는 방식으로 변경해보자

public List<Rider> getRidersInfo(List<String> riderIds) {
    List<String> keys = riderIds.stream()
        .map(id -> RIDER_INFO_PREFIX + id)
        .toList();

    List<String> riderInfos = redisTemplate.opsForValue().multiGet(keys);

    List<Rider> riders = new ArrayList<>();
    for (String riderInfo : riderInfos) {
      if (riderInfo != null) {
        try {
          riders.add(objectMapper.readValue(riderInfo, Rider.class));
        } catch (JsonProcessingException e) {
          throw new RuntimeException("Failed to deserialize rider info", e);
        }
      }
    }
    return riders;
  }

이렇게 하니 시간이 줄긴했는데 결론적으로 맨 처음의 DB조회랑 별로 차이가 안남.

왜 이런 결과가 나타날까 궁금해서** Redis GEO로 라이더의 id리스트만 조회**하는 부분을 속도 측정했더니 평균 10ms 정도로 빠른 속도를 보였다. 결국 라이더 정보 조회를 위해 한 번 더 레디스나 DB에 왔다 갔다 하면서 총 두 번의 I/O가 일어나기 때문에, 한 번의 I/O로 처리하는 맨 처음의 로직과 성능의 차이가 별로 없었던 듯 하다.

다만, 지금의 테스트는 라이더의 위치 정보가 고정적인 상태로 진행되었기 때문에, 실제의 서비스 환경과는 좀 다를 것 같아서 라이더의 위치 정보가 실시간으로 변하고 있는 상황에서 2차 테스트를 다시 진행해보도록 하자.

문제

이번 스프링부트 프로젝트에서 인터페이스의 구현체를 선택해서 주입해야하는 부분이 있었다. 구현체를 주입하는건 간단하고 다양한 방법이 존재하지만, 스프링 빈 주입시 어떤 구현체를 주입할지 명확하게 지정할 수 있도록 해주는 @Qualifier 애너테이션을 적용해보기로 하였다.

@Service
@RequiredArgsConstructor
public class AgentMatchingService {
    private final ApplicationEventPublisher eventPublisher;

      @Qualifier("leastBusy")
      private final AgentMatchingStrategy strategy;
}

@Component("leastBusy")
public class LeastBusyStrategy implements AgentMatchingStrategy {
}

처음엔 이런식으로 구현했다. 그런데 @Qualifier로 지정한 구현체가 주입되지 않는 문제가 발생했다.

원인

문제의 원인은 롬복 생성자 때문이었다. 롬복의 자동 생성 기능 (@AllArgsConstructor, @RequiredArgsConstructor 등)은 단순히 생성자를 자동 생성할 뿐, 필드에 붙어있는 @Qualifier를 인식해서 주입되는 파라미터에 붙이지 못한다.

해결

1. 생성자 정의

가장 명확하고 빠른 해결 방법으로는 롬복의 생성자를 사용하지 않고 그냥 직접 생성자를 정의하면 된다.

public AgentMatchingService(
      ApplicationEventPublisher eventPublisher,
      @Qualifier("leastBusy") AgentMatchingStrategy strategy) 
  {
    this.eventPublisher = eventPublisher;
    this.strategy = strategy;
  }

2. config

이 방법은 구글링하다가 찾은 방법인데 롬복의 설정 파일을 추가해 @Qualifier를 인식하도록 하는 방법도 있다고 한다.

루트 디렉토리에 lombok.config 파일을 생성하고 아래의 내용을 추가한다.

lombok.copyableAnnotations += org.springframework.beans.factory.annotation.Qualifier

다만 이 방법을 적용하지 않은 이유는, 우리 프로젝트는 멀티 모듈로 구성된 MSA 프로젝트이므로 설정 파일을 추가하는 것보단 명시적으로 생성자를 사용하는게 더 간단하고 안정적인 해결 방법이라 생각했기 때문이다.

이번 프로젝트는 라이더용 배달 어플로, 주문이 발생하면 가게 근처의 라이더들에게 주문 배달 알림을 전송하는 기능을 구현해야한다. 이 때, 이 알림 기능을 어떤 기술로 구현할지에 대해 고민해보았다.

메시지 큐

우선 이번 알림 서비스 구현은 이벤트 기반의 메시지 큐를 활용하여 구현하기로 결정했다. 메시지 큐 활용시 알림 서비스가 비동기적으로 실행되어 빠르고 안정적으로 처리될 수 있을 뿐만 아니라 시스템 간의 결합도를 낮춰 유지보수와 확장에 용이하기 때문이다.

그렇다면 메시지 큐를 어떤 기술로 구현할 것인가에 대한 고민을 하게 되었는데 가장 일반적인 메시지 큐인 RabbitMQ, kafka와 Redis Pub/Sub까지 함께 고려해보았다.

Redis Pub/Sub

Redis Pub/Sub은 큐에 메시지를 저장하는 형태가 아닌, 메시지 발행과 함께 구독자들에게 즉시 전달 후 소멸되는 형태이다. 메시지가 저장되지 않으므로 메시지 전달에 대한 보장이 약하다. 즉 신뢰성이 떨어진다. 그렇지만 구현이 가장 간단하다.

Redis Pub/Sub은 실시간 처리에만 적합하고 알림 전달 보장이 필요한 시스템에서는 적합하지 않다고 할 수 있다. 우리 서비스는 라이더들에게 배달에 대한 알림 전송의 안정성이 중요하다고 볼 수 있으므로 Redis Pub/Sub은 고려 대상에서 제외하기로 결정했다.

RabbitMQ VS Kafka

RabbitMQ와 Kafka는 둘 다 발행된 메시지를 큐에 저장하는 방식이다. 전송에 실패하더라도 사용자가 알림을 다시 받을 수 있다. 즉 신뢰성 높은 메시지 처리가 가능하다.

RabbitMQ와 Kafka의 가장 큰 차이는 대용량 스트림인데 Kafka는 고용량 대용량 처리에 강하여 메시지 내구성이 매우 좋다. 다만 우리 서비스에서 한 번에 수십만건의 알림을 처리할 것도 아니고 단순 알림 서비스에 Kafka를 적용하기에는 구현 난이도, 비용, 스펙 측면에서 모두 과하다고 생각했기 때문에 RabbitMQ로 결정했다.

그러나 이 결정을 번복하게 되는데.... 이유는 이벤트를 발행하는 로직에서 이미 Kafka로 이벤트를 발행하고 있기 때문이었다. Kafka는 producer에서 이벤트를 한 번 발행하면 consumer쪽에서 group id를 다르게 설정하여 여러 다른 도메인에서 하나의 이벤트에 대해 각각 처리할 수 있다는 특징이 있다. 즉, 알림 쪽에서 RabbitMQ를 사용하게 되면 이벤트를 두 번 발행해야하지만, kafka를 사용하게 되면 추가적인 이벤트 발행 로직 없이 이미 발행된 이벤트를 활용하면 된다.

뿐만 아니라, 프로젝트 전반적으로 Kafka를 사용하고 있었으나 RabbitMQ를 사용하고 있는 도메인은 없다. 여기서 알림 기능에 RabbitMQ를 도입하게 되면 RabbitMQ 도커 컨테이너를 추가로 띄우고 설정해야하므로 추가적인 비용이 발생하게 된다.

이러한 이유로 Kafka로 통일하여 구현하기로 결정하였다.

클라이언트

처음에는 우리 서비스에 프론트가 존재하지 않아서 Slack 알림으로 구현하였다. 그러나 후에 WebSocket을 활용한 알림 기능도 구현하면 좋을 것 같아서 WebSocket Stomp를 활용해 두 가지 알림이 비동기로 전송될 수 있도록 구현하기로 결정햇다.

1. 영속성 컨텍스트의 범위는?

➡️ 영속성 컨텍스트의 범위는 일반적으로 HTTP 요청이 시작될 때 생성되고, 응답이 완료될 때 소멸된다. JPA에서는 @Trancational이 적용된 메서드 내에서 유지된다.

영속성 컨텍스트는 엔티티 객체를 관리하는 공간으로 엔티티 객체의 생명 주기를 관리하고 변경 감지를 통해 자동으로 DB에 반영하는 역할을 한다.

2. Spring의 Bean Scope?

➡️ @Componet로 등록된 Bean이 어떤 범위로 관리될지 설정할 수 있다. 기본값은 Singleton으로 애플리케이션에서 하나의 인스턴스만 생성되고 DI 컨테이너가 생성될 때 한 번만 초기화 된다.

3. JPA 에서 FetchType 이 LAZY 로 설정된 엔티티를 조회할 때, 프록시 객체 동작 방식은?

➡️ 엔티티를 조회할 때 실제 데이터를 로드하는 것이 아니라 프록시 객체가 생성된다. 실제 데이터가 필요한 시점에 영속성 컨텍스트를 통해 엔티티를 조회하고 데이터를 가져온다.

4. Spring 에서 @Transactional 이 적용된 메서드가 실행될 때, 프록시 객체 동작 방식은?

➡️ 트랜잭션이 적용된 메서드는 AOP 기반의 프록시 객체를 생성하여 실행된다. 메서드 실행 전 트랜잭션이 시작되며 메서드가 종료될 때 트랜잭션이 커밋되거나 롤백된다.

5. Transaction isolation 레벨?

➡️ 트랜잭션 격리 수준 동시에 실행되는 트랜잭션 간의 데이터 격리 수준에 대한 설정이다. 기본값은 REPEATABLE READ로, 트랜잭션 동안 동일한 데이터를 읽을 수 있다. READ UNCOMITTED(커밋되지 않은 데이터 읽기 가능), READ COMITTED(커밋된 데이터만 읽기 가능), SEIALIZALBE(동시 실행 차단) 등의 격리 수준이 존재한다.

6. MySQL 에서 인덱스 사용 시, 쓰기 작업이 발생할 때 인덱스의 자료구조 재정렬 방식?

➡️ MySQL의 B-Tree 인덱스는 삽입/삭제 시 자동으로 정렬된다. B-Tree 특성에 따라 적절한 위치에 삽입되고 균형 유지를 위한 재정렬 작업이 발생한다.

7. Java 에서 객체를 직렬화한 후 역직렬화할 때, 클래스의 classpath가 변경되면ClassNotFoundException 오류가 발생하는 이유?

(클래스 버전 관리/SerialVersionUID 에 대해 알고 있는지) ➡️ Java에서 객체를 직렬화할 때, 클래스의 메타데이터가 함께 저장된다. 역직렬화 시점에 데이터의 클래스 메타데이터와 일치하는 클래스를 찾을 수 없으면 ClassNotFoundException이 발생한다.

8. Spring 내부에서 DI 과정이 이루어지는 방식?

➡️ 스프링은 ComponentScan을 통해 Bean을 찾고 인스턴스를 생성한 뒤, @Autowired, @Inject 등의 애너테이션, 생성자 등을 통해 의존성을 주입한다. Bean 인스턴스를 스프링 컨테이너에 등록하고 필요에 따라 제공한다.

9. DDD에서 이벤트 리스너 패턴 구성 방식은?

➡️ 도메인 객체의 상태 변화가 발생하면 이벤트가 발행된다. 이벤트 리스너가 해당 이벤트를 감지하고 처리한다.

프로젝트 질문

1. 의존역전원칙(DIP)은 무엇이고 고수준 모듈을 어떻게 보호하는지?

➡️ DIP는 고수준 모듈이 저수준 모듈에 의존하지 않고 추상화에 의존하도록 인터페이스를 활용하여 의존성을 역전하는 개념이다.

저수준 모듈이 아니라 인터페이스나 추상 클래스를 참조하여 의존성을 분리한다. 인터페이스를 주입하여 고수준 모듈이 특정 구현체에 의존하지 않도록 보호할 수 있게 된다.

2. 트래픽이 많은 서비스에서 Redis를 많이 사용하는 이유를 Redis의 내부 구조와 연관 지어 설명?

➡️ 레디스는 인메모리 데이터베이스로 디스크보다 빠른 속도를 제공한다. 다양한 자료 구조를 지원하여 상황에 맞게 적용할 수 있다.

3. 주문 시스템을 개발했는데, 선점 기능을 도입한다면 어떻게 개발 할지?

➡️ 1. 버전 정보를 사용하여 충돌을 감지하는 낙관적 락 2. 하나의 트랜잭션만 데이터에 접근 가능하도록 제어하는 비관적 락 3. 다중 인스턴스 환경에서 선점을 구현하는 분산 락

4. 프로젝트를 다중 인스턴스 또는 MSA 구조로 변경한다고 했을 때 고려해야할 점은?

➡️ 데이터 일관성, 서비스 간 통신, 로드 밸련싱, 보안 등

5. JWT 기반 인증에서 토큰을 즉시 만료시킬 수 있는 방법은?

➡️ 1. 레디스에 로그아웃된 토큰을 저장하고 인증시 체크하는 블랙리스트 설계 2. 토큰 무효화 API 제공 3. 엑세스 토큰의 유효시간을 짧게 하고 리프레쉬 토큰 무효화

프로그래머스: 콜라 문제 https://school.programmers.co.kr/learn/courses/30/lessons/132267

해당 문제를 해결하기 위해 재귀 함수를 사용했다.

def bottle(a, b, n, result):
    if n < a:
        return result

    give = n // a * a
    receive = n // a * b
    return bottle(a, b, n - give + receive, result + receive)

에러

그런데 특정 테스트 케이스에서만 런타임 에러가 발생했다. 재귀 함수를 사용하고 있으므로 이와 관련된 것일 거라 생각했다. 찾아본 결과, 파이썬에서는 기본적으로 재귀 깊이 제한 (sys.getrecursionlimit())이 약 1000으로 설정되어 있기 때문에 재귀 호출이 1000번 이상 반복되어 RecursionError (maximum recursion depth exceeded)가 발생했을 가능성이 높은 것으로 보인다.

해결

이를 해결하기 위한 방법으로는 반복문으로 변경하거나 재귀의 깊이를 늘리는 방법이 있다. 하지만 재귀의 깊이를 늘리게 되면 메모리 소비가 커지고 무한 루프에 빠질 수 있어서 메모리를 절약할 수 있도록 반복문으로 변경하였다.

while n >= a:
   give = n // a * a
   receive = n // a * b
   n -= give - receive
   result += receive
return result

반복문으로 변경하니 런타임 예외가 발생하지 않고 통과되었다.

• 프로젝트명: 13friday
• 진행 기간: 2025.03.12 ~ 2025.03.26
• 팀원: 박동휘,서현재,김지현,진강훈
• 목표: MSA 기반 B2B 물류 관리 및 배송 시스템 개발

📊 4L 회고

1. Liked (좋았던 점, 장점)

• 현재 : MSA를 경험할 수 있어서 좋았다
• 강훈: 새로운 아키텍쳐 경험을 쌓고 다양한 기술을 적용시켜 볼 수 있어서 좋았다.
• 지현: 처음 MSA 프로젝트를 하며 새로운 경험을 할 수 있었다.

2. Learned (배운 점)

• 현재 : 인증,인가 흐름에 대해서 진짜 명확하게 알게 되었다
• 지현: MSA 환경에서 설계, 통신, 구현 방법 등을 배움
• 강훈: MSA 의 설계 방식과 DDD 적용하는법, feginClient로 다른 서비스의 API를 호출하는 방법을 배웠다.
• 동휘: feignClient로 통신하는 방식에 대해 배웠다.

3. Lacked (부족했던 점, 단점)

• 지현: 초반의 의사소통, 컨벤션이 부족해서 프로젝트 마무리 시점에 시간이 부족하였다.
• 현재 : docker라던가 CRUD를 제외한 기타 항목들에 대한 지식이 없어서 다른 것들을 적용 못했다.
• 강훈: MSA 나 DDD, docker의 개념이 부족하여 초반 설계단계에서 시간을 너무 많이 쓰게되어 프로젝트 시작이 늦어졌다.
• 동휘: 프로젝트를 정확히 이해하는데 시간이 걸렸고 지식이 부족해 오류를 해결하는데 시간이 걸림. 에러처리를 제대로 못했다.

4. Longed for (아쉬웠던 점, 더 바랐던 것)

• 현재 : kafka, jmeter, zipkin등 부하테스트라던가, 성능고도화에 대한 고려조차 못한게 아쉽다
• 지현: 일정 관리를 통해 미리 테스트를 진행하고 보완점을 찾아 개선했으면 좋았을 듯 합니다.
• 강훈: 이동경로를 P2P로 했는 데 난이도가 제일 쉬운 모델이였어서 다른 모델로 적용시켜봤으면 좋았을것같다.
• 동휘: 여러 전략들에 대해 깊이 고민하지 못하였고 성능 테스트를 제대로 못한 점이 아쉬웠다.

개선 방향

• 현재 : 말을 많이 해야겠다. 적극적으로 의사소통을 해야 프로젝트가 더 원활하게 진행 할 수 있을 것 같
• 동휘: 부하 테스트등 성능 테스트를 통해서 기능을 더 개선하면 좋을 듯 합니다.
• 지현: 초반부터 꼼꼼한 설계와 일정, 시나리오 작성을 하면 더 수월하게 진행할 수 있을 것 같다.
• 강훈: 초반 설계 단계에서 확실하게 마무리하고, 단위 테스트를 더 많이 한다.

Redis란?

Redis(Remote Dictionary Server)는 인메모리 NoSQL 데이터베이스로, 키-값(key-value) 저장소 형태로 데이터를 빠르게 저장하고 검색할 수 있다.

가장 큰 특징은 인메모리 데이터 베이스라는 점이다. 데이터를 디스크가 아닌 메모리(RAM)에 저장하여 매우 빠른 성능을 제공한다. 따라서 높은 트래픽을 처리하는 시스템에 적합하다.

데이터 타입

Redis는 단순 문자열, 리스트, 집합, hash, set 등 다양한 데이터 구조의 저장 방식을 지원한다. key-value 데이터베이스이므로 value로 사용하고자 하는 자료형에 따라 다른 명령어를 사용하게 된다. 대부분의 명령이 존재하지 않는 key 값에 사용되어도 정상적으로 동작하며, 존재하지 않는 key에 데이터를 저장하면 key를 생성한다.

String

# key에 value 문자열 저장
SET <key> <value>
MSET <key> <value> <key> <value>...

# key에 저장된 문자열 반환
GET <key>
MGET <key> <key>...

# 정수 저장시
INCR <key> # 1 증가
DECR <key> # 1 감소

LIST

여러 문자열 데이터를 리스트로 저장한다. 레디스에서 리스트는 Linked List 형태로 저장된다.

# 리스트 앞/뒤에 저장
LPUSH <key> <value>
RPUSH <key> <value>

# 리스트 맨 앞/뒤 값 반환 및 제거
LPOP <key>
RPOP <key>

LLEN <key> # 리스트 길이 반환
LRANGE <key> <start end> # start부터 end까지 원소 반환

SET

문자열의 집합이며 중복을 허용하지 않고 순서가 존재하지 않는다.

SADD <key> <value>    # 값 추가
SREM <key> <value>    # 값 삭제
SMEMBERS <key>        # set에 저장된 모든 원소 반환
SCARD <key>            # set 크기 반환

SINTERCARD <key1> <key2>..    # 교집합 크기 반환
SINTER <key1> <key2>        # 교집합 원소 반환
SUNION <key1> <key2>        # 합집합 원소 반환

SORTED SET

정렬된 집합으로 set에 score 실수를 함께 저장한다. 데이터를 가져올 때 score를 기준으로 정렬하여 값을 가져올 수 있다. 순위와 관련된 리더보드 등의 기능을 만들 때 주로 사용된다.

ZADD <key> <score> <meber>    # key의 set에 score 점수를 가진 member 추가
ZINCRBY <key> <inc> <member>    # member의 score를 inc만큼 증가
ZRANK <key> <member>    # member의 순위 반환
ZRANGE <key> <start end>    # start부터 end 순위 까지의 member 반환

ECS(Amazon Elastic Container Service)는 AWS에서 제공하는 컨테이너 오케스트레이션 서비스이다. 컨테이너 기반 애플리케이션을 AWS 환경에서 쉽게 배포하고 관리할 수 있도록 도와준다. 쿠버네티스와 비슷한 역할을 하지만 보다 저렴하고 사용하기 쉬우며 AWS에 최적화된 관리형 서비스로 제공된다. 또한 서버리스로도 구성 가능하다.

주요 기능으로는 컨테이너 관리, 클러스터 관리, 로드 밸런싱, 자동 스케일링, IAM으로 권한 세분화 등이 있다.

실행 방식

ECS는 컨테이너 실행에 2가지 방식을 제공한다. 하나는 EC2 기반의 방식 또 다른 하나는 Fargate를 사용한 서버리스 방식이다.

• EC2 : EC2 인스턴스에서 컨테이너를 실행하는 방식. 더 많은 제어가 가능하지만 인스턴스를 직접 관리해야한다.
• Fargate : 서버 관리 없이 컨테이너만 실행하는 방식. AWS가 자동으로 인프라를 관리하며 클러스터 인스턴스도 필요하지 않다.

구성 요소

• Task Definition : 컨테이너를 실행하기 위해 정의한 설정
• Task : ECS에서 실제로 실행되는 도커 컨테이너
• Service : 컨테이너를 실행, 유지 관리하는 역할, 테스트가 두 개 이상 모인 것
• Cluster : 컨테이너를 실행할 수 있는 인프라 그룹 (EC2, Fargate)

워크플로우

초기 설정

1. 컨테이너 이미지 빌드 & 저장
2. 클러스터 인스턴스 생성 (EC2 방식일 경우)
3. Task Definition 생성
4. Service 생성

실행 과정

1. 컨테이너 레지스트리에 저장된 도커 이미지를 가져옴
2. ECS에서 이미지를 실행하여 컨테이너(task) 생성
3. ECS에서 서비스 및 클러스터 관리, 모니터링

ECR

ECR(Amazon Elastic Container Registry)은 Docker 컨테이너 이미지를 저장하고 관리하는 AWS의 컨테이너 레지스트리 서비스이다. 도커 허브와 비슷한 기능을 하지만 AWS 환경에 최적화되어 있다. 주요 기능으로는 컨테이너 이미지 저장 및 관리, CI/CD 연동, 보안 및 스캔 기능 등이 있다.

ECR 이미지 업로드 및 배포 과정

1. 도커 이미지 빌드
2. ECR 로그인
3. ECR에 이미지 태깅
4. ECR에 이미지 푸시
5. ECR에서 컨테이너 배포

CI/CD

ECS과 ECR을 활용하여 다음과 같은 과정으로 CI/CD 파이프라인을 구성 할 수 잇다.

1. 코드 변경
2. Docker 이미지 빌드
3. ECR에 푸시
4. ECS가 자동으로 새로운 이미지 배포
5. 서비스 무중단 업데이트

• 프로젝트명: AI를 활용한 배달 REST API SERVER
• 진행 기간: 2025.02.12 ~ 2025.02.25
• 팀원: 이승욱, 김정환, 김지현, 오연주
• 목표: 광화문 근처에서 운영될 음식점들의 배달 및 포장 주문 관리, 결제, 그리고 주문 내역 관리 기능을 제공하는 플랫폼 개발

📊 개인 SWOT 분석

✅ 1. Strengths (강점 - 내가 잘한 점)

• Spring Security에서 예외 처리를 진행한 점
• 배포를 담당한 점
• 다른 팀원들의 질문에 적극적으로 대답해드리고 오류 사항을 같이 확인하며 해결함

⚠️ 2. Weaknesses (약점 - 부족했던 점)

• Refresh 토큰과 로그아웃 부분을 구현하려 했으나 시간 관계상 담당하지 않은 점
• 추가 기능을 더 적극적으로 구현하지 못한 점

🔍 3. Opportunities (기회 - 배울 기회가 있었던 부분)

• 그동안의 팀 프로젝트에서는 Spring security와 유저 관련 기능 구현을 맡은 부분
• 스프링 시큐리티와 JWT에 대한 기술적인 이해도, 구현 실력이 증가함
• 내가 어려워하던 부분에 도전하여 스스로의 성장을 도모함

⚡ 4. Threats (위협 - 나의 성장을 방해한 요소)

• 이 정도하면 되지 않았을까하는 안일한 마음이 순간적으로 들 때가 가장 나의 성장에 방해가 되는 것 같음

🎯 개선 방향 및 액션 플랜

• 개발 일정을 더 계획적으로 작성하여 더 많은 작업을 체계적으로 할 수 있도록 해야겠음
• 더 적극적으로 프로젝트에 임해서 내가 맡은 부분 이상의 성과를 내야겠다는 마음가짐

• 프로젝트명: AI를 활용한 배달 REST API SERVER
• 진행 기간: 2025.02.12 ~ 2025.02.26
• 팀원: 이승욱, 김정환, 김지현, 오연주
• 목표: 광화문 근처에서 운영될 음식점들의 배달 및 포장 주문 관리, 결제, 그리고 주문 내역 관리 기능을 제공하는 플랫폼 개발

📊 4L 회고

✅ 1. Liked (좋았던 점, 장점)

• 팀원분들이 각자 일을 가지고 하는게 다툼이 없었다.
• 공평하게 사다리타기로 진행되는 것도 나쁘지 않았다.
• 초반에 code with me를 통해 프로젝트의 세팅을 같이하여 오류를 줄인 것 같다.
• 오류가 생겼을 때 같이 해결하는 것이 좋았다.

📚 2. Learned (배운 점)

• refresh token에 대해서 공부하여 구현해봄
• docker를 사용하여 편리성을 깨달음
• 코드 convention의 중요성
• Scheduler의 사용법과 이점
• GlobalException의 사용법
• DDD 구조
• ERD설계에 관계형 DB와 비관계형 DB의 차이
• Spring security 예외 처리 방법

⚠️ 3. Lacked (부족했던 점, 단점)

• blacklist로 토큰 관리를 하지 못했었던 점
• test code를 작성하지 못했던 점

🔍 4. Longed for (아쉬웠던 점, 더 바랐던 것)

• 필수 요구사항만 구현했는데 조금 더 확장시켜보았으면 좋았을 것 같다.
• 개발 진행 중 필수 요구 사항을 발견하여 수정한 것
• JWT와 사용했던 기술들이 현업에서 어떻게 사용하는지 깊이 알아보지 못한 것
• 테스트 시간을 충분히 잡지 못한 것

🎯 다음 프로젝트를 위한 개선 방향

• 프로젝트에 사용될 기술 스택(MSA, CI/CD, Kafka)들을 좀 더 미리 공부해보는 게 좋을 것 같다.
• 일정 관리를 체계적으로 하여 더 많은 작업을 효율적으로 할 수 있도록 계획
• PR을 좀 더 세부적으로 작성할 수 있도록 연습해보는 것
• 매번 하는 CRUD가 아닌 다른 것도 도전해볼 수 있게 일정 조율을 하는 것이 좋을 것 같다.

Delivery 프로젝트 기능 구현을 마무리 하고 배포 단계에서 CI/CD를 할 것인지 의논하였으나 프로젝트 규모가 작아 그냥 배포만 하기로 결정하였다. 그런데 배포 과정에서 예상치 못한 오류를 만났으니... 트러블 슈팅을 정리해보자

gradle wrap

첫 번째 문제는 우리의 프로젝트 파일에 gradle-wrapper.jar 파일이 포함되지 않아서 발생했다. 이 파일이 존재하지 않으면 간단히 Gradle Wrapper를 초기화해서 파일을 생성해주면 된다. ec2 환경이니 gradle 설치부터 해주어야 한다.

우분투 기반의 EC2에서 그냥 apt install로 gradle을 설치하면 4.X의 낮은 버전이 설치된다. 우리 프로젝트는 JDK 17, Gradle 8.12.1 버전을 사용하므로 버전을 맞추기 위해 수동으로 설치해주어야 했다.

//gradle 설치
sudo wget https://services.gradle.org/distributions/gradle-8.12.1-bin.zip 

// 압축 해제
sudo unzip -d /opt/gradle gradle-8.12.1-bin.zip

// 환경 변수 설정
export PATH=$PATH:/opt/gradle/gradle-8.12.1/bin

gradle 설치 후 권한을 부여하고 wrap을 실행한다.

sudo chmod 777  gradle-wrapper.properties
sudo chmod 777  gradlew.bat

gradle wrap

...이렇게 하면 된다고 하는데 우리의 조그마한 t2.micro가 wrap 명령어 사용과 함께 CPU 사용률 100%를 찍고 뻗어버렸다. Gradle Daemon을 종료하고 시도한다던가 하는 방법을 GPT가 추천하긴 했지만 이 시점에 제출이 얼마 남지않아.. 시간이 얼마 없었으므로 gradle-wrapper.jar 파일을 그냥 로컬에서 직접 쏴서 때려 넣어버렸다. 아무튼 그렇게 해서 빌드는 성공했다.

Docker compose 리소스 부족

이제 docker compose up 명령어로 서버와 DB, 레디스를 띄웠는데.... CPU 사용률이 또 100%를 찍고 뻗어버렸다. 요청을 보내도 무한 로딩에 걸리질 않나 SSH 접속도 안되질 않나

문제 해결을 위해 인스턴스 종료 후 재시작한 뒤, docker-compose.yml 파일에 리소스 설정을 추가해주었다. t2.micro는 vCPU 1개, RAM 1GB를 제공하므로 이에 맞춰서 각각의 컨테이너의 CPU와 메모리 사용량을 제한하였다.

    deploy:
      resources:
        limits:
          cpus: "0.5"  # 최대 CPU 50% 사용
          memory: "400M"  # 최대 400MB RAM 사용

리소스 설정 후 재시작하니 잘 작동하여 배포가 성공적으로 이루어짐을 확인하였다!

예외 처리

이번 delivery 프로젝트에서 Spring Security를 사용하여 인증/인가 과정을 구현하고 Global Exception을 정의해 비지니스 로직에서의 전역적인 예외 처리를 구현해두었다. 그런데 필터에서 발생한 예외는 @ContollerAdvice에 잡히지 않으며 상태 코드만 클라이언트로 반환해준다.

우선 필터의 예외가 @RestControllerAdvice에 잡히지 않는 이유는 시큐리티 필터 체인의 구조 때문이다. 일반적인 비지니스 로직에서의 예외는 서버가 받은 요청이 컨트롤러에 도달한 이후 발생한다. 그러나 스프링 시큐리티는 요청이 컨트롤러에 도달하기 전, 필터 체인에서 예외를 발생시킨다. 즉 @RestControllerAdvice가 처리 가능한 영역이 아니다.

그래서 필터 체인에서 예외가 발생하면 시큐리티가 예외를 자체적으로 처리하고 status code만 클라이언트로 전송한다. 예외의 발생 원인을 클라이언트에서 알 수 있도록 커스터마이징하기 위해 예외 처리를 시도했다.

Authentication Entry Point

우선 인증(Authentication) 실패 시의 예외를 처리하기 위해서 AuthenticationEntryPoint을 구현해준다. 인증 실패시 401 Unauthorized 에러 코드와 메시지를 반환한다.

// 인증 예외 처리
@Component
@Slf4j(topic = "JwtAuthenticationEntryPoint")
public class JwtAuthenticationEntryPoint implements AuthenticationEntryPoint {

  @Override
  public void commence(HttpServletRequest request, HttpServletResponse response,
      AuthenticationException authException) throws IOException, ServletException {

    String errorMessage = authException.getMessage();
    log.error("Unauthorized error: {}", errorMessage);

    // 응답 에러 메시지 반환
    response.setStatus(HttpStatus.UNAUTHORIZED.value());
    response.setCharacterEncoding("UTF-8");
    response.getWriter().write(errorMessage);
  }
}

Access Denined Handler

인가(Authorization) 과정에서의 예외 처리는 AccessDeninedHandler에서 구현한다. 인가 실패 시 403 Forbidden 상태 코드와 에러 메시지를 반환한다.

// 인가 예외 처리
@Component
@Slf4j(topic = "JwtAccessDeniedHandler")
public class JwtAccessDeniedHandler implements AccessDeniedHandler {

  @Override
  public void handle(HttpServletRequest request, HttpServletResponse response,
      AccessDeniedException accessDeniedException) throws IOException, ServletException {

    String errorMessage = accessDeniedException.getMessage();
    log.error("Forbidden error: {}", errorMessage);

    response.setStatus(HttpStatus.FORBIDDEN.value());
    response.setCharacterEncoding("UTF-8");
    response.getWriter().write(errorMessage);
  }
}

트러블슈팅

여기까진 이론이고 실제로 프로젝트에 적용하면서는 원하는 대로 응답이 오지 않아 꽤 많은 시행착오를 거쳤다. 그 중 가장 골치 아팠던 문제들이 아래와 같다.

1. unsuccessfulAuthentication()

첫 번째는 validateToken()에서 던져진 예외들이 잡히지 않아서 응답이 제대로 오지 않는 다는 것이었다.

로그인 실패 로그를 보니 JwtAuthenticationEntryPoint까지 예외가 전파되지 않고 JwtAuthenticationFilter에서 처리되어 끝나버렸는데 이유는 내가 이 필터 안에 unsuccessfulAuthentication() 메서드를 오버라이딩 해놨기 때문이었다..... 여기서 401로 response를 던졌기 때문에 예외 처리가 이미 된 것이다... (안돼서 삽질을 엄청나게 했는데 말이다

  @Override
  protected void unsuccessfulAuthentication
      (HttpServletRequest request, HttpServletResponse response, AuthenticationException failed)
      throws IOException, ServletException {
    log.error(failed.getMessage());
    response.setStatus(401);
  }

resopnse 를 던지는 대신 entrypoint의 commence를 호출하도록 수정해서 예외를 전파시켰다.

@Override
  protected void unsuccessfulAuthentication
      (HttpServletRequest request, HttpServletResponse response, AuthenticationException failed)
      throws IOException, ServletException {
    jwtAuthenticationEntryPoint.commence(request, response, failed);
  }

2. Global Exception 처리

두 번째는 response에 Global Exception의 메시지가 응답으로 오는 것이 아니라 spring security의 기본 에러 메시지가 온다는 문제였다. 에러 로그를 보면 발생시킨 exception이 확인이 되는데 정작 메시지는 Full authentication is required to access this resource 이런게 오더라... 이걸 해결하기 위해 Global Exception을 던지지 않고 AuthenticationException을 상속받은 CustomAuthenticationException을 정의해서 던졌는데도 잡히지 않았다.

그래서 디버깅을 돌렸더니 AuthenticationException의 인스턴스가 InsufficientAuthenticationException인 걸 발견하게 되었다. 찾아보니 스프링 시큐리티의 예외 처리 흐름에서 내 custom exception이 wrap 되어 버려서 커스텀 예외처리의 의미가 없다나... 간단하게 말하자면 덮어쓰기 된거다.

이걸 해결하고 원하는 응답값을 주려면 InsufficientAuthenticationException을 직접 또 정의해서 던져주면 되기야 하겠지만 이렇게 되면 커스텀 응답 처리의 의미가 있나 싶어졌고... 이 부분은 그냥 Exception Filter를 통해 처리하기로 결정했다.

Exceptoin Filter를 가장 앞단에 배치시켜서 Authorization 인가 과정에서 발생하는 Global Exception을 잡아 처리했다.

// web security config
http.addFilterBefore(jwtExceptionFilter, UsernamePasswordAuthenticationFilter.class);

// jwt exception filter
try {
      filterChain.doFilter(request, response);
    } catch (GlobalException e) {
      log.error("ERROR: {}, URL: {}, MESSAGE: {}", e.getStatus(),
          request.getRequestURI(), e.getMessage());

      response.setStatus(HttpStatus.UNAUTHORIZED.value());
      response.setCharacterEncoding("UTF-8");
      response.getWriter().write(e.getMessage());

드디어 원하는 응답으로 예외 처리를 성공했다!

이번 delivery 프로젝트에서 유저 기능 구현을 담당하게 되어 JWT 토큰 방식의 로그인을 구현 하던 중 토큰을 쿠키에 저장할지 헤더에 저장할지 고민이 생겼다. 두 가지 방식은 각각의 장단점이 존재한다.

Cookie

쿠키(Cookie)에 저장하는 방식은 서버가 JWT를 발급하여 쿠키에 저장한 뒤, 클라이언트로 전송하는 방식으로, 클라이언트는 자동으로 이후 요청에 쿠키를 포함한다.

장점

• 자동 전달 : 클라이언트가 자동으로 쿠키를 요청에 포함시키므로, 별도의 토큰 관리 로직이 필요하지 않다.
• XSS 공격 방지 : HttpOnly 쿠키를 사용하면 JavaScript로 쿠키에 접근할 수 없다.

단점

• CSRF 공격에 취약 : 쿠키가 자동으로 요청에 포함되므로 CSRF 공격에 노출될 수 있다.
• 도메인 제약 : 쿠키는 도메인 단위로 관리되므로 여러 도메인 간에 토큰 공유가 어렵다.
• 사이즈 제한 : 쿠키에 크기 제한 (약 4KB)이 있어 토큰의 크기가 커질 경우 문제가 될 수 있다.

Header

헤더(Header)에 저장하는 방식은 클라이언트가 JWT를 로컬 저장소에 저장해두고 HTTP 요청 헤더에 JWT를 포함하여 전송힌다.

장점

• CSRF 위험 감소 : 쿠키를 사용하지 않으므로 상대적으로 CSRF 공격에 안전하다.
• 유연성 : 클라이언트 측에서 토큰을 직접 관리하므로 토큰의 저장 및 전송 방식을 원하는 대로 커스터마이징할 수 있다.
• 도메인 독립성(CORS) : 헤더에 저장된 토큰은 특정 도메인에 묶이지 않고 사용할 수 있으므로 특히 MSA와 같은 환경에서 다양한 도메인간의 통신 시 유리하다.

단점

• XSS 위험 : 로컬이나 세션 스토리지에 저장하는 경우, JavaScript로 접근 가능하므로 XSS 공격에 취약할 수 있다.
• 복잡성 : 클라이언트에서 토큰을 저장하고 요청마다 헤더에 추가하는 로직을 직접 구현해야 한다.

결론

사실 쿠키와 헤더 방식 중에서는 일반적으로 헤더 방식이 더 많이 사용된다. 헤더 방식은 서버에 부담이 덜 하고 쿠키 방식은 도메인의 제약이 크기 때문이다. 특히나 서버의 확장성과 유지보수성을 고려한다면 헤더 방식으로 선택하는 것이 좋다.

Q. 자바에서 Checked Exception과 Unchecked Exception에 대해 설명해주세요.

A. Checked Exception은 컴파일 예외로, 컴파일 시점에 확인되며 반드시 예외 처리를 해야한다. Unchecked Exception은 런타임 예외로, 프로그램 실행 중에 발생하며 예외 처리를 강제하지 않는다.

Checked Exception

컴파일러가 체크하는 예외이며 개발자가 명시적으로 try-catch 블럭 또는 throws을 사용해 예외를 처리해야한다. 컴파일 에외는 예외 처리를 하지 않으면 프로그램을 실행할 수 없다.

Runtime Exception

런타임 시점에 발생하는 예외로, 프로그래머의 실수나 코드의 논리적인 오류로 인해 발생한다. 자바에서는 RuntimeException을 상속한 예외들이 해당된다. 컴파일러가 예외 처리를 강제하지는 않지만 프로그래머가 적절히 처리해야한다.

Error VS Exception

Error는 주로 JVM에서 발생하는 회복이 어려운 문제나 오류로, 시스템 레벨에서 발생하는 오류이다. 일반적으로 프로그램에서 처리하지 않으며 애플리케이션 코드에서 복구할 수 없는 심각한 문제를 나타낸다. Exception은 프로그램 실행 중 발생할 수 있는 오류 상황을 나타낸다. 대부분 회복 가능성이 있으며 예외 처리를 통해 프로그램 내에서 오류 상황을 제어할 수 있다.

API 명세

도메인 : 사용자(User), 음식점(Store), 음식(Food), 주문(Order), 리뷰(Review), 주소(Address)

ERD

아키텍처

스프링 클라우드는 마이크로서비스 아키텍쳐(MSA) 기반의 시스템 구축을 도와주는 스프링 프레임워크의 확장이다. MSA 환경에서는 서비스 간 통신, 로드 밸런싱, 분산 구성 관리 등의 다양한 기능이 필요한데 스프링 클라우드는 이러한 기능을 손쉽게 구현할 수 있도록하는 다양한 모듈을 제공한다.

주요 기능

1. 서비스 디스커버리 (Service Discovery)

MSA 환경에서는 각 서비스의 위치(IP 및 포트)가 동적으로 변할 수 있다. 따라서 각각의 서비스들을 등록 및 검색할 수 있는 중앙 저장소 역할의 도구가 필요하다. 이를 통해 서비스 간의 동적 연결을 지원한다.

• Eureka Netflix OSS 기반의 서비스 디스커버리 도구. 서비스 인스턴스가 실행될 때 자동으로 등록되며,클라이언트는 Eureka 서버를 통해 서비스의 위치를 조회할 수 있다. 로드 밸런싱과 장애 감지를 통한 서비스 회복 기능을 제공한다.

2. API 게이트웨이 (API Gateway)

모든 클라이언트의 요청을 한 곳에서 관리하는 진입점 역할. 클라이언트와 마이크로서비스 간의 통신을 중재하고, 요청을 적절한 서비스로 라우팅한다. 또한 인증/인가, 로깅, 부하 분산 등의 기능을 제공한다.

• Zuul Netflix OSS 기반의 API 게이트웨이. 요청 라우팅, 필터링, 보안 등의 기능을 제공한다.
• Cloud Gateway 스프링 클라우드에서 제공하는 API 게이트웨이. 비동기 및 논블로킹 방식으로 동작하여 Zuul 보다 더 높은 성능을 제공한다.

3. 로드 밸런싱 (Load Balancing)

클라이언트 요청을 여러 인스턴스에 분배하여 부하를 균형있게 조절한다.

• Ribbon Eureka와 연동하여 서비스 인스턴스 목록을 가져와 동적으로 로드 밸런싱을 수행할 수 있다. 클라이언트는 Ribbon을 통해 서비스에 대한 여러 개의 인스턴스 중 하나를 선택하여 요청을 보내는 방식으로, 클라이언트 사이드 로드 밸런싱 방식이라고도 한다. 분산 전략으로 라운드 로빈, 가중치 기반 등 다양한 로드밸런싱 알고리즘을 지원한다.

4. 서킷 브레이커 (Circuit Breaker)

서킷 브레이커는 마이크로서비스 간의 호출 실패를 감지하고 지연이나 실패를 처리하여 시스템의 전체적인 안전성을 유지하는 역할을 하며 빠르게 장애 부분을 격리하고 시스템의 다른 부분에 영향을 주지 않도록 한다.

• Hystrix Netflix OSS 기반의 서킷 브레이커 라이브러리.
• Resilience4j Hystrix의 대체 도구로, 경량화되고 모듈화된 자바 기반의 서킷 브레이커 라이브러리. 서킷 브레이커가 open되면 특정 임계치를 초과한 요청을 차단하고, 일정 시간이 지나면 다시 정상 동작을 시도할 수 있다. 실패 시 Failback 매커니즘을 통해 대체 동작을 수행한다.

5. 설정 관리 (Config Server)

여러 마이크로서비스의 설정을 중앙에서 관리하고, 변경 사항을 실시간으로 반영하도록 할 수 있다.

• Spring Cloud Config 중앙 집중식 구성 관리를 제공하는 프레임워크. Spring Cloud Bus를 사용하면 서비스 재시작 없이도 설정 반영이 가능하다.

6. 분산 추적

분산 시스템에서 서비스 간의 요청 흐름을 추적하여 모니터링하는 기능이다.

• Zipkin 각 요청에 고유한 추적 ID를 부여하여 요청의 흐름을 시각화 할 수 있다. 요청의 시작부터 끝까지의 경로를 추적하여 지연 시간, 오류 등의 정보를 수집한다. 또한 특정 요청을 검색하고 필터링하여 문제를 진단할 수 있다.

7. 이벤트 드리븐 아키텍처 (Event-Driven Architecture)

이벤트 드리븐 아키텍처는 시스템에서 발생하는 이벤트를 기반으로 동작하는 소프트웨어 설계 방식이다. 이벤트는 비동기적으로 처리되며, 서비스 간의 결합도를 낮추고 확장성을 높인다.

• Spring Cloud Stream 이벤트 드리븐 아키텍처를 구현하기 위한 프레임워크. 메시지 브로커(Kafka, RabbitMQ 등)를 통해 이벤트 스트리밍을 처리한다. 예시로 알림 기능 등이 있다.

MSA

MSA(Microservices Architecture)란 하나의 애플리케이션을 여러 개의 독립적인 서비스로 분리하여 개발, 배포, 유지보수를 용이하게 하는 소프트웨어 아키텍처 스타일로, 모든 기능이 하나의 애플리케이션 내에 포함되는 모놀리식 아키텍처(Monolithic Architecture)와 반대되는 개념이다. 각 서비스는 특정 비지니스 기능을 수행하며 서로 독립적으로 동작하고 API를 통해 통신한다.

주요 특징

• 서비스 분리 : 애플리케이션을 여러 개의 독립적인 마이크로 서비스로 분리하며 각 서비스는 특정 기능을 담당
• 독립성 : 각 서비스는 독립적으로 배포 및 운영이 가능하며 특정 서비스만 개별적으로 확장이 가능하다. 서비스 간의 의존성을 최소화하여 하나의 서비스에 문제가 생겨도 다른 서비스에 영향을 미치지 않는다.
• 분산 데이터 관리 : 서비스마다 각각의 데이터베이스를 가질 수 있다. 데이터의 일관성을 유지하기 위해 이벤트 기반 아키텍처를 사용할 수 있다.
• 서비스 간 통신 : 주로 RESTful API, gRPC, 메시지 큐 등을 통해 이루어진다.

구성 요소

• API Gateway : 클라이언트의 요청을 받아 내부 서비스로 라우팅한다. 인증, 로깅, 로드 밸런싱의 역할을 수행한다.
• Eureka (Service Discovery) : 각 서비스의 위치를 동적으로 찾도록 도와주는 서비스 레지스트리의 역할을 한다.
• Config Server : 각 마이크로서비스들의 설정 정보를 중앙 관리한다.

[외부 클라이언트]
       │
       ▼
[ API Gateway ] 
   ┌───┴───┐
   ▼       ▼
[User]  [Order]  [Payment]  ← 마이크로서비스
   ▲       ▲         ▲
   │       │         │
[ Eureka (Service Discovery) ]  ← 서비스 등록 및 검색
   ▲
   │
[ Config Server ]  ← 중앙 구성 관리

장점

• 독립성 : 특정 서비스만 업데이트 가능하며 각각의 서비스를 독립적으로 개발 할 수 있다.
• 확장성 : 트래픽이 많은 서비스만 개별적으로 확장 할 수 있어 비용 절감이 가능하다.
• 장애 격리 : 특정 서비스에 장애가 발생해도 전체 시스템이 다운되지 않는다.

단점

• 복잡성 : 서비스가 많아질수록 구현, 배포, 모니터링, 로깅이 어렵다. 또한 여러 서비스를 관리하기 위한 추가적인 인프라가 필요하다.
• 네트워크 지연 : 각 서비스의 호출이 많아지면 성능 저하가 발생할 수 있다.
• 데이터 일관성 : 각 서비스가 독립된 DB를 가지면 트랜잭션 처리가 어렵다.

MA VS MSA

RDS

RDS 인스턴스 생성

1. AWS RDS 대시보드에서 "데이터베이스 생성" 클릭
2. 데이터베이스 엔진 선택 (EX. MySQL)
3. 템플릿 - 프리티어 선택
4. DB 인스턴스 식별자, 마스터 사용자 이름, 암호 설정
5. 퍼블릭 엑세스 설정

• 허용시 : 외부(로컬 컴퓨터, EC2 등)에서 접속 가능 / 다만, AWS 정책 변경으로 프리티어에서도 과금됨
• 비허용시 : EC2에서 RDS의 프라이빗 엔드포인트로 접속

6. VPC 보안 그룹 생성
7. 추가 구성 - 초기 데이터베이스 설정 (필요시)

보안 그룹 설정

RDS 보안그룹의 인바운드 규칙을 편집하여 EC2 또는 외부에서 접근 가능하도록 한다.

• 유형 : MYSQL/Auora
• 포트 : 3306
• 소스(퍼블릭) : 0.0.0.0/0
• 소스(프라이빗) : (EX. EC2 보안그룹으로 제한) ⚠️ 프라이빗 접근으로 설정했다면 EC2와 RDS를 같은 VPC&서브넷에 배치하면 된다.

파라미터 그룹 설정

RDS 환경에 맞는 파라미터를 설정하여 타임존, 문자 인코딩, 데이터 정렬 기준 등에 대한 설정을 할 수 있다. 아주 간단한 프로젝트 환경이라면 꼭 필요하진 않다.

1. RDS 파라미터 그룹 생성 및 세부 정보 설정
2. 파라미터 편집에서 세부 설정 진행

• time_zone : Asia/Seoul
• character_set_* : utf8mb4
• collation_* : utf8mb4_general_ci

3. RDS 데이터베이스 옵션에서 파라미터 그룹 선택

🔗 Spring Boot의 설정 파일에 DB URL 설정

url = jdbc:mysql://[RDS 엔드포인트]:3306/[Database]

EC2

EC2 인스턴스 생성

1. AWS EC2 대시보드에서 "인스턴스 시작" 클릭
2. AMI 선택 (이하 Ubuntu 선택 기준)
3. 인스턴스 유형 선택 (프리티어 - t2.micro)
4. 키 페어 발급 후 저장
5. 보안 그룹 생성

보안 그룹 설정

인바운드 규칙을 추가하여 접근 허용

• 포트 22 : SSH
• 포트 80 : HTTP
• 포트 443 : HTTPS
• 포트 8080 : Spring Boot

SSH로 EC2 접속

로컬 컴퓨터(mac) 터미널에서 접근 가능하다.

# 1. 키페어 권한 변경
sudo chmod 600 [key.pem]

# 2. EC2 접속
ssh -i key.pem [ubuntu]@[ec2-public-ip]

EC2 인스턴스에서 "연결"을 선택하여 웹 콘솔로도 접속할 수 있다.

Spring Boot

스프링부트 애플리케이션을 빌드하여 JAR 파일을 생성 한뒤 EC2에 전송해서 실행시키면 배포가 완료된다.

1. 인텔리제이 Gradle 탭의 bootjar를 클릭하면 build > libs 폴더에 jar 파일이 생성된다.
2. 로컬(mac)에서 EC2로 jar 파일을 전송한다.

   scp -i key.pem app.jar ubuntu@ec2-public-ip:/home/ubuntu/

3. EC2에 JDK를 설치한다.

   sudo apt-get update
   sudo apt install openjdk-17-jdk

4. jar 파일을 실행시킨다.

   java -jar [app.jar]
   

백그라운드 실행

nohup java -jar [app.jar] &

실행 종료

ps -ef | grep -java kill -9 [pid]

이렇게 배포 한뒤 `http://[public ip]:8080/` 으로 접속하면 확인할 수 있다.

## 환경 변수
설정 파일의 민감 정보를 환경 변수로 관리하고 있다면 EC2 터미널에서 직접 환경 변수를 설정하여 사용할 수 있다.
```bash
# .bashrc 파일에 추가하여 환경 변수 영구 설정
sudo echo 'export EX_VAR=value' >> ~/.bashrc
source ~./bashrc

포트포워딩

jar 파일을 실행시킨 뒤 배포하여 웹 서비스에 접속하려면 주소 뒤에 8080 포트 번호를 항상 붙여주어야 한다. HTTP 요청에서는 80 포트가 기본으로 사용되므로 80 포트로 전달되는 요청을 자동으로 8080으로 전달하는 포트포워딩(port forwarding)을 설정하면 포트 번호를 입력하지 않아도 된다.

EC2 터미널에서 포트포워딩 설정

sudo iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 8080

• iptables : 리눅스의 네트워크 관리 도구
• -t nat : nat 주소 변환 테이블
• -A PREOUTING : PREOUTING 체인에 규칙 추가
• -i eth0 : eth0 네트워크 인터페이스
• --dport : 패킷의 목적지 포트
• --to--port : 리다이렉션할 포트

⚠️ 네트워크 인터페이스가 다를 경우 확인 후 수정

# 네트워크 인터페이스 확인
ip -a

포트포워딩 후 http://[public ip] 로 접속하여 확인