백짱미 개발log

본 포스팅은 공룡책으로 불리는 Abraham Silberschatz, Peter B. Galvin, Greg Gagne의 『Operating System Concept 10th』 기반으로 정리한 글입니다.

Operating System Services

OS service

1. user에게 유용한 기능

• User Interface (사용자와 컴퓨터의 연결 지점)
• Program execution (프로그램을 메모리에 로드하고 실행, 종료)
• I/O operations (사용자가 직접 제어X, 입출력 명령으로 I/O 방법 제공)
• File-system manipulation (I/O, 조작, 권한 관리)
• Communications (process간 통신) (1. shared memory) (2. message passing)
• Error detection (오류 탐지 및 수정, 종류에 따른 처리 진행)

2. System 자체적으로 효율적인 운영을 위한 기능

• Systems with multiple processes can gain efficiency
• Resource allocation (효율적인 CPU 사용을 위해 CPU 속도, 실행돼야 하는 프로세스, core 수 등을 고려하여 CPU 스케줄링 진행)
• Logging (어떤 프로그램이 어떤 자원을 얼마나 사용하는가)
• Protection and security (자원 접근 통제, 외부 침입에 대한 인증 요구)

User and Operating System Interface

• CLI (Command-Line Interface) or command interpreter
• GUI (Graphic User Interface)

Command Interpreters

• 사용자-지정 명령 처리
• 파일 조작
• 구현 방법
  • 명령 해석기 자체가 명령어를 실행할 수 있는 코드 내장
  • 명령을 실행하는 파일(프로그램)이 별도로 존재하고, 이를 호출해서 실행
  • 이 경우 프로그래머가 system에 새로운 명령어 추가하기 쉬움

System Calls

OS 서비스에 대한 인터페이스를 제공하는 역할

• System call table : 특정 system call에 할당된 동작들이 있고, 이것들이 모인 곳(Interrupt vector)
• System call은 kernel과 user program을 이어주는 interface 역할
  • ex) user program이 파일을 열 때 시스템에 접근하기 위해서는 kernel mode로 전환되어야 하고, 여러 동작들을 수행하기 위해서는 system call이 여러 번 호출됨
  • 그 후 실제 I/O 처리가 이뤄지고 후처리 과정 거침

Application Programming Interface (API)

• 단순한 프로그램도 OS의 기능을 많이 사용하며 수많은 system call 호출
• 개발자가 system call을 직접 처리하는 대신 사용할 수 있는 집합인 API 사용
• OS가 제공하는 라이브러리를 통해 API를 사용하여 이를 구성하는 함수들이 개발자를 대신하여 실제 system call 수행
• Most Common API
  • Window, POSIX, Java API

API 장점

• program portability (이식성) : 동일한 API를 사용하면 어떤 시스템에서라도 complie & run
• 실제 system call은 정교하여 다루기 어려우므로 편리한 API 사용

RTE (Run-Time Environment)

• 특정 프로그래밍 언어로 쓰여진 application을 수행하기 위한 sw 집합
• system-call interface 제공
  • OS가 제공하는 system call에 대한 연결점
• API 함수 호출이 일어나면 이를 가로채서 필요한 OS System call을 호출
• System call에 대한 번호가 있고, 이에 따라 index된 테이블을 유지
• System call interface는 system call의 상태 정보 return

System Call Implementation

 OS에게 parameter 전달 방식

• register 이용
• memory block 이용 : 메모리 내 block이나 table에 저장 
  • 그 시작 주소를 register에 parameter로 전달
• 조합 : parameter의 수에 따라 register or block method 사용

Types of System Calls 

• Process Control
• File management
• Device management
• Information maintenance
• Communications
• Protection

Process Control

• Program → 정상 end() / 비정상 abort()
• 정상/비정상적 상황에서 제어는 command interpreter로 무조건 전달
• process가 다른 program을 load() / excute()
• 프로세스 생성, 종료, 복제
• 생성된 프로세스의 실행 종료를 기다림
• 특정 시간만큼 기다림 (sleep)
• 특정 event를 기다리거나 일으킴 (signal)
• 메모리를 할당하거나 해제 (allocate)
• 공유 데이터 잠금/해제

Communication

proces 간 통식 방식

1. Message Passing Model
   
   • Mailbox를 통한 message 교환
   • connection 후 통신
   • 상대의 이름(id)을 알아야 통신 가능
   • 충돌이 없고 구현이 더 쉬움
2. shared-memory 
   • 공유 영역에 읽기/쓰기 함으로써 정보 교환
   • 동시에 같은 위치 기록 X
   • 컴퓨터 내에서 메모리 전송 속도로 수행하므로 속도가 빠르고 통신이 편리
   • process간 보호와 동기화에서의 문제 발생

Linkers and Loader

program은 disk 상에서 binary executable file로 저장되는데, 이런 program을 memory에 load한 후 process로 배치한다.

• compiler : source program → object file (소스 코드를 바이너리 코드로 변환)
• linker : object file → executable file (relocatable object file들을 연결하여 single binary executable file로 변환)
• loader : executable file → program in memory (executable file을 memory에 적재하는 역할)
• ./main : fork() 시스템 콜을 통해 새로운 process가 생성
• build : source program이 compiler와 linker를 거쳐 executable file이 되는 과정
• dll(dynamically linked libraries) : program 중에서 기본적으로 실행하지 않고 사용자가 요청할 때, 실행 중간에 동적으로 link되는데, 여러 process들이 DLL을 공유하여 메모리를 절약
• object file = 컴파일, 어셈블러를 통해 변환된 파일 (기계어), relocatable object file (ELF 포맷)

Why Applications Are Operating-System Specific

특정 OS에서 컴파일된 application은 다른 OS에서 실행이 불가능한데, 이는 OS가 고유의 system call을 제공하기 때문이다.

• interpreter 언어로 작성한다 (interpreter는 여러 OS에서 사용 가능)
  • 소스 프로그램의 각 line을 읽어서 상응하는 유사 기계어를 실행하고 OS call을 호출한다
  • 기계어로 구성된 것보다 성능이 떨어지고 intepreter가 OS의 일부 기능만 제공한다는 단점이 있다
• 가상 머신을 포함한 언어로 작성한다 (Java)
  • Java RTE는 java 응용을 java 가상 머신으로 load하기 위한 요소들을 포함한다
  • 이러한 RTE가 많은 IS에 이식되어 어떤 java 응용이던지 RTE 내에서 실행이 가능하다
  • 성능 저하 문제가 있다
• 표준 언어나 API를 사용한다
  • 어디서든 컴파일이 가능하다
  • 실행될 OS에서 port되어야 하기에 시간이 소요된다

Operating System Design and Implementation

Mechanisms and Policies (기법과 정책)

• Mechanism : 기법, 어떻게 할 것인가
• Poicies : 운영상 정책/수단, 무엇을 할 것인가

→ 기법과 정책을 분리함으로써 융통성이 생긴다. (여러 정책에서 사용될 수 있는 기법)

프로그램 유형에 따라 우선순위를 부여하는 기법과, 자원 할당 여부를 결정할 때마다 정책이 필요하다.

ex) CPU protecting의 경우 Timer mechanism을 사용하고 사용자 별로 타이머 시간을 다르게 설정하는 식으로 구현된다.

Operating System Structure

운영체제가 제대로 동작하고 쉽게 수정이 되도록하기 위해서 main 함수에 전체 코드를 넣는 대신 여러 함수로 로직을 분리해야 한다.

1) Monolitic Structure (Tightly coupled system)

