PLAY NODE 2017 방문 후기 입니다.

Typescript, Express, Decorator, Angular

타입스크립트 제가 한번 써봤습니다. (김병진님 Flitto)

• 자바스크립트는 타입이 없어서 타입에러가 많이 발생한다.

• 문제점 : 함수의 인풋과 아웃풋이 어떤 것인지 기존 코드를 보고 유측하기가 어렵다.

  • 해결책 : 타입을 typeof로 체크해주기 시작.. (코드가 더러워지기 시작)

• Front-End

  • Typescript를 도입하기로 결정

    • 타입스크립트는 변수에 타입을 지정해줄 수 있다.

    • 컴파일 과정에서 타입이 다른것은 커파일 에러가 발생한다.

  • 인풋 타입 정리

    • 결합과 상속을 통해서 인풋 타입을 정리하기 시작

      • IDE 딴에서 인풋타입을 체크해주니 타입 에러를 노출 시켜줘서 편리했다.

  • 아웃풋 타입 정리

    • Observable(userInterface)

• Back-End (Node + Express)

  • 타입스크립트로 인풋 아웃풋에 대해서 타입을 정의

• 백엔드와 프론트앤드에 중복되는 타입이 많아짐

  • 백엔드와 프론트앤드에서 공유하는 패키지를 만들어서 해당 패키지에 중복된 타입을 모아 두기 시작

    • 일관된 형태의 데이터로 프론트앤드 백앤드 통신이 가능해짐

• 자바스크립트 @decorator

  • 타입스크립트에서는 @decorator 를 잘 지원해준다.

• TS-EXPRESS-DECORATOR

  • Express 프레임워크에서 타입스크립트의 @decorator 를 사용하기 편하게 Wrapping 한 프레임워크

  • 데코레이터를 사용하면서 관심사의 분리가 가능해짐

  • 의존성 주입이 가능해짐

    • @Service로 지정된 데코레이터를 컨트롤러의 컨스트럭터에서 인젝션을 해줌

  • 데코레이터를 사용하면 스프링 DI 컨테이터처럼 AUTO WIRED 기능을 사용할 수 있다.

    • 데코레이터를 미리 읽어서 데코레이터가 표시된 class들을 빈처럼 만드는게 가능함

      • 이러한 class를 만드는 과정에서 API 문서화 같은 작업도 가능함 (뭔가 module이 있을듯?)

• 왜 타입스크립트?

  • 타입스크립트는 컴파일 언어이기 때문에 컴파일 과정이 추가되어서 사소한 실수를 방지할 수 있다.

  • 타입을 정의할 수 있게되면서 IDE 딴에서 미리 에러를 찾아 낼 수 있어서 개발 생산성이 높아졌다.

• 개인적인 생각

  • 어디선가 타입스크리틑를 사용하면 자바처럼 자바스크립트를 쓸 수 있다는 말을 들었는데 (객체 지향적으로) 그런 부분에서 프론트앤드와 백앤드를 객체지향적으로 사용할 수 있게 되는게 매력적일 것 같다.(원래 내가 모듈화를 좋아함)

  • 그런데 한가지 걱정되는게 타입스크립트가 브라우저 서포트를 어디까지 해줄지가 의문인데 조사해봐야겠다.

  • 타입스크립트도 웹팩 통해서 바벨컴파일(?) 돌리면 ES 하위 버전으로 할 수 있겠지?

Typescript와 Flow

자바스크립트 코드에 정적 타이핑 도입하기 (안희종님 하이퍼커넥트)

• 정적 타입 시스템의 장점

  • 버그에 대한 처리비용이 적은 쪽에서 처리가 가능하다.

  • 자바스크립트에 정적 타입 시스템 도입시 효과에 대한 연구

    • 깃헙에 공개된 이슈중 타입 시스템으로 잡을 수 있었던 버그의 비율은 얼마나 되는지에 대해서 조사

      • 탐지 가능한 버그

        • 타입체커가 버그를 고치는 커밋 직전의 코드베이스를 통과시켜주지 않는다면, 해당 버그는 정적 타입 시스템으로 탐지 및 예방할 수 있었을 것이다.

        • 실험결과 : 저장소에 들어오는 버그중 10% 이상 버그를 줄 일 수 있다.

          • 버그가 안발생하는게 아니고 처리 가능한 시점을 앞단계로 옮겨서 처리 비용을 줄일 수 있다.

    • 코드와 더 밀접히 연결된 문서화가 가능해진다.

    • 리펙토링이 용이해진다.

    • 타입 시스템을 통해서 더 안전하게 더 빠르게 개발이 가능해진다.

