Kubernetes 애플리케이션을 위한 애플리케이션 서비스: 똑같은 오래된 새로운

VMS VAX 문제 해결에서 서버리스 마이크로서비스를 작성하는 것까지는 먼 길이지만(다만 re:Invent에서 AWS Lambda 에 COBOL 지원이 발표되면서 IT 레미케이트 의 첫 번째 라운드가 완료되었을 수도 있습니다).

그동안 많은 것이 바뀌었습니다. Perl로 스크립트를 해킹해서 어딘가에 존재하지 않는 디렉토리로 변경할 수 있게 해주는 운영 체제에 짜증이 났던 기억이 납니다(보너스: 그곳에 도착한 후에 디렉토리를 만들 수 있게 해줍니다). 이제는 문제를 해결하는 데 사용하는 시간만큼이나 문제를 해결하는 방법에 대한 결정을 내리는 데도 시간을 쓸 수 있는 듯합니다. 그리고 이건 정말 환상적이에요. 새로운 장난감들이 우리에게 선사하는 다양한 아키텍처, 개발 속도, 디지털 기회, 그리고 개발자의 창의성이 폭발적으로 늘어나는 것은 정말 멋진 일입니다. 프로시니엄 아치의 어느 쪽에 있든, 빌더와 소비자 모두 새로운 더 나은 앱을 즐기고 있으며, 그 속도와 기능은 얼마 전만 해도 공상과학에나 나올 법한 수준입니다.

컨테이너와 이를 주의 깊게 감시하는 Kubernetes 마인더가 적절한 예입니다. 컨테이너 기술은 의심할 여지 없이 애플리케이션 개발 폭발을 촉진하는 핵심 요소였습니다.

이번 주 햇살 가득한 시애틀에서는(이 글을 쓰는 날 오전 10시 46분 기준 [업데이트 - 오후 1시 36분 현재도 여전히 맑음]) 8,000명이 넘는 사람들이 모여 쿠버네티스와 기타 오픈소스 관련 기술에 대해 이야기하고, 듣고, 배우고 있습니다. 대화, 실습 학습, 자극의 혼합은 혁신의 핵심입니다. 당신이 이 글을 읽는 동안, 12개의 훌륭한 새로운 아이디어(그리고 37개의 끔찍한 아이디어)가 꿈꿔졌을 겁니다.

이러한 앱 중 일부는 삶을 바꿀 수도 있고, 일부는 건축을 혁신할 수도 있으며, 일부는 사용자 인터페이스를 발전시킬 수도 있고, 일부는 아마도 내가 청소년 문화와 얼마나 동떨어져 있는지를 보여주는 또 다른 방법이 될 수도 있을 것입니다.

하지만 몇 가지 요구 사항은 다양한 애플리케이션과 여기에서 사용하는 프레임워크를 통합하는 데 필요합니다. 해결책은 다르게 보일 수 있지만 모든 사람이 해결해야 할 중요한 구성 요소가 있습니다.

규모 – 크게 성공하려면 그 과정에서 커질 수 있어야 합니다(그리고 가끔은 다시 원래대로 돌아올 수도 있습니다).

안정성 – 모든 앱에는 적절한 수준의 안정성이 필요합니다. '무대 데모 통과'부터 생명을 위협하는 가동 시간 요구 사항까지 포함됩니다.

보안 – 나쁜 사람들이 존재하며, 때때로 그들은 귀하의 애플리케이션을 공격할 것입니다. 현대 시스템의 복잡성으로 인해 걱정해야 할 공격 표면 영역이 끊임없이 늘어나는 듯합니다.

관찰 가능성 – 보고 믿는 것이 중요하며, 문제가 있을 때는 이것이 두 배로 중요합니다. OSI 계층에서 적절한 정보를 적절한 사람에게 신속하게 전달하면 실패를 줄이고, 더 빨리 복구하고, '당신이 만들고, 당신이 운영한다'는 세상을 조금 더 편안하게 만드는 데 도움이 될 수 있습니다.

이러한 요구 사항은 그렇게 독특한 것은 아니지만 모든 잘 설계된 앱에서 해결해야 할 근본적인 문제이며, 이상적으로는 문제가 되기 전에, 코드 한 줄을 작성하기 전에 해결해야 합니다.

