'Deploy'에 해당하는 글 3건

ECS Deployment strategy

Server/AWS 2018. 8. 27. 02:02

배포 자동화 스크립트를 만들기 전에 가장 궁금했던 것은 배포 전략(?) 이었다.

예를 들어 로드 밸런서에 인스턴스 2 대를 운영 중이라면, 3 가지 정도의 배포 방법을 생각할 수 있다.


  • 인스턴스를 2 대 이용할 경우, A 인스턴스를 중단하고 새로 배포 후, B 인스턴스를 중단하고 새로 배포하는 방법이 있을 수 있다.
  • 인스턴스를 2 대에서 2 대를 추가할 경우, C/D 인스턴스에 새로 배포 후, A/B 인스턴스를 중단하는 방법이 있을 수 있다.
  • 인스턴스를 2 대에서 1 대를 추가할 경우, C 인스턴스에 새로 배포 후에, A 나 B 인스턴스를 중단하든 그 반대로 하든... 아무튼...


Service 설정에 보면 Replica 전략에서 배포구성에 관한 옵션이 두가지 있다. minimumHealthyPercent maximumPercent 인데 이것과 인스턴스 수 조정으로 배포 전략을 결정할 수 있다. minimumHealthyPercent 은 RUNNING 상태인 Task 수를 최소 얼만큼 유지할 것인지를 설정한다. 로드 밸런서를 붙인 상태에서는 동시에 inService 상태 인지도 체크한다. maximumPercent 는 RUNNING 상태이거나 PENDING 상태의 최대 Task 수를 고려하여 설정한다.

(아래는 min / max 로 표현하겠음.)


로드 밸런서를 붙인 상태에서 운영중인 2 대의 인스턴스를 가장 빠르고 안정적으로 배포하기 위한 설정을 위해 다음과 같이 테스트 해 보았다.



A. Instance 2 (+0) 50% 100%


이 설정은 인스턴스 2 대 중, 하나의 인스턴스의 Task(50%) 는 무조건 RUNNING 상태를 유지하게 된다는 것을 예상할 수 있다. 그로 인해 번갈아 가면서 배포가 가능하게 될 것이다.


- Service Log

00:00:00 - 로드밸런스에서 A 인스턴스 등록 해제

00:00:00 - A Task DRAINING 상태 시작

00:00:12 - A Task 중지 완료

00:00:22 - 새로운 A Task 시작

00:00:33 - 로드밸런스에서 A 인스턴스 등록

00:00:54 - 로드밸런스에서 B 인스턴스 등록 해제

00:00:54 - B Task DRAINING 상태 시작

00:01:15 - B Task 중지 완료

00:01:25 - 새로운 B Task 시작

00:01:36 - 로드밸런스에서 B 인스턴스 등록


A Instance -> LB 해제 -> Task 중지 -> Task 시작 -> LB 등록

B Instance                                              -> LB 해제 -> Task 중지 -> Task 시작 -> LB 등록


로그를 보면 Task 를 삭제하거나 실행하는 과정은 간단하다.


1. 로드밸런스에서 인스턴스 등록 해제

2. Task DRAINING 시작

3. Task 중지


4. 새로운 Task 시작

5. 로드밸런스에서 인스턴스 재등록


여기서 max 를 200% 로 둔 다면 하나의 Task 를 DRAINING 으로 변경하며 즉시 여유분의 인스턴스를 찾을 것이므로 경고가 발생한다. 배포는 되겠지만 약간의 딜레이가 발생할 것이다.



B. Instance 2 (+0) 100% 150%


이 설정은 인스턴스 2 대 중, 2 대의 인스턴스의 Task(100%) 가 무조건 RUNNING 상태를 유지하게 되므로 배포할 방법이 없다.

min 을 100% 로 설정하려면 max 값에 대응할 수 있는 추가 인스턴스가 필요하다.

CPU / MEM / PORT 등의 요구사항을 만족하는 인스턴스를 찾지 못했다는 에러 메시지가 나타날 것이다.


