몇 년 전 흥미로운 문제가 있었습니다. 저희는 모든 소프트웨어를 클라우드에서 사용하는 완전 원격 회사입니다. 그리고 인프라스트럭처를 코드로 사용하는 컨테이너에서 실행되는 Spring Boot 애플리케이션 제품군을 보유하고 있었습니다. 하지만 비즈니스 민첩성이 필요했습니다.

글로벌 고용 시장은 빠르게 변화하고 새로운 제품에 대한 수요는 항상 존재합니다. 업계에서 선두를 유지할 수 있는 방법을 찾아야 했습니다.

당사는 대담한 전략을 가진 기술 기업입니다.

2022 에서 "서버리스 우선 및 컨테이너를 필요에 따라 사용한다는 ADR(아키텍처 결정 레코드)을 만들었습니다." 그리고 거의 모든 엔지니어링 팀( 40 )에서 토론을 촉발시켰습니다.

먼저 몇 가지 용어를 설명하겠습니다.

서버리스 퍼스트는 서비스형 기능만이 아닙니다. 또한 클라우드 제공업체의 관리형 서비스 그룹이기도 합니다: 

  • 인프라를 관리하지 않음으로써 운영 오버헤드 감소

  • 필요에 따라 0으로 확장하여 완전히 탄력적으로 만드는 것을 포함하여 필요에 따라 확장합니다.

  • 탄력적인 가격 책정(사용한 만큼만 지불) 

G-P에서 서버리스 퍼스트는 AWS Lambda, EventBridge, Step Functions, Fargate, SQS, SNS, API Gateway, S3, DynamoDB 등을 사용하는 것을 의미합니다.

서버리스 우선이란 컴퓨팅, 스토리지, 메시징 등의 솔루션을 선택할 때 팀이 서버리스 옵션으로 시작하길 원한다는 의미입니다. 중요한 참고 사항: 서버리스 서비스가 요구 사항을 충족하지 못하는 경우, 팀은 더 많은 운영 투자가 필요한 더 무거운 서비스로 돌아가야 합니다.

"필요에 따른 컨테이너"는 서버리스 우선이 서버리스 전용을 의미하지 않는다는 점을 명확히 합니다. 컨테이너가 필요한 경우(예: COTS 소프트웨어 제품을 설치하는 경우)가 있는데 이는 괜찮습니다.

고객을 우선시하는 기술 전략

고객과 사용자의 요구를 충족하기 위해 민첩하게 움직입니다. Lambda, S3, DynamoBD와 같은 서비스는 복원력이 뛰어나고 빠릅니다. 차별화되지 않은 무거운 짐을 덜어줌으로써 일반적인 인프라 구성 작업 대신 사용자를 위한 기능을 개발하는 데 더 많은 시간을 할애할 수 있습니다.

G-P의 핵심 원칙은 다음과 같습니다: "직접 만들고, 직접 운영합니다." 저희 팀은 소프트웨어를 소유하고 있습니다. 따라서 우리는 DevOps 팀에게 소프트웨어를 벽 너머로 던져주는 것이 아닙니다. 

"서버리스 우선"의 이점

서버리스는 본질적으로 이벤트 중심입니다.

저희 아키텍처는 완전히 이벤트 중심입니다. EDA(이벤트 중심 아키텍처)를 사용하면 조직과 소프트웨어를 모두 확장할 수 있습니다. 서버리스를 사용하면 폭발 반경을 작게 유지하고 이벤트를 통해 완전히 클라우드 네이티브 방식으로 통신할 수 있습니다.

제약 조건 활성화

Global Employment Platform™ (글로벌 고용 플랫폼)으로서 Dropbox는 규정 준수를 중요하게 생각합니다. Atlassian의 클라우드 인프라는 잘 설계되어 있으며, 워크로드를 분리하고 클라우드 규정 준수를 자동화하는 다중 계정 전략을 사용합니다. 서버리스는 클라우드 리소스를 프로비저닝하는 방식을 제어하여 높은 기준을 적용하는 데 도움이 됩니다.

작업 부하 분산

