Google Cloud로 마이그레이션: 환경 최적화

Last reviewed 2023-12-07 UTC

이 문서는 Google Cloud로 마이그레이션하기 위한 최적화 단계를 계획 및 설계하는 데 유용합니다. Google Cloud에 워크로드를 배포한 후 환경 최적화를 시작할 수 있습니다.

이 문서는 Google Cloud로 마이그레이션에 대해 여러 편으로 구성된 다음 시리즈 중 일부입니다.

다음 다이어그램은 마이그레이션 과정을 보여줍니다.

4가지 단계로 구성된 마이그레이션 경로

최적화 단계에서는 초기 배포보다 더 효율적인 환경으로 개선할 수 있습니다.

이 문서는 Google Cloud로 마이그레이션한 기존 환경의 최적화를 계획 중이거나, 최적화 기회를 살펴보고 최적화 과정을 미리 알아보고자 할 때 유용합니다.

최적화 단계는 이 시리즈에 설명된 마이그레이션 프레임워크에 따라 평가, 계획, 배포, 최적화로 구성됩니다. 이 다목적 프레임워크를 사용하여 전체 마이그레이션을 계획하고 각 단계의 독립적인 작업을 세분화할 수 있습니다. 최적화 단계의 마지막 단계가 완료되면 이 단계를 다시 시작하여 새로운 최적화 대상을 찾을 수 있습니다. 최적화 단계는 최적화 루프로 정의되고 루프 실행은 최적화 반복으로 정의됩니다.

최적화는 지속적인 작업입니다. 환경의 발전에 따라 지속적으로 환경을 최적화합니다. 통제 불가능한 중복 작업을 피하기 위해 측정 가능한 최적화 목표를 설정한 후 목표가 달성되면 최적화를 중단할 수 있어야 합니다. 그런 다음 보다 과감한 새로운 목표를 설정할 수 있지만 최적화에는 시간, 노력, 기술력 등 리소스 측면의 비용이 발생한다는 점을 고려하세요.

다음 다이어그램은 최적화 루프를 보여줍니다.

최적화 결정 트리 이 다이어그램의 더 큰 이미지는 최적화 결정 트리를 참조하세요.

이 문서에서는 다음과 같이 반복 가능한 최적화 루프 단계를 수행합니다.

  1. 현재 환경, 팀, 최적화 루프를 평가합니다.
  2. 최적화 요구사항 및 목표를 설정합니다.
  3. 환경을 최적화하고 팀 교육을 실시합니다.
  4. 최적화 루프를 조정합니다.

이 문서에서는 사이트 안정성 엔지니어링(SRE)의 규율과 개념을 설명합니다. Google은 수십억 명의 사용자를 지원하는 글로벌 인프라를 효율적이고 안정적으로 운영하기 위해 SRE 규율을 개발했습니다. 다수의 비즈니스 및 공동작업 프로세스를 수정해야 하는 경우 조직에 완전한 SRE 규칙을 도입하는 것이 비현실적일 수 있습니다. 조직에 가장 적합한 일부 하위 집합의 SRE 규율을 적용하는 것이 더 간단할 수 있습니다.

환경, 팀, 최적화 루프 평가

최적화 작업을 시작하기 전에 환경을 평가해야 합니다. 또한 환경을 최적화하려면 팀이 보유하지 않은 기술이 필요할 수 있으므로 팀의 기술력도 평가해야 합니다. 마지막으로 최적화 루프를 평가해야 합니다. 루프는 다른 리소스와 마찬가지로 최적화할 수 있는 리소스입니다.

환경 평가

현재 환경을 상세하게 파악하세요. 최적화를 성공적으로 수행하려면 환경의 작동 방식을 이해하고 개선이 필요한 부분을 파악해야 합니다. 이 평가는 최적화 단계와 다음 최적화 반복을 비교 평가할 수 있는 기준을 설정합니다.

