RSS Feed of Wonyu

HTTP

Sun, 23 Mar 2025 00:00:00 GMT

✅ 웹 브라우저와 서버 간의 통신을 위한 응용 계층 프로토콜

📌 특징

무상태성(Stateless)

각 요청이 독립적이고, 서버는 이전 상태를 기억하지 않는다.

🔹 장점

많은 요청을 효율적으로 처리 가능
구현 단순

🔹 단점

로그인 등 상태 유지가 필요한 경우 별도 구현 필요 ex) 쿠키, 세션, 토큰 등

클라이언트-서버 구조

요청자와 응답자가 명확하게 나뉘는 구조

텍스트 기반 프로토콜

사람이 직접 읽고 이해할 수 있는 텍스트 형식으로 구성

🔹 장점

디버깅이나 테스트 간편

🔹 단점

binary 형식보다 비효율적 -> HTTP/2에서는 binary framing 도입

📌 기본 구조: 요청 - 응답

요청

클라이언트가 서버에 리소스를 요청할 때 보내는 메세지

🔹 구성 요소

요청 라인: GET /page.html HTTP/1.1
헤더: 요청에 대한 추가 정보
본문: 주로 POST/PUT 요청에서 사용

요청 예시

GET /index.html HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0
Accept: text/html

응답

서버가 요청을 처리한 후 클라이언트에게 돌려주는 메세지

🔹 구성 요소

상태 라인: HTTP/1.1 200 OK
헤더: 응답에 대한 정보
본문: 요청한 데이터

응답 예시

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 1234

<html>
  <body>Hello, world!</body>
</html>

📌 버전별 비교

HTTP/1.0

🔹 특징

요청마다 새로운 TCP 연결 필요 -> 비효율적 (매번 3-way handshake) -> Keep-Alive
헤더 전송 시 중복이 많고 압축이 없어 비효율적

🔹 Keep-Alive
HTTP 연결을 끊지 않고 재사용해서 성능을 높이는 기술

HTTP/1.0에서는 명시적으로 Keep-Alive를 사용할 수 있다.
HTTP/1.1은 기본 지원

HTTP/1.1

🔹 주요 개선점

지속 연결
- 기본적으로 연결 유지(keep-alive 필요 없음)
파이프라인 지원
- 요청은 순차 전송, 응답도 순차 도착이 기본 원칙이라 브라우저들이 사용을 꺼림

❌ 한계

멀티 요청/응답 병렬 처리 불가능
-> 여전히 Head-of-Line Blocking 발생

HTTP/2

🔹 주요 개선점

멀티 플렉싱 -> 하나의 TCP 연결로 동시에 여러 요청과 응답 전송 가능
헤더 압축
- 중복 제거 + 압축 -> 대역폭 절약, 속도 향상
서버 푸시
- 클라이언트의 요청 없이 서버가 미리 리소스 전송 가능
바이너리 프레이밍
- 텍스트가 아닌 바이너리 기반

🔹 Head-of-Line Blocking
앞줄에 있는 하나의 요청이 지연되면, 그 뒤의 요청들까지 기다려야 하는 상황

📌 HTTP & REST

✅ HTTP는 프로토콜(통신 방법)이고, REST는 아키텍처 스타일(설계 원칙)이다.

항목	HTTP	REST
개념	프로토콜 (통신을 위한 약속)	아키텍처 스타일 (설계 방식)
목적	클라이언트 ↔ 서버 간 데이터 전송	웹 리소스를 명확하고 일관되게 설계
내용	요청/응답 포맷, 상태 코드, 메서드 등	자원 중심 URI 설계, 메서드에 따라 의미를 부여
관계	REST는 HTTP 위에서 주로 사용됨	HTTP를 기반으로 동작하는 경우가 많음

따라서 REST는 HTTP 뿐만 아니라 WebSocket, gRPC 등 다른 프로토콜 위에서도 적용 가능

REST(Representational State Transfer)

✅ 자원을 중심으로 설계하는 방식
✅ "자원의 표현(Representation)"을 이용해 상태(State)를 전달(Transfer)

🔹 핵심 설계 원칙

Client-Server 구조: 클라이언트와 서버를 명확하게 분리해야 한다.
Stateless: 각 요청은 독립적이며, 서버는 이전 요청의 상태를 저장하지 않는다.
Cacheable: 응답은 캐시가 가능한지 여부를 명확히 나타내야 한다.
Uniform Interface: 자원 접근은 표준 HTTP 메서드와 URI 사용을 지켜 일관된 인터페이스를 통해 이뤄져야 한다.
Layered System: 클라이언트는 REST 서버와 상호작용할 뿐, 중간 서버에 대해서는 모른다.
Code on Demand: 서버는 클라이언트로 실행 가능한 코드(JavaScript 등)를 전송할 수 있다

Acceptance Test

Fri, 14 Mar 2025 00:00:00 GMT

✅ 사용자 스토리(시나리오)에 맞춰 수행하는 테스트
✅ 개발자와 이해관계자들 간의 토의를 통해 만들어진 시나리오에 기반해 테스트
✅ 실제 HTTP 요청을 보내고 응답을 확인하는 최상위 레벨의 테스트

📌 특징

사용자 관점에서 동작 검증

단순한 코드 실행이 아니라, 실제 사용자의 시나리오를 검증함.
예: "사용자가 회원 가입을 하면, 로그인할 수 있어야 한다."

전체 시스템을 테스트 (E2E 포함)

REST API, 데이터베이스, 보안 설정 등 전체 애플리케이션의 동작을 포함한 검증
단순한 API 응답뿐만 아니라, 비즈니스 로직, DB 반영 여부까지 확인 가능

REST API 기반의 테스트가 일반적

RestAssured를 사용하여 HTTP 요청-응답을 기반으로 검증
Spring Boot에서는 @SpringBootTest(webEnvironment = WebEnvironment.RANDOM_PORT)를 사용하여 서버를 띄워 테스트

📌 REST-assured

✅ REST API를 테스트하기 위한 Java 기반의 라이브러리
✅ HTTP 요청을 보내고, 응답을 검증하는 기능을 제공
✅ Spring Boot, JUnit과 함께 API 테스트를 수행할 때 많이 사용됨

REST Assured는 2.0 버전 이후로 BDD 스타일(Given-When-Then)을 기반으로 API 테스트를 작성하도록 설계되었다.

Given(설정-요청 준비)

기능	설명	예제
`baseUri()`	기본 URL 설정	`given().baseUri("http://localhost:8080")`
`basePath()`	기본 경로 설정	`given().basePath("/users")`
`port()`	포트 설정	`given().port(8080)`
`header()`	요청 헤더 설정	`given().header("Authorization", "Bearer token")`
`contentType()`	요청 데이터 타입 설정	`given().contentType("application/json")`
`body()`	요청 본문 (JSON, XML 등) 설정	`given().body("{ \"name\": \"Alice\" }")`
`pathParam()`	경로 변수 설정	`given().pathParam("id", 1)`
`queryParam()`	쿼리 파라미터 설정	`given().queryParam("sort", "name")`

API 요청을 보낼 때 필요한 정보(헤더, 파라미터, 본문 등)을 설정한다.

🔹 Default Values
REST-assured는 기본적으로 host를 localhost, port를 8080으로 지정하지만, 메서드나 설정 파일을 통해 값을 변경할 수 있다.

메서드

given().port(80). ..

설정 파일

RestAssured.baseURI = "http://myhost.org";

When(행위-요청 실행)

기능	설명	예제
`get()`	GET 요청 전송	`when().get("/users/{id}")`
`post()`	POST 요청 전송	`when().post("/users")`
`put()`	PUT 요청 전송	`when().put("/users/{id}")`
`delete()`	DELETE 요청 전송	`when().delete("/users/{id}")`
`patch()`	PATCH 요청 전송	`when().patch("/users/{id}")`

설정된 요청을 실행해 실제 HTTP 요청을 보낸다.

Then(검증-응답 확인)

기능	설명	예제
`statusCode()`	HTTP 상태 코드 검증	`then().statusCode(200)`
`body()`	응답 본문(JSON, XML 등) 값 검증	`then().body("name", equalTo("Alice"))`
`header()`	응답 헤더 값 검증	`then().header("Content-Type", "application/json")`
`time()`	응답 시간 검증	`then().time(lessThan(2000L))`
`extract()`	응답 값 추출	`then().extract().jsonPath().getString("token")`

응답이 예상한 값과 일치하는지 검증한다.

🔹 ExtractableResponse
extract() 메서드를 통해 응답 정보를 담은 객체를 반환받아 AssertJ로 테스트할 수 있다.

protected void 회원가입_검증(ExtractableResponse response) {  
    int code = response.statusCode();  
    assertThat(code).isEqualTo(HttpStatus.CREATED.value());  
}

vs MockMVC

✅ REST Assured와 MockMvc는 둘 다 API 테스트를 수행할 수 있지만, 사용하는 환경이 다름
✅ MockMvc는 실제 HTTP 요청을 보내지 않고, Controller 계층을 Mock으로 테스트하는 반면, RestAssured는 실제 서버에서 테스트를 수행

테스트 방식	설명	실제 네트워크 요청	Spring 컨텍스트 필요 여부
MockMvc	Controller 계층만 테스트	❌	⭕
Rest Assured	전체 애플리케이션을 실행하고 API 테스트 수행	⭕	⭕

📌 참고

https://tecoble.techcourse.co.kr/post/2021-05-25-unit-test-vs-integration-test-vs-acceptance-test/
https://github.com/rest-assured/rest-assured/wiki/Usage
https://www.baeldung.com/rest-assured-tutorial

Slice Test

Sun, 09 Mar 2025 00:00:00 GMT

✅ Slice Test는 Spring에서 특정 레이어(Controller, Repository 등)만 테스트하는 방식
✅ 애플리케이션 전체를 로드하는 것이 아니라, 필요한 빈(Bean)만 로드하여 테스트 속도를 향상
✅ 각 레이어별로 독립적인 단위 테스트를 수행할 수 있도록 도움

📌 필요성

vs Unit Test

Unit Test는 특정 클래스만 테스트하기 때문에 Spring Context를 사용하지 않는다. 따라서 다른 Spring Bean과의 연동 테스트가 어렵다.

반면, Slice Test는 각 레이어의 필요한 빈을 로드하기 때문에 특정 레이어의 연동 테스트가 가능하다.

vs SpringBootTest

SpringBootTest는 Spring Context를 사용하고, 다른 Spring Bean과의 연동 테스트가 가능하다. 하지만 애플리케이션 전체를 로드하기 때문에 시간이 오래걸리고 무겁다.

반면, Slice Test는 특정 레이어의 빈들만 로드하기 때문에 비교적 가볍다.

📌 Web Layer Slice Test

✅ Web Layer Bean들만 로드하여 테스트하는 방법
✅ Service 및 Repository는 로드되지 않으며, Service는 Mock으로 주입해야 함

@WebMvcTest

@WebMvcTest 어노테이션을 이용하면 웹 레이어 테스트를 하는 데 필요한 @Controller, @ControllerAdvice, Filter 등만 Bean으로 등록된다.

예시 코드

@ExtendWith(SpringExtension.class)
@WebMvcTest(UserController.class)
public class UserControllerTest {

    @Autowired
    private MockMvc mockMvc;

    @MockBean
    private UserService userService;

    @Test
    void shouldReturnUser() throws Exception {
        // Given
        Long userId = 1L;
        UserDto mockUser = new UserDto(userId, "John Doe", "john@example.com");
        when(userService.getUserById(userId)).thenReturn(mockUser);

        // When & Then
        mockMvc.perform(get("/users/{id}", userId))
                .andExpect(status().isOk())
                .andExpect(jsonPath("$.name").value("John Doe"))
                .andExpect(jsonPath("$.email").value("john@example.com"));
    }
}

MockMvc를 사용하여 위처럼 REST API를 실제로 호출하는 것처럼 테스트 가능하다.

@MockBean

위 예시 코드에서 UserService는 왜 @Mock이 아닌 @MockBean으로 등록되었을까?
위 코드는 Web Layer 내 Spring Bean과의 연동을 테스트하는 것이므로 Service 객체도 일반 Mock 객체가 아닌 Spring Bean인 Mock 객체가 필요하다. 따라서 @MockBean으로 Spring Bean인 Mock 객체를 주입한 것이다.

📌 Repository Layer Test

✅ JPA 관련 Bean(@Repository)만 로드하여 테스트

예시 코드

@DataJpaTest
public class UserRepositoryTest {

    @Autowired
    private UserRepository userRepository;

    @Test  
void 멤버_저장_테스트() {  
    // given  
    String name = "choi";  
    String nickname = "phillip";  
    Member member = Member.of(name, nickname);  
  
    // when  
    myJpaRepository.save(member);  
    Optional<Member> foundResult = myJpaRepository.findById(1L);  
  
    // then  
    assertSoftly(softly -> {  
        softly.assertThat(foundResult)  
              .isNotEmpty();  
        Member foundMember = foundResult.get();  
        softly.assertThat(foundMember.getName()).isEqualTo(name);  
        softly.assertThat(foundMember.getNickname()).isEqualTo(nickname);  
    });  
	}
}

@DataJpaTest를 사용하면 기본적으로 인메모리 데이터베이스인 H2를 기반으로 테스트용 데이터베이스를 구축한다. 또한 테스트가 끝나면 롤백을 해준다.

레포지토리 계층은 실제 DB와 통신 없이 Mock 객체를 사용하는 것이 의미가 없기 때문에 직접 DB와 통신하는 @DataJpaTest를 사용해야 한다.

📌 참고

https://jojoldu.tistory.com/226
https://tecoble.techcourse.co.kr/post/2021-05-18-slice-test/
https://mangkyu.tistory.com/145

Mockito

Sat, 08 Mar 2025 00:00:00 GMT

✅ Java에서 가장 널리 사용되는 Mocking 프레임워크
✅ 객체의 동작을 사전에 정의하여 단위 테스트를 쉽게 수행할 수 있도록 지원
✅ 실제 객체를 사용하지 않고 Mock 객체를 생성하여 독립적인 테스트를 가능하게 함

📌 사용 방법

JUnit과 함께 사용

✅ Mockito와 JUnit 모두 테스트 프레임워크이기 때문에 같이 사용하기 위해선 설정이 필요하다.

@ExtendWith(MockitoExtension.class)
public class MockitoAnnotationUnitTest {
    ...
}

위와 같이 설정하면, Mockito를 이용해 Mock 객체를 생성하고, JUnit을 통해 테스트할 수 있다.

주요 기능

🔹 Mock 객체 생성

import static org.mockito.Mockito.*;

UserRepository userRepository = mock(UserRepository.class);

🔹 Stub 설정

when(userRepository.findById(1L)).thenReturn(new User(1L, "John Doe", "john@example.com"));

Mockito의 when().thenReturn()을 사용하면, Stub처럼 특정 입력값에 대해 미리 정의된 값을 반환하도록 설정할 수 있다.

🔹 예외 발생 시뮬레이션

when(userRepository.findById(2L)).thenThrow(new UserNotFoundException("User not found"));

Mockito는 예외 상황을 시뮬레이션할 수 있도록 thenThrow()를 제공한다.

🔹 메서드 호출 검증(행위 검증)

verify(userRepository).findById(1L); // 메서드가 호출되었는지 확인
verify(userRepository, times(1)).findById(1L); // 정확히 1번 호출되었는지 확인
verify(userRepository, never()).findById(2L); // 특정 메서드가 호출되지 않았는지 확인

Mockito의 행위 검증 기능을 활용하면, 코드가 예상대로 동작했는지를 명확히 검증할 수 있다.

📌 어노테이션

@Mock

🔹 Mockito.mock() 사용

@Test
public void whenNotUseMockAnnotation_thenCorrect() {
    List mockList = Mockito.mock(ArrayList.class);
    
    mockList.add("one");
    Mockito.verify(mockList).add("one");
    assertEquals(0, mockList.size());

    Mockito.when(mockList.size()).thenReturn(100);
    assertEquals(100, mockList.size());
}

🔹 @Mock 사용

@Mock
List<String> mockedList;

@Test
public void whenUseMockAnnotation_thenMockIsInjected() {
    mockedList.add("one");
    Mockito.verify(mockedList).add("one");
    assertEquals(0, mockedList.size());

    Mockito.when(mockedList.size()).thenReturn(100);
    assertEquals(100, mockedList.size());
}

위처럼 @Mock 어노테이션을 사용하면, static 메서드 없이 mock 객체를 생성할 수 있다.

@InjectMocks

✅ 생성된 Mock 객체를 자동으로 테스트 객체에 주입한다.

🔹 @InjectMocks를 사용하지 않을 때

@ExtendWith(MockitoExtension.class)
public class UserServiceTest {

    @Mock
    private UserRepository userRepository;

    private UserService userService; // @InjectMocks 없이 직접 생성

    @BeforeEach
    void setUp() {
        userService = new UserService(userRepository); // 생성자를 통해 수동으로 주입
    }
}

🔹 @InjectMocks 사용할 때

@ExtendWith(MockitoExtension.class)
public class UserServiceTest {

    @Mock // Mock 객체 생성
    private UserRepository userRepository;

    @InjectMocks // userRepository를 자동으로 주입하여 UserService 생성
    private UserService userService;
}

@InjectMocks는 하나의 SUT에 대해서만 사용해야 한다.

📌 참고

https://www.baeldung.com/mockito-series

Test Double

Fri, 07 Mar 2025 00:00:00 GMT

📌 Test Double이란?

✅ 테스트 코드에서 실제 객체를 대체하는 가짜 객체
✅ 독립적인 테스트를 수행할 수 있게 함

필요성

🔹 독립성 보장
실제 객체가 외부 DB, 네트워크, 파일 시스템 등 외부 시스템에 의존성을 가지면 테스트가 영향을 받을 수 있다.
Test Double을 사용하면 외부 요소와 분리해 단위 테스트를 수행할 수 있다.

🔹 속도 향상
외부 시스템 호출이 필요한 테스트는 실행 속도가 느리다.
Test Double을 사용하면 빠르게 실행할 수 있는 가짜 객체를 활용해 빠르게 테스트를 수행할 수 있다.

🔹 특정 상황 쉽게 재현
네트워크 오류, 응답 지연 등의 상황을 쉽게 재현하여 시뮬레이션할 수 있다.

📌 Test Double의 종류

Test Double은 크게 다섯 가지 유형으로 분류된다.

Dummy

✅ 단순히 파라미터를 채우기 위해 사용
✅ 필수적으로 요구되지만, 실제 사용하지 않는 객체

예시 코드

class DummyUser implements User {
    @Override
    public String getUsername() {
        return null; // 아무 동작도 하지 않음
    }
}

// 테스트 코드
@Test
void testDummy() {
    NotificationService notificationService = new NotificationService();
    notificationService.sendNotification(new DummyUser()); // 실제 사용 X
}

Stub

✅ 미리 정해진 값을 반환하는 객체
✅ 복잡한 로직 없이 테스트에 필요한 최소한의 동작만 수행

예시 코드

class PaymentServiceStub implements PaymentService {
    @Override
    public boolean processPayment(double amount) {
        return true; // 항상 성공 반환
    }
}

// 테스트 코드
@Test
void testStub() {
    PaymentServiceStub paymentStub = new PaymentServiceStub();
    OrderService orderService = new OrderService(paymentStub);

    assertTrue(orderService.placeOrder(100.0)); // 항상 성공
}

Fake

✅ 실제 객체와 비슷하지만, 간단한 인메모리 저장소 등을 활용해 테스트 수행
✅ 실제 구현에 가깝지만, 완전한 기능을 제공하지 않음

예시 코드

class FakeUserRepository implements UserRepository {
    private Map<String, User> database = new HashMap<>();

    @Override
    public void save(User user) {
        database.put(user.getUsername(), user);
    }

    @Override
    public User findByUsername(String username) {
        return database.get(username);
    }
}

// 테스트 코드
@Test
void testFake() {
    FakeUserRepository fakeRepo = new FakeUserRepository();
    User user = new User("testUser");
    fakeRepo.save(user);

    assertEquals(user, fakeRepo.findByUsername("testUser")); // 저장된 객체 반환
}

Spy

✅ 실제 객체를 감싸 호출 정보를 감시하는 객체
✅ 실제 객체의 메서드를 실행하면서 호출 여부, 횟수 등의 정보 검증 가능

예시 코드

class SpyList<T> extends ArrayList<T> {
    private int addCallCount = 0;

    @Override
    public boolean add(T element) {
        addCallCount++;
        return super.add(element);
    }

    public int getAddCallCount() {
        return addCallCount;
    }
}

// 테스트 코드
@Test
void testSpy() {
    SpyList<String> spyList = new SpyList<>();

    spyList.add("hello");
    spyList.add("world");

    assertEquals(2, spyList.getAddCallCount()); // add()가 몇 번 호출되었는지 검증
}

🔹 Mock과의 차이점
Mock은 모든 동작을 가로채지만, Spy는 실제 메서드 실행한다. 따라서 사이드 이펙트를 주의해야 한다.

Mock

✅ 호출에 대한 기대를 명세하고, 해당 내용에 따라 동작하도록 프로그래밍 된 객체

예시 코드

@ExtendWith(MockitoExtension.class)
public class UserServiceTest {

    @Mock
    private UserRepository userRepository;

    @InjectMocks
    private UserService userService;

    @Test
    public void shouldReturnUserWhenUserIdIsProvided() {
        // Given
        Long userId = 1L;
        User mockUser = new User(userId, "John Doe", "john@example.com");
        when(userRepository.findById(userId)).thenReturn(mockUser);

        // When
        User result = userService.getUserById(userId);

        // Then
        assertNotNull(result);
        assertEquals("John Doe", result.getName());
        verify(userRepository).findById(userId);
    }
    
    @Test
    public void shouldThrowExceptionWhenUserNotFound() {
        // Given
        Long userId = 2L;
        when(userRepository.findById(userId)).thenThrow(new UserNotFoundException("User not found"));

        // When & Then
        assertThrows(UserNotFoundException.class, () -> userService.getUserById(userId));
        verify(userRepository).findById(userId);
    }
}

📌 행위 검증 & 상태 검증

행위 검증

테스트 대상(SUT)이 예상대로 다른 객체와 상호작용하는지(특정 동작을 수행하는지) 확인

상태 검증

특정 작업 수행 후 반환값이 예상대로 나오는지 확인

비교

when(userRepository.findById(userId)).thenReturn(mockUser);

Mock 객체인 userRepository를 Stub처럼 행동하게 한다.
하지만, "사전 정의된 기대"를 기반으로 한다는 점에서 Mock 객체이다.

assertNotNull(result);
assertEquals("John Doe", result.getName());

상태 검증이지만, 그 상태가 특정 행위(UserRepository의 호출)에 의해 만들어진 것이므로, 간접적으로 행위 검증의 의미도 포함될 수 있다.

verify(userRepository).findById(userId);

실제 상호 작용이 수행되었는지 확인하는 행위 검증이다.

🔹 Mock vs Stub

Stub은 단순히 입력값에 대해 고정된 값을 반환한다. (상태 검증)
Mock은 명세대로 행동한다. 따라서 반환값 뿐만 아니라 상호 작용이 예상대로 수행되었는지 검증할 수 있게 한다. (상태 검증, 행위 검증)

📌 참고

https://stackoverflow.com/questions/3459287/whats-the-difference-between-a-mock-stub

JUnit & AssertJ

Thu, 06 Mar 2025 00:00:00 GMT

📌 JUnit이란?

✅ Java 진영에서 가장 많이 사용되는 유닛 테스트 프레임워크
✅ Java 애플리케이션에서 유닛 테스트와 통합 테스트를 실행하는 데 사용

구성요소

JUnit 5는 다음 3가지 모듈로 구성된다.

모듈	설명
JUnit Platform	다양한 테스트 엔진을 실행할 수 있는 기반 제공
JUnit Jupiter	JUnit 5의 테스트 엔진 제공 (`@Test`, `@BeforeEach` 등)
JUnit Vintage	JUnit 3, 4 기반의 테스트 실행 지원

📌 JUnit 라이프사이클 어노테이션

✅ 테스트 실행 전/후 설정 및 정리를 수행하는 메서드를 정의할 수 있게 한다.

어노테이션	설명
`@BeforeEach`	각 테스트 전에 실행
`@AfterEach`	각 테스트 후에 실행
`@BeforeAll`	모든 테스트 실행 전에 1번 실행
`@AfterAll`	모든 테스트 실행 후 1번 실행

import org.junit.jupiter.api.*;

class LifecycleTest {
    
    @BeforeAll
    static void beforeAll() {
        System.out.println("📌 모든 테스트 시작 전 (1회 실행)");
    }

    @BeforeEach
    void beforeEach() {
        System.out.println("🔹 개별 테스트 실행 전");
    }

    @Test
    void test1() {
        System.out.println("✅ 실행: test1");
    }

    @Test
    void test2() {
        System.out.println("✅ 실행: test2");
    }

    @AfterEach
    void afterEach() {
        System.out.println("🔹 개별 테스트 실행 후");
    }

    @AfterAll
    static void afterAll() {
        System.out.println("📌 모든 테스트 종료 후 (1회 실행)");
    }
}

📌 JUnit 단언 (Assertions)

✅ 테스트 결과를 검증하는 다양한 Assertions를 제공
✅ 모두 org.junit.jupiter.api.Assertions 클래스의 static 메서드로 제공

메서드	설명
`assertEquals(expected, actual)`	기대값과 실제값 비교
`assertTrue(condition)`	조건이 `true`인지 확인
`assertFalse(condition)`	조건이 `false`인지 확인
`assertNotNull(object)`	객체가 `null`이 아님을 확인
`assertThrows(Exception.class, () -> {...})`	예외 발생 여부 확인

Assertions 예시

@Test  
void addAssertions() {  
    int sum = 2 + 3;  
    Assertions.assertEquals(sum, 5);  
}

예외 처리 Assertions 예제

@Test  
void exceptionAssertions() {  
    Assertions.assertThrows(ArithmeticException.class, () -> {  
        int result = 1 / 0;  
    });  
}

문제점

❌ 가독성이 떨어지는 검증
❌ 메서드 체이닝을 지원하지 않아 여러 검증을 수행하기 어려움
❌ 예외 검증이 제한적

AssertJ는 위와 같은 JUnit의 문제점을 해결한다.

📌 AssertJ란?

✅ Java에서 테스트를 작성할 때 필요한 직관적인 단언을 제공하는 라이브러리
✅ 테스트 코드의 가독성을 향상

구성요소

✅ 여러 모듈로 구성되어 있으며, 각 모듈은 특정한 타입에 대한 단언을 제공

AssertJ Core: JDK 타입(String, Iterable, Stream, Path, File, Map 등)에 대한 단언을 제공
AssertJ Guava: Guava 라이브러리의 타입(Multimap, Optional 등)에 대한 단언을 제공
AssertJ Joda-Time: Joda-Time 라이브러리의 타입(DateTime, LocalDateTime 등)에 대한 단언을 제공
AssertJ Neo4j: Neo4j 데이터베이스의 타입(Path, Node, Relationship 등)에 대한 단언을 제공
AssertJ DB: 관계형 데이터베이스의 타입(Table, Row, Column 등)에 대한 단언을 제공
AssertJ Swing: Swing 사용자 인터페이스의 기능적 테스트를 위한 API를 제공

⭐️ AssertJ Core가 가장 널리 사용되며, 나머지 모듈은 특정 환경(Guava, Joda-Time, DB 등)에서 사용됨

특징

향상된 가독성: assertThat() 메서드를 중심으로 자연스러운 언어 구조를 제공
풍부한 단언 메서드: 문자열, 컬렉션, 예외, 파일 등 다양한 타입에 대한 단언을 지원
메서드 체이닝: 여러 단언을 체이닝하여 가독성 향상
IDE 친화적: 코드 자동 완성 기능을 통해 개발 생산성을 향상

📌 AssertJ 단언 (Assertions)

기본 단언

@Test
void basicAssertions() {
    String name = "Frodo";
    assertThat(name).isEqualTo("Frodo")
                    .startsWith("Fro")
                    .endsWith("do")
                    .isEqualToIgnoringCase("frodo");
}

컬렉션 단언

@Test  
void collectionAssertions() {  
    List<String> fellowship = List.of("Frodo", "Sam", "Gandalf");  
    assertThat(fellowship).hasSize(3)  
                          .contains("Frodo", "Sam")  
                          .doesNotContain("Sauron");  
}

예외 단언

import static org.assertj.core.api.Assertions.*;

@Test  
void exceptionAssertions() {  
    assertThatThrownBy(() -> {  
        throw new Exception("boom!");  
    }).isInstanceOf(Exception.class)  
      .hasMessageContaining("boom");  
}

객체 단언

public class Member {
	Long id;
	String name;
	String nickname;
}

@Test  
void fieldsAssertions() {  
    Member member1 = new Member(1L, "choi", "phillip");  
    Member member2 = new Member(null, "choi", "phillip");  
  
    assertThat(member1).usingRecursiveComparison()  
                       .ignoringFields("id")  
                       .isEqualTo(member2);  
}

📌 JUnit과 AssertJ의 관계

JUnit은 테스트 실행을 담당 (테스트 라이프사이클 관리, @Test 제공)
AssertJ는 직관적이고 강력한 검증을 담당 (assertThat()으로 가독성 개선)
AssertJ는 JUnit이 없으면 테스트를 실행할 수 없음
JUnit만 사용하면 검증 코드가 불편하므로, AssertJ를 추가하면 가독성이 향상됨

📌 참고

https://junit.org/junit5/docs/current/user-guide
https://assertj.github.io/doc

TDD 개요

Tue, 04 Mar 2025 00:00:00 GMT

📌 TDD란?

✅ 테스트를 먼저 작성한 후에 실제 코드를 작성하는 개발 방법론
✅ 요구사항을 기반으로 테스트 케이스를 먼저 만들고, 그 테스트를 통과할 수 있도록 최소한의 코드를 작성한 후, 이를 점진적으로 개선하는 방식

3단계 사이클

RED (실패하는 테스트 작성)
- 기능을 구현하기 전, 먼저 테스트를 작성한다.
- 처음에는 당연히 실패한다.
GREEN (테스트가 통과하도록 최소한의 코드 작성)
- 테스트가 통과할 수 있도록 최소한의 코드를 작성한다.
- 복잡한 최적화 없이 가장 단순한 해결책을 적용한다.
BLUE (리팩토링)
- 중복을 제거하고, 더 나은 코드 구조로 개선한다.
- 테스트를 다시 실행하여 리팩토링 과정에서 기능이 깨지지 않았는지 확인한다.

TDD의 필요성

🔹 설계 개선
테스트를 먼저 작성하면서 시스템의 구조와 인터페이스를 고민하게 되어 더 나은 설계를 유도한다.

🔹 장기적인 관점에서 개발 비용 감소
코드의 안정성이 증가하고, 리팩토링에 용이한 코드가 되므로 장기적으로 개발 속도를 향상시킨다.

📌 테스트 종류

단위 테스트 (Unit Test)

✅ 가장 많은 비율을 차지하는 테스트
✅ 개별 함수, 클래스, 모듈을 독립적으로 테스트

통합 테스트 (Integration Test)

✅ 여러 모듈이 결합되었을 때 정상적으로 작동하는지 테스트
✅ 테스트 격리 전략이 필요

E2E 테스트 (End-to-End Test)

✅ 애플리케이션의 전체적인 흐름 테스트

📌 FIRST 원칙

✅ 테스트 코드가 갖추어야 할 5가지 원칙

Fast (빠르게 실행)
Isolated (독립적으로 실행 가능)
Repeatable (반복 실행 가능)
Self-validating (결과를 스스로 검증 가능)
Timely (적시에 작성, 코드 작성 전에 먼저 테스트 작성)

📌 Testability

✅ 테스트를 얼마나 쉽고, 효과적으로 수행할 수 있는지 나타내는 정도
✅ 얼마나 쉽게 입력을 변경(Controllability)하고, 출력을 검증(Observability)할 수 있는가?

DIP & DI

객체가 하위 모듈이 아닌 추상화된 상위 모듈에 의존하게 함(DIP)으로써 쉽게 입력(input)을 변경할 수 있게 한다. 테스트 시 대역을 객체에 주입(DI)해 쉽게 출력(output)을 검증할 수 있도록 한다.

이는 변경 사항에 유연하게 대응할 수 있는 코드를 유도한다.

Spring AOP

Mon, 03 Mar 2025 00:00:00 GMT

✅ AOP(Aspect Oriented Programming)은 핵심 비즈니스 로직이 아닌 공통적인 부가적인 관심사(로깅, 보안, 트랜잭션 관리 등)를 분리하여 코드의 유지보수성을 높이는 프로그래밍 기법

📌 핵심 개념

용어	설명
Aspect	공통 관심사(로깅, 트랜잭션, 보안 등)를 모듈화한 객체
Advice	특정 JoinPoint에서 실행될 코드 (Before, After, Around 등)
JoinPoint	Advice가 실행될 수 있는 지점 (메서드 실행 시점 등)
Pointcut	JoinPoint 중에서 Advice를 적용할 대상을 정의하는 표현식
Weaving	Advice를 실제 대상 객체에 적용하는 과정 (컴파일 타임, 런타임 등)

📌 Spring AOP의 주요 Advice 종류

✅ 오류 확률 감소와 간결한 코드를 위해 최소한의 유형 선택 권장

Advice 유형	설명	예제
Before	대상 메서드 실행 전 실행	`@Before("execution(* com.example..*(..))")`
After Returning	대상 메서드 실행 후 (예외 발생 X) 실행	`@AfterReturning("execution(* com.example..*(..))")`
After Throwing	대상 메서드 실행 중 예외 발생 시 실행	`@AfterThrowing("execution(* com.example..*(..))")`
After (Finally)	대상 메서드 실행 완료 후 (성공/실패 상관없음) 실행	`@After("execution(* com.example..*(..))")`
Around	대상 메서드 실행 전/후 모두 실행 (가장 강력함)	`@Around("execution(* com.example..*(..))")`

🔹 AOP 동작 순서

1️⃣ @Around 실행 (메서드 실행 전)  
2️⃣ @Before 실행  
3️⃣ 대상 메서드 실행  
4️⃣ @AfterReturning 실행 (정상 종료 시)  
5️⃣ @AfterThrowing 실행 (예외 발생 시)  
6️⃣ @After 실행 (무조건 실행)  
7️⃣ @Around 실행 (메서드 실행 후)

📌 Spring AOP 적용 방식

✅ 프록시 기반 방식과 AspectJ 기반 방식이 있다.

프록시 기반 방식

✅ Spring이 기본적으로 제공하는 AOP 방식
✅ 런타임에 프록시 객체를 생성하여 AOP 기능을 적용
✅ 스프링 컨테이너에서 관리하는 빈에만 적용 가능

🔹 동작 방식

JDK 동적 프록시: 인터페이스가 있는 경우, java.lang.reflect.Proxy를 이용해 프록시 생성
CGLIB 프록시(클래스 기반): 인터페이스가 없는 경우, CGLIB 라이브러리를 사용해 바이트코드 조작으로 프록시 생성

🔹 프록시 동작 방식
AOP 없이 Spring 빈을 실행시키면, 아래와 같이 실행될 것이다. 만약 AOP를 활용하면, Spring 빈은 아래와 같이 실행된다. POJO를 구현한 AOP 프록시 객체가 클라이언트 요청을 받아 foo() 실행 전/후 advice를 실행하는 것이다.

🔹 프록시 생성 방식
Spring AOP는 AnnotationAwareAspectJAutoProxyCreator라는 BeanProcessor의 구현체를 사용해 AOP 프록시를 생성한다.

1️⃣ Spring 컨테이너가 Spring 빈을 생성
2️⃣ BeanPostProcessor (AnnotationAwareAspectJAutoProxyCreator)가 빈을 감지
3️⃣ AOP 적용 대상이면 프록시 객체를 생성하여 빈으로 등록
4️⃣ 클라이언트가 Spring 빈을 호출하면 프록시가 먼저 실행됨
5️⃣ 프록시가 AOP Advice(Before, After 등)를 실행한 후, 원래 메서드를 실행

테스트 코드

@SpringBootTest  
class MyServiceTest {  
  
    @Autowired  
    private MyService myService;  
  
    @Test  
    void testAopProxyType() {  
        assertThat(myService.getClass()).isEqualTo(MyService.class);  
    }  
}

결과

필요:com.example.my.MyService
실제:com.example.my.MyService$$SpringCGLIB$$0

Spring AOP가 적용된 MyService의 빈 객체를 확인해보면, 프록시 객체가 감싸진 것을 확인할 수 있다.

AspectJ 기반 방식

✅ Spring AOP보다 더 강력한 AOP 방식
✅ 컴파일 타임 또는 로드 타임에 바이트코드를 수정하여 AOP 적용
✅ Spring Bean이 아닌 일반 객체에도 AOP 적용 가능

📌 예제

🔹 기본적인 Aspect 모듈

@Aspect
@Component
@Slf4j
public class LoggingAspect {  // Aspect
    
    @AfterReturning("execution(* com.example.my..*(..))")  // Pointcut
    public void afterMethodExecution(JoinPoint joinPoint) {  // Advice
        log.info("✅ service 실행 완료: ");
    }
}

🔹 포인트컷 분리

@Aspect
@Component
@Slf4j
public class LoggingAspect {  // Aspect

    @Pointcut("execution(* com.example.my..*(..))")  // Pointcut
    public void myMethods() {}
    
    @AfterReturning("myMethods()")  
    public void afterMethodExecution(JoinPoint joinPoint) {  // Advice
        log.info("✅ service 실행 완료: ");
    }
}

📌 참고

https://docs.spring.io/spring-framework/reference/core/aop.html

Spring 예외 처리

Fri, 28 Feb 2025 00:00:00 GMT

📌 Spring 기본 예외 처리 방식

