◆ Micro Service의 내부 구조 정의
▶ 외부 영역 – 세부 사항
● 외부 영역은 내부 영역의 서비스 인터페이스를 사용하는 인바운드 어댑터와 내부 영역에서 선언한 아웃바운드 인터페이스를 구현하는 다양한 어댑터로 구성
● 어댑터는 플러그인처럼 언제든지 교체되거나 확장될 수 있어야 하기 때문에 내부 영역이 먼저 정의된 후에 외부 영역의 세부사항은 늦게 정의돼도 상관없도록 해야 하는데 이 같은 방식이 소프트웨어를 부드럽게(Soft) 만듬
● 어댑터
● API 퍼블리싱 어댑터
◎ API 퍼블리싱 어댑터는 REST API를 발행하는 인바운드 어댑터
◎ 내부 영역의 서비스 인터페이스를 호출해서 REST 형식의 API로 제공
◎ 명시적인 REST 리소스 명칭을 정의하고 각 REST 메서드가 의도에 맞게 서비스 인터페이스를 호출
◎ 엔터티를 직접 제공하지 않고 API의 필요에 맞는 DTO를 생성해서 엔티티를 변환 및 매핑해서 전달하는 것이 바람직
● API 프락시 어댑터
◎ API 프락시 어댑터는 다른 서비스의 API를 호출하는 아웃바운드 어댑터
◎ 내부 영역에 정의된 프락시 인터페이스를 구현하며 다른 서비스의 API는 REST API가 될 수도 있고 소켓이나 SOAP 프로토콜을 사용하는 API일 수도 있기 때문에 기술에 맞는 적절한 통신 방법을 구현
● 저장소 처리 어댑터
◎ 저장소 처리 어댑터를 구현할 때는 데이터 처리 메커니즘을 선택할 필요가 있는데 OR 매핑 방식 과 SQL 매핑 방식을 사용할 수 있으며 내부 영역에서 어떤 구조를 선택하든 둘 다 사용할 수 있지만 일반적으로 트랜잭션 스크립트 패턴을 사용할 경우 SQL 매핑 방식을 사용하고 도메인 모델 패턴을 사용할 경우 OR 매핑 방식을 많이 선택
◎ SQL 매핑 방식의 프레임워크로는 마이바티스가 가장 많이 사용되고 OR 매핑 방식으로는 JPA 나 스프링 데이터(Spring Data)가 많이 사용됨
◎ SQL 매핑 방식의 경우 SQL 질의문을 수동으로 작성해야 하므로 세밀한 SQL 제어가 필요할 경우 유용
◎ OR 매핑 방식은 OR 매퍼가 런타임 시 저장소에 따라 자동으로 질의문을 생성하기 때문에 SQL 작성에 따르는 개발자의 작업량을 줄일 수 있고 설정 내용에 따라 손쉽게 저장소를 변경할 수 있기 때문에 SQL 매퍼 방식보다 유연한 메커니즘으로 질의문을 수동으로 작성할 필요가 줄어들어 OR 매핑 방식에 익숙해지면 균일한 질의문 품질과 생산성 향상을 꾀할 수 있음
◎ 최근 추세를 보면 외국에서는 OR 매퍼가 SQL 매퍼보다 휠씬 많이 사용되고 있지만 아직까지 국내에서는 SQL 매퍼의 사용률이 높은 편인데 아마도 처음에 논했던 데이터베이스 중심의 아키텍처 및 객체지향 경험의 내재화가 높지 않았던 개발 문화에 기인하는 듯.
◎ OR 매퍼를 선택했던 프로젝트의 사례를 들면 생산성이 높은 OR 매퍼를 선택했음에도 프로젝트 팀원들이 대부분 SQL 매퍼에 익숙하고 객체 모델링에 익숙하지 않아서 학습 곡선이 높고 어려움이 많았는데 아키텍트는 이러한 상황을 고려해서 제공할 비즈니스의 성격 및 팀원의 역량과 개발 효율성을 두루 고려해서 저장 메커니즘을 선택해야 할 것
● 도메인 이벤트 발행 어댑터
◎ 외부 아키텍처에서 서비스 간 비동기 메시지 통신에 대해 살펴봤는데 여기서 전달 대상이 되는 정보가 도메인 이벤트
◎ 도메인 이벤트는 어떤 사건에 따른 상태의 변경 사항을 말하는 데 주문됨, 주문 취소됨 등의 명칭을 갖는 클래스로 구현되며 컨슈머(consumer)에게 전달 되기 위해 도메인 이벤트 발행 어댑터를 통해 발행
◎ 애그리거트 패턴을 적용할 경우 도메인 이벤트는 애그리거트에서 발생한 사건
◎ 실제로 도메인 이벤트가 생성되는 위치는 내부 영역이며 도메인 이벤트 발행 어댑터는 내부 영역의 이벤트 인터페이스를 구현해서 아웃바운드로 특정 메시지 큐나 스트림 저장소에 발행하는 역할을 수행
● 도메인 이벤트 핸들러
◎ 도메인 이벤트 발행 어댑터가 있다면 당연히 수신할 수 있는 인바운드 어댑터도 필요
◎ 도메인 이벤트 핸들러는 외부에서 발행된 도메인 이벤트를 구독해서 내부 영역으로 전달하는 일을 수행
◎ 이벤트 상태에 따라 적절한 서비스 인터페이스를 호출해서 내부 영역에 이벤트를 전달
◆ Agile Process
▶ Micro Service를 만들기 위한 가장 효율적인 프로세스는 실제로 동작하는 제품 중심의 반복/점진적 애자일 개발 프로세스
▶피드백을 통한 지속적인 개선을 추구하는 애자일 프로세스는 가장 효율적인 의사소통 구조와 협업 체계를 가진 다기능 팀을 필요로 하고 그러한 다기능 팀이 만들어내는 결과물이 Micro Service
▶ 2000년대 초반에 일어난 애자일 문화의 확산과 애자일 방법론의 중심 프랙티스(지속적 통합, 데브옵스 등), 그리고 클라우드 인프라, Micro Service 생태계의 발전은 그 흐름을 함께한다고 볼 수 있음
▶ 그동안 대표적인 애자일 방법론으로 스크럼과 XP 등을 많이 활용해 왔는데 특히 XP의 지속적 통합 프랙티스는 품질이 보장된 소프트웨어를 반복적이고 점진적으로 개발할 수 있게 하는 기본 토양이 되고 소프트웨어를 개발하는 생명주기로 스크럼 프로세스가 광범위하게 대중화 됨
▶ 스크럼은 스크럼 팀이라는 조직 구성과 스프린트라는 짧은 반복 주기를 통해 피드백과 개선 작업을 촉진함으로써 단기간에 제품을 생산하고 이를 계속 발전시킬 수 있게 해주지만 스크럼이나 XP를 살펴보면 개발 문화 및 관리 프로세스에 대해서는 자세히 설명하지만 설계하고 개발하는 엔지니어링 공정에 대해서는 자세히 언급하지 않아 여러 오해를 낳기도 하는데 즉 개발 문화가 미성숙된 조직에서는 애자일을 활용하면 설계나 관련 산출물을 아예 작성하지 않고 곧바로 개발을 진행할 수 있다고 생각하는 경향이 있는데 그것은 잘못된 생각
▶ 애자일에서 설계/개발 공정에 대해 상세히 설명하지 않는 까닭은 애자일 자체가 성숙된 개발 문화 에서 가장 효과가 좋은 프랙티스들을 가속화하고 기존 공정의 군더더기나 낭비를 제거하는 방식에서 시작됐기 때문인데 성숙된 개발 문화에서는 시시콜콜하게 설계 방식이나 개발 공정을 언급하지 않아도 알아서 자율적이고 효율적으로 진행되기 때문에 특별히 언급하지 않았던 것
▶애자일 문화가 국내에 유입되는 과정에서 우리나라 특유의 빨리빨리 문화 와 접목되어 설계가 불필요하고 바로 개발할 수 있는 방식으로 오해받고 있지만 소프트웨어를 설계하지 않고 곧바로 개발한다는 것은 사실 불가능
▶ 아무리 간단한 소프트웨어라도 소스코드를 담을 대략의 프로그램 구조, 모듈, 명명규칙 등을 정의하고 그것들 간의 호출 관계를 생각해야 함
▶ 문서화하지 않더라도 이러한 고민이나 사고 자체가 설계인 것
▶ 애자일에서는 이전의 개발 프로세스에서 강조했던 너무 세밀해서 과하고 무거운 설계 산출물의 무용함을 인식하고 실용적으로 접근해야 한다는 것을 강조
▶ XP에는 단순한 설계(Simple Design)라는 프랙티스가 있는데 이것은 어느 정도 개발을 시작할 수 있을 정도의 가벼운 설계를 의미하는데 설계를 단순하고 간단하게 하고 바로 개발로 들어간 뒤에 실제로 동작하는 소프트웨어를 보면서 다시 지속적으로 리팩터링(refactoring)하는 방식이 더 효율적이라고 말함
▶ 애자일에는 빨리 그리고 자주 실패를 경험해 보는 것이 중요하기 때문에 단순한 설계를 통해 우선 최소한의 실제로 동작하는 제품(MVP - Minimum Viable Product)을 만들어 자주 배포하는 것이 중요하고 이러한 과정을 거치면서 각 개발팀에 맞는 최적의 개발 프로세스를 지속적으로 향상시킬 수 있음
▶ 개발 문화가 성숙하지 않은 팀에 이 정도의 지침만 준다면 2~3주의 스프린트가 기존의 워터폴 일정을 단기간으로 축소한 고된 행군의 축약 버전이 되거나 계속된 시행착오의 연속으로 중도에 다시 워터폴 방식으로 되돌아갈 수 있고 그 결과물인 Micro Service조차 잘 정리되지 않은 채 뒤죽박죽인 스파게티 코드가 될 가능성이 높음
▶ 이렇게 되지 않으려면 기민한 반복 주기에 적합한 군더더기를 제거하고 핵심 활동에 집중할 수 있는 Micro Service 설계 및 개발 방법이 필요
◆ 도메안 주도 설계와 Micro Service
▶ 도메인 주도 설계(DDD)는 2003년에 에릭 에반스(Eric Evans)가 쓴 책으로 이미 Micro Service가 대중화되기 전에 출간되었는데 객체지향 설계 및 개발의 유용한 패턴을 정리했는데 특별히 Micro Service를 위한 책은 아니었지만 이후에 마이크서비스 개발이 활성화되는 과정에서 DDD가 Micro Service의 설계와 개발을 위한 주요 가이드로 주목 받았는데 특히 Micro Service의 애플리케이션 개발 측면, 응집성이 있는 도메인 중심의 Micro Service를 도출하는 지침 및 Micro Service 내부의 비즈니스 로직 설계의 주요한 가이드로 사용되고 있어서 Micro Service 설계 영역에서 빈번히 언급되고 주요 오픈소스(예: 스프링 부트 등)의 아키텍처도 DDD의 영향을 받아 왔기 때문에 Micro Service를 도출하고 내부 구조를 설계하는 데 도메인 주도 설계 기법을 활용하는 것이 효과적
▶ DDD에는 전략적 설계(strategic design)와 전술적 설계(tactical design)라는 설계 영역이 있음
▶ 전략적 설계는 도메인 전문가 및 기술팀이 함께 모여 유비쿼터스 언어(ubiquitous language)를 통해 도메인 지식을 공유 및 이해하고 이를 기준으로 개념과 경계를 식별해 바운디드 컨텍스트(bounded context)로 정의하고 경계의 관계를 컨텍스트 맵(context map)으로 정의하는 활동
▶ 전술적 설계는 식별된 바운디드 컨텍스트 내의 도메인 개념인 도메인 모델을 구성하는 유용한 모델링 구성 요소들을 설명
◆ 기민한 설계 / 개발 프로세스
▶애자일한 Micro Service 설계/개발 절차
▶ 점진/반복적인 스크럼 생명주기
● 기본 생명주기는 스크럼의 스프린트를 활용
● 스프린트는 스크럼의 점진, 반복적인 생명주기이며 보통 1〜4주 동안 실행
● 백로그(backlog)라는 일감 목록을 기반으로 각 스프린트에 일감이 배분되어 진행되며 매 스프린트마다 실제로 동작하는 소프트웨어를 시연하고 피드백을 얻음
● 스크럼의 주요 개념 및 공정
◎ 스크럼 팀: 스프린트가 진행되는 팀을 스크럼 팀이라고 하는데 스크럼 팀은 스크럼 마스터와 팀 멤버로 구성되고 스크럼 팀은 다기능 팀으로서 Front End 개발자, Back End 개발자, 설계자, 테스터, 비즈니스 전문가, 디자이너 등이 한 팀을 구성하는데 여러 직능을 가진 전문가들이 같은 팀에 모여 있으므로 의사결정이 빠르고 협업이 긴밀한데 스크럼 마스터는 협업을 촉진하고 팀의 장애물을 제거하는 역할을 수행
◎ 스크럼 미팅: 스크럼 팀은 매일 아침 각자의 자리에 서서 짧게 진행되는 스탠드업 미팅을 통해 각자의 일을 투명하게 공유
◎ 스프린트 계획 수립: 시스템의 모든 요구사항은 제품 백로그에 담기는데 그 다음 일정에 맞게 스프린트를 몇 번 수행할 것인가가 결정되는데 보통 스프린트는 1~4주의 기간이며 스프린트 횟수가 결정되면 제품 백로그에 담긴 백로그를 각 스프린트에 적절히 배분하고 스프린트가 종료되면 백로그 완료 일감을 기준으로 팀의 생산성이 결정되는데 이를 속도라고 부르고 이 속도는 프로젝트를 예측하기에 매우 중요한데 왜냐하면 이 속도에 맞춰 팀의 다음 스프린트 계획이 세워지기 때문이며 이러한 과정을 지속적인 계획(continuous planning)이라고 하며, 기존의 고정된(fixed) 계획이 아니라 적응적(adaptive) 계획이라고 볼 수 있음
◎ 기존의 고정된 계획은 범위가 고정돼 있고 일정, 비용, 품질이 그에 맞춰 유동적이었다면 적응적 계획은 일정, 비용, 품질이 고정돼 있고 그에 따라 범위가 조정되는 것을 볼 수 있음
● 팀의 속도에 맞춰 스프린트를 진행하다 보면 일정 내에 완료해야 할 일의 우선 순위를 정하는 것이 매우 중요해지고. 이는 가장 우선 순위가 높은 시스템의 핵심 기능에 집중할 수 있게 해줌
◎ 시연: 스프린트 마지막의 활동은 시연과 회고인데 시연은 초기에 정의한 백로그가 모두 구현되고 그 요건을 만족하는지 확인하는 자리로 이때 피드백을 받을 수 있고 다음 스프린트에 반영할 요건들을 확인할 수 있음
◎ 회고: 회고는 팀원들이 자기 스스로를 돌아보는 과정으로 Micro Service를 설계 및 개발하는 과정에서 좋았던 방식과 안 좋았던 방식을 논의하고 개선점을 찾아 다음 스프린트에 적용할 수 있음
● 스프린트가 협업을 진행하기 위한 관리 공정이었다면 다음으로 설계 및 개발과 관련된 엔지니어링 공정에는 스프린트 내에 설계 및 개발에 대한 공정이 있고. 특이한 점은 스프린트에 들어가기 전의 설계 및 개발을 위한 작업들이 존재한다는 것
댓글