MySQL 5.7 소스 설치

이 문서는 MySQL 5.7 소스 설치 문서 입니다.

Boost 라이브러리

MySQL 5.7 로 넘어오면서 GIS관련해 기능과 InnoDB Engine 에서 R-tree indexes 가 포함되었다. geometry compute 위한 많은 native code 들로 작성이 되었는데 이를 위해서 Boost.Geometry 를 이용했다. 따라서 소스 설치시에 이 라이브러리를 필요로한다.

Boost 라이브러리를 컴파일 단계에서 다음의 옵션으로 알려줄 수 있다.

-DWITH_BOOST: Cmake 컴파일러에게 Boost 지점를 알려준다. Boost 지점은 다음의 셋중에 하나여야 한다.

  • tarball/zip 파일
  • tarball/zip 파일을 포함하는 디렉토리
  • tarball/zip 파일을 압축해제한 디렉토리

-DDOWNLOAD_BOOST: boolean 값으로 Boost tarball/zip 파일을 자동으로 다운로드 받게 할지 말지를 결정한다.

두 옵션을 조합해서 사용하기도 한다. 우선순위는 DWITH_BOOST 이며 여기서 찾지 못할 경우에 DDOWNLOAD_BOOST 를 체크해 다운로드를 할지 말지를 결정한다.

하지만 최근의 MySQL 5.7 소스에는 boost 를 포함해서 배포한다. 따라서 DWITH_BOOST 옵션을 사용해서 포함된 boost 디렉토리를 지정해주면 된다.

준비

CentOS 가 최소설치되었다고 가정하고 시작했기 때문에 컴파일 환경을 구축해줘야 한다.

Ubuntu

Download and Unpack

Configure and Compile

cmake 를 사용하기 때문에 일반적인 configure 와는 다르다. cmake 대로 옵션을 제공한다. 다음과 같다. 보시면 무엇을 의미하는지 알수 있을 것이다.

  1. -CMAKE_INSTALL_PREFIX:PATH=/opt/mysql5.7.21
  2. DWITH_engine_STORAGE_ENGINE nor -WITHOUT_engine_STORAGE_ENGINE 사용하고자 하는 스토리지 엔진을 지정하는 옵션입니다. engine 에는 모두 대문자로 쓰며, MySQL에서 지원하는 엔진들을 적어주면 됩니다.  ex) -WITH_INNOBASE_STORAGE_ENGINE:BOOL=ON -WITHOUT_PARTITION_STORAGE_ENGINE:BOOL=ON
  3. -ENABLED_LOCAL_INFILE:BOOL=boolean SQL파일을 로드하게 해주는 기능을 켭니다.  -ENABLED_LOCAL_INFILE:BOOL=ON
  4. -WITH_EXTRA_CHARSETS:STRING=all 추가로 지원할 언어를 지정합니다. 기본값은 all 입니다. -WITH_EXTRA_CHARSETS:STRING=all
  5. -WITH_SSL:STRING=(no, yes, bundled, system) SSL 지원여부 입니다. system으로 할경우에 시스템에 설치된 SSL library를 이용하게 됩니다. SSL 관련 library가 설치되어 있어야 겠죠. -WITH_SSL:STRING=system
  6. -WITH_ZLIB:STRING=(bundled, system) system으로 할 경우에 시스템에 설치된 Library를 이용합니다. -WITH_ZLIB:STRING=system
  7. -WITH_READLINE:BOOL=boolean readline 지원여부입니다. -WITH_READLINE:BOOL=ON

이러한 옵션들은 다음과 같이 확인이 가능하다.

이제 필요한 옵션들을 다음과 같이 해준다. 그리고 컴파일하고 설치해준다.

설치후 작업

설치가 끝난 후에는 수동으로 옮겨주어야할 파일들이 존재 한다. 그래서 설치 후 작업을 다음과 같이 진행 하면 된다.

계정을 추가

심볼릭 링크를 다음과 같이 생성해 줍니다.

디렉토리 설정과 관련된 my.cnf 내용은 다음과 같다.

다음과 같이 필요한 디렉토리를 생성하고 소유권을 바꿔 준다.

MySQL 라이브러리 시스템 인식.

시스템 데이터베이스 생성.

정상적으로 끝났다면, /opt/dbstorage/mysql/logs/mysqld_error.log 파일에 임시 루트 패스워드가 기록된다. 이를 참조해서 초기 접속시에 활용해야 한다.

Systemd 스크립트 등록

Systemd 를 사용하기 위해서는 컴파일 옵션을 -DWITH_SYSTEMD=1 를 반드시 해줘야 한다. 그리고 다음과 같이 mysqld.service 파일을 작성한다.

