전체 글

[JAVA] Comparator

Comparator는 기본적으로 하나의 추상 메서드만을 가지는 함수형 인터페이스입니다. 그래서 사용을 위해 다음 이미지와 같이 선언되어있는 추상 메서드인 int compare(T o1, T o2)를 구현하면 됩니다. Comparator 인터페이스의 구현 내부를 살펴보면 compare 추상 메서드 외에도 다른 메서드들이 많이 선언되어 있는 것을 확인할 수 있습니다. 처음 해당 메서드들을 접했을 때는 메서드가 이렇게 많이 선언되어 있는데 왜 FunctionalInterface로 선언될 수 있는 건지 궁금했는데요. 기본적으로 Java에서 모든 클래스와 인터페이스는 Object 클래스에 선언되어 있는 메서드들을 상속받습니다. 또한 default 메서드 혹은 정적 메소드 같은 경우는 FunctionalInterf..

[Grafana Loki] 다중 서버 환경에서 그라파나 로키를 이용해 로깅하기

들어가면서 현재 진행중인 프로젝트에서 구성했던 서버를 Scale Out 하게 되었습니다. 여기에는 여러가지 배경이 있었는데요, 가장 큰 이유는 앞으로 있을 크고 작은 업데이트를 적용할 때 무중단 배포를 수행하기 위해 블루/그린 배포 전략을 적용하기 위한 서버 이중화가 필요했었다는 것입니다. 그에 따라 배포 시에는 블루/그린 서버로 사용되지만 평소에는 nginx 로드 밸런싱 기능을 활용하여 트래픽을 분산처리할 수 있도록 하여 리소스를 최대한 효율적으로 사용하고자 했습니다. 그런데 문제가 하나 있었습니다. 기존에는 단일 서버 환경에서 수행하던 로깅 데이터 모니터링이 정상적으로 동작하지 않는 문제였는데요. 그 원인은 서버가 이중화 되면서 한 곳에 저장되던 로깅 데이터가 각 서버에 나뉘어져 저장되기 시작했다는 ..

[최적화] Tomcat 스레드 풀 튜닝에 대한 고찰

들어가면서 서비스 API 서버를 구축하고 운영하면서 Tomcat 스레드 풀과 관련된 설정값들을 어떻게 튜닝할 수 있을지 생각해볼 기회가 생겼습니다. 막연하게 최적의 설정값을 찾으면 성능이 좋아지겠다고 생각은 했지만 왜 튜닝을 해야하는지, 어떻게 진행해야 하는지 감이 잘 잡히지 않았었습니다. 그래서 나름대로 백엔드 서버에서 Tomcat 스레드 풀 관련 설정값들을 왜 튜닝해야 하는지, 어떻게 튜닝할 수 있는지를 고민해보고 정리해봤습니다. 스레드 풀의 크기를 적절하게 조절해야 하는 이유 스레드를 생성하는 것은 비용이 많이 드는 작업입니다. 새로운 스레드를 위한 메모리 공간을 할당하는데 이 메모리 공간은 JVM이 할당받은 메모리 공간을 점유하게 됩니다. 이 때 기본적으로 1MB의 메모리 영역만큼을 하나의 스레드..

[DB] 인덱스 기본 개념과 클러스터링, 논클러스터링 인덱스

들어가면서 프로젝트의 기본적인 성능 최적화를 위해 사용중인 데이터베이스에 인덱스를 적용해야 할 일이 생겼습니다. 그 전에 인덱스의 간단한 기본 개념과 클러스터링, 논클러스터링 인덱스에 대해 정리해보려합니다. 인덱스 기본 개념 및 용어 정리 인덱스란 데이터베이스에서 원하는 값을 빠르게 찾기 위해 사용하는 자료구조입니다. 인덱스를 이용하면 데이터베이스 테이블에 대한 검색 성능을 향상시킬 수 있으며, where 절 등을 통해 활용됩니다. 인덱스의 특징 인덱스는 항상 최신의 정렬상태를 유지합니다. 인덱스도 하나의 데이터베이스 객체입니다. 데이터베이스 크기의 약 10% 정도의 저장 공간을 필요로 합니다. 자주 사용되는 용어 정리 페이지 : 데이터가 저장되는 단위 (MySQL 에서는 16KB) Full Table ..

[우아한테크코스] LV3 - 4차 스프린트 회고

