운영체제(OS): 프로그램들을 실행하는 메인 프로그램, 하드웨어의 자원들을 이용해서 응용 프로그램을 관리->커널이 함
커널: 운영체제는 내부에 여러 개의 구성요소로 나뉘는데, 그 중에서 커널은 바로 프로그램들을 중재하는 역할을 함
CPU: 컴퓨터 시스템을 통제하고 프로그램이 돌아가는 모든 계산을 함
메모리: 전기적인 신호를 내부에서 임시적으로 저장, 프로그램이 실행되는 과정을 책임
1. CPU의 계산 결과를 저장해준다. CPU가 계속 계산을 하면서 나오는 결과들을 메모리에 임시적으로 저장하고 이를 다시 CPU가 사용하는 방식입니다.
2. 프로그램이 실행되는 공간을 제공한다. 프로그램이 실행된다면 프로세스의 형태로 메모리 위에 올라가게 됩니다. 그리고 프로그램이 종료되면 메모리에서 사라집니다.
디스크: 정보를 영구적으로 저장하는 역할
프로세스들을 관리하면서 이렇게 갑작스런 입출력 장치의 신호나 예외상황을 자주 겪게 됩니다. 이 때 실행되고 있는 CPU 자원을 잠시 가져와서 갑작스러운 신호들을 먼저 처리하게 됩니다. 이때 CPU가 작업중인 프로세스는 대기 상태로 있게 되는 거
-- 빌드 : 소스코드를 실행할 수 있는 소프트웨어 산출물로 만드는 행위
최종적으로 개발자들이 짠 코드가 빌드를 통해 바로 실행할 수 있는 상태가 됨
--IDE: 코딩을 하고 디버깅, 컴파일 등의 전반적인 작업을 제공해주는 프로그램을 의미합니다.
옛날에는 코딩은 코드 편집기에서 따로 치고, 컴파일 작업은 또 별도로 공간에서 했었다면 IDE(Integrated Development Environment)는 이를 하나의 프로그램 안에서 한 번에 할 수 있게 제공해주는 프로그램
-- 네트워크 : 네트워크는 컴퓨터와 컴퓨터간의 연결
- 네트워크 연결이 되기 위해선 크게 프로토콜, IP주소, PORT 이 세가지를 필요
네트워크에서 정보를 요구해서 받는 쪽은 클라이언트(Client) / 정보를 제공해 주는 쪽은 서버(Server)
--프로토콜 : 네트워크 통신이 기본적으로 전세계적으로 가능한 이유는 규격(규칙)
컴퓨터로 원격을 접속할 때는 SSH라는 프로토콜을 사용/ 이메일을 보낼 때는 SMTP라는 프로토콜을 사용
->네트워크 통신을 위해서는 상대 컴퓨터 주소(IP)와 어떤 방식(프로토콜)으로 통신을 할지 정하게 됨
-- IP주소는 (Internet Protocol Address)는 네트워크 통신을 위한 주소로, 컴퓨터의 고유 주소가 아니라 우리가 연결하게 되는 네트워크(와이파이, 랜선 연결 등)를 기준으로 부여받는 IP 주소.. IP 주소가 컴퓨터끼리 연결을 위한 네트워크 주소
--포트 : 컴퓨터 내에 프로세스로 도달하기 위한 주소로, 컴퓨터 내에서 프로세스가 가지고 있는 주소.
-- 도메인 네임(Domain Name)은 사람이 쉽게 인식할 수 있는 네트워크용 영문 주소
->웹을 접속할 때 뿐만 아니라, 클라이언트가 서버(API 서버, 데이터베이스 서버) 등과 통신할 때 도메인 네임(URL)를 이용해서 정보를 주고받음
--라이브러리 : 프로그램의 특정 기능을 수행하도록 미리 짜여진 코드 뭉치
--프레임워크는 코드의 큰 뼈대(Frame)를 제공해줘서 그 뼈대에서 개발을 할 수 있도록 도와줌
--API는 '프로그램과 프로그램을 연결시켜주는 매개체 ---- API(Application Programming Interface)는 쉽게 이야기하면 규칙들의 집합입니다. API가 대신해주는 프로그램의 기능들을 미리 정리해서 규칙을 잘 세워두면 클라이언트는 접근할 프로그램을 모르더라도 API에 따라 손쉽게 통신을 할 수 있게 됨. 클라이언트 프로그램은 접근해야 하는 프로그램에 접근하지 않고 편하게 API를 통해 정보를 요청할 수 있도록 됩니다. 이때 API 서버는 API를 제공하는 서버라고 생각하기.
< API의 사용 사례 >
- 날씨 데이터같은 공공 데이터를 손쉽게 접근할 수 있도록 국가에서는 기상청 API를 제공한다.
- 회사의 데이터베이스의 보안 때문에 API 서버를 두고 클라이언트와 통신하게 한다.
-- Git은 소스 코드의 버전을 관리하는 툴
--Github는 git이 적용된 원격 코드 저장소
하나의 원격 저장소에서 커밋들을 패치(fetch)한 후 새로운 코드를 작성하게 돼요. 그리고 만든 커밋들을 푸시(push)하기 위해선 마찬가지로 원격 저장소에 보내게 됩니다. 이 원격 저장소의 역할을 github가 하게 됩니다.
프레임워크는 규칙을 줌 템플릿, 컨트롤러 뷰 등 -> 규칙 준수
필요할때 ㅇㅇㅇ를 빌드하기위한 ㅇㅇㅇ 라이브러리 내가 컨트롤함
-- 클라우드 시대에는 서버 전용 컴퓨터를 살 필요가 없어짐 클라우드가 컴퓨팅 파워(가상 컴퓨터)를 제공해주고 네트워크 관리를 손쉽게 제공해주기 때문 클라우드는 서버의 컴퓨팅 파워를 제공하고 네트워크 관리를 손쉽게 해줌 / 기존에 회사에서 관리해야 했던 컴퓨터들을 클라우드 회사에서 직접 관리함 (가상화 기술)
컴퓨터 간의 네트워크 설정 가능, 컴퓨터의 성능을 자유롭게 설정
-- 서버 호스팅: 온라인으로 손쉽게 서버 컴퓨터를 빌리는 것
-- 트래픽 : 네트워크 관점에서 클라이언트의 요청량
트래픽이 많아지면 성능저하, 응답 시간이 길어짐 -> 더 많은 컴퓨팅 자원(높은 CPU, 메모리)가 있어야 안정적인 서버 운영이 가능해짐 ----> 클라우드에서는 이렇게 트래픽에 대응해서 컴퓨팅 자원을 줄이거나 늘리는 스케일링 작업을 손쉽게 해줌 - 서버 컴퓨터를 늘려주거나, 성능을 높여줌.
웹을 제공해주는 웹서버, 데이터 통신을 위한 API 서버, 이미지 등의 파일을 관리하는 스토리지 서버, 로그들을 관리하는 로그 서버, 빅데이터를 저장하는 빅데이터 저장소 --->라우드에서 쉽게 사용할 수 있도록 제공해줌
-- 병목현상 : 트래픽이 높아질수록 점점 자원이 남지 않게 되고 결국 응답을 바로 못해주고 밀리게 되는 병목현상이 발생 ---> 해결법 : 스케일 업, 스케일 아웃
--스케일업 : 해당 서버의 컴퓨터 성능을 높이는 것, CPU나 메모리의 성능을 높여서 더 많은 요청에 대응할 수 있게
--스케일아웃 : 서버를 여러대로 늘리는 것, 트래픽을 분산시켜 하나의 서버가 일하는 양을 줄여주는거
-- 오토 스케일링: 클라우드가 자동으로 스케일링을 해쥼
-- 로드(Load) : 서버 입장에서 처리해야할 일
-- 로드밸런싱: 스케일 아웃을 통해 로드를 분산시키는 과정
--로그데이터 : 데이터를 바탕으로 사용자들을 분석할 수 있고, 현재 실행되고 있는 프로그램들의 상태도 확인할 수 있기 때문 / IT 제품(웹, 앱)을 통해 유저가 어디서 얼마나 머물렀고, 어디에 관심을 가지는지에 대한 전반적인 데이터를 수집합니다. 이 데이터를 클라이언트 로그 라고 합니다.
Google Analytics, Facebook Pixel 등은 유저행동을 분석해주는 서비스로 코드 몇 줄이면 편하게 클라이언트 로그를 쌓는 걸 도와주고 분석하는 환경까지 제공 ----하지만 서비스 규모가 커지면 더 자세한 분석과 커스터마이징을 필요로 합니다.
그래서 데이터 수집 환경을 구축하는 데이터 엔지니어 가 필요
서버 컴퓨터의 상태를 파악 - 모니터링 한다고 말하며, 모니터링을 하기 위해선 기본적으로 서버의 기록들이 필요함. 이를 **서버 로그** 라고함.
----보통 트래픽이 많은 API(WAS)서버, 데이터베이스 등에 모니터링 도구를 붙여서 사용
- 브라우저에서 웹이 동작하는 과정
-웹을 실행하는 환경은 브라우저입니다. 웹을 제공하는 곳은 웹 서버
- 사용자가 브라우저에서 url(도메인 주소)를 입력
- 브라우저는 웹 서버를 실행하고 있는 컴퓨터에게 요청
- 웹 서버에서는 프론트엔드 개발자가 개발한 웹을 클라이언트(브라우저)에게 전달
- Javascript가 적용 ex1) 화면이 로드될 때 마이페이지 정보를 API 서버에게 요청합니다.
브라우저 화면에 웹을 그리는 전체적인 과정을 브라우저 렌더링이라고 함
여기서 렌더링 은 프로그래밍적으로 화면을 그리는 것을 의미
-- SPA(SIngle Page Application) : 한 번 요청에 모든 페이지를 다운받습니다. 그래서 처음에는 로딩이 느릴 수 있지만, 그 이후에 페이지 전환은 빠르게 가능해서 좋은 사용성을 제공, 페이지 별로 새롭게 웹 서버에서 페이지를 다운받는 방식 MPA(Multi Page Application) 이라고 합니다. MPA는 해당 페이지만 제공해주면 되기에 초기에 화면을 빠르게 보여줄 수 있는 장점, but 새로 페이지로드해서 사용성 떨어짐
-- 웹이 웹서버와 통신해서 웹을 다운받는 방식은 크게 2가지가 있습니다. CSR(Client Side Rendering) 과 SSR(Server Side Rendering)
CSR : 브라우저 측에서 HTML,CSS, Javascript를 처음부터 실행시키는 방식으로, HTML, CSS를 전부 브라우저에서 렌더링함. 이때 웹 서버는 HTML, CSS, Javascript를 단순히 서빙(건네주는)하는 역할을 합니다. CSR은 브라우저에서 전부 언어를 실행하므로 웹 서버는 큰 부담이 없음
SSR : 웹 서버에서 HTML, CSS, Javascript 를 미리 한 번 실행시킨 후 브라우저에게 건네주는 방식 --- API 통신을 웹 서버에서 미리 진행해서 데이터를 적용할 수 있음. 그러면 최종적으로 결과가 적용된 HTML, CSS, Javascript 파일을 받게 돼서 브라우저는 더 빠르게 화면을 보여줄 수 있다. 다만 웹 서버가 그만큼 일을 더 함
--크로스 브라우징 : 브라우저의 종류에 상관없이 똑같이 웹을 보여주려함 --- 크로스 브라우징 테스트: 대표적으로 LambdaTest , 자동화 테스트를 제공하는 Selenium 등
-- 백엔드는 서비스에 필요한 데이터들을 저장하고 클라이언트(사용자, 관리자 등)를 위해 알맞게 데이터를 가공하는 역할 ---- IT 서비스에 필요한 데이터들을 저장하고 이를 목적에 맞게 가공하는 공간
--->1. API 개발
2. 데이터베이스 관리 - 데이터 모델링
3. 서버 및 클라우드 관리 - 클라우드 이용 서버 구축(클라이언트에게 정보를 줄 수 있는 서버 프로그램을 설치)
아키텍처에 따라 응답 속도, 백엔드 개발자가 개발하는 속도 그리고 비용 등 많은 부분이 결정됨
-- API 서버 : 데이터베이스의 데이터들을 가공해서 클라이언트에게 전달하는 역할
API 서버는 클라이언트와 통신해서 데이터를 넘김
프론트엔드(웹, 앱)에게 데이터를 제공하는 API 서버를 WAS(Web Application Server)라고 합니다.
API 서버가 조금 더 넓은 개념이고 WAS는 프론트엔드에게 데이터를 건네주는 서버를 한정지어서 얘기합니다.
-- 스토리지 서버 : 스토리지 서버에 파일들을 저장한 후 URL 주소를 통해 다운을 받는 방식
이미지의 경우 웹 서버, API 서버를 통해 URL 주소를 전달받습니다(이미지 자체를 받기에는 용량이 크죠.) 그러면 URL 주소를 통해 파일 스토리지에 접근해서 이미지를 다운받고 보여주는 거죠.
--캐시 서버 : 만일 API 서버에서 항상 동일한 결과를 제공해준다면 굳이 매번 데이터베이스, API 서버가 작업할 필요는 없다. -- 캐시서버 이용시 API 서버와 데이터베이스가 일을 따로 하지 않고 바로 저장된 데이터를 제공해줄 수 있게 됨
-- HTTP 프로토콜?
-특정 기기 간에 데이터를 주고받기 위해 정의됨
-웹에서 브라우저와 서버 간에 데이터를 주고받기 위한 방식으로 HTTP 프로토콜을 사용
-HTTP 프로토콜은 상태가 없는(stateless) 프로토콜 = 데이터를 주고 받기 위한 각각의 데이터 요청이 서로 독립적으로 관리가 된다(=이전 데이터 요청과 다음 데이터 요청이 서로 관련이 없다)
-일반적으로 TCP/IP 통신 위에서 동작하며 기본 포트는 80번
--HTTP Request & HTTP Response
-HTTP 프로토콜로 데이터를 주고받기 위해서 요청(Request)을 보내고 응답(Response)을 받아야 함
--URL(Uniform Resource Locators)
-서버에 자원을 요청하기 위해 입력하는 영문 주소
--HTTP 요청 메서드
-URL을 이용하면 서버에 특정 데이터를 요청할 수 있음
-요청하는 데이터에 특정 동작을 수행하고 싶으면 ? HTTP 요청 메서드(Http Request Methods)를 이용
==>GET : 존재하는 자원에 대한 요청(일반적으로 정보를 받아올 때 사용,기본 메소드)
POST : 새로운 자원을 생성
PUT : 존재하는 자원에 대한 변경
DELETE : 존재하는 자원에 대한 삭제
==>기타 요청 메서드
HEAD : 서버 헤더 정보를 획득. GET과 비슷하나 Response Body를 반환하지 않음
OPTIONS : 서버 옵션들을 확인하기 위한 요청. CORS에서 사용
-- HTTP 상태 코드(HTTP Status Code)
-URL, 요청 메서드가 클라이언트에서 설정해야 할 정보라면 HTTP 상태 코드는 서버에서 설정해주는 응답(Response) 정보
-상태 코드로 에러 처리를 할 수 있음
-주요 상태 코드는 200번대부터 500번대까지 다양하게 있음
---- 200번대의 상태 코드는 대부분 성공을 의미
200 : GET 요청에 대한 성공
204 : No Content. 성공했으나 응답 본문에 데이터가 없음
205 : Reset Content. 성공했으나 클라이언트의 화면을 새로 고침하도록 권고
206 : Partial Conent. 성공했으나 일부 범위의 데이터만 반환
---- 300번대의 상태 코드는 대부분 클라이언트가 이전 주소로 데이터를 요청하여 서버에서 새 URL로 리다이렉트를 유도
301 : Moved Permanently, 요청한 자원이 새 URL에 존재
303 : See Other, 요청한 자원이 임시 주소에 존재
304 : Not Modified, 요청한 자원이 변경되지 않았으므로 클라이언트에서 캐싱된 자원을 사용하도록 권고. ETag와 같은 정보를 활용하여 변경 여부를 확인
---- 400번대 상태 코드는 대부분 클라이언트의 코드가 잘못된 경우, (유효하지 않은 자원 요청, 요청이나 권한이 잘못된 경우)
400 : Bad Request, 잘못된 요청
401 : Unauthorized, 권한 없이 요청. Authorization 헤더가 잘못된 경우
403 : Forbidden, 서버에서 해당 자원에 대해 접근 금지
404 : 요청한 자원이 서버에 없다
405 : Method Not Allowed, 허용되지 않은 요청 메서드
409 : Conflict, 최신 자원이 아닌데 업데이트하는 경우. ex) 파일 업로드 시 버전 충돌
---- 500번대 상태 코드는 서버 쪽에서 오류
501 : Not Implemented, 요청한 동작에 대해 서버가 수행할 수 없는 경우
503 : Service Unavailable, 서버가 과부하 또는 유지 보수로 내려간 경우
-- HTTP 통신?
네트워크 통신시 사용되는 HTTP 프로토콜을 활용한 통신
아래 세가지는 요청과 응답 모두 공통적
-요청 라인에 URL, Method 같은 핵심 요청 정보가 들어갑니다. 요청과 응답에 따라 구성 요소가 다릅니다.
-Header에 HTTP 관련 여러 설정 값이 들어갑니다.
-Body에는 통신에 필요한 데이터가 들어갑니다(옵션)
-- HTTP 요청
HTTP 통신으로 서버에게 정보를 요청하기 위해선 규칙을 지켜야 함
1. 어떤 서버에게 요청할 것인지 URL이 있어야 한다. (요청 라인)
2. 어떤 방식으로 통신을 할 것인지 Method 가 있어야 한다 (요청 라인)
--클라이언트가 HTTP 요청을 할 때 정보를 담아야 하는 경우 ex) 회원가입 시 회원 정보, 상품을 만들 때 상품 정보, 로그인을 할 때 아이디 패스워드 정보를 서버에게 보내줘야됨
->GET 방식은 서버에 데이터를 전송해야 할 때 url 맨 뒤에 query를 붙임 query는 key=value 형태 POST도 URL 뒤에 query가능
->POST 메소드의 경우 HTTP의 Body 부분에 데이터를 담을 수 있음. Body는 HTTP 통신에 구조적으로 데이터를 담아서 전송할 수 있게 도와줌 ex) 대표적으로 로그인, 상품 업로드, 결제하기 등 get은 body에 못담음
-- HTTP Method
클라이언트가 서버에게 HTTP 요청 시 URL 주소, HTTP Method -> HTTP Method에 따라 서버에서는 어떤 요청인지를 파악
--HTTP 응답
1. 응답이 어떤 상태인지를 나타내는 Status Code 가 있어야 합니다 (요청 라인)- Status Code 는 200~ 500 번까지
2. 요청 결과를 Body에 담아야 합니다.
--CI는 Continuous Integration : CI 툴은 내부 컴퓨터 환경에서 프로젝트 소스코드를 통해 프로그램을 실행시킴. 즉 프로젝트 빌드를 CI 툴에서 알아서해줌
1. 코드를 짜고
2. 프로젝트를 빌드하고 테스트를 실행한 후
3. 프로젝트 저장소에 코드를 합친다.
--코드 리뷰 : 코드리뷰는 다른 개발자들이 직접 본인의 코드를 확인하는 과정
에러가 날 수 있는 부분들, 회사의 코딩 컨벤션 을 잘 지켰는지 등을 확인하고 리뷰남김
해당 리뷰를 코드에 적용한 후 다시 리뷰를 요청하는 방식으로 진행
-- QA :해당 제품이 잘 동작하는지 직접 확인하는 작업
개발자들이 테스트 코드를 작성하는 것도 일종의 QA(테스트 코드만으로 제품의 완성도를 평가하기는 어렵기 때문에 사람이 보통 추가로 QA 작업을 진행)
--서비스 배포 : 개발환경의 코드를 운영환경에 프로그램을 실행시키는 일련의 작업
QA 완료 ->사용자들이 사용하는 실제 환경(운영환경-웹 서버, API 서버, 앱 스토어 등)에 적용해야됨
개발자가 코드를 짜서 프로젝트에 코드를 합치는 작업들은 개발환경에서 진행됨
--CD(Continuous Deployment): 자동화 그리고 연속적으로 배포를 할 수 있게 해주는 것
CI를 통해 코드가 정상적으로 원격 저장소 합쳐졌다면, CD는 원격저장소에 있는 소스코드를 운영환경 컴퓨터에 최종적으로 실행시킨다
용어정리
--인프라: 폭넓은 의미로 프로그램을 실행시키기 위한 환경 / 프로그램을 실행시키기 위해선 하드웨어, 운영체제, 네트워크 등의 인프라(환경(이 필요 ->인프라 환경을 클라우드 에서 많이 제공해주고 있음
--코딩 컨벤션: 코드를 관리하고 읽기 쉽게 만들기 위한 규칙
--레거시 코드 : 이전에 짰던 코드는 옛날, 구식의 코드인 레거시 코드 가 됨 에러가 나는 코드는 아니나 비효율적이거나 가독성이 떨어지는 코드일 수도. --->이 코드들을 현재 목적과 방향에 맞게 수정하는 것을 '리팩토링'한다고 함
-- 디버깅 : 에러(버그)시 개발된 코드에서 문제를 찾는 전체 과정
--의존성dependency : 얼마나 대상들이 얼마나 서로 의존하고 있는지, 개발된 코드들끼리 의존하는 정도
