ZU-TECHLOG

[취업준비] 개발직군 기술 면접 정리 - CS질문

J1Yun — Sun, 22 Oct 2023 10:33:27 +0900

운영체제

https://spotted-green-b02.notion.site/59b5ffefce52423f9a0a5b41e9aef18b?pvs=4

면접 질문 - 운영체제편

프로세스 vs 스레드, 멀티 프로세스 vs 멀티 스레드

spotted-green-b02.notion.site

네트워크

https://spotted-green-b02.notion.site/2c70aac881ec42528494f9913d64b2a2?pvs=4

면접 질문 - 네트워크편

OSI 7 Layer

spotted-green-b02.notion.site

데이터베이스

https://spotted-green-b02.notion.site/DB-f55b4e11dfce4d38ab28a72c81e5fe5f?pvs=4

면접 질문 - DB편

DDL, DML, DCL

spotted-green-b02.notion.site

자료구조, 알고리즘

https://spotted-green-b02.notion.site/4ae5f7c49a0b46c1868905abc7541db2?pvs=4

면접 질문 - 자료구조,알고리즘편

스택, 큐, 트리, 힙

spotted-green-b02.notion.site

디자인패턴

https://spotted-green-b02.notion.site/31d81da91de54cbd9feaa3e0bfad7a00?pvs=4

면접 질문 - 디자인패턴편

싱글톤

spotted-green-b02.notion.site

자바(Java)

https://spotted-green-b02.notion.site/27ce2e5e9fa7454f9b1b19635a9e2a29?pvs=4

면접 질문 - 자바편

라이브러리와 프레임워크 차이

spotted-green-b02.notion.site

[취업준비] 개발직군 기술 면접 질문 - 자료구조, 알고리즘 편

J1Yun — Sun, 22 Oct 2023 10:24:59 +0900

자세한 내용 정리

https://spotted-green-b02.notion.site/4ae5f7c49a0b46c1868905abc7541db2?pvs=4

면접 질문 - 자료구조,알고리즘편

스택, 큐, 트리, 힙

spotted-green-b02.notion.site

면접에 자주 나오는 자료구조/알고리즘 개념

스택, 큐, 트리, 힙
Array/ArrayList vs LinkedList
암호화 알고리즘
이진 트리, 이진 탐색 트리
그리디 알고리즘 vs 동적계획법(DP)
B트리
해시
그래프

[취업준비] 개발직군 기술 면접 준비 - 디자인패턴 편

J1Yun — Sun, 22 Oct 2023 10:22:01 +0900

자세한 내용 정리

https://spotted-green-b02.notion.site/31d81da91de54cbd9feaa3e0bfad7a00?pvs=4

면접 질문 - 디자인패턴편

싱글톤

spotted-green-b02.notion.site

면접에 자주 나오는 디자인패턴 개념

싱글톤 패턴
팩토리 패턴
이터레이터 패턴
전략 패턴
옵저버 패턴
프록시 패턴
MVC / MVP / MVVM 패턴

[취업준비] 개발직군 기술 면접 준비 - DB 편

J1Yun — Sun, 22 Oct 2023 10:16:59 +0900

자세한 내용 정리

https://spotted-green-b02.notion.site/DB-f55b4e11dfce4d38ab28a72c81e5fe5f?pvs=4

면접 질문 - DB편

DDL, DML, DCL

spotted-green-b02.notion.site

면접에 자주 나오는 DB 개념

DDL, DML, DCL
트랜잭션
RDBMS vs NoSQL
캐싱(Redis)
인텍스
정규화와 반정규화
ORM
Key
트리거
DELETE, TRUNCATE, DROP

[취업준비] 개발직군 기술 면접 준비 - 네트워크 편

J1Yun — Sun, 22 Oct 2023 10:12:55 +0900

자세한 내용 정리

https://spotted-green-b02.notion.site/2c70aac881ec42528494f9913d64b2a2?pvs=4

면접 질문 - 네트워크편

OSI 7 Layer

spotted-green-b02.notion.site

면접에서 자주 나오는 네트워크 개념

OSI 7 Layer
TCP vs UDP
TCP/IP 흐름제어와 혼잡제어
HTTP vs HTTPS
HTTP 주요 메서드
HTTP 응답 코드
쿠키와 세션
토큰 기반 인증(JWT) vs 세션 기반 인증
www.naver.com을 브라우저에 입력하면?

[취업준비] 개발직군 기술 면접 준비 - 운영체제 편

J1Yun — Sun, 22 Oct 2023 10:05:02 +0900

자세한 내용 정리

https://spotted-green-b02.notion.site/59b5ffefce52423f9a0a5b41e9aef18b?pvs=4

면접 질문 - 운영체제편

프로세스 vs 스레드, 멀티 프로세스 vs 멀티 스레드

spotted-green-b02.notion.site

면접에 자주 나오는 운영체제 개념

프로세스 VS 스레드
멀티프로세스 VS 멀티스레드
프세스 메모리 구조
동기와 비동기
Blocking과 Non-Blocking
데드락(교착상태)
프로세스 동기화 (뮤텍스와 세마포어)
CPU 스케줄링

[취업준비] 개발직군 기술 면접 준비 - 자바(Java) 편

J1Yun — Sun, 22 Oct 2023 09:55:39 +0900

자세한 내용 정리

https://spotted-green-b02.notion.site/27ce2e5e9fa7454f9b1b19635a9e2a29?pvs=4

면접 질문 - 자바편

라이브러리와 프레임워크 차이

spotted-green-b02.notion.site

면접에 자주 나오는 자바(Java) 개념

인터페이스 VS 추상 클래스
Object Class
Static 키워드
Final 키워드
==, equals 차이
접근 제어자 종류와 특성
Throw VS Throws
Error VS Exception, CheckedException VS UnCheckedException
Reflection
String VS StringBuffer VS StringBuilder
JVM 메모리 구조
JVM 구조, 동작 방식
Garbage Collection(GC)
Synchronized (동시성 처리)
Overriding(오버라이딩) VS Overloading(오버로딩)
객체지향프로그래밍(OOP)
직렬화, 역직렬화
List, Set, Map

[취업준비] 임원 면접, 인성 면접 기출 질문 완벽 정리 - 질문 유형별

J1Yun — Sun, 22 Oct 2023 09:38:50 +0900

인성 질문

성격의 장단점
다른 사람에게 피드백 받은 나의 장단점
스트레스 해소법
가장 스트레스를 받는 상황
존경하는 인물과 이유
본인만의 의견 조율 방법
본인만의 소통 방법
본인만의 의사 결정 노하우
리더형? 팔로워형?
리더가 갖추어야 하는 역량은?
내가 남들보다 뛰어난 강점과 약점
학점이 좋은데 공부만 했나?
학점 관리 비법
대외활동이 많은 이유
왜 대학원에 진학하지 않았는가
커뮤니케이션 능력 vs 직무 능력
면접에서 떨어진다면
대인관계에서 가장 중요한 것
대학원에 진학하지 않은 이유
(공백기가 있을때) 공백기에 무엇을 했는지
(이직 시) 이직하는 이유

경험 질문

창의력을 발휘한 경험 / 개선해본 경험
갈등을 해결한 경험
팀워크나 소통 능력을 발휘한 경험
리더쉽을 발휘한 경험 / 리더 경험
새로운 것에 도전한 경험
성공 경험
실패 경험
가장 힘들었던 경험
조직이나 동료를 위해 희생했던 경험
가장 열정적으로 몰입했던 경험
중재자 역할 경험
봉사활동 경험

기업/직무/역량 질문

가장 기억에 남는 프로젝트
직무 수행에 있어 본인의 강점과 약점
직무 수행에 있어 가장 필요한 역량
직무 수행을 위해 본인이 준비한 것
본인을 뽑아야 하는 이유
회사에서 이룰 본인의 최종적인 꿈
회사에서 제공하는 서비스의 장단점
회사의 인재상과 핵심가치 + 본인이 해당되는 것
지원한 직무에서 하는 일 + 하고싶은 일
경쟁사는 어디? + 비교
전공 선택 이유
SW개발 직무 선택 이유
주로 사용하는 언어
새로운 기술/언어를 습득하는 방법
모르는 개념/문제 발견 시 주로 정보를 얻는 방법

적응력/상황/가치관 질문

회사에서 중요하다고 생각되는 가치 / 회사 선정 기준
워라밸에 대한 생각
직장 상사에게 부당한 대우를 받는다면
회사에서 맡은 업무가 적성에 맞지 않는다면
원하는 직무와 다른 직무를 맡게 된다면
직장 상사가 부당한 업무 지시를 한다면
동료/선배가 나의 아이디어/성과를 가로챈다면
함께 일하기 힘든 팀원/상사는 어떤 유형인가 + 그러한 팀원을 만난다면 어떻게 대처할 것인가
상사가 나의 제안/아이디어를 거절한다면
상사의 말/의견이 틀렸다고 생각된다면
상사와의 갈등이 발생한 경우
본인을 색깔로 표현한다면
동료가 편법을 저지른다면
동료가 편법을 제안한다면

[DB] 정규화(Normalization)와 반정규화(De-Normalization)

J1Yun — Mon, 3 Apr 2023 15:33:17 +0900

정규화(Normalization)

릴레이션을 여러 개로 분리하는 과정
릴레이션 간 잘못된 함수 종속 관계로 발생하는 각종 삽입/갱신/삭제 이상 현상을 해결하기 위함
불필요한 데이터 제거를 통해 저장 공간을 효율적으로 사용
함수 종속 관계는 릴레이션 분리(정규화)의 기준이 됨

※ 삽입/갱신/삭제 이상 현상에 관한 내용은 아래 포스트 참고
https://zu-techlog.tistory.com/141

[DB] 이상 현상(Anomaly) 개념, 종류

이상 현상(Anomaly) 중복이 발생하고 전체적인 무결성이 저하 릴레이션에 대한 데이터 삽입, 수정, 삭제 연산을 할 때 발생할 수 있는 부작용 현실세계의 실제 값과 데이터베이스에 저장된 값이 일

zu-techlog.tistory.com

제 1정규화(1NF)

릴레이션의 모든 도메인이 더 이상 분해될 수 없는 원자 값만으로 구성되어야 함
위 그림은 Telephone Number의 도메인이 원자 값이 아니기 때문에 제 1정규형 만족 X

릴레이션의 속성 값 중에서 한 개의 기본키에 대해 두 개 이상의 값을 가지는 반복 집합이 있다면 제거
위 그림은 Telephone Number에 대해 2개의 반복 집합을 가지고 있으므로 제 1정규형 만족 X

제 2정규형(2NF)

제 1정규형을 만족하면서 기본키가 아닌 모든 속성에 완전 함수 종속을 만족해야 함
부분적 함수 종속 제거

함수 종속이란?

- 완전 함수 종속: 기본키가 단일키 일 경우 X -> Y 만족, 기본키가 복합키 일 경우 {X1,X2} -> Y 만족
- 부분 함수 종속: 기본키가 복합키 일 경우 X1, X2 중 하나만으로도 Y의 값을 결정
- 이행적 함수 종속: X -> Y인데, Y -> Z 다. 결국 X -> Z인 것을 알 수 있는 경우

예시)

Model Full Name은 복합키인 Manufacturer와 Model에 대해 완전 함수 종속을 만족하지만 Manufacturer Country는 Manufacturer에 따라서만 결정되는 부분 함수 종속 관계를 가짐

따라서, 위와 같이 테이블을 분리하여 부분 함수 종속을 제거하면 제 2정규형 만족 가능

제 3정규형(3NF)

제 2정규형을 만족하면서 기본키가 아닌 모든 속성이 기본키에 대해 이행적 함수 종속을 만족하지 않도록 함

예시)

Winner Date of Birth 속성은 기본키가 아닌 속성 Winner에게 종속되고, Winner는 기본키인 Tournament와 Year에 종속되므로 결국 Winner Date of Birth는 {Tournament, Year}에 의존하게 되는 이행적 함수 종속 관계를 가짐

따라서, 위와 같이 테이블을 분리하여 이행적 함수 종속을 제거하면 제 3정규형 만족 가능

BCNF

제 3정규형을 만족하면서 모든 결정자가 후보키 집합에 속해야 함

예시)

교수는 하나의 과목만 강의할 수 있다고 가정할 때, 결정자는 '교수' (교수에 따라 과목이 정해지기 때문) 이지만 후보키는 {학생, 과목}로 '교수'가 포함되지 않음

따라서, 위와 같이 테이블을 분리하여 결정자가 후보키가 되도록 하면 BCNF 만족 가능

반정규화(De-Normalization)

정규화는 릴레이션 분리로 인해 릴레이션 간 JOIN 연산이 많아져 질의에 대한 응답 시간이 느려질 수 있음
데이터 조회 성능 향상을 위해 데이터 중복을 허용하며 릴레이션을 합치는 과정
데이터베이스의 완벽한 구조 설계를 포기하고 데이터 무결성을 깨뜨리는 대신 데이터베이스 읽기 성능을 향상
데이터 중복으로 삽입, 수정, 삭제의 성능은 낮아질 수 있음
상황에 따라 필요 시 반정규화 수행
- 정규화에 충실하여 종속성, 활용성은 향상되었지만, 수행속도가 느려진 경우
- 다량의 데이터 범위를 자주 처리해야하는 경우
- 특정 범위의 데이터만 자주 처리하는 경우
- 요약/집계 정보가 자주 요구되는 경우

예시)

강사, 수업, 수강료 3개의 테이블을 JOIN하여 데이터를 조회하는 과정에서 속도 저하가 발생하면 반정규화를 통해 일부 데이터 중복을 허용하며 조회 속도를 향상시킬 수 있음

[DB] 이상 현상(Anomaly) 개념, 종류

J1Yun — Fri, 31 Mar 2023 14:26:50 +0900

이상 현상(Anomaly)

중복이 발생하고 전체적인 무결성이 저하
릴레이션에 대한 데이터 삽입, 수정, 삭제 연산을 할 때 발생할 수 있는 부작용
현실세계의 실제 값과 데이터베이스에 저장된 값이 일치하지 않는 문제가 발생
정규화를 통해 해결

기본 테이블 예시) 학교 테이블

1. 삽입 이상(Insertion Anomaly)

특정 데이터가 존재하지 않아 중요한 데이터를 데이터베이스에 삽입할 수 없을 때 발생
내가 원하는 값만 테이블에 삽입하고 싶은데, 테이블에 필요하지 않은 필드들 때문에 원치 않는 필드의 값도 삽입해야 하는 경우
신설된 '수학과'에는 학생이 존재하지 않아 테이블에 '수학과' 데이터를 추가할 수 없음
정규화를 통해 학생 테이블과 학과 테이블로 분리하면 해결 가능

2. 삭제 이상((Deletion Anomaly))

특정 정보를 삭제하면, 원치 않는 정보도 삭제되는 현상
'둘리' 학생의 데이터를 삭제하려면 '컴퓨터공학과'와 관련된 정보도 함께 삭제됨
정규화를 통해 학생 테이블과 학과 테이블로 분리하면 해결 가능

3. 갱신 이상(Modification Anomaly)

업데이트 했을때 그 속성의 다른 속성값들과의 불일치가 발생하는 현상
테이블의 특정 데이터를 업데이트했는데, 정상적으로 변경되지 않거나 너무 많은 행이 변경되는 경우
'워런 버핏' 학과장 명을 변경하려할 때 '경영학과'의 학생이 100명이므로 100개의 데이터를 모두 변경해야 함
한 행이라도 변경되지 않는다면 데이터 무결성이 유지되지 않음
정규화를 통해 학교 테이블과 학과장 테이블을 분리하면 해결 가능

[DB] SQL 조인(Join) 개념, 종류

J1Yun — Fri, 24 Mar 2023 14:59:16 +0900

조인(Join)

한 데이터베이스 내의 여러 테이블의 레코드를 조합하여 하나의 열로 표현한 것\
데이터베이스에는 서로 관계있는 데이터가 여러 테이블로 나뉘어 저장되있어 조인을 통해 각 테이블을 연결하여 효과적으로 검색
두 테이블의 조인을 위해서는기본키(PRIMARY KEY, PK)와 외래키(FOREIGN KEY, FK) 관계로 맺어져야 함

조인의 종류

내부 조인(I NNER JOIN): 두 테이블을 조인할 때, 두 테이블에 모두 지정한 열의 데이터가 있어야 함
외부 조인(OUTER JOIN): 두 테이블을 조인할 때, 1개의 테이블에만 데이터가 있어도 결과가 나옴
상호 조인(CROSS JOIN): 한쪽 테이블의 모든 행과 다른 쪽 테이블의 모든 행을 조인하는 기능
자체 조인(SELF JOIN): 자신이 자신과 조인한다는 의미로, 1개의 테이블을 사용

※ 샘플 데이터베이스 구조는 다음과 같음

내부 조인(INNER JOIN)

가장 흔한 결합 방식이며 기본 조인 형식으로 간주
공통적인 부분만 SELECT

명시적 조인 표현(explicit)

Join 키워드와 함께 On 키워드 사용

SELECT *
FROM STUDENT_TABLE
INNER JOIN DEPARTMENT_TABLE
ON STUDENT_TABLE.DEPARTMENT_ID = DEPARTMENT_TABLE.DEPARTMENT_ID;

암시적 조인 표현(implicit)

From 절에서 테이블을 분리하는 컴마(,)를 사용

SELECT *
FROM STUDENT_TABLE, DEPARTMENT_TABLE
WHERE STUDENT_TABLE.DEPARTMENT_ID = DEPARTMENT_TABLE.DEPARTMENT_ID;

외부 조인(OUTER JOIN)

조인 대상 테이블에서 특정 테이블의 데이터가 모두 필요한 상황에서 효과적으로 결과 집합을 생성
두 테이블이 가지고 있는 전체 부분 SELECT

왼쪽 외부 조인(LEFT OUTER JOIN)

왼쪽 테이블의 모든 데이터를 포함하는 결과 집합을 생성

# 공통부분 포함
SELECT *
FROM STUDENT_TABLE S LEFT OUTER JOIN DEPARTMENT_TABLE D
ON S.DEPARTMENT_ID = D.DEPARTMENT_ID;

# 공통부분 불포함
SELECT *
FROM STUDENT_TABLE S LEFT OUTER JOIN DEPARTMENT_TABLE D
ON S.DEPARTMENT_ID = D.DEPARTMENT_ID
WHERE D.DEPARTMENT_ID IS NULL;

오른쪽 외부 조인(RIGHT OUTER JOIN)

테이블의 모든 데이터를 포함하는 결과 집합을 생성

# 공통부분 포함
SELECT *
FROM STUDENT_TABLE S RIGHT OUTER JOIN DEPARTMENT_TABLE D
ON S.DEPARTMENT_ID = D.DEPARTMENT_ID;

# 공통부분 불포함
SELECT *
FROM STUDENT_TABLE S RIGHT OUTER JOIN DEPARTMENT_TABLE D
ON S.DEPARTMENT_ID = D.DEPARTMENT_ID
WHERE S.DEPARTMENT_ID IS NULL;

완전 외부 조인(FULL OUTER JOIN)

두 테이블의 모든 데이터를 포함하는 결과 집합을 생성

# 공통부분 포함
-- ORACLE
SELECT *
FROM STUDENT_TABLE S FULL OUTER JOIN DEPARTMENT_TABLE D
ON S.DEPARTMENT_ID = D.DEPARTMENT_ID;
-- MYSQL
SELECT *
FROM STUDENT_TABLE S LEFT OUTER JOIN DEPARTMENT_TABLE D
ON S.DEPARTMENT_ID = D.DEPARTMENT_ID
UNION
SELECT *
FROM STUDENT_TABLE S RIGHT OUTER JOIN DEPARTMENT_TABLE D
ON S.DEPARTMENT_ID = D.DEPARTMENT_ID;

# 공통부분 불포함
-- ORACLE
SELECT *
FROM STUDENT_TABLE S FULL OUTER JOIN DEPARTMENT_TABLE D
ON S.DEPARTMENT_ID = D.DEPARTMENT_ID
WHERE S.DEPARTMENT_ID IS NULL OR D.DEPARTMENT_ID IS NULL;
-- MYSQL
SELECT *
FROM STUDENT_TABLE S LEFT OUTER JOIN DEPARTMENT_TABLE D
ON S.DEPARTMENT_ID = D.DEPARTMENT_ID
WHERE D.DEPARTMENT_ID IS NULL
UNION
SELECT *
FROM STUDENT_TABLE S RIGHT OUTER JOIN DEPARTMENT_TABLE D
ON S.DEPARTMENT_ID = D.DEPARTMENT_ID
WHERE S.DEPARTMENT_ID IS NULL;

상호 조인(CROSS JOIN)

한쪽 테이블의 모든 행과 다른 쪽 테이블의 모든 행을 결합시켜 모두 SELECT
카티션 곱(CARTESIAN PRODUCT)이라고도 함

SELECT *
FROM STUDENT_TABLE S CROSS JOIN DEPARTMENT_TABLE D

[DB] 데이터베이스 기초 용어, 키(Key)의 개념과 종류

J1Yun — Thu, 23 Mar 2023 16:05:46 +0900

데이터베이스 기초 용어

릴레이션(Relation)
- 관계형 데이터 모델에서 하나의 개체에 관한 데이터를 저장하기 위한 구조 (= 테이블)
- 스키마와 인스턴스로 이루어짐
스키마(Schema)
- 릴레이션의 이름, 각 속성의 이름, 타입, 도메인 등을 정의하는 개념
인스턴스(Instance)
- 릴레이션에 저장되는 데이터(튜플)의 집합
속성(Attribute)
- 릴레이션의 열(Column)
- 서로 다른 이름을 가져야 함
튜플(Tuple) / 레코드(Record)
- 릴레이션의 행(Row)
- 중복 불가
차수(Degree)
- 하나의 릴레이션에서 속성의 전체 개수
카디널리티(Cardinality)
- 하나의 릴레이션에서 튜플의 전체 개수
도메인(Domain)
- 릴레이션의 속성이 가질 수 있는 원자값들의 집합

키(Key)

릴레이션의 튜플을 식별할 수 있는 단일 속성 혹은 속성들의 집합
유일성과 최소성에 따라 키의 종류가 달라짐

유일성

하나의 키값으로 튜플을 유일하게 식별할 수 있는 성질
혈액형, 나이 (X) | 주민번호, 학번 (0)

최소성

키를 구성하는 속성들 중 가장 최소로 필요한 속성들로만 키를 구성하는 성질
키를 구성하고 있는 속성들이 각 튜플을 구분하는 데 꼭 필요한 속성들로만 구성되어 있는지 확인
[주민번호+나이] (X) | [주민번호] (X)
- 나이를 키로 설정하지 않아도 주민번호 만으로도 유일성을 만족함

키 종류

슈퍼 키(Super Key)

슈퍼키는 유일성의 특성을 만족하는 속성 또는 속성들의 집합
어떤 속성을 결합하든 튜플을 식별할 수 있으며 중복 튜블이 발생할 수 없는 경우
최소성은 만족하지 않아도 됨
Ex) [학번], [주민번호], [학번+이름], [주민번호+나이] 등

후보키(Candidate Key)

유일성과 최소성을 모두 만족하는 속성 또는 속성들의 집합
최소의 속성을 결합하여 튜플을 식별할 수 있어야 함
Ex) [학번], [주민번호]

기본 키(Primary Key)

유일성과 최소성을 만족하는 후보 키 중 다음을 고려하여 하나를 선택한 키
- NULL 값을 가질 수 없는 속성이 포함된 후보 키
- 값이 자주 변경될 수 없는 속성이 포함된 후보 키
- 단순한 후보 키
Ex) [학번]

대체 키(Alternate Key)

후보 키가 두개 이상일 경우 키본키로 하나를 지정하고 남은 후보 키 집합
보조 키라고도 함
Ex) [주민번호]

외래 키(Foreign Key)

다른 릴레이션의 기본 키를 그대로 참조하는 속성 또는 속성들의 집합
릴레이션 간의 관계를 나타내기 위해 사용
외래 키에는 참조 테이블의 기본 키에 존재하지 않는 값을 참조할 수 없음. (참조 무결성 조건)
- 데이터 추가/삭제 시 항상 외래 키가 참조한 값은 참조 테이블에 존재하도록 고려해야 함
Ex) 외래 키: 주문 테이블의 '주문고객' 속성 | 참조 키: 고객 테이블의 '고객ID'

⭐️ 참고

[DB] 트랜잭션(Transaction) 개념, 특징, 연산, 상태

J1Yun — Wed, 22 Mar 2023 14:47:04 +0900

트랜잭션(Transaction)

데이터베이스의 상태를 변화시키는 하나의 논리적 기능을 수행하기 위한 작업의 단위
한꺼번에 수행되어야할 일련의 연산
데이터베이스 일관성과 무경성 보장
- 데이터베이스의 하나의 작업이 수행되는 동안 다른 작업이 간섭하지 못하도록 함
- 논리적인 작업 셋을 모두 완벽하게 처리하거나 또는 처리하지 못할 경우에는 원 상태로 복구해서 작업의 일부만 적용되는 현상이 발생하지 않게 만들어주는 기능

트랜잭션 연산

Commit
- 하나의 트랜잭션이 성공적으로 끝나서 데이터베이스가 일관성 있는 상태에 있음을 알려주기 위해 사용하는 연산
Rollback
- 하나의 트랜잭션 처리가 비정상적으로 종료되어 데이터베이스의 일관성을 깨뜨렸을 때, 이 트랜잭션의 일부가 정상적으로 처리되었더라도 트랜잭션의 원자성을 보장하기 위해 이 트랜잭션이 행한 모든 연산을 취소(Undo)하는 연산

트랜잭션 특징(ACID)

