오피사이트 장애 발생 시 대처 가이드

1. 서비스가멈추는순간은항상갑작스럽다. 접속이안되고, 결제창이멈추고, 고객문의가폭주한다. 장애는규모 와업종을가리지않는다. 차이는준비정도와대응속도다. 여러차례의새벽장애전개를겪으며배운것은, 기 술만으로는위기를지나갈수없고, 조직과절차, 평소의습관이결국다운타임을단축한다는사실이다. 오피사 이트운영자와실무자에게필요한실전형대처가이드를, 준비단계부터포스트모템까지한호흡으로정리한다. 여기서말하는원칙은특정스택에한정되지않는다. 그러나예시를들때는웹서버, 데이터베이스, 캐시, WAS 같은일반적인구성으로설명한다. 운영자커뮤니티나오피가이드레벨의내부문서에서이미쓰이는표현도그 대로차용한다. 무엇이 ‘장애’인가, 어디서부터기록할것인가 장애판단기준이모호하면의사결정이늦어진다. 단순히에러율이올랐다는이유만으로전사알림을울릴필요 는없지만, 지표가회복불가능한궤적을보이는데도관성적으로지켜보는건더위험하다. 운영환경에서쓰기 좋은기준은다음과같다. SLO 기반의주요지표가연속된두개의측정구간에서임계치를초과한경우, 또는사 업적으로치명적인트랜잭션(로그인, 결제, 예약, 콘텐츠열람등)이 3분이상실패율 5퍼센트이상을유지하는 경우, 장애로선언한다. 선언시점부터모든조치와판단을기록해야한다. 누가어떤명령을실행했고, 어떤설 정을바꿨는지, 각타임스탬프를남기지않으면포스트모템은형식적회고로끝난다. 장애를정의할때기술지표만보지말고고객관점지표를함께둬야한다. 평균응답시간 800ms가내부적으로 는문제가없어보여도, 특정단말의이미지로딩실패가고객의체감경험을무너뜨릴수있다. 실제로모바일 3G 구간에서만발생한이미지 CDN 서빙이슈를, 서버 CPU가여유롭다는이유로한시간넘게놓친사례가있 다. 오피사이트같은트래픽가변성이큰환경에서는체감형지표가더빨리신호를준다. 알림, 관측, 책임자지정, 이세가지가 1분을살린다 관측과알림의설계는도구선택보다임계치와라우팅설계가더중요하다. 알림은적어야한다. 신뢰도가떨어 지는알림은결국음소거된다. 서비스레벨에서최소 4가지라인을제안한다. 가용성, 에러율, 응답시간, 핵심트 랜잭션성공률. 여기에시스템레벨에서는 CPU 스틸타임, 디스크 IOPS 대기, 메모리 OOM, 네트워크패킷드롭 같은신호를더한다. 로그는정제된형태로수집해야한다. 원시로그만쌓아두면장애시점에필요한검색이늦 어진다. 가장많이쓰는쿼리패턴을미리저장해둔다. 예를들어 “최근 10분 5xx 비율상위엔드포인트”, “특정 사용자그룹타임아웃발생건수” 같은쿼리다. 장애대응시역할은명확할수록좋다. Incident Commander 한명, 커뮤니케이션담당한명, 드라이버(실행담당) 한명. 작은조직에서는한사람이두역할을겸할수있지만, 말하는사람과키보드를잡는사람을분리하면판 단속도가오른다. 슬랙이나메신저채널은사전에정하고, 전용브리지룸을열어대화를한곳에모은다. 장애중 에는 DM으로빠지는대화가가장위험하다. 그정보가기록에남지않고, 회복이후에도같은실수가반복된다. 장애를줄이는설계의습관