• 커널의 모든 기능을 single, static binary 파일에 넣음
• 단일 주소 공간에서 실행됨
• 장점
  • 구조가 단순
  • 구현, 확장이 어려움
  • system-call interface에서 overhead가 거의 없고 kernel 내 통신이라 빠름 (한 번에 메모리로)
  • 속도/효율성 때문에 여전히 사용되는 구조
• ex) original unix os

• The Linux OS (UNIX 기반, 변형)

2) Layered Approach (Loosely coupled system)

• System이 개별적인 작은 요소들로 분리됨
• 모든 요소들이 kernel을 구성
• Module식 설계의 한 방법

• OS 계층은 data와 operation으로 구성되는 추상화 객체의 구현
• 상위 계층 M은 하위 계층의 연산(기능)을 호출함
• 계층 M은 상위 계층에서 호출되는 data/function으로 구성됨

• 장점 (construction과 debugging의 간편함)
  • Layer 0에서는 hardware가 정확하다고 가정했을 때 다른 부분은 신경 쓰지 않고 디버깅 가능
  • 단계별로 이전/하위 단계가 정확하게 동작한다고 가정
  • error 발견했다면 해당 층에서의 문제
  • 계층별로 이전/하위 계층에서 제공하는 연산이 어떻게 동작하는지는 몰라도 됨
  • 각 계층은 상위 계층에 특정 정보들을 숨김
• 단점 (Pure layered approach 방식의 OS는 잘 사용되지 않음)
  • 적절한 계층별 기능 정의의 어려움
  • 전체적 성능 저하

→ 계층을 줄여서 모듈화 코드의 장점을 제공하면서 문제점을 피하도록 함

3) Micorkernels

Smaller kernel(Mach) - Microkernel 접근 방식으로 커널을 모듈화함

• 중요하지 않은 요소는 커널에서 제거하고 별도의 주소 공간에 존재하는 user level program으로 구현
• 통신 기능 외에 최소한의 프로세스/메모리 관리 기능 제공
• Message passing 통한 간접적인 통신 제공
• 장점
  • OS 확장이 쉬움 - 새로운 service는 user space에 추가, kernel은 수정이 불필요
  • kernel에 대한 보안/신뢰성 제공 - 대부분의 service가 user process로 실행
• 단점
  • 가중된 시스템 기능 부하로 인한 성능 문제
  • 두 사용자 서비스 통신으로 서비스 간 메세지 복사 (독립된 주소 공간)
  • 메세지 교환을 위한 프로세스 간 전환(switch) 필요
  • 메세지 복사/프로세스 간 전환이 microkernel 기반 OS 성장에 장애가 됨

4) Modules → 현대적 OS 구현

Loadable kernel modules (LKMs)

• kernel은 핵심 요소들을 가지며, boot/run time시 추가 서비스들은 모듈로 연결한다
• kernel은 핵심 service를 제공하며 다른 service들은 kernel 실행 동안 동적으로 구현한다 (실행 중 변경 가능)

ex) CPU 스케줄링, 메모리 관리 -> kernel에 직접 구현 // 파일 시스템 지원 → LKM으로 구현

Layered system과 유사

• 각 kernel 영역이 defined, protected 인터페이스를 가짐
• 계층적 동작이 아닌 임의의 다른 모듈 호출 가능

Microkernel approach 유사

• 주 모듈이 핵심 기능을 가지며 다른 모듈을 적재하고 통신하는 방법을 안다
• mesage passing을 사용하지 않으므로 더 효율적이다

Linux

• 리눅스는 device driver, file system 지원을 위해 LKM을 사용한다
• LKM은 시스템 시작, 또는 실행 중에 kernel에 insert된다
• 필요한 driver가 없으면 동적으로 적재/제거 가능하다
• LKM을 허용하면서 monolithic system의 성능에서의 이점을 유지한다

본 포스팅은 공룡책으로 불리는 Abraham Silberschatz, Peter B. Galvin, Greg Gagne의 『Operating System Concept 10th』 기반으로 정리한 글입니다.

운영체제

• Operating system, 컴퓨터 하드웨어를 관리하는 소프트웨어
• 사용자가 편리하고 효율적으로 프로그램을 실행할 수 있는 환경을 제공

운영체제는 자동차부터 스마트폰, PC, 클라우드 컴퓨팅 환경까지 어느 곳에나 존재한다.

따라서 현대 컴퓨팅 환경에서 OS의 역할을 탐구하기 위해 먼저 컴퓨터 하드웨어의 구성과 구조를 이해하는 것이 중요하다.

필요 기반 지식으로 CPU, 메모리 및 I/O 장치, 저장장치가 포함된다.

컴퓨터 시스템

• 컴퓨터 : 정보를 처리하는 기계

정보

• 불확실성을 측정해서 수치적으로 표현한 것 l(X) = -log2P(X)
• 정보의 최소 단위 bit (binary digit)

What Operating Systems Do

컴퓨터 시스템의 네가지 구성 요소

• HW
• OS
• application program
• User

1) 하드웨어 HW

하드웨어는 중앙 처리 장치(CPU), 메모리 및 입출력(I/O) 장치로 구성되어 시스템의 기본 컴퓨팅 리소스를 제공한다.

2) 운영체제 OS

하드웨어 제어와 다양한 응용 프로그램 간의 하드웨어 사용을 제어하고 조정하는 역할을 한다.

3) 응용 프로그램 application program

응용 프로그램이란 워드 프로세서, 스프레드시트, 컴파일러, 웹 브라우저 등을 말하며 사용자의 계산 문제를 해결하기 위해 이들 자원이 어떻게 사용될지를 정의한다.

4) 사용자 User

사용자 관점에서의 운영체제

한 사용자가 리소스를 독점하도록 설계되어있다.

사용자가 수행하는 작업을 최대화하며, 대부분이 Resource utilization을 위해 설계된다.

컴퓨터에 대한 사용자의 관점은 인터페이스에 따라 달라진다.

시스템 관점에서의 운영체제

운영체제는 하드웨어와 가장 밀접하게 연관된 프로그램으로, 자원 할당자(resource allocator)로 볼 수 있다.

자원에 대해 서로 상충되는 많은 요청들이 있으므로 운영체제는 컴퓨터 시스템을 효율적이고 공정하게 운영할 수 있도록 어느 요청에 자원을 할당할 지를 결정해야 한다.

또한 제어프로그램으로도 볼 수 있다.

오류 및 부적절한 사용을 방지하기 위해 사용자 프로그램을 관리한다. 또한 I/O 장치의 작동 및 제어를 관리한다.

다시 한번 운영체제에 대한 정의를 내려보자.

일반적으로 운영체제에 대한 적합한 정의는 없다.

운영체제는 유용한 컴퓨팅 시스템을 만드는 문제를 해결할 수 있는 합리적인 방법을 제공하기 때문에 존재한다.

컴퓨팅 시스템의 기본 목표는 프로그램을 실행하고 사용자의 문제를 더욱 쉽게 해결할 수 있게 하는것인데, 하드웨어만으로는 쉽지 않으므로 응용 프로그램이 개발되는 것이다.

그런데 이러한 프로그램에는 입출력 장치 제어와 같은 특정 공통 작업이 필요하고, 이런 기능은 운영체제라는 하나의 소프트웨어로 통합된다.

보다 일반적인 정의는, 운영체제는 컴퓨터에서 항상 실행되는 프로그램이다.

일반적으로 커널이라고 한다.

컴퓨터 시스템의 구성 (Computer-System Organization)

