2/8 정리

잼우·2022년 2월 8일
1

DevOps

목록 보기
2/3

*공부한 내용을 토대로 혼자서 정리하는 글입니다.
틀린 부분이나 보충할 부분 지적 언제든 환영합니다 :)


수직 확장 vs. 수평 확장

규모 확장에는 크게 두가지 방법이 있습니다.
바로 수직 확장(Vertical Scaling, Scale Up)과 수평 확장(Horizontal Scaling, Scale Out)입니다.

*수직 확장

  1. 서버의 성능(CPU, RAM, 스토리지, 네트워크 I/O)을 높이는 방법
  2. 수정 내역을 한곳에만 반영하면 되기 때문에 수정, 업데이트가 쉬움
  3. 확장에 한계가 있고 경우에 따라서는 특정 제조사 전용 장비만 써야 하는 등의 단점이 있음
  4. 수직 확장은 장애 대응이 어려움. 만일 고성능의 서버가 서비스를 제공하는 유일한 하드웨어라면, 그 장비의 성능이 어떠하든지 간에, 하드웨어 고장 등의 장애가 발생하면 즉시 서비스가 중단됨

*수평 확장

  1. 더 많은 서버를 도입하는 방법
  2. 부하가 여러 시스템에 분산되기 때문에 시스템 장애에 더 강함
  3. 데이터가 담긴 컴퓨터가 가용성을 위해 복제되는 경우, 각 컴퓨터의 데이터가 동기화(sync)되어야 함

IT 인프라의 자동화를 돕는 툴로는 어떤 것들이 있나요?

  1. Anusable

Ansible은 오픈 소스 인프라 자동화 도구입니다.
애플리케이션에 IT 구성요소를 배치, 구성 및 조정하는 기능을 자동화 합니다.

Ansible은 인프라 자동화에 사용되는 최고의 DevOps 도구 중 하나이며, 에이전트 없는 아키텍처로 인해 서버에 추가 소프트웨어가 필요하지 않습니다.

  1. Puppet

Puppet은 자동화에 사용되는 코드 도구로서의 오픈 소스 인프라이다. 그것은 Puppet이라는 고유의 언어를 가지고 있습니다.

다른 DevOps 프로그램의 수동 스크립트 기반 변경을 자동화합니다.
구성 관리 도구 구문은 기본 응용 프로그램의 OS 및 구문과 분리됩니다.

  1. SaltStack

stackSaltStack은 고속 인프라 자동화 툴입니다.
IT 인프라를 최적으로 관리, 구성 및 조정합니다.

솔트스택은 솔트 마스터의 명령을 구현하는 마스터 슬레이브 아키텍처를 가지고 있습니다.

  1. Terraform

Terraform은 코드 자동화 도구로서의 오픈 소스 인프라입니다.
AWS, Azure, GCP 등과 같은 클라우드 제공업체와 잘 협력합니다.
기업에서 Kubernetes clusters를 관리하는 데 자주 사용됩니다.

  1. Docker

Docker는 컨테이너화에 사용되는 최고의 인프라 자동화 도구 중 하나입니다. 이 플랫폼은 서로 영향을 미치지 않고 단일 서버에서 여러 애플리케이션을 실행할 수 있도록 지원합니다.

별도의 하드웨어 설정으로 저장공간을 고립 가능하게합니다. 이것은 서버와 같은 방식으로 애플리케이션을 구현하는 데 도움이 됩니다.

Docker는 구성요소가 애플리케이션을 신속하게 구축하기 때문에 널리 사용되는 인프라 도구 중 하나입니다. 리소스를 최적화하고 충돌을 줄일 수 있는 고가용성을 제공합니다.

  1. Chef

Chef는 구성 관리에 사용되는 최고의 Ruby 기반 인프라 자동화 도구 중 하나입니다. Ruby DSL(도메인별 언어) 기반의 클라이언트-서버 아키텍처를 사용합니다.

이 툴은 IT 인프라의 속도, 규모 및 일관성을 제공합니다. 사용자가 변화에 신속하게 적응할 수 있도록 인프라를 코드로 접근합니다.

  1. AWS CloudFormation

