이 자리를 마련해주신 K-Devcon 2025 커뮤니티 여러분께 진심으로 감사드립니다.

이번 발표는 조금 더 먼저 경험한 선배가 후배들을 위해 나누는 이야기라고 생각해 주시면 좋겠습니다. 부담 없이 편하게 들어주시면 감사 하겠습니다.

발표 주제는 대규모 데이터를 직접 계산하지 않고도 효과적으로 추정(Sketches)하는 기법에 관한 것입니다.

본 내용은 대기업(삼성전자 MX, 삼성 SDS 아키텍트 과정, 현대자동차, KT, 주요 금융권 등)에서 실제로 3시간 과정으로 진행되는 강의 내용 핵심을 압축해 소개드릴 예정입니다.

[Session7]  손영수 | 어니컴
– 발표 테마 : 딥다이브
– 발표 주제 : 거대한 데이터 추정하기 (sketching massive datasets)
– 거대 데이터의 빠른 추정을 위한 다양한 핵심 알고리즘 개념을 소개합니다.

맴버십 알고리즘

• Bloom Filter – 존재 여부를 파악
• Counting Bloom Filter– 맴버 삭제를 지원하는 맴버십 (존재여부) 알고리즘
• Cuckoo Filter (뻐꾸기 or 추방 필터)  – CBF보다는 적은 메모리로 맴버 삭제 지원

빈도수  스케치

• Count-Min Sketch(CMS)
• Heavy Hitter with CMS
• Range Query + Dyadic Range

분위수 및 분포 스케치

• HDRHistogrm,
• DynaHist
• DDSketch

카디널리티 스케치

• LogLog
• SuperLogLog
• HyperLogLog (HLL).

스트리밍 샘플링

• 베르누이
• 저수지 / 편향된 저수지
• 체인 샘플링
• 우선순위  샘플링

시간상 다 다룰수 없을수도 있습니다.. 최대한 핵심만 잘 전달해 볼수 있도록 노력하겠습니다.

누군가는 꼭 번역했어야 할, 그런 책이었습니다.

『Pattern-Oriented Software Architecture』는 GoF의 디자인 패턴과 함께 소프트웨어 설계 패턴의 양대 산맥이라 불릴 만큼 깊은 영향을 끼친 명서입니다. 객체지향의 미시적 설계에 초점을 맞춘 GoF가 있었다면, POSA는 시스템 수준의 구조적 사고와 아키텍처적 시야를 열어준 책이었습니다.

약 15년 전, 이 책의 번역 작업에 참여했던 저는 최근 다시 이 책을 손에 들게 되었습니다. 시간이 흐르고, 경험과 나이가 쌓인 지금, 그때는 보이지 않던 문장과 문맥이 새롭게 읽혔고, 그 무게도 전과는 다르게 다가왔습니다.

솔직히 말하자면, 역자로서 이런 책을 다시 번역하는 것이 경제적으로 큰 보상이 있는 일은 아닙니다. 하지만 누군가는 해야 할 일이었고, 저는 그 ‘누군가’가 되기로 했습니다.

선배들이 열어준 시장과 공유해준 경험이 있었기에 지금의 제가 있고, 이제는 그 고마움을 후배들에게 되돌려줄 차례라고 생각했습니다.

이 번역이 패턴을 공부하는 이들, 그리고 더 좋은 아키텍처를 고민하는 모든 개발자들에게 작은 이정표가 되기를 바랍니다.

부족하지만 나름 꼼꼼히 다듬고 최대한 책에서 나오지 않는 “숨겨진 이야기 나 배경 지식”도 다루었습니다.

부족하지만 좋은 서적이 나올수 있게 많은 분의 참여 바랍니다.

너무 공감이 가는 자료라서, 읽어보시길 바랍니다.

1. 경험이 쌓여야 좋은 판단을 할수 있음.

• 좋은 판단은 (잘못된 판단을 했던) 경험에서 옵니다.
• 프로덕션에서 테스트를 할 때 사용자 맥락을 고려하지 않는 것보다, 더 나쁜 것은 아예 프로덕션 환경에서 테스트하지 않는 것입니다.

2. 최종 사용자 배포 전 흔히 저지르는 실수들:

이상적인 해피케이스에만 집중:

• 문제: 실패할 가능성이 있는 상황을 무시하고, 이상적인 경로만 테스트함.
• 예시: 메시징 앱이 네트워크 연결이 불안정할 때 작동하지 않아, 프로덕션에서 메시지가 전송되지 않음.

 부족한 사용자 수용 테스트(UAT):

• 문제: 실제 사용자들을 테스트에 충분히 참여시키지 않음.
• 예시: 테스트 중 사용자 피드백을 반영하지 않아, 최종 인터페이스가 사용자들에게 혼란을 줌.

 불완전한 테스트 범위:

• 문제: 중요한 예외 상황을 테스트에서 놓침.
• 예시: 유효하지 않은 신용카드 입력에 대한 테스트가 누락되어, 프로덕션에서 결제가 실패함.

 비현실적인 테스트 데이터:

• 문제: 테스트가 실제 환경을 반영하지 않음.
• 예시: 개발 중 특수 문자를 테스트하지 않아, 사용자가 이를 입력했을 때 프로덕션에서 앱이 충돌함.

 환경 차이:

• 문제: 프로덕션과 다른 환경에서 테스트를 진행함.
• 예시: 웹 애플리케이션이 테스트 환경에서는 잘 작동하지만, 실제 환경에서는 네트워크 속도가 느려 타임아웃이 발생함.

 통합 테스트 부족:

•  문제: 구성 요소 간의 상호작용 문제를 간과함.
•  예시: 프로덕션에서 API가 기존 데이터베이스와의 데이터 구조 불일치로 인해 실패함.

 비기능적 테스트 생략:

•  문제: 성능과 보안 테스트를 충분히 하지 않음.
•  예시: 프로모션 후 예상치 못한 트래픽 증가로 웹사이트가 다운됨.

3. 기타 사례:

• 예상치 못한 충돌: 사소한 변경이 프로덕션에서 시스템 전체의 큰 충돌을 유발함.
• 보안 취약점: 배포 후 패치되지 않은 보안 취약점이 악용됨.
• 데이터 손상: 테스트되지 않은 예외 상황이 라이브 거래 중 데이터베이스 손상을 일으킴.
• 서버 과부하: 부하 테스트를 충분히 하지 않아 예상치 못한 다운타임이 발생함.
• 사용자 이탈: 출시 후 성능 문제를 해결하지 못해 사용자가 앱을 떠남.

프레임워크 내부를 설명하는 전통적인 패턴과 최신 트랜드를 반영한 패턴들을 조화롭게 설명하였고 , 실제 사용되는 Use Case들 기반으로 많은 부분들을 녹였습니다.

S사 5일 강의 과정에 대한 피드백은 맨 마지막에 붙이도록 하며, 커리큘럼에 대해서 공유를 합니다. 많은 분들이 아키텍처 설계 / 평가 코스웍을 만드실때 참고하시길 바랍니다.

소프트웨어 설계 개론및 확장가능한 대용량 서비스 아키텍처 (1일차)

소프트웨어 설계 이론 (CMU – QAW , Architecture Driver, ATAM 등)

CMU (카네기멜론 대학)의 소프트웨어 아키텍처 프로스세에 대해서 전반적으로 설명을 하는 시간을 가집니다. 그리고 이 프로세스에 대한 문서를 google docs를 공유함으로써, 실제 프로젝트가 끝나면 설계경험을 가지게 하는 것이 목적입니다.

확장 가능한 웹서비스 아키텍처

• 서비스 구성
• 복제
• 파티셔닝(샤딩)
• Consistent Hasing
• 캐시 사용 전략 + Redis Usecase
• Proxy  / Load Balancer
• Queue (RabbitMQ vs Kafka)
• 데이터 베이스 (CAP – PACELC)
• 실사례 아키텍처 (Lambda, Kappa, Uber)

클라우드 + MSA패턴

• 긴 트랜잭션 관리
• 데이터베이스 패턴
• 일관성 유지하기 패턴
• 트랜잭션 관리
• 쿼리 및 분리
• 서비스 통신방식
• API 접근
• 서비스 검색
• 배포
• Scatter+Gather  , Map Reduce, Materialized View, Sidecar등

거대한 데이터 추정하기 + POSA 패턴 심화 과정 (2일차)

거대한 데이터 추정하기 (Sketch Massive Datasets)

• 맵버십 알고리즘 (bloom filter, cuckoo filter +@)
• 빈도수 추정 (Count Min Sketch + @)
• 백분위 분포 (HDRHistogram, DynaHist, DDSketch)
• 유일성 추청 (loglog, Superloglog, Hyperloglog)

아키텍처 패턴 (POSA1)

네트워크 서버 패턴 (POSA2 )

• 서비스 접근설정
• 이벤트 핸들러
• 동시성 제어
• 동기화

POSA2 패턴 이벤트 핸들러 심화

• 디스패처 만들기
• 프로토콜 확장성 추가하기
• Reflection / Component Configurator 패턴 적용
• Thread Pool 적용하기
• Proactor 패턴 맛보기

자원관리 패턴 (POSA3)

내결함성 패턴과 아키텍처 설계 (3일차)

내결함성 패턴 (Fault Tolerance 패턴)

• 내결함성 아키텍처 패턴
• 내결함성 탐지 패턴
• 오류 복구 패턴
• 부하 완화 패턴
• 결함 처리 패턴

아키텍처 설계 실습

• 인증과제 (우버 또는 다른 케이스 협의)
• CMU 아키텍처 설계 프로세스 소개 및 템플릿 전달
• Architecture Driver 도출
• High Level 설계
• Design Decision 결정
• 하위 뷰 일부 도출

웹 부하테스트 및 성능 튜닝 이론 (4일차)

부하테스트 이론 및 실습 (Jmeter)

•  부하 테스트 이론
•  Jmeter 환경 구축
•  테스트 케이스 실습
•  성능 측정 하기
•  다양한 컴포넌트를 활용한 고급기법 소개
• 테스트 진행시 고객(파트너)사와 협의해야 하는 것들
• 적절한 임계점 설정하기
• 테스트 진행 절차 방안
• 테스트 진행 실사례 경험담 공유
• 성능 평가 리포트 작성 방안 전달

성능 진단 평가 및 아키텍처 평가 (5일차)

성능 측정 기법및 장애 사례 공유

• 서버- APM 및 인프라 모니터링을 활용한 장애 진단 기법 (동적, 실행 관점)
• 모바일 – 안드로이드 운영체제 커널 변천사 와 내부 아키텍처, 성능 진단 사례
• 웹 프론트엔드 성능 지표
• AI 모델 성능 평가 사례 (모델 품질, 데이터 품질)

아키텍처 평가 기법 및 개선하기

• 아키텍처 시각화 지표 (Archiecture Viusalization)
• 질서의 본질 (약식)
• 리펙토링 실사례 
• QAS (Quality Attribute 시나리오) 검증 
• 아키텍처 접근법 분석서 리뷰

실 강의 피드백

Samsung SDS 5일 코스에 대한 피드백 내용을 공유드립니다.

강의 요청을 하시는 분들에게

시간당 25만원이 아니면 강의를 하지 않습니다. (최소 3시간 보장)

다만 수도권이 아닌 지방이라면 지식 공유를 위해 훨씬 저렴하게 해 드릴 생각이 있습니다. 또한 수익 전액에 대해서 취약계층이나 장애인 기부를 하는 공공의 강의라면 차비와 숙박비만 지원해 주시면, 2,3시간의 특강은 얼마든지 가능합니다.

indigoguru@gmail.com 으로 연락을 주시면 됩니다. 감사합니다.

10년전에 발표한 아키텍처 시각화 패턴의 마무리 글을 올립니다.

패턴 I 회에서는  아키텍처 시각화 패턴의 전체적인 구조와 구성되는 패턴들의 종류들을 간단히 소개하고, 아키텍처 시각화를 하기 전에 소프트웨어 시스템을 분석하기 위한 기본 요소들인 Domain Level Classifier Pattern과 Class Dependency Classifier Pattern에 대해서 살펴보았다.

2회에서는 시간에는 소프트웨어 시스템의 아키텍처 분석에 기본이 되는 다양한 Metric에 대한 설명을 올렸다.

이번 3회에서는 의존성을 관리하는 시각화 지표를 설명한다.

Dependency Visualization(Chart) Pattern

Context

