마이크로서비스 아키텍처 구축(1) - MSA를 지탱하는 기본 개념

은총알은 없으니 경험이 많지 않거나 비즈니스 도메인에 대한 이해가 낮다면
무리한 마이크로서비스의 도입보다는 모놀리스에서 시작해서 점진적으로 분해하는 것이 좋다.

  • 마이크로서비스 아키텍쳐 구축

1. 마이크로서비스

Infrastructure automation

  • scale up/down
    • 수직 확장
    • 머신 리소스(CPU, Memory, Storage)를 추가
  • scale in/out
    • 수평 확장
    • 시스템의 노드, 머신, 애플리케이션 등을 추가

같은 이유로 변경되는 것들은 한데 모으고, 서로 다른 이유로 변경되는 것들은 분리하라.
Single Responsibility Principle / 단일 책임 원칙 ( 로버트 C, 마티 )

그렇다면 얼마나 작아야 작은 것일까?

코드가 너무 크다고 느껴지지 않는 한 아마 아직까지는 충분히 작다

서로 독립적인 변경이 가능하고 소비자의 변경없이 배포할 수 있도록 서비스 사이의 모든 통신은 네트워크 호출을 통해 이루어진다.
→ Application Programming Interface(API)

마이크로서비스 = 분산 시스템 + 서비스 지향 아키텍쳐(SOA, service-oriented architechture)
마이크로서비스는 SOA에 대한 특정 접근법

  • 서비스
    • 완전히 분리된 운영시스템의 프로세스
  • 모놀리식 시스템
    • 장애 가능을 낮추기 위해 수많은 머신 상에서 실행되어야 하지만
  • 마이크로서비스
    • 서비스의 전체 장애를 차단하고 기능을 적절히 저하시키는 시스템을 구축할 수 있다
  • 격벽/bulkhead
    • 장애 전파를 막는 용도

2. 진화적 아키텍트

아키텍트는 구축하는 시스템의 품질 수준이나 동료들의 근무 조건, 변화에 대응하는 조직의 능력에 대해 그 어떤 다른 역할보다 직접적인 영향을 줄 수 있다. 그러나 우리는 이 역할에 대해 꽤 자주 오해하는 듯 하다, 어째서일까?

넷플릭스

  • 데이터 저장 기술을 대부분 카산드라로 통일
  • 비록 모든 경우데 적합한 최선의 대응책은 아닐지라도,
  • 넷플릭스는 카산드라와 관련된 도구 및 전문지식을 통해 얻는 가치야말로
    • 몇몇 특정 태스크에 더 적합할 수 있는 다수의 이종 플랫폼 확장을 지원하고 운영하는 것보다 더 중요하다고 생각
  • 넷플릭스는 확정성을 가장 중요한 요소로 생각하는 극단적인 사례일 수있지만, 그들의 생각을 이해할 수 있는 있을 것

코딩하는 아키텍트

  • 아키텍트가 만들어내는 시스템을 개발자도 수용하기 원한다면 아키텍트는 그 같은 결정의 파급력을 이해할 수 있어야 한다.
  • 이것은 적어도 아키텍트가 팀과 함께 시간을 보내고, 이상적으로는 팀과 함께 실제로 코딩하는 것을 의미한다. -> 짝 프로그래밍
  • 아키텍트가 개발팀 옆에 있는 것이 얼마나 중요한지 아무리 강조해도 지나치지 않다.
  • 이것은 진화를 하거나 단순히 코드를 리뷰하는 것보다 훨씬 효과적이다.

트레이드오프

  • 시스템 설계상의 결정은 모두 트레이드오프
  • 동시에 발생할 수 없어 한 목표를 택했다면 다른 것을 포기해야 하는 상층 관계에 있는 상황 또는 그 상황 사이의 균형을 의미

의사 결정을 프레이밍

  • 성취해야 할 목표에 기반하여 일련의 원칙과 실천 사항을 정의하는 것으로 10개 미만이 좋음
  • 헤로쿠의 12가지 요소 -> www.12factor.net

모니터링

  • 서비스 간 경계를 넘어 시스템 상태를 일관되게 살펴볼 수 있어야 함
  • 서비스 세부 상태가 아닌 시스템 전체 상태를 볼 수 있어야 함
  • metric : 모든 서비스가 자기 상태와 일반적인 모니터링 관련지표를 동일한 방식으로 전송

