yoo97 개발 블로그

[백준] 5464. 주차장

yoo97 — Fri, 24 Feb 2023 09:19:34 +0900

문제 링크 : https://www.acmicpc.net/problem/5464

# N: 주차 공간 개수, M: 총 차량 댓수
N, M = map(int, input().split())

# 각 주차 공간의 단위 요금표
cost_table = []
for _ in range(N):
     cost = int(input())
     cost_table.append(cost)

# 차량 번호별 차량의 무게. 1번부터 시작
cars_weight = [0]
for __ in range(M):
    weight = int(input())
    cars_weight.append(weight)

# 출력할 정답. 총 금액
answer = 0

# 주차 공간 생성. 0은 비어있다는 의미
space = [0 for _ in range(N)]

# 주차 공간이 부족하면 대기할 대기열
queue = []

# count: 현재 주차된 총 댓수.
# for를 통해 매번 비어있는지 확인해도 되지만
# 매번 전체 주차 공간을 탐색하면 비효율적임.
# count와 N이 동일하면 빈 공간이 없다고 판단할 수 있음.
count = 0

for i in range(2 * M):
    # car: 양수이면, 해당 번호의 차량 주차. 음수이면 해당 번호의 차량 출차
    car = int(input())
    # 주차하는 경우
    if car > 0:
        # space가 만차 상태이면
        if count == N:
            # 주차 대기
            queue.append(car)
        # space에 빈 공간이 있으면
        else:
            # 앞에서부터 빈 공간 확인하기
            for j in range(N):
                # 현재 공간이 비어있으면
                if space[j] == 0:
                    # 현재 공간에 주차
                    space[j] = car
                    # 주차했으므로 현재 총 주차된 차량 수 증가
                    count += 1
                    break
    # 출차하는 경우
    else:
        # 음수를 양수로 변환. car 차량을 출차하면 된다.
        car = car * -1
        # 아래는 주차된 공간에서 car 차량을 찾는 로직
        for j in range(N):
            # 현재 확인중인 공간에 car가 주차되어 있으면
            if space[j] == car:
                # cost_table[j]: j번째 공간의 단위 무게당 비용
                # space[j]: j번째 공간에 주차된 차량 번호
                # cars_weight[space[j]]: 차량의 무게
                # car_cost: 해당 차량이 내야할 요금(공간의 무게당 비용 * 차량의 무게)
                car_cost = cost_table[j] * cars_weight[space[j]]
                answer += car_cost
                # 원래 주차된 차량이 나갔으므로
                # 해당 자리를 빈자리로 만들거나 대기 차량을 주차시켜야 한다.
                # 대기차량이 있으면
                if queue:
                    # 해당 자리에 대기 차량을 주차시킨다.
                    space[j] = queue.pop(0)
                # 대기 차량이 없으면
                else:
                    # 해당 자리를 빈자리로 만든다.
                    space[j] = 0
                    # 차량이 나가기만 했으니 총 주차된 차량 댓수를 1 감소시킨다.
                    count -= 1

print(answer)

[Spring] Logback 설정

yoo97 — Sun, 5 Feb 2023 16:28:11 +0900

Spring Boot Logback 설정

Logback

로깅 프레임워크 중 하나로 SLF4J의 구현체이다.

Logback은 logback-core, logback-classic, logback-access의 3가지 모듈로 나뉜다.
logback-core는 다른 두 모듈을 위한 기반 역할을 한다. Appender와 Encoder(Layout) 인터페이스가 속한다.
logback-classic은 core에서 확장된 모듈로, core와 SLF4J API 라이브러리를 가진다. Logger 클래스가 여기에 속한다.
logback-access는 서블릿 컨테이너와 통합되어 HTTP 액세스에 대한 로깅 기능을 제공한다.

Logback을 이용하여 로깅을 수행하기 위해 필요한 주요 설정 요소로는 Logger, Appender, Encoder 3가지가 있다.

Logger

Logger는 실제 로깅을 수행하는 구성요소이다.
ch.pos.logback.classic.Level 클래스에 Logger가 사용 가능한 다섯 가지 레벨(TRACE, DEBUG, INFO, WARN, ERROR)이 정의되어 있다. Level을 통해 출력할 로그의 레벨을 조절할 수 있다. 각 Level은 TRACE < DEBUG < INFO < WARN < ERROR이며, 지정한 레벨보다 작은 레벨의 로그는 기록되지 않는다.

ERROR : 요청을 처리하는 중 오류가 발생한 경우 표시
WARN : 처리 가능한 문제, 향후 시스템 에러 원인이 될 수 있는 경고성 메시지 표시
INFO : 상태변경과 같은 정보성 로그 표시
DEBUG : 프로그램을 디버깅하기 위한 정보를 표시
TRACE : Debug보다 훨씬 상세한 정보를 표시

Appender

Appender는 로그 메시지가 출력될 대상을 결정하는 역할을 한다. Appender는 다음과 같은 종류가 있다.

ConsoleAppender : 콘솔에 로그 출력
FileAppender : 파일 단위로 로그 저장
RollingFileAppender : 설정 옵션에 따라 로그를 여러 파일로 나누어 저장
SMTPAppender : 로그를 메일로 전송하여 기록
DBAppender : 로그를 DB에 저장

Encoder

Encoder는 로그 이벤트를 바이트 배열로 변환하고, 해당 바이트 배열을 Output Stream에 쓰는 작업을 담당한다.
Appender에 포함되어 사용자가 지정한 형식으로 표현 될 로그 메시지를 변환하는 역할을 담당한다.

Spring-Boot Logback Settings

스프링에서 Logback 설정을 위해 logback-spring.xml을 작성할 수 있다.
logback.xml을 사용하게 되면 스프링 설정 전에 Logback 설정이 먼저 완료되어 로그 제어가 어려워질 수 있다.

Dynamic Reloading

dynamic reloading 기능을 지원한다.

<?xml version="1.0" encoding="UTF-8" ?>
<configuration scan="true" scanPeriod="60 seconds">
    <!-- 60초 주기로 파일을 검사하여 바뀌었으면 프로그램을 갱신한다. -->
    <!-- ...logback settings... -->
</configuration>

Appender 설정

<?xml version="1.0" encoding="UTF-8" ?>
<configuration scan="true" scanPeriod="60 seconds">

    <!-- appender 설정 -->
    <!-- ConsoleAppender -->
    <appender name="CONSOLE" class="ch.qos.logback.core.ConsoleAppender">
        <encoder>
            <!-- 로그 출력 패턴 설정 -->
            <pattern>
                %d{yyyy-MM-dd HH:mm:ss.SSS} %-5level ${PID:- } --- %logger: %-5line : %m%n
            </pattern>
        </encoder>
    </appender>

    <!-- FileAppender -->
    <appender name="FILE-INFO" class="ch.qos.logback.core.rolling.RollingFileAppender">
        <!-- 로그를 기록할 파일명과 경로 설정 -->
        <file>./log/info/info-%d{yyyy-MM-dd}.log</file>
        <encoder>
            <pattern>
                %d{yyyy-MM-dd HH:mm:ss.SSS} %-5level ${PID:- } --- %logger: %-5line : %m%n
            </pattern>
            <charset>UTF-8</charset>
            <!-- 헤더에 패턴 출력 -->
            <outputPatternAsHeader>true</outputPatternAsHeader>
        </encoder>

        <!-- 로그 필터링 설정 -->
        <filter class="ch.qos.logback.classic.filter.LevelFilter">
            <!-- INFO 레벨의 로그만 파일에 기록 -->
            <level>INFO</level>
            <onMatch>ACCEPT</onMatch>
            <onMismatch>DENY</onMismatch>
        </filter>

        <!-- Rolling 정책 결정 -->
        <rollingPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedRollingPolicy">
            <!-- 파일 쓰기가 종료된 log 파일명의 패턴 지정. '.gz', '.zip'과 같이 지정하면 자동 압축 -->
            <fileNamePattern>
                ./log/info/info-%d{yyyy-MM-dd}.%i.log
            </fileNamePattern>
            <!-- 파일당 최대 용량 -->
            <maxFileSize>10MB</maxFileSize>
            <!-- 로그파일 최대 보관 주기(일). 해당 설정일 이상 지나면 로그파일 자동 삭제 -->
            <maxHistory>30</maxHistory>
        </rollingPolicy>
    </appender>

 <!-- 설정한 appender 적용 -->
    <root level="info">
        <appender-ref ref="CONSOLE"/>
        <appender-ref ref="FILE-INFO"/>
    </root>

</configuration>

Property

property : 설정 파일에서 사용될 변수값을 선언한다.

