운영 설계

자원 관리 및 최적화

클라우드 자원 관리

클라우드 자원 관리 최적화는 단순히 기술적 용량 관리를 넘어 비즈니스 성과 대비 비용 효율성을 극대화하는 지속적인 활동으로 재정의됩니다.

사용한 만큼 지불하는 클라우드 모델은 관리가 소홀할 경우 불필요한 비용 낭비로 이어질 수 있어, 기술적 역량과 재무적 운영(FinOps)을 결합한 전략적 접근이 필요합니다.

초기 설계 단계부터 탄력적 설계를 고려함으로써 애플리케이션과 인프라가 수요 변화에 유연하게 대응할 수 있도록 하고, 불필요한 자원 할당과 비용 효율성을 높이는 것이 중요합니다.

탄력적 설계는 클라우드 환경의 확장성을 최대한 활용하여 필요에 따라 자원을 신속하게 늘리거나 줄일 수 있는 유연성을 제공합니다.

지속적 최적화는 클라우드 운영의 핵심 요소로, 지속적인 모니터링과 분석을 통해 자원 사용 패턴을 파악하고 비효율적인 부분을 개선합니다.

이를 위해 자동화된 도구와 프로세스를 활용해 자원 사용량을 실시간으로 모니터링하고, 불필요한 비용을 절감하며, 데이터 기반 의사결정으로 자원 배분을 최적화합니다.

FinOps는 클라우드 자원 관리의 재무적 측면을 강조하며, 비용 관리와 예산 통제를 통해 비즈니스 목표를 달성합니다.

클라우드 비용을 투명하게 관리하고, 비용 대비 최대의 가치를 창출하여 자원을 효율적으로 활용하고 예산 내에서 운영하며 불필요한 지출을 최소화합니다.

이를 통해 조직의 재정 건전성을 유지하고, 클라우드 환경에서의 비용 관리와 재무적 책임을 강화합니다. (※ FinOps는 비용최적화 원칙에서 더 상세하게 다룹니다.)

이러한 접근법은 클라우드 자원을 효율적으로 관리하고 비용 효율성을 극대화하며 비즈니스 성과를 높이는 데 기여합니다.

클라우드 자원 관리

Samsung Cloud Platform을 비롯한 대부분의 클라우드 사업자는 자원에 대한 용량 제한을 설정하고 있습니다.

이러한 제한은 저장 용량, 생성 가능한 서비스 수 등 특정 자원의 사용 한도로 나타나며, 특정 고객이나 프로젝트가 자원을 독점하지 않도록 하기 위한 조치입니다.

클라우드 아키텍처를 설계할 때는 다음과 같은 사항을 고려하여 제한 용량을 점검해야 합니다.

• 프로젝트의 용량 요구사항을 사전에 파악하여 예기치 못한 자원 소비 제한을 방지합니다.

• 부하 급증 가능성을 고려해 자원 자동 확장 계획을 수립합니다.

• 제한 용량은 정기적으로 검토하여 최신 상태를 유지합니다.

Samsung Cloud Platform의 Console에서 서비스 제한을 확인할 수 있습니다(Console > Management > Quota Service).

일부 서비스는 제공 용량의 증가를 요청할 수 있습니다. 자원 배포 사전에 제한 용량을 검토하고, 용량 조정이 가능할 경우 미리 요청을 진행합니다.

평균 사용량 추이 분석 및 용량 조정

온프레미스 환경과는 달리, 클라우드 환경에서는 물리적 장비 및 시설의 관리를 클라우드 사업자가 직접 담당합니다.

이로 인해 사용자는 장비 구매 및 설치에 소요되는 시간을 줄이고, 서비스 구축과 활용에 집중할 수 있는 여건을 갖추게 됩니다.

클라우드를 활용하면 불필요한 유휴 자원을 사전에 준비하거나 유지할 필요가 없으며, 필요 시 가상 머신(VM)을 생성하거나 확장·축소하는 방식으로 유연하게 대응할 수 있습니다.

사용한 만큼만 비용을 지불하는 구조이기 때문에, 최대 트래픽 시간에 필요한 초과 용량만을 포함하여 비용을 최적화할 수 있습니다.

하지만 이러한 환경에서는 필요한 용량을 즉시 생성하여 사용할 수 있기 때문에, 자원 사용량을 효율적으로 관리하는 것이 매우 중요합니다.

이를 위해 평균 사용량 추이를 분석하는 절차가 반드시 수반되어야 합니다.

이러한 분석을 시작하려면, 먼저 주요 클라우드 워크로드를 식별해야 합니다.

워크로드의 평균 및 최대 사용률, 현재와 미래의 용량 요구사항을 평가하기 위해서, 해당 워크로드를 사용하는 부서의 업무 흐름과 계획 프로세스를 충분히 이해하고 있어야 합니다.

또한 과거의 부하 패턴을 분석하는 작업도 필요합니다.

예를 들어, 지난 3개월 간의 최고 사용량, 시간대별 최고 사용량, 분당 최고 사용량 등의 데이터를 활용하여 패턴을 도출할 수 있습니다.

Cloud Monitoring 도구를 활용하면 다음과 같은 부하 패턴을 분석할 수 있습니다.

• 평균 및 최대 사용률