Spring Boot에서 별도의 핸들링 없이 예외가 발생하면, DispatchServlet이 /error엔드포인트로 요청을 위임하고, BasicErrorController가 실행되고, 상태 코드 500 에러가 발생한다.

이때, BasicErrorController는 ErrorAttributes를 이용해 예외 정보를 가져와 JSON 또는 HTML로 응답한다.

BasicErrorController.java

@Controller  
@RequestMapping("${server.error.path:${error.path:/error}}")  
public class BasicErrorController extends AbstractErrorController {

	@RequestMapping  
	public ResponseEntity<Map<String, Object>> error(HttpServletRequest request) {  
	    HttpStatus status = getStatus(request);  
		    if (status == HttpStatus.NO_CONTENT) {  
		       return new ResponseEntity<>(status);  
		    }  
	    Map<String, Object> body = getErrorAttributes(request, getErrorAttributeOptions(request, MediaType.ALL));  
	    return new ResponseEntity<>(body, status);  
	}
}

Response

{
	"timestamp": "2025-02-27T05:28:50.861+00:00",
	"status": 500,
	"error": "Internal Server Error",
	"path": "/"
}

단점

사용자 친화적인 메시지를 제공할 수 없음
클라이언트가 에러에 대한 핸들링을 하기 힘듦
특정 예외 별 다른 응답을 제공하기 힘듦

위 단점을 해결하기 위해 Spring은 에러를 유연하게 처리할 수 있는 방법을 제공한다.

📌 @ExceptionHandler

✅ Exception 클래스 별 처리할 응답을 지정할 수 있다.
✅ 에러 응답의 payload를 자유롭게 다룰 수 있다.

MyController.java

@RestController
@RequestMapping
public class MyController {

    @GetMapping
    public String throwError() {
        throw new CustomException();
    }

	@ExceptionHandler(CustomException.class)  
	public ResponseEntity<String> handleCustomException(final CustomException exception) {  
    return ResponseEntity.status(HttpStatus.BAD_REQUEST).body("bad request");  
	}
}

Response

bad request

동작 과정

1️⃣ 컨트롤러 실행 중 예외 발생 (throw new CustomException();)
2️⃣ DispatcherServlet이 예외를 감지하고 @ExceptionHandler 탐색
3️⃣ @ExceptionHandler(CustomException.class) 메서드가 실행됨
4️⃣ 예외가 ResponseEntity<String>로 변환되어 클라이언트에게 응답됨

장점

사용자 친화적인 메시지를 전달할 수 있다.
에러 코드나 payload를 통해 클라이언트가 에러 별 핸들링을 할 수 있다.
예외 별로 다른 응답을 제공할 수 있다.

📌 Spring Filter 예외 처리

문제점

Spring Filter는 서블릿 컨테이너 영역에서 관리되지 않기 때문에 Filter에서 발생한 에러는 ExceptionHandler가 감지할 수 없다.

CustomFilter.java

@Component  
@Slf4j  
public class CustomFilter implements Filter {  
  
    @Override  
    public void doFilter(final ServletRequest request, final ServletResponse response,  
        final FilterChain chain)  
        throws IOException, ServletException {  
        throw new CustomException();  
    }  
}

Response

{
	"timestamp": "2025-02-27T05:49:57.566+00:00",
	"status": 500,
	"error": "Internal Server Error",
	"path": "/"
}

Filter에서 발생한 CustomException이 위에서 봤던 BasiErrorController로 전달된 것이다.

해결 방법

따라서 FIlter의 예외의 경우, 다음과 같이 따로 처리해줘야 한다.

CustomFilter.java

@Component  
@Slf4j  
public class CustomFilter implements Filter {  
  
    @Override  
    public void doFilter(final ServletRequest request, final ServletResponse response,  
        final FilterChain chain)  
        throws IOException, ServletException {  
        HttpServletResponse httpResponse = (HttpServletResponse) response;  
        httpResponse.sendError(HttpServletResponse.SC_BAD_REQUEST, "bad request");  
    }  
}

Response

{
	"timestamp": "2025-02-27T05:57:10.784+00:00",
	"status": 400,
	"error": "Bad Request",
	"path": "/"
}

동작 과정

1️⃣ Filter 내부에서 httpResponse.sendError(HttpServletResponse.SC_BAD_REQUEST, "bad request") 호출
2️⃣ 서블릿 컨테이너가 400 상태 코드와 메시지를 포함한 요청을 다시 /error 엔드포인트로 전달
3️⃣ Spring Boot의 BasicErrorController가 /error 요청을 받아 JSON 응답 생성
4️⃣ 클라이언트가 JSON 응답을 받음

📌 참고

https://spring.io/blog/2013/11/01/exception-handling-in-spring-mvc
https://mangkyu.tistory.com/173

Filter & Interceptor

Thu, 27 Feb 2025 00:00:00 GMT

✅ Filter와 Interceptor는 Spring에서 요청을 가로채 처리할 수 있는 두 가지 주요 컴포넌트
✅ 두 컴포넌트 모두 요청(Request)과 응답(Response)에 대해 사전/사후 처리를 수행할 수 있지만, 동작 시점과 적용되는 범위가 다름

📌 Spring Filter

✅ WAS 레벨에서 동작
✅ DispatcherServlet 요청 전 실행

주요 메서드

public interface Filter {
    void init(FilterConfig filterConfig) throws ServletException;
    void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException;
    void destroy();
}

🔹 doFilter()

모든 요청을 가로채어 특정 처리를 수행
chain.doFilter(request, response)를 호출하지 않으면 요청이 DispatcherServlet으로 전달되지 않음

🔹 init()

필터가 처음 생성될 때 한 번만 실행되는 초기화 메서드

🔹 destroy()

필터가 제거될 때 한 번 실행되는 정리 작업 메서드

Filter & Bean

✅ Filter는 WAS에 의해 관리되는 서블릿 컴포넌트였기 때문에 Bean으로 등록할 수 없었음
✅ Filter에서도 Spring 기술을 필요로 하는 상황이 많아지면서 Bean으로 등록 가능해짐

🔹 DelegatingFilterProxy
✅ Spring Application Context의 Filter 클래스를 Servlet Filter에 등록할 수 있도록 해주는 객체

CustomFilter.java

@Component("loggingFilter")
public class CustomFilter implements Filter {

    private static Logger LOGGER = LoggerFactory.getLogger(CustomFilter.class);

    @Override
    public void init(FilterConfig config) throws ServletException {
        // initialize something
    }

    @Override
    public void doFilter(
      ServletRequest request, ServletResponse response, 
      FilterChain chain) throws IOException, ServletException {
 
        HttpServletRequest req = (HttpServletRequest) request;
        LOGGER.info("Request Info : " + req);
        chain.doFilter(request, response);
    }

    @Override
    public void destroy() {
        // cleanup code, if necessary
    }
}

ApplicationInitializer.java

public class ApplicationInitializer 
  extends AbstractAnnotationConfigDispatcherServletInitializer {
    // some other methods here
 
    @Override
    protected Filter[] getServletFilters() {
        DelegatingFilterProxy delegateFilterProxy = new DelegatingFilterProxy();
        delegateFilterProxy.setTargetBeanName("loggingFilter");
        return new Filter[]{delegateFilterProxy};
    }
}

🔹 Spring Boot 등장
Spring Boot 등장 이후, Spring Boot가 내장 웹서버를 지원하면서 ServletContext를 직접 제어할 수 있기 때문에 위와 같은 과정 없이도 Filter 빈을 Filter Chain에 등록할 수 있게 되었다.

📌 Spring Interceptor

✅ Spring MVC에서 DispatcherServlet 이후, 컨트롤러로 요청이 가기 전후에 실행되는 컴포넌트
✅ Handler(Controller)를 실행하기 전/후에 특정 로직을 수행할 수 있도록 도움

필요한 상황

API 요청 감사 또는 로깅
인증/인가 체크
요청 데이터 가공 컨트롤러 실행 전후에 필요한 공통 로직을 구현할 때 유용

주요 메서드

public interface HandlerInterceptor {
    default boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
        return true;
    }

    default void postHandle(HttpServletRequest request, HttpServletResponse response, Object handler, ModelAndView modelAndView) throws Exception {
    }

    default void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex) throws Exception {
    }
}

🔹 preHandle()
요청을 가로채 컨트롤러 실행 전에 수행

🔹 postHandle()
컨트롤러 실행 후, View 렌더링 전에 작업 수행

🔹 afterCompletion()
요청 처리가 완료된 후 실행(예외가 발생하더라도 실행)

📌 참고

https://www.baeldung.com/spring-delegating-filter-proxy
https://mangkyu.tistory.com/221
https://www.baeldung.com/spring-mvc-handlerinterceptor
https://mangkyu.tistory.com/173

DNS

Wed, 26 Feb 2025 00:00:00 GMT

📌 개요

DNS 필요성

✅ DNS는 사람이 이해하기 쉬운 도메인(www.google.com)을 IP 주소로 변환하는 역할
✅ DNS가 없을 땐, IP 주소와 도메인 이름을 매핑한 파일을 관리

🔹 주소 변환 명령

nslookup google.com

Server:		182.172.255.180
Address:	182.172.255.180#53

Non-authoritative answer:
Name:	google.com
Address: 142.251.42.142

DNS를 이용하면 위처럼 도메인 이름으로 IP 주소를 얻을 수 있다.

DNS의 구성 요소

🔹 네임 스페이스

트리 구조의 네임 스페이스를 비롯해 데이터에 대한 이름 관련 규칙 정의
네임 스페이스의 트리에 연결된 호스트는 자원 레코드라는 정보 집합체로 표현

🔹 네임 서버

네임 스페이스의 트리 구조와 트리에 보관된 정보 집합체를 관리

🔹 해석기(Resolver)

네임 서버로부터 클라이언트의 요청 정보를 얻어 내는 프로그램

📌 네임 스페이스

네임 스페이스의 구조

✅ DNS 네임 스페이스는 계층적인 트리 구조
✅ 상위 도메인에서 하위 도메인으로 내려가는 계층적 구조를 가지고 있어 효율적으로 관리

. (루트 도메인)
├── com
│   ├── google.com
│   │   ├── www.google.com
│   │   ├── mail.google.com
├── org
│   ├── wikipedia.org
│   ├── openai.org

🔹 TLD(Top Level Domain)
최상위 도메인을 뜻하며, 위에선 com, org가 TLD

데이터베이스 서비스

✅ DNS 서버는 분산된 데이터베이스 시스템으로, 특정 도메인 정보를 저장하고 관리
✅ 계층 구조로 관리함으로써, 하위 도메인 관리 권한 위임을 하부 구조 전체에 대해 재귀적으로 적용

🔹 존(Zone)
임의의 네임 서버가 관리하는 영역

🔹 도메인과 존
특정 네임 서버 하부에 새로운 도메인 네임 서버가 추가되면, 도메인과 존 영역이 달라진다.

자원 레코드

✅ DNS는 다양한 정보(도메인 이름, IP 주소 등)를 자원 레코드(Resource Record) 형태로 저장

🔹 자원 레코드 필드

Name: 찾고자 하는 가변 길이의 도메인 이름
Type: 레코드의 종류
Class: 프로토코 패밀리, 인터넷에서는 IN 값 사용
TTL(Time To Live): 자원 레코드의 유효시간을 표시, 캐시의 만료 시간을 정한다.
RD Length: 자원 데이터의 길이
RD(Resource Data): 자원 데이터, 자원 레코드의 유형 값에 따라 내용의 구성과 크기가 달라진다.

🔹 자원 레코드 종류

레코드 타입	설명
A	도메인 → IPv4 주소 변환
AAAA	도메인 → IPv6 주소 변환
CNAME	도메인 → 별칭(alias) 설정
MX	메일 서버 정보
NS	특정 도메인의 네임 서버 정보

📌 네임 서버와 해석기

해석기 (Resolver)

✅ 해석기는 사용자가 입력한 도메인 이름을 IP 주소로 변환하는 과정의 시작점

🔹 인증 데이터와 캐시 데이터

인증 데이터: 해당 데이터를 직접 관리하는 네임 서버로부터 받은 정보
캐시 데이터: 이전 요청에 의해 호스트가 보관하던 데이터

요청의 처리

✅ DNS 질의는 두 가지 방식으로 수행

🔹 재귀적 질의

클라이언트가 로컬 네임 서버에 질의하면, 로컬 네임 서버가 스스로 최종 응답을 찾아서 반환

클라이언트는 중간 과정을 알 필요 없이 최종 결과만 받음

Resolver <-> Local Name Server <-> Name Server1 
                           <-> Name Server2 
                           <-> Target Name Server (최종 응답 반환)

🔹 반복적 질의

클라이언트가 직접 여러 개의 네임 서버에 질의

네임 서버는 최종 IP 주소를 주는 것이 아니라, 다음 질의할 네임 서버를 안내

Resolver <-> Local Name Server 
     <-> Name Server1 
     <-> Name Server2 
     <-> Target Name Server (최종 응답 반환)

📌 DNS 프로토콜

DNS 메시지

✅ UDP 53번 포트를 사용하며, 메시지는 요청(Request)과 응답(Response)으로 구성

🔹 DNS 메시지 구조

| Header | Question | Answer | Authority | Additional |

Header: 요청 ID, 플래그, 질의 수 등 포함
Question: 클라이언트가 요청한 도메인 정보
Answer: 질의에 대한 응답 (IP 주소 등)
Authority: 권한 있는 네임 서버 정보
Additional: 추가 정보 (예: CNAME 레코드)

IoC Container

Wed, 26 Feb 2025 00:00:00 GMT

IoC Container는 객체의 생성, 관리 및 DI(Dependency Injection)을 담당하는 핵심 요소이다.

📌 IoC(Inversion of Control)

✅ 객체의 생성 및 제어 흐름을 개발자가 직접 관리하지 않고, 외부에서(컨테이너가) 관리하는 디자인 패턴

Bean

✅ Spring에서 IoC Container에 의해 관리되는 객체

핵심 개념

✅ IoC Container는 DI를 통해 객체 간 의존 관계를 느슨하게 만든다.
🔹 전통적인 방식

public class Car {
    private Engine engine;

    public Car() {
        this.engine = new Engine();
    }
}

Car 객체에 필요한 Engine() 객체를 직접 생성해 Car 객체가 Engine 객체에 강결합되어있다.

🔹 IoC 방식

@Component
public class Engine {
    public void start() {
        System.out.println("Engine Started!");
    }
}

@Component
public class Car {
    private final Engine engine;

    @Autowired
    public Car(Engine engine) { 
        this.engine = engine;
    }
}

IoC Container가 Car 객체에 Engine 객체를 주입(DI)해 결합을 느슨하게 만든다.

🔹 장점

결합도 감소
객체 관리 자동화
유지보수성 증가

Bean 등록 방법

Spring IoC 컨테이너에서 Bean을 등록하는 방법은 크게 세 가지가 있다.

방법	설명	사용 예시	특징
XML 기반 설정	`beans.xml` 파일을 사용하여 Bean을 정의	`<bean id="myBean" class="com.example.MyBean"/>`	Spring의 초창기 방식으로 최근 거의 사용되지 않음
Java 기반 설정	`@Configuration` + `@Bean` 사용	`@Bean public MyBean myBean() { return new MyBean(); }`	Java 코드만으로 설정 가능해 가독성이 좋아 일부 경우 사용됨
Annotation 기반 설정 (자동 스캔)	`@Component`, `@Service`, `@Repository`, `@Controller` 사용	`@Component public class MyBean {}`	가장 많이 사용됨

DI 방식

🔹 생성자 주입

@Component
public class Car {
    private final Engine engine;

    @Autowired 
    public Car(Engine engine) {
        this.engine = engine;
    }
}

장점

불변성 보장: final 필드를 사용해 값이 변경되지 않도록 함
의존성 누락 방지: Bean 생성 시 주입이 강제됨
순환 의존성 감지 가능: 애플리케이션 실행 시 순환 의존성을 바로 감지해 예외 발생

🔹 필드 주입

@Component
public class Car {
    @Autowired
    private Engine engine;
}

장점

코드가 간결
테스트 시 쉽게 Mocking 가능(@MockBean 사용 가능)

단점

불변성 보장X
DI가 강제되지 않음: 객체가 생성된 후에도 null일 가능성이 있음
순환 의존성 감지 어려움: 실행 중 예외가 발생할 수 있음 필드 주입은 권장되지 않는다.

🔹 세터 주입

@Component
public class Car {
    private Engine engine;

    @Autowired
    public void setEngine(Engine engine) {
        this.engine = engine;
    }
}

장점

선택적 의존성 주입 가능: 필요할 때만 의존성을 변경할 수 있음
Spring 컨텍스트 없이도 객체 생성 가능: 테스트에 용이

단점

필드가 null일 수 있음: 주입하지 않으면 런타임 오류 발생 가능
객체의 일관성을 유지하기 어려움: 생성 후에도 값이 변경될 가능성이 있음

⭐️ Spring Boot 공식 문서에도 생성자 주입을 권장

📌 Container의 종류

BeanFactory

✅ 가장 기본적인 IoC 컨테이너 인터페이스

🔹 Bean 생성 시점
getBean() 호출 시 생성

ApplicationContext

✅ BeanFactory를 확장한 형태로, 보다 다양한 기능 제공

🔹 Bean 생성 시점
컨테이너 초기화 시점에서 미리 생성

🔹 장점

AOP 지원 (Transaction, Security와 쉽게 결합 가능)
Event 시스템과 통합
국제화(i18n) 지원을 통한 다국어 메시지 관리

Spring Boot에서는 자동으로 ApplicationContext를 IoC 컨테이너로 사용한다.

📌 동작 과정

설정 파일(XML, Java Config, Annotation) 읽기
Bean 등록 (Bean Definition 생성)
Bean 객체 생성 및 초기화 (@PostConstruct, InitializingBean 등)
의존성 주입 (DI 적용)
애플리케이션 실행 후 Bean 사용
애플리케이션 종료 시 Bean 소멸 (@PreDestroy, DisposableBean 등)

📌 참고

https://docs.spring.io/spring-framework/reference/core/beans.html

Structured Logging

Tue, 25 Feb 2025 00:00:00 GMT

📌 Spring Logging 개요

✅ Log는 애플리케이션의 동작을 추적하고 문제를 진단하는 중요한 기능
✅ Spring은 다양한 로깅 프레임워크를 지원하며, 기본적으로 SLF4J를 권장

📌 SLF4J(Simple Logging Facade For Java)

✅ SLF4J는 다양한 구현체(Logback, Log4j 등)과 연동 가능한 추상화 계층 제공

주요 특징

🔹 로깅 구현체에 대한 의존성 제거

인터페이스를 제공해 실제 로그 처리 구현을 위임
런타임에 원하는 로깅 프레임워크로 변경 가능

🔹 유연한 로깅 프레임워크 변경 가능

설정만 변경하면 SLF4J API만 사용해 구현체 변경 가능

🔹 바인딩 개념을 사용해 로깅 프레임워크 연결

로깅 구현체의 바인딩을 추가해 로그 출력

구조

🔹 SLF4J API

로깅을 위한 공통 인터페이스

🔹 SLF4J 바인딩

SLF4J와 실제 로깅 구현체를 연결하는 역할

🔹 로깅 구현체

실제 로그를 출력하는 엔진

주요 인터페이스

Logger.java

package org.slf4j;

public interface Logger {
    String getName();

    boolean isTraceEnabled();
    void trace(String msg);
    void trace(String format, Object arg);
    void trace(String format, Object arg1, Object arg2);
    void trace(String format, Object... arguments);
    void trace(String msg, Throwable t);

    boolean isDebugEnabled();
    void debug(String msg);
    ...

    boolean isInfoEnabled();
    void info(String msg);
    ...

    boolean isWarnEnabled();
    void warn(String msg);
    ...

    boolean isErrorEnabled();
    void error(String msg);
    ...
}

위 인터페이스는 로깅을 위한 기본 메서드들을 정의하며, 모든 구현체는 위 인터페이스를 구현해야 한다.
팩토리 패턴으로 실제 Logger 구현체가 생성된다.

📌 Log Level

✅ 애플리케이션에서 로깅할 메시지의 중요도를 나타내는 설정
✅ 필요하지 않은 로그를 줄이고, 중요한 정보를 쉽게 확인 가능

로그 레벨	설명	사용 예시
TRACE	가장 상세한 로그, 디버깅용	내부 흐름 추적 (잘 사용되지 않음)
DEBUG	디버깅을 위한 상세 로그	개발 시 코드 흐름 확인
INFO	일반적인 실행 정보	서비스 실행, 주요 이벤트 로깅
WARN	잠재적인 문제 경고	성능 저하, 예상치 못한 동작
ERROR	심각한 오류 로그	예외 발생, 시스템 장애

🔹 Spring Boot의 기본 로그 레벨은 INFO
🔹 application.properties에서 로그 레벨 설정 가능

logging.level.root=DEBUG

🔹 운영 환경에서는 INFO, 개발 환경에서는 DEBUG 권장

📌 SLF4J의 구현체

Logback

✅ Spring Boot의 기본 로깅 구현체

🔹 특징

SLF4J의 공식 구현체
XML 및 Groovy 기반 설정 가능
RollingFileAppender를 통한 로그 롤링 지원

Log4j2

✅ Log4j2는 Log4j의 개선된 버전으로, 성능과 확장성이 뛰어난 로깅 프레임워크
✅ Logback보다 성능이 더 좋고 비동기 로깅 가능

🔹 특징

비동기 로깅 지원
JSON, YAML, XML 설정 파일 지원
Garbage-Free(GC-Free) 로깅으로 메모리 사용 최적화

🔹 Spring Boot에서 Log4j2 사용
기존 Logback을 제외시키고, Log4j2를 추가해야 한다.

dependencies {
	implementation "org.springframework.boot:spring-boot-starter-log4j2"
	modules {
		module("org.springframework.boot:spring-boot-starter-logging") {
			replacedBy("org.springframework.boot:spring-boot-starter-log4j2", "Use Log4j2 instead of Logback")
		}
	}
}

📌 MDC(Mapped Diagnostic Context)

✅ 각 요청마다 관련된 데이터를 유지하고 로그에 자동으로 포함할 수 있도록 도와주는 Key-Value 저장소
✅ 내부적으로 ThreadLocal을 사용해 각 쓰레드마다 저장소를 유지

특징

🔹 요청 단위 로그 추적 가능

같은 요청에서 발생하는 모든 로그에 공통된 정보를 자동으로 추가 가능

🔹 key-value 기반 저장
🔹 로그 자동 출력

MDC에 저장된 값들을 로깅 구현체 설정을 통해 자동으로 로그에 포함 가능

📌 Structured Log

✅ 단순한 문자열 형태가 아닌 JSON이나 key-value 형식으로 기록하는 로깅 기법
✅ 로그 분석, 검색, 필터링에 최적화됨 (ELK, Grafana와 연동 가능)

장점

🔹 검색 및 필터링 용이
🔹 로그 데이터 시각화 가능

ELK(Elasticsearch, Logstash, Kibana), Grafana 등의 로그 분석 도구와 쉽게 연동 가능
로그 데이터를 차트, 그래프 형태로 분석 가능

🔹 JSON 포맷을 사용한 머신러닝 분석 가능

빅데이터 분석이나 머신러닝 모델 학습에 활용 가능

🔹 검색 및 필터링 용이

MSA에서 각 서비스와 로그를 공통된 JSON 포맷으로 통합 가능

🔹 검색 및 필터링 용이

Format

✅ 기본적으로 출력되는 JSON 로그는, 설정된 포맷에 맞게 MDC 값을 활용하여 자동으로 생성

🔹 ECS
ElasticSearch와 호환되는 표준 로그 형식 설정

logging.structured.format.console=ecs
logging.structured.format.file=ecs

예시

{
  "@timestamp": "2025-02-25T12:00:00.123Z",
  "log.level": "INFO",
  "message": "User login successful",
  "event.category": "authentication",
  "event.action": "user_login",
  "user.id": "567",
  "user.name": "john_doe",
  "http.request.method": "POST",
  "http.response.status_code": 200
}

🔹 GELF
Graylog에 최적화된 로그 형식 설정

logging.structured.format.console=gelf
logging.structured.format.file=gelf

예시

{
  "version": "1.1",
  "host": "server-1",
  "short_message": "User login successful",
  "full_message": "User john_doe logged in from IP 192.168.1.100",
  "timestamp": 1708886400.123,
  "level": 6,
  "_user_id": "567",
  "_ip_address": "192.168.1.100",
  "_http_method": "POST"
}

🔹 Logstash
Logstash에서 수집하고 처리하기 최적화된 로그 형식

logging.structured.format.console=logstash
logging.structured.format.file=logstash

예시

{
  "timestamp": "2025-02-25T12:00:00.123Z",
  "level": "INFO",
  "message": "User login successful",
  "service": "UserService",
  "user_id": "567",
  "ip_address": "192.168.1.100",
  "http_method": "POST"
}

📌 궁금한 점

Structured Logging은 어떻게 활용할까?

아래는 개인적인 의견입니다.

먼저, Logging에 대한 응집도와 핵심 로직 분리를 위해 아래와 같은 방법을 사용하는 것이 좋을 것 같다.

Spring Filter 이용
Spring AOP에서 자동 설정

요청이 시작될 때부터 끝날 때까지 가져야할 공통 필드는 Filter에서부터 처리하고,
특정 Layer의 메서드를 호출할 때와 같이 로깅 부가 기능을 분리할 때는 AOP를 사용하는 것이 좋을 것 같다.

user.id를 filter를 활용해 공통 필드로 추가해보자.

application.properties

logging.structured.format.console=logstash

JsonLogFilter.java

@Component  
public class JsonLogFilter implements Filter {  
  
    @Override  
    public void doFilter(final ServletRequest request, final ServletResponse response,  
        final FilterChain chain)  
        throws IOException, ServletException {  
  
        try {  
            String userId = "example userId";  
            MDC.put("user.id", userId);  
            chain.doFilter(request, response);  
        } finally {  
            MDC.clear();  
        }  
    }  
}

log

{
   "@timestamp":"2025-02-25T23:26:59.796577+09:00",
   "@version":"1",
   "message":"test log",
   "logger_name":"com.example.javacicdpractice.member.MemberController",
   "thread_name":"http-nio-8080-exec-1",
   "level":"INFO",
   "level_value":20000,
   "user.id":"example userId"
}

user.id가 로그에 정상적으로 추가되었다.

📌 참고

https://docs.spring.io/spring-boot/how-to/logging.html https://docs.spring.io/spring-boot/reference/features/logging.html#features.logging.log-levels

기존 Layered Architecture에 대한 고민

Sun, 23 Feb 2025 00:00:00 GMT

이 글은 이전에 기록한 글을 바탕으로 작성된 글입니다.

📌 배경

처음 개발을 시작했을 때, 3-tier Layered Architecture를 많이 사용했다. 그러나 프로젝트 규모가 커질수록 애플리케이션의 복잡성이 증가했고, 기능을 수정하거나 확장하는 것이 점점 어려워졌다.

이 문제를 해결하기 위해 객체지향의 본질에 대해 공부하며 고민하기 시작했다. 그리고 가장 중요한 도메인 로직에 집중하지 못하고 있다는 점을 깨달았고, 이를 해결하기 위해 아키텍처를 개선하게 되었다.

📌 3-tier Layered Architecture

3-tier Layered Architecture는 서버 개발을 처음 시작할 때 많이 사용하는 구조다.

Controller: 클라이언트 요청을 처리
Service: 비즈니스 로직을 담당
Repository: 데이터를 영속화 이 아키텍처의 가장 큰 장점은 쉽고 빠르게 애플리케이션을 개발할 수 있다는 점이다. 그러나 복잡한 애플리케이션을 구현하기에는 한계가 있다.

3-tier Layered Architecture의 단점

🔹 낮은 확장성과 유지보수성
이 구조에서 애플리케이션을 개발할 때, 일반적으로 다음 두 가지 접근 방식을 택한다.

Controller부터 개발 → 프레임워크와 API 설계 아키텍처에 의존하게 된다.
Entity와 Repository부터 개발 → DB 중심의 사고방식이 형성된다. 어떤 접근을 택하든, Service 계층이 모든 핵심 로직을 담당하게 되고, 결국 절차지향적이고 DB 중심적인 애플리케이션이 만들어진다. 이는 확장성과 유지보수성을 저해하는 핵심적인 문제점이다.

🔹 낮은 Testablility
Service 계층은 복잡한 의존성을 가지며, 단위 테스트가 어렵다.

테스트를 진행하더라도 인수 테스트나 슬라이스 테스트와 같은 중간 규모 테스트가 많아지고, 시간이 오래 걸린다.
핵심 로직을 효과적으로 검증하기 어려워 디버깅이 힘들어진다. 이러한 문제 역시 DB 중심적이고 절차지향적인 설계 때문이라고 볼 수 있다.

개선 방향

이 문제를 해결하려면 객체 간의 협력 관계를 고려한 설계가 필요하다.

각 도메인의 책임을 명확히 정의하고,
각 책임이 어떤 행동을 수행할지 고민해야 한다. 즉, 도메인 로직에 집중하는 아키텍처를 설계해야 한다.

📌 개선된 Layered Architecture

새로운 아키텍처에서는 표현 계층의 역할은 기존 3-tier 구조와 유사하다. 하지만 Application 계층과 Infrastructure 계층의 역할을 재정립하여 확장성과 유지보수성을 높였다.

Application 계층

기존 3-tier 구조의 가장 큰 문제는 Service 객체가 핵심 로직을 직접 처리한다는 점이다.
이로 인해 도메인 객체 간의 유기적인 협력 관계를 구성하지 못한다.

🔹 개선된 Application 계층의 역할

Service 객체는 비즈니스 로직을 직접 수행하지 않는다.
대신, 도메인 객체들이 협력할 수 있도록 조정하는 역할만 담당한다.
즉, Service 계층은 도메인 객체 간 협력의 장을 만들어주는 역할을 한다.

Infrastructure 계층

Infrastructure 계층은 구현 기술을 담당하며, 이를 통해 DIP를 적용하여 상위 계층(도메인 및 서비스 계층)이 특정 기술에 직접 의존하지 않도록 한다.

기존 구조에서는 Service 계층이 특정 구현체에 강하게 결합되어 있었다. 따라서 구현이 변경될 경우, Service 계층도 함께 수정해야 하므로 유지보수 비용이 증가했다. 이를 해결하기 위해 도메인 객체의 역할을 추상화한다.

🔹 DIP 적용 방식

Service 계층은 구현체가 아니라, 추상화된 역할(인터페이스)에 의존한다.
구현체는 Infrastructure 계층에서 구현하여 Service 계층과의 의존성을 느슨하게 만든다.

예를 들어, Service 객체에서 교통수단 도메인을 이용한다고 해보자.

기존 구조에서는 위처럼 Service 객체가 구현체에 강결합되어 있었다.

개선된 구조에서는 위처럼 유연한 구조가 된다.

Infrastructure 계층은 이처럼 상위 계층이 특정 구현체에 강결합되는 것을 방지해준다.

장점

🔹 확장성과 유지보수성 향상

DIP를 적용함으로써 OCP(개방-폐쇄 원칙)와 DIP(의존성 역전 원칙)를 만족한다.
결과적으로 도메인의 확장과 변경이 용이해진다.

🔹 테스트 용이성(Testability) 증가

도메인 객체의 가짜(Fake) 구현체를 사용하여 Service 계층을 단위 테스트할 수 있다.
핵심 로직을 도메인 계층에서 담당하므로 소규모 단위 테스트가 가능해진다.

🔹 도메인 중심 설계 가능

도메인 객체 간의 협력 관계를 먼저 고려하여 애플리케이션을 설계할 수 있다.
이는 결과적으로 비즈니스 로직을 더 효과적으로 모델링할 수 있도록 돕는다.

DispatcherServlet의 동작 과정

Sat, 22 Feb 2025 00:00:00 GMT

✅ Spring MVC에서 프론트 컨트롤러 역할을 하는 핵심 서블릿
✅ 모든 HTTP 요청을 받아 적절한 컨트롤러로 전달하고, 응답을 생성하여 클라이언트에게 반환

📌 Front Controller 패턴

✅ 모든 요청을 한 곳에서 처리하고, 이후 적절한 컨트롤러로 위임하는 패턴

만약 DispatcherServlet이 없다면, Servlet 컨테이너가 요청에 맞는 핸들러를 찾아야하며, 모든 요청마다 개별 서블릿을 사용해야 한다. 따라서 모든 요청을 DispatcherServlet이 처리하도록 하는 프론트 컨트롤러 패턴이 적용된다.

장점

모든 요청을 프론트 컨트롤러에서 관리하여 중복을 줄일 수 있음
컨트롤러 별로 로직을 분리하면서도, 공통 작업(예: 보안, 로깅)을 프론트 컨트롤러에서 처리 가능

📌 요청 처리 과정

DispatcherServlet에 요청이 전달
DispatcherServlet이 HandlerMapping를 활용해 적절한 핸들러를 조회
DispatcherServlet이 HandlerAdapter를 활용해 해당 핸들러를 실행
핸들러가 작성된 비즈니스 로직대로 요청을 처리
핸들러가 반환값 반환
핸들러 어댑터가 반환값 처리
DispatcherServlet이 응답 반환

HandlerMapping

✅ 요청을 분석하여 어떤 컨트롤러가 처리할지 결정
✅ 적절한 컨트롤러를 찾아 반환

HandlerMapping.class

public interface HandlerMapping {  
    @Nullable  
    HandlerExecutionChain getHandler(HttpServletRequest request) throws Exception;  
}

🔹 getHandler(request)
요청을 분석해 적절한 HandlerExecutionChain를 반환

🔹 HandlerExecutionChain
HandlerMapping이 찾은 핸들러(컨트롤러)와 해당 핸들러에 적용할 HandlerInterceptor(인터셉터)들을 함께 관리하는 객체

DispatcherServlet.class

protected HandlerExecutionChain getHandler(HttpServletRequest request) throws Exception {  
    if (this.handlerMappings != null) {  
        Iterator var2 = this.handlerMappings.iterator();  
  
        while(var2.hasNext()) {  
            HandlerMapping mapping = (HandlerMapping)var2.next();  
            HandlerExecutionChain handler = mapping.getHandler(request);  
            if (handler != null) {  
                return handler;  
            }  
        }  
    }  
  
    return null;  
}

HandlerAdapter

✅ HandlerMapping이 찾아준 컨트롤러를 실행하는 역할

HandlerAdapter.class

public interface HandlerAdapter {  
    boolean supports(Object handler);  
  
    @Nullable  
    ModelAndView handle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception;   
}

🔹 supports(handler)
해당 핸들러(컨트롤러)가 이 HandlerAdapter에서 실행할 수 있는지 확인하는 메서드

🔹 handle(request, response, handler)
HandlerMapping이 반환한 컨트롤러를 실행하는 메서드

DispatcherServlet.class

protected HandlerAdapter getHandlerAdapter(Object handler) throws ServletException {  
    if (this.handlerAdapters != null) {  
        Iterator var2 = this.handlerAdapters.iterator();  
  
        while(var2.hasNext()) {  
            HandlerAdapter adapter = (HandlerAdapter)var2.next();  
            if (adapter.supports(handler)) {  
                return adapter;  
            }  
        }  
    }  
}

📌 궁금했던 점

어떻게 다양한 타입의 응답 데이터를 처리할까?

RequestMappingHandlerAdapter.class 핸들러의 반환 응답 형식에 따라 분기하여 반환값을 처리한다.

private List<HandlerMethodReturnValueHandler> getDefaultReturnValueHandlers() {  
    List<HandlerMethodReturnValueHandler> handlers = new ArrayList(20);  
    handlers.add(new ModelAndViewMethodReturnValueHandler());  
    handlers.add(new RequestResponseBodyMethodProcessor(this.getMessageConverters(), this.contentNegotiationManager, this.requestResponseBodyAdvice));
    ...
    return handlers;
    }

DispatcherServlet이 다양한 응답 형식을 어떻게 추상화해서 반환하는가?

DispatcherServlet은 실제로는 응답을 반환하는 것이 아닌 HttpServletResponse에 응답 데이터가 기록되도록 한다. 따라서 다양한 HandlerMethodReturnValueHandler가 HttpServletResponse에 응답 데이터를 기록한다.

DispatcherServlet.class

protected void doDispatch(HttpServletRequest request, HttpServletResponse response) throws Exception {
    HandlerExecutionChain mappedHandler = getHandler(request);
    if (mappedHandler == null) {
        noHandlerFound(request, response);
        return;
    }

    HandlerAdapter ha = getHandlerAdapter(mappedHandler.getHandler());
    
    // 🚀 컨트롤러 실행
    ModelAndView mv = ha.handle(request, response, mappedHandler.getHandler());

    // 🚀 반환된 결과를 처리
    processDispatchResult(request, response, mappedHandler, mv, null);
}

📌 참고

https://docs.spring.io/spring-framework/reference/web/webmvc/mvc-servlet.html https://mangkyu.tistory.com/18

WAS와 Servlet

Fri, 21 Feb 2025 00:00:00 GMT

📌 WAS(Web Application Server)

✅ Servlet을 실행하고 관리하는 서버 (Servlet 컨테이너 역할)
✅ HTTP 요청을 처리하고, Servlet을 통해 동적인 웹 페이지를 생성하여 클라이언트에게 응답
✅ 대표적인 WAS: Apache Tomcat

배경

🔹 기존 솔루션의 한계
과거에는 단순한 HTML, CSS, 이미지 등의 정적 파일을 제공하는 웹 서버(Apache, Nginx) 만 존재했다.
웹이 발전함에 따라 사용자의 요청에 따른 동적인 처리가 필요해졌다.

🔹 기존 솔루션의 한계 해결

