책 내용이 쉽지 않아 이해가 잘가지 않았던 부분에 나만의 주석을 달아놓기 위함+ 실무적으로 참고하고 싶은 부분4장 아키텍쳐4.2.1 프라이머리 키에 의한 클러스터링p 99. '프라이머리 키가 클러스터링 인덱스이기 때문에 프라이머리 키를 이용한 레인지 스캔은 상당히 빨리 처리 될 수 있다'프라이머리 키에 의한 클러스터링이란, 데이터의 실제 물리적 주소가 PK 값을 기준으로 배열되어있다는 뜻이다. 클러스터링 키를 지원하지 않는 MyISAM 엔진의 경우 데이터의 물리적 주소는 여기저기 분산되어있고, 인덱스는 이 주소값을 가지고 있는 방식으로 동작한다. 전자(클러스터링 키) 가 후자(비 클러스터링 키) 보다 근본적으로 성능의 차이를 보이는 이유는 데이터의 물리적인 주소가 한군데에 같이 모여 있다는 것이다. 그렇..
분류 전체보기
처음엔 플로이드 워셜로 시도했다. 플로이드 워셜이 N^3 인데 N 이 1000 이고 대충 1초 정도를 예상했음. 그런데 시간초과가 나서 다익스트라로 AC 를 받았다. (32ms) 그런데 0ms 가 기록에 있는 걸 보고 풀이를 봤는데, 다익스트라로 생각지 못한 풀이가 있어서 남겨봄.* 참고로 플로이드워셜로도 최적화하면 풀리긴 함. 가장 먼저 떠오른건 플로이드 워셜 알고리즘이었다. 왜냐하면 다익스트라는 한점에서 다른 모든 점까지의 최단거리를 구하는 알고리즘인데, 이번 문제의 조건은 모든 점에서 특정 점까지의 최단거리를 구해야하니까 적절하지 않다고 생각했음. 그런데 다익스트라는 한점에서 다른 모든 지점으로의 최단거리 뿐만 아니라 한 점으로 도착하는 다른 모든 점에서부터의 최단거리 또한 구할 수 있다. !!..
이전에 진행한 내잔고를 부탁해 프로젝트에서는 Redis 를 활용한 캐싱 처리를 제대로 사용하지 못한 느낌이 있었다. 그때는 어떤 데이터를 캐싱해야할지 잘 감이 안와서 그냥 남들 하는대로 Refresh 토큰을 저장해두는 정도로만 활용하였다. 대신 채팅 기능을 구현할 때 사용자의 구독 정보 관리와 서버간 메세지 브로커로 활용한 바 있다. 물론 대규모의 트래픽 처리를 하는 경우에는 메세지 브로커로 Kafka 를 쓰겠지만, 그래도 알차게 Redis 를 활용했다고 생각한다. 이번 프로젝트에서는 Redis 의 캐싱 기능을 더 야무지게 활용하여 api 응답 시간을 줄이고자 하였다. 사실 기술적으로 별 내용은 아닌데 나름 참고할만한 유즈케이스 같아서 기록해 둔다.1. 캐싱 데이터캐싱 처리는 데이터를 가지고 올때 DB ..
https://www.acmicpc.net/problem/11049 그리디와 dp 를 두고 세시간 넘게 고민하다가 뇌가 안되는거 같아서 포기하고 풀이방향을 보고 풀었다. dp 는 어느정도 익숙해졌다 싶었는데, 이렇게 과감하게도 풀 수 있구나 싶어서 꼭 기억을 해두려고 한다. 너무 분해.dp 라는 생각이 가장 직관적으로 다가왔는데, 점화식을 어떻게 잡아야 할지 감이 안왔다. 기본적으로 dp[start][end] = start 부터 end 까지 연산의 최소값 으로 메모이제이션을 하는 쉽게 알 수 있다. 그런데 여기서dp[start][end] 와 dp[start][end + 1] 사이의 관계식(점화식)은 어떻게 만들까? 둘에 관계가 보이지 않았다.start ~ end 에서 start ~ end + 1 한개만 ..
현재 comppi 는 dev 환경만 구축이 되어있는 상태인데, 이제 배포가 임박하여 prod 환경을 구축하고 배포하려고 한다. 지금은 컨트롤 플레인까지 총 4개의 노드에서 dev 어플리케이션을 구동하고 있는데, 이제 배포할 prod 는 dev 를 동일한 노드에서 운용해도 될 정도로 하드웨어 리소스가 충분하지도 않고, 가능한 개발 서버와 운영 서버의 환경을 분리하고 싶었다. 개발 PC 를 클러스터에 포함시켜서 별도로 3개 정도의 worker 노드를 추가하여 그쪽에 dev 환경을 구축/배포하고, 기존의 운영 서버에서는 운영 환경을 격리시켜 놓으려고 한다. 여튼 오늘 정리하려는 글은 쿠버네티스 클러스터에 개발 PC 를 추가하기 위해서 또다시 VM 을 올리고, 쿠버네티스 환경을 프로비저닝해줘야 했는데, 해당 과..
쿠버네티스에 cicd 파이프라인을 구축했다. 상당히 많이 헤맸다. 헤맸던 이유는 머리속에 cicd 가 이뤄지는 구조를 분명히 그리지 못해서 그런거 같다. cici 의 대상에 대해서 분명히 설정하고, 어떤 도구들이 어떤 대상을 바라보고 있는지 확실하게 인지하고 있었으면 조금 더 명쾌하게 해결이 되었을 것 같다. 사실 그렇게 복잡한 구조도 아닌데, 퇴근후에 지친 상태로 프로젝트를 진행하면 빨리 끝내고 쉬고 싶은 생각이 들고 머리도 잘 안돌아가서 바보 같이 대충대충 빨리 하게된다... 지금에서야 배포 파이프라인의 구조가 명확하게 머리속에서 그려지기 때문에 문제가 없는데 어쩐지 다른 공부를 계속하다보면 휘발될지도 모르겠다는 생각에 부랴부랴 구축 과정과 파이프라인 구조를 정리 해둔다. 1. Kubernetes ..
comppi 의 0.1.0 버전 개발(MVP) 이 어느정도 마무리가 되면서 드디어 미뤄왔던 운영 서버를 올리는 작업에 착수했다. 현재 생각은 24 시간 돌아가는 서버용 PC 에는 운영서버를, 개발할 때만 켜두는 개발PC 에 개발 서버를 올려서, 운영서버에는 부담이 가지 않도록 하는 것이다. 이런 경우 개발 PC에 별도의 쿠버네티스 클러스터를 만들어두고 운용하는 편이 좋을 것 같은데, 그렇게 되면 클러스터 외부에 로드밸런서를 달아야 한다. 왜냐면 난 공용 IP 가 하나이고 때문에 도메인에 따라서 어떤 클러스터로 보낼지 정해줘야 하기 때문이다. 물론 이렇게 할 수도 있지만, 일이 너무 커지는 것 같기도 하고 쿠버네티스의 여러가지 오브젝트를 다뤄보고 싶은 욕심도 있었어서, 두개의 PC 를 하나의 쿠버네티스 ..
기존에 VirtualBox 에서 VM 을 생성하여 쿠버네티스 클러스터를 구축·운영하였는데, Type1 Hypervisor 라는 개념을 알게되어 Type 1 Hypervisor 인 Proxmox 위에서 쿠버네티스 클러스터를 재구축하였다. 간단하게 Type1, Type2 하이퍼바이저의 차이와 Proxmox 클러스터 구축 과정, 추후 숙제를 정리해두려고 한다. 1. Hipervisor Type1/Type2 하이퍼바이저는 가상화를 제공하는 플랫폼 소프트웨어를 말한다. 내가 기존에 사용하던 VirtualBox(Oracle) 나 Vmware 같이 가상머신을 생성, 실행, 리소스 관리하는 기능을 수행한다. 쿠버네티스나 도커같이 컨테이너 관련 플랫폼도 가상화의 영역이긴 하지만, OS 수준에서 구현된 컨테이너 런타임에 ..
이전 글 [ https://techforme.tistory.com/60 ] 이전 글에서는 MVCC 에 대해서 아주 간략하게 알아보았다. MVCC 의 구조, 자세한 동작 방식을 더 알아보면 좋겠지만 "동시성 제어" 라는 매커니즘에 한정해서 하나의 예시만을 들었다. (나중에 제대로 공부하기로 하고...) 이번 글에서는 Lost Update 가 발생하는 상황에서 MVCC 와 Lock 이 각각 어떻게 문제를 해결하는 지 알아보고 각각의 장단점과 함께 "낙관적 락" 과 "비관적 락" 의 개념을 알아 본다. 1. Lost Update 1) Lost Update 란? Lost Update 란 말 그대로 Update 쿼리가 유실되는 상황을 말합니다. Lost Update 가 일어나는 간단한 상황을 제시하겠습니다. 초기..
이전 글 [ https://techforme.tistory.com/59 ] 이전 글에서 동시성 제어를 위한 기술인 'Lock' 에 대해서 알아보았다. Lock 이 어떤식으로 Transaction 의 Schedule 을 컨트롤 하는지, 그리고 Lock 획득하고 반환하는 절차에 따라 어떤 영향(Deadlock 발생, Recoverability 보장)이 나타나는지에 대해서도 알아보았다. Lock 의 경우 Read 와 Write 가 상호 배타적으로 작업을 수행하게 되는데 (Read Lock 이 걸린 자원에 대해서는 Write Lock 을 획득할 수 없거나 반대로 Write Lock 이 걸린 자원은 Read Lock 획득이 불가능함) 이런 경우 Concurrency 가 상당히 떨어지기 때문에 성능면에서 아쉬울 수..
