개발중인 서버의 특정 프로세스의 기능은 네트워크의 패킷을 감시하고 특정 프로토콜을 필터로 각 서버에서 보내는 데이터의 일관성이 유지되는지를 확인하는 것 이다. 상위서버에서 gateway 로 데이터를 요청하면 gateway 는 하위서버에 요청을 보내고 하위서버 에서는 gateway로 응답을, 그리고 응답받은 gateway 는 상위 서버에 맞는 데이터로 변환하여 응답을 보내게 된다.이 상황에서 하위 데이터와 상위 데이터가 쌍을 이뤄 일관성을 유지하는지 실시간 패킷의 이동을 감시하여 해당 값를 분석하여 확인하는 것 이다.해당 프로세스는 위와 같은 형태로 구성되어 있다.감시 대상의 패킷이 발생하면 감시 프로세스가 동작하고 해당 데이터에 대한 값을 DB 와 내부 캐시로 반영을 하고 특정 조건을 만족 할 경우 웹 ..
기존의 정의된 일련의 로직을 수정하는 것은 어렵지만 그 중에서도 내가 가장 힘들었던 부분은 객체를 완전히 재정의 하는 부분이다.물론 하나의 객체만 재 정의 한다면 크게 문제가 되지는 않겠지만 여러객체들이 서로 상호작용하거나 혹은 복잡한 상속 관계를 포함하고 있다면 얘기는 달라진다. 최근 하나의 테이블이 너무 많은 정보를 포함하고 있다는 생각이 들어서 리팩토링을 하기로 결정했고 어떠한 방식으로 테이블을 쪼갤 수 있을까를 고민했다. 테이블의 구조는 다음과 같다A 부터 G 까지의 7가지 상태를 모두 단 하나의 테이블로 표현 할 수 있었다.각 상태는 target 이라는 Enum 타입에 따라서 각자 상태의 종류를 구분 할 수 있는 형태였다.target 에 따라서 필요한 필드 값이 모두 다르기 때문에 단일 테이블에..
애플리케이션 구조현재 개발중인 서버는 캐시 서버가 따로 존재하지 않는다.따라서 캐시관리를 위해 코어 서버에서 직접 캐시를 관리해야 하고 그 과정에서 싱글톤 패턴을 이용해 각 모듈에 맞는 캐시를 따로 관리하고 있다. 각각의 모듈을 위와 같이 서로다른 형태의 캐시를 가지고 있고 각 모듈은 각각의 캐시 상태를 통해 복잡한 로직을 수행하고 있다. 최근에 모듈A 에서 모듈B의 캐시를 참조해야 하는 상황이 발생했는데 이 부분을 어떻게 해결해야 할 것인지를 고민했다.개발을 하다보면 하나의 책임만을 수행할 수 있도록하는 단일 책임 원칙을 고수하는것이 원칙인데 이 부분을 지키자니 작은 곳에서 사용하는데 너무 큰 자원을 낭비해야 하는 상황이 발생했고 결국엔 그 부분만 예외적으로 참고할 수 있도록 해당 원칙을 무시하기로 ..
트랜잭션트랜잭션은 데이터베이스의 상태를 변경하기 위해서 실행되는 단위를 말한다.애매하다.최근 이 트랜잭션에 대한 혼동이 있어서 버그가 발생했고 그 이슈를 해결하면서 다시 한 번 트랜잭션에 대한 개념을 돌이킬 수 있었다. 데이터베이스의 상태를 변화시킨다는 것은 한 문장의 질의어를 수행하는 것을 의미 하지 않는다.상태를 변경하기 위해 실행되는 단위는 하나의 질의어로 수행가능할 수 있지만 두개 이상의 질의어 혹은 여러개의 질의어를 통해서 수행 될 수 있다는 것을 혼동하면 안된다. 버그 발견어떠한 상태를 확인하는 로직이 있었다.1초에 한번씩 스케줄을 돌면서 상태를 확인하고 비 정상상태가 판단 되었을 경우 소켓을 통해 그 결과를 웹에 반영하는 형태의 구조였다. 한 번 특정 상태를 유지하면 더 이상 웹소켓에 반영하..
최근 테이블 업데이트 과정에서 시간단축을 위해서 벌크 쿼리를 사용한 적이 있다. 그 과정에서 String 으로 구성된 컬럼 하나에 like 를 조건으로 사용해 시간결과를 확인해보았고 도저히 받아들일 수 없는 결과를 맞이했다. 벌크 연산 쿼리가 Querydsl 보다 훨씬 더 느린 결과가 나온것이다. 왜지?!, 바로 사수 개발자 분께 물어보니 쿼리를 보고 바로 문제를 짚어주셨다. "LIKE 연산을 수행하네요, = 로 변경하세요" 1차 의문 LIKE 와 = 의 연산 알고리즘은 다른 방식인가? LIKE 문은 %와 같이 사용하지 않는다면 결과적으로 동일한 문자열을 서칭하게 되는데 이것은 = 문의 사용과 동일한 결과 값을 보내준다. 실제로 둘의 알고리즘이 동작하는 차이를 알아보자 했고 하루동안 계속 찾아본 결과 D..
자바 Reflection 기능. 특정 DB 테이블을 csv 파일로 변환하는 도중 테이블의 필드 정보를 사용해야 할 경우 Reflection 기능을 통해서 확인 할 수 있다. Spring JPA를 사용하다 보니 DB 테이블을 직접 생성하지 않고 @Entity 어노테이션을 통해서 생성을 하면 자바의 Reflection 기능을 통해 쉽게 테이블의 컬럼 정보 (Class 정보)를 가져올 수 있는 것이다. 기능확인을 위해 Reflection 이라는 클래스를 만들었다. @NoArgsConstructor @AllArgsConstructor @Entity public class Reflection { @Column(name = "integer_num") private Integer integerNum; @Setter ..
개발 공부를 할 때 작은 프로젝트단위에서만 개발을 해서그런지 if else 문을 많이 사용하긴 했지만 switch case 문은 한 번도 사용해 본 적이 없었다. 굳이 사용을 할 필요성이 없었기 때문이다. 그러다 최근 실무에서 패킷 분석을 하던 도중 switch case 문이 많은 곳에서 사용된다는 것을 확인했고 문뜩 if else 문과 비교분석을 통해서 정리를 해봐야 겠다는 생각이 들었다. 우선 구글을 돌아다녀서 확인 한 결과 가장 많이 나온 얘기는 if else 와 switch case 둘 모두 전체 프로그래밍의 성능에 큰 차이가 없기 때문에 의미에 따라 사용하는것이 좋다는 것이다. 물론 switch case 를 통해서 나타낼 수 없는 경우에는 당연히 if else를 사용하겠지만 둘 모두의 문법에서 ..
