'EC2'에 해당하는 글 6건

EKS Fargate limit

Daily/Prog 2021. 12. 7. 21:23

3년만인가. 드디어 ECS 에서 EKS 로 넘어왔다. 그 때도 ECS 보다는 조금 더 핫했던 쿠버네티스를 써보고 싶었지만 아마 아시아 리전에는 없었던 것으로 기억한다. 그리하여 이래저래 문서들 보고 헤딩하며 클러스터를 만들었는데 무언가 deployment 가 이상 작동을 하는 듯 했다. 안그래도 헤딩 중인데 되는 것 같기도 하고 안되는거 같기도 하고, 한참 삽질 끝에 Fargate 노드가 2개 까지만 만들어지는 현상을 발견했다. 이벤트 로그 메시지:

 

"Your AWS account has reached the limit on the number of Fargate pods it can run concurrently"
당신의 AWS 계정이 동시에 실행할 수 있는 Fargate 포드 수 제한에 도달했습니다.

 

 

내 계정은 이제 막 새로 판지 얼마 안된 새삥인데, 계정에도 뭔 종류가 있나. 뭔 업그레이드를 해야 하나 싶었다. 일단 구글에서는 저 메시지로 검색된 결과가 거의 없었다. 그나마 증상이 유사한 글에서, 몇몇 제한이 있는 리전이 있어서 리전을 바꾸던지 EC2 를 써야 한다는 글을 보았다. 우선 리전에서 fargate 할당량 체크를 했다.

 

[Service Quotas] - [Fargate On-Demand resource count]
사용률 4% / 적용된 할당량 값 50 / AWS 기본 할당량 값 1,000

 

 

개널널. 아직 48개 더 만들 수 있는데 나한테 왜그러는지... 혹시나 해서 도쿄 리전에도 만들어 봤으니 똑같은 메시지. 어쩔 수 없이 [지원센터] 찬스를 이용했다. 간결하게 물었다.

 

Q. eks 를 사용중이다. Fargate Pod 수가 2가 되면 더 이상 Pod 를 추가할 수 없다.

 

그랬더니 답변이 정말 개허접스럽게 왔다.

 

A. Fargate 동시 작업 제한 문제가 발생하지 않도록 EC2 인스턴스를 시작하시겠습니까?

 

 

ㅋㅋㅋ Basic 이라고 답변을 이딴 식으로 하면 돼, 안돼? Fargate 써볼라고 하는 사람한테 할 소리? 장사 안하겠다는건데 진짜 수준 개실망. Basic 은 기술문의도 막혀있네. 우와~ 처음 알았음. 답변도 거의 반나절 걸리고 내가 진짜 웬만하면 저기 글 안올리는데 이거 너무 이상해서 올렸더니만 역시나네. 사실 내 질문은 저기서 끝나지 않았음. '이것도 안된다. 저것도 안된다.' 그랬더니 그 때부터는 모든 질문을 기술팀에 넘겼다며 답변이 오는대로 바로 전달하겠다는 말을 남겼고, 난 며칠동안 답변이 오기전 그 모든 현상들을 해결했다.

 

사실 위 문제의 해결은 그들이 할당량을 100 으로 늘리자마자 해결됐다. 이걸로 해결된게 더 어이가 없다. 이 할당량은 리전에서 생성할 수 있는 Farget 의 최대치인데 기존에도 널널했는데 이제서 됐다는게 이상하다. 위에 나타난 에러는 내 AWS 계정의 제한을 얘기했다. 그들이 내 계정의 제한을 풀어준 것이라면 이해가 가겠지만... 또, 신규 계정의 fargate 제한이 2라면 그것도 말이 안된다. 이에 대해 구체적으로도 문의를 했지만, 과다 청구를 막기 위한 제한이니 안될 경우  할당량 증가 요청을 하라는 ㄱ소리... 불이익을 받지 않기 위해 별 다섯개를 투척하긴 했다만... 

 

내 결론은 Fargate 적용된 할당량 기본값은 2임. 화면에 보여진 50은 아마도 버그일 것임. 아니면 x < 50 ? 50 이던가. 그래서 할당량 값을 새로 업데이트만 시켜줘도 50 이상의 값이 설정되는 것임. 아마 나 역시 51로만 업데이트 했어도 됐을 것임. 이것이 바로 내 소설이다. 만약 이런 문제가 발생하면 바로 할당량 요청 ㄱㄱ

 

 

