순전히 개인적인 경험과 주관적인 의견으로 작성된 글입니다.

잘못된 정보가 있으면 지적 부탁드립니다.

Overview

웹플럭스는 흔히 비동기/논블로킹 이벤트루프 모델이라고 말합니다.

적은 수의 쓰레드로 많은 요청을 처리할 수 있는 걸 장점으로 내세우고 있는데, 항상 의문이 있었습니다.

흔히 블록킹 구간이라고 하는 네트워크 I/O 또는 데이터베이스 I/O 작업은 결국 어디선가 또는 누군가가 대기했다가 결과를 받아서 처리해야 합니다.

기존 MVC 모델에서 비동기 처리를 하면 별도의 쓰레드를 사용해서 처리했었기 때문에 큰 의문이 없었지만 쓰레드 하나로는 어떻게 처리하는지 궁금했습니다.

만약 웹플럭스에서도 별도 쓰레드풀을 만들어 처리한다면 요청량 증가에 따라 점점 백그라운드 쓰레드가 많아질거고 적은 수의 쓰레드로 컨텍스트 스위칭 비용 최소화 라는 장점이 무색해질 것 같았습니다.

이것저것 찾아본 결과 I/O 요청은 커널단으로 넘기고 JVM 은 I/O 요청에 필요한 데이터 복사만 해주기 때문에 블록킹 구간이 없다는 정보를 얻었습니다.

그렇다면 실제로 쓰레드가 처리해야 하는 연산이 오래 걸리는 경우에는 어떻게 될까? 라는 의문도 함께 들었습니다.

궁굼증을 해결하기 위해 코드를 짜서 테스트를 진행해보기로 했습니다.

전체 코드는 Github 에서 확인할 수 있습니다.

  • 테스트 환경
    • Kotlin / WebFlux 기반의 Spring Boot
    • 쓰레드는 단 하나만 사용
  • 테스트 내용
    • WebClient 로 응답이 오래 걸리는 외부 API 요청 시 쓰레드가 블락되는가?
    • 쓰레드가 처리해야 하는 무거운 연산 요청이 동시에 들어오면 비동기/논블로킹으로 처리 가능한가?
  • 주의사항
    • API 테스트를 할 때 동일 브라우저에서 여러 탭을 열어서 같은 요청을 보내면 순서대로 처리하기 때문에 시크릿 브라우저를 열어서 테스트 필요

1. 요청이 오래 걸리는 외부 API 를 요청하면 어떻게 될까?

Spring WebFlux 에서 외부 API 를 호출할 때는 WebClient 를 사용합니다.

WebClient 는 기존 MVC 모델에서 사용하던 RestTemplate 클래스와는 다르게 비동기로 API 를 호출하고 응답받을 수 있는 기능을 지원합니다.

WebClient 는 Spring WebFlux 에서 사용하는 이벤트 루프 워커 쓰레드를 공유합니다.

그래서 만약 외부 API 요청 시에 쓰레드가 Block 된다면 굉장한 문제가 생깁니다.

웹플럭스는 Core * 2 개의 쓰레드를 사용하기 때문에 많은 쓰레드를 사용하는 MVC 모델에 비해 쓰레드 블락의 영향이 큽니다.


1.1. 외부 API 서버 만들기

@SpringBootApplication
class ServerMvcApplication

fun main(args: Array<String>) {
    System.setProperty("server.port", "8181")
    runApplication<ServerMvcApplication>(*args)
}

@RestController
class BlockController {
    val log: Logger = LoggerFactory.getLogger(BlockController::class.java)

    @GetMapping("/block/{id}")
    fun block(@PathVariable id: Long): ResponseEntity<String> {
        log.info("request $id start")
        Thread.sleep(5000)
        log.info("request $id end")
        return ResponseEntity.ok().body("response $id")
    }
}

API 요청을 받아 5초 뒤에 응답해주는 서버입니다.

일반적인 상황을 위해 외부 서버는 Spring Boot WebMVC 로 만들었습니다.

로컬에서 동시에 띄우기 위해 포트를 8181 로 변경하였고 /block/{id} API 를 요청하면 쓰레드를 5초동안 슬립시킨 후에 응답합니다.

MVC 모델은 요청마다 쓰레드를 하나씩 할당해서 처리하기 때문에 여러 요청이 들어와도 5초씩만 지연됩니다.


크롬 브라우저와 시크릿 브라우저에서 요청하면 별도 쓰레드에서 각각 요청을 처리하는 걸 볼 수 있습니다.


1.2. WebFlux 서버 만들기

위에서 만든 MVC 를 호출하는 웹플럭스 서버를 만들어봅니다.


1.2.1. Server Code

@SpringBootApplication
class ServerWebfluxApplication

fun main(args: Array<String>) {
    // 쓰레드 1개만 사용
    System.setProperty("reactor.netty.ioWorkerCount", "1")
    runApplication<ServerWebfluxApplication>(*args)
}

@Configuration
class RouterConfig {
    val log: Logger = LoggerFactory.getLogger(RouterConfig::class.java)

    @Bean
    fun route(handler: RouterHandler) = router {
        "v1".nest {
            GET("/call/{id}", handler::call)

            before { request ->
                log.info("Before Filter ${request.pathVariable("id")}")
                log.info("$request")
                request
            }

            after { request, response ->
                log.info("After Filter ${request.pathVariable("id")}")
                response
            }
        }
    }
}

@Controller
class RouterHandler {
    val log: Logger = LoggerFactory.getLogger(RouterHandler::class.java)
    val webClient = WebClient.create("http://localhost:8181")

    fun call(request: ServerRequest): Mono<ServerResponse> {
        val id = request.pathVariable("id")

        return webClient.get()
            .uri("/block/$id")
            .retrieve()
            .bodyToMono(String::class.java)
            .flatMap {
                ServerResponse.ok().json().body(
                    Mono.just("[request $id] response $it")
                )
            }
    }
}

/v1/call/{id} 요청을 받으면 http://localhost:8181/block/{id} 호출한 결과값을 응답하는 API 입니다.

쓰레드 블록 여부를 판단해야 하기 때문에 워커 쓰레드 갯수를 1 개로 세팅합니다.


1.2.2. Thread Count

실제로 쓰레드가 한 개만 뜬 것을 확인할 수 있습니다.

요청은 모두 하나의 쓰레드로만 들어오며 쓰레드가 블락되는 경우 API 응답이 지연될 겁니다.


1.2.3. Log

쓰레드 하나로만 처리하는데도 Block 되지 않고 각각 5초만에 응답을 리턴합니다.


1.3. WebClient 대신 RestTemplate 을 사용하면?

@Controller
class RouterHandler {

    fun rest(request: ServerRequest): Mono<ServerResponse> {
        val id = request.pathVariable("id")
        val restTemplate = RestTemplate()
        val response = restTemplate.getForObject("http://localhost:8181/block/$id", String::class.java)

        return ServerResponse.ok().json().body(
            Mono.just(response!!)
        )
    }
}

테스트 하는 김에 RestTemplate 으로도 테스트 해봤습니다.

/v1/rest/{id} 를 호출하면 쓰레드 1개를 블록시키기 때문에 요청이 순차적으로 처리됩니다.


일반 브라우저와 시크릿 브라우저에서 동시에 호출해도 순서대로 처리되는 걸 볼 수 있습니다.


2. 무거운 연산을 수행하는 경우에는 어떻게 될까?

API 요청은 논블로킹으로 처리하는데 무거운 연산을 쓰레드가 직접 수행하는 경우에는 어떻게 되는지 확인해봤습니다.


2.1. Server Code

@Controller
class RouterHandler {
    val log: Logger = LoggerFactory.getLogger(RouterHandler::class.java)

    fun heavy(request: ServerRequest): Mono<ServerResponse> {
        val id = request.pathVariable("id")

        (0..1_000_000_000).forEach {
            if (it % 100_000_000 == 0) {
                log.info("Request [$id] for: $it")
            }
        }

        return ServerResponse.ok().json().body(
            Mono.just("heavy response $id")
        )
    }
}

