Outsider's Dev Story

Stay Hungry. Stay Foolish. Don't Be Satisfied.

Puppeteer: Headless Chrome용 Node.js 라이브러리

지난달에 Headless Chrome으로 AWS Lambda에서 웹사이트 스크린샷 찍기에 대해서 글을 올렸는데 이때는 Chrome Launcherchrome-remote-interface를 조합해서 사용했다. 동작 방식을 이해하기는 좋지만 간단한 기능을 위해서 손이 많이 가서 불편하다.

Puppeteer

Puppeteer는 Headless Chrome을 쉽게 사용할 수 있도록 Google Chrome팀에서 공개한 Node.js 라이브러리다. 크롬 팀에서 직접 만들었기 때문에 믿고 쓸 수 있고 사용해본 결과 꽤 잘 만들었다.

앞에서 언급한 Chrome Launcherchrome-remote-interface와는 달리 Puppeteer은 올인원 라이브러리라고 생각하면 된다. 그래서 크롬 버전이나 Chrome Devtools Protocol에 대해 몰라도 그냥 사용할 수 있다. 크롬을 조작하는 API도 잘 구성되어 있다.

설치

npm i puppeteer로 설치해서 사용할 수 있는데 puppeteer은 호환되는 최신 Chromium을 다운받아서 사용한다. 그래서 로컬에 설치된 Chrome 버전과 상관없이 항상 잘 동작할 수 있다. Peppeteer은 Headless Chrome만 사용할 수 있는 것은 아니지만 이 목적으로 만들어졌으므로 기본적으로 Headless Chrome으로 동작한다.

온라인에서 사용해 볼 수 있는 데모 페이지도 제공하므로 여기서 테스트해볼 수 있다.

사용방법

Puppeteer는 문서가 잘 되어 있어서 쉽게 사용방법을 배울 수 있다. 처음 공개될 때는 Node.js 7.6.0 이상만 지원했지만, 지금은 6.4.0도 지원한다. 문서의 예제 코드는 대부분 async/await로 되어 있으므로 여기서는 Promise 기반의 코드로 설명하겠다.(코드는 거의 같다.)

// run.js
const puppeteer = require('puppeteer');

puppeteer.launch()
  .then((browser) => {
    return browser.newPage()
      .then((page) => {
        return page.goto('https://github.com/')
          .then(() => page.screenshot({path: 'github.png'}))
      })
      .then(() => browser.close());
  });

이 코드를 node run.js로 실행하면 https://github.com/ 사이트를 띄워서 스크린샷을 찍고 현 위치에 github.png로 저장한다.(기본 사이즈는 800x600이다.) 깔끔한 async/await를 Promise로 변경해서 좀 보기 안 좋게 되어 있지만 잘 동작한다. 이전 글에서 복잡한 코드로 Headless Chrome을 다루던 것에 비해 내부 동작을 추상화해서 아주 쉽게 사용할 수 있다. 비슷하게 page.pdf() 함수를 사용하면 이미지 대신 PDF로 저장할 수 있다.

// run.js
const puppeteer = require('puppeteer');

puppeteer.launch()
  .then((browser) => {
    return browser.newPage()
      .then((page) => {
        return page.goto('https://google.com/', { waitUnitl: 'networkidel' })
          .then(() => page.$('#lst-ib'))
          .then((search) => search.click())
          .then(() => page.type('puppeteer'))
          .then(() => page.$('input[type="submit"]'))
          .then((submit) => submit.click())
          .then(() => page.waitForNavigation())
          .then(() => page.screenshot({path: 'google.png'}))
      })
      .then(() => browser.close());
  });

이번에는 페이지를 조작하는 예제이다. https://google.com/에 접속해서 검색 칸에 puppeteer를 입력하고 검색하기 버튼을 누른 결과화면을 google.png로 캡쳐한 것이다. 코드를 보면 직관적이라서 Selenium 식의 브라우저를 다루는 코드를 작성해 본 적이 있다면 쉽게 이해할 수 있는 코드이고 상세 메서드와 옵션은 API 문서를 참고하면 된다.

