목록전체 글 (316)
ecsimsw
Vultr의 Object storage PicUp 은 사진 업로드하고 다운로드 할 수 있다. 사용자의 사진 스토리지에 문제가 생길 상황을 대비하여 Object storage를 추가하고 백업 스토리지로 사용하기로 하였다. AWS S3 에서 벗어나 Object storage 선택지를 늘려보고 싶어서 여러 선택지를 확인했고, Vultr 라는 회사의 Object storage 를 사용하기로 했다. 이 글에서는 Vultr 의 Object storage 를 선택한 이유와 간단한 사용 방법, 추천 대상을 소개한다. 1. 저렴한 비용 익숙한 AWS가 아니라 Vultr 의 Object storage를 이용한건 비용의 문제가 가장 컸다. 사용되는 storage와 bandwith를 동일하게 1TB 라고 했을 때 AWS는 2..
만약 DB 서버가 다운된다면? 이전 글 에서 DB 데이터 백업과 부하분산을 목적으로 DB replication 을 적용하고 Transactional readOnly 여부에 따라 DataSource 를 분기했다. 이 글에선 Master, Replica 중 하나라도 Connection 에 문제가 생기는 상황을 고민한다. DB 서버를 단순히 쿼리가 readOnly 인지 여부만으로 분기한다면 둘 중 하나라도 문제가 생길 경우 서비스의 읽기가 안되거나 쓰기가 안 되는 심각한 문제가 발생할 것이다. 다른 Stand by Master node 를 만들어두고 Master 가 다운 되었을 때 교체하는 방식, Master 가 죽었을 때 Slave 를 Master 로 승격시키는 방식 등 여러 정책을 고민했다. 그중에서도 아..
GC와 Stop the world JVM의 가비지컬렉터는 힙 영역의 메모리에서 더 이상 사용되지 않는 자원을 정리하는 역할을 한다. 이때 사용되지 않는다란 다른 지역 변수, static 변수, 파라미터, JNI의 객체, 다른 힙 영역의 객체 등에서 더 이상 참조되지 않는 것을 말한다. 아래 그림에서 빨간색으로 표시된 Unreachable objects는 GC의 대상이 된다. 이때 자원을 정리하는 과정에서 새로운 객체가 할당되거나 객체 간 연결이 생길 경우를 방지하기 위해, GC를 위한 스레드를 제외한 모든 스레드의 작업이 중단된다. 이런 GC를 위한 애플리케이션 전체 중단 시간을 Stop the world라고 한다. ( 보다 자세한 STW가 필요한 이유 ) 두가지 GC와 처리 영역들 Stop the wo..
0. AS IS 기존에는 이 메인 / 백업 스토리지 업로드를 동기로 처리했다. 400KB의 이미지를 업로드할 때 main 33ms, backup 1680ms 정도가 필요했고, 사용자 응답은 이 둘을 더한 값 + ⍺ 가 될 것이다. 이미지 업로드 시에 각 스토리지 업로드를 비동기로 처리하되 모든 업로드가 정상일 경우에만 사용자에게 정상으로 응답하고자 한다. 그리고 동시에 비동기식 업로드 과정에서 생길 수 있는 더미 파일을 사용자 흐름에 포함하지 않고 처리하고자 한다. 이 글에선 위 요구 사항을 만족하기 위한 작업 과정을 소개한다. 목차는 다음과 같다. 1. 단순 비동기 처리 2. Future로 비동기 / 블록킹 방식으로 처리하는 경우, 그 문제점 3. CompletableFuture으로 쉽게 구현하는 다양..
캐시로 조회 성능 개선 Pic-up 은 앨범 기반 사진 스토리지이다. Picup 은 페이지네이션이 적용되어 있고, 서비스 특성상 사용자는 앨범을 조회 시 항상 첫 페이지의 사진들부터 확인한다. 전체 앨범 조회에도 마찬가지다. 사용자의 앨범 목록을 조회할 때도 항상 첫 페이지의 사진들부터 조회한다. 그리고 그 앨범, 사진들은 수정될 여지가 적다. 일반 게시물과는 다르게 사진을 앨범으로 한번 만들어두면 그 이후로는 사진을 삭제하거나 수정하는 요청보다는 단순 조회가 다수일 것이다. 그래서 조회 성능을 개선하고 DB에 접근하는 네트워크 비용을 아끼고자 캐시를 도입하게 되었다. 이 글에선 어떤 전략으로 캐시를 사용했고, Spring 에서의 설정 방법을 소개한다. 어떤 캐시를 사용할까 1 : 지역 캐시와 전역 캐시..
Mysql DB Multi source replication 지난 글에선 데이터 백업, 쿼리 분산을 위한 Mysql replication 을 소개했다. DB 서버 하나에 데이터를 넣어두는 것이 위험하다고 생각해 복제용 DB를 만들어 데이터를 백업했고, 이를 읽기 전용 서버로 생각하여 백업과 부하 분산 두 가지를 잡을 수 있었다. 이번엔 새로운 니즈가 생겼다. 지금 프로젝트 배포를 개인 홈 서버에 하고 있는데 물리적인 문제가 생겨 데이터가 날아가면 어쩌지 하는 생각이다. (혹시 불이라도 나거나 SSD가 고장나면 어째..) 원하는 구조는 아래와 같다. Api 서버별로 다른 DB 서버로부터 Cloud server 에 하나의 Mysql DB 를 띄워 단순 복제하는 것이다. 여러 소스로부터 복제한다고 해서 이를 ..
0. 메시지 큐 사용 이유와 전략, 재앙 시나리오 소개 Picup 프로젝트에선 메시지 큐로 RabbitMQ 를 사용한다. 이 글에서는 Message queue 를 사용하게 된 이유부터 Rabbit mq의 주요 설정 옵션들 그리고 프로젝트 내에서 MQ 사용 시나리오를 소개하려 한다. 1. Message queue 도입 배경 2. Rabbit MQ 의 주요 옵션, Dead letter 3. 프로젝트에서의 사용 시나리오 / 재앙 시나리오 1. Message queue 도입 배경 Picup 에서는 사진 파일을 한 번에 많은 양 삭제할 수 있어야 한다. 사용자가 앨범 삭제를 요청하면 서버에선 앨범 내에 들어있는 관련 사진들을 삭제해야 한다. 이때 사용자가 그 파일들이 실제로 삭제 처리 될 때까지 그 시간을 기다릴..
커서 기반 페이지네이션으로 전환 PicUp 프로젝트는 앨범 기반의 사진 클라우드 스토리지 서비스이다. 프로젝트에서 기존 Offset 기반의 페이지네이션에서 Cursor 기반의 페이지 네이션으로 방식을 변경하는 과정을 정리하려고 한다. 이 글에선 세가지 키워드를 다룬다. - Offset based 의 성능 문제 - 100 만개 더미 데이터 생성 / LOAD DATA INFILE 방식 업로드 - 쿼리 테스트 결과 Offset based vs Cursor based Offset 기반 페이지네이션에는 유명한 2가지 문제가 있다. 데이터 중복 / 누락 조회 문제, 퍼포먼스 문제. 데이터 중복 / 누락 문제는 일상에서 만나기 쉬워 예상하기 쉬울 것 같다. 3 페이지를 보던 와중에 다른 글이 많이 추가되면 4 페이지..