클라우드 제공업체가 서버리스 서비스를 관리합니다. AWS가 통합, 보안, 조정, 지원, 유지 관리하는 단일 빌딩 블록 세트를 통해 고객을 위한 가치 사슬의 더 높은 단계에 집중할 수 있습니다.

잘 설계된 워크로드

우리가 생성하는 모든 워크로드는 AWS Well-Architected 프레임워크를 통해 검토됩니다. 규모, 보안, 안정성, 비용 최적화에 중점을 두어 SLA(서비스 수준 계약)를 충족할 뿐만 아니라 초과 달성할 수 있도록 합니다. 이를 통해 클라우드 환경이 계속 발전함에 따라 엔지니어링 팀의 역량을 강화할 수 있습니다. 

팀 소개

저희의 기술 전략은 야심차고 도전적입니다. 많은 엔지니어가 서버리스 아키텍처(또는 분산 아키텍처)에서 일해 본 경험이 없습니다. 서버리스 아키텍처로의 전환은 쉽지 않은 일이며, 저희는 학습하고 크게 생각하며 속도에 맞춰 움직이는 데 익숙한 엔지니어를 찾습니다.

일부 엔지니어는 서버리스(예, 서버가 있다는 것은 알고 있습니다)라는 용어에 대해 잘 모르는데, 이는 이 접근 방식이 함수로 코드를 작성하는 것 이상이기 때문입니다. Atlassian의 전략에는 기존의 클라우드 네이티브 원칙에 대한 총체적인 접근 방식이 필요합니다.

결과

2년 동안 놀라운 발전을 이루었습니다. 현대화에는 많은 이점이 있습니다( AWS/클라우드 현대화의 알려진 비즈니스 가치에 대한 기사 참조). 구체적으로 다음과 같은 현상이 관찰되었습니다:

1. 속도: 시스템을 세분화한 덕분에 팀과 제품이 독립적으로 혁신하고 발전할 수 있습니다. 이는 비즈니스 민첩성에 큰 영향을 미칩니다.

2. 규정 준수: 모든 워크로드를 검토하기 위해 AWS Well-Architected Framework를 사용합니다. 우리는 많은 AWS 관리형 서비스를 사용하기 때문에 운영의 우수성을 믿고 높은 품질에서 시작할 수 있습니다.

3. 시스템적 사고: 시스템, 안정성, 비즈니스 가치에 대해 추론할 수 있도록 많은 프로세스를 표준화해야 했습니다. 저희는 가치가 낮은 구성 요소에 시간을 낭비하지 않습니다.

4. 혁신: 서버리스는 모든 것이 애플리케이션 프로그래밍 인터페이스(API)라는 뜻입니다. 이러한 강제 제약 조건에는 애플리케이션 프로그래밍 인터페이스(API) 우선 접근 방식이 필요합니다. 스스로를 플랫폼이라고 생각할 때, G-P Gia™ 를 새로운 지식창고에 연결하는 것처럼 API를 통해 시스템을 쉽게 연결함으로써 새로운 차원의 혁신을 이룰 수 있습니다.

5. 소유권: AWS는 인프라를 소유하지만 비즈니스 도메인은 우리가 소유합니다. 도메인 중심 설계를 통한 서버리스 퍼스트 덕분에 비즈니스 문제에 집중할 수 있었습니다. 이를 통해 기능에 대한 소유권을 명확하게 유지할 수 있습니다.

서버리스 우선이 항상 빠른 것은 아니지만 더 유리합니다. 개별 개발자 속도보다는 시스템 속도에 맞게 최적화하는 것이 좋습니다. 서버리스 퍼스트는 함수를 사용하는 것이 아니라 '코드는 책임이다'라는 생각에서 출발합니다. 시스템이 자산입니다." 작성해야 하는 코드가 적을수록 구축하는 비즈니스 시스템을 더 많이 고려하고 설계할 수 있습니다.

이야기를 나누다 보면 서버리스 퍼스트의 직접적인 결과인 작업 속도가 얼마나 빨라졌는지 알게 될 것입니다. 계속 지켜봐 주세요.