Google Cloud로 마이그레이션: 워크로드 평가 및 탐색에는 워크로드 및 환경 평가에 대한 광범위한 안내가 포함되어 있습니다. 최근 Google Cloud로 마이그레이션을 완료했다면 환경 구성, 관리, 유지보수에 대한 세부정보가 이미 있을 것입니다. 그렇지 않으면 가이드에 따라 환경을 평가하세요.

팀 평가

환경을 명확하게 이해했다면 팀이 현재 보유한 기술을 평가하세요. 먼저 보유한 모든 기술, 각 기술에 대한 전문성 수준, 각 기술에 대해 경험과 지식이 가장 풍부한 팀원을 나열합니다. 다음 단계에서 이 평가를 통해 최적화 목표를 달성하는 데 필요한 기술 중 누락된 것이 있는지 살펴보세요. 예를 들어 관리형 서비스를 사용하려면 이 서비스를 프로비저닝, 구성, 상호작용할 수 있는 기술이 필요합니다. Memorystore를 사용하여 현재 환경의 애플리케이션에 캐싱 레이어를 추가하려면 이 서비스를 사용하기 위한 전문 지식이 필요합니다.

환경을 최적화하면 비즈니스 및 공동작업 프로세스에 영향을 줄 수 있다는 점을 고려하세요. 예를 들어 자체 관리형 서비스 대신 완전 관리형 서비스를 사용하면 작업자의 수작업 부담을 해소하므로 시간을 효과적으로 활용할 수 있습니다.

최적화 루프 평가

최적화 루프도 최적화할 수 있는 리소스입니다. 이 평가에서 수집된 데이터를 사용하면 마지막 최적화 반복 중에 팀의 작업 수행 방식에 대한 명확한 통계를 얻을 수 있습니다. 예를 들어 반복 기간을 줄이려면 복잡성과 추구하는 목표를 포함하여 마지막 반복에 대한 데이터가 필요합니다. 또한 마지막 반복 중에 발생한 모든 장애에 대한 정보가 있어야 장애가 다시 발생할 경우 완화 전략을 적용할 수 있습니다.

이 최적화 반복이 첫 번째 반복인 경우 수행 능력을 비교할 기준을 설정하기에 데이터가 부족할 수 있습니다. 첫 번째 반복 중에 팀의 예상 수행 능력에 대한 가설을 작성합니다. 첫 번째 최적화 반복 후에 루프와 팀의 수행 능력을 평가하고 가설과 비교합니다.

최적화 요구사항 및 목표 설정

최적화 작업을 시작하기 전에 반복을 위해 명확하게 측정할 수 있는 목표를 여러 개 작성하세요.

이 단계에서는 다음 활동을 수행합니다.

  1. 최적화 요구사항을 정의합니다.
  2. 최적화 요구사항에 따라 측정 가능한 최적화 목표를 설정합니다.

최적화 요구사항 정의

최적화 단계의 요구사항을 나열합니다. 개선이 필요하다는 요구사항을 표시해야 하지만 반드시 측정 가능할 필요는 없습니다.

워크로드, 환경, 자체 최적화 루프에 관한 일련의 품질 특성부터는 설문을 작성하여 요구사항을 설정하는 방법을 안내할 수 있습니다. 설문에서는 현재 환경, 프로세스, 워크로드에 중요한 특성을 다룹니다.

품질 특성을 정의하는 데 도움이 되는 다양한 소스가 있습니다. 예를 들어 ISO/IEC 25010 표준에서 소프트웨어 제품의 품질 특성을 정의하거나 개발자가 Google Cloud 설정 체크리스트를 검토할 수 있습니다.

예를 들어 설문을 통해 다음과 같은 질문을 물어보세요.

  • 인프라와 그 구성요소를 수직 또는 수평으로 확장할 수 있나요?
  • 인프라가 수동 개입 없이 변경사항 롤백을 지원하나요?
  • 인프라 및 워크로드를 처리하는 모니터링 시스템이 이미 있나요?
  • 인프라에 사고 관리 시스템이 있나요?
  • 계획한 최적화를 구현하는 데 시간과 노력이 얼마나 필요한가요?
  • 이전 반복에서 모든 목표를 달성할 수 있었나요?

