"다수의 서버에 다수의 인스턴스로 동작하더라도 기능에 문제가 없도록 설계되어야 합니다"
이 문장을 해석해보자.
→
애플리케이션을 확장할 때, 애플리케이션의 기능에 문제가 발생하지 않도록 주의해야 합니다. 예를 들어, 사용자의 요청을 처리하는 데 필요한 데이터가 한 대의 서버에만 존재한다면, 그 서버가 아닌 다른 서버에서는 해당 요청을 제대로 처리할 수 없을 것입니다. 또는, 여러 개의 프로세스가 동시에 같은 데이터를 변경하려고 하면, 데이터의 일관성이 깨질 수 있습니다.
따라서, 애플리케이션을 설계할 때는 이런 문제가 발생하지 않도록 고려해야 합니다. 예를 들어, 1.모든 서버가 동일한 데이터에 접근할 수 있도록 분산 데이터베이스를 사용하거나, 2.데이터 변경 작업을 동기화하는 등의 방법을 사용할 수 있습니다. 이렇게 설계하면, 애플리케이션은 여러 서버나 여러 인스턴스에서도 안정적으로 운영될 수 있습니다
분산 데이터베이스를 사용하려면 어떻게 하지? 그리고 데이터 변경 작업을 동기화 하는 방법이 뭘까?
분산 데이터 베이스 사용방법
1.데이터베이스 관리 시스템(DBMS)이 제공하는 분산 처리 기능을 사용
2.여러 대의 서버에 데이터베이스를 설치하고 이들을 연결하는 방식
데이터 변경 작업을 동기화하는 방법
1.데이터베이스의 트랜잭션 기능을 사용
2.분산 락이나 분산 트랜잭션을 사용
"일반적으로는 데이터베이스 관리 시스템(DBMS)이 제공하는 분산 처리 기능을 사용하거나, 여러 대의 서버에 데이터베이스를 설치하고 이들을 연결하는 방식을 사용합니다."
분산 처리 방법의 종류는?
- 복제(Replication): 복제는 데이터를 여러 서버에 동일하게 유지하는 방법입니다. PostgreSQL에서는 주로 마스터-슬레이브 구조를 사용한 복제를 지원합니다. 마스터 서버에서 발생하는 모든 변경(INSERT, UPDATE, DELETE 등)이 슬레이브 서버에도 반영되므로, 마스터 서버에 문제가 생겼을 때 슬레이브 서버를 이용해 서비스를 계속 제공할 수 있습니다. 또한, 읽기 쿼리는 슬레이브 서버에서 처리하도록 분산시킴으로써 성능을 향상시킬 수 있습니다.
- 파티셔닝(Partitioning): 파티셔닝은 큰 테이블을 작은 부분(파티션)으로 나누는 방법입니다. PostgreSQL에서는 테이블을 여러 파티션으로 나누고, 각 파티션을 다른 서버에 저장할 수 있습니다. 이를 통해 데이터의 일부만 조회할 때 필요한 데이터가 저장된 서버에서만 조회를 수행하므로, 전체 데이터를 조회하는 것보다 빠른 성능을 얻을 수 있습니다.
- 셰딩(Sharding): 셰딩은 데이터를 여러 데이터베이스에 분산 저장하는 방법입니다. 각 데이터베이스는 독립적으로 운영되며, 각각의 데이터베이스를 셰드라고 부릅니다. PostgreSQL에서는 직접적인 셰딩을 지원하지 않지만, 응용 프로그램 레벨에서 셰딩을 구현하거나, Citus와 같은 확장 플러그인을 사용하여 셰딩을 구현할 수 있습니다.
이러한 방법들은 각각 장단점이 있으므로, 사용하려는 애플리케이션의 요구 사항에 따라 적절한 방법을 선택해야 합니다. 예를 들어, 복제는 데이터의 안정성을 높이는 데 유용하지만, 쓰기 성능을 향상시키지는 못합니다. 반면, 셰딩은 쓰기 성능을 향상시킬 수 있지만, 데이터의 일관성을 유지하는 것이 더 어렵습니다.
파티셔닝 vs 샤딩
파티셔닝 : 하나의 데이터베이스 내에서 테이블을 논리적으로 분할하는 방법. 각 파티션은 일반적으로 같은 데이터베이스 또는 같은 서버에 위치. 데이터의 조회 성능을 향상 시킴.
샤딩 : 샤딩은 데이터를 여러 데이터베이스에 분산 저장하는 방법. 셰딩은 데이터의 쓰기 성능을 향상시키고, 서버 간의 부하를 분산시키는 데 유용함.
파티셔닝과 셰딩은 각각 다른 상황에서 사용됩니다. 파티셔닝은 주로 대용량 테이블을 관리하고, 데이터 조회 성능을 향상시키는 데 사용됩니다. 반면, 셰딩은 데이터베이스의 쓰기 성능을 향상시키고, 서버 간의 부하를 분산시키는 데 사용됩니다
메시지 큐:
큐 시스템은 일련의 작업을 순서대로 처리하는 데이터 구조입니다. 이는 특히 동시에 많은 요청이 들어오는 시스템에서 유용하게 사용됩니다. 예를 들어, 티켓 예약 시스템에서 동시에 수천명의 사용자가 티켓을 예약하려고 할 때, 모든 요청을 즉시 처리하는 것은 어렵습니다. 이런 경우, 요청을 큐에 넣고 순차적으로 처리하면 시스템의 부하를 줄일 수 있습니다.
- 메세지 브로커:
- 메시지를 받아 처리하고 나면 즉시 삭제되는 구조
- 대표 : Redis ,RabbitMQ
- 이벤트 브로커:
- 데이터를 처리해도 기록을 삭제하지 않음. 브로커에 이벤트 데이터를 저장해 장애가 발생하더라도 그 지점에서 다시 재처리 할 수 있음. 또한, 실시간 스트림 데이터를 효과적으로 처리함.
- Kafka, AWS Kinesis
메시지 브로커는 이벤트 브로커의 역할을 할 수 없지만 이벤트 브로커는 메시지 브로커의 역할도 할 수 있음.
Redis의 분산 락(Distributed Locks) & 클러스터 구성 :
- Redis의 분산 락(Distributed Locks): 여러 서버가 동시에 같은 자원에 접근하는 것을 막는 기능. 마치 여러 사람이 동시에 한 개의 문을 통과하려고 할 때, 한 사람씩 차례대로 통과하도록 하는 것과 같음. 이를 통해 데이터의 일관성을 유지하고 동시에 발생할 수 있는 문제를 방지.
- Redis 클러스터 구성: 클러스터는 여러 서버를 하나의 그룹으로 묶어서 관리하는 것. Redis 클러스터는 여러 Redis 서버를 하나의 그룹으로 묶어서 데이터를 분산 저장하고 처리하는 기능을 제공
대용량 트래픽 참고 자료:
좋은 글 감사합니다.