Category: AWS

A contents of Amazon Web Services

SSM 에이전트를 사용해 Windows Server에 CloudWatch 구성하기

AWS 에서 Windows 시스템을 운영하고 있다면 Custom Metric 을 수집하고 싶을 것이다. Windows 시스템의 경우에 AWS 에서는 CPU Utilization 을 기본 지원할뿐 Memory, Disk Usage 는 Custom Metric 을 운영자가 손수 구성해야 한다.

SSM Agent

CloudWatch 구성을 위한 가장 쉬운 방법은 SSM Agent 를 이용하는 것이다. SSM Agent 는 AWS 에서 제공하는 것으로 AWS Console 에서 인스턴스로 다양한 명령, 연결, 파라메터 저장등을 제공한다.

특히나 Windows 시스템을 운영할 경우에 AWS 는 SSM Agent 사용을 적극 권장하고 있다. 기존에는 Windows 시스템을 운영할 경우에 AWS 는 EC2Config 라는 프로그램을 사용해 AWS Service 와 상호작용하도록 했지만 이제는 Windows 시스템을 제어하고 EC2Config 를 제어하는 차원에서 SSM Agent 가 중요한 역할을 담당하도록 하고 있다.

Windows Server 2008 ~ 2012 R2

Amazon 에서 생성한 AMI 이미지들에 한해서 Windows Server 에는 EC2Config 가 모두 설치되어 있다. 그리고 2016년 이후에 생성한 AMI 이미지에는 SSM Agent도 함께 기본 설치되어 있다.

문제는 Windows Server 버전에 따라서 설치되어지는 EC2Config 버전에 차이가 난다. 이는 .NET 버전에 의존하기 때문인데, 이것 때문에 어떤 특징적인 기능들이 작동하지 않게 된다.

특히나 CloudWatch Custom Metric 수집에 있어서 버전에 따라서 방법과 설정이 달라진다. 시스템을 운영하는 입장에서 일괄성이 없이 버전마다 다양한 방법을 써야한다면 어려움이 많아진다.

하지만 SSM Agent 를 이용하면 CloudWatch Custom Metric 뿐만 아니라 CloudWatch Logs 를 손쉽게 수집할 수 있다.

CloudWatch 구성하기

SSM Agent 를 설치를 하면 awsCloudWatch 플러그인이 설치된다. 이는 다음과 같이 확인이 가능하다.

awsCloudWatch 디렉토리로 이동해 보면 여러파일이 보이는데, 여기서 AWS.EC2.Windows.CloudWatch.json 파일을 다음과 같이 작성한다.

여기서 중요한 것이 “IsEnabled”: true 를 추가해주는 것이며 Flows 에서 어떤 것을 수집할지를 정해준다.

위 설정 파일은 Memory, C 드라이브, D 드라이브 의 Custom Metric 을 “Windows/Default” 의 Namespace 로 수집하도록 설정하고 있다. 또, ApplicationEventLog, SystemEventLog 에 대해서도 CloudWatch Logs 로 전송하도록 하고 있다.

이렇게 한 후에 다음과 같이 SSM Agent 를 재시작 해준다.

이 문서의 내용은 다음의 메뉴얼을 참조 했다.

Ansible, ec2.py 를 이용한 Dynamic Inventory 활용

Ansible 에는 접속 정보와 관련된 정보들을 Inventory 라고 부른다. 접속 호스트, 접속 계정 정보뿐만 아니라 이들을 그룹으로 묶거나 변수 설정도 가능하다.

그런데, 클라우드 시스템과 같이 서버 관련 정보를 API 형식으로 제공할 경우에 일일이 호스트 정보를 파일로 저장할 필요가 없다. 클라우드 시스템에 서버 관련 정보를 호출하며 자동으로 Inventory 정보가 생성되는 기능을 제공하는데 이를 Dynamic Inventory 라고 한다. 이 기능은 클라우드 뿐만 아니라 LDAP 과 같은 인증 시스템에도 활용가능하다.

Ansible 세팅

AWS 클라우드의 Dynamic Inventory를 활용하기 위한 Ansible 을 세팅해 보자. 가장 중요한 ansible.cfg 는 다음과 같다.

특별히 inventory 에는 AWS 클라우드에 제공하는 Dynamic Inventory 스크립트 위치를 지정해준다. ansible 을 이용한 접속 정보, 실행할 계정에 대한 정보등을 기재한다.

디렉토리는 구조는 대략 다음과 같다.

AWS 클라우드 Dynamic Inventory 파일

AWS 클라우드의 경우에도 Ansible 의 Dinamic Inventory 기능을 제공한다. 작동원리는 AWS 자원 정보를 불러오고 이것을 Ansible 이 인식하는 Inventory 정보를 구성하는 것이다. AWS 자원 정보를 불러오기 위해서 AWS 는 다음과 같은 스크립트와 환경설정 정보를 제공한다.

ec2.py 는 AWS 클라우드 시스템에 호스트 관련 정보를 불러오도록 한다. ec2.ini 는 어디, 어떤 정보를 불러올 건지 어떤 내용을 출력할 것인지를 지정할 수가 있다. 예를들면 다음과 같다.

regions 이 기본값은 all 이다. 이러면 모든 리전에 대해서 호스트 정보를 수집할려고 하기 때문에 시간이 오래걸리는 문제가 발생한다. 특정한 리전에 대해서만 수행하도록 지정하는 것이 좋다.

IAM 설정

가장 중요한것이 IAM 설정이다. Ansible 을 실행하는 서버에는 호스트 정보를 불러올수 있는 IAM 권한이 필요하다. 보통 IAM Role 지정이라고 하는데 대략 다음과 같은 Policy 를 만들어 Role 적용을 하면 된다.

Access Key, Secret key 를 이용하는 방법도 있지만 권장하지 않는다.

ec2.py 테스트 및 특징

이제 요건이 갖춰졌으니 테스트를 해보자.

내용을 보면 위와같은 key 값들을 보게 된다. 집작했겠지만 ec2.py 는 ec2 인스턴스의 tag 를 key 로 지정해준다. tag 뿐만 아니라 ec2 인스턴스의 정보를 key 만들어준다.

이 key들은 Ansible Inventory 의 group 변수로 활용이 가능하다.

ec2 key pair 를 이용한 접속 정보 만들기

ec2.py 에서 key 들은 곧바로 Ansible 의 group 으로 활용 가능하다. 이를 위해서 inventory/production/group_vars 디렉토리에 key 이름으로 yaml 파일을 생성한다. 그리고 다음과 같이 내용을 입력한다.

Ansible이 그룹 접속을 할때에 위 변수를 활용하게 된다. AWS 클라우드 ec2 접속하기 위한 keypair 를 이용하는데 따른 설정이다.

접속 테스트

이제 다 됐다. 다음과 같이 접속 테스트를 한번 해본다.

위와같이 나오면 성공한 것이다.

AMAZON S3 버킷 램덤화 객체 접두사 불 필요.

과거에 AMAZON S3 버킷 성능 끌어올리기 라는 글을 통해서 S3를 사용하는데 있어서 성능향상 방법에 대해서 설명한 적이 있다. 핵심은 객체 접두사를 램덤화해서 S3에 올라가는 파일들이 균일하게 넓게 퍼질 수 있도록 해야한다는 것이였다.

하지만 2018년 7월 17일에 AWS 에서는 S3에 성능향상을 언급하면서 이제 객체 접두사의 랜덤화는 불필요하다고 말했다.

Amazon S3, 요청 처리 성능 개선 발표

이 같은 S3 요청 처리 성능 향상으로 인해 객체 접두사를 랜덤화하여 더 빠른 성능을 실현하라는 이전의 지침은 더 이상 적용되지 않습니다. 즉, 이제 성능 저하 없이 S3 객체에 논리적 또는 순차적 명명 패턴을 사용할 수 있습니다. 이 성능 향상은 이제 모든 AWS 리전에서 제공됩니다. 자세한 내용은 Amazon S3 개발자 가이드를 참조하십시오.

이제 S3 버킷에서 객체를 저장할때 접두사를 램덤화하려는 고민을 하지 않아도 된다.

외부MySQL 에서 AWS Aurora로 마이그레이션

데이베이스 이전은 매우 중요한 작업이다. 다른 IT 인프라와는 다른 속성을 가진 데이터베이스를 물리적 공간도 다른 곳에 옮기기는 쉬운 일이 아니다. 더군다나 데이터베이스는 모든 IT 비지니스에 핵심으로 사업 성공에 성패를 가르기도 한다.

AWS 를 사용하다보면 데이터베이스 이전 작업을 종종 겪게 된다. 처음부터 AWS 에서 제공하는 DaaS 인 RDS, Aurora 를 사용한다면 별 걱정이 없겠지만 AWS도 아닌 일반 IDC 의 데이터베이스를 AWS RDS, Aurora 로 옯기기는 매우 힘든 작업이다.

