본문 바로가기

Concepts124

Timeout - 개요 Timeout은 예상되는 시간내에 결과를 받지 못할 경우 오류 상황으로 간주하는 패턴이다. 사실 설명이 필요할까 싶을 정도로 널리 그리고 거의 필수적으로 사용되는 패턴이다. 하지만 그렇다고해서 중요하지 않은것은 아니다. 서비스들이 연쇄적으로 호출관계를 가질 때, timeout을 적용하지 않는다면 하나의 서비스만 장애가 나도 이를 연쇄적으로 호출했던 서비스들은 무한대기를 하게된다. 이때 timeout을 적용하면 하나의 서비스 장애가 전체 시스템 장애가 되는 상황을 방지할 수 있다. - Golang example 간단한 패턴인만큼 곧바로 golang 예제를 살펴보자. 사실 golang 에서는 첫번째 인자로 권장하는 context.Context 덕분에 구현이 굉장히 용이한편이다. func TestTi.. 2023. 11. 11.
Throttling - 출처: https://learn.microsoft.com/en-us/azure/architecture/patterns/throttling Throttling pattern - Azure Architecture Center Control the consumption of resources used by an instance of an application, an individual tenant, or an entire service. learn.microsoft.com - 개요 어플리케이션 인스턴스, 개인 테넌트나 전체 서비스에 의해 사용되는 자원의 소비량을 제어한다. 리소스에 로드가 많이 걸리는 상황에서도 시스템이 계속해서 동작하고 서비스 수준 계약을 충족하도록 해준다. - Context and pr.. 2023. 11. 4.
Retry - 출처: https://learn.microsoft.com/en-us/azure/architecture/patterns/retry Retry pattern - Azure Architecture Center Learn how to use the Retry pattern to enable an application to handle anticipated, temporary failures when the app tries to connect to a service or network resource. learn.microsoft.com - 개요 Application이 서비스나 네트워크 리소스에 접속할 때, 실패한 연산을 재시도 함으로써 일시적인 오류를 다룰 수 잇게 해주는 패턴이다. Application의.. 2023. 10. 31.
Debounce - 출처: 클라우드 네이티브 패턴 - 개요 Debounce는 함수 호출 빈도를 제한하여 여러 번 호출 발생시 처음이나 마지막 호출만 동작하도록 하는 패턴이다. - Context and Problem 시스템의 작업중에서는 속도가 느리고 비용이 많이 드는 작업이 존재한다. 이런 유사한 작업이 연속적으로 여러 번 발생할때마다 서버가 요청을 처리하면 무거운 작업을 계속 수행해야 한다. - Solution Front-end 개발을 해본적이 있다면 Debounce나 Throttle이라는 용어가 익숙할것이다. 가장 대표적인 예제가 자동완성검색이다. 이를 구현할 때 검색창에 입력 이벤트가 발생할때마다 요청을 서버로 보내면, 서버의 부하가 많이 걸릴 수 있다. 그래서 Debounce 패턴을 이용하여 일정 기간내의 마지막.. 2023. 10. 30.
Circuit Breaker 출처: https://learn.microsoft.com/en-us/azure/architecture/patterns/circuit-breaker Circuit Breaker pattern - Azure Architecture Center Handle faults that might take a variable amount of time to fix when connecting to a remote service or resource. learn.microsoft.com - 개요 Circuit Breaker는 원격 서비스나 자원에 접근할 때 오류가 발생하는 경우 복구에 어느 정도 시간이 걸리는지 알 수 없는데, 이런 경우를 다루는데 유용한 패턴이다. Application의 안정성과 탄력성을 향상 시킨다... 2023. 10. 27.
Cloud Native의 구성요소 - 출처: 클라우드 네이티브 GO - 매튜 A. 티트뮤스 지음 - 확장성 (Scaleability) 요청량이 급격하게 증가했을 때 대응하는 시스템의 능력을 말한다. 수직적 확장(Vertical scaling, Scale up): 시스템의 할당된 하드웨어 자원을 늘리는것을 말한다. 예를 들어 DB 서버의 경우 성능 향상을 위해 메모리를 늘린다면 이는 수직적 확장에 해당한다. 직관적이고 관리가 쉽지만 요청량이 아주 커지면 한계점이 존재한다. 수평적 확장(Horizontal scaling, Scale out: 인스턴스를 추가하는 방식을 말한다. 늘어난 요청량을 처리하기 위해 장비 Node를 늘린다면 이는 수평적 확장에 해당한다. 관리가 어렵지만 서비스 규모가 아주 커진다면 수평적 확장은 피할 수 없다. 수평적.. 2023. 10. 10.
DDD - 개념적 윤곽 - 출처: 도메인 주도 설계 - 에릭 에반스 - 개념적 윤곽(Conceptual contour) 코드를 개발하다보면 유연하게 조합할 수 있도록 작은 크기로 기능을 나누기도 하며, 복잡성을 캡슐화하기 위해 기능을 더 큰 단위로 통합 하기도 한다. 이런 방법들은 지나치게 단순해서 일반 원칙으로 적용하기에는 부적절하다. 하지마 이런 방법들은 문제를 해결하기 위한 동기를 부여한다. 모델 혹은 설계를 구성하는 요소가 모놀리식 구조이면 기능이 중복되어 클라이언트는 인터페이스로부터 유용한 정보를 일부만 파악가능하다. 반대로 클래스와 메소드를 잘게 나누면 작은 객체들의 협력 방식을 이해하고 있어야 하기 때문에 클라이언트 객체가 무의미하게 복잡해진다. 도메인에는 잠재적인 일관성이 존재한다. 특정 모델을 발견하면 나중에 .. 2022. 10. 31.
DDD - Assertion - 출처: 도메인 주도 설계 - 에릭 에반스 - 개요 복잡한 계산을 하는 부분은 앞서 살펴본 side effect free function 으로 분리하면 문제의 난이도를 낮출 수 있다. 하지만 여전히 부수효과가 있는 명령(command)는 Entity 에 남아있으며 개발자는 이런 명령의 영향력을 이해해야 한다. 단순한 명령의 경우 코드를 조사하는것만으로도 결과를 예측할 수 있다. 하지만 앱의 규모가 커지면 작은 부분을 조합하여 큰 부분을 구성하는 설계가 등장하기 마련이고, 이럴 경우 사용자가 하나의 명령을 호출하면 다른 명령을 호출하게 된다. 이렇게 되면 각 호출되는 명령을 이해해야 해서 캡슐화가 깨지게 된다. 내부를 조사하지 않고 설계 요소의 의미와 연산 실행결과를 이해하는 방법이 필요하다. 이를 "단.. 2022. 10. 22.
DDD - Side effect free function - 출처: 도메인 주도 설계 - 에릭 에반스 - 연산과 함수 연산은 명령(command, modification)과 질의(query)로 나눌 수 있다. 명령(command, modification): 변수값을 변경해서 시스템의 상태를 변경 질의(query): 변수안에 저장된 데이터에 접근하고, 저장된 데이터를 기반으로 계산을 수행 함수는 부수효과를 일으키지 않고 결과를 반환하는 연산이다. 여러번 호출 해도 무방하며 매번 동일한 값을 반환한다. - 명령과 질의의 분리 명령과 질의는 서로 엄격하게 다른 연산으로 분리해야 한다. 변경을 발생시키는 메서드는 도메인 데이터를 반환하지 않고 단순하게 유지해야 한다. 또는 명령과 질의를 분리하는 대신 연산의 결과를 표현하는 새로운 VO(Value-Object)를 생성.. 2022. 10. 22.
DDD - Inteface - 출처: 도메인 주도 설계 - 에릭 에반스 - Intention Revealing Interface (의도를 드러내는 인터페이스) Interface는 Client 개발자가 객체를 효과적으로 사용하기 위해 알아야할 정보를 추상화하고 있다. 그래서 Interface가 제대로 작성되어 있지 않으면 Client 개발자는 사용하려고 하는 개체에 대한 세부사항을 아주 세밀하게 알고 있어야 한다. Client 개발자의 머릿속이 이런 구현 세부사항들로 넘처나게 되면 해결해야 할 비즈니스 문제를 집중해서 해결할 수 없다. 객체의 캡슐화 가치가 떨어지게되는것이다. 클래스나 연산이름을 지을때에는 수행 방법이 아닌 결과와 목적만을 표현해야 한다. TDD 를 잠깐이라도 접해본적이 있다면 구현하지도 객체에 대해 Test cod.. 2022. 10. 1.

티스토리툴바