- Service Log

00:00:00 - 요구사항에 부합하는 컨테이너 인스턴스가 없으므로 Task 를 실행할 수 없다. 



C. Instance 2 (+1) 50% 150%


- Service Log

00:00:00 - 로드밸런스에서 A 인스턴스 등록 해제

00:00:00 - A Task DRAINING 상태 시작

00:00:00 - 새로운 C Task 시작

00:00:20 - A Task 중지 완료

00:00:20 - 로드밸런스에서 C 인스턴스 등록

00:00:31 - 새로운 A Task 시작

00:00:41 - 로드밸런스에서 B 인스턴스 등록 해제

00:00:41 - B Task DRAINING 상태 시작

00:00:41 - 로드밸런스에서 A 인스턴스 등록

00:01:02 - B Task 중지 완료


A Instance -> LB 해제 -> Task 중지 -> Task 시작 -> LB 등록

B Instance                                              -> LB 해제 -> Task 중지

C Instance -> Task 시작 -> LB 등록          



D. Instance 2 (+1) 100% 150%


- Service Log

00:00:00 - 새로운 C Task 시작

00:00:13 - 로드밸런스에서 C 인스턴스 등록

00:00:34 - 로드밸런스에서 A 인스턴스 등록 해제

00:00:34 - A Task DRAINING 상태 시작

00:00:54 - A Task 중지 완료

00:01:05 - 새로운 A Task 시작

00:01:16 - 로드밸런스에서 A 인스턴스 등록

00:01:37 - 로드밸런스에서 B 인스턴스 등록 해제

00:01:37 - B Task DRAINING 상태 시작

00:01:58 - B Task 중지 완료


A Instance                       -> LB 해제 -> Task 중지 -> Task 시작 -> LB 등록

B Instance                                                                    -> LB 해제 -> Task 중지

C Instance -> Task 시작 -> LB 등록



E. Instance 2 (+2) 50% 200%


- Service Log

00:00:00 - 로드밸런스에서 A 인스턴스 등록 해제

00:00:00 - A Task DRAINING 상태 시작

00:00:00 - 새로운 C, D Task 시작

00:00:10 - 로드밸런스에서 C 인스턴스 등록

00:00:21 - 로드밸런스에서 B 인스턴스 등록 해제

00:00:21 - B Task DRAINING 상태 시작

00:00:21 - A Task 중지 완료

00:00:21 - 로드밸런스에서 D 인스턴스 등록

00:00:32 - B Task 중지 완료


A Instance -> LB 해제 -> Task 중지

B Instance                       -> LB 해제 -> Task 중지

C Instance -> Task 시작 -> LB 등록          

D Instance -> Task 시작           -> LB 등록



F. Instance 2 (+2) 100% 200%


- Service Log

00:00:00 - 새로운 C, D Task 시작

00:00:12 - 로드밸런스에서 C, D 인스턴스 등록

00:00:34 - 로드밸런스에서 A, B 인스턴스 등록 해제

00:00:34 - A, B Task DRAINING 상태 시작

00:00:55 - A, B Task 중지 완료


A Instance                       -> LB 해제 -> Task 중지

B Instance                       -> LB 해제 -> Task 중지

C Instance -> Task 시작 -> LB 등록          

D Instance -> Task 시작 -> LB 등록



위와 같이 minimumHealthyPercent / maximumPercent / task 수를 설정하여 다양한 배포 방법들을 테스트 해 보았다. B 를 제외한 A/C/D/E/F 의 배포는 모두 정상적으로 이루어 졌다. 물론 시간이나 순서 등은 각자의 배포물 용량이나 트래픽에 따라 변할 수 있다. 단계가 간결한 F 배포가 가장 빠를 것 같았는데 E 배포가 더 빨랐다는 것은 예상 밖이다. C 나 D 같은 경우는 min 과 max 값이 동시에 모두 가능할 때 어느쪽으로 먼저 배포에 영향을 미치는지를 보고 싶어서 테스트 한 것이었는데 minimumHealthyPercent 가 매우 중요함을 알게 됐다.이번 테스트로 A 방법이 가장 효율적인 것을 알게 되었고, 빠르고 빈도수가 높은 배포는 E/F 방법을 으로 전략을 세우는 것이 효과적임을 알게 됐다.



