개발놀이터

MySQL의 InnoDB 스토리지 엔진의 기본 격리수준은 REPEATABLE READ입니다. 하지만 REPEATABLE READ에서 발생할 수 있는 문제 중 하나인 Phantom Read를 피할 수는 없는데요.  MySQL은 각종 locking 매커니즘을 이용해서 Phantom Read를 막을 수 있었다고 MySQL팀은 설명했습니다. 하지만 무조건 Phantom Read가 발생하지 않는 것은 아닙니다.  이번 포스팅에선 MySQL에 사는 유령에 대해서 공부해보고 정리해봤습니다.  Phantom Read우선 Phantom Read에 대해서 간단하게 짚고 넘어가도록 하겠습니다.  어떤 상황이 Phantom Read를 발생시킬까요? A트랜잭션이 SELECT 쿼리를 날린다B트랜잭션이 이후 INSERT 쿼리를 날..

마이크로 서비스와 메세지 브로커는 뗄 수 없는 사이입니다. 서로 다른 도메인이 여러개의 서버로 나눠져 있는 상황에서 모든 서버에 동일하게 데이터를 전달해야 하는 경우에 메세지 브로커만한게 없죠.  그렇기에 모놀리식에서는 메세지 브로커를 사용하는게 오버엔지니어링이 되기도 합니다.  이번 포스팅에서는 메세지 브로커의 근심과 걱정에 대한 내용을 공부해보고 정리해봤습니다.  메세지 브로커https://coding-review.tistory.com/504 아파치 카프카 (개념)저번 포스팅에서 파트2를 시작하면서 메세지 브로커의 장을 열었습니다. 메세지 브로커를 이용해서 서버간 통신을 조금 더 매끄럽게 진행할 수 있다는 것을 알았고 어떤 모델이 있는지 알았습coding-review.tistory.com메세지 브로커..

이번 포스팅에선 리눅스가 어떻게 파일을 읽고 쓰는지에 대해서 공부해본 내용을 정리하려합니다.  요즘 리눅스 커널에 대해서 공부하고있는데요. 아직 배경지식이 전무하다시피해서 공부하는데 애먹고있습니다. 바로 시작해보죠! cf) 이 포스팅 전 읽고 오시면 좋은 글이 있습니다! 파일시스템에 대한 간략한 정보들이 정리되어있습니다. https://coding-review.tistory.com/564 리눅스 기본 명령어 동작 원리 : 디렉토리 구조편 (cd, ls, rm, mv, cp)이번 포스팅은 이전 포스팅에서 영감을 얻었습니다.  https://coding-review.tistory.com/563 데이터베이스 쿼리를 실행하면 내부적으로는 어떤 일이 벌어질까?오랜만에 포스팅을 쓰는 것 같습니다. 거coding-r..

이번 포스팅은 이전 포스팅에서 영감을 얻었습니다.  https://coding-review.tistory.com/563 데이터베이스 쿼리를 실행하면 내부적으로는 어떤 일이 벌어질까?오랜만에 포스팅을 쓰는 것 같습니다. 거의 열흘만인 것 같은데 요즘 쿠버네티스를 공부하느라고 실습을 위주로 공부하고 있느라 공부할 시간이 마땅히 나지 않았네요...  이번 포스팅은 평소coding-review.tistory.com제 공부 방향은 항상 문득 떠오르는 주제이거나 이전 주제에서 깊이있게 공부해볼만한 주제를 따로 선정해서 더 공부하는 편입니다. 이전에 데이터베이스 쿼리를 실행하면 OS레벨에서 어떤 일이 벌어지는지 공부했는데 이때 System Call이나 파일시스템에 대해서 많은 공부가 되었고 이 내용을 잘 활용하면 기..

오랜만에 포스팅을 쓰는 것 같습니다. 거의 열흘만인 것 같은데 요즘 쿠버네티스를 공부하느라고 실습을 위주로 공부하고 있느라 공부할 시간이 마땅히 나지 않았네요...  이번 포스팅은 평소에도 너무나도 궁금했던 데이터베이스의 연산과 그 속사정입니다. 이번 포스팅에선 OS레벨에서의 속사정과 데이터베이스 내부의 속사정 두가지 관점에서 톺아보도록 하겠습니다.  쿼리를 실행하면 OS레벨에선 어떤 일이 벌어질까?우리는 아래와 같은 쿼리를 날렸습니다.  SELECT * FROM USER u LEFT JOIN ORDER o ON u.user_id = o.user_id WHERE u.user_id = 20; 그럼 데이터가 어떻게 우리 눈에 보일 수 있게 될까요?  이 질문이 머리속에서 떠오르고 난 뒤 곰곰히 생각해봤을 때..

