현재 업무에서 사용하는 라이브러리 중, 몇몇 라이브러리는 도메인에 맞도록 혹은 성능 개선을 위해 커스텀해서 사용중인데요.이러한 모듈이 점차 많아지면서 전체 node_modules를 관리하기가 어려워졌습니다. 이 문제를 해결하기 위해 아래와 같은 방법들을 고려해 보았습

요즘 회사 업무중 하나로, 기존에 사용하던 객체 저장소를 새로운 플랫폼의 저장소로 이전하는 작업을 하고있는데요.이번 기회에 얼마전에 책너두를 진행하며 읽었던 가상 면접 사례로 배우는 대규모 시스템 설계 기초 2를 복습하며, 정리한 내용을 다시 한 번 곱씹어보고자 합니다

안녕하세요! 오늘은 메시지 큐에 대해 알아보고자 합니다.최근 많은 기업들, 혹은 프로젝트들이 MSA를 도입하고 있고, 이로인해 메시지 큐의 사용을 피할 수 없는 상황이 많아지고 있는데요. 이번 포스팅에서는 메시지 큐의 개념과, 이를 사용함에 있어 가장 많은 문제(?)

객체 버전은 버킷 안에 한 객체의 여러 버전을 보관하는 기능이다.이를 통해 이전 객체의 복구 등의 작업이 가능해진다.클라이언트가 HTTP로 PUT 요청을 보낸다.API 서비스는 IAM 서비스로부터 사용자의 신원과 권한을 확인한다.확인결과 이상이 없다면 데이터를 저장소로

메타데이터를 통해 아래와 같은 질의를 지원해야 한다.객체 이름으로 객체 ID 찾기객체 이름을 기반으로 삽입, 또는 삭제 처리같은 접두어를 갖는 버킷 내의 모든 객체 찾기이러한 요구사항을 만족하기 위한 메타데이터 테이블 구조는 다음과 같다:버킷 테이블의 규모 산정고객은

데이터 내구성은 저장 시스템에 있어 핵심적인 요소이다.아무리 뛰어난 설계를 가진 소프트웨어 제품이라도, 하드웨어 장애는 피할 수 없다.일반적으로 하드 디스크의 연간 장애율은 0.81%라고 한다. - 출처이를 기반으로 6 nines(99.9999%)의 내구성을 만족하기

주요 주제데이터 저장소메타데이터 데이터 모델버킷 내의 객체 목록 확인객체 버전큰 파일의 업로드 성능 최적화쓰레기 수집(garbage collection)데이터 저장소는 실제 바이너리 데이터를 저장하는 곳임.API 서비스와 연계하여 객체 업로드/다운로드 요청을 처리한다.

알아두어야 할 객체 저장소의 특성객체 불변성(object immutability): 객체 저장소에 저장된 객체는 수정할 수 없다.오로지 완전한 대체만 가능하다.키-값 저장소(key-value store): 객체가 저장될 때 특정 URI를 부여한다.저장은 1회, 읽기는

오늘은 개발과는 다소 관련없는 글을 들고 왔습니다.정말 오래전부터 노트(바인더)를 쓰는 것을 좋아했는데요, 개발자가 된 뒤로는 아날로그 노트를 거의 쓰지 않게 되어 아쉽기도 합니다.그래도 최근에 다시 아이패드로 예전 다이어리를 마이그레이션 하면서, 예전에 정리했던 글귀

저장소 시스템의 종류는 아래와 같은 세 가지 종류가 있다.블록(block) 저장소파일(file) 저장소객체(object) 저장소블록 저장소는 특정 서버에 원시 블록(raw block)을 직접 제공한다.가장 유연하고 융통성이 높다. 또한 성능도 가장 우수하다.그말인 즉슨

연구에 따르면, 50% 이상의 메일은 스팸으로 처리된다.우리의 메일 시스템이 스팸 처리를 피하기 위해서는 아래와 같은 조치가 필요하다.이메일 전송시에는 전용 IP를 사용해야한다.새로운 IP에서 발송되는 메일은 스팸 처리될 가능성이 높다.따라서 충분한 기간 좋은 평판(r

이메일의 헤더는 일반적으로 매우 작으며, 빈번하게 사용된다.이메일의 본문은 크기가 클 수 있고, 사용 빈도는 낮다이메일의 특성상, 사용자별 격리가 필수적이다.다른 사용자의 메일을 볼 수 없고, 보여서도 안된다.데이터의 신선도가 사용 빈도에 영향을 끼친다.주로 관계형 데

POST /v1/messages GET /v1/folders { "id": "1", "name": "Inbox", "user_id": "123", } GET /v1/folders/{:folderID}/messages GET /v1/message

주요 기능이메일 발송/수신모든 이메일 가져오기읽음 여부에 따른 필터링제목, 발신인, 메일 내용에 따른 검색 기능스팸 및 바이러스 방지 기능HTTP 사용첨부파일 지원안정성: 메일이 소실되어서는 안된다.가용성: 이메일과 사용자 데이터를 여러 노드에 복제하여 부분 장애에도

일반적으로 개별 호텔의 객실 예약시스템의 부하는 높지 않다.하지만 만약 booking.com이나 expedia.com과 같은 대형 플랫폼과 연동이 필요하다면 확장이 필요하다.샤딩을 할 때 가장 중요한것은 테이블을 어떻게 분할할 것인가이다.이 케이스에서는 hotel_id

비관적 동시성 제어방안사용자가 업데이트를 시도하는 순간 락을 걸어 다른 사용자가 업데이트를 시도하지 못하도록 한다.다른 사용자는 현재 사용자가 업데이트를 완료할 때까지 대기해야 한다.장단점장점모든 갱신을 직렬화하여 충돌을 막을 수 있다.데이터 경합이 심할 때에도 무결성

아래와 같은 이중 예약을 방지해야한다.한명의 사용자가 예약 버튼을 두 번 이상 누르는 경우두 명의 사용자가 동시에 같은 객실을 예약하는 경우클라이언트측 구현사용자가 예약 버튼을 누르면 버튼을 비활성화하고, 예약 요청을 보낸다.간단하지만 우회가 가능하므로 완전한 해결책이

앞서, room_id의 존재에 문제가 있었다.이를 해결하기 위해 room_type_id를 사용하여 예약 요청을 수정한다.이에따라 예약의 스키마는 아래와 같이 변경된다.또한, 이렇게되면 객실을 직접 예약하는것이 아니므로, 이를 매핑하는 테이블을 추가해야 한다.이를 위해

이 중 신규 예약시 사용할 인자의 형태는 아래와 같다.여기서 reservationID는 멱등키(idempotent key)이다.이는 중복 예약을 방지하기 위해 사용된다.이 시스템에서는 읽기 빈도가 쓰기에 비해 높다.또한 예약 시스템에는 ACID 속성이 매우 중요하다.따

집계결과는 RTB(Real-Time Bidding) 시스템에 전달되므로, 이를 정확하게 유지하는것이 중요하다.지연시간: 시스템의 주요 부분마다 타임스탬프를 기록하여 지연시간을 측정한다.메시지 큐 크기: 큐의 크기가 갑자기 증가하는 경우 집계 서비스 노드를 추가해야 한다