---
# reviewers:
# - enisoc
# - erictune
# - foxish
# - janetkuo
# - kow3ns
# - smarterclayton
title: 복제 스테이트풀 애플리케이션 실행하기
content_type: tutorial
weight: 30
---

<!-- overview -->

이 페이지에서는 {{< glossary_tooltip term_id="statefulset" >}} 으로 복제
스테이트풀 애플리케이션을 실행하는 방법에 대해 소개한다.
이 애플리케이션은 복제 MySQL 데이터베이스이다. 이 예제의 토폴로지는
단일 주 서버와 여러 복제 서버로 이루어져있으며, row-based 비동기 복제 방식을
사용한다.

{{< note >}}
**해당 설정은 프로덕션 설정이 아니다**. 쿠버네티스에서 스테이트풀한 애플리케이션을 실행하기 위한 일반적인 패턴에
집중하기 위해 MySQL 세팅이 안전하지 않은 기본 설정으로 되어 있다.
{{< /note >}}

## {{% heading "prerequisites" %}}


* {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
* {{< include "default-storage-class-prereqs.md" >}}
* 이 튜토리얼은
  [퍼시스턴트볼륨](/ko/docs/concepts/storage/persistent-volumes/)
  그리고 [스테이트풀셋](/ko/docs/concepts/workloads/controllers/statefulset/),
  [파드](/ko/docs/concepts/workloads/pods/),
  [서비스](/ko/docs/concepts/services-networking/service/),
  [컨피그맵(ConfigMap)](/docs/tasks/configure-pod-container/configure-pod-configmap/)와 같은 핵심 개념들에 대해 알고 있다고 가정한다.
* MySQL에 대한 지식이 있으면 도움이 되지만, 이 튜토리얼은 다른 시스템을 활용하였을 때도
  도움이 되는 일반적인 패턴을 다루는데 중점을 둔다.
* default 네임스페이스를 사용하거나, 다른 오브젝트들과 충돌이 나지 않는 다른 네임스페이스를 사용한다.



## {{% heading "objectives" %}}


* 스테이트풀셋을 이용한 복제 MySQL 토폴로지를 배포한다.
* MySQL 클라이언트에게 트래픽을 보낸다.
* 다운타임에 대한 저항력을 관찰한다.
* 스테이트풀셋을 확장/축소한다.



<!-- lessoncontent -->

## MySQL 배포하기

MySQL 디플로이먼트 예시는 컨피그맵과, 2개의 서비스, 그리고 스테이트풀셋으로
구성되어 있다.

### 컨피그맵 생성하기 {#configmap}

다음 YAML 설정 파일로부터 컨피그맵을 생성한다.

{{< codenew file="application/mysql/mysql-configmap.yaml" >}}

```shell
kubectl apply -f https://k8s.io/examples/application/mysql/mysql-configmap.yaml
```

이 컨피그맵은 당신이 독립적으로 주 MySQL 서버와 레플리카들의 설정을 컨트롤할 수 있도록
`my.cnf` 을 오버라이드한다.
이 경우에는, 주 서버는 복제 로그를 레플리카들에게 제공하고
레플리카들은 복제를 통한 쓰기가 아닌 다른 쓰기들은 거부하도록 할 것이다.

컨피그맵 자체가 다른 파드들에 서로 다른 설정 영역이
적용되도록 하는 것이 아니다.
스테이트풀셋 컨트롤러가 제공해주는 정보에 따라서,
각 파드들은 초기화되면서 설정 영역을 참조할지 결정한다.

### 서비스 생성하기 {#services}

다음 YAML 설정 파일로부터 서비스를 생성한다.

{{< codenew file="application/mysql/mysql-services.yaml" >}}

```shell
kubectl apply -f https://k8s.io/examples/application/mysql/mysql-services.yaml
```

헤드리스 서비스는 스테이트풀셋
{{< glossary_tooltip text="컨트롤러" term_id="controller" >}}가 집합의 일부분인
파드들을 위해 생성한 DNS 엔트리들(entries)의 위한 거점이 된다.
헤드리스 서비스의 이름이 `mysql`이므로, 파드들은
같은 쿠버네티스 클러스터나 네임스페이스에 존재하는 다른 파드들에게 `<pod-name>.mysql`라는 이름으로
접근될 수 있다.

`mysql-read`라고 불리우는 클라이언트 서비스는 고유의 클러스터 IP를 가지며,
Ready 상태인 모든 MySQL 파드들에게 커넥션을 분배하는 일반적인 서비스이다.
잠재적인 엔드포인트들의 집합은 주 MySQL 서버와 해당
레플리카들을 포함한다.

오직 읽기 쿼리들만 로드-밸런싱된 클라이언트 서비스를 이용할 수 있다는 사실에 주목하자.
하나의 주 MySQL 서버만이 존재하기 떄문에, 클라이언트들은 쓰기 작업을 실행하기 위해서
주 MySQL 파드에 (헤드리스 서비스 안에 존재하는 DNS 엔트리를 통해)
직접 접근해야 한다.

### 스테이트풀셋 생성하기 {#statefulset}

마지막으로, 다음 YAML 설정 파일로부터 스테이트풀셋을 생성한다.

{{< codenew file="application/mysql/mysql-statefulset.yaml" >}}

```shell
kubectl apply -f https://k8s.io/examples/application/mysql/mysql-statefulset.yaml
```

다음을 실행하여, 초기화되는 프로세스들을 확인할 수 있다.

```shell
kubectl get pods -l app=mysql --watch
```

잠시 뒤에, 3개의 파드들이 `Running` 상태가 되는 것을 볼 수 있다.

```
NAME      READY     STATUS    RESTARTS   AGE
mysql-0   2/2       Running   0          2m
mysql-1   2/2       Running   0          1m
mysql-2   2/2       Running   0          1m
```

**Ctrl+C**를 입력하여 watch를 종료하자.

{{< note >}}
만약 아무 진행 상황도 보이지 않는다면, [시작하기 전에](#before-you-begin) 에 언급된
동적 퍼시스턴트볼륨 프로비저너(provisioner)가 활성화되어 있는지 확인한다.
{{< /note >}}

해당 메니페스트에는 스테이트풀셋의 일부분인 스테이트풀 파드들을 관리하기 위한 다양한 기법들이
적용되어 있다. 다음 섹션에서는 스테트풀셋이 파드들을 생성할 때 일어나는 일들을 이해할 수 있도록
일부 기법들을 강조하여 설명한다.

## 스테이트풀 파드 초기화 이해하기

스테이트풀셋 컨트롤러는 파드들의 인덱스에 따라
순차적으로 시작시킨다.
컨트롤러는 다음 파드 생성 이전에 각 파드가 Ready 상태가 되었다고 알려줄 때까지 기다린다.

추가적으로, 컨트롤러는 각 파드들에게 `<스테이트풀셋 이름>-<순차적 인덱스>` 형태의
고유하고 안정적인 이름을 부여하는데, 결과적으로 파드들은 `mysql-0`, `mysql-1`,
그리고 `mysql-2` 라는 이름을 가지게 된다.

스테이트풀셋 매니페스트의 파드 템플릿은 해당 속성들을 통해
순차적인 MySQL 복제의 시작을 수행한다.

### 설정 생성하기

파드 스펙의 컨테이너를 시작하기 전에, 파드는 순서가 정의되어 있는
[초기화 컨테이너](/ko/docs/concepts/workloads/pods/init-containers/)들을
먼저 실행시킨다.

`init-mysql`라는 이름의 첫 번째 초기화 컨테이너는, 인덱스에 따라
특별한 MySQL 설정 파일을 생성한다.

스크립트는 인덱스를 `hostname` 명령으로 반환되는 파드 이름의
마지막 부분에서 추출하여 결정한다.
그리고 인덱스(이미 사용된 값들을 피하기 위한 오프셋 숫자와 함께)를
MySQL의 `conf.d` 디렉토리의 `server-id.cnf` 파일에 저장한다.
이는 스테이트풀셋에게서 제공된 고유하고, 안정적인 신원을 같은 속성을
필요로 하는 MySQL 서버 ID의 형태로 바꾸어준다.

또한 `init-mysql` 컨테이너의 스크립트는 컨피그맵을 `conf.d`로 복사하여,
`primary.cnf` 또는 `replica.cnf`을 적용한다.
이 예제의 토폴로지가 하나의 주 MySQL 서버와 일정 수의 레플리카들로 이루어져 있기 때문에,
스크립트는 `0` 인덱스를 주 서버로, 그리고 나머지 값들은
레플리카로 지정한다.
스테이트풀셋 컨트롤러의
[디플로이먼트와 스케일링 보증](/ko/docs/concepts/workloads/controllers/statefulset/#디플로이먼트와-스케일링-보증)과
합쳐지면, 복제를 위한 레플리카들을 생성하기 전에 주 MySQL 서버가 Ready 상태가 되도록
보장할 수 있다.

### 기존 데이터 복제(cloning)

일반적으로, 레플리카에 새로운 파드가 추가되는 경우, 주 MySQL 서버가
이미 데이터를 가지고 있다고 가정해야 한다. 또한 복제 로그가 첫 시작점부터의 로그들을
다 가지고 있지는 않을 수 있다고 가정해야 한다.
이러한 보수적인 가정들은 스테이트풀셋이 초기 크기로 고정되어 있는 것보다, 시간에 따라
확장/축소하게 할 수 있도록 하는 중요한 열쇠가 된다.

`clone-mysql`라는 이름의 두 번째 초기화 컨테이너는, 퍼시스턴트볼륨에서 처음 초기화된
레플리카 파드에 복제 작업을 수행한다.
이 말은 다른 실행 중인 파드로부터 모든 데이터들을 복제하기 때문에,
로컬의 상태가 충분히 일관성을 유지하고 있어서 주 서버에서부터 복제를 시작할 수 있다는 의미이다.

MySQL 자체가 이러한 메커니즘을 제공해주지는 않기 때문에, 이 예제에서는 XtraBackup이라는
유명한 오픈소스 도구를 사용한다.
복제 중에는, 복제 대상 MySQL 서버가 성능 저하를 겪을 수 있다.
주 MySQL 서버의 이러한 충격을 최소화하기 위해, 스크립트는 각 파드가 자신의 인덱스보다
하나 작은 파드로부터 복제하도록 지시한다.
이것이 정상적으로 동작하는 이유는 스테이트풀셋 컨트롤러가 파드 `N+1`을 실행하기 전에
항상 파드 `N`이 Ready 상태라는 것을 보장하기 때문이다.

### 복제(replication) 시작하기

초기화 컨테이너들의 성공적으로 완료되면, 일반적인 컨테이너가 실행된다.
MySQL 파드는 `mysqld` 서버를 구동하는 `mysql` 컨테이너로 구성되어 있으며,
`xtrabackup` 컨테이너는
[사이드카(sidecar)](/blog/2015/06/the-distributed-system-toolkit-patterns)로서 작동한다.

`xtrabackup` 사이드카는 복제된 데이터 파일들을 보고 레플리카에 MySQL 복제를 시작해야 할
필요가 있는지 결정한다.
만약 그렇다면, `mysqld`이 준비될 때까지 기다린 후 `CHANGE MASTER TO`,
그리고 `START SLAVE`를 XtraBackup 복제(clone) 파일들에서
추출한 복제(replication) 파라미터들과 함께 실행시킨다.

레플리카가 복제를 시작하면, 먼저 주 MySQL 서버를 기억하고, 서버가 재시작되거나
커넥션이 끊어지면 다시 연결한다.
또한 레플리카들은 주 서버를 안정된 DNS 이름
(`mysql-0.mysql`)으로 찾기 때문에, 주 서버가 리스케쥴링에 의해 새로운
파드 IP를 받아도 주 서버를 자동으로 찾는다.

마지막으로, 복제를 시작한 후에는, `xtrabackup` 컨테이너는 데이터 복제를 요청하는
다른 파드들의 커넥션을 리스닝한다.
이 서버는 스테이트풀셋이 확장하거나, 다음 파드가 퍼시스턴트볼륨클레임을 잃어서 다시 복제를
수행해햐 할 경우를 대비하여 독립적으로 존재해야 한다.

## 클라이언트 트래픽 보내기

임시 컨테이너를 `mysql:5.7` 이미지로 실행하고 `mysql` 클라이언트
바이너리를 실행하는 것으로 테스트 쿼리를 주 MySQL 서버(`mysql-0.mysql` 호스트네임)로
보낼 수 있다.

```shell
kubectl run mysql-client --image=mysql:5.7 -i --rm --restart=Never --\
  mysql -h mysql-0.mysql <<EOF
CREATE DATABASE test;
CREATE TABLE test.messages (message VARCHAR(250));
INSERT INTO test.messages VALUES ('hello');
EOF
```

`mysql-read` 호스트네임을 사용하여 Ready 상태가 되었다고 보고하는 어느 서버에나 시험 쿼리를
보낼 수 있다.

```shell
kubectl run mysql-client --image=mysql:5.7 -i -t --rm --restart=Never --\
  mysql -h mysql-read -e "SELECT * FROM test.messages"
```

그러면 다음과 같은 출력를 얻을 것이다.

```
Waiting for pod default/mysql-client to be running, status is Pending, pod ready: false
+---------+
| message |
+---------+
| hello   |
+---------+
pod "mysql-client" deleted
```

`mysql-read` 서비스가 커넥션을 서버들에게 분배하고 있다는 사실을 확인하기 위해서,
`SELECT @@server_id`를 루프로 돌릴 수 있다.

```shell
kubectl run mysql-client-loop --image=mysql:5.7 -i -t --rm --restart=Never --\
  bash -ic "while sleep 1; do mysql -h mysql-read -e 'SELECT @@server_id,NOW()'; done"
```

보고된 `@@server_id`가 무작위로 바뀌는 것을 알 수 있다. 왜냐하면 매 커넥션 시도마다
다른 엔드포인트가 선택될 수 있기 때문이다.

```
+-------------+---------------------+
| @@server_id | NOW()               |
+-------------+---------------------+
|         100 | 2006-01-02 15:04:05 |
+-------------+---------------------+
+-------------+---------------------+
| @@server_id | NOW()               |
+-------------+---------------------+
|         102 | 2006-01-02 15:04:06 |
+-------------+---------------------+
+-------------+---------------------+
| @@server_id | NOW()               |
+-------------+---------------------+
|         101 | 2006-01-02 15:04:07 |
+-------------+---------------------+
```

루프를 끝내고 싶다면 **Ctrl+C**를 입력하면 되지만, 다음 단계에서의 영향을 보기 위해서
다른 창에 계속 실행시켜 놓는 것이 좋다.

## 노드와 파드 실패 시뮬레이션하기 {#simulate-pod-and-node-downtime}

단일 서버 대비 레플리카들의 풀에 의한 읽기의 가용성 향상을
시연하기 위해, 파드를 Ready 상태로 강제하면서 `SELECT @@server_id`
루프를 돌리자.

### 준비성 프로브 고장내기

`mysql` 컨테이너의 [준비성 프로브](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#define-readiness-probes)는
쿼리를 실행할 수 있는지를 확인하기 위해 `mysql -h 127.0.0.1 -e 'SELECT 1'`
명령을 실행한다.

준비성 프로브를 강제로 실패시키는 방법은 해당 명령을 고장내는 것이다.

```shell
kubectl exec mysql-2 -c mysql -- mv /usr/bin/mysql /usr/bin/mysql.off
```

이것은 `mysql-2` 파드의 실제 컨테이너의 파일시스템에 접근해서 `mysql` 명령의 이름을 변경하여,
준비성 프로브가 찾을 수 없도록 한다.
몇 초 뒤에, 파드는 컨터이너 중 하나가 준비되지 않았다고 보고할 것이다.
다음 명령을 실행시켜서 확인할 수 있다.

```shell
kubectl get pod mysql-2
```

`READY` 항목의 `1/2`를 확인하자.

```
NAME      READY     STATUS    RESTARTS   AGE
mysql-2   1/2       Running   0          3m
```

이 시점에서, `102`를 보고하지 않지만, 계속해서 `SELECT @@server_id` 루프가 실행되는 것을
확인할 수 있을 것이다.
`init-mysql` 스크립트에서 `server-id`를 `100 + $ordinal`로 정의했기 때문에,
서버 ID `102`는 `mysql-2` 파드에 대응된다는 사실을 상기하자.

이제 파드를 고치면 몇 초 뒤에 루프 출력에
나타날 것이다.

```shell
kubectl exec mysql-2 -c mysql -- mv /usr/bin/mysql.off /usr/bin/mysql
```

### 파드 삭제하기

레플리카셋이 스테이트리스 파드들에게 하는 것처럼, 스테이트풀셋 또한 파드들이 삭제되면 파드들을
다시 생성한다.

```shell
kubectl delete pod mysql-2
```

스테이트풀셋 컨트롤러는 `mysql-2` 파드가 존재하지 않는 것을 인지하고,
같은 이름으로 새로운 파드를 생성하고 같은
퍼시스턴트볼륨클레임에 연결한다.
잠시동안 서버 ID `102`가 루프 출력에서 사라지고 다시 나타나는 것을
확인할 수 있을 것이다.

### 노드 드레인하기

만약 당신의 쿠버네티스 클러스터가 여러 노드들을 가지고 있으면,
[드레인](/docs/reference/generated/kubectl/kubectl-commands/#drain)을 사용하여
노드 다운타임을 시뮬레이션할 수 있다.

먼저 MySQL 파드가 존재하고 있는 노드를 확인하자.

```shell
kubectl get pod mysql-2 -o wide
```

노드 이름은 마지막 열에서 나타날 것이다.

```
NAME      READY     STATUS    RESTARTS   AGE       IP            NODE
mysql-2   2/2       Running   0          15m       10.244.5.27   kubernetes-node-9l2t
```

그 후에, 다음 명령을 실행하여 노드를 드레인한다.
그러면 새로운 파드가 스케줄되지 않게 방지하고(cordon), 기존의 파드들을 추방(evict)한다.
`<node-name>`를 이전 단계에서 찾았던 노드의 이름으로 바꾸자.

{{< caution >}}
노드 드레인은 해당 노드에서 실행 중인 다른 워크로드와 애플리케이션들에게
영향을 줄 수 있다. 테스트 클러스터에만
다음 단계를 수행하자.
{{< /caution >}}

```shell
# 위에 명시된 다른 워크로드들이 받는 영향에 대한 주의사항을 확인한다.
kubectl drain <node-name> --force --delete-emptydir-data --ignore-daemonsets
```

이제 파드가 다른 노드에 리스케줄링되는 것을 관찰할 수 있다.

```shell
kubectl get pod mysql-2 -o wide --watch
```

출력은 다음과 비슷할 것이다.

```
NAME      READY   STATUS          RESTARTS   AGE       IP            NODE
mysql-2   2/2     Terminating     0          15m       10.244.1.56   kubernetes-node-9l2t
[...]
mysql-2   0/2     Pending         0          0s        <none>        kubernetes-node-fjlm
mysql-2   0/2     Init:0/2        0          0s        <none>        kubernetes-node-fjlm
mysql-2   0/2     Init:1/2        0          20s       10.244.5.32   kubernetes-node-fjlm
mysql-2   0/2     PodInitializing 0          21s       10.244.5.32   kubernetes-node-fjlm
mysql-2   1/2     Running         0          22s       10.244.5.32   kubernetes-node-fjlm
mysql-2   2/2     Running         0          30s       10.244.5.32   kubernetes-node-fjlm
```

그리고, 서버 ID `102`가 `SELECT @@server_id` 루프 출력에서 잠시
사라진 후 다시 보이는 것을 확인할 수 있을 것이다.

이제 노드의 스케줄 방지를 다시 해제(uncordon)해서 정상으로 돌아가도록 조치한다.

```shell
kubectl uncordon <node-name>
```

## 레플리카 스케일링하기

MySQL 레플리케이션을 사용하면, 레플리카를 추가하는 것으로
읽기 쿼리 용량을 키울 수 있다.
스테이트풀셋을 사용하면, 단 한 줄의 명령으로 달성할 수 있다.

```shell
kubectl scale statefulset mysql  --replicas=5
```

명령을 실행시켜서 새로운 파드들이 올라오는 것을 관찰하자.

```shell
kubectl get pods -l app=mysql --watch
```

파드들이 올라오면, `SELECT @@server_id` 루프 출력에 서버 ID `103` 과 `104`가 나타나기
시작할 것이다.

그리고 해당 파드들이 존재하기 전에 추가된 데이터들이 해당 새 서버들에게도 존재하는 것을
확인할 수 있다.

```shell
kubectl run mysql-client --image=mysql:5.7 -i -t --rm --restart=Never --\
  mysql -h mysql-3.mysql -e "SELECT * FROM test.messages"
```

```
Waiting for pod default/mysql-client to be running, status is Pending, pod ready: false
+---------+
| message |
+---------+
| hello   |
+---------+
pod "mysql-client" deleted
```

축소하는 것도 간단하게 할 수 있다.

```shell
kubectl scale statefulset mysql --replicas=3
```

{{< note >}}
확장은 퍼시스턴트볼륨클레임을 자동으로 생성하지만,
축소에서는 해당 PVC들이 자동으로 삭제되지 않는다.

이로써 확장을 빠르게 하기 위해 초기화된 PVC들을 보관해 두거나,
삭제하기 전에 데이터를 추출하는 선택을 할 수 있다.
{{< /note >}}

다음 명령을 실행하여 확인할 수 있다.

```shell
kubectl get pvc -l app=mysql
```

스테이트풀셋을 3으로 축소했음에도 PVC 5개가
아직 남아있음을 보여준다.

```
NAME           STATUS    VOLUME                                     CAPACITY   ACCESSMODES   AGE
data-mysql-0   Bound     pvc-8acbf5dc-b103-11e6-93fa-42010a800002   10Gi       RWO           20m
data-mysql-1   Bound     pvc-8ad39820-b103-11e6-93fa-42010a800002   10Gi       RWO           20m
data-mysql-2   Bound     pvc-8ad69a6d-b103-11e6-93fa-42010a800002   10Gi       RWO           20m
data-mysql-3   Bound     pvc-50043c45-b1c5-11e6-93fa-42010a800002   10Gi       RWO           2m
data-mysql-4   Bound     pvc-500a9957-b1c5-11e6-93fa-42010a800002   10Gi       RWO           2m
```

만약 여분의 PVC들을 재사용하지 않을 것이라면, 이들을 삭제할 수 있다.

```shell
kubectl delete pvc data-mysql-3
kubectl delete pvc data-mysql-4
```



## {{% heading "cleanup" %}}


1. `SELECT @@server_id` 루프를 끝내기 위해, 터미널에 **Ctrl+C**를 입력하거나,
    해당 명령을 다른 터미널에서 실행시키자.

   ```shell
   kubectl delete pod mysql-client-loop --now
   ```

1. 스테이트풀셋을 삭제한다. 이것은 파드들 또한 삭제할 것이다.

   ```shell
   kubectl delete statefulset mysql
   ```

1. 파드들의 삭제를 확인한다.
   삭제가 완료되기까지 시간이 걸릴 수 있다.

   ```shell
   kubectl get pods -l app=mysql
   ```

   위와 같은 메세지가 나타나면 파드들이 삭제되었다는 것을 알 수 있다.

   ```
   No resources found.
   ```

1. 컨피그맵, 서비스, 그리고 퍼시스턴트볼륨클레임들을 삭제한다.

   ```shell
   kubectl delete configmap,service,pvc -l app=mysql
   ```

1. 만약 수동으로 퍼시스턴스볼륨들을 프로비저닝했다면, 수동으로 삭제하면서,
   그 밑에 존재하는 리소스들을 또한 삭제해야 한다.
   만약 동적 프로비저너를 사용했다면, 당신이 퍼시스턴트볼륨클레임으로 삭제하면
   자동으로 퍼시스턴트볼륨을 삭제한다.
   일부 (EBS나 PD와 같은) 동적 프로비저너들은 퍼시스턴트볼륨을 삭제
   하면 그 뒤에 존재하는 리소스들도 삭제한다.



## {{% heading "whatsnext" %}}

* [스테이트풀셋(StatefulSet) 확장하기](/ko/docs/tasks/run-application/scale-stateful-set/)에 대해 더 배워보기.
* [스테이트풀셋 디버깅하기](/ko/docs/tasks/debug/debug-application/debug-statefulset/)에 대해 더 배워보기.
* [스테이트풀셋(StatefulSet) 삭제하기](/ko/docs/tasks/run-application/delete-stateful-set/)에 대해 더 배워보기.
* [스테이트풀셋(StatefulSet) 파드 강제 삭제하기](/ko/docs/tasks/run-application/force-delete-stateful-set-pod/)에 대해 더 배워보기.
* [Helm Charts 저장소](https://artifacthub.io/)를 통해
  다른 스테이트풀 애플리케이션 예제들을 확인해보기.