무중단 배포 작업 검증1

[hyeonji1220]

• 무중단인지: 1초에 100번 요청을 보내면서 cd를 돌릴 때, 누락되는 요청이 하나라도 있는지
• 견디는지: 어플리케이션이 하나 떠있고, 하나 더 띄워서 cd 돌릴 때, 견디는지. CPU, 메모리가 어느정도 치솟는지.
• (이 사이에) pr 올려서 공유 겸 리뷰
• TPS에 영향이 많이 가는지: (TPS팀의 도움을 받아) CD를 돌리는 와중에 TPS를 측정해서, 평소와 비교하기

산초 레디스 하는 동안 커비가 마무리해야할 것

• pr 올리고 리뷰 받으려면 공유가 되어야하니, 공유할 디스커션 정리
• 공유 말로 한 번 하고
• pr 올리기

추가로 해야할 것

• 무중단 배포 prod에도 적용 (이번 배포 때 적용해야지 요구사항 측면에서 의미가 있을듯)

[hyeonji1220]

무중단인지 - ✅

1초에 300번의 리뷰폼 질문 가져오기 GET 요청을 보낼 때 오류 처리되는 요청이 있는지 확인.
(도구: jmeter로 100개의 쓰레드가 1초에 3개씩)

1. 오류 처리되는 요청 없음
   

2. deploy step: 43초 걸려서 정상 종료

[hyeonji1220]

견디는지

1. CD만 돌 때: 기존 스프링 어플리케이션 + CD

1. 견디는가?: 견딘다. ec2가 죽지는 않았다.
2. CPU: CD 과정 동안 60%에 도달했다.
3. ram: 70%에 도달했다.
4. graceful shutdown 타임아웃 10초 내에 기존 요청 모두 정상 처리.

2. 요청도 같이 보낼 때: 기존 스프링 어플리케이션 + CD + 1초당 300회 GET 요청 보내는 상황

• 요청 상황: 100개의 쓰레드가 1초에 3개씩 리뷰폼 질문 가져오기 요청

1. 견디는가?: 견딘다.
2. CPU: CD 과정 동안 57%에 도달했다.
3. ram: 75%에 도달했다.
4. graceful shutdown 타임아웃 10초 내에 기존 요청 처리 못함. 20초로 늘리니 모두 정상 처리.

• 참고) 1초당 50개 쓰레드가 3번씩 GET 요청의 경우: graceful shudown 10초로도 충분했음.

[hyeonji1220]

graceful shutdown의 타임아웃 시간 정하기

10초 vs 20초

타임아웃 시간 길게줬을 때(20초)

장점

• 누락되는 요청이 없음
• 이유: 많은 요청이 들어옴 → CPU 바빠서 처리 오래걸림 → graceful로 기존 요청 처리 시간을 넉넉하게 주면 처리 완료함

단점

그만큼 어플리케이션이 2개 떠있는 시간이 10초 더 길어짐 → CPU, 메모리에 부하가 커지는 시간이 10초 더 늘어남. 그동안의 사용자들은 응답 속도가 느림

결론

1. 타임아웃 20초: 매 배포마다 응답 시간이 오래걸려서 사용자가 불편함
2. 타임아웃 10초: 매 배포마다 누락되는 요청이 생겨서 사용자가 불편함

[hyeonji1220]

오래 기다리더라도 응답해주는 게 맞다 → 20초로 결정

[nayonsoso]

아무런 docker 도, iptable rule 도 없는 경우 ✅

목표

CURRUENT_SERVER_PORT : 8080
NEW_SERVER_PORT : 8081
CURRUENT_ACTUATOR_PORT : 5959
NEW_ACTUATOR_PORT : 5960

처음에는 80 -> 8080 & 5959 -> 5960 강제 rule 추가 성공해야 함

만약 헬스 체크에 실패한다면,

• 위에서 설정한 rule 이 삭제되고 결과적으로 아무것도 남아있지 않는 상태가 되어야 함
  만약 헬스 체크에 성공한다면, (롤백)
• 80 -> 8081 규칙과 5959 -> 5960 룰이 남아있어야 한다.

---

8081 / 5960 도커와 iptable 이 설정되어있는 경우 ✅

목표

CURRUENT_SERVER_PORT : 8081
NEW_SERVER_PORT : 8080
CURRUENT_ACTUATOR_PORT : 5960
NEW_ACTUATOR_PORT : 5959