service-quotas

 


WRITTEN BY
손가락귀신
정신 못차리면, 벌 받는다.

트랙백  0 , 댓글  0개가 달렸습니다.
secret

AWS VPC 시나리오

Server/AWS 2019. 5. 17. 11:54

AWS 에서 VPC 마법사로 생성할 수 있는 VPC 시나리오로 다음의 4가지를 제공한다.

public 서브넷만 있는 VPC

public 및 private 서브넷이 있는 VPC

public 및 private 서브넷이 있고 VPN 액세스를 제공하는 VPC

private 서브넷만 있고 VPN 액세스를 제공하는 VPC


이 4가지의 VPC 구성을 알고나면 어떤 커스텀 VPC 구성도 가능하다. 하나씩 살펴보자.



1. public 서브넷만 있는 VPC


위 그림에는 다음 정보가 포함된다.

vpc : 10.0.0.0/16

public subnet : 10.0.0.0/24

ec2 : 10.0.0.6 (EIP: 198.51.100.2)

router : 10.0.0.0/16(local), 0.0.0.0/0(igw-id)

internet gateway

ec2 가 인터넷에 오픈되어 있는 웹서비스 등에 알맞는 구성이다. 서브넷은 모두 private 형태이므로 외부와의 통신이 가능하려면 internet gateway 를 두어야 하며, 나가는 트래픽에 대하여 routing table 에 올바르게 설정해야 한다. 10.0.0.0/16(local) 은 해당 vpc 의 다른 서브넷으로의 통신을 가능하게 하며, 0.0.0.0/0(igw-id) 는 외부 모든 트래픽은 igw-id 로 보낸다는 설정이다. 외부에서 해당 서비스(EC2 등) 에 접근할 수 있도록 Public IP 주소도 연결해야 한다. Public IP 주소가 없다면 외부로부터 요청을 받을 수가 없을 것이고, router 에 igw 로의 설정이 없다면 외부로 응답이나 요청을 할 수 없을 것이다. 보안적인 측면에서 보안그룹(security group) 과 network acl 로도 ip/port 에 대하여 허용/거부를 설정할 수 있는데 network acl 은 보통 다 열어놓고 보안그룹만 이용한다. 모든 포트가 차단된 상태에서 웹서비스시 80, 443 포트로 들어오는 요청은 모두 열어주고, 22 포트는 개발자 ip 정도만 열어주는 형태를 추천한다. 이것이 일반적인 public 서브넷의 형태이다. 



2. public 및 private 서브넷이 있는 VPC


위 그림에는 다음 정보가 포함된다.

vpc : 10.0.0.0/16

public subnet : 10.0.0.0/24

private subnet : 10.0.1.0/24

ec2(web) : 10.0.0.5~7 (EIP: 198.51.100.1~3)

ec2(db) : 10.0.1.5~7

router1 : 10.0.0.0/16(local), 0.0.0.0/0(igw-id)

router2 : 10.0.0.0/16(local), 0.0.0.0/0(nat-gw-id)

internet gateway

nat gateway

프론트엔드와 백엔드로 나누어 일반적으로 웹서버만 public 서브넷에 두고 DB 는 private 서브넷에 두어, 외부에서는 웹서버와 접근 가능하게 하고 DB 는 웹서버에서만 접근 가능하게 하는 구성이다. 굳이 노출할 필요없는 백엔드를 외부와 차단시키는 것에 중점을 둔 구성이다. public/private 구분을 위해 igw(인터넷 게이트웨이) 로 향하지 않도록 router 를 하나 더 추가해야 한다. 옵션이지만 private 서브넷에서 일방적으로 외부와 통신을 해야 한다면 nat 게이트웨이를 생성하고 router 에 nat 게이트웨이로 트래픽을 보내도록 routing 을 추가한다. igw 가 public 서브넷과 외부와의 양방향 통신이 가능하게 한다면, nat 게이트웨이는 public 서브넷에 위치하면서 private 서브넷에 대하여 외부로 단방향 통신(요청/응답) 이 가능하게 하며 응답을 받을 수 있도록 public IP 할당이 필요하다. 외부에서는 여전히 nat 게이트웨이로 서브넷과 통신할 수 없다. (nat 게이트웨이는 유료) 웹서버의 보안그룹 설정은 시나리오1과 동일, DB 보안그룹 설정은 웹서버 보안그룹ID 로부터 오는 해당 DB 전용포트만 열어주면 된다. 예로 mysql 의 경우 3306 포트.