• 사용 패턴의 급격한 변화

• (비즈니스 상황 변화로 인해) 특정 기간에 급증

부하 급증 이벤트가 사전에 계획되어 있는 경우, 트래픽 증가에 원활히 대응하기 위해 초과 프로비저닝을 미리 검토하는 것이 바람직합니다.

아울러 자원 사용량이 제한 용량에 근접할 경우, 운영자에게 자동으로 알림이 발송되도록 설정되어 있는지 확인하는 절차도 필요합니다

클라우드 자원 최적화

클라우드 자원 최적화는 운영 우수성을 위한 지속적인 습관이자 프로세스로, 비용 효율성을 높이고 서비스 성능을 유지하며 클라우드 환경의 장점을 최대한 활용할 수 있는 전략입니다.

이를 위해 컴퓨팅, 스토리지, 유휴 자원 관리, 그리고 비용 모델 최적화 등 다양한 측면에서 접근해야 합니다.

컴퓨팅 최적화는 단순히 평균 CPU 사용률에 의존하는 것이 아니라, 통계적으로 유의미한 지표를 활용해 워크로드 유형에 맞는 최적의 인스턴스 유형을 선택하는 과정입니다.

예를 들어, 지난 14일간 P95 CPU 사용률이 30% 미만과 같은 지표를 사용하여 불필요한 비용을 줄이고 자원을 효율적으로 활용합니다.

(※ P95 CPU 사용률은 CPU 성능 테스트나 모니터링에서 ‘95번째 백분위수(Percentile)‘를 의미하며, 이는 전체 CPU 사용량 데이터 중 가장 느린 5%의 성능을 나타내는 지표로, 시스템의 ‘최대 부하 시 안정성’을 측정합니다. CPU가 최대로 작동하는 상황(100% 사용률에 근접한 상태)에서 실제 사용자 응답 시간이나 시스템 부하가 어느 정도까지 올라가는지 보여주며, 80~90%대 P95는 일반적일 수 있지만, 100%에 가깝다면 병목 현상이나 과부하를 의미할 수 있습니다.)

유휴 자원 관리는 사용되지 않고 비용만 발생하는 자원을 식별하고 제거하는 과정입니다.

Unattached Disks/Volumes, Old Snapshots/Images 등을 정기적인 점검을 통해 삭제하는 정책을 수립하여 비용을 절감합니다.

마지막으로, 비용 모델 최적화는 기술적 최적화 이후에 재무적 최적화(FinOps)를 통해 청구서 자체를 할인받는 전략입니다.

필요시 즉시 사용, 약정 플랜, 대용량 자원 할인 등 다양한 구매 옵션을 조합하여 비용을 절감합니다.

이러한 전략들을 지속적으로 모니터링하고 개선함으로써 클라우드 자원 최적화를 통해 비용 효율성을 높이고, 서비스 성능을 유지하며 클라우드 환경의 장점을 최대한 활용할 수 있습니다.

자동화 프로세스 설계

IT 운영은 다양한 공급업체가 제공하는 하드웨어 및 소프트웨어의 빠른 기술 변화에 능동적으로 적응해야 하는 특성을 가지고 있습니다.

많은 조직이 하이브리드 클라우드 또는 멀티 클라우드 시스템을 구축하고 있으며, 온프레미스와 클라우드 환경을 동시에 운영하는 사례도 점차 늘고 있습니다.

최근 개발된 시스템에서는 Microservice 등의 기술이 함께 실행되며, 인터넷을 통해 수백만 개의 디바이스가 이들 서비스에 접속하는 구조가 일반화되고 있습니다.

이처럼 복잡한 환경에서는 IT 운영자가 여러 작업을 동시에 수행해야 하므로, 모든 작업을 수작업으로 처리하는 것은 현실적으로 어렵습니다.

서비스를 지속적으로 운영하고, 이벤트 발생 시 신속하게 복구하는 책임이 운영팀에 부여되어 있기 때문에, 사전에 준비된 대응 체계를 갖추는 것이 필수적입니다.

장애가 발생한 후에 대응하는 방식보다는, 장애 발생 가능성을 미리 예측하고 선제적으로 준비하는 접근이 더욱 효과적이라 할 수 있습니다.

안정적이고 신속한 운영을 위해서는 프로세스를 자동화하는 것이 바람직하며, 자동화 구현이 가능한 운영 영역은 다음 표를 통해 확인할 수 있습니다.

클라우드 기반 운영 효율성을 극대화하기 위해서는 인프라 수준에서는 컨테이너 기반 자동화를 구현하고, Application 수준에서는 코딩, 빌드, 통합, 릴리즈, 배포 단계의 파이프라인을 구성하는 것이 필요합니다.

이러한 자동화 구현을 촉진하는 대표적인 프로세스로는 DevOps가 있으며, 이는 개발팀과 운영팀 간의 협업을 통해 제품이나 서비스를 지속적으로 제공할 수 있도록 돕는 방법론입니다.

DevOps는 Application의 구축부터 배포까지 개발 수명 주기 전반에 걸쳐 개발팀과 운영팀이 협력하고 책임을 공유하며, 지속적인 피드백을 주고받는 구조를 지향합니다.

이러한 DevOps 환경에서는 다음과 같은 도구 및 자동화 요소들이 활용됩니다.

