
저장소 관리 전략의 필요성 프로젝트 초기에는 모노리딕 시스템으로 서비스를 구현하게 된다. 다만 프로젝트가 거대화되면서 모노리딕 시스템은 높은 결합도와 낮은 응집력을 가지고 있기에 이를 해결하기 위해서 개발 조직은 시스템의 각 부분을 도메인 별로 분리해서 마이크로 서비스로 구성하기 시작하게되며 이때 개발 조직은 쪼개진 각 서비스를 하나의 리포지토리에서 관리할지, 각자 다른 리포지토리에서 관리할지 고민하게 된다. 모노리포, 멀티리포 저장소 관리 방식은 프로젝트의 규모, 개발 환경, 팀 구성 등 다양한 요소에 따라 선택되며, 이 중에서 가장 일반적인 방식으로는 모노레포와 멀티레포가 있다. 리포지토리를 관리하는 방법은 시스템의 각 모듈을 개별 리포지토리에서 관리할 것인지, 하나의 리포지토리에서 관리할 것인지에 ..
회원 테이블의 특징 및 설계 결정 요소 거의 모든 서비스에서 참조하는 테이블이기에 READ 작업이 많아 불필요한 컬럼의 읽기가 일어나면 좋지 않을 수 있다.그렇기에 1:1 매칭되는 컬럼이 있더라도, 정규화를 해서 분리하는 것이 좋다고 판단했다.기본 테이블 구성에는 회원 정보, 회원 인증 정보등이 필요하지만 좀 더 나은 회원 데이터 관리를 위해서 필요한 정보들은 로그 데이터 및 휴면 계정 데이터 등이 있다.테이블 구성회원 정보회원 인증로그스키마 단위로 나누면 보안 그룹 설정 관리와 MSA 적인 측면을 고려할 수 있다. 회원 인증 정보를 따로 두는 이유는 최근에는 엄청 다양한 로그인 방식이 있기 때문에 따로 둬서 관리하는 방법이 더 효율적이라고 생각했다. 아래는 각 스키마 별 구성이다.회원 (MEMBER)m..
비즈니스 타입과 환경 (Business Type and Environment) 상품의 개수 - 상품 데이터가 많음. 상품의 다양성 - 데이터 카테고리를 잘 설계해야한다. 통제 - 일관된 포맷의 상품의 정보를 셀러에 요구하거나 생성해야한다. 판매자의 정보 관리, 지표화 - policy, margin, quantity, quality 즉각적 - 검색을 위한 키워드 완성, 추천 기능 필요 로그 데이터가 엄청 많음 - 판매, 회원 가입, 탈퇴, 배송 로그 데이터 관리 필요 파레토 vs 롱테일 - 일반적으로 작은 수요에도 적극적으로 대응할 수 있는 e-commerce에서는 롱테일 법칙 적용 (검색, 추천의 알고리즘을 적극적으로 활용) 같은 데이터를 다른 용도로 많이 씀 - 데이터 중복이 많고 이동이 많기에 수익 ..
- Total
- Today
- Yesterday
- 분산 처리
- 모노레포
- 디스코드 봇
- 회원 테이블
- Hypernetwork
- Spring cloud
- Textual Inversion
- 소프트웨어 방법론
- tauri
- vae
- load balancing
- 멀티레포
- 토이 프로젝트
- Embedding
- MLOps
- Polyrepo
- 형상 관리
- Spring Security
- oauth2
- spring boot
- stable diffusion
- Microservice
- monorepo
- Multirepo
- 로드밸런서
- discord bot
- springboot
- load balance
- Kubernetes
- spring cloud config
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | ||
6 | 7 | 8 | 9 | 10 | 11 | 12 |
13 | 14 | 15 | 16 | 17 | 18 | 19 |
20 | 21 | 22 | 23 | 24 | 25 | 26 |
27 | 28 | 29 | 30 |