서버 죽었는대요?

제목이 좀 많이 흠칫하네요.

회사에서 도메인을 바꾸다 일어난 일을 기록했습니다.

다 끝나고 보니 웃김

 

드디어.. 리뉴얼 개발이 끝난 날.. 나: 배포하겠습니다. 팀장님: 그래요~.

route53 에 연결되어있던 sellbuymusic.com 의 대상을 IP 에서 alb 로 갈아끼워야했습니다.

리뉴얼 개발은 다 해놨고 도메인만 갈아끼면 되는 상황! → 뭐야 개 쉽네?

후딱 하고 로그 계속 봐야겠다~ 생각했으나. 3월 4일 2시 10분에 시작한 배포는 장장 3월 5일 1시 10분이 되어서야 끝났습니다.. 밤을 새서 한건 아니고 4일 2시 10분부터 6시쯤까지 서비스가 제정신이 아니다가 도저히 안되겠어서 alb에서 IP로 돌렸습니다. 일대기 시작.

0: 레코드를 어떻게 바꿔칠까

찾아본 결과…

aws route53에는 라우팅 정책중에 가중치 기반 라우팅이 있더군요

오 그럼.. 바꿔치기 할 때 eventBridge 로 걸어서 바꾸면 되겠네

나의 계획:

1. IP 로 붙어있는 기존 레코드의 라우팅 정책을 단순 → 가중치 기반으로 변경 (가중치 255)
2. 가중치 기반으로 새로운 레코드 생성. 이건 대상을 IP 가 아닌 alb 로 연결 (가중치 0)
3. eventBridge 에 가중치를 바꾸는 것 시간 걸기
4. 해당 시간에 바뀜
5. 여유롭게 로그를 확인한다

계획은 창대했으나 3번부터 문제가 생겼습니다.

일단, deploy-role 에 스케쥴러 권한이 없음. 페이로드에 넣어도 실행 안됨. 왜 안 됐나 보려고 하면 SQS 에 데드 레터 큐(DLQ) 달고 봐야함. (아오귀찮아 알아서 cloudwatch 에 넣어달라고요)

SQS 보니, 아래 같은 에러가 계속 발생함. 어느순간 저는 타입 지옥에 있었습니다.

 

Invalid RequestJson provided. Reason The field 'TTL' is not supported by api 'changeResourceRecordSets' for the service 'aws-sdk:route53'.

 

제미나이는 계속 이거에 대해 에러가 난다고 하니, 그냥 람다로 하는것이 훨씬 깔끔하다고 했습니다. 왜 그 생각을 못 했지 람다에 하면 로그도 cloudwatch 로 넣어줘서 보기 편합니다.

삽질 몇번 끝에 최종 람다 코드입니다.

import boto3

def lambda_handler(event, context):
    client = boto3.client('route53')
    
    response = client.change_resource_record_sets(
        HostedZoneId='',
        ChangeBatch={
            'Comment': 'Switching traffic completely to new version',
            'Changes': [
                {
                    'Action': 'UPSERT',
                    'ResourceRecordSet': {
                        'Name': 'sellbuymusic.com.',
                        'Type': 'A',
                        'SetIdentifier': 'sbm-old-version',
                        'Weight': 0,
                        'TTL': 300,
                        'ResourceRecords': [{'Value': ''}] 
                    }
                },
                {
                    'Action': 'UPSERT',
                    'ResourceRecordSet': {
                        'Name': 'sellbuymusic.com.',
                        'Type': 'A',
                        'SetIdentifier': 'sbm-new-version', 
                        'Weight': 255,
                        'AliasTarget': {
                            'HostedZoneId': '',
                            'DNSName': '',
                            'EvaluateTargetHealth': True
                        }
                    }
                }
            ]
        }
    )
    print(f"Route53 응답 결과: {response}")

테스트 완료. 잘 되네. 뭐. 진행시켜.

1: 오 붙었다 붙었다

당일.. 약속의 시간 오후 2시. 본부장님: 10분만 늦추자 나: 네

다시.. 약속의 시간 오후 2시 10분.. ‘자 갑니다~…’

오케이. 람다는 약속을 지켰고~

ecs 에 잘 붙었다! 오 붙었다!! 붙었어요!! 아닐걸?

핵심 기능 테스트 해보니 잘되네.. 나이스 나:나머지 도메인들도 리다이랙트ㄱㄱ!

모바일은 m.sellbuymusic.com, 영문은 en.sellbuymusic.com, 영어 모바일은 enm.sellbuymusic.com 이런식으로 되어있어서 이걸 전부 리다이랙트를 해주어야했습니다.

근데. 타이밍 좋게(?) 나머지 도메인들을 alb에 붙이니.. ecs 태스크가 재시작 하는 거 아니겠습니까…? 어라..?

지표 보니 cpu 사용량 100%!! (네?) 일단 cpu 와 메모리를 더 늘려서 배포를 다시 해줬습니다. (로컬과는 사뭇 다른 사용량) 근데도 죽네?

 

Task failed ELB health checks in (target-group arn:aws:elasticloadbalancing:ap-northeast-2:211125666341:targetgroup/sellbuymusic-fe-tg/f9ad6bbb070cf9cd)

 