설문에 답변하는 것부터 시작하면 이 최적화 반복의 요구사항 목록을 작성해 볼 수 있습니다. 다음과 같은 요구사항이 있을 수 있습니다.

  • 애플리케이션의 성능을 높입니다.
  • 환경 구성요소의 가용성을 높입니다.
  • 환경 구성요소의 안정성을 높입니다.
  • 환경의 운영 비용을 줄입니다.
  • 최적화 반복 기간을 단축하여 내재된 위험을 줄입니다.
  • 개발을 가속화하고 TTM(time to market)을 앞당깁니다.

개선이 필요한 부분을 파악한 후 목록에 포함된 요구사항을 평가합니다. 이 평가에서는 최적화 요구사항을 분석하고, 충돌 요소를 찾고, 목록에서 요구사항의 우선순위를 지정합니다. 예를 들어 애플리케이션 성능 향상에 대한 요구사항은 운영 비용 절감과 충돌할 수 있습니다.

측정 가능한 목표 설정

요구사항 목록을 작성했으면 각 요구사항에 대해 측정 가능한 목표를 정의합니다. 하나의 목표를 둘 이상의 요구사항에 반영할 수 있습니다. 불확실한 부분이 있거나 요구사항을 지원하는 데 필요한 목표를 모두 정의할 수 없으면 이 반복의 평가 단계로 돌아가 누락된 정보를 수집한 다음 요구사항을 구체화하세요.

이러한 목표를 정의하는 데 도움이 필요하면 SRE 규율, 서비스 수준 지표(SLI) 정의, 서비스 수준 목표(SLO) 정의 중 하나를 따르세요.

  • SLI는 제공되는 서비스 수준을 양적으로 측정하는 기준입니다. 예를 들어 주요 SLI에는 평균 요청 지연 시간, 오류율, 시스템 처리량 등이 있습니다.
  • SLO는 SLI에서 측정되는 서비스 수준의 목표 값 또는 값 범위입니다. 예를 들어 SLO 측면에서 평균 요청 지연 시간은 100밀리초 미만일 수 있습니다.

SLI 및 SLO를 정의한 후 SLI를 측정하는 데 필요한 모든 측정항목을 수집하지 않았다는 것을 인식할 수 있습니다. 이 경우 측정항목 수집이 가장 먼저 해결해야 할 최적화 목표가 됩니다. SLI에 필요한 모든 측정항목을 수집하기 위해 모니터링 시스템을 확장하는 것과 관련된 목표를 설정합니다.

환경 및 팀 최적화

환경, 팀, 최적화 루프를 평가하고 이 반복의 요구사항을 설정했으면 이제 최적화 단계를 수행할 수 있습니다.

이 단계에서는 다음 활동을 수행합니다.

  1. 환경, 팀, 최적화 루프를 측정합니다.
  2. 이러한 측정에 따른 데이터를 분석합니다.
  3. 최적화 활동을 수행합니다.
  4. 다시 측정하고 분석합니다.

환경, 팀, 최적화 루프 측정

모니터링 시스템을 확장하여 환경, 팀, 최적화 루프의 동작에 대한 데이터를 수집한 후 최적화 후 비교할 기준을 설정합니다.

이 활동은 평가 단계에서 수행한 작업을 바탕으로 하며, 이 작업을 확장합니다. 요구사항 및 목표를 설정하면 측정값과 최적화 목표의 관련성이 유지되도록 수집할 측정항목을 알 수 있습니다. 예를 들어 현재 환경의 워크로드 중 하나의 응답 지연 시간을 줄이도록 SLO와 관련 SLI를 정의한 경우에는 해당 측정항목을 측정할 데이터를 수집해야 합니다.

