기본 콘텐츠로 건너뛰기

NGINX module 개발 시 참고 하기 좋은 글


## 🙋 NGINX 모듈은 언제 만드나요?
Nginx 는 많은 웹 서비스들에서 사용하는 웹 서버 프로그램 입니다. Nginx 는 그 자체로 강력하고, 다양한 모듈을 가지고 있기 때문에 많은 서비스들에서 사용됩니다. 

하지만 서비스의 요구사항에 따라서, Nginx 그 자체만으로는 부족한 상황이 발생합니다. 앱 서버에서 처리하기에는 앱의 로직과는 동떨어져있어 책임원칙에 위반하고, nginx 의 설정 로직에서 처리되면 좋을 것 같은 요구사항들이 있습니다. 예를 들면, 프록시를 할 때 특정 값을 가공하여 넘겨주고 싶을 수 있습니다. 또, header 에 있는 값을 가지고 `$remote_addr` 를 변조하여 사용하고 싶다거나 하는 상황이 있습니다. 

그런 상황에서 적절한 처리를 할 수 있는 nginx 모듈을 직접 만들어 nginx 에 적용해줄 수 있습니다. Nginx 는 C 언어로 만들어져 있어 모듈도 보통 C 로 작성됩니다. 하지만 최근에는 [Lua](https://github.com/openresty/lua-nginx-module#readme) 로 작성하거나 [njs (nginx 에서 사용하기 위한 일종의 custom js)](https://nginx.org/en/docs/njs/) 를 사용하여 모듈이 작성되기도 합니다. 하지만 이 글에서는 C 언어로 Nginx 모듈을 작성할 때 참고하기 좋은 글들을 소개합니다. 


## Nginx 공식 문서
> https://nginx.org/en/docs/dev/development_guide.html

공식 문서는 어떤 상황에서든지 중요한 것 같습니다. 이미 만들어진 프로그램에 대해서 추가로 개발할 때는 설명서를 자세하게 살펴봐야 합니다. 

공식 문서에서는 Nginx 에서 사용되는 자료형과 구조체, 변수, 로그 방식부터 Nginx 가 HTTP 관련 요청을 처리하는 방식 등 다양한 내용들이 기록되어 있습니다. 따라서 모듈을 개발하는 경우가 아니더라도, Nginx 를 깊게 이해하고 싶다면 한번 쯤 읽고 공부해보기 좋은 문서입니다. 하지만 이 글을 읽었다고 해서 모듈 개발을 착수하기는 어렵습니다. 개발 시에 참고하기 좋은 튜토리얼이 따로 준비되어 있지는 않습니다. 처음 접하는 사람이 읽기에 다소 이해하기 어려운 용어들도 많습니다. 하지만 개발하는 도중에는 이 문서를 계속 참고하면서 코드를 이해하고 수정해나가야합니다. 


## NAVER D2 - NGINX 모듈 제작하기
> https://d2.naver.com/helloworld/192785

네이버 기술블로그에 작성된 Nginx 모듈 제작 튜토리얼 글입니다. 제가 처음 모듈을 제작해야된다고 했을 때 참고했던 좋은 글이었습니다. 

2012년에 작성되어 조금은 달라진 부분도 있겠지만, 크게 변경된 점이 없고 충분히 컴파일하는데 이슈가 없었습니다. 그리고 Nginx 에서 모듈이 구동되는 개념을 잘 설명하고 있고, 작더라도 구동할 수 있는 커스텀 모듈을 만들 수 있도록 잘 설명하고 있습니다. 모듈을 작성할 때 필요한 인터페이스, 변수와 핸들러, 모듈의 컨텍스트 등 필요한 개념에 대해서 자세한 설명과 함께 작성해볼 수 있는 코드를 제공하여 큰 도움이 되었습니다. 


## Evan Miller 의 Nginx Modules Guide
> https://www.evanmiller.org/nginx-modules-guide.html

[A/B 테스트 샘플 데이터 계산기](https://www.evanmiller.org/ab-testing/sample-size.html)로 유명한 Evan Miller 가 작성한 nginx module 가이드입니다. Nginx 모듈의 구성을 좀 더 자세하게 설명합니다. 각 항목에 대한 개념과 형태를 잘 설명하고 있어, 자주 참고하고 여러번 읽으면서 개발해나갔습니다. 특히 개발 문서에서 디테일하게 설명되지 않는 코드 동작 흐름을 잘 설명하고 있습니다. Nginx 모듈의 전체에서 부분으로 설명해 나가는 방식은 모듈을 좀 더 쉽게 이해할 수 있도록 도와주었습니다. 

## Nginx 의 내부 모듈 코드
> https://github.com/nginx/nginx/tree/master/src/http/modules

실제 모듈의 사례를 참고하는 것은 빠르게 개발하는 데 중요합니다. Nginx 코드에는 이미 많은 모듈이 개발되어 함께 컴파일됩니다. 작성된 모듈들을 참고하면 request 에 저장되어 있던 데이터를 좀 더 이해 할 수 있었고, 이해하기 어려웠던 ngx 구조체들을 사용하는 방식을 참고할 수 있었습니다. 


## 기타 다른 Nginx 모듈 레포지터리

Nginx 모듈 코드 뿐만 아니라, Nginx 써드파티 모듈들도 있어 개발 시에 참고해볼 수 있었습니다.

#### [headersmore (openresty)](https://github.com/openresty/headers-more-nginx-module)
#### [user-agent (alibaba)](https://github.com/alibaba/nginx-http-user-agent)



댓글

이 블로그의 인기 게시물

안드로이드 native c++ 컴파일 관련 정리

# 툴체인 선택 표 1. 다양한 명령 집합에 대한 APP\_ABI 설정 | 아키텍처 | 툴체인 이름 | | ---------- | ------------------------------------ | | ARM 기반 | arm-linux-androideabi-**{gcc-version}** | | x86 기반 | x86-**{gcc-version}** | | MIPS 기반 | mipsel-linux-android-**{gcc-version}** | | ARM64 기반 | aarch64-linux-android-**{gcc-version}** | | X86-64 기반 | x86\_64-**{gcc-version}** | | MIPS64 기반 | mips64el-linux-android-**{gcc-version}** | # Sysroot 선택 ``` SYSROOT=$NDK/platforms/android-21/arch-arm ``` # 컴파일러 호출 ## 간단한 호출 다음은 NDK 내에 미리 빌드 되어있는 `arm-linux-androideabi-4.8` 툴체인을 이용한 빌드 방법이다. ``` export CC="$NDK/toolchains/arm-linux-androideabi-4.8/prebuilt/ \ linux-x86/bin/arm-linux-androideabi-gcc-4.8 --sysroot=$SYSROOT" $CC -o foo.o -c foo.c ``` 이 방법에서는 C++ STL (STLport, libc++ 또는 GNU libstdc++)을 사용할 수 없습니다. 예외나 RTTI가 지원되지도 않는다. ## 고급 방법 NDK는 명령줄에서 사용자 지정 툴체인 설치를 수행할 수 있는 `make-standalone-toolchain.sh` 셸 스크립트를 제공합니다. `$NDK/build/tools/` 디렉터리에 있으며, 여기서 $NDK는 NDK의 설치 루트 디렉터리입니다. ``` $NDK/bui

정보 검색 평가 지표 ( + RAGAS)

> https://amitness.com/posts/information-retrieval-evaluation 글을 읽고 정리한 문서입니다. ## 지표의 목적 상위 N 결과가 얼마나 우수한지 어떻게 평가할 것 인가? ### Binary relevance - 문서에 대한 관련성을 `있다 / 없다` 로만 판단한다. - 현재 Ranking model 이 query 에 대해서 5개의 각각의 문서 관련도는 `[1, 0, 1, 0, 1]` 로 나타낼 수 있다. (*binary*) ## Order-unaware metrics ### Precision@k $$ Precision@k = \frac{ true\ positives@k}{(true\ positives@k) + (false\ positives@k)} $$ - 이 메트릭은 상위 K 결과의 관련 항목 수를 정량화합니다. - 추출된 k 랭크 문서 중에서 관련 있는 문서의 갯수 예시) *Precision@2* ### Recall@k $$ Recall@k = \frac{ true\ positives@k}{(true\ positives@k) + (false\ negatives@k)} $$ - 이 메트릭은 쿼리에 대한 모든 실제 관련 결과 중에서 몇 개의 실제 관련 결과가 표시되었는지 알려줍니다. - 전체 관련 있는 문서 갯수 중에서 k 랭크 내에 추출된 관련 있는 문서의 갯수 예시) *Recall@2* ### 참고: Precision 과 Recall 의 집합관계 - A = 모델에서 문서가 관련 있다고 예측한 영역 (예측) - B = 실제 관련 있는 문서가 있는 영역 (정답) - b 영역 = True Positive 로 모델이 추출한 관련 문서 중 실제 관련 있는 문서가 있었던 영역 모델이 반환한 결과 중에서 실제 관련도 있는 문서를 추출한 비율이 precision, 실제 관련 있는 문서 목록 중 model 이 올바르게 문서를 추출한 비율이 recall 이라고 할 수 있다

서버에서 Client IP 를 추출하는 여러가지 방법

서비스 요구사항에 따라 Client IP 가 필요한 상황이 있다. 보안을 위해서 Client IP 를 확인하여 접근을 허용할 수 있다. 허용되지 않은 IP 의 경우 접근을 막을 수 있다. 로그 요구사항으로 어떤 사용자가 접근하고 있는 지를 기록하기 위해 Client IP 를 남겨야 할 수 있다. 하지만 사용자나 서비스의 네트워크 구성에 따라서 Client IP 를 추출하는 것이 쉽지 않을 수 있다. 프록시가 있어 직접 연결한 Client 를 실제 사용자로 판단할 수 없는 경우가 그렇다. 프록시 뒤에 있는 사용자를 찾으려고 노력하면 Client IP 를 숨기거나 우회하기 위해서 변조를 시도하는 상황을 마주하게 된다. 그래서 Client IP 를 추출하기 위한 여러 방안들을 아래에 정리하게 되었다. 결론부터 먼저 말하면, 일반적인 상황에서 나는 `X-Forwarded-For` 의 가장 오른쪽의 Public IP 를 Client IP 로 판단하기로 했다. 믿을 수 없는 목록 중에서 신뢰할 수 있으면서 간단하고, 빠른 방법이라 생각하기 때문이다. 하지만 여러 방안들을 조사했을 때, 어떤 상황에서는 사용할 수 있는 지, 또 어떤 지점이 문제가 되는 지 생각해볼 수 있었다. 그래서 고민했었던 여러 방안들을 소개하려고 한다. ### Remote IP 프록시가 없는 간단한 구조의 서비스라면 서버에 연결된 Remote IP 를 Client IP 로 추출할 수 있다. 하지만 Remote IP 가 실제 사용자의 IP 라는 확신이 없다면, Client IP 로 사용하기 어렵다. 사용자 네트워크 구성에서 proxy 가 있다면, 서버에 연결된 Remote IP 는 실제 사용자의 Client IP 가 아닐 수 있다. 여기에서 서비스 요구사항에 대한 명확한 정의가 필요해질 수 있다. 사용자 네트워크의 사설 IP 를 추출해야 하는 지, 아니면 공인 IP 를 추출해야 하는 지 정의가 필요하다. 사설 IP 는 서비스의 입장에서 큰 의미가 없기 때문에, 보통 공인 IP