• 코드 기반 인프라 관리

• 중앙 집중형 코드 저장소

• CI/CD(지속적 통합 및 지속적 배포) 파이프라인

우선 코드 유형 인프라에 관해 살펴보겠습니다.

코드 유형 인프라 프로비저닝 및 관리

운영팀은 자동화 기술을 활용함으로써 업무 효율성을 크게 향상시킬 수 있습니다.

특히 코드 기반 인프라(Infrastructure as Code, IaC) 접근 방식을 활용하면, 새로운 서버 실행이나 서비스 시작·중지 작업을 자동화할 수 있으며, 반복적인 인프라 관리 업무를 줄이고 전략적 기획에 더 많은 시간을 투입할 수 있습니다.

IaC를 배포하고 관리할 때는 지시형 도구보다 선언형 도구가 운영 환경에 더 적합한 것으로 평가됩니다.

선언형 도구는 배포 완료 상태를 정의 파일에 명시하고, 해당 상태를 유지하려는 방식으로 작동합니다.

배포 중 실패가 발생하더라도 선언된 상태를 만들기 위해 반복적으로 작업을 수행하거나, 장애로 인해 변경이 발생한 경우에도 원래 상태로 복구하려는 동작이 자동으로 이루어집니다.

이러한 특성 덕분에 운영자의 개입이 줄어들고 안정적인 인프라 운영이 가능해집니다.

반면, 지시형 도구는 배포 작업을 단계별로 지시하는 방식이기 때문에, 실패나 변경 상황에 대해 운영자가 직접 개입해야 하는 경우가 많습니다.

Samsung Cloud Platform은 코드형 인프라 작업을 지원하며, CLI와 Open API를 제공합니다.

이를 활용하면 아래 그림과 같이 IaC 도구인 Terraform을 활용하여 자원 배치를 자동화할 수 있습니다.

Samsung Cloud Platform에서 Terraform 작업용 인증키를 생성하고 환경 설정을 완료한 뒤, 배포할 자원 및 환경 구성을 코드로 작성하여 Terraform 명령어로 kr-west1 Region과 kr-east1 Region에 VM을 배포합니다.

중앙 코드 저장소 구현

Samsung Cloud Platform의 DevOps Service에는 사용자가 소스 코드를 저장하고 형상 관리할 수 있는 도구를 내장하고 있습니다. 프로젝트별로 Private Git Repository를 구성하여 사용자별 접근 권한을 설정할 수 있으며, 이를 통해 소스 코드의 안전한 공유 및 개발 협업, CI/CD 환경 구성이 가능해집니다.

다음 그림은 DevOps Service를 이용한 Application 배포 자동화 아키텍처를 나타낸 것입니다.

사용자가 소스 코드를 Git에 Push하면 Jenkins 파이프라인이 트리거되어, 빌드된 Application 또는 컨테이너 오브젝트 구성 선언 파일이 Kubernetes Engine에 자동으로 배포됩니다.

중앙 저장소에 소스 코드뿐 아니라 인프라 구성 선언 파일을 함께 저장하고 운영 관리를 수행하면, 변경 사항을 통합 관리할 수 있으며, 버전 관리 기능을 통해 필요 시 이전 상태로 복구하는 것도 가능합니다.

지속적 통합 및 배포(CI/CD) 사용

지속적 통합(Continuous Integration, CI)을 통해 개발자는 코드 저장소에 자주 Commit하고, 자동으로 빌드 및 테스트를 수행합니다.

이 과정에서 단위 테스트와 통합 테스트가 자동으로 실행되며, 운영 환경에 배포하기 전 자동화 테스트와 수동 테스트를 모두 거칩니다.

모든 테스트를 통과한 경우에만 Staging 및 운영 환경으로의 배포가 허용됩니다.

지속적 통합은 소프트웨어 개발 수명 주기에서 빌드 및 단위 테스트 단계를 자동화하는 프로세스를 의미하며, 코드 저장소에 Commit된 모든 업데이트는 자동화된 빌드와 테스트를 생성합니다.

지속적 배포(Continuous Deployment, CD)는 지속적 통합 프로세스를 확장하여, 테스트를 통과한 빌드를 운영 환경에 자동으로 배포하는 절차를 포함합니다.

다음 그림은 Samsung Cloud Platform의 CI/CD 프로세스를 보여주고 있습니다.

실제 CI/CD에서는 여러 사람이 공동으로 코드를 작성하며, 모든 개발자가 최신 빌드를 기반으로 작업해야 합니다.

이를 위해 중앙 코드 저장소를 구성하여 여러 버전의 코드를 관리하고, 개발자들이 공동으로 접근해 작업할 수 있게 해야 합니다.

개발자는 이 저장소에서 코드를 체크아웃한 뒤 로컬 복사본에서 변경하거나 새로운 코드 작성하고, 테스트 후 다시 저장소에 Commit합니다.

지속적 통합(CI)은 소프트웨어 릴리스 과정의 대부분을 자동화하지만 운영 환경으로의 최종 배포는 개발자가 직접 트리거하는 방식이 일반적입니다. 지속적 배포(CD)는 빌드 단계 이후 모든 코드 변경 사항을 테스트 환경 또는 운영 환경에 자동으로 배포함으로써 지속적인 통합(CI)을 확장하는 개념입니다.