<?xml version="1.0" encoding="UTF-8" ?>
<configuration>

    <!-- property 선언 -->
    <property name="LOG_PATTERN" value="%d{yyyy-MM-dd HH:mm:ss.SSS} %-5level ${PID:- } --- %logger: %-5line : %m%n"/>
    <property name="LOG_CHARSET" value="UTF-8"/>
    <property name="LOG_FILE_PATH" value="./log"/>
    <timestamp key="BY_DATE" datePattern="yyyy-MM-dd"/>

    <!-- appender 설정 -->
    <appender name="CONSOLE" class="ch.qos.logback.core.ConsoleAppender">
        <encoder>
            <!-- property 사용 -->
            <pattern>${LOG_PATTERN}</pattern>
            <charset>${LOG_CHARSET}</charset>
        </encoder>
    </appender>

    <appender name="FILE-INFO" class="ch.qos.logback.core.rolling.RollingFileAppender">
        <!-- property 사용 -->
        <file>${LOG_FILE_PATH}/info-${BY_DATE}.log</file>
        <encoder>
            <!-- property 사용 -->
            <pattern>${LOG_PATTERN}</pattern>
            <charset>${LOG_CHARSET}</charset>
            <outputPatternAsHeader>true</outputPatternAsHeader>
        </encoder>

        <filter class="ch.qos.logback.classic.filter.LevelFilter">
            <level>INFO</level>
            <onMatch>ACCEPT</onMatch>
            <onMismatch>DENY</onMismatch>
        </filter>

        <rollingPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedRollingPolicy">
            <!-- property 사용 -->
            <fileNamePattern>${LOG_FILE_PATH}/info-${BY_DATE}.%i.log</fileNamePattern>
            <maxFileSize>10MB</maxFileSize>
            <maxHistory>30</maxHistory>
        </rollingPolicy>
    </appender>


    <root level="info">
        <appender-ref ref="CONSOLE"/>
        <appender-ref ref="FILE-INFO"/>
    </root>

</configuration>

Logger 설정

root와 logger를 통해 설정할 수 있다.

root : 전역 설정. 지역 설정인 logger가 선언되면 해당 logger 설정이 default로 적용된다.
logger : 지역 설정. 특정 패키지의 logger를 설정할 수 있다.

<?xml version="1.0" encoding="UTF-8" ?>
<configuration>
    <!-- ...other settings... -->

    <!-- root level 설정 -->
    <root level="info">
    <appender-ref ref="CONSOLE"/>
    </root>

    <!-- 특정 패키지 logging level 설정 -->
    <!-- additivity 값은 root 설정 상속 유무를 결정하는 속성이다. default 값은 true -->
    <logger name="com.example.demo.service" level="debug" additivity="false">
        <appender-ref ref="CONSOLE"/>
        <appender-ref ref="FILE-INFO"/>
    </logger>

</configuration>

Profile별 설정 분리

srpingProfile을 통해 Profile별로 Logger, Appender 설정을 분리할 수 있다.

<?xml version="1.0" encoding="UTF-8" ?>
<configuration scan="true" scanPeriod="60 seconds">

    <!-- property 선언 -->
    <property name="LOG_PATTERN" value="%d{yyyy-MM-dd HH:mm:ss.SSS} %-5level ${PID:- } --- %logger: %-5line : %m%n"/>
    <property name="LOG_CHARSET" value="UTF-8"/>
    <property name="LOG_FILE_PATH" value="./log"/>
    <timestamp key="BY_DATE" datePattern="yyyy-MM-dd"/>

    <!-- 로컬 환경 logger settings -->
    <springProfile name="local">
        <appender name="CONSOLE" class="ch.qos.logback.core.ConsoleAppender">
            <encoder>
                <pattern>${LOG_PATTERN}</pattern>
                <charset>${LOG_CHARSET}</charset>
                <outputPatternAsHeader>true</outputPatternAsHeader>
            </encoder>
        </appender>

        <root level="info">
            <appender-ref ref="CONSOLE"/>
        </root>
    </springProfile>

    <!-- 운영 환경 logger settings -->
    <springProfile name="prod">
        <appender name="FILE" class="ch.qos.logback.core.rolling.RollingFileAppender">
            <file>${LOG_FILE_PATH}/info-${BY_DATE}.log</file>
            <encoder>
                <pattern>${LOG_PATTERN}</pattern>
                <charset>${LOG_CHARSET}</charset>
                <outputPatternAsHeader>true</outputPatternAsHeader>
            </encoder>
            <rollingPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedRollingPolicy">
                <!-- property 사용 -->
                <fileNamePattern>${LOG_FILE_PATH}/info-${BY_DATE}.%i.log</fileNamePattern>
                <maxFileSize>10MB</maxFileSize>
                <maxHistory>30</maxHistory>
            </rollingPolicy>
        </appender>

        <root level="info">
            <appender-ref ref="FILE"/>
        </root>
    </springProfile>

</configuration>

Logback 출력 로그 색상 변경

<conversionRule conversionWord="clr" converterClass="org.springframework.boot.logging.logback.ColorConverter" />
<!-- %clr(...){cyan} 과 같이 사용할 수 있다. %clr() 내부의 내용이 지정한 색상으로 출력된다. -->

<!-- 사용 예 -->
<property name="LOG_PATTERN" value="${CONSOLE_LOG_PATTERN:-%clr(%d{${LOG_DATEFORMAT_PATTERN:-yyyy-MM-dd HH:mm:ss.SSS}}){faint} %clr(${LOG_LEVEL_PATTERN:-%5p}) %clr(${PID:- }){magenta} %clr(---){faint} %clr([%15.15t]){faint} %clr(%-40.40logger{39}: %-5line){cyan} %clr(:){faint} %m%n${LOG_EXCEPTION_CONVERSION_WORD:-%wEx}}"/>

참고 사이트 : https://oingdaddy.tistory.com/257

[Github] Github Action 기초 및 Spring Boot CI/CD Workflow 구성하기

yoo97 — Sun, 22 Jan 2023 02:25:28 +0900

Github Action을 이용한 CI/CD 구축

Github Action

Github Action은 미리 정의된 특정 작업의 수행을 자동화할 수 있게 해주는 기능이다.
빌드/배포 워크플로를 자동화하거나, Pull Request 전 테스트를 자동으로 수행하여 테스트 통과시에만 PR을 open하도록 설정하거나, 특정 시간대에 크롤링 스크립트 등을 반복 수행하도록 하는 등, 여러 작업을 자동화 할 수 있다.

Github Action 구성 요소

Github Action을 구성하는 요소는 아래와 같다.

Workflow
- 가장 최상위에 위치한 개념으로, 모든 명령어의 집합을 말한다.
- 하나 이상의 Job으로 구성되어 있으며 특정 Event(Push, Pull Request)에 의해서 실행될 수도 있고 특정 시간대에 실행될 수도 있다.
- .github/workflows 디렉토리에 .yml 형태로 저장된다.
Event
- Workflow를 실행시키는 특정 행동을 의미한다.
- Push, Pull Request, Commit과 같은 Github 내의 특정 행동이나, Github 외부에서 발생한 이벤트 등이 될 수 있다.
- Github Action 공식 문서 참고
Job
- 동일한 Runner에서 실행되는 여러 Step의 집합을 말한다.
- 기본적으로 하나의 Workflow 내의 여러 Job은 독립적으로 실행된다. 독립적으로 실행된다는 말은 병렬로 실행된다는 의미이다.
- 필요에 따라 의존관계를 설정하여 Job들의 실행 순서를 지정해줄 수 있다. 이 경우, 의존하는 작업이 실패하면 이후의 작업들은 취소된다.
- 하나의 Job 내에서 각각의 Step은 다양한 Task로 인해 생성된 데이터를 공유할 수 있다.
Step
- Github Action에서 가장 작은 실행 단위로, 명령을 실행할 수 있는 각각의 Task를 의미한다.
- Step은 shell command가 될 수도 있고, 하나의 Action이 될 수도 있다.
Action
- Job을 구성하기 위해 여러 Step을 결합한 독립적인 command를 말한다.
- Github Action에서 재사용이 가능한 Workflow의 가장 작은 단위이다.
- 직접 만든 Action을 사용하거나 타인이 작성한 Action을 불러와 사용할 수 있으며, 자신이 작성한 Action을 다른 사람들에게 배포할 수도 있다.
Runner
- Job을 실행시키기 위한 애플리케이션을 말한다.
- Runner 애플리케이션은 Github에서 호스팅하는 가상 환경 또는 직접 호스팅하는 가상 환경에서 실행 가능하며, Github에서 호스팅하는 가상 인스턴스의 경우, 메모리 및 용량 제한이 존재한다.

참고 : Github Action의 실행 환경
Github Action은 가상기계 위에 도커 컨테이너를 띄워 수행된다. 따라서 가상기계의 실행 환경과 도커 컨테이너로 띄울 실행 환경을 명시해야 한다. 이때, 가상기계의 실행 환경은 필수로 지정해야 하며, 컨테이너로 띄울 도커 이미지는 선택사항이다.
컨테이너로 띄울 도커 이미지는 여러개가 주어질 수 있다. 도커 이미지를 여러개 선택하게 되면, 선택한 이미지를 띄운 컨테이너들을 생성하고, 각 컨테이너에서 동일한 작업을 수행하게 된다. 이를 이용하면 서로 다른 운영체제에서 작업을 실행시킬 수 있다.

CI/CD Workflow 구성하기

먼저 Github Repository에서 Actions 탭을 선택하여 Github Action을 구성할 수 있는 페이지로 들어간다.

이후, 상단의 set up a workflow yourself를 클릭하여 Workflow를 구성할 수 있는 페이지로 접근한다. 그러면 Workflow를 작성할 수 있는 에디터가 보이는데, 여기에 구성할 Workflow의 내용을 작성하면 된다.

