1.
인프라 구조도를 보면 Cloud Front -> S3 -> Load Balancer를 통과하게 되어있는데, 이 Flow에서 S3 -> Load Balancer에 전달하는 요청 이 어떤 내용인가요?
•
클라이언트에게 input 받은 정적인 데이터를 클라우드 프론트를 통해 백엔드 서버에 전달 하거나 필요한 데이터 요청에 대해 표현할려고 했습니다.
2.
Reddison을 통한 동시성 제어는 테스트를 어떻게 진행하셨고 어떻게 잘 동작하는지를 확인하셨나요?
•
실제로 동작이 잘되는지에 대해 확인은 하지 못하고, 테스트 코드를 통해 잘 작동하는지 확인 했습니다.
•
아래의 메서드를 이용했다.
쓰레드 풀: 미리 일정 개수의 쓰레드를 생성해서 사용하는 기법
* ExecutorService : 병렬 작업 시 여러 개의 작업을 효율적으로 처리하기 위해 제공되는 JAVA 라이브러리
* ExecutorService에 Task만 지정해주면 친절하게 알아서 ThreadPool을 이용해서 Task를 실행하고 관리* ThreadPool에 있는 Thread수보다 Task가 많으면, 미실행된 Task는 Queue에 저장되고,
* 실행을 마친 Thread로 할당되어 순차적으로 수행된다.
* FixedThreadPool : 고정된 개수를 가진 쓰레드풀
* CountDownLatch : CountDownLatch는 특정 작업을 수행하는 데 있어서 특정 쓰레드로 하여금 대기할 수 있게 해주는 역할을 한다.
3.
동시성 제어를 활용시 Redis를 사용하는 것은 좋아보이나, 아키텍쳐를 보면 EC2 인스턴스마다 Redis가 존재하게 되는 것으로 보이는데 Redis를 다른 인스턴스로 분리해야하는 것 아닐까요? 또한, MySQL을 활용한 락과, Redis을 활용한 락 차이를 정확히 알고 계신지도 궁금하네요. 그 부분을 의사 조율 부분에서는 발견할 수 없었습니다.
•
현재 시간이 부족해 인스턴스를 분리하는 작업은 못했습니다. 추후 고도화 작업에서 Redis를 다른 인스턴스로 분리할 예정입니다.
•
Mysql은 공통된 자원에 대한 Lock을 거는 것이고, Redis를 통한 Lock은 어떠한 행위에 대한 Lock을 한다고 조사했습니다. 저희 예약하기 프로세스는 방 테이블에서 해당 레코드를 읽고 그 후 reservation이라는 테이블에 예약하기를 생성하고 다시 reservation 리스트를 조회 해 예약 가능한 시간대를 보여주는 프로세스입니다.
•
그리고 Mysql의 락은 특정 테이블이나 레코드, 트랜잭션 수준에서 적용된다고 조사했습니다. 이러한 부분에서 저희는 하나의 프로세스 단위로 Lock을 거는 Redis가 더 적합하다고 생각했습니다.
•
참고
◦
MySQL은 관계형 데이터베이스 시스템으로, 데이터를 테이블 형태로 저장합니다. 락은 주로 특정 테이블 또는 레코드에 적용됩니다.
◦
Redis는 메모리 기반의 키-값 저장소이며, 데이터는 메모리에 저장됩니다. 락은 Redis의 문자열 데이터 유형을 사용하여 구현될 수 있습니다.
1.
Locking의 범위:
•
MySQL 락은 주로 특정 테이블, 레코드 또는 트랜잭션 수준에서 적용됩니다.
•
Redis 락은 키 단위로 적용되며, 여러 프로세스 또는 스레드가 동일한 키를 사용하여 락을 획득할 수 있습니다.
2.
락의 유연성:
•
MySQL의 락은 트랜잭션 또는 세션 범위로 적용될 수 있으며, 여러 유형의 락(읽기 락, 쓰기 락 등)이 지원됩니다.
•
Redis의 락은 개발자가 필요에 따라 더 유연하게 구현할 수 있습니다. 예를 들어, 세마포어 또는 임계 영역을 사용하여 락을 구현할 수 있습니다.
3.
성능:
•
Redis는 메모리에 데이터를 저장하고 빠른 읽기 및 쓰기 작업을 지원하므로, 락의 획득 및 해제가 매우 빠를 수 있습니다.
•
MySQL은 디스크 기반의 데이터 저장소를 사용하므로, 락의 획득 및 해제가 상대적으로 느릴 수 있습니다.
4.
데이터 일관성:
•
MySQL의 락은 트랜잭션을 통해 일관성을 유지하고 데이터베이스의 ACID 속성을 보장합니다.
•
Redis의 락은 개발자가 수동으로 일관성을 관리해야 하며, Redis는 일반적으로 ACID 속성을 제공하지 않습니다
