시간과 공간 그리고 진실의 방

0. 들어가면서

프로세스(Process)는 개발을 하는 사람들이 가장 많이 들어보는 단어 중에 하나라고 생각합니다.

사실 개발을 하는 사람 뿐만 아니라, 일상 생활에서도 프로세스라는 말은 참 많이 쓰죠.

그런데 과연 '프로세스'란 정확히 무엇을 의미할까요?

1. 프로세스(Process)

Process: A process is a program in execution which then forms the basis of all computation.

위 정의처럼 프로세스는 실행 중인 프로그램을 의미합니다. 그렇다면, 실행 중인 프로그램이라는 것은 도대체 무엇으로 구성되어 있을까요? 

프로세스는 크게 이미지(Image) 영역과 컨텍스트(Context) 영역으로 구분되어 있습니다. 프로세스의 컨텍스트 영역에는 Data Reigster, $PC, $SP 등의 값이 저장되고, 프로세스의 이미지 영역에 우리가 흔히 말하는 스택, 힙, 데이터, 코드 영역이 존재합니다.

아래 그림을 통해 프로세스의 이미지 영역을 자세히 들여다 보겠습니다.

프로세스 이미지(Image)

프로세스의 이미지(Image) 구조는 위와 같습니다. 제일 작은 메모리 주소 부분에는 Text(Code) 영역이 존재하는데, 여기에는 실행 가능한 코드들이 컴파일한 기계어 형태로 저장됩니다.

그리고 그 위에는 초기화해서 변하지 않는 변수를 저장하고, 다시 그 위에 아직 초기화하지 않은 전역 변수나 정적(static) 변수를 저장합니다. 이 두 부분을 엄밀히 구분할수도 있는데, 여기서는 Data 영역으로 표시되어 있습니다. 

Stack 영역에는 지역 변수, 임시 변수, 매개 변수, return value, return address 등이 저장됩니다. 여기서 return address란 어떤 함수를 호출하고 그 결과를 다시 main이나 다른 함수에 return해야 할 때, 돌아갈 곳을 명시해주는 주소를 담는 공간입니다.

참고로 Stack 영역은 컴파일 타임에 크기가 결정되기 때문에 무한히 할당할 수가 없습니다. 때문에 재귀함수가 너무 많이 호출되거나 함수가 지역변수를 너무 많이 가지고 있어서 Stack 영역을 초과하게 되면 StackOverflow에러가 발생하기도 하죠.

Heap 메모리 영역에는 프로그램 런타임에 동적 메모리가 할당됩니다. 쉽게 말해 이 영역에는 객체의 데이터가 저장된다고 볼 수 있는데요. 스택 영역에는 이 객체들에 대한 참조값이 저장되어 있어서 이를 통해 힙 영역에 존재하는 객체에 접근할 수 있게 됩니다.

스택 영역과 힙 영역에 대해서는 JVM의 GC를 설명할 때 자세히 다룬 적이 있어서 참고하실 분은 아래 링크를 확인해보시면 좋겠습니다.

💡 2. PCB(Process Control Block)

위에서 우리는 프로세스를 실행 중인 프로그램이라고 했습니다. 그런데 이를 조금 다르게 정의해보면 프로세스는 곧 실행 가능한 PCB(Process Control Block)를 가진 프로그램이라고 볼 수도 있는데요.

PCB는 운영체제가 프로세스를 제어하기 위해 정보를 저장해 놓는 곳으로 프로세스의 상태 정보를 저장하는 구조체라고 생각하면 됩니다.

프로그램을 돌아간다는 것은 많은 수의 프로세스가 돌아간다는 것을 의미합니다. 그리고 이러한 프로세스들은 Time Sharing을 하거나 서로 참조하는 등으로 컨텍스트 스위칭(Context Switching)을 하게 되는데, 이를 위해서 각 프로세스의 상태를 저장할 공간인 PCB가 필요한 것입니다.

PCB는 아래 그림과 같은 구조로 생겼습니다.

PCB

