도커와 마이크로 서비스 그리고 DevOps

25gStroy·2022년 2월 13일
0

Docker

목록 보기
5/20

도커 탄생배경

서버를 이전할때 작은 설정하나만 실수하더라도 프로그램이 배포가 안되는 경우가 생길 수 있다. 그렇다면 그 서버를 수십개를 이전한다면? 엄청나게 잔인하고 고통스러운 작업이 아닐수가 없게된다.
하지만 도커가 탄생하면서 위와같은 복잡한 배포 작업들이 엄청나게 간소화 됐다.
도커는 일종의 서버환경을 감싸서, 도커 레벨로 서버를 다룰 수 있게 해주고. 따라서 서버이전,서버 패키지 버전변경등등으로 일일이 서버 설정이 풀필요 해진것이다.
이제 개발자는 단순히
도커를 만들어서, 서버에서 그 도커를 실행시키기만 하면된다...

웹서비스 개발과 마이크로 서비스

  • 모놀리틱 구조
    • 처음에는 하나의 서버에 모든 기능을 넣었다.
      1세대 : 정적패이지 서버
      2세대 : 동적페이지 서버
      3세대 : 다양한 사양자에 요구에 맞춰서 mvc패던으로 구조화된 프레임워크를 사용,빠르게 다양한 기능을 제공
    • 하지만 이제는 너무나 고도화된 서버가 필요해 졌기 때문에 모놀리틱 구조를 사용하지 않는다.
  • 마이크로 서비스
    • 서비스가 방대해짐에따라, 하나의 서버에 모아놓으면, 특정 기능의 문제로 전체 시스템에 장애발생
      즉 서버를 여러개로 분류를 하고 각각에 서버에 기능들을 명시해 놓고 띄어놓은 서버들 사이에 REST API를 통해서 서로 서버들끼리 REST API 통신으로 기능을 호출해나가면서 복잡하게 운영되고 있다.
    • 기능단위로 서버를 사용하기때문에 그 기능에 문제가 생겼을때 24시간 서비스를하는 입장에서 훨씬 편하게 일을 처리할 수 있다.
  • 마이크로 서비스는 여러개의 서버를 관리하다보니까 수시로 코드와 기능을 업데이트해야하기때문에 도커로 각각의 기능을 도커로 감싸서 서버로 배포를 하는것이다.
    ex)
    쇼핑몰 서비스를 운영한다고 가정했을땐
  • 결재 개발팀 서버
  • 장바구니 개발팀 서버
  • 상품등록 개발팀 서버

Dev Ops

서비스가 방대해짐에 따라, 조직 운영도 바꿔야 할 필요가 생김

기존 서비스 조직

  • 개발팀
  • 운영팀
    개발은 언제나 소통이 안됨
    예전에는 위와같은 구조로 서비스를 운영할 수 있었지만 현제에 들어선 사용자들의 니즈가 워낙 다양해지고 그 기능별로 수시로 서버에 릴리즈를 해줘야하기때문에 어떻게보면 마이크로 서비스가 강제된것이다.
    그럼 이 마이크로 서비스에서 각각의 개발팀이 수시로 각자의 분야에서버를 릴리즈를 하게 되는데 그럼 당연히 각각의 팀끼리 소통, 그리고 운영팀의 소통이 어려울 수 밖에 없다.
    그럼 운영하는 입장에서 서비스에 세부서비스가 다운되면 개발팀과의 소통이 당연히 어려울 수 박에없게되는 것이다.

Dev Ops의 탄생 배경

  • 본래 새로운 기능을 릴리즈하면 개발팀이 운영팀에 어떻게 운영할지 알려줘야함
    • micro features라면 많은 기능을 제대로 알려주기 어렵다.
    • 운영이 잘 안될경우, 이 부분은 개발팀 역할이 아니므로 운영팀에 제대로 안알려주는경우가 많다.
  • 수만은 micro features를 운영팀이 제대로 이해하고 대응하지 않으면 서비스 다운또는 비정상동작으로 고객 경험이 극도로 저하된다.
  • 수만은 micro features와 수만은 사용자
    • 엄청난 트래픽을 버텨낼 시스템과 운영법이 필요

위와같은 문제가 발생함에 따라서 다음과 같은 제안을 하게된다.

  • 개발자가 운영팀에 들어가면?
    • 운영효율적인 시스템 개발
    • 운영을 자동화시켜서 운영팀 인력 효율화 가능
    • 운영/개발 전체 이해/소통이 쉬움
      하지만 개발자는 아무도 운영팀에 들어가려하지 않는다. 개발만하고싶어함

그래서 생겨난 DevOps

  • 운영+ 운영시스템 효율화/자동화 프로젝트를 목표로부여!
    • 개발자가 목표를 가지고 개발을 할 수 있음
    • 개발자는 micro features에 대해서도 빠르게 이해할 수 있음

DevOps의 역할

  • Release System 자동화
  • 코드 리뷰, 테스트 자동화
  • 서비스 모니터링 시스템
  • 이슈 발생시 커뮤니케이션 시스템
    한마디로 자동배포하는사람...

위와같은 상황에서 DevOps가 도커를 모르는것은 말이 안된다.

  • 각 마이크로 서비스를 도커로 개발
  • 초댕숑량 서비스를 유지보수하기 위한 서버 핸들링 필요
    • 쿠버네티스개발
  • 수시 릴리즈를 지우너하기 위한 배포시스탬
    • 개발자가 git 에 신규 코드를 릴리즈하면,
    • Jenkins/Travis CI등으로 서버 자동 재가동
    • 배포자동화
  • 수시 릴리즈시, 서비스를 중단되지 않았으면 좋겠음
    • 무중단 배포

위 서비스를 개발하는데 모든 기초는 도커와 리눅스서버에 대한 이해도라고 합니다.

profile
애기 개발자

0개의 댓글