구글과 네이버의 위기

미국과 한국에서 승승장구만 하고 있는 두 회사에게 언제 위기가 올까??개인적으로 페이스북과 아마존의 주가가 그것을 말해준다고 본다.

사용자가 웹서비스를 사용하는데는 두가지 패턴이 있다고 하자. (이커머스 ?쪽에서 널리 쓰이는 구분 법 임)

  • 목적형 ?- 뚜렷한 목적을 가지고 검색을 하는 상황.
  • 발견형 ?- 뭔가 재미있는 상품이나 기사를 발견하고 싶은 상황.

구글은 목적형에, 페이스 북은 발견형에 최적화 되있다고 했을 때 현재까지는 각자 영역에서 잘 하고 있는 모양새였다.

두 회사에게도 위기가 닥칠 수도 있다고 생각한 건 어느샌가 부터 브라우저를 통해 네이버나 구글에 접속하고 있지 않았다는 걸 느꼈을 떄다.

한국인의 경우 스마트폰을 켜서 뉴스를 볼때 습관적으로 네이버나 다음에 접속해서 뉴스를 본다. 나도 이전에는 주로 다음뉴스나 RSS 리더등을 사용해 뉴스를 소비했었다.

하지만 최근에는 뉴스는 거의 페이스북으로 소비하고 있는 것 ?같다. 언론들 사이트와 오피니언 리더들을 팔로잉 하기 시작하면 서 큐레이션 되는 뉴스가 훨씬 더 익숙해진 것이다.

정확히 필요한 정보는 구글이나 네이버를 통해서 검색하지만 돈이되는 정보는 ?1등 업체에서 하게 된 현실도 그렇다. 쇼핑은 아마존을 사용해 검색하고 , 숙박은 에어비엔비나 부킹닷컴에서 검색하고, 이동할 일이 필요하다면 우버나 테슬라의 무인 운전 기능을 사용해서 이동하면 된다. 구글이 20세기의 전화번호부처럼 바뀔 가능성도 있는 것이다.

예를들어 페이스북이 검색 결과의 수준을 높여서 목적형에 최적화된 정보들을 주는 동시에 메신져 플랫폼까지 장악한다면 구글과 대등해질 수도 있다고 본다. 마찬가지로 목적형 쇼핑에 최적화된 아마존도 다른 다양한 서비스들을 통해 목적 + 발견형 으로 나아가려고 하는 모양새이다.

역시 영원한 1등은 없다. 물론 구글하고 네이버도 이 사실을 잘 알고 있겠지만.

 

 

SRE (Site Reliability Engineering) 를 읽고나서..

http://www.amazon.com/Site-Reliability-Engineering-Production-Systems/dp/149192912X

올해 출판된 책인데, 내용이 괜찮아서 번역되기 전에 원서로 읽고 간단히 정리함.

Preface

  • SE (Software Engineering) 와 아이를 가지는 것의 공통점은 탄생전의 노력도 힘들고 고통스럽지만, 출산 후에 들어가는 노력과 정성이 더 크다는 것이다.
  • 전체 소프트웨어 라이프 사이클의 40%~90% 의 노력이 개발 후에 발생한다.
  • 배포되고 운영되는 소프트웨어를 안정적이라고 간주하는 것은 틀렸다
  • SE는 주로 디자인과 개발에 초점을 두는 경향
  • 개발에서 – 배포 – 운영까지 모든 생명주기를 다루는 규칙이 필요
  • 이런 규칙은 보다 넒은 기술셋을 요구하고 다른 종류의 엔지니어와는 조금 다른 관심사를 가진다 – 이런 discipline 을 SRE라고 부른다.

Introduction

  • 전통적인 SysAdmin 은 개발자에 비해서 Operational 한 기술셋을 요구함
    • SysAdmin 의 장점
      • 구현이 쉬움, 다른 유사산업(건설?)에서 예제들을 가져다 쓸 수 있음
      • 관련 스킬 보유자를 찾기 쉬움
      • 기존 도구 & 서비스 제공업체 들이 이미 존재 해서 새로운 도구 개발 필요없음
    • 단점 (개발과 운영을 분리 했을 시)
      • 직접 비용 발생
        • 서비스가 커지면서 변경이 일어나거나 이벤트 발생시에 수동으로 대처하는 방식으로는 많은 인원을 필요로함 -> 비용증가
      • 간접 비용 발생
        • 두팀의 기술셋과 동기, 백그라운드가 다르다는 사실
        • 각자다른 리스크 인식, 해결방안, reliability 에 대한 개념
    • 개발팀은 빠른 기능추가를 원함 ,운영팀은 문제가 없기를 바람람
    • 두팀의 목표가 상이함함
  • 구글은 이런 문제에 SRE 라는 다른 접근 방식을 취함함
  • 간단하게 설명하면 SRE는 개발자 출신의 운영팀
    • 크게 두가지로 분류됨
      • 60%는 구글 Software Engineering
      • 40%는 개발자 역량으로는 조금 부족하지만 다른 전문성을 가진사람 (주로 유닉스와 네트워킹)
    • 근무 시간의 50%는 운영, 50%는 개발에만 씀
    • 채용이 힘들다
  • SLO (Service Level Objective)
    • 사용자는 100%나 99.99%의 Availability 나 차이를 못 느끼기 때문에 100%를 목표로 잡는 것은 잘못 됨
    • 다른 요인으로 인해 100%가 될수도 없음 (네트워크 유실 등)
    • Target Availability 는 반드시 있어야 함
    • 99.99%의 Availability 를 가진다면 0.01% 의 Error Budget 을 가짐짐
    • 이 Error Budget 을 활용하면 SRE팀과 개발팀의 목푤르 일치 시킬 수 있음음
      • Error Budget 내에서 더 빠른 기능 개발 및 배포
  • 모니터링
    • 전통적인 system Metric 에 의한 alert은 잘못된 것임.
    • 인간이 해석을 하는게 아니라 컴퓨터가 해석을 하고 사람은 행동여부만 결정해야 함
      1. alert
      2. ticket
      3. logging
  • 변경관리
    • Progressive roll out
    • 빠르고 정확하게 문제 찾기
    • 문제 발생시 안전한 롤백
  • 수요조사
    • Organic Growth (서비스 런칭 후 자연스러운 증가)
    • Inorganic Growth (새로운 기능 추가 등으로 인한 증가)
  • 프로비져닝

