서버관리의 역사

in Dev on Dev


서버관리의 역사

서버관리의 역사를 기술 발전순으로 따라가보자.
서버의 상태를 관리하기 위한 서버기술자들의 노력으로 탄생했다.

1. 자체 서버 운영

자체 서버를 운영하고, 서버와 랙을 관리한다.
회사에서 랜선도 직접 꼽고, 라우터를 연결하는 등.

과정

  • 서버 주문 - 서버 설치 - 컴퓨터 HW 연결(CPU, Memory 등) - 네트워크 연결 - OS 설치 - 계정 설정 …
  • 성능이 좋은 것을 미리 구매하고 효율적인 사용을 위해 여러 어플리케이션을 설치.
  • 서버를 설정하기 위해 많은 노력과 시간, 비용이 듬

예시

Node.js를 자체 서버에 설치한다고 생각해보자.

  • 먼저 시스템 유저를 설정하고, 환경변수를 설정하고, 방화벽 설정, 네트워크 설정, 의존성, Nodejs 실행, git에서 소스 가져오기, 설정…. -> Run
    이렇게 많은 과정을 거쳐서 nodsjs를 실행하게 된다.

문제점

  • 만약 개발자가 명령어를 입력해서 환경을 바꾸면, 상태가 바뀔텐데 어떻게 대처할 것인가?
  • 버전업을 할 경우 제대로 실행될 것인지?

해결방안

ppt에 매뉴얼을 작성하고, 버전관리를 함
그러나, 문서의 정확도, 신뢰성, 작성날짜 등 의문의 들기 시작함

2. 설정 관리 도구의 등장

설정을 자동으로 관리해주는 도구를 사용.

종류

CHEF, puppet, ansible 등

장점

  • 상태관리 코드로 버전관리도 가능하고, 상태파일만 있으면 install이 편리해짐.
  • 이전 담당자가 어떤 것을 했는지 알 수 있고, 협업도 가능하다.

    단점

  • 어렵다. 러닝커브가 존재함.
  • 한 서버에 설치하면 잘 되지만, 여러 버전을 한 서버에 설치는 불가능.

3. 가상머신의 등장

Virtual Box, VMWare 등의 가상머신이 등장하면서 좀 더 편리해짐.

예시

1번 Virtual Box에 Jenkins를 설치하고, 2번에 Wordpress, 3번에 Chat을 설치하면 잘 돌아간다.

장점

  • 가상머신은 서버가 우선 돌아가도록 보장해준다.
  • 한 서버에 가상머신을 여러개 설치해서 쓸 수 있다.
  • 현재 상태를 저장할 수 있다.

    단점

  • 버전을 업데이트하거나, 처음부터 다시 설정할 땐 알 수 없다.
  • 가상머신에서 그 과정을 다 기록하고 있진 않기 때문에.
  • 또한, 자신이 만든 이미지를 다른 곳에 또 띄우고 싶다면 40GB, 80GB씩 되기 때문에 이미지 공유가 쉽지 않다.
  • 느리다 !! 손해보는 느낌!

4. 클라우드의 등장

종류

Amazon AWS, Google Cloud, MS Azure 등

장점

  • 하드웨어 파편화 문제 해결
  • 가상화된 환경만으로 아키텍처 구성이 가능해진다.
  • 이미지를 기반으로 다수의 서버 상태 관리가 가능하다.
  • 마치 전기를 사용하듯 편리하다.

문제점

서버 운영 자체는, 여전히 누군가가 담당하여 관리해야한다.

5. PaaS 등장

  • PaaS(Platform-as-a-service)는 하드웨어 및 소프트웨어 플랫폼을 제공하는 클라우드 컴퓨팅을 뜻한다.

    종류

    Heroku, Next.js의 경우 Vercel, Netlify, AWS Elastic Beanstalk, Google Cloud App Engine 등.

장점

  • 소스 코드만으로 배포가 가능하다.
  • 일반화된 프로비저닝 방법을 제공한다.
  • 프로비저닝(provisioning)은 사용자의 요구에 맞게 시스템 자원을 할당, 배치, 배포해 두었다가 필요 시 시스템을 즉시 사용할 수 있는 상태로 미리 준비해 두는 것을 말한다.

단점

  • 프로비저닝 과정에 개입할 수 없다. 커스터마이징할 때 문제가 생김
  • 애플리케이션을 PaaS 방식에 맞게 작성해야함.
  • 서버에 대한 원격 접속 시스템을 제공하지 않음.
  • 서버에 파일 시스템을 사용할 수 없음
  • Site패키지를 설치할 수 없음
  • 로그 수집을 제한적인 방식으로 허용(STDOUT)
  • 애플리케이션 배포에 대한 새로운 패러다임

PaaS에서 할 수 있을까?

  • 크론잡(문자발송, 예약, 정산 등)
  • 데이터 분석(BigQuery, S3등 연동)
  • 로그 분석(엘라스틱 서치, 스택드라이버, 클라우드와치 등)
  • 애플리케이션 성능 모니터링
  • A/B테스트, Canary 배포
  • 네트워크, 스토리지 설정

