[기술포스팅 원문]

1. 테스트와 프로덕션의 신뢰성 확보가 생산성 향상의 핵심이다.

• 신뢰와 빈번한 배포는 엔지니어의 생산성을 높이는 두 가지 필수 요소이다. 이러한 신뢰를 얻기 위해서는 효과적인 테스트 전략이 필요하며, 이는 최종 사용자에게 품질을 보장하는 역할을 한다. 과거의 유닛 테스트와 통합 테스트에서 발전한 새로운 테스트 방식이 요구된다.

2. 지속적인 배포 환경의 자동화가 생산성 증대를 가능하게 한다.

• 산업 표준으로 자리잡은 지속적인 배포는 생산성을 높이기 위해 필수적이라 할 수 있다. 그러나 스테이징 환경의 불안정으로 인해 테스트가 느려지는 문제를 겪고 있으며, 다양한 테스트 방식을 지속적으로 활용해야 한다. 또한, 복원력 공학을 통해 다운타임을 예방할 수 있다.

3. A/B 테스트가 링크드인에서 데이터 기반 결정을 지원한다.

• A/B 테스트는 사용자의 만족도를 평가하고, 최상의 기능 개선을 위한 방법으로 활용된다. 이 방법을 통해 코드의 복잡성을 관리하면서도 효율성을 유지할 수 있다. 또한, 다양한 메트릭을 집계하여 제품 개발과 개선을 지원한다.

4. 마이크로서비스와 분산 시스템의 복잡성을 해결하는 전략이 필요하다.

• 링크드인은 마이크로서비스 구조로 전환하여 다양한 독립적인 서비스를 관리하고 있다. 그러나 복잡한 분산 시스템에서 발생하는 문제를 해결하기 위해서는 회복력 엔지니어링이 필수적이다. 이를 통해 문제를 사전에 예측하고, 자동 롤백 기능을 통해 신속히 대응할 수 있다.

5. 카나리아 릴리스와 소프트웨어 배포 전략이 중요하다.

• 카나리아 릴리스는 새로운 버전을 점진적으로 배포하여 리스크를 줄이는 기술이다. 이를 통해 문제가 발생하기 전에 미리 대처할 수 있지만, 코드 리뷰와 테스트를 통해 문제가 발생하지 않도록 해야 한다. 배포 전략의 중요성을 깨닫고, 빈번한 배포를 위한 노력이 필요하다.

영상요약

1. 생산성 향상을 위한 테스트 전략

- LinkedIn의 경험과 광범위한 연구를 바탕으로 한 테스트 전략을 공유함.

- 엔지니어들이 신속하게 작업하고, 자신의 코드가 프로덕션에서 잘 작동하는지 확인하는 것이 중요함.

- 신뢰도 확보와 빈번한 배포가 생산성을 높이는 두 가지 핵심 요소로 언급됨.

- 단위 테스트와 통합 테스트를 넘어, 실시간 환경에서의 테스트가 필수적이라고 주장함.

- 2012년 Seth Elliot의 정의에 따르면, 실시간 환경 테스트는 실제 사용자의 다양한 환경을 활용하며 사용자에게 위험을 최소화하는 것을 목표로 함.

- 과거의 테스트 방식과 달리, 현재는 더 나은 프레임워크와 테스트 작성 방법을 활용하고 있음.

- 카나리 릴리스 등의 방법론으로 실험과 위험 감소를 동시에 추구함.

2. 지속적인 배포를 위한 테스트 환경과 미래

- 현재 스테이징 환경은 여전히 목적이 있지만, 우리는 지속적인 배포가 산업 표준임을 strongly 믿고 있습니다.

- 회사는 생산성을 높이기 위해 생산을 자주 배포해야 한다고 인식하고 있으며, 이에 따라 지속적인 배포 자동화가 필수적입니다.

- 하지만 스테이징 환경에서는 불안정성이 문제로 테스트 속도가 느린 편입니다.

- 우리는 유닛 테스트와 통합 테스트를 계속 진행할 것이며, 새로 졸업하는 대학생들이 테스트 가능한 코드를 작성할 수 있기를 바랍니다.

