PostgreSQL Replication – Log Shipping

PostgreSQL 리플리케이션은 장애를 대비해 가용성을 높이는 최소한의 방법입니다. 현재 버전의 PostgreSQL 다양한 리플리케이션을 지원하는데, 이 문서는 가장 오래되고 기초적인 리플리케이션인 Log Shipping Replication 에 대해서 다룹니다.

File based replcation in PostgreSQL

이 리플리케이션은 Warm Standby 이라고 합니다. 이에 대한 설명은 PostgreSQL 문서에 다음과 같이 잘 나와 있습니다.

운영 서버에서 만드는 트랜잭션 로그 조각을 정기적으로 대기 서버로 옮기고, 그것을 적용시켜, 운영 서버가 장애로 멈추게 되면, 대기 서버를 운영해서, 가용성을 향상할 수 있다. 이 기능을 warm standby, 또는 log shipping 기능이라고 한다.

이 복제 방식은 먼저, 운영 서버와 대기 서버가 모두 실행 중이어야한다. 하지만, 두 서버 쌍방간의 연결 상태는 다른 복제 방식보다 나빠도 괜찮다. 운영 서버는 아카이브 모드로 운영 되어야하며, 운영 중에 생기는 다 쓴 WAL 세그먼트 파일(스위칭된 트랜잭션 로그 파일)을 차례대로 대기 서버로 보내고, 대기 서버는 복구 모드 전용(복구가 끝나도 다음 복구 파일이 있으면 계속 복구 작업을 하는 상태)으로 실행된다. 이 방식을 이용하면, 데이터베이스 테이블들을 수정해야할 필요가 없다. 또한 다른 복제 방식에 비해 관리 작업 비용도 적으며, 복제 작업이 운영 서버 쪽으로 끼치는 영향도 다른 복제 방식보다 적다.

이 방식의 구현 방법은 간단하다. 운영 서버에서 다 쓴 WAL 파일을 다른 서버로 운송(shipping) 하는 것 뿐이다. PostgreSQL에서는 그 로그 옮기는 작업은 한 번에 하나의 로그 파일을 옮길 수 있도록 구현되어 있다. WAL 파일(16MB)을 옮기는 작업은 데이터베이스 서버 밖에서 관리자가 정의한 방식으로 진행 되기 때문에, 같은 사이트 내로 옮겨도 되고, 전혀 다른 시스템 쪽으로 보내도 되고, 여러 시스템으로 한꺼번에 보내도 된다. 이 부분은 전적으로 관리자에게 맡긴다. 단지 고려해야할 사항은 파일이 전송될 때의 전송량 때문에 운영 서버에 영향을 줄 수도 있다. 이 부분이 염려되면, 전송 속도를 제한 할 수 있는 방법도 고려해야할 것이다. 아니면, 레코드 기반 로그 전달 방식 (스트리밍 복제)을 고려할 수 도 있다. (25.2.5절 참조)

로그 전달 방식은 비동기식임을 기억해야 한다. 다시 말하면, 전송하는 WAL 내용은 이미 커밋된 자료이기 때문에, 그 자료가 대기 서버로 미쳐 전달 되기전에 운영 서버가 멈춰버리면, 그 자료는 손실 된다. 자료 손실량을 줄이는 방법으로 archive_timeout 환경설정값을 몇 초 정도로 짧게 지정해 자주 사용하는 WAL 파일을 바꾸고, 그것을 전송하면, 되겠지만, 그 파일의 크기가 16MB이기 때문에, 잦은 WAL 파일 전송 작업으로 네트워크 사용량이 증가할 것이다. 스트리밍 복제 방식(25.2.5절 참조)을 이용하면, 이 손실 되는 자료량을 최소화 할 수 있다.

(물론 위에서 언급한 한계점이 있기는 하지만,) 대기 서버로 넘어 오는 WAL 파일이 제때에 잘 넘어 온다면, 운영 서버가 중지 되어 대기 서버가 그 역할을 맡기까지 서비스가 중지되는 시각은 극히 짧다. 이렇게 가용성을 향상 시킨다. 베이스 백업 자료를 준비하고, 지금까지 보관해둔 WAL 파일을 가지고, 서버를 복구 하는 방법은 이 방식보다 꽤 많은 서비스 중지 시간이 필요할 것이다. 서버가 복구 되는 기술적인 방식은 동일하지만, 가용성 입장에서는 차이가 난다. warm standby 방식으로 구현되면, 대기 서버 쪽에서는 어떤 쿼리도 사용할 수 없다. 대기 서버 쪽에서 읽기 전용 쿼리를 사용하려면, hot standby 방식으로 구축해야한다. 이 부분은 25.5절에서 자세히 설명한다.

 

