Caused by: org.springframework.dao.DataAccessResourceFailureException: Connection refused

ElasticSearch(ES)와 Spring boot를 묶었을 때 아래와 같이 docker-compose.yml를 작성할 수 있다. elasticsearch가 실행된 후 Spring boot를 실행했으나, ES와의 연결을 성공하지 못해 오류가 발생한다. 맨 위 에러 메시지 위로 올라가다 보면 아래와 같은 오류 메시지를 볼 수 있을 것이다. Caused by: org.springframework.beans.BeanInstantiationException: Failed to instantiate [org.springframework.data.elasticsearch.repository.support.SimpleElasticsearchRepository]: Constructor threw exception

ES가 정상적으로 동작하는 지 확인 한 후, Spring Boot를 실행하도록 하자.

services:
  elasticsearch:
    image: docker.elastic.co/elasticsearch/elasticsearch:8.17.0
    container_name: elasticsearch
    environment:
      - discovery.type=single-node
      - xpack.security.enabled=false
    ports:
      - "9200:9200"
    networks:
      - elk_network
    healthcheck:
      test: [ "CMD-SHELL", "curl -fsSL http://localhost:9200/_cluster/health || exit 1" ]
      interval: 10s
      timeout: 5s
      retries: 5

  springboot-app:
    build:
      context: .
      dockerfile: Dockerfile
    container_name: springboot-app
    environment:
      - SPRING_PROFILES_ACTIVE=dev
    ports:
      - "8080:8080"
    networks:
      - elk_network
    depends_on:
      elasticsearch:
        condition: service_healthy

돈이 없어 인스턴스 업그레이드나 추가를 하지 못하고 현실과 타협한 결과물을 한번 공유해보고자 한다.

아마 이 예시는 메모리가 부족한 상태에서 무중단 배포를 하고 싶은 사람들에게 도움이 될 것이다. 프리티어 사용자들은 micro 인스턴스에서 진행한다면 가벼운 서비스 정도는 무중단으로 배포할 수 있을 것이다.

작성할 예시의 스펙은 다음과 같다.

• EC2 t3a.small 인스턴스
• Ubuntu 운영체제

0. 일단 구조는 이런 식.

단순하다. FE에서 8080포트를 사용하여 통신을 하고 있기에, Nginx를 8080으로 실행하고 있다. 또한, https 통신을 하지 않고 있다는 가정이다.

1. EC2의 디스크 용량을 늘리자.

1) AWS EC2에 접속해서 할 일

EC2 small 인스턴스의 기본 디스크 용량은 8GB이다. 다음 단계인 Swap Memory를 사용하기에 추가 용량이 필요했기에, 용량을 증설했다.

용량이 충분한 사람들은 이 과정을 진행하지 않아도 되기에, 2)로 넘어가면 된다.

모든 스크린샷은 이미 증설한 이후이므로, 볼륨 크기가 달라도 무시하면 된다. AWS EC2 인스턴스 정보다. 아래 스토리지 탭에 들어가면 해당 인스턴스가 사용하는 스토리지를 확인할 수 있다. 볼륨 ID를 클릭하게 되면 스토리지 정보로 넘어가게 된다. 볼륨의 상세 정보에서 우측 상단의 수정을 클릭하여 용량을 수정하자. 필요한 만큼 용량을 늘리고 수정을 누르자. 늘리는 것은 가능하지만, 줄이는 것은 불가능하기에 신중하게 늘리자. 범용 SSD의 경우, 1GB당 월 요금 $0.1이 추가된다.

작업이 완료되면, 해당 인스턴스로 접속해 보자.

2) 인스턴스에 접속해서 할 일

파일 시스템명은 /dev/root, 파티션명은 /dev/abcd 로 가정한다.

아래 명령어를 실행하면, 각 파일 시스템의 정보가 나오는데, /dev/root 의 크기가 그대로임을 볼 수 있다. 파티션을 재할당해야 변경된다. 파티션을 재할당해 보자.

$ df -h

명령어를 실행하여 우리가 사용하는 파티션을 확인해야 한다.

$ lsblk

명령어를 실행하면 파티션이 확장된다. 파티션이 확장되었으니, 볼륨을 재할당하자.

$ sudo growpart /dev/abcd 1