Puppeteer는 기본적으로 Headless 모드로 동작하므로 디버깅이나 확인의 목적으로 실제 브라우저 동작을 보려면 puppeteer.launch({ headless: false })처럼 headless 옵션을 꺼주어야 한다. 이렇게 하면 실제 Chromium이 실행되면서 동작하는 것을 볼 수 있다.(엄청 빠르지만!!)

Puppeteer를 사용해 본 결과 너무 잘 만들어져 있고 편해서 Chrome Launcherchrome-remote-interface를 사용할 이유가 그다지 없어 보였다. 크롬 팀이 직접 만들어서 안정성도 좋아 보인다.

2017/09/27 19:31 2017/09/27 19:31

[Book] 코드로 인프라 관리하기

코드로 인프라 관리하기

코드로 인프라 관리하기 - 6점
키프 모리스 지음
강재준 옮김
한빛미디어


인프라 관련 스터디에서 주제로 선택해서 읽은 책이었다. 작년부터 클라우드 인프라를 만지기 시작하면서 Terraform을 쓰고 있지만 원래 인프라를 쭉 하던 개발자는 아니라서 제대로 공부를 하진 않았기 때문에 책은 나오자마자 샀지만 안 읽고 있다가 이번에 스터디를 계기로 다 읽었다.

서버를 애완동물이 아닌 가축처럼 취급하라.

AWS를 엄청 잘 만지는 건 아니고 인프라를 오래 연구한 것도 아니지만 어느 정도 지식은 가지고 있었다. 팀 내에서 의논해서 인프라를 어떤 방향으로 구축해 갈지를 1년 정도 논의해 오기도 했고 이전과는 다른 개념인 Infrastructure as Code를 적용할 때 현실적인 문제들의 해결이 될 실마리를 이 책이 제공해주길 바랐다. 결과부터 말하면 나로서는 실망이다. 전체를 다 읽고 느낀 점은 책이 너무 추상적이다. 처음부터 너무 쉬운 이론 얘기 들이 나와서 "다음 장 가면 실무 얘기 나오겠지..."하다가 책이 끝났다. 인프라 혹은 Infrastructure as Code에 대한 개념이 전혀 없다면 도움이 될 수도 있겠지만 아무래도 이쪽에 관심 있는 사람들은 사전지식을 꽤 많이 갖고 있지 않나 싶은데 이 책은 너무 이론적이라서 뻔한 말만 하다가 끝난 느낌이다.

이 책이 말하고자 하는 것은 클라우드 시대가 오면서 기존에 진짜 서버를 직접 관리하던 전통방식과는 완전히 달라졌고 여기에 더해 코드로 관리하는 접근이 왜 필요하고 어떻게 해야 하는지를 설명하고 있다. 결론부터 얘기하다 보니 좀 박하게 평했는데 좀 더 자세히 얘기하자면 초기에는 왜 코드로의 접근이 필요하고 어떤 도구들이 있는지 이를 적용하는 과정이나 개념은 어떻게 되는지를 조목조목 설명한다. 결국, 코드로 접근하다 보니 그동안 프로그래밍에서 애자일에서 하던 빠른 실패, 빠른 이터레이션, 완벽한 설계보다는 빠른 변경, 자동화 같은 개념을 그대로 인프라를 대상으로 설명하고 있다. 개발자가 아닌 사람들을 대상으로 설명한다면 (인프라라는 관점에서) 신선한 접근일 수도 있지만, 개발자로서는 굳이 안 해도 되는 설명을 하고 있고 일부 부분에 대해서는 인프라라는 말을 빼면 프로그래밍에 관한 얘기인지 인프라에 관한 얘기인지 모를 정도이다.

1장 문제와 원칙