소프트웨어 시스템의 속하는 다양한 도메인들의 의존성(상속, 참조 등)은 소프트웨어 시스템의 심각한 아키텍처적인 문제점이나 전체적인 그림을 그려볼 수 있도록 도와주는 아키텍처 분석에 있어서 중요한 정보이다. 그렇기 때문에 앞서 소개하였던 클래스 다이어그램을 통한 분석이나 소스 코드를 통한 분석에서도 이러한 도메인들 간의 의존성을 파악하는 부분에  많은 비중을 두고 분석하게 된다. 그 중에서도 특히 클래스 다이어그램을 통한 분석은 대부분이 이러한 의존성을 중심으로 아키텍처를 파악한다고 할 수 있다. 

하지만 클래스 다이어그램을 통한 분석은 너무 넓게 바라보기 때문에 분석으로 얻을 수 있는 정보가 너무 적으며, 소스 코드를 통한 분석은 너무 깊게 바라보기 때문에 분석에 많은 시간이 걸리며 전반적인 아키텍처에 대한 큰 그림을 그리는 것이 힘들어 아키텍처를 파악하는데 있어서 부적합하다. 

Problem

• 아키텍처적인 문제점을 발견하기에 많은 시간이 필요한 클래스 다이어그램과 코드 분석 방법

클래스 다이어그램과 코드를 바탕으로 도메인간의 의존성을 분석하게 되면 소프트웨어 시스템에 내제 되어있는 상호 참조와 같은 다양한 아키텍처적인 문제점들이 바로 코드나 클래스 다이어그램에는 들어나지 않아 문제를 발견하기가 매우 어렵다. 

• 소프트웨어 시스템의 아키텍처를 가늠하기 힘든 클래스 다이어그램과 코드 분석 방법

이러한 분석 방법으로는 소프트웨어 시스템의 전체적인 흐름과 아키텍처를 파악하기에는 무리가 있다. 이는 클래스 다이어그램의 경우에는 단순히 의존성만이 나타나고, 그 의존성이 발생하는 부분이나 발생 정도에 대한 내용들을 제공해주지 않으며, 코드 수준에서는 아무런 기본 정보를 제공해주지 않기 때문에 분석자가 스스로 파악해야만 한다. 

Force

• 소프트웨어 시스템의 아키텍처적인 문제점을 직관적으로 확인할 수 있어야만 한다.
• 클래스 다이어그램이 제공해주지 않는 보다 자세한 정보들을 제공해주어야만 한다.
• 코드 수준의 분석보다는 요약된 정보를 제공해야만 한다.
• 소프트웨어 시스템의 의존성에 의한 전체적인 아키텍처를 가늠할 수 있어야만 한다.

Solution

소프트웨어 시스템 내의 의존성 정보들을 이용하여 시각화하면 분석자에게 보다 많은 정보를 줄 수 있게 된다. 의존성을 바탕으로 시각화를 하계 되면 우선 클래스 다이어그램의 기본적인 상속이나 추상화 수준 등에 정보는 기본적으로 포함하게 된다, 이 외에도 현재 소프트웨어 시스템의 전체적인 흐름을 파악할 수 있게 되고, 소프트웨어 시스템이 내부적으로 가지고 있는 크기 문제나 상호 참조와 같은  아키텍처적인 문제점을 매우 쉽게 발견 할 수 있다.

<표 6 –  각 분석 방법의 비교>

Consequences

• 소프트웨어 시스템을 적절한 범위 내에서 분석할 수 있게 된다.
• 소프트웨어 시스템의 아키텍처를 보다 빠른 시간 안에 파악할 수 있게 된다.
• 소프트웨어 시스템의 아키텍처적인 문제점들을 파악하기 쉬워진다.

Side-effects

• 소프트웨어 시스템의 의존성들이 매우 복잡해질수록 시각화를 하기 위해 많은 시간이 필요하게 된다.
• CC와 같은 복잡도나 크기 등과 같은 의존성 이외의 정보들은 분석할 수 없어 분석에 한계가 존재한다. 

Knows Uses

• CodePro AnalytiX:  구글에서 제공하는 정적 분석기인 AnalytiX에서는 각 소프트웨어 시스템의 도메인들간의 의존성을 원 형태로 배치하여 사용자의 분석을 돕는다.
• Structure 101: 아키텍처 시각화 툴인 Structure 101에서는 소프트웨어 시스템의 도메인들 간의 의존성을 바탕으로 DSM으로 표현하여 사용자의 분석을 돕는다.
• STAN4J: 아키텍처 시각화 툴인  STAN4J에서는 소프트웨어 시스템의 도메인들 간의 의존성들을 바탕으로 Digraph 형태로 표현하여 사용자의 분석을 돕는다.

Related Patterns

• Dependency Structure Matrix Pattern: Dependency 패턴을 시각화 하기 위한 서브 패턴의 하나
• Dependency Composition Digraph Pattern: Dependency 패턴을 시각화 하기 위한 서브 패턴의 하나
• Class Dependecy Classifier Pattern : 각 도메인 간의 모든 의존성에 대한 기본 데이터

5.1 Dependency Structure Matrix(DSM) Pattern

Context

소프트웨어 시스템에 존재하는 도메인(패키지, 클래스, 메소드 등)들과 이러한 요소들간의 여러 의존성들이 존재한다. 이러한 정보들은 하나의 소프트웨어 시스템에서도 매우 방대한 양을 가지고 있기 때문에 무엇보다도 이를 요약해줄 수 있어야 하며, 또한 이 내용들을 토대로 소프트웨어 시스템을 분석하고자 하는 사람은 최대한 쉽고 빠르게 소프트웨어 시스템 전체의 구성을 파악하고 문제점을 찾을 수 있어야 하므로,  이 정보들을 시각화 할 수 있는 기법이 필요하다.

Problem

• Dependency Chart 패턴을 적절하게 시각화 할 수 있는 방법이 필요하다.

앞서 Dependecy Chart 패턴을 기반으로 소프트웨어 시스템 내부의 다양한 도메인들의 의존성들을 소프트웨어 시스템을 분석하고자 하는 사람이 보다 쉽고 빠르고, 그리고 직관적으로 이해할 수 있어야 하는 방법이 필요하다.  

Force

• 소프트웨어 시스템의 도메인들의 의존성을 쉽게 파악할 수 있어야 한다.
• 소프트웨어 시스템의 아키텍처적인 문제점을 발견하기 쉬워야 한다.
• 소프트웨어 시스템의 전체적인 아키텍처를 파악하기 쉬워야 한다.

Solution

일반적으로 의존성을 시각화 하는 가장 기본적인 방법으로는 Dependency Structure Matrix (Design Structure Matrix, DSM)이 존재한다(Neeraj05). DSM은 행렬의 형태로 의존성을 시각화하여 보여주는 방법으로, 이는 기본적으로 그래프 이론에서의 그래프를 표현하는 방법 중에 인접 행렬 방식과 동일한 방식으로 시각화가 이루어진다.

<표 6 –  DSM의 예>

DSM은 위의 표와 같이 분석하고자 하는 소프트웨어 시스템의 의존성을 쉽게 파악할 수 있도록 행렬의 모습으로 전체적인 의존성을 보여준다. 이러한 DSM은 열을 기준으로 의존성을 분석할 수 있다. 간단히  예를 들자면 A열과 C행이 교차하는 지점에 2라는 값은 A요소가 C를 두번 참조(의존)한다는 의미로 비교적 직관적이고 빠르게 해석할 수 있게 된다.  또한 위의 표와 같이 소프트웨어 시스템 내부의 상호 참조와 같은 아키텍처적인 문제점이 존재할 경우 바로 알아볼 수 있다.

Implementation

DSM을 구현할 수 있는 방법들은 여러 종류가 존재 한다. 여기에서는 그 중 특정 도메인 수준에서 DSM을 시각화 하는 방법에 대해서 이야기하겠다.

• 기본 절차

1 단계: 시각화를 위한 기본 도구를 선택한다.

2 단계: Class Relationship Classifier 패턴을 기반으로 시각화 하려는 프로젝트의 의존성을 추출한다.

3 단계:  추출된 의존성 정보들 도메인 수준을 기준 도메인의 시점으로 변경한다.

4 단계: 변경된 의존성 정보들을 바탕으로 DSM을 시각화 한다.

• 예제 소스 코드(분석 대상) – 예제로 분석하고자 하는 코드는 다음과 같다.

package PackageA;

class ElementA{

ElementB b;

ElementB getElementB(){return b;}

}

package PackageB;

class ElementB{

ElementC c;

ElementC getElementC(){return c;}

}

package PackageC;

class ElementC{

ElementA getElementA(){return new ElementA();}

}

• 절차 설명

1 단계: 시각화를 위한 기본 도구를 선택한다.

제작하고 있는 아키텍처 시각화 툴에 알맞은 차트 또는 그래픽 구현 도구를 선택한다. 간단하게 웹을 이용하여 제작한다면 SVG나 HTML5의 캔버스가 될 수 있다. 시각화을 구현하기 위한 기본 도구들은 개발자가 원하는 요소들을 자율적으로 선택 하면된다. 

2 단계: Class Relationship Classifier 패턴을 기반으로 시각화 하고자 하는 소프트웨어 시스템의 도메인 간의 의존성을 추출한다.

앞서 설명한 Class Relationship Classifier 패턴을 기반으로 시각화 하고자 하는 소프트웨어 시스템 안에 존재하는 10가지의 모든 의존성들을 추출한다.  

<표 7 – 테스트 코드에서 추출된 의존성들의 예제>

3 단계:  추출된 의존성 정보들 도메인 수준을 기준 도메인의 시점으로 변경한다.

추출된 의존성 정보들의 시작요소와 도착요소의 도메인 수준을, 분석하고자 하는 기준 도메인의 시점으로 변경한다. 간단히 예를 들자면  시각화 하려는 기준이 “패키지” 단위라면 “PackageC.ElementC. getElementA” 와 같은 “패키지”단위 보다 하위에 속하는 “메소드” 단위의 정보를 기준점인 패키지 단위의 정보, 즉 “PacakageC”로 변경하여 DSM을 그린다.

4 단계: 변경된 의존성 정보들을 바탕으로 DSM을 시각화 한다.

도메인 시점을 변경한 의존성 정보들을 바탕으로 실제 DSM을 시각화 한다. 이때 의존성의 수는 변경된 의존성 정보 안에서 시작 요소와 도착 요소가 모두 같은 경우의 수를 기입한다.

<표 8 – 완성된 DSM 예제>

Consequences

• 소프트웨어 시스템의 의존성에 의한 아키텍처를 분석하기 쉬워진다.
• 소프트웨어 시스템 내부의 아키텍처적인 문제점들을 발견하기 쉽다.

Side-effects

• 소프트웨어 시스템의 규모가 커지면 분석하기 힘들어진다.
• 의존성의 정확한 종류를 파악하는 것이 불가능하다.
• 소프트웨어 시스템의 전체적인 아키텍처를 생각하기가 힘들다.

Knows Uses

• Structure 101: 아키텍처 시각화 툴인 Structure 101에서는 각 패키지나 클래스간의 의존성을 바탕으로 DSM으로 표현하여 사용자의 분석을 돕는다.

Related Patterns

• Relation 패턴: 소프트웨어 시스템의 의존성의 종류에 대하여 정의 및 추출 방식에 대한 패턴이다.
• Dependency Composition Digraph 패턴: DSM이 가지는 단점을 해결하기 위한 패턴

5.2 Dependency Composition Digraph Pattern

Context

DSM Pattern을 기반으로 Dependency Graph Pattern의 시각화하면, 우선 클래스 다이어그램이나 소스 코드 분석에 비해 아키텍처를 보다 쉽게 파악할 수 있게 되며, 해당 소프트웨어 시스템이 가지고 있는 아키텍처적인 문제들을 비교적 발견하기 쉬워 진다.

그렇지만 DSM Pattern은 분석하고자 하는 대상의 규모가 커지면 분석하기가 매우 힘들어지며 표에 나타나있는 의존성에 정확한 종류도 파악하기 힘들다.

거기다가 행렬을 기반으로 데이터를 시각화하기 때문에 분석가가 이를 기반으로 소프트웨어 시스템에 대한 전체적인 아키텍처를 직관적으로 바로 생각하기가 힘들다는 단점이 존재한다. 

Problem

• 소프트웨어 시스템의 규모가 커지면 분석하기 힘든 문제

DSM 패턴을 이용한 방법에서는 소프트웨어 시스템의 규모가 커질수록 행렬도 이에 비례하여 커지게 된다. 그렇기 때문에 분석할 도메인들이 많아질수록 살펴봐야 할 요소들이 많아지고 너무 커진 행렬 때문에 분석자체도 힘들어지는 문제를 가지고 있다.  

• 행렬 구조의 복잡함에 의한 전체적인 아키텍처를 파악하기 힘든 문제