저의 존경하는 고용주인 F5 Networks는 이러한 요구 사항을 충족하면서 수십억 달러 규모의 사업을 구축했으며, 솔직히 말해서 저희는 그 일에 꽤 능숙합니다(하지만 저는 그렇게 말하고 싶습니다 ). 우리는 이런 필요를 충족시키기 위해 만든 것들을 애플리케이션 서비스 라고 부릅니다. 애플리케이션 트래픽을 보호하고, 검사하고, 지시하는 애플리케이션 서비스입니다. 클라이언트를 올바른 장소로 라우팅하는 애플리케이션 서비스, 주요 애플리케이션 원격 측정 데이터를 추출, 전달, 표시하는 애플리케이션 서비스입니다. 이것이 고객의 애플리케이션을 계속 작동시키는 핵심 서비스이며, 애플리케이션이 어디에서 어떻게 생성되었는지와 관계없이 계속해서 필요로 하는 서비스입니다.

공급업체 피치로 다시 돌아가볼까요?

지금까지는 '옛날식 기술이 여전히 유효하다고 나를 설득하려는 늙은이'였습니다. 좋아요, 공중에서 뒤집히고 꼬여 거꾸로 떨어진 것이 있습니다. 가장 중요한 것부터 시작해 보겠습니다. 서비스가 배포되는 방식.

플랫폼과 업무 관행 도입을 뒷받침하는 기술 중 하나는 의도를 자동화되고 통합된 방식으로 실행에 연결하는 시스템입니다. 애플리케이션 서비스도 이 체인의 일부가 되어야 하며, 이는 단순한 런타임의 변경보다 더 근본적인 변화를 나타냅니다.

때로는 서비스를 기존 구성 요소에 주입해야 합니다. 예를 들어 Aspen Mesh가 Istio 에 추가하는 뛰어난 가시성과 제어 기능이 그렇습니다. 또는 F5 컨테이너 커넥터 와 같은 연결 도구를 사용하면 환경을 서비스에 연결하여 Kubernetes 포드가 추가되거나 제거됨에 따라 보안, 확장 및 관찰할 수 있습니다.

이상적으로는, 애플리케이션 서비스를 생성하는 코드는 해당 애플리케이션의 코드와 동일한 저장소에 존재해야 하며, 동일한 방식으로 배포되어야 합니다. 애플리케이션 서비스 정의(예: 웹 애플리케이션 방화벽 서비스)는 코드로 존재해야 하며 코드로 처리되어야 합니다. 즉, 서비스 정의가 변경되고 소스 코드 관리에서 커밋되면 추가적인 인적 입력 없이 프로덕션 웹 애플리케이션 방화벽이 배포됩니다. 최근 뉴스에서 Airbnb의 입담 좋은 멜레인 세불라는 Kubecon 에서 수요일 기조연설에서 모든 서비스 구성 요소를 유지하는 것(단일 프로젝트에서 인프라 정의 포함, 앱 개발자의 삶을 편리하게 해주는 약 50가지의 다른 멋진 것들 포함)을 설명하면서 정확히 그 모델을 설명했습니다.

서비스 인스턴스의 이러한 변화(긴 IT 티켓 대기열의 환영스러운 사라짐과 더불어)는 극적이고도 명확합니다.

두 번째 변화는 조금 더 평범할 수도 있지만 여전히 중요합니다. 쿠버네티스와 컨테이너의 장점 중 하나는 환경 간의 이식성입니다. Kubernetes 관리 마이크로서비스는 지원되는 컨테이너 엔진이 있는 곳(힌트: 모든 곳)에서 실행되며, 동일한 앱 서비스도 거기에 있어야 하며, '어느 정도 동일'하거나 '약간 다른 인터페이스로 다른 방식으로 동일한 작업을 수행'하는 것이어서는 안 됩니다. 똑같아요. 즉, 우리가 파견해야 할 장소의 수는 계속 늘어나고 있다는 뜻입니다.

현재 및 잠재적인 모든 Kubernetes 배포와 동일한 방식과 동일한 장소에서 작업해야 하는 필요성은 F5의 지침 원칙이 되었습니다.

이는 절대적으로 중요합니다. 고객은 기존 앱의 확장성과 보안을 유지할 뿐만 아니라 이 글을 쓰는 시점까지 불량 카페인 분자가 운 좋은 아데노신 수용체에 결합하여 점심 식사 후 활력을 얻는 것으로 간주되는 앱을 보호하고 감시해야 한다는 것을 알아야 하기 때문입니다.