인프콘을 보고

인프콘에서 재밌어 보이는 주제 몇 가지만 정리해 보았습니다.

[무료] 인프콘 2022 다시보기 - 인프런 | 강의

 

1. 서버비 0원, 클라우드 큐 도입으로 해냈습니다! 조현영

zeroCho님의 발표 자료입니다.

ZeroCho Blog

 

 

상황

엑셀 업로드, 다운로드 시 서버에 메모리 부족 문제가 발생해 OOM이 발생하고 있었습니다.

 

엑셀 업로드, 다운로드의 경우는 대용량의 데이터를 가공할 가능성이 많습니다.

실제로 엑셀의 경우 일반인 분들이 자주 사용하며 대량의 데이터를 모았다가 업로드, 다운로드하는 경우가 많습니다.

 

그 많은 데이터가 메모리를 차지하기 때문에 OOM이 날 수 있습니다.

 

저희 회사의 다른 팀에서도 동일한 문제가 있었습니다. 

다른 점은 저희는 엑셀 다운로드 시점에 OOM이 난 것이고 발표 내용은 업로드 시점에 OOM이 난 것입니다.

저희는 스케일 업을 하였지만 해당 발표에서는 다른 방법을 제시합니다.

 

해결 과정

해결 방법 중 소개된 것이 스케일업, 스케일 아웃인데, 스케일아웃에는 소개된 것이 오토스케일링입니다.

스케일 업은 서버의 물리적인 성능을 향상하는 것입니다.

스케일 아웃은 서버를 증가시키는 것입니다.

저는 오토스케일링이 만능인 줄 알았습니다. 

이론상 너무 이쁜 그림이 그려질 줄 알았는데 소개된 내용에는 바로 cpu100 메모리 100을 찍으면 다음 인스턴스가 뜰 동안 먹통, 다음 인스턴스가 떠도 바로 100을 찍으니 먹통인 것입니다.

 

2024.03.06
다를 수 있지만 100이 기준점이 아니라 60, 70만 떠도 오토스케일링을 할 수 있을 듯 하다.

 

해결 방안

발표자 분은 다른 아키텍처를 보여주십니다.

 

바로 엑셀을  S3에 올리고 올라간 파일을 람다를 이용해 json형태로 바꾼 후 메시징 큐를 이용하는 것입니다.

큐는 AWS의 SQS를 사용한 것으로 보입니다. 

어드민 서버는 원하는 MAX값만큼 적절하게 SQS에서 당겨와 처리를 하게 되어 서버에 부담이 덜 가게 됩니다.

 

이러한 방법을 이용해 라이더의 배송 완료 처리도 처리하는 모습을 소개합니다.

 

 

이러한 해결 방법으로 인해 스케일 업 없이 엑셀 업로드를 해결할 수 있었습니다.

기본 제공되는 AWS의 기능들이기에 기준치만 넘지 않으면 무료로 사용할 수 있는 기능들입니다.

 

언제 쓰면 좋을까요?

저희 회사도 비슷한 점이 있습니다.

• 특정 기능만 부하가 몰릴 때
• 특정 시간에만 부하가 몰릴 때
• 갑작스럽게 몰려서 오토스케일링이 안될 때

 

저희 회사 또한 위에 3가지가 해당하기에 공감이 가고 도움이 되는 세션이었습니다.

 

 

질문

SQS 방식을  pub/sub 구조로 바꾸면 안 될까요?

가능하지만 중복 등록되지 않도록 합시다.

->자주 사용되는 kafka에서는 컨슈머 그룹 등을 잘 제공해 주기에 문제는 없어 보입니다.  

 

 

문제점

1. 대기열이 생겼기에 사용자 입장에서는 작업이 느리게 처리되는 것처럼 보입니다.

2. 총개수가 몇 개인지 파악이 어려워집니다. -> 특정 시간마다 집계를 하는 방법으로 해결할 수 있습니다.

 

* 다운로드 시 에 스케일 업 없이 해결하는 새로운 방법을 네이버 테크 블로그에서 볼 수 있었다.

제로초님에게 질문을 남겼었는데, 스트림즈 이야기를 해줘서 찾아봤더니 네이버에서 소개한 방법이 존재했었다.

https://d2.naver.com/helloworld/9423440

 

 

2. 나도 내 코드의 문제를 알고 싶다고요? 

한주승 님의 발표 자료입니다.

 

주제

테스트를 할 때 기억해야 할 기본 적인 것들에 대한 발표입니다.

 

 

1. 테스트 케이스 정의하기

테스트를 하기 전에 무엇을 테스트해야 할지 정의해야 합니다.

test행위를 통해 어떤 기댓값이 발생하는지를 정의합니다.

하지만 잘못 정의된 테스트 케이스는 제품의 불량을 가져오게 됩니다.

 

2. 요구사항 분석하기

테스트 케이스는 어떻게 바르게 정의할 수 있을 까요?

제품 요구사항을 통해 정의할 수 있을 것입니다.

테스트 케이스는 그저 제품 요구사항을 바꾼 다른 말이라고도 할 수 있습니다.

 

 

3. 문제 해결하기

요즘은 타 팀과의 협력을 통해 개발을 할 때가 많습니다.

그러다 버그가 발생했다면 남 탓보다는 인터페이스를 확인해봅시다. 

내가 제대로 된 정보를 input으로 제공하고 있는지?

output이 정의된 대로 오는지를 확인하고 input의 문제라면 나의 코드를 output이 문제라면 예제를 들어 타 팀과 협의해볼 수 있습니다.

 

 

-

 

해당 주제를 봤을 때는 테스트 코드를 통한 테스트 방법 소개인 줄 알았지만 전체적인 테스트 방법에 대한 것을 소개해 주십니다.

요즘 유닛 테스트에 대한 생각이 조금씩 변하고 있어 테스트 관련 주제를 선택하여 글을 써 보았습니다.

모든 커버리지 등은 좋지만 마냥 커버리지에 목메기, TDD 맹신하기 등의 생각은 좋지 않다고 생각합니다.

Test코드를 처음부터 잘 설계하지 않으면 깨지기 쉬운 Test코드들이 많이 발생할 수 있습니다. 

 

관련 주제로 한 포프 님의 유튜브 또한 많은 생각을 할 수 있게 도와주었습니다.

버그 발생 시 유닛 테스트 추가,

변하지 말아야 할 코드의 의미가 있을 시 테스트 코드 추가.

등의 기준을 제시하시고 있습니다.

"TDD는 죽었다" - Rails를 만든 DHH의 글