개념글 모음

요약


백엔드 구현은


1. 제공하려는 서비스를 컴퓨터공학적 개념에 맞춰서 분할

2. 이들에 가장 들어맞는 서비스나 오픈소스 프로젝트를 선택

3. 이들 사이의 연계 로직과 필요한 비즈니스 로직을 작성


아... 가끔씩 듣는 질문인데 정말 어려운 질문이다.


우선 컴퓨터에서 서버는 어떻게 정의할 수 있을까? 자주 사용하는 방법인 언어학을 가져와서 이야기하는 수법을 써 보자면, 역할이 정의한다고 할 수 있다. 영어에서 품사는 위치가 정의한다. 동일한 eye라는 단어가 명사의 자리에서는 '눈'을 뜻하지만, 동사의 자리에 가면 '집중하다' '보다' 와 같은 '눈'이라는 명사의 뜻에서 파생된 의미를 갖는다.


클라이언트 컴퓨터나 서버 컴퓨터나 다 동일한 컴퓨터다. 차이가 있으면 클라이언트는 서비스를 제공하고, 서버는 같은 컴퓨터에 사용자가 원하는 서비스를 제공하기 위한 역할이 맡겨져 있단 것일 뿐, 근본적으로는 동일하다.


즉 백엔드는 이 컴퓨터와 서비스들을 엮어서 서버라고 하는 추상적인 기능의 집합체를 만들어 내는 것이다. 따라서 백엔드에서 담당하는 역할들로 백엔드에서 수행하는 기능을 보자.


서버는 클라이언트에서 수행하는 것이 불가능한 수준의 연산을 하거나, 다른 사용자들과의 정보를 연계하거나, 사용자의 정보를 보관하고 필요한 시점에 다시 제공하는 역할을 수행한다.


유튜브는 사용자가 올린 컨텐츠와 그 반응을 연계하는 것을 서버에 담당시킨다. 당근마켓은 서로 다른 사용자가 올린 정보들을 중계해 주는 역할을 한다. ChatGPT는 사용자의 텍스트 정보를 수신해 종단 기기가 수행할 수 없을 규모의 연산을 처리한 결과를 다시 클라이언트로 보내준다. 드롭박스는 사용자의 파일을 안전하게 수신해, 협업하는 사람들이나 원 고객에게 다시 제공하는 역할을 수행한다.


서버의 역할이 슬슬 감이 올 것이다.


1. 사용자로부터 정보를 수신한다.

2. 일련의 보관 및 처리 과정을 거친다. 다른 사용자와 연결해주는 과정 또한 포함된다.

3. 사용자에게 유의미한 응답을 보내준다.


그럼 이걸 하기 위해서 서버에서 사용할 수 있는 기술들에는 어떤 것이 있을까? 아마존 웹 서비스에서 제공하는 유의미한 서비스들로 한번 파악해보자. AWS 기준으로 설명했지만 수많은 퍼블릭 클라우드에도 동등한 기능들이 있다.


1. 사용자들로 받은 어마어마한 규모의 바이너리 정보를 '저장' 하고 싶다면: S3(바이너리 저장 서비스)

S3는 아마존 웹 서비스에서 제공하는, Simple Storage Service의 줄임말이다(S가 3번 나와서 S3라고 줄여 부른다). S3는 비유하자면, 컴퓨터에게 있어서 보조기억장치와 같은 역할을 수행한다. 더 쉽게 말하자면 클라우드 서비스에서 사용하는 하드디스크라고 봐도 무방한다(보조기억장치의 대세가 SSD로 넘어갔음에도 불구하고 HDD로 비유한 이유는 후술한다). 물론 실제로 하드디스크 자체를 서비스로 제공하는 건 아니고, 파일을 더 용이하게 관리하기 위한 기반 시스템들이 묶여 제공된다. 아무튼 '정적'으로 '파일을 저장' 할 수 있다는 면에서는 공통점이 있다. 여러분이 파일을 서버로 업로드하는 기능을 구현한다면, 실제 로직을 담당하는 부분들에서 이 바이너리 파일과 사용자 인증 정보를 받은 후, 적법한 권한이 있다면 S3에 파일을 저장하거나 읽어오는 AWS SDK의 API를 통해 사용자에게 이 바이너리를 제공하게 된다. 그걸로 끝이다.


2. S3보다 빠르게 사용자에게 정적 에셋들을 제공하고 싶다면: CloudFront

