카카오 광고 플랫폼 MSA 적용 사례 및 API Gateway와 인증 구현에 대한 소개if kakao
황민호(robin.hwang) / kakao corp. DSP개발파트
---
최근 Spring Cloud와 Netflix OSS로 MSA를 구성하는 시스템 기반의 서비스들이 많아지는 추세입니다.
카카오에서도 작년에 오픈한 광고 플랫폼 모먼트에 Spring Cloud 기반의 MSA환경을 구성하여, API Gateway도 적용하였는데 1년 반 정도 운영한 경험을 공유할 예정입니다. 더불어 MSA 환경에서는 API Gateway를 통해 인증을 어떻게 처리하는지 알아보고 OAuth2 기반의 JWT Token을 이용한 인증에 대한 이야기도 함께 나눌 예정입니다.
카카오 광고 플랫폼 MSA 적용 사례 및 API Gateway와 인증 구현에 대한 소개if kakao
황민호(robin.hwang) / kakao corp. DSP개발파트
---
최근 Spring Cloud와 Netflix OSS로 MSA를 구성하는 시스템 기반의 서비스들이 많아지는 추세입니다.
카카오에서도 작년에 오픈한 광고 플랫폼 모먼트에 Spring Cloud 기반의 MSA환경을 구성하여, API Gateway도 적용하였는데 1년 반 정도 운영한 경험을 공유할 예정입니다. 더불어 MSA 환경에서는 API Gateway를 통해 인증을 어떻게 처리하는지 알아보고 OAuth2 기반의 JWT Token을 이용한 인증에 대한 이야기도 함께 나눌 예정입니다.
OpenSearch는 배포형 오픈 소스 검색과 분석 제품군으로 실시간 애플리케이션 모니터링, 로그 분석 및 웹 사이트 검색과 같이 다양한 사용 사례에 사용됩니다. OpenSearch는 데이터 탐색을 쉽게 도와주는 통합 시각화 도구 OpenSearch와 함께 뛰어난 확장성을 지닌 시스템을 제공하여 대량 데이터 볼륨에 빠르게 액세스 및 응답합니다. 이 세션에서는 실제 동작 구조에 대한 설명을 바탕으로 최적화를 하기 위한 방법과 운영상에 발생할 수 있는 이슈에 대해서 알아봅니다.
AWS 클라우드를 활용하면 사용자의 트래픽에 따라 IT 인프라 아키텍처를 확장할 수 있습니다. 이번 강연에서는 서비스 초기의 작은 트래픽에 대응할 수 있는 단순한 아키텍처로 시작해 사업 성장 후의 수백만 사용자에 달하는 대규모 트래픽을 지탱할 수 있는 고확장성 아키텍처에 이르기까지의 단계별 아키텍처 구성 방법에 대해 소개해 드리고 컴퓨팅 및 데이터베이스 선택 및 사용자 증가에 따른 트래픽 경감 방법, 오토스케일링 및 모니터링과 자동화, DB 부하 분산, 고가용성 확보 등에 대한 다양한 모범사례를 알려드릴 예정입니다.
[오픈소스컨설팅]클라우드기반U2L마이그레이션 전략 및 고려사항Ji-Woong Choi
Cloud 기반으로 U2C(Unix to Cloud),U2L(Unix to Linux) 마이그레이션에 대한 가이드 라인과 사이징 관련 고려 사항에 대해 설명한 자료입니다.
많은 전환 프로젝트에서 추출된 경험치가 들어가 있으며, 전환별 난이도 및 고려사항이 들어가 있습니다.
데브시스터즈의 Cookie Run: OvenBreak 에 적용된 Kubernetes 기반 다중 개발 서버 환경 구축 시스템에 대한 발표입니다.
Container orchestration 기반 개발 환경 구축 시스템의 필요성과, 왜 Kubernetes를 선택했는지, Kubernetes의 개념과 유용한 기능들을 다룹니다. 아울러 구축한 시스템에 대한 데모와, 작업했던 항목들에 대해 리뷰합니다.
*NDC17 발표에서는 데모 동영상을 사용했으나, 슬라이드 캡쳐로 대신합니다.
고객의 플랫폼/서비스를 개선한 국내 사례 살펴보기 – 장준성 AWS 솔루션즈 아키텍트, 강산아 NDREAM 팀장, 송영호 야놀자 매니저, ...Amazon Web Services Korea
AWS는 175개 이상의 다양한 서비스를 제공해드리고 있습니다. 주요 서비스들 외에도 고객 서비스의 품질을 개선하는 데에 이러한 다양한 AWS의 서비스들의 도움을 받을 수 있습니다. 이번 세션에서는 AWS Transit Gateway, AWS Global Accelerator, AWS Shield, AWS IoT, Amazon WorkSpaces 를 통해서 고객의 플랫폼/서비스를 개선한 국내 사례들을 살펴보며 AWS 서비스들을 어떻게 활용할 수 있는지 보여드립니다.
배민찬(https://www.baeminchan.com) 서비스의 백엔드 시스템 중 일부가 지난 1년간 어떤 고민과 아이디어, 결과물을 만들어냈는지 공유하려고 합니다. 발표 중 언급되는 용어나 도구에 대해 일반적인 정의나 간단한 설명은 언급되나 자세히 다루지 않습니다. 사용된 도구들로 어떻게 이벤트 기반 분산 시스템을 만들었는지에 대한 이야기가 중심입니다.
클라우드 여정의 시작 - 클라우드 전문가 조직의 프랙티컬 가이드-김학민, AWS SA Manager::AWS 마이그레이션 A to Z 웨비나Amazon Web Services Korea
마이그레이션 도중 고객 IT팀은 On-premise 운영 모델에서 클라우드 운영 모델로 전환되어야 합니다. 전환 도중에 ITIL을 클라우드, 애자일, DevOps 기반 역량과 프로세스에 매핑해야 합니다. 해당 세션에서는 클라우드 운영 모델로 원활한 전환을 도와주는 CEE (Cloud Enablement Engine)의 작동 원리 및 적용 방식을 살펴보고자 합니다.
OpenSearch는 배포형 오픈 소스 검색과 분석 제품군으로 실시간 애플리케이션 모니터링, 로그 분석 및 웹 사이트 검색과 같이 다양한 사용 사례에 사용됩니다. OpenSearch는 데이터 탐색을 쉽게 도와주는 통합 시각화 도구 OpenSearch와 함께 뛰어난 확장성을 지닌 시스템을 제공하여 대량 데이터 볼륨에 빠르게 액세스 및 응답합니다. 이 세션에서는 실제 동작 구조에 대한 설명을 바탕으로 최적화를 하기 위한 방법과 운영상에 발생할 수 있는 이슈에 대해서 알아봅니다.
AWS 클라우드를 활용하면 사용자의 트래픽에 따라 IT 인프라 아키텍처를 확장할 수 있습니다. 이번 강연에서는 서비스 초기의 작은 트래픽에 대응할 수 있는 단순한 아키텍처로 시작해 사업 성장 후의 수백만 사용자에 달하는 대규모 트래픽을 지탱할 수 있는 고확장성 아키텍처에 이르기까지의 단계별 아키텍처 구성 방법에 대해 소개해 드리고 컴퓨팅 및 데이터베이스 선택 및 사용자 증가에 따른 트래픽 경감 방법, 오토스케일링 및 모니터링과 자동화, DB 부하 분산, 고가용성 확보 등에 대한 다양한 모범사례를 알려드릴 예정입니다.
[오픈소스컨설팅]클라우드기반U2L마이그레이션 전략 및 고려사항Ji-Woong Choi
Cloud 기반으로 U2C(Unix to Cloud),U2L(Unix to Linux) 마이그레이션에 대한 가이드 라인과 사이징 관련 고려 사항에 대해 설명한 자료입니다.
많은 전환 프로젝트에서 추출된 경험치가 들어가 있으며, 전환별 난이도 및 고려사항이 들어가 있습니다.
데브시스터즈의 Cookie Run: OvenBreak 에 적용된 Kubernetes 기반 다중 개발 서버 환경 구축 시스템에 대한 발표입니다.
Container orchestration 기반 개발 환경 구축 시스템의 필요성과, 왜 Kubernetes를 선택했는지, Kubernetes의 개념과 유용한 기능들을 다룹니다. 아울러 구축한 시스템에 대한 데모와, 작업했던 항목들에 대해 리뷰합니다.
*NDC17 발표에서는 데모 동영상을 사용했으나, 슬라이드 캡쳐로 대신합니다.
고객의 플랫폼/서비스를 개선한 국내 사례 살펴보기 – 장준성 AWS 솔루션즈 아키텍트, 강산아 NDREAM 팀장, 송영호 야놀자 매니저, ...Amazon Web Services Korea
AWS는 175개 이상의 다양한 서비스를 제공해드리고 있습니다. 주요 서비스들 외에도 고객 서비스의 품질을 개선하는 데에 이러한 다양한 AWS의 서비스들의 도움을 받을 수 있습니다. 이번 세션에서는 AWS Transit Gateway, AWS Global Accelerator, AWS Shield, AWS IoT, Amazon WorkSpaces 를 통해서 고객의 플랫폼/서비스를 개선한 국내 사례들을 살펴보며 AWS 서비스들을 어떻게 활용할 수 있는지 보여드립니다.
배민찬(https://www.baeminchan.com) 서비스의 백엔드 시스템 중 일부가 지난 1년간 어떤 고민과 아이디어, 결과물을 만들어냈는지 공유하려고 합니다. 발표 중 언급되는 용어나 도구에 대해 일반적인 정의나 간단한 설명은 언급되나 자세히 다루지 않습니다. 사용된 도구들로 어떻게 이벤트 기반 분산 시스템을 만들었는지에 대한 이야기가 중심입니다.
클라우드 여정의 시작 - 클라우드 전문가 조직의 프랙티컬 가이드-김학민, AWS SA Manager::AWS 마이그레이션 A to Z 웨비나Amazon Web Services Korea
마이그레이션 도중 고객 IT팀은 On-premise 운영 모델에서 클라우드 운영 모델로 전환되어야 합니다. 전환 도중에 ITIL을 클라우드, 애자일, DevOps 기반 역량과 프로세스에 매핑해야 합니다. 해당 세션에서는 클라우드 운영 모델로 원활한 전환을 도와주는 CEE (Cloud Enablement Engine)의 작동 원리 및 적용 방식을 살펴보고자 합니다.
초고속 웹사이트 개발을 위한 Codeigniter PHP FrameworkInseok Lee
지난 10월에 연구실에서 진행했던 세미나 자료입니다.
웹개발에 대한 기본적인 개념이나 프레임웤에 대한 내용을 전혀 모르는 학부 학생들과 연세가 있으신 박사과정 학생들을 위해 제작되었습니다.
Codeigniter의 내용보다도 왜 Codeigniter를 쓰면 좋은지, 그리고 웹 개발 방법은 어떻게 바뀌어 왔는지 등을 이곳저곳의 슬라이드(Codeigniter 한국사용자 포럼의 웅파님, 다음커뮤니케이션의 윤석찬님)를 정리하였습니다.
초보자를 대상으로 하는 강의에서 참고하면 좋을 것 같아용~
관련 문의는 Codeigniter 한국사용자 포럼 codeigniter-kr.org 에서 해주세요~
(GameTech2015) Live Operation by Adbrix의 Node.js와 MongoDB를 이용한 멀티테넌트 인프라 구축사례Jeongsang Baek
대부분의 중소 모바일 게임 업체는 앱을 잘 만들기에도 시간이 모자라 출시일을 잘 맞추기 급급한 상황이다. 그러다 보니 운영을 위한 툴은 소홀히 개발하는 경우가 대부분이고 운영 캠페인은 날림으로 개발하거나 그때 그때 개발자가 필요한 부분만 개발하기 일쑤다. 그러다보니 마케터는 결국 늘 개발자 눈치만 살피게 된다. 필자는 블루윈드에서 이러한 문제를 절감했고 '모바일 게임 개발사가 앱 개발에만 집중할 수 있게 해주고 싶다'는 IGAworks의 철학에 공감하여 라이브 오퍼레이션 프로젝트를 시작하게 되었다.
라이브 오퍼레이션의 개발 중점과제는 5가지였다. 첫번째, 다수의 개발사가 하나의 큰 클라우드 시스템을 사용하도록 multi-tenant 인프라를 구축해야 한다. 두번째, TCO(Total cost of ownership)를 최소화해야 한다. 세번째, 앱의 핵심유저를 실시간으로 그룹화하여 타게팅 캠페인을 할 수 있어야 한다. 네번째, 캠페인의 성과를 마케터에게 실시간으로 피드백해야 한다. 다섯째, 3개월 안에 정식 서비스가 되어야 한다는 점이었다. (왜 우리에게 주어지는 시간은 늘 3개월인가) 그리고 당연하지만 이 서비스를 혼자 개발해야 했다.
이 다섯가지 이슈를 해결하기 위하여 AWS 클라우드 상에 생산성과 성능이 검증된 node.js 와 mongodb를 이용하여 서비스 백엔드를 구성하였고, multi-tenant를 구성하기 위한 여러가지 고민과 그 해결책을 직접 구현하였다. 필자는 node.js와 mongodb를 사용해 본 경험이 충분하다 생각했지만 대규모 정식 서비스를 진행하며 많은 함정에 빠졌고 결국 해결했다.
이 발표를 통해 청강자는 node.js와 mongodb를 이용하여 multi-tenant 인프라를 구축해야 할 때 고려해야 할 설계 방식과 기술적인 고민, 그것에 대한 현실적인 해법을 얻을 수 있다.
designing, implementing and delivering microservices with event storming, spr...uEngine Solutions
Implementing Microservices is something like an adventure. Analyzing and decomposing microservices with applying DDD and make them into code, all is not easy. With new simple approach - Event storming, designing and implementing an event-driven MSA became easier ever seen before.
어느 해커쏜에 참여한 백엔드 개발자들을 위한 교육자료
쉽게 만든다고 했는데도, 많이 어려웠나봅니다.
제 욕심이 과했던 것 같아요. 담번엔 좀 더 쉽게 !
- 독자 : 백엔드 개발자를 희망하는 사람 (취준생, 이직 희망자), 5년차 이하
- 주요 내용 : 백엔드 개발을 할 때 일어나는 일들(개발팀의 일)
- 비상업적 목적으로 인용은 가능합니다. (출처 명기 필수)
사례들로 알아보는 컨테이너, 언제 어떻게 쓰면 좋을까? – 김성수 AWS 솔루션즈 아키텍트, 허준 AWS 어카운트 매니저, 이창명 선데이토...Amazon Web Services Korea
컨테이너를 활용할 수 있는 Workload는 정해져 있는 걸까? 이제는 주변에서 쉽게 보고 들을 수 있는 컨테이너, 하지만 정작 내가 쓰려면 어떻게 써야 할지 감을 잡기 어려운 것도 사실이죠. 유명 게임, 웹 서비스에서 컨테이너를 어떻게, 왜 쓰게 되었는지를 알아봅니다. 그리고 컨테이너에 올리는 작업의 특성을 파악하면 활용할수 있는 팁들까지, 실사례를 통해서 알아봅니다!
Domain Driven Design 기반의 마이크로서비스 디자인 방법론에 대해 설명을 하고 피보탈이 권장하는 모노리스 애플리케이션의 마이크로서비스 전환 방법론에 대해 살펴봅니다. 또한 실제 마이크로서비스 프로젝트에서 발생할 수 있는 우려사항들에 대해서도 국내 프로젝트 경험을 바탕으로 짚어봅니다.
이준영 (현 소프트웨어인라이프 연구원)
OpenShfit와 CSB.IO
인프라 비용을 절감하고 애플리케이션 개발속도를 향상 시킬 수 있는 방안으로 PaaS와 레드햇의 오픈 소스 솔루션인 OpenShift에 대하여 설명한다.
그리고, CSB.IO와 OpenShift의 미래 모습에 대해서도 소개한다.
- The Cloud Life Seminar 2014 발표 내용
Kubernetes advanced sheduling
- Taint and tolerant
- Affinity (Node & inter pod)
Learn how to place Pod like (same or different) node, rack, zone, region
3. 시작하기에 앞서서
• 아쉽게도 “마이크로서비스 아키텍쳐”를 권장하지는 않겠습니다.
• 실력이 전체적으로 좋은 팀만이 운영이 가능
• 좋은 커뮤니케이션이 전제되어야 함
• 서비스 개발에 유용 (SI 나 프로젝트식의 만들고 빠지는 식에는 안좋음)
• 장애 처리 , 테스트 어려움
5. 전통적인 아키텍쳐 스타일
• 모노리틱 아키텍쳐 (통서버)
• 하나의 서버에 모든 비지니스 로직이 들어가 있는 형태
• 하나의 중앙 집중화된 데이타 베이스에 모든 데이타가 저장됨
6. 전통적인 아키텍쳐 스타일의 장단점
• 단점
• 여러개의 기술을 혼용해서 사용하기 어려움 (node.js , Ruby, Python etc)
• 배포 및 재기동 시간이 오래 걸림
• 수정이 용이하지 않음 (타 컴포넌트 의존성)
• 장점
• 기술 단일화
• 관리 용이성
7. 마이크로서비스 아키텍쳐란?
• 시스템을 여러개의 독립된 서비스로 나눠서, 이 서비스를 조합함으로서 기능을 제공하는 아키텍쳐 디자인 패
턴
• SOA의 경량화 버전 (실패한다면 실패하는 이유도 같음)
서비스란?
– 단일된 기능 묶음으로 개발된 서비스 컴포넌트
– REST API등을 통하여 기능을 제공
– 데이타를 공유하지 않고 독립적으로 가공 저장
사용자 관리 인터페이스
• REST
• Thrift,Protocol buffer
• AMQP
• :사용자 데이타
8. 서비스 조합
• 하나의 기능을 구현 하는데, 여러개의 서비스를 조합하여 기능을 제공
예) 주문 하기 : 사용자 정보 조회, 상품 정보 조회, 신규 주문 생성
사용자 관리
상품 관리
주문 관리
쇼핑몰 웹
API CALL
사용자정보
상품정보
주문정보 사용자 관리 상품 관리 주문 관리
사용자 정보 상품 정보 주문 정보
쇼핑몰 웹
API CALL
모노리틱
아키텍쳐
마이크로 서비스
아키텍쳐
9. 기술 스택
• 마이크로 서비스 아키텍쳐는 서비스 별로 다른 기술 스택을 사용할 수 있음
사용자 관리
(JAVA)
상품 관리
(node.js)
주문 관리
(JAVA)
사용자 정보
(Cassandra)
상품 정보
(MySQL)
주문 정보
(CouchBase)
쇼핑몰 웹
API CALL
장점일까?
• 운영 관점에서 여러가지 기술을 동
시에 다뤄야 함
(Devops – You build, You run)
• 사람이 떠나면 보수 불가
(Product not a project)
단점일까?
• 적절한 기술을 적절하게 배치 가능
o 복잡한 데이타 RDBMS, 양이
많은 고속 데이타 NoSQL
o C10K NoSQL, 빠른 개발 스크
립트 언어, 튼튼한 시스템은 자
바 …
10. 팀 모델
• 컨웨이의 법칙
• 뼈저리게 느낌
“소프트웨어의 구조는 그 소프트웨어를 만드는 팀
의 구조와 일치한다.”
설계 백날 잘해야 소용없음
제대로 된 팀 구조를 만드는 것이 설계 (그 다음은 알아서 됨 ?)
• 친한팀 컴포넌트끼리는 개발이 잘됨. 그러다 보니 그쪽으로 기능이 몰림
• 잘하는 팀한테 자꾸 중요 기능이 몰림
서비스 컴포넌트들이 균등하게 디자인 되지 않음
11. 팀모델
• 분산형 거버넌스 (각 팀이 알아서. 적합한 기술, 스스로 하기)
• You build & You run!!
• Self Organized Team
• Product vs Project
• Cross functional team
• Alignment (소통!!)
12. 팀 모델
• 팀간 조율이 핵심
• 새로운 조율자 ROLE이 요구됨
프로그램 메니져 : 팀간 일정 조율
치프 아키텍트 : 서비스간 흐름 정의, 표준 정의, 에러 추적/처리 방법 정의
14. 마이크로 서비스 아키텍쳐 토폴로지
• 일반적인 마이크로 서비스 아키텍쳐 스택 구조
API gateway
Service orchestration
(mediation, aggregation)
CommonAPIs
CommonAPIs
CommonAPIs
CommonAPIs
CommonAPIs
CommonAPIs
생략 가능 영역
• API 게이트 웨이 : API의 single end point
• Common APIs : 범용 API
• Orchestration : 여러 API를 묶어서, 요구 사항에 맞
는 로직을 구현
• Service Orchestration
규모가 커질 수 록 추가되는 계층들 (오케스트레이션, API 게이트 웨이)
1단계
2단계
3단계
15. 쇼핑몰 API
서버
서비스 오케스트레이션 계층의 활용
사용자 관리 상품 관리 주문 관리
사용자 정보 상품 정보 주문 정보
앱 또는 자바스크
립트 클라이언트
API CALL
사용자 관리 상품 관리 주문 관리
사용자 정보 상품 정보 주문 정보
API CALL
클라이언트
API CALL
클라이언트에서 직접 서비
스를 조합 하는 방식
별도의 조합 계층(Orchestration or Mediation)
을 넣는 방식
다른 프로토콜 사용 가능
ex)내부 PB, 외부 REST
• API가 범용적으로 잘 짜야 있어야함
• 클라이언트 팀이 모든 컴포넌트팀과
조율이 필요
규모가 크지 않은 구조에서 효과적
• 중간에 API를 커스터마이제이션 또는 조합
하는 계층을 별도로 둠
• 클라이언트팀은 조합 API 개발팀과 커뮤니
케이션만 하면 됨
• 클라이언트 요구 사항에 기민하게 대처
• 그러나 계층은 하나 더 늘어남 (성능,디버
깅,배포)
일정 규모 이상. 특히 클라이언트
가 여러개인 구조에 효과적
16. API 게이트 웨이
• 클라이언트와 API 서버 앞에서 일종
의 프록시 처럼 위치 하여 다양한 기
능을 수행함
• API 인증/인가
• 로깅
• 라우팅
• 메시지 변환
• 메시지 프로토콜 변환
:
API 서버 API 서버 API 서버
데이타 데이타 데이타
API 게이트 웨이
17. API 게이트 웨이
• SOA ESB (Enterprise Service Bus)의 단순화 버전
• 있으면 좋음. 없어도 됨
• 만들 수 있는 실력있으면, 쓰는게 좋음
• 잘못 쓰면 망하는 지름길
18. API 게이트웨이를 이용한 설계 패턴 #1
• 인증,인가의 단일화
IDM
(계정관리)
API 토큰
관리
클라이언트
API
게이트 웨이
API
서버
1. API 토큰 발급 요청
2. 사용자 인증/인가
3. API 호출
5. API 호출
4. API 토큰 인증
19. API 게이트웨이를 이용한 설계 패턴 #2
• 멀티 앤드포인트와 멀티 프로토콜 제공
<그림. 다양한 디바이스로 부터 정보를 수집하는 IOT시스템에 타입별 앤
드 포인트 제공하는 예제>
20. • MEP (Message Exchange Pattern) 변화
API 게이트웨이를 이용한 설계 패턴 #2
21. API 게이트웨이를 이용한 설계 패턴 #3
• 오케스트레이션
• ESB 기반 SOA 프로젝트가 실패한 대부
분의 원인 (안하는게 좋음)
• 오케스트레이션 서버를 별도로 두는게
좋음
22. API 게이트웨이를 이용한 설계 패턴 #4
• 메세지 기반 라우팅
• 글로벌 배포 시스템에 유용함
• 멀티 버전 시스템 (레거시 업그레이드)에 유용
23. API 게이트웨이를 이용한 설계 패턴 #5
• Cross Cutting Concern (공통 기능) 처리
• 인증,로깅등 공통 기능 처리
• API 개발팀은 비지니스 로직에 집중할 수 있도록 해줌
24. API 게이트웨이를 이용한 설계 패턴 #6
• 다중 API 게이트 웨이 패턴
• 내부,외부용 API 게이트웨이 분리
25. API 게이트웨이를 이용한 설계 패턴 #7
• API 호출용 엔드포인트와 스트리밍 (파일)용 엔드포인트 분리
26. API 게이트웨이를 이용한 설계 패턴 #6
• 비 기능 요소 제어
• QoS 제어
• Metering & Charging (상용 API 서비스 과금)
• API 모니터링
27. 분산 트렌젝션의 추적
• 여러개의 서비스 컴포넌트를 조합하여 움직이는 트
렌젝션에 대한 추적 디자인 패턴
• 원리 (XA 분산 트렌젝션과 유사)
• 초기 API에서 GTXID와 LTXID를 생성
• 서버를 넘어갈때 마다 같은 GTXID를 사용, LTXID는 하
나씩 증가
• 구현시
• 서버간에는 HTTP 헤더로 TXID 전달
• 서버내에서는 Thread Local (Java)등의 컨택스트 변수
활용
초기 표준 설계가 중요함
28. Beyond API 게이트 웨이
• API 플랫폼
• API 게이트 웨이
• API 포탈 (웹)
• API 스펙 문서
• 샌드 박스 제공
• 제품군
• 설치형
• WSO2 (오픈소스)
• CA Layer 7 (상용)
• Tyk.io (오픈소스)
• IBM Strong Loop (오픈소스)
• 클라우드형
• AWS API GW
• apigee
30. 마이크로 서비스 아키텍쳐 문제점
• 장애 진단
• 테스팅
• 표준 관리
• 팀의 역량에 따른 일정 및 품질 문제
• 트렌젝션 관리
• 서비스간 코디네이션 (Chief Architect, Program manager의 역할)
• 서비스간 일정 관리
31. 마이크로서비스 아키텍쳐와 같이 가는 개념들
• Self Organized Team
• Agile based interaction model
• Devops (Development & Operation)
• CD (Continuous Delivery)
• Product not a project
32. 마이크로서비스 아키텍쳐
• 전체적인 기술 역량이 뛰어날 것
• Project 보다는 Product 기반의 서비스 조직에 유리
• 일정 규모 이상의 팀이 되어야 유리함
• 팀간 커뮤니케이션과 조직 구조 (Self organized team) 세팅이 전제
• API 게이트 웨이는 양날의 검
• 왠만하면 하지 마시고… 모노리틱과 MSA 중간 정도에서 타협을
• 통제된 기술.
• 너무 잘게 나누지 말고. 업무 단위 정도로 인터페이스 정해가면서.