서버리스 = 오토파일럿에서의 운영

자동화와 오케스트레이션을 위한 플랫폼이 필요합니다. 서버리스가 바로 여러분이 찾던 것일 수도 있습니다.

서버리스(일명. 서비스로서의 기능은 아직 초기 단계에 있습니다. 그리고 이제 막 그 기능을 찾은 기술은 "하지만 무엇에 유용할까?"라는 질문에 답해야 하는 경향이 있습니다. 특히, 거의 매일 새로운 개발이나 기술이 우리의 관심을 끌고 있는 시대에 이는 더욱 그렇습니다.

서버리스의 일반적인 사용 사례는 이미지 처리나 데이터 마이닝과 같은 특정 유형의 작업 부하에 클라우드의 힘을 활용하는 기능을 중심으로 이루어집니다. 하지만 오늘날 일부 조직에서는 운영 자동화와 같은 그다지 매력적이지 않은 목적으로 서버리스를 사용하고 있습니다.

사실 저는 서버리스가 오늘날 운영을 자동화하는 가장 효율적인 수단 중 하나라고 주장할 수도 있습니다. (저는 그렇게 주장할 거라고 생각합니다.) 운영 자동화 플랫폼으로 서버리스를 진지하게 고려해야 하는 이유는 다음과 같습니다.

1. 이벤트 중심입니다

이벤트 기반 시스템에서 동작은 일이 발생하게 합니다. 이벤트(때로는 액션 이라고도 함)는 여러 가지 방법으로 트리거될 수 있지만, 명령줄(예: 'curl')이나 간단한 웹 인터페이스를 통한 REST API 호출을 통해 호출되는 경우가 가장 많습니다. 여기에는 서비스 프로비저닝, 구성 업데이트, 방화벽 규칙 비활성화와 같은 작업이 포함됩니다. 기본적으로 애플리케이션을 프로덕션에 배포하는 것과 그에 따른 필수 네트워크 및 앱 서비스는 일련의 "작업"으로 분해됩니다. 파이프라인의 많은 작업은 이전 작업의 완료에 의해 트리거되며 이는 OpenWhisk 와 같은 서버리스 환경의 "작업 시퀀스" 개념에 잘 맞습니다. 결국 배포 오케스트레이션은 여러 개의 작은 개별 자동화 작업으로 구성된 프로세스를 자동화하는 것입니다. 각각은 서버리스 환경으로의 API 호출로 적절하게 표현될 수 있으며, 전체 시퀀스를 시작하는 포괄적인 API 호출이 있을 수 있습니다.

2. 코드 및 재사용으로 인프라를 촉진합니다.

템플릿과 스크립트는 코드로서의 인프라 개념에 부합하지만, 서버리스 기반 시스템은 본질적으로 이 기준을 충족합니다. 이렇게 하면 배포 아티팩트와 구조를 프로세스에 주입된 코드로 캡슐화하여 재사용을 더욱 촉진할 수 있습니다. 즉, 시간이 지남에 따라 측정하고 최적화할 수 있는 예측 가능하고 반복 가능하며 일관된 프로세스를 의미합니다. "한 작업, 한 기능" 접근 방식은 구성 가능성을 더욱 촉진하고 동적으로 생성된 파이프라인을 기반으로 다양한 기능을 주입하여 쉽게 구동할 수 있는 프로세스의 보다 유동적인 생성을 가능하게 합니다.

3. "서버리스"입니다

이제 우리는 모두 서버리스가 말 그대로 서버가 없는 것은 아니라는 것을 알고 있습니다. 하지만 기본 하드웨어(및 소프트웨어) 인프라가 그것을 사용하는 사람들에게는 "보이지 않는다는" 동일한 개념은 개발자에게 매력적으로 느껴지므로 인프라 및 네트워크 운영에도 매력적으로 느껴져야 합니다. 배포 파이프라인을 자동화하고 조율하기 시작하면 이를 관리할 소프트웨어와 시스템이 필요하다는 점을 기억하세요. 즉, 라이선스가 필요하고, 유지 관리하고, 관리하고, 확장하고, 보안을 유지해야 하는 서버와 소프트웨어가 필요하다는 뜻입니다. 소비자 대상 앱을 관리하는 것이 얼마나 힘든 일인지 이미 알고 계시겠지만, 운영 관련 앱도 마찬가지라고 상상해 보세요. 한 번 구축된 서버리스 인프라는 기본 인프라에 대한 걱정 없이 원하는 수의 워크플로를 구축할 수 있는 일관된 플랫폼을 제공합니다. 즉, 개발자를 서버리스로 끌어들이는 것과 동일한 이점을 운영에서도 실현할 수 있습니다.

4. 그것은 모든 것을 다룹니다 

그게 도대체 무슨 상관이냐고 생각할 수도 있을 겁니다. 글쎄요, 말씀드릴게요. 어떤 데이터 센터도 이기종 인프라에서 운영되지 않으며, 심지어 단일 공급업체의 하위 집합 내에서도 기업은 여러 모델과 버전의 하드웨어 및 소프트웨어를 실행합니다. 조직이 직면하는 과제 중 하나는 환경 전반에서 다양한 장치와 버전을 관리하는 것입니다. 대부분의 서버리스 환경은 이미 다양한 언어와 툴셋을 지원합니다(한 작업은 Python으로, 다른 작업은 node.js로 작성할 수 있음). 또한, 무엇이든 실행되는 컨테이너인 "이미지 기반" 작업도 지원합니다. 이렇게 다양한 시스템을 자동화하는 작업으로 구성된 프로세스를 조율하려는 세상에서 가장 잘 작동하는 도구(그리고 아마도 유일한 도구)를 사용할 수 있는 능력은 운영에 큰 도움이 됩니다.

문제는 소비자와 기업 사용자 모두가 끊임없이 액세스하고 사용하는 대부분의 애플리케이션과 달리 운영 작업은 드물게 실행되고 때로는(인정하고 싶지 않지만) 보안 또는 가용성 사고에 대한 대응으로 별다른 경고 없이 실행된다는 것입니다. 즉, 서버리스와 같은 이벤트 기반 시스템이 적합해 보입니다. 이는 전체 운영 스펙트럼에 걸쳐 다양한 작업을 실행할 수 있는 "항상 켜진" 플랫폼을 제공합니다. 어느 순간에는 보안 관련 작업(방화벽 규칙 업데이트)을 실행할 수도 있습니다. 다음으로, 즉각적인 시정이 필요한 제로데이 익스플로잇에 대한 대응으로 애플리케이션의 데이터 경로에 새로운 앱 서비스(예: WAF)를 주입하는 작업을 시작할 수 있습니다. 동일한 플랫폼은 자동화되고 확장 가능한 방식으로 필요한 모든 운영 작업을 실행할 수 있는 메커니즘을 제공할 수 있습니다.

이벤트는 Slack과 같은 ChatOps 지원 시스템에서 티켓 생성이나 봇 명령에 의해 트리거될 수도 있고, 티켓이나 명령에서 필요한 정보를 자동으로 가져와서 작업을 완료하는 데 적절한 작업을 호출할 수 있습니다.

서버리스는 개발자에게 초점을 맞추고 있지만, 기본 원칙과 메커니즘은 자체 운영 오케스트레이션 시스템을 구축하거나 자체적인 통합 및 운영상의 과제를 안고 있는 느슨하게 결합된 시스템 세트에 의존하는 것보다 매력적인 대안이 됩니다.

운영 자동화 여정을 막 시작했다면 엔터프라이즈용 서버리스 플랫폼을 면밀히 살펴보고 요구 사항에 얼마나 적합한지 확인하는 것이 좋습니다.