게시글 정보를 담는 article 테이블에 약 1200만건의 데이터를 삽입하였다. 분산 데이터베이스 환경(샤딩)을 고려하여 FK는 설정하지 않았다.(board_id, writer_id)

QueryPlan을 확인하고, 인덱스를 설정하는 등 테스트를 진행하며 성능을 개선해보자.

페이징 구현

특정 게시판의 N번 페이지에서 M개의 게시글을 불러오는 쿼리는 아래와 같다. (최신순 정렬)

select * from article 
    where board_id = {board_id}
    order by created_at desc
    limit M offset (N-1) * M

위 쿼리 그대로 4번 페이지에서 30개의 게시글을 조회했다.

페이지 조회 결과

고작 1200만건의 데이터에서 30개의 게시글을 조회하는데 실행에 5.48초가 걸렸다. 정상적인 서비스가 어려운 수준이다.

실행계획(Query Plan)

explain키워드를 통해 실행계획을 확인해보자.

*type = ALL *

• 테이블 전체 순회 - Full Table Scan

Extra = Using where; Using filesort

• where 절을 사용하며, 데이터가 많아 메모리에서 정렬할 수 없어서, 파일(디스크)에서 데이터를 정렬한다.

전체 데이터에 대해 필터링 및 정렬을 수행하므로 아주 큰 비용이 든 것을 확인할 수 있다.

Using filesort MySQL InnoDB 스토리지 엔진은 Order by 사용시 기본적으로 메모리의 정렬 버퍼(sort_buffer)를 사용한다.
하지만 정렬할 레코드 양이 너무 많아 정렬 버퍼의 크기를 초과할 경우, 디스크의 임시공간을 만들어 그곳에서 정렬을 한다.
: Disk I/O가 다수 발생 -> 속도 저하

인덱스

이를 개선하기 위해 인덱스를 사용할 수 있다.

create index idx_board_id_article_id 
on article(board_id asc, article_id desc);

인덱스를 통해 board_id에 대해 오름차순 정렬, board_id가 같다면 article_id에 대해 내림차순 정렬된 B+ tree가 생성된다.

article_id는 Snowflake 알고리즘을 사용하기 때문에 article_id에 대한 정렬이 곧 시간순 정렬이다.

인덱스를 걸고 동일한 쿼리를 실행한 결과 아주 빠르게 조회되는 것을 확인할 수 있다. 하지만 이것으로 모든 문제가 해결되었을까?

동일한 쿼리로 50000번째 페이지를 조회해보자. offset = (50000 - 1) * 30

실행 시간은 1.83초로 매우 느려졌다. Query Plan을 살펴봐도 인덱스가 사용되는 것을 확인할 수 있다.

인덱스가 제대로 적용되었다면, offset이 늘어났다고해서 실행 시간에 유의미한 변화가 없을 것으로 기대했다.

왜 이런 문제가 발생할까?

Clustered Index / Secondary Index

MySQL InnoDB 스토리지 엔진에는 두가지 주요한 인덱스가 존재한다.

현재 우리의 Article 테이블에서는 PK인 {article_id}로 Clustered Index가 생성되어있고, {board_id, article_id} 로 Secondary Index를 생성한 상태이다.

실행 쿼리

select * from article 
    where board_id = 1
    order by article_id desc
    limit 30 offset 1499970

예상 동작

1) 세컨더리 인덱스의 리프 노드 시작점에서 1499970의 offset이 될 때까지 곧장 skip한다.

2) 30개의 포인터가 참조하는 클러스터드 인덱스의 데이터를 조회한다.

실제 동작

1) 세컨더리 인덱스의 리프 노드 시작점에서 클러스터드 인덱스의 데이터를 전부 조회하면서 1499970의 offset이 될 때까지 skip한다.

2) 30개의 포인터가 참조하는 클러스터드 인덱스의 데이터를 조회한다.

offset이 될 때까지 전부 조회하면서, offset이 클 경우 성능 문제가 발생하는 것이다.

예상대로 동작하지 않는 이유? (추정)
현재 실행하는 쿼리는 select *로 최종적으로 세컨더리 인덱스만으로는 확인할 수 없는 값을 조회한다. InnoDB 스토리지 엔진은 이런 경우 where 조건에 부합하는지 여부를 확인하기 위해 실제 데이터를 전부 조회하는 과정을 거친다.
물론 현재 쿼리는 세컨더리 인덱스에서 확인할 수 있는 컬럼인 board_id만으로 where 조건문이 구성되어있지만, 이는 특수한 경우이다. 쿼리 옵티마이저가 특수한 경우를 모두 캐치해서 최적화하지는 않는 것으로 추정된다.

쿼리 튜닝

Covering Index

세컨더리 인덱스만으로 필요한 데이터 컬럼을 모두 가져올 수 있으면, 이를 커버링 인덱스라고 부르고 성능이 매우 우수해진다.

select * from (
    select article_id from article //세컨더리 인덱스만으로 확인 가능
    where board_id = 1
    order by article_id desc
    limit 30 offset 144970
) t left join article on t.article_id = article.article_id;

기존 인덱스 사용이 필요한 부분을 내부쿼리로 변경하고, 커버링 인덱스가 되도록 article_id만 조회하였다.

이후 기존 테이블과 left join을 한다.

튜닝 결과

같은 결과를 출력하는데 1.83 -> 0.04초로 속도가 상당히 개선되었다.

조건

• 아이템을 선택하거나 선택하지 않거나 둘 중 하나만 가능. (0-1)
• 각 아이템은 무게(Weight)와 가치(Value)를 지닌다.

기본 Knapsack

최대 W의 무게에서, 최대 가치의 조합을 찾아라.

기본 Knapsack 문제는 일차원 배열 혹은 이차원 배열로 해결할 수 있다.

일차원 DP

• dp[w] = 무게 w일 때의 최대 가치

이차원 DP

• dp[i][w] = i번째 아이템까지 고려했을 때, 총 무게가 w일 때의 최대 가치

두 해결 방법 모두 시간복잡도는 O(NW)로 동일하지만, 공간복잡도는 O(W), O(NW)로 다르다.

따라서 아이템의 개수(N)가 많고, 선택한 아이템을 역추적할 필요가 없으면, 일차원 DP로 해결하는 것이 적절하다.

일차원 DP 알고리즘

int[] dp = new int[maxWeight];

//모든 아이템에 대해
for(int i = 0; i < N; i++) {
    int tmpWeight = //현재 아이템 무게
    int tmpValue = //현재 아이템 가치

    // *중요 뒤에서부터 순회 (중복 선택 방지)
    for(int w = maxWeight; w >= tmpWeight; w--) {
        dp[w] = Math.max(dp[w], dp[w - tmpWeight] + tmpValue);
    }
}

점화식

• dp[w] = Math.max(dp[w], dp[w - tmpWeight] + tmpValue)

현재 무게(w) 에서의 최대 가치를, 현재 아이템을 넣는 것을 고려했을 때의 가치와 비교하여 갱신한다.

앞에서부터 순회할 경우 현재 아이템을 중복으로 삽입하는 것이므로 주의.

이차원 DP 알고리즘

int[] dp = new int[N][maxWeight]

//모든 아이템에 대해
for(int i = 0; i < N; i++) {
    int tmpWeight = //현재 아이템 무게
    int tmpValue = //현재 아이템 가치

    for(int w = 0; w < maxWeight; w++) {
        if(w < tmpWeight) {
            dp[i][w] = dp[i-1][w]; //현재 아이템을 못넣음
        } else {
            dp[i][w] = Math.max(
                dp[i-1][w], //아이템을 안넣음
                dp[i-1][w - tmpWeight] + tmpValue //아이템을 넣음
            )
        }
    }
}

점화식

현재 무게(w) 보다 아이템의 무게가 큰 경우 (아이템을 넣지 못할때)

• dp[i][w] = dp[i-1][w]

현재 무게(w) 가 아이템의 무게보다 크거나 같은 경우 (아이템을 넣을 수 있을 때)

