잦은 업데이트로 인한 서버 및 데이터베이스 트래픽 증가

MFC에서 파트너의 포스팅, 파트너의 팔로우 등을 관리하는 SNS 서비스를 구현했는데, 이 중 사용자가 포스팅 좋아요 등록/취소나 파트너 팔로우 추가/취소 버튼을 계속해서 클릭했을 때 각 작업에 대해 업데이트 구문이 발생하게 되는데, 이 부분에서 MySQL 서버에 계속 접근하는 과정에서 너무 많은 부하를 발생시키지 않을까? 라는 생각이 들었다.

실제로 동시에 한 포스팅 혹은 파트너에 대해 n명의 사용자가 좋아요나 팔로우를 등록하기만 해도 총 n건의 업데이트문이 발생하게 된다. 업데이트문이 실행될 때마다 MySQL 서버에 접근하게 되고, 이러한 작업이 동시에 많이 발생하게 되면 그만큼 부하가 증가하여 처리 속도가 길어지게 된다.

💡 해결 방안 : 배치 서버 도입

🌟 배치 서비스 도입 : 업데이트 내역을 집계하여 배치로 한 번에 업데이트 처리

배치 로직 자체는 SSG.COM 프로젝트에서 적용했던 배치 처리와 유사하지만, 이번 프로젝트는 MSA 환경으로 구성되어 있기 때문에 처리 로직이 더 복잡해질 수 밖에 없다..

일단 전반적인 로직은 SNS 서비스에서 업데이트 작업 발생하면 Kafka를 통해 포스팅/파트너 ID와 업데이트 내역을 배치 서비스에 전달하고, 배치 서비스에서는 이를 Redis에 집계해두었다가 스케줄러를 통해 특정 시간마다 업데이트 내역을 MySQL에 최종적으로 반영 하도록 구성하였다.

여기서 업데이트 내역을 최대한 빠르게 반영하기 위해 스케줄러 실행 간격을 초 단위로 설정하였다. 이외에도 해당 로직을 구성하기 위해 고민했던 2가지의 문제를 아래에 자세히 설명해보겠다.

🤔 고민

1. 배치 로직 구현 : 기존 서비스 VS 배치 서버 분리

이전에는 모놀리식 구조였기 때문에 비즈니스 로직과 배치 로직이 하나의 서비스에 구현되었지만, 이번 프로젝트는 MSA 환경이였기 때문에 많은 고민을 했는데,, 결국 배치 서버를 분리하기로 한 이유는 아래와 같다,,

• 다른 서비스에서도 배치 로직이 필요했는데, 이를 각 서비스에서 관리하기 보다는 하나의 서비스에서 일괄 관리하는 것이 효율적이라고 판단함

• 배치 로직이 짧은 간격으로 실행되기 때문에, 배치 로직에서 많은 자원을 사용하게 되면 다른 비즈니스 로직의 실행에 영향을 미치게 됨

• 장애 전파를 최소화하기 위한 MSA의 장점을 살려, 배치 서비스에서 문제가 발생해도 기존 서비스는 정상적으로 실행될 수 있도록 설계

  
  

이를 구현하기 위해서는 SNS 서비스 업데이트 내역을 배치 서비스로 전달하기 위한 로직이 추가적으로 필요했고, 이는 Kafka를 통해 구현하였다. Kafka를 선택하게 된 이유와 데이터 전달 로직과 관련된 자세한 내용은 이 글에서 자세히 다루고 있다! (데이터 전달 관련은 이 부분은 아니긴 함..)

2. 업데이트 내역 집계 : Map VS Redis

배치 서비스는 전달받은 데이터를을 사용하여 다음 스케줄러가 실행되기 전까지의 업데이트 내역을 집계해야 한다. (ex : 30초 사이에 n번 글의 좋아요 개수가 4개 증가 → n, +4)

각 ID 별로 내역을 집계해야 하기 때문에 <ID : 업데이트 내역>, 즉, <Key, Value> 형태로 데이터를 저장할 수 있는 Map과 Redis 중에 고민하다가,, 최종적으로 Redis를 선택하게 된 이유는 다음과 같다.

• Map은 메모리 기반이기 때문에 애플리케이션 서버가 꺼지면 저장된 데이터가 휘발되지만, Redis는 별도의 데이터베이스 서버 기반으로 동작하므로 애플리케이션의 서버가 꺼져도 저장된 데이터가 유지됨

• 빠른 데이터 접근 및 대규모 데이터 저장에 적합

💻 구현

포스팅과 파트너 처리 로직이 동일하므로, 포스팅 관련 작업에 대한 코드만 작성 + 배치 처리 로직이 중요하므로 Config, Controller 등의 일부 내용은 생략될 예정!

1. SNS 서비스

✅ 포스팅 좋아요 등록/취소 요청 시 ID, 업데이트 내역을 배치 서비스로 *전송 *

- KafkaProducer, PostSummaryDTO

@Service
@RequiredArgsConstructor
public class KafkaProducer {
    private final KafkaTemplate<String, Object> kafkaTemplate;

    public void createBookmark(PostSummaryDto dto) { // 좋아요 등록
        kafkaTemplate.send("create-bookmark", dto);
    }

    public void deleteBookmark(PostSummaryDto dto) {
        kafkaTemplate.send("delete-bookmark", dto); // 좋아요 취소
    }
}

@Getter
@Builder
public class PostSummaryDto {
    private Long postId;
    private String partnerId;
}

지금 와서 드는 생각인데,, producer를 두 개로 분리하지 말고 producer는 하나만 두고 DTO에 업데이트 상태?(등록/취소)를 구분하는 추가해서 분기점 두고 구현하는 게 훨씬 덜 복잡하기 편했을 것 같기도,,

- BookmarkServiceImpl

• createBookmark : 좋아요 내역 저장 후, 메시지 생성
• deleteBookmark : 좋아요 취소 시, 좋아요 내역 삭제 후 메시지 생성

@Service
@Transactional
@Slf4j
@RequiredArgsConstructor
public class BookmarkServiceImpl implements BookmarkService {
    private final BookmarkRepository bookmarkRepository;
    private final KafkaProducer producer;

    @Override
    public void createBookmark(Long postId, String userId) { // 좋아요 등록
        if(bookmarkRepository.existsByPostIdAndUserId(postId, userId)) {
            throw new BaseException(BOOKMARK_CONFLICT);
        }

        bookmarkRepository.save(Bookmark.builder()
                .userId(userId)
                .post(postId)
                .build());

        producer.createBookmark(PostSummaryDto.builder().postId(postId).build());
    }

    @Override
    public void deleteBookmark(Long postId, String userId) { // 좋아요 취소
        int cnt = bookmarkRepository.deleteByPostId(postId, userId);
        if(cnt > 0) producer.deleteBookmark(PostSummaryDto.builder().postId(postId).build());
    }
}

2. 배치 서비스 (1) : 업데이트 내역 집계

✅ 업데이트 내역을 Redis에 집계

- KafkaConsumer

• createBookmark : increment(key, 1)을 통해 key번 글의 좋아요 개수 +1
• deleteBookmark : decrement(key, 1)을 통해 key번 글의 좋아요 개수 -1

@Service
@RequiredArgsConstructor
@Slf4j
@Transactional
public class KafkaConsumer {
    private final PostSummaryRepository postSummaryRepository;
    private final RedisTemplate<String, Object> redisTemplate;
    private static final String POST_PREFIX = "post:like:";

    @KafkaListener(topics = "create-bookmark", containerFactory = "postSummaryListener")
        String key = POST_PREFIX + dto.getPostId();
        redisTemplate.opsForValue().increment(key, 1);
    }

    @KafkaListener(topics = "delete-bookmark", containerFactory = "postSummaryListener")
    public void deleteBookmark(PostSummaryDto dto) {
        String key = POST_PREFIX + dto.getPostId();
        redisTemplate.opsForValue().decrement(key, 1);
    }
}

3. 배치 서비스 (2) : 배치 로직 구현 및 실행

✅ Redis의 집계 내역을 MySQL에 최종적으로 반영 → 30초 간격으로 실행

- PostJobConfig

• sacnKeys(pattern) : Redis 내에 저장된 다양한 업데이트 내역 중, 구별자를 통해 포스팅 관련 데이터만 조회하기 위한 메서드

private Set<String> scanKeys(String pattern) {
    Set<String> keys = new HashSet<>();
    ScanOptions options = ScanOptions.scanOptions().match(pattern).count(1000).build();

    try (Cursor<byte[]> cursor = redisTemplate.getConnectionFactory()
            .getConnection()
            .scan(options)) {

        while (cursor.hasNext()) {
            keys.add(new String(cursor.next()));
        }
    } catch (Exception e) {
        throw new RuntimeException("Failed to scan Redis keys", e);
    }
    return keys;
}

• ItemReader : Redis에서 포스팅 관련 내역을 조회하여 포스팅 ID와 업데이트 내역을 PostBookmarkDTO 형태로 저장했다면, Redis에는 다음 기간동안의 집계 내역을 새로 저장해야 하므로 기존의 집계 내역 삭제

@Bean(name = "postReader")
@StepScope
public ItemReader<PostBookmarkDto> postSummaryItemReader() {
    Set<String> keys = scanKeys("post:like:*");
    List<PostBookmarkDto> bookmarkList = new ArrayList<>();

    for (String key : keys) {
        Long postId = Long.valueOf(key.replace("post:like:", ""));
        Integer bookmarkCnt = Integer.valueOf((String)redisTemplate.opsForValue().get(key));

        bookmarkList.add(new PostBookmarkDto(postId, bookmarkCnt));
        redisTemplate.delete(key);
    }
    return new ListItemReader<>(bookmarkList);
}

• ItemProcessor : PostBookMarkDTO → PostSummary 변환 시, 기존 좋아요 개수 + 업데이트 내역
• ItemWriter : MySQL에 업데이트 내역 최종 반영

@Bean(name = "postProcessor")
@StepScope
public ItemProcessor<PostBookmarkDto, PostSummary> postSummaryProcessor() {
    return dto -> {
        PostSummary summary = postSummaryRepository.findByPostId(dto.getPostId())
                .orElseThrow(() -> new BaseException(BaseResponseStatus.POST_NOT_FOUND));

        return PostSummary.builder()
                .id(summary.getId())
                .postId(dto.getPostId())
                .bookmarkCnt(summary.getBookmarkCnt() + dto.getBookmarkCnt())
                .build();
    };
}

전체 코드는 너무 길어서,, 깃허브에서 확인 가능!

- JobScheduler

@Slf4j
@Configuration
public class JobScheduler {
    private final JobLauncher jobLauncher;
    private final Job postSummaryJob;

    @Scheduled(fixedRate = 30000) // 30초 간격으로 실행
    public void postJobSchedule() throws Exception {

        JobParameters jobParameters = new JobParametersBuilder()
                .addLocalDateTime("time", LocalDateTime.now())
                .toJobParameters();

        JobExecution postJob = jobLauncher.run(postSummaryJob, jobParameters);
    }
}

⚙️ 실행

초기 데이터

실행 결과

• 14번 포스팅에 사용자 A, B, C가 좋아요 등록 (+3)

• 20번 포스팅에 사용자 A, B, C가 좋아요 등록 후, A가 좋아요 취소 (+3-1=+2)
• 25번 포스팅에 사용자 B가 좋아요 등록 후, 취소 (+1-1=0)

: kafkaConsumer에서 집계 과정에 로그를 찍어서 확인해본 결과, 좋아요 등록텍스트 시에는 집계값+1, 취소 시에는 집계값-1을 수행하는 것을 확인할 수 있다!

: 배치 실행 후 ItemWriter에서 실행된 쿼리를 보면, 총 2개의 업데이트문이 실행된 것을 확인할 수 있다. 25번 포스팅의 경우 등록과 취소가 한 번에 이루어져 집계값이 0이기 때문에 값이 변하지 않았고, 이로 인해 JPA의 변경 감지가 적용되지 않아 업데이트문이 별도로 실행되지 않았다.

업데이트문은 각 포스팅에 대해 실행되기 때문에 N개의 포스팅에 대한 업데이트가 발생하면 N개의 업데이트문이 실행되기는 하겠지만, 그래도 위 작업들을 배치 처리 없이 각자 업데이트 처리 했다면 3개의 포스팅에 대해 총 9개(14번 3개, 20번 4개, 25번 2개)의 업데이트문이 발생했을 것이다. 쿼리 개수가 줄어든 것은 물론이고, 다수의 업데이트문이 하나의 트랜잭션으로 처리되므로 DB 서버에 대한 접근이 줄어 트래픽 수 또한 줄일 수 있을 것이다!

➕

그러나 이를 완벽한 해결책이라고 볼 수는 있을까? 처음에는 집계 처리 과정에서 발생하는 업데이트 처리 최적화에 대해서만 고민해서 위와 같은 해결책을 생각했었는데, 배치 로직을 구현하다 보니 Redis에 접근하거나, 변경 감지를 위한 SELECT문 추가 실행에 대한 트래픽 문제가 신경쓰이기 시작했다,, 변경 감지의 경우 JPA를 사용하지 않으면 해결될 것 같기도 하고?,, 하여튼 이 부분에 대해서는 더 고민해봐야 할 것 같다,,!

대용량 데이터를 효율적으로 일괄(배치) 처리하기 위한 프레임워크

: Spring Batch 로깅/추적, 트랜잭션 관리, 작업 재시작/건너뛰기, 작업 처리 통계, 리소스 관리 등 배치 처리에 필요한 다양한 기능들을 제공

📒 용어

배치 처리 시 사용되는 기본적인 객체 및 테이블명 정리!

• Job *: *한 번에 처리해야 할 배치 작업 단위(객체)

• JobInstance : Job의 논리적 실행 단위 → 실행될 때마다 새로운 JobInstance 생성

• JobParameter : Job이 실행될 때 필요한 파라미터를 제공하고, 이를 통해 JobInstance를 구분 → String, Double, Long, Date 타입 지원

• JobExecution : JobInstance 실행 시도에 대한 객체 → 시작/종료시간, 상태 등에 대한 정보를 담고 있으며, 실패 후 재시도 시 별도의 JobExecution 생성

• Step : 처리해야 할 작업 내용(단계) → Job은 하나 이상의 Step으로 이루어지며, 각 Step은 순차적으로 처리됨

• StepExecution : Step의 실행 시도에 대한 객체 → JobInstance와 유사하며, read/write/commit/skip 수 등의 정보도 저장

• ExecutionContext : Step 혹은 Job의 실행 중에 발생하는 데이터를 저장하고 공유 → 작업 실패 시, ExecutionContext에 저장된 데이터를 통해 마지막 실행 상태를 재구성하여 작업 수행

  • JobExecutionContext : Commit 시점에 저장
  • StepExecutionContext : 실행 사이에 저장

• JobRepository : 배치 처리와 관련된 모든 정보(Job/StepExecution, JobParameters)를 저장하고 관리

• JobLauncher : Job과 JobParameters를 사용하여 Job을 실행하고, 생명주기를 관리

• ItemReader : 배치 작업에서 처리할 아이템(데이터)을 읽어오기 위한 인터페이스

• ItemProcessor : ItemReader로부터 읽어온 데이터를 처리(필터링, 변환 등)하기 위한 인터페이스

• ItemWriter : 배치 처리된 데이터를 최종적으로 기록(DB에 저장, 파일 생성, 메시지 발행 등)하기 위한 인터페이스

• Tasklet : 간단한 단일 작업 시 사용

• Chunk : 한 번에 처리 될 row수를 의미하는 Chunk라는 단위를 생성하고, 해당 단위로 트랜잭션을 수행 → 주로 대용량 데이터 처리 시 사용되며, Reader, Processor, Writer 단계를 거침

💻 구현

Spring Boot 3.x + Spring Batch 5.x 버전 사용!

⚙️ 설정

- build.gradle

implementation 'org.springframework.boot:spring-boot-starter-batch' # batch
implementation 'org.springframework.boot:spring-boot-starter-quartz' # 스케줄러

- application.yml

• job.enabled : 서비스가 실행될 때, 배치 작업을 자동으로 실행할 것인지에 대한 설정

  • true : 서비스 실행 시 배치 실행 / false : 실행 X

• jdbc.initialize-schema : 배치 관련 메타 테이블 생성 여부

  • always : 항상 생성 / embedded : 내장 DB인 경우, 생성 / never : 생성하지 않음

spring:
  batch:
    job:
      enabled: false
    jdbc:
      initialize-schema: always

만약 jdbc:initialize-schema: always 임에도 테이블이 생성되지 않는다면, schema-db명.sql 파일을 찾아서 스크립트를 복사한 후 DB에서 직접 실행시켜주면 된다.

인텔리제이의 경우 CTRL+N 후 files에서 schema로 검색하면 쉽게 찾을 수 있음! 총 9개의 메타테이블이 생성되어야 함!

📝 처리 로직

각 상품에 대한 집계 데이터(평균 별점, 리뷰 개수)를 리뷰가 등록될 때마다 업데이트 하는 것은 비효율적이라고 판단했고, 이를 해결하기 위해 30분 단위로 데이터를 집계하여 업데이트하는 방식으로 로직을 구현하기로 함.

이런 방식으로 구현하면 리뷰 데이터를 실시간으로 반영할 수 없다는 문제가 발생하기는 하는데, 실제 쇼핑몰에서도 리뷰 검수 등의 단계를 거쳐 바로 보여주지 않는 곳이 있기 때문에 괜찮다고 판단했고,, 대신 시간을 30분 단위로 정하여 최대한 빠르게 반영될 수 있도록 처리하기로 함!

✍🏻 코드

- JobConfig

실행할 Job에 대한 정의 : Step, Reader, Processor, Writer 등

Job

• JobRepository와 트랜잭션 매니저를 생성하고, 이를 각 스텝마다 전달

• JobBuilder : Job의 이름, Step 등을 정의 ➡️ 해당 Job은 스텝을 하나만 가지고 있지만, Step을 순차적으로 실행시키고 싶다면 .next(step)으로 이어나가면 됨!

@Bean(name = "itemSummaryJob")
public Job itemSummaryJob(JobRepository jobRepository, PlatformTransactionManager txm) throws Exception {
    return new JobBuilder("itemSummaryJob", jobRepository)
                .start(step(jobRepository, txm))
                .build();
}

Step

• @JobScope : Job 실행 시 bean을 생성하며, Job의 생명주기 관리

• StepBuilder : Step의 이름, 작업 단위(taskle/chunk) 등을 정의

  • Chunk 단위 사용 : 상품 데이터가 약 1000개 이므로, 100개 단위로 묶어서 트랜잭션 실행

  • allowStartIfComplete : 이미 완료된 Job을 실행시킬 지에 대한 설정

    @Bean(name = "itemSummaryStep")
    @JobScope
    public Step step(JobRepository jobRepository, PlatformTransactionManager txm) throws Exception {
    return new StepBuilder("itemSummaryStep", jobRepository)
                .<ReviewSummaryDTO, ItemCalc>chunk(100, txm)
                .reader(reader())
                .processor(processor())
                .writer(writer())
                .allowStartIfComplete(true)
                .build();
    }

ItemReader

• @StepScope : Step 실행 시 bean을 생성하며, Step의 생명주기 관리

• Review 테이블에서 각 상품 별 집계 데이터를 조회하여 ReviewSummaryDTO 형태로 저장하기 위한 Reader 🌟

• JpaPagingItemReaderBuilder : JPA의 페이징을 활용하여 데이터를 읽어오기 위한 ItemReader 구현체 → 원래는 Querydsl을 활용하려고 했으나,, 구현체를 직접 구현해야 해서 이미 구현되어 있는 페이징 구현체 사용,,

  • pageSize : Chunk의 단위 사이즈와 동일하게 지정 (100개)
  • queryString : 데이터를 읽어오기 위한 쿼리