• 그럼 어떤걸 선택해서 도입해야해?

  • 크게 두가지 타입스크립트, 플로우 두가지 큰 옵션이 존재한다.

    • 새로운 언어를 만든것이 아니라 기본 자바스크립트 위에 올릴 수 가 있다.

    • 기본적으로 두 시스템이 많이 비슷하다. (문법적으로)

  • 그래서 뭘 써야할까

    • 두개다 괜찮은 시스템이라 생각, 문서를 꼼꼼히 읽어보고 프로젝트의 성격에 맞는걸 잘 골라서… (뻔한 이야기…)

    • 발표자 : 타입스크립트를 쓰세요!

• 왜 타입스크립트를 써야 하나요?

  • 안전함과 편리함 사이 설득력 있는 트레이드 오프

    • 자바스크립트는 기본적으로 느슨한 언어이다 그래서 너무 안전성을 따지는 Flow 같은 경우에는 귀찮은 경우가 많아진다. -> 개발 생산성이 떨어진다.

  • 훌륭한 IDE 서포트

  • 훨씬 거대한 커뮤니티 (개인적으로 가장 중요한 이유)

• 어떻게 도입해야 하나요?

  • Plain JS 사용중인 프로젝트 (나나나)

    • 타입스크립트 설치 및 타입 정의

      • npm install -g typescript

      • 라이브러리 my-cool-lib를 타입 의존성과 함꼐 설치

    • tsconfig.json

    • webpack 과의 통합

      • ts-loader

      • awesome-typescript-loater

    • 점진적 타이핑

      • 파일별 적용

        • JS 에서 TS 임포트

          • 웹팩 통해서 하는거 추천

      • 한 파일 내 부분 적용

        • 타입 추론

        • 타입 강제

  • Flow를 사용중인 프로젝트

• 교훈

  • 생각만큼 어렵지는 않다.

    • 유용한 전략 : 이슈를 해결할 때 마다 관련된 파일을 타입스크립트로 바꾼다.

    • 리팩토링이 너무 쉬워진다

  • babel-loader + ts-loader

    • 폴리필을 쓰면 전역을 오염시켜서 문제가 발생할 소지가 있다. (JS + TS 같이 사용하는 동안에는 주의)

• 개인적인 생각

  • 타입스크립트는 타입스크립트 컴파일러를 거쳐서 자바스크립트로 바뀔텐데 이게 ES6 문법 이상일 것 같다. (우연히 발표자 분을 카페에서 만나서 말씀을 나눴는데 그런 이슈가 있어 하위 브라우저 서포트 이슈가 생길것 같다고 하신다.)

  • 그럼 babel-loader 를 거쳐서 ES5 문법으로 바꿔주면 될텐데 babel-loader가 지원하지 않는 부분이 존재할 것 같다.

  • 이런 부분에 대해서 발표자분과 말씀을 나눴는데, babel-loader가 지원하는 부분이 어디인지 확인이 가능하다 하니 알아봐야겠다.

  • 타입스크립트 꼭 한번 써보고 싶다 프론트앤드를 자바처럼 짤 수 있다면 진짜 진짜 편할거 같다.

Node.js API 서버 성능 개선기

성능 테스트를 위한 준비 / 도구/ 결과 분석 (변정훈님 - 스마트 스터디)

