크게 DB에는 2가지 종류가 존재합니다. SQL을 사용하는 RDB와 SQL도 사용하는 NoSql(NoSql이 왜 Nosql인지에 대해 sql을 안써서 noSql이다 아니다 Not only sql의 약자라 그렇다라는 말들이 존재합니다. 안 중요하다고 생각합니다.)그렇다면, 어떻게 다를까요? 성능을 올리는 방식에는 크게 두가지가 있습니다. 수평적으로 늘리는 방식과 수직적으로 늘리는 방식이 있습니다. 간단히 설명하자면 수평적으로 성능을 올리는 방법은 갯수나 방법등을 늘리는 방법이고, 수직적으로 늘리는 방법은 성능을 올리는 방법입니다. 이에 해당하는 기술들은 Replication, 파티셔닝, 샤딩등이 존재한다고 합니다. 자세하게 설명하면 다른 방법들이긴하지만 말이죠. 그리고 개발을 하게 되면 SQL을 사용하여 ..
오래 기억에 남으려고 이해가 가지 않는것들은 이해가 갈때까지 공부하는 방식을 선택하였고, 계속 복습을 반복하는 형식으로 진행하였습니다. 하지만 여기에는 아주 치명적인 문제가 있었습니다. 그것은 생각보다 시간이 오래걸렸습니다. 보통 토요일 부터 시작해서 월요일까지 정리를 마치는데 나오는 결과물이 생각보다 좋지는 않았던거 같습니다. 그래서 방법을 다시한번더 바꾸려고 합니다. 그렇다고 해서 GPT에 돌린결과를 그대로 쓸 생각은 없습니다. 그렇게 해버리면 공부하는 의미가 없기 때문이죠. 조금더 고민해보고 진행해보겠습니다.일단 학습을 하려고 하는 범위 부터 말씀드리고 깊게 학습하는 방식으로 변경하는게 좋다고 생각합니다.학습할 내용은 다음과 같습니다.Index, SQL Injection, Statement vs P..
이전 장에서 프로세스의 상태에 대해 자세하게 알아봤습니다. 그리고 프로세스는 독립된 메모리 공간이라고 설명했었습니다. 간단하게 저번에 학습한 내용을 복습해보면 프로세스의 상태는 생성 -> 준비 -> 대기 -> 실행 -> 종료 -> 좀비 -> 해제 순으로 진행이 되어지며, 스케쥴러를 통해 프로세스의 실행 순서를 결정하게 되어집니다. 실행 순서를 나타내는 방식으로는 FSFC 먼저 들어온 친구부터 처리하는 기법, 우선순위 우선순위가 높은거 부터 처리하는 기법, RR 순차적으로 돌면서 처리하는 기법(순차적은 원형입니다.) SFJ 짧은 시간이 걸릴거 같은거 부터 처리하는 기법, CFS CPU가 가장 적게 쓴거 부터 처리하는 기법등이 존재합니다. 핵심은 모든 스케쥴러는 최초 1회는 FSFC으로 동작을 하게 되고, ..
기억을 더듬어서 CPU 스케쥴링이란건 뭘까? 내 기억으로는 락을 학습할때 락 해제를 도와주는 그런 역할로 나왔던걸로 기억한다.그리고 프로세스 동기화 같은 경우 일반적으로 프로세스는 독립적인 공간이 존재하기 때문에 동기화는 불가능하다. 하지만 이것을 가능하게 해주는 것이 IPC라고 알고 있다. 물론 이러한 사실들이 잘못된 내용들이 많다고 생각한다. 방금 GPT를 돌려보니 대부분 내가 한말이 틀렸다고 한다. 그렇다면 다시 잡는게 좋지 않을까 생각이 든다. 듬성듬성한 기억을 더듬어서 프로세스부터 스레드까지 다시 한번더 정리해보자.프로세스 상태프로세스는 독립된 메모리 공간이라고 했습니다. 그리고 다음과 같은 상태가 있다고 했습니다. 프로세스가 새로 생긴 상태, 그 프로세스가 동작하는 상태, 프로세스가 죽은 좀비..
전 회사에서 노드를 스프링을 바꿔야 하는 과제를 받았었다. 문제가 있었다. 당시 그 프로젝트는 SSO가 적용되어있다. SSO는 간단히 말해 여러 서비스를 통합해서 관리를 할 수 있어야 했다.그래서 스프링 시큐리티를 적용하기로했다.하지만 문제가 발생했다. 내가 스프링 시큐리티를 모른다는 사실이었다. 그래서 같이 일하시는 분이랑 시큐리티에 대해 같이 학습을 하였다.시간이 지나고 나니 스프링 시큐리티가 어떤 프로젝트인지 전혀 감이 잡히지않아 이렇게 다시 공부하기로 마음먹었다.|일단 내가 제일 먼저 알아야 하는건 본질에 대해 알아야 한다고 생각한다. 스프링 시큐리티가 과연 뭘까? 스프링은 이걸로 무엇을 하고 싶어하는걸까? 사실 스프링 시큐리티를 적용하지 않아도 인가며 인증이고 전부 가능하다. 스프링 시큐리티를 ..
[복습]지금까지 네트워크를 학습을 하였다. 그래서 그것들을 간단하게 복습하고 이번에는 어떤것을 대략적으로 학습할 수 있을지 생각해보자우리가 네트워크에서 가장먼저 학습하는 부분은 OSI 7계층이다. 7계층 같은 경우는 이론적으로 위대하신 선배님들이 정리해놓은것이라고 합니다. 하지만 문제는 7계층 같은 경우, 데이터의 흐름 신호를 설명하기에는 부족했다. 그러니까 실무적인 관점이 아니라는 뜻이라고 생각하면 됩니다. 그래서 만든 TCP/IP계층이 등장헀습니다. TCP/IP도 전반적으로 OSI와 다를것은 없습니다. 다만 여기서 중점적으로 봐야 하는 부분은 계층 신호입니다. 계층은 물리 -> 데이터 링크 -> 네트워크 -> 전송 -> 응용계층으로 되어있습니다. 신호란 전기신호입니다. 결국 모든 신호는 0과 1로 ..
WEB에는 대 프로토콜 HTTP가 있다. HTTP에 대해 간략히 복습하자면 HTTP는 비연결 지향 프로토콜이다. 클라이언트의 요청(Request)이 서버로 전송되고 응답(Response)이 완료되면 연결이 즉시 종료된다. 이러한 특성 때문에 요청 간의 상태가 유지되지 않으며, 한 번 전송된 메시지는 서버나 클라이언트 어느 쪽에서도 자동으로 저장되지 않는다. 하지만 모든 메시지가 즉시 연결이 종료되면 안될 수 있다. 예를 들어, 클라이언트가 보낸 메시지를 지속적으로 조회하거나,서버가 실시간으로 상태 변화를 전달해야 하는 상황이라면HTTP의 비연결·비상태 특성만으로는 한계가 발생한다. 이러한 문제를 해결하기 위해 다양한 방식이 등장했다.Long Polling, Server-Sent Events(SSE), 그..
1주차에 UDP TCP를 학습을 하고 2주차에는 HTTP를 학습하였습니다. OSI로 따지든 TCP/IP기준으로 따지든 둘다 데이터라는 것을 통신하게 되어집니다. 당연한 얘기겠지만, 계층이 올라가면서 이 안에서 동작하는 전기 신호의 이름은 변경이 되었습니다. 어찌보면 그냥 신호일뿐인데 어째서 이것들을 나누었을까요? 이건 제 생각인데 계층 마다 분리를 하고 싶었던게 아닌가 싶습니다. 이거는 이러니까 이거지.. 개인적으로 "장비" 입장에서는 신호를 나타나내는 용어가 그렇게 중요할까요? 아마 사람에게 중요한 일일 겁니다. 그래야 구분짓기 쉬우니까 그 당시 인간들은 이런 행위를 굉장히 즐긴거 같습니다. 계층 나누고 그것을 부리는 명칭을 달리하는 것말이죠. 얘네를 왜 학습해야 하지?가만 생각해보면 이것들을 왜 알아..
오픈 채팅방에커리어 상담글이 올라왔다. 현재 나는 4년째 백엔드 개발자고 8개월째 이직 준비중에 있다. 또한 도메인변경을 원했기 때문에 커리어 상담을 신청하게 되었다. 어찌 저찌 신청서를 제출하고 기달렸다. 10월 26일 일요일 7시에 상담해준다는 연락을 메일로 받았다. 사실 토욜이었는데 취소되었고 일욜로 바뀌었지만 난 못봤다. 상담 시작간단하게 자기소개를 하고 어떤것을 지금 중점적으로 해야 하는지 설명해주셨다. 일단 나는 이커머스로 도메인 변경을 원했는데사실 이커머스에서 어떤일을 하는지 왜 그 도메인을 원하는지에 대해 구체적으로 고민하지 않았던거 같다. 단순히 생각했을때 고객들과 가장 밀접한 도메인이라고 생각만 했지 구체적으로 생각하지는 않은거 같다.기술같은 경우도 머릿속에 아른거리는 기술들만 있지 실..
이전 장에서 예고한것처럼 쿠키랑 세션에 대해 알아봅시다. HTTP에서 TLS이 추가되어서 보안이 증가된 형태인거는 이제 이해했는데 그렇다면, 인증쪽은 어떻게 처리를 해야 할까요? 아니 애초에 이게 왜 필요한건지 이해할 필요가 있을거 같습니다. 웹이나 앱등등 사용자를 등록하게 되어집니다. 등록을 하게 되면 로그인이라는걸 하게 되는데 그런 다음 어떻게 해야 할까? 쿠키나 세션 하물며 JWT토큰 조차 없다고 생각해보자 이거는 그냥 데이터에 불과할겁니다.. 그걸 통해 뭔가 액션을 취할 수 는 있겠는데 그걸 계속 유지를 시킬 수는 없습니다. 왜냐하면 HTTP는 알다시피 Stateless 비연결성 프로토콜입니다. 즉, 한 번 요청하고 응답이 끝나면 그 연결에 대한 기억은 완전히 사라집니다. 여기서 어라? HTTP는..
지난번에 TCP와 UDP를 학습하였습니다. 이제 이것을 발전시킨 기술 하나를 살펴볼 건데요. 그것은 바로 HTTP입니다.HTTP가 웹을 위한 프로토콜로 잘 알려져 있긴 하지만 HTTP에 대해 잘 알지 못하고 있습니다. 인터넷에 HTTP를 검색하면 많은 정보들이 나오긴 하지만 생각만큼 잘 와닿지 않았습니다. 1960년대에 HTTP라는 기술에 대한 설계가 시작이 되었고, 팀 버너스 리를 필투로 1989년에 HTTP가 개발이 되었다고 합니다. 어떻게 보면 중요한 내용일 수도 있겠지만, 생각해 보면 지금 말하고 있는 사실과 HTTP의 연관성을 짓지 못하는 경우가 많은 거 같습니다. 이러한 이유가 발생한 이유가 뭘까요? 단순히 암기를 하려고 했던 게 아닐까요? 이번에 제대로 HTTP를 빠개봅시다.HTTP는 어디에..