2. 오피사이트는트래픽급증과급감을반복한다. 설계는대체로스파이크와홀리데이시즌을기준으로한다. 평균 트래픽에맞추지말고, 상위 5퍼센트구간을견딜수있도록버퍼를둬야한다. 단, 과도한과금과연결되면현실 적으로불가능해진다. 실제로는오토스케일링의상한과하한을계절별프로파일로분리해운영한다. 평상시하 한을낮추되, 상한은예측에따라번들로잡고, 외부캐시와 CDN으로정적인리소스와일부 API 응답을프런트 에서흡수한다. 로그인과결제같은상태성트랜잭션은절대캐시에의존하지말고, 리드트래픽중심의엔드포 인트에서캐시히트율을 70에서 85퍼센트까지올리는것이현실적인목표다. 단일장애지점을줄이는방법은고전적이지만여전히가장효과적이다. DNS는이중화하고, 헬스체크를적극적 으로사용하며, L4/L7 로드밸런서를이중화한다. 데이터베이스는리더 - 리플리카구조를기본으로하고, 장애 전환시트랜잭션유실가능성과읽기정합성저하를명확히이해해야한다. 특히쓰기집중구간에서멱등성을 보장하지않은 API는재시도에취약하다. 몇해전카드결제 API가 30초지연되면서클라이언트가 3회재시도 를날려중복결제가발생한사례가있었다. 서버는에러를반환하지않았고, 클라이언트는타임아웃을오판했 다. 이런경우서버와클라이언트모두요청식별자와멱등키를강제해야한다. 첫 10분, 무엇을할것인가 장애선언후첫 10분은상황을좁히는시간이다. 범위를넓히면손이느려진다. 트래픽, 에러율, 핵심트랜잭션 을동시에본다. 서버지표만보면네트워크를놓치고, 애플리케이션로그만보면외부의존성을놓친다. 중복원 인탐색을피하려면관찰순서를정해둔다. 사용자체감부터, 외부의존성, 엣지, 애플리케이션, 데이터계층순 이다. 고객센터에서들어오는케이스가특정통신사나특정지역에편중되어있으면, 내부보다는 ISP 라우팅이 나 CDN POP 이슈일확률이높다. 반대로모든구간에서 5xx가튄다면, 애플리케이션배포나설정변경을의심한 다. 장애초기에흔한실수는조용한롤백이다. 기록과공지없이배포를되돌리면, 겉으로는빨리회복되는것처럼 보여도원인분석이어려워진다. 롤백은대체로정답이지만, 변경범위를정확히아는경우에만선택해야한다. 애매하다면트래픽을서서히줄이는방식으로카나리를되감고, 에러율이반응하는지관찰한다. 과거에무의식 적으로전체롤백을했다가, 데이터마이그레이션스크립트가이미돌아간상태여서더큰불일치가생긴경험 이있다. 데이터변경을동반하는배포에서는항상롤백시나리오를별도로적어둬야한다. 외부의존성, 계약서보다빠른우회로 오피사이트는대개여러외부서비스를묶어고객경험을만든다. 결제, 본인인증, SMS, 메일, 맵, 푸시, 광고 SDK, 분석도구등, 그중하나만어긋나도코어플로우가끊긴다. 계약서의 SLA는장애순간에아무런위로가되 지않는다. 대비책은두가지다. 기능적폴백과공급자이중화. 기능적폴백은예를들어본인인증이지연될때, 낮은신뢰의대체루트를임시로열고후속검증을추가하는방식이다. 공급자이중화는결제나메시징처럼대 체가능한모듈을두개이상붙이고, 라우팅을상황에따라바꾸는방식이다. 단, 이중화자체가장애의원인이 될수있다. 상태머신의복잡도가올라가고, 실패모드가급증한다. 따라서트래픽의 5에서 10퍼센트만평소에 세컨더리로흘려서냉간대기대신온기대기를유지하는편이낫다. 과거에 SMS 인증이특정시간대에지연되던공급자가, 공휴일에는대기열을대폭줄이는정책으로바뀌면서예 측이무너진적이있다. 그이후로는두공급자를동적으로전환하는로직을넣고, 일단위로성공률과평균전송 시간을비교해라우팅가중치를조정했다. 계약서검토보다이로그가실무에는더도움이된다. 데이터베이스, 캐시, 큐, 이 3종의전형적장애패턴 데이터베이스장애는대체로세가지로요약된다. 잠금경합, 커넥션고갈, 스토리지병목. 잠금은대량업데이트 나스키마변경중에자주발생한다. 초단기해결책은문제쿼리를찾아 KILL하고, 적용중인 DDL이라면롤백을 택하되서비스영향시간을계산한다. 커넥션고갈은앱단의커넥션풀설정과밀접하다. 최대커넥션을늘리는 것은지연된파국일뿐, 지연이쌓여타임아웃이도미노로발생한다. 안전한접근은, 읽기전용트래픽을리플리 카로넘기고, N+1 쿼리를임시캐시에태워급한불을끄는것이다. 스토리지는디스크지연이 20ms를넘고 IOPS 대기가생길때체감성능저하가빠르게나타난다. SSD 계층을추가해도, 쓰기증폭이많은워크로드에서는금 방한계에부딪힌다. 장기적으로는테이블파티셔닝, 아카이빙, 인덱스재구성, 쿼리재작성의조합이필요하다.

