Operation 59

Network - HTTP 1.1과 HTTP 2.0의 차이

HTTP 1.1 버전은 15년 동안 지속되었습니다. 하지만 하나의 웹사이트에 무수한 리소스가 존재하고 무수한 요청을 주고 받게 되면서 HTTP 1.1이 가진 문제점이 대두되면서 HTTP 2.0이 등장했습니다. HTTP 1.1과 HTTP 2.0의 차이점을 HTTP 1.1(기존)의 문제점과 HTTP 2.0의 해결 전략을 중심으로 알아보겠습니다. Multiplexed Streams HTTP 1.0에서 TCP 세션을 맺는 것을 중복해서 수행하는 성능 이슈가 있었고, HTTP 1.1에서 Keep-alive를 통해서 해당 문제를 풀어냈었습니다. https://jaehoney.tistory.com/279 HTTP 2.0에서는 Multiplexed라는 기술을 도입하는데 1개의 세션으로 여러 개의 요청을 순서 상관없이 ..

Operation/Network 2022.09.29

Network - Proxy와 Gateway의 차이!

프록시(Proxy)와 게이트웨이(Gateway)는 클라이언트와 목적지 서버 간의 중계하는 역할을 한다는 점에서 매우 유사하다. 프록시와 게이트웨이의 역할과 차이점에 대해서 알아보자. 프록시 프록시가 있는 서버에서는 아래와 같이 요청이 전달된다. 클라이언트 -> 프록시 프록시 -> 서버 프록시는 중간에서 요청을 받아서 전달하고, 응답도 받아서 클라이언트에 전달해야 하므로 커넥션을 적절히 다룰 수 있어야 한다. 프록시를 사용하는 목적은 아래와 같다. 네트워크 캐싱 보안점 역할 (방화벽) 나는 무중단 배포를 위해 Reverse Proxy(클라이언트 -> 프록시 서버 -> 내부 서버 구조의 Proxy)를 사용한 적이 있다. 참고: https://jojoldu.tistory.com/267 게이트웨이(Gateway..

Operation/Network 2022.09.29

Network - HTTP 1.0과 HTTP 1.1의 차이 (지속성, 파이프라이닝, ...)

HTTP(Hyper Text Transfer Protocol)는 인터넷에서 주로 사용하는 데이터를 송수신하기 위한 프로토콜이다. HTTP의 변환점 중 가장 큰 부분이 HTTP 1.0 -> HTTP 1.1과 HTTP 1.1 -> HTTP 2.0로의 발전이다. 해당 포스팅에서는 HTTP 1.0과 HTTP 1.1의 차이에 대해서 알아보자. 1. 지속성 HTTP 1.0과 HTTP 1.1의 가장 큰 차이점은 지속성이다. 그렇다. 바로 Connection: Keep-alive 속성이다. HTTP 1.0에서 요청하고 수신할 때마다 새로운 TCP 세션을 맺어야 한다. 반면, HTTP 1.1부터는 TCP 세션을 한 번만 맺으면 여러 개의 요청을 보내고 응답을 수신할 수 있다. 결과적으로 TCP 세션을 처리하는 비용을 줄..

Operation/Network 2022.09.29

MSA에서 트랜잭션을 보장하는 방법(2PC, SAGA)

개요 1개 애플리케이션에서 여러 개의 DB 서버를 사용한다면 Java의 경우 JTA나 ChainedTransactionManager 등을 사용해서 분산 트랜잭션을 사용할 수 있다. 문제는 MSA에서 트랜잭션을 어떻게 보장하냐는 것이다. 결제을 한다고 하면 아래의 마이크로 서비스와의 연동이 있을 수 있다. 주문, 배달, 리워드 해당 기능들이 결제 서버, 주문 서버, 배달 서버, 리워드 서버 등으로 분리되어 있다. 트랜잭션을 어떻게 관리할 수 있을까? 2PC (Two-Phase Commit) 2단계에 거쳐 영속하는 작업을 말한다. 해당 가상의 서비스에서는 주문이 끝나면 회원에 등록된 카드로 금액이 결제 되어야 한다. 배달이 진행되어야 하고 사용한 포인트는 차감되어야 한다. Transaction Coordin..

MSA(Microservices Architecture)의 장단점

장점 각 서비스를 독립적으로 배포가 가능하다. 유연한 확장 코드 관리가 편리하다. (git conflict 가능성 감소) 책임이 명확하게 분리된다. 장애 범위가 축소된다. 광고 서비스가 장애나도 전체 범위로 확산되지 않음 팀별 코드 이해도 증가 생산성 증가 출시 시간 단축 단점 구현 난이도 상승 API 사용 범위 파악이 어려움 해당 API 스펙을 변경하면 예상 치 못한 서비스에서 장애가 날 수 있음 리소스 비용이 크다. 서버가 많이 필요 배포가 훨씬 더 많고 잦음 트랜잭션 관리가 복잡함 분산 서비스마다 트랜잭션 관리를 처리해야 함 메시징 시스템이 필요할 수 있음 통합 테스트가 어려움

블로킹(Blocking)과 논 블로킹(Non-Blocking)!

