API 아키텍처 마스터링

5장. API 배포 및 릴리스

이 작품은 AI를 사용하여 번역되었습니다. 여러분의 피드백과 의견을 환영합니다: [e-mail]

이 장에서는 디자인, 빌드 및 테스트에서 대상 환경에서의 실행으로 이동하는 방법을 함께 살펴봅니다.

소개에서 소개한 회의 시스템 사례 연구를 생각해 보세요. 단일 사용자 인터페이스와 서버 측 애플리케이션이 있었습니다. 서버 또는 사용자 인터페이스에 업그레이드를 배포하려면 다운타임이 발생할 가능성이 높습니다. 배포와 릴리즈 작업이 긴밀하게 연결되어 있고 분리할 수 없을 수도 있습니다. 또한 배포에 문제가 발생하면 변경 사항을 롤백하는 데 시간이 걸렸을 수도 있습니다. UI와 서버 구성 요소 간의 연결이 느슨해지면 배포 및 릴리즈에 더 많은 옵션을 제공하는 방법을 살펴보는 것과 더불어 기존 회의 시스템에 대한 몇 가지 옵션을 살펴볼 것입니다.

트래픽 관리의 도입으로 배포와 릴리스를 분리할 수 있는 옵션이 제공됩니다. 이 장에서는 이에 대해 자세히 살펴보고 변경 사항을 롤아웃하는 데 사용할 수 있는 회의 시스템 옵션을 살펴보겠습니다. API 버전 관리가 회의 시스템에서 릴리스 모델링 옵션에 어떤 영향을 미치는지 고려해야 합니다.

롤아웃의 핵심 고려 사항 중 하나는 변경의 성공 여부를 파악하는 것입니다. API 아키텍처는 본질적으로 분리되어 있으므로 성공적인 릴리스를 수행하려면 올바른 메트릭, 로그 및 추적을 사용할 수 있는지 확인하는 것이 중요합니다. 메트릭의 고려 유형과 릴리스 및 사고 관리/문제 해결에 어떻게 도움이 되는지 살펴봅니다.

마지막으로, 최종적인 일관성이 변화에 미치는 영향과 애플리케이션 수준에서 문제가 발생할 수 있는 부분에 대해 살펴봅니다. 프록시와 같은 추가 인프라 계층을 도입하려면 캐싱 및 헤더 전파에 대한 결정이 필요합니다. 이러한 고려 사항과 의견 대립이 있는 플랫폼을 선택하는 이유를 살펴봅니다.

배포와 릴리스 분리

이 장을 최대한 활용하려면 배포와 릴리즈의 차이점을 이해하는 것이 중요합니다. 배포 는 이제 시스템에서 실행 중인 프로세스가 있기 때문에 기능을 프로덕션 환경으로 가져오는 것을 포함합니다. 배포되었지만 프로덕션 시스템과의 상호 작용을 통해 새 기능이 활성화되거나 실행되지는 않습니다. 이러한 분리를 달성하는 방법에는 여러 가지가 있으며 곧 살펴볼 것입니다. 릴리즈는 새 기능을 통제된 방식으로 활성화하여 새 기능 도입의 위험을 제어할 수 있도록 하는 것입니다. Thoughtworks Technology Radar 에서 배포와 릴리즈의 차이점에 대해 잘 설명되어 있습니다:

지속적 배포를 구현하는 것은 많은 조직에게 여전히 어려운 과제이며, 배포와 릴리스를 분리하는 것과 같은 유용한 기술을 강조하는 것이 여전히 중요합니다. 애플리케이션 구성 요소나 인프라에 변경 사항을 배포하는 행위를 지칭할 때는 배포라는 용어를 엄격하게 사용하는 것이 좋습니다. 비즈니스에 영향을 미치는 기능 변경이 최종 사용자에게 릴리스될 때는 릴리스라는 용어를 사용해야 합니다. ...