시작하기에 앞서

WAL 파일

대부분의 데이터베이스 시스템은 데이터베이스에 변화와 관련된 모든 작업에 대해서 파일로 기록을 해 둡니다. 정확하게는 데이터를 조작하기에 앞서 어떤 SQL 를 명령했는지에 대해서 로깅을 한 후에 실제 데이터를 조작 합니다. 이는 갑자기 장애가 발생했을시에 이 로그 파일을 이용해 데이터를 복구할 수 있게 됩니다. 이를 WAL (Write Ahead Log) 파일이라고 합니다.

PostgreSQL 도 같은 방법으로 동작합니다. PostgreSQL 에서 WAL 파일은 pg_xlog 디렉토리에 생성되며 특징은 16MB 크기단위로 파일이 쪼개져 저장됩니다.

 

CheckPoint

모든 데이터베이스 시스템은 메모리 기반으로 동작합니다. 메모리에 자주 쓰이는 데이터를 캐쉬해기도 하고 트랜잭션시에도 메모리에 저장됩니다. 특정 시점이 되면 PostgreSQL 은 메모리에 있는 것을 디스크에 쓰기를 함으로써 실제 데이터가 영구적으로 저장이 됩니다.

그런데, 이러한 작업을 수동으로 해야할 때가 있습니다. 대표적으로 PITR(Point In Time Recovery) 백업을 하기 위해서는 모든 메모리에 내용을 강제로 디스크에 쓰여져야 합니다. 이때 PostgreSQL 가 하는 작업이 바로 CheckPoint 입니다.

다시말해, CheckPoint 는 메모리에 있는 내용을 디스크에 강제로 쓰기하는 작업을 말합니다.

 

리플리케이션 설정하기

설정하는 순서는 다음과 같습니다.

  1. Master 서버가 standby 서버에 postgres 계정으로 ssh 패스워드 인증없이 바로 접속할 수 있도록 설정을 합니다.
  2. Master 서버의 postgresql.conf 파일을 수정하고 서버를 재시작 합니다.
  3. Master 서버에서 PITR 백업을 합니다.
  4. 백업본을 standby 서버로 전송합니다.
  5. standby 서버에서 전송받은 백업 압축파일을 해제 합니다.
  6. standby recovery.conf 파일을 작성하고 pg_xlog 디렉토리를 생성하고 소유권을 postgres 로 바꿉니다.
  7. standby 서버를 기동 합니다.

SSH no password 접속 설정.

이는 RSA 키를 교환함으로써 가능 합니다. PostgreSQL 은 postgres 계정으로 동작하기 때문에 postgres 계정에서 Standby postgres 계정으로 RSA 키 접속을 설정해 줍니다.

먼저, Master  서버의 postgres 계정에서 다음과 같이 키를 작성해 줍니다.

이렇게하면 postgres 계정에 “.ssh/id_rsa, .ssh/id_rsa.pub” 두개의 파일이 생성이 됩니다. id_rsa 는 private key 이고 id_rsa.pub 는 public key 입니다. 다음과 같이  publickey 를 Standby 의 postgres 계정을 복사해 줍니다.

이제 그냥 “ssh ‘postgres@192.168.96.26′” 을 입력하면 패스워드 입력 없이 접속이 가능해 집니다.

Master 서버에 postgresql.conf 파일 설정

다음과 같이 postgresql.conf 파일을 설정해 줍니다.

archive_command 에 설정한대로 Standby 서버에 archive 디렉토리를 만들어주고 postgres 소유권으로 바꿔 줍니다.

서버를 재시작 해줍니다.

Standby 를 위한 데이터 백업하기 

리플리케이션의 시작은 슬레이브 데이터베이스시스템을 위해 데이터베이스를 옮겨주는 것입니다. PostgreSQL 뿐만아니라 MySQL 도 그렇지만, 데이터베이스의 파일들을 압축해서 옮겨줘야 하는데, 이를 위해서는

  1. Master 서버의 작업 중단
  2. 모든 메모리에 있는 내용을 디스크에 쓰기(CheckPoint)

