분산 처리 시스템에 대해 깨달은 바
분산 처리 시스템이 무엇인가에 대해 어렴풋이 알고는 있었지만, 속 시원하게 이해된다는 느낌은 받지 못했다
아마 왜 그런 구조가 되어야만 했는지를 파악하지 못해서 그런 것 같다
그러다가 이번에 쿠버네티스와 엘라스틱서치에 대해 알아보면서, 분산 처리 시스템의 구조와 왜 그렇게 구성이 되어야 했는지를 이해하게 되어서 글을 적어보았다
별 내용은 아니지만 한눈에 구조를 이해하게 된 시점이라 내용을 정리해보려고 한다
필요성?
DB의 테이블을 예시로 들어보자. 이는 특정 의미를 가지는 데이터의 집합이라고 할 수 있다
처음에는 잘 설계된대로 하나의 의미를 가졌을 것이다. 그렇지만 서비스가 확장되고 기능이 많아지면서, 데이터는 여러 의미를 가지게 된다
이때 우리는 리팩토링을 고려하게 된다. 너무 많은 의미를 가지게 되었으니 적절히 분리하기 위함이다
하지만 데이터가 가지는 의미가 많아지는 것이 아니라, 양 자체가 많아지게 된다면?
50GB로 설정한 데이터가 어느새 500GB가 넘어가게 된다면?
이럴경우 고민하는 것이 바로 분산 처리 시스템이다
일단 쪼개보자!
분산 저장 구조가 필요한 이유는 방대한 양의 데이터를 하나에 몰아 저장하기엔 어려우므로 잘게 쪼개서 나누자는 것이다
일단 나눠보고 나서 생각하자. 가령 500GB의 User 데이터가 있었으니, 50GB 씩 10개로 나눠서 저장해보자
User_Table1, User_Table2, … 이렇게 10개의 저장소가 생겨났다
어떻게 접근?
나눠진 것은 좋은데, 문제는 접근성이다. 어떻게 저장하고 조회할 것인가?
10개 테이블로 나눠졌으니 각각 지정해서, 하나는 User_Table1 에다 저장하고 나머지는 User_Table2 에다 저장하는 등의 방식으로 진행되어야 할까?
아니다. 특별한 의미가 있어서 나눈게 아닌, 단순히 관리의 용이를 위해 10개로 나눈 것이다. 여전히 데이터는 User 하나의 의미만 갖는다
즉 User에다 저장한다 라는 식으로 진행되야 한다는 것이다
논리적 공간 생성!
사용하는 입장(외부)에서는 어디에 저장되는가?는 관심이 없다
반면 내부에서는 실제 지정된 테이블에 저장되어야 한다
해결방법은 바로 논리적 공간을 중간에 두는 것이다
.
.
.
User 라는 논리적 공간을 만들고, 이를 User_Table 1~10과 연결한다
이렇게 만들면 사용할 때는 User 에다 저장하지만, 실제로는 물리적 테이블에 저장이 된다
논리적 공간과 물리적 공간 연결!
그럼 User와 User_Shard는 어떻게 연결이 되는 것일까?
그것이 바로 라우팅, 맵핑, 혹은 로드 밸런싱이라고 부르는 기술로, 고르게 잘 분산되어 저장할 수 있도록 도움을 준다
여기까지를 요약하자면
논리적 공간인 User를 앞에 두고, 내부적으로는 라우팅, 맵핑, 혹은 로드 밸런싱을 통해 각 물리적 공간에 저장한다
