DB 동시성 처리, 낙관적 Lock & 비관적 Lock, 왜 프론트엔드 SSL만으로는 안 될까?
SSL 백엔드 처리하는 이유와 동시성 처리 낙관적 락과 비관적 락을 알아보자.
Nov 26, 2024
동시성 처리
이번에 좋은 계기로 키워드를 받아 공부해보니 진짜 많은 것이 내제 되어 공부할게 이렇게 많구나 싶었다… 지금부터 하나하나 알아본 것을 정리해본다.
배선임님 : 자 봐봐 만약에 시간 mm:ss 까지 똑같은 데이터가 들어오면 어떻게 처리할꺼야?이러한 질문을 받으니 궁금했다… 어? 진짜 어떻게 처리하지?
일단 내가 생각하는
Transaction엔 저번 글처럼 데이터 처리 단위를 의미한다고 생각한다. 근데 공부하다보니 Lock이라는 단어가 나왔다.Lock 이란?
- 락은 여러 프로세스나 스레드가 동시에 동일한 데이터나 자원을 수정하지 못하도록 보호하는 메커니즘입니다.
- 주로 데이터베이스나 멀티스레드 환경에서 데이터의 무결성과 경쟁 조건(Race Condition)을 방지하기 위해 사용됩니다.
재밋었다. 일단 어떤 처리를 할때 잠궈 놓고
동기적으로 일을 시키는 느낌~?그럼? 더 깊게 들어가보니 나왔던 개념이 바로 낙관적인 lock과 비관적인 lock이 있었다…
낙관적 vs 비관적 락
특징 | 낙관적 락 | 비관적 락 |
가정 | 충돌이 드물다고 가정 | 충돌이 자주 발생한다고 가정 |
작동 방식 | 충돌 발생 여부를 나중에 체크 | 작업 중 충돌을 미리 방지 |
성능 | 읽기 작업이 많을수록 성능이 좋음 | 락 대기 시간이 길면 성능 저하 가능 |
충돌 처리 | 충돌 발생 시 재시도 필요 | 충돌을 사전에 방지 |
사용 사례 | 읽기가 많고 쓰기가 적은 시스템 (예: 조회 위주) | 쓰기가 많고 충돌 가능성이 높은 시스템 (예: 금융) |
낙관적 lock 같은 경우엔 읽어보니 애플리케이션 단에서 lock을 하는 개념이었고비관적 lock 같은 경우엔 데이터베이스 트랜잭션 lock 개념이었다.이게 조금 어렵게 생각하지말고 쉽게 생각하면
난관적 락: 신뢰 기반의 접근법
- 비유:
- 당신은 회의실이 비어 있을 거라 "낙관적으로 생각"하고 그냥 들어가서 사용합니다.
- 나중에 퇴실할 때, 담당자가 회의실 사용 시간을 확인하고 겹친 예약이 있었는지 체크합니다.
- 만약 겹친 사람이 있었다면, 당신은 "예약 겹침 오류"를 받고 다시 예약해야 합니다.
당신이 친구들과 회의실을 예약하고 싶다고 가정해봅시다.
- 핵심 개념:
- 충돌이 일어나지 않을 거라 "낙관적으로" 처리.
- 애플리케이션 단에서 나중에 "겹치지 않았는지" 확인하는 방식.
비관적 락: 확실한 보호
- 비유:
- 당신이 예약을 넣는 순간, 담당자가 회의실 문을 잠가버립니다(= 락).
- 다른 사람이 회의실을 사용하려 하면 "잠겼다"는 메시지가 나오고, 당신이 사용을 끝낸 후 문을 열어줄 때까지 기다려야 합니다.
- 이렇게 하면 절대 겹치는 일이 없습니다.
당신이 회의실을 예약하고 싶은데, 이번엔 "겹치는 일이 절대 없어야" 한다고 가정하게 된다.
- 핵심 개념:
- 충돌 가능성이 높은 상황에서 "비관적으로" 접근.
- 미리 데이터베이스에서 락을 걸어 다른 작업을 차단.
그럼 첫번째 질문인
배선임님 : 자 봐봐 만약에 시간 mm:ss 까지 똑같은 데이터가 들어오면 어떻게 처리할꺼야?로 다시돌아온다면 나는 비관적 락을 적용해서 하나의 처리가 들어오면 비동기로 순번으로 처리하도록 하는게 올바른 방향이 아닐까~?
배선임님 : 그럼 누가? 어느 부분에서 락킹을 거는데?WAS에서 락 관리의 단점 → 난 was에서 거나~? 했는데 그럼 만약 여러대의 was라면? 그….래!? 그럼 다른 was는 락킹이 됫는지를 모른다… 그래 이게 단점이다 결국 데이터 베이스에서 락킹을 해버리는게 맞다.. .그렇다!
결국
SQL로 보내서 데이터베이스에서 락을 하던 메모리 Redis를 사용해서 락을 걸어도 된다.. 오~- 안정성 우선이면 SQL (데이터베이스).
- 속도와 확장성이 중요하면 Redis (메모리).
왜 프론트엔드 SSL만으로는 안 될까?
(1) 내부 네트워크도 안전하지 않을 수 있음
- 내부 네트워크라고 해서 100% 안전하지 않습니다.
- 내부 공격(예: 악의적인 내부 직원).
- 네트워크 상의 데이터 스니핑 가능성.
- 따라서 백엔드 서버로 전달되는 데이터도 암호화해야 안전합니다.
(2) 중간에 추가 서버(CDN, 로드밸런서)가 있으면?
- CDN이나 로드밸런서는 사용자의 요청을 백엔드로 전달하는 중계 역할을 합니다.
- 이 중계 서버와 백엔드 간 통신이 암호화되지 않으면 중간에서 데이터가 노출될 수 있습니다.
(3) 규제 및 표준 준수
- 많은 보안 규제(예: GDPR, PCI-DSS)는 종단 간 암호화(End-to-End Encryption)를 요구합니다.
- 클라이언트 ↔ 프론트엔드 ↔ 백엔드 모두 암호화해야 규제를 준수할 수 있습니다.
DB 옵티마이저
SQL 쿼리(데이터베이스 명령어)를 가장 빠르고 효율적인 방법으로 실행할 수 있도록 계획을 세우는 역할을 합니다.
옵티마이저는 왜 필요할까?
데이터베이스에는 데이터가 엄청 많다…
어떤 경로로 데이터를 가져오는 게 제일 빠를까?를 고민한다면?
- 옵티마이저가 이런 질문에 대해 가장 좋은 답(경로)을 골라주는 역할을 합니다.
- 이 과정을 쿼리 최적화(Query Optimization)라고 한다..
옵티마이저는 SQL 쿼리 실행의 똑똑한 내비게이션이다.
커넥션 풀(Connection Pool)란?
데이터베이스와 연결(Connection)을 미리 만들어두고 재사용할 수 있게 관리하는 시스템이다.
데이터베이스는 연결을 설정하는 데 시간이 걸리기 때문에, 매번 새로 연결을 만들지 않고 미리 만들어둔 연결을 재활용해서 빠르게 처리할 수 있게 하는 것이라 생각하면 된다.
- 데이터베이스와의 연결을 미리 만들어 놓고, 애플리케이션 요청이 올 때 즉시 할당하는 시스템.
- 빠른 처리와 자원 절약을 위한 필수 기술.
Share article