MVP에서 서버 없는 프로덕션 준비까지

전 직장 생활에서 저는 창업회사에서 일했습니다. 소프트웨어 제품을 구축할 때 속도와 규모의 이분법을 만났습니다.창업자들은 제품의 첫 번째 교체를 구축할 때 흔히 "... 우리는 아직 규모 문제에 접근하지 못했기 때문에 우리가 그곳에 도착했을 때 이 점을 걱정하게 된다"는 태도를 취한다.이 소프트웨어의 첫 번째 버전은 신속하게 구축되고 발표된 것이다. 엔지니어들은 그들이 근본적으로 신속하게 교체되는 기초가 없고 시간문제일 뿐이라는 것을 깨달았다.불가피한 것은 그들 자체의 인프라 시설의 한계로 인해 개발 주기가 느리고 마감일이 불가능하며 창조력과 기능성을 유지하는 압력이 너무 크다는 것이다.나를 믿어, 나는 줄곧 거기에 있었어.
초창기 기업에서 이런 문제들을 대규모로 해결하는 데 필요한 자원을 찾는 것은 불가능하지 않아도 어렵다.나는 서버가 없는 것이 이 도전에 대한 아주 좋은 대답이라는 것을 발견했다.나는 제리미 데리가 이 점을 잘 정리했다고 생각한다.
"서버 없이는 기본 컴퓨팅 리소스의 유지 관리 및 운영에 대한 걱정 없이 고객에게 가치를 제공하는 데 집중할 수 있습니다."
이 글에서 저는 Courier에서 우리가 가장 좋아하는 서버가 없는 이야기를 탐색하고 서버가 없는 기초 지식을 되돌아보고 서버가 없는 것이 어떻게 우리 팀으로 하여금 더 적은 자원으로 더 많은 임무를 완성하게 하는지 탐색하고 싶습니다.아마도 이러한 사고를 통해 당신은 서버가 없는 환경을 더욱 잘 이해하고 다음 프로젝트나 창업 회사에 적합한지 확인할 수 있을 것이다.

화폐화 60일

내가 Courier에 가입했을 때, 나는 왜 창시자인 트로이 굿(Troy Goode)이 서버 없는 기술을 사용하기로 결정했는지 궁금했다. 왜냐하면 이것은 비교적 새로운 기술로 활발한 개발자로 구성된 작은 지역사회를 가지고 있기 때문이다.질문할 때 그는 "Ruby on Rails나 Django의 속도, 그리고 Kubernetes의 규모"를 찾고 있으며 그 중 하나를 선택할 필요가 없다고 말했다.서버 프레임워크가 없는 것이 적합합니다.트로이는 팀으로서 Courier의 강력한 송신 채널을 구축하여 잠재적 고객을 유치하고 개발 후 60일 이내에 결제 계좌를 만들 수 있다.이것은 나에게 있어서 믿을 수 없는 흥분이며, 작은 단체가 생산 준비를 매우 빨리 할 수 있다는 생각도 검증되었다.
더욱 인상적인 것은 우리 송신관의 핵심 설계가 지난 18개월 동안 기본적으로 변하지 않았다는 것이다.이것은 우리로 하여금 밑바닥 인프라 시설이 아니라 특정한 고객 용례에 전념할 수 있게 한다.이 기금회는 우리에게 양호한 서비스를 제공하여 우리가 계속 신속하게 발전하고 고객의 피드백에 응답할 수 있도록 한다.

S3는 저희 친구예요.

Courier에서 우리는 S3의 열렬한 팬입니다.모든 새로운 기능과 서비스가 해마다 쏟아지는 것 같아서 S3는 제대로 사랑받지 못했다.99.9%의 가동 시간 보장, 매우 간단한 API와 저렴한 비용으로 볼 때 사랑할 만한 것이 뭐가 있겠는가!
내가 Courier에서 배운 가장 좋아하는 디자인 모델 중 하나는 웹 서비스 to S3 모델이다. 왜냐하면 그것은 유연성과 간단성을 가지고 있기 때문이다.

