Laravel와 Bref를 활용한 팀 우선 서버리스 엔지니어링

녹화 영상

https://www.youtube.com/watch?v=41JNqwdVmfk

플랫폼 엔지니어링 접근 방식의 서버리스 개발

• CNCF 정의: 서버를 관리하지 않고 애플리케이션을 구축하고 실행하는 것.
• 이점:
• [ 1 ] 운영 부담 감소.
• [ 2 ] 비용 절감.
• [ 3 ] 더 빠른 개발 경험.
• [ 4 ] 서버 프로비저닝 부담 해소.

도입 목표와 원칙

• [ 1 ] 목표:
• 실제 고객 문제를 해결한다.
• [ 2 ] 원칙:
• 실질적인 가치를 창출한다.
• PHP 팀의 업무 방식에 부합해야 한다.
• 한 사람만이 아니라 팀 전체가 유지보수할 수 있어야 한다.

사례 연구와 교훈

• [ 1 ] 파트너 데이터용 간단한 API:
• API Gateway와 Lambda를 사용해 데이터를 S3에 저장했다.
• 성능 문제 없이 트래픽이 200배 증가하는 성과를 거뒀다.
• 숨겨진 문제: 한 사람만 유지보수할 수 있었다.
• 교훈: 문제는 언어(Python)가 아니라 팀 문화와의 충돌 및 익숙하지 않은 도구에 있었다.
• [ 2 ] 머신 러닝용 서버리스 플랫폼:
• 비용을 절감했고 데이터 사이언티스트들에게 좋은 반응을 얻었다.
• 문제: 일반 개발팀은 이를 사용할 수 없었다.
• 교훈: 전문가뿐 아니라 주된 개발자 집단을 위한 솔루션이 필요했다.
• [ 3 ] AWS Amplify:
• AWS Amplify 실험에 관한 자세한 내용은 중간에 끊겼지만, 더 폭넓은 팀을 위한 지속 가능한 서버리스 솔루션을 찾으려는 또 다른 시도였던 것으로 보인다.

핵심 시사점

• [ 1 ] 공동 소유:
• 진정한 성공을 위해서는 공동 소유와 팀 문화에 대한 존중이 필요하다.
• [ 2 ] 팀 적합성:
• 솔루션은 팀의 업무 방식에 부합하고 팀 전체가 유지보수할 수 있어야 한다.

결론

• 서버리스를 효과적으로 도입하는 여정에는 팀 문화를 이해하고 존중하며, 유지보수성을 보장하고, 모든 이해관계자를 위한 실질적인 가치를 창출하는 일이 포함된다.

새로운 프로토타입의 과제

• [ 1 ] 초기 반응:
• 서버리스를 사용한 새 프로토타입은 익숙한 도구로 형성된 실험실 팀의 기존 "근육 기억"과 달랐기 때문에 저항에 부딪혔다.
• [ 2 ] 교훈:
• 큰 변화를 도입하기 전에 익숙한 도구에 대한 신뢰와 편안함을 확보하는 것이 중요하다.

팀별 경험 비교

• [ 1 ] Ruby 팀:
• 서버리스를 성공적으로 도입했다.
• [ 2 ] PHP 팀:
• 높은 인지 부하로 어려움을 겪었다.
• [ 3 ] 깨달음:
• 성공 여부의 차이는 인지 부하와 도구에 대한 익숙함에서 비롯되었다.

플랫폼 엔지니어링으로 전환하기 위한 새로운 전략

• 팀 전체가 서버리스를 쉽게 사용하고 유지보수할 수 있도록 플랫폼 엔지니어링으로 전환한다.

목표 재평가

• 기존 목표: 단순히 서버리스 프로젝트를 출시하는 것.
• 새로운 목표: 팀 전체가 운영할 수 있는 서버리스 프로젝트를 출시하는 것.
• 성공 지표: 함수 개수가 아니라 팀의 자신감.

PHP 팀에서 서버리스를 활용하는 방법

• 익숙한 도구의 필요성:
• PHP 개발자들에게는 편하게 사용할 수 있는 도구가 필요했다.
• 사용자 지정 런타임:
• 2018년부터 Lambda에서 PHP용 사용자 지정 런타임을 사용하기 시작했다.

솔루션: Laravel과 Bref

• [ 1 ] Laravel:
• 개발자들이 이미 신뢰하고 익숙하게 사용하고 있었다.
• [ 2 ] Bref:
• Lambda에서 PHP를 실행할 때 발생하는 복잡성을 처리했다.
• [ 3 ] 결합 솔루션:
• 기존 워크로드를 유지하면서 서버리스를 테스트하고 그 이점을 얻을 수 있게 했다.

최초의 프로덕션 애플리케이션

• [ 1 ] 애플리케이션:
• 대용량 CSV 파일 처리.
• [ 2 ] 기술 스택:
• Amazon S3 Select를 사용해 Lambda에서 데이터를 필터링함으로써 예측 가능한 성능을 보장했다.
• [ 3 ] 결과:
• 처리 시간이 빨라졌고 서버 관리가 필요 없어졌다.

팀 도입과 성공

• [ 1 ] 주니어 개발자:
• 문서를 따라 서버리스 앱을 개발하고 배포할 수 있었다.
• [ 2 ] 역할 변화:
• 발표자의 역할이 병목 지점에서 코치로 바뀌었다.
• [ 3 ] 반복 가능성:
• 이 접근 방식을 반복해서 적용할 수 있게 되었고, 더 이상 한 명의 전문가에게 의존하지 않게 되었다.

