ecsimsw

Vultr의 Object storagePicUp 은 사진 업로드하고 다운로드 할 수 있다. 사용자의 사진 스토리지에 문제가 생길 상황을 대비하여 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 로 승격시키는 방식 등 여러 정책을 고민했다. 그중에서도 아..

이전 글 - 리버스 프록시 개념과 Nginx, ELB 로 로드밸런싱 실습리버스 프록시 개념이 처음이거나 Nginx config 를 처음 다뤄본다면 이전 글을 먼저 보고 오는 것을 추천한다. 해당 글에선 리버스 프록시와 로드 밸런싱 개념, 다중 WAS에서 Sesstion 관리, Nginx 와 AWS ALB로 로드밸런싱 실습을 다뤘다.Rate limit, Ip white list프로젝트를 배포할 때마다 무서운 것들이 있다. 악의적인 과도한 요청, 접속해선 안될 곳에 접근이 가능, 암호화되지 않은 데이터... 특히 가장 먼저 서버를 보여주는 주변 사람들이 웹 개발자가 많아서 더 무섭다. 이 사람들은 일반 사용자랑 달리 아주 자연스럽게 서버를 테스트할 테니 말이다. 그리고 실제로 꼼꼼하게 방어하지 않았다..

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 를 띄워 단순 복제하는 것이다. 여러 소스로부터 복제한다고 해서 이를 ..

Mysql db replication PicUp 프로젝트에서 DB를 백업하기 위해서 replication 을 사용한다. 당장은 백업을 위함이 가장 컸지만 replication 도입으로 쿼리 부하 분산, 지역화의 이점도 얻을 수 있을 것이다. 이 글에선 아래 네가지 키워드를 다룬다. - Mysql이 제공하는 Replication 방식과 각 장단점 - 이 프로젝트에서 비동기 복제 방식을 사용한 이유와 정합성 문제 고민 - Mysql 에서 비동기 Statement Based Replication 설정 방법 - Spring 에서 여러 DB source를 정의하고 transaction readOnly 옵션으로 target source 를 분기할 수 있는 설정 Replication 종류 Mysql 의 복제 방식은 ..