jongviet

*3월3일 eks 오토스케일링을 통해 트래픽에 맞춰 노드가 죽고 뜬다. 내부에 속한 파드 또한 이리 저리 이동하면서 자리 잡게 되는데 노드 확대 & 축소가 여러번 반복되다보면 특정 디플로이먼트의 파드가 균형없이 여러 노드에 배정되게 된다. 결과적으로 새로 뜬 노드에 주요한 디플로이먼트가 배정되지 않는 상황도 초래하고 노드 별 CPU가 불균형하게 사용되게 된다. 트래픽을 많이 발생시키는 디플로이먼트의 파드들은 기본적으로 HPA를 적용했었고, 적용된 디플로이먼트는 노드 수를 초과하는 수의 파드를 최소한 가지게 된다. *HPA란(HorizontalPodAutoscaler) - 디플로이먼트 단위로 워크로드 크기에 따라 자동으로 파드 수를 조절해주는 기능 - 디플로이먼트 단위로 yaml을 제작하며, CPU 사용률..

*2월29일 트래픽 폭증으로 인해 AWS EKS 오토스케일링을 적용하면서 다양한 문제가 생기게 되었다. 그 중 배치 서버의 파드가 cron으로 돌아가는 테스크를 완료 하지 않은 시점에 지속적으로 종료되는 문제가 발생했다. 새로운 EC2에 배치 서버를 띄우면 쉽게 해결이 되지만, 여러 보안 설정, 다른 배포 방법 등.. 너무 귀찮고 관리 범위도 많아진다. 그렇다고 배치서버의 파드를 2개로 증가시키면 멱등성이 확보되지 않은 상황에서 중복된 일을 하게 되는 문제 또한 발생한다. 이러한 고민을 해결해주는 설정값을 외부 조언을 통해 확인 할 수 있었는데, 바로 terminationGracePeriodSeconds이다. 직역하자면 종료 유예 기간 초 정도이다. 배치 서버 yaml 내 아래 설정값만 넣으면 오토스케일..

*2월28일 너무 오랜만에 포스팅을 한다. 게을러진 탓도 있고 실무에서 벌어지는 일들을 대응하느라 마음의 여유가 부족했다. 회사 비즈니스 모델이 전환되면서 엄청난 규모의 데이터가 매일 생성되게 되었다. (일 기준 약 300만..) 제휴를 맺고 있는 각 파트너에게 다양한 방향에서 여러 지표를 제공해야해서 다양한 이벤트(유저 동작)으로 인해 파생되는 로우데이터가 매우 잘게 나뉘어 생성되고, 그에 따라 매일 생성되는 데이터의 수도 압도적으로 많아졌다. 그전까지 NoSQL을 사내에서 주력으로 사용하다보니 여러 개념이 부족했었는데 이번 기회에 RDB에 데이터를 축적하면서 RDB에 대해 많이 익히게 되었다. 먼저 RDB 파티셔닝에 대한 개념이 없어서 엄청나게 많은 수가 생성되는 데이터 타입을 별도 테이블로 이관 하..

*5월29일 -전전 개발 직장에서 git action과 Jenkins를 활용하여 CI/CD를 구축한 시니어분이 있었다. 당시에는 그냥 사용해보기만 했었는데 현 직장에서 깃 푸시에 맞춰 빌드 후 쿠버네티스 pod를 띄우는 과정까지 처리하게 되었다. 최초 세팅이고 아직 테스트 쪽이 빠져있어 어떻게 세팅했는지만 개인적으로 정리해보고자 한다. -리눅스 관련 명령어를 별도로 공부했었는데 오랜만에 하려니 다시 생각이 잘 안난다.. 아래 정도만 다시 리마인드하자.. $df -h // 용량 $free -h //메모리 $sudo find / -name 'swap.*’ // 파일찾기 $cat // 파일 터미널 상 표시 $ls -al // 숨김 파일 포함 전체 파일 표시 $vi $vim 1.적절한 AWS EC2 인스턴스를 ..

*5월21일 -대용량 파일 다운로드를 SQS & Lambda 조합으로 본 서버 외에 자원을 사용하는 식으로 구성하다가, 다운로드 내역과 만료 처리가 필요함을 팀 내부에서 느꼈다. 리더분께서 DynamoDB TTL과 stream을 이용하면 Lambda를 트리거할 수 있다고 제안해주셨고 스터디를 통해서 '대용량 파일 다운로드 요청' -> '백엔드 서버' -> 'SQS' -> '파일 추출 및 생성용 Lambda 작업 진행 후 히스토리 데이터 & TTL용 데이터 put' -> 'DynamoDB TTL' 발동 후 'DynamoDB Stream'을 통해 만료 처리용 Lambda에 도달 -> '만료 처리 후 히스토리 데이터 업데이트' 순으로 플로우를 처리했다. 1.Stream 연동 방법 -Stream은 Dynamo..

*5월 7일 -5월2일~3일 일정으로 회사 개발팀 전체 함께 AWS Summit 2023에 참가했다. 들었던 각종 내용들과 앞으로 좀 더 대비하거나 알아봐야할 내용을 조금은 정제된 메모장과 같이 정리해보도록 하자. 1.기조연설 -기조 연설은 Nandini Ramani AWS 모니터링 담당 부사장님, 함기호 AWS Korea 대표이사, 오순영 KB국민은행 센터장, 이준영 야놀자 엔지니어링 수석 부대표분이 진행해주셨다. Nandini Ramani 분이 메인으로 진행하면서 중간 중간 다른 연사들이 나와 특정 주제에 대해 PT 하는 방식이었다. 확실히 서방과 한국식 PT의 차이를 느낄 수 있었고, 모두들 매끄럽게 잘 진행해주셨던 것 같다. 기조 연설 시작 전 Nandini Ramani분의 영상을 좀 찾아봤는데,..

*4월16일 -현재 회사 어드민 페이지 내 특정 테이블 데이터에 대한 엑셀 다운로드 기능을 프론트 단에서 전부 처리하도록 구현 해놓고 있었다. 하지만 추후 회사 외부에 동일한 기능을 제공해야 할 필요성이 생겼고 해당 기능을 SQS & Lambda를 통해 구현해보기로 했다. 1.SQS 구성 -SQS는 생성은 거의 디폴트 옵션으로 진행했다. 유형은 표준/FIFO가 있는데 표준은 순서 보장이 되지 않고 중복 발송이 될 수 있고, FIFO는 글자 그대로 선입선출이고 정확히 1회만 처리한다. 따라서 당연히 후자가 조금 더 비싸다. 하지만 SQS로부터 넘어온 msgId 및 람다 내 캐싱을 통해 표준으로도 충분히 1회 작업만 진행할 수 있다고 판단했기에 표준으로 했다. -SQS 생성 직후 ARN과 URL 값을 잘 ..

-이상한 고집이 있어서 항상 반복문을 통해 DB를 get, put, update, delete 할 때 항상 for await of를 썼었다. 언제부터인지는 모르겠지만 개발 첫 회사에서 통계 관련 데이터를 몽고DB에 update를 치다가, 업데이트 직후 후처리를 순차적으로 해야 할 일이 있어서 그랬던 것 같다. 이번에 특정 기능을 고도화하다가 확실하게 깨달았는데 for await of 대비 promise.all이 단순 get 기준 5배 정도 빨랐다. 1.for await of -순차적으로 반드시 처리되어야 하고 res를 받아서 후처리를하거나 응답값에 포함되어야 해야 할 때 사용! 2.promise.all -순차적으로 처리될 필요가 없는 경우 사용하기 아주 적절. 특히 get의 경우 전부다 받은 다음 추가적..