현대의 범용 컴퓨터 시스템은 하나 이상의 CPU와 Device Controller로 구성되며 공유 메모리 사이 액세스를 제공하는 공통 버스를 통해 연결된 여러 장치 컨트롤러로 구성된다.

일반적인 컴퓨터 시스템 구성

• 구성 요소 (CPU, Device Controller)
  • 디바이스 컨트롤러 : 일부 로컬 버퍼 스토리지와 특수 목적 레지스터 집합을 유지, 관리
  • CPU와 디바이스 컨트롤러는 메모리 사이클에 대한 경쟁을 하며 병렬로 실행이 가능하다.
• 시스템 버스
  • 구성요소 <=> 공유 메모리
• 공유 메모리

• OS는 각 device controller(장치 측면)에 대해서 device driver(OS 측면)라는 장치 제어 프로그램을 가진다.
  • device controller는 local buffer storage와 refister의 집합을 가진다.
• CPU는 device controller를 통해 device에 I/O 명령을 내린다.
• device controller는 interrupt를 통해 CPU에게 실행이 끝났음을 알린다.

시스템 작동 방식 : 1) 인터럽트 -> 2) 스토리지 구조 -> 3) I/O 구조

인터럽트 (Interrupts)

인터럽트는 운영체제에서 하드웨어가 상호작용하는 방식의 핵심 부분이다.

CPU가 인터럽트되면 하던 일을 멈추고 즉시 서비스 루틴의 시작 주소로 이동한다. 이후 작업이 완료되면 CPU는 중단되었던 연산을 제거한다.

CPU와 I/O device가 통신하는 방법으로, HW는 언제나 interrupt trigger할 수 있다.

bus를 통해서 CPU에 신호를 전달한다,

I/O 작업 수행 방식

1. 디바이스 드라이버가 디바이스 컨트롤러에 적절한 레지스터를 로드한다.
2. 디바이스 컨트롤러는 레지스터의 내용을 검사하여 수행 작업을 결정한다.
3. 디바이스 컨트롤러는 장치에서 로컬 버퍼로 데이터 전송을 시작한다.
4. 데이터 전송이 완료되면 디바이스 컨트롤러는 디바이스 드라이버에게 작업이 완료되었음을 알린다. 이때 디바이스 컨트롤러에서 디바이스 드라이버에게 작업 완료를 알리는 역할을 하는 것이 인터럽트이다.
5. 이후 디바이스 드라이버는 읽으려는 데이터의 포인터 또는 상태 정보를 반환한다.

인터럽트 작동 방식

1. 인터럽트별 핸들러 호출
2. 포인터 테이블을 사용하여 인터럽트 루틴 진행
   • 속도 향상, 중간 과정 필요 X
   • 포인터 테이블: 인터럽트 서비스 루틴의 주소 보유
3. 인터럽트 벡터(테이블) - 인터럽트 요청 번호 인덱싱
4. 인터럽트 핸들러 루틴으로 이동
5. 해당 인덱스 주소에서 서비스 시작
   • 이때 인터럽트 핸들러는 작동 중의 모든 상태 저장 → 처리 수행 → 상태 복원 수행
6. 작업이 모두 완료되면 복귀 명령을 실행하여 CPU를 인터럽트 실행 이전 상태로 복원

인터럽트 아키텍처는 인터럽트 처리 전 상태로 복원할 수 있도록 인터럽트된 상태 정보를 저장한다.

이후, 인터럽트가 서비스된 후 이전 리턴 주소로 돌아가 인터럽트가 발생하지 않은 것처럼 복원하고 이전의 연산을 재개한다.

Storage Structure

커널은 실행기(Executor)를 통해 프로그램을 실행시킨다. 실행기는 기억장치(Storage)에서 exe파일(Windows의 경우)을 가져오고, 커널이 이것을 메모리에 할당해 실행시킨다.

즉, 모든 program은 반드시 main memory에 올라야만 실행될 수 있다. 하지만 main memory는 DRAM으로 구현하여 휘발성이고 용량이 작기 때문에 별도의 저장장치가 필요하다.

현대 컴퓨터 시스템은 기본적으로 폰 노이만 구조를 따른다.

폰노이만 아키텍처 (von Neumann architecture)

• 전형적인 시작-실행 사이클
  • fetch & execute
• 메모리에서 명령어 레지스터, 데이터 레지스터 사용
  • instruction register

Storage Hierarchy

• storage system은 여러개의 hierarchy로 구성
  • 용량과 속도에 따라 계층 구조 구성
  • registers - cache - main memory - ssd (solid-state disk) - HDD (hard disk) - optical disk - magnetic tapes (백업!)

Computer-System Architecture

• core : 명령어 실행, 데이터 local 저장하는 요소 (register를 가짐)
• main CPU with core : 범용 명령어 셋을 실행

Computer System Component

• CPU
• Processor
• Core
• MultiCore
• MultiProcessor

Single-Processor Systems

• 하나의 CPU(core 1개)를 갖는 시스템

Multi-Processor Systems (parallel system, tightly-coupled system)

• 여러 개의 Single-core CPU를 갖는 시스템
• processor들은 computer bus, clock, memory, peripheral device 등을 공유한다.
• throughput 증가 (processor 수와 성능이 정비례하지는 않음)
• Economy of Scale(규모의 경제 - 여러 개의 단일 시스템에 비해 비용 절약)
• Increased Reliability(증가된 신뢰성 - 어느 구성 요소의 고장에도 불구하고 동작을 계속할 수 있기에 우아한 퇴보를 넘어 결함 허용이라고 불림)

1) Asymmetric MultiProcessing (AMP) - 각 processor에 특정 작업이 할당

• 서로 다른 칩에 각각 CPU가 있는 구조
• processor가 실행하는 task가 구분됨
• core 간 기능 차이가 있음

2) Symmetric multiprocessing (SMP) - 각 processor가 모든 작업 수행

• 메모리 하나에 각각 연결된 CPU가 각각의 register와 cache 가지고 task 수행
• 서로 다른 칩에 각각 CPU가 있는 구조
• processor가 실행하는 task 구분이 없으며 core 간 기능 차이가 없음

Multi-core systems - 하나의 CPU에 여러 core를 넣음, 진화된 구조

• 여러 core들이 한 chip에 있는 구조
• 한 칩에서 CPU core끼리 통신하기에 칩 사이 통신보다 훨씬 빠름
• power를 적게 쓰며 각 core는 자신의 register set과 local cache를 가짐

이러한 multi-processor system에서 CPU를 추가한다면 분명 성능이 향상될 수 있지만 확장성은 떨어지게 된다.

또한 너무 많은 CPU를 추가하는 경우 system bus에 대한 경쟁을 초래하여 성능 저하로 이어진다.

Clustered Systems

multiple-processor와 비슷하나 아래와 같은 차이점이 있다.

• node(individual systems)들로 구성된다.
• 각 node들은 multicore system으로, 느슨하게 연결된다.
• storage를 공유하고 LAN이나 faster interconnect를 통해 연결된다.

즉, 멀티프로세서 시스템은 여러 CPU가 하나의 시스템을 이루는 것이지만, 클러스터 시스템은 여러 독립적인 시스템(node)들이 모여 하나의 시스템을 이루는 것이다.

• asymmetric clustering : node들의 기능이 비대칭, 한 machine은 hot-standby mode (모니터링만 하고 대기중). 나머지가 사용됨
• sysmmetric clustering : node들의 기능이 대칭, 서로 모니터링하고 노는 node없이 모두 사용됨

다음과 같은 특징이 있다.

