위코드 기업협업 3주 차 회고

목차

1. 이번주 공부한 것

2. 마무리가 다가온다

 

* 결론 나지 않은 내용들 다수 포함

 

1. 이번주 공부한 것

1-1. 트랜잭션

저번 달에 프로젝트를 진행하면서도 트랜잭션을 사용했었습니다.

이번에도 투표 모듈을 만들며 트랜잭션을 사용할 일이 생겼는데,

흥미로운 점은 몽고디비는 트랜잭션 기능 지원을 최근에야 시작했다 하더군요.

(아마 초창기에는 Read 용도로 몽고디비를 주로 사용했기 때문이지 않을까... 라는 추측)

 

무튼, 저는 트랜잭션이 일련의 작업이 시작부터 종료시점까지의 일관성을 보장해준다는 뜻으로 두루뭉술하게 이해하고 있었습니다. 

가장 대표적인 예시가 계좌이체죠.

 

 

하지만, 당연한 말이지만, 제 생각보다 트랜잭션은 복잡한 개념이었습니다.

요즘 데이터베이스 시스템은 대부분 다중 사용자 환경을 지원합니다.

그렇기 때문에 동시에 여러명이 데이터를 수정하려 하는 일이 잦은데,

어떻게 하면 데이터의 무결성을 보장할 수 있을까요?

 

과연 question_id = 3의 responseCount 값은 어떻게 될까?

 

동시성 제어 (상호 배제)

ORM, ODM을 쓰면 내부적으로 트랜잭션이 어떻게 돌아가는지 모를 수 있는데,

(제가 그랬습니다.)

트랜잭션이 시작된 순간 업데이트될 데이터에 락이 걸리고, commit을 하면 락을 풉니다.

락을 통해 다른 트랜잭션과의 상호 배제 (mutual exclusion) 를 보장받을 수 있죠.

 

 

이쯤되면 또다른 궁금증이 생깁니다.

그렇다면 하나의 트랜잭션이 락을 걸고 작업을 하는 동안,

다른 트랜잭션은 해당 트랜잭션의 작업이 끝날 때까지 대기하는 것인가? (직렬?)

 

그래서 동시성 제어 스케줄링에는 비직렬 스케줄, 직렬가능 스케줄이 있다고 합니다.

스케줄링에 대한 얘기를 하자면 포스팅이 끝이 없을 것 같아 링크 걸어두겠습니다.

https://www.crocus.co.kr/1375

 

그리고 locking 의 단위도 다양합니다.

 

출처: https://medium.com/pocs/%EB%8F%99%EC%8B%9C%EC%84%B1-%EC%A0%9C%EC%96%B4-%EA%B8%B0%EB%B2%95-%EC%9E%A0%EA%B8%88-locking-%EA%B8%B0%EB%B2%95-319bd0e6a68a

 

테이블 단위 이상으로 락을 걸어버리면

update할 row 외의 다른 row도 락이 걸려버리기 때문에

다중사용자 환경에서 비효율적일 수 있습니다.

 

데드락 (교착 상태)

서로 다른 트랜잭션이 각자의 데이터에 락을 걸어놓고 작업하다가,

서로의 데이터를 요구할 때 발생합니다.

말로 설명하기 어렵네요. 그림으로 보시죠.

Deadlock 예시, 출처: https://www.sqlshack.com/understanding-the-deadlock-definition-in-sql-server/

 

이 경우, 오라클 베이스 데이터베이스는 한쪽의 트랜잭션을 풀어준다고 합니다.

그 외 데드락을 해결하는 방법은

1. 예방 2. 회피 3. 탐지 및 복구 정도가 있는데,

이 또한 여기서 회고록에서 다루기엔 너무나도 긴 내용이 될 것 같으니 패스하도록 하겠습니다.

 

번외로, 공부하다보니 은우님의 자기소개 문구가 떠올랐습니다.

 

1초에 백만개의 트랜잭션이라니... 어떻게 하신겁니까.

 

1-2. API Gateway

API Gateway는 사실 일주일 전에도 띄워져 있던 건데, 이해를 하고 사용한 건 아니었습니다.

그냥 나의 Lambda를 invoke해주는 역할을 한다고만 이해했을 뿐.

그러다가 이번주에 Swagger로 Open API를 구동하려고 했는데, 왜인지 API Gateway에게 막혔습니다.

뭘 해보려고 해도 API Gateway에 대한 이해가 부족해서 왜 안되는지조차 알 수 없었습니다.

그래서 API Gateway, 더 나아가 프록시에 대한 공부가 필요하다 느꼈습니다.

 

API Gateway도 또하나의 서버라고 생각할 수 있습니다.

말그대로 관문(Gateway)의 역할을 하는데,

 

API Gateway의 대표적인 역할은 아래와 같습니다.

 

1. 여러개의 분산된 API 서비스를 하나의 엔드포인트로 단일화

2. 여러개의 분산된 API 서비스의 인증/인가 과정 통일

3. 로드 밸런서 기능

4. 요청/응답에 대한 모니터링 간편화

 

그 외 캐싱, 서비스 디스커버리 등등...

 

출처: https://www.express-gateway.io/eg-vs-amazon-aws-api-gateway/

 

공부하다보니 꽤 프록시스럽다는 생각이 들었습니다.

뭔가 이런 API Gateway의 특징이 Swagger와의 연동 문제에 이유가 되지 않을까 싶습니다.

출처: https://towardsaws.com/access-swagger-ui-in-aws-lambda-via-api-gateway-deployed-with-the-serverless-framework-d80268ef1d79

 

https://stackoverflow.com/questions/54206514/how-to-access-aws-api-gateway-documentation-using-swagger-ui

How to access AWS API Gateway documentation using Swagger UI

 

 

2. 마무리가 다가온다.

뒤돌아보니 꽤 많은 걸 하고, 많은 걸 공부했습니다.

위에 적어놓은 내용 외에도, async await 처리, 불필요한 DB hit 줄이기 (성능 개선),

API 문서 작성, npm scripts 작성 등 꽤 많은 작업을 했던 한 주였습니다.

첫 주에 떨려하고 겁먹던 제 모습을 지금 생각해보자니 재밌네요.

 

매 주 challange가 생겨났었는데, 

(첫째 주 - serverless가 뭐지? 둘째 주 - javascript는 왜 이러지? 셋째 주 - Swagger가 왜 안되지?)

결국 하나씩 알아가는 재미 덕분에 개발공부를 계속 하는 것 같습니다.

 

참고

https://movenpick.tistory.com/30

#03. 트랜잭션(Transaction) & 병행제어(Concurrency Control)

https://myjamong.tistory.com/181

[Oracle] Transaction Dead Lock 발생 실습, 이론 말고 직접 만들어 보자 :: 마이자몽

https://offbyone.tistory.com/225

MySQL locking - Table-Level Locking, Row-Level Locking, Optimistic Locking

https://medium.com/pocs/%EB%8F%99%EC%8B%9C%EC%84%B1-%EC%A0%9C%EC%96%B4-%EA%B8%B0%EB%B2%95-%EC%9E%A0%EA%B8%88-locking-%EA%B8%B0%EB%B2%95-319bd0e6a68a

동시성 제어 기법 — 잠금(Locking) 기법

https://towardsaws.com/access-swagger-ui-in-aws-lambda-via-api-gateway-deployed-with-the-serverless-framework-d80268ef1d79

Access Swagger UI in AWS Lambda via API Gateway — Deployed with the Serverless Framework