본문 바로가기
Study/Knowledge

DevOps란? - CI/CD, IaC, MSA, Logging ...

DevOps란? 소프트웨어의 개발(Development)과 운영(Operations)의 합성어로서,

소프트웨어 개발자와 정보기술 전문가 간의 소통, 협업 및 통합을 강조하는 개발 환경이나 문화를 말한다.

데브옵스는 소프트웨어 개발조직과 운영조직간의 상호 의존적 대응이며

조직이 소프트웨어 제품과 서비스를 빠른 시간에 개발 및 배포하는 것을 목적으로 한다.

아직 개발과 운영이 분리된 회사가 많지만, 점점 그 경계가 사라지고 있으며,

개발과 배포 운영 (DevOps)에 있어 효율적이고 안정적인 방법으로 떠오르는 좋은 도구들이 많이 나오고 있다.

 

 

 

1.  CI/CD (지속적 통합, 지속적 전달) 

소프트웨어의 개발과 배포, 운영에 있어서 협업중 개발코드에 대한 변경사항이 지속적으로 통합되고, 관리되는 환경은 매우 중요합니다. 이러한 과정을 CI라고 합니다. SVN, Git 등의 서비스를 통해 진행되지만,

현재 붐처럼 떠오르는 MSA(Micro Service Archietecture) 환경에서 CI는 기능 충돌 방지를 제공하며, 신속히 버그를 찾아 품질을 개선하고 검증과 배포의 시간을 최소화하는데 도움을 줄수 있기에 중요함.

또한 CD는  Continuous Delivery & Continuous Deployment 의 의미로 지속적인 서비스 제공, 배포를 의미하는데, 공유레포지토리를 자동으로 Release하며 개발자의 변경사항이 배포 Production에 연결되어 적용되는 환경을 의미함.

 

여기서 DevOps엔지니어는 CI/CD 자동화를 위한 파이프라인을 구성하고 모니터링을 구성하여 개발자들의 개발방향을 가이드해주어 신속한 배포로 보다 안정적이고 신뢰성높은 서비스를 제공하는데 기여함.

DevOps 엔지니어가 사용하는 대표적인 CI/CD 툴로는, Jenkins / Travis CI / Bamboo 등이 있음.

 

 

2.  IaC (Infrastructure as Code)

인프라 운영을 코드로 개발하여 관리하는 도구, "프로그래밍형 인프라"라고도 부름

기존의 수동으로 시스템마다 인프라를 구현하던 시대가 지고, 코드로 개발된 인프라 구성이 활성화 되고있다.

이를 통해, 인프라구성의 시간과 비용이 절감되고, 일관성 보장, 오류감소, 구성변동 제거 등의 강점을 가지게 되었다

IaC Tool 종류

 

  • Chef
  • Puppet
  • Red Hat Ansible
  • Saltstack
  • Terraform 
  • AWS CloudFormation 

이를 통해, 개발을 위한 인프라구성, 프로비저닝 작업을 자동화시킬수 있어, 크게 주목받고 있다

자세한 내용은 이미 이전 글에서 다루고있으니 아래를 참조 바람. 

https://bangu4.tistory.com/143

 

[Infra] IaC의 개념과 종류 - 앤서블, Terraform,Puppet...

정의 인프라 구축도 이제 프로그래밍 시대가 되었다. "프로그래밍형 인프라"라고도 하는 iac (Infrastructure as Code)는 인프라 구성을 마치 소프트웨어를 프로그래밍하는 것처럼 처리하는 방식이다.

bangu4.tistory.com

 

 

 

3. MSA

마이크로서비스 아키텍처는  small services, each running in its own process (스스로 돌아 갈 수 있는 작은 서비스) , independently deployable(독립적 배포 가능 서비스)로 설명하고 있다.

https://martinfowler.com/articles/microservices.html

마이크로 서비스는 완전히 독립적으로 배포가 가능하고, 다른 기술 스택(개발 언어, 데이터베이스 등)에 사용 가능한 서비스 영역을 가진다.

 

