아마존 혁신의 문화: Amazon Culture of Innovation
아마존의 미션
아마존은 기술 기업으로 알려져있지만 고객을 중심에 두고 해결책으로 기술을 사용할 뿐이다.
제프 베조스가 아이템으로 책을 가장 먼저 선정한 이유는 만져보지 않아도 구매가 가능하며, 이와 동시에 썩지 않는 등 보관과 배송이 용이하다는 이유도 있었지만 가장 큰 이유는 단일 품목 중에서 가장 다양한 제품이 있었기 때문이다. 즉, 고객 중심적 사고의 결과였으며 이후에 아마존 킨들 역시 이러한 맥락 상에서 구매한 책을 바로 다운로드 받아서 볼 수 있도록 출시가 된 것이다.
flywhell 다양한 선택지를 제공. 책에서 현재 자동차까지. 다양한 옵션을 제공하면 고객의 경험치가 높아진다. AWS도 1500개가 넘는 소프트웨어 기업이 7000 개가 넘는 소프트웨어 제공. 선순환을 이루면. 규모의 경제를 통해서 다시 원가 절감. VALUE PROVISION PRICE, SELECTION(선택지), CONVINIENCE
CULTURE
16개의 leadership principle. 전제조건이 있다. 전 직원이라는 가정하에 이 LP가 적용된다. 왜 필요했을까? 13년 전에 24,0000명 작년에는 145만명, 폭팔적으로 성장. 하나하나 지시가 불가능해진다. 하나의 거대 기업보다는 수천 개의 start-up을 지향. 지켜야만할 행동 강령을 주어 스스로 판단하고 자율적으로 행동할 수 있도록 한 것이 LP.
이러한 LP는 채용 과정에서도 매우 중요하게 다뤄지며 승진과 인사고과 평가시에도 어떤 LP를 직접적으로 보여주었는가. 또한 커뮤니케이션과 회의 시에도 사용된다.
Invent and Simplify
무언가 아이디어를 냈을 때 사람들이 모두 고개를 끄덕이면 혁신보다는 그냥 개선의 아이디어일 확률이 높다. 혁신적인 아이디어라고 생각하면 오래 참고 견뎌라. AWS를 시작할 때도 여론은 비슷한 평가. 낮은 이익률로 인해서 주주들에 의해 많은 challenge가 있었다. 그러나 현재는 이익의 절반 이상의 가장 많은 기여를 하는 사업부.
Working Backwards is a process
거의 모든 사업모델 상품, 서비스까지 모두 이를 적용. 초기 아이디어를 만드는 것부터 고객을 위한 것인지 파악하는 것.
- who is the customer => 세그멘테이션보다 페르소나 단 한 사람을 정해서 집중해 서비스를 설계
- painpoint를 가지고 있고 우리가 어떻게 해결해 줄 수 있는가?
- 명확한 value proposition를 가지고 있는가?
- 사용케이스를 설명할 수 있어야 한다.
이와 더불어, 스스로 보도자료와 FAQs를 작성해보면서 설계한 것에 대해서 한 번 더 점검한다.
- 65세의 캠핑카에 사는 가상의 인물 존을 설정하고 진행
- painpoint : 집이 없어서 배송을 친구의 집 혹은 비싼 값을 지붛하고 오프라인에서 구매
- 편의성의 측면에서 매우 clear하게 해결한 사례
- 가장 많은 사용자들은 현재 여행자 혹은 출장을 다니는 사람이 현재 최대 소비자가 되었다.
organization
single threaded ownership
한 팀이 오너십을 가지고 책임을 진다. 크던 작던 하나의 문제를 해결할 수 있는 단일 팀을 만들어야 한다.
2004년 제프 베조스가 고안한 아이디어로. cross-functional한 사람들로 타이트하게 이뤄진다. R&D와 운영이 분리되어 있으면 책임을 전가할 가능성이 높다. 같은 팀에 two-pizza로. 프로젝트가 커지면 다시 팀을 쪼개며, 민첩성을 유지하려고 노력.
architecture
loosely coupled System
상호 의존성을 낮추며 사업을 진행. 더 빠르게 scale up을 할 수 있도록.
기존의 monolitic한 'Primitive'하게 수정하며 MSerA를 구현. 수많은 primitive들로 구성되어 있다. amazon.com 에서 검색, 상품 이미지, 추천 모두 별도의 어플리케이션으로 구성되어 있다. 이러한 아키텍처가 제공된 것이 또 aws cloud. 필요하다면 수 천 개의 컴퓨터를 제공해주기도 했다가 또 필요가 없을 시에는 반납을 할 수 있어 실패에 대한 비용을 낮출 수 있다.
알아두면 쓸모 있는 EC2 이야기
수백만명의 고객들이 AWS 컴퓨터 상에서 다양한 워크로드를 제공하고 있다.
M1 방식만 존재했다. 그러나 2010에는 4개의 인스턴스가 만들어졌다. 현재는 OS 종류와 다양한 환경과 비즈니스 요구에 충족할 수 있도록 다양한 옵션이 존재한다. 애플리케이션 및 워크로드에 맞는 적합한 프로세서를 제공한다.
Amazon EC2 수명주기
수명주기 이해가 필요하다. EC2가 시작하는 순간부터 종료될 때까지 다양한 상태로 전환되기 때문이다. 또한 각 상태에서 요금의 발생과 각 상태에 따라 변경되는 부분이 있다. 처음 인스턴스를 구성하여 시작하면 pending 상태로 전환이 도고 시작 시 지정한 인스턴스 유형에 따라 호스트 컴퓨터의 하드웨어가 결정된다. 또한 구성에 따라 퍼블릭 IPv4를 할당 받고, running 상태로 전환된다. 이 상태부터는 비용이 청구되기 시작한다.
여기서 중요한 부분은 2가지 정지 상태나 최대 절전모드에서 다시 running 상태로 전환 시 다시 pending 과정을 거치기 때문에 호스팅 컴퓨팅이나 public IPv4가 변경된다.
- 만약 IP가 유지되어야 한다면 탄력적 IP를 사용할 수 있으며 또 다른 하나는 EBS 볼륨을 사용해야지 데이터가 유지된다.
- 또 다른 볼륨 방식은 인스턴스 스트어 볼륨의 경우 stop 할 수 없고 데이터 유지가 어려우므로 이 점에 유의해야 한다.
인스턴스의 사이즈에 대한 문의가 많다고! 그런데 인스턴스는 한 번에 최적의 타입을 선택하는 것이 아니라 계속해서 모니터링하며 서비스에 맞게 수정하며 최적화 하는 것. 위와 같이 표기법을 통해서 인스턴스 유형을 제공해준다.
auto scaling은 인스턴스의 자동 복구와 I/O 트래픽에 따라서 EC2 인스턴스의 수를 정해 놓은 용량만큼 자동으로 늘려주고 줄여주는 기능이다. 이를 통해서 월말 등 트래픽이 늘어 날 때 유연하게 대처할 수 있다. 다만 예측이 어려울 때는 더 호율적으로 해야할 필요성.
이러한 니즈를 충족 시킬 수 있는 것이 EC2의 spot instance이다. 경매와 비슷한 방식을 통해서 온디맨드 인스턴스와 동일하게 작동. 그러나 EC2 pool로 용량이 회수되거나 기본 가격이 높아질 경우 인스턴스 중단이 발생한다.
위는 워크로드에 따른 스팟 인스턴스 사용의 예이다.
대규모 서비스를 위한 AWS의 대표적인 NoSQL Database 서비스 알아보기
관계형과 NoSQL 데이터 베이스
2021년 12월 db-engines.com의 데이터베이스 인기순위 380개가 넘는 데이터 베이스 엔진이 등록되어 있고 top10에 3개의 NoSQL 데이터베이스가 있다. 점차 많은 애플리케이션에서 NoSQL을 채택해나가고 있음을 볼 수 있다. 2000년대 초반까지만 하더라도 우리가 서비스나 시스템을 만들 때 사용할 수 있는 데이터베이스의 종류는 많지 않았다. 그러나 4차 산업혁명과 더불어 다양한 프로그래밍 언어와 런타임이 생겨났고 데이터베이스 역시 매번 새롭게 등장하고 있다.
현재 관계형과 NoSQL 데이터베이스는 서로의 장점을 흡수하며 발전해나가고 있다. 대표적으로 관계형 데이터베이스 중 스키마에서 자유로운 JSON 데이터타입이라는 것을 볼 수 있고 확장성을 흡수해나가고 있으며 또한 NoSQL 데이터베이스들은 관계형 데이터베이스가 갖는 주요 특징인 트랜잭션과 보조 인덱스를 흡수하며 단점을 제거해나가고 있다.
