kakasoo

회사 내에 배포되어 있는 라이브러리를 보고 npm Pro 결제 없이도 private하게 라이브러리를 배포할 수 있는 걸 알았다. 배포할 패키지가 있는 레포지토리에서 package.json에 pubhlishConfig를 추가 하고, .npmrc 파일을 만들어서 아래와 같이 내용을 추가한다. // 배포하려는 라이브러리 쪽 package.json { "name": "@username/repositoryName", "publishConfig": { "registry": "https://npm.pkg.github.com" }, ... } # 배포하려는 라이브러리 쪽 .npmrc @username:registry=https://npm.pkg.github.com/ 이후에 패키지를 다운 받는 쪽에서도 .npmrc 파일..

외부 API ( 나의 경우 페이스북, 구글 등 ) 를 이용하는 경우, DB가 분산되어 있는 경우 ACID를 어떻게 보장할까? 첫 번째로 살펴본 것은 2PC ( Two-Phase Commit ) 인데, 예제 코드는 아래와 같다. 이 코드는 각각의 작업 단위를 Node로 정의하여 원자성을 보장해야 하는 것들을 Coordinator에게 전달한다. 2PC 프로토콜은 트랜잭션을 커밋할지 롤백할지 결정하기 위해 모든 Node의 투표 결과를 확인한다. interface Node { name: string; vote: boolean | null; prepare(): void; // commit할지, rollback할지 투표를 한다. commit(): void; rollback(): void; } class Coordi..

마이크로서비스 패턴이라는 책을 읽고, NestJS 코드로 다시 이해한다. NestJS에서 가장 많이 볼 수 있는 구조는 Controller - Service - Repository 로 이어지는 계층화된 아키텍처 (layered artchitecture)다. 이는 표현 계층, 비즈니스 로직 계층, 영속화 (persistence) 계층이라고 하는데, Controller는 사용자 인터페이스 또는 외부 API가 구현된 계층, Service는 비즈니스 로직이 구현된 계층, 영속화 계층은 DB 상호작용 로직이 구현된 계층이라는 뜻이다. 여기에는 한 가지 문제가 있다. 과연 어플리케이션에 동작을 의뢰하는 계층이 Controller 밖에 없는가? NestJS를 해봤다면 이미 정답을 할 텐데, 배치 시스템이나 소켓 통신..

콘웨이의 법칙에 대해서 읽었을 때 이게 무얼 의미하는 지 몰랐다. 콘웨이의 법칙 지인에게 MSA에 대해 설명하다가 이걸 왜 해야 하냐는 이야기를 들었다. API의 요청 수가 많아져서 서버가 죽는 속도가 서버의 증설 속도보다 빨라지는 시점에 서버는 차례대로 다운되고 결국 모든 서버가 닫히면서 서비스가 중단된다는 설명을 해줬다. 기술적으로는 그랬다. 그런데 불현듯 조직에 대한 생각이 들었다. 기술적인 부분 말고도, 조직 관리 측면에서도 MSA는 필연적인 것은 아닐까? 나는 지금 내 생황이 떠올랐다. 나는 새로운 회사로 이직한지 이제 일주일이 되었는데, 이 회사는 현재 100명이 넘는 사람이 있어서 사람들 얼굴과 이름을 외우는 것도 한 세월이다. 아마 1년 후에도 다 못외우고 있을지도 모른다. 그런데 만약 모..

모놀리식 지옥의 실상 모놀리식 아키텍처의 근본적인 한계는 성공한 어플리케이션 부터 생긴다. 더 큰 서비스, 더 많은 기능, 더 많은 개발자들은 애자일식 개발/배포도 불가능한 상황이 온다. 서비스는 너무 복잡해져서 어떤 개발자도 전체를 ‘완전히’ 이해하는 게 불가능해진다. 단일 코드베이스는 소통/조정에 오버헤드를 유발하고, 코드를 커밋한 후 반영되기까지 매우 긴 지연이 발생한다. 당연히 이런 큰 코드들은 IDE의 실행 속도도 늦추고 개발 속도를 계속 떨어드린다. 확장은 어렵고, 신뢰성이 떨어지며 ( 에러 발생 시 전체 서비스가 다운된다 ) 새로운 기술을 적용하기도 어렵다. 마이크로서비스 아키텍처 모놀리식의 단점을 느끼고 있다면 서비스가 성공적이었다는 것을 의미해도 될 거 같다. 만약 서비스가 비대해져서 더..

- 모든 것을 테스트한다는 오해 카카수 : 테스트 코드를 도입하려고 해요. 개발자1 : 좋아요. 하죠. 근데, 그걸 한다고 모든 문제가 사라질 건 아니에요. - 작업 방식에 대한 오해 카카수 : 테스트 코드를 도입하려고 해요. 개발자2 : 좋습니다. 근데 GET 요청은 테스트할 필요 없는 거죠? - 시간 낭비에 대한 오해 카카수 : 테스트 코드를 도입하려고 해요. 기획자 : 우리 안그래도 비즈니스가 급한데, 정말 괜찮을까요? 어느 정도 버그는 그냥 넘어가도 되는데? 테스트 주도 개발 이라는 말을 처음 지은 사람은 욕을 먹어야 한다는 얘기를 들었을 때, 그 이유를 이해 못했다. 하지만 이걸 팀원들에게 설명하고 도입하려고 하니 “굳이 왜 테스트를 해야 하느냐”는 질문들이 돌아왔다. 테스트를 해야 하는 이유는..

대학교 기술 세미나에서 발표할 일이 있을 때, 선후배 동문들을 상대로 발표한 적이 있는데, 그 때 코드를 최근 공유할 일이 생겼다. 그래서 블로그에도 올려서, 누구나 볼 수 있게 한다. ( Repository에도 올렸다. ) 지금 가르치는 학생분들을 포함해, Node.js에서 기본적인 서버 구현이 가능한 사람이라면 충분히 배워볼 만 하다. STEP 0. Express 코드 const express = require("express"); const http = require("http"); const path = require("path"); const app = express(); app.use(express.static("public")); const server = http.createServer(a..

지금 내가 개발하고 있는 서비스는, B2B 특성 상 유저에게 주어질 수 있는 권한이 다양하다. 게임처럼 ( 나는 안해서 정확히 모르지만 ) 브론즈부터 플래티넘까지의 계급이 있다고 이해하기 보다, 세부적인 권한을 설정해야 한다. 가령 우리 고객들은, 자기의 후임에게 아래처럼 권한을 줄 수 있다. "배송지를 새로 추가할 수는 있지만, 기존의 배송지를 수정할 수는 없게 하고 싶고, 직접 결제할 수는 없지만 주문 내역을 볼 수는 있다." 우리 서비스 내에서 유저에게 설정해줄 수 있는 권한은 카테고리만 해도 10가지 가량 되고, 세부 항목은 수십 가지가 넘는다. 심지어 이 항목들은, 아직도 기획이 추가되는 단계이고, 점차 확보할 고객 구성에 따라서 더 다양해질 수도 있다. 우리 서비스를 고객들이 어떻게 활용하느냐..

수직확장과 수평확장 사람들은 확장성과 관련해 용량 확장(수직 확장), 규모 확장(수평 확장) 을 말한다. 수직 확장은 좀 더 강력한 장비로 이동하는 것이고, 수평 확장은 여러 기기들로 부하를 분산하는 것을 말한다. 서로 다른 기기로 부하를 나누기 때문에 수평 확장은 다시 비공유 아키텍처라고 부르기도 한다. 단일 장비에서 수행하는 시스템이 비교적 간단하기는 하지만, 고사양 장비는 매우 비싸 대개 규모 확장을 택한다. 적절한 장비 몇 대가 다량의 낮은 사양 가상 장비, 또는 몇 대의 높은 사양 가상 장비보다 저렴하고 효율적이다. 탄력적 (Elastic) 일부 시스템은 탄력적(elastic)이다. 즉, 부하 증가를 감지하면 컴퓨팅 자원을 자동으로 추가할 수 있다. 탄력적인 시스템은 부하를 예측할 수 없을 경우..

커머스마다 돈 계산하는 방법은 다 다르다. 다만, 모든 사이트에서 공통적으로 사용될 수 있도록 다이어그램을 하나 만들어봤다. 결제 금액 계산하는 법 장바구니 가격 계산 상품 가격 계산 ( 옵션과 선택 옵션의 가격과 수량 곱의 합 ) 옵션 가격 계산 상품의 가격과 옵션 수량의 곱 선택 옵션 가격 계산 상품 가격과 선택 옵션 수량의 곱 배송비 책정 각 상품 당 배송비 책정 상품 정보나 배송지 정보가 누락된 경우 배송비 0원 ( 비정상적인 경우 ) 도서산간지역인 경우 도서산간지역 배송비를 책정 도서지역 배송비보다 상품의 배송비가 큰 경우, 큰 쪽을 우선 ex. 배송비가 40,000원인 경우 도서지역 배송비인 5,000원보다 크게 된다. 배송비가 무료인 경우 0원. 배송비가 유료인 경우, 상품의 배송비로 고정...

이 글은 Node.js를 더 잘 다루기 위해 비동기 제어를 설명합니다. 일부러 돌아가는 길을 선택함으로써 일반적으로 사용하지 않았을 법한 것을 설명합니다. 구글 페이지 가져오기 import axios from "axios"; async function getWebContent(url: string) { const { data } = await axios.get(url); return data; } (async () => { await getWebContent("https://google.com"); })(); 즉시 실행 함수 형태로 구글의 메인 페이지 문서를 읽는 코드를 작성했습니다. 간단합니다. 다음으로는, 이를 10번 반복하는 함수를 만들 것입니다. 비동기적으로 구글 페이지 10번 가져오기 impor..

성능 기술하기 부하 매개 변수를 증가시키고 시스템 자원은 그대로면 성능은 어떻게 될까? 부하 매개변수를 증가시켰을 때 성능을 그대로 하려면 자원은 얼마나 늘려야 할까? 두 질문 모두 성능수치가 필요하다. 하둡 (Hadoop) 같은 일괄 처리 시스템은 보통 처리량 ( throughput ) ( 초당 처리 가능한 레코드 수나 일정 크기의 데이터 집합으로 작업을 수행할 때 걸리는 전체 시간 )에 관심을 가진다. 온라인 시스템에서 더 중요한 사항은 서비스 응답 시간 ( response time ), 즉 클라이언트가 요청을 보내고 응답을 돌려받기 까지의 시간이다. 클라이언트가 몇 번이고 반복해서 동일한 요청을 하더라도 매번 응답 시간은 다르다. 이 때, 대부분의 요청은 꽤 빨라도, 특히 오래 걸리는 특이 값 ( ..