[우아한 개발] - 06. 시행착오 겪으며 성장하기

가정의 달 이벤트가 쏘아올린 배민 선물하기 대란

사건사고와 해결 과정

이벤트는 성공적이나 예상보다 너무 많은 참여자
문제 1: 구매 시점에 전화번호가 없는 경우가 어떻게 있지?

ㅋㅋㅋㅋㅋ 여기서 사실 웃겨서 아예 ㅋㅋㅋ라고 메모를 해둠. 내가 마주했다면 식은땀이 났을 문제이지만... 😨

구매자를 찾을 방법이 없어 VoC가 인입되면 해결
문제 2: 몰아치는 VoC
알림톡 방을 실수로 나간 사람들 문제의 경우는 실제로 지인에게 선물 받은 것임에도 스팸으로 오인하고 알림톡을 지우는 일이 발생할 수 있음.
상품권을 받지 못한 경우나 이미 등록된 상품권이라고 나오는 경우는 하나하나 직접 어드민에서 조회해서 해결
문제 3: 나 당첨자 맞다
상상하지도 못한 에지 케이스
이벤트 페이지의 작은 유의사항으로 고지는 하였지만 유저가 인지하지 못하고 넘어간 문제

개발자 입장에서만 보면, 사실 기획대로 제작한 것이기 때문에 개발 문제가 아니라서 다행이다?라는 생각도... 물론 문제 터지면 다 같이 달라붙어서 해결해야겠지만...

외부 시스템 장애에 대처하는 우리의 자세

외부 시스템 : 소셜 네트워크 서비스, 지도 서비스, 결제 대행 서비스, 메시지 서비스 등
외부 시스템 연동은 직접 개발하고 운영하는 것에 비해 간단한 연동 작업으로 높은 수준의 서비스를 이용할 수 있고. 직접 구축 및 운영보다 저렴하지만 통제 범위 밖에 있어 불안 요소가 있다.

외부 시스템 의존성 조사

이중화 작업과 불필요한 의존 관계를 끊어내는 작업이 진행
조사를 통해 리스크를 가시화하고, 전사의 연동 내역을 확인해 플랫폼화할 수 있는 요소들을 도출, 연동 방법에 대한 지식 공유

외부 시스템 정보

명칭
제공 업체 정보
연간 장애 발생 횟수
사용 보편성(얼마나 많은 업체가 쓰는지)
갱신 주기(인증서, 데이터, API key 교체 등의 주기)

내부 시스템 정보

담당 팀
유발 장애 등급(내부 장애 등급 분류표를 기준으로, 해당 시스템 장애 발생시 최고 장애 등급)
알람 채널
모니터링 수단
로그 정보
의존성 약화 또는 제거 방안
현재 상태
목표 상태

외부 시스템 연동 시 주의할 점

외부 시스템 장애를 회피할 수 있는 몇 가지 방법

의존성 제거
외부 시스템을 연동할 때 꼭 필요한지 고민
필요한 기능이 서비스 안정성에 우선하는지 비교해보고 판단
이미 연동해서 사용 중인 시스템이라도 주기적으로 적합성을 살펴보는 관심이 필요
서비스가 커지고 구조가 변경되면, 외부 시스템을 통한 이득은 변하지 않지만 리스크는 더 커질 수 있다

벤더 이중화
같은 기능을 제공하는 여러 벤더사가 존재할 때는 벤더 이중화/다중화를 통해 장애를 회피할 수 있다.
결제 대행 서비스, 지도 서비스, 문자 서비스 등
장애 시간을 최소화하도록 벤더 간의 전환을 간단하게 구성하는 것이 중요
어드민에 전환 기능을 구현해 다수의 팀원이 조치하도록 구성하는 것이 일반적
벤더 이중화시 주의점은 벤더 전환은 장애 발생시에만 동작해 전환 대상인 벤더 사의 사용 빈도가 극도로 낮다는 점
해당 벤더의 스펙이 변경되는 등 연동 상태를 늘 체크해 평소 9:1, 8:2의 비율로 상시로 트래픽을 주고받는다.

지도 서비스 하나 구현하는 것도 엄청 힘들었는데... 이중화를 해놓고 전환을 해가며 관리..? 단순히 똑같은걸 두 개 구현하는 식은 아닐 것 같은데 어떤 식으로 관리되는지 궁금하기도 하다...

장애 격리
이중화가 불가능한 외부 시스템은 존재한다.
이 경우, 외부 시스템의 장애가 연동과 관련 없는 부분으로 전파되지 않도록 장애를 격리하는 것이 중요
배달 대행사 시스템에 장애가 발생시 주문 처리가 불가능해지는데, 대상 업소들을 주문 불가 상태로 변경하는 등으로 장애를 격리
지도 서비스에 문제가 생긴다면 지도를 제외한 페이지를 노출시키는 등으로 처리

