infra19 [Network] HTTP Keep-Alive VS TCP Keep-Alive 제대로 알기 안녕하세요. 지난 시간에 Apache HttpClient 코드를 분석하면서 Network에 대해서 훑어보는 시간을 가져보았었습니다. 그러면서 Keep-Alive에 대해서 간단히 짚고 넘어갔었는데요. 오늘은 이 Keep-Alive에 대해서 헷갈릴 수 있는 부분들을 정리해보도록 하겠습니다.개요Keep-Alive는 Connection을 유지하기 위한 메커니즘입니다. TCP와 Http 모두 Keep-Alive로 Connection을 유지합니다. 둘을 햇갈릴 수 있습니다. 하지만 이 두 Keep-Alive는 완전 다르기 때문에 구분해서 알아둘 필요가 있습니다.Connection은 너무 오래유지하는 것도 너무 짧게 유지하는것도 모두 리소스적인 낭비로 이어질 수 있습니다. 너무 오래 유지하게 되면 더 이상 사용하지 .. 2024. 6. 2. [Network] Apache HttpClient의 설정으로 알아보는 클라이언트 관점의 네트워크 속성들 개요네트워크에 대해서 꼼꼼하게 이해하고 사용하면 좋겠다라는 생각을 했습니다. 어디서부터 시작할까를 생각했을 때 가장 쉽게 접근하고 사용할 수 있는 영역부터 시작한다면 좋겠다라는 생각으로 정리하며 이글을 써보게 되었습니다. 다른 서버를 호출하는 HttpClient의 설정을 하나하나 알아보며 이 설정들은 어떤것을 뜻하는지 이해해보도록 하겠습니다.Apache httpClient오늘 예제로 사용할 코드는 Apache HttpClient 코드입니다. Apache HttpClient는 현재도 관리되고 있는 몇 안되는 java 기반의 http client 중 하나입니다. 저는 해당 라이브러리를 아래의 이유로 사용하고 있습니다.현재도 메인테이닝되는 중non-blocking IO 지원코루틴을 명확하게 지원feign과 연.. 2024. 5. 17. [gRPC + java or kotlin] gRPC를 직접 구현재보자 - 공통 모델편 안녕하세요. 오늘부터는 gRPC를 직접 구현해보는 시간을 가져보도록 하겠습니다.총 3개의 챕터로 진행될 예정이며 이번 포스팅은 공통 모델, 서버, 클라이언트 편으로 나누어서 진행하려고 합니다.오늘은 protocol buffer를 이용해서 java에서 공통된 모델을 만드는 과정을 보도록 하겠습니다.IDL(Interface Defintion Language)gRPC는 Interface를 먼저 정의해야한는 언어라고 말씀드렸습니다. 이부분에 대해서는 이전 시간에 [gRPC] protocol buffer3를 실제로 사용해보자 포스팅을 참고하시면 좀 더 자세한 내용을 알 수 있습니다. 오늘 사용할 protocol buffer 파일은 아래와 같습니다. 각 라인의 설명은 코드에 달아두었습니다. 위 링크에서 proto .. 2021. 7. 31. [gRPC] protocol buffer3를 실제로 사용해보자 안녕하세요. 오늘은 gRPC의 2번째 시간입니다. 오늘은 gRPC에서 사용하는 IDL(Interface Defintion Language)인 protocol buffer을 실제로 사용해보도록 하겠습니다. 기본프로토콜 버퍼(protocol buffer)는 .proto의 확장자를 파일명으로 가집니다. 그리고 내부의 기본적인 구성은 아래와 같습니다.syntax = "proto3";message SearchRequest { string query = 1; int32 page_number = 2; int32 result_per_page = 3;}위의 구성을 통해 알 수 있는 내용을 보면 아래와 같습니다.첫 라인에는 syntax로 proto3를 사용한다고 명시해줍니다. 명시하지않으면 기본 값으로 proto2의.. 2021. 7. 25. [gRPC] gRPC에 대해서 알아보자 - 기본 컨셉편 안녕하세요. 오늘은 gRPC에 대해서 알아보는 시간을 가져보도록 하겠습니다.gRPC 개요gRPC는 HTTP/2를 기반으로 Protocol Buffers로 정의하며 통신시 바이트 스트림으로 통신하게 됩니다. 따라서 Json 기반으로 통신하는 Rest API 보다 더 가볍습니다. 또한 gRPC는 HTTP/2 기반이기 때문에 하나의 채널 커넥션을 맺고 그 커넥션을 통해서 동시에 메시지를 보내고 처리할 수 있습니다. 이런 이유로 전체적인 통신 속도의 향상 또한 크게 기대할 수 있습니다. ( 바이트 스트림 통신으로 인한 latency 상승은 그렇게 크지 않다고 합니다. Link 참조)개요gRPC는 Google Remote Procedure Calls의 약자입니다. 이름에서 알 수 있듯이 RPC의 한 종류입니다. .. 2021. 7. 24. 리눅스 명령어 사용법 ( tail, head, more, less ) 안녕하세요. 어느덧 포스팅의 갯수가 172개가 되었습니다. 이번 포스팅으로 173번째를 맞이하게 됩니다. 한번 돌아봤었는데 제가 가장 먼저 썼던 포스팅이 리눅스 많이 사용하는 기본명령어 5가지 모음 라는 포스팅이었습니다. 들어가보시면 아시겠지만... 내용도 너무 대충이고.. 지금과는 많이 다른 느낌입니다. 언젠가는 한번 갱신해야지 라고 생각하고 있었는데요. 이번에 관련하여 새로운 내용을 추가하는 포스팅을 진행하고자합니다. 오늘 공유하고자 하는 포스팅은 unix 계열 terminal(unix, linux, mac 등)에서의 명령어에 대해서 알아보는 시간을 가져보고자합니다. 아래 파일은 명령어로 테스트 해볼 파일의 내부입니다. { "content": [ { "id": "com.ncsoft.lineagem19.. 2021. 7. 3. [Linux] top 명령어로 서버의 상태 파악하기 안녕하세요. 오늘은 linux의 top 명령어어 대해서 분석하는시간을 가져보도록 하겠습니다.TOP 명령어top 명령어는 현재 OS의 상태를 나타내주는 CLI 어플리케이션입니다. 메모리 사용량, CPU 사용량 등을 나타내주며 top를 실행하는 동안에는 주기적인 업데이트로 실시간에 근접한 내용을 보여줍니다. 리눅스에서 top 명령어를 실행하면 아래와 깉이 노출됩니다. 위에는 전체의 요약이 있으며 아래에는 각 프로세스마다 구체적인 내용을 포함하고 있습니다.요약 영역요약 영역은 top에서 상단에 위치하고 있습니다. 이 요약영역은 전체 프로세스가 OS에 대해서 리소스를 어느정도 차지하고 있는지를 알려줍니다. 요약 영역에 나타나는 대표적인 값은 시간, 유저, 로드 에버리지(Load Average), 테스크(Task.. 2021. 2. 23. [HTTP] HTTP Cache - 프로세스와 기본 헤더 안녕하세요. 오늘 여러분들에게 소개해드릴 내용는 HTTP의 Cache 프로세스와 관련된 기본 헤더들입니다. 웹사이트를 통해 이미지 , js, html 파일 등의 데이터를 가지고 올 때 해당 데이터의 크기만큼의 통신 데이터 처리가 필요합니다. 동일한 이미지를 접속할 때 마다 받아온다면 클라이언트 입장에서도 부담이며 여러 클라이언트를 동시에 상대하는 서버에는 더더욱 부담이 될 것입니다. 이렇게 때문에 HTTP에서는 캐싱(caching)를 지원하고 있습니다.오늘은 HTTP Cache의 종류와 그 과정에 대해서 알아보는 시간을 가져보도록 하겠습니다.HTTP 캐싱캐싱은 크게 두가지의 종류가 있습니다. 사설(private) 캐시와 공유(shared) 캐시입니다. 사설 캐시는 각 Client의 로컬 캐시에 데이터를 .. 2021. 2. 4. [HTTP] HTTP 메시지 분석 하기 안녕하세요. HTTP는 현대 개발에서 가장많이 사용하는 프로토콜 중에 하나입니다. 주로 이 프로토콜을 기본으로하여 유저와 서버간 서버와 서버간의 데이터를 주고 받습니다. 오늘은 이런 HTTP의 구조에 대해서 개괄적으로 분석해보는 시간을 가져보도록 하겠습니다.http 통신의 구성http 통신은 요청과 응답이 하나의 세트로 이루어집니다. 즉, 요청(Request)에 대해서 응답(Resonse)이 오는 구조인데요. 이때 http의 프로토콜 구조는 세부 내용은 다르지만 요청(Request), 응답(Resonse) 모두 동일한 구성을 가집니다. 바로 시작줄(Start Line)과 헤더(Headers)와 바디(Body)로 구성된다는 것입니다.아래 이미지는 제 블로그(sabarada.tistory.com)을 접속했을.. 2021. 1. 28. [MSA] Elastic Stack을 이용한 중앙 집중형 로깅_실제 운영 환경 안녕하세요. 오늘은 Elastic Stack을 이용한 중앙 집중형 로깅_1 포스팅에 이어서 각각의 elastic stack을 한번 이어보도록 하겠습니다. 개론 클라우드 환경에서 중앙 집중형 로깅을 만드는 것은 로컬환경에서 세팅하는 것과 많은 차이를 가지고 있습니다. 우리가 클라우드 상황임에 따라서 고려해야하는 상황이 좀 더 추가되는 것이지요. 고려해야하는 상황과 해결법은 아래와 같습니다. 서비스는 서버에 독립적이어야 한다. docker를 통한 해결 서비스는 상황에 따라 유연하게 Scale-out될 수 있어야한다. 새로운 서버에 새로운 서비스가 인스턴스로 올라왔다면 Log Shipper(로그를 중앙으로 전달하는 프로세스)또한 Scale-out 되어야 한다. Auto-Scaling 등을 이용한 해결 kube.. 2019. 12. 18. [MSA] Filebeat와 Logstash의 비교 안녕하세요. 원래 오늘은 ElasticSearch를 실제로 적용시켜보는 과정을 포스팅하려고 했습니다. 하지만 아키텍처를 그리기 전에 한번 비교하고 넘어가고 싶어서 이렇게 번외로 비교를 한번 진행하려고 합니다. 원래 ELK Stack에서 L인 Logstash는 ElasticSearch로 data shipper 역할을 하고 있었습니다. 어플리케이션에서 생산되는 log 등에 대해서 분석 및 수집 도구인 ElasticSearch로 전송의 역할도 담당했습니다. 하지만 2015년 더 경량의 data shipper인 filebeat가 나왔습니다. 이 둘의 공통점은 무엇이고 차이점은 무엇인지, 그리고 filebeat는 어디에 쓰면 좋고 logstash는 어디에서 사용하면 좋을지 한번 알아보도록 하겠습니다. 이 글은 l.. 2019. 12. 13. [MSA] Elastic Stack을 이용한 중앙 집중형 로깅_1 안녕하세요. 저번시간까지는 Tracing에 대해서 알아보았습니다. 그리고 이번시간 부터는 중앙 집중형 로깅에 대해서 알아보도록 하겠습니다. 중앙 집중형 로깅이라는 것은 말 그대로 기존 방식의 로컬의 하드디스크에 로깅을 남기는 것이 아니라 외부에 로깅을 하는 것을 말합니다. 이런 로깅 방법의 지원으로 Elastic Stack을 이용할 수 있습니다. 원래 ELK Stack은 빅데이터 분석용으로 많이 사용되었었지만 클라우드 환경이 보편화 되며 중앙 집중형 로깅에도 많이 사용된다고 합니다. 간단한 설명 후 진행하도록 하겠습니다. Elastic Stack? 사실 Elastic Stack보다는 ELK Stack으로 많이 알려져 있습니다. 그럼 ELK Stack이란 뭘까요? 이에대한 설명은 elastic 회사 홈페이.. 2019. 12. 9. 이전 1 2 다음
