패턴 I 회에서는 아키텍처 시각화 패턴의 전체적인 구조와 구성되는 패턴들의 종류들을 간단히 소개하고, 아키텍처 시각화를 하기 전에 소프트웨어 시스템을 분석하기 위한 기본 요소들인 Domain Level Classifier Pattern과 Class Dependency Classifier Pattern에 대해서 살펴보았다.
2회에서는 시간에는 소프트웨어 시스템의 아키텍처 분석에 기본이 되는 다양한 Metric에 대한 설명을 올렸다.
이번 3회에서는 의존성을 관리하는 시각화 지표를 설명한다.
이 글은 Kousik Nath의 System Design: Design a Geo-Spatial index for real-time location search을 번역한 글로, 모든 저작권은 원저작자에 있습니다. 최대한 원문을 살리려 했으나, 이해를 돕기 위해 의역과 역주를 사용한 곳도 있습니다.
수정할 부분이 있다면 indigogurur골뱅이gmail.com으로 남겨주시길 바랍니다.
2부는 아키텍처 전략: 실시간 위치 검색을 위한 지리 공간 인덱스 설계 시리즈 두 번째 시간으로 샤딩으로 아키텍처 개선하기에 대해 다루었습니다.
- 개요 및 아키텍처
- 샤딩으로 아키텍처 개선하기
- Geo Hash를 이용하여 아키텍처 개선하기
소개
우리는 실생활에서 항상 실시간 위치 검색 서비스를 사용합니다. 음식 주문 앱이나 주문형 택시 예약 서비스는 요즘 어디서나 볼 수 있죠. 이 글의 목적은 실생활에서 지리 공간 인덱스(Geo-spatial Index)에 대한 백엔드 인프라를 설계하는 방법을 살펴보는 것입니다.
지난 1편에서는 로드밸런서와 캐시를 이용하여 부하를 배분 및 감소하는 전통적인 아키텍처를 설명했습니다. 
이번 시간에는 위 그림에서 더 개선된 아키텍처 접근법을 공유합니다. 더 나은 방법으로 캐시를 분할하는 방법을 알아보도록 하겠습니다.
계속 읽기
이 글은 Kousik Nath의 System Design: Design a Geo-Spatial index for real-time location search을 번역한 글로, 모든 저작권은 원저작자에 있습니다. 최대한 원문을 살리려 했으나, 이해를 돕기 위해 의역과 역주를 사용한 곳도 있습니다. 수정할 부분이 있다면 indigoguru@gmail.com으로 남겨주시길 바랍니다. 이번 시간은 아키텍처 전략: 실시간 위치 검색을 위한 지리 공간 인덱스 설계 시리즈 첫 번째 시간으로 개요 […]
[1]이 글에서는 Uber와 같은 택시 애플리케이션 서비스의 아키텍처 및 시스템 설계에 대해 배워보고자 합니다. Uber 애플리케이션에서 탑승자(CAB를 원하는 사람)가 앱에서 드라이버를 요청하면 해당 사용자를 선택하기 위해 드라이버가 이동합니다. 이면에는 여행을 지원하는 1,000대의 서버가 있으며 여행에 테라바이트의 데이터가 사용되었습니다. Uber 회사가 시작되었을 때 그들은 단순한 모놀리식(monolithic) 아키텍처를 가졌습니다. 백엔드 서비스, 프런트 엔드 서비스 및 데이터베이스가 있었습니다. […]
트위터는 왜 두번이나 모니터링 시스템을 직접 개발 하였을까요? Monitorama 에서 발표한 Building Twitter Next-Gen Alerting System과 여러 컨퍼러스에서 발표한 내용을 정리해서 공유해 드리고자 합니다.
Twitter 모니터링 초창기 시스템 아키텍처
첫 모니터링 솔루션은 위와 같이 아키텍처를 수립하였습니다. (현재 오픈소스 솔루션과 유사하죠) 1.0 시스템은 다음과 같은 컴포넌트로 구성되어 있습니다. (트위터의 모니터링 시스템이 오픈소스로 공개되지 않아서, 전적으로 발표자료에 의존해 설명이 구체적이지 않습니다. )
- Agent – 데이터를 수집하는 Agent로 시스템 성능에 필요한 여러 지표를 수집.
- Collector & Storage API – 수집부에서 데이터를 모아 Storage API 를 통해 Time Series Database( Manhattan으로 추정)에 저장하고, 그정보를 Cassandra에 저장.
- Monitoring – Query 엔진으로 데이터를 긁어와 여러 지표를 모니터링.
- Dashboard – Alert 과 Dashboard 를 쉽게 구성할수 있는 Config, DSL을 제공.
- Ad Hoc Queries – 상황에 따라 적합한 쿼리를 던질수 있음.
트위터는 왜 모니터링 2.0 시스템을 만들어야 했나?
하지만 트위터의 급격한 성장으로 인해, 위 아키텍처로는 더 이상 모니터링을 할수 없는 상황이 되었습니다.
- 1분당 수집되는 메트릭이 3년 만에 3억개(300M)-> 14배로 43억개(4.3B)으로 증가.
- 발생하는 알럿의 증가 – 1분당 2500개 -> 1분당 3만개로 증가.
아키텍트가 알아야할 12가지의 Presentation을 공개합니다. 아키텍트가 알아야할 97가지중 제가 선별한 12가지의 내용이 들어가 있으며, 앞으로 +1 씩 더해가면서 점차 내용을 확대하고 다듬을 생각입니다. 많은 분에게 도움이 되셨으면 합니다. 상업적 자료 사용은 금지이며, 저작자의 이름을 공개한 상황에서 사용하는 것은 허락합니다.
“아키텍트가 알아야 할 97가지 것들” 에서 저에게 가장 와 닿는 에피소드입니다. 기술도 중요하지만, 더 중요한 것은 기회를 잡을 수 있냐다 라는 말이 너무나 가슴깊이 와 닿았습니다. 결국 사람들과 어떠한 관계를 가지느냐에 따라, 그 모듈의 관계 역시 정해 지는 거죠. 기술 매우 중요하지만, 그것 보다는 어떻게 팀원들과 하나되어 서로의 단점을 상쇄시키고, 장점을 강화 시킬수 있을까요? 이게 요즘 저의 가장 큰 숙제인거 같습니다.
지금 이순간에도 실패한 급여 시스템 프로젝트를 진행하고 있는 사람이 아마 한 명 이상 있을 것입니다.
왜 그런걸까요? 자바 대신 루비를 선택하거나, Smalltalk 대신 파이썬을 선택했기 때문일까요? 혹은 오라클 대신에 포스트그레스를 사용하기로 결정했기 때문일까요? 혹은 리눅스를 선택했어야 했는데 윈도우를 선택했기 때문일까요?
실패한 프로젝트에서 사용한 기술이 전락하는 것을 우리 모두는 보아왔습니다. 하지만 문제가 정말 해결하기 너무 어려워서 자바가 해당 업무에 적합하지 않았다라는 것은 무엇을 의미하는 것일까요?
대부분의 프로젝트들은 사람에 의해 만들어지며, 사람들은 성공과 실패에 대한 기반이 됩니다. 따라서, 사람들을 성공할 수 있게 만드는데 도움이 되는 것에 대해 생각해 볼 필요가 있습니다.
한편으로는, “단지 일을 올바로 하지 않고” 프로젝트를 어렵게 하는 누군가가 있다는 가망성에 대해 충분히 생각해 볼 수 있습니다.
오늘날의 시스템은 분산되어 있고, 느슨하게 결합되어 있습니다. 느슨하게 결합된 시스템을 구축하는 것은 조금 귀찮은 작업입니다., 우리는 왜 이런 귀찮은 작업을 해야 될까요? 우리는 조그만 변화로 시스템들이 산산이 부서지는 것을 원하지 않기 때문에, 우리의 시스템들이 (변화에) 유연하길 원합니다.
오늘날의 환경에서 유연함은 매우 중요한 자산입니다. 여기서 우리는 어플리케이션의 작은 부분만을 제어할 수 있습니다. 분산 서비스나 써드-파티 패키지들에서 작동하는 나머지 부분들은 다른 부분이나 외부 밴더 들에 의해 제어됩니다.
그래서, 변화에 유연하고 시간이 흐름에 따라 진화할 수 있게 시스템을 구축하는 것은 좋은 노력처럼 보입니다. 하지만, 이것은 우리의 시스템이 시간이 흘러감에 따라 변할 수 있음을 의미합니다. “오늘날의 시스템은 더 이상 어제의 시스템이 아니다.” 라는 것처럼..
불행하게도, 변화는 문서화하는 것도 어렵게 만듭니다. 항상 변경되는 시스템에서는, 문서가 프린터 되는 순간 그 문서는 구식으로 되어 버리고, 이러한 상황들이 심해질 수 있습니다. 게다가, 일반적으로 유연하게 시스템을 구축 하는 것은 아키텍쳐가 좀더 복잡해 지는 것을 의미하며, 잘 알려진 “Big Picture (큰 그림)”[1]을 얻기 어렵습니다.
예를 들어 만약 모든 시스템의 컴포넌트들이 꼭 설정 가능한 채널을 통해 다른 구성요소들과 통신을 한다면, 컴포넌트들은 어떤 행위를 (무엇을 해야) 할지에 대한 정보를 얻기 위하여 채널 설정부만 바라보면 됩니다.
제 2회 아키텍트 Summit에 발표 자료입니다. 아키텍트에 ‘아’짜도 따라가지 못하는 저가, 우여 곡절 속에 수많은 쟁쟁한 분과 함게 발표를 맡게 되었습니다.
다른 쟁쟁한 아키텍트 분들에게 누가 되지 않았길 바라며, 발표를 준비했습니다. 주제는 패턴과 EA의 활용에 대해서 간략히 언급해 드렸습니다.
로마인의 세계에서, 야누스는 시작과 끝, 문과 통로의 신입니다. 야누스는 다른 방향의 바라보는 두 개의 머리로 보통 묘사되며, 영화나 동전에서 볼 수 있는 상징입니다. 야누스는 전환과 변화를 나타냅니다. 우리의 삶에서 예를 든다면 과거에서 미래로, 젊음에서 늙음, 결혼, 탄생, 시대의 도래와 같은 것이 있습니다.
소프트웨어 또는 건축물이든 어떤 아키텍트도, 앞과 뒤로, 과거에서 미래로 볼 수 있는 야누스의 능력은 꼭 필요한 능력입니다. 아키텍트는 비전과 현실, 향후 방향과 과거의 성공, 개발 제약과 사업/관리 기대치를 융합하기 위해 노력합니다.
이러한 (간극을 메우는) 다리를 만드는 것은 아키텍트의 중요한 역할입니다. 종종 아키텍트는 프로젝트를 완성하기 까지, 프로젝트에 영향을 미치는 다른 영향력들(예를 들어 접근 용이성 vs 보안, 경영의 미래 비전을 설계하면서 현재 비지니스 프로세스를 만족시키는 것)이 발생시키는 간극을 극복하기 위해 노력할 때, 희로애락을 느끼기도 합니다.
다양한 프로젝트의 이해당사자를 만족시킬 수 있는 소프트웨어(product)를 만들기 위하여, 좋은 아키텍트는 두 가지의 다른 아이디어나 생각, 다른 목표와 비전을 처리할 수 잇는 두 개의 머리를 가져야만 합니다. 아키텍트인 당신은 단순히 두 개의 얼굴이 아닌, 야누스가 가진 두 개의 머리를 주의 깊게 보아야 합니다. 훌륭한 IT 아키텍트는 뛰어난 경청 자[1] 이자 평가자 이어야 합니다.
Architecture 101 