[넷플릭스의 클라우드 엔지니어링] 2. 클라우드가 가져온 변화

넷플릭스의 클라우드 엔지니어링 국내도서 저자 : 정윤진 출판 : 예문사 2020.06.10 상세보기

클라우드가 가져온 변화

1. 모바일의 발전이 가져온 효과

• 폭발적으로 증가한 클라이언트 장치, 즉 단말의 종류와 수가 증가하면서 클라우드가 발전함
  • '데이터 폭발'로 설명되는 이현상으로 어린이부터 나이 지긋한 어르신들까지 모두 콘텐츠의 생산, 수정, 공유에 참여할 수 있게 됨
• 클라우드가 기술적으로 홀로 발전한 것이 아님
  • 초기에는 클라우드를 직접 만들어 서비스하려는 움직임에서 이제는 잘 사용하려는 형태로 변화하고 있음
• 클라우드와 함꼐 수면위로 떠오른 수많은 기술을 구현하기 위한 도구들의 등장
  • AWS, GCP, Azure, Sales Force
• 클라우드 기반의 서비스를 잘 하는 회사들은 모두 '어딘가 조금 다른' 조직의 문화나 구성을 포함하고 있음
• 소개된 것들의 적용 부분
  • 점진적으로 효과를 확인하고 피드백을 받으며 변화를 적용하는 방법이 옳은 접근
  • 넷플릭스의 도구가 좋다고 바로 서비스에 적용할 수 있는 게 아님

2. 다양한 기술의 조합

애자일의 개척 회사 중 하나인 피보탈에서는 애자일의 정의를 '굉장한 소프트웨어를 개발하는 방법'으로 정의

애자일 주제 미팅에 대한 공통된 피드백

• 신규 프로젝트에만 사용할 수 있다
• 기존의 대규모 서비스에 적용하는 것은 무리다
• 프로젝트를 처음 시작할 때만 가능하다
• 현재 KPI 산정 방식과 맞지 않는다

어째서 애자일이 중요한가?

뛰어난 투명성

팀 내의 서로 다른 역할을 가진 의사 결정권자들이 '현재' 일하고 있는 내용에 대해 공유하고
무엇이 진행되어야 하는지에 대해 이해하고 있기 때문이다

뛰어난 예측성

연속 배포의 방법과 함께, 사업에서 요청된 기능은 1~2주 내에 반복적으로 개발, 테스트 및 배포가 진행된다
따라서 자주 배포를 수행하기 때문에 서비스의 기능개선이나 배포에 대한 예측이 수월해진다

뛰어난 유연성

기능 개발의 우선순위에 대한 변경이 필요할 때, 즉시 반영할 수 있다

사업적 가치에 집중

개발해야 하는 우선순위에 대해 명확하게 확인할 수 있으므로 사업 의사 결정권자는 서비스에 어떤 기능이 반영될지
그리고 무엇을 먼저 해야 하는지에 대해 집중할 수 있다

사용자에 집중

'사용자 스토리'는 사용자가 개발해야 하는 기능을 어떻게 사용하는지에 대한 이야기를 담고 있다
따라서 디자이너나 개발자가 개발하는 기능이 '사용자 입장'에서 고려되며 사용되지 않는 가치 없는 작업이 될 가능성을 줄인다

품질에 집중

수많은 기능을 '원기옥'처럼 모으고 모아서 한꺼번에 배포하는 것이 아니라 배포 가능한 동작하는 수준으로 잘게 쪼개어 더 자주 배포함으로써
'사용자가 원하는 방향으로' 서비스를 개선하고 더 자주 리뷰를 수행하므로 서비스 품질이 더 자주 개선된다

팀 구성원들의 의지

애자일을 책에서 배우기 쉽지 않은 이유는 이 방법이 구성원 간 매우 활발한 대화와 공유를 통해서 이루어지는 프로세스이기 때문이다
따라서 이 개발 프로세스에 참여할 팀의 구성원들은 새로운 것에 대한 도전과 배움에 대한 열정
그리고 이슈에 대해 팀 내에서 공유할 수 있어야 한다

스스로 진행하려고 하는 경우

만약 애자일 업무 프로세스를 별도의 도움 없이 직접 진행하고자 한다면 지금 그만두는 것이 좋다고 조언한다
애자일 업무 흐름은 단시간 내에 홀로 이루어지는 것이 아니다
경우에 따라서는 실패할 수도 있으며 팀 전체가 일정 수준에 이르기 위해서는
이방법에 대해 신념을 가지고 지원해주는 C레벨 스폰서가 필요할 수도 있다
더군다나 이 애자일 업무 흐름에서는 다양한 도구의 설정과 사용이 필요하기 때문에
가급적이면 피보탈랩과 같은 훌륭한 파트너를 찾는 것이 좋다

새로운 프로세스와 도구를 사용할 준비가 되었는가