아래의 그림은 Samsung Cloud Platform에서 구현한 개발, 테스트, 운영 환경의 CI/CD 아키텍처를 나타냅니다.

1. DevOps Service 신청 후, 사용자 영역에 소스 코드 저장소 및 CI/CD 도구를 구성하고 DevOps Console과 연계합니다.

2. 개발자는 개발 소스 코드를 소스 코드 저장소의 개발자 branch에 Push합니다.

3. 개발 환경에 소스 코드를 배포하기 위해 개발자 branch를 Dev branch에 Pull 요청합니다.

4. 리뷰 단계를 거쳐 Dev branch에 병합(merge)합니다.

5. Dev branch 병합 이후 CI/CD 빌드 파이프라인이 실행되며, 소스 코드 체크 아웃 → 빌드 → 컨테이너 이미지 빌드 과정을 거칩니다.

6. 빌드된 컨테이너 이미지는 Container Registry에 저장됩니다.

7. 대상 클러스터(dev)의 컨테이너에 신규 버전 이미지가 배포됩니다.

8. 개발자는 frontend 컨테이너에 접근하여 배포 결과를 확인합니다.

9. Dev → Stage 확인 후 운영 릴리스를 위해 Production branch에 병합하고, Production 클러스터를 대상으로 4~8번의 절차를 반복합니다.

10. 블루-그린 배포 방식을 통해 릴리스를 수행하며, End User에게 서비스를 제공합니다.

클라우드 배포

클라우드 배포는 시스템 변경을 적용하는 핵심 과정으로, 장애 발생의 주요 원인 중 하나입니다.

운영 우수성은 이러한 장애 없는 배포를 어떻게 설계하고 실행 하느냐에 크게 좌우됩니다.

이를 위해 자동화, 모니터링, 롤백 기능 등 체계적인 전략과 도구가 필수적입니다.

지속적 통합(CI)과 지속적 배포(CD) 파이프라인을 구축함으로써 개발부터 배포까지의 과정을 효율적으로 관리하고, 변경 사항을 신속하고 안전하게 적용할 수 있습니다.

이는 시스템의 가용성과 신뢰성을 유지하는 데 중요한 역할을 합니다.

배포 전략으로는 블루-그린 배포와 카나리 배포 등이 널리 사용됩니다.

블루-그린 배포는 새로운 버전과 기존 버전을 동시에 운영하며, 문제가 발생하면 빠르게 이전 버전으로 전환할 수 있어 안정성이 높습니다.

카나리 배포는 소규모 사용자 그룹에 새로운 버전을 점진적으로 적용하여 문제를 조기에 발견하고 해결할 수 있는 장점이 있습니다.

이러한 전략들은 클라우드 환경의 탄력성과 확장성을 고려하여 설계되어야 합니다.

클라우드 환경에서는 리소스 할당, 부하 분산, 장애 복구 계획 등을 통해 시스템의 안정성을 보장해야 합니다.

또한, 보안과 규정 준수 요구사항을 충족하는 배포 프로세스를 마련하여 데이터 보호와 규제 준수를 확보해야 합니다.

이러한 요소들을 종합적으로 고려하여 클라우드 배포를 설계하고 실행함으로써 운영 효율성과 서비스 품질을 극대화할 수 있습니다.

인프라, Application 배포 전략 수립

인프라 및 Application 배포 자동화를 구성하고 난 후 배포 전략을 검토해야 합니다.

가장 많이 사용하는 배포 전략은 다음과 같습니다.

• 인플레이스 배포
  인플레이스 배포는 기존 서버 집합에 새로운 Application 버전을 직접 배포하는 방식입니다. 한 번의 배포 작업으로 업데이트가 이루어지기 때문에 일정 수준의 가동 중지 시간이 발생할 수 있습니다.
  하지만 인프라 변경이 거의 필요 없고, 기존 DNS 레코드를 수정할 필요가 없기 때문에 배포 프로세스 자체는 비교적 빠르게 진행됩니다.
  배포에 실패한 경우에는 재배포가 복원의 유일한 방법입니다.

• 롤링 배포
  롤링 배포는 서버 집합을 여러 그룹으로 나누어 순차적으로 업데이트를 진행하는 방식입니다.
  모든 서버를 동시에 업데이트할 필요가 없기 때문에, 배포 중에도 이전 버전과 새 버전이 공존할 수 있습니다.
  이로 인해 가동 중지 시간을 최소화할 수 있으며, 제로 다운타임을 달성하는 데 유리한 전략으로 평가됩니다.
  새 버전 배포가 실패하더라도 일부 서버만 영향을 받기 때문에 전체 서비스에는 큰 영향을 주지 않습니다.
  다만, 배포 시간은 인플레이스 방식보다 다소 길어질 수 있습니다.

