[월:] 2016년 07월

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는 자바스크립트로

Small meeting /w Bom

by

정해진 시간을 넘겨 3시간이나 Bom 과 미팅을 했는데,

정리 해둘 겸 블로그에 정리 해놓는다.

한국 사회에 파급력 있는 사람이기 때문에 가까이서 대화를 나눴던 사람으로서 기록을 남겨놓는 것이 좋다고 판단한다.

부정적인 뉘앙스가 있을 수도 있지만 굉장히 긍정적인 경험이었다. ( 부정적이었다면 적지도 않음.)

첫인상은 절대 Good listener 는 아니라는 것,? 굉장히 열정적으로 자기 생각을 주입시킨다.

내부에서는 이런 비젼 공유하는 자리를 부흥회라고 한다. 하고싶은 이야기가 머리 밖으로 쏟아지는 것이 보일정도.

예전보다 효과가 조금 떨어지긴 했지만 여전히 CEO가 일반 직원들과 직접 이야기 한다는 것은 굉장히 고무적인 일이 아닐 수 없다.

다만 그 비젼이나 방향성들이 중간 관리자 (다른 조직보다는 확연하게 적지만 그래도 있다) 들이 공유하지 못하고 있다는 느낌.

이건 Bom 과 중간관리자 모두에게 잘못이 있다고 본다.

감히 직원으로서 판단하자면,

비젼 제시와 공유라는 CEO의 가장 중요한 목표에 대해서는 A+ 를 받기 부족함이 없고

소탈하고 친화력이 있어서 대부분의 사람들한테는 호감을 주는 것 같다,

다만 다소 일방적인 면이 있고, 워낙 말을 많이 하다보니 가끔 직원들에게 허언?으로 들리는 말을 가끔 한다는 것 정도가 단점이라고 하겠다.

그렇지만 한국 어디에서도 찾아 볼 수 없는 CEO는 맞다.

  • 특정 비즈니스( local )은 우리가 아니어도 충분히 다른데서 서비스를 받을 수 있다, 품질도 우리가 퀄리티 못함. 그래서 키우지 않음.
  • 개인적으로는 셀러 페이지 만드는 것은 반대, 고객한테 정말 좋은 경험이 될 것 인가?
  • 업무 중에 자기 이름을 대고 추진력을 높이는 사례가 종종 있는데 , 구체적인 사례들 들어달라
    • 누구를 한명 찾아서 Blame 하려는 것은 아니라 프로세를 바꾸고 싶어서 그렇다
    • 회의 중에 Disagree 하고 끝나면 Commit 해야 하는데 안그런 사람이 너무 많다
    • 측근 중에도 회의 끝나고, 따로 이야기 하자고 하는 경우가 몇번 있는데, 확실하게 no라고 이야기하고 회의떄 이야기 하자고 한다.
  • 정말 우리가 없으면 고객들이 슬퍼할 것인가? 갸갸갸 인 서비스는 필요없다. 확실히 누구보다 좋아야 함
  • 복지는 식당의 위생과 같아서 고민없을 특정 수준만 넘어서면 일하면서 얻는 재미가 더 중요하다.
    • 그러나 현재 별로 재미 없어지고 있는데 그 이유는 무엇인가. ?
    • 커뮤니케이션이 적어서 Why 에 대한 이해 없이 일하기 때문에… 그렇다면 PSI 플래닝을 강화
  • 고객에게 노출되는 쪽이라 보이는 장애가 많아서 실제 업무에 집중하기가 힘듬.
    • 개발자를 많이 채용해서 실제 업무비중을 늘릴 수 있도록 하겠다. ( 리크루팅이 문제.)
  • 프라이스 라인.. 별볼일 없는 회사 였는데, 부킹 닷컴 인수 후 50조 가치가 됨
    • 부킹 닷컴은 SPC 중 Conveninece 로는 제일 가는 회사
  • 채용시에 나이 안물어 볼 것. 나이가 뭐가 중요한가? 사람이 너무 없기 때문에 나이 가려가면서 채용할 수 없음
  • One-way door, Two-way door 의사 결정에 있어서 대부분 Two-way? . 잘 안되면 다시 돌아오면 됨.
  • 개발자를 데려 오기 위해 좋은 방법이 있으면 강구해 달라, 일정 시간을 리크루팅에 쏟으면 좋아질까?
    • 개발자가 굉장히 많은 회사지만 외부적으로 공개하는게 적지만 (기술 Blog 나 컨퍼런스 스폰서등)
    • 우리는 확실히 하이테크 컴퍼니이다 (이부분은 동감) 밖에서 보이기에는 쇼핑몰 하나지만 굉장히 많은 것들을 소프트웨어로 처리함.

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