뒤 두가지가 필요합니다. PostgreSQL 은 이 두가지를 명령어를 통해서 한번에 되도록 지원하는데 두가지 방법이 있습니다. 이 문서에서는 PITR 백업 방법을 설명합니다.

먼저, PostgreSQL  서버에 다음과 같이 해줍니다.

이제 백업 완료된 파일을 Slave 서버로 옮겨 줍니다.

백업본을 Standby  서버로 옮겨주기

다음으로 Slave 서버에서 전송되어진 압축파일을 다음과 같이 압축해제해 줍니다.

Standby 서버에서 전송받은 백업 압축파일을 해제

이제 recovery.conf 을 작성해 줍니다.

recovery.conf 파일 작성

다음과 같이 recovery.conf 파일을 작성하기 위해서 다음과 같이 data 디렉토리로 이동해 줍니다.

recovery.conf 는 다음과 같이 작성해 줍니다.

이렇게 파일을 작성하고 역시나 소유권을 postgres 로 변경해줍니다. 그리고 서버를 시작해줍니다.

체크하기

이 렇게 해놓으면 Master 서버에서는 archive 해야할 로그파일을 Standby 서버로 전송하고 Standby 서버는 이것을 replay 하게 됩니다. 그러니까 Standby 서버는 replay 로만 동작하게 됩니다. 이는 상태를 보면 알 수 있습니다. Standby 서버의 프로세스 상태는 다음과 같습니다.

38번째 파일을 기다리고 있다고 나옵니다. . ‘/opt/pgsql-9.5.0/archive’ 에는 Master 에서 전송한 파일을 받고 받자마자 바로 replay를 합니다. 그리고 3개가 넘어가면 pg_archivecleanup 프로그램이 recovery.conf 에 명시된대로 삭제됩니다. 이는 ‘/opt/pgsql-9.5.0/archive’ 디렉토리를 모니터링 해보면 알 수 있습니다. 없던 파일이 나타나고 사라지는것을 확인할 수 있습니다.

로그파일을 보면 현재 상태를 확인할 수 있습니다.

이 Replication 의 특징는 Standby 를 활용할 수 없습니다. Select 전용으로라도 활용할 수 없습니다. 왜냐하면 replay로 동작중이기 때문에 psql 를 이용해서 접속을 하면 다음과 같은 에러메시지를 만나게 됩니다.

만일 Master 서버에 여러 Standby 서버가 필요하다면 Master 서버에 postgresql.conf 파일에 ‘archive_command’ 에 스크립트를 넣어줍니다.

단점

이 Log Shipping Replication 은 자세한 Replication 상태를 모니터링 할 수가 없습니다. 파일 전송은 PostgreSQL 이 담당하는게 아닌 리눅스 시스템이 담당합니다. 거기다 Standby 서버에는 접속조차 할 수 없어서 Standby 서버에서 제대로 Recovering 이 되고 있는지를 알 수가 없습니다.

동작 방법이 16MB WAL 파일 작성이 완료되어지면 전송이 되어지는데, 그래서 WAL 파일이 자주 생성된다면 파일을 전송하는데 시스템 자원 소모가 커질 우려도 있습니다.

KVM Ubuntu 가상머신에 콘솔 접속하기

Ubuntu 를 KVM 가상머신으로 설치를 했다면 콘솔 접속을 해보면 안됩니다. 지난번에 CentOS6/7 배포판에서의 가상머신 콘솔접속에 대해서 다루어 었는데, Ubuntu 는 이들과 조금 다르기에 포스팅 해봅니다.

이 글은 ubuntu 14.04 를 대상으로 합니다.

처음 Ubuntu 를 KVM 가상머신으로 설치를 했다면 SSH 나 Virt-manager 나 vnc 를 이용해서 접속을 해야만 합니다. 그래야 콘솔접속을 위한 설정을 해볼 수 있습니다.

GRUB 설정

공통 Grub 설정은 /etc/default/grub 에 있습니다. 다음과 같이 설정을 해줍니다.

그리고 다음과 같이 업데이트를 해줍니다.

