Thread에 대해서 오래전에 정리했던 적이 있다. 하지만 일을 하다가.. 아직도 Thread에 대해서 잘모른다는 느낌이 들어서 더 자세하게 다시한번 정리를 하고자 한다.

 

https://codingstudy95.tistory.com/67

 

스레드

사전적 의미로 한 가닥의 실이라는 뜻으로 한가지 작업을 실행하기 위해 순차적으로 실행할 코드를 실처럼 이어놓았다고 해서 유래된 이름이다. 하나의 스레드는 하나의 코드 실행 흐름이므로

codingstudy95.tistory.com

 

 

스레드란 무엇인가!!?

자바에서 Thread(스레드)는 프로그램 내에서 동시에 실행되는 작업의 단위를 의미한다. 회사에서 여러 사람이 각자의 다른 일을 동시에 하는 것과 마찬가지로, 스레드는 하나의 프로그램 안에서 여러 작업을 동시에 처리할 수 있도록 해준다.

(예: 데이터 처리, 사용자 요청 처리, 파일 입출력 등)

  • 단일 스레딩 : 한 사람이 모든 일을 순서대로 처리하는 것 -> 모든 작업이 순차적으로 처리되므로, 하나의 작업이 오래 걸리면 다른 작업들도 지연된다.
  • 멀티스레딩 : 여러 사람이 동시에 각자 일을 분담해서 처리하는 것 -> 여러 스레드가 동시에 작업을 처리하여, 한 작업이 늦어도 다른 작업은 계속 진행될 수 있다.

 

 

그럼 자바에서는 왜 멀티스레딩이 필요할까?

 

식당에서 한 사람이 모든 요리를 한다면 주문이 많은 경우 오래 걸리겠지만, 여러 요리사가 동시에 각자 다른 요리를 준비하면, 음식이 빨리 준비되는것과 비슷하다.

 

사용자 경험 향상

한 번에 한 작업만 처리한다면, 사용자가 어떤 요청을 할 때마다 기다려야 한다. 하지만 멀티스레딩을 사용하면, 여러 작업이 동시에 처리되어 응답 속도가 빨라지고 사용자 경험이 개선된다.

 

자원 활용의 극대화

컴퓨터는 여러 CPU 코어를 가지고 있는데, 멀티스레딩을 통해 이 코어들을 동시에 사용할 수 있다. 즉, 컴퓨터의 능력을 최대한 활용하여 더 빠르고 효율적으로 작업할 수 있다.

 

 

자바에서 스레드를 만들어보자 자바에서는 스레드를 만드는 방법이 두 가지 있다.

 

1. Thread 클래스 상속하기

// MyThread.kt
class MyThread : Thread() {
    // run 메서드를 재정의하여 스레드가 실행할 작업을 정의합니다.
    override fun run() {
        // 스레드가 실행될 때, "Hello from MyThread!"를 5번 출력합니다.
        for (i in 1..5) {
            println("Hello from MyThread! - $i")
            // 잠깐 멈추는 시간 (1000밀리초 = 1초)
            Thread.sleep(1000)
        }
    }
}

fun main() {
    // MyThread 클래스의 인스턴스를 생성하고, start()를 호출하면 스레드가 실행됩니다.
    val thread = MyThread()
    thread.start()
}
  • MyThread는 Thread 클래스를 상속받아 만든 새로운 스레드 클래스이다.
  • run() 메서드 안에 스레드가 해야 할 일을 작성한다.
  • thread.start() 를 호출하면, 새로운 스레드가 시작되어 run() 메서드의 내용이 실행된다.

 

2. Runnable 인터페이스 구현하기

또 다른 방법은 Runnable 인터페이스를 구현하는 것이다. 이 방법은 클래스 상속의 제약을 피할 수 있다는 장점이 있다.

// MyRunnable.kt
class MyRunnable : Runnable {
    override fun run() {
        // 스레드가 실행될 때, "Hello from MyRunnable!"를 5번 출력합니다.
        for (i in 1..5) {
            println("Hello from MyRunnable! - $i")
            Thread.sleep(1000)
        }
    }
}

fun main() {
    // Runnable 인터페이스를 구현한 MyRunnable 인스턴스를 Thread에 전달하여 실행합니다.
    val runnable = MyRunnable()
    val thread = Thread(runnable)
    thread.start()
}
  • MyRunnable 은 Runnable 인터페이스를 구현하여, run() 메서드 안에 작업 내용을 정의한다.
  • 이 객체를 Thread 생성자에 넘겨주고, start() 를 호출하면 스레드가 실행된다.

 

스레드의 생명주기와 상태

자바 스레드는 여러 상태를 가진다. 각 상태는 스레드가 어떤 작업을 하고 있는지를 나타낸다.

 

  • New: 스레드가 생성되었지만 아직 실행되지 않은 상태
  • Runnable: 실행 중이거나 실행 준비가 된 상태
  • Blocked/Waiting: 다른 스레드에 의해 잠시 멈춰 있는 상태
  • Timed Waiting: 일정 시간 후에 다시 실행될 상태
  • Terminated: 스레드의 작업이 모두 끝난 상태

한 사람이 일어나서 출근 준비를 하는 것처럼, 스레드도 만들어진 후 실행 준비, 작업 중, 대기, 그리고 작업 종료의 과정을 거친다.

 

 

 

근데 문제가 발생할 수 있다. 멀티스레딩에서 여러 스레드가 동시에 같은 데이터를 수정하려 할 때 문제가 발생할 수 있다.

이를 경쟁 조건 (Race Condition) 이라고 하며, 이를 해결하기 위해 동기화(Synchronization) 를 사용한다.

 

예를 들어 콘서트 티켓을 예매할때 한 좌석을 동시에 두명이 예매하려고 할때 좌석을 누구에게 할당해야 할까?  이런 문제를 해결하려면, 한 사람이 작업을 끝낼 때까지 기다리도록 해야 한다.

 

 

synchronized 키워드 사용 예제

class Counter {
    var count: Int = 0

    // synchronized를 사용해 여러 스레드가 동시에 count를 수정하지 않도록 보호합니다.
    @Synchronized
    fun increment() {
        count++
    }
}

fun main() {
    val counter = Counter()
    val threads = mutableListOf<Thread>()

    // 10개의 스레드를 생성하여 동시에 increment()를 호출합니다.
    for (i in 1..10) {
        val thread = Thread {
            for (j in 1..1000) {
                counter.increment()
            }
        }
        threads.add(thread)
        thread.start()
    }

    // 모든 스레드가 끝날 때까지 대기합니다.
    threads.forEach { it.join() }

    // 10개의 스레드가 각각 1000번씩 increment했으므로, 최종 결과는 10000이어야 합니다.
    println("최종 count: ${counter.count}")  // 결과: 10000
}
  • @Synchronized 어노테이션을 사용해 increment() 메서드에 동시에 접근하는 것을 막는다.
  • 여러 스레드가 동시에 increment() 를 호출해도, 동기화 덕분에 안전하게 실행된다.   

 

 

내가 회사에서 일하면서 실제로 겪은 스레드 문제가 있다.

 