for 문을 많이 돌면서 오래 걸리는 API 를 만들었습니다.


2.2. Log

위와 마찬가지로 쓰레드는 하나만 사용했습니다.

로그를 보면 알 수 있듯이 기존 요청을 처리하는 동안 대기했다가 순서대로 요청을 처리하는 것을 알 수 있습니다.


2.3. Response Time

id=1 인 요청은 5초만에 응답했지만 id=2 인 경우에는 앞의 연산 때문에 지연되어 9초나 걸린 것을 확인할 수 있습니다.


Conclusion

직접 테스트를 해보니 인터넷에서 알아본 것처럼 NIO 쓰레드를 사용하면 I/O 요청 시 쓰레드가 대기하지 않고 다른 일을 처리할 수 있었습니다.

하지만 실제로 쓰레드가 일을 해야하는 무거운 연산을 수행하는 경우에는 응답이 지연되는 결과를 얻었습니다.

흔히 웹플럭스를 사용하기 좋은 환경으로 무거운 연산이 적고 I/O 위주의 로직이 존재하는 환경을 이야기합니다.

DB 를 연동할 때도 R2DBC 나 NoSQL 처럼 Reactive 모델을 지원하지 않는 경우 블로킹 구간이 발생해서 사용할 수 없다 라고도 말합니다.

그동안은 막연하게 생각해오기만 했는데 실제로 테스트 해서 눈으로 확인해보니 이유를 알 수 있었습니다.

Overview

Java 에서 메서드를 호출 시 파라미터를 전달하는 방법에 대해 알아봅니다.

순서는 다음과 같이 진행합니다.

  1. Call by Value, Call by Reference 차이
  2. Java 에서의 파라미터 전달 방법
  3. JVM 메모리에 변수가 저장되는 위치
  4. 원시 타입 (Primitive Type) 전달
  5. 참조 타입 (Reference Type) 전달

1. Call by Value, Call by Reference

메서드를 호출할 때 파라미터를 전달하는 방법에는 두 가지가 있습니다.


1.1. Call by Value

Call by Value 는 메서드를 호출할 때 값을 넘겨주기 때문에 Pass by Value 라고도 부릅니다.

메서드를 호출하는 호출자 (Caller) 의 변수와 호출 당하는 수신자 (Callee) 의 파라미터는 복사된 서로 다른 변수입니다.

값만을 전달하기 때문에 수신자의 파라미터를 수정해도 호출자의 변수에는 아무런 영향이 없습니다.


1.2. Call by Reference

Call by Reference 는 참조 (주소) 를 직접 전달하며 Pass By Reference 라고도 부릅니다.

참조를 직접 넘기기 때문에 호출자의 변수와 수신자의 파라미터는 완전히 동일한 변수입니다.

메서드 내에서 파라미터를 수정하면 그대로 원본 변수에도 반영됩니다.


2. Java 에서의 파라미터 전달 방법

그럼 Java 에서는 어떤 방법을 사용할까요?

Java 로 개발을 해봤다면 메서드로 변수를 넘기고 거기서 값을 수정해본 경험이 있을 겁니다.

그래서, Call by Reference 라고 오해하기 쉽지만, Java 는 오직 Call by Value 로만 동작합니다.


3. JVM 메모리에 변수가 저장되는 위치

Java 의 Call by Value 에 대해 이해하기 위해선 먼저 변수 생성 시 메모리에 어떤 식으로 저장되는 지 알아야 합니다.

Java 에서 변수를 선언하면 Stack 영역에 할당됩니다.

원시 타입 (Primitive Type) 은 Stack 영역에 변수와 함께 저장되며

참조 타입 (Reference Type) 객체는 Heap 영역에 저장되고 Stack 영역에 있는 변수가 객체의 주소값을 갖고 있습니다.


그림으로 표현하면 이렇습니다.

원시 타입, 참조 타입을 생성할 때마다 동일한 방식으로 메모리에 할당됩니다.

이제 각 타입별로 파라미터를 넘겨줄 때 어떤 식으로 동작하는지 알아봅니다.


4. 원시 타입 (Primitive Type) 전달

원시 타입은 Stack 영역에 위치합니다

메서드 호출 시 넘겨받는 파라미터들도 원시 타입이라면 Stack 영역에 생성됩니다.

간단한 예시 코드와 함께 확인해봅니다.


public class PrimitiveTypeTest {

    @Test
    @DisplayName("Primitive Type 은 Stack 메모리에 저장되어서 변경해도 원본 변수에 영향이 없다")
    void test() {
        int a = 1;
        int b = 2;

        // Before
        assertEquals(a, 1);
        assertEquals(b, 2);

        modify(a, b);

        // After: modify(a, b) 호출 후에도 값이 변하지 않음
        assertEquals(a, 1);
        assertEquals(b, 2);
    }

    private void modify(int a, int b) {
        // 여기 있는 파라미터 a, b 는 이름만 같을 뿐 test() 에 있는 a, b 와 다른 변수
        a = 5;
        b = 10;
    }
}

위 코드에서 test() 의 변수 a, bmodify(a, b) 로 전달받은 파라미터 a, b 의 이름과 값은 같습니다.

하지만 다른 변수입니다.

modify(a, b) 를 호출하는 순간 Stack 영역에 새로운 변수 a, b 가 새로 생성되어 총 4 개의 변수가 존재합니다.


그림으로 보면 한눈에 이해가기 쉽습니다.

Stack 내부에 test()modify() 라는 영역이 나뉘어져 있고 거기에 동일한 이름을 가진 변수 a, b 가 존재합니다.

그래서 modify() 영역의 값을 바꿔도 test() 영역의 변수는 변화가 없습니다.

원시 타입의 전달은 값만 전달하는 Call by Value 로 동작합니다.


5. 참조 타입 (Reference Type) 전달

참조 타입은 원시 타입과는 조금 다릅니다.

변수 자체는 Stack 영역에 생성되지만 실제 객체는 Heap 영역에 위치합니다.

그리고 Stack 에 있는 변수가 Heap 에 있는 객체를 바라보고 있는 형태입니다.

마찬가지로 코드 예시와 함께 알아봅니다.


class User {
    public int age;

    public User(int age) {
        this.age = age;
    }
}

public class ReferenceTypeTest {

    @Test
    @DisplayName("Reference Type 은 주소값을 넘겨 받아서 같은 객체를 바라본다" +
                 "그래서 변경하면 원본 변수에도 영향이 있다")
    void test() {
        User a = new User(10);
        User b = new User(20);

        // Before
        assertEquals(a.age, 10);
        assertEquals(b.age, 20);

        modify(a, b);

        // After
        assertEquals(a.age, 11);
        assertEquals(b.age, 20);
    }

    private void modify(User a, User b) {
        // a, b 와 이름이 같고 같은 객체를 바라본다.
        // 하지만 test 에 있는 변수와 확실히 다른 변수다.

        // modify 의 a 와 test 의 a 는 같은 객체를 바라봐서 영향이 있음
        a.age++;

        // b 에 새로운 객체를 할당하면 가리키는 객체가 달라지고 원본에는 영향 없음
        b = new User(30);
        b.age++;
    }
}

원시 타입 코드와 마찬가지로 동일한 변수 a, b 가 존재합니다.

여기서 modify(a, b) 를 호출한 후에 a.age 의 값이 변경되었기 때문에 Call by Reference 로 파라미터를 넘겨주었다고 착각하기 쉽습니다.

하지만 Reference 자체를 전달하는 게 아니라 주소값만 전달해주고 modify() 에서 생긴 변수들이 주소값을 보고 객체를 같이 참조하고 있는 겁니다.

단계별 그림으로 확인해봅니다.


5.1. 처음 변수 선언 시 메모리 상태

