언제까지 실시간 서비스에 AWS ALB로 Health Check 5초 기다리실 거에요?

1. AWS ALB Health Check

AWS ALB Health Check는 AWS에서 제공하는 여러 가지 서비스에서 사용되는 모니터링 기능입니다. 클라우드 인프라와 애플리케이션 상태를 지속적으로 확인하여 가용성 및 성능을 유지하고, 서비스 중단이나 요청 실패를 줄이는 데 도움을 줍니다. AWS에서는 Route 53, Elastic Load Balancer(ELB), Amazon ECS 등 다양한 서비스에서 Health Check를 제공합니다.

1-1. AWS ALB Health Check 구성

성능 비교를 위한 테스트 환경은 다음과 같습니다.

1. Instances

2. Load Balancer

3. Target Group

테스트를 진행하기 위해 2개의 Instance를 생성하였고, Load Balancer 및 Target Group을 각각 하나씩 생성하였습니다.

1-2. AWS ALB Health Check의 기본값 분석

1. Target Groups 탭에서 생성한 Target Group을 선택한 뒤, Health Checks 블록을 클릭하면 현재 Health Check의 설정을 확인할 수 있습니다.

오른쪽의 Edit을 클릭하여 설정 편집에 들어가 자세한 값을 확인합니다.

다음은 Edit 클릭 후 AWS ALB Health Check 설정의 기본값(default setting) 입니다.

Health Check 할 프로토콜은 HTTP이고 경로는 / 로 설정되어 있는 것을 확인할 수 있고, 아래에 Advanced health check settings를 클릭하여 자세한 구성을 확인합니다. 다음은 AWS Health Check의 기본 구성입니다.

따라서 AWS Health Check의 기본값은 다음과 같습니다.

• Health check port – Load Balancer 가 대상에 대한 Health Check를 수행할 때 Target Group과 동일한 포트를 사용합니다.

• Healthy threshold – 연속 5번의 Health Check를 성공하면 정상으로 간주합니다.

• Unhealthy threshold – 연속 2번의 Health Check를 실패하면 비정상으로 간주합니다.

• Timeout – 5초동안 응답이 없으면 Health Check 실패로 간주합니다.

• Interval – Health Check는 30초에 한 번 이루어집니다.

• Success codes – 응답 성공시 상태 코드 200을 나타냅니다.

여기서 중요한 점은 AWS Health Check의 기본 구성을 변경하지 않고 사용한다면 Health Check를 30초에 1번 실행한다는 것입니다. Health Check를 30초에 1번 진행한다면 30초의 긴 시간 동안 서버나 애플리케이션에서 발생하는 문제를 실시간으로 감지하는데 상대적으로 느릴 수 있습니다. Health Check 간격이 길어질수록 많은 문제점들이 생깁니다.

관리자는 서버나 리소스에 대한 대응이 늦어지게 됩니다. 이로 인해 서비스 제공 업체의 관리 및 모니터링 작업에서 지연이 발생하며, 즉각적인 조치가 요구되는 문제를 빠르게 대응하지 못할 수 있습니다. 이는 곧 사용자들에게도 영향을 미치며 실패한 서비스와 계속되는 로딩 및 요청 실패 등의 문제에 직면할 가능성이 높습니다. 이 외에도 많은 문제점이 발생할 수 있으므로 이를 고려하여, Health Check의 간격을 적절히 조절하여 안정성과 성능을 유지할 필요가 있습니다.

1-3. AWS Health Check 최적화하기

AWS Health Check 설정을 변경하여 최적화하겠습니다. 다음과 같이 설정할 수 있는 제한이 아래에 표시되어 있습니다. 이에 맞게 최솟값으로 변경합니다. 해당 비교에서는 다음과 같이 수정하였습니다.

AWS Health Check의 Interval 최솟값은 5초입니다. 이 5초가 느린 시간은 아닙니다. 하지만 실시간 서비스가 중요하거나 높은 수준의 가용성이 요구되는 서비스를 운영하는 기업 같은 경우는 이 5초 또한 길 수 있습니다. 예를 들면 다음과 같습니다.