3. public 및 private 서브넷이 있고 VPN 액세스를 제공하는 VPC


위 그림에는 다음 정보가 포함된다.

vpc : 10.0.0.0/16

public subnet : 10.0.0.0/24

private subnet : 10.0.1.0/24

ec2(web) : 10.0.0.5~7 (EIP: 198.51.100.1~3)

ec2(db) : 10.0.1.5~7

router1 : 10.0.0.0/16(local), 0.0.0.0/0(igw-id)

router2 : 10.0.0.0/16(local), 0.0.0.0/0(vgw-id)

internet gateway

vpn (virtual private gateway, customer gateway)

시나리오2번과 비슷하지만 private subnet 을 외부는 여전히 차단하고 특정 네트워크(customer gateway)와만 통신할 수 있도록 하는 구성이다. vpn 이라고 하는 가상 비공개 네트워크를 구현하여 vpn 에 연결되어야만 private subnet 과의 통신이 가능하다. vpc 콘솔에서 private 서브넷과 연결할 네트워크(customer gateway) 를 ip 와 함께 지정하고 virtual private gateway 생성, 그리고 그 둘을 이어주는 Site-to-Site VPN 연결을 구성하면 된다. (vpn 도 역시 유료) 서브넷의 보안그룹 설정은 vpn 으로 연결되는 네트워크 ip 대역으로부터 필요한 포트만 열어주면 된다.



4. private 서브넷만 있고 VPN 액세스를 제공하는 VPC


위 그림에는 다음 정보가 포함된다.

vpc : 10.0.0.0/16

private subnet : 10.0.0.0/24

ec2(web) : 10.0.0.5~7 (EIP: 198.51.100.1~3)

router : 10.0.0.0/16(local), 0.0.0.0/0(vgw-id)

vpn (virtual private gateway, customer gateway)

시나리오3번에서 public 서브넷만 제외한 구성이다. public 서브넷이 없으므로 igw 도 없다. vpn 과 연결된 특정 네트워크에서만 private 서브넷과 통신이 가능하며, 외부가 차단된 구성이다보니 서비스보다는 사내 인트라넷이나 개발 서버 등이 필요할 때 사용 가능한 구성이다.


이 중에 그나마 유용하게 쓸 수 있는 것이 2번이나 3번 시나리오 이다. 내가 선호하는 구성은 소규모 웹서비스의 경우 2번과 흡사하게. 더 큰규모의 웹서비스는 3번 시나리오에서 public subnet 에는 elb 만 두고 모든 자원을 private 서브넷으로, private 서브넷은 vpn 연결로 관리하는 것이 즐겨 사용하는 시나리오 이다. ^^


WRITTEN BY
손가락귀신
정신 못차리면, 벌 받는다.

트랙백  0 , 댓글  0개가 달렸습니다.
secret



Linux 상에서의 Minikube 도 설치 방법이 여러가지이다. 우선 하이퍼바이저 상에서 Minikube 를 구동할 것인지, 호스트에서 직접 구동할 것인지를 선택해야 한다. 하이퍼바이저를 이용한다면 리소스를 더 알뜰히 사용할 수 있겠지만, 모든 리눅스에서 하이퍼바이저를 사용할 수는 없다. Widnows 편에서 말했듯이 CPU 의 가상화(VT-x/AMD-v) 지원과 Bios 에서 가상화 활성화 상태를 확인해야 하는데, 요즘 많이들 사용하는 클라우드 컴퓨팅 서비스(EC2, GCE) 등에서는 대부분 HVM 가상화를 사용하고 있고, 그 자체가 이미 VM 이므로 그들은 Bios 에 접근을 할 수 없다. 결국 클라우드 컴퓨팅에서는 하이퍼바이저를 사용할 수 없으므로 과감히 VM 사용을 포기한다.ㅠ 현재 상황이 Linux 에서 VM 을 돌리기 위해 멀쩡한 PC 들에 Linux 를 까기는 좀;; 아무튼 현재 상황에서는 Linux 에서 VM 없이 호스트에서 Minikube 를 직접 구동시켜는 방법을 사용해야 하며, VM 없이 Minikube 를 시작하는 명령은...


 # minikube start --vm-driver=none 