외부 MySQL 에서 RDS로 마이그레이션 하기
외부 MySQL 에서 RDS로 마이그레이션 하기

한마디로 말하면 답이 없는 작업이다. AWS 의 모범사례를 보면 이렇게 외부에MySQL 데이터베이스가 존재할 경우에 mysqldump 명령어를 이용해서 데이터를 Export 한 다음에 AWS RDS, Aurora 에 데이터를 Import 하고 외부MySQL(Master) – AWS RDS,Aurora(Slave) 로 묶어 둔 후에 Application 에서의 작업을 통해서 최종적으로 AWS RDS Aurora 만 사용하도록 하고 있다.

외부MySQL 과 RDS 의 리플리케이션 연결
외부MySQL 과 RDS 의 리플리케이션 연결

문제는 용량이다. 만일 외부MySQL 데이터베이스의 용량이 10TB, 아니 4TB 라고 해보자. 그러면 4TB 를 덤프 뜨는 시간이 얼마나 걸릴지 예상하기도 쉽지 않다. MySQL 은 데이터를 덤프 뜨는 동안 테이블을 잠그기 때문에 그동안 서비스를 중단해야 한다.

서비스 중단없이 어떻게 데이터 이전을 할것인하는 건 모든 사업자라면 하는 고민일 것이다.

Netflix 도 이에 대한 고민을 했던 것으로 보인다. 더군다나 외부데이터베이스 시스템이 Oracle 이고 이전하고자하는 데이터베이스가 MySQL 이라면 데이터 변환작업도 함께 진행되어야 한다. 거기다 무중단 서비스…

Netflix 의 이러한 고민은 다음의 기사로 나왔는데, 결론은 Oracle 의 Golden Gate 를 이용했다는 것이다. OGG 라고 불리우기도하는데, 개인적인 경험으로 매우 훌륭한 툴이다. OGG 와 같은 동일한 역할을 하는 소프트웨어가 여럿 존재할 것이다.

핵심은 외부 데이터베이스를 AWS 로 이전하려고 할 경우에 서비스 무중단을 원한다면 OGG 와 같은 프로그램을 이용하는게 답이라는 거다.

만일 무중단 데이터 이전을 자체적으로 하기 힘들다면 국내에 데이터베이스 기술지원을 하는 업체를 돈을 들여서라도 이용하는 편이 낫다. 괜히 능력도 안되는데 의지만 앞선 나머지 일을 진행하다가 데이터 손실이라도 발생하면 사업에 아주 심각한 영향을 줄것이기에 데이터베이스 만큼은 확실한 방법이 요구된다.

AWS Aurora Endpoint and WAS Connection Pool

Abstract

AWS Aurora 는 DB Cluster 로 구현된다. DB Cluster 는 Aurora 인스턴스와 Endpoint 를 포함한 일종의 그룹 개념이다. 이 DB Cluster 에는 1개의 Primary 인스턴스와 15개의 Replica 를 가질 수 있다.

각각의 구성에서 접속이 가능한 지점은 다음과 같이 3가지가 있다.

  • Cluster Endpoint
  • Read Replica Endpoint
  • Instance Endpoint

이러한 Endpoint 와 Aurora 인스턴스 그리고 Primary, Replica 를 조합한 아키텍쳐는 다음과 같다.

AWS Aurora Architecture
AWS Aurora Architecture

Cluster Endpoint

Cluster Endpoint 는 Aurora Cluster 에서 현재 Primary 인스턴스에 접속하기 위한 Endpoint 이다. 모든 Aurora Cluster 는 반드시 하나의 Primary 인스턴스와 이를 연결하는 Cluster Endpoint 를 가진다.

Primary 인스턴스는 Insert, Update, Delete 그리고 DDL(Data Definition Language) 에 관한 모든 쓰기 연산을(write operation) 지원하며 데이터 읽기 연산인 Select 도 지원한다. Cluster Endpoint 는 read/write 를 연산을 제공하는 Primary 인스턴스 접속을 제공한다.

Cluster Endpoint 는 read/write 접속에 대한 자동 FailOver 를 제공한다. Primary 인스턴스에 문제가 발생하면 Replica 인스턴스 중 하나를 Primary 인스턴스로 선택한다. Cluster Endpoint 는 DNS 를 이용해 기존의 Primary 인스턴스의 도메인을 버리고 Replica 인스턴스로 변경한다. 이렇게 함으로써 Cluster Endpoint 도메인 주소는 변경없이 계속 유지 된다. Cluster Endpoint 에서 새로운 Primary 인스턴스로 지정된 Replica 인스턴스는 read/write 역할을 위해서 Primary 인스턴스로 승격된다.

Reader Endpoint

Reader Endpoint 는 Aurora Replica 중에 하나와 연결된다. Aurora Replica 는 읽기 연산(read operation) 만 지원하기 때문에 Reader Endpoint 는 읽기 전용 연결지점이 된다.

만일 Aurora Replica 가 한개 이상이라면 Reader Endpoint 는 Load Balancing 을 지원한다. 각각의 연결은 Round robin 방법으로 Replica 인스턴스 하나와 연결이 되어 연결에 따른 부하가 분산된다.

Instance Endpoint

Aurora DB 를 생성은 결국 Instance 를 생성하게 된다. 모든 Aurora 에 인스턴스는 Endpoint 를 가지는데 이게 Instance Endpoint 이다. 모든 Instance 는 타입과 관련없이 유일한 Instance Endpoint 를 가진다.

이 Instance Endpoint 는 도메인 이름으로 불변이며 Cluster Endpoint, Reader Endpoint 에 CNAME 으로 등록되어 이들의 연결지점으로 사용되어 진다.

WAS Connection Pool

이제 WAS 에서 AWS Aurora 접속을 위한 설정에 대해서 이야기 해보자. WAS 서버가 무엇이든 AWS Aurora 접속을 위해서는 MySQL, MariaDB Connector/j 드라이버를 사용해야 한다.

그런데, Aurora Cluster 를 구성할 경우에 Primary 인스턴스와 Replica 인스턴스로 구성하고 Endpoint 를 각각 Cluster, Reader 로 구성하게 될 것이다. 이렇게되면 WAS 에서는 이를 분산해서 접속해야 할 필요가 생긴다.

MySQL, MariaDB 는 이렇게 read/write 접속과 read only 접속을 분리해서 연결하도록 하는 기능을 제공하는데 이를 Smart Driver 라고 부른다.

한가지 먼저 짚고 넘어가자면, AWS Aurora 를 사용할 경우에는 MariaDB Connector/j 드라이버를 사용할 것을 권장하고 있는데, MariaDB Connector/j 드라이버는 Aurora 를 공식적으로 지원한다.

MariaDB Connector/j 드라이버를 이용해 Cluster Endpoint, Reader Endpoint 를 설정하는 방법은 다음과 같다. (Tomcat 기준 JNDI 설정이다)

이렇게 Cluster Endpoint, Reader Endpoint 주소를 연속해서 주면 된다. 이렇게하면 서버단에서 접속 설정은 끝이난다.

하지만, 이렇게 서버단에서의 설정만으로 접속이 분리되는 것은 아니다. Spring MVC 기준으로 말을 하자면 Transactional 의 ReadOnly 프로퍼티를 준 경우에만 Reader Endpoint 로 접속이 이루어지고 이외에는 전부 Cluster Endpoint 로 접속이 이루어진다.

Spring MVC 에서 이것을 각각 지정하기보다는 TX, AOP 설정을 통해서 한꺼번에 설정이 가능하다.

위와같이 했을 경우에 get* 으로 시작하는 메소드 이름을 가진 Service 빈에서 Read-Only 속성을 부여해 Reader Endpoint 로만 접속하도록 하게 할 수 있다.

마지막으로 고려해야할 것이 한가지 더 있는데, Connection Pool 의 경우에는 접속/해제에 대한 오버헤드를 줄이기 위해서 미리 연결을 해놓는 경우인데, 만일 Aurora FailOver 기능을 사용할 경우에 기존의 Fail된 인스턴스와 연결을 계속 유지하는 경우가 생긴다.

Cluster Endpoint FailOver
Cluster Endpoint FailOver

Replica Role 이 승격되서 새로운 Primary Role 이 되면서 Read/Write 역할을 수행하게 되는데, 이때 Cluster Endpoint 의 DNS 의 CNAME 이 변경된다. 하지만 WAS 서버의 Connection Pool 은 장애가 발생한 기존 Primary Role 인스턴스를 가지고 있게 된다.

