AWS in action 리뷰

11 Jun 2017

한빛출판사의 Amazon Web Service in action 를 읽고

서버, 인프라, 클라우드, 백엔드 등에는 익숙하지만, AWS에 대해 생소한 사람들이 Tutorial로 사용할 수 있을 정도로(?) 친절한 책이다. 어느 정도는 클라우드, 인프라에 대한 지식을, 또 어느정도는 백엔드 레벨의 개발 지식을 필요로 하는 책이다. 주로 GUI를 통한 사용보다는 CloudFormation등 CLI, API를 통한 Infrastructure as Code 방식의 사용에 관해 설명하고 있어, 실제로 github에 있는 코드를 내려받아 실습해 보면서 읽는 방식이 내용을 이해하는 데 도움이 될 것 같다. 1~9장에서는 AWS의 각 구성요소에 대한 설명을, 10~14장에서는 그것들을 활용해 Scale out, Auto Scaling, HA구성, 디커플링 등을 하는 방법을 담았다. GUI에 관한 설명은 거의 없어 초보자에게는 적합하지 않을 듯 싶고, AWS를 어느정도 사용해 본 뒤, 해당 시스템을 좀 더 확장하고 활용하려는 목적에 적합할 듯 하다. 충분히 좋은 책이라고 생각하지만, 개인적으로 10~14장에 대한 내용이 좀 더 많았으면 더 좋았을 것 같다. 그리고 개인마다 다르겠지만, 장애허용, 고가용성, 가용 영역 등 일부 인프라 관련 용어와 AWS용어들은 굳이 국문화 하려고 한 부분이 오히려 좀 더 부자연스럽게 느껴졌다. 또한, 책 제목부터 그래서 당연하겠지만, AWS에서의 자동화, AWS에서의 활용에 대해서만 얘기하고 있어, 그 개념 자체라면 몰라도 코드를 그대로, 다른 퍼블릭 클라우드에서 활용할 수는 없을 것 같다.

장별 요약 및 소감

AWS소개

• Cloudformation을 통한 인프라 자동 생성, immutable infrastructure의 개념 하에, 서버 설치 후 상태의 변경이 없도록 하는 도구.
• AWS는 Xen 기반 오픈소스 하이퍼바이저를 사용, HVM, 인텔 Vt-x 플랫폼, 가상 리눅스 서버로 3.8+ 이상의 커널을 사용하면 최상의 성능이 날 수 있음.

가상서버(EC2) 사용하기

• 인스턴스 생성 시에 Tags는 기술적으로는 크게 의미가 없다. 관리목적으로 인스턴스가 많아진다면 체계적으로 이름을 넣어야 함.
• 인스턴스 Launch후 키를 생성하는데, 잊어버렸다고 해도 다시 생성 가능하다. 윈도우 환경에서는 pem을 puttygen등을 통해 ppk로 변경해야 putty를 통해 접속할 수 있다. 리눅스에서는 pem을 사용하여 접속.

CLI, API, SDK

• 코드로 인프라 관리하기 - JIML기반 < Cloud formation(블루프린트) -> 둘 다 json기반이긴 하나, Cloud formation이 더 일반적인 것 같다.
• GUI보다, CLI, API를 사용해야 하는 이유? 코드는 재사용 가능하며, 작업 시간을 대폭 줄여준다.

배포 자동화

• 사용자는 모든 가상 서버에 사용자 데이터라는 16KB미만의 소량 데이터를 삽입할 수 있음, 일반적으로 부팅 프로세스의 끝에서 쉘 스크립트로 실행하여 사전 작업을 처리하게 할 수 있다.(baseimage를 AMI로 떠 놓는 방법과 병행하면 좋을 것 같다.)
• 배포를 위한 도구들
  • Beanstalk - 간단한 웹 어플리케이션 등을 배포(jenkins등과 포지션이 같다.)
  • Opswork - AWS 기반 chef, 일종의 devops 도구

RDS

• 오로라(Auro) - MySQL과 호환되면서, 더 낮은 비용, 가용성과 성능을 보장하는 RDS
• DB특성상 On premise 시스템 대비 가장 효율적인 AWS 객체인 듯 하다.(관리할 포인트가 줄어듦) 다만, 기존 사용자들에게는 비즈니스의 핵심인 데이터가 다른 곳(?)에 존재한다는 꺼림직함을 극복해야 함
• 가용성을 보장하는 HA구성도 가능, Read를 확장하는 방식인 수평 확장도 가능함
  • 고가용성(HA) DB활용 - 비용은 2배, Master와 Standby로 나뉘어, 한쪽 DB로만 서비스.
  • 읽기 복제(Scaleout)- 읽기만 가능한 DB를 별도로 구성하는 방법, 한쪽 서버에만, 읽기/쓰기를 가능하게 하고, 다른쪽은 읽기만 가능, MySQL/PostgreSQL만 지원

고가용성 달성하기

• 클라우드와치 알람으로 정기적인 헬스 체크를 통해 해당 가상 서버의 장애를 감지, 장애 발생시 해당 새로운 가상서버를 시작하도록 설정 가능
• AWS는 전세계의 여러 리전(Region)으로 나뉘어져 있으며, 해당 리전 안에서 여러개의 가용 영역(AZ:Availablity Zone)으로 나뉜다. 글로벌 서비스가 아닐 경우 서비스 가용성을 위해 여러개의 AZ에 서비스를 골고루 분산해야 하며, 글로벌 서비스의 경우 Region을 적절히 나누는 것도 고려해야 한다.
• 고가용성 달성을 위한 여러가지 방법들
  • 서버 부팅시 특정 EIP를 자동으로 연결
  • Route53등으로 가상서버를 연결하는 DNS를 갱신
  • ELB를 사용하여 가상 서버를 추가
• 오토스케일링을 이용하여 장애시, 부하시 다른 AZ에 새로운 가상 서버를 생성할 수 있다.

인프라 디커플링하기, ELB와 SQS

• ELB로 외부로부터 들어오는 서비스 종속성을 줄이는 방법 - ELB를 이용한 동기 디커플링
• SQS를 통한 비동기 디커플링. 단, SQS는 단지 큐일 뿐, ActiveMQ같은 메세지 브로커가 아니다.

장애허용 시스템 설계하기

• 장애허용(Fault Tolerance-사용자가 장애를 느끼지 못함) > 고가용성(High Availablity-일시적으로 사용불가하나 회복됨)
• EC2인스턴스 중복 사용으로 단일 실패지점을 줄인다.
• 멱등 이미지 상태 머신
  • 멱등(idempotent)이란? 연산을 여러번 하더라도 결과가 달라지지 않는 것. 상태를 변화시키지 않는. 가장 쉬운 예로, 테이블이 있을 경우 생성하지 않는다, 디렉토리가 있을 경우 생성하지 않는다. 등
• 인프라 디커플링 등

스케일 업, 스케일 다운를 오토스케일링 그룹을 통해 자유롭게 하며, 좀 더 적은 비용으로, 원활한 서비스를 구성할 수 있다.