원시 타입과는 다르게 변수만 Stack 영역에 생성되고 실제 객체는 Heap 영역에 생성됩니다.

각 변수는 Heap 영역에 있는 객체를 바라보고 있습니다.


5.2. modify(a, b) 호출 시점의 메모리 상태

넘겨받은 파라미터는 Stack 영역에 생성되고 넘겨받은 주소값을 똑같이 바라봅니다.


5.3. modify(a, b) 수행 직후 메모리 상태

test() 영역과 modify() 영역에 존재하는 a 라는 변수들은 같은 객체인 User01 을 바라보고 있기 때문에 객체를 공유합니다.

b 라는 변수는 서로 같은 객체인 User02 를 바라보고 있었지만 modify(a, b) 내부에서 새로운 객체를 생성해서 할당했기 때문에 User03 이라는 객체를 바라봅니다.

그래서 User03age 값을 변경해도 test() 에 있는 b 에는 아무런 변화가 없습니다.


5.4. test() 끝난 후 최종 메모리 상태

modify(a, b) 메서드를 빠져나오면 Stack 영역에 할당된 변수들은 사라집니다.

최종적으로 위와 같은 상태가 되며 User03 은 어떤 곳에서도 참조되고 있지 않기 때문에 나중에 Garbage Collector 에 의해 제거될 겁니다.


Conclusion

"결국 주소값을 넘기는 게 결국 Call by Reference 아닌가?" 라는 생각을 할 수도 있습니다.

하지만 Call by Reference 는 참조 자체를 넘기기 때문에 새로운 객체를 할당하면 원본 변수도 영향을 받습니다.

가장 큰 핵심은 호출자 변수와 수신자 파라미터는 Stack 영역 내에서 각각 존재하는 다른 변수다 라고 생각합니다.


Reference

Overview

Java8 에서는 Collection 을 다루기 위해 Stream 을 사용합니다.

Kotlin 은 Collections 자체에서 filter, map 등의 여러 가지 API 를 제공하기 때문에 매번 .streams() 를 붙이지 않아도 사용 가능하다는 장점이 있습니다.

하지만 비슷해보이는 두 코드 사이에는 큰 차이점이 하나 있는데요.

바로 Lazy Evaluation 입니다.


1. Lazy Evaluation

Lazy Evaluation 이란 쉽게 말해서 필요하지 않은 연산을 하지 않는다 라고 이해할 수 있습니다.

어떤 로직이나 연산을 그 즉시 수행하지 않고 실제로 사용되기 전까지 미루는 걸 의미합니다.

반대의 의미인 Eager Evaluation 은 연산이 있으면 그때그때 수행하는 것을 의미합니다.

Java Stream 의 예시와 함께 보면 쉽게 이해할 수 있습니다.


2. Java Streams

Stream.of(1, 2, 3, 4, 5, 6)
        .filter(e -> {
            System.out.println("filter: " + e);
            return e < 3;
        })
        .map(e -> {
            System.out.println("map: " + e);
            return e * e;
        })
        .anyMatch(e -> {
            System.out.println("anyMatch: " + e);
            return e > 2;
        });
  • (1, 2, 3, 4, 5, 6) 의 숫자 묶음 존재
  • filter: 3 보다 작은 수만 추출
  • map: 제곱으로 변환
  • anyMatch: 2 보다 큰 수가 있는지 확인

조금 지저분해 보이지만 이해를 돕기 위해 연산 중간중간마다 print 문을 추가했습니다.

위 코드를 있는 그대로 나열하면 6 개의 숫자 묶음에서 3 보다 작은 수만 뽑아서 제곱한 뒤 그 중에서 2 보다 큰 수가 있는지 확인하는 겁니다.

위 코드의 결과값은 아래와 같습니다.


filter: 1
map: 1
anyMatch: 1
filter: 2
map: 2
anyMatch: 4

총 6 개의 숫자가 있었지만 실제로 연산된 것은 두 개 뿐입니다.

anyMatch 조건에 해당하는 숫자가 나오자 이후 숫자들은 볼 필요가 없다고 판단하여 전부 생략했습니다.

이게 바로 Lazy Evaluation (필요하지 않는 연산은 하지 않는다) 입니다.


3. Kotlin Collections

listOf(1, 2, 3, 4, 5, 6)
    .filter {
        println("filter: $it")
        it < 3
    }
    .map {
        println("map: $it")
        it * it
    }
    .any {
        println("any: $it")
        it > 2
    }

그럼 이제 같은 로직을 Kotlin 으로 작성해보았습니다.

위 로직을 실행하며 어떻게 될까요?


filter: 1
filter: 2
filter: 3
filter: 4
filter: 5
filter: 6
map: 1
map: 2
any: 1
any: 4

한 눈에 봐도 결과가 다른 것을 알 수 있습니다.

Kotlin Collections 는 매 연산마다 모든 원소에 대해서 수행합니다.

데이터의 양이 많으면 많을수록 성능 차이는 더욱 벌어질 겁니다.


4. Kotlin Sequences

Kotlin 에서도 Lazy Evaluation 을 수행하게 하는 방법이 있습니다.

바로 Sequence 를 사용하는 겁니다.

위 코드에서 한줄만 추가하면 됩니다.


listOf(1, 2, 3, 4, 5, 6)
    .asSequence()   // 이 부분을 추가해서 Sequence 로 변경
    .filter {
        println("filter: $it")
        it < 3
    }
    .map {
        println("map: $it")
        it * it
    }
    .any {
        println("any: $it")
        it > 2
    }

Collection 에서 수행하지 말고 asSequence() 를 사용해서 Sequence 로 변경한 뒤에 연산을 수행하면 됩니다.

위 코드의 결과는 다음과 같습니다.


filter: 1
map: 1
any: 1
filter: 2
map: 2
any: 4

이제 불필요한 연산을 하지 않는 것을 볼 수 있습니다.


5. 왜 그럴까?

Lazy Evaluation 에 대해 좀더 설명하면 중간 단계 (intermediate step) 의 결과를 바로 리턴하냐 아니냐의 차이에 있습니다.

Kotlin Collections 은 매 연산을 수행할 때마다 결과 Collection 을 반환합니다.

이에 비해 Kotlin Sequences 또는 Java Streams 는 종료 (terminate) 함수가 호출되기 전까지는 연산을 수행하지 않습니다.

위에서 사용한 any() 함수 또한 종료 함수입니다.

이 차이를 쉽게 알려면 종료 함수가 없는 Sequences 를 사용해보면 됩니다.


5.1. Kotlin Sequences 의 Lazy Evaluation 확인

val sequence: Sequence<Int> = listOf(1, 2, 3)
    .asSequence()
    .filter {
        println("filter: $it")
        it < 2
    }
    .map {
        println("map: $it")
        it * it
    }

println("종료함수를 아직 호출하지 않음")
sequence.toList()

Sequences 는 매 함수의 결과로 Sequence 를 반환합니다.

그래서 최종적으로 Collection 으로 변환하려면 다시 toList() 를 호출해야 합니다.

toList() 역시 종료함수라서 호출되는 순간에 모든 연산이 수행됩니다.

Java Streams 의 collect(Collectors.toList()) 와 같다고 생각하시면 됩니다.


종료함수를 아직 호출하지 않음
filter: 1
map: 1
filter: 2
filter: 3

5.2. Kotlin Collections 의 Eager Evaluation 확인

val list: List<Int> = listOf(1, 2, 3)
    .filter {
        println("filter: $it")
        it < 2
    }
    .map {
        println("map: $it")
        it * it
    }

println("Collection 은 매번 List 를 반환하기 때문에 이미 연산됨")

Sequences 와 다르게 Collections 은 매 함수의 결과로 Collection 을 반환합니다.

사실상 매 함수가 모두 종료 함수라고 볼 수 있으며, 그래서 결과를 다음 단계로 넘기지 못하고 매번 전부 연산을 하는겁니다.