클라우드 시대의 동적 인프라에서 우리가 겪는 문제, 서버 폭증, 눈송이 서버, 구성 편차, 자동화 공포 등을 설명한다. 이를 해결하기 위해 정의파일을 사용하고 문서화 및 버전 관리를 함으로써 해결하는 접근을 설명한다.

철기 시대와 클라우드 시대의 근본적인 차이는 '매우 신뢰할 수 있는 하드웨어 위에서 동작하던 신뢰할 수 없는 소프트웨어'가 '신뢰할 수 없는 하드웨어 위에서 신뢰성 있게 동작하는 소프트웨어'로 바뀐 것이다.

시스템을 안전하고 빠르게 변경하는 가장 좋은 방법은 구성을 자주 변경해보는 것이다.

2장 동적 인프라 플랫폼

코드로 인프라를 관리하기 위해 플랫폼이 갖추어야 할 특성을 설명하고 있다. 코드로 관리해야 하므로 플랫폼을 프로그래밍으로 다룰 수 있어야 하고 온디맨드여야 한다.

3장 인프라 정의 도구

인프라 정의 도구의 조건으로 스크립트로 사용할 수 있어야 하고 무인 실행이 가능해야 하며 구성이 외부에 노출되어야 한다는 점을 꼽고 이에 해당하는 현대의 도구들을 소개하고 있다.

4장 서버 구성 도구

인프라 정의 도구 외에 서버 구성 도구에 관해서 설명하고 있다. 여기에는 Ansible, Chef, Puppet 등이 포함된다. 모두 자동화를 위한 도구로 현재의 도구들의 특성을 정리해 놓았다.

5장 일반적인 인프라 서비스

인프라 서비스에서 필요한 내용을 정리하고 있다. 인프라에 공통으로 필요한 감시, 경보, 로깅 등의 관점을 설명하고 요즘 가상화된 특징 아래 서비스 탐색과 분산 프로세스 관리에 관해서도 얘기해서 구축해야 할 인프라의 전반적인 이해를 돕고 있다.

6장 서버를 프로비저닝하는 패턴

본격적으로 서버를 프로비저닝하는 여러 접근방법을 소개한다. 실제 도구는 아니고 패턴을 나누어서 서버의 스냅숏으로 서버를 띄운다거나 새 서버를 처음부터 프로비저닝하는 방법을 소개하고 있다.

7장 서버 템플릿을 관리하는 패턴

서버의 템플릿(AWS라면 AMI가 대표적)을 사용하는 다양한 패턴을 소개한다. 여기서는 템플릿으로 서버를 띄울 때 프로비저닝하거나 템플릿 자체를 프로비저닝 된 상태로 만들어두거나 두 가지를 섞어서 하는 접근 방법을 비교하고 이를 업데이트하는 등의 관리에서 발생할 수 있는 이슈도 소개한다.

중요한 모든 것을 템플릿에 프로비저닝한 후, 그 템플릿으로 서버를 생성하고 난 다음에는 런타임 데이터를 제외한 어떠한 변경도 허용하지 않는 것이 불변 서버의 핵심 개념이다.

8장 서버를 업데이트하고 변경하는 패턴

서버를 구축하고 나면 설정을 바꾸거나 새로운 버전을 적용하는 등 계속 업데이트해야 하는데 이 업데이트 일관성 있게 하기 위해 밀어 넣기/끌어오기 방식 혹은 마스터 없는 구성 등의 방법을 비교하고 업데이트할 때 조심해야 하는 부분 등을 설명한다.

9장 인프라를 정의하는 패턴

전체 인프라를 관리하는 방법을 소개하는 장이다. 직접 서버를 만들거나 환경별로 따로 정의해서 사용할 때의 문제점을 지적하고 인프라를 구조화해서 관리하기 쉽게 하려면 어떻게 해야 하는지 설명한다. 여기서는 애플리케이션 코드와 인프라 코드를 함께 관리하고 인프라 설계의 범위를 변경 범위를 기준으로 맞추라고 권장하고 있다.

