비전공자 출신으로 개발자로 취업해보니, 코드를 짜는 것 이외에도 공부할 분야가 많다는 것을 몸소 느끼고 있습니다. 특히 최근에 출장을 다녀오면서 서버 쪽에 무지한 제 모습을 보면서 전문적인 강의까지는 수강하지 못하더라도, 관련된 서적은 읽어봐야겠다고 생각이 들었어요. 서버 관련 서적을 찾다가 전반적인 인프라를 소개해주는 이 책을 선정하게 되었습니다.
이번 책 리뷰 편도, 전 편 [읽기 좋은 코드가 좋은 코드다] 포스팅 처럼 사내에서 자체적으로 진행하는 스터디에 필요한 토론 및 발표 자료로 쓰이기 때문에 특별한 형식 없이 준비하기로 했습니다😃
인프라(Infra)?
인프라는 우리말로 직역하면 '기반'이란 뜻으로, 우리의 생활을 지탱하는 바탕이나 토대란 의미를 가지고 있다. 인프라의 대표적인 예로 가스, 수도, 전기를 들 수 있다. 인프라의 구조 자체는 복잡하지만, 해당 전문가들에 의해 관리되고 있어 일반 사용자는 그 구조를 이해하지 않고도 간단히 이용할 수 있다는 특징을 가지고 있다.
IT 인프라도 마찬가지다. 사용자가 검색 엔진(네이버, 구글 등)을 통해 검색 키워드를 입력하면 많은 검색 결과를 얻을 수 있다. 이런 방대한 데이터는 어떻게 관리되고 있는지 모른 체 말이다. 이런 부분을 IT 인프라가 지탱하고 있다.
OS(Operation System)💿
OS, 즉 운영체제는 사용자가 컴퓨터를 쉽게 다룰 수 있는 인터페이스다. 이런 OS를 이해하는데 있어서 필수 개념이라고 할 수 있는 것들 중에는 프로세스와 스레드, 커널이 있다.
프로세스 및 스레드는 프로그램 실행 파일 자체가 아니라 OS상에서 실행돼서 어느 정도 독립성을 가지고 동작하는 것이다. 사용자가 프로그램을 설치해서 아이콘을 더블클릭하면 창이 뜨고, 다시 한번 프로그램 아이콘을 더블클릭하면 다른 별도의 창이 열리는 것을 예시로 들 수 있다. 쉽게 말해, 사용자의 요청을 처리하는 친구들! 이라고 표현할 수 있을 것 같다. 하지만 둘의 차이점은 분명히 있다.
프로세스는 전용 메모리 공간을 이용해서 동작한다.
반면에, 스레드는 다른 스레드와 메모리 공간을 공유하고 있는 운명 공동체이다.
OS 커널💾
커널 자체가 OS의 '인프라'라고 생각이 들 정도로, OS에서 큰 비중을 차지 하고 있다. 커널은 다양한 역할을 갖고 있지만, '뒤에서 무슨 일이 벌어지는지 은폐하면서도 편리한 인터페이스를 제공'하는 것이다.
웹 데이터 흐름🏊♀️
첫 번째로, 프로세스나 스레드가 요청을 받고 커널을 통해서 각 서버에 전송을 하게 된다. 여기서 말하는 서버는 사용자단에서 보는 웹서버, 동적 컨텐츠를 처리하는 AP서버, 데이터들이 저장되어 있는 DB서버를 일컫는다.
동적 컨텐츠
높은 빈도로 변경되는 데이터를 가리킨다. 사용자의 은행 잔고 정보나 최신 날씨 정보 데이터, 쇼핑 사이티의 장바구니 등이 이에 해당한다.
- Web Server ➡ AP Server
- 웹 서버로부터 요청이 도착한다.
- 스레드가 요청을 받으면 자신이 계산할 수 있는지, 아니면 DB 접속이 필요한지를 판단한다.
- DB 접속이 필요하면 연결 풀에 액세스 한다.
- DB 서버에 요청을 던진다.
- AP Server ➡ DB Server
- AP 서버로부터 요청이 도착한다.
- 프로세스가 요청을 접수하고 캐시가 존재하는지 확인한다.
- 캐시에 없으면 디스크에 액세스 한다.
- 디시크가 데이터를 반환한다.
- 데이터를 캐시 형태로 저장한다.
- 결과를 AP 서버에 반환한다.
- AP Server ➡ Web Server
- DB 서버로부터 데이터가 도착한다.
- 스레드가 데이터를 가지고 계산 등을 한 후에 파일 데이터를 생성한다.
- 결과를 웹 서버로 반환한다.
직렬 / 병렬🔆
지금까지 한 가지 요청에 대한 전반적인 웹 데이터의 흐름을 알아보았다. 하지만 조금 더 웹을 거시적으로 바라보았을 때, 실제 웹에서는 수백 가지의 요청 많게는 수천 가지의 요청이 한 번에 들어올 경우가 있다. 이럴 경우 개발자는 어떻게 처리하는 게 좋을까?
한 가지 예시로 고속도로에서는 통행료를 지불하는 톨게이트가 존재한다. 4차선 도로에서 1차선 도로로 합류하는 과정이 불가피하게 발생한다. 합류점부터 시작되는 1차선 구간은 혼잡해지기 쉽고 합류점이나 분기점에서는 사고가 발생하기 쉽다. 이런 1차선 구간은 전체 흐름을 느리게 만드는 원인으로 이른바 병목지점(Bottlenect)이 된다.
이러한 문제를 해결하기 위해서는 톨게이트의 개수를 늘려 병렬처리 하는 방법이 있다. 이것은 컴퓨터 세계에서도 마찬가지다. 여러 명의 사용자가 동시에 어떠한 요청을 보냈을 때, 컴퓨터의 성능이 아무리 좋아도 혼자서 처리할 수 있는 양이 정해져 있다.
하지만 무조건적인 병렬 처리는 옳지 못한 개발 방법이다. 프로그램 상의 병렬 처리는 구조가 복잡해서 설계나 구현 난이도가 높기 때문이다. 또한, 병렬화할 때는 일을 분담해서 처리를 한 후 다시 집약할 때 오버헤드가 걸린다. 그러므로 이 오버헤드를 감안하더라도 효과가 있을 경우에만 병렬화 시키는 것이 좋다.
오버헤드란 프로그램의 실행흐름에서 나타나는 현상중 하나로 예를 들어 , 프로그램의 실행흐름 도중에 동떨어진 위치의 코드를 실행시켜야 할 때 , 추가적으로 시간,메모리,자원이 사용되는 현상
결론적으로, 개발자는 각 서버의 처리량이나 응답 상황 로그를 취득해서 어느 서버가 병목지점이 되는지를 파악한 후 튜닝하는 방식이 좋다. 또한, 유량제어를 통해 시스템의 이용자 수를 제한하는 방법도 고려해볼 만한 방법이다.
이 밖에도, 동기/비동기 방식으로 처리하는 방법과 스케일 아웃으로 서버를 늘리는 방법 등 트래픽이 많았을 때의 해결 방법은 많다. 동기/비동기 와 스케일 아웃은 스터디원들이 모두 다 아는 내용이라 생략하겠다.
배타적 제어📍
배타적 제어는 문자 그대로 '다른 것을 배제하는 제어'다. 흔히, 여러 사람이 공유하는 물건일 경우, 누군가가 그 물건을 사용하고 있으면 다른 사람은 그것을 사용할 수 없는 얘기다.
프로그램의 대부분은 공유 데이터를 이용하기 때문에 배타적 제어는 필수로 쓰이고, 대부분은 공유 데이터를 이용하며 부분적으로는 직렬 처리를 사용해야 되는 경우가 있기 때문에, 배타적 제어를 하는 부분은 병목 현상이 발생하기 쉽다.
☝예를 들어, 3차선 도로가 1차선이 되는 부분과 같다. 3차선으로 나누어 운행하던 자동차가 1차선으로 집약되기 때문에 한 대의 자동차가 통과할 때는 다른 차선의 자동차가 들어오지 않도록 배타적 제어를 한다. 이런 부분에서 병목 현상이 발생하기 쉽다.
- 복수의 처리가 공유 자원(CPU, 메모리 등)에 동시에 액세스(갱신)하면 불일치가 발생할 수 있기 때문에 배타적 제어로 보호해줘야 한다.
- 배타적 제어에서는 특정 처리가 공유 자원을 이용하고 있는 동안 다른 처리가 이용할 수 없게 해서 불일치가 발생하지 않도록 한다.
결론적으로, 배타적 제어를 사용하면 공유 데이터의 일관성을 유지할 수 있는 장점이 있는 반면에 병렬 처리가 불가능해 빠르게 요청을 처리할 수 없다. 따라서 정말로 필요한 곳에만 배타적 제어를 하고 병렬 처리가 가능한 부분을 늘리면 CPU를 유용하게 활용해 처리 속도를 높일 수 있다.
탐색 알고리즘🔍
그렇다면, 프로그램 내부에서 사용자의 요청을 빠르게 처리 할 수 있는 방법은 더 없을까? 사용자가 어떠한 내용을 검색하였을 때, 원하는 내용을 가공해서 보여주기 위해서는 데이터를 찾기 쉽도록 미리 정리해 두면 조금 더 빨리 요청을 처리할 수 있을 것이다.
예를 들어, 책이나 사전에서 무언가를 찾고 싶을 때 원하는 키워드를 알고 있으면 색인을 찾거나, 특정 주제에 대해 읽고 싶다면 차례를 찾아볼 것이다. 만약 색인이나 차례가 없다면 읽고 싶은 페이지를 찾기 위해 모든 페이지를 열어 봐야 하는 수고스러움이 발생한다.
컴퓨터 세계에서도 마찬가지다. 데이터를 미리 찾기 쉽도록 정리해 두면 원하는 데이터를 빨리 찾을 수 있다. 이때, 데이터 정리 방법을 데이터 구조, 찾는 방법을 탐색 알고리즘 이라고 부른다.
- 필요한 때에 필요한 데이터를 빠르게 찾기 위해서 데이터를 정리해 둘 필요가 있다.
- 데이터를 찾을 때의 데이터 구조와 데이터 저장 방식(메모리, HDD 등) 특성에 따라 적합한 데이터 정리 방법이 다르다.
- 처리 순서에 맞추어 데이터 구조를 정리할 필요가 있기 때문에 '알고리즘과 데이터 구조'는 자주 함께 다뤄진다.
선형 탐색 | B-Tree Index | Hash Table |
풀 스캔 검색으로 100건의 데이터가 있으면 100건을 모두 보는 것. 모든 데이터가 필요할 경우 적합 |
인덱스는 우리말로 '색인'이다. 인덱스를 통해 검색이 빨라지는 대신에 데이터 추가, 삭제, 갱신 시에는 인덱스도 갱신해야하는 단점이 있다. |
키와 값의 조합으로 구성된다. 아무리 데이터 양이 많아져도 기본적인 등호 검색의 속도는 변하지 않는 장점이 있다. 반면에, 범위 검색에서는 좋지 못한 방법이다. |
폴링(Polling)📃
폴링은 정기적으로 질의하는 것을 가리킨다. 정기적으로 질의함으로써 상대가 어떤 상태인지, 어떤 요구를 가지고 있는지 등을 알 수 있다. 현재 사내에서는 배치 시스템에 주로 사용된다. 배치 시스템의 예시로는 어떤 한 학생이 모든 온라인 강의를 수강했을 때 수료증을 발급해주는 경우가 있다.
사용자 측면에서는 강의를 모두 다 들었다는 것을 알 수 있지만, 프로그램 상에서는 주기적으로 학생들이 강의를 다 들었는지 확인하는 작업이 필요하다. 그러한 작업을 배치 시스템이라고 한다.
- 질의 방향이 단방향이다.
- 질의는 일정 간격을 따라 정기적으로 발생한다.
- 반복만 하면 되기에 프로그래밍이 쉽다.
- 상대가 응답하는지 확인할 수 있다.
- 모아서 일괄적으로 처리할 수 있다.
ps. 신입 사원이 배치시스템에 대해 아직 잘 몰라서 스터디하는 김에 발표 자료에 넣어봤다😄
OSI 7 계층📚
네트워크에서 발생하는 데이터 처리나 교환에는 다양한 구조가 존재한다. 그 구조는 많은 부분에서 계층 구조라는 개념을 적용하고 있다. 계층 구조에서는 데이터나 기능 호출 흐름에 따라 계층 간 역할이 나누어진다는 특징이 있다.
역할이 나누어져 있기 때문에 각 층은 자신이 담당하는 일만 책임을 지며, 다른 일은 다른 계층일 책임을 진다. 서로 상호 연결돼 있는 계층들에서는 교환 방법, 즉 인터페이스만 정해 두면 된다.
컴퓨터에서 계층 구조를 다룰 때 피해 갈 수 없는 것이 OSI 참조 모델이다. OSI 자체는 현재 사용되고 있지 않지만, 이 계층 구조 개념은 다양한 분야에서 공통적으로 참조할 수 있는 참조 모델로서 현재도 사용되고 있다.
- 응용 계층 : 애플리케이션 처리
- 표현 계층 : 데이터 표현 방법
- 세션 계층 : 통신 시작과 종료 순서
- 전송 계층 : 네트워크의 통신 관리
- 네트워크 계층 : 네트워크 통신 경로 선택
- 데이터 링크 계층 : 직접 접속돼 있는 기기 간 처리
- 물리 계층 : 전기적인 접속
이 포스팅에서 모든 계층에 대해 자세하기 다룰 수 없기에 간단하게 설명을 덧 붙였고, 더 자세한 내용은 책의 180 페이지를 참고하면 될 것 같다😊
프로토콜(Protocol)🎈
네트워크에 대해 언급할 때 빠트릴 수 없는 또 다른 한 가지가 프로토콜이다. 프로토콜은 사정에 정해 놓은 순서를 의미한다. 컴퓨터 용어로는 특히 통신 프로토콜이라는 이름으로 자주 등장하며, 컴퓨터가 서로 소통하기 위해 정한 규약을 가리킨다.
사람이 하는 대화를 생각해 봤을 때, 영어나 한국어 같은 언어도 사람끼리의 통신을 위한 프로토콜이라 생각할 수 있다. 또한, 통신 시에 이용하는 매체도 프로토콜이라 볼 수 있다.
이처럼 컴퓨터 세계에서도 거의 모든 곳에 프로토콜이 사용된다. 떨어진 곳에 있는 두 개의 장비는 사전에 절차를 정해 두지 않으면 서로 통신할 수 없기 때문이다. 예를 들어, 브라우저로 웹 페이지를 볼 때 HTTP라고 불리는 프로토콜을 사용해서 서버에게 웹 페이지를 달라고 요청한다. 또한, 이 통신은 전기 신호나 전파를 이용해서 전달된다.
즉, 앞에서 언급했던 계층 구조를 함께 생각하면 프로토콜은 같은 계층 간의 약속이라고 할 수 있다.
TCP / IP📬
TCP/IP의 개념을 설명하기 앞서, 인터넷의 발전 역사를 살펴보면 TCP/IP의 탄생 배경을 알 수 있다. 1980년대까지는 네트워크 제조사별로 수많은 독자 프로토콜을 사용하고 있어서 상호 접속에 문제가 있었다. 프로토콜은 서로 통신하기 위해 탄생했는데, 결과론적으로 그러한 매개체 역할을 하지 못했던 것이다. 이런 이유로 국제 규격의 프로토콜을 만들자는 움직임이 시작됐고, 1982년에 OSI라는 프로토콜이 제정되었다.
TCP(Transmission Control Protocol)는 명칭 그대로 전송을 제어하는 프로토콜로, 신뢰도가 높은 데이터 전송을 가능케 한다. 또한 소캣에 기록된 애플리케이션 데이터는 커널 내에서 통신 대상에게 전달하기 위한 준비를 시작하는데 이때 가장 먼저 임무를 수행하는 프로토콜이 TCP다.
TCP의 장점으로는 애플리케이션이 보낸 데이터를 그 형태 그대로 상대방에게 확실하게 전달할 수 있다. 하지만 TCP가 담당하는 것은 어디까지나 서버가 송신할 때와 서버가 수신한 후 애플리케이션에게 전달할 때로, 상대 서버까지 전송하는 부분은 하위 계층인 IP에 모두 위임한다. 물론, IP만으로도 통신할 수 있지만 IP에는 데이터가 상대방에게 확실히 전달됐는지 확인하는 기능이나 도착한 순서를 확인하는 기능 등이 없다.
위 그림을 살펴보면, 3번의 데이터 흐름이 존재한다.
- 먼저, 통신 상대인 서버 측 OS에게 가상 경로를 열도록 의뢰한다.
- 서버 측에서는 리슨 하고 있는 포트 번호로 통신 요구가 온다. 서버는 문제가 없으면 열어도 된다는 응답을 한다.
- 클라이언트 측도 확인했다는 메시지를 보내며, 이때 처음으로 통신용 가상 경로가 열린다.
연결이 생성된 후에야 데이터 송수신이 시작되기 때문에, TCP에는 데이터가 확실히 전달되도록 보증한다. 또한, 각 TCP 세그먼트에 시퀀스 번호를 붙여서 구현하기 때문에, 데이터의 순서도 보장할 수 있는 장점이 있다.
이 밖에도, 재전송을 제어하거나 흐름과 폭주를 제어하는 장점을 가지고 있다.
세그먼트(Segment)
IP Header와 TCP Header를 제외한 TCP가 실을 수 있는 데이터 크기를 일컫는다.
TCP 세그먼트가 만들어지면 그다음은 IP의 처리가 시작된다. IP(Internet Protocol)는 명칭 그대로 오늘날 인터넷에서 사용되고 있는 가장 중요한 프로토콜이다. IP의 역할을 '지정한 대상 서버까지 전달받은 데이터를 전해 주는 것'이다.
☝이쯤 되면 TCP와 IP가 헷갈릴 수 있다. 짚고 넘어가자면, IP는 데이터를 한 장소에서 다른 장소로 옮겨주는 역할을 하고 TCP는 전체 데이터가 잘 전송될 수 있도록 흐름을 조절하고 성공적으로 상대 컴퓨터에 도착할 수 있도록 보장해주는 역할이다.
다시 한번, OSI 7 계층을 살펴보면, 지금 우리가 주목해야 할 계층은 전송 계층과 네트워크 계층이다. 앞서 전송 계층은 네트워크의 통신을 관리한다고만 짧게 설명하고 넘어갔었는데 조금 더 구체적인 설명을 덧붙이자면, 전송 계층은 송신자와 수신자의 논리적 연결을 담당하는 부분으로, 신뢰성 있는 연결을 유지할 수 있도록 도와준다.
즉, 사용자 간의 연결을 생성하고 데이터를 얼마나 보내고 얼마나 받았는지, 또 제대로 받았는지 등을 확인합니다. 대표적인 예시로, 지금까지 설명한 TCP가 있다.
한편 네트워크 계층은 IP이 활용되는 부분으로 한 사용자가 다른 Endpoint로 가고자 할 경우, 경로와 목적지를 찾아준다. 이를 라우팅(Routing)이라고 하며 대역이 다른 IP들이 목적지를 향해 제대로 찾아갈 수 있도록 돕는 역할을 한다.
👨👩👦👦 오픈채팅방 운영
취업을 준비하는 예비 개발자분들을 위한 질문&답변할 수 있는 공간을 만들었습니다. 취업과 이직을 하기 위해서 어떤 걸 중점적으로 준비해야 하는지부터 포트폴리오&이력서 작성법 등 다양한 질문들을 받고 답변을 드립니다. 참여하셔서 다양한 정보 얻고 가시면 좋을 것 같네요😁
참여코드 : 456456
https://open.kakao.com/o/gVHZP8dg
👨💻 전자책 출간
아울러 제가 🌟비전공자에서 2년만에 보안 전문 중견기업으로 이직 한 방법들을 정리한 전자책을 출간 하게 되었습니다. 어떤 걸 공부해야 하는지, 이직을 위해서 무엇을 준비해야 하는지, 제가 받았던 기술 면접 리스트 등 다양한 목차로 구성되어 있습니다. 또한, 구매 시 1:1 채팅을 이용하여 포트폴리오 첨삭을 도와드리고 있습니다. 🐕전자책으로 얻은 모든 수익은 유기견 센터 '팅*벨 입양센터'에 후원될 예정입니다. 관심 있으신 분들은 아래 링크를 참고해주세요😁
마치며
이번 책을 읽으면서 'IT 인프라는 이 한 권의 책으로 택도 없겠다'라는 생각이 들 정도로, 정말 광범위한 영역임을 다시 한번 느끼게 되었습니다. 사실 책의 모든 내용을 블로그 포스팅 한 개로는 턱없이 부족해서 중요해 보이는 부분 위주로 정리하게 되었네요.
이해하기 어려운 부분도 많았지만, 수박 겉핥기식으로 전반적인 IT 인프라를 알기에는 충분히 좋은 책이었다고 생각합니다. 서두에서도 말했지만, 개발자는 코드만 짜는 사람이 아니라고 생각하기에 종종 이런 아키텍처 관련 서적도 독서하거나 스터디를 하면서 배워나가야 할 것 같네요😄
책 리뷰 포스팅
* [ 스프링 부트와 AWS로 혼자 구현하는 웹 서비스 - 이동욱(향로) ]
* [ 읽기 좋은 코드가 좋은 코드다 - 더스틴 보즈웰, 트레버 파우커 ]
'Book Review' 카테고리의 다른 글
자바 ORM 표준 JPA 프로그래밍 - 연관관계 매핑 (0) | 2022.10.23 |
---|---|
자바 ORM 표준 JPA 프로그래밍 - 엔티티 매핑 (1) | 2022.10.08 |
자바 ORM 표준 JPA 프로그래밍 - JPA란? (0) | 2022.09.24 |
[읽기 좋은 코드가 좋은 코드다] 책 리뷰 (0) | 2022.06.14 |
향로님의 스프링 부트와 AWS로 혼자 구현하는 웹 서비스 (0) | 2022.06.03 |