빙글 테크톡 첫번째


Techtalk at Vingle 1

CI / CD, Microservice As A Tool

  • CI / CD , 마이크로서비스아키텍쳐 모두 도구일뿐 목적이 되면 안된다.
  1. 문제점
  • 배포

    • 이전까진 모놀리틱 앱 - 모든 코드가 레일즈 프로젝트 하나에 들어있었다.

    • 때문에 배포도 전체 코드 - 프로젝트가 커지면서 시간등이 많이 걸림.

    • 테스트를 통과한 master도 production에 올려도 문제가 없는지 아무도 모른다.

    • 배포단위가 커지다 보니 QA시간도 오래걸리고 이전 QA가 끝나지 않아서 배포할 수 없는 경우도 생긴다.

      코드는 사용자에게 배포되기 전까진 아직 아무런가치도 만들어 내지 않은 것 이다. -Vingle

  • 혁신

    • 레일즈 기반의 모놀리틱 앱이기 때문에 새로운 기술 도입에 제약이 많다.

    • 같은 이유로 기술 도입을위한 프론트엔드 라이브러리 추가시 서버까지 죽는 등의 리스크가 너무 크다.

    • 각자의 핵심 역량과 상관 없는 것들을 알아야한다. - 프론트엔드 개발자도 루비를 할 줄 알아야 함.

    • 결국 생산성이 떨어짐.

      기술 혁신이 없으면 그게 왜 IT 회사냐 - Vingle

  1. 목표

    1. 멋있지만 추상적인

      • 빠른 배포

        • 안전하고
        • 빠르고
        • 코드 퀄리티 있고
        • 작게
      • 빠른 혁신

        • 새로운 기술에 높은 접근성
        • 최소의 리스크
    2. 길지만 구체적인

      • 혁신

        • 러닝커브를 낮추자.
        • 기술 도입에 대한 유연성을 높이자 - 리스크를 낮추고 다른 서비스에 영향을 끼치지 않도록.
        • 프로젝트를 쪼개자 - 종속성, 배포, 스케일링, 모니터링, 기술 스택, 코드 베이스

      배포는 CI / CD로 혁신은 Microservice로

CI / CD

  1. 진행하는 모든 프로젝트들에 CI / CD Pipeline 정의

    • Checkout - git checkout ${branch}
    • Dependecy - npm install
    • Test - npm run test
    • Lint - npm run lint
    • Build - npm run build
    • Deploy:staging - npm run deploy:stage
    • Deploy:production - npm run deploy:prod

    젠킨스를 사용해 CI를 한다.

Microservice Architecture

  • 레일즈에 API 로직만 남기고 모든 피쳐 분리.

  • 마이크로서비스의 조건 - 자생, 협업 가능, 비즈니스 도메인을 기반한 모델

  • 다음의 조건을 만족하는 템필릿이 필요

    • 쉬운 확장
    • 배포
    • 모니터링
    • 적당한 사이즈로 쪼개진 서비스
    • 쉬운 서비스간 통신

결국 AWS Lambda + APIGateway를 ServerLess 프레임워크로 묶어서 관리. 타입 스크립트도 사용하자.

  • 직면하게 된 문제들은 젠킨스를 이용해 해결했다.

팀의 수준에 맞는 결과가 나온다.

  • 필요없다면 굳이 쓸 필요가 없다.

    • B2B 서비스라 자주 배포할 필요가 없다면?
    • 안전하게 배포할 수 있는 시간이 정해져 있다면?
    • 팀원들이 모두 전문분야가 비슷하다면?
    • 팀원들이 코드리뷰하는걸 부담스러워 한다면?
    • 모든 QA가 개발 환경에서 가능하다면?





© 2017. by isme2n

Powered by aiden