Atomicity(원자성)
- 트랜잭션이 데이터베이스에 모두 반영되거나, 전혀 반영 되지 않아야 함
- 트랜잭션 내의 모든 명령은 반드시 완벽히 수행되어야 하며(Commit), 모두가 완벽히 수행되지 않고 어느 하나라도 오류가 발생하면 트랜잭션 전부가 취소되어야 함(Rollback)
Consistency(일관성)
- 트랜잭션의 작업 처리 결과는 항상 일관성이 있어야 함
- 데이터베이스의 상태 즉, 시스템이 가지고 있는 고정요소(데이터 타입 등)는 트랜잭션 수행 전과 수행 완료 후의 상태가 같아야 함
Isolation(독립성, 격리성)
- 트랜잭션 수행 시 다른 트랜잭션 연산이 끼어들지 못하도록 보장
- 수행 중인 트랜잭션은 완전히 완료될 때까지 다른 트랜잭션에서 수행 결과를 참조 할 수 없음
Durability(지속성, 영속성)
- 트랜잭션이 성공적으로 완료되었을 경우, 결과는 영구적으로 반영되어야 함

트랜잭션 상태

활동(Active): 트랜잭션이 실행 중인 상태
부분 완료(Partially Committed): 트랜잭션의 마지막 연산까지 실행했지만, Commit 연산이 실행되기 직전의 상태
완료(Committed): 트랜잭션이 성공적으로 종료되어 Commit 연산을 실행한 후의 상태
실패(Failed): 트랜잭션 실행에 오류가 발생하여 중단된 상태
철회(Aborted): 트랜잭션이 비정상적으로 종료되어 Rollback 연산을 수행한 상태 (트랜잭션 취소)

트랜잭션 사용 시 주의할 점
트랜잭션이 데이터베이스의 커넥션을 오래 점유하도록 하지 않기 위해 트랜잭션의 범위를 최소화하여 꼭 필요한 코드에만 적용하는 것이 좋다.

⭐️ 참고

[DB] RDBMS의 SQL과 NoSQL 차이

J1Yun — Tue, 21 Mar 2023 17:02:08 +0900

관계형 데이터베이스(RDBMS, SQL Database)

고정된 행(row)과 열(column)로 구성된 테이블에 데이터를 저장
테이블의 관계가 구조화된 데이터의 모음이기 때문에 구조화된 쿼리 언어(SQL)를 사용하여 데이터를 다룸
각 열은 하나의 속성에 대한 정보를 저장하고, 행에는 각 열의 데이터 형식에 맞는 데이터가 저장
테이블의 구조와 데이터 타입 등을 사전에 정의한 후 그 형식을 유지하며 데이터 조작
테이블 간의 관계를 직관적으로 파악할 수 있음

장점

명확하게 정의된 스키마, 데이터 무결성 보장
관계는 각 데이터를 중복없이 한번만 저장

단점

데이터 스키마를 변경하기 어려워 유연성이 떨어짐
관계를 맺고 있어서 Join 문이 많은 복잡한 쿼리가 만들어질 수 있음
대체로 수직적 확장만 가능함

비관계형 데이터베이스(NoSQL Database)

Key-Value, 문서 등 관계형 데이터베이스와는 다른 방식으로 데이터를 저장
테이블 구조 및 데이터 저장 형식에 대한 제한이 없음
테이블 간 관계를 정의하지 않음

장점

스키마가 없어서 유연함. 언제든지 저장된 데이터를 조정하고 새로운 필드 추가 가능
데이터는 애플리케이션이 필요로 하는 형식으로 저장되어 데이터를 읽어오는 속도가 빨름
수직 및 수평 확장이 가능해서 애플리케이션이 발생시키는 모든 읽기/쓰기 요청 처리 가능

단점

유연성으로 인해 데이터 구조 결정을 미루게 될 수 있음
데이터 중복이 발생할 수 있으며, 중복된 데이터가 변경 될 경우 모든 컬렉션에 대해 수정해주어야 함

NoSQL Database 유형

Key-Value 타입 데이터베이스
- 속성과 값에 대해 Key-Value 쌍으로 나타내어 데이터를 배열의 형태로 저장
- Ex) Redis, Dynamo 등
문서형(Document) 데이터베이스
- 데이터를 테이블이 아닌 JSON과 유사한 형식으로 문서화하여 저장
- 각각의 문서는 하나의 속성에 대한 데이터를 가지고 있고, 컬렉션이라고 하는 그룹으로 묶어서 관리
- Ex) MongoDB 등
Wide-Column Store 데이터베이스
- 데이터베이스의 열(column)에 대한 데이터를 집중적으로 관리하는 데이터베이스
- 각 열에는 key-value 형식으로 데이터가 저장되고, 컬럼 패밀리(column families)라고 하는 열의 집합체 단위로 데이터를 처리
- 하나의 행에 많은 열을 포함할 수 있어서 유연성이 높으며, 데이터 처리에 필요한 열을 유연하게 선택할 수 있어 규모가 큰 데이터 분석에 주로 사용
- Ex) Cassandra, HBase 등
그래프(Graph) 데이터베이스
- 자료구조의 그래프와 비슷한 형식으로 데이터 간의 관계를 구성하는 데이터베이스
- 노드(nodes)에 속성별(entities)로 데이터를 저장하고, 각 노드 간의 관계는 선(edge)으로 표현
- Ex) Neo4J, InfiniteGraph

SQL Database VS NoSQL Database

데이터 저장(Storage)
- SQL DB는 SQL을 활용해 미리 작성된 스키마를 기반으로 정해진 형식에 따라 테이블에 데이터 저장
- NoSQL DB는 key-value, document, wide-column, graph 등의 방식으로 데이터를 저장
스키마(Schema)
- SQL DB는 데이터 속성별로 열(column)에 대한 정보를 정해 미리 정해 고정된 형식의 스키마가 필요
- NoSQL DB는 동적으로 스키마의 형태를 관리
쿼리(Query)
- SQL DB는 SQL과 같이 구조화된 쿼리 언어를 사용해 테이블의 형식과 테이블간의 관계에 맞춰 데이터를 요청
- NoSQL DB는 구조화 되지 않은 쿼리 언어로도 데이터 요청이 가능
확장성(Scalability)
- SQL DB은 주로 수직적 확장(높은 성능의 메모리 및 CPU 사용)만 용이
- NoSQL DB는 수직적 확장 뿐만 아니라 수평적 확장(서버 증설, 클라우드 서비스 이용)에도 유리

SQL 기반의 관계형 데이터베이스를 사용해야 하는 케이스

데이터 구조가 명확하며 변경 될 여지가 없으며 명확한 스키마가 중요한 경우
관계를 맺고 있는 데이터가 자주 변경되는 경우
- 중복된 데이터가 없어(데이터 무결성) 변경이 용이하기 때문

NoSQL 기반의 관계형 데이터베이스를 사용해야 하는 케이스

정확한 데이터 구조를 알 수 없거나 변경 및 확장 될 수 있는 경우
데이터 읽기를 자주 하지만, 데이터 변경은 자주 없는 경우
많은 양의 데이터를 다뤄야 하는 경우
- 데이터베이스를 수평적으로 확장할 수 있기 때문

⭐️ 참고

[DB] 인덱스(Index) 개념, 장단점, 전략, 구조

J1Yun — Mon, 20 Mar 2023 16:33:16 +0900

인덱스(Index)

책의 '색인'과 같이 데이터베이스 내 데이터 검색 성능을 높이기 위해 사용하는 자료 구조
특정 칼럼에 인덱스를 생성하면, 해당 칼럼의 데이터를 정렬하여 별도의 메모리 공간에 데이터의 물리적 주소와 함께 저장
데이터를 검색하는 쿼리를 실행하면 옵티마이저는 인덱스에 저장되어 있는 데이터의 물리 주소를 참조하면서 검색 속도 향상
인덱스 생성 시 데이터를 오름차순으로 정렬

장점

검색 조건 WHERE 절에서의 효율성
- 인덱스를 설정하지 않으면 뒤죽박죽 섞여있는 데이터 중 검색을 하려면 풀 스캔(Full Scan)을 해야함
- 인덱스 테이블은 데이터들이 정렬되어 저장되어 있기 때문에 조건(WHERE절)에 맞는 데이터를 빠르게 찾을 수 있음
정렬 ORDER BY 절에서의 효율성
- 인덱스를 사용하면 이미 정렬되어 있기 때문에 ORDER BY에 의한 정렬 과정을 피할 수 있어 시스템 부하를 줄일 수 있음
MIN과 MAX의 처리 효율성
- 인덱스를 사용하면 데이터가 정렬되어 있기 때문에 MIN값과 MAX값은 각각 시작 값과 끝 값을 의미하여 풀 스캔(Full Scan)으로 처리하는 것보다 효율적으로 동작

단점

인덱스를 위한 추가 저장 공간 필요
- 인덱스를 저장하고 관리하기 위해서는 데이터베이스의 약 10%에 해당하는 저장 공간이 추가로 필요함
DML(INSERT, UPDATE, DELETE) 명령에 취약
- INSERT, UPDATE, DELETE 등 DML 명령어를 실행하면 인덱스 테이블 내 데이터를 다시 정렬하는 과정이 필요함
- 원본 테이블 뿐만 아니라 인덱스 테이블 또한 삽입/수정/삭제를 반영해야하므로 DML이 빈번하게 발생하면 부하 발생
잘못 사용할 경우 오히려 성능 저하
- 테이블의 전체 데이터 중에서 10~15% 이하의 데이터를 처리하는 경우 즉, 테이블에 데이터가 많은 경우에만 효과적
- 데이터가 적을 때는 인덱스가 괜히 저장 공간만 차지할 뿐 풀 스캔이 더욱 빠르게 동작

인덱스 생성 전략

데이터의 삽입/수정/삭제 작업이 많이 일어나지 않고 데이터 조회 및 검색 작업이 빈번히 일어나는 테이블

조건 절에 자주 등장하는 칼럼
조건 절에서=(같음) 연산자로 비교되는 칼럼
ORDER BY 절에서 정렬의 기준으로 쓰이는 칼럼
중복 데이터 발생 확률이 최소인 칼럼
JOIN 조건으로 자주 사용되는 칼럼

인덱스 구조

1. B-Tree 인덱스

탐색 성능을 높이기 위해 균형 있게 높이를 유지하는 Balanced Tree의 일종
모든 리프 노드들은 같은 레벨에 있어야 함
데이터를 정렬된 순서로 저장하며 노드의 균형을 유지해 검색과 삽입, 삭제 작업을 빠르게 처리할 수 있음
노드는 키와 자식 노드를 가리키는 포인터의 쌍으로 이루어지며 각 노드는 여러 개의 키를 가질 수 있음

2. B+Tree 인덱스

B-Tree의 변형으로 B-Tree는 특정 데이터 검색은 효율적이지만 데이터 순회 시 모든 노드를 방문해야 한다는 단점 개선
리프 노드에만 데이터를 저장, 다른 노드에서는 자식 노드를 가리키는 포인터만 저장
리프 노드끼리는 연결리스트(Linked List)로 연결
리프 노드를 제외하고는 데이터를 저장하지 않기 때문에 메모리를 더 확보하여 더 많은 포인터를 담을 수 있어 검색 속도 향상
풀 스캔을 하는 경우 연결리스트로 연결되어 있는 리프 노드만 순회하면 되기 때문에 효율적
인덱스의 경우 부등호를 이용한 순차 검색 연산이 자주 발생하므로 B+Tree를 주로 사용

3. 해시 테이블(Hash Table)

key와 value를 한 쌍으로 데이터를 저장하는 자료구조
해시 함수는 값이 조금이라도 달라지면 완전히 다른 해시 값을 생성해 등호(=) 연산을 이용한 검색에 최적화 되어 있음
부등호(<, >) 연산이 자주 사용되는 검색을 위해서는 적합하지 않음

⭐️ 참고

[운영체제] 캐시 메모리(Cache Memory)와 지역성(Locality), 캐싱 라인(Caching Line)

J1Yun — Sun, 19 Mar 2023 15:01:33 +0900

캐시 메모리(Cache Memory)

메인 메모리(주기억장치)에서 자주 사용하는 프로그램과 데이터를 미리 저장해 둔 고속 메모리
속도가 빠른 장치(CPU 연산)와 느린 장치(메모리 접근) 간의 속도 차에 따른 병목 현상을 줄이기 위한 범용 메모리
메인 메모리와 CPU 사이에 위치
캐시를 사용하면 메모리에 접근하는 횟수가 줄어 컴퓨터 처리 속도 향상
캐시가 효율적으로 동작하기 위해서는 CPU가 참조할 정보에 대해 잘 예측해야 함
- 캐시 적중률(Hit Rate)를 극대화
- 캐시의 지역성(Locality) 고려

캐시 지역성(Locality)

데이터에 대한 접근이 시간적/공간적으로 가깝게 발생하는 것
기억장치 내의 정보를 균등하게 엑세스하는 것이 아닌 어느 한 순간에 특정 부분을 집중적으로 참조하는 특성
캐시 적중률(Hit Rate)을 위해 저장할 데이터는 지역성을 가져야 함

지역성 종류

시간적 지역성
- 특정 데이터가 한번 참조된 경우, 가까운 미래에 또 한번 참조될 가능성이 높은 것
- 메모리 상의 같은 주소에 여러 차례 읽기 쓰기를 수행할 경우, 상대적으로 작은 크기의 캐시를 사용해도 효율성이 높음
공간적 지역성
- 특정 데이터와 인접한 주소의 데이터가 참조될 가능성이 높은 것
- CPU 캐시나 디스크 캐시의 경우 한 메모리 주소에 접근할 때 그 주소뿐 아니라 해당 블록을 전부 캐시에 가져오도록 함
  - 메모리 주소를 오름차순이나 내림차순으로 순서대로 접근한다면 이미 캐시에 저장되어 있기 때문에 효율성이 높음

캐싱 라인(Caching Line)

캐시에서 원하는 데이터를 바로 접근하기 위해 특정 자료구조를 사용해 묶음으로 저장해 놓은 것
캐시에서 데이터를 바로 찾지 못하고 모든 데이터를 순회해야 한다면 캐시 성능이 떨어질 것임
캐시 메모리의 매핑 프로세스
주기억장치로부터 캐시 메모리에 데이터를 가져와 저장하는 방법

캐싱 라인 종류

직접 매핑(Direct mapping)
- 메모리 주소와 캐시의 순서를 일치시켜 지정된 캐싱 라인으로만 매핑
- 메모리의 특정 블럭은 특정 캐싱 라인에만 저장
- 구현이 간단하고 빠르지만, 충돌로 인한 잦은 스와핑이 발생할 가능성이 높아 성능이 제한될 수 있음
연관 매핑(Associative Mapping)
- 순서를 일치시키지 않고 필요한 메모리 값(데이터)을 캐시의 어디든지 저장
- 찾는 과정이 복잡하고 느리지만 충돌이 적으며 필요한 캐시 위주로 저장하기에 적중률 높음
집합 연관 매핑(Set-Associative Mapping)
- 집합 간의 순서는 일치시키는 반면 집합 내에서는 순서를 일치시키지 않고 편하게 저장
- 직접 매핑과 연관 매핑의 장점만 취함

⭐️ 참고

[운영체제] 페이지 교체 알고리즘 - FIFO, OPT, LRU, NRU, LFU, MFU

J1Yun — Thu, 16 Mar 2023 17:33:24 +0900

페이지 교체 알고리즘

필요한 페이지가 메모리에 없을 때 페이지 부재(page fault)가 발생하면 요청된 페이지를 디스크에서 메모리로 읽어와야 한다. 이때, 물리 메모리에 빈 프레임이 존재하지 않는다면 물리 매모리 내 페이지 중 하나를 선택해서 디스크의 스왑 영역을 보내야 한다.(Swapping) 이를 페이지 교체라고 한다. 메모리 내 페이지 부재율을 최소하하기 위한 목적으로 디스크의 스왑 영역으로 보낼 페이지를 결정하는 알고리즘을 페이지 교체 알고리즘이라고 한다.

FIFO(First In First Out)

가장 먼저 메모리에 올라온 페이지를 가장 먼저 내보내는 알고리즘
구현이 간단하지만 페이지의 향후 참조 가능성을 고려하지 않기 때문에 비효율적인 상황이 발생할 수 있음
들어온 시간을 저장하거나 올라온 순서를 큐를 이용해 저장
Belady's Anomaly(FIFO Anomaly) 현상 발생 가능
- 메모리 증가로 더 많은 프레임을 사용했는데도 페이지 부재 횟수가 오히려 증가하는 이상 현상
- ex) 페이지 수를 3개에서 4개로 증가시겼음에도 페이지 부재가 더 발생하는 경우가 있음

OPT(Optimal)

앞으로 가장 오랫동안 사용하지 않을 페이지를 교체하는 알고리즘
모든 페이지 교체 알고리즘 중 page-fault 발생이 가장 적어 성능이 좋음
프로세스가 앞으로 사용할 페이지를 미리 예측하기 어려워 실제로 사용하는 것은 거의 불가능

LRU(Least Recently Used)

가장 오랫동안 사용하지 않은 페이지를 교체하는 알고리즘
시간 지역성(가까운 미래에 다시 참조된 가능성)을 고려해 가장 오래전에 참조가 이루어진 페이지를 내보냄
성능이 좋은 편으로 많은 운영체제가 채택
프로세스가 주기억장치에 접근할 때마다 참조된 페이지 시간을 기록해야해 오버헤드 발생 가능

NRU(Not Recently Used)

LRU처럼 가장 최근에 참조되지 않은 페이지를 선택하지만 교체되는 페이지의 참조 시점이 가장 오래되었음을 보장하지 않음
'클럭 알고리즘'이라고도 함
최근에 참조되었음을 의미하는 1과 참조되지 않음을 의미하는 0 참조 비트(Reference Bit)를 조사
1. 프레임 내의 페이지가 참조될 때 하드웨어에 의해 1로 자동 세팅
2. 클럭 알고리즘은 한 바퀴 돌았음에도 참조되지 않은 페이지의 참조 비트 값을 0으로 바꾼 후 지나감
3. 참조 비트가 0인 페이지를 방문하면 해당 페이지를 교체

LFU(Least Frequently Used)

참조횟수가 가장 적은 페이지를 교체하는 알고리즘
교체 대상이 여러 개라면 가장 오랫동안 사용하지 않은 페이지를 교체
가장 최근에 불러온 페이지가 교체될 수 있으며, 이에 따른 오버헤드가 발생할 수 있음

MFU(Most Frequently Used)

LFU와 반대로 참조 횟수가 가장 많은 페이지를 교체하는 알고리즘

[운영체제] 메모리 할당, 페이징(Paging)과 세그멘테이션(Segmentation)

J1Yun — Wed, 15 Mar 2023 15:09:54 +0900

메모리 할당

시작 메모리 위치, 메모리 할당 크기를 기반으로 메모리에 프로그램 할당
연속 할당과 불연속 할당으로 나뉨

1. 연속 할당

메모리에 연속적으로 공간 할당
물리 메모리를 다수의 공간으로 분할하여 하나의 분할 공간에 하나의 프로세스가 적재되도록 함
고정 분할 방식과 가변 분할 방식으로 나뉨

1-1) 고정 분할 방식(Fixed Partition Allocation)

메모리 공간을 미리 분할하여 고정된 크기로 나누어 관리하는 방식
분할 크기는 모두 동일할 수도 있고 다를 수도 있음
분할된 공간은 영구적으로 고정되기 때문에 메모리에 올릴 수 있는 프로그램의 수 및 크기가 제한적이고 융통성이 떨어짐
내부 단편화(내부 조각)와 외부 단편화(외부 조각) 문제가 발생할 수 있음

1-2) 가변 분할 방식(Variable Partition Allocation)

메모리에 적재되는 프로그램의 크기에 따라 매시점 분할의 크기와 개수가 동적으로 변하는 방식
프로세스 크기 만큼의 메모리 공간을 사용하기 때문에 내부 단편화(내부 조각)은 발생하지 않음
프로세스를 올리기에 충분한 공간이 존재하지 않는 경우 외부 단편화(외부 조각) 문제 발생
프로세스를 메모리 공간 중 어디에 올려야 할지 결졍해야 함
- 최초 적합: 가장 먼저 나오는 가용 메모리 공간에 프로세스를 할당하는 방법
- 최적 적합: 가장 딱 맞는 메모리 공간을 찾아서 프로세스를 할당하는 방법
- 최악 적합: 가장 큰 메모리 공간에 프로세스를 할당하는 방법

2. 불연속 할당

메모리에 불연속적으로 공간 할당
하나의 프로세스가 물리 메모리 상의 여러 위치에 분산되어 적재되도록 함
페이징, 세그멘테이션으로 나뉨

2-1) 페이징(Paging)

프로세스의 주소 공간을 고정된 사이즈의 페이지(Page) 단위로 나누어 물리적 메모리에 불연속적으로 할당하는 방식
메모리는 프레임(Frame)이라는 고정 크기로 분할, 프로세스는 페이지(Page)라는 고정 크기로 분할
페이지와 프레임은 같은 크기
페이지와 프레임을 대응시키는 Page Mapping을 위해 Page Table 필요
Page Table에는 각 페이지 번호와 해당 페이지가 할당된 프레임의 시작 물리 주소를 저장
연속적이지 않은 공간도 활용할 수 있기 때문에 외부 단편화 문제 해결
프로세스의 크기가 페이지 크기의 배수가 아닐 경우 마지막 페이지에 대한 내부 단편화 발생
- 페이지 단위를 작게하면 내부 단편화를 해결할 순 있지만 Page Mapping 과정이 많아져 비효율적

2-2) 세그멘테이션(Segmentation)

프로세스를 서로 다른 크기의 논리적 블록 단위인 세그먼트(Segment)로 나누어 메모리에 불연속적으로 할당하는 방식
세그먼트 단위는 함수 단위일 수도 있고, Code/Data/Heap/Stack 등 논리적 단위일 수 있음
페이징과 마찬가지로 Segment Mapping 과정을 위해 Segment Table 필요
세그먼트의 크기는 각각 다르기 때문에 Segment Table에는 시작 주소와 함께 limit 정보가 주어짐
프로세스가 필요로하는 메모리 공간 만큼이 할당되기 때문에 내부 단편화 문제 해결
메모리 해제를 통한 외부 단편화 발생

Paging VS Segmentation

Paging은 고정 크기의 분할 단위, Segmentation은 가변 크기의 분할 단위를 가짐
Paging은 내부 단편화 발생 가능, Segment은 외부 단편화 발생 가능
Paging은 외부 단편화 해결, Segment은 내부 단편화 해결

⭐️ 참고

[운영체제] 내부 단편화(Internal Fragmentation)와 외부 단편화(External Fragmentation)

J1Yun — Mon, 13 Mar 2023 16:12:03 +0900

단편화(Fragmentation)란?
메모리 공간이 부분으로 나뉘어서 충분히 사용 가능한 메모리가 남아있지만, 프로세스 할당이 불가능한 상태

내부 단편화(Internal Fragmentation)

프로세스가 필요한 양보다 더 큰 메모리가 할당되어 메모리 공간 낭비 발생
프로세스는 실제로 사용하지 않는 메모리 영역을 가지고 있게 됨

Ex) 100MB의 메모리에 80MB 크기의 프로세스 적재

다음과 같은 20MB의 내부 단편화 발생 (해당 메모리 사용 불가)

외부 단편화(External Fragmentation)

남아있는 총 메모리 공간이 프로세스가 요청한 메모리 공간보다 크지만, 남아있는 공간이 연속적이지 않아 사용할 수 없는 경우
쪼개진 메모리 공간을 사용할 수 없어 메모리 낭비 발생
프로세스들이 메모리를 할당하고 반납하는 과정에서, 사용할 수 있는 메모리 공간이 쪼개져서 발생

Ex) 100(50+50)MB 남아있는 메모리 공간에 80MB 프로세스 적재

남아있는 메모리 공간은 50MB+50MB =100MB로 요청한 메모리 공간 80MB보다 크지만, 남아있는 공간이 연속적이지 않아 Process C를 할당할 수가 없게됨

메모리 단편화 해결방법

1. 압축 (외부 단편화 해결)

메모리 재배치를 통해 분산(단편화)되어 있는 공간들을 하나로 합치는 기법

2. 통합 (외부 단편화 해결)

단편화로 인해 분산된 메모리 공간들 중 인접해 있는 공간끼리 통합시켜 큰 메모리 공간으로 합치는 기법
압축은 재배치가 일어나지만 통합은 인접한 공간끼리 합해진다는 차이

3. 페이징 (외부 단편화 해결)

프로세스의 가상 메모리를 고정 크기의 블록인 페이지(page) 단위로 분할하여 물리 메모리에 할당하는 기법
페이지들은 논리적으로 연속적인 공간으로 할당되지만, 물리적으로는 분산되어 할당
페이지 단위로 분할되어 할당되기 때문에 물리 메모리 내에 작은 공간이 남더라도 이를 페이지 크기로 합쳐 큰 공간으로 사용할 수 있기 때문에 외부 단편화 해결

4. 세그멘테이션 (내부 단편화 해결)

프로세스의 가상 메모리를 서로 다른 크기의 블록인 세그먼트(Segment) 단위로 분할하여 물리 메모리에 할당하는 기법
프로세스의 크기가 동적으로 변하는 경우에 효율적으로 메모리를 할당할 수 있어 내부 단편화 해결

5. 메모리 풀 (내부+외부 단편화 해결)

