Education*
Devops
Architecture
F/B End
B.Chain
Basic
Others
CLOSE
Search For:
Search
BY TAGS
linux
HTTP
golang
flutter
java
fintech
개발환경
kubernetes
network
Docker
devops
database
tutorial
cli
분산시스템
www
블록체인
AWS
system admin
bigdata
보안
금융
msa
mysql
redis
Linux command
dns
javascript
CICD
VPC
FILESYSTEM
S3
NGINX
TCP/IP
ZOOKEEPER
NOSQL
IAC
CLOUD
TERRAFORM
logging
IT용어
Kafka
docker-compose
Dart
개발자를 위한 시스템 디자인 개념
Recommanded
Free
YOUTUBE Lecture:
<% selectedImage[1] %>
yundream
2022-10-29
2022-10-16
4634
## 면접을 준비하는 개발자를 위한 시스템 디자인 개념 **시스템 디자인**는 클라우드 엔지니어, DevOps, 소프트웨어 개발자에게 가장 많이 묻는 질문 중 하나다. 면접과정에서 뿐만 아니라 대규모 소프트웨어 문제를 해결하기 위해서도 시스템 설계에 대한 지식이 필요하다. 여기에서는 시스템 설계시 고려해야 하는 기본 개념들과 주요 요소들을 다룰 것이다. ## 시스템 디자인이란 인터넷 서비스 시스템의 최종 목표는 **컴퓨터 시스템을 이용하여 사업의 가치를 고객에게 전달** 하는 것이다. 시스템 디자인은 비즈니스 목표를 달성하기 위한 기능적 및 비기능적 요소를 다룬다. 시스템을 디자인하는 자는(보통 아키텍트라고 부르는) 비용, 기능, 시간을 포함한 다양한 절출안을 고려하여 높은 확장성, 짧은 지연(대기시간), 고가용성을 만족하는 시스템을 설계해야 한다. 시스템 디자인은 몇 가지 필수적인 용어들이 나오게 되는데, 이들 용어를 중심으로 개념적 이해를 하는 것이 좋다. 주요 용어들은 아래와 같다. * 수평/수직 확장성 * 고가용성 * 로드밸런싱 * 데이터 파티셔닝 * 샤딩 * 캐시 * 네트워크 * 프로토콜 * 데이터베이스 : SQL & NoSQL 시스템 디자인은 매우 폭넓은 주제를 다루기 때문에 한번의 인터뷰로 충분하지 않을 수 있다. 그래서 몇 몇 회사들은 시스템 디자인과 관련해서는 두 번 이상 인터뷰를 하고는 한다. DevOps 혹은 클라우드 엔지니어의 경우에는 이론 인터뷰와 실기 인터뷰(과제를 제출하고 이를 가지고 디자인을 토론하는)는 회사들도 많다. 우리가 다룰 주요 개념들을 주제별로 정리 했다. ## Availability 가용성은 시스템의 신뢰성을 측정하기 위해서 사용한다. 가용성은 시스템이 항상 작동상태를 유지하는 것 즉, 클라이언트가 요청을 할 때 언제든지 응답을 할 수 있는 상태를 유지하는 것을 의미한다. 가용성은 일정기간 동안 작동이 가능할 것으로 예측되는 시간을 백분률(%)로 측정을 한다. 예를 들어 1000 시간 동안 999 시간은 작동 할 것이라는 걸 보장하는 시스템이라면 이 시스템은 99.9%의 가용성을 보장한다. 보통 가용성은 1년동안 작동가능한 상태를 백분율로 나타낸다. 이를 표현 할 때는 백분율에 나타나는 9의 숫자로 표현한다. 예를 들어 99.9%의 가용성을 보장하는 시스템은 "이 시스템은 3 nine의 가용성을 보장합니다."라고 표현한다. | 가용성 (%) | DownTime/Year | DownTime/Month | DownTime/Week | | ------- | ------------- | -------------- | ------------- | | 90% (one nine) | 36.53 days | 72 hours | 16.8 hours | | 99% (two nine) | 3.65 days | 7.2 hours | 1.68 hours | | 99.9% (three nine) | 8.77 hours | 43.8 minutes | 10.1 minutes | | 99.99% (four nines) | 52.6 minutes | 4.32 minutes | 1.01 minutes | | 99.999% (five nines) | 5.25 minutes | 25.9 seconds | 6.06 seconds | | 99.9999 % (six nines) | 31.56 seconds | 2.59 seconds | 604.8 milliseconds | 서비스 가용성은 일반적으로 이중화를 이용화를 이용한 복제를 통해서 증가 할 수 있다. 하나의 서버에 장애가 발생하더라도 다른 서버가 작업을 대신처리하게 하여 가용성을 증가시키는 것이다. ## Throughtput Throughput은 시스템의 최대 전송 속도 혹은 용량을 의미한다. 이는 시스템이 주어진 시간 동안에 얼마나 많은 작업을 수행 할 수 있는지를 결정하는 척도로 사용한다. 시스템의 Throughtput을 늘리는 가장 손쉬운(?) 방법은 시스템(컴퓨터)의 수를 늘려서, 요청을 분산처리하는 것이다. ## Latency Latency는 결과 값이 만들어지는데 걸리는 시간의 측정 값이다. 시스템의 속도를 측정하는 지표라고 보면 될 것이다. Latency 가 낮을 수록 빠른 응답을 받을 수 있으니 가능한 Latency를 줄이는게 좋을 것이다. Latency를 낮추는 가장 일반적인 방법은 캐시(Cache)를 구성하는 것 이다. 디스크를 사용하는 데이터베이스에 요청하는 대신에, 메모리를 사용하는 캐시시스템(Redis 같은)에 요청하는 등의 방법이다. ## Network Protocol 네트워크는 물리적인 장치 부터 응용프로그램까지 다양하 프로토콜로 이루어진 복잡한 시스템이다. 네트워크 전체를 이해하면서 애플리케이션을 만드는 것은 불가능에 가깝다. OSI 7 계층(Layer)는 시스템을 7개의 계층으로 계층화 시켜서 단순화 시킨 시스템이다. 각 계층은 그에 맞는 프로토콜을 가지고 있으며, 개발자는 자기가 담당하는 계층의 프로토콜에 집중해서 개발하면 되므로 개발 능률을 향상시킬 수 있다.  개발자는 Network 계층과 Transport 계층 그리고 Application 계층까지 3개 계층을 주로 사용한다. 각 계층의 주요 프로토콜은 아래와 같다. * Network 계층 : IP * Transport 계층 : TCP, UDP * Application 계층 : HTTP, FTP, SMTP ... 클라우드 엔지니어는 위 3개 계층에 대한 보다 심층적인 지식이 필요하다. 클라우드 엔지니어는 Application 계층에서 작동하는 로드밸런서와, Network 계층에서 작동하는 로드밸런서의 차이를 이해하고 있어야 한다. ## Load balancer **로드밸런서**는 많은 서버들 간에 부하를 분산하여 처리 할 수 있도록 조정하는 시스템이다. 로드밸런서는 Throughtput과 Availability를 높이기 위해서 주로 사용하는데, 서버를 늘림으로써 하나 이상의 컴퓨터 시스템에 장애가 발생하더라도 계속 서비스되게 할 수 있다. 또한 컴퓨터를 늘림으로써 처리량을 높일 수 있다. 산술적으로 4대의 서버는 2대의 서버보다 2배 더 많은 요청을 처리 할 수 있을 것이다.  로드밸런스는 다루는 OSI 계층에 따라서 2가지 유형으로 분류 할 수 있다. 1. Application Load Balancer : Application layer에서 작동하는 로드밸런서다. L7 로드 밸런서라고 부른다. HTTP, WebSocket과 같은 애플리케이션 프로토콜을 직접적으로 다룰 수 있기 때문에, 단순 proxy외에 다양한 기능들을 수행 할 수 있다. 예를 들어, URL기반 라우팅, 호스트 네임 기반 라우팅, SSL 인증서 offload, 가중치 기반 라우팅 등 다양한 기능을 사용 할 수 있다. 2. Network Load Balancer : Network Layer에서 작동하는 로드밸런서다. TCP, UDP와 같은 네트워크 프로토콜을 기반으로 한다. 애플리케이션 영역을 다루지 않기 때문에, Application Load Balancer 만큼 다양한 기능을 수행하지 못하지만, 대신 더 간단하고 빠르게 작동한다. ## Proxy 프록시(Proxy)는 클라이언트와 서버 중간에 있는 중개자 시스템이다. 클라이언트가 요청을 보내면 프록시가 이를 받아서 다음 서버에 전달한다. 프록시는 정방향 프록시(forward proxy)와 [역방향 프록시(Reverse Proxy)](https://www.joinc.co.kr/w/man/12/proxy)의 두 가지 유형이 있다. * Reverse Proxy : 클라이언트의 요청을 받아서 뒷 단에 있는 서버에 중개하는 프록시 시스템이다. 로드밸런서와 동일한 구조이며, 실제 로드밸런서는 역방향 프록시의 구현체이기도 하다. * Froward Proxy : 역방향 프록시와는 반대로 서버단(혹은 내부 네트워크)의 요청을 외부로 중개하는 역할을 한다. 허용한 외부서버로만 접속할 수 있게 하는 보안 목적으로 사용하기도 한다.  ## Database 모든 컴퓨터 시스템의 가장 중요한 작업은 **데이터**를 다루는 것이다. 모든 시스템은 어딘가에서 데이터를 읽어오거나 저장해야 한다. 전문적으로 데이터를 다루는 시스템을 **데이터베이스**라고 한다. 데이터베이스는 크게 관계형 데이터베이스 (Relational Database)와 비 관계형 데이터베이스(Non-Relational Database)로 나눈다. **Relation Databases**는 데이터 간의 관계를 엄격하게 적용하는 데이터베이스다. 관계형 데이터베이스는 기본적으로 엄격한 형식에 따라서 저장되고, 엄격한 방식(SQL)을 이용해서 조회 한다. 이러한 데이터베이스는 일관성을 매우 중요하게 생각한다. MySQL, Oracle, PostgreSQL등의 대표적인 관계형 데이터베이스다. **Non relation Databases**는 유연한 구조를 가진다. 엄격한 형식을 가지는 관계형 데이터베이스와는 달리, 형식적으로도 매우 자유롭다. 이러한 데이터베이스는 일반적으로 **분산**과 **속도**에 촛점을 맞춘다. Cassandra, Redis, MongoDB등이 비 관계형 데이터베이스다. 아래는 **Stackoverflow Developer Survey 2022**에 소개된 인기 데이터베이스 목록이다. | 데이터베이스 | 사용율 | | ------ | --- | | MySQL | 46.85% | | PostgreSQL | 43.59% | | SQLite | 32.01% | | MongoDB | 28.3% | | Microsoft SQL Server | 26.87% | | Redis | 22.13% | | MariaDB | 17.93% | | Elasticsearch | 12.21% | | Oracle | 11.49% | | Firebase Realtime Database | 8.72% | | DynamoDB | 8.26% | | Cloud Firestore | 7.45% | | Cassandra | 2.66% | | Neo4j | 2.12% | | IBM DB2 | 2% | | Couchbase | 1.33% | | CouchDB | 1.29% | ## ACID vs BASE 관계형 데이터베이스와 비 관계형 데이터베이스는 다양한 종류의 규정 준수를 보장한다. 관계형 데이터베이스는 일반적으로 **ACID**를 보장하고, 비 관계형 데이텁제이스는 **BASE**를 보장한다. #### ACID AICD(Atomicity, Consistency, Isolation, Durability)즉, 원자성, 일관성, 격리성, 내구성을 보장한다. ACID를 이용해서 관계형데이터베이스는 트랜잭션에 대한 엄격한 관리를 보장한다. * 원자성 : 하나 이상의 작업으로 구성된 작업이 실행될 수 있는데, 이러한 작업중 하나라도 실패하면 전체 트랜잭션이 실패한다. "All or Notion"이라는 트랜잭션 원칙을 보장한다. * 일관성 : 각 트랜잭션이 주어진 규칙 집합에서 유효함을 보장한다. 데이터베이스 상태가 변경될 때마다 데이터가 손상되지 않을 것이라는 것을 보장한다. * 격리 : 트랜잭션이 다른 트랜잭션에 영향을 미치지 않고 독립적으로 발생하는 것을 보장한다. 이를 통해서 데이터베이스작업의 동시성도 함께 보장한다. * 내구성 : 데이터베이스에 기록된 내용은 그대로 유지된다. #### BASE BASE(Basically Available Soft State Eventual Consistency) BASE를 준수함으로써 비 관계형 데이터베이스는 데이터베이스의 무결성을 유지하면서 (관계형 데이터베이스는 제공하기 힘든)더 나은 성능과 확장성을 제공한다. 대량의 데이터를 다룰 때 비 관계형 데이터베이스를 고려하는 주된 이유다. * Basically Available : 시스템이 사용 가능한 상태를 유지하고 가용성을 보장한다. * Soft State : 시스템에 유연성을 제공하며, 시간이 지남에 따라 빠른 액세스가 가능하도록 시스템이 변경된다. * Eventual Consistency(최종 일관성) : 시스템은 결국 최종일관성에 도달한다. 즉시 일관성이 제공되는 관계형 데이터베이스와 차이가 있다. ## SQL vs NoSQL SQL 데이터베이스는 데이터의 구조가 중요하고 쿼리가 복잡하며 업데이트가 적을 때 적합하다. 본질적으로 분산되어 있으며, 확장이 필요하고 빈번한 업데이트가 발생한다면 NoSQL 데이터베이스가 좋은 선택이다. 대부분의 인터넷 서비스는 SQL 과 NoSQL을 함께 사용하여서 성능, 가능, 확장성을 달성한다. 서로 부족한 부분을 채워주는 방식으로 작동한다고 보면 된다. ## Scaling 인터넷 서비스가 양적, 질적으로 성장하면서 더 많은 요청을 처리할 수 있는 능력이 중요해 졌다. 더 많은 요청을 처리하기 위한 가장 좋은 방법은 시스템을 확장하는 것이다. 시스템의 확장에는 **수직 확장**과 **수평 확장** 두 가지가 있다.  수평적 확장은 더 많은 서버를 추가하여 서비스를 확장하는 것을 의미한다. 보통 로드밸런서를 이용해서 서버를 증설하여 요청을 분산해서 처리하는 식으로 작동한다. 수직 확장은 단일 시스템이 더 많은 요청을 처리 할 수 있도록 업그레이드 하는 것이다. 더 강력하고 많은 CPU, 더 많은 메모리, 더 빠른 하드디스크, 더 많은 전력을 투입하는 방식이다. ## Caching 캐싱은 시스템의 성능을 보장하고 응답 대기시간(Latency)를 줄이는데 도움이 된다. 캐싱은 자주 응답하는 데이터를 별도의 장치에 저장하여 더 짧은 시간에 접근 할 수 있도록 한다. 캐시는 특정 데이터를 저장하는데 사용하기 때문에, 데이터베이스에서 처리하는 대신에 캐시에서 빠르고 쉽게 가져올 수 있다. 성능을 향상시킬 수 있는 가장 효과적인 방법이지만 시스템의 복잡성이 증가하는 문제가 있다. 캐시에 저장된 데이터와 데이터베이스에 저장된 원본 데이터간의 일관성이 깨질 수 있으므로 이를 처리하기 위한 복잡도가 더해진다. 캐시는 성능향상을 위해서 메모리를 사용하는데, 일반적으로 비싸다. 따라서 성능의 향상과 메모리 공간, 비용의 문제를 함께 해결하기 위해서, LIFO, FIFO, LRU, LFU 등 다양한 데이터 제거 알고리즘을 사용한다. ## Consistent Hashing Consistent Hashing는 유연한 확장성을 제공하기 위해서 사용한다. 일반적인 해싱보다 더 나은 알고리즘을 제공한다. 일반적인 해싱 알고리즘을 사용 할 경우 시스템이 확장되면(추가되면) 데이터를 전부 재 배치해야 하는 데, Consistent Hasing은 Key / Node 만큼만 데이터를 재 배치하면 된다. 특히 이 방법은 네트워크를 통한 요청처리에 효과적이어서, 로드밸런서 등에 널리 사용한다.  Consistent Hashing에 대한 자세한 내용은 [Consistent Hashing](https://www.joinc.co.kr/w/man/12/hash/consistent) 문서를 참고하자. ## CAP CAP이론(혹은 Brewer's Theorem)은 네트워크로 연결된 분산된 데이터베이스 시스템은 일관성(Consistency), 가용성(Availability), 분할 내구성(Partition Tolerance)의 3가지 특성 중 2가지 특성만 만족할 수 있으며 3가지 특징을 모두 만족할 수는 없다는 이론이다.  데이터베이스를 구성하기 위해서는 3가지 사용 가능한 기능간에 균형을 맞추어야 하기 때문에 개념을 이해하고 있어야 한다. * 일관성 : 모든 컴퓨터 시스템들이 같은 시간에 동일한 항목에 대하여 같은 내용의 데이터를 사용자에게 보여준다. 데이터베이스 시스템이 여러 지역에 분산되어 있을 경우에 전통적인 일관성을 달성 할 수 없게 된다. * 가용성 : 데이터베이스 시스템이 항상 작동중이며, 클라이언트가 요청할 때 올바르게 응답할 수 있어야 함을 의미한다. * 분할 내구성 : 모든 분산 시스템에서 분할 내구성이 중요하다. 분할 내구성은 노드의 손상이나 고장에 관계없이 시스템이 작동해야 하는 것을 의미한다. 예를 들어 지구상에 있는 다양한 지역에 빠르게 데이터를 제공해야 하는 데이터베이스 시스템이 있다고 가정해보자. 이러한 시스템은 "결과적으로 일관성을 제공하는 최종 일관성 모델"을 사용한다. 일관성을 유지 할 수 있으나 이렇게 하려면, 모든 지역에 데이터가 올바르게 업데이트 되었는지를 체크하는 로직으로 성능을 희생시키거나 복잡도가 늘어날 수 있기 때문이다.  ## 리더선출 분산 컴퓨팅에서 리더선출(Leader election)은 단일 프로세서를 여러 컴퓨터에 분산된 작업들의 "관리자 혹은 리더"로 지정하는 작업이다. 분산 컴퓨팅에서는 관리 노드도 가용성을 위해서 두 개 이상(일반적으로 3대 이상)으로 구성한다. 이 중 하나의 노드가 리더가 되어사 전체 분산 시스템을 관리한다. 결국 여러 노드들 중에서 어떤 노드가 리더가 되어야 하는지를 선출해야 한다. 리더를 선택하기 위한 몇 가지 알고리즘이 있는데, 이해하고 있으면 많은 도움이 될 것이다. * Bully Algorithm * Paxos * RAFT * ZAB(Apache Zookeeper)
Recent Posts
LLama-3.2-Vision 테스트
Vertex Gemini 기반 AI 에이전트 개발 04. 프롬프트 엔지니어링
Vertex Gemini 기반 AI 에이전트 개발 03. Vertex AI Gemini 둘러보기
Vertex Gemini 기반 AI 에이전트 개발 02. 생성 AI에 대해서
Vertex Gemini 기반 AI 에이전트 개발 01. 소개
Vertex Gemini 기반 AI 에이전트 개발-소개
생성 AI 모델 Flux.1 설치 및 사용
GPT를 이용한 Reranker 테스트
5분만에 만들어보는 Streamlit 챗봇
Let's encrypt로 SSL 인증서 관리하기
Archive Posts
Tags
cloud
database
분산시스템
Copyrights © -
Joinc
, All Rights Reserved.
Inherited From -
Yundream
Rebranded By -
Joonphil
Recent Posts
Archive Posts
Tags