IDC 서버를 Amazon 클라우드로 마이그레이션 하고 난 후기

HYEONG HWAN, MUN/ 7월 14, 2015/ 미분류/ 6 comments

https://blog.lael.be/post/1591

글 작성 이후에 서버의 구성을 조금 바꾸었습니다.
예를 들어 현재 제가 관리하는 시스템은 사용자의 관여 없이 자동으로 장애처리 및 오토스케일링(UP&Down)이 작동합니다.
해당 내용은 추후 글 수정시 추가하도록 하겠습니다.

< 그림 : 장애가 발생하여 자동으로 서버가 증설되었고, 장애 상태가 종료되어 증설된 서버가 자동으로 제거되었다 >

서버 관리자의 개입 없이 전자동으로 이루어지는 프로세스이며,

최종 고객이나 담당자 그리고 서버관리자까지도 장애를 느끼지 못한다.

---

#글 본문시작.

최근 회사의 서비스 인프라를 아마존 클라우드로 이전하였다.

물리서버(Metal Server)를 오래사용되다 보니까 원인을 알 수 없는 하드웨어 장애가 발생하더라.

 

서버 운영의 유연성과 하드웨어 장애로 부터 벗어나기 위해서 Cloud 환경으로 바꾸어보았다.

 

- 클라우드 인프라의 장점

 

- 빠른 설치 및 운영 대기 시간 감소 : IDC 에서 신규 장비 입고 후 구축하면 최소 이틀 걸린다. 클라우드 환경에서 신규 서버 추가는 5분이면 충분하다. 물론 미리 준비된 서버를 임대계약하면 물리서버도 빠른 시간내에 추가 가능하긴 하다.

IDC는 세팅시 인건비가 들어간다. 클라우드는 전자동이며 확실하고 동일한 품질을 보장하며 세팅비가 들지 않는다.

- 하드웨어 장애 없음 : 클라우드 환경에서도 장애가 발생하기는 한다. 하지만 가상화가 되어 있어서 사용자의 입장에서는 장애를 느끼지 못한다.

하드웨어 교체에 대한 Risk 가 없다. 그냥 고장나지 않는 서버를 쓰기만 하면 된다.

- 하드웨어 변경이 쉬움 : 서버에 메모리를 증설한다고 가정하자.

물리 서버라면 서버 메인보드 종류를 확인하고, 메모리 슬롯이 몇개 사용가능한지, 메인보드가 지원하는 메모리 인터페이스를 보고 적절한 제품을 구입해서 장착한다. 서버를 서버거치대(렉)에서 빼고 뚜껑열어서 메모리 꼽고 다시 장착하고 정상부팅 확인해야 한다.
하지만 클라우드 환경에서는 메모리 변경이나 디스크, CPU 변경 같은 작업을 하기위해 서버를 분해할 필요가 없다.

- 하드웨어 비용 절감 : 더 이상 서버의 부하 대처를 위해서 서버를 미리 입고해서 대기하고 있을 필요가 없다.
서버 수요가 생기면 바로 생성하면 된다. 비싼 하드웨어를 구입하지 않아도 사용할 수 있다. L4로드벨런서를 한달에 3만원이면 사용할 수 있다.

- 인건비 절감 : 직접 IDC 를 방문해서 작업하는 것이 아니라 클릭으로 관리하기 때문에 기존 만큼의 많은 인력이 필요하지 않다.

- 빠른 장애 대처 : 장애 대처에 빠르다. 서버 폭주로 불능상태가 된 서버가 있다면 오른쪽 클릭해서 재부팅 버튼 누르면 된다.

 

클라우드 환경에서는 이런 기민한 대처를 할 수 있다.

 

---

 

IDC 서버 환경

원본 시스템은 웹 서버 5대, 모니터링 서버 1대, L4 1개, DB 서버 2대, NFS 서버 2대, 웹 인증 서버 2대, 개발 서버 1대, 미디어 서버 6대이다.

미디어 서버의 경우 이전시 이득보다는 손실이 크다고 판단되어 이전하지 않기로 하였다.

 