- 또한 점점 복잡해지는 애플리케이션에 대해 복원력 공학을 수행해야 하며, 이는 사이트 다운 및 생산 문제를 예방하는데 도움이 될 것입니다.

- 마지막으로 스테이징 환경의 가치는 다른 곳에서 찾아야 하며, LinkedIn에서는 생산 환경에서 더 많은 테스트를 수행하여 이 격차를 메우고 있습니다.

3. 마이크로소프트의 GitHub 인수와 링크드인의 개발 문화

- 저는 마이크로소프트의 일원으로서 GitHub 인수 소식을 듣고 기뻤습니다.

- 링크드인에서는 오픈 소스 프로젝트를 위해 GitHub를 사용하며, 내부 코드에는 다른 플랫폼을 사용합니다.

- 링크드인의 소프트웨어는 10,000개의 코드 베이스로 구성되어 있으며, 이 중 60%는 활성 상태입니다.

- 매일 100,000개의 Gradle 빌드를 수행하고, 링크드인의 주요 애플리케이션인 linkedin.com은 약 700만 줄의 코드와 300명의 고유 기여자가 있습니다.

- 코드 리뷰는 링크드인에서 필수이며, 이를 통해 훌륭한 공예 수준을 달성하는 데 큰 도움이 됩니다.

4. 2015년부터 시작된 지속적 배포와 개발자 책임

- 2015년부터 지속적 배포를 도입해 다양한 형태의 배포를 경험하고 있으며, 이는 특히 소규모 마이크로서비스가 존재하던 링크드인에서 큰 도움이 되었다.

- 개발자들은 테스트에 대한 책임을 지며 품질 향상을 위해 고민해야 했고, 과거와는 달리 이제는 code push와 feature push를 분리하여 배포하는 방식을 채택했다.

- 이 과정에서 새로운 앱 버전을 프로덕션에 배포하더라도 사용자에게는 새로운 기능이 즉시 보여지지 않으며, 점진적으로 기능을 노출하는 전략을 통해 이뤄진다.

- 또한, 링크드인의 스테이징 환경은 과거에 유용했으나 현재는 안정성을 유지하는 데 어려움을 겪고 있다.

5. 배포 환경의 안정성과 복잡한 시스템 반복의 어려움

- 배포 환경의 안정성을 묻는 질문과 함께, 개인의 경험에 따라 다른 의견이 있다는 사실이 드러났다.

- 특히, '내 서비스는 불안정하지만 모두가 안정적이길 원한다'는 모순된 상황이 발생하며, 이를 해결하기가 어렵다는 점이 강조되었다.

- 또한 복잡한 분산 시스템을 제품에서 복제하여 실제 가치를 얻는 것이 매우 힘들고, 운영 환경에서의 문제를 발견하긴 어렵지 않지만 복잡하다는 점이 지적되었다.

- 현재 중소형 애플리케이션들은 수십 개의 마이크로서비스로 구성되며, 모든 애플리케이션이 점점 분산 시스템으로 변화하는 경향을 보이고 있다.

6. 소프트웨어 배포 전략: 지속적 배포 및 카나리아 릴리스

- 시행착오를 겪으며, 가치를 발견하는 것은 중요하지만, 과정이 힘들다는 점을 명심해야 한다.

- 현지 개발 환경에서는 API 서비스 호출을 시뮬레이션 할 수 있어, 프로덕션 안정성을 활용하여 필요한 모든 작업을 수행할 수 있다.

- 또한, 카나리아 릴리스는 새로운 소프트웨어 버전을 리스크를 줄이며 점진적으로 배포하는 기술로, 적은 수의 사용자에게 먼저 적용하여 문제를 파악할 수 있게 한다.

- 좋은 메트릭을 보여주면, 다른 호스트로 배포해 문제가 발생하기 전에 미리 확인하는 전략을 통해 대처한다.

- 그러나 카나리아 릴리스는 주요 방법이 되어서는 안 되며, 코드 리뷰와 테스트를 통해 문제를 발견해야 할 필요가 있다.

7. 캔러리 출시와 A/B 테스트의 중요성