경쟁 조건과 데드락

  • 경쟁조건 : 여러 스레드가 동시에 데이터를 수정할 때 예상치 못한 결과가 발생하는것
  • 데드락(DeadLock) : 두 스레드가 서로 상대방이 가진 자원을 기다리면서 무한 대기에 빠지는 상황이다.

동기화 블록이나 Lock 객체를 사용해, 자원에 접근하는 순서를 잘 관리해야 한다. 

 

실제로 데드락에 빠지는 로직을 개발하여 정말..난리 난리가 났었던...일이...후..

 

 

스레드 풀 (Thread Pool) 

매번 새로운 스레드를 생성하는 대신, 미리 일정 개수의 스레드를 만들어 두고 재사용하는 방법. 스레드의 생성 비용을 줄이고, 시스템 자원을 효율적으로 사용할 수 있다.

import java.util.concurrent.Executors

fun main() {
    // 고정 크기의 스레드 풀 생성 (3개의 스레드)
    val executor = Executors.newFixedThreadPool(3)

    // 10개의 작업을 스레드 풀에 제출합니다.
    for (i in 1..10) {
        executor.submit {
            println("작업 $i 시작: ${Thread.currentThread().name}")
            Thread.sleep(1000)
            println("작업 $i 완료: ${Thread.currentThread().name}")
        }
    }

    // 스레드 풀 종료
    executor.shutdown()
}
  • Executors.newFixedThreadPool(3)를 통해 3개의 스레드로 이루어진 풀을 생성한다.
  • 여러 작업이 동시에 제출되지만, 동시에 최대 3개 작업만 실행되고 나머지는 대기한다.

사용자 관점에서 한번 생각해보자

 

대부분의 웹 애플리케이션에서는 사용자가 데이터를 수정하고 저장을 누르면, 스레드 풀(Thread Pool) 에서 미리 만들어진 스레드 중 하나가 해당 요청을 처리한다.

 

즉, 사용자가 콘텐츠를 수정하고 저장 버튼을 클릭하면

  1. 웹 서버는 이미 생성되어 대기 중인 스레드 풀에서 하나의 스레드를 할당한다
  2. 해당 스레드가 수정 작업 로직을 실행하고
  3. 작업이 완료되면 그 스레드는 스레드 풀로 돌아가 재사용된다.

이제 스레드에 대해 확실히 알게 된 것 같다.

 

 

 

'Back-End > Java' 카테고리의 다른 글

null 체크, try-catch가 난무하는 코드 수정해보기  (6) 2025.06.09
HTTP 요청 하나당 스레드는 몇 개나 동작할까?  (0) 2025.05.12
try-catch  (0) 2024.07.06
스레드  (1) 2024.07.05
프로세스  (0) 2024.07.04

개발을 하다 보면 ArrayList를 쓸지, LinkedList를 쓸지 고민할 때가 많다. 특히 데이터를 추가할 때(add), 성능이나 메모리 측면에서 어떤 차이가 있는지 정확하게 이해하고 있으면, 더 좋은 성능을 만들 수 있을 것 같아서 정리해본다.

 

1. ArrayList 

  • 내부적으로 배열(Array) 기반으로 데이터를 저장하는 컬렉션이다.
  • 데이터가 추가되면서 배열 크기를 초과하면, 더 큰 배열을 새로 만들고 기존 데이터를 복사한다.
val arrayList = ArrayList<Int>()
arrayList.add(10) // 배열에 10 추가

 

특징 : 

  • 인덱스를 통한 접근 ( get(index) ) 이 매우 빠름 → O(1)
  • 중간 삽입/삭제는 느림 → O(N) (요소 이동 발생)

 

2. LinkedList

  • 노드(Node) 들이 포인터로 연결된 구조이다.
  • 각각의 노드는 데이터(data)와 다음 노드(next)를 가리키는 포인터를 가지고 있다.
val linkedList = LinkedList<Int>()
linkedList.add(10) // 노드로 10 추가

 

특징 : 

  • 앞/뒤 삽입/삭제가 매우 빠름 → O(1)
  • 인덱스를 통한 접근은 느림 O(N) (앞에서붜 순회 필요)

 

 

3. add 시 시간 복잡도 비교

상황 ArrayList LinkedList
맨 뒤에 추가( add(E e) ) 평균 O(1)
(가끔 O(N) 리사이즈)
항상 O(1)
중간에 추가 ( add(index, E e) ) O(N) (뒤 요소 이동) O(N) (위치 탐색 필요)

 

ArrayList의 경우

  • 맨 뒤에 추가할 때는 평균적으로 O(1) 이지만, 배열 용량이 부족하면 O(N) 리사이즈가 발생한다.
  • 중간에 추가할 경우, 추가 위치 이후의 모든 요소를 한 칸씩 밀어야 하므로 O(N)이다.

LinkedList의 경우

  • 맨 뒤에 추가는 항상 O(1) (tail 포인터 사용).
  • 중간에 추가할 경우, 목표 인덱스까지 노드를 순차적으로 탐색해야 하므로 O(N)이다.
  • 탐색 이후 삽입 자체는 포인터지만 연결하면 되기 때문에 삽입 동작은 O(1)이다.

 

 

4. 메모리 사용량 차이

항목  ArrayList LinkedList
메모리 구조 연속된 배열 분산된 노드 + 포인터 연결
한 요소 저장 시 추가 메모리 없음 (배열 포인터만) next/prev 포인터 2개 추가 필요

 

ArrayList의 경우

  • 요소 크기 * 배열 크기 만큼 메모리 사용.
  • 공간이 부족할 것을 대비해 capacity (버퍼 공간)을 여유롭게 잡기도 한다.
  • 배열이라서 캐시 친화적(cache friendly) 이다.

LinkedList의 경우

  • 각 노드마다 데이터 + next 포인터 + prev 포인터 (더블 링크드 리스트 기준)를 저장한다
  • 포인터 오버헤드 때문에 메모리 사용량이 훨씬 많음.
  • 메모리가 연속적이지 않아 캐시 미스(cache miss)가 자주 발생한다.

정리하면, 메모리 효율은 ArrayList가 압도적으로 좋다.

 

 

 

5. 상황별 추천

상황 추천 자료구조
빠른 랜덤 접근이 필요할 때 ArrayList
삽입/삭제가 매우 빈번할 때 LinkedList
메모리 효율을 중요시할 때 ArrayList
요소 수를 자주 바꿀 때 (초대량 삭제 등) LinkedList (특수 상황)

 

대부분의 일반적인 경우 (조회 + 추가)는 ArrayList가 훨씬 효율적이다. LinkedList는 특정 상황(삽입/삭제가 매우 빈번한 경우) 에만 신중하게 써야 한다.

 

 

Kotlin을 공부중인데 val에 대해서 글을 읽던 중 엥? 이게 무슨 말이지 하는 부분이 있었다.

 

분명 "val 로 선언하면 값을 바꿀 수 없다" 라고 봤는데, val로 선언했는데 객체 내부 값이 변하는걸 목격했다.

 

분명히 고정된 값(val)인데 왜 내부 데이터는 바뀌는건지 혼란스러웠다.

 

이건 Kotlin이 값을 불변하게 만든다고 오해한 데서 시작된 착각이라는 것을 알았다.

 

진짜로 불변(Immutable)한 것은 "참조(reference)" 이지, "객체의 상태(state)" 가 아니다.

 

 

