[Well-Architected] Operational Excellence Pillar

Operational Excellence Pillar

이번 장에서는 Well-Architected Framework의 운영 우수성(Operational Excellence Pillar)에 대해서 알아본다.

---

운영 우수성 원칙

• 비즈니스 가치를 실현하고 지원 프로세스 및 절차를 지속적으로 개선하기 위해 시스템을 실행 및 모니터링하는 능력이다.
• 운영 우수성 원칙에서의 중점 영역은 아래와 같다.
  • 조직: 고객은 조직의 우선 순위, 조직 구조 및 팀 구성원이 비즈니스 성과를 지원할 수 있도록 조직이 팀 구성원을 지원하는 방법을 이해해야 한다.
  • 준비: 고객은 운영 아키텍처를 설계해야 한다.
    아키텍처를 실제로 구현하거나 대폭적으로 변경해야 할 시점에 정보에 근거한 의사 결정을 하려면 워크로드와 팀의 준비 상태를 살펴야 한다.
  • 운영: 고객은 워크로드 운영 방법을 알고 워크로드 및 운영 활동의 상태를 이해해야 한다.
    이를 통해 조직 및 비즈니스 성과를 달성하는 데 어려움이 있을 때를 구분하여 적절하게 대응할 수 있다.
  • 진화: 고객은 워크로드 및 운영 활동의 지속적인 개선을 위한 프로세스를 보유해야 한다.
    여기에는 피드백 루프를 구현하여 경험을 통해 학습한 후 개선하고 학습 내용을 공유하여 조직 전체에 도움을 제공할 수 있는 프로세스도 포함된다.

기존 환경에서의 운영 우수성 과제

• 수동 변경: 많은 사용자들은 종종 오래된 문서를 따르면서 잦은 변경을 피할 수 없었다.
• 배치성(대규모) 변경: 시스템 변경은 어려운 작업이며 위험이 따르기 때문에 잦은 변경을 기피하였다.
  이로 인해 대규모 릴리즈를 통해 변경 사항을 일괄로 처리하는 경우가 많아졌다.
• 게임 데이의 부재: 장애 또는 이벤트를 시뮬레이션하는 일도 거의 없었다.
  시뮬레이션 시스템이 없을 뿐만 아니라 시뮬레이션할 수 있는 사람도 없기 때문이다.
• 배울 시간이 없음: 변화의 속도가 너무 빠르다 보니 고객들은 바뀌는 상황에 따라 반응만 보일뿐 실제로 학습할 수 있는 시간이 없었다.
• 오래된 도큐먼트: 변화가 이루어지는 방식으로 인해 최신 정보를 유지하는 것도 어렵다.

클라우드 환경에서 운영 우수성

• 클라우드에서는 위에서 살펴본 기존 환경의 제약 조건이 모두 사라진다.
• 코드로 운영(IaaC): 고객은 애플리케이션 코드에 사용한 것과 동일한 엔지니어링 분야를 전체 환경 및 운영 활동에 적용할 수 있다.
• 취소 가능한 소규모 변경을 자주 수행, 운영 절차를 자주 개선: 자동화를 통해 변경에 따른 노력을 줄이고 점차 빠르게 늘어가는 가역적 변경에 대한 표준을 도입하여 위험을 줄인다.
• 장애를 예측하고 모든 운영 장애로부터 학습: 고객은 게임 데이를 통해 장애를 시뮬레이션하여 복구 프로세스를 테스트함으로써 실제로 장애가 발생했을 때 대응할 수 있는 능력을 키운다.
  이러한 시뮬레이션을 비롯한 모든 운영 이벤트를 통해 학습하여 대응 능력을 개선할 수 있다.

---

조직

• 고객 조직에게 워크로드의 비즈니스 가치와 워크로드를 지원하는 팀의 역할에 대한 공감대가 필요하다.
• 팀은 비즈니스 목표를 서로 공유하여 비즈니스 성공 여부를 결정할 수 있는 운영 우선 순위를 설정해야 한다.
• 다른 팀의 성공을 위해 자신이 해야 할 역할을, 그리고 자신의 성공을 위해 다른 팀이 해야 할 역할을 정확하게 알고 있어야 한다.
• 역할에 대한 책임과 소명에 대해 잘 알고 있으면 노력을 한 곳으로 집중하여 노력의 이점을 극대화하는 데 효과적이다.
• 고객은 팀원들이 실천을 통해 비즈니스 성과를 뒷받침하는 효과를 높일 수 있도록 팀원들을 지원해야 한다.

조직: 비즈니스 요구

