3. Security, Reliablitiy, and Migration
Use federated identity management firebase authentication~ 외부의 identity provider 를 통해 ..
Implement health-check endpoint
Stackdriver monitoring (helth monitoring agent) -> /health upcheck. 어디에 ? storage / database, network connection, 다른 의존들 .. 실패하면 자동으로 알림을 준다.
로깅과 모니터를 어플리케이션의 성능에 대해 두라.
로그를 이벤트 스트림으로 취급하라. 어플리케이션에서는 건들지 말고 stdout 등으로 노출되는 데이터를 다른애가 후처리 해라 . 구글의 스택드라이버를 통해 어플리케이션을 디버그할 수 있고, 에러 모니터링을 설정할 수 있다.
사소한 에러와 오래 지속되는 에러를 우아하게 다뤄라.
trasient erros: 지수적으로 backoff 하여 재시도 해라. 구글클라이언트 클라이언트라이브러리는 재시도에 대해 자동적으로 수행한다.
서비스 가용성 에러: 서킷브레이커를 구현해라. 유저에게 에러를 매번 노출하는 것은 피하는 것노출하는 것도 고려. .
데이터 sovereignnty 와 compliance 요구사항을 고려하라.
어떤 나라에서 데이터보관에 대해 어떻게 규정하고 있는지…
가능한 테스팅과 재앙으로부터 복구계획을 구상하고 어플을 테스트하라.
실패시나리오의 예: 연결 실패 데이터 센터나 클라우드 제공자의 실패 GCP 존이나 리전 실패 배포 롤백 네트워크나 어플리케이션 이슈의 데이터 파괴
계속되는 통합모델 (CI) 을 구현하고 파이프라인으로 배송하라. (CD)
강력한 devops 모델을 구현하라.
코드 저장소 -> 빌드시스템 (배포아티팩트빌드/유닛테스트 실행) -> 배포시스템 (실환경과 테스트환경에 아티팩트를 배포) -> 1. 테스트환경 (통합테스트, 보안, 퍼포먼스 테스트.) / 2. 실환경 (성능 관찰)
큰 수정이 있을때 배포하는 것이 아니라 작은 수정이 이씅ㄹ때마다 배포가 자동화되어 regression 의 리스크를 줄이며 디버그를 재빨리 하며, 이전 테이블의 빌드로 쉽게 롤백할 수 있게한다.
Strangler 패턴을 새로 어플리케이션을 구조화하는데 사용하라.
이패턴: 구버전의 어플리케이션을 조금씩 새로운 서비스의 컴포넌트로 교체해 나가는것.