이제 아래 명령어를 실행하면 볼륨이 재할당된다. 이제 각 정보를 다시 lsblk 명령어로 확인하면 용량이 늘어났음을 볼 수 있다.

$ sudo resize2fs /dev/root

2. Swap을 사용해 메모리를 늘리자.

EC2 small의 경우, 메모리 용량은 2GB이다. 100개 이상의 API를 제공하는 Spring Boot를 2개나 실행하려다가 굉장히 행복한 경험을 할 뻔했다. medium으로 올리게 되면, 메모리도 2배! 가격도 2배! 가 되어버리니 더 저렴한 방법을 찾아야 한다. 위에 언급했다시피 디스크를 활용하는 Swap 메모리를 활용할 것이다. 디스크 공간을 가상의 메모리로 사용하는 것이다. 속도가 메모리에 비해 한참 느려 성능 저하가 발생할 수 있고, 모든 메모리가 꽉 찰 경우 위험한 일이 발생할 수 있기 때문에 충분한 용량을 확보하길 바란다.

1) Swap 파일 만들기

EC2에 접속해서 아래의 명령어를 입력하자.

$ sudo dd if=/dev/zero of=/swapfile bs=128M count=32

'/dev/zero' 에 'swapfile' 을 128MB의 블록을 32개 생성한다. 해당 명령어를 사용하면 128MB * 32 = 4096MB = 4GB의 Swapfile을 생성하는 것이다. 용량은 잔여 디스크 용량 내에서 잘 조절하기를 바란다.

2) Swap 설정

생성한 swapfile에 읽기 및 쓰기 권한을 주자.

$ sudo chmod 600 /swapfile

이제 swapfile을 통해 영역을 설정하자.

$ sudo mkswap /swapfile

Swap 영역에 Swap 파일을 설정하자.

$ sudo swapon /swapfile

Swap 파일이 설정되어 있는지 확인해보고

$ sudo swapon -s

부팅 시에 자동으로 활성화 하도록 파일시스템을 수정할 것이다.

$ sudo vi /etc/fstab

맨 아래에 아래 문장을 추가하고 저장한다.

/swapfile swap swap defaults 0 0

이제 Swap 메모리가 설정됐을 것이다. 아래 명령어로 메모리 상태를 확인해보면

$ free

Swap이 생겼음을 확인할 수 있다.

이제 메모리 여유를 확보했으니까, 행복하게 Spring Boot 애플리케이션을 두 개를 켜보자!

3. Nginx를 설치해 리버스 프록시를 설정하자.

리버스 프록시를 위해 Nginx를 사용할 것이다. 8080 포트로 요청을 받고, 8081과 8082 포트에 각 Spring Boot 애플리케이션을 실행할 것이다. 8081 포트가 구버전이었다면 8082 포트를 신버전으로, 8082 포트가 구버전이었다면 8081 포트를 신버전으로 실행할 것이다.

우선 apt-get을 이용하여 Nginx를 설치하자. apt-get update 등의 내용은 생략한다.

$ sudo apt-get install nginx

nginx가 설치되었는지 확인해 보자.

$ nginx -v

버전이 출력됐다면 설치가 된 것이다.

이제 8080 포트가 실행 중인 스프링부트 애플리케이션을 바라보도록 설정할 것이다. 우선 8080 포트로 서버가 실행 중이었다면, 종료한 뒤에 nginx 설정을 하자. 아래 명령어를 입력하면 설정 파일이 실행된다.

$ sudo vi /etc/nginx/sites-available/default

vi를 이용하여 아래와 같이 수정한다.

아래의 수정한 내용을 설명하자면

1. service-url.inc를 읽어온다.
2. 요청이 오면 {service_url}로 전달한다.
3. proxy_set_header A B => 실제 요청에 A라는 헤더에 B를 할당한다.

service_url을 제외한 변수들은 nginx에서 제공하기 때문에, 구글에 검색해서 알아볼 수 있다. service_url은 service-url.inc에 기록하자.

$ sudo vi /etc/nginx/conf.d/service-url.inc

우선은 service_url을 8081 포트로 두자.

set $service_url http://127.0.0.1:8081;

이 service-url.inc의 위치를 잘 기억해 두고 이제 Spring Boot를 설정하러 가보자.

4. 다른 포트로 두 개의 Spring Boot를 실행하자.