filter: 1
filter: 2
filter: 3
map: 1
Collection 은 매번 List 를 반환하기 때문에 이미 연산됨

Conclusion

이제 Kotlin Sequences 는 Lazy Evaluation 때문에 불필요한 연산을 생략한다는 점을 알았습니다.

하지만 Sequences 가 항상 좋은 것은 아닙니다.

Sequences by Kotlin Reference 를 보면 다음과 같은 문구가 있습니다.

So, the sequences let you avoid building results of intermediate steps, therefore improving the performance of the whole collection processing chain. However, the lazy nature of sequences adds some overhead which may be significant when processing smaller collections or doing simpler computations. Hence, you should consider both Sequence and Iterable and decide which one is better for your case.


요약하자면 Sequences 는 중간 단계의 결과를 생략하기 때문에 성능 향상이 되지만, 오버헤드가 있기 때문에 데이터가 적거나 연산이 단순한 컬렉션을 처리할 때는 오히려 안좋을 수가 있다고 합니다.

그러므로 각자 상황에 맞춰 적절한 방법을 선택하는게 가장 좋습니다.


Reference

'Language > Kotlin' 카테고리의 다른 글

Kotlin Enum  (0) 2021.10.06
Kotlin Collection Sorting (정렬)  (0) 2021.02.19
[Kotlin] Swap  (0) 2020.11.11
[Kotlin] For 문  (0) 2020.11.11
[Kotlin] String - drop, dropLast, dropWhile, dropLastWhile  (0) 2020.09.25

Overview

이미지는 HTML 에서 넣거나 CSS 에서 넣을 수 있습니다.

둘다 이미지가 노출된다는 사실은 같으나 약간의 차이점이 있습니다.


1. HTML 에서 태그 사용

<img src="/temp/image">
  • <img> 태그를 사용하면 이미지 업로드 실패 시 "깨진 이미지 아이콘" 과 "alt" 가 함께 노출된다.
  • SEO 나 성능 등에서 이점이 많다.

2. CSS 에서 background-image 속성 사용

background-image: url(image.jpg);
  • 순전히 디자인 목적이라면 CSS 를 이용해도 된다.
  • CSS 는 이미지 사이즈가 큰 경우 로딩하는데 시간이 더 걸린다
  • 이미지 업로드 실패 시 아무것도 노출되지 않는다.

3. 각각 언제 사용하는게 좋을까?

만약 배경 이미지가 있어도 그만 없어도 문제 없는 상황이라면 실패했을 경우 아예 이미지가 노출되지 않는 편이 좋을 수도 있습니다.

이미지가 없어도 컨텐츠를 이해하는 데 무리가 없기 때문에 사용자에게 굳이 에러 상황을 알려줄 필요가 없습니다.

img 태그는 이미지가 컨텐츠와 관련이 깊고 검색 엔진에 노출이 필요한 경우에 사용하고 background-image 속성은 순수하게 디자인을 위한 목적인 경우에 사용합니다.

제 개인적인 생각으로는 웹 접근성도 고려해서 웬만하면 HTML 태그를 사용하는 게 좋다고 생각합니다.


Reference

'Language > HTML and CSS' 카테고리의 다른 글

Textarea 내부에 HTML Tag 를 넣고 싶을 때  (2) 2021.05.21

Overview

지난 포스팅에서는 AWS 에서 EC2 인스턴스를 생성하고 Spring Boot 서버를 띄워 외부에서 요청하는 것까지 해봤습니다.

이번에는 데이터베이스 연동을 위해 RDS 인스턴스를 생성하고 이전에 만든 EC2 와 연동하는 것까지 진행해봅니다.

다음과 같은 순서로 진행됩니다.

  • RDS 인스턴스 생성
  • 보안 그룹 설정
  • RDS 접속 테스트
  • 파라미터 그룹 설정

1. RDS 인스턴스 생성

EC2 서버에 DB 연동을 하기 위한 RDS 인스턴스를 생성해봅니다.


1.1. RDS 메뉴로 이동

EC2 와 마찬가지로 검색하면 쉽게 찾을 수 있습니다.


1.2. 데이터베이스 생성

대시보드에서 선택해도 되고 아니면 이렇게 메뉴에 진입해서 직접 데이터베이스 생성을 눌러도 됩니다.


1.3. DB 종류 선택

저는 MySQL 을 선택했습니다.


1.4. DB 설정 입력

데이터베이스 이름, 마스터 이름, 비밀번호를 입력합니다.

실제 DB 에 접근할 때 사용할 정보이므로 신중하게 입력해야 합니다.


1.5. 스토리지 설정

사실 프리 티어일 때는 선택권이 거의 없습니다.

그냥 대부분 기본 설정을 사용하면 되는데 "스토리지 자동 조정" 저 부분 체크만 해제해주시면 됩니다.

안그러면 개발을 진행하다 임계값이 초과되면 자동으로 스토리지가 늘어나서 과금될 가능성이 있습니다.


1.6. 보안 그룹 설정

퍼블릭 액세스는 "예" 로 지정해줍니다.

"아니요"를 선택하면 퍼블릭 IP 주소가 할당되지 않기 때문에 외부에서 접속할 수 없습니다.

그리고 EC2 와 마찬가지로 보안 그룹을 설정하거나 새로 생성할 수 있습니다.

기존에 사용 중인게 있다면 "기존 항목 선택" 을 누르고 보안 그룹을 추가하면 됩니다.

여기서는 "새로 생성" 으로 해보겠습니다.


1.7. 추가 구성

추가 구성에서 데이터베이스 이름을 적고 자동 백업을 비활성화 합니다.

어차피 개발용이라 데이터가 중요하지 않아서 자동 백업을 비활성화 했지만, 만약 지워져도 복구해야 하는 데이터라면 당연히 백업을 활성화 해야 합니다.

여기까지 진행했으면 "데이터베이스 생성" 을 눌러서 생성을 완료합니다.

생성 완료까지는 시간이 좀 걸립니다.


2. RDS 보안 그룹 설정

RDS 인스턴스를 생성할 때 보안 그룹을 새로 생성한 걸 기억하실 겁니다.

데이터베이스는 서버에서 접근 가능해야 하기 때문에 보안 그룹 설정이 추가로 필요합니다.

여기서 서버란 곧 "EC2 인스턴스의 탄력적 IP" 를 의미합니다.

탄력적 IP 를 직접 넣는 대신 손쉽게 설정할 수 있는 방법이 있습니다.


2.1. 현재 보안 그룹 확인

RDS 인스턴스 정보로 들어가면 하단에서 보안 그룹 규칙을 확인할 수 있습니다.

친절하게 제가 접속할 수 있게 로컬 IP 만 인바운드 규칙에 추가해두었네요.

아웃바운드는 EC2 와 마찬가지로 모든 트래픽에 대해 열어두었습니다.

RDS 보안 그룹은 EC2 보안 그룹이랑 별도로 관리하지 않고 같은 곳에서 관리합니다.

따라서, 보안 그룹을 편집하려면 EC2 대시보드로 이동하거나 저 보안 그룹 이름을 클릭해서 페이지를 열어야 합니다.


2.2. 보안 그룹 리스트에서 EC2 보안 그룹 ID 복사

EC2 대시보드의 보안 그룹 메뉴로 이동하면 지금까지 만들었던 보안 그룹 리스트를 확인할 수 있습니다.

이전에 만들었던 MySecurityGroup 도 있을 텐데 보안 그룹 ID 를 복사해줍니다.


2.3. RDS 인바운드 규칙에 EC2 보안 그룹 ID 입력

유형을 MYSQL/Aurora 로 선택하고 사용자 지정으로 EC2 보안 그룹의 ID 를 추가하고 저장합니다.


3. RDS 접속 테스트

보안 그룹 설정까지 했다면 실제로 연결이 잘 되는지 다음 두 가지를 테스트 해봅시다.

  • 로컬 PC 에서 접속
  • EC2 인스턴스 서버에서 접속