• dp[i][w] = Math.max(dp[i-1][w], dp[i-1][w-tmpWeight] + tmpValue

일차원 DP와 마찬가지로 현재 무게에서의 최대 가치를, 현재 아이템을 넣는 것을 고려했을 때의 가치와 비교하여 갱신하면 된다.

선택 역추적 이차원 배열을 갱신할 때, 아이템을 선택한 경우 dp[i][w] = dp[i-1][w-tmpWeight] + tmpValue로 갱신된다.

즉, dp[i][w] == dp[i-1][w] 인 경우 i 번째 아이템은 선택하지 않은 것이다.

dp[N][W] 에서 시작하여,

• if(dp[i][w] == dp[i-1][w]) -> i 번째 아이템은 선택 X, i--
• else -> i 번째 아이템 선택 O, i--, w = w - weight[i]

변형 Knapsack

V의 가치 이상을 만족하는 조합 중, 최소 무게를 찾아라.

변형이라고는 하지만 위의 두 방식으로도 해결이 가능하다.

• 1차원 배열을 처음부터 순회하며, 값이 V 이상인 최소 무게를 찾는다.
• 2차원 배열의 마지막 row를 순회하며 값이 V 이상인 최소 무게를 찾는다.

하지만, 기본 Knapsack은 가방의 크기(최대 무게)를 문제에서 제약조건으로 제시하므로, 크기가 합리적인 수준인 경우가 대부분이다.

변형 Knapsack 같은 경우 각 아이템의 크기의 합이 엄청나게 커질 수 있으므로, 최대 무게(모든 아이템 무게의 합)에 맞춰 배열을 만들수 없는 경우가 발생한다.

그럴 때는 가치(V) 기준으로 배열을 만들어서 해결할 수 있다.

일차원 DP

• dp[v] = 가치 V일 때의 최소 무게

//maxValue = sum of all item value
int[] dp = new int[maxValue + 1]

Arrays.fill(dp, INF);
dp[0] = 0;

//모든 아이템에 대해
for(int i = 0; i < N; i++) {
    int tmpWeight = //현재 아이템 무게
    int tmpValue = //현재 아이템 가치

    // *중요 뒤에서부터 순회 (중복 선택 방지)
    for(int v = maxValue; v >= tmpValue; v--) {
        dp[v] = Math.min(dp[v], dp[v - tmpValue] + tmpWeight);
    }
}

int answer = 0;
for(int v = targetValue; v <= maxValue; v++) {
    answer = Math.min(answer, dp[v]);
}

시간복잡도는 O(NW)로 동일하지만, 공간복잡도가 O(W)가 아닌, O(V)로 변경되었다.

주어진 문제에서 무게에 비해 가치의 합이 크지 않을 경우 위 방법을 사용하면 된다.

1. synchronized
2. volatile
3. Atomic

Volatile

이 중 volatile은 다른 스레드의 변경 사항에 대한 가시성(Visibility)을 확보시켜 준다. 하지만 원자성을 보장하지 않기 때문에, 동시성 문제를 완전히 해결할 수 없다.

메모리 계층 구조에서 CPU 코어와 메인메모리 사이에는 캐시가 존재한다.

프로세서의 발전속도를 메인메모리가 따라가지 못하면서, CPU와 메인메모리 사이의 속도 간극을 줄여주는 완충제 역할을 위해 캐시를 도입한 것이다.

멀티코어 환경에서는 각 CPU 코어 별로 캐시메모리가 존재한다.

즉, 멀티스레딩 시 서로 다른 스레드가 서로 다른 코어에서 실행되면, 서로 다른 캐시를 사용하게 될 수 있다.

이로인해 메모리 가시성 문제(다른 스레드의 변경 사항이 보이지 않음)가 발생하며, 이를 해결하기 위해 volatile을 사용할 수 있다.

volatile은 JVM이 해당 변수의 읽기/쓰기를 항상 메인메모리 기준으로 강제한다. 즉, 어떤 스레드든 캐시된 값이 아닌, 최신 값을 공유하도록 보장한다.

Read Committed 와의 유사성

트랜잭션 격리 수준 중 Read Committed은 커밋된 다른 트랜잭션의 변경사항을 볼 수 있게 해준다.

하지만, 그것만으로 쓰기 작업에 대한 동시성 문제를 해결할 수 없다.

읽기 -> (다른 트랜잭션의 쓰기 커밋) -> 읽은 값에 기반한 쓰기

위와 같은 시나리오에서 동시성 문제가 발생하고, Read Committed 만으로는 해결이 불가능하며, 별도의 락킹 메커니즘이 필요하다.

마찬가지로, volatile은 다른 스레드의 변경 사항에 대한 가시성은 확보할 수 있으나, 복합 연산을 불가분한 연산으로 만들지 못하므로, 동시성 문제를 완벽히 해결할 수 없다.

Volatile만으로 동시성 문제를 해결하려면?

Read Only, Write Only 스레드를 나누어야 한다.

• Read 작업은 여러 스레드에서 동시에 가능
• Write 작업은 오직 하나의 스레드에서만!

여러 풋살 매칭 플랫폼에 요청을 보내 데이터를 가공하여 내보내는 '풋살파인더' 프로젝트가 있다.

만약 요청을 보낸 여러 플랫폼 중 특정 플랫폼이 응답하지 않는다면? 응답하지 않는 플랫폼은 제외하고, 나머지 데이터만 가공해서 내려주어야 한다.

기존 코드

//플랫폼 별 요청코드
ResponseEntity<String> response = new RestTemplate().exchange(
    requestUrl,
    HttpMethod.GET,
    new HttpEntity<>(new HttpHeaders()),
    String.class
);

기존코드는 new RestTemplate()으로 매 요청마다 새롭게 RestTemplate 객체를 생성하여 각 플랫폼에 요청을 보낸다.

이 방식은 타임아웃을 설정하지 않아, 특정 플랫폼이 응답하지 않는다면 상당히 오랜시간 대기하여 전체 응답속도가 매우 느려지는 문제가 발생하였다.

또한 매번 RestTemplate() 객체를 생성하는 것도 메모리 낭비가 발생한다.

개선

@Configuration
public class RestTemplateConfig {

    @Bean
    public RestTemplate restTemplate() {
        RequestConfig requestConfig = RequestConfig.custom()
                .setConnectionRequestTimeout(Timeout.ofSeconds(3)) // 연결 타임아웃
                .setResponseTimeout(Timeout.ofSeconds(3))  // 읽기 타임아웃
                .build();

        CloseableHttpClient httpClient = HttpClients.custom()
                .setDefaultRequestConfig(requestConfig)
                .build();

        HttpComponentsClientHttpRequestFactory factory = new HttpComponentsClientHttpRequestFactory(httpClient);

        return new RestTemplate(factory);
    }

}

RestTemplateConfig를 통해 연결 타임아웃, 응답 타임아웃을 설정하고 RestTemplate을 싱글톤으로 관리한다.

이후 RestTemplate를 주입받아서 사용하는 방식으로 변경하였다.

특정 헤더 값을 제외하고 요청을 보내보니, 설정한 타임아웃 만큼 시간이 지나자 예외가 발생하였고, 로그가 남은 것을 확인할 수 있다.

풋살파인더도 무한정 대기하지 않고, 응답이 오지않은 플랫폼을 제외하고 데이터를 응답하였다.

• 조작하려는 데이터가 이미 버퍼풀에 존재한다면, 메모리 I/O 만 일어나므로 애플리케이션은 빠른 응답을 받을 수 있다.

• 하지만 조작하려는 데이터가 버퍼풀에 존재하지 않는다면, 디스크로부터 데이터 페이지를 버퍼풀에 로드하는 과정이 선행되고, 이 과정은 디스크 I/O가 발생하므로 상대적으로 느리다.

속도 측정 테스트

@RestController
@RequiredArgsConstructor
public class ExampleController {

    private final ExampleEntityRepository repository;

    @GetMapping("/test-buffer-hit")
    public String testBufferHit() {
        // 첫 번째 요청 (버퍼 풀에 없는 경우)
        long start1 = System.currentTimeMillis();
        Optional<ExampleEntity> entity1 = repository.findById(1L);
        long end1 = System.currentTimeMillis();

        // 두 번째 요청 (버퍼 풀에 있는 경우)
        long start2 = System.currentTimeMillis();
        Optional<ExampleEntity> entity2 = repository.findById(1L);
        long end2 = System.currentTimeMillis();

        return String.format(
                "First Query Time: %d ms, Second Query Time: %d ms",
                (end1 - start1), (end2 - start2)
        );
    }
}

간단히 속도 측정 테스트를 해보았다. 과정은 다음과 같다.

1. MySQL 서버를 띄우고 데이터를 삽입한다.
2. MySQL 서버를 Shutdown 후, 다시 띄운다.
3. 위 컨트롤러로 요청을 한다.

2에서 서버를 Shutdown 하는 이유는 데이터 삽입 시 버퍼풀에 페이지가 존재하기 때문이다.

테스트 결과

• 첫 번째 요청 : 71ms
• 두 번째 요청 : 6ms

첫 번째 요청(버퍼풀에 데이터 X)은 디스크 -> 버퍼풀로 데이터를 읽어오는 과정이 포함되어, 두 번째 요청(버퍼풀에 데이터 O)에 비해 상당히 느리게 처리된 것을 확인할 수 있다.

워밍업(Warming Up)

워밍업은 쿼리에 사용되는 데이터가 버퍼 풀에 적재돼 있는 상태를 의미한다.

MySQL 5.5 버전 이하에서는 점검을 위해 MySQL 서버를 재시작해야하는 경우, 서비스를 오픈하기 전에 강제 워밍업을 위해 주요 테이블과 인덱스에 대해 풀 스캔을 한 번씩 실행하고 서비스를 오픈했다고 한다.

하지만 MySQL 5.6 이후 버전에서는 버퍼 풀 덤프 및 적재 기능이 도입됐다. 서버 재시작시, 버퍼 풀의 백업과 복구를 할 수 있는 기능으로 innodb_buffer_pool_dump_at_shutdown 과 innodb_buffer_pool_load_at_startup 설정을 MySQL 설정 파일에 넣어두면 된다고 한다.

데이터베이스 이상현상이란 데이터베이스 설계가 잘못되었거나, 비정규화된 상태에서 발생하는 비효율적이고 부정확한 데이터 처리 문제를 의미한다.

아래 테이블로 삽입이상, 갱신이상, 삭제이상의 예시를 들어보자.

사진출처 - https://dev-coco.tistory.com/63

삽입이상

• 데이터 삽입 시 불필요한 데이터도 함께 삽입해야하는 문제

• '컴퓨터 네트워크' 라는 새로운 강의가 추가되었을 때, 아직 수강하는 학생이 없을 수 있다. 그럼에도 데이터를 추가하기 위해서는 불필요한 학생 정보를 함께 삽입해야 한다.

갱신이상

• 데이터 중복으로 인해 일부만 수정하면 불일치가 발생하는 문제

• '김현수' 학생의 전화번호를 수정했을 때, 중복된 모든 열을 찾아서 수정하지 않으면 불일치가 발생한다.

삭제이상

• 특정 데이터 삭제 시, 다른 연관된 데이터도 삭제되는 문제

• '이병철' 학생의 정보를 삭제했더니, '알고리즘' 강의의 정보도 함께 삭제된다.

함수적 종속성(Functional Dependency)

함수적 종속성이란 특정 속성 집합(attribute)이 다른 속성 집합을 유일하게 결정 짓는 관계를 의미한다.

예를 들어, Primary Key는 테이블의 모든 속성을 유일하게 결정 지으므로 {PK} -> {All Attributes} 의 FD가 성립한다.

함수적 종속성은 개념적인 Schema로 판명해야한다. 특정 순간의 Instance로 판단하면 안된다.

즉, 함수적 종속성은 데이터 간의 본질적인 관계를 나타내며, 특정 순간의 데이터 상태가 아니라 데이터 스키마 설계를 기준으로 평가해야 한다.

1) 완전 함수적 종속성(Full Functional Dependency)

완전 함수적 종속성이란 어떤 속성들이 PK 전체에 의존하는 것을 의미한다. PK의 일부만으로 결정되지 않고, 반드시 전체에 의존해야한다.

{학번, 강의코드}는 테이블에서 각 행을 고유하게 식별할 수 있는 최소 속성 집합이다.

• {학번, 강의코드} -> {이름}
• {학번, 강의코드} -> {나이}
• {학번, 강의코드} -> {성별}
• {학번, 강의코드} -> {강의명}
• {학번, 강의코드} -> {전화번호}

위와 같이 테이블의 모든 속성에 대해 함수적 종속성이 존재한다. 하지만, 이는 완전 함수적 종속성을 만족하지 않는다.

• {학번} -> {이름, 나이, 성별, 전화번호}
• {강의코드} -> {강의명}

위와 같이 PK의 일부 속성 만으로 특정 속성을 결정 지을 수 있기 때문이다.

만약 테이블이 {학번, 이름, 나이, 성별, 전화번호} 만으로 구성되어 있고, PK가 {학번} 이라면, 완전 함수적 종속성을 만족할 것이다.

2) 부분 함수적 종속성(Partial Functional Dependency)

부분 함수적 종속이란, 기본키의 일부 속성만으로 특정 속성을 결정할 수 있을 때 발생한다. 위의 예시처럼 PK는 {학번, 강의코드} 인데, {학번} 만으로 결정지을 수 있는 속성들이 존재하는 상황이다.

3) 이행적 함수적 종속성(Transitive Functional Dependency)

이행적 함수적 종속성이란,

• {A} -> {B}
• {B} -> {C}

의 FD가 존재할 때,

• {A} -> {C} 의 함수적 종속성이 발생하는 상황을 의미한다.

이러한 현상은 주로 PK에 포함되지 않은 일반 속성이 또 다른 일반 속성을 결정 지을 때 발생한다. (PK -> {A} -> {B})

위의 예시를 다시 살펴보면, {전화번호} -> {이름} 으로의 FD가 존재한다.

• {학번, 강의코드} -> {전화번호} -> {이름} 의 이행적 함수 종속이 존재하는 것이다.

데이터베이스 정규화(Normalization)

데이터베이스 정규화란 Good Form(정규형)을 정하고, 모든 테이블이 Good Form이 될 때까지 Lossless Decomposition(무손실 분해)을 반복적으로 수행하는 것을 의미한다.

Lossless Decomposition(무손실 분해)란, 분해된 테이블을 다시 조인했을 때, 데이터 손실이 없는 것을 의미한다.

무손실 분해의 조건 Relation R을 R1과 R2로 분해할 때, 아래 둘 중 하나의 조건을 만족해야한다.

• {R1 ∩ R2} -> R1
• {R1 ∩ R2} -> R2

이를 통해 불필요한 데이터의 중복을 줄이며, 이상현상을 방지할 수 있다.

제 1 정규형

• 컬럼이 원자값(Atomic Value, 하나의 값)을 갖도록 테이블을 분해하는 것이다.

제 2 정규형

• 제 1 정규형을 만족한 테이블에 대해 완전 함수 종속을 만족시킨다. 즉, 부분적 함수 종속을 제거한다.

제 3 정규형

• 제 2 정규형을 만족한 테이블에 대해 이행적 함수 종속을 제거한다. 즉, 기본키를 제외한 속성들 간의 함수적 종속성이 존재하면 안된다.

BCNF 정규형