하지만 EC2 Linux 에서도 minikube 를 정상적으로 구동하기 위해 체크해야 할 것들이 있다.



Minikube 구동시 체크사항


  1. 2cpu, 2GB 메모리, 20GB 디스크 이상의 사양.
    EC2 에서 free-tier 인 t2.micro 는 1cpu, 1G 메모리로, minikube 를 구동할 수 없다. 최소 t2.medium 사양(2cpu, 4GB mem)이 필요하다.

  2. docker 설치(Container Runtime)와 cgroup driver 매칭
    docker 가 반드시 필요하며(docker.io 나 docker-ce), 설치 후 docker info | grep -i cgroup 명령으로 cgroup driver 가 cgroupfs 인지 systemd 인지 확인해야 한다. minikube 구동 후에 kubelet 의 cgroup driver 와 일치하지 않는 다면 관련을 참고하여 일치시킨다. VM 에서 구동시에는 docker 가 자동 설치되며 자동 매칭을 해준 부분이다.

  3. 구동 실패시 클러스터 삭제
    minikube start 로 클러스터가 생성되다가 에러가 발생하면 캐싱으로 인해 에러가 반복될 수 있다. 다시 구동하기 전에는 minikube delete 명령으로 생성된 클러스터를 제거해 준다.



EC2 에서 발생할 수 있는 에러 메시지


- virtualbox 미설치 메시지

# minikube start

o   minikube v0.35.0 on linux (amd64)

>   Creating virtualbox VM (CPUs=2, Memory=2048MB, Disk=20000MB) ...

@   Downloading Minikube ISO ...

 184.42 MB / 184.42 MB [============================================] 100.00% 0s

!   Unable to start VM: create: precreate: VBoxManage not found. Make sure VirtualBox is installed and VBoxManage is in the path


- 가상화 비활성화 메시지

# minikube start

o   minikube v0.35.0 on linux (amd64)

>   Creating virtualbox VM (CPUs=2, Memory=2048MB, Disk=20000MB) ...

!   Unable to start VM: create: precreate: This computer doesn't have VT-X/AMD-v enabled. Enabling it in the BIOS is mandatory


- docker 미설치 메시지

# minikube start --vm-driver=none

i   This can also be done automatically by setting the env var CHANGE_MINIKUBE_NONE_USER=true

>   Creating none VM (CPUs=2, Memory=2048MB, Disk=20000MB) ...

!   Unable to start VM: create: precreate: exec: "docker": executable file not found in $PATH


- cgroup driver 불일치 메시지

# minikube start --vm-driver=none

This error is likely caused by:

- The kubelet is not running

- The kubelet is unhealthy due to a misconfiguration of the node in some way (required cgroups disabled)



EC2 (ubuntu) 에서 minikube 구동 성공


# minikube start --vm-driver=none

o   minikube v0.35.0 on linux (amd64)

>   Configuring local host environment ...


!   The 'none' driver provides limited isolation and may reduce system security and reliability.

!   For more information, see:

-   https://github.com/kubernetes/minikube/blob/master/docs/vmdriver-none.md


!   kubectl and minikube configuration will be stored in /root

!   To use kubectl or minikube commands as your own user, you may

!   need to relocate them. For example, to overwrite your own settings:


    - sudo mv /root/.kube /root/.minikube $HOME

    - sudo chown -R $USER $HOME/.kube $HOME/.minikube


i   This can also be done automatically by setting the env var CHANGE_MINIKUBE_NONE_USER=true

>   Creating none VM (CPUs=2, Memory=2048MB, Disk=20000MB) ...

-   "minikube" IP address is 10.0.1.121

-   Configuring Docker as the container runtime ...

-   Preparing Kubernetes environment ...

-   Pulling images required by Kubernetes v1.13.4 ...

-   Launching Kubernetes v1.13.4 using kubeadm ...

:   Waiting for pods: apiserver proxy etcd scheduler controller addon-manager dns

-   Configuring cluster permissions ...

-   Verifying component health .....

+   kubectl is now configured to use "minikube"

=   Done! Thank you for using minikube!

root@ip-10-0-1-121:~# minikube status

