성능 효율성을 위한 설계

시스템 성능을 설명할 때 자주 사용하는 비유 중 하나는 파이프를 통한 물의 흐름입니다.

물의 흐름을 성능에 비유하면, 흐르는 양은 물의 속도와 파이프의 굵기에 따라 결정됩니다.

시스템의 성능도 이와 유사합니다. 물의 속도는 응답 시간에, 파이프의 굵기는 동시에 처리할 수 있는 작업 수에 해당합니다.

만약 파이프를 통해 흐르는 것이 물이 아니라 끈적한 기름이라면, 같은 굵기의 파이프를 사용하더라도 같은 시간 동안 흐르는 양에는 차이가 생길 것입니다.

이처럼 정보시스템에서도 처리하는 업무의 특성에 따라 처리 속도가 달라질 수 있으며, 이에 따라 성능 역시 달라질 수밖에 없습니다.

따라서 사용자의 특성과 환경에 따라 요구되는 성능 수준은 달라질 수 있으며, 동일한 성능이라도 사용자마다 만족도는 다르게 나타날 수 있습니다.

이는 모든 시스템과 사용자에게 일률적으로 적용할 수 있는 기준이 존재하지 않음을 의미합니다.

이러한 점을 고려할 때, ‘성능’은 다음과 같이 정의할 수 있습니다.

성능이란, 특정 업무를 대상으로 사용자의 요청을 기대한 시간 내에 처리할 수 있는 작업량을 의미합니다.

기존의 IT 환경에서는 성능 관리를 위해 제한된 물리적 자원 내에서 처리량을 극대화하는 데 중점을 두었으며, 이를 위해 정보시스템의 각 요소를 최적화하는 작업이 중심이었습니다.

하지만 최근의 IT 환경은 부분 최적화보다는 클라우드 기술을 기반으로 Application 인프라와 자원을 활용하여, 증가하는 서비스 수요와 기술적 요구사항을 효율적으로 충족하는 데 중점을 두고 있습니다.

성능 효율성을 위한 고려사항

비용과 성능 트레이드 오프 고려

성능 요구 사항을 충족하기 위해서 자원을 미리 배포하거나 오버 프로비저닝할 경우 예상하지 못한 비용이 발생할 수 있습니다.

또한 오버 프로비저닝 전략을 채택할 경우, 수요가 급증해 미리 프로비저닝한 자원의 한계를 초과하게 되면, 문제 대응 단계에서 자원 조정이 필요해집니다.

아키텍처 설계 시 수요에 따른 자원 조정 전략을 반영하면, 워크로드 구성 요소의 크기를 유연하게 조정하는 탄력성을 구현할 수 있으며, 이는 클라우드 워크로드의 성능 효율성을 높이는데 기여합니다.

Auto-Scaling은 컴퓨팅 자원을 수요에 맞게 수평 확장/축소할 수 있는 효과적인 수단이지만, Scaling 정책을 적절히 구성하지 않으면, 불필요한 확장이 발생하거나, 필요한 시점에 충분한 성능을 제공하지 못할 수 있습니다.

수요 부하를 분석하고 그 특성에 맞는 정책을 수립하면, 비용 낭비를 줄이고 필요한 컴퓨팅 성능을 확보할 수 있습니다.

캐싱 전략을 구현할 때도 정교한 설계가 필요합니다.

캐싱은 자주 사용하는 콘텐츠를 낮은 지연 시간으로 제공하기 위한 기술이지만, 콘텐츠가 자주 사용되지 않거나 캐싱 보존 주기(Time-To-Live, TTL)가 사용 사례에 적합하지 않을 경우, 불필요한 비용이 발생하거나 지연 시간 개선 효과를 얻지 못할 수 있습니다.

요구 사항에 적합한 클라우드 서비스 선택

워크로드의 성능 목표 및 향후 용량 요구 사항에 맞춰 적절한 클라우드 서비스를 선택합니다.

• 요구 사항의 성능 목표를 충족할 수 있는 서비스를 선택합니다.
  Samsung Cloud Platform은 Virtual Machine, Bare Metal, Serverless Computing 등 다양한 컴퓨팅 옵션을 제공합니다.
  예를 들어, 고가용성의 고성능 OLTP가 요구되는 데이터베이스를 구축해야 하는 경우, Virtual Server에 데이터베이스를 구축하거나 DBaaS 서비스를 사용하는 대신, 두 대의 Bare Metal Server에 데이터베이스 서버를 이중화 구성하고, Multi-Attach 방식으로 Block Storage(BM)을 연결하는 방식을 선택할 수 있습니다.