아래와 같이 SpringBoot 애플리케이션의 CI/CD Workflow를 구성한 내용을 작성했다.
Workflow 파일의 각 위치에 설명을 달아뒀다. #은 해당 코드가 의미하는 바를, ###은 해당 Step이 어떤 작업을 하는지에 대한 설명이다.

# Workflow name
name: ComeOn App Dev CI/CD
# Event Trigger
on:
  push:
    branches: [ "dev" ]
# 현재 Workflow를 구성하는 Job들을 정의
jobs:
  # 하나의 Job에 대한 식별자를 설정. test_and_build는 하나의 Job이 된다.
  test_and_build:
    # 실행환경 설정
    runs-on: ubuntu-latest
    # 현재 Job을 구성하는 Step들을 정의
    steps:
    # `-`으로 Step을 구분한다. name은 Step의 식별자를 정의한다.
    - name: Checkout
      # Action을 사용하여 Step을 구성한다.
      uses: actions/checkout@v3
      # Action에 사용될 변수값 지정
      with:
        # repo settings에서 설정한 secrets 값을 사용한다.
        token: ${{ secrets.ACCESS_TOKEN }}
        submodules: true
    ### runner application java 설정
    - name: Set up JDK 11
      uses: actions/setup-java@v3
      with:
        java-version: '11'
        distribution: 'temurin'
    ### gradlew 실행 권한 부여
    - name: Grant execute permisstion for gradlew
      # shell 명령어로 Step의 Task를 지정한다.
      run: chmod +x gradlew
    ### project test
    - name: Test
      run: ./gradlew clean test -Pprofile=test
    ### project build
    - name: Build
      run: ./gradlew bootJar
    ### 도커 buildx 설정
    - name: Setup Docker Buildx
      uses: docker/setup-buildx-action@v2.2.1
    ### 도커 이미지 build & push
    - name: Docker Image build and push
      # 다음과 같이 작성하여 한 Task에서 여러 shell 명령을 수행하게 할 수 있다.
      run: |
        docker login --username=${{ secrets.DOCKERHUB_USERNAME }} --password=${{ secrets.DOCKERHUB_PASSWORD }}
        docker buildx build --platform linux/arm64/v8,linux/amd64 --tag ${{ secrets.DOCKERHUB_USERNAME }}/image-name:latest --push .

  # 하나의 Job에 대한 식별자를 설정. deploy는 하나의 Job이 된다.
  deploy:
    # 현재 Job의 의존관계 설정. test_and_build 식별자를 갖는 Job이 성공해야 현재 Job이 수행된다.
    needs: test_and_build
    runs-on: ubuntu-latest
    steps:
      ### ssh로 배포 서버에 접근하여 도커 이미지 pull & run
      - name: Docker image pull and run
        uses: appleboy/ssh-action@v0.1.7
        with:
          host: ${{ secrets.HOST }}
          username: ${{ secrets.USERNAME }}
          key: ${{ secrets.PRIVATE_KEY }}
          port: ${{ secrets.PORT }}
          script: |
            docker compose down
            docker image rm ${{ secrets.DOCKERHUB_USERNAME }}/image-name
            docker compose up -d --no-recreate

중간중간 ${{ secrets.XXXX }}와 같은 형식으로 작성된 부분이 보이는데, 이는 민감한 정보를 Secrets 변수로 등록하여 사용하는 방법이다. 이를 이용하면 비밀번호나 엑세스 토큰과 같은 민감한 정보들을 다른 사람들에게 노출하지 않고 안전하게 사용할 수 있다.

Secrets 변수를 등록하는 방법은 간단하다.
프로젝트 Repository의 Settings 탭으로 접근하여, 왼쪽 네비게이션의 Secrets and variables -> Actions 버튼을 클릭한다.
페이지가 전환되면 우측의 New repository secret 버튼을 클릭해서 원하는 변수의 이름과 변수 호출시 사용할 값을 입력하고 Add secret 버튼을 눌러 등록하면 된다.
이렇게 등록된 Secrets 변수는 Github Action에서 사용시 ${{ secrets.variable-name }}와 같은 형태로 사용하면 된다.
Secrets 변수는 사용시에는 정확한 값이 사용되지만, Workflow의 로그에서는 변수 이름으로 출력되어 로그에 해당 값을 노출시키지 않는다.

[Docker] MySQL 컨테이너 띄우고 원격 접속 허용하기

yoo97 — Sun, 15 Jan 2023 00:47:59 +0900

MySQL 컨테이너 띄우고 원격 접속 허용하기

docker-compose 파일 작성

docker-compose 를 통해 MySQL 컨테이너를 띄우기 위한 파일을 작성한다.

version: '3.8'
volumes:
        [volume-name]:
                external: true
                name: [volume-name]
services:
        [service-name]:
                container_name: [container-name]
                image: mysql
                ports:
                        - "3306:3306"
                volumes:
                        - [volume-name]:/var/lib/mysql
                env_file: .env
                environment:
                        - TZ=Asia/Seoul
                restart: always
                command:
                        - --character-set-server=utf8mb4
                        - --collation-server=utf8mb4_unicode_ci
                        - --character-set-client-handshake=FALSE

환경변수 파일 작성

환경변수를 분리한 .env 파일을 작성한다.

MYSQL_HOST=localhost
MYSQL_PORT=3306
MYSQL_ROOT_PASSWORD=[root-password 입력]

MYSQL_USER=[생성할 유저명 입력]
MYSQL_PASSWORD=[생성할 유저 패스워드 입력]

컨테이너 띄우고 MySQL 접속

docker compose 명령어를 통해 MySQL 컨테이너를 띄운다.

$ docker compose up -d

아래 명령을 통해 컨테이너에 접속한다.

$ docker exec -it [container-name] bin/bash

아래 명령을 통해 MySQL에 접속한다.

$ mysql -u root -p

Database 생성

mysql> show databases;
+------------------------+
| Database               |
+------------------------+
| information_schema     |
| mysql                  |
| performance_schema     |
| sys                    |
+------------------------+
5 rows in set (0.01 sec)

mysql> create database testdb;
Query OK, 1 row affected (0.01 sec)

mysql> show databases;
+------------------------+
| Database               |
+------------------------+
| testdb                 |
| information_schema     |
| mysql                  |
| performance_schema     |
| sys                    |
+------------------------+
5 rows in set (0.01 sec)

유저 생성 및 데이터베이스 권한 부여

mysql> use mysql
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Database changed

mysql> select host, user from user;
+-----------+------------------+
| host      | user             |
+-----------+------------------+
| %         | root             |
| localhost | mysql.infoschema |
| localhost | mysql.session    |
| localhost | mysql.sys        |
| localhost | root             |
+-----------+------------------+
5 rows in set (0.01 sec)

mysql> create user 'test_user'@'%' identified by 'password1111';
Query OK, 0 rows affected (0.02 sec)

mysql> select host, user from user;
+-----------+------------------+
| host      | user             |
+-----------+------------------+
| %         | test_user        |
| %         | root             |
| localhost | mysql.infoschema |
| localhost | mysql.session    |
| localhost | mysql.sys        |
| localhost | root             |
+-----------+------------------+
6 rows in set (0.00 sec)

mysql>  flush privileges;
Query OK, 0 rows affected (0.01 sec)

mysql> show grants for 'test_user'@'%';
+----------------------------------------------+
| Grants for test_user@%                       |
+----------------------------------------------+
| GRANT USAGE ON *.* TO `test_user`@`%`        |
+----------------------------------------------+
1 row in set (0.01 sec)

mysql> grant all privileges on testdb.* to test_user@'%';
Query OK, 0 rows affected (0.03 sec)

mysql> show grants for 'test_user'@'%';
+------------------------------------------------------------------------------+
| Grants for test_user@%                                                       |
+------------------------------------------------------------------------------+
| GRANT USAGE ON *.* TO `test_user`@`%`                                        |
| GRANT ALL PRIVILEGES ON `testdb`.* TO `test_user`@`%`                        |
+------------------------------------------------------------------------------+
2 rows in set (0.00 sec)

이제 “test_user”로 “testdb” 데이터베이스에 원격 접속이 가능하다.

참고
DBeaver에 데이터베이스 연결을 생성할 때, Dirver properties에 다음과 같이 옵션을 선택해야 한다.
autoReconnect=true
useSSL=false
allowPublicKeyRetrieval=true

[Spring] Spring REST Docs, Swagger 조합. restdocs-api-spec

yoo97 — Sun, 8 Jan 2023 20:30:15 +0900

Spring REST Docs + Swagger

Swagger, Spring REST Docs 간단한 설명

자바로 API를 개발하게 되면 일반적으로 Spring REST Docs와 Swagger 중 하나를 사용하여 API 문서화를 진행하게 된다.
Spring Rest Docs와 Swagger의 특징은 아래와 같다.

[Swagger]

API 테스트가 가능하다.
API 문서 생성이 자동으로 이루어진다.
프로덕션 코드에 Swagger 문서화를 위한 어노테이션이 추가된다.

[Spring REST Docs]

테스트 코드 작성을 강제하여 API 문서가 신뢰성이 있다.
테스트 성공 이후 생성된 스니펫으로 직접 문서를 작성해야 한다.
API 테스트 불가.

