맞춤형 빌드를 배포하기 위해 서버리스 컴퓨팅으로 전환한 이유

게시 됨: 2018-11-22
서버리스 클라우드 컴퓨팅을 위한 서버 설정.

Pexels의 panumas nikhomkhai 사진

퍼포먼스 마케터가 더 많이, 더 적게, 걱정 없이 할 수 있도록 하기 위한 우리의 약속의 일환으로 TUNE의 팀은 항상 고객에게 서비스를 제공할 수 있는 새로운 방법을 찾고 있습니다. 이 경우 솔루션 엔지니어링 팀은 플랫폼에서 맞춤형 빌드를 배포하고 지원하는 방법을 단순화하는 기술을 발견했습니다. 결과적으로 그들은 이제 더 많은 고객과 협력하여 필요한 솔루션을 구축하는 데 더 많은 시간과 더 적은 비용을 할애할 수 있습니다.


TUNE에서는 네트워크와 광고주가 코드를 한 줄도 작성하지 않고도 즉시 디지털 마케팅 캠페인, 게시자 관계, 지불금 등을 관리할 수 있도록 하는 유연하고 포괄적인 성능 마케팅 플랫폼을 제공하는 것을 자랑스럽게 생각합니다. . 그러나 때때로 다른 완전 관리형 SaaS 시스템과 마찬가지로 고객은 소매를 걷어붙이고 이전 코드 편집기를 실행해야만 달성할 수 있는 사용자 지정 구성, 기능 또는 통합이 필요합니다. 최근에 우리는 이러한 솔루션을 구축하는 방식을 바꾸고 있는 새로운 기술인 서버리스 컴퓨팅으로 전환했습니다.

이 게시물에서는 사용자 지정 개발에서 직면한 문제, 서버리스 빌드 프로세스를 설정하기 위해 취한 단계, 이 새로운 방법론이 비용 및 규모 문제를 어떻게 해결하는지 살펴보겠습니다.

과제: 맞춤형 솔루션에 대한 수요 충족

TUNE에서 솔루션 엔지니어링 팀을 처음 시작했을 때 각 맞춤형 고객 빌드를 별도의 빌드로 취급했습니다. 이러한 빌드의 대부분에는 일반적으로 플랫폼에서 사용자 지정 페이지로 배포되는 프런트 엔드 구성 요소와 서버, 데이터베이스 및 서버를 최신 상태로 유지하는 데 필요한 기타 인프라로 구성된 백 엔드 구성 요소가 있습니다. - 날짜 및 운영.

처음에는 이 방법론이 효과가 있었습니다. 몇 가지 복잡한 사용자 정의 빌드로 구성된 소규모 린 팀을 보유함으로써 각 빌드에 대해 서로 다른 서버를 프로비저닝하고 구성하는 방법이 효과적이었습니다. 이를 통해 우리는 고객을 위한 놀라운 경험을 할 수 있었습니다.

그러나 빌드 수가 증가함에 따라 문제가 발생하기 시작했습니다.

  • 서버가 너무 많습니다! 상상할 수 있듯이 빌드당 최소 2개의 상자를 프로비저닝하면 서버가 너무 많아졌습니다. 엄청난 수의 서버와 그에 수반되는 모든 어려움(예: 보안 업데이트 및 백업)으로 인해 우리가 인정하고 싶은 것보다 더 많은 시간이 소요되었습니다.
  • 해당 서버를 유지하십시오. 각 서버가 자체 엔티티이기 때문에 각 서버가 항상 가동되고 작동하는지 확인하는 책임이 있었습니다.
  • PHP는 저에게 적합하지 않습니다. 대부분의 빌드는 기본 Docker PHP 이미지에서 실행됩니다. 그러나 우리 팀이 성장하면서 우리는 사람들이 파이썬 마법사였을 때 PHP 5.0으로 고객 빌드를 작성하도록 강요하는 것이 의미가 없다는 것을 알게 되었습니다.
  • 이것은 점점 비싸지고 있습니다. 모든 서버가 ec2/RDS에 배포되면서 상당한 월별 비용이 발생하기 시작했습니다.
  • 안전 제일. 이러한 서비스는 민감한 고객 데이터를 처리하므로 해당 데이터의 보안을 보장하기 위해 공개 URL에 대한 인증 방법을 제공해야 했습니다.
  • 크론은 강합니다. 많은 백엔드 서비스가 cron 스크립트로 구성되어 있었고 이를 효율적으로 관리할 방법이 없었습니다.