• 제 3 정규형을 만족한 테이블에 대해 모든 결정자가 후보키 집합에 속해야 한다.
• 즉, 후보키 집합에 속하지 않은 일반 속성이 결정자가 되면 안된다.

CI/CD 과정

.github/workflows/deploy.yml

name: Deploy To EC2

on:
  push:
    branches:
      - main
      - dev

jobs:
  deploy:
    runs-on: ubuntu-latest
    env:
      APP_NAME: liveblog-server
    steps:
      - name: Github Repository 파일 불러오기
        uses: actions/checkout@v4

      - name: JDK 17버전 설치
        uses: actions/setup-java@v4
        with:
          distribution: temurin
          java-version: 17

      - name: application.yml 파일 만들기
        run: echo "${{ secrets.APPLICATION_PROPERTIES }}" > ./src/main/resources/application.yml

      - name: 테스트 및 빌드하기
        run: ./gradlew clean build

      - name: AWS Resource에 접근할 수 있게 AWS credentials 설정
        uses: aws-actions/configure-aws-credentials@v4
        with:
          aws-region: ap-northeast-2
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}

      - name: ECR에 로그인하기
        id: login-ecr
        uses: aws-actions/amazon-ecr-login@v2

      - name: Docker 이미지 생성
        run: docker build -t $APP_NAME .

      - name: Docker 이미지에 Tag 붙이기
        run: docker tag $APP_NAME ${{ steps.login-ecr.outputs.registry }}/$APP_NAME:latest

      - name: ECR에 Docker 이미지 Push하기
        run: docker push ${{ steps.login-ecr.outputs.registry }}/$APP_NAME:latest

      - name: SSH로 EC2에 접속하기
        uses: appleboy/ssh-action@v1.0.3
        with:
          host: ${{ secrets.EC2_HOST }}
          username: ${{ secrets.EC2_USERNAME }}
          key: ${{ secrets.EC2_PRIVATE_KEY }}
          script_stop: true
          script: |
            APP_NAME=${{ env.APP_NAME }}
            docker stop $APP_NAME || true
            docker rm $APP_NAME || true
            docker pull ${{ steps.login-ecr.outputs.registry }}/$APP_NAME:latest
            docker run -d --name $APP_NAME -p 80:8080 ${{ steps.login-ecr.outputs.registry }}/$APP_NAME:latest

대략적인 Flow는 다음과 같다.

1. Git Push

2. application.yml 파일을 GitHub Secrets에서 복사한다.

3. Docker 이미지를 생성한다. (docker build -t .)

   • 프로젝트 디렉토리 하위에 Dockerfile을 정의.

4. ECR에 Docker 이미지를 push

5. SSH로 EC2 접속, ECR에서 도커 이미지를 다운 후 동작

빌드 과정에서 application.yml을 GitHub Secrets에 저장한 후 복사해 사용하는 방식은 민감한 정보를 코드베이스에 노출하지 않아 보안을 강화할 수 있다.

에러 발생

SSH로 EC2 접속하기 부분에서
no basic auth credentials 에러가 지속적으로 발생하면서 실패하였다.

결과적으로 아래 3번 권한 설정이 누락되어 발생한 문제임을 깨닫고 해결하였다.

권한 설정

위 flow가 성공하려면 세가지 권한 설정이 필요하다.

1. Github Actions가 AWS ECR에 접근 가능해야한다. (이미지 푸시)

2. Github Actions가 EC2 인스턴스에 접근 가능해야한다. (SSH 접속)

3. EC2 인스턴스가 AWS ECR에 접근 가능해야한다. (이미지 다운)

3의 권한 설정이 필요한 이유는 ECR의 Private Repository에 이미지를 저장하는 방식을 선택했기 때문이다.

1. Github Actions -> AWS ECR

Github Actions가 내 AWS Resource에 접근하려면 적절하게 권한이 설정된 IAM 유저의 Access Key와 Secret Access Key가 필요하다.

Access Key는 유저를 식별하는 ID, Secret Access Key는 Password 같은 개념이다.

이를 위해 CI-CD 라는 이름의 User Group을 만들고, IAM User 하나를 생성해 연결하였다.

CI-CD 유저 그룹에는 AmazonEC2ContainerRegistryFullAccess(ECR) 정책을 설정한다.

name: AWS Resource에 접근할 수 있게 AWS credentials 설정
uses: aws-actions/configure-aws-credentials@v4
with:
    aws-region: ap-northeast-2
    aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
    aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}

name: ECR에 로그인하기
id: login-ecr
uses: aws-actions/amazon-ecr-login@v2

이렇게 생성한 유저의 Access Key, Secret Access Key를 통해 Github Actions에서 ECR에 로그인한다.

AWS는 관리 효율성, 일관성 보장, 보안 강화 측면에서 유저 그룹에 정책을 할당하고, 유저를 해당 그룹에 추가하는 방식을 사용하는 것을 강력히 권장한다.

2. Github Actions -> EC2 인스턴스

EC2 인스턴스는 .pem 키를 통한 SSH 방식으로 접속하기 때문에 따로 권한 설정이 필요하지 않다. 따라서 CI-CD 유저 그룹에도 EC2 인스턴스 관련 정책은 포함되지 않는다.

3. EC2 인스턴스 -> AWS ECR

EC2 인스턴스가 ECR의 Private Repository에 접근하려면 적절한 정책이 설정된 Role 을 부여해야한다.

EC2 인스턴스는 유저가 아니기 때문에 Role을 사용해야한다.

유저 그룹과 비슷하게 EC2-ECR 라는 Role을 만들고 AmazonEC2ContainerRegistryFullAccess 정책을 설정한다.

EC2 인스턴스에 생성한 Role을 부여한다.

또한 EC2 내부에서 amazon-ecr-credential-helper 설정을 추가적으로 해주어야한다.

참조 https://github.com/awslabs/amazon-ecr-credential-helper?tab=readme-ov-file

이제 EC2 에서 ECR의 Private Repository 로 접근이 가능하다.

문제 해결

앞서 언급한 no basic auth credentials 에러는 (3)의 권한을 제대로 부여하지 않아 생긴 문제였다.

EC2에 Role을 부여하니 해결되었다.

ECR - Life Cycle Policy

ECR에 Docker 이미지를 업로드하면, latest가 아닌 이전 버전의 이미지들이 지속적으로 남아있게된다.

ECR은 사용하는 용량만큼 요금이 청구되기 때문에 이를 주기적으로 삭제해야 한다.

Life Cycle Policy를 통해 자동으로 삭제가 가능하며,

untagged 이미지는 삭제하는 정책을 할당하였다.

정책을 할당해도 곧바로 삭제되지는 않았는데, 이는 AWS에서 주기적으로 처리하기 때문에 시간이 걸린다고 한다.

시간이 지나자 이전 버전의 이미지들이 자동으로 삭제되는 것을 확인할 수 있다!

게시글 참고: inpa.tistory.com - REDIS-📚-캐시Cache-설계-전략-지침-총정리

캐시는 일반적으로 메모리를 사용하기 때문에 데이터베이스 보다 훨씬 빠르게 응답이 가능하다.

하지만 캐시는 데이터 정합성 문제를 야기할 가능성이 있으며, 메모리가 상대적으로 비용이 높기 때문에 효율적인 캐시 설계 전략이 중요하다.

캐시 읽기 전략(Read Cache Strategy)

Look Aside 패턴

• 데이터를 찾을 때, 우선적으로 캐시를 확인하는 전략. 만일 캐시에 데이터가 없을 경우 DB에서 조회.

• 반복적인 읽기가 많은 호출에 적합하며, 원하는 데이터만 별도로 구성하여 캐시에 저장한다.

Look Aside 방식은 캐시에 문제가 발생하더라도, DB에 요청을 전달함으로써 서비스 문제는 대비할 수 있다. 하지만 캐시와 DB 간 정합성 문제가 발생할 수 있으며 초기 조회 시 무조건 DB를 호출해야 하므로 단건 호출 빈도가 높은 서비스에 적합하지 않다. 대신 반복적으로 동일 쿼리를 수행하는 서비스에 적합한 아키텍처이다.

Read Through 패턴

• 캐시에서만 데이터를 읽어오는 전략
• 데이터 동기화를 캐시에 위임하여 조회 속도가 느릴 수 있다.
• 캐시와 DB간 항상 데이터 동기화가 유지된다.

Look Aside 패턴과 유사하지만, 항상 캐시를 통해 데이터를 읽는 패턴이다. 캐시와 DB 간 데이터가 동기화 되지만, 캐시에 문제가 발생할 경우 서비스 전체에 장애가 발생할 수 있다. 그렇기 때문에 Replication 등을 활용해 고가용성을 구축하는 것이 중요하다.

캐시 쓰기 전략(Write Cache Strategy)

Write Back 패턴

• 데이터를 저장할때, DB가 아닌 캐시에 저장
• 캐시에서는 일정 주기 배치 작업을 통해 DB에 반영.
• 캐시에서 오류가 발생하면 데이터가 소실될 수 있음.

Write Back 방식은 데이터를 저장할때 DB가 아닌 먼저 캐시에 저장하여 모아놓았다가 특정 시점마다 DB로 쓰는 방식으로 캐시가 일종의 Queue 역할을 겸하게 된다.

캐시 읽기 전략인 Read-Through와 결합하면 가장 최근에 업데이트된 데이터를 항상 캐시에서 사용할 수 있는 혼합 워크로드에 적합하다.

Write Through 패턴

• 데이터베이스와 Cache에 동시에 데이터를 저장하는 전략
• 캐시와 DB의 데이터가 동기화 됨
• 매번 두 단계의 쓰기 과정을 거치기 때문에 상대적으로 느림.

write throuth 패턴과 write back 패턴 둘 다 모두 자주 사용되지 않는 데이터가 저장되어 리소스 낭비가 발생되는 문제점을 안고 있기 때문에, 이를 해결하기 위해 TTL을 꼭 사용하여 사용되지 않는 데이터를 반드시 삭제해야 한다. (expire 명령어)

Write Around 패턴

• 모든 데이터를 DB에 저장
• 캐시를 통한 쓰기 방식보다 훨씬 빠름
• 캐시와 DB의 데이터가 동기화 되지 않을 수 있다.

1000명이 동시에 채팅할 수 있는 Group-Chat 시스템을 설계해보자.

TPS = 1000 이라고 가정한다.

2. 설계

2-1 웹소켓 연결

1000명의 유저가 단 하나의 서버에 웹소켓을 연결하고 메시지를 주고받는다면, 서버 과부하가 발생할 수 있어 안정적인 서비스를 지원할 수 없다.

이를 해결하기 위해 유저와 웹소켓을 연결하는 Chat Server를 수평적으로 확장하고, 각 서버의 과부하를 모니터링하는 서버를 앞단에 두는 방식을 생각해보았다.

Flow는 다음과 같다.

1. 유저는 모니터링 서버에 웹소켓 연결이 가능한 서버 IP를 요청한다.

2. 모니터링 서버는 과부하가 적은 Chat Server의 IP를 반환한다.

3. 반환받은 IP로 웹소켓을 연결한다.

4. 웹소켓 연결 후 서버는 Key-Value 저장소에 연결정보를 저장한다.

로드밸런서를 통한 Proxy 방식은, 로드밸런서의 과부하가 발생할 수 있다고 판단하여 초기 연결에만 관여하는 모니터링 서버를 도입하는 방식을 생각해보았다.

또한 추후에 메시지를 보낼 때, 각 유저가 어떤 서버와 연결되어있는지 알아야 메시지를 보낼 수 있으므로 Key-Value 저장소에 연결정보를 저장한다.

메시지를 빠르게 보내려면 Redis와 같은 저장소를 쓰는 것이 좋을 것 같다.

2-2 메시지 발행

메시지 발행의 Flow는 다음과 같다.

