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

글로벌 고용 시장은 빠르게 움직이고 있으며, 신제품에 대한 수요는 항상 존재합니다. 우리는 업계 전반에서 우리의 선두를 유지할 수 있는 방법을 찾아야 했습니다.

우리는 대담한 전략을 가진 기술 회사입니다.

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(Event-Driven Architecture)를 사용하면 조직과 소프트웨어를 모두 확장할 수 있습니다. 서버리스는 이벤트를 통해 작은 블래스트 반경을 유지하고 완전한 클라우드 네이티브 방식으로 통신하도록 강요합니다.

제약 조건 활성화

global employment platform 기업으로서 우리는 규정 준수를 진지하게 받아들입니다. 클라우드 인프라는 잘 설계되었으며, 워크로드를 분리하고 클라우드 규정 준수를 자동화하는 다중 계정 전략을 사용합니다. 서버리스는 클라우드 리소스를 프로비저닝하는 방법을 제어하여 높은 표준을 시행하는 데 도움이 됩니다.

작업 오프로드

클라우드 공급자는 서버리스 서비스를 관리합니다. AWS가 통합, 보안, 조정, 활성화 및 유지 관리하는 단일 구성 요소 세트를 통해 고객의 가치 사슬에 더 집중할 수 있습니다.

잘 설계된 워크로드

당사가 생성하는 모든 워크로드는 AWS Well-Architected Framework로 검토됩니다. 당사는 SLA(서비스 수준 계약)를 충족할 뿐만 아니라 초과 달성할 수 있도록 규모, 보안, 신뢰성 및 비용 최적화에 집중합니다. 이를 통해 엔지니어링 팀은 클라우드 환경으로 계속 진화할 수 있습니다. 

팀 소개

우리의 기술 전략은 야심 차며, 이로 인해 도전이 되고 있습니다. 많은 엔지니어가 서버리스 아키텍처(또는 분산 아키텍처)에서 작업하지 않았습니다. 서버리스 아키텍처로의 전환은 쉽지 않으며, 우리는 학습, 큰 사고, 속도에 맞춰 움직이는 데 익숙한 엔지니어를 찾습니다.

일부 엔지니어는 무서버라는 용어에 대해 확신하지 못합니다(예, 서버가 있다는 것을 알고 있습니다). 왜냐하면 이 접근 방식은 기능에서 코드를 쓰는 것 이상의 것이기 때문입니다. 우리의 전략은 클래식한 클라우드 네이티브 원칙에 대한 전체적인 접근 방식을 요구합니다.

결과

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

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

2. 컴플라이언스: AWS Well-Architected Framework를 사용하여 모든 워크로드를 검토합니다. 많은 AWS Managed Services를 사용하기 때문에 운영 우수성에 의존하고 고품질의 장소에서 시작할 수 있습니다.

3. 시스템 사고: 시스템, 신뢰성 및 비즈니스 가치를 추론할 수 있도록 많은 프로세스를 표준화해야 했습니다. 우리는 낮은 가치의 구성 요소를 다루는 데 시간을 할애하지 않습니다.

4. 혁신: 서버리스는 모든 것이 API라는 것을 의미합니다. 이러한 강제 제약에는 API 우선 접근 방식이 필요합니다. 우리가 스스로를 플랫폼이라고 생각할 때, 우리는 G-P Gia™ 를 새로운 지식 베이스에 연결하는 것과 같은 API를 통해 시스템을 쉽게 연결하여 새로운 차원의 혁신에 도달할 수 있습니다.

5. 소유권: AWS는 우리의 인프라를 소유하지만, 우리는 우리의 비즈니스 도메인을 소유합니다. 도메인 중심 설계를 통한 서버리스 우선으로 인해 비즈니스 문제에 집중해야 했습니다. 이렇게 하면 역량에 대한 주인의식을 명확하게 유지할 수 있습니다.

서버리스 우선이 항상 더 빠른 것은 아니지만 더 유익합니다. 우리는 개별 개발자 속도보다는 시스템 속도에 최적화해야 합니다. 서버리스 우선은 기능을 사용하는 것이 아니라 “강령은 책임이다. 시스템이 자산입니다.” 코드를 적게 작성할수록 우리가 구축 중인 비즈니스 시스템을 더 많이 고려하고 성형할 수 있습니다.

우리의 이야기를 공유하면서 우리가 일하는 속도가 분명해질 것이며, 이는 서버리스 우선의 직접적인 결과입니다. 계속 지켜봐 주세요.