소프트웨어 개발 트랜드와마이크로 서비스 아키텍쳐

피키캐스트 CTO조대협

발표자 소개

조 대 협 본명 : 조병욱

회원 13 만명 온라인 개발자 커뮤니티 자바스터디 (www.javastudy.co.kr) 운영자 .. ( 기억의 저편 ..)한국 자바 개발자 협회 부회장 , 서버사이드 아키텍트 그룹 운영자

벤쳐 개발자

BEA 웹로직 기술 지원 엔지니어

장애 진단 , 성능 튜닝

NHN 잠깐

오라클 컨설턴트 (SOA,EAI,ALM,Enterprise 2.0, 대용량 분산 시스템 )MS APAC 클라우드 수석 아키텍트

프리렌서 ( 잘나가는 사장님 )삼성전자 무선 사업부 B2B 팀 Chief Architect

현 피키캐스트 CTO 로 .. 열심히 세상을 즐겁게 만드는 중… .

피키캐스트

회사 개요• 2012 년 12 월 설립• 전체 150 명 • 1000 만 다운로드 , 월 600 만명 방문 , 일 150 만명 방문• 10 대 ~20 대 주요 타켓• 컨텐츠 큐레이션 서비스 • 세상을 즐겁게 만드는 것을 목표로 열심히 일하고 있음…개발실 개요• 18 명 개발자 + 중국 5 명 ( 연말 30 명 목표 )• 인스타그램처럼 작고 빠른 팀을 지향• 목표 3 년내에 모두 페이스북에 취직하자 !!• 괴수 집단 ( 책을 쓰거나 .. 세미나에서 유명하거나… 전문 블러거이거나… 오픈소스 커미터이거나… ) 아니라도 됨… 잘하믄 됨 .. ( 열심히 하는 사람 시러함 ..)

• 개발 트랜드의 변화개발 프로세스• 마이크로 서비스 아키텍쳐 (aka. MSA)

오늘 할 이야기

요즘 실리콘 밸리에서는

잘하는 것 부터 시작해서 발전

대세는 스크립트 언어

스스로 공부 , 스스로 개발 , 내재화소규모 조직 [10~20 명 ]

대우 받는 개발자클라우드 컴퓨팅 빠른 시장 진입 , 저비용 , 누구나 서비스젊은 개발자 ( 한국은 접는 개발자 )

협업 [SNS, 오픈소스 ,GitHub]

CI to CD

유연한 고용 시장메뚜기 !!3 년 넘으면 바보한국은 배신자

개발자의 변신은 무죄새로운 능력 ..!! 잉여력STAR UP

요즘 실리콘 밸리에서는

대세는 수퍼 개발자 !!

3 가지 관점에서 트랜드를 분석

소프트웨어 개발 중심의 변화 시대별 기술의 변화 개발 방식의변화

소프트웨어 개발 중심의 변화

시대별로 소프트웨어를 개발하는 이유가 어떻게 변화 했을까 ?우리가 지금 쓰는 기술들은 왜 ?

소프트웨어 개발 중심의 변화

인터넷 ,SNS 의 시대엔터프라이즈 시대 모바일 시대

서비스 사업자대단한 님들 !!벤더 개발자 !!( 스타트업 , 앱개발자 ) 당신도 할 수 있다

기술 변화의 주체

시대별 기술의 변화

시대별 기술의 변화

인터넷 ,SNS 의 시대엔터프라이즈 시대 모바일 시대EJB, JAVA, SERVLET/

JSP들어는 보셨나요 ?

벤더 : “ 이게 최신 기술임 !!. 교육 부터 다 해드림 !!나만 믿으세요” $$$

먹고 살 걱정 없음 !!

Spring,Hibernate,MySQL,Struts,Ruby On

Rails,PHP ..

서비스사 : 제품은 비싸요 . 우리가 만든거 가져다 쓰세요 !! 대신 책임은 니꺼 !

공부해야 함 .. 압박 !!조금씩 먹고 살기 힘들어짐( 버틸만 함 - 그래도 대세는 있음 )

JavaScript,Cloud,node.js,

