tech blog

5 분 소요


DevOps

img1

정의

Development + Operation

개발과 운영을 결합시켜 만든 개발 방법론을 의미한다.

소프트웨어 개발과 운영을 통합하여 효율성, 협력, 속도, 안정성을 개선하는 개발 및 운영 방법론이다.

장점

속도
애플리케이션 개발 단계를 자동화하여 애플리케이션을 더 짧은 주기로 고객에게 제공할 수 있다.

신속한 제공
릴리스 빈도와 속도를 개선하여 제품을 더 빠르게 개선할 수 있다.

안정성
CI/CD와 같은 방식을 사용하여 각 변경 사항이 제대로 작동하고 안전한지 테스트를 할 수 있다.
모니터링과 로깅을 통해 실시간으로 성능에 대한 정보를 얻을 수 있다.

확장
자동화와 일관성이 지원되기 때문에 위험을 줄이면서 복합한 시스템을 효율적으로 관리할 수 있다.

협업 강화
개발자와 운영팀이 긴밀하게 협력하고 많은 책임을 공유한다.
이를 통해서 비효율성을 줄일 수 있다.

보안
자동화된 규정 준수 정책, 세분화된 제어 및 구성 관리 기술을 사용하여 보안을 유지할 수 있다.

→ 애플리케이션 개발, 배포 단계를 자동화하는 것을 CI/CD (Continuous Integration/Continuous Delivery)라고 하는데 이에 대해서 자세히 알아보자.

CI/CD

CI/CD는 애플리케이션 개발 단계를 자동화하여 애플리케이션을 더욱 짧은 주기로 고객에게 제공하는 방법을 말한다.

img1

CI 는 개발자를 위한 자동화 프로세스인 지속적인 통합을 의미하며, CD는 지속적인 서비스 제공(Continuous Delivery) 및 지속적인 배포(Continuous Deployment)를 의미한다.

이제 각각에 대해서 알아보자.

CI (Continuous Integration)

CI는 지속적인 통합을 의미하는데 간단하게 빌드와 테스트를 자동화하는 것이라고 생각하면 된다.

필요성

CI가 없을 때는 여러 개발자가 수정한 변경 사항을 한번에 모아서 Merge를 했었는데 이때 만약 에러가 발생하면 어느 곳에서 에러가 발생한지 디버깅 하는 것이 굉장히 어려웠다.

→ CI를 성공적으로 구축하게 되면 코드를 변경할 때마다 바로 빌드 및 테스트가 진행되기 때문에 위와 같은 문제가 발생하지 않는다.

과정

  1. 개발자가 코드를 수정하고 CI tool에 병합을 요청한다.
  2. CI tool에서 변경된 코드를 빌드하고 테스트를 수행한다.
  3. 문제가 없다면 코드를 병합한다.
  4. 만약 테스트가 실패하면 바로 개발자에게 피드백을 준다.

CD (Continuous Delivery/Deployment)

CD는 배포를 자동화하는 과정이라고 생각하면 된다. 지속적인 서비스 제공(Continuous Delivery) 또는 지속적인 서비스 배포(Continuous Deployment)를 의미하며 이 두 용어는 상호 교환적으로 사용할 수 있다.

이 두가지 의미 모두 파이프라인의 추가 단계에 대한 자동화를 의미하지만 때로는 얼마나 많은 자동화가 이루어지고 있는지를 설명하기 위해 별도로 사용되기도 한다.

필요성

하나의 서버만 운영한다면 직접 이 서버에 들어가서 배포를 진행하면 된다.

그런데 서버가 여러대가 있다면?

하나 하나 서버에 들어가서 수동으로 스크립트를 실행하여 배포해야 한다. 이는 굉장히 비효율적이다.

→ CD를 구축하게 되면 모든 서버에 자동으로 배포할 수 있다.

Continuous Delivery

애플리케이션에 적용한 변경 사항이 버그 테스트를 거쳐 리포지토리에 자동으로 업로드되는 것을 의미한다.

리포지토리에 올라온 것을 개발자나 운영팀에서 직접 검증하고 애플리케이션을 실시간으로 프로덕션 환경에 수동 배포한다.

Continuous Deployment

개발자의 변경 사항을 리포지토리에서 고객이 사용 가능한 프로덕션 환경까지 자동으로 릴리스하는 것을 의미한다.

