프로젝트/고민 (39) 썸네일형 리스트형 전국 법정동 데이터 저장과 공간 데이터 글 쓰기에 앞서 최근 모두의 텃밭 프로젝트를 하던 중 공간 데이터를 마주치게 됐다. 프로젝트의 기능 중 많은 부분이 위치 정보를 기반으로 제공하는 기능이 많다. 예를 들어 현재 위치를 기반으로 주변 텃밭, 우리 동네의 작물 판매 정보, 커뮤니티 기능이 이에 해당하게 된다. 따라서 이를 위해서는 현재 위치가 어떤 동네에 포함되어 있는지 빠르게 검색할 수 있어야 하기 때문에 대한민국의 법정동 데이터를 db에 구축해 놓을 필요가 있었다. 공간 데이터 타입 dbms로 MySQL을 사용했기 때문에 MySQL에서 지원하는 공간 데이터 타입을 알아야 한다. 위와 같은 공간 데이터 중 우리 프로젝트에서는 법정동(예를 들어 서울 특별시 종로구 통인동과 같음)에 해당 주소의 중심 좌표(Point), Multipolygon.. 내가 작성하지 않은 코드를 개선해보자 개요 최근 프로젝트 한개를 이어받게 됐다. 프로젝트에 대해 간단하게 소개하자면 농림축산식품부 창업 경진대회에서 우승한 프로젝트이며 광고비를 지원받고 실제 사용자를 모을 수 있다는 점에 매료되어 참여를 결심했다. 간단하게 설명하자면 텃밭에 대해 임대인과 임차인 간 연결을 해주는 플랫폼이다. 주말 농장을 하고 싶어하는 분들 또는 텃밭 체험을 하고 싶지만 텃밭 정보를 구하기 어려워 하는 분들을 위해 좋은 경험을 제공하는 목적을 갖고 있다. 실제 사용자가 편하게 이용할 수 있게 하나씩 고민했고 코드적인 문제가 가장 눈에 띄었다. 문제 정의 가장 먼저 개선한 부분은 날씨 정보를 제공하는 API이다. 기존의 코드에는 날씨 정보를 제공하는 API가 존재했고 이는 공공데이터 날씨정보로부터 받아오는 구조였다. 엔드포인트.. 성능 최적화 (S3업로드 병렬 처리와 이미지 리사이징) 이미지 리사이징 현재 톰캣, Nginx의 기본 설정으로 인해1MB 이상의 이미지는 받지 않도록 설정 되어 있다. 현재 프론트 단에서 따로 압축을 해주지 않았기 때문에 사용자는 높은 화질의 이미지를 업로드 할 수 없는 불편함을 겪게 될 것이다. 이에 사용자의 경험을 좋게 해주고 저장 공간도 효율적으로 관리하기 위해 리사이징 처리를 해주는 것이 좋을 것 같다. 내가 사용한 이미지는 9MB 크기의 고용량 이미지다 초기 상태 보는 바와 같이 이미지의 용량이 크더라도 전혀 압축되지 않고 S3에 업로드 된다. 저장 공간을 비효율적으로 쓰고 있을 뿐만 아니라, 사용자가 위 이미지를 볼 때 렌더링 되는데 소요되는 시간도 클 것이다. 아래는 실제 결과이다. 하나의 이미지를 로드하는데 4.2초가 걸렸고 크기 또한 9.8M.. 성능 최적화(캐시) 이번 글이 이번 프로젝트의 성능 최적화 글 중 마지막이 될 것이다. db io가 발생하지 않는다면 어플리케이션의 성능은 극대화 된다. 하지만 Redis와 같은 캐시서버의 운영 비용은 만만치 않으니 신중하게 선택하자. 나의 경우 로컬 캐시인 카페인 캐시를 이용해 캐시를 운영했다. 사용한 이유는 러닝 커브가 매우 낮다는 점이 가장 크다. 또한 성능이 매우 우수하다고 한다.https://github.com/ben-manes/caffeine/wiki/Benchmarks Benchmarks A high performance caching library for Java. Contribute to ben-manes/caffeine development by creating an account on GitHub. gi.. 성능 최적화 (스케일 업, 인덱스 튜닝) 목표 TPS 저번 글에서 시나리오를 통해 성능테스트를 진행해봤다. TPS는 13이 나왔고 목표했던 17 ~ 52에 한참 모자란 결과이다. 예상보다 TPS가 너무 나오지 않아 원인을 분석해본 결과 DB인 것으로 확인이 됐다. 그래서 팀원끼리 각자 맡은 도메인에 대해 쿼리를 개선해보기로 하고 다시 성능테스트를 해봤다. DB에 데이터는 10만건 들어있는 상태다. 먼저 시나리오에 포함되지 않은 읽기 쿼리들까지 포함해서 성능테스트를 해본 결과 다음과 같은 결과가 나왔다. 에러율은 낮지만 TPS는 4.7로 처참한 것을 확인할 수 있다. db는 RDS의 t3.micro를 사용하고 있었는데, cpu 사용량이 100퍼센트 가까히 찍히는 것을 확인할 수 있다. 단순히 인덱스 튜닝만으로는 해결할 수 없을 정도의 TPS와 R.. Ngrinder로 성능테스트 하기 계기 프로젝트가 거의 마무리 되고 조만간 프론트엔드 분들도 작업이 완료될 예정이라고 한다. 이에 따라 사용자를 받기 전에 목표하는 트래픽을 감당할 수 있을지 성능테스트를 해보고 필요하다면 로컬 캐시, etag, 인덱스를 태우거나 쿼리 튜닝을 하고자 한다. 목표하는 트래픽 잡기 내가 진행중인 프로젝트를 간단하게 소개하자면 지도에 사진, 평점 등과 같은 것들을 기록하고 일기를 작성하는 지도기반 커플 다이어리이다. 유사한 어플리케이션으로 커플 앱인 비트윈, 썸원이 있고 다이어리 어플인 timetreep이라는 어플리케이션이 있다. 이제 similarweb이라는 사이트에서 위 어플리케이션들이 얼마나 많은 트래픽을 받는지 확인하고 목표 트래픽을 잡아보자. 썸원인 경우 한달에 약 23만, 비트윈인 경우 한달에 약 1.. 코드의 품질 관리를 도움 받기: SonarCloud, CodeMetrics SonarCloud 코드를 작성하다 보면 통용되는 컨벤션, 중복되는 코드, 보안 취약점 등을 인지하지 못한채 개발하게 된다. 심지어 Java를 C언어 처럼 사용한다거나 Go 언어를 Javascript처럼 사용하는 경우가 있을 것이다.(본인이 익숙한 언어에 맞게 다른 언어를 사용함) 이렇게 되면 새로운 언어를 배운다 하더라도 자신에게 익숙한 언어의 언어스타일로 개발을 하게 되는데 새로운 언어를 사용하는 의미 또한 많이 떨어질 것이다. 이러한 문제를 해결하기 위해 SonarCloud라는 코드 분석 오픈소스가 탄생하게 됐다. 품질관리 요소 이제 어떻게 품질을 관리하는지 알아보자 소나큐브가 코드를 분석하는 지표는 여기에 있다. Java를 기준으로 사용해본 결과 이펙티브 자바에서 강조하는 내용과 일치하는 부분이 .. 우리의 문제 상황에 맞는 락 구현 요약 사용자가 여러개의 좌석을 선택한 상황에서 동시에 다른 사용자가 선택한 좌석과 겹치는 상황이 발생했을 때 어떻게 하면 사용자의 경험을 좋게하면서 최소한의 비용으로 이 상황을 극복할지에 관해 작성했다. 좌석을 선점(선택)할 때는 db를 사용하지 않았기 때문에 일반적인 락과는 다르게 접근해야 했으며, 레디스라는 캐시 서버에 특정 조건에 연산이 수행되지 않도록 하는 것이 문제 해결의 열쇠였다. 문제상황 문제 상황을 말하기에 앞서 예약을 하는 흐름은 다음과 같다. 매장을 선택한다. 매장에서 예약가능한 시간과 날짜를 선택한다 해당 날짜의 좌석을 선점한다. 예약 버튼을 누르면 선점한 좌석이 예약이 된다. 이를 코드로 보여주자면 아래와 같다. 문제의 코드 예약할 좌석의 상태를 캐싱해두는 코드 @Service @R.. 이전 1 2 3 4 5 다음
