개발일기장

문제 - CDN 비용이 너무 많이 나온다.커뮤니티 서비스의 특성상, 대량의 이미지가 업로드되고 조회되고 있었다현재 S3에 저장된 이미지는 CDN을 통해 제공되고 있으며,일 평균 16만 건의 요청에, Data Transfer Out 바이트가 약 1,600GB가 사용되고 있었다.이로 인해 한 달에 약 160만 원의 CDN 비용이 발생하고 있었다. 문제의 원인은 다음과 같았다. 1. 비효율적인 이미지 포맷 사용대부분의 이미지는 JPG, PNG 형식으로 저장 및 조회됨해당 포맷은 상대적으로 용량이 크고, 전송 시 데이터 비용이 높음2. 이미지 크기 최적화 부족사용자가 업로드한 원본 이미지를 리사이징 없이 그대로 사용평균 이미지 크기가 약 2MB로, 불필요하게 큰 용량을 차지3. 적합하지 않은 캐시 정책관리형 캐..

지난 12/26일부터 특정 유저를 대상으로 무료 3,000원 쿠폰을 지급하는 이벤트를 진행했습니다.이번 이벤트의 지급 대상은 약 320만 명으로, 팬아웃 패턴 아키텍처를 도입하여 서버의 부하 없이 연말 이벤트를 성공적으로 마칠 수 있었습니다. 🎁(쿠폰함을 확인해보세요 소근소근) 팬아웃 패턴을 aws 자격증을 준비할 때 학습했는데, 실제 적용할 기회가 생겨 굉장히 뿌듯하였습니다. :)  도입 배경이전에도 유사한 쿠폰 지급 이벤트를 여러 차례 진행했으며, 종종 서버 부하 문제에서 벗어날 수 없었습니다API 서버: 유저가 쿠폰 지급 대상인지 확인한 뒤, 대상자라면 SQS에 이벤트를 발행.Lambda: SQS에서 이벤트를 소비하여 쿠폰 지급 작업을 처리.그 당시에도 쿠폰 지급 대상이 약 300만 명으로 추산 ..

담당하는 앱 서비스에는 1분 이상 라이브 방송을 시청하면 그에 대한 랜덤 룰렛을 돌려서, 랜덤 캐시를 지급하는 서비스가 있습니다. 랜덤 캐시는 2,3,5 캐시등과 1000 혹은 10,000 캐시의 당첨 캐시가 존재합니다.이 랜덤 캐시는 라방 1개당 1번만 받을 수 있으며, 천,만 캐시 당첨자인 경우 라방 종료 후 리스트로 보이게 됩니다. 문제 - 모든건 너무 많은 데이터 때문이야..이렇게 랜덤 캐시를 저장하는 DB는 DynamoDB를 사용하고 있는데요.세월이 흘러 이 DB에는 약 26억건의 456GB의 데이터가 저장된 상태였습니다. 이렇게 랜덤 캐시를 저장하는 DB가 너무 크다 보니 다음과 같은 문제가 발생했습니다.불필요한 26억건의 데이터 저장 비용 발생이게 왜 발생하는지 원인을 알기 위해 Dynamo..

사내에서 기존에 1000줄에 달하는 복잡한 회원가입/로그인 기능 마이그레이션을 제안하고, 진행하게 되었다.그를 위한 첫 단계로, 코드의 안정성을 보장하고 변화에 대응하기 위해 테스트 코드를 도입하게 되었다.특히, 통합 테스트를 중심으로 시스템 전반의 정합성을 검증하고자 한다.다음은 aws , db등 여러가지 환경에 얽혀있는 서버를 로컬에서 가장 간단히 테스트하기 위한 환경 구축기이다. 통합테스트란?통합 테스트는 흔히 E2E(End to End) 테스트라고 불리며, 애플리케이션의 모든 계층을 거쳐 최종적인 기능이 올바르게 동작하는지 검증하는 방법입니다. 즉, 실제로 API 서버를 가동시킨 후 클라이언트가 서버에 요청을 보내고, 그 요청에 대한 응답이 예상한 결과와 일치하는지 확인하는 방식입니다. ex. 정..

최근 회사에서 진행한 DynamoDB 글로벌 보조 인덱스 최적화를 통해 월 2,000달러의 비용을 절감할 수 있었다 문제 : 왜 인덱스 하나의 비용이 월 2,000달러나 나오는데?인덱스 프로젝션 속성이 ALL이면, 그만큼 데이터를 저장하고, 조회하고, 쓰는데 비용이 부과되었기 때문이다.인덱스는 생성 시 함께 프로젝션(저장) 될 속성을 선택할 수 있다. 2024.07.20 - [분류 전체보기] - DynamoDB 알아가기(1) - 인덱스(index), 쓰로틀링(throttling)KEYS_ONLY: 인덱스와 같은 Key만 포함INCLUDE: 특정 항목을 지정하여 포함 (예: name, phone 등)ALL: 모든 속성 포함 예를 들어 user 테이블이 다음과 같다고 하자.이때 snsId라는 값은 sns_i..

회사에 들어와서 처음 맡은게 멀티 태넌시로 이루어진 모듈이었다.일단 멀티태넌시라는 말을 처음 들어봤고, SaaS도 처음 하는 거라서, 부담감이 있었다.그렇게 인수인계를 받고 모듈 작업을 했다.   좋은 경험이였다.설계를 정리 해서 사내에 공유를 했다. 입사하고, 꼭 글을 공유하는게 목표였는데 드디어 이루었다. 내용을 블로그에도 올려본다. 누군가는 도움을 받겠지.+ 자세한 내용을 못 적는 점은 양해 바랍니다 맡은 서비스는 다양한 타서비스에서 서비스를 제공받게 모듈화를 하는 멀티 태넌시 아키텍처를 가진 SaaS 모듈이다.기존에는 클라이언트와 서버가 1:1 = 클라이언트:서버 로 서비스를 유지했다면, 멀티 태넌시 아키텍처에서는N : 1 = 클라이언트:모듈의 형태로 하나의 모듈에 다양한 형태의 서비스가 붙을 수..

회사를 들어온 지 2주 남짓 지났나, 회사에서 운영하는 앱에 있던 하나의 서비스를 똑 떼서 다른 앱에도 붙일 수 있게 멀티 태넌시(SaaS)를 구축하는 업무를 맡았다. 그중 일정 데이터를 산출하는 통계작업을 serverless로 크론으로 돌리면서 설계부터 많은 우여곡절과 고민을 하였다. 정리를 해본다. 일단 멀티 태넌트가 수행하는 요구사항은 독립적이지만, 정 반대로 크론 잡은 모든 db에 일괄적으로 시행을 해야 해서 머리가 복잡했다.요구 사항멀티태넌시 아키텍처를 가진 시스템에서의 매일 정오 시행 되는 크론 작업모든 태넌트들의 DB에 시행멀티 태넌트는 논리적 DB 로 분리서버리스(serverless)로 시행아키텍처 고민하나의 cron 서비스에서 모든 태넌트의 db 관리비즈니스 로직에 멀티 태넌시 아키텍처의..