Ruby on Rails,NoSQL

개발자 : 어려워서 못 써먹겠음 . 차라리 만듬 ..!!기술 변화도 심함이제는 생존의 문제 !!명퇴가 눈앞에 ..

시대별 기술 변화

인터넷 ,SNS 의 시대엔터프라이즈 시대 모바일 시대

UNIX 서버

벤더 소프트웨어

X86 서버

오픈소스

클라우드

오픈소스

스크립트 언어 !!

ORACLE MySQL NoSQL

API

HTML 5안드로이드 ,IOS웹웹 ,4GL

쉽고 빠른 개발기술의 홍수대체제 성격새로운 기술 흐름을 만드는 전환기

안정성 , 미션 크리티컬 업무 위주

• 왜 이런 현상이 생기는가 ? 쉬운 기술이 주목 받는 이유스타트업 . 앱 개발시대별 기술자

조합 1. 기획자 창업디자이너 - 기획자 여자 친구개발자 – 기획자의 친구 ( 디자이너를 사랑함 )

조합 2. 디자이너 창업기획자 - 디자이너의 여자 친구개발자 – 디자이너의 친구 ( 기획자를 사랑함 )

개발자 1 인 혼자 다 해야함 ( 클라이언트 , 서버 , 하드웨어 인프라 )배우기 쉬워야 함돈 떨어지기전에 시장 출시해야함빨리 배울 수 있어야함

수많은 앱들 / 치열한 경쟁시장 현황

빠른 출시 , 빠른 업데이트가 필요

요구 되는 기술

빠른 출시 , 빠른 업데이트가 필요쉬운 기술 필요

낮은 비용

클라우드 컴퓨팅 스크립트 언어운영 효율화Devops

자동화

• 클라우드 컴퓨팅이 가져다준 변화– 저비용으로 시작 가능– 무제한적 리소스– 지역 / 시간 제약에서 자유로워짐– 쉽다 . 하드웨어 인프라에 대한 작업이 없어짐

개발자가 인프라를 핸들링 가능

클라우드 컴퓨팅

클라우드 컴퓨팅

빠른 시장 진입

운영비 절감

초기 투자비 절감

유연한 자원 사용(Auto Scale Out)

느려요 IO Performance

싸지 않아요

기존 솔루션이 안돌아요

장애가 납니다 . 아주 잘 !!( 멀티 데이타 센타 설계 )

클라우드 컴퓨팅의 장점 설계시 고려 사항

• 고려해야 하는 것들

Devops = Development + Operation ( 개발 + 운영 )

Devops 의 등장

개발과 운영 조직을 하나로 묶어서 원할한 의사 소통빠른 반영 , 빠른 피드백 반영 가능

• 흔한 ( 평범한 ) 개발 환경 시나리오– 개발자가 아침에 출근해서– 이클립스를 키고 , 소스코드를 Git 에서 Check Out 한후– JIRA 를 통해서 오늘 할당된 작업을 확인 한후에 코딩을 하고– PC 에서 Junit 등을 이용하여 단위테스트등을 모두 끝 마치고– 코드를 Git 에 Commit 하면– Jekins 에서 코드 변경을 감지하여 , 자동으로 Check Out 해서 mvn 을 이용해서 컴파일 하고 , 테스트 서버에 배포해서 단위 테스트를 모두 수행하고 , 코드의 라인커버리지를 분석하여 리포팅 한다 .– 팀장은 빌드가 완료되었음을 확인하고 , 단위 테스트 100% 완료 및 라인 커버리지 80% 완료를 확인한다 .– 릴리즈 날짜가 오면 , 배포 엔지니어는 별도의 작업 없이 Jenkins 에서 빌드된 그날 WAR 를 확인하고 , Fabric 으로 된 배포 스크립트를 수행하면 , 자동으로 개발 ,QA 환경으로 배포가 되고 , 환경별로 필요한 resource 파일들이 자동으로 customization 해서 배포가 완료된 후 , Junit 기반의 단위 테스트 , SOAP UI 기반의 REST API 테스트 , Seleniuem 기반의 UI 테스트까지 자동으로 완료 한다 . 만약에 배포나 테스트가 실패하면 , 이전 버전으로 자동 롤백한다 .