• high-availabilty service : 한 node가 고장나도 나머지가 정상 작동
• high-performance computing environments : 한 어플리케이션이 클러스터 내 모든 컴퓨터에서 병렬 실행, 작업 분배 → 컴퓨팅 파워가 훨씬 좋다.
• reliability : 안정성이 높다. graceful degradation(연속적인 서비스 제공), fault tilerant(failure에도 불구하고 계속 동작 가능)

Operating-System Operations

Initial program (Bootstrap program)

• 컴퓨터 전원 키면서 실행되는 첫 프로그램
• OS를 메모리에 로딩하는 프로그램

컴퓨터를 실행하기 위해 초기 프로그램인 bootstrap program 실행해야 한다.

비휘발성인 firmware로 HW에 저장되어 부팅 시 실행된다.

• 시스템을 초기화시킨다 (CPU register, device controller, memory contents)
• OS 커널을 찾아 메모리에 로드한다.
• 커널이 로드되어 실행되면 시스템과 사용자에게 서비스를 제공한다. "systemd"라는 프로그램은 리눅스에서 가장 먼저 실행되며, 다른 daemon을 시작한다.

이벤트의 처리 Events

이벤트는 interrupt를 발생시켜 신호를 보낸다.

• Hardware interrupt : device에서 발생
• Trap or Exception : software error, system call (CPU의 도움이 필요한 경우 OS 필요)

Multiprogramming and Multitasking

프로그램은 단순히 저장 장치에 저장된 파일에 불과하며 이러한 프로그램이 메모리에 올라와 실행되면 그것을 프로세스라 부른다.

Multiprogramming

• 여러 프로그램을 메모리에 로드해두고 한 프로세스가 대기 상태가 되면 다른 프로세스의 작업을 수행하는 시스템
• 한 개 이상 프로그램이 실행
• 여러 메모리가 동시에 올라가 있음 → CPU 활용 증가

Multitasking (=multiprocessing)

• multiprogramming의 논리적 확장
• 하나의 CPU를 가지고 여러 프로세스 돌리기
• CPU scheduling
  • CPU 효율 제일 좋게 만들도록 고려
  • 어떤 CPU를 다음으로 돌릴까 switch하며 작업
• 다음과 같은 기능 필요
  • memory management : 여러 process들이 동시에 memory에 접근해서는 안됨
  • CPU scheduling : 어떤 작업을 먼저 처리할 지 결정해야 함
  • process scheduling, disk storage and memory management : 여러 process들을 동시에 실행시키기 위해 서로 영향을 미치는 기능을 제한해야 함

Dual-mode and Multimode Operation

악의적으로 사용자가 OS 코드를 멋대로 수정하는 경우 문제를 방지하기 위해 다른 프로그램이 잘못 실행되지 않도록 해야한다.

그래서 나온 것이 Dual mode로, 실행 모드를 구별하여 권한을 달리 하는 것이다.

• user mode (1)
• kernel mode (0) (= supervisor mode, system mode, privileged mode)

node의 전환은 system call에 의해 이뤄진다.

• user application이 OS에 service 요청
• system은 반드시 user mode에서 kernel mode로 전환해야 함

Timer

• 특정 시간이 지난 후 interrupt가 발생하도록 설정
• 사용자 프로그램이 무한 루프나 system service 호출에 실패하여 제어가 OS로 넘어가지 않는 경우 방지

Process Management

• program은 하나지만 procss는 여러 개일 수 있음
• process는 순차적으로 수행
• 한 번에 하나의 명령만 수행
• process가 병행 실행되도록 서브 process들을 생성하는 system call 제공

Program counter

process는 program이 어디까지 실행되었는지 북마크하는 program counter를 가지고 있다.

• Single-thread process : 하나의 program counter 가짐
• Multi-thread process : 여러 개의 program counter 가짐

Memory Management

Main memory는 매우 커다란 byte의 배열이며, 각 byte에는 주소가 있다.

CPU는 instruction-fetch cycle 동안 main memory에 올라온 명령어들을 읽는다.

그리고 data-fetch cycle 동안 main memory에 데이터를 읽거나 쓴다.

→ 명령어(Instruction)들은 반드시 CPU에 의해 실행되기 전 memory에 load되어야 한다.

Program 실행 과정

• program이 실행될 때 절대 주소로 mapping되고 memory로 load되어야 한다.
• program이 실행되면서 memory의 명령어와 데이터에 접근한다.
• program이 끝나면 memory 공간이 사용 가능함을 공표하고 다음 program이 load되고 실행된다.

Cache Management

Cache는 매우 빠르고 작은 저장 장치이며, Caching은 cachce memory를 이용해 컴퓨터 속도를 높이는 기술이다.

cache에 자주 사용되는 data를 미리 담아두고 CPU나 disk가 cache의 data를 참조할 수 있도록 한다.

데이터는 사용되면서 cache에 일시적으로 저장됨

• 특정 데이터 필요 시 cache를 먼저 확인
• size에 제약이 있어 관리가 필요
• 파일의 중복성이 증가하지만 속도 역시 증가함
• 지역성(Locality) 원리를 사용 → 시간지역성은 한 번 접근한 데이터에 다시 접근할 확률이 높다는 것이고, 공간지역성은 특정 데이터와 가까운 메모리 주소에 있는 다른 데이터에도 접근할 가능성이 높다는 것이다.

최근에 erd 설계를 (오랜만에) 하게 되면서 createdAt, updatedAt에 쓰이는 type에 관해 고민이 생겼다.

지금껏 datetime으로 해놨었는데, datetime 외에도 timestamp와 같이 시간을 기록할 수 있는 컬럼에 관해 표현할 수 있는 type은 다양하다.

오늘은 시간 관련 type에 대해 알아보고, 이를 적재적소 어떻게 쓰는지 알아볼 예정이다!

TIME

time 타입은 HH:MM:SS로 시간에 대한 정보를 담는 타입이다.

time이 가질 수 있는 값의 범위는 -838:59:59 ~ 838:59:59이다.

여기서 시간은 날짜 중에 day의 값을 표현할 수 있는 범위까지이기에 838시간이라는 큰 시간까지 포함이 가능하다.

TIMESTAMP

timestamp 타입은 날짜, 시간 모두 포함한 타입이다.

범위로는 1970-01-01 00:00:01 ~ 2038-01-19 03:14:07 UTC까지 표현할 수 있다.

DATE

date 타입은 날짜는 포함하지만 시간은 포함하지 않을 때 사용하는 타입이다.

YYYY-MM-DD 형식으로 입력이 가능하며, '1000-01-01'부터 '9999-12-31'까지만 입력 가능하다.

DATETIME 타입

datetime 타입은 날짜와 시간 모두 포함할 때 사용하는 타입이다.

YYYY-MM-DD HH:MM:SS 형식으로 '1000-01-01 00:00:00'부터 '9999-12-31 23:59:59'까지 입력 가능하다.

TIMESTAMP vs DATETIME

1. 타입

TIMESTAMP는 숫자형, DATETIME은 문자형이다

2. 용량

TIMESTAMP는 4byte, DATETIME은 8byte이다.

3. 입력

TIMESTAMP는 데이터값을 입력해주지 않고 저장시 자동으로 현재 날짜가 입력된다. (Default Insert (AUTO))

DATETIME은 데이터값을 입력해주어야만 날짜가 입력된다. (명시적 INSERT)

TIMESTAMP의 경우 Timezone을 적용해서 보여준다.

Timezone
타임존은 동일한 로컬 시간을 따르는 지역을 의미하며, 해당 국가에 의해 법적으로 지정된다.

