blog.

Netlify로 프로젝트를 배포했다면, 이제 기본 제공되는 *.netlify.app 주소 대신 나만의 도메인을 연결하고 싶어질 수 있다. 이번 과정에서는 Cafe24에서 도메인을 구입하고, 이를 Netlify에 연결하는 방법을 단계별로 정리했다. 1. 도메인 구매 - cafe24 Cafe24에서 원하는 도메인을 검색해서 구입했다. 1년 사용료는 약 23,500원 정도였다.https://hosting.cafe24.com/?controller=new_domain_search_result 카페24 호스팅 | 온라인 비즈니스의 시작도메인 검색 결과 주요 도메인 국가 도메인 국내 도메인 기관 도메인 국내 지역 도메인 New gTLD 한글 도메인 도메인 신청하기 도메인 신청하기hosting.cafe24.com ..

1. add new project 클릭 2. import an existing project 클릭 3. 원하는 애플리케이션 클릭 : github 클릭그 외에도 gitlab, bitbucket, azure devops 가능하다. 4. github 에서 repository 선택 5, team, project name 설정한다. Base directory (베이스 디렉토리)Netlify가 package.json, .nvmrc 같은 의존성 관리 파일을 찾고, 의존성을 설치하며 빌드 명령을 실행하는 디렉토리입니다. 또한 빌드 과정에서 캐싱 기준이 됩니다. 별도 설정하지 않으면 저장소 루트가 기본값입니다.Site files (사이트 파일)저장소 내 사이트 소스 코드와 관련 설정 파일을 의미합니다. 흔..

3단계 : 상세 설계스트리밍 vs 일괄처리 서비스(온라인 시스템)일괄 처리 시스템(오프라인)스트리밍 시스템(실시간 가깝게 처리)응답성클라이언트에게 빠르게 응답클라이언트에게 응답할 필요 없음클라이언트에게 응답할 필요 없음입력사용자의 요청유한한 크기 갖는 입력, 크기의 데이터입력에 경계 없음 (무한한 스트림)출력클라이언트에 대한 응답구체화 뷰, 집계 결과 지표 등구체화 뷰, 집계 결과 지표 등성능 측정기준가용성, 지연 시간처리량처리량, 지연 시간사례온라인 쇼핑맵리듀스플링크본 설계안에서는 일괄 처리와 스트리밍 처리 경로를 하나로 합치는 카파 아키테쳐를 활용한다. 시간과 집계 윈도 (aggregation window)집계를 하려면 타임 스탬프가 필요하다. 타임 스탬프는 두 가지 다른 위치에서 만들어질 수 있다...

1단계 : 문제 이해 및 설계 범위 확정 기능 요구사항지난 M분 동안의 ad_id 클릭 수 집계매분 가장 많이 클릭된 상위 100개 광고 아이디를 반환다양한 속성에 따른 집계 필터링 지원 데이터의 양은 페이스북이나 구글 규모(자세한 시스템 규모 요구사항은 아래 개략적 추정치에 관한 절 참고) 비기능 요구사항집계 결과 정확성은 데이터가 RTB 및 광고 과금에 사용되므로 중요지연되거나 중복된 이벤트를 적절히 처리할 수 있어야 함견고성(realibility) : 부분적인 장애는 감내할 수 있어야 함지연 시간 요구사항 : 전체 처리 시간은 최대 수 분을 넘지 않아야 함 개략적 측정일간 능동 사용자(DAU) 수는 10억명각 사용자는 하루에 평균 1개 광고를 클릭한다고 가정. 따라서 하루에 10억건의 광고 클릭 ..

1장. 습관을 바꾸려면 습관을 이해하라모든 미루기가 같지는 않다. 미루기의 유형은 수동적 미루기와 능동적 미루기, 두 가지로 나눌 수 있다. 수동적 미루기란 가장 대표적인 형태의 미루기이다. 어떤 행위를 하려 했지만 이루고만 있는 것이다. 혹시 당신이 반복적으로 그리고 진심으로 "이것만 끝내면 바로 그 일을 시작해야지"라고 생각한다면 수동적 미루기를 하고 있을 가능성이 크다.능동적 미루기는 수동적 미루기보다는 더 의도적인 결정으로, 압박감을 느껴야 능률이 더 오른다라고 믿기 때문에 일부러 미루는 경우를 말한다.2장. 미루기의 악순환을 끊지 못하는 이유이 현상은 만족감을 나중으로 미루지 못하고, 당장 눈앞에 있는 것을 선호하는 성향에 일부 기인한다. 미루지 않는 사람이 더 어려운 과업에 먼저 착수하려 하는..