• 블루-그린 배포
  블루-그린 배포 전략에서 ‘블루’는 실제 사용자 트래픽이 전달되는 기존 운영 환경을 의미하며, ‘그린’은 새 코드 버전이 적용된 병렬 환경을 의미합니다.
  배포할 때 사용자 트래픽을 블루 환경에서 그린 환경으로 전환하며, 그린 환경에 문제가 발생하면 트래픽을 다시 블루 환경으로 되돌려 롤백할 수 있습니다.
  DNS 컷오버와 Auto-Scaling 그룹 정책은 블루-그린 배포에서 트래픽을 전환하는 일반적인 방법으로 사용됩니다.
  Auto-Scaling 정책을 사용하면 Application 확장에 따라 기존 인스턴스를 새 버전 Application을 호스팅하는 VM으로 점진적으로 교체할 수 있습니다.
  이 방식은 마이너 릴리스와 소규모 코드 변경에 특히 적합합니다.
  또 다른 방법은 GSLB의 정책을 이용해 Application의 서로 다른 버전 간 전환을 수행하는 것입니다.
  아래 그림은 Application의 새 버전을 호스팅하는 환경을 만든 후 GSLB를 활용해 일부 트래픽을 새로운 환경으로 전환하는 아키텍처입니다.
  GSLB의 정책을 Ratio 알고리즘으로 구성하여 가중치 비율을 조절함으로써 블루 환경에서 그린 환경으로 점진적인 전환을 수행합니다.

• 레드-블랙 배포
  레드-블랙 배포는 블루-그린 배포와 유사하지만, DNS 전환 방식에서 차이가 있습니다.
  레드-블랙 배포는 점진적인 전환 없이 일시에 DNS를 변경하여 새로운 버전으로 전환합니다.
  이로 인해 블루-그린 배포에서는 이전 버전과 새 버전이 일정 기간 공존하지만, 레드-블랙 배포에서는 하나의 버전만 활성화됩니다. 빠른 전환이 필요한 경우에 적합한 전략입니다.

• 불변 배포
  불변 배포는 Application에 알려지지 않은 종속성이 존재하거나, 인프라가 복잡한 경우에 적합한 전략입니다.
  구축된 지 오래되었고 업데이트가 반복된 Application은 시간이 지날수록 업그레이드가 어려워집니다.
  불변 배포에서는 새로운 버전을 릴리스하는 동안 기존 VM을 종료하고, 새로운 VM을 배포합니다.

인프라 및 Application 배포 전략을 설계할 때는 가동 중지 시간뿐만 아니라 비용도 고려해야 합니다.

교체해야 할 VM 수와 배포 빈도를 바탕으로 비용을 산정하고, 예산과 가동 중지 시간을 종합적으로 고려해 가장 적합한 배포 방식을 선택해야 합니다.

고품질 배포를 위해서는 모든 단계에서 Application 테스트를 수행해야 하며, 이를 위해 상당한 노력이 요구됩니다.

앞서 살펴본 CI/CD 파이프라인은 테스트 프로세스를 자동화하고 기능 릴리스의 품질과 빈도를 높이는데 도움이 될 수 있습니다.

버전 관리 사용

인프라 및 Application 배포를 자동화하면 배포 속도와 빈도가 증가합니다.

이는 비즈니스 민첩성 측면에서는 바람직한 전개이지만, 운영팀에게는 배포를 관리하는데 더욱 세심한 작업이 요구됩니다.

장애나 손실 등의 문제, 또는 과거 배포본에 대한 이력 추적이 필요할 수 있으며, 이를 위한 관리 체계를 갖추는 것이 중요합니다.

버전 관리는 정상 상태나 이전 데이터로 복구할 수 있도록 하여, 손실 위험을 줄이는 데 기여합니다.

Samsung Cloud Platform에서는 다음과 같은 세 가지 수준에서 버전 관리를 구성할 수 있습니다.

• Object Storage에 기반한 데이터 버전 관리
  Samsung Cloud Platform의 Object Storage에서는 객체 저장에 버전 관리를 활성화할 수 있습니다.
  객체를 덮어쓰거나 삭제했을 때에도 변경 이전의 객체를 복원할 수 있습니다.
  Object Storage의 버전 관리는 데이터를 보존한다는 점에서는 백업이나 동기화와 유사하지만, 기존 데이터를 보존하는 방식에서는 차이가 있습니다.
  백업은 특정 시점의 데이터를 보존하고, 동기화는 모든 시점의 데이터 변경을 복제 대상에 반영하지만, 기존 데이터를 보존하지는 않습니다.
  Object Storage의 버전 관리는 HTTP Method 중 POST, PUT, DELETE 요청 수신으로 객체가 변경될 때마다 새 버전을 저장하는 것과 동시에 기존 버전을 보존합니다.

• Git에 기반한 소스 코드 버전 관리
  Git 도구를 통해 소스 코드의 형상 관리를 수행할 수 있습니다.
  소스 코드 저장, Commit 내역, 변경 사항, 히스토리 확인 및 변경 알림 등 모든 종류의 Git 명령어와 기능을 사용하여 개발 코드의 버전을 관리할 수 있습니다.
  개발자는 Git 도구에서 소스 코드를 가져와서 로컬 PC에서 작업을 수행하고, 작업이 완료되면 Repository에 Commit을 수행합니다.
  여러 개발자가 협업할 경우, 다음 그림과 같이 버전 관리를 통해 변경 사항을 추적할 수 있습니다.

