Offline

Deview 2016, 2일차 참관기

October 26, 2016

Deview 2016, 2일차 참관기

나는 서버를 썰 터이니 너는 개발만 하여라

개발 업무를 전담하기 위해선 ‘인프라’ 혹은 ‘시스템’과 별개로 독리변수와 같이 분리되어야 한다. 개발자가 ‘인프라’나 ‘시스템’과 결합되어 둘 사이에 어떤 관계가 만들어지고 종속변수로 존재하게 되면 생산성의 저하를 막을 방법이 없다. 회사의 서비스 품질을 높이고 싶다면 비지니스 로직, 코드 품질 등을 위해선 개발자의 ‘컨텍스트 스위칭’을 최소화 해야 한다.그러나 국내의 개발 문화에서 인프라와 완벽하게 분리할 방법이 ‘거의’ 없기 때문에 개발자가 불필요하게 소비해야 할 활동은 ‘자동화’를 통해서 개발자의 업무 영역에서 철저히 격리해야 한다.

자동화를 통해서 DevOps를 전체적으로 적용하는 방법도 분명히 필요하지만, 적은 인원으로 서비스를 만들어가는 팀은 시간내서 꼭 들어볼 필요가 있다고 생각한다.

개발자가 개발 업무에만 집중 할 수 있도록 신뢰 할 수 있는 인프라 시스템 구축하기 – p.2

자동화의 필요성

Lean Startup, Agile등과 같은 개발 프로세스를 회사에 정착시키기 위해서는 시스템이 뒷받침 되어야한다. 하위 구조가 상부 구조를 결정한다는 Karl Marx의 주장을 상기 할 필요가 있다.

머리속에 그려놓은 아키텍쳐와 개발 업무 프로세스/정책을 실행하기 위해서는, 중앙 집중 관리되는 자동화 시스템이 필수로 있어야 했다. – p.7

자동화 과정

현재 회사에서 진행하는 과정 중에서 자동화가 가능한 부분을 선정해서 차근 차근 진행해야 한다. 자동화를 목적으로 없던 일을 자동화 하는 것이 아니라, 기존의 업무 중에서 불필요한 부분을 자동화 시키는게 필수적이다.

답을 먼저 보고 풀이를 만들어 나간다. – p.10

자동화의 이점

인프라를 자동화 하는 과정에서 적은 인원으로 대규모의 서비스를 운영 할 수 있다. 구글, 페이스북, 야후와 같이 극단적인 형태의 관리를 진행할 수 있진 않겠지만, 자동화를 진행하게 되면 1명이 관리할 수 있는 인프라의 갯수가 극단적으로 늘어난다.

당연히 해당 서비스가 급격하게 성정하는 과정에서 이러한 이점은 개발팀의 안정성을 담보하기 때문에 서비스 품질을 보장하는데 많은 기여를 할 수 있을 것이다.

Yahoo에서는 Engineer 한명이 80만대를 관리 – p.11

자동화를 선정하기 위한 도구

Ansible, Chef 등과 같은 프로비저닝 도구를 사용함에 있어서 개발팀에서 활용 가능한 도구를 선택하는 것이 좋다. Bash로도 충분히 좋은 서비스를 구현할 수 있다는 점에서 좀 더 다양한 관점에서 고민해 볼 필요가 있다.

어짜피 Linux/UNIX만 관리할 목적이니 공통적으로 버전 문제가 없는 Bash 채택 – p.13

무엇을 자동화해야 하는가?

서비스를 제공하는 과정에서 꼭 필수적인 것들은 자동화 과정을 통해서 해당 업무를 진행 할 수 있어야 한다. 특히 모니터링 및 Log 관련 부분은 자동화를 통해서 개발자가 잔무를 하지 않아도 해당 시스템의 상태를 알 수 있도록 구성되어야 한다.

시스템 운영 자동화, 시스템 이중화(Clustering, HA, BCP) 적용 및 Test 검증, 모니터링 시스템 구축(Nagios, Monit, Vipviewer) 및 모니터링 Agent 제작, Log Collector(Logstash, Flume, Cacti) – p.17

배포의 경우 개발자가 직접 배포 할 수 있는 환경을 만듬과 동시에 QA에서도 스테이징 서버를 만들 수 있도록 지원하면 훨씬 더 수준높은 서비스를 고객에게 제공할 수 있다.

