Topic 1. 당신의 인생이다. 개발자들의 다양한 여러 불만 → 현재 업무, 기술의 변화, 성과, 연봉, 팀 분위기 등 이에 대한 답은 한결 같다. “왜 직접 바꾸지 않는가?” 당신에게는 스스로의 행동을 직접 결정할 수 있는 힘이 있다. 필요한 사항이 있으면 요구해보기 안된다 했을 때 정말 원하는 거면 다른 곳 찾아보기 여가시간 쪼개서 재미있어 보이는 것 공부하기 이 업계는 여러분에게 놀랄 만큼 다양한 기회를 준다. 주도적으로 행동해서 그 기회를 잡아라. Topic 2. 고양이가 내 소스 코드를 삼켰어요. 실용주의 철학 중 하나 “자신과 자신의 행동에 대해 책임을 지는 것” 기술적 문제? → 정직하고 솔직해져야 한다. 실수나 무지 같은 단점도 인정해야 한다. 팀 내 신뢰 팀이 여러분을 믿고 의지할 수 ..
알림 시스템은 단순히 모바일 푸시 알림에 한정되지 않음. 책에서는 모바일 푸시 알림, SMS 메시지, 이메일 3가지로 분류함. 1단계, 문제 이해 및 설계 범위 확정 질문을 통한 설계 범위 확정 Q) 어떤 종류의 알림 ? 푸시 알림, SMS 메시지, 이메일 iOS, Android, Laptop/Desktop 지원해야 함 Q) 실시간 시스템인지? 연성 실시간 시스템 (Soft real-time) 가능한 빨리 전달되어야 하지만, 요청이 몰린 경우 약간의 딜레이 허용 Q) 사용자가 알림을 받지 않는 옵션이 존재하는지? 사용자가 알림을 허용하지 않으면 알림을 받지 않음 Q) 하루에 몇 건의 알림? 천만 건의 모바일 푸시 백만 건의 SMS 메시지 5백만 건의 이메일 2단계, 개략적 설계안 제시 및 동의 구하기 알..
분산 시스템에서 사용될 유일 ID 생성기 관계형 데이터베이스의 auto_increment 속성을 사용하면 안되나? 분산 시스템 → 데이터베이서 서버 한 대로 버틸 수 있을 것인가? 여러 데이터베이스 시스템 → 지연시간/여러 조건 불충족 등의 문제가 발생할 수 있다. 1단계, 문제 이해 및 설계 범위 확정 요구사항 ID는 유일해야 한다. ID는 숫자로만 구성되어야 한다. ID는 64비트로 표현될 수 있는 값이어야 한다. ID는 발급날짜에 따라 정렬 가능해야 한다. 초당 10,000개의 ID를 만들 수 있어야 한다. 2단계, 개략적 설계안 제시 및 동의 구하기 여러 선택지 고려 다중 마스터 복제 앞서 말했듯 데이터베이스의 auto_increment 기능을 활용하는 것 1만큼 증가시켜 얻는 것이 아닌 데이터베..
정의 처리율 제한 장치 (Rate Limiter) 클라이언트 또는 서비스가 보내는 트리팩의 처리율을 제어하기 위한 장치 정의된 임계치(Threshold)를 넘어서면 추가로 도달한 모든 호출은 처리가 중단 Ex) 사용자는 초당 2회 이상의 새 글을 올릴 수 없다. 같은 IP 주소로는 하루에 10개 이상의 계정을 생성할 수 없다. 처리율 제한 장치는 왜 사용하는가? DoS(Denial of Service) 공격에 의한 자원 고갈(Resource Starvation)을 방지할 수 있다. 비용을 절감할 수 있다. 처리를 제한해 서버를 많이 두지 않고, 우선순위가 높은 API에 더 많은 자원을 할당할 수 있다. 특히 요청 당 비용이 드는 Third party API를 사용하고 있는 경우, 횟수 제한을 통해 과도한..
시스템 설계 면접 기술적 측면 이상으로 지원자가 협렵에 적합한 사람인지, 압박이 심한 상황도 잘 헤쳐나가는지, 좋은 질문을 던질 능력이 있는지 부정적인 것 설계의 순수성에 집착한 나머지 타협적 결정을 도외시하고 오버 엔지니어링을 하는 엔지니어링들이 협업에도 많다. 오버 엔지니어링의 결과로 시스템 전반의 비용이 올라간다. 상당수 회사들은 값비싼 대가를 치르고 있다. 효과적 면접을 위한 4단계 접근법 1단계: 문제 이해 및 설계 범위 확정 바로 답부터 들이밀지 말자. 속도를 늦추자. 깊이 생각하고 질문하여 요구사항과 가정들을 분명히 하자. 가장 중요한 기술 중 하나는 올바른 질문을 하는 것. 적절한 가정을 하는 것. 그리고 시스템 구축에 필요한 정보를 모으는 것. 이 단계에서는 요구사항을 이해하고 모호함을 ..
책 [가상 면접 사례로 배우는 대규모 시스템 설계 기초]에 대해 요약한 글입니다. 단일서버 웹 - 앱 - 데이터베이스 - 캐시 등이 한 서버에서 동작 데이터베이스 웹/모바일 트래픽 처리용도의 서버(웹 계층)와 데이터베이스용 서버(데이터 계층)를 분리 독립적 확장 추구 비-관계형(NoSQL) 데이터베이스가 좋은 선택일 수 있는 경우 아주 낮은 응답 지연시간 필요 다루는 데이터가 비정형 데이터인 경우 데이터를 직렬화/역직렬화 할 수만 있으면 되는 경우 아주 많은 양의 데이터를 저장할 필요가 있는 경우 수직적 규모 확장 / 수평적 규모 확장 스케일 업 / 스케일 아웃 수직적 규모 확장(스케일 업)은 장애에 대한 자동복구 방안이나 다중화 방안을 제시하지 않음. 즉, 장애 발생 시 서비스 중단. 로드 밸런서 부하..
- Total
- Today
- Yesterday
- boj
- gradle
- 백준
- k8s
- 비동기
- java
- r2dbc
- Spring
- tag
- Kubernetes
- 로그
- Intellij
- c++
- 이스티오
- 일상
- docker
- jasync
- 알고리즘
- HTTP
- sidecar
- 하루
- container
- python
- MySQL
- Algorithm
- WebFlux
- Spring boot
- Istio
- Log
- 쿠버네티스
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | |
7 | 8 | 9 | 10 | 11 | 12 | 13 |
14 | 15 | 16 | 17 | 18 | 19 | 20 |
21 | 22 | 23 | 24 | 25 | 26 | 27 |
28 | 29 | 30 |