<div id="readability-page-1" class="page"><div>
    <div>
        
        <h2>
            데이터 중심 애플리케이션 설계 정리
        </h2>
        <h2>
            Part 2
        </h2>
        
        <h3>
            2022-02-02
        </h3>
        
    </div>
    

    
    


    
    
    

    <h2 id="분산-데이터">분산 데이터</h2>

<p>여러 장비 간 분산된 데이터베이스를 필요로 하는 이유</p>

<ul>
  <li>확장성</li>
  <li>내결함성/고가용성</li>
  <li>지연 시간</li>
</ul>

<h2 id="고부하로-확장">고부하로 확장</h2>

<p>더 강력한 장비로 변경을 통해 더 많은 트래픽을 처리할 수 있으며, 공유 메모리를 통해 한대의 서버 처럼 처리할 수 있다.<br>
Hot 스왑등을 이용해 다운타임 없이 장비를 유지 보수 할 수 있다.</p>

<p>이를 수직 확장이라고도 한다.</p>

<p>하지만 이런경우 무한한 증가가 어렵기에 다른 물리 서버를 추가하는 방식을 사용한다.</p>

<h3 id="비공유-메모리-아키텍처">비공유 메모리 아키텍처</h3>

<ul>
  <li>다른 서버 한대를 추가 (각 서버를 노드라고 칭한다.)</li>
  <li>네트워크 통신으로 소프웨어적으로 제어</li>
  <li>수평 확장이고도함</li>
</ul>

<p>공유 메모리 아키텍처에 비해 많은 장점이 있지만, 복잡도를 증가시키고, 발생 할 수 있는 문제가 있다.</p>

<h3 id="복제-대-파티셔닝">복제 대 파티셔닝</h3>

<ul>
  <li>
    <p>복제: 같은 데이터의 복사본</p>
  </li>
  <li>
    <p>파티셔닝: 큰 DB를 파티션으로 쪼개 각기 다른 노드에 추가한다. (aka 샤딩)</p>
  </li>
</ul>

<hr>

<h2 id="복제">복제</h2>

<p>네트워크로 연결된 여러 장비에 동일한 데이터의 복사본을 유지한다 란 뜻</p>

<p>이때 노드간 데이터를 동일하게 유지하기 위해 변경 사항을 각 노드로 복제</p>

<p>복제 알고리즘에서 가장 많이 사용되는 알고리즘이다.</p>

<ul>
  <li>단일 리더</li>
  <li>다중 리더</li>
  <li>리더 없음</li>
</ul>

<h3 id="리더와-팔로워">리더와 팔로워</h3>

<p>DB의 복제본(replica)를 가지고 리더 기반 복제(혹은 master-slave, active-passive)</p>

<p>복제된 노드중 하나를 리더(master or primary)로 지정하고 쓰기는 리더에서 한다.<br>
다른 복제 서버는 팔로워(read replica, slave, secondary)라고 한다.</p>

<p>결국 클라이언트는 write는 리더에게, read는 팔로워에게 요청하게 된다.</p>

<h4 id="동기식-대-비동기식-복제">동기식 대 비동기식 복제</h4>

<p>동기식 복제: 일관성 있는 데이터 유지, but 응답이 지연되면 쓰기가 처리되지 않음
비동기식 복제: 쓰기에 영향을 끼치지 않음, but 일관성이 깨질 수 있음
반동기식: 팔로워 중 하나라도 응답하면 나머지는 비동기식으로 처리되는것</p>

<h4 id="새로운-팔로워-추가">새로운 팔로워 추가</h4>

<ol>
  <li>DB 전체 백업</li>
  <li>새 팔로워에 복사</li>
  <li>binlog를 통해 변경 이후 데이터 요청</li>
  <li>모두 처리 완료 후 “따라잡음”</li>
</ol>

<h3 id="노드-중단-처리">노드 중단 처리</h3>

<p>노드가 멈추는 경우 자동/수동으로 복구해줘야하며, 팔로워/리더가 멈췄을 때 각각 대응이 필요하다.</p>

<h4 id="팔로워-장애-따라잡기-복구">팔로워 장애: 따라잡기 복구</h4>

<p>일관성이 깨진 지점 부터 지금 지점까지 따라잡으며 복구한다.</p>

<h4 id="리더-장애-장애-복구">리더 장애: 장애 복구</h4>

<ol>
  <li>리더가 장애인지 판단.</li>
  <li>새로운 리더 선출</li>
  <li>새로운 리더 사용을 위해 시스템 재설정</li>