DSM 패턴은 행렬의 의존성이 있는 요소에 숫자를 기입하는 형태로 의존성을 나타낸다. 이 방식은 하나의 요소를 중심으로 의존성들을 파악하기에는 편리하지만 소프트웨어 시스템 전체의 의존성을 파악하기에는 매우 힘든 방식이다.  

• 소프트웨어 시스템의 의존성에 대한 정확한 파악 문제

DSM 패턴은 의존성을 단순히 숫자를 통해 나타내기 때문에 의존성의 정도는 추정할 수 있지만, 그 안에 어떠한 의존성을 가지고 있는지는 알 수 있는 방법이 존재하지 않는다.

Force

• 요소(패키지, 클래스 메소드 등)들의 의존성을 쉽게 파악할 수 있어야 한다.
• 소프트웨어 시스템의 아키텍처적인 문제점을 발견하기 쉬워야 한다.
• 소프트웨어 시스템의 아키텍처를 파악하기 직관적이고 명시적이어야 한다.

Solution

소프트웨어 시스템의 의존성을 가중치를 가지는 방향 그래프 형태로 시각화하여 보여주는 방법을 활용하면 이러한 단점을 개선할 수 있다. 이는 DSM이 기본적으로는 그래프 이론의 그래프를 표시하는 방법 중에 하나인 인접 행렬에서 파생되었다는 점을 고려하여, 이를 반대로 그래프로 그리게 되면 행렬이 가지는 시각화와 관련된 단점들을 개선할 수 있게 된다. 

그리고 이러한 가중치를 가지는 방향 그래프를 시각화 할 때, 각 Vertex간의 참조에 따라서 계층 구조로 표현하여 제공한다면, 각각의 요소들의 의존성을 한눈에 확인할 수 있게 된다.

<그림 16 – 계층화 된 방향 그래프 예제>

Implementation

이 패턴을 구현하려면 다음과 같은 단계를 수행하면 된다.

• 기본 절차

1 단계: 시각화를 위한 기본 도구를 선택한다.

2 단계: DSM 패턴을 기반으로 DSM을 생성한 뒤, 그 결과를 바탕으로 가중치를 가지는 방향 그래프를 생성한다.

3 단계: 생성된 방향 그래프를 그릴 수 있는 계층화된 레이아웃을 생성한다.

4 단계: 레이아웃을 바탕으로 그래프를 그린다.

• 예제 소스 코드(분석 대상): DSM패턴의 예제 소스와 동일하다.
• 절차 설명

1 단계: 시각화를 위한 기본 도구를 선택한다.

제작하고 있는 아키텍처 시각화 툴에 알맞은 차트 또는 그래픽 구현 도구를 선택한다. 간단하게 웹을 이용하여 제작한다면 SVG나 HTML5의 캔버스가 될 수 있다. 시각화를 구현하기 위한 기본 도구들은 개발자가 원하는 요소들을 자율적으로 선택 하면 된다. 

2 단계: DSM 패턴을 기반으로 DSM을 생성한 뒤, 그 결과를 바탕으로 가중치를 가지는 방향 그래프를 생성한다.

이 패턴은 기본적으로 DSM 패턴으로 생성된 결과물인 DSM을 가지고 그래프를 생성하기 때문에, 우선적으로 DSM을 생성한다. 그 다음 DSM 정보들을 그래프를 나타내는 인접 행렬로 생각하고 가중치를 가지는 방향 그래프를 구성한다.

<그림 17: DSM을 그래프로 변경한다>

3 단계: 생성된 방향 그래프를 그릴 수 있는 계층 레이아웃을 생성한다.

생성된 방향 그래프에 대한 정보들을 바탕으로 계층 레이아웃을 생성하는 작업을 진행해야 한다. 일반적으로 방향 그래프를 계층 레이아웃을 만들기 위해서는 스기야마 알고리즘([Bastert+01])을 이용하여 레이아웃을 계산해야 한다. 그런데 스기야마 알고리즘의 경우 작업의 몇 가지 요소들이 NP-Hard 문제로 그리디 알고리즘을 기반으로 계산해야만 한다. 그렇기 때문에 계산되는 계층 레이아웃은 항상 최적해를 가지지 않는다는 것에 유의해야 한다.

4단계: 레이아웃을 바탕으로 그래프를 그린다.

생성된 레이아웃을 바탕으로 선택한 시각화 도구를 이용하여 방향 그래프를 그린다. 이 때 그래프의 Edge를 그릴 때 대표적인 의존성(상속이나 참조 등)은 클래스 다이어그램에서 정의된 기호들을 사용하여 구성한다. 

 <그림 18: 완성된 방향 그래프의 모습> 

Consequences

• 소프트웨어 시스템이 가지고 있는 아키텍처적인 문제들을 발견하기 매우 쉽다.
• 계층 구조를 이루고 있어 도메인들의 의존성을 파악하기 쉽다. 
• 대표적인 의존성일 경우, Edge의 모양을 해당 클레스 다이어그램 기호로 표시하여 직관적으로 파악할 수 있다. 
• 소프트웨어 시스템의 전체적인 아키텍처를 파악하기가 쉽다.
• 소프트웨어 시스템의 규모가 커져도 충분히 분석 가능하다.

Side-effects

• 시각화를 표시하기 위한 레이아웃 등을 계산할 때 많은 시간이 소모된다.
• 정형화 된 Chart 타입이 아니기 때문에 시각화 구현 시 어려움이 따른다.

Knows Uses

• STAN4J: STAN4J이라는 아키텍처 시각화 툴에서 Composition 이라는 뷰에서  소프트웨어 시스템의 요소들(패키지, 클래스 등)을 방향 그래프를의 형태로 소프트웨어 시스템의 의존성을 표현해주고 있다.

Related Patterns

• Class Relationship Classifier 패턴: 소프트웨어 시스템의 의존성 종류에 대하여 정의 및 추출 방식에 대한 패턴이다.

맺음

소프트웨어 구조를 시각화하는 패턴들을 설명하였다. 이 패턴을 만들기 위해서, 다양한 시각화 도구들을 분석하였으며, 제품들간의 시각화 하는 지표들의 장단점을 파악하는 계기가 되길 바란다.

새로운 오프라인 강의가 준비되었습니다.

Cloud (MSA) 패턴 에 관한 120페이지 분량의 강의가 완성되었습니다.

하지만 요즘 현 시대에 맞는 아키텍팅을 준비하기 위해 최신 패턴들을 정리했습니다.

• 마이크로 서비스 패턴 언어
• 마이크로 서비스 패턴 맵핑하기
• 마이크소프트 클라우드 디자인 패턴

거의 2주간 정리를 진행했으며, 알고 있는 패턴도 있었지만, 나름 깨달음을 많이 주는 패턴 들도 있었습니다.

패턴 목록

• 긴 트랜잭션 처리하기   (Saga – Orchestration/Choreography)
• 데이터베이스 패턴   (Shared Database, Database per Service)
• 데이터 일관성 유지하기   (Domain Event, Event Sourcing)
• 트랜잭션 관리    (Transactional Outbox, Polling Publisher, Transaction Log)
• 쿼리   (CQRS, API Composition)
• 분리   (Design by SubDomain, Design by Biz Capability)
• 서비스 통신방식   (Messaging , RPI, Domain Specific Protocol)
• 통신/API 접근   (API Gateway, Backends for Frontend)
• 서비스 검색   (Service Registry, Client side/Server side Discovery, Registration)
• 배포   (Service Instance per Host / VM/ Container, Serverless, ..)
• 데이터 집약 성능 향상   (Scatter-Gather, MapReduce, Materialized View)
• 확장성   (SideCar, Ambassador ,Anti Corruption Layer)

참고 아키텍처 시리즈

• Lambda – Monitoring
• Kappa
• Uber Architecture 사레

정리한 패턴 상황..

관련된 강의 의뢰나 문의는 메일이나, 댓글로 남겨주시면 될듯합니다.

손영수 indigoguru@gmail.com

이번 시간은 아키텍처 전략: 실시간 위치 검색을 위한 지리 공간 인덱스 설계 시리즈 마지막 시간으로 Geo Hash를 이용하여 아키텍처 개선하기에 대해 다루겠습니다.

1. 개요 및 아키텍처
2. 샤딩으로 아키텍처 개선하기
3. Geo Hash를 이용하여 아키텍처 개선하기

소개

우리는 실생활에서 항상 실시간 위치 검색 서비스를 사용합니다. 음식 주문 앱이나 주문형 택시 예약 서비스는 요즘 어디서나 볼 수 있죠. 이 글의 목적은 실생활에서 지리 공간 인덱스(Geo-spatial Index)에 대한 백엔드 인프라를 설계하는 방법을 살펴보는 것입니다.

지난 1편 글에서는 로드발랜서와 캐시를 이용하여 부하를 배분 및 감소하는 전통적인 아키텍처를 설명했습니다.

하지만 위 아키텍처는 여전히 IO를 처리하는데 한계가 있어, 도시 ID 기반의 저장소를 분리하는 샤딩이라는 전략을 도입하는 개선된 아키텍처를 2편에서 다루었습니다.

도시와 도시 경계 사이에 있는 배달 에이전트들, 그리고 특정 도시에만 과도하게 트래픽이 몰릴 경우(hotspot)를 고민하는 것이 필요해 보입니다.

접근 방법 3:  Geo-Hash 기반의 파티셔닝 & 매칭된 Hash에 조회(query)하기

우리는 초당 수백만 쿼리와 같은 매우 높은 규모(Uber, Lyft와 같은 서비스의 경우)가 있는 경우 지역/도시 ID 기반의 파티셔닝만으로는 문제를 해결할 수 없다는 것을 확인했습니다. (필요에 따라) 반경을 기반으로 검색 영역을 늘리거나 줄이는 유연성을 가질 수 있는 전략을 찾아야 합니다.

Geo-Hash라는 주어진 위치(lat, long pair)를 인코딩하는 메커니즘이 있습니다. 핵심 개념은 지구를 평평한 표면으로 상상하고 표면을 여러 그리드(정사각형 또는 직사각형, 구현 방법에 따라 달라짐)로 계속 나누는 것입니다. 그림 4에서 먼저 평평한 지구 표면을 0, 1, 2,  3으로 표시되는 4개의 격자로 나눕니다. 이제 각 격자는 100,000 KM x 100,000 KM과 같은 큰 크기의 4개의 서로 다른 영역을 나타냅니다. (이 그림은 이해를 돕기 위한 것으로 정확하지 않을 수도 있습니다.)

위 방법으로는 매칭되는 위치를 검색하기엔 너무 큽니다. 그래서 더 나눌 필요가 있습니다. 이제 4개의 Grid를 각각 4개의 부분으로 나눌 것입니다. 그래서 Grid 0은 이제 내부에 4개의 Grid(00, 01, 02, 03)로 나뉩니다. 그림 4에서  Grid 2가 20, 21, 22, 23의 4개 부분으로 나누어져 있음을 보여줍니다. 이제 이 작은 그리드들이 각각 크기 20,000KM x 20,000KM의 영역을 나타낸다고 합시다. 이것도 매칭되는 위치를 검색하기엔 여전히 큽니다.

그래서 우리는 이러한 Grid들을 4개의 부분으로 계속해서 나누고 각 영역/Grid가 50 KM x 50 KM 영역 또는 검색에 적합한 일부 영역으로 표현될 수 있는 지점에 도달할 때까지, 반복적으로 나누는 작업을 계속했습니다.

따라서 개념적으로 더 많은 Grid를 추가할수록 해당 영역(area)은 계속 작아집니다. 영역의 정밀도가 매우 높아지고 영역(area)을 나타내는 문자열의 길이가 증가합니다. 문자열 “02”는 20,000 KM x 20,000 KM의 영역을 나타내고 문자열 “021201”은 50 KM x 50 KM의 영역을 나타낼 수 있습니다. (언급된 수치는 수학적으로 정확하지 않으며 Geo-Hash의 핵심 개념에 대한 이해를 돕기 위한 것입니다.)

간략히 말하자면,  고정밀 (High precision) Geo-Hash는 문자열 길이가 길고 작은 영역만 포함하는 셀을 나타냅니다. 낮은 정밀도(Low precision)  Geo-Hash는 문자열 길이가 짧고 각각 넓은 영역을 포함하는 셀을 나타냅니다.

모든 Geo-Hash 라이브러리는 평평한 지구를 초기에 4개의 그리드로 표현할까요?

그렇지는 않습니다. 대부분의 Geo-Hash 라이브러리는 32개의 영숫자 문자를 기반으로 하며 표면을 32개의 직사각형으로 계속 나눕니다. 자기가 원하는 진수 체계 (2진수, 16진수 등)로 자신의 Geo-Hash 라이브러리를 구현할 수 있습니다. 그러나 핵심 개념은 동일합니다. (Geo-Hash 내부에 대해서는 차후 별도의 글을 작성하도록 하겠습니다.)  