장애를 격리해서 불필요한 오류를 막겠다는 것은 좋은데, 협업하는 다른 대상에 대한 배려가 부족한 처리는 아닌지 생각이 든다. 외부 시스템 장애로 인한 유저의 불편함을 막겠다는 것은 명목은 좋지만, 자신들의 의도적인 장애 격리를 통해 주문을 받지 못하는 업소 사장님의 입장에서는 이것도 마찬가지로 외부 시스템 장애로 인한 손해가 아닌지...

미작동 감내
위의 방법들로 장애 격리가 불가능한 경우 => AWS, GCP 같은 클라우드 서비스의 장애는 장애 상황의 빠른 인지를 위한 모니터링 강화, 핫라인 운영 등으로 처리

우아한 장애 대응

장애 탐지

시스템 알람을 통한 탐지
모니터링 시스템이 구축되어 슬랙으로 알람을 발송, 온콜 운영
다양한 지표를 참고해 서비스 이상 징후 탐지

시스템 지표: CPU, Memory, latency, 5XX error count 등
비즈니스 지표: 가게 상세 진입률, 주문 추이 등
외부 연동 시스템 지표: 연동 시스템 주문 전달 실패, 프랜차이즈 시스템 오류 등

고객 센터 문의를 통한 탐지
사용 빈도가 극도로 낮은 곳의 오류나 기기, os 버전 등으로 인한 제한적인 오류는 고객 센터를 통해서 인지
과거 모노리틱 구조에서 마이크로서비스 아키텍처로 바뀌어 문제가 있는 도메인을 호출하면 각 담당자에게 온콜이 가도록 분리

장애 공지
장애 발생 시간, 영향 범위, 장애 조치 채널, 내부 정의 장애 등급 등의 정보를 포함
완벽한 정보가 아니더라도 공지를 통해 빠르게 대응을 준비할 수 있음(화재경보기)

장애 전파

장애 복구와 장애 전파를 분리 운영 - 장애 대응 시 장애 복구와 장애 전파를 같은 사람이 하지 않도록
고객이 알고 싶어 하는 내용을 전파(현재 상태, 조치 예정 시간, 후속 대응)

장애 복구

장비 증설
롤백
시스템 변경으로 문제 발생시 즉시 변경 사항을 롤백, 코드 뿐만 아니라 인프라 단의 설정과 같은 다른 변경도 모두 포함
핫픽스
롤백이 불가능하거나 문제의 원인이 명확해 롤백보다 핫픽스가 빠를 경우
장비 교체

장애 후속 조치

장애 원인 분석 - 5 whys 기법
세 가지 포인트를 항상 고려
1. 첫 번째 질문은 항상 장애에 영향을 받은 고객의 관점에서 시작
2. 검증 가능한, 검증된 사실에 기반해 답변
3. 5번의 횟수는 상징적인 숫자로 꼭 질문이 5개일 필요는 없고, 더 적거나 많아도 됨
재발 방지 대책 수립
모니터링 지표 추가, 설정값 변경, 코드 리뷰 절차 개선, 배포 프로세스 수정 등 단기, 중기, 장기적으로 개선할 방안 도출
장애 리뷰
장애 보고서 내용을 바탕으로 장애 리뷰 진행

장애 지표 활용
앞선 데이터를 모아 업타임을 높이거나 전체적인 장애 대응 프로세스를 개선하는 데 참고

장애와 관련된 엑스트라백업 적용기

결제 데이터베이스를 삭제하다

실수로 결제 데이터베이스의 주요 테이블 9개가 삭제되는 사고 발생
바이너리 로그
데이터 수정과 관련된 모든 정보가 담겨 있는 파일로 두 가지의 중요한 목적이 있음

리플리케이션을 구성하는 데 있어서 서브 서버로 바이너리 로그에 포함되어 있는 이벤트 전송
데이터 복구 작업

mysqldump를 사용한 데이터 복구에 시간이 많이 소요되어 새로운 백업 방식을 알아봄

엑스트라백업

mysqldump: 테이블 생성, 데이터 쿼리에 대한 SQL 생성문을 갖는 논리적 백업
엑스트라백업(XtraBackup): 엔진 데이터를 그대로 복사하는 물리적 백업 방식

엑스트라백업의 백업 방식: 전체 백업, 증분 백업, 개별(db, table) 백업, 압축 백업, Encrypted 백업, 스트림을 지원하므로 파이프(|)명령을 사용해 다른 프로그램의 표준 입력으로 리디렉션

mysqldump vs 엑스트라백업