• 조직의 중점 영역에서 운영 우수성 모범 사례를 나타내는 예로 비즈니스 요구에 대한 이해가 있다.
• 비즈니스는 고객의 요구를 해결하기 위해 존재한다.
• 개발 및 운영은 비즈니스의 요구를 해결하기 위해 존재한다.
• 우선 순위는 비즈니스 및 고객 요구를 통해 구체화된다.
• 규정 준수 요구 사항이나 업계 모범 사례와 같은 외부 요인도 우선 순위에 영항을 미칠 수 있따.
• 우선 순위를 설정할 경우 이점과 위험을 모두 고려하여 정보에 근거한 의사 결정을 해야 한다.
• 시장 진입 속도가 우선 순위라면 안정성이 단기적으로 상쇄될 수 있다.
• 성능이 우선 순위라면 비용 최적화가 상쇄될 수 있다.
• 우선 순위는 요구가 바뀔 때마다 업데이트할 필요가 있다.

---

준비

• 원격 측정 설계에서는 워크로드를 통해 고객이 모든 구성 요소의 내부 상태를 파악하는 데 필요한 정보(예: 지표, 로그, 이벤트, 트레이스)를 제공하는 데 중점을 둔다.
• 워크플로우 개선에서는 문제가 커지는 것을 막거나 프로덕션 단계로 번지기 전에 문제를 찾아 해결하는 등 프로덕션 단계로 진행하면서 유익한 변화가 더욱 빠르게 일어나도록 지원하는 실무를 강조한다.
• 배포 위험 완화에서는 고객이 변화를 통해 원하는 성과를 달성하지 못한 경우 이를 빠르게 파악하여 문제를 신속히 복구할 수 있도록 지원하는 실무에 중점을 둔다.
• 운영 준비 상태 파악에서는 워크로드가 프로덕션 단계를 시작할 준비가 얼마나 되어 있는지 그리고 고객 팀이 워크로드를 지원할 준비가 얼마나 준비되어 있는지 파악하는 데 중점을 둔다.
  고객은 프로덕션 단계에서 워크로드를 운영하는 데 따른 위험을 파악하여 운영 여부에 대해 정보에 입각한 의사 결정을 할 수 있다.

준비: 여러 환경 사용

• 준비의 중점 영역에서 운영 우수성 모범 사례를 나타내는 예로 여러 환경 사용이 있다.
• 고객은 개발자에게 실험을 위한 개인 샌드박스와 개발을 위한 개인 개발자 환경을 제공해야 한다.
  이렇게 하면 서로 영향을 미치지 않으면서 동시에 작업이 가능하다.
• 고객은 코드형 인프라와 구성 관리 시스템을 사용하여 프로덕션 단계와 일관성을 유지하지만 목적에 따라 확장도 가능한 환경을 배포해야 한다.
• 프로덕션 단계에 가까워질수록 환경에 대한 보안 통제를 강화해야 한다.
  이렇게 되면 행동과 테스트 결과를 통해 프로덕션 단계에서 예상되는 일을 알아내는 데 효과적이다.
• 환경을 사용하지 않을 때는 고객이 미사용 리소스와 관련된 비용이 발생하지 않도록 환경을 비활성화해야 한다.

---

운영

• 운영은 워크로드 및 운영 활동의 상태를 이해하고 유용한 비즈니스 및 기술 통찰력을 발굴하며 운영 이벤트에 대응하는 데 중점을 둔다.
• 고객은 워크로드 및 운영 측정치를 정의, 캡처, 분석하여 워크로드 상태, 워크로드 지원 시 성공적인 운영 활동 및 비즈니스 성과 달성에 대한 가시성을 제공해야 한다.
• “워크로드 측정치의 기술 통찰력”을 나타내는 예로 변화 “이후 워크로드 구성 요소의 상태에 미치는 영향”이 있다.
• “운영 측정치의 비즈니스 통찰력”을 나타내는 예로 “고객 대응 시스템의 기능을 성공적으로 업데이트하는 횟수”가 있다.
• 고객은 예상되는 측정 값의 기준을 비롯해 개선, 조사 및 개입을 위한 임계값을 설정해야 한다.
  이벤트가 발생하여 임계값을 위반하더라도 고객이 상황에 맞게 대응할 수 있다.
• 판매 프로모션, 배포, 게임 데이와 같은 이벤트는 계획에 따라 일어나지만 사용이나 구성 요소 장애의 급증과 같은 이벤트는 갑작스럽게 일어날 수 있다.
  고객은 런북과 플레이북을 사용하여 이벤트에 대해 일관적으로 대응할 수 있도록 해야 한다.