WAS = 웹 서버 + 웹 컨테이너
정적 컨텐츠는 웹 서버가 제공하고, 동적 컨텐츠는 웹 컨테이너가 제공
웹 컨테이너는 서블릿을 실행하고 관리
웹 컨테이너에서 동적인 데이터를 처리하는 역할을 하는 것이 서블릿

동작 흐름

클라이언트 → HTTP 요청 (GET /hello)
WAS → 요청을 받아 Servlet 실행 (HelloServlet)
Servlet → 동적 응답을 생성하여 응답 (Hello, Servlet!)
WAS → 클라이언트에게 최종 응답 전달

📌 Servlet

✅ HTTP 요청을 받아 동적인 처리를 수행하고, HTML 또는 JSON 등의 응답을 생성
✅ 대표적인 Servlet: DispatcherServlet

동작 흐름

클라이언트 요청을 받아 동적 데이터 생성
- 비즈니스 로직, 외부 시스템과 연동 등
동적인 HTML 또는 JSON을 생성하여 클라이언트에게 반환

라이프사이클 메서드

🔹 init()
Servlet이 처음 생성될 때 한 번 실행 (초기화 작업 수행)

🔹 service()
HTTP 요청이 들어올 때마다 실행 (요청 처리)

🔹 destroy()
Servlet이 제거될 때 한 번 실행 (자원 해제)

📌 Spring MVC

✅ WAS 내에서 서블릿을 기반으로 동작하는 웹 프레임워크
✅ DispatcherServlet이라는 서블릿을 기반으로 동작

📌 참고

https://docs.spring.io/spring-framework/reference/web/webmvc.html https://www.youtube.com/watch?v=F_vBAbjj4Pk

Service Discovery

Tue, 18 Feb 2025 00:00:00 GMT

✅ 서비스 인스턴스를 자동으로 등록하고 검색 가능
✅ IP 주소가 동적으로 변경되어도 항상 최신 정보를 제공
Netflix Eureka는 Netflix OSS(Open Source Software)에서 제공하는 Service Discovery(서비스 디스커버리) 서버 및 클라이언트 라이브러리
마이크로서비스 환경에서 동적으로 서비스 인스턴스를 등록하고 검색할 수 있도록 도움

📌 Netflix Eureka 구성 요소

Eureka는 클라이언트/서버 아키텍처로 구성되며, Eureka Server와 Eureka Client로 구분

구성 요소	역할
Eureka Server	서비스 등록 및 검색을 관리하는 중앙 서버
Eureka Client	Eureka Server에 서비스 등록 및 조회하는 클라이언트

✅ Eureka Server는 독립적인 서비스로 실행되며, Eureka Client가 이를 사용하여 서비스를 등록하고 조회

Eureka Server

✅ Netflix에서 제공하는 Servcie Discovery Server 라이브러리
✅ MSA에서 서비스 등록 및 검색 기능 제공

📌 Netflix Eureka Server의 역할

✅ 서비스 등록: 마이크로서비스가 실행되면서 Eureka Server에 자신을 등록
✅ 서비스 검색: 마이크로서비스가 Eureka Server에서 다른 서비스의 위치(IP, 포트)를 조회
✅ 헬스 체크

서비스가 정상적으로 실행되고 있는지 주기적으로 상태를 체크(heartbeat)
일정 시간 응답이 없으면 자동으로 해당 서비스 제거

📌 Netflix Eureka Server 설정 및 실행

✅ build.gradle

implementation 'org.springframework.cloud:spring-cloud-starter-netflix-eureka-server'

✅ .java

@SpringBootApplication  
@EnableEurekaServer  
public class DiscoveryserviceApplication {  
  
    public static void main(String[] args) {  
        SpringApplication.run(DiscoveryserviceApplication.class, args);  
    }  
  
}

@EnableEurekaServer: 해당 서버를 discovery service로 지정

✅ 설정 파일

server:  
  port: 8761  
spring:  
  application:  
    name: discoveryservice  
eureka:  
  client:  
    register-with-eureka: false  
    fetch-registry: false

application.name: 해당 애플리케이션 서버의 이름(고유한 id)
register-with-eureka: discovery service에 client로 등록할 것인지에 대한 설정값
fetch-registry: 다른 서비스의 정보를 가져오는지 여부

✅ 서버 실행

Eureka Server에서 제공하는 대시보드 조회 가능
어떤 인스턴스가 등록되었는지 확인 가능

Netflix Eureka Client

✅ Eureka Server에 자신을 등록하고, 다른 서비스의 위치를 조회 가능

📌 Netflix Eureka Client 설정 및 실행

✅ build.gradle

implementation 'org.springframework.boot:spring-boot-starter-web'  
implementation 'org.springframework.cloud:spring-cloud-starter-netflix-eureka-client'

✅ 설정 파일

server:  
  port: 9001
spring:  
  application:  
    name: user-service
  
eureka:
  client:  
    fetch-registry: true  
    register-with-eureka: true  
    service-url:  
      defaultZone: http://localhost:8761/eureka

application.name: 해당 애플리케이션 서버의 이름(고유한 id)
register-with-eureka: discovery service에 client로 등록
fetch-registry: 다른 서비스의 정보를 가져올 것

✅ 서버 실행

인스턴스가 정상적으로 등록
현재는 port가 명시적으로 지정되어 있기 때문에 Scale Out 시 여러 User Service 인스턴스를 등록할 수 없다.

📌 Random Port 설정

✅ 설정 파일

server:  
  port: 0  
spring:  
  application:  
    name: user-service  
  
eureka:  
  instance:  
    instance-id: ${spring.application.name}:${spring.application.instance_id:${random.value}}  
  client:  
    fetch-registry: true  
    register-with-eureka: true  
    service-url:  
      defaultZone: http://localhost:8761/eureka

server.port : 0: 사용 가능한 포트를 자동 할당
instance-id
- Eureka는 기본적으로 host ip : service name : port를 기준으로 서비스 인스턴스를 등록
- 동일한 User Service를 여러 개 실행하면 위 값이 동일하여 문제 발생 가능
- 이를 해결하기 위해 instance-id를 고유한 값으로 설정하여 각 인스턴스를 개별적으로 인식

✅ 서버 실행

두 user-service 인스턴스가 정상적으로 등록

상위 계층

Mon, 17 Feb 2025 00:00:00 GMT

상위 계층의 이해

OSI 7계층 모델에서 상위 계층인 세션 계층, 표현 계층, 응용 계층은 사용자 프로그램으로 구현되는데, 일반적으로 세 계층의 기능이 하나의 프로그램으로 묶여 구현된다.

계층	역할
세션 계층 (Session Layer, 5계층)	통신 세션 관리 (연결 설정, 유지, 해제)
표현 계층 (Presentation Layer, 6계층)	데이터 변환, 압축, 암호화
응용 계층 (Application Layer, 7계층)	사용자와 네트워크 간 인터페이스 제공

세션 계층

✅ 통신 세션을 설정, 유지, 해제하는 기능을 담당한다.
✅ 데이터 송수신 시 동기화를 수행하여, 중단 시 다시 연결할 수 있도록 지원한다.
✅ 응용 계층 간의 데이터 교환을 관리하며, 송수신 흐름을 제어한다.

📌 세션 연결

기능	설명
세션 설정 (Session Establishment)	응용 프로세스 간 통신 세션을 설정
세션 유지 (Session Maintenance)	오류 발생 시 재전송을 통해 연결 유지
세션 해제 (Session Termination)	통신이 끝나면 세션을 정상적으로 종료

📌 동기

✅ 동기 기능은 통신 양단에서 서로 동의하는 논리적인 공통 처리 지점, 즉 동기점을 지정하기 위해 사용한다.
✅ 메시지 전송 과정에서 발생하는 오류를 복구하기 위해 동기점을 설정한다.

📌 토큰

✅ 세션 계층은 두 응용 프로세스의 대화를 관리하기 위해 토큰이라는 특수 메시지를 사용한다.

🔹 토큰의 종류

종류	역할
데이터 토큰	데이터를 전송할 수 있는 권리를 제공
해제 토큰	통신 양단 간의 연결 해제 과정을 제어
동기 토큰	동기 처리가 필요한 지점에 사용

📌 동기

✅ 세션 계층에서는 통신 중 오류가 발생할 경우를 대비해 동기화 지점을 설정한다.
✅ 동기화를 통해 중단된 데이터 전송을 특정 지점부터 다시 시작할 수 있다.

동기화 방식	설명
일반 동기 (Minor Synchronization)	작은 단위의 데이터 복구용
주 동기 (Major Synchronization)	전체 데이터 복구용

📌 세션 연결 (Session Connection)

✅ 세션 계층에서 제공하는 연결은 응용 프로세스가 다른 응용 프로세스에 세션을 설정하기 위해 사용한다.

🔹 다중 세션 연결 서버

다수의 클라이언트 프로세스에 동시에 여러 세션 연결을 설정할 수 있는 서버
멀티스레딩 또는 비동기 I/O 방식을 사용해 다중 연결을 처리
ex) 웹 서버, 게임 서버, 채팅 서버 등

🔹 단일 세션 연결 서버

한 번에 하나의 클라이언트만 연결할 수 있는 서버
새로운 클라이언트가 연결 요청 시, 기존 연결을 종료하거나 대기
ex) 텔넷, FTP 등

표현 계층

✅ 응용 프로세스 사이 전송되는 메시지의 표현 방법을 다룬다.
✅ 송신 프로세스가 전달하는 의미를 수신 프로세스에서 정확히 이해할 수 있도록 한다.

📌 데이터 표현

✅ 네트워크에서 송수신되는 데이터를 응용 프로그램이 이해할 수 있도록 변환한다.
✅ 데이터 변환 작업을 수행하여, 서로 다른 시스템 간 호환성을 유지한다.

🔹 주요 변환 방식

변환 방식	설명	예시
문자 인코딩 변환	ASCII ↔ Unicode 변환	다국어 지원
파일 형식 변환	JPEG ↔ PNG 변환	이미지 변환
데이터 구조 변환	Big-endian ↔ Little-endian 변환	CPU 구조 차이 해결

📌 데이터 압축

✅ 네트워크 대역폭을 절약하고 전송 속도를 향상시키기 위해 데이터를 압축한다.

압축 방식	설명	예시
무손실 압축	데이터 손실 없이 크기 축소	ZIP, PNG
손실 압축	품질 저하를 허용하며 크기 축소	MP3, JPEG

손실 압축을 사용하는 이유는 비손실 압축에 비해 압축 데이터의 크기가 작기 때문이다.

응용 계층

✅ 하부 계층을 이용해 사용자에게 편리한 응용 환경을 제공한다.
✅ 운영체제에서 제공되는 계층 4의 인터페이스를 사용해 통신 기능을 구현한다.

MSA 개요

Fri, 14 Feb 2025 00:00:00 GMT

소프트웨어 아키텍처

현재 많은 시스템이 탄력적이고 Cloud Native 환경으로 구축되어 있다.

📌 주요 특징

✅ Auto scailing: 자동 확장성을 갖는다. 자동으로 인스턴스를 증가할 수 있는 환경이다.
✅ Microservices: 전체 서비스를 구축하고 있는 개별적인모듈이나 기능을 독립적으로 개발하고 배포하고 운영할 수 있도록 세분화된 서비스
✅ Chaos engineering: 시스템에 어떤 변동이나 불확실성에 대해서도 안정적인 서비스 제공
✅ Continuous deployments: 수많은 마이크로 서비스를 비리드하고 배포함에 있어 자동화된 시스템을 구축하고 하나의 작업에서 다른 작업으로 연계되는 과정을 파이프라인으로 연결

Cloud Native

클라우드 환경을 최대한 활용하도록 설계된 시스템 아키텍처를 의미한다.
전통적인 온프레미스 환경과 달리, 클라우드 네이티브 아키텍처는 확장성, 탄력성, 자동화, 장애 복구 등을 중심으로 설계된다.

📌 Architecture

✅ 확장 가능한 아키텍쳐

시스템의 수평적 확정에 유연
확장된 서버로 시스템의 부하 분산, 가용성 보장
시스템 또는 서비스 애플리케이션 단위의 패키지
모니터링

✅ 탄력적 아키텍쳐

서비스 생성 - 통합 - 배포, 비즈니스 환경 변화에 대응 시간 단축
분할된 서비스 구조
서비스의 추가와 삭제 자동 감지
변경된 서비스 요청에 따라 사용자 요청 처리(동적 처리)

✅ 장애 격리

특정 서비스에 오류가 발생해도 다른 서비스에 영향 주지 않음

Monolithic vs Microservice

📌 Monolithic

✅ 아키텍쳐

모든 업무로직이 하나의 애플리케이션 형태로 패키지 되어 서비스
애플리케이션에서 사용하는 데이터가 한 곳에 모여 참조되어 서비스되는 형태

✅ 장점

개발의 간소화
쉬운 테스트와 디버깅
직관적인 배포
운영의 단순성

✅ 단점

확장성의 한계
유연성 부족
유지 보수 어려움
배포 주기 지연
기술 선택의 어려움

📌 Microservice

✅ 아키텍쳐

애플리케이션을 여러 개의 독립적인 서비스로 나누어 개발, 배포, 운영

✅ 장점

확장성
유지보수 용이
빠른 배포
기술 스택 유연성
장애 격리
분산 개발

✅ 단점

운영 복잡성
데이터 일관성 유지 어려움
네트워크 오버헤드
분산 시스템 설계 필요
테스트 및 디버깅 어려움

Microservice Architecture란?

📌 특징

✅ 서비스 간 독립성을 유지하여 개별 배포 및 확장이 가능
✅ API 통신 방식으로 REST API, gRPC, 메시지 큐(Kafka, RabbitMQ) 등 사용 가능
✅ 부하 분산(Load Balancing) 및 스케일링 자동화 지원

📌 언제 도입해야 하나?

✅ MSA로 전환할만큼 시간과 비용이 있는가?
✅ 서비스들이 독립적으로 개발, 운영될 수 있는 경계가 잘 만들어져 있는가?
✅ 각 서비스들이 다른 서비스의 에러로부터 독립적인가?
✅ 서비스들마다 최적화된 언어가 다른가?

SOA vs MSA

📌 SOA(Service-Oriented Architecture)

✅ 여러 개의 독립된 서비스를 상호작용하는 방식으로 구성
✅ 각 서비스는 특정 비즈니스 기능을 수행하며, 이 서비스들을 조합하여 더 큰 시스템이나 애플리케이션을 구성

📌 차이점

✅ 서비스의 공유 지향점

SOA: 재사용을 통한 비용 절감
MSA: 서비스 간의 결합도를 낮춰 변화에 능동적으로 대응

✅ 기술 방식

SOA: 공통의 서비스를 ESB(Enterprise Service Bus)에 모아 사업 측면에서 공통 서비스 형식으로 서비스 제공
MSA: 각 독립된 서비스가 노출된 REST API, gRPC 등을 사용해 통신

✅ 서비스 크기

SOA: 비교적 크고 통합된 서비스
MSA: 작은 단위의 독립적인 서비스

MSA 구성요소

📌 External Gateway(API Gateway)

✅ 외부 클라이언트와 내부 마이크로서비스 간의 중간 관문 역할
✅ 클라이언트는 서비스로 직접 접근하지 않고 API Gateway를 통해 요청 ex) Spring Cloud Gateway, AWS API Gateway

📌 Service Mesh

✅ 마이크로서비스 간 통신을 관리하는 인프라 계층
✅ 내부 서비스 간 통신을 관리
ex) AWS App Mesh

📌 Runtime Platform

✅ 마이크로서비스를 실행하고 운영하는 환경으로, 컨테이너 오케스트레이션과 배포 담당
ex) Docker, K8s

📌 CI/CD Automation

✅ 마이크로서비스의 지속적 빌드, 배포를 자동화하는 시스템
ex) Jenkins, Github Actions

📌 Backing Services

✅ 마이크로서비스가 의존하는 외부 데이터 저장소, 메시지 큐, 캐시, 인증 서비스 등 모든 인프라 서비스
ex) MySQL, DynamoDB, Kafka, Redis

📌 Telemetry

✅ 마이크로서비스의 상태를 추적하고 모니터링
✅ 로그 분석, 분산 트레이싱, 성능 모니터링 등
ex) ELK Stack, Zipkin, Prometheus + Grafana

전송 계층

Thu, 13 Feb 2025 00:00:00 GMT

📌 전송 계층의 기능

주요 기능

전송 계층은 프로세스 간(end-to-end) 통신을 지원하며, 주요 기능은 다음과 같다.

기능	설명
세그먼트화(Segmentation) 및 재조립(Reassembly)	데이터를 작은 단위(세그먼트)로 나누고, 수신 측에서 원래 데이터로 복원
오류 제어(Error Control)	데이터 손상 및 손실을 감지하고 필요 시 재전송 수행 (TCP)
흐름 제어(Flow Control)	송신 속도를 조절하여 수신 측 과부하 방지 (TCP 슬라이딩 윈도우)
서비스 프리미티브	전송 계층 사용자가 전송 계층 서비스를 사용하기 위한 인터페이스

전송 계층은 신뢰성이 필요한 경우 TCP, 빠른 전송이 필요한 경우 UDP를 사용한다.

설계 시 고려 사항

전송 계층 설계 시 다음 요소를 고려해야 한다.

(1) 주소 표현

TSAP(Transport Service Access Point)는 전송 계층에서 프로세스를 식별하는 주소이다.
TSAP는 일반적으로 호스트의 IP 주소와 포트 번호의 조합으로 표현되며, 특정 애플리케이션으로 데이터를 전달하는 역할을 한다.
ex) 웹 서버의 IP가 203.0.113.10이고, 포트가 443(HTTPS)이라면, 이 조합이 TSAP를 구성

(2) 멀티플렉싱

여러 개의 애플리케이션 프로세스가 하나의 네트워크 연결을 공유하도록 하는 기술이다.
상방향 멀티플렉싱
- 여러 클라이언트(송신 호스트)가 하나의 서버(수신 호스트)에게 데이터 전송
하방향 멀티플렉싱
- 하나의 서버(송신 호스트)가 여러 클라이언트(수신 호스트)에게 데이터 전송
  ex) 서버가 여러 클라이언트에 비디오 스트리밍 전송

(3) 연결 설정

연결 설정
1️⃣ 클라이언트 → 서버 : SYN(x) 전송 (연결 요청)
2️⃣ 서버 → 클라이언트 : SYN(y) + ACK(x+1) 응답 (연결 수락 및 확인)
3️⃣ 클라이언트 → 서버 : ACK(y+1) 전송 (연결 완료)
- 이 과정에서 오류가 발생하면 재전송이 수행되며, 네트워크 상태에 따라 여러 번 반복될 수 있다.
연결 해제
- 일방적 연결 해제
  - 한쪽 프로세스에서 연결을 해제
- 점진적 연결 해제
  - 양쪽 프로세스 모두에서 연결을 해제

✅ 인터넷에서 네트워크 계층의 기능을 제공하는 프로토콜은 IP이다.
✅ IP 프로토콜 위에서 실행되는 전송 계층 프로토콜은 서비스의 유형에 따라 TCP와 UDP로 구분된다.
✅ TCP는 연결형 서비스를 지원하는 프로토콜이고, UDP는 비연결형 서비스를 지원하는 프로토콜이다.
✅ TCP와 UDP를 선택할 때는 단순히 신뢰성이나 연결 유무의 차이 뿐만 아니라 응용 프로그램의 구축에 어떤 영향을 끼치는지 이해해야 한다.

📌 TCP의 헤더 구조

🔹 TCP 주요 기능

연결형 서비스 제공
전이중 방식의 양방향 가상 회선 제공
신뢰성 있는 데이터 전송을 보장

TCP 헤더 구조

TCP는 신뢰성을 보장하기 위해 20~60바이트의 헤더를 포함하며, 주요 필드는 다음과 같다.

| Source Port | Destination Port |
| Sequence Number |
| Acknowledgment Number |
| Data Offset | Reserved | Flags | Window Size |
| Checksum | Urgent Pointer |
| Options (Optional) | Data |

🔹 TCP 헤더 필드 설명

필드	크기	설명
Source/Destination Port	16비트	송신자/수신자의 포트 번호
Sequence Number	32비트	데이터 순서 보장을 위한 순서 번호
Acknowledgment Number	32비트	수신 확인(ACK)
Flags	9비트	SYN, ACK, FIN 등 제어 플래그
Window Size	16비트	흐름 제어를 위한 윈도우 크기
Checksum	16비트	오류 검출

📌 포트 번호

포트 번호는 프로세스를 구분하는 주소 역할을 수행한다.

🔹 Well-known 포트 예시

프로토콜	포트 번호	설명
HTTP	80	웹 페이지 전송
HTTPS	443	보안 웹 페이지 전송
FTP	21	파일 전송
SSH	22	원격 로그인
DNS	53	도메인 이름 변환

🔹 포트 번호 범위

0~1023: Well-known 포트 (HTTP, FTP 등)
1024~49151: Registered 포트 (앱 개발자가 등록 가능)
49152~65535: Dynamic 포트 (임시 포트)

📌 TCP의 동작 원리

연결 설정 (3-Way Handshake)

1️⃣ 클라이언트 → 서버 : SYN 전송

TCP 헤더의 SYN 플래그를 지정
임의의 순서 번호(10) 설정

2️⃣ 서버 → 클라이언트 : SYN-ACK 응답

다음 수신에 대한 데이터의 순서 번호(10 + 1)를 Acknowledgment Number에 표시
임의의 순서 번호 설정(50)
이때 전송 데이터와 응답 데이터를 함께 전송하는 피기배킹 기능 사용

3️⃣ 클라이언트 → 서버 : ACK 전송 (연결 완료)

Fast Open

TCP 연결이 완전히 열리기 전 데이터를 전송할 수 있게 해주는 기능

🔹 동작 방식

서버는 클라이언트에게 TFO 쿠키 발급
클라이언트는 쿠기 저장
다음 서버 연결 시 SYN 패킷에 TFO 쿠키와 데이터를 함께 실어 전송
서버는 쿠키를 확인하고, handshake 도중에 데이터를 수신/처리 가능

흐름 요약

[최초 연결]
클라이언트 → 서버: SYN
서버 → 클라이언트: SYN-ACK + TFO 쿠키 발급

[이후 연결]
클라이언트 → 서버: SYN + DATA + TFO 쿠키
서버 → 클라이언트: SYN-ACK
(서버는 쿠키 확인 후 DATA 즉시 수신/처리 시작)

데이터 전송

TCP는 시퀀스 번호와 ACK를 통해 패킷 순서를 유지한다.

세 번째 세그먼트부터 데이터 전송이 이뤄진다.
A 프로세스는 순서 번호 11번부터 5바이트의 데이터를 전송하고, B 프로세스는 순서 번호 51부터 10바이트의 데이터를 전송한다.

TCP는 NAK를 사용하지 않는다.

다음에 수신할 데이터 번호를 Acknowledgment Number로 하여 ACK을 보낸다.
ACK을 받지 못한 송신자는 해당 데이터의 세그먼트를 재전송한다.

연결 해제 (4-Way Handshake)

1️⃣ 클라이언트 → 서버 : FIN 전송
2️⃣ 서버 → 클라이언트 : ACK, 데이터 전송
3️⃣ 클라이언트 → 서버 : ACK 전송
4️⃣ 서버 → 클라이언트 : FIN 전송
5️⃣ 클라이언트 → 서버 : ACK 전송(연결 종료)

연결 해제는 양쪽 프로세스의 동의하에 진행된다.

TIME_WAIT

✅ TCP 연결을 종료할 때, 연결이 잠시 기다리는 상태

🔹 종료 과정

클라이언트 → 서버 : FIN
서버 → 클라이언트 : ACK
서버 → 클라이언트 : FIN
클라이언트 → 서버 : ACK → 여기서 클라이언트는 TIME_WAIT 상태 진입해 일정 시간 기다렸다가 연결 종료

🔹 목적

지연된 패킷이 네트워크 상에 떠돌 경우 대비 -> 다른 연결로 진행될 경우 지연 패킷이 뒤늦게 도달해 문제 발생

🔹 TIME_WAIT 짧을 경우 문제

이전 연결이 완전히 종료되지 않은 상태에서 새 연결 요청이 갈 수 있다. -> RST 오류

이러한 경우, 연결 재사용 방식을 개선하거나 커널 설정 조절이 필요하다.

Keep-Alive

✅ TCP 연결이 끊겼는지 확인하기 위해, 유휴 상태에서도 주기적으로 "확인 메시지"를 보내는 메커니즘
✅ 애플리케이션 레벨이 아니라, 운영체제(OS)와 소켓 레벨에서 동작

🔹 필요성
다음과 같은 상황에선 연결을 끊어버린다.

네트워크 연결 끊김
상대방 프로세스가 죽음

연결을 끊지 않으면, 응답이 없는 채로 무한정 대기가 발생

🔹 동작 방식

소켓이 유휴 상태로 일정 시간 동안 아무 데이터도 주고받지 않으면
OS가 Keep-Alive probe라는 패킷을 상대방에게 보냄
상대방이 응답하면 → 연결 유지
응답이 없으면 → 일정 횟수 후 연결 종료

🔹 HTTP와 비교
✅ HTTP의 Keep-Alive는 연결을 재사용하기 위함
✅ TCP의 Keep-Alive는 OS 수준에서, 연결이 끊어졌는지 확인하기 위함

항목	HTTP Keep-Alive	TCP Keep-Alive
레벨	애플리케이션 계층	전송 계층 (OS/커널)
목적	연결 재사용 (성능 향상)	연결 생존 여부 확인 (오류 감지)
유지 시간	짧음 (몇 초~분)	김 (기본 2시간)
설정 위치	HTTP 헤더 / 웹 서버	커널 / 소켓 옵션
대상	브라우저 ↔ 서버 등	모든 TCP 연결 (DB, HTTP 등 포함)

📌 UDP 프로토콜

UDP 헤더 구조

🔹 UDP 주요 기능

비연결형 서비스를 제공
헤더와 전송 데이터에 대한 체크섬 기능 제공
Best Effort 전달 방식 지원
- 전송한 데이터그램이 목적지까지 제대로 도착했는지 확인하지 않는다.
- 데이터 전송 시간에 민감한 응용 환경에서 유리하다.

| Source Port | Destination Port | 
| Length | Checksum | 
| Data |

필드	크기	설명
Source/Destination Port	16비트	송신자/수신자의 포트 번호
Length	16비트	UDP 데이터그램의 전체 길이
Checksum	16비트	오류 검출

UDP의 데이터그램 전송

✅ 흐름 제어 및 오류 검출 없이 패킷을 빠르게 전송한다.
✅ 흐름 제어 및 오류 검출 기능이 없으므로, 응용 프로그램에서 다음과 같은 기능을 직접 구현해야 한다.

데이터그램 분실 감지: 수신 측에서 응답을 보내거나, 별도의 확인 메시지를 통해 패킷 손실 여부를 확인
데이터그램 순서 관리: 각 패킷에 순서 번호를 추가하여, 수신 측에서 올바른 순서로 데이터를 정렬

단계	설명
1️⃣	송신자가 데이터그램을 전송
2️⃣	수신자가 데이터그램을 수신
3️⃣	패킷 손실 발생 시 재전송 없음

📌 RTP 프로토콜

실시간 요구 사항

✅ RTP(Real-time Transport Protocol)는 오디오/비디오 전송을 위한 프로토콜
✅ 기존 UDP에 데이터그램의 순서 번호 기능을 추가
✅ 실시간 데이터 전송에서 가장 중요한 것은 전송 시간

🔹 버퍼
RTP에서 버퍼는 패킷 간격을 일정하게 유지하여 안정적인 스트리밍을 가능하게 한다.

패킷이 네트워크에서 불규칙한 간격으로 도착할 경우, 일정한 간격으로 데이터를 재생하기 위해 버퍼를 사용
버퍼 크기가 클수록 안정성이 증가하지만, 초기 지연(latency)이 증가할 수 있음
실시간성이 중요한 경우, 버퍼 크기를 최소화해야 한다.

🔹 지터(Jitter)
Jitter(지터)는 패킷 도착 시간의 변동을 의미하며, 네트워크 혼잡이나 경로 변경으로 인해 발생한다.

지터가 심하면 오디오/비디오 끊김 현상이 발생할 수 있다.
RTP는 지터 버퍼(jitter buffer)를 사용하여 안정적인 재생을 지원한다.

RTP의 데이터 전송

✅ UDP 기반으로 동작하여 빠른 전송 속도를 보장
✅ 데이터그램 분실이나 도착 순서 변경과 같은 전송 오류를 해결

믹서

여러 RTC 데이터 그램을 하나로 결합
다중 사용자 오디오/비디오 스트림 결합
장점
- 대역폭 절약, 다중 사용자 처리 가능
단점
- 믹싱으로 인해 지연 증가

트랜슬레이터

RTP 데이터그램을 하나 이상의 출력용 RTP 데이터그램으로 만들어주는 장치

RTP 헤더 구조

| Version | Padding | Extension | CC | Marker | Payload Type | 
| Sequence Number | Timestamp | 
| SSRC | CSRC (Optional) |

필드	설명
Version	RTP의 버전 번호이며, 현재 2로 지정된다.
Sequence Number	패킷의 순서를 유지하고, 손실된 패킷을 감지
Timestamp	RTP 페이로드에 포함된 데이터의 생성 시기를 나타낸다.

RTP 제어 프로토콜 (RTCP)

✅ RTCP는 RTP 스트림을 모니터링하고, 품질을 보장하기 위해 사용된다.
✅ 주요 기능

QoS와 혼잡 제어: 송수신 프로세스가 관련 보고서를 작성한다.
- 송신 프로세스: 전송률 등의 정보
- 수신 프로세스: 수신 과정에서 발생하는 패킷 분실이나 지터 등의 정보
세션 크기: 세션 참가자들 사이에 RTCP 패킷이 주기적으로 전송된다.

네트워크 계층

Tue, 11 Feb 2025 00:00:00 GMT

네트워크 계층은 패킷을 목적지까지 전달하는 역할을 담당한다. 이를 위해 IP 주소 체계, 이동 중 IP 유지, 네트워크 상태를 제어하는 다양한 프로토콜을 사용한다.

IPv6 프로토콜

✅ IPv6는 기존 IPv4의 한계를 해결하기 위해 등장한 차세대 인터넷 프로토콜
✅ 128비트 주소 체계를 사용하여 주소 고갈 문제 해결 [[IP 프로토콜]]

📌 주요 특징

128비트 주소 체계: IPv4(32비트)보다 확장된 주소 공간을 제공한다.
주소 자동 구성: DHCP 없이 자동으로 IP 주소 할당이 가능하다.
패킷 크기 고정: 패킷 크기를 고정해 QoS를 개선한다.
보안 강화
멀티캐스트 지원: 브로드캐스트를 제거하고 멀티 캐스트로 대체한다.
헤더 단순화: IPv4 대비 헤더 구조가 간소화된다.

📌 패킷 헤더 구조

IPv6는 고정된 40바이트 헤더를 사용하며, IPv4보다 단순화된 구조다.

| Version | DS | ECN | Flow Label |
| Payload Length | Next Header | Hop Limit |
| Source Address | Destination Address |

Version: IPv6(6)인지 표시
Traffic Class: QoS 및 우선순위 설정, DS(6비트)와 ECN(2비트)로 구성
- DS: 패킷의 우선순위를 결정하는 6비트 코드 -> 긴급 트래픽, 온라인 게임 패킷 같은 우선 순위가 높은 패킷이 우선 처리됨
- ECN: 네트워크 혼잡을 감지하는 기능
Flow Label: 패킷 흐름을 구분하여 QoS 향상
Next Header: 다음에 올 프로토콜(TCP, UDP 등)
Hop Limit: TTL(Time to Live)과 유사, 패킷 생명 주기 관리
Source/Destination Address: 송신지 및 목적지 IPv6 주소

이동 IP 프로토콜 (Mobile IP)

✅ 사용자가 이동 중에도 동일한 IP 주소를 유지할 수 있도록 지원하는 프로토콜
✅ 스마트폰, 노트북 등 모바일 장치가 네트워크를 이동해도 IP 주소가 유지

📌 핵심 개념

홈 네트워크: 장치가 원래 등록된 네트워크
외부 네트워크: 장치가 이동한 네트워크
홈 에이전트: 원래 네트워크에서 패킷을 전달하는 역할
외부 에이전트: 이동한 네트워크에서 장치를 지원
Care-of-Address(CoA): 장치가 이동한 네트워크에서 임시로 부여받는 IP

Mobile IP는 장치가 이동해도 기존 IP 주소를 유지하여 지속적인 연결을 보장

VPN, 5G 네트워크, 원격 근무 환경에서 많이 사용

📌 동작 과정

1️⃣ 모바일 장치가 원래 네트워크(Home Network)에 있음
2️⃣ 외부 네트워크(Foreign Network)로 이동하면, Foreign Agent(FA)가 Care-of Address(CoA)를 할당

CoA는 이동 호스트의 HA에 등록되어 FA와 HA 사이에 터널을 형성하는 데 사용

3️⃣ 홈 에이전트(HA)가 외부 네트워크로 패킷을 터널링(Tunneling)하여 전달

HA는 이동 호스트의 원래 네트워크에서 패킷을 수신하고, 터널링을 통해 외부 네트워크로 전달

4️⃣ 모바일 장치는 기존 IP를 유지하며 인터넷 사용 가능

즉, Mobile IP는 사용자가 이동 중에도 끊김 없이 네트워크를 사용할 수 있도록 해주는 핵심 기술

제어용 프로토콜 (Control Protocols)

✅ 네트워크 계층에서 패킷 전달을 효율적으로 수행하기 위해 다양한 제어용 프로토콜이 사용됨
✅ ICMP, ARP, IGMP 등은 네트워크 상태 관리, 오류 감지, 주소 변환 등의 역할을 수행함.

📌 ARP(Address Resolution Protocol)

✅ IP 주소를 MAC 주소로 변환하는 프로토콜
✅ LAN에서 통신할 때 IP 주소를 MAC 주소로 변환하여 패킷을 전달함.

MAC 주소

송신 호스트가 물리 계층을 통해 데이터를 전송하는 과정에서 필요한 주소

기능	설명
IP → MAC 주소 변환	네트워크에서 패킷을 전달하기 위해 필요
ARP 요청(Request)	특정 IP 주소에 대한 MAC 주소 요청
ARP 응답(Reply)	MAC 주소 응답
캐시 사용	변환된 MAC 주소를 일정 시간 동안 저장

ARP요청은 네트워크의 모든 노드에 브로드캐스트로 전송되며, 대상 IP를 가진 장치는 자신의 MAC 주소를 ARP 응답으로 유니캐스트 전송

ICMP(Internet Control Message Protocol)

✅ 네트워크에서 오류 메시지를 전송하는 프로토콜
✅ 네트워크 문제를 감지하고 진단하는 데 사용
✅ 전송 과정에 문제가 발생하면 라우터에 의해 ICMP 메시지 발생

오류 보고 메시지

DESTINATION UNREACHABLE: 수신 호스트가 존재하지 않거나 접근이 불가한 경우
TIME EXCEEDED: 패킷의 TTL 필드 값이 0이 되어 버려진 경우

질의 메시지

ECHO REQUEST, ECHO REPLY: 특정 호스트가 인터넷에 활성화되어 동작하는지 확인
TIMESTAMP REQUEST, TIMESTAMP REPLY: 두 호스트 간의 네트워크 지연을 계산

📌 IGMP (Internet Group Management Protocol)

✅ 멀티캐스트 그룹을 관리하는 프로토콜
✅ 여러 장치가 동시에 같은 데이터를 받을 때 사용
ex) IPTV, 화상회의

기능	설명
멀티캐스트 그룹 가입	그룹 가입 요청
그룹 유지 관리	네트워크에서 그룹 유지
그룹 탈퇴	그룹 탈퇴 요청

IGMP는 방송(Broadcast) 대신 멀티캐스트를 사용하여 네트워크 효율성을 높이는 데 도움을 준다

IP 프로토콜

Thu, 06 Feb 2025 00:00:00 GMT

네트워크 계층의 기능

네트워크 계층의 핵심 기능은 패킷을 출발지에서 목적지까지 전달하는 것이다.

주요 기능

패킷 전달: 출발지에서 목적지까지 데이터 전송
라우팅: 최적의 경로를 찾아 패킷 전달
- 네트워크의 구성 형태에 대한 정보는 라우팅 테이블에 보관
혼잡 제어: 네트워크에 패킷 수가 급증하는 혼잡 현상을 예방하거나 제거
단편화 및 재조립: 패킷이 네트워크 MTU보다 클 경우 나누어 전송 후 다시 조립

연결형 서비스와 비연결형 서비스

네트워크 계층이 전송 계층에 제공하는 서비스는 크게 두 가지다.

연결형 서비스: 패킷을 전송하기 전 송수신 호스트 사이에 연결 설정
- 경로가 최초 설정 시 고정 -> 모든 패킷이 같은 경로로 따라감 -> 도착 순서 보장
비연결형 서비스: 연결 설정없이 데이터를 패킷 단위로 전송

전송 계층에서 네트워크의 비연결형 서비스를 이용할 때는 자체적으로 오류 제어와 흐름 제어 기능을 더 많이 수행해야 한다.

비연결형 서비스를 이용해 패킷을 전송하면 패킷이 서로 다른 경로를 통해 수신 호스트로 전달되어 순서가 일정하지 않을 수 있다. -> 상위 계층인 전송 계층은 수신한 패킷의 순서를 재조정하는 기능이 필요하다.

혼잡 제어

흐름 제어가 송신 호스트와 수신 호스트의 논리적인 점대점 전송 속도를 다룬다면, 혼잡 제어는 더 넓은 관점에서 네트워크의 전송 능력 문제를 다룬다.