기존 정적 인프라를 보유한 조직은 결국 정적 인프라의 아키텍처적 패턴과 구현에 익숙해지게 마련이다. 동적 인프라 플랫폼으로 넘어갈 때도 여전히 과거의 패턴과 구현을 유지하는 것이 의미 있고 필요하다고 생각하기 쉽다.

10장 인프라를 위한 소프트웨어 엔지니어링 관례

인프라 코드를 잘 관리하는 얘기인데 코드 얘기랑 같다. 품질 유지에 신경 써야 하고 VCS 사용하고 CI/CD를 적용하라고 하고 있다.

시스템을 코드로서의 인프라로 정의하고 도구를 사용해 구축한다고 해서 품질이 더 좋아지는 것은 아니다. 최악의 경우 상황이 더 복잡해질 수도 있다.

특정 변경이나 릴리스를 상용 환경에 실제로 투입할 시점을 결정하는 일은 여전히 필요하다. 이 결정은 사람이 하지만 실행은 도구가 한다.

11장 인프라 변경 시험하기

인프라를 정의했으면 코드와 마찬가지로 테스트하는 방법이다. 실제 테스트하는 예시나 구체적인 부분보다는 테스트 접근의 이론적인 부분이라 크게 도움 되진 않았다.

12장 인프라의 변경 관리 파이프라인

여기서 파이프라인은 인프라 적용을 자동화해서 코드가 올라가면 적용되는 자동화 흐름을 얘기한다. 이 장에서 한 설명은 나는 좀 과하게 느껴졌는데 파이프라인에는 어떤 단계가 있어 설계할 때의 주의점을 소개하고 실제 파이프라인의 여러 가지 패턴, 많은 팀에서 쓸 수 있는 패턴 등을 소개한다.

13장 인프라팀의 작업 흐름

인프라팀의 일하는 방식을 설명하는 장으로 모든 것을 자동화하고 로컬에서는 Vagrant 등으로 샌드박스 환경을 만들어서 사용하도록 권장하고 있고 이렇게 했을 때 얻는 장점 등을 설한다.

좋은 자동화 작업 흐름의 주요 특성은 속도와 신뢰성이다. 긴급 상황에 충분히 대처할 수 있을 정도로 변경을 빠르게 시스템에 적용할 수 있어야 한다.

코드로 인프라를 관리하는 일은 IT 운영자 대부분의 작업 방식과는 근본적으로 다르다. 가장 큰 변화는 서버와 인프라에서 직접 작업하던 것에서 벗어나 간접적인 방식으로 작업하게 된 것이다. 처음에는 좌절감을 줄 수 있다. 간단한 것을 더 느리고 더 복잡한 방식으로 하는 것처럼 느껴질 수 있기 때문이다.

인프라 코드를 효과적으로 작성하는 사람의 가장 중요한 습관은 가능한 모든 작업을 자동화하는 것이다.

14장 동적 인프라의 지속성

인프라에서 서비스를 중단없이 제공하기 위해 관심을 가지어야 할 지표와 무중단 배포를 하기 위해서 블루/그린 배포, 블루/그린인데 동적 인프라에서 필요할 때만 띄우는 피닉스 배포, 대량의 서버 중 일부에만 먼저 배포하는 카나리아 배포 방법을 소개한다.

사소한 문제와 '알려진 문제'를 감내할 수 있는 '충분히 좋은' 문화가 필요하다.

15장 코드로서의 인프라 준비하기

마지막으로 조직에서 Infrastructure as Code를 하려는 자세로 정리한다. 완벽한 설계가 아니라 계속 변경되는 진화적 아키텍처를 만들어야 하고 효과성을 측정하는 방법 등도 소개한다. 마지막으로 큰 조직에서 권한을 어떻게 나누는 게 좋고 안 좋은 점이 있는지를 설명한다.

2017/09/22 17:50 2017/09/22 17:50