3.1. 엔드포인트와 포트 확인

RDS 인스턴스 정보에서 엔드포인트와 포트를 확인합니다.


3.2. 로컬 PC (Sequel Ace) 에서 접속

Database GUI 툴은 여러 가지가 있으므로 각자 편한걸로 접근하시면 됩니다.

저는 Sequel Ace 에서 접속을 시도해보겠습니다.

아래 세가지만 입력 후 Connect 를 누르면 접속 가능합니다.

  • Host: RDS 엔드포인트
  • Username: RDS 생성 시 입력했던 정보
  • Password: RDS 생성 시 입력했던 정보

RDS 생성 시에 지정했던 초기 데이터베이스 이름도 확인할 수 있네요.


3.3. EC2 에서 접속

먼저 EC2 에 접속해줍니다.

우선 MySQL 을 먼저 설치해줘야 합니다.

# Ubuntu 에서 MySQL 설치
$ sudo apt-get update
$ sudo apt-get install mysql-server

그리고 mysql 명령어로 접속을 시도합니다.

권한 문제가 있으면 sudo 로 재시도 합니다.

# mysql -u {유저이름} -p --host {엔드포인트}
$ mysql -u admin -p --host my-rds-instance.ciweuig9oiko.ap-northeast-2.rds.amazonaws.com

접속이 잘 된것을 확인할 수 있습니다.


4. RDS 파라미터 그룹 설정

이제 추가적으로 파라미터 그룹 설정을 해줍시다.

RDS 는 다음 세가지 설정을 필수로 해줘야 합니다.

  • Time Zone
  • Character Set
  • Max Connection

4.1. 파라미터 그룹 페이지로 이동

먼저 파라미터 그룹 메뉴를 찾아 이동합니다.


4.2. 파라미터 그룹 생성

파라미터 그룹 패밀리는 RDS DB 와 맞춰서 선택하고 이름과 설명만 입력해서 생성합니다.

생성한 파라미터 그룹을 클릭해서 파라미터 편집을 누릅니다.


4.3. Time Zone

타임존을 Asia/Seoul 로 변경합니다.


4.4. Character Set

character_set 으로 검색해서 나온 6 개의 값을 전부 utf8mb4 로 변경해줍니다.

원래는 utf8 을 많이 사용했으나 utf8mb4 가 이모지까지 지원하기 때문에 더 많이 사용되는 추세입니다.


collation 으로 검색해서 나온 값들도 전부 utf8mb4_general_ci 로 변경해줍니다.


4.5. Max Connection

마지막으로 max_connections 을 수정해줍니다.

이 값은 원래 RDS 인스턴스 사양에 의해 결정됩니다.


4.6. 최종 변경사항 정리

저장하기 전에 미리보기를 하면 마지막으로 변경 사항들을 확인할 수 있습니다.


4.7. RDS 파라미터 그룹 변경

RDS 인스턴스로 이동해서 "수정" 버튼을 클릭합니다.

그리고 "추가 구성" 탭으로 이동해서 DB 파라미터 그룹을 변경해줍니다.


RDS 는 인스턴스를 수정할 때 예약 적용과 즉시 적용을 선택할 수 있는데 초기 설정이므로 "즉시 적용" 을 선택해줍시다.


Conclusion

이렇게 해서 EC2 에 인스턴스 연동까지 진행해봤습니다.

Spring Boot 에서 DB 에 연동하고 싶다면 로컬에서 접속한 것처럼 세팅해주고 진행하면 됩니다.

이제 DB 연동한 서버를 외부에 노출하는 것까지 가능합니다.

Overview

AWS EC2 인스턴스를 생성하고 Spring Boot 서버를 띄워보는 것까지 진행합니다.

주 목표는 서버를 외부에 제공하는 거라서 따로 배포 시스템을 구축하지 않고 단순히 빌드 파일을 복사해서 수동으로 띄울 겁니다.

글은 다음과 같은 순서로 진행합니다.

  • EC2 인스턴스 생성
  • 탄력적 IP (Elastic IP) 추가
  • 터미널에서 SSH 클라이언트로 EC2 접속
  • 보안 그룹 설정
  • Spring Boot 서버 띄우기

1. EC2 인스턴스 생성

우선 AWS 홈페이지 에 접속해서 계정을 생성 후 콘솔에 로그인 된 상태여야 합니다.

2022년 1월 16일 기준으로 작성되었으며 이후에 홈페이지 인터페이스가 변경될 수 있습니다.

2022년 4월 29일 기준으로 AWS EC2 인스턴스 생성 UI 가 바뀌어서 이부분을 수정합니다.


1.1. AWS Region 설정

우선 위치를 서울로 설정합니다.

리전에 따라서 인스턴스 위치가 결정되기 때문에 외국으로 하면 속도가 낮을 수도 있습니다.

만약 대한민국이 아닌 다른 나라에 서비스 하려면 그 도시를 선택해도 됩니다.


1.2. EC2 메뉴로 이동

처음에 대시보드가 나올텐데 만약 EC2 서비스를 찾기 힘들다면 검색해서 들어갑니다.


1.3. 새 인스턴스 생성

인스턴스 메뉴로 들어가 인스턴스 시작 버튼을 클릭합니다.


1.4. Amazon Machine Image(AMI) 및 인스턴스 유형 선택

AMI 는 어떤 서버로 구성할지 선택하는 겁니다.

여러 종류가 있어서 원하는 걸 선택하면 되고, 저는 프리 티어에 Ubuntu LTS 버전을 선택했습니다.

인스턴스 유형은 프리 티어를 사용한다면 다른 선택권이 없습니다.

스펙이 좋을수록 과금이 더 많이 되기 때문에 처음부터 좋은걸 고르기보다는 작게 시작했다가 스케일업 해나가는 걸 추천드립니다.


1.5. 키 페어 생성

키 페어는 EC2 서버에 SSH 접속을 하기 위해 필수라서 생성해야 합니다.

"새 키 페어 생성" 을 눌러 원하는 이름을 적고 생성합니다.

위 그림처럼 설정 후 생성하면 자동으로 my-key.pem 파일이 다운되며, SSH 환경에 접속하기 위해서는 해당 키 파일이 존재하는 위치로 가서 ssh 명령어를 실행하면 됩니다.

한번 다운받은 후에는 재다운 받을 수 없기 때문에 안전한 곳에 저장해둡니다.


생성한 후에는 이렇게 키 페어를 선택하면 됩니다.


1.6. 네트워크 및 스토리지 선택

네트워크 설정은 EC2 에 접속을 허용하는 ACL 을 생각하면 됩니다.

나중에 "보안 그룹" 이라는 걸로 별도 설정을 할 예정이기 때문에 SSH 트래픽만 허용해줍니다.

위 설정대로 하면 SSH 트래픽 접속 가능한 IP 가 내 IP 로 자동 설정 됩니다.


프리티어는 최대 30 까지 지원하기 때문에 해당 부분만 변경해줍니다.

볼륨 유형은 범용 SSD 로 선택해야 합니다.

만약 Provisioned IOPS SSD (프로비저닝된 IOPS SSD) 를 선택한다면 사용하지 않아도 활성화한 기간만큼 계속 비용이 발생하게 됩니다.


1.7. 인스턴스 설정 요약

다 설정하면 우측에 간단하게 지금까지 설정한 인스턴스 요약이 뜹니다.

이상한 부분이 없다면 인스턴스 시작을 눌러서 생성하면 됩니다.


1.8. 인스턴스 생성 완료

처음 화면으로 돌아오면 이렇게 인스턴스가 생성된 것을 확인할 수 있습니다.

이제 탄력적 IP 와 보안 그룹을 추가하기 위해 인스턴스 ID 를 클릭합니다.


2. 탄력적 IP (Elastic IP)

