본문 바로가기

server/아키텍쳐

(8)
airflow scheduler high cpu usage CPU 99.7% 사용중 ........ 전혀 dag이 실행중이지 않는데도 CPU를 사용입니다. 너무 잦은 DAG 파일 검색으로 인한 CPU부하와 함께 기존 하위 버전 v1.10.*부터 아래와 같은 버그가 있었습니다. 스케줄러 버그 - 스케쥴러가 중단없이 계속 반복됨 웹서버의 높은 CPU 부하 또한 airflow의 디폴트 값 설정값은 속도를 중시하에 셋팅 되어 있습니다. 자신만의 CPU 상황과 dag+task의 수에 맞게 [scheduler] / [webserver] / [core]의 환경변수를 조절 해야 합니다. 아래는 이번에 수정한 환경변수 목록 입니다. 이중에서 dag_dir_list_interval / min_file_process_interval 를 높게 설정한것만으로도 CPU 부하를 줄일 수 ..
캐시 컴퓨터에서 캐시는 일시적인 데이터 집합으로 데이터 요청 시 해당 데이터의 스토리지에 액세스 하여 가능한 한 빨리 처리 위해 사용된다. 캐시를 사용하면 이전의 검색이나 데이터를 효율적으로 재사용할 수 있다 캐시는 운영 체제, CDN (Content Delivery Networks) 및 DNS를 포함한 네트워킹 계층, 웹 애플리케이션 및 데이터베이스를 포함한 다양한 기술 계층 전반에 걸쳐 적용 및 활용할 수 있다. 캐싱을 사용하여 웹서비스, 게임, 미디어 공유 및 소셜 네트워킹과 같은 읽기가 많은 애플리케이션 워크로드에 대해 지연 시간을 크게 줄이고 IOPS를 개선 할 수 있다. 애플리케이션 서버 캐시 서버 요청 계층에 직접 캐시를 배치하면 응답 데이터의 로컬 저장이 가능하다. 서비스에 대한 요청이 있을 때..
Consistent Hashing (일관된 해싱) 일관된 해싱은 여러 스토리지 서버 간에 데이터를 분할하여 스토리지 시스템의 확장성을 구현하기 위해 수행된다. 많은 서버 (데이터베이스 서버+ 파티션)에 많은 데이터가 분산되어 있고 사용 가능한 서버 수가 지속적으로 변경되는 경우 (서버 추가 또는 서버 제거) 일관된 해싱을 사용한다. 단순 해싱을 쓸 수 없는 이유 간단한 해싱은 데이터와 지정된 키를 모듈러 함수를 통해 지정된 범위의 숫자로 생성한다. 모듈러 함수로 md5 사용한다면 0~2^128−1 범위에서 임의의 값을 얻을 수 있다. 이제 우리의 해시 함수는 server_number = hash(key)%n 로 계산된다. 이것은 [0- (n-1)] 범위로 제공하며 n은 서버의 수가 된다. 이렇게 하면 서버수에 따라 데이터가 완벽하게 나뉜다. value를..
airflow 시간대가 다른 두개의 dag을 ExternalTaskSensor 사용하기 airflow ExternalTaskSensor의 설명은 아래 블로그가 잘되어 있으니 참고!! tommybebe.github.io/2020/11/30/airflow-external-task-sensor/ Airflow ExternalTaskSensor 사용 방법 Airlflow Task의 upstream, downstream 설정을 통해 Task 실행 순서를 설정할 수 있는 것과 유사하게 DAG과 DAG 사이에서도 실행 순서를 설정할 필요가 있는 경우가 있다. 이 경우를 위해 Cross-DAG Dependencies가 tommybebe.github.io 나의 경우 ExternalTaskSensor를 이용해서 2개의 dag이 끝나는 시점을 감지한 후 새로운 dag을 실행해야 하는 상황이었다. * 감지해야 ..
코딩을 하기전 해야할 일들 1. 요구사항의 명확화 - 정확히 무엇을 할것인지를 정의할것 2. 파라미터 정의 - int / array / date / timestamp 인지 파라미터를 명확히 한다. 3. 기능의 순서 설계 - 요구사항을 진행하기 위해서 어떤 순서로 코드를 작성할 것인가? UML / 다이어그램 / 순서도 등을 통해 순처리/예외처리를 확인 을 통해 간결해 진다. 4. 코드 작성 및 리팩토링 (코드를 짜면서 기능을 추가 할수도 있으며, 기능 단위로 다시 묶음으로써 리팩토링이 가능해 진다. ) 5. 추가 사항이 있는가 확인. 있다면 다시 1번으로 - 버그나 에러는 1, 2번에서 빠진게 있는것. 만일 이게 아니라면 기능상의 오류 (기능정의부터 잘못됨) - 코드부터 작성하지 말자. 기능과 파라미터를 명확히 하면 더 시간을 아낄..
web developer roadmap 출처 : https://github.com/kamranahmedse/developer-roadmap 눈에 띄는 것은 1. 테스트 작성 및 TDD가 최상단에 있다는것. (6번) 2. Docker / GraphQL을 배워야 한다는것 (19 / 21 번) 자신이 스타트업같이 개발자가 10명 이내의 회사라면 프론트엔드 + 백엔드 + 데브옵스 까지 기본적인 것은 다 해야 한다. (위의 것은 한번쯤은 건들어봐야 한다... 그게 스타트업이다....아무것도 없으니 만들어야됨.. 누가? 네가!)규모가 있는 회사라면 백엔드와 데브옵스 팀이 구분되어 있다. (데브옵스가 인프라팀으로 세분화 된다)게임에서만 케릭터 스킬 뭐 찍을까 몇일씩 고민하지 말고 자신의 테크트리도 잘 보고 찍자.- 단 천재는 알아서 다 잘한다. 저걸 전부..
DSR ( direct server return ) http://novatechservices.com/use-dsr-to-take-a-load-off-your-load-balancer/ 보통의 서버 앞 단에 있는 로드밸런스(L4)에서 사용할수 있는 기능으로 기본적인 통신에서의 클라이언트와 서버의 응답은 client -> load balancer -> server -> load balancer ->client 의 형식으로 로드밸런서가 응답에 대해서도 작동을 하게 된다. ( Inline(proxy) mode 라 한다. )만일 요청이 많아지면 로드밸런서의 처리 때문에 서버가 놀게 되는 현상이 일어날수 있다.이를 막기 위해 응답은 로드밸런서를 거치지 않고 서버가 바로 클라이언트에 응답을 준다. (상단의 그림 참조 )client -> load balancer ->..
서버 구조 생각하기 Massive service basic from DaeMyung Kang Internet Scale Service Arichitecture from DaeMyung Kang webservice scaling for newbie from DaeMyung Kang