3. 캐시는축복이자함정이다. 높은히트율을유지하면비용과지연이함께줄지만, 캐시스탬피드는트래픽폭탄 으로이어진다. 만료를한시점에몰아두지말고, 분산만료를쓰거나 soft TTL 전략을쓰는편이안전하다. 장애 중에는캐시전체플러시를금지해야한다. 감정적으로시원하지만, 탄산한캔에불을끄는격이다. 캐시클러스 터에파편화가심해졌다면재샤딩을검토하되, 실시간재분산이가능한토폴로지를미리준비한다. 큐는눈에덜띈다. 그러나큐지연이상승하면비동기작업이밀리면서체감성능과운영데이터가뒤틀린다. 대 표적증상은알림발송지연, 썸네일생성지연, 정산배치누락이다. 장애시점에는소비자수를수평확장하는 것이즉각적대응이지만, 메시지중복처리안전성을반드시확인한다. 오피사이트의정산로직처럼단한번만 처리되어야하는작업은멱등키와락을활용해재처리에도안전하게설계해야한다. 배포와변경관리, 결국사람의문제 장애의상당수는변경에서시작된다. 코드, 설정, 인프라, 데이터. 무중단배포파이프라인을갖추고도, 피처플 래그의잘못된기본값하나로지옥문이열린사례는셀수없다. 사람은실수한다. 그래서절차가필요하다. 변경 은시간대를가린다. 고위험변경은트래픽이낮은시간대에만, 더블체크이후진행한다. 배포전체크리스트를 짧고강하게만든다. 길면아무도보지않는다. 내경험상다음의 5개문항만꾸준히지켜도사고가반으로줄었 다. 이변경으로영향받는트랜잭션을문서화했는가롤백절차를테스트했고, 데이터마이그레이션의되감기 전략이있는가알림임계치와대시보드가배포후상태를감지하도록준비됐는가트래픽을안전하게절반 으로나눠카나리할수있는가비상연락처와책임자를모두태그했는가 피처플래그는현장에서빛을발한다. 배포를되돌리지않고도기능을꺼서피해를국소화할수있다. 단, 플래그 는쌓인다. 3개월이상방치된플래그는부채다. 정리주기를만드느냐, 장애때마다과거플래그가뜻하지않게 작동하느냐의선택지일뿐이다. 고객커뮤니케이션, 조용한복구가항상최선은아니다 고객은감지한다. 접속이느리거나결제가실패하면이미장애를체감하고있다. 모든장애에공지를박는것은 과도하지만, 체감영향이넓거나지속시간이 10분을넘길것으로보이면상태페이지업데이트를권한다. 문구 는짧고구체적으로. 영향범위, 시작시각, 현재조치, 다음업데이트시각. “일부사용자”라는표현은신뢰를떨 어뜨린다. 실제범위를모르겠다면조건을적는다. “안드로이드앱 6.0 이하버전에서로그인오류가발생중이 며, 15분내다음업데이트를제공하겠습니다.” 같은문장이다. 보상정책은조급하게확정하지않는다. 운영자는빨리죄송하다는오피가이드말을하고싶지만, 보상은데이 터와원인분석이후에결정하는것이공정하다. 대신당일내 1차안내, 48시간내최종공지의타임라인을약속 한다. 반복되는장애에서는보상보다재발방지계획이더중요하다. 계획이실현되는증거를보여줘야신뢰가 회복된다. 보안이슈와장애의경계 장애처럼보이지만, 실제로는보안이벤트인경우가있다. 스팸트래픽급증, 로그인시도폭증, 카드 BIN 범위 스캐닝같은패턴이다. 속도가생명인장애대응에서, 보안확인절차는속도를늦춘다. 그래서미리룰을만든 다. 특정임계치이상의인증실패율상승은 WAF 룰을단계적으로강화하고, 의심구간의트래픽을별도풀로분 리한뒤샘플링한다. 중요한것은차단이전에우회경로를확보하는일이다. 정상사용자까지막아버리면장애 가된다. 보안과가용성사이에완벽한정답은없다. 조직마다위험감내수준을합의해둬야한다. 과거새벽시간대에리퍼러가비어있는 GET 요청이폭증해검색페이지가사실상마비된적이있었다. 초기에 DDoS로판단해 IP 차단을확대했지만, 30분후같은 ASN에서정상사용자트래픽도다수포함된것이확인됐다. 이후에는레이트리밋을사용자세그먼트기준으로바꾸고, CAPTCHA를단계적으로삽입하는우회전략을쓰 면서서비스중단없이방어했다. 이경험이후보안룰변경도배포와동일하게변경기록과롤백플랜을요구한 다.