핵심 요약

  • 아키텍트는 많은 것에 대해 책임을 진다.
  • 그들은 개발을 이끌 수 있는 일련의 원칙을 정하고,
  • 원칙들이 조직의 전략과 일치하도록 보장할 뿐만 아니라
  • 이 원칙들로 인해 개발자를 비참하게 만드는 실천 사항이 만들어지지 않도록 해야 한다.
  • 최신 기술을 유지하고, 올바른 트레이드오프를 결정해야 한다. 이는 실로 엄청난 책임이다.
  • 그뿐 아니라 아키텍트는 사람들과 함께 나아가야 한다.
  • 즉, 함께 일하는 동료들이 의사 결정을 이해하고 수행할 수 있도록 참여시켜야 한다.
  • 그리고 앞에서 언급한 것처럼 그들의 결정이 주는 파급력과 코드를 이해하기 위해 팀과 함께 시간을 보내야 한다.

3. 서비스 모델링하기

무엇이 좋은 서비스를 만드는가?

느슨한 결합(loose coupling)
강한 응집력(high cohesion)

과도한 커뮤니케이션은 잠재적인 성능 문제를 넘어 강한 결합을 초래 할 수 있음
특정 행위를 변경하고자 할 때는 한 곳에서 변경하고 가능한 한 신속하게 릴리스할 수 있어야 함
-> 서로 연관된 행위가 한 곳에 모이고, 다른 경계와는 가능한 한 느슨하게 소통할 수 있도록 우리 문제 영역내에서 경계를 찾자

경계가 있는 콘텍스트(bounded context)

  • 모든 도메인은 다수의 경계가 있는 콘텍스트로 구성
  • 각 콘텍스트 내에는 외부와 통신할 필요가 없는 것뿐만 아니라
  • 경계가 있는 다른 콘텍스트 외부와 공유되는 것
    • 경계가 있는 콘텍스트로 보이는 도메인 부분들을 생각해 볼 것

즉, 콘텍스트는 우리가 이야기하는 도메인(domain) 이 되는 것 같다.

  1. 세포가 존재할 수 있는 이유는
    세포막이 새포 내부와 외부에 있는 것을 구분하고, 어떤 것을 통과시킬지 결정하기 때문
    (크으.. 명언이다)

  2. 재무부서는 창고 내부의 세부 업무에 대해 세세하게 알 필요는 없지만
    재고 수준에 따라 장부 업데이트를 해야하므로 창고가 갖는 재고 품목 정보가 필요
    재고 품목은 두 콘텍스트 간의 공유 모델이 됨

같은 모델이지만 서로 다른 의미를 갖는 것

  • 고객 콘텍스트에서의 반품은 창고 콘텍스트에서의 도착할 패키지와 재입고될 재고 품목을 의미함
  • 하지만 재입고 요청은 창고 콘텍스트 내에서의 아주 내부적인 관심사일 뿐
  • 이에 우리는 어떤 모델을 공유하고, 어떤 내부 표현을 공유하면 안 되는지 명확히 고려해야 함
    • 다른 콘텍스트와 강한 결합을 필할 수 있음
  • 조직 내에 존재하는 경계가 있는 콘텍스트에 관해 고민할 때는
    • 공유 데이터 관점이 아닌 나머지 도메인을 제공하는 콘텍스트의 능력 관점에서 봐야 함
    • 이 콘텍스트는 무엇을 하는가?
    • 그 일을 하기 위해 어떤 데이터가 필요한가?

동일한 용어와 개념

  • 비즈니스 도메인에 기반을 둔 소프트웨어 모델링은 경계가 있는 콘텍스트 개념에 멈춰서는 안 됨
  • 조직 내에서 공유되는 동일한 용어와 개념은 인터페이스에 반영되어야 함
  • 마이크로서비스 간에 전송되는 형태를 조직 간에 전송되는 형태와 동일시하는 것은 아주 유용

4. 통합

우리 문제 영역에서 느슨한 결합높은 응집력의 이중 혜택을 가져다주는 접합부를 어떻게 찾는지 배웠다.
개발자에 의한 변경은 때로 서비스 소비자측의 변경까지 초래하는 결과를 가져올 수 있지만, 가능하면 이러한 변경을 일으키지 않는 기술을 선택하고 싶을 것이다.
서비스 통합에 필요한 좋은 기술을 선택하는 데 도움이 되는 몇 가지 지침이 있다.