6. 도커의 등장

  • 2013년에 DotCloud(현 Docker)에서 첫 공개.

  • 컨테이너 : 격리된 환경에서 작동하는프로세스.

  • 리눅스 커널의 여러 기술을 활용
  • 하드웨어 가상화 기술보다 가벼움
  • 이미지 단위로 프로세스 실행환경을 구성

도커가 등장하고, 서버관리/개발 방식이 완전히 바뀌었다. 예시) docker compose up 명령어

장점

  • 어디서든 돌아간다. AWS, Azure Google Cloud 등..
  • 어떠한 프로그램도 컨테이너로 만들 수 있다.
  • 명령어가 동일하다. docker up 명령어로 (npm start, gradle start 등을 모두 docker up으로 실행)

가상머신과의 차이점

  • 가상머신처럼 독립적으로 실행되지만, 가상머신보다 빠르고, 쉽고, 효율적이다.

도커가 가져온 변화

  • 클라우드 이미지보다 관리하기 쉬움
  • 다른 프로세스와 격리되어 가상머신처럼 사용하지만 성능저하가 거의 없음
  • 복잡한 기술(namespace, cgroups, network,…)을 몰라도 사용할 수 있음
  • 이미지 빌드 기록이 남음
  • 코드와 설정으로 관리 -> 재현 및 수정 가능
  • 오픈 소스 -> 특정 회사 기술에 종속적이지 않음

도커의 기능

  • 자원격리 : 이 프로그램을 돌릴 때 다른 프로그램은 모르게 하자. 격리하기.
    • 프로세스, 파일, 디렉토리 -> 가상으로 분리함
      컴퓨터 HW(CPU, Memory, I/O device)는 그룹별로 제한함
  • 이 자원격리 기능이 도커 이전에는 굉장한 고급기능이었지만, 도커에서는 매우 유용하게 쓸 수 있다.
    리눅스 기능을 이용한 효율적인 서버관리

도커의 관리

실행까지는 편했는데,

    1. 배포는 어떻게 할까?

    명령어 자체는 간단하지만, 서버가 여러개인 경우 일일이 docker stop && docker run 을 하기 번거롭다.

    서버가 굉장히 많을 경우, 일일이 롤아웃/롤백.. 어떻게 할까?

    1. 서비스 검색(Service discovery)은 어떻게 할까?

      사용자가 많아지면, LoadBalancer를 한땀한땀 해야하고, 마이크로서비스를 사용할 경우 더 방대해짐

    1. 서비스 노출(Gateway)은 어떻게 할까?

      Container Orchestration : 복잡한 컨테이너 환경을 효과적으로 관리하기 위한 도구

      • Cluster : 서버를 cluster 라는 개념으로 묶어두고, master에 명령을 내리면 알아서 배포해준다.
      • State : 상태관리. 실제 서버에 접속해서 상태를 변경할 필요없이, 코드로서 관리가 가능하다.
      • Scheduling : 배포관리. 서버 1,2,3의 사용량을 계속 감시하고 있다가 상대적으로 적은 곳을 골라서 배포하고, 만약 모두 포화상태라면 새로 서버를 만들어주기도 한다.
      • Rollout/Rollback : 배포 버전관리. 버전을 업데이트하거나, 문제가 생겨서 이전으로 돌아가려고 할 때 일괄적으로 적용된다.
      • Service Discovery : 서비스 등록 및 조회. 기존의 경우, ip를 일일이 추가해줘야하는데, ip가 생길 때마다 자동으로 중앙에서 저장해주기 때문에 일일이 손으로 관리할 필요가 없다.
      • Volume : 디렉토리를 확장하고 싶을 때, 설정만 하면 된다. 종류가 달라도 쉽게 붙일 수 있다.

      Container Orchestration의 종류 : DEIS, Dancher, Mesos, Marathon, Nomad 등

      -> 컨테이너 관리도구 춘추전국시대를 지나…! 쿠버네티스가 등장했다.

7. 쿠버네티스의 등장

kubernetes

  • 컨테이너를 쉽고 빠르게 배포/확장하고 관리를 자동화해주는 오픈소스 플랫폼

    쿠버네티스 소개

  • 1주일에 20억개 컨테이너를 생성하는 google이 컨테이너 배포 시스템으로 사용하던 borg를 기반으로 만든 오픈소스
  • Productions-Grade Container Orchestration : 운영레벨에서 사용하능한 컨테이너 오케스트레이션.
  • Automated container deployment, sacling, and management
  • Planet Scale : 행성 스케일.
  • Never Outgrow : 다양한 요구사항을 만족시킬 수 있는 유연함
  • Run Anywhere : 어디서나 동작한다. 오픈소스에 표준화되어있기 때문에.
  • 무한한 확장성 : 머신러닝-Kubeflow, CI/CD-Tekton, 서비스메시, 서버리스
  • image-20210708112706466
  • [글로벌 칼럼쏘리! 리눅스, 이제 주인공은 ‘쿠버네티스’](https://www.itworld.co.kr/opinion/112464)

8. 서비스메시의 등장

출처

subicura님의 강의
https://subicura.com/


© 2020.08. by ritajeong

Powered by ritajeong