Process ID는 프로세스의 고유 번호를 의미하며 Process State는 프로세스의 준비, 대기, 실행 등의 상태 정보를 가지고 있습니다.

Process Counter(Pointer)는 프로세스가 다음에 실행할 명령어의 주소를 저장하고 있으며 Register information은 레지스터는 메모리 연산을 처리하기 위해서 임시로 가지고 있는 기억 공간인데 CPU옆에 붙어 있습니다.

Scheduling information은 자신이 CPU스케쥴링에서 어떤 우선 순위를 가지고 있는지에 대한 정보이며 Memomry related information은 할당된 자원의 정보를 가지고 있죠.

또한 Accounting information에는 프로세스를 처리하고 있는 CPU의 사용시간, 실제 사용된 시간 등이 담겨있으며 Status information related to I/O는 입출력 상태 정보를 가지고 있습니다. 프로세스에 할당된 입출력장치의 목록이나 열린 파일 목록 등을 저장하고 있죠.

이렇게 PCB에는 프로세스별로 고유한 값들이 저장되어 있고, 이 값들을 바탕으로 여러 프로세스들을 오가며 전체적인 프로그램이 작동하게 됩니다.

위 PCB의 구조를 하나하나 외우지는 말고 프로그램이 돌아가는 데 프로세스들의 개별 정보가 담겨있다고 이해하면 될 것 같습니다.

3. Context Switching

3-1. 왜 필요한가?

Context Switching은 한 개의 CPU가 하나의 프로세스만 처리할 수 있기 때문에 필요해진 개념입니다.

CPU가 하나의 프로세스를 끝날 때까지 계속 처리하고, 그 다음에서야 다음 프로세스를 처리할 수 있다면 프로세스들 간의 참조도 이루어질 수 없고, 프로세스 간 병목 현상도 심화됩니다. 

따라서, CPU는 실행 중인 프로세스를 계속해서 변화시키는데 이 과정을 컨텍스트 스위칭(Context Switching)이라고 합니다.

3-2. 어떻게 이루어지는가?

위에서 살펴봤듯이, PCB는 Process Counter에 다음에 실행할 프로세스의 주소를 가지고 있는데요. Context Switching이 발생할 때는현재 프로세스의 PCB에서 다음 프로세스의 PCB를 찾아서 레지스터에 적재하고, CPU가 이전에 진행했던 과정을 이어서 진행하게 됩니다.

그런데 프로세스는 각 독립된 메모리 영역을 할당받았기 때문에 공유하는 메모리가 존재하지 않습니다.

따라서 Context Switching이 발생할 때 (1) 캐시 초기화, (2) 메모리 매핑 초기화, (3) 커널 모드로의 진입이라는 세 가지 비용을 항상 수반하게 되고, 이로 인해 큰 오버헤드가 발생하게 됩니다.

이 후 포스팅에서 살펴볼 멀티쓰레딩은 메모리 영역의 공유를 통해 Context Switching 오버헤드를 줄일 수 있기 때문에 더 빠른 응답 시간을 제공할 수 있게 됩니다.

4. 프로세스의 상태(Status)

한편, 우리의 프로그램은 여러 프로세스를 동시에 처리해야 하기 때문에 프로세스는 실행되는 동안 아래 그림처럼 계속해서 상태가 변합니다. 

프로세스 상태

프로세스가 생성된 상태(New), CPU를 할당받기 위해 준비중인 상태(Ready), 어떤 이벤트를 기다리고 있는 상태(Blocked(Waiting)), Instruction(명령어)가 실행되고 있는 상태(Running), 종료 상태(Terminated)가 있죠.

예를 들어보겠습니다. 이전 시간에 인터럽트에 대해 공부했었는데요. 우리가 System Call을 호출하면 해당 프로세스는 Blocked 상태로 변하고 OS는 커널 모드로 진입하게 됩니다. 그러면 그동안 CPU는 다른 Process를 돌리고 있습니다. System call을 호출하는 동안 CPU가 아무일도 하고 있지 않으면 낭비이기 때문이죠.