Serial 콘솔 만들기

다음과 같이 Serial 콘솔을 만들어 줍니다.

그리고 ttyS0.conf 파일을 다음과 같은 부분을 편집해 줍니다.

위와같이 수정해주고 리붓을 해줍니다.

테스트

Ubuntu 가상머신을 재부팅한 후에 호스트 서버에서 다음과 같이 콘솔 접속을 해봅니다. 그러면 다음과 같이 나오면 성공 입니다.

Enter 를 여러번 쳐주면 나옵니다.

 

Apache Tomcat 연동하기 – mod_jk

Tomcat 을 단독으로 운영하지는 않는다. 여러 서버에서 설치한 후에 이것을 부하분산하는 방법으로 운영하는데, 자주 쓰이는 방법이 Tomcat 앞단에 Apache 웹 서버를 두고 이 둘을 연결해주는 방법으로 사용을 한다.

이때 연결방법이 여러가지가 있는데, Tomcat 과 Apache 를 위한 전용의 모듈이 있는데 그것이 바로 mod_jk 이다. mod_jk 는 AJP 프로토콜을 사용해서 이 둘을 연결해주는데, 다른 연결들보다 성능이 우수하다.

환경

이번 테스트한 환경은 다음과 같다.

  • OS: CentOS7 x86_64
  • Java Version: jdk-1.8.0_u65
  • WAS: Tomcat 8.0.30

그리고 서버는 한대이고 Tomcat 을 여러개 설치했다. 이때에 하나의 Tomcat 을가지고 멀티인스턴스 생성방법을 사용했다. 각각의 WAS 서버의 정보는 다음과 같다.

  • instance1, 8109 AJP Port
  • instance2, 8209 AJP Port
  • instance3, 8309 AJP Port

Apache 웹 서버는 CentOS 7 에 Yum 을 이용해서 설치했다. 이때 설치할때에 “httpd-devel.x86_64” 도 함께 설치해줘야 한다.

mod_jk 설치

mod_jk 는 Apache 홈페이지에서 다운로드 가능하다.

설치는 apxs 를 이용해서 Apache 모듈로 설치를 해주면 끝나게 된다.

위와같이 오류없이 libtool 로 설치가 완료되면 정상이다.

mod_jk 설정

mod_jk 에 대한 설정은 기본적으로 두가지 측면에서 이루어진다. 첫째는 Apache 웹서버에서 mod_jk 를 핸들링을 어떻게 할건지에 대한 설정이고 두번째는 mod_jk 가 Apache로부터 받은 요청을 어떻게 Tomcat 에 전달할 것인지에 대한 것이다.

Apache 웹서버에서 mod_jk 설정

mod_jk 를 정상적으로 컴파일 설치했다면 Apache 웹서버에서 이를 인식시켜주고 설정을 해줘야 한다.

여기서 한가지 주의해야할 것이 있는데, CentOS7 에서 Yum 으로 설치한 Apache 의 경우에는 설정하는데 카테고리별로 디렉토리를 분리를 해놨다.

  • 모듈 로딩 설정 디렉토리: /etc/httpd/conf.modules.d
  • 모듈별 설정 디렉토리:  /etc/httpd/conf.d

모듈을 로딩하기 위해서 다음과 같이 conf.modules.d 디렉토리에서 파일을 작성한다.

이렇게 하고나서 다음과 같이 문법 테스트를 해준다. 이 문법 테스트는 설정을 변경할때마다 해주는 것이 좋다.

 

이제 Apache 에서 mod_jk 에 대한 설정을 다음과 같이 해준다.

기본적인 설정은 위와 같다. 저장한 다음에 “workers.properties”, “uriworkermap.properties” 빈 파일을 만들어 줍니다.  Apache 문법 테스트를 해보고 오류가 없다면 정상이다.

mod_jk worker 설정

이 설정은 Apache 와 Tomcat 간에 어떻게 연결을 해야하는지에 대해 정의한다. 이 파일은 위에 “httpd-jk.conf” 파일에서 “conf.d/workers.properties” 로 정의되어 있다.