결론

• 성공적인 서버리스 도입을 위해서는 팀의 역학 관계를 이해하고, 익숙한 도구를 활용하며, 팀 전체가 자신 있게 서버리스 애플리케이션을 운영할 수 있는 환경을 조성해야 했다.

서버리스에서 마주한 새로운 과제

• 서버리스 고유의 문제:
• 콜드 스타트, 시간 초과, 메모리 제한.
• 하나의 Lambda에서 전체 Laravel 앱을 실행하는 방식(Lambda Lift)은 큰 패키지 크기와 복잡한 권한 같은 문제를 낳았다.

실용적인 해결책

• [ 1 ] 완화 조치:
• Lambda Layers와 민감한 함수별 IAM 역할을 사용했다.
• 타이머에는 프로비저닝된 동시성을 적용하고, 콜드 스타트를 관리하기 위해 이벤트 기반 접근 방식을 도입했다.
• [ 2 ] 검증:
• 신뢰받는 엔지니어들과의 논의와 검증을 통해 Lambda에서 모놀리스를 실행하는 방식이 실용적임을 확인했다.

교훈

• [ 1 ] 마이크로서비스와 모놀리스:
• 완벽한 마이크로서비스 아키텍처가 항상 필요한 것은 아니다.
• 팀에게 Lambda Lift는 공동 소유와 빠른 기능 출시를 가능하게 하는 실용적인 선택이었다.
• [ 2 ] 팀의 자신감:
• 특정 아키텍처보다 더 중요하다.

솔루션 확장

• 재사용 가능한 템플릿과 표준 명령:
• 새 팀이 처음부터 시작하지 않아도 되도록 재사용 가능한 템플릿과 표준 명령을 만들었다.
• 플랫폼 팀의 지원 부담을 줄였다.

플랫폼 엔지니어링

• [ 1 ] 정의:
• 개발팀이 더 적은 인지 부하로 기능을 더 빠르게 출시할 수 있도록 공유 서비스를 구축하는 것.
• [ 2 ] 기본 원칙:
• 플랫폼에 관한 CNCF 백서 같은 업계 모범 사례를 따랐다.
• [ 3 ] Team Topologies 모델:
• 플랫폼 팀이 일반적인 문제에 대한 표준 솔루션을 제공해 인지 부하를 줄이고, 향후 합류할 팀들이 기능에 집중할 수 있게 하는 것이 목표였다.

플랫폼 설계

• [ 1 ] 기존 팀에 맞추기:
• 기존 팀 구조와 문화에 맞도록 플랫폼을 설계했다.
• [ 2 ] 인지 부하 줄이기:
• 두려움을 유발할 수 있는 복잡한 서버리스 아키텍처를 피했다.
• 로드 밸런서를 사용해 트래픽을 적절한 컴퓨팅 대상으로 라우팅했다(예: PHP 팀에 익숙한 Lambda).
• [ 3 ] 데이터베이스 선택:
• 개발자들이 익숙한 SQL 명령을 최소한의 변경으로 사용할 수 있도록 MySQL 호환 서비스인 TiDB를 선택했다.

로컬 개발 경험

• 도구:
• 개발자들이 동일한 PHP 명령으로 노트북에서 전체 애플리케이션을 실행할 수 있도록 Docker와 LocalStack을 사용했다.
• 도입 과정의 마찰을 크게 줄였다.

혁신적인 결과

• [ 1 ] 역할 변화:
• 발표자의 역할이 병목 지점에서 조력자로 바뀌었다.
• [ 2 ] 성공적인 확장:
• 여러 팀으로 패턴을 확장했다.
• 새 팀을 서버리스 프로젝트에 합류시키는 과정이 훨씬 빨라졌다.

결론

• 플랫폼 엔지니어링 접근 방식은 인지 부하를 줄이고, 익숙한 도구를 활용하며, 재사용 가능한 템플릿과 표준 솔루션을 제공하는 데 집중함으로써 팀이 서버리스 기술을 도입하고 확장하는 역량을 혁신했다.

플랫폼의 핵심 특성

• [ 1 ] 셀프서비스 시스템
• 명령과 자동화된 CI/CD 파이프라인.
• 지원 티켓을 없애 개발자가 자신의 업무에 집중할 수 있게 한다.
• [ 2 ] 가드레일
• 구조화된 로깅과 알림 기능이 있는 Sentry 같은 도구.
• 문제 해결 지침이 포함된 Lambda 함수를 제공한다.

플랫폼의 발전

• 초기 단계: 긴밀한 협업.
• 현재 단계: 플랫폼 자체가 셀프서비스 제품인 "X as a Service" 모델로 전환 중이다.
• 목표: 셀프서비스를 문화의 자연스러운 일부로 만든다.

지속적인 노력

• 프로세스 통합:
• 스프린트 계획, 코드 리뷰, 회고에 서버리스 패턴을 포함한다.
• 팀 전체가 시스템을 자신 있게 사용하도록 한다.

3단계 로드맵

• [ 1 ] 적응:
• 템플릿과 코칭으로 시작한다.
• [ 2 ] 표준화:
• 테스트와 배포가 표준으로 자리 잡을 때까지 자동화한다.
• [ 3 ] 확장:
• 더 많은 제품으로 패턴을 확장하고 계속 개선한다.
• [ 4 ] 결과:
• 이 단순한 주기를 통해 팀은 생산성을 높이고 미래에 대비할 수 있다.