쵸코쿠키의 연습장

도메인 주도 설계 가변적인 클라우드 인프라 위의 어플리케이션인 마이크로서비스는 그 아키텍처에 특히 유연성과 확장성을 강조하고 있습니다. 이벤트 주도 설계를 통해서도 살펴보았지만 서비스를 제공하는 각 서비스 간의 관계는 서비스가 독립적입니다. 대체가능하도록 느슨하고 유연하게 구조화되어 있어야 합니다. 또한 헥사고날 아키텍처를 통해 살펴본 것처럼 서비스 내부의 구조도 시스템의 유연성과 확장성을 높여야 합니다. 그러기 위해 기술과 비즈니스 로직을 분리하여 구축하는 것이 바람직합니다. 어떻게 각각의 서비스를 비즈니스 독립적으로 식별할 수 있냐는 것과 또 하나는 서비스 내부 구조화 측면에서 어떻게 기술과 독립된 비즈 모델을 잘 설계할 수 있느냐 하는 질문이 있습니다. 이러한 질문에 답을 주는 아주 유용한 도구가 ..

CQRS(Command Query Responsibility Segregation : 명령 조회 책임 분리 서비스의 성능향상을 위해 서비스 Instance를 Scale Out하여 여러 개로 실행한 경우에 데이터 읽기/업데이트 작업으로 인한 리소스 교착 상태가 발생할 수가 있습니다. CQRS 패턴이라고 합니다. Command Query Responsibility Segregation, 명령 조회 책임 분리 패턴입니다. CQRS는 기존의 일반적인 개념이었던 동일한 저장소에 데이터를 넣고, 입력/수정/삭제/조회하는 방식에 도전하는 흥미로운 패러다임을 도입하고 있습니다. 일반적으로 사용자의 비즈니스 요청은 시스템 상태를 변경하는 명령과 시스템의 상태를 가져오는 조회의 두 부분으로 크게 나눌 수 있습니다. 사실 ..

서비스별 데이터베이스 Soa와 구분되는 Msa 특징으로 각각의 마이크로서비스는 각자의 비즈니스 처리를 위한 영구 데이터를 소유하고 있다는 것입니다. 그렇기 때문에 이러한 소유한 데이터는 다른 서비스에 직접 호출되게 하지 않고, 자신의 API를 통해서만 액세스 할 수 있습니다. 주문서비스가 주문수행을 위해 고객 정보를 필요로 한다면, 바로 고객 테이블을 질의를 할 수 없습니다. 반드시 고객 서비스의 API를 통해서만 호출할 수 있습니다. 따라서 이런 구조에서 분산 트랜잭션 문제가 발생할 수 있습니다. 여러 서비스 간에 데이터 일관성을 유지하는 방법 두 개의 서비스에 걸쳐서 트랜잭션 처리가 필요한 업무가 있을 수 있습니다. 즉 여러 서비스 간의 데이터 일관성을 유지할 필요가 있습니다. 이런 분산 트랜잭션 처..

마이크로 서비스 통신 방법 Rest API는 클라이언트에서 서버 쪽에 존재하는 마이크로서비스를 호출할 때 기본 통신방법이 되며, 다양한 클라이언트 채널 연계나 외부에 API의 공개를 원활하게 하기 위한 방법으로는 API G/W를 사용하는 것을 살펴봤습니다. 제일 먼저 검토해야 할 방법은 Rest API 같은 동기식 호출입니다. Sync 방식이라고도 합니다. 동기식 호출은 Request를 하면 바로 Response가 오는 방식을 말합니다.모바일 UI에서 상품서비스에 Post 방식의 요청을 하고, 상품은 주문 서비스에 Get 방식의 동기호출을 하고 있습니다. 그에 따라 바로 응답이 발생하고, 200이라는 OK 코드도 받아오는 것을 볼 수 있습니다. 바로 요청하면 응답이 오는 패턴이기 때문에 가장 많이 쓰이는..

Presentation Layer Presentation Layer에서 가장 많이 쓰이는 패턴은 Model View Controller로 이루어진 MVC 패턴입니다. MVC 모델은 초기 컨트롤러와 모델이 어떤 기술을 쓰느냐에 따라 발전해왔습니다. 최근에는 JSP가 View의 역할을, POJO가 모델의 역할, 서블릿이 이 두 개의 요소를 연계하는 컨트롤러의 역할을 수행하는 방식으로 발전해왔습니다. 그렇지만 현재는 JSP 서블릿뿐만 아니라 웹, 모바일, 태블릿, 인터넷, PC, 셋톱박스와 같은 다양한 인터페이스의 등장으로 인해서 이를 지원하기 위한 다양한 화면 플랫폼이 등장했습니다. Spring의 Thymeleaf나 페이스북이 공개한 React, 기존에 유명했던 ANGULARJS, 그리고 Vue.js 등의 ..

Layer 간의 의존성 UI 클라이언트가 Presentation Layer를 이용하고, Presentation 층이 Business Logic 층을 호출하고, Business Logic 층이 Data Access 층을 호출하고, Data Access 층이 저장소를 접근하게 됩니다. 어플리케이션에서 모든 영역이 중요하겠지만 가장 핵심적인 부분은 아무래도 어플리케이션이 제공하는 주요 서비스의 업무 로직을 담고 있는 Business Logic 층입니다. Presentation 층과 Data Access 층은 기술 트렌드에 따라 다양하게 교체 변화 가능하나, 핵심 비즈니스 기능은 한 번 정의되면 잘 변경되지 않습니다. 따라서 시스템의 확장성과 유연성을 높이기 위해 Layered Architecture는 이러한 ..

Tier와 Layer Tier는 물리층을 의미하며, Layer는 논리층을 의미합니다. Tier는 물리적인 장비, 서버 컴퓨터가 될 수 있습니다. Layer는 이러한 Tier 내부의 논리적인 분할을 의미합니다. 1:1이 될 수도 있지만 Tier의 내부를 제공하는 기능 성격에 따라 논리적 구분을 할 수 있습니다. 여기 어플리케이션 서버라는 중간층은 세 가지 Layer로 구별될 수 있습니다. 가장 일반적인 어플리케이션 Layer인 Presentation, Business Logic, Data Access층으로 나눠질 수 있습니다. Layered Architecture Layered Architecture는 설계자들이 복잡한 시스템을 분리할 때 흔히 사용하는 패턴 중 하나로 상위는 하위를 호출하여, 상위는 하위..

어플리케이션 아키텍처 우선 마이크로서비스 Architecture를 내외부로 구분했을 때 외부 Architecture가 Architecture를 이루는 구성요소의 관계를 설명한다면, 내부 Architecture는 구성요소 자신의 내부 구조를 상세히 정의하는 것을 말합니다. 이런 어플리케이션의 내부 구조를 정의하는 활동을 Application Architecture라고 하는데요. 마이크로서비스의 Inner Architecture, 다른 말로 하면 Application Architecture에 대해 자세히 살펴보도록 하겠습니다. Application Architecture는 어플리케이션이 동작하는 구조, 즉 동작하는 공통 메커니즘을 정의하는 것입니다. 웹 어플리케이션 구조 클라이언트 쪽에 브라우저 및 모바일 ..

인증, 인가 API 게이트웨이에서 인증 인가를 처리할 수 있습니다. 그런데 그것은 자체 기능으로 처리하지 않고 OAuth 서비스를 사용합니다. OAuth는 각각의 리소스 서비스가 자체적으로 인증 인가를 처리하는 것이 비효율적이고 독립성을 떨어뜨리기 때문에 등장한 서비스입니다. 동작 메커니즘을 살펴보면 우선 사용자가 API 게이트웨이를 통해 OAuth에게 각 서비스 리소스에 액세스할 권한이 있는지 요청합니다. 그럼 OAuth 서비스는 인증된 사용자인지 이 리소스에 권한이 있는지 확인하고 그것이 확인됐다면 리소스에 접근 가능한 증명서인 액세스 토큰을 발급해 줍니다. 그러면 API 게이트웨이는 다시 요청을 준비하고 각각의 리소스 서비스는 이런 리퀘스트가 액세스 토큰이 있는지 판단하여 리소스를 허용하는 것입니다..

마이크로 서비스의 역사 우선 기반 서비스가 어떠한 과정을 거쳐서 발전되었는지 마이크로서비스 발전 과정을 살펴보도록 하겠습니다. 그때부터 소프트웨어 업계가 거대한 계획이나 프로세스 대신 빠른 실패와 피드백을 기반으로 하는 실용적인 실천 방법을 선호하게 되었습니다. 우선 AWS가 IaaS 개념으로 2006년도에 EC2를 발표했고 넷플릭스가 스트리밍 사업을 시작하고 아마존의 클라우드 서비스인 AWS로 시스템을 이동하기 시작했습니다. 그러다가 데이터베이스 스토리지가 한 번 크게 망가져서 서비스가 큰 장애를 겪게 됩니다. 이걸 계기로 넷플릭스는 큰 덩어리의 모노리식 시스템에서 마이크로서비스 기반의 시스템으로의 전환을 시작했다고 합니다. 그런데 넷플릭스는 그런 마이크로서비스 기반 시스템을 만들고 운영하면서 여러 어..

인프라 영역 MSA에서 인프라 영역은 클라우드 환경을 의미합니다. 인프라로서의 서비스, 즉 IaaS, 플랫폼으로서의 서비스, 즉 Paas로 나눠집니다. 힘들게 구축했던 인프라를 세계적인 플랫폼 사업자들이 자동화된 기능으로 제공합니다. 예를 들면 시스템의 자원 구성, 할당, 관리, 모니터링 등 일련의 작업들을 몇 번 만의 버튼 클릭만으로 자동화, 시각화해서 제공하고 있습니다. 인프라 영역에서 클라우드 사업자가 제공하는 IaaS를 선택할지, 기존 베어 메탈 장비나 가상 머신인 VM을 선택할지 결정해야 합니다. 그다음 위에 플랫폼 영역에서는 마찬가지로 클라우드 사업자가 제공하는 Paas를 선택할지 또는 직접 오픈 소스로 프라이빗한 Paas를 구축할지 결정해야 합니다. 각각의 관계가 어떤 것을 선택할지라도 유연..

소프트웨어 아키텍처의 의미 소프트웨어 아키텍처는 소프트웨어를 구성하는 요소와 그 구성요소 간의 관계를 정의하는 것입니다. 아키텍처링은 시스템 구축을 위한 여러 가지 비기능 요건, 예를 들면 문제 영역이 되는 성능, 가용성, 보안, 유지보수성, 확장성 등을 만족하도록 여러 가지 해법을 정의하는 과정입니다. 특히 마이크로서비스 아키텍처는 클라우드라는 가상의 인프라를 활용하여 구조화하는 것이기 때문에 클라우드의 특징을 고려하여 설계되어야 합니다. 클라우드 인프라 및 마이크로서비스 기반 시스템의 장점은 변화무쌍한 비즈니스 환경에 대응할 수 있는 대체성과 확장성이 있기 때문에 아키텍처도 변화에 대응할 수 있는 유연성과 확장성을 반드시 갖춰야 합니다. MSA 내부/외부 아키텍처 다음은 일반적인 마이크로서비스 아키텍..

분권 데이터 관리 모노리스의 시스템을 살펴보면 단일 통합 데이터베이스를 사용하고 있습니다. 이러한 단일 데이터베이스를 유지하는 방식은 벤더의 라이센서 모델과 데이터베이스의 기능 확장에 그 뿌리를 두고 있습니다. 마이크로서비스는 Polyglot Persistence 접근 방법을 선택하며, 서비스별로 데이터베이스를 갖도록 설계를 합니다. 즉, 이 말은 각각의 저장소가 분산되어 있어야 하며, 다른 서비스의 저장소를 직접 호출할 수가 없고 API를 통해서만 접근해야 함을 의미합니다. 그런데 이런 케이스에는 반드시 등장하는 문제가 있습니다. 데이터 일관성 문제입니다. 주문 서비스와 배송 서비스가 있다고 생각을 해겠습니다. 상품이 1건 주문되면 배송도 1건 발생해야 합니다. 보통 이러한 처리는 동시적인 트랜잭션으로..

Biz 역량 기반팀 멜빈 콘웨이의 콘웨이 법칙이라는 것이 있습니다. 이는 시스템 개발 시 항상 시스템의 모양이 팀의 구조를 반영한다는 것을 말합니다. 하나의 어플리케이션을 만들기 위해서는 UI팀, 서버개발팀, DB팀과 같은 기능적으로 같은 기술을 가진 팀이 관여하게 됩니다. 따라서 시스템도 같은 모양이 되고, 이런 방식의 팀 구조에서는 아무래도 팀이 다르기 때문에 의사소통의 시간이 오래 걸리게 됩니다. 마이크로서비스를 만드는 팀은 Biz 역량 기반 팀입니다. 이는 역할 또는 기술별로 팀이 별도로 존재하는 것이 아니라 업무 중심으로 보여 기술이 다양한 사람들이 같은 팀을 이루어 서비스를 만드는 것을 의미합니다. 이러한 Biz 역량 기반 팀은 다양한 역할을 가진 기획자, 디자이너, Frontend 개발자, ..

마이크로서비스 아키텍처 우선 마이크로서비스 아키텍처는 하나의 어플리케이션을 여러 개의 서비스 집합으로 구성하는 것을 말합니다. 어디서 많이 보았던 개념인 서비스 지향 아키텍처 SOA가 있습니다. 1990년대 후반부터 발전한 객체 지향 분석 설계, 컴포넌트 기반 개발, Service Oriented Architecture, 즉 SOA의 연장선에 있습니다. SOA와 마이크로서비스 아키텍처의 공통점은 둘 다 소프트웨어 설계 시 서비스 중심을 설계를 지향하는 것입니다. 마이크로서비스와 SOA 서비스 오너십을 보면 마이크로서비스는 하나의 독립된 팀에서 개발하고 관리합니다. 반면 SOA 서비스는 중앙에 관련된 서비스를 공유하기 위한 공유 미들웨어 중심으로 개발하기 때문에 여러 팀, 즉 기획팀, 공통기능개발팀, 개발..

아마존닷컴과 같은 경우는 이미 일반화되었던 쇼핑몰 사업을 가지고 성공을 만들어냈고, 넷플릭스는 비디오 대여 사업으로 시작한 회사입니다. 또한 이들 회사들이 주목할 만한 점은 이들이 끊임없는 비즈니스의 변화를 통해 새로운 가치들을 만들어내고 있다는 것입니다. 11.6초는 몇 년 전에 아마존닷컴이 유명한 IT 컨퍼런스를 통해 발표한 수치입니다. 아마존닷컴이 어플리케이션을 배포하는 주기입니다. 비즈니스상의 문제점이나 개선 사항이 있을 경우에도 이를 수정해서 배포해야 합니다. 즉 그렇기 때문에 이 의미는 아마존 닷컴은 11.6초마다 새로운 서비스와 상품을 배포하고, 또한 서비스의 반응을 보아 개선이 필요할 때나 버그가 발생했을 때 이를 즉시 개선하고 있다는 것입니다. 최근에 비즈니스 흐름은 굉장히 빨리 변하고 ..