< Security, Reliability, and Migration >
Use federated identity management
연합 ID 관리 사용
- 외부 ID 공급자를 사용하여 사용자를 인증 :
- 사용자 인증을 Google, Facebook, Twitter 또는 GitHub와 같은 외부 ID 공급업체에 위임하면 사용자 관리 노력 최소화 가능
- 연합 ID 관리를 사용하면 사용자 인증을 위한 독점 솔루션을 구현, 보호 및 확장할 필요가 없음
Implement health-check endpoints
상태 확인 엔드포인트 구현
- 서비스에 대한 상태 확인 엔드포인트 구현 :
- 항상 사용 가능하고 최적의 성능을 발휘하도록 애플리케이션 및 서비스의 상태를 모니터링하는 것이 중요
- 모니터링 데이터는 시스템에 장애가 발생하는 즉시 운영 팀에 자동으로 경고하는 데 사용
- 그러면 운영 팀이 문제를 즉시 진단하고 해결 가능
- 각 서비스에 대한 상태 확인 엔드포인트를 구현하고 엔드포인트 핸들러는 서비스가 제대로 작동하는 데 필요한
모든 종속성 및 인프라 구성 요소의 상태를 확인 (서비스에 필요한 스토리지, 데이터베이스 및 네트워크 연결의 성능 및 가용성)
- 엔드포인트 핸들러는 성공적인 상태 확인을 위해 HTTP 응답 코드 200을 반환해야 함
- 상태 확인이 실패하면 엔드포인트 핸들러는 오류에 따라 503 또는 보다 구체적인 응답 코드를 반환할 수 있음
- 상태 확인 실패(504 오류 등)를 초래할 만큼 중요한 종속성을 평가함
- 예를 들어, 웹 페이지의 한 섹션에 권장 사항을 표시하는 UI 서비스를 고려해야 함
- UI는 권장 사항 엔진이 다운된 경우 정상적으로 성능이 저하되도록 설계 (권장 사항 섹션 숨기기)
- 이 디자인을 사용하면 추천 엔진이 실패하면 상태 웹 페이지에서 실패를 보고할 수 있지만
여전히 UI 서비스에 대한 성공적인 상태 확인을 반환
- 이 접근 방식을 사용하면 중요하지 않은 종속성을 사용할 수 없는 경우에도 애플리케이션이 계속 트래픽을 수신할 수 있음
- 부하 분산기 또는 Cloud Monitoring 같은 상태 모니터링 에이전트는 주기적으로 상태 확인 엔드포인트에 요청을 보낼 수 있음
- 로드 밸런서는 상태 확인을 사용하여 애플리케이션 인스턴스가 정상이고 트래픽을 수신할 수 있는지 확인
- 정의한 임계값을 초과하여 상태 확인이 실패하면 Cloud Monitoring에서 자동으로 알림을 보냄
Set up logging and monitor your application’s performance
로깅 설정 및 애플리케이션 성능 모니터링
- 로그를 이벤트 스트림으로 처리 :
- 로그는 애플리케이션이 실행되는 동안 계속 발생하는 이벤트의 연속 스트림을 구성
- 애플리케이션에서 로그 파일을 관리하는 대신 stdout과 같은 이벤트 스트림에 작성하고
기본 인프라가 이후 분석 및 저장을 위해 모든 이벤트를 대조
- 이 접근 방식을 사용하면 로그 기반 메트릭을 설정하고 애플리케이션의 다양한 서비스에서 요청을 추적할 수 있음
- Google Cloud의 작업 제품군을 사용하면 애플리케이션을 디버그하고, 오류 보고를 설정하고,
로깅 및 로그 기반 측정항목을 설정하고, 서비스 전반에 걸쳐 요청을 추적하고,
멀티 클라우드 환경에서 실행되는 애플리케이션을 모니터링할 수 있음
Handle transient and long-lasting errors gracefully
일시적이고 오래 지속되는 오류를 정상적으로 처리
- 분산 시스템의 서비스와 리소스에 액세스할 때 애플리케이션은 일시적이고 오래 지속되는 오류에 탄력적이어야 함 :
- 일시적인 네트워크 오류로 인해 리소스를 사용할 수 없는 경우가 있음
이 경우 응용 프로그램은 지수 백오프를 사용하여 재시도 논리를 구현해야 하며 오류가 지속되면 정상적으로 실패해야 함
Cloud Client Libraries는 실패한 요청을 자동으로 재시도
- 오류가 더 오래 지속되는 경우 애플리케이션은 요청을 재시도하는 데 CPU 주기를 낭비해서는 안 되므로
애플리케이션은 회로 차단기를 구현하고 오류를 정상적으로 처리해야 함
- 사용자에게 다시 전파되는 오류는 오류 메시지의 명시적 표시하는 대신 애플리케이션을 정상적으로 성능을 저하시키도록 함
예를 들어 추천 엔진이 다운된 경우 페이지가 표시될 때마다 오류 메시지를 표시하는 대신
페이지에서 제품 추천 영역을 숨기는 것이 좋음
Consider data sovereignty and compliance requirements
데이터 주권 및 규정 준수 요구 사항 고려
- 일부 지역 및 산업 부문에는 데이터 보호 및 소비자 개인 정보 보호에 대한 엄격한 규정 준수 요구 사항이 있음 :
- 예를 들어, 유럽 연합의 데이터 보호 지침은 개인 데이터 처리를 규제
이 지침은 기업이 개인 데이터 보호와 관련하여 충족해야 하는 여러 요구 사항을 지정
- 사용자 및 서비스가 위치할 산업 부문 및 지역에 대한 데이터 보호 요구 사항 검토 필요
Perform high availability testing and develop disaster recovery plans
고가용성 테스트 수행 및 재해 복구 계획 개발
- 고가용성 테스트 수행 및 재해 복구 계획 개발 :
- 기능 및 성능 테스트를 수행하는 것 외에도 고가용성 테스트를 수행
- 이러한 테스트를 통해 강력한 재해 복구 계획을 개발하고 정기적으로 재해 복구 연습을 수행
- 장애 시나리오를 식별하고 재해 복구를 위한 인력, 프로세스 및 도구를 식별하는 재해 복구 계획을 듦
- 실패 시나리오에서 어떻게 대응할지 논의하지만 실제 조치는 수행하지 않는 탁상 테스트를 수행하며
이러한 유형의 테스트는 팀이 예상치 못한 상황에서 무엇을 할 것인지에 대해 토론하도록 권장하고
그런 다음 테스트 환경에서 실패를 시뮬레이션
- 오류 시나리오에서 애플리케이션의 동작을 이해하고 문제를 해결하고 재해 복구 계획을 구체화한 후
프로덕션 환경에서 오류 시나리오를 테스트
프로덕션 환경에서 카나리아 테스트 또는 블루/그린 배포를 수행할 수 있음
- 영향을 최소화하기 위해 유지 관리 기간 또는 사용량이 적은 시간에 이러한 테스트를 예약 - 다음과 같은 실패 시나리오를 고려 :
1) 연결 실패 :
온프레미스 데이터 센터와 GCP 간의 VPN 및 기타 연결이 실패하면 트래픽이 다른 중복 경로를 통해 다시 라우팅되어야 함
2) 온프레미스 데이터 센터 또는 기타 클라우드 제공업체 장애 :
애플리케이션 및 해당 환경은 온프레미스 데이터 센터 중단 또는 다른 클라우드 제공업체와의 정전이 발생한 경우에도
계속 효과적으로 작동해야 함
3) GCP 영역 또는 리전 장애 :
영역 장애 또는 리전 장애의 경우 트래픽이 대체 영역 또는 리전으로 라우팅되는지 확인
영역 오류는 드물고 지역 오류는 매우 드뭄
4) 배포 롤백 :
경우에 따라 소프트웨어 배포를 이전의 안정적인 버전으로 롤백해야 할 수 있으므로 롤백 절차를 테스트
5) 네트워크 또는 애플리케이션 문제로 인한 데이터 손상 :
네트워크 또는 애플리케이션 문제로 인한 데이터 손상의 경우 백업에서 데이터를 복원하는 프로세스를 갖는 것이 중요 - 각 실패 시나리오에서 다음을 확인 :
1) 적절한 사람들에게 적시에 실패에 대해 통보
2) 중복 경로를 사용하여 트래픽이 다시 라우팅
3) 장애 또는 복구 과정에서 데이터가 손상되었는지 확인
4) 모든 서비스가 적시에 복원되었는지 확인
Implement continuous integration and continuous delivery pipelines
지속적 통합 및 지속적 전달 파이프라인 구현
- 자동화를 통해 강력한 DevOps 모델을 구현하여 CI/CD(지속적 통합 및 제공)를 가능하게 함 :
- 자동화는 릴리스 속도와 안정성을 높이는 데 도움이 됨
- 강력한 CI/CD 파이프라인을 통해 여러 변경 사항이 포함된 대규모 릴리스를 만드는 대신
점진적으로 변경 사항을 테스트하고 롤아웃할 수 있음
- 이 접근 방식을 사용하면 회귀 위험을 낮추고, 문제를 빠르게 디버그하고,
필요한 경우 마지막 안정적인 빌드로 롤백할 수 있음
- 지속적 통합 시스템에서 개발자는 Git과 같은 코드 저장소에 코드를 커밋하면
Jenkins와 같은 빌드 시스템은 리포지토리에 대한 커밋을 자동으로 감지하고, 빌드를 트리거하고, 단위 테스트를 실행
- 빌드 시스템은 필요한 모든 런타임 환경에 대한 배포 아티팩트를 생성
- 지속적 배포 시스템에서 Spinnaker와 같은 배포 시스템은 테스트 환경에 대한 빌드 배포를 자동으로 트리거
- 통합, 보안 및 성능 테스트를 자동으로 실행한 다음 성공적인 빌드를 프로덕션 환경에 배포할 수 있음
- 프로덕션 환경에 빌드를 롤아웃할 때 예상치 못한 문제가 많은 사용자에게 영향을 미치지 않도록
카나리아 테스트 또는 블루/그린 배포를 수행하는 것을 고려
- 성능 메트릭 및 경고를 설정하여 프로덕션 환경에서 애플리케이션의 성능을 모니터링할 수 있음
- 지속적인 통합 및 제공 프로세스 전반에 걸쳐 보안을 고려하는 것이 중요 - SecDevOps 접근 방식을 사용하면 다음과 같은 보안 검사를 자동화할 수 있음 :
1) 최신 보안 버전의 타사 소프트웨어 및 종속성을 사용하고 있는지 확인
2) 보안 취약점에 대한 스캔 코드
3) 리소스에 최소 권한 원칙에 따라 권한이 있는지 확인
4) 서비스에서 보낸 로그 및 이벤트가 중앙 위치로 전송되는지 확인
5) 프로덕션에서 오류를 감지하고 마지막 안정적인 빌드로 롤백
Use the strangler pattern to re-architect applications
스트랭글러 패턴을 사용하여 애플리케이션 재설계
- 대규모 애플리케이션을 재설계하고 마이그레이션할 때 Strangler 패턴을 사용하는 것을 고려 :
- 마이그레이션의 초기 단계에서는 레거시 애플리케이션의 더 작은 구성 요소를
새로운 애플리케이션 구성 요소 또는 서비스로 교체할 수 있음
- 원래 애플리케이션의 더 많은 기능을 새로운 서비스로 점진적으로 교체할 수 있음
- Strangler 파사드는 요청을 받아 이전 애플리케이션이나 새로운 서비스로 보낼 수 있음
- 구현이 발전함에 따라 레거시 애플리케이션은 새로운 서비스에 의해 "교살"되어 더 이상 필요하지 않음
- 이 접근 방식은 비즈니스 크리티컬 작업에 영향을 주지 않고 각 서비스 구현에서 학습할 수 있도록 하여 위험을 최소화
- "strangler (교살)"라는 용어는 strangler 덩굴에서 유래
- 덩굴(새로운 서비스)은 무화과 나무의 위쪽 가지에서 씨를 뿌리고 자라기 시작하여
점차적으로 나무를 감싸고 마침내 숙주 역할을 하는 나무(레거시 애플리케이션)를 죽임
(online) 01_Best Practices for Application Development.pdf
1.01MB