• 서버 이미지 버전 관리
  Virtual Server의 이미지를 관리함으로써 서버 버전을 체계적으로 관리할 수 있습니다.
  이 이미지를 활용해 특정 시점의 Virtual Server를 새롭게 배포할 수 있으며, Launch Configuration에 등록해 Auto-Scaling 서버로 사용할 수도 있습니다.
  Kubernetes Engine에서 사용할 Container 이미지는 Container Registry에 저장되며, 해당 이미지는 내부에 pod를 배포할 때 사용됩니다.
  Application에 업데이트가 발생하면 새로운 버전으로 등록해 배포에 활용할 수 있습니다.
  기존 버전도 Registry에 저장하여 관리할 수 있으며, 필요할 경우 과거 버전의 이미지를 확인해서 복원하는 것도 가능합니다.

테스트 및 롤백 자동화

운영 최적화는 지속적으로 수행해야 하는 핵심 절차입니다.

변경 사항을 확인하고 개선하기 위해 지속적인 노력이 필요하며 이러한 점에서 운영 우수성을 달성한다는 것은 단기간에 달성되는 목표가 아니라 지속적인 여정이라고 할 수 있습니다.

워크로드를 유지 관리하는 데 있어서 변경은 불가피하며, 보안 패치 적용, 소프트웨어 업그레이드, 규정 준수 요구사항 반영 등 다양한 이유로 시스템 변경이 발생합니다.

모든 시스템 구성 요소를 정기적으로 업데이트할 수 있도록 워크로드를 설계해야만, 최신 상태를 유지하고 중요한 업데이트를 반영할 수 있습니다.

큰 영향을 피하려면 작은 변경 사항을 적용할 수 있도록 절차를 자동화해야 합니다.

모든 변경 사항은 되돌릴 수 있어야 하며, 이를 통해 문제가 발생하더라도 시스템을 복원할 수 있습니다.

이처럼 작은 단위의 변경을 적용하면 테스트가 용이해지고, 전반적인 시스템 안정성 향상에 도움이 됩니다.

또한 변경 관리를 자동화하여 인적 오류를 줄이고, 운영 우수성을 달성해야 합니다.

다음 그림은 Application의 새 버전을 테스트하기 위한 환경 구성 예시로, 두 가지 이상의 기능 버전을 서로 다른 사용자 집단에 제공하는 A/B 테스트를 구현한 사례입니다.

GSLB에 Ratio 알고리즘을 설정하여 기존 Application(v1)에 전체 요청의 90%를 보내고, 새로 개발한 v2와 v3에는 각각 5%씩 분산시켜 사용자 테스트를 수행할 수 있습니다.

이를 통해 Application과 서버 인프라의 안정성을 검증할 수 있습니다.

본격적인 배포 시에도 동일한 방식을 사용할 수 있습니다.

블루-그린 배포 전략을 선택하여 사용자 요청의 일부를 그린 환경으로 보내서 영향을 테스트할 수 있는데, 이를 카나리(Canary) 분석이라고 합니다.

새로운 버전(v2)에 문제가 있는 경우, 사용자에게 심각한 영향을 미치기 전에 즉시 공지하고 트래픽을 기존 버전(v1)으로 전환할 수 있습니다.

트래픽을 점진적으로 늘려가면서 부하를 처리할 수 있는지 그린 환경을 테스트합니다.

그린 환경을 모니터링하여 문제를 감지하고 트래픽을 다시 변경할 수 있는 기회를 제공함으로써 폭발 반경을 제한합니다.

모든 지표가 정상일 경우, 블루 환경(v1)을 종료하고 자원을 해제합니다.

블루-그린 배포는 가동 중지 시간을 0으로 하고, 손쉬운 롤백을 제공하며, 필요에 따라 사용자가 배포 시간을 지정할 수도 있습니다.

클라우드 모니터링 및 로그 분석

클라우드 모니터링 및 로그 분석은 시스템의 상태를 이해하고 문제를 해결하는 데 필수적인 도구입니다.

전통적인 모니터링은 단순히 무엇이 고장 났는지(예: CPU 100% 사용) 알려주는 반면, 현대 클라우드의 관측 가능성(Observability)은 심층적인 데이터를 제공하여 장애의 원인에 대한 디버깅을 수행할 수 있습니다.

이를 통해 시스템의 복잡성을 이해하고, 근본 원인을 파악하여 신속하고 정확한 대응이 가능합니다.

모니터링과 로그 분석은 클라우드 운영의 효율성, 안정성, 보안을 강화하는 데 기여합니다.

자원 사용 패턴을 분석하여 비용을 최적화하고, 성능 병목 현상을 제거하며, 보안 위협을 조기에 식별할 수 있습니다.

또한, 자동화 도구와 AI를 활용해 실시간 로그 수집 및 분석을 수행하면 운영 최적화를 더욱 빠르고 정확하게 달성할 수 있습니다.

이러한 접근 방식은 클라우드 환경의 동적이고 복잡한 특성을 효과적으로 관리하며, 비즈니스 연속성과 혁신을 지원합니다.

모니터링 및 알림 구성

운영 우수성은 모니터링을 통해 장애 발생 시 신속하게 대응하고 복구할 수 있는 역량에 의해 결정됩니다.

이를 위해서는 이벤트와 그에 따른 대응이 워크로드에 미치는 영향을 파악하여 워크로드의 운영 상태를 이해하고, 이벤트 지표와 대시보드를 사용해 시스템의 운영 상태를 파악하는 것이 중요합니다.