CloudFront는 CDN이다. 앞서 이야기한 S3나 후술할 많은 서비스들은 대부분 HTTP요청을 받은 다음, 이에 걸맞는 HTTP 응답을 제공한다. CloudFront는 그 사이에 끼어서, 해당 HTTP 통신의 클라이언트 요청과 이에 따른 응답을 캐싱한다. 그렇다면 CloudFront는 단순히 연산과 요청에 따른 비용을 절약하고 응답속도를 빠르게 하는 것일까? 물론 그렇지만 또 다른 지역적 응답속도를 높이는 역할 또한 한다.


S3와 같은 상대적으로 복잡한 로직을 수행하는 서비스를 제공하기 위한 유닛들은 사용자와 지근거리에 위치하기가 힘들다. 반면에, CloudFront는 그보다 더 단순하게, 요청에 따른 응답을 빠르게 제공한다는 훨씬 단순한 목적을 갖기 때문에 대규모 데이터센터가 아니라도 상대적으로 중소규모의 데이터센터에도 위치할 수가 있다. CloudFront는 이와 같이 사용자와 상대적으로 더 가까운 장소에 해당 역할을 수행할 수 있는 서버가 위치할 수 있기에(실제로 AWS, GCP, Azure 모두 협력사를 통해 사용자와 최대한 가까운 거리에 이와 같은 컴퓨터들이 구축되도록 직접 소규모 데이터센터를 차리기도 하고 협력사를 통해서 이와 같은 컴퓨터들을 배치한다), 네트워크 경로상으로도 훨씬 더 사용자에게 속도상 이점을 줄 수가 있다. CDN이 Contents Delivery Network라고 불리는 이유다. 네트워크 단위의 캐시라고 생각해도 무방하다(앞에서 속도상의 차이를 느낄 수 있도록 HDD에 S3를 비유한 이유다). 쉽게 말해 대형 데이터센터를 유통망에서의 도매점, CDN은 소매점이라고 생각해도 된다.


3. 실제로 구동 가능한 로직들을 배포할 연산 자원이 필요하다면: EC2

EC2는 Elastic Cloud Compute의 줄임말인데, 쉽게 말해서 메모리와 프로세서가 달려 있고 운영체제가 달린, 가상의 컴퓨터를 임대해주는 서비스이다. 가상의 컴퓨터라고 부른 이유는 데이터센터의 어마어마하게 큰 컴퓨터들의 집합에서 일부를 가상으로 분할해서 제공하기 때문이다. 더 쉽게 말하면, 큰 컴퓨터들에다가 VM 띄워 놓고 그거 임대해주는 서비스다.


물론 컴퓨터에는 운영체제와 실제 서비스로 제공할 로직들이 저장도 되어야 하기 때문에, 메모리와 프로세서만으로는 이 목적이 달성되지 않는다. 그래서 같이 제공되는 것이 바로 EBS(Elatic Block Storage). EBS는 이 EC2에 연결되는 가상의 보조 기억장치이며, 이 두가지가 묶여서 보통 하나의 가상 컴퓨터를 구성한다.


4. 컴퓨팅 자원 위에 올라갈 컨테이너들을 배포하고 싶다면: ECS


도커의 등장 이후 컨테이너로 실제 구동될 환경과 로직을 한번에 묶어서 배포하는 것이 여러모로 뒤탈이 없고 관리가 편하다는 걸 많은 개발자들이 알게 되었다. 이에 발맞춘 서비스가 바로 도커와 같은 컨테이너 기술 자체를 서비스화한 ECS이다. 그냥 EC2 위에다가 도커를 설치하고 배포하면 되지 않느냐고? 실제로 ECS는 기본적으로는 EC2 위에서 구동되는 서비스다. 실제로 머신을 임대하고 그 위에 올라가는 도커 컨테이너들에 관리 편의를 위한 API들을 추가한게 기본적인 ECS의 작동 모델이다(미리 머신을 임대해 두는 것을 프로비저닝이라고 한다). 그냥 설치해서 쓰는 것과의 차이는, 서로 다른 머신에 올라갈 컨테이너들을 수요에 맞춰서 배포 수를 줄이거나 늘이는 등의 집합적 관리의 편의성이 생긴다는 것.


