🥊

본문 바로가기

전체 글

Node.js의 이벤트 루프 노드를 사용하는 회사에 가게되어서, 노드를 배우고 있는데... 자바스크립트나 노드나 다 처음 배우고 있어서 어려운 것이 많은 거 같다. 특히 이해하기 어려운게 이벤트 루프(Event Loop)였고, 핵심적인 부분인 것 같다고 느꼈다. 노드와 관련된 모든 이야기가 이벤트 루프로 모이는듯한 느낌을 받았기 때문이다. 그래서 이걸 이해한다면 노드의 구성 요소와 동작 방식은 물론이고 우선순위가 나뉘어져있는 비동기작업들을 잘 구분하고 설정할 수 있다고 생각했다. 그런 이유로 이번 글에서 이벤트 루프를 중심으로 노드와 관련된 여러가지 지식들도 함께 정리하면서 공부해볼 생각이다. 공부를 하면서 글도 함께 작성하고 있기 때문에, 부정확한 정보가 있을 수도 있다! 그러한 부분들은 실무를 경험하며 차차 수정해나가보겠다. .. 더보기

MySQL에서 ACID를 보장하는 방법 개요MySQL과 같은 RDB는 안전하고 신뢰할 수 있는 트랜잭션을 보장하기 위해 ACID 성질을 핵심 원칙으로 삼고 이를 구현하고 있다. 보통 ACID 성질은 아래와 같이 정의된다.Atomicity (원자성): 트랜잭션의 모든 작업은 전부 처리되거나, 하나도 처리되지 않아야 한다.Consistency (일관성): 트랜잭션이 완료된 후, 데이터베이스는 일관된 상태(규칙, 제약 조건)를 유지해야 한다.Isolation (독립성): 동시에 수행되는 여러 트랜잭션은 서로 영향을 미치지 않고 독립적으로 동작해야 한다.Durability (지속성): 성공적으로 완료된 트랜잭션의 결과는 영구적으로 반영되어야 한다.정의에 대해서는 잘 알고있지만, 데이터베이스에서 이를 어떻게 보장하고 있는지 자세한 내용을 공부해보진 않.. 더보기

공간 쿼리를 데이터 관점으로 완전 개선하다. 취준생으로 이루어진 팀이다보니, 인프라에 돈을 최대한 아끼고자 t4g.micro로 DB를 운영하기로 결정했다. 그런데, 이 스펙에서 공간 쿼리를 수행하게 되면 CPU 집약적인 공간 쿼리 특성상 약 2~3초의 시간이 걸려 응답이 올만큼 느려졌다. 그래서 처음에는 공간 쿼리 자체를 최적화 하기 위해서 여러 방안을 시도했다. 기존에는 $nearSphere라는 공간 쿼리를 통해 주어진 사용자의 위치에서 반지름이 1~3km로 이루어진 원 이내에 포함 및 걸쳐 지나가는 러닝 코스를 조회하고 있었다. 그래서 MongoDB에서 제공하고 있는 공간 쿼리 중 나머지 2개를 통해 이를 최적화 해보고자 했다. $geoIntersects해당 쿼리는 기준이 되는 도형이 주어지면, 그 도형을 지나는 공간 데이터를 조회해준다. 다만.. 더보기

