Struggling Journey

API Gateway 클라이언트와 백엔드 서버 사이의 출입문 (front door) 라우팅 (라우팅, 필터링, API 변환, 클라이언트 어댑터 API, 서비스 프록시) 횡단 관심사 (cross-service concerns) 보안, 인증 (authentication), 인가 (authorization) 일정량 이상의 요청 제한 (rate limiting) 계층 (metering) Netflix Zuul 마이크로 프록시 50개 이상의 AWS ELB의 앞단에 위치해 3개의 AWS 리전에 걸처 하루 백억 이상의 요청을 처리 (2015년 기준) Zuul 이중화 (L4 또는 ELB) API Gateway - Zuul Zuul의 모든 API 요청은 HystrixCommand로 구성되어 전달된다. 각 API 경로 (..

Interface 선언을 통해 자동으로 Http Client를 생성 RestTemplate은 concreate 클래스라 테스트하기 어렵다 관심사의 분리 서비스의 관심 - 다른 리소스, 외부 서비스 호출과 리턴값 관심 X - 어떤 URL, 어떻게 파싱할 것인가 Spring Cloud에서 Open-Feign 기반으로 Wrapping한 것이 Spring Cloud Feign Feign Feign은 Netflix에서 만든 선언적 Http 클라이언트이다. 선언적 Http클라이언트란, 어노테이션 선언만으로 Http 클라이언트를 만들 수 있고 이를 통해서 Http Api 호출이 가능한 것을 의미함. Feign 설정 방법 인터페이스 선언 만으로 Http Client 구현물을 만들어 줌 @FeignClient(name=..

Ribbon 사용 시 서버 목록을 yml에 직접 넣었는데, 자동화 할 방법은? '서버가 새롭게 시작되면 그것을 감지하여 목록에 자동으로 추가되고, 서버가 종료되면 자동으로 목록에서 삭제하기 위한 방법은 없을까?' Service Registry Service Registry 서비스 탐색, 등록 클라우드의 전화번호부 (단점) 침투적 방식 코드 변경 DiscoveryClient spring-cloud에서 서비스 레지스트리 사용 부분을 추상화(Interface) Eureka, Consul, Zookeeper, etcd 등의 구현체가 존재 Ribbon은 Eureka와 결합하여 사용 할 수 있으며, 서버 목록을 자동으로 관리. Eureka Server (Registry) 만들기 @EnableEurekaServer ..

Server Side LoadBalancer 일반적인 L4 Switch 기반의 Load Balancing Client는 L4의 주소만 알고 있음 L4 Swicth는 Server의 목록을 알고 있음 (Server Side Load Balancing) H/W Server Side Load Balancer 단점 H/W가 필요 (비용 up, 유연성 down) 서버 목록의 추가를 위해서는 설정 필요 (자동화 어려움) Load Balancing Schema가 한정적 (RR, Sticky) 12 factors의 dev/prod를 만족하기 어려움 (상용과 개발의 동일함을 가지기가 어렵다) Client LoadBalancer - Ribbon Client (API Caller : 호출하는 쪽에서) 에 탑재되는 S/W 모듈..

Circuit Breaker - Hystrix 분산 시스템에서의 Latency Tolerance and Fault Tolerance Hystrix 적용하기 @HystrixCommand public String anyMethodWithExternalDependency() { URI uri = URI.create("http://172.32.1.22:8090/recommended"); String result = this.restTemplate.getForObject(uri, String.class); return result; } 위의 메소드를 호출할 때 벌어지는 일 이 메소드 호출을 “Intercept” 하여 “대신” 실행 실행된 결과의 성공 / 실패 (Exception) 여부를 기록하고 “통계”를 낸다...

Netflix OSS 플랫폼(AWS) 안의 여러 컴포넌트와 자동화 도구를 사용하면서 파악한 패턴과 해결 방법을 블로그, 오픈 소스로 공개. Spring Cloud Spring Cloud는 Spring boot를 기반으로 MSA 구축에 특화된 라이브러리들의 집합 Spring Cloud에는 Eureka, Hystrix, Ribbon, Zuul 등 많은 넷플릭스 OSS가 통합되어 있음. 모놀리틱에서의 의존성 호출 모놀리틱에서의 의존성 호출은 100% 신뢰! Failure as a First Class Citizen (Failure -> 가장 중요하게 고려해야하는 요소) 분산 시스템, 특히 클라우드 환경에선 실패는 일반적인 표준이다. 모놀리틱엔 없던 장애 유형 한 서비스의 가동율 최대 99.99% 10억 요청 ..

Cloud Native 정의 '클라우드 네이티브'는 클라우드 컴퓨팅 모델을 사용하는 것을 전제로 설계된 시스템과 서비스를 의미함. '클라우드 네이티브'의 핵심은 애플리케이션을 어떻게 만들고 배포하는지에 있으며 위치는 중요하지 않음. 클라우드 서비스를 활용한다는 것은 컨테이너와 같이 민첩하고 확장 가능한 구성 요소를 사용해서 재사용 가능한 개별적인 기능을 제공하는 것을 의미한다. 이러한 기능은 멀티 클라우드와 같은 여러 기술 경계 간에 매끄럽게 통합되므로 제공 팀이 반복 가능한 자동화와 오케스트레이션을 사용해서 빠르게 작업 과정을 반복할 수 있다 - 앤디 맨, Chief Technology Advocate at Splunk Cloud Native의 특징 신축성 (Resiliecy) 민첩성 (Agility)..

MSA 정의 MSA란 시스템을 여러개의 독립된 서비스로 나눠서, 이 서비스를 조합함으로서 기능을 제공하는 아키텍처 디자인 패턴. 아마존의 선택 (2002년경 제프 베조스 메일) 1. 모든 팀들은 데이터와 기능들을 서비스 인터페이스로 연결시켜라. 2. 팀들은 이 인터페이스를 통해서만 연락해야 한다. 3. 다른 어떤 커뮤니케이션 방법도 허용되지 않는다. 직접 링크를 보내거나 다른 팀의 스토리지에 직접 억세스 해서도 안 되며, 공유 메모리나 백도어 같은 것도 안 된다. 모든 커뮤니케이션은 네트워크를 통한 서비스 인터페이스로 이루어져야 한다. 4. 어떤 기술을 쓰든 상관없다. HTTP, Cobra, Pubsub, 독자 프로토콜...그건 상관없다. 베조스는 그런데 관심 없다. 5. 모든 서비스 인터페이스는 예외 ..