데이터 모델과 트랙잭션 디자인 / 개별 프로세스 운영 관리 및 배포 시스템 디자인

패스트 캠퍼스(The Red: 4천만 MAU를 지탱하는 서비스 설계와 데이터 처리 기술 by 카카오페이지 기술전략이사 윤진석) 필기록입니다.

---

서버 개발자들은 반드시 영속화 레벨의 데이터에 대해서 문제를 해결하는 일을 마주치게 된다. 

 

논리적 데이터 아키텍처 

-> 데이터 스키마 또는 논리적 데이터 모델이라고 함 

 

논리적 데이터 모델은 흔히

(1) 객체 기반의 개체-관계 ER모델 -> Object-based logical models 

(2) 행 기반의 관계형 모델을 사용 -> Record-based logical models

 

NoSQL 데이터 모델은 모두 (3) nested key value pairs 다차원 모델을 사용한다. -> object도 아니고 record 기반도 아니다 

 

 

객체지향의 프로그래밍 모델에서는 일반적으로 Object based Logical models를 사용한다. 

 

 

 

 

ERD (Entity Relational Diagram)

사람이 있을 때 여러가지 속성값들을 원형으로 표현한다. 

 

이메일 같은 경우 다중속성으로 이중 원형으로 표현. 

 

ERD를 관계형 모델로 바꾸면 

 

Persons(personId, name, lastName, email) 

 

 

관계를 갖도록 표현할 수도 있다. 

 

 

Persons(personId, name, lastname, email, wifeId)

 

다양한 관계형 모델의 표현을 살펴보자. 

 

 

 

ORM (Object Relational Mapping)

관계형 모델을 OOP의 Entity 형태로 투형(mapping)시키는 방법 

 

Persons(id int, name varchar, age int) 

 

public class Person { 
	private int id;
	private String name; 
    private int age;
    
    public int getID() { 
        return id;
    }

    public void setId(int id) { 
        this.id = id;
    }

    public String getName() { 
        return name;
    }

    public void setName(String name) { 
        this.name = name;
    }

    public int getAge() { 
        return age;
    }

    public void setAge(int age) { 
        this.age = age;
    } 

}

 

 

도식화된 그림을 보면 다음과 같다. 

 

Object Composition 개념이 있다. 

 

기본 Base가 있고 각각의 구체클래스들이 별도의 클래스를 가지면서 표현됨 

 

위의 그림처럼 각각의 테이블이 있을 수도 있고 하나의 테이블로 만들 수도 있다. 

 

 

Orm의 필요 이유 

-> ORM은 일반적으로 DB와 소프트웨어 중간의 Persistence Layer라고 함 -> 지속적인 서비스 소프트웨어 개발/배포 

 

- DBMS에 대한 종속성이 줄어든다.

- 재사용성 및 유지보수성

- 직관적인 코드 

 

 

트랜잭션 

데이터베이스의 상태를 변화시키기 위해 수행하는 논리적 작업의 단위 

 

예를 들어 페이스북에서 친구 요청을 수락 할 때, 

- 나의 친구 목록에 추가함과 동시에 

- 상대방의 친구요청 대기 상태를 수락으로 변경 

 

 

트랜잭션 인터페이스 디자인 

- 트랜잭션 명시: 클라이언트가 수천 개의 개별 쿼리로 접근할 때, 그중 트랜잭션들이 있다면 트랜잭션의 시작과 끝을 제어할 수 있도록 하여 각 쿼리의 고성능 처리와 적절한 롤백 전략을 제시 

- 트랜잭션 묵시: 일반적으로 서비스의 데이터베이스는 여러 개인데, 클라이언트가 특정 데이터베이스에만 종속되기 때문에 숨기는 경우 -> 추상 트랜잭션 메커니즘 형태로 디자인한다 

 

 

---

 

기술적으로 365일 24시간 동안 무정지 되는 서비스를 위해서 소프트웨어를 업그레이드하고 배포하는 방법들에 대해 알아보자. 

 

서비스 무정지 배포 패턴 

 

크게 deployment 접근 방식을 3가지로 볼 수 있다. 

 

 

1) Rolling Deployment

- 순차적으로 패치 

- Backward compatibility 관리 필요 

 

 

 

API 서버의 패치가 필요하다고 할 때, 한 대씩 새로운 버전으로 업그레이드하여 처리한다. 

 

 

 

 

2) Blue/Green Deployment 

- 전체 서버를 스와핑하는 방식 

- 비용이 많이 듬 

 

 

 

기존의 버전과 동일한 스펙의 서버를 준비해놓고 한번에 스위치하는 방식을 블루 그린 배포라고 한다. 

 

롤링 업데이트 같은 경우 중간에 버그가 발생하면 롤백할 수 있지만, 블루 그린 배포에서는 롤백이 필요한 상황이라면 L4 스위치에서 old 혹은 new를 선택하기만 하면 된다. 

 

경험적으로 볼 때 큰 업데이트가 필요한 상황에서 이용하면 유용하다. 

 

 

3) Canary Deployment 

- 트래픽을 순차적으로 이주

- Backward compatibility 관리 필요 

 

 

 

전체 중 퍼센테이지로 분배하면서 점차적으로 배포하는 방식 

 

처음에는 25%만 베타유저 처럼 신규 버전을 이용하게 하다가 점점 50% -> 75% -> 100% 교체하는 방식으로 진행 

 

롤링 업데이트와 차이라고 한다면 기존과 신규의 정확한 비율을 바탕으로 A/B 테스트 같이 테스트를 할 수 있는 환경이 좀 더 용이하다.