들어가면서 4차 스프린트는 하루스터디 서비스 사용자들이 그동안 진행했던 스터디 기록을 모아볼 수 있는 기능을 제공하기 위한 로그인 기능을 구현하는데 집중했던 기간이었다. 과거에 진행했던 스터디 기록을 다시 조회할 수 없다는 것이 서비스 사용자들에게 가장 큰 불편함으로 다가올 것이라고 판단해서 최우선적으로 구현을 하기로 결정했다. 이와 별개로 운영중인 서비스에서 발생하는 로그들을 전혀 확인할 수 없는 문제가 있었는데 이를 해결하기 위해 로깅 시스템을 구축했어야 했다. 무엇 하나 쉽지 않았던 굵직했던 주제들이라 데드라인을 맞추기 위해 팀 내에서도 분업을 해서 정신없이 진행했었다. 이번 회고에서는 바쁘게 진행했던 작업들을 되짚어보면서 그 과정들을 기록해놓고자 한다. 4차 스프린트 Oauth2.0을 이용한 로그..

[Logging] Slack 알림 메세지 Logger 구현하기

들어가면서 기존에 하루스터디 팀 프로젝트를 진행하면서 스프링 콘솔에서 출력되던 스프링 자체 로깅 메세지와 HTTP 웹 요청 / 응답 메세지 값들을 로깅하고자 했습니다. 이를 수행하기 위해 LogBack에서 기본으로 제공하는 Appender 중 RollingFileAppender를 채택해서 사용했습니다. 기본적으로 서버에 파일로 로깅 데이터를 남긴 후 그라파나로 시각화하여 로그를 조회할 수 있는 시스템을 구축하는 것이 최종적인 목표였기 때문입니다. 그러던 중 서버에서 에러 로그가 발생하면 자동으로 백엔드 팀 슬랙에 알림이 오도록 기능을 추가하고 싶어졌습니다. 현재는 서버에서 에러가 발생했는지 여부를 확인하기 위해 팀원들이 직접 그라파나에 접속해서 확인해야 했는데 이를 매번 주기적으로 확인하기란 쉽지 않습니..

[우아한테크코스] LV3 - 3차 스프린트 회고

들어가면서 3차 스프린트는 서비스 배포와 내부 설계 변경에 집중했던 기간이었다. 처음엔 프론트엔드와 백엔드 모두 기능적으로는 구현이 완료된 상태였기에 배포 과정에서 큰 문제는 없을 것이라 판단했었다. 그러나 예상과는 다르게 기본적인 비즈니스 플로우의 시작점에서부터 에러들이 발생하기 시작했다. 이러한 에러들을 해결하며 기능 연동을 위해 노력하는 한편 백엔드 팀에서는 내부 구조에 대한 논의와 변경이 많이 이뤄졌었는데 이를 정리하고자 한다. 3차 스프린트 CloudFlare 캐시 삭제 문제 하루스터디 팀에서는 프론트엔드와 백엔드 별 기능 구현이 1차적으로 완료되고 나서 정식 배포를 위해 기능 연동을 진행했다. 실제로 연동이 잘 되었는지 확인하기 위해 개발 서버에 배포를 완료한 후 배포된 서비스에 접근해서 직접..

[우아한테크코스] LV3 - 2차 스프린트 회고

들어가면서 4차 스프린트가 진행중인 현재 2차 스프린트 회고를 진행해보고자 한다. 노션에 개인적으로 2차 스프린트에 대한 회고를 메모형식으로 정리해두기는 했었으나 프로젝트 일정이 더 급하다는 이유로 포스팅을 미뤄뒀었다. 시간이 더 흘러서 적어뒀던 메모를 보고도 기억이 나지 않기 전에 스스로를 위해 포스팅한다. 2차 스프린트는 뒤쳐지지 않기 위해 무던히 애를 썼던 기간이었다. 첫 주부터 예비군 훈련으로 내리 4일을 빠지게 되었기에 그 동안 팀에서 진행한 업무들을 동기화하는데 더 노력을 기울일 수 밖에 없었다. 다행인지 불행인지는 모르겠지만 4일 동안 1차 스프린트 데모데이 피드백을 중심으로 서비스의 방향성을 뒤집는 기획 회의만 이뤄졌었다. 개발적인 부분이 먼저 시작되었으면 더 쫓아가기 힘들었을텐데 딱 캠퍼..