프로덕션 코드에 API 문서 관련 코드가 추가되면 컨트롤러 단이 상당히 지저분해질 것 같아서 Spring REST Docs를 자주 사용했다.
하지만 테스트 코드 변경시마다 직접 문서를 수정하는 과정이 반복되다 보니 불편함을 느껴서 방법을 찾아보게 되었고 restdocs-api-spec 라이브러리를 알게 되었다.

restdocs-api-spec

restdocs-api-spec 라이브러리를 사용하면 Spring REST Docs와 같이 테스트 코드가 통과하면 OpenAPI 스펙을 얻게되고, Swagger-UI를 통해 OpenAPI 스펙을 문서로 띄우고 테스트할 수 있는 환경을 제공할 수 있다.

이 포스팅은 Spring REST Docs와 Swagger의 장점을 동시에 누릴 수 있도록 restdocs-api-spec 라이브러리를 사용하여 문서를 작성하는 방법을 기록한다.

restdocs-api-spec 깃허브 바로가기

적용 방법

작성한 모든 코드는 필자의 깃허브에서 확인할 수 있다.

build.gradle 설정

restdocs-api-spec 라이브러리를 사용하기 위해 build.gradle에 의존성을 추가한다.

// restdocs-api-spec: version 변수 설정
buildscript {
    ext {
        restdocsApiSpecVersion = '0.16.2'
    }
}

plugins {
    id 'java'
    id 'org.springframework.boot' version '2.7.7'
    id 'io.spring.dependency-management' version '1.0.15.RELEASE'
    // restdocs-api-spec: plugin 추가
    id 'com.epages.restdocs-api-spec' version "${restdocsApiSpecVersion}"
}

group = 'com.example'
version = '0.0.1-SNAPSHOT'
sourceCompatibility = '11'

configurations {
    compileOnly {
        extendsFrom annotationProcessor
    }
}

repositories {
    mavenCentral()
}

// restdocs-api-spec: OpenAPI 스펙 생성 설정 명시
openapi3 {
    server = "http://localhost:8081"
    title = "restdocs-swagger Test API Documentation"
    description = "Spring REST Docs with SwaggerUI"
    version = "0.0.1-SNAPSHOT"
    format = "json"
    outputDirectory = "src/main/resources/static"
    outputFileNamePrefix = "swagger"
}

dependencies {
    implementation 'org.springframework.boot:spring-boot-starter-validation'
    implementation 'org.springframework.boot:spring-boot-starter-data-jpa'
    implementation 'org.springframework.boot:spring-boot-starter-web'

    compileOnly 'org.projectlombok:lombok'
    runtimeOnly 'com.h2database:h2'
    annotationProcessor 'org.projectlombok:lombok'

    testImplementation 'org.springframework.boot:spring-boot-starter-test'
    // restdocs-api-spec: restdocs-api-spec-mockmvc 의존성 추가
    testImplementation "com.epages:restdocs-api-spec-mockmvc:${restdocsApiSpecVersion}"
}

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

openapi3 테스크에서 생성될 OpenAPI 스펙 관련 설정을 추가하는 것을 확인할 수 있다.
관련 설정은 여기에서 확인할 수 있다.

프로젝트 생성시 Spring REST Docs 의존성을 추가하여 생성했다면 asciidoctor 관련 설정이 적용되어 있을 텐데, restdocs-api-spec 라이브러리를 사용하게 되면 해당 설정이 필요없다. asciidoctor 관련 설정을 지운다.

’org.springframework.restdocs:spring-restdocs-mockmvc’ 의존성도 필요없다. restdocs-api-spec-mockmvc 라이브러리가 restdocs의 기능을 지원한다.

API 작성

다음으로 API를 작성한다.
예제를 위해 간단하게 다음과 같이 작성했다.

@Slf4j
@RestController
@RequiredArgsConstructor
@RequestMapping("/api/v1/users")
public class UserController {
    private final UserService userService;

    @PostMapping
    public ApiResponse<UserAddResponse> userAdd(@Validated @RequestBody UserAddRequest request, BindingResult bindingResult) {
        // 요청 데이터 검증 실패시 ControllerAdvice가 Catch -> Exception Controll 함.
        if (bindingResult.hasErrors()) {
            throw new ValidationException(bindingResult);
        }

        Long userId = userService.saveUser(
                new User(
                        request.getName(),
                        request.getAge(),
                        request.getGender()
                )
        );

        return ApiResponse.createSuccess(new UserAddResponse(userId));
    }
}

// 공통 응답 Spec
@Data
@Builder
@AllArgsConstructor(access = AccessLevel.PROTECTED)
public class ApiResponse<T> {
    private LocalDateTime responseTime;
    private String errorMessage;
    private T data;

    public static <T> ApiResponse<T> createSuccess(T data) {
        return ApiResponse.<T>builder()
                .responseTime(LocalDateTime.now())
                .data(data)
                .build();
    }

    public static ApiResponse<?> createError(String errorMessage) {
        return ApiResponse.builder()
                .responseTime(LocalDateTime.now())
                .errorMessage(errorMessage)
                .build();
    }

    // 요청 데이터 검증 실패시 data 필드에 MultiValueMap으로 필드 오류 메시지 넣음
    public static <T> ApiResponse<T> createValidationError(T data) {
        return ApiResponse.<T>builder()
                .responseTime(LocalDateTime.now())
                .errorMessage("요청 데이터 검증 오류 발생")
                .data(data)
                .build();
    }
}

// 요청 성공시 ApiResponse.data에 들어갈 응답 데이터
@Data
@AllArgsConstructor
public class UserAddResponse {
    private Long userId;
}

// 요청 Body 데이터
@Data
@AllArgsConstructor
public class UserAddRequest {
    @NotBlank
    private String name;

    @Range(min = 19, max = 30)
    private int age;

    private Gender gender;
}

이제 테스트 코드를 작성하자.

테스트 코드 작성

@SpringBootTest
@AutoConfigureMockMvc
@AutoConfigureRestDocs //
@ExtendWith(RestDocumentationExtension.class) //
public class UserControllerTest {
    @Autowired
    MockMvc mockMvc;

    @Autowired
    ObjectMapper objectMapper;

    // 요청 성공시 공통 응답 Spec 부분 추출
    FieldDescriptor[] successResponseFields = {PayloadDocumentation.fieldWithPath("responseTime").type(JsonFieldType.STRING).description("응답 시간"),
            PayloadDocumentation.subsectionWithPath("errorMessage").type(JsonFieldType.STRING).description("오류 메시지").optional(),
            PayloadDocumentation.subsectionWithPath("data").type(JsonFieldType.OBJECT).description("응답 데이터").optional()};

    // 요청 데이터 검증 실패시 공통 응답 Spec 부분 추출
    FieldDescriptor[] validFailResponseFields = {PayloadDocumentation.fieldWithPath("responseTime").type(JsonFieldType.STRING).description("응답 시간"),
            PayloadDocumentation.subsectionWithPath("errorMessage").type(JsonFieldType.STRING).description("오류 메시지"),
            PayloadDocumentation.subsectionWithPath("data").type(JsonFieldType.OBJECT).description("오류 필드")};

    @Nested
    @DisplayName("유저 생성")
    class userAdd {

        @Test
        @DisplayName("유저 생성 성공")
        public void success() throws Exception {
            // given
            UserAddRequest userAddRequest = new UserAddRequest("user1", 25, Gender.MEN);

            // when
            ResultActions perform = mockMvc.perform(
                    RestDocumentationRequestBuilders.post("/api/v1/users")
                            .contentType(MediaType.APPLICATION_JSON)
                            .characterEncoding(StandardCharsets.UTF_8)
                            .content(objectMapper.writeValueAsString(userAddRequest))
            );

            // then
            perform.andExpect(MockMvcResultMatchers.status().isOk())
                    .andExpect(MockMvcResultMatchers.jsonPath("$.data.userId").isNotEmpty());

            // docs
            perform.andDo(
                    MockMvcRestDocumentationWrapper.document(
                            "{class-name}/{method-name}",
                            Preprocessors.preprocessRequest(Preprocessors.prettyPrint()),
                            Preprocessors.preprocessResponse(Preprocessors.prettyPrint()),
                            ResourceDocumentation.resource(
                                    ResourceSnippetParameters.builder()
                                            .description("유저 생성")
                                            .requestFields(
                                                    PayloadDocumentation.fieldWithPath("name").description("이름"),
                                                    PayloadDocumentation.fieldWithPath("age").description("나이"),
                                                    PayloadDocumentation.fieldWithPath("gender").description("성별")
                                            )
                                            .responseFields(
                                                    new FieldDescriptors(successResponseFields).and(
                                                            PayloadDocumentation.fieldWithPath("data.userId").description("생성된 유저 식별값")
                                                    )
                                            )
                                            .build()
                            )
                    )
            );
        }

