개발하는 기계공학도

auto_increment 속성? → No! 분산 환경에서 이 접근법은 통하지 않는다. 여러 데이터베이스 서버를 쓰는 경우에는 delay를 낮추기 어렵다. 1단계. 문제 이해 및 설계 범위 확정 ID는 유일해야 한다. ID는 숫자로만 구성되어야 한다. ID는 64비트로 표현될 수 있는 값이어야 한다. ID는 발급 날짜에 따라 정렬 가능해야 한다. 초당 10,000개의 ID를 만들 수 있어야 한다. 2단계. 개략적 설계안 제시 및 동의 구하기 선택지 4개 multi-master replication UUID(Universally Unique Identifier) ticket server twitter snowflake 접근법 다중 마스터 복제 데이터베이스의 auto_increment 기능을 활용한다. 다만..

키-값 쌍에서의 키는 유일해야 하며 해당 키에 매달린 값은 키를 통해서만 접근할 수 있다. put(key, value) get(key) 문제 이해 및 설계 범위 확정 완벽한 설계란 없다. 읽기, 쓰기 그리고 메모리 사용량 사이에 어떤 균형ㅇㄹ 찾고, 데이터의 일광성과 가용성 사이에서 타협적 결정을 내린 설계를 만들어야 한다. 단일 서버 키-값 저장소 한대는 쉽다. 가장 직관적인 방법은 키-값 쌍 전부를 메모리에 해시 테이블로 저장하는 것이다. → 빠른 속도를 보장하긴 하지만 모든 데이터를 메모리 안에 두는 것이 불가능할 수도 있다는 약점이 있음 개선책 2가지 데이터 압축 자주 쓰이는 데이터만 메모리에 두고 나머지는 디스크에 저장 그래도 부족한 때가 곧 찾아온다. 분산 키-값 저장소 분산 키-값 저장소는 ..