Spring Boot의 포트 기본값은 8080이다. 이를 application.properties (혹은 .yml)을 통해 변경할 수 있다. 로컬과 배포 환경이 다를 경우, 이미 프로필을 나누어 놓았을 것이다. 배포 환경으로 구성된 두 개의 프로필을 만들자. 각 프로필에 server.profiles 값을 8081, 8082로 설정하여 저장하자.

두 개의 Spring Boot 애플리케이션을 실행했다고 가정하자.

1. 신버전이 실행되었을 때 ps 명령어를 사용해서 '신버전이 실행되었는가?' 확인하고
2. Nginx가 바라보는 포트를 변경한 뒤
3. 구버전을 종료할 수 있을 것이다. 우리는 이걸 딸깍 한 번으로 해결해 보자.

이 구식 방법을 활용하기로 했다면, 최대한 구식으로 가보자. 우리는 정말로 ps 명령어를 사용해 일하고 있는 Spring Boot가 사용하는 포트를 확인할 것이다. 실행 중인 Java는 Spring Boot 애플리케이션 하나만 있다고 생각하자.

#!/bin/bash

# java의 PID를 찾는다.
java_process=$(ps -eo pid,comm | grep java | awk '{print $1}' | head -n 1)

# pid가 없을 경우, 8082로 가정. 있을 경우 사용중인 포트 번호를 저장.
if [ -z "$java_process" ]; then
    current_port=8082
else
    current_port=$(lsof -Pan -p $java_process -i | grep LISTEN | awk '{print $9}' | sed 's/.*://')
fi

그럼 우리는 현재 사용 중인 포트를 찾았으니, 어떤 프로필의 Spring Boot가 실행 중인지 알 수 있다. 8081의 프로필을 set1, 8082의 프로필을 set2라고 가정하자. set2를 새로 실행시켰을 때, set2가 정상적으로 작동하는지 확인을 한 뒤, Nginx에 연결하고, set1을 종료하자.

if [ $current_port == 8082]; then
    current_profile=set2
    profile=set1
    port=8081
else
    current_profile=set1
    profile=set2
    port=8082
fi

# 새로운 앱 실행
nohup java -jar -Dspring.profiles.active=$profile $path &

# 10초 후 배포 상태 확인
sleep 10