• 인증 API 서버 (회원가입 / 로그인 / 권한부여 / 회원 정보 관리)

  • 왜 성능 테스트를?

    • 서버 하나의 한계 파악

    • 병목구간 확인

    • 코드 개선 후 비교

  • UNIT TEST 에서도 확인 가능하지만 실제 트래픽과 유사한 성능이 궁금

  • 성능 테스트 도구

    • 사용자 시나리오로 작성

    • 대량 트래픽 조절 가능

    • 가능하면 Node.js로 사용

    • Node.js작성된 부하 테스트 도구 : Artillery

      • 기능적으로 필요한 부분이 많이 되어 있다고 생각

        • yml File로 설정과 시나리오를 작성할 수 있다.

          • 어떤 기간동아 얼마 만큼의 액티브 유저가 있는지 설정

          • 회원가입 하고 로그인하고 회원정보 조회한다 등의 시나리오 작성

        • package.json에 아트롤리 테스트 돌릴 수 있도록 scripts 쪽에 작성ㄴ

        • 아트롤리가 리포트 를 만들어 준다.

          • 차트나 데이터 같은 리포트 만들어줌

          • 리포트 json을 떨궈주는데 이걸 보기 좋게 HTML로 만들어 주는 기능도 제공한다.

      • Node.js APM 도구 : New Relic, N

        Solid, Rising Stack

        • 대부분 유료

        • New Relic 사용 -> 고급기능을 제외하고는 무료로 사용 가능 (기본적인 모니터링은 가능)

          • New relic 배포 플래그

          • tip : package.json의 script 에 pre / post 키워드 붙이면 npm run xxx 하면 앞뒤로 해당 스크립트 실행해준다.

      • 테스트 서버 구성

        • AWS 사용

          • Elastic Load Balancer

          • ECS Cluster : docker

          • RDS

          • DNS로 쓰일 Route53 은 성능에 영향이 없을 것이라 테스트 서버에는 구성하지 않음

        • vagrant

          • vagrant 사용하면 AWS에 EC2 인스턴스를 동일한 환경으로 만들 수 있다.

        • ansible (뭔지 모르겠어.. 공부하자..)

      • 튜닝

        • 성능이 생각 이하라 튜닝 작업

          • 클러스터 인스턴스 변경

          • 컨테이너 CPU 메모리 조정

          • DB Pool 사이즈 조정

      • 테스트 결과

        • 한개 시나리오당 20초 정도

          • 다 200대 응답이 오는건 아니다.

    • 굳이 성능 테스트를 하려고 한 이유

      • 개발 하기도 바쁜데 굳이 성능 테스트?

        • Node.js 버전을 8로 올리고 싶어서

          • V8 엔진 업데이트로 성능 향상

          • 도커에 노드 버전만 다르게 해서 완전 동일한 환경에서 성능 테스트 비교

            • 노드8이 훠얼씬 빠르다.

    • Heap dump

      • 메모리 누수 추적이 어렵다.

        • 일주일마다 서버 재시작 (ㅋㅋ)

        • 크롬 개발자도구에서 Take Heap snapshot을 사용하여 할 수 있다.

          • Heapdump

          • shallow size

          • retained size

Node.js로 협력적 멀티태스킹 처리하기

Node.js 멀티태스킹 처리하기 (박일호님 - 카카오)

• 고백

  • 적다고 할 수 없는 숫자의 데이터 마이그레이션 경험담

• 마이그레이션을 하게된 이유

  • 다음 자동차 서비스를 담당하게 됨

    • 역할 1 : 오래된 기사를 마이그레이션 해라

      • 요구사항 분석

        • 구문서 파싱 및 가공

        • 어뷰징 제거

        • 연결된 정보들 처리 (예를들어 댓글)

        • 이 모든것을 안전하게 처리

      • 어떻게

        • DB를 읽고, 쓰고

        • 파일을 읽고, 쓰고

        • API를 호출하고

      • 결론

        • 비동기 요청들을 순차적으로 안전하게 처리해야한다.

    • 왜 노드로 마이그레이션을 ?

      • 노드를 좋아해서

        • 익숙하고, 충분히 마이그레이션 용도로 사용이 가능할 것 같아서

    • 시뮬레이션

      • 한개의 아티클르 처리하기 위해 필요한 비동기 요청 수는

        • 최소 8개 + 댓글 수 * 2 개의 리퀘스트가 필요

    • 그러나 실제 효율은 절반 이하

      • 댓글이 많은 기사에서는 효율이 많이 떨어진다.

    • 해결책

      • 병렬처리로 속도를 높이거나

      • 프로세스의 효율을 높이거나

    • 결국 동시성 문제를 해결해야 하는상황

      • 메시지 큐를 사용해 스케쥴링하고 병렬처리 하기로 결정!

    • 구현을 하면서

      • 비동기를 처리하는 대표적인 방법

        • CallBack

          • Callback Hell…

      • Promise

        • 가독성 좋아지고 예외처리 가능해진다.

        • promise.all 를 사용해서 순서를 보장

        • promise 를 써도 괜찮긴 하지만 …

          • 프로미스 객체가 메모리에 남아서 문제가 생긴다.

    • 메모리 이슈를 어떻게 풀까

      • 협력적 멀티 태스킹

        • 일종의 시분할 방식

        • 운영체제의 개입없이 task 가 독립적으로 CPU 사용

        • 미사용시 자발적 CPU 반환

        • 크리티카 섹션을 보호하기 위한 락이나 세마포 불필요

      • 구현방법의 선택

        • Coroutine

          • ES7 : async, await

          • Node.js 7.6 부터 공식적으로 지원

          • promise를 Wrapping한 것이라 promise 보다 느리다.

            • 그러나 여러개를 처리하는 쪽에서는 효율이 나쁘지 않다.

            • 병렬로 처리하기 때문에 처리하는 갯수가 많아질 수록 효율이 높아진다.

          • 장점

            • 코드 가독성이 좋아짐

            • 대규모 처리시 안전함