블로그

생산의 문제점과 이를 해소하는 애플리케이션 서비스

로리 맥비티 썸네일
로리 맥비티
2018년 3월 19일 게시
prod에서의 dev 문제점

수년간 우리는 '그것에 대한 앱이 있다'는 말을 들어왔습니다. 그리고 지금까지 저는 그것이 대체로 사실임을 알게 되었습니다. 앱이 필요할 거라고는 생각지도 못했던 것들에 대한 앱도 있어요. 하지만 제가 그것을 보고 찾아봤더니, 마치 마법 같았어요.

지금은 '그것에 대한 애플리케이션 서비스가 있습니다'라고 말하는 사람은 없지만, 어쩌면 그래야 할지도 모릅니다. 최소한 IT 분야에서는 그렇습니다. 내가 해야 할 일에 대한 앱이 종종 있는 것처럼, 개발자가 프로덕션 환경에서 해야 하거나 해결해야 할 일에 대한 애플리케이션 서비스가 종종 있기 때문입니다.

예를 들어 보안을 살펴보겠습니다. RisingStack 설문 조사에 따르면, 개발자들은 프로덕션에서 가장 큰 어려움으로 이를 꼽았습니다.

문제점: 보안

이제, 설문조사는 보안에 대해 정확히 무엇이 골치 아픈 일인지에 대한 세부 사항을 다루지 않았습니다(물론 질문을 한다면 매우 다양한 응답을 받을 것이라고 확신하지만요). 제가 아는 것은 2018년 애플리케이션 제공 현황 설문 조사에서 앱 역할(개발자) 응답자의 38%가 "공격의 정교화 증가"를 내년의 가장 큰 보안 과제로 꼽았다는 것입니다. 26%는 보안 부문에서 IT 기술이 부족하다고 답했고, 23%는 애플리케이션(특히 웹 앱)을 공격으로부터 보호하는 데 어려움을 겪는다고 답했습니다.

그런 관점에서 고통스러운 점을 본다면 (제 블로그니까 그렇게 하겠습니다) 그에 맞는 애플리케이션 서비스 가 있습니다 . 실제로는 여러 가지가 있습니다. 목표가 사실상 패치를 적용하거나 기존 취약점이 악용되는 것을 방지하는 것이라 할지라도요.

그런 사람들이 많이 있죠. 문제는 모든 침해, 모든 무단 접근, 모든 유출 데이터가 개발자의 탓으로 돌리는 경향이 있다는 것입니다. 심지어 취약점이 타사 라이브러리에 있었거나, 프로토콜 패킷이나 인터넷의 수백만 개(문자 그대로) 사이트에서 사용하는 플랫폼에 깊이 숨겨져 있었을 때에도 마찬가지입니다. 하지만 로리, 당신은 생각하죠. 라이브러리로 구성된 애플리케이션의 79%는 주의 깊게 검사한 결과 알려진 취약점의 2%에 불과합니다.

스택 취약점 대조 랩

하지만 가장 주목받는 침해 및 데이터 손실 중 일부는 수백만 명의 사람들이 공유하는 플랫폼과 공통 라이브러리의 취약성인 2%로 인해 발생했습니다.

웹 애플리케이션 방화벽 (저희가 매년 조사하는 30가지 애플리케이션 서비스 중 하나)은 공격자가 액세스 권한을 얻고 리소스를 소모하거나 데이터를 훔치는 데 사용하는 증가하는 포트폴리오와 두 가지 모두를 처리합니다. 앱 액세스 제어 역시 자격 증명(자체적으로 가치가 있음)과 애플리케이션 및 해당 데이터에 대한 보호 계층을 제공합니다. 주목할 점은 연례 설문조사에 참여한 모든 응답자의 75%가 온프레미스와 퍼블릭 클라우드 모두에서 애플리케이션을 보호하기 위해 앱 액세스 제어를 사용한다고 답했다는 점입니다.

문제점: 성능

마찬가지로 성능은 개발자가 항상 제어할 수 있는 것은 아닙니다. 앱 성능에 미치는 코드 표준의 영향은 장기적인 지속 가능성을 고려하는 것입니다. 때로는 가장 효율적인 데이터 구조나 구문을 사용할 수 없습니다. 나중에 그 코드를 유지 관리하고 수정해야 하는 사람이 있다는 걸 명심해야 합니다. 때로는 용량, 수요, 네트워크 상태, 10년 된 Windows ME PC를 포기하지 않는 고객 등 통제할 수 없는 변수의 영향이 있을 수 있습니다.

그런 문제점을 해결하는 애플리케이션 서비스도(실제로는 여러 개) 있습니다. TCP 최적화부터 캐싱, 압축, 값비싼 암호화 처리 오프로드까지 정말 다양한 옵션이 있습니다. 이러한 모든 애플리케이션 서비스는 성능을 향상시키고 사용자를 기쁘게 할 수 있습니다.

애플리케이션 서비스 2018년 1월

상당수의 사람들이 이미 앱을 더 빠르고 안전하게 실행하기 위해 이런 서비스를 사용하고 있으며, 성능과 보안의 문제점을 모두 해결하고 있습니다.

문제점: 전개

하지만 개발자들은 프로덕션 단계에서 보안이나 성능 문제만 고민하는 게 아니라, 앱과 애플리케이션 서비스를 프로덕션 단계에서 어떻게 실행하는지에 초점을 맞춘 배포 문제도 고민이라고 말했습니다.

이는 단일 애플리케이션 서비스 또는 일련의 애플리케이션 서비스로 해결할 수 없는 더 큰 문제입니다. 배포 문제를 해결하려면 자동화 및 오케스트레이션을 중심으로 한 보다 전략적인 이니셔티브가 필요하며 코드로서의 인프라와 같은 DevOps 아이디어를 수용해야 합니다.

개발자를 지원하기 위해 프로덕션에서 필요한 변경 사항을 배포하는 데 필요한 프로세스를 체계화하고 DevOps의 원칙과 방법론을 수용하려면 기존 NetOps를 전환하기 위한 협력적인 노력이 필요합니다.

즉, 인프라 공급업체는 API 지원 인프라를 제공해야 하며 CLI보다는 템플릿과 배포 아티팩트를 사용하는 보다 선언적인 모델에서 운영할 수 있는 기능을 지원해야 합니다.

개발자가 지적하는 세 가지 어려움 중에서 배포가 가장 해결하기 어려운 부분인데, 이를 해결할 수 있는 단일 도구나 기술이 없기 때문입니다. IT를 수동으로 구동되는 배포 모델에서 미래의 자동 조립 라인 방식으로 전환하려면 협업과 일치된 노력이 필요합니다.

개발자의 고민을 해결하는 데 어려움이나 용이함에 관계없이, 사실 세 가지 모두 프로덕션에서 NetOps를 통해 해결할 수 있습니다. 풍부한 애플리케이션 서비스를 제공하든 내부 디지털 혁신에 더욱 전념하든 NetOps는 모든 사람에게 프로덕션으로의 전환을 덜 고통스럽고 더 성공적인 경험으로 만들 수 있습니다.