포스트

2024-09-10-TIL

TIL
게시 수정 작성자 August
좋아요 조회 6 분 읽는 시간
  1. docs(posts): separate the sections of every post with a thematic break +6 −0
  2. docs(til): turn the bookmark-only tils into notes (part 1) +20 −12
  3. 처음 게시

Today I Learned

NGINX vs Apache

Apache는 기존에 많이 사용되던 웹 서버 엔진이다. 예전에는 APM이라고 Apache, PHP, MySQL을 묶어서 부르기도 했고, 한 번에 설치해주는 도구도 있었다. (참고)

Apache는 process-driven 방식이며 요청 당 스레드를 생성하는 반면, NGINX는 높은 동시성을 위해 설계되었으며 싱글 스레드로 여러개의 요청을 처리하므로, 비교적 Event Driven Architecture에 적합하다.

이 차이는 두 서버의 연결 처리 모델에서 나온다. Apache는 MPM(Multi-Processing Module)에 따라 연결마다 프로세스나 스레드를 배정한다. 초기 Apache는 새 연결마다 worker 프로세스를 fork하는 비용을 줄이려고 미리 프로세스 풀을 띄워 두는 prefork 모델을 썼고, 나중에 event MPM이 추가되었다. NGINX는 master-worker 구조이고, 각 worker가 단일 스레드의 non-blocking 이벤트 루프로 여러 연결을 동시에 다룬다.

대신 NGINX는 PHP나 Python 같은 동적 콘텐츠를 스스로 처리하지 못하고 PHP-FPM 같은 외부 프로세서에 넘겨야 한다. Apache는 프로세스 안에 모듈을 올려 동적 콘텐츠를 직접 처리할 수 있고, .htaccess로 디렉터리 단위 설정을 할 수 있다는 점에서 유연하다.

NGINX for Frontend or Backend?

NGINX를 백엔드 서버로도 사용할 수 있을까?

NGINX는 백엔드 REST API 서버 자체로 사용되기보다는, 리버스 프록시, 로드 밸런서, 캐시 역할, 또는 보안 필터링을 통해 API 서버의 성능과 보안을 개선하는 데 가장 적합한 용도로 사용됩니다. powered by chatGPT

그러면 프론트 엔드 서버로 사용하는 것이 적합한가? 아니면 게이트웨이 or 리버스 프록시 역할을 하는게 더 적합한가?

NGINX는 프론트엔드 서버로도 적합하게 사용할 수 있지만, 주로 정적 파일 제공과 리버스 프록시 역할에 최적화되어 있습니다. 게이트웨이(리버스 프록시)로 사용할 때는 NGINX가 보안, 로드 밸런싱, API 요청 중계 등의 역할을 하면서 프론트엔드와 백엔드를 분리하여 관리할 수 있어, 더 복잡한 아키텍처에서 유용합니다. powered by chatGPT

NGINX를 포함한 프론트엔드와 백엔드 서버를 구성할 때 best practice를 그림으로 그려줘

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

+---------------------------+      +-----------------------------+
|     Frontend (Client)     |      |        Backend (Server)     |
+---------------------------+      +-----------------------------+
|                           |      |                             |
|  +---------------------+  |      |  +-----------------------+  |
|  |   Browser (Client)   | |      |  |   NGINX (Reverse Proxy)| |
|  +---------------------+  |      |  +-----------------------+  |
|                           |      |             |               |
|  +---------------------+  |      |             v               |
|  | NGINX (Static Files) | |      |    +-------------------+    |
|  |  (HTML, CSS, JS)     | |<--------->|   REST API Server |    |
|  +---------------------+  |      |    +-------------------+    |
|                           |      |             |               |
+---------------------------+      |             v               |
                                   |    +-------------------+    |
                                   |    |   Database Server  |   |
                                   |    +-------------------+    |
                                   |                             |
                                   +-----------------------------+

실제 설정에서는 NGINX 하나가 정적 파일을 직접 내려주고, location /api/ 같은 경로만 proxy_pass로 백엔드에 넘기는 방식이 자주 쓰인다. kronis.dev 글도 이 구성으로 프론트엔드와 백엔드를 같은 도메인 아래에 묶는 예를 보여 준다.

PlatformTransactionManager

PlatformTransactionManager는 Spring의 명령형(imperative) 트랜잭션 인프라에서 중심이 되는 인터페이스다. getTransaction(), commit(), rollback()을 정의한다. Javadoc은 애플리케이션이 이 인터페이스를 직접 쓸 수도 있지만 주된 용도는 아니고, 보통은 TransactionTemplate이나 AOP 기반 선언적 트랜잭션(@Transactional)을 통해 간접적으로 쓰게 된다고 설명한다. 구현체를 만들 때는 AbstractPlatformTransactionManager를 상속하라고 권한다.

Today I Read

프론트엔드와 백엔드 개발자 로드맵, 그리고 JPA 사용 중 예상치 못한 쿼리로 HikariCP 커넥션 문제가 생긴 사람인의 장애 회고를 읽었다.

참고한 자료외부 출처 10

외부 출처

TIL, 2024-TIL
TIL
이 글은 저작권자의 CC BY 4.0 라이선스를 따릅니다.

댓글

아직 댓글이 없습니다