Tyk API 게이트웨이를 위한 인프라 크기 설정
인프라 규모를 결정하는 것은 과학이기도 하고 최적화 문제이기도 합니다. 비용을 절감하면서, 동시에 성장을 가능하게 하는 규모인지 확인하는 것은 모든 조직이 풀어야 할 과제입니다.
다행히도, 시스템 메트릭을 주의 깊게 분석하여 기본 요구 사항이 무엇인지 결정할 수 있다는 것입니다. 여기에는 예상하거나 수신하는 초당 요청 수, 대기 시간에 대한 소비자의 관용 범위 (tolerance), 내결함성을 얼마나 깊이 검토해야 하는지와 같은 요인이 포함될 수 있습니다. 이 접근 방식은 이러한 방정식의 과학적 측면을 다룹니다.
인프라 크기 조정 방정식의 낙관적인 측면은 사용자가 미래에 인프라에 얼마나 많은 요구를 가할 것인지를 묻습니다. 그 요구가 너무 크면 창 밖으로 돈을 던지게 될 것이고, 너무 작게 설정하면 시스템에 부담을 주어 대기 시간과 불행한 사용자를 초래함으로써 사용자로부터 외면 받게 될 것입니다. 고맙게도 클라우드 플랫폼을 사용하면 인프라를 쉽게 확장 및 축소할 수 있는 옵션을 통해 신중하게 낙관할 수 있습니다.
그렇다면 이러한 인프라 크기 조정 고려 사항에서 Tyk 게이트웨이는 어디쯤 있을까요? 계속 읽으시면 알게 됩니다 !
참고: 성장의 각 단계에서 인프라 비용을 확인하여 초과 지출과, 또는 활용도가 낮은지 확인해야 합니다. 운영을 위해 가장 크고 최고의 서버가 정말로 필요합니까? 결국, 여러분의 에고는 과도한 클라우드 요금을 마술처럼 낮춰주지는 못합니다! 비용을 확인하여 지불할 금액을 파악하고 이를 월 지출에 반영하십시오. 예상하지 못한 거대한 청구서에 놀라실 이유가 없습니다!
기본 요구사항 결정
여러분이 속한 시나리오에 따라 베이스라인을 다르게 개발할 수 있습니다: 기존의 트래픽이 있는 이미 보유하고 있는 앱인가요, 아니면 히스토리가 없는 새로운 앱입니까?
트래픽 데이터가 있는 경우 가장 좋은 방법은 평균 지연 시간 (average latency)과 평균 초당 요청 수(RPS)를 중심으로 하는 몇 가지 지표를 조사하는 것입니다. 평균 대기 시간이 확실하지 않지만 평균 RPS를 알고 있는 경우 여기에서 다루는 간단한 부하 테스트 연습이 현재 설정의 평균 대기 시간을 결정하는 데 도움이 될 것입니다.
참조할 트래픽이 없다면 경험과 지식을 바탕으로 충분한 추측을 하십시오. 애플리케이션의 흐름과 출시 또는 트래픽이 피크를 치게 될 것으로 예상하는 이벤트 시점에서의 예상되는 사용자 기반에 대해 조사하면 도움이 될 것입니다. 이것은 최선의 추측을 기반으로 해야 하지만 너무 높거나 너무 낮지 않도록 주의해야만 합니다. 자신이 편안하게 느끼는 현실적인 범위를 찾으십시오.
새로운 앱에 사용자가 없고 API 호출 집약적이지 않은 데도, 밀리초 미만의 지연 시간으로 10,000 RPS를 처리할 수 있는 인프라를 프로비저닝하는 것은 과도합니다. 너무 작게 가고 싶지는 않지만 트래픽이 없다면 문제가 되지 않을 것입니다.
이 단계에서는 이러한 요청이 어디에서 오는지 확인할 수도 있습니다. 글로벌 사용자 기반이 있는 경우라면 사용 사례에 따라 다른 지역에서 인프라를 가동할 수 있습니다. 또한 트래픽을 분할하는 방법을 살펴볼 수도 있습니다. 분산된 지역에서 여러 개의 소규모 서버를 실행할 것인가요, 아니면 몇 개의 중앙 허브를 선택하고 더 큰 서버를 실행할 것인가요?
다양한 시나리오로 실행 해보고 각각의 부하를 테스트하여 가장 좋은 출발점을 결정하는 것이 유용합니다. 그런 다음 비용을 확인하십시오! 일부 인프라를 축소하고 몇 달러를 절약할 수 있습니까? 고객에게 영향을 미치지 않는 절감액을 찾으십시오.
인프라 베이스라인 체크리스트
- 현행 고객 또는 예상되는 초기 사용자 기반으로 계수정보 (metrics) 수집합니다.
- 여러 개의 작은 서버 또는 더 적은 수의 서버로 로드를 분할할지 여부를 결정합니다.
- 결과가 사용자의 기대에 부합하는지 확인하기 위한 부하 테스트
- 비용을 확인하고 절감액을 찾으십시오.
미래의 요구사항 예측
신규 애플리케이션이든 기존 애플리케이션이든 관계없이 어느 정도는 추정을 하게 됩니다. 일부 시나리오에서는 이 작업을 더 쉽게 수행할 수 있습니다. 예를 들어, 비즈니스에서 현재 사용자 기반을 두 배로 늘리려는 계획이 있는 경우, 이를 위한 시뮬레이션을 수행하고 시스템이 여전히 잘 작동하는지 확인할 수 있습니다. 백오피스 애플리케이션을 사용하면 새로운 사용자가 예상되기 때문에 이것이 가능할 수 있습니다.
그러나 외부 시스템을 사용 중이고 향후 요구 사항이 확실하지 않은 경우에는 어떻게 합니까? 또는 사용자 증가 및 채택에 대해 정의되지 않은 숫자가 있는 새 시스템이 있는 경우 어떻게 하시겠습니까? 이러한 시나리오에서는 시장에 대한 좋은 아이디어를 얻기 위해 유사한 회사의 성장을 살펴볼 가치가 있습니다.
현명한 낙관주의가 여기에 도움이 될 것입니다. 확장 방법에 대한 계획을 세울 때입니다. 시스템 및 고객 요구 사항에 따라 사용자 기반을 두 배, 세 배, 네 배(등)로 늘리는 데 필요한 인프라를 고려하십시오. 예상 성장, 이를 지원하는 데 필요한 인프라, 해당 인프라 비용을 개략적으로 설명하는 공식 계획을 작성하십시오. 이 플랜을 사용하여 여러 클라우드 제공업체에서 쇼핑하여 기능 및 비용을 기준으로 사용 사례에 가장 적합한 서비스를 확인할 수 있습니다.
이제 인프라 요구 사항에 대한 몇 가지 수치와 아이디어를 얻었으므로 계획의 각 단계에 따라 몇 가지 부하 테스트를 실행합니다. 이렇게 하면 인프라 계획이 예상 트래픽을 처리할 수 있는지 확인하는 데 도움이 됩니다.
미래 요구사항 체크리스트
- 향후 부하 및 트래픽을 예측하기 위해 잠재적 성장에 대한 정보를 수집합니다.
- 베이스라인 사례로부터 향후 필요한 한도까지 확장할 계획을 도출합니다.
- 예상 성장의 각 단계를 통해 사용자의 기대에 맞는지 확인하기 위해 부하 테스트를 만듭니다.
- 비용을 확인하고 얼마나 절감됐는지 확인하십시오!
자동 확장을 위한 인프라 설정
인프라를 클라우드로 이전할 때 얻을 수 있는 엄청난 이점은 인프라를 자동으로 확장 (auto scaling) 할 수 있다는 것입니다. 대부분의 퍼블릭 클라우드 공급자는 초당 요청, CPU 사용률, 시간 일정 또는 이 세 가지 모두의 조합과 같은 특정 조건에 따라 자동으로 확장할 수 있으므로 크기 조정에 대한 추측을 피할 수 있습니다.
Auto-scaling 그룹은 대부분의 클라우드 공급자에서 사용할 수 있습니다. 지정된 구성상의 제한 또는 매개변수를 기반으로 다양한 리소스에 유연성을 제공합니다. 새 인스턴스가 작동하기 전에 구동되는 데 지연이 있기 때문에 모든 문제를 해결하기 위해 자동 크기 조정에 완전히 의존하지 않고, 발생하는 구동 지연에 따라 인스턴스 크기를 조정하는 것이 중요합니다. 예를 들어, AWS에서는 기본적으로 지난 5분 이내의 지표를 기준으로 확장을 계산합니다. 이는 부하의 급증이 소비자의 급증가된 요청의 영향을 줄이기 위해 충분히 적시에 새 리소스로 실행 되지 않을 수 있음을 의미합니다. 대부분의 클라우드 서비스는, 물론 그 자체적인 문제가 있기는 하지만, 보다 즉시적인 반응적 확장을 허용하는 더 짧은 측정 기간(AWS는 1분)을 유료로 제공합니다.
Auto-scaling 그룹의 제한을 설정할 위치를 논의할 때 최소 인프라 요구 사항에 대한 시작점으로 베이스라인을 사용하는 것이 유용합니다. 그런 다음, 예상되는 미래 요구 사항보다 약간 높게 상한선을 설정하십시오.
수평적으로 확장하면 작동 준비가 된 새 인스턴스를 가져오는 데 시간이 지연된다는 문제가 있습니다. 확장은 즉각적이지 않기 때문에 수요를 충족하기 위해 확장에만 의존할 수는 없습니다. 작업을 실행할 수 있는 가장 작은 서버를 선택한 다음 필요에 따라 확장하지 마십시오. 더 나은 방법은, 대부분의 시간 동안 요구 사항을 처리하는 서버 구성을 찾고, 물론 비용을 고려하면서, 최대 피크 때의 활동을 처리할 수 있도록 확장을 설정하는 것입니다. 하루의 운영기간 동안 두 개의 인스턴스에서 최대 10개의 인스턴스로 여러 번 확장하는 경우라면, 위의 첫 번째 지점으로 돌아가 이 새롭게 가진 데이터를 기준으로 베이스라인을 재평가해야 할 때 일 것입니다.
운영 비용을 먹어치우는 또 다른 요소는, 특히 더 크고 비용이 많이 드는 인프라가 필요한 대규모 작업에서 확장 이벤트 중에, 자동 확장 이벤트 시에 아키텍처가 경험하게 되는 안정화 (stabilization) 및 휴지 기간 (cooldown period)입니다. 설정이 서버를 가동하기 시작하면 설정된 일정 기간 동안 활성 상태를 유지합니다. 이것은 때때로 안정화 기간으로 알려져 있는 것입니다. 예를 들어, 구글 클라우드(GCP)는, 이 글의 작성 시점에는, 기본적으로 10분으로 설정됩니다. 따라서, 서버가 가동되어 필요하지 않은 경우에도 GCP에서 10분 동안 실행되어 월별 요금이 추가됩니다. 안정화 기간 이후 서버가 쿨다운되는 휴지 기간은 몇 분 동안 지속될 수 있습니다. 이것 또한 월별 비용에 추가될 수 있습니다. 이러한 이벤트가 여러 확장 그룹에서 발생하면, 하루에 여러 번 발생하면, 월말에는 엄청난 비용에 놀랄 수 있습니다.
자동 크기 조정은 올바르게 사용하면 인상적인 기능이지만 위에서 언급한 함정에 주의하십시오. 계획을 정기적으로 감사하십시오. 더 높은 트래픽과 부하가 발생하면 베이스라인을 높이고 수요를 충족하도록 아키텍처를 확장하십시오.
오토 스케일링 체크리스트
- 최소 및 최대 Auto Scaling 요구 사항을 ‘현실적으로’ 살펴보십시오.
- 클라우드 공급자에 맞게 오토 스케일링 조정을 구성하십시오.
- 오토 스케일링 조정이 작동하는지 테스트 하십시오.
- 비즈니스 요구 사항에 따라 주기적으로 Auto Scaling 계획 조정
- 안정화 및 쿨다운 기간의 숨겨진 비용을 조심하십시오.
- 실제 비용을 확인하고 절감액을 점검 하십시오!
사용량을 모니터링을 통한 비용 절감
인프라 비용을 절약하고 계획이 제대로 작동하는지 확인하는 가장 좋은 방법은 여러분의 클라우드 공급자가 제공하는 보고서를 확인하는 것입니다. CPU 사용량을 보면 여러분의 추측이 트래픽을 과대평가했는지 여부를 비롯한 추세를 쉽게 확인할 수 있습니다.
사용 통계를 정기적으로 검사하는 것이 좋습니다. 새로운 인프라로 자주 수행한 다음, 시간의 진행에 걸쳐서, 또는 애플리케이션 사용자 또는 사용량이 특정 비율만큼 증가할 때 검사의 간격을 두십시오. 이것은 모두 여러분의 작업 설정 방법과 조직의 요구 사항에 따라 다릅니다. 핵심 사항은 사용량 모니터링이 인프라에 지출하는 비용이 잘 활용되고 있는지 확인하는 효과적인 방법이라는 것입니다.
발생하는 다양한 스케일링 이벤트를 알 수 있도록 알림을 설정할 수도 있습니다. 대부분의 클라우드 공급자는 이러한 알림을 설정할 수 있으며, 이것은 Auto-Scaling 인프라의 상태를 모니터링하는 데 큰 도움이 될 수 있습니다.
훌륭한 모니터링 및 보고의 또 다른 이점은 시스템을 확장하거나 업데이트하고 인프라 계획을 다시 거쳐야 할 때 베이스라인과 향후 요구 사항을 설정하는 데 도움이 되는 훌륭한 계측정보를 얻을 수 있다는 것입니다.
모니터링 체크리스트
- 필요하다면, 해당 월의 사용 보고서를 감사하도록 미리 알림을 설정합니다.
- 인프라 확장 이벤트에 대한 알림 설정
- 자문해 보십시오: 과거 사용량을 기준으로 베이스라인 시스템을 상향 조정하거나 하향 조정해야 합니까?
- 모니터링 보고서에 표시되는 추세와 일치하도록 Auto scaling 조정 구성을 변경합니다.
- 실제 비용을 확인하고 절감액을 점검 하십시오!
Tyk API 게이트웨이에 적용하세요!!
이제 인프라의 크기 조정을 살펴보았으니, 이 지식을 Tyk API 게이트웨이 인프라에 적용할 차례 입니다. 아래는 AWS 내의 다양한 서버 오퍼링, 상대적 비용 및 여러분이 달성할 수 있는 성능을 개략적으로 보여주는 표 입니다.
이제 여러분은 위에서 언급한 전술의 일부 또는 전부를 사용하여 시스템의 다른 구성 요소와 함께 Tyk의 인프라 크기를 정확하게 조정할 수 있습니다.
결론적으로 말하면, 인프라 크기 조정 요구 사항에 대해 현명하고 현실적이 되는 것은 적은 예산을 유지하거나 운영 비용을 줄이는 인상적인 방법입니다. 인프라는 필수입니다. 하지만, 필요하지 않은 것은 어떤 이점도 제공하지 않으면서 조직에 비용을 청구하는 거대한 아키텍처입니다. 적절한 규모의 인프라만 있으면 비즈니스를 성공시키고 성장시킬 수 있습니다.