시간이 많이 걸리는 처리를 관리해야 하지만, 그 처리가 끝날 때까지 기다리고 싶지 않을 때, 이 모델은 매우 적합하다.이 예에서 웹 서비스는 http 요청을 Request Store라는 S3 메모리 통에 넣습니다.이것은 Worker라는 Lambda 함수를 터치하고 요청을 다른 처리할 서비스로 보낼 수 있습니다.
이것은 서버 없는 프레임워크에서 특히 설정하기 쉽다.먼저 클라우드를 사용하여 S3 bucket을 정의해야 합니다.

resources:
 Resources:
   RequestStore:
     Type: AWS::S3::Bucket
     Properties:
       AccessControl: PublicRead

그런 다음 S3 트리거 이벤트를 사용하여 lambda 함수를 정의합니다.

Worker:
 events:
   - s3:
       bucket:
         Ref: RequestStore
       event: s3:ObjectCreated:Put
 handler: handlers/worker.default

나는 잠시 후에 이 목록을 인용하고 코드를 보면서 시스템을 시각화하는 것을 좋아한다.
S3의 또 다른 강력한 용례는 DynamoDB를 사용하여 400KB의 프로젝트 제한을 피하는 것이다.다이나모에 대형 프로젝트 속성을 저장해야 할 때 이를 대상으로 Amazon S3에 저장한 다음 대상 인용을 다이나모 프로젝트에 저장할 수 있습니다.
Courier의 많은 장소에서 이런 방법은 모두 유용하다는 것이 증명되었지만, 결코 균형이 없는 것은 아니다.이 정책은 업무를 지원하지 않기 때문에 프로그램이 발생할 수 있는 모든 고장이나 오류를 처리해야 합니다.

발전기 흐름에서 오는 람바다 병목 현상

서버 없는 개발의 흥미로운 점은 서비스의 사용 상황에 따라 이를 미세하게 조정할 수 있다는 것이다.Courier에서, 이것은 우리가 관건적인 로그 기록 서비스의 성능 문제를 발견한 후, 필요에 따라 진행된 것이다.이것은 문제가 있는 설계의 간략화이다.

이 장면에서, 우리는 몇 가지 서비스를 다이나모표에 쓸 수 있다.이 테이블은 일괄 레코드 스트리밍을 lambda 함수로 전송하며, 이 함수는 UI 조회를 위해 이 레코드를 Elastic에 기록합니다.추가 조사를 통해 우리는 lambda의 교체기 나이가 끊임없이 증가하여 UI에 성능 문제가 발생하는 것을 발견하였다.
우리가 이 이야기의 원만한 결말로 넘어가기 전에, 우리는 몇 가지 용어를 신속하게 정의할 것이다.lambdas batchSize는 이벤트 흐름 조각에서 읽은 기록 수입니다.lambda의 교체기 나이는 클라우드 워치 지표로 일괄 처리의 마지막 기록에 사용된 시간을 측정하는 데 사용된다.우리의 lambda가 새로운 사건을 처리하고 있기 때문에 교체기의 나이도 증가하고 있습니다. 이것은 배압 때문에 모든 신기록을 처리하는 데 더 많은 시간이 필요하다는 것을 의미합니다.다시 말하면, 점점 더 많은 기록이 표에 기록되면서, 이 기록들은 UI에 도달하는 데 더 오랜 시간이 걸린다는 것이다.
제품의 사용량이 증가했기 때문에 이것은 해결해야 할 큰 문제이자 상대적으로 간단한 해결 방안이다.AWS에서는 Lambda의 이벤트 소스에 따라 Lambda 이벤트를 트리거할 로깅의 볼륨 크기를 정의할 수 있습니다.대량 크기를 제외하고parallelizationFactor를 정의할 수 있습니다. 파편마다 여러 개의 병렬 lambda 호출을 제공합니다.예를 들어 Parallelization Factor가 2로 설정된 경우 100개의 조각을 처리하는 데 200개의 병렬 Lambda 튜브를 사용할 수 있습니다.서버 프레임워크가 없는 덕분에 lambda가 정의한 이벤트 부분에서 두 개의 파라미터를 정의하는 것처럼 간단합니다.

LambdaWorker:
   events:
     - stream:
         type: dynamodb
         arn:
           Fn::GetAtt:
             - DynamoTable
             - StreamArn
         batchSize: 1
         parallelizationFactor: 5
   handler: handlers/lambda.worker

내장된 클라우드 워치 지표와 AWS 서비스의 구성 가능성 때문에 AWS와 Serverless는 이런 상황을 더욱 쉽게 처리할 수 있다.lambda를 재배치한 후, 우리는 거의 즉시 배압이 완화되는 것을 보았고, 우리의 하루를 시작했다.