실생활에서 기존 Geo-hash 라이브러리를 비교하고 성능, 노출된 API 및 커뮤니티 지원 측면에서 라이브러리가 얼마나 좋은지 확인합니다. Use Case가 맞지 않는 경우 직접 작성해야 할 수도 있지만 그럴 확률은 낮습니다.

좋은 Geo-Hash 라이브러리 중 하나는 Mapzen입니다. 실생활에서 셀/지역의 치수는 경도 및 위도에 따라 달라질 수 있습니다. 모든 곳이 동일한 정사각형 또는 직사각형은 아니지만 기능은 동일합니다.

그렇다면 우리의 경우 Geo-Hash를 어떻게 사용할 수 있나요?

먼저 30~50제곱KM과 같은 검색에 적절한 영역을 제공하는 Geo-Hash의 길이를 결정해야 합니다. 일반적으로 Geo-Hash 구현에 따라 그 길이는 4에서 6이 될 수 있습니다. 기본적으로 합리적인 검색 영역을 나타낼 수 있고 핫 샤드가 되지 않는 길이를 선택합니다. 길이 L을 결정한다고 가정해 보겠습니다. 이 L 길이 접두사를 샤드 키로 사용하고 더 나은 부하 분산을 위해 현재 개체 위치를 해당 샤드에 배포합니다.

Geo-Hash 개념이 작동하는 이유는 무엇인가요?

우리가 본 것처럼 특정 길이의 Geo-Hash는 유한한 평방킬로미터의 영역을 나타냅니다. 실제 현실에서는 한정된 수의 자동차나 배달원 또는 한정된 물체만 해당 영역에 들어갈 수 있죠. 따라서 최악의 경우에 얼마나 많은 개체가 있을 수 있는지 파악하기 위해 몇 가지 추정치를 개발하고, 그에 따라 핫 샤드 가능성을 줄일 수 있는 인덱스 머신 크기를 계산할 수 있습니다. 유한한 수의 개체가 있는 유한한 영역이 있기 때문에 어쨌든 논리적으로(매우 부하가 많은) 핫 샤드가 없을 것입니다.

인터뷰 팁: Geo-Hash가 어떻게 작동하는지 이해하여 편하게 이야기하거나, 면접관이 이 개념에 대해 모를 수도 있으므로 최소한 간략한 개요를 제공하세요. 면접관이 Geo-Hash의 내부 수학에 대해 질문할 가능성은 거의 없습니다. 그래도 가능하면 Geo-Hash 라이브러리의 구현을 이해하려고 시도합니다. 참조 섹션에 참고할 만한 링크를 넣어두었습니다.

Geo-Hash 기반의 개선된 아키텍처



Write Path(쓰기 경로)

Read Path (읽기 경로)

이 기술을 지원하기 위해,  하위 레벨의 설계를 변경해야 하나요?

나중에 db 계층을 샤딩해야 하는 경우를 대비하여 데이터베이스에 Geo-Hash 접두사를 추가해야 합니다. 길이 L의 해시 접두사를 샤드 키로 사용하여 동일한 작업을 수행할 수 있습니다. 새 스키마는 다음과 같습니다.

Collection Name: Locations
--------------------------

Fields:
-------
id - int (4+ bytes)
title - char (100 bytes)
type - char (1 byte)
description - char (1000 bytes)
lat - double (8 bytes)
long - double (8 bytes)
geo_hash - char(10 bytes)
geo_hash_prefix - char(6 bytes)
timestamp - int (4-8 bytes)
metadata - JSON (2000 bytes)

City to shard mapping:
----------------------

geo_hash_prefix (length = L)     shard_id
------------------------------------------
a89b3                             101
ab56e                             103
fy78a                             109
c78ab                             908
a78cd                             834

Shard to Physical server mapping
--------------------------------

shard_id       index_server
----------------------------
101             index-1
103             index-2
109             index-1
908             index-3
834             index-2

우리 시스템에서,  어떻게 이러한 인덱스를 구현할 수 있을까요?

이러한 인덱스를 구현하기 위해서 세 가지 기본 사항이 필요합니다.

Redis를 사용하여 위의 모든 요구 사항을 모델링 할 수 있습니다.

"7619": {"lat": "89.93", "long": 52.134, "metadata": {...}}

This is how we set Redis sorted set for a given object location belonging to a Geo-Hash prefix:

ZADD key member score 
ZADD geo_hash_prefix object_id current_timestamp

Example:
ZADD 6e10h 7619 1603013034
ZADD 6e10h 2781 1603013050
ZADD a72b8 9082 1603013089

Let's say our expiry time is 30 seconds, so just before retrieving current objects for a request belonging to a Geo-Hash prefix, we can delete all data older than current timestamp - 30 seconds, this way, expiration will happen gradually over time:

ZREMRANGEBYSCORE geo_hash_prefix -INF current_timestamp - 30 seconds

-INF = Redis understands it as the lowest value

(역자의 주  – 명령어에 대한 설명은 아래를 참고 하세요.)

• https://redis.io/commands/zremrangebyscore/
• http://redisgate.kr/redis/command/zremrangebyscore.php

이 전략을 실 생활에서 구현한 회사가 있나요?

-Lyft는 이 전략을 실행했습니다. 자세한 내용은 아래 동영상을 시청하세요.

Geo-Spatial Index를 생성하는 다른 방법이 있습니까?

Google에는 S2 라이브러리라는 Geo Hashing에 대한 대체 솔루션이 있지만 문서가 매우 열악합니다. 언젠가는  다른 블로그 게시물에 다룰 별도의 주제로 간직하겠습니다.

Geo-Hash를 사용한 인기 있는 제품이 있나요?

MongoDB & Lucene은 Geo-Hash를 사용하여 Geo-spacial 인덱스를 생성합니다.

마지막으로 시스템의 응답성이 매우 뛰어나야 한다는 요구사항에 따라 지연 시간을 더 줄일 수 있는 방법은 무엇인가요?

데이터가 정적일 경우를 대비하여 국가별 인덱스 서버의 복제본을 만들 수 있습니다. 택시 위치와 같은 동적 데이터의 경우 지역별로 매우 다릅니다. 따라서 해당 지역 또는 국가의 데이터로만 인덱싱되는 지리적으로 분산된 인덱스 서버를 사용할 수 있습니다. (예: 중국에서 데이터를 가져오면 중국의 인덱스 서버만 해당 데이터를 인덱싱합니다.)

Fault Tolerance(내결함성)을 위해 여러 국가 또는 한 국가의 다른 지역에 걸쳐 인덱스 서버의 복제본을 만들 수 있습니다. DNS 수준 로드 밸런싱을 사용하여 다른 국가에서 사용 가능한 가장 가까운 서버로 사용자를 리다이렉션(재 분배) 할 수 있습니다.

맺으며

지리적 위치 인덱스를 생성하기 위한 여러 가지 실제 접근 방식에 대해 논의했습니다. 모든 문제를 해결할 수 있는 단일 기술은 없습니다. 시스템의 규모, 시스템에 대한 사용자 기대치에 따라,  우리의 요구에 맞는  다양한 기술을 선택할 수 있습니다.

동일한 문제를 해결하기 위해 Quad-Tree를 사용하는 많은 기사가 있지만 실생활에서 얼마나 많은 회사가 이러한 솔루션을 사용하는지 또는 해당 솔루션이 실제로 얼마나 확장 가능한지 잘 모르겠습니다. R-Tree 또는 Uber의 육각형 계층적 공간 인덱스 기반 솔루션이 있으며 향후 기사에서 이에 대해 쓸 수 있습니다.

Geo-Spatial 인덱스를 만드는 몇 가지 실용적인 기술을 배웠기를 바랍니다. 이 기사에서 개선해야 할 사항이 있거나 나에게 듣고 싶은 주제가 있으면 의견을 말하고 알려주세요.

역자의 추천 : 부하를 적절하게 분배하기

참고할 만한  전략으로 IO에 따른 적절한 샤드 크기 분배 전략을 보시길 권해드립니다.

참고 자료

1. https://www.pubnub.com/learn/glossary/what-is-geohashing/
2. https://www.youtube.com/watch?v=cSFWlF96Sds
3. https://www.youtube.com/watch?v=AzptiVdUJXg
4. https://github.com/transitland/mapzen-geohash
5. https://redis.io/commands/zadd
6. https://redis.io/commands/zremrangebyscore

또한 흥미로운  다른  아키텍처 사례도 공유 드리니 참고해 보세요.

Uber 아키텍처와 시스템 디자인트위터는 왜 모니터링 시스템을 다시 만들었나?

수정할 부분이 있다면 indigogurur골뱅이gmail.com으로 남겨주시길 바랍니다.

2부는 아키텍처 전략: 실시간 위치 검색을 위한 지리 공간 인덱스 설계 시리즈 두 번째 시간으로 샤딩으로 아키텍처 개선하기에 대해 다루었습니다.

1. 개요 및 아키텍처
2. 샤딩으로 아키텍처 개선하기
3. Geo Hash를 이용하여 아키텍처 개선하기

소개

우리는 실생활에서 항상 실시간 위치 검색 서비스를 사용합니다. 음식 주문 앱이나 주문형 택시 예약 서비스는 요즘 어디서나 볼 수 있죠. 이 글의 목적은 실생활에서 지리 공간 인덱스(Geo-spatial Index)에 대한 백엔드 인프라를 설계하는 방법을 살펴보는 것입니다.

지난 1편에서는 로드밸런서와 캐시를 이용하여 부하를 배분 및 감소하는 전통적인 아키텍처를 설명했습니다.

이번 시간에는 위 그림에서 더 개선된 아키텍처 접근법을 공유합니다. 더 나은 방법으로 캐시를 분할하는 방법을 알아보도록 하겠습니다.

접근 방법 2:  메모리에 파티션 생성하기 & 영리하게 파티션 검색하기

어떻게 하면 이전의 접근 방식보다 더 잘 할 수 있을까요?

명확하게 그림 1의 병목 지점은 모든 읽기 작업에 대해 모든 캐시 노드를 쿼리하고 있습니다. 위치 검색 영역(공간)을 줄이기 위해 일종의 샤딩/분할 전략을 구현할 필요가 있습니다.

어떻게 파티션(분할 전략)을 구현해야 할까요?

다양한 사례에 대해 구현할 수 있는 표준 파티셔닝(분할 전략)은 없으며, 어떤 종류의 애플리케이션과 어떻게 데이터 액세스 패턴이  보이는지에 따라 전략은 다릅니다.hyper-local food (근거리 동네에서 직접 하는 음식: 배달의 민족, 요기요 등) 배달 애플리케이션을 생각해 봅시다.

우리는 고객에게 효율적으로 배송 대행(배달 라이더/에이전트)을 배정하여 빠른 시간 내에 주문이 발송될 수 있도록 해야 합니다.배달 에이전트(라이더)에게 주문을 할당할 수 있는지 여부를 결정하는 여러 가지 매개 변수가 있을 수 있습니다. 예를 든다면 배달 에이전트가 식당 및 고객 위치에서 얼마나 멀리 떨어져 있는지, 배달 중인지, 그리고 또 다른 주문을 받을 수 있는지 등입니다. 하지만 이 모든 필터를 적용하기 전에 제한된 수의 배달 에이전트를 가져와야 합니다.대부분의 배달 에이전트(라이더)는 특정 지역이 아니라면 도시 안에 있을 것입니다.

인천의 배송 에이전트는 일반적으로 부산에 거주하는 고객에게 주문을 배송하지 않습니다. (역자의 주 – 원문은 벵갈루루 / 하이데라바드라는 540km 떨어진 도시로 이야기하고 있으나 이해를 돕기 위해 인천/부산으로 의역하였습니다.)또한 한 도시에 한정된 수의 에이전트가 있을 것이며, 그 수가 수천 명에 이르진 않을 것입니다. (역자의 주 – 서울은 가능해 보이긴 하나, 저자의 도시의 기준으로 이해해 주시기 바랍니다.)

주문을 배치 처리하기 위한 수천 개의 위치를 그룹화하여, 검색하는 것은 좋은 아이디어입니다. (지방 또는 도시에서 발생한  주문을 배치 처리하고, 같이 배분하는 아이디어를 말함)  따라서 이 이론에 따라 우리는 도시 이름을 하이퍼 로컬 시스템의 파티션 키로 사용할 수 있습니다.

(배송 에이전트, 주문자) 디바이스의 현재 위치에서, 어떻게 도시 이름(파티션키)을 알아낼 수 있나요?