자동화

• 빌드 자동화 , 테스트 자동화 , 배포 자동화 자동화

DEV QA STAGE

테스트完

가상화 or 클라우드필요할때만 전개

릴리즈

연계 시스템

클라이언트

단말 (모바일)

자동 빌드 배포 시스템Python Fabric

Ruby Capistrano

mvn & RPM

리포지토리rpm

Ruby on Rails, Python,PHP대세는 node.js

스크립트 언어

아키텍쳐 스타일의 변화

중앙 집중형

고가용성 (HA)

분산형

Resilience

트랜젝션 보장 장애 허용

한정된 용량 대용량

목표 성능 한계 성능

엔터프라이즈 시대 모바일 시대먹고 살기 좋던 시절 요즘

RMI,WebService REST OPEN API

개발 방식의 변화

정보 습득 방식의 변화

벤더 교육 센터 제품 메뉴얼 책

책온라인 메뉴얼블로그 찾아보기물어보기 ( 영어로… )중수

코드 까보기고수네이버 ?

개발 방식의 변화

벤더가 시키는데로 솔루션에 포함된 예제 보고책 예제 보고 진리를 깨우치고

물어보고다른데 프로젝트 했던 SI 불러서

그럴 시간 없음… .Copy & Paste

Stack overflow

하는데 까정 해본다 . 시간 없음

기술 검증 PoC,BMT

똑똑하면 소스 깐다 .

Trial & Error

• 1 단계 스타트업 !!

단계별 개발 모델의 변화

스타트업

• 2 단계 펀딩 받았다 .

단계별 개발 모델의 변화

성숙된 개발 조직

• 3 단계 깨달았다 .단계별 개발 모델의 변화

CD & DEVOPS

개발 방법론

<Insert Picture Here>

그래서…

저명한 박사님들께서 .. 방법론을 만드시니 .. RUP,CBD,CMMI

개발 방법론

But…

그러나 현실은 방법론은 방법론… 우리는 조금 더 현실적인 방법론이 필요합니다 .

개발 방법론

실용주의 방법론구세주 등장 !!

• 실용주의 방법론• Erich Gamma, Joel Spolsky, Kent beck, Andrew

Hunt• Iterative & Incremental• 애자일 기반

• 기존 방법론과 차이• 요구 사항이 변화할 것을 가정• 에러가 있을 것을 가정하여 , 자주 테스트• 협업과 커뮤니케이션

개발 방법론

• 대표적인 개발 방법론

스크럼이 대세 !!

관리자 입장에서는 예측 불가조직에 맞게 바꿔서 쓰세요 http://agilescout.com/learn-more-agile-software-development-methods-this-year/

개발 방법론

아시는 분들은 이미 알고 , 자료도 많으니 모르시는 분들은이것만도 7 박 8 일은 이야기 할 수 있으니 , Scrum 만 기억해 가세요

• 핵심은개발 방법론

요구 사항은 변한다… 변하는게 나쁜게 아니라 고객은 배우면서 성장한다 .그러니 당연하게 바뀐다 .결국은 사람이 답이다 .커뮤니케이션을 원할하게 하는 방향으로 변화

역할과 원칙 , 프로세스를 잊지 마라안그러면 망한다 . 애자일은 무슨~~

팀모델의 변화

• 기술 분류에 따른 팀 (Functioanl Team)– 프론트 , 백앤드 , 앱 , 운영 ,QA 등

팀모델의 변화

모바일 앱

백앤드

웹 페이지 관리도구댓글 포스팅 댓글 포스팅

앱개발팀 프론트 개발팀

백앤드 개발팀

• Cross functional Team (Product based)– 한팀내에 프론트 , 백앤드 , 앱 , 운영 ,QA 를 다 넣음– MSA 에 적용되는 팀모델

팀모델의 변화

• Cross functional Team (Product based)– Product 간에 복잡한 코디네이션이 필요함– Program manager, Chief Architect 등

팀모델의 변화

