한국 표준(?) 자바셋(Java 1.6+Spring 3.x+MyBatis)과 Monolithic 아키텍처를 사용하고 있었던 제 조직 내에서 기술적 변화를 이끌어가는 것에 관련된 내용입니다.
변화를 유도하기 위해서 어떻게 해야 하는지가 핵심이며,
Architecture, Frontend, Backend, 방법론/프로세스의 영역을 각각의 단계로 나누어서 Phase1을 수행한 것과 Phase2를 수행 중인 내용에 대해서도 다룹니다.
Phase1
- Architecture : Frontend / Backend 명시적 분리
- Frontend : Angular.js, Grunt, Bower 도입
- Backend : Java 1.7/Spring4, ORM 도입
- 방법론/프로세스 : Scrum, Git
Phase2
- Architecture : Micro-Service Architecture(MSA)
- Frontend : Content Router, E2E Test
- Backend : Polyglot, Multi-Framework
- 방법론/프로세스 : Scrum+JIRA, Git Branch Policy, Pair Programming, Code Workshop
오늘날, 모든 기업활동에 있어서 IT는 코어 비즈니스를 보조하는 보조적인 역할에서 벗어나 코어 비즈니스 그 차제가 되는 경우를 쉽게 찾아볼 수 있다. 이러한 엔터프라이즈 어플리케이션 개발에 있어서 기존의 프로젝트 중심 패러다임에서 프로덕트 중심 패러다임으로 전환에 성공한 국내외의 사례를 살펴보고 이들 사례로 부터 Best Practice를 정제하여 보고자 한다.
오늘날, 모든 기업활동에 있어서 IT는 코어 비즈니스를 보조하는 보조적인 역할에서 벗어나 코어 비즈니스 그 차제가 되는 경우를 쉽게 찾아볼 수 있다. 이러한 엔터프라이즈 어플리케이션 개발에 있어서 기존의 프로젝트 중심 패러다임에서 프로덕트 중심 패러다임으로 전환에 성공한 국내외의 사례를 살펴보고 이들 사례로 부터 Best Practice를 정제하여 보고자 한다.
Suggested platform provides a contactless microservices / cloud native application design learning and development using online tools including Cloud-ide and Event-storming tool, kafka, Spring-boot and kubernetes without any installation
Suggested platform provides a contactless microservices / cloud native application design learning and development using online tools including Cloud-ide and Event-storming tool, kafka, Spring-boot and kubernetes without any installation
사용자 인증 시 고민하게 되는 비밀번호 암호화와 데이터 암호화 도구에 대해 순수 웹 결제 플랫폼을 지향하는 시럽페이에 반영된 One Password Protocol (by Mozilla)과 JOSE(by Web Payment Group in W3C) 기술에 대해 간략하게 설명합니다.
Johannes Schlüter's PHPNW08 slides:
The current PHP version, PHP 5.3 introduced a multitude of new language features, most notably namespaces and late static binding, new extensions such as phar, as well as numerous other improvements. Even so, this power-packed release boasts better performance than older PHP releases. This talk will give you a good overview about PHP 5.3 and show some less known features in detail.
JDXA is an amazingly simple, flexible, non-intrusive, feature-rich, and lightweight ORM (Object Relational Mapping) product for Android.
JDXA dramatically decreases development time of Android apps by presenting a more intuitive object-oriented view of on-device SQLite data, eliminating the need to write and maintain endless lines of complex low-level SQL code.
Object-Relational Mapping and Dependency InjectionShane Church
Presentation for El Paso County IT on the concepts of Object-Relational Mapping and Dependency injection with a particular focus on the Microsoft Unity DI Container and the Microsoft Entity Framework. Delivered on October 2, 2012.
<1탄>왜 마이크로 서비스인가 - 마이크로서비스로 구성된 애플리케이션 소개
Session abstract:
이번 세션에서는 무엇이 마이크로 서비스고, 어떤 철학과 사상을 가지고 있는지 알아봅니다. 세션이 종료되면 참석하신 분들은 마이크로 서비스의 구성에서 어떤 내용이 중요한지 알게 됩니다. 전체 시리즈로 진행되는 첫 세션 입니다.
Session agenda:
-실 서비스용 데이터베이스를 종료한다면 어떤 일이 벌어질까
-마이크로서비스와 마이크로서비스가 아닌것
-어떻게 시작해야 하나
-마이크로서비스 애플리케이션 소개
-클라우드 네이티브(클라우드 최적화란)
클라우드 네이티브 IT를 위한 4가지 요소와 상관관계 - DevOps, CI/CD, Container, 그리고 MSAVMware Tanzu Korea
최근 IT 시장은 ‘클라우드 네이티브’ 라는 컨셉을 적극적으로 받아들이면서 혁신의 속도를 높이기 위해 여러가지 노력을 기울이고 있습니다. 본 세션에서는 ‘클라우드 네이티브’ 를 이루는 4가지 요소인 DevOps, CICD, Container, MSA 를 간략하게 살펴보고 MSA 가 나머지 클라우드 네이티브 3 요소와 어떻게 상호작용하여 고객 여러분의 비즈니스에 도움이 되는지 알아봅니다. 그리고 MSA 로 이행하기 위한 조직면에서의 요건과 기술 면에서의 요건을 살펴봅니다.
어느 해커쏜에 참여한 백엔드 개발자들을 위한 교육자료
쉽게 만든다고 했는데도, 많이 어려웠나봅니다.
제 욕심이 과했던 것 같아요. 담번엔 좀 더 쉽게 !
- 독자 : 백엔드 개발자를 희망하는 사람 (취준생, 이직 희망자), 5년차 이하
- 주요 내용 : 백엔드 개발을 할 때 일어나는 일들(개발팀의 일)
- 비상업적 목적으로 인용은 가능합니다. (출처 명기 필수)
커빙의 Django, Celery, Azure Cloud, SNS 연동, 컨텐츠 수집 기술을 한눈에 볼 수 있도록 소개한 자료 입니다.
커빙을 처음 개발하면서 많은 어려움이 있었지만
많은 분들의 도움으로 좋은 결과를 얻을 수 있었답니다!
이에 다른 분들에게 조금이나마 도움이 되었으면 좋겠다는 마음으로 공유합니다 : )
커빙의 Django, Celery, Azure Cloud, SNS 연동, 컨텐츠 수집 기술을 한눈에 볼 수 있도록 소개한 자료 입니다.
커빙을 처음 개발하면서 많은 어려움이 있었고,
또 많은 분들의 도움으로 좋은 결과를 얻을 수 있었습니다.
조금 더 깊은 내용을 다뤘으면 하는 아쉬움이 있지만,
다른 분들에게 조금이나마 도움이 되었으면 좋겠네요!
최근 들어 MSA(Micro Service Architecture)에 대한 관심이 높아지고 Amazon과 넷플릭스, 11번가 등에서 MSA를 이용하여 성과를 보이자 많은 곳에서 MSA를 이용한 프로젝트가 많아 지고 있습니다.
MSA에 대한 내용은 방대하지만, 간단한 개요만 이라도 정리하여 올립니다.
언제 애자일을 써야 좋을까? The better ways of developing softwareKevin Kim
The better ways of developing software
Software Development Methodology
Agile
Scrum Methodology
eXtreme Programming(XP)
Waterfall
Kanban
When to Use Scrum
When to Use Kanban
2. 변화(Changes)?
‘미안하지만 사람들은 정말 변화를
싫어합니다. 바로 그게 문제죠. 사람들은
자기에게 도움이 되는 변화는 물론이고,
변화는 뭐든 다 반대합니다. 그 이유는 바로
사람들이 변화를 싫어하기 때문이죠.’
- 피플웨어(Peopleware), 톰 디마르코/티모시
리스터
3. 소프트웨어라고 다를리가…
• 꼭 그거 써야 돼? 배우기 귀찮은데.
• 지금 쓰던 기술로도 되는데?
• ‘검증’ 안된 거잖아. 우리 회사에서 쓰는 곳
있어?
• 문제 생기면 니가 책임질래?
4. 고양이 목에 방울달기
또한 새로운 체제를 도입하는 선봉 역할을 맡는
것처럼 하기 어려우며, 성공을 보장하기 힘들고,
지극히 위험한 일도 없다. 새로운 질서를
도입하는 사람은 필연적으로 구체제 하에서
기득권을 가졌던 사람들과 모두 적대 관계가 될
것이며, 새로운 체제에서 기득권을 얻을 수도
있는 사람들은 오직 소극적인 태도로 그를
옹호할 것이기 때문이다.
- 군주론, 마키아벨리
5. 그래도 변화는 필요하다
• 새로운 기술은 ‘재미’를 이끌어낸다.
• 기술의 변화가 관점의 변화, 할 수 있는 일의
범위를 변화시킬 수 있다.
• 노땅 개발자는 낡은 기술과 함께 늙어가고,
젊은 개발자는 새로운 기술에 열광한다.
• 먼저 매 맞아주는 선구자들이 오픈소스
커뮤니티에 존재한다. (한국 아니면 어때,
글로벌 시대인데…)
6. 신규 개발 시의 고민
• 지난번과 동일한 기술/방법론을 사용할지?
• 뭔가 새로운 기술이나 새로운 방법론을
시도해볼지?
• 프로젝트 멤버들에겐 뭐가 더 재밌을까요?
(물론 재미를 따질 여유 따윈 없으신 분들도
계시겠지요… /애도)
7. 그래서,
• ‘변화’를 주는 것이 더 재밌다고 생각했기
때문에 변화해보기로 합니다.
• ‘원칙적으로는’ or ‘이상적으로는’ 그렇게
하는 것이 ‘맞다’ or ‘좋다’고 생각되는 거면
그렇게 하기로 합니다.
11. Phase 1 : Architecture
• Frontend와 Backend를 명시적으로 분리하고,
각각 독립적인 개발/배포가 가능하게 한다.
• Frontend와 Backend는 REST API를 사용하여
통신하며, Stateless Architecture여야 한다.
12. Phase 1 : Frontend
Web Application
Presentation
Controller
Business
Data Access
JSP
Sitemesh
JQuery
기존 시스템들의 Frontend
Frontend
HTML
CSS
Angular.js
Bootstrap
Less
Grunt
Bower
Karma
신규 시스템의 Frontend
13. Phase 1 : Frontend
Web Application
Presentation
Controller
Business
Data Access
JSP
Sitemesh
JQuery
기존 시스템들의 Frontend
Frontend
HTML
CSS
Angular.js
Bootstrap
Less
Grunt
Bower
Karma
신규 시스템의 Frontend
Frontend
MVC Framework
Frontend
Task Runner
(Build, Test, Run)
Frontend
Package Manager
Frontend
Test Runner
CSS
Framework
CSS
Helper
14. Phase 1 : Backend
Java 1.6
Tomcat 6
Spring 3.x + XML Conf.
Spring MVC
MyBatis
Maven
기존 시스템들의 Backend
a.k.a. 한국 SI 표준셋(?)
신규 시스템의 Backend
Java 1.7
Tomcat 7
Spring 4.x + Java Conf.
Spring MVC
Spring Data JPA +
Hibernate
Maven
15. Phase 1 : Backend
• Goodbye MyBatis & Hello ORM
– Model-Driven 구조
– DDL 자동생성 (Production 제외)
– ERD 그리느라 시간 낭비하지 않음
– 실행 시에는 MySQL, Unit Test 시에는 H2 사용
• ORM 성능 우려?
– 필요하면 Second-Level Cache 적용
– 그걸로도 안되면 Native Query 사용
– 그걸로도 안되면 DB 튜닝
16. Phase 1 : 방법론/프로세스
• Project Charter 작성
– 프로젝트 개요, Scope, 마일스톤
– 커뮤니케이션 위치(Wiki, JIRA, Agile Board, Git)
– 프로젝트 원칙, FAQ
• Scrum 도입
– JIRA Agile 적극 활용
– Sprint 계획/실행/리뷰
• Git
– 처음엔 별다른 Branch 정책 안 둠
– 그냥 일단 Git부터 익숙해지기
17. Phase 1 : 방법론/프로세스
• 프로젝트 원칙
– Sprint 기간 중에는 모든 멤버가 Sprint의 항목에 대해서만 집중한다.
– Sprint 항목은 Sprint 기간 내에 완료되어야 하며, 구현 항목에 대해 배포가
가능한 형태로 시연이 가능해야 한다.
– Dogfooding
– 모든 구성원은 자발적으로 필요하거나 누락된 항목이나 문제점, 더 좋은
아이디어가 있으면 제안하고, 서로 협력한다.
– 개발하는 모든 과정이나 나오는 산출물을 숨기지 않는다. 개방된
마음으로 지적질을 수용한다.
– 팀, 회사 차원의 개발에서 Best Practice를 만든다는 생각으로 임한다.
18. Backend 개발자Frontend 개발자
Phase 1 – 방법론/프로세스
UserStory 검토
Contract/API 설계
Frontend 개발 Backend 개발
Mock/Unit Test Unit Test
API 연동 Load Test
UserStory 종료
19. Phase 1 결과
• 새로운 서비스를 Beta 오픈했고,
• 새로운 기술을 습득하고 검증했으며,
• 새로운 방법론/프로세스에 대해 적응
• Stakeholder들의 긍정적 Feedback
• 무엇보다, 프로젝트 멤버들이
‘성취감’과 ‘재미’를 느꼈다는 점
21. Phase 2
‘기존’ 서비스들 + @를
‘더욱 새로운’ 기술과
‘더욱 새로운’ 방법론으로
‘더 많은’ 사람들과
만들어보자.
22. Phase 2
‘기존’ 서비스들 + @를
‘더욱 새로운’ 기술과
‘더욱 새로운’ 방법론으로
‘더 많은’ 사람들과
만들어보자.
마이그레이션, 이행을 고려해야 함
세상은 넓고 새로운 기술은 많다
보다 나은 개선을 위한 실험
피자 두판을 넘어간다면..?
23. Phase 2 : Architecture
• 기존 : Monolithic Architecture
“사용자용” Web Application
“운영자용” Web Application
“App용” API Service
“Central” Database
A.UI A.Biz
B.UI B.Biz
A.UI A.Biz
C.UI C.Biz
D.UI D.Biz
D.Biz
A.Biz
A B
C D
24. Phase 2 : Architecture
• To Be : Micro-Service Architecture(MSA)
A
UI
A
Service
B
UI
B
Service
C
UI
C
Service
D
UI
D
Service
A
DB
B
DB
C
DB
D
DB
Content
Router
API
Gateway
Content
Router
Service
Registry
Event
Broker
Config
Service
Deploy
Service
사용자용 Endpoint
관리자용 Endpoint
25. Phase 2 : Architecture
• MSA를 선택한 이유
– Frontend – Backend 분리 + 기능 영역의 분리
– API 기반의 Contract 유지를 강제화
– 빌드/배포 용이, 확장 용이, 장애로 인한 영향 격리
– Micro-Service 단위로 이해하고 개발하기 쉬움
– Micro-Service 단위로 다른 프로그래밍 언어/프레임워크를 사용할
수 있음(Polyglot)
26. Phase 2 : Architecture
• MSA를 선택한 이유
– Frontend – Backend 분리 + 기능 영역의 분리
회사의 Engineer Tech Tree(Frontend/Backend)와 동기화
– API 기반의 Contract 관리를 강제화
API로 뽑아내지 않으면 아무것도 못하니까
– 빌드/배포 용이, 확장 용이, 장애로 인한 영향 격리
Micro-Service 단위로 격리되니까
– Micro-Service 단위로 이해하고 개발하기 쉬움
코드의 양을 줄여서 누구나 쉽게 파악할 수 있도록
– Micro-Service 단위로 다른 프로그래밍 언어/프레임워크를 사용할
수 있음(Polyglot)
실험해보고 싶은 거 맘대로 시도(써보고 아님 말고)
향후 개발자 구하기도 용이할 걸?
27. Phase 2 : Architecture
• 물론, 수많은 단점들이 있다
– Micro-Service를 얼마나/어떻게 나누어서 설계해야 할지?
– Contract (API) 관리를 어떻게 해야 하지?
– 기존에 개발자 혼자서 하면 되던 기능이 여러 명의 개발자(예:
Frontend 개발자, 다른 Micro-Service 개발자)와 협업을 해야 하는
경우들도 생긴다
– 세션은 어떻게 관리해야 하나?
– 서비스 간 의존성/트랜잭션 관리는 어떻게?
– 코드의 중복이 발생
– 배포/운영이 생각보다 머리 아픈데?
28. Phase 2 : Architecture
• 물론, 수많은 단점들이 있다
– Micro-Service를 얼마나/어떻게 나누어서 설계해야 할지?
– Contract (API) 관리를 어떻게 해야 하지?
– 기존에 개발자 혼자서 하면 되던 기능이 여러 명의 개발자(예:
Frontend 개발자, 다른 Micro-Service 개발자)와 협업을 해야 하는
경우들도 생긴다
– 세션은 어떻게 관리해야 하나?
– 서비스 간 의존성/트랜잭션 관리는 어떻게?
– 코드의 중복이 발생
– 배포/운영이 생각보다 머리 아픈데?
어떻게 해결해야 할까?
29. Phase 2 : Architecture
• 물론, 수많은 단점들이 있다
– Micro-Service를 얼마나/어떻게 나누어서 설계해야 할지?
– Contract (API) 관리를 어떻게 해야 하지?
– 기존에 개발자 혼자서 하면 되던 기능이 여러 명의 개발자(예:
Frontend 개발자, 다른 Micro-Service 개발자)와 협업을 해야 하는
경우들도 생긴다
– 세션은 어떻게 관리해야 하나?
– 서비스 간 의존성/트랜잭션 관리는 어떻게?
– 코드의 중복이 발생
– 배포/운영이 생각보다 머리 아픈데?
어떻게 해결해야 할까?
고갱님, 유료 서비스입니다
미안, 이건 다음 시간에…
(사실 현재진행형이라)
그리고 Google 신에게 물어보세요
30. Phase 2 : Architecture
• 물론, 수많은 단점들이 있다
– Micro-Service를 얼마나/어떻게 나누어서 설계해야 할지?
– Contract (API) 관리를 어떻게 해야 하지?
– 기존에 개발자 혼자서 하면 되던 기능이 여러 명의 개발자(예:
Frontend 개발자, 다른 Micro-Service 개발자)와 협업을 해야 하는
경우들도 생긴다
– 세션은 어떻게 관리해야 하나?
– 서비스 간 의존성/트랜잭션 관리는 어떻게?
– 코드의 중복이 발생
– 배포/운영이 생각보다 머리 아픈데?
무엇보다도,
우리는 이 단점들을 극복해가는 과정을 즐기고,
MSA가 가져주는 장점이 훨씬 더 크다고 믿습니다.
Remind:
‘원칙적으로는’ or ‘이상적으로는’ 그렇게 하는 것이 ‘맞다’
or ‘좋다’고 생각되는 거면 그렇게 하기로 합니다.
31. Phase 2 : Frontend
A
UI
B
UI
C
UI
D
UI
Content
Router
Content
Router
사용자용 Endpoint
관리자용 Endpoint
Browser에게
Single
Origin/Endpoint를 보장
UI의 Versioning이나
A/B Testing을
가능하게 하기 위한
기반
로그/통계의 기준
Micro-Service
Backend와 짝을 이뤄
독립적으로 개발됨
실제 서비스에서는
다른 UI들과 Main Page
Container에서 조립됨
E2E(End-to-End) Test
Selenium을 활용한
사용자
Viewpoint에서의 E2E
테스트
32. Phase 2 : Backend
Java 1.7
Tomcat 7
Spring 4.x + Java Conf.
Java 1.8
Embedded Tomcat
Spring Boot
Node.js
Express
MySQL
Redis
Others…
Groovy
Go
ASP.NET 5
Vert.x
Others…
Polyglot,
Multi-
Framework
향후
실험(?)
후보
Polyglot,
NoSql
또다른NoS
ql
또는 Cloud
PlanetSpace
File Storage
Cloud
33. Phase 2 : 방법론/프로세스
• Scrum 고도화
– Estimation 모델 도입
– JIRA Version을 활용한 Release Note 관리
– JIRA Issue Status와 연동
Open -> Progress -> Resolve(Code Commit/Link) -> Close(master
merge 및 배포 완료)
• Git Branch 정책
– Master Branch는 Production/Stage 배포 대상
– Dev Branch는 Sprint 중 개발 공유용
– Feature Branch : JIRA Issue 번호 기준 생성
– Feature->Dev, Dev->Master로 Merge 시 코드 리뷰 및 테스트
34. Phase 2 : 방법론/프로세스
• Pair Programming
– Frontend, Backend, Test별 Pair
• 2개의 Scrum
– 적절한 인원 유지를 위해
• Rules & Conventions
– 팀원 간의 암묵적 지식을 명시적으로 문서화
– 각 Scrum 간 공유
• Sprint Review 시 Code Workshop 실시
– 서로 간의 지식을 공유
35. Phase 2는 현재 진행형
우린 아마 안될거야
분명히 잘 될거예요,
변화가 재밌으니까.