/ = prefix
- /16~28 = prefix 16~28
- 인바운드는 네트워크로 들어오는 정보
클라이언트의 정보 업로드의 경우 등..
클라이언트 → 서버 - 아웃바운드는 클라이언트로 나가는 정보
서버에서 정보를 다운로드 받는 경우 등..
서버 → 클라이언트
강의
프로세스는 뭘까?
- 컴퓨터에서 연속적으로 실행되고 있는 컴퓨터 프로그램
- 알아두면 좋은 강의!
CPU | RAM (memory) | DISK (HDD, SSD) - 메모리(램) 목적? : 자주 사용하는 데이터를 저장한다?
- CPU의 목적? : 연산, 로직 처리.
- DISK의 목적? : 데이터의 저장
- CPU와 메모리는 필수불가결!
- CPU <-> 메모리 관계 : 데이터 연산 및 처리
메모리의 단점 : 용량이 작다. + 휘발성이다(데이터 저장을 할 수 있긴 하지만, 켜져있는 동안만 저장된다. 컴퓨터의 전원이 꺼지는 동안 사라진다!)
메모리의 장점 : 겁나 빠름. HDD보다, SSD보다 빠르다! DISK보다 훨씬훨씬 빠르다. - CPU <-> DISK ? : 디스크 연산속도가 느리기 때문에 CPU의 연산속도가 빠르더라도 전체적인 연산속도가 느려진다.
DISK의 단점 : 느리다(메모리에 비해)
DISK의 장점 : 데이터를 지속적으로 저장할 수 있다. 용량이 메모리보다 (상대적으로) 크다. - CPU 아키텍처 캐시. L1, L2, L3 ... 캐시
L1 <- L2 <- L3 ... - 디스크에 카카오톨 프로그램을 저장(설치)했다.
이것은 디스크에 저장한 것. - 파일... 의 종류
ppt 파워포인트 파일
docx 워드파일
txt 텍스트파일
hwp 한글파일
exe 실행파일 : 카카오톡 실행파일은 디스크에 있다 > 실행을 하면, 코드가 메모리에 올라간다 혹은 상주한다. > 디스크에 저장이 되는 것.
디스크에 있는 실행 가능한 파일을 프로그램이라고 부른다. - CPU <-> 메모리 (코드)
- 프로그램이 메모리에 올라가서 CPU 연산을 하는 상태 > 프로세스
프로그램 -> 프로세스
CPU -> 프로세서 - 프로그램은 하나의 실행파일에 불과하지만, 실행시키는 순간 메모리에 올라가며 CPU와의 상호작용을 통해 연산을 시작하고, 그때부터 프로세스가 된다.
OSI 7 LAYER 구조와 계층 별 기능
- 실제로 존재하지는 않으나, 네트워크가 어떻게 통신하는지를 7단계로 구분한 단계.
암기까지는 필요없지만, 개념적으로는 아는 것이 좋음. - 1) 물리적인 단계(USB 등) (물리적)서버
2) 데이터 링크(이더넷 등) 브릿지
3) 네트워크 단계 (IP 등) 라우터. 원래라면 상대방 IP와 내 IP를 알아야 통신을 할 수 있다.
4) 전송 단계 (TCP, UDP 등)
5) 세션 단계
6) 구현(Presentation) 단계
7) 애플리케이션 단계(HTTP) - URL을 넣는 순간 HTTP 통신이 시작됨.
인캡슐레이션 : 레이어를 내려가면서 (7 → 1) 데이터가 쌓임.
- IP를 모두 외운다는 것은 사실상 불가능. →
도메인을 만들어 IP를 매칭했다. → DNS 서비스라는 것을 이용해서 IP와 매칭되어 있는 도메인을 확인할 수 있다.
표준화는 도대체 무엇인가??!!!
전체적인 피드백
- 클라이언트는 서버에게 요청(Request)전송
서버는 클라이언트에게 응답(Response) 전송
웹의 경우 80포트 이용. ssh의 경우 22포트 이용 - 웹 서버의 경우는 TCP보다는 HTTP라는 프로토콜을 더 많이 이용한다.
규약만 맞추면 어떤 것으로도 서비스를 이용할 수 있다. - 브라우저는 규약들을 사람들이 볼 수 있게, 즉 UI를 이용해서 사용할 수 있게 만든 것이다.
브라우저를 유료로 팔았었다! 옛날에는. Netscape - 정적 컨텐츠는 HTML로 제공. 보통 DB에 저장된 자료를 뿌려주는 것을 정적컨텐츠, DB와 연동해서 내용을 동적으로 뿌려주는 것이 동적 컨텐츠.
- 움직임이 있다고 동적컨텐츠는 아니다! DB와 연동해서 내용이 변동되어야만 동적컨텐츠라고 할 수 있다.
- 웹 서버는 아파치가 많이 사용되지만, 요즘 nginx가 무섭게 추격하고 있다.
- 로드 밸런싱은 부하분산!
- WAS는 동적인 서비스를 다루는 서버이다. 단, 정적 컨텐츠도 제공할 수 있다.
- ASP, PHP, JSP 등등이 있다.
- 톰캣은 8080을 사용함. → 포트는 변경이 가능하지만, 잘 바꾸지는 않는다. 대중성 때문에! 보안성을 생각하면 바꾸는 것이 맞지만.. 대중성을 무시할 수 없다. 접속하기 위해서 추가적인 처리를 매번 해야한다면 고민이 될 것이다.
SSL : 시큐어 소켓 레이어
- 웹의 모든 정보를 암호화하기 때문에, 일반인은 알아볼 방법이 없다.
- 때문에 거의 모든 웹 서비스는 SSL을 사용한다고 할 수 있다.
- 클러스터 : 여러 개를 묶으면 클러스터.
- 고가용성을 목적으로 많이 사용한다.
- 묶는 것 : 클러스터링
클러스터링을 통해 가용성을 높이고 성능 향상도 꾀할 수 있다. - 슈퍼컴퓨터는 슈퍼 클러스터링 컴퓨터라고 할 수 있다.
DB : RDB vs NoSQL
관계형과 비관계형
- 무결성 : 데이터가 변경되면 안됨. (특별한 이유 없이는)
- 관계형과 비관계형 중 어느 것이 좋다고 할 수 없다. 상황과 필요성에 따라서 달라져야한다.
- NoSQL는 여러 형태를 갖을 수 있다.
- RDB : MySQL, MariaDB, PostgreSQL
- MySQL 커뮤니티 버전이 무료.
- NoSQL : redis
- redis는 인메모리(캐시) 기반의 DB. 메모리처럼 빠르기 때문에 DB앞에 둬서 처리속도 향상을 늘릴 수 있다.
표준구성
- 클래식은 네트워크가 분리가 되어있지 않기 때문에 보안에 조금 하자가 있다.
- 의도치 않은 사용자가 생길 수 있다.
- VPC는 네트워크가 분리되어 있다!
- 클래식 환경에서 서버를 3개를 만들고 성능을 구분해도 3tier환경이라고 말할 수 있다. 다만, 보안상 안전하다고 말하기는 애매..
- NAT는
나트라고 읽음. - NAT gateway는 필수는 아님. 여러 목적이 있다.
- ACG는 서버 바로 앞에 있다.
- 허용만 가능
- NACL : Subnet의 방화벽.
- 허용/차단 가능. 선택적 보안. 필수는 아니다. 그러나, 경험상 안하는게 나음. 오류가 났을 때 고치기가 어려움 ㅠㅠ.
Inbound/Outbound
- 상대적 개념이다.
주체가 서버인가? 아님 클라이언트인가? - 클라이언트 → 서버 (inbound)
서버 → 클라이언트 (outbound)
도커
- 가상화는 맞지만, 가상화보다 더 가벼운 컨테이너 기술을 사용한다.
가볍고, 표준화가 되어 있다. Docker Container Image. - 개발자들이 굉장히 좋아한다. 근데 거의 망함..?
쿠버네티스
- 도커에서 처리가 잘 안되는 부분들을 쿠버네티스가 기술적으로 업그레이드 함.
- 자격증 준비해라!
- 알아두면 무조건 도움됨.
- 이것만 알아도 취업 가능.
- 헬름을 쓰면 좀 편해진다.
앤서블
- 자동화 관리가 중점.
- 명령을 자동화, 다중화 할 수 있다. 편의성 굿굿.
- IaC는 좋은 기능. 다만
Terraform이 더 대표적이다.- IaC는 버전관리하기 좋다!
- Terraform이란?
- VM 제작을 코드로 규격화시키고,
테라폼을 실행시키면, 수많은 서버를 만들 수 있다. - 인프라 관리에도 좋다.
- VM 제작을 코드로 규격화시키고,
Q&A
- 아파치에서 프로세스 낭비가 심한 이유
- 아파치의 경우 작업이 생성되면 부모 프로세스 밑에 자식 프로세스가 생성된다. 클라이언트의 요청에 의해 자식프로세스가 생성되고, 요청이 늘어나면 늘어날 수록 많은 프로세스가 늘어나고 계속 CPU와 메모리를 점유하게 된다.
- NGINX에 비해 낭비가 발생할 수 있다.
- 비관계형 DB가 빅데이터에 좋은 이유
- 빅데이터에는 정형화되어 있는 데이터보다 정형화되어 있지 않은 데이터가 더 많다. 빅데이터는 너무 다양한 형태의 데이터가 존재하기 때문에,
- 데이터의 형식에 크게 구애받지 않은 비관계형 DB가 좋다.
- 관계형 DB는 데이터 저장에 필요한 규칙이 너무 빡빡하다.
