개발 일지/대규모 시스템 설계8 [대규모 시스템 설계] 6. MSA 분산 트랜잭션 관리 개요 이전에 진행했던 프로젝트는 분산 트랜잭션 처리 로직을 구현하지 않은 아쉬운 MSA 환경을 구축하였다. 각 마이크로 서비스들은 공유 DB를 바라보고 있었으며, 특정 서버가 트랜잭션을 처리하게되면, 단일 DB 환경에서 데이터의 일관성과 안정성을 보장하는 DB에 의존하여 ACID 특성을 보장할 수 있었다. 하지만, 이러한 방식은 왜 우리가 MSA 환경으로 구성했는지 의문을 품을 수도 있는 부분이다. 하나의 공유 DB를 바라보면서 서비스만 나눴다면 차라리 서비스를 나누지 않고 모놀리식 아키텍처로 구성하는 것이 더 낫지 않나 생각이 드는 것이다. 즉, MSA 환경을 구성하려고 했다면 MSA 답게 하나의 DB에 중앙 집중화를 하지 않고 서비스 별 별도의 DB를 사용하여 다른 서비스 컴포넌트에 대한 의존성을 없.. 개발 일지/대규모 시스템 설계 2023. 10. 15. [대규모 시스템 설계] 5. 키-값 저장소 설계 - CAP 정리 이번 포스팅은 키-값 저장소 설계에 관한 주제이다. 자료구조 중 Map이라는 것을 활용을 해봤다면 Key-Value 구조라는 것이 무엇인지 이해가 갈것이다. 보통 키-값 저장소는 키-값 데이터베이스라고도 불리는 비 관계형 데이터베이스이며 memcached나 레디스 같은 것들이 존재한다. 키-값 자료구조 상 키는 유일해야하며 키를 통해서 값에 접근할 수 있다. 키는 일반 텍스트일 수도 있고, 해시 값일 수도 있다. 아무튼 성능상의 이유로 키는 짧을수록 좋다. 단일 서버 키-값 저장소 한 대 서버만 사용하는 키-값 저장소를 설계하는 것은 쉽다. 키-값 쌍 전부를 메모리에 해시 테이블로 저장하여 들고오면 되는 것이다. 하지만, 모든 데이터를 메모리에 두는 것은 불가능하다. 자원은 유한하기때문에 이러한 문제를 .. 개발 일지/대규모 시스템 설계 2023. 8. 7. [대규모 시스템 설계] 4. 안정 해시 설계 수평적 규모 확장성을 달성하기 위해서는 요청 또는 데이터를 서버에 균등하게 나누는 것이 중요하다. 오늘의 포스팅 주제는 안정 해시와 관련된 내용이니 천천히 살펴보도록 하자. 해시 키 재배치 문제 레디스와 같은 N개의 캐시 서버가 있다고 가정하자. 이 서버들에 부하를 균등하게 나누는 보편적 방법은 아래의 해시 함수를 사용하는 것이다. 현재 N은 4라고 가정을 한다. serverIndex = hash(key) % N (N은 서버 개수) 키 해시 해시 % 4 (서버 인덱스) key0 18358617 1 key1 26143584 0 key2 18131146 2 key3 35863496 0 key4 34085809 1 key5 27581703 3 key6 38164978 2 key7 22530351 3 위의 표를.. 개발 일지/대규모 시스템 설계 2023. 7. 24. [대규모 시스템 설계] 3. 분산 시스템을 위한 유일 ID 생성기 설계 프로젝트를 진행해봤다면 DB를 하나 정도는 활용해봤을 것이다. 하지만, 같은 용도로 활용하는 DB 서버를 분산시켜서 트래픽을 분산시키는 작업을 진행하는 것은 실무가 아닌 이상 토이 프로젝트에 적용하는 것은 상당히 힘들 것이라고 생각한다. 'auto_increment' 속성이 설정된 관계형 데이터베이스를 통해 기본 키를 쓴다면 이것은 단일 서버에 한해서다. 분산 환경에서 이 접근법은 통하지 않는다. 분산 환경에서 여러 DB를 구축을 한다면, 어느 DB로 해당 PK 값으로 데이터 정보를 불러올 것인가가 문제다. 기본적으로 데이터베이스 하나를 이용한다면 PK 값으로 해당 데이터베이스에서 Select문을 날리면 된다. 그러나 데이터베이스 서버가 여러개라면 해당 PK값을 가진 데이터가 어느 데이터베이스에 존재하는.. 개발 일지/대규모 시스템 설계 2023. 7. 23. [대규모 시스템 설계] 2. 처리율 제한 장치 필자는 처리율 제한 장치와 관련된 처리를 해본 경험이 없다. 프로젝트를 진행하면서 필수적으로 진행해야하는 것은 API 기능 명세에 작성된 주요 서비스 구현이 1순위이다. 그러다보니 트래픽에 대한 처리는 어느순간 후순위로 밀려나게 되었다. 하지만 이전 포스팅에서 언급한 것처럼 '성능 개선', '트래픽 처리' 등 개발자 관점에서 도전적으로 프로젝트에 접근하는 것을 권장한다. 물론, 하다보면 필자처럼 시간에 쫓겨 흐지부지될 때가 많지만 시간이 넉넉한 프로젝트를 한다면 새로운 기술에 접근해보자. 이번 장에서는 클라이언트와 웹 서버 사이에 로드밸런서가 아닌 또 다른 친구가 존재하는데 그 친구를 한 번 포스팅하고자 한다. 처리율 제한 장치가 무엇인가 네트워크 시스템에서 처리율 제한 장치는 클라이언트 또는 서비스가 .. 개발 일지/대규모 시스템 설계 2023. 7. 21. [대규모 시스템 설계] 1-3. 아키텍처 설계 무상태 (stateless) 웹 계층 오늘의 포스팅은 무상태 (stateless) 웹 계층을 시작으로 천천히 알아보자. 이전 포스팅에서 생각보다 많은 것을 배워봤다. CDN을 통해 정적 컨텐츠를 캐시하고 로드밸런서를 통해 웹 서버의 분산, 데이터베이스의 다중화 및 캐시 활용 등을 배웠다. 이제 웹 계층을 수평적으로 확장하는 방법을 배워볼 순서인데, 사용자 세션 데이터와 같은 상태정보를 웹 계층에서 제거해야한다. 예를들면, 상태 정보를 관계형 데이터베이스나 NoSQL 같은 지속성 저장소에 보관하여 필요시 가져오게 하는 방법으로 말이다. 이렇게 상태정보를 웹 계층에서 제거하여 설계한 웹 계층을 무상태 웹 계층이라고 부른다. 1. 상태 정보 의존적인 아키텍처 무상태 웹 계층을 배우기전에 상태를 저장하는 웹 계.. 개발 일지/대규모 시스템 설계 2023. 7. 21. [대규모 시스템 설계] 1-2. 아키텍처 설계 데이터베이스 다중화 대규모 시스템 설계에 있어서 가장 중요한 것 중 하나는 데이터를 어떻게 보관을 하냐이다. 보통은 서버 사이에 주(master) - 부(slave) 관계를 설정하고 데이터 원본은 주서버에, 사본은 부 서버에 저장하는 방식이다. 쉽게 말하면, 나루토를 보신 분들은 아시겠지만 나루토가 주(master)이고 그림자 분신술을 써서 만들어진 복제본들이 부(slave)인 것이다. 쓰기 연산(write)은 주(mastser)에서만 지원을 하고 부(slave)에서는 master에서 사본을 전달받아 읽기 연산만을 지원한다. 필자가 프로젝트를 진행하면서 학습했던 내용은 데이터베이스에 데이터를 변경하고 삽입하는 연산보다는 읽기 연산의 비중이 훨씬 높다는 얘기들 들었다. 해당 포스팅을 보는 여러분들도 벌써 .. 개발 일지/대규모 시스템 설계 2023. 7. 20. [대규모 시스템 설계] 1-1. 아키텍처 설계 지금까지 여러 프로젝트를 진행해왔지만 서비스를 더 키우거나 많은 사용자들의 유입이 들어왔던 경험은 없었다. 사실, 실무에서의 개발 경험이 없었기 때문에 위의 사례는 극히 드물다고 생각한다. 특히, "서비스를 런칭해야지!" 라는 거대한 포부를 가지고 개인, 팀 프로젝트를 진행을 해본 분들이 계시다면 팀 동료를 제외한 실사용자 100명을 채우는 것은 상당히 힘든일이라는 것을 공감할 것이다. 즉, 트래픽을 처리하기 위한 대규모 시스템 설계는 실무 경험이 없는 신입 개발자들이 경험하기는 힘들다는 것이다. 그러면 어떻게 해야하는가? 개인적으로 학습이 필요하고 그 학습을 토대로 아키텍처를 구상해야한다고 생각한다. 최근 1년간 싸피 교육으로 개인 공부를 소홀히 하였기에 다시 포스팅을 꾸준히 시작해보려고 한다. 이번 .. 개발 일지/대규모 시스템 설계 2023. 7. 17. 이전 1 다음 반응형