• 규정 준수 및 제한 요건을 충족합니다.
  클라우드는 다양한 서비스를 제공하지만, 특정 규정이나 제한 요건으로 인해 선택이 제한될 수 있습니다.
  예를 들어, 성능과 운영 측면에서 DBaaS를 사용하고자 하더라도, 데이터를 저장할 때 DBaaS에서 지원하지 않는 특정 암호화 모듈을 적용해야 하는 규정 준수 요구 사항이 있다면 해당 서비스 사용은 어려울 수 있습니다.

• 조직 역량을 고려합니다.
  Microservice Architecture는 성능, 운영 측면에서 효율성을 극대화하는 전략이 될 수 있겠지만, 이를 구현하려면 조직의 기술 역량, 프로세스, 문화가 뒷받침되어야 합니다.
  준비되지 않은 상태에서 기술적 혁신을 시도하면 실패 가능성이 높아집니다.

성능을 고려한 전체적 서비스 흐름 설계

흐름(flow)은 워크로드 내에서 특정 작업을 수행하는 일련의 과정을 의미합니다.

사용자의 요청 이벤트가 생성되고 이를 처리하는 메시지가 서버로 전달되며, 응답을 처리해 회신하는 일련의 과정을 흐름이라 할 수 있습니다.

정보 시스템의 성능을 효율화하려면 모든 흐름을 파악하는 것이 중요합니다. 워크로드를 개별 흐름 단위로 분석하면, 병목 현상이나 자원 사용의 비효율성을 발견할 수 있습니다.

이를 위해 각 구성 요소에 분석 및 추적 도구를 적용하고, 성능 메트릭을 설정해 일정 기간 데이터를 수집합니다.

이렇게 수집된 데이터를 바탕으로 중요한 흐름을 식별하여 성능 개선의 우선 대상으로 선정합니다.

중요한 흐름은 고객의 주요 사용자 흐름이거나, 워크로드 상 핵심 작업에 해당하는 시스템 및 데이터 흐름을 의미합니다.

안정성 설계 원칙에서 다룬 업무 영향 분석(더 자세한 내용은 안정성 설계 원칙 > I. 업무 영향 분석 및 복구 목표 정의 > 1.업무 영향 분석(BUSINESS IMPACT ANALYSIS))처럼, 비즈니스 영향도를 평가해 중요한 흐름을 식별하고 성능 지표를 분석해 개선 목표를 수립합니다.

식별된 중요한 흐름에는 전용 자원과 충분한 용량을 제공하여 안정적인 컴퓨팅 환경을 확보합니다.

• 중요한 흐름을 위한 전용 자원 구성
  중요한 흐름은 다른 프로세스의 간섭 없이 독립적으로 작동할 수 있도록 구성해야 하며, 이를 위해 별도의 VPC 또는 서브넷을 활용할 수 있습니다.

• 소프트웨어 수준에서 흐름 격리
  VM(Virtual Machines) 또는 컨테이너 단위로 흐름을 분리하여, 다른 흐름의 간섭을 최소화합니다.

• 전용 자원 및 용량 확보
  중요한 흐름에는 자원 공유를 최소화하고 전용 자원 또는 용량을 할당하여 안정적인 실행을 보장합니다.

다음은 중요한 흐름에서 발생한 문제에 대한 예시입니다.

모 회사는 온라인 채용을 위해 고가용성의 3계층 웹사이트 아키텍처를 운영하고 있습니다.

그러나 인사팀은 특정 시기에 급격한 트래픽 증가로 인해 지원서 접수가 원활하지 않은 문제를 겪고 있습니다.

채용 시즌에는 수만 명의 지원자가 몰리지만, 비시즌에는 시스템 부하가 현저히 낮습니다.

온프레미스 환경에서는 이러한 부하를 처리하기 위해 장비를 추가로 구매해야 하지만, 채용 시즌 이후에는 해당 장비가 유휴 상태로 전환되어 관리 부담이 커지고 비용 효율성도 떨어지는 문제가 발생합니다.

이러한 문제는 클라우드 환경을 통해 해결할 수 있습니다.