여기서 고려해야할 사항은 다음과 같다.

  • worker 이름: worker 이름은 정하기 나름이지만 각각 뒷단의 Tomcat 서버를 구분할 수 있는 이름이여야 한다. 이 worker 이름은 나중에 로드밸런싱을 할때에 Tomcat 에도 적용되어지는 이름이기에 잘 설정해야 한다.
  • worker port: 여기서 말하는 port 는 뒷단 Tomcat 서버의 AJP 포트를 말한다.
  • worker type: 이건 ajp13  으로 설정하면 된다.
  • worker lbfactor: 부하분산을 위한 설정으로 뒷단 Tomcat  서버들에 연결 무게를 설정해준다.

 

mod_jk uriworkermap 설정

이 설정은 특정 URI 에 대해서 mod_jk 의 woker 가 동작하도록 해서 요청을 Tomcat 에 넘길 수 있도록 해준다. Apache – Tomcat 구조에서 최초의 요청은 Apache 가 받아 URI 를 해석하는데, 이 설정을 해주면 특정 URI 에 대해서 Apache 가 Tomcat 에게 넘기게 된다.

여기서 간단한 시나리오를 생각해보자. 현재까지 설정은 부하분산(Loadbalance) 가 없는 것이다. 각 3대의 Tomcat 인스턴스에 대해서 동일한 무게를 주었을 뿐이다. 이렇게되면 특정 URI 요청이 있을때에 어느 Tomcat 인스턴스로 보낼것인지도 문제가 된다.

테스트를 위해서 Tomcat 설치시 나오는 메인페이지를 기준으로 하기로 했다. 이 페이지를 들여다보면 jsp, png, css 파일들로 이루어져 있다. 그러면 jsp 는 instance1 서버가 서빙을 하게하고 png 는 instance2 이 css 는 instance3 이 하게 하면 어떨까하는 시나리오를 만들고 이를 설정에 적용해 보자.

 

테스트

테스트는 간단하다. 브라우저를 실행시키고 http://apache-server-ip/index.jsp 주소로 이동해보는 것이다. 이때 Tomcat 초기 메인화면이 나온다면 정상이다.

그런데, 설정에서 jsp 는 instance1이 png 파일은 instance2 이 css 파일은 instance3 이 처리하도록 설정했었다. 그렇다면 실제로 그렇게 되고 있는지 확인을 해야하는데 확인방법은 각각 Tomcat 인스턴스에 접속 로그를 확인하면 된다.

내가 확인해본 바로는 원하는대로 로그가 찍혔다.

로드밸런스 설정

앞에 예제들은 로드밸런스 설정과는 관계가 없다. 로드밸런스라고 하면 instance1 인스턴스가 응답하지 않을 경우에 다른 서버들이 그 역활을 대신하는 것을 말한다. 이를 위해서는 woker 설정과 urlworkermap 설정을 변경해주어야 한다.

일단, 테스트를 위한 시나리오는 앞에서 서빙했던 jsp, png, css 파일들은 각각의 인스턴스들이 모두 제공하는 것으로 한다. 이렇게되면 urlworkermap 설정은 다음과 같이 바꿔주면 된다.

worker 이름을 balancer 라고 했는데, 이는 worker 설정파일에서 사용할 것이다.

로드밸런스는 특정 인스턴스가 죽었을 경우에 다른 서버가 그 역활을 대신하는 것이다. 이를 위해서 로드밸런스 역활을 위한 worker 이름을 정의하고 그 worker 에 로드밸런스를 위한 worker 이름을 정의해주면 된다. 기존의 worker 파일에 다음과 같이 로드밸런스 내용을 추가하면 된다.

강조한 라인을 주의깊게 보기 바란다.

한가지 더, Tomcat 인스턴스들에게 설정을 해줘야 한다. JvmRoute 설정이라고 하는데, 이 설정을 위한 방법은 두가지가 있다. 첫째는 System.property 를 이용한 방법이고 두번째는 server.xml 을 편집하는 방법이다.

첫번째 방법은 Tomcat 인스턴스 구동시에 커맨드라인으로 값을 넣어주는 것으로 다음과 같이 해주면 된다.

보통 Tomcat 의 시작 스크립트는 JVM_OPTS 옵션을 인식한다. 위와같이 Tomcat 인스턴스의 시작 스크립트에 커맨드 라인 옵션으로 jvmRoute 이름을 주면 인식하게 된다.

두번째는 server.xml 파일을 다음과 같이 편집하는 것이다.

위와같이 설정해주면 된다.

