Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

11st Legacy Application의 Spring Cloud 기반 MicroServices로 전환 개발 사례

23,864 views

Published on

11번가의 기존 Application을 Spring Cloud 기반의 MSA로 전환하고 있는 내용에 대한 공유자료 입니다. 사내 발표용으로 만들어져서 일부 내용은 편집되었습니다.

Published in: Software
  • -- DOWNLOAD THIS BOOKS INTO AVAILABLE FORMAT -- ......................................................................................................................... ......................................................................................................................... Download FULL PDF EBOOK here { http://bit.ly/2m6jJ5M } ......................................................................................................................... (Unlimited)
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • accessibility Books Library allowing access to top content, including thousands of title from favorite author, plus the ability to read or download a huge selection of books for your pc or smartphone within minutes.........ACCESS WEBSITE Over for All Ebooks ..... (Unlimited) ......................................................................................................................... Download FULL PDF EBOOK here { http://bit.ly/2m6jJ5M } .........................................................................................................................
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • accessibility Books Library allowing access to top content, including thousands of title from favorite author, plus the ability to read or download a huge selection of books for your pc or smartphone within minutes ,Download or read Ebooks here ... ......................................................................................................................... Download FULL PDF EBOOK here { http://bit.ly/2m6jJ5M }
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Download or read that Ebooks here ... ......................................................................................................................... DOWNLOAD FULL PDF EBOOK here { http://bit.ly/2m6jJ5M } ......................................................................................................................... Download EPUB Ebook here { http://bit.ly/2m6jJ5M } ......................................................................................................................... Download Doc Ebook here { http://bit.ly/2m6jJ5M } ......................................................................................................................... .........................................................................................................................
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • accessibility Books Library allowing access to top content, including thousands of title from favorite author, plus the ability to read or download a huge selection of books for your pc or smartphone within minutes.........ACCESS WEBSITE Over for All Ebooks ..... (Unlimited) ......................................................................................................................... Download FULL PDF EBOOK here { http://bit.ly/2m6jJ5M } .........................................................................................................................
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

11st Legacy Application의 Spring Cloud 기반 MicroServices로 전환 개발 사례

  1. 1. 11st Legacy Application의 Spring Cloud 기반 MicroServices로 전환 개발 사례 Platform 개발단 Tech Infra 개발 본부 개발혁신팀 윤용성
  2. 2. 이 발표의 목적은… Spring Cloud의 가장 핵심이 되는 개념을 정확하게 이해 Spring Cloud의 주요 요소를 당장 자신의 Project 에 적용하기 위한 동기 부여 Spring Cloud 기반의 MSA로 전환 시 고려사항 공유
  3. 3. Project Vine 11st Legacy Application 개선 Project
  4. 4. Strangler Application Pattern 열대 우림 지역의 Stranger Vine에서 유래 Legacy 교살 전략 새로운 Application 은 독립된 API 서버로 Legacy와 함께 운영 위의 과정을 반복 Application Modernization Strategy “Strangler Application” by Martin Fowler
  5. 5. Strangler Application Pattern in 11st - Hybrid MSA WAR Front/Mobile WAS WAR Front/Mobile WAS REST
 API Zuul API Gateway 전시 API Server 상품 API Server 추천 API Server 추천 Service XXX API Server … Eureka Server Config Server Admin Server ?
  6. 6. Challenges
  7. 7. Best Practice - Netflix OSS & Spring Cloud Hystrix Eureka Ribbon EvCache Spectator Archaius …. Spring Cloud Config Stream Sleuth Contract ….….
  8. 8. Technical Background Spring Cloud Basic Component
  9. 9. Hystrix Circuit Breaker
  10. 10. Hystrix - Circuit Breaker public String anyMethodWithExternalDependency() { URI uri = URI.create("http://172.32.1.22:8090/recommended"); String result = this.restTemplate.getForObject(uri, String.class); return result; } @HystrixCommand Hystrix 적용하기 위의 메소드를 호출할 때 벌어지는 일 - 이 메소드 호출을 'Intercept' 하여 “대신” 실행 - 대신 ?? - 실행된 결과의 성공 / 실패 (Exception) 여부를 기록하고 “통계”를 낸다. - 통계 ?? - 실행 결과 “통계”에 따라 Circuit Open 여부를 판단하고 필요한 “조치”를 취 한다. 조치 ??
  11. 11. Hystrix - Circuit Breaker Circuit Open ?? - Circuit이 오픈된 Method는 (주어진 시간동안) 호출이 “제한”되며, “즉시” 에러를 반환한다. Why ? - 특정 메소드에서의 지연 (주로 외부 연동에서의 지연)이 시스템 전체의 Resource 를 (Thread, Memory등)를 모두 소모하여 시스템 전체의 장애를 유발한다. - 특정 외부 시스템에서 계속 에러를 발생 시킨다면, 지속적인 호출이 에러 상 황을 더욱 악화 시킨다. So ! - 장애를 유발하는 (외부) 시스템에 대한 연동을 조기에 차단 (Fail Fast) 시킴 으로서 나의 시스템을 보호한다. 기본 설정 - 10초동안 20개 이상의 호출이 발생 했을때 50% 이상의 호출에서 에러가 발 생하면 Circuit Open
  12. 12. Hystrix - Circuit Breaker public String anyMethodWithExternalDependency() { URI uri = URI.create("http://172.32.1.22:8090/recommended"); String result = this.restTemplate.getForObject(uri, String.class); return result; } @HystrixCommand 이제 이 메소드가 호출된다면 ? - 이 메소드는 'Intercept' 되어 별도의 Hystrix Thread Pool에서 “대신” 실행 된다. - 메소드 내부에서 발생한 Exception의 횟수는 Circuit Breaker 내에서 통계 가 내어진다. - Circuit Open 조건에 도달하면 Circuit이 Open되어 호출이 차단 된다. * 가장 기본적인 Circuit Breaker 개념 적용 완료 !
  13. 13. Hystrix - Circuit Breaker - 기본 설정으로는 유사한 일을 하는 두개의 메소드가 별도의 Circuit Breaker를 갖게된다. public String anyMethodWithExternalDependency1() { URI uri = URI.create("http://172.32.1.22:8090/recommend"); String result = this.restTemplate.getForObject(uri, String.class); return result; } @HystrixCommand public String anyMethodWithExternalDependency2() { URI uri = URI.create("http://172.32.1.22:8090/mainrecommend"); String result = this.restTemplate.getForObject(uri, String.class); return result; } @HystrixCommand Circuit Breaker는 어떤 단위로 생성되는가 ? - Default로 @HystrixCommand가 명시된 메소드 단위
  14. 14. Hystrix - Circuit Breaker Circuit의 단위 명시하기 - CommandKey - “CommandKey”는 Circuit Breaker의 단위이며 여러개의 메소드를 같은 Key를 명시함으로써 하나의 Circuit을 사용하게 할 수 있다. public String anyMethodWithExternalDependency1() { URI uri = URI.create("http://172.32.1.22:8090/recommended"); String result = this.restTemplate.getForObject(uri, String.class); return result; } @HystrixCommand(commandKey = “ExtDep1”) public String anyMethodWithExternalDependency2() { URI uri = URI.create("http://172.32.1.22:8090/mainrecommend"); String result = this.restTemplate.getForObject(uri, String.class); return result; } @HystrixCommand(commandKey = “ExtDep1”) - 즉, A 메소드와 B 메소드가 같은 Circuit Breaker를 사용한다면, A 와 B의 에러 비율이 함께 통계내어지고, Circuit이 오픈되면 함께 차 단된다.
  15. 15. Hystrix - Circuit Breaker public String anyMethodWithExternalDependency1() { URI uri = URI.create("http://172.32.1.22:8090/recommended"); String result = this.restTemplate.getForObject(uri, String.class); return result; } public String recommendFallback() { return “<미리 준비된 상품 목록>”; } @HystrixCommand(commandKey = “ExtDep1”, fallbackMethod=“recommendFallback”) Hystrix의 또 하나의 중요한 개념 - Fallback - Fallback method는 Circuit이 오픈된 경우 혹은 Exception이 발생한 경우 대신 호출될 Method. - 오류 발생시 Exception 대신 응답할 Default 구현을 넣는다.
  16. 16. Hystrix - Circuit Breaker 오랫동안 응답이 없는 메소드에 대한 처리 방법은 ? - 특정 메소드의 총 소요시간에 대한 Timeout을 직접 관리/예측하는 것은 매우 힘들다 - ex) Socket Connect/Read Timeout, JDBC Timeout, 3rd Party 라이브러디 등 - 설정하지 않으면 default 1,000ms - 물론 이경우에도 Fallback이 있다면 Fallback을 수행 Hystrix에서는 Circuit Breaker별로 Timeout 설정 가능 - 해당 메소드가 설정된 시간안에 안 끝나면 Timeout으로 인한 Exception 자 동 발생
  17. 17. Hystrix - Circuit Breaker 연동 System A Thread Pool A (20 threads) Thread Pool B (10 threads) Thread Pool C (15 threads) Circuit Breaker A Circuit Breaker B Circuit Breaker C Circuit Breaker D Circuit Breaker F 연동 System B 연동 System C User Request Hystrix를 쓴다는 것의 또다른 의미 - Hystrix를 통해 실행한다는 것은 별도의 Thread Pool에서 내 Code를 실행 한다는 것 - 각 Circuit Breaker는 한 개의 Thread Pool과 연동 - 하나의 ThreadPool을 여러 개의 Circuit Breaker가 공유할 수 있다.
  18. 18. Hystrix - Circuit Breaker 각 Circuit Breaker가 사용할 Thread Pool의 지정 - 내 시스템의 Resource가 다양한 기능(서비스)들을 위해 골고루 분배 될 수 있도록.. - 어느 하나 외부 Dependency (외부 연동 시스템)의 문제 발생시 그 영 향으로 부터 시스템의 다른 요소를 보호 - Isolation - ThreadPoolKey (혹은 CommandGroupKey) 속성으로 지정 - 각 Thread Pool 별로 Max Thread 지정 Thread Pool을 사용하는 의미 * Hystrix는 Thread Isolation이 아닌 Semaphore 방식의 Isolation도 제공합니다. (옵션)
  19. 19. 소스 : https://medium.com/netflix-techblog/fault-tolerance-in-a-high-volume-distributed-system-91ab4faae74a 가정 각 서버 별 가용성 : 99.99% 30개의 Dependency 존재 99.99% ^ 30 = 99.7% Uptime = 1달 기준 2시 간 인용 : https://speakerdeck.com/benjchristensen/performance-and-fault-tolerance-for-the-netflix-api-august-201
  20. 20. Ribbon Client Load Balancer
  21. 21. Server Side Load Balancer (with L4 Switch) Client (Caller) Server1 Server2 Server3 Server4 L4 Switc h - 일반적인 L4 Switch 기반의 Load Balancing - Client는 L4의 주소만 알고 있음 - L4 Switch는 Server의 목록을 알고 있음 (Server Side Load Balancer) - H/W Server Side Load Balancer 단점 (장점도 있지만..) - H/W가 필요 (비용↑, 유연성↓) - 서버 목록의 추가를 위해서는 설정 필요 (자동화 어려움) - Load Balancing Scheme이 한정적 (Round Robin, Sticky)
  22. 22. Client Side Load Balancer - Ribbon Client (Caller) Server1 Server2 Server3 Server4 - Client (API Caller)에 탑재되는 S/W 모듈 - 주어진 서버 목록에 대해서 Load Balancing을 수행함 - Ribbon의 장점 (단점도 있지만… ) - H/W가 필요 없이 S/W로만 가능 (비용↓, 유연성↑) - 서버 목록의 동적 변경이 자유로움 - Load Balancing Scheme이 마음대로 구성 가능 R i b b o
  23. 23. Client Side Load Balancer - Ribbon 단순한 Load Balancer ? ServerList - Load Balancing의 대상이될 Server 목록 결정 - 1) Configuration을 통해 직접 목록 설정 - 2) Discovery 기반으로 Runtime에 획득한 서버 목록 사용 IRule - 트래픽을 보낼 서버를 선택 - 1) Simple Round Robbin - 2) Response Time Weighted - 서버별 응답 시간에 따라 트래픽 양 조절 - 3) Availability Filter - 최근 3번 연속 에러를 발생시킨 서버를 Load Balancing 대상에서 일정시 간 동안 제외 시킴
  24. 24. Client Side Load Balancer - Ribbon 단순한 Load Balancer ? IPing - 주기적으로 호출하여 해당 서버의 Aliveness를 검사 - 1) 특정 URL 호출 - 2) Discovery 기반 - Discovery 서버에 UP 상태로 등록되어 있는지 조사 - Ping에 실패한 서버는 임시로 Load Balancing 대상에서 제외 ServerList, IRule, IPing 등 Ribbon의 주요 기능은 다양하게 설 정이 가능하며, 직접 구현하여 넣는 것도 가능
  25. 25. Client Side Load Balancer - Ribbon Ribbon의 또 하나의 중요한 기능 - Retry Client (Caller) Server1 Server2 Server3 Server4 R i b b o O 선택된 대상으로의 호출 실패 시 정해진 횟수 만큼의 Retry 설정 가능 - 같은 서버 재시도 횟수, 다른 서버 재시도 횟수 설정 - Exception 발생 경우 뿐만 아니라 재시도 할 HTTP Status 지정 가능
  26. 26. Client Side Load Balancer - Ribbon How to Use - 다양한 사용 방법이 존재….. - 직접 API 호출하여 대상 서버/포트 획득 후 사용 다양한 Http Client 및 Server에 이미 내장되어 있음 - Spring `RestTemplate` - @LoadBalanced RestTemplate - Spring Cloud Feign Client - Declarative Http Client - Ribbon이 내장되어 있음 - Zuul API Gateway - Ribbon이 내장되어 있음
  27. 27. Eureka Dynamic Service Discovery
  28. 28. MSA를 적용한다고 하나의 서버를 여러개의 API 서버로 분할했는데… - 수많은 API 서버의 IP Address와 Port 번호는 어떻게 Caller에게 전달하 지 ? - L4도 없이 Client Load Balancer를 사용하는데, 각 Ribbon 설정에 언제 서버 주소와 포트 번호를 설정하지 ? 서버 분할 후 고민… “서버가 새롭게 투입되면 그것을 감지하여 목록에 자동으로 추가되고, 서버가 종료되면 자동으로 목록에서 삭제하기 위한 방법은 없을까 ?” “API를 호출하는 쪽에서도 상대방 주소(들)을 알 필요 없이 이름 만으 로 호출하게 할 수는 없을까 ? ”
  29. 29. Dynamic Service Discovery - Eureka API Server “A” Eureka Client Eureka Server Service A ip1:8081 Service B Service C Service D API Caller “가” Eureka Client 0. Eureka를 사용할 모든 Server에 Eureka Client 탑재 주기적으로 Fetch ② 2. Eureka Client는 주기적으로 Service별 IP 목록을 Fetch 보관 서버 시작시 - 등록 / 종료시 - 제거 IP주소:port:”Service A” ① 1. 서버 가동시 자신의 정보(ip/port/서비스명)을 Eureka Server에 등록 (반대로 종료시 삭제) ③ Eureka에 획득한 주소로 호 출 3. API 호출시 서비스 이름 (Service A)를 사용하여 해당 서버 목록 획득 후 호출
  30. 30. Dynamic Service Discovery - Eureka API Server “A” - instance #1 Eureka Client Eureka Server Service A ip1:8081 ip2:8081 ip3:8081 Service B Service C Service D 서버 시작시 - 등록 / 종료시 - 제거 IP주소:port:”Service A” API Server “A” - instance #2/3/4/5/6 Eureka Client Eureka Client Eureka Client Eureka Client Eureka Client 서버 인스턴스 추가 / 제거시 별도의 설정 작업 없이 가능
  31. 31. Dynamic Service Discovery - Eureka Eureka Server 만들기 / Eureka Client 탑재하기 @EnableEurekaServer @SpringBootApplication public class EurekaServiceApplication { public static void main(String[] args) { SpringApplication.run(EurekaServiceApplication.class); } } - Eureka + Ribbon의 결합 시 Ribbon의 LoadBalancing 서버 목록을 Eureka를 통해서 공급 @EnableEurekaClient @SpringBootApplication public class EurekaServiceApplication { public static void main(String[] args) { SpringApplication.run(EurekaServiceApplication.class); } } * dependency 추가 및 추가 설정 필요
  32. 32. Hystrix + Ribbon + Eureka
  33. 33. Hystrix + Ribbon + Eureka 1. Server간의 호출은 Hystrix를 적용한다. - 장애시 Circuit Open을 통한 장애 전파 차단 - Fallback을 통해 응답 오류시 대체 응답 제공 - Timeout을 통해 최대 응답 가능 시간 제어 - Thread Pool 분리를 통한 Isolation 제공 2. Server간의 Load Balancing은 Ribbon을 적용한다. - L4 구성 없이 복수 서버로의 Load Balancing 쉽게 가능 - IRule에 의해서 에러 발생 서버를 Load Balancing 대상에서 임시 제거 - IPing을 통해서 서버의 Aliveness에 따라 트래픽 유입 결정 - Retry를 통해서 호출 실패 시 재시도
  34. 34. Hystrix + Ribbon + Eureka 3. Server의 주소는 Eureka를 통해서 획득한다. - 서버 인스턴스 추가 / 삭제시 Ribbon + Eureka에 의해 자동 반영 - 서버 Down시 Eureka Server가 해당 상태를 반영함으로써 목록에서 제거 “Hystrix + Ribbon + Eureka`를 함께 사용함으로써… - MSA 환경에서의 서버간의 복잡한 호출 관계로 발생할 수 있는 서비스 안정성 문제를 최대한 해결 - 인프라 구성의 단순화
  35. 35. 11st Legacy Application 개선 프로젝트 Project Vine 다시 본론으로…
  36. 36. Strangler Application Pattern in 11st - Hybrid MSA WAR Front/Mobile WAS WAR Front/Mobile WAS REST
 API ?
  37. 37. WAR Front/ WAR Front/ ? 첫번째 고민 - Legacy Application에서 새로 만들어진 수많은 API 서버들을 어떻게 호출할까 ? - Old S/W Stack, 대단위 수정 배포의 Risk 등으로 Eureka, Ribbon 등을 Legacy Application에 직접 탑재하는 것이 어려움 11st New Architecture - Legacy로 부터의 호출
  38. 38. WAR Front/ WAR Front/ ? 두번째 고민 - 모든 API 서버들에 들어갈 공통된 기능을 구현할 곳과, 전체 API 호출을 통제할 곳이 필요해 “전체 API Server들의 맨 앞단에 API Gateway의 도입으로 해결 가 능” 11st New Architecture - Legacy로 부터의 호출
  39. 39. API Gateway - Spring Cloud Zuul의 도입 - API의 외부 노출을 위한 Endpoint로서의 역할 - URL별로 Mapping된 Server 군으로 API 호출을 Forward - 일반적인 API Gateway와 유사 - ? Box 만이 특별한 점
  40. 40. API Gateway - Zuul 1. HystrixCommand 1. Zuul의 모든 API 요청은 HystrixCommand로 구성되어 전달된다. - 각 API 경로 (서버군) 별로 Circuit Breaker 생성 - 하나의 서버군이 장애를 일으켜도 다른 서버군의 서비스에는 영향이 없다. - CircuitBreaker / ThreadPool의 다양한 속성을 통해 서비스 별 속성에 맞는 설정 가능 Service “A” Servers
  41. 41. API Gateway - Zuul 1. HystrixCommand 2. API를 전달할 서버의 목록을 갖고 Ribbon을 통해 Load-Balancing을 수행한 다. - 주어진 서버 목록들을 Round-Robin으로 호출 - 연속 에러 발생 서버는 목록에서 임시 제거 - Coding을 통해 Load Balancing 방식 Customize 가능 Service “A” Servers 2. Ribbon
  42. 42. API Gateway - Zuul 1. HystrixCommand 3. Eureka Client를 사용하여 주어진 URL의 호출을 전달할 “서버 리스트”를 찾는다. - Zuul에는 Eureka Client가 내장 - 각 URL에 Mapping된 서비스 명을 찾아서 Eureka Server를 통해 목록을 조회 한다. - 조회된 서버 목록을 `Ribbon` 클라이언트에게 전달한다. Service “A” Servers 2. Ribbon 3. Eureka Client
  43. 43. API Gateway - Zuul 1. HystrixCommand 4. Eureka + Ribbon에 의해서 결정된 Server 주소로 HTTP 요청 - Apache Http Client가 기본 사용 - OKHttp Client 사용 가능 Service “A” Servers 2. Ribbon 3. Eureka Client 4. Http Client
  44. 44. API Gateway - Zuul 1. HystrixCommand 5. 선택된 첫 서버로의 호출이 실패할 경우 Ribbon에 의해서 자동으로 Retry 수행 - Retry 수행 조건 - Http Client에서 Exception 발생 (IOException) - 설정된 HTTP 응답코드 반환 (ex 503) Service “A” Servers 2. Ribbon 3. Eureka Client 4. Http Client 5. Retry By Ribbon
  45. 45. API Gateway - Zuul 1. HystrixCommand Zuul의 모든 호출은…. Service “A” Servers 2. Ribbon 3. Eureka Client 4. Http Client 5. Retry By Ribbon - HystrixCommand로 실행되므로 Circuit Breaker를 통해 - 장애시 Fail Fast 및 Fallback 수행 가능 - Ribbon + Eureka 조합을 통해 - 현재 서비스가 가능한 서버의 목록을 자동으로 수신 및 상태에 따른 목록 제 - Ribbon의 Retry 기능을 통해 - 동일한 종류의 서버들로의 자동 재시도가 가능
  46. 46. 11st New Architecture with Zuul API Gateway WAR Front/Mobile WAS WAR Front/Mobile WAS REST
 API 전시 API Server 상품 API Server 추천 API Server 추천 Service XXX API Server … Eureka Server Config Server Admin Server Zuul API Gateway Hystrix + Eureka + Ribbon 모든 Legacy Application으로 부터의 호출은 Zuul API Gateway를 통해서 호출
  47. 47. 11st New Architecture - Internal Server to Server호출 WAR Front/Mobile WAS REST
 API 전시 API Server 상품 API Server 추천 API Server 추천 Service XXX API Server … Eureka Server Config Server Admin Server Zuul API Gateway Hystrix + Eureka + Ribbon 새롭게 분리된 API 서버간에도 많은 호출이 필요하다. - Hystrix, Ribbon, Eureka를 내부 호출 안에서도 적용할 필요 가 있다.
  48. 48. 11st New Architecture - Internal Server to Server호출 내부 API 서버간에 Hystrix + Ribbon + Eureka를 적용하는 방법 1. Hystrix + Ribbon + Eureka를 직접 사용 2. @LoadBalanced RestTemplate + Hystrix Wrapping 3. Spring Cloud Feign을 사용하는 방법
  49. 49. Spring Cloud Feign Declarative Http Client - Java Interface + Spring MVC Annotation 선언 만으로 HTTP 호출을 위한 HTTP Client Bean을 자동 생성 - Open Feign기반의 Spring Cloud 확장 Hystrix + Eureka + Ribbon 연동 기능 내장 - 간단한 설정만으로 Hystrix, Ribbon, Eureka 적용이 가능 - 즉, HTTP 호출에 다음의 기능들이 자동으로 적용 가능 - 예) Circuit Open, Timeout, Fallback, Thread Pool Isolation, Load Balancing, Dynamic Service Discovery
  50. 50. 11st New Architecture with Spring Cloud Feign WAR Front/Mobile WAS REST
 API 전시 API Server 상품 API Server 추천 API Server 추천 Service XXX API Server … Eureka Server Config Server Admin Server Zuul API Gateway Hystrix + Eureka + Ribbon Spring Cloud Feign Hystrix + Eureka + Ribbon 모든 내부 호출에도 Hystrix, Ribbon, Eureka를 적용하여 Server 간 직접 호출한다.
  51. 51. 11st New Architecture - 외부 서버로의 호출 WAR Front/Mobile WAS REST
 API 전시 API Server 상품 API Server 추천 API Server 추천 Service XXX API Server … Eureka Server Config Server Admin Server Zuul API Gateway Hystrix + Eureka + Ribbon 페 인 페 인 신규 API 서버로 부터 기존의 외부 서버로의 호출 - 기존 외부 서버는 Eureka Client가 탑재 되어 있지 않으므로 Eureka를 통한 서 버 주소 획득은 어려움 - Hystrix + Ribbon의 조합만 사용 (실제 구현은 Spring Cloud Feign을 통해 Eureka만 disable해서 사용)
  52. 52. 11st New Architecture - 외부 서버로의 호출 WAR Front/Mobile WAS REST
 API 전시 API Server 상품 API Server 추천 API Server 추천 Service XXX API Server … Eureka Server Config Server Admin Server Zuul API Gateway Hystrix + Eureka + Ribbon 페 인 페 인 Hystrix + Ribbon 신규 API 서버에서 외부 서버로의 호출은 Hystrix + Ribbon 조 합을 사용한다.
  53. 53. 11st Architecture TF Project Vine - Platform Management
  54. 54. 기존 L4 기반의 Zero Downtime Deployment Client (Caller) Server1 Server2 Server3 Server4 L4 Switc h 배포시스 템 (Jarvis) 1. 배포 대상 서버 L4 Out 명령 2. 서버 배포 및 재가동 3. L4 In 명령
  55. 55. 11st New Architecture - Spring Cloud 기반의 Zero Downtime Deployment Eureka Server Client (Caller) Server1 Server2 Server3 Server4 배포시스 템 (Jarvis) 1. 배포 대상 서버 Eureka 상태 변경 요청 - Out Of Service 3. 서버 배포 및 재가동 R i b b o E u r e k 4. 서버 재가동시 Eureka 상태 원상 복구 - UP 2. 주기적인 Eureka 상태 정보 동기화 현재는 Jarvis의 명령어를 통해 Eureka에 Manually 명령을 내리게 구성되어있지만, 올해 내 Eureka-Aware하게 배포 시스템 개선 예정
  56. 56. 11st New Architecture - Spring Cloud 기반의 Zero Downtime Deployment 그러나 실제 Eureka의 상태 변경이 API를 호출하는 쪽에 까지 반영되는데는 시간이 필요함 1. Eureka Server의 응답 Cache 2. Eureka Client의 주기적 동기화 주기 3. Ribbon의 내부 Cache 갱신 주기 * 위의 세가지 옵션에 대한 “주의깊은” 조정 과 이해가 필요
  57. 57. 11st New Architecture - Config 관리 기존의 Configuration 관리 - Application Config - 주로 War안에 Properties 파일 포함 - 개발자가 관리 - WAS Config - 해당 시스템의 디렉토리에 존재 - Infra Engineer가 관리 Project Vine에서의 Config 관리 문제 - Spring Boot 기반의 Embedded Tomcat 사용 - 따라서, WAS(Tomcat) Config가 War 안에 같이 포함 - 담당 Infra Engineer가 이를 수정하기 위해서는 Repository에 Clone / 수정 / 빌드 / 배포를 다시해야 한 다 ?
  58. 58. 11st New Architecture with Spring Cloud Config Spring Cloud Config - Git 기반으로 Config 파일들을 관리 - Config Client를 탑재한 서버들은 가동 시 Config Server 에 접속하여 관련된 모든 Config를 내려받아 적용 Spring Cloud Config Server API
 Server Spring Cloud Config Client Git Repo API
 Server Spring Cloud Config Client API
 Server Spring Cloud Config Client Clone & Fetch Config FileConfig FileConfig FileConfig FileConfig FileConfig FileConfig FileConfig FileConfig FileConfig File
  59. 59. 11st New Architecture with Spring Cloud Config Spring Cloud Config + Git 기반으로 Config 관리의 장점 - Config 의 수정 내용이 Git History로 남는다. - 누가 / 언제 / 왜 이 Property를 고쳤는지를 확인하는 것이 서 버 문제 발생시 제일 어려운 점 - Embedded WAS를 사용하는 경우도 Infra Engineer들이 설정 변 경이 용이하다. - Application 소스 Repo의 수정이 아닌 Config 전용 Repo의 수정 - 재빌드 없이 적용 가능 - Config 변경에 관한 Pull Request 및 Review가 가능하다. - Config 변경 사항을 Pull Request로 생성 - 동료/리더 들의 Review를 통해 오류 방지 - Infra Engineer 와 개발자간 상호 협력
  60. 60. 11st New Architecture - Monitoring 기존의 Monitoring Infra 이외의 추가 적인 Monitoring 요건 발생 Hystrix Monitoring - Hystrix의 상태가 시스템 전체적으로 제일 중요한 모니터링 요소가 됨 - 각 Circuit Breaker의 통계 및 상태 - 각 Thread Pool의 통계 및 상태 Netflix Turbine을 통해 Hystrix Dashboard 구성 가능
  61. 61. 11st New Architecture - Monitoring Spring Boot Application의 각 상태 정보 조회 및 제어 - Spring Boot Admin Server을 통해 각 API Server의 Actuator를 통한 정보 획득 및 제어 가능 - Spring Boot Admin Server를 자체로 확장 (진행중) - Eureka의 세부 상태 조회 / 제어 - Zuul의 내부 상태 조회 / 제어
  62. 62. Project Vine Lessons Learned
  63. 63. Lessons Learned “Open Source를 100% 신뢰하지는 말것” Documentation은 부실할 수 있으며, Bug가 다수 존재할 수 있으며, 심지어 Bug가 발견되어도 아무도 급하게 Bug를 수정해 주지 않는다. Source 보는 것을 두려워 하지 않으며, 확인이 필요한 중 요한 기능은 꼭 소스코드를 확인하라 Github의 Issues / Pull Request를 자주 확인하라
  64. 64. Lessons Learned “Test, Test, Test” Open Source의 현재 동작하던 기능이 Version Up과 함 께 사라지거나 다르게 동작할 수 있다. Property는 쉽게 추가되거나 삭제될 수 있다. 대부분의 경우 우리는 이러한 변화를 인지하지 못한다. Open Source를 통해 사용하는 주요 기능에 대해서 Integration 테스트를 작성하여 Version Up 이후에도 여전 히 원하는 대로 동작하는지 확인하라 ex) 틀린 주소를 주입하고 우리의 Fallback이 호출되는 지 확인하는 테스트
  65. 65. The End

×