주요 흐름인 ❶Web Server와 ❷Application Server의 워크로드를 위해 Auto-Scaling을 구현하고, ❸데이터베이스에 DBaaS 고가용성을 구현하였습니다.

반면 주요 흐름이 아닌 ❹Bastion Server와 ❺Standalone Application 서버는 단독 서버로 구성합니다.

클라우드 성능 개선 영역

지연 시간

지연 시간(Latency)은 네트워크를 통해 데이터를 전송하는 데 걸리는 시간을 의미합니다.

최종 사용자와 정보 시스템 사이의 거리가 가깝고 시스템의 응답 속도가 빠르다면 지연 시간은 짧습니다. 반대로 거리가 멀거나 응답 속도가 느리다면 지연 시간은 길어집니다.

네트워크 지연 시간이 길어지면 Application 성능이 저하되며, 일정 수준 이상으로 증가할 경우 시스템 장애로 이어질 수도 있습니다.

네트워크 지연 시간은 다양한 요인에 의해 발생합니다.

우선, 요청 위치와 수신 위치 사이의 네트워크 회선 및 라우터 등의 중계 장비에 의해 지연 시간이 발생할 수 있습니다.

출발지부터 목적지까지 데이터 패킷이 경유하는 라우터를 홉(hop)이라 하는데, 홉 수가 많을수록 지연 시간은 증가합니다.

또한, 데이터센터 내에서 방화벽 등의 경계 보호 장비와 내부 네트워크 장비에 의해 지연이 발생할 수 있습니다.

서버 팜 내 웹, Application, 데이터베이스 간 또는 서버 내부의 작동 메커니즘에 의해서도 지연이 발생할 수 있습니다.

아울러, Application이 다른 서버와 연계하여 응답을 회신해야 하는 경우에도 지연은 발생할 수 있습니다.

지연 시간을 줄이기 위한 가장 기본적인 방법은 클라이언트와 서버 간의 네트워크 거리를 줄이는 것입니다.

서버를 클라이언트와 지리적으로 가까운 Region에 배치하거나, CDN을 구성하여 엣지 서버에서 직접 응답을 처리하는 방식이 있습니다.

다음 그림은 다양한 콘텐츠가 담긴 웹사이트의 수신 트래픽 지연 속도를 나타냅니다.

네트워크 홉 수가 적을수록 맨 오른쪽의 지연 시간이 감소하게 됩니다.

처리량(Throughput)

사용자와 서버의 거리를 줄여 지연 시간을 단축하는 설계와 함께, 네트워크 처리량을 증가시키는 것도 네트워크 성능을 높이는 방안 중 하나입니다.

처리량은 단위 시간당 처리되는 작업의 양을 의미합니다.

처리량과 지연 시간은 밀접한 관계가 있습니다.

단시간에 더 많은 데이터를 전송할 수 있다는 것은 지연 시간이 짧고 처리량이 높다는 것을 의미합니다.

네트워크 처리량은 초당 전송된 데이터 양(Bytes/second 또는 bits/second)으로 표현됩니다.

운영체제 수준에서는 처리량이 CPU와 메모리 간의 초당 데이터 전송양에 따라 결정됩니다. 데이터베이스 분야에서는 초당 처리 가능한 트랜잭션 수(operations/second 또는 Transactions/second)로 나타냅니다.

성능 요구 사항을 정의할 때 처리량에 대한 요구는 동시 접속자 수와 동시 처리량으로 표현되며, 이는 II. 컴퓨팅 설계 > 1. 컴퓨팅 서비스, 서버 타입 및 사이징에서 추가적으로 다룹니다.

처리량을 높이기 위해 고려할 수 있는 방안은 다음과 같습니다.

• 전송 서버 확장
  동일한 작업을 수행하는 컴퓨팅 Node를 Load Balancer에 병렬로 배치하여 전체 서비스의 처리량을 늘릴 수 있습니다.

• 전송 방식 변경
  Application 연결을 세션 방식이 아닌 API 기반 연결 방식으로 구현하면 자원 활용도를 높일 수 있습니다.

• 하이브리드 연결 구성
  Direct Connect가 필요한 경우, 하이브리드 연결을 검토하여 적절한 대역폭을 선택할 수 있습니다.

용량 계획

용량 계획은 미래의 워크로드 요구 및 사용 패턴을 고려하여 자원 용량에 대한 의사결정을 내리는 절차입니다.

