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

실무환경에서 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

퇴사 이후에 제 자신에 대한 성찰과 인고의 시간을 보내며 면접을 보고 공부를 진행하고 있다.

다름 아닌 무엇보다도 걸리는 것은 잦은 이직경력 이랄까

이게 누군가가 보기에는 "어쩔 수 없었다." 라고 대답하기에는 어려웠던 많은 환경들과 수많은 것들

그리고 그러한 부분을 극복하지 못한 것도 결국은 내가 아닌가 싶기도 하고

프리랜서로서 다년간의 활동을 하면서 클라이언트들을 설득하는 커뮤니케이션 스킬을 얻었다고 생각했지만, 결과적으로 나는 커뮤니케이션 스킬에 있어서나 사람을 배려하는 부분에 있어서 부족했던 것은 아닌가 다시금 돌아보게 되는 시간들이 되고 있다

또한 가장 큰 것은 "내 커리어에 있어서 나는 애매한 사람인가? 애매한 사람이 아닌가" 라는 것인데

많은 개발자들과 소프트웨어 엔지니어, 시스템 엔지니어들은 하나의 언어나 주어진 스택쪽으로 일직선을 향해 달리는 반면에 나는 그렇지 못했던 부분이 아쉽게 작용한다

결과적으로는 나도 진득하니 엉덩이를 붙이고 둥지를 틀고 싶은 곳을 찾고 있는데, 그마저도 쉽지 않은 것이 현실이다.

아니 정확하게는 많이 부족한 내 자신이 문제인 것이 맞다고 보는 것이 맞겠다.

더 잘하고 싶고, 더 잘 해내고 싶고, 예전보다 더 끈질기게 물고 늘어져서 성취를 이루어낼 수 있는 자신감은 있지만

그러기엔 아직 나는 좀 부족한 것 같다는 생각이 든다.

그렇게 6개월을 보내다 보니 어느새 이력서를 지원했던 곳과 면접을 진행했던 곳이 140곳을 넘어가고 있다.

드라마 육룡이나르샤 에서 정도전 역할을 맡았던 김명민 배우가 했던 말이 있다

결국은 네가 만들려는 세상과 내가 만들려는 세상이 같은 것인데,
내가 한들 어떠하며, 네가 한들 어떠하겠느냐

고단하구나 방원아

심하게 공감되는 대사가 아닌가 싶다

1. Overview

In this tutorial, we’ll discuss the virtual memory and swap space concept in the operating system. We’ll also present the core differences between them.

2. Fundamentals of Virtual Memory

Modern operating systems are designed to execute multiple programs simultaneously and provide efficient and fast processing. Although, issues like lack of memory space, memory fragmentation can degrade the efficiency of an OS. Using virtual memory, we can solve the issues that cause the processing of the OS to be slow in terms of time and consumed memory.

It’s a memory management concept that creates the illusion that the computer has a huge amount of memory. Moreover, virtual memory allows the OS to extend its existing physical memory. It can be located on a hard disk.

In virtual memory, we map the program addresses into the main memory addresses. In some cases, if we don’t have enough main memory available, we map them into the disk memory addresses:

In addition to increasing the performance of the OS, virtual memory provides memory protection for the addresses that are translated to a physical address.

Any program that wants access to a certain area of memory executes a load function to specify a virtual address. Therefore, the computer will then translate this virtual address, transforming it into a physical address.

As soon as the physical address is available, the computer will look it up in the RAM. If the computer can’t find the physical address in RAM, it’ll search for it on the disk. Furthermore, the OS will also update the translation map. Finally, the computer reads the required case of memory and returns the data to the program.

In modern OS, the virtual memory concept is generally executed using demand paging and page replacement algorithms.

3. Introduction to Swap Space

Like virtual memory, swap space is a secondary memory. It’s used by the OS when there is no physical memory available for further execution of the processes.

If the OS faces a situation when it needs memory, but the RAM is full, it moves the inactive pages from RAM to swap memory. If these pages are needed in the future, the OS can move them again from swap space to RAM.

It offers a slower access time compared to RAM and located in the disk memory. Swap space is actually a part of the virtual memory.

There are several applications of swap space. It stores the applications which the OS doesn’t use frequently. Hence, if the OS has sufficient swap space, it always keeps the RAM free. Moreover, it helps in increasing the performance.

Another crucial use of swap space is that it can be used as a single contiguous memory by the OS. Hence, it also reduces I/O operations to read or write a file.

Swap space is available in Windows and Linux-based operating systems by default. The amount of swap space generally equals twice the RAM of the system. Moreover, the user has the option to increase or decrease it based on the requirements.

4. Difference Between Virtual Memory and Swap Space

In this section, let’s discuss the core difference between virtual memory and swap space in OS:

5. Conclusion

In this tutorial, we discussed the fundamentals of virtual memory and swap space in the OS. We also highlighted the core differences between them.

Comments are closed on this article!

Recruiting process

서류전형 - 온라인 테스트 (Online Assessment) - 1차 면접 (Technical Interview) - 2차 면접 (Loop Interview) - 최종합격

정말로 정말로 험난한 여정이 아니였나 싶다. 무엇보다도 굉장히 나에게 행운이였던 것은 최종면접까지 바로 갈 수 있는 길이 AWS Event 를 통해서 기회가 주어졌었기 때문이다.

이러한 기회와 경험을 가질 수 있게 해줬던 AWS 에 정말 소중함과 고마움을 느끼고 감사하다.

