로그인회원가입
트렌딩최신과거
veltrends 개발 후기
faviconvelog.io

veltrends 개발 후기

프로젝트를 만든 이유: 튜토리얼을 위한 프로젝트로 시작했으나 만들다 보니까 작업 규모가 커져버림 모바일 우선 디자인 모바일 먼저 기획하고 나중에 데스크탑으로 확장하는 방식 모바일 화면에서의 UX를 먼저 고려하고 기획 할 수 있음 서비스 기능의 핵십에 대해서 좀 더 집중 가능 모바일에서 데스크탑으로 확장 난이도는 쉬운 편 데스크탑 -> 모바일 대응은 화면이 잘리지 않도록 대응하는 느낌인 반면, 모바일 -> 데스크탑 대응은 어떻게 하면 데스크탑에서 좀 더 편하게 보여줄 수 있을지 고민하여 개선하는 느낌 Remix 후기 초심자에게 추천하기엔 아직 이르다. API 서버가 분리되어 있는 경우에 대한 가이드가 부족해서 혼자 길을 만들어가야함. action은 생각보다 불편함. 한 페이지에 데이터 쓰기가 많은 경우 처리가 까다로움 배포는 vercel로 하는게 좋음. cloudflare는 불편한 점들이 몇가지 있음 Remix vs Next.js 상황에 따라 다른 선택을 할 것 Terraform 인프라 설정을 코드로 유지보수 할 수 있게 해줌 써보니 좋았다. Fastify Fastify를 택한 이유: Nest.js 는 별로 안 좋아하고 더 좋은 선택지를 찾다가 Typebox Type Provider를 사용하면 JSON Schema와 TypeScript 연동을 훨씬 쉽게 할 수 있음 Prisma 스키마 관리가 용이함 특정 필드만 select 했을 때 전용 Type을 따로 만들어줘서 실수 방지 앞으로 veltrends 계획: 서비스 활성화에 도움을 줄 수 있는 것들을 우선으로 구현

좋아요 15
댓글 5
by velopert · 약 1개월 전
Discord는 어떻게 10억 단위의 실시간 메시지를 인덱싱할까?
faviconSukhad Anand · Geek Culture

Discord는 어떻게 10억 단위의 실시간 메시지를 인덱싱할까?

Discord는 엄청나게 많은 사용자들이 하루에 10억 단위의 메시지를 보내곤합니다. 사용자들은 해당 메시지들을 다시 검색을 하고 싶기도 하지요. Discord에서는 메시지 검색 기능을 제공하기 위해서 데이터를 어떻게 인덱싱을 하고 있을까요? Discord에서는 ElasticSearch를 사용함 ElasticSearch엔 데이터를 JSON 형태로 담음 ElasticSearch는 내부적으로 Inverted index를 생성함. Inverted Index란 낱말이나 숫자와 같은 내용물로부터의 매핑 정보를 데이터베이스 파일의 특정 지점이나 문서 또는 문서 집합 안에 저장하는 색인 데이터 구조 Inverted Index를 통해 Discord에서 데이터를 거의 실시간으로 빠르게 찾을 수 있음 인덱싱이 실시간으로 이뤄지지 않음. 데이터는 벌크로 등록됨. 방금 올라온 메시지를 검색하는일은 잘 없어도, 옛날 메시지는 검색하는 일이 많기 때문에 이러한 구조가 괜찮음 벌크 인덱싱을 하기 위해서 다음 작업을 함 분산화된 Queue를 사용하여 들어오는 메시지를 임시적으로 담음 Indexer Worker 여러대를 사용해서 ElasticSearch에 데이터를 벌크로 등록함 Discord에서는 Queue를 위해 Celery를 사용함. 오픈소스 분산 Queue 소프트웨어임. ElasticSearch 서버도 여러대를 사용중임. 클러스터라는 개념 사용. 데이터는 어떤 클러스터에 담길까? Sharp Allocator를 사용하여 어디에 데이터를 담을지 판단 돌아가고 있는 ElasticSerach 클러스터들을 관리하기 위해서 etcd 라는 오픈소스 사용함.

좋아요 8
댓글 3
by velopert · 약 1개월 전
대기업들이 시장에 MSA라는 독을 풀었다.
faviconshirohoo

대기업들이 시장에 MSA라는 독을 풀었다.