@Bean
@StepScope
public JpaPagingItemReader<ReviewSummaryDTO> reader() throws Exception {

    return new JpaPagingItemReaderBuilder<ReviewSummaryDTO>()
                .pageSize(100)
                .queryString(
                        "select new com.comehere.ssgserver.review.dto.resp.ReviewSummaryDTO("
                                + "min(i.id), min(ic.id), round(avg(r.star), 1), count(r)) "
                                + "from Review r "
                                + "join Item i on r.itemCode = i.code "
                                + "join ItemCalc ic on i.id = ic.itemId "
                                + "group by r.itemCode"
                )
                .entityManagerFactory(emf)
                .name("itemSummaryReader")
                .build();
    }

ItemProcessor

• Reader에서 읽어온 ReviewSummaryDTO를 ItemCalc 형태로 변환하기 위한 Processor 🌟

• ItemProcessorBuilder : process(가공할 데이터)를 통해 데이터 처리 로직 구현

@Bean
@StepScope
public ItemProcessor<ReviewSummaryDTO, ItemCalc> processor() {
    return new ItemProcessor<ReviewSummaryDTO, ItemCalc>() {
        @Override
        public ItemCalc process(ReviewSummaryDTO dto) throws Exception {
            return ItemCalc.builder()
                    .id(dto.getCalcId())
                    .reviewCount(dto.getReviewCount())
                    .averageStar(dto.getAverageStar())
                    .build();
        }
    };
}

ItemWriter

• Proccesor에서 처리한 ItemCalc를 데이터베이스의 Item_Calc 테이블에 최종적으로 저장 ➡️ 변경 내역 업데이트 🌟

@Bean
@StepScope
public JpaItemWriter<ItemCalc> writer() {
    return new JpaItemWriterBuilder<ItemCalc>()
            .entityManagerFactory(emf)
            .build();
}

✅ 전체 코드

@Slf4j
@Configuration
@RequiredArgsConstructor
@Transactional
public class BatchJobConfig {
    private final EntityManagerFactory emf;

    @Bean(name = "itemSummaryJob")
    public Job itemSummaryJob(JobRepository jobRepository, PlatformTransactionManager txm) throws Exception {
        log.info("job start");
        return new JobBuilder("itemSummaryJob", jobRepository)
                .start(step(jobRepository, txm))
                .build();
    }

    @Bean(name = "itemSummaryStep")
    @JobScope
    public Step step(JobRepository jobRepository, PlatformTransactionManager txm) throws Exception {
        log.info("step start");
        return new StepBuilder("itemSummaryStep", jobRepository)
                .<ReviewSummaryDTO, ItemCalc>chunk(100, txm)
                .reader(reader())
                .processor(processor())
                .writer(writer())
                .allowStartIfComplete(true)
                .build();
    }

    @Bean
    @StepScope
    public JpaPagingItemReader<ReviewSummaryDTO> reader() throws Exception {
        log.info("reader start");

        return new JpaPagingItemReaderBuilder<ReviewSummaryDTO>()
                .pageSize(100)
                .queryString(
                        "select new com.comehere.ssgserver.review.dto.resp.ReviewSummaryDTO("
                                + "min(i.id), min(ic.id), round(avg(r.star), 1), count(r)) "
                                + "from Review r "
                                + "join Item i on r.itemCode = i.code "
                                + "join ItemCalc ic on i.id = ic.itemId "
                                + "group by r.itemCode"
                )
                .entityManagerFactory(emf)
                .name("itemSummaryReader")
                .build();
    }

    @Bean
    @StepScope
    public ItemProcessor<ReviewSummaryDTO, ItemCalc> processor() {
        log.info("processor start");
        return new ItemProcessor<ReviewSummaryDTO, ItemCalc>() {
            @Override
            public ItemCalc process(ReviewSummaryDTO dto) throws Exception {
                return ItemCalc.builder()
                        .id(dto.getCalcId())
                        .reviewCount(dto.getReviewCount())
                        .averageStar(dto.getAverageStar())
                        .build();
            }
        };
    }

    @Bean
    @StepScope
    public JpaItemWriter<ItemCalc> writer() {
        log.info("writer start");
        return new JpaItemWriterBuilder<ItemCalc>()
                .entityManagerFactory(emf)
                .build();
    }
}

💾 실행

현재 상품별 집계 내역은 아래와 같은데, 현재 집계 데이터가 없는 8번 상품의 리뷰를 작성하고, 1번 상품의 리뷰를 추가로 작성한다고 했을 때, 배치 실행 후 집계 내역은 어떻게 변할까?

🌟 배치 작업 수행

실행 시간이 정각이 아닌 이유는 테스트를 위해 job.enabled: true로 설정했기 때문,,

1. Reader

: Reader에 작성한 쿼리를 실행하여 집계 내역 조회

2. Processor + Wirter

: JPA의 변경 감지를 활용하여 업데이트 된 2개의 상품(1번, 8번)에 대해 업데이트 실행

✅ 결과

1번과 8번 각각 2개의 리뷰를 추가로 작성하였고, 그에 따라 리뷰 개수와 평균 별점이 업데이트 된 것을 확인할 수 있다!

🙏🏻 참고

• Spring Batch란? 간단한 개념과 코드 살펴보기

• Spring Batch란? 이해하고 사용하기(예제소스 포함)
• Tasklet vs Chunk 비교와 처리 테스트

https://coolsms.co.kr/ : 건당 20원, 최초 가입 시 300P 무료 제공!

회원가입을 구현하다 보니 자연스럽게 인증 로직을 구현하게 되었는데, 이메일이랑 휴대폰 문자 인증 둘 중에 고민하다가 이메일 계정 무한 생성 << 같은 부정행위를 막기 위해서 한 사람당 한 번만 가입할 수 있도록 문자 인증을 도입하기로 결정하게 되었다!

이후에 관련 API를 찾아보다 가장 많은 샘플이 존재했고, 또 팀원이 이전 팀에서 써본 경험이 있었던 CoolSMS를 사용하기로 결정. 유료이긴 했으나 무료 포인트를 주니까 테스트용으로 충분할 것 같아서 걍 사용,, 하기로 했으나 막판에 모자라서 걍 엔빵해서 결제하긴함,,ㅋㅋ

🗝️ API Key 발급 + Spring 연동

발급 : 회원가입 후 대시보드 ➡️ 개발/연동 ➡️ API Key 발급 ➡️ 새로운 API KEY

Spring 연동 : 공식 깃허브 참고!!

CoolSMS에서 공식 깃허브를 운영하면서 언어 + 프레임워크별 의존성 및 샘플 코드를 제공해준다! 나는 Gradle 기반의 Spring Boot를 사용하므로 해당 레포를 참고하여 build.gradle에 아래 의존성을 추가해줬다.

implementation 'net.nurigo:sdk:4.3.0'

추가적으로 application.yaml에 위에서 발급했던 API Key와 Secret Key, 그리고 문자 전송 시 사용할 번호 데이터를 미리 입력해둠!

coolsms:
  api:
    key: "API KEY 입력"
    secret: "SECRET KEY 입력"
    sender: "발신자 번호" # (- 없어야 함)

💻 코드 구현

로직의 큰 틀은 문자 인증 요청 ➡️ 문자 발송 ➡️ 인증번호 검증인데, 이 과정에서 인증번호는 5분동안만 유효하도록! 구현하는 것이 목표였음..

문제는 인증번호를 5분동안 어디에 저장하냐?였는데 MySQL은 서버 부하때문에 제외였고,, 선택지는 세션 아니면 레디스였는데 이것저것 찾아보니 세션의 time-out 기능을 사용하게 되면 세션을 사용하는 다른 로직에 영향을 미칠 수 있다는 점과, 세션 키가 중복될 위험이 있다는 점이 걸려서 처리 속도가 빠른 인메모리 캐시 DB인 Redis를 사용하기로 했다! 따라서,

문자 인증 요청 ➡️ 인증번호 발급 후 Redis에 <휴대폰번호, 인증번호> 저장 (만료시간 지정) ➡️ 검증 요청 시 키 값인 번호로 조회 ➡️ 검증 통과 시 데이터 삭제

이 로직을 최종적인 틀로 잡고 구현 시작,,

⚙️ 메세지 전송

• SmsUtil : CoolSMS에서 제공하는 DefaultMessageService와 SingleMessageSentResponse 객체를 사용하여, 인증번호와 수신자 번호를 전달받으면 실제 메세지를 생성하여 전송하는 로직 구현

@Component
public class SmsUtil {
    @Value("${coolsms.api.key}")
    private String apiKey;

    @Value("${coolsms.api.secret}")
    private String secretKey;

    @Value("${coolsms.api.sender}")
    private String sender;

    DefaultMessageService messageService;

    @PostConstruct
    private void init() {
        this.messageService = NurigoApp.INSTANCE.initialize(apiKey, secretKey, "https://api.coolsms.co.kr");
    }

    // 인증번호 전송 : 단일 메세지
    public SingleMessageSentResponse sendSms(String receiver, String code) {
        Message message = new Message();
        message.setFrom(sender); // 보내는 사람 : 관리자
        message.setTo(receiver); // 받는 사람 : 유저
        message.setText("[MFC] 본인 확인 인증번호 : [" + code + "]\n인증번호는 5분간 유효합니다."); // 전송 내용

        return messageService.sendOne(new SingleMessageSendingRequest(message));
    }
}

• AuthService : 인증을 요청한 휴대폰 번호를 통해 해당 회원이 이미 존재하는지 검증하고, 새로 가입하는 회원인 경우 6자리의 인증번호 code를 발급하여 SmsUtil의 sendSms()를 호출하여 메세지를 전송한 후, redis에 해당 내역을 저장

@Service
@RequiredArgsConstructor
@Transactional
public class AuthServiceImpl implements AuthService {
    private final SmsRepository smsRepository;
    private final SmsUtil smsUtil;

    @Override
    public void sendSms(SmsReqDto dto) {
        String to = dto.getPhone();
        if(isDuplicate(to)) {
            throw new BaseException(DUPLICATED_MEMBERS);
        }

        int random = (int) (Math.random() * 900000) + 1000;
        String code = String.valueOf(random);

        smsUtil.sendSms(to, code); // 문자 전송
        smsRepository.createSmsCode(to, code); // 인증번호 redis에 저장
    }

    private boolean isDuplicate(String phone) {
        return memberRepository.findByActivePhone(phone).isPresent();
    }
}

• SmsRepository : redis에 <휴대폰번호, 인증번호> 형식으로 인증 내역을 저장하는데, 이때 Duration을 통해 해당 데이터의 유효기간을 지정할 수 있음. 인증번호가 5분동안만 유효하므로 LIMIT_TIME을 5분으로 설정해줌.

  @Repository
  @RequiredArgsConstructor
  public class SmsRepository {
    private final StringRedisTemplate redisTemplate;
  
    private final String PREFIX = "sms:";
    private final int LIMIT_TIME = 5 * 60;
  
    public void createSmsCode(String phone, String code) {
        redisTemplate.opsForValue()
                .set(PREFIX + phone, code, Duration.ofSeconds(LIMIT_TIME));
    }
  }

⚙️ 인증

• AuthService : redis에서 휴대폰 번호를 통해 값을 조회해서 인증번호를 검증한 후, 통과했다면 해당 인증번호는 더이상 의미없기 때문에 redis에서 삭제 처리.

@Service
@RequiredArgsConstructor
@Transactional
public class AuthServiceImpl implements AuthService {
    private final SmsRepository smsRepository;
    private final SmsUtil smsUtil;

    @Override
    public void verifyCode(SmsReqDto dto) {
        if(!isVerify(dto)) {
            throw new BaseException(MESSAGE_VALID_FAILED);
        }

        smsRepository.removeSmsCode(dto.getPhone());
    }

    private boolean isVerify(SmsReqDto dto) {
        return smsRepository.hasKey(dto.getPhone()) &&
                smsRepository.getSmsCode(dto.getPhone())
                        .equals(dto.getCode());
    }
}

• SmsRepository

  • hasKey(phone) : 해당 휴대폰 번호를 키로 가지는 값이 있는지 조회. 만약 인증 요청 후 5분이 지났다면, 해당 데이터는 삭제되어 더이상 존재하지 않음.

  • getSmsCode(phone) : 해당 휴대폰 번호를 키값으로 가지는 인증번호 값 조회. 사용자가 입력한 인증번호와 일치하는지 검증할 때 사용

  • removeSmsCode(phone) : 해당 휴대폰 번호를 키값으로 가지는 내역 삭제

@Repository
@RequiredArgsConstructor
public class SmsRepository {
    private final StringRedisTemplate redisTemplate;

    private final String PREFIX = "sms:";
    private final int LIMIT_TIME = 5 * 60;

    public boolean hasKey(String phone) {
        return redisTemplate.hasKey(PREFIX + phone);
    }

    public String getSmsCode(String phone) {
        return redisTemplate.opsForValue().get(PREFIX + phone);
    }

    public void removeSmsCode(String phone) {
        redisTemplate.delete(PREFIX + phone);
    }
}

✅ 테스트

1. 휴대폰 번호로 인증 요청 : 문자가 정상적으로 수신되는 것을 확인!

2-1. 잘못된 인증번호로 검증 : 예외 발생

2-2. 올바른 인증번호로 검증

2-3. 올바른 인증번호로 재검증 : 첫번째 검증 통과 시 삭제되므로, 해당 내역이 존재하지 않아 예외 발생

사실 문자 인증 처음에 담당하게 됐을 때 좀 쫄았었는데 공식 깃허브랑 몇몇 기술 블로그들이 넘 친절해서 금방 할 수 있었던 것 같다,, 나중에 개인 플젝 작은거나 하나 하면서 이메일 인증도 구현해봐야지,, 시간이 된다면,,

⭐ 이벤트 기반 아키텍처 : 분산 시스템 환경에서 서비스들이 이벤트를 기반으로 비동기 통신하는 구조

이벤트를 기반으로 통신한다는 것은 한 서비스에서 이벤트를 생성하여 발행하면(pub) 해당 이벤트를 필요로 하는 서비스가 이벤트를 받아서 처리(sub)하는 방식으로 작동한다.

여기서 이벤트란 주목할 만한 사건, 즉, 회원가입이나 주문과 같이 어떠한 작업이 실행됐다고 생각하면 편하다. 그렇다면 이벤트가 발행되는 것은 API가 호출되는 것이라고 치고, 이벤트를 구독하고, 받아서 처리한다는 것은 어떤 개념일까? 나는 이걸 MSA & 분산 DB 환경에서 한 서비스의 이벤트가 다른 서비스의 이벤트나 데이터에 영향을 미친다. 라는 느낌으로 이해하고 작업을 진행했다.

내가 2차 프로젝트를 진행하면서 EDA를 적용한 부분을 정리해봤는데, 대충 이정도였다. 이걸 참고해서 위 설명에 예시를 들어보자면, 인증(Auth) 서비스에서 회원가입 이벤트가 발행되면 카프카(아래 설명 예정)에 관련된 데이터(메세지)가 저장되고, 이 이벤트를 구독한 회원(Member) 서비스에서 해당 데이터를 들고 회원 DB 서버에 프로필 데이터를 저장하는 방식으로 동작하게 된다.

인증 서버에서 회원가입 요청을 처리할 때 위와 같은 데이터들을 받는데, 각 DB의 테이블을 살펴보면 email, password, name, phone, birth, gender는 인증 서버에서, nickname, favoriteStyle은 회원 서버에서 관리하는 것을 알 수 있다. 그렇다면, 회원가입 시 인증 서버의 Member 테이블과 회원 서버의 User/Partner(role에 따라 분기), Favorite_Style 테이블에 INSERT문을 실행해야 하는데, 인증 서비스에서는 인증 DB 서버만 다루기 때문에, 해당 서비스에서 회원 DB 서버에 프로필 정보를 저장을 처리할 수 없는 문제가 발생하게 된다.

이러한 경우, 어떻게 다른 서비스로 데이터를 전달할 수 있을까? 바로 카프카와 같은 메시지 큐를 활용하면 된다!

📢 Kafka

메시지 큐 방식을 기반으로 하여 분산 시스템 환경에서 대규모 메시지를 안정적으로 전송, 수집, 활용할 수 있도록 서비스를 중개하는 분산 메시징 시스템

메시지 큐를 찾아보면 가장 많이 나오는 툴이 Kafka와 RabbitMQ인데, 위에서 설명했던 내가 구현한 부분 외에도 다른 팀원분도 EDA를 사용하는 경우가 제법 있어서 대용량 메시지를 좀 더 안정적으로 처리할 수 있는 Kafka를 선택하게 되었다.

• Broker : 카프카 애플리션이 설치된 서버

• Producer : 메시지(이벤트)를 발행하여 브로커에 전달하는 서비스
• Consumer : 브로커의 메시지를 구독하여 처리하는 서비스
• Topic : 브로커에서 메시지를 구분하기 위해 설정하는 고유한 이름
• Partition : 브로커 내에서 병렬 처리를 가능하게 함
• Zookeeper : 분산 애플리케이션들을 그룹화하여 관리하는 시스템

카프카에 대해서 정리하자면 글이 한없이 길어질 것 같아서.. 일단 이 글에서는 이 정도 개념만 가지고 서비스 통신을 구현하는 코드 위주로 정리할 예정.. 주키퍼와 카프카 서버를 구축하는 과정이나, 좀 딥한 개념에 대해서는 추후 작성할 인프라 파트에서 다룰 예정!

⚙️ Producer

이벤트 발행 시, <토픽명, 메시지>를 <String, Json> 형태로 전송

✍🏻 KafkaConfig

@Configuration
public class KafkaConfig {
    @Value("${spring.kafka.bootstrap-servers}") // .yml에 환경변수 선언
    private String BOOTSTRAP_SERVER;

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

    @Bean
    public ProducerFactory<String, Object> producerFactory() {
        Map<String, Object> configs = new HashMap<>();
        configs.put(ProducerConfig.BOOTSTRAP_SERVERS_CONFIG, BOOTSTRAP_SERVER);
        configs.put(ProducerConfig.KEY_SERIALIZER_CLASS_CONFIG, StringSerializer.class);
        configs.put(ProducerConfig.VALUE_SERIALIZER_CLASS_CONFIG, JsonSerializer.class);

        return new DefaultKafkaProducerFactory<>(configs);
    }
}

✍🏻 KafkaProducer

• 프로필 정보를 InsertProfieDto 객체 형태로 전송하면, 설정값에 따라 DTO를 JSON으로 변환하여 브로커에 저장

@Service
@RequiredArgsConstructor
public class KafkaProducer {
    private final KafkaTemplate<String, Object> kafkaTemplate;

    public void sendProfile(InsertProfileDto dto) {
        kafkaTemplate.send("profile-insert", dto);
    }
}

✍🏻 AuthService

• SignUpReqDto에서 프로필 데이터를 InsertProfileDto 객체에 담아 producer를 통해 브로커에 전송

@Service
@RequiredArgsConstructor
@Transactional
public class AuthServiceImpl implements AuthService {
    private final MemberRepository memberRepository;
    private final KafkaProducer producer;

    @Override
    public String signUp(SignUpReqDto dto) {
        if(!dto.getRole().equals("USER") && !dto.getRole().equals("PARTNER")) {
            throw new BaseException(NO_EXIT_ROLE);
        }

        Member member = createMember(dto);
        producer.sendProfile(InsertProfileDto.toBuild(dto, member.getUuid()));
        return member.getUuid();
    }
}

⚙️ Consumer

토픽명에 따른 JSON 형태의 메시지를 DTO로 변환하여 처리