3단계 : 상세 설계지표 수집폴 vs 푸시 모델폴모델 이 접근법에서 지표 수집기는 데이터 가져올 서비스 목록을 알아야 한다. 서버가 수시로 추가/삭제되는 대규모 운영 환경에서는 적용하기 어렵다. etcd나 아파치 주키퍼 같은 서비스 탐색 기술 활용하면 이 문제는 해결할 수 있다. 각 서비스는 자신의 가용성 관련 정보를 서비스 탐색 서비스(이하 Service DisCovery System) 에 기록되고, SDS 서비스 엔드포인트 목록에 변화가 생길 때마다 지표 수집기에 통보한다. 수천 대 서버가 만들어 내는 지표 데이터를 수집하려면 지표 수집기 한대로는 부족하다. 지표 수집기 서버 폴을 만들어야 본 설계안에서 다루는 지표 데이터 규모를 감당할 수 있다. 지표 수집기 서버를 여러 대 둘 때 데이터를 중복해서..

1단계 : 문제 이해 및 설계 범위 확정 개략적 요구사항 및 가정 대규모 인프라를 모니터링 해야 함일간 능동 사용자 수 1억명 (100million)서버 폴 1,000개, 폴당 서버 수 100개, 서버당 100개의 운영 지표를 수집한다고 치면 모니터링 해야 하는 지표의 수는 천만 개 수준데이터 보관 기간은 1년 수집한 그대로 데이터를 보관하는 기간은 일주일 그 뒤에는 1분 단위 데이터로 변환한 후에 30일간 보관. 그 뒤에는 1시간 단위 데이터로 변환한 뒤에 1년간 보관 모니터링할 지표는 다양한데, 예를 들면 다음과 같다.CPU 사용률요청 수 메모리 사용량 메시지 큐 내의 메시지 수 비기능 요구사항규모 확장성 : 시스템은 늘어나는 지표 수와 경보의 양에 맞게 확장될 수 있어야 한다. 낮은 응답 지연 ..

3단계 : 상세 설계 데이터 저장소메시지 큐의 트래픽 패턴 읽기와 쓰기가 빈번하게 일어난다. 갱신/삭제 연산은 발생하지 않는다. 순차적인 읽기/쓰기가 대부분이다. 선택지1 : 데이터페이스 => 읽기와 쓰기가 동시에 대규모로 빈번하게 발생하는 상황 잘 처리하는 데이터베이스는 설계가 어렵다. 선택지2 : 쓰기 우선 로그 (Write-Ahead Log) 새로운 항목이 추가되기만 하는 일반 파일 지속성 보장해야 하는 메시지는 디스크에 WAL로 보관하는 것을 추천한다. 일괄 처리 생산자, 소비자, 메시지 큐는 메시지를 가급적 일괄 처리한다. 일괄 처리가 성능 개선에 중요한 이유는 다음과 같다. 운영체제로 하여금 여러 메시지를 한 번의 네트워크 요청으로 전송할 수 있도록 하기 때문에 값비싼 네트워크 왕복 비용을 ..

1단계 : 문제 이해 및 설계 범위 확정 기능 요구사항생산자는 메시지 큐에 메시지를 보낼 수 있어야 한다. 소비자는 메시지 큐를 통해 메시지를 수신할 수 있어야 한다. 메시지는 반복적으로 수신할 수도 있어야 하고, 단 한번 만 수신하도록 설정될 수 도 있어야 한다. 오래된 이력 데이터는 삭제될 수 있다.메시지 크기는 킬로바이트 수준이다. 메시지가 생산된 순서대로 소비자에게 전달할 수 있어야 한다. 메시지 전달 방식은 최소 한번, 최대 한 번, 정확히 한 번 가운데 설정할 수 있어야 한다. 비기능 요구사항 높은 대역폭과 낮은 전송 지연 가운데 하나를 설정으로 선택 가능하게 하는 기능규모 확장성. 이 시스템은 특성상 분산 시스템일 수 밖에 없다. 메시지 양이 급증해도 처리 가능해야 한다. 지속성 및 내구성..

3단계 : 상세 설계 데이터 모델[ 경로 안내 타일 ]도로 데이터는 수 테라바이트에 해당한다. 주어진 상태 그대로는 경로 안내 알고리즘의 입력으로 활용할 수 없으므로 경로 안내 타일 처리 서비스를 활용한다. 경로 안내 타일은 해상도에 따라 세 벌을 만든다. 어디에 저장해야 할까 ?그래프 데이터는 메로리에 인접 리스트 형태로 보관하는 것이 일반적이다. 하지만 본 설계안이 다루는 타일 데이터는 메로리에 두기에는 양이 너무 많다. 가장 효율적인 방법은 S3 같은 객체 저장소에 파일을 보관하고 그 파일을 이용한 경로 안내 서비스에서 캐싱하는 것이 바람직하다. 지오해시 기준으로 분류해두면 위도와 경도 주어졌을 때 신속하게 찾을 수 있다. [ 사용자 위치 데이터 ]사용자위 위치 데이터 저장하려면 엄청난 양의 쓰..