이 머신을 미리 프로비저닝해두는 것 조차 귀찮다면, ECS 의 하위 서비스인 Fargate라고 하는 서비스를 쓸 수 있다. 머신을 임대하는 것 조차 자동화된 서비스로, 머신 프로비저닝까지 신경 쓸 것 없이 여러분은 로직의 작성에만 집중하면 된다. 목표 배포 수와 메모리 점유율 등의 숫자만 정의해 두면, Fargate가 알아서 배포, 죽은 컨테이너 재구동, 스케일 아웃까지 해 준다(대신 단위 컴퓨팅 유닛당 과금이 2배다).


5. 백업, 로드 분석, 보안 등 신경써야 할 부분이 모두 자동화된 RDBMS를 쓰고 싶다면: RDS


RDS Relational Database Service의 줄임말이다. 이름답게 MySQL, PostgreSQL 등 관계형 데이터베이스를 서비스로 제공한다. 이것도 결국은 EC2에다가 RDBMS를 설치하고 AWS의 추가 API와 서비스들을 얹어 놓은 것에 지나지 않는다. 그런데 비용은 단위 머신을 직접 임대해서 DBMS를 설치하는 것의 약 3~4배 정도를 자랑한다. 그럼 여러분들은 궁금할거다. '도대체 이걸 왜 그 돈을 줘 가면서 써야 하는 거지?'


그건 바로 대기업의 Best Practice를 바로 서비스형으로 제공받으며, 마찬가지로 RDBMS를 직접 쓰는 것보다 편하기 때문이다. 예를 들어, 여러분이 EC2 위에다가 RDBMS를 설치했다가 아래 구문을 실제로 수행했다고 해 보자.


DROP * FROM db;


멘붕이 올 것이다. 여러분들의 모든 테이블과 데이터 엔티티는 날아갔다. 그런데 이런 상황에서 백업도 안 해 뒀다면? 서비스는 그날로 문을 닫아야 할 것이다. 소송이나 안 당하면 다행이지. 다행스럽게도 RDS에는 이런 상황들을 막기 위한 방비책들을 매우 많이 마련해 뒀다. 후술할 IAM등과 엮어 애초에 해당 서비스에 접근 가능한 경로를 최대한 차단할 수도, 백업을 aggresive하게 할 수도, 복제본을 미리 엄청나게 많이 구워 둘 수도 있다. 이런 솔루션들을 직접 구현하면 되지 않느냐고? 그거 할 인건비 쓰고, 시간 쓰고, 그 서비스들 구현하기 위한 기반 서비스들에 추가로 지출을 하느니 차라리 RDS 쓰는게 싸다. 그래서 쓰는게 바로 RDS다. 물론 쿠팡과 같은 대기업들에서는 이런 관리 전략을 실제로 맞춤해서 만들기도 하지만, 그건 그때 가서 생각할 일이다.


그리고 RDS는 기본적으로 연산 부하가 높기로 유명한데, 단순한 읽기만을 많이 제공하는 서비스라면(대부분 그렇다), 읽기 복제본을 깔끔하게 늘릴 수 있는 RDS Aurora라는, 다른 RDBMS의 확장을 쓰는 것이 좋다.


6. 사용자들의 인증을 관리하고 싶다면: Cognito


의외로 서비스 구현할 때 공통적으로 쓰이는 부분이지만, 실제로 구현하려면 까다로운 것이 인증이다. 인증 서비스는 대개 사용자들로 부터 인증을 위한 정보(보통 패스워드와 계정 정보)를 받은 다음, 인증정보가 저장된 데이터베이스에 가서 사용자 정보와 부합하는지 점검하고, 사용자들에게 인증을 위한 토큰을 생성해 클라이언트로 다시 전달해 주는 역할을 한다. 그런데 사용자가 비밀번호를 잊어버렸다면? 암호는 평문 그대로 저장하면 안된다는데 이걸 암호화할 방법은? 실제 사용자의 특정 세션들을 만료해야 한다면? JWT 토큰을 위한 키는 주기적으로 로테이션해야 한다는데, 사용자를 인증할 키는 언제 만료시켜야 하지? SSO 로그인은 어떻게 구현해야 할까? 이와 같은 인증에 뒤따라오는 수많은 작업들을 서비스형으로 제공하는 것이 바로 Cognito이다. 무엇보다 RDS등 핵심 서비스를 제공하기 위한 부하를 이런 수시로 작동해야 하는 로직들에 낭비하면 안 되는데, 이 때 Cognito는 서비스형이므로 부하에 제한이 없으므로 서비스의 부하를 최적화할 목적으로도 안성맞춤이다.


7. RDBMS 이외의 완전관리형 NoSQL을 사용하고 싶다면: DocumentDB, DynamoDB