고객 생성은 단순한 CRUD 명령의 집합으로 간주될 수 있다.
하지만 대부분의 시스템에서 그렇게 단순한 작업은 아니다.
새로운 고객이 등록되면 금융 결제 또는 환영 이메일과 같은 부가적인 프로세스를 시작해야 하고,
고객 정보를 변경하거나 삭제할 때는 또 다른 비즈니스 프로세스가 작동할 수 있다.

  • DB는 사실상 공유된 매우 큰 API로서 상당히 깨지기 쉬워, 대개 대규모의 회귀 테스트가 필요
  • 시간이 지나도 서비스 내부 변경 방식에 관한 자율성을 서비스에 줄 수 있도록
  • 소비자에게 서비스의 세부 구현이 은폐되기를 진심으로 원함
  • 그렇지 않으면 느슨한 결합과는 영영 이별
  • 좋은 마이크로서비스의 핵심 원칙은 강한 응집력과 느슨한 결합

동기 통신

원격 서버에 대한 호출이 완료될 때까지 연산 작업이 중단

  • 언제 작업이 성공적으로 완료되었는지 알 수 있어서 추론하기 용이
  • 요청/응답 스타일

요청/응답 스타일(request/response)

동기 통신 방식과 명확히 일치하지만, 비동기 통신에서는 콜백을 활용하여 작동할 수 있음

비동기 통신

호출자는 작업이 완료되었다는 회신을 기다리지 않으며, 심지어는 작업의 완료 여부에 관심이 없을 때도 있음

  • 클라이언트와 서버 간에 오랫동안 접속을 유지하기 어려운 장기 작업에 유용
  • 결과를 기다리는 동안 중단된 호출이 성능 저하를 일으키는 곳에서 짧은 지연시간이 필요할 때 적합
  • 이벤트 기반 협업

이벤트 기반 협업

  • 클라이언트는 완료되어야 할 작업을 요청하는 대신 이벤트가 발생했음을 알리고 다른 당사자들이 무엇을 해야 할지 알기 기대함
  • 우리는 결코 다른 누구에게도 해야할 일을 말하지 않는 것
  • 결합도가 매우 낮은 방식

오케스트레이션(orchestration) 방식

오케스트라 지휘자처럼 프로세를 안내하고 구동하는 하나의 중앙 두뇌에 의존

  • 고객 서비스에 지나치게 많은 중앙 관리 권한이 부여되는 단점
  • 웹 중간에서 허브가 되어 로직이 살아나는 중심점이 될 수 있음
  • 이 방식은 빈약한 CRUD 기반의 서비스에 할 일을 지시하는 소수의 똑똑한 신과 같은 서비스를 낳음

REST - REpresentational State Transfer

웹에서 영감을 얻은 아키텍쳐 방식으로 resource의 개념 이 가장 중요

  • 자원이 외부에 보여지는 방식과 내부에 저장되는 방식은 완전히 분리1
  • HTTP가 동사(verb)처럼 스펙의 일부로 우리에게 제공하는 몇몇 기능은 HTTP상의 REST를 쉽게 구현할 수 있게 함

HTTP

자체적으로 REST 방식과 궁합이 맞는 유용한 기능들을 정의

  • REST 아키텍처 방식은 실제로 메서드가 메서드가 모든 자원에 대해 같은 방식으로 동작
  • HTTP 사양서에는 우리가 사용할 수 있는 다수의 메서드가 정의 (GET/POST/PUT/DELETE 등)
  • GET : 멱등 방식등2으로 자원을 추출
  • POST : 새로운 자원을 생성
  • JSON은 HTTP상에서 작동하는 대중적인 콘텐츠 타입

HATEOAS

Hypermedia As The Engine Of Application Status
클라이언트와 서버가 결합하지 않게 도와주는 또 다른 원칙인 애플리케이션 상태 엔진

  • 클라이언트가 다른 자원에 대한 링크를 통해 서버와 (잠재적으로 상태 변이를 초래하는) 상호작용을 한다는 것
  • 어떤 URI를 요청했는지 알고 있으므로 서버 내 고객의 정확한 위치를 알 필요는 없음
  • 대신 클라이언트는 필요한 것을 발견하기 위해 링크를 찾고 탐색