MariaDB Connector/J 드라이버에는 이를 위해서 SOCKET_TIMEOUT 값을 두고 있다. Aurora 의 경우에는 10000ms 로 10초 동안 접속이 이루어지지 않을 경우에 Socket Timetout 으로 간주해 FailOver 로직을 수행한다.

Socket Timeout 은 JDBC 드라이버 측에서 설정을 해줘야 한다. 이는 대부분 URL 에 파라메터로 지정하는데, 다음과 같이 할 수 있다.

MariaDB connector/J 에서 connectTimeout 기본값은 0이며 socketTimeout 의 경우 Aurora 일 경우 10000ms 로 되어 있다. 이정도면 MariaDB Connector/J 를 사용하는데 있어서 별도의 설정을 해주지 않아도 될 정도다.

AWS Aurora With MySQL

AWS Aurora(오로라) 는 AWS RDS 서비스 중에 하나 이다. 다른 RDS 서비스들은 기존 오픈소스, 상용 데이터베이스를 이용해 만든 반면에 Aurora 는 AWS가 자체 개발한 데이터베이스이다.

AWS RDS 는 Database-as-a-service (DBaaS) 인데, 이는 데이터베이스 관리에 많은 부분을 AWS가 알아서 해준다. 예를들면 데이터베이스 서버운영, 버그 패치, 이중화, 자동 FailOver등이며 웹 콘솔을 이용해 사용자의 각종 설정들을 처리해는 서비스다.

이 글은 AWS Aurora, 그중에서 MySQL Engine 에 대해서만 간단히 정리한 것이다. 이 글은 AWS Aurora 전부를 담고 있지 않음을 주의해야 한다.

Aurora MySQL Engine

Aurora 는 2가지 엔진(PostgreSQL, MySQL) 을 호환 엔진을 가진다. MySQL 호환 엔진의 경우에 MySQL 메이저 버전별로(MySQL 5.6, 5.7) 또 나뉜다.

Aurora MySQL 엔진을 이해하기 위해서 먼저 MySQL 를 간단히 살펴보자.

MySQL Architecture

기존의 MySQL 이중화 아키텍쳐는 다음과 같다.

MySQL With Replica On AWS
MySQL With Replica On AWS

AWS RDS MySQL 인데, 일반적인 MySQL 의 Replication 도 위와 동일 하다. 이 그림이 설명하는 특징은 다음과 같다.

  • MySQL 서버들은(Primary, Replica) 자신만의 Storage 를 가진다.
  • Storage 는 EBS Storage 이다.
  • Replica Instance 는 Primary Instance 로부터 Binary log 를 전송받아 이것을 Relay 해 데이터를 복제한다.

AWS RDS MySQL 서비스조차도 MySQL이 제공하는 복제방식을 그대로 사용했기 때문에 On-Demand 의 MySQL Replication 아키텍쳐와 동일하다.

이런 아키텍쳐 운영에서 문제는 추가적인 Replica 구성에 있다. 추가적인 Replica 를 더했을 경우에 기존 데이터를 전부 덤프를 뜨고 Restore 해준다음에 Position 값을 맞춰줘야 한다.

거기다 Replica가 바쁜 상태일때에 Binlog Relay가 느려지는 Replication Lag 현상도 문제다. Primary 에 추가된 레코드가 한참이 지나도록 Replica 에서 조회가 안될 수도 있다.

Aurora Architecture

AWS Aurora Architecture
AWS Aurora Architecture

AWS Aurora 아키텍쳐로 특징은 다음과 같다.

  • Storage 는 모든 인스턴스에 공유 된다. .
  • Storage 는 EBS 가 아닌 Distributed Virtual Volume Storage 다.
  • Redo Log 만 전송된다.
  • Pallarel Query 를 지원한다.

Aurora MySQL 특징

가장 큰 차이점을 살펴봤는데, 이외에도 몇가지 차이가 존재한다.

  • Multi-AZ 를 지원하지 않는다. – 오해의 소지가 있는데, 기존의 Multi-AZ 는 내부 StandBy 서버를 말했었다. 하지만 Aurora 는 Muti-AZ Deployment 를 할 경우에 내부 StandBy 서버 없이 Read Replica 가 AZ 로 생성되면서 이 역할을 대신한다. 용어의 혼돈이 존재하는 부분이다.
  • MySQL 의 Single thread connection 방식인데, Aurora MySQL 은 Dynamic 방식이다. 내부적으로 Epoll Multiplex 를 사용한다.
  • 사용할 Storage 용량을 정하지 않아도 된다. 10GB 씩 최대 64TB 까지 자동으로 늘어난다. (AWS RDS MySQL 의 경우 EBS 한계치인 16TB 까지다.)
  • Replica 에 대한 LoadBalancer 를 지원해 이중화를 지원한다. 이를 위해서는 읽기전용 Cluster Endpoint를 사용해야 한다.
  • FailOver 시에 Read Replica 중에 하나를 Primary Role 로 승격 시킨다. Primary Cluster Endpoint 를 사용하면 접속지점 변경이 없다.

중요한 특징들도 존재한다.

  • Aurora DB Cluster 역추적(Backtrack, 되감기)

보통의 DB 에서 특정 시점으로 되돌리기 위해서는 백업본을 이용해 Point-In-Time 복원을 수행해야 한다. AWS RDS 의 경우 특정 시점의 백업을 이용해 복원해 새로운 DB 클러스터를 만들어 내는데 이것이 Aurora DB 클러스터 백업 및 복원에 대한 개요 다.

Aurora DB Cluster 역추적은 백업/복원 과정이 아닌 데이터베이스를 특정시점으로 되감는 것이다. 새로운 DB 클러스터는 생성되지 않는다.

역추적 기능이 활성화된 상태에서 생성한 DB 클러스터에서만 역추적이 가능하다. (새 DB 클러스터를 만들 때, DB 클러스터의 스냅샷을 복원할 때, DB 클러스터를 복제할 때) 역추적 기능이 비활성화된 상태에서 생성한 DB 클러스터에서 역추적이 불가능 하다.

역추적이 활성화된 Aurora DB 클러스터를 업데이트하면 변경 레코드가 생성된다. Aurora은 대상 기간에 대한 변경 레코드를 보존하며 이 레코드를 저장하기 위해 시간당 요금을 지불한다.

  • Aurora Storage IOPs 는 오직 Aurora 의 인스턴스 타입에 따른다.

AWS RDS MySQL 의 경우에 EBS Storage 를 사용하기 때문에 IOPs 를 따로 결정할 수 있다. 하지만 AWS Aurora 의 경우에는 Storage 타입이 존재하지 않음으로 인해서 IOPs 는 인스턴스 타입에 따른다.

결과적으로 빠른 IOPs 가 필요하다면 Aurora 인스턴스 타입을 업그레이드 해줘야 한다.

  • Global Database 지원 – Region Replica 를 지원 한다.

Region 간 복제를 지원하는것인데, 현재 3개 지역만 지원한다.

  • Multi Master Replica

현재 Preview 단계에 있다. 언제 정식 서비스 될지는 모르지만 Preview로 맛을 볼수는 있다.

  • Free Tier 를 제공하지 않는다.

AWS Aurora 는 Free Tier 를 제공하지 않는다. 공자 사용 안된다는 이야기.

  • T2 타입에서 Performance Schema 활성화 안됨

적용 Capacity 를 가진 타입의 경우에 Performance Schema 활성화가 안된다.

AWS Aurora 비용

선택한 옵션에 따라서 추가 비용 부담이 있지만 기본적으로 가장 많은 비용이 들어가는 것으로는 다음과 같다.

  1. Storage I/O 요금 – 1백만 건당 0.22 USD
  2. 스토리지 요금 – 월별 GB 0.11 USD
  3. Global Database – 복제된 쓰기 I/O 백만 건당 0.22 USD

Storage I/O 요금을 주의해야 하는 것은 데이터 이관시다. AWS Aurora 로 데이터베이스를 바꿀려고 할 경우에 데이터를 부어야 하는데, 이때 대량의 Storage I/O 가 발생하게 되며 고 비용을 물어야 한다. – 처음부터 AWS Aurora 를 선택하는게 좋을 수 밖에..

Amazon RDS의 Read Replica 에 Multi-AZ Deployment 지원.

2018년 1월 11일날자로 “Amazon RDS 읽기 전용 복제본은 이제 다중 AZ 배포를 지원합니다.” 를 발표했다.

한글화를 하니까 그런지 잘 와닫지 않는데, URL 주소를 보면 확실히 이해가 될 것이다. 그런데, 저 글에서 한가지 불만이 있다. 다이어그램이 없다는 거!!

하지만 놀랍게도 AWS 의 트위터에서 이것을 소개하는데 다이어그램이 있었다. 그래서 다이어그램을 첨부한다.

amazon rds read replicas now support multi az deployment
amazon rds read replicas now support multi az deployment

