Spring은 POJO 기반의 프레임워크라는 말을 들어보았을 것이다. 여기서 POJO의 의미는 무엇일까? POJO는 Plain Old Java Object의 약자로 말 그대로 해석을 하면 오래된 방식의 자바 오브젝트라는 말이다. 뜻이 애매하고 와닿지도 않는다. 이런 애매모호함은 다양한 해석을 만들었고, 포스팅마다 설명이 다르다.
결국 정확한 어원과 의미를 알아야겠다는 생각을 가지게 되었고, 다양한 자료들을 조사하기 시작하였다. POJO를 정확하게 이해하기 위해서는 단어 등장의 배경부터 알아야한다.
Spring에서의 핵심 개념인 의존성주입(Dependency Injection, DI)과 제어의 역전(Inversion of Control, IoC)에 대해 알아보도록 하자. 두 개념은 사실 거의 같은 의미라고 할 수 있다. 의존성 주입은 외부에서 두 객체간의 관계를 결정해주는 디자인 패턴이고, 이 객체들의 사용에 대한 책임이 프레임워크에 있다는 것이 바로 제어의 역전이기 때문이다. 즉, Spring은 IoC를 통해 객체들의 의존성을 분리시켜 결합도를 낮춰주는 역할을 하고 있다.
Spring Framework이 등장하기 전에는 EJB라는 기술을 통해 웹 애플리케이션을 개발하였다. 이 기술은 여러가지 복잡성으로 인해 사용하기 까다로웠고, 이러한 단점들을 보안하기 위한 기술들이 연구되었다. 그 과정에서 가장 호평을 받은 기술이 Spring Framework이다.
물론 Spring Framework가 처음부터 바로 나온것은 아니다. 2002년 로드 존슨은 자신이 출판한 저서(Expert One-on-One J2EE Design and Development)에 스프링의 핵심 개념과 기반 코드들을 소개하였다.
책 출간 직후 유겐 휠러와 얀 카로프가 로드 존슨에게 오픈 소스 프로젝트를 제안하였고, 전통적인 EJB라는 겨울을 넘어 새로운 시작이라는 뜻으로 Spring이라고 명칭을 짓게 되었다.
일반적으로 배치(Batch) 프로그램이라 하면, 일련의 작업들을 하나의 작업단위로 묶어 연속적으로 일괄처리 하는 것을 말한다.
예를 들어 하루전날의 집계된 요금데이터를 집계해야한다고 가정해보자. 이 업무는 하루에 1번만 수행하면 된다. 이를 위해 api를 구성하는것은 낭비가 된다. 또한 대량의 데이터를 처리하는 도중 실패가 된다면?? 이에 대한 처리를 어떻게 할 것인가?
이러한 단발성 대용량 데이터를 처리하는 프로그램을 배치프로그램이라 한다. 위에서 한 고민들을 살펴보면 단순히 집계하는 비즈니스 로직 이외에 고려해야할 부분이 많다는 것을 알 수 있다. 개발자가 비즈니스 로직 이외의 다른 부분들에 대한 고민을 덜어주도록 지원하는것을 프레임워크라 한다. 대표적인 프레임워크는 Spring이 있다.
시스템을 운영하는 입장에서 개발을 진행한다면 다양한 상황들을 가정하게 된다. 프로그램이 갑작스럽게 죽었을 경우, 서버가 다운됐을 경우, DDos 공격을 당하게 되었을 경우등이 가정되는 상황들이다. 이러한 이벤트에서도 시스템은 피해를 최소화할 수 있어야 한다. 이와 관련하여 과거 진행되었던 개발건 중 JDBC 타임아웃 설정에 관한 좋은 경험이 있어 공유하고 설명하고자 한다.
2020년 실시간으로 들어오는 다량의 데이터들을 DB에 적재하는 프로그램 개발을 맡게 되었다. Kinesis로부터 읽어들인 데이터를 DB에 적재하면 되는 단순할 수 있는 개발건이었지만, 기존에 운영중인 시스템의 구조를 바꾸는 일이라 영향도가 꽤나 큰 건이었다. 기능 개발은 단기간에 끝났지만 성능테스트와 발생할 수 있는 다양한 상황에 대응하는 기능들을 추가하는데 공수가 더 들어가게 되었다.
앞서 말했듯이 Grafana는 시계열 데이터를 시각화하는데 가장 최적화된 대시보드를 제공해주는 오픈소스 툴킷이다. 주로 InfluxDB, Prometheus, Graphite등의 시계열 데이터베이스와 함께 사용되며 실시간 데이터분석, 모니터링등에서 많이 사용되고 있다. 특히 자체적인 Alert기능 제공은 해당 툴을 선택하는데 가장 큰 이유가 되었다.
Grafana를 설치과정은 공식사이트를 통해 자세하게 나와있다.(https://grafana.com/grafana/download)
프로메테우스와 그라파나의 전체적인 아키텍처 및 설치과정을 알아보도록 하자
지난 게시물에서도 말했듯이 프로메테우스는 데이터소스, 그라파나는 시각화 툴의 역할을 각각 맡고 있다. 또한 프로메테우스는 서버 뿐만 아니라 다양한 노드(컴포넌트)가 수집한 데이터를 pull방식으로 가져오는 구조이다. 여기서 node는 프로메테우스에서 제공하는 서비스일 수도 있고 사용자가 직접 커스텀한 Exporter일수도 있다.
그 구조는 아래와 같다.
2018년 유지보수중이던 시스템이 기존 NT 서버에서 AWS로 모든 인프라를 옮기는 대공사를 진행하게 되었다.
인프라 전면전환 작업은 2년 가까운 시간이 되어서야 반영이 되었고, 2020년경부터 새로운 AWS인프라 위의 시스템을 유지보수하기 시작했다. 각종 문제들이 많이 생기기 시작했지만 가장 시급한 문제는 모니터링 시스템의 부재였다.
현재 내가 운영하고 있는 시스템은 실시간 대용량 트랜잭션을 처리하는 시스템으로, 장애발생시 5분 이내에 복구조치가 되도록 계약되어 있었고, 이를 위해서 모니터링 체계 구축은 필수적인 작업이었다.
많은 조사가 있었고 결국 우리는 프로메테우스와 그라파나라는 오픈소스를 사용하여 모니터링 체계를 구축하기 시작했다.
트랜잭션은 하나의 작업을 수행하기 위해 필요한 데이터베이스의 연산들을 모아놓은 것으로, 데이터베이서에서 논리적인 작업의 단위이며 장애가 발생했을 때 데이터를 복구하는 작업의 단위이다.
현업에서 쓰이는 개념으로 쉽게 설명하면 트랜잭션 단위로 데이터의 커밋과 롤백이 이루어진다.
2000년대 초 로버트 마틴이 명명한 객체 지향 프로그래밍의 다섯가비 기본원칙을 마이클 페더스가 원칙의 앞글자를 따서 다시 SOLID라고 소개하였다.
SOLID의 5대원칙은 다음과 같다.
이 다섯가지 원칙애 대해 자세히 알아보도록 하자