필요한 메모리 크기와 개수를 지정해 미리 할당을 받아 메모리 풀을 만들어 놓고 필요할 때마다 사용하고 반납
할당받았던 메모리 공간을 가져다 쓰고 반납하기 때문에 메모리 할당과 해제로 인한 외부 단편화가 생기지 않음
필요한 크기만큼 할당을 해놓기 때문에 내부 단편화 또한 생기지 않음
메모리 단편화로 인한 메모리 낭비량보다 메모리 풀을 만들었지만 쓰이지 않는 메모리의 양이 큰 경우에는 사용하지 않아야 함
미리 할당해 놓고 사용하지 않는 순간에도 역시 메모리 누수가 일어나는 것이므로 잦은 동적할당과 해제가 일어날 경우에 사용하는 것이 바람직

⭐️ 참고

[운영체제] 뮤텍스(Mutex)와 세마포어(Semaphore) - 동기화

J1Yun — Fri, 10 Mar 2023 15:01:15 +0900

교착 상태: https://zu-techlog.tistory.com/128

[운영체제] 교착 상태 (Dead Lock, 데드락)

교착 상태(Dead Lock, 데드락) 두 개 이상의 프로세스들이 서로가 가진 자원을 무한정 기다리며 멈추어 있는 상태 프로세스 A는 자원 1을 가지고서 자원 2를 요구, 프로세스 B는 자원 2를 가지면서 자

zu-techlog.tistory.com

임계 영역과 경쟁 상태: https://zu-techlog.tistory.com/129

[운영체제] 임계 영역(Critical Section)과 경쟁 상태(Race Condition)

임계 영역(Critical Section) 둘 이상의 프로세스 또는 스레드가 공유 자원에 접근할 때 순서 등의 이유로 결과가 달라질 수 있는 코드 영역 한 번에 하나의 프로세스나 스레드만 접근할 수 있는 코드

zu-techlog.tistory.com

뮤텍스(Mutex)

Key에 해당하는 오브젝트를 소유한 프로세스/스레드(이하 스레드) 만이 공유 자원에 접근할 수 있도록 하는 알고리즘
공유 자원을 lock()을 통해 잠금하고, unlock()을 통해 잠금을 해제
공유 자원에 대해 다중 스레드들의 접근을 조율하기 위해 동기화 또는 락 사용
잠금이 설정되면 다른 스레드는 잠금이 해제될 때까지 해당 영역에 접근할 수 없음 (동시 사용 불가)
공유 자원을 사용 중인 스레드가 있을 때 다른 스레드가 공유 자원에 접근하면 Blocking 후 대기 큐로 보내 sleep 시킴
잠금 또는 잠금 해제라는 상태만을 가지는 Boolean 타입의 Lock 변수 사용
공유 자원을 점유하는 스레드는 Key를 가지며 잠금 설정을 하고, 잠금 해제 시에는 Key를 다음 대기 스레드에게 반납
Lock을 건 스레드 만이 Lock을 해제할 수 있음

과정 예시

1번 프로세스가 자원을 접근하기 위해 Key를 점유한 후 공유 자원 이용
2번 프로세스는 공유 자원을 사용하기 위해 대기 (sleep)
3번 프로세스 또한 공유 자원을 사용하기 위해 2번 프로세스 다음 순번으로 대기
1번 프로세스가 공유 자원을 모두 사용하고 Key를 반환
2번 프로세스는 대기하고 있다가 반환된 Key를 점유하고 공유 자원을 사용

※ 스핀락(Spinlock)과의 차이
스핀락(Spinlock)은 락을 가지고 공유 자원에 진입할 수 있을 때까지 계속해서 진입을 시도하며 기다리기 때문에 CPU 낭비 발생
뮤텍스(Mute)는 Lock 변수를 통해 공유 자원에 진입이 불가함이 확인 되면 대기 큐로 들어가 sleep하기 때문에 효율적

세마포어(Semaphore)

공유 자원에 접근할 수 있는 최대 허용치 만큼 프로세스/스레드(이하 스레드)의 동시 접근을 허용하는 알고리즘
0이상의 정수를 담고 있는 세마포어 변수를 통해 wait과 signal 관리
접근 가능한 공유 자원의 수가 1개일 때는 이진 세마포어로 뮤텍스처럼 사용할 수 있음
Lock을 걸지 않은 스레드도 Signal을 보내 Lock을 해제할 수 있음
스레드가 공유 자원을 이용할 때 허용 접근 수(세마포어 변수)는 1 감소하고, 공유 자원을 빠져나올 때는 1 증가

과정 예시

공유 자원에 대한 최대 허용치를 정의 -> 허용치: 3
1번 프로세스가 공유 자원에 접근 -> 허용치 2로 감소
2번 프로세스가 공유 자원에 접근 -> 허용치 1로 감소
3번 프로세스가 공유 자원에 접근 -> 허용치 0로 감소
4번 프로세스가 공유 자원에 접근 -> 허용치가 0이므로 대기
2번 프로세스가 공유 자원을 모두 사용 -> 허용치 1로 증가
대기하던 4번 프로세스가 공유 자원에 접근 -> 허용치 0로 감소

뮤텍스와 세마포어의 차이

동기화 대상의 개수
- 뮤텍스는 동기화 대상이 오직 1개일 때 사용
- 세마포어는 동기화 대상이 1개 이상일 때 사용
세마포어는 뮤텍스가 될 수 있지만 뮤텍스는 세마포어가 될 수 없음
- 이진 세마포어(Binary Semaphore)는 뮤텍스처럼 동작
자원 소유 가능 여부
- 뮤텍스는 Lock을 통해 자원에 대한 소유권과 그 책임을 가짐
- 세마포어는 자원을 소유할 수 없음
잠금 해제 주체
- 뮤텍스는 Lock을 한(소유권을 가진) 스레드만이 뮤텍스를 해제할 수 있음
- 세마포어는 Lock을 하지 않은 스레드도 Signal을 통해 뮤텍스를 해제할 수 있음
Clean Up
- 뮤텍스는 프로세스가 종료될 때 자동으로 Clean Up
- 세마포어는 시스템 상에 파일로 존재

⭐️ 참고

[자료구조] 단순/원형/이중 연결리스트(Linked List) 구현 - 파이썬(Python)

J1Yun — Tue, 7 Mar 2023 18:12:34 +0900

연결리스트(Linked List)

다음 순서의 자료가 있는 위치를 데이터에 포함시키는 방식으로 자료를 저장하는 선형 자료구조
연결리스트는 Node로 구성되어 있고, Node 안에는 Data와 Link(Next)로 구성
- Data: 데이터 값 저장
- Link(Next): 다음 노드를 가리킴

장점

데이터 추가, 삭제에 유리
- 배열: 시간복잡도 O(n)
- 연결리스트: 시간복잡도 O(1)
공간복잡도 측면에서 유리 (배열처럼 연속된 공간을 할당하지 않고 필요 시에만 메모리를 동적 할당하기 때문)
- 메모리 누수 X
- 유연한 메모리 관리

단점

데이터 탐색 시 불리 (데이터의 논리적 저장 순서와 물리적 저장 순서가 일치하지 않아 인덱스 접근이 아닌 전체를 순회해야 하기 때문)
- 배열: 시간복잡도 O(1)
- 연결리스트: 시간복잡도 O(n)
테이터 정렬 시 불리

단순 연결리스트(Singly Linked List)

가장 단순히 다음 노드에 대한 참조만 고려한 형태의 연결리스트
마지막 노드는 항상 NULL을 가리킴
헤드 포인터의 주소나 다음 노드의 주소가 부정확할 때 데이터 유실의 위험이 높음 (안정적X)

1. 노드 생성

class Node:
    def __init__(self, val):
        self.data = val
        self.next = None

2. 연결리스트 초기화

class SimplyLinkedList:
    def __init__(self):
        self.nodeCount = 0  # 연결리스트 내 노드 수
        self.head = None  # 첫 번째 노드
        self.tail = None  # 마지막 노드

3. 노드 삽입

# 맨 앞(head)에 노드 삽입
def insert_front(self, val):
    new_node = Node(val)
    
    if self.head is None:  # 빈 연결리스트일 때
    	self.head = new_node
        self.tail = new_node
        
    else:  # 빈 연결리스트가 아닐 때
    	new_node.next = self.head
        self.head = new_node
    
    self.nodeCount += 1
 
 
# 중간에 노드 삽입
def insert_middle(self, target, val):
    current = self.head
    
    while current != None:
    	previous = current
        current = current.next
        
        if previous.data == target:  # target 값을 가진 노드 뒤에 삽입
        	new_node = Node(val)
            new_node.next = current
            previous.next = new_node
            self.nodeCount += 1
            break
                    	

# 맨 끝(tail)에 노드 삽입
def insert_back(self, val):
    new_node = Node(val)
    
    if self.head is None:  # 빈 연결리스트일 때
    	self.head = new_node
        self.head = new_node
        
    else:  # 빈 연결리스트가 아닐 때
    	self.tail.next = new_node
        self.tail = new_node
        
    self.nodeCount += 1

4. 노드 삭제

def delete_front(self):
    # 연결리스트가 비어있지 않을 경우
    current = self.head
    self.head = self.head.next
    del(current)
    self.nodeCount -= 1
 
 
def delete_middle(self, target):
    current = self.head
    
    while current != None:
    	previous = current
        currrent = current.next
        
        if curren.data == target:
            previous.next = current.next
            del(current)
            self.nodeCount -= 1
            break
            
            
def delete_back(self):
    # 연결리스트가 비어있지 않을 경우
    previous = None
    current = self.head
    
    while current.next != None:  # tail 노드를 가리키고있는 바로 이전 노드를 찾아야하므로 전체 순회
    	previous = current
        currrent = current.next
    
    previous.next = None
    self.tail = previous
    del(current)
    self.nodeCount -= 1

원형 연결리스트(Circular Linked List)

단순 연결리스트에서 마지막 노드가 다시 첫 번째 노드를 가리키도록 설정한 형태의 연결리스트
NULL을 가리키는 노드가 없음

※ 원형 연결리스트의 구현 방식은 단순 연결리스트와 그 원리가 비슷하기 때문에 원형 연결리스트의 구현은 생략하겠음.

이중 연결리스트(Doubly Linked List)

단순 연결리스트에서 다음 노드 뿐만 아니라 이전 노드에 대한 참조도 고려한 형태의 연결리스트
노드와 노드가 상호 연결
역순 접근 및 탐색 가능

1. 노드 생성

class Node:
    def __init__(self, val):
        self.data = val
        self.prev = None
        self.next = None

2. 연결리스트 초기화

class DoublyLinkedList:
    def __init__(self):
        self.head = None  # 첫 번째 노드
        self.tail = None  # 마지막 노드
        self.head.next = self.tail
        self.tail.prev = self.head

3. 노드 삽입

# 맨 앞(head)에 노드 삽입
def insert_front(self, val):
    new_node = Node(val)
    
    if self.head is None:  # 빈 연결리스트일 때
    	self.head = new_node
        self.tail = new_node
        self.head.next = tail
        self.tail.prev = head
        
    else:  # 빈 연결리스트가 아닐 때
    	new_node.next = self.head
        self.head.prev = new_node
        self.head = new_node
    
    self.nodeCount += 1
 
 
# 중간에 노드 삽입
def insert_middle(self, target, val):
    current = self.head
    
    while current != None:
    	previous = current
        current = current.next
        
        if previous.data == target:  # target 값을 가진 노드 뒤에 삽입
        	new_node = Node(val)
            new_node.next = current
            current.prev = new_node
            previous.next = new_node
            new_node.prev = previous
            self.nodeCount += 1
            break
                    	

# 맨 끝(tail)에 노드 삽입
def insert_back(self, val):
    new_node = Node(val)
    
    if self.head is None:  # 빈 연결리스트일 때
    	self.head = new_node
        self.head = new_node
        self.head.next = tail
        self.tail.prev = head
        
    else:  # 빈 연결리스트가 아닐 때
    	self.tail.next = new_node
        new_node.prev = self.tail
        self.tail = new_node
        
    self.nodeCount += 1

4. 노드 삭제

def delete_front(self):
    # 연결리스트가 비어있지 않을 경우
    current = self.head
    self.head = self.head.next
    self.head.prev = None
    del(current)
    self.nodeCount -= 1
 
 
def delete_middle(self, target):
    current = self.head
    
    # target은 압쪽에 위치한다고 가정 (target 데이터가 tail과 가깝게(뒷쪽에) 위치한다면 역순회로 구현)
    while current != None:
        currrent = current.next
        
        if curren.data == target:
        	left = current.prev
            right = current.next
            left.next = right
            right.prev = left
            del(current)
            self.nodeCount -= 1
            break
            
            
def delete_back(self):
    # 연결리스트가 비어있지 않을 경우
    current = self.tail
    self.tail = self.tail.prev
    self.tail.next = None
    del(current)
    self.nodeCount -= 1

[운영체제] 임계 영역(Critical Section)과 경쟁 상태(Race Condition)

J1Yun — Fri, 3 Mar 2023 11:14:06 +0900

임계 영역(Critical Section)

둘 이상의 프로세스 또는 스레드가 공유 자원에 접근할 때 순서 등의 이유로 결과가 달라질 수 있는 코드 영역
한 번에 하나의 프로세스나 스레드만 접근할 수 있는 코드 영역
한 프로세스가 critical section에 접근하고자 했지만 다른 프로세스가 이미 해당 영역에서 작업을 하고 있다면 entry section에서 대기하고 있다가 exit section으로부터 작업 종료 신호를 받으면 critical section에 진입하도록 동기화 필요
상호 배제(Mutual Exclusion): 한 프로세스가 임계 영역에서 작업 중이라면 다른 프로세스가 접근하지 못하도록 통제가 필요함
진행(Progress): 아무도 임계 영역에 진입하지 못하면 안되며 아무도 임계영역에 있지 않다면 진입하고자 하는 프로세스를 진입시켜야함
유한 대기(Bounded Waiting): 프로세스가 임계 영역에 진입하기 위해 무한정으로 기다리는 기아 현상(Starvation)이 발생해서는 안됨

※ 코드 영역

entry section
- critical section에 진입하기 위해 집입 허가를 요청하는 영역
- 접근 제어(lock)
critical section
- 하나의 프로세스나 스레드만 접근할 수 있는 영역
exit section
- 제어(lock)을 해제하는 등 더 이상 임계 구역에 머무르지 않음을 알리는 영역
remainder section
- entry, critical, exit을 제외한 나머지 코드 부분 영역

경쟁 상태(Race Condition)

임계 영역에 두 개 이상의 프로세스/스레드가 접근했을 때 발생할 수 있는 문제
임계 영역 내에서 두 개 이상의 프로세스/스레드가 공유 자원(Shared Resource)를 동시에 변경할 경우 실행 순서에 따라 결과가 달라짐 (일관성 저하)

공유 자원(Shared Resource)란?
시스템 안에서 각 프로세스나 스레드가 함께 접근해서 사용할 수 있는 모니터, 프린터, 파일, 데이터 등의 자원이나 변수

Ex) 두 개의 스레드가 전역 변수의 값을 1씩 증가

Tread 1: read value -> 0
Tread 2: read value -> 0
Tread 1: increase value -> 1
Tread 2: increase value -> 1 (일반적으로 두 번 증가시켰으므로 2가 되어야 하지만 위의 순서로 실행될 경우 값이 1로 변경)

경쟁 상태가 발생하는 경우

커널 작업을 수행하는 중에 인터럽트가 발생했을 때
- 문제상황: 커널모드에서 데이터를 로드하여 작업을 수행하다가 인터럽트가 발생하여 같은 데이터를 조작하는 경우
- 해결법: 커널모드에서 작업을 수행하는 동안 인터럽트를 disable 시켜 CPU 제어권을 가져가지 못하도록 함
프로세스가 시스템 콜을 통해 커널모드로 진입하여 작업을 수행하는 도중 문맥 교환이 발생했을 때
- 문제상황: 프로세스1이 커널모드에서 데이터를 조작하다가 할당 시간이 초과되어 CPU 제어권이 프로세스2로 넘어가 같은 데이터를 조작하는 경우
- 해결법: 프로세스가 커널모드에서 작업하는 경우 할당 시간이 초과되어도 문맥 교환을 하지 않도록 함
멀티 프로세서 환경에서 공유 메모리 내의 커널 데이터에 접근할 때
- 문제상황: 2개의 CPU가 동시에 커널 내부의 공유 데이터에 접근하여 조작하는 경우
- 해결법: 커널 내부에 있는 각 공유 데이터에 접근할 때마다 해당 데이터에 대해 Lock/Unlock을 함

※ 경쟁 상태를 해결하는 방법(뮤텍스, 세마포어)은 다음 포스팅에서 작성하겠다.

참고

[운영체제] 교착 상태 (Dead Lock, 데드락)

J1Yun — Thu, 2 Mar 2023 14:47:34 +0900

교착 상태(Dead Lock, 데드락)

두 개 이상의 프로세스들이 서로가 가진 자원을 무한정 기다리며 멈추어 있는 상태
프로세스 A는 자원 1을 가지고서 자원 2를 요구, 프로세스 B는 자원 2를 가지면서 자원 1을 요구

교착 상태 발생 조건

상호 배제(Mutual Exclusion)
- 한번에 하나의 프로세스만이 공유 자원을 사용할 수 있어야 함
점유와 대기(Hold and Wait)
- 모든 프로세스는 최소 하나의 자원을 점유하면서 다른 프로세스가 가지고 있는 자원을 기다리고 있어야 함
비선점(Non Preemption)
- 다른 프로세스가 자신에게 할당된 자원을 모두 사용해 반환할 때까지 강제로 뺏어올 수 없어야 함
환형 대기(Circular Wait)
- 공유 자원과 해당 자원을 사용하기 위해 대기하는 프로세스들이 원형으로 구성되어 있어야 함
- 자신에게 할당된 자원을 점유하면서 앞 or 뒤 프로세스의 자원을 요구

교착 상태 해결 방안

예방(Prevention): 교착 상태가 발생하지 않도록 발생 4가지 조건 중 하나를 제거하는 방법
회피(Avoidance): 교착 상태의 발생 가능성을 인정하면서 적절히 피해가는 방법
탐지(Detection): 교착 상태가 발생했는 지 점검하며 발견해내는 방법
회복(Recovery): 교착 상태가 발생한 프로세스와 자원을 되살려내는 방법

1. 예방(Prevention)

상호 배제 조건 부정
- 공유 자원을 여러개의 프로세스가 한번에 사용할 수 있도록 함
점유와 대기 조건 부정
- 프로세스가 실행되기 전 필요한 모든 자원을 할당하여 대기 과정을 없애거나 자원을 점유하지 않은 상태에서만 자원을 요구할 수 있도록 함
- 자원 낭비 증가
비선점 조건 부정
- 프로세스가 다른 자원을 요구할 때 이미 점유하고 있던 자원은 다른 프로세스가 선점할 수 있도록 함
- 기아 상태 발생 가능
환형대기 조건 부정
- 자원을 선형 순서로 분류하여 고유 번호를 할당하고, 각 프로세스는 현재 점유한 자원의 고유 번호보다 앞이나 뒤 어느 한쪽 방향으로만 자원을 요구하도록 함
- 모든 프로세스에 자원 할당 순서를 부여

2. 회피(Avoidance)

은행원 알고리즘(Banker's Algorithm)
- 프로세스의 자원 할당량을 미리 파악해 최소한 하나의 프로세스에게 할당해줄 만큼의 자원은 CPU가 보유하고 있어야 한다는 개념
- 각 프로세스에게 자원을 할당했을 때 교착상태가 발생하지 않으며 모든 프로세스가 완료될 수 있는 상태를 안전상태, 교착상태가 발생할 수 있는 상태를 불안전 상태라고 함
- 특정 프로세스가 자원을 요청했을 때 해당 요청으로 시스템이 불안전 상태에 빠진다면 이를 거절하는 방식
- 계속해서 안전상태를 유지해야하기 때문에 자원 사용률이 낮음
- 프로세는 최대 자원 요구량을 미리 파악해야하며 자원을 반드시 순환시켜야 하는 부담
- 자원의 양과 사용자(프로세스) 수가 일정해야 함

3. 탐지(Detection)

교착 상태 발견 알고리즘
- Allocation, Request, Available 등으로 시스템에 데드락이 발생했는지 여부를 탐색
- 은행원 알고리즘에서 했던 방식과 유사하게 현재 시스템의 자원 할당 상태를 가지고 파악
자원 할당 그래프 이용

4. 회복(Recovery)

프로세스 종료
- 교착 상태에 있는 프로세스를 강제 종료
- 모든 프로세스를 중단시키는 방법과, 하나씩 중단시키며 회복되는지 확인하는 방법이 있음
자원 선점
- 교착상태에 있는 프로세스로부터 점유 자원을 선점(회수)하여 다른 프로세스에게 할당

[운영체제] CPU 스케줄링 알고리즘 - 비선점형, 선점형

J1Yun — Tue, 28 Feb 2023 15:00:31 +0900

CPU 스케줄링 척도

1. CPU 이용률(CPU utilization): 시간당 CPU를 사용한 시간의 비율
2. 처리율(Throughput): 시간당 처리한 작업의 비율
3. 반환시간(Turnaround Time): 프로세스가 생성된 후 종료되어 사용하던 자원을 모두 반환하는 데까지 걸리는 시간
4. 대기시간(Waiting Time): 대기열에 들어와 CPU를 할당받기까지 기다린 시간
5. 반응시간(Response Time): 대기열에서 처음으로 CPU를 얻을 때까지 걸린 시간

-> CPU 이용률과 처리율은 극대화하는 것이 좋고 반환시간, 대기시간, 반응시간은 줄이는 것이 좋다

1. CPU 스케줄링 알고리즘 - 비선점형

비선점형 방식(non-preemptive)은 프로세스가 스스로 CPU 소유권을 포기하는 방식
강제로 프로세스를 중지하지 않음
다른 프로세스가 CPU를 점유하고 있다면 이를 뺏을 수 없음
컨텍스트 스위칭으로 인한 부하가 적지만 프로세스의 배치에 따라 효율성 차이가 많이 남
Ex) FCFS, SJF, 우선순위 등

1-1) FCFS(First Come First Served)

큐에 도착한 순서에 따라 가장 먼저 요청한 프로세스에게 CPU를 할당해주는 알고리즘

장점

개발 용이
기아 현상 발생 X
반환시간(Turnaround Time) 면에서 좋을 수 있음

단점

호위 효과(Convoy Effect)
- 소요 시간이 긴 프로세스가 먼저 도달할 경우 효율성이 낮아짐
- 실행 시간이 짧은 작업이어도 늦게 도착하면 대기 시간이 길어짐
평균 대기 시간과 응답시간(Response Time)이 길어질 수 있음

1-2) SJF(Shortest Job First)

큐에 도착한 프로세스 중 실행 시간(Burst Time)이 가장 짧은 프로세스를 먼저 실행하는 알고리즘
실제로는 실행 시간을 정확히 알 수 없기 때문에 과거의 실행 시간을 바탕으로 추측해서 사용

장점

평균 대기 시간이 짧음
짧은 작업에 유리

단점

기아 현상(Starvation)
- 실행 시간이 긴 프로세스의 경우 영원히 CPU 할당을 받지 못하게 될 수 있음
프로세스의 실제 실행 시간을 예측하기 어려움

1-3) 우선순위(Priority)

각 프로세스의 우선순위에 따라 우선순위가 가장 높은 프로세스에게 먼저 CPU를 할당하는 알고리즘
선점형과 비선점형으로 모두 설계 가능
기아 현상이 발생할 수 있지만 노화(Aging) 기법으로 해결 가능
- 오래된 작업일수록 우선 순위를 높여줌

2. CPU 스케줄링 알고리즘 - 선점형

현재 실행 중인 프로세스를 알고리즘에 의해 중단시키고 강제로 다른 프로세스에게 CPU 소유권을 할당하는 방식
다른 프로세스가 CPU를 점유하고 있더라도 이를 뺏을 수 있음
처리 시간이 매우 긴 프로세스의 CPU 독점을 막을 수 있지만 잦은 컨텍스트 스위칭으로 부하가 발생할 수 있음
Ex) Round Robin, SRF, MLQ/MLFQ

2-1) Round Robin(RR)

각 프로세스에게 동일한 할당 시간(Time Quantum)을 부여해서 해당 시간 동안만 CPU를 이용하도록 하는 알고리즘
할당 시간 안에 끝나지 않으면 다시 준비 큐(Ready Queue)의 가장 뒤로 돌아가고 CPU는 다음 프로세스를 실행

장점

n개의 프로세스에 대해 할당 시간이 q라면 어떤 프로세스도 (n-1)q 이상의 시간을 기다리지 않아도 됨
응답시간(Response Time)이 빠름
공정한 스케줄링 기법이며 프로세스들의 CPU 사용 시간이 랜덤하게 섞여 있을 경우 효율적

단점

할당 시간 q가 커지면 FCFS처럼 동작
할당 시간 q가 작아지면 컨텍스트 스위칭이 찾아져서 오버헤드가 커짐

2-2) SRF/SRTF(Shortest Remaining Time First)

SJF의 선점형 방식
현재 실행 중인 프로세스의 남은 시간보다 더 짧은 실행 시간을 가진 프로세스가 도착할 경우 CPU를 강제로 회수하여 교체하는 알고리즘
새로운 프로세스가 도달할 때마다 스케줄링을 다시 하기 때문에 CPU 사용 시간을 측정할 수 없고, 기아 현상 발생 가능

2-3) Multi-Level Queue(다단계 큐)

여러 종류의 준비 큐(Ready Queue)를 활용하는 알고리즘
각 준비 큐에는 서로 다른 스케줄링 알고리즘을 적용
- 우선순위가 낮은 큐들이 실행 못하는 걸 방지하고자 각 큐마다 다른 Time Quantum을 설정 해주는 방식
- 우선순위가 높은 큐는 작은 Time Quantum 할당. 우선순위가 낮은 큐는 큰 Time Quantum 할당
- 일반적으로 Foreground 프로세스들은 Round Robin 방식을 사용하고, Background 프로세스는 FCFS를 사용
각 큐 사이에서 프로세스 이동은 불가해 스케줄링 부담이 적음
낮은 순위의 큐에 위치한 프로세스가 실행되지 않는 기아 현상이 발생할 수 있음