만일 두가지 설정을 모두 했을 경우에는 server.xml 파일 설정이 우선되어 적용된다.

테스트

편한 방법으로 설정하고 Apache와 Tomcat 인스턴스를 재시작해주고 index.jsp 를 호출해보면 된다.

HTTP 접속 포트 끄기

이렇게 Apache – Tomcat 연동을 하고나면 반드시 Tomcat 인스턴스의 HTTP 접속 포트를 Disable 해주는걸 잊지 말아야 한다.

 

 

가상 머신에 콘솔 접속하기

CentOS 6/7 혹은 RHEL 6/7 은 KVM 가상화를 지원 합니다. 가상화를 위한 네트워크를 설정하고 가상화 패키지를 설치하면 이제 가상 머신, 게스트 OS 를 설치할 수 있게 됩니다. 그런데, 맨 처음에 게스트 OS 를 설치하고 나면 더구나 DHCP 로 IP를 할당 받는다면 설치가 끝나고 나서 할당된 IP를 모르기 때문에 바로 접속을 할 수가 없습니다.

그래서 virt-manager 를 이용해서 게시트OS 화면에 접속하고 로그인을 하고 IP를 확인한 후에 SSH를 이용해서 외부에서 접속이 가능해 집니다. 하지만 이것말고 호스트 OS 터미널에서 게스트 OS로 virsh 명령어를 이용해서 접속할 수 있는데 이것이 가상 머신에 콘솔 접속하기 입니다.

virsh 명령어

virsh 명령어는 호스트OS에서 게스트OS(가상머신)을 관리하기 위한 명령어 입니다.

가상머신 이름이 나오는데, 이를 이용해서 다음과 같이 직접 게스트OS에 접속이 가능합니다.

하지만 게스트OS에 접속이 안됩니다.

게스트OS Grub 설정 변경

이를위해서 게스트OS에 Grub 에 옵션으로 다음과 같이 ‘console=ttyS0’ 을 추가해 줍니다.

하지만 이렇게 하나하나 다 하기보다는 다음과같은 명령어를 이용하면 편합니다.

CentOS6/RHEL6 의 경우 – grubby

grubby 는 각종 옵션들을 쉽게 설정할 수 있게 해줍니다. 위의 경우에 다음과 같이 할 수 있습니다.

CentOS6/RHEL6 에는 이렇게만 하고 서버를 재시작해줍니다.

CentOS7/RHEL7 의 경우 – /etc/default/grub 편집

CentOS7/RHEL7 의 경우에는 grub2 를 채택하고 있고 공통적인 옵션들은 ‘/etc/default/grub’ 파일에 있습니다. 이 파일을 편집해 줍니다.

이렇게 하고 grub2 를 다음과 같이 갱신해 줍니다.

위와같이 하고 난후에 가상머신을 재시작해줍니다.

접속 테스트

가상머신을 재시작한 후에 호스트OS에서 다음과 같이 접속을 해봅니다.

명령어를 입력해주고 Enter 를 두번 쳐주면 접속 로그인이 나옵니다. Console 접속을 해제하기 위해서는 Ctl+] 를 입력하시면 됩니다.

 

Tomcat Manager 접속 제한.

톰캣은 웹에서 톰캣을 관리할 수 있도록 Manager 페이지를 제공합니다. Tomcat 에 대한 관리를 어느정도 할 수 있기 때문에 보안상 Tomcat Manager 접속 제한 을 해서 아무나 접속을 못하게 하는것이 좋습니다.

방법은 VirtualHost 설정디렉토리에 manager.xml 파일을 작성하는 겁니다.

Allow 에는 IP 주소나 도메인을 넣을 수 있으며 IP의 경우에 Subnet 으로도 표시가능하고 도메인의 경우에는 *로도 표시가 가능합니다.

 

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

Tomcat manager 암호화 패스워드 설정

Tomcat 에는 Tomcat 서버를 관리를 쉽게 하기위한 GUI,Script 페이지를 제공합니다. 그런데, 여기에 접근하기 위해서는 인증을 설정해야 하는데 이는 $CATALINA_BASE/conf/tomcat-users.xml 파일에 설정하도록 되어 있습니다.