이러한 문제가 대두되면서 고객 빌드에 백엔드 기능을 제공할 수 있는 더 간단하고 비용 효율적인 방법을 찾아야 한다는 것을 알게 되었습니다. 그러나 많은 토론과 솔루션에 대한 명확한 선두주자가 없는 후에 아이디어가 바닥나기 시작했습니다. (또한 새로운 커스텀 빌드에 대한 수요가 미친 듯이 증가함에 따라 시간은 확실히 우리 편이 아니었습니다.)

솔루션: 구조를 위한 서버리스 컴퓨팅

서버리스 컴퓨팅 대해 들어본 적이 없다면 처음 들었을 때와 똑같은지 궁금할 것입니다. 서버 없이 어떻게 코드를 실행할 수 있습니까? (걱정하지 마세요. 프로그래밍에 대한 기본적인 이해는 여전히 정확하며, 이 글을 쓰기 전에 해피 아워 스페셜을 남용하지 않았습니다.)

"서버리스" 는 새로운 기술에 대해 정말 혼란스러운 용어입니다. 왜냐하면 어리석은 말은 하지 않겠습니다. 분명히 여전히 서버가 코드를 실행하고 있기 때문입니다. 그렇다면 서버리스란 정확히 무엇 입니까?

서버리스 컴퓨팅은 클라우드 공급자가 서버 역할을 하여 기계 리소스 할당을 동적으로 관리하는 클라우드 컴퓨팅 실행 모델입니다. 위키피디아

서버리스 클라우드 솔루션을 사용하면 서버와 관련된 번거로움을 생각하지 않고 애플리케이션과 서비스를 구축하고 실행할 수 있습니다. 기본적으로 서버리스 컴퓨팅을 사용하면 가장 잘하는 일인 코드 작성을 할 수 있습니다.

서버리스 설정 프로세스

서버리스 기술의 작동 원리를 보여주기 위해 이 기능을 설정하는 데 사용한 단계를 살펴보겠습니다.

참고: 서버리스 기능을 갖춘 많은 클라우드 제공업체가 있습니다. 이 예에서는 AWS Lambda 를 사용 합니다.

    1. 먼저 새 Lambda 함수를 생성하고 " Blueprints ." 를 선택합니다. 그런 다음 키워드 필드에 " http "를 입력하고 Python 또는 Node microservice-http-endpoint를 선택합니다. (청사진은 더 빠르게 개발할 수 있도록 미리 제작된 코드 블록입니다. 정말 멋지죠?) 선택했으면 " 구성 "을 클릭하십시오 .
      AWS Lambda에서 기능을 구성하는 방법.

      AWS Lambda에서 기능을 구성하는 방법.

    2. 기능 이름과 역할을 추가합니다. 그런 다음 보안 옵션 " API 키로 열기 "로 API 게이트웨이 트리거를 선택합니다 . 이 API 게이트웨이는 Lambda 함수를 트리거할 공개 URL을 제공합니다. API 키를 추가하면 인증 방법이 제공되므로 적극 권장합니다.
      AWS Lambda에서 개방형 API 게이트웨이 키 설정.

      AWS Lambda에서 개방형 API 게이트웨이 키 설정.

    3. 함수를 생성하고 나면 이제 코드를 구성할 수 있습니다. 보시다시피 청사진은 Dynamo 테이블 과 상호 작용할 수 있는 멋진 진입점 후크를 이미 제공 했습니다(데이터베이스를 추가하려는 경우). 공개 URL이 로드되면 lambda_handler 아래에 있는 모든 것이 실행됩니다. 데이터베이스도 추가 중이므로 Dynamo로 이동하여 데이터베이스를 생성해 보겠습니다.
      AWS Lambda에서 Dynamo 데이터베이스 테이블 생성.

      AWS Lambda에서 Dynamo 데이터베이스 테이블 생성.

    4. Dynamo 테이블이 생성되면 공개 URL에서 이 Lambda 함수를 호출해 보겠습니다. 함수로 돌아가서 상단의 " API 게이트웨이 " 아이콘을 클릭합니다. 엔드포인트와 API 키가 이미 생성되었음을 확인해야 합니다.
      AWS Lambda 함수에서 API 게이트웨이 아이콘을 찾을 수 있는 위치입니다.

      AWS Lambda 함수에서 API 게이트웨이 아이콘을 찾을 수 있는 위치입니다.

    5. 이제 터미널을 열고 " x-api-key" 헤더 아래에 API 키를 추가한 다음 TableName 쿼리 문자열 매개변수 아래에 생성한 테이블 이름을 추가합니다.
      터미널에 키와 데이터베이스 이름을 입력하여 AWS Lambda에서 서버리스 빌드 설정을 완료합니다.

      완료하려면 터미널에 키와 데이터베이스 이름을 입력하십시오.