2-4) MFQ/MLFQ(Multi-Level Feedback Queue)

Multi-Level Queue와 비슷하지만 큐 간에 프로세스들이 이동할 수 있는 알고리즘
Multi-Level Queue에서 자신에게 할당된 Time Quantum을 모두 사용한 프로세스는 밑으로 내려가고 Time Quantum을 다 채우지 못한 프로세스는 원래 큐 위치 그대로 둠
처리 시간이 짧은 프로세스를 먼저 처리하기 때문에 반환시간(Turnaround Time)을 줄여주며 짧은 작업에 유리

⭐️ 참고

[네트워크] HTTP 주요 메서드 - GET, POST, PUT, PATCH, DELETE

J1Yun — Mon, 27 Feb 2023 15:47:56 +0900

HTTP 메서드

HTTP 메서드란 클라이언트와 서버 사이에 이루어지는 요청(Request)과 응답(Response) 데이터를 전송하는 방식이다.

HTTP 메서드의 종류는 총 9가지인데, 이중 주로 사용하는 메소드 5가지와 기타 메서드 4가지로 구분된다.

주요 메서드

GET: 리소스 조회
POST: 요청 데이터 처리, 주로 등록에 사용
PUT: 리소스를 대체하며 해당 리소스가 없으면 생성
PATCH: 리소스 부분 변경
DELETE: 리소스 삭제

기타 메서드

HEAD: GET과 동일하지만 메시지(body) 부분을 제외하고 상태 줄과 헤더만 반환
OPTIONS: 대상 리소스에 대한 통신 가능 옵션을 설명 (주로 CORS에서 사용)
CONNECT: 대상 자원으로 식별되는 서버에 대한 터널을 설정
TRACE: 대상 리소스에 대한 경로를 따라 메시지 루프백 테스트 수행

HTTP 메서드 특징

안전성(Safe)
- 안전한 메서드의 목적은 서버에 영향을 줄 수 있는 메서드가 사용될 때 사용자들에게 그 사실을 알려줄 수 있도록 하는 것
- 읽기 전용일 때 안전한 메서드로 간주
- Ex) GET, HEAD, OPTIONS, TRACE
멱등성(Idempotent)
- 특정 메서드의 요청을 여러번 하더라도 동일한 결과가 반환될 때 멱등하다고 함
- Ex) GET, PUT, DELETE, HEAD, OPTIONS, TRACE
캐시 가능성
- 추후 재사용을 위해 응답을 저장할 수 있음을 나타냄
- Ex) GET, POST, PATCH, HEAD

1. GET

리소스 조회 / 데이터 검색 (Read)
서버에 전달하고 싶은 데이터는 쿼리 스트링(Query-String)을 통해 전달
- Ex) GET /users/10?username=jiyun&age=24
여러 개의 동일한 요청을 보내면 매번 같은 결과가 생성 (멱등성)
캐싱이 가능하기 때문에 데이터 조회 시 GET을 사용하는 것이 유리

2. POST

데이터 추가/생성/처리 (Create/Insert)
메시지 바디(body)를 통해 서버로 요청 데이터 전달 -> 서버는 요청 데이터를 처리하여 업데이트
주로 신규 리소스 등록, 프로세스 처리에 사용
멱등성을 가지지 않아 동일한 POST 요청을 하여도 다른 리소스가 생성

3. PUT

기존 리소스 수정 / 데이터 갱신 (Update)
메시지 바디 내의 리소스가 있으면 덮어쓰고, 없으면 새로 생성
클라이언트는 리소스의 구체적인 경로를 지정해주어야 함
- Ex) PUT /users/10: 10번 유저 수정

4. PATCH

리소스의 일부 부분 변경 (Update)
메시지 바디 내의 리소스만을 부분적으로 업데이트 (PATCH를 지원하지 않는 경우 POST로 대체)

5. DELETE

기존 리소스 삭제 (Delete)
자원 삭제 후 해당 자원이 사라져 응답할 내용이 없는경우 204(NO CONTENT) 반환

※ GET과 POST의 차이

GET은 서버 상의 데이터나 상태를 변경시키지 않아야하기 때문에 조회를 위해서만 사용하지만, POST는 데이터 추가/생성/처리 등을 위해 사용한다.

GET은 멱등성을 가지고 있기 때문에 매 요청 시마다 같은 결과를 내지만 POST는 멱등성이 없다.

GET과 POST의 자세한 특징과 차이는 아래 포스팅에 자세히 정리해놓았다.
https://zu-techlog.tistory.com/65

[네트워크] GET 메서드와 POST 메서드 특징, 차이

GET과 POST는 HTTP 프로토콜을 이용해 서버에 데이터를 전달할 때 사용되는 방식이다. 각각 GET과 POST 메서드의 특징 및 차이는 다음과 같다. GET 메서드 개념 정보 조회를 위한 메서드 클라이언트가

zu-techlog.tistory.com

※ POST와 PUT의 차이

POST는 Create/Insert의 개념이고, PUT은 Update의 개념이다.

PUT은 POST와 달리 클라이언트가 리소스의 위치를 알고 URI를 지정해 주어야 한다.

POST는 멱등성을 가지지 않는 반면, PUT은 멱등성을 가진다.

※ PUT과 PATCH의 차이

PUT은 리소스 전체를 교체하고, PATCH는 일부 데이터만 변경한다.

PUT 요청에서 PATCH 요청처럼 메시지 바디에 일부 데이터만 명시해 변경하려 한다면, 명시되지 않은 자원 데이터는 사라진채 덮어씌워진다.

[운영체제] IPC(Inter Process Communication) - 프로세스 간 통신

J1Yun — Mon, 27 Feb 2023 15:47:02 +0900

IPC(Inter Process Communication)

독립적인 메모리 공간을 갖는 프로세스 간의 통신 기법
한 프로세스가 다른 프로세스의 자원을 사용하기 위해 동시에 접근 가능한 메모리 즉, 프로세스들이 공유하는 메모리가 필요
커널 영역에서 IPC라는 내부 프로세스 간 통신 설비를 제공

1. 공유 메모리 (Shared Memory)

공유 메모리(Shared Memory)가 데이터 자체를 공유하도록 설비
프로세스가 공유 메모리 할당을 커널에 요청하면 커널은 해당 프로세스에 메모리 공간을 할당
모든 프로세스는 공유 메모리에 접근할 수 있음
Text와 Data 영역 사이 공유 메모리 포인팅 공간 (각 프로세스가 메모리 영역에 첨부되는 방식)
프로세스 간 Read, Write를 모두 필요로 할 때 사용
중개자 없이 곧바로 메모리에 접근할 수 있기 때문에 모든 IPC 중 가장 빠르게 작동
동기화에 주의

2. 파이프 (Pipe)

통신을 위한 메모리 공간(버퍼)을 생성하여 프로세스가 데이터를 주고 받게끔 함
단방향 통신 지원

2-1) 익명 파이프 (Anonymous PIPE)

익명의 PIPE를 통해 동일한 부모-자식 or 형제 프로세스 간의 단방향 통신을 지원
- 통신할 프로세스를 명확히 알 수 있어야 함
- 외부 프로세스에서 사용할 수 없음
파이프로 두 개의 프로세스를 연결하고 하나의 프로세스는 데이터를 쓰기만, 다른 하나는 데이터를 읽기만 함
한쪽 방향으로만 통신이 가능한 파이프의 특성 때문에 반이중(Half-Duplex) 통신이라고도 부름
간단하게 사용할 수 있지만 전이중 통신으로 송/수신을 모두 하려면 두 개의 파이프를 만들어야 해서 구현이 복잡해짐
pipe 함수로 생성

2-2) 네임드 파이프 (Named PIPE)

이름이 있는 파일을 사용하기 때문에 부모 프로세스와 무관한 다른 프로세스끼리도 통신 가능
- 다른 프로세스들이 PIPE 이름만 알면 통신 가능
- 외부 프로세스도 사용 가능
익명 파이프와 마찬가지로 반이중 통신 방식이기 때문에 전이중 통신을 위해서는 두 개의 파이프를 만들어야해 구현이 복잡해짐
mkfifo나 mknod 함수로 생성

3. 소켓 (Socket)

동일한 호스트 운영 체제에서 실행되는 프로세스 간 데이터를 교환하기 위한 데이터 통신 엔드포인트
네트워크 소켓 통신을 통해 데이터 공유
- 데이터 교환을 위해 양쪽 PC에서 각각 임의의 포트를 정하고 해당 포트 간의 연결을 통해 데이터를 주고 받는 방식
- 각 PC가 타 PC 포트에 연결되면 PIPE처럼 1대1로 데이터를 주고받음
같은 도메인 내 원격에서 프로세스 간 데이터를 공유할 때 사용
클라이언트/서버의 통신 구조
- 서버는 bind, listen, accept 과정을 통해 소켓 연결 준비
- 클라이언트는 connect를 서버에 요청
- 연결 수립 후 socket에 데이터 send()
- 연결 해제 시 socekt close()
전이중(Full Duplex)/양방향 통신이 가능

4. 메시지 큐 (Message Queue)

입출력 방식은 Named PIPE과 동일하지만 데이터 흐름이 아닌 메모리 공간을 사용한 PIPE임
다수의 프로세스 간 메시지를 전달할 수 있음
사용할 데이터에 번호를 붙혀 여러 프로세스가 동시에 데이터를 쉽게 다룰 수 있음
메시지 접근을 위해 key 필요

5. 메모리 맵 (Memory Map)

공유 메모리처럼 메모리 공간을 공유하지만 열린 파일을 메모리에 매핑시켜 공유하는 방식
프로세스의 가상 메모리 주소 공간에 파일을 매핑한 뒤 가상 메모리 주소로 직접 접근하는 것으로 파일 읽기/쓰기를 대신
주로 파일로 대용량 데이터를 공유해야할 때 사용
페이징 기법을 사용해 파일의 내용을 관리하며 페이지 크기에 따라 적절히 파일의 내용을 읽고 쓸 수 있음
대부분 운영체제에서는 프로세스를 실행할 때 실행 파일의 각 세그먼트를 메모리에 사상하기 위해 메모리 맵 파일을 이용

6. RPC (Remote Procedure Call)

별도의 원격 제어를 위한 코딩 없이 다른 주소 공간에서 함수나 프로시저를 실행할 수 있게하는 프로세스 간 통신 기술
원격 프로시저 호출을 통해 프로그래머는 함수가 실행 프로그램에서 로컬 위치에 있던 원격 위치에 있든 동일한 코드를 이용할 수 있음
분산 네트워크 망에서 많이 사용하는 방식
분리된 PC에 저장된 데이터를 마치 내 PC에 존재하는 것처럼 데이터를 가져와 사용하는 통신 방법
- 스텁(Stub)을 통해 마치 데이터가 자신의 디스크에 존재하는 것처럼 착각을 일으킴

IPC 정리

IPC 종류	PIPE	Named PIPE	Message Queue	Shared Memory	Memory Map	Socket
용도	부모 자식 간 단방향 통신	다른 프로세스와 단방향 통신	다른 프로세스와 단방향 통신	다른 프로세스와 양방향 통신	다른 프로세스와 양방향 통신	다른 시스템 간 양방향 통신
공유 매개체	파일	파일	메모리	메모리	파일+메모리	소켓
통신단위	stream	stream	구조체	구조체	페이지	stream
통신방향	단방향	단방향	단방향	양방향	양방향	양방향
통신 가능 범위	동일 시스템	동일 시스템	동일 시스템	동일 시스템	동일 시스템	동일+외부 시스템

⭐️ 참고

[운영체제] PCB와 문맥 교환(Context Switching)

J1Yun — Fri, 24 Feb 2023 15:00:19 +0900

PCB (Process Control Block)

운영체제가 시스템 내의 프로세스들을 관리하기 위해 프로세스마다 유지해야하는 정보들을 담는 커널 내 자료구조
- 커널 주소 공간의 data 영역에 존재
프로세스의 메타 데이터들이 저장되는 곳
- Process ID
- Process 상태
- CPU Regiter 값
- CPU 스케줄링 정보
- 메모리 사용/관리 정보
- 등등
Linked List 방식으로 관리
- PCB 생성마다 PCB List Head에 주소값으로 연결

PCB가 필요한 이유

CPU에서는 프로세스의 상태에 따라 주기적으로 프로세스를 교체해주는 작업이 필요하다. 이를 문맥 교환(Context Switching)이라고 한다. 문맥 교환 시 현재 CPU 상에서 실행되고 있던 프로세스의 정보(문맥)을 자신의 PCB에 저장하고, 새롭게 CPU 할당을 받게되는 프로세스는 PCB로부터 예전에 저장했던 자신의 정보(문맥)을 복원시켜 이어서 실행할 수 있어야 한다. 이렇듯 PCB는 문맥 교환 과정에서 프로세스의 정보/상태/문맥을 저장하기 위해 사용된다.

문맥 교환(Context Switching)

CPU/코어에서 실행중이던 프로세스/스레드가 다른 프로세스/스레드로 교체되는 것 (프로세스/스레드 -> 이하 프로세스)
하나의 프로세스로부터 다른 프로세스로 CPU 제어권이 이양되는 과정
멀티 태스킹(Multitasking), 인터럽트 핸들링(Interrupt Handling) 시 문맥 교환 발생
- 프로세스가 주어진 time slice(quantum)를 다 사용했다는 인터럽트가 발생했을 때
- 입출력 요청(IO 작업) 등에 대한 인터럽트가 발생했을 때
- 자식 프로세스 생성, 인터럽트 처리 대기 등 프로세스가 다른 리소스를 기다려야할 때
- 다른 리소스를 기다리지 않아도 되는 그 외 인터럽트나 시스템콜 발생 시에는 유저에서 커널로 모드만 바뀔 뿐 문맥 교환 X
여러 프로세스가 동시에 실행되는 것처럼 느껴지게 하기 위해 사용 (멀티 태스킹)
짧은 time slice 등으로 인한 잦은 문맥 교환은 오버 헤드를 발생

Context Switching 과정

P1 실행 중 운영체제에서 프로세스의 스케줄러에 의해 인터럽트 발생
프로세스가 실행되는 유저 모드에서 커널 모드로 전환
기존에 실행되었던 현재 프로세스(P1)의 상태/정보를 자신의 PCB1에 저장
PCB2로부터 다음에 실행되는 프로세스(P2)의 상태/정보 복구
커널 모드에서 유저 모드로 전환
새로운 프로세스 P2 실행

프로세스 상태 전이에 따른 문맥 교환이 필요한 상황

필요 상황	설명	전이 과정
dispatch	새롭게 CPU 할당 받아 실행 상태로 전이	준비 → 실행 (dispatch)
CPU 할당 시간 만료	CPU 할당 시간 만료로 준비 상태로 전이	실행 → 준비 (Timeout)
I/O 작업 및 할당	I/O 작업이 필요하여 작업 완료 시까지 대기 상태로 전이	실행 → 대기 (Sleep)
System Call	또다른 서비스 호출이 필요한 경우 대기 상태로 전이	실행 → 대기 (Sleep

문맥 교환의 오버헤드 해결 방안

다중 프로그래밍 수준(time slice 주기)을 낮추어 문맥 교환 발생 빈도 감소
스레드를 이용해 문맥 교환 부하 최소화 (스레드는 메모리 영역을 공유하여 메모리 주소 관련 처리를 수행할 필요 X)
스택 이용 프로그램의 경우 스택 포인터를 활용해 문맥 교환 부하 최소화

⭐️ 참고

[운영체제] 유저모드(User-Mode)와 커널모드(Kernel-Mode), 인터럽트(Interrupt)와 시스템콜(System Call)

J1Yun — Thu, 23 Feb 2023 15:27:37 +0900

유저 모드(User-Mode)와 커널 모드(Kernel-Mode)

커널에서는 중요한 자원을 관리하기 때문에 사용자가 해당 자원에 쉽게 접근하지 못하도록 보호하기 위해 나뉨
시스템에 중요한 영향을 미치는 연산은 커널 모드에서만 실행되도록 함으로써 하드웨어 보안 유지
프로세스가 실행되는 동안 유저 모드와 커널 모드를 반복적으로 넘나듬
유저 애플리케이션은 시스템 서비스를 호출할 때 유저 모드에서 커널 모드로 전환

유저/사용자 모드

사용자가 접근할 수 있는 영역을 제한적으로 두고 프로그램의 자원에 함부로 접근하지 못하도록 하는 모드
하드웨어 직접 접근 불가능
코드 작성, 프로세스 실행 명령 등 실행 가능
유저 애플리케이션 코드가 실행

커널 모드

모든 시스템 메모리 등 하드웨어에 직접 접근 가능
모든 CPU 명령 실행 가능
운영체제 코드나 디바이스 드라이버 같은 커널모드 코드가 실행

인터럽트(Interrupt)

시스템에서 발생한 다양한 종류의 이벤트 or 그런 이벤트를 알리는 메커니즘
인터럽트 신호가 들어오면 CPU를 잠깐 정지, 즉각적으로 인터럽트를 처리하기 위해 커널 코드를 커널 모드에서 실행
키보드/마우스 등 IO 디바이스로 인한 인터럽트, 0으로 나누는 산술 연산에서의 인터럽트, 처리 시간이 다 되었을 때의 인터럽트, 프로세스 오류로 인한 인터럽트 등 발생
- 하드웨어 인터럽트: IO 디바이스에서 발생하는 인터럽트
- 소프트웨어 인터럽트(트랩): 0으로 나누는 산술 연산, 잘못된 메모리 공간 접근 등 프로세스 오류로 발생하는 인터럽트

인터럽트 처리 과정

인터럽트 요청
프로세스 실행 중단 (실행 중이던 명령까지만 수행)
PCB(Process Control Block)에 현재 프로세스 상태 저장, PC(Program Counter)에 다음 실행할 명령 주소 저장
인터럽트 벡터를 읽고 인터럽트 처리 루틴 실행 (인터럽트 처리)
처리 완료 시 저장했던 프로세스 상태 복구
인터럽트 해제 및 중단된 프로세스 재개

시스템콜(System Call)

운영체제가 커널에 접근하기 위한 인터페이스
프로그램이 OS커널이 제공하는 서비스를 이용하고 싶을 때 시스템콜 발생
유저 모드에서 커널 모드 영역의 기능을 사용할 수 있도록 커널 모드로 잠시 전환 (시스템콜을 기반으로 유저와 커널 분리)
프로세스/스레드 제어, 파일 조작, 장치 조작, 소켓, 통신 등과 관련한 시스템콜 발생

파일 Read 예제

⭐️ 참고

[운영체제] 동기/비동기(Sync/Async), 블로킹/논블로킹(Blocking/Non-Blocking)

J1Yun — Wed, 22 Feb 2023 15:25:25 +0900

동기/비동기? 블로킹/논블로킹?

동기와 비동기, 블로킹과 논블로킹의 개념은 유사하게 느껴질 수 있지만 서로 바로보는 관점을 달리하고 있다.

동기/비동기는 일을 처리하는 순서(시점)와 결과(처리)와 관련있는 개념으로 이전 작업 종료와 동시에 시작하면 동기, 그렇지 않으면 비동기로 구분한다.

블로킹/논블로킹은 제어권과 관련있는 개념으로 함수 호출 시 제어권이 넘어가면 블로킹, 그렇지 않고 자신의 할일을 지속하면 논블로킹으로 구분한다.

동기(Synchronous)

작업을 동시에 수행하거나 동시에 끝나거나 끝나는 동시에 시작함
- 요청 작업의 종료 시점과 나머지 작업 요청 시작 시점의 동시성
호출한 함수의 작업 완료 응답이 필요해 작업 완료 여부를 계속해서 묻거나 응답을 기다림
호출한 함수의 작업 완료 여부에 대해 계속해서 관심을 갖음
응답(리턴값)에 대해 즉각적으로 처리

비동기(Asynchronous)

요청 작업의 종료와 다른 요청의 시작 시점이 일치하지 않으며 끝나는 동시에 시작하지 않음
함수를 호출하여 실행만 시킬 뿐 작업의 완료 여부에는 관심을 갖지 않으며 자신의 작업을 계속해서 이어감
응답(리턴값)에 대한 처리는 즉각적으로 이루어질 수도, 이루어지지 않을 수도 있음(나중에 처리)
요청 및 함수 호출 시 콜백 함수를 함께 전달하고, 응답이 준비되면 함께 보낸 콜백 함수가 실행됨

블로킹(Blocking)

A 함수가 B 함수를 호출하면 A는 B에게 제어권을 넘겨주고, B는 자신의 작업이 끝날 때까지 제어권을 가지고 있음
A 함수는 B 함수의 실행이 끝날 때까지 멈추고 기다림
B 함수가 수행을 완료해서 제어권을 다시 A함수에게 넘겨주면 A 함수는 자신의 작업을 다시 실행

논블로킹(Non-Blocking)

A 함수가 B 함수를 호출하면 제어권은 넘어가지 않은 채 B 함수가 실행
- 함수 호출 시 제어권이 B함수에게 넘어가지만 바로 A 함수에게 넘어간다고 보는 레퍼런스도 있지만 어찌됐든 핵심은 호출된 함수가 실행 중일 때도 제어권을 가지고 있다는 사실임
A 함수는 여전히 제어권을 가지고 있으므로 B 함수의 실행/종료 여부와 관계없이 계속해서 자신의 작업 수행

동기/비동기 + 블로킹/노블로킹 조합

1) Sync-Blocking

A 함수는 B 함수를 호출하며 제어권을 넘겨주고(블로킹), 함수 B의 리턴값을 기다림(동기)
A 함수는 B 함수의 리턴값과 제어권을 기다리며 아무것도 하지 않음

2) Sync-Nonblocking

A 함수는 B 함수를 호출하며 제어권을 넘기지 않고 자신의 작업을 계속 수행함(논블로킹)
A 함수는 B 함수의 리턴값이 필요하기 때문에 자신의 작업 실행 중간중간 B 함수의 종료 여부를 물어서 확인함(동기)
대표적 예) Polling

3) Async-Nonblocking

A 함수는 B 함수를 호출하며 제어권을 넘기지 않고 자신의 작업을 계속 수행함(논블로킹)
A 함수는 B 함수 호출 시 콜백 함수를 넘겨주며 B 함수의 종료 여부에 관심을 갖지 않음(동기)
B 함수는 자신의 작업이 완료되면 A 함수가 준 콜백 함수를 실행(동기)

4) Async-Blocking

A 함수는 B 함수를 호출하며 B 함수의 종료 즉, 리턴값에 신경쓰지 않으며 콜백 함수 만을 보냄(비동기)
A 함수는 B 함수의 작업에 관심이 없지만 제어권을 넘겨 B 함수가 종료될 때까지 기다림(블로킹)

[운영체제] 프로세스 메모리 구조 - Code, Data, Heap, Stack

J1Yun — Tue, 21 Feb 2023 14:28:32 +0900

프로세스 메모리 구조

Code(Text)

사용자가 작성한 프로그램 코드가 저장되는 공간
수행할 수 있는 기계어 명령의 형태로 변환되어 저장
변경이 불가능한 Read-Only

Data

전역 변수나 static 변수 등 프로그램이 사용하는 데이터를 저장하는 공간
전역 변수나 static 변수를 참조한 코드 부분은 컴파일이 완료되면 data 영역 내의 해당 주소값을 가리키도록 변경됨
전역 변수가 저장되는 공간은 Data 영역과 BSS 영역으로 나뉨
- Data: 초기화 된 전역 변수
- BSS: 초기화 되지 않은 전역 변수
컴파일 시 데이터가 저장되며 프로그램 종료 시 삭제됨
전역 변수의 값이 변경될 수 있으므로 Read-Write

Heap

프로그래머가 필요할 때마다 사용할 수 있는 메모리 공간
동적으로 메모리를 할당-해제
동적 메모리 할당이 일어나면 주소값이 커지는 방향으로 영역 확장

Stack

데이터를 일시적으로 저장하는 공간
호출된 함수가 수행을 마치고 복귀할 주소나 지역 변수, 매개 변수, 리턴값 등이 임시로 저장
프로그램 실행 중 함수 호출 시 데이터가 저장되고 함수의 수행이 완료되면 삭제됨
LIFO(Last In First Out) 방식으로 데이터 적재
데이터가 임시로 저장되면 주소값이 작아지는 방향으로 영역 확장 (Heap과 반대)
Stack 영역과 Heap 부분이 만난다면 메모리가 소진되었다는 의미로 계속해서 데이터를 저장하면 메모리 초과로 stack overflow 발생

⭐️ 참고

[운영체제] 프로세스와 스레드, 멀티 프로세스와 멀티 스레드

J1Yun — Mon, 20 Feb 2023 15:11:51 +0900

프로세스(Process)

프로그램이 메모리로 올라와 운영체제로부터 CPU를 할당받고 실행되고 있는 상태
CPU 스케줄링의 대상이 되는 작업의 흐름을 지칭
하나의 프로그램(애플리케이션)은 하나 이상의 프로세스를 가짐
각 프로세스는 별도의 주소 공간에서 실행되고 프로세스끼리 지원을 공유하지 않기 때문에 다른 프로세스의 변수나 자료구조에 접근할 수 없음
프로세스는 각각 독립된 메모리 영역(Code, Data, Stack, Heap)을 할당 받음

스레드(Thread)

프로세스 내에서 실행되는 흐름의 단위
하나의 프로세스는 하나 이상의 스레드를 가짐
각각의 스레드는 프로세스 내에서 Stack 영역만 따로 할당받고 Code, Data, Heap 영역은 서로 공유함