Google 지도는 현재 도시 및 관련 위치 정보를 식별하기 위해 Reverse Geo-Coding  API를 제공합니다. 이 API는 Android 및 iOS 앱에서 사용할 수 있습니다.

개선된 새 아키텍처

배송 에이전트의 현재 위치는 대부분 동적으로 변하므로,  모바일 장치의 최신 위치로  지속적으로 서버에 전달(핑하도록) 할 수 있습니다.

핑은 10초마다 발생할 수 있습니다. 또한 서버가 배달 에이전트 디바이스에서 수신한 현재 위치는 10초 후에 만료되므로, 오래된 위치 정보 데이터는 저장하지 않습니다. 그램 3은 개선된 새로운  아키텍처입니다.

그림 2에 설명된 이전 아키텍처에서 일부를 변경하여 개선된 아키텍처를 생각해 냈습니다. (역자의 주 – 원문은 그림 1에서 개선했다고 했으나, 흐름상 그림 2가 적합해 보임)

도시 이름 기반의 위치 데이터 샤딩 체계를 도입했습니다. (도시 이름에 충돌이 발생할  위험이 있는 경우, 도시 ID를 사용할 수도  있음)우리는 위치 데이터들을  여러 개의 논리적 샤드로 나눕니다. 서버 또는 물리적 머신은 많은 논리적 샤드를 포함할 수 있습니다. 논리적 샤드에는 특정 도시에만 속하는 모든 위치 데이터가 포함됩니다. 이 할당 전략에서 큰 도시에는 많은 양의 위치들이 포함되는 반면 작은 도시에는 적은 양의 위치들이 포함될 수 있습니다.

이러한 샤드를 관리하고, 가능한 모든 캐시 서버에 균등하게 로드 균형을 맞추기 위하여 중앙 메타데이터 레지스트리(central metadata registry)를 사용하고 있습니다. 메타데이터 레지스트리에는 도시 이름에서 논리적 샤드 ID로의 매핑, 논리적 샤드 ID에서 메모리 내 인덱스 서버 ID로의 매핑이 포함되어 있습니다. (서비스 검색 메커니즘을 사용하여 서버 ID를 사용하여 서버의 IP 주소를 얻을 수 있습니다. 역자의 주: 해당 부분은 이 글의 논의 범위를 벗어남.)

City to shard mapping:
''''''''''''''''''''''''''

city           shard_id
''''''''''''''''''''''''''
Bangalore        101
Hyderabad        103
Mumbai           109
New York         908
San Francisco    834

Shard to Physical server mapping
''''''''''''''''''''''''''
shard_id       index_server
''''''''''''''''''''''''''
101             index-1
103             index-2
109             index-1
908             index-3
834             index-2

한개의 샤드(예: index-1) 콘텐츠(위치 개체)는 다음과 같습니다.
"San Francisco":
[    
  { 
  "agent_id": 7897894,        
  "lat": 89.678,        
  "long": 67.894    
  },     
  {        
  "agent_id": 437833,        
  "lat": 88.908,        "
  long": 67.109    
  },    
... 
]

읽기 및 쓰기 요청 둘 다(먼저 요청 대상의 IP 주소를 사용하여) 메타데이터 레지스트리와 통신하여 배송 에이전트가 정확히 어느 도시에 있는지 또는 고객 요청이 어디에서 왔는지 확인합니다.

(IP에서)변환된 도시(도시 ID)를 이용하여 shard id를 식별하고, shard id를 이용하여 index server를 식별합니다. 마지막으로 요청은 특정 인덱스 서버로 전송됩니다. 따라서 더 이상 모든 캐시/인덱스 서버를 조회할 필요가 없습니다. 이 아키텍처에서는 읽기 또는 쓰기 요청이 데이터 저장소와 직접 통신하지 않으므로 API 지연 시간이 훨씬 더 줄어듭니다.

또한 그림 3의 아키텍처에서  소비자가 해당 위치 데이터를 선택하고 타임스탬프 또는 주문 ID 등과 같은 적절한 메타데이터로 데이터베이스를 업데이트하는 큐에 데이터를 넣습니다. 이것은 필요한 경우에 대비하여 이력을 추적하고 배달원의 이동 경로를 추적하기 위해서만 수행됩니다. 하지만 이내용은 이번 아키텍처에서 부차적인 부분이라 언급하지 않겠습니다

역자의 주 – 데이터를 큐에  넣어서 이후 업데이트하는 이유는 한 건씩 직접 DB에 업데이트하면 락이 빈번하게 발생하며 성능 저하가 발생한다. 보통 데이터를 개별적으로 한 건씩 넣는 것보다  1분 또는 10초와 단위 시간마다 묶어서 일괄 배치 처리하는 게 훨씬 DB의 부하를 줄일 수 있다.  

중앙 레지스트리에서 정적 파티션을 관리하는 것이 파티션을 관리하는 가장 간단한 방법입니다. 캐시 서버 중 하나에 부하가 많아지는 경우, 부하가 많이 발생하는 시스템(인스턴스)에서 다른 시스템(인스턴스)으로 논리적 파편의 일부를 이동하거나 새 시스템(인스턴스)를 할당할 수 있습니다.

비록 파티션을 조작하고 이동하는  정책이 자동화되어 있지 않고 사람의 개입이 요구되더라도  보통은 운영적인 실수를 일으킬 가능성은 매우 적습니다. 그러나 일반적인 성장, 비정상적인(월드컵 등) 성장이 발생할 경우도 있습니다. 수천 대의 물리적 시스템이 있을 때 정적 파티션을 관리하는 것은 어려움이 될 수 있으므로 자동화된 파티셔닝 체계를 살펴보고 이러한 활용 사례가 만족하는 도구를 개발해야 합니다. (역자의 주: 성장의 속도를 고려하여, 파티셔닝을 수동으로 할 것인가? 자동으로 할 것인가?)

파티션 키로 도시를 선택하면 어떤 트레이드 오프가 있습니까?

현재 배달 에이전트 중 한 명이 두 도시의 경계 근처에 있을 가능성이 매우 높습니다. 예를 들어 그는 A 도시에 있는데 이웃 도시 B에서 주문이 들어오고 배달 에이전트와 도시 B의 고객과의 거리가 상당히 짧다고 가정해 보겠습니다. 하지만, 안타깝게도 배달 에이전트는 도시 B에 없기 때문에 우리는 에이전트를 파견할 수 없습니다. 따라서 때때로 도시 기반 파티셔닝이 모든 사용 사례에 최적이 아닐 수 있습니다. 또한 크리스마스나 새해와 같은 특정 행사에 대한 도시의 수요가 증가함에 따라 특정 도시 기반의 샤드는  매우 많은 부하가 발생할 수도 있습니다.  이 전략은 하이퍼 로컬 시스템에서 작동할 수 있지만 Uber와 같은 매우 큰 스케일(범위)를 가진 시스템에서는 적합하지 않습니다.

다음 영상에서는 이러한 문제를 해결하기 위한  Uber의 전략에 대해 상세히 알수  있습니다.

역자의 가이드

14분터 시작하는  Hot Spot 부분부터 참고하시기 바랍니다.간단히 요약하자면,  긴 특정지역에 운전자와 라이더(고객)이 몰리면 Sub Sharding 전략과 복제의 전략을 이용해서 부하를 분산하는 전략을 사용하고 있다는 것입니다.

단 복제본을 만들 경우 NRT (near real time)에 준하는 복제 방식을 선택하는지 엄격한 Consistency를 적용하는 지는 알 수 없지만 전자를 선택해도 상관없을 것으로 유추됩니다.

이유는 모든 드라이버 데이터를 엄격한 일관성으로 관리하는 것은 많은 성능 저하를 가져오기 때문입니다. 또한 샤드에서 수십, 수백 명의 드라이버(운전자)중 한,두 명이 동기화되지 않아도 현재 저장되어 있는 운전자 리스트에서만 고르면 되므로 큰 이슈가 아닐 것으로 생각됩니다.

물론 동기화가 완벽하게 안되어 예외적인 요청이 갈수 있는데 이것은 승객을 태우고 있는지, 그 위치에 벗어나지 않는지 한 번 더 체크하고 호출하는 추가적인 예외 처리가 더 필요해 보입니다

파티션 중 하나가 충돌하면 어떻게 되나요? 어떻게 데이터를 복구해야 하나요?

위치 데이터는 매우 동적이며, 시스템에서 몇 초 동안만 유지되기 때문에(만료 시간이 짧기 때문에) 파티션이 충돌한 후 복구되거나, 수동으로 페일오버(복구전략)를 수행하면 됩니다. 클라이언트 장치에서 시스템으로 지속적으로 스트리밍되므로 데이터가 자동으로 다시 축적됩니다.

그럼 수백만 개에서 수 십억 개의 위치를 분할하여, 탐색할 수 있는 다른 방법이 있을까요?  3편에서 다루어 보겠습니다.

이번 시간은 아키텍처 전략: 실시간 위치 검색을 위한 지리 공간 인덱스 설계 시리즈 첫 번째 시간으로 개요 및 아키텍처에 대해 다루었습니다.

1. 개요 및 아키텍처
2. 샤딩으로 아키텍처 개선하기
3. Geo Hash를 이용하여 아키텍처 개선하기

소개

우리는 실생활에서 항상 실시간 위치 검색 서비스를 사용합니다. 음식 주문 앱이나 주문형 택시 예약 서비스는 요즘 어디서나 볼 수 있죠. 이 글의 목적은 실생활에서 지리 공간 인덱스(Geo-spatial Index)에 대한 백엔드 인프라를 설계하는 방법을 살펴보는 것입니다.

공간을 다루는 여러 회사가 어떻게 문제를 해결했는지, 다양한 접근 방식의 장단점은 무엇인지, 어떻게 문제에 접근했는지 다루어보겠습니다.  또한 시스템 및 아키텍처 설계 기술 인터뷰 관점에서 문제에 접근하는 방법에 대해서도 알아보겠습니다.

실제 사용 사례

1. Uber, Lyft, Bolt와 같은 실시간 택시 예약 서비스
2. Yelp와 같은 실시간 호텔/레스토랑 검색
3. 마케팅 프로모션을 위해 특정 매장 근처에 있는 쇼핑객을 대상으로 하는 서비스
4. 하이퍼 로컬 배달 시스템 — Uber Eats와 같은 레스토랑 주문에 대해 배달 에이전트를 파견하는 서비스

설계 요구 사항

1. 우리의 서비스는 전 세계적으로 사용됩니다.
2. 클라이언트 또는 사용자가 위치를 지정하면 당사 서비스는 특정 수의 주변 위치를 파악해야 합니다.
3. 인프라는 안정적이어야 합니다.
4. 시스템은 200ms 이하로 응답해야 합니다. 따라서 지연 시간을 줄이기 위한 설계는 큰 관심사입니다.
5. 초당 50,000개의 읽기 쿼리와 초당 10,000개의 쓰기 쿼리를 지원해야 합니다.
6. 사용자가 증가함에 따라 시스템은 큰 부담 없이 선형적으로 확장되어야 합니다.
7. 단순화를 위해 위치가 제목, 설명, 유형, 위도 및 경도 (title, description, type, latitude& longitude )로 표시된다고 가정합니다.
8. 시스템은 MULTI-TENANT가 아닙니다.
9. 클라이언트는 일반적으로 모바일 클라이언트이지만 웹 클라이언트도 있을 수 있습니다.

정량적 분석 (Quantitative Analysis)

2억 개의 위치(location)에서 시작한다고 가정해 보겠습니다. 성장률이 매년 25%일 때, 다음 몇 가지 추정 치를 보여드리겠습니다.

스토리지 측정 (Storage Estimation)

말했듯이 위치는 타이틀, 유형, 설명, 위도, 경도(title, type, description,lat, long)로 표시됩니다.

이러한 모든 매개변수에 대해 합리적인 숫자를 가정해 보겠습니다.

제목=100바이트, 유형=1바이트, 설명=1,000바이트, 위도= 8바이트, 길이= 8바이트  (title = 100 bytes, type = 1 byte, description = 1000 bytes, lat = 8 bytes, long = 8 bytes)

따라서 단일 위치에는 최소한 다음의 용량이 필요합니다(100 + 1 + 1,000 + 16) bytes = ~1,120 bytes = ~1,200 bytes

2억 개의 위치를 기반으로 서비스를 시작한다면, 다음과 같은 용량이 필요합니다 200 * 10⁶ * 1200 bytes = 240GB(Gigabytes)

매년 25%의 성장률로 5년을 계획한다면 다음과 같은용량이 필요합니다.

1년 차: 240GB2년 차: (240 + 240 * .25) = 300GB3년 차: (300 + 300 * .25) = 375GB4년 차: (375 + 375 * .25) = ~470GB5년 차: (470 + 470 * .25) = ~600GB