HTTP는 대규모 트래픽에는 적합할 수 있지만 TCP 또는 다른 네트워킹 기술 기반의 대체 프로토콜과 비교하면
낮은 지연시간이 필요한 통신에는 그다지 좋은 선택은 아님

correlation ID/상관관계 ID

적재적소에서 모니터링하고 프로세스 경계 요청을 추적할 수 있도록 상관관계 ID의 사용을 적극 검토

고객 정보 변경에 관한 결정이 고객 서비스 외부에서 이뤄진다면 응집력을 잃은 것

Rx(Reactive Extension)

반응형 확장 라이브러리

  • Observer pattern에 기반을 두고 설계됨
  • 관찰 대상 순서를 이용하여 비동기 이벤트 기반의 반응형 프로그래밍을 지원하는 라이브러리
  • 다수의 호출 결과를 조회하고 그 결과에 따라 연산을 실행하는 메커니즘
  • 이들 호추른 그 자체로 blocking or nonblocking 호출이 될 수 있음
  • 하위 서비스에 대해 동시에 발생하는 호출들을 훨씬 쉽게 처리하면서 다수의 호출을 함께 조립할 수 있다는 것

내부적으로 Rx는 전통적인 흐름을 뒤집음

  • 데이터를 요청하는 대신 데이터에 대한 연산을 수행, 그 연산(또는 연산의 집합)의 결과를 관찰, 변경에 따라 반응
  • 일부 Rx 구현제를 통해 관찰 대상의 함수를 수행 할 수 있음
  • RxJava에서는 map과 filter같은 전통적인 함수가 수행 될 수 있음

여러분 시스템의 도처에 있는 중복된 행위를 변경하려 할 때 모든 것을 제대로 변경하기 어렵고 이는 버그로 이어질 수 있다.
따라서 일반적으로 DRY를 기도문으로 사용하는 것도 일리가 있다.

DRY(Don’t Repeat Yourself)

중복된 코드를 회피하는 시도로 단순하게 정의되지만, 더 명확하게 정의하자면 시스템의 행동양식과 지식의 중복을 회피하는 모든 시도

  • 반드시 피해야 할 위험 중 하나는 마이크로서비스와 소비자 간의 지나친 결합
  • 마이크로서비스 자체의 작은 변경 사항 하나가 많은 소비자에게 불필요한 변경을 초래 할 수 있음
  • 공유 코드의 사용이 이러한 결합을 만듬

공유 코드를 서비스 경계를 넘어서 사용한다면 잠재적인 결합의 문제를 안고 있는 셈

  • 하지만 로깅 라이브러리와 같은 공통 코드는 외부에서는 보이지 않는 내부의 개념이므로 사용해도 문제 없음
  • 코드를 공유하기보다는 결합이 생기지 않도록 그 템플릿을 새로운 서비스마다 복사

Semantic versioning

유의적 버전 관리. 클라이언트가 서비스의 버전 번호만 보고도 해당 서비스와 통합 가능한지 알 수 있는 명세
MAJOR.MINOR.PATCH 형태

  • MAJOR : 하위 호환성이 깨진 변경이 발생 했음
  • MINOR : 하위 호환성을 유지하면서 새로운 기능들이 추가되었음
  • PATCH : 기존 기능의 버그를 수정했다는 것을 의미

다수의 병행 서비스 버전 사용하기

다양한 버전의 서비스를 동시에 실행하고, 구 소비자의 트래픽을 구버전에, 신규 소비자의 신버전에 라우팅하는 것
단점

  • 한 서비스의 내부 버그를 고치려면 두 벌의 서로 다른 서비스를 수정하고 배포해야 함
  • 소비자가 찾는 서비스로 유도하기 위한 부가적인 로직이 필요
  • 서비스가 처리해야할 영속적 상태가 있는지 고려

API Gateway

  • 클라이언트에 개별 서비스를 액세스할 수 있는 단일 접근 지점
  • 클라이언트의 요청을 적절히 해당 서비스로 라우팅하거나 다양한 서비스로 분배
  • 클라이언트에 최적화된 API를 제공하고, 클라이언트의 인증 및 접근 제어를 가능하게 함

