내가 들은 서버 없는 응용 프로그램에 대한 흔한 불평 중 하나는 구조도에서 매우 복잡해 보이고 많은 활동 부품이 있다는 것이다.그러나 이는 서버 없는 응용 프로그램이 있는 응용 프로그램보다 더 복잡하다는 것을 의미하는가?
내가 시작하기 전에 간단한 연습을 하자.

서버 아키텍처

두 서버 애플리케이션 중 어느 것이 더 복잡합니까?

글쎄요, 그렇죠?구성도 자체가 모든 상황을 설명할 수 없기 때문이다.이러한 EC2 아이콘은 코드에 숨겨진 모든 복잡성을 잘 숨깁니다.
만약 우리가 이 두 응용 프로그램의 실제 외관에 대해 더욱 성실한 표시를 한다면 어떻게 될 것인가.너는 이 응용 프로그램들이 실제로 발생하는 90퍼센트를 소홀히 해서는 안 된다는 것을 안다.
우리는 이런 결과를 얻을 수 있다.


갑자기 응용 프로그램 1이 응용 프로그램 2보다 훨씬 복잡하다는 것이 분명해졌다.우리는 그것들의 본질에 대해 더욱 잘 이해했다.
물론 구조도는 더 복잡해졌지만, 그 자체가 나쁜 일인가?그것은 응용 프로그램에 대한 중요한 세부 사항과 그것이 실제로 무엇인지를 보여 준다.단지 이전에 이 데이터베이스 테이블과 처리 프로그램 모듈을 생략했기 때문에 그것이 존재하지 않는다는 것은 아니다.물론 그것이 당신에게 가져다 줄 복잡성과 두통에 대한 면역을 의미하는 것은 아니다.무지는 행복이 아니다. 프로그램을 지원해야 하고 새벽 3시에 서버가 정지될 때 깨어나야 할 때 행복하지 않다.
서버가 다운되면프로덕션 환경에서 서버만 실행하는 것은 아닙니다.AWS 모범 사례를 따르는 경우 최소한 두 개의 가용성 영역에서 응용 프로그램을 실행합니다.
그리고 RDS 실례가 하나밖에 없을 거야.최소한 읽기 복사본을 가지고 있으면 주 서버가 붕괴되지 않도록 합니다.


일단 당신이 중요한 실현 세부 사항을 소홀히 하지 않는다면, 그것은 좀 복잡해지기 시작할 것이다. 그렇지?

서버 아키텍처 없음

같은 효과가 있는 서버가 없는 응용 프로그램은 어떻게 됩니까?API 게이트웨이, 람바다, 다이나모DB가 유력하다.물론, RDS를 Lambda와 함께 사용할 수 있지만, 솔직히 말해서, 만약 DynamoDB가 데이터 접근 패턴을 충족시킬 수 있다면, DynamoDB로 바꾸어야 합니다.이를 사용하는 것은 훨씬 쉽다. 관리가 필요한 인프라가 없으면 어느 규모에서든 일치하고 빠른 성능을 얻을 수 있다.
서버가 없는 상황에서, 우리의 두 응용 프로그램은 이렇게 보일 수 있다.


잠깐만, 그 많은 AZ 상자들은 어디에 있습니까?
API Gateway, Lambda, DynamoDB는 모두 당신에게 상자를 열면 바로 사용할 수 있는 다중 AZ를 제공하기 때문에 이것은 더 이상 당신의 책임이 아닙니다.
그렇다면 구조도에서 포착되지 않은 모든 다른 복잡성은 그럼에도 불구하고 해결해야 한다.로그와 지표를 수집하고, 운영체제를 안전하게 업데이트하고, 자동 축소 그룹을 설정하고, 보존 실례를 얼마나 구매해야 하는지 계산해 보세요.CI/CD 파이프라인의 모든 복잡성은 말할 것도 없다. 코드를 어떻게 포장하고 배치하는지, 청록색 배치를 어떻게 해서 배치 정지를 피하는지 등이다.
단지 구조도에 포착되지 않았기 때문에 존재하지 않는다는 것은 아니다.사실 저는 AWS에서 프로그램을 구축한 지 10년이 넘었습니다. 서버리스가 등장하기 전에 저는 80%의 업무 시간을 인프라 시설과 관련된 업무를 처리하는 데 가볍게 사용했습니다.
서버가 없는 응용 프로그램에 대해 이러한 인프라 시설 문제는 플랫폼에서 제공하거나 대폭 간소화되었다.예를 들어, Serverless framework을 사용하여 어플리케이션을 패키지화하고 배포하려면 다음 명령 하나만 필요합니다.

