[실용주의 클라우드컴퓨팅]서비스의 연속성 보장은 인프라 자원 최적화가 정답

시스템 규모에 맞게 자원을 배치하는 일은 매우 중요하다. 자원이 부족하면 성능이 낮아져 정상적인 서비스가 불가능하다. 반면 자원을 과다하게 배치하면 비용이 낭비된다. 하지만 어떤 서비스도 시작할 때 예측한 인프라 규모가 딱 들어맞는 경우는 거의 없다. 서비스를 실제로 운영해봐야 자원이 어느 정도 필요한지 알 수 있다.

이로 인해 온프레미스에서는 사용하지 않던 자원을 과다하게 배치하거나 또는 유입된 고객을 다 처리하지 못해 장애가 발생하는 경우가 다반사이다. 많은 시스템이 클라우드로 이전된 지금도 이런 종류의 장애가 없는 것은 아니다. 그러나 최소한 필요한 자원을 추가하거나 필요 없는 자원을 조정하는 데 많은 시간이 소요되지는 않는다.

클라우드에서 자원을 배치하거나 조정하려면 자원이 얼마나 필요한지 가늠하기 위해 인프라의 성능을 측정해야 한다. 대표적인 측정 방법으로 벤치마킹테스트(BMT)을 들 수 있다. 주의할 점은 이 때의 테스트는 유의미하지만 판단의 절대적 기준으로 삼으면 안 된다는 점이다. 클라우드는 물리자원을 가상화해서 공유하는 것이이다. 다른 고객의 사용량에 영향을 받는, 이른바 '시끄러운 이웃(noisy neighbor)' 문제로부터 아직도 완전히 자유롭지 못하다는 점을 간과해선 안된다.

[실용주의 클라우드컴퓨팅]서비스의 연속성 보장은 인프라 자원 최적화가 정답

다시 말하자면 측정 시점의 대상 자원이 어떤 상태이고 부하가 얼마나 걸려있는 지에 따라 BMT 결과는 크게 달라질 수 있다. 최근에는 이런 불확실성을 조금이라도 줄이기 위해 디스크 입출력(I/O)에 대해 프로비전드 IOPS(Provisioned IOPS)를 구매하는 상품이 적지 않게 출시되고 있다.

그래도 클라우드 자원 성능은 전반적으로 예측하기 어렵다. 항상 동일하게 유지된다고 보장할 수 없기 때문이다. 게다가 프로비전드 IOPS처럼 성능을 보장받으려면 높은 가격을 지불해야 한다.

아마존웹서비스(AWS)의 오랜 사용자들이 이런 문제에 대해 가지고 있는 한 가지 팁은, 가상머신(VM)의 CPU 스틸 타임(Steal Time)이 20%를 넘어가면 해당 VM을 재시작한다는 것이다. CPU 스틸 타임이란 해당 VM에 주어진 시간 중 실제로 CPU를 할당받지 못해서 대기하는 시간이다. CPU 스틸 타임이 길다는 것은 그만큼 해당 VM이 배포한 호스트의 CPU에 과부하가 걸려 있다는 것을 뜻한다.

이때 VM을 재시작하면 부하가 상대적으로 낮은 다른 호스트로 VM이 이전돼 성능이 개선될 수 있다. VM을 재시작했는데도 CPU 스틸 타임이 20%를 넘는다면 이 값이 좋아질 때까지 자동화한 스크립트가 계속해서 VM을 재시작한다. AWS 내부에도 각 서버의 부하가 균등해지도록 관리하는 프로세스가 없지는 않다. 하지만 이러한 증상이 관찰된다는 것은 시스템이 100% 완벽하지 않다는 점을 시사한다.

[실용주의 클라우드컴퓨팅]서비스의 연속성 보장은 인프라 자원 최적화가 정답

어떤 CSP(클라우드 서비스 공급자) 고객게시판을 보면 서버가 일정 시간마다 거의 중단될 정도로 성능이 낮아진다는 불평을 호소하는 경우도 더러 있다. 이건 CSP 측에서 정해진 시간에 일괄 작업(batch job)을 구동하거나 호스트를 같이 사용하는 다른 고객이 부하를 크게 일으키는 것일 수 있다. 다시 말해 BMT때 좋은 성능이 나왔다고 해도 이 성능이 물리서버처럼 테스트와 동일하게 유지되리란 보장은 어디에도 없다.

클라우드 성능 관리를 위해 자원 상태를 지속적으로 확인해 최적화해야 한다. 결론적으로 클라우드를 사용할 때는 온프레미스에서 하던 기존 방식의 BMT 결과에 절대적으로 의존하면 안 된다. 대신 자원 사용량과 포화도를 확인하고 그에 맞춰 인프라를 탄력적으로 늘리거나 줄이는 작업을 지속적으로 수행해야 한다.

고객은 물리적 인프라의 관리와 통제를 CSP에 맡겨 버렸기 때문에 배치된 VM의 호스트에 성능 지연 요소가 발생해도 할 수 있는 일이 별로 없다. 앞서 얘기한대로 VM을 재시작해 다른 호스트로의 배치를 유도하는 정도의 조치를 취할 수 있을 뿐이다. 이를 위해서는 자원 사용량을 지속적으로 모니터링할 수 있는 관제 시스템과 적절한 자동화 도구가 필요하다.

최근에는 오케스트레이션 도구가 너무 좋다 보니 일부 컨테이너에 과부하가 발생해 다운되더라도 서비스가 끊기지 않도록 추가 컨테이너를 자동으로 올리는 등의 작업이 가능하지만 이런 상황이 항상 바람직한 건 아니다. 서비스의 연속성을 보장해주는 오케스트레이션 도구는 최후의 보루나 보험 같은 개념으로 인식해야 한다. 인프라의 자원 상태를 지속적으로 확인해 최적화하는 게 정답이다. 그것이 클라우드 시대에 인프라를 쓰는 올바른 방식이다.

<자료제공:클라우드 전문기업 케이아이엔엑스(KINX)> 노규남 CTO bardroh@kinx.net