무중단 배포 작업 과정1

[nayonsoso]

내가 하는 작업은 무엇을 위한 작업인가?

-> 무중단 배포를 위함이다.
머지 후 다시 run 할 때 발생하는 downtime 을 없애기 위해서이다.
작업이 끝나고 나서, 빌드를 하는 중간에 요청을 보내는 툴(e.g. Jmeter) 를 사용해서 error 응답이 얼마나 오는지를 확인해서 결과를 판단한다.

이 작업으로 해결하려는 문제는 무엇인가? 본질을 생각해보자.

downtime 을 없애기 위해서이다.
사용자가 죽은 서버에 보내지 않기 위함.
api 버전 불일치되는 ec2 를 동시에 띄우지 않기 위함.
우테코 요구사항을 만족하기 위함.

우리의 궁극적인 목표가 "사용자가 항상 200 받게 하기" 라면, 프론트도 사실 신경을 써야 하는건 맞다.
프 / 백 배포 버전 달라서 생기는 문제는 인지는 하나, 1차 목표로 백엔드 무중단만 고려한다.

작업을 함에 있어 무엇을 가장 우선시해야 할까?

후보 : 속도 / 깊이 있는 공부 / 꼼꼼하게 모든 조건을 만족시키는 것
1/ 속도 : 다음주 월요일까지 완료해야 한다.
2/ 깊이 있는 공부 : 논의했던 과정을 문서화만 한다면 괜찮다고 생각한다.
이미 나와있는 방식 중에서 우리가 선택하는 것, 무엇을 적용할까?
넓은 가능성을 고려하는 방식 & 비교 & 다양한 측면 따지기
3/ 꼼꼼하게 조건 (배포를 하는 중에도 사용자가 사용할 수 있게)를 만족하는 것을 목표로!! 이것을 기준으로 해야 한다.

상대적으로 중요하게 생각하지 않아도 되는 부분은 무엇인가?

• 되기만 하면 되는 것이긴 함. 방법만 고르면 됨
• Code Deploy? Lambda? EC2 생성? => 내려놔도 되지 않을까?
• "배포를 하는 중에도 사용자가 사용할 수 있게"
• 복잡도 중요 X
• 변경이 크면 오히려 혼란스러울지도?!
• 무중단 배포가 얹혀가는 느낌! 너무 깊이는 들어가지 말자.
• 일어날 가능성이 너무 적은 상황을 가정하는 것

반드시 충족시켜야 하는 것들에는 무엇이 있는가?

• ☑️ 빌드를 하는 중간에 요청을 보내는 툴(e.g. Jmeter) 를 사용해서
• 배포를 하는 동안 error 응답이 얼마나 오는지를 확인한다.
• error 가 아예 오면 안된다!!!
• ☑️ 배포 과정에서 run이 실패하면, 이전 버전의 docker image 를 pull 받아서 다시 run 한다.
• 다른 쪽에는 영향을 주면 안된다.

어떤 순서로 일을 처리할 것인가?

• 1️⃣ CD 가 시작될 때, LB 에서 한쪽으로 보내지 않게 하는 방법을 찾는다.
• 2️⃣ CD 를 ec2 마다 / 순차적으로 하게 한다.
• 3️⃣ CD 에서 run 이 실패할 시 롤백하게 한다.
  • 4️⃣ 그리고 남아있는 ec2 에서 cd 가 돌지 않게 한다.
• 새로운 버전 run 이 성공하면,
  • 5️⃣ 업데이트 된 것은 LB 와 다시 이어주고, 아직 안된 것은 끊고 이 과정을 동일하게 실행한다.
  • "동시에 이어주고, 다른건 끊어주게 한다." / 함수로 치면 이어준 다음 & 끊어준다.
• 6️⃣ Jmeter 로 확인을 한다.

어떻게 해야 이 일을 더 효율적으로 처리할 수 있을까?

• 구글링을 하고
• 지피티한테 물어보고
• 다른 사람들한테 물어본다.
• 코치한테 물어본다.
• 각 스텝에서 너무 시간 과투자하면 안됨.