내가 이번에 치뤘던 부분은 Loop Interview 이고, 추가적으로 Technical interview 까지 겸해서 보게 되었다. 사실상 최종면접임에도 불구하고 Technical Interview 까지 진행된 것을 보니, 아무래도 1차 & 2차 Process 를 통합해서 제공해주셨던 모양이다.

특히 Danny 님께서 제공해주셨던 AWS SE 가 읽어야할 부분에서 Documents 를 읽고 공부하면서 느꼇던 여러가지 부분이 있는데

1. 내가 Linux 에 대해서 자신이 있다고 생각했는데 생각보다 Deep Dive 하게 알지는 못했구나 라는 사실

2. Linux 에서 Legacy 적으로 기본적인 것들이라고 볼 수 있지만, 그런 것들의 개념에 대해서 까먹었었다는 사실 (굉장히 아쉬웠다.)

학창시절에 내가 가장 유일하게 자랑할 수 있었던 무기는 암기능력과 동시에 세세한 설명까지 모두다 외워버리는 스킬을 가지고 있었다. (그 당시는 당시에 배우는 모든 것들이 내가 가는 길에 도움이 될 것이라 자신있게 생각했기 때문이다.)

하지만 역시 세월이 지나고 사람은 녹슬기 마련인지, 갈고 닦지 않아서 그런 것인지는 몰라도 내가 가지고 있던 녹슬은 부분이 어느 정도 드러났구나 라는 부분을 오늘의 Technical Assessment 부분에서 느꼇다. 

하지만 이번에 Technical Assessment 를 진행하면서 기분이 좋았던 점은, 아무래도 "면접을 본다기 보다는 Session 을 즐길 수 있는 시간이 됬었다" 라는 부분이 아닌가 싶다.

"이러한 이러한 개념에 대해서 설명해주세요." 라는 부분을 interviewer 분께 요청 받았을 때에, 내가 내는 답변에 대해서 이것으로 끝이 아니라 지속적으로 물어봐주시고 내가 무언가를 더 생각하고 유도할 수 있도록 생각하게 해주시는 부분에서 확실히 내가 어느정도 알고있기도 하고 생각날 수 있도록 섬세히 배려해주신다는 점이 너무 기분이 좋았다.

면접을 보고 나서 Tech Assessment 에서 어느 정도 털린 부분 (사실상 많이 답변 못한 부분)이 많이 있긴 하지만 아무래도 평소에 갈고닦던 스킬들이나 개념들에 대해서 정확히 알고 넘어가는 부분은 반드시 다시 필요해보인다.

그래서 앞으로 계획하고 있는 것은, Danny 님께서 건내주신 것을 기반으로 SE가 알아야 될 부분들에 대한 Document 들을 세세하게 읽고 공부해볼 생각이다. AWS에 합격하던 합격하지 못하는 것과는 더불어 1주일 간 공부를 하면서 너무나 행복했기 때문이다.

추가적으로 Loop interview 를 겪으면서 내가 가지고 있던 "이건 나의 Story 이자 History 요.."  를 기반으로 LP에 접목하여 AWS와 얼마나 Fit이 잘 맞는가에 대한 부분을 겪어보는 것을 가졌었는데, 아무래도 LP보다는 Technical Interview 에 대해서 더욱 심층적으로 힘을 썻던 탓인지 생각보다 잘 준비해서 치르진 못했다.

심지어 16 LP 중에서 8가지의 LP만 나온하셨는데, 몇몇의 interviewer 분들 께서는 LP를 3개 ~ 4개 들고 오신 것 같은 느낌까지 받을 정도로 빡셋던 부분이 있다. (마지막 Session 에서 치뤗던 Interviewer 님께 받은 부분이였다.)

내가 준비했던 사례가 적절하지 않았거나 뭔가 부족하거나 시간이 부족했거나 더욱 더 확인하고 싶으셨던 것이겠지라고  좋게좋게 생각하고 있지만 사실 마지막 Session 때에 식은땀을 엄청나게 흘렸다.

(안그래도 땀돌이인데 나자신 홍수를 낼 뻔했다.)

이번에 채용 프로세스를 진행하게 되면서 내가 가장 크게 느낀 것 중 하나는, 내가 Linux 를 정말 좋아하고 사랑한다고는 하였지만 정말 그렇게까지 사랑했던 것이 맞는 의문을 다시한번끔 다시 가지게 되었다

내가 정말 찐으로 Linux 를 좋아하고 사랑하는지를 많은 사람들 앞에서 조금 더 당당하게 드러낼 수 있도록 많은 부분을 갈고 닦아야 겠다고 느꼈고, 결과적으로 떨어질 것으로 직감하고 있기에 취업이 될 지는 모르겠으나, 또다시 AWS 에 1년~2년뒤에 도전해보게 되지 않을까 싶다.

그렇게 해서 내가 지원했던 결과는 꽤나 많은 횟수를 자랑하는데

AWS Solutions Architect (서류합격 이후 1차 인터뷰 보고 광탈)

AWS CSE - DMS (서류합격 이후 1차 인터뷰 보고 광탈 - 여기서는 아무래도 Development 가 두드러지지 않았나.)

AWS TAM (요기는 그냥 서류광탈)

AWS CSE - LIIN (얼떨결에 AWS에 많은 부분을 지원한 부분 통하여 사랑을 받은 것인지 몰라도 꽤나 인상깊게 봐주셔서 너무 감사했다.)

비록 Back-end Developer 로 시작했으나 DevOps 이자 SE 로써의 방향또한 놓치고 싶지 않고, 내가 좋아하는 것 또한 구조를 학습하고 개선하고 공유하며 남들을 Support 하는 부분이기에, 꼬옥 AWS 와 함께 해보고 싶다.