혼잡 발생의 가장 큰 원인은 네트워크 용량에 비해 전송 패킷이 많기 때문이다. 해결 방법

트래픽 관리(Traffic Shaping): 송신자가 전송 속도를 조절하여 네트워크의 부하를 줄이는 방식
- Leaky Bucket 등
혼잡이 발생한 경로를 피해 패킷을 전송

라우팅 프로토콜

라우팅은 패킷이 네트워크를 통해 이동하는 최적의 과정을 결정하는 과정 라우팅을 수행하는 장치가 라우터이며, 라우터는 라우팅 프로토콜을 이용해 경로를 설정

라우팅 방식

정적 라우팅: 관리자가 수동으로 경로 설정 -> 운영 중인 네트워크의 구성에 변화가 생기면 이에 적절하게 대처할 수 없다. -> 실시간 혼잡도를 반영할 수 없다.
동적 라우팅: 라우팅 프로토콜을 사용해 자동으로 경로 설정 -> 현재 네트워크 상황을 고려해 최적의 정보를 선택할 수 있다. -> 네트워크에 새로운 부하를 주어 성능에 부정적인 영향을 미친다.

동적 라우팅 방식을 사용하기 위해선 현재의 네트워크 링크 상태를 점검해 이를 새로운 경로 배정 시 적용해야 한다.

라우팅 테이블

패킷 전송 과정에서 라우터들이 적절한 경로를 쉽게 찾을 수 있도록 가장 기본적인 도구로 라우팅 테이블을 사용한다.

라우팅 테이블에 포함해야 하는 필수 정보는 (목적지 호스트, 다음 홉)의 조합이다. '목적지 호스트'까지 패킷을 전달하기 위해 어떤 이웃 호스트('다음 홉')으로 가야 하는지 알려주는 정보이다. 따라서 라우팅 테이블 정보는 네트워크에 연결된 모든 라우터에 존재한다.

최단 경로 라우팅

패킷이 목적지에 도달할 때까지 거치는 라우터 수, 즉 홉(hop)의 수가 최소화될 수 있도록 경로를 선택하는 방식

홉 수 외 거리 기준이 될 수 있는 요소

전송 지연 시간
전송 대역폭
통신 비용

거리 벡터 라우팅

라우터가 이웃 라우터와 라우팅 정보를 교환하는 방식

필수 정보

링크 벡터: 이웃 네트워크에 대한 연결 정보
- 각 네트워크와 연결하기 위해 할당한 라우터 포트 번호
```
링크 벡터 L(x) = [포트(1), 포트(2), 포트(3), ... , 포트(n)]
```
거리 벡터: 개별 네트워크까지의 거리 정보
- 일반적으로 최소 전송 지연 시간
```
거리 벡터 D(x) = [거리(1), 거리(2), 거리(3), ... , 거리(n)]
```
다음 홉 벡터: 개별 네트워크로 가기 위한 다음 홉 정보
```
다음 홉 벡터 H(x) = [홉(1), 홉(2), 홉(3), ... , 홉(n)]
```

IP 프로토콜

IP 프로토콜은 네트워크 계층에서 데이터를 패킷으로 나누어 전달하는 핵심 프로토콜이다. 모든 장치는 고유한 IP 주소를 가지고 있으며, 패킷은 송신지에서 목적지까지 IP 주소를 기반으로 전달된다.

특징

비연결형 서비스 제공
패킷을 분할/병합하는 기능 수행
Best Effort 원칙에 따른 전송 기능 제공 -> 전송 패킷이 수신 호스트에 100% 도착하는 것을 보장하지 않는다. -> 상위 계층에서 전송 오류 문제를 고려해야 함

패킷 구조

| Version | Header Length | Type of Service | Total Length |
| Identification | Flags | Fragment Offset |
| Time to Live (TTL) | Protocol | Header Checksum |
| Source IP Address | Destination IP Address |
| Options | Data |

Version: IPv4(4) 또는 IPv6(6) 여부
TTL(Time to Live): 패킷의 생존 시간 (0이 되면 폐기)
Protocol: 상위 계층 프로토콜 (예: TCP=6, UDP=17)
Source/Destination IP Address: 송신지 및 목적지 IP
Header Checksum: 오류 검출

패킷 분할

데이터 링크 계층 프로토콜의 프레임은 크기가 프로토콜마다 다르다. 따라서 상위 계층에서 내려온 데이터를 데이터 링크 계층의 프레임 틀에 담을 수 있도록 분할하고, 수신 호스트에서는 이를 다시 재조립하는 작업을 수행한다.

IP 프로토콜의 분할 기능은 라우터의 좌우에 연결된 LAN이 서로 다를 수 있기 때문에 전송 경로에 위치한 라우터에 의해 수행된다.

분할 과정

송신지에서 패킷을 생성 → MTU(Maximum Transmission Unit)보다 크면 분할 필요
라우터가 패킷의 크기를 검사
- 패킷이 MTU보다 크면 분할 수행
패킷을 여러 개의 조각으로 나누어 전송
- 분할된 패킷은 각각 독립적인 IP 패킷으로 전달됨
목적지에서 패킷을 재조립하여 원래의 데이터 복원

DHCP 프로토콜

네트워크에 연결된 장치에게 자동으로 IP 주소와 기타 네트워크 설정을 제공하는 프로토콜 -> 자동으로 IP 주소 할당

동작 과정

단계	DHCP 메시지	설명
1. Discovery	DHCPDISCOVER	클라이언트 → 네트워크로 IP 요청 브로드캐스트
2. Offer	DHCPOFFER	DHCP 서버 → IP 주소 제안
3. Request	DHCPREQUEST	클라이언트 → 제안된 IP 주소 요청
4. Acknowledgment	DHCPACK	DHCP 서버 → IP 주소 최종 할당

데이터 링크 계층

Mon, 03 Feb 2025 00:00:00 GMT

데이터 링크 계층은 장치 간 신뢰성 있는 데이터 전송을 담당하는 계층이다. 이 계층은 MAC(Media Access Control) 계층과 LLC(Logical Link Control) 계층으로 나뉜다.

MAC 계층: 물리적인 데이터 전송 및 접근 제어
LLC 계층: 논리적인 연결 및 프레임 흐름 관리

MAC 계층

역할

네트워크의 물리적 매체(유선/무선)에 대한 접근 제어
MAC 주소를 사용해 송수신 장치 식별

MAC 주소

네트워크 인터페이스 카드(NIC)에 할당된 고유한 48비트 주소
Source와 Destination MAC 주소를 포함해 프레임 전송

MAC 프레임 구조

MAC 계층 프로토콜에 정의된 MAC 헤더와 트레일러 정보를 추가한 것을 MAC 프레임이라 하며, IEEE 802.3 표준안의 이더넷 프로토콜에서는 이더넷 프레임이라고 한다.

| Preamble | Destination MAC | Source MAC | Type/Length | Data | Checksum |

Preamble: 동기화 신호
- 수신 호스트가 송신 호스트의 클록과 동기를 맞출 수 있도록 시간을 제공하는 것이 목적
Destination MAC, Source MAC: 목적지와 송신지 MAC 주소
Type/Length: 상위 프로토콜 식별/전송 데이터의 크기
Checksum: 데이터 변형 오류의 여부를 확인할 수 있는 값

CSMA/CD

전송 매체의 신호를 감지해 프레임의 전송 여부를 결정하는 프로토콜을 신호 감지(Carrier Sense) 프로토콜이라고 한다.

신호 감지 프로토콜은 신호 감지 방식에 따라 분류된다.

1-persistent CSMA

신호 감지 프로토콜 중 가장 간단한 형태는 1-persistent CSMA 방식이다.

기본 원리
1. 송신 노드가 먼저 채널 감지
2. 채널이 비어 있으면, 즉시 데이터 전송
3. 채널이 사용 중이면, 계속 감지하고 대기
4. 채널이 다시 비어지면 즉시 전송
5. 충돌이 발생하면 백오프(Backoff, 랜덤 대기 후 재시도) 과정 수행
한계
- 충돌 발생 확률이 높음

Non-persistent CSMA

동작 과정
1. 송신 노드가 채널 감지
2. 채널이 비어 있으면 즉시 데이터 전송
3. 채널이 사용 중이면 일정 시간 랜덤 대기
4. 랜덤 대기 후 다시 감지하고, 비어 있으면 전송, 사용 중이면 다시 대기
5. 충돌이 발생하면 백오프(Backoff) 과정 수행
장점
- 충돌 발생 확률이 낮음
단점
- 채널 사용률이 낮음(효율이 떨어짐)

p-persistent CSMA 위 두 CSMA 방식의 절충형

동작 과정
1. 송신 노드가 채널 감지
2. 채널이 비어 있으면 p의 확률로 즉시 전송
3. (1-p)의 확률로 랜덤 대기 후 다시 감지
4. 채널이 사용 중이면 랜덤 대기 후 다시 감지
5. 충돌 발생 시, 백오프(Backoff) 과정 수행
장점
- 네트워크 부하에 따라 유연하게 조정 가능
  - p가 높을 수록 빠른 전송, p가 낮을 수록 충돌 방지 효과 증가
단점
- 적절한 p 값 설정이 중요

LLC 계층

역할

MAC 계층과 상위 계층(네트워크) 간의 인터페이스
프레임의 흐름 제어 및 오류 제어
다양한 네트워크 프로토콜과 MAC 계층 간의 통신 조정

LLC 프레임 구조

| DSAP | SSAP | Control | Data |

DSAP(Destination Service Access Point): 목적지 서비스 액세스 포인트 (예: IP, ARP 식별)
SSAP(Source Service Access Point): 송신 측의 서비스 액세스 포인트
Control: 오류 제어, 흐름 제어 정보 포함
Data: 상위 계층에서 전송한 실제 데이터

데이터 링크 계층

프로토콜 기초

데이터 링크 계층은 프레임 단위로 데이터를 전송한다. 프레임 종류

정보 프레임: 상위 계층이 전송을 요구한 데이터를 수신 호스트에 전송하는 용도로 사용
- 프레임의 순서 번호, 주소 정보, 오류 검출 코드 등을 포함
긍정 응답 프레임: 정보를 수신한 호스트는 오류 검출 코드를 확인하고, 변형 오류가 없다면 송신 호스트에 바르게 수신했다는 의미로 ACK(Positive Acknowledgement) 프레임을 전송
부정 응답 프레임: 만약 변형 오류가 발생했다면 송신 호스트에 NAK(Negative Acknowledgement)을 회신한다.

주요 기능

프레임화
주소 지정
오류 제어
흐름 제어
매체 접근 제어 위 기능을 수행하기 위해 슬라이딩 윈도우 프로토콜과 HDLC 프로토콜이 사용

슬라이딩 윈도우 프로토콜

두 호스트 간의 프레임 전송을 위한 일반적인 통신 프로토콜로, 오류 제어와 흐름 제어 기능을 함께 지원한다.

특징

Stop-and-Wait 프로토콜보다 효율적
- 여러 개의 프레임을 동시에 전송 가능
수신 측에서 확인 응답(ACK)을 보내며 흐름 제어 수행
Selective Repeat 사용 시, 손실된 프레임만 선택적으로 재전송 가능

Go-Back-N ARQ

특징
- 송신 측이 N개의 프레임을 한 번에 전송 가능
- 오류 발생 시 해당 프레임 이후의 모든 프레임을 다시 전송
- 수신 측이 순차적으로 데이터 수신
동작 방식
1. 송신 측이 윈도우 크기 N만큼 프레임 전송
2. 수신 측이 ACK을 순서대로 응답
3. 특정 프레임이 손실되거나 오류 발생 시, 해당 프레임 이후 모든 프레임 재전송
장단점
- 장점: 구현이 단순하고 안정적
- 단점: 오류 발생 시 불필요한 재전송이 많음

Selective Repeat ARQ(SR-ARQ)

특징
- 오류가 발생한 프레임만 선택적으로 재전송
- 수신 측이 순서를 유지하며 개별 프레임을 저장
동작 방식
1. 송신 측이 윈도우 크기만큼 프레임 전송
2. 수신 측이 개별 프레임에 대해 ACK 전송
3. 오류가 발생한 프레임만 재전송
장단점
- 장점: 불필요한 재전송 최소화 -> 네트워크 대역폭 절약
- 단점: 수신 측에서 패킷을 정렬하는 버퍼 필요

HDLC 프로토콜

비트 지향형 프로토콜로 데이터 전송의 신뢰성을 높이기 위해 오류 제어와 흐름 제어 기능을 포함하는 표준 데이터 링크 계층 프로토콜

특징

비트 프레임 방식 사용
오류 검출을 위한 CRC 포함
슬라이딩 윈도우 기반의 흐름 제어 및 오류 복구 사용

프레임 구조

| Flag (01111110) | Address | Control | Data | CRC | Flag (01111110) |

Flag: 프레임의 시작과 끝
Address: 송신 및 수신 주소 지정
Control: 프레임 유형 및 오류 제어
Data: 실제 전송되는 데이터
CRC: 오류 검출

프레임 유형

Control 필드 값에 따라 세 종류로 구분된다.

I(정보)-프레임: 데이터 전송을 위한 프레임(순서 번호 포함)
S(감독)-프레임: 흐름 제어 및 오류 제어 프레임(ACK 포함)
U(비번호)-프레임: 링크 제어 및 관리

데이터 전송

Sun, 02 Feb 2025 00:00:00 GMT

전송 방식

데이터 전송 방식은 어떻게 목적지에 도달하는지에 따라 분류할 수 있다.

점대점(Point-to-Point) 방식

한 장치에서 다른 특정 장치로 데이터를 전송하는 방식

특징

두 개의 노드 사이 직접적인 연결 필요
LAN에서는 MAC 주소를 기반, WAN에서는 전용선 또는 VPN을 이용한 논리적 연결을 통해 이루어진다.

ex) 전화 통신, VPN

브로드캐스팅(BroadCasting) 방식

네트워크에 연결된 모든 장치에게 데이터를 전송하는 방식

특징

일대다 방식으로 동작
동일 네트워크(LAN) 내에서는 라우터 없이 전송할 수 있지만, WAN에서는 브로드캐스트 트래픽이 제한되며, 라우터가 이를 필터링할 수도 있다.

ex) DHCP 요청, IPv4 브로드캐스트 패킷(255.255.255.255)

멀티포인트(Multipoint) 방식

하나의 송신자가 여러 개의 수신자에게 데이터를 전송하는 방식

특징

브로드캐스트와 달리 특정 그룹만 데이터를 받을 수 있도록 제한 가능
일대다 또는 다대다 통신 가능
주로 멀티캐스트 기술을 이용해 구현

ex) IPTV, 온라인 게임 서버

멀티캐스팅 vs 유니캐스팅

멀티캐스팅: 한 번의 전송으로 다수의 수신 호스트에 데이터 전송 가능
유니캐스팅: 한 번의 전송으로 수신 호스트 하나에만 데이터 전송 가능

오류 제어

네트워크에서 발생하는 오류를 감지하고, 복구하여 데이터의 신뢰성을 유지하는 과정

전송 오류 유형

비트 오류: 한 개 이상의 비트가 바뀌는 오류
- 패리티 체크를 통해 오류 검출 가능
패킷 손실: 네트워크 혼잡, 신호 감쇠로 인해 패킷이 유실
- 송신 호스트의 타임아웃 기능으로 오류 검출 가능
중복 패킷: 같은 패킷이 여러 번 도착
패킷 순서 오류: 패킷이 올바른 순서로 도착하지 않음

순서 번호

각 프레임의 고유 번호로 부여한다.

역할

패킷이 유실되었는지 확인: 특정 순서 번호의 패킷이 오지 않으면 재전송 요청
중복 패킷 식별 가능: 동일한 패킷이 여러 번 도착하면 중복 패킷 무시
패킷 순서를 올바르게 정렬 가능: 경로 변경으로 순서가 뒤죽박죽일 수 있지만, 재정렬 가능

흐름 제어

송신 속도를 제어해 수신 호스트 측 과부하 방지

기법

Stop-and-Wait: 한 번에 하나의 패킷을 보내고 응답(Ack)을 기다림
- 느리지만 신뢰성 높음
Sliding-Window: 일정 개수의 패킷을 보내고 수신 측이 처리 가능한 만큼 수락
- 효율적

기본 원리

수신 호스트가 다음에 수신할 데이터 프레임의 개수를 통지
- 수신 호스트의 버퍼 수에 직접적인 영향을 받는다.
송신 호스트는 위 수에 근거해 연속해서 데이터 프레임 전송

프레임 구조

프레임은 네트워크에서 데이터를 일정 크기로 나누어 전송하는 기본 단위

각 프레임은 헤더, 데이터, 트레일러로 구성되며, 프레임의 시작과 끝을 어떻게 구분할지에 따라 문자 프레임 방식과 비트 프레임 방식으로 나뉜다.

문자 프레임

문자 프레임 방식은 특정 문자(Character)를 사용해 프레임의 시작과 끝을 구분하는 방식

| STX(Start of Text) | 데이터 | ETX(End of Text) |

STX: 프레임의 시작을 나타내는 문자
ETX: 프레임의 끝을 나타내는 문자

문제점

데이터 부분에 ETX와 동일한 문자가 포함되면 수신 측에서 프레임 종료로 착각할 수 있다.
- 문자 스터핑을 사용해 해결: DLE(Data Link Escape) 문자를 추가

비트 프레임

비트 프레임 방식은 특정한 비트 패턴을 사용해 프레임의 시작과 끝을 구분하는 방식

| 플래그(Flag, 01111110) | 데이터 | 오류 검사(CRC) | 플래그(01111110) |

플래그: 시작과 끝을 나타내는 비트 패턴
CRC: 데이터가 손상되지 않았는지 검증

문제점

플래그와 동일한 비트 패턴이 포함되어 수신 측에서 착각할 수 있다.
- 비트 스터핑을 통해 강제로 0을 삽입 두 방식에서 스터핑을 사용할 때 수신 호스트는 강제로 추가된 문자나 비트를 상위 계층인 네트워크 계층에 전달하기 전 제거해야 한다.

오류 검출 기법

오류 검출은 데이터가 손상되거나 변조되지 않았는지 확인하는 과정이다. 일반적으로는 오류 복구 코드를 이용한 순방향 오류 복구 방식은 사용하지 않고, 재전송 방식을 이용해 오류를 복구한다. 이를 ARQ(Automatic Repeat reQuest) 방식이라 한다.

이를 위해선 송신 호스트가 오류를 검출하기 위한 코드를 전송 데이터와 함께 송신해야 한다. 오류 검출 코드는 패리티 비트, 블록 검사, 다항 코드 등을 이용해 생성할 수 있다.

패리티 비트

데이터에 1비트를 추가해 오류를 감지한다.

문제점

간단하지만, 검출 능력이 낮다.

블록 검사

여러 개의 바이트를 하나의 블록으로 구성한 후 교차 검사를 한다.

문제점

전송되는 데이터의 양과 비교해 오류 검출을 위한 오버헤드가 크다.

다항 코드

다항식을 이용해 오류를 검출하는 네트워크 프로토콜에서 가장 많이 사용하는 검출 기법이다.

과정

데이터를 이진수로 간주하고 다항식으로 표현
모듈로 연산을 통해 나머지 값을 오류 검출 코드(FCS)를 생성
수신 측에서 동일한 연산을 통해 데이터 손상 확인

장점

연속된 비트 오류를 효과적으로 감지
하드웨어 및 소프트웨어 구현 간단
버스트 오류(특정 위치에 집중적으로 발생하는 오류) 검출 능력이 뛰어남

라우팅과 인터네트워킹

Sat, 01 Feb 2025 00:00:00 GMT

라우팅

라우팅은 네트워크에서 데이터를 목적지까지 최적의 경로로 전달하는 기능을 의미한다. 라우팅 시스템은 라우터와 스위치 같은 네트워크 장비들이 패킷을 전달하는 방식을 결정하는 역할을 한다.

회선 교환

데이터를 전송하기 전 두 장치 간에 물리적인 전용 회선을 설정하는 방식

특징

전용 경로가 설정되며, 데이터 전송이 끝날 때까지 경로가 유지
패킷 단위의 라우팅이 없음
한 번 회선이 설정되면, 다른 트래픽이 그 대역폭을 사용할 수 없음

라우팅 방식

경로 설정: 데이터 전송 전 경로 설정
고정 경로 유지: 한 번 설정도니 경로는 끝까지 유지

예시

공중 전화망

프레임 릴레이

프레임 릴레이 방식은 패킷 교환 방식의 일종으로 고정된 경로를 설정한 후 데이터 프레임을 빠르게 전송하는 방식

특징

가상 회선 방식 사용 -> 회선 교환과 패킷 교환의 중간 형태
패킷마다 새로운 경로를 찾지 않고, 설정된 가상 경로를 사용
전송 속도가 빠르고 효율적

예시

기업 네트워크에서 WAN 연결

패킷 교환

패킷 교환은 데이터를 작은 패킷으로 나누어, 각각 독립적으로 목적지까지 전달하는 방식

특징

각 패킷이 독립적으로 경로를 선택: 동일한 데이터라도 여러 패킷이 서로 다른 경로로 갈 수 있음
라우팅 알고리즘이 매우 중요: 최적의 경로를 실시간으로 찾아야 함
혼잡 제어 및 흐름 제어 필요: 패킷이 서로 다른 경로로 가므로, 도착 순서를 맞추는 과정 필요

라우팅 방식

동적 라우팅: 실시간으로 최적 경로 찾음
라우팅 프로토콜을 사용해 네트워크 상태 학습, 경로 결정

ex) RIP, OSPF 등

예시

인터넷(IP 네트워크)
LAN/WAN 기반 데이터 통신

네트워크의 분류

네트워크는 범위나 용도에 따라 LAN, MAN, WAN으로 분류된다.

LAN(LOcal Area Network)

LAN은 작은 범위(한 건물, 사무실, 학교 등) 내에서 장치들을 연결하는 네트워크다.

특징

좁은 지역에서 운영
데이터 전송 속도가 높음
일반적으로 이더넷 기반으로 구축

주요 기술

이더넷: 유선 LAN의 표준 기술
Wi-Fi: 무선 LAN의 표준 기술
스위치, 라우터 등의 네트워크 장비 사용

예시

가정 내 Wi-Fi 네트워크
기업 사무실에서 사용되는 내부 네트워크

MAN(Metropolitan Area Network)

하나의 도시 또는 특정 지역을 연결하는 네트워크다.

특징

도시 수준의 광역 네트워크
여러 개의 LAN을 연결하는 역할
인터넷 제공업체가 관리하는 경우가 많음

예시

도시 전체를 연결하는 공공 Wi-Fi 네트워크
지역 ISP 네트워크

WAN(Wide Area Network)

전 세계적으로 데이터를 주고받는 대규모 네트워크

특징

광범위한 지역 연결
일반적으로 ISP(인터넷 서비스 제공자, KT, SKT 등)가 관리
속도는 네트워크 장비, 회선, 거리 등에 따라 다름

주요 기술

IP: 대규모 트래픽을 효율적으로 관리
위성 네트워크: 지리적으로 떨어진 지역 연결
5G: 모바일 WAN 네트워크

예시

인터넷
기업용 WAN

인터네트워킹

인터네트워킹은 여러 개의 독립적인 네트워크를 상호 연결해 하나의 통합된 네트워크를 구축하는 기술이다. 이를 위해 브리지, IP 인터네트워킹, 인터넷 라우팅 같은 기술이 사용된다.

브리지

특징

서로 다른 LAN을 연결해 하나의 논리적인 네트워크로 통합
브로드캐스트 도메인을 확장해 같은 네트워크처럼 동작할 수 있도록 만듦

동작 방식

네트워크에 연결된 장치들의 MAC 주소 테이블 유지
패킷이 들어오면 MAC 주소를 확인하고, 목적지가 같은 네트워크 내에 있으면 필터링해 불필요한 전송을 방지
목적지가 다른 네트워크에 있다면 브리지를 통해 전달

브리지를 이용한 인터네트워킹 예시

이더넷 LAN을 확장해 여러 개의 사무실을 하나의 네트워크로 연결

IP 인터네트워킹

IP 인터네트워킹은 IP 주소를 사용해 서로 다른 네트워크를 연결하는 기술 이는 네트워크 계층(OSI 3계층) 에서 이뤄지며, 라우터가 핵심적인 역할을 한다.

특징

IP 주소를 사용해 네트워크 식별
서로 다른 LAN과 WAN을 연결해 데이터가 목적지까지 갈 수 있도록 함
라우팅 프로토콜을 사용해 최적의 경로를 결정

동작 방식

패킷이 LAN을 벗어나면, 라우터가 IP 주소를 기반으로 최적 경로를 찾음
라우터는 IP 패킷을 네트워크 계층에서 포워딩
목적지 네트워크로 가는 가장 효율적인 경로를 선택해 전송

핵심 기술

IP 주소 체계: 네트워크 식별을 위해 사용
서브넷팅: 네트워크를 효율적으로 나누는 기술
NAT: 사설 IP를 공인 IP로 변환해 인터넷에 연결

예시

가정이나 회사의 LAN을 ISP의 WAN과 연결해 인터넷 사용
기업 네트워크에서 여러 지사를 연결해 동일한 네트워크 환경 제공

인터넷 라우팅

인터넷 라우팅은 인터넷에서 데이터 패킷을 최적의 경로로 전달하는 과정을 의미

핵심 개념

라우터: 네트워크 계층에서 패킷을 전달하는 장비
라우팅 테이블: 목적지 네트워크에 대한 정보 저장
라우팅 프로토콜: 최적의 경로를 동적으로 결정하는 알고리즘

라우팅 방식

정적 라우팅
- 네트워크 관리자가 수동으로 경로 설정
- 트래픽이 적거나 변동이 거의 없는 네트워크에서 사용
동적 라우팅
- 라우터가 자동으로 최적의 경로를 결정하고 업데이트
- 네트워크 상태 변화에 따라 경로를 자동으로 수정

네트워크 개요

Mon, 13 Jan 2025 00:00:00 GMT

용어 정리

네트워크 기초 용어

네트워크를 이해하려면 시스템, 인터페이스 전송 매체, 프로토콜, 네트워크, 인터넷과 같은 용어를 먼저 이해해야 한다.

네트워크는 하드웨어적 전송 매체를 매개로 서로 연결되어 데이터를 교환하는 시스템의 모음이며, 시스템과 전송 매체의 연결 지점에 대한 규격이 인터페이스다. 시스템이 데이터를 교환할 때는 통신 규칙인 프로토콜이 필요하다. 위 개념들을 도식화 해보면 다음과 같다.

시스템

내부 규칙에 따라 자율적으로 동작하는 대상을 가리킨다. 시스템의 동작에는 외부 입력이 있을 수 있으며, 내부 정보와 외부 입력의 조합에 따른 출력이 있을 수 있다.

인터페이스

시스템과 시스템을 연결하기 위한 표준화된 접촉 지점을 의미한다.

하드웨어적 관점: 물리적 규격
소프트웨어적 관점: 함수 이름, 인수 지정

전송 매체

시스템 간 데이터 전달을 위한 물리적 전송 수단을 가리킨다.

ex) 공기, 무선 신호 등

프로토콜

논리적으로 상호 연동되는 시스템이 전송 매체를 통해 데이터를 교환할 때 따르는 규칙

인터페이스와 차이 프로토콜과 인터페이스가 비교될 때는 상하 개념이 적용된다. 프로토콜은 동등 계층 사이의 관계를 다루지만, 인터페이스는 상하 계층 사이 관계를 다룬다.

인터넷

전 세계의 모든 네트워크가 유기적으로 연결되어 동작하는 통합 네트워크

표준화

서로 다른 시스템이 상호 연동해 동작하려면 표준화를 통한 형식의 통일이 필요하다.

시스템 기초 용어

네트워크 시스템은 수행 기능에 따라 다음과 같이 다양한 명칭으로 부를 수 있다.

노드

컴퓨터 이론 분야에서 특정 시스템을 가리키는 가장 일반적인 용어로 사용된다. 모든 시스템을 통칭하며, 인터넷 내부를 구성하는 라우터와 인터넷 바깥쪽에 연결되어 데이터를 주고받는 호스트로 구분된다.

라우터

인터넷 내부를 구성하며, 기본적으로 데이터 전송 기능을 포함한다. 라우터의 주요 역할은 데이터 중개 기능이며, 호스트들 사이 데이터 전송이 인터넷 내부에서 최적의 경로를 통해 이루어지도록 한다.

호스트

인터넷 바깥쪽에 연결되어 일반 사용자들의 네트워크 접속 창구 역할을 한다. 응용 프로그램을 실행할 수 있고, 이를 통해 사용자들은 다양한 서비스를 제공받는다.

좀 더 정확하게 말하자면, 호스트는 인터넷이 가장자리에서 사용자와 직접 상호작용하거나 데이터를 생성, 소비하는 시스템이고 라우터는 인터넷의 중심부에서 데이터의 중계와 경로 최적화를 담당한다.

클라이언트와 서버

클라이언트는 임의의 인터넷 서비스를 이용하는 프로세스고, 서버는 서비스를 제공하는 프로세스다. 클라이언트와 서버의 개념은 서비스 단위이므로 고정되지 않는다. 따라서 기준이 되는 서비스에 따라 클라이언트가 서버가 될 수도, 서버가 클라이언트가 될 수도 상대적 개념이다.

구조적 모델

OSI 7계층 모델

호스트가 제공하는 복잡한 네트워크 기능을 연관된 그룹으로 묶어 계층 모델로 설명할 수 있다. 다수의 시스템을 서로 연결해 통신하려면 전체 시스템 구조를 표준화해야 한다. 표준화된 구조가 바로 OSI 7계층 모델이다.

물리 계층(Physical Layer)

호스트를 전송 매체와 연결하기 위한 인터페이스 규칙과 전송 매체의 특성을 다루며, 데이터가 전송 매체를 통해 신호로 전달되도록 한다.

데이터 링크 계층(Data Link Layer)

주로 물리 계층이 감지한 오류를 제어하는 기능을 수행한다.

네트워크 계층(Network Layer)

데이터가 목적지까지 안전하게 도착하기 위해선 여러 라우터를 거쳐야 한다. 주로 이 과정에서 올바른 경로를 선택할 수 있도록 지원한다. 네트워크 부하가 증가하면 특정 지역에 혼잡이 발생할 수 있는데 혼잡 제어 또한 네트워크 계층이 담당한다.

전송 계층(Transport Layer)

최종적인 경로상의 양 끝단 사이의 연결이 완성되는 계층으로 주로 데이터 신뢰성과 정확성을 보장한다.

세션 계층(Session Layer)

통신 세션의 설정, 유지, 종료를 담당하며, 주로 세션 연결과 연결 복구 작업을 수행한다.

표현 계층(Presentation Layer)

전송되는 데이터의 의미를 잃지 않도록 올바르게 표현하고, 호스트들이 표준화된 방법으로 데이터를 인식할 수 있게 해준다. ex) 압축, 암호화

응용 계층

일반 사용자를 위한 다양한 네트워크 응용 서비스를 지원한다.

한 호스트를 기준으로 데이터 전송은 위아래 양방향으로 모두 가능하며, 두 호스트 사이에서는 좌우 양방향으로 모두 가능하다. 다만, 좌우 간 물리적 데이터 전송은 반드시 아래 물리 계층을 통해 이루어진다.

인터네트워킹

네트워크와 네트워크의 연결을 인터네트워킹이라고 한다. 인터네트워킹 시스템은 수 많은 네트워크를 연결해 데이터를 중개할 수 있어야 한다.

연결된 모든 네트워크에 대해 물리적이고 논리적인 인터페이스를 지원해 둘 이상의 네트워크를 유기적으로 연동할 수 있어야 한다.

Gateway

인터네트워킹 기능을 수행하는 시스템을 일반적으로 Gateway라고 한다. Gateway는 서로 다른 네트워크 간의 데이터 통신을 가능하게 한다. 프로토콜 변환 역할을 수행하고, OSI 7계층 중 응용 계층까지 동작할 수 있는 고급 장치이다.

프로토콜

프로토콜은 시스템이 데이터를 교환하기 위해 사용하는 통신 규칙이다. OSI 7 계층 모델에서는 각 계층에서 수행하는 프로토콜이 서로 역할을 분담해 독립적으로 동작한다. 따라서 계층 2에는 계층 2끼리 통신할 수 있는 프로토콜이 존재한다.

ex) RPC, HTTP, IP 등

데이터 단위 데이터를 프로토콜에서 정의된 규격에 맞춰야 한다. 이와 같은 한 단위의 규격으로 묶인 전송 데이터를 데이터 단위라고 한다.

OSI 7계층 모델의 각 계층에 규격화된 데이터에는 고유 명칭이 있다. 계층에 상관 없이 사용할 때는 PDU(Protocol Data Unit)라고 부른다.

계층	PDU 이름	역할 및 주요 정보
물리 계층	Bits	데이터를 비트 단위로 전송 (0과 1).
데이터 링크 계층	Frame	MAC 주소 및 오류 검출 정보(CRC)를 포함한 프레임 단위로 데이터 처리.
네트워크 계층	Packet	IP 주소(출발지/목적지)를 포함한 패킷 단위로 라우팅 수행.
전송 계층	Segment/Datagram	포트 번호를 포함하여 신뢰성(TCP) 또는 비신뢰성(UDP) 전송.
세션 계층	Data	세션 설정 및 데이터 흐름 제어.
표현 계층	Data	데이터 압축, 암호화, 형식 변환.
응용 계층	Data	최종 사용자 응용 프로그램에서 사용하는 데이터.

주소의 표현

일반적으로 주소의 개념은 단순히 서로를 구분한다는 고유 목적을 넘어 주소가 가리키는 대상의 특징을 표현할 수 있다.

시스템을 지칭하는 구분자는 내부에서 처리되는 숫자 기반의 주소와 함께 사용자의 이해와 편리성을 도모하는 문자로된 이름을 제공해야 한다.

IP 주소

IP 프로토콜이 호스트를 구분하기 위해 사용하는 주소 체계이다.

IPv4: 32비트의 이진 숫자로 구성된다.
IPv6: 128비트의 이진 숫자로 구성된다.

IP 주소는 임의로 할당되는 것이 아닌 특정 규칙에 따라 인접한 주소들을 그룹으로 묶어 관리한다. 이는 네트워크 계층에서 경로를 선택할 때 중요한 기준이 된다.

호스트 이름

위에서 언급한 사용자들의 이해와 편리성을 위한 문자로된 주소가 호스트 이름이다. 이는 DNS를 통해 IP 주소로 변환된다.

DNS

DNS는 주소와 이름 정보를 자동으로 유지하고 관리하는 분산 데이터베이스 시스템이다. 네트워크가 커지면 DNS에 저장되는 정보의 양이 과도하게 많아지기 때문에 하나의 집중화된 네임 서버가 전체 호스트를 관리하는 것이 아닌 여러 영역에 분산되어 해당 영역에 위치한 호스트 정보를 관리한다.

파일시스템

Fri, 10 Jan 2025 00:00:00 GMT

파일 시스템

컴퓨터에는 다양한 종류의 파일이 있고, 이들은 하드디스크 같은 제 2저장장치에 보관된다. 보관 과정에 사용자가 개입하게 되면, 다른 파일들이 훼손되거나 저장장치 내부가 어지럽혀질 수 있다. 따라서 운영체제는 파일 관리자를 두어 저장장치의 전체 관리를 맡기는데 이를 파일 시스템이라고 한다.

주요 개념

파일 테이블: 파일 시스템에서 파일의 메타데이터와 상태 정보를 관리하는 구조
- 주로 운영체제가 파일과 관련된 정보를 효율적으로 추적하고 접근하기 위해 사용
블록: 저장장치에서 파일을 관리하는 단위
- 일반적으로 4KB, 8KB

파일 종류

파일은 운영체제 입장에서 다음과 같이 나뉜다.

실행 파일: CPU를 이용해 작업하는 파일로 메모리에 올라가 프로세스가 되는 파일
데이터 파일: 실행 파일이 작업하는 데 필요한 데이터를 모아놓은 파일

파일 속성

파일 이름:
- 파일의 논리적 이름으로 파일을 식별하기 위해 사용됩니다.
파일 크기:
- 파일의 총 크기(바이트 단위).
생성/수정/접근 시간:
- 파일이 생성된 시간, 마지막으로 수정된 시간, 마지막으로 접근한 시간.
파일의 위치 정보:
- 파일이 디스크에 저장된 블록(또는 클러스터)의 위치.
접근 권한:
- 읽기, 쓰기, 실행 권한 등 파일의 접근 제어를 위한 정보.
파일 속성 정보:
- 숨김 파일, 시스템 파일, 읽기 전용 여부와 같은 속성.
파일 상태:
- 파일이 열려 있는지, 닫혀 있는지 등.
파일 소유자 및 그룹:
- 파일을 소유한 사용자 및 그룹 정보. 파일 속성은 파일의 파일 헤더에 기록되며, 파일 헤더는 각 파일의 맨 앞부분에 저장된다.

저장장치 관리 기법

파티션

저장장치를 2개 이상의 묶음으로 나누는 것을 파티션을 나눈다고 하며, 파티션은 논리적으로 구분된 저장장치 영역을 의미한다. 분리된 파티션마다 파일 시스템을 탑재해 논리적으로 구분하는 방식으로 구현된다. 하지만 파티션 확장성 부족과 자원 분배가 비효율적인 문제가 있어 유닉스에서는 여러 개의 파티션을 하나로 통합하는 기능을 제공하는데 이를 마운트라고 한다.

포맷

포맷은 저장장치의 파일 시스템을 초기화하는 작업이다.

조각 모음

조각 모음은 디스크에 저장된 조각난 파일 데이터를 재배치하여 데이터 접근 속도를 최적화하는 과정이다.

장점

데이터 접근 속도 향상: 디스크의 읽기/쓰기 속도 증가
디스크 수명 연장: 헤드의 이동이 줄어들어 디스크 마모 감소