• 금융 서비스 – 주식 거래 플랫폼, 금융 거래 및 실시간 분석 시스템과 같은 금융 서비스는 네트워크 지연 시간에 매우 민감하며, 신속한 거래 처리와 데이터 신뢰성이 중요합니다.

• 응급 서비스 – 응급 의료 서비스나 긴급 상황 대응을 위한 통신 시스템과 같은 응급 서비스는 시스템 가용성이 매우 중요하며, 짧은 Health Check Interval 값이 필요합니다.

• 스트리밍 서비스 – 실시간 스트리밍 서비스, 게임 서비스 및 고화질 동영상 스트리밍 플랫폼 들에서는 실시간 서비스 가용성이 중요합니다.

이 외에도 Health Check를 빠르게 설정해야 하는 기업이나 서비스들은 5초라는 시간은 느린 편에 속합니다. 이런 고객들이 AWS Health Check를 사용하려고 하면 문제가 생길 수 있습니다. 만약 고객이 Health Check를 1초에 한 번 즉, Interval 값을 1로 지정해야 하는 고객일 경우 다음과 같은 문제가 발생합니다.

AWS Health Check에서 제공하는 범위가 5~300초 이기 때문에 1초로 설정할 수 없습니다.

출처 : www.nginxstore.com
--------------------------------------------------------------------------------------------

www.nginxkorea.co.kr 도 많이 사랑해주세요.

nginx plus 에 대한 문의 사항이나 기타 궁금하신 사항

www.nginxkorea.com/contact 로 언제든지 방문해주시면

무료 상담이 가능하다는 사실 알려드릴게요.

NGINX USER INTERVIEW 2탄 - GO NGINX !

NGINX 사용 경험과 NGINX로의 전환 과정

NGINX 사용 기간 및 용도
저는 약 2년간 NGINX를 사용해왔습니다. 주로 리액트-익스프레스 애플리케이션의 웹서버로 활용하고 있으며, 리버스 프록시와 SSL/TLS 설정에도 사용하고 있습니다. 최근에는 온프레미스 애플리케이션을 클라우드 아키텍처로 전환하는 작업을 진행 중인데, 앞으로는 NGINX를 통해 로드밸런싱 작업도 수행할 예정입니다.

NGINX 운영 환경

NGINX를 운영하는 환경은 주로 엔클라우드와 AWS의 클라우드입니다.

회사에서 NGINX를 도입한 이유 및 장점
회사는 가벼운 리소스 사용량과 업계 표준으로 자리잡은 점 때문에 NGINX를 도입하여 운영하고 있습니다. 아파치와 비교했을 때, NGINX는 훨씬 적은 리소스를 사용하면서도 높은 성능을 발휘하기 때문에 선택하게 되었습니다.

NGINX 사용으로 얻은 이점
NGINX를 사용하면서 가장 큰 이점은 운영 효율성입니다. 빠른 응답 속도와 적은 리소스 사용 덕분에 클라우드 환경에서 비용 절감 효과도 누리고 있습니다.

주요 프로젝트 및 기술적 도전 과제
기억에 남는 프로젝트 중 하나는 아파치 웹서버와 톰캣 애플리케이션 서버를 사용하는 애플리케이션에 프로메테우스와 그라파나를 설치하면서 NGINX를 도입한 사례입니다. 이 과정에서 NGINX를 통해 SSL/TLS 인증서를 자동 갱신하도록 설정하고, 동적 라우팅과 리버스 프록시를 사용해 리액트 환경에서의 CORS 정책을 우회하는 작업을 수행했습니다.

NGINX 운영 중 겪은 문제점 및 해결 방법
NGINX를 운영하면서 큰 문제는 없었습니다.

대부분 구글링을 통해 해결 가능한 사소한 설정 문제들이었기 때문입니다.

앞으로의 계획
앞으로는 아직 특별한 계획은 없지만, 현재 진행 중인 클라우드 아키텍처 전환 작업과 관련해 NGINX의 기능을 더욱 확장하고 활용할 방안을 계속 모색하고 있습니다.

클라우드 환경에서도 필요한 NGINX 를 알고 싶으시다면,

www.nginxkorea.co.kr 에 가입하셔서 상담 한번 받아보세요.

NGINX 텀블러 증정이벤트 기간입니다!