작업에 방해가 될만한게 있나? 그걸 어떻게 차단할 수 있을까?

• 미션 (밤에 한다)
• 주말에 안나오는 산초 ㅠㅠ 주말에 나오겠습니다!!!

예상 작업 시간을 적고, 타이머를 설정하자

예상 시간 :
실제 시간 :
예상 시간과 실제 시간이 다른 이유 :

[donghoony]

[nayonsoso]

1️⃣ 번 작업에서
LB 와 blue의 연결을 끊을 때, blue 로 가고 있던 트래픽을 grean 으로 리라우팅을 해준다면,
error 응답을 더 줄일 수 있을 것 같다.

https://velog.io/@juhyeon1114/AWS-Auto-scaling-group-BlueGreen-%EB%B0%B0%ED%8F%AC%ED%95%98%EA%B8%B0

[hyeonji1220]

2️⃣ CD 를 ec2 마다 / 순차적으로 하게 한다.

방법 1. concurrency

[nayonsoso]

🔸 blue-green 적용 계획

후보

1️⃣ code deploy + elb :
code deploy 가 제공하는 blue-green 기능을 사용하는 방법.
elb 의 타겟 그룹에 green(새로운) ec2 그룹을 만든 다음 blue(이전) ec2 그룹은 제거하는 형태.

2️⃣ git workflow + shell script 를 사용하는 방법
하나의 ec2 에서 돌아가는 app 이 있는 상태에서, docker 에서 새로 받은 image 로 run 을 한다.
run 이 성공하면 포트 매핑을 한 다음, 기존의 app 은 kill gracefully한다. (그때까지 받은 요청을 처리한 다음 죽임)

결국 선택한 것

❗️git workflow + shell script 방법❗️
레벨5가 끝나고, 우리만의 인프라로 바뀐다면 LB 를 사용하지 않는 인프라 구조로 바뀔 수도 있다.
또한 aws 자체가 비싼편이기 때문에 클라우드 서비스 자체를 바꿀 수도 있다.
(예를 들어서 마이크로 소프트의 클라우드 서비스 Azure 는 학생 인증하면 100$ 크레딧 제공)
따라서 LB 가 필요한 1번 방법은 aws 서비스에 의존적인 확장성이 낮은 방법이라는 생각이 들었다.

한가지 걱정되는 부분은
"하나의 app 이 실행되어있는 상태에서 새로운 이미지를 받아서 실행하는 순간을 ec2가 버틸 수 있을까?"
였으나, 기존 release 를 할 때 하나를 run 할 때 CPU 는 17%(평균 3%) 그리고 메모리는 67%(평소에는 50)이 되었기 때문에, 감당할 수 있을 것이라 생각한다.

[hyeonji1220]

정정 ❗️ code deploy + elb 방법으로 변경❗️

TPS를 키워가면서 대규모 트래픽을 대비하는데 ... (작성중)

[hyeonji1220]

2️⃣ CD 를 ec2 마다 / 순차적으로 하게 한다.

방법 2. max-parallel

기본적으로는 모든 러너를 사용해서 job들을 병렬적으로 수행한다. 하지만 max-parallel 설정을 통해 동시에 실행할 job의 개수를 설정해줄 수 있다.

jobs:
  test-concurrency:
    runs-on: ${{ matrix.os }}
    strategy:
      max-parallel: 1 # 동시에 1개만 job이 실행되도록 설정
      matrix:
        os: [ubuntu-latest, windows-latest, macos-latest]  
    concurrency:
      group: sequential-test
      cancel-in-progress: false # 이전 작업을 취소하지 않는다는 설정

실험 결과 순서대로 하나씩 runs-on을 실행함!

[hyeonji1220]

ASG를 꼭 써야할까?

https://docs.aws.amazon.com/ko_kr/codedeploy/latest/userguide/applications-create-blue-green.html

https://docs.aws.amazon.com/ko_kr/codedeploy/latest/userguide/deployment-groups-create-blue-green.html

[hyeonji1220]