멀티프로세스(Multi-Process)

하나의 애플리케이션을 여러 개의 프로세스로 구성하여 각 프로세스가 하나의 작업을 처리하도록 하는 것
각각의 프로세스는 서로 공유하는 자원이 없음

장점

여러 개의 자식 프로세스 중 하나에 문제가 발생하면 해당 프로세스만 죽는 것으로 다른 프로세스에게 영향을 주지 않음 (독립적)

단점

Context Switching(문맥교환) 오버헤드
- 각각의 자식 프로세스는 독립된 메모리 영역을 할당받았기 때문에 문맥 교환 시 캐시에 있는 모든 데이터를 리셋하고 다시 캐시 정보를 불러와야 함
- 캐시 메모리 초기화 등 무거운 작업은 문맥 교환 과정에서 오버헤드가 발생하는 원인이 됨
프로세스 간 통신 기법(IPC) 필요
- 한 프로세스가 다른 프로세스의 자원에 접근하려면 프로세스 간 통신(IPC)을 사용해야함
- 예) 파이프, 소켓 등

Context Switching(문맥교환) 란?
한 번에 한 가지 작업밖에 처리하지 못하는 CPU의 특성에도 한 번에 여러 개의 프로세스나 스레드가 실행되는 것처럼 보이기 위해 여러 프로세스/스레드를 짧은 단위로 번갈아가며 실행해주어야 한다. 이때, 실행 중이던 프로세스/스레드를 중단하고 다른 프로세스/스레드를 실행하는 것을 Context Switching(문맥 교환)이라고 한다.

멀티스레드(Multi-Thread)

하나의 애플리케이션을 여러 개의 스레드로 구성하여 각 스레드가 하나의 작업을 처리하도록 하는 것
각각의 스레드는 Stack을 제외한 모든 자원을 공유

장점

시스템 자원의 소모 감소
- 프로세스 생성을 통해 자원을 할당하는 시스템 콜이 줄어 자원을 효율적으로 사용 및 관리할 수 있음
- 스레드 간 데이터를 주고받는 일이 간단해 시스템 자원 소모 적음
시스템 처리량 증가, 비용 감소 (Context Switching 오버헤드 감소)
- Stack을 제외한 자원을 공유하여 CPU 스케줄링 과정 Context Switching(문맥 교환) 시 비용과 부담이 적음
간단한 통신 방법으로 프로그램 응답 시간 단축
- IPC와 같은 복잡한 통신 기법을 사용하지 않아 통신의 부담이 적음

단점

동기화 문제
- 여러 스레드가 동시에 하나의 자원에 접근하는 경우에 대한 문제 발생
여러 개의 스레드 중 하나에 문제가 발생하면 해당 스레드 뿐만 아니라 다른 스레드의 작업에도 영향을 줌
- 프로세스 자체를 중단해야 함
구현, 테스트, 디버깅이 어려움

⭐️ 참고

[네트워크] DNS(도메인 네임 시스템) 구성요소, 동작방식

J1Yun — Tue, 14 Feb 2023 16:20:48 +0900

DNS(Domain Name System)

도메인 이름을 실제 IP 주소로 변환하여 연결해주는 시스템
사용자로 하여금 도메인 이름을 통해 실제 네트워크 상에서 사용하는 IP로 접속할 수 있도록 함
DNS는 상위 기관과 하위 기관과 같은 계층 구조를 가지는 분산 데이터베이스 구조
상위 기관에서 인증된 기관에게 도메인 생성 및 IP 주소로 변경할 수 있는 권한 부여

3가지 구성 요소

도메인 네임 스페이스(Domain Name Space)
- DNS가 저장/관리하는 계층적 구조
- 최상위에 루트 DNS 서버가 존재하고 그 하위로 연결된 모든 노드가 연속해서 이어진 계층 구조로 이루어짐

도메인 네임 스페이스

네임 서버(Name Server, =DNS서버): 권한 있는 DNS 서버
- 문자로 이루어진 도메인 이름을 실제 네트워크 통신 시 사용되는 IP주소로 변환하기 위해서는 도메인 네임 스페이스의 트리 구조에 대한 정보가 필요한데 이러한 정보를 가지고 있는 서버
- 도메인 이름과 IP주소를 저장하고 있는 데이터베이스 역할
- Root DNS 서버: TLD DNS 서버의 IP 주소를 관리하는 절대 존엄 서버
- Top-Level Domain(TLD) DNS 서버: 도메인 등록 기관이 관리하며 SLD DNS 서버의 IP주소를 저장
- Second-Level Domain(SLD) DNS 서버(=Authoritative DNS 서버): 실제 도메인과 IP 주소의 관계가 저장
리졸버(Resolver): 권한 없는 DNS 서버
- DNS 클라이언트의 요청을 네임서버로 전달하고 네임서버로 부터 IP주소 정보를 받아 클라이언트에게 제공
- 수많은 네임서버에 접근하며 사용자로부터 요청받은 도메인의 IP정보를 조회하는 기능 수행

DNS 동작 방식

※ Local DNS: Resolver Server / com DNS: TLD DNS 서버 / naver.com DNS: SLD DNS 서버

웹 브라우저에 www.naver.com을 입력하면 Local DNS에게 www.naver.com에 대한 DNS 조회 진행
Local DNS는 Root DNS에게 www.naver.com에 대한 질의
Root DNS는 Local DNS에게 com DNS의 IP 주소 전달
Local DNS는 전달받은 IP주소로 com DNS에게 www.naver.com에 대한 질의
com DNS는 Local DNS에게 naver.com DNS의 IP 주소를 전달
Local DNS는 또다시 전달받은 IP주소로 naver.com DNS에게 www.naver.com에 대한 질의
naver.com DNS는 Local DNS에게 www.naver.com에 해당하는 IP주소인 222.122.195.6 전달
Local DNS는 해당 IP주소를 캐싱한 뒤 웹 브라우저에게 전달

[네트워크] SOP(Same Origin Policy)와 CORS(Cross-Origin Resource Sharing), CORS 오류 해결 방법

J1Yun — Mon, 13 Feb 2023 16:14:53 +0900

SOP(Same Origin Policy)

같은 출처의 HTTP 요청만을 허락하는 정책
자원을 요청한 출처와 해당 요청에 응답하는 서버의 출처가 다를 경우 해당 자원을 사용하지 못하도록 제한 -> CORS 정책을 지켰을 시에만 예외적으로 허용
SOP 정책이 없을 시 노출된 소스코드를 통해 CSRF(Cross-Site Request Forgery)나 XSS(Cross-Site Scripting)와 같은 방법으로 공격자의 사용자 정보 탈취 위험이 있음

※ 출처(Origin)란?

위와 같은 URL 구조에서 Protocol + Host + Port에 해당하는 부분을 뜻한다. 브라우저는 Protocol, Host, Port가 모두 같다면 같은 출처, 셋 중 하나라도 다르다면 다른 출처라고 판단한다.

CORS(Cross-Origin Reource Sharing)

교차 출처(다른 출처) 리소스 공유
서버측에서 CORS 헤더를 통해서 다른 출처(웹)에서 자원에 접근할 수 있는 권한을 부여하도록 브라우저에게 알려주는 정책
출처가 다른 요청이더라도 CORS 헤더를 통해 CORS 정책을 잘 지켰다면 제대로 응답하도록 허용

CORS 동작 방식 (CORS 위반 여부 확인 방법)

웹 클라이언트 애플리케이션은 HTTP 프로토콜을 통해 다른 출처의 리소스 요청
브라우저는 요청 헤더의 Origin이라는 필드에 요청을 보내는 출처를 추가로 담아서 보냄
서버는 응답 헤더에 Access-Control-Allow-Origin(리소스에 접근이 허용된 출처)를 담아서 보냄
브라우저는 요청 시 보낸 Origin과 응답 헤더 속의 Access-Control-Allow-Origin을 비교
- Access-Control-Allow-Origin에 Origin이 포함된다면 클라이언트로 응답 전송
- 포함되지 않는다면 브라우저는 해당 응답을 버리고 CORS 정책 위반 메시지를 console에 출력

CORS 시나리오

CORS의 구체적인 동작 방식은 아래 세 가지의 시나리오에 따라 변경된다. 요청이 어떤 시나리오를 따르는 지에 따라 해결 방법도 달라진다.

1. Preflight Request

브라우저는 요청을 한번에 보내지 않고 예비 요청(prefight)과 본 요청으로 나누어 두 번 요청 전송
예비 요청에는 HTTP 메소드 중 OPTIONS 메소드 사용
브라우저는 예비 요청으로 통해 본 요청이 안전하게 전달될 수 있을 지 스스로 확인
- Javascript의 Fetch API 등을 활용해 브라우저에게 리소스를 받아오라는 명령을 보냄
- 이에 대해 브라우저는 서버에게 미리 예비 요청을 보냄
- 서버는 이에 대한 응답 헤더에 현재 자신이 어떤 것(메소드/헤더)를 허용하고 어떤 것을 금지하는지에 대한 정보를 담아 전송
- 브라우저는 자신이 보낸 예비 요청과 응답 헤더의 허용 정책을 비교한 후 해당 요청이 안전하다고 판단되면 같은 요청(본 요청)을 다시 보냄

2. Simple Request

예비 요청을 보내지 않고 서버에게 바로 본 요청을 전송한 후 서버가 이에대한 응답 헤더에 Access-Control-Allow-Origin을 보내면 이때 브라우저가 CORS 정책 위반 여부를 검사하는 방식
Prefight Request와 유사하지만 예비 요청 유무만 다름
예비 요청을 생략할 수 있는 경우는 정해져 있음
- 요청 메소드는 GET, HEAD, POST 중 하나여야 함
- Accept, Accept-Language, Content-Language, Content-Type, DPR, Downlink, Save-Data, Viewport-Width, Width를 제외한 헤더는 사용하면 안됨
- 만약 Content-Type를 사용한다면 application/x-www-form-urlencoded, multipart/form-data, text/plain만 허용

3. Credentialed Request

인증된 요청을 사용하는 방법
다른 출처 간 통신에서 좀 더 보안을 강화하기 위해 사용
credentials이라는 옵션을 통해 요청 헤더에 인증과 관련한 정보를 담을 수 있도록 함
- same-origin(기본값): 같은 출처 간 요청에만 인증 정보를 담을 수 있다
- include: 모든 요청에 인증 정보를 담을 수 있다
- omit: 모든 요청에 인증 정보를 담지 않는다
credentials 옵션에 same-origin이나 include와 같은 옵션을 사용하여 인증 정보가 포함되었다면 브라우저는 다른 출처의 리소스 요청 시 Access-Control-Allow-Origin 확인 뿐만 아니라 추가적인 검사 조건을 추가
- 서버 응답 헤더에는 Access-Control-Allow-Origin의 값으로 와일드카드(*)를 사용할 수 없으며 명시적인 URL을 작성해야한다
- 서버 응답헤더에 Access-Control-Allow-Credentials라는 헤더와 그 값아 true로 설정되어 있어야한다

CORS 해결 방법

서버에서 Access-Control-Allow-Origin 세팅하기
- Access-Control-Allow-Origin: \*는 모든 출처에서 오는 요청을 허용한다는 뜻으로 당장은 편할지라도 보안상 좋지 않음
- Access-Control-Allow-Origin: https://J1Yun.github.com과 같이 허용 출처를 명확히 적어주는 것이 좋음
프론트에서 Webpack Dev Server로 리버스 프록싱하기
- 웹팩과 webpack-dev-server에서 제공하는 프록시 기능을 활용하여 CORS 정책 우회

[네트워크] 토큰 기반 인증(+JWT), 서버(세션)기반 인증

J1Yun — Fri, 10 Feb 2023 13:49:51 +0900

토큰(Token) 기반 인증

클라이언트가 서버에 접속 시 서버에서 해당 클라이언트에게 인증의 의미로 '토큰'을 부여 -> 인증(Authentication)
클라이언트는 또 다시 서버에 요청을 보낼 때 발급받은 토큰을 요청 헤더에 심어 전송
서버는 헤더 내 토큰을 열어 자신이 제공한 토큰이 맞는지 확인하여 인증 과정 처리 -> 인가(Authorization)

용어 정리
- 인증(Authentication): 자신이 누구인지 증명하고 검증하는 과정 (로그인)
- 인가(Authorization): 인증 작업 이후에 인증된 사용자에 대한 자원 접근 확인 및 허가 절차 (권한 확인)

장점
- 토큰 정보를 클라이언트 측에서 저장하기 때문에 stateless(무상태)하며, 서버 확장에 용이 (서버 부담 X)
- 토큰은 한 번 발급되면 유효기간이 만료될 때까지 계속 사용 가능
- 토큰에는 기본 정보, 전달할 정보, 토큰이 검증되었다는 서명 등 필요한 모든 정보를 자체적으로 지니고 있음
- header와 payload를 가지고 signature을 생성하므로 데이터 위변조 방지
단점
- 쿠키/세션과 다르게 토큰 자체의 데이터 길이가 길어, 인증 요청이 많아질수록 네트워크 부하 발생
- Payload 자체는 암호화되지 않기 때문에 유저의 중요한 정보는 담을 수 있음
- 토큰을 탈취 당할 경우 대처가 어려움

토큰 인증 과정

사용자가 아이디와 비밀번호로 로그인
서버는 클라이언트(사용자)에게 토큰을 발급
클라이언트는 서버 측에서 전달받은 토큰을 쿠키나 스토리지에 저장
서버에 요청 시마다 해당 토큰을 HTTP 요청 헤더에 포함시켜 전달
서버는 전달받은 토큰을 검증하고, 요청에 응답

JWT (JSON Web Token)

인증에 필요한 정보들을 암호화시킨 JSON 토큰을 의미
JWT 토큰은 점(.)으로 구분된 Header, Payload, Signature로 구성
1. Header(헤더): 보통 토큰의 타입이나 서명 생성에 어떤 알고리즘이 사용되었는지 저장
2. Payload(내용): 사용자 권한 정보와 실제로 사용될 정보(JWT를 통해 알 수 있는 데이터)를 저장
3. Signature(서명): 'Header+Payload'와 서버가 가지고 있는 유일한 Key값을 헤더에서 정의한 알고리즘으로 암호화한 값 (비대칭 암호화) -> Authorization(인가) 작업으로 토큰의 유효성 검증 시 사용

서버(세션) 기반 인증

클라이언트가 서버에 접속 시 서버는 클라이언트(사용자)의 정보를 서버의 세션 저장소에 저장 후 세션ID 발급 -> 인증(Authentication)
클라이언트는 또 다시 서버에 요청을 보낼 때 발급받은 세션ID을 요청 헤더와 함께 전송
서버는 헤더 내 세션ID를 통해 세션 저장소에 접근한 후 세션ID에 해당하는 세션 정보가 존재하는지 확인하여 인증 과정 처리 -> 인가(Authorization)

장점
- 모든 인증 정보를 서버에서 관리하기 때문에 보안성이 높음
단점
- 서버 측 (세션 저장소)에서 정보가 저장되므로 요청이 많아지면 서버 부하가 심해짐
- 공격자가 세션ID를 탈취하여 정상 클라이언트인 척 위장 가능
- 서버 확장 시 세션 분산 작업이 어려움

※ 쿠기와 세션에 대한 내용은 아래 포스팅 참고바랍니다.
https://zu-techlog.tistory.com/67

[네트워크] 쿠키(Cookie)와 세션(Session) 특징, 차이

HTTP 프로토콜은 비연결 지향으로 서버가 클라이언트의 요청에 따라 응답을 보내주면 바로 연결을 끊는다. 또, 연결을 끊는 순간 클라이언트와 서버의 통신이 종료되며 상태 정보를 유지하지 않

zu-techlog.tistory.com

[네트워크] SSL/TLS 핸드쉐이크 - TLS 1.3

J1Yun — Thu, 9 Feb 2023 16:37:51 +0900

SSL과 TLS

TLS(Transport Layer Security)는 SSL(Secure Socket Layer)의 상위 버전 표현이라고 할 수 있다. SSL은 SSL 1.0부터 시작해 SSL 2.0, SSL 3.0, TLS 1.0, TLS 1.3까지 버전 업데이트가 되면서 SSL의 명칭이 TLS로 변경된 것이다. 이 포스트에서는 TLS 3.0을 기반으로 설명하며 명칭은 TLS로 통일한다.

TLS는 전송계층에서 보안을 제공하는 프로토콜이다. HTTPS 통신 시 주로 사용되며, 클라이언트와 서버가 통신할 때 TLS를 통해 제3자가 메시지를 도청하거나 위조, 변조하지 못하도록 한다.

TLS는 다음과 같은 기능 및 역할을 가진다.

암호화: 제3자와 주고받는 데이터를 숨김
인증: 통신의 대상이 신뢰할 수 있는 요청된 당사자임을 보장 (신원 확인)
무결성: 데이터가 위조되거나 변조되지 않았는지 확인

본격적으로 TLS 핸드쉐이크에 대해 살펴보기 이전에 대칭키와 비대칭키(공개키) 암호화, 인증서와 관련한 개념을 이해해야 한다.
해당 게시물은 아래에 링크로 들어가 확인하자.

https://zu-techlog.tistory.com/114

[보안] 대칭키와 비대칭키(공개키) 암호화 + 디지털 인증서

대칭키 암호화 암복호화에 사용되는 키가 동일한 방식 장점: 암호화 속도 빠름, 대용량 데이터 암호화에 적합, 기밀성 제공 단점: 키 배송 문제 발생 - 키 교환 시 탈취 위험, 사람이 증가할수록

zu-techlog.tistory.com

TLS 핸드쉐이크

클라이언트와 서버가 데이터를 주고 받기 전 서버의 무결성과 신원을 확인하고, 대칭키를 전달하기까지의 과정
사용자가 TLS를 사용하는 웹사이트를 접속하면 클라이언트와 웹 서버간에 TLS Handshake가 시작
- 사용할 TLS 버전 지정
- 사용할 암호 제품군(사이퍼슈트) 결정
- 서버는 공개키로 TLS 인증서 발급
- 클라이언트는 서버의 TLS 인증서를 사용하여 서버의 신원 인증
- 메시지 암호화를 위한 세션 키 생성/전달

TLS Handshake 진행과정 - TLS 1.3

Client Hello
- 클라이언트는 서버와의 연결을 위해 TLS버전, 사이퍼슈트(암호 제품군 알고리즘 집합), 클라이언트 랜덤값, 임시 DH 매개변수(대칭키 생성 알고리즘)를 담은 패킷 전송
Server Hello, EncryptedExtensions, Certificate, CertificateVerify
- 서버는 클라이언트가 보낸 Client Hello 패킷에서 TLS 버전 식별과 사이퍼슈트 선택
- 자신의 공개키가 포함된 TLS인증서, 서버 랜덤값, 임시 DH 매개변수를 담아 전송
- 클라이언트와 서버가 서로 교환한 DH 매개변수를 사용하여 임시 암호 키인 세션키(대칭키) 생성
Finished
- 클라이언트와 서버는 세션키를 기반으로 암호화된 통신 시작

[보안] 대칭키와 비대칭키(공개키) 암호화 + 디지털 인증서

J1Yun — Wed, 8 Feb 2023 16:20:47 +0900

대칭키 암호화

암복호화에 사용되는 키가 동일한 방식
장점: 암호화 속도 빠름, 대용량 데이터 암호화에 적합, 기밀성 제공
단점: 키 배송 문제 발생 - 키 교환 시 탈취 위험, 사람이 증가할수록 키 관리 어려움, 낮은 확장성, 무결성/인증/부인방지 제공 X
Session Key(세션키), Secret Key(비밀키), Shared Key(공유키), 단용키라고도 함
대표적 알고리즘 : 공인인증서의 암호화방식으로 유명한 SEED, DES, 3DES, AES, ARIA, 최근 주목받고 있는 암호인 ChaCha20

비대칭키 암호화

암복호화에 사용되는 키가 서로 다른 방식 (공개키와 개인키)
장점: 키 분배 필요 X, 기밀성/인증/부인방지 기능 제공
단점: 암호화 속도 느림, 무결성 제공 X
암호 모드: 공개키로 암호화 -> 개인키로 복호화
- 소량의 메시지 암호화 목적
- 주로 키 교환의 용도로 사용
인증 모드: 개인키로 암호화 -> 공개키로 복호화
- 메시지를 인증 및 부인 방지하는 목적
대표적 알고리즘: RSA, Diffie Hellman, ECC 등

대칭키 VS 비대칭키(공개키) 정리

	대칭키	비대칭키
키 관계	암호화 키 = 복호화키	암호화 키 ≠ 복호화 키
암호화 키	비밀키	공개키
복호화 키	비밀키	개인키
비밀키 전송	필요	불필요
키 길이	짧다	길다
인증	곤란	용이
암복화 속도	빠르다	느리다
경제성	높다	낮다
전자서명	복잡	간단
주 용도	고용량 데이터 암호화(기밀성)	키 교환 및 분배, 인증, 부인방지
장점	- 암복호화 키 길이가 짧음 - 구현이 용이하고, 암복호화가 빠름 - 암호화 강도 전환이 용이 - 암호화 기능이 우수 - 각종 암호 시스템의 기본으로 활용	- 사용자가 증가하더라도 관리해야 할 키의 개수가 상대적으로 적음 - Key 전달이나 교환에 적합 - 인증과 전자 서명에 이용 - 대칭키 보다 확장성이 좋음 - 여러가지 분야에서 응용이 가능 - 키 변화의 빈도가 적음
단점	- 키 교환 원리가 명시되지 않아 키 분배가 어려움 - 관리할 암복호화 키가 많음 - 확장성이 낮음 - 전자서명(디지털서명)이 불가능 - 부인방지 기능이 없음	- 키 길이가 김 - 복잡한 수학적 연산을 이용함으로 암복호화 속도가 느림 - 중간에 인증과정이 없으므로 중간자 공격에 취약 (전자서명,인증서 등으로 해결)
예	[Feistel] : SEED, DES [SPN] : ARIA, AES, IDEA 메시지 인증코드(MAC)	Diff-Hellman, RSA, ECC, DAS [Block chain] [TPM]

※ 참고

기밀성(Confidentiality): 인가되지 않은 자는 정보를 확인하지 못하도록 하며 정보가 유출되더라도 평문으로 해독할 수 없고 변조나 위조되지 못하도록 기밀을 유지
무결성(Integrity): 인가되지 않은 자로부터 위조나 변조가 발생하지 않았는지 확인
인증(Authentication): 수신받은 메시지가 송신자 본인이라는 것을 확인하고 증명
부인 방지(Non-Repudiation): 메시지를 보낸 사람이 보낸 사실을 부인하거나, 받는 사람이 받은 사실을 부인하지 않도록 증명

무결성은 대칭키와 비대칭키(공개키) 알고리즘 모두에서 성립하지 않으며, 비대칭키 암호화 방식에서는 전자 서명(인증서)를 추가함으로써 무결성 보장 가능 (대칭키는 전자서명 어려움)

디지털 인증서

보안이 필요한 통신에서 상대방이 통신하고자 하는 대상이 맞음을 확인해 주는 역할
인증서 소유주의 신분을 보증하고, 인증서에 포함된 공개키(public key)가 그 소유주 것이 맞음을 증명
서로가 신뢰할 수 있는 제삼자 인증 기관인 CA(Certificate Authority)와 비대칭 암호화 필요
CA가 인증서를 요청한 사람이나 기관에 대한 신분과 보유한 공개키를 또 다른 관계자에게 보증을 해주는 방식

디지털 인증서 발급 과정

User B는 CA에게 자신이 B임을 증명하기 위해 자신의 공개키를 보내고, CA에게 B의 공개키가 맞음을 인증하는 인증서 발급받음
User A는 User B에게 B의 공개키가 포함된 인증서를 받음
User A는 신뢰할 수 있는 인증기관 CA에게 진짜로 CA에서 발급된 인증서가 맞는지 확인
User A는 인증서에 포함된 공개키로 메시지를 암호화해서 User B에게 전달
User B는 본인의 개인키로 해당 메시지를 복호화

[네트워크] HTTP/1.X, HTTP2, HTTP3 버전 차이, 특징

J1Yun — Tue, 7 Feb 2023 23:02:24 +0900

※ HTTP 개요: https://zu-techlog.tistory.com/60

[네트워크] HTTP와 HTTPS 프로토콜

HTTP (Hyper Text Transfer Protocol) 웹 상에서 클라이언트와 서버 간에 요청(request)과 응답(response)으로 정보를 주고 받을 수 있는 프로토콜 TCP와 UDP 사용, 80번 포트 사용 비연결(Connectionless) 클라이언트가

zu-techlog.tistory.com

HTTP 버전 - HTTP/1.X, HTTP2, HTTP3

HTTP/1.0

한 연결당 하나의 요청을 처리하도록 설계
서버에게 요청 시 매번 연결과 해제의 과정을 반복해야 했기에 RTT가 오래걸린다는 문제
- RTT: 패킷이 목적지에 도달하고 나서 다시 출발지로 돌아오기까지 걸리는 시간 (패킷 왕복 시간)

HTTP/1.1

Persistent Connection 추가
- HTTP/1.0을 보완하여 매번 TCP 연결을 하는 것이 아니라 한 번 TCP 초기화를 한 이후에 keep-alive라는 옵션으로 일정 시간동안 연결 상태를 유지

Persistent Connection 도식화

Pipelining 추가
- TCP의 특성상 요청 후 응답을 기다려야하는 문제를 보완
- 클라이언트는 앞 요청의 응답을 기다리지 않고 순차적으로 요청 전송, 서버는 요청이 들어온 순서대로 응답

Pipelining 도식화