시간이 지나 System operation이 끝나면 다시 CPU에게 Interrupt를 발생시킵니다. Interrupt를 받은 CPU는 현재 실행 중인 프로세스를 멈추고, 커널 모드로 돌아가 Interrupt를 Handling하죠. 그리고 이전 프로세스를 다시 Ready 상태로 돌려놓습니다. Ready 상태의 프로세스는 우선 순위나 CPU 점유 상태에 따라 다시 Running 상태로 될 준비를 하죠.

이러한 내용을 그림으로 정리해보면 아래와 같습니다.

프로세스가 Ready Queue에 들어와서 다시 재가동되는 것은 CPU 스케줄링에 의해 좌지우지되는 내용인데요. 이 부분에 대해서는 CPU Scheduling에 관한 글에서 설명하겠습니다.

5. Mode Switching VS Context Switching

한편, 이전 글에서 공부했던 것처럼 유저모드~커널모드 간의 스위칭은 세 가지 상황에서 일어납니다.

1.  Hardware Externel interrupt(Timer, I/O Interrupt)
2.  Software Exception(Page fault, invalid operations..)
3.  System Call(I/O Operation, fort()..)  

그리고 이렇게 유저모드와 커널모드 간의 스위칭 과정을 모드 스위칭(Mode Switching)이라고 하는데요. 모드 스위칭은 위에서 살펴본 프로세스 간의 Context Switching과는 다른 개념입니다.

모드 스위칭이 일어날 때는 현재 프로세스의 상태를 저장하고, 프로그램 카운터(PC)를 다음 작업을 할 주소값으로 세팅합니다. 그리고 커널 모드로 전환하여 수행해야 하는 Instruction을 핸들링하죠.

한편 Context Switching에서는 진행 중이던 프로세스의 상태를 기록하고, 불러오는 프로세스의 이전 상태를 복원해야 합니다. 또한 각 프로세스를 저장할 큐의 메모리 위치를 선점하는 등의 작업이 필요하죠. 즉, 프로세스의 상태를 변화시키는 과정 전체를 의미하기 때문에 모드 스위칭보다 조금 복잡합니다.

그리고 Context Switching은 모드 스위칭의 결과로 발생합니다. 즉, 인터럽트(Interrupt), Exception, System Call 등이 일어나면 Mode Swtiching이 일어나고 이에 따라 필요 시 Context Switching이 일어나는 것이죠.

그럼 Context Switching의 과정을 살펴볼까요? 위에서 살펴본 PCB 구조와 프로세스 상태 변화 그림을 같이 보겠습니다.

1. Context Switching이 일어나면 다른 프로세스로 넘어가기 위해 프로그램 컨텍스트(Program Context)를 바꿉니다.

2. 그리고 현재 프로세스의 상태(Running)를 blocked, ready, exit 등으로 바꿉니다.

3. Process Control block(PCB)를 적절한 큐로 이동시킵니다.

4. 프로세스 스케쥴링에 따라 다음에 수행할 프로세스를 선정합니다.

5. 수행할 프로세스의 PCB를 적절한 큐로 이동시킵니다.

6. 수행할 프로세스의 Process State를 Running으로 변환합니다.

7. 수행할 프로세스의 이전까지 작업했던 Program context를 복원하고 작업을 수행합니다.

위와 같은 방식으로 프로세스의 스위칭이 일어나게 됩니다. 이해가 되셨나요?

이렇게 이번 시간에는 프로세스란 무엇인지부터 프로세스의 구조와 PCB, 프로세스의 상태 및 스위칭 과정에 대해 살펴봤습니다.

다음 시간에는 본격적으로 OS가 어떻게 동작하는지 알아보도록 하겠습니다.

감사합니다.

https://studyandwrite.tistory.com/5

발생했던 Shop 에서의 Session 동기화 문제를 정상적으로 수정했다.

일단 내가그린기림기르김그림 을 기반으로 설명해보자면

결과적으로 예전에 China Developer 에 의해서 Credential Key가 노출되서 이 부분에 대해서 변경하고 재배포 하는 과정에서 Scheduler 를 가동할 수 있는 곳이 따로 있었던 곳을 발견했다.