1. 유저가 웹소켓으로 연결된 서버로 메시지를 보낸다.
2. 서버는 데이터베이스에 특정 채팅방에 속한 유저 아이디를 요청한다.
3. 응답받은 유저 아이디를 기반으로 Key-Value 저장소에 각 유저가 연결된 서버 IP를 요청한다.
4. 응답받은 서버 IP에 Relay 요청을 보낸다.
5. 각 서버는 연결된 유저에 메시지를 보낸다.

InnoDB는 MySQL의 스토리지 엔진 중 거의 유일하게 레코드 기반의 잠금을 제공하며, 그 때문에 높은 동시성 처리가 가능하고 안정적이며 성능이 뛰어나다.

InnoDB 아키텍처 및 특징

프라이머리 키에 의한 클러스터링

클러스터링이란 여러 개를 하나로 묶는다는 의미이다.

클러스터링 인덱스(키)는 인덱스(키) 값이 비슷한 레코드끼리 묶어서 저장하는 형태를 의미한다. (공간적 지역성)

InnoDB의 모든 테이블은 PK를 기준으로 클러스터링 되어 저장된다. 즉, PK 값에 의해 실제 레코드의 물리적 저장 위치가 결정된다.

반면, 세컨더리 키는 실제 레코드의 주소가 아닌 PK를 참조한다.

클러스터링 인덱스의 장단점

장점

• PK(클러스터링 키)로 검색할 때 처리 성능이 매우 빠름(특히, PK에 의한 범위 검색)

• 모든 세컨더리 인덱스가 PK를 가지고 있기 때문에, 인덱스 만으로 처리될 수 있는 경우가 많음. (커버링 인덱스)

단점

• PK 값이 클 경우, 모든 세컨더리 인덱스 저장 공간이 커짐

• 세컨더리 인덱스를 통해 검색할 때, PK 를 통해 다시 한 번 검색해야함

• INSERT 할 때, PK 값에 의해 레코드 저장 위치가 결정되므로 처리 성능이 느림

• PK 변경 시(잘 일어나진 않지만) 레코드를 DELETE 하고 INSERT 해야하므로 처리 성능이 느림

커버링 인덱스란, 인덱스만으로 필요한 데이터를 가져올 수 있는 인덱스를 의미한다. 만약 age에 인덱스가 걸려있고, age > 30 이상인 모든 유저의 PK를 알고 싶다면, InnoDB는 age 인덱스가 PK를 참조하므로 실제 데이터가 있는 테이블을 조회하지 않아도 된다.

클러스터링 인덱스의 장점은 빠른 읽기(SELECT)이며, 단점은 느린 쓰기(INSERT, UPDATE, DELETE)라는 것을 알 수 있다.

일반적인 웹 서비스는 읽기와 쓰기의 비율이 8:2 혹은 9:1 정도이기 때문에 *조금 느린 쓰기를 감수하고 읽기를 빠르게 유지하는 것이 좋다고 한다. *

InnoDB와 달리 MyISAM 엔진은 클러스터링 키를 지원하지 않으며, 모든 인덱스는 물리적인 레코드의 주소 값(ROWID)를 가진다.

외래 키(FK) 지원

MyISAM, MEMORY 스토리지 엔진과 달리 InnoDB는 외래 키를 지원한다.

외래 키는 부모와 자식 테이블 모두 해당 칼럼에 인덱스 생성이 필요하고, 변경 시 잠금이 여러 테이블로 전파되므로 데드락 발생을 유념해야 한다.

MVCC(Multi Version Concurrency Control)

MVCC는 레코드 레벨의 트랜잭션을 지원하는 DBMS가 제공하는 기능이며, 가장 큰 목적은 잠금을 사용하지 않는 일관된 읽기를 제공하는 것이다.

하나의 레코드에 대해 여러 버전이 동시에 관리되며, InnoDB는 InnoDB 버퍼풀과 Undo Log를 사용하여 이를 구현한다.

위와 같이 INSERT 문이 실행된 이후의 상황에서, 버퍼 풀에 있는 특정 레코드를 업데이트 한다면 어떻게 될까? (m_area 서울 -> 경기)

UPDATE가 실행되면, 커밋 여부와 관계없이 버퍼 풀의 데이터를 즉시 수정하고, 언두 로그에 변경 이전 값을 복사한다.

만약 커밋이 일어나기 전에 다른 트랜잭션에서 레코드를 조회하면, READ_UNCOMMITTED 격리 수준에서는 버퍼 풀에 있는 값을,

READ_COMMITTED, REPEATABLE_READ, SERIALIZABLE 에서는 아직 커밋되지 않았기 때문에, 변경 이전인 언두 로그에서 값을 읽어서 반환한다.

잠금 없는 일관된 읽기

트랜잭션 격리수준을 보장하기 위해 락을 활용하는 기법들이 있지만, 동시성 처리 성능이 떨어진다. InnoDB에서 READ_COMMITTED, REPEATABLE_READ 수준의 읽기 작업은 잠금을 대기하지 않고 곧바로 실행되기 때문에 동시 처리 성능이 뛰어나다.

InnoDB 버퍼 풀

이점

InnoDB 버퍼 풀은 디스크의 데이터 파일이나 인덱스 정보를 메모리에 캐시해 두는 공간이다. 쓰기 작업을 지연시켜 일괄 작업으로 처리할 수 있게 해주는 버퍼 역할도 같이 한다.

쓰기 작업의 지연은 어떤 이점을 가져올까?

Data Access Patterns

디스크에 저장된 데이터에 접근하는 패턴은 Random과 Sequential이 있다.

HDD와 같은 저장장치에서 Random Access는 데이터가 존재하는 위치로 헤더가 물리적으로 이동하는데 시간이 소모된다.

반면 Sequential Access는 마지막으로 헤더가 움직인 위치에 지속적으로 데이터를 쓰기 때문에, 헤더가 움직이는 물리적 시간이 소모되지 않는다.

System Design: Why is Kafka fast? 에 따르면 두 패턴은 성능에 엄청난 차이를 보인다.

일반적인 애플리케이션에서는 INSERT, UPDATE, DELETE 처럼 데이터를 변경하는 쿼리는 데이터 파일의 이곳저곳에 위치한 레코드를 변경하기 때문에 Random Access 작업을 발생시킨다.

InnoDB 버퍼 풀과 쓰기 지연을 통해 이러한 Random Access를 모아서 처리하면 그 횟수를 줄여 성능이 개선된다.

버퍼 풀과 리두 로그

파일 저장 방식의 문제점

데이터를 컴마로 구분된, 파일에 저장하면 어떤 문제점이 발생하는가? 그리고 이를 프로그래밍 언어를 통해 직접 파싱해서 다뤄야 한다면?

Data Integrity

• 만약 누군가가 year를 저장해야하는 곳에 Invalid String을 삽입하면?

• 도메인 무결성 X

• 하나의 앨범에 여러 아티스트가 존재하면?

• 파일의 구조를 변경해야하고, 작성한 코드는 더 이상 사용할 수 없다.

• 아티스트를 삭제한다면?

• 앨범 파일에서의 삭제 처리를 보장할 수 있는가?

• 동일한 아티스트가 여러 앨범을 만들었을 경우, 같은 아티스트임을 어떻게 보장할 수 있는가?

• 참조 무결성 X

Implementation

• 특정 레코드를 어떻게 찾을 것인가?

• 파일의 내용을 full-scan 해야만 한다.

• 같은 데이터베이스를 사용하는 애플리케이션을 하나 더 만든다면? 그리고 그것이 서로 다른 Machine 에서 작동한다면?

• 전체를 Copy, Paste?

• 서로 다른 스레드에서 동시에 파일에 접근한다면?

Durability

• 레코드를 업데이트하는 도중 프로그램이 멈추면?

• 트랜잭션 지원 X

• Replication 등을 활용해 고가용성을 지원할 수 있는가?

DBMS는 위와 같은 문제들을 해결하는 소프트웨어이다.

Data Models

Data Model은 데이터베이스에 데이터가 어떤 형식으로 저장되는지 묘사한 것.

Schema는 특정 Data Model을 기반으로 데이터의 형식을 표현한 것.

대부분의 DBMS는 관계형 모델이다.

Data Independence (데이터 독립성)

3단계 데이터 구조

• Physical Schema : 데이터의 물리적 저장구조를 정의한다

• Logical Schema : 데이터의 논리적 구조를 정의한다.

• External Schema : 뷰등 사용자 관점에서 데이터베이스를 바라보는 관점을 정의한다.

관계형 모델의 구조적 핵심은 데이터 독립성이다. 데이터베이스의 테이블과 내용을, 물리적인 저장 방식과 독립적으로 다루는 것이다.

DBMS를 사용하는 애플리케이션 개발자는 데이터가 물리적으로 어떻게 저장되는지 알 필요가 없다. 개발자는 오직 high-level의 애플리케이션 로직에만 집중하면 된다. (추상화)

그에 따라 물리적인 저장장치가 변경되어도, 애플리케이션의 코드가 변경될 필요가 없다.

• Physical Data Independence(물리적 데이터 독립성) : Physical Schema(데이터의 물리적 저장방식)가 변경되어도 Logical Schema에 영향을 주지않는다. 데이터베이스의 논리적 구조를 변경하지 않고도 저장 장치를 변경할 수 있다.

• Logical Data Independence(논리적 데이터 독립성) : Logical Schema(논리적 구조)가 변경되어도, External Schema(애플리케이션에서의 사용)에 영향을 주지 않는다. 애플리케이션의 코드를 변경하지 않고도 데이터베이스의 논리 구조를 변경할 수 있다.

Document Data Model

Document Data Model은 Object와 Relation의 불일치를 피하기 위해 등장했다. 객체와 데이터베이스를 강하게 결합하는 방식이다.

Relational 모델은 위와 같이 Artist와 Album 간의 관계를 맺고, ArtistAlbum 테이블을 생성하는 방식으로 데이터를 저장한다. 하지만 이러한 방식은 객체지향의 세계와 일치하지 않는다.

객체지향에서는 참조자를 통해 다른 객체를 포함하지만, 관계형 모델은 외래키를 통해 테이블을 조인해야만 한다.

조인에는 많은 비용이 소모되고, Document Model을 고안한 사람들은 이러한 조인 비용이 좋지않다고 생각했다(교수님 왈)

Document 모델은 객체지향에서 한 객체가 다른 객체를 포함하듯이, 데이터를 저장한다.

마치 Artist 객체가 Album 객체의 리스트를 포함하듯, Artist 내부에 Json Document 형식으로 데이터를 저장한다.

조인 비용이 소모되지 않으므로, 빠른 데이터 접근이 가능하다.

Document 모델의 문제점

하지만 이러한 방식은 어떤 문제점이 있을까?

• 데이터 중복 : 하나의 앨범이 여러 아티스트가 작업했다면? 각 아티스트마다 동일한 앨범정보가 포함될 것이다.

• 추상화 X : 내 애플리케이션이 데이터를 다루기 위해 데이터 구조를 잘 알아야한다. 즉, 추상화가 되지 않는다. 데이터 구조가 변경되면 애플리케이션 코드도 변경되어야 한다.

MySQL 서버는 크게 MySQL 엔진과 스토리지 엔진으로 구분할 수 있다.

MySQL 엔진은 사람의 머리와 같은 역할로, 쿼리를 최적화 하고 실행계획을 수립한다.

스토리지 엔진은 사람의 손발과 같은 역할로, 실제 데이터를 디스크 스토리지에 읽고 쓰는 역할을 맡는다.

스토리지 엔진은 핸들러 API를 만족하면 누구든지 구현해서 MySQL 서버에 추가해서 사용이 가능하다. 또한 여러 스토리지 엔진을 동시에 사용할 수 있으며, 테이블마다 다른 스토리지 엔진을 사용할 수 있다.