1. Kotlin의 val 과 var 기본 개념

먼저, Kotlin의 val 과 var 는 변수 선언 방식이다.

키워드 의미
val 읽기 전용(Read-only) 참조
var 읽기/쓰기(Read-Write) 참조

 

  • val 은 참조를 변경할 수 없다.
  • var 은 참조를 변경할 수 있다.

즉, val 은 "이 참조가 다른 객체를 가리키지 않도록 고정"하는 것이다. "참조하는 객체 재부"는 건들 수 있다.

 

val list = mutableListOf(1, 2, 3)
list.add(4)      //  가능
list.remove(2)   //  가능
// list = mutableListOf(5, 6, 7)  // ❌ 에러! 참조 변경 불가

 

위 코드에서 알아볼 수 있다.

  • list 가 가리키는 리스트 객체는 수정 가능하다.
  • 그러나 list 자체를 다른 리스트로 바꿀 수 없다.

 

var 은 참조 변경이 가능하다

var list = mutableListOf(1, 2, 3)
list = mutableListOf(10, 20, 30)  // 가능

 

 

오호..이제 알겠다. 근데 왜 이런 설계를 했을까???

 

2. val 설계 이유

Kotlin이 val 을 참조 고정만 보장하고, 객체 불변성을 강제하지 않는 이유는 다음과 같다.

 

이유 1 : 유연성과 기능

  • 객체를 통째로 새로 생성하는 것보다, 기존 객체를 수정하는 것이 빠를 때가 많다.
  • 특히 컬렉션 같은 경우 "수정 가능한 컬렉션 (mutableListOf)" 은 효율적이다.

이유 2: Kotlin의 철학

  • Kotlin은 "개발자에게 선택권을 준다" 는 철학을 지향한다.
  • 불변 객체를 원하면, 개발자가 immutable한 자료구조를 선택해야 한다.

Kotlin은 "불면(immutable)"을 강제하지 않는다. 읽기 전용 참조(read-only reference)만 보장한다.

 

 

3. Mutable 과 Immutable 객체

mutable = 내부 상태를 바꿀 수 있다.

immutable = 내부 상태를 바꿀 수 없다.

구분 설명 예시
Mutable 객체 객체 내부 데이터 변경 가능 mutableListOf, HashMap 등
Immutable 객체 객체 내부 데이터 변경 불가 listOf, Map (읽기 전용 View)

 

Kotlin의 listOf() 로 만든 리스트도 사실은 완전한 immutable은 아니다. 완전히 불변한 컬렉션을 원하면 별도로 관리해야 한다.

예: Collecitons.unmodifiableList(), 또는 직접 만드는 데이터 클래스

 

 

즉 비유를 하자면

 

val 은 집주소를 고정하는 것이다. 집 주소를 못 바꾸지만, 집안 가구 배치나 이런건 마음대로 바꿀 수 있지 않은가.

val 집 = MyHouse()
집.소파 = "새 소파로 교체" // OK
// 집 = 다른집() // ❌ 참조 변경은 불가

 

 

 

4. 데이터 클래스와 불변성

Kotlin에서는 데이터 클래스를 많이 사용한다.

data class Person(var name: String, var age: Int)

 

val 로 선언해도 name, age는 변경 가능하다.

 val person = Person("Alice", 25)
person.age = 26  // 내부 필드 변경 가능

 

  • person 이라는 참조는 고정된다
  • 하지만 person 객체 내부 필드(age)는 변경 가능하다.

 

정말 진짜 불변성을 원한다면 다음과 같이 만들 수 있다.

 

1. data class를 val 프로퍼티로만 만든다.

data class ImmutablePerson(val name: String, val age: Int)

 

이제 name, age를 바꿀 수 없다.

 

2. 불변 컬렉션을 사용한다.

val list = listOf(1, 2, 3)
// list.add(4)  // ❌ 컴파일 에러

 

 

 

주의할 점

상황 주의해야 할 점
API 리턴 타입을 val로 선언했지만 내부 객체가 Mutable인 경우 외부에서 상태가 변조될 수 있다.
글로벌 상태를 val로만 선언하고 안심하는 경우 Thread-safety는 별개 문제이다.

 

  • val 은 객체 상태를 보호해주지 않는다.
  • 불변성을 원하면 객체 설계 자체를 immutable하게 헤야 한다.

의존성? 의존성이 뭘까?

어떤 물건을 만들거나 사용할 때 다른 것이 꼭 필요할때 우리는 그것을 의존한다고 한다.

예를 들어 자동차는 엔진이 꼭 필요하다.

  • 자동차는 혼자서는 움직일 수 없다.
  • 반드시 엔진이 있어야 움직일 수 있다.
  • 자동차는 엔진에 의존하고 있다고 말할 수 있다.

이처럼 어떤 객체가 다른 객체를 필요로 할 때, 의존성이 있다고 말한다.

 

그렇다면 의존성 주입(Dependency Injection) 이란 무엇일까?

 

만약 자동차가 엔진을 직접 만들 필요 없이, 공장에서 엔진을 가져와 조립할 수 있다면 더 편리하지 않을까?? 

>>> 이것이 의존성 주입니다.

 

쉽게 말해

  • 자동차(클래스)는 엔진을 직접 만들지 않음
  • 필요한 엔진을 공장에서(스프링)  가져옴
  • 스프링이 자동차에 엔진을 자동으로 넣어줌(의존성 주입)!

 

오호라..스프링이 있으면 편리해 보인다. 그럼 만약에 의존성 주입이 없다면 어떤 문제가 생길까???

class Car {
    private Engine engine = new Engine();  // 자동차가 직접 엔진을 생성
    
    public void start() {
        engine.run();
    }
}

 

이런 식으로 코드를 작성할 경우

  1. 자동차(Car)가 직접 엔진을 생성하고 있다.
  2. 나중에 엔진을 바꾸고 싶다면 자동차 코드를 직접 수정해야 한다.
  3. 코드가 유연하지 않고, 새로운 기능 추가도 어려워진다.

즉, 자동차가 직접 엔진을 만들게되면, 나중에 다른 엔진(전기 엔진, 하이브리드 엔진)으로 바꾸기 어려워진다.

 

 

그렇다면 의존성 주입을 사용하려면 어떻게 해야할까???

 

Spring Boot에서는 자동으로 필요한 객체(엔진)를 주입해줄 수 있다.

class Car {
    private Engine engine;

    public Car(Engine engine) {  // 외부에서 엔진을 넣어줌
        this.engine = engine;
    }

    public void start() {
        engine.run();
    }
}

 

이렇게 되면 자동차는 아주 쉽게 엔진을 교체할 수  있다.

  • Engine engine = new GasEngine();  (가솔린 엔진)
  • Engine engine = new ElectricEngine(); (전기 엔진)
  • Engine engine = new HybridEngine(); (하이브리드 엔진)

즉, 자동차 스스로 엔진을 직접 만들 필요 없이, 외부에서 받아서 사용할 수 있다.

 

 

너무 신기하다 근데 스프링은 어떻게 의존성을 주입하는 걸까?

 

스프링은 자동으로 필요한 객체를 찾아 주입(Injection) 해준다.

