2020-03-09 게시 됨2020-03-09 업데이트 됨serverless18분안에 읽기 (약 2633 단어)

서버리스 배포 베스트 프랙티스(번역)

written by Fernando Medina Corey

이 튜토리얼의 대부분을 만들기 위해서는 Serverless Framework’s의 대시보드에 로그인 해야 한다: https://dashboard.serverless.com.

본인은 글을 모두 읽은 다음에 이 주석을 달고 있다. 베스트 프랙티스를 실행할 방법을 알려준 다음 Safeguard라는 Serverless Framework의 대시보드, 기타 등등 대시보드 기능으로 베스트 프랙티스를 실행하는 내용을 알려준다. 문제를 먼저 알려주고 해결하고 싶으면 우리 제품을 써보는 게 어떻냐는 약팔이 느낌도 있긴 하다.

Overview

너가 지속적으로 서버리스 애플리케이션들을 만들 때, 앱들의 복잡성과 범위는 계속 증가할 것이다. 그 성장은 버그를 최소화 하고, 앱의 보안을 유지하고, 개발을 더 빠르게 만들어주는 well-structured 된 practices들이 필요하게 만든다. 이 포스트는 다양한 서버리스 최선의 배포 방식들을 보여줄 것이다. 우리가 그것들을 복습하게 되면, 나는 또한 어떻게 너가 쉽게 이러한 케이스들을 너만의 서버리스 프레임워크 앱에 적용하기 위해 새로운 대시보드 Safeguards를 쓸 것인지 보여줄 것이다. 서버리스 대시보드에 익숙하지 않다면 이 문서를 참조해라

그럼, 몇 가지 배포의 Best Practices를 확인해보자.

보안

적절하게 비밀키를 관리해라

API 키, 데이터베이스 Credentials, 또는 다른 secrets들은 안전하게 저장되고, 안전하게 애플리케이션에 의해 접근될 필요가 있다. 몇가지 다양한 방법이 있는데 가장 중요한 것은 다음과 같다.

너의 secrets을 버전 관리(source control) 밖에 있도록 해라
secrets에 접근을 제한해라 (최소 권한의 원칙)
애플리케이션의 다른 스테이지에 대해 secrets를 분리해라

우리는 이전에 서버리스 프레임워크를 사용할 때 secrets를 관리하는 몇 가지 방법들을 논의한 적이 있는데, 이것은 아마 너에게 좋은 옵션이 될 것이다.

더 최근에는 우리는 너의 secrets를 다양한 서비스들, AWS 계정들, 애플리케이션의 스테이지를 포괄하는 관리를 할 수 있도록 Parameters를 붙였다. 너는 또한 애플리케이션의 serverless.yml에 환경 변수가 일반 텍스트로 설정되었을 때 배포가 안되도록 막기 위해 Safeguard polices를 사용할 수도 있다.

IAM 정책 허용을 제한하라

또 다른 중요한 best practice는 너가 너의 애플리케이션들의 허용 범위를 제한하는 것이다. AWS의 경우, 너가 너의 서비스들을 위한 IAM 정책들을 만들 때, 역할들을 애플리케이션을 수행할 수 있는 최소한의 권한만 줘야 한다. 이 부분의 일부로, 너는 와일드 카드(*: asterisk) 사용하는 것을 줄여야 한다. Safeguard policy를 활용하면, 와일드카드가 담긴 IAM permissions를 제한할 수 있다.

이 Safeguard policy를 통해 배포 자체를 막을 수도 있지만, 개발자에게 다른 방법을 찾아보라고 경고를 주는 정도로 할 수도 있다.

배포 시간을 제한해라

너가 블랙프라이데이 러쉬를 준비하는 이커머스 팀인 것을 상상해보자. 너는 너의 코드의 상태를 확신하지만, 너는 바쁜 기간의 새로운 버그가 생길 작은 가능성조차 제한하고 싶을 것이다. 한 가지 일반적인 방법은 이 기간 동안에는 너의 배포를 중단하고 걸어 잠그는 것이다. 주말에 전화 알람을 받고 싶지 않은 조직도 비슷한 상황이 발생하므로, 그들은 금요일과 월요일 오전에는 배포를 중단할 수 있다.

Safeguard는 너의 환경에 이 정책을 적용할 수 있게 해준다.

일관적인 컨밴션들

Stages

컨벤션 락. 그들은 개발자들이 기준점을 배우고, 직관적으로 시스템의 다른 부분들을 이해하도록 돕는다. 어디에나 있는 개발 컨벤션 중 하나는 소비자들이 보는 코드(프로덕션 스테이지)와 개발자들이 작업하는 코드(개발 스테이지)를 분리하는 것이다. 이렇게 스테이지를 분리하는 것은 너의 코드가 일관적인 방법으로 고객에게 이동하게 된다 (개발 스테이지 -> 프로덕션 스테이지).