MySQL 엔진

MySQL 엔진은 클라이언트의 접속 및 쿼리 요청을 처리하는 커넥션 핸들러와 SQL 파서 및 전처리기, 최적화된 실행을 위한 옵티마이저가 중심을 이룬다.

• SQL 파서 : 들어온 SQL을 토큰으로 분리하여 트리 형태의 구조로 만들어낸다. 이 과정에서 기본 문법 오류들이 발견되고, 사용자에게 오류 메시지를 전달한다.

• 전처리기 : 파서 트리를 기반으로 구조적인 문제를 파악한다. 파싱된 각 토큰을 실제 객체와 매핑하고, 존재 여부와 접근 권한 등을 확인한다. 존재하지 않거나, 접근 권한이 없는 경우 이 단계에서 걸러진다.

• 옵티마이저 : DBMS의 두뇌라고 할 수 있는 옵티마이저는 사용자의 쿼리를 가장 저렴한 비용으로 가장 빠르게 처리할 수 있도록 변환하고, 실행 계획을 수립한다.

• 쿼리 실행기(실행 엔진) : 옵티마이저에 의해 만들어진 각 계획대로 스토리지 엔진(핸들러)에 직접 수행하는 역할을 한다. 실행 계획의 각 단계에서 만들어진 결과를 다음 단계의 입력으로 연결하는 역할을 수행한다.

스토리지 엔진(핸들러)

스토리지 엔진은 핸들러 API를 구현하며, 디스크에 읽고 쓰는 역할을 담당한다.

핸들러 API는 SHOW GLOBAL STATUS LIKE 'Handler%;'명령어로 확인이 가능하며, 얼마나 많은 데이터 작업이 있었는지 확인할 수 있다.

스토리지 엔진은 InnoDB, MyISAM, MEMORY 등이 있으며, 그 중 가장 많이 사용되는 엔진은 InnoDB 스토리지 엔진이다.

각 스토리지 엔진은 성능 향상을 위해 키 캐시(MyISAM)나 버퍼 풀(InnoDB)과 같은 기능을 내장하고 있다.

MySQL 스레딩 구조

MySQL 서버는 프로세스 기반이 아닌 스레드 기반으로 동작하며, 크게 포그라운드(Foreground) 스레드, 백그라운드(Background) 스레드로 구분할 수 있다.

MySQL 서버에서 실행 중인 스레드 목록은 performance_schema 데이터베이스의 threads 테이블을 통해 확인할 수 있다.

Foreground 스레드

포그라운드 스레드는 최소한 서버에 접속된 클라이언트의 수만큼 존재하며, 주로 각 클라이언트 사용자가 요청하는 쿼리 문장을 처리한다.

클라이언트가 MySQL에 접속하면 서버는 클라이언트의 요청을 처리해 줄 스레드를 생성해 그 클라이언트에게 할당한다.

포그라운드 스레드는 데이터를 MySQL의 데이터 버퍼나 캐시로부터 가져오며, 버퍼나 캐시에 없는 경우 직접 디스크의 데이터나 인덱스 파일로부터 데이터를 읽어와서 작업을 처리한다.

MyISAM 스토리지 엔진은 디스크 쓰기 작업까지 포그라운드 스레드가 처리하지만, InnoDB 스토리지 엔진은 데이터 버퍼나 캐시까지만 포그라운드 스레드가 처리하고, 나머지 버퍼로부터 디스크까지의 쓰기 작업은 백그라운드 스레드가 처리한다.

Spring-boot 웹 애플리케이션을 하나 띄웠을 때, 위와 같이 포그라운드 스레드가 10개 추가로 생성된 것을 확인할 수 있다.

그런데 왜 포그라운드 스레드가 10개나 생성된 것일까? 그 이유는 데이터베이스 커넥션 풀(Connection pool) 설정 때문이다.

HikariCP(Spring boot 기본 데이터베이스 커넥션 풀링 라이브러리)는 최대 성능을 보장하기 위해 초기화 시 미리 커넥션을 생성하고 유지하는데, 이 동작이 MySQL 서버에 연결된 활성 스레드 수를 증가시킨다.

애플리케이션 시작 시, 기본적으로 10개의 커넥션을 생성하여 풀에 보관하고, MySQL 서버는 이 10개의 커넥션을 유지하기 위해 10 개의 포그라운드 스레드를 생성하는 것이다.

즉, MySQL 서버는 기본적으로 1:1로 커넥션과 스레드를 매핑한다.

Spring boot의 데이터베이스 커넥션 풀 설정

spring:
  datasource:
    hikari:
      maximum-pool-size: 10 //최대 커넥션 수
      minimum-idle: 5 //최소 유휴 커넥션 수

위와 같이 커넥션 풀 설정이 가능하며, 이에 따라 MySQL 서버의 포그라운드 스레드 수도 달라진다.

애플리케이션 시작 시, minumum-idle 만큼 5개의 포그라운드 스레드만 생성된 것을 확인할 수 있다.

만약 애플리케이션이 동시에 5개의 커넥션을 모두 사용하면서 새로운 커넥션을 요청한다면, 최대 10개까지 커넥션을 새롭게 생성할 것이며, 그에따라 MySQL의 포그라운드 스레드 수도 늘어날 것이다.

백그라운드 스레드

InnoDB는 다음과 같이 여러 작업이 백그라운드로 처리된다.

• Insert Buffer를 병합하는 스레드
• 로그를 디스크로 기록하는 스레드
• InnoDB 버퍼 풀의 데이터를 디스크로 기록하는 스레드
• 데이터를 버퍼로 읽어 오는 스레드
• 잠금이나 데드락을 모니터링하는 스레드

InnoDB를 포함한 일반적인 상용 DBMS에는 대부분 쓰기 작업을 버퍼링해서 일괄 처리하는 기능이 탑재되어있다.

이러한 이유로 InnoDB에서는 INSERT, UPDATE, DELETE 쿼리로 데이터가 변경되는 경우 데이터가 디스크의 데이터 파일로 완전히 저장될 때까지 기다리지 않아도 된다. (이는 백그라운드 쓰기 스레드가 처리한다)

메모리 할당 및 사용 구조

MySQL에서 사용되는 메모리 공간은 크게 글로벌 메모리 영역과 로컬 메모리 영역으로 나뉜다.

글로벌 메모리 영역은 클라이언트 스레드의 수와 무관하게 하나의 메모리 공간만 할당되고, 모든 스레드에 의해 공유된다.

로컬(세션) 메모리 영역은 클라이언트 스레드가 쿼리를 처리하는 데 사용되는 영역이다.

플러그인 스토리지 엔진 모델

플러그인 모델

MySQL의 독특한 구조 중 대표적인 것은 플러그인 모델이다.

각 스토리지 엔진을 플러그인의 형태로 사용할 수 있으며 뿐만 아니라 검색 엔진을 위한 검색어 파서, 인증 기능도 모두 플러그인으로 구현되어 제공된다.

사용자가 직접 스토리지 엔진 플러그인을 개발하더라도, 사람의 머리 역할을 하는 MySQL 엔진은 그대로 동작한다. 따라서 이는 DBMS 전체 기능이 아닌 일부분의 기능만 수행하는 엔진을 작성하는 것이다.

컴포넌트

MySQL 8.0 부터는 기존의 플러그인 아키텍처를 대체하기 위해 컴포넌트 아키텍처가 지원된다.

플러그인의 단점은 다음과 같다.

• 플러그인은 오직 MySQL 서버와 인터페이스할 수 있고, 플러그인끼리는 통신 불가
• 플러그인은 MySQL의 서버 변수나 함수를 직접 호출하기 때문에 안전하지 않음(캡슐화 안됨)
• 플러그인은 상호 의존관계를 설정할 수 없어서 초기화 어려움

컴포넌트는 이러한 단점들을 보완해서 구현되었다.

@Service
@RequiredArgsConstructor
public class RegisterUserService implements RegisterUserUseCase {

    private final UserRepository userRepository;

    @Override
    @Transactional
    public void register(RegisterCommand command) {
        if(userRepository.existsByUsername(command.getUsername())) {
            throw new DuplicateUsernameException(ErrorCode.DUPLICATE_USERNAME, "이미 존재하는 유저 이름입니다.");
        } //이름이 같은 유저가 존재할 경우, 예외를 던진다.

        User user = new User(command.getUsername(), command.getPassword());

        userRepository.save(user);
    }
}

회원가입을 처리하는 RegisterUserService 구현체이다.

회원가입 로직은, 중복된 유저 이름이 발생하지 않도록 하기 위해

1. 데이터베이스에 같은 이름이 존재하는지 확인한다.
2. 존재한다면, 예외를 발생시킨다. 이 예외는 @ControllerAdvice에서 캐치되어 클라이언트에게 에러 응답을 내려준다.
3. 존재하지 않는다면, 데이터베이스에 저장한다.

간단해보이는 이 코드는 의도대로 중복된 이름의 회원가입을 방지하며 제대로 동작할까?

JMeter를 통해 10개의 스레드로 동시요청을 보내보았다.

의도대로라면, 10개의 동일한 요청 중 첫번째 요청만 성공하고 나머지는 실패해야하지만,

위와 같이 10개 중 3개의 요청이 성공하는 것을 확인할 수 있다.

원인

@Override
@Transactional
public void register(RegisterCommand command) {
    if(userRepository.existsByUsername(command.getUsername())) {
        throw new DuplicateUsernameException(ErrorCode.DUPLICATE_USERNAME, "이미 존재하는 유저 이름입니다.");
    }
    /**
     이 지점에 여러 스레드가 동시에 진입할 수 있다.
    */
    User user = new User(command.getUsername(), command.getPassword());

    userRepository.save(user);
}

문제의 원인은 첫번째 userRepository.save(user) 가 호출되기 이전에, 동시에 여러 스레드에서 userRepository.existsByUsername() 조건문을 통과할 가능성이 있다는 점이다.

부끄럽지만 지금까지 @Transactional 어노테이션이 동시성 문제를 해결해준다고 생각했다. (ACID 중 Isolation 특성이, 한 트랜잭션에서 메서드를 호출하면 다른 트랜잭션이 호출할 수 없게 '고립' 시킨다고 생각했다라나 뭐라나..)

해결방안

엔티티의 unique 제약조건

@Entity
public class User {
    //...

    @Column(nullable = false, unique = true)
    private String username;
}

위와 같이 Entity의 username 컬럼에 unique constraint를 걸어준다. 그러면 여러 스레드가 동시에 조건문을 통과하더라도, 데이터베이스에 저장하는 시점에 제약조건에 의해 단 하나의 스레드만 성공하게 된다.

테스트 결과, 단 하나의 요청만 OK 응답을 받았다.

하지만 위와 같이 실패 응답의 status code가 서로 다른 문제가 발생한다.

이는 여전히 일부 스레드는 조건문을 통과하여 핸들링하지 않은 예외(유니크 제약조건을 위반할 시)를 발생시키기 때문이다.

사실 unique 제약 조건을 건 순간, 앞단의 조건문은 의미가 없다. 따라서 코드를 다음과 같이 개선하였다.

@Service
@RequiredArgsConstructor
public class RegisterUserService implements RegisterUserUseCase {

    private final UserRepository userRepository;

    @Override
    @Transactional
    public void register(RegisterCommand command) {
        try {
            userRepository.save(
                    new User(command.getUsername(), command.getPassword())
            );
        } catch (DataIntegrityViolationException e) {
            throw new DuplicateUsernameException(ErrorCode.DUPLICATE_USERNAME, "이미 존재하는 유저 이름입니다.");
        }
    }
}

곧바로 데이터베이스에 저장 쿼리를 날리고, 유니크 제약조건 위반 예외가 발생하면, 애플리케이션의 예외로 변환하는 방식이다.