동기와 비동기, 블로킹과 논 블로킹을 같은 것이나 비슷한 것이라고 오해하는 경우가 많다. 해당 개념들은 전혀 다른 개념이며 직접적인 관련이 없다. Caller와 Callee 먼저 아래 개념을 이해하자. Caller: 호출하는 함수를 말한다. Callee: 호출당하는 함수를 말한다. 동기 & 비동기 동기와 비동기는 프로세스의 수행 순서 보장에 대한 매커니즘이다. 동기(Synchronous)는 Caller가 Callee의 작업 결과를 기다린다. 비동기(Asynchronous)는 Caller는 Callee의 작업 결과에 관심이 없다. Callee가 Caller에게 Callback을 수행한다. (Callee에서 예외가 터져도 Caller는 영향을 받지 않는다.) 일반적으로 Blocking(블로킹)과 Async(..

Operation/OS 2022.07.06

OS - 프로세스와 스레드 차이

프로세스 프로세스를 알기 전에 프로그램을 알아야 한다. 프로그램(Program)은 어떤 작업을 위해 실행할 수 있는 파일을 말한다. 프로세스의 사전적 정의는 다음과 같다. 컴퓨터에서 연속적으로 실행하고 있는 컴퓨터 프로그램 메모리에 올라와 실행되고 있는 프로그램의 인스턴스(독립적인 개체) 운영체제로부터 시스템 자원을 할당받는 자원의 단위 정리하면 프로그램의 실행된 부분을 의미한다. 프로세스는 다음의 특징을 갖는다. 각각 독립된 메모리 영역(Code, Data, Stack, Heap)을 할당받는다. 코드 영역(code area): 프로그래머가 작성한 프로그램이 저장되는 영역 데이터 영역(data area): 코드가 실행되면서 사용한 환경이나 파일들의 각종 데이터들이 모여있다. 스택 영역(stack area..

Operation/OS 2022.07.05

스토리지 종류 (파일/블록/객체 스토리지)

스토리지의 종류 최근에 사이드 프로젝트를 담당하게 되면서 영상물을 서버에 저장하는 작업이 필요했습니다. 제가 아는 서버에 파일을 저장하는 방법은 두 가지였습니다. DB에 파일명, 확장자와 BinaryData로 내용을 저장하는 방법 파일을 서버에 저장하고 DB에서는 그것을 꺼내쓸 수 있는 데이터만 저장하는 방법 어떤 것이 좋을 지 궁금해서 당근마켓 피드 & 디스커버리 팀에서 일하는 지인에게 어떤 것을 사용하냐고 물어봤어요! 결론은 예전에는 첫 번째 방법처럼 DB에 BinaryData로 저장하다가 CDN 사용 이점때문에 두 번째 방법으로 갈아탔다고 하네요. 추가로 오브젝트 스토리지에 영상물을 저장한다고 했습니다. 저는 오브젝트 스토리지가 어떤 것인지도 잘 몰라서 스토리지 종류에는 어떤 것이 있는 지 알아보기..

Apache JMeter란 무엇인가? (+ 사용 방법 with 성능 및 부하 테스트)

Apache JMeter Apache JMeter는 서버가 제공하는 성능 및 부하를 측정할 수 있는 테스트 도구이다. JMeter는 순수 Java 애플리케이션 오픈소스이며 서버나 네트워크 또는 개체에 대해 과부하를 시뮬레이션하여 강도를 테스트하거나 다양한 부하 유형에서 전체 성능을 분석하는 데 사용할 수 있다. 비슷한 부하테스트 도구로는 Apache Benchmark, Ngrinder, Pinpoint, Gatling등이 있다. 다음은 Apache JMeter가 가진 특징을 나열한 것이다. 다양한 프로토콜/서버를 테스트할 수 있다. 웹 - HTTP, HTTPS SOAP / REST 웹 서비스 FTP 데이터베이스 (JDBC 사용) Mail (SMTP, POP3, IMAP) ... CLI 지원 CI 또는 C..

카프카란 무엇인가? (+카프카 구성요소)

카프카(Kafka)란? 카프카(Kafka)는 Pub-Sub 모델의 메시지 큐의 한 종류이다. 2011년 미국 링크드인(Linkedin)에서 개발했다. 더 자세히 살펴보자. 다음은 카프카 개발 전 링크드인의 데이터 처리 시스템이다. 기존 링크드인의 데이터 처리 시스템은 각 파이프라인이 파편화되고 시스템 복잡도가 높아서 새로운 시스템을 확장하기 어려웠다. 이로 인해 새로운 시스템의 개발 필요성이 높아졌고, 다음과 같은 목표를 가지고 새로운 시스템을 개발했다. 프로듀서와 컨슈머의 분리 메시징 시스템과 같이 영구 메시지 데이터를 여러 컨슈머에게 적용 높은 처리량을 위한 메시지 최적화 트래픽 증가에 따른 스케일아웃이 가능한 시스템 다음은 카프카를 적용한 후 링크드인의 데이터 처리 시스템이다. 한 눈에 보기에도 훨..