Samsung Cloud Platform의 Cloud Monitoring 서비스는 운영 중인 인프라 자원의 사용 현황, 변경 정보, 로그 등을 수집하며, 설정된 임계치를 초과하면 이벤트를 발생시켜 알림으로 통보합니다.

이러한 기능을 통해 사용자는 성능 저하나 장애 상황에 신속하게 대응할 수 있으며, 자원 용량 확대가 필요한 시점을 예측하여 안정적인 컴퓨팅 환경을 유지할 수 있습니다.

Cloud Monitoring이 제공하는 계측 기능은 크게 두 가지로, 성능 데이터 수집 및 이벤트 처리와 로그 데이터 수집 및 이벤트 처리로 구분됩니다.

시스템 상태를 추적하는 것은 워크로드 동작을 이해하는 데 필수적 요소입니다.

운영팀은 시스템 상태 모니터링을 활용하여 구성 요소의 이상을 감지하고, 그에 따라 조치를 수행합니다.

일반적으로 모니터링은 서버의 CPU와 메모리 사용률 추적 등 인프라 계층으로만 국한된다고 생각하기 쉽지만, 실제로는 Application, 네트워크, 데이터베이스 등 아키텍처의 모든 계층에 모니터링이 적용되어야 합니다.

다음 표는 Cloud Monitoring을 연결하여 모니터링을 구성할 있는 서비스 목록입니다.

Samsung Cloud Platform의 Cloud Monitoring에서 알림을 구성하려면 이벤트를 정의해야 합니다.

이벤트란 모니터링 대상의 성능 값이 사전에 지정한 임계치에 이르렀을 때 그것을 사용자에게 알리기 위한 설정입니다.

이벤트 설정 시 모니터링 대상, 성능 항목, 측정 유형/단위, 위험도, 임계치를 지정합니다.

그리고 알림을 수신할 대상을 지정하여 알림을 발송할 수 있습니다.

로그 기록 및 수집

로그 수집 및 분석은 문제 발생 시 사후 대응을 위한 목적으로 수행됩니다.

이는 문제 원인을 분석하는 접근법이 문제 해결의 실마리를 가장 신속하게 제공하기 때문입니다.

문제를 올바르게 식별할 수 있다면 효율적인 해결책을 찾아내고 적용할 수 있습니다.

Samsung Cloud Platform은 로그 수집용으로 1GB의 저장 공간을 제공하며, 이를 초과하면 오래된 로그부터 자동으로 삭제됩니다.

Cloud Monitoring에서 로그 수집을 설정하려면 수집 대상에 로그 에이전트가 설치되어 있어야 합니다.

Network Logging은 Firewall, Security Group, NAT에서 로그를 수집해 Object Storage에 저장하며, 이를 통해 VPC 내부와 외부를 오가는 트래픽을 분석할 수 있습니다.

Cloud Monitoring과 Network Logging이 시스템과 관련된 활동 기록이라면, Logging&Audit은 클라우드 및 사용자의 활동 기록입니다.

예를 들어, 사용자가 Console에 로그인하여 Virtual Server를 생성하였다면, 이러한 활동은 Logging&Audit에 기록됩니다.

Trail을 구성하면 이러한 로그를 기간 제약 없이 장기 보존할 수 있습니다.

다양한 자원에서 데이터를 수집하여 의사 결정을 내리고, 잠재적인 문제를 예측하는 과정은 운영의 필수 조건은 아니지만, 운영 품질을 높이는 데 결정적으로 기여합니다.

이는 향후 발생 가능한 장애를 사전에 예측하고, 팀이 적절한 대응을 할 수 있게 준비하는데 도움이 됩니다.

작업 이벤트와 워크로드 전반에 걸친 다양한 활동, 인프라 변경에 대한 로그를 수집하는 메커니즘을 구현해 상세한 활동 추적을 만들고, 감사 목적으로 활동 기록을 유지해야 합니다.

대규모 조직에서는 다수의 시스템에서 많은 양의 로그 데이터가 생성되고 있는데, 이 데이터에서 인사이트를 얻으려면 일정 기간 동안의 로그와 이벤트 데이터를 수집하고 저장하는 메커니즘이 필요합니다.

로그 분석 및 개선 활동

Samsung Cloud Platform의 도구와 솔루션을 이용하여 구축한 모니터링 로그를 분석함으로써 개선을 추진할 수 있습니다.

정기적인 로그 분석을 통해 클라우드 운영의 효율성을 높이고, 비용을 최적화하며, 보안을 강화할 수 있습니다.

클라우드 환경에서는 다양한 자원이 동적으로 생성되고 삭제되며, 이에 따라 대량의 로그 데이터가 생성되는데, 이러한 로그 데이터를 효과적으로 분석하면 잠재적 문제를 조기에 발견해서 운영을 최적화할 수 있는 개선점들을 도출할 수 있습니다.

우선, 클라우드 로그 분석을 통해 자원 사용 패턴을 파악함으로써 비용을 최적화할 수 있습니다.