4. 모니터링의함정, 숫자에속지않기 지표만보면상황을잘알것같지만, 지표는관점이다. 평균응답시간이개선됐는데민원은늘어나는이상한경 우가있다. 백분위수의함정이다. p50이좋아져도 p95, p99가나빠지면장치가느린사용자, 네트워크가취약한 사용자는더불편해진다. 장애대응시에는적어도 p95까지같이본다. 또하나, 애그리게이션간격의문제다. 1 분단위지표는 10초단위스파이크를숨긴다. 에러율이 1분평균 2퍼센트로보이지만, 실제로는 10초동안 20퍼 센트까지치솟았다가내려갈수있다. 알림은짧은간격과긴간격두가지를섞어야한다. 로그역시유용하지만, 과도한샘플링은원인을가린다. 비용때문에로그를 10퍼센트만남기는환경에서, 특정 에러의재현빈도를과소평가하는일이흔하다. 장애시점만큼은샘플링을일시적으로끄고, 이후다시복구하 는기능을준비해둔다. 비용은늘지만, 원인분석시간을줄인다. 포스트모템, 비난없는회고는실제로가능한가 장애가끝나면회고가남는다. 비난없는회고를말로만외치면무용지물이다. 핵심은행동의변경으로이어지 는가, 그리고그변경이나중에검증되는가다. 좋은포스트모템은다섯가지를남긴다. 사고의타임라인, 직접원 인과근본원인, 감지지연과의사결정지연분석, 재발방지액션과마감일, 알림과커뮤니케이션개선점. 특히 의사결정지연은사람문제로귀결되기쉬운데, 대개는정보의부족이나과도한승인절차가원인이다. 권한을 넓혀야할때와좁혀야할때를구분해문서화한다. 실제조직에서는마감일이밀리기쉽다. 그래서분기마다장애액션아이템이행률을경영지표로올려둔다. 개 발팀의 KPI가되면형식적이될수있다는우려가있지만, 아무지표도없으면더빨리흐려진다. 밸런스가필요 하다. 액션수를줄이고, 효과가큰것부터완료하도록스코프를작게쪼갠다. 재해복구와지역다중화, 비용과현실의타협 DR 계획은문서속에서만존재하기쉽다. 두지역에모든것을이중화하면이상적이지만, 비용과운영복잡도가 크게오른다. 현실적접근은핵심데이터와필수트랜잭션만우선순위를지정해보호하는것이다. RTO와 RPO를 비즈니스와합의한다. 예를들어결제는 RPO 0에가까워야하지만, 로그데이터는 RPO 10분도감내할수있다. RTO는사용자의인내심과직접연결된다. 15분내복구가가능한구성인지, 실제로연 1회이상훈련하는지에답 할수있어야한다. 훈련없는 DR은그림의떡이다. 클라우드사업자내다중리전은설정으로가능해보이지만, 네트워크, IAM, 데이터동기화, 서드파티종속성등 숨은단서가많다. 특히라이선스가리전별로달리적용되는상용소프트웨어는장애시전환을가로막는다. 계 약과키관리까지포함해서재점검해야한다. CDN 역시모든 POP에서동일하게동작하지않는다. 리전장애가 발생하면, CDN의오리진라우팅규칙이의도와다르게작동할수있다. 테스트는로컬에서가아니라실제리전 장애를가정한캔드테스트로진행해야한다. 팀을지키는운영문화 장애는사람을소모시킨다. 새벽알람, 주말복구, 포스트모템까지이어지면팀은금방지친다. 교대제를만들고, 온콜수당을명확히지급하고, 대체휴무를보장한다. 온콜자는의사결정권한이있어야한다. 권한없는온콜은 전화기지킴이에불과하다. 장애대응매뉴얼은누구나읽을수있지만, 모두가같은실력을갖추지는않는다. 정 기적인게임데이로대응역량을끌어올린다. 의도적으로작은장애를만들어팀이안전하게실패해보게하는훈 련이다. 실전에서는그 10분의연습이차이를만든다. 또하나, 사내공유의습관. 장애를겪은팀만배운다면, 조직의학습속도는느리다. 주간공유에서짧게라도 “이 번주장애한줄요약, 배운점하나”를소개하면, 같은실수를다른팀이줄인다. 오피사이트같이변화가잦은 환경에서는이공유가비용을크게절약한다. 현장에서바로쓸수있는초단기체크리스트