계절적 변화나 신제품 출시 등 비즈니스 일정에 따른 사용량 변화를 예측하고, 이를 용량 계획에 반영합니다.

이러한 사전 대응 전략은 서비스 중단을 예방하고 성능 효율성을 향상시킬 수 있습니다.

과거 사용량 추세 및 증가 데이터를 분석하여 단기 및 장기 용량 요구 사항을 예측하고, 병목 및 Auto-Scaling의 문제를 사전에 파악하여 일관된 워크로드 성능을 확보할 수 있습니다.

• 장기간 축적된 데이터를 분석합니다.
  1년 이상 축적된 사용률, 성능 데이터, 워크로드 패턴 로그를 분석하여, 계절적, 주기적 수요를 파악하고 수요 급증 시기의 부하를 용량 계획에 반영합니다.

• 병목을 식별합니다.
  프로덕션 환경과는 별도로 테스트 환경을 구성하고, 부하를 발생시켜 병목 지점을 측정하고 개선하여 전체적 성능을 향상시킵니다.

• 자동 확장을 구현합니다.
  수작업 확장 대신 자동화된 확장 방식을 구성합니다.

스케줄 기반 Auto-Scaling을 설정하거나, 클라우드 서비스의 관리형 서비스를 활용하여 내재된 용량 확장을 이용합니다.

성능 목표 정의, 측정 및 개선

성능 목표 정의, 측정 및 개선 프로세스 수립

성능 요구사항은 사용자에게 최적화된 정보시스템 서비스를 제공하고, 안정적인 운영과 유지를 위해 요구되는 핵심 요소입니다.

이는 시스템이 기능을 수행할 때 얼마나 빠르고 효율적으로 처리할 수 있는지를 구체적으로 설명합니다.

또한 성능 요구사항은 특정 조건에서 기능을 수행할 때 필요한 시간, 처리량, 자원의 최대 사용치 등에 대해 기술합니다.

성능 요구사항이 중요한 이유는 최종 사용자가 체감하는 시스템 품질에 큰 영향을 미치기 때문입니다.

시스템 처리 속도, 화면 응답 시간, 페이지 오류 및 정지 시간 등은 서비스 수준 관리에서 치명적인 불만족 요소가 될 수 있습니다.

따라서 이러한 항목은 반드시 제안 요청서에 명시하고, 시스템 구축 시 장비 성능 테스트와 연계하여 성능 목표를 충족해야 합니다.

성능 요구사항의 항목은 다음과 같으며, 각 항목에 따라 구체적인 성능 목표를 수립합니다.

기존 정보시스템에서는 성능 측정 방법론으로 USE 방법론을 사용했지만, 최근 클라우드 네이티브 Application 개발이 확산되면서 RED 방법론이 사용되기도 합니다.

USE 방법론 (The USE Method)

Brendan Gregg이 제안한 방법론으로, 성능 검토 초기 단계에서 시스템의 병목 지점을 분석하기 위해 사용합니다.

USE 방법론은 다음과 같이 정의할 수 있습니다.

“모든 resource (자원)에 대하여 utilization (사용률), saturation (포화율), errors (오류)를 확인합니다.”

각 용어의 정의는 아래 표와 같습니다.

USE 방법론의 절차는 아래와 같습니다.

USE 방법론은 순서도의 흐름에 따라 오류를 먼저 점검한 후, 사용률과 포화도를 차례로 확인하는 방식으로 수행됩니다.

일반적으로 오류는 직관적으로 확인이 가능하므로, 먼저 오류 여부를 점검한 후 나머지 항목을 분석하는 것이 시간 절약에 효과적입니다.

예를 들어, CPU 사용률이 100%라면 해당 지점이 병목일 가능성이 높습니다.

이러한 지표를 확인할 때는 지표의 갱신 주기를 함께 고려해야 합니다.

Cloud Monitoring의 최소 지표 갱신 주기는 1분이며, VM의 100% 사용률이 지속적으로 발생하는지, 아니면 일시적으로 발생하는지 확인합니다.

USE 방법론은 소프트웨어에 대한 깊은 이해 없이도 기계적으로 적용할 수 있으며, 온프레미스 환경은 물론 클라우드 환경에서도 유용하게 활용되어 왔습니다.

이 방법론에서는 주로 물리적 하드웨어 자원을 모니터링 하며, 소프트웨어는 대부분의 시스템에서 공통적으로 사용하는 기본적인 자원에 해당합니다.

