[beanstalk]eb cli으로 배포 시, 주의할점

1년간 빈스톡을 사용하면서, 배포할 때 주의해야했던 점들을 정리하고자 한다.

 

1. 빈스톡은 local git code를 배포한다.

remote에 있는 git code를 땡겨다가 배포하는게 아니다.

그래서 배포하기 직전에, 최신 master code를 로컬로 땡겨온 다음에 배포해야한다.

 

2. 빈스톡에 있는 모든 인스턴스는 같은 애플리케이션 버전이여야한다.

터미널로 eb deploy 명령문을 실행해서 배포를 하던 도중,

실수를 한게 있어서 나도 모르게 command + c  버튼을 눌러서, 배포를 강제종료했던 적이 있다.

 

그런데 배포 강제 종료는 일을 더 꼬이게 만든다.

 

빈스톡에서는 모든 인스턴스의 버전이 같아야한다.

 

예를 들어 모든 인스턴스가 같은 버전으로 배포되기 전에, 배포를 중단시켜 버리면

최신 버전으로 배포된 인스턴스들은 degraded 상태가 된다.

 

4개의 인스턴스가 있었을 때, 2개의 인스턴스는 최신 버전 / 2개의 인스턴스는 구버전인 경우 아래와 같은 상황을 볼 수 있을거다.  

$ eb health --refresh
elasticBeanstalkExa-env                                  Degraded                  2016-03-28 23:13:20
WebServer                                                                              Ruby 2.1 (Puma)
  total      ok    warning  degraded  severe    info   pending  unknown
    4        2        0        2        0        0        0        0

  instance-id   status     cause
    Overall     Degraded  Incorrect application version found on 2 out of 4 instances. Expected version "Sample Application" (deployment 1).
  i-d581497d    Degraded  Incorrect application version "v2" (deployment 2). Expected version "Sample Application" (deployment 1).
  i-d481497c    Degraded  Incorrect application version "v2" (deployment 2). Expected version "Sample Application" (deployment 1).
  i-126e00c1    Ok
  i-8b2cf575    Ok

  instance-id   r/sec    %2xx   %3xx   %4xx   %5xx      p99      p90      p75     p50     p10
    Overall     646.7   100.0    0.0    0.0    0.0    0.003    0.002    0.001   0.001   0.000
  i-dac3f859    167.5    1675      0      0      0    0.003    0.002    0.001   0.001   0.000
  i-05013a81    161.2    1612      0      0      0    0.003    0.002    0.001   0.001   0.000
  i-3ab524a1    155.9    1559      0      0      0    0.003    0.002    0.001   0.001   0.000
  i-bf300d3c    162.1    1621      0      0      0    0.003    0.002    0.001   0.001   0.000

  instance-id   type       az   running     load 1  load 5      user%  nice%  system%  idle%   iowait%
  i-d581497d    t2.micro   1a   25 mins       0.16     0.1        7.0    0.0      1.7   91.0       0.1
  i-d481497c    t2.micro   1a   25 mins       0.14     0.1        7.2    0.0      1.6   91.1       0.0
  i-126e00c1    t2.micro   1b   25 mins       0.03    0.08        6.9    0.0      2.1   90.7       0.1
  i-8b2cf575    t2.micro   1c   1 hour        0.05    0.41        6.9    0.0      2.0   90.9       0.0
  
  instance-id   status     id   version              ago                                  deployments
  i-d581497d    Deployed   2    v2                   9 mins
  i-d481497c    Deployed   2    v2                   7 mins
  i-126e00c1    Deployed   1    Sample Application   25 mins
  i-8b2cf575    Deployed   1    Sample Application   1 hour

 

그래서 이러한 상황이 발생하면, 배포에 성공했던 가장 최근 버전으로 재배포를 해줘야한다.

 

3. 배포에 실패한 인스턴스는 LB에 등록되지 않는다

빈스톡은 LB에서 인스턴스를 떼내고, 해당 인스턴스에 새로운 버전을 배포하고, 다시 이 인스턴스를 LB에 등록해주는 방식으로 배포된다. 만약 인스턴스가 5개이고, 만약 1개씩 배포되게 설정을 했으면 위의 과정을 5번하는거다. ( 그래서 빈스톡 배포는 느리다 )

그런데 한 인스턴스를 배포하다가 실패하면, 이 인스턴스를 LB에 다시 등록해주지 않는다.

그래서 남은 인스턴스들끼리만 트래픽을 처리하다보니, CPU / 디스크 / 메모리 사용량들이 늘어나서

남은 인스턴스들에도 빨간불이 들어오는 상황이 생기기도 한다.

 

4. 무한 카오스에 빠지면 안된다

빈스톡 배포에 실패하면, 종종 카오스에 빠진다.

메모리가 부족해서 배포에 실패하기도 하고, 패신저 연결이 안되서 실패하기도 하고.. 아무튼 특정 인스턴스에서만 배포가 안되는 현상이 발생하는 경우도 있다.

v1 버전이였던걸 v2으로 배포하다가 특정 인스턴스에서만 배포가 안되면,

'다시 v2으로 배포해보자!' 라는 마음가짐으로 다시 배포 명령문을 날리고는 한다.

 

그런데 이러면 전체 인스턴스의 버전이 다르기 때문에 또 배포에 실패할거다.

그러면 또다른 이유로 배포에 실패하게 되니.. 또다른 카오스에 빠지게 된다.

 

때문에 이런 경우에는 침착하게, 모든 서버의 애플리케이션 버전을 다시 맞춰준 다음에

문제가 발생한 인스턴스의 상황을 확인 한 후, 재배포를 해줘야한다.

 

 

 

참고 자료

EB CLI 관련 문제 해결 - https://docs.aws.amazon.com/ko_kr/elasticbeanstalk/latest/dg/eb-cli-troubleshooting.html

Notifications and Troubleshooting - https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/environments-health-enhanced-notifications.html