Architecting for Cloud

Cloud를 위한 Architecting 은 뭔가 달라야 할까?

기본적으로 내 생각은 Cloud를 위한 Architecting 은 기본적인 분산 시스템을 만드는 것과 달라서는 안된다고 생각한다.

결국 특별한 Cloud 서비스용으로 뭔가를 사용한다면, 해당 시스템에 Lock-in 될 가능성이 높아지기 때문이다.

http://aws-musings.com/architecting-for-cloud/#more-376 에 보면, Architecting for Cloud  관련 내용이 나와서 간단하게 정리해보려 한다.

이 글을 쓰신 분은 Amazon 을 이용한 내용이지만,  어디든 적용가능 할만하다.(그리고 내가 적는 내용은 위의 글의 내용을 내가 이해한 대로 좀 변경하고, 본인의 경험을 추가했다.)

1. 특별한 Components 가 없더라도 동작하도록 아키텍처를 구성하라.

– 시스템의 일부분이 다운되었을 때를 가정한다.  만약, 블로그 서비스등을 하는데, 메인 DBMS 가 장애나서 데이터를 가져올 수 없는 상황이라면, 어쩔 수 없다.

(이런 케이스는, DBMS를 이중화 하는 형태로 처리를 해야한다.)

– 그런데 여기서 말하듯이, Configuration 서버 등이 장애가 났을 경우, 서비스가 돌지 않는다면, 전체 시스템의 작은 일부분 때문에, 전체가 돌지 않는 것은 문제가 생긴다.

그럴 때에도 동작할 수 있도록 하는 것이 필요하다. 최근에, 캐시 서버에 접속하지 않으면, 대기하는 코드 때문에, 캐시 서버에 장애가 났을 때, 서비스가 돌지 않는 문제가 발생했었다.  캐시 서버를 이용하면, 성능이 좋아지지만, 캐시 서버의 문제가 생기더라도, DB 서버에서 동작하게 되어서 서비스에 문제가 없어야 한다.

(이럴 때, 다른 이슈가 발생할 수 있는데, 캐시 서버로 인해서 성능이 좋아져서, 서버를 줄이게 되면, 캐시 서버가 문제가 되었을 때, 서비스에 문제가 생길 수 도 있다.)

2. 중요한 서비스는 Elastic load Balancer 를 이용하라.

– 중요한 서비스는 부하시에 문제가 발생하지 않도록 Elastic load Balancer + Auto Scaling 을 이용하라는 내용이다.

( 실제로, 서비스에 우연히 특정 시점에 부하가 많이 몰리는 경우가 있다. 이 때, 제일 아쉬운 것이 클라우드 서비스를 이용하면, 바로 장비를 추가할 수 있을텐데 라는 생각이 들 때가 있다. 클라우드 서비스의 장점도 몇 분안에 장비 추가나 제거가 가능하다는 데 있다. )

3.  디스크의 데이터가 중요하다면 EBS Volumes 을 이용해라.

– EBS Volumes 의 경우, RAID를 이용하는 것 처럼, 내부 디스크가 깨어지더라도, 어느 정도의 안전성을 보장한다.(RAID + Hotspare 로 구성하게 되면, 디스크가 깨지더라도 서비스를 진행하는데 문제가 없다. Raid를 HotSpace 디스크로 재구성 하는 시간이 걸리지만, 서비스가 가능하다. 일반적으로 하드웨어 장애는 디스크 장애가 가장 빈번하다.)

EBS Volumns의 경우,  가상 머신에 문제가 있을 때, 다른 Instance 에 마운트 해서 이용하기도 쉽고, Snapshot 생성하는 것도 굉장히 쉽다.)

4. 데이터를 여러 장비에 중복해서 저장하라.

– 분산 파일 시스템을 이용하여 데이터를 저장하라. 데이터의 유실을 피하기 위해서 hdfs 나  여러 분산 파일 시스템을 이용하는 것이 좋다.

( 보통 3 copy를 이용하면 거의 유실 없이 데이터가 안전하다고 말을 하지만, 실제로 가끔씩 3copy 가 깨지는 케이스도 상당히 많다. 일반적으로는 3 copy + tape backup 등으로 추가로 백업이 필요하다. )

5. Snapshots 을 자주 생성해라.

– 가능하면 매 시간 마다 Snapshots를 구축하라.(필요하다면 증분 백업을 하는 것도 가능하다. http://aws.amazon.com/ebs/)

6. 자기 자신의 시스템을 설치하지 말고 아마존에서 제공하는 서비스를(SNS, SQS) 를 이용해라.

– 개인적으로는 이렇게 서비스를 이용하게 되면 아마존에 Lock-In 되지 않을 까 싶은데, 따로 구축하는 것보다는 이를 권장하다고 하고 있다.

– 아마도 적절한 Queue 시스템을 만드는 것이 어렵기 때문이 아닐까 싶다.(이런 Queue 시스템은 여러 모로, 있으면 좋다.)

7. 좋은 사례를 따라가라.

– 좋은 EC2 구축 사례가 다음 사이트에서 다운 받을 수 있다.

http://jineshvaria.s3.amazonaws.com/public/cloudbestpractices-jvaria.pdf

직접 읽어보시면, 뭔 번역 내용이 실제 내용과 왜 이렇게 달라라고 말씀하실 수 있기 때문에, 제가 영어를 못한다는 걸 미리 밝혀드립니다.