링크에 내용 중에 다음을 주목할 필요가 있다.

이제 프로덕션 데이터베이스에 대한 재해 복구(DR) 전략의 일부로서 다중 AZ과 함께 읽기 전용 복제본을 사용할 수 있습니다. 잘 설계 및 테스트된 DR 계획은 재해 후에도 비즈니스 지속성을 유지하는 데 필수적입니다. 소스 데이터베이스와 다른 리전에 배치된 읽기 전용 복제본은 스탠바이 데이터베이스로 사용되다가 지역 장애가 발생했을 경우 새 프로덕션 데이터베이스로 승격될 수 있습니다.

DR 구축할때 Amazon RDS 에 Read Replica Multi-AZ 기능을 이용하면 무중단 운영이 가능하다는 이야기가 되겠다.

Amazon S3 버킷 성능 끌어올리기

이글은 “How do I improve the performance of my S3 bucket?” 의 내용을 번역한 것입니다. 오역이 있을 수 있습니다.

이슈

Amazon S3 에 작업부하(workload)가 굉장히 높을때, S3 성능은 작업부하에 맞춰서 확장되지 않는다. 이런 상황이 발생하면 때때로 HTTP 500, 503 에러를 받게된다. 다음과 같은 작업부하에서 어떻게 Amazon S3 버킷의 성능을 최적화 할 수 있을까?

  1. 100 request/sec 넘는 혼합된 요청 타입(GET, PUT, DELETE 혹은 GET bucket)
  2. 300 request/sec 넘는 GET 요청.

개관

Amazon S3 는 각 AWS 리전에서 Object Key 이름의 인덱스(index) 를 관리한다. Object Key 들은 인덱스에서 여러 파티션에 걸쳐서  UTF-8 바이너리 순서대로 저장된다. Key 이름은 Key 가 저장되는 파티션을 결정한다. 순차적인 접두사(sequential prefix)를 사용하는것은, timestamp 나 알파벳 순서와 같이, Amazon S3 가 아주 많은 Key들에 대해 특정 파티션을 지정하게될 것이고 이는 잠재적으로 막대한 파티션의 I/O 용량을 쓸 가능성이 높아진다.

해결책

작업부하가 혼합된 요청 타입일때, Key 이름에 접두사처럼 해쉬 스트링을 추가함으로써 키 이름에 랜덤화를 도입하라. Key 이름에 랜덤화 도입으로 인해서, I/O 부하는 여러 인덱스 파티션에 걸쳐 분산되어질 것이다. 예를들어, 문자 순서의 MD5 해쉬를 계산할 수 있으며, Key 이름에 해쉬로부터 3 혹은 4개 문자를 Key 에 접두사처럼 더하는 계획을 세울 수 있다. 다음의 예제는 16진 해쉬의 4문자를 접두사 더한 Key 이름들을 보여준다.

4문자 해쉬 접두사가 없으면, S3는 각 Object 이름이 examplebucket/2013-26-05-15-00-0  시작되는 1이나 2 인덱스 파티션에 모든 부하가 분산될 것이고 인덱스에 모든 Object 는 알파벳-숫자 순서로 저장되어진다. 4문자 해쉬 접두사는 로드를 여러 인덱스 파티션에 걸쳐 분산시켜준다.

작업부하가 대부분 GET 요청을 보내는 거라면, Key 이름에 랜덤화를 추가할 수 있다. 게다가, 여러분은 높은 데이터 전송율과 낮은 레이턴시를 필요로하는 사용자에게 컨텐츠를 분산하기 위해 CloudFront 와 Amazon S3 를 통합해 운영할 수 있다.

Object Key 이름에 랜덤화 도입과 Amazon CloudFront 와 Amazon S3 의 통합 운영에 대한 더 많은 정보는 Request Rate and Performace Considerations 를 봐라.

AWS Certified Solutions Architect – Associate Exam 시험 후기

AWS 자격증 시험 으로 다양한 종류가 있는데,  AWS Certified Solutions Architect – Associate Exam 도 그중에 하나다. 아마도 시스템 인프라를 다루는 사람들이라면 제일 먼저 도전하게 되는 AWS 자격증 시험 인데, 이 글은 이 시험에 대한 후기이며 앞으로 이 시험을 준비하는 사람들을 위해서 도움이 되길 희망한다.

시험준비 – 교재

AWS 를 현장에서 사용하고 있다고 하더라도 AWS 자격증 시험 을 치르는 것은 또다른 문제다. AWS 서비스 자체가 매우 방대하고 시험에서 중점적으로 어느부분을 테스팅 하는지 모르기 때문에 현장의 경험에만 의존해 시험을 치루기에는 무리가 있다.

특히, 나 처럼 AWS 서비스를 이용하면서도 특정 서비스에 치중된 것만 이용할 경우에는 별도의 시험 준비가 필요하다.

자격증 시험이라고 하면 먼저 교재를 떠올린다. 더군다나 국제 자격증이라면 시험을 준비하기 위한 무언가가 절실해 지는데 그때마다 적절한 교재를 우선 찾게 된다.

AWS Certified Solutions Architect – Associate Exam 의 경우에는 교재는 많지 않다. 하지만, 아예 없지는 않고 해외서적으로서 있다.

AWS Certified Solutions Architect - Associate Exam 교재
AWS Certified Solutions Architect – Associate Exam 교재

‘OFFICIAL STUDY GUIDE’ 문구가 눈에 뛴다.

아무튼, 나의 경우에는 이 교재를 온라인 주문으로 구매했다. 구매는 교보문고 인터넷을 통해서 주문하면 되는데, 내가 구매할때 시점에서 $43 였으며, 원래 가격은 $60 인데 할인받았다, 배송비를 포함해 한화로 63,000 원이 들었다. 배송은 15일 정도 걸린거 같다.

AWS 자격증 시험을 준비하는데 길잡이로서 교재는 매우 훌륭한 역활을 한다. 하지만 서적으로 구매하는 것보다는 E-Book 으로 구매하길 권장한다. 이유는 영문으로 작성된거는 둘째치고 폰트가 작았다. 물론 영어권 사람들에게는 그 폰트 크기가 표준이겠지만 한국 사람으로서 느끼기에는 폰트가 작아보였다. 그러다보니 읽기 불편하고 집중도 안되고 진도는 안가게 되고 시간을 많이 소비했다.

E-Book 이라면 컴퓨터에서 볼수 있고 확대/축소 기능을 이용해서 자신이 원하는 대로 볼수 있다. 또, 한가지 더 이점이 있는데 각종 아키텍쳐 그림들이 서적에서는 흑백으로 인쇄된반면에 E-Book 에서는 컬러로 되어 훨씬 이해력을 높여준다.

교재의 기능은 시험 준비를 위한 길잡이와 동시에 체계적인 정리로 인해서 머리속에 정리해주는 느낌도 준다. 마치 컴퓨터 파일을 적절한 디렉토리로 나누어 저장하도록 도와주는게 교재가 아닐까 싶다.

AWS Certified Solutions Architect – Associate Exam 교재 단점.

이 글을 쓰는 시점이 2018년 2월 3일이다. AWS 서비스는 분기별로 크게는 년도별로 서비스들을 확장해 왔다. 시간이 흐름에 따라, 그 시대에서 트랜드를 반영하는 기술들이 대거 만들어지고 고객에게 제공해왔다.

그래서 그런지 실제 시험과 이 교재와의 차이가 있다. 대표적인 것이 ECS 였다. 이 교재에는 ECS 에 대한 내용이 없다. 하지만 실제 시험에서는 ECS 에 대한 문제가 다수 나왔다. 기억나는 것중에 하나는 ECS 서비스을 이해해야만 풀수 있는 문제였고 다른 하나는 ECS 서비스에 보안 설정 문제였다. 하지만 교재에는 ECS 서비스에 대한 내용은 없다.

API Gateway + Lambda 도 역시 이 교재에는 없다. 하지만 시험에는 다수 출제되었다.

또 다른 단점은 여러 서비스를 조합해 탄력적(Elasticity) 인 아키텍쳐 설계와 관련해 많은 모범사례들을 다루지 않는다. 이 교재는 시험 범위에 포함된 각 서비스들에 대한 특징을 기술하고 이를 잘 이해하는지를 테스트하는 연습문제로 구성되어 있다. 물론 후반부에 이에 대해 별도의 챕터가 있지만 그것만으로 AWS Certified Solutions Architect – Associate Exam  에서 요구하는 관점을 전부 얻기는 문제가 있어 보인다.

마지막 단점으로는 책의 구성이다. 이는 시험을 보고 난후 느낀 개인적인 단점인데, 책의 구성은 AWS 의 서비스를 중점적으로 설명하고 부가적으로 보안과 확장성을 가볍게 언급하는 정도였다.