5. 두꺼운매뉴얼은장애시에펼쳐지지않는다. 평소에는깊이있는문서를, 위기에는손에잡히는한장을. 아래 체크리스트는실제운영중손에익힌순서다. 팀과스택에맞게수정해붙여두면좋다. 장애선언, 채널오픈, 역할지정, 타임라인기록시작고객체감지표확인, 상태페이지 1차공지판단최근 30분변경사항확인, 카나리롤백또는플래그오프검토외부의존성상태점검, 임시폴백또는라우팅전 환트래픽제어, 읽기캐시확장, 핵심트랜잭션보호 이다섯줄만지켜도, 대다수의장애는확산을막을수있다. 세부행위는조직마다다르지만, 순서와의사소통은 어디서나비슷하다. 오피가이드수준의실무팁몇가지 오랫동안현장에서통했던자잘하지만실전적인팁을더한다. 완벽한해법은아니지만, 작은차이가큰시간을 벌어준다. 첫째, 에러페이지도서비스다. 단순한사과문보다, 현재상태와예상복구시간을담은가벼운에러페이지는고 객이탈을줄인다. 캐시가능한정적에러페이지를 CDN에미리올려두면, 오리진이아플때도품격을지킬수 있다. 둘째, 지갑을열타이밍을정해둔다. 장애시즉시비용을올려해결할수있는구간, 예를들어메시지전송단가 가더비싸도성공률높은공급자로스위치하는판단을, 사전에 CFO와합의해둔다. 의사결정이늦어지지않는 다. 셋째, 메트릭명명규칙을표준화한다. 팀이바뀌어도 “service.request.error.rate”, “db.connection.utilization”처럼상 식적네임스페이스를쓰면, 새멤버도빠르게대시보드를읽는다. 넷째, 실패실험을기록으로남긴다. “이방법은안먹혔다”는문장이다음장애에서 5분을절약한다. 희망적실 험을반복하는시간은가장값비싸다. 다섯째, 고객센터와기술팀의핫라인을만든다. 고객센터는체감이슈를가장빨리알고, 기술팀은원인을가장 늦게알때가있다. 단두줄의템플릿, “증상, 단말/통신사, 시작시각”만정확히받아도탐지속도가빨라진다. 마무리, 장애를줄이는가장확실한길 도구와스택은바뀐다. 좋은베스트프랙티스도환경을옮기면반쪽짜리가된다. 그러나장애를줄이는원리는 의외로단순하다. 관측을신뢰하고, 변경을작게하며, 폴백을준비하고, 기록으로말하는것. 오피사이트처럼변 동성이큰서비스는특히이원칙의효과가크다. 오피가이드식으로말하자면, 장애는없앨수없지만, 줄이고 짧게만들수있다. 오늘하나라도준비하면, 다음장애의첫 10분이달라진다. 그리고그 10분이, 고객과팀을지 킨다.