host: Running

kubelet: Running

apiserver: Running

kubectl: Correctly Configured: pointing to minikube-vm at 10.0.1.121




WRITTEN BY
손가락귀신
정신 못차리면, 벌 받는다.

트랙백  0 , 댓글  0개가 달렸습니다.
secret

CodeStar

Server/AWS 2018. 9. 17. 21:31

특정 프로그래밍 언어로 개발/빌드/배포 환경을 미리 구성된 템플릿을 사용하여 빠르게 구축해 주는 서비스이다. 예를 들어, Laravel 로 PHP 개발을 하려 한다면, EC2 / Git / CodeBuild / CodeDeploy / CodePipeline 등을 미리 구성해 주며 git 에 push 만 하면 자동 배포되어 결과를 확인할 수 있다. 그리고 제공되는 대시보드에서 프로젝트의 개발/빌드/배포 등의 이벤트 현황을 즉시 확인할 수 있다. 아무래도 미리 준비된 템플릿으로 빠르게 구성되는 장점은 있지만, 언어나 프레임워크의 버전, 서버종류 등의 선택이 제한적인 단점 때문에 사용할 일이 있을지는 모르겠다.





CodeStar 는...


CodeStar 는 AWS 를 기반으로 애플리케이션을 빠르게 개발, 빌드, 배포할 수 있는 클라우드 기반 서비스이다. CodeStar 프로젝트를 생성하면 이미 만들어진 CloudFormation 템플릿 중 원하는 환경의 어플리케이션을 선택할 수 있다. 사용되는 Service 들이 모두 리전 별 서비스이므로 CodeStar 역시 리전 별로 서비스한다. CodeStar 자체는 무료이므로 함께 사용하는 리소스의 요금만 발생된다.



CloudFormation 템플릿 선택사항


  • Application : Web application / Web service / Static Website / AWS Config Rule
  • Service : Elastic Beanstalk / EC2 / AWS Lambda
  • Language : Python / PHP / C# / Node.js / Ruby / Java / Go / HTML


Web application 와 Web service 의 차이라면 Web application 은 UI 나 웹페이지 기능이 많고, Web service 는 RESTful 같은 API 기능에 특화되어 있는 것 같다. 그 외에도 빌드가 트리거 될 AWS CodeCommit 나 GitHub 중 하나의 저장소를 선택해야 하고, 리소스 구성 세부 정보에서 배포될 EC2 와 VPC, Subnet 등을 설정할 수 있다.


CodeStar 에는 프로젝트, 도구 체인 및 중요 이벤트를 전체적으로 보여주는 대시보드를 제공한다. 최신 프로젝트 활동 모니터링, 코드 변경, 빌드 결과 및 배포 상태 추적 같은 작업을 타일에 추가/제거하여 대시보드를 구성할 수 있다. 프로젝트를 생성하면 팀의 소유자로 추가되며, 다른 사용자를 더 추가하고 역할을 부여하여 함께 운용할 수 있다. GitHub 리포지토리나 Atlassian JIRA 같은 AWS 외부의 리소스를 사용하는 경우, 사용자 이름 및 이메일 주소를 가진 별도의 사용자 프로필을 사용할 수 있다. 코드를 변경하고 저장소에 푸시하면, Continuous deployment 타일에 진행 중인 작업이 표시되며, CodePipeline 에서 저장소의 변경 사항으로 빌드 및 배포되어 엔드포인트에서 결과를 확인할 수 있다.


프로젝트를 삭제하면 관련 내부 리소스는 자동으로 모두 삭제된다.




WRITTEN BY
손가락귀신
정신 못차리면, 벌 받는다.

트랙백  0 , 댓글  0개가 달렸습니다.
secret

ECS Task

Server/AWS 2018. 8. 17. 22:16

Image 를 푸시하고 Cluster 를 생성하면 Image 를 구동할 수 있는 것처럼 얘기했지만, 해야 할 것이 하나 더 있다.


Docker 저장소의 Image 는 ECS 에서 사용하기 위해 Task 라는 작업에 정의해야 한다. 이 task 정의에는 실행할 이미지, 컨테이너 사양, 포트 등을 설정할 수 있으며, 이러한 Task 정의로부터 특정 ECS Cluster 를 선택하여 실행시킬 수 있다. Image 는 여러 Task 정의에서 가져다 쓸 수 있으며 Task 정의 역시 여러 Cluster 에서 실행시킬 수 있다.