HOL Blocking (Head Of Line Blocking) 문제
- 앞의 요청(패킷)에 대한 응답이 늦어지면 뒤의 모든 요청들은 모두 blocking되어 응답이 지연됨
연속된 요청 간에 헤더의 많은 중복이 생긴다는 문제

HTTP/2.0

HTTP/1.x의 시간 지연 문제를 해결
Multiplexed streams (멀티플렉싱)
- HTTP/1.1의 Pipelining은 한번의 연결에서 여러 요청을 보낼 수는 있었지만 동시에 여러 요청을 처리하진 못했음
- 하나의 커넥션 내에 여러개의 스트림(stream, 양방향 데이터 흐름)을 사용하여 송수신
- 메시지가 이진화된 텍스트인 프레임(frame)으로 나뉘어 요청마다 구분되는 스트림(stream)을 통해 전달
- 프레임(frame)이 각 요청의 스트림(stream)을 통해 전달되며, 하나의 커넥션 안에 여러개의 스트림(stream)을 가질 수 있게되어 다중화(multiplexing)가 가능해짐
- 스트림(stream)을 통해 각 요청의 응답 순서가 의미가 없어져 HTTP/1.x의 HOL Blocking 문제 해결

Multiplexing 도식화

Header Compression (헤더 압축)
- 요청과 응답 헤더의 메타데이터를 압축해서 기존의 연속된 요청에서의 중복 헤더로 인한 오버헤드 문제를 해결
- 이전에 표시된 헤더를 제외한 필드를 허프만 코딩을 활용해서 압축
Server Push (서버 푸시)
- 클라이언트가 서버에 요청하지 않아도 클라이언트에게 필요한 리소스를 서버가 추가적으로 push해주는 기능
각 요청마다 stream으로 구분해 병렬적으로 처리함에도 불구하고 TCP 고유의 HOL Blocking이 여전히 존재하는 문제
- 서로 다른 stream이 전송되고 있을 때, 하나의 Stream에서 유실이 발생되거나 문제가 생기면 결국 다른 Stream도 문제가 해결될 때 까지 지연되는 현상이 발생

HTTP/3.0

TCP 위에서 돌아가는 HTTP/2.0와는 달리 QUIC라는 계층 위에서 돌아가며 TCP기반이 아닌 UDP 기반
HTTP/2.0의 장점(멀티플렉싱 등)의 기능을 가지고 있음
초기 연결 설정 시 지연 시간 감소라는 대표적 특징 (UTP기반)
- 초기 연결(통신 시작) 시 3-way handshaking 과정을 거치지 않아 1-RTT만 소요
- 클라이언트와 서버거 한번 신호를 주고받은 후 바로 통신 시작
TCP의 stream은 하나의 chain으로 연결되는 것과 달리 각 stream당 독립된 stream chain을 구성하여 TCP의 HOL Blocking을 해결

코딩테스트 주요 연산자/메소드 시간 복잡도 정리 - 파이썬(Python)

J1Yun — Mon, 6 Feb 2023 22:45:37 +0900

시간 복잡도 in 코딩테스트

	N이 1000일 때의 연산 횟수
O(N)	1000
O(NlogN)	10000
O(N^2)	1000000
O(N^3)	1000000000

시간 제한이 1초인 문제일 때

N의 범위가 500인 경우: 시간복잡도가 O(N^3)인 알고리즘을 설계하면 문제를 풀 수 있다.
N의 범위가 2000인 경우: 시간복잡도가 O(N^2)인 알고리즘을 설계하면 문제를 풀 수 있다.
N의 범위가 100000(10만)인 경우: 시간복잡도가 O(NlogN)인 알고리즘을 설계하면 문제를 풀 수 있다.
N의 범위가 10000000(1000만)인 경우: 시간복잡도가 O(N)인 알고리즘을 설계하면 문제를 풀 수 있다.

리스트(List)

	Operation	Example	Big-O	Notes
1	Index	l[i]	O(1)	인덱스로 값 찾기
2	Store	l[i] = val	O(1)	인덱스로 데이터 저장
3	Length	len(l)	O(1)	리스트 길이
4	Append	l.append(val)	O(1)	리스트 뒤에 데이터 추가
5	Pop	l.pop()	O(1)	리스트 마지막 데이터 pop
6	Clear	l.clear()	O(1)	빈 리스트로 만듦
7	Slice	l[a:b]	O(b-a)	슬라이싱
8	Extend	l.extend(l2)	O(len(l2))	리스트 확장
9	Construction	list(…)	O(len(…))	리스트 생성
10	check ==, !=	l1 == l2	O(N)	전체 리스트가 동일한지 확인
11	Insert	l[a:b] = …	O(N)	데이터 삽입
12	Delete	del l[i]	O(N)	데이터 삭제
13	Containment	x in/not in l	O(N)	x값 포함 여부 확인
14	Copy	l.copy()	O(N)	리스트 복제
15	Remove	l.remove(val)	O(N)	리스트에서 val값 제거
16	Pop 2	l.pop(i)	O(N)	i번째 인덱스 값 pop
17	Extreme value	min(l) / max(l)	O(N)	전체 데이터를 확인해야함
18	Reverse	l.reverse()	O(N)	뒤집기
19	Iteration	for v in l:	O(N)	전체 데이터 순회
20	Sort	l.sort()	O(N log N)	파이썬 기본 정렬
21	Multiply	k*l	O(k N)	리스트 곱만큼 리스트 개수 증가

집합(Set)

	Operation	Example	Big-O	Notes
1	Add	s.add(val)	O(1)	집합 요소 추가
2	Containment	x in/not in s	O(1)	포함 여부 확인
3	Remove	s.remove(val)	O(1)	요소 제거(없으면 에러)
4	Discard	s.discard(val)	O(1)	요소 제거(없어도 에러x)
5	Pop	s.pop()	O(1)	랜덤하게 하나 pop
6	Clear	s.clear()	O(1)	빈 집합으로 만듦
7	Construction	set(…)	O(len(…))	길이만큼
8	check ==, !=	s != t	O(len(s))	전체 요소 동일 여부 확인
9	<= or <	s <= t	O(len(s))	부분집합 여부
10	Union	s, t	O(len(s)+len(t))	합집합
11	Intersection	s & t	O(len(s)+len(t))	교집합
12	Difference	s - t	O(len(s)+len(t))	차집합
13	Symmetric Diff	s ^ t	O(len(s)+len(t))	여집합
14	Iteration	for v in s:	O(N)	전체 요소 순회
15	Copy	s.copy()	O(N)	복제

딕셔너리(Dictionary)

	Operation	Example	Big-O	Notes
1	Store	d[k] = v	O(1)	집합 요소 추가
2	Length	len(d)	O(1)	딕셔너리 길이
3	Delete	del d[k]	O(1)	해당 key 제거
4	get/setdefault	d.get(k)	O(1)	key에 따른 value 확인
5	Pop	d.pop(k)	O(1)	pop
6	Pop item	d.popitem()	O(1)	랜덤 데이터(key:value) pop
7	Clear	d.clear()	O(1)	빈 딕셔너리로 만듦
8	View	d.keys()	O(1)	key 전체 확인
9	Values	d.values()	O(1)	value 전체 확인
10	Construction	dict(…)	O(len(…))	(key, value) tuple 갯수만큼
11	Iteration	for k in d:	O(N)	딕셔너리 전체 순회

덱크(collections.deque)

	Operation	Example	Big-O	Notes
1	Copy	dq.copy()	O(N)	복제
2	Append	dq.append(val)	O(1)	요소 추가 (큐의 오른쪽)
3	Append Left	dq.appendleft(val)	O(1)	요소 추가 (큐의 왼쪽)
4	Pop	dq.pop()	O(1)	마지막 데이터 pop
5	Pop Left	dq.popleft()	O(1)	첫번째 데이터 pop
6	Extend	dq.extend(dq2)	O(k)	dq + dq2 확장
7	Extend Left	dq.extendleft(dq2)	O(len(dq2))	dq2 + dq 확장
8	Rotate	dq.rotate(k)	O(k)	양수k: 오른쪽으로 n만큼 회전, 음수k: 왼쪽으로 n만큼 회전
9	Remove	dq.remove(val)	O(N)	요소 제거

우선순위큐(heapq)

	Operation	Example	Big-O	Notes
1	Heappush	heappush(h, 1)	O(logN)	힙에 원소 추가
2	Heappop	heappop(h)	O(logN)	가장 작은 원소 pop
3	Heapify	heapify(h)	O(N)	리스트를 힙으로 변환

이진탐색(bisect)

	Operation	Example	Big-O	Notes
1	Bisect Left	bisect_left(data, x)	O(logN)	data에 x가 들어갈 수 있는 가장 작은 인덱스
2	Bisect Right	bisect_right(data, x)	O(logN)	data에 x가 들어갈 수 있는 가장 큰 인덱스

[네트워크] TCP/IP 흐름제어와 혼잡제어

J1Yun — Mon, 6 Feb 2023 15:39:12 +0900

흐름제어

송신측과 수신측의 데이터 처리 속도 차이를 해결하기 위한 기법
송신측의 전송량이 수신측의 처리량보다 클 경우 수신측의 큐가 용량을 넘어 전송된 패킷의 손실이 일어날 수 있기 때문에 송신측의 패킷 전송량을 제어함
수신측이 송신측에게 현재 자신의 상태를 피드백하는 형태

1. Stop and Wait

매번 전송한 패킷에 대해 확인 응답(ACK)을 받아야만 그 다음 패킷을 전송
구조 상 비효율적

2. Sliding Window

수신측에서 설정한 윈도우 크기만큼 송신측에서 확인 응답 없이 패킷을 전송할 수 있게하여 데이터 흐름을 동적으로 조절
송신측은 먼저 윈도우에 포함되는 모든 패킷을 전송하고, 수신측으로부터 확인 응답(ACK)가 오면 윈도우를 옆으로 옮겨가며 다음 패킷들을 전송

동작 방식

송신측에서 [0, 1, 2, 3, 4, 5, 6]의 프레임을 전송할 수 있는 윈도우를 가지고 있음
먼저 0과 1을 전송했다고 가정하면 송신측의 슬라이딩 윈도우 구조는 [2, 3, 4, 5, 6]과 같이 축소
이때, 수신측으로부터 정상 수신을 알리는 ACK를 받았다면 송신측의 슬라이딩 윈도우는 해당 ACK의 프레임 수([0, 1])만큼 오른쪽으로 윈도우의 경계를 확장
만약 송신측이 일정 시간동안 수신측으로부터 ACK를 받지 못한다면 패킷 재전송
송신측은 ACK와 함께 전달되는 수신측의 남은 버퍼 크기(윈도우 크기)를 바탕으로 전송량 제어

혼잡 제어

송신측의 데이터 전달과 네트워크의 데이터 처리 속도 차이를 해결하기 위한 기법
네트워크의 혼잡을 피하기 위해 송신측에서 보내는 데이터의 전송속도를 제어함
- 송신측의 데이터는 지역망이나 인터넷으로 연결된 대형 네트워크를 통해 전달되는데, 이때 한 라우터에 데이터가 몰려 모든 데이터를 처리할 수 없는 경우, 호스트들은 데이터를 재전송하게 되고 결국 혼잡만 가중시켜 오버플로우나 데이터 손실을 발생시킴
- 네트워크 혼잡이란, 네트워크 내에 링크 대역폭 이상의 데이터가 전송되거나 네트워크 내의 패킷 수가 과도하게 증가하는 현상

1. AIMD (Additive Increase/ Multicative Decrease, 합 증가/ 곱 감소)

처음에는 패킷을 하나씩 전송 (Window Size = 1)
네트워크가 정상(ACK 수신 O)일 경우 Window Size + 1
네트워크가 혼잡(ACK 수신 X)한 경우 Window Size / 2
공편한 방식으로, 여러 호스트가 한 네트워크를 공유하고 있다면 나중에 진입한 쪽이 불리하겠지만, 시간이 흐르면서 평형 상태로 수렴하게 되는 특징
문제점은 초기에 네트워크의 높은 대역폭을 사용하지 못해 오랜 시간이 걸리고, 네트워크 혼잡 상황을 미리 감지하지 못하기 때문에 네트워크가 혼잡해지고 나서야 대역폭을 줄일 수 있는 방식임

2. Slow Start (느린 시작)

처음에는 패킷을 하나씩 전송 (Window Size = 1)
네트워크가 정상(ACK 수신 O)일 경우 각각의 패킷 마다 Window Size + 1, 한 주기가 지나면 Window Size * 2가 됨 (지수적 증가)
네트워크가 혼잡(ACK 수신 X)한 경우 Window Size를 1로 줄임
AIMD 방식에 비해 처음 전송 속도를 올리는데 오랜 시간이 걸리지 않음

3. Congestion Avoidance (혼잡 회피)

처음에는 네트워크 수용량을 예상하기 어렵지만 한번 혼잡이 발생하고 나면 그 이후에는 네트워크 수용량을 어느정도 예측할 수 있음
혼잡 현상이 발생하던 window size의 절반(임계값)까지는 이전처럼 지수 함수 꼴로 윈도우 크기를 증가시키고, 이후부터는 완만하게 1씩 증가
전송량이 임계값을 넘으면 Congestion Avoidance 단계로 진입하여 AIMD 방식으로 Window Size 조정

4. Fast Retransmit (빠른 재전송)

수신측에서 먼저 도착해야할 패킷이 도착하지 않고 다음 패킷이 도착한 경우에도 ACK 패킷을 전송함
단, 순서대로 잘 도착한 마지막 패킷의 다음 패킷 순번이 ACK 패킷과 함게 전송되므로 송신측은 손실된 패킷에 대해 순번이 중복된 ACK 패킷을 받게됨. 이를 인지하면 송신측은 해당 순번의 패킷을 재전송
중복된 순번의 패킷을 3개 받으면 재전송, 혼잡을 감지하고 window size 감소

5. Fast Recovery (빠른 회복)

혼잡한 상태가 되면 window size를 1로 줄이지 않고 반으로 줄이고 선형증가시키는 방법
빠른 회복 정책까지 적용하면 혼잡 상황을 한번 겪고 나서부터는 순수한 AIMD 방식으로 동작

[네트워크] HTTP 상태/응답 코드 정리

J1Yun — Thu, 2 Feb 2023 21:26:08 +0900

HTTP Status Code

HTTP 상태 코드를 통한 요청 응답

HTTP 상태 코드는 클라이언트가 보낸 요청(request)이 성공적으로 처리되었는지 그 상태를 응답(response)을 통해 알려주기 위해 활용된다. 이러한 응답은 5개의 그룹으로 나뉘어지며, 상태 코드를 표시하는 3자리 수 중 가장 앞자리 수가 바로 응답의 종류를 의미한다.

상태	그룹	역할
1XX	Informational Response 조건부 응답	현재 요청까지 처리했다는 전송 프로토콜 수준의 임시적 응답
2XX	Success 성공	클라이언트의 요청이 성공적으로 처리
3XX	Redirection 경로 재지정	요청 처리를 완료하기 위해 클라이언트의 추가적인 조취 필요
4XX	Client Error 클라이언트 오류	요청 내용이 잘못되는 등 클라이언트로 인한 오류 발생
5XX	Server Error 서버 오류	서버의 요청 처리 실패

1XX Informational Response (조건부 응답)

100 - Continue (계속)

지금까지의 상태가 괜찮으며 클라이언트는 계속해서 요청을 하거나 이미 요청을 완료한 경우에는 무시해도 된다

101 - Switching Protocol (프로토콜 전환)

클라이언트가 서버에 프로토콜 전환을 요청한 것으로 서버는 승인 중인 상태이다

102 - Processing (처리, WebDAV)

서버가 요청을 수신하였으며 이를 처리하고 있지만 아직 제대로 된 응답은 알려줄 수 없다

103 - Early Hints (사전 도움)

주로 Link 헤더와 함께 사용되어 서버가 응답을 준비하는 동안 사용자 에이전트가(user agent) 사전 로딩(preloading)을 시작할 수 있도록 한다.

2XX Success (성공)

200 - OK (성공)

클라이언트가 요청한 작업이 성공적으로 처리된 상태이다

201 - Created (작성됨)

생성 작업 요청이 성공적으로 처리되어 새로운 리소스가 생긴 상태로 POST를 통한 요청이 대표적이다

202 - Accepted (허용됨)

서버가 요청을 접수했지만 아직 처리하지 않았다 (다른 프로세스에서 처리 or 다른 서버가 요청 처리 or 배치 프로세스)

203 - Non-Authoritative Information (신뢰할 수 없는 정보)

돌려받은 메타 정보 세트가 Origin 서버의 것과 일치하지 않지만 로컬이나 서드 파티 복사본에서 모아졌다

204 - No Content (내용 없음)

요청에 대해서 보내줄 수 있는 내용이 없다 (헤더에 의미가 있을 수 있음)

3XX Redirection(경로 재지정)

301 Moved Permanently (영구적 이동)

요청한 리소스의 URI가 변경되었다 ( 응답 헤더 Location에 새로운 URI 전달)

302 - Found (일시적 이동)

현재 서버가 다른 위치(URI)의 페이지로 요청에 응답하고 있지만 클라이언트는 향후 요청 시 원래 위치(URI)를 계속 사용해야 한다

303 - See Other (기타 위치보기)

요청한 리소스가 다른 URI에 있어 리다이렉트 장소를 GET 메소드를 통해 얻어야 한다.

304 - Not Modified (수정 없음)

이전의 동일한 요청과 비교하여 수정되지 않았음을 의미하여 캐시를 목적으로 사용된다

307 - Temporary Redirect (임시 리다이렉션)

302와 동일하나 HTTP Method 를 변경하면 안된다

4XX Client Error (클라이언트 오류)

400 - Bad Request (잘못된 요청)

클라이언트가 보낸 요청의 문법이 잘못되어 이해할 수 없다

401 - Unauthorized(권한 없음)

요청한 리소스에 대한 엑세스 권한이 없다 (ex. 로그인하지 않고 정보 조회)

403 - Forbidden(접근 금지)

요청한 리소스에 대한 엑세스가 금지되었다 (ex. 로그인은 되었지만 결제를 하지 않고 서비스 접근)

401과 비슷하지만 403에는 authorization 헤더가 있어 클라이언트가 누구인지 알고 있다

404 - Not Found(찾을 수 없음)

요청할 리소스를 서버에서 찾을 수 없다

405 - Method Not Allowed(허용되지 않은 메서드)

요청에 지정된 메서드가 URI로 표시된 리소스에 허용되지 않는다 (ex. 읽기 전용 리소스에 PUT요청)

408 - Request Timeout(요청 시간 초과)

서버의 요청 대기 시간을 초과했다 (연결을 끊고 싶은 것)

5XX Server Error (서버 오류)

500 - Internal Server Error (내부 서버 오류)

서버에서 요청을 처리하는 중 에러가 발생했다

501 - Not Implemented (구현되지 않음)

서버에 요청을 수행할 수 있는 기능이 없다 (서버가 지원하지 않는 HTTP Method를 사용한 경우)

502 - Bad Gateway (불량 게이트웨이)

서버가 게이트웨이나 프록시 역할을 하고 있거나 또는 업스트림 서버에서 잘못된 응답을 받았다

503 - Service Unavailable (서비스를 사용할 수 없음)

서버가 오버로드되었거나 유지관리를 위해 다운되었기 때문에 현재 서버를 사용할 수 없다

504 - Gateway Timeout (게이트웨이 시간초과)

서버가 게이트웨이나 프록시 역할을 하고 있거나 또는 업스트림 서버에서 제때 요청을 받지 못했다

[네트워크] REST, REST API, RESTful 알아보기

J1Yun — Wed, 1 Feb 2023 15:52:16 +0900

REST

자원을 이름으로 구분하여 해당 자원의 상태 및 정보를 주고 받는 모든 것을 의미
웹의 기존 기술과 HTTP 프로토콜을 활용하기 때문에 웹의 장점을 최대한 활용할 수 있는 아키텍처 스타일
네트워크 상에서 Client와 Server 사이의 통신 방식
HTTP URI를 통해 자원을 명시하고, HTTP Method(GET, POST, PUT, DELETE)를 통해 해당 자원에 대한 CRUD를 적용하는 것

REST 구성 요소

자원(Resource)
- URI로 표시
- 모든 자원에 대한 고유 ID(URI)가 존재하고, 이 자원은 Server에 존재
- Client는 URI를 이용해서 자원을 지정하고 해당 자원의 상태(정보)에 대한 조작을 Server에 요청
행위(Verb)
- HTTP 프로토콜의 Method 사용
표현(Representation of Resource)
- Client가 자원의 상태(정보)에 대한 조작을 요청하면 Server는 이에 적절한 응답(Representation)을 보냄
- REST에서 하나의 자원은 JSON, XML, TEXT, RSS 등 여러 형태의 Representation으로 나타내어 질 수 있음
- JSON이나 XML를 통해 데이터를 주고 받는 것이 일반적

REST 특징

Server-Client(서버-클라이언트 구조)
- 자원을 가지고 있는 쪽은 Server, 자원을 요청하는 쪽은 Client
- 서버와 클라이언트 서로 간의 의존성 낮음
Stateless(무상태)
- HTTP 프로토콜의 Stateless 속성을 그대로 가지고 있음
- Client의 context 정보(쿠키, 세션 등)를 Server에 저장히지 않아 구현 단순
- Server는 각각의 요청을 별개로 인식하고 각각 처리 -> 처리 방식의 일관성 부여, 서비스 자유도 향상
Cacheable(캐시 처리 가능)
- HTTP 프로토콜의 캐싱 기능 활용 가능
- 대용량 요청의 효율적 처리 가능
- 캐시 사용을 통해 서버의 트랜잭션이 발생하지 않기 때문에 전체 응답시간, 성능, 서버의 자원 이용률 향상
Layered System(계층화)
- Client는 REST API Server만을 호출
- REST Server는 다중 계층으로 구성 가능
  - 순수 비즈니스 로직을 처리하는 API 서버 앞에 보안, 로드밸런싱, 암호화, 사용자 인증 등의 서버 계층을 추가하여 구조상의 유연성 제공 가능
- 프록시, 게이트웨이와 같은 네트워크 기반의 중간 매체 활용 가능
Code-On-Demand(optional)
- Server로부터 제공받은 리소스 처리에 대한 코드를 Client에서 실행
- 반드시 충족할 필요 X
Uniform Interface(인터페이스 일관성)
- URI로 지정한 자원에 대한 조작을 통일되고 한정적인 인터페이스로 수행
- HTTP 표준 프로토콜에 따르는 모든 플랫폼에서 사용 가능

REST 장단점

장점
- HTTP 프로토콜의 인프라를 그대로 사용하므로 REST API 사용을 위한 별도의 인프라를 구출할 필요 X
- HTTP 표준 프로토콜에 따르는 모든 플랫폼에서 사용 가능
- URI 자원 명시를 통해 REST API 메시지가 의도하는 바를 명확하게 나타내므로 의도하는 바를 쉽게 파악 가능
- 서버와 클라이언트의 역할이 명확히 분리
- 각종 브라우저, 모바일 디바이스 등 다양한 클라이언트 및 멀티 플랫폼에 대한 서비스 지원 용이
단점
- 표준 존재 X
- 사용할 수 있는 메서드가 형태가 제한적 (only HTTP Method)
- 구형 브라우저의 경우 지원하지 않는 부분이 존재

<참고> REST vs GraphQL

REST
- HTTP URI를 통해 자원을 명시하고 HTTP Method를 통해 자원에 대한 CRUD를 적용
- 서버와 클라이언트의 역할이 명확히 분리되며 RestAPI의 메시지가 의도하는 바를 쉽게 파악 가능
- 여러 엔드포인트를 가지며 엔드포인트에 따라 정해진 응답만을 받아올 수 있음
GraphQL
- 클라이언트가 필요한 데이터를 얻도록 하는 일종의 쿼리 언어
- 백엔드가 정해놓는 틀이 없어 유연함
- 하나의 엔드포인트를 가지며 요청할 때 사용하는 쿼리에 따라 다른 응답(원하는 데이터만)을 받을 수 있음

REST API

REST를 기반으로 서비스 API를 구현한 것
REST 기반으로 시스템을 분산해 확장성과 재사용성을 높여 유지보수 및 운용을 편리하게 할 수 있음
REST는 HTTP 표준을 기반으로 구현하므로, HTTP를 지원하는 프로그램 언어로 클라이언트와 서버를 구현할 수 있음

REST API 설계 원칙

- 도큐먼트 : 객체 인스턴스나 데이터베이스 레코드와 유사한 개념
- 컬렉션 : 서버에서 관리하는 디렉터리라는 리소스
- 스토어: 클라이언트에서 관리하는 리소스 저장소

URI에서 자원은 동사보다는 명사를, 대문자보다는 소문자 사용
URI에서 자원의 도큐먼트 이름은 단수 명사 사용
URI에서 자원의 컬렉션 이름은 복수 명사 사용
URI에서 자원의 스토어 이름은 복수 명사 사용

URI에 HTTP Method 이름 명시 X
- ex) delete, post, get
URI에 행위에 대한 동사 표현(기능 표현) 명시 X
- ex) show, insert
경로 부분 중 변하는 부분은 유일한 값으로 대체 (고유 ID를 활용해 자원 특정)
- ex) students/12

슬래시 구분자(/)는 계층 관계를 나타내는데에 사용
URI 마지막 문자를 슬래시(/) 포함 X
하이픈(-)은 URI의 가독성을 높이기 위해 사용 가능
언더바(_)는 사용 X
URI에 파일 확장자(.jpg 등) 포함 X
리소스 간 연관 관계가 있는 경우: /리소스명/리소스 ID/연관 있는 다른 리소스 명
- ex) /users/{userid}/devices (일반적으로 소유 ‘has’의 관계를 표현할 때)