• Cross functional team (Feature based)– 기능 단위로 팀을 묶고 , 한팀이 전체 컴포넌트를 개발– 플랫폼화 필수 ( 쉽게 기능 추가가 필요한 구조 )

팀 모델 변화

MSA 의 기본 개념 이해

• 모노리틱 아키텍쳐 ( 통서버 )전통적인 아키텍쳐 스타일

• 하나의 서버에 모든 비지니스 로직이 들어가 있는 형태• 하나의 중앙 집중화된 데이타 베이스에 모든 데이타가

저장됨

• 단점– 여러개의 기술을 혼용해서 사용하기 어려움 (node.js , Ruby, Python etc)– 배포 및 재기동 시간이 오래 걸림– 수정이 용이하지 않음 ( 타 컴포넌트 의존성 )

• 장점– 기술 단일화– 관리 용이성

전통적인 아키텍쳐 스타일의 장단점

• 시스템을 여러개의 독립된 서비스로 나눠서 , 이 서비스를 조합함으로서 기능을 제공하는 아키텍쳐 디자인 패턴• SOA 의 경량화 버전 ( 실패한다면 실패하는 이유도 같음 )

마이크로서비스 아키텍쳐란 ?

서비스란 ?– 단일된 기능 묶음으로 개발된 서비스 컴포넌트– REST API 등을 통하여 기능을 제공– 데이타를 공유하지 않고 독립적으로 가공 저장

사용자 관리 인터페이스• REST• Thrift,Protocol buf -

fer• AMQP• :

사용자 데이타

• 하나의 기능을 구현 하는데 , 여러개의 서비스를 조합하여 기능을 제공 예 ) 주문 하기 : 사용자 정보 조회 , 상품 정보 조회 , 신규 주문 생성서비스 조합

사용자 관리

상품 관리

주문 관리

쇼핑몰 웹

API CALL사

용자

정보

상품

정보

주문

정보

사용자 관리 상품 관리 주문 관리

사용자 정보 상품 정보 주문 정보

쇼핑몰 웹

API CALL

모노리틱아키텍쳐 마이크로 서비스아키텍쳐

• 마이크로 서비스 아키텍쳐는 서비스 별로 다른 기술 스택을 사용할 수 있음기술 스택

사용자 관리(JAVA)

상품 관리(node.js)

주문 관리(JAVA)

사용자 정보(Cassandra)

상품 정보(MySQL)

주문 정보(Couch-Base)

쇼핑몰 웹

API CALL

장점일까 ?

• 운영 관점에서 여러가지 기술을 동시에 다뤄야 함(Devops – You build, You run)

• 사람이 떠나면 보수 불가(Product not a project)

단점일까 ?

• 적절한 기술을 적절하게 배치 가능o 복잡한 데이타 RDBMS, 양이 많은 고속 데이타 NoSQLo C10K NoSQL, 빠른 개발 스크립트 언어 , 튼튼한 시스템은 자바 …

• 컨웨이의 법칙 – 뼈저리게 느낌

팀 모델

“ 소프트웨어의 구조는 그 소프트웨어를 만드는 팀의 구조와 일치한다 .”설계 백날 잘해야 소용없음 제대로 된 팀 구조를 만드는 것이 설계 ( 그 다음은 알아서 됨 ?)

• 친한팀 컴포넌트끼리는 개발이 잘됨 . 그러다 보니 그쪽으로 기능이 몰림• 잘하는 팀한테 자꾸 중요 기능이 몰림서비스 컴포넌트들이 균등하게 디자인 되지 않음

• 분산형 거버넌스 ( 각 팀이 알아서 . 적합한 기술 , 스스로 하기 )• You build & You run!!• Self Organized Team• Product vs Project• Cross functional team• Alignment ( 소통 !!)

팀 모델

• 팀간 조율이 핵심 – 새로운 조율자 ROLE 이 요구됨

팀 모델

프로그램 메니져 : 팀간 일정 조율치프 아키텍트 : 서비스간 흐름 정의 , 표준 정의 , 에러 추적 / 처리 방법 정의