DATE와 DATETIME의 경우 범위가 거의 같지만 TIMESTAMP의 경우 다르기에 사용할 때 목적에 따라 명확히 구분해서 사용해야한다!

요즘 프로젝트하면서 erd 설계를 하고 있는데, 테이블 연관관계와 정규화에 대해 더 알고 싶어 블로그에 기록하게 되었다!

정규화에 대해 알아보자.

정규화

이상현상이 있는 릴레이션을 분해하여 이상현상을 없애는 과정, 이로써 여러 개의 릴레이션을 생성하게 된다.
이를 단계별로 구분하여 정규형이 높아질 수록 이상현상은 줄어든다.

여러 엔티티의 속성을 혼합하면 정보가 중복 저장된다. 정규화의 기본 목표는 테이블 간 중복된 데이터를 허용하지 않는다.

이러한 테이블을 분해하는 정규화 단계가 정의되어 있는데 여기서 테이블을 어떻게 분해하는지에 따라 정규화 단계가 달라진다.

그 전에, 이상현상과 함수 종속성에 대해 짚고 넘어가자.

이상현상

• 삽입 이상 (Insertion Anomaly) : 튜플 삽입 시 특정 속성에 해당하는 값이 없어 NULL을 입력해야 하는 현상
• 삭제 이상 (Deletion Anomaly) : 튜플 삭제 시 같이 저장된 다른 정보까지 연쇄적으로 삭제되는 현상
• 갱신 이상 (Update Anomaly) : 튜플 갱신 시 중복된 데이터의 일부만 갱신되어 일어나는 데이터 불일치 현상

위와 같은 테이블을 예로 들어보자.

1) 삽입 이상

 만약 강의를 수강하지 않은 학생을 추가할 때 과목 번호와 성적에 null 값이 들어가거나 불필요한 데이터를 추가해야 삽입할 수 있는 문제점이 발생한다. 아래와 같은 데이터를 삽입할 수 없다.

학생이 수강신청 할 때 반드시 과목 번호를 알아야 삽입이 가능하다.

2) 삭제 이상

학번이 345인 학생이 수강 신청한 과목을 취소하면 해당 강의에 대한 정보 모두 삭제된다.

가 교수가 강의하는 과목을 취소하는 경우 해당 강의를 듣는 학생에 대한 정보 모두 삭제된다.

3) 갱신 이상

학번이 123인 학생의 지도교수가 라로 변경되면, 이 학생이 수강하는 모든 과목 (행)에서의 지도 교수를 변경시켜줘야 한다.

함수 종속성 (Functional Dependency)

• 어떤 속성 A의 값을 알면 다른 속성 B의 값이 유일하게 정해지는 관계
• A -> B로 표기하며 A를 B의 결정자(Determinant)라고 한다.
• A -> B이면 A는 B를 결정한다(Determine) 한다고 하고, B는 A에 종속한다(Dependent)라고 한다.

함수 종속성은 크게 세 가지로 나뉜다.

1) 완전 함수 종속 : 기본키를 구성하는 모든 속성에 종속되는 경우

2) 부분 함수 종속 : 기본키를 구성하는 속성의 일부에 종속되거나, 기본키가 아닌 다른 속성에 종속되는 경우

3) 이행적 함수 종속 : A, B, C 세 속성이 있고, A -> B, B -> C 종속 관계가 있을 때 A -> C가 성립하는 경우

위와 같은 테이블이 있다고 하자.

여러 학생들이 있고 각 학생별로 여러 과목을 수강한다고 하면 위 테이블의 기본 키는 (학번, 과목번호)이다.

그렇다면 이름과 학년은 학번만 알아도 유일하게 결정된다.

반면에 성적은 학번과 과목 번호를 모두 알아야 유일하게 결정된다.

따라서 이름과 학년은 (학번, 과목번호)에 대해 부분 함수 종속이고, 성적은 완전 함수 종속이다.

이렇게 엔티티를 구성하는 속성간의 함수 종속성을 판단하여 좋은 릴레이션인지 알 수 있다.

제1 정규형 (1NF)

제1 정규형은 다음과 같은 규칙들을 만족해야 한다.

1. 각 컬럼이 하나의 속성만을 가져야 한다.
2. 하나의 컬럼은 같은 종류나 타입(type)의 값을 가져야 한다.
3. 각 컬럼이 유일한(unique) 이름을 가져야 한다.
4. 칼럼의 순서가 상관없어야 한다.

상단의 테이블을 보면 '나'는 여러 개의 취미를 갖고 있으므로 제1 정규형을 만족하지 못한다. 그렇기에 제1 정규화하여 분해할 수 있다.

제2 정규형 (2NF)

제2 정규형은 다음과 같은 규칙을 만족해야 한다.

1. 제1 정규형을 만족해야 한다.
2. 모든 컬럼이 부분적 종속(Partial Dependency)이 없어야 한다. 즉 모든 칼럼이 완전 함수 종속을 만족해야 한다.

부분적 종속이란 기본키 중 특정 컬럼에만 종속되는 것이다. 제1 정규화를 진행한 테이블에 대해 완전 함수 종속을 만족하도록 테이블을 분해하는 것이다.

즉 기본키의 부분집합이 결정자가 되어선 안된다는 것이다.

이 테이블의 기본 키는 (학번, 강좌 이름)로 복합키이다. 그리고 (학번, 강좌 이름)인 기본 키는 성적을 결정하고 있다.

(학번, 강좌이름) -> (성적)

여기서 강의실 컬럼은 기본키의 부분집합인 강좌이름에 의해 결정될 수 있다.

(강좌이름) -> (강의실)

즉, 기본키(학번, 강좌이름)의 부분키인 강좌이름이 결정자이기 때문에 위의 테이블의 경우 다음과 같이 기존의 테이블에서 강의실을 분해하여 별도의 테이블로 관리하여 제2 정규형을 만족시킬 수 있다.

제3 정규화 (3NF)

제3 정규형은 다음과 같은 규칙을 만족해야 한다.

1. 제2 정규형을 만족해야 한다.
2. 기본키를 제외한 속성들 간의 이행 종속성 (Transitive Dependency)이 없어야 한다.

여기서 이행적 종속이라는 것은 A -> B, B -> C가 성립할 때 A -> C가 성립되는 것을 의미한다.
예를 들어 아래와 같은 계절 학기 테이블을 살펴보자. 

기존의 테이블에서 학번은 강좌 이름을 결정하고 있고, 강좌 이름은 수강료를 결정하고 있다.

그렇기 때문에 이를 (학생 번호, 강좌 이름) 테이블과 (강좌 이름, 수강료) 테이블로 분해해야 한다.

BCNF (Boyce-Codd Normal Form)

BCNF는 제 3정규형을 좀 더 강화한 버전으로 다음과 같은 규칙을 만족해야 한다.

1. 3정규형을 만족해야 한다.
2. 모든 결정자가 후보키 집합에 속해야 한다.

예를 들어 다음과 같은 특강수강 테이블이 존재한다고 하자.

특강수강 테이블에서 기본키는 (학번, 특강이름)이다. 그리고 기본키 (학번, 특강이름)는 교수를 결정하고 있다. 또한 여기서 교수는 특강이름을 결정하고 있다.
그런데 문제는 교수가 특강이름을 결정하는 결정자이지만 후보키가 아니다.

이처럼 후보키 집합이 아닌 칼럼이 결정자가 되어버린 상황을 BCNF를 만족하지 않는다고 한다.

(참고로 위 테이블은 제3 정규형까지는 만족하는 테이블이다 )