녹지: 자동화

처음부터 새로운 프로젝트를 시작하는 것은 사람을 흥분시킨다.낙관적인 분위기가 높아지면서 창조적인 토론과 혁신의 기회가 많다.내가 Courier에 가입했을 때, 나는 운 좋게도 CTO Seth Carney와 함께 Automations라는 새로운 녹지 프로젝트를 이끌었다. 이 프로젝트는 사용자들이 메시지를 보내는 방식과 시간을 더욱 잘 통제하도록 하기 위해서였다.
우리는 사용자가 분리된 작업 정의에서 자동화를 정의할 수 있도록 하기 시작했고, 나중에 그것을 단계라고 명명했다.이러한 절차를 처리하기 위해서 우리는 간단하지만 효과적인 작업 처리 시스템을 설계하였다.

우선, 우리는 앞에서 언급한 신뢰할 수 있는 웹 서비스부터 S3 디자인 모델에 이르기까지 전송된 자동화 정의를 신속하게 검증하고 이를 S3에 저장하여 사용자에게 응답을 되돌려준다.아직 어떤 작업도 처리되지 않았고 검증된 작업만 있다.우리는 사용자가 응답을 받기 전에 전체 자동화의 실행을 기다리는 것을 원하지 않는다.
그런 다음 RequestWorker가 요청을 받아 각 작업이 정의된 순서대로 처리됩니다.다른 서비스를 시도한 후에 우리는 SQS를 작업 프로세서로 선택했다. 왜냐하면 처리량이 무한하고 DLQ를 사용하여 메시지를 다시 시도할 수 있기 때문이다.마지막으로 이벤트 로드의 작업 정의를 통해 JobWorker를 트리거합니다.그 역할은 작업의 정의에 따라 작업을 수행하고 다음 작업을 줄을 서는 것이다.SQS 대기열을 정의하고 SQS 트리거가 있는 Lambda는 앞서 정의한 웹 서비스 to S3 모드와 유사합니다.
먼저 CloudFormation을 사용하여 큐를 정의합니다.

resources:
 Resources:
   JobQueue:
     Type: AWS::SQS::Queue
     Properties:
       VisibilityTimeout: 60

그런 다음 lambda 함수를 정의하고 SQS 트리거 이벤트를 사용합니다.

JobWorker:
 events:
   - sqs:
       arn:
         Fn::GetAtt:
           - JobQueue
           - Arn
 handler: handlers/worker.default

재미있어 보이는 이 문법에 주의해라.이를 클라우드 형성 내재 함수라고 하는데 이것은 AWS 자원의 기초 ID를 검색하는 방법이다.Google S3 트리거 예시에서 이렇게 할 필요가 없습니다. 이것은 구름이 형성하는 괴벽입니다.어떤 서비스가 어떤 내재적인 기능을 필요로 하는지 추적하기 어려워서 나는 이것을 발견했다.연취에서 온 조언이 도움이 됐어요.
우리는 일주일 안에 이 구조를 설계하고 실현하며 발표할 수 있다.한 팀에서 실시한 것을 감안하면 나는 이 성과에 대해 매우 자부심을 느낀다.그때부터 우리는 자동화를 위해 더 많은 서비스, 특성과 기능을 추가했지만 첫 번째 실현은 동료와의 좋은 업무 관계를 열었을 뿐만 아니라 나에게 서버 구동 인프라가 없는 진정한 가치를 증명했다.
작성자: Chris Gradwohl
Serverless는 자신의 도전과 좌절이 없는 것이 아니다.어쨌든 서버가 없는 것은 이미 내가 제품과 회사를 구축하는 데 가장 좋아하는 방식이 되었다.시장의 불확실성과 빠른 교체의 수요에 직면할 때 나는 서버가 없는 것을 선택하면 내장 규모의 거대한 개발 속도를 실현할 수 있다고 생각한다.당신은 서버가 없는 것에 대해 어떤 견해를 가지고 있습니까?나는 네가 이러한 서버가 없는 이야기를 좋아하길 바란다. 나는 네가 그 속에 몰입할 능력이 있다고 생각하고 서버가 없는 것으로 다음 프로젝트를 구축하기를 바란다.