현재 사용하고 있는 프로젝트 관리 도구가 애자일을 지원하는가
팀의 구성원들은 테스트 주도 개발 방법, CI/CD 와 같은 방법과 도구를 사용할 준비가 되었는가
그리고 현재 그런 도구가 준비되어 있는가
UX 팀과의 협업은 어떻게 수행할 것인가
조직의 규모가 클수록 이런 변화에 능동적으로 대처하고자 하는 사람들이 더 많이 필요
애자일을 시작하는 것은 지금 당장이라도 가능하지만 '잘' 수행하기까지는 시간이 필요할 것이다

데브옵스의 핵심 부분인 개발팀에 사전 정의된 클라우드 인프라를 사용하는 다양한 도구와 API 제공은 운영팀의 역량에 달려있다
그리고 이 운영팀의 역량이 바로 서비스의 가용성과 안정성 그리고 심지어 개선 속도를 좌우하는 것이다

넷플릭스가 공개하고 있는 모든 도구는 이런 형태다
3~4명의 뛰어난 운영팀이 전체 서비스에 필요한 도구를 만들면 나머지 개발팀들이
이 도구를 원할 때 가져다가 자신의 애플리케이션에 사용한다

수천 대의 데이터 베이스가 수 명의 엔지니어에 의해 관리되는 마법의 실체가 바로 이런 형태의 데브옵스 인 것이다

3. 넷플릭스가 만든 서비스 구조

마이크로 서비스는 다음과 같은 요구를 처리하기 위해 발전된 구조

• Isolation(고립)
• Consistency(일관성)
• Failure Detection(장애 검출)
• Fault Identification(장애 식별)
• Live Upgrade(라이브 업그레이드)
• Stable Storage(안정적인 저장소)

4. 디지털 트랜스 포메이션의 핵심

소프트웨어와 데이터를 다루는 기술을 내재화할 시기가 도래했다

소프트웨어 기술의 내재화가 필요한 궁극적인 이유

• 사업의 핵심 영역에 맞닿는 커스텀 소프트웨어를 만들어야 한다
• 사업의 핵심 영역을 다른 회사에 공개할 수 없다
• SI를 통해 발주해서 만드는 소프트웨어 사이클링이 시장의 변화에 대응할 수 없을 정도로 느리다

5. 넷플릭스가 장애를 취급하는 방법

거대한 자바 기반의 애플리케이션과 거대한 데이터베이스로 구성되어 있던 것을 수많은 작은 서비스들로 분리해 냈다
그리고 사람들은 이런 구조를 마이크로서비스라고 부른다
각 마이크로서비스는 자신이 처리해야 할 역할이 있다

어떤 마이크로서비스를 구성하는 하드웨어 또는 소프트웨어에 문제가 발생해도 장애는 그 지역에 국한된다
서킷 브레이커와 같은 도구를 통해 문제가 발생한 서버로의 연결은 다른 형태로 취급된다
따라서 각각의 서비스는 다른 서비스의 상태와 관계없이 안정적으로 동작한다

넷플릭스 발표 및 공개된 문서에서 공통적으로 언급하는 것이 'Embracing failure' 이다
장애를 이전과는 다르게 취급함으로써 조직 전체가 고가용성을 위해 추구하는 방향이 이전과는 달라진 것이다

6. 모든 것은 고장 날 수 있다

SPOF(Single Point Of Failure)를 제거하는 것 - 단일 장애가 전체 장애로 번질수 있다는 개념
서비스에서 발생한 장애가 전체 장애로 확산하지 낳도록 하기 위해 점진적으로 개선해야 하는 첫 번째 구간의 대상을 이방법을 통해 추출

넷플릭스가 사용하는 방법은 '카오스 엔지니어링'이라고 종종 언급되며 장애를 일부러 유발한다

넷플릭스의 원숭이 군단(Simian Army Projects)

• Chaos Monkey: 넷플릭스를 구성하는 가상 머신중 아무거나 랜덤하게 끈다
• Chaos Gorilla: 넷플릭스 서비스를 위한 하나의 가용존 전체의 서버를 종료시킴
• Chaos Kong: 하나의 리전을 완전히 꺼버린다
  • N+1이라고 불리는 아키텍처 개선을 통해 하나의 리전 전체가 문제가 발생하더라도 다른 리전으로 트래픽을 우회할 수 있도록 구성함
• Janitor Monkey
• Doctor Monkey
• Compliance Monkey
• Latency Monkey
• Security Monkey

넷플릭스는 장애를 일부러 유발함으로써 실제로 발생했을 때의 대응을 매우 빠르게 한다
이 학습의 반복을 통해 모든 구성원은 자신이 담당한 서비스에 대한 이해를 높인다
이는 결과적으로 장애 발생 후 복구시간을 매우 빠르게 만든다

스프링 부트 프로젝트 리더인 필 웹의 말을 인용하자면
'소프트웨어를 현 상태로 유지하는 데 힘을 쏟기보다, 항상 필요한 소프트웨어가 되도록 유지해야 한다'
는 점을 강조하고 싶다

넷플릭스 서비스에서 배워야할 가장 강력한 부분은 바로 변화를 적용하면서도 장애에 대한 대응 능력이 매우 뛰어나다