일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 | 31 |
- 메시지
- desktop
- Chat gpt
- 네이버웍스
- 자바 정규식
- 분산추적
- eclipse
- 도커
- 모니터링 및 경고 중앙화
- MSA
- 네이버클라우드플랫폼
- linux
- docker
- GitLab
- application 재기동
- ChatGPT
- AWS
- 정규표현식
- crontab
- 마이크로서비스 패턴
- GIT
- 알림
- chat API
- 가상머신 차이
- sh
- MAC
- 리눅스
- error
- 제어루프
- Catalina
- Today
- Total
목록마이크로서비스 패턴 (8)
시간나는대로 틈틈히 정리 합시다~~!!!
1. 문제점 - 응답 시간이나 하드웨어 자원 사용량이 지나치게 높은 경우 문제의 근본 원인을 찾는게 매우 어렵다. - 마이크로서비스별 하드웨어 자원 사용량을 분석할 수 있어야 한다. 2. 해결책 마이크로서비스 인스턴스가 사용하는 하드웨어 자원 사용량에 대한 메트릭(metric)을 수집하는 새 컴포넌트(모니터 서비스)를 시스템 환경에 추가한다. - 오토스케일링(auto-scaling)된 서버를 포함해 시스템 환경에서 사용하는 모든 서버의 메트릭을 수집해야 한다. - 서버에서 새로 시작된 마이크로서비스 인스턴스를 감지해 메트릭을 수집해야 한다. - 수집한 메트릭을 조회 및 분석하기 위한 API와 그래픽 도구를 제공해야 한다. 3. 구현된 오픈소스 도구 - 쿠버네티스 : 그라파나와 프로메테우스 (참고: 쿠버네..
1. 문제점 다수의 마이크로서비스 인스턴스가 여러 서버에 분산돼 있는 시스템 환경에선 중단되거나 지연된 마이크로서비스 인스턴스를 수동으로 감지하고 대처하는 것이 어렵다. 2. 해결책 - 시스템 환경의 상태를 관찰하는 새 컴포넌트(제어루프)를 시스템 환경에 추가한다. - 이 컴포넌트는 운영자가 지정한 상태와 실제 상태를 지속적으로 관찰하며, 두 상태가 다른 경우에는 현재 상태가 지정한 상태와 일치하도록 조치를 취한다. 3. 구현 참고 컨테이너를 기반으로 하는 환경에선 쿠버네티스와 같은 컨테이너 오케스트레이터로 구현한다. 4. 구현된 오픈소스 - 쿠버네티스 : 쿠버네티스의 컨트롤러 매니저(controller manager)
1. 문제점 - 동기 방식으로 상호 통신하는 마이크로서비스 시스템 환경은 연쇄 장애가 발생할 여지가 있다. - 하나의 마이크로서비스가 응답하지 않으면 이 마이크로서비스의 클라이언트 또한 또 다른 클라이언트의 요청에 응답하지 않게 된다. - 이 문제는 시스템 환경 전체에 재귀적으로 전파되어 중요한 부분까지 중단시킬 수 있다. 2. 참고사항 - 이런 문제는 블로킹 I/O를 사용해 동기식 요청을 실행하는 경우에 자주 발생한다. - 다수의 동시 요청이 발생한 상황에서 서비스의 응답이 예기치 않게 지연되면 스레드 풀이 빠르게 소진돼 호출이 지연되거나 중단된다. - 이런 장애는 클라이언트의 클라이언트에게 연쇄적으로 전파된다. 3. 해결책 대상 서비스에 문제가 있다는 것을 감지해 새 요청을 보내지 않도록 차단하는 서..
1. 문제점 시스템 환경에 대한 외부 호출을 처리하는 동안 마이크로서비스 사이에서 흐르는 요청 및 메시지를 추적 할 수 있어야 함 장애 시나리오 예시 - 최종 사용자가 특정 장애에 대한 해결을 요청했을 때 문제를 일으킨 마이크로서비스를 찾고 근본 원인을 밝히려면 어떻게 해야 하는가? - 특정 엔티티와 관련된 문제를 지원하고자 이와 관련된 모든 로그 메시지를 찾고 싶다. 예를 들어, 어떤 주문 번호에 대한 문제가 발생했을 때 해당 주문의 처리에 관여한 모든 마이크로서비스의 로그 메시지를 찾으려면 어떻게 해야 하는가? 2. 해결책 - 공조 마이크로서비스 사이의 처리 과정을 추적하려면 관련된 모든 요청 및 메시지에 상관 ID를 넣어야 하고, 모든 로그 이벤트에 상관 ID가 있어야 한다. (correlation..
1. 문제점 보통 애플리케이션을 실행하고 있는 서버에 로그를 기록하는데, 여러 개의 소규모 서버에 다수의 마이크로서비스 인스턴스를 배포하는 마이크로서비스 아키텍쳐 기반의 시스템 환경에선 다음과 같은 문제가 있다. - 각 마이크로서비스 인스턴스가 로컬에 로그 파일을 기록하는 상황에서 전체 시스템 환경에서 발생하는 사건을 개괄하려면 어떻게 해야 하는가? - 문제가 발생한 마이크로서비스 인스턴스를 찾아서 로그 파일에 오류 메시지를 쓰려면 어떻게 해야 하는가? - 최종 사용자가 문제를 보고했을 때 이와 관련된 로그 메시지를 찾으려면 어떻게 해야 하는가? - 문제의 근본 원인이 되는 마이크로서비스 인스턴스를 찾으려면 어떻게 해야 하는가? 2. 해결책 로그를 중앙화해 관리하고, 다음과 같은 기능을 갖춘 새 컴포넌트..
1. 문제점 - 일반적으로 애플리케이션은 여러 환경 변수나 파일에 담긴 구성 정보와 함께 배포된다. - 다수의 마이크로서비스 인스턴스가 배포된 마이크로서비스 아키텍처 기반의 시스템 환경에선 문제가 있다. > 실행 중인 모든 마이크로서비스 인스턴스의 구성 정보를 한눈에 보려면 어떻게 해야 하는가? > 구성을 업데이트하고 관련된 모든 마이크로서비스 인스턴스가 올바르게 업데이트 되기 하려면 어떻게 해야 하는가? 2. 해결책 시스템 환경에 모든 마이크로서비스의 구성정보를 저장하는 새 컴포넌트(구성서버)를 추가한다. - 마이크로서비스 집합에 대한 구성정보를 한 곳에 저장하고 환경별 설정을 지원한다. (예: dev, test, qa, prod) 3. 구현된 오픈소스 도구 - 스프링 클라우드 : Spring Conf..
1. 문제점 - 보통 HTTP 기반의 Restful Json API와 같은 블로킹 I/O 모델을 사용해 동기식 통신을 구현해 왔다. - 블로킹 I/O를 사용하면 요청을 처리하는 동안 운영체제의 스레드를 점유하게 된다. - 동시 요청 수 혹은 요청과 관련된 컴포넌트가 증가하면 운영체제의 가용 스레드가 부족해 응답 시간이 늦거나 서버가 중단되는 문제가 발생할 수 있다. - 블로킹 I/O를 과도하게 사용하면 마이크로서비스 시스템에 오류가 발생하기 쉽다. - 연쇄 장애가 발생할 수 있다. > 어떤 서비스의 지연 시간이 증가하면 가용 스레드가 부족해져서 클라이언트가 실패할 수 있다. > 이런 상황은 클라이언트의 클라이언트에게도 동일한 유형의 문제를 유발하게 된다. 2. 해결책 논블로킹 I/O를 사용해 데이터베이스..
1. 문제점 클라이언트가 마이크로서비스와 그 인스턴스를 찾을 수 있어야 한다. 일반적으로 컨테이너 등에서 실행되는 마이크로서비스 인스턴스는 시작하면서 동적 IP 를 할당 받는다. 그러다 보니 클라이언트에서는 마이크로서비스가 노출하는 HTTP 기반의 REST API를 호출하기 쉽지 않다. 2. 해결책 현재 사용 가능한 마이크로서비스와 그 인스턴스를 추적하는 새 컴포넌트(서비스검색 서비스)를 시스템 환경에 추가한다. - 마이크로서비스와 마이크로서비스 인스턴스를 자동으로 등록 및 해지한다. - 클라이언트는 마이크로서비스의 논리 엔드포인트에 요청을 보낼 수 있어야 한다. - 요청은 사용 가능한 마이크로서비스 인스턴스 중 하나로 라우팅된다. - 마이크로서비스에 대한 요청은 가용 인스턴스로 로드밸런싱 되어야 한다...