이미 위에서 완전관리형 DBMS를 쓰는 이점을 설명했으니, 이 부분은 간략하게만 짚고 넘어가겠다. DynamoDB는 애초에 아마존이 독자적으로 구현한 DBMS이며, DocumentDB는 MongoDB와 RDS-Mysql 및 PostgreSQL등과 유사한 관계를 갖는다. 이외에도 아마존의 완전관리형 DBMS 서비스는 많으니 사용할 DBMS에 맞춰서 걸맞는 완전관리형 NoSQL DBMS를 사용하면 된다.


8. 검색 기능을 구현하고 싶다면: CloudSearch, Elasticsearch


검색 기능이 생각보다 구현하기 어렵다는 것은 다들 알 것이다. 단순히 패턴 매칭을 하는 정도야 물론 DBMS 차원에서도 쉽게 구현이 가능하지만, 자연어 검색, 유의어 검색 등을 구현해야 하는 수준은 이 정도로는 구현하기 힘들다. 이 때 오픈소스 진영에서 주로 쓰는 것이 Elasticsearch인데, 이 조차도 완전관리형이라는 아이디어를 도입해서 다른 서비스들과 쉽게 연계하고 연동성을 높이고 싶다면 AWS의 검색 서비스들을 사용하면 된다.


9. 코드를 클라우드에서 빌드하고, 유닛 테스트와 같은 점검을 수행하고, 배포하고 싶다면: CodeBuild, CodeDeploy, CodePipeline


Travis, Jenkins등의 Ci/CD 를 사용해봤다면 알 것이다. 처음에야 직접 서버 환경에 접근해서 코드를 불러오고, 빌드를 하고, 실행하는게 가능하지만, 그걸 300~400 개 정도 되는 머신에 반복 수행하는 것은 쉽지 않다는 것을. CodeBuild는 별도의 빌드 머신을 배포하고, 이들 머신에서 일련의 쉘 스크립트를 실행한다. 물론 이 정도야 별개의 머신을 하나 지정해 두고 해당 머신에서 동작할 이 기능들을 직접 구현하는 걸로 충분하지 않냐고 할 수 있지만, 만약 이걸 실제로 배포해야 한다면? 결국 배포하는 과정에서 CodeDeploy의 AWS API들을 사용하게 된다(실제로 Travis와 같은 Ci/CD 서비스를 써 본 사람들은, 결국 AWS에서 환경설정을 해야 했을 것이다. 이 부분이 저 서비스들에 대한 설정이다). CodePipeline은 이와 같이 빌드-테스트-배포 과정에서 쓰이는 일련의 과정들을 하나로 엮을 수 있도록 해 준다.


10. 네트워크 단에서의 보안 방벽을 구축하고 싶다면: WAF, SecurityGroup


집에 공유기를 설치해 봤다면, 기본적으로 외부에서 공유기에 접근을 시도할 때 규칙에 따라 차단하거나 허용하는 등의 보안 방벽을 세울 수 있다는 것을 알 것이다. AWS에서는 WAF와 EC2의 하위 서비스인 Security Group이 이 부분을 수행한다. Security Group은 기본적으로 공유기의 포트 포워딩과 매우 유사해, IP대역이나 다른 Security Group으로부터 접근을 허용하거나 차단할 수 있다. WAF는 방화벽을 서비스한 것으로, Security group과 같이 IP 대역 뿐 아니라 반복적인 비허용 접근 시도, 특정 CVE 공격을 위한(즉 널리 알려진 취약점을 Exploit 하기 위한) 요청들을 규칙에 따라 차단할 수 있다.


11. 서로 다른 서비스들로 들어오는 요청을 분산해 분배하고 싶다면: ELB


수 많은 컨테이너를 띄웠지만, 사용자 어플리케이션에 해당 주소로 접근하기 위한 IP 주소를 일일이 알려줄 수는 없다. 심지어 ECS와 같은 곳에서 컨테이너가 죽가나 살아나는 등의 이유로 IP 주소가 수시로 바뀐다면 더더욱. 이 때 이 인스턴스들로 들어가는 요청을 먼저 받은 다음, 부하에 따라 이들을 적절히 분배하는 것이 ELB, 즉 Elastic Load Balancer다. 이들 서비스들은 특정 동작을 수행하기 위한 연산 노드들의 집합으로 구성되며(EC2, ECS 서비스 등 뭐든 이 집합에 집어넣을 수 있다), 이들 사이에서 ELB는 들어온 HTTP 요청들을 분배해 준다.