        @Test
        @DisplayName("요청 데이터 검증 실패")
        public void validFail() throws Exception {
            // given
            UserAddRequest userAddRequest = new UserAddRequest(null, 10, null);

            // when
            ResultActions perform = mockMvc.perform(
                    RestDocumentationRequestBuilders.post("/api/v1/users")
                            .contentType(MediaType.APPLICATION_JSON)
                            .characterEncoding(StandardCharsets.UTF_8)
                            .content(objectMapper.writeValueAsString(userAddRequest))
            );

            // then
            perform.andExpect(MockMvcResultMatchers.status().isBadRequest());

            // docs
            perform.andDo(
                    MockMvcRestDocumentationWrapper.document(
                            "{class-name}/{method-name}",
                            Preprocessors.preprocessRequest(Preprocessors.prettyPrint()),
                            Preprocessors.preprocessResponse(Preprocessors.prettyPrint()),
                            ResourceDocumentation.resource(
                                    ResourceSnippetParameters.builder()
                                            .responseFields(
                                                    new FieldDescriptors(validFailResponseFields).and(
                                                            PayloadDocumentation.subsectionWithPath("data.name").description("name 필드 검증 오류 메시지 리스트").optional(),
                                                            PayloadDocumentation.subsectionWithPath("data.age").description("age 필드 검증 오류 메시지 리스트").optional()
                                                    )
                                            )
                                            .build()
                            )
                    )
            );
        }
    }
}

기본적으로 Spring REST Docs 사용법과 같다.
주의할 점은 docs 작성 시에 MockMvcRestDocumentationWrapper.document()를 사용해야 한다는 점이다.

또한 @AutoConfigureRestDocs 어노테이션이 필요하다.
기존에 Spring REST Docs를 사용할 때에는 해당 어노테이션이 없어도 MockMvc에 커스터마이징한 설정을 넣어서 사용했다.
내가 방법을 못찾은 것일 수도 있지만.. 이번 시도에서는 커스터마이징이 어려웠다.

한 가지 주의할 점이 또 있다.
이 역시 Spring REST Docs를 사용할 때에는 PayloadDocumentation.beneathPath()를 통해 응답의 특정 필드부터만 문서 작성을 명시해도 테스트가 통과되었다.
이 때에는 @AutoConfigureRestDocs 어노테이션을 사용하지 않았고 직접 설정을 추가했었는데, restdocs-api-spec 라이브러리를 사용할 때에는 @AutoConfigureRestDocs 어노테이션 때문인지 몰라도, beneathPath()를 사용하면 테스트가 실패했다(스니펫은 정상적으로 생성된다).
이 때문에 공통 API 스펙같은 경우 따로 추출하여 FieldDescriptors(...)로 묶어주고, 추가로 FieldDescriptor가 필요한 경우, FieldDescriptors.and(...) API를 통해 붙여주었다.

Open API Spec 생성

테스트 코드 작성이 완료되고 테스트를 수행하여 통과되면 /build/generated-snippets/ 아래에 .adoc 파일과 resource.json 파일이 생성되었을 것이다.

이제 gradle의 openapi3 태스크를 수행하면 .adoc 스니펫 파일들과 resource.json 파일을 이용해서 Open API 스펙을 생성한다.
./gradlew openapi3 명령을 입력하거나 인텔리제이 기준 Gradle 탭을 열어 Tasks/documentation/openapi3 태스크를 수행하자.

태스크 수행이 성공적으로 완료되면, build.gradle에서 openapi3 태스크 설정시 지정한 outputDirectory 경로에 {outputFileNamePrefix}.{format}으로 Open API 스펙이 생성된다.
따로 지정하지 않았다면 디폴트 값인 build/api-spec/openapi3.json으로 생성된다.

Swagger-UI로 Open API Spec 띄우기

프로젝트에서 Swagger-UI 의존성을 추가하여 Swagger 페이지를 생성할 수도 있지만, 별도 Swagger-UI 서버를 띄워 여기에 Open API 스펙들을 모아서 관리하도록 하였다.
요즘 MSA 프로젝트를 많이 구성하는데 여러 서버의 문서를 한 곳에서 모아서 보고 싶었기 때문이다.

Swagger-UI 서버를 띄우기 위해 Docker Compose를 이용했다.

# swaggerui-docker-compose.yml
version: "3"
services:
  swagger:
    container_name: local-swagger
    image: swaggerapi/swagger-ui
    ports:
      - "8080:8080"
    env_file:
      - .env

컨테이너에 필요한 환경변수를 별도 파일로 작성했다.

// .env
URLS=[{url:'http://localhost:8081/swagger.json',name:'Test'},]

URLS에 {url:'url1',name:'name1'} 형식으로 [] 내부에 값을 집어넣으면 Swagger-UI에서 name 값을 선택하면 해당 name에 매핑된 url을 불러온다. 따라서 name에 특정 서버의 문서 이름을 기입하고 url에 해당 서버의 Open API Spec을 불러올 경로를 입력하면, Swagger-UI를 통해 여러 서버의 Open API Spec들을 편리하게 확인할 수 있다.

이제 우리가 작성한 애플리케이션 서버를 띄우고, Swagger-UI 서버 컨테이너를 실행해서 확인해보자.

구동에 성공했다.