즉  tools 인스턴스 안에서도 가능하고, scheduler 인스턴스 안에서도 가능했던 것이다

문제 1. Ranking Serviece 및 Score 부분에서 2번 집계되는 현상 발생

자 이 부분에서 해결하기 위해서, scheduler 인스턴스 내에서 관리할 수 있도록 해당 부분에서 daemon을 activate시키고

tools 에 있던 scheduler 는 deactivate 시키는 것을 했었다. 

그 이후에 참조를 이루는 부분에서 scheduler 에 있는 부분에서 sync 가 정상적으로 이루어지지 않았으니

tools 에 기반하는 scheduler 에서 정상적으로 작동할 수 있냐는 의문을 가졌던 것이다.

그렇게 판단한 기반 근거를 살펴보자

1. scheduler 내에서 사용되던 log 가 2020 ~ 2021년 사이에는 존재했으나, 그 이후에는 로그 기록이 확보되지 않았다. 물론 이러한 부분에서 log rotate 가 작동된 것일 수 있겠으나, 이러한 부분에서 deprecated 됬었을 수 있다는 것을 추론 할 수있다.

2. tools 내의 scheduler 에서 가동되던 log를 살펴보면 2022년 6월 22일 정도를 마지막으로 이루어졌다가 이후 약 2~3개월의 Gap 이 있다가 다시 3월까지 이루어졌었다.

이러한 부분에 의하여 Scheduler 가 고도몰의 Custom Session Method 를 연결하여 지속적으로 연결을 성립하는 역할을 한다면, 충분히 참조될 만 하다는 것이다.

그렇다면 여기서 놓치고 있는 것이 무엇이였을까?

추측 가능한 결론

1. 아마도 EIP 에 의해서 Static IP가 주어지고, 해당하는 부분에 의해서 지속적으로 연결을 수립하여 생기는 과정 중에 tools 에 고정해놨을 반면에 scheduler 에서는 EIP 가 배정되지 않았던 것과 동시에 별도의 IP가 존재하는 부분

하지만 이러한 부분에서 약간의 추론을 더 생각해보자면, 내부적으로 ELB를 호출해서 rest 쪽을 호출했었고, 이러한 부분에 의하여 rest의 End-Point 를 호출하기 때문에 별도의 Scheduler 에 의한 부분을 찾지 못했던 것이다.

추가적으로 찾아봐야 할 것

샵에서 로그인이 풀리는 이슈나 종종 로그인 세션이 잡히기는 하지만 풀리는 이슈에 대해서 완전히 해결되긴 하였다.

하지만, tools 에 관련된 부분을 참조하여 지속적으로 이루는 부분이 있는지 확인사살을 해야할 것 같다. 아마 분명히 있을 것이라 본다.

AWS Instance 내에서 기본적으로 보여지는 2가지의 Duplicated 된 것이 보였는데,

moyamo-scheduler 

그리고 moyamo-tools 내에서 운영되는 scheduler 가 중첩되었었다.

이러한 부분에서 두 가지의 scheduler 가 다른 역할을 하냐고 물어본다면, 역시나 아니다.

한 가지의 scheduler 는 분명히 suspend 되거나 terminated 되었어야 할 것 같은데, 내부 Log상으로 봐서 예전에 쌓여있던 로그 자체에서도 moyamo-scheduler 는 2021년에 사용하던 기록에서 유래된 것이고, 이러한 부분들은 확실히 ELS와 기타 다른 module 들이 합쳐진 곳에서 운영되는 scheduler 와는 별도로 관리되었던 것이다.

여하튼 2개를 같이 키면 당연히 scheduler가 2번 수집하게 되므로, Record 도 2번 쌓이게 되는데

그렇다면 발생하는 문제는

랭킹 Score 에서 2배로 쌓이는 것

그리고 해당하는 부분에 있어서 Score 가 문제가 아닌 댓글 Counting 에 대해서도 2배가 되는 현상이 발견되었었고

이 때문에 해당하는 부분에 대하여 해결하기 위하여 예전에는 moyamo-scheduler 내에서만 daemon을 가동시키고