결론


가성비 좋은 배포는 A, 속도/빈도수 높은 배포는 E/F 를 사용하자.




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

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

ECS 배포

Server/AWS 2018. 8. 20. 23:32

드디어 ECS 마지막 단계인 배포다. ㅋㅋ 지금까지 Docker Image 를 만들었고, Docker Image 를 ECR 에 푸시했고, 해당 이미지를 Task 정의에 할당했고, Task 정의를 Cluster 의 인스턴스에서 실행해 보았다. 제목의 ECS 배포란 말은 Cluster 의 인스턴스에서 Task 정의를 실행한 것을 말한다. 정확한 표현으로는 단지 Task 실행이다. ^^ 이미 Task 정의를 Cluster 에서 직접 시켜봤으니 사실상 배포를 해 본 셈이다. 실제 웹서버 운영이라면 Auto scaling 이나 Load Balancing 을 붙이게 되는데 이것은 Cluster 의 Service 를 생성하여 설정할 수 있다.


* Service 가 해주는 일

- Auto scaling 이나 Load Balancing 설정.

- Service 스케줄러 전략으로부터 Task 정의 인스턴스를 제어.



1. Service 생성



Cluster - Services - [Create] 를 클릭하고 항목을 작성한다. Service 이름, Task 정의 선택, Task 수, 로드 밸런싱, Auto scaling 등을 설정하고 나머지는 다 default 로 둔다. (로드 밸런싱, Auto scaling 생성/설정은 알아서 ㅜ). Service 생성을 마치고 나면 Task 수 만큼의 인스턴스가 생성되어 바로 구동된다. 즉 바로 배포.


Service 에서는 Task 실행이 실패하거나 중단되어도 Task 수를 유지할 수 있도록 계속해서 Task 실행을 시도하게 된다. 이것 역시 Task 를 직접 실행하는 것과이 차이점이다. Service 에서 Task 수를 유지하려는 것은 Service 생성시 default 설정으로 둔 Replica 전략 때문이다. 이 Replica 는 최소 상태 백분율 및 최대 백분율 파라미터 등의 설정 대로 실행할 Task 정의를 어느 인스턴스에 배포할지를 판단한다.


즉, ECS 배포는 Task 의 실행, 곧 Service 를 생성하거나 업데이트 하는 순간 Task 정의가 실행되며 배포된다고 볼 수 있다. 추후 이미지를 수정하여 변경되거나 했을 때 최신 버전으로 인스턴스에 올리기 위해서는 Service 를 업데이트만 해주면 된다. Service 생성도 배포이고, Service 업데이트도 배포인 것이다.



2. Service 업데이트


Service 를 다른 용도로 업데이트 할 일은 별로 없을 것이다. 주로 인스턴스 수를 조정하거나 최신 이미지를 재배포 할 때 업데이트를 하게 될텐데, 업데이트는 매우 간단하다. Service 리스트에서 업데이트할 Service 에 체크하고 Update 를 클릭하면 기존 세팅이 나타나는데 [Force new deployment] 항목에 체크하고 나머지 항목은 모두 그대로 두면 latest 이미지를 가져와 업데이트 할 것이다.




이렇게 배포를 마쳤다. 여기까지는 ECS Document 만 보고 쉽게 따라할 수 있지만, Free Tier 사용자의 경우 EC2 를 두 개 이상 테스트 해보기는 쉬운 결정이 아닐 수도 있다. Fargate 도 마찬가지. 표면상 배포는 잘 돌아가겠지만, 관리 측면에서 보면 앞으로 고민해야 할 일이 더 많을 수도 있다. Image 업데이트부터 배포까지의 매우 번거로운 단계를 최대한 자동화 시키는 것에 대한 고민과, 인스턴스에 늘어나는 Image 에 대한 용량이나 롤백에 대한 고민, task 실행 실패시 알람 및 전략, ECS/Docker/EC2 로그 수집 방법 등등 필요로 하는 더 많은 기능들에 대해 고민해 봐야 한다. 운영면에서는 관련 문서가 그리 많지 않으니 그냥 열심히들 삽질해 보자.




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

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