AWS EC2 인스턴스는 서버를 중지하고 다시 실행시키면 퍼블릭 IP 가 변경되기 때문에 클라이언트가 사용할 수 있는 변하지 않는 IP 가 필요합니다.

탄력적 IP (Elastic IP) 란 외부에서 인스턴스에 접근 가능한 고정 IP 입니다.

탄력적 IP 는 만들어놓고 사용하지 않더라도 과금이 되기 때문에 필요한 만큼만 생성하는 것이 중요합니다.

자세한 설명은 AWS Docs - 탄력적 IP 에서 확인하실 수 있습니다.


우선, 진짜 퍼블릭 IP 가 변경하는지 한번 확인해봅시다.

현재 생성된 인스턴스의 정보입니다.

퍼블릭 IP 로 3.35.238.69 가 할당된 것을 확인할 수 있습니다.



인스턴스를 중지 시켰다가 다시 실행시켜보았습니다.

인스턴스 ID, 프라이빗 IP 와 같은 정보는 동일한데 퍼블릭 IP 가 13.125.3.218 로 변경된 것을 볼 수 있습니다.

이렇게 퍼블릭 IP 는 변경될 가능성이 있기 때문에 변하지 않는 탄력적 IP 를 할당해주어야 합니다.



2.1. 탄력적 IP 메뉴 접근

메뉴에서 탄력적 IP 를 찾아서 들어갑니다.

아직 아무것도 할당받은 게 없기 때문에 새로운 IP 를 추가합니다.


2.2. 새로운 탄력적 IP 할당

딱히 변경할 건 없고 바로 할당을 선택해서 만들어줍시다.


2.3. 탄력적 IP 주소 선택

방금 생성한 탄력적 IP 를 선택해서 연결을 시도합니다.


2.4. 인스턴스 선택 및 연결

설정 화면에 들어가면 현재 내 인스턴스 목록을 선택할 수 있고 연결된 프라이빗 IP 까지 선택 가능합니다.


2.5. 인스턴스 정보 확인

탄력적 IP 를 연결하고 다시 인스턴스 정보를 확인해보면 IP 가 할당된 것을 볼 수 있습니다.

퍼블릭 IP 주소도 기존 값에서 탄력적 IP 주소로 자동으로 변경되었습니다.


3. SSH 클라이언트로 서버 접속

이제 내가 만든 EC2 인스턴스에 접속해봅니다.

인스턴스 정보에서 "연결" 버튼을 클릭하면 인스턴스에 연결 가능한 여러가지 방법을 알려줍니다.

여기서 "SSH 클라이언트" 로 접속하는 방법을 알아봅니다.


사실 너무 친절하게 알려주고 명령어도 복사할수 있게 되어있어서 따로 할건 없습니다.

저 방법대로 서버에 한번 접속해보고, 호스트를 등록해서 간편하게 등록하는 방법을 알아봅시다.


3.1. 터미널 실행 후 키 페어 파일 위치로 이동

터미널을 실행해서 이전에 다운 받은 키 페어 파일 위치로 이동합니다.

저는 다운로드 받은 후 따로 옮기지 않았기 때문에 Downloads 디렉토리에 들어갔습니다.

키 파일이 없으면 접속할 수 없고 다시 다운받을 수도 없기 때문에 잘 관리해야 합니다.


3.2. 키 파일 권한 변경

$ chmod 400 my-key.pem

키 파일의 권한을 변경해줍니다.


3.3. SSH 접속

가이드에 있는 대로 퍼블릭 DNS 또는 퍼블릭 IP 를 사용해서 인스턴스에 접속할 수 있습니다.

# 퍼블릭 DNS 로 접속
$ ssh -i "my-key.pem" ubuntu@ec2-3-37-206-248.ap-northeast-2.compute.amazonaws.com

# 퍼블릭 IP 로 접속
$ ssh -i "my-key.pem" ubuntu@3.37.206.248



3.4. 호스트 등록해서 간편하게 접속

이제 우리는 SSH 로 EC2 인스턴스 서버에 접속할 수 있습니다.

하지만 위에서 본 것처럼 매번 ssh -i {키 페어 파일} {ubuntu}@{탄력적 IP} 를 입력해야 합니다.

일일히 기억하기도 귀찮고 타이핑도 번거롭기 때문에 호스트로 등록해서 쉽게 접속할 수 있도록 변경해봅시다.


3.4.1. ~/.ssh 디렉터리로 키 페어 파일 복사

우선 키 페어 파일을 ~/.ssh/ 로 복사합니다.

$ cp my-key.pem ~/.ssh/

3.4.2. 키 페어 파일 권한 변경

키 페어 파일의 권한을 변경합니다.

$ chmod 600 my-key.pem



3.4.3. ~/.ssh/config 파일 생성

~/.ssh/ 디렉터리에 config 파일을 생성해서 다음과 같이 입력합니다.

이미 파일이 존재한다면 맨 아래에 입력하면 됩니다.

User 는 우분투를 선택했다면 ubuntu 고 그 외에는 전부 ec2-user 일겁니다.

$ vi ~/.ssh/config

# 아래는 파일 내용
# ssh -i {키 페어 파일} {유저 이름}@{탄력적 IP}
Host {원하는 호스트 이름}
User {유저 이름}
HostName {탄력적 IP}
IdentityFile {키 페어 파일 위치}

위 형식에 따라 저는 다음과 같이 작성했습니다.



3.4.4. 설정한 Host 이름으로 접속

이제 키 페어 파일이 없는 곳에서도 간단한 별칭으로 SSH 접속이 가능합니다.



4. 보안 그룹 설정

보안 그룹은 AWS 에서 제공하는 방화벽 모음입니다.

서비스를 제공하는 애플리케이션이라면 상관 없지만 RDS 처럼 외부에서 함부로 접근하면 안되는 인스턴스는 허용된 IP 에서만 접근하도록 설정이 필요합니다.

  • 인바운드 (Inbound): 외부 -> EC2 인스턴스 내부 허용
  • 아웃바운드 (Outbound): EC2 인스턴스 내부 -> 외부 허용

4.1. 현재 보안 그룹 확인

인스턴스 정보의 보안 탭에서 현재 설정된 보안 그룹을 확인할 수 있습니다.

처음 인스턴스를 생성할 때 아무런 보안 그룹을 설정하지 않았기 때문에 default 값만 들어가있습니다.

인바운드 규칙 해석해보면 22번 포트의 모든 IP 에 대해서 TCP 연결을 허용한다는 의미입니다.

SSH 접속을 위해 22번 포트는 기본으로 설정해준 것 같네요.

이제 새로운 보안 그룹을 만들어 봅시다.


4.2. 보안 그룹 ID 리스트 확인

인스턴스에서 보안 그룹 ID 를 보고 들어갈 수도 있지만 메뉴에서 직접 들어가면 이렇게 보안 그룹 ID 리스트를 볼 수 있습니다.

보안 그룹은 인스턴스와 별개로 존재하기 때문에 한번 만들어두면 새 인스턴스를 생성해도 한번에 적용할 수 있습니다.

우측 상단의 "보안 그룹 생성" 버튼을 눌러서 새 보안 그룹을 만들어봅시다.


4.3. 보안 그룹 생성

먼저 보안 그룹의 이름과 설명을 추가하고 인바운드 규칙과 아웃바운드 규칙을 편집합니다.


4.4. 인바운드 규칙

인바운드는 외부에서 EC2 로 요청할 때 허용할 IP 대역을 설정할 수 있습니다.

원하는 규칙을 추가하려면 "규칙 추가" 버튼을 누릅니다.

유형을 먼저 선택하면 자동으로 그에 맞는 프로토콜과 포트 범위가 고정됩니다.

웬만한 유형들이 이미 존재하기 때문에 편하게 설정할 수 있습니다.

우선 로컬 PC 에서 서버에 접속할 수 있게 SSH 를 추가하고 소스를 내 IP 로 추가합니다.