UI 부분 구성

  • 큰 단위의 UI 부분은 서버 측 애플리케이션으로부터 제공, 적절한 API 호출을 수행
  • UI 부분이 팀의 소유권과 완전히 일치할 때 가장 잘 작동
  • 예로, 뮤직 쇼핑몰에서 주문 관리를 담다하는 팀은 주문 관리와 연관된 모든 페이지를 구성해서 제공하는 것
  • 그러나 사용자 경험의 일관성 유지는 풀어야할 숙제

퍼사드 패턴(facade pattern)

  • 외부에 대한 내부 콘텐트 서비스를 추상황하는 용도로 쓰임
  • SOA 또는 Design Pattern에서는 이를 Service Facade 또는 Facade Pattern이라고 부름
  • 위키백과 - 퍼사드 패턴

통합과 관련된 여러 방안 정리

  • 데이터베이스 통합은 최대한 피할 것
  • REST와 RPC의 장단점을 이해하고 요청/응답을 통합하는 좋은 출발점으로 REST를 고려
  • 오케스트레이션보다는 코레오그래피를 우선
  • 포스텔의 법칙을 이해하고 관대한 독자 패턴을 사용해서 호환성을 깨트리는 변경과 불필요한 버전을 피할 것
  • 구성 꼐층으로서의 사용자 인터페이스를 고려

5. 모놀리스 분해하기

모놀리스는 시간이 흐르면서 자라나고,
빠른 속도로 새로운 기능과 코드 라인을 요구하며,
머지않아 조직 내 사람들이 건드리거나 바꾸기를 두려워하는 거대하고 무서운 존재가 된다.

좋은 접합부란?

  • 경계가 있는 콘텍스트(bounded context)
  • 조직 내의 응집력 있고, 느슨히 결합된 경계를 잘 표현

리팩토링

  • 현대적 IDE에서 코드 이동은 리팩토링 기능을 통해 다른 작업 중에 자동적이고 점진적으로 이뤄질 수 있음
  • 하지만 코드 이동에 따른 오류를 잡아내기 위해 여전히 테스트가 필요
  • 시간이 지나면서 우리는 잘 어울려 남아 있는 코드와 그렇지 못한 코드를 알아가기 시작
  • 대게 끝까지 생존한 코드가 우리가 간과했을지 모를 경계가 있는 콘텍스트로 인식될 수 있음
    • 서비스를 분리하기 전에 모든 코드를 도메인에 따라 나눠진 패키지들에 따라 정렬할 필요는 없다
    • 한번에 모든 것을 바꾸려는 빅뱅(Big-bang) 접근법을 취할 필요는 없고, 이 과정을 천천히 조금씩 진행되는 것으로 인식
    • 뒤엉킨 모든 의존성의 출처가 대게 데이터베이스라는 것

외부 키 관계 깨뜨리기

  • 특정 콘텍스트의 코드 내에 데이터베이스 맵핑 코드를 함께 배치하면 어떤 코드가 데이터베이스의 어느 부분을 사용하는지 이해할 수 있음
  • 예를 들어 경계가 잇는 콘텍스트 단위의 맵핑 파일과 같은 것을 사용한다면 하이버네이트에서는 매우 명확
    • 스키마스파이(SchemaSpy) : 테이블 관계를 그래픽으로 표현하는 도구
  • 이 모든 것은 궁극적으로 서비스 경계로 확장될 수 있는 테이블 간의 결합을 이해하도록 해줌
  • 보고서를 생성하기 위해 서로 다른 두 개의 데이터베이스에 호출해야 하는 것은 분명하며 옳은 것

공유 데이터 분리

  • 각 패키지에 복제, 장기적으로 보면 그 테이블은 각 서비스 내부에서도 복제 될 수 있음
  • 공유 정적 데이터를 코드로 다루는 것
  • 서비스의 부분으로 배포되는 속성 파일에 저장되거나,
  • 열거형 개체(enumeration)가 될 수 있음
  • 동작 중인 데이터베이스 테이블을 변경하는 것보다 설정 파일을 변경하는 것이 용이하나 데이터 일관성에 대한 문제는 여전히 존재

트랜잭션의 경계

  • 애플리케이션 코드를 완전히 불리하여 각각의 마이크로서비스로 만들기 전에,
  • 서비스는 이전과 같이 하나로 유지한 채 우선 스키마 분리를 추천
  • 서비스를 단계적으로 분리
  • 연산의 일부를 큐나 로그 파일에 큐잉하여 나중에 재시도 할 수 있음