Swagger-UI에 접속해서 애플리케이션 서버의 Open API Spec을 불러오는데 Fetch error가 발생한다면?
Failed to fetch http://localhost:8081/swagger.json**Fetch error**
Possible cross-origin (CORS) issue? The URL origin (http://localhost:8081) does not match the page (http://localhost:8080). Check the server returns the correct ‘Access-Control-Allow-*’ headers.

Open API Spec을 불러올 서버에 CORS 설정이 필요하다. CORS 설정을 추가해주자.

고찰

restdocs-api-spec 라이브러리가 아직 완벽하게 Spring REST Docs를 지원하지는 못하는 것 같다.
MultiValueMap 같은 경우 <String, String> 타입인데, Map의 value 타입을 String으로 명시하고 테스트를 수행하니 테스트가 실패한다.
타입 명시를 지우고 테스트를 성공시킨 후, resource.json을 확인해보니 Array 타입으로 명시되어있다. MultiValueMap<String, String>의 특정 키의 value[0]은 String 타입인데 말이다..

또한 Swagger-UI에서 이를 확인하면 아래와 같이 출력된다.

API를 테스트 할 수 있다는 점은 협업하는 입장에서 매우 좋은 것 같다.
하지만 API 필드 타입과 설명을 명시하는 부분에서는 Spring REST Docs만을 사용해서 직접 문서로 만드는 것이 더 확실하게 명시할 수 있는 것 같다(내 개인적인 생각이다).

어쨋든 Spring으로 API 문서를 작성할 때 Swagger, Spring REST Docs 2개의 선택지에서 restdocs-api-spec라는 선택지가 하나 더 생기게 되었다.
협업하는 팀원들간에 상의를 해보고 더 적절한 것을 선택하면 좋을 것 같다.

[Git] 깃 서브모듈(Submodule)

yoo97 — Sat, 7 Jan 2023 11:57:08 +0900

Submodule

Git Submodule은 하나의 저장소(부모)에 다른 저장소(자식)를 두고 관리하기 위한 도구로, 하나의 프로젝트에서 다른 프로젝트를 함께 사용해야 하는 경우에 많이 사용한다.

나는 프로젝트는 public repo로 관리하고, 애플리케이션의 중요한 정보들이 담기는 .yml, .properties는 private repo에 따로 관리하고 싶어서 이를 적용했다.

간단해보였지만 의외로 주의해야 할 점이 많아서 기록해두려 한다.

프로젝트에 Submodule 적용하기

1. Public, Private Repository 생성

먼저 Public Repository 하나와 Private Repository 하나를 생성한다.

Public Repository에는 프로젝트를, Private Repository에는 프로젝트에서 숨겨야하는 중요한 설정 파일들(application.yml 등)을 넣는다.

이 때, Private Repository에서 관리할 파일들은 Public Repository에서 제거해준다.

2. Public Repository에 Submodule 등록

Public Repository에 다음과 같이 서브 모듈을 등록해준다.

$ git submodule add [submodule로 등록할 repo 주소] [submodule 디렉토리를 둘 경로]
Cloning into ...
remote: Enumerating objects: 11, done.
remote: Counting objects: 100% (11/11), done.
remote: Compressing objects: 100% (11/11), done.
remote: Total 11 (delta 0), reused 11 (delta 0), pack-reused 0
Receiving objects: 100% (11/11), done.

정상적으로 등록이 완료되면 서브 모듈을 등록한 repository 최상위에 .gitmodules 파일이 생성되고, 지정한 경로에 submodule repository 디렉토리가 생성된다.

.gitmodules 파일 내부는 다음과 같다.

$ cat .gitmodules
[submodule "submodule 디렉토리 경로"]
    path = submodule 디렉토리 경로
    url = submodule git repository 주소

3. Public Repository Push

submodule 등록을 완료하였으면 이를 commit/push 해야 리모트에 반영된다. Public Repository를 push 하자.

push 한 뒤에 깃허브를 확인해보면 config @ 102f51b와 같이 디렉토리 이름 뒤에 @ commit-id가 붙어있고, 링크로 표시되는 것을 확인할 수 있다.
해당 링크로 접근하면 submodule로 등록된 repository에 접근할 수 있는데, 해당 submodule repository가 private이라면 권한이 없는 유저는 접근할 수 없다.

여기서 표시되는 commit-id는 해당 repository가 참조하는 submodule repository의 commit-id이다.

Submodule이 적용된 프로젝트 clone 하기

처음 submodule이 적용된 프로젝트를 clone 하면, submodule 내부의 파일이 존재하지 않는다.
터미널에서 다음 명령을 통해 submodule을 초기화하고 업데이트한다.

# submodule 초기화
$ git submodule init
Submodule '프로젝트에 적용된 submodule path' (submodule repository url) registered for path '프로젝트에 적용된 submodule path'

# submodule 업데이트
$ git submodule update
Cloning into 'local project의 submodule path'...
Submodule path 'project submodule path': checked out 'submodule commit-id'

submodule이 적용된 프로젝트를 처음 clone 할 때 submodule까지 한번에 clone 할 수 있다. 다음 명령을 이용한다.
$ git clone --recurse-submodules [main-project-url]

update된 submodule repository를 main repository로 가져오기

submodule repository가 업데이트 되었는데 메인 프로젝트 repository에 아직 반영이 안되었을 경우, submodule repository의 변경 사항을 가져와서 작업해야 하는 경우에는 다음 명령을 이용할 수 있다.

$ git submodule update --remote --merge

--remote 옵션은 .gitmodules 파일에 정의되어 있는 브랜치의 최신 버전으로 업데이트한다.
--merge 옵션은 로컬에서 작업 중인 부분과 원격에 작업된 부분이 다르면, merge까지 진행해준다.

위 명령을 수행하고 나면 메인 프로젝트에 submodule repository의 변경 사항이 적용되었다.
메인 프로젝트 commit/push 시점에 해당 변경 사항을 함께 commit/push 해주면 된다.
로컬에 업데이트한 submodule의 변경 사항을 commit/push 해주지 않으면 remote에는 변경 사항이 적용되지 않은 이전 커밋의 submodule을 참조하고 있을 것이다..

로컬의 submodule repository 변경 내역을 commit/push 하기

submodule repository의 파일에 변경 사항을 커밋하고 싶다면, 먼저 메인 프로젝트에 등록된 submodule repository 디렉토리로 이동한다.

메인 프로젝트에서 해당 디렉토리로 이동하면, 메인 프로젝트가 참조하고 있는 submodule repository의 commit으로 체크아웃 될 것이다.

아래와 같이, 변경 내역을 commit/push 할 submodule repository의 branch로 checkout하고, add, commit, push 한다.

# project submodule path로 이동
~/project $ cd [project submodule path]

# main project가 참조하고 있는 submodule의 commit으로 체크아웃 됨.
# commit/push 할 branch로 checkout
~/project/submodule-path[➦ commit-id] $ git checkout main

# add, commit, push 수행하면 된다.
~/project/submodule-path[ main] $

submodule repository를 업데이트하고 나면, 메인 프로젝트의 submodule이 참조하고 있는 submodule repository의 commit을 업데이트 해줘야 한다.
메인 프로젝트에서 git submodule update 명령을 통해 submodule이 참조하는 commit을 업데이트 해주자.

submodule repository에 새로운 변경 내역을 업데이트 했지만, 메인 프로젝트에서 git submodule update 명령을 수행하지 않으면, 메인 프로젝트는 여전히 변경 내역이 적용되지 않은 이전 커밋의 버전을 참조한다.
메인 프로젝트에서도 변경 사항을 적용하고 싶다면 꼭 submodule을 업데이트 해주자.

Jenkins 같은 CI/CD 툴을 이용할 때 서브 모듈에 있는 파일이 필요할 수도 있다. 이 경우 서브 모듈에 접근할 수 있는 권한을 줘야한다. (ex: Jenkins의 경우 credentials를 추가해주면 간단하게 해결된다.)

[Spring] Web-Socket, SockJS, STOMP 이론

yoo97 — Fri, 6 Jan 2023 13:56:17 +0900

WebSocket, SockJS, STOMP 소개

WebSocket

WebSocket은 기존의 단방향 HTTP 프로토콜과 호환되어 양방향 통신을 제공하기 위해 개발된 프로토콜이다.

웹 소켓은 HTTP를 사용하는 네트워크 데이터 통신의 단점을 보완하는데 그 목적이 있다.
웹 소켓을 설명하기 이전에, 웹 소켓의 등장 이전에는 HTTP 통신의 단점을 어떻게 해결하려고 했는지 알아보겠다.

WebSocket 등장 이전

모든 HTTP를 사용한 통신은 클라이언트가 먼저 요청을 보내고, 그 요청에 따라 웹 서버가 응답하는 형태이며 웹 서버는 응답을 보낸 후 웹 브라우저와의 연결을 끊는다.
이러한 통신 방식을 반이중 통신(Half Duplex)라고 한다.

실시간 검색어와 같이 서버에서 제공하는 데이터를 항상 최신으로 유지하고 싶다고 하자.
반이중 통식 방식을 지원하는 기존 HTTP 통신으로는 어떻게 해결할 수 있었을까?

Polling
클라이언트가 일반적인 HTTP 요청을 주기적으로 보내서 변경된 데이터를 확인하는 방식을 Polling이라고 한다.
가장 간단하고 쉬운 방식이지만 클라이언트가 주기적으로 요청을 보내기 때문에 클라이언트의 수가 많아지면 서버의 부담이 많아지게 된다. HTTP 커넥션을 맺고 끊는 것 또한 리소스를 많이 잡아먹는다는 문제가 있었다.

Polling의 문제를 해결하기 위해 Long-Polling이 등장한다.

Long-Polling
Long-Polling은 클라이언트에서 서버로 일단 HTTP 요청을 보내고, 서버는 요청을 받은 상태를 유지하다가 클라이언트가 원하는 이벤트가 서버에 발생하면 그 때 응답 메시지를 보낸다. 응답을 받은 클라이언트는 다시 서버로 요청을 보내 다음 이벤트를 기다리게 된다.
Polling 방식보다는 서버의 부담이 줄지만, 이 방식 역시 클라이언트로 보내는 이벤트의 발생 주기가 짧다면 Polling 방식과 별반 다를게 없다. 또한 동시에 여러 이벤트가 발생하게 되어 다수의 클라이언트에게 보내야 할 경우, 서버의 부담이 급증하게 된다는 문제가 있다.

이 때, SSE가 등장한다.

SSE(Server-Sent Event)
클라이언트가 서버로 HTTP 요청을 보내면 서버는 이벤트에 대한 응답을 할 때 이 HTTP 요청에 대한 연결을 끊지 않고 계속 유지한다. 이렇게 되면 서버는 이벤트가 발생하여 변경이 필요한 데이터만 계속 응답하면 된다. 이러한 방법을 SSE라고 한다.
클라이언트는 한 번만 요청을 보내놓으면 커넥션이 끊기지 않는 한 계속해서 변경된 데이터를 받을 수 있고, 서버 입장에서도 이벤트가 발생할 때 마다 HTTP 커넥션을 생성하지 않아도 되어 부담이 줄어들게 된다.

Polling, Long-Polling, SSE와 같은 방식은 실시간으로 변경된 데이터를 전달받을 수 있지만, 여전히 서버에서 클라이언트 방향으로, 단방향으로 데이터를 전송한다.
실시간 검색어나 주식, 날씨 정보와 같은 데이터는 양방향 통신이 필요없다. 서버의 데이터가 변동되면 단방향으로 데이터를 전달받으면 된다.

하지만 채팅의 경우에는 어떤가?
상대에게 실시간으로 메시지를 전송해야 하고, 상대의 메시지를 실시간으로 전달받아야 한다. 즉, 양방향 통신이 필요하다.
이렇게 서버를 통해 여러 클라이언트가 실시간으로 데이터를 주고 받기 위해 WebSocket 기술이 등장하게 된 것이다.

웹 소켓

위에서 언급했듯이, WebSocket은 기존의 단방향 HTTP 프로토콜과 호환되어 양방향 통신을 제공하기 위해 개발된 프로토콜로, 서버와 클라이언트 사이에 Socket 커넥션을 유지하면서 양방향 통신을 가능하게 하는 기술이다.

웹 소켓의 동작 과정은 다음과 같다.

클라이언트가 HTTP 프로토콜로 Handshake 요청을 한다.
이에 대해 서버는 HTTP 상태 코드 101을 응답해준다. 이때 HTTP Upgrade 헤더를 사용하여 웹 소켓 프로토콜로 변경할 수 있도록 명시한다.
이후 통신 프로토콜을 WebSocket 프로토콜로 변환하여 데이터를 전송할 수 있게끔 한다.

WebSocket은 일반 Socket 통신과는 달리 HTTP 80, HTTPS 443 포트 위에서 동작하도록 설계되었다. 따라서 별도의 포트를 열지 않아도 된다.

HTTP 통신은 HTTP와 HTTPS로 통신하는데, HTTPS는 통신의 보안을 위해 HTTP에 보안을 적용한 것이다.
웹 소켓은 통신을 위해 ws를 사용하는데 ws는 HTTP에 대응하는 것이며, 보안을 위해서는 wss를 사용하여 통신해야 한다.

SockJS

웹소켓은 HTML5 이후에 나왔기 때문에 HTML5 이전의 기술로 구현된 서비스에서는 웹소켓 기술을 사용할 수 없다.
HTML5 이전의 기술로 구현된 서비스에서 웹소켓처럼 동작할 수 있도록 도와주는 것이 SockJS이다.

SockJS는 네이티브 웹소켓을 사용하려고 하는 WebSocket 클라이언트이며, 웹소켓을 지원하지 않는 구형 브라우저에 대체 옵션을 제공한다.
우선 WebSocket 연결을 시도하고 실패할 경우 SSE, Long-Polling과 같은 HTTP 기반의 다른 기술로 전환하여 다시 연결을 시도한다.

SockJS를 사용하면 애플리케이션이 웹소켓을 사용하도록 허용하고 브라우저 등에서 웹소켓을 지원하지 않는 경우에 웹소켓을 대체할 대안 기술을 사용하도록 한다. 런타임에 사용 기술을 변경하기 때문에 애플리케이션 코드의 변경이 필요없어 유연하다는 장점이 있다.

SockJS는 서버에서 주기적으로 Heartbeat 메시지를 전송하도록 하여, 프록시가 커넥션이 끊겼다는 결론을 내리지 않도록 한다. 주기적으로 보내는 시간을 heartbeat interval이라고 한다.
서버가 Heartbeat 메시지를 전송하고 클라이언트가 이에 대한 응답을 하지 않으면, 서버는 클라이언트가 죽은 것으로 판단한다.
반면 클라이언트는 마지막 Hearbeat 메시지를 전송받고 특정 시간(heartbeat timeout)동안 Heartbeat 메시지를 받지 못하면 서버가 죽은 것으로 판단하고 접속 종료와 재접속 흐름을 진행한다.
기본값으로 heartbeat interval은 25초, heartbeat timeout은 60초로 설정되며 설정을 변경할 수 있다.

(참고) STOMP를 이용해 Heartbeat를 주고 받게되면, SockJS의 Heartbeat 설정은 비활성화된다.

STOMP

웹소켓만을 이용하게 되면 해당 메시지가 어떤 요청인지, 어떻게 처리해줘야 하는지 직접 구현해야 한다. 세션을 관리하는 방법 또한 서버에서 직접 구현하게 된다.

STOMP는 Simple Text Oriented Message Protocol의 약자로, 메시지 전송을 효율적으로 하기 위한 프로토콜이다.
클라이언트와 서버가 전송할 메시지의 유형, 형식, 내용들을 정의하는 매커니즘으로, 메시지의 헤더에 값을 줘서 인증 처리를 구현하는 것도 가능하다.

STOMP는 PUB/SUB 구조로 동작한다.
PUB/SUB 구조는 메시지를 공급하는 주체와, 소비하는 주체를 분리하여 제공하는 메시징 방법이다.
따라서 메시지 송신, 수신에 대한 처리를 명확하게 정의할 수 있다.

STOMP 공식 문서

PUB/SUB 구조

PUB/SUB 구조에 대해 조금 더 설명해 보겠다.

PUB은 클라이언트의 메시지 송신과 관련된다.
서버가 /pub/chat-room/{chat-room-id}과 같은 메시지 요청 경로를 오픈했다고 하자.
클라이언트들은 서버에서 오픈한 메시지 요청 경로로 메시지를 전송하고, 서버는 메시지를 전달받아 적절한 처리를 한다.

SUB은 클라이언트의 메시지 수신과 관련된다.
클라이언트가 /sub/chat-room/{chat-room-id}와 같이 구독요청을 보내면, 서버는 해당 경로를 topic으로 관리하고 특정 이벤트가 발생했을 때 특정 topic을 구독중인 클라이언트들에게 메시지를 전달할 수 있다.
간단하게 말하면 topic을 기준으로 그룹을 나누고, 서버는 topic 그룹으로 세션을 관리, 클라이언트는 구독한 topic에 대한 메시지를 수신할 수 있도록 한다.

RabbitMQ, Kafka와 같은 외부 메시지 큐를 사용하는 이유
WebSocket만을 이용하게 되면, 세션 단위의 메시지 전달만 가능하다. 따라서 채팅방을 여러개 만들지 못한다는 문제가 있다.
이를 해결하기 위해 STOMP를 이용하여 pub/sub 구조로 여러 방을 만들고 STOMP Broker를 통해 특정 Topic을 구독중인 클라이언트들에게 메시지를 전달할 수 있다.
하지만 STOMP는 서버 메모리를 Broker로 사용하기 때문에 서버가 2개 이상일 경우, 한 서버에서 발생한 메시지를 다른 서버에 전달하기가 어렵다. 클러스터링을 통해 해결해야 한다.
이러한 문제를 해결하기 위해 외부 메시지 큐를 사용할 수 있다. 한 서버에서 발생한 메시지는 외부 메시지 큐에 적재되고, 외부 메시지 큐를 구독중인 모든 서버는 적재된 메시지를 가져와 메시지가 해당되는 토픽을 구독중인 모든 클라이언트들에게 전달할 수 있게 된다.

[프로그래머스] 혼자 놀기의 달인 (Kotlin)

yoo97 — Sat, 31 Dec 2022 15:38:28 +0900

프로그래머스 : 혼자 놀기의 달인 (Kotlin)

문제

문제 확인하기

풀이

cards의 길이는 총 상자의 개수이며, cards의 값에는 1부터 cards의 길이까지의 숫자 카드가 존재한다.

그리고 문제를 다시 확인해보자.

그 다음 임의의 상자를 하나 선택하여 선택한 상자 안의 숫자 카드를 확인합니다. 다음으로 확인한 카드에 적힌 번호에 해당하는 상자를 열어 안에 담긴 카드에 적힌 숫자를 확인합니다. 마찬가지로 숫자에 해당하는 번호를 가진 상자를 계속해서 열어가며, 열어야 하는 상자가 이미 열려있을 때까지 반복합니다.

이 부분은 DFS 알고리즘을 통해 구현할 수 있다.
상자의 번호를 cards 배열의 인덱스로, 상자안의 값을 cards 배열의 값으로, 상자가 열렸는지 여부는 방문 여부를 체크하는 새로운 배열 visited를 선언하여 최상위 DFS 알고리즘 호출 한번에 하나의 그룹을 얻을 수 있다.
이때, DFS 호출의 결과로 몇 개의 상자를 방문했는지 반환하도록 한다.

visited 배열을 순차적으로 탐색하면서 아직 방문되지 않은 상자에 대해 DFS 알고리즘을 계속해서 호출하도록 한다.

모든 상자에 대해 방문을 마쳤다면, 최상위 DFS 호출이 반환한 방문한 상자의 갯수 중 가장 큰 2개를 곱셈하면 문제가 요구하는 답을 얻을 수 있다.
DFS 호출 한번에 모든 상자를 열었다면 0을 반환하면 된다.

이때 주의할 점은 상자 번호를 가리키는 cards 배열의 인덱스와 카드 숫자를 가리키는 cards 배열의 값이 다르다는 점이다.
배열의 인덱스는 0부터 시작하고, cards 배열의 값은 카드 숫자를 가리키므로 1부터 시작한다.
따라서 카드 번호가 k이면, 다음 선택할 상자 번호는 k-1이 된다.

아래는 코틀린으로 작성한 코드이다.

class Solution {
    lateinit var visited: BooleanArray

    fun solution(cards: IntArray): Int {
        visited = BooleanArray(cards.size)

        var group1 = 0
        var group2 = 0

        for (i in cards.indices) {
            // 현재 상자를 열지 않았으면
            if (!visited[i]) {
                // 현재 상자를 연다.
                visited[i] = true
                // DFS 수행, 이 그룹의 개수를 얻는다.
                val count = dfs(i, cards)
                // 현재 그룹의 개수 저장
                if (count > group1) {
                    group2 = group1
                    group1 = count
                } else if (count > group2) group2 = count
            }
        }

        // 가장 개수가 많은 그룹끼리 곱셉
        // 그룹이 하나뿐이면 group2는 0이 되므로 문제의 요구사항 만족
        return group1 * group2
    }

    fun dfs(idx: Int, cards: IntArray): Int {
        var count = 1
        // cards[idx]는 현재 박스의 카드 숫자
        // 인덱스는 0부터 시작, 카드 번호는 1부터 시작
        // 따라서, 다음 박스의 인덱스는 현재 박스의 카드 숫자 - 1 
        val nextBoxIdx = cards[idx] - 1
        // 다음 박스륿 오픈하지 않았으면
        if (!visited[nextBoxIdx]) {
            // 다음 상자를 연다
            visited[nextBoxIdx] = true
            count = dfs(nextBoxIdx, cards) + 1
        }
        // 현재 박스의 카드 숫자를 박스의 번호로 한다면(가장 깊은 DFS) 1을 반환
        // 그렇지 않으면 DFS가 중첩된 횟수만큼(최상위 DFS 한 번에 방문한 박스 개수만큼) 반환
        return count
    }
}

[프로그래머스] 마법의 엘리베이터 (Kotlin)

yoo97 — Fri, 30 Dec 2022 18:15:26 +0900

프로그래머스 : 마법의 엘리베이터 (Kotlin)

문제

문제 확인하기

풀이

storey 층에서 0층으로 내려가야 한다.
내려가는 방법은 -10^c or +10^c (c >= 0) 중에서 선택해야 한다.

우선 storey로 한 자리 숫자가 주어졌을 때를 생각해보자.

3이 주어졌다고 할 때 단순히 -1 버튼을 3번 눌러서 0층으로 가는 것이 가장 빠르다.

7이 주어졌다고 해보자.
이 때는 -1을 7번 누르는 것 보다 +1을 3번 눌러서 10층으로 이동하고 -10 버튼을 눌러 0층으로 가는 것이 가장 빠르다.

5가 주어지면 어떨까?
5가 +1을 5번 누르고 -10을 한 번 누르는 것 보다는 단순히 -1을 5번 누르는 것이 더 빠르게 이동할 수 있다.

이번에는 storey가 두 자리 숫자가 주어졌을 때를 생각해보겠다.

13이 주어진다면 -1을 3번, -10을 한번 누르는 것이 가장 빠르다.

17이 주어진다면 -1을 7번 누르는 경우보다 +1을 3번, -10을 2번 누르는 경우가 더 빠르다.

각각 45와 55, 65가 주어진 경우를 생각해보자.
45가 주어진다면 -1을 5번, -10을 4번 누르는 경우가 총 9번 누르게 되어 가장 빠르다.
55가 주어진다면 -1을 5번, -10을 5번, 총 10번으로 이동 가능하고 또 다른 방법으로 +1을 5번, +10을 4번, -100을 1번 눌러 총 10번으로 이동하는 경우가 있다.
65가 주어진다면 +1을 5번, +10을 3번, -100을 1번 눌러 총 9번만 눌러서 0층으로 갈 수 있다.

즉, i번째 자릿수가 5이면 i+1번째 자릿수의 값에 따라 올라갈지 내려갈지 정해야 한다.
위 내용을 확인해보면 i+1번째 자릿수가 4 이하이면 - 버튼으로 내려가면 되고, 6 이상이면 + 버튼을 통해 올라가는 것이 빠르다.
그럼 i+1번째 자릿수가 5일 경우가 남는데, 이 때는 올라가든 내려가든 동일했기 때문에 아무 경우나 하나를 골라 선택하면 된다.

여기서 알고리즘을 도출할 수 있다.

1의 자릿수부터 마지막 자릿수까지 차례로 확인하여 아래 내용을 반복한다.
- 현재 확인중인 자릿수를 i라고 한다. i번째 자릿수의 값(k)에 따라 아래 내용을 수행한다.
  - k가 5보다 작으면, -10^(i-1) 버튼을 k번 눌러 내려간다.
  - k가 5보다 크면, +10^(i-1) 버튼을 10 - k번 눌러 올라간다. 이 때, 다음 자릿수의 값이 1 증가한다.
  - k가 5이면, 다시 아래 내용 중 하나를 선택해서 수행한다.
    - i+1번째 자릿수의 값(j)이 4 이하이면, -10^(i-1) 버튼을 k번 눌러 내려간다.
    - i+1번째 자릿수의 값(j)이 5 이상이면, +10^(i-1) 버튼을 10 - k번 눌러 올라간다.

여기서 주의할 점은 storey의 자릿수 만큼 반복을 수행했다면, storey의 마지막 자릿수에서 자릿수 올림이 발생했는지의 여부이다.

만약 98765가 storey로 주어졌을 때, 총 자릿수의 갯수는 5개이다.
위 알고리즘을 통해 5번 반복수행 했다고 하자.
위 알고리즘을 이용하면 마지막 자릿수 9에서 자릿수 올림이 발생한다.
그럼 알고리즘 수행을 마쳤을 때 현재 위치한 층은 100000가 되어 0층으로 이동하지 않은 상태가 된다.

이 경우 -100000 버튼을 한번 눌러 0층으로 갈 수 있기 때문에 알고리즘 수행을 마쳤을 당시 총 버튼을 누른 횟수 + 1을 결과로 반환하면 된다.

아래는 해당 내용을 코틀린을 사용해서 작성한 코드이다.

class MagicElevator {
    fun solution(storey: Int): Int {
        // 총 버튼을 누른 횟수
        var answer = 0

        var remainStorey = storey
        // 자릿수
        val digitCount = remainStorey.toString().length

        // 자릿수 만큼 진행
        for (i in 1 .. digitCount) {
            // 10^(i-1)의 자릿수 값
            val digitNum = getDigitNumberFrom(digitAt = i, num = remainStorey)
            // 자릿수의 값이 5보다 크면 +10^(i-1) 버튼을 통해 올라간다.
            if (digitNum > 5) {
                remainStorey += makeDigitNumber(digit = i, num = 10 - digitNum)
                answer += (10 - digitNum)
            }
            // 자릿수의 값이 5보다 작으면 -10^(i-1) 버튼을 통해 내려간다.
            else if (digitNum < 5) {
                remainStorey -= makeDigitNumber(digit = i, num = digitNum)
                answer += digitNum
            }
            // 자릿수의 값이 5이면 다음 자릿수를 확인한다.
            else {
                // 다음 자릿수가 없으면 -10^(i-1) 버튼을 통해 내려간다.
                if (i + 1 > digitCount) {
                    remainStorey -= makeDigitNumber(digit = i, num = digitNum)
                    answer += digitNum
                } else {
                    // 다음 자릿수
                    val nextDigitNumber = getDigitNumberFrom(num = remainStorey, digitAt = i + 1)
                    // 다음 자릿수가 4 이하이면 -10^(i-1) 버튼을 통해 내려간다.
                    if (nextDigitNumber <= 4) {
                        remainStorey -= makeDigitNumber(digit = i, num = digitNum)
                        answer += digitNum
                    }
                    // 다음 자릿수가 5 이상이면 +10^(i-1) 버튼을 통해 내려간다.
                    else {
                        remainStorey += makeDigitNumber(digit = i, num = 10 - digitNum)
                        answer += (10 - digitNum)
                    }
                }
            }
        }

        // 기존 storey 의 가장 큰 자릿수에서 자릿수가 하나 더 생겼을 경우
        // ex) 9 -> 10이 된 경우, -10 버튼을 눌러줘야 한다.
        if (remainStorey != 0 && remainStorey % 10 == 0) answer++;

        return answer
    }

    // num * 10^(digit-1) 값 생성
    private fun makeDigitNumber(digit: Int, num: Int) = ((10).toDouble().pow(digit - 1) * num).toInt()

    // num 에서 digitAt 번째 자릿수 값 꺼냄
    private fun getDigitNumberFrom(num: Int, digitAt: Int): Int = ((num / (10).toDouble().pow(digitAt - 1)) % 10).toInt()
}

[프로그래머스] 멀쩡한 사각형 (Kotlin)

yoo97 — Thu, 29 Dec 2022 17:15:16 +0900

프로그래머스 : 멀쩡한 사각형 (Kotlin)

문제

문제 확인하기

풀이

가로 3, 세로 4 크기의 직사각형이 주어졌다고 하자.

이 직사각형을 대각선 양 끝 꼭짓점을 기준으로 자르는 것을 좌표상에 표시하면 아래와 같이 표현할 수 있다.

양 끝 꼭짓점([0, 0]과 [3, 4])을 서로 이었을 때 나오는 대각선은 y = (4/3) * x 방정식으로 표현할 수 있다.
우리는 이 대각선을 기준으로 우측에 있는 삼각형에 몇 개의 1 * 1 크기의 정사각형이 존재하는지 세고, 이 값의 2배를 정답으로 반환하면 된다.

여기서 1 * 1 크기의 정사각형이 몇 개가 존재하는지 어떻게 셀 수 있을까?

먼저 x 좌표의 범위가 0 ~ 1인 부분을 보자.
여기는 정사각형이 존재하지 않는다.

다음 x 좌표의 범위가 1 ~ 2인 부분을 보자.
x 좌표가 1일 때 y 좌표는 4/3 이다.
x 좌표가 2일 때는 확인할 필요가 없다.
x 좌표가 1일 때의 y 좌표 4/3 위로는, 대각선이 1 * 1 정사각형을 모두 잘라버려 더 이상 정사각형이 아니게 된다.

따라서 x 좌표가 1일 때의 y 좌표값을 자연수로 내림한 값 만큼의 1 * 1 크기의 정사각형이 존재하게 된다.
여기서 4/3을 자연수로 내림하면 1이 되고, 1 * 1 크기의 정사각형이 1개 존재한다.

위 내용을 통해 x 좌표의 범위가 2 ~ 3인 부분도 확인해보자.
x좌표가 2일 때 y 좌표는 8/3 이다.
8/3 위로는 x 좌표 3 이내에 정사각형이 존재하지 않는다.

따라서 x 좌표가 2일 때의 y 좌표값을 자연수로 내림한 값이 x 좌표값 2에서 3 이내에 존재하는 정사각형의 개수이다.
여기서 8/3을 자연수로 내림하면 2이 되고, 1 * 1 크기의 정사각형이 2개 존재하는 것이다.

이제 위 과정을 통해 구한 정사각형의 값을 모두 더하면 큰 직각삼각형 하나에 존재하는 1 * 1 정사각형의 개수(sum)가 된다.

3 * 4 크기의 직사각형을 대각선으로 잘랐기 때문에 이 직각삼각형이 2개 존재하게 되므로, sum * 2가 문제가 요구하는 정답이 된다.

아래는 코틀린으로 작성한 코드이다.

class Solution {
    fun solution(w: Int, h: Int): Long {
        return (0L until w.toLong()).reduce { total, i -> total + (h.toLong() * i) / w } * 2
    }
}