| 📢 notice. K-DEVCON Daejeon 브랜치는 대전, 세종을 중심으로 운영 중인 개발자 커뮤니티이며 온라인으로 IT 지식과 개발에 관련된 토론을 나누고, 오프라인 정기 스터디 모임(격주 토요일, 유료)이 진행되고 있습니다. IT업계에 종사하고 있거나 IT를 공부하고 있다면 누구나 함께할 수 있습니다. 자세한 내용은 아래 링크를 참고해 주세요. l K-DEVCON : https://k-devcon.com/pages/K-DEVCON-Daejeon l K-DEVCON Daejeon 정기 스터디 모임 신청 문의 : https://forms.gle/dF6rR6oF4QE68LDq6 |
안녕하세요? 새 학기가 시작되는 3월입니다 😊
무탈한 시작되셨나요? 아직 날이 아직 쌀쌀하네요. 감기 조심하시길 바랍니다.
3월 9일 토요일 낮에 K-DEVCON Daejeon 브랜치에서 데이터 중심 애플리케이션 설계 책으로 스터디가 진행되었습니다.
따끈따끈한 후기를 기록합니다.
일정
l 2024.03.09 14:00-18:00 (4h)
l 대전 궁동 더포럼
참여자 수
l 9명
스터디 진행 내용
l 데이터 중심 애플리케이션 설계 Part 1 - 05. Replication: 황 OO
l 경제에 대한 토론
k-devcon 대전 정기 스터디
05장 Replication(복제)
복제란 네트워크로 연결된 여러 장비에 동일한 데이터의 복사본을 유지한다는 의미입니다. 데이터 복제가 필요한 이유는 무엇일까요?
첫 번째 이유로는 지리적으로 인한 지연 시간을 줄일 수 있습니다. 예를 들어 넷플릭스 콘텐츠를 전 세계로 복제를 해둠으로써 지리적으로 지연 시간을 줄일 수 있게 됩니다.
두 번째로는 시스템의 일부에 장애가 발생해도 지속적으로 동작할 수 있도록 가용성을 높일 수 있습니다. 또 읽기 처리량을 늘릴 수 있습니다. 읽기 질의를 제공하는 장비의 수 자체를 확장하는 것으로, 여러 복제 데이터를 둠으로써 부하를 분산할 수 있게 됩니다.
데이터 쓰기를 진행할 때 복제는 어떻게 이루어질까요?
먼저 복제 서버 중 하나를 리더로 지정합니다. 그리고 다른 복제 서버는 팔로워입니다.
클라이언트가 데이터베이스에 쓰기를 진행할 때 클라이언트는 요청을 리더에게 보내야 합니다. 리더는 먼저 로컬 저장소에 새로운 데이터를 기록하고, 다른 복제 서버에 복제를 진행하게 됩니다.
팔로워에 데이터를 어떻게 보낼까요?
리더가 로컬 저장소에 새로운 데이터를 기록할 때마다 데이터 변경을 복제 로그나 변경 스트림의 일부로 팔로워에게 전송하게 됩니다.
각 팔로워는 리더로부터 로그를 받으면 리더가 처리한 것과 동일한 순서로 모든 쓰기를 적용해 그에 맞게 데이터베이스의 로컬 복사를 갱신하게 됩니다.
복제에서 모든 어려움은 이러한 쓰기에 해당하는 복제된 데이터의 변경 처리에 있으며, 이것이 이번 5장의 내용입니다.
데이터 복제 알고리즘은 크게 Single-leader , Multi-leader, leaderless로 구분할 수 있습니다.
먼저 Single-leader를 살펴보겠습니다. 하나의 리더에 여러 명의 팔로워를 가집니다.
복제하는 방식에는 동기식 방법과 비동기식 방법이 있습니다.
동기식의 경우 리더는 팔로워가 쓰기를 수신했는지 확인해 줄 때까지 기다립니다.(sync) 확인이 끝나면 사용자에게 성공을 보고하고 다른 클라이언트에게 해당 쓰기를 보여주게 됩니다. 동기식의 경우 데이터가 유실되지 않지만 속도가 느립니다. 팔로워 수는 1개가 아닐 수 있고 수십-수백 개가 되는 팔로워 모두가 완료되기를 기다리는 것은 어렵기 때문입니다.
비동기식의 경우 리더는 변경 사항 메세지를 전송하지만 팔로워의 응답을 기다리지 않습니다.(async)
속도가 빠른 대신에 데이터가 유실될 수 있습니다. 보통 복제는 매우 빠르게 진행되지만, 변경 내용을 적용하기에 얼마나 오래 걸릴지는 보장할 수 없습니다. 팔로워가 수분 이상 리더와 떨어질 수 있고 팔로워가 장애를 복구 중이거나 시스템이 최대 가용량 부근에서 동작하거나 노드 간 네트워크 문제가 있을 수 있기 때문이죠
현실적으로 데이터베이스에서 동시식 복제를 사용하려면 보통 팔로워 하나는 동기식으로 하고, 그 밖에는 비동식으로 하는 것을 의미합니다.
Multi-leader의 경우는 리더가 여러명인 방식을 뜻합니다.
다중 데이터센터를 운영하거나 오프라인 작업을 하는 클라이언트, 협업 편집(클라우드 서버에서 저장한 채로 협업으로 편집을 할 때) Multi-leader 방식을 사용하곤 하지만, 다중 쓰기에서 문제가 발생하게 됩니다. 이론은 있지만 실무에서는 잘 사용하지 않으며, 다중 쓰기를 하지 않고 단일 쓰기로 자주 사용됩니다. 즉 멀티 리더는 구성하지만, 멀티 write의 구성은 복잡도가 증가하기 때문에 잘 구성하지 않습니다.
leaderless의 경우 전체가 리더이거나 전체가 팔로워인 경우를 leaderless라고 합니다.
초기 복제 데이터 시스템은 대부분 리더가 없었다고 합니다. 이 개념은 관계형 데이터베이스가 우세한 시대에는 대부분 잊혔다고 하며, 리더 없는 복제는 아마존이 내부 다이나모 시스템에서 사용한 후 다시 데이터베이스용 아키텍처로 유행했다고 합니다.
이미지와 함께 복제 알고리즘 3가지를 함께 살펴보았습니다.
리더가 장애인 경우는 어떻게 알 수 있을까요? 보통 시간으로 측정한다고 합니다. 여러 번의 요청을 시도하고, 요청에 대한 응답이 없을 경우 리더에 장애가 있다고 판단하곤 하며 이는 관리자에 의해 미리 설정되게 됩니다. Failover는 DB에서 변경하게 되며, 롤 체인지가 일어나게 됩니다. 보통 다음 리더 후보에 대한 설정을 미리 정의해 두게 된다고 합니다.
그리고 복제 시 일어날 수 있는 여러 이상 현상들을 살펴보았습니다.
사용자가 서버에 접근을 할 때 특정한 데이터베이스를 접근하도록 정하지 않은 이상 어떤 데이터 베이스에 접근할 지 알 수 없습니다.
사용자가 쓰기를 시도하고(리더), 복제 지연으로 인해 팔로워1에게 복제가 진행되지 않은 상태에서 사용자가 팔로워 1에게 접근하게 되면 쓴 내용을 읽어올 수 없는 상태가 됩니다.
또 발생할 수 있는 이상현상으로 사용자1이 최신 복제 서버를 읽고, 그다음 예전 복제(업데이트가 진행되지 않은) 서버를 읽어 시간이 역전된 듯한 현상도 발생할 수 있습니다.
쓰기를 진행한 경우 다시 읽을 때 리더의 데이터베이스를 참조하거나, 각 사용자가 읽기 시 항상 동일한 복제 서버에서 수행되게끔 하는 단조 읽기 방법 등이 해결 방안으로 제시되지만 실제로 구현하기엔 어려움이 있는 것으로 보입니다.
이상 현상의 대부분의 문제점은 시간으로 인해 해결이 되지만, 그 시간을 줄이는 데 비용을 많이 사용하게 됩니다.
대전 정기 스터디에서는 다양한 주제로 토론도 진행하고 있으며, 지식이 확장되고 함께 성장하는 문화를 지켜나가고 있습니다.
의견을 교류하며 더 많이 기억에 남게 되는 것 같습니다. 오늘도 유익한 시간이었습니다.
K-DEVCON 대전 정기 스터디! 많은 응원과 열정, 그리고 또 참여를 환영합니다!
읽어주셔서 감사합니다! 오늘도 좋은 하루되세요.
K-DEVCON은 IT 전문가 커뮤니티 그룹으로 다양한 IT 기술을 연구하며 회원간의 소통을 공유하는 모임 입니다. 현재 IT업계에 종사하고 있거나, 종사할 예정이거나, IT를 공부하는 학생 그리고 IT에 관심이 있다면 누구나 함께할 수 있습니다.
기술 세미나, 스터디, 토론 등 다양한 활동을 하고 있으며, 주요 소통 및 이벤트 공유는 오픈챗 및 홈페이지 등을 통해서 공유하고 있습니다.
소프트웨어 엔지니어, 데이터 엔지니어, 머신러닝 엔지니어, 시스템 엔지니어, 시큐리티 엔지니어, 데브옵스, SRE, PM, Educator, UI/UX, 스타트업, 대학생 등 다양한 구성원이 활동 중입니다.
homepage : https://k-devcon.com
contact : info@k-devcon.com
'데브콘 리뷰 보기' 카테고리의 다른 글
| [Review] 2024-02-24 K-DEVCON Deajeon : 이월엔 지오! (3) (0) | 2024.03.23 |
|---|---|
| [Review] 2024-02-24 K-DEVCON Deajeon : 이월엔 지오! (2) (1) | 2024.03.23 |
| [Review] 2024-02-24 K-DEVCON Deajeon : 이월엔 지오! (1) (1) | 2024.03.06 |
| [Review] 2024-02-22(목) K-DEVCON 서울 : 이월엔 그로스! 2부 (0) | 2024.02.29 |
| [Review] 2024-02-22(목) K-DEVCON 서울 : 이월엔 그로스! 1부 (0) | 2024.02.27 |