<1탄>왜 마이크로 서비스인가 - 마이크로서비스로 구성된 애플리케이션 소개
Session abstract:
이번 세션에서는 무엇이 마이크로 서비스고, 어떤 철학과 사상을 가지고 있는지 알아봅니다. 세션이 종료되면 참석하신 분들은 마이크로 서비스의 구성에서 어떤 내용이 중요한지 알게 됩니다. 전체 시리즈로 진행되는 첫 세션 입니다.
Session agenda:
-실 서비스용 데이터베이스를 종료한다면 어떤 일이 벌어질까
-마이크로서비스와 마이크로서비스가 아닌것
-어떻게 시작해야 하나
-마이크로서비스 애플리케이션 소개
-클라우드 네이티브(클라우드 최적화란)
Pivotal은 개발자 생산성을 높이고 운영비용을 줄이면서 성공적인 비지니스를 할 수 있도록 개발 환경의 혁신 문화와 플랫폼을 제공하고 있습니다.
본 세션에서는 플랫폼의 구조와 효과에 대해 소개하며 기업이 진정한 기술선도 업체로 발전해 갈 수 있도록 혁신적은 플랫폼 *PAS, *PKS를 소개합니다.
*PAS: Pivotal Application Service로 개발자에게 기능 구현 속도를 높이고, 운영 팀은 세계 최고 수준의 가용성을 제공해주는 서비스입니다.
*PKS: Pivotal Container Service로 Kubernates의 배포, 관리, 모니터링, 업데이트 등을 자동화하고 Pivotal에서 관리해주는 서비스입니다
클라우드 네이티브 IT를 위한 4가지 요소와 상관관계 - DevOps, CI/CD, Container, 그리고 MSAVMware Tanzu Korea
최근 IT 시장은 ‘클라우드 네이티브’ 라는 컨셉을 적극적으로 받아들이면서 혁신의 속도를 높이기 위해 여러가지 노력을 기울이고 있습니다. 본 세션에서는 ‘클라우드 네이티브’ 를 이루는 4가지 요소인 DevOps, CICD, Container, MSA 를 간략하게 살펴보고 MSA 가 나머지 클라우드 네이티브 3 요소와 어떻게 상호작용하여 고객 여러분의 비즈니스에 도움이 되는지 알아봅니다. 그리고 MSA 로 이행하기 위한 조직면에서의 요건과 기술 면에서의 요건을 살펴봅니다.
Domain Driven Design 기반의 마이크로서비스 디자인 방법론에 대해 설명을 하고 피보탈이 권장하는 모노리스 애플리케이션의 마이크로서비스 전환 방법론에 대해 살펴봅니다. 또한 실제 마이크로서비스 프로젝트에서 발생할 수 있는 우려사항들에 대해서도 국내 프로젝트 경험을 바탕으로 짚어봅니다.
이번 밋업에서는 다양한 프로젝트에서 도메인에 따라 데이터를 분리한 경험이 있는 엔지니어들이 직접 마이크로서비스에 대해 이야기 합니다. 특히 피보탈의 APAC에서 Application Transformation 을 주도하는 팀의 Sumant Singh Rana와, Satya Ranjan 두 수석 엔지니어들, 그리고 이들과 현재 한국에서 함께 프로젝트를 진행하고 계신 피보탈 한국 김영태 상무님이 함께 하십니다.
마이크로서비스에서 도메인 모델에 따른 데이터의 분리와 적절한 데이터 저장소의 선택은 가장 먼저 고려되어야 할 사항입니다. 피보탈은 다양한 엔터프라이즈 고객과의 프로젝트 수행을 통해 체계화된 서비스를 보유하고 있으며, 본 밋업에서는 그 경험과 과정을 공유하는 시간이 될 것입니다.
Pivotal Concourse를 활용한 CI/CD pipeline automated build-up & Workflow managemen...VMware Tanzu Korea
현업의 업무요청에서부터, 개발/검증/배포에 관련한 일련의 업무 과정을 하나의 Ticket으로 관리하여, 개발 생애주기 전체를 관리하는 방법에 대해 설명합니다. Concourse CI를 기반으로, 미리 만들어진 CI/CD pipeline Template을 통해 현업의 업무 요청을 Ticket 단위로 처리하여, Ticket 별로 개발 업무 과정을 자동화 할 수 있도록 구성한 사례를 공유합니다. Pivotal PAS를 통해, 개발 산출물에 대한 Build 및 Delivery가 Dev.Test/ Staging Test/ Production Deply 순서로 진행되어, 단계별 승인권자에 의해 별도의 결재 처리 없이 배포가 진행 될 수 있도록 간편화하였습니다. 형상관리에 대한 Version 전략 및 Branch 전략을 포함하고 있어서, 개발 설계 단계에서부터 쉽게 이해하고 사용 할 수 있도록 구성하였습니다.
Pivotal 에서는 GE, AllState, VolksWagen 등 세계 유수의 기업들과 긴밀한 협업 관계를 이루고 있습니다. 본 세션에서는 클라우드 네이티브 및 Digital Transformation 을 위한 조직 구조, 문화, 환경을 알아보고 Pivotal 에서 어떻게 도움을 드릴 수 있는지 알아봅니다.
Pivotal은 개발자 생산성을 높이고 운영비용을 줄이면서 성공적인 비지니스를 할 수 있도록 개발 환경의 혁신 문화와 플랫폼을 제공하고 있습니다.
본 세션에서는 플랫폼의 구조와 효과에 대해 소개하며 기업이 진정한 기술선도 업체로 발전해 갈 수 있도록 혁신적은 플랫폼 *PAS, *PKS를 소개합니다.
*PAS: Pivotal Application Service로 개발자에게 기능 구현 속도를 높이고, 운영 팀은 세계 최고 수준의 가용성을 제공해주는 서비스입니다.
*PKS: Pivotal Container Service로 Kubernates의 배포, 관리, 모니터링, 업데이트 등을 자동화하고 Pivotal에서 관리해주는 서비스입니다
클라우드 네이티브 IT를 위한 4가지 요소와 상관관계 - DevOps, CI/CD, Container, 그리고 MSAVMware Tanzu Korea
최근 IT 시장은 ‘클라우드 네이티브’ 라는 컨셉을 적극적으로 받아들이면서 혁신의 속도를 높이기 위해 여러가지 노력을 기울이고 있습니다. 본 세션에서는 ‘클라우드 네이티브’ 를 이루는 4가지 요소인 DevOps, CICD, Container, MSA 를 간략하게 살펴보고 MSA 가 나머지 클라우드 네이티브 3 요소와 어떻게 상호작용하여 고객 여러분의 비즈니스에 도움이 되는지 알아봅니다. 그리고 MSA 로 이행하기 위한 조직면에서의 요건과 기술 면에서의 요건을 살펴봅니다.
Domain Driven Design 기반의 마이크로서비스 디자인 방법론에 대해 설명을 하고 피보탈이 권장하는 모노리스 애플리케이션의 마이크로서비스 전환 방법론에 대해 살펴봅니다. 또한 실제 마이크로서비스 프로젝트에서 발생할 수 있는 우려사항들에 대해서도 국내 프로젝트 경험을 바탕으로 짚어봅니다.
이번 밋업에서는 다양한 프로젝트에서 도메인에 따라 데이터를 분리한 경험이 있는 엔지니어들이 직접 마이크로서비스에 대해 이야기 합니다. 특히 피보탈의 APAC에서 Application Transformation 을 주도하는 팀의 Sumant Singh Rana와, Satya Ranjan 두 수석 엔지니어들, 그리고 이들과 현재 한국에서 함께 프로젝트를 진행하고 계신 피보탈 한국 김영태 상무님이 함께 하십니다.
마이크로서비스에서 도메인 모델에 따른 데이터의 분리와 적절한 데이터 저장소의 선택은 가장 먼저 고려되어야 할 사항입니다. 피보탈은 다양한 엔터프라이즈 고객과의 프로젝트 수행을 통해 체계화된 서비스를 보유하고 있으며, 본 밋업에서는 그 경험과 과정을 공유하는 시간이 될 것입니다.
Pivotal Concourse를 활용한 CI/CD pipeline automated build-up & Workflow managemen...VMware Tanzu Korea
현업의 업무요청에서부터, 개발/검증/배포에 관련한 일련의 업무 과정을 하나의 Ticket으로 관리하여, 개발 생애주기 전체를 관리하는 방법에 대해 설명합니다. Concourse CI를 기반으로, 미리 만들어진 CI/CD pipeline Template을 통해 현업의 업무 요청을 Ticket 단위로 처리하여, Ticket 별로 개발 업무 과정을 자동화 할 수 있도록 구성한 사례를 공유합니다. Pivotal PAS를 통해, 개발 산출물에 대한 Build 및 Delivery가 Dev.Test/ Staging Test/ Production Deply 순서로 진행되어, 단계별 승인권자에 의해 별도의 결재 처리 없이 배포가 진행 될 수 있도록 간편화하였습니다. 형상관리에 대한 Version 전략 및 Branch 전략을 포함하고 있어서, 개발 설계 단계에서부터 쉽게 이해하고 사용 할 수 있도록 구성하였습니다.
Pivotal 에서는 GE, AllState, VolksWagen 등 세계 유수의 기업들과 긴밀한 협업 관계를 이루고 있습니다. 본 세션에서는 클라우드 네이티브 및 Digital Transformation 을 위한 조직 구조, 문화, 환경을 알아보고 Pivotal 에서 어떻게 도움을 드릴 수 있는지 알아봅니다.
<3탄>스프링 부트를 사용한 마이크로 서비스 개발 (로컬 환경) | 페어 프로그래밍 데모 (테스트 작성)
이번 세션에서는 Spring Boot를 사용한 웹 애플리케이션 개발에 대해 소개합니다. 이때 제작되는 애플리케이션은 Pivotal에서 풀타임으로 사용하고 있는 페어프로그래밍을 통해 테스트부터 작성하는 핑퐁 페어등을 소개합니다. 두명이 함께 코드를 작성하는 환경을 통해 빠른 사업환경의 변화를 수용할 수 있는 개발 업무가 Pivotal에서는 어떻게 다른지 살펴봅니다.
Pivotal Cloud Foundry(PCF) 2.0 and Pivotal Container Service ( PKS ) 신혜원VMware Tanzu Korea
클라우드 기반 어플리케이션을 위한 엔터프라이즈 플랫폼인 Pivotal Cloud Foundry 2.0이 새롭게 릴리즈 되면서 기존 버전과 달라진 주요 기능을 살펴보고, Pivotal Container Service (PKS)를 이용해서 개발자가 일관되고 예측 가능한 방법으로 코드를 신속하게 빌드하고 배포하는 방법에 대해 알아봅니다.
넷플릭스에서는 높은 속도로 데이터를 제공하기 위해서 뿐만 아니라 멀티 리전의 데이터 가용성을 바탕으로한 전체 서비스 가용성 유지를 위해 캐시를 사용하고 있습니다. 이 앞의 세션에서 보았던 마이크로서비스 구조를 염두해 둘때 한가지 가장 간단한 변화는 외부 클라이언트로 부터 유입되는 단 하나의 요청에 대한 응답을 만들기 위해 다수의 내부 서비스들로 부터 데이터를 확보해야 하며, 이는 다수 서비스들에 대한 요청과 응답으로 이루어지게 됩니다. 내부 네트워크 성능, 데이터 저장소의 응답속도등의 복합적인 영향으로 인해 마이크로 서비스는 쉽게 느려질 수 있으며, 이는 보통 '팬아웃 효과'로 알려져 있습니다. 뿐만 아니라 다수 서비스간의 데이터 정합성 유지, 필요에 따라 각 서비스간 데이터의 다운타임 없는 이동, 증가하는 데이터량에 동시에 증가하는 데이터 소스의 부하, 그리고 이런 것들을 모두 감안한 데이터 복제 등을 처리해야 할 필요가 있습니다. 본 세션에서는 넷플릭스에서는 이런 문제를 어떤 방식으로 해결하는지, 그리고 스프링 부트, 스프링 클라우드를 비롯한 피보탈의 기술을 사용해서 어떻게 빠르고 쉽게 사용할 수 있는지에 대해 알아봅니다.
[Container 기반의 DevOps] Cloud Native
열린기술공방에서 처음으로 런칭한 교육 프로그램의 트렌드 세션 자료입니다. 급변하는 환경에 맞춘 SW를 개발하고 배포하기 위해, 빠른 의사결정을 할 수 있는 환경과 프로세스가 더욱 중요해지고 있는데요. 기업들에게 왜 클라우드 네이티브 전략이 필수적인지에 대해 소개한 자료입니다.
열린기술공방의 교육 과정을 통해 Kubernetes위에서 동작하는 Application의 빌드부터 배포까지의 과정을 한 눈에 확인하실 수 있습니다.
다들 DevOps 를 적용하고는 있지만 어디까지가 DevOps 인 것인지, 어떻게 얼마나 바꾸고 적용할 것인가 결정하는 것은 쉽지 않습니다.
본 세션은 DevOps 를 왜 적용해야 하는가? 라는 질문을 시작으로 DevOps 를 Culture, Think, Code, Deliver, Run, Manger, Learn 의 7단계로 나누어 차근차근 짚어봅니다.
Meetup tools for-cloud_native_apps_meetup20180510-vsminseok kim
마이크로서비스로 시스템을 구성하면 서비스간에 연관관계가 줄어들면서 서비스 릴리즈 속도가 높아지고 유연하게 대처할 수 있지만, 관리포인트가 늘어나게 되어 운영상에 많은 어려움을 마주치게 됩니다. 배포 될 때마다 생성되고 소멸되는 마이크로서비스를 다른 마이크로서비스가 쉽게 참조하게 하고 마이크로서비스들의 설정 정보를 일관되게 관리하는 일은 쉬운일이 아닙니다. 이러한 문제를 해결하기 위해 Spring Cloud 프로젝트와 같은 도구를 비롯하여 Pivotal Cloud Foundry와 같은 클라우드 플랫폼등이 있습니다. 이번 밋업에서는 마이크로서비스를 운영할 때의 어려운점과 도움을 주는 다양한 도구들에 대해 알아보도록 하겠습니다.
<3탄>스프링 부트를 사용한 마이크로 서비스 개발 (로컬 환경) | 페어 프로그래밍 데모 (테스트 작성)
이번 세션에서는 Spring Boot를 사용한 웹 애플리케이션 개발에 대해 소개합니다. 이때 제작되는 애플리케이션은 Pivotal에서 풀타임으로 사용하고 있는 페어프로그래밍을 통해 테스트부터 작성하는 핑퐁 페어등을 소개합니다. 두명이 함께 코드를 작성하는 환경을 통해 빠른 사업환경의 변화를 수용할 수 있는 개발 업무가 Pivotal에서는 어떻게 다른지 살펴봅니다.
Pivotal Cloud Foundry(PCF) 2.0 and Pivotal Container Service ( PKS ) 신혜원VMware Tanzu Korea
클라우드 기반 어플리케이션을 위한 엔터프라이즈 플랫폼인 Pivotal Cloud Foundry 2.0이 새롭게 릴리즈 되면서 기존 버전과 달라진 주요 기능을 살펴보고, Pivotal Container Service (PKS)를 이용해서 개발자가 일관되고 예측 가능한 방법으로 코드를 신속하게 빌드하고 배포하는 방법에 대해 알아봅니다.
넷플릭스에서는 높은 속도로 데이터를 제공하기 위해서 뿐만 아니라 멀티 리전의 데이터 가용성을 바탕으로한 전체 서비스 가용성 유지를 위해 캐시를 사용하고 있습니다. 이 앞의 세션에서 보았던 마이크로서비스 구조를 염두해 둘때 한가지 가장 간단한 변화는 외부 클라이언트로 부터 유입되는 단 하나의 요청에 대한 응답을 만들기 위해 다수의 내부 서비스들로 부터 데이터를 확보해야 하며, 이는 다수 서비스들에 대한 요청과 응답으로 이루어지게 됩니다. 내부 네트워크 성능, 데이터 저장소의 응답속도등의 복합적인 영향으로 인해 마이크로 서비스는 쉽게 느려질 수 있으며, 이는 보통 '팬아웃 효과'로 알려져 있습니다. 뿐만 아니라 다수 서비스간의 데이터 정합성 유지, 필요에 따라 각 서비스간 데이터의 다운타임 없는 이동, 증가하는 데이터량에 동시에 증가하는 데이터 소스의 부하, 그리고 이런 것들을 모두 감안한 데이터 복제 등을 처리해야 할 필요가 있습니다. 본 세션에서는 넷플릭스에서는 이런 문제를 어떤 방식으로 해결하는지, 그리고 스프링 부트, 스프링 클라우드를 비롯한 피보탈의 기술을 사용해서 어떻게 빠르고 쉽게 사용할 수 있는지에 대해 알아봅니다.
[Container 기반의 DevOps] Cloud Native
열린기술공방에서 처음으로 런칭한 교육 프로그램의 트렌드 세션 자료입니다. 급변하는 환경에 맞춘 SW를 개발하고 배포하기 위해, 빠른 의사결정을 할 수 있는 환경과 프로세스가 더욱 중요해지고 있는데요. 기업들에게 왜 클라우드 네이티브 전략이 필수적인지에 대해 소개한 자료입니다.
열린기술공방의 교육 과정을 통해 Kubernetes위에서 동작하는 Application의 빌드부터 배포까지의 과정을 한 눈에 확인하실 수 있습니다.
다들 DevOps 를 적용하고는 있지만 어디까지가 DevOps 인 것인지, 어떻게 얼마나 바꾸고 적용할 것인가 결정하는 것은 쉽지 않습니다.
본 세션은 DevOps 를 왜 적용해야 하는가? 라는 질문을 시작으로 DevOps 를 Culture, Think, Code, Deliver, Run, Manger, Learn 의 7단계로 나누어 차근차근 짚어봅니다.
Meetup tools for-cloud_native_apps_meetup20180510-vsminseok kim
마이크로서비스로 시스템을 구성하면 서비스간에 연관관계가 줄어들면서 서비스 릴리즈 속도가 높아지고 유연하게 대처할 수 있지만, 관리포인트가 늘어나게 되어 운영상에 많은 어려움을 마주치게 됩니다. 배포 될 때마다 생성되고 소멸되는 마이크로서비스를 다른 마이크로서비스가 쉽게 참조하게 하고 마이크로서비스들의 설정 정보를 일관되게 관리하는 일은 쉬운일이 아닙니다. 이러한 문제를 해결하기 위해 Spring Cloud 프로젝트와 같은 도구를 비롯하여 Pivotal Cloud Foundry와 같은 클라우드 플랫폼등이 있습니다. 이번 밋업에서는 마이크로서비스를 운영할 때의 어려운점과 도움을 주는 다양한 도구들에 대해 알아보도록 하겠습니다.
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.
All about Data Center Migration Session 1. <Case Study> 오비맥주 사례로 알아보는 DC 마이그레...BESPIN GLOBAL
기존 레거시(Legacy) 시스템이 가지고 있는 변화하는 기술에 대한 빠른 대응과 비즈니스 어플리케이션 배포의 한계 등을 극복하기 위한 대안인 클라우드 도입.
클라우드 국내 도입 현황과 클라우드로 마이그레이션을 해야 하는 이유를 실제 사례를 통해 알려드립니다.
클라우드를 통해 비즈니스 혁신을 가속화하고 쉽고 정학하게 구현하실 수 있습니다.
[목차]
1. 클라우드 국내 도입 현황과 클라우드로 마이그레이션을 해야 하는 이유
2. 클라우드 마이그레이션의 기본 프로세스, 전략, 비용 절감 효과, 로드맵
3. 베스핀글로벌 구축 사례 : 오비맥주의 마이그레이션 사례 공유
source : http://www.opennaru.com/cloud/msa/
마이크로서비스는 애플리케이션 구축을 위한 아키텍처 기반의 접근 방식입니다. 마이크로서비스를 전통적인 모놀리식(monolithic) 접근 방식과 구별 짓는 기준은 애플리케이션을 핵심 기능으로 세분화하는 방식입니다. 각 기능을 서비스라고 부르며, 독립적으로 구축하고 배포할 수 있습니다. 이는 개별 서비스가 다른 서비스에 부정적 영향을 주지 않으면서 작동(또는 장애가 발생)할 수 있음을 의미합니다.
안녕하세요. 이희종입니다. 한국 오라클에서 근무 하고 있습니다.
저희 팀에서는 지식 먹방이라는 방송을 Youtube 채널을 통해서 하고 있구요. 이번에 마이크로서비스라는 주제를 가지고 한번 다루어 보는 시간을 가져 보았습니다. 아직 마이크로서비스라는 단어에 대해서 생소하신 분이라면 개념을 이해하기에 좋은 자료라고 생각됩니다.
방송영상은 https://www.youtube.com/watch?v=64t4Kck6JEQ 보실 수 있습니다.
이와 더불어 오라클 클라우드 서비스 중에 하나인 Application Container Cloud Service 에 대한 내용도 포함되어 있습니다.
최근 들어 MSA(Micro Service Architecture)에 대한 관심이 높아지고 Amazon과 넷플릭스, 11번가 등에서 MSA를 이용하여 성과를 보이자 많은 곳에서 MSA를 이용한 프로젝트가 많아 지고 있습니다.
MSA에 대한 내용은 방대하지만, 간단한 개요만 이라도 정리하여 올립니다.
Cloud-Native Architecture
MSA(Micro Service Architecture)
MDA(Micro Data Architecture)
MIA(MIcro Inference Architecture)
MSA-Service Mesh
MDA-Data Mesh
MIA-AI Inference Mesh
Kubernetes
Container
Kubeflow
Volcano
Apache Ynikorn
ChatGPT
AGI(Artificial General Intelligence)
ASI(Artificial Specialized Intelligence)
초-전환시대
초-연결시대
SQream GPU DBMS
Cloud와 Cloud Native의 목표는.. 왜? 어떻게? 뭐가 좋아지나...
1. (왜) 가속화된 초-전환, 초-연결 IT 환경변화에 대비하기 위해서
2. (어떻게-H/W) IT H/W 부분은 IaaS 서비스화하여
점유된, Over Subscription된 H/W(Server, Network, Storage)들 모아서 Pool화하고, 가상화기술을 통해 Tenant로 자원들을 분리해 서비스화해 제공하고
필요시 적시에 Pool의 가상H/W를 제공하고, 상황에 따라 확장・축소(Scale in/out, up/down)하면서, 축소된 자원을 다른 요청들을 위해 빠르게 재-할당하는 유연성을 제공하고
3. (어떻게-S/W) S/W 부문도
PaaS, SaaS 적극 활용으로 App.개발 시간을 단축하고
App.분야인 기존 MACRO Service Architecture형 Monolith Architecture(Web-WAS-DB)를 작게 쪼개서 변화에 빠르게 적응할 수 있는 MSA(Micro Service Architecture)로 변경하여 Service Mesh형으로 관리하고
Data분야도 Data Warehouse, DataLake(Bigdata), LakeHouse등 기존 MACRO Data Architecture를 MSA형식으로 MDA(Micro Data Architecture)로 전환 후 Data Mesh형태로 관리하고,
AI로 동적프로그램 생성하여 App.개발시간 단축하고, AI분야도 초-거대 AI구현(MACRO)보다는 작은|특화된 Deep Learning Network(Model)들로 작게 쪼개서 MIA(Micro Inference Architecture)로 비지니스 환경에 적용하고 Inference Mesh형태로 관리하는 시스템으로 전환하고
4. (어떻게-조직) 조직구조도 CI/CD형 DevOps환경, 데이타,트랜잭션중심업무중심, 기술중심 문제해결중심, 직능중심조직직무중심조직으로 전환하면
5. (좋아지는 것) 초-전환, 초-연결 환경에 빠르고, 지속적으로 적응할 수 IT as a Product 환경을 구현하는 것
Openshift 활용을 위한 Application의 준비, Cloud Nativerockplace
What is Cloud-native - DevOps, MSA and Cloud-native: Openshift 활용을 위한 Application의 준비, Cloud Native
*웨비나 다시보기 영상 바로가기:
https://www.youtube.com/watch?v=tzSBS-vki6w
Pivotal Dojo 서비스는 조직이 클라우드로 전환하기 위해 플랫폼 팀을 균형있게 구성하고 애자일하게 운영할 수 있는 방법을 체득할 수 있게 도와줍니다. 이번 세션에서는 이 Dojo서비스와 실제 사례에 대해 소개하며 기업이 지속가능한 혁신이 가능케 하는 방법에 대해 알아봅니다.
본 세션에서는 Pivotal이 추구하는 Any App, Every Cloud, One Platform 전략에 대하여 살펴보고, 이러한 전략이 마이크로 서비스와 같은 클라우드 네이티브 IT 환경을 구성하는데 어떻게 도움을 줄 수 있는지 살펴 봅니다. 특히 Kubernetes, Istio, Envoy 등의 다양한 오픈소스를 어떻게 활용하고 플랫폼에 흡수하여 운영할 수 있는지 살펴 봅니다.
굿 소프트웨어 컴퍼니로의 여정(Journey To Be a Good Software Company)VMware Tanzu Korea
본 발표자료는 Pivotal Korea에서 주최한 Cloud Native Day 2019 Seoul 컨퍼런스의 기조연설 발표자료입니다.
발표자: 사친 쉬리다르(Sachin Shridhar), 서비스 및 CSO 부사장, Pivotal America & APJ
발표자 소개: 사친 쉬리다르는 피보탈 아시아태평양&일본(APJ) 및 미국 지역의 커스터머 석세스 조직(CSO) 그룹의 부사장입니다. CSO는 솔루션 아키텍처, 구현, 딜리버리, 컨설팅 및 교육을 포함한 모든 리전의 테크니컬 서비스를 책임지고 있는 그룹입니다. 사친은 고객의 소프트웨어 기반 환경으로의 전환을 돕기 위해, 피보탈 오퍼링을 운영하여 소프트웨어 개발을 기업의 핵심 역량 및 이점으로 만드는 일을 하고 있습니다. 사친은 업계에서 20년 이상, 아시아 태평양 및 일본 전역의 시장에서 10년 이상을 보냈습니다. 그는 테크놀로지 기업의 서비스 및 솔루션에 오래된 경력을 가지고 있으며, 고객과 파트너가 기술 제공을 통해 성공할 수 있도록 지원해 왔습니다. 피보탈 이전에는 5년 넘게 레드햇의 아시아태평양&일본 서비스 담당 부사장으로 근무하면서 프리세일즈, 컨설팅 및 교육 비즈니스를 주도했습니다.
목차:
Why MicroServices
Who has done it
Why Pivotal
SpringFramework 5에서 선보이는 Reactive와 같은 핵심기능이 Spring Data, Spring Security, Spring WebFlux프로젝트에 녹아져 있는지 살펴봅니다. 또한 이러한 기능들이 어떻게 여러분의 시스템의 반응성을 높이고 효율적으로 동작하게 하는지 알아봅니다.
Project Riff는 Kubernetes 기반의 함수형 서비스로 스크립트, Node.js, Spring Cloud Function로 작성된 함수를 이벤트 발생시 실행 할 수 있습니다. Riff 상에 Spring Cloud Function을 사용하여 Serverless Spring을 사용하는 방법에 대해서 살펴봅니다.
이번 Pivotal의 SpringOne에서는 금융, 자동차, 리테일, 통신, 공공 등 다양한 산업에서 약 20여곳의 고객들이 Digital Transformation을 위해 조직/프로세스/기술플랫폼 측면에서 피보탈과 어떻게 일하고 있는지를 발표하였습니다. 본 세션에서는 이러한 사례를 가볍게 살펴보고, 우리에게 어떤 인사이트를 주고 있는지 알아보는 시간을 가질 예정입니다.
7. 피보탈 시리즈 밋업
1화 : 왜 마이크로 서비스인가
2화 : 도메인을 중심으로한 데이터 분리
3화 : 스프링 부트를 사용한 마이크로 서비스, 그리고 페어 프로그래밍
4화 : 스프링 클라우드를 사용한 다수의 마이크로 서비스 연결
5화 : 다수의 마이크로 서비스 팀을 위한 스프링과 데이터 서비스의 배포와 운영
6화 : 멀티 리전, 멀티 클라우드와 하이브리드 모두를 사용가능하게 하는 데이터 복제
7화 : 카오스 엔지니어링 테스트의 적용
8화 : 스프링 클라우드 펑션과 함수형 서비스를 사용한 API 게이트웨이 오프로딩
9화 : 데이터 과학의 서비스 적용
주요 목표: 데이터베이스 서버를 꺼도 지속되는 서비스 만들어 보기
8. Technology Outcomes - Insurance
Technology
Outcomes
Allstate: Developers spending 80% of time
coding vs. 20% (4X improvement)
Liberty Mutual: Delivered a revenue-
generating app MVP in one month
Talanx Group: Significant increase in % Dev
time on coding
[Major P&C Insurer]: Achieved 90x faster
application release cycles
[Regional P&C Insurer]: Moved from 28-
day deployments to 1
[Regional P&C Insurer]: Went from 21 days to apply
security patches to 1 day, which amounted to
>$1.5M in cost savings (human capital); the
frequency of patching also went from 17x per year
to 365.
[Major P&C Insurer]: Significant operational
efficiencies through pipeline automation - 21
concourse pipelines for systems patching &
upgrades
Liberty Mutual: 60% reduction of
infrastructure cost with PCF
[Major P&C Insurer]: 25% reduction
in computing resource usage
[Major P&C Insurer]: 0% downtime in
production; 0 weekend outages for
application releases; achieving
consistent API response times of < 12ms
[Regional P&C Insurer]: MTTR has gone
from 3 days to 1 hour; also went from 4
hours of production downtime per month
to 0
Allstate: Supporting over 1,000 Developers on
PCF and over 11,000 deployments a month on the
platform; also setup CompoZed labs to accelerate
product team scale
Liberty Mutual: 1,000 production deploys per day
across 600 applications
[Regional P&C Insurer]: Time to scale from 90
days to 10 seconds (autoscaling)
● Speed
● Savings
● Stability
● Scalability
● Security
11. 마이크로 서비스란
a definition of this new architectural term
The term "Microservice Architecture" has sprung up over the last few years to describe a
particular way of designing software applications as suites of independently deployable services.
While there is no precise definition of this architectural style, there are certain common
characteristics around organization around business capability, automated deployment,
intelligence in the endpoints, and decentralized control of languages and data.
In short, the microservice architecture style is an approach to developing a single application as a
suite of small services, each running in its own process and communicating with lightweight
mechanisms, often an HTTP resource API.
- James Lewis and Martin Fowler
12. 마이크로 서비스란
이 새로운 아키텍처 용어의 정의는
“마이크로서비스 아키텍처”는 최근 몇년간 독립적 서비스로 배포가 가능하도록
소프트웨어를 디자인하는 방법에 대한 묘사로 사용되고 있다. 이 아키텍처 스타일에 대한
정확한 정의는 존재하지 않지만, 비지니스 능력에 기반한 조직 구성, 자동화된 배포,
엔드포인트 동작에 대한 정보, 그리고 데이터와 언어를 분산 형태로 다루는 등의 매우
명확한 공통적 특징이 있다.
단순히 말하면, 마이크로서비스 아키텍처 스타일은 여러개의 작은 서비스들을 바탕으로
구성된 하나의 애플리케이션이다. 각각의 작은 서비스들은 자신만의 프로세스를 가지고
있으며, HTTP와 같이 가벼운 방식을 사용하여 통신하도록 구성한다.
- 제임스 루이스와 마틴 파울러
13. 마이크로 서비스의 특징
• 분리된 서비스들의 집합 (Componentization via Services)
• 비지니스 능력에 따른 조직 구성 (Organized around Business Capabilities)
• 프로젝트가 아닌 프로덕트 (Products not Projects)
• 똑똑한 엔드포인트와 멍청한 파이프 (Smart endpoints and dumb pipes)
• 분산된 운영 방식 (Decentralized Governance)
• 분산된 데이터 관리 (Decentralized Data Management)
• 인프라스트럭쳐 자동화 (Infrastructure Automation)
• 실패에 대비한 디자인 (Design for failure)
• 점진적 디자인 (Evolutionary Design)
20. 마이크로 서비스의 미래
• 아마존, 넷플릭스, 더 가디언, UK 정부 디지털 서비스, 호주 리얼에스테이트 서비스, 포워드, 그리고
comparethemarket.com 과 같은 사업자들이 이 분야의 개척자
• 모놀리틱 애플리케이션에 비해서 상당한 장점들이 있지만, 마이크로서비스를 명확하게 정의하기에는 아직
충분한 경험이 쌓이지 않은듯 하다. (2013년 기준)
• 대부분의 아키텍처는 구현 시점 이후 몇년이 지나야 선택이 옳았는지 틀렸는지를 알 수있게 된다. 모듈화에 대해
강력한 의지가 있는 실력있는 팀이 몇년 동안이나 걸려서 모놀리틱 아키텍처를 만들기도 한다. 그리고 많은
시스템에서 마이크로서비스를 어떻게 적용해야 하는지 명확한 답을 낼 수 없는 경우도 많다.
• 분리를 해야 하는 경우 그 경계 지점을 정하는 것은 해당 컴포넌트가 비지니스를 얼마나 잘 반영하고 있는가가
기준이 된다. 하지만 이 경계 지점이 어디인지를 확실하게 구분짓는 것은 어려운 일이다. “점진적 디자인”의
의미는 이런 모호한 경계를 지속적으로 리팩토링 해야 한다는 것이며, 이것은 마이크로서비스 적용의 어려움을
나타낸다.
• 분리된 시스템들이 원격으로 통신하는 상황에서의 리팩토링은 단일 프로세스 내에서의 리팩토링보다 훨씬
어려워질 수 있다.
• 팀의 기술 역량 역시 매우 중요하다. 마이크로서비스는 수많은 새로운 기술을 필요로 하며, 이 새로운 기술을
충분히 습득하지 못한 팀이 엉망의 마이크로서비스를 만들고 있는것은 한참 시간이 지나서야 발견되기도 한다.
https://martinfowler.com/articles/microservices.html
30. 모놀리틱 구조의 한계
30
B
A
D C
A
모듈
의존성 관계
Original
change
Overhead
synchronization
work
D모듈의변경A의Heat가
높을때..
D모듈 변경 시 A,B,C의 추가 테스트 필요
D모듈의 작은 변화도 전체 App의 배포를 요구
D모듈만 테스트하고는 릴리즈 할 수 없음
A,B,C,D모듈이 동시에 변경할 경우 엄청난
부가적인 작업이 필요
결론적으로 매우 느린 릴리즈 사이클이 형성
A 모듈이 집중적으로 많이 사용되는 경우에도
어쩔 수 없이 전체 App을 Scale 헤야 함
(메모리, Disk 등의 비효율성)
A 모듈이 문제가 생기면 장애가 나머지 모듈에도
영향을 줄 수 밖에 없음
모놀리틱 구조의 한계
31. D모듈 변경 시 A,B,C의 추가 테스트 필요
D모듈의 작은 변화도 전체 App의 배포를 요구
D모듈만 테스트하고는 릴리즈 할 수 없음
A,B,C,D모듈이 동시에 변경할 경우 엄청난
부가적인 작업이 필요
결론적으로 매우 느린 릴리즈 사이클이 형성
A 모듈이 집중적으로 많이 사용되는 경우에도
어쩔 수 없이 전체 App을 Scale 헤야 함
(메모리, Disk 등의 비효율성)
A 모듈이 문제가 생기면 장애가 나머지 모듈에도
영향을 줄 수 밖에 없음
더 신속한
업데이트
독립적인
확장성
장애의
전파없는
가용성
성능과
유저 경험
여러 팀이 독립적으로 릴리즈
사이클을 결정하여,
요구사항을 더 빠르게 반영
(API 기반의 Contract)
부하가 발생하는 모듈만 독립적으로
Scale-Out/In 할 수 있는 구조
장애를 하나의 모듈에만 고립시켜,
전체적인 서비스에는 영향을 끼치지
않음
(더 빠른 Root Cause 분석)
애플리케이션의 사이즈가 축소됨에
따라 Start 시간과 Scale 시간이 단축
모놀리틱 구조의 한계 MSA 도입 시 개선 사항
34. 성능과
유저경험
Traffic Pattern Compute Resources Response Time
Long
Start-up
Time
t t t
Short
Start-up
Time
t t t
msInstance
count
Traffic
msInstance
count
Traffic
t1
t1
1,000ms
200ms
35. 넷플릭스가 고려했던 포인트…
마이크로 서비스 동작상태에 대한 모니터링 필요
장애 고립을 제어할 수 있는 역량 필요
API 기반 서비스 연동이 필요
클라우드 기반 서비스 생명주기 관리 필요
팬아웃(Fan-Out) 현상에 대한 제어가 필요
다양한 데이터 서비스를 지원하는 도구 제공이 필요
수많은 마이크로 서비스의 설정 관리 필요
서비스 문제 발생시 자동 복구가 필요
서비스에서 발생하는 로그의 취합 저장 분석 필요
장애를 사전에 테스트할 수 있는 환경이 필요
마이크로 서비스에 적합한 조직 구성
마이크로 서비스에 적합한 문화
Configuration Server
Service Discovery
Circuit Breaker
API Gateway
Distributed Tracing
Zero Downtime Delivery
Fault Injection Test
Chaos Engineering
Persistence Cache Layer
Sidecar / Library
자유와 책임 중심의 개발 문화
셀프 서비스로의 패러다임 변화
넷플릭스의 해결책들…
조직적
변화
기술적
변화
36. As you’ve seen from some examples, Netflix micro system looks very complicated,
but since you understand what their platform does, it’s a combination of a Micro service and Platform tools.
37. Netflix, is keep developing various tools to solve “their problems” based on this eco system.
However, it’s not easy to build up this kind of eco system.
39. 넷플릭스가 고려했던 포인트…
마이크로 서비스 동작상태에 대한 모니터링 필요
장애 고립을 제어할 수 있는 역량 필요
API 기반 서비스 연동이 필요
클라우드 기반 서비스 생명주기 관리 필요
팬아웃(Fan-Out) 현상에 대한 제어가 필요
다양한 데이터 서비스를 지원하는 도구 제공이 필요
수많은 마이크로 서비스의 설정 관리 필요
서비스 문제 발생시 자동 복구가 필요
서비스에서 발생하는 로그의 취합 저장 분석 필요
장애를 사전에 테스트할 수 있는 환경이 필요
마이크로 서비스에 적합한 조직 구성
마이크로 서비스에 적합한 문화
넷플릭스의 해결책들..
자유와 책임 중심의 개발 문화
셀프 서비스로의 패러다임 변화조직적
변화
기술적
변화
Configuration Server - 설정
Service Discovery – 서비스 등록/탐색
Circuit Breaker – 장애 고립
API Gateway – API 기반 지원
Distributed Tracing - 모니터링
Zero Downtime Delivery - 배포
Fault Injection – 인위적 장애 주입
Chaos Engineering
Persistence Cache Layer
Sidecar / Library
1
2
3
4
5
6
7
8
40. • Externalized Config Server
• Service Register & Discovery
• Circuit Breaker
• API Gateway
• Load Balancing with IPC
• Realtime Monitoring
• Zero Downtime Delivery
• Fault Injection Test
• Chaos Engineering
• Etc…
https://netflix.github.io/
44. Netflix API Gateway – Zuul
https://medium.com/netflix-techblog/announcing-zuul-edge-service-in-the-cloud-ab3af5be08ee
API Gateway – API 기반 지원4
45. Netflix Load Balancing with IPC – Ribbon
https://medium.com/netflix-techblog/announcing-ribbon-tying-the-netflix-mid-tier-services-together-a89346910a62
API Gateway – API 기반 지원4
50. Netflix Fault Injection Test – FIT
And Automate it
https://medium.com/netflix-techblog/fit-failure-injection-testing-35d8e2a9bb2
Fault Injection – 인위적 장애 주입7
51. Netflix Chaos Engineering – Simain Army
https://medium.com/netflix-techblog/the-netflix-simian-army-16e57fbab116
Chaos Engineering8