이것을 /usr/lib/systemd/system/mysqld.service 로 저장하고 systemd 에 등록해주고 시작해 준다.

이렇게하고 제대로 구동되었는지를 살펴보면 된다.

패스워드 초기화.

MySQL 5.7 은 설치할때에 root 에 대한 임시패스워드를 발급한다. 하지만 이것은 오직 root 접속을 위한 것으로 임시패스워드 대신 다른 패스워드로 변경하기 전에는 다음과 같이 명령어가 듣질 않는다.

다음과 같이 패스워드를 변경해 준다.

 

Bash 파일 존재 유무 체크하기

Bash 쉘 스크립트를 작성할때 자주 사용하는 로직인 바로 파일 존재 유무를 체크하는 것이다. 파일 하나만 체크할 수도 있고 여러파일을 체크할 수도 있다. 여러 파일을 체크할때는 다음과 같이 할 것이다.

이것을 Bash 쉘 스크립트에서는 어떻게 리턴을 받아야 하나하는 고민이 생긴다. 가장 쉬운 방법은 stdout, stderror 를 체크하는 방법이다.

Bash 에서 이를 exit code 라고 하고 $? 에 세팅이되어 다음과 같은 로직이 가능해진다.

명령어가 성공(stdout)하면 $?에 0, stderr 면 1 이다. 위를 실행하면 다음과 같다.

위 방법외에도 한줄로 다음과 같이 할 수도 있다.

AND 와 OR 연산자를 이용해서 메시지를 출력하도록 한다.

하지만 위 방법도 오류 메시지, 혹은 결과가 출력이 되는데 이를 방지하고 결과만 받고 싶다면 다음과 같이 할 수 있다.

이렇게 하면 결과 출력 없이 yes, no 만 출력이 된다.

출처: How to check if a file exists in a shell script

salt-ssh 패스워드 입력으로 동작하게 하기

salt-ssh 는 Client 와 통신 및 명령어를 전달하기 위해서 SSH를 이용하는데, 매번 패스워드를 입력하기 보다는 RSA 인증키를 교환함으로써 무인증 로그인을 가능하게 한다. 하지만 가끔은 보안문제로 인해서 무인증 RSA 인증을 사용하지 못하는 상황이 있을 수도 있다. 그래서 매번 실행할때마다 패스워드를 입력하도록 할 수 있다.

먼저 Client 에 관한 리스트는 roster 파일에 기술한다. salt-ssh 는 이 파일에 있는 목록으로 Client 를 호출하고 등록한다. 기본 roster 파일은 Salt root 디렉토리에서 etc/salt/roster 파일이다.

roster 파일의 예제는 위와 같다. 하지만 password 필드도 보안문제로 적어서는 안된다고 할 경우에 salt-ssh 를 사용할때에 패스워드를 입력하다록 하면되는데 다음과 같다.

etc/salt/roster 파일에 등록된 호스트와 계정에 대한 패스워드를 요구한다. 만일, 기본 roster 가 아닌 다른 계정정보를 가지는 roster 파일을 사용할 수도 있다.

 

MariaDB 10.2.13 소스 설치

MariadbMariaDB 는 MySQL 의 오픈소스 버전 입니다. MySQL 를 최초로 개발한 사람이 점점 폐쇄성이 짙어가는 MySQL 을 대체하기 위해 MySQL 을 복제하고 기능을 개선한 MySQL 의 또 다른 버전 입니다.

현재 MariaDB 는 10.2.13 버전 입니다. MariaDB 10 소스 설치를 해보겠습니다. 설치 환경은 다음과 같습니다.

  • CentOS 7
  • 64bit

준비

다음의 패키지가 설치되어 있어야 합니다.

 

다운로드 및 unpack

 

Configure and make and install

MariaDB 는 cmake 를 이용하기 때문에 일반 Configure 와는 다르게 이것을 이용 합니다.

 

설치후 작업

설치가 끝난 후에는 수동으로 옮겨주어야할 파일들이 존재 합니다. 그래서 설치 후 작업을 다음과 같이 진행 합니다.

계정을 추가 합니다.

디렉토리 설정과 관련된 my.cnf 내용은 다음과 같습니다.

다음과 같이 디렉토리를 생성하고 소유권을 바꿔 줍니다.

MariaDB 라이브러리 시스템 인식.

시스템 데이터베이스 생성.

Systemd 스크립트 등록.

user, group 을 mysql 에서 maria 로 바꿔 주고 등록해줍니다.

 

galera_recovery 파일에 mysql 를 maria 로 바꿔 줍니다.

 