RESTful

"RESTful 하다": REST API를 제공하는 웹 서비스
"RESTful 하지 않다": CRUD 기능을 모두 POST로 처리하거나 REST API 설계 원칙을 따르지 않은 경우
REST를 REST답게 쓰기 위한 방법 (REST 원리를 따르는 시스템)

[BOJ] 백준 21609번 상어 중학교 - 파이썬(Python)

J1Yun — Fri, 7 Oct 2022 19:23:00 +0900

문제

상어 중학교의 코딩 동아리에서 게임을 만들었다. 이 게임은 크기가 N×N인 격자에서 진행되고, 초기에 격자의 모든 칸에는 블록이 하나씩 들어있고, 블록은 검은색 블록, 무지개 블록, 일반 블록이 있다. 일반 블록은 M가지 색상이 있고, 색은 M이하의 자연수로 표현한다. 검은색 블록은 -1, 무지개 블록은 0으로 표현한다. (i, j)는 격자의 i번 행, j번 열을 의미하고, |r1 - r2| + |c1 - c2| = 1을 만족하는 두 칸 (r1, c1)과 (r2, c2)를 인접한 칸이라고 한다.

블록 그룹은 연결된 블록의 집합이다. 그룹에는 일반 블록이 적어도 하나 있어야 하며, 일반 블록의 색은 모두 같아야 한다. 검은색 블록은 포함되면 안 되고, 무지개 블록은 얼마나 들어있든 상관없다. 그룹에 속한 블록의 개수는 2보다 크거나 같아야 하며, 임의의 한 블록에서 그룹에 속한 인접한 칸으로 이동해서 그룹에 속한 다른 모든 칸으로 이동할 수 있어야 한다. 블록 그룹의 기준 블록은 무지개 블록이 아닌 블록 중에서 행의 번호가 가장 작은 블록, 그러한 블록이 여러개면 열의 번호가 가장 작은 블록이다.

오늘은 이 게임에 오토 플레이 기능을 만드려고 한다. 오토 플레이는 다음과 같은 과정이 블록 그룹이 존재하는 동안 계속해서 반복되어야 한다.

크기가 가장 큰 블록 그룹을 찾는다. 그러한 블록 그룹이 여러 개라면 포함된 무지개 블록의 수가 가장 많은 블록 그룹, 그러한 블록도 여러개라면 기준 블록의 행이 가장 큰 것을, 그 것도 여러개이면 열이 가장 큰 것을 찾는다.
1에서 찾은 블록 그룹의 모든 블록을 제거한다. 블록 그룹에 포함된 블록의 수를 B라고 했을 때, B2점을 획득한다.
격자에 중력이 작용한다.
격자가 90도 반시계 방향으로 회전한다.
다시 격자에 중력이 작용한다.

격자에 중력이 작용하면 검은색 블록을 제외한 모든 블록이 행의 번호가 큰 칸으로 이동한다. 이동은 다른 블록이나 격자의 경계를 만나기 전까지 계속 된다.

다음은 N = 5, M = 3인 경우의 예시이다.

2	2	-1	3	1
3	3	2	0	-1
0	0	0	1	2
-1	3	1	3	2
0	3	2	2	1

여기서 찾을 수 있는 크기가 가장 큰 블록 그룹을 다음과 같이 빨간색으로 표시했다.

2	2	-1	3	1
3	3	2	0	-1
0	0	0	1	2
-1	3	1	3	2
0	3	2	2	1

블록 그룹이 제거되면 다음과 같이 변하고, 점수 82점을 획득한다.

2	2	-1	3	1
		2	0	-1
			1	2
-1		1	3	2
		2	2	1

중력이 작용하면 다음과 같이 변한다.

		-1	3	1
			0	-1
2		2	1	2
-1		1	3	2
	2	2	2	1

90도 반시계방향으로 회전한 결과는 다음과 같다.

1	-1	2	2	1
3	0	1	3	2
-1		2	1	2
				2
		2	-1

다시 여기서 중력이 작용하면 다음과 같이 변한다.

1	-1
3		2	2	1
-1		1	3	2
		2	1	2
	0	2	-1	2

오토 플레이가 모두 끝났을 때 획득한 점수의 합을 구해보자.

입력

첫째 줄에 격자 한 변의 크기 N, 색상의 개수 M이 주어진다.

둘째 줄부터 N개의 줄에 격자의 칸에 들어있는 블록의 정보가 1번 행부터 N번 행까지 순서대로 주어진다. 각 행에 대한 정보는 1열부터 N열까지 순서대로 주어진다. 입력으로 주어지는 칸의 정보는 -1, 0, M이하의 자연수로만 이루어져 있다.

출력

첫째 줄에 획득한 점수의 합을 출력한다.

https://www.acmicpc.net/problem/21609

21609번: 상어 중학교

상어 중학교의 코딩 동아리에서 게임을 만들었다. 이 게임은 크기가 N×N인 격자에서 진행되고, 초기에 격자의 모든 칸에는 블록이 하나씩 들어있고, 블록은 검은색 블록, 무지개 블록, 일반 블록

www.acmicpc.net

풀이 및 코드

from collections import deque

n, m = map(int, input().split())
board = []
for _ in range(n):
    board.append(list(map(int, input().split())))

dx, dy = [-1, 1, 0, 0], [0, 0, -1, 1]

def dfs(x, y, value, visited, visited_now):
    global count_block, count_rainbow

    visited_now[x][y] = 1
    if board[x][y] > 0:
        visited[x][y] = 1
    count_block += 1
    count_rainbow += 1 if board[x][y] == 0 else 0

    for i in range(4):
        nx, ny = x + dx[i], y + dy[i]
        if nx < 0 or nx >= n or ny < 0 or ny >= n or visited[nx][ny] or visited_now[nx][ny]:
            continue
        if board[nx][ny] == value or board[nx][ny] == 0: 
            dfs(nx, ny, value, visited, visited_now)
        

def findMaxBlockGroup():
    global count_block, count_rainbow
    max_block_group = (0, 0, 0, 0)
    visited = [[0]*n for _ in range(n)]

    for i in range(n):
        for j in range(n):
            if board[i][j] > 0 and not visited[i][j]:
                visited_now = [[0]*n for _ in range(n)]
                count_block, count_rainbow = 0, 0

                dfs(i, j, board[i][j], visited, visited_now)
                if count_block >= 2:
                    max_block_group = max(max_block_group, (count_block, count_rainbow, i, j))

    return max_block_group


def removeBlockGroup(x, y):
    queue = deque()
    visited = [[0]*n for _ in range(n)]
    queue.append((x, y))
    value = board[x][y]
    board[x][y] = -2

    while queue:
        x, y = queue.popleft()

        for i in range(4):
            nx, ny = x + dx[i], y + dy[i]
            if nx < 0 or nx >= n or ny < 0 or ny >= n or visited[nx][ny]:
                continue
            if board[nx][ny] == value or board[nx][ny] == 0:
                queue.append((nx, ny))
                board[nx][ny] = -2


def gravity():
    for j in range(n):
        remained = []
        for i in range(n-1, -1, -1):
            if board[i][j] == -1:
                remained = remained + [-2] * (n - i - len(remained) - 1)
            if board[i][j] != -2:
                remained.append(board[i][j])

        remained = remained + [-2] * (n - len(remained))
        for i in range(n-1, -1, -1):
            board[i][j] = remained[n-i-1]


def rotateCounterclockwise():
    return list(map(list, zip(*board)))[::-1]


result = 0
while 1:
    block_size, _, standard_x, standard_y = findMaxBlockGroup()
    if block_size == 0:
        break

    removeBlockGroup(standard_x, standard_y)
    result += block_size**2

    gravity()

    board = rotateCounterclockwise()

    gravity()

print(result)

요구사항이 많기 때문에 문제를 잘 읽고 조건을 파악한 후 그대로 구현하면 된다. 기능은 다음과 같이 분류하였다.

findMaxBlockGroup(): dfs를 활용하여 가장 큰 블록 그룹 찾기
removeBlockGroup(): 해당 그룹의 모든 요소 삭제하기 -> 이후 점수 계산
gravity(): 중력 가하기
rotateCounterclockwise(): 반시계 방향으로 격자 돌리기

[BOJ] 백준 21608번 상어 초등학교 - 파이썬(Python)

J1Yun — Fri, 7 Oct 2022 19:08:03 +0900

문제

상어 초등학교에는 교실이 하나 있고, 교실은 N×N 크기의 격자로 나타낼 수 있다. 학교에 다니는 학생의 수는 N2명이다. 오늘은 모든 학생의 자리를 정하는 날이다. 학생은 1번부터 N2번까지 번호가 매겨져 있고, (r, c)는 r행 c열을 의미한다. 교실의 가장 왼쪽 윗 칸은 (1, 1)이고, 가장 오른쪽 아랫 칸은 (N, N)이다.

선생님은 학생의 순서를 정했고, 각 학생이 좋아하는 학생 4명도 모두 조사했다. 이제 다음과 같은 규칙을 이용해 정해진 순서대로 학생의 자리를 정하려고 한다. 한 칸에는 학생 한 명의 자리만 있을 수 있고, |r1 - r2| + |c1 - c2| = 1을 만족하는 두 칸이 (r1, c1)과 (r2, c2)를 인접하다고 한다.

비어있는 칸 중에서 좋아하는 학생이 인접한 칸에 가장 많은 칸으로 자리를 정한다.
1을 만족하는 칸이 여러 개이면, 인접한 칸 중에서 비어있는 칸이 가장 많은 칸으로 자리를 정한다.
2를 만족하는 칸도 여러 개인 경우에는 행의 번호가 가장 작은 칸으로, 그러한 칸도 여러 개이면 열의 번호가 가장 작은 칸으로 자리를 정한다.

예를 들어, N = 3이고, 학생 N2명의 순서와 각 학생이 좋아하는 학생이 다음과 같은 경우를 생각해보자.

학생의 번호좋아하는 학생의 번호

학생의 번호	좋아하는 학생의 번호
4	2, 5, 1, 7
3	1, 9, 4, 5
9	8, 1, 2, 3
8	1, 9, 3, 4
7	2, 3, 4, 8
1	9, 2, 5, 7
6	5, 2, 3, 4
5	1, 9, 2, 8
2	9, 3, 1, 4

가장 먼저, 4번 학생의 자리를 정해야 한다. 현재 교실의 모든 칸은 빈 칸이다. 2번 조건에 의해 인접한 칸 중에서 비어있는 칸이 가장 많은 칸인 (2, 2)이 4번 학생의 자리가 된다.


	4

다음 학생은 3번이다. 1번 조건을 만족하는 칸은 (1, 2), (2, 1), (2, 3), (3, 2) 이다. 이 칸은 모두 비어있는 인접한 칸이 2개이다. 따라서, 3번 조건에 의해 (1, 2)가 3번 학생의 자리가 된다.

	3
	4

다음은 9번 학생이다. 9번 학생이 좋아하는 학생의 번호는 8, 1, 2, 3이고, 이 중에 3은 자리에 앉아있다. 좋아하는 학생이 가장 많이 인접한 칸은 (1, 1), (1, 3)이다. 두 칸 모두 비어있는 인접한 칸이 1개이고, 행의 번호도 1이다. 따라서, 3번 조건에 의해 (1, 1)이 9번 학생의 자리가 된다.

9	3
	4

이번에 자리를 정할 학생은 8번 학생이다. (2, 1)이 8번 학생이 좋아하는 학생과 가장 많이 인접한 칸이기 때문에, 여기가 그 학생의 자리이다.

9	3
8	4

7번 학생의 자리를 정해보자. 1번 조건을 만족하는 칸은 (1, 3), (2, 3), (3, 1), (3, 2)로 총 4개가 있고, 비어있는 칸과 가장 많이 인접한 칸은 (2, 3), (3, 2)이다. 행의 번호가 작은 (2, 3)이 7번 학생의 자리가 된다.

9	3
8	4	7

이런식으로 학생의 자리를 모두 정하면 다음과 같다.

9	3	2
8	4	7
5	6	1

이제 학생의 만족도를 구해야 한다. 학생의 만족도는 자리 배치가 모두 끝난 후에 구할 수 있다. 학생의 만족도를 구하려면 그 학생과 인접한 칸에 앉은 좋아하는 학생의 수를 구해야 한다. 그 값이 0이면 학생의 만족도는 0, 1이면 1, 2이면 10, 3이면 100, 4이면 1000이다.

학생의 만족도의 총 합을 구해보자.

입력

첫째 줄에 N이 주어진다. 둘째 줄부터 N2개의 줄에 학생의 번호와 그 학생이 좋아하는 학생 4명의 번호가 한 줄에 하나씩 선생님이 자리를 정할 순서대로 주어진다.

학생의 번호는 중복되지 않으며, 어떤 학생이 좋아하는 학생 4명은 모두 다른 학생으로 이루어져 있다. 입력으로 주어지는 학생의 번호, 좋아하는 학생의 번호는 N2보다 작거나 같은 자연수이다. 어떤 학생이 자기 자신을 좋아하는 경우는 없다.

출력

첫째 줄에 학생의 만족도의 총 합을 출력한다.

https://www.acmicpc.net/problem/21608

21608번: 상어 초등학교

상어 초등학교에는 교실이 하나 있고, 교실은 N×N 크기의 격자로 나타낼 수 있다. 학교에 다니는 학생의 수는 N2명이다. 오늘은 모든 학생의 자리를 정하는 날이다. 학생은 1번부터 N2번까지 번호

www.acmicpc.net

풀이 및 코드

data = {}
n = int(input())
for _ in range(n**2):
    s, f1, f2, f3, f4 = map(int, input().split())
    data[s] = [f1, f2, f3, f4]

seats = [[0]*n for _ in range(n)]
dx, dy = [-1, 1, 0, 0], [0, 0, -1, 1]

for student, friends in list(data.items()):
    result = (0, 0, -n+1, -n+1)
    for x in range(n):
        for y in range(n):
            if seats[x][y]:
                continue
            friend_cnt, empty_cnt = 0, 0
            for k in range(4):
                nx, ny = x + dx[k], y + dy[k]
                if nx < 0 or nx >= n or ny < 0 or ny >= n:
                    continue
                if seats[nx][ny] == 0:
                    empty_cnt += 1
                    continue
                if seats[nx][ny] in friends:
                    friend_cnt += 1
                    continue
            result = max(result, (friend_cnt, empty_cnt, -x, -y))
    x, y = -result[-2], -result[-1]
    seats[x][y] = student

answer = 0
for x in range(n):
    for y in range(n):
        student = seats[x][y]
        count = 0
        for k in range(4):
            nx, ny = x + dx[k], y + dy[k]
            if nx < 0 or nx >= n or ny < 0 or ny >= n:
                continue
            if seats[nx][ny] in data[student]:
                count += 1
        if count == 0:
            continue
        answer += 10**(count-1)

print(answer)

N은 20보다 작거나 같아 최대 학생 수 는 400명이기 때문에 완전탐색을 고려해볼 수 있다. 각 학생에 대해 각 자리를 순회하며 만족도가 가장 높은 위치를 찾아 지정하는 방식으로 단순히 구현하면 된다.

[디자인패턴] Factory Method 패턴 - 하위 클래스에서 인스턴스 작성하기

J1Yun — Tue, 6 Sep 2022 22:48:12 +0900

※ Java 언어로 배우는 디자인 패턴 입문(영진닷컴) 도서를 바탕으로 작성된 내용입니다.

Factory Method(펙토리 메소드) 패턴 소개

Template Method 패턴을 인스턴스 생성의 측면에 적용한 패턴
- 아래의 Factory Method 패턴 구조에서는 Creates가 Template Method에 해당
인스턴스를 만드는 방법을 상위 클래스에서 결정하지만 구체적인 클래스 이름까지 결정하지 않으며 구체적인 내용은 모두 하위 클래스에서 수행
상위 클래스에서는 공정(설계)만 선언, 하위 클래스에서 공정의 구체적인 동작을 구현

교재 발췌 이미지

예제 프로그램 - ID카드 공장

- Product 클래스 (Product.java)

추상 클래스로 구현된 Product(제품)의 역할

package framework;

public abstract class Product {
  public abstract void use();
}

- Factory 클래스 (Factory.java)

공정을 담고 있는 Creater(작성자)의 역할
Product를 생산하는 공정 과정을 담고 있음

package framework;

public abstract class Factory {
  public final Product create(String owner) {
    Product p = createProduct(owner);
    registerProduct(p);
    return p;
  }
  protected abstract Product createProduct(String owner);
  protected abstract void registerProduct(Product product);
}

- IDCard 클래스 (IDCard.java)

ConcreteProduct(구체적인 제품)의 역할
Product를 상속 받아 구체적으로 구현

package idcard;
import framework.*;

public class IDCard extends Product {
  private String owner;
  public IDCard(String owner) {
    System.out.println(owner + "의 카드를 만듭니다.");
    this.owner = owner;
  }
  @Override
  public void use() {
    System.out.println(owner + "의 카드를 사용합니다.");
  }
  public String getOwner() {
    return owner;
  }
}

- IDCardFactory 클래스 (IDCard.java)

ConcreteFactory 역할
Factory를 상속받아 구체적으로 공정 내용을 구현

package idcard;
import framework.*;
import java.util.*;

public class IDCardFactory extends Factory {
  private List owners = new ArrayList();
  @Override
  protected Product createProduct(String owner) {
    return new IDCard(owner);
  }
  @Override
  protected void registerProduct(Product product) {
    owners.add(((IDCard)product).getOwner());
  }
  public List getOwners() {
    return owners;
  }
}

- Main 클래스 (Main.java)

import framework.*;
import idcard.*;

public class Main {
  public static void main(String[] args) {
    Factory factory = new IDCardFactory();
    Product card1 = factory.create("홍길동");
    Product card2 = factory.create("박길동");
    Product card3 = factory.create("이길동");
    card1.use();
    card2.use();
    card3.use();
  }
}

장점과 단점

장점

framework 패키지는 idcard 패키지에 의존하지 않는다.
OCP 객체지향 원칙을 따른다.
Client(Main)의 입장에서 구체적인 공정이 추가되어도 Template Method(Creates)만 알면 되어 간편하다.

단점

추상 메소드 사용 시 하위 클래스에서 해당 메소드를 구현하지 않으면 컴파일 문제가 생긴다.
→ 디폴트의 구현 준비, 에러 이용
Provider(제공자) 입장에서 제품 공정이 늘어남에 따라 추가되는 클래스가 많아진다.

[AWS] SSL 인증서 설정한 CloudFront에 S3 배포 후 도메인 연결하기 - S3, CloudFront, Route53, ACM

J1Yun — Tue, 6 Sep 2022 01:12:08 +0900

1. Amazon S3 - 버킷 생성

Amazon S3 검색 >> 버킷 >> 버킷 만들기
버킷 이름, 리전 선택 >> 생성

모든 퍼블릭 엑세스 차단 해제
- 차단을 해제하지 않으면 정적 웹사이트 호스팅 후 도메인 접근 시 'Access Denied' 에러가 뜬다.

생성된 버킷 선택 >> 속성 >> 하단 정적 웹 사이트 호스팅 편집
정적 웹 사이트 호스팅 활성화, 인텍스 문서 설정

권한 >> 버킷 정책 편집
- 버킷 접근에 대한 정책 설정을 위해 다음 내용을 삽입한다.
- [버킷 ARN] 부분은 정책 에디터 상단에 표시된 버킷 ARN을 복사하여 붙혀 넣는다.

{
    "Version": "2012-10-17",
    "Id": "Policy1662277569063",
    "Statement": [
        {
            "Sid": "Stmt1662277568046",
            "Effect": "Allow",
            "Principal": "*",
            "Action": "s3:GetObject",
            "Resource": "[버킷 ARN]/*"
        }
    ]
}

2. AWS Certificate Manager(ACM) - SSL 인증서 생성

※ 사전에 도메인이 준비되어야 한다. 도메인은 Amazon Route53 - 도메인 등록을 통해 구매할 수 있다.
해당 실습에선 사전에 구매되어 있던 jigeumgo.com 도메인을 예시로 사용해보겠다.

ACM 검색 >> 인증서 요청 >> 퍼블릭 인증서 요청
- 미국 동부(버지니아 북부) 리전에서만 요청 가능하다.

도메인 이름을 다음과 같이 설정 >> 요청
- 도메인 앞에 *을 붙힌 이름으로 인증서를 생성하면 모든 서브 도메인에 대해 공통적으로 적용할 수 있다.

요청된 인증서 선택 >> Route 53에서 레코드 생성 버튼 >> 레코드 생성

3. Amazon CloudFront - S3버킷 배포

CloudFront 검색 >> 배포 >> 배포 생성
원본 도메인으로 이전에 만든 S3 버킷 도메인 선택

기본 캐시 동작 > 뷰어 - 뷰어 프로토콜 정책, 허용된 HTTP 방법 변경
- 뷰어 프로토콜 정책: Redirect HTTP to HTTPS 선택
- 허용된 HTTP 방법: GET, HEAD, OPTIONS, PUT, POST, PATCH, DELETE 선택

설정 > 대체 도메인 이름(CNAME), 사용자 정의 SSL 인증서 설정
- 대체 도메인 이름(CNAME): www 서브 도메인 입력
- 사용자 정의 SSL 인증서: 이전에 생성한 SSL 인증서 선택

배포 생성 후 index.html을 포함한 배포 파일 업로드

4. Amazon Route 53 - CloudFront로 연결될 도메인 레코드 추가

Route 53 검색 >> 호스팅 영역 >> (호스팅 영역 생성) >> 도메인 선택 >> 레코드 생성
빠른 레코드 생성
- 먼저 '별칭' check bar를 활성화 해준다.
- 레코드 이름: CloudFront에 설정한 대체 도메인 이름(CNAME)과 같은 서브 도메인명 입력
- 트래픽 라우팅 대상: CloudFront 배포에 대한 별칭 선택
- 배포 선택: 이전에 생성한 CloudFront 도메인 선택

5. 도메인 접속

연결한 www 도메인으로 접속 테스트

[Programmers] 프로그래머스 LV.1 성격 유형 검사하기 - 파이썬(Python)

J1Yun — Fri, 2 Sep 2022 16:30:06 +0900

문제 설명

나만의 카카오 성격 유형 검사지를 만들려고 합니다.
성격 유형 검사는 다음과 같은 4개 지표로 성격 유형을 구분합니다. 성격은 각 지표에서 두 유형 중 하나로 결정됩니다.

지표 번호	성격 유형
1번 지표	라이언형(R), 튜브형(T)
2번 지표	콘형(C), 프로도형(F)
3번 지표	제이지형(J), 무지형(M)
4번 지표	어피치형(A), 네오형(N)

4개의 지표가 있으므로 성격 유형은 총 16(=2 x 2 x 2 x 2)가지가 나올 수 있습니다. 예를 들어, "RFMN"이나 "TCMA"와 같은 성격 유형이 있습니다.

검사지에는 총 n개의 질문이 있고, 각 질문에는 아래와 같은 7개의 선택지가 있습니다.

매우 비동의
비동의
약간 비동의
모르겠음
약간 동의
동의
매우 동의

각 질문은 1가지 지표로 성격 유형 점수를 판단합니다.

예를 들어, 어떤 한 질문에서 4번 지표로 아래 표처럼 점수를 매길 수 있습니다.

선택지	성격 유형 점수
매우 비동의	네오형 3점
비동의	네오형 2점
약간 비동의	네오형 1점
모르겠음	어떤 성격 유형도 점수를 얻지 않습니다
약간 동의	어피치형 1점
동의	어피치형 2점
매우 동의	어피치형 3점

이때 검사자가 질문에서 약간 동의 선택지를 선택할 경우 어피치형(A) 성격 유형 1점을 받게 됩니다. 만약 검사자가 매우 비동의 선택지를 선택할 경우 네오형(N) 성격 유형 3점을 받게 됩니다.

위 예시처럼 네오형이 비동의, 어피치형이 동의인 경우만 주어지지 않고, 질문에 따라 네오형이 동의, 어피치형이 비동의인 경우도 주어질 수 있습니다.
하지만 각 선택지는 고정적인 크기의 점수를 가지고 있습니다.

매우 동의나 매우 비동의 선택지를 선택하면 3점을 얻습니다.
동의나 비동의 선택지를 선택하면 2점을 얻습니다.
약간 동의나 약간 비동의 선택지를 선택하면 1점을 얻습니다.
모르겠음 선택지를 선택하면 점수를 얻지 않습니다.

검사 결과는 모든 질문의 성격 유형 점수를 더하여 각 지표에서 더 높은 점수를 받은 성격 유형이 검사자의 성격 유형이라고 판단합니다. 단, 하나의 지표에서 각 성격 유형 점수가 같으면, 두 성격 유형 중 사전 순으로 빠른 성격 유형을 검사자의 성격 유형이라고 판단합니다.

질문마다 판단하는 지표를 담은 1차원 문자열 배열 survey와 검사자가 각 질문마다 선택한 선택지를 담은 1차원 정수 배열 choices가 매개변수로 주어집니다. 이때, 검사자의 성격 유형 검사 결과를 지표 번호 순서대로 return 하도록 solution 함수를 완성해주세요.

제한 사항

1 ≤ survey의 길이 ( = n) ≤ 1,000
- survey의 원소는 "RT", "TR", "FC", "CF", "MJ", "JM", "AN", "NA" 중 하나입니다.
- survey[i]의 첫 번째 캐릭터는 i+1번 질문의 비동의 관련 선택지를 선택하면 받는 성격 유형을 의미합니다.
- survey[i]의 두 번째 캐릭터는 i+1번 질문의 동의 관련 선택지를 선택하면 받는 성격 유형을 의미합니다.
- choices[i]는 검사자가 선택한 i+1번째 질문의 선택지를 의미합니다.
- 1 ≤ choices의 원소 ≤ 7choices의 길이 = survey의 길이
choices 뜻