"소스" 를 선택하면 우측에 알아서 IP 가 추가되며, 특정 IP 나 대역을 넣으려면 "사용자 지정" 으로 추가할 수 있습니다.

만약 여러 사람이 함께 작업하는 프로젝트라면 각각의 로컬 PC IP 를 전부 추가해줘야 합니다.

SSH, HTTP, HTTPS 와 같은 기본 포트들을 열고 스프링 부트 프로젝트트까지 사용자 지정으로 추가해줍니다.


4.5. 아웃바운드 규칙

아웃바운드 규칙은 딱히 설정할 필요 없기 때문에 "모든 트래픽" 그대로 둡니다.


4.6. 인스턴스에서 보안 그룹 변경

다시 인스턴스로 돌아와서 "보안 그룹 변경" 버튼을 눌러줍니다.


방금 생성한 MySecurityGroup 을 추가해줍니다.

보안 그룹은 여러 개를 동시에 설정할 수 있기 때문에 기존에 설정된 launch-wizard-1 보안 그룹은 제거해줍니다.


4.7. 변경된 보안 그룹 확인

다시 인스턴스 설정을 보면 보안 그룹이 적용된 것을 볼 수 있습니다.

만약 제대로 보이지 않는다면 새로고침을 한번 해주세요.


5. EC2 인스턴스에 Spring Boot 서버 띄우기

배포 시스템 이런거 생략하고 진짜 단순하게 서버 띄우는 것만 확인해봅니다.

가장 간단한 방법은 두가지가 있는데 1번으로 진행하겠습니다.

  1. jar 파일을 빌드하여 EC2 복사 후 실행
  2. EC2 에서 프로젝트 git clone 후 실행

5.1. JDK 설치

# EC2 인스턴스
$ sudo apt-get update
$ sudo apt-get install openjdk-11-jdk

java -version 으로 명령어로 설치 여부를 확인할 수 있습니다.


5.2. Spring Boot 프로젝트 빌드

# 프로젝트 파일로 이동 후
$ gradle clean build

BUILD SUCCESSFUL in 5s
17 actionable tasks: 10 executed, 7 up-to-date


# 빌드 파일 복사
$ scp ./build/libs/api-0.0.1-SNAPSHOT.jar {호스트 이름}:/home/ubuntu

프로젝트를 빌드하면 ./build/libs 디렉토리에 jar 파일이 생성됩니다.

해당 파일을 EC2 서버로 복사합니다.

호스트 이름에는 ubuntu@{퍼블릭 IP} 또는 ubuntu@{퍼블릭 DNS} 가 들어가야 하는데 만약 ~/.ssh/config 에 호스트 이름을 등록해두었다면 간소화된 이름을 사용할 수 있습니다.

퍼블릭 IP (탄력적 IP) 또는 퍼블릭 DNS 를 그대로 사용한다면 키 페어 파일 (.pem) 이 명령어를 사용하는 위치에 존재해야 합니다.


5.3. EC2 인스턴스에서 실행

# EC2 인스턴스
$ nohup java -jar api-0.0.1-SNAPSHOT.jar &

nohup 명령어를 사용하면 로그를 nohup.out 파일에 남길 수 있습니다.


5.4. 퍼블릭 IP 또는 DNS 로 접근 확인

http://{탄력적 IP}로 접속하면 정상적으로 서버에 연결이 되는 걸 볼 수 있습니다.


Conclusion

지금까지 AWS EC2 인스턴스를 생성하고, 변하지 않는 탄력적 IP 를 할당해주고, 보안 그룹으로 방화벽을 설정한 후에 서버를 띄우는 것까지 진행해봤습니다.

다음에는 데이터베이스를 관리하는 RDS 인스턴스를 만들어보겠습니다.

'공부 > CI & CD' 카테고리의 다른 글

Github Actions CD: AWS EC2 에 Spring Boot 배포하기  (27) 2022.05.05
Github Actions CI: 자동 빌드 및 테스트 하기  (0) 2022.04.27
AWS 2편: RDS 생성 후 EC2 와 연동  (2) 2022.01.23
Docker 명령어  (0) 2022.01.05
kubectl 명령어  (0) 2021.12.23

1. docker run

$ docker run --name my-container -p 8080:8080 -d my-container-image
  • --name <name>: 도커 컨테이너 이름을 설정
  • -d: 백그라운드로 실행
  • -p <local port>:<container port>
    • 특정 포트로 연결
    • 로컬 머신의 8080 포트를 컨테이너 내부의 8080 포트와 매핑시킴
    • http://localhost:8080 으로 애플리케이션에 접근 가능

컨테이너 이미지로 컨테이너를 실행합니다.


2. docker exec

# my_continaer 컨테이너에 echo 명령어 실행
$ docker exec my_container echo "hello world!"

# my_container 컨테이너의 bash 접속
$ docker exec -it my_container bash
  • -i: 표준 입력(STDIN) 을 오픈 상태로 유지합니다. 셸에 명령어를 입력하기 위해 필요합니다.
  • -t: 의사 (PSEUDO) 터미널 (TTY) 을 할당합니다.

도커 컨테이너에 명령어를 전달하여 실행합니다.

i 옵션을 빼면 명령어를 입력할 수 없고, t 옵션을 빼면 명령어 프롬포트가 화면에 표시되지 않습니다.


3. docker images

$ docker images

도커 이미지 목록을 조회합니다.


4. docker rmi

$ docker rmi my-docker-image

도커 이미지를 삭제합니다.


Reference

1. gcloud (구글 클라우드) Cluster

클러스터는 Node 의 묶음입니다.

클러스터를 전환하면 kubectl get nodes 명령어의 정보도 달라집니다.

# 구글 클라우드 클러스터 리스트 조회
$ gcloud container clusters list

# 구글 클라우드의 클러스터를 kubeconfig 에 등록
$ gcloud container clusters get-credentials <클러스터 이름>

# 클러스터 생성 (노드 3개와 함께)
$ gcloud container clusters create <클러스터 이름> --num-nodes 3

# 구글 클라우드 클러스터 삭제
$ gcloud container clusters delete <클러스터 이름>

2. kubectl config

kubectl 명령어에 클러스터 정보, 인증 정보를 세팅해두고 편하게 사용할 수 있습니다.


2.1. Credential

# 인증 정보 조회
$ kubectl config get-users

# 인증 정보 생성
$ kubectl config set-credentials <이름> --옵션들

# 인증 정보 삭제
$ kubectl config unset users.<이름>

2.2. Cluster

# 클러스터 리스트 조회
$ kubectl config get-clusters

# 클러스터 생성
$ kubectl config set-cluster <클러스터 이름> --server <Host:Port>

# 클러스터 삭제
$ kubectl config unset clusters.<클러스터 이름>

2.3. Context

컨텍스트는 클러스터 정보와 인증 정보를 매핑해서 하나로 관리할 수 있게 해줍니다.

특정 클러스터를 사용하기 위해선 사용자 정보도 필요합니다.

만약 A 유저 정보를 사용하는 A 클러스터와 B 유저 정보를 사용하는 B 클러스터가 존재한다고 생각해 봅시다.

각 클러스터를 스위칭하기 위해선 유저 정보를 또 스위칭하는 과정을 매번 해야 합니다.

Context 는 클러스터와 유저 정보를 하나로 묶어서 컨텍스트를 스위칭 하는 것만으로도 클러스터 접근을 쉽게 할 수 있습니다.

# 컨텍스트 리스트 조회
$ kubectl config get-contexts

# 현재 컨텍스트 조회
$ kubectl config current-context

# 새로운 컨텍스트 생성
$ kubectl config set-context <컨텍스트 이름>

# 특정 컨텍스트 사용 (전환)
$ kubectl config use-context <컨텍스트 이름>

# 특정 컨텍스트 삭제
$ kubectl config unset contexts.<컨텍스트 이름>