따라서 소프트웨어 로직에 의존하지 않으며, 어떤 소프트웨어를 사용하더라도 적용할 수 있습니다.

그러나 물리적 자원을 분할하여 사용하는 Microservice 아키텍처에는 적용에 한계가 있습니다.

이러한 경우에는 RED 방법론을 사용하는 것이 적절합니다.

RED 방법론 (The RED Method)

Tom Wilkie가 Microservice 환경에서의 성능 분석을 위하여 제안한 방법입니다.(The RED Method: How to Instrument Your Services | Grafana Labs)

“모든 서비스에 대하여, rate (처리율), errors (오류 수), duration (처리 시간)을 모니터링한다.”

RED 방법론의 메트릭은 모두 요청(request)에 기반한 항목들로 구성됩니다.

각 용어를 정의하면 다음과 같습니다.

USE 방법론이 하드웨어 지표 중심이라면 RED 방법론은 서비스 요청 중심의 메트릭에 초점을 맞춥니다.

Microservice 환경에서 웹 Application의 응답 지연이나 오류를 분석할 때 RED 방법론이 유용합니다.

RED 방법론 역시 하드웨어나 소프트웨어의 내부 구조를 해체하거나 분석하지 않고도 간단하게 적용할 수 있습니다.

단, Cloud Monitoring에서는 RED 지표를 수집할 수 없기 때문에, Prometheus 등의 도구를 활용하는 것이 효과적입니다.

지속적인 최적화 및 개선

지속적인 성능 최적화란 시스템 성능을 모니터링하고 분석하며, 개선 활동을 지속적으로 수행하는 일련의 프로세스를 의미합니다.

성능 효율성의 목표는 수요의 변동에 따라 자원을 조정하여, 사용자가 기대하는 시간 내에 응답을 제공하는 데 있습니다.

정보 시스템의 성능은 시간이 지남에 따라 저하될 수 있습니다.

따라서 수요 변동, 기능 및 인터페이스 증가에 따른 복잡성 등 시스템 내외부의 다양한 변수를 고려해야 합니다.

지속적인 변화 속에서도 성능 효율성 목표를 달성하기 위해서는 다음과 같은 최적화 및 개선 전략이 필요합니다.

• 새로운 클라우드 기술을 검토하고 적용합니다.
  클라우드 사업자는 인프라와 소프트웨어 플랫폼에 지속적으로 새로운 기술을 도입합니다.
  따라서 이러한 기술을 정기적으로 검토하고 적용해야 합니다.
  이전 버전의 플랫폼에 대한 기술 지원이나 업데이트가 중단되면, 성능은 물론 보안과 가용성에도 부정적인 영향을 미칠 수 있습니다.

• 개선 우선 순위를 지정합니다.
  시간이 흐름에 따라 구축 당시에는 최적화되었던 기술이 비효율적으로 변할 수도 있습니다.
  예를 들어, 데이터베이스에서 특정 쿼리가 중요한 흐름으로 사용되었지만, 트렌드 변화로 인해 다른 쿼리가 중요해질 수 있습니다.
  초기에는 특정 흐름에 맞춰 자원과 쿼리를 최적화하여 성능 목표를 달성했을 수 있습니다. 그러나 트렌드가 변화하면서 새롭게 부하가 집중된 쿼리 및 자원 계획이 최적화되어 있지 않다면, 전체적인 성능저하로 이어질 수 있습니다.
  이러한 경우 우선 순위를 조정하고 쿼리 및 자원 용량 계획을 변경할 필요가 있습니다.

• 성능 최적화를 자동화합니다.
  자동화는 반복적이고 시간이 많이 소요되는 수동 프로세스를 제거하여 오류 가능성을 줄이고 일관성을 확보할 수 있습니다.
  이를 위해 성능 테스트, 배포 및 모니터링 등의 작업에 자동화를 적용합니다. USE 방법론이나 RED 방법론을 적용할 경우에도, 모니터링 대상 성능 지표의 임계치를 설정하고, 특정 이벤트 발생 시 즉시 관리자에게 자동 알림이 전송되도록 구성해야 합니다.
  또한, 긴급 이벤트 발생 시에는 자동화된 스크립트를 통해 신속하게 대응할 수 있도록 사전 계획을 수립합니다.