2. Google Production Environment

  • pass

3. Embracing Risk

  • Extreme reliability comes at cost
    • 사용자경험(UX)이 네트워크나 디바이스 같이 less reliable 한 컴포넌트들에 의해 주도되기 때문
  • reliability 를 늘리는 비용은 not linear 이고.. 100x의 비용이 들어감
    • 유후장비에 대한 Cost (cost of redundant machine)
    • 기회 비용 (opportunity cost)
    • 최대한 reliable 하게 만들돼 필요이상은 아님 (no more reliable than it needs to be)
  • 리스크 측정 (Measuring risks)
    • 대부분의 서비스에서 risk tolerance (받아 들일 수 있는 리스크)는 계획되지 않은 다운타임 (unplanned downtime)의 허용시간과 동일
      • Unplanned downtime 은 99.99 와 같이 뒤에 붙는 9의 숫자로 표현될 수 있다.

        Availability = uptime / (uptime + downtime) e.g) 99.99% Availability 는 년간 52.56 분의 downtime 을 의미함

    • 그러나 Google 과 같이 Globally 서비스 하는 회사는 위 값이 의미가 없다
      • 그래서 request success rate 를 사용

        Availability = successful requests / total requests

    • daily 2.5M 요청을 처리할 경우 99.99%의 가용성은 하루에 250 errors 를 의미한다
  • 서비스의 Risk tolerance 알아내기
    • 다음과 같은 Factor 를 사용
      • 필요로 하는 Availability level . 다음과 같은 기준으로 정한다.
        • 사용자의 기대 Level
        • 매출과 즉결되는가?
        • 유료인가 무료인가
        • 시장에 경쟁서비스가 있는가? 그 경쟁상대의 레벨은?
        • 기업고객 대상인가 일반고객 대상인가
      • 종류가 다른 장애는 서비스에 미치는 영향도 다른가?
        • 이미지가 늦데 로딩되는 것과 개인정보가 유출되는 장애는 수준이 다름

4. Service Level Objective

  • SLI (Service Level Indicator)
    • request Latency
    • error rate
    • system throughput
    • Availability
  • SLO (Service Level Objective)
    • SLI < 목표 & lower bound < upper bound

5. Eliminating Toil

  • 구글에서 SRE는 Operational Work 보다 장기 엔지니어링 프로젝트에 시간을 쏟길 원한다. Operational work 는 종종 오해되서 Toil 로 대체해서 사용한다
  • Toil (잡일) 정의하기
    • Manual
      • 예를들어 어떤 작업을 자동화한 스크립트를 사람이 수동으로 돌리는 것
    • Repetitive
    • Automatable
    • 태스크 종료후에도 똑같은 상태일 경우
    • O(n) 으로 증가할 경우
  • SRE 는 50% 이하의 시간만 Toil (잡일)에 쓰고 나머지 시간은 Toil 을 제거하는 일에 쓴다
    • 이 잡일들을 빨리 제거하지 않으면 곧 일의양이 늘어나고 모든 사람들의 시간을 100% 소비하게 된다
      • SRE 채용시에도 분명히 알려줌. 단순 운영업무가 아니다
    • 잡일은 항상 나쁜가?
    • 규모가 작을때는 그렇지 않을 수도 있다. 그런종류의 일에서 성취감을 느끼고 , 좋아하는 사람들도 있음음.
    • low risk , low stress
    • 양이 많아지면 그사람의 커리어 자체를 위협

6. Monitoring Distributed system

  • 구글에서 사용하는 용어
    • 화이트박스 모니터링
      • JVM 메트릭이나 내부 시스템 정보를 사용한 모니터링
    • 블랙박스 모니터링
      • 외부에서 사용자의 시선으로 모니터링
    • 대시보드
      • 서비스의 핵심 지표를 보여주는 웹 애플리케이션
  • 4가지 중요 지표
    • Latency
      • 성공한 요청과 실패한 요청의 latency 를 섞지 마라라
      • Slow error 는 Fast error 보다 나쁘다
    • Traffic
      • 시스템 별로 조금씩 측정기준이 다를 수 있다
      • 웹서비스의 경우 초당 http request
      • 오디오 스트리밍의 경우 동시 세션수나 네트워크 량
    • errors
      • 요청당 에러 비율
      • 500 or 200 이지만 비정산 응답을 모두 카운팅
    • Saturation
      • 시스템의 포화도

7. Evolution of automation at Google

  • 자동화의 가치
    • 일관성 (Consistency)
    • 확장 가능한 플랫폼으로 커질 수 있다
      • 플랫폼화 되면 버그나 실수들도 쉽게 관리가 되고 동시에 처리 가능능
    • Faster Recovery
    • Faster Action
  • automation
    • 소프트웨어 위에 동작하는 소프트웨어. Meta SW
    • 예제..
      • 사용자 계정 생성
      • 클러스터 구성
      • 소프트웨어설치
      • 서비스 롤아웃
      • 실시간 설정 변경