[풀스택] HTTP's streaming / Curl / SOA / Microservice

 

 

 

HTTP Client Modules in Python

• Standard Libraries
  • urllib : URL handling module
    URL을 전문적으로 처리하는 python 라이브러리 
  • http.client : HTTP protocol client module
• Non-Standard Library (recommended)
  
  • 3rd - party
  • “Requests: HTTP for Humans”
  • Installation required ( pip install requests ) Elegant and simple HTTP library for Python
  • import requests required
  • 클라이언트 측에서 사용한다면, request를 쓰세요
  • 한 줄이면 끝 - 정말 쉽다

 

 

 

 

HTTP Server Modules in Python

• http.server - HTTP servers (standard library)
  • http.server.HTTPServer 클래스
    TCP/IP 서버 개발과 유사
  • http.server.ThreadingHTTPServer 클래스
  • http.server.BaseHTTPRequestHandler 클래스
  • Client 디버그를 위한 간단한 서버 구동 방법
    • 추가적 개발을 안 하더라도 서버가 뜬다!
    • python -m http.server
    • python -m http.server 8000
    • python -m http.server 8000 --bind 127.0.0.1
    • python -m http.server --directory /tmp/
    • parameter을 주거나, directory 지정도 가능 

 

 

 

HTTP의 목적

• “멀티미디어 웹 콘텐츠 전송”이 아닌 “정보 교환” 임
• 웹 콘텐츠 서버는 django (장고) 웹 프레임워크 등을 권장

 

• HTTP1.1의 문법을 이해하는 일 
• 컨텐츠를 주고 받는다? 해야할 일이 훨씬 많은 것 
• 웹 서버 X, HTTP 서버 -> 리퀘스트에 응답하는 애
• 웹 서버 - HTTP를 쓰지만, 멀티미디어 컨텐츠를 실어나른다 -> 장고를 쓰는 것 
• 웹 base의 서버 application
• http 기반의 서버 어플리케이션은 매우 많다. 
• 공통점 - http를 깔고 있다 -> 그 위에 더 올라감

 

 

 

HTTP GET & POST server example

1. 간단하게 웹 브라우저로 할 수 있다. 간단히 get 써보기 가능
2. 파이썬으로 import request로 접속 가능
3. 프로그래밍까지 가능   

 

 

 

유용한 개발 도구들 

• 개발자 모드 네트워크 
  • 받고 있는 element와 처리 시간도 모두 보여줌
• http 서버를 실행시키면 무엇을 할까? 
  • 파일이 그대로 보인다!
  • 현재 디렉토리의 파일들을 모두 보여줌
  • 파일 탐색기 기능
  • 다운로드도 가능 wow
• 컬 (Curl) 
  • 클라이언트는 다양한 방법으로 접속 가능 
    리퀘스트 사용, 그냥 웹 주소로도 가능
    여러 통신 프로토콜의 클라이언트 버전을 모두 지원 
  • 클라이언트 쪽을 하나의 application으로 구현한 것 
  • curl + URL 
    통채로 가져온 것을 볼 수 있다. 
  • 리눅스에 있는 명령 
    • 보통 파일로 저장 or 다른 프로그램에게 전달
    • 스트림 형태로 내보내도록  
    • 바이트 덩어리를 입력으로 받도록
    • 화면으로 보내주기 보다는 (not GUI)
    • 결과를 받아, 다른 곳으로 입력을 하도록
      -> batch file 

 

 

 

HTTP의 영상 streaming

• 유튜브에 영상 업로드 - 가공중입니다 문구
• 내가 업로드 한 포맷과 해상도
• 영상을 서로 다른 표준 해상도로 전부 다 바꿈
  저사양 단말기에서도 볼 수 있도록 

 

• 4K라면, 파일을 작은 단위로 쪼갬 
  4K -> 작은 파일들의 모음 

 

• 첫번째 파일을 HTTP GET request 
  계속계속 GET을 하는 것 