이러한 측정항목을 이해하면 팀과 최적화 루프에도 적용할 수 있습니다. 모니터링 시스템을 확장하여 데이터를 수집하면 팀과 최적화 루프와 관련된 측정항목을 측정할 수 있습니다. 예를 들어 최적화 반복의 기간을 줄이도록 SLO와 관련 SLI를 정의한 경우에는 해당 측정항목을 측정할 데이터를 수집해야 합니다

모니터링 시스템을 확장하는 데 필요한 측정항목을 설계할 때 데이터 수집이 환경 및 프로세스의 성능에 영향을 미칠 수 있다는 점을 고려하세요. 측정을 위해 구현해야 하는 측정항목과 샘플 간격을 평가하여 성능에 영향을 미칠 수 있는지 확인합니다. 예를 들어 샘플링 빈도가 높은 측정항목은 성능을 저하시킬 수 있으므로 추가로 최적화해야 합니다.

Google Cloud에서 Cloud Monitoring을 사용하여 데이터를 수집하는 데 필요한 측정항목을 구현할 수 있습니다. 워크로드에 직접 커스텀 측정항목을 구현하려면 Cloud Monitoring용 Cloud 클라이언트 라이브러리 또는 OpenTelemetry를 사용하면 됩니다. Google Kubernetes Engine(GKE)을 사용하는 경우 GKE 사용량 측정을 사용하여 CPU, GPU, TPU 사용량과 같은 리소스 사용량에 대한 정보를 수집한 후 리소스 사용량을 네임스페이스 또는 라벨을 기준으로 분류합니다.

마지막으로 Cloud 아키텍처 센터 및 Google Cloud 백서를 참조하여 팀에서 환경을 최적화하는 데 필요한 새로운 기술을 찾아볼 수 있습니다.

데이터 분석

데이터를 수집한 후, 수집된 데이터를 분석 및 평가하여 환경, 팀, 최적화 루프의 수행 능력을 최적화 요구사항 및 목표와 비교하여 파악합니다.

특히 다음을 기준으로 환경을 평가합니다.

  • SLO
  • 업계 권장사항
  • 기술적 채무가 없는 환경

최적화 목표에 따라 설정한 SLO는 기대에 부합하는지 여부를 파악하는 데 도움이 됩니다. SLO를 충족하지 않을 경우 팀 또는 최적화 루프를 개선해야 합니다. 예를 들어 지정된 백분위수로 표시되는 워크로드의 응답 지연 시간에 대한 SLO를 설정했지만 이 워크로드가 해당 표시에 부합하지 않는 경우 이는 워크로드의 해당 부분을 최적화해야 한다는 신호입니다.

또한 현재 상황을 업계에서 인정된 권장사항과 비교할 수 있습니다. 예를 들어 Google Cloud 설정 체크리스트를 사용하면 엔터프라이즈 워크로드의 프로덕션에 즉시 사용 가능한 환경을 구성할 수 있습니다. GKE를 사용하는 경우 컨테이너 작업을 위한 권장사항을 따르고 있는지 여부를 확인할 수 있습니다.

데이터를 수집한 후 비용 측면에서 더 효율적인 환경으로 최적화하는 방법을 고려하세요. Cloud Billing 데이터를 BigQuery로 내보내고 Looker Studio로 데이터를 분석하여 사용 중인 리소스 수를 파악하고 지출 패턴을 추출할 수 있습니다.

마지막으로 현재 환경을 기술적 채무가 없는 환경과 비교하여 장기 목표를 충족하는지와 기술적 채무가 증가하는지 여부를 확인합니다. 예를 들어 모니터링 대상 환경의 리소스 수와 마지막 반복 이후 프로비저닝한 리소스 수를 비교하는 SLO를 설정할 수 있습니다. 모니터링 시스템을 확장하여 이러한 새로운 리소스를 포괄하지 않으면 기술적 채무가 증가합니다. 기술적 채무의 변화를 분석할 때 이러한 변화를 유발한 요인도 고려하세요. 예를 들어 비즈니스 요구에 따라 기술적 채무가 증가했거나 예기치 않은 문제가 발생했을 수 있습니다. 기술적 채무의 변경을 유발한 요인을 파악하면 향후 최적화 목표에 대한 통계를 얻을 수 있습니다.

