분류 전체보기

개발자로서 네트워크의 구조나 동작 원리를 이해하는 것은 필수적인 기본 역량 중 하나일 것이다. 이런 이유로 나도 네트워크의 복잡한 구조를 파악하기 위해 상당한 노력을 기울여왔다. 네트워크 관련 서적이나 강의를 틈나는 대로 읽고 유튜브 강의도 종종 보면서 네트워크의 계층이나 프로토콜에 대한 지식을 쌓았고, 최근에 홈 서버를 구축하면서 배운 내용을 연계해서 이해보려고도 노력했다. 그럼에도 책이나 강의에서 다루는 네트워크 관련 내용은 상당히 이론적이로 추상화된 지식을 다루는데 집중하고 있기 때문에, 실제 네트워크가 물리적으로 어떻게 구성이 되어있는지, 어떤 장비가 어떻게 사용 되는지에 대해서는 구체적으로 알기 어렵다. 이런 지식은 일반적으로 네트워크 인프라 엔지니어의 담당 영역이라서 개발자의 입장에서는 자세히..

꼼삐에서 식물 검색을 할 때 실시간 인기 식물 순위가 노출되면 좋겠다는 요구사항이 있었다. 사실 복잡한 로직을 요하는 기능은 별로 개발해본 적이 없었어서, 요구사항을 듣고서 바로 구현방안이 떠오르지 않았다. 어떤 자료구조를 활용해서 어떻게 구현할 지 조금 고민하다가 금방 구현을 하긴 했다. 그런데 최근에 어떤 회사 채용 과정에서 관련 내용을 묻는 질문이 있었는데, 까먹어버려서 뭔가 뚜렷하게 답을 하지 못했다. 잊지 않도록 상세하게 구현 내용을 좀 적어두려고 한다.1. 기능 요구사항'인기 순위' 라는 기능을 개발하기 위해서는 생각보다 여러 조건들이 필요했다. 우선 '인기' 라는 것을 어떤 지표로 판단할 것인지를 정해야 했다. 직관적으로 떠올릴 수 있는 지표는 조회수, 관련 게시글 수(이 경우에는 관련 게시..

MongoDB 클러스터를 구축하려고 하는데, MongoDB 에서는 Replication 이 어떤식으로 동작하는지, 주의할 점이 어떤 게 있는지, 그리고 주요한 설정 값은 뭔지 정리해보았다. MongoDB 클러스터 구축시 적절하게 활용하고자 한다.  주로 서적으로 공부를 하는 편인데, MongoDB 는 최근 시장이 매우 커짐과 동시에 버전이 계속 업데이트 되어서 레퍼런스를 찾기가 쉽지 않았다. 국문 서적중에는 가장 최근에 나온 MongoDB 완벽가이드? 이게 4.x. 버전으로 글 작성 기준의 최신 버전인 8.0 버전과 비교해서 상당히 뒤떨어져 있기 때문에, 좀 아쉬울 것 같았다. (그래도 주문은 해놓았음...)  근데 MongoDB 의 공식 문서을 봤는데, 별도로 서적이 필요 없을 정도로 매우 정리가 잘되..

오늘은 Redis 를 운영 단계에서 사용할 때 안정성 있게 사용하기 위한 지표인 '가용성' 관련해서 공부한 내용을 정리한다. Redis 는 대부분의 서비스에서 중추적인 역할을 담당하기 때문에 장애 상황에 대한 대응책이 꼭 필요하다. 장애 상황을 빠르게 극복하고 정상화하여 최종적으로 서비스의 고 가용성을 확보하기 위해서는 Redundancy(Replication) 과 자동 Failover 가 확보되어야 할 것이다. 즉, Redis 서버를 여러개 복제해서 운용하고 있다가 Primary 노드에 장애가 생기면 Replica 노드가 장애가 발생한 Primary 노드를 대신해 서비스를 이어갈 수 있어야 한다는 것이다.  1. Replication (복제)Redis 도 다른 데이터베이스와 마찬가지로 DB 자체적으로 ..

gRedis 의 동작 방식을 공부했다. Redis 가 싱글 스레드임에도 비동기적으로 멀티플렉싱 IO 를 어쩌구 저쩌구 하는 설명을 여기저기서 많이 보았는데, 사실 이런 단어들은 나한테 별로 직관적으로 와닿는 설명이 아니라서... 좀 더 아랫단의 동작을 분석해서 Redis 가 어떻게 빠르게 동작할 수 있는지를 알고 싶었다. 코드 수준까지 분석하는 건 역시 힘들고 핵심적인 사항만 정리한다. 1. Redis 의 네트워크 I/O나는 지금까지 I/O 작업이라고 하면 디스크에 읽고 쓰는 것을 주로 생각해왔다. 그런데 Redis 에서 주로 거론되는 I/O 작업은 디스크의 입출력을 이야기 하는 것이 아니라 네트워크의 I/O 를 이야기한다. I/O 는 디스크에서만 일어나는 게 아니라 네트워크를 통해 들어온 요청, 응답을..

지금까지 Redis 는 주로 캐싱 용도로 많이 사용했고, 그외로 Pub/sub 처리, 실시간 인기순위 등에 사용했었다. 사실 실제 운영 환경에서 Redis 를 운용해본적은 없어서 조금 고민이 부족했던 부분이 많이 있었는데 실제 운영 환경에서는 어떤 고민들을 해야했고, 어떤 문제들이 발생하는지 공부한 내용을 정리한다.1. 메모리 관리Redis 는 태생적으로 메모리를 저장공간으로 사용하는 인메모리 데이터베이스로, 디스크를 이용하는 RDB 에 비해서 데이터 입출력 속도가 매우 빠르다. 그러나 성능이 좋은 만큼 비용은 훨씬 크다. 때문에 제한된 용량을 가지며 가격도 디스크에 비해 매우 비싸다.더보기기억 장치별 성능최근에는 보조기억장치로 SSD(Solid State Disk) 를 주로 사용하는데 이는 하드 디스크..

HTTP 에 관한거라고는 시작줄, 헤더, 공백, 바디 정도로 이루어져있다. 는 것 정도밖에 모르고 있었다. 사실 HTTP 통신의 경우 워낙 추상화가 잘되어있기 때문에 그냥 뭐 알아서 잘하나보지라고 블랙박스인 상태로 놔두고 있었던 것 같다. 그러나 최근에 등장한 HTTP 2, 3 버전은 통신 방식에서 기존 HTTP 1 버전과 확연한 차이를 보이고 있기 때문에 버전별로 어떤 차이가 있는지 대강은 알 필요가 있는 것 같다. 그리고 공부하면서 조금 이해가 안갔던 부분도 정리를 해두려고 한다. 전체적인 배경은 GPT 선생님께서 정리해주셨다. 1. HTTP 1.0 ~ 1.1HTTP 1.0 버전은 HTTP가 1991년 처음 발표되고 난 후 인기를 끌면서 발생한 다양한 요구사항들을 반영하여 처음으로 표준화하여 발표된 ..

꼼삐 프로젝트를 시작하면서 인프라 구성 쪽을 가장 공부해보고 싶었다. 꼼삐를 시작하기 직전에 회사에서 했던 배달공제조합 프로젝트에서 쿠버네티스와 아르고 씨디를 사용했었는데, 그때는 다른 계열사 데브옵스 엔지니어가 인프라 관련 작업들을 다 해주기도 했고 워낙 개발일정이 빠듯했어서 인프라 구성 관련해서 제대로 공부할 수 없었다. 현업에서의 개발 환경은 확실히 다르긴 했다. 개발, 검증, 운영 세단계로 환경을 분리하여 운영하고 있었고, 보안 수준이나 리소스 수준도 다르고 배포과정도 다르고... (사실 구체적인 부분은 잘 모름) 사실 무엇보다 쿠버네티스와 아르고 cd 로 구성한 컨테이너 오케스트레이션이 잘 알지도 못하면서 좀 멋져보였다. 여튼 이런 이유에서 꼼삐에서는 가상화 인프라 구성(가상 머신, 컨테이너) ..

이전글에서 가상화 기본 개념을 정리했다. 이어서 현대의 System VM 은 어떻게 구현되는지에 대해 공부한 내용을 정리해본다.1. 에뮬레이션 (Emulation) 과 Qemu (Quick EMUlator)Qemu 는 가상 환경을 만들기 위해 필요한 모든 하드웨어 시스템을 에뮬레이트한다. 여기서 에뮬레이트란, 가상의 하드웨어를 실제 물리 머신 위에서 소프트웨어적으로 구현하는 것이다. 이를 위해 가상환경에서 동작하는 어플리케이션 프로그램이나 운영체제가 하드웨어 자원(이라고 믿고 있지만 실제로는 Qemu 인) 에 보내는 요청을 적절히 처리할 수 있어야 한다. Qemu 는 에뮬레이트 되는 하드웨어의 모든 명령어를 실제 물리머신이 처리할 수 있도록 binary translation 을 하는 방식으로 이를 구현한..

가상화 기술 관련 공부를 심도있게 하고 싶은데 참고할 자료를 찾기 쉽지 않았다. 그러던 중 Virtual Machines : Versatile Platforms For Systems And Processes 라는 영문 원서의 pdf 본을 구할 수 있었는데, 가상화 기술 관련해서는 운영체제의 공룡책 만큼이나 바이블이라고 한다. 기술적으로 상당히 깊이 있어 보여서 이걸 완독을 하는 건 조금 나중의 일일 것 같고, 일단 개론 격에 해당하는 1장을 읽어서 내맘대로 정리 해본다.  이후 목차는 2장부터 6장까지는 JVM 같은 프로세스 레벨의 가상 머신을 다루고, 7장 ~ 9장 부분이 시스템 VM 을 다룬다. 책이 2005 년에 발간되었는데, 알아보니 Intel 의 VT-x 가 처음 도입된게 2005년이라고 해서 ..