• 오는 속도를 체크
  -> 느려지네? -> HD의 3번째 거 가져와 
  해상도 변화의 원리 (이유)
• 끊임없이 http request 

 

• 메세지의 간격이 균등하게 온다면 
• -> 속도(해상도) 좀 올려볼까? 
• 다음 조각은 1080으로 줘

 

• 동영상 업체가 http 쓴다면? -> 프로토콜 TCP 
• 압축된 것 풀기 + 버퍼링 시간 (실시간 dynamic 아님!)
• 천천히 받으면서, 에러 복구하면서 쌓아 놓고,  제 시간 되면 플레이
• 에러 검출 및 복구를 하는 것 (광고)
• 그 시간에 버퍼링 시간을 버는 것 

 

• HTTP -> TCP 기반
  TCP의 문제를 고스란히 가져 감 
  연결 설정 시간 + slow start
• 유튜브, 넷플릭스 마저도 해당 문제를 겪었다

 

• ex) 명동 실시간 라이브
  서버에서는 압축해서 인코딩
  http 라이브 스트리밍 서버 -> 클라이언트
  이미 인코딩 된, 쪼개진 영상을 보내는 것 뿐
  -> static resource
• 서버에서 클라이언트까지 늦게 도착한 경우 
  위성 통신 sky life (위성에서 오는 속도가 느려서)
• 퀄리티가 reasonable한 수준 (실시간 방송)
  화질이 그리 좋지 않더라도, 표준 코덱을 하나만 찍어서 라이브 송출
  압축을 하는 것에는 시간이 많이 걸리고, 
  압축을 푸는 데에는 빠름

 

 

 

 

< 추가 설명 >

• SOA (Service Oriented Architecture)
• Microservice / Serverless / Cloud Native
  • OpenStack
  • Docker / Kubernetes
• SOAP (Simple Object Access Protocol)
• REST (Representational State Transfer) & RESTful
• JSON (JavaScript Object Notation)

 

 

 

https://azderica.github.io/01-architecture-soa/

 

 

 

Monolithic vs SOA vs Microservice

1. monolithic

• 서버 -> 거대한 아키텍처 하나
• 메인 프레임 급 굉장히 막강한 컴퓨터 (유닉스 계열)
• 굉장히 좋은 프로세서 사용
• tmi) 운영체제 입장에서, 리눅스도 monolithic 단어 씀 

 

2. SOA - Service Oriented Architecture

• 하나의 컴퓨터가 다룰 수 없는 복잡한 문제
• 인텔CPU 리눅스 + 묶었더니
  메인프레임에 도전할 성능이 나오기 시작함
  가격도 저렴
• 한 대로 만들던 소프트웨어
  여러 개의 프로그램으로 분리시킨 후 
  네트워크로 묶은 것
• 서비스 오리엔티드 아키텍처 SOA
  현재(micro)와 과거(monolithic)의 중간 개념

 

3. microservices

• 우리의 시대 - micro service
• 100개의 기능
  극단적으로, 100개로 쪼개서 100대의 컴퓨터에서 돌려
• 기능을 잘개 쪼개서, 여러 컴퓨터에서 동시 다발적 처리
• 이를 통신을 통해 연결

 

 

 

< monolithic vs SOA >

• monolithic
  • 하나의 거대한 프로그램 내부의 모듈들이 하나로 통합됨
  • 하나의 프로젝트 내부에 소스코드들 -> 빌드 -> 거대한 하나의 프로그램
  • 이런 애들이 서로 대화를 나눌 경우는 별로 X
  • 공유 DB 사용, 동시다발적 작업X
• SOA
  • 별도의 프로그램들로 구성됨
  • 쪼갠 이후, 일의 선후 관계가 발생
  • 앞에 애가 마치면, 통신을 통해 다음 애에게 정보 전달
  • 서버 to 서버, 전후 관계가 생겼다. 
  • 분화 작업이 시작 -> 서버 간 통신을 HTTP로 시작!  

 

 

 

< microservice >