Google Cloud에서 환경을 모니터링하기 위해 Monitoring을 사용하여 차트, 대시보드, 알림을 설계할 수 있습니다. 그런 다음 심층 분석과 보관 기간 연장을 위해 Cloud Logging 데이터를 라우팅할 수 있습니다. 예를 들어 집계 싱크를 만들고 Cloud Storage, Pub/Sub 또는 BigQuery를 대상으로 사용할 수 있습니다. 데이터를 BigQuery로 내보내면 Looker Studio를 사용하여 데이터를 시각화하여 트렌드를 파악하고 데이터를 바탕으로 예측할 수 있습니다. 또한 Recommender, Security Command Center와 같은 평가 도구를 사용하여 환경과 프로세스를 자동으로 분석하고 최적화 대상을 찾을 수 있습니다.

모든 측정 데이터를 분석한 후 다음 두 가지 질문에 답해야 합니다.

  1. 최적화 목표에 부응하고 있나요?

    이 질문에 대한 답이 예라면 이 최적화 반복이 완료되고 새 반복을 시작할 수 있습니다. 아니요라고 답했다면 두 번째 질문으로 이동하세요.

  2. 예산에서 정한 리소스를 고려할 때 이 반복에 대해 설정한 최적화 목표를 달성할 수 있나요?

이 질문에 답하려면 시간, 비용, 전문 지식 등 필요한 모든 리소스를 고려하세요. 이 질문에 대한 답이 예라면 다음 섹션으로 이동하세요. 그렇지 않으면 이 반복에 사용할 수 있는 리소스를 고려하여 최적화 목표를 구체화하세요. 예를 들어 고정된 일정의 제한을 받는 경우 다음 반복을 위해 일부 최적화 목표를 예약해야 할 수 있습니다.

팀 최적화

환경을 최적화하는 것은 지속적인 도전과제로, 평가 및 분석 중에 발견했지만 팀이 보유하지 않은 기술이 필요할 수 있습니다. 따라서 최적화 활동을 성공적으로 실현하려면 새로운 기술을 획득하고 프로세스를 보다 효율적으로 개선하여 팀을 최적화하는 것이 중요합니다.

팀을 최적화하려면 다음을 수행해야 합니다.

  • 교육 프로그램을 설계하고 구현합니다.
  • 팀 구조와 문화를 최적화합니다.

팀이 보유하고 있지 않은 기술을 획득하려면 교육 프로그램을 설계 및 구현하거나 Google Cloud 전문 트레이너가 준비한 프로그램을 선택해야 합니다. 자세한 내용은 Google Cloud로 마이그레이션: 워크로드 평가 및 탐색을 참조하세요.

팀을 최적화하는 동안 팀의 구조와 문화를 개선할 여지가 있는지 파악할 수 있습니다. 회사마다 팀의 구조와 문화 발전에 기여한 고유한 역사와 특이성이 있으므로 이상적인 상황을 사전에 규정하기가 어렵습니다.

DevOps 관행 도입을 목표로 조직 변경사항을 실행하고 측정하기 위한 일반 프레임워크를 알아보려면 혁신적 리더십부터 시작하는 것이 좋습니다. 조직에 DevOps 문화를 효과적으로 구현하는 방법에 대한 실질적인 안내는 SRE 방법론을 포괄적으로 설명하는 사이트 안정성 엔지니어링을 참조하세요. 함께 제공되는 책자인 사이트 안정성 워크북에서는 구체적인 예시를 사용하여 SRE 원칙과 관행을 적용하는 방법을 보여줍니다.

환경 최적화

측정항목 데이터를 측정하고 분석한 후에는 최적화가 필요한 영역을 알 수 있습니다.

