잼있는 블로그

Architecture ORDBMS, multi-process(연결마다 프로세스 생성) RDBMS, single-process(연결마다 쓰레드 생성) Data types supported Numeric, date/time, character, boolean, enumerated, geometric, network address, JSON, XML, HSTORE, arrays, ranges, composite Details Numeric, date/time, character, spatial, JSON Details Indexes supported B-tree, hash, GiST, SP-GiST, GIN, and BRIN 기본적으로 B-tree;특정 데이터 타입에 R-tree, hash, inverted..

◼CheckList 1. 애플리케이션이 성숙했을 때 얼마나 많은 데이터를 저장할 것으로 예상되는가? 어느 정도의 데이터를 저장 할 것인가? 기가바이트 단위 이하 -> 모든 데이터베이스 가능 페타바이트 이상 -> '라이브' 데이터는 쿼리 속도를 위해 in-memory나 SSD 고려, 전체 데이터는 HDD로 보관 등의 구조 필요 2. 첨두 부하(peak load)에서 동시에 몇 명의 사용자를 처리할 것으로 예상되는가? 동시 사용자는 몇 명인가? 동시 사용자 부하 추정 필요 많은 데이터베이스가 확장 문제가 있다 예상치 못하거나 계절적인 부하를 위해 여러 서버로 확장 할 수 있는 옵션 필요 수동으로 샤딩 없이 수평적으로 확장이 가능한 데이터베이스는 적다 3. 애플리케이션에 필요한 가용성(availbility),..

어플리케이션의 복잡도를 다루기 위해 적절한 응집도와 결합도를 찾아야 한다. SOLID는 높은 응집도와 낮은 결합도를 위한 OOD의 설계 원칙이다. SOLID SOLID는 지향해야 될 목표로 이상향에 가까움 현실적인 문제로 Trade off는 항상 있다. SRP(Single Responsibility Principle)::단일 책임 원칙 하나의 객체는 하나의 책임을 가져야 한다. ex) 예금 잔고 객체 단일책임은 정해진 게 아니라 어디까지 하나의 책임으로 볼 건지 고민 필요 입금, 출금이 있을 때 입출금 하나의 책임인지 따로따로가 단일 책임인지에 대한 고민 하나의 객체가 있는데 두개의 책임이 있다면 분리 package main ​ type FinanceReport struct { ​ } ​ func (r ..

우선 모든 판단에 Why로 시작하자 최근에 면접을 본 후 부족한 부분을 알게 되었고 10배 이상 뛰어난 개발자가 되는 법이라는 글을 보면서 깨달음을 얻어 적는 글입니다. 생각이 바뀌거나 추가 내용이 필요할 때마다 업데이트 예정입니다. Why 습관화 모든 선택엔 이유가 있어야 한다! 생각한다고 생각 했지만 생각보다도 무심코 편리하기 때문에, 당장에 문제가 되지 않았기 때문에 판단이 간소화됐거나 지나쳤던 부분들이 많았습니다. 예를 들어 python으로 개발한 이유나, A가 아닌 B방법으로 개발한 이유 등이 됩니다. 기준은 비지니스 필요 없는 작업은 비용 손해 why에 대한 답을 위해선 기준이 필요하다. 그리고 why의 시작이 연구분야가 아니고서는 비즈니스를 하기 위함이 대부분일 것이다. 따라서 불필요한 개발..

FastVentures의 Textbook 영상 콘텐츠 수강 내용을 정리합니다. ◼ 중요성 연간 밴처 캐피털이 받는 사업 계획서 수부터 성공하는 기업 수 = 500 → 30 → 10 → 5 → 사업 게획서를 받아서 미팅까지 가는데 94%가 drop이 되기 때문에 중요하다 한자마루 사업 계획서는 가장 best 사업은 잘 안됨 티몬 사업 계획서는 가장 worst 사업은 달됨 → 사업계획서와 사업의 성패 연관 관계는 낮다 ◼ 목적 잠재적 투자자와 커뮤니케이션 투자자가 원하는 이야기를 들랴줘야 함 투자자가 누구인가 (엔젤 투자자 vs 벤처캐피털) 엔젤투자자: 팀과 제품에 초점. 투자금액이 낮고 얼리 스테 이지기 때문에 벤처캐피털: 성과와 수익모델에 초점. 투자금액이 높고 조금 나중의 스테이지에 만난다. 팀과 제품..

◼ OS Upgrade 유지보수(security patch 등)의 이유로 cluster에서 node를 안정적으로 내리려면 어떻게 해야 하는가? 5분 안에 node를 살린다면 pod가 실행되지만 5분이 지나면 pod가 제거(terminated)된다. kube-controller-manager --pod-eviction-timeout (Default: 5m) replicaSet으로 관리되고 있던 pod라면 다른 node에 배지가 되지만 그렇지 않으면 사라진다. 안전한 방법은 아래와 같다. kubectl drain node01 node01안에 있는 pod들이 축출 되면서 다른 node로 스케줄링된다. node01에 cordon이 되면서 스케줄링이 안되게 된다. kubectl uncordon node01 nod..

◼ Rolling Updates and Rollbacks application update 하는 deployment strategies로 두 가지 방법이 있다. Recreate 기존에 배포된 모든 application을 삭제하고 updated된 application을 한 번에 배포하는 전략 삭제되고 생성되는 과정에서 application이 작동이 안되는 downtime이 존재한다. Rolling update Rolling Update rolling update: application이 downtime 없이 점진적으로 updated 되는 것 rollout: application을 update하는 것 따로 설정하지 않으면 rolling update가 default이다. deployment가 rollout을 ..

◼ Mornotiring node 갯수, 몇개가 healthy 한지, resource metrics(cpu, memory) 등등 확인 필요 k8s에는 builtin solution이 없고 훌륭한 open source 들이 있다. Metrics Server 대표적으로 metric Server는 node와 pod 정보를 수집하여 in memory에 저장한다. 따라서 disk에 저장 되지 않아 history를 보려면 다른 solution을 사용해야 한다. 클러스터에 하나 존재 각각의 node에 위치한 agent인 kubelet이 metric 서버에 전달 한다. kubelet 안에 있는 sub component인 cAdvisor가 pod와 node등의 metric 정보를 읽어온다 top 명령어로 resource..