✍🏻 KafkaConfig

• InsertProfileDto 타입의 메시지를 받아서 처리하는 ConsumerFactory 생성
  ➡️ 처음에는 프로듀서처럼 Object로 받아서 처리하려고 했는데, 계속 예외가 발생해서 각 컨슈머 별로 DTO를 분리해서 설정하니까 정상적으로 처리됨 + 프로듀서도 Object 보다는 나누어서 처리하는게 좋다고 함!

@Configuration
public class KafkaConfig {
    @Value("${spring.kafka.bootstrap-servers}")
    private String BOOTSTRAP_SERVER;

    @Value("${spring.kafka.consumer.group-id}")
    private String GROUP_ID;

    @Bean
    public ConsumerFactory<String, InsertProfileDto> insertProfileConsumer() {
        Map<String, Object> configs = new HashMap<>();
        configs.put(BOOTSTRAP_SERVERS_CONFIG, BOOTSTRAP_SERVER);
        configs.put(GROUP_ID_CONFIG, GROUP_ID);
        configs.put(JsonDeserializer.TRUSTED_PACKAGES, "*");

        return new DefaultKafkaConsumerFactory<>(
                configs,
                new StringDeserializer(),
                new JsonDeserializer<>(InsertProfileDto.class, false)
        );
    }

    @Bean
    ConcurrentKafkaListenerContainerFactory<String, InsertProfileDto> insertProfileListener() {
        ConcurrentKafkaListenerContainerFactory<String, InsertProfileDto> factory
                = new ConcurrentKafkaListenerContainerFactory<>();
        factory.setConsumerFactory(insertProfileConsumer());
        return factory;
    }

✍🏻 KafkaConsumer

• @KafkaListner(topics="토픽명", containerFactory="리스너명") : 브로커에서 해당 토픽명을 가지는 메시지를 받아와서 처리

  • DTO내의 role 값에 따라서 유저 혹은 파트너 프로필 생성 + 선호 스타일 저장 ➡️ 파트너 프로필 생성 시, 배치 서비스에 집계 데이터를 생성해야 하므로 새로운 이벤트 발행

@Service
@RequiredArgsConstructor
@Transactional
@Slf4j
public class KafkaConsumer {
    private final UserRepository userRepository;
    private final PartnerRepository partnerRepository;
    private final FavoriteStyleRepository favoriteStyleRepository;

    private final KafkaProducer producer;

    @KafkaListener(topics = "profile-insert", containerFactory = "insertProfileListener")
    public void insertProfile(InsertProfileDto dto) {
        if(dto.getRole().equals("USER")) { // 유저
            userRepository.save(User.builder()
                    .uuid(dto.getUuid())
                    .nickname(dto.getNickname())
                    .build());
        } 

        else if(dto.getRole().equals("PARTNER")) { // 파트너
            Partner partner = partnerRepository.save(Partner.builder()
                    .uuid(dto.getUuid())
                    .nickname(dto.getNickname())
                    .build());

            // 새로운 이벤트 발행 : 배치 서비스에서 사용
            producer.createPartner(PartnerSummaryDto.builder()
                    .partnerId(partner.getUuid())
                    .build());
        } 

        else { // 이외의 파라미터 : 예외 발생
            throw new BaseException(NO_EXIT_ROLE);
        }

        dto.getFavoriteStyles() // 선호 스타일 저장 : 파트너 & 유저 공통
                .forEach(i -> favoriteStyleRepository.save(
                        FavoriteStyle.builder()
                                .uuid(dto.getUuid())
                                .styleId(i)
                                .build()));
    }
}    

⭐ 결과

1. 인증 서버

• 신규 회원 데이터 생성 → 회원 서비스에 UUID와 프로필, 선호 스타일 전달

2. 회원 서버

• 신규 회원의 UUID를 가지는 파트너 프로필, 선호 스타일 데이터 생성 → 배치 서비스에 UUID 전달

➕ 배치 서버

• 신규 회원의 UUID를 가지는 파트너 집계 데이터 생성

✅ 장단점

그렇다면 분산 시스템에서 데이터를 EDA를 통해 관리하면 어떤 점이 좋고, 어떤 점에서 문제가 발생할까?

🙆🏻‍♀️ 장점

• 서비스 간 느슨한 결합 : 브로커는 메시지 수신 여부와 관계 없이 독립적으로 메시지를 관리함. 즉, 수신 측 서비스가 작동하지 않아 메시지를 수신하지 못하더라도 송신 측 서비스는 이미 메시지를 전송하였기 때문에 이에 영향을 받지 않고 독립적으로 작동함.

• 이벤트 전달 보장 : 이벤트가 발행되는 순간 브로커가 메시지를 안전하게 저장하므로, 수신 측 서비스가 작동하지 않더라도 재가동 시 누락된 메시지를 수신할 수 있음.

• 비동기 처리를 통한 성능 최적화 : EDA는 비동기 통신 기반이므로 여러 요청을 한 번에 처리할 수 있기 때문에 시스템 전체의 처리량을 높일 수 있음.

• 확장성 및 재사용성 향상 : 하나의 메시지를 여러 서비스에서 구독하여 사용할 수 있으므로, 필요에 따라 기능을 추가하거나 변경할 수 있음.

  
  

🙅🏻‍♀️ 단점

• 시스템 복잡도 증가 : 이벤트의** 흐름을 추적하고 관리**하는 처리 로직을 구현하는 부분에서 전체적인 시스템이 복잡해질 수 있음.

• 이벤트 처리 순서 보장의 어려움 : 다수의 이벤트가 비동기로 처리되기 때문에, 동일한 이벤트에 대해 순차적 처리를 보장할 수 없음.

• 데이터 일관성 유지의 어려움 : DB 서버가 분산되어 있기 때문에, 이벤트 발행 시점에 수신 측 서비스가 작동하지 않는 경우 데이터가 실시간으로 반영되지 않아 일관된 데이터 상태를 유지하기 어려울 수 있음.

🙏🏻 참고

• Apache Kafka를 사용하여 EDA 적용하기

• 이벤트 기반 아키텍처(Event-Driven Architecture)란?
• 카프카(kafka) vs RabbitMQ
• 이벤트 기반 아키텍처의 이해와 장단점

특정 상품과 연관된 리뷰 이미지들을 조회하는 쿼리 최적화

⚙️ Review : ReviewImage = 1 : N 연관관계

@Entity
@Getter
@NoArgsConstructor
public class Review extends BaseEntity {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    @Column(nullable = false, updatable = false)
    private String itemCode;

    ...
}

@Entity
@NoArgsConstructor
@Getter
public class ReviewImage {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    @ManyToOne(fetch=LAZY)
    @JoinColumn(name = "review_id", nullable = false, updatable = false)
    private Review review;

    ...
}

⚙️ ReviewImageListDTO : 최종 반환 형태

@Getter
@AllArgsConstructor
public class ReviewImageListDTO {
    private Long reviewId;
    private Long imageId;
    private String url;
    private String alt;
}    

1. 단순 조인

단순 조인 실행 : N + 1 문제 발생

@Query("select ri  from ReviewImage ri left join ri.review r where r.itemCode = :itemCode")
Slice<ReviewImage> findReviewImages(@Param("itemCode") String itemCode, Pageable page);

결과는 정상적으로 반환되나, 전달된 itemCode에 해당하는 리뷰 이미지들을 조회하는 쿼리 하나와, 해당 이미지와 연관된 리뷰 아이디를 조회해오는 2개의 쿼리, 총 3개의 쿼리가 실행되었다.

→ ReviewImage의 Review 에 지연 로딩이 적용되어 있기 때문에 이미지와 연관된 리뷰에 대한 정보는 조회하지 않고, 빈 객체인 프록시 객체인 상태로 존재한다. 이 때, 서비스에서 조회 결과를 DTO 형태로 변환하는 과정에서 reviewImage.getReview().getId() 를 통해 연관된 리뷰의 아이디 값을 가져오는데, 이 때 review는 프록시이므로 getId()를 통해 값을 가져오려고 할 때가 되어서야 해당 아이디 값을 가지는 리뷰를 조회하는 쿼리를 실행한다.

이 때, 같은 리뷰 아이디값을 가진다면 영속성 컨텍스트를 활용하여 한 번의 쿼리로 해결할 수 있지만, 연관된 리뷰의 아이디가 n개라면 n개의 추가 쿼리가 발생하게 되면서 성능을 저하시킬 수 있다.

2. Fetch Join

JPA에서 제공하는 페치 조인 실행 : 필요없는 데이터까지 조회하게 됨

@Query("select ri  from ReviewImage ri left join fetch ri.review r where r.itemCode = :itemCode")
Slice<ReviewImage> findReviewImages(@Param("itemCode") String itemCode, Pageable page);

하나의 쿼리로 원하는 결과를 얻을 수는 있지만, 페치 조인은 연관된 엔티티들, 즉 리뷰와 리뷰 이미지 테이블 내의 모든 컬럼을 한 번에 조회하게 된다. 저기서 실질적으로 4개의 필드만 사용하고 나머지 필드들은 사용하지 않는데, 4개의 데이터를 가져오려고 9개의 데이터까지 덤으로 매번 가져오는 건 성능적으로 비효율적이지 않을까? 생각이 들었다.. 사실 덩치 큰 쿼리가 마음에 안들었음 ㅎ..

💡 해결책

엔티티 타입으로 조회해서 DTO로 변환하는 방식이 아닌, DTO 타입에 맞춰서 조회하기!

1. JPQL

select new com.comehere.ssgserver.review.dto.resp.ReviewImageListDTO...

: JPQL에서 DTO 타입으로 조회하기 위해서는 조회 타입에 조회하고 싶은 형식의 DTO를 생성자 선언하듯이 선언하면 되는데, DTO가 존재하는 경로 상의 모든 패키지명을 명시해야 하므로 쿼리가 지저분해진다.. 따라서 해당 방식은 패스..

2. Querydsl

Querydsl의 Projections 사용 : 생성자, 필드, 어노테이션 등 다양한 방법이 있는데 나는 생성자 주입 방식 사용!

• Projections.constructor : 생성자(@AllArgsConstructor)를 통해 조회된 값을 DTO 타입에 주입

List<ReviewImageListDTO> result = query
                .select(Projections.constructor(ReviewImageListDTO.class,
                        reviewImage.review.id.as("reviewId"),
                        reviewImage.id.as("imageId"),
                        reviewImage.imageUrl.as("url"),
                        reviewImage.alt))
                .from(reviewImage)
                .join(reviewImage.review, review)
                .where(review.itemCode.eq(itemCode))
                .limit(page.getPageSize() + 1)
                .offset(page.getOffset())
                .fetch();

하나의 쿼리로 필요한 데이터만 조회 완.

Spring Framework에서 제공하는 오픈 소스 기반의 Gateway 서비스

기본 설정 및 라우팅에 대해서는 이 글 참고!

✅ JWT 검증 필터

게이트웨이로 들어오는 요청에 대하여 JWT 토큰의 유효 여부를 검증한 후, 검증을 통과한 요청만 해당 서비스로 전달

서비스로 들어오는 모든 요청을 JWT 토큰이 필요한 요청과 필요하지 않은 요청으로 나눌 수 있는데, 이 요청들은 모두 게이트웨이를 거쳐서 서비스로 전달되므로, 각 서비스 별로 토큰 검증 필터를 구현하기 보다는 게이트웨이에서 한 번만 구현하여 검증을 거친 후에 통과한 요청만 서비스로 전달하는 방식이 더욱 효율적임.

일반적인 Spring Web MVC 프로젝트에서는 tomcat 기반의 Spring Security를 사용하여 토큰 검증 필터를 구현하지만, Spring Cloud Gateway는 Spring Webflux 프로젝트, 즉, netty *기반이므로 *Spring Security를 함께 사용할 수 없음. 따라서, Spring Cloud gateway에서 제공하는 AbstractGatewayFilterFactory를 상속하여 구현하여야 함.

⚙️ AuthorizationHeaderFiler

요청에 토큰이 존재하는지, 존재한다면 유효한 토큰인지 검증 ➡️ 유효하지 않은 경우 예외 처리

1. SecretKey 객체 생성

private final SecretKey key;

public AuthorizationHeaderFilter(@Value("${jwt.secret-key}") String key) {
    super(Config.class);
    byte[] keyBytes = Decoders.BASE64.decode(key);
    this.key = new SecretKeySpec(keyBytes, SignatureAlgorithm.HS256.getJcaName());
}

2. 토큰 존재 여부 검증

⭐ 헤더에 Authorization이 없다면 토큰이 없다는 뜻이므로 예외 처리!

@Override
public GatewayFilter apply(Config config) {
    return (exchange, chain) -> {
        ServerHttpRequest req = exchange.getRequest();
        HttpHeaders header = req.getHeaders();

        if(!header.containsKey(HttpHeaders.AUTHORIZATION)) {
            throw new BaseException(NOT_FOUND_TOKEN);
        }
    };
}

2. 토큰 유효성 검증

⭐ 올바른 형식이 아니거나, 토큰의 유효기간이 지나 만료된 경우 예외 처리!

• 올바르지 않은 형식 : 토큰이 Bearer로 시작하지 않는 경우

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

        String authorization = header.get(HttpHeaders.AUTHORIZATION).get(0);
        if(authorization == null || !authorization.startsWith("Bearer")) {
            throw new BaseException(INVALID_TOKEN);
        }

        String jwt = authorization.substring(7);
        isValid(jwt);
        return chain.filter(exchange);
    };
}

➕ isValid(jwt) : 토큰 유효성 검증

• parseClaimsJws(jwt) : 토큰이 올바른 Secret Key로 서명되었는지 + 만료되지 않았는지 검증

  • ExpiredJwtException : 토큰이 만료된 경우에 대한 예외 처리
  • Exception : 그 외의 예외 처리 (유효하지 않은 토큰)

private void isValid(String jwt) {

    try {
        Jwts.parserBuilder()
                .setSigningKey(key)
                .build()
                .parseClaimsJws(jwt);
    } catch(ExpiredJwtException e) {
        throw new BaseException(EXPIRED_TOKEN);
    } catch(Exception e) {
        throw new BaseException(INVALID_TOKEN);
    }
}

✍🏻 전체 코드

@Component
public class AuthorizationHeaderFilter extends AbstractGatewayFilterFactory<AuthorizationHeaderFilter.Config> {
    private final SecretKey key;

    public AuthorizationHeaderFilter(@Value("${jwt.secret-key}") String key) {
        super(Config.class);
        byte[] keyBytes = Decoders.BASE64.decode(key);
        this.key = new SecretKeySpec(keyBytes, SignatureAlgorithm.HS256.getJcaName());
    }

    @Override
    public GatewayFilter apply(Config config) {
        return (exchange, chain) -> {
            ServerHttpRequest req = exchange.getRequest();
            HttpHeaders header = req.getHeaders();

            if(!header.containsKey(HttpHeaders.AUTHORIZATION)) {
                throw new BaseException(NOT_FOUND_TOKEN);
            }

            String authorization = header.get(HttpHeaders.AUTHORIZATION).get(0);
            if(authorization == null || !authorization.startsWith("Bearer")) {
                throw new BaseException(INVALID_TOKEN);
            }

            String jwt = authorization.substring(7);
            isValid(jwt);
            return chain.filter(exchange);
        };
    }

    private void isValid(String jwt) {

        try {
            Jwts.parserBuilder()
                    .setSigningKey(key)
                    .build()
                    .parseClaimsJws(jwt)
                    .getBody()
                    .getSubject();
        } catch(ExpiredJwtException e) {
            throw new BaseException(EXPIRED_TOKEN);
        } catch(Exception e) {
            throw new BaseException(INVALID_TOKEN);
        }
    }

    public static class Config {
    }
}

⚙️ 필터 적용

.yml에서 토큰이 필요한 요청에 대한 라우팅에 토큰 검증 필터 적용

한 서비스 내에서도 토큰이 필요한 요청과 필요하지 않은 요청이 각각 존재하므로, 토큰이 필요한 요청에 대한 라우팅과 필요하지 않은 요청에 대한 라우팅을 분리해서 토큰이 필요한 요청에 대한 라우팅에만 토큰 검증 필터를 적용해야 함!

ex) sns 서비스에 대한 라우팅

• sns-service-get : 단순 조회 요청이므로 토큰 불필요 ➡️ 토큰 검증 필터 미적용