보상 트랜잭션(compensating transaction)

  • 직전의 트랜잭션을 되돌릴 새로운 트랜잭션을 발생시키는 것

분산 트랜잭션(distributed transaction)

  • 보상 트랜잭션을 수동으로 통제하는 방식의 대안
  • 2단계 커밋(two-phase commit)

리포팅 데이터베이스

  • 일반적인 모놀리식 서비스 아키텍처에서 모든 데이터는 거대한 단일 데이터베이스에 저장됨
  • 모든 데이터가 한 곳에 모여 있어서 모든 정보의 경계를 넘어서 리포팅하는 것이 실제로 매우 쉽다
  • SQL 질의와 그와 유사한 것들을 통해 데이터를 쉽게 조인할 수 있기 때문
  • 리포팅 질의가 메인 시스템의 성능에 영향을 주는 것을 우려하여
  • 리포트를 메인 데이터베이스에서 실행하지 않을 것
  • 이에 리포팅 시스템은 대게 읽기용 복제 데이터베이스(read replica)에 연결됨

서비스 호출을 통한 데이터 추출

  • 데이터베이스 스키마는 실행 중인 모놀리식 서비스와 리포팅 시스템 사이에서 사실상 공유 API임
  • 스키마의 변경은 조심스럽게 관리되어야 하며, 실제로 이것은 스키마를 변경하고 조율할 기회를 줄이는 방해물
  • 실제 시스템 또는 리포팅 시스템을 지원하는 사용 사례를 위해 데이터베이스를 최적하는 방법은 제한적
  • 데이터 구조 변경이 실행 중인 시스템에 악영향을 주더라도 리포팅을 빠르게 하기 위해 데이터를 다르게 구성할 수 없음
  • 스키마가 한 사용 사례에는 훌륭하게 들어맞지만 다른 사례에는 그렇지 못하거나 두 사례의 목적과 부합하지 않아 최소한의 공통분모만 가지게 되는 것
  • 일반적인 관계형 데이터베이스가 많은 리포팅 도구와 호환되는 SQL 질의 인터페이스를 제공하더라도 동작 중인 서비스에 데이터를 저장하기 위한 최선의 방법은 아님

데이터 덤프

  • 리포팅 시스템이 데이터를 끌어오는 방식 대신 리포팅 시스템에 데이터를 밀어 넣는 방식을 시도할 수 있다.
  • 일반적인 HTTP 호출로 데이터를 추출하는 데 있어 단점 중 하나는 다수의 호출을 할 때 발생하는 HTTP의 부하고
  • 리포팅 목적으로만 사용될지도 모르는 API를 만들어야 하는 부담이다.
  • 같은 데이터의 소스인 서비스의 데이터베이스에 직접 접근하여 리포팅 데이터베이스로 밀어 넣는 독립 프로그램을 가지는 것

데이터마트
  • AWS S3를 실제로 거대한 데이터 마트로 위장하며, JSON 파일을 S3에 저장하기 위해 데이터 펌프를 사용함
  • 솔루션이 확장이 필요할 때까지 아주 효과가 있었고, 엑셀과 태블로 같은 표준 리포팅 도구와 통합할 수 있는 큐브를 채우도록 이 펌프들을 변경하는 것을 검토

이벤트 데이터 펌프

  • 고객 서비스가 상태가 바뀌면 상태 변이 이벤트가 발행되고 고객 리포팅 맵퍼를 통해 중앙의 리포팅 데이터베이스로 펌프 됨

백업 데이터 펌프

넷플릭스

  • 카산드라 데이터를 백업하기 위해 데이터 파일을 복사해서 안전한 곳에 저장
  • SStable로 알려져있는 이런 파일들을 S3 객체 저장소에 저장
  • 이 백업된 데이터를 원본으로 사용하는 하둡을 통해 방대한 양의 데이터를 처리할 수 있는 파이프라인을 구현, 아이기스토스 프로젝트로 오픈소스화 됨
  • 하지만 데이터 펌프처럼 이 백업 데이터 펌프 패턴 역시 리포팅 스키마와 결합