이 섹션에서는 Google Cloud 환경에 적용할 일반적인 최적화 기술을 설명합니다. 또한 인프라와 사용 중인 서비스와 관련된 모든 최적화 활동을 수행할 수 있습니다.

모든 항목 코드화

Google Cloud와 같은 퍼블릭 클라우드 도입을 통해 얻을 수 있는 가장 큰 장점 중 하나는 Cloud APIs와 같이 잘 정의된 인터페이스를 사용하여 리소스를 프로비저닝, 구성, 관리할 수 있다는 것입니다. 원하는 도구를 사용하여 코드형 인프라(IaC) 프로세스와 직접 선택한 버전 제어 시스템을 정의할 수 있습니다.

Terraform과 같은 도구를 사용하여 Google Cloud 리소스를 프로비저닝한 다음 Ansible ,Chef 또는 Puppet과 같은 도구를 사용하여 이러한 리소스를 구성할 수 있습니다. IaC 프로세스는 최적화 작업에 효과적인 롤백 전략을 구현하는 데 도움이 됩니다. 인프라를 설명하는 코드에 적용한 변경사항을 되돌릴 수 있습니다. 또한 변경사항을 테스트하여 인프라를 업데이트하는 동안 예기치 않은 장애를 방지할 수 있습니다.

또한 유사한 프로세스를 적용하여 환경의 다른 측면을 코드화할 수 있습니다. 예를 들어 코드형 정책(Open Policy Agent와 같은 도구 사용)과 코드형 작업(GitOps사용)이 있습니다.

따라서 초기의 최적화 반복에 IaC 프로세스를 도입하면 추가 최적화 활동을 코드로 정의할 수 있습니다. 또한 프로세스를 점진적으로 적용하면서 환경에 적합한지 평가할 수 있습니다.

모든 항목 자동화

전체 환경을 완전히 최적화하려면 리소스를 효율적으로 사용해야 합니다. 즉, 작업자의 수작업 부담을 해소함으로써 리소스를 절약하여 최적화 활동과 같이 가치를 창출하는 더 중요한 작업에 재투자해야 합니다.

SRE 권장사항에 따라 자동화를 늘려 반복 업무를 없앨 수 있습니다. 매우 전문화된 소프트웨어 엔지니어링 기술이나 노력이 필요하지 않은 자동화 작업도 있습니다. 경우에 따라 실행 가능한 짧은 스크립트를 주기적으로 사용하면 하루에 몇 시간씩 절약할 수 있습니다. Google Cloud는 Google Cloud CLI와 같은 도구 및 팀에서 반복적인 태스크를 자동화하는 데 사용할 수 있는 Cloud API, Cloud Scheduler, Cloud Composer, Cloud Run과 같은 관리형 서비스를 제공합니다.

모든 항목 모니터링

환경에 대한 세부 측정 정보를 수집할 수 없다면 가정을 뒷받침할 데이터가 없기 때문에 환경을 개선할 수 없습니다. 즉, 최적화 목표에 부응하기 위해 해야 할 일을 알 수 없습니다.

포괄적인 모니터링 시스템은 환경에 필요한 구성요소로, 최적화 목표를 평가하는 데 필요한 필수 측정항목을 모니터링합니다. 모니터링 시스템을 설계할 때는 최소 4가지 골든 신호를 모니터링하도록 계획하세요.

Monitoring 및 Logging과 같은 관리형 서비스를 사용하면 복잡한 모니터링 솔루션을 설정하지 않고도 환경을 모니터링할 수 있습니다.

특정 물리적 위치에만 데이터를 강제 저장하는 데이터 제한 정책이나 여러 클라우드 환경을 동시에 사용하는 서비스가 충족되도록 하이브리드 및 멀티 클라우드 환경을 모니터링하는 모니터링 시스템을 구현해야 할 수도 있습니다.

클라우드 지원 방식 채택

