📚 개발 도서
-
RDB와 NoSQL📚 개발 도서/대규모 시스템 설계 기초 2023. 6. 8. 20:24
쉬운코드님의 유튜브 영상 보면서 정리한 내용입니다. Relation Database의 단점 유연한 확장성의 부족 새로운 column을 추가하고 싶으면 반드시 scheme를 변경해야 한다. scheme를 변경이 필요하여 컬럼을 추가한다면 해당 작업 자체가 굉장히 위험 부담이 될 수 있다. (왜냐하면 기존에 있는 대량 데이터에 대해서 새로운 column을 추가하기 때문에 대용량 write가 필요함) 복잡한 join은 read의 하락 중복 제거(for 데이터의 일관성)를 위해 정규화 진행한다. 이는 데이터 중복을 최소화한다. 하지만 전체 데이터를 읽어오고 싶을 때 join을 많이 해야하는 문제가 발생한다. → 그만큼 DB 서버에 CPU 많이 사용하고, 응답 시간이 늘어난다. 일반적으로 RDB는 scale-ou..
-
[클린코드] 함수📚 개발 도서/클린코드 2023. 5. 7. 11:08
3-2 함수가 읽기 쉽고 이해하기 쉬운 이유는 무엇일까? 의도를 분명히 표현하는 함수를 어떻게 구현할 수 있을까? 함수에 어떤 속성을 부여해야 처음 읽는 사람이 프로그램 내부를 직관적으로 파악할 수 있을까? 이 질문들과 함께 챕터를 읽어보자. 작게 만들어라! // 3-3 public static String renderPageWithSetupAndTeardowns ( PageData pageData, boolean isSuite) throws Exception { if (isTestPage(pageData)) includeSetupAndTeardownPages(pageData, isSuite); return pageData.getHtml(); } → 이 함수는 이야기처럼 술술 읽혀진다. 블록과 들여쓰기 ..
-
[클린코드] 의미 있는 이름📚 개발 도서/클린코드 2023. 4. 29. 11:33
다음 규칙들을 적용해서 코드 가독성이 높아져보자! 의도를 분명히 밝혀라 좋은 이름을 지으려면 시간이 걸리지만 좋은 이름으로 절약하는 시간이 훨씬 더 많다. 그릇된 정보를 피하라 일관성이 떨어지는 표기법은 그릇된 정보다. 의미있게 구분하라 컴파일러나 인터프리터만 통과하려는 생각으로 코드를 구현하는 프로그래머는 스스로 문제를 일으킨다. 다른 클래스를 ProductInfo 혹은 ProductData라 부른다면 개념을 구분하지 않은 채 이름만 달리한 경우다. Info나 Data는 a, an, the와 마찬가지로 의미가 불분명한 불용어다. 불용어는 중복이다. 읽는 사람이 차이를 알 수 있도록 이름을 지어라. 이름이 달라야 한다면 의미도 달라져야한다. 발음하기 쉬운 이름을 사용하라 발음하기 쉬운 단어를 사용할 때 ..
-
[클린코드] 깨끗한 코드📚 개발 도서/클린코드 2023. 4. 18. 20:17
코드가 존재하리라 코드는 요구사항을 표현하는 언어이다 언어는 요구사항에 가깝게 만들 수 있다. 요구사항에서 정형구조를 뽑아낼 수 있는 도구를 만들 수 있다. 나쁜 코드 회사가 망한 원인은 바로 나쁜 코드 탓이었다. 버그가 남아있고, 프로그램이 죽는 횟수가 늘고, 출시하기에 바빠 코드를 마음대로 짜고, 기능을 추가할수록 엉망이 되어갔다. 고행(wading) 나쁜 코드를 헤쳐나간다. 르블랑의 법칙 나중은 결코 오지 않는다. 나중에 손보겠다고 한 코드와 돌아간다는 사실에 안도감을 느끼며 위로함 → 나중은 결코 오지 않는다. 나쁜 코드로 치르는 대가 나쁜 코드가 쌓일수록 팀 생산성이 떨어진다. 태도 “우리에게”라는 단어가 자주 나온다 좋은 코드를 사수하는 일은 바로 우리 프로그래머들의 책임이다. 원초적 난제 나..
-
[데이터 중심 애플리케이션 설계] 응답 시간 (p50, p95, p99)📚 개발 도서/데이터 중심 애플리케이션 설계 2023. 4. 13. 01:21
“전형적인” 응답 시간을 알고 싶다면 평균은 좋은 지표가 아니다. 얼마나 많은 사용자가 실제로 지연을 경험했는지 알려주지 않기 때문이다. 일반적으로 백분위를 사용하는 편이 좋다. 응답 시간 목록을 가지고 가장 빠른 시간부터 제일 느린 시가가지 정렬하면 중간 지점이 중앙값(median)이 된다. 사용자가 보통 얼마나 오랫동안 기다려야 하는지 알고 싶다면 중앙값이 가장 좋은 지표다. 중앙값 == 50분위(p50)사용자 요청의 절반은 중앙값 응답 시간 미만으로 제공되고, 나머지 반은 중앙값보다 오래 걸린다.사용자가 여러 개의 요청을 보내면 최소한 하나의 요청이 중앙값보다 느릴 확률이 50%보다 높다. 특이 값이 얼마나 좋지 않은지 알아보려면 상위 백분위를 살펴보는 것도 좋다.95분위, 99분위, 99.9분위가..
-
[데이터 중심 애플리케이션 설계] BASE와 ACID📚 개발 도서/데이터 중심 애플리케이션 설계 2023. 4. 12. 00:04
BASEBasically Available, Soft State, Eventually Consistent데이터 가용성과 데이터 처리 성능이 향상되도록 한다!Basically Available(가용성) : Master 서버에 장애가 발생해도, 여러 Slave 서버로 인해 무중단 서비스가 가능하다. (가용성을 제공한다.)Soft State(소프트 상태) : 각각의 데이터가 도달한 시점에 데이터가 갱신된다. (유연한 상태를 가진다.)Eventually Consistent(결과적 일관성)→ 시스템 부하 및 네트워크 속도에 따라 서버에 복제하는 시간이 다를 수 있으나, 최종적으로는 모든 서버에 데이터가 복제된다.복제 메커니즘에 의해 모든 서버에 데이터 복제가 동시에 실행될 수 없다.ACIDAtomicity, Co..
-
Consistent Hashing (안정 해시)📚 개발 도서/대규모 시스템 설계 기초 2023. 2. 12. 01:02
해시 키 재배치(rehash) 문제 N개의 캐시 서버가 존재할 때 이 서버들에 부하를 균등하게 나누는 보편적인 방법 serverIndex = hash(key) % N (N: 서버의 개수) 이는 서버가 추가되거나 기존 서버가 삭제되면 문제가 된다. serverIndex = hash(key) % (N-1) (-1: 삭제된 서버) 장애가 발생한 서버에 보관되어 있는 키뿐만 아니라 대부분의 키가 재분배되게 된다. 대부분 캐시 클라이언트가 데이터가 없는 엉뚱한 서버에 접속하게 되는 것이다. 즉 노드 삭제 및 추가가 있는 경우 hash(key) % N 결과에 미치는 영향이 너무 커서 많은 수의 요청이 실패하여 캐시된 데이터가 다시 로드된다는 것이다. → 대규모 캐시 발생 안정 해시(consistent hash) 해..
-
[대규모 시스템 설계 기초 - 01] 사용자 수에 따른 규모 확장성📚 개발 도서/대규모 시스템 설계 기초 2023. 1. 13. 19:00
[01] 사용자 수에 따른 규모 확장성 한 명의 사용자를 지원하는 시스템에서, 몇백만 사용자를 지원하는 시스템에 이르기까지 설계 단일 서버 모든 컴포넌트(웹 앱, 데이터베이스, 캐시 등)가 단 한 대에 서버에서 실행되는 간단한 시스템 사용자 요청 과정 클라이언트는 DNS에 도메인 이름으로 IP를 질의한다. DNS는 우리 시스템의 일부는 아니다. 클라이언트는 DNS 조회 결과로 IP를 얻어온다. 이 IP 주소는 웹 서버의 주소이다. 이 IP 주소로 클라이언트는 HTTP 요청을 전달한다. 웹 서버는 클라이언트에게 HTML 웹 페이지를 전달한다. 데이터베이스 서버 분리 사용자가 늘어나면, 단일 서버로는 부족하여 웹계층(웹/모바일 트래픽 처리 서버)와 데이터 계층(데이터베이스 서버)로 분리할 수 있다. 이는 각..