안녕하세요
북미 개발자 취업 컨설팅 드로우드림입니다!
이번 글에서는 데이터베이스의 기초개념인 트랜잭션과 ACID에 대해 알아보겠습니다.
<트랜잭션(Transaction)이란?>
하나의 논리적 기능을 수행하기 위한 작업의 단위이자, 더이상 쪼갤 수 없는 업무의 최소단위입니다. 이 때의 한 덩어리의 작업들은 모두 실행되거나, 모두 실행되지 않습니다. (all-or-nothing) 즉 묶여있는 모든 작업들을 모두 완료해야 정상적으로 종료되고 하나의 트랜잭션은 실행을 마치면 commit(완료)되거나 처음부터 다시 시작하는 rollback(변경 취소) 됩니다.
<트랜잭션이 왜 필요할까요?>
트랜잭션의 목적은 데이터의 부정합을 방지하기 위함입니다. 예를 들면, A 은행 → B은행으로 돈을 보내기 위하여 출금하고 송금한다고 가정합니다. A은행에서 돈을 출금하고나서 B은행으로 송금하려고 하는데 갑자기 시스템이 멈추면 어떻게 될까요? 돈은 출금되었지만, 송금되지 않고 증발하게 되는 끔찍한 상황이 발생합니다.
데이터베이스의 트랜잭션이 안전하게 수행되기 위해서는 ACID라는 조건을 만족해야합니다.
ACID란 원자성(Atomicity), 일관성(Consistency), 격리성(Isolation), 지속성(Durability)의 네 가지 주요 속성을 의미합니다. ACID 트랜잭션은 데이터베이스 작업이 올바르게 실행되도록 보장하며, 실패가 발생하더라도 데이터베이스가 이전 상태로 복구될 수 있게 합니다. 이로 인해 데이터의 신뢰성과 일관성을 높이는 데 중요한 역할을 합니다.
<ACID 트랜잭션의 기본 속성 이해하기>
원자성 (Atomicity)
ACID 트랜잭션에서 원자성은 트랜잭션이 하나의 단일하고 분할할 수 없는 작업 단위로 처리된다는 것을 보장합니다. 트랜잭션의 어떤 부분이라도 실패하면 전체 트랜잭션이 롤백되어 트랜잭션 중에 이루어진 모든 변경 사항이 되돌아가게 됩니다. 이렇게 함으로써 데이터베이스가 일관된 상태를 유지하고 트랜잭션 중에 발생할 수 있는 어떤 실패도 영향을 미치지 않도록 보장합니다
일관성 (Consistency)
일관성은 트랜잭션 전후에 데이터베이스가 유효한 상태를 유지하도록 보장합니다. 다시 말해, 데이터베이스 스키마는 모든 제약 조건과 규칙을 만족해야 하며, 이러한 제약 조건을 위반하는 트랜잭션은 데이터베이스의 일관성을 유지하기 위해 롤백되어야 합니다. 이를 통해 데이터베이스가 무결성을 유지하고 데이터가 정확하고 신뢰할 수 있도록 보장됩니다.
격리성 (Isolation)
격리성은 각 트랜잭션이 다른 트랜잭션과 독립적으로 작동함을 보장합니다. 즉, 트랜잭션의 효과는 커밋되기 전까지 다른 트랜잭션에 보이지 않아야 합니다. 이를 통해 동시 실행되는 트랜잭션 간의 간섭과 충돌을 방지하고 데이터베이스의 무결성을 유지합니다. 애플리케이션과 데이터베이스 시스템의 특정 요구 사항에 따라 트랜잭션의 격리 수준을 조정할 수 있습니다.
지속성 (Durability)
지속성은 시스템 오류가 발생하더라도 트랜잭션 중에 데이터베이스에 수행된 변경 사항이 영구적으로 저장됨을 보장합니다. 커밋된 트랜잭션 후의 모든 변경 사항은 시스템이 파괴되거나 전원이 끊겨도 유지됩니다.
<ACID 트랜잭션의 작동 원리>
ACID 트랜잭션은 일련의 단계를 통해 데이터 무결성을 유지합니다. 다음은 데이터베이스가 ACID 트랜잭션을 구현하는 일반적인 방식입니다.
트랜잭션 시작: BEGIN TRANSACTION 문을 통해 트랜잭션을 시작하고, 트랜잭션을 롤백할 수 있는 저장점을 설정합니다.
작업 실행: 트랜잭션 내의 모든 작업이 순차적으로 실행됩니다. 데이터베이스는 각 작업이 제약 조건과 스키마를 준수하는지 검증합니다.
커밋 또는 롤백: 모든 작업이 성공적으로 완료되면 COMMIT 문을 통해 트랜잭션이 커밋됩니다. 작업 중 하나라도 실패하면 트랜잭션은 시작 시 설정된 저장점으로 롤백됩니다.
<ACID 트랜잭션의 실제 예시>
예를 들어, 은행 앱에서 사용자가 한 계좌에서 다른 계좌로 자금을 이체하려는 경우를 생각해보겠습니다. 트랜잭션은 다음과 같이 진행될 수 있습니다:
트랜잭션 시작: 돈을 인출하는 작업을 시작합니다.
출금: 출금 계좌에서 이체 금액을 차감합니다.
입금: 입금 계좌에 이체 금액을 추가합니다.
**커밋
<ACID 트랜잭션 대안 >
ACID 트랜잭션은 데이터 신뢰성, 일관성, 독립성 및 내구성을 보장하는 여러 가지 이점을 제공합니다. 그러나 모든 응용 프로그램에 최적의 선택은 아닐 수 있습니다. 이러한 경우 ACID 대신 고려할 수 있는 다양한 대안적 트랜잭션 모델과 이론이 있습니다. 이러한 대안에는 다음이 포함됩니다:
BASE (기본적으로 사용 가능하고, 소프트 상태이며, 최종적으로 일관성있음) BASE는 ACID 트랜잭션의 대체물이 아니라 즉시 일관성을 보장할 수 없는 분산 시스템을 처리하기 위한 대안적 모델입니다. BASE는 일관성보다는 가용성과 분할 내구성을 강조합니다. 이 모델은 장기적인 안정성을 위해 단기적인 일관성을 희생합니다. 모든 데이터가 결국 일관성을 갖추게 될 것이라고 가정하지만 이를 보장할 수는 없습니다. 이 접근 방식은 높은 볼륨의 분산 시스템에 적합하며 확장성과 가용성을 더 많이 제공합니다. NoSQL 데이터베이스와 함께 사용되는 경우가 많으며, 이는 엄격한 일관성 요구 사항보다는 확장성과 가용성을 우선시합니다.
CAP (일관성, 가용성, 분할 내구성) CAP 이론은 분산 시스템에서 세 가지 일관성, 가용성 및 분할 내구성을 모두 보장하는 것은 불가능하다는 것을 설명합니다. 그러나 일관성을 가용성 및 분할 내구성에 희생시키지 않기를 제안하지는 않습니다. 사실, 이 이론은 일관성과 분할 내구성 사이의 상충 관계를 제시합니다. 이는 네트워크 분할이 발생할 때 일관성과 분할 내구성 중에서 선택해야 한다는 것을 의미합니다. CAP 이론은 실제로 대체 트랜잭션 모델이 아닌 분산 시스템의 한계를 이해하기 위한 이론적인 프레임워크입니다. CAP 원칙의 원칙을 사용하여 분산 시스템을 설계하고 구현할 수 있습니다.
NoSQL 데이터베이스 NoSQL 데이터베이스는 엄격한 일관성 기준을 강요하지 않으며 성능과 확장성을 우선시합니다. 높은 처리량이 필요한 응용 프로그램에서 사용되며 데이터 일관성이 중요하지 않습니다. 관계형 데이터베이스가 원하는 ACID 특성을 보장하는 반면, NoSQL 데이터베이스는 대량 및 복잡한 데이터 세트를 처리하는 데 더 효과적입니다. 또한 BASE 속성은 다양한 응용 프로그램에 대해 더 나은 성능을 발휘할 수 있습니다. 이 경우 항상 ACID가 보장되지 않습니다.
<분산 시스템의 ACID 트랜잭션 >
분산 시스템은 단일 서비스를 제공하기 위해 서로 상호 작용하는 여러 컴퓨터로 구성됩니다. ACID 트랜잭션은 지리적으로 분산된 여러 노드로 구성되어 네트워크를 통신하는 분산 시스템에서 구현하기 어려울 수 있습니다. 대표적으로는 지연 시간과 일관성, 가용성 및 확장성과 같은 문제로 인해 발생합니다.
네트워크 지연 시간: 분산 시스템에서 네트워크 지연 시간은 ACID 트랜잭션의 성능에 영향을 줄 수 있습니다. 네트워크 통신 지연으로 인해 트랜잭션 시간이 길어지고 오버헤드가 높아질 수 있습니다.
일관성: 분산 시스템의 모든 노드에서 일관성을 유지하는 것은 어려울 수 있습니다. 분산 시스템의 노드는 동일한 데이터의 다른 버전을 저장할 수 있으며 이는 불일치를 유발할 수 있습니다.
가용성: 분산 시스템을 가용 상태로 유지하는 것은 어려울 수 있습니다. 노드가 실패할 수 있으며 시스템의 반응성을 유지하기가 어려울 수 있습니다.
확장성: 분산 시스템의 노드 수가 증가함에 따라 일관성과 가용성을 유지하기가 더 어려워집니다.
분산 시스템에서 ACID 속성을 유지하기 위한 해결방법
네트워크 지연, 일관성, 가용성 및 확장성과 같은 요소로 인해 분산 시스템에서 ACID 트랜잭션을 유지하기 어렵다는 문제점을 해결하기 위해 여러 해결책이 개발되었습니다. 각 해결책을 자세하게 알아봅시다.
이중 커밋: 이 프로토콜은 분산 시스템의 모든 노드가 트랜잭션을 커밋하기 전에 동의하여 데이터 일관성과 트랜잭션 결과에 대한 합의를 보장합니다. 다중 버전 동시성 제어 (MVCC): 이 기술은 각 트랜잭션이 적절한 데이터 버전에 액세스할 수 있도록하여 분산 시스템에서 데이터 동시성을 관리하며 동일한 데이터의 여러 버전이 공존할 수 있도록합니다. 복제: 분산 시스템에서 복제는 다양한 노드에 동일한 데이터의 여러 복사본을 유지함으로써 네트워크 지연을 줄이고 가용성을 높입니다. 분할: 이 프로세스는 분산 시스템의 여러 노드에 데이터를 분할하여 성능과 확장성을 개선하지만 데이터 일관성 유지의 복잡성을 증가시킵니다.
ACID 트랜잭션은 데이터베이스 관리의 기본 개념으로 데이터 무결성, 일관성, 격리 및 내구성과 같은 이점을 제공합니다. 서버가 실패해도 데이터베이스가 일관된 상태를 유지하는 것을 보장합니다. 그러나 과도한 처리 부담, 교착 상태 및 분산 시스템에서의 확장성 문제와 같은 제한 사항이 있습니다.
ACID 트랜잭션은 강력한 일관성과 신뢰성을 제공하지만 모든 사용 사례에 항상 최적의 선택이 되지는 않을 수 있습니다. 따라서 고유한 요구 사항과 요구 사항을 신중하게 평가하여 ACID 트랜잭션 또는 BASE 또는 CAP와 같은 대체 트랜잭션 모델이 시스템에 더 적합한지를 결정해야 합니다.
<rate limit>
<Rate Limiting이란? >
Rate Limiting은 사용자가 시스템 자원을 고갈시키는 것을 방지하기 위해 네트워크 트래픽을 제한하는 기술입니다. Rate Limiting은 악의적인 행위자가 시스템을 과도하게 부담시키고 서비스 거부(DoS)와 같은 공격을 유발하는 것을 어렵게 만듭니다. 이것은 공격자가 대상 시스템에 요청을 넘치게 하여 네트워크 용량, 저장 공간 및 메모리를 과도하게 소비하는 것을 포함합니다.
Rate Limiting을 사용하는 API는 너무 많은 API 호출을 시도하는 모든 클라이언트를 속도 제한하거나 일시적으로 차단할 수 있습니다. 이는 속도 제한된 사용자의 요청을 특정 시간 동안 느리게 하거나 전혀 차단할 수 있습니다. Rate Limiting은 합법적인 요청이 시스템에 도달하여 전체 응용 프로그램의 성능에 영향을 미치지 않고 정보에 액세스할 수 있도록 보장합니다.
<Rate Limiting이 중요한 이유>
Rate Limiting은 현대적인 사이버 보안 전략의 중요한 부분입니다. 들어오는 요청률에 영향을 미치는 여러 공격 기술에 대응합니다.
분산 서비스 거부(DDoS)
DDoS 공격은 대상 시스템을 트래픽으로 압도하여 합법적인 사용자에게 사용할 수 없게 만들려고 시도합니다. Rate Limiting은 특정 트래픽 출처가 너무 많은 요청을 보내지 못하게하여 DDoS 위협을 완화합니다.
그러나 DDoS 공격은 요청을 많은 다른 소스로 분배하기 때문에 독특한 도전 과제가 있습니다. 때로는 수백만 개의 IP 주소가 될 수 있습니다. 공격을 분산하면 각 출처가 속도 제한을 초과하지 않도록 할 수 있습니다. 보안 솔루션은 서로 다른 위치에서의 요청을 단일 공격의 일부로 식별하여 하나의 출처로 처리해야 합니다.
자격 채우기 공격자가 사용자 자격 증명을 포함하는 데이터베이스를 침해하면 이러한 자격 증명을 사용하여 추가 공격을 수행할 수 있습니다. 일반적으로 봇은 자격 증명을 로그인 양식에 넣어서 자격 증명 세트가 작동할 때까지 로그인할 수 있습니다.
봇은 종종 수백 또는 수천 개의 자격 증명을 로그인 양식에 제출할 수 있기 때문에 아주 유용합니다. Rate Limiting은 자격 채우기를 식별하고 봇이 계정을 탈취하기 전에 차단하는 데 도움이 됩니다.
무차별 대입
무차별 대입 공격은 실제 사용자 자격 증명 목록이 없는 자격 증명 채우기 공격과 유사합니다. 이 경우 봇은 임의로 생성된 자격 증명을 제출하여 자격 증명 세트가 작동할 때까지 시스템적으로 제출합니다.
강력하게 보호된 웹 응용 프로그램은 무차별 대입 공격을 완화하기 위한 암호 요구 사항을 설정하지만 대규모 공격은 여전히 많은 네트워크 리소스를 소비할 수 있습니다. Rate Limiting은 시스템 리소스를 절약하기 위해 이러한 공격을 차단합니다.
데이터 스크래핑 및 도난
악의적인 행위자들은 대상 웹 사이트에서 정보를 스크랩하여 판매하거나 경쟁사를 약화시키는 데 사용합니다. 예를 들어, 공격자는 전자 상거래 회사에서 가격 정보를 도난할 수 있습니다. 스크레이퍼 봇은 대상 애플리케이션에서 대량의 데이터를 복사할 수 있습니다. Rate Limiting은 데이터 스크래핑을 감지하고 차단합니다.
<Rate Limiting의 작동 방식>
Rate Limiting은 응용 프로그램 내에서 작동하며 웹 서버에서 작동하지 않습니다. Rate Limiting은 일반적으로 요청의 출처인 IP 주소를 추적하고 요청 사이의 경과된 시간을 식별하는 것을 포함합니다. IP 주소는 응용 프로그램이 각 요청을 누가 보냈는지 식별하는 주요 방법입니다.
Rate Limiting 솔루션은 특정 IP 주소에서의 모든 요청 사이의 경과된 시간을 측정하고 설정된 시간 내에 수행된 요청의 수를 추적하여 작동합니다. 지정된 시간 내에 한 IP 주소가 너무 많은 요청을 한 경우 Rate Limiting 솔루션은 해당 IP 주소를 속도 제한하고 다음 시간대에 해당 요청을 수행하지 않습니다.
Rate Limited 응용 프로그램은 사용자가 요청을 너무 자주 보내면 개별적으로 줄이라고 할 수 있습니다. 이는 경찰관이 제한 속도를 초과하는 운전자를 멈추거나 부모가 아이들에게 짧은 기간 동안 너무 많은 설탕을 먹지 말라고 하는 것과 유사합니다.
<Rate Limit의 유형 >
관리자는 제한 속도를 설정할 때 다양한 매개변수 및 방법을 정의할 수 있습니다. 조직의 선택한 Rate Limiting 기술은 목표 및 필요한 제한 수준에 따라 달라집니다.
Rate Limiting의 세 가지 주요 접근 방법에 대해 알아보겠습니다.
사용자 제한 속도: 이것은 가장 많이 쓰이는 제한 속도 방법입니다. 주어진 사용자가 제한된 기간 동안 수행한 요청 수를 식별합니다. 일반적으로 사용자의 IP 주소 또는 API 키를 추적하여 수행됩니다. 지정된 제한 속도를 초과하는 사용자는 제한된 시간대가 재설정될 때까지 응용 프로그램이 더 이상의 요청을 거부하도록 유도됩니다. 또는 사용자는 개발자에게 제한 속도를 높이도록 문의할 수 있습니다.
지리적 제한 속도: 개발자는 지정된 지리적 영역에 대해 특정 시간에 대한 각 지역의 제한 속도를 설정하여 응용 프로그램을 추가로 보호할 수 있습니다. 예를 들어, 개발자는 특정 지역의 사용자가 자정부터 오전 9시까지 덜 활동적일 것으로 예상하고 이 시간대에 낮은 제한 속도를 정의할 수 있습니다. 이러한 접근 방식은 의심스러운 트래픽을 방지하고 공격 위험을 더 줄입니다.
서버 제한 속도: 개발자는 응용 프로그램의 일부를 처리하기 위해 특정 서버를 정의하는 경우 서버 수준에서 제한 속도를 설정할 수 있습니다. 이 접근 방식은 더 많은 유연성을 제공하여 사용자가 자주 사용하는 서버에서 제한 속도를 높이고 활동이 적은 서버에서 트래픽 제한을 낮출 수 있습니다.
< Rate Limiting에 사용되는 알고리즘>
Fixed-window Rate Limiting
Fixed-window Rate Limiting 알고리즘은 주어진 시간대(창) 동안 허용되는 요청 수를 제한합니다. 예를 들어, 서버의 제한 속도 구성 요소는 1분에 최대 200개의 API 요청을 허용하는 알고리즘을 구현할 수 있습니다. 지정된 시간부터 고정된 시간대가 시작됩니다. 서버는 9:00부터 9:01까지 200개 이상의 요청을 제공하지 않을 것이며, 창은 9:01에 재설정되어 9:02까지 다른 200개의 요청을 허용합니다.
개발자는 사용자 또는 서버 수준에서 Fixed-window Rate Limiting 알고리즘을 구현할 수 있습니다. 사용자 수준에서 알고리즘을 구현하면 각 사용자를 분당 200개의 요청으로 제한합니다. 반면, 서버 수준 알고리즘은 서버를 제한하므로 모든 사용자가 함께 최대 1분에 200개의 요청을 할 수 있습니다.
Leaky Bucket Rate Limiting
Leaky bucket rate limiting 알고리즘은 지정된 시간대에 의존하지 않기 때문에 고정 창 알고리즘과 다릅니다. 시간을 고려하지 않고 요청 대기열의 고정된 길이에 집중합니다. 서버는 먼저 도착한 순서대로 요청을 처리합니다. 새 요청은 대기열의 뒷부분에 추가됩니다. 대기열이 가득 차 있을 때 새 요청이 도착하면 서버는 해당 요청을 삭제합니다.
Sliding-window Rate Limiting
Sliding-window Rate Limiting알고리즘은 시작 시점을 제외하고 고정 창 알고리즘과 유사합니다. Sliding-window Rate Limiting에서 시간대는 사용자가 새 요청을 할 때만 시작됩니다. 예를 들어, 첫 번째 요청이 오전 9시 00분 24초에 도착하고(제한 속도는 분당 200회인 경우), 서버는 9시 01분 24초까지 최대 200개의 요청을 허용합니다.
Sliding-window Rate Limiting 알고리즘은 고정 창 rate limiting에 영향을 미치는 문제를 해결하는 데 도움이 됩니다. 또한, 누수 버킷 rate limiting이 직면한 굶주림 문제를 더 유연성을 제공함으로써 완화합니다.
<Imperva와 Rate Limiting >
Imperva 고급 보트 보호는 웹 사이트, 모바일 앱 및 API에 대한 rate limiting을 강제하고 모든 접근 지점에서 비즈니스 로직 공격을 방지할 수 있습니다. 온라인 사기를 중지하기 위해 계정 탈취 또는 경쟁 가격 스크랩을 통한 보트 트래픽을 원활하게 볼 수 있습니다.
보트 방지 이외에도 Imperva는 응용 프로그램, API 및 마이크로서비스에 대한 포괄적인 보호를 제공합니다:
웹 응용 프로그램 방화벽 - 웹 트래픽의 세계적인 분석으로 공격을 방지합니다.
런타임 응용 프로그램 자체 보호 (RASP) - 응용 프로그램 런타임 환경에서의 실시간 공격 감지 및 방지는 응용 프로그램이 이동하는 곳에 따라 이동합니다. 외부 공격 및 주입을 차단하고 취약성 백로그를 줄입니다.
API 보안 - 자동 API 보호를 통해 API 엔드포인트가 게시되는 대로 보호합니다. 응용 프로그램을 악용으로부터 보호합니다.
DDoS 방어 - 엣지에서 공격 트래픽을 차단하여 보증된 가동 시간과 성능 영향 없이 비즈니스 연속성을 보장합니다. 온 프레미스 또는 클라우드 기반 자산을 안전하게 보호합니다. AWS, Microsoft Azure 또는 Google Public Cloud에 호스팅되는 경우와 관계없이.
공격 분석 - 응용 프로그램 보안 스택 전반에 걸쳐 기계 학습 및 도메인 전문 지식으로 완전한 가시성을 제공하여 소음에서 패턴을 확인하고 응용 프로그램 공격을 감지하여 공격 캠페인을 격리하고 방지할 수 있습니다.
클라이언트 측 보호 - 제공업체 체인 사기, 데이터 유출 및 클라이언트 측 공격 위험을 줄이기 위해 타사 JavaScript 코드에 대한 가시성 및 제어를 확보합니다.
오늘은 ACID 트랜잭션과 Rate-Limiting 개념에 대해 알아보았습니다.
두 개념에 대한 중요성과 활용하기 위한 방법을 학습하는데에 도움이 되었으면 좋겠습니다!