Deploy to Nexus

Tool/Maven 2013. 5. 13. 18:22

Internal Repository

 

Private remote internal repository 은 내부(사내) 저장소라고 합니다.
프로젝트 개발시 모든 구성원이 중앙 저장소로부터 필요한 라이브러리를 다운로드 할 수 있지만, 구성원간에 공유해야 하는 별도의 리소스를 공유, 관리하기 위해 사내 저장소가 필요합니다.
사내 저장소 구성을 위해 Nexus, Artifactory 등의 OSS 를 이용할 수 있습니다. 둘 중 대세인 Nexus 를 사용해 보겠습니다.

 

Nexus site : http://www.sonatype.org/nexus
Nexus 설치 안내

 

대략적인 Nexus 로의 배포 시나리오는 다음과 같습니다.

 

  • 누군가 Nexus에 라이브러리를 등록할 수 있도록 별도의 계정 생성.
  • 로컬 저장소에서 mvn deploy 시 배포될 Nexus 주소/계정 정보 등록.
  • Nexus로 배포

 

 

1. 사용할 계정 생성

 

Nexus 사이트에 admin 계정으로 로그인하여 [Security] - [Users] - [Add...] 항목을 클릭한 후 새 계정을 생성합니다.
아니면 기존 생성된 user의 패스워드만 변경하여 사용해도 됩니다. (항목에서 마우스 우측버튼 클릭)

 

 

2. 계정 정보 삽입

 

Nexus 에 접속할 수 있는 계정 정보를 로컬 저장소의 settings.xml 파일에 삽입합니다.

 

$ vi ~/.m2/settings.xml
<servers>
    <server>
        <id>nexus</id>
        <username>deployment</username>
        <password>[password]</password>
    </server>
</servers>

 

 

3. 배포 정보 삽입

 

배포할 nexus 의 저장소 정보를 프로젝트의 pom.xml 파일에 삽입합니다.

 

$ vi <project_home>/pom.xml
<distributionManagement>
    <repository>
        <id>nexus</id>
        <name>Internal Releases</name>
        <url>http://domain.com:8081/nexus/content/repositories/releases/</url>
    </repository>

 

    <snapshotRepository>
        <id>nexus</id>
        <name>Internal Releases</name>
        <url>http://domain.com:8081/nexus/content/repositories/snapshots/</url>
    </snapshotRepository>
</distributionManagement>

 

 

4. 배포

 

$ mvn deploy

 

 

 


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

트랙백  0 , 댓글  2개가 달렸습니다.
  1. 질문자 2013.05.29 17:48
    안녕하세요 넥서스 정보 찾다가 질문 드립니다.
    1. 계정 정보 삽입에서 <id>는 nexus 상에서 repository ID를 말하는 것인지요?
    repository ID와 정확히 일치해야 하는지 아니면 의미는 없는 것인지 궁금합니다.
    2. 배포 삽입 정보에서 <repository>와 <snapshotRepository>의 차이가 무엇인지 궁금합니다.

    답변 부탁드립니다.
    • 1. <계정 정보 삽입>의 ID는 임의로 정하셔도 됩니다. 대신 <배포 정보 삽입>의 ID와 일치해야 그 url로 접속할 수 있겠지요?
      2. url을 보시면 <repository />의 url은 releases 디렉토리를 가리키고 <snapshotRepository />의 url은 shapshots 디렉토리를 가리킵니다. 배포시 스냅샷 버전은 snapshots 디렉토리로, 릴리스 버전은 releases 디렉토리로 업로드 됩니다.
secret