Welcome to gwimong's Blog!
안녕하세요. 귀몽이의 개인 블로그입니다.-
Database 이해하기 #2
DB Lock
DBMS마다 Lock를 구현하는 방식과 세부 적용 방법은 다르지만,
데이터의 접근을 제한함으로써 일관성을 보장하기 위한 방법으로 기본적인 개념은 유사합니다.Lock 종류
DB Lock은 적용 대상과 상황에 따라 분류할 수 있습니다.
적용 대상에 따른 분류
- Row lock : 변경하려는 row에 대해 lock을 설정
- Record lock : index record에 대한 lock을 설정
- Gap lock : index record의 gap에 대한 lock 설정(gap은 index 중 실제 record가 없는 부분)
- Table lock : Table과 index에 모드 lock을 설정
- Database lock : 데이터베이스를 복구하거나 스키마를 변경할 때 설정
적용 상황에 따른 분류
- Shared Lock : 원하는 데이터에 lock을 걸었지만, 다른 세션에서 읽을 수 있습니다. 보통 데이터를 읽을 때 사용합니다.
- Exclusive Lock : 데이터에 lock을 걸면, 다른 세션에서 읽거나 변경 할 수 없습니다. 보통 데이터를 변경 할 때 사용합니다.
- Intention Lock : 요청한 범위에 대한 lock를 수행 할 수 있는지 빠르게 확인하기 위해 사용됩니다.
(예를 들어, Transaction A가 하나의 Row에 Exclusive lock을 걸어 놓은 상태에서 Transaction B가 해당 테이블 전체에 대한 lock을 걸기 위해선 모든 테이블 Row에 대한 lock 유무를 확인해야 합니다. 이 때, Transaction A가Intention Lock 테이블에 걸어두면 Transaction B는 좀 더 빠르게 Lock 적용 유무를 확인 할 수 있습니다.)
Blocking
Transaction 간의 lock 경합이 발생하여, 작업이 진행되지 않고 멈춰선 상태를 말합니다.
Shared Lock 간에는 발생하지 않지만, Exclusive Lock에선 경합을 하여 우선 순위에 따라 Transaction이 수행됩니다.이렇게 Blocking 된 Transaction은 lock이 해제 될 때까지 대기하게 되며, 이는 성능에 좋지 않는 영향을 미칩니다.
경합을 최소화하기 위해선 아래의 사항을 준수합니다.- Transaction은 길지 않게 작성합니다.
- 동일한 데이터를 갱신하는 Transaction은 동시에 수행되지 않도록 설계합니다.
- Transaction 격리 수준을 불필요하게 상향 조정하지 않습니다
- 한번에 수행되는 작업 단위(쿼리)를 너무 무겁게 작성하지 않습니다.
Dead Lock
Dead lock(교착 상태)은 두 개 이상의 작업이 서로 상대방의 작업이 끝나길 기다리고 있기 때문에, 결과적으로 아무것도 완료되지 못하는 상태를 말합니다.
Database에서 dead lock은 서로 다른 Transaction 간의 교착 상태를 의미합니다.해결 방법
- 예방 기법 : Dead Lock이 발생하지 않도록 미리 예방하는 방법입니다.
- Transaction이 실행되기 전에 필요한 모든 자원을 Lock 한다.
- 일정 시간이 지나면 쿼리가 취소도록 설정한다.
- 회피 기법 : 자원을 할당할 때 Time Stamp를 활용하여 Dead lock이 발생하지 않도록 회픠하는 방법입니다.
- Wait-Die 방식 : 먼저 들어온 Transaction은 대기(Wait)하고 나중에 들어온 Transaction은 포기(Die)하고 나중에 다시 요청한다.
- Wound-Wait 방식 : 먼저 들어온 Transaction은 데이터를 선점(Wound)하고, 나중에 들어온 Transaction은 대기(Wait)한다.
- 낙관적 병행 제어 기법 : Transaction이 커밋을 수행할 때, 데이터에 문제가 있다면 Roll-back 하는 방법입니다.
- 빈도 줄이기 기법 : Dead lock 발생 확률을 줄이는 방법입니다.
- Transaction 진행 방향을 같은 방향으로 처리
- Trahsaction 처리 속도를 최소화
- Lock 해제 시간을 조절
확인 방법
DBMS마다 Dead Lock을 관리하는 방법이 상이합니다.
MySQL-innodb 기준으로 아래의 쿼리를 통해 확인 할 수 있습니다.mysql> show engine innodb status위 쿼리를 수행하면 현재 innodb의 상태 정보를 표출되며, 최근 발생한 Dead lock 정보를 확인 할 수 있습니다.
만약 모든 deadlock에 대해 확인 하고 싶은 경우, 아래의 설정을 변경합니다.
[my.cnf][mysqld] innodb_print_all_deadlocks = 1또는
mysql> SET GLOBAL innodb_print_all_deadlocks = 1;
-
Database 이해하기 #1
DB Transaction
DB Transaction은 DBMS 또는 이와 유사한 시스템에서 사용되는 상호 작용의 단위입니다.
즉, 시스템을 변환시키는 하나의 논리적 기능을 수행하기 위한 작업의 단위로, 한번에 모두 수행되어야 할 일련의 연산들을 의미합니다.Transaction의 성질
ACID(원자성, 일관성, 고립성, 지속성)는 데이터베이스 Transaction이 안전하게 수행된다는 것을 보장하기 위한 성질을 가리키는 약어입니다.
- Atomicity(원자성) : 데이터베이스에 모두 반영이 되던지, 전혀 반영되지 않던지 해야 한다.
- Consistency(일관성) : 수행 전과 완료 후의 시스템의 상태가 같아야 한다.
- Isolation(독립성) : Transaction는 각각 독립적으로 수행되며, 다른 연산에 영향을 끼칠 수 없다.
- Durability(영구성) : 연산이 정상적으로 완료된 이후에는 영구적으로 반영이 되어야 한다.
Transaction 연산
Transaction은 시스템에 적용하기 위한 연산으로 Commit와 Rollback이 있습니다.
- Commit : Transaction의 모든 작업이 성공적으로 완료 된 것을 Transaction 관리자에 알려주는 연산
- Rollback : Transaction의 작업 중 일부가 비정상적으로 종료되어 데이터베이스의 일관성을 깨뜨렸을 때, 해당 Transaction이 행한 모든 작업을 취소( Undo)하는 연산
Transaction 상태
- Active(활동) : Transaction이 실행 중인 상태
- Failed(실패) : Transaction 실행 중 오류가 발생하여 중단된 상태
- Aborted(철회) : Transaction이 비정상적으로 종료되어 Roolback 연산을 요청한 상태
- Partially Committed) : Transaction 연산이 정상적으로 수행되었으며 Commit 연산을 요청하기 전 상태
- Committed(완료) : Transaction의 모든 작업이 정상적으로 수행되어, Commit 연산을 실행한 상태
Isolation Level
Transaction의 ACID를 엄격하게 준수하면, 데이터의 적합성은 보장 할 수 있지만 동시성 효율은 매우 떨어지게 됩니다.
이러한 Trade-off 관계에서 데이터베이스는 서로 다른 Transaction이 어느 정도 허용이 가능하도록 격리 수준을 지원합니다.
(Level 수준이 높을 수록 엄격한 격리 수준을 제공)Name Level Dirty Read Non-Repeatable Read Phantom Read 정합성 동싱성 Serializable 3 X X X 높다 낮다 Repeatable Read 2 X X O 중간 중간 Read Committed 1 X O O 중간 중간 Read Uncommitted 0 O O O 낮다 높다 - Dirty Read : 다른 Transaction에 의해 수정되었지만, 아직 커밋되지 않은 데이터를 읽어 발생하는 오류
- Non-Repeatable Read : Transaction에서 같은 데이터를 여러번 조회 할 때, 조회 결과가 상이한 현상(다른 Transaction에서 데이터를 수정함)
- Phantom Read : 한 Transaction에서 일점 범위의 레코드를 처음 조회 할땐 없던 유령 레코드가 그 다음 조회 시에 나타나는 현상
Serializable
Transaction이 사용 중인 테이블의 모든 Row에 대한 접근을 제한합니다.
이 격리 수준에서는 단순한 Select 쿼리가 실행되더라도, 다른 Transaction이 데이터에 접근 할 수 없습니다.
가장 높은 데이터 접합성을 보장하지만, 그만큼 성능은 가장 느립니다.Repeatable Read
Transaction이 Active 될 때 수행한 시간을 기록하고, 해당 시점을 기준으로 consistent read를 수행합니다.
하지만 새로운 Row가 추가 되는 것을 막지는 않습니다.* consistent read : Read operation을 수행 할 때, 현재 DB의 값이 아닌 특정 시점의 snapshot을 읽어 오는 것
Read Committed
Transaction은 읽기 연산 마다 DB Snapshot를 생성합니다. 이로 인해, 커밋이 완료된 다른 Transaction의 변경 사항은 consistent read 시 반영됩니다.
대부분의 DBMS가 기본 모드로 채택하고 있는 격리 수준입니다.Read Uncommitted
커밋이 되지 않은 데이터 변경을 다른 Transaction이 조회 가능하도록 허용하는 격리 수준입니다.
데이터 부정합 문제가 발생할 확률은 높아지지만, 그만큼 성능은 가장 빠릅니다.
-
Cloud not reserve enough space for object heap
장애 현상
Spring boot project를 내장 톰캣으로 실행시킬 때 아래의 오류가 발생함.
Error occurred during initialization of VM
Could not reserve enough space for 2097152KB object heap해결 과정
해당 오류는 프로젝트 실행 시 heap 메모리가 부족하다는 오류입니다.
- Intellij의 heap 메모리 설정
Help > Change Memory Settings
- Java VM 옵션 추가
-Xms1024m -Xmx2048m
- JDK 변경
JDK 1.8(64bit)를 추가로 설치하고, 실행 시 해당 JDK로 실행되도록 변경
원인 분석
The maximum theoretical heap limit for the 32-bit JVM is 4G.
Due to various additional constraints such as available swap, kernel address space usage, memory fragmentation, and VM overhead, in practice the limit can be much lower.
On most modern 32-bit Windows systems the maximum heap size will range from 1.4G to 1.6G. On 32-bit Solaris kernels the address space is limited to 2G. On 64-bit operating systems running the 32-bit VM, the max heap size can be higher, approaching 4G on many Solaris systems.32bit JVM은 이론상 최대 4GB의 메모리를 사용 할 수 있지만, Windows 환경에선 2GB로 제한됩니다. 이로 인해 2GB 이상의 프로젝트를 실행 할때 해당 오류가 발생 한 것입니다.
- Intellij의 heap 메모리 설정
-
HTTP Cookie의 Security
Http Cookie
HTTP Cookie는 서버에 의해 브라우저에 저장되는 데이터 조각입니다.
Cookie는 2개의 유형으로 나뉩니다.- persistent cookies : 만료일을 가지는 cookie로, 사용자 경험을 저장하기 위해 주로 사용
- session cookies : 세션 종료와 함께 삭제되는 cookie로, 자격 증명 등을 저장하기 위해 주로 사용
Session과 Cookie
Http는 connectionless & Stateless(무상태성, 상태 정보를 가지 않는) 프로토콜입니다.
서버는 요청한 클라이언트의 상태 정보를 알 수 없기 때문에, 매번 인증 절차를 수행해야 합니다.
- Client A는 Server로 사용자 정보를 전송하여 인증 절차를 수행합니다.
- Server는 Client A의 대한 Session을 생성하여 Set-Cookie에 담아 Client에 전송합니다.
- 이 후, Client A는 Server로 요청 시, 세션 정보를 cookie에 담아 함께 전송합니다.
- Server는 Session cookie를 해석하여 Client A라는 것을 확인하고, 요청을 처리합니다.
-
HTTP의 발전
HTTP의 시작
HTTP는 HyperText Transfer Protocol의 약자로,
1989년 월드 와이드 웹이 개발되면서 데이터 전송을 위한 프로토콜입니다.
HTTP/0.9
원라인 프토로콜로도 불리는 HTTP/0.9는 HTTP/1.0 이전의 프로토콜을 명시하기 위한 버전입니다. (HTTP/1.0 이전에는 별도로 버전 번호를 부여하지 않았으나, HTTP/1.0과 구분하기 위함)
HTTP/0.9는 요청 메서드가 GET만 존재하였으며, 매우 단순한 구조의 프로토콜입니다.
HTTP/1.0
프로토콜 확장을 위한 여러 노력들이 반영되었습니다.
- 각 요청 시 버전 정보를 포함합니다.
- 상태 코드가 추가 되었습니다.
- HTTP 헤더가 추가 되엇습니다.
- Content-Type에 문서 정보를 명시 할 수 있어, 다양한 문서들을 전송 할 수 있습니다.
그 외에 여러 새로운 기능들을 시도하였으며 이러한 내용을 RFC 1945(1996년 11월)에 공개되었습니다.
HTTP/1.1
최초의 표준 프로토콜로 RFC 2068(1997년 1월)에 처음 공개되으며,
HTTP/1.0의 모호함을 명확하게 정의하고 많은 개선 사항들을 적용하였습니다.
- 커넥션 재사용
- Pipelining 도입
- 청크된 응답 지원
- 캐시 제어 매커니즘 도입
- Host 헤더 추가
(동일 ip 주소에 다른 도메일을 호스팅 가능 -> Colocation 가능)
HTTP/2.0
더 나은 성능을 위한 프로토콜입니다.
- 이진 프로토콜
- 요청과 응답의 멀티플렉싱을 지원
- 전송된 데이터의 불필요한 오버헤드를 제거하고, 유사한 내용의 헤더들을 압축( HPACK 적용)
HTTP/3.0
TCP/TSL가 아닌 QUIC를 사용합니다.
QUIC(Quick UDP Internet Connection) : 범용 목적의 전송계층 통신 프로토콜로서, TCP가 아닌 UDP를 이용하여 다중화 연결을 지원하는 방식입니다.
-
비동기 통신을 위한 Ajax와 WEB API
비동기 통신
HTTP Request(요청)하고 이에 대한 Respone(응답)을 순차적으로 처리하지 않는 통신 방법입니다.
비동기식은 Requset와 이에 대한 Respone을 순차적으로 처리하는 동기식에 비해, 여러 요청을 동시에 수행할 수 있어 많은 이점이 있습니다.
이러한 이점을 통해
- 페이지 새로고침 없이 서버에 데이터를 요청 할 수 있으며,
- 서버로부터 데이터를 받고 이에 대한 이벤트를 자연스럽게 처리 할 수 있습니다.
Ajax
Asynchronous Javascript And XML의 약자로 “에이젝스” 또는 “아작스”라고 읽습니다.
jqery에서 제공하는 ajax()와 혼돈하는 경우가 많은데,
javascript로 XMLHttpRequest 객체를 이용해 서버와 클라이언트가 비동기로 통신하는 기법
을 말합니다.
WHATWG에서는 이러한 Ajax를 구현하기 위해 XMLHttpRequset 또는 Fetch 를 표준으로 관리하고 있습니다.
XMLHttpRequset
XMLHttpRequest는 Internet Explorer의 XMLHTTP라고 불리는 ActiveX 기술로부터 시작되지만, 현재는 대부분의 브라우저에서 지원을 하고 있습니다.
XMLHttpRequest 인터페이스는 이용해 서버와 클라이언트가 비동기로 통신을 수행하이름에 XML이 들어가지만 모든 종류의 데이터를 담을 수 있습니다.
아래는 순수한 javascript로 ajax를 구현하는 예시입니다.
// httpRequest.readyState에 대한 처리 처리 구현 function responeFunction() {} // XMLHttpRequest 객체 생성 const httpRequest = new XMLHttpRequest(); // HTTP 요청의 상태가 변경 되었을 때 수행 될 함수 지정 httpRequest.onreadystatechange = responeFunction; // HTTP 요청 정보 설정 httpRequest.open("GET", "test.json"); // HTTP 요청 httpRequest.send();Fetch
XMLHttpRequest를 이용한 AJAX는 복잡하기도 하고, 가독성이 좋지 않습니다.
이를 보완하기 위해 ES6부터 Fetch를 지원하기 시작하였습니다.Fetch API는 HTTP 파이프라인을 구성하는 요청과 응답 등의 요소를 Javascript에서 제어할 수 있도록 인터페이스를 제공합니다.
fetch는 매우 간단하게 구현 할 수 있습니다.
// HTTP 요청 fetch("http://test.json").then((response) => console.log(response.json())); // 응답 처리Refernces