클라우드 지원은 클라우드에서 애플리케이션을 효율적으로 설계하고 실행하기 위한 방법을 설명하는 패러다임입니다. Cloud Native Computing Foundation(CNCF)은 클라우드 기반 애플리케이션을 컨테이너, 서비스 메시, 마이크로서비스, 변경 불가능한 인프라 선언적 API와 같은 기술을 통해 확장, 관리, 관찰할 수 있는 복원력이 우수한 애플리케이션으로 정의합니다. Google Cloud는 사용자가 클라우드 지원 애플리케이션을 설계하고 실행할 수 있도록 GKE, Cloud Run, Traffic Director, Logging, Monitoring과 같은 관리형 서비스를 제공합니다.

CNCF Trail Map 및 CNCF Cloud Native Interactive Landscape에서 클라우드 지원 기술에 대해 자세히 알아보세요.

비용 관리

결제와 비용 모델이 다르기 때문에 Google Cloud와 같은 퍼블릭 클라우드 환경의 비용을 최적화하는 방법은 온프레미스 환경을 최적화하는 것과 다릅니다.

자세한 내용은 Google Cloud로 마이그레이션: 비용 최소화를 참조하세요.

측정 및 분석 반복

이 반복에 대한 최적화 활동이 완료되면 측정과 분석을 반복하여 목표에 도달했는지 확인할 수 있습니다. 다음 질문에 답변해 보세요.

  • 최적화 목표를 달성했나요?

    이 질문에 대한 답이 예라면 다음 섹션으로 이동하세요.

    아니요라고 답했다면 환경 및 팀 최적화 단계의 시작 부분으로 돌아가세요.

최적화 루프 조정

이 섹션에서는 이 반복에서 따른 최적화 루프를 팀 구조 및 환경에 맞게 업데이트하고 수정합니다.

최적화 루프 코드화

최적화 루프를 효율적으로 최적화하려면 표준화되고 간소하며 관리할 수 있는 형식으로 루프를 문서화하고 정의하되, 나중에 변경할 수 있는 여지를 남겨두어야 합니다. Cloud Composer와 같은 완전 관리형 서비스를 사용하여 워크플로를 생성, 예약, 모니터링, 관리할 수 있습니다. 먼저 비즈니스 프로세스 모델 및 표기법(BPMN)과 같은 언어로 프로세스를 표현할 수도 있습니다. 그런 다음 이러한 프로세스를 비즈니스 프로세스 실행 언어(BPEL)와 같은 표준화된 언어로 코드화할 수 있습니다. IaC를 도입한 후 코드로 프로세스를 설명하면 IaC를 적용한 후 나머지 환경 요소을 관리할 수 있습니다.

최적화 루프 자동화

최적화 루프를 코드화한 후 반복 작업을 자동화하면 수작업 부담을 해소하고, 시간을 절약하고, 더 효율적으로 최적화 루프를 개선할 수 있습니다. 데이터를 측정하고 팀이 분석할 수 있도록 집계 보고서를 생성하는 등 사람이 결정하지 않아도 모든 작업을 자동화할 수 있습니다. 예를 들어 Cloud Monitoring으로 데이터 분석을 자동화하여 환경이 정의된 SLO에 부합하는지 확인할 수 있습니다. 최적화를 최적화 루프를 반복하는 끝이 없는 작업으로 고려하면 약간만 자동화해도 효율성이 크게 향상됩니다.

최적화 루프 모니터링

환경의 모든 리소스에 대해 수행한 것처럼 최적화 루프를 모니터링하여 최적화가 예상대로 작동하는지 확인하고 병목 현상과 향후 최적화 목표도 찾아야 합니다. 팀이 각 최적화 단계에서 사용한 시간과 리소스를 추적하여 모니터링을 시작할 수 있습니다. 예를 들어 문제 추적 시스템 및 프로젝트 관리 도구를 사용하면 프로세스를 모니터링하고 문제 해결 시간과 완료 시간 같은 측정항목에 대한 관련 통계를 추출할 수 있습니다.

다음 단계