일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | |||
5 | 6 | 7 | 8 | 9 | 10 | 11 |
12 | 13 | 14 | 15 | 16 | 17 | 18 |
19 | 20 | 21 | 22 | 23 | 24 | 25 |
26 | 27 | 28 | 29 | 30 | 31 |
- JavaScript
- 모션비트
- 백준
- 리액트
- 티스토리챌린지
- 핀토스
- 소켓
- userprog
- 나만무
- defee
- 자바
- 코드트리
- pintos
- TiL
- 스택
- 자바스크립트
- 알고리즘
- 크래프톤정글
- 4기
- Java
- CSS
- corou
- 사이드프로젝트
- 크래프톤 정글
- 오블완
- 시스템콜
- HTML
- Flutter
- Vue.js
- 큐
- Today
- Total
미새문지
24.07.15 day25 IPC, CSR과 SSR 본문
IPC(Inter-Process Communication)
IPC가 무엇이고, 어떤 종류가 있는지 설명해 주세요.
IPC는 프로세스 간 통신을 의미하는데, 이는 컴퓨터 시스템 내에서 실행 중인 여러 프로세스가 서로 정보를 교환하거나 동기화하기 위해 사용하는 다양한 메커니즘을 포함한다.
주로 멀티태스킹 환경에서 필수적이며, 분산 시스템, 병렬 처리, 네트워크 통신 등 다양한 응용 분야에서 사용된다.
IPC의 주요 목적
- 데이터 공유: 프로세스 간 데이터를 교환
- 데이터 보호: 동시 접근 시 데이터의 일관성을 유지
- 동기화: 여러 프로세스 간의 작업 순서를 제어
- 원격 프로시저 호출: 다른 프로세스의 함수를 호출하여 결과를 얻는다.
IPC의 주요 종류
파이프(Pipes)
- 익명 파이프(Anonymous Pipes): 한 프로세스에서 다른 프로세스로 데이터 스트림을 전달한다. 주로 부모와 자식 프로세스 간 통신에 사용
- 이름 있는 파이프 (Named Pipes): 시스템 내의 서로 다른 프로세스 간 통신에 사용. 이름을 가지며, 네트워크를 통해서도 통신 가능.
메시지 큐(Message Queues)
- 프로세스 간에 메시지를 보내고 받을 수 있는 큐를 제공하며, 메시지는 특정 형식과 우선순위를 가질 수 있다.
공유 메모리 (Shared Memory)
- 여러 프로세스가 접근할 수 있는 메모리 영역을 공유하여 데이터를 교환한다. 가장 빠른 IPC 메커니즘 중 하나이지만, 동기화 문제를 처리해야 한다.
세마포어 (Semaphores)
- 프로세스 간의 동기화를 위한 변수이다. 주로 공유 자원의 접근을 제어하기 위해 사용되며, 카운터 방식으로 동작한다.
소켓 (Sockets)
- 네트워크를 통해 프로세스 간 데이터를 교환하는 방법이며, 로컬 및 원격 프로세스 간 통신에 모두 사용한다.
메모리 매핑 (Memory-Mapped Files)
- 파일 기반 공유 메모리 형태로 파일을 메모리에 매핑하여 파일을 통해 프로세스 간 데이터를 공유한다.
시그널 (Signals)
- 프로세스에 특정 이벤트가 발생했음을 알리는 신호이다. 주로 프로세스의 상태 변경이나 인터럽트를 알리는 데 사용된다.
RPC (Remote Procedure Call)
- 다른 프로세스의 함수를 호출하는 방식으로, 로컬 및 원격 프로세스 간에 사용된다. 대표적인 구현으로는 gRPC, JSON-RPC 등이 있다.
Shared Memory가 무엇이며, 사용할 때 유의해야 할 점에 대해 설명해 주세요.
공유 메모리 (Shared Memory)
공유메모리는 여러 프로세스가 공동으로 접근할 수 있는 메모리 영역을 제공하여, 이 영역을 통해 프로세스 간 데이터를 빠르고 효율적으로 교환할 수 있는 IPC 메커니즘이다.
공유 메모리는 데이터 교환 속도가 빠르기 때문에, 많은 양의 데이터를 짧은 시간에 주고받아야 하는 응용 프로그램에서 자주 사용된다.
특징
- 고속 데이터 교환: 메모리 기반 통신이기 때문에 데이터 전송 속도가 매우 빠르다.
- 직접 메모리 접근: 프로세스가 직접 메모리에 접근하여 읽기 및 쓰기를 수행한다.
- 적은 오버헤드: 추가적인 데이터 복사나 컨텍스트 스위칭이 적어 시스템 오버헤드가 낮다.
사용 방법
공유 메모리는 운영체제에서 제공하는 API를 통해 사용된다. 예를 들어, 유닉스 계열 시스템에서는 shmget, shmat, shmdt, shmctl 등의 시스템 호출을 사용한다.
- shmget: 공유 메모리 세그먼트를 생성하거나 접근한다.
- shmat: 공유 메모리 세그먼트를 현재 프로세스의 주소 공간에 부착한다.
- shmdt: 공유 메모리 세그먼트를 현재 프로세스의 주소 공간에서 분리한다.
- shmctl: 공유 메모리 세그먼트의 제어 작업(예: 삭제, 정보 조회)을 수행한다.
유의해야 할 점
- 동기화 문제
- 여러 프로세스가 동시에 공유 메모리에 접근할 수 있기 때문에, 데이터의 일관성을 유지하기 위해 동기화 메커니즘이 필요한다.
- 이를 위해 세마포어나 뮤텍스와 같은 동기화 도구를 사용하여 접근을 제어해야 한다.
- 데드락(Deadlock)
- 동기화 과정에서 데드락이 발생할 수 있기 때문에 이를 방지하기 위한 데드락 회피 및 예방 전략을 설계해야 한다.
- 메모리 관리
- 공유 메모리 세그먼트를 적절히 관리하지 않으면 메모리 누수가 발생할 수 있다.
- 프로세스가 종료될 때 공유 메모리를 해제해야 하며, 사용하지 않는 공유 메모리 세그먼트를 삭제해야 한다.
- 보안 문제
- 공유 메모리는 모든 프로세스가 접근할 수 있기 때문에, 민감한 데이터를 공유할 때 보안 문제가 발생할 수 있다.
- 이를 위해 접근 권한을 적절히 설정하여 인증된 프로세스만 공유 메모리에 접근하도록 해야 한다.
- 플랫폼 의존성
- 공유 메모리의 구현 및 사용 방식은 운영체제에 따라 다를 수 있어 코드의 이식성에 주의해야 한다.
CSR과 SSR
CSR과 SSR은 웹 애플리케이션을 렌더링하는 두 가지 주요 방법이다.
클라이언트 사이드 렌더링(Client-Side Rendering, CSR)
장점
- 사용자 인터페이스 반응성
- CSR은 사용자가 한 번 페이지를 로드하면, 이후에는 서버 요청 없이 클라이언트 측에서 대부분의 UI 업데이트가 이루어지므로 반응 속도가 빠르다.
- 부드러운 사용자 경험
- CSR은 SPA(Single Page Application)와 함께 사용되며, 페이지 전환 시 깜빡임이 없고 더 부드러운 사용자 경험을 제공한다.
- 개발 생산성
- 클라이언트 측에서 전체 애플리케이션을 제어할 수 있어 개발자들이 더 많은 자유도를 가질 수 있다.
- 캐싱
- CSR은 정적 자산(예: JavaScript, CSS)을 캐싱하여 애플리케이션 성능을 향상시킬 수 있다.
단점
- 초기 로드 시간
- 처음 페이지를 로드할 때 필요한 모든 자산을 다운로드하고 실행해야 하므로 초기 로드 시간이 길어질 수 있다.
- SEO 문제
- 검색 엔진이 자바스크립트를 제대로 실행하지 못하면 페이지 콘텐츠를 제대로 인덱싱하지 못할 수 있다.
- 초기 데이터 로드
- 초기 렌더링 시 데이터를 서버에서 가져와야 하므로, 이 과정에서 성능 저하가 발생할 수 있다.
서버 사이드 렌더링(Server-Side Rendering, SSR)
장점:
- 초기 로드 시간
- 서버에서 미리 렌더링된 HTML을 전송하므로, 클라이언트 측에서 자바스크립트를 실행하기 전에도 페이지를 볼 수 있어 초기 로드 시간이 빠르다.
- SEO 친화적
- 서버에서 렌더링된 페이지는 검색 엔진에 의해 쉽게 인덱싱될 수 있어 SEO에 유리하다.
- 데이터 초기화
- 초기 데이터가 서버에서 제공되므로, 클라이언트에서 추가적인 데이터를 가져오는 시간이 단축된다.
단점:
- 서버 부하
- 모든 요청마다 서버에서 페이지를 렌더링해야 하므로, 서버 부하가 증가할 수 있다.
- 복잡성 증가
- SSR을 구현하는 데 필요한 설정과 코드가 CSR에 비해 더 복잡할 수 있다.
- 유연성 부족
- 클라이언트에서 자유롭게 UI를 조작하는 데 제한이 있을 수 있다.
선호도
선호도는 주로 애플리케이션의 성격, 요구 사항, 그리고 개발 팀의 역량에 따라 달라진다.
- SEO가 중요한 경우
- 블로그, 뉴스 사이트, 전자상거래 사이트 등 SEO가 중요한 경우에는 SSR이 선호되는데, 검색 엔진 최적화(SEO)와 초기 로드 시간 단축이 주요 요인이기 때문이다.
- 복잡한 사용자 인터페이스
- 대시보드, 실시간 데이터 피드 등 사용자와의 상호작용이 많고 복잡한 UI를 제공해야 하는 애플리케이션의 경우에는 CSR이 더 적합한데, CSR이 반응성 높은 인터페이스와 부드러운 사용자 경험을 제공할 수 있기 때문이다.
- 혼합 접근법
- 최근에는 CSR과 SSR의 장점을 모두 취하는 혼합 접근법인 Hydration을 사용하기도 하는데, 서버에서 렌더링된 페이지를 클라이언트 측에서 재활용하여 동적인 콘텐츠로 변환하는 방식을 많이 사용한다.
- 예시로 Next.js 같은 프레임워크는 이러한 접근법을 쉽게 구현할 수 있도록 도와준다.
CSR과 SSR 중 어느 것을 선택할지는 프로젝트의 특성과 요구 사항에 따라 결정되어야 하며, 두 접근법을 함께 사용하는 추세가 많이 늘고 있다고 한다.
'개발 TIL' 카테고리의 다른 글
24.07.17 day27 메모리 연속할당, 숫자 고르기 (0) | 2024.07.17 |
---|---|
24.07.16 day26 캐시 메모리, 백준 1654번 랜선자르기 (0) | 2024.07.16 |
24.07.12 day24 남추문 스터디 회고 (0) | 2024.07.12 |
24.07.11 day23 뮤텍스와 세마포어, 데드락(Deadlock), 프로그램 컴파일 (0) | 2024.07.11 |
24.07.10 day22 스케줄링 알고리즘 학습 (0) | 2024.07.10 |