tools에서는 종료를 시켰었다.

하지만 관리 포인트의 증가와 동시에 Tools 에서 참조하는 문제가 뭔가가 벌어졌어지리라고는 생각하지 못했는데,

공교롭게도 전 개발사에 의하여 Credential Key가 노출되는 상황이 벌어졌었고, 그 때문에 Credential key를 교체하는 상황에서 해당하는 부분에 대하여 내가 인지하지 못했었다.

그 이후에 Credential Key를 교체하고 전부 jar 로 컴파일하여 정상적인 모듈로 탑재하였으나, 모야모 샵 내에서 고도몰 세션 이슈가 발생했었는데.. 아무리 코드를 분석해봐도 예전에는 정상적으로 작동되던 것이 어떤 부분때문에 문제가 되는지 정말 어리둥절 하기도 했고

그 때문에 Spring - Android - Godomall 사이에서 오가는 Log를 수집하면서 accessToken 에 대한 byte 길이의 차이라던가 그런 부분에 대하여 파악하기도 하였고

Godomall 내부에서 overwritten 된 Custom Session Code에 대하여 전부 분석해보았으나, 에러찾기는 굉장히 애매한 상태인 것이다.

고렇다면 문제가 무엇일까

1. 

아마 예상컨데 Session 을 주기적으로 연결하고 끊는 과정에서 생기는 어느정도의 간헐적인 Delay 이슈일 수도 있을 것

2.

그리고 Android 에서 Spring 쪽을 호출하고, Spring 쪽에서 호출하는 뭔가 메세지 브로커 같은 것이 정상적으로 관리가 안되고 있을 가능성

3. 

망할놈의 Hikari CP 안에서 정상적으로 데이터베이스에 대해서 놓고 빼고 놓고 빼고를 하지 못할 가능성

그렇다고 해서 커넥션 풀을 최적화 하는걸 배제하고 read, write instance 에 대해서 증가시키는 것은 좀 에바참치니까 일단 풀부터 조져봐야한다

4.

고도몰 내에서 작성된 Custom Session 코드와 Spring 쪽에서의 통신 문제 - 근데 이건 다 살펴봐서 패스

5.

Android 측면에서 발견될 문제로 생각될 수도 있는데, 이건 Yagnesh 가 아무리 생각해도 Back-end Issue 라고 하니까 뭐 어케든 처리해야것다

실무환경에서 DataBase 성능 최적화 및 ORM에 대해 이야기 할때 커넥션풀이라는 단어가 자주 등장하여 한번 정리가 필요할 것 같아 정리한 포스트 입니다.

🍌 JDBC란?

Hikari CP(히카리 커넥션풀)을 알아보기에 앞서 JDBC의 개념을 정리하자면,
JDBC는 Java Database Connectivity의 약자로 자바에서 데이터베이스에 접속할 수 있도록 하는 자바 API다.

JDBC는 데이터베이스에서 자료를 쿼리하거나 업데이트하는 방법을 제공한다.

🍑 DB 커넥션 풀이란

일반적인 데이터 연동과정은 웹 어플리케이션이 필요할 때마다 데이터베이스에 연결하여 작업하는 방식입니다.
하지만 이런 식으로 필요할 때마다 연동해서 작업할 경우 데이터베이스 연결에 시간이 많이 걸리는 문제가 발생합니다.

예를들어 거래소의 경우, 동시에 몇천명이 동시에 거래 및 조회 기능을 사용하는데 매번 데이터베이스와 커넥션을 맺고 푸는 작업을 한다면 굉장히 비효율적일 것입니다.

이 문제를 해결하기 위해 현재는 웹 어플리케이션이 실행됨과 동시에 연동할 데이터베이스와의 연결을 미리 설정해 둡니다.

그리고 필요할 때마다 미리 연결해 놓은 상태를 이용해 빠르게 데이터베이스와 연동하여 작업을 합니다.

이렇게 미리 데이터베이스와 연결시킨 상태를 유지하는 기술을 커넥션 풀
(Connection Pool, CP)라고 합니다.