시스템의 규모가 클 뿐더러 서비스 중단 없이 옮겨야 해서 고생 좀 했다.

 

1. EC2 생성하여 환경 적합성 검토하기

가장 먼저 해야 할 작업은 “이전 할 수 있는가”를 판단하는 것이다.

실서비스 환경을 구축해 보고 테스트 해 본다.

소프트웨어 변경에 따른 시스템 동작여부를 테스트 해 보아야 한다.

 

라엘이의 경우

CentOS 5.7 32bit -> Amazon AMI 2015.03 64bit

Apache 2.2 -> Apache 2.4

PHP 5.2 -> PHP 5.6

MySQL 5.2 -> MySQL 5.5

으로 소프트웨어 환경을 바꾸었다.

 

이에따라 환경설정 파일을 변환하고, deprecated 된 함수를 제거하거나 대체하고,

전자결제나 본인인증 확인시 사용되는 Apache 확장 프로그램을 재 컴파일 하였다.

 

 

서비스를 구동할 수 있는 수준까지 변환 작업을 하였다.

 

2. RDS 생성하기

실 서비스 구동 가능성이 확인되었으니, DB 서버를 분리 구축하는 작업을 진행하였다.

Amazon RDS 에서 인스턴스를 생성한 후 연결하였다.

EC2 에서 RDS 로 신뢰할 수 있는 내부망으로 연결되며, 내부 트래픽은 과금되지 않는다.

 

RDS 에서 환경설정 할 것이 매우 많으니 사용 환경에 맞게 튜닝하도록 하자.

 

그리고 디비 Restore 테스트를 해보아야한다. 실서버의 데이터를 덤프받은 후에 RDS 로 넣어본 후 예상되는 서비스 장애시간을 계산해본다.

글로 설명하기 쉽지 않아 따로 적지는 않지만 몇몇 기법을 사용해야 할 것이다.

100만건 데이터 insert 기준 1초 이내 시간이 소요되어야 한다. (한국서버에서 Tokyo 인스턴스로 삽입시)

 

3. S3 생성하기

서버간에 공유폴더를 사용해야 할 일이 있어서 생성했었는데… 최종적으로는 사용하지 않았다.

공유폴더로 사용하기에는 빠른 속도의 I/O가 나오지 않았다.

Amazon 에서 공유폴더용 파일시스템인 Elastic File System 을 준비하고 있다고 하니 기다려 보도록 한다.

 

EFS 가 출시되기 전까지는 자체적으로 공유파일 서버를 구축하여 운영한다.

메인 서버를 두고 sshfs 를 통해 파일을 공유한다.

 

4. 백업정책 설정하기

RDS는 세팅옵션에 백업 정책을 정할 수 있다. 매일 백업 15일 보관을 하도록 하였다. 시스템 중단없이 자동으로 백업한다.

증분 백업이라서 백업시 스토리지 용량이 크게 늘어나지 않는다. 백업 스토리지는 사용량의 100%까지 무료이며 초과시 S3 용량단위로 과금한다.

EC2 인스턴스는 데이터 백업을 해야 하는데 volume 백업은 AWS Command Line Interface 로만 가능하다.

Bash 스크립트로 백업을 하도록 짰고 cron 을 설정하여 1일 2회 백업을 하도록 하였다.