데이터 저장소에 위치 정보를 저장하기 위해서는 최소 600GB의 저장소가 필요합니다. 사용 사례에 따라 저장해야 할 다른 메타데이터/보조 정보나 검색 또는 쿼리 작업을 용이하게 하기 위해, 데이터 저장소 내부에 저장해야 하는 메타데이터를 고려하면  실제로 더 많은 스토리지가 필요할 수 있습니다.  따라서 스토리지를 최소 1TB로 추정해 보겠습니다.

그렇다면 1TB의 데이터를 저장하려면 몇 대의 시스템이 필요할까요? 현재 AWS 또는 Azure에는 비용 및 사용 사례에 따라 16TB에서 64TB의 스토리지를 제공할 수 있는 많은 데이터베이스 시스템 유형이 있습니다. 따라서 이상적으로 1대의 기계로 사용 사례를 지원하기에 충분합니다. 하지만 성장률이 높거나 인기가 높아지면 스토리지 또는 시스템이 더 필요할 수 있습니다. 그럼에도 불구하고, 우리는 수평적 확장(horizontal scaling)을 지원하도록 인프라를 설계할 것입니다.

역자 주 : 용량 산정만큼 , 실제 IOPS (IO per Second)의 산정도 중요하다.  사용자가 늘어남에 따라 초당 얼마큼의 IO를 처리할 수 있는지, 디스크에 어떻게 이 IO를 분배할지에 대한 전략도 같이 고민되어야 한다.

인터뷰 팁: 실제로는 예상 성장률이 확실해지면 자세한 스토리지 요구 사항을 제시할 수 있습니다. 일반적으로 엔지니어링팀과 제품팀이 협력하여 수치를 산출합니다. 하지만 인터뷰에서는 상당한 시간이 소요될 것이기 때문에 계산할 필요가 없습니다. 첫 해에 계산하고 어떤 숫자로 추정할 수 있습니다. 충분히 합리적인 데이터 크기와 증가를 염두에 두고 데이터를 기반으로 결정을 내리고, 불합리한 숫자를 버리지 말고, 너무 많은 수치를 벗어난 추정은 좋지 않다는 것을 면접관에게 보여주기 위한 것입니다.

읽기가 많은 시스템 vs 쓰기가 많은 시스템

요구사항은 이미 초당 50,000 읽기 쿼리와 10,000 쓰기 쿼리를 지원해야 한다고 명시되어 있습니다. 따라서 우리 시스템은 읽기:쓰기 비율 5:1로, 극도로 읽기가 많다는 것은 이미 정해져있습니다.

요구 사항에 읽기에 대한 설명 또는 힌트가 없는 경우 어떻게 해야 할까요? 읽기/쓰기 비율은 어떻게 결정하시겠습니까?

우선, 어떤 종류의 시스템을 설계하고 있는지 고려해야 합니다. Facebook 뉴스피드 또는 Twitter Timeline은 읽기와 쓰기가 많은 시스템입니다. Google 검색 또는 트윗 검색 시스템과 같은 것을 설계하는 경우는 읽기가 매우 많은 시스템이고, 로그 전달 애플리케이션을 설계하는 경우 쓰기가 매우 많은 애플리케이션입니다. 또한 얼마나 많은 DAU(일일 활성 사용자)가 있는지, 그들이 생산하고 있는 콘텐츠의 양과 매일 소비하고 있는 콘텐츠의 양을 고려해야 합니다. 여기서 말씀드린 대로 추측해 보세요. 시스템이 읽기가 많은지 쓰기가 많은지 추측하실 수 있을 겁니다.

인터뷰 팁: 시스템 설계 인터뷰에서 다양한 시스템의 DAU에 대해 이야기하기 전에 DAU, 일일 트윗, 매일 얼마나 많은 사진/동영상이 Facebook 또는 Twitter에 업로드되는지와 같은 필요한 정보 목록을 작성합니다. YouTube 등 또는 Google이 크롤링하는 웹사이트 수 또는 Yelp가 매일 다양한 시스템에 대해 서비스를 제공하는 사용자 수 등 이러한 애플리케이션에 대한 읽기 및 쓰기의 일일/월간 통계 목록을 만들어 보세요.

사용 규모에 대해 모르는 경우, 명시된 시스템이 얼마나 많은 사용자 또는 읽기/쓰기를 가질 수 있는지 대략적으로 생각하여 면접관과 함께 확인해 보세요. 면접관들은 보통 여러분의 예상이 옳다고 생각하는 것과 약간 어긋날 경우에 대비하여 여러분의 측정 기준에 도움을 줍니다. 하지만 직접적으로 묻지 말고, 대략적인 적절한 수치를 던질 수 있는 첫 단계를 밟으세요  DAU와 연관된 매개 변수로부터 추정치를 도출해 보고 나서 물어보세요.

더 중요한 것은 모의 인터뷰를 연습하거나, 다른 사람의 모의 인터뷰를 자주 시청하여 이러한 수치와 아이디어에 익숙해지는 것입니다.

네트워크 밴드위스(Network Bandwidth) 측정

대역폭 및 처리량 계산을 수행하려면 네트워크를 통해 전송하는 데이터의 양을 알아야 합니다. API Signature(명세)을 결정해야 제대로 판단할 수 있습니다. 다음 섹션을 살펴보겠습니다.

네트워크 프로토콜 선택

앞서 언급한 요구사항에서, 웹&모바일 클라이언트를 지원해야 되다고 명시하고 있고 있습니다.  타사 개발자가 인프라와 통합해야 하므로 개발자 친화적이고 사용하기 쉽고 이해하기 쉬운 프로토콜을 선택해야 합니다.  다음과 같은 여러 가지 옵션들이 있을 수 있습니다. (SOAP, RESTful API over HTTP 또는 RPC API)

SOAP: 꽤 오래되고 복잡하며, 중첩된 스키마이며 일반적으로 요청과 응답을 표현하는 데 XML이 사용됩니다. 개발자에게 그다지 친숙하지도 않습니다. SOAP은 선택하지 않겠습니다.

RPC: 동일한 데이터 센터에서의 통신에 적합한 사용 사례에 적합하며 RPC는 클라이언트 및 서버 측 스텁을 생성해야 밀접하게 연결됩니다. 필요한 경우 클라이언트-서버 통합을 변경하는 것은 어려울 것입니다. 그래서 우리는 RPC도 선택하지 않을 것입니다.

HTTP 기반의 Restful API: 이것은 오늘날 사실상의 표준입니다. 개발자 친화적이며, 대부분의 개발자들은 커뮤니티에서 잘 이해된 요청/응답을 표현하기 위해 JSON 스키마를 사용하며, 필요할 때 새로운 API 버전을 통합하고 도입하기 쉽습니다. 이러한 이유로, 우리는 HTTP를 사용하여 API를 RESTful API로 설계를 진행할 것입니다.

API 시그니처 (명세)

우리의 시스템을 외부에 노출하기  위해,  필요한 요청과 응답을 위한 최소한의 API 구조를 결정해야 합니다.

Get Location (API)

Request(요청): 우리는 위치 기반 시스템을 설계하고 있기 때문에 클라이언트에서 가져와야 하는 최소한의 데이터는 경도 및 위도(longitude & latitude)입니다. 또한 클라이언트가 검색할 최대 반경(maximum radius)을 지정할 수 있는 유연성을 지원하는 경우 반경(radius)을 입력으로 사용할 수 있습니다. 또한 우리는 클라이언트가 관심 있는 일치하는 위치의 max_count를 취할 수 있습니다. 따라서 GET HTTP API는 아래와 같을 수 있습니다.

인증 시스템이 이미 구축되어 있다고 가정하므로 여기에서는 인증에 대해 고려하지 않겠습니다

radius & max_count 매개 변수는 선택적 매개 변수입니다. 또한 클라이언트가 GET 위치 API에 값을 지정하거나 지정하지 않을 경우, 애플리케이션 서비스에 최대 허용 반경 또는 위치 수를 정확하게 결정할 수 있는 비즈니스 로직이 있다고 가정하겠습니다

Response (응답) : 응답은 다음과 같습니다

응답의 위치 리스트(결과)에는 클라이언트가 지정한 최소 max_count 또는 제공된 위치에 대해 시스템에서 사용할 수 있는 모든 항목이 포함될 수 있습니다.

Create Location API

마찬가지로 다음과 같이 위치 API를 만들 수 있습니다:

위 POST API는 단일 위치 또는 여러 위치를 만드는 데 사용할 수 있는, 대량 API입니다. 대량 API가 필요한지 단일 개체 API가 필요한지 여부는 클라이언트가 시스템에서 원하는 것에 따라 달라질 수 있습니다.

인터뷰 팁: 인터뷰에서 대량 API가 필요한지 여부를 명확히 해야 할 수 있습니다. 그렇다면 목록에서 지원하는 위치 개체 수를 명시해야 합니다. 시스템의 처리량이나 네트워크 효율성에 영향을 미치기 때문에 개체 수를 유연하게 보낼 수 없습니다.

응답 코드(response code)는 202 ->이는 시스템이 API의 잠재성(조건을 충족하지 못하는 것 – 예 속도 지연, 일관성 없는  결과 반환 등)을 줄이기 위해 요청을 비동기식으로 처리하는 것을 의미합니다.

이제 API 요청 및 응답 스키마가 명확하므로 네트워크 대역폭 및 처리량 계산을 수행해 보겠습니다.

네트워크 밴드위스(Network Bandwidth)  측정

GET API 대역폭 (bandwidth)GET 위치 API의 경우 응답 목록에서 최대 30개의 위치를 지원한다고 가정해 보겠습니다. 따라서 단일 응답 객체 크기는 다음과 같습니다.

id(int를 고려한 4bytes) + title (100 bytes) + description (1000 bytes) + lat (8 bytes) + long(8 bytes) = 1120 바이트.

30개 위치의 경우 응답 헤더 및 모두와 같은 추가 메타데이터를 고려하여 1120 * 30 bytes = 33.6 Kilobytes = ~35 Kilobytes를 보내야 합니다.

따라서 단일 GET 요청은 35KB의 대역폭을 사용합니다. 50000 GET 쿼리를 지원하는 경우 초당 35 * 50000 KB = 1.75 GB = ~ 초당 2GB의 데이터를 지원해야 합니다.

POST API 대역폭초당 10000 쓰기 요청을 지원해야 합니다. 대량 쓰기 (bulk write) 및 클라이언트가 API 호출당 최대 30개의 위치를 업로드하는 것을 고려하여 다음과 같이 처리량을 지원해야 합니다.

10000 * (30 * (title(100 bytes) + description(1000 bytes) + lat(8 bytes) + long(8 bytes))) = ~350 MB per second. (초당 350MB)

이것은 상당히 작지만 성장과 함께 이 수치는 증가할 수 있습니다.

따라서 읽기 및 쓰기 쿼리를 결합하면 (1.75GB + 350MB) = 초당 ~2.1GB 데이터 전송을 지원해야 합니다.

시스템이 점점 더 성장할 것이기 때문에, 이러한 처리량을 달성하기 위해 애플리케이션 서버 전체에 로드를 분산해야 할 수도 있음을 의미합니다.

인터뷰 팁: 인터뷰에서 너무 많은 계산을 수행하면 완료하는 데 시간이 오래 걸릴 수 있습니다. 따라서 면접관에게 그러한 대역폭을 추정할 필요가 있는지 물어보세요. 일반적으로 스토리지 및 네트워크 대역폭 계산은 인터뷰에 충분해야 합니다. 정확할 필요는 없지만 빠르고 편안하게 계산할 수 있도록 여러 사용 사례에 대해 연습해야 할 수도 있습니다.

데이터베이스 스키마

높은 수준의 디자인을 할 때 데이터베이스 스키마에 대해 생각하는 것은 매우 자연스러운 일이지만 Use Case(사용 사례)에 대해 먼저 생각하고 다음 질문을 스스로에게 물어보세요.

어떤 종류의 위치 데이터를 저장하고 있나요? 정적인가요? 동적인가요?

레스토랑 위치와 같이 데이터가 정적인 경우 이러한 위치는 대부분 정적이므로 해당 위치 데이터를 데이터 저장소에 넣는 것이 좋습니다.위치 데이터가 택시 위치 또는 배달원 위치와 같이 매우 동적이며 해당 위치가 지속적으로 시스템에 푸시되는 경우 이러한 목적 또는 그 목적을 위해 추적을 활성화하지 않는 한 영구 데이터 저장소에 저장하는 것은 이치에 맞지 않습니다.

이제 데이터 저장소를 사용해야 한다는 것을 깨달았다면 어떤 종류의 저장소를 보고 있나요?

