
기존 상황 및 문제 정의기존 인프라 비용이 달마다 30만원 이상이 소요되고 있었으며, 딱히 트래픽을 받지 않는 상황에서 과하게 인프라 자원을 사용 중이었다.(ecs-fargate 를 과하게 사용하고 있었다.)이러한 인프라 구성을 개편하여 비용을 줄이고 우리가 예상하는 운영 시 트래픽에 맞게 사용하고 싶었다.이를 위해 작업한 내용을 공유하고자 한다. 다음과 같은 예상되는 초기 유저 수를 고려하고 있으며, 인스턴스의 크기와 개수는 경험을 토대로 프리티어 인스턴스로 충분할 것으로 예상하여 프리티어를 초기 테스트용 인스턴스로 설정했다.예상 유저 수: 100명원하는 처리량: 50 ~ 100tps사용 중인 인스턴스: aws t2.micro (프리티어)메모리: 1GB + swap memory 2GBvCPU: 1 성..

* 2024.08.03 까지의 프로젝트만을 대상으로 하는 글이다. 깃허브에 들어가보니 나도 모르는 사이 내가 만든 Repository가 3자릿수가 되었다는 사실을 알게 되었다.그 동안 내가 참여한 프로젝트만 fork 하였고, 의미 없이 아무 Repository나 fork 하며 Repository 수를 늘리지 않았다.직접 개발한 Repository만 남겨놓으려 했었기에 의미있다 생각하고, 기념으로 그 동안 개발 활동을 정리 해보고자 한다. 프로젝트가 좀 많은데, 몇몇 팀 프로젝트는 9개월 이상 진행했던 만큼 프로젝트 양에 집중한게 아님을 먼저 밝힌다.개발자로서 가져야 할 개발적인 고민이 더 중요하다 생각해서 항상 양보다 질에 집중하고 있다.적극적으로 개발 경험을 쌓을 기회마다 참여하여 다양하게 경험할 수 ..
아모르각코 프로젝트에 코드 리뷰어로서 참여하고 있으며, 요청을 받아 시스템 설계를 돕기로 했다.백엔드 개발자 분과 함께 고민하며 알림 시스템을 설계한 과정을 소개해보고자 한다.참고로 서비스에서 알림은 총 6가지 케이스에 발송되며 주변 모각코 생성시 알림, 모각코 참여 수락 알림 등이다. 흐름은 다음과 같다:1. 요구사항 파악2. 고려할 케이스 파악3. 기술 선택4. 데이터 흐름 설계5. 전체 아키텍처 1. 요구사항 파악지원하는 알림 종류(email, sms, app push 등) 및 지원하는 기기 종류서비스 상에서 알림 전송SMS 알림, 푸시 알림현재 클라이언트는 웹 브라우저만 지원실시간성의 수준무조건 실시간은 아니어도 되지만, 가능하면 빠르게 전송알림이 어떤 경우에 발송되는가클라이언트의 API 호출시 ..

이길저길의 실시간 양방향 위치 공유 시스템 설계 과정에 수행한 성능테스트 결과를 공유하고자 한다.성능테스트 결과 뿐만 아니라 이전 글의 분석까지 종합하여 기술을 선정하였다. 시스템의 요구사항은 간략하게 다음과 같다:각 클라이언트는 연결이 된 시점부터 3초에 한 번 자신의 위치를 공유한다.위치 공유 대상은 사용자가 생성한 그룹의 그룹원들이며, 설계 단계의 예상 평균 그룹 인원수는 4명이다. 실시간 통신 기술들을 성능테스트 사전에 비교했던 흐름은 다음과 같다:SSE vs Short PollingSSE로 구현시 API를 총 2개를 구현하여 사용해야한다.SSE 커넥션 API자신의 위치를 전송하여 그룹원들에게 알리는 API Short Polling 에 비해 커넥션을 하나 더 가지고 있게 되어 SSE는 비효율적..

지금까지 성능테스트를 위해 써본 툴을 비교해보고자 합니다. 오픈소스이며 자유도가 높은 툴을 사용하고자 하다 보니 3가지 툴을 사용해보았습니다.각각의 "스크립트 작성 방법", "gui 확인 방법"은 다음과 같습니다. locust스크립트 작성 방법: Pythongui 확인 방법: 명령어 실행시 실시간으로 확인할 수 있는 간단한 서버가 실행되어 브라우저로 접속하면 된다.k6스크립트 작성 방법: Javascriptgui 확인 방법: influxdb와 grafana를 연결하여 grafana에 제공되는 대시보드를 import하여 확인한다.다른 방법이 있는지는 모르겠으며, docker를 사용하여 간단히 grafana, influxdb를 사용했었다.artillery스크립트 작성 방법: yamlgui 확인 방법: 모두 ..
Redis에서 키를 관리하는 법자료구조를 가리키는 key를 의미innerkey가 아님키의 자동 생성과 삭제자동 생성키가 존재하지 않을때 아이템을 넣으면 자동으로 빈 자료구조 생성하여 넣음키 작업을 따로 하지 않아도 자동으로 명시한 키 값으로 자료구조 생성대신, 같은 키로 다른 자료구조가 있다면 에러 반환자동 삭제stream을 제외한 모든 자료구조는 모든 아이템이 삭제되면 자동으로 키도 삭제됨키와 관련된 커맨드EXISTS key keynamekeyname에 해당하는 키 있는지 확인존재하면 1, 없으면 0KEYS pattern h*llo저장된 키를 패턴에 맞게 조회하며, 위 예시의 h*llo 의 경우 * 자리에 아무것도 없거나 어떤것이 와도 패턴이 맞는 키를 모두 조회패턴은 글롭패턴을 따른다KEYS모든 키를..

string [”key” → “value”]특징키와 실제 데이터가 1:1 로 연결되는 유일한 자료구조value에 저장 가능한 데이터최대 512MB의 문자열 데이터 저장 가능binary-safe 하기에 JPEG 이미지, 바이트 값, HTTP 응답값 등 또한 저장 가능숫자 또한 저장 가능INCR(1 증가), INCRBY(지정하는 숫자만큼 덧셈 가능)비슷한 원리로 DECR, DECRBY 도 가능숫자를 원자적으로 조작 가능 → 여러 클라이언트가 경쟁 상태를 발생시키지 않음 (중복 처리 없음)기본 사용SET k v → O(1)k 라는 key에 v 라는 value 저장GET k -> O(1)k 라는 key에 해당하는 value 가져옴숫자의 경우INCR k , DECR kINCRBY k 30 , DECRBY k 30..

soft-delete-hibernatehibernate가 제공하는 @SoftDelete 어노테이션을 알아보자[hibernate 6.4.4 버전 기준으로 MySQL과 함께 테스트 했으며 6.4 버전부터 도입된 어노테이션이다.]@SoftDelete JavaDoc다음 어노테이션을 테스트디폴트로 boolean 타입의 deleted 필드가 추가되며, Entity 내부에 자바코드로 동일한 이름의 필드를 사용할 수 없다.중복 필드 에러가 발생한다.즉, deleted 필드는 자바 코드로 접근 불가하다.필드명은 커스텀하게 설정 가능하며, boolean 타입이 싫은 경우 converter를 사용할 수도 있다. (후술 예정)JpaRepository.deleteAll() 호출시deleted = true 로 update 된다...