이전 글 : Recoverability 란? [ https://techforme.tistory.com/58 ] 이전까지 동시에 요청된 Transaction 의 처리 Schedule 과 관련한 두가지 특성인 Serializability, Recoverability 를 알아보았다. 이는 동시성 제어(Concurrency Control) 시 고려해야할 두가지 조건이라고 할 수 있으며, 두 특성을 보장하지 못하는 경우 Transaction 이 의도치 않은 결과를 일으킬 가능성이 있게 된다. 이번 글에서는 이러한 Scheduling 을 위한 전략인 Lock 에 대해서 알아본다. 1. Lock 1) lock 이란? DB 는 Transaction 을 Scheduling 하는 전략으로 'Lock' 이라는 매커니즘을 사..
분류 전체보기
이전 글 : Serializability 란? [ https://techforme.tistory.com/57 ] 이전 글에서 트랜잭션의 동시성 제어중 Serializability 에 대해서 알아 보았다. 이를 통해 Serializability를 보장하도록 Transaction 을 스케줄링 함으로써 Non-Serial 한 트랜잭션 처리의 결과를 Serial 하도록 만들 수 있었다. 그러나 해당 글에서는 Transaction 이 Rollback 되는 상황을 고려하지 않았는데, Transaction 은 어떠한 경우에서도 오류가 발생하였을 때 Rollback 을 통해 이를 안전하게 되돌릴 수 있도록 보장되어야 한다. (Recoverable) 이번 글에서는 이러한 Recoverable 특성과 관련하여, Tra..
프로젝트가 끝나고 운영체제와 네트워크 강의를 들으며 얀전히(?) CS 지식을 쌓고 있었다. 이는 개발자로서 기본소양을 쌓기 위한 목적이었지만, 당연히 기술 면접에 대한 준비의 일환이기도 했다. 꾸준히 지식을 쌓고 있으면 면접에서도 당당할 수 있지 않을까 했는데 너무 안일한 생각이었다. 인터넷에서 기술면접에서 단골로 나온다는 질문 리스트를 찾아보니, 대부분 한마디도 대답할 수 없는 것들이었기 때문이다. 그래도 다른 질문들은 검색해보면 어렴풋이는 알 것 같은 개념이긴 했는데, "MVCC 가 무엇인가?" 라는 질문은 검색해서 관련 포스팅을 읽고 나서도 전혀 오리무중이었다. 발등에 불이 떨어진 기분으로, DB 에서의 동시성 제어(Concurrency Control) 의 기본적인 공부들을 했고, 지식이 MVC..
이 문제는 2022 카카오 인턴십 코딩 테스트 문제로, 이번에 본 2024 겨울 인턴십 코딩 테스트를 대비하기 위해서 풀었던 문제이다. 처음에 dp 로 시도했다가 테스트 케이스를 다 맞추지 못해서, 다익스트라를 적용해서 간신히 풀어내었다. 다익스트라도 자꾸 시간 초과가 나서 최적화를 하는데 애먹었다. 각각의 접근 방식을 정리해두고 최종적으로 AC 받은 다익스트라 알고리즘의 최적화 방법도 남겨 놓는다. 1. 기본 아이디어 1) 정상에서 다시 입구로 갈때 중복된 간선을 이용해도 되기 때문에, 입구에서 정상까지 가는 단일한 경로만 고려한다. 2) 다른 출발점이나 정상을 경유하는 경로는 고려하지 않는다. 위 두가지 아이디어를 전제로 두고 아래와 같이 알고리즘을 짰다. 2. DP [틀림] 1) 각 출발점에서 df..
백준에서 골드 문제를 랜덤으로 돌리던 중 1414번 불우이웃돕기를 만나게 되었다. 한 30 ~ 40분 정도를 고민해서 풀이의 방향은 잡았었는데, 내 생각에 자신이 없어서 결국 풀이를 검색했다. MST(Minimum Spanning Tree) 라는 부류의 문제였고 MST 를 푸는 대표적인 알고리즘 중 하나인 크루스칼 알고리즘이 내 초기 아이디어와 거의 동일한 방법이었다는 것을 알게 되었다. '그냥 내 풀이대로 밀고나가볼걸' 이라는 아쉬움을 느끼긴 했지만, 확신할 수 없는(다시 말해 증명할 수 없는) 직관은 허무할 수 밖에 없다라는 결론에 도달하게 되었다. 크루스칼 알고리즘은 사실 간단하다. 그리디라는 기본 자세를 가지고 가지를 뻗어나가면 되는 것이다. 나 정도의 사람도 직관적으로 떠올릴 수 있는 방법이다...
이전글 [https://techforme.tistory.com/48] 이전글에서 서버를 이중화 하면서 authorization_request_not_found 오류가 나는 상황에 대한 해결책으로 ip hash 방식의 부하분산을 이야기 했었다. 이는 간단한 해결책이긴 했지만, 만약 부하 분산 방식을 round robin 으로 바꾸라는 요구사항이 생긴다면, 전혀 대응할 수 없는 미봉책이었다. (사실 Nginx 를 더 활용해 보고 싶어서 해봤다.) 근본적인 해결책이 필요했다. 이번 게시글에서는 OAuth Authorization 요청 정보를 서버 내부에 저장하지 않고 외부에 저장함으로써, Nginx 의 부하 분산 알고리즘과 상관없이 해당 문제를 해결할 수 있는 방법을 설명한다.1. 문제 상황 분석1) 문제 발..
이전에 지리데이터를 다루면서 "클러스터링" 이라는 단어를 잘 모르고 쓴 적이 있다. 개발 초기, 창고의 검색 방식에 대해 고민하다가 "위치 정보 데이터가 많아지면 대체 원하는 정보를 어떻게 조회해오지?" 라는 거의 공상에 가까운 생각을 했다. 일단은 어떤 한 점(위경도)에서 주어진 반경 내의 데이터를 조회한다고 했을 때, 가장 먼저 떠올릴 수 있는 방법은 모든 데이터와의 거리를 일일이 다 계산해서 주어진 반경 내에 있는지 판단하는 방식을 먼저 떠올렸다. (그때는 풀 스캔, 시퀀셜 스캔이라는 단어도 몰라서 내가 알고 있는 단어인 브루트 포스 단어로 이 방법을 지칭했다.) 그러다가 당근 마켓을 떠올렸고 비슷한 지역끼리 묶어서 그 근처 지역만 먼저 조회하면 되지 않나? 라는 생각에서 "클러스터링" 이라는 말을..
이전 포스팅에서 무중단 배포를 rolling 방식, blue-green 방식으로 구현했었다. 그렇게 해놓고 보니, 서버가 이중화 되었을 때도 기능들이 제대로 동작하는지 테스트 하고 싶어졌다. 단일 서버였다가 서버 개수가 두 개 이상으로 늘어나면 각각의 요청이 동일한 서버가 아닌 다른 서버로 연결 되기 때문에 예기치 않은 문제들이 생길 수 있다. 특히 서버 내부의 메모리로 관리하는 자료가 있다면 문제가 발생하기 쉽다. 이 경우 서버의 메모리마다 관리하는 정보가 각각 달라지는데 만약 요청을 서로 다른 서버가 처리하게 되면 동일한 결과가 나오지 않게 되기 때문이다. stateful 한 서버가 되는 것이다. 예를 들어 로그인 정보를 각각의 서버에서 저장하고 있게 되면 로그인 정보를 가지고 있지 않은 서버에 요..
저번 포스팅에서 무중단 배포를 구현하면서 blue-green / rolling / develop 세가지 방식의 배포를 전부 구현했었는데, 그중에 develop 배포 방식은 기존 브랜치의 배포(8080, 8081 포트)를 중단하고 8082 포트에서 develop 브랜치를 배포 새롭게 배포를 하는 식으로 동작했었다. 이것도 무중단으로 동작하긴 하지만 사실 개발 단계의 서버를 그대로 노출하게 되므로 아무 의미가 없는 배포 방식이었다. 개발용 서버는 개발자나 QA 같은 특정 집단의 사람들만 이용할 수 있도록 하고, 기존 서비스는 그대로 유지해야 제대로 된 동작 방식이라는 생각이 들었다. 그래서 이렇게 바꿔봤다. 1. Nginx 설정1) 요청 식별특정 ip 만 특정 업스트림으로 보내도록 Nginx 설정을 수정했..
무중단 배포와 자동화 배포얼마전에 유튜브 영상을 보는데 CI/CD 라는 말이 오용되는 케이스가 있다는 이야기를 들었다. 최근 신입 개발자 이력서에 Jenkins 나 Github Actions 를 이용해서 자동으로 프로젝트를 배포하는 구조를 모두 CI/CD 라고 칭하는 경향이 있는데, 사실 자동화 배포 툴로 배포를 진행한다고 해도 프로젝트가 빌드되는 시간동안 배포가 중단된다면 이는 엄밀히 말해 중단없이 연속적으로 배포된다는 의미의 CD(Continuos Deploy) 라 할 수 없으며 단순히 자동화 배포라고 이야기 해야한다는 말이었다. 그렇게 보니 우리 프로젝트 또한 빌드 시간 동안 배포가 끊기게 되는 자동화 배포 구조로 동작하고 있었다. 최근에 내 이력서를 보고 공부가 웹어플리케이션 개발에 치중되어 웹..