그렇기 때문에 BCNF 정규화를 만족시키기 위해서 위의 테이블을 (학번, 특강이름), (특강이름, 교수) 테이블로 분해해야 한다.

정규화 장단점

장점

• 데이터베이스 변경 시 각종 이상 현상들이 발생하는 문제점을 해결할 수 있다.
• 데이터베이스 구조 확장 시 정규화된 데이터베이스 구조에서는 새로운 데이터 형의 추가로 인한 확장 시, 그 구조를 변경하지 않아도 되거나 일부만 변경해도 된다. 이는 데이터베이스와 연동된 응용 프로그램에 최소한의 영향만을 미치게 되며 응용프로그램의 생명을 연장시킨다.
• 사용자에게 데이터 모델을 더욱 의미있게 제공
• 정규화된 테이블들과 정규화된 테이블들간의 관계들은 현실 세계에서의 개념들과 그들간의 관계들을 반영

단점

• 릴레이션의 분해로 인해 릴레이션 간의 연산(JOIN 연산) 증가되어 질의에 대한 응답 시간이 느려질 수 있다.

정규화를 수행한다는 것은 데이터를 결정하는 결정자에 의해 함수적 종속을 가지고 있는 일반 속성을 의존자로 하여 입력/수정/삭제 이상을 제거하는 것이다. 데이터의 중복 속성을 제거하고 결정자에 의해 동일한 의미의 일반 속성이 하나의 테이블로 집약되므로 한 테이블의 데이터 용량이 최소화되는 효과가 있다.

따라서 정규화된 테이블은 데이터를 처리할 때 속도가 빨라질 수도 있고 느려질 수도 있는 특성이 있다.

조회를 하는 SQL 문장에서 조인이 많이 발생하여 이로 인한 성능저하가 나타나는 경우에 반정규화 적용이 필요하다.

반정규화(De-normalization, 비정규화)

데이터베이스의 성능 향상을 위하여, 데이터 중복을 허용하고 조인을 줄이는 데이터베이스 성능 향상 방법이다.

반정규화는 조회(select) 속도를 향상시키지만, 데이터 모델의 유연성은 낮아진다.

반정규화의 대상

• 정규화에 충실하여 종속성, 활용성은 향상 되었지만 수행속도가 느려진 경우
• 다량의 범위를 자주 처리해야하는 경우
• 특정 범위의 데이터만 자주 처리하는 경우
• 요약/집계 정보가 자주 요구되는 경우
• 테이블에 지나치게 조인을 많이 사용하게 되어 데이터를 조회하는 것이 기술적으로 어려울 경우

반정규화 기법

계산된 컬럼 추가
배치 프로그램으로 총판매액, 평균잔고, 계좌평가를 미리 계산하고 그 결과를 특정 칼럼에 추가한다.

테이블 수직 분할
하나의 테이블의 두 개 이상의 테이블로 분할한다. 즉, 칼럼을 분할하여 새로운 테이블을 만드는 것이다.

테이블 수평분할
하나의 테이블에 있는 값을 기준으로 테이블을 분할하는 방법이다.

반정규화 주의사항

 반정규화를 과도하게 적용하다 보면 데이터의 무결성이 깨질 수 있다.

 또한 입력, 수정, 삭제의 질의문에 대한 응답 시간이 늦어질 수 있다.

레퍼런스
https://rebro.kr/159
https://mangkyu.tistory.com/110
https://github.com/JaeYeopHan/Interview_Question_for_Beginner/tree/master/Database#%EC%A0%95%EA%B7%9C%ED%99%94%EC%97%90-%EB%8C%80%ED%95%B4%EC%84%9C
https://code-lab1.tistory.com/48

흔히 백엔드 개발자들이 사용하는 MySQL이라 부르는 것은 MySQL 서버라고 부를 수 있다.

MySQL 서버는 두뇌 역할을 하는 MySQL 실행 엔진이 있고, 손 발 역할을 하는 스토리지 엔진으로 구성된다.

이 둘은 핸들러 API를 통해 서로 통신을 주고 받는다.

쿼리의 실행 과정을 통해 아키텍처에 대해 알아보자.

간단한 join문으로 구성된 쿼리문을 실행한다.

select u.userIdx, u.userName, b.buyList from Buy
	left join User as u on u.userIdx = b.userIdx

1. 쿼리 파서 (Parser)

사용자가 SQL 쿼리문을 날리게 되면 쿼리 파서가 요청을 수행한다.

이 쿼리 파서는 SQL 문장을 트리의 형태로 파싱한다.

이 트리 안에 있는 각각의 요소는 MySQL이 인지할 수 있는 최소한의 단위인 Token으로 파싱이 된다.

SQL 문법 오류 여부를 확인하고 예외가 있다면 예외 메세지를 반환한다.

2. 전처리기 (PreProcessor)

다음으로 전처리기에 파서 트리 데이터가 전달된다.

전처리기는 예약어를 제외한 Token을 검사해서 데이터베이스에 실제로 객체가 존재하는지, 실제로 그 객체에 사용자가 접근할 수 있는지 권한을 검증한다.

3. 옵티마이저 (QueryOptimizer)

전처리기에서 수행된 데이터를 바탕으로 옵티마이저에게 전달한다.

옵티마이저는 파서 트리를 실행 계획으로 바꾸는 역할을 한다. 가장 효율적인 방법으로 SQL을 수행할 최적의 처리 경로를 생성해주는 것을 목적으로 한다.

1. 데이터 접근 방법 결정
2. join 등 쿼리 재작성 및 실행
3. 테이블 접근/스캔 순서 결정하여 사용할 인덱스 선택

이런 옵티마이저는 크게 두 종류로 구분할 수 있다.

비용 기반 최적화와 규칙 기반 최적화로 나눌 수 있는데 전자는 MySQL에 존재하는 다양한 통계 정보를 활용해 수행 계획을 수립, 후자는 동일한 SQL이면 항상 동일한 SQL 실행 계획을 수립하는 것이다.

MySQL 포함한 대부분의 RDBMS는 비용 기반 최적화로 진행된다.

비용 기반 최적화

SQL문을 처리하는데 필요 비용이 가장 적은 실행 계획을 선택하는 방식이다. 

비용이란 SQL문을 처리하기 위해 예상되는 소유시간 또는 자원 사용량을 의미하며 비용 기반 최적화는 테이블, 인덱스, 칼럼 등의 다양한 객체 통계정보와 시스템 통계정보 등을 이용한다.

비용기반은 통계정보가 없는 경우 불확실한 실행계획을 생성 할 수 있으므로 정확한 통계정보를 유지하는 것이 중요하다.

# 통계 정보란? (MySQL)
 대략의 레코드 건수와 인덱스의 유니크한 값의 개수. 벤더마다 약간씩 차이가 있다.
 Memory 테이블은 별도 통계 정보가 없으며, MyISAM과 InnoDB의 테이블과 인덱스 통계 정보는 아래와 같이 확인 할 수 있다.

SHOW TABLE STATUS LIKE 'user_ldap_list';
SHOW INDEX FROM user_ldap_list;

# 통계정보 수집시 고려사항

• 시간 : 시스템 부하가 적은 날짜와 시간을 산정해 수집
• 샘플 크기 : 데이터베이스와 세그먼트의 크기에 비례해 일정 부분만 추출
• 정확성 : 오브젝트의 데이터와 통계정보의 데이터가 근접해야 함
• 안정성 : 통계정보 수집으로 인한 데이터베이스 성능 저하를 최소화해야 함