MSA vs Monolithic Architecture

[ Monolithic : 단단히 짜여 하나로 되어 있는 ]

아직까지는 많은 소프트웨어가 단단하게 Meshed되 있는 Monolithic 형태로 구현되어 있고, 소규모 프로젝트에는 간단한 Architecture이고, 유지보수가 용이하기 때문에 Monolithic Architecture가 훨씬 합리적임

 

Monolithic Architecture가 가지는 한계점, 취약점

  • 서비스/프로젝트가 커지면 커질수록, Monolithic Architecture는 영향도 파악 및 전체 시스템 구조의 파악에 어려움이 있음.
  • 빌드 시간 및 테스트시간, 그리고 배포시간이 기하급수적으로 늘어나게 됨.
  • 서비스를 부분적으로 Scale-Out 하기가 어렵고 비용이 많이 들어감.
  • 부분의 장애가 전체 서비스의 장애로 이어지는 경우가 발생하게 됨.

 

 

MSA는 비즈니스 민첩성(Business agility)과 관련이 큼. (경영자는 좋아하지만 개발자는 싫어한다는 MSA..)

서비스나 프로젝트가 크고, 복잡하고, 장기적으로 운영될 수록, MSA의 장점이 더욱 드러나게 됨.

 

MSA가 가지는 특징

  • 각각의 서비스는 그 크기가 작을 뿐, 서비스 자체는 하나의 모놀리틱 아키텍쳐와 유사한 구조를 가짐
  • 각각의 서비스는 독립적으로 배포가 가능해야 함.
  • 각각의 서비스는 다른 서비스에 대한 의존성이 최소화 되어야함
  • 각 서비스는 개별 프로세스로 구동 되며, REST와 같은 가벼운 방식으로 통신되어야 함.

일반적으로 하나의 서비스는 하나의 기능이며, 하나의 프로젝트라고 볼 수 있지만, 비즈니스와 시스템의 실정에 맞게 서비스의 범위(크기)를 설정하는 것이 중요함.

 

MSA가 극복한 한계점

  • 배포(deployment) 관점
    * 서비스 별 개별 배포 가능 ( 배포 시 전체 서비스의 중단이 없음)
    • 요구사항을 신속하게 반영하여 빠르게 배포할 수 있음.
  • 확장(scaling) 관점
    * 특정 서비스에 대한 확장성이 용이함.
    • 클라우드 사용에 적합한 아키텍쳐.
  • 장애(failure) 관점
    * 장애가 전체 서비스로 확장될 가능성이 적음
    • 부분적 장애에 대한 격리가 수월함

신기술의 적용이 유연하고, 서비스를 polyglot하게 개발/운영 할 수 있다는 장점이 있음.

 

MSA의 단점

Monolithic Architecture은 단순한 아키텍쳐인데 비해 MSA는 보다 복잡한 아키텍쳐로, 전체 서비스가 커짐에 따라 그 복잡도가 기하급수적으로 늘어날 수 있다.

  • 성능 - 서비스 간 호출 시 API를 사용하기 때문에, 통신 비용이나, Latency가 그만큼 늘어나게 됨.
  • 테스트 / 트랜잭션 - 서비스가 분리되어 있기 때문에 테스트와 트랜잭션의 복잡도가 증가하고, 많은 자원을 필요로 하므로 큰 비용이 발생함.
  • 데이터 관리 - 데이터가 여러 서비스에 걸쳐 분산되기 때문에 한번에 조회하기 어렵고, 데이터의 정합성 관리가 어려움.

 