sls deploy

이렇게
Lambda는 기존의 파란색과 녹색으로 상자를 열어 바로 사용할 수 있는 배치를 실행하고, 전송된 요청을 자동으로 나의 새 코드를 실행하는 새로운 직원으로 바꿉니다.노직원은 이미 비행 중인 요청을 처리하면 기용된다.
트래픽이 급증할 때, Lambda는 자동으로 내 코드를 실행하는 직원의 수를 조정합니다. 아무도 내 프로그램을 사용하지 않을 때, 나는 이러한 추가 자원을 기다릴 필요가 없습니다.앞서 언급한 바와 같이 Lambda는 기본적으로 나의 코드를 3개의 가용성 구역에 배치할 것이다.
나는 모든 안전 구멍과 공격 방향을 걱정할 필요가 없다.
내 코드를 실행하는 인프라는 AWS에서 관리하고 보호합니다.내 코드를 실행하는 서버에 직접 로그인해서 사방을 엿볼 수 있는 사람은 아무도 없다.운영 체제가 계속 업데이트되고 최신 보안 패치를 사용하여 패치됩니다.
Meltdown과 Spectre이 공개되었을 때, 나는 일주일 동안 우리 회사의 모든 도커 사진과 AMI를 수리했다.지금까지 우리의 람바다 기능은 모두 첫날에 수리한 것이기 때문에 우리는 손가락 하나를 움직일 필요가 없다.
더욱 세밀한 체계 구조 구성 요소가 있기 때문에 나는 더욱 좋은 안전 실천을 응용할 수 있고 모든 기능의 권한을 필요로 하는 범위 내에 제한할 수 있다.만약 빈틈이 생기고 공격자가 코드를 통해 AWS 환경에 들어갈 수 있다면 (유출된 의존항이나 성공한 코드를 통해 공격을 주입할 수 있음) 공격자가 발생할 수 있는 손해를 제한할 수 있습니다.

요컨대

자신에게 무엇이 더 중요한지 물어봐라. 외관이 간단한 응용 프로그램 그래프를 가지고 있느냐, 아니면 더 간단한 응용 프로그램을 가지고 있느냐.
서버가 없는 프로그램은 종이상에서 서버가 있는 프로그램보다 더 복잡해 보일 수 있지만, 이 도표들 중 하나는 AWS 계정에서 실행하는 실제 표시일 뿐입니다.네가 감히 상자를 열어 안에 무엇이 있는지 볼 때, 이 도표들 중 하나만이 너에게 무서운 기쁨을 줄 것이다.

서버 없는 응용 프로그램에는 더 복잡한 체계 구조도가 없습니다.그들은 더욱 진실한 응용 프로그램의 실제 상황에 대한 구조도를 가지고 있다.내장된 신축성, 탄력성, 안전성을 고려하면, 같은 서버 프로그램보다 서버 프로그램이 없는 것이 훨씬 간단하다.
"단순한 서버 없는 어플리케이션에도 복잡한 아키텍처 맵이 있습니다"라는 주장은 어플리케이션에 숨겨진 수많은 복잡성이 드러나고 드러난다는 사실을 반영합니다.
이것은 좋은 일이다.
이제 애플리케이션의 진정한 복잡성을 파악할 수 있고, 애플리케이션에 대한 보다 심도 있고 정확한 정보를 파악할 수 있으므로 애플리케이션을 보다 잘 이해하고, 아키텍처 결정을 내릴 수 있습니다.
따라서 구조도가 더욱 복잡해 보인다면 응용 프로그램 자체의 구축과 유지보수는 더욱 간단할 것이다. 코드를 실행하는 베이스 인프라를 걱정할 필요가 없고 배치와 조작 모델이 더욱 간단하며 개발자에 대한 요구도 낮기 때문이다.어쨌든 서버가 없는 것은 거대한 순승리다.
게시물 “Even simple serverless applications have complex architecture diagrams”, so what?이 theburningmonk.com에 가장 먼저 올라왔다.