운영: 이벤트

• 운영에서 운영 우수성 모범 사례를 나타내는 예로 이벤트, 인시던트 및 문제를 관리하는 프로세스 구성이 있다.
• 고객이 정의해야 하는 대응 프로세스의 대상은 아래와 같다.
  • 주시하고 있는 이벤트
  • 인시던트: 개입이 필요한 이벤트
  • 문제: 개입이 필요하고 다시 발생할 수 있거나 현재 해결할 수 없는 이벤트
• 알림이 발생하는 모든 이벤트에 대해 런북이나 플레이북의 형태로 잘 정의된 대응을 마련해야 한다.
• 정의된 알림은 대응 프로세스를 정의하고 에스컬레이션을 적용하는 역할 또는 팀에서 소유해야 한다.
• 정의된 대응은 에스컬레이션을 트리거하는 요소와 에스컬레이션 프로세스를 포함하고 각 작업의 특정 소유자를 식별해야 한다.
• 에스컬레이션에는 제3자 공급업체 또는 AWS Support 같은 외부 당사자가 포함될 수 있다.

참고

• 에스컬레이션: 긴급 사고가 발생하여 상사의 지시나 지원이 필요할 때 이루어진다. 예를 들어, 아래와 같은 경우에 에스컬레이션이 이루어진다.
  • 클레임으로 책임자의 대응을 요구받은 경우
  • 가격 흥정 등 권한이 있는 책임자의 대응이 필요한 경우
  • 전문가 또는 권한이 있는 관리자의 대응이 필요한 문제가 발생한 경우
• 인시던트: 인스턴트는 “IT 장애”로 재해석할 수 있으며, 인시던트를 관리한다는 것은 IT 장애를 관리한다는 것을 의미한다.

---

진화

• 고객은 고객에게 영향을 미치는 이벤트, 피드백 루프, 학습 교훈, 측정치 분석, 교차 검토 등 다양한 분석을 통해 찾아낸 개선 가능성을 평가해야 한다.
• 고객은 가능성에 대한 검증 과정을 통해 우선 순위를 결정하고 필요에 따라 변경한 후 결과를 평가해야 한다.
• 변경으로도 원하는 결과를 얻지 못할 경우에는 다른 방법을 고려해야 한다.
• 고객이 개선 노력을 통한 이점을 극대화하려면 학습 교훈과 결과물을 팀원들과 공유해야 한다.

피드백 루프

• 진화 영역에서 운영 우수성 모범 사례를 나타내는 예로 피드백 루프 통합이 있다.
  • 활동에는 개선이 필요한 부분을 파악하기 위한 피드백 루프가 포함되어야 한다.
  • 피드백은 우선 순위를 정하여 개선하는 데 사용해야 한다.
  • 피드백은 운영 활동을 실행하는 과정에서, 사용자 경험에서, 그리고 비즈니스 및 개발팀에게서 나와야 한다.
  • 예시로 피드백 메커니즘은 비즈니스팀, 개발팀, 운영팀과 함께 운영 및 워크로드 측정치를 정기적으로 검토하는 것이 있다.
    이러한 회의를 통해 비즈니스 요구의 변화를 식별하고 통찰력을 검증하며 개선 기회 및 방법을 파악한다.
  • 고객은 시간이 지나면서 피드백을 평가하여 개선 성공 여부를 인지할 수 있다.

---

핵심 사항

• 운영 우수성 원칙의 핵심 사항은 아래와 같다.
  • 비즈니스 우선 순위를 파악한다.
  • 운영을 고려한 설계를 통해 워크로드의 상태 및 성공적인 운영 활동에 대한 통찰력을 키울 수 있다.
  • 워크로드와 팀을 포함하여 운영 준비 상태를 평가한다.
  • 워크로드의 상태와 운영 활동의 상태를 파악한다.
    이를 통해 비즈니스 및 운영 통찰력을 얻을 수 있다.
  • 런북과 플레이북을 사용하여 이벤트를 준비하고 이에 대응한다.
  • 경험을 통해 학습하고 개선한다.
    이러한 경험의 이점을 극대화하려면 조직에서 학습한 내용을 공유한다.

참고

• 런북(Runbook): 문제를 해결하기 위해 필요한 조치들을 정의한 것이다.
• 플레이북(Playbook): 장애에 영향을 미친 원인을 조사하고 식별하기 위해 수행되는 프로세스를 문서화 한 것이다.

---

참고 자료

• https://explore.skillbuilder.aws/learn/course/1793/play/48096/the-operational-excellence-pillar-korean