@Component
class Engine {
    public void run() {
        System.out.println("엔진이 가동됩니다.");
    }
}

@Component
class Car {
    private final Engine engine;

    @Autowired  // 스프링이 자동으로 Engine을 넣어줌!
    public Car(Engine engine) {
        this.engine = engine;
    }

    public void start() {
        engine.run();
    }
}

 

@Autowired를 사용하면 스프링이 알아서 엔진을 찾아서(Car에) 넣어준다.

이제 Car 객체를 만들 때 자동으로 Engine이 들어간다.

 

 

의존성 주입 3가지 방법

 

1. 생성자 주입(추천)

class Car {
    private final Engine engine;

    @Autowired
    public Car(Engine engine) {  // 생성자를 통해 의존성 주입
        this.engine = engine;
    }
}

 

장점 : 

  • 반드시 필요한 값이 주입된다 (final 사용 가능)
  • 테스트하기 쉽고 유지보수도 편리하다

 

2. 필드 주입(사용 지양)

class Car {
    @Autowired
    private Engine engine;  // 필드에 직접 주입
}

 

단점 : 

  • 필수값이 빠질 수 있다.
  • 테스트하기 어렵다
  • Spring Context 없이 사용할 수 없다.

 

3. Setter 주입

class Car {
    private Engine engine;

    @Autowired
    public void setEngine(Engine engine) {  // Setter를 통해 주입
        this.engine = engine;
    }
}

 

장점 : 필요할 때 객체를 바꿀 수 있다.

단점 : 의존성이 필수가 아닐 수도 있음(Setter를 호출하지 않으면 값이 없다)

 

 

 

의존성에 대해 알아보았는데 의존성 주입에 대해 요약하자면

 

중요한 이유 !

  1. 코드의 재사용성이 높아짐 -> Car 클래스를 수정하지 않고 다양한 Engine을 사용가능
  2. 유지보수가 쉬워짐 -> Engine을 변경할 때 Car 클래스를 수정할 필요가 없다.
  3. 테스트하기 쉬움 -> 테스트할 때 가자(Mock) 객체를 쉽게 주입할 수 있다.
  4. 스프링이 자동으로 객체를 관리 ->  개발자가 직접 객체를 만들 필요가 없다.

 

브라우저 캐시는 단순히 프론트엔드의 영역이 아니라, 실제 서비스의 성능과 트래픽 비용, 심지어 버그 발생 가능성까지 영향을 미치는 아주 중요한 요소이다.

 

브라우저 캐시란?

브라우저 캐시는 클라이언트(사용자의 웹 브라우저)가 자주 사용하는 데이터를 저장해두고, 다음에 다시 요청할 때 빠르게 보여주기 위한 기술이다. 

 

예 : 어떤 쇼핑몰 사이트에 방문시, 그 사이트의 로고 이미지가 매번 서버에서 오면 느릴것이다. 그래서 브라우저는 이걸 한 번 다운로드한 뒤, 다음부터는 자기 컴퓨터에 저장된걸 보여준다.

 

 

브라우저 캐시의 핵심 메커니즘 

1. Cache-Control

서버가 클라이언트에게 이 리소스를 어떻게 캐시해야 할지 알려주는 HTTP 헤더이다.

  • max-age=3600 -> 1시간 동안 캐시해라
  • public -> 누구나 캐시해도 된다

2. ETag / Last-Modified

  • 캐시된 파일이 변경됐는지 확인하는 데 사용한다.
  • 변경이 없으면 304 Not Modified로 응답해서 데이터를 아예 보내지 않는다.

 

 

3. 실무에서 사용 가능한 전략

리소스 타입 캐시 전략
이미지, JS, CSS long-term 캐시 + 파일명에 해시
HTML 페이지 no-cache 또는 must-revalidate
API 응답(GET) short max-age 또는 no-store

 

 

4. CDN과의 캐시 연계

클라우드플레어, AWS CloudFront 같은 CDN은 브라우저 뿐 아니라 서버 앞단에서 전 세계에 캐시를 제공한다. 이를 통해 TTFB(Time to First Byte)를 극적으로 낮출 수 있다. 

 

서버 -> CDN -> 브라우저 순으로 캐시 계층을 구성하면 성능 최적화에 큰 효과가 있다.

 

 

5. 디버깅 방법

브라우저 개발 도구에서 Network 탭을 열고, 리소스를 확인하면 아래 정보들을 볼 수 있다.

  • Status : 200 OK vs 304 Not Modified
  • Cache-Control 헤더
  • ETag / Last-Modified 여부

실제로 문제를 겪을 때 이 도구를 통해 빠르게 원인을 추적할 수 있다.

대부분의 테이블에 날짜 데이터가 등록된 컬럼이 있을 것이다. 날짜별로 그룹화 하여 조회하려면 어떻게 해야할까??

 

1. TRUNC 함수 사용

TRUNC 함수를 사용하면 날짜별로 잘라낼 수 있다.

 

* 월 단위로 자르는 예시

SELECT TRUNC(REG_DT, 'MM') AS month_start,
       COUNT(*) AS cnt
FROM your_table
GROUP BY TRUNC(REG_DT, 'MM')
ORDER BY month_start;

이 쿼리는 REG_DT의 월의 첫 날(예: 2024-08-01) 기준으로 그룹화하여 각 월에 해당하는 데이터 건수를 보여준다.

 

2. TO_CHAR 함수 사용 

날짜를 원하는 형식(예: 'YYYY-MM')으로 변환하여 그룹화할 수도 있다.

SELECT TO_CHAR(REG_DT, 'YYYY-MM') AS month,
       COUNT(*) AS cnt
FROM your_table
GROUP BY TO_CHAR(REG_DT, 'YYYY-MM')
ORDER BY month;

 

* 만약 REG_DT 컬럼이 문자열 형식이라면, 먼저 TO_DATE 또는 TO_TIMESTAMP 함수를 사용하여 날짜로 변환해야 한다.

실시간 통신은 채팅, 알림, 게임. 금융 거래 등 다양한 분야에서 핵심 기술로 사용된다. 예를 들어, 소셜 미디어에서 친구가 게시물을 올릴 때 실시간 알림이 전송되는 경우, WebSocket을 통해 효율적으로 구현할 수 있다. 추후에 어떤 서비스를 구현해 볼지 모르기 때문에 한번 관련된 내용을 정리해두자

 

기본 개념을 먼저 이해해보자 

 

1. HTTP 프로토콜

HTTP(HyperText Transfer Protocol)는 웹의 기본 통신 프로토콜이다. 

  • 요청-응답 구조 : 클라이언트가 요청하면 서버가 응답
  • 단발성 연결 : 요청 후 연결 종료
  • 비상태성 : 각 요청이 독립적

위처럼 HTTP의 한계는 실시간 상호작용에 적합하지 않다는 점이다. 실시간 데이터 전송이나 서버의 지속적인 이벤트 알림은 HTTP만으로 구현하기 어렵다.

 

 

2. WebSocket이란?

WebSocket은 HTTP와 달리 양방향, 지속적인 연결을 제공하는 프로토콜이다. 

  • 지속 연결 : 클라이언트와 서버가 한 번 연결되면 계속해서 데이터를 주고받을 수 있다.
  • 양방향 통신 : 서버가 클라이언트에게 자유롭게 메시지를 전송할 수 있다.
  • 실시간성 : 낮은 지연시간으로 실시간 데이터를 처리할 수 있다.

 