12. 여러 연산 노드들이 공유해 쓸 수 있는 큐가 필요하다면: SQS


Simple Queue Service의 줄임말이다. 서비스의 규모가 점차로 커진다면, 사용자들에 알림을 발송하거나 사용자의 정보를 분석해야 하는 등 Time Critical 하진 않지만 언젠가는 수행해야 하는 작업들이 늘어난다. 이 때 비용을 절감하고 싶다면 작업을 적재했다가 순차적으로 느긋하게 수행하는 큐를 활용하게 된다. 이 때 이 중앙화된 큐의 역할을 서비스로 제공하는 것이 바로 SQS다. SQS의 가장 중요한 기능 중 하나는 큐에서 메시지 하나를 가져온 다음에는 일정 시간(대개 작업을 수행할 것으로 기대되는 시간) 동안 다른 노드들에는 이를 노출하지 않고, 작업일 성공적으로 수행된 다음에는 큐에서 이를 완전히 제거하도록 할 수 있다는 것.


13. 여러 배포들이 만들어낸 기록들을 중앙에서 쌓아 보고 싶으면: CloudWatch, Xray


사용자들이 장애를 호소할 때, 결국은 남은 기록들을 기반으로 오류의 원인을 분석할 수 밖에 없다. 그런데 서비스의 규모가 커질수록 어마어마하게 많은 서비스들에서 발생한 로그들을 모아서 봐야만 이들 오류의 원인이 이해가 된다. CloudWatch는 API를 통해서 특정한 기록들을 중앙의 로그 스트림에 쏴 주거나, 특정한 연산 노드의 stdout, stderr등의 스트림에 올라간 스트링들을 모두 중앙에서 모아서 기록한다. 하지만 서로 다른 로그 기록 집합에서 연관성 있는 것들을 찾기는 쉽지 않다. Xray는 AWS에서 제공하는 Distributed Tracing인데, 하나의 클라이언트 요청을 여러 연산 노드들에서 순차적으로 나눠 진행했을때 특정한 조건을 만족하면(서로를 연관 지을 수 있는 표지가 있다면), 이들 정보를 하나로 묶어서 마치 한 개의 컴퓨터에서 발생한 Stack Trace 처럼 모아서 보여준다.


14. 서로 다른 서비스 사이에 권한을 지정하고 싶다면: IAM


권한이라는 개념은 보안에서 강력한 치트키다. 서비스의 핵심 로직에 필요없는 권한은 그냥 안 줘 버리면 접근 경로가 차단되니 공격을 하기가 힘들어진다. AWS의 대부분 서비스들은 각 서비스에서 수행할 권한들의 종류를 규정하며, 관련 권한이 안 주어진 엔티티에서 이를 요구하는 API를 요청할 경우 그냥 실행을 거부한다. 따라서 특정 권한이 필요하다면, 서로 다른 엔티티들이 특정 동작에 대해서 서로를 신뢰하도록 해야 한다. 이를 규정하는 것이 IAM, 즉 Identity and Access Management이다.


예를 들어 S3 버킷(한 개의 클라우드 단의 보조기억장치라고 봐도 무방하다)에서 웹 사이트를 서비스하기 위해 GIthub의 레포지터리에서 Codepipeline(빌드를 위한 CodeBuild, S3에 배포하기 위한 CodeDeploy 포함)으로 파일을 보내고, 이들을 고속으로 서비스하기 위해서 CloudFront로 CDN을 붙인다고 해 보자. 이 때 CloudFront에서 S3 버킷에서 파일 목록과, 파일 자체를 가져올 권한이 없다면? 당연히 서비스가 되지 않을 것이다. 그리고 S3 버킷에 파일을 업로드할 권한이 CodeDeploy의 배포에 없다면? 당연히 파일을 업로드할 수 없으니 배포가 무한정 실패할 것이다. 이런 권한 모델이 귀찮다고 생각할 수 있지만, 기억하자. 해커는 바로 여러분의 그런 귀찮음을 파고든다.


15. 이 많은 서비스들의 환경설정을 자동화 하고 싶다면: CloudFormation, CDK