다음과 같이 mariadb 를 시작해 줍니다.

 

Docker 기본 원리

Docker 는 Linux 의 Container 기술이다. 일단 Linux 에 해당하는 기술이라고 하는 이유와 함께 Container 를 위한 제반사항들에 대해서 알아본다.

과거에 Solaris 에 Zone 이라는 기술이 있었다. 가상화기술이 아니라 Container 기술이라고 소개가 되었던 기억이 있다. Solaris 9 에서 이전의 Solaris 8 을 Zone 이라는 기술을 이용해서 하나의 하드웨어에서 돌릴 수 있었다.

Linux 진영에서는 Jail 이라고 해서 chroot 로 파일시스템을 격리하는 기술을 이용해 마치 독립된 하나의 운영체제처럼 사용했었다. 지금도 검색을하면 Jail 환경에서 웹서버를 돌리는 기술 문서가 나온다.

그러다가 Linux 진영에서 아예 커널에서 이것을 지원하도록 만들기 시작했는데, 그것이 LXC 다. 내가 전에 직장에서 이것을 이용한 서비스를 만들던 친구녀석이 있었는데, 그때 나도 같이 봤던 기억이 있다. LXC 에서 cgroup 은 핵심이였다. 돌이켜 생각해보면 지금의 도커만큼이나 LXC 를 이용해서 구현을 할 수 있었던 것으로 기억한다. 하지만 노력과 비용이 너무 많이 들어갔다는게 문제였다.

Docker 는 정확하게 LXC 의 뼈대를 가졌다고 볼 수도 있다. 혹자는 최근의 Docker 는 LXC 를 버리고 libcontainer 를 독자적으로 사용하기 때문에 LXC 와 다르다고 하겠지만 LXC 가 사용하는 하부 구조를 Docker 도 그대로 사용한다 것을 부인할 수 없다.

  • Namespace
  • Cgroup

Docker 의 핵심은 위 두가지로 모두 Linux 커널에서 지원해야 한다. Docker 가 Linux 의 Container 기술이라고 하는 이유다. 실제로 Windows, Mac OS 에서도 설치할 수 있지만 설치할때 가상머신을 설치하고 난후에 Docker 를 설치하는걸 볼 수 있다.

Namespace

Namespace 는 마치 예전에 chroot 와 비슷하다. 다른 것이면 chroot 는 파일 시스템 격리를 우선했지만 Namespace 는 6가지를 지원한다.

  • File System
  • Process
  • Network
  • IPC
  • Hostname
  • User

Namespace 는 프로그래밍 세계에서도 사용하는 용어인데,  그곳에서 보여주는 특성과 동일하다. 6가지에 대해서 격리된 공간(isolated space)를 만들어준다. 운영체제는 분명 1개인데, 여러개의 격리된 독립적인 공간을 가질 수 있다.

물론 이를 위해서는 커널에서도 지원해야 한다.

Cgroup

Cgroup 은 Linux 시스템의 자원(Resource) 를 제어할 수 있게 해준다. 자원에 대해서 그룹을 생성한다. 그리고 그 그룹을 특정 사용자가 사용할 수 있도록 소유권을 준다. 그러면 사용자가 프로그램을 실행할때 cgroup 을 할당하면 거기에 있는 자원만큼만 사용하게 된다.

다음과 같은 자원을 제어할 수 있다.

  • Memory
  • CPU
  • I/O
  • Network
  • Device

당연히 이것도 커널에서 지원해야 한다.  커널이 지원하면 다음과 같이 /sys 에 cgroup이 나타난다.

 

애초에 Docker 도 LXC 를 이용해 구현되었다가 지금은 runC 라고 하는 걸 독자적으로 만들어서 사용하고 있다고 한다.

참고:

  1. Docker(container)의 작동 원리
  2. 초보를 위한 도커 안내서 – 도커란 무엇인가?

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 를 봐라.

CentOS 6 버릴때가 됐다.

이제 CentOS6 은 버릴때가 됐다. 오늘 PHP 7 버전을 설치하려고 보니 crypto library 가 sodium 을 필요로 하는데 이게 버전이 1.0 이상 버전이다.

문제는 이 버전을 설치하기위해서는 autoconf, automake 를 별도로 설치해줘야 하며 libzip 의존성에서도 1.0 버전 이상을 요구해 의존성 패키지가 계속 생긴다. CentOS6 에서의 컴파일러 관련 패키지들이 버전이 낮은게 문제가 계속 되고 있다.

