[목차]310 [기술적 선택] 카프카의 도입 이유와 ELK-Stack과 결합한 시스템 설계 프로젝트를 진행하면서 서비스의 API 기능을 구현하는 것뿐만이 아니라 '성능 개선', '트래픽 처리'를 주제로 어떤 기술을 도입을 할지 고민을 하는 시점이 있었다. 그때 당시 ELK-Stack을 활용한 로그 수집과 프로젝트 전체 인프라 구축 및 Top-10 인기 검색어 서비스와 알림 서버 구현 등 필자가 맡은 역할은 모두 완료한 상태였다. 어떠한 기술을 도입할 지 고민하고 있을 때 많은 기업 공채에서 'kafka를 적용해본 경험이 있는 분' 이라는 글을 상당히 많이 봤었다. 그게 대체 뭐길래? 기업들이 찾는건지 그때 당시에는 정확히 알지 못했다. 모놀리식 아키텍처가 아닌 MSA 환경의 아키텍처 설계를 현재 수많은 기업들이 채택하고 활용하고 있다. 카프카는 MSA 구조에서 상당히 효율적으로 활용할 수 있는.. 프로젝트/기술적 선택 2023. 7. 23. [대규모 시스템 설계] 3. 분산 시스템을 위한 유일 ID 생성기 설계 프로젝트를 진행해봤다면 DB를 하나 정도는 활용해봤을 것이다. 하지만, 같은 용도로 활용하는 DB 서버를 분산시켜서 트래픽을 분산시키는 작업을 진행하는 것은 실무가 아닌 이상 토이 프로젝트에 적용하는 것은 상당히 힘들 것이라고 생각한다. 'auto_increment' 속성이 설정된 관계형 데이터베이스를 통해 기본 키를 쓴다면 이것은 단일 서버에 한해서다. 분산 환경에서 이 접근법은 통하지 않는다. 분산 환경에서 여러 DB를 구축을 한다면, 어느 DB로 해당 PK 값으로 데이터 정보를 불러올 것인가가 문제다. 기본적으로 데이터베이스 하나를 이용한다면 PK 값으로 해당 데이터베이스에서 Select문을 날리면 된다. 그러나 데이터베이스 서버가 여러개라면 해당 PK값을 가진 데이터가 어느 데이터베이스에 존재하는.. 개발 일지/대규모 시스템 설계 2023. 7. 23. [기술적 선택] ELK-Stack 도입 이유 및 개념 협업 프로젝트를 하다보면 정해진 목표와 과제가 매일 주어지면서 각자 맡은 역할을 충실히 하는 것이 제일 중요하다. 특히나 프로젝트의 목표물을 만들기 위해 기본적인 API를 작성하고 로직을 설계하고 테스트를 하다보면 시간이 무척 빨리 지나간다. 프로젝트는 시간이 한정적이라 서비스를 만드는 것이 급급한 나머지 성능을 개선한다거나 새로운 기술에 도전하는 것은 상당히 힘든일이다. 필자는 그 시간을 쪼개고 쪼개서 새로운 기술 "ELK-Stack"을 활용한 로그 수집가로서 활동을 하게 되었다. 도입 이유 지금까지 프로젝트를 진행하면서 로그를 활용했던 경험은 단순히 데이터를 출력하기 위함이였다. 즉, 스프링 환경에서 로깅 레벨을 INFO로 설정하여 DTO의 값이 제대로 전달되었는지에 대한 확인차 체크하는 용도였던 것.. 프로젝트/기술적 선택 2023. 7. 22. [기술적 선택] Webflux의 적용한 이유와 동작 흐름 필자는 알림 서버를 활용하기 위해 WebFlux라는 웹 프레임워크를 활용하였다. 우리가 진행한 프로젝트는 개발자 커뮤니티 서비스를 만드는 것이였고, 내부적으로 여러 서비스를 제공한다. 해당 프로젝트는 옛 싸이월드 감성으로 제작된 프로젝트였기 때문에 일촌 신청, 방명록, 댓글, 일촌 수락 등 사용자의 커뮤니티를 활성화하기 위한 서비스가 주목적이다. 따라서 다른 사용자들이 요청한, 또는 작성한 컨텐츠들과 관련된 사람들에게 알림 서비스를 제공한다. 즉, 여러 클라이언트들이 동시다발적으로 컨텐츠 요청이 들어올 경우 이를 처리하기 위해선 동기적인 방식이 아닌 새로운 방식을 고민해봐야했다. 고민 끝에 blocking 방식보다는 적은 리소스로 동시성을 다루는 non blocking 방식을 생각하게 되었고, 일반적으로.. 프로젝트/기술적 선택 2023. 7. 22. [기술적 선택] SSE 웹 기술을 활용한 이유 (알림 기능) HTTP 프로토콜은 기본적으로 클라이언트가 요청을 보내고 서버에서 응답을 보내주면 연결을 끊어버린다. 채팅과 같은 서비스에서 계속 연결을 유지하고 응답 데이터가 지속적으로 이루어져야한다면? 서버가 전송하고 싶어도 연결이 되어있지 않기 때문에 보낼 수 없는 상황이 발생할 것이다. 그래서 이러한 문제점을 해결하기 위해 폴링, 긴 폴링, 소켓, SSE의 방식이 도입이 된 것이다. Polling 클라이언트가 주기적으로 서버에게 요청을 보내는 방식을 폴링이라고 한다. 즉, 일정시간마다 클라이언트가 서버에게 데이터가 새로 생겼는지 확인하고 새로운 데이터가 있으면 응답을 받는 것이다. 정말 단순한 방식이다. 하지만 단순한만큼 계속 요청을 한다는 점에서 리소스 낭비가 발생한다. 필자의 생각은 알림이 발생하지 않는 상황.. 프로젝트/기술적 선택 2023. 7. 22. [기술적 선택] Elasticsearch 데이터 구조와 설계 방안 엘라스틱 서치를 활용하여 로그 수집과 게시글 키워드 검색 기능을 구축하면서 의아한 부분이 있었다. 역색인 구조인 것은 알겠지만, 어떻게 데이터가 저장이 되고 데이터 다중화는 어떤식으로 진행이 되는지, 가용성은 어떻게 되는지 등이 개념이 잡히지 않았다. 이번 포스팅에서는 Elasticsearch의 데이터 구조가 어떤식으로 잡혀있는지 살펴보려고 한다. 개념 정리 위의 그림을 보면 클러스터, 노드, 샤드, 인덱스로 구성되어 있는 것이 보인다. 하나씩 살펴보자. 1. 클러스터 노드들의 묶음이라고 보면 된다. 클러스터로 묶인 노드들은 노드간 데이터 교환을 위해 http 포트 (9200-9299), tcp 포트 (9300-9399)를 열어둔다. 그러므로 노드 1로 입력된 데이터를 노드 2에서 읽을 수도 있고, 그 .. 프로젝트/기술적 선택 2023. 7. 22. [대규모 시스템 설계] 2. 처리율 제한 장치 필자는 처리율 제한 장치와 관련된 처리를 해본 경험이 없다. 프로젝트를 진행하면서 필수적으로 진행해야하는 것은 API 기능 명세에 작성된 주요 서비스 구현이 1순위이다. 그러다보니 트래픽에 대한 처리는 어느순간 후순위로 밀려나게 되었다. 하지만 이전 포스팅에서 언급한 것처럼 '성능 개선', '트래픽 처리' 등 개발자 관점에서 도전적으로 프로젝트에 접근하는 것을 권장한다. 물론, 하다보면 필자처럼 시간에 쫓겨 흐지부지될 때가 많지만 시간이 넉넉한 프로젝트를 한다면 새로운 기술에 접근해보자. 이번 장에서는 클라이언트와 웹 서버 사이에 로드밸런서가 아닌 또 다른 친구가 존재하는데 그 친구를 한 번 포스팅하고자 한다. 처리율 제한 장치가 무엇인가 네트워크 시스템에서 처리율 제한 장치는 클라이언트 또는 서비스가 .. 개발 일지/대규모 시스템 설계 2023. 7. 21. [대규모 시스템 설계] 1-3. 아키텍처 설계 무상태 (stateless) 웹 계층 오늘의 포스팅은 무상태 (stateless) 웹 계층을 시작으로 천천히 알아보자. 이전 포스팅에서 생각보다 많은 것을 배워봤다. CDN을 통해 정적 컨텐츠를 캐시하고 로드밸런서를 통해 웹 서버의 분산, 데이터베이스의 다중화 및 캐시 활용 등을 배웠다. 이제 웹 계층을 수평적으로 확장하는 방법을 배워볼 순서인데, 사용자 세션 데이터와 같은 상태정보를 웹 계층에서 제거해야한다. 예를들면, 상태 정보를 관계형 데이터베이스나 NoSQL 같은 지속성 저장소에 보관하여 필요시 가져오게 하는 방법으로 말이다. 이렇게 상태정보를 웹 계층에서 제거하여 설계한 웹 계층을 무상태 웹 계층이라고 부른다. 1. 상태 정보 의존적인 아키텍처 무상태 웹 계층을 배우기전에 상태를 저장하는 웹 계.. 개발 일지/대규모 시스템 설계 2023. 7. 21. [대규모 시스템 설계] 1-2. 아키텍처 설계 데이터베이스 다중화 대규모 시스템 설계에 있어서 가장 중요한 것 중 하나는 데이터를 어떻게 보관을 하냐이다. 보통은 서버 사이에 주(master) - 부(slave) 관계를 설정하고 데이터 원본은 주서버에, 사본은 부 서버에 저장하는 방식이다. 쉽게 말하면, 나루토를 보신 분들은 아시겠지만 나루토가 주(master)이고 그림자 분신술을 써서 만들어진 복제본들이 부(slave)인 것이다. 쓰기 연산(write)은 주(mastser)에서만 지원을 하고 부(slave)에서는 master에서 사본을 전달받아 읽기 연산만을 지원한다. 필자가 프로젝트를 진행하면서 학습했던 내용은 데이터베이스에 데이터를 변경하고 삽입하는 연산보다는 읽기 연산의 비중이 훨씬 높다는 얘기들 들었다. 해당 포스팅을 보는 여러분들도 벌써 .. 개발 일지/대규모 시스템 설계 2023. 7. 20. [대규모 시스템 설계] 1-1. 아키텍처 설계 지금까지 여러 프로젝트를 진행해왔지만 서비스를 더 키우거나 많은 사용자들의 유입이 들어왔던 경험은 없었다. 사실, 실무에서의 개발 경험이 없었기 때문에 위의 사례는 극히 드물다고 생각한다. 특히, "서비스를 런칭해야지!" 라는 거대한 포부를 가지고 개인, 팀 프로젝트를 진행을 해본 분들이 계시다면 팀 동료를 제외한 실사용자 100명을 채우는 것은 상당히 힘든일이라는 것을 공감할 것이다. 즉, 트래픽을 처리하기 위한 대규모 시스템 설계는 실무 경험이 없는 신입 개발자들이 경험하기는 힘들다는 것이다. 그러면 어떻게 해야하는가? 개인적으로 학습이 필요하고 그 학습을 토대로 아키텍처를 구상해야한다고 생각한다. 최근 1년간 싸피 교육으로 개인 공부를 소홀히 하였기에 다시 포스팅을 꾸준히 시작해보려고 한다. 이번 .. 개발 일지/대규모 시스템 설계 2023. 7. 17. 이전 1 2 3 4 5 6 ··· 31 다음 반응형