서버리스 프레임워크에서는 기본적으로 너가 작업한 내용들이 너의 애플리케이션들이 dev 스테이지에 푸시된다. 그 다음 production을 위한 배포 준비가 됐을 때 serverless.yml을 업데이트 하는 것을 통해서 prod와 같은 스테이지로 배포할 수 있게 된다. 각 스테이지들에서, 너는 아마 아주 다른 설정들을 사용하고 싶을 것이다.

다행히도, 스테이지들과 상호작용할 때 너가 서버리스 대시보드로 할 수 있는 새로운 세분성들이 있다. 스테이지당 설정들은 아래와 같은 것들이 포함될 수 있다.

배포를 해야하는 AWS 계정, 지역, 스테이지들
배포에 대해서 Safeguard가 평가해야 하는 것들
어떤 파라메타들, 비밀키들이 사용되었는지

Safeguard를 사용해서 개발 단계의 배포를 차단하는 것 부터, 프로덕션 스테이지의 AWS 계정 까지 범위의 것들을 수행(설정 하는 것들)하거나, 너의 프로덕션 API 키들이 항상 Production에 묶이도록 할 수 있다. 이러한 옵션들은 필요와 워크플로우에 따라 너에게 지원을 주는 것에 대해서 아주 유연하게 된다.

승인된 지역들

지역적으로 분산된 팀에서 일하고 있을 때, 각 리전의 개발자들을 위한 기본적인 AWS 리전은 같지 않을 것이다. 시애틀에 있는 사람은 us-west-2에 잇고, 필라델피아에 있는 사람은 us-east-1을 사용할 것이다. 독립적으로 개발하고 있다고 하면, 이러한 차이들은 부주의에 따라서 어떤 이슈를 만들게 될 것이다. 하나의 서비스는 하나의 리전을 아마 참조하고 있다. 하지만 실제로 배포는 각자 될 필요가 있다. 또는, 다양한 리전들은 아마도 그에 맞게 지원되는 특징들, 제한들이 있을 수 있다.

위와 같은 이슈들을 피하기 위해서, 우리는 개발자들에게 하나의 지역 또는 하나의 지역의 서브넷만을 사용할 것을 요구한다. 그리고 당연히, Safeguard가 이런 보호막을 해줄 수 있다. (역주: … 기승전 Safeguard) 배포 시간에 너의 서비스가 특정 리전, 또는 리전들의 리스트에 배포되도록 제한해준다.

함수 이름과 설명들

스테이지와 리전 컨트롤의 조합 속에서, 너의 인프라 안에서 일관적인 이름과 설명들을 유지하는 것은 새로운 개발자들이 빠르게 서비스들을 파악하고, 어떻게 다른 앱 스테이지에 그것들을 연결할지 이해하고, 그리고 더 쉽게 빌드하고 디버깅할 수 있도록 도울 수 있다.

하나의 일반적인 패턴으로는 너의 람다 함수들이 모두 일관적으로 서비스 이름, 스테이지 그리고 함수 이름을 갖고 있는 것이다. 이것은 만약 그들이 같은 AWS 계정에 있다면 너에게 더 쉽게 관련된 함수들을 찾을 수 있게 한다. 그리고 더욱 빠르게 여러 함수들을 특정 서비스에 묶을 수 있도록 해준다.

유저에게서 컨텐츠를 제출받고 처리하고, 데이터베이스에 저장하고 인덱싱하는 하나의 서비스를 상상해보자. 그것은 아마 하나의 람다 함수가 제출에 대해 승인/거절하고 DynamoDB에 저장한다. 그리고 다른 하나는 ElasticSearch에 인덱싱한다. 만약 너가 이러한 간단한 아키텍쳐를 취하고, 개발, 운영 환경 모두에 퍼져있다고 하면, 너는 이미 네 개의 함수를 가지고 있는 것이다. 우리가 람다 함수 네이밍 컨벤션(serviceName-stage-fucntionName)을 따르고 있을 때, 위와 같이 하는 것을 더 쉽게 만든다. 이런 상황에서 네이밍은 다음과 같이 될 것이다.

newSubmissions-prod-submissionGrader
newSubmissions-prod-elasticsearchIndexer
newSubmissions-dev-submissionGrader
newSubmissions-dev-elasticsearchIndexer

이 방법으로 너는 정확하게 어떤 함수가 너가 필요한 것인지 알 수 있다. 만약 너가 새로운 개발자가 부적절하게 이름 지어진 서비스를 배포하지 않을까 걱정하고 싶지 않다면, 마찬가지로 Safeguard를 사용해 네이밍을 제한할 수 있다.

후기

Safeguard 광고를 번역했다. 유료 서비스는 아니라고 한다. 디테일한 프랙티스, 조금 Advanced한 Serverless Framework의 베스트 프랙티스를 위한 설정들 등을 기대하면서 읽었는데 아쉬움이 크다. 마지막에 Takeaways라는 “Safeguard와 우리 대시보드의 기능은 이게 다가 아니야~” 라는 내용이 있는데 이 부분은 그냥 생략했다. 도커 베스트 프랙티스와는 비교할 수 없는 의미없는 번역이 된 것 같다.