- 캔러리 출시에서는 CPU와 메모리와 같은 하드웨어 메트릭, 예외 발생 여부 및 비즈니스 메트릭을 포함한 여러 신호를 추적해야 하며, 이로 인해 노이즈가 발생할 가능성이 있다.

- 우리의 목표는 모든 팀이 완전 자동화된 캔러리 출시를 가능하게 하는 것이지만, 복잡한 앱에서는 항상 개발자나 SRE가 출시 상황을 모니터링해야 할 수 있다.

- A/B 테스트는 사용자 참여와 만족도를 평가하기 위한 표준 방법으로, 두 가지 코드 경로를 통해 특정 집단의 사용자가 새로운 기능을 보고, 다른 집단은 이전 기능을 경험하도록 설정한다.

- 우리는 A/B 테스트 프레임워크를 실험과 좋은 변경 사항 식별뿐만 아니라 리스크 완화에도 사용하며, 기능이 준비되지 않았을 경우를 대비해 기능 토글로 코드를 감추는 방식이다.

- 브랜치 바이 추상화 전략은 피처 토글과 A/B 테스트를 결합해 데이터 기반 의사 결정을 가능하게 하며, 이는 링크드인의 데이터 중심 접근법의 핵심이다.

8. A/B 테스트의 중요성과 개발자 생산성 향상

- A/B 테스트는 웹 사이트의 변화가 사용자에게 의미가 있는지를 확인하는 데 사용되며, 백엔드와 같은 다른 영역에서도 활용된다.

특히 검색 알고리즘 개선에 A/B 테스트의 필요성을 느꼈으며, 사용자가 검색 결과 클릭률을 통해 검색 품질이 향상되었는지를 알 수 있다.

- LinkedIn에서는 회원들에게 최상의 경로 기회를 제공하기 위한 혁신의 한 방법으로 A/B 테스트를 활용하고 있으며, 이는 개발자에게도 좋은 결정을 내리도록 돕는다.

- A/B 테스트는 위험 완화뿐만 아니라 데이터 기반 결정을 내리는 데 필수적이며, 코드를 복잡하게 만들지만 그만한 가치를 지닌다.

이러한 과정을 통해 효율성을 유지하고, 문제 발생 시 특정 기능만 축소할 수 있어 안정성을 높일 수 있다.

9. A/B 테스팅과 코드 관리의 중요성

- 기능을 실행한 후에는 오래된 코드 경로를 삭제하는 방법이 필요하다. 내부적으로 자주 실행되지 않는 오래된 코드 부분이 존재할 수 있으며, 이를 자동으로 추적하고 수정 책임자를 두는 시스템이 중요하다.

- 특정 맥락에서 A/B 테스팅을 사용하며, 모든 엔지니어는 자신의 코드를 A/B 테스팅으로 감싸는 것이 요구된다. 코드 리뷰와 기업 문화가 이를 강제하고, 이를 잊으면 리뷰에서 문제가 제기될 수 있다.

- 실험을 진행하며 1,000개 이상의 메트릭을 수집하고, 수백 개의 실험이 동시에 실행되고 있어, 메트릭과 실험의 상호작용에서 문제가 발생할 수 있다. 이러한 문제를 해결하기 위한 다양한 창의적인 방법을 찾아냈다.

LinkedIn.com의 아키텍처는 테스트를 수행하는 방식 중 일부를 보여준다. 여러 가지 코드베이스를 가지고 있으며, 모든 클라이언트는 하나의 API 서비스를 통해 마이크로서비스와 통신한다.

- API는 마이크로서비스와 백엔드에서 결과를 집계하여 클라이언트가 최적의 방식으로 활용할 수 있도록 전달하는 깔끔한 아키텍처를 제공하여, 빠른 속도로 기능 개발이 가능하게 한다.

10. 링크드인이 적용한 지속적 배포 패턴

- 링크드인에서는 3x3 지속적 배포 패턴을 적용하며, 이는 하루에 세 번의 생산 배포를 목표로 하고 배포까지의 최대 시간은 세 시간으로 설정된다.