데이터 크기가 크지 않다면 mysqldump를 사용하는 것이 간단하고 복원시 신경 써야 할 포인트가 적다는 장점이 있음.
데이터 크기가 다르다면 많은 시간 소요

장애가 발생하기 이전에 장애를 관리할 수 있는 포인트가 많이 있으므로, 전체 복구 포인트가 존재하는 지 등을 점검하는 것이 중요

사례별로 알아본 안전한 S3 사용 가이드

S3는 사용이 쉬운 만큼 보안 관점에서는 고민해야 할 점이 많다.

S3의 보안 가이드가 어려운 이유

S3는 사고는 탐지하기가 어려운 편
위험을 예방하기 위해 가이드를 만들고 지켜지고 있는지 모니터링이 필요

보안 편향적 사고 주의하기
항상 위험만을 동기로 한 보안 편향적 사고에 빠지지 않도록 해야 함
사용성까지 고려한 쉽고 안전한 방법을 적절히 제시할 수 있도록 해야 함

S3 사용 사례별 보안 가이드

용어의 파도... 🌊

정적 웹 호스팅 버킷, 정적 리소스 파일 서빙용 버킷, 원격 파일 저장용 버킷, 민감한 정보 저장용 버킷

정적 웹 호스팅 버킷
S3 버킷만으로 정적 웹을 호스팅하기에는 몇 가지 문제가 있음

HTTPS가 아닌 HTTP 통신을 하는 점
버킷이 퍼블릭 공개인 점
AWS S3의 엔드포인트 주소를 그대로 사용해야 하는 점

위 문제들을 해결하기 위해 S3 버킷에 연결할 AWS 클라우드 프론트 서비스가 필요
클라우드 프론트는 CDN 역할을 하는 AWS 서비스로, S3 버킷과 클라우드 프론트를 연결한 후, OAI 설정으로 연결한 클라우드 프론트를 통해서만 접근 가능하도록 한다.
클라우드 프론트의 엔드포인트 주소는 가독성 등의 문제로 서비스에 사용하기 적절하지 않은데, 이를 해결하기 위해 라우트53에서 CNAME 레코드를 지정한다. 라우트 53 설정 이후 클라우드 프론트에서 CNAME 설정과 ACM을 통해 발급한 SSL 인증서를 적용한다.

위와 같이 설정 과정을 거치면,

HTTPS가 아닌 HTTP 통신을 하는 점 => 클라우드 프론트에 ACM(인증서)를 적용해 해결
버킷이 퍼블릭 공개인 점 => 클라우드 프론트를 S3에 연결해 S3는 클라우드 프론트 뒤에 숨기고 클라우드 프론트를 통해서만 접근 가능하도록 설정
AWS S3의 엔드포인트 주소를 그대로 사용해야 하는 점 => 클라우드 프론트의 엔드포인트 주소를 라우트 53과 연결해 적절한 서비스 도메인 주소 값을 할당

이후, IP 기반의 접근 통제를 S3 버킷 정책에서 관리하면 S3 버킷 정책 수정권한이 있는 IAM 유저들은 버킷 정책 수정이 가능해짐.
=> AWS WAF 서비스를 이용해 IP 기반의 접근 통제 정책 관리로 해결

정적 리소스 파일 서빙용 버킷
정적 리소스 데이터인 CSS, JS, JPG 등을 서빙하는 웹 리소스 저장소로 사용하는 경우
정적 웹 사이트로 만들지 않고, S3 버킷을 퍼블릭 공개로 설정해 정적 데이터 파일을 서빙
이 때 발생하는 문제는 정적 웹 호스팅 버킷과 동일한데, 같은 방법으로 해결할 수 있음

원격 파일 저장용 버킷
버킷이 불특정 다수에게 열려있고 IP 제어가 불가능해 누구나 S3에 접근할 수 있는 위험성
AWS WAF에서 문자열 검사 및 차단을 통해 비정상 접근을 판단하고 차단하는 방법을 사용할 수 있음

민감한 정보 저장용 버킷
AWS 멀티 계정 환경에서 서비스를 운영할 때 발생할 수 있는 문제(태그, 일관성 없는 이름, 담당자 외에는 알기 어려운 버킷 정보 등)
문제를 해결하기 위해 제한된 계정(보안 계정)으로 민감 버킷을 분리해 관리한다.
이를 통해 정확한 태그 정보, 목적이 분명한 버킷 이름, 제한된 계정에서 관리되어 보안팀의 통제 범위로 문제점을 해소할 수 있다.
민감 버킷을 보안 계정에 분리하더라도 서비스 계정에 있는 서버에서 민감 버킷에 접근해야 하는 경우가 있을 수 있는데, 이 때는 최소 권한을 제공해 제한적으로 접근 가능하도록 설정한다.