この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
안녕하세요 클래스메소드의 이수재 입니다.
온 프레미스로 부터의 마이그레이션이나 신규 구축 등에서 좋은 컨설팅을 위해 Well-Architected와 비기능 요건을 고려하게 됩니다.
물론 처음부터 비기능 요건을 전부 고려하며 요구 사항을 정의해나갈 수는 없지만 이후의 오버헤드를 줄이기 위해 고려할 점이라는 것은 분명합니다.
이 부분을 좀 더 공부하던 중에 다른 사원의 글을 알게 되었고 공부를 겸하여 번역본을 작성하게 되었습니다.
원문은 AWS システム構築 非機能要件ヒアリングシートを公開してみた입니다.
본 내용은 비기능 요건 조사의 첫 시작 정도로 참고해주세요.
가용성
가동률
| 질문 | 질문의 의도 |
|---|---|
| 시스템 간의 우선순위를 설정 하였는가? | 시스템이 제공하는 기능에 따라 우선순위가 다릅니다. 따라서 중요도에 따라 우선순위를 설정합니다. |
| 각 시스템의 운용 시간의 정의되어 있는가? | 온라인 / 배치를 포함하여 시스템이 운용되는 시간을 정의합니다. 유지 보수(maintenance) 작업은 이를 피해서 실시합니다. 24시간 운용의 시스템의 경우 AWS 에서 행하는 유지 보수 시간이 있음을 주의합니다. 그래도 24시간 운용이 필요하다면 금액적인 부담이 늘어날 수 있는 것을 인식합니다. |
| 시스템마다 중요도에 따라 가동률(SLA)을 정의하였는가? | 온 프레미스에서의 가동률과는 별개로 AWS에서 정의해둔 가동률로 시스템의 가동률을 정의합니다. |
| 정기적인 시스템 정지 계획이 정의되어 있는가? | - AWS 에서 행하는 유지 보수가 있으며 상황에 따라서 피할 수 없습니다. - 스케일 업/다운은 원칙적으로 중지됩니다. - 중요한 패치에는 재부팅이 필요한 경우가 있습니다. 이러한 상황에서도 가동률을 유지하기 위해서 월마다 혹은 연마다 정지 계획을 정의해 둡니다. 유지 보수의 예정이 없다면 정지 계획을 고려사항에서 제외할 수 있습니다. |
백업 및 복구
| 질문 | 질문의 의도 |
|---|---|
| RPO(복구 지점 목표)는 정의되어 있는가? | 스냅샷 저장 간격과 상관있습니다. 코스트를 고려하여 RPO를 정의합니다. EC2에 RDBMS를 구축하여 사용하는 경우에는 제품 자체의 기능으로 RPO를 준수합니다. |
| RTO(복구 시간 목표)는 정의되어 있는가? | 인프라를 복구하는 시간 뿐만 아니라 어플리케이션을 복구하는 시간도 고려해야합니다. 예로 들면 스냅샷으로 복구한 후 최신 버젼의 배포가 필요한 경우, 소요 시간이나 자동화 절차의 소요 시간 등도 고려해야 합니다. 장애 원인 파악에 필요한 시간은 제어하기 어려우므로 복구 작업 시간에 대해 확실히 의식해둡니다. |
| RLO(복구 목표 레벨)는 정의되어 있는가? | 어느 정도까지 복구하는 것을 복구라고 할 지 정의합니다. 예로 들면 주요 기능은 몇 시간 안에 복구하지만 추가 기능은 다음날에 복구하는 방식을 생각할 수 있습니다. 현실적인 레벨을 정의해둡시다. |
| 시스템의 중요도에 맞춰 RPO/RTO/RLO가 정의되어 있는가? | RPO/RTO/RLO는 코스트와 직결되기 때문에 시스템의 중요도에 맞추어 정의합니다. |
| 보존 기간 / 세대는 정의 되어 있는가? (단 컴플라이언스를 위한 삭제와 헷갈리지 않도록 주의) |
인프라의 장애로 인한 볼륨의 손실은 금방 알아차리지만 어플리케이션의 버그나 미스에 의한 데이터 부정합 등은 알아차리기 힘들다고 생각됩니다. 문제가 발생한 경우 어느 세대부터 문제가 발생하는지 파악합니다. |
| 데이터를 복구할 때 데이터의 정밀도는 어느 정도인가? 볼륨 / 파일 / 데이터 베이스(스키마 등 전체) |
정밀도에 따라 복구 절차를 검토합니다. 데이터 베이스는 시스템 자체의 기능으로 내보냅니다. 익스포트의 타이밍과 AWS 유지 보수의 타이밍을 조정합니다. |
장애 대책
| 질문 | 질문의 의도 |
|---|---|
| 재해 복구/장애 대책을 강구할 필요가 있는가? | Multi AZ / Multi Region 등 구성을 정하기 위한 인풋 리전 레벨의 다중 구성이라면 운영도 검토할 필요가 있습니다. |
| 재해 복구가 시행되는 [장애]가 정의되어 있는가? | 어떠한 장애로 인해 재해 복구가 시작되는지 정의하여 대책의 레벨을 결정합니다. |
| 재해 복구의 복구 시간 목표는 정의되어 있는가? | 장애의 정의에 따라 목표 시간이 달라집니다. 서울 인근의 대규모 장애인 상황에 짧은 시간 안에 복구 등은 높은 코스트가 요구됩니다. |
| 재해 복구 레벨은 정의되어 있는가? | 재해 복구 시 어떤 서비스를 어느 정도까지 복구할 것인지 정의합니다. 어느 레벨까지 복구하느냐에 따라 발생하는 코스트가 달라집니다. |
컴플라이언스(규칙 및 제도 준수)
| 질문 | 질문의 의도 |
|---|---|
| 업무에서의 조직 요건, 법적 요건, 컴플라이언스 요건은 정의되어 있는가? | 업무 고유의 보안 요건, 그룹사에서 준수해야 할 요건 등이 있으므로 사전에 체크해둡니다. |
| 정기적인 보안 검사를 하고 있는가? 해당 검사에는 어떠한 내용이 필요한가? |
Security Hub, Conformance Packs, Trusted Advisor 등을 통해 정기적으로 체크합니다. 필요에 따라 서드 파티 툴의 사용을 검토합니다. |
| 외부 벤더에 의한 정기적인 취약성 검사가 필요한가? | 업계 표준에 따라서 외부 벤더의 검사가 필요한 경우가 있습니다. |
| AWS 콘솔에 로그인 할 때 MFA 디바이스를 사용할 수 있는가? | 다중 인증을 권장하고 있습니다. 보안을 위해 MFA 인증을 의무화하는 것이 좋습니다. |
| AWS 콘솔에 로그인 할 때 비밀번호 정책이 필요한가? | IAM 비밀번호 정책을 강제합니다. |
| 허가되지 않은 AWS 자원의 조작이 발생하였을 때 통지 및 알람이 설정되어 있는가? | Cloud Trail 로그를 감시합니다. 예) 각 리소스의 설정 변경, 인증 에러 등 |
| 보관하는 데이터의 기밀 분류가 있는가? 있는 경우 어떤 데이터를 어떻게 보호하는지 정의되어 있는가? |
암호화나 IAM/S3 정책으로 정의할 수 있습니다. 높은 수준의 기밀을 요구하는 데이터는 버킷을 나누는 등의 대책을 고려할 수 있습니다. |
| 전송하는 데이터의 기밀 분류가 있는가? 있는 경우 어떤 데이터를 어떻게 보호하는지 정의되어 있는가? |
TLS 통신을 이용하는 범위는 어디까지인지, VPC 외에는 필수로 하는지, VPC 안에서는 임의로 하는 등 |
| 암호화 키의 보관에 대한 요건이 있는가? | 유저가 작성한 키를 사용할 것인지, AWS의 기본 암호화로 충분한지 등. PCI CSS는 KMI 필수 |
| 업계나 조직에서 일어날 수 있는 보안 사고가 있는가? 과거에 발생한 보안 사고가 있는가? |
위협 모델을 정의한다면 인풋과 재발 방지책을 정의합니다. |
패치 관리
| 질문 | 질문의 의도 |
|---|---|
| 조직의 보안 정책에서 패치 관리에 대한 규정이 있는가? | 설계에서의 인풋(전제조건)으로 활용하기 위해 |
| 기존 패치 시스템은 있는가? | 있는 경우 워크로드를 관리 대상으로 할 것인지 정의합니다. |
| 기존 패치 시스템에서 워크로드를 관리하는가? | 기존 패치 시스템을 그대로 사용할 경우 사용 전제 하에 설계, 사용하지 않는 경우 Patch Manager 사용을 검토합니다. |
| 패치 관리 대상인 플랫폼은 무엇인가? | Windows나 주요 Linux는 괜찮아도 마이너한 OS의 경우 검토가 필요합니다. |
| 중요한 취약성을 긴급 패치 적용 대상으로 하는 운용을 하는가? | 실시하는 경우 검사와 알림의 구조나 작업을 검토합니다. |
| 긴급 패치라고 판단하는 조건이 정의되어 있는가? | 기본적으로 OS 벤더가 규정하고 있는 [긴급]을 이용합니다. MW도 똑같은 방식으로 적용할 수 있습니다. CVSS score를 판단 기준으로 적용해도 됩니다. |
| 패치 적용 전 테스트를 실시하고 있는가? | 실시하고 있지 않은 경우 검증 환경을 준비할 수 있는지 확인해보고 가능하다면 검증 환경을 마련합니다. 라이센스 등의 문제로 검증 환경을 준비할 수 없는 경우도 있습니다. |
| 패치 적용을 위한 유지 보수 시간을 확보할 수 있는가? | 패치를 확실하고 안전하게 적용하려면 유지 보수 시간을 마련합니다. |
방어 대책
| 질문 | 질문의 의도 |
|---|---|
| 안티 바이러스 및 안티 멀웨어 등의 도입이 필요한가? 기존에 사용하던 제품을 계속 사용할 것 인가? |
서비스에 대응할 수 있는 제품을 선택합니다. 예) 컨테이너 라면 Aqua 등 |
| IDS / IPS 의 도입이 필요한가? | 인터넷과 접하는 개소에 AWS WAF를 도입합니다. VPC 내부에서 IDS/IPS가 필요한 경우에는 EC2 상에서 가동할 수 있는 제품을 선택합니다. |
| 기존에 IDS / IPS 가 도입되어 있다면 규칙을 공유할 수 있는가? | 동등하거나 유사 기능을 구축할 때의 재료로 사용합니다. |
| 접속원 제한 요건이 있는가? - 기존 IP 주소의 허용 및 거부 - 국가에 의한 접속 허용 및 거부 |
동등하거나 유사 기능을 구축할 때의 재료로 사용합니다. |
운용 계정 관리
| 질문 | 질문의 의도 |
|---|---|
| 어떤 조직에서 서비스 운용을 실시하고 있는가? | 조직과 작업 분담을 명확히 합니다. 또한 작업을 실시하는데 필요한 권한을 역할에 알맞게 부여합니다. |
| 각 역할을 부여할 멤버는 누구인가? | 역할을 부여할 멤버를 결정하기 위해서 입니다. |
| 비밀번호 정책은 정의되어 있는가? | ISMS 등으로 정의되어 있는 경우에는 이에 따릅니다. |
| 직책에 따른 권한 변경은 정의되어 있는가? | 직무가 아닌 직책에 따른 권한이 부여되어 있는가를 확인합니다. 일반적으로 접속하지 않는 유저에게 강한 권한이 부여되어 있지 않는가를 확인합니다. |
운용
작업(JOB) 관리
| 질문 | 질문의 의도 |
|---|---|
| 작업 관리 툴의 도입이 필요한가? 작업 관리 툴을 통해 요구하는 기능이 있는가? |
작업 모음, 업무 캘린더 등 작업 관리 툴 특유의 기능이 필요하다면 유상 제품을 선택합니다. cron 이라면 CloudWatch Evnets(EventBridge), 상태에 따른 작업 관리라면 StepFunction 을 활용할 수 있습니다. |
| 작업 실행이 실패한 경우 통지는 필요한가? 또한 어디로 통지하면 되는가? |
재시도해도 실패한 경우 수동으로 작업하거나 원인 조사가 필요하기 때문에 통지를 설정하는 것이 좋습니다. 누구에게 통지할 것인지는 조직에 따라 다릅니다. |
로그 관리
| 질문 | 질문의 의도 |
|---|---|
| 로그 관리는 필요한가? 관리 대상은 정의되어 있는가? OS / 미들웨어 / 어플리케이션 / 네트워크 / AWS / 보안 등 |
무엇을 어디에 저장할 것인지를 정의합니다. AWS에서는 어떻게 로그를 취득하고 활용할 것 인가를 정의할 필요가 있습니다. |
| 각각의 로그의 이용 목적은 정의되어 있는가? | 감사 목적, 장애 조사, 액세스 분석 등 로그 별 목적을 알고 최적의 저장 장소를 정의합니다. |
| 보존 기간은 정의되어 있는가? | 보존 기간은 AWS 요금에 영향이 있습니다. |
| 로그 분석은 필요한가? 어떠한 로그를 어느 정도로 분석할 것인지 정의되어 있는가? |
Athena、CloudWatch Logs Insight、QuickSight、Amazon ES、서드 파티 툴 등의 선택지가 있습니다. 보안 로그 등이라면 SIEM 등을 활용할 수 있습니다. |
감시
| 질문 | 질문의 의도 |
|---|---|
| 리소스 감시를 하고 있는가? CPU 사용률/메모리 사용률/디스크 사용률/액세스 수/전송량 등 AWS 자원에 대한 감시가 필요한가? |
CloudWatch 와 Agent 로 구현하거나 서드 파티 툴 등의 선택지가 있습니다. |
| OS 상의 서비스 혹은 프로세스 감시를 할 것인가? 이 경우 지표는 있는가? (AWS 관리형 서비스나 서버리스 서비스의 경우 제외) |
CloudWatch 와 Agent 로 구현하거나 서드 파티 툴 등의 선택지가 있습니다. |
| AWS 리소스의 헬스체크를 할 것인가? | ping 감시로는 효과가 미비합니다. PHD와 CloudWatch에서 헬스체크를 합니다. |
| 엔드포인트 감시를 할 것인가? | 외부 감시는 서비스의 기동 상황을 감시하기 위해 필요합니다. |
| 어플리케이션 감시를 할 것인가? | 외부 감시로 한번에 체크할 수 있으면 좋습니다. 어플리케이션은 개별적으로 감시해야하는 경우가 많으므로 제대로 체크해야합니다. |
| 비즈니스 KPI(Key Performance Indicators)를 측정하고 있는가? | 비즈니스 KPI에서 필요한 지표에 대해 IT로서 어떠한 매트릭스를 제공할 수 있는지 체크합니다. |
| 통지하는 매트릭스, 임계치는 정의되어 있는가? | 혼란을 야기하지 않도록 통지는 최소한으로 합니다. 통지 대상은 통상과 긴급(warning / critical)의 2가지로 준비합니다. 주간 혹은 자동으로 대처되는 것은 통상으로 설정합니다. 야간이나 서비스 다운 등 사람의 즉시 대처가 필요한 것을 긴급으로 설정합니다. |
| 어떤 식으로 통지할 것인지 정의되어 있는가? 메일 / 채팅 툴 / 전화 / 서비스 티켓 툴 / 종합 관리 툴 등 |
AWS에서 수신처로 통지하는 수단은 아키텍쳐 설계와 관련있습니다. 메일이나 chatwork/slack은 구현하기 쉽고 전화나 서비스 티켓 툴과의 연계는 서비스 구축이 필요합니다. |
| 통지해야하는 이벤트(장애)와 수신처는 정의되어 있는가? | 이벤트가 통지해야하는 팀에 제대로 도착해야합니다. |
| 경보 통지의 중요도는 정의되어 있는가? | 긴급 경보와 통상 경보를 분리하여 대처에 대한 작업의 효율을 높입니다. |
| 경보 통지의 중요도에 따라 수신처가 정의되어 있는가? | 통상은 메일 긴급은 전화 등으로 구분할 수 있습니다. |
어플리케이션
| 질문 | 질문의 의도 |
|---|---|
| 어플리케이션의 빌드 및 배포 방법을 클라우드 최적화 할 예정이 있는가? 배포의 롤백을 쉽게 할 수 있는가? |
배포 방법 / 문제 발생 시의 롤백 방법 / 테스트 방법 등의 정의를 하는 것이 좋습니다. |
| 어플리케이션의 코드 버젼 관리 툴을 도입할 계획이 있는가? 어플리케이션의 테스트 자동화 툴을 도입할 계획이 있는가? |
AWS 서비스와의 통합을 고려해야 합니다. |
운용 유지 관리
| 질문 | 질문의 의도 |
|---|---|
| 인프라 운용 및 운용 관리를 하는 조직이 정의되어 있는가? (CCoE / SRE팀 / 인프라 담당 팀 등) |
설계나 설비의 스코프를 정하는 설정할 때 [현실적인 범위]를 검토하기 위해 필요합니다. |
| (상기 조직의 멤버에 관해)AWS 서비스에 대해 어느 정도의 지식을 가지고 있는가? | 필요하다면 AWS 에서 제공하는 트레이닝의 수강을 제안합니다. |
| 과제 해결이나 장애 대응, 정상 작업 등 작업을 관리하는 방식이나 툴은 정의되어 있는가? | 있는 경우에는 툴 사용을 전제로 프로세스를 설계합니다. 없다면 다른 작업 관리 서비스의 이용을 추천합니다. 성과를 가시화 하는 것은 운영의 가치를 평가하기 위해 필수입니다. |
| 정기적인 운영 리뷰를 실시하는 회의가 있는가? | 없는 경우에는 정기적인 회의를 권장하고 효율적으로 운영될 수 있도록 운영 방법을 제안합니다. |
| 업무상 유익한 지식 / 절차 / 장애 보고를 공유하는 수단이 있는가? | 있는 경우 툴 사용을 전제로 프로세스를 설계합니다. 없는 경우에는 Github/Confulence 등의 서비스를 채용합니다. 장애나 사고에 관해서는 리포트의 형식이나 리뷰 등을 정의해 지속적인 개선을 가능하게 합니다. |
| 시스템 운용 보수에 필요한 작업은 절차서로 문서화 되어 있는가? | AWS에서 새로 발행하는 운용 절차를 문서화 합니다. |
| 절차서를 자동화하는 툴을 이용하고 있는가? | 툴은 AWS에서도 계속 이용 가능한지 RDS나 Lambda 같은 서비스도 대응할 수 있는지 확인합니다. |
| 운용 보수 작업에 있어 프로세스 흐름은 정의되어 있는가? | 프로세스 흐름을 클라우드 운용에서도 적용할 수 있는지 적용을 위해 수정할 필요가 있는지 확인할 필요가 있습니다. |
| 시스템 이벤트의 대응은 자동화 되어 있는가? | 이벤트의 복구 액션을 자동화 할 것인지 확인할 필요가 있습니다. |
용량(capacity)
성능목표치
| 질문 | 질문의 의도 |
|---|---|
| 온라인 처리, 배치 처리에 요구하는 성능 목표치는 정의되어 있는가? | 아키텍쳐나 인스턴스 타입, 볼륨 타입 선택에 영향이 있는 부분이므로 파악할 필요가 있습니다. |
| 보관하는 데이터 양, 데이터베이스의 데이터 양이 데이터 종류에 따라 정의되어 있는가? | 아키텍쳐나 인스턴스 타입, 볼륨 타입 선택에 영향이 있는 부분이므로 파악할 필요가 있습니다. |
| 필요한 IOPS가 어플리케이션 / 데이터베이스 별로 정의되어 있는가? | 아키텍쳐나 인스턴스 타입, 볼륨 타입 선택에 영향이 있는 부분이므로 파악할 필요가 있습니다. |
| 외부 시스템과의 연계가 있는 경우 필요한 네트워크 대역은 정의되어 있는가? | 평소에 일정한 대역이 필요한 경우에는 대역폭을 보증하는 Direct Connect 도입을 검토합니다. |
확장성
| 질문 | 질문의 의도 |
|---|---|
| 스케일 업/다운을 하는 지표가 있는가? | 리사이즈 방식에 영향이 있습니다. 기본적으로 리사이즈에는 서비스 정지가 동반됩니다. |
| 스케일 업/다운을 할 수 있는 어플리케이션이 준비되어 있는가? | AutoScailing 에 대응할 수 있는지는 아키텍쳐에 영향이 있습니다. 또한 관리형 서비스에 대응할 수 있는 어플리케이션이 클라우드 화에 알맞습니다. |
| 어플리케이션 별로 부하 특성이 정의되어 있는가? - 계절에 따라 부하가 변화한다 -홍보를 통해 부하가 급상승하기 쉽다 - 정기적으로 급상승하는 날이 있다 |
아키텍쳐나 인스턴스 타입, 볼륨 타입 선택에 영향이 있는 부분이므로 파악할 필요가 있습니다. |
| 성능 테스트를 하고 있는가? | 테스트 방식에 영향이 있습니다. |
환경
라이센스 관리
| 질문 | 질문의 의도 |
|---|---|
| AWS로 반입하는 라이센스가 정의되어 있는가? 또한 AWS에서 가동할 수 있는 라이센스인지 라이센스 판매처에 서포트 유무를 확인하였는가? |
관리 대상을 특정합니다. [AWS로의 반입이 가능한가]를 확인할 필요가 있으며 클라우드 상에서 라이센스 체계가 바뀌는 것도 있습니다. |
| 이동 작업 중 병행 기동이 가능한지 판매처에 확인하였는가? | 이동 작업 중 병행 기동에 시간 한정을 두는 라이센스도 있습니다. |
계정 관리
| 질문 | 질문의 의도 |
|---|---|
| 청구 분리를 위해 여러개의 AWS 계정을 생성하는가? | AWS 이용 요금을 상세한 내역까지 정확하게 파악하기 위해서는 청구 단위 별로 AWS 계정을 생성할 수 있습니다 |
| 시스템 환경(개발/스테이징/프로덕션 등)별로 여러개의 AWS 계정을 생성하는가? | 보안측면에서는 통제를 강화하기 위해 환경별로 AWS 계정을 생성할 수 있습니다. |
| 로그 수집 계정이나 보안 관리, 네트워크 관리만 하는 AWS 계정이 있는가? | 여러개의 AWS 계정을 사용하는 경우 특정 목적을 위한 계정을 생성하여 집중 관리할 수 있습니다. |
네트워크 토폴로지(network topology)
| 질문 | 질문의 의도 |
|---|---|
| Direct Connect 를 사용하여 AWS와 접속하는 AWS 계정이 있는가? | 회선 다중화, IP 주소 관리, 여러 계정의 접속 등 아키텍쳐에 영향이 있습니다. |
| 온프레미스 거점 <-> Direct Connect <-> AWS 의 접속도가 정의되어 있는가? | Direct Connect, Transit Gateway 등 최적의 아키텍쳐를 고려해야합니다. |
| VPN 을 이용하여 AWS와 접속하는 AWS 계정이 있는가? | 회선 다중화, IP 주소 관리, 여러 계정의 접속 등 아키텍쳐에 영향이 있습니다. |
| 온프레미스 거점 <-> VPN <-> AWS 의 접속도가 정의되어 있는가? | Transit Gateway 등 최적의 아키텍쳐를 고려해야합니다. |
마치며
많은 실전 경험을 가지신 아키텍터 분들이 보시기엔 부족한 항목이나 의도가 있을지도 모릅니다.
하지만 저와 같이 아직 경험이 부족한 아키텍터 분들에게는 검토를 시작하는데 조금이나마 도움이 될 수 있을 것이라 생각합니다.
혹은 온프레미스에서 클라우드로의 이전을 고려하시는 분들에게 조금이나마 명확한 청사진을 떠올리는데 도움이 되었으면 합니다.
실제 컨설팅에서는 한번의 회의로 끝내는 것이 아닌 지속적으로 보완해나가야 한다는 점도 의식하여 아키텍쳐를 구성하도록 합니다.
긴 글 읽어주셔서 감사합니다.
오타 및 내용 피드백은 언제나 환영합니다. must01940 지메일 로 보내주시면 감사합니다.
14