이번에는 Task 정의를 생성하여 사용할 Image 를 설정해 보겠다.



1. 아키텍처 설계


컨테이너 서비스인 ECS 를 사용하여 어플리케이션을 운영한다는 것은 아키텍처 면에서 기존 방식과 조금씩 차이가 있을 수 있다. (이건 각자 알아서 ㅜ) 하나의 이미지를 여러 인스턴스에서 실행할 것인지 하나의 인스턴스에 여러 이미지를 실행할 것인지 등을 생각해 보아야 한다. 일단 하나의 Docker 이미지로 웹 서버 2대를 사용한다고 했을 때 필요한 것은,


web Image:1 -> web Task 정의:1 -> web Cluster (EC2:2)


이렇게 구성하면 될 것이다. 2 대의 인스턴스를 로드 밸런서에 묶기 위해 Cluster 에 Service 라는 것도 추가해야 하지만 일단 생략했다. 공통 모듈을이나 구성 요소에 따라, 하나의 task 정의에 여러 컨테이너(Image) 를 정의할 수도 있을 것이고... 일단 가장 심플하게 가보자.



2. Task 정의 생성


먼저 콘솔의 ECS - Task Definitions - [Create new Task Definition] 을 선택한다. ECR 에서도 잠시 거론했지만, Task 정의도 가장 먼저 선택하는 것이 시작 유형이다. Fargate / EC2 인스턴스 시작 유형 중 하나를 가장 먼저 선택하게 되고, 선택한 시작유형에 따라 미세하게 설정에 차이는 있다. Network 모드나 Port 설정 등... ECS Document 에 보면 Task 정의를 Dockerfile 처럼 json 파일로 정의할 수 있게 만들어놨는데, 그걸 먼저 보면 토나온다. 설정하는 것은 몇개 안되는데 모든 항목들이 다 나와 있어서 매우 복잡해 보이지만, 콘솔 대신 json 파일로 작업해야 한다면 콘솔에서 제공하는 json 형태의 스크립트에서 설정할 항목만 뽑아서 가져다 쓰면 된다. EC2 인스턴스 시작 유형을 선택했다면 이것저것 설정할 항목이 많아 보이는데, 대부분 Default 로 두면 되고 설정할 것은 몇 개 안된다.


- Task 정의 이름

- Add container : 사용할 Image 의 Repository URI, 이 컨테이너에 할당할 메모리/CPU, Port 매핑


메모리와 CPU 는 사용할 인스턴스 사양과 추가할 컨테이너들을 고려하여 설정한다. 이게 끝이다. ㅋㅋ 컨테이너 Image 나 메모리/CPU, 포트 매핑 등을 수정하기 위해 task 를 업데이트 하면 새로운 리비전이 추가된다. 아마도 운영중에는 크게 수정할 일이 없을 것이다.



3. Task 실행


구동을 확인해 보고 싶다면, Task 정의 리스트에서 Task 정의를 선택하고 [Run Task] 를 클릭하여 실행할 Cluster 를 선택하고 Number of tasks 수를 입력하면 끝. 혹은 Cluster - Tasks 에서 [Run new Task] 를 선택해도 결과는 동일하다. Number of tasks 수를 2 로 지정하면 두 개의 인스턴스에서 Task 가 독립적으로 실행될 것이다. Cluster 에 지정된 인스턴스 수가 한 개라면 한 개의 Task 만 실행된다. Task 가 실행되고 나면 PENDING 상태에 돌입하고 수초내에 정상적인 인스턴스에서 실행되고 있다는 뜻의 RUNNING 상태가 된다. Cluster 에 등록된 인스턴스에서 Task 정의의 Image 를 실행시킬 것이고, Public DNS 를 통해 Image 구동을 확인할 수 있다. Task 를 Stop 시키면 인스턴스에의 task 도 곧 중지된다. 개발 중에는 이렇게 로드 밸런서를 통하지 않고 Task 정의를 클러스터에 다이렉트로 실행시켜서 바로 Image 를 확인할 수 있다.




WRITTEN BY
손가락귀신
정신 못차리면, 벌 받는다.

트랙백  0 , 댓글  0개가 달렸습니다.
secret