저번 글에 이어서, 많은 요청이 발생했을때 데이터베이스를 어떻게 설계해야 하는지 알아보도록 하자. 데이터베이스 다중화대부분의 데이터베이스는 다중화 기능을 제공한다. 예를들어 AWS에서는 Read Replica를 통해 Master-Slave 관계를 만들 수 있다. 즉, 같은 데이터베이스를 하나의 Master DB와 여러개의 SlaveDB로 두는 방식으로, 원본이 Master서버에 사본이 Slave서버에 저장된다. 이경우 Master DB에서는 Write(쓰기연산)가 가능하고, Slave DB에서는 Read(읽기연산)만 가능하다. 웹이나 앱등을 구현하다보면, 쓰기/수정/삭제연산과 같이 Write연산보다는 읽기연산인 Read가 훨씬 많이 사용하게 되는것을 알게된다. 사실 당연하다. 뭔가를 수정,삭제하기 위해..

요즘 개발 포스트나 공고등을 보다보면 항상 눈에 보이는 단어가 있다.바로 "대규모 시스템 개발 경험"!비슷한 말로 대규모 트래픽 처리 경험, 대용량 데이터 처리 경험, 확장성있는 구조 등등이 있다. 대체 대규모 시스템이란 얼마나 다른 구조를 갖고 있기에 실무에서 강조 또 강조하는것일까?현재 나는 "빼곡"이라는 서비스를 운영하고 있긴 하지만, 아직 많은 이용자와 트래픽이 있는것은 아니기에 막상 경험해보긴 힘들었다. 따라서 책과 포스팅을 통해 개인적으로 학습해보고, 이를 토대로 아키텍처를 설계해보며 기업들이 강조하는 대해 알아보고, 성장하고자 한다. cf. 주 참고자료는 한 면접을 준비하며 알게된 상 면접 사례로 배우는 대규모 시스템 설계 기초>라는 책이다. 초기 서비스단일서버(클라이언트, 서버, DB)요..

스프링에서 백엔드 Repository를 구현하다보면 사용하는 어노테이션이 있다.바로 @Transactional! AOP를 활용해서 커밋, 롤백 등 트랜잭션을 관리하는 기능이다.만약 해당 repository에서 읽기작업만 수행할 경우, readOnly=true 속성을 사용하기도 한다.@Transactional(readOnly = true) 위 설정을 통해 성능상의 이점을 가져올 수 있다고 하는데, 좀더 구체적으로 어떤 이점이 있는지 공부해보려고 한다. Transcational과 Dirty ChekingTransactional은 begin()부터 commit()작업 전까지 영속성 컨텍스트를 유지한다.또한, 영속성 컨텍스트로 불러온 Entity의 변경사항을 DB에 바로 적용하지 않고, Dirty Chekin..

두번째 리팩토링의 주제는 @Reposiotry 생략했는데 왜 정상작동? 이다. 과거 MyBatis를 활용해서 프로젝트를 진행했던적이 있다. Controller, Service, Repository 등 클래스들은 어노테이션을 통해 꼭 빈으로 등록했었다(당시에 몇번 빼먹었다가 오류가 나서 수정했던 기억이ㅎ) 그런데 프로젝트의 경우, @Repository 어노테이션을 생략해도 정상적으로 동작하는것을 발견했다. 초반에 작성했던 클래스를 제외하고는 대부분 명시하지 않았다. 구현에 급급하다보니 살피지 못했던 부분이다. 다른점이라면 기술스택으로 인한 차이가 있다. JPA를 채택하고있기 때문에 Repository는 모두 JpaRepository를 extends하는 인터페이스 기반의 레포지토리이다. 그렇다면 지금 발..