HTTP와 WebSocket의 차이점을 표로 만들어보자

 

구분 HTTP WebSocket
연결 방식 요청-응답 후 연결 종료 연결 후 지속적으로 열린 상태 유지
통신 방향 단방향(클라이언트 요청에 의존) 양방향(서버와 클라이언트 모두 자유롭게 전송)
프로토콜 오버헤드 매 요청마다 헤더 정보 전송 초기 핸드쉐이크 후 최소한의 오버헤드
실시간성 제한적(폴링 방식 필요) 매우 우수 (즉시 데이터 전달)

 

실시간 애플리케이션에서 왜 WebSocket을 선호하는지 알 것 같다. 그러면 WebSocket의 동작 원리에 대해서 알아보자

 

 

3. WebSocket의 동작 원리

3.1 핸드쉐이크 과정

WebSocket 통신은 HTTP 핸드쉐이크로 시작한다.

  1. 클라이언트 요청 : 클라이언트는 HTTP 업그레이드 헤더를 포함하여 서버에 연결 요청을 보낸다.
  2. 서버 응답 : 서버는 요청을 수락하고, 프로토콜을 WebSocket으로 전환하는 응답을 보낸다.
  3. 연결 수립 : 이후 연결은 TCP기반의 지속 연결로 전황되어 데이터를 주고받는다.

이 과정을 통해 기존 HTTP 환경에서도 WebSocket을 사용할 수 있는 유연성을 제공한다.

 

3.2 연결 유지 및 메시지 교환

연결이 성립되면 클라이언트와 서버는 프레임 단위로 메시지를 주고받는다.

  • 텍스트 프레임 : 일반 텍스트 메시지 전송
  • 바이너리 프레임 : 이미지, 파일 등 이진 데이터 전송
  • 컨트롤 프레임 : 연결 종료, 핑/퐁 등 관리 메시지 전송

3.3 연결 종료 메커니즘

연결 종료 시에는 양측에서 종료 요청을 보내고, 지정된 절차에 따라 연결을 정상적으로 마감한다. 이 과정을 예기치 않은 연결 종료를 방지하고, 자원 누수를 최소화한다.

 

 

Spring Boot를 활용해서 간단한 서비스를 만들어보자

 

Spring Boot에서는 기본적으로 WebSocket을 지원하고, 모듈도 제공해준다.

  • spring-boot-starter-websocket : WebSocket 관련 의존성 자동 구성
  • STOMP(Simple Text Oriented Messaging Protocol) : 메시지 브로커와의 통신 지원

Spring Boot에서 WebSocket을 사용하려면 Gradle 또는 Maven을 통해 의존성을 추가해준다.

 

*gradle 예시

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

 

 

간단한 실시간 알림 서비스 

  • 사용자가 실시간으로 이벤트를 감지
  • 서버는 이벤트 발생 시 즉시 모든 관련 클라이언트에 알림 전달
  • 연결 상태를 지속적으로 유지하여 지연 없이 메시지 전송

 

WebSocket 설정 클래스

@Configuration
@EnableWebSocket
class WebSocketConfig : WebSocketConfigurer {
    override fun registerWebSocketHandlers(registry: WebSocketHandlerRegistry) {
        registry.addHandler(NotificationHandler(), "/ws/notifications")
            .setAllowedOrigins("*")
    }
}

 

WebSocket 핸들러 클래스

class NotificationHandler : TextWebSocketHandler() {

    override fun handleTextMessage(session: WebSocketSession, message: TextMessage) {
        val receivedText = message.payload
        val response = TextMessage("알림: $receivedText")
        session.sendMessage(response)
    }

    override fun afterConnectionEstablished(session: WebSocketSession) {
        println("클라이언트 연결됨: ${session.id}")
    }

    override fun afterConnectionClosed(session: WebSocketSession, status: CloseStatus) {
        println("클라이언트 연결 종료: ${session.id}")
    }
}

 

실행 클래스

@SpringBootApplication
class WebSocketApplication

fun main(args: Array<String>) {
    runApplication<WebSocketApplication>(*args)
}

 

 

화면

<!DOCTYPE html>
<html lang="ko">
<head>
    <meta charset="UTF-8">
    <title>Kotlin WebSocket 테스트</title>
</head>
<body>
    <h2>실시간 알림 테스트</h2>
    <input id="input" type="text" placeholder="메시지 입력">
    <button onclick="send()">전송</button>
    <div id="log"></div>

    <script>
        const ws = new WebSocket("ws://localhost:8080/ws/notifications");
        ws.onmessage = (event) => {
            const log = document.getElementById('log');
            log.innerHTML += `<p>${event.data}</p>`;
        };

        function send() {
            const input = document.getElementById('input');
            ws.send(input.value);
            input.value = '';
        }
    </script>
</body>
</html>

컬럼 삭제 중 해당 에러가 떴다. 

 

원인

  • 테이블이 다른 세션에서 사용 중이다.

다른 사람이 테이블에 대해 SELECT나 UPDATE를 하고 있거나, 트랜잭션이 열려 있어서 락이 걸려 있는 상태이다. Oracle은 ALTER TABLE 같은 DDL 문장을 실행할 때 해당 테이블에 대해 exclusive lock을 걸려고 시도하는데, 이미 누군가 쓰고 있다면 그 락을 못 걸고 에러가 난다.

 

누군가 테이블을 사용하고 있군... 

 

 

해결 방법

  1. 잠깜 기다렸다가 다시 시도 : 누군가 사용하고 있다는건 일시적인 현상이므로 가장 직관적인  해결 방법인것 같다.
  2. 락 걸린 세션 확인하기(DBA 권한 필요)
  3. 락 잡고 있는 세션 종료(주의! 꼭 필요한 경우에만 진행한다.)

* 락 걸린 세션 확인 쿼리

SELECT
  l.session_id,
  s.serial#,
  s.username,
  s.status,
  o.object_name
FROM
  v$locked_object l
  JOIN dba_objects o ON l.object_id = o.object_id
  JOIN v$session s ON l.session_id = s.sid
WHERE
  o.object_name = 'A';

 

 

* 세션 종료

ALTER SYSTEM KILL SESSION '세션ID,시리얼번호' IMMEDIATE;

Java 기반 프로젝트를 배포할 때 자주 사용하는 Jar 파일과 War 파일이 있다. 누군가는 War 파일로 달라고 하고, 누군가는 Jar 파일로 달라고 한다. 두 파일의 차이점은 무엇이고 어떨때 활용하면 좋을까?

 

Jar, War 모두 패키징이다.

 

여기서 패키징은 단순히 파일을 압축하는 것이 아니라, 실제 애플리케이션을 실행 가능한 형태로 만들어 주는 매우 중요한 단계이다.

 

연인에게 줄 선물을 박스째로 주는 것보다 예쁘게 포장해서 주면 더 좋은것과 마찬가지이다.

 

소프트웨어도 Jar 파일이나 War 파일과 같은 포맷으로 잘 포장되어 있어야, 다른 개발자나 운영자가 쉽게 사용하고 배포할 수 있다.

 