단점

시간 소모: 시간이 오래 걸림
SSD 비효율: SSD에서 조각 모음을 수행하면 오히려 불필요한 쓰기로 수명이 단축될 수 있음

파일 구조

파일은 하나의 데이터 덩어리다. 파일 구조는 이 덩어리를 어떻게 구성하느냐에 따라 다음과 같이 구분된다.

순차 파일 구조

가장 기본적인 파일구조다. 순차 파일 구조는 파일 내용이 하나의 긴 줄로 늘어선 형태다.

장점

단순성: 구현이 쉽고, 데이터가 정렬되어 있어 검색과 처리가 직관적이다.
효율적 일괄 처리: 데이터를 순차적으로 처리하는 작업에 적합하다.

단점

랜덤 접근 비효율: 특정 데이터를 검색하려면 순차적으로 읽어야 하므로 시간이 오래 걸린다.
삽입/삭제의 비효율: 중간에 데이터를 삽입/삭제 하려면 데이터를 재구성해야 한다. 사용 사례
거래 내역, 로그 파일 등 순차적으로 추가되고 전체를 자주 처리하는 데이터에 적합하다.

인덱스 파일 구조

순차 파일 구조의 단점을 해결한 파일 구조다. 데이터 파일과 별도로 키 값과 해당 데이터 위치를 저장한 인덱스 파일을 사용한다.

장점

빠른 검색: 순차 파일보다 특정 데이터를 빠르게 검색 가능하다.
효율적 수정: 데이터를 수정해도 전체 파일을 재구성할 필요 없다.

단점

추가 저장 공간 필요: 인덱스 파일을 유지하기 위한 추가 공간이 필요하다.
인덱스 유지 비용: 데이터가 변경될 때마다 인덱스 파일을 업데이트해야 한다.

사용 사례

데이터베이스처럼 데이터가 많고 특정 키 값으로 자주 검색되는 경우에 적합하다.

직접 파일 구조

저장하려는 데이터의 특정 값에 어떤 관계를 정의해 물리적인 주소로 바로 변환하는 파일 구조다.

장점

빠른 검색 속도: 데이터 위치를 직접 계산하여 접근하므로 검색 속도가 매우 빠르다. 단점
충돌 문제: 서로 다른 키 값이 동일한 해시 주소로 계산되는 경우 충돌 발생
복잡한 구현: 해시 함수 설계와 충돌 처리 메커니즘이 필요

사용 사례

빠른 검색이 중요한 캐시 등에 적합하다.

경로

경로는 전체 디렉터리 중 파일이 어디에 있는지를 나타내는 정보다.

절대 경로

파일 시스템의 루트 디렉터리를 기준으로 파일이나 디렉터리의 위치를 나타내는 경로

ex) /home/user/documents/file.txt

상대 경로

현재 있는 위치를 기준으로 파일의 위치를 나타내는 경로

ex) .\file.txt

할당 방식

연결 할당

파일에 속한 데이터를 연결 리스트로 관리하는 방식이다. 파일 테이블에는 시작 블록에 대한 정보만 저장하고, 나머지 데이터는 시작 블록부터 연결하여 저장한다.

장점

외부 단편화 방지: 연속적인 물리 배치가 필요 없으므로 빈 블록을 효율적으로 활용 가능하다.
동적 파일 크기 증가 가능: 필요한 만큼 블록을 추가할 수 있어 크기 제한이 상대적으로 적다.
블록 삽입 및 삭제 용이: 중간에 블록을 추가하거나 삭제해도 다른 블록에 영향을 미치지 않는다.

단점

랜덤 접근 어려움: 데이터 블록이 물리적으로 연속되지 않아 순차 접근만 가능하다.
추가 저장 공간 필요: 다음 블록의 포인터를 저장해야 하므로, 일부 공간이 낭비된다.

인덱스 할당

이 할당 방식에서 파일 제어 테이블은 인덱스 블록을 연결한다. 인덱스 블록 안에는 실제 데이터의 위치 정보(블록 정보)가 순서대로 보관되어 있다. 유닉스는 인덱스 할당 방식을 사용해 크기에 제한이 없다.

인덱스 블록: 데이터 블록들의 주소를 저장한 테이블
데이터 블록: 실제 데이터가 저장된 블록들

빈 블록 관리

파일 시스템은 빈 블록의 정보만 모아놓은 빈 공간 리스트를 사용해 빈 공간을 효율적으로 관리한다. 파일이 삭제되면 해당 파일의 데이터 블록들 주소를 빈 공간 리스트에 등록하는 방식이다.

장점

디스크 복구 가능
시간이 오래 걸리는 공간을 비우는 작업 생략 가능

입출력 시스템과 저장장치

Thu, 09 Jan 2025 00:00:00 GMT

입출력 버스

✅ 컴퓨터는 필수 장치인 CPU와 메모리, 주변장치인 입출력장치와 저장장치로 구성
✅ 각 장치는 메인보드에 있는 버스로 연결된다.
✅ 여러 입출력 작업을 병렬적으로 처리할 수 있도록 여러 데이터 전송 경로를 두는데 이를 채널

✅ 주변 장치

저속 주변장치: 메모리와 주변장치 사이에 오고 가는 데이터 양이 적어 데이터 전송률이 낮다. ex) 키보드, 마우스, 프린터 등
고속 주변장치: 대용량의 데이터가 오고 가기 때문에 데이터 전송률이 높다. ex) 그래픽카드, 하드디스크, SSD 등 고속 주변장치가 저속 주변장치와 입출력 버스를 공유하면 입출력 속도가 현저히 저하되므로, 고속 입출력 버스와 저속 입출력 버스로 분리하여 운영한다.

✅ 입출력 버스가 구분되기 때문에 입출력 장치에 대한 관리를 I/O Controller가 수행한다.

📌 DMA(직접 메모리 접근)

✅ CPU의 개입 없이 I/O Controller가 메모리에 직접 접근할 수 있는 기술이다.
✅ CPU의 작업 공간과 DMA Controller의 작업 공간이 겹치는 것을 방지하기 위해 메인메모리의 일부를 DMA Controller에 할당한다.
✅ I/O 작업이 완료되면, I/O Controller는 CPU에 인터럽트를 보내 작업 완료를 알린다.

📌 폴링 방식

✅ CPU가 일정한 간격으로 IO 장치를 확인하며 데이터가 준비되었는지 직접 검사하는 방식
✅ 특징

소프트웨어 기반: CPU가 직접 장치를 확인
CPU 부하 증가
비효율적, 성능 저하 초래

📌 인터럽트 방식

✅ IO 장치에서 데이터가 준비되었을 때 CPU에 신호(인터럽트)를 보내 작업을 요청하는 방식
✅ 특징

하드웨어 기반: 인터럽트 컨트롤러와 같은 추가 하드웨어 필요
CPU 부하 감소
구현이 복잡함: 인터럽트 핸들러를 운영체제에서 구현해야 함

📌 인터럽트 종류

인터럽트는 입출력 장치에서만 발생하는 것이 아닌 CPU가 시스템을 효율적으로 운영하는 데 필수적인 메커니즘이다.

구분	설명	예시
하드웨어 인터럽트	외부 장치(입출력 장치, 타이머, 전원 등)에서 발생하는 인터럽트	키보드 입력, 디스크 데이터 전송 완료, 타이머
소프트웨어 인터럽트	프로그램이 명령어를 실행하여 발생하는 인터럽트	시스템 콜, 예외 처리 (ex. `INT 0x80`)
예외 인터럽트	프로그램 실행 중 오류가 발생할 때 발생하는 인터럽트	0으로 나누기 오류, 페이지 폴트
비동기 인터럽트	현재 실행 중인 코드와 무관하게 발생하는 인터럽트	키보드 입력, 네트워크 데이터 수신
동기 인터럽트	실행 중인 명령어의 결과로 발생하는 인터럽트	시스템 콜, 잘못된 명령어 실행

✅ 인터럽트 처리 과정

I/O 장치나 시스템 이벤트가 인터럽트를 발생
CPU는 현재 실행 중인 작업을 중단
인터럽트 벡터를 이용해 적절한 인터럽트 핸들러를 호출
인터럽트 핸들러가 인터럽트를 처리한 후 CPU가 원래 작업으로 복귀

✅ 인터럽트 벡터와 인터럽트 핸들링

인터럽트 벡터: 각 인터럽트 신호의 핸들러 주소를 저장한 테이블
인터럽트 핸들러: 특정 인터럽트 발생 시 실행되는 코드

✅ 다중 인터럽트 발생 시 처리 방식

우선순위 기반 처리 → 중요한 인터럽트를 먼저 처리 (ex: 타이머 인터럽트)
중첩 인터럽트(Nested Interrupts) → 높은 우선순위 인터럽트가 낮은 우선순위 인터럽트를 중단하고 먼저 실행
인터럽트 큐(Interrupt Queue) → 우선순위가 같은 경우 FIFO(First-In-First-Out)로 처리

저장장치

📌 하드디스크

섹터는 하드디스크의 가장 작은 저장 단위다. 하나의 섹터에는 한 덩어리의 데이터가 저장된다. 트랙은 플래터에서 회전축을 중심으로 데이터가 기록되는 동일한 동심원상에 있는 섹터의 집합이다. 여러 개의 플래터에 있는 같은 트랙의 집합을 실린더라고 부른다.

하드디스크에서 데이터를 가져오는 데 걸리는 총시간은 탐색 시간 + 회전 지연 시간 + 전송 시간이다. 이 중 가장 오래 걸리는 것이 탐색 시간이다.

📌 SSD

하드디스크는 모터로 헤드를 이동시키기 때문에 느리다. 반면 SSD는 전자의 이동으로 작동하기 때문에 하드디스크보다 훨씬 속도가 빠르고 소음을 발생시키지 않는다. 하지만 가격이 훨씬 비싸다는 단점이 있다.

SS의 가장 큰 장점은 빠른 데이터 입출력 속도다. 현재는 하드디스크의 전송 속도를 수십 배 뛰어넘고 있다.

디스크 스케줄링 알고리즘

디스크의 데이터 전송 시간 중 탐색 시간이 가장 느리다. 따라서 디스크 스케줄링을 통해 탐색을 위한 트랙의 이동을 최소화한다.

📌 FCSFS 디스크 스케줄링

가장 단순한 디스크 스케줄링 방식으로 요청이 들어온 트랙 순서대로 서비스한다.

📌 SSTF 디스크 스케줄링

현재 헤드가 있는 위치에서 가장 가까운 트랙부터 서비스한다.

📌 블록 SSTF 디스크 스케줄링

큐에 있는 트랙 요청을 일정한 블록 형태로 묶은 후 블록으로 묶인 트랙들만 순서를 변경한다.

📌 SCAN 디스크 스케줄링

헤드가 움직이기 시작하면 맨 마지막 트랙에 도착할 때까지 되돌아 가지 않고 계속 앞으로만 전진하면서 요청받은 트랙을 서비스한다.

📌 C-SCAN 디스크 스케줄링

SCAN 기법을 변형한 것으로, 헤드가 한쪽 방향으로 움직일 때는 요청받은 트랙을 서비스하고 반대 방향으로 돌아올 때는 서비스하지 않는다.

📌 LOOK 디스크 스케줄링

더 이상 서비스할 트랙이 없으면 헤드가 끝까지 가지 않고 중간에서 방향을 바꾼다.

RAID

저장장치에는 최대 사용 횟수가 정해져 있다. 따라서 중요한 데이터는 수시로 백업해야 하는데 이를 자동으로 수행하는 시스템이 RAID(Redundant Array of Independant Disks)이다.

RAID는 동일한 규격의 디스크를 여러 개 모아 구성하며, 장애가 발생했을 때 데이터를 복구하는 데 사용된다. 이는 하나의 원본 디스크와 같은 크기의 백업 디스크에 같은 내용을 동시에 저장하고, 한 디스크가 고장 났을 때 다른 디스크를 사용해 복구하는 방식으로 동작하며, 이를 미러링이라고 한다.

RAID에는 여러 디스크에 데이터를 동시에 저장해 데이터의 입출력 속도를 높이는 방식도 있다. 이렇게 데이터를 여러 조각으로 나눠 보내는 방식을 스트라이핑이라고 한다.

가상 메모리

Tue, 07 Jan 2025 00:00:00 GMT

가상 메모리

물리 메모리의 크기와 상관없이 프로세스에 커다란 메모리 공간을 제공하는 기술이다. 프로세스는 운영체제가 어디에 있는지, 물리 메모리의 크기가 어느 정도인지 신경 쓰지 않고 메모리를 마음대로 사용할 수 있다. 이러한 가상 메모리 시스템은 메모리 관리자가 운영한다.

가상 메모리에서 메모리 관리자가 사용할 수 있는 메모리의 전체 크기는 물리 메모리(실제 메모리)와 스왑 영역을 합한 크기다. 메모리 관리자는 물리 메모리와 스왑 영역을 합쳐 프로세스가 사용하는 가상 주소를 실제 메모리의 물리 주소로 변환하는데 이러한 작업을 동적 주소 변환(DAT)라고 한다.

매핑 테이블

메모리 관리자는 가상 주소와 물리 주소를 일대일로 매핑한 테이블로 관리한다. 위 매핑 테이블은 세그먼테이션 매핑 테이블 예시이다. 프로세스 A의 어떤 값이 필요하다면, 물리 메모리의 세그먼트 0에서 원하는 데이터를 가져오면 된다.

페이징과 세그먼테이션

메모리 관리 방식은 크게 고정 분할 방식인 페이징과 가변 분할 방식인 세그먼테이션으로 나뉜다. 페이징은 페이지 매핑 테이블을 사용해 주소를 변환하고, 세그먼테이션은 세그멘테이션 매핑 테이블을 사용해 주소를 변환한다.

지역성

기억장치에 접근하는 패턴이 메모리 전체에 고루 분포되는 것이 아닌 특정 영역에 집중되는 성질을 나타낸다.

공간의 지역성: 현재 위치에서 가까운 데이터에 접근할 확률이 먼 거리에 있는 데이터에 접근할 확률보다 높음
시간의 지역성: 현재를 기준으로 가장 가까운 시간에 접근한 데이터가 더 먼 시간에 접근한 데이터보다 사용될 확률이 높음
순차적 지역성: 작업이 순서대로 진행됨

지역성 이론은 특히 캐시에서 이용되는 이론이다. 캐시는 시간적으로나 지역적으로 가까이 있는 데이터를 가져옴으로써 캐시 적중률을 높인다.

논리 주소, 가상 주소, 물리 주소

가상 메모리 시스템은 프로세스가 물리 메모리를 직접 사용하는 대신 논리 주소(Logical Address)와 가상 주소(Virtual Address)를 사용하여 메모리에 접근하도록 설계되어 있다. 이러한 주소를 물리 주소(Physical Address)로 변환하는 역할은 메모리 관리 유닛(MMU)이 담당한다.

논리 주소 (Logical Address): CPU가 생성하는 주소로, 프로그램의 관점에서 사용하는 주소
가상 주소 (Virtual Address)
- 운영체제가 정의한 가상 메모리 공간의 주소로, 논리 주소와 1:1 매핑
- 논리 주소와 가상 주소는 사실상 동일한 경우가 많음
- 논리 주소는 사용자 관점, 가상 주소는 운영체제 관점에서 표현된다는 점이 주요 차이
물리 주소 (Physical Address)
- 실제 메모리(RAM)의 주소로, 하드웨어가 메모리에 접근할 때 사용하는 주소
- 가상 주소는 메모리 관리 유닛(MMU)에 의해 물리 주소로 변환

페이징 기법

고정 분할 방식으로 메모리를 관리하는 기법이다. 가상 주소 공간과 물리 주소 공간을 같은 크기로 나누어 사용한다. 가상 주소 공간에서 분할된 각 영역을 페이지, 물리 주소 공간의 각 영역을 프레임이라 부른다. 가상 주소의 분할된 각 영역을 페이지라고 부르며 물리 메모리의 각 영역은 가상 주소의 페이지와 구분하기 위해 프레임이라고 부른다. 페이지와 프레임의 크기는 같다.

페이지 5의 프레임과 같이 invalid로 표시된 부분은 스왑 영역에 있다는 의미이다.

주소 변환 과정

편의를 위해 가상 주소 공간과 물리 주소 공간을 똑같이 10B로 나눴다.

가상 주소 30번의 주소 변환 과정
1. 페이지를 찾는다. 30번은 페이지 3의 0번 위치에 있다.
2. 페이지 3의 실제 물리 주소는 프레임 1에 있다.
3. 최종적으로 프레임 1의 0번 위치에 접근한다. 이 주소가 가상 주소 30번의 물리 주소다.
가상 주소 18번의 주소 변환 과정
1. 페이지를 찾는다. 18번은 페이지 1의 8번 위치에 있다.
2. 페이지 1의 실제 물리 주소는 프레임 3에 있다.
3. 최종적으로 프레임 3의 8번 위치에 접근한다. 이 주소가 가상 주소 18번의 물리 주소다.

정형화된 주소 변환

이제 주소 변환 과정을 정형화해 보자. 페이징 기법에서는 가상 주소를 VA(Virtual Address) = <P, D>로 표현한다. P는 page, D는 distance를 의미한다. 위 예시에서 가상 주소 30번을 정형화하면, VA = <3, 0>으로 작성할 수 있다.

물리 주소는 PA(Physical Address) = <F, D>로 표현한다. F는 frame을 의미한다. 위 예시에서 프레임 1의 0번 위치를 정형화하면 PA = <1, 0>으로 작성할 수 있다.

실제 컴퓨터는 2진법을 사용하므로 한 페이지의 크기는 2의 지수승이다. 따라서 주소는 다음과 같이 변환된다.

P = (VA) / (page size)
D = (VA) % (page size)

TLB

가상 주소를 물리 주소로 변환하는 작업은 CPU 내 MMU가 담당한다. 작업은 다음과 같은 과정을 거친다.

MMU가 메모리에 있는 페이지 매핑 테이블에 접근해 물리 주소로 변환한다.
변환된 물리 주소를 이용해 필요한 데이터를 가져온다. 위 과정에서 메모리에 접근하기 때문에 CPU 안에 있는 레지스터나 캐시에 접근할 때보다 시간이 오래걸린다. 이는 CPU 성능 저하로 이어진다.

위 문제를 해결하기 위해 페이지 매핑 테이블의 일부를 CPU 안쪽으로 가져오는데 이를 변환 색인 버퍼(TLB: Translation Look-ahead Buffer)라고 한다. TLB는 캐시된 페이지 매핑 테이블로 지역성 이론에 근거해 현재 사용 중이거나 사용이 예상되는 페이지 테이블의 일부를 CPU 안쪽으로 가져온다.

세그먼테이션 기법

세그먼테이션에서는 하나의 연속된 공간을 세그먼트라고 한다.

주소 변환 과정

세그먼테이션 기법에선 가상 주소를 VA = <S, D>로 표현한다. S는 Segment number, D는 distance를 의미한다.

주소 변환 과정은 다음과 같다.

프로세스 A는 세그먼트 0으로 분할되었으므로 S는 0, D는 32다. 따라서 가상 주소 VA = <0,32> 다.
세그먼트 0의 시작주소 120을 알아낸 후 거리 32를 더해 물리 주소 152를 구한다. 이때 메모리 관리자는 거리가 세그먼트의 크기보다 큰지 점검한다. 크다면 메모리를 벗어나는 것이므로 해당 프로세스를 강제 종료한다.
물리 주소 152번에 접근해 원하는 데이터를 읽거나 쓴다.

세그먼테이션 테이블에는 물리 메모리의 시작 주소를 나타내는 주소와 세그먼트의 크기를 나타내는 limit가 있다. 물리 메모리에 접근할 때마다 거리 D의 크기가 limit보다 작은지 매번 확인한다.

페이징 기법과 세그먼테이션 기법 비교

구분	페이징 기법	세그먼테이션 기법
기본 개념	고정 크기(페이지)로 메모리를 분할하여 가상 주소와 물리 주소를 매핑	가변 크기(세그먼트)로 메모리를 분할하여 가상 주소와 물리 주소를 매핑
단편화	내부 단편화 발생: 페이지 크기보다 작은 데이터를 저장하면 남는 공간 낭비	외부 단편화 발생: 가변 크기 때문에 빈 공간이 단편적으로 발생
주소 변환	가상 주소를 `<P, D>`(Page, Offset) 형태로 표현, 페이지 매핑 테이블을 통해 물리 주소로 변환	가상 주소를 `<S, D>`(Segment, Offset) 형태로 표현, 세그먼트 매핑 테이블을 통해 물리 주소로 변환
관리 테이블	페이지 매핑 테이블(Page Mapping Table) 사용	세그먼트 매핑 테이블(Segment Mapping Table) 사용
단점	- 프로그램의 논리적 구조를 무시하고 고정 크기로 나눠져 관리 복잡성 증가 - 페이지 크기 결정이 중요	- 메모리 단편화 심화 가능 - 세그먼트의 크기를 동적으로 조정하기 어려움
장점	- 메모리 관리가 단순 - 고정 크기 때문에 관리 효율적	- 프로그램의 논리적 구조(코드, 데이터, 스택 등)를 반영하여 메모리를 유연하게 관리 가능
사용 사례	현대 시스템에서 주로 사용됨	일부 특수 목적 시스템에서 사용됨 (예: 특정 임베디드 시스템, 레거시 소프트웨어)
단편화 해결 방법	- 내부 단편화 최소화를 위해 적절한 페이지 크기 선택 - 페이지 교체 알고리즘 사용	- 외부 단편화를 해결하기 위해 압축(compaction) 또는 페이징과 혼합 사용

요구 페이징

운영체제는 필요한 모듈만 메모리에 올려 실행하고 나머지 모듈은 필요하다고 판단될 때 메모리로 불러오는데 이를 요구 페이징이라고 한다.

프로세스의 일부만 메모리로 가져오는 이유는 다음과 같다.

메모리를 효율적으로 관리: 메모리가 꽉 차면 관리하기 어려우므로 가능하면 적은 양의 프로세스만 유지한다.
응답 속도 향상: 용량이 큰 프로세스를 전부 메모리로 가져와 실행하면 응답이 늦어질 수 있으므로 필요한 모듈만 올려 실행한다.

가상 메모리 시스템에서 프로세스는 물리 메모리와 스왑 영역 중 한 곳에 있다. 페이지가 스왑 영역에 있는 경우는 크게 두 가지다.

요구 페이징으로 인해 처음부터 물리 메모리에 올라가지 못한 경우
메모리가 꽉 차서 스왑 영역으로 옮겨 온 경우 어떤 것이든 스왑 영역에 있는 모듈은 물리 메모리로 가져오는 스왑인 과정을 거쳐야 사용 가능하기 때문에 페이지 매핑 테이블에는 페이지가 메모리에 있는지, 스왑 영역에 있는지 표시해야 한다. 이때 사용하는 비트가 유효 비트다.

페이지 매핑 테이블 엔트리 구성

페이지 매핑 테이블의 각 엔트리 구성은 다음과 같다.

페이지 번호
플래그 비트
- 접근 비트(access bit): 페이지가 메모리에 올라온 후 사용한 적이 있느지 알려준다.
- 변경 비트(modified bit): 페이지가 메모리에 올라온 후 데이터 변경이 있었는지 알려준다.
- 유효 비트(valid bit): 페이지가 실제 메모리에 있는지 나타낸다.
- 읽기 비트, 쓰기 비트, 실행 비트(read bit, write bit, execute bit): 각 작업에 대한 실행 권한을 나타낸다. 권한이 없는 작업 접근을 차단하는 데 사용된다. 따라서 위 3 비트를 합쳐 접근 권한 비트라고도 한다.
주소 필드

페이징 부재

프로세스가 페이지를 요청했을 때 해당 페이지가 메모리에 없는 상황을 페이지 부재라고 한다. 페이지 부재가 발생하면 프로세스가 해당 페이지를 사용할 수 있도록 스왑 영역에서 물리 메모리로 옮겨야 한다.

만약 메모리에 빈 프레임이 있다면, 그곳에 페이지를 올리고 페이지 매핑 테이블을 갱신하면 된다. 하지만 빈 프레임이 없다면 메모리에 있는 프레임 중 하나를 스왑 영역으로 내보낸 후 해당 페이지를 가져와야 한다. 이때 어떤 페이지를 스왑 영역으로 내보낼지 결정하는 알고리즘을 페이지 교체 알고리즘이라고 하며, 페이지 교체 알고리즘에 의해 스왑 영역으로 보낼 페이지를 대상 페이지(victim page)라고 한다.

페이지 교체 알고리즘

메모리가 꽉 차서 메모리에 있는 페이지를 스왑 영역으로 보내야할 때 보낼 페이지를 결정하는 알고리즘이다.

무작위 페이지 교체 알고리즘

스왑 영역으로 보낼 페이지를 특별한 로직 없이 무작위로 선정한다. 지역성을 전혀 고려하지 않기 때문에 성능이 좋지 않아 거의 사용되지 않는다.

FIFO 페이지 교체 알고리즘

큐를 이용해 시간상 메모리에 가장 먼저 들어온 페이지를 대상 페이지로 선정하여 스왑 영역으로 쫓아낸다.

무조건 오래된 페이지를 대상 페이지로 선정하기 때문에 성능이 떨어진다.

최적 페이지 교체 알고리즘

앞으로 사용하지 않을 페이지를 스왑 영역으로 보내는 이상적인 알고리즘이다. 실제로 미래의 접근 패턴을 안다는 것은 불가능하기 때문에 구현이 불가능한 이론적인 알고리즘이다.

LRU(Least Recently Used) 페이지 교체 알고리즘

페이지에 접근한 시간을 기준으로 대상 페이지를 선정한다. 메모리에 올라온 후 가장 오랫동안 사용되지 않은 페이지를 스왑 영역으로 옮긴다.

접근 시간이나 참조 비트를 유지하기 위한 메모리가 추가로 필요하기 때문에 낭비되는 메모리 공간이 많다는 것이 단점이다.

LFU(Least Frequently Used) 페이지 교체 알고리즘

페이지가 몇 번 사용되었는지를 기준으로 대상 페이지를 선정한다. 일반적인 경우 위 LRU 알고리즘과 성능이 비슷하다고 알려져 있다.

페이지 접근 횟수를 표시하는 데 추가 공간이 필요하므로 낭비되는 메모리 공간이 많다는 것이 단점이다.

NUR(Not Used Recently) 페이지 교체 알고리즘

LRU나 LFU와 성능이 비슷하면서도 불필요한 공간 낭비 문제를 해결한 알고리즘이다. 추가 비트 2개만 사용하여 미래를 추정한다.

참조 비트: 페이지에 접근하면 1이 된다.
변경 비트: 페이지가 변경되면 1이 된다. 모든 페이지의 초기 상태는 (0, 0)이다. 이 상태에서 페이지에 읽기 또는 실행 같은 접근이 발생하면 (1, 0)으로 바뀐다. 만약 쓰기 또는 추가 같은 변경이 일어나면 (0, 1)이 된다. 두 연산이 모두 발생하면 (1, 1)이 된다.

페이지마다 접근 비트와 변경 비트를 두고 (0, 0), (0, 1), (1, 0), (1, 1)의 순서대로 대상 페이지를 선정한다.

흔한 경우는 아니지만 모든 페이지의 비트가 (1, 1)일 때는 NUR 페이지 교체 알고리즘을 정상적으로 적용할 수 없기 때문에 모든 페이지 비트를 (0, 0)으로 초기화한다.

2차 기회 페이지 교체 알고리즘

FIFO 페이지 알고리즘과 마찬가지로 큐를 사용하지만, 특정 페이지에 접근해 페이지 부재 없이 성공할 경우 해당 페이지를 큐의 맨 뒤로 이동하여 대상 페이지에서 제외한다는 차이점이 있다.

성능은 LRU, LFU, NUR 페이지 교체 알고리즘보다 약간 낮고 FIFO 페이지 교체 알고리즘보다 약간 높은 것으로 알려져있다. 그러나 큐를 유지하는 비용이 높고, 큐의 중간에 있는 값을 뒤로 이동하는 작업이 추가된다는 단점이 있다.

시계 페이지 교체 알고리즘

시계 페이지 교체 알고리즘은 원형 큐를 사용한다.

대상 페이지를 선정하는 포인터와 접근 비트가 있다. 대상 포인터가 가리키는 페이지가 스왑으로 옮겨지고, 해당 포인터는 아래쪽으로 이동한다. 접근 비트가 1이면 0으로 만들고 다시 한 칸 밑으로 이동한다.

NUR 페이지 교체 알고리즘보다 추가 공간이 적게 들지만 알고리즘이 복잡하고 계산량이 많다는 것이 단점이다.

스레싱

여러 프로세스를 동시에 실행하게 되어 메모리가 꽉 찬 후에는 새로운 프로그램을 메모리에 올리기 위해 새로운 프로그램을 메모리에 올리기 위해 기존 프로그램을 스왑 영역으로 옮기는 횟수가 잦아진다.

이와 같이 프로세스가 많이 실행되고 하드디스크 입출력이 너무 많아져 작업이 멈춘 것 같은 상태를 스레싱이라 한다.

스레싱은 각 프로세스에 프레임을 할당하는 문제와도 연결된다. 실행 중인 여러 프로세스에 프레임을 얼마나 나누어 주느냐에 따라 시스템의 성능이 달라진다. 너무 적은 프레임을 할당한다면 페이지 부재가 빈번하게 일어날 것이고, 너무 많은 프레임을 할당한다면 메모리를 낭비해 전반적인 시스템 성능이 낮아질 것이다.

프레임 할당 방식

위에서 언급한 문제를 최소화하기 위해 남아 있는 프레임을 실행 중인 프로세스에 적절히 나누어 주는 정책이 필요하다. 프로세스에 프레임을 할당하는 방식은 크게 정적 할당과 동적 할당으로 구분된다.

정적 할당

프로세스 실행 초기에 프레임을 나누어 준 후 그 크기를 고정하는 방식이다.

균등 할당: 프로세스의 크기와 상관없이 사용 가능한 프레임을 모든 프로세스에 동일하게 할당
- 한계
  - 크기가 큰 프로세스의 경우 페이지 부재가 빈번하게 발생
  - 크기가 작은 프로세스의 경우 메모리 낭비가 발생한다.
비례 할당: 프로세스의 크기에 비례하여 프레임을 할당
- 한계
  - 프로세스가 실행 중에 필요로 하는 프레임을 유동적으로 반영하지 못함
  - 사용하지 않을 메모리를 처음부터 미리 확보해 공간을 낭비

동적 할당

프로세스를 실행하는 중에 시시각각 변하는 요청에 따라 프레임을 나누어 주기도 하고 회수하기도 하는 방식이다. 작업 집합 모델을 사용하는 방식과 페이지 부재를 사용하는 방식이 있다.

작업집합 모델: 지역성 이론을 기반으로 가장 최근 접근한 프레임이 이후에도 참조될 가능성이 높다는 가정에서 출발해 최근 일정 시간 동안 참조된 페이지들을 집합으로 만들고, 집합에 있는 페이지들을 물리 메모리에 유지하여 프로세스의 실행을 돕는다.
페이지 부재 빈도: 페이지 부재 횟수를 기록하여 페이지 부재 비율을 계산하는 방식으로 상한선과 하한선을 설정한다. 상한선을 초과하면 프레임을 늘리고, 하한선 밑으로 내려가면 프레임을 회수한다.

물리 메모리 관리

Mon, 06 Jan 2025 00:00:00 GMT

논리 주소와 물리 주소

논리 주소: 프로세스 입장에서 바라본 시작점을 0으로 놓았을 때 주소
물리 주소: 메모리의 입장에서 바라본 실제 저장되는 주소 논리 주소와 물리 주소의 변환은 메모리 관리 유닛(MMU)이 담당한다.

주소 변환 과정:

CPU가 논리 주소를 생성
MMU가 논리 주소를 변환하여 물리 주소를 생성
- 논리 주소에 베이스 레지스터(Base Register) 값을 더함
변환된 물리 주소를 통해 메모리에 접근

메모리 오버레이

과거엔 메모리가 값비싼 저장장치였기 때문에 개인용 컴퓨터에 큰 메모리를 사용할 수 없었다. 그렇다면 물리 메모리보다 큰 프로그램이 어떻게 작동했을까?

프로그램의 크기가 물리 메모리보다 클 때 전체 프로그램을 메모리에 가져오는 대신 적당한 크기로 잘라 가져오는 기법을 메모리 오버레이라고 한다.

메모리 오버레이는 프로그램을 몇 개의 모듈로 나눠 필요할 때마다 모듈을 가져와 사용한다. 메모리 오버레이에서 다음과 같은 중요한 의미를 찾을 수 있다.

한정된 메모리에서 메모리보다 큰 프로그램을 실행할 수 있다.
프로그램 전체가 아닌 일부만 메모리에 올라와도 실행할 수 있다. -> 메모리를 여러 조각으로 나눠 여러 프로세스에 할당할 수 있음

하지만 프로그래머가 직접 프로세스를 작은 모듈로 나누고, 메모리 적재 및 교체 작업을 관리해야 했기 때문에 작업 부담이 크다.

현대의 가상 메모리 시스템이 등장하면서, 메모리 오버레이 방식은 더 이상 사용되지 않게 되었고, 운영체제가 자동으로 메모리와 스왑을 관리하는 방식이 자리 잡게 되었다.

스왑

메모리가 모자라 쫓겨난 프로세스를 저장장치의 특별한 공간에 모아두는데 이러한 영역을 스왑 영역이라고 한다.

동작 원리:

운영체제가 메모리 관리의 주체가 되어, 메모리에 공간이 부족한 경우 사용하지 않는 프로세스의 데이터를 디스크의 스왑 영역으로 이동(스왑 아웃)시킨다
필요할 때 스왑 영역에 있는 데이터를 다시 메모리로 가져온다(스왑 인)

스왑 영역은 메모리에 쫓겨났다가 다시 돌아가는 데이터가 머무는 곳이기 때문에 저장장치는 장소만 빌려주고 메모리 관리자가 관리한다.

스왑을 이용하면 운영체제는 물리 메모리의 확장으로 간주한다. 예를 들어, 8GB의 RAM과 4GB의 스왑 영역이 있으면, 운영체제는 12GB의 메모리를 사용할 수 있는 것처럼 인식한다. 하지만 디스크는 RAM보다 속도가 훨씬 느리기 때문에 성능 저하가 발생한다. 따라서 스왑은 메모리 부족 상황을 보조하기 위한 용도로만 사용되며, 물리 메모리를 대체할 수는 없다.

메모리 오버레이와 관계

스왑은 프로그램의 전체 구조를 관리하지 않고, 운영체제의 메모리 관리 방식으로 동작한다. 따라서, 메모리 오버레이 방식과 무관하게 작동할 수 있다.

메모리 가변 분할 방식

프로세스의 크기에 맞게 메모리를 분할하는 연속 메모리 할당 방식이며 세그멘테이션 메모리 관리 기법이라고 부른다.

장점

프로세스를 하나의 연속된 주소로 다룬다

단점

작은 빈 공간이 생기는 외부 단편화가 발생 외부 단편화 문제를 해결하기 위한 메모리 배치 방식은 다음과 같이 크게 세 가지로 나뉜다.

최초 배치

단편화를 고려하지 않는 방식으로 프로세스를 메모리의 빈 공간에 배치할 때 메모리에서 적재 가능한 공간을 순서대로 찾다가 첫 번째로 발견한 공간에 프로세스를 배치한다.

특징

구현이 간단하고 속도가 빠르지만, 외부 단편화가 증가할 수 있음.

최적 배치

메모리의 빈 공간을 모두 확인한 후 크기가 가장 비슷한 곳에 프로세스를 배치한다.

특징

외부 단편화를 줄이지만, 빈 공간을 모두 확인해야 하므로 속도가 느림.

최악 배치

빈 공간을 모두 확인한 후 가장 큰 공간에 프로세스를 배치하는 것으로 최적 배치와 정반대되는 방법이다.

특징

가장 큰 빈 공간을 선택하여 자원을 낭비할 가능성이 있음.

메모리 고정 분할 방식

프로세스의 크기에 상관 없이 메모리를 같은 크기로 나눠 관리한다. 고정 분할 방식을 사용하여 물리 메모리를 나누는 방식을 페이징 메모리 관리 기법이라고 한다.

장점

메모리 관리가 편하다.

-> 현대 메모리 관리는 페이징을 기본으로 한다.

단점

프로세스를 배치하고 공간이 남는 내부 단편화가 발생한다.

ex) 20KB로 메모리를 나눴을 때, 18KB 프로세스를 실행하면, 2KB의 단편화 발생 내부 단편화를 줄이기 위해선 메모리를 어떤 크기로 나눌지 신중하게 결정해야 한다.

외부 단편화와 내부 단편화 비교

외부 단편화: 가변 분할 방식에서 발생하며, 메모리의 빈 공간이 작아서 새로운 프로세스를 배치할 수 없는 경우.
내부 단편화: 고정 분할 방식에서 발생하며, 프로세스가 메모리에 배치되었지만, 할당된 공간보다 작은 크기를 사용할 때 남는 공간.

교착 상태

Sun, 05 Jan 2025 00:00:00 GMT

개요

교착 상태(Deadlock)는 두 개 이상의 프로세스가 서로의 작업을 완료하기 위해 필요한 자원을 기다리며 영원히 진행되지 못하는 상태를 말한다.

교착 상태 발생 예시는 다음과 같다. 위와 같이 임계구역으로 보호되는 프린터와 스캐너가 필요한 두 프로세스 P1과 P2가 각각 프린터와 스캐너를 할당받은 후 양보하지 않는 경우를 예로 들 수 있다.

위와 같이 두 프로세스가 자원을 점유하고 서로 추가 자원을 기다리며 대기하는 상황에 교착 상태가 발생한다.