1 매우 비동의

2 비동의

3 약간 비동의

4 모르겠음

5 약간 동의

6 동의

7 매우 동의

https://school.programmers.co.kr/learn/courses/30/lessons/118666

프로그래머스

코드 중심의 개발자 채용. 스택 기반의 포지션 매칭. 프로그래머스의 개발자 맞춤형 프로필을 등록하고, 나와 기술 궁합이 잘 맞는 기업들을 매칭 받으세요.

programmers.co.kr

풀이 및 코드

def solution(survey, choices):
    types = {'R': 0, 'T': 0, 'C': 0, 'F': 0, 'J': 0, 'M': 0, 'A': 0, 'N': 0}
    for i in range(len(choices)):
        if choices[i] < 4:
            types[survey[i][0]] += (choices[i] * 3) % 4
        if choices[i] > 4:
            types[survey[i][1]] += choices[i] % 4
    type_key = list(types.keys())
    
    answer = ''
    for i in range(0, len(type_key), 2):
        if types[type_key[i]] > types[type_key[i+1]]:
            answer += type_key[i]
        elif types[type_key[i]] < types[type_key[i+1]]:
            answer += type_key[i+1]
        else:
            answer += min(type_key[i], type_key[i+1])
    return answer

성격 유형에 대한 점수를 dictionary 형태로 만들어 저장한다. 각각의 지표 별로 더 높은 점수의 성격 유형을 채택하되, 점수가 같을 때에는 min함수를 활용하여 알파벳이 사전 상 더 빠른 (작은) 유형을 선택한다.

[Programmers] 프로그래머스 LV.1 신고 결과 받기 - 파이썬(Python)

J1Yun — Fri, 2 Sep 2022 16:12:13 +0900

문제 설명

신입사원 무지는 게시판 불량 이용자를 신고하고 처리 결과를 메일로 발송하는 시스템을 개발하려 합니다. 무지가 개발하려는 시스템은 다음과 같습니다.

각 유저는 한 번에 한 명의 유저를 신고할 수 있습니다.
- 신고 횟수에 제한은 없습니다. 서로 다른 유저를 계속해서 신고할 수 있습니다.
- 한 유저를 여러 번 신고할 수도 있지만, 동일한 유저에 대한 신고 횟수는 1회로 처리됩니다.
k번 이상 신고된 유저는 게시판 이용이 정지되며, 해당 유저를 신고한 모든 유저에게 정지 사실을 메일로 발송합니다.
- 유저가 신고한 모든 내용을 취합하여 마지막에 한꺼번에 게시판 이용 정지를 시키면서 정지 메일을 발송합니다.

다음은 전체 유저 목록이 ["muzi", "frodo", "apeach", "neo"]이고, k = 2(즉, 2번 이상 신고당하면 이용 정지)인 경우의 예시입니다.

유저 ID	유저가 신고한 ID	설명
"muzi"	"frodo"	"muzi"가 "frodo"를 신고했습니다.
"apeach"	"frodo"	"apeach"가 "frodo"를 신고했습니다.
"frodo"	"neo"	"frodo"가 "neo"를 신고했습니다.
"muzi"	"neo"	"muzi"가 "neo"를 신고했습니다.
"apeach"	"muzi"	"apeach"가 "muzi"를 신고했습니다.

각 유저별로 신고당한 횟수는 다음과 같습니다.

유저 ID	신고 당한 횟수
"muzi"	1
"frodo"	2
"apeach"	0
"neo"	2

위 예시에서는 2번 이상 신고당한 "frodo"와 "neo"의 게시판 이용이 정지됩니다. 이때, 각 유저별로 신고한 아이디와 정지된 아이디를 정리하면 다음과 같습니다.

유저 ID	유저가 신고한 ID	정지된 ID
"muzi"	["frodo", "neo"]	["frodo", "neo"]
"frodo"	["neo"]	["neo"]
"apeach"	["muzi", "frodo"]	["frodo"]
"neo"	없음	없음

따라서 "muzi"는 처리 결과 메일을 2회, "frodo"와 "apeach"는 각각 처리 결과 메일을 1회 받게 됩니다.

이용자의 ID가 담긴 문자열 배열 id_list, 각 이용자가 신고한 이용자의 ID 정보가 담긴 문자열 배열 report, 정지 기준이 되는 신고 횟수 k가 매개변수로 주어질 때, 각 유저별로 처리 결과 메일을 받은 횟수를 배열에 담아 return 하도록 solution 함수를 완성해주세요.

제한사항

2 ≤ id_list의 길이 ≤ 1,000
- 1 ≤ id_list의 원소 길이 ≤ 10
- id_list의 원소는 이용자의 id를 나타내는 문자열이며 알파벳 소문자로만 이루어져 있습니다.
- id_list에는 같은 아이디가 중복해서 들어있지 않습니다.
1 ≤ report의 길이 ≤ 200,000
- 3 ≤ report의 원소 길이 ≤ 21
- report의 원소는 "이용자id 신고한id"형태의 문자열입니다.
- 예를 들어 "muzi frodo"의 경우 "muzi"가 "frodo"를 신고했다는 의미입니다.
- id는 알파벳 소문자로만 이루어져 있습니다.
- 이용자id와 신고한id는 공백(스페이스)하나로 구분되어 있습니다.
- 자기 자신을 신고하는 경우는 없습니다.
1 ≤ k ≤ 200, k는 자연수입니다.
return 하는 배열은 id_list에 담긴 id 순서대로 각 유저가 받은 결과 메일 수를 담으면 됩니다.

https://school.programmers.co.kr/learn/courses/30/lessons/92334

프로그래머스

programmers.co.kr

풀이 및 코드

from collections import defaultdict

def solution(id_list, report, k):
    answer = []
    report_who = defaultdict(set)
    for rep in report:
        id, report_id = rep.split()
        report_who[report_id].add(id)

    restricted_id = []
    for id in id_list:
        if len(report_who[id]) >= k:
            restricted_id.append(id)

    for id in id_list:
        count = 0
        for rid in restricted_id:
            if id in report_who[rid]:
                count += 1
        answer.append(count)
    
    return answer

이 문제의 핵심은 동일한 유저에 대한 신고 횟수는 1회로 처리된다는 것이다. 단순히 신고 횟수가 k회 이상인 경우가 아닌 신고한 사람이 k명 이상일 경우를 판단해 게시판 이용을 정지시켜야 한다. 따라서 각 유저별로 신고 당한 ID를 저장할 때(report_who) 동일한 유저에 대해서는 신고가 한번만 저장될 수 있도록 set을 사용했다.

[BOJ] 백준 17144번 미세먼지 안녕! - 파이썬(Python)

J1Yun — Fri, 26 Aug 2022 20:58:11 +0900

문제

미세먼지를 제거하기 위해 구사과는 공기청정기를 설치하려고 한다. 공기청정기의 성능을 테스트하기 위해 구사과는 집을 크기가 R×C인 격자판으로 나타냈고, 1×1 크기의 칸으로 나눴다. 구사과는 뛰어난 코딩 실력을 이용해 각 칸 (r, c)에 있는 미세먼지의 양을 실시간으로 모니터링하는 시스템을 개발했다. (r, c)는 r행 c열을 의미한다.

공기청정기는 항상 1번 열에 설치되어 있고, 크기는 두 행을 차지한다. 공기청정기가 설치되어 있지 않은 칸에는 미세먼지가 있고, (r, c)에 있는 미세먼지의 양은 Ar,c이다.

1초 동안 아래 적힌 일이 순서대로 일어난다.

미세먼지가 확산된다. 확산은 미세먼지가 있는 모든 칸에서 동시에 일어난다.
- (r, c)에 있는 미세먼지는 인접한 네 방향으로 확산된다.
- 인접한 방향에 공기청정기가 있거나, 칸이 없으면 그 방향으로는 확산이 일어나지 않는다.
- 확산되는 양은 Ar,c/5이고 소수점은 버린다.
- (r, c)에 남은 미세먼지의 양은 Ar,c - (Ar,c/5)×(확산된 방향의 개수) 이다.
공기청정기가 작동한다.
- 공기청정기에서는 바람이 나온다.
- 위쪽 공기청정기의 바람은 반시계방향으로 순환하고, 아래쪽 공기청정기의 바람은 시계방향으로 순환한다.
- 바람이 불면 미세먼지가 바람의 방향대로 모두 한 칸씩 이동한다.
- 공기청정기에서 부는 바람은 미세먼지가 없는 바람이고, 공기청정기로 들어간 미세먼지는 모두 정화된다.

다음은 확산의 예시이다.

왼쪽과 오른쪽에 칸이 없기 때문에, 두 방향으로만 확산이 일어났다.

인접한 네 방향으로 모두 확산이 일어난다.

공기청정기가 있는 칸으로는 확산이 일어나지 않는다.

공기청정기의 바람은 다음과 같은 방향으로 순환한다.

방의 정보가 주어졌을 때, T초가 지난 후 구사과의 방에 남아있는 미세먼지의 양을 구해보자.

입력

첫째 줄에 R, C, T (6 ≤ R, C ≤ 50, 1 ≤ T ≤ 1,000) 가 주어진다.

둘째 줄부터 R개의 줄에 Ar,c (-1 ≤ Ar,c ≤ 1,000)가 주어진다. 공기청정기가 설치된 곳은 Ar,c가 -1이고, 나머지 값은 미세먼지의 양이다. -1은 2번 위아래로 붙어져 있고, 가장 윗 행, 아랫 행과 두 칸이상 떨어져 있다.

출력

첫째 줄에 T초가 지난 후 구사과 방에 남아있는 미세먼지의 양을 출력한다.

https://www.acmicpc.net/problem/17144

17144번: 미세먼지 안녕!

미세먼지를 제거하기 위해 구사과는 공기청정기를 설치하려고 한다. 공기청정기의 성능을 테스트하기 위해 구사과는 집을 크기가 R×C인 격자판으로 나타냈고, 1×1 크기의 칸으로 나눴다. 구사

www.acmicpc.net

풀이 및 코드

from copy import deepcopy
r, c, t = map(int, input().split())
graph = []
for _ in range(r):
    graph.append(list(map(int, input().split())))

dx, dy = [-1, 1, 0, 0], [0, 0, -1, 1]

def spread():
    data = deepcopy(graph)
    for x in range(r):
        for y in range(c):
            if graph[x][y] > 0:
                temp, count = graph[x][y] // 5, 0
                for i in range(4):
                    nx, ny = x + dx[i], y + dy[i]
                    if nx < 0 or nx >= r or ny < 0 or ny >= c or graph[nx][ny] == -1:
                        continue
                    data[nx][ny] += temp
                    count += 1
                data[x][y] -= temp * count
    return data

def move(x1, x2):
    data = deepcopy(graph)
    for i in range(1, c-1):
        data[x1][i+1] = graph[x1][i]
        data[x2][i+1] = graph[x2][i]
    for i in range(c-1):
        data[0][i] = graph[0][i+1]
        data[r-1][i] = graph[r-1][i+1]
    for i in range(x1):
        data[i+1][0] = graph[i][0]
        data[i][c-1] = graph[i+1][c-1]
    for i in range(x2+1, r):
        data[i-1][0] = graph[i][0]
        data[i][c-1] = graph[i-1][c-1]
    data[x1][0], data[x2][0], data[x1][1], data[x2][1] = -1, -1, 0, 0
    return data

cleaner = []
for _ in range(t):
    graph = spread()
    for i in range(r):
            if graph[i][0] == -1:
                cleaner.append(i)
    graph = move(cleaner[0], cleaner[1])

result = 0
for i in range(r):
    for j in range(c):
        if graph[i][j] > 0:
            result += graph[i][j]

print(result)

주어진 조건 그대로 구현하면 되는 문제이다. 주의할 점은 미세먼지 확산과 공기청정기 작동 시 입력 받은 미세먼지 데이터에 직접 변형시키는 것이 아니라, deepcopy로 복사본을 만들어서 적용한 후 덮어 쓰는 방식으로 구현해야 한다. 확산되거나 이동한 미세먼지가 다른 격자의 미세먼지 확산이나 이동에 영향을 끼치면 안되기 때문이다.

[BOJ] 백준 15685번 드래곤 커브 - 파이썬(Python)

J1Yun — Tue, 23 Aug 2022 18:55:48 +0900

문제

드래곤 커브는 다음과 같은 세 가지 속성으로 이루어져 있으며, 이차원 좌표 평면 위에서 정의된다. 좌표 평면의 x축은 → 방향, y축은 ↓ 방향이다.

시작 점
시작 방향
세대

0세대 드래곤 커브는 아래 그림과 같은 길이가 1인 선분이다. 아래 그림은 (0, 0)에서 시작하고, 시작 방향은 오른쪽인 0세대 드래곤 커브이다.

1세대 드래곤 커브는 0세대 드래곤 커브를 끝 점을 기준으로 시계 방향으로 90도 회전시킨 다음 0세대 드래곤 커브의 끝 점에 붙인 것이다. 끝 점이란 시작 점에서 선분을 타고 이동했을 때, 가장 먼 거리에 있는 점을 의미한다.

2세대 드래곤 커브도 1세대를 만든 방법을 이용해서 만들 수 있다. (파란색 선분은 새로 추가된 선분을 나타낸다)

3세대 드래곤 커브도 2세대 드래곤 커브를 이용해 만들 수 있다. 아래 그림은 3세대 드래곤 커브이다.

즉, K(K > 1)세대 드래곤 커브는 K-1세대 드래곤 커브를 끝 점을 기준으로 90도 시계 방향 회전 시킨 다음, 그것을 끝 점에 붙인 것이다.

크기가 100×100인 격자 위에 드래곤 커브가 N개 있다. 이때, 크기가 1×1인 정사각형의 네 꼭짓점이 모두 드래곤 커브의 일부인 정사각형의 개수를 구하는 프로그램을 작성하시오. 격자의 좌표는 (x, y)로 나타내며, 0 ≤ x ≤ 100, 0 ≤ y ≤ 100만 유효한 좌표이다.

입력

첫째 줄에 드래곤 커브의 개수 N(1 ≤ N ≤ 20)이 주어진다. 둘째 줄부터 N개의 줄에는 드래곤 커브의 정보가 주어진다. 드래곤 커브의 정보는 네 정수 x, y, d, g로 이루어져 있다. x와 y는 드래곤 커브의 시작 점, d는 시작 방향, g는 세대이다. (0 ≤ x, y ≤ 100, 0 ≤ d ≤ 3, 0 ≤ g ≤ 10)

입력으로 주어지는 드래곤 커브는 격자 밖으로 벗어나지 않는다. 드래곤 커브는 서로 겹칠 수 있다.

방향은 0, 1, 2, 3 중 하나이고, 다음을 의미한다.

0: x좌표가 증가하는 방향 (→)
1: y좌표가 감소하는 방향 (↑)
2: x좌표가 감소하는 방향 (←)
3: y좌표가 증가하는 방향 (↓)

출력

첫째 줄에 크기가 1×1인 정사각형의 네 꼭짓점이 모두 드래곤 커브의 일부인 것의 개수를 출력한다.

https://www.acmicpc.net/problem/15685

15685번: 드래곤 커브

첫째 줄에 드래곤 커브의 개수 N(1 ≤ N ≤ 20)이 주어진다. 둘째 줄부터 N개의 줄에는 드래곤 커브의 정보가 주어진다. 드래곤 커브의 정보는 네 정수 x, y, d, g로 이루어져 있다. x와 y는 드래곤 커

www.acmicpc.net

풀이 및 코드

n = int(input())
data = []
grid = [[0] * 101 for _ in range(101)]
for _ in range(n):
    data.append(tuple(map(int, input().split())))

dx, dy = [0, -1, 0, 1], [1, 0, -1, 0]
for y, x, d, g in data:
    dragon = []
    dragon.append((x, y, d))
    grid[x][y] = 1
    nx, ny = x + dx[d], y + dy[d]
    for _ in range(g):
        length = len(dragon)
        for i in range(length-1, -1, -1):
            d = (dragon[i][2] + 1) % 4
            dragon.append((nx, ny, d))
            grid[nx][ny] = 1
            nx, ny = nx + dx[d], ny + dy[d]
    grid[nx][ny] = 1

result = 0
for i in range(100):
    for j in range(100):
        if grid[i][j] and grid[i+1][j] and grid[i][j+1] and grid[i+1][j+1]:
            result += 1

print(result)

dragon 이라는 배열에 그릴 경로의 시작 위치(x, y)와 방향(d)를 저장하고, 해당 끝점(nx, ny)를 기준으로 90도 시계 방향으로 방향 돌려가며 하나하나 그려나가는 방식으로 구현했다. 이때, 이전 경로의 끝점을 기준으로 그려나가야 하기 때문에 dragon 배열을 역순회하면서 저장되어있는 방향을 90도 꺾은 방향(d = (dragon[i][2] + 1) % 4)으로 이전 경로의 끝점에 연결해야 한다.

[SWM] 소마 7월 회고 - 기술 및 아키텍처 설계, 스프린트 시작

J1Yun — Fri, 19 Aug 2022 00:21:58 +0900

1. 기술 및 아키텍처 설계

프런트엔드 기술 스택의 경우에는 프런트엔드 개발 담당인 연수생B가 구성 후 우리에게 공유하였다. 나와 연수생A는 백엔드 파트 기술 스택 구성과 AWS 아키텍처 설계를 담당하였다. AWS 아키텍처 설계의 경우, 우리의 담당 멘토님이신 멘토님A의 도움을 받았다. 멘토님A는 현재 AWS 커뮤니티 빌더(Community Builder)로 활동하시는 AWS 전문가이시다. 덕분에 이전에 경험해보지 못한 보안과 대용량 트래픽을 고려한 서버/DB 아키텍처를 설계하고 구축해 볼 수 있었다.

1.1. 기술 스택 선택하기

프론트엔드 파트에서 선정된 기술 스택은 다음과 같다.

TypeScript/ReactJS
React-Router
Styled-Components
Zustand

백엔드와 데이터베이스 파트에서 최종적으로 선택한 기술 스택은 다음과 같다.

TypeScript/Nest.js
Socket.io
TypeORM/MySQL
(+) Redis

연수생A와 백엔드 기술 스택 선택에 대한 이야기를 나누어본 결과 공통적으로 객체 지향 프로그래밍(OOP)에 대한 관심을 가지고 있었다. 하지만 나와 연수생A 모두 Node.js와 Express을 주로 활용해왔는데 우리가 익숙하게 사용했던 JavaScript는 객체 지향적으로 설계하기에는 까다로운 부분들이 있다. 따라서, 객체 지향적인 문법과 구조를 지원하는 TypeScript를 활용하기로 결정했다. 처음에는 대표적인 객체 지향 언어인 Java를 고려해보기도 했지만 짧은 기간 내에 새로운 언어와 프레임워크를 익혀 활용하는 것은 완성도 있는 결과물을 도출해야하는 프로젝트의 특성 상 한계가 있을 것이라고 판단했다. TypeScript는 기본적으로 JavaScript를 기반으로 하기 때문에 빠르게 익히고 활용하기에 적합했으며, 타입 시스템으로 에러 발생 가능성을 사전에 방지하는 등의 장점도 있다. 백엔드 프레임워크는 TypeScript와 궁합이 좋은 NestJS를 선택했다. NestJS는 다양한 라이브러리를 쉽게 설치하며 기능을 확장할 수 있다는 Node.js의 장점은 그대로 가지면서 모듈/컴포넌트 기반으로 재사용성과 유지보수성이 높은 코드 구조를 설계할 수 있다. 이또한 결국엔 완벽한 객체 지향을 위한 선택이었던 것이다. '지금갈게' 서비스의 경우 '실시간성'이 가장 핵심적인 구현 요소이기 때문에 양방향 통신을 통한 실시간 요청을 처리를 위한 웹소켓으로 Socket.io를 활용한다. 데이터베이스의 경우 관계형 DB인 MySQL을 사용하되 TypeORM으로 매핑할 예정이다.

1-2. AWS 대용량 아키텍처 구성하기

최종적으로 구성된 AWS 시스템 구성도는 다음과 같다.

Amazon S3/CloudFront
Amazon EC2/ELB/NatGateway
Amazon AutoScalingGroup
Amazon Route53/CertificateManager
Amazon RDS/ElasticCacheForRedis

서버 아키텍처는 대용량 트래픽과 보안, 고성능을 고려한 구성해봤다. 소마에서 팀별로 클라우드 지원금을 지급하기 때문에 AWS 환경에 직접 구축도 해볼 수 있었다. 우선 연수생A와 함께 멘토님A의 도움을 받아 실제 프로젝트에 적용될 스펙과 동일하게 연습용 클라우드 환경 구축 실습을 진행했다. 클라이언트 측은 S3를 사용하여 웹사이트를 호스팅했고, 이에 전송 속도와 보안성을 높이고자 CDN 서비스인 Cloudfront를 덧붙혔다. 서버 측은 두 개의 EC2 인스턴스와 ELB를 활용하여 분산 서버를 구축했다. 이때, 보안을 고려하여 두 개의 EC2 인스턴스는 두 개의 가용영역 내 각각의 프라이빗 서브넷 영역에 위치시키고, 외부 인터넷 통신을 위한 Nat Gateway와 프라이빗 인스턴스 접근을 위한 bastion host까지 구축했다. 이들은 Auto Scaling Group으로 인스턴스 수와 크기가 자동으로 관리된다. 관계형 데이터베이스의 경우 RDS를 이중화하여 데이터베이스 장애 등에 대비하고, 읽기 전용 복제본(Replica)으로 분산 DB를 구성하여 데이터베이스 조회 성능을 높혔다. 마지막으로 데이터 캐싱과 메시지 PUP/SUB을 지원하기 위한 ElastiCache for Redis를 Master-Slave 구조로 이중화했다.

2. 스프린트 시작

첫 스프린트가 시작되었다. 먼저, Jira 팀 페이지에 전반적은 로드맵과 백로그를 정의한 후 담당자까지 지정해서 등록하였다. 이전까지는 중구난방으로 할 일을 정의하고, 아무나 해당 일처리를 진행했다면 애자일(스크럼) 개발 방식 도입 후에는 능률이 확실히 올랐다. 우선, 스프린트와 백로그를 확실하게 정의하고 이를 기록으로 남겨두게 되어 프로젝트 진행 현황이나 내가 해야할 일을 한눈에 확인할 수 있었고, 스프린트 기간이 정해져 있다 보니 작업들이 뒤로 밀리지 않고 체계적으로 마무리가 된다는 느낌을 받았다. 또, 중간중간 발생하는 이슈들에 대해 일정 딜레이 없이 효과적으로 관리할 수 있었다.

2-1. Socket.io를 활용한 채팅방 만들어보기

나와 연수생A 모두 Socket.io와 같은 웹소켓은 처음 사용해 보았다. 자세한 통신 방법이나 사용법에 대한 이해도 부족했기 때문에 Socket.io를 본 프로젝트에 바로 적용하는 것은 무리가 있다고 판단했다. 따라서, 스터디를 통해 웹소켓(Socket.io)에 대한 기본지식 및 개념을 공부하고, 채팅방을 구현하는 미니 프로젝트를 개인적으로 진행해 보기로 했다. 스터디는 Socket.io 공식문서(https://socket.io)와 유튜브 강의 등의 학습자료로 공부한 후 그 내용을 레퍼런스와 함께 노션에 정리해서 공유했다. 이후 소켓 통신을 구현할 수 있는 대표 예제를 참고하여 채팅방 프로그램을 구현했다. namespace와 room의 개념, 그리고 발행(Publish)에 해당하는 emit과 구독(Subscribe)에 해당하는 on 기능을 활용했다. 백엔드와 데이터베이스 파트 또한 공식 문서 등을 활용해 NestJS와 TypeORM/MySQL로 구현하는 방법을 익혀 적용했다.

https://github.com/J1Yun/simple-chatting-web

GitHub - J1Yun/simple-chatting-web: NestJS, TypeORM, Socket.io를 활용한 채팅 구현 실습

NestJS, TypeORM, Socket.io를 활용한 채팅 구현 실습. Contribute to J1Yun/simple-chatting-web development by creating an account on GitHub.

github.com

2-2. JWT와 Passport를 활용한 로그인 인증 기능 구현하기

본격적인 MVP 개발에 들어가기 이전에 먼저 서비스 로직과 관계없는 로그인 인증 기능을 구현하기로 했다. 기존에 토이 프로젝트를 진행할 때는 주로 쿠키와 세션을 통해 인증 기능을 구현해왔지만 이번에는 확장성을 고려해 토큰 기반의 인증 방식을 채택했다. 그 중에서 가장 대표적인 JWT 토큰을 활용해 로그인 정보를 관리한다. 로그인 성공 시 서버는 JWT 토큰을 발급해 이를 클라이언트에서 관리하도록 넘겨준다. 토큰 인증 방식 및 JWT와 관련한 상세 내용은 블로그 포스팅을 참고하면 된다. JWT와 더불어 Passport.js라는 라이브러리도 함께 사용한다. Passport.js JWT 토큰으로 '인증'을 수행할 수 있도록 하는 Node.js의 미들웨어이다. passport에는 여러 strategy(전략)이 있는데 단순히 JWT 토큰을 읽어와 사용자를 인증하도록 아래 사진과 같이 JwtStrategy를 작성했다. 이와함께 @UseGuards() 데코레이터를 통해 사용자 정보 확인이 필요한 API 호출 시 인증 과정이 수행되도록 구현했다.

JwtStrategy

choices	뜻
1	매우 비동의
2	비동의
3	약간 비동의
4	모르겠음
5	약간 동의
6	동의
7	매우 동의