그게 다야! 이제 데이터베이스에 연결된 안전한 작동하는 백엔드가 있습니다. 간단한 다섯 단계만 거치면 됩니다.

서버리스 컴퓨팅이 우리의 과제를 해결한 방법

이제 서버리스 빌드를 설정하는 방법을 보여 주었으므로 이 클라우드 기반 모델이 문제 체크리스트에 대해 어떻게 작동하는지 살펴보겠습니다.

  • 서버가 너무 많습니다! 서버리스 ... 더 이상 서버가 없다는 뜻이겠죠?
  • 해당 서버를 유지하십시오. 서버리스 컴퓨팅은 클라우드 제공업체에서 관리하므로 이러한 제공업체가 서버를 모니터링할 수 있는 이점을 얻을 수 있습니다. Sherlock Holmes를 플레이하고 싶은 분들을 위해 Cloudwatch 에서 함수에 의해 출력된 모든 서버 로그를 볼 수도 있습니다 .
  • PHP는 저에게 적합하지 않습니다. 서버리스 모델을 사용하면 C#, Python, NodeJS, Go 및 Java로 작성할 수 있습니다.
  • 이것은 점점 비싸지고 있습니다. 서버리스 솔루션을 사용하면 실행 시간(100밀리초당)과 전송된 데이터 양을 기준으로 비용이 측정됩니다. 서버가 유휴 상태인 시간을 포함하는 월별 지불과 달리 사용한 만큼만 지불하면 됩니다. 100ms 실행당 0.000000208달러의 저렴한 비용으로 서버리스 컴퓨팅을 사용하면 상당한 현금을 절약할 수 있습니다.
  • 안전 제일. 서버리스는 안전한가요? 내장 API 키 인증 시스템을 사용하면 확실합니다.
  • 크론은 강합니다. Cloudwatch에 기본적으로 구축된 cron 관리 시스템을 사용하여 시간 창을 설정하고 잊어버리십시오. Cloudwatch는 모든 로깅 및 실행을 처리합니다.

마지막 생각들

여기 TUNE의 솔루션 엔지니어링 팀에게 서버리스 컴퓨팅으로의 전환은 게임 체인저였습니다. 사용 용이성, 비용 절감 및 민첩한 친화적 기능은 모든 신규 고객 빌드를 처리하는 방식을 변경했습니다. 서버리스 클라우드 기반 솔루션은 서버 측 컴퓨팅의 세계를 변화시킬 것입니다. 나는 당신에 대해 모르지만 한 가지 확실한 것은 TUNE 솔루션 엔지니어링 팀이 준비되어 있다는 것입니다.

TUNE 플랫폼 과 당사가 제공하는 맞춤형 개발 서비스 에 대해 자세히 알아 보려면 전문 서비스 페이지 를 방문하십시오 .