인프라 체크 리스트, 서비스 개시 체크리스트
- Taejoon Moon
프로덕션 수준의 인프라 체크 리스트
Terraform Up & Running 6장 프로덕션 수준의 테리폼 코드 - 프로덕션 수준 인프라 체크리스트 표6-2
작업 | 설명 | 사용가능한 도구 |
|---|---|---|
설치 |
|
|
설정 |
|
|
프로비전 |
|
|
배포 |
|
|
고가용성 |
|
|
확장성 |
|
|
성능 |
|
|
네트워킹 |
|
|
보안 |
|
|
성능지표 |
|
|
로그 |
|
|
백업 및 복구 |
|
|
비용 최적화 |
|
|
문서화 |
|
|
테스트 |
|
|
클라우드의 경우 각 클라우드 벤더별로 well architeded 문서
https://docs.aws.amazon.com/ko_kr/wellarchitected/latest/framework/welcome.html
운영 우수성, 보안, 안정성, 성능 효율성, 비용 최적화
Google Cloud Architecture Framework | Cloud Architecture Center
시스템 설계, 운영 우수성, 보안, 신뢰성, 비용 최적화, 성능 최적화
구글 SRE 등의 서비스 개시 체크리스트
“클라우드 시스템을 관리하는 기술 - 클라우드 관리자가 알아야 할 웹 규모 분산 시스템 설계와 운영” 책에도 아래와 비슷한 내용의 서비스 개시 체크리스트가 있음.
The PRACTICE OF CLOUD SYSTEM ADMINISTRATION - Chapter 7.2.1 Service Launches - Sample Launch Readiness Review
Survey (http://www.amazon.com/The-Practice-Cloud-System-Administration/dp/032194318X)
https://www.informit.com/articles/article.aspx?p=2249032&seqNum=2
“클라우드 시스템을 관리하는 기술” 예제를 참고로 해서 만든 자료. 상황에 따라 편집해서 사용하면 됨.
카테고리 | 서비 카테고리 | 설명 | 필수여부 | 예제 |
서비스 개시 정보 | 서비스 이름 |
|
|
|
| 서비스 개시 날짜 |
|
|
|
| 서비스 폐기 날짜 | 일시적으로 필요한 서비스가 있을 수 있으므로 서비스 폐기 날짜도 있어야 함 |
|
|
| 서비스 개발팀 |
|
|
|
| 서비스 운영팀 |
|
|
|
예산 | 예산 승인 여부 | 사전에 예산을 받았는지 확인 비상상황의 경우 예외적인 정책이 있을 수 있으며 이에 대한 정책이 없으면 만들어야 함 |
|
|
Architecture | 서비스 설계 승인 여부 | production 넣기 전에 기술/비용 관점에서 서비스 설계에 대한 검토가 필요함 |
|
|
| 시스템 구조/서비스 설계 |
|
|
|
| 장애 조치 방법 |
|
|
|
| 시스템 규모 변화에 대한 대응 방법 |
|
|
|
수용량 | 예상하는 초기 사용자 수와 QPS | 초기 예상치 |
|
|
| 해당 수치의 근거(부하 검사 및 보고서 링크 제시) |
|
|
|
| 초기 수치가 기대치의 두배, 다섯배 이상일 경우 어떤 일이 발생하는가? |
|
|
|
| 예상하는 외부(인터넷) 대역폭 사용량은? |
|
|
|
| 1,3,12개월 이후의 네트워크 및 저장소 요구사항 | 향후 예상치 |
|
|
의존성 | 이 서비스가 의존하는 시스템들은? |
|
|
|
개발/운영 프로세스 | CI & CD | 개발단계에서 진행하는 부분이므로 불필요한 항목일 수 있음 |
|
|
| Staging 환경에서 테스팅 여부 | production 넣기 전에 테스팅을 진행했는지 확인을 해야 함 |
|
|
| 자산DB/CMDB 등록 | 자동으로 처리되는 경우 불필요할 수 있음 |
|
|
가이드 준수 여부 확인 | IAM |
|
|
|
| AMI |
|
|
|
| AWS Resource Tag |
|
|
|
| AWS VPC Policy |
|
|
|
| 리소스 네이밍규칙 |
|
|
|
| Network ACL |
|
|
|
| Security Group |
|
|
|
운영정책 | HOST OS에 대한 설정 관리 여부 | 수동으로 설정 관리가 되면 안됨 |
|
|
| 게이트웨이 서버에서 접속 여부 |
|
|
|
| 시스템 로깅 설정 |
|
|
|
재난대비 | 개시 첫날의 사용량이 예상치의 10배인 상황에 대한 계획은 무엇인가? | 백업 방법 및 복구 방법 |
|
|
| 백업이 작동하는가? 그리고 복구가 제대로 되는지 점검했는가? |
|
|
|
모니터링 | 시스템/서비스 모니터링 대상, 전략 |
|
|
|
| 모니터링 담당 팀 |
|
|
|
문서화 | 운영 과제, 각종 경보에 대한 각본 여부 |
|
|
|
승인 | 마케팅 부서가 모든 로고와 문구, URL 서식을 승인했는가? |
|
|
|
| 보안팀이 서비스를 감사, 승인했는가? |
|
|
|
| 개인정보 보호에 관한 감사가 완료되었고 모든 문제가 조정되었는가? |
|
|
|
구글 SRE 서비스 런치 체크리스트
https://sre.google/sre-book/launch-checklist/
Architecture
Architecture sketch, types of servers, types of requests from clients
Programmatic client requests
Machines and datacenters
Machines and bandwidth, datacenters, N+2 redundancy, network QoS
New domain names, DNS load balancing
Volume estimates, capacity, and performance
HTTP traffic and bandwidth estimates, launch “spike,” traffic mix, 6 months out
Load test, end-to-end test, capacity per datacenter at max latency
Impact on other services we care most about
Storage capacity
System reliability and failover
What happens when:
Machine dies, rack fails, or cluster goes offline
Network fails between two datacenters
For each type of server that talks to other servers (its backends):
How to detect when backends die, and what to do when they die
How to terminate or restart without affecting clients or users
Load balancing, rate-limiting, timeout, retry and error handling behavior
Data backup/restore, disaster recovery
Monitoring and server management
Monitoring internal state, monitoring end-to-end behavior, managing alerts
Monitoring the monitoring
Financially important alerts and logs
Tips for running servers within cluster environment
Don’t crash mail servers by sending yourself email alerts in your own server code
Security
Security design review, security code audit, spam risk, authentication, SSL
Prelaunch visibility/access control, various types of blacklists
Automation and manual tasks
Methods and change control to update servers, data, and configs
Release process, repeatable builds, canaries under live traffic, staged rollouts
Growth issues
Spare capacity, 10x growth, growth alerts
Scalability bottlenecks, linear scaling, scaling with hardware, changes needed
Caching, data sharding/resharding
External dependencies
Third-party systems, monitoring, networking, traffic volume, launch spikes
Graceful degradation, how to avoid accidentally overrunning third-party services
Playing nice with syndicated partners, mail systems, services within Google
Schedule and rollout planning
Hard deadlines, external events, Mondays or Fridays
Standard operating procedures for this service, for other services