• 개발에서 통합하고, 배포도 자동 -> 쭉 자동화된 시스템
• 수천 수만개의 컴퓨터(CPU)를 생각하여 설계됨
• 작은 프로그램들을 쫙 뿌리는 방식으로 구현
• 하나의 함수가 몇 개의 컴퓨터에서 돌아가는, 마이크로 서비스
• 굉장히 작은 단위로 개발한다

 

 

 

Microservice : Cloud Computing

• 오픈 스택
  • CPU + 디스크 + 네트워크 
  • 빌려서 사용하고, 필요 없어지면 반납한다.
  • 가상 머신을 띄우는 스킴
  • ex) 서버 시스템의 운영체제가 리눅스 
    회사 개발도 다 리눅스로 
    -> 리눅스 위에 리눅스가 올라가게 됨
    리눅스 위에서 리눅스를 띄우냐 -> 성능저하 문제 발생
• 도커 & 쿠버네틱스
  • 가상 머신 기법 X
  • 동작하고 싶은 프로그램이 필요한 라이브러리, 환경 변수, 본인 자체 등
    컴퓨터에 소프트웨어 설치 및 삭제가 쉬운 컨테이너 기술 
  • 수천 수만 대에 동작하게 하자 
    
    
  • 도커 - 설치 및 해제 
    쿠버네티스 (오케스트레이터) - 수천 개에 뿌리자 
  • 모두 리눅스 foundation
    microservice 기반으로 개발
    cloud native foundation
    수천 수만대의 CPU 디스크, 연결하는 네트워크 개념
    프로그래밍을 하고, 운영을 하는 -> 여기 관심있는 사람은 여기로 모여라
    서버와 관련 + CI/CD, 데브옵스 -> 다 여기로 모임
    
  • Cloud Native 
    클라우드 환경을 고려하여, 소프트웨어 개발, 운영하는 것 
  • kubernetes
  • 300만 개의 코어에서 구글 서비스를 만들기 위한 서비스
    적은 인원을 통해, 효율적으로 컨테이너를 운영할 수 있다. 
    컨테이너 -> 하나의 실행 프로그램(서버급 프로세스)
    수 억 개의 프로세스로 나누어서 실행
    
    
  • 가상머신 위에 올라온 프로그램 
    윈도우, 리눅스, 유닉스 위에서 (호스트 OS)
    이 위에 다시 리눅스 유닉스를 띄움 (게스트 OS)
  • 리눅스 위에 도커를 띄우면 
    별도의 운영체제를 올리지 않고,
    어플리케이션과 라이브러리들을 설치했다가, 같이 삭제할 수 있다. 
  • Docker - 윈도우와 리눅스 연결 가능

 

 

 

SOAP & REST/RESTful

2000 SOA 등장
통신 시 HTTP 사용
TCP/UDP 등 소켓 프로그래밍이 아닌
-> 함수 호출과 유사한 response 방식 
-> 프로그램 짜는 것이 쉽다

이때 주고 받는 정보를 어떻게 표현하는가? 
XML -> 가장 쉬운 축소판이 html
무한 극강의 over spec 투입
xml 처리하느라 너무 힘들었다

SOAP

service oriented architecture protocol
파싱 -> xml에서 원하는 데이터 추출하는 기술
오버헤드가 너무 큰 데?

 

2007
HTTP 위에 대안들을 올림 
JSON / RESTful 웹 서비스 
HTTP를 쓰는 것은 동일
문서 만드는 방식, 복잡한 XML을 쓰지 말자

JSON - 자바 스크립트의 노테이션 
(파이썬의 리스트, 딕셔너리, 인티저 등에 매핑)
왜 함수 호출인데, 문서를 주고 받고 있지? 
함수 호출하는 것처럼 데이터를 주고 받자

정적인 html을 동적으로 바꿔줄 수 있는 프로그래밍 언어 JS

왜 JS? 네트워크를 타는 언어 JS ! (파이썬, C 아니라)
이러면서 REST 단어 등장하기 시작