그런데, 여기에는 패스워드를 입력하도록 되어 있는데 텍스트로 되어 있습니다. 보안상 좋지 않습니다. 그래서 Tomcat manager 암호화 패스워드 설정 을 하는게 좋습니다.

이 문서는 Tomcat 7.x 버전에서 테스트 되었습니다.

Digest 암호화 생성

다음과 같이 패스워드를 생성 합니다.

SHA 암호화된 패스워드가 나왔습니다. 이것을 다음과 같이 $CATALINA_BASE/conf/tomcat-users.xml 에 넣어줍니다.

이제 이러한 암호화 패스워드를 Tomcat 서버가 알아먹도록 설정을 해줍니다. 설정은 $CATALINA_BASE/conf/server.xml 에 다음과 같이 해줍니다.

이제 Tomcat 을 재시작 해줍니다.

Tomcat 에러 정보 숨기기

Java 애플리케이션을 작성할때에 에러 발생시 보여줄 에러 페이지를 설정할 수 있습니다. 웹 애플리케이션 설정 파일인 web.xml 파일에 다음과 같이 해줍니다.

단순하게 HTTP 응답코드 뿐만 아니라 Java Exception 객체에 따른 에러도 설정할 수 있습니다.

하지만 이러한 것은 웹 애플리케이션 개발단계에서 설정을 하는 것인데, 이것 말고 서버단계에서 Tomcat 에러 정보 숨기기 를 할 수 있습니다.

Java Application 에러

Tomcat Server 정보 숨기기

에러가 발생했을때보면 Tomcat 서버의 정보가 함께 표시됩니다. 불필요한 정보 입니다. 이를 숨기거나 다른 것으로 서버단에서 바꿀 수 있습니다. $CATALINA_HOME/lib 디렉토리로 이동하고 다음과 같이 디렉토리를 만들어 줍니다.

그리고 다음과 같이 파일을 작성합니다.

그 다음 Tomcat 을 재시동 시켜 주면 적용이 됩니다.

HTTP Header 에 서버 배너 삭제

잘 모르는 이야기인데, 위에처럼 서버정보를 숨긴다 하더라도 다음과 같이 HTTP Header 에는 배너가 추가됩니다.

톰캣 HTTP Header 배너

Server 에 보면 “Apache-Coyote/1.1″ 가 나옵니다. 이는 다음과 같이 설정함으로써 안나오게 할 수 있습니다.

위에 보는 것처럼 Server=” ” 를 추가해주고 톰캣을 재시작하면 됩니다.

자세한 오류 정보 숨기기

오류가 발생하면 Tomcat 은 아주 자세한 정보를 보여줍니다. 여기에는 파일의 위치, Java 애플리케이션의 Stack trace 까지 다 나옵니다. 이를 막는 방법은 아주 간단합니다.

단, 이 방법은 Tomcat 7.0.55 이상 버전이여야 합니다.

Tomcat 은 여러가지 서버단에서 필터를 넣을 수 있습니다. Tomcat 의 동작에 여러가지 옵션을 넣거나 바꾸거나 하는 겁니다. 이를 필터라고 하지 않고 밸브(Valve)라고 하고 밸브를 통해서 여러가지 설정을 할 수 있는데, 자세한 오류 정보 숨기기도 밸브를 이용해서 가능합니다.

위에 보면 Host 설정안에 ErrorReportValve 를 설정하고 있습니다. 이렇게 설정을 한 후에 톰캣을 재시작 시켜주면 적용됩니다.

CentOS에서 SNMP 설치 및 설정하기

SNMP(Simple Network Management Protocol) 은 원래 네트워크 장비를 관리하기 위한 통신 규약입니다. 그런데, 이제는 네트워크 장비뿐만아니라 컴퓨터, 전자장비까지 확장해서 사용하고 있습니다. 리눅스 시스템에서도 SNMP를 사용할 수 있습니다.

이를 이용하면 SNMP 를 이용해서 중앙집중식으로 각각의 장비들의 자원, 자원사용량등을 장비에 거의 모든 것을 알 수 있고 가지고 올 수 있습니다. 저의 경우에는 Cacti 라는 시스템 자원 모니터링 시스템에서 원격 시스템의 자원 사용량을 가지고 오기 위해서 각 서버마다 SNMP를 사용합니다.

준비

이 문서는 다음과 같은 환경에서 작성되었습니다.

  • CentOS 7
  • X86_64