# 실행 계획이란?
SQL에서 요구한 사항을 처리하기 위한 절차와 방법
실행계획에서 표시되는 내용 및 형태는 벤더마다 약간 차이는 있지만 실행계획이 SQL 처리를 위한 절차와 방법을 의미한다는 기본적인 사항은 모두 동일하다.

실행 계획은 여러 단계로 이뤄져 있는데 (스텝) 각각 스텝에서 어떤 명령이 수행되었고 몇 건의 데이터가 처리되었으며 얼마만큼의 비용과 시간이 소요되었는지를 표시한다.

규칙 기반 최적화

우선순위가 높은 규칙이 적은 일량으로 해당 작업을 수행하는 방법이다.

규칙 기반 최적화 옵티마이저가 실행계획을 생성할 때 참조하는 정보에는 SQL문을 실행하기 위해서 이용 가능한 인덱스 유무와 (유일, 비유일, 단일, 복합 인덱스) 종류, SQL문 에서 사용하는 연산자(=, <, <>, LIKE, BETWEEN 등)의 종류 그리고 SQL문에서 참조하는 객체(힙, 테이블, 클러스터 테이블 등)의 종류 등이 있다.

규칙 기반은 인덱스를 이용한 액세스 방식이 전체 테이블 액세스 방식보다 우선순위가 높으므로 이용 가능한 인덱스가 존재하다면 항상 인덱스를 사용하는 실행계획을 생성하게된다. join 순서를 결정할 때는 join 컬럼 인덱스의 존재 유무가 중요한 판단기준이다.

규칙 기반은 정해진 규칙에 따라 만들어졌을때 BETWEEN 의 현실적인 데이터의 건수 등을 측정을 예측하지못한다.

4. 실행 엔진 (Query Executioin Engine)

다음으로 실행 엔진이다.

옵티마이저에서의 실행계획은 실행 엔진으로 전달되어 스토리지 엔진과 통신을 하여 데이터를 읽어오는 작업을 수행한다.

스토리지 엔진은 실행 엔진의 요청을 처리하기 위한 디스크로부터 데이터를 읽고 쓰는 작업을 한다. 실행 계획대로 각 핸들러에게 요청해서 받은 결과를 또 다른 핸들러 요청의 입력으로 연결하는 역할을 수행한다.

MySQL엔진과 다르게 여러개를 동시에 사용할 수 있다.

5. 핸들러(Storage Engine)

핸들러는 MySql 서버의 가장 밑단에서 MySql 실행 엔진의 요청에 따라 데이터를 디스크로 저장하고 디스크로부터 읽어오는 역할을 담당한다. 스토리지 엔진을 의미한다.

MySQL 엔진은 SQL interface, Parser, Preprocessor, Optimizer, Cache와 Buffer로 구성된다.

InnoDB 스토리지 엔진은 Transaction, Buffer pool, Clustering index, MVCC, Foreign key, Deadlock 감지 등이 있다.

MySQL 8.0 이후로부터 InnoDB 스토리지 엔진을 기본 엔진으로 사용하고 트랜잭션을 제공한다.

* InnoDB 스토리지 엔진

InnoDB 엔진(버퍼 풀, Undo log)과 디스크로 구성된다.

Set GLOBAL TRANSACTION ISOLATION
LEVEL REPEATABLE READ;

상단과 같이 트랜잭션 레벨을 repeatable read로 설정하고 insert문을 활용하여 데이터를 삽입하면 버퍼풀과 디스크에 해당 데이터가 같이 들어간 것을 확인할 수 있다. 이는 버퍼풀이 디스크의 데이터값을 캐싱했다는 것으로 확인할 수 있다.

다음으로 삽입한 데이터를 수정하고 커밋하면, 업데이트한 데이터가 버퍼풀에 반영이 되었고 이전의 데이터는 Undo Log에 추가된다.

디스크에 있는 데이터는 버퍼풀에서 쓰기 작업이 지연되고 있는 상태라면 이전의 데이터로 기록이 되고, 쓰기 작업이 일괄적으로 처리된 상태라면 업데이트된 데이터가 기록된다.

Undo Log에 있는 트랜잭션 Id가 있는데, 이는 실행한 트랜잭션의 id를 의미한다. (순차적으로 증가한다)

버퍼풀

버퍼풀은 데이터 캐싱하고 버퍼링시켜서 데이터를 읽고 쓰는 작업을 빠르게 한다.

MVCC (트랜잭션 동시성을 제어하는 방법)

• 하나의 레코드에 대해 여러 개의 버전을 관리 (트랜잭션 id)
• 잠금 없는 일관된 읽기를 제공한다.

-> MVCC, 정렬 처리방식, 복제는 다음 포스팅에서 더 다뤄보기!!

참고
- https://velog.io/@zerodin/%EC%98%B5%ED%8B%B0%EB%A7%88%EC%9D%B4%EC%A0%80%EC%99%80-%EC%8B%A4%ED%96%89%EA%B3%84%ED%9A%8D
- https://youtu.be/8PRkLItDwXQ

오늘 인텔리제이로 작업하다가 

Caused by: java.net.SocketTimeoutException: connect timed out

라는 에러가 떠서, 관련 CS 지식 타임아웃에 대해 정리해보려고 한다.

스프링부트 API 제작 후 빌드해서 테스트하려고 하는데 직전까지만 해도 잘 돌아가던 빌드가 왜 안되었을까?

.

.

인줄 알았으나 그냥 경고 표시였다.

이번 기회에 타임아웃에 대해 제대로 알고 가보자.

서버 간 통신이 많아지는 MSA 구조가 주목받으면서 내부 시스템 안에서도 서로 클라이언트와 서버가 되어 데이터를 주고 받는 비중이 점점 커지고 있다. 이런 상황에서 통신을 요청하는 클라이언트는 다양한 Timeout 오류를 만날 수 있는데, 이런 Timeout에 대한 종류를 잘 구별한다면 각각의 상황에 따라 구분해서 처리할 수 있다. 

타임아웃

• 프로그램이 특정한 시간 내 성공적으로 수행되지 않아 진행이 자동적으로 중단되는 것
• 응답을 무한정 기다릴 수 없기 때문에 기다릴 시간을 정해야 함

타임아웃 사례

• Socket(양방향 통신), Http(단방향 통신)에서 다양하게 활용
• JDBC
  • JDBC Driver Type4는 소켓을 사용하여 DBMS에 연결하는 방식
  • Connection Timeout : DB 커넥션 요청을 했으나, 특정 시간 내 연결이 안될 때
• 채팅 프로그램
  • Socket Timeout : 채팅 프로그램에서 서버로부터 특정 시간 응답이 없을 때
• WEB
  • Connection Timeout : 클라이언트에서 서버로 request를 날렸을 때 연결되지 않은 상태로 특정시간 이상 대기

관련 패키지

• java.net
• HttpClient

1) java.net 패키지

• 네트워킹 응용 프로그램을 구현하기 위한 클래스를 제공하는 패키지
• java.net 패키지는 크게 두 섹션으로 나뉨
  • 저수준 API
    • Addresses : 네트워크 식별자 ex) IP 주소
    • Sockets : 기본 양방향 데이터 통신 메카니즘
    • Interfaces : 네트워크 인터페이스
  • 고수준 API
    • URIs : Universal Resource Identifiers
    • URLs : Universal Resource Locators
    • Connections : URL이 가리키는 리소스에 대한 연결

java.net 패키지에서 제공하는 4개의 socket