Jar 파일(Java Archive)

Jar 파일은 Java 애플리케이션을 패키징하는데 사용되는 파일 형식이다. 여러 개의 클래스 파일, 리소스 파일, 메타데이터를 하나의 압축 파일로 묶은 것이다. 특히 Spring Boot와 같은 프레임워크에서는 애플리케이션 전체가 Jar 파일 하나로 패키징된다.

 

 

Jar 파일의 특징

  • 독립적 실행 가능 : 내장된 Tomcat, Jetty 등 웹 서버를 함께 포함하여 별도의 웹 서버 설치 없이 실행할 수 있다.
  • 실행 방식 간편 : 명령어 한 줄로 간편하게 실행할 수 있다.
  • 클라우드 및 마이크로서비스 환경 적합 : 컨테이너화된 환경에서 효율적으로 관리된다.
  • 실행 가능한 Jar 파일은 main() 메서드를 포함하고 있어,  java - jar filename.jar   명령어로 실행할 수 있다.

 

활용법 

  • 애플리케이션 배포 : 독립 실행형 애플리케이션으로 배포할 때 사용한다.
  • 라이브러리 제공 : 다른 프로젝트에서 공통적으로 사용할 수 있는 기능을 포함한 라이브러리를 Jar 파일로 제공할 수 있다.

 

 

 

War 파일(Web Application Archive)

War 파일은 웹 애플리케이션을 Tomcat, JBoss, WebLogic 등 외부 웹 서버에 배포할 때 사용되는 형식이다.

 

War 파일의 특징

  • 외부 서버에 의존적 : 별도의 외부 웹 서버가 반드시 필요하다.
  • 복잡한 설정 지원 가능 : 다양한 서버에서 다수의 애플리케이션 관리 시 효율적이다.
  • 전통적인 배포 방식 : 기존 웹 서버 기반 인프라에 적합하다.

어떤 것을 선택할지?

  • Jar : 빠른 배포가 중요하거나 클라우드 환경에 배포한다면 Jar 파일이 좋다.
  • War : 복잡한 서버 환경을 관리하거나 기존 웹 서버를 활용해야 하는 환경이라면 War 파일이 유리하다.

 

두 파일의 차이점을 정리해보자 

 

Jar와 War 파일의 차이점

1. 구조와 구성 요소 비교

 

Jar 파일:

  • 주로 클래스 파일과 리소스 파일, 메타데이터가 포함됩니다.
  • 실행 가능한 Jar 파일은 main() 메서드를 포함하여 독립적으로 실행됩니다.

War 파일:

  • 웹 애플리케이션에 필요한 모든 파일(HTML, CSS, JS, 서블릿, JSP, WEB-INF 폴더 등)이 포함됩니다.
  • War 파일은 서블릿 컨테이너(예: Tomcat)에 배포되어 실행됩니다.

 

 

2. 실행 환경과 용도

 

Jar 파일:

  • 용도: 독립 실행형 애플리케이션, 라이브러리 제공
  • 실행 환경: JVM이 설치된 모든 환경에서 실행 가능
  • 실행 방법: java -jar myapp.jar

War 파일:

  • 용도: 웹 애플리케이션, 동적 웹 사이트
  • 실행 환경: 서블릿 컨테이너(예: Tomcat, Jetty)가 필요
  • 배포 방법: War 파일을 서버의 webapps 폴더에 복사하여 자동 배포

 

실제 개발 사례와 활용 전략

제가 백엔드 개발자로 일하면서 느낀 점은, Jar 파일과 War 파일을 어떻게 활용하느냐가 프로젝트의 성격에 따라 달라진다는 것이다.

 

1. 소규모 프로젝트 vs 대규모 웹 서비스

  • 소규모 프로젝트:
    독립 실행형 애플리케이션이나 명령줄 도구 등은 Jar 파일로 배포하는 것이 편리합니다.
  • 대규모 웹 서비스:
    웹 애플리케이션은 War 파일로 패키징하여 Tomcat 같은 서버에 배포합니다.

 

 

2. 마이크로서비스 아키텍처에서의 활용

요즘은 많은 기업들이 마이크로서비스 아키텍처를 채택하고 있다고 한다.
각 서비스는 독립적으로 개발되고 배포되는데, 이때

  • 각 서비스는 Jar 파일로 배포될 수도 있고,
  • 혹은 각각의 웹 애플리케이션으로 War 파일로 패키징되어 별도의 서블릿 컨테이너에서 실행될 수도 있습니다.

 

 

3. 실제 적용 예: Spring Boot 애플리케이션

Spring Boot는 기본적으로 Jar 파일로 배포할 수 있도록 설계되어 있지만, 설정을 통해 War 파일로도 패키징할 수 있습니다.

 

Jar 파일로 배포하는 경우

장점:

  • 독립 실행형으로 배포하기 쉽고, 내장 Tomcat을 포함하여 추가 설정이 필요 없습니다.

예제

   java -jar myapplication.jar    

 

 

War 파일로 배포하는 경우

Spring Boot 애플리케이션을 War 파일로 빌드하려면, 메인 클래스에 SpringBootServletInitializer 를 상속받는 설정이 필요하다.

 

예제 코드를 한번 살펴보자

package com.example.demo

import org.springframework.boot.autoconfigure.SpringBootApplication
import org.springframework.boot.builder.SpringApplicationBuilder
import org.springframework.boot.web.servlet.support.SpringBootServletInitializer

@SpringBootApplication
class DemoApplication

/**
 * War 파일로 패키징하기 위한 설정 클래스
 */
class ServletInitializer : SpringBootServletInitializer() {
    override fun configure(application: SpringApplicationBuilder): SpringApplicationBuilder {
        return application.sources(DemoApplication::class.java)
    }
}

fun main(args: Array<String>) {
    runApplication<DemoApplication>(*args)
}

 

빌드 후 생성된 War 파일을 Tomcat의 webapps 폴더에 복사하면 자동으로 배포된다.

 

 

Jar 파일 구조 다이어그램

 

Jar 파일은 Java 클래스, 리소스, 그리고 메타데이터가 하나의 압축 파일에 담겨 있는 구조이다.

 

 

War 파일 구조 다이어그램

 

War 파일은 웹 애플리케이션을 위한 모든 파일이 포함되어 있으며, WEB-INF 폴더 아래에 클래스와 라이브러리들이 존재한다.

회사에서 일을 하면서 실제로 대규모 트래픽을 경험해 볼 수는 없다. 끽해야 일일 접속자가 350명 정도..? 사내 서비스라 이용자가 너무 적다. 

 

여러 구인구직 공고를 보면 대부분 대규모 트래픽을 구축해보거나 경험해본 사람들을 우대하는 것을 보고 나 스스로 대규모 트래픽에 관해 여러 문서나 사례등을 바탕으로 대규모 트래픽을 처리하는 방법에 대해 많이 공부해야 된다고 느꼈다.

 

이 글 하나만 읽어도 대규모 트래픽 환경에서 어떻게 안정적인 시스템을 설계할 수 있는지 확실하게 정리하고자 한다.(나처럼 실제 트래픽을 경험해 본 적이 없더라도 말이다..)

 

 

1. 대규모 트래픽이란?