변경 비용

  • 데이터베이스를 분리하는 것은 더 많은 작업이 필요
  • 데이터베이스 변경을 되돌리는 것은 복잡한 일
  • 서비스들이 지나치게 결합된 통합을 분리하는 것 또는 다수의 소비자가 사용하는 API를 완전히 재작성하는 것은 상당히 큰 작업
  • 높은 비용이 드는 변경은 이들 작업이 점점 더 위험해진다는 것

화이트 보드를 활용하여 디자인을 스케치, 서비스 경계를 넘어 실행할 때 어떤 일이 발생하는지 확인

  • 어떤 출이 발생하는가?
  • 이상한 순환 참조를 볼 수 있는가?
  • 지나치게 호출이 많은 두 서비스를 발견했는가?

+ Words

  • 코드베이스/codebase
    • 소프트웨어 시스템, 애플리케이션, 컴포넌트를 빌드하는 데 사용되는 코드의 전체 집합
    • 일반적으로 작성한 코드 파일
  • 결함 감내 시스템/fault tolerant system
    • 일부 장치나 서브시스템에 고장이나 오작동이 나타나면 시스템의 성능과 기능을 축소 구성하여 정지하지 않고도 동작을 유지하는 방식을 사용하고 있는데 이 방식을 단계별 성능 저하(graceful degradation)
  • 팩토링/factoring - 분해/decomposition
    • 이해하고, 작성하고, 유지하기 쉽도록 복잡한 문제와 시스템을 외부 동작의 변경 없이 부분으로 나누는 것
  • 브르어(Brewer)의 정리
    • 일관성/consistency
    • 가용성/availability
    • 분할 내성/partition tolerance
    • 모두를 만족하는 분산 시스템이 존재하지 않음을 증명하는 정리
  • callback
    • 다른 코드의 인수로 넘겨주는 실행 가능한 코드
    • 콜백을 넘겨받는 코드는 이 콜백을 필요에 따라 즉시 실행할 수도 있고 나중에 실행할 수도 있음
  • 원격 프로시저 호출(remote procedure call/RPC)
    • local call을 통해 원격 서비스를 실행하는 기술
  • load balancer
    • 부하 분산기
  • payload
    • 전송의 근본적인 목적이 되는 데이터의 일부분으로, 해당 데이터와 함께 전송되는 헤더와 메타데이터 등의 데이터는 제외
  • handshake
    • 두 개체간의 정상 통신 전에 통신 채널의 파라미터를 설정하는 자동화된 협상 과정
  • tolerant reader pattern/관대한 독자 패턴
    • 서비스 디자인 패턴 중의 하나
    • 서비스 공급자가 제공한 메시지 포맷은 변경될 수 있음을 염두에 두고 메시지의 필요한 데이터만 추출하며 관련 없는 데이터는 무시해서 변경 결함을 피하게 함
  • RabbitMQ
    • AMQP 프로토콜을 구현한 오픈 소스 메시지 중개자 소프트웨어
    • 얼랭 언어 기반으로 구현하여 클러스터링 등의 고급 기술과 다양한 언어의 클라이언트 라이브러리를 지원
  • Competing Consumer pattern
    • 메시지를 위해 경쟁하는 다수의 작업자 인스턴스를 다루는 방법을 기술
  • bootstrapping
    • 일반적으로 컴퓨터의 전원이 켜지거나 리셋된 후 외부 입력 없이 기본 소프트웨어를 메모리에 로드하여 독립 수행하는 과정
  • 접합부
    • seam
  • structure101
    • 애자일 아키텍처 개발 환경으로, 코드베이스의 구조화를 돕기 위해 다양한 IDE를 위한 플러그인을 제공
  • SKU(Stock Keeping Unit)
    • 개별 상별 상품에 대해 재고 관리 목적으로 추적이 쉽도록 하기 위해 사용하는 식별 관리 코드
  • Cassandra
    • 컬럼 지향 데이터베이스(column-oriented database)로 대용량 확장이 매우 용이한 리포팅 시스템에 적합
    • 컬럼 지향 데이터베이스는 데이터를 열 단위로 저장

  1. 다양한 REST 방식을 비교한 Richardson Maturity Model을 참고
  2. 동일하게 반복되는 요청에 결과가 달라지지 않는 성질


쿠팡 파트너스 활동을 통해 일정액의 커미션을 제공받을 수 있습니다.