하지만 AWS Certified Solutions Architect – Associate Exam 시험을 본 봐로서 주어진 문제자체부터가 AWS 서비스를 조합하고 여기서 보안을 어떻게 할것이며 탄력적인 운영을 위해 설정해야 하는 옵션들에 대해서 물어본다.  탄력적이고 지속적인 서비스를 위한 관점이 시험문제 전반에 흐르고 있고 이를 구현함에 있어 필요한 보안설정을 어떻게 해야하는지가 더해진다.

이러다보니 나 같은 경우에 시험문제가 상당히 어려웠다. AWS Certified Solutions Architect – Associate Exam 교재에 연습문제 수준, 그러니까 특정 서비스에 국한된 옵션 설정이나 기능들을 묻는 문제의 비중은 거의 없다. 설사 그러한 옵션을 묻는 문제조차도 두가지 이상의 서비스를 조합해 서비스를 할 경우에 어떤 서비스의 옵션을 활성화를 해야지만 원하는 결과를 얻을 수 있는가? 식으로 나온다.

이래가지곤 교재만으로 시험을 통과하기에는 상당한 어려움이 있다. 그 만큼 이 교재도 현 시점과 갭이 상당하다는 것이다.

AWS Certified Solutions Architect – Associate Exam 교재, 지침서는 필요.

단점을 보면 지침서, 교재, 오프라인 강의등이 별도움이 안될것 같이 와 닿을 것이다. 하지만 그런 의미로 전달하고자 하는 말이 아니였다. 교재, 지침서에 나오는 수준에서 각 서비스별 특징과 속성만 잔득 외워서 시험에 응시하면 문제가 될 수 있다는 것을 말하고자 하였다.

실제 문제에서는 각 서비스별 특징과 속성에 대한 문제는 몇 문제가 출제되지 않는다. 그것이 시험에 당락을 결정할만큼 출제 수도 많지 않아서 교재, 지침서만 달달 외워서는 문제가 있다는 것이다.

하지만 교재, 지침서, 오프라인 강의등은 모두 중요하다. 문제를 이해하기 위해서는 각 서비스의 특징과 속성을 매우 잘 알고 있어야 하기 때문이다. 문제가 두 서비스를 같이 사용하는 경우에 뭔가 안되는데 이럴경우 어떤것을 해야하나? 하는 식의 문제도 다수 나온다. 이런 문제는 당연히 두 서비스의 특징과 옵션들을 알고 있어야 문제를 풀수 있다.

다만, 교재에서는 Scaliable, HA 등과 같은 Elastic 관련 아키텍처에 대한 챕터가 1번 나오고 그 내용도 매우 적다. 각 서비스에 대한 특징과 속성을 다 외우고 난 후에 어떻게 하면 탄력적인 아키텍쳐를 디자인하는 지에 대한 다양한 모범사례를 많이 소개했더라면 좋았을 것 같다.

물론, 이러한 다양한 모범사례는 인터넷에 많이 나와 있어서 굳이 교재, 지침서, 오프라인에서 논의가 되어야 하는지 의문이라고 반문할 수도 있겠지만 그래도 시험의 합격을 위함이 아니라 다양한 모범사례에서도 탄력적인 아키텍쳐에 잘 부합하는 사례정도는 될수 있는 한 많이 소개 해줬으면 하는 이쉬움이 남는다.

이 글을 읽게 되면 ‘시험 존나 어렵겠네.. ㅠㅠ’ 하면서 자신감을 잃으리고 쓴 글이 절대 아닙니다. ‘존나 어렵다’ 라는 건 개인마다 다 달라서 그것을 절대적인 기준으로 삼기에는 무리가 있습니다. 저의 경우에만 ‘존나’ 어려웠던 것이고 그것이 나에게 어떤 부분이 어려움을 느끼게 해줬는지에 대해서 혹시나 타인에게 이러한 어려움도 있다는 것을 공유함으로써 앞으로 응시하고자 하는 분들에게 참고가 됐으면 하는 바람이였습니다.

이 시험에 응시하고자 하시는분들의 건투를 빌어요. 도움이 되고자 하는 마음에 두서 없이 적은것이 공포를 불어 일으킨거 같아 마음이 아프네요.

이 글이 공포심을 불러 일으킨다면 더 이상 이 글로 인해서 좋지 못한 영향을 주는 바 그냥 ‘뭐 개같은 글이 있나??’ 식으로 치부하고 넘어가셨으면 합니다. 글이 너무 진지해 많은 분들에게 어려움만 남기게 된거 같아 마음이 아프네요.

이 글의 내용은 참고만 하고 마음에 담아 두시마시고 어짜피 시간이 흐름에 따라 유효하지 않을 겁니다. 몇일간만 더 열어두고 비공개로 바꿀께요. 죄송합니다. _(__)_

AWS Certified Solutions Architect – Associate Exam 시험 관점.

앞서 교재 단점에서 언급것과 같이 AWS Certified Solutions Architect – Associate Exam 시험의 관점은 명확하다.

  1. Elastic Architecture
  2. Security to AWS Service
  3. Hybrid Architecture
  4. Service’s Features and Funtions

가장 큰 핵심은 ‘Elastic’ 과 ‘Security’ 다. Elastic 혹은 Elasticity 는 AWS 가 추구하는 핵심이다. 이를 위한 Cloud 라고 보면된다. 가용성, 내구성, 확장성 이라는 단어도 이 Elastic 이라는 단어안에 포함된다.

두번째는 Security 이다. AWS 에서 최우선으로 고려하는 것이 바로 Security 라고 한다. 이를 위해서 IAM 서비스와 각종 감시를 위한 서비스들을, 예를들어 CloudTrail, AWS Config, VPC Flow… , 를 제공한다.

세번째는 하이브리드 아키텍쳐 였다. 이것도 의외였다. 상당히 많은 문제들이 이 하이브리드 아키텍쳐에 대한 것이였다. AWS Cloud 서비스와 On-premise (Data Center) 와 연동된 아키텍쳐에서의 다양한 문제들이 나왔다. 작게는 VPN 연결 설정 문제부터 시작해서 이러한 환경에서 Security 를 어떻게 확보할 것이지를 묻는 문제였는데 상당히 촘촘한 문제였고 답문 예제도 상당히 촘촘했다. 그러다보니 문제와 답문 예제를 상당히 꼼꼼하게 읽지 않고서는 풀수 없는 문제였다.

하이브리드 아키텍쳐에 대한 문제가 많이 나온데에는 아마도 현 시점에서의 AWS 서비스의 사용방향을 반영한 결과라고도 보인다. 모든 서비스를 AWS 를 사용한다면 이러한 아키텍쳐에 대한 고민이 없겠지만 현실적으로 각종 법규와 같은 제약으로 인해서 Data Center 와 연동해야하는 시점이다. 이러한 현실에서 AWS 서비스가 지향하는 탄력적이고 보안성이 높은 아키텍쳐 설계를 위해서는 반드시 알아야할 내용이기도 하다.

내가 시험에 응시한 현 시점에서 자주 출제된, 비중있게 나온 문제의 서비스는 다음과 같다.

  • Auto Scaling Group
  • VPN, VPC Peer
  • Multi AZ, Replicated
  • ECS, Lambda and API Gateway

모든 시험문제 전반에 이러한 과점은 끝임없이 깔려 있다. 특정 서비스에 대한 특징이나 옵션에 대한 질문에서 조차도 이러한 탄력적이고 보안적인 측면으로부터 시작된다. 이러다보니 앞에서 언급한 비중있게 나온 문제도 같은 서비스지만 문제 과점은 달랐다.

예를들어 다음과 같다.

  1. VPN 서비스를 이용해 외부와 연결을 해야하는데 AWS 서비스에서 해줘야할 것은?
  2. VPN 서비스를 이용해 외부와 연결된 상태인데 On-premise 에는 이미 Active Directory 를 이용해 Role 기반으로 Account 를 관리중이다. 무슨 서비스를 이용하는게 적절하며 어떻게 계정을 설정해야 하는가? (Choose TWO)

Auto Scaling Group 에 경우에는 다양한 모범사례(Best Practice) 에서 어떻게 설정해야하는 문제가 다수 나왔다. 모범사례는 다양한 아키텍쳐를 의미한다고 보면된다. 몇걔의 Subnet 에 몇개의 EC2 Instace 가 있으며 가용성을 100% 유지하기 위한 구성으로 적합한 것, 현재 Elastic Load Balancer 뒤에 여러 Subnet 중에 한쪽 Subnet 에만 EC2 Instance 가 구성되어 있는 경우에 가용성을 높일 수 있는 구성등을 묻는 문제등이다.