이것은 논쟁의 여지가 있는 주제입니다. 무엇을 선택할지는 데이터 모델 및 데이터 액세스 패턴에 따라 다릅니다.  관계형 저장소와 비 관계형 저장소 간에는 많은 논쟁이 있습니다. 그러나 항상 간단하게 시작할 수 있습니다. 테이블 형식이나 관계형 형식으로 데이터를 시각화하는 것이 항상 더 쉽습니다. 데이터 모델에 따라 다양한 데이터베이스 기술을 탐색, 벤치마킹 및 데이터와 비교하고 해당 기술에서 사용 사례에 대한 지원을 찾지 않는 한 하나를 선택하기가 어렵습니다.이 시점에서 지금 당장은 특정 기술을 선택하지 않고 데이터 저장소에 저장해야 하는 최소한의 데이터 구조가 무엇인지 식별하는 작업을 진행하겠습니다.

데이터 저장소에도 동적 데이터를 저장할 수 있나요? 거기에 무엇이 문제가 될까요?

우리는 저장할 수 있지만 삽입 또는 업데이트 속도가 매우 높아 본질적으로 디스크/IO 사용 측면에서 시스템 비용이 매우 많이 들고 더 큰 규모에서는 쓸모가 없게 됩니다. 이 기사의 뒷 부분에서 완전한 동적 데이터를 처리하는 방법을 살펴보겠습니다.

데이터베이스 스키마는 어떻게 생겼나요?

현재로서는 상당히 일반적인 다음 스키마를 저장할 수 있습니다. 데이터베이스 기술에 따라 데이터 유형과 크기가 변경될 수 있지만, 설계 검토자나 면접관에게 원하는 바를 잘 보여줄 수 있습니다. 필요한 경우 나중에 수정할 수 있습니다.

인터뷰 팁: 인터뷰에서 관계형 또는 비관계형 데이터베이스를 선택할지 여부는 항상 뜨거운 질문입니다. 많은 사람들이 읽기 부하가 높기 때문에 비관계형 데이터베이스가 여기에 잘 맞을 것이라고 맹목적으로 말합니다. 이것은 완전히 정답이 아닙니다. No-SQL은 마술처럼 확장되지 않습니다. 약간의 운영 부담이 있습니다.  일반적으로 좋은 기능인 애플리케이션 지정 키(application specified key)에 의한 샤딩 지원을 기본 제공합니다.

기술을 선택할 때 데이터가 데이터베이스 시스템에서 제공하는 데이터 모델에 맞는지, 데이터베이스 시스템이 얼마나 많은 커뮤니티 지원을 받는지, No-SQL의 경우 내부 파티셔닝 체계가 실제 환경에서 어떻게 작동하는지를 고려해야 합니다.

워크 로드 (작업 부하) 등 또는 사용 사례에 적합한지 확인합니다.  읽기 로드 또는 규모만 기준으로 데이터베이스를 결정하는 것은 논리적이지 않습니다. 매우 높은 규모의 시스템에서는 데이터베이스만 전체 로드를 처리하지 않는다는 점을 기억하세요.

이 글의 뒷부분에서 함께 로드를 공유하고 시스템을 구성하는 여러 가지 구성 요소를 볼 수 있습니다. 데이터 저장소는 그 일부일 뿐입니다. 또한 많은 대기업에서 많은 주요 사용 사례에 RDBMS를 사용합니다. 따라서 관계형 시스템이든 비관계형 시스템이든 관계없이 데이터베이스 기술이 기존 회사 인프라뿐만 아니라 사용 사례의 환경에 어떻게 적합한지 확인해야 합니다. 또한 비용 및 운영 우수성은 고려해야 할 매우 중요한 또 다른 요소입니다.

인터뷰 상황에서는  모든 사람이 RDBMS를 이해하고 있으므로, 나중에 목적에 맞는 적절한 기술을 선택할 것이라고 말하고,  RDBMS로 가정하고 시작하셔도 됩니다.

High Level Design(고수준 설계)

이제 사용 사례(Use Case) 및 기대치, 추정에 대한 적절한 아이디어가 있으므로 이제 높은 수준의 설계를  도출 할수 있습니다.

그림 1은 시스템의 가장 기본적인 HLD (고수준 설계)를 보여줍니다. 트래픽을 허용하는 Load Balancer(로드밸런서) 뒤에 배치된 애플리케이션 서버가 있습니다. 이러한 앱 서버는 API 정의와 함께 배포됩니다.  API 구현은 데이터베이스에 연결하고, 결과를 가져오고, 응답을 형성하고 클라이언트에게 다시 반환합니다.

여기에  Load Balancer(로드밸런서)가 필요한 이유는 무엇인가요?

초당 50,000개의 읽기 쿼리를 처리해야 하므로 최악의 경우 모든 트래픽이 동일한 지역에서 오는 것을 고려하면 단일 서버에서 해당 부하를 관리하기 어려울 것입니다. 따라서 부하를 공유할 수 있는 상태 비저장 애플리케이션 서버가 필요합니다. 따라서 로드 밸런서가 필요합니다.

어떤 종류의 Load Balancer(로드밸런서)인가요? 하드웨어인가요? 소프트웨어인가요?

우리의 기존 인프라 및 비용 최적화 기술에 달려 있습니다. 소프트웨어 부하 분산 장치는 하드웨어 부하 분산 장치보다 비용이 적게 듭니다. 하드웨어 로드 밸런서는 특별한 하드웨어 요구 사항이 있을 수 있지만 , 소프트웨어 요구 사항보다 더 효율적이고 고급입니다. 그러나 아직 표준이나 선택 사항이 없는 경우 HAProxy와 같은 소프트웨어 로드 밸런서를 선택하는 것이 좋습니다.AWS에서 서비스를 생성하는 경우 AWS 자체에서 프로비저닝된 HAProxy 로드 밸런서를 얻을 수 있습니다. 레이어 7 애플리케이션 로드 밸런서와 같은 정교한 로드 밸런서가 필요하지 않으며 단순히 레이어 4 또는 네트워크 로드 밸런서를 사용할 수 있습니다.

데이터베이스에 무엇을 넣어야 하나요?

API 정의에서 JSON 형식의 위치 개체 목록을 사용하는 것을 확인했습니다. 우리의 데이터베이스 스키마는 또한 API와 거의 일치하게 구성했습니다. 따라서 해당 위치 데이터를 데이터 저장소에 간단히 저장할 수 있습니다. -> 데이터 저장소에 저장하기 전에 해당 데이터에 대한 일부 유효성 검사, 변환 또는 비즈니스 논리 구현이 필요할 수 있습니다.

데이터베이스에서 무엇을 쿼리하고 있나요? 쿼리는 어떻게 동작하나요?

이것은 지금까지 다룬 질문 중, 가장 흥미롭고 까다로운 질문입니다. 우리는 단순히 데이터 저장소를 사용하고 있기 때문에 수행하는 쿼리는 사용하는 저장소에 따라 다릅니다. 데이터 저장소가 기본 지리적 위치 쿼리를 지원하는 경우 해당 쿼리를 작성하여 애플리케이션 로직에서 가까운 위치를 검색할 수 있습니다.

그러나 모든 데이터 저장소가 위치 쿼리(location query)를 지원하는 것은 아닙니다. MySQL과 같은 기존 RDMS 시스템은 기본 위치 쿼리(location query)를 지원하지 않습니다.그럼에도 불구하고 우리는 초당 최소 50,000개의 읽기 쿼리를 지원하고 있기 때문에 대기(지연)시간이 200ms 이하라는 제약 조건으로 인해, 네트워크 또는 디스크 IO 병목 현상이 발생할 수도 있습니다. 그래서,  데이터 저장소에서 항상 검색을 수행하는 것은 사실상 불가능합니다.또한 우리가 사용하는 데이터 저장소에 관계없이 위치 쿼리를 원활하게 관리할 수 있는 방식으로 시스템을 설계하는 것이 좋습니다. 이제 우리의 문제는 다음과 같습니다.

데이터 저장소가  규모가 커짐에 따라 많은 부하를 처리할 수 없는 상황에서도 (기본적으로 지원하지 않거나 지원하더라도) 위치를 검색 가능하게 만드는 방법은 무엇인가요?

위치 검색을 좀 더  쉽게 하기 위해  다양한 접근 방식에 대해 이야기해 봅시다.

접근 방법 1:  메모리에서 위치 및 검색을 캐싱 하기

우리의 초기 데이터 크기는 대략  240 GB이며 가까운 미래에 그 이상으로 600 GB로 커질 수 있습니다. 대규모 읽기 쿼리를 지원해야 하므로 적극적인 캐싱 전략을 수행해야 합니다. 그렇다면 어떻게 해야 할까요?

우리의 의도는 가능한 한 캐시를 쿼리하고 데이터베이스에 대한 부하를 줄이는 것입니다. 우선 캐시 머신의 메모리에 있는 240GB의 데이터를 모두 수용할 수 있나요?

네, 그렇게 할 수 있지만 비용에 따라 여러 대의 기계가 필요할 수 있습니다. 메모리 가 충분한 단일 시스템을 얻을 수 250+ Gigabytes있지만 비용 효율적이지 않을 수 있습니다. 그래서 우리는 각각 120 GB 메모리가 있는 2대의 캐시 머신을 가질 수 있고, 데이터를 2대의 머신에 나누어 배포할 수 있습니다.

캐시에 무엇을 저장하나요?

이 접근 방식에서는 모든 위치 쿼리에 대해 제공된 클라이언트(위도, 경도)와 모든 캐시 머신에 저장된 모든 위치 사이의 거리를 찾습니다. 모든 결과를 찾은 후 오름차순 거리 순서 및 고객이 제공한 기준(있는 경우)에 따라 위치 순위를 매깁니다. 이것은 기본적으로 무차별 대입 검색이며 완전히 메모리에서 수행하므로, 우리의 데이터베이스가 위치 쿼리를 지원하지 않는다면 데이터베이스에서 전체 작업을 수행하는 것보다 더 빠릅니다. 위치를 저장하는 형식은 중요하지 않습니다. 위치 ID를 키로 저장하고 위치 개체를 값으로 저장하거나 캐시가 개체 목록을 지원하는 경우, 위치 목록을 키로 저장하고 위치 목록 전체에서 검색할 수 있습니다.

캐시는 어떻게 로드되나요?

몇 분마다 실행되고 마지막 ID 또는 타임스탬프 이후 위치를 로드하는 예약된 작업을 수행할 수 있습니다. 이것은 실시간 프로세스가 아니므로 (POST 타입의) location API가 호출될 때 쓰기 경로도 위치 정보를 작성/업데이트하도록 할 수 있습니다.  다음 아키텍처에서 쓰기 경로에는 2단계가 있습니다. (아래 그림 2, 그림 3을 참고하세요)

1단계: 데이터베이스에 쓰기

2단계: 캐시에 쓰기

이제 쓰기를 순차적으로 실행할 수 있습니다. 데이터베이스가 정적 데이터에 대한 신뢰할 수 있는 소스이기 때문입니다. 먼저 데이터를 데이터베이스에 쓴 다음 캐시 클러스터에 써야 합니다.다음 아키텍처에서 캐시 로더는 조정 프로세스 역할을 하는 백그라운드 프로세스입니다. 쓰기 경로의 2단계가 실패하는 경우 캐시 로더는 데이터가 누락되었음을 발견하므로 데이터를 씁니다. 데이터가 이미 존재하는 경우 메모리 내 개체의 타임스탬프에 따라 로더는 데이터를 업데이트할지 건너뛸지 결정할 수 있습니다. 데이터베이스에 더 많은 업데이트된 데이터/더 높은 타임스탬프가 있는 경우 캐시의 데이터를 업데이트합니다.또한 캐쉬 로더는 “Follower 머신”에서 데이터를 읽습니다. 데이터베이스를 확장하는 방법일 뿐입니다. 모든 쓰기 작업은 “Leader”에서 발생하고 읽기 작업은 “Follow” 머신에서 발생합니다. 여기에는 트레이드오프가 있습니다. “Follower”는 “Leader”보다 몇 밀리초에서 몇 초 정도 늦게 데이터가 기록될 수 있습니다. 대부분의 실생활 사용 사례에서 동기식 복제가 아닌 비동기식 복제를 사용하기 때문입니다. 동기식 복제 속도가 느리기 때문입니다. 역자 주 – 동기식 복제 / 비동기식 복제라고 어렵게 표현을 했지만,  업계에서는   NRT- Near Real Time(실시간에 준하는) 복제를 하느냐, 아니면 Master – Slave에서 복제 중 Slave에 복제가 안될 경우 Rollback하게 엄격한 복제를 할지  고민을 해야 한다. MongoDB 같은 경우 WritingConcern을 이용해 Writing Level을 결정할 수 있다.  대부분은 성능적인 이슈로 NRT Replication을 사용한다.