AWS CloudFormation은 가장 인기 있는 클라우드 기반 인프라 자동화 도구 중 하나입니다. 인프라를 코드로 사용하여 AWS 리소스를 쉽게 모델링하고 설정할 수 있습니다.

AWS에서 리소스를 관리하고 애플리케이션을 모니터링하여 시간과 노력을 절약합니다. 템플릿을 사용하여 스택을 생성, 업데이트 및 삭제함으로써 리소스를 프로비저닝하고 구성합니다.

IT 인프라를 전 세계적으로 확장할 수 있도록 지원합니다.

  1. Jenkins

Jenkins는 애플리케이션 제공을 위한 가장 빠른 통합 자동화 도구 중 하나입니다. GitHub 또는 SVN과 같은 버전 제어 시스템으로 사용되는 자바 기반 오케스트레이션 (컴퓨터 시스템과 애플리케이션, 서비스의 자동화된 설정, 관리, 조정을 의미, 프로세스 또는 워크플로우를 자동화하는 방식) 도구입니다.

더 이상 단순한 CI 툴이 아니며 애플리케이션 프로비저닝 (사용자의 요구에 맞게 시스템 자원을 할당, 배치, 배포해두고 필요에 따라 즉시 사용할 수 있는 상태로 준비시켜두는 것) 및 배치를 위한 파이프라인을 구축하는 데 사용됩니다.

최근에는 사용자가 완전한 코드로 CI/CD 파이프라인을 얻을 수 있도록 하는 코드 기능으로 파이프라인을 도입하였습니다.

출처: https://www.hitechnectar.com/blogs/infrastructure-automation-tools/#InfrastructureAutomationToolsPuppet


문제 풀이

1. 각 팀의 목표는 어떻게 다른가요? 두 팀의 목표에서 상충되는 부분이 존재하나요?

*Dev 팀의 목표
잦은 업데이트 및 배포로 고객에게 제공한 변경을 빠르게 이용하길 원함.

*Ops 팀의 목표
제공하고자 하는 소프트웨어의 안정성에 더 중점을 둠.

-> Dev 팀은 생산성 향상을 위한 프레임워크를 도입하고 싶어 하지만 Ops 팀은 안정성이 보장되지 않기 때문에 꺼림.
-> 한쪽은 변화를, 한쪽은 안정성을 추구하다 보니 서로의 견해 차이가 생김.


2. DevOps를 실현 가능하게 하기 위해 기술이 필요한 부분과, 기술이 아닌 문화로 풀어야 할 부분은 각각 무엇인가요? CI/CD 파이프라인에 근거해 답해봅시다.

Plan → Code → Build → Test → Release → Deploy→ Operate

CI -> Plan → Code → Build → Test
CD -> Release → Deploy → Operate

*기술이 필요한 부분

-> 기술은 개발자가 직접 코딩하는 과정이기 때문에 Code와 Build 과정이라고 생각했습니다.

Code → 개발자가 코드를 코드저장소에 Push 함.
Build → 코드저장소에서 코드를 가져와서 유닛테스트 후 빌드함.

*문화로 풀어야 할 부분

-> DevOps의 중심에는 공통의 책임, 상호 신뢰 및 열린 소통의 문화가 있습니다.
로컬 빌드에서 작동한다고 개발 팀이 작업을 완료 처리하는 것만으로는 충분하지 않습니다.
이는 부서 간의 장벽을 허물고 품질 보증팀, 보안 및 인프라팀과 협업하여 프로세스에서 해당 팀의 과정을 이해하는 것을 의미합니다.

Test → 코드 빌드의 결과물이 다른 모듈과 잘 통합되는지 확인함.
Release → 배포 가능한 소프트웨어 패키지를 작성함.
Deploy → 프로비저닝 진행 및 서비스 사용자에게 노출.
Plan → 서비스 계획 수립.
Operate → 서비스 배포 후 현황 파악 및 문제 감지.

참조: https://www.jetbrains.com/ko-kr/teamcity/ci-cd-guide/devops-ci-cd/


profile
DevOps 새내기

0개의 댓글