프로덕션 등급 Kubernetes로 복잡성 감소
일반적으로 컨테이너와 Kubernetes를 사용하는 마이크로서비스 아키텍처(MSA)는 디지털 경험의 출시 시간을 단축하여 비즈니스 성장과 혁신을 촉진합니다. 기존 아키텍처와 함께 또는 독립 실행형으로 이러한 최신 앱 기술을 사용하면 뛰어난 확장성과 유연성, 더 빠른 배포, 심지어 비용 절감까지 가능합니다.
2020년 이전에 대부분의 고객이 이미 디지털 혁신 전략의 일부로 마이크로서비스를 채택하기 시작했지만 코로나 대유행으로 인해 앱 현대화가 진정으로 가속화되었다는 사실을 알게 되었습니다. NGINX 사용자에 대한 2020년 설문조사에 따르면 응답자의 60%가 프로덕션 환경에서 마이크로서비스를 사용하고 있으며 이는 2019년의 40%에서 증가한 수치이며 컨테이너는 다른 최신 앱 기술보다 2배 이상 인기가 있습니다.
목차
1. 문화, 복잡성, 보안
1-1. 문화(Culture)
1-2. 복잡성(Complexity)
1-3. 보안(Security)
2. Solution: 프로덕션 등급 Kubernetes
2-1. 클러스터 안팎으로 트래픽을 가져오기 위한 확장 가능한 ingress-egress tier
2-2. 클러스터 전체의 위협으로부터 보호하는 내장 보안
2-3. 클러스터 내에서 트래픽을 최적화하기 위한 확장 가능한 east-west traffic tier
3. NGINX가 도움이 되는 방법
3-1. 자동화(Automation) – 앱을 더 빠르고 안전하게 출시
3-2. 보안(Security) – 기존 및 새로운 위협으로부터 고객과 비즈니스를 보호합니다.
3-3. 성능(Performance) – 고객과 사용자가 기대하는 디지털 경험 제공
3-4. 통찰력(Insight) – 비즈니스를 발전시키고 고객에게 더 나은 서비스를 제공하십시오.
1. 문화, 복잡성, 보안
Kubernetes는 CNCF(Cloud Native Computing Foundation)의 2020년 설문 조사에서 입증된 바와 같이 컨테이너화된 앱 관리를 위한 사실상의 표준으로, 응답자의 91%가 Kubernetes를 사용하고 있으며 그 중 83%는 프로덕션 환경에서 사용하고 있습니다. Kubernetes를 채택할 때 많은 조직이 상당한 아키텍처 변경에 대비하지만 최신 앱 기술을 대규모로 실행하는 조직의 영향에 놀랐습니다. Kubernetes를 실행하는 경우 다음 세 가지 비즈니스 크리티컬 장벽이 모두 발생했을 수 있습니다.
1-1. 문화(Culture)
앱 팀이 애자일 개발 및 DevOps와 같은 현대적인 접근 방식을 채택하더라도 일반적으로 “조직은 자체 커뮤니케이션 구조를 반영하는 시스템을 설계한다”는 Conway의 법칙을 따릅니다. 즉, 분산 애플리케이션은 독립적으로 운영되지만 리소스를 공유하는 분산 팀에 의해 개발됩니다. 이 구조는 팀이 빠르게 실행할 수 있도록 하는 데 이상적이지만 사일로(silo) 구축을 권장하기도 합니다. 결과에는 빈약한 커뮤니케이션(자체적으로 결과가 있음), 보안 취약성, 무분별한 도구, 일관되지 않은 자동화 관행 및 팀 간의 충돌이 포함됩니다.
1-2. 복잡성(Complexity)
엔터프라이즈급 마이크로서비스 기술을 구현하려면 조직에서 가시성, 보안 및 트래픽 관리를 제공하는 중요한 구성 요소 제품군을 통합해야 합니다. 일반적으로 팀은 이러한 요구 사항을 충족하기 위해 인프라 플랫폼, 클라우드 네이티브 서비스 및 오픈소스 도구를 사용합니다. 이러한 전략 각각에 적합한 위치가 있지만 각각에는 복잡성을 야기할 수 있는 단점이 있습니다. 그리고 단일 조직 내 여러 팀이 동일한 요구 사항을 충족하기 위해 서로 다른 전략을 선택하는 경우가 너무 많아 “운영 부채”가 발생합니다. 또한 팀은 특정 시점에서 프로세스와 도구를 선택하고 컨테이너를 사용하여 최신 마이크로 서비스 기반 애플리케이션을 배포하고 실행하는 것과 관련된 변화하는 요구 사항에 관계없이 계속 사용합니다.
CNCF 클라우드 네이티브 인터랙티브 랜드스케이프는 마이크로서비스 기반 애플리케이션을 지원하는 데 필요한 인프라의 복잡성을 잘 보여줍니다. 조직은 인프라 종속, 섀도 IT, 도구 확산 및 인프라 유지 관리를 담당하는 사람들을 위한 가파른 학습 곡선을 포함하는 결과와 함께 다양한 이종 기술에 익숙해져야 합니다.
1-3. 보안(Security)
링 펜스(ring-fence) 보안과 같은 전략은 Kubernetes에서 실행 가능하지 않기 때문에 보안 요구 사항은 클라우드 네이티브 및 기존 앱에서 크게 다릅니다. 대규모 생태계와 컨테이너화된 앱의 분산 특성은 공격 표면이 훨씬 더 크다는 것을 의미하며, 외부 SaaS 애플리케이션에 대한 의존도는 직원과 외부인이 악성 코드를 삽입하거나 정보를 유출할 기회가 더 많다는 것을 의미합니다. 또한 문화 및 복잡성 영역에서 설명하는 결과(특히 도구 확산)는 최신 앱의 보안 및 복원력에 직접적인 영향을 미칩니다. 동일한 문제를 해결하기 위해 에코시스템에서 서로 다른 도구를 사용하는 것은 비효율적일 뿐만 아니라 각 구성 요소를 올바르게 구성하는 방법을 배워야 하는 SecOps 팀에게 큰 도전이 됩니다.
2. Solution: 프로덕션 등급 Kubernetes
대부분의 조직 문제와 마찬가지로 Kubernetes의 문제를 극복하는 방법은 기술과 프로세스의 조합입니다. 이 가이드 문서의 나머지 부분에서는 기술 구성 요소에 중점을 둘 것이지만 프로세스 및 기타 주제에 대한 향후 가이드 문서를 계속 주시하십시오.
Kubernetes는 오픈소스 기술이므로 구현하는 방법이 많습니다. 일부 조직에서는 고유한 기본 Kubernetes를 사용하는 것을 선호하지만 대부분은 Amazon Elastic Kubernetes Service(EKS), Google Kubernetes Engine(GKE), Microsoft Azure Kubernetes Service(AKS)와 같은 서비스에서 제공하는 유연성, 규범성 및 지원의 조합에서 가치를 찾습니다. ), Red Hat OpenShift Container Platform 및 Rancher.
Kubernetes 플랫폼을 사용하면 쉽게 시작하고 실행할 수 있습니다. 그러나 그들은 깊이보다는 서비스의 폭에 중점을 둡니다. 따라서 한 곳에서 필요한 모든 서비스를 얻을 수 있지만 대규모 생산 준비에 필요한 기능 세트를 제공하지는 않을 것입니다. 즉, 고급 네트워킹 및 보안에 중점을 두지 않습니다. Kubernetes가 많은 고객을 실망시키는 부분입니다.
Kubernetes를 프로덕션 등급으로 만들려면 다음 순서로 세 가지 구성 요소를 더 추가해야 합니다.
2-1. 클러스터 안팎으로 트래픽을 가져오기 위한 확장 가능한 ingress-egress tier
2-2. 클러스터 전체의 위협으로부터 보호하는 내장 보안
클러스터 외부(outside)에서는 “거친” 보안으로 충분할 수 있지만 클러스터 내부(inside)에서는 “세밀한” 보안이 필요합니다. 클러스터의 복잡성에 따라 유연한 WAF(웹 애플리케이션 방화벽)를 배포해야 하는 세 위치가 있습니다. Ingress Controller, Service별 Proxy 및 Pod별 Proxy. 이러한 유연성을 통해 청구와 같은 민감한 앱에 더 엄격한 제어를 적용하고 위험이 낮은 곳에서는 더 느슨한 제어를 적용할 수 있습니다.
2-3. 클러스터 내에서 트래픽을 최적화하기 위한 확장 가능한 east-west traffic tier
이 세 번째 구성 요소는 Kubernetes 애플리케이션이 기본 도구가 처리할 수 있는 복잡성 및 규모 수준 이상으로 성장한 경우 필요합니다. 이 단계에서는 클러스터 내의 애플리케이션 서비스에 보다 세분화된 트래픽 관리 및 보안을 제공하는 오케스트레이션 도구인 Service Mesh가 필요합니다. Service Mesh는 일반적으로 컨테이너화된 애플리케이션 간의 애플리케이션 라우팅 관리, 자율적인 mTLS(서비스 간 상호 TLS) 정책 제공 및 시행, 애플리케이션 가용성 및 보안에 대한 가시성 제공을 담당합니다.
이러한 구성 요소를 선택할 때 이식성과 가시성을 우선시하십시오. 플랫폼에 구애받지 않는 구성 요소는 팀이 학습하고 보호할 수 있는 도구가 줄어들고 비즈니스 요구 사항에 따라 워크로드(workload)를 더 쉽게 이동하여 복잡성을 줄이고 보안을 개선합니다. 가시성과 모니터링의 중요성은 아무리 강조해도 지나치지 않습니다. Grafana 및 Prometheus와 같은 인기 있는 도구와의 통합은 인프라에 대한 통합된 “단일 창” 보기를 생성하여 고객이 문제를 발견하기 전에 팀이 문제를 감지할 수 있도록 합니다. 또한 프로덕션 등급 Kubernetes에 반드시 필요한 것은 아니지만 최신 앱 개발의 필수 부분인 다른 보완 기술이 있습니다. 예를 들어 조직이 기존 앱을 현대화할 준비가 되었을 때 첫 번째 단계 중 하나는 API Gateway로 마이크로서비스를 구축하는 것입니다.
3. NGINX가 도움이 되는 방법
당사의 Kubernetes 솔루션은 플랫폼에 구애받지 않으며 프로덕션 등급 Kubernetes를 활성화하는 데 필요한 세 가지 구성요소, 즉 NGINX Ingress Controller를 Ingress-Egress 계층(tier)으로, NGINX App Protect를 WAF로, NGINX Service Mesh를 east-west 계층(tier)으로 포함합니다.
이러한 솔루션은 다음과 같은 4가지 핵심 영역에서 귀하를 지원함으로써 Kubernetes를 가장 친한 친구로 만들 수 있습니다.
3-1. 자동화(Automation) – 앱을 더 빠르고 안전하게 출시
NGINX Service Mesh의 NGINX Plus 사이드카(Sidecar) 자동 배포와 결합된 NGINX Ingress Controller의 트래픽 라우팅 및 앱 온보딩 기능을 사용하여 앱을 배포, 확장, 보호 및 업데이트하십시오.
3-2. 보안(Security) – 기존 및 새로운 위협으로부터 고객과 비즈니스를 보호합니다.
NGINX Service Mesh 및 NGINX Ingress Controller를 사용하여 서비스 간 종단 간 암호화를 관리하고 시행하는 동안 클러스터의 모든 위치에 NGINX App Protect를 배포하여 잠재적인 실패 지점을 줄입니다.
3-3. 성능(Performance) – 고객과 사용자가 기대하는 디지털 경험 제공
다른 WAF, Ingress Controller 및 로드 밸런서를 능가하는 NGINX 솔루션으로 성능 저하 없이 트래픽 급증 및 보안 위협을 손쉽게 처리합니다.
3-4. 통찰력(Insight) – 비즈니스를 발전시키고 고객에게 더 나은 서비스를 제공하십시오.
NGINX Ingress Controller 및 NGINX Service Mesh에서 앱 성능 및 가용성에 대한 대상 인사이트(Insight)를 얻고 마이크로서비스(Microservices) 앱에서 요청이 처리되는 방식을 이해하기 위한 심층 추적을 사용합니다.
댓글을 달려면 로그인해야 합니다.