#On The Field 개발자가 개발에만 집중할 수 있도록 전담하는 프로덕트팀 DevOps
안녕하세요, 페이타랩 프로덕트팀 DevOps Engineer 파트 리더 김예찬입니다.
그동안 페이타랩의 DevOps 파트가 어떤 가치관을 가지고, 어떤 일을 하는지에 대해 공유할 수 있는 자리가 없어서 아쉬움이 있었는데,
이번 팀 블로그를 시작하며 프로덕트팀원 중 첫 기회가 저에게 오게 되어 참 기쁩니다. 😊
DevOps 파트 리더이자 실무자로서, 여러분과 나누고 싶었던 이야기를 들려드리고자 합니다.
제목없음
포지션 차이
DevOps Engineer, 어떤 역할을 맡고 있나요?
DevOps Engineer는 쉽게 설명해 드리자면 '개발'과 '운영'을 아우르며 하나의 통합된 프로세스로 묶어내는 역할을 합니다.
흔히 서버 인프라를 관리하고, 소프트웨어 배포 및 운영 파이프라인 자동화, 네트워크 작업을 하는 시스템 엔지니어나 SRE(Site Reliability Engineer)와 동일하게 생각하시기도 해요. 물론 이 역할들도 DevOps Engineer의 큰 부분을 차지하고 있습니다. 이 또한 얼마나 중요한 업무들인가요?
하지만 DevOps Engineer는 단순히 인프라 업무를 넘어서 개발팀뿐만 아니라 회사 전체가 더욱 원활하게 자신의 업무에 집중할 수 있도록 지원한다는 점이 위 두 역할과의 가장 핵심적인 차별점이라고 생각합니다.
동료들이 업무에서 마주하는 기술적인 불편함과 비효율성에 깊이 공감하고, 이를 해결하기 위해 혁신적인 해결책을 마련하는 것.
이게 바로 DevOps Engineer의 역할이라고 생각하고 있어요.
그래서 페이타랩의 DevOps 파트는 이런 가치관을 디딤돌로 삼고 있습니다.
때로는 필요한 서버 환경을 가장 빠르고 안정적으로 구축하는 시스템 엔지니어
때로는 서비스의 최대 가용성 보장을 위해 모든 노력을 기울이는 SRE
더 나아가서는 개발자들이 보다 원활하게 일할 수 있도록 든든하게 서포트하는 "IT팀을 위한 IT팀"이 되어드리기도 합니다.
저희는 이 모든 노력과 애정을 쏟으며 패스오더 서비스가 매일 매일 한 발자국 더 발전할 수 있도록 끊임없이 기여하고 있어요.
경영지원업무
패스오더 서비스의 미라클 모닝 ☀️
"미라클 모닝"은 이른 아침부터 독서나 운동 등을 통해 하루를 생산적으로 시작하는 라이프 스타일을 말하죠.
그런데 저희 패스오더 서비스도 자신만의 '미라클 모닝'을 매일 실천하고 있다는 사실, 알고 계셨나요?
네, 맞아요! 패스오더에게 하루 중 가장 중요한 피크 타임이 바로 아침 시간대입니다.
사람들이 막 출근을 시작했을 무렵인 오전 8시에서 9시 사이, 패스오더는 이 단 한 시간 동안 하루 전체 트래픽의 무려 33.3%를 소화하며 가장 활발하게 움직입니다. 유저들의 주문이 폭주하는 서비스의 핵심 골든타임인 셈이죠!
저희 DevOps 파트는 이처럼 중요한 피크 시간을 단 한 순간도 문제 없이 안정적으로 보낼 수 있도록 트래픽 흐름에 맞춰 서버 규모를 미리 확장하는 자동화 시스템을 빈틈없이 구축해 두었어요.
패스오더의 성공적인 아침은 자동화로부터
출근 시간대와 점심 시간대에 가장 높은 트래픽 패턴
시간대에 관계 없이 언제나 안정적인 서비스 퍼포먼스 구현
패스오더 서비스는 예측 가능한 트래픽 패턴이 반복된다는 큰 특징을 가지고 있어요.마치 직장인들이 출근길에 자연스레 카페를 찾아 카페인 수혈을 하는 것처럼 패스오더 또한 매일 아침 비슷한 양상으로 활발하게 사용되는 모습을 보여줍니다.
이러한 패턴을 발견한 덕분에 저희는 트래픽 증가에 맞춰 미리 서버 규모를 선제적으로 확장하여 어떤 상황에서도 유저들이 불편함 없이 패스오더를 사용할 수 있도록 안정성을 확보하고 있습니다.
물론, 시간대 마다의 알맞은 확장 값을 찾기까지는 정말 많은 노력이 필요했어요. 자칫 잘못 설정한다면 실 수요 대비 서버 규모가 부족해 장애가 발생할 수도 있기 때문에 신중하고 세심한 접근도 요구되었죠.
페이타랩 DevOps 파트의 대원칙인 "사용자의 서비스 경험이 우선"이라는 명제에 따라 초반에는 예측 값 이상으로 서버 규모를 충분히 확장하여 안정성을 확보했어요.
그 후, 리소스 사용량을 점진적으로 축소 및 최적화하는 과정을 거쳐 현재는 가장 효율적인 서버 자동 확장 시스템을 정교하게 구축해 두었습니다.
그리고 저희는 여기서 더 나아가 매주 정기적으로 지난 한 주의 서버 지표와 리소스 사용량을 꼼꼼히 체크하고 분석하면서 다음 확장 때의 리소스 절감과 효율성 극대화를 위해 지속적으로 노력하고 있어요.
그렇다면 Autoscaler는?
물론, 저희도 Autoscaler를 활용해 서버 개수와 DB 규모를 유동적으로 확장 및 축소하고 있어요.
그럼에도 스케줄링을 걸어 미리 규모 조정을 하는 이유는, Autoscaler가 개입할 때는 이미 늦었다고 보기 때문입니다.
특정 Threshold나 Anomaly 패턴 등에 의존하고 있는 Autoscaler는 서버 규모가 확장돼야만 하는 계기, 즉 평균 이상의 트래픽이 발생했거나 부하가 높은 상황이 발생해야 동작하게 됩니다. 이러한 지표를 감지하여 서버 규모가 늘어나기 시작했다는 건, 이미 일부 유저는 서비스 지연을 감지한 후일 가능성이 높다는 거죠.
"최고의 사용자 경험"을 추구하는 페이타랩 DevOps 파트는 Autoscaler로 서버가 자동 확장되는 그 찰나의 순간이라도 유저가 지연을 경험하는 일 없도록 해야 한다는 결론을 내렸습니다.
하지만 사용자 경험을 최우선에 두는 것은 비용 최적화와 함께하기에 그리 친한 친구는 아니죠.
이 둘을 잘 중재해서 서비스 운영 비용의 효율화를 개선해 내는 것 또한 저희 파트의 큰 업무입니다. 서버 확장 직후, 약간의 리소스가 더 발생하긴 하지만
최고의 서비스 품질과 안정성 그리고 우리 모두의 마음의 평화🧘‍♂️(굉장히 중요한 부분 중 하나이죠!)를 위해 타협하는 자세도 필요한 것 같아요.
따라서 Autoscaler는 스케줄링을 통한 서버 확장 그 이상을 넘어서서 예상치 못한 부하가 들어왔을 때의 대응을 도울 “일종의 보험 역할”로 그 자리를 지키고 있습니다.
DevOps Engieer도 함께 미라클 모닝 ☀️
그렇다면 서버 인프라만 미라클 모닝을 하고 있을까요?
아닙니다!
DevOps Engineer도 오전 피크 시간 만큼은 꼭 함께 실시간으로 모니터링을 하며 서버 상태를 체크합니다.
패스오더 유저들의 모든 여정을 함께하는 페이타랩 파트너지원팀과 함께 긴밀하게 소통하며 실시간으로 유저 레벨과 인프라 레벨에서의 서비스 상태 모두 챙기고 있어요.
DevOps 파트와 파트너지원팀의 미라클 모닝
파트너지원팀
고객 인입을 실시간 대응하며 패스오더 앱을 사용해 반복적으로 테스트 주문을 발생시켜 서비스에 문제가 없는지 확인합니다.
DevOps 파트
인프라 상태를 실시간 모니터링하며 에러가 발생하지는 않았는지, 서비스 Latency는 정상인지 등을 확인합니다.
사실 미라클 모닝을 실천하는 건 사람도 서버도 쉽지만은 않아요.
하지만 800만 패스오더 유저가 고된 출근길에 여유롭고 편하게 카페인 수혈을 할 수 있도록 도와준다는 점에 큰 보람을 느끼고 있답니다.
그리고 이만큼의 대용량 트래픽을 매일 같이 다룰 기회는 DevOps Engineer로서도 쉽게 접할 수 있는 경험이 아니라고 생각해요.
여러분도 800만 유저의 카페인 수호자가 되어 보고 싶지 않으신가요?
제목없음
경영지원팀인재상
오싹오싹 장애 대응하기 🥶
전 세계를 아울러 DevOps Engineer에게 가장 큰 공포는 무엇일까요?
네, 바로 장애 상황입니다. 심장이 벌렁거리고 땀이 비 오듯 나는 장애 상황은 아무리 겪어도 쉽게 익숙해지지 않죠.
혼란스러운 상황에서 최대한 빠른 서비스 복구가 필수적인 만큼,
페이타랩 DevOps 파트는 "일단 따라하면 어떻게든 서비스를 살릴 수 있는 가이드"를 구축해 두었어요.
장애 대응 가이드는,
깊이 생각할 겨를이 없는 상황에서 문제의 원인이 될 만한 핵심 요소들을 빠르게 살펴보고 추가 리소스를 넉넉하게 투입시켜 대응할 틈을 버는 것이 핵심이에요.
그렇기에 최대한 복잡하지 않아야 하고, 일단 따라하면 문제 상황을 해결할 수 있을 만큼 간단해야 한다고 생각합니다.
1. 페이타랩의 3가지 핵심 대응 전략
➊ 서버나 데이터베이스의 확장
패스오더는 서비스 Latency가 높거나 데이터베이스의 CPU가 비정상적으로 높아지는 등의 비정상 지표가 감지되면 문제가 발생하는 서버(마이크로서비스)나 데이터베이스를 2배 규모로 확장합니다.
순간의 장애 대응에서 최대한 가용성과 버퍼를 확보하는 것이 주목적이고, 높은 사양을 선택하더라도 길지 않은 시간 이내의 사용은 수 달러 수준으로 크지 않다는 점을 확인하여 이렇게 결정하게 되었어요.
➋ ArgoCD와 Argo Rollouts을 통한 현대적인 배포 형태 관리
페이타랩에서는 배포 이력을 업무 툴인 Notion과 Slack의 특정 채널에서 체계적으로 관리하고 있어요.
ArgoCD와 Argo Rollouts을 통해 배포 형태를 현대적으로 관리하고 있기 때문에 히스토리 확인 후 이전 버전으로 수십 초 안에 복구할 수 있죠.
➌ "3분 주문 취소" 지표
마지막으로, 페이타랩만의 특별한 지표로 "3분 주문 취소"라는 값이 있어요.
고객이 접수한 주문이 3분 안에 수락되지 않을 경우, 서비스 장애일 수도 있다고 생각해서 Slack을 통해 알림을 받고 있습니다.
3분 주문 취소가 5분 내에 10건 이상 발생한 경우, 서비스에 문제가 있으니 확인이 필요하다고 경고를 보내줍니다. 이 경우에는 위에서 언급한 Latency, 사용량, 또는 에러 발생률 지표를 종합해서 서비스에 문제가 없는지 진단하고 그에 알맞는 조치를 취하고 있습니다.
이렇듯 대부분의 긴급 대응 조치는 높은 스킬을 필요로 할 정도로 어렵진 않지만 담당자가 당황하는 바람에 빠르게 할 수 있는 조치도 늦어지는 경우를 종종 보았어요.
이는 사람이라면 당연한 반응일 수밖에 없는 것 같습니다.
그래서 이런 경우를 대비해 일단 따라할 수 있는 가이드를 마련해 두었고, 가이드가 주는 심리적 안정감 덕분에 실제 대응도 더욱 신속하고 침착하게 이뤄지고 있답니다.😉
2. 놓칠 수가 없는 알림, Squadcast
저희 페이타랩은 모두 Slack을 통해 소통하고 있습니다.
하지만, 긴급 대응이 필요한 장애 상황에서도 과연 Slack으로 충분할까요?
아닙니다!
Slack의 알림은 메시지 내용의 크리티컬함 수준을 구별해주지 못하기 때문에 한창 업무에 집중하고 있거나 퇴근 이후라면 수많은 메시지 알림 속 섞여 있는 절.대. 놓치면 안 되는 서비스 경고를 놓칠 수도 있죠. (어떻게 알았냐구요? 저도 알고 싶지 않았습니다. 🥲)
뼈아픈 상황들을 직접 겪으며 이런 문제점을 인지한 저희는 Slack과는 별도로 상황의 심각성을 알 수 있는 알림 시스템을 마련하였습니다.
바로, 체계적인 On-call 알림 기준을 설정한 것이죠!
Squadcast라는 On-call 특화 서비스를 활용해 Slack 알림과 더불어 앱 푸시 알림&전화로 긴급 시스템 알림을 받고 있어요.
즉각적인 확인이 필요한 알림이 발생하면 Slack 메시지와 더불어 Squadcast 서비스를 통한 모바일 푸시 알림이 발생하게 됩니다. 여기서의 푸시 알림은 iOS와 Android 모두 "Critical Alert"로 분류되기 때문에 휴대폰이 무음 혹은 작은 볼륨으로 설정되어 있어도 언제나 최고 음량으로 울립니다.
만약 이 단계에서도 문제 확인이 안 된 경우, 사태 중재가 가능한 서비스 관리자 레벨에게도 푸시 알림과 함께 전화 알림이 발송됩니다.
ARS 전화처럼 자동 응답기 전화를 통해 특정 장애가 진행되고 있음을 알려주는 거죠.
저희 페이타랩은 이런 조치들을 통해 심각한 장애 발생 시, 담당자가 빠르게 인지하도록 환경을 마련해 두었고 모든 담당자가 부재중일 때에도 관리자 인원들을 호출해 빠른 Escalation이 가능하게 했습니다.
서비스를 운영하며 마주하는 장애 상황은 언젠가는 꼭 겪을 수밖에 없는 그리고 절대 피할 수 없는 숙명과도 같아요.
페이타랩 DevOps 파트에서는 이런 뼈아픈 운영 경험을 바탕으로 "어떻게 하면 장애 상황을 조금이라도 더 빠르게 파악하고 대응할 수 있을까"에 대해 열심히 고민하고 있습니다.
직관적인 대응 가이드와 적절한 알림 도구를 활용해 이전에는 빠르게 대응하기 어려웠던 문제들을 신속하게 대처해가며 한 걸음 더 성장하는 스스로의 모습과 패스오더를 체감하는 것은 매일 아침 기분 좋게 업무를 시작할 수 있게 하는 원동력이 되어준답니다.
제목없음
제목없음
지쳤나요?
또 하나의 애증, 배포하기
개발자가 가장 자주 마주하지만 익숙해지지 않는 애증의 존재가 또 무엇일까요?
바로 배포입니다.
끊임없이 성장하는 조직에서 잦은 배포는 필수적입니다.
그만큼 고객에게 더 빠르고 많이, 그리고 Agile하게 새로운 서비스의 가치를 전달한다는 의미니까요.
하지만, 기존에 문제 없이 작동하던 서비스에 새로운 무언가를 추가하는 작업이다 보니 "잘 돌아가던 서비스에 문제가 생기면 어쩌지?" 하는 불안감을 안겨주게 됩니다.
그렇다고 배포를 안 할 수는 없는 법!
페이타랩은 이러한 불안을 해소하고 안정성을 높이기 위해
Canary 배포 방식을 도입했습니다.
🔎Canary 배포란?
신규 코드를 소수의 트래픽에 먼저 적용하여 안정성을 확인한 후, 점진적으로 트래픽을 늘리는 배포 방식
(1) Argo Rollouts로 시작된 Canary 배포
페이타랩은 기존에 사용하던 ArgoCD에 연동 가능한 Argo Rollouts을 통해 Canary 배포를 구현하기 시작했어요. 하지만 마이크로서비스 아키텍처(MSA) 환경과 HTTP, Kafka를 함께 사용하는 복잡한 구조는 곧 두 가지의 큰 난관에 부딪혔습니다.
[ 첫 번째 두통, 그리고 해결 ] 마이크로서비스 간 통신 문제
Canary 워크로드가 구버전의 Stable 워크로드와 통신하면서 문제가 발생한 상황이었습니다. 저희는 Istio Service Mesh를 활용해 Stable은 Stable끼리, Canary는 Canary끼리 통신하도록 라우팅 규칙을 설정하여 문제를 해결했습니다. 또한 외부 트래픽만 'Canary와 Stable 사이의 비율'로 나누는 방식으로 내부 통신 일관성을 유지할 수 있었습니다.
[ 두 번째 두통, 그리고 해결 ] Kafka 통신 문제
Kafka 통신에는 Istio의 라우팅 분기 기능을 직접 적용할 수 없다는 문제가 있었습니다. 고민 끝에 Kafka 통신을 REST 형태로 바꿔주는 Gateway(Proxy)를 직접 제작해서 문제를 해결했습니다. 이를 통해 Kafka 이벤트 통신에도 Istio의 라우팅 기능을 적용할 수 있게 되었고, 이벤트를 발행한 Pod의 메타데이터를 구분점으로 삼는 커스텀 Header를 추가해
Canary 배포 상태에서도 정상적인 통신을 구현해냈죠.
(2) 그렇게 탄생한 "0단계 모드"
이러한 점진적인 배포를 통해 유저에게 미치는 영향을 최소화할 수는 있었지만 저희는 또 다른 두 가지 고민에 빠졌습니다.
첫째, 단 한 명의 유저도 불편함을 겪지 않으면서 배포 시 발생한 문제점을 인지할 수 있는 방법은 없을까?
둘째, 프로덕션 데이터와 인프라를 활용해 꼼꼼하게 QA를 하면서도 유저에게 실제로 영향을 주지 않을 수는 없을까?
이러한 고민을 해결하기 위해 저희는 통상적인 점진적 배포에는 존재하지 않는 특별한 "0단계 모드"를 고안했습니다.
0단계 모드는, 워크로드는 실행되지만 실제 외부 트래픽 인입에는 영향을 주지 않아요.
대신 특수한 QA용 HTTP Header가 삽입된 요청만 Canary로 흘러가도록 설계해서 프로덕션 서비스에는 영향을 주지 않으면서도 안전하게 테스트할 수 있는 환경을 구축하였습니다.
덕분에 프로덕션 환경에서의 QA 부담이 '거의 없다' 싶을 정도로 줄어들었고, 개발자들의 배포 부담은 줄이고 질 좋은 코드를 더 자주 그리고 많이 배포할 수 있게 되었답니다.
이러한 우여곡절 끝에 Canary 배포 인프라가 완전히 정착할 수 있었고 페이타랩 배포 프로세스의 알파&오메가 역할을 착실히 수행하고 있답니다.
이제는 민감한 배포도 마음 졸이며 진행하지 않아도 되고 트래픽이 적은 새벽에 출근해야 할 경우가 적어져서 개발자분들께서 업무 만족도가 굉장히 상승했다고 해요.
무엇보다 0단계 모드를 활용해 안정적인 환경에서 QA가 가능하여 잠재적인 문제를 미리 수정하고 배포할 수 있게 되었다는 점이 우리 모두에게 큰 심리적 안정감을 주고 있습니다.
DevOps 파트 역시 모든 배포를 민감하게 추적하고 모니터링하는 부담이 줄어서 업무 시간을 더 생산성 있게 사용하게 되었고 피로도 많이 감소했어요.많은 시간과 노력이 필요한 개선이었지만 결과적으로는 이 모든 리소스가 들어갈 만한 가치가 있었고 커리어 측면에서도 큰 성취를 이룰 수 있었습니다.
제목없음
제목없음
성장과기회
여기까지, 페이타랩 DevOps Engineer의 이야기였습니다.
자, 여기까지가 저희 페이타랩의 DevOps 파트 이야기입니다. 어떻게 읽으셨나요?
"와, 흥미롭다!" 싶으시다면 여러분도 훌륭한 예비 페이타랩 DevOps 인재입니다.
페이타랩은 오늘도 성장하기 위해 빠르게 움직이는 조직이에요.하루하루 성장하는 서비스의 든든한 버팀목인 DevOps 파트는, 패스오더가 잘 달려 나갈 수 있도록 그리고 흔들리지 않도록 잘 잡아주는 파수꾼 역할을 하고 있습니다.
DevOps Engineer로서 역동적인 성장을 함께 해보고 싶지 않으신가요?
긴 글 읽어주신 오늘의 독자 여러분, 내일은 팀원으로 만날 수 있기를 바라봅니다.
페이타랩 파수꾼 이야기의 주인공이 되고 싶다면?
페이타랩 합류하기
제목없음
김예찬 페피DevOps Engineer ㅣ 프로덕트팀
개발자가 개발에만 집중할 수 있는 환경을 고민합니다.
오늘도 서버의 신에게 다운타임 방지 기도를 올리며 ···
우리 업장 무사고 0일차.