그렇게 다시 한 번 테스트를 시도했는데..

또 다른 문제

엥? 어째서인지 예외가 캐치되지 않고, 콘솔에 그대로 스택 트레이스가 출력되었다.

DataIntegrityViolationException 이 아닌가? 싶어서 Exception 으로 바꿔서 모든 예외를 캐치하도록 했음에도, 여전히 콘솔에 스택 트레이스가 출력되었다.

원인

ChatGPT에게 이유를 물어보았고 여러 답변이 나왔다. 그 중 위 답변을 보며 JPA의 영속성 컨텍스트(Persistence Context)를 떠올리게 되었다.

@Transactional 어노테이션을 통해 영속성 컨텍스트(캐시) 내에서 작업이 이루어지게 되고, 실제 DB에 쿼리가 날아가는 flush()가 호출되는 시점은 트랜잭션이 종료되는 시점이다.

@Override
@Transactional
public void register(RegisterCommand command) {
    try {
        userRepository.save(
                new User(command.getUsername(), command.getPassword())
        ); //여기서 실제 DB에 쿼리를 날리지 않는다. 
    } catch (DataIntegrityViolationException e) {
        throw new DuplicateUsernameException(ErrorCode.DUPLICATE_USERNAME, "이미 존재하는 유저 이름입니다.");
    }

    //여기서 DB에 쿼리가 날아간다. 따라서 예외가 캐치되지 않는다.
}

userRepository.save() 를 하는 것은 엔티티를 persist 상태로 만드는 행위이며 이는, 엔티티 매니저에의해 관리되는 영속 상태를 만드는 것을 의미한다.

따라서 이 시점에는 DB에 쿼리를 날리지 않아, 유니크 제약조건 위반이 확인되지 않는다.

개선

@Override
@Transactional
public void register(RegisterCommand command) {
    try {
        userRepository.save(
                new User(command.getUsername(), command.getPassword())
        );
        userRepository.flush(); //try-catch 문 내부에서 flush()를 진행
    } catch (DataIntegrityViolationException e) {
        throw new DuplicateUsernameException(ErrorCode.DUPLICATE_USERNAME, "이미 존재하는 유저 이름입니다.");
    }
}

위와 같이 try-catch문 내부에서 곧바로 flush()를 호출하는 방식으로 수정하였다.

콘솔에 스택 트레이스가 출력되지 않고, 유니크 제약조건 위반 예외가 애플리케이션의 예외로 변환되어 제대로 핸들링 된 것을 확인할 수 있다!

역할과 책임

의문점

해결은 했으나 아직 여러 의문이 들었다.

이렇게 엔티티의 unique constraint를 통해 해결하는 것이 과연 적절할까?

'중복된 username은 허용하지 않는다' 는 것은 비즈니스의 규칙이다. 따라서 도메인 레이어(서비스)에서 이를 다룰 책임이 있다고 생각한다.

@Override
@Transactional
public void register(RegisterCommand command) {
    try {
        userRepository.save(
                new User(command.getUsername(), command.getPassword())
        );
        userRepository.flush();
    } catch (DataIntegrityViolationException e) {
        throw new DuplicateUsernameException(ErrorCode.DUPLICATE_USERNAME, "이미 존재하는 유저 이름입니다.");
    }
}

위 코드는 '중복된 username은 허용하지 않는다'는 비즈니스 규칙이 잘 드러나는가? (애플리케이션 예외로 변환하면서 잘 드러나는 것 같기도 하고)

unique 제약조건을 통해 해결하는 것은, 도메인 레이어의 책임을 영속성 레이어로 전가하는 것은 아닌가?

트레이드 오프

다시 ChatGPT에게 물었다. 일리가 있는 주장이나, 트레이드 오프이므로 장단점을 잘 파악해야한다는 답변을 주었다.

문제가 있던 기존 코드는 확실히 비즈니스 규칙이 잘 드러난다. -> 하지만 동시성 문제가 발생한다.

유니크 제약 조건을 사용하여 경쟁상태를 원천적으로 차단하였다. 이를 통해 중복 이메일 확인 조건도 삭제할 수 있었다. -> 코드 중복이 줄고, 중복 방지 로직을 쉽게 구현할 수 있었다. -> 하지만 비즈니스 로직과 데이터베이스 설계가 결합되었다. -> 비즈니스 규칙의 변경이 필요할 경우, 데이터베이스 설계를 수정해야한다.

정답은 없는 것 같다. 어떤 선택에든 트레이드 오프가 따르기 마련이다.

비즈니스 규칙이 변경될 가능성이 극히 적은데도, 변경에 열려있는 설계를 하기 위해 너무 많이 고민하는 것은 오버 엔지니어링이 아닐까 싶다.

타입과 함수

타입

타입은 집합이다. boolean, int 같은 원시타입(Primitive Type) 외에도 구조체, 클래스, Enum 등도 모두 타입에 해당한다. ex) Boolean = {False, True}

Integer = {... -1, 0, 1, ...}

Double = {... 0.9, 0.99, 1.0 ...}

함수

f : X → Y

함수는 두 집합을 연결하여 관계를 만들어주는 연산이다.

수학에서의 함수는 순수함수이다.

순수함수의 특징은 다음과 같다.

1. 동일한 인자가 주어졌을 때, 항상 동일한 결과를 반환한다.
2. 순수함수 f : X → Y 는 집합 X의 원소를 함수 f에 대입하면 집합 Y의 원소가 나오는 성질이 항상 유지된다.

객체지향 프로그래밍의 메서드는 일반적으로 순수함수일까?

객체지향 세계에서 각 객체들은 상태(state)와 행위(behavior)를 가진다. 그리고 객체의 행위는 상태에 영향을 받는다.

아래 예제를 보자.

class MyClass {
    int factor = 1;

    public int calc(int val) {
        return val + this.factor;
    }
}

calc() 메서드의 반환값은 외부요소인 factor에 의존적이다. 만약 factor의 값이 변하면, 동일한 입력에 대해 다른 출력값을 반환한다. 따라서 이는 순수함수가 아니다.

public int div(int a, int b) {
    return a / b;
}

그렇다면 위와 같은 div() 메서드는 어떨까? 의존하는 외부요소가 없으므로 순수함수라 생각할 수 있다.

하지만 만약 b가 0이라면, java.lang.ArithmeticException 이 발생한다.

int 집합 → int 집합 의 관계가 항상 보장되지 않으므로 순수함수가 아닌 것이다.

함수 외부 요소에 의존하지 않더라도, 결과 집합 이외의 집합값을 발생시키면 순수함수가 아니다.

함수의 합성과 사이드이펙트

함수 f : X → Y, g : Y → Z 일 때,

두 함수의 합성은 g ∘ f : X → Z 이다.

프로그래밍 세계에서도 합성이 존재한다. 예를 들어 인터넷에서 사이트를 옮겨 다니게 하는 링크는 함수이다. 링크를 계속 클릭하여 웹을 탐방하는 것은 함수의 합성으로 생각할 수 있다.

link : site → site web : link ∘ link ∘ link ...∘ link

함수의 합성 덕분에 우리는 커다란 문제를 작은 문제들로 쪼개어 풀 수 있다.

하지만 그것이 항상 성공하지는 않는다. 왜냐하면, 사이드이펙트(Side Effect) 때문이다.

사이드이펙트는 어떤 함수가 존재할 때, 이 함수가 순수함수가 될 수 없게 만드는 모든 것을 의미한다.

사이드이펙트가 존재하여 순수함수성이 깨지면, 함수의 합성은 더 이상 진행될 수 없다.

• 우리가 작성한 프로그램은 커다란 문제를 작은 문제들로 쪼개어 해결하는 함수의 합성이다.

• 사이드 이펙트가 존재하면 함수의 합성이 실패할 수 있다.

Monad

Monad는 일종의 디자인 패턴으로써, 결과값 집합과 오류값 집합을 하나의 집합으로 만든 것이다.

함수의 실행 결과를 모나드로 반환한다면, 순수함수의 성질을 잃지 않을 수 있다. 순수함수의 성질을 잃지 않기 때문에, 함수의 합성을 지속적으로 이어나갈 수 있다.

간단한 모나드의 예제를 보자.

public abstract class Result<T> {
    public static class Success<T> extends Result<T> {
        T value;

        public Success(T value) {
            this.value = value;
        }
    }
    public static class Fail<T> extends Result<T> {

    }
}

Result<T> 모나드를 도입하고 {Success, Fail} 집합을 포함한다. 함수 내부 연산에서 사이드 이펙트가 발생하면, Fail을 반환한다.

public int div(int a, int b) {
    return a / b;
} // b가 0일 때 사이드 이펙트가 발생한다.

public Result<Integer> div(int a, int b) {
    try {
        return new Result.Success<>(a / b);
    } catch (Throwable e) {
        return new Result.Fail<>();
    }
}

div()의 반환값을 모나드로 변경한다.

var a = div(10, 0);

if(a instanceof Result.Success<Integer>) {
    //...
} else if(a instanceof Result.Fail<Integer>) {
    //...
}

위와 같이 사용한다면, div의 두 번째 매개변수로 0이 입력되더라도, 에러가 발생하지 않는다.

Map과 FlatMap

모나드에는 Map과 FlatMap 기능이 존재한다.

Map은 구체타입 -> 구체타입으로 변환하는 함수를 입력받고, 모나드를 반환한다.

FlatMap은 구체타입 -> 모나드로 변환하는 함수를 입력받고, 모나드를 반환한다.

Optional<Integer> len1 = Optional.of("Hello")
                .map(s -> s.length());


Optional<Integer> len2 = Optional.of("Hello")
                .flatMap(s -> Optional.of(s.length()));

위와 같이 map() 에는 구체타입을 반환하는 람다식이, flatMap()에는 Optional<>을 반환하는 람다식이 들어가는 것을 알 수 있다.

두 함수의 반환값은 모두 Optional<>로 모나드를 반환한다.

즉 map, flatMap을 사용해서 메서드 체이닝이 가능하며, 모나드 패턴을 적용하여 체이닝의 중간 단계에서 실패하지 않는다.

Optional.map()의 구현 코드를 보면 값이 존재하지 않을 때, mapper 함수를 적용하지 않고, Optional.empty()를 반환하는 것을 볼 수 있다.

2019 카카오 개발자 겨울 인턴십 - 불량 사용자

내 정답 코드

import java.util.*;

class Solution {
    boolean[] visited;
    List<Integer>[] cases;
    Set<String> answerSet = new HashSet<>();

    void dfs(int idx) {
        if(idx == cases.length) {
            StringBuilder sb = new StringBuilder();
            for(int i = 0; i < visited.length; i++) {
                if(visited[i]) sb.append(i);
            }
            answerSet.add(sb.toString());
            return;
        }

        List<Integer> possibles = cases[idx];

        for(int p : possibles) {
            if(visited[p]) continue;

            visited[p] = true;
            dfs(idx + 1);
            visited[p] = false;
        }
    }

    boolean isMatched(String a, String b) {
        if(a.length() != b.length()) return false;
        for(int i = 0; i < a.length(); i++) {
            if(a.charAt(i) == '*' || b.charAt(i) == '*') continue;
            if(a.charAt(i) != b.charAt(i)) return false;
        }
        return true;
    }

    public int solution(String[] user_id, String[] banned_id) {
        visited = new boolean[user_id.length];
        cases = new List[banned_id.length];

        for(int i = 0; i < banned_id.length; i++) {
            cases[i] = new ArrayList<>();
            for(int j = 0; j < user_id.length; j++) {
                if(isMatched(banned_id[i], user_id[j])) {
                    cases[i].add(j);
                }
            }
        }

        dfs(0);

        return answerSet.size();
    }
}

