개발놀이터

저는 현재 소규모 스타트업에서 일하고 있는데요. 회사에서 큼직하지 않은 잡다한 인프라 담당을 겸하고 있습니다. 사용자 권한 관리하고 서버 내리고 올리고 라우팅이나 포트 관리하고 이런 서버관리 업무가 제 업무에 포함되어있습니다.  그러다보니 평소에 안그래도 부족했던 리눅스관련 지식이 더 티가 잘나더군요... 그래서 이번 기회에 리눅스 명령어부터 리눅스 커널에 대해서 좀 공부를 할  생각입니다.  평소의 제 방식처럼 일단 사용법부터 들이박아보고 이론은 조금 시간이 지나고 배워보도록 하겠습니다.   리눅스 사용자 추가서버 컴퓨터는 대부분 리눅스로 되어있습니다. 보통 제가 프로젝트를 할 때는 AWS에서 제공해주는 기본 사용자를 사용하곤 했었죠. 회사에선 개발전용 사용자가 있고 루트 사용자가 있더군요.  이 사용..

약 2년전 시작했던 프로젝트인 온라인 쇼핑몰 프로젝트는 제가 취직을 함으로써 종료되었고 더이상 건드리지 않았습니다. 하지만 사이드프로젝트로서 나중에 이직할때 도움이 되고자 코드 리팩토링을 진행하게 되었습니다.  리팩토링을 진행하던 중에 조회수를 증가시킴과 동시에 쿠키에 조회했다는 정보를 넣어 조회수 중복 증가를 방지하는 로직을 발견했고 그 부분에서 리팩토링할 부분이 있었습니다.  바로 @Transcational 의 남용이었죠.  @Servicepublic class ClickDuplicationPreventService { @Transactional public void viewCountUp(Item item, HttpServletRequest request, HttpServletResponse r..

이번에도 Redis에 관한 내용...은 아니고 JWT에 대한 내용입니다. Redis는 조연입니다. 많은 분들이 회원 인증에 JWT를 사용하곤 하십니다. 실제로 저도 프로젝트에 JWT와 Spring Security를 접목시켜 회원 인증을 진행했습니다. 프로젝트에 JWT로 인증을 진행하는건 좋은데 그 뒤가 궁금했습니다. 만약에 Redis에 장애가 발생하면 JWT인증은 어떻게 될까? JWT와 Redis 구글링 한번이면 나오는 내용이기 때문에 자세히 다루지는 않겠습니다. JWT는 stateless한 인증 방식이라고 알고들 계시겠지만 이는 반은 맞고 반은 틀린 이야기입니다. 보통 JWT로 인증을 진행할 때 Access Token은 쿠키에 Refresh Token은 Redis에 저장하곤 합니다. 쿠키에 HTTP o..

만약 캐싱 솔루션으로 Redis를 사용하고 있다면 Redis가 장애상황으로 죽어버리는 경우 RDBMS에 부하가 심하게 발생하여 RDBMS까지 연쇄적으로 장애가 발생하는 상황이 충분히 있을 수 있습니다. 저는 프로젝트를 진행하면서 Redis를 이용해서 캐싱 솔루션을 도입했고 결과적으로 RDBMS의 부하를 30퍼센트 이상 줄이기도 하였습니다. 이 30퍼센트라는 수치는 결코 무시할 수 없기 때문에 Redis의 장애상황에 대한 대비책이 있어야합니다. 이번 포스팅에선 Redis가 장애시 RDBMS의 연쇄적인 장애를 대응하기 위해 어떤 전략을 사용하는지 알아보도록 하겠습니다. Redis의 가용성을 높이자! 흔히 생각할 수 있는 방법으로 Redis를 죽지않게 관리하는 것입니다. Redis에는 두가지 배포 방식이 있습..

데이터베이스에는 동시성 문제를 해결하기 위해 시스템 내부적으로 다양한 방법들을 제공해줍니다. 오늘은 데이터베이스에서 사용할 수 있는 다양한 동시성 제어에 대해서 알아보도록 하겠습니다. 동시성 제어 이번 포스팅에서 중점적으로 다룰 동시성 제어 방식은 타임스탬프 기반 프로토콜 (Timestamp-Based Protocol) 낙관적 동시성 제어 (Optimistic Concurrency Control) 이렇게 두가지를 보도록 하겠습니다. 사실 저 두개 말고도 락 기반 프로토콜과 MVCC가 있는데 이 두가지는 이미 포스팅으로 다뤘기 때문에 이번엔 링크만 남기고 넘어가도록 하겠습니다. 락 기반 프로토콜 https://coding-review.tistory.com/302 Phantom Read 부정합문제 해결방안 ..

이번 포스팅에선 Redis와 Memcached의 동시성 문제에 대해서 궁금증이 생겨서 공유하고자 글을 쓰게 되었습니다. 구글링하다 Redis-Semaphore로 Mutex 해결하기 라는 제목의 포스팅을 발견했습니다. 처음엔 보고 "으잉? 이게 무슨말이야?" 하게 됐는데 Mutex는 동시성 문제를 해결하는 방법론인데 Mutex를 해결..? 아마 포스팅 쓰신 글쓴이분께서 Mutex의 뜻을 착각하고 계신게 아닌가 싶었습니다. 그래서 그 부분은 넘어가도록 하고 Redis-Semaphore라는게 걸려서 이번에도 역시 GPT로 공부해봤습니다. Redis와 Memcached의 차이 우선 이 둘의 차이부터 짚고 넘어가도록 하겠습니다. Redis 싱글스레드이다. 여러가지 자료형을 제공한다. String, Hash, Li..

Q. TCP의 흐름 제어와 혼잡 제어에 대해서 설명해주세요. A. 흐름 제어는 송신자와 수신자 사이에서 벌어지는 현상이고 송신자가 보내는 패킷의 크기가 수신자의 수용 용량보다 클 경우 수신자의 버퍼를 동적으로 늘리기 위해 잠시 시간을 벌어주는 용도로 사용됩니다. 이때 sliding window 방식으로 수신자가 ACK 패킷을 전달할 때마다 일정량의 데이터를 보내주는 것이 특징입니다. 혼잡 제어는 송신자와 수신자와의 통신뿐만 아니라 더 넓은 범위에서 일어나는 현상으로서 네트워크 트래픽이 너무 많아지는 경우 패킷이 로스되는 것을 막기 위해 트래픽 레벨의 모니터링을 통해 혼잡을 막기위해 window 크기와 전송 속도를 제어하는 역할을 합니다. Q. window 크기가 뭔가요? A. 단위 시간당 전송되는 패킷의..

우리가 흔히 말하는 네트워크 통신은 TCP 3way handshaking에 의해 일어납니다. 그리고 TCP에 대해 조금 공부해보신 분들은 UDP와의 차이도 말할 수 있죠. UDP와 다르게 TCP는 전이중 방식과 점대점 방식 그리고 흐름제어와 혼잡제어를 통해 높은 신뢰성을 줄 수 있다고 말이죠. 잠시 설명하자면 전이중 방식은 전송이 양방향으로 이어진다는 뜻이고 점대점 방식은 각 연결점이 종단점을 가진다는 것입니다. 하지만 흐름제어와 혼잡제어는 그냥 외우기만해서 잘 모르더라구요. 이 부분에 대해서 본격적으로 공부해봤습니다. 흐름 제어 흐름 제어는 송신자와 수신자 사이에 버퍼(데이터를 받을 수 있는 용량)를 관리하기 위해 나온 방법론입니다. 만약 송신자가 수신자에게 엄청나게 큰 데이터를 넘겨준다고 생각해봅시다..

이번 포스팅에선 데이터베이스 프로시저에 대해서 알아보도록 하겠습니다. 면접 봤는데 해당 내용이 나왔고 대답을 못했습니다. 다음 면접을 위해 정리해두는 느낌으로 포스팅 해보도록 하겠습니다. 데이터베이스 프로시저 프로시저란 무엇일까요? 간단하게 쿼리 묶음이라고 생각하시면 됩니다. 만약 자주 사용하는 SQL문이 있다면 그것들을 정리해둔 것이죠. 한번 간단한 예시를 상정해보고 코드 예제까지 보여드리겠습니다. "books"라는 테이블에 새로운 책을 입력할 것입니다. "books"테이블에 특정 책의 수량을 변경할 것입니다. 데이터가 바뀐 책의 상세 데이터를 요청해보겠습니다. DELIMITER // CREATE PROCEDURE ManageBook(IN bookTitle VARCHAR(255), IN bookAuth..

Q. 트랜잭션 전파단계에 대해서 설명해주세요 A. 스프링은 여러개의 트랜잭션 연산을 하나로 통합하기위해 물리 트랜잭션과 논리 트랜잭션이라는 개념을 도입했고 이로인해 트랜잭션 연산들이 전파되면서 원자성을 보장할 수 있었습니다. JPA에서는 다양한 트랜잭션 전파 단계를 지원하는데 디폴트값인 REQUIRED부터 무조건 새로운 트랜잭션을 만드는 REQUIRES_NEW 그외에도 SUPPORTS, NOT_SUPPORTED, NESTED, NEVER, MANDATORY 등이 있습니다.