또, 강조하고 싶은게 문제를 아주 면밀히 주의깊게 읽어봐야 한다. 영어라면 더 더욱 두번 읽어서라도 그 뜻을 반드시 이해해야 한다. 여러 서비스를 조합해 설정을 요구하는 것인지 보안을 요구하는지에 대한 관점을 먼저 파악하고 난 후에 질문내용에 따라 답을 정해야 한다.  문제 자체가 상당히 꼬여있고 일종의 “낚시성” 지문도 많아 상당한 주의가 요구된다.

영어로 시험을 볼 경우에 각 서비스가 지향하는 무게 중심을 잘 알아야 한다. Durability, Consistency 등에 무게를 둔 서비스인지를 잘 알아야 한다. 언뜻 보기에 여러 서비스가 모두 사용 가능한것처럼 보이지만 문제에서 요구하는 타켓을 잘 집어 내야한다.

시험 후기

개인적으로 AWS 서비스를 현장에서 사용하고 있다. 만 3년정도 된거 같다. 하지만 현장에서 사용한다고 해서 모든 AWS 서비스를 이용한건 아니다. 나의 경우에는 고작 해봐야 EC2 Instance 와 Elastic Load Balancer, Amazon S3 정도다.

CloudTrail, AWS Config, CloudFront, VPC Flow 사용은 비교적 최근이였고 특히 IAM 사용은 최근이다. IAM 의 경우에 현장에서는 보안적인 측면으로 인해서 권한을 잘 주지 않는다. 하지만 확실한 것은 IAM Administrator 권한 없이 무언가를 해보기에는 상당한 제약이 있으며 이로인해서 IAM의 강력한 기능과 모범사례를 이해하기에는 한계가 있다.

또, AWS Certified Solutions Architect – Associate Exam 에 경우에 현재의 기술 트랜드에 대해 철저한 테스트를 한다. 대표적인 것이 ECS 였다. Docker 로 대표되는 기술이자 Micro Acrchitecture 설계를 요구하는 분야다. 최근에 가장 핫 이슈이기도 함과 동시에 이론상으로만 논의되는게 아니라 현실적으로 이미, 아니 몇년 전부터 현장에서 사용되어지는 기술이다. Lambda + API Gateway 도 빠질 수 없다.

이러한 트랜드 외에도 외부 Data Center 나 On-premise 와 포함한 Hybrid Architecture 설계와 보안에 대한 테스트도 당연한 것이다.

본 시험을 치르기 전에 봤던 모의고사 시험과, 총 20문제에 $20를 내면 AWS Training 에서 볼수 있다,  갭이 너무나 컸다. 이래도 되나 싶을 정도 였다. ECS 관련된것도 Lambda + API Gateway 관련된 것도 없었다.

상당히 어려웠다. 사실상 탈락과도 같았다 할 정도의 턱걸이 합격이 였다. 그래서 그런지 집으로 돌아오는 내내 찝찝함을 떨칠 수가 없었고 마음만 더 무거워 졌다. 애시당초 이 시험을 본 목적은 내가 AWS 서비스를 잘 이용하고 있고 이해하고 있는지가 궁금해서였다. 많은 사람들이 내가 AWS 서비스를 사용한다는 이유로 많은 문의를 했고 그에 대해서 내가경험을 기반으로 이야기를 해줬는데 그렇게 해서는 안되는 거다. 경험만큼 큰 이론이 어디있냐 하겠지만 AWS 서비스를 만든 전문가만 하겠으며 그런 사람들이 말하는 수많은 이론과 목적들을 내 경험만으로 그것을 습득했다고 보기는것은 자만심 그 자체 아니겠나….

그래서 AWS 서비스가 지향하는 바가 무엇이며 어떻게 하는것이 잘 사용하는지에 대해서 알고 싶었고 가장 효율적인 방법이 바로 자격증 시험이라 판단해 도전했지만 처참했다. 합격은 숫자에 불과해…

부록1 어떤 사람들에게 적합한가?

AWS Certified Solutions Architect – Associate Exam 은 시스템 인프라를 다루는 사람에게 유리하다. 작게는 SE (System Engineer) 에서부터 크게는 DevOps 분야에서 종사하는 사람에게 적합하다. 각종 서비스와 용어들이 이 분야에서 자주 사용되어지고 실전으로 몸에 익힐 수 있기 때문이다.

국내 자격증 처럼 이론상으로만 공부하고 응시할 수준은 아니다. 실제로 AWS 서비스를 상당히 잘 사용해본 사람에게 유리하다. 특히나 다양한 모범사례(Best Practice) 와 백서(WhitePaper) 등을 꼼꼼히 읽어봐야 한다.

따라서 AWS 서비스를 다양하게 직접 다루어봐야 한다. 그리고 탄력적이면서 보안성을 높이는 관점과 현재 기술 트랜드에 대해서 학습을 해야 한다.

부록2 시험 응시 등록은 어떻게 하나.

AWS Training 웹 사이트가 있다. 로그인을 위해서 먼저 AWS 계정이 필요하며 Training 을 위한 계정 연동을 위한 간단한 추가 정보를 요구한다.

로그인이 정상적으로 되면 시험 응시 등록은 AWS Training 웹 싸이트에서 모두 가능 하다.  시험에 응시 등록후에 모든 결과는 Training 계정에 메일로 모두 발송된다. 따라서 잘 알려진 메일서비스를 사용한게 좋다.

부록3. 영문으로 시험을 볼 경우에 30분 연장을 할 수 있다고 들었다. 어떻게 하나.

나도 이 부분에 대한 정보를 찾아봤지만 자세하게 나온건 없었다. 그래서 AWS 에 문의 메일을 보냈고 2~3일 후에 다음과 같이 안내 메일을 받았다.

시험 시간 30 추가 요청은 아래 절차를 따라주시기 바랍니다. 1) AWS Certification Account 접속 2) 상단 네비게이션에서 Upcoming Exam 클릭 3) 오른쪽 네가지 선택 Request Exam Accommodations 선택 3) Request Accommodation 클릭 4) Accommodation Type 드롭다운 박스에서 ESL +30Minutes 선택 5) Create 클릭 

위 메일 내용에서 1 -> 2 로 넘어가는 단계가 한 단계 더 있다. AWS Certification Account 에 접속하면 바로 Upcoming Exam 메뉴가 보이지 않는다. 다음과 같이 하면 된다.

  1. 먼저 AWS Training 웹 사이트에 로그인을 한다.  로그인을 하면 위쪽 왼쪽에 “자격증” 메뉴가 있는데 그걸 클릭.
  2. 다음과 같이 화면이 바뀐다. 여기서 “AWS 자격증 계정” 클릭.
  3. AWS Training Certification Account
    AWS Training Certification Account
  4. 화면이 바뀜과 동시에 URL 이 https://www.certmetrics.com/amazon/ 로 바뀌고 영문 페이지가 나온다. 이제 “Upcoming Exams” 메뉴가 상단에 보인다.
  5. 나머지는 앞에 메일 내용 3번부터 따라하면 된다.

이것을 요청해서 통과되면 모든 자격증 시험 시간이 일괄 30분 연장된다. 심지어 모의고사 시험 시간도 30분 연장 된다.

시험 문항은 55문항이며 기본 80분 + 30분 더해서 110분으로 영문 시험을 봤다. 시험이 끝나고 받은 메일로 보니 55문항을 53분만에 푼것으로 나왔다. 너무나 시간을 활용을 못했다고 봐야 한다. 영어시험이라고 하더라도 110분이면 아무 많은 시간이며 한문제 한문제를 좀 더 고심하면서 풀었다면 좀 더 좋은 성적을 거뒀을 지도 모른다. 시험에 응시할 분들은 모든 시간을 충분히 활용하길 바란다.

반드시 모의시험을 보길 권장한다. 단일 서비스의 특징이나 설정 문제는 이 모의시험에서 비슷하게 많이 출제가 되었다. 인터넷에 덤프가 있다고 들었는데, 안 봐서 모르겠지만, 내 느낌으로는 별 도움이 안될거 생각된다.

부록4 인상 깊었던 문제 한 두개 정도 기억나면 말해달라…

이게 문제가 안될지 모르겠지만 한가지 적어보자면… 이런문제가 있었다.

Q) Database 시스템에 operating system privileges 를 주려고 한다. 적절한 것은 ?

A) Database 시스템만 나오면 “오~ RDS” 라고 자동 반응하게 된다. 실제로 답문항에 RDS 어쩌구 하는게 있었다. 하지만 문제를 잘 봐야 한다. 문제의 포커스는 operating system 에 권한을 주려고 한다는 것이다.  그 OS 에 Database 시스템이 동작하고 있다는 것이다.