(참조 : http://docs.aws.amazon.com/cli/latest/userguide/getting-help.html)

 

볼륨데이터를 백업할 때에 서버를 종료할 필요가 없다.

 

5. ELB 설정하기

Elastic Load Balancer 이다. 널리 쓰이는 HTTP, HTTPS, TCP 프로토콜 로드밸런싱을 지원한다.

POST Routing 방식이라서 ELB와 연결해주는 서버에서 IP 포워딩 부분을 설정해 주어야 한다. 올바른 서비스를 위해서 아파치의 mod_rpaf 모듈이 필요할 것이다.

Health Check 부분이 있는데, 처음에는 사용하기 쉬운 TCP 80 Ping 방식을 사용했는데, 나중에는 HTTP 페이지 체크방식으로 바꾸었다. 자신의 시스템에 맞게 unhealthy  한 상태를 정의하도록 하자.

 

6. 서버 이미지 생성하기

비슷한 용어로 3가지가 있는데, SnapShot은 볼륨의 증분백업본을 말하고, SnapShot을 가지고 Volume 을 만들거나 Image 를 만들 수 있다.

Image는 Volume + 하드웨어 설정값 을 말한다.

 

 

7. 오토 스케일 그룹 설정하기

자동으로 서버가 늘어나고 줄어드는 것을 설정할 수 있다.

Amazon Machine Image를 선택하고, 최대 최소 갯수 및 증가 감소 조건을 지정하면 된다.

 

8. Cloud Watch 설정하기

서버 및 ELB, AutoScale 그룹의 이상상태를 감지하고 알람을 만들 수 있다.

메인 서버의 CPU가 70% 이상일 경우 서버가 5분마다 1대씩 추가되도록(Scale - Out) 하였다.

LoadBalancer 내의 서버중 Unhealty 한 서버가 있을 경우 서버를 자동으로 1대 추가하도록 하였다.

AutoScale 그룹의 평균 CPU 사용량이 50% 이상일 경우 5분마다 1대씩 추가하도록 설정하였다.

 

CPU 이외에도 다양한 조건을 지정할 수 있으니 자신의 시스템에 맞게 설정하도록 하자.

 

9. 네임서버 이전

Route53 을 사용하면 도메인을 ELB 와 연결할 수 있다.

Route53을 사용하지 않으면 ELB 의 CNAME을 설정하여 연결할 수 있다.

서비스의 중단을 피하기 위해서 기존 네임서버와, Route 53 의 네임서버내 레코드를 동일하게 유지하도록 하였다.

 

10. 웹서버 이전

Rsync 를 통해 파일을 동기화 하였다.

그 후에도 아마존 서버에 프록시 설정을 해서 기존 서버를 사용하도록 한다.

DNS 의 전파속도가 오래 걸리기 때문에 프록시 세팅이라는 선행 작업을 하여야 한다.

- 프록시 세팅은 이 글을 참조하세요. https://blog.lael.be/post/1023

 

 

11. 디비 서버 이전

안정성에 위안을 삼지만… Amazon RDS 가 생각만큼 엄청 빠르지는 않다. 비용도 만만치 않다.

 

12. 최종 이전

DNS 전파가 길면 이틀이 걸리기 때문에 DNS 에서 A 레코드를 아마존 서버로 바꾼지 이틀 후에 작업한다.

웹과 디비 이전을 다시 한번 진행한다. (웹은 Rsync 증분 전송이 될 것이고, DB 는 다시 덤프해서 다시 넣도록 하자. DB 작업이 오래 걸린다.)

웹과 디비 이전이 끝나면 프록시 설정을 풀고, 아마존 서버에서 서비스 하도록 하자.

무중단 서비스이기 때문에 이전 도중의 데이터는 손실이 일어난다. 라엘이의 경우 사람이 없는 새벽 시간대에 작업하였다.

이전 후 회원, 게시판, 결제정보등의 민감한 정보에 대해서 다시한번 디비 비교를 하였다.

 

서버 Monitor 탭을 보면서 AutoScale 정책을 수정한다.

 

아 그리고 비용처리에 있어서 세금계산서가 필요하신 경우 국내딜러(메가존이나 호스트웨이 같은 업체)를 이용하면 된다.

메가존 (http://hosting.kr/index_new.jsp#Cloud_AWS)

호스트웨이 (http://aws.hostway.co.kr/)

 

내가 사용료를 한국 돈으로 -> 국내 딜러에게 지불하고 세금계산서를 받는 것이다.

딜러가 -> 아마존에 적절히 결제해 준다.

 

단점은, 딜러를 이용해서 한국 돈으로 결제하면 부가세 10%가 추가된다. 지원사업 사업비 처리를 위해서라면 국내딜러를 통해 결제하고, 내 돈 나가는 것이면 직접 달러결제하는 것을 추천한다.