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

Jung Yun Kim·2021년 9월 2일
0

Why

개발을 하고 유저가 사용함에 따라 데이터가 매번 쌓인다. 이전에는 데이터를 효과적으로 주고받고, 보관하며, 계산하는가에 초점이 있다.
전반적으로 어떻게 데이터가 많아지면 어떻게 시스템을 설계하는 것이 좋을지 생각하게 해주는 책이라고 생각한다.

데이터 시스템의 기초

애플리케이션이 필요로 하는 것

데이터베이스 - 데이터를 저장
캐시 - 읽기속도 향상을 위해 값비싼 수행결과를 기억
검색색인 - 키워드로 데이터를 검색하거나 필터링 제공
스트림처리 - 비동기 처리를 위해 다른 프로세스로 메시지 보내기
일괄처리 - 주기적으로 대량의 데이터 분석

신뢰성

무언가 잘못되더라도 지속적으로 올바르게 동작함

  1. 하드디스크, 램, 네트워크 케이블을 잘못연결하거나 뽑는 등의 문제
  2. 잘못된 입력으로 애플리케이션이 멈춰버리는 문제
  3. 일부 프로세스가 자원(CPU, 램, 네트워크 등)을 과도하게 사용
  4. 관리자가 설정파일을 잘못설정하였을 때
  5. 잘못된 데이터를 기반으로 하여 통계같은것들이 이미 계산되었을때, 재계산 도구가 필요

모두 경험해 보았던 문제다. 서비스를 하는 건 아니지만 다녔던 회사에서 서버실을 구축해서 사용하고 있었을 때, 하드디스크 문제, 램문제, 네트워크 케이블을 잘못뽑는 문제 모두 경험해보았으며, 2,3,4,5 역시 모두 경험해보아서 극 공감한다.
나는 하나의 장비에 패킷처리, 로깅, 검색 등 4~5개의 프로세스가 떠 있는 제품을 만들어본적이 있다.
여기서 문제는 각자 다른개발자들이 모여 만들었기 떄문에 3번의 상황이 벌어질 경우 패킷처리가 안되는 문제가 있었다.
5번도 마찬가지로, 타시스템에 붙지 못하거나, 데이터를 가져올 수 없는 상황을 개발자가 투입되서 해결 후 통계가 맞지 않는 문제가 있었다.

확장성

비지니스가 확장됨에 따라 시스템의 동시 사용자수가 증가함에 부하가 증가하는데, 안정적으로 동작할까?

확장성은 시스템이 특정방식으로 커지면 이에 대처하기 위한 선택은 무엇인가? and 추가 부하를 다루기 위해 계산 자원을 어떻게 투입할까? 라는 의미

예를 들어 트위터
트위터가 초창기에 비해서 엄청나게 커졌는데, 이를 어떻게 해결했을까?

  1. 초창기 버전
    우리가 아는 RDB의 조인
    트윗테이블에 보낸 사람의 ID를 FK로 저장하고 JOIN으로 가져온다.
    타임라인을 보면 항상 조인문을 실행할 것임

  2. 개선버전
    사용자가 트윗을 작성하면 팔로워들의 홈타임라인에 내용을 쓰게끔 하는 것
    팔로워가 천만명이면 단일트윗 하나를 보내도 천만명에게 쓰게끔 된다!

  3. 하이브리드
    팔로워가 일정수가 되면 1번을 통해 작동하고, 기본동작은 2번

부하 대응 접근방식

Scale up

좀 더 좋은 장비

Scale out

좀 더 많은 장비

동영상을 올리면 인코딩하는 서비스를 만들었다고 해보자.
요청사항이 빠른시간안에 동영상이 올라가야 한다 라고 하면 Scale up을 해야 되겠고,
다수의 사용자의 평균시간을 줄이자고 한다면 Scale out을 해야할듯하다.
둘다 잡으려면 더 복잡한 로직이 필요하겠지(스케일 업, 아웃은 당연히 고려해야 하고..)

유지보수성

쿠버네티스가 생각난다.

운용성

운영이 편리해야 한다. CI,CD에 매우 어울리는 상황
시스템을 배포하고 복원할 수 있어야 한다.
모니터링 매번 서버에서 top 으로 확인해야하는가?
오류의 전파가 있기전에 자동으로 차단해야 한다.

단순성

새로운 엔지니어가 시스템을 이해하기 쉽게 해야한다.
복잡성은 다양한 증상으로 나타난다. 용량의 급증, 모듈간 강한 커플링, 복잡한 의존성, 일관성 없는 명명, 성능 문제 해결을 목표로 한 해킹, 임시방편으로 문제를 해결한 특수 사례

발전성

요구사항이 바뀌지 않는 소프트웨어는 없으니 간단하고 이해하기 쉬운 시스템을 만들어 수정에 용이해야한다.

정리

모두 한번씩 회사에서 겪어 보았던 문제이다.
회사를 다니면서 제품을 리뉴얼할 기회가 있었지만 4~5개의 프로세스가 엮여 있는 것이라, 1~2개만 리뉴얼을 하고 다른 부분은 리뉴얼을 하지 못하였다.
그런 부분에서 좀 아쉽고, 그런 제품으로 유지보수에서 애먹었을 엔지니어분들에게 고마운 감사를 표한다.
그런제품을 만들지 말아야지 라는 생각은 항상 하고 있다.

0개의 댓글