개발자가 직접 배포 할 수 있는 환경 만들기 – p.26

자동화의 원칙은?

특히 자동 배포를 만드는 과정에서 시스템이 중단 되지 않도록 준비하자. 서비스를 사용하는 사용자를 고려해야 하고, 해당 서비스를 사용하는 단 1명의 사용자가 겪게될 불편함에 대한 고민이 필요하다. SW 품질을 높이는 이유가 서비스를 사용하고 있는 고객 때문이라면 현재 서비스를 활용하고 있는 단 1명의 사용자의 중요성을 되새겨 봐야한다.

무중단 배포 시스템 구축하기 – p.29

개발자가 수동으로 인프라 시스템의 구성을 변경하지 못하도록 제한하고, 만약 설정을 변경하거나 확인하는 과정이 필요할 경우 별도로 인프라를 제공해서 개발자가 인프라 구성 요소의 변경에 종속되지 않도록 시스템을 표준화해야 한다.

시스템 표준화 – p.17

네이버 콘텐츠 통계서비스 소개 및 구현 경험 공유

실시간은 이제 필수다.

사용자도 자신이 생산한 콘텐츠에 대한 반응을 실시간으로 확인하길 원한다. 결론적으로 말해서, 어떤 콘텐츠를 제공하는 서비스의 경우 서비스의 결과를 사용자에게 실시간으로 알려주는 것은 이제 필수적으로 만들어야 될 것 같다.

블로그 사용자 설문조사 개선사항 TOP3, 1) 실시간 통계 2) 게시글별 통계 – p.4

“그때는 맞고 지금은 틀리다”

언제나 오래된 레거시 시스템은 항상 발목을 붙자는다. 그때는 옳았던 결정이 지금은 틀렸을 경우도 있고, 그때의 틀렸던 결정이 지금은 말도 안되는 부담감을 주는 경우도 있다. 무엇이 되었든 레거시는 우리에게 ‘애증’으로 다가온다.

그리고 경험의 부제는 레거시 시스템을 더욱더 격려하게 옹호하게 되는 원동력이 되기도 하는 것 같다. 그럼에도 불구하고 단 한발자국도 나가지 못하는 상황에서 레거시는 언제나 짐이다.

경험을 미리 할 수 있는 방법이 없으니, 레거시를 개선하고 계속해서 꾸준히 관리하면서 적절한 리팩토링과 아름다운 설계에 집착해야 하는 이유 중 하나라 할 수 있다.

오래된 레거시 시스템, 안정적인 서비스 운영이 검증된 빅데이타 구현 경험 부제 – p.6

계산 방법

서비스 로직이 명확하다면, 서버 자원을 적절하게 활용 할 수 있는 방법을 최대한 활용하자.

[…] 미리 계산, […] 바로 계산

설계 방법론

적절한 방법을 위해서 설계 방법론에 대해선 아낌없이 투자하자. 이런 투자는 향후 레거시를 레거시답게 만들고, 솔루션을 서비스답게 만들어준다.

http://lambda-architecture.net

M/R v.s SparkSQL

기존의 M/R이 가진 문제점도 있겠지만 SQL로 변환했을 때 가져올 이점이 훨씬 더 커보였다. 기초적이고 기본적인 기술이나 방법에 대해서 한번쯤 관져볼 필요가 있다.

대부분의 M/R code는 SQL로 표현 가능 – p.34

문제 해결을 위한 방법

하나의 솔루션으로 모든 것을 해결할 수 있는 방법은 없다(No Silver Bullet: Essence and Accidents of Software Engineering을 참고 할 것). 여러 가지 방법을 합쳐서 하나의 솔루션으로 만드는 과정은 필수적이다. 그러기 위해서 서비스에 대한 이해를 바탕으로 올바른 설계 방법을 고민하고, 기존 시스템과 연동하는 효율적이고 합리적인 방법등을 팀원과 함께 공유하고 고민해여 한다.

모든 문제를 하나의 솔루션만으로 해결할 수는 없습니다. 그리고 특정 상황에 맞는 유일한 정답은 없습니다. Use-case에 적합한 테스트들을 통해 필요한 사항들을 검증해야 합니다 – p. 61