MSA 설계 패턴

• 일반적인 마이크로 서비스 아키텍쳐 스택 구조마이크로 서비스 아키텍쳐 토폴로지

API gateway

Service orchestration (mediation, aggregation)

Com

mon

API

s

Com

mon

API

s

Com

mon

API

s

Com

mon

API

s

Com

mon

API

s

Com

mon

API

s

생략 가능 영역 • API 게이트 웨이 : API 의 single end point• Common APIs : 범용 API• Orchestration : 여러 API 를 묶어서 , 요구 사항에

맞는 로직을 구현

• Service Orchestration

규모가 커질 수 록 추가되는 계층들 ( 오케스트레이션 , API 게이트 웨이 )

1 단계2 단계

3 단계

쇼핑몰 API 서버

서비스 오케스트레이션 계층 활용

사용자 관리 상품 관리 주문 관리

사용자 정보 상품 정보 주문 정보

앱 또는 자바스크립트 클라이언트

API CALL

사용자 관리 상품 관리 주문 관리

사용자 정보 상품 정보 주문 정보

API CALL

클라이언트

API CALL

클라이언트에서 직접 서비스를 조합 하는 방식 별도의 조합 계층 (Orchestration or Mediation)을 넣는 방식

다른 프로토콜 사용 가능ex) 내부 PB, 외부 REST

• API 가 범용적으로 잘 짜야 있어야함• 클라이언트 팀이 모든 컴포넌트팀과 조율이 필요

규모가 크지 않은 구조에서 효과적

• 중간에 API 를 커스터마이제이션 또는 조합 하는 계층을 별도로 둠• 클라이언트팀은 조합 API 개발팀과 커뮤니케이션만 하면 됨• 클라이언트 요구 사항에 기민하게 대처• 그러나 계층은 하나 더 늘어남 ( 성능 , 디버깅 ,배포 )

일정 규모 이상 . 특히 클라이언트가 여러개인 구조에 효과적

• API 인증 / 인가• 로깅• 라우팅• 메시지 변환• 메시지 프로토콜 변환:

API 게이트 웨이

API 서버 API 서버 API 서버

데이타 데이타 데이타

API 게이트 웨이

• 클라이언트와 API 서버 앞에서 일종의 프록시 처럼 위치 하여 다양한 기능을 수행함

• SOA ESB (Enterprise Service Bus) 의 단순화 버전• 있으면 좋음 . 없어도 됨• 만들 수 있는 실력있으면 , 쓰는게 좋음• 잘못 쓰면 망하는 지름길

API 게이트 웨이

• 인증 , 인가의 단일화API 게이트웨이를 이용한 설계 패턴 #1

IDM( 계정관리 )

API 토큰 관리

클라이언트

API게이트 웨이

API서버

1. API 토큰 발급 요청

2. 사용자 인증 / 인가

3. API 호출

5. API 호출

4. API 토큰 인증

• 멀티 앤드포인트와 멀티 프로토콜 제공API 게이트웨이를 이용한 설계 패턴 #2

< 그림 . 다양한 디바이스로 부터 정보를 수집하는 IOT 시스템에 타입별 앤드 포인트 제공하는 예제 >

• MEP (Message Exchange Pattern) 변화API 게이트웨이를 이용한 설계 패턴 #2

• 오케스트레이션API 게이트웨이를 이용한 설계 패턴 #3

• ESB 기반 SOA 프로젝트가 실패한 대부분의 원인 (안하는게 좋음 )• 오케스트레이션 서버를 별도로 두는게 좋음

API 게이트웨이를 이용한 설계 패턴 #4• 메세지 기반 라우팅

– 글로벌 배포 시스템에 유용함– 멀티 버전 시스템 ( 레거시 업그레이드 ) 에 유용

• Cross Cutting Concern ( 공통 기능 ) 처리– 인증 , 로깅등 공통 기능 처리– API 개발팀은 비지니스 로직에 집중할 수 있도록 해줌

API 게이트웨이를 이용한 설계 패턴 #5

• 다중 API 게이트 웨이 패턴– 내부 , 외부용 API 게이트웨이 분리

