728x90
반응형

서버끼리 통신하는 작업을 하다가 방화벽이 뚫려 있는지 확인할 일이 생겼다.

ping도 쓰고 curl도 쓰는데 둘 차이가 뭔지 갑자기 궁금해져서 찾아봤다.

 

Ping

ping [대상 목적지 ip]

탁구 ping pong의 줄임말인 줄 알았는데(그런 의미도 있다고 하지만),  Packet Internet Groper의 약자라고 한다...!

확인할 IP로 인터넷 패킷을 전송하고 대상이 보낸 응답을 분석하는 방식이다. 

실제 ping google.com을 쳐보면 packets 전송상태를 나타내 준다. 

ping은 ICMP 프로토콜(TCP/IP에서 IP 패킷을 처리할 때 발생되는 문제를 알려주는 프로토콜)을 사용하는데 이 프로토콜은 OSI 7 계층의 3 layer에 해당하는 Network layer에 속하는 프로토콜을 사용한다.

OSI 7계층(리마인드,,)

 

그렇기 때문에 4 layer인 Transport layer에서 사용하는 port 정보를 이용하지 않는다.

그래서 ping 명령어로는 포트가 열려있는지 까지는 확인할 수 없는 것이다.

 

Curl

curl [대상 목적지] (default로 GET)

Curl은 Client URL의 약자라고 한다. URL로 데이터를 전송하여 서버에서 데이터를 가져오거나 서버에 데이터를 보낼 때 사용한다.

즉, curl을 활용하여 endpoint에 HTTP 프로토콜을 이용하여 PUT, POST 등의 요청을 보내고 그 결과를 확인할 수 있다.

 

 

telnet

telnet [대상 목적지] [포트번호]

ping이 단지 요청을 보내고 받아서 분석하는 명령어라면 telnet은 컴퓨터와 컴퓨터 사이를 연결해주는 명령어이다.

포트 오픈 확인까지 할 수 있는 telnet은 transport layer 를 통해 통신하는 거(겠지..?)

윈도우 컴퓨터에서는 설정을 통해 telnet을 활성화시키면 되고

맥 환경에서는 brew를 통해 다운로드하면 된다.

728x90
반응형
728x90
반응형

URI(Uniform Resource Identifier) -> 통합 자원 식별자로 인터넷에 있는 자원을 나타내는 주소

URL(Uniform Resource Locator) -> 네트워크 상에서 웹 페이지, 이미지, 동영상, 등의 파일이 위치한 정보를 나타낸다.

URL(Unifor Resource Name) -> URI의 표준 포맷 중 하나, 이름으로 리소스를 특정한다. 

 

URL은 URI의 더 일반화된 부류의 부분집합이고 URI는 URL과 URN으로 구성된 종합적인 개념이다.

 

http는 스킴(어떻게)를 의미하고 ftp, rtsp(비디오) 등의 다른 가용한 프로토콜을 사용할 수 있다.

URL은 동일하게 '스킴://서버위치/경로' 구조로 이루어져 있다.

 

(항상 까먹어서 내가 보려고 정리!)

728x90
반응형
728x90
반응형

Thread 몇개로 돌리는 애플리케이션이 있다.

어떤 thread가 어떤 작업을 하는지 알고싶었다. 그래서 thread id 찍어보고 싶은데 어떻게 찍는지 몰라서 찾아봄

val threadId = Thread.currentThread.getId

 

생각보다 많이 간단...!

728x90
반응형
728x90
반응형

Pyspark

콘솔에 로깅이 1초마다 뜨는게 거슬려서 알아봄

SparkContext.setLogLevel()

Log levels: ALL, DEBUG, ERROR, FATAL, INFO, OFF, TRACE, WARN

 

728x90
반응형
728x90
반응형

문자열 split 방법

val s = "aa bb cc"
val splited = s.split(" ")


일반적인 split은 위와 같이 하면 된다.


dot(.)이 포함된 문자열을 split 하려고 했는데 안된다.
아래와 같이 하면 된다.

val s = "aa.bb.cc"
val splited = s.split("\\.")



dot(.)은 자바 정규식 예약어이기 때문에 \(back slash)가 필요한데 \ 자체도 예약어이기 때문에 \\ 두번 붙여야 한다.

728x90
반응형
728x90
반응형

카카오 제네시스 - 카프카 기반 스트리밍 데이터 플랫폼

2021년 Kakao 에서 봤던 Cory 님(광고추천팀 - 데이터 플랫폼 개발)이 작성한 글이고 내가 요즘 공부하는 카프카, 업무와 직관된 데이터 플랫폼이라는 제목 워딩에 끌려 클릭했다.

개인적으로 사용자에게 직접 서비스될 수 있는 분야가 업무적으로 더 선호된다. 하지만 이미 플랫폼에 집중된 내 업무로는 직접 서비스할 기회는... 적다. 거의 없을 수도..

그런데 광고 추천이라니. 내가 직접 서비스하진 않더라도 결국에는 개인화된 광고를 서빙하는 작업을 하는 플랫폼일 것이다! 완전 끌린다.

(나는 누가 쓰는지도 모르고.. 그냥 들어오는 데이터 ETL 하는 느낌인데 말이다.. ㅠㅠ)

아무튼 그래서 이번 기술 블로그 엄청 재밌게 읽었다! 공부 의욕 뿜뿜!

들어가면 나오는 내용이지만 나만을 위한 정리

  • 기존 카프카 데이터 파이프라인 아키텍처의 관리에서의 어려움과 리소스 낭비로 새로운 카프카 커넥트 기반 데이터 플랫폼을 구성
  • 고려한 점: 오너십 / 모니터링 / 배포 / 데이터 리니지(화면)
  • 카프카 커넥트 사용
    • ETL 역할을 수행하는 것을 커넥터라고 하며, 싱크 커넥터는 consumer, 소스 커넥터는 producer 역할을 한다.
    • 카프카 커넥트는 분산 커넥트와 단일 커넥트로 나뉜다.

  • 카프카 커넥트를 API 동작이 아닌, 지속적 운영을 위해 vue.js로 어드민 페이지를 만들어서 모든 파이프라인 관련 동작을 제네시스 웹을 통해 수행 가능하록 개발.
  • 카프카 커넥트를 운영하며 고려해야 할 점
    • 반드시 웹 화면이 필요
      • REST API를 통해 파이프라인을 생성, 수정, 삭제할 수 있지만 언제까지나 API 툴로 운영할 수가 없음
      • 오픈소스로 나와 있는 카프카 커넥트 웹을 사용해도 됨
    • 커스텀 커넥터 개발 → 보안 관련 이슈
    • 커넥터 클러스터 구분 운영
      • 커넥터의 특성(메몰리 많이 사용/CPU 많이 사용)에 따라 커넥트 클러스터를 분리하여 운영하는 것을 고려

도커로 말아서 올렸더라. 도커도 또 공부하려면 한참인데 정말...!!

이거 다 개발하려면 진짜 많은 시간과 노력이 들었겠다 싶다.

나도 하고 싶다. 배울게 너무 많다...!


한 줄 느낀 점:
플랫폼 운영하려면 알아야 할게 많다. 좋게 생각하면 배우는 거 좋아하는 나한테 딱!

728x90
반응형

+ Recent posts