요즘 사이드 프로젝트 때문에 실습만 주구장창 했는데 오랜만에 이론 포스팅입니다. 쿠버네티스를 공부하다보면, 그리고 DevOps에 대해 공부하다보면 한번쯤은 보게 되는 논쟁 바로 "쿠버네티스 클러스터에 RDB배포? 시기상조다" VS "쿠버네티스 클러스터에 RDB배포 안해봤어? 겁나 편한데" 이 논쟁을 구글링하면 마땅한 답이 없습니다. 누가 시원하게 쓰면 좋아! 쓰면 나빠! 이걸 적어놓은걸 찾기 힘들었습니다. 그래서 GPT와 토론을 하면서 주장 -> 반박 -> 재반박 -> 반박에 반박 을 거듭하여 나름 정리해봤습니다.  우선 이 논쟁에 대해 짚어야 하는 부분은 크게 다섯가지입니다.  트랜잭션 롤백에 대한 관점마스터 슬레이브 노드 선출에 대한 관점네트워크 망분리로 인한 split-brain 상황에 대한 관점쿠..

이전 포스팅과 이어집니다! https://coding-review.tistory.com/560 AWS EKS 모니터링 환경 구축하기 (Prometheus, Grafana)이전 포스팅에서 이어집니다!  https://coding-review.tistory.com/559 AWS EKS HPA로 확장성 높이기저번 포스팅에서 이어지는 내용입니다!  https://coding-review.tistory.com/558 AWS EKS 스프링 + Nginx + SSL저번 포스coding-review.tistory.com 이전엔 프로메테우스 + 그라파나로 모니터링 환경을 구축해봤습니다. 이번 포스팅에선 이전 포스팅에다 슬랙을 추가해보도록 하겠습니다.  이전 포스팅 내용은 담지 않았습니다! helm repo add pro..

이전 포스팅에서 이어집니다!  https://coding-review.tistory.com/559 AWS EKS HPA로 확장성 높이기저번 포스팅에서 이어지는 내용입니다!  https://coding-review.tistory.com/558 AWS EKS 스프링 + Nginx + SSL저번 포스팅에서 이어지는 내용입니다!  https://coding-review.tistory.com/557 AWS EKS 스프링 프로젝트에 Ncoding-review.tistory.com 이전 포스팅에선 HPA와 CA로 파드와 노드를 동적으로 늘리는 실습을 했습니다. 이번엔 모니터링 환경을 구축해보도록 하겠습니다! 이전 포스팅에서 다뤘던 내용은 다루지 않겠습니다! 모니터링 환경 구축프로메테우스 설치우선 프로메테우스 yaml..

저번 포스팅에서 이어지는 내용입니다!  https://coding-review.tistory.com/558 AWS EKS 스프링 + Nginx + SSL저번 포스팅에서 이어지는 내용입니다!  https://coding-review.tistory.com/557 AWS EKS 스프링 프로젝트에 NGINX 붙이기이번 포스팅은 이전 포스팅과 어느정도 이어집니다. 이전에 스프링 프로젝트를 간단coding-review.tistory.com 저번 포스팅에선 Nginx Ingress Controller 에 letsencrypt로 발급한 키로 secret을 만들어서 SSL을 연결했습니다. 이번 포스팅에선 HPA와 CA를 이용해서 파드에 무리가 가면 파드를 늘리고 파드를 늘리는 과정에서 노드의 자원이 부족하면 노드까지 늘..

저번 포스팅에서 이어지는 내용입니다!  https://coding-review.tistory.com/557 AWS EKS 스프링 프로젝트에 NGINX 붙이기이번 포스팅은 이전 포스팅과 어느정도 이어집니다. 이전에 스프링 프로젝트를 간단하게 배포했는데 저는 추후 HTTPS를 붙여서 실제 도메인을 붙여볼 예정이기 때문에 Nginx에 스프링 프로젝트를coding-review.tistory.com 저번 포스팅에선 Nginx를 설치하고 스프링 프로젝트를 붙여서 로드밸런서를 이용해서 외부에서 접속해봤습니다.  이번엔 Nginx에 SSL을 붙여서 HTTPS를 적용시켜봤습니다. 거의 4일내내 이거만 한거같네요. 본격적으로 시작해보겠습니다! Nginx와 SSL 근데 이제 Kubernetes를 곁들인저도 Nginx에 SS..