[1]이 글에서는 Uber와 같은 택시 애플리케이션 서비스의 아키텍처 및 시스템 설계에 대해 배워보고자 합니다. Uber 애플리케이션에서 탑승자(CAB를 원하는 사람)가 앱에서 드라이버를 요청하면 해당 사용자를 선택하기 위해 드라이버가 이동합니다. 이면에는 여행을 지원하는 1,000대의 서버가 있으며 여행에 테라바이트의 데이터가 사용되었습니다. Uber 회사가 시작되었을 때 그들은 단순한 모놀리식(monolithic) 아키텍처를 가졌습니다. 백엔드 서비스, 프런트 엔드 서비스 및 데이터베이스가 있었습니다. […]

저자 : Robert Armstrong / Netflix 파트너 엔지니어 Netflix는 수백만 개의 셋톱 박스, 스마트 TV, 스트리밍 스틱 및 기타 가전 기기에서 사용 중입니다. Netflix의 DRE(Device Reliability Engineering/디바이스 신뢰성 엔지니어링) 팀은 엄격한 초기 인증 과정을 거쳐 (위에서 언급한) 디바이스들이 수없이 많은 업데이트와 서비스 개선을 통해 고품질의 경험을 지속적으로 제공하도록 보장할 책임이 있습니다. 현재까지 전 세계에는 1,600개가 […]

AI 안면인식 / 이상행동 인식 실증 사업 정보 공유 AI 안면인식 테스트 1 – 해외 동향 편에 이어 지난 2년 동안 과기부 / 법무부 범부처 협력 사업인 AI 안면인식 과제 사업의 실증 사례를 공유해 드리고자 합니다. 실제 어니컴/STA가 진행한 사업으로, 국내 공항에서 요구되는 안면인식/ 이상행동 테스팅에 대한 좋은 노하우 그리고 테스팅 및 학습 제반 환경 […]

AI 테스팅, 안면인식, 과기부, 법무부, 어니컴, NIPA

맥을 쓰다보면 Parallel Desktop , Clean My Mac 같은 솔루션들이 끊임없이 매출을 창출하기 위해 버전을 관리하는 방법들을 내놓고 있다. 물론 새버전이 나올때마다 새롭게 사게해서, 짜증이긴 하지만.. 그 들도 먹고 살아야 하니 어쩔수없다. 그 만큼 가치가 있다면 계속 돈주고 사야지. 그럼 솔루션 업체 입장에서는 어떻게 해야 저항없이 고객들이 새 버전으로 솔루션을 업그레이드 할수있게 만들 수 있을가? […]

무려 3년이 다 되어가지만,  일전에  SaaSTR이라는  컨퍼런스에 다녀왔다.  (좋은 행사에 보내주신, WhaTap 에 이동인 대표님에게 감사를 드린다) AppDynamics가 Cisco에 4조에 인수된 사건과 발생하였고,  SaaS에서 내놓으라는 회사에서 자신의 노하우와 여러 기반 기술을 공유한 행사였다.   여기서  크게 관심을 가진 세션이 있었는데 CPO가 무엇을해야 되는지에 대한 세션이었다.

CPO(최고 제품 개발자) 또는 VPP (VP of Product)가  해야 되는 일

  • 물건을 잘 파는 거, 향후 전략, 마켓팅과 연합.
  • 일반 고객 / 중요 고객 / 엔지니어 팀과 이야기 하면서 방향을 잡아가는 것.
  • 지휘자 / 커뮤니케이터 / 오케스트레이션, 오가나이제이션
  • 팀간에 ceo가 vision을 실행한다면 그걸 하게 만들어야 되는 역할.

CPO(VPP)와 프로덕트 관리자와 다른 것은 무엇인가요?

  • 접점이 달라진다. 팀원을 이끄는게 아니라, 고객과 이야기 하고 고객이 원하는 product으로 갈수 있게 이끌어야 한다.
    leadership이 달라진다. pm은 엔지니터링 팀을 이끌고 잘 돌아가는게 하는게 목적.
  • CPO(VPP)는 정말 다양한 백그라운드를 가지고 있다.
    – 디자이너 출신: 고객의 경험을 중심. 어떠한 성격을 가지는지. 어떻게 고객과 점접을 가지고 이야기 하는지.
    – 엔지니어 출신: 실현 가능한지, Scope은 얼마인지에 집중이 필요하다.