matches(String regex)

문제에서는 user_id 와 문자열의 일부가 '*'로 이루어진 banned_id가 매칭되는지를 파악해야한다.

boolean isMatched(String a, String b) {
        if(a.length() != b.length()) return false;
        for(int i = 0; i < a.length(); i++) {
            if(a.charAt(i) == '*' || b.charAt(i) == '*') continue;
            if(a.charAt(i) != b.charAt(i)) return false;
        }
        return true;
    }

나는 위와 같이 일일이 파악하였으나(ㅎㅎ;) 풀고나서 다른 사람의 풀이를 보다가 String 클래스에서 제공하는 matches 메서드를 알게되었다.

matches()는 문자열을 정규표현식과 매칭되는지 파악해주는 유용한 함수이다

String reg = banned_id.replace("*", "[\\w]") 
if(user_id.matches(reg)) {
    ///매칭되는경우
}

banned_id에서 *를 전부 [\\w] 로 변경한 Regular Expression에 대해 matches() 메서드를 호출하면 쉽게 파악할 수 있다!

\w: 알파벳(a-z, A-Z), 숫자(0-9), 밑줄(_)을 포함합니다. \d: 숫자(0-9)를 포함합니다.

스레드는 Unit of Execution으로 불리며, CPU 코어의 실행단위이다. 즉, 하나의 프로세스에서 두 개 이상의 스레드를 사용함으로써 두 가지 이상의 작업을 동시에 실행할 수 있다.

하지만 단순히 Thread만 사용해서 동시에 여러 작업을 처리하는 프로그램을 만든다면 문제가 발생한다.

만약 작업 요청이 들어올때마다 스레드를 생성하여 처리한다면 어떤 문제가 발생할까?

스레드 생성비용 문제

Java의 경우 One-To-One Threading 모델로 스레드를 생성한다.

즉, User Thread 생성 시, OS Thread와 연결해야하며, 이는 새로운 스레드를 생성할 때마다 오버헤드가 크게 발생함을 의미한다.

작업 요청에 대해 매번 새롭게 스레드를 생성하여 처리한다면, 결과적으로 최종적인 요청 처리시간이 증가하는 문제가 발생한다.

과도한 스레드 생성 문제

만약 프로세스의 요청 처리 속도보다 더 빠른 속도로 요청이 들어온다면 어떻게 될까?

새로운 스레드가 무제한적으로 계속 생성되며, 스레드가 많아질 수록 메모리를 차지하고, Context-Switching이 더 자주 발생한다.

또한 CPU 자원을 경합하는 경우가 발생할 수 있으며, 이는 하나 이상의 스레드가 데이터를 기록하려고 할 때 다른 스레드가 해당 데이터를 읽으려고 하는 경우이다.

이에 따라 메모리 문제가 발생할 수 있고, CPU 오버헤드가 증가한다.

Thread Pool

이러한 문제를 해결하기 위해 Thread Pool(스레드풀)을 사용한다. 스레드풀은 스레드를 허용된 수 만큼만 사용하도록 제한하는 시스템이다.

스레드풀의 기본 플로우는 다음과 같다.

1. 처음에는 core size만큼의 스레드를 생성한다.

2. 유저 요청(Connection)이 들어올때마다 작업 큐에 담는다.

3. 유휴상태(idle)인 스레드가 있다면 작업 큐에서 작업을 꺼내 스레드에 작업을 할당하여 처리한다.

4. 1 만약 유휴상태인 스레드가 없다면 작업은 작업 큐에서 대기한다.

5. 2 작업 큐가 가득 차면 스레드를 생성한다.

6. 3 max size 만큼의 스레드가 존재하고, 작업 큐도 가득차면 connection-refused 오류를 반환한다.

7. 작업이 완료되면 스레드는 다시 유휴상태로 돌아간다.

위와 같은 방식으로 생성될 수 있는 스레드의 개수를 제한하고, 한 번 생성된 스레드를 없애지 않고 재사용함으로써, 스레드 생성에 따른 오버헤드를 없앨 수 있다.

즉, 여러 개의 작업을 동시에 처리하면서도 안정적으로 처리하고 싶을 때 Thread Pool은 효과적이다.

Web Server

웹서버의 특성 상 동시에 여러 요청을 처리해야하며, 앞서 설명한 Thread Pool을 사용하기 매우 적합하다.

Tomcat

Tomcat은 Spring Boot의 내장 Servlet Container 중 하나이며, Java 기반의 WAS이며, Java의 Thread Pool과 매우 유사한 자체 스레드풀 구현체를 가지고 있다.

톰캣의 스레드풀에서는 두 가지 추가적인 요소가 존재한다.

1. Max-Connections : 톰캣이 최대로 동시에 처리할 수 있는 Connection의 개수를 의미한다. Web 요청이 들어오면 톰캣의 Connector가 Connection을 생성하면서 요청된 작업을 ThreadPool의 Thread와 연결한다.

2. Accept-Count : Max-Connections 이상의 요청이 들어왔을때 사용하는 대기열 Queue 사이즈이다. 이 대기열이 꽉 찼을때 들어오는 요청은 거절될 수 있다.

톰캣의 스레드풀 관련 설정은 application.yml 혹은 application.properties 같은 설정파일을 통해 가능하다.

server:
  tomcat:
    threads:
      max: 200
      min-spare: 10
    max-connections: 8192
    accept-count: 100 # Task queue size
    connection-timeout: 20000

위 설정을 하나하나 살펴보자면,

• max : Thread Pool에 생성될 수 있는 스레드의 최대 개수를 의미한다. 기본값은 200이다.

• min-spare : 최소한으로 유지할 스레드의 수를 의미한다.

• max-connections : 한 번에 처리할 수 있는 최대 연결 수이며, 이는 Keep-Alive 상태도 포함한다. 기본값은 8192이다. 사실 상 서버의 실질적인 동시요청 처리 개수라고도 생각할 수 있다.

• accept-count : max-connections를 초과하는 요청이 들어올때 대기할 수 있는 최대 수. 기본 값은 100이다. 너무 작게 설정한다면, 요청이 몰렸을 때 들어오는 요청들을 모두 거절할 수도 있다.

Tomcat 8 버전 이후부터는 Non-Blocking I/O 방식을 채택하여, 기존의 1 connection - 1 thread 방식에서 벗어나 N connection - 1 thread 방식으로 전환되었다. 이를 통해 하나의 스레드가 여러 연결의 작업을 관리할 수 있어, 더 적은 스레드로도 높은 동시성을 처리할 수 있다.

따라서 Non-Blocking I/O 방식의 최신 버전 톰캣을 사용한다면, 최대 스레드의 개수보다 적거나 같은 수의 max-connections를 설정하는 것은 비효율적이라고 한다.

Thread Pool의 설정들은 TPS와 요청에 대한 응답시간을 결정하는 하나의 요소이며, 이러한 설정들이 적절하지 않다면, 병목현상 및 CPU 오버헤드와 메모리 문제를 유발할 수 있다.

프로세스

프로세스는 실행중인 프로그램이며, 운영체제로부터 독립된 메모리 공간을 할당받는다. 메모리 공간은 Code/Data/Heap/Stack 영역으로 이루어져있다.

• Code 영역은 read-only로, 실행할 프로그램의 기계어 코드가 저장된다.
• Data 영역은 전역변수, 정적변수 등이 저장된다.
• Heap 영역은 동적으로 할당된 구역으로 객체, 배열 등이 저장된다. Java의 new, C의 malloc 키워드 등이 해당된다.
• Stack 영역은 각각의 함수 호출의 지역변수, 매개변수, 리턴주소 값 등이 저장된다.

프로세스는 운영체제의 CPU 스케줄링의 대상이며, 컨텍스트 스위칭(Context Switching)을 통해 여러 프로세스가 CPU를 번갈아 사용한다.

컨텍스트 스위칭은 CPU가 하나의 프로세스에서 다른 프로세스로 전환될 때, 이전 프로세스의 레지스터 값, 프로그램 카운터(PC), 스택 포인터 등의 상태를 저장하고, 새로운 프로세스의 상태를 복원하는 작업을 말한다. 컨텍스트 스위칭은 오버헤드가 발생하므로, 적절한 스케줄링 알고리즘이 필요하다.

또한 프로세스는 각각 독립된 메모리 공간을 가지기 때문에, 데이터를 주고 받기 위해 IPC(Inter-Process-Communication) 기법을 사용해야한다.

IPC에는 다음과 같은 방식들이 존재한다.

• Message Queue : 운영체제가 관리하는 큐를 통해 프로세스 간 데이터를 교환하는 방식. 프로세스는 큐에 메시지를 쓰거나 읽어서 데이터를 주고받는다.

• Shared Memory : 두 프로세스가 동일한 메모리 영역을 공유하여 데이터를 주고받는 방식

• Socket : 네트워크 통신에서 주로 사용되는 소켓은, 같은 호스트의 프로세스 간 통신에도 사용할 수 있다.

스레드

스레드는 하나의 프로세스 내에서 동시에 진행되는 실행 흐름의 단위이다. 각각의 스레드는 독립된 Stack 영역과 레지스터 값을 보유하며, Code, Data, Heap 영역을 공유한다.

스레드간의 메모리를 공유하기 때문에, 프로세스간 통신(IPC)보다 오버헤드가 적다.

다만, 공유 자원 문제로 인해 경쟁 상태, 데이터 불일치 등의 문제가 발생할 수 있다.

공유 자원 문제란, 여러 스레드가 동시에 하나의 자원에 접근하거나 수정할 때 발생하는 문제로, 예상치 못한 동작이나 데이터 손상을 초래할 수 있는 상황을 말한다.

이러한 문제를 방지하기 위해 적절한 동기화 메커니즘을 사용하는 것이 중요하다.

크롬 브라우저

크롬 브라우저에서는 각각의 페이지마다 탭이 존재하여 손쉽게 전환이 가능하다. 웹페이지 화면을 렌더링하는 각각의 탭을 직접 구현한다면, 프로세스와 스레드를 어떻게 활용해야할까?

하나의 프로세스에서 여러 스레드를 생성하여 모든 탭을 관리하는 구조, 혹은 각 탭을 독립된 프로세스로 생성하는 구조로 설계할 수 있을 것이다.

각각의 장단점을 비교해보자.

하나의 프로세스 + 여러 스레드(탭) 구조

장점

• 메모리 효율성 : 모든 스레드가 Code, Data, Heap 영역을 공유하므로 각 탭마다 프로세스 전체 메모리 공간을 할당하는 방식보다 사용량이 적다.

• 빠른 통신 : 공유메모리를 통한 스레드 간의 통신은 IPC에 비해 훨씬 빠르다.

단점

• 안정성 저하 : 만약 하나의 스레드에 문제가 발생하면, 다른 스레드도 제대로 동작하지 않을 수 있다.

• 병목현상 : 공유 자원에 접근할 때 동기화 문제가 발생할 수 있으며, 이를 해결하기 위해 락을 많이 사용하면 성능이 저하될 수 있다.

각 탭별 독립된 프로세스 구조

장점

• 안정성 : 각 탭이 독립된 프로세스에서 실행되므로, 한 탭에서 문제가 발생해도 다른 탭이나 브라우저 전체에 영향을 미치지 않습니다.

단점

• 높은 메모리 사용량 : 각 탭이 독립된 메모리 공간을 가지기 때문에 메모리 사용량이 증가합니다.

• 복잡한 통신 : 프로세스 간 통신은 IPC를 사용해야 하므로, 스레드 간 통신에 비해 구현이 복잡하고, 성능이 낮을 수 있다.

  
  

하나의 스레드에 문제가 발생하면, 다른 스레드가 제대로 동작하지 않는 이유는 무엇일까? 하나의 스레드가 다른 스레드에 어떤 문제들을 발생 시킬 수 있는 것인가?