수평적 규모 확장성을 달성하기 위해 요청을 서버에 균등하게 나누는 것이 중요한데 안정 해시는 보편적으로 사용하는 기술이다. 해시 키 재배치(rehash) 문제 안정 해시 해시 테이블 크기가 조정될 때 평균적으로 오직 k/n개의 키만 재배치하는 해시 기술이다. k : 키의 개수, n : 슬롯의 개수 해시 공간과 해시 링 해시 서버 해시 키 서버 조회 서버 추가 서버 제거 기본 구현법의 두 가지 문제 기본 절차는 다음과 같다. 서버와 키를 균등 분포 해시 함수를 사용해 해시 링에 배치한다. 키의 위치에서 링을 시계 방향으로 탐색하다 만나는 최초의 서버가 키가 저장될 서버다. 2가지 문제 서버가 추가되거나 삭제되는 상황을 감안하면 파티션의 크기를 균등하게 유지하는 것이 불가능 (파티션 : 인접한 서버 사이의 ..

처리율 제한 장치 : 클라이언트 또는 서비스가 보내는 트래픽의 처리율(rate)을 제어하기 위한 장치 사례 사용자는 초당 2회 이상 새 글을 올릴 수 없다. 같은 IP 주소로는 하루에 10개 이상의 계정을 생성할 수 없다. 같은 디바이스로는 주당 5회 이상 리워드를 요청할 수 없다. 장점 Dos(Denial of Service) 공격에 의한 자원 고갈 방지 요청에 대한 비용 절감 서버 과부화 방지 1단계. 문제 이해 및 설계 범위 확정 2단계. 개략적 설계안 제시 및 동의 구하기 처리율 제한 알고리즘 토큰 버킷 (버킷 크기, 토큰 공급률) 장점 구현이 쉽다. 메모리 사용 측면에서 효율적이다. 짧은 시간에 집중되는 트래픽도 처리 가능 단점 버킷 크기와 토큰 공급률이라는 두 개 인자를 갖고 있는데 적절하게 ..

개략적 규모 추정을 효과적으로 해 내려면 규모 확장성을 표현하는 데 필요한 기본기에 능숙해야 한다. 특히 2의 제곱수나 응답지연 값, 그리고 가용성에 관계된 수치들을 기본적으로 잘 이해하고 있어야 한다. 2의 제곱수 2의 x제곱 근사치 축약형 10 1천 1KB 20 1백만 1MB 30 10억 1GB 40 1조 1TB 50 1000조 1PB 모든 프로그래머가 알아야 하는 응답지연 값 메모리는 빠르지만 디스크는 아직도 느리다. 디스크 탐색은 가능한 한 피하라. 단순한 압축 알고리즘은 빠르다. 데이터를 인터넷으로 전송하기 전에 가능하면 압축하라. 데이터 센터는 보통 여러 지역에 분산되어 있고, 센터들 간에 데이터를 주고받는 데는 시간이 걸린다. 가용성에 관계된 수치들 계산 팁 근사치를 활용하라 가정들은 적어 ..

단일 서버 웹 앱, DB, 캐시 등이 모두 서버 한 대에서 실행되는 구조 데이터베이스 사용자가 늘면 서버 하나로는 충분하지 않아서 여러 서버를 두어야 한다. 웹/모바일 트래픽 처리 용도(웹 계층) 데이터베이스 서버(데이터 계층) DB 선택 기준 대부분은 관계형 데이터베이스가 최선이지만 특정한 경우에는 비-관계형 데이터베이스를 사용한다. 아주 낮은 응답 지연시간(latency)이 요구될 때 다루는 데이터가 비정형이라 관계형 데이터가 아닐 때 데이터를 직렬화하거나 역직렬화 할 수 있기만 하면 될 때 아주 많은 양의 데이터를 저장할 필요가 있을 때 수직적 규모 확장 vs 수평적 규모 확장 스케일 업 : 고사양 자원을 추가하는 행위(수직적 규모 확장) 스케일 아웃 : 더 많은 서버를 추가해 성능을 개선하는 행위..

Filter vs Interceptor Filter J2EE 표준 스펙 기능으로 디스패처 서블릿에 요청이 전달되기 전/후에 url패턴에 맞는 모든 요청에 대해 부가작업을 처리할 수 있는 기능을 제공한다. 스프링 밖에 존재한다. 스프링 컨테이너가 아닌 톰캣과 같은 웹 컨테이너(서블릿 컨테이너)에 의해 관리된다. (스프링 빈으로 등록은 된다.) Interceptor J2EE 표준 스펙인 필터와는 달리 Spring이 제공하는 기술로써, 디스패처 서블릿이 컨트롤러를 호출하기 전과 후에 요청과 응답을 참조하거나 가공할 수 있는 기능을 제공한다. 스프링 안에 존재한다. 디스패처 서블릿은 핸들러 매핑을 통해 적절한 컨트롤러를 찾도록 요청하는데 , 그 결과로 실행 체인(HandlerExecutionChain)을 돌려준..

secret 변수는 -secret.yml 에서 관리하고 나머지는 .yml 에서 프로파일별로 나누어서 작성해주면 된다. 그러면 spring.profiles.active 와 include 차이가 뭘까? active는 활성화할 프로파일을 지정하는 데 사용됨. include는 @Configuration 클래스에서 프로파일을 조건부로 적용하기 위해 사용된다. include 예제 @Configuration @Profile("dev") public class DevConfiguration { // Dev 환경에서만 필요한 설정 } 일반적으로는 ‘spring.profiles.active’를 사용하여 프로파일을 지정하고 필요한 설정을 관리하는 것이 일반적이다. ‘include’는 주로 ‘.yml’로 분리된 설정을 관리하..

요약 : 그릇과 내용물을 동일시한다. 복수와 단수를 동일시한다. (여러 개를 모아서 마치 하나의 것처럼 취급하는 것) → 복합 객체를 구성하는 개별적인 객체들을 모두 동일한 방법으로 다룰 수 있게 하는 패턴 예시 : 파일 시스템의 ‘file’과 ‘directory’ file과 directory는 서로 다르지만, 둘 다 ‘directory 안에 넣을 수 있는 것’ 이라는 공통 속성을 이용한다. → file과 directory를 directory entry이라고 부르고 같은 종류로 동일시하는 것 (composite 패턴의 조건) 예제 프로그램 클래스 목록 이름 설명 Entry File과 Directory를 동일시하는 추상 클래스 File 파일 클래스 Directory 디렉터리 클래스 Main 동작 테스트용 ..

분명히 타겟그룹에 설정한 ec2가 정상적으로 돌아가는 것을 확인했는데 health check를 하면 자꾸 unhealty가 나왔다. healty check 요청은 30초마다 한번씩 체크하고 2번이 연속적으로 실패하면 unhealty를 띄워준다. 먼저 요청이 제대로 오는지 확인했다. 해당 EC2로 접근해 다음 명령어를 통해 80으로 들어오는 신호를 기다렸다. sudo tcpdump -i ens5 port 80 -vvv 30초 단위로 일정한 health-check 요청이 들어오는 것을 확인할 수 있다. 그렇다면 왜 unhealty인 것인가? 순간 든 생각이 지정된 80포트로 healty-check가 고정으로 들어오고 응답해준다면 80포트는 우리가 사용할 수 없는 것인가 생각했다. 실제로 alb의 health..