코루틴이 대체 뭔데최근 컴퓨터 밑바닥의 비밀 에 대한 책을 읽으면서 고급 프로그래밍을 위한 공부를 하던 도중 동시성 프로그래밍에 대한 내용과 코루틴에 대한 부분이 등장했고 해당 챕터를 읽으면서 이해를 하는데 있어서 꽤나 애를 먹었다. 동시성 프로그래밍을 달성하기 위한 개념적인 것들과 코루틴에 대한 기본적인 이해는 어렵지 않다고 하지만 실질적인 동작 흐름을 시간단위로 쪼개서 생각을 했을 때 과연 어떠한 방식으로 동작하는 것인가 에 대한 부분을 정확하게 정의하고 넘어가야 겠다는 생각을 하게 되었고 시간 단위로 쪼개서 프로세스의 실행흐름을 살펴보는 과정을 가지기로 했다. 우선 코루틴을 이해하기 위해서 가장 중요한 부분은 동시성 프로그래밍과 병렬성 프로그래밍에 대한 이해에서 부터 시작된다고 생각한다. 동시성 프..
개발중인 서버의 특정 프로세스의 기능은 네트워크의 패킷을 감시하고 특정 프로토콜을 필터로 각 서버에서 보내는 데이터의 일관성이 유지되는지를 확인하는 것 이다. 상위서버에서 gateway 로 데이터를 요청하면 gateway 는 하위서버에 요청을 보내고 하위서버 에서는 gateway로 응답을, 그리고 응답받은 gateway 는 상위 서버에 맞는 데이터로 변환하여 응답을 보내게 된다.이 상황에서 하위 데이터와 상위 데이터가 쌍을 이뤄 일관성을 유지하는지 실시간 패킷의 이동을 감시하여 해당 값를 분석하여 확인하는 것 이다.해당 프로세스는 위와 같은 형태로 구성되어 있다.감시 대상의 패킷이 발생하면 감시 프로세스가 동작하고 해당 데이터에 대한 값을 DB 와 내부 캐시로 반영을 하고 특정 조건을 만족 할 경우 웹 ..
갑작스럽게 상승하는 cpu 사용률 혹은 메모리를 어떤 방식으로 확인 할 수 있을까?그리고 어떤 과정을 통해서 위와 같은 상황이 발생하는 것 일까? 우선적으로 성능을 측정하기 위해서 우리가 가장먼저 해볼 것은 각 메서드의 실행 시간이다.메서드가 실질적으로 실행되는 시간을 측정하여 특정 로직의 필요 이상의 시간이 발생 한다면 메서드를 수정하거나 혹은 다른 방법을 통해서 문제를 해결하는 것이 기본이다. 실제로 경험 해 본 결과 대부분의 문제는 DB 에 접근하는 레포지토리 서비스 관련 이슈가 많은 것 같다. 글 쓰는 순서.최근에 성능측정어떤 방식으로 성능 측정을 진행 하는지실제로 효과가 있었는지 visualVM 을 찾기 전 까지의 과정을 그대로 서술 하고 이 어플리케이션을 통해서 확인 할 수 있었던 부분 ..
Null 처리에 관한 탐구와 Optionalnull 처리를 어떤 방식으로 진행 해야 할 것인가에 대한 부분은 언제나 고민이 된다.함수형 프로그래밍을 도입하며 객체지향적 개발을 지향하는 현 시점의 프로그래밍 기법이 과연 null 을 명시적으로 처리하는 완벽한 방법을 제공하지 않는다는 것이 어쩌면 놀랍기도 하다.물론 null 처리를 위한 Optional 이라는 강력한 기능이 추가되었지만 이 기능이란것이 생각보다 많은 부분에서 사용되지 않는다는점, 이미 진행된 프로그래밍에 적용함으로써 일관성을 해칠 수 있다는 점에서 사용을 꺼리게 된다.또한 애초에 모든 null 처리를 Optional 로 진행하는 것을 권장하지 않다 보니 명시적 null 처리를 진행해야 하는 부분이 반드시 발생한다는 것을 생각해보면 Optio..
이슈 어플리케이션을 개발하던 도중 특정 프로세스에서 급격하게 느려지는 현상을 발견했다.어떠한 특정 로직에서 병목현상이 발생하거나 혹은 필요없는 로직을 타고 있다는 의심이 들었고 각 메서드마다 성능을 측정해봐야 한다는 생각이 들었다. 가장먼저 떠오른 방법은 AOP 를 이용하는 방법 이었다.AOP 를 이용해서 각각의 메서드를 측정하여 평균 시간이 오래 걸리는 로직순서대로 하나씩 확인해 볼 예정이었다. 문제해결 1. 리플렉션과 커스텀 애노테이션 모든 메서드의 성능을 확인할 필요는 없다. 특정 프로세스에서 느려지는 현상을 확인하기 위해 모든 메서드에 AOP를 적용하게 된다면 전체적으로 성능이 느려질 것 이고 그에 따라서 제대로 된 성능을 확인하기 어려울 것이라고 생각했다. 제한된 컴퓨팅 파워에서 성능 측정을 위..
기존의 정의된 일련의 로직을 수정하는 것은 어렵지만 그 중에서도 내가 가장 힘들었던 부분은 객체를 완전히 재정의 하는 부분이다.물론 하나의 객체만 재 정의 한다면 크게 문제가 되지는 않겠지만 여러객체들이 서로 상호작용하거나 혹은 복잡한 상속 관계를 포함하고 있다면 얘기는 달라진다. 최근 하나의 테이블이 너무 많은 정보를 포함하고 있다는 생각이 들어서 리팩토링을 하기로 결정했고 어떠한 방식으로 테이블을 쪼갤 수 있을까를 고민했다. 테이블의 구조는 다음과 같다A 부터 G 까지의 7가지 상태를 모두 단 하나의 테이블로 표현 할 수 있었다.각 상태는 target 이라는 Enum 타입에 따라서 각자 상태의 종류를 구분 할 수 있는 형태였다.target 에 따라서 필요한 필드 값이 모두 다르기 때문에 단일 테이블에..
애플리케이션 구조현재 개발중인 서버는 캐시 서버가 따로 존재하지 않는다.따라서 캐시관리를 위해 코어 서버에서 직접 캐시를 관리해야 하고 그 과정에서 싱글톤 패턴을 이용해 각 모듈에 맞는 캐시를 따로 관리하고 있다. 각각의 모듈을 위와 같이 서로다른 형태의 캐시를 가지고 있고 각 모듈은 각각의 캐시 상태를 통해 복잡한 로직을 수행하고 있다. 최근에 모듈A 에서 모듈B의 캐시를 참조해야 하는 상황이 발생했는데 이 부분을 어떻게 해결해야 할 것인지를 고민했다.개발을 하다보면 하나의 책임만을 수행할 수 있도록하는 단일 책임 원칙을 고수하는것이 원칙인데 이 부분을 지키자니 작은 곳에서 사용하는데 너무 큰 자원을 낭비해야 하는 상황이 발생했고 결국엔 그 부분만 예외적으로 참고할 수 있도록 해당 원칙을 무시하기로 ..
트랜잭션트랜잭션은 데이터베이스의 상태를 변경하기 위해서 실행되는 단위를 말한다.애매하다.최근 이 트랜잭션에 대한 혼동이 있어서 버그가 발생했고 그 이슈를 해결하면서 다시 한 번 트랜잭션에 대한 개념을 돌이킬 수 있었다. 데이터베이스의 상태를 변화시킨다는 것은 한 문장의 질의어를 수행하는 것을 의미 하지 않는다.상태를 변경하기 위해 실행되는 단위는 하나의 질의어로 수행가능할 수 있지만 두개 이상의 질의어 혹은 여러개의 질의어를 통해서 수행 될 수 있다는 것을 혼동하면 안된다. 버그 발견어떠한 상태를 확인하는 로직이 있었다.1초에 한번씩 스케줄을 돌면서 상태를 확인하고 비 정상상태가 판단 되었을 경우 소켓을 통해 그 결과를 웹에 반영하는 형태의 구조였다. 한 번 특정 상태를 유지하면 더 이상 웹소켓에 반영하..
