2024년도 보람차고 재밌는 한해였다. 회사에 입사하여 2년이 다 되어가기까지 과정을 되돌아보고, 내가 2024년에 세웠던 목표를 얼마나 이뤘는지, 2025년에는 어떤 목표를 설정하고 그 목표를 실행하기 위해 어떤 행동들을 실천해보면 좋을지 정리해보자.
PHP...🫠 를 걷어내기 위한 선행 작업으로 인증 로직 이관이 필요했다. 인증 로직 이관 뿐만 아니라, 보안적으로 더 안전한 방법으로 변경하기 위해 팀원분들과 다른 회사의 사례도 조사하면서 어떤 방식이 적절한지 논의하는 미팅을 많이 가졌다. 이런저런 방식으로 설계를 하며 각 아키텍쳐의 장단점에 대해서도 고민할 수 있었다. 팀원분들과의 티키타카가 재밌었던 1월이었다.
2월달에 발생한 이슈는 우리 API 서버에서 다른 API 서버를 호출하는 과정에서 다른 API 서버에서 응답 지연이 발생하자, 우리 서비스까지 장애 전파가 되면서 발생했다. 장애 전파 방지를 위해 서킷 브레이커까지 추가해놓았는데...
원인은 다른 API 서버 호출에서 지연이 발생하면 OSIV 설정으로 인해 DB 커넥션을 너무 오래 물고 있어, 커넥션이 부족해져서 우리 서버이 DB 로직에서 응답지연이 발생하며 장애가 전파되는 이슈였다. OSIV 설정 외에도 다른 API 서버 호출 시, readTimeout 을 기본값(6초)으로 둔 것도 장애의 원인중 하나였다.
서킷 브레이커 동작 테스트는 진행했었지만, 다른 서버가 바로 에러 응답을 주는 경우만 고려하고, 정상 응답은 주지만 지연 시간이 발생하는 경우는 고려하지 못 했다🥲 성능 테스트 시에는 다양한 케이스를 고려해야한다는 교훈을 얻을 수 있었다.
3월달에 발생한 이슈는 캐시 매니저를 로컬 캐시에서 Redis 로 변경하면서 필드 추가를 추가하면서 발생했다. 원인은 Spring 에서 제공해주는 ObjectMapper 에는 정의되어있지 않은 필드가 있어도 에러가 발생하지 않았지만, 내가 생성한 ObjectMapper 에는 에러가 나도록 설정 되어있었다🥲
원인은 운영환경 배포 방식으로 블루/그린 배포이면서, 50프로씩 전환하는 방식을 사용하고 있었는데 신규 형상으로 전환된 인스턴스에서 필드가 추가되어 저장되자, 전환되지 않은 구 형상 서버에서 에러를 뱉은 것이다. 구 형상까지 모두 전환되자 에러는 멈췄다. 배포 후에 에러가 발생하자 무조건 롤백만 생각했었는데, 더 큰일날 뻔 했다.🔥 (리더님 감사합니다)
개발환경 배포 방식은 100프로 비율로 롤링 업데이트 하는 방식이라 구형상과 신규 형상이 동시에 트래픽을 받는 케이스가 없었다. 현재는 Spring 에서 제공해주는 ObjectMapper 를 사용하고 있어 필드 추가 및 제거 시에 이슈가 없도록 설정해놓았지만, 위 장애 이후 로는 필드 변경 작업이 생기면 개발환경에서 배포하고 구 형상으로 롤백하여 이슈가 없는지 확인하고 있다.😇 장애가 발생했을 때, 에러가 난다고 무조건 롤백하는 것보다는 원인 파악을 최소한으로 하고 결정해야한다는 교훈을 얻었다.(물론 너무 긴박한 상황이겠지만)
장애 덕분에 성장한 2, 3월이었다... 후
PHP 는 프로세스 기반으로 동작하여, 풀 관리가 불가능하다. 그래서 트래픽이 많이 들어오는 시점에 DB DNS Cache 되어있는 IP 로 커넥션이 몰려 장애가 번번히 발생했다. DB 직접 붙는 로직을 API 로 이관하는 작업을 하였고, 그 결과로 DB Replica 인스턴스도 줄일 수 있어 뿌듯했다.💶
1월부터 설계했던 인증 개편 서비스 작업도 진행했다. 기존 방식에서 변경되는 부분이 많고, 클라이언트측에서 서버 응답값에 따라 어떻게 처리하고 있는지 확인도 필요해서 테스트가 쉽지 않았다.
그래도 PHP 에서 멀어지던 4, 5월이었다.
언젠가는 회사 기술 블로그에 글을 기재하고 싶다는 야망(?)이 있었는데, 실현했다. 글을 쓰면서, 동료분들의 피드백을 받을 수 있어서 감사한 시간이었고, MySQL MVCC 가 어떻게 동작하는지도 확인할 수 있어 뿌듯한 시간이었다.
파편화되어있는 회원 서비스를 합치기 위해 로직을 이관하는 작업을 진행했다. fade-out 할 서버와 유지할 서버를 나누고, 유지할 서버의 기능을 정의하면서 fade-out 서버의 기능들은 어떤 서버로 이관되어야 적절할지 논의하였다.
입사 전에는 MSA 가 모눌리식에 비해 무조건 장점이 있을 것이다 라고 생각했던 나의 편견이 바뀌는 시간이었다.
인증 서비스 개편하면서, 신규 인증 서비스가 기존 인증 방식보다 많은 트래픽을 받도록 설계되면서 내부 통신에서 효율적인 통신방식이 필요해졌다. gRPC POC 및 성능 테스트를 하며 기존 JSON 통신과의 차이를 정리하였다.
gRPC가 운영에 적용될 날을 기대했던 8월이었다.
구인증과 신인증이 동시에 운영되는 상황에서 어떻게 하위호환성을 유지할지에 대해 논의했다. 클라이언트에는 웹/웹뷰/앱 이 있는데, 앱 <-> 웹뷰 인터페이스에서 미처 확인하지 못한 케이스도 있어 논의할 부분이 계속 생겼다.
기존 EC2(도커 컨테이너에서 운영되지만)에서 ECS 로 전환하는 작업을 인프라팀과 진행했다. 인프라에 대한 공부도 할 수 있었고, k8s 도 궁금해졌다.🥹 인프라도 참 재밌는 것 같다.
인증 개편 서비스가 배포되었다. 혹여나 배포했는데 로그인이 풀린다거나, 로그인이 안 된다거나, 서비스 이용에 지장을 주는 등 이슈를 최소화하기 위해 배포는 새벽 2시에 진행했다.
다같이 저녁에 출근해서 마지막 만찬(?) 느낌으로 치킨도 먹고, 롤 내전 약속도 잡으면서 팀원분들과 더 친/편해졌다. 이런 저런 이슈가 있었지만, 롤백 없이 잘 마무리 되어서 참 뿌듯했던 날이었다.
배포 후에 ElastiCache 의 메모리 사용량이 생각보다 많아서 스케일업 작업이 필요했는데, 이때 어떻게 장애를 최소화하면서 작업을 진행할 수 있을지 고민이 많이 되었다. 우리는 Redis Client 로 Lettuce 를 사용하고 있는데, 특정 에러 발생시에 라우팅만 해줘도 장애를 줄일 수 있을 것 같은데, 컨트리뷰트 각을 봐야겠다는 생각이 들었다. (과연 할 수 있을 것 인가)
2024년에는 내부 구현 코드를 직접 확인하는 방식으로 딥다이브를 했다. Java 외에 PHP 나 C(아주 흐린눈) 라이브러리 구현 코드를 까서 보고, 정말 내가 생각한대로 동작하는게 맞는 건지 확인하였다.
내년에는 열심히 사고, 전시만 하면서 마음의 위안을 얻었던 책들도 좀 읽으면서 딥다이브 계속 했으면 좋겠다.
전보다 나의 의견을 잘 낼 수 있게 되었다. 팀원분들과 편/친해져서 나의 의견을 공유드렸을 때, 내가 의도한 대로 잘 전달되었을 거라는 확신도 생겼고, 나의 의견에 대한 명확한 피드백도 주실거라는 신뢰도 생겼다.
2023년에 세운 목표중에 실천해서(아직 갈길이 멀지만) 제일 뿌듯한 목표이다.
다른 분들이 이미 아실 내용이라고 해서 공유 못했던 것들을 공유하기 시작했다. 다른 팀원분이 공유하시기 전에 [쓸데없는 공유] 라는 제목으로 공유하면 마음 편하게 공유할 수 있다고 하셔서👍, 나도 시리즈를 같이 사용하기 시작했다. 전보다 마음 편하게 공유할 수 있게 되었다!
계속 가져가야 할 목표이다. 공식 문서, 책을 통해서도 딥다이브 하는 힘을 계속 길러보자.
ECS 전환을 하면서 인프라도 참 재밌는 것 같다는 생각이 들었다. k8s 공부를 도전해봤으면 좋겠다.
개발을 늦게 접했지만 개발자가 되어야 겠어 라고 결심했을 때, 다른 사람보다 늦었다는 생각에 계속 달려왔던 것 같다.
물론 개발과 일은 지금도 너무 재밌고, 나한테 긍정적인 영향을 주지만 2025년에는 내 삶을 풍요롭게 해줄 수 있는 다른 가치들도 찾아보는 시간이 되었으면 좋겠다.
2022년, 2023년, 2024년 내가 하고 싶었던 일을 하면서 너무 재밌고, 행복하게 보냈다. 2025년은 왠지 더 재밌을 것 같은 느낌이 든다! 2025년도 잘 부탁한다☺️