🍊 스프링에서의 커넥션 풀

자바에서는 기본적으로 DataSource 인터페이스를 사용하여 커넥션풀을 관리한다.

Spring에서는 사용자가 직접 커넥션을 관리할 필요없이 자동화된 기법들을 제공하는데

SpringBoot 2.0 이전에는 tomcat-jdbc를 사용하다,
현재 2.0이후 부터는 HikariCP를 기본옵션으로 채택 하고있다.

🍓 왜 Hikari Cp일까?

히카리 벤치마킹 페이지를 참고하면 아래와 같이 월등한 성능을 보인다는 것을 알 수있다.

HikariCp가 다른 커넥션풀 관리 프레임워크보다 빠른 성능을 보여주는 이유는
커넥션풀의 관리 방법에 있다.

히카리는 Connection 객체를 한번 Wrappring한 PoolEntry로 Connection을 관리하며,
이를 관리하는 ConcurrentBag이라는 구조체를 사용하고 있다.

ConcurrentBag은 HikariPool.getConnection() -> ConcurrentBag.borrow()라는 메서드를 통해 사용 가능한(idle) Connection을 리턴하도록 되어있다.

이 과정에서 커넥션생성을 요청한 스레드의 정보를 저장해두고 다음에 접근시 저장된 정보를 이용해 빠르게 반환을 해준다.

이러한 방법 때문에 속도에 이점이 있으며 해당 방법의 자세한 설명은 아래 블로그를 참조하면 좋을 것 같다.
HikariCP Dead lock에서 벗어나기 (이론편)

🍎 Hikari CP 사용법

build.gradle에 따로 추가할 필요 없이
"org.springframework.boot:spring-boot-starter-jdbc"
를 추가하면 자동으로 추가된다.

이후 application.yml에 설정값을 추가하면 되는데

spring:
 datasource:
   url: jdbc:mysql://localhost:3306/world?serverTimeZone=UTC&CharacterEncoding=UTF-8
   username: root
   password: your_password
   hikari:
     maximum-pool-size: 10
     connection-timeout: 5000
     connection-init-sql: SELECT 1
     validation-timeout: 2000
     minimum-idle: 10
     idle-timeout: 600000
     max-lifetime: 1800000

server:
 port: 8000

options

• maximum-pool-size: 최대 pool size (defailt 10)
• connection-timeout: (말 그대로)
• connection-init-sql: SELECT 1
• validation-timeout: 2000
• minimum-idle: 연결 풀에서 HikariCP가 유지 관리하는 최소 유휴 연결 수
• idle-timeout: 연결을위한 최대 유휴 시간
• max-lifetime: 닫힌 후 pool 에있는 connection의 최대 수명 (ms)입니다.
• auto-commit: auto commit 여부 (default true)

🍋 DeadLock 피하기

이론적으로 필요한 최소한의 커넥션 풀 사이즈를 알아보면 다음과 같다.

PoolSize = Tn × ( Cm -1 ) + 1

• Tn : 전체 Thread 갯수
• Cm : 하나의 Task에서 동시에 필요한 Connection 수

위와 같은 식으로 설정을 한다면 데드락을 피할 수는 있겠지만 여유 커넥션풀이 하나 뿐이라 성능상 좋지 못하다.
따라서 커넥션풀의 여유를 주기위해 아래와 같은 식을 사용하는것을 권장한다.

PoolSize = Tn × ( Cm - 1 ) + ( Tn / 2 )

• thread count : 16
• simultaneous connection count : 2
• pool size : 16 * ( 2 – 1 ) + (16 / 2) = 24

더 자세히 알아보고 싶으면 다음 블로그에서 확인하면 좋을듯 하다.
HikariCP Dead lock에서 벗어나기 (실전편)

https://velog.io/@miot2j/Spring-DB%EC%BB%A4%EB%84%A5%EC%85%98%ED%92%80%EA%B3%BC-Hikari-CP-%EC%95%8C%EC%95%84%EB%B3%B4%EA%B8%B0