MSA는 여러 대 기업에게는 축복이겠지만, 대기업을 선망하는 스타트업, 중소기업은 충분한 고민 없이 이를 쉽게 따라해서는 안된다. MSA의 위대함에 대해 설파하는 기업들의 공통점: DB가 SPOF(Single Point of Failure)됐다 트래픽과 데이터가 많아서 DB에 장애가 발생했고 그 장애가 모든 서비스로 전파 생존하기 위하여 MSA로의 전환 웹 애플리케이션은 스케일 아웃을 하면 I/O 부하 분산, CPU 부하 분산됨 웹 개발에서 피해야 하는 것은 느린 디스크에서 작업하는 것 디스크의 데이터에 메모리에 캐싱하면 디스크 I/O 줄일 수 있음. DB의 메모리의 용량을 키워 최대한 많은 데이터를 캐싱할 수 있게 스케일업을 주로 하게 됨 DB성능이 안나오면 테이블, 쿼리 최적화, 물리 메모리 확대 계속해서 DB 장애가 발생하면 MSA로의 전환을 고려해볼 최소 요건이 된다고 생각함 작성자의 회사에서는 잘못된 기술적인 판단과 결정으로 아루 이른 시 기에 MSA로의 전환을 하여 실효를 거두기 못하면서 트래픽이 많지 않음에도 불구하고 한달 약 4천만의 서버비만 부담된 적이 있음 쪼개진 서비스를 재통합중, 비용이 줄어들고있음 (이번달 2천만원) MSA로 긍정적인 효과를 본 것이 없고 상처만 남았음 너무 일찍 MSA를 도입하는 것 보다는, 나중에 MSA의 전환이 수월할 수 있도록 프로젝트를 모노레포 + 멀티모듈로 설계하고 추후 모듈 하나를 마이크로 서비스로 쉽게 분리할 수 있게 구성하는 것이 더욱 현명할 것.

좋아요 4
by velopert · 약 1개월 전
29CM 카테고리 자동완성 기능 개발기
faviconCirclee7 · Geek Culture

29CM 카테고리 자동완성 기능 개발기

29CM 카테고리 자동완성 기능 개발을 담당한 백엔드 개발자가 공유해주는 이야기입니다. 29CM의 카테고리 자동완성 기능이란 "코트" 라고 입력시 "트렌치 코트", "더블 코트" 등의 카테고리 링크를 제공하는 기능 개발 시작시 개발디자인 문서를 작성하여 팀내 리뷰어 분들과 함께 개발방향과 대안 배포전략등을 논의함 기능 구현에 있어서 3가지 옵션이 있었음 클라이언트 사이드 구현 서버 사이드 구현 (ElasticSearch 미사용) 서버 사이드 구현 (ElasticSearch 사용) ES(ElasticSearch) 를 사용하면 형태소 붙석 및 유사어 검색을 통해 편의성을 제공해줄 수 있으나 데이터 적재 작업이 선행되어야 하는게 공수가 컸으며, 개발자 본인은 ES 대한 경험이 부족했음 2안, ES 없이 구축하는 결정을 내림. Trie) 구조체를 통한 자동완성 기능을 개발하기로 결정함 실험이 성공한다면 확장성 있는 장기 목표를 잡고 계획을 세운다 Trie 구조체는 단기적인 방법. 추후 기능의 효용성이 검증된다면 Long term 솔루션을 실행해야함 이 때문에 추후 ES 로의 전환을 위한 마일스톤도 작성함 배운 점 카테고리 자동완성 기능을 위한 개발 디자인 문서를 작성하면서 여러 방법과 대안을 모색하고 빠른 의사결정을 할 수 있었음 기능의 목표와 목표가 아닌 것을 명확하게 하여 요구사항을 준수하는 빠른 실험 방법을 찾을 수 있었음 장기적인 개선 방향을 명확히하여 확장된 실험을 시작하기 위한 준비도 할 수 있었음

좋아요 4
by velopert · 약 1개월 전
Recoil.js 를 사용하면서 배운 것들
faviconWritten by · Kitemaker

Recoil.js 를 사용하면서 배운 것들

Kitemaker에서 Recoil을 사용하면서 배운 점들을 정리하여 포스트로 올렸습니다. 기존엔 이 회사에서는 useReducer를 사용하여 간단한 상태관리를 해왔다고 합니다. 앱에서 다루는 데이터가 무수히 많아지면서 불필요한 리렌더링이 많이 발생해서 사용자 인터랙션에 따라 즉각적으로 반응하는 빠른 UX를 제공함에 있어서 어려움이 있었다고 하네요. 불필요한 리렌더를 줄이기 위하여 Recoil을 적용했다고합니다. API가 명확하고 이미 익숙했던 Redux랑 비슷한점도 있어서 사용하기 편했다고합니다. 추갖거으로, Meta팀이 성능 높은 UI를 다루기위해서 Recoil을 설계했다는 점이 결정에 있어서 중요한 역할을 했다고 합니다. 이 결정에 대해서 굉장히 만족스럽고, 적용 후 많은 개선이 있었으며 사용하면서 몇가지 배움이 있었다고 합니다. 높은 성능을 위해서 무엇이 렌더를 유발하는지 잘 이해하고, selectors를 잘 준비하는 것이 중요합니다. selector에서 새로운 배열이나 새로운 객체를 반환한다면 리렌더를 유발하기때문에 referentially equal (===) 한 값을 반환하는게 굉장히 중요합니다. 커스텀 Equality Check 활용한 성능 개선 Transaction을 활용하여 여러 종류의 업데이트를 한번에 몰아서 실행 atom의 수를 주시할것. atom이 너무 많아지면 성능에 영향을 끼침. 함께 렌더링되는 것이 있다면 가급적 하나의 atom으로 합쳐서 할 것 Recoil을 사용하여 불필요한 리렌더링을 많이 줄였지만, Recoil은 Magic이 아닙니다. 제대로 사용하기 위해서, 성능을 잘 최적하기 위해서는 충분한 시간이 필요합니다.

좋아요 4
by velopert · 약 1개월 전