앞서 보앗듯, 스레드끼리는 Code, Data, Heap 영역을 공유하는데, Heap 영역은 프로세스 실행 도중 동적으로 크기가 변하는 영역이다. 만약 하나의 스레드가 이를 과도하게 할당하여 사용한다면? -> 메모리 부족 에러가 발생하여 다른 스레드가 더 이상 메모리를 사용할 수 없게 될 것이다.

또 만약 하나의 스레드가 특정 공유자원에 대한 락을 점유한 상태로 무한루프에 빠지거나 과도한 연산을 요청하여 응답하지 않는다면? -> 이를 획득해야하는 다른 스레드는 데드락 상태에 빠지고 무한 대기 상태에 빠질 수 있다.

이와 같은 이유로 하나의 프로세스 + 여러 스레드 구조에서는 하나의 스레드(탭)가 트롤짓을 한다면 전체 스레드(전체 탭)에 문제가 생길 가능성이 있다.

그렇다면 하나의 탭이 문제를 일으킬 가능성을 따져봐야한다.

웹서버가 제공한 HTML, CSS, JavaScript 코드는 브라우저 내에서 실행되며, 이 코드는 웹 개발자가 작성한 로직에 따라 동작하므로 브라우저 입장에서는 실행 결과를 예측할 수 없다.

특히, JavaScript는 클라이언트 측에서 실행되며, 무한 루프, 과도한 메모리 사용, 대규모 이벤트 처리 등 의도치 않은 동작(트롤짓)을 유발할 가능성이 있다.

특정 웹페이지의 동작 방식을 사전에 예측할 수 없기 때문에, 하나의 프로세스가 여러 탭을 관리하는 구조는 안정성 측면에서 매우 취약하다.

따라서 각각의 탭을 렌더링하는 기능은 다중 프로세서로 설계하는 것이 적합하다고 생각한다.

크롬 브라우저 아키텍처

실제로 크롬 브라우저 아키텍처는 위와 같은 구조로 되어있다고 한다.

각각의 탭을 렌더링하는 '렌더러 프로세스' 외에도 '브라우저 프로세스', '플러그인 프로세스', 'GPU 프로세서' 등이 함께 동작한다.

다만 사진에서 볼 수 있듯, 렌더러 프로세스는 탭별로 프로세스를 할당하는 구조로 되어있다.

한 탭이 응답하지 않더라도 다른 탭은 사용 가능하다는 점은 각 탭마다 독립적인 렌더러 프로세스를 유지했을 때의 이점이다. 웹 페이지에서 처리할 작업이 많아 응답하지 못하는 경우나 웹 페이지를 담당하던 렌더러 프로세스의 실행이 중단된 경우 등에 이런 이점을 확인할 수 있다.

안정성 확보 측면 외에도 보안과 격리(sandbox)의 이점도 있다고한다. 운영체제를 통해 각각의 프로세스의 권한을 제한한다면, 특정 프로세스가 특정 기능을 사용할 수 없게 제한할 수 있다.

예를 들어, 웹서버의 코드가 실행되는 렌더러 프로세스와, 쿠키를 저장하고 관리하는 스토리지 프로세스(Storage Process)가 분리되어 있음으로써 보안과 안정성을 강화할 수 있다.

이러한 구조에서는 렌더러 프로세스에서 실행되는 예측 불가능한 코드가 쿠키와 같은 민감한 데이터에 직접 접근하지 못하게 된다.

또한, 스토리지 프로세스는 렌더러 프로세스의 충돌이나 비정상적인 동작으로부터 격리되어, 데이터를 안전하게 보호하고 브라우저의 안정성을 유지할 수 있다.

사진출처 : Chrome for Developers - Inside look at modern web browser (part 1)

그런데 깃허브 username과 새로 발급한 토큰을 정확하게 입력해도 지속적으로 remote: Invalid username or password. 에러가 발생하였다.

토큰을 재발급해보고, Scope도 전부 선택해보고, origin을 https://github.com/[path] 에서 https://[username]:[token]@github.com/[path] 형태로 바꾸기도 해봤지만 해결이 되지 않았다.

문제는 ~/.gitconfig 파일의 기본 설정이었다.

[http "https://github.com/"] 
    extraheader = AUTHORIZATION: basic <Base64 인코딩된 인증 정보>

위 설정을 통해 Git이 Github와 통신할 때, HTTP 요청에 Authorization 헤더가 자동으로 추가된다. 위 코드에 만료된 토큰이 들어가 있어서 지속적으로 문제가 발생, 삭제하고 다시 시도하니 해결되었다.

GitHub는 기본 인증 방식(Basic Authentication)을 더 이상 권장하지 않으며, HTTPS를 사용할 경우 Personal Access Token을 별도로 입력하는 방식을 더 추천한다.

내일 현대오토에버 코테를 앞두고 빡센 구현 문제 하나 풀어보았다.

주어진 이차원 평면에서 조건에 맞게 다리를 건설하고, 모든 경로를 잇는 다리 길이의 총합의 최소를 구하는 문제이다.

접근법

각각의 섬을 그래프의 노드로, 다리를 간선으로 생각할 수 있다.

1. 먼저 각각의 섬을 구분짓는다.
2. 조건에 맞는 가능한 모든 다리를 건설한다. 동일한 섬을 연결한다면 최소 길이의 다리만 남긴다.
3. 주어진 정보로 그래프를 구성한다.
4. 최소스패닝트리(MST)를 구한다.

최소 스패닝 트리(MST)

최소 스패닝 트리(Minimum Spanning Tree, MST)는 연결된 무향 그래프에서 모든 정점을 포함하는 부분 그래프 중 간선 가중치의 합이 최소인 트리를 말합니다. 여기서 "스패닝 트리"란, 그래프의 모든 정점을 포함하되 사이클이 없는 연결 그래프입니다. 즉, MST는 그래프 내의 모든 정점을 연결하면서 간선 비용을 최소화하는 구조입니다.

최소 스패닝 트리의 특징은

• 트리 구조이며 따라서 사이클이 없다. 모든 정점이 연결되어있다.
• n개의 노드에 대해 간선의 개수는 n-1이다.
• 간선 가중치의 합이 최소이다.

프림 알고리즘 (Prim’s Algorithm)

프림 알고리즘은 최소신장트리를 구하는 알고리즘이며 직관적이어서 이해가 쉽다. 현재까지 구성한 MST에 인접한 가장 짧은 간선을 지속적으로 선택해 나아가면 된다.

우선순위큐를 통해 쉽게 구현이 가능하며, 시간복잡도는 모든 간선만큼 반복하며 우선순위큐에 삽입, 삭제를 하므로 O(E logV)이다.

프림 알고리즘은 하나의 정점에서 시작하여 인접한 간선 중 가장 낮은 가중치를 가진 간선을 선택해 MST에 추가한다. 이후 추가된 정점의 인접 간선 중 최소 가중치 간선을 선택하는 과정을 반복하여 모든 정점이 포함될 때까지 진행한다.

전체 코드

구현문제를 풀때는 최대한 간단하게 작은 단위의 함수들로 쪼개어 푸는 편이다.

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

public class Main {
    static int[][] map;
    static int row;
    static int col;

    static int[] dRow = {-1, 1, 0, 0};
    static int[] dCol = {0, 0, -1, 1};

    static int[][] adjs;

    static class Bridge {
        int to;
        int length = -1;
    }

    static boolean isValidRange(int r, int c) {
        return 0 <= r && r < row && 0 <= c && c < col;
    }

    static void bfsToNumbering(int r, int c, int islandNum, boolean[][] visited) {
        Queue<int[]> q = new ArrayDeque<>();
        q.add(new int[]{r, c});

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

            if(visited[tmpR][tmpC]) continue;
            visited[tmpR][tmpC] = true;
            map[tmpR][tmpC] = islandNum;

            for(int i = 0; i < 4; i++) {
                int nextR = tmpR + dRow[i];
                int nextC = tmpC + dCol[i];
                if(islandNum == 2 && i == 1) {
                    int here = 1;
                }
                if(isValidRange(nextR, nextC) && map[nextR][nextC] != 0) {
                    q.add(new int[]{nextR, nextC});
                }
            }
        }
    }

    static void numberingIsland() {
        boolean[][] visited = new boolean[row][col];

        int islandNum = 0;
        for(int i = 0; i < row; i++) {
            for(int j = 0; j < col; j++) {
                if(map[i][j] == 1 && !visited[i][j]) {
                    bfsToNumbering(i, j, ++islandNum, visited);
                }
            }
        }

        adjs = new int[islandNum + 1][islandNum + 1];
        for(int i = 0; i < islandNum + 1; i++) {
            Arrays.fill(adjs[i], Integer.MAX_VALUE);
            adjs[i][i] = 0;
        }
    }

    static boolean isNearWater(int r, int c) {
        for(int i = 0; i < 4; i++) {
            int nextR = r + dRow[i];
            int nextC = c + dCol[i];
            if(isValidRange(nextR, nextC) && map[nextR][nextC] == 0) return true;
        }
        return false;
    }

    static Bridge makeBridge(int r, int c, int dRow, int dCol, int startIslandNum) {
        Bridge b = new Bridge();
        int len = 0;
        while(isValidRange(r, c) && map[r][c] == 0) {
            r += dRow;
            c += dCol;
            len++;
        }

        if(isValidRange(r, c) && map[r][c] != startIslandNum) {
            b.length = len;
            b.to = map[r][c];
        }

        return b;
    }

    static void setAdj(int r, int c) {
        int tmpIslandNum = map[r][c];

        for(int i = 0; i < 4; i++) {
            int nextR = r + dRow[i];
            int nextC = c + dCol[i];
            if(isValidRange(nextR, nextC) && map[nextR][nextC] == 0) {
                Bridge b = makeBridge(nextR, nextC, dRow[i], dCol[i], tmpIslandNum);
                if(b.length >= 2) {
                    adjs[tmpIslandNum][b.to] = Math.min(adjs[tmpIslandNum][b.to], b.length);
                    adjs[b.to][tmpIslandNum] = Math.min(adjs[b.to][tmpIslandNum], b.length);
                }
            }
        }
    }

    static void setAdjs() {
        for(int i = 0; i < row; i++) {
            for(int j = 0; j < col; j++) {
                if(map[i][j] != 0 && isNearWater(i, j)) {
                    setAdj(i, j);
                }
            }
        }
    }

    public static int getMinBridgeSum() {
        boolean[] visited = new boolean[adjs.length];

        int count = 0;
        int sumOfChosenBridge = 0;

        //len, isLandNum
        PriorityQueue<int[]> pq = new PriorityQueue<>(Comparator.comparingInt(a -> a[0]));
        pq.add(new int[]{0, 1});

        while (!pq.isEmpty()) {
            int[] tmp = pq.poll();
            int len = tmp[0];
            int tmpNode = tmp[1];

            if(visited[tmpNode]) continue;
            visited[tmpNode] = true;
            count++;
            sumOfChosenBridge += len;

            if(count == adjs.length - 1) break;

            for(int i = 1; i < adjs.length; i++) {
                if(adjs[tmpNode][i] != Integer.MAX_VALUE && !visited[i]) {
                    pq.add(new int[]{adjs[tmpNode][i], i});
                }
            }
        }

        if(count != adjs.length - 1) return -1;

        return sumOfChosenBridge;
    }

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

        row = Integer.parseInt(st.nextToken());
        col = Integer.parseInt(st.nextToken());

        map = new int[row][col];

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

        numberingIsland(); //각각의 섬을 구분짓는다.
        setAdjs(); //그래프를 구성한다

        System.out.println(getMinBridgeSum()); //최소신장트리의 간선의 합을 출력한다.
    }
}