23.06.15
DEVOTEE를 활성화 시키면
지금 작성한 커뮤니티 글에 대해 1개의 댓글을 달아줍니다.
버튼을 누르면 글 수정 시 ChatGPT가 작성한 댓글이 수정됩니다.
| 컨텐츠 유형 | 제목 | 저장일 | 삭제 |
|---|
본인인증 로그인에 실패하였습니다.
회원이 아니시거나 본인인증 등록이
완료되지 않은 사용자입니다.
바야흐로 때는 에이닷의 초기 개발 시점... 초기 서버 개발 인원으로 서비스를 안정적으로 설계 및 개발하여 당차게 출시 해 보려는 서버 개발자들이 있었으니~
네 그렇습니다. 에이닷 서버팀의 첫 시작은 이렇게 작게 시작하였습니다.
하지만 늘 그렇듯 우리의 목표는 항상 크고 위대합니다. 고객에게 어떻게 더 발전된 서비스를 제공할 수 있을까요? 우리는 어떻게 한정된 자원으로 최대의 목표를 달성 할 수 있었을까요?
그래서 우리는 퍼블릭 클라우드를 사용하고, 클라우드 네이티브 아키텍처를 따르는 설계를 하기로 결정하였습니다.
기존의 IDC 내에서 개발하는 형식으로도 클라우드 환경에서 개발할 수 있습니다.
하지만, 클라우드 환경에서 애플리케이션을 최적화하고 확장성과 유연성을 극대화하기 위해서는 어떻게 해야 할까요?
우리는 아래의 항목들을 적용하여 생기는 부가 시간들로, 비즈니스 로직 개발에 더 집중 하기로 하였습니다.
하나의 repository에서 여러 비즈니스 로직 서버 개발을 진행하는 전략을 채택하였습니다.
이는 불필요한 중복 코드를 획기적으로 줄이고, 관심사가 같은 서비스 군들로 서버를 묶음 및 분할하여 고객의 요구사항에 맞추어 서버를 논리적, 물리적 분리 할 수 있도록 만들었습니다.
각 내부 서비스들이 고객의 트래픽 부하에 따라서 자동으로 그 갯수가 증감하는 auto-scale in/out 을 적용하였습니다.
수동으로 물리적인 서버를 증설하는 것이 아니라 일관된 가상의 서버들이 증감하게 하여 서버 구축의 복잡성이 감소하였습니다.
바퀴를 예로 들어보겠습니다. 비즈니스가 성장함에 따라서 현재 시장에 나와 있는 바퀴로는 대응이 불가 할 수 있습니다.
이 때에는 바퀴를 새로 개발하고 유지하는 팀이 생겨나서 해당 바퀴를 가지고 비즈니스를 해야할 것입니다. 그렇지만 현재 시장에 나와있는 바퀴가 괜찮다면 어떠한 선택을 해야할까요?
우리는 현재 비즈니스 상황에서 차용할 수 있는 다양한 바퀴들을 도입했습니다. 또한 도입하면서 언제든지 바퀴를 바꾸어 사용 할 수 있도록 유연성도 설계에 추가하였습니다.
해당 과정으로 훌륭한 바퀴들인 큐, DB, 모니터링, 로깅 시스템들을 사용하고 있고 해당 커뮤니티에 의해 지속 발전되고 있습니다.
이는 문제가 발생하기 전에 이상 현상을 모니터링 하는등 사전 대응도 가능하게 했습니다.
개발자는 비즈니스 로직의 개발에만 집중 할 수 있도록, 운영에 대한 부담을 코드로 자동화하여 줄이는 것을 목표로 하였습니다.
이를 위해서 사용된 것이 GitOps와 IaC입니다.
monorepo, kubernetes, git을 유기적으로 엮어 GitOps를 도입하였습니다.
개발자가 개발된 코드를 소스 저장소에 커밋하면 이를 감지하고 자동으로 CI/CD가 수행되어 빌드 및 배포까지 완료되도록 하였습니다.
이를 인프라 자체에도 적용하는 IaC를 도입함으로 인해서, aws 인프라 자체까지 GitOps의 범위로 포함할 수 있었고, 이를 통해 코드로써 인프라도 관리할 수 있게 하였습니다.
즉, 현재 소스 저장소에 올라간 코드가 곧 배포된 서버 환경 그 자체이다.
라는 전제를 믿고 개발자는 코드만 신경써서 개발할 수 있게되었습니다.
에이닷의 초기 런칭은 성공적으로 잘 마무리 되었습니다. 이제 실제로 트래픽을 맞으며 서버 최적화 및 운영을 하고 추가 기능 개발 건을 대응해야 합니다.
정신없이 추가 기능을 개발하다가 한 종류의 AWS 인프라 비용이 꽤 많이 부과되는 것을 확인 하였습니다.
그것이 어떤 것이었을까요? 예상을 해 보실 수 있을까요?
때로는 다윗이 골리앗을 이길 수도 있는 법이죠.
지속 증가하는 새빨간 비용 그래프 🥲
해당 비용은 로깅을 담당하는 cloudwatch 비용이였습니다.
개선 사항을 도출해야 했습니다.
cloudwatch 로그 비용은 인입되는 로그 크기와 저장하는 로그 크기로 크게 2가지의 GB 용량 단위로 과금이 됩니다.
따라서 저장하는 로그 크기를 절대적으로 줄이는 것이 유효할 것이라 판단했습니다.
현재 발생하는 로그의 양을 줄이기 위해서 cloudwatch의 최적화를 진행하기로 하였습니다.
cloudwatch에서 사용하는 로그 수집 도구는 fluent-bit입니다.
aws에서 제공하는 설정 가이드의 기본 값은 kubernetes에서 발생하는 모든 로그를 수집합니다.
사내 보안 규칙에 위배되지 않으면서 비즈니스 로직의 관심사에 해당하는 로그들만 수집하도록 설정하여 중복 수집을 최소화 하였습니다.
기본 값은 모든 로그에 로그 생성 당시의 kubernetes pod 정보를 같이 출력하고 있었습니다.
해당 정보는 metric 수집기에서도 수집하는 중복 정보이므로 제거하였습니다.
또한, 로그 필터처리 전의 로그 원본을 보존하는 옵션도 제거하여 로그가 2배로 찍히는 경우도 제거하였습니다.
cloudwatch의 로그 저장 플랜에서 로그의 저장과 검색만 가능한 옵션이 있습니다. 여러가지 잡다한 더 많은 기능을 제공하지 않는 대신 가격이 2배 저렴합니다.
알람 시스템은 더 저렴한 타사의 시스템을 사용하고 있으므로 로그 저장 플랜을 수정하였습니다.
위의 개선 사항들을 적용하였습니다.
그래프의 2번째 막대까지가 적용 전이며, 3번째 막대가 월 중간에 적용하여 줄어든 모습입니다.
그리고 4번째 막대가 한달 모두 적용되어 3번째 그래프 대비 약 25%만 과금 된 것을 확인 할 수 있습니다.
한 달에 나가는 빨간색의 cloudwatch 비용을 줄이고 보니, 이번에는 파란색의 그래프가 눈에 들어오기 시작했습니다.
해당 비용은 database 비용이였습니다.
비용을 조사해 보니 storage io 비용이 많이 나오고 있었고, 사용량 대비 instance type이 높게 잡혀 있었다는 것을 확인 할 수 있었습니다.
그래서 아래와 같이 최적화를 진행하였습니다
aws rds의 기본 과금 구조는 크게 instance node의 uptime에 대한 과금과 io 요청에 대한 과금으로 나눌 수 있습니다.
기본 과금 구조 이외에 io-optimized 과금 구조도 존재하는데, 이는 instance node의 uptime에 대한 과금이 30% 비싸지는 대신 io 요청에 대한 과금이 사라지는 것입니다.
이 부분을 현재 우리의 상황에 맞는지 조사하여, 과금 구조를 io-optimized로 변경하였습니다
조사 결과, 현재 구조에서 절반으로 instance type을 낮추어도 트래픽을 모두 소화할 수 있겠다는 계산이 나왔습니다.
따라서, instance type을 절반의 컴퓨팅 파워를 제공하는 type으로 변경하였습니다
서버 환경의 변경은 현재 접속하고 있는 모든 사용자에게 영향을 미치기 때문에, 실제로 행하기가 무척 까다롭고 어렵습니다.
배포에 절차가 있기 마련이고 이를 지켜야 에러가 없는 경우가 많습니다.
그렇다면 GitOps의 경우는 어떨까요? Database Instance Type 변경 무중단 배포를 할 수 있을까요?
우리는 이를 달성하기 위해서 Database connection pool의 max life time을 2분으로 설정했고, instance가 다른 서버를 순차적으로 띄워서 해당 배포에 대응하였습니다.
type만 다른 aws resource 2개를 순차적으로 적용하기 위한 Terraform 코드 중 일부
해당 설정 변경으로 50% 이상 절감 할 수 있겠다고 판단했고 실제로 그렇게 줄어들었습니다
그래프에서 파란색의 비중이 아름답게 줄어드는 모습을 보실 수 있습니다 🥹
SKT 에이닷은 AI와 함께 사용자에게 단순 기능 제공을 넘어 더 나은 가치를 제공합니다.
내부적으로 서버팀은 안정적인 서비스와 더 새로운 기능을 제공하기 위해서 노력하고 있으며, 지속 가능한 미래를 위해서 더 효율적인 방법을 찾아낼 것입니다.
즐거운 에이닷 사용이 될 수 있도록 하겠습니다.
감사합니다. 행복하세요!
DEVOTEE를 활성화 시키면
지금 작성한 댓글에 AI가 댓글을 달아줍니다.