좀 더 구체적으로 어떤 조건이 충족되어야 교착 상태가 발생했다고 할 수 있는지 알아보자.

교착 상태 필요조건

교착 상태의 네 가지 필요 조건이 있다. 이를 모두 만족해야 교착 상태가 발생했다고 할 수 있다.

상호 배제: 한 프로세스가 사용하는 자원은 다른 프로세스와 공유할 수 없는 배타적인 자원이어야 한다.
비선점: 한 프로세스가 사용 중인 자원은 다른 프로세스가 빼앗을 수 없다.
점유와 대기: 프로세스가 어떤 자원을 점유한 상태에서 추가 자원을 요청하며 기다려야 한다.
순환 대기: 점유와 대기를 하는 프로세스 간 관계가 원을 이뤄야 한다.

위에서 본 예시로 네 가지 조건을 살펴보자.

상호 배제: 프린터와 스캐너는 한 프로세스가 사용하면 다른 프로세스가 사용할 수 없는 배타적인 자원이다.
비선점: P1이 P2가 점유한 스캐너를 빼앗을 수 없다.
점유와 대기: 두 프로세스는 모두 하나의 자원을 점유한 상태에서 다른 프로세스의 자원을 기다리고 있다.
순환 대기: 프린터, 스캐너 그리고 두 프로세스의 관계가 원을 이루고 있다.

기아(Starvation) 상태와 교착(Deadlock) 상태의 차이점

기아 상태는 잘못된 정책으로 인해 특정 프로세스의 우선 순위가 계속해서 미뤄져 작업이 수행되지 않는 것이다. 따라서 Aging 기법으로 해결할 수 있다.

교착 상태는 잘못된 정책이 아니어도 자연적으로 발생한다. 따라서 Aging 기법이나 정책의 수정으로도 해결할 수 없다.

그렇다면 교착 상태는 어떻게 해결해야 할까?

교착 상태 해결 방법

교착 상태를 해결하는 방법은 예방(preventation), 회피(avoidance), 검출(detection)이며, 추가적으로 상태가 발견된 후 자원을 회복(recovery)하는 방법이 있다.

예방(preventation)

위에서 언급한 교착 상태를 유발하는 네 가지 조건이 발생하지 않도록 무력화하는 방식이다. 하지만 자원을 얼마만큼 할당해야 교착 상태가 발생하지 않는다는 보장이 없기 때문에 실효성이 적다.

상호 배제 예방: 독점적으로 사용할 수 있는 자원을 없애버린다. 하지만 현실적으로는 모든 자원을 공유할 수 없기 때문에 상호 배제를 무력화하긴 어렵다.
비선점 예방: 모든 자원을 빼앗을 수 있도록 만든다. 이 또한 현실적으로 모든 자원에 대해 적용할 수 없기 때문에 무력화하기 어렵다.
점유와 대기 예방: 자원을 요청할 때 전부 할당받거나 아예 할당받지 않는다. 이 방법은 자원에 대한 권한이 아닌 프로세스의 자원 사용 방식을 바꾼다는 점에서 위 두 예방 방식과는 다르지만, 작업 방식이 제한되고 자원이 낭비된다는 단점이 있다.
순환 대기 예방: 자원에 순서를 부여하고, 순서대로 자원을 요청하도록 한다. 이 방법 또한 점유와 대기 예방과 마찬가지로 작업 방식이 제한되고 자원이 낭비될 수 있다는 단점이 있다.

회피(Avoidance)

교착 상태가 발생하지 않는 범위 내에서만 자원을 할당하고, 교착 상태가 발생하는 범위에 있으면 할당을 취소하고 프로세스를 대기시키는 방법이다.

이 방법에선 자원의 총수와 현재 할당된 자원의 수를 기준으로 시스템을 안정 상태와 불안정 상태로 나눈다. 그리고 시스템이 안정 상태를 유지하도록 자원을 할당한다.

이 방법의 대표적인 구현 방식은 은행원 알고리즘이다. 대출 금액이 가능한 범위 내이면(안정 상태이면) 대출이 허용되지만 그렇지 않으면(불안정 상태) 거부되는 방식의 알고리즘이다.

문제점

모든 프로세스가 자신이 사용할 자원을 미리 선언해야 하지만 현실적으로 쉬운 일이 아니다.
시스템의 전체 자원수는 일시적인 고장이나 추가가 빈번하기 때문에 고정된 시스템 전체 자원 수를 계산하기 쉽지 않다.
불안정 상태가 되면 반드시 교착 상태가 발생하는 것이 아닌데도 자원을 할당하지 않기 때문에 자원 낭비가 발생한다.

검출(Detection)

타임아웃: 일정 시간 동안 작업이 진행되지 않은 프로세스를 교착 상태가 발생했다고 간주하는 방법
- 장점
  - 구현이 쉽다. -> 가벼운 교착 상태 검출이라고 불림
- 단점
  - 교착 상태가 발생하지 않은 프로세스가 강제 종료될 수 있다.
  - 모든 시스템에 적용할 수 없다.
    - DB와 같은 프로세스는 데이터 일관성을 처리해야 하는 등 중요 조건이 있기 때문에 롤백과 같은 추가 작업이 필요하다.
자원 할당 그래프: 시스템 내 프로세스가 어떤 자원을 사용하고 있는지를 알 수 있어 사이클을 통해 교착 상태를 감지할 수 있다.
- 장점
  - 작업 방식을 제한하지 않으면서 교착 상태를 정확하게 파악할 수 있다.
- 단점
  - 구현이 어렵다. -> 무거운 교착 상태 검출이라고 불림
  - 그래프 유지 보수와 사이클 검사 작업으로 인한 오버헤드가 발생한다.

회복(Recovery)

교착 상태가 검출된 후 프로세스를 강제 종료하거나 자원을 회수해 교착 상태를 해결하는 방법이다.

교착 상태를 일으킨 모든 프로세스 종료
교착 상태를 일으킨 프로세스 중 하나를 골라 순서대로 종료
- 각 프로세스의 우선순위, 작업 시간, 사용하는 자원의 수를 고려해 종료 순서를 정해야 한다.

프로세스 동기화

Fri, 03 Jan 2025 00:00:00 GMT

프로세스 간 통신

프로세스 혹은 스레드는 독립적으로 실행된다. 한 프로세스 내 스레드끼리는 같은 메모리 영역을 공유하기 때문에 어렵지 않지만 프로세스 간 통신은 다르다. 서로 다른 프로세스는 메모리 영역이 다르기 때문에 공유된 메모리를 통해 통신하는 것이 쉽지 않다. 운영체제는 프로세스 간 통신 방법을 제공하는데 이를 IPC(Inter Process Communication) 라고 한다.

대표적인 프로세스 간 통신 종류

공유 메모리나 공유 파일을 이용한 통신: 일정한 메모리 영역이나 파일을 공유하고 이를 통해 데이터를 주고 받는다. 데이터를 주고 받는 방법을 프로세스끼리 결정해야 하기 때문에 가장 원시적인 방법이다.
파이프를 이용한 통신: 하나의 컴퓨터 내 프로세스 간 통신에 많이 사용하는 수단이다. 파이프는 프로세스 간 통신을 위해 운영체제가 제공하는 통신 기법이다. 보통 fork()로 만들어진 부모-자식 간 통신에 사용된다.
소켓을 이용한 통신: 네트워크로 연결된 컴퓨터에서 데이터를 주고받기 위한 통신 기법이다. 파이프와 비교했을 때 초기화할 내용도 많고 시스템 자원도 많이 사용하기 때문에 같은 컴퓨터 내 통신에선 비효율적이다.

통신 방향에 따른 분류

양방향 통신: 데이터를 양쪽 방향으로 동시에 전송할 수 있는 구조 ex) 소켓 이용 통신, 전화
반양방향 통신: 데이터를 양쪽 방향으로 전송 가능하지만, 동시 전송은 불가능한 구조 ex) 무전기
단방향 통신: 한쪽 방향으로만 데이터를 전송할 수 있는 구조 ex) 파이프 이용 통신

통신 구현 방식에 따른 분류

공유 메모리를 사용하는 통신 방식의 가장 큰 문제는 상대방이 데이터를 언제 보낼지 받는 쪽에서 모른다는 것이다. 따라서 데이터를 받는 쪽에서 반복적으로 공유 메모리를 점검하는 수밖에 없다. 이렇게 수시로 점검하며 기다리는 상태를 busy waiting이라고 한다. busy waiting은 시스템 자원 낭비가 크다. 이를 해결하기 위해 데이터가 도착했음을 알려주는 동기화를 사용한다.

프로세스 간 통신은 동기화 기능 여부에 따라 대기가 있는 통신과 없는 통신으로 구분된다. 대기가 있는 통신(blocking communication)을 동기화 통신(synchronous communication), 대기가 없는 통신(non-blocking communication)을 비동기화 통신(asynchronous communication)이라고 한다.

파이프를 이용한 통신과 소켓을 이용한 통신은 대기가 있는 통신이므로 바쁜 대기를 사용하지 않고도 통신이 가능하다.

파이프를 이용한 통신

만약 프로세스 B가 파이프1에 대해 읽기 연산을 수행했는데 프로세스 A가 파이프 1에 대해 쓰기 작업 중이라면, 프로세스 B는 대기 상태가 된다. 이러한 대기 상태는 프로세스 A의 쓰기 작업이 끝나는 순간 자동으로 풀려 동기화가 이뤄진다. 따라서 프로세스 B는 busy waiting를 하지 않아도 된다.

위처럼 파이프 통신 방식은 단방향 통신이기 때문에 양방향 통신을 하기 위해선 2개의 파이프가 필요하다.

소켓을 이용한 통신

서버 쪽 웹 데몬(HTTPD) 포트에 여러 클라이언트가 요청을 보냈다고 해보자. 만약 소켓을 사용하지 않는다면 한 클라이언트가 포트를 장악하고 나머지 클라이언트들은 하염없이 기다려야 한다. 하나의 포트에 여러 클라이언트를 연결하려면 소켓이 필요하다. 클라이언트들은 포트에 연결된 멀티 소켓에 하나씩 연결된다.

네트워킹 상황에서 통신할 때는 연결 프로시저 호출이나 소켓을 이용한다. 원격 프로시저 호출은 다른 컴퓨터에 있는 함수를 호출하는 것을 말한다. 이는 일반적으로 소켓으로 구현된다.

소켓을 이용한 통신에서는 소켓 1개만 사용해도 양방향 통신이 가능하다.

공유 자원과 임계구역

공유 자원

정의:

여러 프로세스나 스레드가 동시에 접근하거나 사용할 수 있는 자원

ex) 메모리, 파일, 데이터베이스, 프린터 등

문제점: 여러 프로세스 또는 스레드가 동시에 공유 자원에 접근하면 데이터 충돌, 불일치, 손상 등의 문제가 발생할 수 있다.

임계구역

정의:

공유 자원에 접근하는 코드 영역으로, 하나의 프로세스나 스레드만이 진입 가능해야 한다.
임계 구역은 공유 자원을 안전하게 사용하기 위해 동기화 기법을 필요로 한다.

경쟁 조건(race condition)

여러 프로세스나 스레드가 동시에 공유 자원에 접근하면서, 실행 결과가 접근 순서에 따라 달라지는 상태

생산자-소비자 문제

생산자-소비자 문제는 Race condition의 전통적인 예시다. 생산자는 물건의 수를 증가시키고, 소비자는 물건의 수를 감소시킨다. 만약 생산자 코드와 소비자 코드가 동시에 실행될 경우 문제가 발생한다. 현재 총합(sum)이 3이라고 해보자.

생산자 코드 먼저 실행

생산자 sum = 4
소비자 sum = 2
결과 sum = 2

소비자 코드 먼저 실행

소비자 sum = 2
생산자 sum = 4
결과 sum = 4

임계구역 문제 해결 조건

임계구역 문제를 해결하는 데 있어 가장 중요한 조건은 다음과 같다.

상호 배제(mutual exclusion): 한 번에 하나의 프로세스만 임계 구역에 진입할 수 있도록 보장

한정 대기(bounded waiting): 어떤 프로세스도 임계구역에 진입하지 못해 무한 대기하지 않아야 함

진행의 융통성(progress flexibility): 한 프로세스가 다른 프로세스의 진행을 방해해서는 안 됨

임계구역 문제 해결 방법

문제 예시

동시 진입 상황: 상호 배제 조건이 충족되지 않아 두 프로세스 이상이 임계구역에 접근
한정 대기 문제: 락을 풀지 못해 작업이 진행되지 못하는 Deadlock 발생
진행의 융통성 문제: 한 프로세스의 진행이 다른 프로세스로 인해 방해받는다.

세마포어

공유 자원의 접근을 제어하기 위한 동기화 도구로 자원을 사용할 수 있는 상태를 나타내는 정수 값을 유지하며, 프로세스나 스레드가 자원에 접근할 때 값을 변경하여 동기화를 구현한다

구성
- 1. 정수 값 (S):
  2. 자원의 상태를 나타낸다
  3. 초기 값은 사용할 수 있는 자원의 개수로 설정된다
- 두 가지 기본 연산:
  - wait() (또는 P()): 자원을 요청
    - 자원을 사용할 수 있으면 값을 감소시키고, 사용 권한을 부여
    - 자원을 사용할 수 없으면 대기
  - signal() (또는 V()): 자원을 해제
    - 자원의 사용이 끝났음을 알리고, 값을 증가시킴
    - 대기 중인 프로세스가 있으면, 자원 사용 권한 부여 wait() 연산 자원을 요청하며 다음과 같이 작동한다
세마포어 값 S가 1 이상이면:
- S를 1 감소시킨다
- 요청 프로세스는 자원을 사용한다
세마포어 값 S가 0이면:
- 요청 프로세스는 대기 큐에 들어가며, 자원 사용 대기 signal() 연산 자원을 해제하며 다음과 같이 작동합니다:
세마포어 값 S가 대기 중인 프로세스가 없다면:
- S를 1 증가시킨다
세마포어 값 S가 대기 중인 프로세스가 있다면:
- 대기 중인 프로세스 하나를 깨워 자원을 사용하게 한다

다음은 2개의 공유 자원에 대해 3개의 프로세스가 작업하는 상황을 나타낸다. 문제점

복잡성:
- 다수의 프로세스가 세마포어를 사용할 경우 설계가 어려움
데드락(Deadlock):
- 프로세스 간의 자원 요청 순서가 꼬일 경우, 데드락이 발생할 수 있음
기아 상태(Starvation):
- 우선순위가 낮은 프로세스가 계속 대기하게 될 수 있음
휴먼 에러:
- 프로그래머가 직접 구현해야 하므로 이를 잘못 사용하거나 사용하지 않을 수 있음

모니터

프로세스나 스레드가 공유 자원에 안전하게 접근할 수 있도록 동기화와 상호 배제를 보장하는 고수준의 동기화 도구로 공유 자원과 이를 사용하는 코드(임계 구역)를 캡슐화하여 동시성 문제를 해결한다.

위 세마포어 알고리즘이 모든 프로세스에서 자동으로 처리된다면, 굳이 따로 wait(), signal()를 사용할 필요가 없다. 모니터는 이를 실제로 구현한 것으로 공유 자원을 내부적으로 숨기고 접근하기 위한 인터페이스만 제공한다.

모니터는 시스템 자원을 사용자로부터 숨기고 사용자 요구 사항을 처리할 수 있는 인터페이스만을 제공한다는 점에서 system call과 같은 개념이라고 볼 수 있다. 장점

캡슐화:
- 공유 자원과 연산을 하나의 단위로 관리하여 코드 가독성과 유지보수성 향상
안전성:
- 동기화 오류 가능성 감소

궁금했던 부분

non-blocking communication의 발전

위에서 언급한 대로 non-blocking communication의 busy waiting을 blocking communication이 동기화를 통해 해결했다. 하지만 동기화 방식은 대기 상태가 길어질 경우 전체 응답성이 떨어지고 성능이 저하될 수 있다는 단점을 가지고 있다.

현대 non-blocking communication은 busy waiting과 동기화 방식의 대기 상태 문제를 해결한다.

고안된 방식:
- 데이터를 수신할 준비가 되었는지 상태를 반복적으로 확인하지 않고, 이벤트 기반 처리나 콜백 메커니즘을 사용
- CPU는 데이터 송수신을 기다리지 않고 다른 작업을 계속 수행
동작 원리:
1. 이벤트 기반 처리:
  - 데이터가 준비되면 이벤트를 발생시켜 관련 작업을 처리
2. 콜백 메커니즘:
  - 데이터 송수신이 완료되었을 때, 사전에 등록된 콜백 함수 호출
장점:
- 응답 시간을 개선하고, 다수의 작업을 동시에 처리 가능
- CPU 자원을 최대한 활용하여 병렬성을 높임

원격 프로시저 호출(RPC)

개념

원격 프로시저 호출(RPC)은 네트워크 상의 다른 시스템(서버)에 있는 함수를 로컬 함수처럼 호출할 수 있게 해주는 기술 예시

Server

from xmlrpc.server import SimpleXMLRPCServer

def add(a, b):
    return a + b

# 서버 생성
server = SimpleXMLRPCServer(("localhost", 8080))
print("Server is running on port 8080...")
server.register_function(add, "add")  # 함수 등록
server.serve_forever()

Client

import xmlrpc.client

# 서버 연결
client = xmlrpc.client.ServerProxy("http://localhost:8080")

# 원격 함수 호출
result = client.add(5, 3)
print(f"Result from server: {result}")

CPU 스케줄링

Sun, 29 Dec 2024 00:00:00 GMT

개요

CPU 스케줄러는 여러 프로세스의 상황을 고려해 CPU와 시스템 자원을 어떻게 배분할지 결정한다. 즉, 프로세스의 모든 상태 변화를 조정하는 것이다.

종류

CPU 스케줄러는 프로세스 관리의 범주를 나누어 스케줄링한다. 규모에 따라 장기 스케줄러, 중기 스케줄러, 단기 스케줄러로 구분된다.

장기 스케줄러: 시스템 내 전체 작업 수를 조절한다.
- 현대 OS에선 사용 빈도가 낮다.
중기 스케줄러: 시스템 내 부하를 조절하기 위해 과부하 전 프로세스를 보류 상태로 보내거나 보류 상태의 프로세스를 활성화한다.
단기 스케줄러: 어떤 프로세스에 CPU를 할당할 것인지 결정한다.
- CPU 스케줄링에서 가장 중요한 역할 담당

목적

공평성: 모든 프로세스가 자원을 공평하게 배정받아야 한다.
효율성: 시스템 자원이 유휴 시간 없이 사용되도록 스케줄링 해야 한다.
안정성: 우선순위를 사용해 중요 프로세스가 먼저 작동되도록 함으로써 시스템 자원을 점유하거나 파괴하려는 프로세스로부터 자원을 보호해야 한다.
확장성: 프로세스가 증가해도 시스템이 안정적으로 작동하도록 해야 한다.
반응 시간 보장: 시스템이 적절한 시간 안에 프로세스의 요구에 반응해야 한다.
무한 연기 방지: 특정 프로세스의 작업이 무한하게 연기되어선 안 된다.

스케줄링 시 고려 사항

스케줄러가 어떤 프로세스에 우선적으로 CPU를 할당할지 결정할 때 고려해야할 사항이 있다.

선점형 스케줄러와 비선점형 스케줄러

구분	선점형 스케줄러	비선점형 스케줄러
작업 방식	실행 중인 프로세스가 끝나기 전에, 우선순위가 높은 프로세스가 CPU를 점유할 수 있다	실행 중인 프로세스가 끝날 때까지 CPU 점유를 유지하며, 다른 프로세스는 대기한다.
장점	- 응답 시간이 짧아 사용자 작업의 응답성이 향상된다 - 긴 작업을 대기시키고 짧은 작업을 우선 처리 가능하다 - 동적 우선순위 변경이 가능하다	- 구현이 단순하고, 컨텍스트 스위칭 비용이 적다 - CPU가 특정 작업에 집중할 수 있어 처리량(Throughput)이 증가한다
단점	- 잦은 컨텍스트 스위칭으로 CPU 오버헤드 발생한다	- 프로세스 간 공정성이 떨어질 수 있다 - 긴 작업이 완료되기 전까지 다른 작업이 계속 대기(컨보이 효과)할 가능성이 있다
사용 사례	- 시분할 방식 스케줄링에 사용된다	- 일괄 작업 방식 스케줄링에 사용된다

프로세스 우선순위

프로세스에 우선순위가 있다는 것은 중요도가 다르다는 것이다. 프로세스는 크게 커널 프로세스와 일반 프로세스로 나뉘며, 커널 프로세스가 일반 프로세스보다 우선순위가 높다.

일반 프로세스도 중요도가 각각 다르기 때문에 우선순위가 다르다. 이 우선순위는 사용자가 조절이 가능하다. 하지만 특정 프로세스에 우선순위를 너무 높이면, 다른 프로세스 처리에 영향이 가기 때문에 유닉스에선 관리자에게만 해당 권한을 부여한다.

CPU 집중 프로세스와 I/O 집중 프로세스

프로세스는 CPU를 사용해 작업하는 실행 상태 또는 I/O를 요청해 완료되기까지 기다리는 대기 상태에 있다. 이때 CPU를 할당받아 실행하는 작업을 CPU burst, I/O 작업을 I/O burst라고 한다. 프로세스는 위 작업 형태에 따라 CPU 집중 프로세스와 I/O 집중 프로세스로 나눌 수 있다. CPU 집중 프로세스는 CPU burst가 많고, I/O 집중 프로세스는 I/O burst가 많다.

두 프로세스가 있다고 할 때 어떤 프로세스의 우선순위를 높이는 것이 효율적일까? 위에서 볼 수 있듯 I/O 집중 프로세스를 먼저 실행 상태로 옮기는 것이 효율적이다. I/O 집중 프로세스가 CPU 집중 프로세스보다 실행 상태에 먼저 들어가는 경우를 사이클 훔치기 라고 한다.

다중 큐

준비 상태의 다중 큐

프로세스는 저마다 중요도가 다르며 중요도는 PCB에 표시된다. 스케줄러가 모든 프로세스의 PCB를 뒤져 우선순위가 높은 프로세스를 찾으려면 상당히 번거로울 것이다.

따라서 우선순위에 따라 여러 개의 큐를 만들어 프로세스를 분리한다. 이를 간단히 도식화하면 다음과 같다.

프로세스의 우선순위를 배정하는 방식은 고정 우선순위 방식과 변동 우선순위 방식이 있다.

고정 우선순위 방식: 프로세스에 부여된 우선순위가 프로세스가 종료될 때까지 바뀌지 않는다.
- 장점: 구현이 쉽다.
- 단점: 시스템 변화에 대응하기 어려워 효율이 떨어진다.
변동 우선순위 방식: 프로세스 생성 시 부여받은 우선순위가 작업 중간에 변한다.
- 장점: 시스템 효율을 높인다.
- 단점: 구현이 어렵다.

대기 상태의 다중 큐

대기 상태는 입출력이 완료되기를 기다리는 프로세스가 모인 곳이다. 여기선 같은 I/O를 요구한 프로세스들끼리 모아놓는다. I/O 작업이 끝나고 인터럽트가 도착하면, 준비 상태가 된다.

준비 상태의 다장 큐는 한 번에 하나의 프로세스를 꺼내 CPU에게 할당하지만, 대기큐는 여러 개의 PCB를 동시에 꺼내 준비 상태로 옮긴다. 이렇게 동시에 끝나는 인터럽트를 처리하기 위해 인터럽트 벡터라는 자료구조를 사용한다.

스케줄링 알고리즘

스케줄링 알고리즘의 선택 기준

어떤 스케줄링 알고리즘이 효율적인지 파악하려면 그 기준이 있어야 한다.

CPU 사용률: 전체 시스템의 동작 시간 중 CPU가 사용된 시간
처리량: 단위 시간당 작업을 마친 프로세스의 수
대기 시간: 작업을 요청한 프로세스가 대기하는 시간
응답 시간: 프로세스 시작 후 첫 번째 출력 또는 응답이 나올 때까지 걸리는 시간
반환 시간: 대기 시간 + 실행 시간

비선점형 알고리즘

프로세스가 CPU를 할당받으면 작업이 끝날 때까지 CPU를 놓지 않는다. 이 경우 효율이 떨어져 지금은 거의 사용되지 않는다.

FCFS (First Come, First Served):
- 도착 순서대로 프로세스를 처리
- 장점: 구현이 간단
- 단점: 앞의 긴 작업으로 인해 뒤의 작업이 지연되는 컨보이 효과 발생
SJF (Shortest Job First):
- 실행 시간이 가장 짧은 프로세스를 우선 처리
- 장점: 평균 대기 시간 최소화
- 단점: 우선순위에 밀려 작업이 계속 연기되는 기아 상태 발생 가능

선점형 알고리즘

시분할 시스템을 고려하여 만들어진 알고리즘으로, 어떤 프로세스가 CPU를 할당받아 실행 중이라도 운영체제가 CPU를 빼앗을 수 있다.

Round Robin (RR):
- 모든 프로세스에 동일한 타임 슬라이스를 할당 -> 우선순위가 적용되지 않음
- 장점: 공정성 보장, 짧은 응답 시간
- 단점: 타임 슬라이스가 적절하지 않으면 성능 저하
SRTF (Shortest Remaining Time First):
- SJF 스케줄링과 RR 스케줄링을 혼합한 방식
- 실행 중인 작업보다 남은 실행 시간이 짧은 작업이 도착하면 CPU를 빼앗김
- 장점: 평균 대기 시간 최소화
- 단점: 작업의 실행 시간을 예측하기 어려움
Priority Scheduling (선점형):
- 높은 우선순위의 작업이 도착하면 실행 중인 작업을 중단
- 장점: 중요한 작업을 빠르게 처리
- 단점: 기아 상태 발생 가능

프로세스의 우선순위는 시스템의 효율성이 아닌 프로세스의 중요도를 기준으로 결정된다.

다단계 큐 스케줄링

다단계 큐 스케줄링은 우선순위에 따라 준비 큐를 여러 개 사용하는 방식이다. 각각의 큐는 RR방식으로 운영되며, 상단 큐에 있는 모든 프로세스의 작업이 끝나야 다음 우선순위 큐의 작업이 시작된다.

장점

단순성:
- 큐를 분리하여 처리하므로 구조가 명확하다.

단점

유연성 부족:
- 큐 간 이동이 불가능하므로, 동적으로 프로세스 우선순위를 변경하기 어렵다.
기아 상태(Starvation):
- 우선순위가 낮은 큐에 있는 프로세스가 오랫동안 실행되지 않을 수 있다.

다단계 피드백 큐 스케줄링

다단계 피드백 큐 스케줄링은 우선순위가 낮은 프로세스에 불리한 다단계 큐 스케줄링의 문제점을 보완한 방식이다. 이 방식에서 프로세스는 CPU를 사용한 후 원래 큐로 되돌아가지 않고 우선순위가 하나 낮은 큐의 끝으로 들어간다. 때문에 우선순위가 낮은 프로세스의 실행이 연기되는 문제를 완화할 수 있다.

물론 프로세스의 우선순위가 낮아진다고 해도 커널 프로세스가 일반 프로세스의 큐에 삽입되지는 않는다.

또한 이 방식에서는 우선순위에 따라 타임 슬라이스의 크기가 다르다. 프로세스의 우선순위가 낮아질 수록 타임 슬라이스의 크기가 커진다. 따라서 어렵게 얻은 CPU를 좀 더 오랫동안 사용할 수 있도록 한다.

장점

유연성:
- 프로세스 특성에 따라 큐 간 이동이 가능하다
기아 상태 방지:
- 우선순위가 낮은 프로세스도 시간이 지나면 실행될 기회를 얻는다
성능 최적화:
- 짧은 작업은 빠르게 처리하고, 긴 작업은 낮은 우선순위 큐로 이동한다

단점

복잡성 증가:
- 큐 이동 조건과 알고리즘 설계가 복잡하다
컨텍스트 스위칭 비용 증가:
- 프로세스가 큐를 이동할 때 잦은 컨텍스트 스위칭 발생한다

프로세스와 스레드

Sat, 28 Dec 2024 00:00:00 GMT

프로세스란?

프로그램과 프로세스의 차이

프로그램은 어떤 데이터를 사용하여 어떤 작업을 할지 그 절차를 정의한 것이다. 따라서 저장장치에 저장되는 정적인 상태다.

반면 프로세스는 정의된 절차를 실행에 옮기는 것으로 메모리에 올라온 동적인 상태다. 그렇다면 프로그램이 프로세스로 전환되려면 어떤 과정을 거쳐야할까?

프로그램에서 프로세스로의 전환

가장 먼저 운영체제는 프로그램을 메모리의 적당한 위치로 가져온다. 그와 동시에 프로세스 제어 블록(PCB)을 만든다. PCB에는 프로세스를 처리하는 데 필요한 다양한 정보가 들어있어 프로그램이 프로세스로 전환되는 데 꼭 필요하다.

프로세스 제어 블록

개념: 운영체제가 각 프로세스를 관리하기 위해 사용하는 데이터 구조
주요 정보
- PID: 프로세스를 구분하는 ID
- 메모리 관련 정보: 프로세스의 메모리 위치 정보
- 각종 중간값: 시분할 시스템에서는 여러 프로세스가 번갈아 가며 실행되기 때문에 다음에 작업해야할 코드의 위치가 담긴 프로그램 카운터가 저장된다.
- 우선순위 정보: 프로세스의 스케줄링 순서를 결정한다.
주요 역할
- 프로세스 상태 관리
- 스케줄링 지원
- Context Switching

프로세스의 상태

이전 기록에서 다룬 일괄 작업 시스템의 경우 하나의 작업이 모두 끝난 후 다른 작업이 수행된다. 따라서 프로세스 상태는 생성, 실행, 완료 중 하나가 된다.

하지만 시분할 시스템은 좀 더 복잡하다. 프로세스의 작업이 끝나지 않아도 CPU를 넘겨주는 일이 빈번하기 때문이다. 생성 상태 생성 상태는 프로그램이 올라오고 PCB를 할당받은 상태다. 생성된 프로세스는 바로 실행되는 것이 아닌 준비 상태에서 본인 순서를 기다린다.

준비 상태 준비 상태는 실행 순서를 기다리는 상태다. PCB는 Ready Queue에서 기다리며 CPU 스케줄러에 의해 관리된다.

실행 상태 실행 상태는 프로세스가 CPU를 할당받아 실행되는 상태다. 자신에게 주어진 시간, 즉 타임 슬라이스 동안만 작업이 가능하다. 타임 슬라이스 동안 작업이 완료되면 정상 종료되고, 작업을 끝내지 못하면 클록이 보낸 인터럽트에 의해 timeout이 발생해 다시 준비 상태로 돌아간다.

대기 상태 대기 상태는 실행 상태에서 입출력을 요청한 프로세스가 입출력 완료를 기다리는 상태다. 입출력이 완료되면 인터럽트가 발생해 준비 상태로 전환된다 .

완료 상태 완료 상태는 프로세스가 종료되는 상태다. 코드와 사용한 데이터를 메모리에서 삭제하고 PCB는 폐기한다.

Context Switching

Context Switcing은 CPU가 현재 실행 중인 프로세스의 상태(Context)를 저장하고, 다음에 실행할 프로세스의 상태를 복원하여 작업을 전환하는 과정이다.

절차

실행 중인 프로세스 상태 저장
실행 중인 프로세스의 상태(Context)를 PCB(Process Control Block)에 저장한다.
저장되는 정보:
- 프로그램 카운터(PC): 다음에 실행할 명령어의 주소.
- CPU 레지스터 상태: 계산 중이던 데이터, 연산 상태 등.
- 메모리 관리 정보: 프로세스가 사용하는 메모리 주소 정보.
새 프로세스의 상태 복원
실행할 프로세스의 PCB에서 상태(Context)를 복원한다.
복원되는 정보:
- 프로그램 카운터(PC).
- CPU 레지스터 값.
- 메모리 정보.
프로세스 전환
CPU가 새 프로세스의 명령어 실행을 시작한다.

Context Switching은 위처럼 일반적으로 타임 슬라이스가 만료되었을 때 발생한다. 하지만 다음과 같은 상황에서도 발생한다.

입출력 요청
우선순위 스케줄링
인터럽트 발생

타임 슬라이스의 크기

위 Context Switching이 너무 빈번하게 일어나면, 시스템 성능이 떨어질 것이다. 따라서 타임 슬라이스의 크기를 정하는 것도 중요하다.

만약 타임 슬라이스 크기가 너무 크다면, 작업 전환까지 시간이 너무 오래 걸려 끊겨 보일 것이다. 비디오 플레이어와 워드프로세서를 동시에 실행한다고 해보자. 타임 슬라이스가 너무 크다면, 비디오가 끊겨 보이고, 워드프로세서의 반응 속도도 매우 느릴 것이다.

타임 슬라이스를 너무 작게 설정한다면, 위에서 말한 대로 시스템의 성능이 떨어진다. Context Switching에 5ms가 걸린다고 가정해보자. 만약 타임 슬라이스를 1ms로 설정한다면, 실제 작업을 못 하는 문제가 발생할 것이다.

결론적으로 타임 슬라이스는 되도록 작게 설정하되 Context Switching에 걸리는 시간을 고려해 적당한 크기로 설정하는 것이 중요하다.

프로세스의 연산

이번엔 프로세스가 어떻게 생성되고 분리되는지 알아보자.

프로세스의 구조

코드 영역: 프로그램의 실행 코드(명령어)가 저장되는 영역으로 CPU가 실행할 기계어로 번역된 명령어들이 포함

읽기 전용으로 처리된다. 데이터 영역: 코드가 실행되면서 사용하는 변수나 파일 등 각종 데이터가 저장되는 영역
읽기/쓰기로 처리된다. 스택 영역: 함수 호출 시 지역 변수, 매개변수, 반환 주소 등이 저장되는 영역
사용자에게는 보이지 않는다.

fork() 시스템 호출

개념: fork()는 실행중인 프로세스(부모 프로세스)로부터 새로운 프로세스(자식 프로세스)를 생성한다.

동작 방식:

프로세스 복사:
- 부모 프로세스의 메모리 공간(텍스트, 데이터, 힙, 스택)을 그대로 복사하여 자식 프로세스를 생성.
프로세스 ID(PID):
- fork()는 자식 프로세스에서는 0을 반환, 부모 프로세스에서는 자식의 PID(Process ID)를 반환.
독립적인 실행:
- 부모와 자식 프로세스는 서로 독립적으로 실행되며, 서로 영향을 미치지 않음.
- 각 프로세스는 자신만의 PCB(Process Control Block)를 가짐.

장점

프로세스의 생성 속도: 새로 생성하는 것보다 생성 속도가 빠르다.
추가 작업 없이 자원 상속: 부모 프로세스가 사용하던 모든 자원을 추가 작업 없이 상속할 수 있다.
시스템 관리 효율: 부모 프로세스와 자식 프로세스가 구분자로 연결되어 있기 때문에 자식 프로세스를 종료하면 부모 프로세스가 정리할 수 있다.

exec() 시스템 호출

개념: exec()는 기존 프로세스를 새로운 프로세스로 전환하는 함수다.

동작 방식:

현재 프로세스 대체:
- exec()는 호출된 프로세스의 기존 코드, 데이터, 힙, 스택을 모두 제거하고, 새로 지정된 프로그램으로 메모리 내용을 교체합니다.
프로세스 ID 유지:
- exec()는 새로운 프로그램을 실행하지만, 프로세스 ID(PID)는 변경되지 않습니다.
- 즉, 프로세스의 껍데기는 그대로 유지된 상태에서 실행 코드만 변경됩니다.
새로운 프로그램 실행:
- 새로운 프로그램의 실행이 시작되며, 기존 프로그램의 흐름은 완전히 종료됩니다.

exec()를 호출하면, fork()와 같이 새로운 프로세스가 생성되는 것이 아닌 기존 프로세스가 새로운 프로세스로 대체된다. 따라서 기존 프로세스의 PID를 유지한다.

fork()와 exec()

위 내용을 요약하면, fork()는 부모 프로세스를 복사해 효율적으로 새로운 프로세스를 생성하고, exec()는 기존 프로세스와 다른 새로운 프로세스로 전환할 수 있게 한다.

이러한 프로세스의 복사와 전환은 프로세스의 생성 과정과 계층 구조를 이해하는 데 큰 도움이 된다.

프로세스의 계층 구조

유닉스의 예를 통해 프로세스의 계층 구조를 살펴보자. 유닉스에서 커널이 처음 부팅되면, 커널 관련 프로세스를 여러 개 만드는데 그 중 init 프로세스는 전체 프로세스의 출발점이 된다. fork()와 exec() 시스템 호출을 이용해 자식 프로세스를 만드는 것이다.

장점

관리 용이성:
- 트리 구조를 통해 프로세스의 부모-자식 관계를 명확히 하고, 고아 프로세스나 좀비 프로세스를 효율적으로 관리.
계층적 접근:
- 부모-자식 관계를 기반으로 프로세스 상태를 추적하거나 자원을 할당.
자원 분리:
- 부모와 자식 프로세스는 독립적인 메모리와 실행 흐름을 가지므로, 안전하고 안정적인 운영 가능.
유연한 작업 분배:
- 부모 프로세스가 주요 작업을 관리하고, 자식 프로세스가 세부 작업을 분담.

고아 프로세스: 자식 프로세스가 종료되기 전 부모 프로세스가 먼저 종료될 경우 자식 프로세스는 고아 프로세스가 된다. 좀비 프로세스: 자식 프로세스가 종료되었는데도 부모 프로세스가 뒤처리를 하지 않을 때 발생한다.