그러면 이것은 RDS 로 구성한게 아니라 EC2 Instance 에 Database 를 올린 것이 된다. 따라서 문제를 바꿔 말하면 EC2 Instance 에 Database 를 위한 권한이 필요하다는 이야기고 이는 결국 IAM Role 기반으로 권한 설정을 하는 것이 가장 적합하다고 하겠다. Database 에 권한을 부여하면 되지 않냐하겠지만 문제에서는 OS 레벨에서 권한이다.

부록5 기타 및 주의해야 할 것.

시험 응시 등록을 할때에 시험장을 고를 수 있다. 물론 모든 시험장이 같은 일자와 시간을 제공하진 않는다. 어떤 시험장은 주말에 응시할 수 없다. 나의 경우에 강남 시험장을 이용했다. 주말 오후 4시에 응시할 수 있는 곳은 그곳 뿐이였다.

반드시 15분 전에는 도착을 해야 한다. 나의 경우에 3시 45분부터 시험 응시 확인을 시작했다. 따라서 그 이전에 도착을 해야 좋다. 주말이라 그런건지는 몰라도 응시생은 나 포함해서 3명이여서 금방 끝나버려서 늦게 도착하면 어떻게 될지 모른다.

시험 응시 등록을 마치면 메일이나 Dashboard 에서 응시번호, 응시일자 장소등이 기입된 페이지가 나오고 인쇄할 수 있도록 해놨다. 인터넷 상에서는 이 페이지를 인쇄하고 가야한다고 해서 가지고 갔지만 그건 필요가 없었다.

한가지 ‘벙쪘던’ 것은 반드시 2개의 신분증 카드가 필요하다는 것이다. 한국 사회에서 신분증명은 주민등록증, 자동차 운전면허 둘중 하나만 있으면 된다. 그래서 시험장에서 응시생 확인을 할때에 자동차 운전면허만 보여줬더니 하나를 더 내놓으라는 것이다.

이게 뭔가 싶었다. 하지만 시험 응시 등록 완료 안내 페이지에는 반드시 자신의 신분을 증명할 2개의 수단을 제시해야한다고 되어 있다. 하지만 그것을 간과했던 나는 크게 당황했는데 등록확인해주시는 분이 ‘신용카드’ 도 된다고 해서 신용카드를 보여줬다.

한국 사회에서 신용카드가 무슨 신분증명이 될까 싶다만은 어쨌거나 반드시 2개여야 한다. 주민등록증과 운전면허증, 신용카드, 학생증, 여권 등에서 2개만 가지고 있으면 된다. 돌이켜 생각해보면 많이 당황한 순간이 였다.

시험장에 가면 등록확인을 한다. 내가 응시한 시험장 한쪽 벽면에는 사물함, 그건 마치 헬스장 사물함 처럼 보였다!!!, 있고 거기에 소지품을 넣어야 한다. 한가지 중요한 것은 호주머니에 아무것도 가지고 들어갈 수 없다. 모두 살물함에 보관해야 한다.

시험장 안에는 마치 도서관 처럼 컨닝을 못하도록 책상이 놓여있다. 그리고 책상에는 A4 몇장과 연필이 제공된다. 특이한 것은 귀마개도 제공됐다. (나는 사용하지 않았다!)  시험장에서 제공된 A4와 연필은 시험이 끝났다고 해서 들고 나올 수 없다. 들고 나올 경우 부정으로 간주 시험이 취소처리 된다.

마지막으로 시험감독관의 말을 주의깊게 들어야 한다. 그중에서 시험이 끝나고 난후 결과를 바로 확인하는 페이지가 나오는데, 그 화면이 나오면 창을 닫거나 오른쪽 위에 “Exit” 버튼을 누르지 말고 그대로 나오라고 했다. 시스템에 문제인지 Exit 버튼을 누르면 문제가 생길수 있다는 말을 하던데 암튼 이러한 주의사항을 잘 새겨들어서 합격에 들뜬 나머지 깔끔하게 정리하자 했다가는 큰 고충을 겪을 수도 있다. 그냥 다 놔두고 몸만 나오면 된다.

AWS 2016 서울 후기

새해 첫주, 심심하던 차에 Amazon Web Service 2016 Seoul 행사가 1월 7일 있었다. 몇일전부터 문자 메시지로 바코드와 함께 9시부터 시작한다는 안내가 와서 까먹지는 않고 있었다. 하지만 눈떠보니 8시고 차를 끌고 행사장에 도착했을때에는 9시가 훌쩍 넘어 30분을 향하고 있어 지각했다는 자괴감으로 헐레벌덕 뛰어들어갔다.

간단한 요깃거리..

9시부터 생각했던건 착각이였다. 9시부터 현장등록과 행사장 입장을 하고 본 행사는 10시부터 였다. 고맙게도 AWS.KR 에서 아침 댓바람(?)부터 왔을 사람들을 위해서 간단한 요깃거리를 준비해 뒀다. 간단한 한입빵과 커피… 이 정도면 아침식사로는 충분했다.

AWS 2016 서울 현장등록

이번 행사는 세개의 클래스(Class)로 나뉘어 준비되었다. AWS Intro, AWS Advanced, AWS Gaming 으로 각각 행사장소를 달리해 자신이 흥미있고 알고자하는 사람들을 타킷으로 알맞게 나눈것이다. 이 세개의 클래스는 오후에 진행됐고 오전에는 본행사로 Andy Jassy 글로벌 총괄 사장이 직접 연사로 나와 AWS 에대한 소개와함께 그동안의 노력과 성과등을 설명하는 시간등으로 준비되었다.

AWS CLOUD 2016 Seoul

AWS Staff 에 문자메시지로 온 바코드를 보여주고 네임태그를 건내받았고 본 행사장 입구에서 안내 팜플렛과 들고 다니게 편하라고 종이가방도 함께 받아 행사장에 입장했다. 행사장에 들어서니 언듯봐도 꽤 사람들이 많았다. 본 행사가 시작됐을때에는 자리가 모잘라 뒤에 서 있는 사람도 생날 정도였다.

AWS 2016 Seoul 팜플렛과 종이가방

10시가 되자 본 행사가 시작되었다. 글로벌 총괄 사장 Andy Jassy 가 연사로 등장했다. 그 동안 AWS  가 어떻게 되었으며 작년 한해 얼마큼 노력하고 새로운 기능들을 추가했는지, 서비스 진화에 발맞춰 AWS CLOUD 가 무엇을 만들어내고 고객들에게 제공했는지등을 설명했다.

Andy Jassy 글로벌 총괄 사장

Andy Jassy 는 전 세계 AWS 행사에 빠지지 않고 참석하는 사람으로 유명한데, 그가 대한민국을 찾은 것은 이번이 처음이라고 한다. 작년에도 한국에서 행사를 했었는데 그땐 안오고 하필 올해 왜 왔을까?

Asia Pacific Seoul Region

드디어 세계 12번째로 한국에 AWS CLOUD 를 위한 데이터센터인 Region 이 오픈했다. 그가 이말을 했을때에 뒤에서 환호성이 들리기도 했다. (많은 사람들이 그들이 누군지 알거 같닸다는 눈초리를 보내기도 했다. ㅋㅋㅋㅋ) 그의 말에 맞춰 실제로 AWS Console 에 Seoul Region 이 나타났으며 한국 시장 진출을 타진했던 Netflix 의 서비스도 오픈되었다고 한다.

Andy Jassy 사장의 Seoul Region 오픈 선포(?)를 끝으로 그의 프리젠테이션은 끝이났고 뒤이어 AWS 한국 직원들이 프리젠테이션이 이어졌다. 그 첫번째로 세계 12번째로 오픈한 Seoul Region 을 기술적인 측면에서 소개했다. 어떤 서비스를 사용가능하고 어떤 장점을 가져다 줄지가 주요 내용이였다.

AWS Seoul 에서 사용가능한 서비스

새롭게 오픈한 Seoul Region 의 대한 정보는 매우 귀중했다. AWS 에서 선보이는 모든 서비스를 지금 다 사용할 수 있지는 않기 때문이다. 연사의 주된 목적은 바로 이러한 정보를 전달하는데 있었고 그의 프리젠테이션은 이 목적에 매우 충실했다.

그가 소개한 내용중에 Direct Connector 서비스, 그중에서 “상면임대”가 눈길을 끌었다. Direct Connector 서비스는 실제 물리적인 인프라를 AWS 에 연결할 수 있도록 하는 서비스로 쉽게 말해서 데이터센터간 인터넷 회선 연결이라고 보면 된다. 그동안 대한민국은 이것이 불가능했다. 아니 엄밀해 말해 가능하긴 했지만 그 효용성이 없었다. 하지만 오늘 Seoul Region 이 생기면서 그 효용성이 살아났고 그의 프리젠테이션에는 ‘상면임대’ 라는 새로운 서비스 서포트가 생겨난 것이다.

Director Connector 상면임대

