클라우드
인프러스트럭처 부분을 가상화 및 리소스화 해 개인과 기업을 불문하고 전 세계 사용자가 이용할 수 있는 서비스
장점
- 하드웨어 장비에 대한 유지비용, 인건비 절감
- 적절한 설계 수행시 장애 발생 가능성 낮음
- 서버 증설, 스토리지 증설과 같은 요구에 대한 민첩성
온프레미스와의 차이
클라우드 | 온프레미스 | |
컴퓨터(서버) | 클라우드 | 가상화 |
인스턴스 크기 | CPU모델명, 코어수, 하이퍼스레딩 기술 유무 | |
스토리지 | 객체전체 | DAS, RAID 구성에 따른 유효 실행량, IOPS |
네트워크 | VPC, WAF, TFW 등의 제공되는 서비스 | 레이어, 포트, 대역, VLAN 및 다중화 등의 논리 설정, WAF, 보안 등 경우에 따른 역할 |
기타 | 계정과 권한의 역할 | 크게 논의되지 않음 |
구축하는 시스템의 목적 | 만들면서 생각 | 비즈니스 계획 준수 (시스템 비용 포함 예산) |
목적 실현하기 위한 구상 | PoC등으로 구현, 리소스의 증감은 나중에 유연하게 대응 | 사전 용량 계획, 높은 SLA를 실현하기 위해 시스템 검토 |
설계/구축 | Well-Architecture, CDP 등을 이용해 infrastructure 부분은 즉시 구축하고 애플리케이션 부분은 애자일 개발 등 깃허브나 소스코드에서의 관리 | 실제로 수행할 일을 WBS등으로 정의하고 체제를 정비해 항목별로 성과를 달성, 코드에서의 관리 외에 문서에 매개변수 시트 등을 보관 |
시스템 개발 방식
폭포수 모델
개발 공정을 요건정의, 설계, 개발, 테스트 순으로 수행하는 개발
개발하는 인프라스트럭쳐나 애플리케이션 사양이 결정된 경우
애플리케이션이 모놀리식 아키텍쳐이고, 세분화할 수 없는경우
장점
- 개발 공정의 흐름이 명확하기 때문에 개발 기간이나 필요한 인원 수 등을 계획 및 관리하기 쉽다.
- 요건을 최초에 확정하기 때문에 만드는 대상이 명확하고 품질을 보증하기 쉽다.
단점
- 개발 도중에 요건 변경 불가 (재작업량, 공수 비용의 증대)
애자일 방식
1-2주 정도의 단위로 요건 정의, 설계, 개발, 테스트를 수행하는 이터레이션을 반복하면서 시스템을 개발
사양이 유동적으로 변경되는 경우
개발하는 애플리케이션을 분할해서 개발할 수 있는 마이크로서비스 아키텍쳐인 경우
장점
- 개발 내용을 작게하여 요건 변경에 유연하게 대응
- 요건을 무한정 변경하는 것이 아닌, 개발 초기에 어느정도 정책을 결정
단점
- 개발 비용이나 일정 추정이 어렵다.
혼합 형태
인프러스트럭쳐 부분은 폭포수 모델, 애플리케이션 부분은 애자일 개발을 적용하는 혼합 형태도 존재.
애플리케이션팀 담당 범위
OS 보다 상위 레이어 담당
애플리케이션 / 바이러스대책, 데이터베이스, 미들웨어 / 운영체제, 컨테이너 오케스트레이터
- 애플리케이션의 설계, 구축, 운용
- 미들웨어의 설계, 구축, 운용
- 데이터베이스의 설계, 구축, 운용
(단, AWS 매니지드 서비스를 사용하는 경우는 인프라스트럭쳐 팀에서 설계, 구축, 운용을 수행) - OS 계층에서의 애플리케이션 작동에 필요한 설정의 설계, 구축
인프라스트럭쳐팀 담당 범위
OS 계층보다 하위 계층 담당
컴퓨팅 자원, 스토리지, 네트워크 / IAM 사용자, 보안(CloudTrail, GuardDuty 등), 기타 AWS 관리 / AWS 계정
- AWS 계정 준비
- AWS 콘솔상의 사용자, 보안 대책의 설계, 구축, 운용
- 컴퓨팅 자원, 스토리지, 네트워크의 설계, 구축, 운용 등
- OS 계층에서의 애플리케이션 작동에 필요한 설정의 설계, 구축
- 바이러스 대책 소프트웨어