캐시 머신을 분할하는 전략은 무엇인가요?

캐시 머신을 분할하는 많은 전략이 있지만 지금은 시스템을 더 단순하게 유지하고 캐시 머신이 완전히 채워지거나 임계값까지 채워질 때까지 캐시 머신을 계속 채우도록 하겠습니다. 기계가 가득 차면 다음 기계로 전환합니다.

캐시 시스템을 분할(partitioning)하는 전략은 무엇인가요?

캐시 머신을 분할하는 전략은 여러 가지가 있지만 지금은 시스템을 더 단순하게 유지하고 캐시 머신이 완전히 채워지거나 한계값까지 채워질 때까지 계속해서 캐시 머신을 채웁니다. 일단 하나의 머신(인스턴스)가 가득 차면 다음 머신으로 교체합니다.

이 전략에서 머신 전체의 캐시 로드가 불균형해질 것이라고 생각하지 않나요?

호텔/레스토랑 검색과 같은 시스템의 경우 매우 특정한 수의 레스토랑/호텔이 있고, 밤새 호텔/레스토랑 수가 갑자기 증가하거나 급증하지 않으므로 이 시스템이 잘 작동할 수 있습니다. 따라서 우리는 매우 상대적으로 정적인 양의 데이터를 가지고 있으며 이 데이터를 포함하기에 충분한 캐시 머신이 몇 개인지 이미 알고 있습니다.캐시 로더 백그라운드에서 동작하는  프로세스와 쓰기 경로(를 저장한) 캐시를 사용함으로 우리의 모든 캐시 머신은 데이터는 궁극적으로 채워질 겁니다. 지속적으로 데이터가 증가하는 경우 어쨌든 두 기계는  결국 요청을 hit (Cache Hit – 캐시에 데이터가 있어 DB까지 안 가는 상황) 하는 상황으로 가게 될 겁니다. 또는 이후 모든 (거리를 계산한) 위치 정보의 요청을 처리하게 될 겁니다. 따라서 이러한 캐시 채우기 전략은 주어진 상황에서 잘 작동합니다. 동적 데이터(움직이는 물체)에 대한 캐시 파티셔닝을 최적화하는 방법은 다음편에서 보도록 하겠습니다.

캐시 클러스터를 쿼리하는 방법은 무엇인가요?

병렬 스레드를 사용하여 캐시 머신을 쿼리하고, 데이터를 독립적으로 처리하고, 결합하고 응답을 생성할 수 있습니다. 따라서 Divide & Conquer 전략은 그림 2와 같습니다.

이 시스템을 더 개선하기 위해 우리는 무엇을 해야 할까요? 우리는 모든 location(위치) 요청을 모든 캐시 머신을 통해서 쿼리를 하고 있습니다. 이것은 값비싼 방법이죠. 혹시 더 나은 방법이 있을까요?

다음 편에는 위치정보를 처리하기 위해 점진적으로 개선된 사례를 공유하도록 하겠습니다. 또한 흥미로운 다른 아키텍처 사례도 공유드리니 참고해 주세요!

Uber 아키텍처와 시스템 디자인

트위터는 왜 모니터링 시스템을 다시 만들었나?

아키텍처 설계 프로세스는 말그대로 진행은 하면 되지만, 결국 많은 설계 기법을 알지 못하면 좋은 설계를 하지 못하는 상황이 빈번하게 발생했습니다.

2022년에 다음과 같은 강좌 들을 진행했습니다.

또한 후배들을 위해서도 한번 누군가는 정리를 해줘야 된다는 생각이 들었습니다. 이에 다음과 같은 패턴들을 정리하는 프로젝트르 진행했으며, 아직 초벌 수준이지만, 대규모 패턴 강좌가 업데이트 되었음을 말씀 드립니다.

Architecture 패턴 (POSA1)

큰 구조를 잡는 패턴들

이 패턴의 가치는 말씀 안드려도 잘 알거라 생각합니다. 패턴지향 소프트웨어 아키텍처 1권이라는 서적의 번역작업에 참여를 했었고, 현재 절판되어서 아쉬움이 큽니다.

GoF 디자인 패턴과 쌍벽을 이루는 패턴계의 명서인데, 아쉬움이 크네요.

특히 Broker 패턴, MVC, PAC 패턴등 소프트에어 설계 기법에 꼭 아셔야 하는 기법들이 잘 정리되어 있습니다. 아마 Broker 패턴 하나 만으로 1시간 이상 설명을 해야 되는 정말 중요한 패턴이지요.

저는 가볍게 1시간 분량으로 준비되어 있습니다.

Douglas Schmidth교수님의 소개 자료도 참고 바랍니다

분산 / 네트워크 서버 패턴 (POSA2)

분산 객체와 동시성을 어떻게 제어하나? 백엔드 프로그래머를 위한 패턴

이 패턴의 가치는 다들 잘 아시겠지만, Netty, WCF. .NET Remoting, EJB, COM+, CORBA와 같은 분산 객체 (Distributed Object)의 내부 구조를 설명하는 패턴입니다.

조금더 상세히 말씀드리면, Douglas Schmidth 교수님을 주축으로, ACT & TAO라고 하는 RealTime, 미션 크리티컬한 환경에서 사용된 분산객체를 40명정도 팀을 이루어 직접 개발을 하였고, 오픈소스로 공개하셨습니다. 더불어, 직접 내가 이렇게 설계했어리고 설명해 준 책이 바로 POSA 2 패턴입니다.

이 패턴을 이해하기 위해서는 다음과 같은 선수 지식들이 필요합니다.

• Common ORB Architecutre (CORBA)
• JAWS (어댑티브하게 구성을 변경할수 있는 Web Server)
• RealTime 환경에 배경 지식

총 6~7시간 정도의 시간이 소요될것으로 예측됩니다.

• 1시간으로 짧게 훑어보기 버전
• 3시간으로 배경 지식과 함께 깊게 이해해 보기
• 4시간의 Dispatcher 직접만들기 실습 (Client-Dispatcher, Reactor, Thread-Pool, Component Configurator, Proactor )
• Reactor/Proactor의 성능차이에 대한 이해

이 패턴에 대해서 핵심적으로 봐야 되는 두가지를 뽑으라면 저는 다음과 같이 가이드를 드릴수 있습니다 .

• 디스패처 (다양한 프로토콜이 추가되더라도 변경없이 확장하는 서버 만들기)
• 동기화 전략 ( 동시에 여러개의 요청을 처리하기 위해, 동기화 전략은 어떻게 가져가야 하나?)

특히 동기화 전략에서, Message Queue를 핸들링 하기 위한 기법들이 어떻게 보면 지금의 MQ 패턴의 씨앗이 되지 않았나 조심히 생각해 봅니다.

리소스 관리 패턴 (POSA3 – Resource Management Pattern)

제한된 자원을 어떻게 효율적으로 관리할까..

자원을 효율적으로 관리하기 위한 패턴입니다. (1시간 정도의 분량입니다.)

크게 3가지 파트로 나뉘어서 이 패턴을 나누어 설명할수 있습니다.

• 자원 획득을 위한 패턴 (Resource Acquisiton)
• 자원 수명주기를 위한 패턴 (Resource LifeCycle)
• 자원 해제를 위한 패턴 (Resource Release)

대용량 시스템을 위한 백엔드 설계 패턴 (AOSA)

오픈소스 기존 기술을 이용한 대용량 백엔드 아키텍처 구축하기

패턴계에는 POSA (Pattern Oriented Software Architecture)가 있다면, 오픈소스 진영에는 AOSA (Architecture of Open Source Application)이 있습니다.

오픈소스의 아키텍처를 공유한 서적인데요. 오픈소스 인만큼 모든 책 내용이 오픈되어 있습니다. 이 링크를 참고해서 보시길 바랍니다. http://aosabook.org/en/index.html

여기서 나오는 첫번째 챕터인 확장가능한 웹 시스템 만들기(http://aosabook.org/en/distsys.html)의 내용을 시작점으로 보강되었습니다. 책 내용에서는 단순히 아키텍처만 언급되어 있는데, 이러한 아키텍처를 만들기위해 사용할수 있는 COTS , 즉 오픈소스에 대한 추천과 이들을 사용하는 방법에 대해서 참조할만한 가이드를 같이 제공하고 있습니다.

• Google Photo 같은 이미지 공유 서비스를 만든다면?
• 기본개념 (서비스 구축, 이중화, 파티셔닝)
• 빠르게 접근,확장하기 ( Cache, Proxy, Index)
• 메세징 처리 기법 (Queue)
• 다양한 데이터 베이스 톺아보기
• 다양한 아키텍처의 적용 예 (OLTP, OLAP, Lambda, Kappa, Uber와 같은 Geo-Based Architecture)
• Netflix Devops 운영사례 / (실제 운영중인 모바일 APM – IMQA 운영사례는 이후 공유)

Cloud + MSA 패턴

클라우드 환경에서 다양한 오픈소스로 아키텍처 구축하기

이 패턴은 크게 아래 3가지 컨텐츠를 기반으로 정리를 했습니다. (2시간 분량)

• 1. 저희 PLoP 패턴학회에서 첫 발표한 Micro Service 패턴, 저도 이때 PLoP 컨퍼런스에 참여를 했는데, 정작 제 발표라서, 이 패턴을 듣지 못했어요.
• 2. Mind-mapping MSA Design Pattern 조금더 디테일하게 연관관계가 잘 나와있었던거 같아요
• 3. 정말 대단하다고 말을 할수 밖에 없는 Microsoft의 선 구안을 느낄수 있는, Cloud Design Pattern 을 기반으로 정리했습니다. 대단하고 말하는 이유가 2016년도에 처음 이 패턴을 발표 했거든요.

여튼 큰 뼈대는 가져왔어도, 상세 내용은 제가 찾아보고, 직접 정리를 했습니다.

아시다시피 위 패턴들에는 구체적인 컴포넌트들이 안나와있어서, Chatgpt와 함께 토론하면서 핵심 컴포넌트들을 나름 도출해 봤습니다.

고 가용성 확보를 위한 Fault Tolerance 패턴

죽지않는 시스템을 만들려면.. 어떠한 개념을..

제가 처음 PLoP 컨퍼런스에서 패턴을 발표할때, 저의 가이드(목자)가 되어주신 Robert S. Hanmer님의 Fault Tolerance 패턴입니다. 이 책을 번역을 하기로 마음을 먹고 이야기를 나누었는데, 특정 출판사가 독점으로 가지고 있고, 인쇄 부분이 서로 맞지 않아서, 번역을 포기한 기억이 납니다.

마음이 너무 아픈 서적이고, 이 서적이 국내에 번역이 되면 크게 도움이 될거 같다는 생각은 많이듭니다. 총 300페이지가 넘는 양인데, 일단 이중에 도움이 될만한 것을 추려서, 1/3 정도 공개를 했습니다.

실제 본 수업시간은 1시간 30분 ~ 2시간 사이가 될듯 합니다.

맺음

일단 몇몇 패턴들은 저의 지식이 아직 완전하지 않아, 계속 업데이트 중입니다. 시간이 되면 정리를 하도록 하겠습니다.

그리고 강의비는 일전에 아키텍처및 성능 튜닝 과정에서 언급한것처럼, 시간당 25만원이 최소 기준입니다.

단 1일 최소 강의 비용은 80만원까지입니다. (3시간 이상단위만 움직일 예정입니다 , 물론 2시간 하고 80을 주신다면 그건 수락 가능합니다. ) 저도 회사 연차등을 사용해야 하므로 1일 50만원으로는 여러가지 상황을 고려하면, 마이너스 인 상황입니다.

교수가 아니면 이 비용을 줄수 없다고 하시는 회사가 있으시지만, 죄송하지만 불가합니다. 실 세계의 경험의 가장 중요한 소프트웨어 아키텍팅 영역이, 아직도 학벌 타이틀로 강의비가 결정된 상황이 아쉽습니다.

Hillside Group 패턴학회의 정식 위원이고, ISO 29119 WG26의 국내에 몇 안되는 소프트웨어 테스팅 표준화 위원이지만, 그 비용을 못 주시면 다른 교수님에게 부탁드리겠습니다.

이에 반해, 수도권이 아닌 지역 분들이라면, 더 저렴하게 방문을 할 생각입니다. 편하게 연락주시길 바랍니다.

또한 수익 전액에 대해서 취약계층이나 장애인 기부를 하는 공공의 강의라면, 차비와 숙박비만 지원해 주시면, 2,3시간의 특강은 얼마든지 가능합니다.

indigoguru골뱅이gmail.com 으로 편하게 연락주세요.