Direct Connector 를 위해서, 다시 말해 데이터센터간 연결을 회선 연결을 위해서는 물리적으로 직접적인 연결이 가능해야 한다. 하지만 AWS 는 KINX(킹스)라는 업체를 통해서 이 문제를 해결했다.

우리는 많은 인터넷 데이터 회선을 사용한다. 예를들면 KT 회선, LG Dacom 회선, SK 회선등이 그것이다. 인터넷 데이터 회선 사업자, 아니 좀 더 정확하게는 ISP (Interner Service Provider) 들이 제공하는 인터넷 회선 라인을 사용한다. 문제는 이 각각의 ISP 업체간에도 회선을 연결해줘야 한다는 것이다. 안그러면 KT회선 사용자는 SK 회선 사용자와 연결을 할 수가 없을 테니까. 그래서 각 회선 사업자간을 연결해주는 인터넷 데이터 회선 교환 사업자가 필요한데 KINX 가 바로 그런 사업자다. 한국에서 가장 큰 사업자다.(아마 경쟁업체가 없다지?) 인터넷 데이터 회선 교환을 비유하자면 고속도록의 나들목(인터체인지) 라고 할 수 있겠다.

KINX Internet Exchange ConceptAWS.KR 은 바로 인터넷 데이터 회선 교환 사업자 KINX 를 협력 파트너로 정해 Director Connector 를 지원하게 된다. KT IDC 에 서버는 이제 KINX 나들목을 거쳐 AWS CLOUD 와 직접적으로 연결이 가능해진 것이다.

더군다나 KINX 자체의 IDC 에 물리적인 서버를 둔다면, 그것은 바로 AWS CLOUD 와 연결에 물리적으로 가장 근접한 위치에 놓이게 되어서 보다 쉽게 물리 인프라와 AWS CLOUD 간 연결이 가능해는데 이게 바로 ‘상면임대’ 라는 개념인 것으로 보인다.

AWS 한국 직원의 첫번째 세션 “2016 AWS 신규 서비스 소개” 는 매우 필요했고 중요했으며 유용했다. 이 세션을 마지막으로 Global 세션은 끝났고 오후부터는 Intro, Advanced, Gaming 으로 클래스가 나뉘어 진행될 예정이였다.

점심은 AWS.KR 에서 준비한 도시락을 제공 받아 맛있게 점심세션(?)을 진행했다. 마침 자리를 테이블 좌석으로 이동한 터라 편하게 도시락을 제공받아 점심을 해결할 수 있었다.

AWS CLOUD 2016 점심 도시락

점심시간이나 휴식시간에도 행사장 밖 부스에서는 미니 세션도 함께 진행되 AWS 2016 CLOUD Seoul 행사에 참가한 업체들의 홍보와 더불어 정보습득할 수 있는 기회이기도 했으며, IT 바닥(?)이 좁은 한국이다보니 오랜만에 만난 친구, 선후배들간의 명함교환하는 모습도 눈길을 끌었다. 또, 각 부스별 마련된 이벤트를 통해서 선물을 챙기는 솔솔한 재미도 함께 제공됐다.

AWS 2016 Seoul 이벤트 선물

나는 Advanced 클래스를 신청했기에 자리이동 없이 앉아 있었고 점시시간이 끝나자 세션이 시작되었다. “AWS를 활용한 글로벌 아키텍쳐 운용 전략” 제목이였지만 실상은 AWS Seoul Region 오픈으로 Region 별 이전이 필요로 할텐데, 어떻게 서비스를 이전할지에 대한 정보제공이 주 목적이였다.

컴퓨팅 및 네트워크 이전 AWS CLI

이 세션에서 느낀 것은 Security Group, Network ACL, S3 이전등은 될수 있으면 AWS CLI 를 이용해서 하는 것이 편하다는 것과 Route 53 의 Weight 방법을 이용해 서비스 이전후에 서비스 지역 교체를 할 수 있다는 것이 핵심이였다.

Route 53을 이용한 서비스 교체

또, 놀라웠던 새로운 서비스도 눈에 띄었는데 기존의 RDS 외에 EC2 에서 자체적으로 구축한 데이터베이스를 위한 것으로 두개의 EC2 인스턴스 데이터베이스간의 Replication 을 자동으로 해주는 서비스가 눈길을 끌었다. 원리는 Source EC2 인스턴스의 데이터베이스 접속정보와 Target EC2 데이터베이스 접속정보를 AWS Console 를 통해서 입력해주면 복제를 해주는 것이 주요내용인데, 서비스 이름이 기억이……. (치매.. ㅠㅠ. 공개된 프리젠테이션 참고하셔요..)

세션들은 계속 진행됐다. 세션이 끝날때마다 잠깐의 휴식시간이 주어지긴 했다. 그 와중에 내 스마트폰 배터리가 바닥을 들어내는 바람에 몇몇 세션을 찍지 못했다. 흥미로웠던 세션별로 몇가지만 찍어야하는 상황이 되고 말았다. ㅠ

“클라우드 기반 실시간 데이터 분석 및 예측 방법” 세션에서는 그간의 AWS 가 제공했던 Big Data 서비스를 소개하고 이들을 어떻게 조합하고 운영하는지등에 대해서 프리젠테이션이 진행됐다.

AWS Big Data Roadmap

눈길을 끈것은 AWS 의 QuickSight 서비스 였다. 이 서비스는 Big Data 로 분석된 내용을 SQL 문으로 즉각즉각 그때그때 필요한 것만 뽑아낼 수 있도록 했다는 것이다. 이에 그치지 않고 현재 AWS 는 시각화까지 제공할 목적으로 서비스 개발을 진행하고 있다고 한다. 파이차트, 꺽은선 그래프등으로 Kibana 서비스와 동급의 내용이였다.

이렇게 보면 Big Data 를 AWS 서비스만 가지고 조합하면 하나의 플랫폼이 나올 정도로 전 영역을 전부 AWS 내에 집약시키겠다는 전략을 보여준 세션이였다고 평가할 만 했다.

다음으로 관심을 가졌던 것은 “고급 AWS 클라우드 보안 및 규정 활용 방법” 세션이였다. 스마트폰 배터리가 나가는 바람에 사진한장 없지만 클라우드의 보안을 어떻게 해야하는지에 대한 기초보다 좀 더 나간 방법들이 주된 내용이였다. 눈길을 끈것은 바로 현실적인 문제인 약간의 법적인 문제에 대한 나름의 설명이 좋았다.

마지막으로 흥미로웠던 것은 “고급 클라우드 아키텍쳐 방법론” 세션이였다. 연사가 현장에서 청중들에게 앙케이트 조사를 요청하고 그것을 기반으로 자신의 프리젠테이션 내용을 전달하는 Interactive 한 프리젠테이션과 자신감 넘치는 목소리로 청중들을 이끌었다.

AWS 2016 앙케이트 조사

“Well-Architected Method” 에 대한 정의에서부터 시작해 주요한 요소 네가지를 펼치고 그 내용을 소개했으며 중간중간 앙케이트 조사등으로 청중의 참여를 이끌었다. 이를 위해서 자신만의 프리젠테이션 노트북을 세팅하느라 시작전에 약간의 작업이 필요했는데, 청중들을 위해서 많은 준비를 했다는 느낌을 많이 받았다. 개인적으로 AWS 2016 Seoul 의 최고의 연사는 바로 이분이라고 생각한다.

개인적인 평가

이번 AWS 2016 Seoul 행사는 Seoul Region 오픈 선언이 가장 큰 이슈였다. 이후 진행된 Advanced 세션들은 이 Seoul Region 에 관련된 내용들로서 서비스 소개, 이전 방법등으로 사용자가 궁금해 할것을 미리 대비라도 한듯한 것이였을만큼 기획에 짜임새가 돋보였다. 그 이후에 진행된 세션들도 평소에 대충알고 있던 내용을 정리하고 좀 더 심화해보는 것으로 흥미로웠고 꽤나 알찬 내용이였다. 연사 프리젠테이션 중간에 관련 업체들의 실제 적용사례들을 소개하는 것 또한 주입식 정보전달을 벗어나 실제적이고 실층적인 내용을 청중에게 전달함으로써 현실감을 더했다. 홈페이지에 관련 자료가 올라오면 꼭 보라고 권하고 싶다.

협력업체 부스와 이벤트로 선물을 주는 전략도 나름 괜찮아 보였다.

이번 행사를 보고 느낀 것은 ‘이거 준비하느라 고생 꽤나 했겠구나’ 하는 생각이였고 그런 고생이 헛되지 않을만큼, 그 이상으로 아주 좋았다.

Amazon Web service

 

  • Camera: iPhone 4S
  • Taken: 7 1월, 2016
  • Flash fired: no
  • Focal length: 4.28mm
  • ISO: 200
  • Shutter speed: 1/20s