SNMP는 서버/클라언트 구조를 가지고 있습니다. 중앙 집중식으로 한 곳에서 정보를 모을 경우에는 중앙 서버를 제외하고 SNMP 데몬만 설치해주면 됩니다.

설치

설치는 Yum 을 이용해 다음과 같이 해주면 됩니다.

위에 뒷부분 ‘net-snmp-utils’ 는 SNMP 데몬하고는 아무런 관련이 없기 때문에 설치를 않해되 되지만 SNMP 데몬의 제대로 동작하는지를 테스트하기 위해서는 설치해주는 것이 좋습니다. ‘net-snmp-utils’ 는 말 그대로 SNMP를 다루기위한 여러가지 명령어들이 들어 있습니다.

설정

CentOS7 의 특징은 데몬이 실행될때에 옵션을 제공해 줄 수 있는데, 이를 위해서 ‘/etc/sysconfig’ 디렉토리에 데몬이름으로 파일을 가지게 됩니다. 그러면 데몬 실행 프로그램에서 이를 import 해서 사용하곤 하는데 SNMP 데몬도 이와 같습니다.

먼저 데몬 실행 옵션을 다음과 같이 설정 해줍니다.

위 옵션들은 다음과 같습니다.

  • -Ls 는 로그 메시지 stderr, stdout 으로 내보내고 로그레벨을 정한다. 기본은 -Lsd 로 d 는 LOG_DEBUG 을 말한다. 로그의 수준은 0 ~ 7 까지 존재하는데 다음과 같다.

    이는 -LSwd 나 -LS4d 식으로 숫자와 알파벳으로 지정할 수 있다. -LSed / -LS3d 같은 예제이다. 또, -LS1-5d 처럼 로그레벨 수준을 어디서 어디까지로 정할 수도 있다. 위 예제에서는 데몬 메시지를 syslog 로 보내는데 로그 레벨 1~5까지를 보내라는 뜻이다.
  • -Lf 는 지정한 파일로 로그 메시지를 보낸다. 위 예제에서는 /dev/null 임으로 로그 메시지를 삭제하는 효과를 보인다.
  • -p 는 pid 파일을 지정해 준다.

다음으로 SNMP 자체 설정을 합니다. 아래의 예제는 시스템 자원을 읽기 전용으로만 설정하는 것입니다.

SNMP 설정은 ‘sec.name’ 별로 설정을 할 수 있습니다. sec.name 을 여러게 정의하면 group도 여러개 설정할  수 있고 이렇게 되면 access 도 여러개 설정할 수 있습니다. 주목할 것은 access 에서 뒷부분에 read, write, notif 가 보이는데, 위 예제가 시스템 자원을 읽기만 할 것이기 때문에 read 부분만 all 로 하고 나머지를 none 으로 한 것입니다.

마지막으로 systemd 에 snmpd 를 활성화 해주고 시작해 줍니다.

로깅 변경

위 설정대로 하면 snmpd 로그가 /var/log/messages 에 저장이 됩니다. 하지만 /var/log/messages 는 커널 메시지도 저장되고 하는 중요한 것이여서 별도 파일에 저장하는 것이 좋습니다.

이를 위해서 snmpd 를 위한 별도의 로그 파일 설정을 해주는데, 먼저 /etc/sysconfig/snmpd 설정을 다음과같이 바꿔 줍니다.

rsyslog 데몬에서 다음과 같이 설정해 줍니다.

위에 예제에서 첫번째라인은 로그레벨 6 에 대해서는 /var/log/message 에서 제외하고 로그레벨6은 /var/log/snmpd.log 에 저장하도록 지정한 것입니다.

이렇게 해주고 데몬을 재시작 해줍니다.

로그 로테이션도 설정해 줍니다.

만일 일일이 출력하고 싶지 않다면 /etc/snmp/snmpd.conf 파일에 다음과 같이 설정해 줍니다.

 

Firewalld 설정

CentOS 7 에서는 iptables 에서 firewalld 로 변경되었습니다. snmpd 를 위해 firewalld 를 설정해 줘야 합니다.

먼저 snmp 관련해서 방화벽 열기위한 정보를 xml 파일로 작성해 줍니다.

그리고 다음과 같이 public zone 에 등록해줍니다.