대규모 트래픽은 한꺼번에 수많은 사용자가 웹사이트나 애플리케이션에 접속해 데이터를 요청하는 상황을 말한다. 예를 들어, 쇼핑몰의 대규모 세일 기간이나, 로또 청약 신청, 공연 티켓 예매등 평소보다 엄청난 사용자가 몰리는 경우를 의미한다.

 

이런 상황에서는 제대로 준비가 되어있지 않다면 서버가 과부화되어 느려지거나 다운될 위험이 있기 때문에, 효율적인 시스템 설계가 매우매우 중요하다.

 

 

대규모 트래픽 환경에서는 다음과 같은 문제들이 발생할 수 있다.

 

2. 대규모 트래픽이 주는 도전 과제

  • 응답 속도 유지 : 수많은 요청이 동시에 들어와도 빠르게 응답해야 한다.
  • 서버 과부화 방지 : 한 서버에 모든 요청이 몰리면 서버가 다운될 수 있으므로, 부하를 적절히 분산시켜야 한다.
  • 데이터 일관성 유지 : 여러 서버가 동시에 데이터를 처리할 때, 데이터의 정확성과 일관성을 유지하는 것이 필수적이다.
  • 확장성 : 사용자 수가 급증해도 시스템이 원활하게 동작하도록 쉽게 확장할 수 있어야 한다.

 

그렇다면 위의 과제들을 해결하면서 어떻게 하면 효율적인 시스템을 설계할 수 있을까?

 

3. 효율적인 시스템 설계 전략

3-1. 수평 확장(Horizontal Scaling)

수평 확장의 개념은 한 서버의 성능을 높이는 대신, 여러 대의 서버를 추가하여 전체 트래픽을 분산시키는 방법이다. 비유하자면 한 교실에 너무 많은 학생이 모이면 선생님이 수업을 제대로 진행하기 어려우니, 여러 교실로 나누어 진행하는 것과 같다.

 

Spring Boot/Kotlin을 사용하는 백엔드 서버를 예시로 들어보자 (모든 예시는 Spring Boot 프레임워크와 Koltin을 사용하는 백엔드이다.)

 

수평 확장은 보통 클라우드 환경(AWS, GCP, Azure)이나 컨테이너 오케스트레이션(Kubernetes)과 함께 사용한다. Spring Boot 애플리케이션은 별도의 추가 설정 없이도 여러 인스턴스를 띄우면 수평 확장이 가능하다.

 

더보기

* 관련해서 더 알아보아야 하는 것 : Docker를 이용해 여러 개의 Spring Boot 컨테이너를 실행하고, Kubernetes를 사용하여 Auto Scaling 기능을 적용하는 방법을 찾아보자.

 

3-2. 부하 분산(Load Balancing)

부하 분산은 사용자 요청을 여러 서버에 골고루 분산시켜 한 서버에 부담이 집중되지 않도록 하는 기술이다. 음식점에서 한 웨이터가 모든 손님을 상대하기 어려우니, 여러 웨이터가 각 테이블을 나누어 케어하는 것과 같다.

 

Spring Boot 애플리케이션은 외부 로드 밸런서(Nginx, HAProxy, AWS ELB 등)와 함께 사용하여 부하 분산을 쉽게 구현할 수 있다.

직접 로드 밸런싱 코드를 작성하는게 아니라 로드 밸런서 설정 파일을 통해 서버 간 트래픽 분산을 관리한다.

 

Nginx 설정 일부 예시 :

upstream spring_backend {
    server 192.168.1.101:8080;
    server 192.168.1.102:8080;
    server 192.168.1.103:8080;
}