API 게이트웨이를 이용한 설계 패턴 #6

• API 호출용 엔드포인트와 스트리밍 ( 파일 ) 용 엔드포인트 분리API 게이트웨이를 이용한 설계 패턴 #7

• 비 기능 요소 제어– QoS 제어– Metering & Charging ( 상용 API 서비스 과금 )– API 모니터링

API 게이트웨이를 이용한 설계 패턴 #6

• 여러개의 서비스 컴포넌트를 조합하여 움직이는 트렌젝션에 대한 추적 디자인 패턴분산 트렌젝션의 추적

원리 (XA 분산 트렌젝션과 유사 )

• 초기 API 에서 GTXID 와 LTXID 를 생성• 서버를 넘어갈때 마다 같은 GTXID 를 사용 , LTXID 는 하나씩 증가구현시• 서버간에는 HTTP 헤더로 TXID 전달• 서버내에서는 Thread Local (Java)등의 컨택스트 변수 활용 초기 표준 설계가 중요함

• API 플랫폼– API 게이트 웨이– API 포탈 ( 웹 )

• API 스펙 문서• 샌드 박스 제공

• 제품군– 설치형

• WSO2• CA Layer 7

– 클라우드형• AWS API GW• apigee

Beyond API 게이트 웨이

MSA 적용 사례

촬영 및 배포 금지

• 총 4 개 국가에 개발센터 위치• 글로벌 시스템• 설득에만 거의 일년• 개념 이해가 안되거나 공감대가 낮은 팀• 솔루션 베이스• 나중에는 서로 가지고 가겠다고 해서 , 두개의 API 게이트웨이가 생기는• 다행히 IDM 은 도입이 되어 있던 상황 (SAML, OAuth2 등 지원 가능 )• 인터페이스 맞추는데 무잖히 많은 시간 . ( 팀별 레벨차 )• 말 안듣팀이 있었음 . ( 표준화에 무지 어려움 )• 팀간 일정 조율 및 배포등이 어려워서 전체 배포 일정 지장• 에러가 생길때 마다 E2E 를 보기위해서 전체 메신져 사용

O 사의 MSA 사례 촬영 및 배포 금지

• 높으신 분이 자체 개발하라고 한 API 게이트웨이 , 구매한 API 게이트 웨이 , 신규 프로젝트등

• API 표준화팀이 힘이 없음 제각각의 API ( 통제 안됨 )

• 과연 성공할까 ? ( 무늬만 MSA)

국내 P 사의 사례 촬영 및 배포 금지

• 원하지 않는 MSA 의 대표적인 사례• 개발자들이 공부하고 싶은 기술로 독립된 API 서버를 만들어냄

– JAVA, PHP, Python Flask, Python Django, Erlang– MySQL, Postgres, Redis, memcached, MongoDB

• 그리고 퇴사…• 현재 마이그레이션 하느냐고 죽어나는 중… .

국내 C 사의 사례 촬영 및 배포 금지

MSA 정리

• 장애 진단• 테스팅• 표준 관리• 팀의 역량에 따른 일정 및 품질 문제• 트렌젝션 관리• 서비스간 코디네이션 (Chief Architect, Program manager 의 역할 )• 서비스간 일정 관리

마이크로 서비스 아키텍쳐 문제점

• Self Organized Team

• Agile based interaction model

• Devops (Development & Operation)

• CD (Continuous Delivery)

• Product not a project

마이크로서비스 아키텍쳐와 같이 가는 개념들

• 전체적인 기술 역량이 뛰어날 것• Project 보다는 Product 기반의 서비스 조직에 유리• 일정 규모 이상의 팀이 되어야 유리함• 팀간 커뮤니케이션과 조직 구조 (Self organized team) 세팅이 전제• API 게이트 웨이는 양날의 검• 왠만하면 하지 마시고… 모노리틱과 MSA 중간 정도에서 타협을

– 통제된 기술 .

– 너무 잘게 나누지 말고 . 업무 단위 정도로 인터페이스 정해가면서 .

마이크로서비스 아키텍쳐

감사합니다 .