만약 헬스 체크에 성공한다면,

• 80 -> 8080 규칙과 5959 -> 5959 룰이 남아있어야 한다.
  만약 헬스 체크에 실패한다면 (롤백)
• ❗️80 -> 8081 규칙과 5959 -> 5960 룰이 남아있어야 한다❗️
• 위 규칙이 남아있지 않으면 502 Bad Gateway 가 반환된다.

---

🚨 사건일지 - 중단이.. 아니었다?!

Jmeter 로 무중단 배포를 테스트하던중,
배포 도중 502가 짧은 시간 응답되는 것을 포착하였다.
위 로그 중에서 Container review-me-app-8081 Stopped 가 찍히는 동시에 발생한 예외 응답이었다.
이것이 의미하는바는, 우리의 지금 무중단 배포가 유중단 배포라는 것이다...😱

다시 로그를 살펴보자..!
우선, Container Stopping 까지는 어떠한 예외 응답도 나지 않았지만,
Container Stopped 가 찍히는 순간 예외 응답이 발생한 것이다.
즉, 앞선 단계,
기존 컨테이너가 실행되는 동시아 docker 로 새 컨테이너를 띄운 단계나,
iptable 의 규칙을 replace 하는 과정은 잘 넘어갔다는 것이다.

여기까지 생각을 한다면, "기존 docker 를 종료함으로써 예외 응답이 발생함"에 더 집중할 수 있게 된다.
그리고 커비와 나는 이 원인을 아래 코드에서 발견했다.

docker-compose --env-file .env."$PROFILE_VAR" stop -t 10 app-$OLD_PORT

위 코드는 docker graceful shutdown 을 구현한 코드이다
10초동안의 시간을 주고, 기존 어플리케이션으로 돌아온 응답을 모두 처리할 수 있게 했다.

하지만 '요청을 너무 많이 보내고 있어서 10초가 충분하지 않았나?' 라는 가설을 세우게 되었다.
따라서, 1/ 같은 프로세스를 유지하고, 요청만 적게 보냈을 때 예외 응답이 발생하는지를 관찰했고,
2/ 같은 요청 수를 유지하고, shutdown 의 시간을 20으로 높였을 때 예외가 발생하는지를 관찰해봤다.

[hyeonji1220]

발견한 문제

cd를 돌릴 때 runner를 max-parallel 1로 설정하면
prod 1의 배포가 끝나고 나서 prod2가 배포되는 건데, 그렇다면 구, 신 버전의 공존 문제가 발생한다.

대안

max-parallel 설정을 따로 하지 않고 prod1, 2가 병렬로 runner가 실행되게 한다.
약간의 시간차이는 있겠으나 매우 적을 것으로 추측됨

[hyeonji1220]

트러블 슈팅

dev에 요청을 너무 많이 보내서 dev가 요청을 처리하는데 시간이 오래걸렸다. 따라서 인스턴스를 껐다 켰는데 이 때, 여러 문제가 발생했다.

팀원에게 물어볼 것 1) ubuntu 사용자에게 도커를 sudo로 실행하는 수준의 권한을 줘야하나?
그 전에는 docker ps를 할 때 sudo를 안 붙여도 됐는데, 인스턴스를 껐다 키니 sudo를 붙여줘야해서
cd의 docker login step에서 실패했다.

[hyeonji1220]

그외 dev 인스턴스를 껐다 키면서 있었던 트러블 슈팅

1. swap도 설정이 해제되어서 용량이 부족해 터미널 접속이 안됨 → 인스턴스 사이즈를 키워서 해결
2. 그 과정에서 swap 파일을 중복 생성해서 인스턴스 시작이 안됨 → 볼륨을 분리해서 다른 인스턴스에 붙여 접속해서 중복 swap 파일 제거
3. actions runner가 offline 되어서 다시 실행시킴

[hyeonji1220]

추측되는 원인

1. Docker 소켓 권한
   있음
2. 그룹
   도커 그룹에 ubuntu 추가했음
3. 러너 사용자
   우분투임

[hyeonji1220]

pkill runner.listner 후 run.sh로 러너 재시작을 하니 해결되었다.
docker에 ubuntu를 권한이 있는 사용자로 추가한 것이 적용되며 해결된 것으로 추측