• Socket : TCP 클라이언트 API, 일반적으로 원격 호스트에 연결하는 데 사용됨
• ServerSocket : TCP 서버 API, 일반적으로 클라이언트 소켓의 연결 허용
• DatagramSocket : UDP 엔드포인트 API, datagram 패킷을 주고 받는데 사용
• MulticastSocket : multicast 그룹을 처리하는 DatagramSocket의 하위클래스
• TCP 소켓을 통한 송수신 -> Socket.getInputStream() 메소드 및 Socket.getOutputStream()메소드를 통해 얻을 수 있는 InputStreams 및 OutputStreams를 통해 수행됨

* Socket 관련 Timeout

1. Connection Timeout
2. Socket Timeout / Read Timeout

1. Connection Timeout

• 클라이언트가 서버측으로 Connection을 맺길 원하지만 서버의 장애 상황으로 맺어지지 못할 때 발생하는 timeout
• 이 경우에는 서버에 접근이 안되는 경우라서 클라이언트는 서버의 장애 상황으로 간주할 수 있음. 보통 이 경우에 클라이언트는 일시적인 오류 상황으로 구분하여 처리를 하거나 미리 정의된 dafault 데이터나 cache 데이터로 fallback 처리하기도 함.
• Connection 과정
  • TCP 소켓 통신에서 클라이언트와 서버가 연결될 때 정확한 전송을 보장하기 위해 상대방 컴퓨터와 사전에 세션을 수립함. (3-way handshake)
  • 3-way handshake가 정상적으로 끝나야 Connection이 됐다고 표현할 수 있음. 즉, Connection Timeout이란 3-way HandShake가 정상적으로 수행되어 서버에 연결되기까지 소요된 시간임.
• TCP 3-way HandShake 절차
  • 1) 클라이언트 A 는 B 서버에 접속을 요청하는 SYN 패킷을 보냄. 이때 A는 SYN을 보내고 SYN/ACK 응답을 기다리는 SYN_SENT 상태가 됨
  • 2) B 서버는 SYN 요청을 받고 A에게 요청을 수락한다는 ACK와 SYN flag가 설정된 패킷을 발송하고 A가 다시 ACK으로 응답하길 기다린다. 이때 B 서버는 SYN_RECEIVED 상태가 됨
  • 3) A는 B에게 ACK을 보내고 이후부터는 연결이 이뤄지고 데이터가 오가게 되는 것이다. 이때 B 서버 상태는 ESTABILSHED이다.
    • SYN : synchronize sequence numbers
    • ACK : acknowledgement
    • 4-way handshake : 3-way handshake는 TCP의 연결을 초기화할 때 사용한다면, 4-way handshake는 세션을 종료하기 위해 수행되는 절차임

2. Socket Timeout

• 클라이언트와 서버가 connection을 맺은 후 서버는 데이터를 클라이언트에게 전송하게 됨. 이때 실제 데이터를 주고 받는 과정은 하나의 데이터 덩어리가 아닌 여러개의 패킷으로 나눠서 전송되는데 각 패킷이 전송될 때 시간 차(Gap)가 있음. 이 차이 시간의 제한(임계치)을 SocketTimeout이라고 함.
• read timeout과의 관계
  • 클라이언트와 서버가 connection은 맺어졌지만 I/O (Input/Out) 작업이 길어지거나 락이 걸려 요청이 처리되지 못하고 있을 때 클라이언트는 더 이상 기다리지 못하고 커넥션을 끊음. 이런 상황을 Read Timeout이라고 함.
• java.net에서는 socket timeout과 read timeout을 혼용하며, setSoTimeout() 메소드를 사용함

2-1. Read Timeout

• 클라이언트와 서버가 connection에는 성공했지만 실제 데이터를 전송하는 I/O 과정이 길어지는 경우 일정 시간이 경과되면 클라이언트는 connection을 끊게 됨.
• 보통 주고 받는 데이터의 양이나 네트워크 속도에 따라서 대응을 다르게 함. 만약 데이터의 양이 크다면 이를 분할해서 받을 수 있도록 API 자체 Spec을 변경하거나 Retry 전략을 사용할 수 있고, 속도가 느려서 발생하는 상황이라면 전반적으로 네트워크 대역폭 증가를 위한 인프라 작업을 고려할 수 있음

* Connection, Socket/Read Timeout과 관련된 예외

• java.net.Socket.Exception : Thrown to indicate that there is an error creating or accessing a Socket. -> connection timeout
• java.net.SocketTimeoutException : Signals that a timeout has occurred on a socket read or accept. -> socket timeout, read timeout

2) HttpClient 라이브러리

Apache HttpClient

• HTTP 프로토콜을 손쉽게 사용할 수 있게 해주는 클라이언트측 HTTP 전송 라이브러리
• Apache HttpComponents 제품군의 HttpClient는 http 통신을 위한 표준이 되어옴
• httpURLConnection의 단점(connection pooling)을 채우는 다양한 API를 가진 성숙한 프로젝트
• Apache HttpClient를 이용하면 간편하게 HTTP request를 보낼 수 있음. 간혹 웹 서버를 만들면서 다른 서버로부터 request를 보내 response받아 데이터를 처리해야할 때가 있음. 이때 HttpClient를 이용하면 간단하게 구현 가능
•  java.net 패키지와의 차이점
  • java.net 패키지는 HTTP를 통해 리소스에 액세스하기 위한 기본 기능을 제공하지만, 많은 애플리케이션에 필요한 완전한 유연성이나 기능을 제공하지 않음
  • HttpClient 패키지는 최신 HTTP 표준 및 권장 사항의 클라이언트 측을 구현하는 효율적이고 최신이며 기능이 풍부한 패키지를 제공해 이 공백을 채우려고 함
  • 확장을 위해 설계된 HttpClient는 기본 HTTP 프로토콜에 대한 강력한 지원을 제공하는 동시에 웹 브라우저, 웹 서비스 클라이언트 또는 분산 통신을 위해 HTTP 프로토콜을 활용하거나 확장하는 시스템과 같은 HTTP 인식 클라이언트 응용 프로그램을 구축하는 모든 사람에게 유용할 수 있음

HttpClient에서 제공하는 timeout 관련 메소드

• setConnectTimeout : 서버와 연결을 맺을 때의 타임아웃
• setConnectionRequestTimeout : ConnectionManager(커넥션풀)로부터 꺼내올 때의 타임아웃
• setSocketTimeout : 요청/응답간의 타임아웃
• Connection Pooling
  • HttpClient로 빈번히 connection을 맺었다가 사용이 끝나고 끊고 하다 보면 더 이상 Connection을 열 수 없는 경우가 발생할 수 있음
  • connection을 닫는다고 호출을 해도 실제로는 어느정도 TIME_WAIT 상태에 있다가 끊어지는데 이런 것들이 많이 쌓여 있으면 File Descriptor가 꽉 찼다는 에러(Too Many Open Files)가 나면서 connection을 맺지 못하게 된다.
  • 이런 현상을 방지하기 위해서 Connection을 재사용할 수 있도록 HttpClient에서 제공하는 Connection Pool을 사용함 (getHttpClient를 호출할 때 Connection Pool이 지정된 사이즈로 생성되고 Connection을 하나 만들어 리턴함)
  • Pool을 사용할 때마다 항상 주의해야할 것은 반환을 꼭 해 줘야한다!

Timeout 예시

# HttpClient 4.3 (Configure Timeouts Using the New 4.3 Builde)
int timeout = 5;
RequestConfig config = RequestConfig.custom()
	.setConnectTimeout(timeout * 1000)
    .setConnectionRequestTimeout(timeout * 1000)
    .setSocketTimeout(timeout * 1000).build();
   CloseableHttpClient client = 
   	HttpClientBuilder.create().setDefaultRequestConfig(config).build();