지속적인 서비스 제공(Continuous Delivery)과의 차이점은 개발자, 운영팀에서 리포지토리에 올라온 릴리스를 확인하지 않고 자동으로 배포까지 수행한다는 것이다.

CI/CD를 위한 대표적인 도구

Jenkins, Gihub Actions, Circleci, GitLab CI/CD등이 있다.
이 중에서 Jenkins를 가장 많이 사용한다.

무중단 배포

다운타임 (DownTime)

img1

한대의 서버를 사용하여 서비스를 운영한다고 생각해보자. V1이 실행되고 있는 상황에서 새로운 기능이 추가된 V2가 개발이 완료됐다. 사용자에게 새로운 기능을 제공하기 위해서는 V2를 배포해야 한다.

하지만 서버를 한대로 운영하고 있기 때문에 V2를 실행하기 위해서는 V1을 종료하고 V2를 실행해야 한다.

V1을 종료하고 V2를 실행하는 동안에 사용자는 서비스를 이용할 수 없다. 이를 다운타임(downTime)이라고 한다.

→ 다운타임 없이 새로운 기능을 추가하기 위한 방법을 무중단 배포라고 한다. 이를 위해서는 최소한 2대의 서버가 있어야 한다.

리버스 프록시 (Reverse Proxy)

img1

무중단 배포를 이해하기 위해서는 리버스 프록시에 대해서 알아야 한다.

리버스 프록시란 클라이언트와 웹 서버 간의 중개자 역할을 하는 서버이다.

서버 대신에 클라이언트의 요청을 대신 받아서 웹 서버로 전달하고, 웹 서버의 응답을 클라이언트에게 전달하는 역할을 수행한다.

이를 통해서 웹 서버의 부하를 분산시키고, 보안을 강화할 수 있다.

장점

로드 밸런싱
웹 서버에 동시에 많은 트래픽이 몰릴 때, 서버에 부하가 발생할 수 있다.

리버스 프록시를 사용하면 클라이언트의 요청을 여러 대의 서버로 분산시켜 각 서버의 부하를 줄이고, 서버의 가용성을 높여 안정적으로 서비스를 운영할 수 있다.

보안 강화
리버스 프록시를 사용하면 외부에서 서버로 바로 접근하지 못하게 된다.

서버와 클라이언트 사이에서 악성 요청을 필터링하거나, 접근 제한과 같은 역할을 수행할 수 있다.

캐싱 및 가속화
자주 사용되는 정적 파일(CSS, JS)를 캐시에 저장하여 빠르게 제공할 수 있다.

이로 인해 서버의 부하를 줄이고 응답 시간을 단축시킬 수 있다.

단점

추가적인 서버 설정 비용
리버스 프록시를 사용하기 위해서는 추가적인 서버 설정과 관리가 요구된다.

네트워크 지연
중간 다리(리버스 프록시)를 거치기 때문에 약간의 네트워크 비용이 발생한다.

복잡성 증가
아키텍처가 복잡해질 수 있다.

→ 리버스 프록시의 장단점은 사실 프록시 패턴의 장단점과 동일하다.

로드 밸런싱

정의

컴퓨터 네트워크 기술의 일종으로 둘 혹은 셋 이상의 중앙처리장치 혹은 저장장치와 같은 컴퓨터 자원들에게 작업, 즉 부하를 나누는 것을 의미한다.

필요성

서비스 런칭 단계에서는 고객이 거의 없기 때문에 서버 한대로도 모든 요청을 처리할 수 있다.

하지만 점점 고객의 수가 늘어나고 서비스가 확장되면 서버 한대로는 모든 요청을 처리할 수 없게 된다.

증가하는 트래픽을 대처하기 위해서 사용할 수 있는 방법은 크게 2가지로 Scale-up, Scale-out 이 있다.

img1

  • Scale up : 서버 자체의 성능을 향상하는 방법으로 비용이 상대적으로 많이 든다.
  • Scale out : 서버를 증설하는 방법이다. 이 방법을 사용하기 위해서는 로드밸런싱이 필수로 요구된다.

종류

L4 로드밸런싱
전송 계층에서 로드(트래픽)을 분산시킨다.
IP주소나 포트번호, MAC주소 등에 따라 트래픽을 나누고 분선처리를 할 수 있다.

