Start-up 인프라를 클라우드로 구성하면 장점이 많습니다. 사업성이 보장되지 않는 상태에서 장비 구매비용(혹은 연단위 임대비용)과 장비 delivery에 대한 시간투자, 장비 관리 시간투자 등의 비용을 많이 절약할 수 있습니다. 이런 이점은 Start-up 기업들이 우선적으로 고려하는 인프라 환경을, 클라우드라는 가상의 환경으로 고려하는 이유이기도 합니다. 그러나 클라우드는 사용한 비용만큼 지불하는 구조임에도 불구하고, 결코 저렴하다고는 말할 수 없습니다. 또한 클라우드 환경의 관리가 편하다라고 말할 수는 없습니다. 비용 효율화를 위해 관리자(클라우드 인프라 관리자)는 쓸데없는 비용 누수에 신경써야하며 누구나가 의심하는 클라우드 환경의 보안 부분을 신경써야 합니다. 하지만 잘 구성되어있는 환경이라면, 저렴한 비용과 관리의 편리가 가능합니다.
처음 잘 구성되어야 한다는 선행조건을 만족하기 위해, AWS 클라우드 환경의 인프라 설계와 설계된 구성에서의 기본적이지만 필수적인 사항을 이야기 하려 합니다. 작년 하반기 정부의 클라우드 발전법 발의와 이번달(2016년1월) AWS 한국 지역 오픈으로, 지금까지보다 클라우드 환경이 더 많이 사용될 것으로 예상됩니다.
다음 그림은 WEB - WAS - DB 구조의 평범한 3-tire 아키텍쳐입니다. CDN사용과 캐쉬용도의 in-memory 서버, 세션 클러스터링을 위한 No-SQL이 부가적으로 구성되있습니다.
AWS 아키텍쳐는 기본적으로 다음의 사항을 고려해야합니다.
1. HA(High-Availability) : SPOF(Single Point of Failure)제거
고가용성은 가상의 환경에서 서비스를 위한 필수적 요건입니다. HA를 하나의 지역(Region)에 2개 이상의 가용영역((Availability Zone : AZ)) 구성과 DR를 위한 여러 국가(Region)를 이용하는 방법이 있습니다.(주: local서비스를 위해서 Backend 서비스는 HQ에 Frontend 서비스만 전국가로 배치하여 구성하는 경우가 많습니다.) AWS가 99.5%의 신뢰성을 보장하지만, 0.5%의 실패 가능성 때문에 가상의 환경에서는 반드시 Fault-Tolerant 환경으로 구성해야합니다.
요즘 대부분의 솔루션(FOSS 혹은 상용제품)들은 HA구성과 Clustering를 지원합니다. 반드시 가상화 환경에서는 Standalone 상태의 SPOF를 제거하는 설계를 해야합니다.
2. 보안
보안은 귀찮고 불편하지만 클라우드 발전법의 정보보호 대책이 구체화되면서 좀더 신경을 써야될 부분입니다. AWS에서 제공되는 기본적인 서비스를 이용하여 최소한의 보안 구성을 할 수 있습니다.
다음 그림은 AWS에서 서비스를 위한 최소한의 VPC 구성을 나타냅니다. Public Subnet과 Private Subnet을 구분하고 Public 구간은 DMZ에 해당하는 구간으로 외부 ELB, Bastion Host만 위치시킵니다.
그외 biz logic 처리 서버들은 Private Subnet에 위치하여 외부로의 침입을 차단합니다. 이 VPC 환경과 Public/Private subneting은 기본으로 설계되어야 합니다.
다음 그림은 VPC에서 지원하는 Subnet/ RouteTable/ SecurityGroup / NetworkACL과의 보안관계를 나타냅니다.
보안 구성 요소를 서비스별로 나열하면 다음과 같습니다.
- IAM : ROOT계정은 credential을 생성하지 않습니다. ROOT계정은 MFA 인증으로 two-factor 인증으로 구성하며, 웹 콘솔 사용은 Admin 권한의 신규 유저(two-facto인증)를 사용합니다.
- EC2 : On-premis의 보안 수준에 준하여(iptable, TCPWapper등) 구성합니다. 사설망과 공인망의 EC2 MasterKey(KeyParis)는 분리하여 보관합니다. EC2는 Role을 부여하여 서버내에 혹은 AWS API 소스내 Credential를 저장하지 않습니다.
- VPC : 사설망과 공인망을 분리하여 Tier간 subneting으로 구분합니다. RDS를 포함한 서비스 EC2는 반드시 사설망에 위치시킵니다.
- SecurityGroup : ALL(0.0.0.0/0)의 Source, Port는 제거합니다.
- NetworkACL : Subnet간 ACL를 구성합니다.
- RouteTable : Subnet 간 통신을 위한 라우팅을 설계합니다.
- Bastion Host : 사설망의 EC2는 Bastion Host를 통해서만 접속하도록 구성합니다. 평소 사설망 EC2 접속이 필요없다면 stop상태를 유지합니다.
- NAT G/W : 사설망의 EC2는 외부접근을 위해 NAT G/W를 이용합니다. NAT EC2는 외부에 취약요소가 됩니다.
- S3 : bucket의 policy를 적용하여 bucket내 자료 접근을 통제합니다.
- CloudFront : WAF를 구성하여 XSS, SQL-Injection의 위협을 완화합니다.
- ELB : SSL 적용으로 웹구간 암호화를 적용합니다.
- RDS : DB관리자의 원격지 서버접속은 SSL을 이용합니다. EBS는 Encrypt 옵션을 적용합니다. (Oracle이면 HSM를 적용하여 TDE로 구성합니다.)
참고가 될 AWS 백서 : http://media.amazonwebservices.com/AWS_Security_Best_Practices.pdf
3. Decoupling = Loose-coupled => 자동화
사용 리소스를 넉넉히 할당하여 서비스를 하면 리소스 관리는 편하지만 그만큼 비용이 발생하게 됩니다. 클라우드의 자원 50% 내외의 사용량을 유지할 정도로 리소스를 할당하고, 클라우드의 강점인 Auto-Scaling 기능을 이용하면 비용 효율화를 할 수 있습니다. Auto-Scaling은 리소스의 Spike 대응으로 scale in/out, scale up/down이 유연하게 자동으로 구성할 수 있습니다. AWS에서 서비스되는 ELB, DynamoDB, SQS등 Auto-Scaling을 자체적으로 지원하는 서비스를 우선으로 고려하고, 자체 서비스 특성상 솔루션을 도입해야할 경우 scaling에 적합한 구조로 구성해야합니다. 예를 들어, WEB서버와 WAS서버 연동을 위해 중간에 Internal ELB를 구성하여 WEB서버 증설시 WAS가 영향을 받지 않고, WAS 증설시 WEB서버에 영향을 받지 않는 구조로 구성해야 합니다. 이는 기본적으로 tier간 decoupling으로 구성해야 하는 이유입니다.
Auto-Scaling 기능의 비용 절감 이외
- Java heap 메모리 조절로 EC2 type을 다운 사이징
- 예약인스턴스(Reserved Instance) 도입 (단, RI 계약은 해지시 제약이 있으므로 신중해야합니다.)
- 유휴시간의 개발서버(RDS포함)는 STOP
- GP2의 Brusting 기능으로 좀더 낮은 비용으로 IOPS 성능 효과
- Route53은 CNAME보다는 Alias로 구성
등의 방법으로 AWS서비스별로 비용 절감의 요소가 있습니다. 또한 주기적으로 Trust advisor를 이용하여 비용이 누수되는 부분을 체크하는 것도 효과가 있습니다.
클라우드 환경은 리소스의 제한없이 사용자가 유연하게 구성이 가능하다는 장점이 있는 반면, 과도한 비용청구와 보안이 취약하다는 약점이 존재합니다.
앞서 언급한, 처음 잘 구성된 환경은 저비용에 관리가 용이한 구성으로, On-premise보다 더 ROI를 낼수 있는 가능성이 충분이 있습니다.