</ol>

<p>다만 팔로워 복구와는 다르게 잘못될 경우 여러 문제 점이 생길 수 있다.</p>

<ul>
  <li>비동기식 복제의 경우 새로운 리더의 데이터와 이전 리더의 데이터가 맞지 않을 수 있음</li>
  <li>여러 노드가 자기가 리더라고 주장하는 스플릿 브레인 상황이 발생 할 수 있음</li>
  <li>정말 리더가 죽었는지에 대한 판단이 애매함</li>
</ul>

<h3 id="복제-로그-구현">복제 로그 구현</h3>

<p>다양한 방법으로 복제를 진행한다.</p>

<h4 id="구문-기반-복제">구문 기반 복제</h4>

<p>SQL 구문을 그대로 파싱하고 실행해 데이터를 복제한다.</p>

<h4 id="쓰기-전-로그-배송">쓰기 전 로그 배송</h4>

<p>추가되는 바이트로 열을 복제한다.</p>

<p>오라클, Postgresql에서 사용</p>

<h4 id="논리적-로그-복제">논리적 로그 복제</h4>

<p>Row 단위로 DB 테이블에 쓰기를 기술한 레코드 열이다.</p>

<p>MySQL에서 사용</p>

<h4 id="트리거-기반-복제">트리거 기반 복제</h4>

<p>DBMS상에서 사용되는 트리거나, 스토어드 프로시저를 이용한 방법</p>

<p>애플리케이션 코드를 사용할 수 있는 만큼 오버헤드가 크지만, 그만큼 유연하기에 많이 사용되어진다.</p>

<p>(쓰기 충돌 해소 로직 등을 추가하여 사용할 수 있다.)</p>

<h3 id="복제-지연-문제">복제 지연 문제</h3>

<p>리더의 쓰기속도를 팔로워가 따라가지 못해 발생하는 이슈이다.</p>

<p>동기식에선 읽기 서버 확장을 통해 해소할 수 있지만, 그만큼 장애 확율이 높아지기에 불안정해진다.</p>

<p>비동기 방식은 잠시 따라가지 못하더라도 최종적으로 따라가게 된다.</p>

<h4 id="자신이-쓴-내용-읽기">자신이 쓴 내용 읽기</h4>

<p>자신이 쓰고 바로 읽을 때 팔루워 DB에 까지 아직 복제가 이뤄지지 않은 경우</p>

<ul>
  <li>쓰기 후 읽기는 리더에서 읽게 설정해 일관성을 유지할 수 있다.</li>
</ul>

<h4 id="단조-읽기">단조 읽기</h4>

<p>시간이 거꾸로 가는 현상</p>

<p>팔로워가 여럿일 때 모든 팔로워에 복제가 이뤄지지 않아 각 요청시 다른 결과를 반환 하는 경우</p>

<ul>
  <li>유저id 등을 이용해 한 팔로워 서버를 사용하게 하는 방식 등이 있다.<br>
다만, 팔로워 서버가 망가진 경우 재라우팅이 필요하다.</li>
</ul>

<h4 id="일관된-순서로-읽기">일관된 순서로 읽기</h4>

<p>데이터의 순서가 뒤바뀌는 증상</p>

<p>샤딩된 DB에서 많이 발생하는 증상이며, 질문전에 답이 나오는 등의 문제가 발생하는 경우</p>

<ul>
  <li>DB데이터를 항상 같은 순서로 쓰기를 적용하면 일관된 순서현상을 일어나지 않는다.</li>
</ul>

<h3 id="복제-지연을-윈한-해결책">복제 지연을 윈한 해결책</h3>

<p>최종적으로 일관된 시스템을 유지하며, 비동기식이면서 동기식으로 동작하는 척 하는 것이 해결방법이다.</p>

<p>이에 관련된 방법은 Part 3에서 다루게 된다.</p>

<h3 id="다중-리더-복제">다중 리더 복제</h3>

<p>리더 기반 복제의 단점인 리더가 하나만 존재 해야하는 상황에 대한 대응 방안이다.</p>

<p>하지만 다중 리더인 만큼 쓰기에 대한 복잡성, 장애 대응, 운영 난이도가 크게 올라게된다.</p>


    
    
    
</div></div>

 SilNex  

silnex

책을 읽으면서 내용을 정라하며 기록

데이터 중심 애플리케이션 설계 정리

댓글