MySQL과 MongoDB 공간 인덱스의 차이 개요런세권 프로젝트를 개발하며 MySQL에서 MongoDB로 마이그레이션했고, 그 결과 API 응답 속도를 크게 개선할 수 있었다. 처음에는 단순히 NoSQL인 MongoDB가 더 빠르다고만 생각했는데, 이 글을 쓰며 그 차이가 공간 인덱스가 도형을 근사하는 방식의 차이에서 비롯된다는 것을 이해했다. 이 글에서는 공간 데이터의 기본 개념부터 MySQL과 MongoDB가 각각 공간 데이터를 저장하고 인덱싱하는 방식을 비교하며, 그 내부 동작 원리를 정리한다. 공간 데이터란 무엇인가?공간 데이터는 기하학적 개체의 물리적 위치 및 모양에 대한 정보를 나타내며, GIS 서비스에서 핵심적으로 사용되는 데이터이다. 공간 데이터와 관련된 표준은 OGC(Open Geospatial Consortium, 개방형 공간 정.. 더보기

RPC(Remote Procedure Call)란 무엇일까? 0. 개요원격 함수 호출 말 그대로 물리적으로 떨어져있는 서버 간의 통신을 로컬에서 함수를 호출하듯 동작하도록 만들어주는 개념이다. 여기서 핵심은 호출하는 쪽에서 로컬에 있는 함수를 호출하는 것처럼 사용할 수 있다는 것이다. 기존에 흔히 REST 방식의 서버 API를 만들 때를 생각해보면 URL로 자원의 경로를 설정하고 HTTP 메서드를 통해 자원에 어떤 행위를 할지 결정하고 필요한 데이터를 JSON 구조로 받아 처리했다. 즉, 자원 중심의 API를 설계했다. 하지만 RPC는 자원이 아닌 행위에 초점을 맞추어 API를 설계한다. REST에서 서버와 클라이언트가 요청/응답에 대한 JSON 구조를 정의하듯, RPC는 요청/응답에 필요한 데이터 스키마를 정의한다. 그리고 REST에서 URL로 자원의 경로와 H.. 더보기

Fielding이 말하는 진짜 REST API REST API를 만든 장본인 Fielding은 2008년에 REST APIs must be hypertext-driven 라는 글을 작성했다. 해당 글의 내용을 보면 Fielding이 설계한 REST API는 다음의 규칙을 따라야한다.자원의 식별자와 접근 방법은 구분되어야 한다.표준 프로토콜을 있는 그대로 써라.API 문서에 URL 목록을 나열하지 마라. 대신, 응답 형태를 잘 정의해라.고정된 자원 이름, 계층 구조를 사용하지마라.타입이 지정된 자원을 가지지 마라.사전 지식없이 진입할 수 있게 하라.이러한 규칙을 따르지 않을거면 REST API라 부르지도 말고, 다른 유행어를 골라 쓰라는 말까지 할 정도로 REST API의 핵심이라고 강조하고 있다. 도대체 어떤 내용이길래 Fielding이 이렇게까지 .. 더보기

1개의 재고가 있을 때 동시에 100명의 사용자가 요청하면? 최근 면접에서 제목에 대한 질문을 받았다. "1개의 재고가 있을 때 동시에 100명의 사용자가 요청하면 어떻게 처리하시겠어요?" 현재 진행 중인 두 프로젝트가 동시성에 대해서 고려하지 않아도 되는 서비스이다보니 자연스레 이런 부분에 대한 학습을 하지 못했기에 질문을 받았을 때 당황했다. 그래서 정말 생각나는대로 답변을 했다."저는 비관적 락을 통해 동시성을 제어할 것 같습니다. 낙관적 락의 경우 사용자 1명이 구매를 진행하는 동안 나머지 99명은 재고가 있음을 확인하고 구매를 시도할텐데, 이때 재고가 없다면 사용자 경험 측면에서 그닥 좋은 인상을 남기지 못할 것 같습니다." 이에 성능에 대한 질문도 나왔고, 이렇게 답했다. "비관적 락이 성능면에서 손해를 보는 건 맞습니다. 그래서 주문, 결제 사이의 트.. 더보기

자바로 GitHub Actions 라이브러리 만들기 팀 프로젝트를 하다 보면 PR이 올라온 뒤 리뷰가 지연되는 경우가 종종 있다. 바쁜 일정 속에서 PR을 까먹기도 하고, 언제까지 리뷰해야 하는지 기준이 없으면 자연스럽게 흐지부지되기도 한다. 이러한 문제를 팀에서 인지하고, 코드 리뷰에 2일이라는 제한 시간을 두기로 했다. 하지만, 결국 이것도 머리로 기억해야 하는 문제였다. 그래서 PR에 마감일을 시각적으로 표시해주면 어떨까 생각했다. D-2, D-1, D-Day 같은 라벨이 PR에 붙어있으면 리뷰어 입장에서도 기억하지 않아도 쉽게 확인할 수 있고, 남은 기간에 대해서 긴박함을 느낄 수 있을 것이다. 도입하기 전에 먼저 이미 있는 액션 라이브러리들을 찾아보았다. 유력했던 후보가 네이버에서 만든 d-day-labeler였는데, 이건 마감일을 따로 지정할 .. 더보기

이전 1 2 3 4 ··· 12 다음

티스토리툴바