Amazon의 운영 효율성 – Operational Excellence (2-1) 개발 도구

1. 아마존 초기 개발 및 구축

IT 엔터프라이즈 시스템에는 다양한 개발 및 운영 도구가 필요합니다. 기존 데이터베이스 엔터프라이즈에서 실행할지 또는 클라우드에서 실행할지 여부.

테스트 자동화
구성 관리
소프트웨어 배포
모니터링 및 시각화
보고하다
변경 관리
사고 관리
질문을 하다
보안 감사
예측 및 계획

이러한 개발 도구의 중요성을 이해하기 위해 시스템 아키텍처를 변경하는 과정에서 소프트웨어 배포가 무엇을 의미하는지 설명하겠습니다. 앞서 기사에서 언급했듯이, amazon.com의 초기 서점 시스템은 전면 페이지, 웹 통합 서버, 여러 개의 내부 데이터베이스 툴을 갖춘 3계층 구조로 비교적 간단하다.

개별 응용 프로그램을 사용할 때 특정 개발자가 변경한 사항으로 인해 공유 시작 파이프라인의 다른 개발자와 충돌할 수 있습니다. 이 작업에는 몇 가지 조정이 필요합니다.

모든 팀이 위반하지 않도록 먼저 변경 사항을 조정해야 합니다.보안 및 성능을 위해 종속 라이브러리를 업그레이드하려면 모든 개발자를 동시에 업그레이드해야 합니다. 빨리 고쳐야 할 경우에는 패치가 필요하면 똑같이 고쳐야 합니다.감사 및 승인 프로세스. 그것은 보통 매주 일하면 해결된다.이 문제는 금요일에 발생할 것입니다.저녁 또는 이른 아침에 변경 사항을 병합합니다.

휴스턴 팀 및 명령줄 도구

기능이 개발되면 도입 단계에서도 문제가 발생한다. 모든 리소스가 공유되므로 테스트 후 전체 애플리케이션을 재구성하고 구성 요소를 다시 배포해야 합니다. 이 프로세스를 통해 한 줄 코드 또는 하위 코드를 변경해야 합니다.고비용의 "단방향" 및 "프로세스 변경"이 구축 관리를 추가합니다.도로 품질 관리에는 위험과 실패 가능성이 있으며, 전체 배치 사이클이 계속 지연되고 있습니다.

당시 아마존은 휴스턴이라는 중앙집권 연대를 창설했다.팀, Perl 스크립트를 사용하여 이러한 단일 칩 애플리케이션을 배포합니다.모든 팀이 휴스턴에 전화해서 요청했어요.유통을 요청하면 병목 현상이 발생할 것입니다.

대부분의 빌드 및 배포 작업은 명령줄 스크립트를 사용하여 생성됩니다..NFS 서버가 NFS(네트워크 파일 시스템) 서버에 중앙 집중화하고 필요에 따라 복사하여 사용하지 못했습니다.가끔 문제가 생기기도 한다.

간단한 서버 관리에서 고객 서비스에 이르기까지 명령줄 도구 서비스.예를 들어 고객에게 환불을 요청하는 CS 운영자는 다음 명령을 사용합니다.

마찬가지로 하트 도구는 모든 쇼핑몰 기능, 고객 서비스 및 서비스에 동일한 데이터베이스를 사용하므로 모든 사용자가 프로덕션 서버에 로그인하고 Unix 명령을 실행해야 합니다. 누군가 제작에 실수를 하면 상당히 위험할 거예요.

서비스가 급속도로 발전하면서 아마존은 더 이상 받아들일 수 없는 고객이 되었습니다.중앙 혁신과 신속한 기능 개발 및 배치의 문화. 이에 아마존은 시스템과 기업조직의 전반적인 구조를 동시에 바꾸기로 했다.

분할 단일 칩 응용 프로그램

앞서 기사에서 언급했듯이 아마존의 단일 목록 웹사이트는 슬라이스 아키텍처를 비즈니스 영역과 기능으로 세분화하여 재구성하기 시작한다. 모든 작업이 한 번에 완료되는 것은 아니지만 의류는 서비스 지향(SOA)이며 오늘날의 마이크로 서비스 아키텍처는 계속 발전하고 있습니다.진열하다

Amazon.com 사이트를 방문하면 데이터를 수집하고 전체 페이지를 구성하기 위해 최소 100개의 별도 서비스가 필요합니다. 기타 페이지 객체의 요소 및 호출 횟수는 상품 표시, 결제 페이지 등에 의해 호출되는 서비스의 종류, 캐시 효과 등에 따라 조금씩 다를 수 있습니다.

예를 들어 다음 Amazon 제품 페이지에서 다음을 수행합니다.각 서비스 팀은 제품 정보, 검토 데이터, 전자책 가용성, 판매자 정보, 가격, 재고 등을 생성하여 API로 전송합니다.

한 번의 클릭으로 구매할 수 있는 경우 지금 구매 버튼을 만듭니다.
여기서 지금 구매 버튼을 클릭하면 클릭한 주문으로 돌아갑니다.가능하면 고객은 클릭하는 즉시 서비스 결과를 보고 주문합니다. 한 번 주문하기 어려운 경우 버튼이 나타나지 않습니다.HTTPA는 PI 정의 호출 결정 서비스를 제공하고, 서비스의 API를 유지 및 안정화하며, 서비스는 정상입니다.항상 제공하다.

개별 서비스를 새로 배포하거나 갱신할 경우 일부 제품 페이지가 제한되고 쇼핑 환경에 큰 영향을 미치지 않습니다. 각 서비스 운영 팀은 전체 서비스를 중단시킬 염려 없이 신속하게 기능을 구현하고 구현할 수 있습니다.

피자팀 2팀 변경

기존 시스템의 아키텍처를 변경하는 것은 좋은 결과를 가져오지 않습니다. 1967년 멜빈 콘웨이의 이름을 딴 콘웨이법은 기업체제와 조직문화로 고통받는 이들에게 중요한 인식을 심어주었다.

소프트웨어를 제대로 개발하고 운영하기 위해서는 개발자 간의 잦은 의사소통이 필요하다는 얘기다. 분산 아키텍처를 생성할 때는 팀 조직도 분산해야 합니다.소프트웨어 인터페이스 구조는 개발 그룹(예: 메일 통신)의 구조와 비슷하거나 전화 승인 후 팀워크를 유지합니다.메소드에서 제공하는 모드에서 데이터 공유 방법은 REST API보다는 FTP 또는 Batch Excel 파일에 가깝습니다.)

전체 아키텍처를 나눈 아마존은 소규모 팀(점심용 피자 2판 포함)으로 나눠 각각 자체 서비스를 만들고 운영할 수 있게 된다.  TwoPiza 팀은 내부 및 외부 고객과 협업, 로드맵 및 서비스를 제공합니다.사양, 코드 생성, 테스트 실행, 생성, 프로덕션 배치 및 운영의 완전한 자율성.

두 피자 팀은 서비스에만 집중하고 API를 통해 다른 팀 서비스와 소통한다. 인원이 적어 개발에 필요한 다양한 개발도구를 개발할 수 없다. 초기 아마존 시스템에서는 수백 개의 지원을 만들었습니다.피자 팀의 셀프 서비스 도구는 매우 중요합니다.