Cx 레벨간의 차이는 무엇인가요?

  • CEO는 비전을 제시한다
  • CPO는 사용자가 어떠한 느낌을 가질지, 어떠한 기능을 제공할지 고민을 해야 한다.
  • CTO는 자동차의 엔진을 잘 만들어야 한다.

CPO가 해야 할일을 구체적으로 알려주세요.

  • 고객과의 접점을 늘리고, 어떠한 제품과 기능을 제공해야 하는지, 많은 이야기를 해야 한다.
  • 유저 스토리를 만들고 왜 사용하고, 어떻게 진행하고 등에 대해서 끊임없이 이끌어야 한다.
  • engineer , marketer, customer 간에 조율하고 이끌어야 한다.
  • context switching 을 잘해야 한다. 7일에 7개의 언어를 배우듯이 여기 저기 왔다 갔다 잘해야 한다. 상황에 맞게 변신하는게 매우 중요하다.

계속 읽기

싸움은 가능한 피해야 하나, 결국 제한된 자원에서 소수의 승자만 존재한다면, 어쩔수 없이 싸움(경쟁)을 해야 한다.

싸우지 않고 이기는 것이 가장 최상이다. 라는 말은 있으나 실제 어떻게 하면 구체적으로 이걸 하는지 실행 방법에 대해서 구체적으로 나온 글등은 찾기 어려웠다.  요즘 당하고 있는데.  역시 고수는 다르다는 것을 깨닫고 있다.

보통 고수들의 전략을 보면 다음과 같다.

  1. 절대 자신이 직접 싸우지 않는다.
  2. 자신의 의견을 대신해서 잘 내세울 여러 대리자들을 만든다.
  3. 대리자들을 만들기 위해서는 당연히 보상이 필요하다. (이익을 확실히 보장하거나, 한 자리를 주겠다거나, 넌 정의를 지키는 사도야  그러니 꼭 니가 나서야해!  그럴 힘은 너만 있어.. 등.. )
  4. 그리고 싸우고자 하는 상대의 부정적인 정보를 계속 전달한다.
  5. 이 대리자들은 부정적인 시각으로 벌써 상대방을 바라보기 때문에,  직접 만나도 의심의 눈초리로 바라본다.  대부분 설득이 되지 않는다.
  6. 결국 대리자와 당사자는 피터지게 싸운다.
  7. 대리자가 이기면, 자신의 영향력을 발휘해 계속 잘 관리하면서 같이 이익을 공유한다.
  8. 대리자가 진다면,  결국 자기는 크게 상처를 입지 않고,  결국 싸움판이 벌어졌기 때문에 싸운 당사자들만 피를 보며 평판이 나빠진다.

그럼 여기서 만약 내가 당하는 피해자라면 해야 될 방어 전략은 무엇이 있을까?

계속 읽기

CPO는 제품의 향후 마일스톤을 결정하고, 어떠한 가치및 기능들을 전달할지 결정하는  역할이다.  개발자에게는 제품/상품이라는 개념이 다소 생소할수 있겠지만, 결국 우리가 만드는 SW들은 고객들에게 하나의 상품이다.  고객의 입장에서 매력적인 / 또 실제 팔릴수 있는 상품을 만들수 있게 제품 전반에 지휘권을 가지고 있는 자다.    

클라우드 꼭 해야 하나?

클라우드 바람이 불고 있다.  개발자나 DBA 입장에서는 서버를 빌려쓰는 것으로 이해할 수 있지만, 전통적인 시스템 운영자에게는 그 이상이다.    클라우드를  도입시 고려해야 되는 상황과 시장 에 대해서 설명하고자 한다.