GO NGINX!!!

한 번에 기업 내부정보 싹 털어가는 API 공격, 어떻게 대응하나

최근 API 공격 동향, 보안 인증 우회로 기업 및 고객정보 탈취
API와 관련된 보안 위협은 오래 전부터 꾸준히 있어 왔지만, 최근 동향은 인증과 권한을 우회하거나 이를 도용해 기업의 중요 정보나 고객 정보를 탈취하는 게 주를 이루고 있다. API의 고유 특성을 보면, 과거 ‘웹 공격’은 UI를 통해 단계적으로 로그인을 진행해 중요한 정보가 모여 있는 페이지에 접근하는 방식이었다면, ‘API 공격’은 1차 접근 권한인 로그인 과정만 거치면 곧바로 내부 정보에 접근할 수 있도록 된 구조이기 때문에 한 번의 공격만으로 중요한 정보를 손쉽게 탈취할 수 있다. ‘API 로직’이란 로그인이 가능한, 권한을 받은 자만 데이터에 접근하는 것을 의미하며, API 공격은 로직을 깨고 권한을 넘어선 접근과 이로 인한 공격이 가능하다.

최근 API 보안 솔루션은 기존 기능에 머신러닝 엔진을 채택해 API를 학습하며 고유 로직을 확인해 이를 넘어서는 공격을 막을 수 있다. 특히, 학습 알고리즘에 출력물을 미리 제공하지 않고 스스로 찾아내는 비지도 학습을 적용한다. API를 분류할 때는 알고 있는 API에서 접근하게 되는데, 이 같은 방식으로는 실제 API를 분석했을 때 관리 영역에 포함되지 않는 API도 다수 발견되기 때문이다. 관리범위 밖에 있는 API 공격도 국내외 곳곳에서 발생하고 있기 때문에 관리되고 있는 API, 관리되지 않는 API 모두 챙기고 관리하는 것이 중요하다.

지난해 가트너(Gartner)가 발표한 API 보안 리포트는 현재 출시돼 있는 API 주요 기능으로 △가시화 : 어떤 API를 사용하고 있는지 인식하는 것 △이상징후 : 특정한 공격이나 우회접근을 통한 비인가자의 공격이 없는지를 파악하는 것 △조치 프로세스 : API는 개발보안과 연계돼 있어 코드 수정이나 아키텍처 변경 등 위협자 차단 과정을 자동화하거나 유기적으로 연결하고 개선하는 행위 △개발 테스트 : 시스템 가동 전 모의해킹 공격 등 런타임 테스트를 개발 플랫폼과 연결하거나 유기적인 작동을 위한 자동화 행위 등을 꼽았다.

F5는 머신 러닝을 사용하여 사용자 여정 전반에서 중요한 엔드포인트와 트랜잭션에 대한 진실과 의도를 정확하게 판단함으로써 자동화된 공격과 수동 사기를 차단합니다. 동일한 기술로 전체 사용자 여정에서 실제 고객을 사칭하기 위해 사기꾼이 사용하는 수동 공격도 방지한다.

10 분 데코톡은 사랑입니다 ♥

이 영상만큼 nginx 에 대해 쉽게 설명하는 개념 영상이 없는 것같습니다.

정말 최고 good! 피케이님 감사드립니다.

2024 0313 NGINX KOREA 밋업 (뒤늦은) 후기

2024. 03. 13 (수) 밋업 행사를 다녀왔습니다~!

첫번째 세션에서는 김재홍 상무님께서 Nginx Gateway Fabric 을 소개하는 시간을 가졌습니다.

많은 개발자분들이 참석해주셨고, k8s(kubernetes Ingress Controller) 의 세계에서

Nginx 의 운영사례를 적용해보고 기존 Ingress 제품에 Gateway API 구현을 끼워 넣는 것에 대한