CentOS6 의 End of life 는 2020년 11월 30일까지로 아주 오랜기간동안 지원을 해왔다. 어떤 소프트웨어를 아주 오랜기간 지원을 한다는 것은 매우 어려운 일인데, 이렇게 오랬동안 지원해준데에 감사할 따름이다.

현 시점에서 가장 좋은 배포판으로는 Ubuntu 16.04 이다. CentOS7 은 커널 버전이 3.10 이지만 , 물론 비공식으로 4.x 버전을 사용할 수 있다,  Ubuntu 16.04 는 4.x 버전이다. 커널 버전에 따른 성능 향상도 무시못함으로 될 수 있으면 Ubuntu 16.04 를 사용하는 것이 좋다.

MySQL 5.7 초기화 오류 메시지

MySQL 5.7 이 릴리즈 된지도 오래 지났다. 인기 있는 데이터베이스 시스템이라서 그런지 현장에서 많이 쓰이는 거 같다. 무엇보다도 Replication 기능의 향상이 많은 사용자를 끌어들이는 느낌이다.

이 글에서는 개인적으로 MySQL 5. 7 를 사용하면서 느낀 변화에 대해서 기술하고자 한다. 변화에 대한 기술은 MySQL 5.6 과 비교한 것이다.

데이터베이스 초기화

기존에는 mysql_install_db 를 사용했지만 이제는 mysqld 에 옵션으로 –initialize 를 주고 실행하면 시스템 데이터베이스와 테이블, innodb 저장소등을 만들어준다.

기존의 MySQL 5.6 에서 사용하는 my.cnf 파일을 가져다 초기화를 하면 위와 같이 warining 과 함께 ERROR 가 발생하면서 중단된다.

unkown variable ‘log_bin_basename’

분명히 메뉴얼에는 존재하는데도 인식이 안된다.  알수 없는 옵션이라고 하면서 데이터베이스 초기화가 안되는데 log_bin 옵션에다가 해주면 된다.

 

explicit_defaults_for_timestamp

TIMESTAMP 컬럼 데이터 타입에 대한 기본값에 대해 명시적으로 지정을 할지 말지를 결정하는 옵션. 기본은 OFF 이나 그럴 경우에 위와 같이 경고 메시지가 나온다.

TIMESTAMP 를 컬럼에서 사용할때 기본값을 명시하지 않으면 이전 버전에서는 “NOT NULL DEFAULT CURRENT_TIMSTAMP ON UPDATE CURRENT_TIMESTAMP” 가 된다. 하지만 5.7 에선 위 옵션을 이용해서 ON 으로 지정할 경우에 “NULL DEFAULT NULL” 값이 지정이 된다.

‘innodb-autoextend-increment’: unsigned value 10485760 adjusted to 1000

MySQL 5.7 에서 innodb-autoextend-increment 옵션 값은 1 ~ 1000 사이의 값이여야 한다. 단위는 MB 이여서 최고값 1000 은 1GB 가 된다. 이 경고 메시지는 10MB 라고 값을 입력함에 따라 값의 범위를 벗어나 생긴 것이다. 1 ~ 1000 사이의 값을 넣어주면 된다. 단, 단위는 생략.

이 옵션은 file-per-table 테이블스페이스 파일 이나 general 테이블 스페이스 파일에는 아무런 영향을 주지 않는다. 이러한 파일은 innodb-autoextend-increment 세팅과 상관없이 자동으로 확장된다. 초기의 확장은 소량으로 진행되지만 이후에는 4MB 씩 늘어난다.

Using innodb_support_xa is deprecated and the parameter may be removed in future releases. Only innodb_support_xa=ON is allowed

MySQL 5.7.10 버전 이후부터는 항상 활성화 된다. innodb_support_xa 를 비활성화 하면 replication 이 안전하지 않게 되고 바이너리 로그 그룹 커밋(Binary log group commit)과 관련된 성능 향상이 되지 않아 더이상 허용되지 않는다.

Using innodb_file_format is deprecated and the parameter may be removed in future releases.

5.7 이후에 기본값이 Barracuda 로 바뀌었으며 가까운 미래에 없어질 것이다. 원래 이 옵션은 5.1 버전으로 다운그레이드를 위해서 만들어졌으며 5.1 은 더 이상 지원을 하지 않게됨에 따라서 필요하지 않게 되었다.

옵션을 설정하지 않으면 된다.

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 버튼을 누르면 문제가 생길수 있다는 말을 하던데 암튼 이러한 주의사항을 잘 새겨들어서 합격에 들뜬 나머지 깔끔하게 정리하자 했다가는 큰 고충을 겪을 수도 있다. 그냥 다 놔두고 몸만 나오면 된다.