L7 로드밸런싱
애플리케이션 계층에서 로드를 분산시킨다.
HTTP, SMTP, FTP 등을 바탕으로 로드를 분산 처리할 수 있다.

로드밸런싱 알고리즘

라운드로빈 방식

단순히 서버로 요청이 들어온 순서를 바탕으로 처리하는 방식이다.

클라이언트의 요청 순서에 따라 처리되기 때문에 여러 대의 서버가 동일한 스펙을 가지고 있고, 서버와의 연결이 오래 지속되지 않을 때 사용하면 좋다.

가중 라운드로빈 방식

서버마다 가중치를 설정하고 가중치가 높은 서버에 클라이언트의 요청을 우선적으로 배분하는 방식이다.

각 서버의 트래픽 처리 능력이 다를 때 사용한다.

IP 해시 방식

클라이언트의 IP 주소를 바탕으로 해시함수를 돌려서 항상 동일한 서버에 도달하게 만드는 방식이다.

클라이언트는 항상 동일한 서버로부터 서비스를 받을 수 있게 된다.

최소 연결 방식

클라이언트 요청이 들어올 때를 기준으로 가장 트래픽이 적은 서버로 연결하는 방식이다.

서버에 분산된 트래픽이 일정하지 않을 때 적합하다.

최소 리스폰타임

서버의 연결 상태와 응답 시간을 모두 고려하여 트래픽을 분산하는 방식이다.

무중단 배포 방식

롤링(Rolling) 배포

img1

→ 여기서의 Nginx는 로드밸런서 역할을 하는 리버스 프록시라고 생각하면 된다.

롤링 배포 방식은 사용중인 인스턴스 내에서 새로운 버전을 점진적으로 교체해 나가는 방식으로 무중단 배포의 가장 기본적인 방법이다.

위에서부터 차례대로 서버1, 서버2, 서버3이라고 해보자.

과정

  1. 로드밸런서(Nginx)에서 서버1로 라우팅되지 않게 설정한다.
  2. 서버1에 새로운 버전을 배포한다.
  3. 로드밸런서에서 다시 서버1로 라우팅될 수 있도록 변경한다.
  4. 이 과정을 서버2, 서버3에 점진적으로 적용한다.

장점

차례대로 배포를 진행하기 때문에 상황에 따라서 롤백이 어렵지 않다.

추가적인 인스턴스를 늘리지 않아도 된다.

단점

새로운 버전을 배포할 때마다 처리할 수 있는 서버가 줄어들기 때문에 트래픽이 몰릴 수 있다.

배포가 진행될 때 구버전과 신버전이 동시에 존재하기 때문에 호환성 문제가 발생할 수 있다.

Blue Green 배포 방식

img1

→ 블루는 구버전을, 그린은 신버전을 의미한다.

운영중인 구버전과 동일하게 신버전 인스턴스를 구성하고 로드밸런서를 사용하여 모든 트래픽을 한번에 신버전으로 전환하는 방식이다.

장점

구버전의 인스턴스가 그대로 남아있기 때문에 롤백이 쉽다.

한번에 라우팅을 변경하기 때문에 배포하는 속도가 빠르다.

구버전 환경을 다음 배포에 재사용할 수 있다.

단점

구버전과 신버전을 가지고 있어야 하기 때문에 시스템 자원이 2배로 필요하다.

카나리 배포 방식

img1

과정

  1. 신버전을 소수의 유저들에게 배포하고 문제가 없는지 확인한다.
  2. 만약 문제가 없다면 점차 많은 유저에게 배포한다.

→ 블루 그린 방식과 유사하지만 트래픽을 한번에 바꾸는 것이 아니라 단계적으로 바꾸는 것이 차이점이다.

장점

성능 모니터링에 유용하다.

A/B 테스트로 활용할 수 있다.

  • A/B 테스트란?

    A/B 테스팅이란 웹 사이트 방문자를 임의로 두 집단으로 나누고, 한 집단에게는 기존 사이트를 보여주고 다른 집단에게는 새로운 사이트를 보여준 다음, 두 집단 중 어떤 집단이 더 높은 성과를 보이는지 측정하여, 새 사이트가 기존 사이트에 비해 좋은지를 정량적으로 평가하는 방식을 말한다.

단점

네트워크 트래픽을 제어하는 부담이 있다.

참고 사이트

참고