2.4. 컨텍스트에 인증 정보와 클러스터를 매핑

# 1. username, password 로 인증 정보 생성
$ kubectl config set-credentials <Credential 이름> --username=<아이디> --password=<비밀번호>

# 2. token 으로 인증 정보 생성
$ kubectl config set-credentials <인증 정보 이름> --token=<토큰>

# 클러스터 정보 생성
$ kubectl config set-cluster <클러스터 이름> --server <Host:Port>

# 클러스터 정보와 인증 정보로 새로운 컨텍스트 생성
$ kubectl config set-context <Context 이름> --cluster=<Cluster 이름>  --user=<Credential 이름>

# 컨텍스트 사용
$ kubectl config use-context account-webapp-dev-context

3. 노드 (Node)

노드는 여러 개의 파드를 갖는 단위입니다.

$ kubectl get nodes

4. 파드 (Pod)

파드는 쿠버네티스의 가장 기본적인 배포 단위입니다.

파드는 하나 이상의 컨테이너를 포함하기 때문에 각 컨테이너를 각각 배포하지 않고 한번에 배포 가능합니다.

파드는 고유의 IP 와 Port 를 가지며, 파드 내의 컨테이너들은 localhost:<각 컨테이너 포트> 형식으로 서로 통신 가능합니다.

# 파드 조회 (-o wide 붙이면 좀더 자세한 정보 나옴) (pods = po)
$ kubectl get pods

# 좀더 자세히 조회
$ kubectl get po -o wide

# 파드 삭제
$ kubectl delete pod kubia

# 파드 전체 삭제
$ kubectl delete po --all

# 파드 상세한 설명 보기
$ kubectl describe pod <파드 이름>

# 로그 보기
$ kubectl logs <파드 이름>

# 여러 컨테이너를 포함한 파드인 경우에 컨테이너 이름 지정
$ kubectl logs <파드 이름> -c  <컨테이너 이름>

# 이전 컨테이너의 로그 확인
$ kubectl logs <파드 이름> --previous

# 파드의 환경변수 확인
$ kubectl exec <파드 이름> -- env

4.1. 새로운 파드 생성 (kubectl create vs apply)

  • create: 새로운 Object 생성. 이미 존재하면 에러
  • apply: 새로운 Obejct 생성. 이미 존재하면 변경된 부분만 반영

https://stackoverflow.com/questions/47369351/kubectl-apply-vs-kubectl-create


5. 서비스 (Service)

서비스는 외부에서 파드에 접근할 수 있게 해주는 로드 밸런서 역할을 합니다.

파드는 어떠한 이유에 의해 새로 생성되거나 지워질 수 있는데 이럴 때마다 파드의 IP 가 바뀌기 때문에 외부 클라이언트가 파드의 정확한 IP 를 추적하기 어렵습니다.

서비스는 여러 파드를 갖고 있으며 외부에서는 각 파드의 IP, Port 대신 서비스의 IP, Port 에 접근하면 서비스가 알아서 파드로 연결해줍니다.

# 서비스 생성
$ kubectl expose deployment kubia --type=LoadBalancer --port=8080 --name=kubia-http

# 서비스 조회
$ kubectl get svc

6. 레이블 (Label)

이름 그대로 라벨링의 역할을 합니다. (발음은 책마다 다른 것 같네요)

각 파드에 Key:Value 레이블을 설정해서 나중에 "레이블 셀렉터" 라는 걸로 특정 파드들을 동시에 제어할 수 있습니다.

주로 서비스가 목적에 따라 구분된 파드들을 동시에 실행하거나, 삭제하거나, 조회할 때 사용합니다.

# 레이블까지 조회
$ kubectl get po --show-labels

# 레이블 추가 (--overwrite 옵션을 추가하면 기존 레이블 수정)
$ kubectl label po <파드 이름> <레이블>=<설정>

# 특정 레이블들까지 같이 조회
$ kubectl get po -L creation_method=manual,env

# creation_method=manual 에 해당하는 파드 조회
$ kubectl get po -l creation_method=manual

# 값에 상관 없이 env 레이블을 갖고 있는 파드 조회
$ kubectl get po -l 'env'

# 위와 반대로 env 레이블을 갖고 있지 않은 파드 조회
$ kubectl get po -l '!env'

노드에도 파드처럼 레이블 세팅이 가능합니다.

# gpu=true 의 레이블을 노드에 세팅
$ kubectl label node <노드이름> gpu=true

6.1. 레이블 셀렉터 (Label Selector)

등록된 레이블 기반으로 특정 파드들을 그룹화 할 때 사용합니다.

쿼리처럼 사용 가능합니다.

  • creation_method!=manual: creation_method 레이블 갖고 있는 파드 중에 값이 manual 이 아닌 것
  • env in (prod,dev): env 레이블 값이 prod 또는 dev 로 되어 있는 파드
  • env notin (prod,dev): env 레이블 값이 prod, dev 가 아닌 파드

7. 어노테이션 (Annotation)

파드에 붙이는 주석 같은 개념입니다.

PR 번호, 작성자 등등.. 레이블처럼 키 값으로 사용할 수는 없지만 Description 역할을 합니다.

# 특정 파드에 어노테이션 추가
$ kubectl annotate pod <파드이름> mycompany.com/someannotation="foo bar"

8. 네임스페이스 (namespace)

클러스터를 논리적으로 구분하는 가상 클러스터라고 생각하면 됩니다.

Pod, Service 등을 네임스페이스 별로 생성하거나 관리할 수 있고 사용자의 권한 역시 별도로 부여할 수 있습니다.

처음 공부할 때는 레이블이랑 뭐가 다른건지 헷갈렸었는데..

레이블은 말 그대로 파드에 붙은 정보를 의미하는 거고 네임스페이스는 다음과 같은 일을 할 수 있습니다.

  • 특정 네임스페이스에 별도의 권한을 두어 파드, 서비스 등 접근 분리
  • dev, sandbox, prod 처럼 애플리케이션은 동일하지만 환경이 다른 경우 각 환경 별로 리소스를 다르게 할당 가능 (prod 환경은 좀더 많이 할당)

위에서 한번 언급했지만 네임스페이스는 논리적으로 구분하는 것이지 물리적인 구분은 아니라서 각 파드끼리 통신이 가능합니다.

# 클러스터에 있는 모든 네임스페이스를 나열
$ kubectl get ns

# 특정 네임스페이스의 파드 조회 (-n 으로 축약 가능)
$ kubectl get po --namespace <네임스페이스>

# 네임스페이스 생성 (yaml 파일로 만드는걸 추천)
$ kubectl create namespace <네임스페이스>

# 특정 네임스페이스에 파드 생성
$ kubectl apply -f kubia-manual.yaml -n <네임스페이스>

9. 레플리카셋 (ReplicaSet)

레플리카셋은 파드를 관리하는 역할을 합니다.

지정된 숫자보다 파드가 적으면 새로 생성하고, 더 많으면 삭제하는 등 항상 일정 갯수의 파드를 유지하도록 관리합니다.

파드에 문제가 생겨 갑자기 삭제되어도 레플리카셋이 부족한 파드를 새로 생성해주기 때문에 안정적으로 서비스를 운영할 수 있습니다.

과거에는 레플리케이션 컨트롤러를 사용했으나 이제 상위호환인 레플리카셋을 사용합니다.

# 레플리카셋 조회
$ kubectl get rs

10. 데몬셋 (DaemonSet)

데몬셋은 레플리카셋과 유사하지만 조금 다릅니다.

노드를 기준으로 파드 생성을 관리하며 노드 셀렉터를 사용해서 특정 노드들에만 파드를 생성시킬 수 있습니다.

# 데몬셋 조회
$ kubectl get ds

11. 잡 (Job)

잡은 지속적으로 실행되는 파드와 다르게 수행 후 종료되는 태스크입니다.

# 잡 조회
$ kubectl get jobs

+ Recent posts