본문 바로가기

Architecture

(23)
Service Mesh 아키텍처 스타일 비교 이전 글에서 서비스 메시에 대해서 간략히 언급했었습니다. 서비스 메시가 무엇인지 아직 모르시는 분은 링크를 통해 읽어보세요. 본 글에서는 서비스 메시의 아키텍처 스타일에 대해서 얘기하고자 합니다. 우리가 이미 알고 있는 방법일 수 도 있습니다. Library 방식: 라이브러리로 필요 기능들이 제공되며, 애플리케이션의 코드 레벨로 사용되어야 합니다. (어찌 보면, 서비스 메시라고 할 순 없지만 서비스 메시를 구현하기 위한 대안? 으로 이해하시면 될 것 같습니다.) Node Agent 방식: Node Agent나 Daemon에 의해서 기능들이 제공됩니다. Sidecar 방식: 컨테이너내에 sidecar로 proxy가 적용되어 기능들이 제공됩니다. 이제 각각의 아키텍처 스타일에 대해 상세히 살펴 볼까요? 타입..
Service Mesh Architecture (서비스 메시 아키텍처) 마이크로 서비스는 소프트웨어 산업에 많은 영향을 주었습니다. Monolithic에서 마이크로 서비스 아키텍처로 전환하면 독립적으로 더 자주 애플리케이션을 배포 할 수 있습니다. 그러나 마이크로 서비스 아키텍처를 채택하는 것은 분산 시스템을 설계 할 때 발생하는 문제들을 가지고 있고 이 문제를 해결해야 한다는 것을 의미합니다. 분산 컴퓨팅의 오류를 살펴 볼까요? 네트워크는 신뢰할 수 있다. 지연 시간은 0이다. 네트워크 대역폭은 무한하다. 네트워크는 안전하다. Topology는 변하지 않는다. 관리자 한명이 모든 것을 처리한다. 데이터 전달 비용은 0이다. 동종 네트워크이다. 마이크로 서비스 아키텍처 사용시 네트워크에 대하여 종속성이 생깁니다. 이는 안정성에 문제를 유발합니다. 서비스 수가 증가하게 되면 ..
마이크로 서비스 관련 Tool 마이크로 서비스 Tool이라고 표현했지만, 다양한 기술의 모음이라고 생각하면 된다. 이번 글에서는 서로 다른 용도로 사용되는 마이크로 서비스 Tool에 대해서 살펴 볼 것이다. 운영체제 어플리케이션을 만들때에 가장 중요한 요소 중 하나는 적합한 기반을 설정하는 것이고, 결국 어플리케이션은 운영체제를 기반으로 수행되게 된다. Linux는 이런 운영체제중에 하나이며 가장 일반적으로 사용된다. Linux container를 사용하여 실행 환경 및 보안, 네트워킹, 스토리지와 같은 부분을 조절할 수 있다. 프로그래밍 언어 마이크로 서비스의 주요 장점은 다른 언어와 기술을 사용할 수 있다는 점이다. 따라서 개발자는 자유롭게 기술 스택을 선택하고 어플리케이션을 개발 할 수 있다. 그러나 현재 시점에서 가장 많이 사..
Netflix내의 마이크로서비스가 데이터를 처리하는 방법 (Gutenberg) 마이크로서비스 아키텍처에서는 단일 서비스에서 여러 목적지로 데이터 세트를 전파하는 것이 어려울 수 있다. 여기서 말하는 데이터 세트는 서비스 구성, 배치 작업 결과등의 모든 것을 의미 할 수 있다. 이러한 것들은 시간이 지남에 따라 종종 업데이트되어야 하기도 한다. 예를 들어서 Netflix에서는 수많은 A/B 테스트를 실행하고 있고 이런 테스트는 여러 서비스를 걸쳐서 수행되기에 테스트 담당자는 구성을 즉시 조정할 수 있어야 한다. 그리고 문제 발생시 이전 버전으로 롤백을 해야 한다. 다른 예는 머신 러닝 모델의 결과에 대한 배포이다. 머신 러닝 모델의 결과는 여러 팀에서 사용되지만, 모델을 담당하는 팀이 고가용성 서비스에 대한 관심이 높진 않다. 그리고 데이터 결과에 대한 활동들은 여러 팀이 활동하기에..
마이크로 서비스 전환시 알아야 할 것 어떤 서비스를 만들때에 Monolithic으로 만들어야 할지? Monolithic으로 만들고 Microservices로 구성해야 할지? 아니면 처음부터 Microservices로 구성해야 하는지에 대한 고민이 생긴다. Microservices는 최근 급속히 발전하는 많은 기업이 소프트웨어 아키텍처로 이동할 것을 고려하고 있다. Microservices 또는 Serverless로의 이동은 잘 만들면 금융, 소매, 마케팅, 데이터 분석 및 기타 여러 산업에서 효율성을 가져 올 수 있다. 위 그래프는 2017년에 도입되었거나 2018년도에 도입해야 하는 최우선 기술들을 표현한 그래프이다. 제품이나 서비스가 잘못 설계되었을 경우, Microservices를 적용한다고 하여 품질이 향상되지는 않는다. (그 이유는..
마이크로 서비스에서 분산 트랜잭션 분산 트랜잭션은 무엇인가? 아래는 트랜잭션을 사용한 Monolithic 커머스 시스템이다. 위의 경우는 체크 아웃 요청에 대해 데이터베이스에서 트랜잭션이 생성된다. 각 비즈니스 단계에 대해서 데이터베이스에서 보장한다. ACID(Atomicity, Consistency, Isolation, Durability)로 알려져 있다. 아래는 마이크로 서비스에서의 커머스 시스템이다. 모놀리틱은 데이터베이스에 의존하여 트랜잭션을 처리하지만, 마이크로 서비스의 경우 데이터베이스에 의존할 수가 없다. 그 이유는 각 서비스마다 별도의 데이터베이스를 가지고 있기 때문이다. 마이크로 서비스에서 트랜잭션에 대한 문제 마이크로 서비스 아키텍처가 나온 후, 데이터베이스의 ACID 특성을 사용할 수 가 없다. 특정 로직을 처리하기 ..
마이크로 서비스를 사용하지 않는 경우 본 글은 찰스 페발의 블로그의 글 을 번역한 것이다. 굳이 마이크로 서비스가 필요하지 않는 상황에서도 “마법의 키워드”와 같이 마이크로 서비스를 꼭! 해야 한다는 상황에서 정말 그래야 하는지 고민해 볼 필요가 있다. 마이크로 서비스란? 마이크로 서비스에는 많은 정의가 있다. 일반적으로는 아래와 같이 요약된다. 마이크로 서비스는 구성 요소 설계 및 배치 아키텍처에 적용 되는 패턴이다. 서비스를 작게 유지하고 기능별로 그룹화 한다. 관심사를 분리하여 구현한다. 서로 자율적으로 분리되어 있어야 한다. 독립적 배포 및 버전을 조정하여 확장할 수 있어야 한다. 마이크로 서비스 패턴의 일반적인 구현은 다음과 같다. 주요 문제는 적용 가능한 패턴의 폭이 상당히 넓다는 것이다. 그렇기 때문에 마이크로 서비스를 선택하는..
마이크로 서비스의 경계 마이크로 서비스를 사용하면 이점을 얻을 수 있지만, 경험에 비추어보면 몇 가지 문제가 있었다. 영향을 최소화 할 수 있도록 도출된 문제를 인식하는 것이 중요하기에 여기에 몇 가지 적는다. 문제 중 하나는 마이크로 서비스의 경계를 잡는 일이다. 이것은 가장 어려운 작업이다. 마이크로 서비스 범위 설정 각각의 마이크로 서비스가 단일 책임의 원칙을 수용하는 구조라면 이 글을 쓸일이 없었을 것이다. 커머스 플랫폼에서 결제를 담당하는 서비스를 생각해보자. 처음에는 두 가지의 지불 방법 (카드와 바우처)만 존재했고, 이 두가지 방법이 동일한 서비스에서 구현되었다고 가정한다. 여기에 계좌 이체, Paypal등 다른 결제 방식이 추가된다고 하면 어떻게 해야 하는가? 미래의 요구 사항을 미리 알면 설계 시 혹은 경계 설..