소프트웨어-이야기/아키텍처 썸네일형 리스트형 Server Driven UI: SDUI 1. SDUI의 등장 배경과 정의왜 SDUI인가?기존의 앱 개발 방식은 UI 로직이 클라이언트(App)에 종속되어 있다.기능을 수정하려면 [코드 수정 -> 빌드 -> 스토어 심사 -> 유저 업데이트]라는 긴 과정을 거쳐야 한다.하지만 비즈니스는 실시간으로 변한다."갑작스러운 이벤트 배너를 상단에 배치해야 한다면?""A/B 테스트를 위해 특정 유저에게만 다른 레이아웃을 보여주고 싶다면?"이런 요구사항에 즉각 대응하기 위해 등장한 것이 바로 Server-Driven UI이다.정의SDUI는 이름 그대로 서버가 UI의 구조와 데이터를 결정하고, 클라이언트는 이를 해석하여 화면에 그리는(Rendering) 방식을 의미한다. 서버는 "어떤 데이터를 보여줄지"뿐만 아니라 "어떤 컴포넌트를 어떤 순서로 배치할지"에 대.. 아고다 사례로 살펴본 예약 엔진: Dynamic Graph, Risk Profiler 아고다에서는 Multi-Product Booking Engine (MPBE)이라고 부르는 예약 엔진을 운영하고 있다. 포스팅에 언급된 Dynamic Graph, Risk Profiler 기능을 정리하고자 한다.Multi-Product Booking Engine아고다는 여행 상품 종류가 점점 다양해지면서, 이를 똑같은 방식으로 처리하는 기존 예약 엔진으로는 한계가 있었다고 한다. 그래서 속도나 안정성을 포기하지 않으면서도, 복잡한 흐름을 유연하게 제어할 수 있는 구조가 필요했다고 한다. 이에 아고다는 비동기 에이전트가 동작하는 그래프 기반 아키텍처를 도입했다고 소개한다.예약 과정에서 발생하는 재고 확인, 사기 탐지, 결제 승인 같은 절차를 작은 단계로 분리하고, 각 상품의 특성에 따라 다른 방식으로 조합할.. 시스템 설계 스터디 진행기 최근 커뮤니티를 통해 시스템 설계 스터디를 진행했다.스터디장으로 스터디를 준비하고, 진행했던 과정을 기록하고자 한다. 1. 그라운드룰 정하기 GITHUB PR Template 샘플## Checklist - [ ] README 파일에 다음 요소가 모두 포함되어있는지 확인합니다. * Requirements * Functional * Non-Functional * Estimates * Design * API * Reference - [ ] 해당 기술이 활용되는 사례를 생각해봅니다. - [ ] 참고하기 좋은 포스팅 사례를 찾아봅니다. - [ ] 함께 고민해보고 싶은 주제나 키워드를 생각해봅니다. 2. 스터디 주제 선정하기 systemdesignfi.. <김용욱> 마이크로서비스 아키텍처 구축 가이드: 설계원칙 서비스의 의존관계 코드 레벨의 참조 코드 레벨의 참조는 다른 서비스의 API나 이벤트 정의를 따르는 것이다. 참조하는 서비스의 스펙이 변경되면, 자신도 같이 변경되어야 한다. 런타임 레벨 참조 실행 중에 다른 서비스의 API나 이벤트를 호출하는 것이다 런타임 레벨에서 다른 서비스의 기능을 호출한다면, 해당 서비스에 장애가 발생했을 때 영향을 받을 수 있다. 설계원칙 (1) 참조 방향을 역전하자! 코드 레벨의 참조와 런타임 레벨의 참조는 보통 동일한 방향을 가진다. 하지만 코드 레벨의 참조를 역전시키는 경우, 둘의 방향이 반대가 된다. 예제로 살펴본 참조의 역전: Callback API callback API가 코드 레벨 참조와 런타임 레벨 참조의 방향이 바뀌는 대표적인 사례이다. Payment serve.. <김용욱> 마이크로서비스 아키텍처 구축 가이드: 프론트엔드 마이크로 서비스 아키텍처 5.1.3 프론트엔드 마이크로 서비스 아키텍처 프론트 도메인 분리하기 프론트엔드를 여러 도메인 별로 분할해야하는 경우가 있다. 프론트엔드 팀의 규모가 지나치게 큰 경우다. 이 경우, 개발 생산성이 낮아지고, 테스트와 배포가 어려워진다. 도메인 별로 팀을 묶어두었으나, 프론트엔드 애플리케이션은 1개인 케이스다. 이렇게 되면 팀 별로 독립적인 배포가 어려워진다. UI 조합하기 화면을 도메인 별로 분리하고 난 이후에는, 분리된 화면을 연결해줄 수 있는 방법이 필요하다. 크게 두가지 방법이 있다. 분리된 UI를 조합하는 심플한 방법은 HTML 링크를 사용하는 것이다. 서비스마다 별도의 사이트를 두고, 메뉴를 선택할 때 해당 사이트로 전환한다. 각 서비스는 같은 인증 체계를 갖고 있어서, 별도의 로그인 없.. 개발자를 위한 최소한의 인증 시스템 지식: Oauth2.0 + HTTP JWT 인증에 필요한 정보를 암호화한 Token이다. JWT 구성을 살펴보자. JWT은 3가지 구성요소로 나뉜다. 각 구성영역은 토큰의 점으로 구분된다. header payload signature JWT이 등장한 배경 요구사항 로그인을 하려면 아이디와 패스워드가 필요하다. 그리고 로그인을 일정 시간동안 유지해야한다. 아이디와 패스워드를 매번 보내주려면, 어딘가에 이 정보를 저장해야한다. 대안 (1) 아이디와 패스워드를 API를 요청할 때마다 전달하기 아이디와 패스워드를 사용자에게 매번 입력받는 것은 무리이다. 그래서 클라이언트 저장소에 아이디와 패스워드를 저장해서, 매번 전달해야한다. 쿠키에 아이디, 패스워드를 저장해서 전달하는 안이 있다. 그러나 개인 민감정보가 쿠키에 담겨있는 것은 보안상 안전하지 .. Service Aggregator VS BFF 애플리케이션 아키텍처 패턴으로 Service Aggregator와 BFF가 있다. 둘이 비슷한듯 다른데, 그 차이점을 이해해보자. Service Aggregator은 여러 MSA 호출을 조합하는 오케스트레이션 역할을 하는 서버를 말한다. Backend For Front은 UI에 친화적인 응답을 만드는 서버를 말한다. 그래서 Mobile/PC 별로 다른 화면을 위한 BFF도 존재할 수 있다. BFF도 여러 API을 호출한다는 점에서 Service Aggregator와 공통점이 있다. 그러나 사용하는 목적이 다르다는 점에서 차이가 있다는 생각이 든다. [EDA] 이벤트 발행하기 애플리케이션에서 이벤트를 발행하는 방법은 크게 Application layer event와 Persistence layer event으로 나뉜다. Application layer event 애플리케이션 안에서 명시적으로 이벤트를 발행하는 방법이다. 장점은 원하는 시점에 이벤트를 발행할 수 있다는 것이다. DB에 데이터가 적재되지 않는 상황에서도 이벤트를 발행할 수 있다. 단, 도메인과 DB가 명시적으로 분리되어있는 경우에만 사용가능하다. 만약 도메인과 DB를 다른 애플리케이션에서 사용하고 있는 경우, 이벤트를 감지하지 못하는 상황이 발생할 수 있다. Persistence layer event 데이터 저장소를 활용하여 이벤트를 발행하는 방법이다. CDC가 대표적인 예이다. 이 방법은 도메인/DB가 분리되어.. 이전 1 2 3 다음
