아키텍처

아키텍처

    Backend For Frontend는 무엇인가?

    최근에 BFF에 대해서 공부를 해 보아야 할 필요성을 느껴서 블로그에 정리해 보았다. BFF에 대한 설명을 하기 전에 먼저 MSA에 대해서 이야기를 해 보려고 한다. MSA MSA는 작은 자율 서비스 컬렉션으로 구성된다. 각 서비스는 독립적이며 제한된 컨텍스트 내에서 단일 비즈니스 기능을 구현해야 한다. 제한된 컨텍스트는 비즈니스 내의 자연스러운 분할이며 도메인 모델이 존재하는 명시적 경계를 제공한다. 마이크로 서비스란 다음과 같은 특성을 가지고 있다. 작고, 독립적이며, 느슨하게 결합되어 있다. 각 서비스는 작은 개발팀이 관리할 수 있다. 서비스를 독립적으로 배포할 수 있다. 팀이 전체 어플리케이션을 빌드한 후 재배치하지 않고도 기존 서비스를 업데이트 할 수 있다. 서비스가 잘 정의된 API를 사용하여..

    [소프트웨어 아키텍처 101] Ch06. 아키텍처 특성 측정 및 거버넌스

    6.1 아키텍처 특성 측정 아키텍처 특성을 정의할 때 흔히 다음과 같은 문제들이 발생한다. 물리학이 아니다 : 아키텍처 특성은 대부분 의미가 모호하다. 정의가 너무 다양하다 : 부서마다 정의를 통일하기 전까지는 원활한 소통이 어렵다. 너무 복합적이다 : 바람직한 아키텍처 특성은 대부분 더 작은 다른 여러 특성들로 구성된다. 이 세가지 문제들은 아키텍처 특성을 객관적으로 정의하면 모두 해결된다. 6.1.1 운영적 특성 아키텍처 특성은 성능, 확장성처럼 비교적 정확하게 측정할 수 있는 것도 많지만, 팀 목표에 따라 그에 따른 해석은 미묘하게 갈릴 때가 많다. 예를 들어 특정 요청에 대한 평균 응답 시간을 측정할 경우, 어떤 경계 조건 때문에 1%의 요청이 다른 요청보다 처리 시간이 10배 오래 걸리면 어떻게..

    [소프트웨어 아키텍처 101] Ch04~05. 아키텍처 특성 정의, 식별

    4. 아키텍처 특성 정의 아키텍트는 개발팀과 함께 도메인 또는 비즈니스 요구사항을 정의할 수 있지만, 주로 소프트웨어로 처리할 일 중 도메인 기능과 직접적인 관련이 없는 모든 것들, 즉 아키텍처 특성(architectural characteristic)을 정의, 발견, 분석하는 일을 수행한다. 아키텍처 특성은 다음 세 가지 기준을 충족한다. 비도메인(nondomain) 설계 고려 사항을 명시한다. 어플리케이션 설계 시 어플리케이션으로 처리할 일은 구체적인 요구사항으로 정리한다. 아키텍처 특성은 이 요구사항을 구현하는 방법, 어떤 선택을 하게 된 이유와 관련된 운영/설계 기준을 명시한다. e.g. 일반적으로 어느 정도의 어플리케이션의 성능은 중요한 아키텍처 특성이지만, 요구사항 정의서에는 적혀있지 않는 경..

    [소프트웨어 아키텍처 101] Ch03. 모듈성

    플랫폼마다 제공하는 코드 재사용 메커니즘은 제각각이지만, 연관된 코드를 모듈(module)로 묶는 방법은 모두 지원한다. 본인이 선택한 개발 플랫폼에서 모듈성과 그것을 구현한 수 많은 코드를 이해하는 것은 아키텍트에게 대단히 중요한 일이다. 우리가 아키텍처를 분석해야 할 (메트릭, 피트니스 함수, 시각화 등) 많은 도구가 이 모듈성에 기반하기 때문이다. 모듈성은 일종의 구성 원리(organizing principle)이다. 아키텍트가 대충 아무렇게나 조각들을 이어 붙여 시스템을 설계하면 무수한 난관에 봉착해 옴짝달싹 못 하는 시스템이 되어 버린다. 물리학에 비유 하자면, 소프트웨어 시스템은 엔트로피(entropy, 무질서)가 증가하는 방향으로 움직이는 복잡한 시스템을 모델링한다. 질서를 유지하려면 물리적..

    [소프트웨어 아키텍처 101] Ch02. 아키텍처 사고

    아키텍처의 사고는 크게 네 가지로 나뉜다. 아키텍처와 설계의 차이를 이해하고 아키텍처 작업을 진행하면 개발팀과 어떻게 협력해야 할지 아는 것 어느 정도 기술의 깊이를 유지하면서 폭넓은 기술 지식을 확보하는 것 아키텍트는 다른 사람들이 보지 못하는 해결책과 가능성을 떠올릴 수 있다. 다양한 솔루션과 기술 간의 트레이드오프를 이해하고, 분석하고 조율하는 것 비즈니스 동인(business driver)의 중요성을 이해하고 그것을 아키텍처 관심사로 해석할 줄 아는 것 2.1 아키텍처 대 설계 아키텍트처럼 사고한다는 건 비즈니스와 기술 문제를 해결하기 위해 아키텍처와 설계의 차이점을 알고 이 둘을 긴밀하게 통합한 솔루션을 모색하는 것이다. 전통적인 아키텍트의 책임과 개발자의 책임은 다음과 같다. 이 전통적인 아키..

    [소프트웨어 아키텍처 101] Ch01. 서론

    을 읽고 챕터별로 주요한 내용들을 간략하게 정리해 보려고 한다. Ch01. 서론 10년 전만 해도 소프트웨어 아키텍트는 주로 모듈성(modularity), 컴포넌트(component), 패턴(pattern) 등 순수 기술적인 부분을 다루었지만, 이제는 (마이크로서비스처럼) 훨씬 폭 넓은 능력을 활용하는 새로운 아키텍처 스타일의 등장으로 인해 그 역할과 범위가 한층 더 확대되었다. p26 1.1 소프트웨어 아키텍처란? 소프트웨어 아키텍트는 이렇게 끊임없이 변하는 생태계 안에서 뭔가 결정을 내리는 사람들이다. 아키텍처를 공부하는 사람들이 명심해야 할 점은, 아키텍처란 예술과 마찬가지로 콘텍스트(context, 문맥, 맥락)로서만 이해할 수 있다는 것이다. 20세기의 아키텍처의 주요 목표 중 하나는 최대한 효..

    Docker #6. 스웜을 사용한 실전 어플리케이션 개발 - Part1

    이번 포스팅은 책의 CH04. 스웜을 이용한 실전 어플리케이션 개발 내용을 공부하고 정리한 내용이다. 도커를 사용하여 어플리케이션을 개발하는 흐름을 이해하고 스웜을 이용한 배포에 초점을 맞추어서 자세한 코드를 다 확인하면서 가지는 않음을 미리 명시한다. 아키텍처 구성 간단한 TODO App을 만들어 보려고 한다. 대략적인 아키텍처는 다음과 같다. 데이터베이스로는 MySQL, API는 Restful API(예제 코드는 Go 언어 기반), 웹 어플리케이션(Vue / React), Nginx 프록시 서버 이렇게 네 가지로 크게 구분해서 구성 요소를 생각해 볼 수 있다. Nginx의 경우 어플리케이션 프론트엔드 서버 및 API 앞단의 리버스 프록시 역할을 하며, 캐싱이나 라우팅 등에도 사용이 된다. 이전 포스팅..

    <GoF의 디자인패턴> 1. 서론

    요즘에 실무에서 프론트엔드 개발을 하기 시작하면서, 과거에 혼자서 프로젝트를 할 때와 다른 점들이 몇 가지가 보이기 시작했다. 그 중에 하나가 디자인 패턴인데, 아직도 나는 디자인 패턴을 왜 써야 하고 또 잘 쓰려면 어떻게 써야 하는지에 대해서 잘 모른다. 그래서 주말에 조금씩 디자인 패턴을 공부해 보기로 했다. 교재는 이고 디자인 패턴 관련된 책 중에서 오랫동안 많은 사람들한테 읽혀진 책 중 하나이다. 책의 내용을 정리하면서, 최근에 추가되거나 수정된 내용들을 적절하게 업데이트 하는 식으로 공부 및 포스팅을 작성해 보려고 한다. 개발자들은 혼자서 프로젝트를 하는 경우보다 여럿이 함께 하는 경우가 훨씬 더 많다. 그리고 혼자 하더라도 그 사람이 처음부터 끝까지 프로젝트를 책임지고 한다는 보장은 없다. 그..