alb: 죽일게 ㅇㅇ.

스테이징 도메인에 있을 땐 문제 없었잖아 왜그래 진짜로

지옥의 디버깅이 시작됐습니다.

2: (웃음을 잃었다)

일단, 첫 번째 오류…

NEXT APP URL 이 build 될 때 ENV에서 제대로 들어가지 않은것같다. 일단 하드코딩으로 바로 넣자.

오케이. 다음.

근데도 안되네? 이것저것 시도해보니 어느새 오후 6시.. 장장 3시간 넘게 서비스가 맛갔습니다.. 옆에서는 cs 전화가 울리고 운영팀이 커버치시는 소리가 들려요… alb님 더이상.. 죽이지 말아주세요..ㅜㅠ 제발요ㅠㅜ

팀장님이랑 야근하면서 원인을 찾았습니다. 제가 가중치 기반으로 라우팅을 걸면서 대수롭지 않게 생각했는데 ‘대상 상태 평가’ 라는 항목.. ㅜㅜ 이 항목을 true 로 해놓으면 가중치를 255 - 0 으로 해두더라도 가중치 255 쪽이 이상하면 가중치 0인 쪽으로 도메인을 돌립니다.. curl 날리면서 깨달았어요. 상태 평가 항목을 일부로 끄지 않는 이상 기본 옵션은 ‘켜져있습니다.’ 사실 켜놓는 것이 유리한데, 이 경우에는 아니였던 겁니다.

그 이유는 가중치 0으로 해놓은 곳에 (IP) 가면 그걸 그 서버개발자가 특정 주소가 아닌 이상(b2b는 허용) alb로 리다이랙트 하게 해놓은 것이죠..

aws: 뭐야 서버 이상한데? 어쩔 수 없지 가중치 0인곳으로 가

이전 서버: b2b에 등록된 곳 아니네? 뭐야 리뉴얼도 했는데 alb로 가~

aws: 뭐야 서버 이상한데? 어쩔 수 없지 가중치  0인곳으로 가

…

리다이랙션 지옥에 와버린거죠.

어떻게든 ecs를 죽이고 테스트 해 본 결과입니다.

팀장님: 내일 아침. 다시 가보자.

3: 빙산의 일각

다시 돌아온 약속의 시간.. 오전 9시..

나: 슛할게요?

오 됐다! 잘 된다!! 결제랑 다 잘돼요!! curl 날려도 정상이에요!

오케이.. 나머지 도메인도 이관가자…

그렇게 m.sellbuymusic.com을 붙인순간.. 서버가 또 죽었습니다. (저는 그만 정신을 잃을뻔 했습니다)  

다시 해보자. (해보자가 아니야. 해야하는거야. 할수있습니다가 아니야. 해야하는거야.)

무수히 curl을 날린 결과.. 알아냈습니다.. 다른 서브도메인들(m, en, enm, jp, jpm) 붙인 순간 죽어버리고, 이곳으로 curl을 날리면 무한 리다이랙트를 하는 것입니다. (리다이랙트 너무 많이 했다 는 에러가 나옵니다.ㅎㅎ)

왜 리다이랙트를 할까…? 그것은 바로.. 저의 실수때문이었는데요..

다국어를 적용하면서 뭐 하나 바뀔때마다 서버 배포하기 싫음 + 수정 있을 때 운영단에서 알아서 했으면 좋겠음. 으로 생각하다보니 google apps script 를 이용하게 되었고… 그걸 이용해서 캐싱하고.. 그러다보니 api가 필요했고.. 그러다보니 url 이 파졌고.. 예.. 근데 우연히라도 사용자가 /api 페이지에 들어오는 것이 싫었습니다. (중요한 정보는 없는데.. 혹시 모르니까..ㅎㅎ) 그래서 alb 규칙 우선순위에 sellbuymusic.com으로 오면 이 tg로 보내! 하는 것보다 더 위에 sellbuymusic.com && /api/* 면 redirect 해~ 를 해놨는데 ㅎㅎ..

이게 build 될 때 route.ts 가 먼저 실행되고, 그 다음에 Api 인스턴스가 만들어지면서 여기서도 리다이랙트 지옥이 펼쳐지고 있었던겁니다. (로컬에 console 찍으면 바로 나와요 ㅎㅎ)

next: 오케 다국어 json 다 받아와볼까~

당연히 next 에 닿기도 전에 alb가

alb: 뭐야.. 니가 뭔데 /api/* 로 와? / 로 리다이랙트.

지옥 시작… 이게 지옥이지

바로 삭제.

가장 유저가 적은 jp로 테스트해보고.. 잘된다.. 오케이.. curl 날려도 의도대로 리다이랙트 됨.. 이때부터 저도 모르게 웃음이 나오더군요.

다.. 붙었다.. 지옥 탈출이다..

팀장님: 진짜 수고했다

감사합니다… 커버 쳐 준 운영팀.. 계속 같이 디버깅해주신 팀장님..

이틀동안 정말 많이 배웠습니다.. 배포에 자신감이 좀 있었는데 이번에 두려움을 배웠습니다. 옆에서 전화소리가 울리면 흠칫하게 되요.. (운영팀 미안합니다..)

4: 하지만 됐죠?