11월 1주 있었던 일 정리

Introduction

• 운영 환경에서 OOM 발생
  • 문제 상황
  • 해결 과정
• 나의 고민
  • 토이 프로젝트 진행
  • 경계해야 할 부분 - 악동이 되지 말자.
  • 마지막으로

운영 환경에서 OOM 발생

문제 상황

운영 환경에서 heap 공간이 부족해서 OOM이 발생했어. 모니터링으로 확인했을 때 한 번의 요청에서 정말 많은 메모리가 필요했어.

사용한 메모리 양이 2.3GB 밖에 되지 않았지만 OOM 이슈가 발생했어. 물리 메모리를 넘어서 많은 메모리를 사용하게 되면 스와핑이 발생하는 게 맞지 않나 생각이 들었지.

자료

실제 물리 메모리를 캡처하지 못해서 큰 힌트를 얻지 못했지. 예상으로는 OS에 의해 메모리 할당을 받지 못해서 발생했다고 생각해.

다시 문제로 돌아오자면 전체 실행 시간을 봤을 때 메모리 소실이 존재하지 않았어.

해결 과정

문제가 발생했을 떄 heap 메모리가 과할당되고 그로인해 OOM이 발생한다면 한 명의 사용자의 데이터를 백업하기 위한 메모리 공간이 많이 필요하지 않을까라는 결론에 다다랐어. 원인에 맞게 문제를 해결 할 수 있는 방법에 두 가지가 존재했지.

• 메모리에 데이터를 적재하지 않고 디스크에 적재한 다음 압축을 진행한다.
• JVM 힙 사이즈를 임시적으로 늘린다.

첫 번째 방법은 코드 수정이 많지만 확실한 방법이고 두 번째 방법은 코드 수정이 없지만 실패할 가능성이 높았어. 그래서 JVM 힙 사이즈를 임시적으로 늘려 시도한 후 실패한다면 코드 수정 작업을 진행하는 게 좋아보였어.

메모리 크기 변경 이후 정상적으로 문제가 해결 됐어.

마지막으로 할당하는 메모리 용량의 크기가 커지면서 다른 서비스들과 메모리 할당 문제가 발생할 수 있어보였어. 지금은 80% 가량의 물리 메모리를 사용하고 있어.

현재가 요청량의 피크라고 생각해 그 이상의 메모리 증설을 하지 않을 계획이야.

진행 과정에서 아쉬운 점을 정리했어.

• 개발할 때 최대 데이터 양 계산이 미흡한 점
• 관리 툴 설정에서 평균 실행 시간을 측정하지 못한 점
• 관리 툴 설정에서 하루 총 실행량을 측정하지 못한 점
• 문제 상황의 상태를 측정하지 못한 점

개선점은 다음과 같아.

• 데이터 기반 의사 결정의 중요성을 꺠달음
• 예산 산정의 중요성을 꺠달음

오랜만에 JVM 메모리도 학습할 수 있었어.

나의 고민

요즘 업무를 잘하고 있는지 걱정이 많았어. 해야 할 업무를 찾고 개선하고 싶은데 목표와 명분이 없어서 행동이 위축되기도 했지. 필독! 개발자 온보딩 가이드 책을 읽는데 개발자로서 경계해야 할 점을 알려주고 있어서 책에 맞게 잘 수행하고 있는지 비교해보기로 했어.

작은 리팩토링은 꾸준하게 테스트 범위를 정하고 테스트를 추가하면서 제품에 기여할 수 있지만 요즘은 아쉬운 프로세스를 개선하고 싶은 마음이 컸어. 책에서는 대규모 리팩터링을 통해 기술부채를 상환하는 과정은 다음처럼 정의하고 있어.

1. 상황 사실 그대로 설명한다.
2. 부채의 위험과 비용을 기술한다.
3. 해결책을 제안한다.
4. 대안에 대해 논의한다.
5. 트레이드 오프를 비교한다.

장애 상황 들을 확인했을 때 서버 단위의 레이턴시 지표가 필요해보였고 시스템 메트릭 수집을 보강할 필요성을 느꼈어. JVM 상태 체크는 가능하지만, MSA 구조로 구성된 시스템에서는 서버 간 연결 상태 체크가 필요해보였지.