위 고아 프로세스와 좀비 프로세스가 많아지면, 자원이 낭비되기 때문에 효율적인 운영에 방해가 된다. 따라서 운영체제는 주기적으로 반환되지 못한 자원을 회수해야 한다.

스레드

오늘날의 운영체제는 프로세스의 낭비 요소를 제거하고 프로세스 작업의 유연성을 얻기 위해 멀티스레드를 사용한다.

개념

스레드는 프로세스의 코드에 정의된 절차에 따라 CPU에 작업 요청을 하는 실행 단위다. 운영체제 입장에서 작업 단위는 프로세스이고, 프로세스가 생성되고 CPU 스케줄러가 CPU에게 전달하는 작업하나가 스레드다. 즉, CPU 입장에서 작업 단위는 스레드인 것이다.

프로세스와 스레드의 차이

구분	프로세스	스레드
실행 단위	독립적인 실행 단위.	프로세스 내의 실행 단위.
자원 관리	프로세스는 독립된 메모리 공간(코드, 데이터, 힙, 스택)을 가짐.	같은 프로세스 내의 스레드끼리 메모리와 자원 공유.
통신 방식	프로세스 간 통신(IPC) 필요.	프로세스 내 스레드는 직접 메모리 접근 가능.
오버헤드	생성 및 전환 시 오버헤드 큼.	생성 및 전환 시 오버헤드 작음.
독립성	프로세스는 서로 독립적.	같은 프로세스 내 스레드는 독립적으로 실행되지만, 자원 공유로 인해 영향을 받음.

스레드는 프로세스라는 개념이 만들어진 한참 후에 만들어진 개념이다. 초기의 운영체제에서는 작업의 단위가 프로세스 하나뿐이었다. 당시엔 1개의 스레드만 가진 프로세스만 있는 셈이었기 때문에 구분할 필요가 없던 것이다.

CPU와 프로그래밍 기술이 발전하면서 여러 개의 코어를 가진 CPU가 생겨나 멀티스레드를 지원하기 시작했다. 따라서 프로세스를 다양한 스레드로 나눠 여러 코어에 배분함으로써 시스템의 효율을 높이게 된 것이다.

멀티스레드

멀티스레드는 하나의 프로세스에서 여러 스레드가 병렬로 실행되도록 하는 기술이다.

과거에는 프로세스 하나에 스레드가 하나였기 때문에 여러 작업을 하려면 fork() 시스템 호출로 여러 개의 프로세스를 만들어야 했다. 하지만 오늘날에는 하나의 프로세스에 여러 스레드를 만들어 사용한다.

프로세스의 데이터는 정적인 영역과 동적인 영역으로 나뉜다. 동적인 영역의 대표적인 예는 레지스터 값, 스택 등이 있다. 멀티스레드 환경에선 여러 스레드들이 정적인 영역을 공유하고, 독립적으로 동적 영역을 가진다.

장점

응답성 향상: 여러 스레드를 활용하므로 사용자의 작업 요구에 빨리 응답할 수 있다.
자원 공유: 프로세스가 가진 자원을 모든 스레드가 공유하게 되어 원활하게 작업을 진행할 수 있다.
효율성 향상: 여러 개의 프로세스를 생성할 필요가 없어 불필요한 자원의 중복을 막는다.
다중 CPU 지원: 2개 이상의 CPU를 가진 컴퓨터에서 효율적으로 CPU를 이용할 수 있다.

단점

동기화 문제: 여러 스레드가 동일한 자원(변수, 데이터 구조)에 접근할 때, 데이터 충돌이나 비정상 동작이 발생할 수 있다.
디버깅의 어려움: 스레드는 병렬로 실행되므로 실행 순서를 예측하기 어렵고, 디버깅 및 테스트가 복잡하다.
데드락: 여러 스레드가 서로가 보유한 자원을 기다리며 영원히 정지 상태에 빠지는 문제가 발생할 수 있다.
하나의 스레드 오류가 전체 프로세스에 영향: 같은 프로세스 내의 스레드들은 메모리를 공유하므로, 하나의 스레드가 비정상 종료되면 다른 스레드와 프로세스 전체에 영향을 줄 수 있다.

컴퓨터 구조와 성능

Fri, 27 Dec 2024 00:00:00 GMT

기본 구성

하드웨어는 기본적으로 필수 장치와 주변 장치로 나뉜다. CPU와 메인 메모리가 필수 장치이고, 입출력 장치나 저장 장치 등이 주변 장치로 분류된다.

메인 메모리는 제 1 저장 장치라고도 불리며, 전력이 끊어지면 데이터를 잃어버린다. 따라서 영구적으로 데이터를 보관하기 위해선 별도의 작업이 필요하다. 이 역할을 해주는 것이 USB, 하드디스크 같은 저장 장치이고, 제 2 저장 장치라고도 불린다.

왜 저장 장치는 메모리보다 느릴까?

설계 목적 차이: 메인 메모리는 데이터를 빠르게 읽고 쓰기 위해 설계되었으며, CPU와 가까운 위치에서 데이터를 직접 주고받는다. 반면, 저장 장치는 데이터를 안정적으로 장기간 보존하는 데 중점을 둔다.
비용과 기술적 제약: 메모리는 고속 처리를 위해 고급 반도체 기술을 사용하지만, 저장 장치는 비용 효율성을 중시하여 대량의 데이터를 저장할 수 있도록 설계된다.
데이터 접근 방식 차이: 메모리는 랜덤 액세스 방식으로 동작하여 모든 위치에 균일한 시간으로 접근 가능하지만, 저장 장치는 블록 단위 접근으로 인해 속도가 느릴 수 있다.

폰노이만 구조

폰노이만 구조는 CPU, 메모리, 입출력장치, 저장장치가 버스로 연결된 시스템 설계 모델을 말한다. 이 구조는 오늘날 대부분의 컴퓨터 시스템에 적용된 기본 아키텍처다.

이전 컴퓨터는 하드와이어링 형태였기 때문에 다른 용도로 컴퓨터를 사용하려면 전선의 연결을 바꿔야했다. 폰노이만 구조 덕분에 하드웨어를 바꾸지 않고도 프로그램을 교체할 수 있게 된 것이고, 컴퓨터로 다양한 작업을 할 수 있게 된 것이다.

폰노이만 구조의 가장 중요한 특징은 모든 프로그램은 메모리에 올라와야 실행할 수 있다. 는 것이다.

시스템 버스와 CPU 버스

시스템 버스는 메모리와 주변장치를 연결하며, FSB(Front-Side Bus) 혹은 전면 버스라고 부른다. CPU 버스는 CPU 내부 다양한 장치들을 연결하는 버스로 BSB(Back-Side Bus) 혹은 후면 버스라고 부른다. BSB의 속도는 CPU의 클록과 같으며 FSB보다 훨씬 빠르다.

클록

컴퓨터에서 일정한 박자를 만들어내는 것을 클록이라고 한다. 클록에 의해 일정 간격으로 만들어진느 틱을 펄스 혹은 클록 틱이라고 부른다. 클록이 펄스를 만들면 거기에 맞춰 컴퓨터 안 부품들이 작업을 진행한다.

이 펄스의 단위는 Hz다. 1초 동안 몇 번의 작업이 이루어져 몇 번의 펄스가 발생했는지 의미한다. 예를 들어 3GHz의 CPU가 있다면 해당 CPU는 1초 동안 약 30억 번의 작업이 가능한 CPU인 것이다.

cpu와 메모리

CPU 구성

산술논리 연산장치(ALU): CPU에서 데이터를 연산하는 장치
제어장치: CPU에서 작업을 지시하는 부분
레지스터: 작업에 필요한 데이터를 CPU 내부에 보관하는 곳

레지스터 종류

레지스터는 크게 일반 레지스터와 특수 레지스터로 구분된다. 일반 레지스터는 사용자 프로그램에 의해 변경되지만, 특수 레지스터는 사용자가 임의로 변경할 수 없다.

일반 레지스터

데이터 레지스터(DR): 메모리에서 가져온 데이터를 임시로 저장한다.
주소 레지스터(AR): 데이터 또는 명령어가 저장된 메모리의 주소를 저장한다.

특수 레지스터

프로그램 카운터(PC): 다음에 실행할 명령어의 주소를 기억하고 있다가 제어장치에 알려준다.
명령어 레지스터(IR): 현재 실행 중인 명령어를 저장한다.
메모리 주소 레지스터(MAR): 메모리에서 데이터를 가져오거나 반대로 메모리로 데이터를 보낼 때 주소를 지정하는 데 사용된다.
메모리 버퍼 레지스터(MBR): 메모리에서 가져온 데이터나 메모리로 옮겨갈 데이터를 임시로 저장한다. 항상 메모리 주소 레지스터와 함께 동작한다.

AR & MAR 둘 다 메모리 주소를 다루지만, AR은 CPU 내부 작업을 위한 주소 저장에 사용되며, MAR은 메모리 접근을 위한 주소를 관리한다.

DR & MBR 둘 다 데이터를 임시 저장하지만, DR은 CPU 연산 중 데이터를 저장하며, MBR은 메모리와 CPU 간 데이터 전송을 위한 버퍼 역할을 한다.

그림을 통해 Load mem(100), register 2가 처리되는 과정을 살펴보자.

PC에는 실행할 코드의 행 번호가 저장된다. 이 코드는 제어장치(Control Unit)에서 실행된다. 실행된 코드는 IR에 저장된다.
제어장치가 IR에 있는 명령어를 해석해 메모리 100에 있는 데이터를 가져오라는 신호를 보낸다.
MAR에는 100이 저장된다. 메모리에 있는 데이터를 CPU로 옮기는 일은 메모리 컨트롤러가 담당한다. 레지스터는 CPU가 관리하는 영역이기 때문에 메모리 컨트롤러는 숫자 2를 레지스터로 직접 옮기지 못한다. 따라서 MBR로 보낸다.
제어장치는 메모리 버퍼 레지스터에 저장된 값 2를 레지스터 2로 옮긴다.

버스의 종류

시스템 버스는 제어 버스, 주소 버스, 데이터 버스로 나뉜다.

제어 버스: 제어 버스에는 다음에 어떤 작업을 할지 지시하는 제어 신호가 오고 간다.
- CPU, 메모리, 주변장치와 양방향으로 오고 간다.
주소 버스: 메모리의 데이터를 읽거나 쓸 때 어느 위치에서 작업할 것인지를 알려주는 주소 정보가 오고 간다. 이 버스는 메모리 주소 레지스터와 연결되어 있으며 단방향이다.
- CPU에서 메모리나 주변장치로 나간다. 반면 주소 버스를 통해 CPU로 전달되는 정보는 없다.
데이터 버스: 데이터가 목적지까지 이동할 수 있도록 한다. 이 버스는 메모리 버퍼 레지스터와 연결되어 있으며 양방향이다.

버스의 대역폭은 한 번에 전달할 수 있는 데이터의 최대 크기다. 이 버스의 대역폭은 CPU가 한 번에 처리할 수 있는 데이터의 크기와 같다. 흔히 32bit CPU, 64bit CPU라고 하는데 여기서 32bit, 64bit가 CPU가 한 번에 처리할 수 있는 데이터의 크기이며, 이는 버스의 대역폭, 레지스터의 크기와 같다.

메모리

종류

메모리는 읽거나 쓸 수 있는 RAM(Random Access Memory)과 읽기만 가능한 ROM(Read Only Memory)으로 구분된다. RAM

휘발성
- DRAM: 데이터가 일정 시간이 지나면 사라진다.
- SRAM: 전력이 공급되는 동안 데이터를 저장할 수 있다.
- SDRAM: 펄스가 발생할 때마다 데이터를 저장한다.
비휘발성
- FRAM
- PRAM ROM
PROM
EPROM 전력이 끊겨도 데이터를 보관할 수 있다. 하지만 읽기 전용이기 때문에 BIOS(Basic Input/Output System)를 ROM에 저장한다.

보호

운영체제 영역이나 다른 프로그램 영역으로 침범하려는 바이러스로부터 메모리를 보호하기 위해선 하드웨어의 도움이 필요하다.

CPU는 현재 진행 중인 작업의 메모리 시작 주소를 경계 레지스터에 저장하고, 마지막 주소를 한계 레지스터에 저장한다. 작업이 진행되는 과정에서 두 주소 범위를 벗어나는지 점검해 보호한다.

만약 주소 범위를 벗어난다면, 인터럽트가 발생한다. 이땐 운영체제가 해당 프로그램을 강제 종료시키게 된다.

부팅

결국 운영체제도 CPU에 의해 실행되는 프로그램이다. 따라서 운영체제를 메모리에 올리는 과정이 있어야 하고 이 과정을 부팅이라고 한다.

사용자가 컴퓨터의 전원을 키면 ROM에 저장된 BIOS가 실행된다. BIOS는 하드웨어를 점검하고, 운영체제를 실행시키는 부트스트랩 코드를 실행시킨다.

컴퓨터 성능 향상 기술

현대 컴퓨터 구조의 가장 큰 문제는 CPU와 메모리, 주변장치의 작업 속도가 다르다는 것이다. CPU는 내부 버스의 속도와 같다. 하지만 시스템 버스의 속도보다 빠르기 때문에 주변 장치의 속도가 따라가지 못한다.

이를 해결하기 위해선 어떤 방법이 있을까?

버퍼

버퍼는 두 장치 사이의 속도 차이를 완화하는 역할을 한다. 일정량의 데이터를 모아 한꺼번에 전송하면 적은 작업량으로도 많은 양의 데이터를 옮길 수 있다.

스풀

버퍼와 유사한 용어로 스풀이 있다. 스풀은 CPU와 입출력장치가 독립적으로 동작하도록 고안된 소프트웨어적 버퍼이다.

예를 들어 워드프로세서로 작업하고 프린터로 출력한다고 했을 때 스풀러가 없다면, 출력까지 워드프로세서가 알아서 처리해야 하므로 인쇄가 끝날 때까지 워드프로세서를 사용할 수 없게 되는 것이다. -> 인쇄 내용을 스풀러 공간에 저장하면 인쇄 동안에도 워드프로세서로 다른 작업을 할 수 있게 된다.

캐시

캐시는 메모리와 CPU 간의 속도 차이를 완화하기 위해 메모리의 데이터를 미리 가져와 저장해 두는 임시 저장소라고 할 수 있다. 메모리는 시스템 버스의 속도로 작동하기 때문에 비교적 느리지만, 캐시는 CPU 내부 버스의 속도로 작동하기 때문에 빠르다.

CPU는 메모리에 접근할 때 먼저 캐시를 방문한다. 원하는 데이터를 찾았을 때 캐시 히트라고 하며 그 데이터를 바로 사용한다. 하지만 원하는 데이터가 캐시에 없다면, 메모리로 가서 그 데이터를 찾아야 한다. 이를 캐시 미스라고 한다.

컴퓨터의 성능을 향상하려면 캐시 적중률이 높아야 한다.

캐시의 크기를 늘린다.
지역성 이론에 따라 데이터를 가져온다.
- 가까이 있는 데이터가 사용될 확률이 더 높다는 이론

만약 캐시에 있는 데이터가 변경되면, 이 변경 사항을 메모리에 반영해야 한다. 이때 두가지 방식이 있다.

즉시 쓰기: 캐시의 변경 사항을 메모리에 즉시 반영한다.
- 장점: 메모리와 캐시 사이 데이터 불일치가 발생하지 않음
- 단점: 빈번한 데이터 전송으로 성능이 느려짐
지연 쓰기: 캐시의 변경 사항을 모아서 주기적으로 반영한다.
- 장점: 데이터 전송 횟수가 줄어 시스템 성능 향상
- 단점: 메모리와 캐시 사이 데이터 불일치가 발생할 수 있음

저장장치의 계층 구조

저장장치의 계층 구조는 사용자가 저렴한 가격으로 용량은 하드디스크처럼 사용하고 작업 속도는 레지스터처럼 빠르게 만들어준다. 하지만 중복되는 데이터의 일관성을 유지하는 것이 문제가 될 수 있다.

인터럽트

초기 컴퓨터는 주변장치가 많지 않았다. 따라서 CPU가 입출력장치에서 데이터를 가져오거나 보냈는데, 이렇게 CPU가 주변장치의 상태를 주기적으로 확인하며 처리하는 방식을 폴링(Polling) 방식이라고 한다.

오늘날 주변장치가 많아지면서 CPU가 모든 입출력에 관여하면 작업 효율이 떨어진다. 이러한 문제를 해결하기 위해 등장한 것이 인터럽트 방식이다.

인터럽트 방식은 CPU의 작업과 저장장치의 데이터 이동을 독립적으로 운영함으로써 시스템의 효율을 높인다. 즉 데이터의 입출력이 이루어지는 동안 CPU가 다른 작업을 할 수 있다.

인터럽트 방식의 동작 과정을 살펴보자.

CPU가 IO 컨트롤러에게 입출력 명령을 보낸다.
IO 컨트롤러는 명령받은 데이터를 메모리에 가져다 놓거나 메모리에 있는 데이터를 저장장치로 옮긴다.
데이터 전송이 완료되면 IO 컨트롤러는 CPU에게 완료 신호를 보낸다.
CPU는 현재 작업을 중단하고, 데이터를 처리한다. 여기서 CPU에 전달되는 완료 신호를 인터럽트라고 한다. 인터럽트가 전달되면, CPU는 하던 일을 중단하고 옮겨진 데이터를 처리한다. 이처럼 하던 작업을 중단하고 처리해야 하는 신호라는 의미에서 인터럽트라는 이름이 붙은 것이다.

DMA(Direct Memory Access)

인터럽트 방식으로 작업을 수행하기 위해선 IO 컨트롤러가 CPU의 허락 없이 메모리에 접근할 수 있는 권한이 필요하다. 이것을 직접 메모리 접근(DMA)라고 한다.

MMIO(Memory Mapped I/O)

DMA 방식은 인터럽트 방식의 시스템을 구성하는 필수 요소다. 하지만 IO 컨트롤러가 메모리를 직접 사용하게 되면 메모리가 복잡해진다. 따라서 CPU가 사용하는 메모리 공간과 DMA를 통해 들어오고 나가는 데이터를 분리하는 것이 필요하다. 이렇게 메모리의 일정 공간을 입출력에 할당하는 기법을 MMIO라고 한다.

사이클 훔치기

만약 CPU와 DMA가 동시에 메모리에 접근할 한다면 어떤 일이 발생할까? 이 경우엔 보통 CPU가 메모리 사용 권한을 양보한다. 그 이유는 CPU의 작업 속도가 더 빠르기 때문이다. 이렇게 DMA가 메모리에 접근하는 동안 CPU가 메모리를 사용하지 못하도록 잠시 대기하는 상황을 사이클 훔치기(Cycle Stealing)라고 한다.

멀티 프로세싱

단일 프로세서 시스템

과거에는 컴퓨터 한 대에 프로세서(CPU)가 하나 있는 시스템이었다. 이를 단일 프로세서 시스템이라고 한다. 이런 시스템에서 성능을 향상하는 방법은 CPU의 클록을 높이거나 캐시의 크기를 늘리는 것이었다. 하지만 클록을 높이면 발열 문제가 생기고, 캐시의 크기를 늘리는 것은 비용적인 한계가 있다.

멀티 프로세서 시스템

컴퓨터 성능을 높이기 위해 프로세서를 여러 개 설치하여 사용하는 시스템을 멀티 프로세서 시스템이라고 한다. 멀티 프로세서 시스템에선 프로세서마다 레지스터와 캐시를 가지며, 모든 프로세서가 시스템 버스를 통해 메인 메모리를 공유한다.

멀티코어 시스템

단일 프로세서 시스템을 멀티 프로세서 시스템으로 바꾸기 위해선 메인 보드의 설계 변경을 포함해 많은 변화가 필요하다. 그런데 기존 시스템을 유지한 채 멀티 프로세싱을 할 수 있게 하는 시스템이 있다. 바로 멀티코어 시스템이다.

멀티코어 시스템은 하나의 칩에 CPU의 핵심이 되는 코어를 여러 개 만들어 여러 작업을 동시에 처리할 수 있게 한다.

CPU 멀티스레드

하나의 코어에서 2개 이상의 명령어를 처리하는 방법도 있다. 하나의 코어가 여러 개의 스레드를 이용하게 하는 것이다. 여기서 스레드란 CPU가 처리할 수 있는 작업의 단위를 말한다. 이렇게 여러 스레드를 동시에 처리하는 방법을 CPU 멀티스레드라고 한다.

프로세서 vs 코어

구분	프로세서(Processor)	코어(Core)
개념	작업을 처리하는 CPU 전체 장치.	프로세서 내부에서 작업을 처리하는 독립적인 명령어 처리 단위.
구성	코어, 캐시, 메모리 컨트롤러, 버스 인터페이스 등으로 구성.	명령어 처리 유닛(CU, ALU)로 구성.
주요 역할	컴퓨터의 전체 작업 관리 및 처리.	병렬 처리 및 작업 분산.
병렬 처리 능력	코어 수에 따라 병렬 처리 능력이 결정.	각 코어가 독립적으로 병렬 작업 수행.
예시	Intel Core i7 프로세서(다중 코어 포함).	6코어, 8코어 등 단일 프로세서 내 여러 코어.

각 시스템 비교

개념	CPU/코어 수	예시 상황
단일 프로세서 시스템	CPU 1개	한 사람이 계산기를 하나 사용하여 계산
멀티 프로세서 시스템	CPU 여러 개	두 사람이 각각 계산기를 사용해 계산
멀티 코어 시스템	코어 여러 개	한 사람이 손에 여러 계산기를 들고 계산
멀티 스레드	스레드 여러 개	한 계산기에서 덧셈과 곱셈을 동시에 처리

운영체제 개요

Sat, 21 Dec 2024 00:00:00 GMT

운영체제란?

운영체제란 컴퓨터 자원을 효율적으로 관리하는 소프트웨어를 말한다. 사용자나 응용 프로그램들은 운영체제를 통해서만 컴퓨터 자원에 접근할 수 있다.

📌 역할

운영 체제의 주요 역할은 다음과 같다.

✅ 자원 관리
운영체제는 컴퓨터의 여러 자원들을 응용 프로그램에 나눠줌으로써 사용자가 원활하게 작업할 수 있도록 돕는다. 만약 자원을 요청한 프로그램이 여러 개라면 적당한 순서로 자원을 배분하고 적절한 시점에 자원을 회수해 다른 응용 프로그램에 나눠준다.

✅ 자원 보호
운영체제는 악의적인 사용자나 미숙한 사용자로부터 자원을 보호하는 역할도 한다. 특정 응용 프로그램이 다른 응용 프로그램의 영역을 침범할 수 없도록 한다.

✅ 하드웨어 인터페이스 제공
운영체제는 CPU, 메모리, 키보드, 마우스와 같은 다양한 하드웨어를 일관된 방법으로 사용할 수 있는 인터페이스를 제공한다. 덕분에 어떤 회사에서 만든 하드웨어인지 신경 쓸 필요가 없다.

✅ 사용자 인터페이스 제공
운영체제는 사용자가 운영체제를 편리하게 사용할 수 있도록 사용자 인터페이스를 지원한다.
ex) CLI, GUI

운영체제의 구성

📌 커널과 인터페이스

운영체제는 커널과 인터페이스로 구성되어 있다. 커널은 운영체제의 핵심 기능을 구현한 프로그램이고, 인터페이스는 사용자와 응용 프로그램에 인접해 커널에 명령을 전달하고 결과를 반환한다.

운영체제 관점에서 본 컴퓨터 구조는 다음과 같다. 인터페이스를 통해 커널에 명령을 내리면 인터페이스가 그 결과를 전달해 주는 것이다.

그림에서 볼 수 있듯 커널은 인터페이스와 분리되어 있다. 따라서 같은 커널이라도 다른 인터페이스가 장착되면 사용자에겐는 다른 운영체제처럼 보인다. 대표적인 예시로 mac OS는 유닉스 계열 커널을 사용하면서도 직관적이고 미려한 GUI(인터페이스)를 사용해 많은 사람들이 이용하고 있다.

📌 시스템 호출(System Call)

System Call은 커널과 응용 프로그램 간의 인터페이스다. 응용 프로그램은 System Call을 통해 하드웨어 자원이나 운영체제의 서비스를 요청할 수 있다.

✅ 역할

운영체제와 응용 프로그램 간의 통신 : 사용자 프로그램은 직접 하드웨어에 접근할 수 없으므로, 커널을 통해 간접적으로 하드웨어 자원을 제어하거나 데이터를 처리한다.
보안과 안정성 보장: 시스템 호출은 커널 모드에서 실행되므로, 자원 접근을 제어하여 보안을 유지하고, 프로그램 간 간섭을 방지한다.
운영체제 기능 제공: 파일 읽기/쓰기, 프로세스 생성/종료, 메모리 할당 등과 같은 기능을 애플리케이션이 사용할 수 있도록 지원한다.

✅ 주로 사용하는 System Call
🔹 프로세스 관리

fork(): 새로운 프로세스 생성
- 현재 실행 중인 프로세스를 복제해 자식 프로세스 생성
exec(): 새로운 프로그램 실행
- 현재 프로세스를 새로운 프로그램으로 변경
wait(): 자식 프로세스 종료 대기
- 부모 프로세스가 자식 프로세스가 종료될 때까지 대기
_exit(): 프로세스 종료
- 프로세스를 강제 종료

🔹 파일 관리

open(): 파일 열기
read(): 파일 읽기
write(): 파일 쓰기
close(): 파일 닫기

🔹 네트워크 관리

socket(): 소켓 생성
connect(): 서버에 연결

✅ 운영체제의 Dual Mode

🔹 사용자 모드

일반 애플리케이션 프로그램이 실행되는 모드
운영체제의 핵심 기능이나 하드웨어에 직접 접근할 수 없음
제한된 명령어만 실행 가능
보호된 영역(메모리, 하드웨어 등)에 접근할 수 없음

🔹 커널 모드

운영체제가 실행되는 모드
모든 하드웨어 자원(CPU, 메모리, 디스크 등)에 접근 가능
모든 명령어 실행 가능
프로세스 및 메모리 관리를 포함한 작업 수행

🔹 필요성

보안 강화
안정성 유지
자원 보호
시스템 제어 및 효율적인 운영

🔹 동작 과정

사용자가 실행한 일반 프로그램이 사용자 모드에서 실행
시스템 콜 또는 인터럽트 발생
- 사용자가 파일을 열거나 새로운 프로세스를 생성하는 등의 작업을 하면 운영체제의 서비스 필요
커널 모드로 전환
요청된 작업 수행 후 사용자 모드로 복귀

응용 프로그램의 System Call 요청에 대한 흐름을 도식화하면 다음과 같다.

커널

📌 역할

✅ 프로세스 관리: 다양한 종류의 프로세스에 CPU를 배분하고 작업할 수 있는 환경을 만들어준다.

✅ 메모리 관리: 프로세스에 작업 공간을 배치하고 실제 메모리보다 큰 가상공간을 제공한다.

✅ 파일 시스템 관리: 데이터를 저장하고 접근할 수 있는 인터페이스를 제공한다.

✅ 입출력 관리: 필요한 입력과 출력 서비스를 제공한다.

✅ 프로세스 간 통신 관리: 공동 작업을 위한 각 프로세스 간 통신 환경을 지원한다.
커널의 핵심 기능은 유기적으로 얽혀 있다. 기능들을 어떻게 구현했는가에 따라 종류가 구분된다.

📌 종류

✅ 단일형 구조 커널(Monolithic)
단일형 구조 커널은 초창기 운영체제의 구조로, 커널의 핵심 기능을 구현하는 모듈이 구분 없이 하나로 구성되어 있다.

✅ 계층형 구조 커널(layered)
계층형 구조 커널은 비슷한 기능을 가진 모듈을 묶어 하나의 계층으로 만들고 계층 간의 통신을 통해 운영체제를 구현하는 방식이다.

✅ 마이크로 구조 커널(Micro)
커널의 크기가 계속해서 커지고 필요한 하드웨어의 용량이 늘어남에 따라 커널 소스가 방대해졌다. 이러한 문제를 해결하기 위해 마이크로 구조 커널이 나오게 됐다.

마이크로 구조 커널의 운영체제는 프로세스 관리, 메모리 관리, 프로세스 간 통신 관리 등 가장 기본적인 기능만 제공한다. 그리고 많은 부분들이 사용자 영역에 구현되어 있다. 하지만 각 모듈이 독립적으로 동작하기 때문에 하나의 모듈이 실패하더라도 전체 운영체제에 영향을 주진 않는다. 또한 커널이 이식하기 쉽고 가벼워 CPU 용량이 작은 시스템에도 적용할 수 있다.

CS Study

Fri, 20 Dec 2024 00:00:00 GMT

배경

이전엔 CS가 단지 고리타분한 이론이라고 생각했다. 하지만 프로젝트를 진행하면서 의사결정의 타당한 근거를 위해 반드시 있어야 하는 기본기라는 것을 알게 되었다.

CS 지식이 부족했기 때문에 제시할 수 있는 솔루션의 근거가 빈약했고, 각 솔루션의 장단을 비교할 때도 어려움을 겪었다. 이와 같은 전문성 부족을 조금이라도 줄이고자 CS 공부를 꾸준히 하려고 한다.

OS를 시작으로 Algorithm, DB, Network를 주변에서 추천받은 책과 여러 CS github repository를 참고해 기록하고, 비슷한 내용이 나올 때마다 복습과 업데이트를 반복하는 것이 목표다.

OS

참고한 서적

https://product.kyobobook.co.kr/detail/S000200716007

참고한 레포

https://github.com/Seogeurim/CS-study

https://github.com/VSFe/Tech-Interview

Elastic Beanstalk에 애플리케이션 배포, 자동화(CD)

Tue, 17 Dec 2024 00:00:00 GMT

이전 기록에서 ECR에 Spring Boot application 이미지 push를 자동화하는 것까지 진행했다. 이젠 이미지를 Elastic Beanstalk에 반영하는 작업을 자동화할 차례다.

먼저 Elastic Beanstalk를 실행해보자. Elastic Beanstalk는 AWS 콘솔에서 간단한 설정만으로 이전에 봤던 아래 모든 인프라 아키텍처를 구성할 수 있다.

Docker 이미지를 활용할 것이기 때문에 Elastic Beanstalk 플랫폼은 Docker를 선택한다. 다른 환경 구성은 본인에 프로젝트에 맞게 설정한 후 환경을 생성하면, 샘플 앱이 정상적으로 실행되는 것을 확인할 수 있다.

이슈

환경이 생성될 때 겪은 이슈들은 다음과 같다.

vpc 지정

Auto Scaling activity failed XX minutes ago with error: The parameter SecurityGroup is not recognized. Launching EC2 instance failed.

Auto Scaling 그룹이 인스턴스를 생성하는 과정에서 보안 그룹을 제대로 식별하지 못하는 문제가 발생했다. Stack Overflow를 참고해 VPC를 명시적으로 선택하여 문제를 바로 해결할 수 있었다. AWS의 Troubleshoot EC2 Auto Scailing 에도 위 오류가 없어서 정확한 이유는 아직 확인하지 못했다.

public ip

EC2 인스턴스를 public subnet에 생성하고, public ip를 허용해줘야 인스턴스가 Elastic Beanstalk과 연결될 수 있다.

EC2 권한

EC2가 ECR의 이미지를 pull할 수 있어야 하기 때문에 EC2의 role에 AmazonEC2ContainerRegistryReadOnly 권한을 줘야 했다.

RDS 연결

Elastic Beanstalk에서 RDS를 같은 VPC 내에 생성해주는 것은 맞지만, Spring Boot Application이 RDS와 연결되기 위해선 추가로 해줘야 하는 것들이 있다.

환경 변수

애플리케이션이 처음 실행될 때 데이터베이스 연결 정보를 설정해야 하므로 Elastic Beanstalk 환경의 구성(Configuration) 탭에서 환경 변수(Environment Variables)를 지정해야 한다. 생성된 RDS 정보를 기반으로 적절한 값을 입력한다.

jdbc:mysql://[RDS 엔드포인트]:[포트]/[데이터베이스명]

DB_URL은 위와 같은 형식으로 작성하면 되고, USERNAME과 PASSWORD는 Elastic Beanstalk 환경을 생성할 때 지정한 값을 작성하면 된다.

rds 연결 확인

EC2 인스턴스에 SSH로 접속한 뒤, RDS에 정상적으로 연결되는지 확인한다.

데이터 삽입

필요한 DB와 테이블을 생성해주고, 데이터를 추가한다.

배포 자동화

Github Actions 스크립트 추가

이제 기존 github actions 스크립트에 docker 이미지를 실행 중인 Elastic Beanstalk에 반영하는 스크립트를 추가해보자.

name: CI/CD  
  
on:  
  push:  
    branches:  
      - master  
  
env:  
  ECR_REGISTRY: ${{ secrets.AWS_ECR_REGISTRY }}  
  ECR_REPOSITORY: ${{ secrets.AWS_PROD_ECR_REPOSITORY }}  
  IMAGE_TAG: ${{ github.sha }}-${{ github.run_number }}  
jobs:  
  build-and-push:  
    runs-on: ubuntu-latest  
  
    steps:  
      - name: Checkout repository  
        uses: actions/checkout@v3  
  
      - name: Configure AWS CLI  
        uses: aws-actions/configure-aws-credentials@v2  
        with:  
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}  
          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}  
          aws-region: ap-northeast-2  
  
      - name: Log in to Amazon ECR  
        id: login-ecr  
        uses: aws-actions/amazon-ecr-login@v1  
  
      - name: Build and Push Docker Image  
        run: |  
          docker build -t $ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG .  
          docker push $ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG  
  
      - name: Get current time  
        uses: 1466587594/get-current-time@v2  
        id: current-time  
        with:  
          format: YYYYMMDD_HH-mm-ss  
          utcOffset: "+09:00"  
  
      - name: Update Dockerrun.aws.json  
        run: |  
          sed -i "s|{{ECR_REGISTRY}}|${{ env.ECR_REGISTRY }}|g" environment/prod/Dockerrun.aws.json  
          sed -i "s|{{ECR_REPOSITORY}}|${{ env.ECR_REPOSITORY }}|g" environment/prod/Dockerrun.aws.json  
          sed -i "s|{{IMAGE_TAG}}|${{ env.IMAGE_TAG }}|g" environment/prod/Dockerrun.aws.json  
  
      - name: Beanstalk Deploy  
        uses: einaregilsson/beanstalk-deploy@v22  
        with:  
          aws_access_key: ${{ secrets.AWS_ACCESS_KEY_ID }}  
          aws_secret_key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}  
          application_name: test-prod-app  
          environment_name: Test-prod-app-env  
          version_label: test-prod-${{steps.current-time.outputs.formattedTime}}  
          region: ap-northeast-2  
          deployment_package: environment/prod/Dockerrun.aws.json

Elastic Beanstalk 배포에 필요한 Dockerrun.aws.json 파일은 environment 디렉토리에 환경 별로 작성했다.

소스 코드 push

이제 변경된 소스 코드를 push하면, Elastic Beanstalk에 자동으로 반영된다. 샘플 앱에서 Spring Boot 애플리케이션이 정상적으로 배포된 것을 확인할 수 있다.

소스 코드 변경

dto를 변경해보자.

// MemberDto.java
public record MemberDto(Long id, String name) {  
  
    public static MemberDto toDto(final Member member) {  
        return new MemberDto(member.getId(), member.getName());  
    }  
}

구축한 파이프라인에 의해 변경 사항이 정상적으로 반영된 것을 확인할 수 있다.

소프트웨어마에스트로(SWM) 회고

Thu, 12 Dec 2024 00:00:00 GMT

4월부터 11월까지 소프트웨어마에스트로(이하 SWM) 활동이 끝났다. 늦었지만 기억과 각오가 더 휘발되기 전에 8개월 간 경험한 것들을 기록으로 남기려고 한다.

내가 경험한 모든 것들은 문제 해결 능력에서 시작하고 끝난다. 다양한 측면에서 내가 경험한 것들을 추상화하고 구조화하면 문제 해결 능력으로 귀결된다.

이번 SWM 기간 동안 문제를 정확히 인식하고, 해당 문제 상황에 대한 솔루션을 찾아서 논리적인 근거와 개인 혹은 팀의 핵심 가치에 기반한 최적의 결정을 할 수 있는 능력이 가장 중요하다는 것을 체감했다.

내가 경험한 것들은 크게 서비스, 개발, 협업 측면으로 나눌 수 있다.

서비스

내가 경험한 SWM 활동은 서비스의 0 to 1 과정이었다.

서비스 시작

먼저 인스타그램과 노코드 툴을 활용해 최소한의 비용으로 우리가 생각한 pain point와 솔루션이 실제 사용자들에게 유효한지 확인했다. 다행히 반응이 좋은 아이디어를 발견할 수 있었고, 우린 이 서비스에 집중하기 시작했다.

문제 해결 사이클

이후엔 같은 사이클을 계속해서 반복했다.

사용자 데이터(인터뷰, GA 등)로 사용자 데이터 수집
데이터를 종합해 가설 수립
적절한 방법으로 검증 처음 경험한 사이클이었기 때문에 경험치가 부족해 어려움을 겪었지만, 서비스에 대한 애정과 성취감이 이전 프로젝트들과 비교할 수 없이 크게 느껴졌다.

난 이전까지 개발을 위한 결과물을 만들었다. 하지만 이번엔 우리가 타겟한 사용자를 위한 실제로 쓰이는 결과물을 만들었다. 꾸준히 사용자는 증가했고, 감사하게도 많은 분들이 서비스 잘 쓰고 있다는 말씀들을 해주셨다. 돌이켜보면 이를 통해 느꼈던 애정과 성취감이 가장 큰 원동력이 되었던 것 같다.

아쉬웠던 점