예를 들어, 사용하지 않는 자원이 활성화된 상태로 유지되거나 예상치 못한 트래픽 증가로 인해 비용이 급증하는 데이터가 발견된 경우, 해당 데이터를 기반으로 Auto-Scaling 정책을 재설정하거나 약정 요금을 통해 비용을 절감할 수 있습니다.

다음으로, 성능 개선에도 활용할 수 있습니다.

클라우드 환경에서의 로그 분석은 시스템 성능을 모니터링하고 최적화하는 데 중요한 역할을 합니다.

로그 데이터를 분석하여 Application의 응답 시간, 데이터베이스 쿼리 속도, 네트워크 대역폭 사용량 등을 파악할 수 있으며, 이를 통해 성능 저하가 발생하는 구간을 찾아내어 병목 현상을 제거하거나 자원 배포를 최적화함으로써 시스템 전체의 성능을 향상시킬 수 있습니다.

로그 분석은 보안 위협을 식별하고 대응하는 데에도 필수적입니다.

Trail 로그에는 사용자 액세스와 작업 기록이 포함되어 있으며, VPC 로그 분석을 통해 비정상적인 네트워크 활동을 찾아낼 수 있습니다.

로그 데이터를 지속적으로 분석하면 비정상적인 로그인 시도, 데이터 유출 시도, 악성 활동 등을 빠르게 감지할 수 있는데, 이상 징후를 조기에 발견하여 적절한 대응 조치를 취함으로써 보안 위협을 최소화할 수 있습니다.

단기적인 로그 분석은 기존에 제공되고 있는 도구로 수행할 수 있지만 더 나은 인사이트를 얻기 위해서는 전문 로그 분석 도구나 인공지능을 활용할 수 있습니다.

로그 분석을 자동화 도구와 인공지능(AI)을 활용해 수행하면 운영 최적화를 더욱 빠르고 정확하게 달성할 수 있습니다.

이러한 로그 분석 도구를 활용하면 실시간 로그 수집 및 분석이 가능하며, 문제 발생 시 즉시 알림을 제공하거나 자동으로 수정 작업을 수행할 수 있습니다.

이벤트 대응

이벤트 등급 정의

업무 영향도는 업무 구조화, 주요 업무 식별, 업무 연관성 분석을 통해 평가되며(자세한 내용은 안정성 설계 원칙 참조), 이를 바탕으로 식별된 주요 시스템을 대상으로 이벤트의 중요도를 정의할 수 있습니다.

Cloud Monitoring에서는 이벤트를 설정하고, 이를 위험도로 분류할 수 있습니다.

위험도는 가장 높은 수준인 Fatal, 중간 수준인 Warning, 가장 낮은 수준인 Information으로 지정할 수 있으며, 각 위험도에 따라 이벤트 발생 빈도를 시각화할 수 있습니다.

이벤트 설정을 통해 반드시 확인해야 할 모니터링 정보를 놓치지 않고 파악할 수 있습니다.

예를 들어, 과부하와 관련된 성능 값이 일정한 수치를 초과할 때마다 이벤트가 발생하도록 설정하면, 해당 자원 운영 중 과부하 위험이 있을 때마다 사용자에게 알림이 전달됩니다.

운영자는 이를 토대로 문제가 발생하기 전에 미리 대응할 수 있습니다.

이벤트 관리 프로세스

장애가 발생하거나 실제 장애로 이어지지 않더라도 그에 준하는 긴급(Fatal) 이벤트가 발생하면 신속하게 조치를 수행해야 합니다.

이를 위해 이벤트 관리 프로세스가 사전에 정의되어야 하며, 이를 통해 문제를 신속하게 파악하고 적절한 대응 조치를 취할 수 있습니다.

다음 그림은 안정성 설계 원칙에서 설명한 장애 관리 프로세스의 예시입니다.

이벤트 대응 자동화

신속한 이벤트 대응을 위해 사전 정의된 프로세스를 기반으로 대응 조치를 수행하고, 이벤트 대응 자동화를 구성하면 장애 식별부터 대응까지 소요되는 시간을 줄일 수 있습니다.

예를 들어, 아래 그림과 같이 외부 공격자에 의해 서버에 DDoS 공격이 시작되었다고 가정해보면, DDoS 공격의 목표는 과도한 트래픽을 서버에 발생시켜 정상적인 사용자가 서비스를 사용하지 못하게 하는 서버 불능화입니다.

이러한 경우 가장 바람직한 방법은 DDoS Protection을 구성하여 공격을 탐지하고 방어하는 것입니다.

이러한 공격에 대응하기 위한 아키텍처 접근은 Virtual Server에 Auto-Scaling을 구성하여 부하에 따라 서버의 수를 증가시키는 정책을 구성하는 것입니다.

이를 통해 정상 사용자의 서비스 사용이 완전히 차단되지 않도록 자동화된 대응을 구현합니다.

또한 Cloud Monitoring에서 Network In 또는 CPU 사용량 등의 임계치 설정과 알림을 구성하여 관리자에게 알림이 발송되도록 합니다.

관리자가 공격을 통지받고 조치하는 동안 Auto-Scaling의 자동화 조치로 서비스 생존을 확보하고, 관리자는 신속하게 공격자 IP를 파악하여 Firewall에 해당 IP 주소에 대한 거부 정책을 구성함으로써 서비스를 보호할 수 있습니다.