MSA가 가지는 구조적 컴포넌트

  • Inner Architecture 

         서비스할 기능별 MSA 설계 - 쇼핑몰이라면, 주문하기부분, 결제부분 등으로 나누어 서비스할지

         DB 구조 설계 - 데이터의 정합성을 보장하면서 어떠한 DB 서비스들을 사용할지

         서비스별 API 설계 

         컴포넌트별 Layer 설계 

  • Outer Architecture 

         External Gateway  -  외부에서 사용자가 서비스 사용을 위한 접근시, 인증, 정책관리 등을 수행

         Service Mesh - 이너구조상 MSA 컴포넌트별 통신을 위한 네트워킹, 트래픽관리 라우팅을 수행 

         Container Management - 쿠버네티스와 같은 서비스로 운영의 유연성과 자율성을 제공

         Backing Services - 실시간 처리시스템을 위한 비동기 메세지큐를 제공, 장애 대응을 위한 시스템 

         Telemetry - 서비스별 상태 모니터링 및 이슈대응을 위한 역할을 담당 

         CI/CD Automation - 서비스 개발에 대한 지속적인 통합과 배포를 자동화하는 기능요소

 

MSA 대한 이해를 돕는 추가 상세 내용과 다양한 참조글 링크

 

 

 

4. 모니터링 & 로깅 

DevOps에 있어서 모니터링은 빠질수 없는 분야이다.

Application Performance Management (APM) 에 대한 퍼포먼스와 트렌잭션을 분석하는 모니터링이 필요하지만, 

Infrastrucre 측면에서도 Server, 라우터, 스위치를 포함한  Network 전반에 대한 모니터링도 필요하다.

 

 

Application 영역

 

애플리케이션 부분에 있어서 모니터링은,

신속한 버그 추적과 재발 방지를 위해 필요하며,

최소 응답시간을 지속적으로 유지하기 위해서 모니터링 서비스가 반드시 도입되야 함.

좀 더 능동적으로 APM을 사용한다면 발생 빈도가 높은 메소드를 분석하여 코드 리팩토링에 사용 할 수도 있다.

오픈소스로는 네이버의 핀포인트 와 와탭의 CTO가 커미터로 참여하고 있는 스카우터 가 있다.

해외에서는 New RelicAppDynamics 가 유명하며 국내에는  WhaTap 이 APM 서비스를 제공하고 있다.

 

 

 

Infrastructure 영역

인프라 측면에서는

NagiosZabbix 와 같은 오픈소스 기반의 모니터링 솔루션이 많이 제공되고 있다.

해외 서비스로는 DataDog 가 유명하며, 국내에서는 WhaTap 이 Infrastructure 모니터링을 제공 한다. 

Log Analysis

로그 분석은 플랫폼에서 제공하는 시스템 로그를 분석하거나 커스터마이징된 로그 데이터를 분석하는 도구이다.

로그 분석을 통해 시스템의 결함을 미리 알아낼 수도 있으며,

비지니스 데이터를 분석할 수도 있다.

SplunkElastic, PaperTrail, Logstash,  Loggly,  Logentries,  SumoLogic 과 같은 벤더를 통해 서비스를 제공받을 수 있다.

 

 

위와 같은 신기술의 발전과 다양한 오픈소스 도구들이

DevOps의 신속한 개발, 안정성, 신속한 전달 , 유연한 확장, 협업향상, 보안 등의 이슈를 해결해주고 있어

빠르게 떠오르고 있다.

 

 

해당분야의 지식에 더 관심이 있고, 일을 하고 싶다면, 

AWS DevOps Professional 자격증이나, MicroSoft Azure DevOps 자격증을 공부하여 취득해보길 바랍니다.

https://aws.amazon.com/ko/certification/certified-devops-engineer-professional/

 

AWS 공인 DevOps 엔지니어 – 프로페셔널

AWS 공인 DevOps 엔지니어 – 프로페셔널 시험은 AWS 환경을 프로비저닝, 운영 및 관리한 실무 경력이 2년 이상이며 DevOps 엔지니어 역할을 수행하는 사람을 대상으로 합니다. 실무 경험보다 더 좋은

aws.amazon.com

 

 

 

참고 사이트

더보기