일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |
- docker
- 알림
- Catalina
- 정규표현식
- 제어루프
- desktop
- Chat gpt
- chat API
- error
- application 재기동
- eclipse
- 분산추적
- MSA
- AWS
- GIT
- 모니터링 및 경고 중앙화
- MAC
- GitLab
- 리눅스
- ChatGPT
- linux
- 자바 정규식
- 네이버클라우드플랫폼
- 메시지
- 네이버웍스
- sh
- 가상머신 차이
- 도커
- crontab
- 마이크로서비스 패턴
- Today
- Total
목록MSA (3)
시간나는대로 틈틈히 정리 합시다~~!!!
1. 문제점 보통 애플리케이션을 실행하고 있는 서버에 로그를 기록하는데, 여러 개의 소규모 서버에 다수의 마이크로서비스 인스턴스를 배포하는 마이크로서비스 아키텍쳐 기반의 시스템 환경에선 다음과 같은 문제가 있다. - 각 마이크로서비스 인스턴스가 로컬에 로그 파일을 기록하는 상황에서 전체 시스템 환경에서 발생하는 사건을 개괄하려면 어떻게 해야 하는가? - 문제가 발생한 마이크로서비스 인스턴스를 찾아서 로그 파일에 오류 메시지를 쓰려면 어떻게 해야 하는가? - 최종 사용자가 문제를 보고했을 때 이와 관련된 로그 메시지를 찾으려면 어떻게 해야 하는가? - 문제의 근본 원인이 되는 마이크로서비스 인스턴스를 찾으려면 어떻게 해야 하는가? 2. 해결책 로그를 중앙화해 관리하고, 다음과 같은 기능을 갖춘 새 컴포넌트..
1. 정의 - 일체형 애플리케이션을 서로 협력하는 독립 소프트웨어 컴포넌트로 나누는 것이며, 애플리케이션을 쉽게 확장하고 빠르게 개발하기 위한 아키텍처이다. - 아래 두가지 목표를 달성하고자 일체형 애플리케이션을 작은 독립컴포넌트로 나누는 것이다. > 빠르게 개발해 지속적으로 배포할 수 있어야 한다. > 수동 혹은 자동으로 쉽게 스케일링할 수 있어야 한다. - 독립컴포넌트로 동작하려면 아래와 같은 기준을 충족해야 한다. > 아무것도 공유하지 않는 아키텍처를 유지해야 한다. (데이타베이스 공유X) > 명확한 인터페이스를 통해서만 통신해야 한다. (동기서비스 혹은 API를 이용한 메시징 방식을 사용할 수 있는데, 메시지 형식은 버전 관리 전략에 따라 안정적으로 문서화되고 개선되어야 한다.) > 개별적인 런타..
1. 문제점 - 보통 HTTP 기반의 Restful Json API와 같은 블로킹 I/O 모델을 사용해 동기식 통신을 구현해 왔다. - 블로킹 I/O를 사용하면 요청을 처리하는 동안 운영체제의 스레드를 점유하게 된다. - 동시 요청 수 혹은 요청과 관련된 컴포넌트가 증가하면 운영체제의 가용 스레드가 부족해 응답 시간이 늦거나 서버가 중단되는 문제가 발생할 수 있다. - 블로킹 I/O를 과도하게 사용하면 마이크로서비스 시스템에 오류가 발생하기 쉽다. - 연쇄 장애가 발생할 수 있다. > 어떤 서비스의 지연 시간이 증가하면 가용 스레드가 부족해져서 클라이언트가 실패할 수 있다. > 이런 상황은 클라이언트의 클라이언트에게도 동일한 유형의 문제를 유발하게 된다. 2. 해결책 논블로킹 I/O를 사용해 데이터베이스..