- id: sns-service-get
  uri: lb://SNS-SERVICE
  predicates:
    - Path=/sns-service/**, /sns-service/bookmark/**, /sns-service/follow/**
    - Method= GET
  filters: # 경로 필터만 적용
    - StripPrefix=1 

• sns-service-filter : 포스팅 & 좋아요 & 팔로우 CRUD와 관련된 요청이므로 토큰 필요 ➡️ 토큰 검증 필터 적용

  • filters 내에 name: 필터명을 통해 커스텀 필터 여러 개 적용 가능! ```yaml

• id: sns-service-filter # 토큰이 필요한 요청 : 토큰 검증 필터 적용 uri: lb://SNS-SERVICE predicates:

  - Path=/sns-service/posts/**, /sns-service/bookmark/**, /sns-service/follow/**

  • Method=PUT, POST, DELETE filters:
    • StripPrefix=1
  • name: AuthorizationHeaderFilter

➕ 예외 처리

⭐ ErrorWebExceptionHandler : 예외 전역 처리

Spring Web MVC 기반 애플리케이션에서 @ExceptionHandler를 사용하여 컨트롤러에서 발생한 예외를 처리하는 것처럼,** Spring Webflux** 기반 애플리케이션에서는 ErrorWebExceptionHandler를 구현하여 필터에서 발생한 예외를 처리할 수 있음.

MVC 프로젝트와 동일하게 BaseException, BaseResponse, BaseResponseStatus를 사용하여 커스텀할 예정!

➕ BaseException : 커스텀 예외

@Getter
public class BaseException extends RuntimeException{
    private BaseResponseStatus status;

    public BaseException(BaseResponseStatus status) {
        this.status = status;
    }
}

➕ BaseResponse : 커스텀 응답 형식

public record BaseResponse<T>(HttpStatusCode httpStatus, Boolean isSuccess, String message, int code, T result) {


    public BaseResponse(BaseResponseStatus status) {
        this(status.getHttpStatusCode(), false, status.getMessage(), status.getCode(), null);
    }

    public BaseResponse(BaseResponseStatus status, T result) {
        this(status.getHttpStatusCode(), false, status.getMessage(), status.getCode(), result);
    }
}

➕ BaseResponseStatus : 커스텀 응답 상태 코드 + 메세지

@Getter
@RequiredArgsConstructor
public enum BaseResponseStatus {

    NOT_FOUND_TOKEN(HttpStatus.UNAUTHORIZED, false, 401, "토큰이 필요한 요청입니다."),
    INVALID_TOKEN(HttpStatus.UNAUTHORIZED, false, 401, "유효하지 않은 토큰입니다."),
    EXPIRED_TOKEN(HttpStatus.UNAUTHORIZED, false, 401, "만료된 토큰입니다."),
    INVALID_ACCESS(HttpStatus.FORBIDDEN, false, 403, "잘못된 접근입니다."),
    INTERNAL_SERVER_ERROR(HttpStatus.INTERNAL_SERVER_ERROR, false, 500, "서버 에러");

    private final HttpStatusCode httpStatusCode;
    private final boolean isSuccess;
    private final int code;
    private final String message;

}

⚙️ ErrorResponse

1. BaseResponse 생성

@Override
public Mono<Void> handle(ServerWebExchange exchange, Throwable ex) {
    ServerHttpResponse response = exchange.getResponse();

    BaseResponse<?> baseResponse;
    if (ex instanceof BaseException e) {
        baseResponse = new BaseResponse<>(e.getStatus());
        response.setStatusCode(baseResponse.httpStatus());
    } else {
        baseResponse = new BaseResponse<>(BaseResponseStatus.INTERNAL_SERVER_ERROR, ex.getMessage());
        response.setStatusCode(HttpStatus.INTERNAL_SERVER_ERROR);
    }
}

2. BaseResponse ➡️ JSON 변환

private final ObjectMapper objectMapper;

@Override
public Mono<Void> handle(ServerWebExchange exchange, Throwable ex) {
...

response.getHeaders().setContentType(MediaType.APPLICATION_JSON);
    try {
        return response
                .writeWith(Mono.just(response.bufferFactory()
                .wrap(objectMapper.writeValueAsBytes(baseResponse))));
    } catch (JsonProcessingException e) {
        return Mono.error(e);
    }
}

✍🏻 전체 코드

• @Order(-1) : 핸들러의 우선순위 설정 (낮은 숫자일수록 우선순위가 높음) ➡️ 커스텀 핸들러에 우선순위를 설정해주지 않으면 기본 핸들러인 DefaultErrorWebExceptionHandler가 실행되므로, 커스텀 핸들러를 사용하기 위해서는 반드시 우선순위를 설정해줘야 함!

@Order(-1)
@RequiredArgsConstructor
@Component
public class ErrorResponse implements ErrorWebExceptionHandler {
    private final ObjectMapper objectMapper;

    @Override
    public Mono<Void> handle(ServerWebExchange exchange, Throwable ex) {
        ServerHttpResponse response = exchange.getResponse();

        BaseResponse<?> baseResponse;
        if (ex instanceof BaseException e) {
            baseResponse = new BaseResponse<>(e.getStatus());
            response.setStatusCode(baseResponse.httpStatus());
        } else {
            baseResponse = new BaseResponse<>(BaseResponseStatus.INTERNAL_SERVER_ERROR, ex.getMessage());
            response.setStatusCode(HttpStatus.INTERNAL_SERVER_ERROR);
        }

        response.getHeaders().setContentType(MediaType.APPLICATION_JSON);
        try {
            return response
                    .writeWith(Mono.just(response.bufferFactory()
                    .wrap(objectMapper.writeValueAsBytes(baseResponse))));
        } catch (JsonProcessingException e) {
            return Mono.error(e);
        }
    }
}

➕ 커스텀 예외인 BaseException과 그 외의 예외를 구분하여 처리

• BaseException : BaseResponseStatus에 지정한 상태코드 + 메세지

• 그 외의 예외 : 상태코드 500 + + result에 실제 원인을 담은 메세지 전달

이 글에서 연결한 도메인에 접속해보니 갑자기 504가 뜨면서 접속이 안되는 문제가 발생,, 분명 처음에는 잘 됐는데 왜 갑자기 안된걸까?

분명 과제 제출 전에는 잘 됐는데,, 제출 후에 터지니까 너무 당황스러워서 급하게 이것저것 찾아보니 로드밸런서에 연결된 대상 그룹의 상태가 Unhealthy여서 연결이 끊긴 거였음,,

오른쪽 끝에 상태 확인 세부 정보를 보면** Health checks failed with these codes: [404]라고 뜨는데 이게 뭔 말인가 보니 **상태 검사 코드가 404라서 에러가 뜬다! 라는 뜻이라고 함. 근데 상태 검사가 뭔데,,?

✅ 원인 : 상태 검사

로드밸런서와 대상(인스턴스)이 정상적으로 연결되는지 주기적으로 상태를 검사하는 것

대상 그룹에서 상태 검사 탭을 보면 위와 같은 설정 값을 볼 수 있다. 내용을 대충 요약해보자면,

⭐ 프로토콜:포트/경로 를 통해 30초 간격으로 요청을 보내고, 응답의 상태 코드가 200이면 정상적인 연결

• 요청을 연속 5번 성공하면 정상 임계값으로 판단하여 Healthy
• 요청을 연속 2번 실패하면 비정상 임계값으로 판단하여 Unhealthy

인 것 같은데,, 다시 내 에러 코드를 보면 ** Health checks failed with these codes: [404]이므로, /pockyjx.site/로 상태 검사 요청 시 200이 아니라 **404를 반환해서 에러가 발생한다는 뜻,,

여기서 드는 의문 2개

1. 해당 요청에서 왜 404를 반환할까?
2. 처음에는 잘 되다가 왜 갑자기 안될까?

이 2개를 한 번에 해결 해버리는 원인을 찾았는데,, app.module.ts에서 Controller: []에 /를 처리하는 컨트롤러인 *AppController를 뺐기 때문,, *

// app.module.ts
@Module({
  imports: [
    ...
  ],
  controllers: [], // 여기에 AppController를 넣어야 '/'에 대한 요청을 처리..
  providers: [AppService],
})

export class AppModule {}

// app.controller.ts
@Controller()
export class AppController {
  constructor(private readonly appService: AppService) {}

  @Get() // 루트(/)에 대한 요청 처리 : 상태 검사
  getHello(): string {
    return this.appService.getHello();
  }
}

좀 더 자세히 정리해보자면,,

• 첫 배포 때는 Controller: [AppController]였기 때문에 /에 대한 요청을 처리하는 AppController가 활성화되어 있어서 상태 검사 요청 시 200을 반환해서 Healthy 상태를 유지. 따라서 이때까지는 서버 안터짐.

• 두 번째 배포에서 swagger에 사용하지도 않는 컨트롤러가 뜨는게 거슬려서 Controller: [] 상태로 배포했는데 (⬅️ 여기서 개큰문제 발생..) 이거 때문에 /를 처리할 수 있는 AppController가 비활성화 되었고, 상태 검사 요청 시 404를 반환하게 되면서 Unhealthy 상태가 된 것,, ⭐

⚙️ 해결

1. 성공 코드 변경

/에 요청 시, 상태 코드가 404일 때 성공으로 판단하도록 변경

2. 상태 검사 경로 변경

상태 검사 요청 경로를 서비스가 처리할 수 있는 경로로 변경

➕ 대상 그룹 생성 시 설정

사실 가장 좋은 방법은,, 처음에 대상 그룹 생성 할 때부터 잘 생각한후에 설정값 잘 넣기,, ㅎ

2차 때 정신 없어서 도메인 연결 관련해서 정리 못했던 것도 있고,, 마침 과제 하면서 개인 프로젝트? 배포용 도메인 하나 산 기념으로 다시 연결해보면서 정리해보는 글,,

💡 Route 53

⭐ Route 53 : 클라우드 기반의 DNS 웹 서비스 ➡️ EC2, ELB, S3 등의 다양한 인프라와 연결 가능

➕ DNS (Domain Name System) : 도메인 이름 ➡️ IP 주소 변환

✅ 도메인 연결

도메인 구매하기 : 가비아

1. Route 53 : 호스팅 영역

• 호스팅 영역 생성 : 구매한 도메인 주소 입력
  

2. 네임서버 설정

• 호스팅 영역 시 NS, SOA 레코드가 자동 생성되는데, 이 중 NS 레코드가 제공하는 4개의 트래픽 값을 가비아의 네임서버로 등록해줘야 함. xxx.xxx.xxx. 형태로 제공하는데, 여기서 마지막 .을 지우고 입력해야 함.

• 가비아에서 사용할 도메인의 네임서버에 4개의 트래픽 값을 1~4차에 순서대로 입력!

3. ACM : 인증서 요청

• ACM(Amazon Certificate Manager)에서 인증서 요청 : 도메인 주소 입력 ➡️ 검증까지 10분정도 걸린듯?

• 검증 기다리는 동안 생성된 인증서를 통해 Route 53에서 레코드 생성 해주기. 다시 Route 53으로 돌아가서 해당 도메인 호스팅 영역을 확인해보면 CNAME 레코드가 생성된 것을 확인할 수 있음! (늦게 캡쳐해서 A 레코드까지 있는데 얘는 밑에서 생성할 예정..)

• 이것저것 하다보면 어느샌가 인증서가 발급되어 있다,, 다음 단계 ㄱㄱ

4. 대상 그룹

EC2 → 로드 밸런싱 → 대상 그룹

• 대상 유형 : EC2 인스턴스에 배포했으므로 인스턴스 선택

• 프로토콜 : 포트 : nestjs 프로젝트를 3000번 포트로 배포했으므로 HTTP:3000으로 설정

• 대상 등록 : 도메인 연결할 인스턴스 선택 후 아래에 보류 중인 것으로 포함 꼭 클릭하기,, 안했다가 로드밸런서까지 다 연결했는데 계속 503 떠서 한참 삽질함 ^-^,,

5. 로드밸런서

EC2 → 로드 밸런싱 → 로드밸런서

• 가용 영역 : 최소 2개 이상 선택해야 함. 각 영역을 체크하면 서브넷 ID가 나오는데, 해당 영역의 서브넷 ID가 연결할 인스턴스의 서브넷 ID와 일치하는 걸 포함해줘야 함! 나는 2a가 같길래 그냥 위에서 2개 설정해줌..

• 리스너 : HTTP와 HTTPS에 연결해줌. HTTP의 경우 프로젝트를 3000번으로 배포했으므로 해당 포트와 연결하고, HTTPS는 기본 포트인 443 + 위에서 만든 인증서까지 연결. 해준 후에 둘 다 위에서 생성한 대상 그룹과 연결해주기!

• 로드밸런서를 생성했으면 Route 53으로 돌아가서 해당 호스팅 영역에 레코드 생성 후에 만든 로드밸런서 연결해주기! (별칭 선택) 그러면 A 레코드까지 생성 완료.

• 로드밸런서 생성 시 만들어준 HTTP/HTTPS 리스너에 새로운 규칙 생성

  • HTTPS : https://도메인 접속 시 대상 그룹으로 바로 연결

  • HTTP : http://도메인 접속 시 https://도메인으로 리다이렉션하도록 설정!

로드밸런서까지 설정한 후에 도메인 접속 시 배포된 프로젝트가 정상적으로 보이는 것을 확인할 수 있음!

현재는 과제로 제출한 nestjs 프로젝트를 연결해놨는데, 앞으로 개인 프로젝트나 개인적으로 뭐 배포할 일 있으면 해당 도메인을 애용할 예정,,

API 구현하기 전에 기본적으로 뭘 셋팅해줘야 하나 이것저것 찾아보다가 일단 제일 많이 나온? 부분만 기본적으로 설정해보기..

✅ CORS

*main.ts *에서 설정 가능!

• default 설정 : 모든 도메인 허용

  const app = await NestFactory.create(AppModule, { cors: true }); // 방법 1
  app.enableCors(); // 방법 2

➡️ 위 방법대로 설정 시, default 옵션은 다음과 같음

{
  "origin": "*",
  "methods": "GET,HEAD,PUT,PATCH,POST,DELETE",
  "preflightContinue": false,
  "optionsSuccessStatus": 204
}

• 커스텀 옵션 : app.enableCors() 내에 지정할 옵션 명시

  app.enalbeCors({
    origin: ['url1', 'url2', ...], // 허용할 도메인 (단일 도메인일 경우 [] 생략)
    methods: 'GET, PUT, ...', // 허용 메서드
    credentials: true, // 인증 정보 포함 여부
    ...
  })

✅ 환경변수

config, cross-env 모듈을 사용하여 개발 환경(개발, 배포)에 따른 환경 변수 설정하기

1. config, cross-env 모듈 설치

   npm i @nestjs/config cross-env

2. package.json 설정 추가 : 실행 환경에 따른 NODE_ENV 지정 → dev=development, prod=production

   "scripts": {
    "start:dev": "npm run prebuild && cross-env NODE_ENV=development nest start --watch",
    "start:prod": "cross-env NODE_ENV=production node dist/main",
    "prebuild": "rimraf dist"
   },
   ...

3. app.module.ts : 실행 환경에 따른 env 파일 지정 → start:prod 실행 시 package.json 설정에 의해 NODE_ENV=production이므로 .prod.env를 실행하고, 그 외의 경우(start:dev) .dev.env 실행

import { Module } from '@nestjs/common';
import { AppController } from './app.controller';
import { AppService } from './app.service';
import { TypeOrmModule } from '@nestjs/typeorm';
import { ConfigModule } from '@nestjs/config';
import * as process from 'process';
import { Member } from './member/Member.entity';

@Module({
  imports: [
    ConfigModule.forRoot({
      isGlobal: true,
      load: [],
      cache: true,
      envFilePath: process.env.NODE_ENV === 'production' ? '.prod.env' : '.dev.env'
    })
  ],
  ...
})

✅ TypeORM

TypeORM : TypeScript와 JavaScript를 사용한 객체 관계 매핑 수행 (Java의 JPA와 같은 역할!)

1. npm을 통해 typeorm, mysql 패키지 설치

   $ npm install @nestjs/typeorm typeorm mysql2

2. 환경변수 설정

• .env : DB 설정 → 보안에 민감한 정보이므로 .gitignore 에 추가

  DB_HOST=host 주소
  DB_PORT=포트번호
  DB_USERNAME=사용자명
  DB_PASSWORD=비밀번호
  DB_DATABASE=사용할 스키마명

• app.module.ts : env의 DB 설정을 가져와서 실행

@Module({
  imports: [
    TypeOrmModule.forRoot({
      type: 'mysql',
      host: process.env.DB_HOST,
      port: +process.env.DB_PORT, // + : 문자열 → 숫자 변환
      username: process.env.DB_USERNAME,
      password: process.env.DB_PASSWORD,
      database: process.env.DB_DATABASE,
      entities: [사용할 엔티티 목록],
      synchronize: true // 실행 시 entites 내의 엔티티에 해당하는 테이블 자동 생성
    })
  ],
  ...
})

➕ 예제

엔티티를 생성하여 애플리케이션과 DB가 잘 연결되었는지 확인해보기!

• 엔티티 생성 : src/member/Member.entity.ts

import { Column, Entity, PrimaryGeneratedColumn } from 'typeorm';

@Entity() // 엔티티 지정 : () 안붙이면 실행 시 에러 발생
export class Member {
  @PrimaryGeneratedColumn() // PK : AI 적용
  id: number;

  @Column({type: 'varchar', nullable: false, length: 20}) // 컬럼 제약조건 지정 가능
  name: string;
}

• app.modules.ts. : entities에 생성한 엔티티 추가

  import { Member } from './member/Member.entity';
  

@Module({ imports: [ TypeOrmModule.forRoot({ entities: [Member], ... }) ], ... })

![](https://velog.velcdn.com/images/pockyjx_/post/58e08f7e-3d98-4aeb-b33a-9fa898d37fba/image.png) : 애플리케이션 실행 시 **`env`에 지정한 스키마에 테이블이 생성**되고, 각 **컬럼마다 제약조건이 잘 설정**된 것을 확인할 수 있다!

---

## ✅ Swagger

1. npm을 통해 **`swagger`** 모듈 설치
```shell
npm i --save @nestjs/swagger swagger-ui-express

2. main.ts : swagger 문서를 사용하기 위한 기본 설정 추가

• await app.listen(3000)를 실행하면 애플리케이션이 요청을 수신하기 시작함. 이때, listen()이 호출된 후에 swagger 모듈 설정이 실행되면 해당 모듈이 API 엔드포인트르 찾지 못해 404 에러가 발생하므로, 모든 모듈의 설정 및 생성을 끝낸 후에 listnen()을 가장 마지막에 실행해줘야 함!

import { NestFactory } from '@nestjs/core';
import { AppModule } from './app.module';
import { DocumentBuilder, SwaggerModule } from '@nestjs/swagger';

async function bootstrap() {
  const app = await NestFactory.create(AppModule, { cors: true });

  // 기본 설정
  const config = new DocumentBuilder()
    .setTitle('API 문서')
    .setDescription('API 문서입니다.')
    .setVersion('1.0')
    .build();

  // 문서 생성
  const document = SwaggerModule.createDocument(app, config);

  // localhost:3000/api 접속 시 생성한 swagger 문서 실행
  SwaggerModule.setup('api', app, document);

  await app.listen(3000);
}
bootstrap();

➕ 컨트롤러에 적용하기

• @ApiTags() : 컨트롤러에 대한 태그

• @ApiOperation() : 메서드에 대한 설명

• @ApiResponse() : 상태에 따른 응답 반환 형태

• @ApiBody() : 요청 Body에 대한 정보

• @ApiParam() : 요청 파라미터에 대한 정보

• @ApiQuery() : 쿼리에 대한 정보

• @ApiProperty() : 프로퍼티에 대한 정보 (DTO에서 주로 사용)

• app.controller.ts

import { Controller, Get } from '@nestjs/common';
import { AppService } from './app.service';
import { ApiOperation, ApiResponse, ApiTags } from '@nestjs/swagger';

@ApiTags('기본 API')
@Controller()
export class AppController {
  constructor(private readonly appService: AppService) {}

  @Get()
  @ApiOperation({ summary: '홈', description: '홈 접속' })
  @ApiResponse({ status: 200, description: '성공'})
  @ApiResponse({status: 404, description: '실패'})
  getHello(): string {
    return this.appService.getHello();
  }
}

🙏🏻 참고

• 01. Nest.js 프로젝트 초기 세팅하기

• Nest.js - 초기 세팅
• CORS (Nest.js 공식 문서)
• NestJS CORS
• [NestJS] 환경 변수 관리하기
• [NestJS] mysql 데이터베이스 연동하기
• NestJs 프로젝트에서 Swagger 사용하기

💡 Node.js

Chrome V8 Engine으로 빌드된 JavaScript 런타임 환경 → 다양한 OS 환경에서 실행 가능

• 싱글 쓰레드 비동기 방식 : 입력은 하나의 쓰레드에서 받지만, 받은 순서대로 처리하지 않고 먼저 처리된 결과 값을 먼저 반환

  • 하나의 쓰레드를 사용하므로 메모리 & 리소스 사용량이 적음
  • 하나의 쓰레드에서 에러가 발생하면 프로그램 전체로 전파됨
    

🙆🏻‍♀️ 장점

• 비동기 방식으로 인한 서버 부하 최소화
• npm을 통한 다양한 모듈 및 패키지 제공
• 구글이 제작한 V8 Engine을 사용하므로 확장성이 좋음

👍🏻 로직이 간단하면서, 대용량의 요청을 빠르게 처리해야 하는 서비스 : 스트리밍, 채팅 등

🙅🏻‍♀️ 단점

• 비동기 방식으로 인해 로직이 복잡해지면 콜백 함수의 늪에 빠질 수 있음
• 싱글 쓰레드이므로, 하나의 작업 처리 시간이 긴 경우에 불리함 ⭐
• 코드를 실행해야만 에러를 알 수 있음 : 싱글 쓰레드로 인해 에러 발생 시 전체 프로세스가 동작하지 않음. 따라서, 테스트가 매우 중요함!

👎🏻 로직이 복잡하면서 단일 작업의 처리 시간이 오래 걸리는 서비스

💡 Nest.js

Node.js에 기반을 둔 웹 프레임워크

• Node.js의 단점 보완

  • TypeScript 지원
  • 확장성 : 모듈/컴포넌트 기반으로 프로그램 작성
  • 객체지향 개념 도입 : IoC(제어의 역전), AOP(관점 지향 프로그래밍), DI(의존성 주입)
    

🙆🏻‍♀️ 장점

• Express, Fastify와 호환 가능
• OOP, 함수형 프로그래밍 일부 요소 사용 가능
• 규모 가변성 (scalable) : 운영 상황에 따라 애플리케이션의 규모가 동적으로 변함
• Nest.js에서 제공하는 아키텍처로 인해 유지보수 용이
  

🙅🏻‍♀️ 단점

• 러닝 커브가 있는 편 (Spring 경험이 있으면 괜찮을지도?..)
• 간결함을 추구하는 Node.js에 비해 구조가 복잡한 편

⚙️ 설치

✅ Nest.js는 Node.js 기반 : Node.js 먼저 설치 후, npm을 통해 Nest.js 라이브러리 설치

1. Node.js 설치 (LTS 권장)

• 설치 확인 : 버전이 출력되면 정상적으로 설치된 거임!

node -v

2. nestjs cli 설치

• -g : 글로벌 환경에 설치

  npm i -g @nestjs.cli # 설치
  npm root -g # 글로벌 환경 설치 경로 확인

3. 프로젝트 생성

nest new [프로젝트명]

• 프로젝트 생성 명령어 실행 시, 원하는 패키지 매니저를 선택해야 함. 나는 npm 선택!

? Which package manager would you ❤️  to use? (Use arrow keys)
> npm 
  yarn 
  pnpm 

⭐ 생성된 프로젝트

• app.controller.ts : 기본 컨트롤러 (라우팅 + 요청 처리)
• app.controller.spec.ts : 컨트롤러 단위 테스트용 파일
• app.module.ts : 최상위 모듈 파일
• app.service.ts : 단일 메서드를 사용하는 기본 서비스 로직
• main.ts : 애플리케이션을 실행하는 엔트리 파일
  

4. 실행

• 명령어 실행 후 http://localhost:3000 접속

  npm run start # 서버 실행
  npm run start:dev # 수정 사항 바로 반영

➕ main.ts

import { NestFactory } from '@nestjs/core';
import { AppModule } from './app.module';

async function bootstrap() {
  const app = await NestFactory.create(AppModule);
  await app.listen(3000); // 포트번호 지정
}
bootstrap();

➕ app.controller.ts : 컨트롤러

import { Controller, Get } from '@nestjs/common';
import { AppService } from './app.service';

@Controller() // 컨트롤러 선언
export class AppController {
  constructor(private readonly appService: AppService) {} // 서비스 의존성 주입 : 생성자

  @Get() // Get 요청을 받아서 처리 (루트 경로)
  getHello(): string {
    return this.appService.getHello(); // 서비스 로직 호출
  }
}

➕ app.service.ts : 서비스

import { Injectable } from '@nestjs/common';

@Injectable() // 다른 서비스에 주입될 수 있음을 명시 → 컨트롤러에서 주입하여 사용
export class AppService {
  getHello(): string { // 내부 로직 정의
    return 'Hello World!';
  }
}

🙏🏻 참고

• [Node.js] 특징 및 장단점

• NestJS 소개
• 1.1 NestJS 소개
• NestJS 시작하기
• [NestJs] 개발하기

MSA 환경 내의 모든 서비스 엔드 포인트 단일화

최근 진행했던 팀 프로젝트의 서비스아키텍처에서 가져온 부분인데, 간단히 설명하자면 프론트 서버에서 API를 호출하면 해당 서비스에 직접 API를 요청하는 것이 아니라, 게이트웨이 서버로 요청을 보낸 후에 게이트웨이에서 라우팅 작업을 통해 해당 서비스로 요청을 전달하는 방식으로 동작하게 된다.

게이트웨이를 사용하지 않으면 프론트에서 각 서버의 url을 알아야 하는데, 게이트웨이 통해 게이트웨이 url만을 사용하여 API 요청이 가능해진다!

💡 Spring Cloud Gateway

Spring Framework에서 제공하는 오픈 소스 기반의 Gateway 서비스

• Spring Cloud Gateway vs Spring Cloud Zuul (패치 중단)

  	SCG	Zuul
  기반 웹 서버	Netty	Tomcat
  동기/비동기	비동기	동기
  웹 프레임워크	Spring Webflux	Spring Web MVC

✅ 역할

• Routing : 요청을 전달할 경로(서비스) 설정
• Load Balancing : 여러 서버에 대한 트래픽을 분배하여 부하 분산 처리
• Filter : 요청에 대한 특정 작업 수행 → 인증, 에러 처리 등

1. 기본 설정

게이트웨이 서비스 생성 + 유레카 서버에 등록

• application.yml

  server:
  port: 8000
  

eureka: client: register-with-eureka: true fetch-registry: true service-url: defaultZone: http://localhost:8761/eureka

spring: application: name: gateway

![](https://velog.velcdn.com/images/pockyjx_/post/95a15c51-33f6-40a2-abca-19f33816aad6/image.png)


---

### 2. CORS 설정
> ✅ CORS (**C**ross-**O**rigin **R**esource **S**haring) : **다른 출처**에 있는 리소스에 접근(**요청**) <br>
→ **클라이언트 측에서 서버 측으로 요청**을 보내는 경우 출처가 다르므로 접근을 허용하지 않는 경우를 방지하기 위해, **특정 출처를 가지는 클라이언트의 요청의 접근을 허용**하도록 설정해야 함!

➕ 모놀리식 아키텍처의 경우 Spring Security를 통해 설정 가능함. MSA 환경에서도 각 서비스 별로 설정 가능하지만, 모든 서비스에 Spring Security 의존성을 추가하고 Config를 작성해줘야 함.. 어차피 게이트웨이를 거쳐서 서비스에 갈 것이기 때문에 **게이트웨이에서 CORS에 대한 설정**을 해줌으로써 **모든 서비스에 공통적으로 적용**할 수 있음! 

근데 또 공통적인 부분 말고 각 서비스 별로 추가로 설정해줘야 하는 경우가 있을지도?.. 이건 아직 경험 안해봐서 모르겠음 ㅎ..
<br>

- `application.yml`

  - **`allowedOrigins`** : **`*`**는 **모든 경로**를 허용하지만, **`allow-credentials: true`**인 경우에는 `*`를 사용할 수 없으므로 **허용할 모든 출처를 직접 명시**해야 함. (ex - JWT 토큰 검증)

```yml
spring:
  cloud:
    gateway:
      globalcors:
        cors-configurations:
          "[/**]":
            allowedOrigins: # 허용할 출처(도메인)
              - "http://localhost:3000" # 클라이언트 : 프론트 서버
            allow-credentials: true # 인증 포함 요청 가능 (JWT 토큰)
            allowedHeaders: "*" # 허용할 
            allowedMethods: # 허용할 HTTP 메서드
              - PUT
              - GET
              - POST
              - DELETE
              - OPTIONS # Preflight 요청 시 사용

3. 라우팅 설정

요청 경로에 따라 요청을 전달할 서비스 및 서버 선택 (로드 밸런싱)

• application.yml

  • uri : 요청을 전달할 주소 → 로드 밸런싱 적용 시 lb://eureka에 등록된 서비스명 형태로 명시

  • predicates : 해당 조건을 만족하는 요청만 명시된 uri로 전달 (조건문)

    • Path : 특정 경로 (ex - /member-service/** 경로의 요청만 전달)
    • Method : 특정 메서드

  • filters : 요청에 특정 작업 수행

    • StripPrefix=n : n번째 경로까지 제거한 후 전달 (ex - /member-service/partners/profile → `/partners/profile)

    • 커스텀 필터도 등록 가능 (ex - JWT 토큰 검증 필터)

spring:
    gateway:
      routes:
        - id: member-service # 라우팅 id
          uri: lb://MEMBER-SERVICE # 이동할 주소
          predicates: # 라우팅 조건 : 경로, 메서드, ...
            - Path=/member-service/**
          filters:
            - StripPrefix=1 # 첫번째 경로 제거
            # - rewritePath=/member-service/(?<segment>.*), /$\{segment} : StripPrefix와 같은 역할

ex1) member-service에 직접 요청

ex2) 게이트웨이를 통한 요청

: 서비스에 직접 요청했을 때와 결과가 같음. 즉, 게이트웨이에서 member-service로 요청을 잘 전달했다는 뜻!

➕ 게이트웨이 요청 시 member-service를 붙이지 않으면 404 에러가 발생하는데, 이는 라우팅 설정 시 /member-service/**에 해당하는 요청만 전달하도록 해놔서 그런거임.. 쉽게 말하면 /partners/profile을 처리하는 라우팅이 없기 때문!

🙏🏻 참고

• [Spring Cloud] Spring Cloud Gateway - 기본 개념

• API Gateway, MSA의 출입구 ( Spring Cloud Gateway )
• Spring Cloud Gateway CORS 문제 해결하기

Micro (작은?) Service (서비스) Architecture (구조) : 독립적으로 실행 및 배포 가능한 작은 서비스들로 이루어진 구조 ➡️ 다수로 분산된 프로젝트

↔️ Monolithic Architecture (모놀리식 아키텍처) : 모든 서비스가 하나의 프로젝트 내에 존재하는 구조

✅ 특징

서비스 간 API를 통한 상호작용 : 각 서비스의 엔드 포인트를 API 형태로 외부에 노출

• 각 서비스는 하나의 비즈니스(도메인)에 관한 기능만 수행 ➡️ 회원 서비스, 상품 서비스, ...
• 메시징 시스템을 통해 서비스 간 통신 가능 : Kafka, Fegin Client, RestTemplate, ...
  

🙆🏻‍♀️장점

• 재사용 및 유연한 확장 가능 : 다양한 서비스와 결합 가능
• 독립적인 실행 및 배포 : 특정 서비스 배포 시, 다른 서비스는 정상적으로 동작
• 다양한 기술 스택 사용 가능 : 서비스 별 필요한 기술 스택 사용 가능
• 서비스 간 장애 전파 최소화 : 특정 서비스에 장애가 발생해도, 다른 서비스는 정상적으로 동작
  

🙅🏻‍♀️ 단점

• 설계의 복잡성 : 도메인 설정의 모호함 → 잘못된 도메인 설정 시, 더 많은 비용이 들 수 있음
• 성능 저하 : 서비스 간 API 호출 시 통신 비용 및 지연 발생
• 트랜잭션 및 데이터 관리의 복잡성 : 분산 데이터베이스 사용으로 인해 데이터 관리가 비교적 어려움

💡 Spring Cloud

분산 시스템에 필요한 다양한 기능들을 추상화하여 제공하는 라이브러리

• Service Discovery : MSA 환경 내의 서비스를 검색, 호출 및 상태 관리 → Eureka, Zookeeper, ...
• API Gateway : MSA 환경 내의 모든 서비스 엔드 포인트 단일화 + 인증/인가 수행 → Zuul, Spring Cloud Gateway, ...
• Config Server : 각 서비스에서 필요한 설정 정보를 중앙에서 관리 + 변경 시 재빌드 하지 않고 런타임 중 적용 → Spring Cloud Config

➕ 구현 예제

1. Service Discovery

• Eureka Server : 30초에 한 번씩 등록된 서비스 목록 갱신

• Application.java : @EnableEurekaServer 어노테이션 추가

  @EnableEurekaServer
  @SpringBootApplication
  public class EurekaApplication { ... }

• application.yml ⭐

  spring:
  application:
    name: eureka
  
  output:
    ansi:
      enabled: always
  

server: port: 8761

eureka: client: register-with-eureka: false # 유레카 서버 본체이므로, 자신을 클라이언트로 등록하지 않음 fetch-registry: true # 캐싱 여부

➡️ http://localhost:8761 접속 시 등록된 서비스 목록 확인 가능 (아직 등록된 서비스 없음!)![](https://velog.velcdn.com/images/pockyjx_/post/288c0ca5-89aa-4783-9385-6e5f063903a1/image.png)


#### 2. Discovery Client
- **Eureka Discovery Client** : 서비스 **시작** 시 자신의 정보를 **Eureka Server에 등록** + 30초마다 상태 전달 ![](https://velog.velcdn.com/images/pockyjx_/post/e79f3b78-7e3c-447e-9332-8a1fc614bb4b/image.png)

- `Application.java` : **`@EnableDiscoveryClient`** 어노테이션 추가
```java
@SpringBootApplication
@EnableDiscoveryClient
public class MemberserviceApplication { ... }

• application.yml ⭐

  server:
  port: 0
  

spring: application: name: member-service # 서비스명

eureka: instance: # 인스턴스 생성 instance-id: # 인스턴스 id 랜덤 생성 : 랜덤 포트(0) 사용 시, 여러 개의 서비스가 실행되어도 0번 하나로 인식되는 경우 방지 ${spring.application.name}:${spring.application.instance_id:${random.value}} client: register-with-eureka: true # 유레카 서버에 서비스 등록 fetch-registry: true # 유레카 서버가 갱신될 때마다 정보 가져옴 service-url: defaultZone: http://localhost:8761/eureka/ # 유레카 서버 주소

``` ➡️ http://localhost:8761 접속 시 member-service가 등록된 것을 확인할 수 있다!

게이트웨이부터는 복잡하므로 다음 글에 계속..

🙏🏻 참고

• [MSA 개념 정립하기] MSA의 개념과 장단점

• [간단정리] MSA란?(등장배경, 특징, 장단점)
• Spring Cloud 공식 문서
• [Spring Cloud] 스프링 클라우드 란 무엇인가요?
• [Spring Cloud] Spring Cloud Eureka - 기본 개념 및 활용

AWS EC2 서버에서 Jenkins를 사용하여 CI/CD 자동 배포 서버 구축하기!

➕ EC2 인스턴스 생성하기 + 보안 그룹 생성 및 설정하기 : Ubuntu + t2.micro 서버 생성

🐋 Docker

1. EC2 서버 접속

ssh -i [키페어 이름] [리눅스 계정명]@[EC2 퍼블릭 IPv4 DNS]

• 터미널을 사용할 키페어 파일(.pem)이 존재하는 경로에서 열어줄 것
• 리눅스 계정명의 경우, 우분투 서버를 사용한다면 ubuntu

: 계정명이 ubuntu@ip[]로 변경되었다면 성공적으로 접속된 것!

2. Docker 설치

• 리눅스에서 기본으로 제공하는 apt 패키지 업데이트

  sudo apt-get update

• Docker 설치

  sudo apt-get install docker.io

  : 설치 후 docker --version을 입력했을 때, 버전이 뜨면 정상적으로 설치된 것!

• Docker 실행

  sudo service docker start

: sudo systemctl status docker를 통해 Docker의 실행 상태를 확인했을 때, active이면 정상적으로 실행되고 있다는 뜻!

3. Docker에 MySQL 설치

• MySQL Docker Image 다운 : 버전을 명시하지 않은 경우, 가장 최신 버전

  sudo docker pull mysql:[version]

• 다운로드 된 Docker image 목록 확인 : mysql이 설치됨

  sudo docker images

• MySQL Docker 컨테이너 생성 및 실행

  sudo docker run --name mysql-container -e MYSQL_ROOT_PASSWORD=[password] -d -p 3306:3306 mysql:latest

• Docker 컨테이너 리스트 확인 : mysql-container이 실행 중

  sudo docker ps -a

• EC2 *내부에서 실행중인 *MySQL Docker 컨테이너에 접속하기 : bash로 mysql 컨테이너에 접근 후 패스워드 입력 (입력해도 안보임) ➡️ mysql에 접속 완료!

  sudo docker exec -it mysql-container bash
  bash $ mysql -uroot -p

• 외부에서 MySQL 컨테이너에 접속하기 (Workbench) : EC2 인스턴스의 IP를 사용하여 연결 가능! ➡️ 보안 그룹에서 MySQL의 포트번호인 3306번을 열어줘야 함

• MySQL Docker 컨테이너 시작/중지/재시작

  # 실행
  docker start mysql-container
  

중지

docker stop mysql-container

재시작

docker restart mysql-container

---

### 4. Docker image 빌드

- 프로젝트 최상단 경로에 **`Dockerfile`** 생성 ➡️ `clean` 후 **`bootJar`**을 통해 **jar 파일 빌드**
![](https://velog.velcdn.com/images/pockyjx_/post/ea73a56f-edf2-46b4-95c0-b41894b209e7/image.png)

FROM openjdk:17 ARG JAR_FILE=build/libs/*.jar COPY ${JAR_FILE} app.jar ENTRYPOINT ["java", "-jar", "/app.jar"]

- **Dockerfile이 있는 패키지**(프로젝트)에서 터미널을 실행한 후, **Docker image 생성** ➡️ 태그 생략 시 `latest`
```shell
docker build -t [username/image명]:[태그명] .

• image 실행 ➡️ 포트번호 : 8888

docker run -p [외부 포트번호(사용자 지정)]:[컨테이너 내부 포트번호(8080)] [이미지명]:[태그]

: 8888번 포트에서 프로젝트가 정상적으로 실행된다!

5. Docker image를 DockerHub에 push

• Docker 로그인 : 이미 로그인 되어있다면 docker login 만으로 가능

  docker login -u [username]

• image push 하기

docker push [이미지명]

6. 배포

• EC2 서버에 접속 후 docker login 수행

• 로그인을 수행한 계정의 DockerHub에서 이전에 생성한 image를 컨테이너로 가져오기 (pull)

  sudo docker pull [이미지명]

  

• image 실행하기 (배포) ➡️ 포트번호 : 8888

  sudo docker run -d -p [외부 포트번호]:[컨테이너 내부 포트번호] [이미지명]:[태그]

🚨 트러블 슈팅

• ssh: connect to host [ip주소] port 22: Connection timed out : EC2 서버에 접속되지 않는 문제 발생

➡️ 인스턴스 생성 시 적용한 보안 그룹에 ssh의 22번 포트를 열어주지 않아서 ssh에 접속할 수 없었음.. 해당 보안 그룹에 22번 포트를 열어주니 정상적으로 연결됨!

🙏🏻 참고

• AWS EC2에서 Jenkins 자동배포 구축하기 (1)

• [Docker] Docker로 AWS EC2 - MySQL 설치 및 테스트
• [Docker] Docker - Spring Boot로 EC2 배포하기
• [Docker]도커 이미지 만들기 + 도커 이미지 dockerhub 에 push 해보기(feat.springboot)
• SpringBoot 프로젝트 docker로 배포하기

✅ 스프링 부트 + JPA를 사용하여 회원 관리 API (등록, 조회, 삭제) 구현하기

✔️ 도메인

• @Table(name = "users") : H2 시스템 내에 user 테이블이 존재하므로, 생성될 테이블의 이름을 users로 지정

• @JsonIgnore : 조회 시 반환하지 않을 데이터 → 비밀번호와 같은 보안에 민감한 데이터

@Entity
@NoArgsConstructor
@Table(name = "users")
@Getter
public class User {
    @Id @GeneratedValue
    private Long id;
    private String name;
    private int age;

    @JsonIgnore
    private String password;

    public User(String name, int age, String password) {
        this.name = name;
        this.age = age;
        this.password = password;
    }
}

✔️ 리포지토리

• 스프링 데이터 JPA가 제공하는 JpaRepository 사용 : 기본적인 CRUD 기능 제공

public interface UserRepository extends JpaRepository<User, Long> {}

✔️ 컨트롤러

• @RestController = @Controller + @ResponseBody : API 구현 시 사용

  • @Controller : *뷰 *페이지 반환
  • @ResponseBody : 반환되는 데이터를 JSON 등의 타입으로 변환하여 응답 메시지의 바디에 담아서 반환

• UserDTO : 회원 목록 조회 시 회원 수 + 회원 목록 형태로 반환하기 위한 DTO

@RestController
@RequestMapping("/users")
@RequiredArgsConstructor
public class UserController {
    private final UserRepository repository;

    @GetMapping
    public UserDTO allUsers() {
        List<User> users = repository.findAll();
        return new UserDTO(users.size(), users);
    }

    @PostMapping
    public ResponseEntity<User> save(@RequestBody User user) {
        User saveUser = repository.save(user);
        return ResponseEntity.status(HttpStatus.CREATED).build();
    }

    @GetMapping("/{id}")
    public User oneUser(@PathVariable Long id) {
        Optional<User> optional = repository.findById(id);
        if(optional.isEmpty()) throw new UserNotFoundException(id+"번 회원을 찾을 수 없습니다.");

        return optional.get();
    }

    @DeleteMapping("/{id}")
    public void deleteUser(@PathVariable Long id) {
        Optional<User> optional = repository.findById(id);
        if(optional.isEmpty()) throw new UserNotFoundException(id+"번 회원을 찾을 수 없습니다.");

        repository.deleteById(id);
    }

    @Data
    @AllArgsConstructor
    static class UserDTO {
        private int cnt;
        private List<User> users;
    }
}

ex1) GET /users : 회원 목록 조회

ex2) POST /users : 회원 저장 → 상태코드 201 created 반환

ex3) GET /users/{id} : 특정 회원 조회 → 존재하지 않는 회원일 경우 404 not found 반환

ex4) DELETE /user/{id} : 특정 회원 삭제 → 존재하지 않는 회원일 경우 404 not found 반환

📒 HATEOAS

Hypermedia As The Engine Of Application State : 요청과 관련된 URI를 응답에 담아서 반환

ex) 회원 등록 시 회원 목록 + 특정 회원 조회 링크 제공, 특정 회원 조회 시 회원 목록 링크 제공 등 ...

⭐ REST 구현의 3단계

1. 리소스의 도입 : 서버가 가진 모든 리소스에 대한 고유한 URI 제공
2. HTTP 동사 : HTTP Method를 통해 리소스에 수행하고자 하는 작업을 표현
3. HATEOAS : 해당 자원에 대해 호출 가능한 API 정보를 상태에 반영하여 표현

ex) 회원 삭제 API 설계

📝 스프링 부트 + HATEOAS 구현

✅ 특정 회원 조회 시 회원 목록, 회원 삭제 링크 전달하기

✔️ 라이브러리 추가 (build.gradle)

implementation 'org.springframework.boot:spring-boot-starter-hateoas'

✔️ 컨트롤러

• EntityModel : 결과 데이터 + 관련 링크 반환

  • add() : 링크 추가 ➕ withRel() : 해당 링크에 대한 참조 (설명)

• WebMvcLinkBuilder : 링크 생성 ** → **타겟 컨트롤러 내의 타켓 메서드에 매핑된 URI

  • linkTo() : 컨트롤러 클래스를 가리키는 WebMvcLinkBuilder 객체 반환

  • methodOn() : 타겟 메서드의 가짜 메서드 콜이 들어있는 컨트롤러 프록시 클래스를 생성

    @GetMapping("/{id}")
    public EntityModel<User> oneUser_HATEOAS(@PathVariable Long id) {
    Optional<User> optional = repository.findById(id);
    if(optional.isEmpty()) throw new UserNotFoundException(id+"번 회원을 찾을 수 없습니다.");
    User user = optional.get();
    
    EntityModel<User> entityModel = EntityModel.of(user);
    WebMvcLinkBuilder allUser = linkTo(methodOn(this.getClass()).allUsers());
    entityModel.add(allUser.withRel("all-user"));
    
    return entityModel;
    }

ex) GET /users/2 : 2번 회원 정보 + 회원 목록 API 링크 반환

📒 Swagger

개발한 REST API를 자동으로 문서화시키는 프레임워크 → API 목록 확인 및 테스트 가능

✔️ 라이브러리 (build.gradle)

• Springfox (2020.07 이후로 업데이트 X → doc 사용 권장)

• Springdoc ⭐ (스프링 부트 3.x 이후 버전부터 springdoc-openapi-ui 사용 시 404 에러 발생)

implementation 'org.springdoc:springdoc-openapi-starter-webmvc-ui:2.2.0'

라이브러리 추가 후 /swagger-ui/index.html에 접속하면 아래와 같은 페이지 확인 가능! (기본값 : 생성된 모든 API 컨트롤러 (@RestController) + 객체 출력)

✔️ 설정 : SwaggerConfig.java

• @OpenAPIDefinition(info) : API 명세서의 기본 정보 (제목, 설명, 버전 등)

• GroupedOpenApi : 여러 API 컨트롤러를 그룹화하여 표시

  • group : 그룹 이름
  • pathsToMatch : 그룹에 속하는 경로 패턴

@Configuration
@OpenAPIDefinition(
        info = @Info(
                title = "회원 관리 API 명세서",
                description = "회원 관리 API 명세서",
                version = "v1.0"
        )
)
public class SwaggerConfig {

    @Bean
    public GroupedOpenApi userAPI() {
        return GroupedOpenApi.builder()
                .group("회원 관리")
                .pathsToMatch("/users/**")
                .build();
    }
}

✔️ 도메인

• @Schema : 모델(객체)에 대한 상세 정보

@Entity
@NoArgsConstructor
@Table(name = "users")
@Getter
@Schema(description = "회원 정보를 관리하기 위한 도메인 객체")
public class User {

    @Id @GeneratedValue
    @Schema(title = "사용자 id", description = "자동 생성")
    private Long id;

    @Schema(title = "사용자 이름", description = "2 ~ 15글자 이내")
    private String name;

    @Schema(title = "사용자 나이", description = "5세 이상부터 가입 가능")
    private int age;

    @JsonIgnore
    @Schema(title = "비밀번호", description = "8 ~ 20자 이내의 영소문자+숫자+특수기호(!~_=+@#) 조합")
    private String password;

    ...
}

✔️ 컨트롤러

• @Tag : 클래스(컨트롤러)에 대한 상세 정보
• @Operation : 특정 경로에 대한 작업(메서드)에 대한 상세 정보
• @Parameter : 파라미터에 대한 상세 정보
• @ApiResponse : 응답 상태코드에 대한 상세 정보

@RestController
@RequestMapping("/users")
@RequiredArgsConstructor
@Tag(name = "users", description = "회원 관리 컨트롤러")
public class UserController {
    private final UserRepository repository;

    @GetMapping
    @Operation(summary = "회원 목록 API", description = "전체 회원 목록을 조회")
    public UserDTO allUsers() {
        List<User> users = repository.findAll();
        return new UserDTO(users.size(), users);
    }

    @PostMapping
    @Operation(summary = "회원 등록 API", description = "새로운 회원을 등록")
    public ResponseEntity<User> save(@RequestBody User user) {
        User saveUser = repository.save(user);
        return ResponseEntity.status(HttpStatus.CREATED).build();
    }

    @GetMapping("/{id}")
    @Operation(summary = "회원 조회 API", description = "사용자 ID를 통해 특정 회원 조회")
    @ApiResponses({
            @ApiResponse(description = "OK", responseCode = "200"),
            @ApiResponse(description = "NOT FOUND", responseCode = "404"),
            @ApiResponse(description = "INTERNAL SERVER ERROR", responseCode = "500")
    })
    public EntityModel<User> oneUser_HATEOAS(@Parameter(description = "사용자 ID", required = true, example = "1")
                                                 @PathVariable Long id) {
        Optional<User> optional = repository.findById(id);
        if(optional.isEmpty()) throw new UserNotFoundException(id+"번 회원을 찾을 수 없습니다.");
        User user = optional.get();

        EntityModel<User> entityModel = EntityModel.of(user);
        WebMvcLinkBuilder allUser = linkTo(methodOn(this.getClass()).allUsers());
        entityModel.add(allUser.withRel("all-user"));

        return entityModel;
    }

    @DeleteMapping("/{id}")
    @Operation(summary = "회원 삭제 API", description = "사용자 ID를 통해 특정 회원 삭제")
    public void deleteUser(@PathVariable Long id) {
        Optional<User> optional = repository.findById(id);
        if(optional.isEmpty()) throw new UserNotFoundException(id+"번 회원을 찾을 수 없습니다.");

        repository.deleteById(id);
    }

    ...
}

• @Tag + @Operation

• @Operation + @Parameter

• @ApiResponses

🙇🏻‍♀️ 참고 1 : [개정판 2023-11-27] Spring Boot 3.x 를 이용한 RESTful Web Services 개발 🙇🏻‍♀️ 참고 2 : Hypermedia-driven REST API 🙇🏻‍♀️ 참고 3 : [SpringBoot] Swagger API 문서 자동화 간단 연동, 테스트하기 🙇🏻‍♀️ 참고 4 : [Spring Boot] Springdoc 라이브러리를 통한 Swagger 적용

REpresentational State Transfer : 자원의 표현(이름)에 의한 상태(데이터) 전달

• 월드 와이드 웹(www)과 같은 분산 하이퍼미디어 시스템을 위한 소프트웨어 개발 아키텍처의 한 형식 : HTTP 프로토콜 사용 → HTTP URI를 통해 자원을 명시하고, HTTP Method를 통해 해당 자원에 CRUD 처리

  • HTTP URI : 자원의 표현 (이름) → 클라이언트는 URI를 통해 서버에 자원에 대한 처리를 요청함

  • HTTP Method : 자원에 대한 처리 (CRUD Operation)

    • POST = CREATE : 생성
    • GET = READ : 조회
    • PUT/PATCH = UPDATE : 완전/일부 수정
    • DELETE = DELETE : 삭제

• ⭐ 스마트폰이 급성장하게 되면서, 서버는 웹 브라우저 외에 모바일(안드로이드) 기기와 같은 다양한 클라이언트와 통신해야 하는 상황에 직면하게 된다. 이 때 HTTP 프로토콜을 따르는 플랫폼이라면 REST 방식을 사용하여 특정 언어나 기술에 종속되지 않고 통신할 수 있다.

📝 특징

1. server - client 구조

• server : 리소스를 가지고 있는 쪽 → API 제공 및 비즈니스 로직 처리
• client : 리소스를 요청하는 쪽 → context 관리

2. Stateless : 무상태 (서버는 클라이언트의 상태를 보존하지 않음)

: HTTP 프로토콜은 무상태이므로 HTTP 프로토콜 기반인 REST 또한 무상태이다.

3. Chaceable : 캐시 처리 가능

: HTTP 프로토콜에서 사용하는 Last-Modified, E-Tag 등을 사용하여 캐싱을 구현할 수 있다. 캐시를 사용하면 응답시간이 빨라져 API의 성능을 향상시킬 수 있다.

📒 REST API

REST 기반으로 서비스 API를 구현한 것

• API (Application Programming Interface) : 운영체제나 프로그래밍 언어가 제공하는 기능을 제어할 수 있게 만든 인터페이스 → 애플리케이션을 연결하여 서로 통신하는 것

: 하나의 API를 웹, 모바일 등 여러 시스템에서 사용함으로써 확장성 및 재사용성이 높아진다.

📝 설계 규칙

• URI : 리소스 표현 → 소문자, 복수 명사 권장

ex) 특정 회원 조회 : GET /members/{id}

• HTTP Method : 리소스에 대한 행위 표현 → URI에는 되도록이면 동사를 사용하지 않는다.

ex) 특정 회원 삭제 : DELETE /members/{id}

➕ REST API가 아닌 HTML Form의 경우, GET/POST만 지원하므로 필요에 따라 동사인 컨트롤 URI를 사용할 수도 있음 → POST /members/{id}/delete

• 슬래시 /는 계층 관계를 나타냄 : 하나의 리소스를 전달해야 하므로 URI의 마지막에 /를 사용하지 않는다.

ex) GET /members/ ❌ → GET /members ⭕

• 리소스 간 연관관계가 있는 경우, /리소스명/리소스ID/연관된 리소스명 형식으로 표현

ex) 특정 회원이 작성한 모든 게시글 조회 : GET /members/{id}/posts

• 파일 확장자는 URI에 포함하지 않는다. → 헤더 (Accept) 사용

ex) GET /members/image.jpg ❌ → GET /members + Accept: image/jpg ⭕

✔️ REST API 설계 예시

: 실제로 사용된 URI는 /members, /members/{id} 2개이지만, HTTP Method를 통해 각 작업을 구분하여 다양한 작업을 처리할 수 있다!

🙇🏻‍♀️ 참고 : [Network] REST란? REST API란? RESTful이란?

객체의 생성과 표현을 분리하여 다양한 구성의 인스턴스를 만드는 생성 패턴

📒 점층적 생성자 패턴

필수 입력 필드 + 선택 입력 필드를 하나씩 늘려가며 생성자를 오버로딩하는 방식

public class Member {

    // 필수 입력 정보
    private String name;
    private int age;

    // 선택 입력 정보
    private String phoneNumber;
    private String email;
}

클래스를 생성하다 보면 위 경우처럼 값이 무조건 있어야 하는 필수 입력 필드와, 값이 있어도, 없어도 되는 선택 입력 필드가 존재하게 된다.

public class Member {
    ...

    public Member() {}

    // 필수 입력 정보 생성자
    public Member(String name, int age) {
        this.name = name;
        this.age = age;
    }

    // 필수 입력 정보 + 전화번호 생성자
    public Member(String name, int age, String phoneNumber) {
        this.name = name;
        this.age = age;
        this.phoneNumber = phoneNumber;
    }

    // 필수 입력 정보 + 이메일 + 전화번호 생성자
    public Member(String name, int age, String phoneNumber, String email) {
        this.name = name;
        this.age = age;
        this.phoneNumber = phoneNumber;
        this.email = email;
    }
}

생성자를 통해 값을 입력받는 경우, 필수 정보를 입력받는 생성자, 필수 입력 정보 + 선택 정보 1을 입력받는 생성자, 필수 입력 정보 + 선택 정보 2를 입력받는 생성자, ... 와 같이 경우에 따른 생성자를 별도로 생성해야 한다. 이는 한 클래스 내의 필드 수가 증가할수록 생성자의 수 또한 증가하여 가독성이 떨어지게 된다.

Member member1 = new Member("member1", 10, "010-1234-5678", "member1@naver.com");
Member member2 = new Member("member2", 20, "member2@naver.com", "010-9876-5432");

또한, 각 생성자의 매개변수 순서를 기억해야 한다. 타입이 같은 필드가 여러 개인 경우 순서가 바뀌어도 타입만 일치하면 컴파일 에러가 발생하지 않고 정상적으로 실행되기 때문에 이후 해당 데이터를 사용하는 로직 처리 시 문제가 될 수 있다.

📒 자바 빈즈 패턴

기본 생성자 + setter()를 통한 값 입력

public class Member {
    // 필수 정보
    private String name;
    private int age;

    // 선택 정보
    private String phoneNumber;
    private String email;

    public Member() {}

    public void setName(String name) {
        this.name = name;
    }

    public void setAge(int age) {
        this.age = age;
    }

    public void setPhoneNumber(String phoneNumber) {
        this.phoneNumber = phoneNumber;
    }

    public void setEmail(String email) {
        this.email = email;
    }
}

점층적 생성자 패턴의 단점을 해결하기 위해 자바 빈즈 패턴을 활용할 수 있다. 자바 빈즈 패턴은 생성자를 일일이 만드는 대신 기본 생성자 하나만 만들고, 각 필드에 대한 setter() 메서드를 열어두어 값을 입력받는 방식이다.

Member member = new Member();

member.setName("member");
member.setAge(10);
member.setEmail("member@naver.com");
member.setPhoneNumber("010-1234-5678");

자바 빈즈 패턴을 사용하면 필드의 입력 순서를 기억할 필요 없이, setXXX()를 통해 각 필드에 맞는 값을 입력할 수 있다. 하지만, 이 방식 또한 setter()를 모두 정의해야 하기 때문에 가독성이 좋은 편은 아니며 (해당 문제는 Lombok의 @Setter로 해결 가능), 필수 입력 필드에 대한 값 입력을 필수로 두지 않기 때문에, 누락할 가능성이 존재한다.

또한, setter()의 가장 큰 문제는 해당 메서드를 통해 어디서든 객체의 데이터를 변경할 수 있다는 것이다. 여러 메서드에서 특정 인스턴스를 호출하여 setter()로 값을 변경하다 보면, 이후 변경에 대한 추적이 힘들어 유지보수성이 떨어지게 된다. 따라서, setter()를 무작위로 열어두는 것은 위험을 초래할 수 있다.

📒 빌더 패턴

별도의 Builer 클래스의 메서드 통해 값을 입력받은 후, build()를 통해 인스턴스 생성

📝 Builder 클래스 구현

1. 기준 클래스와 같은 필드를 가지는 Builder 클래스 구현
2. 값을 입력받기 위한 생성자 + 메서드 생성 → Builder 객체를 리턴하여 체이닝 기법 적용
3. 최종 인스턴스를 반환하는 build() 메서드 생성

public class Member {
    // 필수 정보
    private String name;
    private int age;

    // 선택 정보
    private String phoneNumber;
    private String email;

    // 빌더 클래스
    static class MemberBuilder {
        private String name;
        private int age;
        private String phoneNumber;
        private String email;

        // 필수 입력 필드 : 생성자
        public MemberBuilder(String name, int age) {
            this.name = name;
            this.age = age;
        }

        public MemberBuilder setPhoneNumber(String phoneNumber) {
            this.phoneNumber = phoneNumber;
            return this;
        }

        public MemberBuilder setEmail(String email) {
            this.email = email;
            return this;
        }

        // 최종 인스턴스 생성
        public Member build() {
            Member member = new Member();

            member.name = name;
            member.age = age;
            member.email = email;
            member.phoneNumber = phoneNumber;

            return member;
        }
    }
}

Member member = new Member
                        .MemberBuilder("member", 10)
                        .setPhoneNumber("010-1234-5678")
                        .build();

생성자를 통해 필수 입력 필드인 name과 age의 값을 입력받고, 선택 입력 필드인 phoneNumber와 email은 메서드를 통해 선택적으로 값을 입력할 수 있다. 최종적으로 build() 메서드를 호출해야 입력값이 적용된 Member 인스턴스가 정상적으로 반환된다.

📝 @Builder

Lombok에서 제공하는 빌더 클래스 생성 어노테이션 : 클래스 및 생성자 단위에 적용 가능

✔️ 클래스

• 클래스 단위에 적용 시, 모든 필드를 포함하는 빌더 클래스 생성

@Builder
public class Member {
    // 필수 정보
    private String name;
    private int age;

    // 선택 정보
    private String phoneNumber;
    private String email;
}

Member member = Member.builder()
                .name("member")
                .age(10)
                .email("member@naver.com")
                .phoneNumber("010-1234-5678")
                .build();

➕ 클래스 단위에 @Builder와 @NoArgsConstructor를 함께 사용하면 에러 발생 : @Builder는 생성자가 없는 경우에만 생성자를 자동으로 생성한다. 따라서, @NoArgsConstructor에 의해 기본 생성자가 생성되거나, 클래스 내에 모든 필드를 가지는 생성자가 아닌 다른 생성자가 있는 경우 모든 필드를 가지는 생성자를 수동으로 생성해주어야 한다. (@AllArgsConstructors 추가)

✔️ 생성자

• 생성자 단위에 적용 시, 해당 생성자의 매개변수에 포함된 필드만을 사용하여 빌더 클래스 생성

public class Member {
    // 필수 정보
    private String name;
    private int age;

    // 선택 정보
    private String phoneNumber;
    private String email;

    @Builder
    public Member(String name, int age, String phoneNumber) {
        this.name = name;
        this.age = age;
        this.phoneNumber = phoneNumber;
    }
}

Member member = Member.builder()
                .name("member")
                .age(10)
                //.email("member@naver.com") // 에러 발생 : 생성자에 미포함된 필드
                .phoneNumber("010-1234-5678")
                .build();

🙇🏻‍♀️ 참고 1 : [JAVA] 빌더패턴 (Builder Pattern) , @Builder 🙇🏻‍♀️ 참고 2 : Builder 패턴, @NoArgsConstructor, @AllArgsConstructor

Breath First Search : 다차원 배열을 탐색할 때, 너비를 우선으로 탐색하는 알고리즘

• int[][] graph : 그래프를 2차원 배열로 표현

  • 배열의 인덱스 : 노드 번호 (0번 노드는 없으므로 아무것도 입력하지 않음)

  • 해당 인덱스 내의 요소 : 인접한 노드 번호

• boolean[] isVisit : 노드의 방문 여부 표시

• bfs(int start) : *start번 노드부터 *탐색 수행

  1. 큐에 시작점을 넣고 방문 표시
  2. 큐의 가장 앞에 위치한 노드를 꺼내고 인접한 노드 탐색 2-1. 인접한 노드에 방문 표시가 없다면 큐에 넣고 방문 표시 후** 2번 반복** 2-2. 인접한 노드가 없거나 이미 방문했다면 2번 반복
  3. 큐가 비면 탐색 종료

import java.util.*;
public class Main {

    // 그래프 : 인덱스 - 인접 노드 형태
    static int[][] graph = {{}, {2,3,5}, {1}, {1,4}, {3}, {1,6}, {7, 8}, {6,8}, {6,7}};

    // 노드 방문 여부
    static boolean[] isVisit = new boolean[graph.length];

    // 탐색 순서 출력
    static StringBuilder sb = new StringBuilder();

    public static void main(String[] args) {

        // 1번 노드부터 탐색 시작
        bfs(1);

        bw.write(sb + "");
        bw.close();
    }

    static void bfs(int start) {
        Queue<Integer> q = new LinkedList<>();

        q.offer(start); // 1. 시작 노드 삽입
        isVisit[start] = true; // 1. 시작 노드 방문 표시


        while(!q.isEmpty()) { // 3. 큐가 빌 때까지 반복
            int idx = q.poll(); // 2. 탐색할 노드 인덱스
            sb.append(idx + " ");

            for(int i=0;i< graph[idx].length;i++) { // 2. 인접한 노드 탐색
                int tmp = graph[idx][i];

                if(!isVisit[tmp]) { // 2-1. 인접한 노드에 방문하지 않은 경우
                    q.offer(tmp); // 2-1. 인접 노드 큐에 삽입
                    isVisit[tmp] = true; // 2-1. 인접 노드 방문 표시
                }
            }
        }
    }
}

✅ 모든 칸이 큐에 한 번씩 들어갔다 나오므로, N개의 칸에 대한 시간 복잡도는 O(N) → 한 칸 당 O(1)

🙇🏻‍♀️ 참고 : [Algorithm] BFS(Breadth-first search)를 Java로 구현해보자!

📒 연습문제

📝 예제 1

[1926] 그림 : 파란색으로 칠해진 칸들 중, 상하좌우로 연결된 모든 칸을 탐색하기 → (0, 0)에서 시작

0. 시작 지점인 (0, 0)에 대해 방문 표시하기

1. (0, 0)의 상하좌우를 탐색하여 파란색이면서 방문하지 않은 칸의 좌표를 큐에 삽입한 후 방문 표시하기

2. 큐의 가장 앞 원소 좌표로 이동하며 큐에서 해당 좌표를 제거한 후, 1번 과정 반복

3. 큐가 비면 탐색 종료

   
   

✔️ 구현

import java.io.*;
import java.util.*;

public class Main {

    static int[][] graph;
    static boolean[][] isVisit;
    static int[] dx = {-1, 1, 0, 0};
    static int[] dy = {0, 0, -1, 1};
    static int n, m;


    public static void main(String[] args) throws IOException {

        BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
        BufferedWriter bw = new BufferedWriter(new OutputStreamWriter(System.out));

        StringTokenizer st = new StringTokenizer(br.readLine());
        n = Integer.parseInt(st.nextToken()); // 세로 (행)
        m = Integer.parseInt(st.nextToken()); // 가로 (열)

        graph = new int[n][m];
        isVisit = new boolean[n][m];

        for(int i=0;i<n;i++) {
            st = new StringTokenizer(br.readLine());
            for(int j=0;j<m;j++) {
                graph[i][j] = Integer.parseInt(st.nextToken());
            }
        }

        int cnt = 0;
        int max = 0;
        for(int i=0;i<n;i++) {
            for(int j=0;j<m;j++) {
                if(graph[i][j] == 1 && !isVisit[i][j]) {
                    max = Math.max(max, bfs(j, i));
                    cnt++;
                }
            }
        }

        bw.write(cnt + "\n" + max);
        bw.close();
    }

    static int bfs(int x, int y) {
        Queue<int[]> q = new LinkedList<>();
        q.offer(new int[] {x, y});
        isVisit[y][x] = true;

        int area = 1;
        while(!q.isEmpty()) {
            int[] tmp = q.poll();
            int px = tmp[0]; int py = tmp[1];

            for(int i=0;i<4;i++) {
                int nx = px + dx[i];
                int ny = py + dy[i];

                if(nx < 0 || ny < 0 || nx > m-1 || ny > n-1) continue;
                if(graph[ny][nx] == 1 && !isVisit[ny][nx]) {
                    q.offer(new int[] {nx, ny});
                    isVisit[ny][nx] = true;
                    area++;
                }
            }
        }
        return area;
    }
}

📝 예제 2 : 최단거리 측정

[2178] 미로 탐색

• graph[x][y] : 이 칸으로 오기까지 거쳐온 칸의 수 = 이전 칸의 값 + 1

import java.io.*;
import java.util.*;

public class Main {

    static int[][] graph;
    static boolean[][] isVisit;
    static int[] dx = {-1, 1, 0, 0};
    static int[] dy = {0, 0, -1, 1};
    static int n, m;

    public static void main(String[] args) throws IOException {

        BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
        BufferedWriter bw = new BufferedWriter(new OutputStreamWriter(System.out));

        StringTokenizer st = new StringTokenizer(br.readLine());
        n = Integer.parseInt(st.nextToken());
        m = Integer.parseInt(st.nextToken());

        graph = new int[n][m];
        isVisit = new boolean[n][m];

        for(int i=0;i<n;i++) {
            String s = br.readLine();

            for(int j=0;j<m;j++) {
                graph[i][j] = s.charAt(j) - '0';
            }
        }

        bfs(0, 0);

        bw.write(graph[n-1][m-1] + "");
        bw.close();
    }

    static void bfs(int x, int y) {
        Queue<int[]> q = new LinkedList<>();
        q.offer(new int[] {x, y});
        isVisit[x][y] = true;

        while(!q.isEmpty()) {
            int[] tmp = q.poll();
            int px = tmp[0];
            int py = tmp[1];

            for(int i=0;i<4;i++) {
                int nx = px + dx[i];
                int ny = py + dy[i];

                if(nx < 0 || ny < 0 || nx > n-1 || ny > m-1) continue;
                if(graph[nx][ny] == 1 && !isVisit[nx][ny]) {
                    q.offer(new int[] {nx, ny});
                    isVisit[nx][ny] = true;
                    graph[nx][ny] = graph[px][py] + 1;
                }
            }
        }
    }
}

📝 예제 3 : 시작점이 여러 개

[7576] 토마토

• 탐색 시작점이 여러 개인 경우 graph를 채울 때 시작점의 좌표를 큐에 넣고 시작하면 된다!

• 시작점의 값이 1이므로, 최종 답은 graph[x][y] - 1

import java.io.*;
import java.util.*;

public class Main {

    static int[][] graph;
    static int[] dx = {-1, 1, 0, 0};
    static int[] dy = {0, 0, -1, 1};
    static int n, m;
    static Queue<int[]> q = new LinkedList<>();

    public static void main(String[] args) throws IOException {

        BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
        BufferedWriter bw = new BufferedWriter(new OutputStreamWriter(System.out));

        StringTokenizer st = new StringTokenizer(br.readLine());
        m = Integer.parseInt(st.nextToken());
        n = Integer.parseInt(st.nextToken());

        graph = new int[n][m];
        for(int i=0;i<n;i++) {
            st = new StringTokenizer(br.readLine());
            for(int j=0;j<m;j++) {
                graph[i][j] = Integer.parseInt(st.nextToken());
                if(graph[i][j] == 1) q.offer(new int[] {i, j});
            }
        }
        bw.write(bfs() + "");
        bw.close();
    }

    static int bfs() {
        while(!q.isEmpty()) {
            int[] tmp = q.poll();
            int px = tmp[0];
            int py = tmp[1];

            for(int i=0;i<4;i++) {
                int nx = px + dx[i];
                int ny = py + dy[i];

                if(nx < 0 || ny < 0 || nx > n-1 || ny > m-1) continue;
                if(graph[nx][ny] == 0) {
                    graph[nx][ny] = graph[px][py] + 1;
                    q.offer(new int[] {nx, ny});
                }
            }
        }

        int day = 0;
        for(int i=0;i<n;i++) {
            for(int j=0;j<m;j++) {
                if(graph[i][j] == 0) return -1;
                day = Math.max(day, graph[i][j]);
            }
        }
        return day - 1;
    }
}

📝 예제 4 : 시작점이 두 종류

• 시작점의 종류가 다른 경우, 각 시작점에 대하여 BFS 수행

  • fire[][] (불) : 좌표가 범위를 넘지 않으면서 벽(#)이 아니라면 이전 좌표의 시간 + 1 저장

  • move[][] (지훈) : 좌표가 벽이 아니면서 지훈이가 도달한 시간이 불이 퍼지기 전인 경우 이전 좌표의 시간 + 1 저장 → 좌표가 범위를 넘으면 탈출한 것이므로 시간 출력 / 반복문이 종료되면 탈출하지 못한 것이므로 IMPOSSIBLE출력

import java.io.*;
import java.util.*;
public class Main {

    public static class Node {
        int x, y;
        public Node(int x, int y) {
            this.x = x;
            this.y = y;
        }
    }

    public static void main(String[] args) throws IOException {

        BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
        BufferedWriter bw = new BufferedWriter(new OutputStreamWriter(System.out));

        StringTokenizer st = new StringTokenizer(br.readLine());
        int r = Integer.parseInt(st.nextToken());
        int c = Integer.parseInt(st.nextToken());

        int[][] move = new int[r][c];
        int[][] fire = new int[r][c];

        Queue<Node> moveQ = new LinkedList<>();
        Queue<Node> fireQ = new LinkedList<>();

        for(int i=0;i<r;i++) {
            String s = br.readLine();
            for(int j=0;j<c;j++) {
                char ch = s.charAt(j);

                if(ch == 'J') {
                    move[i][j] = 1;
                    moveQ.offer(new Node(i, j));
                }
                else if(ch == 'F') {
                    fire[i][j] = 1;
                    fireQ.offer(new Node(i, j));
                }
                else {
                    move[i][j] = ch;
                    fire[i][j] = ch;
                }
            }
        }

        int[] dx = {-1, 1, 0, 0};
        int[] dy = {0, 0, -1, 1};

        Node tmp;
        int px, py, nx, ny;

        // 불 bfs
        while(!fireQ.isEmpty()) {
            tmp = fireQ.poll();
            px = tmp.x; py = tmp.y;

            for(int i=0;i<4;i++) {
                nx = px + dx[i]; ny = py + dy[i];
                if(nx < 0 || ny < 0 || nx > r-1 || ny > c-1) continue;
                if(fire[nx][ny] == '.') {
                    fire[nx][ny] = fire[px][py] + 1;
                    fireQ.offer(new Node(nx, ny));
                }
            }
        }

        // 지훈 bfs
        while(!moveQ.isEmpty()) {
            tmp = moveQ.poll();
            px = tmp.x; py = tmp.y;

            for(int i=0;i<4;i++) {
                nx = px + dx[i]; ny = py + dy[i];
                if(nx < 0 || ny < 0 || nx > r-1 || ny > c-1) { // 탈출
                    System.out.println(move[px][py]); return;
                }

                if(move[nx][ny] != '#') {
                    if(move[px][py] + 1 < fire[nx][ny]) {
                        move[nx][ny] = move[px][py] + 1;
                        moveQ.offer(new Node(nx, ny));
                    }
                }
            }
        }

        // 탈출 실패
        System.out.println("IMPOSSIBLE");
    }
}

: 2차원 배열 2개에 큐까지 2개 써서 그런지 메모리 초과 발생,, 인줄 알았으나 다른 사람들의 풀이를 봐도 다 2개씩 쓰고 통과하던데 나는 왜? 싶어서 GPT한테 물어봤는데,,

상상도 못한 답변 ㄴㅇㄱ.. 시간 비교에만 집중하느라 해당 좌표에 갔는지 표시를 안했던 것.. 그래서 같은 칸을 중복으로 탐색하다 보니 메모리 초과가 발생한 것.. 그래서 탐색한 불의 좌표를 -1로 표시하고 이후 해당 좌표가 -1이면 탐색하지 않도록 처리하니 성공!

// 지훈 bfs
while(!moveQ.isEmpty()) {
    tmp = moveQ.poll();
    px = tmp.x; py = tmp.y;

       for(int i=0;i<4;i++) {
        nx = px + dx[i]; ny = py + dy[i];
        if(nx < 0 || ny < 0 || nx > r-1 || ny > c-1) { // 탈출
            System.out.println(move[px][py]); return;
        }

        if(move[nx][ny] != '#') {
               // 방문하지 않았거나, 
            if(fire[nx][ny] != -1 && move[px][py] + 1 < fire[nx][ny]) {
                move[nx][ny] = move[px][py] + 1;
                fire[nx][ny] = -1; // 방문 표시
                  moveQ.offer(new Node(nx, ny));
              }
        }
    }
}

📝 예제 5 : 1차원에서의 BFS

[1697] 숨바꼭질

• 그래프를 1차원 배열로 생성하여, 시작 위치에서 x+1, x-1, 2x로 이동한 후 각 이동 위치에서 다시 x+1, x-1, 2x로 이동하는 방식으로 탐색을 수행하다가, 동생이 있는 위치에 도달하면 탐색을 종료한다.

import java.io.*;
import java.util.*;
public class Main {

    static int[] graph = new int[100001];
    static int s, e;

    public static void main(String[] args) throws IOException {
        BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
        StringTokenizer st = new StringTokenizer(br.readLine());
        s = Integer.parseInt(st.nextToken());
        e = Integer.parseInt(st.nextToken());

        System.out.println(bfs());
    }

    static int bfs() {
        Queue<Integer> q = new LinkedList<>();
        q.offer(s);
        graph[s] = 1;

        while(!q.isEmpty()) {
            int tmp = q.poll();
            if(tmp == e) return graph[tmp]-1;

            if(tmp-1 >= 0 && graph[tmp-1] == 0) {
                graph[tmp-1] = graph[tmp] + 1;
                q.offer(tmp-1);
            }

            if(tmp+1 < 100001 && graph[tmp+1] == 0) {
                graph[tmp+1] = graph[tmp] + 1;
                q.offer(tmp+1);
            }

            if(tmp*2 < 100001 && graph[tmp*2] == 0) {
                graph[tmp*2] = graph[tmp] + 1;
                q.offer(tmp*2);
            }
        }
        return 0;
    }
}

💡 DFS

Depth First Search : 다차원 배열을 탐색할 때, 깊이를 우선으로 탐색하는 알고리즘

✅ 큐가 스택으로 변경된 것 외에는, BFS와 전체적인 흐름이 같다!

1. 스택에 시작점을 넣고 방문 표시
   3. 스택의 꼭대기에 위치한 노드를 꺼내고 인접한 노드 탐색 2-1. 인접한 노드에 방문 표시가 없다면 스택에 넣고 방문 표시 후** 2번 반복** 2-2. 인접한 노드가 없거나 이미 방문했다면 2번 반복
   4. 스택이 비면 탐색 종료

import java.io.*;
import java.util.*;
public class Main {

    static int[][] graph = {{}, {2,3,5}, {1}, {1,4}, {3}, {1, 6}, {5, 7, 8}, {6, 8}, {6, 7}};
    static boolean[] isVisit = new boolean[graph.length];
    static StringBuilder sb = new StringBuilder();

    public static void main(String[] args) throws IOException {
        bfs(1);
        System.out.println(sb);
    }

    static void bfs(int v) {
        Stack<Integer> s = new Stack<>();
        s.push(v);
        isVisit[v] = true;

        while(!s.isEmpty()) {
            int idx = s.pop();
            sb.append(idx + " ");

            for(int i=graph[idx].length-1;i>=0;i--) {
                int tmp = graph[idx][i];
                if(!isVisit[tmp]) {
                    s.push(tmp);
                    isVisit[tmp] = true;
                }
            }
        }
    }

: 스택은 후입선출이기 때문에, 순서를 맞추기 위해 각 노드에 인접한 노드를 역순으로 탐색

📒 BFS vs DFS

• BFS : 시작점과 인접한 노드 모두 탐색 → 각 인접 노드와 인접한 노드 모두 탐색 → ...

• DFS : 시작점과 인접한 노드 하나 탐색 → 한 노드와 인접한 노드의 탐색이 모두 끝난 후 시작점과 인접한 *다른 노드 하나 *탐색 → ...

⭐ 거리 탐색 시, BFS에서는 시작점과 인접한 노드의 거리가 모두 +1이였지만 DFS는 해당 공식이 성립하지 않기 때문에 거리 탐색 시 사용할 수 없다!

🙇🏻‍♀️ 출처

• [바킹독의 실전 알고리즘] 0x09강 - BFS
• [바킹독의 실전 알고리즘] 0x0A강 - DFS

Spring Data가 제공하는 페이징 + 정렬 추상화 인터페이스

: 구현체인 PageReauest를 통해 페이징에 필요한 데이터(시작 페이지, 최대 결과 개수, 정렬 조건)를 전달하면 페이징 결과를 Page타입으로 반환한다.

📒 게시판 페이징

목표 : 모든 게시글을 조회한 결과를 페이징하여 화면에 나타내기

✅ 스프링 부트,** 스프링 데이터 JPA**, 타임리프 사용

1. Entity

@Entity
@Getter @Setter
@NoArgsConstructor(access = AccessLevel.PROTECTED)
public class Post {
    @Id @GeneratedValue
    @Column(name = "board_id")
    private Long id;
    private String title;
    @Lob
    private String content;
    private LocalDateTime createDate;
    private LocalDateTime updateDate;

    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "member_id")
    private Member member;

    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "category_id")
    private Category category;
}

2. BoardDTO

• 화면에 출력할 정보 : 게시글 번호, 카테고리명(category), 게시글 제목, 작성자 이름(member), 작성일

@Data
public class BoardDTO {
    private Long id;
    private String categoryName;
    private String title;
    private String userName;

    @DateTimeFormat(pattern = "yyyy-MM-dd HH:mm")
    private LocalDateTime createDate;

    public BoardDTO(Post post) {
        this.id = post.getId();
        this.categoryName = post.getCategory().getName();
        this.title = post.getTitle();
        this.userName = post.getMember().getUserName();
        this.createDate = post.getCreateDate();
    }
}

2. Repository

• Spring Data JPA 사용 : JpaRepository 상속

• findBoard(Pageable) : 페치 조인을 통해 연관관계를 가지는 member와 category를 한 번에 조회 + 파라미터로 전달된 pageable를 데이터를 통해 페이징 수행

public interface PostRepository extends JpaRepository<Post, Long> {
    @Query("select p from Post p join fetch p.category c join fetch p.member m")
    Page<Post> findBoard(Pageable pageable);
}

3. Service

• findAll(Pagealbe)

  • 리포지토리의 findBoard(Pageable)에 pageable 전달
  • page.map() : findBoard()가 반환한 엔티티를 BoardDTO로 변환하여 컨트롤러에 반환

@Service
@RequiredArgsConstructor
@Transactional
public class PostService {
    private final PostRepository postRepository;

    public Page<BoardDTO> findAll(Pageable pageable) {
        Page<Post> page = postRepository.findBoard(pageable);
        return page.map(board -> new BoardDTO(board));
    }
}

4. Controller

• 요청의 파라미터로 page, size, sort 등의 정보가 넘어오면 Pageable 타입으로 바인딩 → 해당 데이터를 사용하여 PageRequest 객체 생성

  • @PageableDefault : 페이징 관련 데이터 기본값 설정

    • size : 최대 결과 개수 (default = 20)
    • page : 조회 페이지 (default = 0)
    • sort + direction : 단일 정렬 조건

  • @SortDefault.SortDefaults({@SortDefault(sort=,direction), ...}) : 다중 정렬 조건

• 뷰 페이지에 page, pm (하단부 페이징 관련 데이터) 전달

@Controller
@RequestMapping("/boards")
@RequiredArgsConstructor
public class BoardController {
    private final PostService postService;

    @GetMapping
    public String postList(@PageableDefault(size = 2, sort = "id", direction = Sort.Direction.DESC) Pageable pageable,
                               Model model) {

        Page<BoardDTO> page = postService.findAll(pageable);
        PageMaker pm = new PageMaker(page);

        model.addAttribute("pm", pm);
        model.addAttribute("page", page);

        return "board/postList";
    }
}

: /boards 요청 시 실행되는 쿼리 (게시글 전체 조회 + 카운트 쿼리)

5. PageMaker

• 컨트롤러에서 전달받은 Page를 사용하여 화면의 하단 페이징 영역 관련 데이터 (계산식은 이전 프로젝트에서 사용한 공식 사용..)

  • page.getNumber() : 현재 요청한 페이지 → 0부터 시작하므로, 1 더한 값 출력
  • page.getTotalPages() : 페이지의 총 개수

@Getter
public class PageMaker {
    private int nowPage; // 현재 페이지
    private int startPage; // 현재 페이지 블럭 내의 첫번째 페이지
    private int endPage; // 현재 페이지 블럭 내의 마지막 페이지
    private boolean prev; // 이전 페이지가 있는가?
    private boolean next; // 다음 페이지가 있는가?
    private int block = 2; // 한 번에 출력할 페이지 개수

    public PageMaker(Page<?> page) {
        nowPage = page.getNumber() + 1;

        endPage = (int)(Math.ceil((double)(nowPage)/block)) * block;
        startPage = endPage - block + 1;
        endPage = Math.min(endPage, page.getTotalPages());

        prev = startPage != 1;
        next = ((long)endPage < page.getTotalPages());
    }
}

6. HTML : 하단부 페이징

• Previous : 해당 페이지 블럭의 prev가 true인 경우에만 출력

  • 첫 페이지 («) : /boards?page=0
  • 이전 페이지 블럭의 endPage (‹) : /boards?page=startPage-2

• 페이지 블럭 : startPage ~ endPage 출력 → 출력된 p의 값은 page+1이므로, 클릭 시 /boards?page=p-1로 이동

• Next : 해당 페이지 블럭의 next가 true이면서 endPage가 0 이상인 경우에만 출력

  • 다음 페이지 블럭의 startPage (›) : /boards?page=endPage
  • 마지막 페이지 endPage (») : /boards?page=getTotalPages()-1

<nav aria-label="Page navigation example">
    <ul class="pagination justify-content-center pagination-sm">

    <!-- 첫 페이지로 이동 -->
    <li class="page-item" th:if="${pm.prev}">
        <a class="page-link" th:href="@{/boards(page=0)}" aria-label="Previous">
            <span aria-hidden="true">&laquo;</span>
        </a>
    </li>
    <!-- 첫 페이지 이동 -->

    <!-- 이전 페이지 블럭으로 이동 -->
    <li class="page-item" th:if="${pm.prev}">
        <a class="page-link" th:href="@{/boards(page=${pm.startPage}-2)}" aria-label="Previous">
            <span aria-hidden="true">&lsaquo;</span>
        </a>
    </li>
    <!-- 이전 페이지 블럭으로 이동 -->

    <!-- 페이지 블럭 -->      
    <li th:class="page-item" th:each="p : ${#numbers.sequence(pm.startPage, pm.getEndPage())}"
        th:classappend="(${pm.nowPage == p})? 'active' : ''">
        <a class="page-link" th:href="@{/boards(page=${p}-1)}" 
               th:text="${p}"></a>
    </li>
    <!-- 페이지 블럭 --> 

    <!-- 다음 페이지 블럭으로 이동 --> 
    <li class="page-item" th:if="${pm.next && pm.endPage > 0}">
        <a class="page-link" th:href="@{/boards(page=${pm.endPage})}" aria-label="Next">
            <span aria-hidden="true">&rsaquo;</span>
        </a>
       </li>
    <!-- 다음 페이지 블럭으로 이동 --> 

    <!-- 마지막 페이지로 이동 --> 
    <li class="page-item" th:if="${pm.next && pm.endPage > 0}">
        <a class="page-link" th:href="@{/boards(page=${page.getTotalPages()}-1)}" aria-label="Next">
            <span aria-hidden="true">&raquo;</span>
        </a>
    </li>
    <!-- 마지막 페이지로 이동 --> 

    </ul>
</nav>

📝 시연

ex0) *테스트 데이터 *

ex1) block = 2, size = 2

ex2) block = 5, size = 2

ex3) block = 5, size = 5

➕ 일단은 Page 타입으로 받아서 일반 게시판 형태로 구현해봤는데, 나중에 시간이 되면 Slice 타입으로 받아서 더보기 형식으로 구현해봐야겠다!

한 쪽 끝에서만 원소를 넣고 뺄 수 있는 자료구조 : 후입선출 (LIFO)

• 원소의 추가 & 제거 & 상단의 원소 확인 : O(1) → 원칙적으로 상단의 원소를 제외한 나머지 원소를 확인할 수 없음

📒 구현

배열 혹은 연결 리스트를 사용하여 구현 가능

- dat[] : 스택을 구현할 배열
- pos : 상단 원소의 위치

• push() : 스택에 원소 추가

  void push(int x) {
    dat[pos++] = x;
  }

• pop() : 스택에서 원소 제거

  void pop() {
    pos--;
  }

• top() : 스택의 상단 원소 확인

  int top() {
    return dat[pos-1];
  }

📒 연습문제

[10733] 제로

public class Main {
    public static void main(String[] args) throws IOException {

        BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
        BufferedWriter bw = new BufferedWriter(new OutputStreamWriter(System.out));

        Stack<Integer> stack = new Stack<>();
        int k = Integer.parseInt(br.readLine());

        for(int i=0;i<k;i++) {
            int num = Integer.parseInt(br.readLine());
            if(num == 0) stack.pop();
            else stack.push(num);
        }

        int sum = 0;
        for (Integer i : stack) {
            sum += i;
        }

        bw.write(sum + "");
        bw.close();
    }
}

[2493] 탑

public class Main {
    public static void main(String[] args) throws IOException {

        BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
        BufferedWriter bw = new BufferedWriter(new OutputStreamWriter(System.out));

        Stack<int[]> stack = new Stack<>();
        int n = Integer.parseInt(br.readLine());

        StringTokenizer st = new StringTokenizer(br.readLine());
        StringBuilder sb = new StringBuilder();
        for(int i=0;i<n;i++) {
            int tmp = Integer.parseInt(st.nextToken());
            while(!stack.isEmpty()) {
                if(stack.peek()[0] < tmp) stack.pop();
                else {
                    sb.append(stack.peek()[1] + " "); break;
                }
            }

            if(stack.isEmpty()) sb.append("0 ");
            stack.push(new int[] {tmp, i+1});
        }
        bw.write(sb + "");
        bw.close();
    }
}

💡 큐 (Queue)

한 쪽 끝에서 원소를 넣고, 반대쪽 끝에서 원소를 뺄 수 있는 자료구조 : 선입선출 (FIFO)

• 원소의 추가 & 제거 & 앞 뒤 원소 확인 : O(1) → 앞/뒤가 아닌 나머지 원소들의 확인 및 변경은 원칙적으로 불가능

📒 구현

원형 배열을 사용한 구현

- dat[] : 큐를 구현할 배열
- head = 0 : 가장 앞 원소의 인덱스 (제거할 위치)
- tail = 0 : 가장 뒤 원소의 인덱스 + 1 (삽입할 위치)
- mx : 배열 크기

: 큐를 배열로 구현하게 되면 원소를 하나씩 꺼낼 때마다 head가 증가하는데, 이 때 head가 한 칸씩 밀리게 되면서 앞 공간에는 더이상 원소를 넣을 수 없게 된다.

: 이를 해결하기 위해, 원형 배열을 구현하여 head가 배열의 마지막 원소까지 도달한 경우 tail을 비어있던 앞 공간으로 이동시켜 데이터를 삽입할 수 있다. (입력 개수가 정해진 코딩 테스트의 경우, 벼열의 크기를 입력 개수보다 크게 선언하여 사용하면 선형 배열으로 사용 가능)

• push() : 큐에 원소 삽입

void push(int x) {
    if(tail == mx) tail = 0;
    dat[tail++] = x;
}

• pop() : 큐의 원소 제거

  void pop() {
    if(head == mx) head = 0;
    else head++;
  }

• fornt() / back() : 큐의 가장 앞/뒤 원소 반환

int front() { return dat[head]; }

int back() { return dat[tail-1]; }

📒 연습문제

[2164] 카드2

public class Main {
    public static void main(String[] args) throws IOException {

        BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
        BufferedWriter bw = new BufferedWriter(new OutputStreamWriter(System.out));

        Queue<Integer> q = new LinkedList<>();
        int n = Integer.parseInt(br.readLine());
        for(int i=1;i<=n;i++) {
            q.offer(i);
        }

        while(q.size() != 1) {
            q.poll();
            q.offer(q.poll());
        }

        bw.write(q.poll() + "");
        bw.close();
    }
}

💡 덱 (Deque)

양쪽 끝에서 원소를 넣고 뺄 수 있는 자료구조

• 원소의 추가 & 제거 & 앞 뒤 원소 확인 : O(1) → 가장 앞/뒤가 아닌 나머지 원소들의 확인이 원칙적으로 불가능

📒 구현

배열이나 연결 리스트를 사용하여 구현

- mx : 배열의 크기
- dat[2*mx+1] : 덱을 구현할 배열
- head = mx / tail = mx 

: 덱에서는 양쪽에서 삽입과 제거가 이루어지기 때문에, head와 tail의 시작 지점을 mx로 두고, 배열의 크기를 2*mx+1로 두어 양쪽으로 확장 가능하게 설계해야 한다.

• push_front/back() : 앞/뒤쪽에서 원소 삽입

void push_front(int x) { dat[--head] = x; }
vois push_back(int x) { dat[tail++] = x; }

• pop_front/back() : 앞/뒤쪽에서 원소 제거

void pop_front() { head++; }
void pop_back() { tail--; }

• front/back() : 앞/뒤 원소 반환

  int front() { return dat[head]; }
  int back() { return dat[tail-1]; }

📒 연습문제

[1021] 회전하는 큐

• 중간 인덱스를 기준으로 특정 원소의 인덱스가 작으면 2번 연산, 크면 3번 연산 수행 → 앞/뒤 원소가 아닌 중간 원소의 인덱스에 접근 하므로 연결 리스트를 사용하여 구현

import java.io.*;
import java.util.*;

public class Main {
    public static void main(String[] args) throws IOException {

        BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
        BufferedWriter bw = new BufferedWriter(new OutputStreamWriter(System.out));

        StringTokenizer st = new StringTokenizer(br.readLine());
        int n = Integer.parseInt(st.nextToken());
        int m = Integer.parseInt(st.nextToken());

        LinkedList<Integer> deque = new LinkedList<>();
        for(int i=1;i<=n;i++) {
            deque.add(i);
        }

        int[] arr = new int[m];
        st = new StringTokenizer(br.readLine());
        for(int i=0;i<m;i++) {
            arr[i] = Integer.parseInt(st.nextToken());
        }

        int cnt = 0;
        for(int i=0;i<m;i++) {
            int target = deque.indexOf(arr[i]);
            int mid = 0;

            if(deque.size() % 2 == 0) mid = deque.size() / 2 - 1;
            else mid = deque.size() / 2;

            if(target <= mid) {
                for(int j=0;j<target;j++) {
                    deque.addLast(deque.pollFirst());
                    cnt++;
                }
            }

            else {
                for(int j=0;j<deque.size()-target;j++) {
                    deque.addFirst(deque.pollLast());
                    cnt++;
                }
            }

            deque.pollFirst();
        }

        bw.write(cnt + "");
        bw.close();
    }
}

🙇🏻‍♀️ 출처

• [바킹독의 실전 알고리즘] 0x05강 - 스택
  
• [바킹독의 실전 알고리즘] 0x06강 - 큐
  
• [바킹독의 실전 알고리즘] 0x07강 - 덱
  

원소를 저장할 때, 다음 원소가 있는 위치를 포함하여 저장하는 자료구조

• k번째 원소를 확인/변경 : O(K) 소요 → 첫번째 주소값을 통해 차례대로 두번째, 세번째, .., K번째 원소에 도달

• 임의의 위치에 원소를 추가 & 제거 : O(1) 소요 (추가하고 싶은 위치의 주소값을 아는 경우, 모르면 첫번째부터 탐색해야 하므로 K+1) → 뒤의 요소를 모두 옮기는 것이 아닌, 다음 원소의 주소값만 변경하면 됨

• 원소들이 메모리에 연속적으로 위치하지 않아 메모리 할당이 쉬움 → 캐시 적중률은 낮음

• 각 원소가 다른 원소의 주소값을 가지고 있어야 하기 때문에, N에 비례하는 추가 공간이 필요하다.

📒 종류

📝 단일 연결 리스트

각 원소가 자신의 다음 원소의 주소를 가지고 있는 연결 리스트

📝 이중 연결 리스트

각 원소가 자신의 이전 원소와 다음 원소의 주소를 가지고 있는 연결 리스트

📝 원형 연결 리스트

끝이 처음과 연결되어 있는 연결 리스트 (단일 & 이중 모두 가능)

📒 배열 vs 연결 리스트

배열과 연결 리스트는 선형 자료구조이다!

📒 구현

배열에 원소를 저장하고, 각 원소의 이전 원소와 다음 원소의 주소값을 각각의 배열에 저장 → 0번에서 시작한다고 가정, 이전 혹은 다음 원소가 없으면 -1

• dat[] : 원소의 값
• pre[] : 이전 원소의 주소값
• nxt[] : 다음 원소의 주소값

• traverse() : 원소값 출력 → 배열의 순서대로 출력하는 것이 아닌, 연결 리스트 순서대로 출력

void traverse() {
    int cur = nxt[0]; // 현재 주소값

    while(cur != -1) { // nxt[] = -1 : 다음 원소가 없다는 뜻
        System.out.println(dat[cur] + ' ');
        cur = nxt[cur];
    }
}

• insert() : 임의의 위치에 원소 추가

void insert(int addr, int num) {
    dat[unused] = num; // 1. 새로운 원소 생성
    pre[unused] = addr; // 2. 새 원소의 pre : 삽입 위치의 주소값
    nxt[unused] = nxt[addr]; // 3. 새 원소의 nxt : 삽입 위치의 nxt

    // 4. 삽입 위치 다음 원소의 pre : 새 원소의 주소값 (삽입 위치에서 다음 원소가 있는 경우)
    if(nxt[addr] != -1) pre[nxt[addr]] = unused; 
    nxt[addr] = unused; // 4. 삽입 위치의 nxt : 새 원소의 주소값 

    unused++; // 5. 다음에 값을 추가할 주소
}

• erase() : 임의의 위치의 원소 삭제

void erase(int addr) {

    nxt[pre[addr]] = nxt[addr]; // 1. 이전 위치의 nxt : 삭제할 위치의 nxt    
    if(nxt[addr] != -1) pre[nxt[addr]] = pre[addr]; // 2. 다음 위치의 pre : 삭제할 위치의 pre
}

📒 연습문제

[1406] 에디터

import java.io.*;
import java.util.Arrays;
import java.util.LinkedList;
import java.util.List;
import java.util.StringTokenizer;

public class Main {
    public static void main(String[] args) throws IOException {

        BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
        BufferedWriter bw = new BufferedWriter(new OutputStreamWriter(System.out));

        LinkedList<Character> list = new LinkedList<>();
        String s = br.readLine();
        for(int i=0;i<s.length();i++) {
            list.add(s.charAt(i));
        }

        int n = Integer.parseInt(br.readLine());
        int cursor = list.size();
        for(int i=0;i<n;i++) {
            String order = br.readLine();
            switch (order.charAt(0)) {
                case 'L' : if(cursor > 0) cursor--; break;
                case 'D' : if(cursor < list.size()) cursor++; break;
                case 'B' : if(cursor > 0) { list.remove(cursor - 1); cursor--; } break;
                case 'P' : list.add(cursor, order.charAt(2)); cursor++;
            }
        }

        StringBuilder sb = new StringBuilder();
        for(char ch : list) {
            bw.write(ch);
        }
        bw.close();
    }
}

: 위 코드를 제출하니 시간 초과가 떴다.. 아무래도 삽입/삭제 시 해당 인덱스를 바로 찾아가는 것이 아닌 첫 시작점부터 차례대로 찾아가야 하므로 O(N)의 시간 복잡도를 가지게 되어 발생한 문제인 것 같다. 그렇다면 이를 어떻게** O(1)**로 풀 수 있을까?

✔️ ListIterator

Iterator를 상속한 인터페이스 : 양방향 탐색 가능

✅ ListIterator를 사용해서 해당 인덱스를 처음부터 순서대로 찾아가는 것이 아닌, 실제 커서가** 특정 위치에서 한 칸씩 움직이는 형태로 동작하므로, **O(1)의 시간 복잡도를 가지게 된다!

• list.listIterator() : 가장 앞에서부터 탐색 시작 → 문제의 조건은 제일 끝에서 시작하므로 list.size()를 시작 위치로 지정

• hasPrevious() : 이전 원소가 있는지 확인 (역방향) → previous() : 이전 원소 리턴

• hasNext() : 다음 원소가 있는지 확인 (정방향) → next() : 다음 원소 리턴

• remove() : next() 또는 previous()가 가리키는 원소 제거

• add() : 현재 탐색 위치에 원소 추가

public class Main {
    public static void main(String[] args) throws IOException {

        BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
        BufferedWriter bw = new BufferedWriter(new OutputStreamWriter(System.out));

        LinkedList<Character> list = new LinkedList<>();
        String s = br.readLine();
        for(int i=0;i<s.length();i++) {
            list.add(s.charAt(i));
        }

        int n = Integer.parseInt(br.readLine());
        ListIterator<Character> cursor = list.listIterator(list.size());
        for(int i=0;i<n;i++) {
            String order = br.readLine();
            switch (order.charAt(0)) {
                case 'L' : if(cursor.hasPrevious()) cursor.previous(); break;
                case 'D' : if(cursor.hasNext()) cursor.next(); break;
                case 'B' : if(cursor.hasPrevious()) { cursor.previous(); cursor.remove(); } break;
                case 'P' : cursor.add(order.charAt(2));
            }
        }

        StringBuilder sb = new StringBuilder();
        for(char ch : list) {
            bw.write(ch);
        }
        bw.close();
    }
}

🙇🏻‍♀️ 참고 : 백준 1406번) 에디터(ListIterator)

➕ 스택을 사용한 풀이도 있었는데 그건 스택 강의 듣고 다시 보기..

🙇🏻‍♀️ 출처 : [바킹독의 실전 알고리즘] 0x04강 - 연결 리스트