for count in {1...10}
do
    response=$(curl -s http://localhost:$port/health
    up_cnt=$(echo $response | grep 'UP' | wc -l)

    # 배포 상태 확인 시 'UP'이라는 단어가 있는지 확인
    if [ $up_cnt -ge 1 ]
    then
        echo "> 배포 정상"
        break
    else
        echo "> 배포 비정상"
        echo "> Health check: ${response}"
    fi

    # 최대 10회 배포 상태 확인 시도. 10회가 끝나면 스크립트 종료.
    if [ $count -eq 10 ]
    then
        echo "> 배포 실패."
        echo "> 배포 과정을 종료합니다."
        exit 1
    fi

    # 10초 후 상태 확인 재시도
    echo "> 배포 상태 확인 재시도"
    sleep 10
done

# 포트 전환
echo "set \$service_url http://127.0.0.1:${port};" | sudo tee /etc/nginx/conf.d/service-url.inc

# Nginx 재시작
sudo service nginx reload

# 이전 버전 Spring Boot 정상 종료
kill -15 $java_process

5. 뭐여 안되는디.

복붙으로 안된다. 이런 구식으로 무중단 배포를 하는 사람이 있을 리가...

만약 이 구식을 원한다면 Gracefult Shutdown 설정, Spring Boot Actuator 의존성 추가, 배포 스크립트 완성을 하면 된다.

이 방법은 실제 서비스에 23년 11월에 적용한 방법이다. 메모리를 2GB 가까이 잡아먹는 100개 이상(150개에 가까운)의 API를 제공하는 녀석을 어떻게든 낮에도 배포를 하고 싶었다. 당시 나 혼자서 구상할 수 있는 최대한의 방법이었다. 근데 아무도 이렇게는 안했으면 한다. Docker도 쓰고, Jenkins나 Github Actions로 CI도 구현하고, CodeDeploy도 사용해서 더 좋은 방법으로 하면 아마 이거보다 훨씬 더 좋은 글을 쓸 수 있는 사람이 될 것이다. 이런 글(경험담)을 또 쓴다면 '진흙탕 뒹굴기 시리즈' 정도로 칭할 듯

참고 링크를 남기고 이만 끝.

혹시 진짜 만약에 이 방법을 택하고 하다가 막히면 언제든지 아래 이메일 보내주세요. growing.lilbear@gmail.com

참고 링크

1. Swap Memory - https://repost.aws/ko/knowledge-center/ec2-memory-swap-file
2. 무중단 배포 - https://github.com/jojoldu/springboot-webservice/blob/master/tutorial/7_NGINX_SSL_%EB%AC%B4%EC%A4%91%EB%8B%A8%EB%B0%B0%ED%8F%AC.md

• null일 수 있는 콘테이너 객체
• 쉽게 말하면 그냥 널일수도 있고, 아닐수도 있고

왜 있을까요?

공식 문서을 읽어보면 나온다.

API Note: Optional is primarily intended for use as a method return type where there is a clear need to represent "no result," and where using null is likely to cause errors. A variable whose type is Optional should never itself be null; it should always point to an Optional instance.

없다는 것을 확실하게 표현할 수 있게 하려고 만든 것으로 표현한 것 같다.

어떻게 쓸까요?

이 친구가 참 괴상한 친구인 것이 사용할 때 주의사항이 26가지나 된다. 링크

나는 그래서 가급적 지양하는 편인데, 필요한 경우 아래를 지켜서 사용한다.

1. isPresent() - get() 대신 orElse() / orElseGet() / orElseThrow()

// 안 좋은 코드
Optional<Member> member = ...;
if (member.isPresent()) {
    return member.get();
} else {
    return null;
}

// 안 좋은 코드
Optional<Member> member = ...;
if (member.isPresent()) {
    return member.get();
} else {
    throw new NoSuchElementException();
}

// 좋은 코드
Optional<Member> member = ...;
return member.orElse(null);

// 좋은 코드
Optional<Member> member = ...;
return member.orElseThrow(() -> new NoSuchElementException());

2. orElse(new ...) 대신 orElseGet(() -> new ...)

orElse(...) 에서 ... 는 Optional 에 값이 있든 없든 무조건 실행된다. 따라서 ... 가 새로운 객체를 생성하거나 새로운 연산을 수행하는 경우에는 orElse() 대신 orElseGet() 을 써야한다.

// 안 좋은 코드
Optional<Member> member = ...;
return member.orElse(new Member()) // member에 값이 있든 없든 new Member()는 무조건 실행됨.

// 좋은 코드
Optional<Member> member = ...;
return member.orElseGet(Member::new);  // member에 값이 없을 때만 new Member()가 실행됨.

// 좋은 코드
Member EMPTY_MEMBER = new Member();
...
Optional<Member> member = ...;
return member.orElse(EMPTY_MEMBER); // 이미 생성됐거나 계산된 값은 orElse()를 사용해도 무방.

3. 단지 값을 얻을 목적이라면 Optional 대신 null 비교

Optional 은 비싸다. 따라서 단순히 값 또는 null 을 얻을 목적이라면 Optional 대신 null 비교를 쓰자.

// 안 좋은 코드
return Optional.ofNullable(status).orElse(READY);

// 좋은 코드
return status != null ? status : READY;

4. Optional 대신 비어있는 컬렉션 반환

Optional 은 비싸다. 그리고 컬렉션은 null 이 아니라 비어있는 컬렉션을 반환하는 것이 좋을 때가 많다. 따라서 컬렉션은 Optional 로 감싸서 반환하지 말고 비어있는 컬렉션을 반환하자.

// 안 좋은 코드
List<Member> members = team.getMembers();
return Optional.ofNullable(members);

// 좋은 코드
List<Member> members = team.getMembers();
return members != null ? members : Collections.emptyList();

// 안 좋은 코드
public interface MemberRepository<Memeber, Long> extends JpaRepository {
    Optional<List <Member>> findAllByNameContaining(String part);
}

// 좋은 코드
public interface MemberRepository<Member, Long> extends JpaRepository {
    List<Mbmer> findAllByNameContaining(String part);
}

5. Optional 을 필드로 사용 금지

Optional 은 필드에 사용할 목적으로 만들어지지 않았으며, Serializable 을 구현하지 않았다. 따라서 Optional 은 필드로 사용하지 말자.

// 안 좋은 코드
public class Member {
    private Long id;
    private String name;
    private Optional<String> email = Optional.empty();
}

// 좋은 코드
public class Member {
    private Long id;
    private String name;
    private String Email;
}

6. Optional 을 생성자나 메서드 인자로 사용 금지

Optional을 생성자나 메서드 인자로 사용하면, 호출할 떄마다 Optional 을 생성해서 인자로 전달해줘야 한다. 하지만 호출되는 쪽, 즉 api나 라이브러이 메서드에서는 인자가 Optional 이든 아니든 null 체크를 하는 것이 언제나 안전하다. 그러므로 null 체크를 하자.

// 안 좋은 코드
public class HRManager {
    public void increaseSalary(Optional<Member> member) {
        member.ifPresent(member -> memberincreaseSalary(10));
    }
}
hrManager.increaseSalary(Optional.ofNullable(member));

// 좋은 코드
public class HRManager {
    public void increaseSalary(Member member) {
        if (member != null) {
            member.increaseSalary(10);
        }
    }
}
hrManager.increaseSalary(member);

7. Optional을 컬렉션의 원소로 사용 금지

컬렉션에는 많은 원소가 들어갈 수 있다. 따라서 비싼 Optional 을 원소로 사용하지 말고 원소를 꺼낼 때나 사용할 때 null 체크하는 것이 좋다.

// 안 좋은 코드
Map<String, Optional<String>> sports = new HashMap<>();
sports.put("100", Optional.of("BasketBall"));
sports.put("101", Optional.ofNullable(someOtherSports));
String basketBall = sports.get("100").orElse("BasketBall");
String unknown = sports.get("101").orElse("");

// 좋은 코드
Map<String, String> sports = new HashMap<>();
sports.put("100", "BasketBall");
sports.put("101", null);
String basketBall = sports.getOrDefault("100", "BasketBall");
String unknown = sports.computeIfAbsent("101", k -> "");

8. of() , ofNullable() 혼동 주의

of(X) 은 X 가 null 이 아님이 확실할 때만 사용해야 하며, X가 null 이면 NullPointerException이 발생한다. ofNullable(X) 은 X가 null 일 수도 있을 때만 사용해야 하며, X가 null이 아님이 확실하면 of(x) 를 사용해야 한다.

// 안 좋은 코드
return Optional.of(member.getEmail());

// 안 좋은 코드
return Optional.ofNullable("READY");

// 좋은 코드
return Optional.ofNullable(member.getEmail());

// 좋은 코드
return Optional.of("READY");

9. Optional<T> 대신 OptionalInt, OptionalLong, OptionalDouble

Optional 에 담길 값이 int, long, double 이라면 Boxing/Unboxing 이 발생하는 Optional<Integer>, Optional<Long>, Optional<Double> 을 사용하지 말고, OptionalInt, OptionalLong, OptionalDouble 을 사용하자.

// 안 좋은 코드
Optional<Integer> count Optional.of(38);
for (int i = 0; i < count.get(); i++) { ... }

// 좋은 코드
Optional count = Optional.of(38);
for (int i = 0; i <count.getAsInt(); i++) { ... }

• 컬렉션, 배열 등의 저장 요소를 하나씩 참조하여 함수형 인터페이스(람다식)를 적용하며 반복적으로 처리할 수 있도록 해주는 기능.
• 그냥 쉽게 말하면 반복문을 대체 할 수 있는 기능
• 자바 8부터 추가됐으니 참고하길.

왜 써요?

처음에는 정말 왜 사용해야 하는지 이해하지 못했다. 메서드들을 알고 있어야 코드의 이해가 가능하고, 성능 또한 for문 혹은 foreach문보다 좋지 않다. 하지만 로직이 복잡하면 for문안에 담는 것보다 훨씬 간결하게 작성할 수 있고, 유지보수가 수월하다. (그리고 쓰다보면 이어지는게 재밌다)

어떻게 생겼어요?

Obejct.스트림생성().중개연산().최종연산();

• 최종연산을 하지 않으면 오류가 난다.

어떻게 써요?

메서드들을 정리한 자료가 있는데, 진짜 너무 많다. 자주 사용하는 것들의 예시를 들어놓겠다.

public class Ball {
    private int number;

    public Ball(int number) {
        this.number = number;
    }

    public void getNumber() {
        return this.number;
    }

    //...
}

public class MapSample {
    // 스트림을 이용한 메서드
    public int sumAll(List<Ball> balls) {
        return balls.stream()
                .mapToInt(ball -> ball.getNumber())
                    .sum();
    }
    // for문을 이용한 메서드
    public int sumAllByFor(List<Ball> balls) {
        int sum = 0;
        for (int i = 0; i < balls.size(); i++) {
            sum += balls.get(i).getNumber();
        }
        return sum;
    }
    // iter을 이용한 메서드
    public int sumAllByForEach(List<Ball> balls) {
        int sum = 0;
        for (Ball ball : balls) {
            sum += ball.getNumber();
        }
        return sum;
    }
}

public class FilterSample {
    // 스트림을 이용한 메서드
    public Ball findBall(List<Ball> balls, int number) {
        return balls.stream()
                .mapToInt(ball -> ball.getNumber())
                    .filter(ball -> ball.getNumber() == number)
                    .findFirst()
                    .orElseThrow(RuntimeException::new);
    }
    // for문을 이용한 메서드
    public Ball findBallByFor(List<Ball> balls, int number) {
        for (int i = 0; i < balls.size(); i++) {
            if (balls.get(i).getNumber() == number) {
                return balls.get(i);
            }
        }
        throw new RuntimeException();
    }
    // iter을 이용한 메서드
    public Ball findBallByForEach(List<Ball> balls, int number) {
        for (Ball ball : balls) {
            if (ball.getNumber() == number) {
                return ball;
            }
        }
        throw new RuntimeException();
    }
}

하나의 콜렉션을 유일한 필드 변수로 갖고 있는 클래스.

뭣하러 만들어요?

1. 비즈니스에 종속적인 자료구조
2. Collection의 불변성을 보장
3. 상태와 행위를 한 곳에서 관리
4. 이름이 있는 컬렉션

누가 쓰라고 그랬어요?

'객체지향 생활체조 규칙 8 - 일급 콜렉션 사용'

설명

비즈니스에 종속적인 자료구조

대표적인 예로, 생성 시에 필요한 검증 로직들을 비즈니스 로직을 담당하는 서비스에서 옮겨갈 수 있다. 서비스단에서 그 검증 로직 다 찾아보고 왜 검증해야 하는지 알아내는 것보다, 한 클래스 내에서 확인할 수 있다면? 아니면 그 로직을 알 필요가 없다면? 일급 컬렉션의 강점이 나타나게 되는 것이다.

public class LottoService {
    public void createNumber() {
        List<Long> lottoNumbers = createNonDuplicateNumbers();
        validateSize(lottoNumbers);
        validateDuplicate(lottoNumbers);
        // ....
    }
}

public class LottoNumbers {
    private List<Long> lottoNumbers;

    public LottoNumbers(List<Long> lottoNumbers) {
        validateSize(lottoNumbers);
        validateDuplicate(lottoNumbers);
        this.lottoNumbers = lottoNumbers;
    }
}

일급 컬렉션을 필요한 조건을 충족하는 새로운 자료구조를 만든다고 생각하면 된다.

후배들이 클래스가 무엇인지 설명해달라고 할 때, 너가 원하는 타입을 만든다고 생각하면 된다고 해준다.

원하는 값을 담는(필드 변수), 필요한 기능을 갖고 있는(메서드) 타입을 만드는 거니까.

그것과 동일하게 새로운 자료구조를 만든다고 생각하면 될 것 같다.

대신 필드가 컬렉션 하나인 것이 차이점이겠다.

Collection의 불변성을 보장 (가능하다)

그냥 클래스를 생성할 시에, 필드에 접근을 불가능하게 만들면 된다.

필드의 접근제어자를 private로 설정하고, 변경하는 로직을 전혀 만들지 않으면 끝.

가능하다는 거지, 꼭 그렇다는 것은 아니다.

값을 변경하고 싶으면 아예 새로운 객체를 만들어서 반환해도 된다.

상태와 행위를 한 곳에서 관리

굳이 설명을 담지는 않겠다. 위에서 언급한 것을 읽으면 당연시된다.

이름이 있는 컬렉션

일급 컬렉션 이니까 이름이 있는 커스텀된 컬렉션이 된다. 의미를 컬렉션 명에 담을 수 있다.