개발

Reactive Functional Programming

by
RxJS merge operator

reactive programming 이 요새 너무 뜨는데, 왜 뜨는걸까 간단히 정리해본다.

  • Functional Programming 의 장점을 취하고 싶다
  • OOP는 왜 안되고 ?Functional Programming을 해야하나
  • OOP는 변화하는 부분을 캡슐화 해서 코드를 이해하기 쉽게 만듬
  • FP는 변화하는 부분 자체를 최소화 해서 코드를 이해하기 쉽게 만듬
  • 암달의 법칙 (Amdahl’s law) – 병렬 프로그램에서 병렬화 , 직렬화 할 수 있는 부분이 있다고 했을 때 그 프로그램의 성능은 병렬화 할 수 있는 코드의 크기로 결정됨
  • 자바스레드와 락을 이용해서 병렬 프로그램? 힘들 것 같다.
  • CPU코어가 빨라지는데는 한계가 있음 병렬화 할 수 있는 프로그램이 대세가 될 것
  • FP를 사용하고 싶지만 사용자 UI를 다루는 부분등에서 부수효과는 (Side-Effect) 생김.
  • FP를 사용하며 ?Side Effect 효과를 낼 수 있는 게 Reactive Programming
  • Reactive Programming 은 데이터의 흐림이 그 핵심이 있음
    • a=10
    • b= a + 1
    • a = 100
    • b?
  • RP에서는 b가 101이 된다. 자바나 C에서 b의 값은 11, 엑셀이 가장 대표적인 RP
  • Funtional Reactive Programming 을 해서 얻어지는 장점은?
  • Reative Manifeto (리액티브 선언)에 그 답이 있음. 리액티브한 프로그램의 정의는 다음과 같음
    • responsive – 실시간으로 사용자와 상호작용하는 앱 , 몇 초의 반응 속도도 만족못함 밀리세컨단위
    • resilient – 오류를 스스로 검출하고 격리시킴, 사용자에겐 validation error, 다른 서비스에겐 application error
    • elastic – 클라우드를 이용한 스케일 아웃 , 경합을 최소화하고 지역 참조성 (Locality of refernce)을 높여야 함함, Share Nothing Design
    • message driven – 서로 강하게 묶여 있지 않음 , SOA, 비동기적으로 통신, 낮은 지연율과 높은 처리율
  • React를 이용한 FRP
  • 비동기 데이터 스트림을 처리할 수 있는 프로그래밍
  • 마우스 스크롤, 이벤트, 변수등 모두 스트림 입력
  • 서버 Node,js 클라이언트 React.js 를 이용해 한벌의 UI 공유
  • UI는 자바스크립트로

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

by

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
    • 예제..
      • 사용자 계정 생성
      • 클러스터 구성
      • 소프트웨어설치
      • 서비스 롤아웃
      • 실시간 설정 변경