단점들을 상쇄할 만한 기능들을 설명해주셨습니다. 자체 Gateway API 프로젝트로서 NGINX Gateway Fabric은 쿠버네티스 환경을 변화시키려 노력하고 있고 기존의 쿠버네티스 ingress controller 에 비해 서비스 네트워킹의 많은 요소의 표준화에 그 강점이 있다고 합니다. 이번 밋업을 통해 더욱 느끼게 된 사실은 F5가 NGINX를 통해 많은 개발자들에게 굉장히 가치가 있는 서비스를 많이 하고 있고, 특히나 NGINX 의 오픈소스의 강점들을 살리면서 NGINX 상용화 버전에서 실제 기능적으로 어떤 부분들이 더 필요한지에 대해 함께 많이 생각해보는 시간이 되었습니다. 너무 유익하고 재미있는 시간이었습니다.

많은 분들의 식을 줄 모르는 열정과 열기에 이번 밋업 참가에 대한 감회가 남달랐고 정말 좋았습니다.

다음 nginx 밋업도 기대가 되네요~!

그 전에 다음 밋업 참가를 위해 NGINX 공부를 열심히 더 해야 겠다는 생각이 들었어요 ㅎㅎ

nginx 와 관련한 더 자세한 내용을 알고 싶으시다면,

www.nginxkorea.co.kr

피케이의 Nginx

[10분 데코톡] 피케이의 Nginx 영상입니다.

뒷북이지만, 행사안내 겸 올리겠습니다~ 꼭 보세YO

역삼 구글캠퍼스에서 진행한 쿠버네티스 유저그룹 기술 세미나 & 10주년 기념행사가 2024년 06월 13일에 개최되었습니다. 10주년 기념을 맞이하여 이날에는 K8S 떡과 음료를 제공해줘서 좋았습니다.

첫번째 세션에는 F5 코리아의 김재홍님의 발표가 있었습니다. NGINX Gateway Fabric 기술에 대하여 설명을 해주셨는데, 애플리케이션 전달과 성능 향상에 있어서 NGINX Gateway Fabric 기술이 어떻게 활용될 수 있는지에 대한 종합적인 이해를 얻었고, Ngixn Gateway Fabric 기술에 대해 알아가는 유익한 시간이 되었습니다.

이후 유지연님의 Kyverno 오픈소스 정책 엔진에 대한 발표는 K8S 클러스터에서 정책관리 구현을 고민하는 참가자들에게 도움이 될 것 같았습니다.

저는 이번 행사를 통해 NGINX Gateway Fabric 기술에 대한 관심이 있었고, NGINX Gateway Fabric 프로젝트를 시작하게 된 이유를 발견했습니다. 세션을 통해 Gateway API가 전체 Kubernetes 환경을 변화시킬 가능성에 대해 더 기대하게 되었고, 전체 제품 클래스가 더 이상 필요하지 않을 수도 있고 새로운 제품이 등장할 수도 있지만, Gateway API는 워낙 풍부한 가능성을 제공하기 때문에 발표 내내 집중하지 않을 수 없었습니다.

이전의 Kubernetes Ingress 패러다임에 비해 특히 이번 Gateway API의 큰 개선점 중 하나는 서비스 네트워킹의 많은 요소의 표준화에 있다고 합니다. 늦은 포스팅이지만, 올해 쿠버네티스 탄생 10주년을 축하드리며 마무리 하겠습니다~ 정말 뜻깊은 행사였습니다.

다음에 K8S 가 기대되는 행사입니다.

서버 운용할 때 트래픽 리스크 관리 어떻게 하고 있어요?

서버 트래픽 리스크를 제거하고 성능을 극대화 하는 방법

세계적으로 가장 바쁜 웹사이트들은 NGINX를 사용합니다.

그렇다면 왜 Nginx일까요?

트래픽을 분산 , 관리 및 표준화로

트래픽 양이 증가하는 동안에도 웹사이트 성능이 더욱 안정적으로 유지된다면?

트래픽 처리 성능을 극대화 하기 위한 팁들 모두 준비했습니다.

Nginx 에 대한 다양한 Usecase들을 알고,

사이트에서 운용에 대한 꿀팁들을 얻어가세요.

사이트로의 트래픽 흐름의 최적화를 기대하세요.

• 트래픽 분산을 최적화 하고 서버 리소스를 사용할 수 있는 다양한 알고리즘을 사용하는 정교한 로드밸런싱

• 트래픽을 관리하고 배포하는 능력의 향상

다양한 USECASE와 인터뷰들이 있습니다.

www.nginxkorea.co.kr