팀원들 모두 위와 같은 과정이 처음이라 경험치가 부족했다. 특히 목표 KPI를 수립하는 것이 어려웠다. 현재 상황에서 어떤 목표가 적절한지에 대한 감을 잡기가 힘들었다. 목표 KPI 수립이 잘됐다면, 조금 더 뾰족한 문제 인식과 활발한 강점 활용으로 서비스를 더 성장시킬 수 있었을 것 같다는 아쉬움이 있다.

개발

개발은 가장 비싼 방법이다

수립한 가설들을 검증하는 방법 중 가장 비싼 방법이 개발이라는 것을 배웠고 이를 실제로 체감했다. 서비스를 운영하는 입장에서 한번 한번의 의사결정은 굉장히 중요하다. 한번의 잘못된 결정으로 시간과 돈이 크게 낭비될 수 있기 때문이다. 따라서 우리는 개발보다 주로 인스타그램이나 인터뷰 등 최대한 리소스를 적게 사용하는 방법으로 가설을 검증했다.

수많은 의사결정의 연속

개발을 하다보면 크고 작은 수많은 의사결정들이 요구된다. 인프라 구축부터 컨벤션 등등 많은 솔루션 중 가장 타당하며 팀의 핵심 가치에 부합하는 솔루션을 선택해야 했다. 팀원들 모두 서로 의견을 잘 들어주고 수용해준 덕분에 원활한 의사결정을 할 수 있었던 것 같다.

MSA

백엔드 팀원과 기술 스택이 달라 효율적인 분업을 위해 컨텐츠 업로드 서버와 API 서버를 분리했고, 난 주로 API 서버를 담당해 전체적인 DB 스키마와 API 설계를 맡았다. 서버를 분리한 것이 처음이었는데 책임이 분리되어 책임이 분리되어 업무를 효율적으로 나눌 수 있었고, 작업 속도가 빨랐다.

아쉬웠던 점

의사결정을 하는 과정에서 기본기가 부족하다는 것을 많이 체감했다. 때문에 선택할 수 있는 솔루션도 한정적이었고, 근거도 부족했던 것 같다.

개발 외의 태스크도 많다보니 실제로 결정에 대한 근거가 기억이 나지 않았던 적이 몇번 있었다. 간단하게 팀 블로그를 만들어 중요한 의사결정만이라도 다른 어떤 솔루션이 있었고, 결정에 대한 근거가 무엇이었는지 기록으로 남겼다면 하는 아쉬움이 있다.

MSA를 처음 경험해보는 것이다 보니 Gateway, 인증/인가 등 추가로 분리했어야 할 서버들에 대해 너무 늦게 알아버렸다. 이에 대한 추가적인 공부와 분리도 필요할 것 같다.

협업

Jira

Jira라는 협업 툴을 경험할 수 있었다. 다양한 플랫폼과 연동이 가능하고, Automation을 활용해 번거로운 작업 현황 변경 같은 반복적인 작업도 자동화할 수 있어 굉장히 편했다. 무엇보다 일을 시작하기 전 빠르게 리마인드와 분업이 가능하다는 점과 중간 중간 팀원들에게 따로 물어보지 않아도 작업 현황을 볼 수 있다는 점이 가장 편했던 것 같다.

애자일

애자일 방법론을 적용해 프로젝트를 진행했다. 위에서 언급한 문제 해결 사이클을 효율적으로 반복하기 위해 최적의 방법론인 것 같다. 비교적 짧은 호흡으로 확실한 목표를 세우니 훨씬 몰입하기 좋았던 것 같다.

아쉬웠던 점

Jira와 애자일 방법론 모두 처음 경험하는 것들이었기 때문에 미숙한 점들이 있었다. 특히 스토리 포인트 투표를 조금 더 적극적으로 도입해 작업 시간에 대해 예측하는 연습을 많이 했다면 하는 아쉬움이 있다.

느낀점

SWM 덕분에 값진 경험과 배움을 얻을 수 있었다. 위에서 기록한 내가 배운 모든 것들은 SWM에서만 얻을 수 있는 것이라고 생각한다.

우리 팀이 결성될 수 있었던 이유는 같은 방향성을 가지고 있었기 때문이다. 다들 그동안 계속 했던 것이 아닌 SWM에서만 할 수 있는 것들을 해보고 싶어했다. 우리 팀의 방향성은 고급스럽고 완성도 높은 개발을 위한 결과물이 아닌 서툴더라도 우리가 애정할 수 있고, 사용자에게 쓰이는 서비스를 개발하는 것이었다. 좋은 팀원들과 멘토님들을 만난 덕분에 위 방향성에 맞는 알찬 기간을 보낼 수 있었다.

내가 개발을 공부하기로 결심한 것은 즐기면서 일하고 싶다는 단순한 생각 때문이었다. 내가 애정하는 서비스를 위해 즐겁게 일하고 싶었다. 하지만 내 성장을 위해 프로젝트 여러 개를 병행하며 무엇 하나 애정하지 못하는 모순되는 날들을 보냈다. 이 사실도 SWM 덕분에 알 수 있었고, 개발을 더 큰 관점에서 볼 수 있게 되었다.

계획

다행히 팀원 모두 서비스를 지속하는 데 동의해 계속 운영하게 되었다. 아쉬웠던 점들을 팀원들과 공유하고 싱크를 맞추는 시간을 가져야할 것 같다. 또한 부족했던 CS 공부와 새로운 기술이나 접근 방식 등 제시할 수 있는 솔루션의 폭을 넓힐 수 있는 공부도 기록과 함께 지속적으로 할 계획이다.

그리고 이번 SWM 기간동안 논리가 빈약하다는 것과 내 생각을 정리하고 구조화하는 능력이 부족하다는 것을 느꼈다. 때문에 그동안 시간이 없다는 핑계로 미뤘던 독서와 글쓰기도 꾸준히 할 계획이다.

Spring Boot Application Image ECR에 push(CI)

Sat, 07 Dec 2024 00:00:00 GMT

이전 기록에서 Spring Boot Application을 Dockerfile을 활용해 docker iamge로 빌드했다.

이제 소스 코드가 push되면 해당 소스 코드를 image로 빌드하고, ECR에 push하는 과정을 github Actions 스크립트를 통해 자동화해보자.

image build & ECR push 자동화

ECR repository 생성

먼저 AWS 콘솔에 들어가 ECR Repository를 생성한다.

생성한 repository 정보 github secret에 등록

생성한 Repository에 Github Actions가 image를 push하기 위해선 해당 Repository의 정보를 알고 있어야 한다. 하지만 외부에 repository에 대한 정보가 공개되면 안되기 때문에 github secrets에 등록해보자.

Github Repository의 "Settings">"Secrets and variables">"Actions"에서 repository secrets를 등록해주면, 외부에 ECR repository 정보를 공개하지 않으면서 Github Actions가 그 값들을 사용할 수 있다.

ECR push 권한 부여

ECR에 image를 push하기 위해선 Github Actions에게 그에 대한 권한을 부여해야 한다. 따라서 AWS 콘솔에서 IAM에 들어가 사용자를 생성하고, 해당 사용자의 ACCESSID와 ACCESSKEY도 github repository secrets에 등록해주자.

Github Actions 스크립트 생성

name: CI/CD  
  
on:  
  push:  
    branches:  
      - master  
  
env:  
  ECR_REGISTRY: ${{ secrets.AWS_ECR_REGISTRY }}  
  ECR_REPOSITORY: ${{ secrets.AWS_PROD_ECR_REPOSITORY }}  
jobs:  
  build-and-push:  
    runs-on: ubuntu-latest  
  
    steps:  
      - name: Checkout repository  
        uses: actions/checkout@v3  
  
      - name: Configure AWS CLI  
        uses: aws-actions/configure-aws-credentials@v2  
        with:  
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}  
          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}  
          aws-region: ap-northeast-2  
  
      - name: Log in to Amazon ECR  
        id: login-ecr  
        uses: aws-actions/amazon-ecr-login@v1  
  
      - name: Build and Push Docker Image  
        env:  
          IMAGE_TAG: ${{ github.sha }}-${{ github.run_number }}  
        run: |  
          docker build -t $ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG .  
          docker push $ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG

위 스크립트는 등록된 repository secrets를 이용해 image를 ECRd에 push하는 스크립트다. 위 과정을 도식화하면, 다음과 같다. 이제 소스코드를 master branch에 push하면, 생성된 ECR repository에 이미지가 정상적으로 push 되는 것을 확인할 수 있다.

인프라 구조 설계, 간단한 API 서버 이미지 빌드

Fri, 06 Dec 2024 00:00:00 GMT

인프라 구조

계획한 구조는 다음과 같다.

architecture

code push

Git 레포지토리에 애플리케이션 코드를 푸시하는 단계로 이는 CI/CD 파이프라인의 시작점이다.

push image

GitHub Actions이 애플리케이션 코드를 Docker 이미지로 빌드하고, Amazon ECR(AWS Elastic Container Registry)에 이미지를 푸시하는 단계다.

deploy

push된 새로운 버전의 이미지를 배포하는 단계다. 이때 업데이트는 롤링 업데이트 방식을 사용할 예정이다. 그 이유는 가장 무중단 배포 방식이기 때문이다.

현재 팀에선 비용과 시간을 최대한 가볍게 가져가는 것이 중요하기 때문에 위 CI/CD 단계는 최대한 간단하게 Github Actions를 이용할 예정이다.

간단한 API 서버 구축

Member.java

@Entity  
@NoArgsConstructor(access = lombok.AccessLevel.PROTECTED)  
@Getter  
public class Member {  
  
    @Id  
    @GeneratedValue(strategy = GenerationType.IDENTITY)  
    private Long id;  
    private String name;  
}

MemberController.java

@RestController  
@RequiredArgsConstructor  
public class MemberController {  
  
    private final MemberRepository memberRepository;  
  
    @GetMapping  
    public List<MemberDto> test() {  
        return memberRepository.findAll()  
                               .stream()  
                               .map(MemberDto::toDto)  
                               .toList();  
    }  
}

MemberDto.java

public record MemberDto(String name) {  
  
    public static MemberDto toDto(final Member member) {  
        return new MemberDto(member.getName());  
    }  
}

MemberRepository.java

public interface MemberRepository extends JpaRepository<Member, Long> {  
}

RDS 연결을 위해 다소 억지스러울 수 있는 API 서버를 구축했다. 요청을 보내면, DB에 저장된 member의 데이터를 반환하는 API를 제공한다.

이제 API 서버를 image로 빌드할 dockerfile을 작성해보자.

FROM gradle:7.6.1-jdk17 AS build  
WORKDIR /app  
COPY build.gradle settings.gradle ./  
RUN gradle dependencies --no-daemon  
COPY . /app  
RUN gradle clean build --no-daemon  
  
FROM openjdk:17-slim  
WORKDIR /app  
COPY --from=build /app/build/libs/*.jar /app/app.jar  
EXPOSE 8080  
ENTRYPOINT ["java"]  
CMD ["-jar", "app.jar"]

위처럼 멀티 스테이지 빌드를 사용하면, docker image 크기를 줄임으로써 배포 환경에서 보다 가볍고 빠르게 서버가 구동될 수 있다.

위 Dockerfile을 이용하면, 만든 spring boot application을 이미지로 빌드할 수 있다.

Elastic Beanstalk이란 무엇일까

Wed, 04 Dec 2024 00:00:00 GMT

운영 중인 서비스를 Elastic Beanstalk으로 관리하게 되어 Elastic Beanstalk를 이용해 간단한Spring boot Application을 배포하고, CI/CD를 구축하는 과정을 기록하려고 한다.

Elastic Beanstalk이란?

Elastic Beanstalk은 AWS(Amazon Web Services)에서 제공하는 PaaS(Platform as a Service) 서비스다. 이를 통해 사용자는 웹 애플리케이션 및 서비스를 쉽게 배포, 관리, 그리고 확장할 수 있다. Elastic Beanstalk은 개발자가 애플리케이션 코드에 집중할 수 있도록 인프라 설정 및 관리를 자동화해준다.

주요 특징

자동화된 인프라 관리
- Elastic Beanstalk은 애플리케이션 실행에 필요한 리소스(EC2, S3, RDS 등)를 자동으로 생성, 설정, 그리고 연결한다.
- 인프라 설정과 관리를 사용자가 직접 수행할 필요 없이 Beanstalk이 이를 처리한다.
언어와 플랫폼 지원
- 다양한 언어와 플랫폼을 지원한다. (Java, .NET, PHP, Node.js, Python, Ruby, Go 등)
- Docker 컨테이너도 지원하여 더 많은 환경에서 활용 가능하다.
빠른 배포
- 애플리케이션 패키지(코드 및 설정)를 업로드하면 Elastic Beanstalk이 자동으로 애플리케이션을 실행할 환경을 구성한다.
확장성
- 사용량에 따라 리소스를 자동으로 확장하거나 축소한다(예: EC2 Auto Scaling, Elastic Load Balancing).
- 이를 통해 애플리케이션은 안정적으로 높은 트래픽을 처리할 수 있다.
모니터링
- Amazon CloudWatch와 통합되어 애플리케이션 상태를 실시간으로 모니터링할 수 있다.
- 대시보드에서 애플리케이션 성능, 상태, 그리고 문제를 쉽게 파악할 수 있다.
사용자 제어
- Elastic Beanstalk은 완전 자동화된 서비스이지만, 필요 시 세부 설정을 사용자 지정할 수 있다.
- EC2 인스턴스의 유형, 데이터베이스 설정, 네트워킹 등을 직접 설정 가능하다.

Elastic Beanstalk의 구조

애플리케이션(Application)
- 사용자가 배포하려는 전체 프로젝트다.
환경(Environment)
- 애플리케이션이 실행되는 실행 환경이다.
- Load Balancer가 있는 프로덕션 환경 또는 단일 EC2 인스턴스 환경을 설정할 수 있다.
애플리케이션 버전(Application Version)
- Elastic Beanstalk에서 관리하는 특정 애플리케이션 배포 패키지다.
환경 구성(Environment Configuration)
- Elastic Beanstalk 환경의 설정 세부사항이다(인스턴스 유형, 데이터베이스, 네트워킹 등).

사용 사례

웹 애플리케이션 배포
- 블로그, 전자 상거래 웹사이트 등 다양한 웹 애플리케이션을 빠르게 배포 및 확장 가능.
백엔드 API
- 모바일 앱 또는 웹 애플리케이션의 백엔드 서비스로 사용.
실험 및 프로토타이핑
- 새로운 기능을 빠르게 배포하고 테스트할 수 있는 환경 제공.
자동 확장 요구가 있는 애플리케이션
- 애플리케이션의 트래픽 증가에 따라 동적으로 확장이 필요한 경우 적합.

장단점

장점

간편성: 코드만 업로드하면 실행 환경이 자동으로 구성.
확장성: Auto Scaling과 Load Balancing이 내장되어 트래픽 증가를 처리 가능.
통합: AWS 서비스(S3, RDS, CloudWatch 등)와 원활히 연동.
유연성: 자동화된 설정을 기본으로 하되, 필요 시 사용자 정의 가능.

단점

복잡한 커스터마이징에 비적합: 자동화된 기능은 세부적인 사용자 설정에는 제한이 있을 수 있음.
학습 필요: Elastic Beanstalk의 자동화 및 설정 방식을 이해해야 최적의 활용이 가능.

Elastic Beanstalk는 사용하는 리소스 외 비용이 필요하지 않기 때문에 빠르게 애플리케이션을 배포하고 관리하고자 하는 사용자에게 특히 유용한 서비스다.

docker volume

Sat, 30 Nov 2024 00:00:00 GMT

배경

컨테이너는 기본적으로 상태가 없다. 이러한 특성 덕분에 쉽게 scale out이 가능하며, 다른 환경에서도 빠르게 배포할 수 있다.

하지만 이 때문에 다음과 같은 문제가 생길 수 있다.

컨테이너의 휘발성: 컨테이너가 삭제되면 내부 데이터도 함께 삭제된다. 이는 데이터 지속성이 필요한 애플리케이션에는 부적합하다.
데이터 관리의 필요성: 데이터베이스나 로그 파일처럼 지속적인 데이터 저장이 필요한 경우가 있을 수 있다.

Docker는 컨테이너가 호스트 머신에 파일을 저장하고 컨테이너가 중지된 후에도 파일이 유지될 수 있도록 스토리지 기능을 제공한다.

스토리지 기능

Docker의 스토리지 기능은 3가지가 있다.

볼륨
Bind Mount
tmpfs 마운트 위 스토리지 기능들은 호스트에서 데이터의 위치에 따라 구분된다.

docker storage
볼륨은 Docker에서 관리하는 호스트 파일 시스템의 일부에 저장된다. 따라서 Docker가 아닌 프로세스는 이 부분을 수정하기 힘들다.
바인드 마운트는 호스트 시스템의 어디에나 저장될 수 있다.
tmpfs 마운트는 호스트 시스템의 메모리에만 저장된다.

이번 기록에선 Docker의 가장 일반적이고 많이 쓰이는 볼륨에 대해 다루고자 한다.

Docker volume이란?

볼륨은 Docker에 의해 생성되고 관리된다. 볼륨을 생성하면 Docker 호스트의 디렉토리에 저장된다. 이 볼륨을 컨테이너와 연결하면, 컨테이너와 볼륨의 데이터가 연결된다.

Docker Volume은 컨테이너의 데이터를 지속적으로 저장하기 위한 Docker에서 제공하는 스토리지 메커니즘이다. 컨테이너가 삭제되거나 재배포되더라도 데이터를 유지할 수 있도록 설계되었다.

마운트

Docker에서 마운트는 컨테이너가 외부의 파일 시스템(Volume 또는 Host 디렉토리)을 내부의 파일 시스템에 연결하여 사용할 수 있도록 설정하는 작업을 말한다.

위 과정을 통해 컨테이너가 중지된 이후에도 데이터를 지속적으로 제공할 수 있으며, 여러 컨테이너가 데이터를 공유할 수 있다.

실습

mySQL 컨테이너로 Docker Volume을 이용하면, 컨테이너가 중지된 이후에도 데이터가 유지될 수 있다는 것을 확인해보자.

준비

docker volume 생성
```
docker volume create my-volume
```

첫 번째 컨테이너 생성

docker run -d \
--name mysql-container-1 \
-e MYSQL_ROOT_PASSWORD=rootpassword \
-e MYSQL_DATABASE=testdb \
-v my-volume:/var/lib/mysql \
mysql:latest

첫 번째 컨테이너에서 데이터 생성
```
docker exec -it mysql-container-1 mysql -uroot -prootpassword
```
생성된 첫 번째 mysql 컨테이너에 접속한다.

USE testdb;
CREATE TABLE shared_users (id INT AUTO_INCREMENT PRIMARY KEY, name VARCHAR(255), age INT);
INSERT INTO shared_users (name, age) VALUES ('Alice', 30), ('Bob', 25);
SELECT * FROM shared_users;

shared_users 테이블을 생성하고, 데이터를 삽입한다.

첫 번째 컨테이너 삭제
```
docker rm -f mysql-container-1
```

두 번째 컨테이너 실행

docker run -d \
--name mysql-container-2 \
-e MYSQL_ROOT_PASSWORD=rootpassword \
-e MYSQL_DATABASE=testdb \
-v my-volume:/var/lib/mysql \
mysql:latest

두 번째 컨테이너에서 데이터 확인
```
docker exec -it mysql-container-2 mysql -uroot -prootpassword
```
두 번째 mysql 컨테이너에 접속한다.

USE testdb;
SELECT * FROM shared_users;

앞서 생성했던 shared_users의 데이터를 확인해보면 첫 번째 컨테이너는 삭제되었지만, 볼륨에 의해 정상적으로 데이터가 잘 남아 있는 것을 확인할 수 있다.

docker network

Thu, 28 Nov 2024 00:00:00 GMT

개요

도커의 가상 네트워크를 통해 내부 컨테이너의 IP를 정의하고, 컨테이너끼리의 통신과 외부에서 컨테이너로의 통신이 가능하다.

네트워크 종류

Driver	Description
bridge	기본 네트워크 드라이버
host	컨테이너와 Docker 호스트 간의 네트워크 격리를 제거
none	컨테이너를 호스트 및 다른 컨테이너와 완전히 격리
overlay	여러 Docker 데몬을 연결하는 오버레이 네트워크를 제공
ipvlan	IPv4 및 IPv6 주소 지정에 대해 완전한 제어를 제공
macvlan	컨테이너에 MAC 주소를 할당

기본 네트워크 드라이브인 bridge 네트워크를 위주로 살펴보자.

구성 요소

도커에서 bridge 네트워크를 만들면, 다음과 같은 구성 요소가 생성된다.

가상 브릿지 (Bridge): docker0라는 가상 네트워크 인터페이스를 생성한다. 이 브릿지는 호스트 시스템의 네트워크와 컨테이너 네트워크를 연결해주는 가상 스위치 역할을 한다.
서브넷과 IP 할당: 기본 bridge 네트워크는 172.17.0.0/16 서브넷을 사용한다.
iptables: 포트 포워딩, NAT 등 외부 네트워크와의 통신을 관리한다.

가상 브릿지

이 브릿지는 호스트 시스템에 존재하며, 같은 브리지 네트워크에 속한 모든 컨테이너를 연결하는 가상 스위치 역할을 한다.

따라서 같은 네트워크 내부 컨테이너들끼리 통신할 때 가상 브릿지(docker0)를 거치며, 이때 docker dns를 사용해 컨테이너 이름으로 통신이 가능하다.

iptables

도커의 iptables에는 어떤 IP에 어떤 컨테이너가 매핑되는지 규칙이 있다.

NAT

Docker는 iptables에 포함된 nat 테이블의 POSTROUTING 체인을 사용하여 컨테이너 내부 IP를 호스트의 외부 IP로 변환합니다.
이를 통해 컨테이너는 외부 네트워크와 통신할 수 있지만, 외부에서는 컨테이너의 내부 IP를 알 수 없습니다. 포트 포워딩
외부에서 특정 포트로 접근하면, Docker는 해당 요청을 iptables 규칙을 통해 지정된 컨테이너의 포트로 전달합니다.
nat 테이블의 PREROUTING 체인에서 포트 포워딩 규칙이 추가됩니다.

정리하면 컨테이너에서 외부로의 통신(아웃 바운드)은 iptables의 nat table을 통해 수행되고, 외부에서 내부로의 통신(인바운드)는 iptables에 지정된 규칙에 따라 특정 포트마다 지정된 특정 컨테이너로 전달되기 때문에 -p 옵션을 통해 포트가 지정되어야 가능하다. docker 네트워크 내부 컨테이너끼리의 통신은 스위치 역할을 하는 docker0를 통해 이뤄진다.

실습

위 내용들을 실습을 통해 확인해보자.

네트워크 생성

docker network create my-network

my-network라는 네트워크를 생성했다.

docker network inspect my-network

inspect명령을 통해 상세 조회를 해보면, 서브넷과 게이트웨이 정보 등을 볼 수 있다.

"Config": [
                {
                    "Subnet": "172.20.0.0/16",
                    "Gateway": "172.20.0.1"
                }
            ]

이제 my-network에 컨테이너들을 실행시켜보자.

docker run -d --name app1 --network my-network nginx

docker run -d --name app2 --network my-network alpine sleep 1000

nginx 컨테이너와 alpine 컨테이너를 my-network 내부에 실행시켰다. app2에서 app1으로 핑을 보내보자.

docker exec -it app2 ping app1

위에서 언급한 bridge dns 서버를 통해 app1이라는 이름으로 통신할 수 있는 것을 확인할 수 있다.

그렇다면 이번엔 app3 컨테이너를 실행시켜보자.

docker exec -it app2 ping app3

app3 컨테이너를 상세 조회해보면, 기본 bridge 네트워크에서 실행된다는 것을 알 수 있다.

docker exec -it app2 ping app3

app2에서 app3에 핑을 보내면, ping: bad address 'app3'이라는 메세지를 볼 수 있다. 이를 통해 app3와 app2가 서로 다른 네트워크에 위치해 있다는 것을 확인할 수 있다.

인바운드 통신

외부에서 해당 네트워크로 접근하기 위해선 앞서 언급한대로 포트 포워딩을 이용해야 한다.

docker run -d -p 80:80 --name app4 nginx

80포트로 접속했을 때 app4의 nginx 서버로 접근하도록 지정해준다. 이렇게 되면 해당 기기와 같은 사설망 내 다른 기기에서 app4의 nginx 서버에 접속할 수 있게 된다.

다음과 같이 노트북과 같은 와이파이를 공유하는 스마트폰에서 app4 nginx 서버에 접근할 수 있는 것을 확인할 수 있다.

phone

스마트폰에서 app4까지의 통신 과정을 도식화 하면 아래와 같다.

architecture

docker image

Thu, 07 Nov 2024 00:00:00 GMT

이전 글에서 봤던 이미지에 대해서 좀 더 자세하게 살펴보자.

이미지는 왜 필요할까?

소프트웨어를 실행하기 위해선 크게 하드웨어와 소프트웨어가 필요하다. 소프트웨어는 크게 3가지 구성 요소로 나뉜다.

OS: 하드웨어의 리소스를 사용할 수 있도록 해준다.
Config: 소프트웨어의 실행에 필요한 패키지, 라이브러리 그리고 런타임 언어 등
실행시킬 소프트웨어 Docker는 어떻게 위 소프트웨어의 3가지 구성 요소를 모두 가질까?

위 3가지 구성 요소를 모두 포함하는 것이 이미지이다. 이미지에는 이전에 말했듯 모든 파일, 바이너리, 라이브러리 및 구성이 포함된다.

하지만 여기서 든 의문이 있다.

분명 Docker는 Host OS를 공유한다고 했는데 이미지에 왜 OS가 포함되는가?

Docker의 이미지는 Host OS와 관계 없이 동일하게 동작해야 한다. 따라서 이미지에는 OS의 모든 구성 요소가 아닌 해당 소프트웨어를 실행시키는 데 필수적인 라이브러리와 유틸리티만을 OS로 포함하는 것이다. 특히 Host 커널을 공유하기 때문에 컨테이너 마다 추가적인 커널이 필요 없어 가벼운 용량과 빠른 실행을 유지할 수 있다.

이미지 레이어

이미지는 컨테이너를 실행시키기 위한 읽기 전용 파일이다. 이를 좀 더 공간 효율적으로 사용하기 위해 이미지는 Layered File System으로 관리된다.

왜 레이어드 구조를 사용하는가?

레이어드 구조를 사용하는 핵심적인 이유는 재사용성이다. 아래 ImageA와 ImageB를 살펴보자.

docker image

Nginx Config까지는 같지만, 그 다음 단계에서 각각 다른 파일을 추가했다. 만약, ImageA와 ImageB를 각각 하나의 큰 덩어리로 저장했다면 중복이 생겨 비효율적일 것이다.

따라서 같은 변경이 일어난 레이어를 재사용하기 위해 레이어드 구조로 파일을 관리한다. 덕분에 위 구조처럼 ImageA와 ImageB는 Nginx Config까지 같은 레이어를 공유하고 이후 단계부터 다른 이미지를 사용하는 것이다. docker [image] history 명령을 통해 해당 이미지가 어떤 레이어로 구성되었는지 알 수 있다.

다만 이미지 레이어는 순차적으로 쌓이기 때문에 같은 파일로 구성된 이미지들이라도 순서가 다르면 다른 이미지 레이어를 사용한다는 것을 주의해야 한다.

COPY ON WRITE 전략

다음 레이어가 이전 레이어를 수정하게 될 때는 해당 파일을 복사(COPY)하고 수정(WRITE)하는 식으로 동작한다.

불변성

위 COPY ON WRITE 전략 덕분에 레이어가 쌓여도 이전 레이어에는 영향을 주지 않기 때문에 각 이미지 레이어는 불변성을 유지함으로써 안전하게 공유될 수 있다.

캐싱

또한 이미지를 빌드할 때, 이전 이미지 레이어들을 캐싱해 새롭게 추가된 부분들만 빌드하고 이전 단계의 레이어는 캐싱된 레이어를 사용함으로써 빌드 시간을 단축할 수 있다.

docker image 저장

Thu, 07 Nov 2024 00:00:00 GMT

이미지 저장 방식엔 두 가지가 있다.

커밋 방식
빌드 방식

커밋 방식

커밋 방식은 다음과 같은 순서로 이루어진다.

이미지를 컨테이너로 실행
컨테이너에서의 수정
Commit으로 새로운 레이어 추가

문제점

위 커밋 방식으로 했을 때의 문제점은 다음과 같다.

이미지를 만들 때마다, 레이어를 추가할 때마다 컨테이너를 실행해야 한다.
사용자가 직접 레이어를 추가해줘야 한다.
여러 레이어를 추가하기 위해선 여러 번의 커밋이 필요하다. 위와 같은 문제로 커밋 방식을 사용하게 되면 비효율적이고, 휴먼 에러의 위험이 커진다. 위 문제점을 해결하는 이미지 저장 방식이 빌드 방식이다.

빌드 방식

빌드 방식은 컨테이너를 생성하고 커밋하는 작업을 도커가 대신 수행해준다. 이때 도커가 수행할 수 있도록 하는 파일이 바로 Dockerfile이다.

도커는 Dockerfile에 따라 임시로 컨테이너를 생성하고, 사용자가 정의한 작업을 수행한 후 커밋을 실행한다. 따라서 여러 개의 레이어도 쉽고 빠르게 추가할 수 있다.

dockerfile

지시어

Instruction	Description
FROM	베이스 이미지 지정
RUN	이미지 빌드 과정에서 실행하고, 결과를 새로운 레이어로 추가
WORKDIR	이후 RUN, CMD, ENTRYPOINT, COPY, ADD 명령에 대한 작업 폴더를 지정
COPY	원하는 파일을 레이어에 복사
CMD	컨테이너 실행 시 실행할 명령어 지정

여기서 CMD와 RUN의 차이는 뭘까? CMD는 컨테이너 실행 때만 사용되기 때문에 별도의 레이어를 추가하지 않는다. 반면 RUN은 이미지 빌드 과정에서 실행하고, 결과를 새로운 레이어로 추가한다. 따라서 RUN은 주로 환경을 설정하고 필수 파일과 패키지를 설치하는 데 사용되고, CMD는 애플리케이션을 동작시키는 등의 명령을 한다.

빌드 방식의 이미지 저장은 IaC 개념으로 dockerfile이라는 코드로 이미지를 관리하는 방식이다. 지시어를 이용해 레이어 추가 과정을 명시하고, 컨테이너 생성과 수정된 변경 사항 커밋을 dockerd에게 맡기는 것이다.

빌드 컨텍스트

빌드 컨텍스트는 빌드에서 접근할 수 있는 파일의 집합을 의미한다. 이미지 빌드 방식은 dockerd가 임시 컨테이너를 실행하고 레이어를 하나씩 추가하기 때문에 dockerfile과 빌드 컨텍스트가 반드시 제공되어야 한다. 그래야 어떤 파일들을 어떻게 수정할지 알 수 있기 때문이다.

$ docker build [OPTIONS] PATH | URL | -

멀티 스테이징 빌드

멀티 스테이징 빌드 방식은 두 개의 base image를 활용하는 방식이다.

보통 애플리케이션 소스 코드를 빌드하는 과정에서 굉장히 많은 파일들이 생성된다. 하지만 이 중 대부분의 파일이 실제 애플리케이션 실행에 사용되지 않는다. 멀티 스테이징 빌드 방식을 활용하면 위 빌드와 실행 이미지를 분리함으로써 애플리케이션 실행 이미지 크기를 줄일 수 있다.

많이 쓰이는 Spring Boot Application에 대해 생각해보자. 애플리케이션을 실행하는데 필요한 것은 jar 파일과 java runtime이지만, 소스 코드와 gradle과 같은 빌드 도구 그리고 빌드 결과물까지 너무 많은 파일들이 생성된다. 여기서 빌드 이미지와 실행 이미지를 구분하면 실행에 필요한 이미지 크기를 많이 줄일 수 있을 것이다.

spring boot multi-stage build

실제 dockerfile을 살펴보자.

FROM gradle:7.6.1-jdk11 AS build
WORKDIR /app
COPY build.gradle settings.gradle ./
RUN gradle dependencies --no-daemon
COPY . /app
RUN gradle clean build --no-daemon

FROM openjdk:11-jre-slim
WORKDIR /app
COPY --from=build /app/build/libs/*.jar /app/app.jar
EXPOSE 8080
ENTRYPOINT ["java"]
CMD ["-jar", "app.jar"]

위에서 build스테이지에서 gradle을 이용해 소스 코드를 빌드하고, 해당 결과물인 jar파일을 실행하는 이미지를 만들었다. 따라서 소스코드, 빌드 도구, 실행에 필요없는 파일들이 없어져 이미지의 크기를 줄일 수 있게 됐다.

Docker란 무엇일까

Tue, 05 Nov 2024 00:00:00 GMT

Docker는 이전 글에서 봤던 컨테이너 가상화 기술을 사용자가 손쉽게 사용할 수 있도록 해준다. 이와 같은 소프트웨어를 컨테이너 플랫폼이라고 한다.

아키텍처

도커는 클라이언트 - 서버 구조로 실행된다. 여기서 클라이언트는 사용자고, 서버는 도커 데몬(dockerd)이다.

도커 데몬

dockerd는 docker api 요청을 수신해 이미지, 컨테이너, 볼륨 등의 docker 객체를 관리한다. 하지만 사용자가 매번 docker api에 맞춰 요청을 보내는 것은 번거롭기 때문에 Docker CLI가 제공된다.

docker cli

Docker CLI는 클라이언트의 명령어에 맞게 API를 만들어 dockerd에게 전달하고, 응답으로 받은 JSON을 테이블로 변환해 클라이언트에게 보여준다.

docker architecture

구성 요소

이미지

이미지는 특정 시점의 파일 시스템을 저장한 압축 파일이다. 여기엔 모든 파일, 바이너리, 라이브러리 및 구성이 포함되며, 백업이나 스냅샷과 개념적으로 비슷하지만 크기가 훨씬 작아 인터넷으로 저장하고, 공유하기 좋다.

컨테이너

컨테이너는 실행 상태의 이미지를 말한다.

이미지와 컨테이너

둘의 관계는 프로그램과 프로세스와 관계와 매우 유사하다.

프로그램을 설치하면 디스크에 공간에 저장된다. 이를 실행하면 프로세스가 되고, 한 프로그램을 여러 개 실행할 수 있다. 이때 각 프로세스는 리소스를 사용한다.

이미지 또한 하나의 이미지에 대해 여러 컨테이너를 실행할 수 있고, 각 컨테이너는 리소스를 사용한다. 여기서 가장 큰 차이점은 격리 여부다. docker는 컨테이너 가상화를 사용하므로 각 컨테이너는 격리된 환경에서 실행된다.

가상화 기술

Mon, 04 Nov 2024 00:00:00 GMT

가상화 기술이란?

가상화 기술이란 물리적인 컴퓨터 내부에서 논리적인 여러 컴퓨팅 환경을 띄우는 것을 말한다.

왜 사용할까?

가상화 기술을 사용하는 이유를 알기 위해 가상화 기술을 사용하지 않았을 때 발생하는 문제에 대해 살펴보자.

하나의 물리적인 컴퓨터에서 여러 프로그램을 구동한다고 하면, 이 프로세스들은 호스트 머신의 리소스를 공유하게 된다. 따라서 한 프로세스의 에러가 전이될 수도 있고, 한 프로세스의 사용량 급증으로 인해 리소스를 더 많이 사용해 다른 프로세스들이 정상적으로 작동하지 않을 수도 있다.

문제점

에러 전이
사용량 급증

위와 같은 문제를 해결하기 위해 가상화 기술을 사용하는 것이다. 위 문제가 발생하는 이유는 여러 프로세스가 호스트 머신의 리소스를 공유하기 때문이다. 따라서 프로세스 별로 사용할 수 있는 리소스를 제한해 환경을 논리적으로 구분하면 위 문제를 근본적으로 해결할 수 있다.

해결

에러 전이: 격리를 통해 하나의 프로세스 에러가 다른 프로세스에 영향을 주지 못하게 한다.
사용량 급증: 각 환경의 리소스를 제한시킴으로써 다른 환경에 영향을 주지 못하게 한다.

추가로 가상화 기술은 필요에 따라 가상 환경의 크기를 조정하거나 새로운 인스턴스를 추가하는 등 효율적인 인프라 관리를 가능하게 한다.

가상화 방식

하이퍼 바이저

전통적인 가상화 방식으로 호스트 OS 위에 가상 머신을 띄워 게스트 OS를 설치하고, 해당 가상 머신에서 프로세스를 실행하는 방식이다. 이때 가상 머신은 호스트 OS와 별개의 OS를 사용한다는 것이 중요하다.

프로세스가 리소스를 사용할 때 OS의 커널에 요청을 보낸다. 이때 System Call이라는 표준을 이용하는데 OS 마다 다른 System Call을 사용한다. 그렇다면 가상 머신의 게스트 OS가 어떻게 호스트 머신의 리소스를 사용할 수 있을까? 바로 하이퍼 바이저가 이 역할을 수행한다.

하이퍼 바이저는 게스트 OS의 System Call이 정상적으로 수행될 수 있도록 가상 머신과 실제 하드웨어 사이에서 중재자 역할을 해준다.

컨테이너

컨테이너 가상화는 하이퍼 바이저 방식과 다르게 호스트 OS를 공유한다. 하이퍼 바이저 방식처럼 소프트웨어가 공간을 격리 시키는 것이 아닌 리눅스의 격리 기술을 이용해 커널이 직접 공간을 격리시킨다.

별도의 게스트 OS 설치, 부팅이 필요 없기 때문에 컨테이너 가상화는 빠르고 가볍다는 강력한 장점을 가진다. 따라서 현대 애플리케이션 운영 환경에서 더 선호된다.

하지만 호스트 OS의 커널을 공유하기 때문에 비교적 보안에 취약하다는 단점이 있다.