개발 일기

최근에 있었던 일을 간략하게 작성해 봅니다. 사건 사이드 프로젝트와 연관된 게임의 이슈가 터지게 되었고 마침 그 이슈가 사이드 프로젝트와 긴밀한 관계가 있었다. 많은 유저들이 웹 사이트에 들어오게 되었다. 정말 많은 트래픽이 발생하였는데.. 결과 정말 약 1일 정도(24시간) 정말 재미있는 일이 있었다. 이슈 발생 초기 뉴스가 나가고 트래픽이 엄청나게 상승하기 시작했다. 그라파나에서 보는 ALB 분당 Request가 평균 8천 건이 넘어갔다. 핀포인트에서도 RealTime(5분) 동안 Request가 엄청나게 발생하였고 시간이 지날수록 Request가 더욱 증가하게 되었다. front 서버와 backend 서버의 스케일 아웃도 동작하게 되었다. (지금껏 동작한 적이 없다.. ) 클라우드 환경의 이점(확장..

(런칭은 11월 30일에 하였지만 글을 1월에 작성..) V1 런칭 V1을 만들어서 런칭했다. 예상작업보다 7일 정도 딜레이 되었지만 결국 해냈다는 거에 의의를 두고 있다. 모든 큐브데이터를 저장하였고 현재는 통계를 보여주고 있다. 샤딩은 디비 서버를 여러대로 분리하는 건데 지금 우리는 디비 서버를 여러 대 두기에는 비용적 측면에서는 부족하여 논리 디비 샤딩을 채택하였다. mysql 내에서 스키마를 여러 개 만들어 데이터를 분산해서 처리하고 있다. 현재 기준으로 1억 4천만 건이 저장되고 있고 데이터를 가공하고 통계데이터를 만들고 보여주고 있다. 회고 저장은 jdbctemplate 조회는 jpa를 사용하여 데이터를 서빙중에 있는데 샤딩을 직접 로직을 생각해서 만들어본게 처음이라 내가 예상한것보다 개발 기..

v1 런칭을 위해 필요한것들 v1에 새로운 기능들이 추가되었다. 1. 캐릭터 정보 2. 랭킹 3. 큐브 사용 모든 raw 데이터들 캐릭터 정보 기능 캐릭터 정보 기능은 현재 메이플스토리에서 제공하는 api가 없다 그래서 우리는 크롤링을 하여 가져오기로 결정 하였고 메이플 사이트를 매번 크롤링 하면 블락을 먹게 될테니 아래 구조로 시스템을 만들기로 했다. 1. 초기 데이터 저장시 캐릭터 따로 저장 2. 캐릭터 명을 aws sqs에서 전송 3. aws lambda가 "제한된" 개수 만큼 sqs에서 꺼내가서 크롤링 4. aws lambda가 api 서버에 전송 5. 저장 이렇게 한다면 lambda가 일정 주기 및 동시 실행 제어로 메이플 스토리 크롤링을 매번 안하게 되고 사이트에서 블락을 당하지 않을거라는 판..

그라파나 프로메테우스 도입 슬슬 트래픽도 어느정도 있고 cpu 사용량 및 인프라 지표를 보는데 매번 aws에 가서 MFA 인증을 하고 각 인프라에가서 지표를 보는게 너무 번거러워 그라파나랑 프로메테우스를 사용하여 한곳에서 모니터링을 할 수 있도록 하고싶었다. 하지만 문제가 있었는데 결국 그라파나를 설치할 서버(비용) 이 필요했고 사이드 프로젝트를 진행하면서 최대한 프리티어를 활용하고 적은 비용을 내고 싶었다. 다행이도 백엔드 친구가 본인의 나스를 제공해주겠다 하였고 aws cloud watch를 사용하여 aws인프라들을 한곳에서 모니터링 할 수 있게 되었다. 핀포인트의 도입 핀포인트를 도입하려 했다 이유는 아래와 같다. 1. request 파라미터들을 보고싶었다. 2. 400대 요청들의 실패 원인 및 그..