Availability는 시스템이 항상 정상적으로 작동하며, 사용 가능한 상태를 유지하는 능력을 의미합니다. 즉, **"서비스가 항상 사용 가능하게 유지되는가?"**를 측정하는 지표입니다.
Availability의 주요 특징
주요 목표
서비스가 중단되지 않고 사용 가능한 상태를 유지.
사용자 요청에 대해 항상 응답 가능.
중요한 설계 요소
장애 복구(Recovery): 장애 발생 시 빠르게 복구. 예: 장애가 난 인스턴스를 자동으로 교체.
중복 구성(Redundancy): 중요한 시스템은 여러 복사본을 유지. 예: 여러 AZ(가용 영역)에서 서버 실행.
무중단 배포: 서비스 중단 없이 업데이트 적용.
Availability의 측정
**Uptime(가동 시간)**으로 측정. 예: 99.9% 가용성은 1년 동안 약 8시간 45분의 다운타임 허용.
예시
Availability가 높은 시스템: 금융 서비스가 24/7로 항상 거래 가능.
AWS 서비스: Multi-AZ RDS, ELB(Elastic Load Balancer)로 부하 분산.
Scalability와 Availability의 차이점
Scalability (확장성)
Availability (가용성)
정의
시스템의 처리 능력을 유지하거나 확장하는 능력.
시스템이 항상 정상 작동하며 사용 가능한 상태를 유지하는 능력.
목표
증가하는 부하(사용자, 데이터 등)에 유연하게 대응.
서비스 중단 없이 항상 작동 가능.
초점
성능과 처리량 유지 또는 향상.
안정성과 중단 없는 서비스 제공.
주요 설계 요소
부하 분산, 자동 확장(Auto Scaling), 데이터 파티셔닝.
장애 복구, 중복 구성, 무중단 배포.
예시
트래픽 증가 시 인스턴스 추가로 대응.
장애가 발생해도 빠르게 복구하여 사용자에게 영향을 최소화.
Scalability와 Availability의 관계
Scalability는 Availability를 지원: 트래픽 증가에 대응하지 못하면 서비스가 중단될 수 있으므로 확장성이 가용성을 높이는 데 도움.
Availability는 Scalability를 필요로 함: 가용성을 유지하려면 트래픽 증가 시 확장이 가능해야 함.
추가적인 고려 사항
Trade-off
Scalability와 Availability를 동시에 극대화하기 어렵기 때문에 우선순위를 설정해야 함. 예: 초기에 가용성보다는 확장성에 초점을 맞출 수 있음.
AWS에서의 구현
Scalability:
Auto Scaling으로 EC2 인스턴스 수 조절.
DynamoDB의 읽기/쓰기 용량 자동 조정.
Availability:
ELB로 다중 인스턴스에 부하 분산.
Multi-AZ RDS로 장애 복구 및 중단 방지.
실제 사례
Netflix:
Scalability: 글로벌 사용자 증가에 맞춰 서버를 확장.
Availability: 장애 발생 시에도 스트리밍 서비스가 끊기지 않도록 설계.
쉽게 이해하기
Scalability는 "더 많은 손님을 받을 수 있는 큰 식당"을 만드는 것.
Availability는 "식당이 항상 열려 있고 손님이 들어올 수 있는 상태"를 유지하는 것.
ELB (Elastic Load Balancer)
📌 **ELB (Elastic Load Balancer)**는 AWS에서 제공하는 트래픽 분산 서비스로, 애플리케이션의 가용성과 확장성을 높이는 역할을 합니다.
ELB는 들어오는 요청(HTTP, HTTPS, TCP 등)을 여러 EC2 인스턴스나 컨테이너로 자동으로 균등하게 분배합니다. 쉽게 말해, 서버 앞에서 교통 정리를 해주는 신호등 같은 역할을 합니다. 🚦
ELB의 주요 특징
트래픽 분산
사용자 요청을 여러 서버로 분산하여 트래픽 부하를 줄이고 성능을 최적화.
고가용성 지원
서버 중 일부가 다운되더라도 정상 작동하는 서버로 트래픽을 전달하여 서비스 중단 방지.
확장성
서버 수가 늘어나거나 줄어드는 상황에서도 자동으로 적응 가능.
자동 상태 검사
연결된 인스턴스(서버)의 상태를 지속적으로 모니터링하여 정상적인 인스턴스에만 트래픽 전달.
HTTPS/TLS 지원
암호화된 트래픽(HTTPS)을 처리하여 보안을 강화.
ELB의 유형
AWS에서는 애플리케이션과 트래픽 유형에 따라 4가지 ELB 유형을 제공합니다.
특징
사용 사례
ALB (Application Load Balancer)
- HTTP/HTTPS 트래픽 분산. - URL, 호스트 이름 기반의 정교한 라우팅 지원. - OSI 모델 7계층에서 동작 - 컨테이너화된 애플리케이션과 연동하여 사용 가능
웹 애플리케이션, REST API 등.
NLB (Network Load Balancer)
- TCP/UDP 트래픽 분산. - 매우 낮은 지연 시간과 고속 성능 제공. - OSI 모델 4계층에서 동작
실시간 애플리케이션, 게임 서버, IoT.
CLB (Classic Load Balancer)
- 초창기 ELB. - HTTP/HTTPS, TCP/UDP 트래픽을 처리 - OSI 모델 4~7계층에서 동작 - 초창기 모델인 만큼 잘 사용 안한다.
단순한 트래픽 분산 작업(구형 서비스에 주로 사용).
Gateway Load Balancer
- 네트워크 트래픽을 특정 보안 장치(방화벽, IDS/IPS 등)로 라우팅.
보안 애플리케이션 트래픽 관리.
ELB의 주요 사용 사례
트래픽 부하 분산
웹 서버 또는 애플리케이션 서버 간 요청을 분산하여 성능 최적화.
서비스 중단 방지
서버 장애 발생 시 정상 상태의 서버로 트래픽을 자동 전달.
HTTPS 지원
SSL/TLS 인증서를 로드 밸런서에 설치해 보안 트래픽 처리.
자동 확장(Auto Scaling)과 결합
서버가 추가되거나 삭제될 때 자동으로 인스턴스를 로드 밸런서에 등록.
ELB의 주요 구성 요소
리스너 (Listener)
로드 밸런서가 들어오는 요청을 수신하는 구성 요소.
프로토콜과 포트 번호(예: HTTP:80, HTTPS:443)를 설정.
대상 그룹 (Target Group)
트래픽이 분배될 EC2 인스턴스, 컨테이너, 또는 IP 주소의 집합.
상태 검사 (Health Check)
대상의 상태를 주기적으로 확인하여, 정상 상태인 대상에만 트래픽 전달.
ELB의 장단점
장점
단점
고가용성 제공: 서버 장애 시 자동 대응
초기 설정이 복잡할 수 있음.
확장성 지원: 증가하는 트래픽에 자동 대응
트래픽 분산 정책에 따라 추가 비용 발생 가능.
보안 강화: HTTPS/TLS 트래픽 지원
복잡한 라우팅 규칙이 필요한 경우 관리가 어려울 수 있음.
유연한 라우팅: URL, 호스트 이름 기반 라우팅 가능 (ALB).
특정 유형에 따라 선택과 설정이 요구됨.
ELB의 동작 과정
클라이언트 요청이 ELB에 도달.
리스너가 요청을 수신.
ELB는 요청을 **상태가 양호한 대상 그룹(Target Group)**의 인스턴스에 분배.
인스턴스가 요청을 처리한 뒤, 클라이언트에 응답.
ELB와 Auto Scaling의 관계
ELB는 트래픽을 분산하여 서버의 부하를 줄이고,
Auto Scaling은 트래픽 증가/감소에 따라 서버를 자동으로 추가하거나 제거. 이 둘을 결합하면 높은 가용성과 확장성을 동시에 확보할 수 있습니다.
쉽게 이해하기
**ELB는 "트래픽 신호등"**입니다. 클라이언트 요청이 서버로 몰리지 않도록 여러 서버로 교통정리를 해줍니다. 고장 난 서버를 자동으로 제외하고, 정상 작동 중인 서버로만 트래픽을 보내줍니다.
Application Loadbalancer 사용해보기
#!/bin/bash# 스크립트가 Bash 쉘에서 실행되도록 지정하는 선언.
apt-get update
# 패키지 관리자(Apt)를 통해 패키지 목록을 업데이트하여 최신 정보를 가져옴.
apt-get install -y nginx
# Nginx 웹 서버를 설치. "-y"는 설치 중 사용자 입력을 자동으로 승인.
cat <<EOF > /var/www/html/index.html
# "cat" 명령을 사용하여 HTML 파일을 작성.
# "<<"와 "EOF"를 사용하여 여러 줄의 텍스트를 하나의 파일로 입력.
# 이 텍스트는 "/var/www/html/index.html" 파일에 저장됨.
<!DOCTYPE html>
<html>
<head>
<title>Welcome to Nginx</title>
</head>
<body>
<h1>Hello World!</h1>
<p>AWS deployed by Me!</p>
<p>private ip is $(hostname -f)</p>
</body>
</html>
EOF
# HTML 파일 작성 완료.
# $(hostname -f)는 현재 인스턴스의 호스트 이름(프라이빗 IP 포함)을 출력하여 HTML 페이지에 포함.
sudo systemctl start nginx
# Nginx 서비스를 시작.
# "sudo"를 사용하여 관리자 권한으로 실행.
📌 Amazon Elastic Block Store (EBS)는 Amazon EC2 인스턴스에 연결할 수 있는 블록 수준 스토리지 볼륨으로, 데이터의 지속성과 고가용성을 제공하는 AWS 서비스입니다. EBS는 네트워크 기반 스토리지로, EC2 인스턴스와 연결되어 작동하며, 데이터를 안전하게 저장하고 백업할 수 있습니다. = AWS의 USB라고 생각하면 된다. 실제 USB처럼 다른 인스턴스에 갖다 꽂을 수도 있다. 당연히 인스턴스 1개에 여러 EBS가 연결될 수도 있다.
AWS 데이터센터의 독립적인 물리적 위치로, 같은 리전(region) 안에서 장애(네트워크 문제로 서버스가 중단되는 상황)로부터 분리된 데이터센터라고 생각하면 됩니다. 쉽게 말해, 한 리전에 여러 개의 안전한 건물이 있다고 보면 돼요!
우리가 이 데이터센터의 일부를 빌려서 사용하는 게 바로 EC2 인스턴스입니다.
Region(리전)
AWS가 전 세계에 위치한 데이터 센터 그룹을 묶어 둔 것입니다. 쉽게 말해, 지리적으로 떨어진 AWS의 데이터센터 묶음으로, 미국, 한국, 일본 같은 지역마다 리전이 하나씩 있습니다.
예를 들어:
서울 리전(ap-northeast-2): 한국의 AWS 데이터센터 그룹.
도쿄 리전(ap-northeast-1): 일본의 AWS 데이터센터 그룹.
각 리전은 서로 독립적으로 운영되며, 데이터와 리소스는 기본적으로 리전 간에 공유되지 않습니다. 그래서 데이터를 특정 국가나 지역에 저장해야 하는 규정을 지킬 때 유용합니다!
플러그 앤 플레이 (Plug and Play)
EBS는 인스턴스의 USB 메모리처럼 동작.
하나의 EC2 인스턴스에서 분리해 다른 인스턴스에 연결 가능.
다중 볼륨 연결 가능
하나의 EBS는 하나의 인스턴스에만 연결 가능.
하지만 하나의 인스턴스에는 여러 개의 EBS를 연결할 수 있어 스토리지 확장 가능.
EBS의 주요 사용 사례
운영 체제 저장
EC2 인스턴스의 루트 디스크로 사용하여 OS 설치.
데이터베이스 스토리지
MySQL, PostgreSQL과 같은 데이터베이스 저장소로 활용.
애플리케이션 데이터 저장
로그 데이터, 파일 시스템 또는 응용 프로그램 데이터를 저장.
백업 및 복구
EBS 스냅샷을 통해 데이터 백업 및 복구 용도로 활용.
고성능 분석 작업
머신러닝, 빅데이터 분석 등 IOPS가 중요한 워크로드에 적합.
EBS의 유형
스토리지 유형
특징
사용 사례
범용 SSD (gp3, gp2)
낮은 지연 시간, 다양한 워크로드에 적합.
웹 서버, 소규모 데이터베이스
프로비저닝된 IOPS SSD
높은 IOPS와 낮은 지연 시간 제공.
고성능 데이터베이스, 대규모 트랜잭션 처리
스루풋 최적화 HDD
대규모 순차적 읽기/쓰기 작업에 적합.
로그 처리, 데이터 웨어하우스
콜드 HDD
비용 효율적인 대용량 스토리지.
아카이브 데이터, 잘 사용하지 않는 데이터
EBS와 인스턴스 저장소(Instance Store) 비교
특징
EBS
인스턴스 저장소
데이터 지속성
EC2 종료 후에도 데이터 유지
EC2 종료 시 데이터 삭제
백업 가능 여부
스냅샷을 통해 백업 가능
백업 불가
가용성
특정 AZ에서 사용 가능, 다른 AZ로 복제 필요
EC2 인스턴스에만 종속
사용 사례
데이터베이스, 로그, 애플리케이션 데이터
캐시, 임시 데이터 처리
EBS의 장단점
장점
단점
데이터 지속성과 안정성 제공
추가 비용 발생 (스토리지 용량 및 IOPS 기준 과금)
스냅샷을 통한 백업 및 복구 가능
리전 간 이동이 불편 (스냅샷 복사 필요)
다양한 스토리지 옵션 제공
고성능 IOPS 요구 시 비용 증가 가능
플러그 앤 플레이 방식으로 유연한 관리 가능
AZ 내에서만 사용 가능
쉽게 이해하기
EBS는 EC2 인스턴스의 USB 메모리 같은 역할을 합니다.
하드디스크처럼 데이터를 저장할 수 있으며, EC2 서버를 꺼도 데이터는 유지됩니다.
한 서버에서 떼어 다른 서버에 붙일 수 있고, 백업(스냅샷)을 통해 안전하게 데이터를 보호할 수 있습니다.
추가 정보
EBS 스냅샷 활용
데이터를 백업하거나 다른 가용 영역(AZ) 또는 리전으로 이동할 때 사용.
비용 최적화
워크로드에 맞는 스토리지 유형 선택(예: 범용 SSD vs 콜드 HDD).
스냅샷 데이터를 주기적으로 정리하여 저장 비용 절감.
EBS snapshot
📌 EBS(Elastic Block Store) Snapshot은 EBS 볼륨의 데이터를 백업하고 복원할 수 있는 AWS 기능입니다. 스냅샷은 EBS 볼륨의 데이터를 복사하여 Amazon S3에 저장하며, 필요할 때 데이터를 복원하거나 새로운 볼륨으로 생성할 수 있습니다.
EBS Snapshot의 주요 특징
백업 및 복원
EBS 볼륨의 데이터를 백업하고, 특정 시점으로 복원할 수 있음.
스냅샷에서 새로운 볼륨을 생성하여 데이터 복구 가능.
증분 방식 저장
첫 스냅샷은 EBS 볼륨의 전체 데이터를 저장.
이후 스냅샷은 이전 스냅샷과의 변경된 데이터만 저장하여 저장 공간과 비용 절감.
Amazon S3에 저장
스냅샷 데이터는 Amazon S3에 안전하게 보관되며, 높은 내구성을 제공.
지역 간 복사 가능
스냅샷을 다른 AWS 리전으로 복사하여 데이터 이동 및 마이그레이션에 활용.
자동 스케줄링
스냅샷 생성 작업을 자동화하여 주기적으로 백업 가능. → AWS Backup 또는 Data Lifecycle Manager(DLM)를 사용.
EBS Snapshot의 주요 사용 사례
데이터 백업 및 복원
스냅샷을 사용하여 데이터를 정기적으로 백업하고, 장애 시 이전 상태로 복구 가능.
볼륨 확장
기존 EBS 볼륨의 크기를 확장하고 싶을 때 스냅샷을 기반으로 새로운 볼륨을 생성 후 데이터 마이그레이션.
📌 AWS란? AWS(Amazon Web Services)는 아마존이 제공하는 클라우드 컴퓨팅 플랫폼으로, 전 세계적으로 분산된 데이터 센터를 통해 고객에게 IT 인프라 서비스를 제공합니다. 사용자는 AWS를 통해 필요한 리소스를 유연하고 효율적으로 설정, 관리할 수 있습니다.
AWS 주요 서비스 카테고리
컴퓨팅: EC2(Elastic Compute Cloud), Elastic Beanstalk 등
데이터베이스: RDS(Relational Database Service) 등
스토리지: S3(Simple Storage Service), EBS(Elastic Block Store) 등
네트워킹: VPC(Virtual Private Cloud), CloudFront, Route 53 등
보안: IAM(Identity and Access Management) 등
On-Premise
📌 On-premise는 조직 내부에 물리적으로 설치된 서버를 의미합니다. 이러한 서버는 해당 조직의 IT 팀이 직접 관리 및 유지보수하며, 주로 중요한 데이터와 애플리케이션을 호스팅하는 데 사용됩니다.
On-premise vs. 클라우드 서비스 비교
On-premise:
서버가 조직 내에 위치
자체 관리 및 유지보수 필요
초기 설치 비용이 높음
클라우드:
외부 데이터 센터에서 호스팅
클라우드 제공 업체가 관리
유연한 비용 구조
추가로 알아야 할 정보
AWS의 장점:
확장성: 필요에 따라 리소스를 쉽게 조정 가능
비용 효율성: 사용한 만큼만 비용 지불
글로벌 접근성: 다양한 지역에 배치된 데이터 센터 사용
On-premise의 장점:
데이터 보안: 민감한 데이터를 조직 내에서 직접 관리
맞춤형 인프라: 비즈니스 요구에 따라 시스템 설계 가능
사용 이유: 조직의 특성과 요구에 따라 클라우드(AWS)와 On-premise를 선택하거나, 두 가지를 혼합하여 하이브리드 환경을 구축하기도 합니다.
@Repository
public interface ExampleRepository extends JpaRepository<ExampleEntity, Long> {
@Lock(LockModeType.PESSIMISTIC_WRITE)
@Query("SELECT e FROM ExampleEntity e WHERE e.id = :id")
ExampleEntity findByIdWithLock(@Param("id") Long id);
}
동시에 여러 노드(서버)가 공유 자원에 접근하려는 상황에서 데이터의 무결성과 일관성을 보장.
2. 특징
멀티 노드 환경:
여러 노드가 동일한 자원에 접근 가능.
분산 락을 통해 자원을 독점적으로 사용할 노드를 제어.
데이터 일관성 보장:
데이터의 충돌 방지 및 무결성 유지.
중앙 관리:
락 상태를 중앙에서 관리하거나 분산 환경에서 합의 프로토콜을 사용.
3. 동작 원리
락 생성:
특정 자원에 대해 락 생성 요청.
락이 성공하면 해당 노드는 자원을 독점적으로 사용 가능.
락 유지:
락을 일정 시간 동안 유지.
필요 시 갱신(Renewal) 가능.
락 해제:
자원 사용이 끝나면 락을 해제.
타임아웃으로 자동 해제될 수도 있음.
4. 분산 락 구현 방식
4.1 데이터베이스 기반
방법: 데이터베이스 테이블에 락 상태를 저장.
SQL 예제:
-- 락 생성INSERTINTO distributed_lock (resource, lock_time) VALUES ('RESOURCE_ID', NOW());
-- 락 확인SELECT*FROM distributed_lock WHERE resource ='RESOURCE_ID';
-- 락 해제DELETEFROM distributed_lock WHERE resource ='RESOURCE_ID';
장점:
별도 도구 없이 쉽게 구현 가능.
트랜잭션과 연동하여 락 관리.
단점:
성능 저하(데이터베이스 부하 증가).
대규모 시스템에서는 비효율적.
4.2 Redis 기반
방법: Redis의 SETNX 명령어를 사용하여 락 생성.
예제:
# 락 생성
SET resource:lock "LOCKED" NX PX 10000
# 락 확인
GET resource:lock
# 락 해제
DEL resource:lock
장점:
빠른 속도.
TTL(Time-To-Live) 설정으로 자동 해제 가능.
단점:
단일 노드 Redis 사용 시 SPOF(Single Point of Failure) 발생 가능.
클러스터 환경에서는 Redlock 알고리즘 필요.
4.3 ZooKeeper 기반
방법: 분산 락의 상태를 ZNode에 저장하여 관리.
예제:
# ZNode 생성 (락 획득)
create /locks/resource
# 락 해제delete /locks/resource
장점:
강력한 일관성 보장.
분산 환경에 최적화.
단점:
설정 및 관리 복잡.
ZooKeeper 설치 필요.
5. Redlock 알고리즘 (Redis 기반 분산 락)
Redis 클러스터 환경에서 락의 일관성을 보장하는 알고리즘.
여러 Redis 노드에 동일한 키로 락 생성 요청.
과반수 이상의 노드에서 락 성공 시 락 획득.
TTL을 설정하여 자동으로 락이 해제되도록 설정.
락 해제 시 모든 노드에서 락 해제.
6. 장단점
장점
단점
데이터 충돌 및 중복 작업 방지.
락 구현 및 관리 복잡도 증가.
고성능 분산 환경에서 데이터 무결성 보장.
락 생성/해제 시 네트워크 지연으로 인한 성능 저하 가능.
다양한 도구를 활용한 구현 가능(데이터베이스, Redis, ZooKeeper 등).
잘못된 락 설정 시 데드락 발생 가능.
7. 분산 락 사용 사례
동시에 한 번만 실행해야 하는 작업:
예: 배치 처리, 데이터 마이그레이션.
중복 실행 방지:
예: 주문 처리, 결제 처리.
리소스 공유:
예: 파일 업로드/다운로드, 재고 관리.
8. 학습하면 좋은 추가 주제
락 컨텐츠 관리 전략:
TTL 설정, 자동 해제 로직 구현.
ZooKeeper와 Redis의 비교:
각 기술의 장단점 및 사용 사례 분석.
분산 시스템에서의 일관성 모델:
강한 일관성, 최종적 일관성(Final Consistency) 개념 이해.
Redlock 알고리즘 심화:
클러스터 환경에서의 락 일관성 보장 방법.
격리 수준
트랜잭션 격리 수준 (Transaction Isolation Levels)
1. 트랜잭션 격리 수준이란?
트랜잭션 간의 상호작용에서 발생할 수 있는 데이터 충돌 문제를 방지하기 위해 데이터베이스가 제공하는 동시성 제어 메커니즘.
각 격리 수준은 데이터 일관성과 동시성 성능 간의 트레이드오프를 제공.
2. 주요 격리 수준과 특징
격리 수준
Dirty Read
Non-Repeatable Read
Phantom Read
특징
READ UNCOMMITTED
허용
허용
허용
- 커밋되지 않은 데이터를 읽을 수 있음(Dirty Read). - 가장 낮은 격리 수준으로 동시성 성능은 높지만 데이터 일관성이 낮음.
READ COMMITTED
방지
허용
허용
- 커밋된 데이터만 읽을 수 있음. - Oracle, SQL Server의 기본 격리 수준. - Non-Repeatable Read 가능.
REPEATABLE READ
방지
방지
허용
- 동일 트랜잭션 내에서 항상 같은 데이터 읽기 보장. - MySQL(InnoDB)의 기본 격리 수준.
SERIALIZABLE
방지
방지
방지
- 모든 트랜잭션을 순차적으로 실행하는 것처럼 동작. - 가장 높은 격리 수준으로, 동시성 성능이 낮지만 데이터 일관성 보장.
3. 주요 개념
Dirty Read:
다른 트랜잭션이 아직 커밋되지 않은 변경 사항을 읽는 것.
예시: A 트랜잭션이 데이터를 수정하고 커밋하지 않은 상태에서 B 트랜잭션이 수정된 데이터를 읽음.
Non-Repeatable Read:
한 트랜잭션에서 같은 데이터를 두 번 읽었을 때, 값이 달라지는 현상.
원인: 다른 트랜잭션에서 데이터를 수정하고 커밋한 경우.
Phantom Read:
한 트랜잭션에서 동일한 조건으로 데이터를 조회했을 때, 새로운 데이터가 추가되거나 삭제되는 현상.
원인: 다른 트랜잭션에서 데이터를 추가/삭제한 경우.
4. 격리 수준별 예제
4.1 READ UNCOMMITTED
-- A 트랜잭션START TRANSACTION;
UPDATE accounts SET balance = balance -100WHERE id =1;
-- B 트랜잭션START TRANSACTION;
SELECT balance FROM accounts WHERE id =1; -- Dirty Read 발생
4.2 READ COMMITTED
-- A 트랜잭션START TRANSACTION;
UPDATE accounts SET balance = balance -100WHERE id =1;
-- B 트랜잭션START TRANSACTION;
SELECT balance FROM accounts WHERE id =1; -- 커밋되지 않았으므로 읽을 수 없음
4.3 REPEATABLE READ
-- A 트랜잭션START TRANSACTION;
SELECT balance FROM accounts WHERE id =1; -- 1000
UPDATE accounts SET balance = balance -100WHERE id =1;
-- B 트랜잭션START TRANSACTION;
SELECT balance FROM accounts WHERE id =1; -- A 트랜잭션의 변경 사항 보이지 않음
4.4 SERIALIZABLE
-- A 트랜잭션START TRANSACTION;
SELECT balance FROM accounts WHERE id =1;
-- B 트랜잭션START TRANSACTION;
SELECT balance FROM accounts WHERE id =1; -- 대기 상태 (A 트랜잭션 종료 후 실행)