- 세 시간이라는 시간 제약은 테스트 전략을 수립하는 데 매우 중요하며, 빈 엔드 투 엔드 테스트는 불가능하다는 것을 깨닫게 된다.

또한, 고유한 테스트 접근 방식을 통해 안정적인 테스트를 유지하면서 지속적 배포를 가능하게 했다.

- 그러나 몇 가지 도전 과제가 있으며, 예를 들어, 더미 데이터가 오래되어 갱신이 필요하다는 문제와 함께, 테스트 속도와 신뢰성에 대한 관리가 중요하다.

- 마지막으로, 파이프라인에서 크로스 브라우저 테스트나 실제 모바일 장치 테스트는 포함되지 않으며, 이는 느리고 신뢰할 수 없는 결과를 초래할 수 있기 때문이다.

11. 모바일에서의 배포과정과 마이크로서비스 테스트

- 모바일에서의 카나리 릴리즈는 기존 애플리케이션을 한 번에 변경할 수 없기 때문에 업데이트에 따른 다양한 문제가 존재한다.

- 회사의 경우 앱 스토어에 새로운 버전을 보낼 때 유저가 이전 버전을 그대로 사용할 위험이 있으므로, 주기적인 업데이트 주기가 더욱 중요하다.

- 일반적으로 서버 쪽에서는 매일 업데이트를 할 수 있지만, 모바일은 도전 과제가 다르며, 가능한 한 짧은 배포 주기를 유지해야 한다.

- 우리는 과거 모노레포에서 스타트업 방식으로 마이크로서비스로 진행하며 800개의 코드 베이스로 전환했고, 약 400만 줄의 코드를 제거하였다.

- 현재 500개의 마이크로서비스와 약 3,500개의 REST 리소스를 보유하고 있으며, 각 서비스는 독립적인 개발 및 배포를 지원하고 있다.

12. 링크드인에서의 생산성 및 테스트 전략

- 단일 저장소에서 생산성을 높이기 위해 속도가 핵심이다.

- 우리는 독립적인 주기와 빠른 배포를 목표로 하며, 마이크로서비스 개발에 REST 및 Java 기반의 RESTful 프레임워크를 사용한다.

- 테스트 프레임워크는 생산 트래픽을 기록하고 재생하는 기능을 제공하지만, 일부 도전 과제가 존재하며 모든 프로젝트에서 표준으로 사용하고자 한다.

- 다크 카나리 테스트와 같은 다양한 프레임워크를 통해 마이크로서비스의 테스트를 구현하며, 사용자에게 미치는 영향을 최소화할 수 있는 전략을 가지고 있다.

- 링크드인 내 검색 기능 개발을 위한 프레임워크도 제공하여, 팀이 중복 개발을 피할 수 있도록 하고 있다.

13. 분산 시스템에서의 테스트와 회복력 엔지니어링

- 상태를 가진 서비스인 이 시스템은 인덱스 파일과 검색 데이터에 의존하여 작동하며, 이 파일은 매우 크고 복잡한 구조를 가지고 있다.

- 생산 데이터를 사용하여 문제를 테스트하는 것이 중요하지만, 이는 여러 문제를 야기할 수 있으며, 이러한 문제를 사전에 해결하는 것이 필요하다.

- 회복력 엔지니어링은 시스템의 문제를 사전에 파악하고 해결하는 데 중점을 두어야 하며, 포스트모템보다 문제가 발생하기 전에 해결 방법을 알아내는 것이 중요하다.

- 또한, 복잡한 분산 시스템에서 발생하는 실패는 자동 롤백을 통해 신속하게 대응할 수 있고, 사용자가 피해를 최소화할 수 있도록 해야 한다.

- 마지막으로, 실제 사용자와 환경의 다양성을 활용하여 프리 프로덕션에서는 발견할 수 없는 버그를 찾아내는 것이 필수적이다.

요약(한국어) : https://lilys.ai/digest/1095468?s=1&nid=-1=

이 게시글은 [lilys.ai]를 통해 요약되었으며, 정보 공유 목적으로 게시되었습니다. 원문 게시물에 대한 책임이나 이해 관계가 없습니다. - 소프트웨어QA 포럼