IAM에서 보았듯, 이미 서로 다른 서비스들을 연계하려면 이들 사이에 수행해야 할 일련의 작업들이 있단 것을 알 수 있다. 그런데 이 작업들이 의외로 귀찮다. CDK Cloud Development Kit의 약자로, AWS에서 발표한 BaaC(Backend as a Code) SDK이다. 백엔드에서 사용할 엔티티들을 코드로 정의하고 서비스 엔티티들 사이나 엔티티 자체에 대해 수행해야 할 작업들을 정의하면 CDK CLI가 알아서 필요한 AWS의 서비스 엔티티들을 추가로 정의하거나 권한 문제를 해결하고 백엔드에서 필요한 인프라들을 생성, 수정한다. 예를 들어 ECS Fargate 서비스 하나를 규정하고, RDS에 정보를 수정, 저장하고 읽는 서비스를 정의한다고 하자. ECS Fargate에서 사용할 컨테이너를 정의하고, 이들의 CI/CD 과정을 정의한다. 그리고 RDS 인스턴스 하나를 정의하고, 미리 정의한 ECS Fargate에서 해당 RDS 인스턴스에 접근 권한을 허용한다. 이 과정 전체를 마치 서비스 로직 하나를 코딩해서 만들어내듯이 작성/배포할 수 있도록 한 것이 CDK이다.


CDK는 이 작업을 위한 SDK이고, 그럼 실제로 이걸 AWS에서 수행하는 서비스가 필요하지 않나? 물론 그렇다. 이 작업을 실제로 수행하는 서비스 이름이 바로 CloudFormation이다. CloudFormation은 클라우드에 배포되어야 하는 엔티티들의 목록을 작성한 Yaml 파일을 받아, 실제로 이들에 대한 배포를 수행한다. 전체 과정에서 에러가 하나라도 발생한다면 전체 배포가 롤백된다(사실상 사람이 직접 하는 것 보다 결정적으로 나은 부분이 이거다). CDK CLI는 배포 과정에서 바로 이 Yaml 파일을 생성하고, CloudFormation에 해당 파일을 전달하면 AWS는 이 정의에 따라서 필요한 엔티티들을 생성하고 수정, 때로는 삭제하는 것.


AWS 이외의 기업에서 제공하는 이와 같은 서비스에는 Hashicorp의 Terraform등이 있다.




위에서 본 서비스들을 엮기 위해서는, 직접 작성한 로직들 사이에서는 네트워크 요청을 통해서 필요한 작업을 수행하거나, AWS 의 각 서비스별 API를 호출하면 된다. 만약 AWS에서 제공하는 서비스가 본인들의 요구사항에 맞지 않다면, 위와 같은 기능들을 수행하는 수많은 오픈 소스 라이브러리 중 하나를 골라 사용해도 된다.


그리고 수많은 서비스들이나 라이브러리를 사용할 때 가장 중요한 것이 합목적성이다. 큐를 RDBMS를 통해서 구현하는 것은 불가능하지 않다. 페이로드와 요청 타임스탬프, 요청 처리여부를 테이블 하나에 저장한 다음 타임스탬프로 오름차순으로 정렬하면 그게 큐니까. 하지만 RDS(혹은 RDBMS를 직접 개별 컴퓨터에 설치한다손 치더라도)와 SQS(혹은 오픈소스 큐 라이브러리로 치환하더라도) 사이의 Computational Cost를 생각한다면 절대 좋은 구현이라고는 말 할 수 없다.


즉 백엔드 구현은 서두에 언급했듯,


1. 제공하려는 서비스를 컴퓨터공학적 개념에 맞춰서 분할

2. 이들에 가장 들어맞는 서비스나 오픈소스 프로젝트를 선택

3. 이들 사이의 연계 로직과 필요한 비즈니스 로직을 작성


하는 것이 끝이다. 위에서 말한 것 이외에도 블록체인도 관리형 서비스로, 도커까지 갈 필요도 없는 작은 로직을 컴퓨팅 환경에 대한 고려는 아예 접어 두고 배포하는 FaaS(Function as a Service), 여러 인스턴스 사이에서 특정한 설정값을 공유하기 위한 서비스, 도메인을 렌탈하기 위한 서비스 등 AWS는 수없이 많은 백엔드에서 필요한 구성요소들을 서비스로 제공하며, 이는 AWS와 동등한 풀 피쳐 퍼블릭 클라우드인 GCP, 네이버 클라우드, Microsoft Azure 등도 마찬가지이다. 심지어 사용자에게 특정 컨텐츠를 빠르게 제공한다는 면에서는 대기업의 제품들보다도 더 유용한 CloudFlare와 같은 회사들도 있다. 목적성에 맞춰 하위 구성요소를 택하고, 이들을 엮어 주는 것이 백엔드 개발의 전부이다.