책에서 있는 전략을 고려해 1 번과 2 번을 미리 공유했고, 3 번 이후의 전략을 세워야 했어. 상황에 맞게 다음 진행 작업을 정리했어.

1. 개선할 점과 관련해 불편한 점을 추합한다.
2. 샘플을 보여주고 이해관계자의 반응을 파악한다.
3. 긍정적인 반응을 받으면 개선한다.

진행 작업을 정리하는 일도 중요하지만 실패를 대비하기 위한 방법도 필수였어. 특히나 관리가 안되서 사용되지 않는 코드들이 꽤나 많았어. 그런 제품들은 너무 아쉬웠는데, 내가 만든 제품도 그런 문제가 발생하지 않도록 개선이 필요했어.

• 구현에서 실패를 대비하기 위해 투자 비용을 줄이기 위해서 샘플 프로젝트로 시도하는 일이었다. 신기술에만 집중해 최대한 빠르게 팀원들에게 공유하는 방법을 선택했다.
• 운영에서 실패를 대비하기 위해 개선할 부분이 제품에 영향이 가지 않도록 주의하고 관리 포인트를 최대한으로 줄이도록 신경쓰려고 한다.

데이터베이스인 경우 지속적으로 관리가 필요한데 데이터가 많이 쌓이는 시스템 지표 특성상 관리 주기가 꽤나 빈번해 보였어. 아직 개인적인 추측일 뿐이지만 오래된 데이터들을 방출하는 방식으로 운영한다면 관리 주기를 늦출 수 있어보여.

토이 프로젝트 진행

사내에 필요한 기술이 무엇인지 고민하려고 토이 프로젝트를 만들고 있어. 제품에 적응하기 위해 유사한 환경을 구축했지.

• 프로덕션 환경에 데이터 기반 의사 결정이 가능하도록 서비스 지표 수집 도구 구성
• 프로덕션 환경에서 병목 지점을 사전 파악하기 위한 시스템 지표 수집 도구 구성

경계해야 할 부분 - 악동이 되지 말자.

책에서는 업무를 하면서 악동이 되지 말라고 해. 사내 표준에서 벗어나 새로운 도구를 사용한다면 추가 비용이 발생하기 때문이야.

표준을 변경 할 때 우선순위, 소유권, 비용, 구현 세부 내역 등을 고려할 필요가 있었어. 이미 팀내에 지표 대시보드, 로그 집계 도구가 존재하는데 서버 간 연결 상태 체크가 필요한지 진지하게 고민할 필요가 있었어. MSA로 구성된 제품이기 때문에 새로운 표준을 제시할 만큼 필요해보여.

마지막으로

책에서 지켜야 할 일과 피해야 할 일을 공유하고 있다. 그 중 필요한 부분만 발췌했어.

앞으로 신경써야 할 부분들을 정리했어.

• 빠른 학습
• 안정적이게
• 업무에 충실하자

첫 번째는 테스트 등을 건너뛰고 새로운 기술을 학습하는 데 초점을 맞추는 일이야. 새로운 기술을 학습해 공유하기 위해서는 선택과 집중이 요구 돼. 내가 선택한 건 새로운 기술을 학습하는 일이고 그에 맞게 집중해서 빠르게 팀에 공유를 진행했어.

두 번째는 되도록 검증된 기술을 사용하는 일이야. 새롭게 추가되거나 유지가 되지 않은 안정적이지 않은 라이브러리를 최대한 경계하고 있어.

마지막으로는 업무에 충실할 수 있도록 해야 해. 이 부분이 가장 걱정되는 부분이다. 흥미로 인해 우선순위가 낮은 업무부터 할 수 없는 노릇이야. 이런 작업들은 최대한 업무 외적으로 진행 중이야.

내가 잘하고 있는지 걱정이 많아. 모든 업무는 한 번 시작하면 다시 돌아가기 어려워보여서 더 신중해져. 그래도 신중함이 소극적인 행동으로 변하지 않도록 책을 읽으면서 신경쓰고 있어. 앞으로도 꼼꼼하면서도 넓은 발자취를 남겨보려 해.