미국은 클라우드 전환 율이 5:5 이지만 한국은 이제 8:2 -> 7:3으로 넘어가고 있는 상황이다. 혹자는 낮은 클라우드 전환 율이 해외에 비해 경쟁력이 없다, 뒤쳐지고 있다 라는 이야기를 하고 있다.

엄격하게 말하면, 이러한 상황은  한국 시장의 특성때문에 그렇다. 미국,중국은 내국 서비스라고 해도 미국 전역에 서비스를 배포해야 한다.   개별 IDC 업체들을 돌아가며 IDC 특성에 맞추어가며 배포하는 것보다, AWS, Azure, GCE와 같은 글로벌 밴더사의 클라우드 플랫폼에서 운영 배포하는 것이 유지보수가 훨씬 쉽기 때문에,  미국, 중국 전역 또는 글로벌한 서비스들은  클라우드로  빠르게 전환되고 있는 추세다.

현재 한국은 중견 기업 이상급들이 비용 절감을 위해 오픈 스택, Private Cloud 도입을 하고 있는 추세이다.   하지만 글로벌에 나갈때는  멀티 리전, 멀티 존에 대한 운영이나 경험들에 대해 부족해 어려움을 겪고 있는 현실이며, 이러한 경험을 가진 인력을 구하기는 쉽지 않다.

클라우드는 공유 제한

cloud instance

그림 1. 클라우드는 공유자원

개발자, 운영자 DBA가 클라우드가 가져오는 가장 큰 제약은 클라우드는 공유자원이라는 것이다. 하나의 머신에, 가상화된 여러개의 인스턴스를 올려 놓은 것이다.   즉 다시 말하자면, 우리는 공유자원을 빌려 쓰는 것이므로 오늘 잘 동작한다고 해서 내일 잘 동작한다는 것을 보장할수 없다.

iops queue length.png

그림 2. 클라우드 장애의 단골 손님 –  IOPS 부족 문제

국내 서비스중인  안정적인 게임이 중국에 클라우드에서 배포되고 나서 발생한 장애사례이다. 한국에서는 실제 물리서버에서 배포를 했었는데, 중국 진출 후 클라우드를 처음 도입하였다.   그런데 두개의 리전에 로그인 서비스를 배포 했는데, 특정 시간대에 한쪽 리전에서만 계속 로그인이 제대로 되지 않아 튕기는 문제가 발생했다.

장애시 개발팀은 이미 몇 년동안 검증된 로직인데, 원인을 찾기 힘들어 했었고, 문의가 들어와 확인을 해보니 클라우드 인프라의 문제였다.  바로 클라우드에 가장 장애로 많이 이어지는 IOPS (초당 발생하는 IO) 가 대표적인 예이다.  위 그림을 보면 IOPS가 초당 250으로 제한이 되어있는 것처럼 볼수 있으며, 실제 IOPS 요청에 비해 부하가 반영이 되지 않아 Write Queue에 요청이 쌓여 있는 것을 볼수 있다.

왜 이러한 현상이 발생했을까? 앞서 언급한 것 처럼 클라우드는 공유자원이다.   즉 하나의 Host 머신에서 우리 서비스 이외에 다른 서비스들도 입점 할수  있으며,이 서비스가 특정 시간마다 과도한 자원을 사용한다면 (IO가 많이 필요한 배치 작업을 돌린다면), 우리 서비스에 영향을 줄수 있다는 것이다.  그래서 기존 서비스를 쾌적한 다른 존으로 배치하고 나서 장애는 해결되었다.

계속 읽기

트위터는 왜 두번이나 모니터링 시스템을 직접 개발 하였을까요?   Monitorama 에서 발표한 Building Twitter Next-Gen Alerting System과  여러 컨퍼러스에서 발표한 내용을 정리해서 공유해 드리고자 합니다.

Twitter 모니터링 초창기 시스템 아키텍처

observability2

첫 모니터링 솔루션은 위와 같이 아키텍처를 수립하였습니다. (현재 오픈소스 솔루션과 유사하죠)     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만개로 증가.

계속 읽기