server {
    listen 80;
    server_name yourdomain.com;

    location / {
        proxy_pass http://spring_backend;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

 

 

3-3. 캐싱(Caching)

캐싱은 자주 사용되는 데이터를 미리 저장해 두어, 데이터베이스나 다른 서버에 매번 접근하지 않고 빠르게 응답하는 기술이다. 냉장고에 좋아하는 간식을 미리 저장해두면, 매번 마트에 가지 않고도 간식을 즐길 수 있는 걸 생각하면 비슷하다.

 

Spring Boot는 Redis와 같은 캐시 솔루션과 쉽게 통합할 수  있다.

 

Redis 캐시 설정 및 사용 예시 : 
1. build.gradle.kts에 Redis 의존성 추가

dependencies {
    implementation("org.springframework.boot:spring-boot-starter-data-redis")
    // ... 기타 의존성
}

 

2. applicaiton.properties에 Redis 설정 추가

# Redis 서버 설정 (로컬에서 Redis가 실행 중임을 가정합니다)
spring.redis.host=localhost
spring.redis.port=6379

# 기본 서버 포트 (8080번 포트로 실행)
server.port=8080

 

3. Kotlin 코드 예제 - 캐시 서비스 구현

 

CacheService.kt

package com.example.demo.service

import org.springframework.beans.factory.annotation.Autowired
import org.springframework.data.redis.core.RedisTemplate
import org.springframework.stereotype.Service
import java.util.concurrent.TimeUnit

/**
 * CacheService 클래스는 Redis를 이용하여 캐시 기능을 제공하는 서비스이다.
 * 이 클래스에서는 데이터를 캐시에 저장(setCache)하고, 조회(getCache)하는 기능을 구현한다.
 */
@Service
class CacheService(@Autowired val redisTemplate: RedisTemplate<String, String>) {

    /**
     * setCache 함수는 지정된 key와 value를 캐시에 저장합니다.
     * timeout은 캐시에 데이터가 유지될 시간(초)입니다.
     */
    fun setCache(key: String, value: String, timeout: Long = 60) {
        // opsForValue()는 단순한 key-value 캐싱에 사용됩니다.
        redisTemplate.opsForValue().set(key, value, timeout, TimeUnit.SECONDS)
    }

    /**
     * getCache 함수는 지정된 key에 해당하는 캐시된 값을 반환합니다.
     * 만약 캐시에 값이 없으면 null을 반환합니다.
     */
    fun getCache(key: String): String? {
        return redisTemplate.opsForValue().get(key)
    }
}

 

AsyncService.kt

package com.example.demo.service

import org.springframework.scheduling.annotation.Async
import org.springframework.stereotype.Service

/**
 * AsyncService 클래스는 비동기 작업을 처리하기 위한 서비스이다.
 * @Async 어노테이션을 사용하여, 이 클래스의 메서드가 호출될 때 즉시 반환되고,
 * 별도의 스레드에서 작업을 수행하게 된다.
 */
@Service
class AsyncService {

    /**
     * doAsyncWork 함수는 3초 동안 대기한 후 "비동기 작업 완료!" 메시지를 콘솔에 출력한다.
     * 이 함수는 @Async 어노테이션 덕분에 호출 즉시 비동기적으로 실행된다.
     */
    @Async
    fun doAsyncWork() {
        // 3초간 대기하여, 긴 작업을 비동기적으로 처리하는 예제를 시뮬레이션한다.
        Thread.sleep(3000)
        println("비동기 작업 완료!")
    }
}

 

 

DemoController.kt

package com.example.demo.controller

import com.example.demo.service.AsyncService
import com.example.demo.service.CacheService
import org.springframework.web.bind.annotation.GetMapping
import org.springframework.web.bind.annotation.RestController

/**
 * DemoController는 REST API를 제공하는 컨트롤러이다.
 * 이 컨트롤러는 캐시 기능과 비동기 작업 기능을 테스트하기 위한 API를 제공한다.
 */
@RestController
class DemoController(
    val cacheService: CacheService,  // CacheService를 주입받아 캐시 기능을 사용한다.
    val asyncService: AsyncService   // AsyncService를 주입받아 비동기 작업을 수행한다.
) {

    /**
     * /ping API는 캐시에서 "greeting" 키의 값을 조회하고,
     * 값이 없다면 "pong"을 캐시에 저장한다.
     * 동시에 비동기 작업을 실행하고, "pong"을 응답한다.
     */
    @GetMapping("/ping")
    fun ping(): String {
        val key = "greeting"
        // 캐시에서 key "greeting"의 값을 가져온다.
        var value = cacheService.getCache(key)
        // 만약 캐시에 값이 없으면,
        if (value == null) {
            value = "pong"
            // 캐시에 60초 동안 "pong" 값을 저장한다.
            cacheService.setCache(key, value, 60)
        }
        // 비동기 작업을 실행한다.
        // 이 작업은 백그라운드에서 3초 후 완료된다.
        asyncService.doAsyncWork()
        // "pong"을 응답으로 반환한다.
        return value
    }
}

 

 

3-4. 비동기 처리와 큐

사용자의 요청을 즉시 처리하지 않고, 큐에 저장한 후 차례대로 처리하는 방식이다. (인터파크에서 앞에 몇명이 남았다고 알려주는게 큐를 사용해서 그런게 아닐까?) 놀이공원에서 사람들이 대기열에 서 있다가 순서대로 놀이기구를 타는 것처럼, 요청을들 순차적으로 처리한다.

 

@Async 어노테이션을 사용하면 쉽게 비동기 작업을 구현할 수 있다. 

간단한 예제를 보면

// AsyncService.kt
package com.example.demo.service

import org.springframework.scheduling.annotation.Async
import org.springframework.stereotype.Service

/**
 * AsyncService는 긴 작업을 비동기적으로 처리하는 서비스이다.
 * @Async 어노테이션을 사용하여, 이 메서드가 호출되면 별도의 스레드에서 실행된다.
 */
@Service
class AsyncService {

    /**
     * doAsyncWork 함수는 3초간 대기 후 콘솔에 "비동기 작업 완료!" 메시지를 출력한다.
     */
    @Async
    fun doAsyncWork() {
        // 3000 밀리초 (3초) 동안 대기한다.
        Thread.sleep(3000)
        println("비동기 작업 완료!")
    }
}

 

 

비동기에 대해서 감이 안올수 있다. Controller에서 비동기를 호출 후 처리하는 간단한 예제를 살펴보자

// DemoController.kt
package com.example.demo.controller

import com.example.demo.service.AsyncService
import org.springframework.web.bind.annotation.GetMapping
import org.springframework.web.bind.annotation.RestController

/**
 * DemoController는 간단한 REST API를 제공하여, 비동기 작업을 테스트할 수 있게 한다.
 */
@RestController
class DemoController(val asyncService: AsyncService) {

    /**
     * /asyncTest 경로를 호출하면, 비동기 작업이 실행되고 즉시 응답을 반환
     */
    @GetMapping("/asyncTest")
    fun asyncTest(): String {
        asyncService.doAsyncWork()  // 비동기 작업 실행
        return "비동기 작업이 시작되었습니다!"
    }
}

 

위 코드가 어떻게 동작할까? 사용자가 /asyncTest API를 호출하면, 서버는 즉시 "비동기 작업이 시작되었습니다!" 라는 응답을 반환하고, 백그라운드에서 3초 후 "비동기 작업 완료!" 메세지를 콘솔에 출력한다. 순서대로 실행되는게 아니다.

 

Spring Boot와 Kotlin에서 간단한 메시지 큐를 구현해보자(RabbitMQ 사용)

 

1. build.gradle.kts에 의존성 추가

dependencies {
    // RabbitMQ와 Spring Boot 연동을 위한 의존성
    implementation("org.springframework.boot:spring-boot-starter-amqp")
    // 기타 의존성...
}

 

2. application.properties에 RabbitMQ 설정

# RabbitMQ 서버 설정 (기본적으로 로컬에서 실행 중이라고 가정)
spring.rabbitmq.host=localhost
spring.rabbitmq.port=5672

 

메세지 큐 서비스 구현

// MessageQueueService.kt
package com.example.demo.service

import org.springframework.amqp.rabbit.annotation.RabbitListener
import org.springframework.amqp.rabbit.core.RabbitTemplate
import org.springframework.stereotype.Service

/**
 * MessageQueueService는 RabbitMQ를 사용하여 메시지 큐를 통한 비동기 처리를 구현한 서비스
 */
@Service
class MessageQueueService(val rabbitTemplate: RabbitTemplate) {

    /**
     * sendMessage 함수는 지정한 메시지를 "queue.tetris" 큐로 전송한다.
     */
    fun sendMessage(message: String) {
        rabbitTemplate.convertAndSend("queue.tetris", message)
    }

    /**
     * receiveMessage 함수는 "queue.tetris" 큐를 구독하여 메시지를 수신한다.
     * 메시지가 수신되면 콘솔에 출력하고, 필요한 추가 처리를 수행할 수 있다.
     */
    @RabbitListener(queues = ["queue.tetris"])
    fun receiveMessage(message: String) {
        println("메시지 수신: $message")
        // 메시지 처리 로직을 여기에 작성할 수 있다.
    }
}

 

위에서 만든 메시지 큐를 활용하는 Controller 를 만들어보자.

// QueueController.kt
package com.example.demo.controller

import com.example.demo.service.MessageQueueService
import org.springframework.web.bind.annotation.GetMapping
import org.springframework.web.bind.annotation.RestController

/**
 * QueueController는 메시지 큐를 통해 작업을 비동기적으로 처리하는 API를 제공
 */
@RestController
class QueueController(val messageQueueService: MessageQueueService) {

    /**
     * /queueTest 경로를 호출하면, "테트리스 블럭 이동"과 같은 작업 메시지를 큐에 전송한다.
     */
    @GetMapping("/queueTest")
    fun queueTest(): String {
        // 메시지 큐에 메시지를 전송한다.
        messageQueueService.sendMessage("테트리스 블럭 이동")
        return "메시지가 큐에 전송되었습니다!"
    }
}

 

사용자가 /queueTest API를 호출하면 메시지 "테트리스 블록 이동"이 RabbitMQ 큐에 전송되고, 해당 큐를 구독 중인 receiveMessage  메서드가 메시지를 수신하여 처리한다.

 

 

전체 아키텍쳐 다이어그램을 살펴보면

 

이런 식으로 표현할 수 있다. 사용자의 요청이 로드 밸런서를 통해 여러 서버에 분산되고, 각 서버는 캐싱, 비동기 처리. 메시지 큐, 데이터베이스를 활용해 안정적으로 응답을 제공하는 구조를 보여준다.

 

뭔가 부족한것 같다. 앞으로 각각의 자세한 내용을 더 공부해야겠다.

+ Recent posts