시간이 느리게 가는 건

오늘 새벽 퇴근할때까지
AWS 서비스 쿼터에 신청한
vCPU 할당 제한에 대한 상한요청은 아직 받아들여 지지 않았다.

저녁식사후에
할당량을 다시 확인해보니
64개에서 96개로 늘어있었다!

그런데 내가 신청한 상한치는 256인데
96까지만 상향을 해주었다.

일단 96개를 가지고 해보기로하고
클릭랩의 백엔드와 데이터베이스를 업그레이드하면서
인스턴스 유형을 업그레이드 했기 때문에

나에게 남은 vCPU는 96 - 28 = 68개 였다.

68개의 vCPU로는
4개의 vCPU를 가지고 있는 c6in.xlarge인스턴스를
17까지 켤 수 있다.

어제까지는 11개였지만
오늘은 17개까지 켤 수 있는 것이다.

이것도 발전이라면 발전이므로
일단 실행했다.

인스턴스 개수를 상한까지 늘리고
다시 팬텀플로우를 통해서
rps측정을 하는데

초반엔 6개가 늘어난 만큼 rps도 늘어났다.

하지만
터미널에 찍히는 로그가
익숙한 움직임을 보이기 시작했다.

출렁임이 똑같이 보이는 것이다.

인스턴스가 늘어난 만큼
rps출렁임의 간격은 늘어나긴했지만

rps가 0까지 내려갔다가
다시 올라오는 현상은 없어지지 않았다.

바닥을 찍고오는 출렁임때문에
rps는 여전히 5,000을 넘기지 못했다.

나쁘지 않은 인스턴스가 17개가 켜져있음에도 불구하고
11개일 때와 같은 증상이 발현되고
rps5,000도 나오지 않는다는 건

내가 rps라는 수치에 대한 감이 없거나
대단히 잘못된 접근을 하고 있거나
아니면 거의 다 왔거나인데

나는 아예 길을 잘못 들어선 걸로 생각하기로 했다.

vCPU용량 상한을 더 늘려 받아서
인스턴스 개수를 늘려서 해결하는게
몸과 머리가 가장 편한 방법이긴 하다.

이미 11개에서 17개로 넘어갈때
약간이나마 rps가 늘었음을 확인했고
이제 돈으로 밀어 붙이는 선택지가 있음을 확인했다.

하지만 나에게는 1,000달러 크레딧 제한이라는
게임의 규칙이 있다.

게임의 규칙을 지키면서 뽑아낼 수 있는
최대의 rps가 의미가 있는 rps일 것이기에

일단 다른 방법론을 택하기로 했다.

다른 방법론이란
vCPU 96개라는 제한된 자원을
파워가 쎈 컴퓨터 17대가 아닌
파워가 약한 컴퓨터 50+대에 투입해 보는 것이다.

시도해보기 전엔
그 무엇도 증명할 수 없다.

나도 이렇게 해서 rps가 높아질 거란 확신은
이 세상에서 제일 없었다.

이제 돈 아껴야하는데…

설령 돌고 돌아 처음과 같은 생각과 결론을 내린다 해도,
고민 끝에 처음과 같은 생각에 다다른 경우와,
고민해도 어차피 같은 결론일 거라
깊이 고민할 시도조차 안 하는 경우는
분명 다른 삶이 펼쳐진다고 나는 믿는다.

『료의 생각 없는 생각』 p.164