오늘 42 동료들과 이야기를 하던 중 재미있는 주제가 나왔다. "지그재그"라는 플랫폼에서 회원 정보 탭에서 내 정보가 아닌 타인의 정보가 보인 적이 있다는 것. 비슷한 사례를 살펴보니, 2023 년 ChatGPT 에서도 발생한 적이 있었다. 이 두 사례에서는 대체 어쩌다가 내 로그인 정보로 다른 사람의 정보를 볼 수 있게 된 것일까?

임베디드로 온지 꽤 되었지만 백엔드를 해본 입장에서 상당히 이해가 되지 않는 문제라서 이리저리 함께 고민을 해보았다. (웃긴건 그 자리에 백엔드는 한 명 밖에 없었다. ㅋㅋ) 먼저 문제를 다루는 기사는 다음과 같다.

문제 정리

지그재그, 개인정보 유출 논란에 이용률 절반 ‘뚝’ | 아주경제

카카오 품에 안겨 승승장구하던 패션 커머스 플랫폼 ‘지그재그’가 휘청이고 있다. 최근 개인정보 유출 논란 이후 애플리케이션(앱) 이용자 수가…

아주경제이나경

챗GPT, 타인 대화기록 노출 오류…수정 마쳐 | 연합뉴스

(서울=연합뉴스) 김계환 기자 = 대화형 인공지능(AI) ‘챗GPT’ 개발사인 오픈AI는 챗GPT에서 타인과의 대화 기록이 노출되는 오류가 발견…

연합뉴스김계환

위 두 사례로 그 증세가 비슷하다. 대략 문제를 정리해보면 다음과 같았다.

1. ​사용자의 인증이 필요하며 해당 사용자에게 속한 정보를 조회하였다.
2. 인증에 문제는 없었으며 타인의 정보가 노출되었다.
3. 매번 같은 사람의 정보가 유출된 것이 아니라, 랜덤하게 다른 사람의 정보가 유출되었다.

추론

특히 재미있는 부분은 "랜덤하게 다른 사람의 정보가 보인다"는 것이다. 인증면에서도 문제가 없었으며 백엔드에서도 정상 동작을해서 응답을 준 상황으로 보인다. 그러면 문제가 있을 법한 부분은 요정도가 있지 않을까? 하고 이야기를 했다.

1. 인증을 하고 엉뚱한 유저 정보를 반환하여 해당 값으로 데이터를 요청함
2. PK 를 바탕으로 데이터를 조회하는 경우 잘못된 DB 관리로 인한 문제.
3. DB 혹은 Cache 에 대한 비동기 요청에서 발생하는 문제.

1 번의 경우 가능성이 높진 않다고 생각했다. 높은 확률로 JWT 와 같이 비세션 방식을 통해 인증을 처리하고 있었을 것이고 (실제로 ChatGPT는 JWT 사용), 이 경우 서버 측 세션이 꼬여서 유저 정보를 잘못 반환하는 전형적인 문제는 발생하지 않는다.
다만, 그렇다고 해서 “절대 발생할 수 없다”는 것도 아니다. JWT 자체는 stateless지만, 클라이언트에서 토큰을 관리하는 방식이나, 프록시/캐시 서버의 처리, 혹은 백엔드의 context 보존 방식에 따라 예기치 않은 상태 꼬임이 발생할 여지는 있다. 그래도 이번 사례에서는 그런 식의 흐름 오류는 아니었던 것 같아서 가능성 낮게 봤다.

2 번의 경우는 PK 기반으로 데이터를 조회하면서, 여러 DB를 운영하는 구조에서 테이블을 나눠 쓰거나 마이그레이션 중 실수로 동일한 ID가 중복되어 나타나는 문제가 아니냐는 추론이었다. 예전부터 흔하게 나오는 멀티테넌시 관련 사고 중 하나이기도 하다.
그런데 이건 구조적으로 그렇게 설계했다면 진작에 테스트나 QA 과정에서 걸렸을 확률이 높고, 실제로 ID가 중복되더라도 “랜덤하게 타인의 데이터가 보인다”는 증상과는 조금 결이 다르다. 중복된 ID가 있다고 해서 매 요청마다 타인이 계속 바뀌는 식으로 유출되진 않을 가능성이 크기 때문이다. 물론 실수로 이렇게 만들 수는 있겠지만, 그게 root cause였다면 좀 더 다른 양상으로 문제가 나타났을 거라고 본다.

3 번의 경우 비동기로 DB 에 데이터를 얻는 과정에서 커넥션에 문제가 생겨 꼬인 것이 아니냐는 것. 그럴 수도 있지만 DB 와의 커넥션 요청에 대한 응답의 순서가 꼬인다는 것은 조금 이상하다. 요청에서 커넥션을 가지고 온 뒤 요청-응답의 pair 가 완성이 되어있을 것이기에 일반적으로 발생하지 않는다.

이야기를 나누다가, 기사를 통해 힌트를 얻었는데, Redis-py 라는 라이브러리와 비동기 상황에서의 문제라는 것을 알게되었다. redis 자체나 백엔드 서버 로직에서의 문제보다는 redis 와의 커넥션을 관리하거나 요청, 응답을 처리하는 과정에서 무언가 꼬인 것이다.

그러면 만약 redis 와의 연결에서 이러한 구조를 가지고 있다면 3번과 같은 케이스가 발생할 수 있다고 생각했다. Redis 와의 요청 / 응답 구조가 이렇게 되지 않을까? 싶었다. (결국 여러 요청에 대한 비동기적 응답 구조는 이렇게 되기 마련이니까)

1. Request queue 를 통해 command request
2. Response queue 를 통해 command response
3. 즉, Request / Response 가 각 queue 를 통해 이루어짐
4. 그런데 Request 에 대한 Response 유실이 발생 (못받거나 안받거나)
5. Requester 입장에서 Response 가 하나씩 밀리는 문제가 발생

NVMe 에서는 CID 를 통해 Command 에 대한 요청-응답 매칭이 가능하지만, CID 와 같이 요청에 대한 응답임을 확인할 수 있는 구조가 아닌, 늘 순차적인 처리가 보장된다면 충분히 발생할 수 있는 문제이다. 이 경우 랜덤하게 나타나는 타인의 데이터를 설명할 수 있다.

원인 리뷰

그러면 실제 문제는 무엇일까? 이 문제는 이미 취약점으로 잘 정리가 되어있었다.

ChatGPT data leak and Redis race condition vulnerability that remains unfixed

Last week’s OpenAI payment data and chat history leak involved a Race Condition vulnerability in an open source component, Redis.

2024 Sonatype BlogAx Sharma

1. connection pool 이 존재
2. 한 connection 에서 redis 쪽으로 요청(write) 이후 request 취소
3. response 가 pop 되기 이전 connection 이 망가지고, 해당 connection 자체는 살아서 반환
4. 다른 요청에서 해당 Connection 을 받으면 dequeue 시 남아있던 response 를 받으면서 순서가 꼬임.

꽤 근접한 접근을 했다. (뿌듯) 그런데 글을 읽으면서, 재밌다고 느낀 점은 Redis 의 요청 처리구조는 CID 와 같이 request / response 에 대한 pair 를 확인할 수 없다는 것이다. 이 부분이 너무 당연하다고 생각했다. 왜냐면, NVMe 에서는 CID 를 통해서 이를 보장하곤하는데 (애초에 Request 에 대한 Response 의 순서가 보장되지 않으니, 없으면 안된다.) Redis 에서는 이러한 장치가 존재하지 않았다.

Redis 구조 맛보기

왜 이렇게 처리를 하는 것일까? 이는 Redis 의 철학과 연관된다.

1. 단순화를 통해서 성능 극대화 / No Lock / Atomic / ... --> single thread
2. single thread 기반이니 sequential 한 처리
3. request / response 또한 FIFO 구조 + 상태 예측 가능.

그러니 redis 입장에서는 할 일을 해준 것이다. 그런데 문득, queue 에 대해서도 궁금함이 생겼다. 실제로 queue 는 어느 레벨에서 이루어지는 것일까? 만약 한 connection 에서 response 를 가져가지 않는다면 다른 connection 에서도 이에 대한 영향을 받는다. 그러나 상황을 살펴볼 때 connection 단위로 queue 가 유지되는 것으로 보인다.

Redis 에서의 queue 는 TCP 를 통한 socket stream 이다. 즉, connection 에서 client 는 server 와의 write buffer 에 write 하면서 요청을 하고, server 는 응답을 다시 buffer 에 써주면서 response 를 하는 구조이다. 즉, connection 이 끊기면 queue 가 날라가는 셈이다.

내부적으로 connection 또한 어떻게 처리되는지 궁금해서 찾아보니, single thread 기반이기에 epoll 과 같은 i/o multiplexing 을 통해 작동한다. epoll 을 통해 event 를 받아 i/o 요청을 처리하게 될 것이고, 각 connection 에서도 다시 순차적으로 request 에 대해 response 가 순차적으로 돌아가는 구조이다.

더 생각해볼만한 주제로는 이러한 순차적 처리 구조가 좋을 수도 있지만, 한 편으로는 processing time 이 긴 명령에 대해서는 이후의 latency 를 증가시키기에 single thread 구조에서는 다소 불리할 수도 있는 것 아닌가? 하는 것이다. 물론 atomic 하게 순차적으로 처리하도록 하는 것이 여러면에서 유리할 수는 있으나 atomic 하지 않아도 되는 명령이 들어오는 상황에서는 latency 를 늘리는 상황이 많이 연출될 수 있기 때문이다. 똑똑한 사람들이 만드니 분명 무슨 대책이 있었을 것 같은데, 나중에 한번 찾아볼만한 것 같다.

다른 곳에서는?

하나 더 생각해볼 주제라면, DB 나 다른 프로토콜은 어떻게 처리하는가? 이다. 이러한 문제는 MySQL, Postgres 와 같은 일반적인 DB 에서는 발생하지 않았다. 즉, 내부적으로 Request / Response 에 대한 pair 를 보장해주고 있다는 것이다. 이 방법에 대해 우선 찾아본 방식은 두 가지 정도로 보인다.

1. Stream / Request 에 대한 고유 식별자 제공
2. Connection 에서 한 번에 하나의 요청 처리

1 번의 경우 kafka / HTTP2 stream 에서의 방식이다. 찾아보지는 않았지만, 결국 request 에 대한 response 가 순차적이지 않은 환경이다. (Storage 의 I/O 도 마찬가지) 이러한 경우 만약 request 에 대해 Sequential 하게 처리 할 경우 느린 응답이 있는 경우 latency 가 굉장히 증가하게 될 것이므로 비효율적이다. 따라서 순차적이지 않은 응답에 대해 pair 를 만들 방법이 필요하고, 이를 고유 ID 를 활용한다.

2 번의 경우 RDBMS 에서 주로 선택하는 방식이다. 이들은 connection 에서 하나의 요청이 끝나고 난 뒤 그 다음 요청에 대해 처리하도록 한다. 물론 이들도 redis 와 달리 multi thread 를 통해 병렬적으로 처리되나 connection 단위의 격리된 context 를 통해 데이터 일관성을 보장하고자 함으로 보인다. (만약 connection 내에서 이렇게 하지 않으면 엄청나게 더 많은 장치들과 함께 우리는 배울게 더 늘어났을 것이다...)

반면, Redis 는 single-thread / sequential 처리로 작동하여 구조적으로 문제가 없으나 Client 측에서 async + connection pool 을 구현하는 과정에서 이를 처리하지 못하여 나타나는 문제가 되버린 케이스다.

마무리

상당히 재미있는 주제였다. (나는 임베디드 맨이라 잘 모르겠지만) 백엔드 엔지니어로서도 기초적인 이론에 기반해서 분석하고 배울 것이 많은 이슈인 것 같다. SSD FW 를 다루는 입장에서도 이러한 명령 처리 과정 중 failure 상황에서 발생할 수 있는 문제나 NVMe 에서의 queue 구조에 대해서도 한번 다시 생각을 해볼 수 있었다. (FW 내부에서의 명령 처리 구조에서도 고민해볼만한 재미있는 주제같다.) 덕분에 취업하고 한참 쉬던 블로그에 재미있는 글도 싣는다.

소셜 로그인을 구현하다보면 OAuth 를 자연스레 마주치게된다. 구글, 카카오, 페이스북, 네이버... 수 많은 연동을 하지만 연동 가이드를 따를 뿐 OAuth를 왜 사용하는지에 대해서는 골똘히 고민해본 적은 없었다. 이번 글에서는 OAuth 가 없던 세상부터 OAuth가 어떻게 타 서비스와의 연동을 이룰 수 있도록하는지 알아볼 것이다. 그리고 끝으로 OAuth 위에서 작동하는 OIDC 가 무엇인지, 왜 사용하는 지에 대해서 알아볼 것이다.

(글 읽기에 앞서, 대부분의 내용은 RFC 6749에 명시된 것을 적당하게 풀어서 이야기하고 있음을 밝힌다. 결국 OAuth 을 이해하기 위해서는 직접 구현과 더불어 해당 문서의 정독이 필요하다.)

타 서비스와 연동하기

OAuth 에 대해 알아보기 전에, OAuth 가 탄생하게된 배경에 대해서 알아볼 필요가 있다. 한번 "유튜브 분석기" 라는 어플리케이션을 만든다고 가정해보자. 이 어플리케이션은 다음과 같은 일을 해야한다. (여기서 타 서비스는 "유튜브 분석기" 가 된다)

• 사용자의 유튜브 기록을 조회하고 이를 분석한다.

해당 기능을 구현하기 위해서는 "사용자의 유튜브 기록"을 조회할 수 있어야한다. 그런데 OAuth 가 존재하지 않는 세상이라면 어떻게 "사용자의 유튜브 기록"을 획득할 수 있을까?

• 사용자에게 구글 이메일 / 비밀번호를 받는다.
  • 그리고 그 이메일 / 비밀번호를 서버는 저장해둔다.
• 어플리케이션에서는 해당 구글 이메일 / 비밀번호로 대신 로그인하고 정보를 구글에서 획득한다.

그렇다. 직접 구글에 들어갈 수있는 권한인 아이디와 패스워드 를 사용자는 우리 어플리케이션에 제공해야한다. 듣기만해도 사용자 그리고 서비스 운영자 모두에게 굉장히 찝찝한 일이다. 이런 방식으로 로그인을한다면 다음과 같은 문제가 발생할 수 있다.

• 사용자의 권한을 과도하게 획득한다.
  • 나쁜 마음을 먹은 서비스 운영자가 사용자의 계정으로 나쁜 짓을 할 수 있다.
• 사용자의 민감 정보 노출된다.
• 사용자는 비밀번호를 변경하는 방법 외에 해당 권한을 revoke 할 방법이 존재하지 않는다.
• 타 서비스 운영자의 경우 추가로 구글에 대한 사용자의 민감 정보를 별도로 신경써서 관리를 해야한다.

해당 방식은 매우 위험하고 서비스 운영자(구글), 타 서비스 운영자(유튜브 분석기), 사용자 모두에게 불편한 방식이다. 이러한 문제를 해결하고자 OAuth 라는 프로토콜이 등장하게 된다. 

OAuth (Open Authorization)

앞서 우리는 사용자의 자원을 제 3 서비스에게 제공하기 위해 서비스의 "로그인 민감 정보"를 제공해야했다. 이 과정에서 다양한 문제가 발생할 수 있음을 알 수 있었다. OAuth 는 바로 이런 문제를 해결하기 위해서 등장했다.

역사

OAuth 는 사실 De facto 표준(사실상 표준) 으로 기관들이 모여 "이게 표준이야" 라고 모여서 만들어진 표준은 아니며 널리 사용되여 API 접근 권한에 대한 사실상의 표준이 되었다.

2006년 트위터에서 OpenID 구현과 동시에 위 예시와 마찬가지로 Twitter, Google 과 같은 서비스에 접근하여 특정 정보를 획득하고자 하는 수요가 발생하였고, 이러한 API 에 접근하기 위한 표준이 없다는 사실에 OAuth Discussion Group 이 탄생하여 2007년 OAuth 1.0 에 대한 최종 초안이 등장하였다.

정의

OAuth 2.0 의 RFC의 요약부터 살펴보자.

• OAuth 2.0 인증 프레임워크는 Resource Owner 와 HTTP Service 간 승인 상호 작용을 조율하여 Resource Owner 를 대신하여 타사 애플리케이션(Client)이 HTTP Service 에대한 제한된 액세스 권한을 얻거나, 타사 애플리케이션이 자체적으로 액세스 권한을 얻을 수 있도록 허용한다.
  • 잘 살펴보면 "인가(Auhtorization)" 에 대해서 이야기하고 있다. "인증"이 아님을 잘 생각해두자.

OAuth 프로토콜은 결국 다음과 같은 목적을 위해서 만들어졌다고 요약해볼 수 있다.

• 타사 어플리케이션이 자원 소유자의 자원에 대해서 "제한적 접근" 을 할 수 있도록 "인가"를 제공하며, 이 과정이 "안전하게" 이루어 질 수 있도록 하는 프로토콜

그런데, 여기서 등장하는 "역할"에 관한 용어들이 우리에게 친숙한 client-server 구조와 다소 다르다. 그래서 먼저 각 역할에 대한 OAuth 에서의 재정의를 살펴보자.

Role

Resource Owner

• 최종 사용자를 일컫는다. Google 에 "자원"을 소유한 본인을 일컫기에 Resource Owner 라는 명칭이 붙는다.
• Resource Owner 는 결과적으로 Client 에게 자원에 대한 접근에 대한 권한을 위임하게 된다.

Resource Server

• 예시에서 Google 에 해당한다. Resource Owner 가 소유한 자원을 가지고있는 서버를 일컫는다.
• 해당 서버는 위임된 권한을 인증하는 토큰을 검사하고, 해당 자원에 대한 응답을 보내게 된다.

Client

• 예시에서 유튜브 분석기 에 해당한다. Resource Owner 가 소유한 자원에 대한 권한을 위임 받아, 대리로 자원에 대해 다루는 주체이다.
• 일반적으로 Resource Owner 가 특정 서비스를 활용하기 위해 접근하는 서버가 그 대상이 된다.
• Client 의 경우 confidential / public 두 종류로 나눌 수 있다.
  • confidential client 의 경우 일반적으로 자격 증명의 기밀성을 유지할 수 있는 client를 말한다. 일반적으로 web server 를 통해서 접근 권한을 획득하는 경우 이에 해당한다.
    • confidential 한 경우에는 public / private key pair 와 같이 client - authorization server 간의 인증 방법을 제공하곤한다.
  • public client 의 경우 native app / user-agent 를 끼고(브라우저 위에서) 동작하는 js app 과 같이 resource owner 가 직접 실행하여 자격 증명에 대한 기밀성을 유지할 수 없는 client 를 말한다.
• 각 종류에 따라 Grant를 받는 방식의 변화가 발생할 수 있다.
  • web server 의 경우에는 보통 authorization_code를 통한다.
  • native app / browser app 과 같은 경우에는 implict 를 사용하여 문제를 해결할 수 있다.
• + Authorization server 에서는 각 client 에 대한 식별자를 제공해야한다. 이는 Authorization server 내에서 구분되며, secret 으로 활용하는 내용은 아니다.
  • CLIENT_ID 와 같은 key 값을 제공하는데 이게 보통 여기에 해당한다.

Authorization Server

• 앞선 예시에서는 Google OAuth Server 가 해당이 된다. 해당 자원에 대한 인가 권한을 발급하기 위한 서버로 Resource Owner 으로부터 권한을 승인받고 Resource Owner 에게 Access Token 을 실제로 발급하는 주체가 된다.
  • 이후 해당 Access Token을 Resource Owner 는 Client 에게 제공하여 권한을 위임할 것이다''.

Grant

role 부분에서 잠시 Grant에 대한 내용이 있었다. Grant 는 "어떤 방식으로 인가를 받을 것인가?" 라는 것에 대한 내용이다.

1. Authorization Code Grant: 가장 보편적인 방식으로, 사용자가 Authorization Server에서 인증한 후 Authorization Code를 client 에게 전달한다
2. Implicit Grant: 주로 브라우저 기반 애플리케이션에서 사용되며, Access Token을 직접받는 간단한 방식
3. Resource Owner Password Credentials Grant: 사용자가 자신의 사용자 이름과 비밀번호를 직접 클라이언트에 입력하여 Access Token을 받는 방식
4. Client Credentials Grant: 클라이언트가 인증서와 같은 자신의 자격증명을 사용하여 Access Token을 받을 때 사용한다

Protocol Endpoint

Authorization Endpoint

Authorization endpoint 는 resource owner 와 상호작용을하고, 인가에 대한 grant 를 받기 위해서 사용한다. authorization server 는 반드시 resource owner 에 대한 증명을 해야한다.(구글 로그인을 할 때 아이디, 패스워드를 입력하는 부분) 해당 과정은 인증 과정과 관련이 되어있어 민감 정보를 다루기도 하기에 TLS 를 통해서 이루어져야한다.

• response_type
  • authorization endpoint 는 어떤 형태의 grant를 사용할 지에 대해서 명시를 해야한다. 이를 위한 부분이 required parameter 이다. 일반적으로 OAuth 소셜 로그인 과정에서는 "code" 를 사용하는데, 이는 authorization code 형태의 grant를 수행함을 나타낸다. 반면, access token 을 직접 받는 implicit grant 의 경우 "token"을 사용한다.

Redirection Endpoint

• Resource owner 와의 상호작용을 종료하고 난 후, resource owner 의 user agent 를 사용하여 client 에게 보낼 방법이 필요하다. 이 때 사용하는 endpoint 가 바로 redirection endpoint 이다.
  • 소셜 로그인 과정에서 redirect uri 를 설정하곤하는데 해당 부분이 이 부분이다.
• 이 또한 나름의 민감 정보인 authorization code 를 전달하기에 TLS 를 통한 통신을 권장하고 있다.

Token Endpoint

• Client 가 authorization code 혹은 refresh token 을 제시하고 access token 을 얻는데 사용하는 authoirzation server 단의 endpoint 이다. 이 때 POST method를 통해 요청해야한다.

OAuth 2.0 프로토콜의 흐름

RFC 6749 예시

     +--------+                               +---------------+
     |        |--(A)- Authorization Request ->|   Resource    |
     |        |                               |     Owner     |
     |        |<-(B)-- Authorization Grant ---|               |
     |        |                               +---------------+
     |        |
     |        |                               +---------------+
     |        |--(C)-- Authorization Grant -->| Authorization |
     | Client |                               |     Server    |
     |        |<-(D)----- Access Token -------|               |
     |        |                               +---------------+
     |        |
     |        |                               +---------------+
     |        |--(E)----- Access Token ------>|    Resource   |
     |        |                               |     Server    |
     |        |<-(F)--- Protected Resource ---|               |
     +--------+                               +---------------+

                     Figure 1: Abstract Protocol Flow

1. (A) Client 는 Resource Owner 에게 인증 요청을 한다. (구글로 로그인하기 버튼 클릭)
2. (B) Resource Owner 는 권한 부여 요청을 받고, 권한에 대한 허가를 내준다.
   1. 다소 실제보다 짧게 표현되는데 구글 로그인을 하고 권한(Scope)을 설정하는 부분이 이에 해당한다.
   2. (A) 과정에서 Client 는 구글 Authorization Server 로의 경로로 사용자를 보내고, (B) 과정에서 로그인 -> 인증 정보 획득 -> Authorization code을 Client 에게 전송을 말하고 있다.
3. (C) Client 는 Authorization 서버로 가서 해당 권한으로 Access Token 을 발급 받는다.
   1. Client 는 2번 과정에서 Authorization code 를 이미 획득하였고, Authorization code 를 통해 Access Token 을 발급받는 과정.
4. (D) Authorization Server 는 Authorization code 를 검증하고 권한에 대한 Access Token 을 발급한다.
   1. 여기서 받은 Access token 을 통해 앞으로 Client 는 Resource Owner 의 자원에 대해서 대리로 접근할 수 있다.
5. (E) Client 는 Access Token 을 들고 Resource Owner 에게 해당 자원에 대해서 요청을 한다.
6. (F) Resource Server 는 검증된 Access token 일 경우 해당 자원 요청에 대해서 응답한다.

• 아래 hudi.blog 에서 제공한 예시는 해당 과정을 더 자세히 표현하고 있다.

• 여기서 조금 다른 점은 DB 에 Access Token 저장 부분이다.
  • 일반적으로 어플리케이션에서 소셜 로그인을 할 경우 "회원 이메일" " 식별정보" "성별" 등을 획득하곤한다.
  • 해당 정보는 (거의) 불변성을 가지고 있다. 첫 로그인에서 access token 을 통해서 획득하고 더 이상 resource server 에 요청하지 않아도 되는 정보이기도 한다.
  • 따라서, Application 을 작성하기에 따라 달라지게 된다. 만약 유저가 "성별" "나이" "이메일" 등의 요소를 요청할 경우 Resource server 로 부터 접근하여 해당 정보를 제공할 수도 있고, Application 의 DB에 해당 정보를 미리 저장할 수도 있다.
  • 만약 Youtube Analyzer 와 같은 어플리케이션이라면 access token 의 소유는 필연적일 것이다. (계속 들고와서 보여줘야하니까..)

OIDC

OAuth 프로토콜의 경우 제한된 엑세스에 대해 인가를 수행하는 프로토콜이다. 즉, "인증"과는 다소 멀다. 소셜 로그인 과정을 떠올려보면 이를 알 수 있다.

• Authorization code 를 받아오고, 이를 바탕으로 access token 요청
• access token을 바탕으로 회원의 정보에 대한 요청

access token 만을 획득하는 과정에서 사실 "인증"의 부분은 끝난 것이나 다름없다. 그러나, 회원에 대한 필요한 정보 (email / id) 등을 획득하기 위해서 access token 을 사용하여 추가로 정보를 요청해야하는 불편함이 있었다.

이러한 문제를 해결하고자하는 것이 OIDC (OpenID Connect) 이다. 원리는 간단하다. OAuth 2.0 프로토콜 위에서 access token 을 돌려주는데, 해당 토큰을 JWT 로 구성하고 payload 에 필요한 회원의 정보를 같이 전달하는 것이다. 이를 통해 소셜 로그인과 같이 회원에 대한 인증 작업을 수행하기 위해 2번의 요청을 한 번으로 줄일 수 있다.

현재 네이버의 경우에는 OIDC 를 지원하지 않으며, 카카오의 경우에는 OIDC 를 지원하고 있다. 위에서 배운 내용을 토대로 아래 카카오에서 제시한 로그인 흐름을 보면 조금 더 이해가 잘될 것이다.

궁금할만한 정보들

Authorization code / Access code 를 나누는 이유

• Resource Owner 가 Client 에게 인가 정보를 전송하는 방법은 URI를 통한 방법밖에 없다. (Redirect URI 경로를 따라가면서 전송하기 때문)
  • 이 과정에서 바로 브라우저로 노출되는데, Access Token 은 해당 resource owner 의 자원을 요청할 수 있는 민감한 토큰이다.
  • 따라서 access token 을 받는 주체를 server로 변경한다. 이 때 단순하게 authorization code 만을 들고 가는 것이 아닌, Authentication server 와 미리 합의된 client id / secret 과 같은 정보를 함께 전송한다.
  • 그 결과, 보다 더 안전하게 resource owner 의 자원에 접근할 수 있다.

Refresh token 의 필요성

• Access token 은 stateless 하다. stateless 한 access token 이 노출되거나 탈취당할 경우 해당 access token 으로 접근하는 것을 방법이 마땅히 존재하지 않는다. (JWT 에서의 문제와 동일)
• 따라서, access token 의 expire 주기를 짧게 주고, refresh token 을 통해서 access token 만료시 빠르게 refresh token 을 통해 access token 을 갱신하는 용도로 활용한다.

Authorization vs Authentication

• 정말 단순하게 실사용 예시로 표현하면 다음과 같다.
  • Authentication (인증)
    • 로그인 / OTP
  • Authorization (인가)
    • Cookie / JWT / API Key
• Authentication (인증) 은 사용자의 신원을 확인하는 행위이다. 따라서, 이미 저장된 데이터와 비교하면서 "해당 사용자가 맞는가?"를 검증한다.
  • ID / PW 로그인
  • 2FA (OTP / Email 추가 인증 / 생체 인증 ...)
  • API 인증
    • 위 OAuth 에서 API_ID / API_SECRET 을 통해서 신원을 확인하는 작업이 있는데 인증의 과정이라고 볼 수 있음.
• Authorization (인가)은 "권한" 에 대한 이야기이다. "어떤 자원에 누가 무엇을 할 수 있는가?" 를 검증하는 행위이다.
  • JWT
• Session + Cookie
• OAuth
• OpenID
  • 위 OIDC 때문에 조금 헷갈릴 수 있다. 다만 근본적으로 생각해보면 OAuth 2.0 위에서 Authentication (인증 서버에서의 인증) + Authorization (토큰을 통한 접근) 모두 수행하는 것을 알 수 있음. (JWT 생각해보면 이해가 빠르다.)

참고 자료

OAuth 2.0 — OAuth

RFC 6749: The OAuth 2.0 Authorization Framework

The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. This specification replaces and obsoletes the OAuth 1.0 protocol described in RFC 5849. [STANDARDS-TRACK]

IETF DatatrackerDick Hardt

OAuth 2.0 개념과 동작원리

Hudi

OAuth 2.0 / Refresh token, Authorization code

평소 OAuth 2.0에서 궁금했던것들. Refresh token이 왜 필요한건지, Authorization code Grant flow에서 왜 굳이 Access token 대신 Authorization code를 중간에 거치는건지에 대한 고민 같은것들을 정리해봤다.

OAuth - Wikipedia

Wikimedia Foundation, Inc.Contributors to Wikimedia projects

비슷해보이지만 다른 두 친구를 소개합니다. Authentication vs Authorization | 아웃풋 트레이닝

내외부 관련된 서비스를 런칭하거나 기능을 추가할때 같이 논의되는 Auth에 대해 들어보셨을텐데요, 보통 Auth라고 하면 Authentication을 말하거나 Authentication + Authorization를 통칭합니다. 이렇게 구분지어 분리를 해놓은 거 보니 다른 것 같긴한데 과연 무엇이 어떻게 다를까요? 함께 알아가요.

아웃풋 트레이닝

문제 코드

// 	Web 요청
final RestTemplate restTemplate = new RestTemplate();
final String url = "<http://apis.data.go.kr/6410000/busrouteservice/getBusRouteInfoItem>";
final String serviceKey = "QIMPxKy%2B%2FltHKSomethingapikeyxg%3D%3D";
final UriComponentsBuilder builder = UriComponentsBuilder.fromHttpUrl(url)
	.queryParam("serviceKey", serviceKey)
	.queryParam("routeId", "234000031");
final String requestUri = builder.toUriString();
""
// 	OpenAPI 호출
ResponseEntity<String> response = restTemplate.getForEntity(requestUri, String.class);
System.out.println(response.getBody());

result

<OpenAPI_ServiceResponse>
	<cmmMsgHeader>
		<errMsg>SERVICE ERROR</errMsg>
		<returnAuthMsg>SERVICE_KEY_IS_NOT_REGISTERED_ERROR</returnAuthMsg>
		<returnReasonCode>30</returnReasonCode>
	</cmmMsgHeader>
</OpenAPI_ServiceResponse>

문제

정상적으로 serviceKey 를 입력했음에도, serviceKey 가 등록되지 않았다는 오류를 반환받음

분석

request URL 변환 과정에 문제가 있다고 가정하고 debug 진행

query 를 간편하게 삽입하기 위해서 UriComponentsBuilder 를 활용하였는데, % 은 unsafe character 로 URI 변환 과정에서 % 이 %25 로 변환된 모습을 볼 수 있었음

URIComponentBuilder

URIComponentBuilder 의 결과를 toUriString() 할 때를 찾아보면 다음을 호출한다.

 this.build().encode().toUriString() 

encode() 과정에서 기존의 encoded 된 key 를 다시 encode 하고 있고 % 를 다시 인코딩하여 문제가 생긴다.

Decoded Key로 변경

그러면 encoding 이전의 key로 변경하고 전달하면 해결되지 않을까

final String url = "<https://apis.data.go.kr/6410000/busrouteservice/getBusRouteInfoItem>";
final String decodedKey = "QIMPxKy+/lt~~~~~==";
final var uri = UriComponentsBuilder.fromUriString(url)
	.queryParam("serviceKey", decodedKey)
	.queryParam("routeId", "234000031")
	.toUriString();
// 	OpenAPI 호출
ResponseEntity<String> response = restTemplate.getForEntity(uri, String.class);

여전히 같은 오류를 받았으며, QIMPxKy+/lt~~~~~%3D%3D 라고 encode 된 것을 확인했다.

= 의 경우 정상적으로 encode 되어 %3D 로 인코딩되었으나, + 와 / 의 경우 인코딩되지 않은 것.

https://stackoverflow.com/questions/18138011/url-encoding-using-the-new-spring-uricomponentsbuilder

UriComponentBuilder 를 통해서는 정상적으로 Request 가 불가한 상황이다.

String 합치기

final String uri = url + "?serviceKey=" + encodedKey + "&routeId=" + routeId;

이번에는 String 에서 합치기만 했다. 그러나 여전히 Response 는 같다. (대체 왜?)

Browser 에서는 정상인 링크로 바로 보내기

final String uri = "<https://apis.data.go.kr/6410000/busrouteservice/getBusRouteInfoItem?serviceKey={KEY}&routeId=234000031>";

Browser 에서는 아무런 문제가 없는 링크로도 전송해보았다. 분명 성공해야하는데, 여전히 Response 는 같다.

답답해서 wireshark 로 까봤다.

Wireshark 에서 확인해보니 또 다시 encoding 과정을 거친 값으로 실제 리퀘스트가 갔음을 확인했다.

Debugger 에서 URI 값을 확인했을 때는 정상적으로 parameter가 넘어갔다. 그러나, 결국 실제 request 로 날라갈 때는 또 인코딩이 된 상태로 넘어간다. 즉, parameter 상에서 URLEncoded 된 URI 를 넘겨도 또 다시 RestTemplate 의 요청 과정 어디에선가 Encoding 을 한다.

범인찾기 - RestTemplate

RestTemplate 의 과정을 살펴보면 결국 URL 대상으로 요청을 execute 하는 부분이 있다. 이 부분에서 URL 로 다시 바꿔서 요청을 실행하는데 이 부분이 문제다.

불행하게도 위에서와 같은 이유로 decoded 된 key 를 넘기더라도 + 와 같은 문자열이 인코딩되지 않아 정확한 key 를 보낼 수 없다.

따라서, 해당 과정을 피하는 방법을 떠올려야한다.

해결 방안

final URI uri = URI.create(uriString);

딱 이 한 줄만 추가하면 된다...

URIComponentBuilder 부분에서 encoding 하는 문제의 경우에도 해결할 수 있다. 다음과 같이 작성해보자.

final var builder = new DefaultUriBuilderFactory();
builder.setEncodingMode(DefaultUriBuilderFactory.EncodingMode.NONE);

final String uriString = builder.builder()
    .scheme("http")
    .host("apis.data.go.kr")
    .path("/6410000/busrouteservice/getBusRouteInfoItem")
    .queryParam("serviceKey", encodedKey)
    .queryParam("routeId", routeId)
    .build()
    .toString();
final URI uri = URI.create(uriString);

사실 아래 글에서 처음에 찾긴 했는데, 어디서 문제를 발생시키는지 당최 파악이 안돼서 열심히 파봤다. 쓸 때마다 늘 염두에 둘 부분인 것 같아 글로 기록해둔다.

[졸업프로젝트]공공데이터 포털 service key is not registered error 해결 방법

공공데이터 포털의 API를 졸업프로젝트를 진행하면서 사용하게 되었는데, 이 과정에서 “service key is not registered error”를 만나게 되었다. 이 오류를 해결하기 위한 과정이 적혀있다.

Grass

약 3달 전쯤 유튜브를 보다가 우연히 발견한 코인이다. 내 네트워크 대역폭을 제공하고 그 댓가로 해당 코인을 지급해주는 개념이다. (AI 학습을 위한 데이터 획득을 위함이라나...) 때문에 컴퓨팅 파워를 무지막지하게 활용해야하는 다른 코인보다 손쉽게 채굴할 수 있다.

나름 방식도 간단할 뿐더러 아직 활성화가 되지 않아 실제로 트래픽을 잡아먹지 않았다. 채굴 보상은 대략 3 만원 / ip 정도로 잡고 있어, 홈 서버가 굴러가는데 소요되는 전기세를 손쉽게 얻어낼 수 있다고 생각이 들었다.

Grass: Earn a Stake in the AI Revolution

Grass is the easiest way to participate in the growth of AI. Join 2,000,000+ users securely monetizing their internet resources.

Grass

작동 방식

Grass 의 채굴방식은 간단하다. 그냥 Chrome extension 을 설치하고 로그인하면 터널이 형성되어 내 디바이스의 네트워크를 통해서 데이터를 획득할 수 있다.

Miner 만들기

사실 기존에 Grass miner 로 제공된 코드들이 github 에 있었다. 따로 개발하기는 귀찮아서 해당 프로그램을 사용해서 채굴을 했다. Chrome extension 을 통해서만 채굴이 가능하기 때문에 대부분의 채굴 프로그램은 다 webdriver 를 load 하고 crx 파일을 통해서 확장 프로그램을 로드하며, 접속을 확인하는 정도로 작동한다.

GitHub - kgregor98/grass: A Docker Image for getgrass.io

A Docker Image for getgrass.io. Contribute to kgregor98/grass development by creating an account on GitHub.

GitHubkgregor98

그런데 이번에 확장 프로그램의 새 버전을 출시하며 1.25x 의 보상을 주었고, 기존의 프로그램의 경우 제대로 대응이 되지 않았다. 코드를 조금 변경하면 되기는 하는데, 단순한 작업인지라 코드가 굉장히 지저분했다.

또한 이번에 모니터링을 옮기면서 Grass 가 제대로 채굴되고 있는지에 대해서도 정보를 받아와보고 싶었다. 그래서 그냥 취미겸 한번 만들어보기로 했다.

구상

Grass 의 경우 이렇게 따로 올려서 채굴하는 방식은 다 동일할 수 밖에 없다. 단순히 어떤 언어로 작성하냐의 차이 정도이다. 다만, 이번에 Prometheus 를 통한 모니터링이 가능하도록 하는 기능을 추가할 것이며, 추후에 변경사항이 있을 때 조금 더 편리하게 코드를 고치고자 깔끔하게 리팩토링하는 과정이 될 것이다.

대략 정리하면 이렇게 구성해서 프로그램을 만들 수 있다.

• Chrome webdriver 를 통해 확장 프로그램을 로드
• Selenium 을 통해서 로그인 / 정보획득 자동화
• FastAPI + Prometheus Client 를 통해서 Prometheus metric 제공

리팩토링하기

위 레포에 있는 코드의 경우, main.py 에 다 때려박은 형태이다. 코드를 변경할 수는 있었지만 너무 더러워서 수정할 때 귀찮음이 있었다. 그래서 기능적으로 모듈로 분리해보고자 했다. 위 코드를 보면 다음과 같이 움직인다.

1. 환경 변수로부터 유저 로그인 정보를 획득한다.
2. 확장 프로그램을 다운받는다.
3. Chrome webdriver 를 확장 프로그램과 함께 로드한다.
4. webdriver 를 통해서 로그인한다.
5. webdriver 를 통해서 연결 상태를 검증한다.
6. 연결 상태를 api 를 통해서 받아오기 위해 Flask 를 시작한다.

이를 각각 기능적으로 나눠서 생각해봤다.

• 환경변수를 로드하는 기능
• 확장 프로그램을 가져오는 기능
• webdriver 를 로드하는 기능
• grass 페이지 내에서 작업을 하기 위해 webdriver 를 조작하는 기능
• API

그런데, 이 중에서 확장 프로그램을 다운받는 기능은 제외했다. 굳이 URL 로 받아올 이유가 딱히 없다. 미리 local 에 받아두고 이를 그냥 바로 주입하는 편이 나았다. 결과적으로 다음과 같이 다시 나누었다.

• Config
  • 환경 변수를 가져오고 관리
• Util
  • 프로그램 내 기타 유틸리티 기능
• GrassHandler
  • webdriver 를 통해 app.getgrass.io 에서 핸들링하는 기능 집합
• Grass
  • Grass miner 를 시작 / 관리 / 데이터 획득을 위해 driver / handler 를 제공받아 작동하는 최종 인터페이스
• API
  • FastAPI 의 controller code 들을 담음

Grass 와 GrassHandler 의 경우 굳이 구분을 한 이유는 복잡성 때문이었다. 프로그램 특성상 webdriver 를 변경하거나 handler 를 변경할 이유는 잘 없기에 GrassHandler 코드와 통합되어 작성해도 별 문제는 없다. 다만, 이렇게 때려박아버리니 기존의 코드와 다를 바가 없었고 기능 구분이 되지 않았다.

그래서 Grass 는 내 프로그램 입장에서 필요한 기능들의 집합한 인터페이스 느낌으로 활용하도록 했다. GrassHandler 의 경우 webdriver 를 조작하는데만 집중하도록 했다. 이렇게 코드를 작성할 경우 webdriver 를 다른 것으로 교체하거나 webdriver 가 아닌 다른 방식으로 채굴이 가능해졌을 때 handler 만 교체해서 사용하면 된다.

Util 부분의 경우 사실 애매한 method 들의 집합이다. 시간을 변환한다거나, Chrome driver 를 획득한다거나 하는 기능이다. 좋은 코드라고는 할 수 없겠으나 따로 나눠둘 곳도 마땅하지 않아 그냥 묶어뒀다.

그대로 나름 나누고 나니 코드를 읽고 수정하는데 간편해졌다. (나만 그럴지도)

Prometheus client

Metric을 받아와서 Grafana 로 보고 싶었다. 모니터링 서버의 경우 Prometheus를 통해 메트릭을 모두 수집하고 있어, 여기서도 Prometheus 를 통해서 pull 하도록 했다. 이는 prometheus-client 라이브러리의 활용을 통해서 쉽게 해결할 수 있다.

겪었던 문제

FastAPI :코드를 작성하면서 FastAPI 를 괜히 사용했다는 것을 알게됐다. FastAPI 의 경우 asyncio 를 사용하는데, selenium 을 통해서 webdriver 를 조작하는 과정은 블로킹 될 수 밖에 없어 이점을 취하지 못했다.

또한 프로그램 로드 과정에서 main.py 에서 실행하는 로직 그대로 프로그램이 시작되는 것이 아니었다. 이 때문에 프로그램을 종료하는 과정이 복잡해졌으며, 원하는 에러 코드로 exit 할 수도 없었고, 객체를 조작함에 있어서도 좀 고생을 했다. (python에 대한 이해 부족이다...)

요리조리 해결 방안을 찾아내기는 했으나 적절하지 못했던 선택이었다. Flask 로 전환을 좀 고려해봐야겠다.

Selenium : app.getgrass.io 의 서버가 꽤 불안정하다. 로그인 요청을 했을 때 바로 요청을 받아주면 좋겠으나 그냥 무한 대기를 해버리는 경우가 빈번했다. 또한 로그인을 하더라도, 로드가 제대로 되지 않는 경우도 많았다. 이런 경우 마땅히 방법이 없어, 프로그램을 재시작하는 수 밖에 없었다.

Python : Grass 객체나 Prometheus 객체의 경우 프로그램 전반에서 인스턴스가 하나만 존재해야한다. Python 으로 코드를 제대로 작성해본적이 없어서 언제 인스턴스가 만들어지고, 코드가 실행되는지, 클래스 생성자에 대한 이해가 부족했다. 지금 해결책이라고 한 방법들이 좋은 방법은 아닐 것 같다.

Grafana Dashboard 만들기

Grafana Dashboard 의 경우 매번 있는 것을 사용했었다. 이번에 처음 만들어보는데 그렇게 어렵지는 않았다. 다음과 같은 구성으로 대시보드를 구성했다.

• 전체 노드 상태 확인
  • Summary
  • 네트워크 퀄리티 기록 (range)
  • 채굴량
  • 시간별 채굴량
• 각 노드 상태
  • 위와 거의 동일

생각한대로 잘 결과를 받아온다. grass 홈페이지에서도 이미 보여주는 정보들이라 필요한가 싶긴하다 ㅋㅋ. 그래도 Grafana 내에서 확인할 수 있으니 나름 의미는 있겠다. 노드가 많았으면 조금 더 활용도가 있었을텐데 아쉽다.

현재는 실제로 트래픽이 발생하지 않아 큰 의미는 없지만, 트래픽 모니터링은 기능에 추가하는게 어떨까싶다.

후기

재미삼아서 만들어본 프로젝트였다. 크게 뭔가 한 것은 없고 다음과 같은 것들을 가볍게 경험했다.

• 나름의 OOP 하기
• Selenium 으로 webdriver 조작
• Prometheus client 만들기
• Grafana dashboard 만들기

허접하지만, 누군가 github 에서 보고 referal 을 해서 부자가 됐으면 좋겠다. ㅋㅋ

끝~

지난 글에 이어 Oracle Cloud 로 모니터링 시스템을 옮기는 과정을 마저 진행해보겠다.

VPN 설치

• 모니터링 서버에서 내부 서비스의 경우 외부로 노출될 이유가 없다. 따라서, VPN 을 통해서만 해당 서버에 접속 할 수 있도록 한다.
• 기존에 OpenVPN 을 통해서 VPN 을 구축하고 있어, 해당 서버도 OpenVPN 을 활용하도록 할 것이다.

docker container 올리기

• Wireguard / OpenVPN 두 가지 선택지가 있다.
• 기존의 경우 라우터에서 OpenVPN 을 지원하여 OpenVPN 을 바탕으로 통신하였다. 그러나 최근 OpenVPN 보다 WireGuard 쪽으로 트렌드가 넘어간 것으로 보인다. OpenVPN 에 비해서 경량화 되어있으며 빠르고 보안적으로도 안전하다. 따라서 이번 기회에 VPN 을 wireguard 로 변경해보고자 한다.
• 이미지는 다음 이미지를 사용할 것​이다.

https://hub.docker.com/r/linuxserver/wireguard

• wireguard 의 경우 gui 를 자체 제공하지 않는다. 이를 제공하는 web ui 또한 함께 추가하자.

GitHub - ngoduykhanh/wireguard-ui: Wireguard web interface

Wireguard web interface. Contribute to ngoduykhanh/wireguard-ui development by creating an account on GitHub.

GitHubngoduykhanh

version: "3.8"
name: wireguard
services:
  wireguard:
    image: lscr.io/linuxserver/wireguard:latest
    container_name: wireguard
    cap_add:
      - NET_ADMIN
      - SYS_MODULE #optional
    environment:
      - PUID=1003
      - PGID=1003
      - TZ=Etc/UTC
      - SERVERURL=${SERVER_URL}me #optional
      - SERVERPORT=51820 #optional
      - PEERS=1 #optional
      - PEERDNS=auto #optional
      - INTERNAL_SUBNET=10.13.13.0 #optional
      - ALLOWEDIPS=0.0.0.0/0 #optional
      - PERSISTENTKEEPALIVE_PEERS= #optional
      - LOG_CONFS=true #optional
    volumes:
      - ./data/wireguard:/config
      - /lib/modules:/lib/modules #optional
    ports:
      - 5000:5000
      - 51820:51820/udp
    sysctls:
      - net.ipv4.conf.all.src_valid_mark=1
    restart: unless-stopped

  webui-wireguard:
    image: ngoduykhanh/wireguard-ui
    container_name: webui-wireguard
    cap_add:
      - NET_ADMIN
    network_mode: service:wireguard
    environment:
      - SENDGRID_API_KEY
      - EMAIL_FROM_ADDRESS
      - EMAIL_FROM_NAME
      - SESSION_SECRET
      - WGUI_USERNAME=${USER}
      - WGUI_PASSWORD=${PW}
      - WG_CONF_TEMPLATE
      - WGUI_MANAGE_START=false
      - WGUI_MANAGE_RESTART=false
    logging:
      driver: json-file
      options:
        max-size: 50m
    volumes:
      - ./data/db:/app/db
      - ./data/wireguard:/etc/wireguard

발생한 문제들

• wireguard 가 갑작스럽게 연결이 안되는 문제가 있었다. 이상하게 핸드폰에서는 연결이 되는데, mac 에서만 연결이 안됐다.
• Peer 충돌로 인한 문제였던 것으로 보인다. 동시에 여러 device 에서 접근 하는 경우에 주의좀 해야할 것 같다.
• web-ui 연결하면서도 네트워크 관련하여 문제가 발생했다.
  • webui-wireguard 와 wireguard container 가 서로 연결되어있어야한다.
  • 포트 개방을 web-ui 에서 하는 것이 아니다 (?) 왠지는 모르겠지만 그렇게 설정이 되어있더라.
  • /etc/wireguard 부분의 경우 docker container 로 올리는 경우 wireguard 의 config 볼륨과 같아야한다.
• DNS 문제가 종종 생길 수도 있다. 내 라우터의 경우 pi-hole DNS 와 연결되어있는데 딱히 문제가 발생하지는 않았다. 다만 문제가 발생한다는 보고가 몇 개 있다.

NPM Proxy

• VPN 으로 접속하여 내부 망 경로로 접속을 해도 된다. 하지만, 그냥 NPM 자체 기능을 통해 source ip 를 제한할 수 있다. NPM 에서 access list 를 설정하고, 이를 해당하는 도메인으로 지정했다.

• VPN 을 통하지 않은 경로의 경우 403 이 나오며 접속이 불가해졌다.

Home server 모니터링

Network

• VPN 을 통해서 두 네트워크를 잇는 방법을 처음에 고려했다.
  • 다음과 같이 생각해보았다.
    • Home server 의 docker container 로 wireguard 올리기
    • Oracle VM 과 wireguard 로 연결
    • container 간 VPN 통신으로 정보를 전달한다.
  • 그러나 해당 방식으로 구현할 경우 다음과 같은 문제가 발생한다.
    • pve-exporter 의 경우 pve node 로부터 정보를 받아오는데, 이는 home network 에서만 들고 올 수 있다.
    • 그러나 해당 컨테이너를 Oracle 쪽의 VPN 과 묶으면 home network 쪽으로 접근할 수가 없다.
• 따라서, 앞서 NPM 을 통해 접근 제어를 한 방식으로 접근해보려고 한다.
  • 맘에는 안들지만... 현재 찾아본 바로는 별 수가 없는 것 같다.
• pve-exporter 에서 전달해주는 metric 을 외부로 개방하되, access list 를 통해서 oracle vm 측에서만 들고 올 수 있도록 설정했다.

pve-exporter

• proxmox node 의 경우 pve-exporter 를 통해서 prometheus 로 metric 을 보낼 수 있다.

Monitor Proxmox VE With Prometheus And Grafana

In the video below, we show how to monitor Proxmox VE with Prometheus and Grafana

Tech Tutorials

• 위 게시물에서 아주 친절하게 설명해둬서 그것을 그대로 따라갔다.

• 이제 proxmox 노드 상태도 이 곳에서 관찰 할 수 있다.

cAdvisor

• 이왕 모니터링 하는 겸, 컨테이너들의 상태도 모니터링하고자한다.
• cAdvisor 는 컨테이너 모니터링에 특화된 툴이다. 마찬가지로 docker container 를 통해서 올릴 수 있다.

  cadvisor:
    image: gcr.io/cadvisor/cadvisor
    container_name: cadvisor
    ports:
      - 8080:8080
    volumes:
      - /:/rootfs:ro
      - /var/run:/var/run:rw
      - /sys:/sys:ro
      - /var/lib/docker/:/var/lib/docker:ro
      - /dev/disk/:/dev/disk:ro

• metric 을 prometheus 에서 수집할 수 있도록 추가해준다.

 - job_name: cadvisor
    scrape_interval: 15s
    static_configs:
      - targets:
        - cadvisor:8080

• grafana dashboard 또한 추가하면 이렇게 컨테이터네 대한 정보를 수집할 수 있다.

• 각 서버마다 cAdvisor 를 설치해주었고, metric을 수집하도록하였다.
• Synology 의 경우 문제가 발생했었다. volume 연결에서의 문제인데, linux 환경과 다르기 때문이었다.

Issues with cadvisor on Synology NAS · Issue #1846 · google/cadvisor

I am having issues running cadvisor on my Synology NAS. If ran on docker, I get this: I1227 04:16:53.543073 1 storagedriver.go:50] Caching stats in memory for 2m0s I1227 04:16:53.543643 1 manager.g…

GitHubgoogle

• CPU 사용량이 다른 컨테이너에 비해 눈에 띄게 높았다. 나만 그런 상황은 아니었고, 다른 사람들도 비슷하게 겪고 있는 문제였다. 아래 이슈에서 제안해준대로 housekeeping_interval=15s 으로 15%-> 2% 로 줄일 수 있었다.

(Relatively) high CPU usage for the cadvisor container · Issue #2523 · google/cadvisor

I noticed that the CPU usage of cadvisor is the highest of all containers I’m running, which I feel is unexpected. it’s still not crazy (an average of 7%), but I feel it should be less. I’m using t…

GitHubgoogle

Router 모니터링

• Router 쪽의 상태도 알아두면 나쁘지 않겠다는 생각이 들었다. 한국에서 내 공유기로 시도를 하신 분이 있어 그대로 시도해보았다.

asus ac68u - prometheus, grafana 모니터링 하기

1. ac68u에서 정보를 수집할 node_exporter를 컴파일 한다. asus ac68u 의 경우 armv7 아키텍처를 사용하고 있다. 이 아키텍처에 맞도록 node_exporter를 크로스 컴파일 한다. git clone git@github.com:prometheus/node_exporter.git cd node_exporter GOARCH=‘arm’ GOOS=linux go build 2. node_exporter를 ac68u로 이동 후 실행 크로스 컴파일 한 node_exporter 파일을 asus ac68u로 이동한 후 실행해준다. scp ./node_exporter admin@192.168.1.1:~/ ssh admin@192.168.1.1 ’nohup ./node_exporter >/de…

TISTORY수수라이프

• 여기서 생각도 안한 삽질을 했는데 -_-..
• AC68U 와 AC68P 의 차이일지도 모르겠다. ARMv7 아키텍처로 동일한데, 위 방식으로 컴파일하면 Illegal instruction 이 발생했다.
• Linux RT-AC68P-8AF8 2.6.36.4brcmarm #1 SMP PREEMPT Sat Jan 1 13:43:55 EST 2022 armv7l ASUSWRT-Merlin 라고 나온다. ARMv7 에 linux 니까 안될리가. 없어 이해가 안됐다.
• 내 컴파일 바이너리가 문젠가 싶어, 정식으로 배포된 바이너리를 받아도 마찬가지.

Illegal instruction on Asus RT-AC68U router · Issue #1822 · caddyserver/caddy

1. What version of Caddy are you using (caddy -version)? Website says 10.0.6, caddy -version gives “illegal instruction” 2. What are you trying to do? this is my first try to run Caddy on Asus RT-A…

GitHubcaddyserver

• 비슷한 문제를 ac68u 에서 겪은 사람이 있었다. ARMv7 로하면 안되고 ARMv5로 해야 된단다. (?) 혹시나 싶어 ARMv5 버전을 가져와서 사용하니 잘 작동한다.
• SNMP 로 자료 수집이 가능하긴하다.

결과

홈 서버에 대한 모니터링 도구를 모두 Oracle Cloud 로 옮겼다. 기존에는 Proxmox node 에 대해서만 모니터링하고 있었으나, 이번 기회에 다음과 같이 모니터링 도구를 추가했다.

• Proxmox node 모니터링
  • pve-exporter
• Oracle Cloud VM모니터링
  • node-exporter
• 호스팅 중인 web service 모니터링
  • blackbox-exporter
• docker container 모니터링
  • cAdvisor

또한 Grafana 를 통해 이를 시각화하였으며, Grafana 의 알림 도구를 통해 hosting 중인 서비스가 down 되는 경우 즉각 알림이 오도록 조치했다. 테스트 결과 아주 잘 작동하고 있다.

이전과 마찬가지로 개인 VM 이기에 내부 망에 접근하기 위해 VPN 을 설정하였고, 이번에는 Wireguard 를 활용하였다. 여러 VPN 을 굳이 사용할 이유도 없고, OpenVPN 에 비해 Wireguard 가 이점이 있어, 홈 서버 또한 Wireguard 로 전환하는 것을 검토해볼 필요가 있다. 다만, Router 단에서 직접 접속을 하는 것을 원하는 상황인데, 현재 펌웨어에서는 Wireguard 를 지원하지 않아 그 방법을 모색해봐야할 것이다.

앞으로 추가로 기기를 추가하거나 VM 을 늘린다면 현재 작업한 내용을 수동으로 일일히 추가해야한다. 좀 귀찮은 작업이라서 자동으로 할 수 있는 방법에 대해서도 찾아볼 필요가 있다.

또한, Cloud 와 홈 서버의 네트워크 관련한 작업이 은근히 골칫거리였다. 현재는 단순하게 ACL 을 통해 접근을 제한하고 있다. 하지만 최대한 격리가 필요한 환경에서는 서로 다른 네트워크를 묶어야할텐데 이에 대해서 지식이 전무하여 어떻게 해야할 지 몰랐다. 아마 site-to-site VPN 같은 서비스를 Cloud 제공 업체에서 제공하는 것으로 알고 있는데 조금 더 찾아봐야할 것 같다.

이번에 사용한 툴들에 대해서 각각 공부해볼만한 것이 꽤 많다. 현재는 단순하게 툴의 조합을 맞춘 것이지만, 이후 백엔드 서버를 구성하거나 한다면 내기 필요한 모니터링 요소를 관찰 할 수 있도록 만들어야할 것이다. 적어도, prometheus 에 대해서는 깊게 짚고 넘어갈 필요는 있어보인다.

결과적으로 현재 나의 모니터링 구조는 아래와 같이 되었다.

배경

• 아찔한 일이 있었다. 면접을 보는 당일에 갑작스레 집에 있는 서버가 다운이 되었다. 이를 인지한 것은 실제로 서버가 다운되고 4시간이나 지난 이후였다. 다행히 면접 과정에서 직접 서버에 접속하거나 하는 일은 없었지만, 완전히 손을 댈 수 없는 상황이 되어 상당히 당황스러웠다.

• 기존 서버의 경우 위와 같은 구조를 취하고 있는데, 내부망 관리 및 모니터링과 실제 서비스 파트를 나누고 있을 뿐이다.
• 현재 상태에서는 여러가지 문제 상황이 발생할 수 있다.
  • 서비스 서버가 뻗는 경우
    • 서비스 접속 불능으로 이어짐.
    • 해당 경우에는 서버가 다운 된 것을 인지하기만 하면, 원격으로 재부팅 / 재설정이 가능하다.
  • 모니터링 서버가 뻗는 경우
    • 모니터링이 중단되고, 내부 DNS 서버가 중지되어 내부 망 접속에서 문제가 발생할 수 있음.
    • 라우터가 다운되지 않았다는 가정 하에, 재부팅 및 재설정은 가능함.
  • 서버 라우터, 혹은 WAN 이 들어오는 첫 모뎀쪽 스위치가 다운되는 경우
    • 이 케이스로 인해서 이번에 서버가 완전히 접속 불가하였음.
    • 외부에서 접속할 수단이 아예 존재하지 않으므로, 원격으로 처리할 수 있는 방안이 존재하지 않음.
    • 적어도 서비스가 중단되었다는 사실은 인지할 필요가 있음.

해결 방안 모색

• 이번에 발생한 문제는 "외부에서 완전히 대응이 불가능한" 상황이었다.
• 이상적으로는 외부에 다른 클러스터를 구축하고 이중화를 함으로서 해결하는 방법이 있다. 그러나 비용을 생각하면 합리적이지 않다.
  • Proxmox Cluster 로 추가 구성하는 경우에는 서버 구축 비용이 추가로 발생한다. 한 두푼이 아니라서 제외한다.
  • 클라우드의 무료 서비스를 활용해보는 것도 고려해보자.
• 완전히 서버가 다운이 되는 경우에 대해서는 대응은 하지 못하더라도 적어도 서버가 다운되었다는 사실은 인지해야한다. 따라서, 각 서버에 대해서 health check 를 외부에서 할 수 있도록 하고, 문제가 발생한 경우 알림을 받을 수 있도록 하려고 한다.
• 안정성이 최우선이므로, 이는 외부 클라우드를 통하는 것이 적절하다.
• 가능하다면, 이중화도 고려해본다.

클라우드 선정

• 클라우드 선정에서 가장 중요한 것은 비용이다.
  • 성능의 경우 관리하는 서버가 많지 않고 고부하 작업이 존재하지 않기에 크게 고려하지 않는다.

클라우드(Cloud) 프리티어 비교 - 서비스 및 스펙 비교 - 상시 무료 비교

클라우드 프리티어 이번에는 각 4개 회사의 클라우드 프리티어 서비스 중 기본인 컴퓨트(VM) 스펙 중점으로 비교 확인 해보도록 하겠습니다. 클라우드 회사에서는 여러가지 유형으로 맛보기 서비스 형태인 프리티어 서비스 를 하고 있습니다. 프리티어 제공 내역 프리티어 안에는 세부적으로 크게 상시 무료 와 기간제 무료 그리고 크레딧 제공 형태로 구분 됩니다. - 기간제 무료는 특정 기간에서

HoingJade(정현호)

• 다른 Cloud VM 프리티어의 경우 대부분 기간의 제한이 있다.
• 러닝커브를 생각하면, 기존에 사용할 수 있던 AWS 를 사용하는 것이 좋을 수 있다만 1년의 프리티어 제한을 이미 다 써먹었다. (계정을 새로 만들면 되기는 함)
• 오라클의 경우에는 ARM 을 사용하는 VM 의 경우 무료로 사용이 가능하다.
  • 꽤 매력적인 조건이다.
  • ARM 4 core / 24GB or 1GB / 6GB *4 VM 이 가능하다.
  • Oracle DB (10GB 정도) 사용이 가능하다.
  • Object Storage 10GB 도 사용이 가능하다.
  • 가장 놀라운건 "평생 무료" 라는 점이다.
    • 언젠가는 막힐지도 모르겠지만...?

오라클 클라우드 삽질기

Free-tier VM Instance 만들기

• 이게 삽질이 될 줄은 몰랐다...
• 오라클 클라우드는 프리티어를 제공하기는 하나, 이 사용량이 제한되어있다.
  • 이 소식을 듣고 다른 홈 리전(싱가폴)에 지정하여 만들었다. 그러나 싱가폴 리전도 포화 상태이다. 괜히 쓸데없이 먼 곳에 동록했다(...) 더군다나 오라클 클라우드의 경우 계정 재생성이 어렵다.
    • 새로 계정을 파더라도 기존에 사용한 카드 번호를 사용할 경우 계정 블락이 되거나 아예 생성이 되지 않을 수 있다. (AWS 가 벌써 그리워진다.)
    • 모니터링용으로 구성하는 서버이기에 우선은 신경을 끄도록 하려고 한다. 실제 서비스를 올리는 경우는 아직 없고, 있더라도 이중화 목적으로 사용할 것이다.
• 프리티어 계정에서만 생성이 되지 않는 것이기 때문에 유료 계정으로 전환했다
  • 지급 검사로 100불 정도 소요가 되었다.
  • 일반적으로 이것도 바로바로 취소되는 편인데, 왠걸 바로 취소가 되지 않아 당황했다. (아직도 안됐다...)
  • 카드 결제 뿐 만아니라, 계정 업그레이드도 시간이 소요된다. (돈 주고 쓴다는데 대체 왜 이러는지 이해할 수가 없다.)
    • 계정 업그레이드는 빠르면 30분 길면 일주일 정도 소요된다. 나는 약 3시간 정도의 시간이 소요됐다.
• 유료 계정으로 전환한 뒤, 정상적으로 인스턴스를 생성할 수 있었다. 우선 만든 인스턴스는 ARM 2 core / 12G RAM 이다.
• SSH 접속의 경우, 첫 생성 과정에서 얻은 private key를 통해 접속할 수 있었다.
• 이후 고정 IP 할당을 해줬다.
  • Reserved IP 설정 업데이트가 바로 되지 않는데, 기다리면 된다.

[OCI] 오라클 클라우드 - 2. 고정 IP 설정

오라클 클라우드에 VM을 생성하면 임시 IP가 배정이 되는데 외부에서 접근하기 위해서는 고정IP를 설정해 주어야 한다 1. 고정IP 예약 설정 OCI에서 먼저 고정IP를 예약하자 아래와 같이 OCI 메뉴에서 Networking → IP Management → Reserved Public IPs 로 접속한후 Reserve Public IP Address 버튼을 눌러 고정 IP를 예약하자 Reserve Publlic IP Address 메뉴로 들어가면 아래와 같은 창이 나오는데 Reserved Public IP Address Name 에 임의의 이름을 입력하고, IP Address Source에서 Oracle을 선택한 후 아래쪽에 Reserve Public IP Address 버튼을 클릭하면 아래와 같이 위…

TISTORY기억력이 점점 나빠진다

기본 설정

• 초기에는 사용자가 ubuntu 로 지정되어있다. 보안적인 이유로 계정명을 변경했다.

오라클 클라우드 우분투 계정 설정 가이드 - 이불색 하늘

계정 이름을 생성 전 정할 수 있는 Azure와 달리 오라클, AWS (필자는 AWS를 사용해보지 않았지만) 등에서는 가상 컴퓨트 인스턴스, 그러니까 서버를 생성할때 사용자 이름을 ubuntu로 부여해준다. ssh ubuntu@ip -i ~/.ssh/id_rsa.pub 일단 서버로 ssh접속을 한다. sudo -i 접속 후 루트 계정으로 로그인한다. adduser user를 추가한다. 는 꼭 자신이 하고 싶은 이름으로 바꾸도록 한다. (예: azureuser, ...) mkdir

이불색 하늘 - Chnrit의 블로그

• 네트워크 inbound / outbound 보안 규칙 설정이 필요하다. VCN (AWS 의 VPC 가 여기서는 VCN 이다.) 에서 보안 규칙을 설정한다.

Oracle Cloud에서 HTTP 포트 열기

Oracle Cloud를 사용해서 웹 서비스를 만들경우 기본적으로 ICMP, SSH만 열어놓기 때문에 HTTP, HTTPS 요청은 거부하게 됩니다. 이를 해결하기 위해서 Oracle cloud에서 HTTP, HTTPS를 제공하기 위해 해당 포트를 여는 방법을 정리해보겠습니다. 먼저, 오라클 클라우드 콘솔로 접속합니다. 네트워크 관련 설정을 위해 가상 클라우드 네트워크(VCN)로 이동합니다. 현재 인스턴스가 속해있는 VCN을 선택해서 들어갑니다. (따로 설정하지 않았다면 기본으로 생성되어있는 것 한개만 존재합니다.) VCN에 들어가면 좌측에 리소스에 네트워크 보안 그룹으로 이동합니다. 새로운 규칙을 생성하기 위해 ”네트워크 보안 그룹 생성” 버튼을 눌러 새로운 보안 그룹을 생성합니다. 네트워크 보안그룹에…

TISTORYyongckim

• 조금 더 편리하게 접속을 하고자, 해당 서버에 따로 별칭을 주기로 했다.
  • photogrammer.me 의 DNS 를 관리하는 cloudflare 에서 레코드 테이블에 추가했다.

모니터링 구축

• 모니터링의 대상은 다음과 같다.
  • Oracle Cloud VM / 내부 모니터링 서비스
  • Router
  • Proxmox hosts
  • Home server 의 웹 서비스
• 기존의 모니터링의 경우 InfluxDB + Grafana 형태였으나, 이번에는 Prometheus 로 변경하고자한다.
  • Promethus 를 사용함으로서 기존 Proxmox 이외에도 Router 쪽의 metric 을 보다 쉽게 가져올 수 있으며, Blackbox exporter 를 활용하면 service health check 도 조금 더 간편해진다.
  • 추가로, 전원 사용량 관련해서도 모니터링을 추가할 예정인데 metric 을 prometheus 로 뽑아주는 코드가 있어 간편하다.
  • 아무래도 influx db 는 시계열 데이터베이스일 뿐이기 때문에, metric 에 특화된 prometheus 를 활용하는 것이 조금 더 좋겠다.

Oracle Cloud 내부 서비스 모니터링 하기

• 홈 서버와의 통신의 경우 보안적인 문제를 먼저 고려해야한다. Prometheus 를 통해서 통신을 하게 될 것인데, Prometheus 의 경우 pulling 방식으로 데이터를 가져온다. 이는 홈서버에서 pulling 을 하기 위한 포트를 별개로 개방해둬야한다는 의미가 된다.
• 그러나, 어디서나 내 서버의 정보를 가져오도록 하는 것은 바람직하지 않다. 이 부분에 대해서는 잘 생각해서 최대한 타인이 접근할 수 있는 구조로 변경해야한다.
• 이러한 이유로 우선 Oracle cloud 내부의 서비스를 Promethues + Grafana 를 통해서 모니터링하도록 했다.

Grafana

• 모니터링 시각화 도구로서 Grafana를 활용한다.
• 현재 계획은 Grafana 를 시각화 도구로 활용하고, Prometheus 는 metric 수집 도구로 활용하고자 한다.
• docker compose 를 통해서 container 로 올린다.

  grafana:
    image: grafana/grafana:latest
    container_name: grafana
    restart: always
    ports:
      - ?:3000
    volumes:
      - ./data/grafana:/var/lib/grafana
    depends_on:
      - prometheus
    networks:
      - monitoring

• 해당 설정에서 Grafana 가 permisson deined 를 뿜으며 start 되지 않는 문제가 발생하였다.
  • volume 으로 잡은 곳에 grafana 가 접근을 하지 못하고 있었다.
  • 처음에는 user:root 로 권한을 잡아줬으나. log 에서 previliged 된 유저를 사용하는 것에 대해서 경고를 했다.
  • 따라서, volume 으로 잡은 디렉토리에 대해 권한을 변경했다.
    • sudo chmod 777 {volume_dir}
    • 다만 조금 더 섬세하게 권한을 제어하는 것이 낫다고 본다.

Prometheus

• 기존 홈서버의 경우 InfluxDB 에 metric 을 push 하고 grafana를 모니터링 시스템으로 활용하고 있었다. 이는 Proxmox 자체에서 InfluxDB 로 metric 을 보내는 기능은 있으나 Prometheus 쪽으로 보내는 기능은 내장하지 않았기 때문이었다.
• 그러나, 이번에는 Prometheus 로 통합해서 모든걸 해보려고 한다. InfluxDB 의 경우 시계열 DB 일 뿐 모니터링에 대한 책임은 없다. 그러나 Prometheus 는 이를 위해 탄생한 프로그램이며, Prometheus 에 metric 을 보낼 수 있는 다양한 서비스들이 존재한다.
• 현재 VM 상태 또한 직접 InfluxDB 쪽으로 보내도록 cron job 을 만들거나 해야하는데, 이보다는 아래 활용한 node-exporter 를 활용하는 것이 더 편리하며, 웹 서비스의 상태 체크 또한 blackbox exporter 를 활용하는 것이 더 편리하다.
• 아무튼, Prometheus 또한 docker compose 에 함께 올렸다.

  prometheus:
    image: prom/prometheus:latest
    container_name: prometheus
    restart: unless-stopped
    volumes:
      - ./configs/prometheus.yml:/etc/prometheus/prometheus.yml
      - ./data/prometheus:/prometheus
    command:
      - --config.file=/etc/prometheus/prometheus.yml
      - --storage.tsdb.path=/prometheus
      - --web.console.libraries=/etc/prometheus/console_libraries
      - --web.console.templates=/etc/prometheus/consoles
      - --web.enable-lifecycle
    ports:
      - ?:9090
    networks:
      - monitoring
    depends_on:
      - node-exporter
      - blackbox

• Prometheus 의 경우 metric 수집을 위한 config 가 별도로 필요하다. 설정은 아래와 같이 했다.
  • 아직 이쪽 config에 대해서 자세히 알고 있지 않아, 기본적으로 각 exporter 들의 기본 설정을 가져왔다.

global:
  scrape_interval: 1m

scrape_configs:
  - job_name: 'prometheus'
    scrape_interval: 1m
    static_configs:
      - targets:
        - prometheus:9090

  - job_name: 'node'
    static_configs:
      - targets: 
        - node-exporter:9100

  - job_name: blackbox
    metrics_path: /probe
    scrape_interval: 5s
    params:
      module: [http_2xx]
    static_configs:
    - targets:
      - ...
    relabel_configs:
    - source_labels: [__address__]
      target_label: __param_target
    - source_labels: [__param_target]
      target_label: instance
    - target_label: __address__
      replacement: blackbox:9115

Node exporter

• node exporter 는 host 의 상태를 prometheus 로 export 할 수 있도록 돕는 도구이다.
• 이상적으로는 host 쪽에 직접 설치하는 것이 바람직하다. 그러나, 다행히도 container 로 올려서 host 의 정보를 받아올 수 있도록 하는 방법이 존재했다.
  • container 의 특성상 host 쪽의 정보를 알게하는게 적절한 행동은 아니다.
• docker compose 는 다음과 같다.

  node-exporter:
    image: prom/node-exporter:latest
    container_name: node-exporter
    restart: unless-stopped
    volumes:
      - /proc:/host/proc:ro
      - /sys:/host/sys:ro
      - /:/rootfs:ro
    command:
      - --path.procfs=/host/proc
      - --path.rootfs=/rootfs
      - --path.sysfs=/host/sys
      - --collector.filesystem.mount-points-exclude=^/(sys|proc|dev|host|etc)($$|/)

• Prometheus 쪽에서도 설정을 잡아줘야한다.

  - job_name: 'node'
    static_configs:
      - targets: 
        - node-exporter:9100

• Grafana 에서 node exporter dashboard 를 가져왔다. 단순하게 prometheus 로 연동하면 끝난다.

• 연동 과정 중에 docker network 가 서로 제대로 연결이 되지 않아 문제가 발생했었다. 이유는 멍청하게 해당 서비스를 도커 네트워크에 묶지 않았던것, 그리고 네트워크 내부 망인데 외부 포트로 연결하고 있던 것이었다.

Blackbox exporter

• blackbox exporter 는 Web service 들에 대해서 healthcheck 를 하고 이에 대한 metric 을 export 하는 툴이다.
• 이번 모니터링 도구의 핵심이며, 홈에서 호스팅하고 있는 서비스에 대해서 모두 모니터링 할 것이다.
• 설치 및 설정은 간단하다. 아래와 같이 compose, blackbox config, prometheus config 를 작성했다.
• docker compose

  blackbox:
    image: prom/blackbox-exporter:latest
    container_name: blackbox
    ports:
      - 19115:9115
    command:
      - --config.file=/etc/blackbox/blackbox.yml
    volumes:
      - ./configs/blackbox.yml:/etc/blackbox/blackbox.yml
    networks:
      - monitoring
    restart: unless-stopped

• blackbox config

modules:
  http_2xx:
    prober: http
    timeout: 5s
    http:
      method: GET

• prometheus config

  - job_name: blackbox
    metrics_path: /probe
    scrape_interval: 5s
    params:
      module: [http_2xx]
    static_configs:
    - targets:
      - ...
    relabel_configs:
    - source_labels: [__address__]
      target_label: __param_target
    - source_labels: [__param_target]
      target_label: instance
    - target_label: __address__
      replacement: blackbox:9115

• 마찬가지로 Grafana 에 이미 만들어진 dashboard 를 넣어줬다. prometheus 랑 연동하면 끝.

• 추가로, 서비스가 다운 된 경우 알림이 오도록 간단하게 알림을 설정했다.
  • Dashboard 에서 Fail 부분에 0 이상 값이 도달한 경우 알림을 송신하도록 설정했다.
  • 홈 서버 전체를 내려보았고, 정상적으로 알림을 수신할 수 있었다.

• 이렇게 설정하고 이틀 정도 사용했는데, 거짓 알림이 자꾸만 왔다.
• 기존 alert 의 경우 count(probe_success{ job ~= blackbox} == 0) 으로 체크를 하고 있었는데, probe 에 종종 실패하는 경우가 많이 발생하는 것이 문제였다.
• 따라서, 특정 지점에서의 값을 보는 것 보다는 일정 interval 에서 비교하는 것이 적합하다고 판단했다.
  • 기존의 count(probe_success{ job =~ blackbox} == 0) 는 probe 에 실패한 갯수를 세는데, 이렇게 하면 일시적으로 probe 에 실패하는 상황에서 거짓 알림 문제가 발생한다. 이 거짓 알림은 순전히 운으로 나오는 것이라서, 재수가 없으면 pending 되는 중에도 다시 probe 에 실패하고 알림을 발송한다.
  • 따라서, probe 대상의 갯수와 interval 동안 probe 에 성공한 갯수의 최댓값을 비교하도록 했다. 따라서 A 값을 probe 에 성공한 수인 count(probe_success{ job =~ blackbox} == 1) 로 수정하고, 이를 2m 동안의 interval 동안의 range 로 가져오도록했다.
  • probe 대상의 수도 필요하다. 이는 count(up{job=blackbox}) 로 획득할 수 있다.
  • A 값은 시리즈이기 때문에, 이 값들 중에서 MAX 값을 reduce 해온다. 인터벌 내내 MAX 값이 up 값과 일치하지 않는다면 특정 서버가 다운되었음을 의미하게 된다.
  • 그리고 $B==$C 값으로 해당 true / false 로 표현하고 threshold 를 잡아줬다.

• 다만, 현재는 down 된 서버가 있으면 그냥 알림이 오도록했는데 "어떤 서버가 down 되었는가?" 라는 상세 정보까지는 알 수 없다. 여기에 대해서는 조금 더 찾아봐야겠다.

구조

• 결과적으로 위와 같은 구조를 갖추었다. Oracle cloud 위에 있는 VM 에 대한 모니터링과 홈 서버에서 호스팅 중인 서비스의 health check 가 가능하게 되었으며, 서버에 문제가 발생했을 때, 텔레그램으로 알림이 온다.
• Oracle Cloud 가 중단되는 경우를 대비하여 홈서버 측에서도 클라우드에 대한 모니터링을 고려해볼 수도 있겠다. 다만, 이는 나중에 하는 것으로 우선은 미뤄두자.

Cloud 네트워크 설정

Reverse Proxy 설정

• Reverse Proxy 의 경우 Nginx Proxy Manager 를 활용했다.
• 설정 중에 몇 가지 문제가 있었다.

1. aarch64 환경에서 SSL 문제

• 기존 홈 서버의 경우 x86 환경이었다. 별다른 이슈 없이 cloudflare 의 api 를 활용해서 Lets encrypt + certbot 을 활용할 수 있었다.
• 그러나, 이번의 경우 certbot 쪽에서 알 수 없는 문제가 발생했다. 다행히 해당 이슈가 github 에 있었다. 현재 latest 버전은 해결이 되어있지 않으나, 문제를 해결하고 있는 버전으로 변경하여 해결했다.

certbot-dns-cloudflare install fails. · Issue #2381 · NginxProxyManager/nginx-proxy-manager

Checklist Have you pulled and found the error with jc21/nginx-proxy-manager:latest docker image? Yes Are you sure you’re not using someone else’s docker image? Yes Have you searched for similar iss…

GitHubNginxProxyManager

2. proxy 를 하지 못하는 문제

• 각 서비스에 대해서 도메인을 붙여두고 reverse proxy 를 하고자 했으나, 502 Bad Gateway 가 발생했다.
• NPM 서비스쪽에서 다른 서비스와 도커 네트워크가 일치하지 않아 찾을 수 없는 문제였다.
  • 기존에는 localhost:port 로 표기했으나, 도커 네트워크 안쪽이라서 안되는 것으로 보였다.
• compose 파일 자체는 다르나, docker network 는 공유하도록했다.
  • docker network connect {network} {container}

Ingress 보안 규칙

• 모든 포트로 접속하게 하는 것은 위험하며, 최전방에 Reverse Proxy 를 통해서 접속하도록 하고자 했다.
• 80, 443 포트만 개방하도록 했다.

생각보다 글이 많이 길어져서 홈서버 Proxmox node / Router 모니터링은 다음 글에 이어서 작성하겠다. 이번 글을 통해서 구축한 서버의 구조는 다음과 같다.

홈 서버 모니터링 시스템 Oracle Cloud 로 이전하기 (2)

지난 글에 이어 Oracle Cloud 로 모니터링 시스템을 옮기는 과정을 마저 진행해보겠다. VPN 설치 * 모니터링 서버에서 내부 서비스의 경우 외부로 노출될 이유가 없다. 따라서, VPN 을 통해서만 해당 서버에 접속 할 수 있도록 한다. * 기존에 OpenVPN 을 통해서 VPN 을 구축하고 있어, 해당 서버도 OpenVPN 을 활용하도록 할 것이다. docker

PhotogrammerSungjun Park

Mock Data 생성기의 필요성

• dummy data 를 대량으로 생산하기 위해서는 몇 가지 방법이 있었다.
  • mock generator (web) 이용
  • procedure 작성
  • 직접 코드 작성
• mock generator 의 경우 간편하게 만들기는 하지만, 백 만 건이 초과하는 경우에 해당 web 에서 응답을 하지 않거나, 유료 결제가 필요했다. 특히, csv 로 export 해서 LOAD DATA 를 통해서 적재할 경우 백 만 건에 30초 미만으로 아주 빠르게 적재할 수 있었으나, 천 만 건 이상의 데이터를 획득 불가하여 아쉽게도 제외했다.
• procedure 의 경우 insert into 구문을 loop 돌면서 주입한다. 꽤나 편리한 방법이고, BULK INSERT 를 활용한다면 더 빠른 적재를 할 수 있다. 다만, 생성할 수 있는 데이터의 형태가 한정되어있다.
• 직접 코드를 작성하는 방법의 경우, json-schema-faker 라는 라이브러리를 결합하여 활용하는 방법이 있었다. 그러나, json-schema-faker 를 이용하려면, json-schema 를 작성해야하고, faker 를 통해서만 데이터 생성(물론 피하는 방법이 있기는 함.)해야해서, 다소 불편함을 느꼈다.
• 결과적으로, Programmable 하게 코드로 간단하게 작성하여 원하는 형태의 데이터를 빠르게 csv 파일 만들어내는 라이브러리를 하나 만드는 것이 더 낫겠다는 판단을 했고, mock2csv 라이브러리를 제작했다.

Mock2CSV

• 언어는 typescript 를 선택했다.
  • npm 에서 활용할 수 있는 라이브러리가 많았으며, 하나 모듈 작성하는데 코드 작성 시간이 짧다.
  • Web GUI 를 구성하고자 하는 욕심이 있었고, Web GUI 를 만들기 편한 언어기도 하다.
  • Java 를 선택했다면, Entity 를 끌어다와서 convert 할 수 있는 여지가 있었을 것 같다. 다만, 개발 / 테스트 / 사용에서는 오히려 툴로서 사용하기에 불편하다고 판단했다.
• 기존 라이브러리 최대한 활용할 수 있으며, programmable 하게 코드를 작성하여 csv 로 생성할 수 있도록 하였다.
• csv 파일을 만드는 부분은 최대한 라이브러리에 맡기고, 어떤 데이터를 생성해야하는지에 대한 부분은 programmable 하게 적을 수 있도록 하고 싶었다. json-schema-faker 의 경우 정적인 json-schema 를 통해서 생성해야하기에, 불편함을 느꼈기 때문이다.
• 따라서, 간단한 interface 를 schema 로 정했다. (schema 가 적절한 단어 선택인지는 모르겠지만...)

Schema

export interface Schema {
	[key: string]: () => string;
}

let uid = 1;
const User: Schema = {
	user_id : () => (uid++).toString(),
	nickname: () => faker.internet.userName(),
	...
}

Schema interface 는 아주 단순하다. Object 의 key 는 각 column 을 의미하며, 각 column 의 생산 방법을 lambda function 으로 정의한다. 이렇게하면, faker 에서 처리하지 못하는 다양한 타입도 다른 library 를 끌어와서 대체하거나 직접 작성할 수 있다. 또한, id 와 같은sequence 또한 간단한 코드로 처리가 가능하다.

Mock2CSV

class Mock2CSV {
	// member variables..
	constructor(options?: Options) {
      ...
    }

    generate(schema: Schema, recordNum: number, filePath: string) {
      ...
    }
    
    generateToStream(schema: Schema, recordNum: number, stream: WriteStream) {
      ...
    }
}

csv 를 만드는 class 로 Mock2CSV 라는 클래스를 만들었다. 해당 클래스는 csv 형식의 데이터를 schema를 바탕으로 제작하는 책임을 가지고 있다. web 버전의 mock generator 를 참고하여, quote, escape, delimiter, newline 을 configuration 할 수 있도록 해두었다.

초기 버전에서는 Mock2CSV 객체 생성 과정에서 schema, recordNum, filePath 등을 주입했다. 그러나, 그렇게 사용할 경우 새로운 schema 에 대해서 생산을 할 때마다 객체를 새로 생성해야한다. 따라서, csv 를 어떻게 포메팅할 지에 대한 설정만을 하고 generate(schema, recordNum, filePath) 를 통해서 여러 번 재사용할 수 있도록 변경하였다.

generateToStream(schema, recordNum, stream) 또한 추가했다. 이는 stream 을 통해서 외부에 전송하는 경우를 염두에 둔 것이다. web GUI 를 간략하게 붙여서 Mock Generator 와 같은 환경을 보다 쉽게 만들어내기 위함이다. 이후 작업이 있다면 Schema 를 외부 GUI 를 통해서 선택하고 이를 객체로 만든 후 generation 할 수 있는 형태로 만들어내는 과정이 될 것이다. (혹은 예외처리?)

generateAsync 를 v0.0.7 에서 추가하였다. LOAD DATA 실험 중에 나눠진 데이터를 주입하기 위해 한 번에 20개의 csv 파일을 생성해야했다. 단일 파일을 처리하는 경우에는 괜찮았으나, 현재 코드의 경우에는 모든 stream 이 종료되고 난 이후에야 파일이 한번에 생성되는데 적절한 동작은 아니라고 생각되었다. 때문에, Async 가 지원되는 API 를 추가하였다.

개발하면서 ...

v0.0.6 까지는 테스트 없이 코드를 작성하였는데, 안정성이 너무 떨어졌다. 특히, async api 하나 들어오기 시작하니, 테스트 프레임워크의 도움이 절실해졌다. vitest 가 깔끔하니 괜찮아보여 도입하였고, 덕분에 escape 를 처리하고 있지 않았던 문제로 함께 수정할 수 있었다. (역시 테스트는 선택이 아닌 필수이다) 다만, api 에 대한 e2e 테스트만 수행하고 내부 private method 에 대한 검증은 아직 하지 못했다. (아마 방법이 있을 것 같은데, 조금 찾아봐야할 듯 싶다.)

option 관련해서도 고민이 많았었다. (물론 나만 쓰지만) 다른 사람이 사용한다면 어떻게 처리하는 것이 조금 더 편리할까? 라는 고민에 대해서 많이 하게 되었다. 초기에는 fn(options: Options = new Option()) 형태를 취했는데, 유연성이 부족했다. 이후에 fn(options?: Options | Object) 형태로 변경하였고, this.options = { new DefaultOption(), ...options}; 로 변경하며 Option 객체를 모두 받지 않아도 설정이 가능하도록 변경했다. 아마 다른 방법이 더 있을 것 같기는 하나, 현재는 만족.

아무튼, 만든 이후 이전 작성글에서 LOAD DATA 를 테스트하는데 굉장히 유용하게 활용했다. 데이터 생성 로직 자체가 눈에 잘 들어와서 편리했고, 나름 잘 만든 것 같다는 생각이 든다.

example

사용 방법은 어렵지 않다. schema 를 정의하고, Mock2CSV instance 에서 .generate(schema, recordNum, filePath); 를 호출하면 된다.

import { bcrypt, Schema, faker, moment, Mock2CSV } from "mock2csv";

let user_id = 1;
const pw = bcrypt.hashSync("password123", 10); // encrypt password (encryption is time-consuming)

const User: Schema = {
	userId: () => (user_id++).toString(),
	nickname: () => faker.internet.userName(),
	email: () => faker.internet.email(),
	password: () => pw,
	createdAt: () => moment().tz("Asia/Seoul").format("YYYY-MM-DDTHH:mm:ss.SSSSSSZ"),
	updatedAt: () => moment().tz("Asia/Seoul").format("YYYY-MM-DDTHH:mm:ss.SSSSSSZ"),
};

const m2c = new Mock2CSV();  

m2c.generate(User, 1e3, "user.csv");

배포

• npm 에 배포하는 것은 처음이었다. typescript 를 만진지 꽤 되어 권장 설정으로 대충 만들어냈다.
• 사소한 변경 사항(README.md 수정이나 package.json 수정)에도 새로운 버전을 publish 해야했다. 버전을 의미없이 많이 올렸는데, 조금 더 신중하게 수정 / 배포가 필요함을 느꼈다.
• 단순한 코드이기는 하나, 이렇게 배포하는 것은 처음이라 색다른 경험(?) 이었다. 나 말고 사용할 사람이 더 있을지는 모르겠으나, 업데이트시에 이것저것 주의해야할 것들이 많이 보인다. (만들자마자 deprecated 되어버린 경우도 있었는데, 실제 누가 사용하는 라이브러리라면 곤란했을 것이다.)
• typescript 에서 손 뗀지 시간이 좀 됐는데, 관련 configuration 잡는 것에 대해서도 다시 짚고 넘어갈 필요가 있었다.
• 배포한 라이브러리는 아래에서 볼 수 있다.
  • mock2csv-npm
  • github

현재 만들고 있는 토이 프로젝트에서는 대량의 데이터가 존재하는 DB 를 대상으로 여러가지 테스트를 수행한다. 테스트를 수행하기 위해서 더미 데이터를 주입할 방법에 대해서 모색해야했다.

SQL Procedure

• SQL 문으로 직접 테이블에 데이터를 주입한다.
• 직접 Insert into () values (); 와 같은 구문을 작성할 수도 있지만, Procedure 혹은 function 을 직접 작성하여 해결하는 편이 낫다.
• Procedure 예시

  
DROP PROCEDURE IF EXISTS init_perfomances $$  
CREATE  PROCEDURE init_perfomances(  
    IN num_rows INT  
) BEGIN  
    DECLARE i INT DEFAULT 1;  
    DECLARE name VARCHAR(255);  
    DECLARE start_at TIMESTAMP;  
    DECLARE end_at TIMESTAMP;  
    DECLARE created_at TIMESTAMP;  
    DECLARE updated_at TIMESTAMP;  
--  loop num_rows times  
    WHILE i <= num_rows DO  
        SET name = CONCAT('name_', i);  
        SET created_at = FROM_UNIXTIME(UNIX_TIMESTAMP('2020-01-01') + FLOOR(RAND() * (UNIX_TIMESTAMP('2024-01-01') - UNIX_TIMESTAMP('2020-01-01'))));  
        SET updated_at = created_at;  
#         start at is a random time larger than created Time  
        SET start_at = FROM_UNIXTIME(UNIX_TIMESTAMP(created_at) +  
                                     FLOOR(RAND() * (UNIX_TIMESTAMP('2024-01-01') - UNIX_TIMESTAMP(created_at))));  
#         end at is a random time larger than start Time  
        SET end_at = FROM_UNIXTIME(UNIX_TIMESTAMP(start_at) +  
                                   FLOOR(RAND() * (UNIX_TIMESTAMP('2024-01-01') - UNIX_TIMESTAMP(start_at))));  
        INSERT INTO performances (performance_id, name, start_at, end_at, created_at, updated_at) VALUES (i, name, start_at, end_at, created_at, updated_at);  
        SET i = i + 1;  
    END WHILE;  
END $$

• Procedure 을 사용할 경우 8 min per 1,000,000 rows 정도 걸린다.
  • 이는 loop 로 100 만 건의 insert into 를 하기 때문에 더 느리다.
  • 단순 테스트에서는 bulk insert (100 rows split) 으로 할 경우 < 40s 정도 소요된다.
• 나름 간편하게 데이터를 생성하고 주입할 수 있다는 장점이 있다.
• 데이터 적재 속도로 따지면 후에 기술할 CSV 를 통한 LOAD DATA 에 비해서 많이 느린 편이다. 하지만, constraint 를 잘 지키면서 빠르게 작성하기에 용이하다는 장점이 있다.
• 다만 이 방법의 경우 `INSERT INTO `구문이 너무 많이 호출된다. BULK INSERT 를 이용하여 INSERT INTO 구문의 호출 횟수를 줄여 어느정도 속도 증가를 기대할 수 있다.
• Procedure 을 서버에서 실행하기만 하면 되므로, 별도로 데이터를 생성하고 옮기거나 하는 작업이 필요 없다는 것 또한 큰 장점이다.

Mock Generator

• 더미 데이터 생성기 와 같은 생성기를 활용하는 방법이다. 생성기의 경우 다양한 데이터 타입이나 종류에 대해서 의미있게 식별되는 다양한 데이터를 삽입한다. 실제와 같은 환경을 일부 모사하고 싶을 경우 해당 방법을 사용할 수 있다.
• csv 포멧으로 export 해두는게 좋다. 아래 기술될 LOAD DATA INFILE 을 활용하면 빠르게 데이터를 넣을 수 있다.
• 테스트 결과 웹을 통한 Dummy data 생성기는 대부분 1,000,000 건 이 초과할 경우 쓸 것이 못된다. 생성 시간 자체가 너무 오래걸리고 해당 서버에서 timeout 이 나는 것으로 보인다. 더 큰 데이터의 경우에는 유료 결제로 해결을 해야한다.
• 직접 Faker 라이브러리 등을 활용해서 CSV 파일을 만드는 것도 한 방법이다.
  • 주입할 schema 를 입력 / 필요한 format 을 정의하면 자동으로 주입하도록 한다면, 보다 쉽게 만들어낼 수 있다.
  • 다만, 이를 완전히 지원하는 라이브러리가 존재하는지는 아직 모르겠다. 웹 버전으로는 현재 존재하는데, docker 에 올려서 사용할 수 있도록 라이브러리를 만들어서 하나 배포하는 것도 괜찮아보인다.

LOAD DATA

• Mock Generator 와 같은 툴은 일반적으로 csv, sql 문 등으로 DB 에 삽입할 방법을 제공한다. 그 중에서, csv 를 활용해서 다음과 같이 load 할 경우 빠르게 데이터를 삽입할 수 있다.

mysql --local-infile=1 -u root -p
-- input password.
use test_db;
-- load data from csv
LOAD DATA LOCAL INFILE '/var/lib/mysql/output.csv' INTO TABLE USERS
FIELDS ENCLOSED BY '"' TERMINATED BY ';' ESCAPED BY '"' LINES TERMINATED BY '\n'
(@col1, @col2, @col3, @col4, @col5, @col6) set user_id=@col1,nickname=@col2,email=@col3,password=@col4,created_at=@col5,updated_at=@col6;

• procedure 의 경우 백 만 건에 총 8분 가량 소요된 반면 해당 쿼리로는 30초만에 적재가 완료되었다.
• 미리 데이터를 csv 로 생성할 수 있다면 해당 방법을 통하는 것이 가장 빠르다.
• MySQL - LOAD DATA

LOAD DATA 테스트

• 100 만건 주입 시에는 약 20초에 적재가 완료되었으나, 1,000 만건이 들어있는 csv 파일을 주입하는 경우에는 30분이 넘도록 주입에 실패했다.
• index 생성으로 인한 문제인지 혹은 다른 문제인지 확인하고자 테스트를 진행했다.
• 우선 아래 두 케이스를 비교해보자.

1. 10 M rows 를 한번에 주입
2. 500K 씩 나누어 20번, 총 10M row 주입

우선, 1번 10M 케이스는 > 30 min 이 소요되었으며 시간이 증가할수록 데이터가 주입되는 속도가 점점 느려져 테스트를 중단했다. 여기서 내 추측은 10 M 을 추가하는 과정에서 index 생성 오버헤드가 점점 증가하여, 데이터 주입이 느려지는 것으로 추측했다. (그러나, 현재 주입하는 데이터가 index 를 3개만 가지고 있는데 너무 큰 오버헤드가 아닌가? 하는 생각이 든다.)

2번 500K * 20 케이스에서는 놀랄만한 결과를 얻었다. 10 M 의 데이터를 주입하는데 총 160 sec 이 소요되었으며, 각 쿼리당 10 sec 미만이 소요되었다. 만약 인덱스 생성으로 인한 오버헤드가 존재했다면, record 의 증가와 비례하여 데이터 적재 시간이 증가해야한다. 그러나, 전혀 관련이 없는 모습이다. 10 M 까지는 인덱스의 영향과 관계없이 한번에 얼마만큼의 데이터를 주입하는가? 가 중요하다. 해당 구간에서는 record의 적재에 대해서 index의 영향은 크지 않다.

• 아래 stack overflow 의 질문에서는 나와 같은 고민을 이야기하고 있다.

Loading Lots of Data into MySQL too Slow

I’m running MySQL on my local computer. I’ve setup a database with multiple tables, 3 of which are potentially interesting here: CREATE TABLE rnames ( id INT AUTO_INCREMENT PRIMARY KEY, rname

Stack Overflowmimo31

• 질문자가 질문을 하게 된 데이터 적재량 - 속도의 연관은 아래 그래프와 같다.

• 내가 경험한대로 각 CSV 에 row 수가 증가할 수록 데이터 적재 속도가 비선형적으로 증가한다.
• 더 눈여겨볼 것은 그가 index / fk contraint 를 제거하고 적재한 상황이다.

• 3e6 케이스에서는 900s-> 60s 으로 95% 가량의 속도를 줄였다. index 가 실제로 데이터를 적재하는데 영향을 미치고 있다.
• 다만 이는 내가 2번에서 테스트한 상황과 다소 다르다. 작성자는 csv 파일 자체의 크기를 지속적으로 늘려간 반면, 나의 경우에는 record 의 개수와 연관이 있다.
• 결과적으로, 한번에 적재하는 양 은 인덱스 와 연관을 갖는것으로 보인다.
• 이는 Bulk insert 과정에서 두 가지의 문제를 짚어볼 수 있다.
  • transaction log
• LOAD DATA 의 경우 하나의 Transaction 으로 묶여 실행된다. 그런데, infile 의 data 가 증가할 수록 transaction 의 크기가 커지고 이에 따라 transaction log 또한 함께 증가한다.
  • load 과정에서 trasnaction log 관련한 warning 이 뜨기도 했다.
• index
  • index 를 갱신할 때, 한 번에 갱신하는 양이 많을 수록 B-Tree 의 rebalancing이 더 많이 필요하게 된다.
    • (해당 부분은 내부 동작에 대해서 아직 이해가 되지 않았다. B-Tree 의 rebalancing 이 비용이 높은 작업임은 이해하나, record 의 수에 비례하는 작업이기도 하다.)
• 따라서, 대량의 데이터를 migration 하거나 삽입해야하는 경우에는 다음과 같은 방법으로 속도를 최적화할 수 있다.
  • 정합성이 보장된 데이터라면 index 를 잠시 drop 하고 load 이후에 다시 index를 설정한다.
  • 데이터 적재시 한번에 너무 많은 양을 보내기보다, 나눠서 적재한다. (transaction 의 크기를 최적화)

방법에 따른 비교

• 환경
  • M1 Macbook Pro (Ram 16GB / M1 Pro)
  • Docker + MySQL 8.0
• LOAD DATA (10M 케이스의 경우 1 / 10 값을 산정함)

• LOAD DATA / Procedure 모두 index 를 해제하고 적재 후 다시 생성한다면 시간을 줄일 수 있다.

결론

• 상황에 따라 대량의 데이터를 삽입 시 두 가지의 방법을 고려하자.
  • Procedure + Bulk insert
    • 더미데이터를 생성하는 경우 유용하다. csv 파일로 저장할 경우, csv 파일의 크기 만으로도 상당히 크다. LOAD DATA 보다 느리기는 하나, 2배 정도 차이나므로 시도해볼만 하다.
  • LOAD DATA (CHUNKED)
    • DATA 를 migration 하는 경우에 가장 좋은 방법으로 판단된다. 모든 방법 중에서 가장 빠르게 적재할 수 있는 방법이며, 넣을 데이터를 나눌 Chunk 의 크기 조절과 MySQL 설정, Index 설정 등을 통해서 더욱 더 빠르게 최적화할 수 있다.

Ghost CMS 를 활용한 블로그로 넘어온지 약 3개월 정도 되어간다. 최근까지 글을 잘 올리지 않다가, 다시 쓸 만한 글들이 있어서 쓰고 있다.

초기에 도입할 당시에는 Self-host 가 가능한 것, 내 마음대로 주무를 수 있는 것을 강점으로 생각하고 도입했다. 그런데, 생각보다 꽤나 불편한 것들이 많다.

Blog 를 위한 CMS 가 아니다.

Ghost 는 블로그를 만드는 사람을 위주로 만들어지지 않았다. 오히려 상업 사이트를 만드는데 최적화되어있다. 예를 들어 멤버십 기능이라던가, 다중 유저가 포스트를 작성할 수 있도록 유저 목록을 유지할 수 있다거나... 아무튼 상업 사이트에서 적극적으로 활용할 수 있는 기능들이 많다.

그러나, 블로그를 대상으로하면 기능이 꽤나 부실하다. 블로그의 기초인 Category 기능부터 없다. Tag를 통해서 직접 분류하도록 해야하며, Category 처럼 보이기 위해서는 theme 을 직접 건드리면서 tag 를 요리조리 볶아야한다. 댓글 기능도 기본으로 지원하지 않으며, TOC (목차) 도 직접 넣어주어야한다. (괜히 기성 블로그 플랫폼을 사용하는 것이 아니다.)

물론, 자유도가 꽤 높은 편이기에 직접 theme 을 만들기 시작하면 좀 달라질지도 모르겠다. 다만, Ghost 에 맞는 프론트 뷰를 뿌리기 위해서 자체 API 에 대한 학습, 활용이 필요하다. 여간 귀찮아서, 그냥 제공해주는 기본 theme 을 사용 중인데, 수정 없이 블로그로 사용하기에는 많이 부족하다.

Free Theme / Blog 를 위한 Theme 이 부족하다.

WordPress 를 사용했다면 어땠을까? 하는 생각이 드는 부분이 바로 이것이다. WordPress 에 비하면 내가 선택할 수있는 theme 에 대한 선택지가 너무나 좁다. 특히 앞서 언급했듯, Blog 를 위한 CMS 가 아니다보니 유료 Theme 조차도 블로그보다는 상업 사이트들에 맞춰져있다. 종종 Free Theme 을 찾을 수는 있기는 하나, Ghost 버전이 맞지 않는 경우가 많으며 언어 때문인지 Ghost 버전 때문인지 모를 호환성 문제가 있다.

Self host 의 약점

Self-host blog 는 이번이 처음인데, 굉장한 약점이 있다. SEO 가 안된다. 그냥 내 블로그가 구글, 네이버에 노출 자체가 안되고 있다. 그냥 사람이 나 빼고 안온다 -_-; 광고 수익을 기대한다거나, 특별히 널리 알리고자 하는 의도는 없어서 크게 상관없기는 하지만, 이왕 열심히 작성한 글 많은 사람들이 보면 좋지 않은가?

아무래도 내 블로그의 경우에는 완전히 새로운 도메인으로활동하며, 이전의 일부 문서를 가져오며 중복된 게시물로 사이트 평판이 낮기 때문으로 보인다. 이런 문제를 가볍게 블로그하면서 따로 신경쓰기에는 상당히 골치아프다. 상업적인 목적을 가진다면 완전 비추다. 플랫폼 위에서 노는 이유가 다 있다.

그럼에도 좋은 점

Markdown 기반으로 작성이 편하다. 최근 Obsidian 으로 기록을 하고 이 쪽으로 넘기면서 글을 작성하고 있는데, 이런 면에서 굉장히 편리하다. 그냥 native 하게 지원하기에 머리아플 일이 없다.

또한 Ghost API 를 통해서 Obsidian 에서 바로 글을 넘길 수도 있다. 이미지까지 넘기지는 못해서 잘 사용하지는 않기는 하지만, Obsidian 과의 연동성, 그리고 API 를 활용해서 더 많은 것을 할 수 있다는 점이 꽤나 인상깊었다.

unsplash 와 연동되어 이미지를 빠르게 삽입할 수 있는 것도 꽤나 큰 장점이다. 테마에 따라 다르나, 가볍게 thumbnail을 가져와서 쓸 수 있다. (이쁜 블로그만들기에 좋다. ㅋㅋ) 아마, 상업적 활용에 목적을 두고 있어서 추가한 기능으로 보인다.

앞으로..

넘어오는게 꽤 귀찮은 작업이었고 지금 보기에는 WordPress 말고는 딱히 넘어갈만한 대상도 없다. 제대로 활용하려면 Theme 을 하나 직접 만들어봐야할 것 같은데, 여기에 투자할 만큼 시간이 넉넉하지는 않다. 최대한 심플하면서 블로그 기능을 갖춘 형태로 언젠가 한번 자체 제작하고 Open 해둬봐야겠다.

인증 인가와 상태 반환 코드

요구사항

• HTTP 표준과 부합해야한다.
• Client 입장에서 처리하기 편리해야한다.
• 보안을 고려해야한다.

고려대상

• 인증에 실패할 경우 항상 401 (Unauthorized)
• 상황에 따른 HTTP Status code
  • 인증 정보가 있는 경우
    • 성공
    • 실패
      • 잘못된 정보로 인증 하는 경우
      • 유효한 인증이나 접근이 불가능 한 경우
        • 403 ? 404 ?
  • 인증 정보가 없는 경우

의사결정

• 상황에 따라 HTTP Status code 를 분리해서 나타내야한다.
• 잘못된 인증 정보(만료된 토큰과 같은 경우)에 대해서만 401 Unauthorized 로 처리한다.
  • 만약 모든 비인가 상태에 대해서 401 Unauthorized 로 보낼 경우 다음과 같은 문제가 발생할 수 있다.
    • 우선 401 Unauthorized 의 경우 인증 과정의 이슈 를 나타내는 상태코드이다. 따라서, 이는 token 만료 혹은 잘못된 인증 정보에 대한 응답이 적합하다.
      • 잘못된 정보로 인증을 시도한 것 같아 라는 응답에 적합하다.
    • 반면 403 Forbidden 혹은 404 Not Found 은 해당 자원에 대한 접근에 대한 처리이다.
      • 403 Forbidden 의 경우 네가 누구인지는 아는데, 이러한 이유로 이 자원에 접근할 수 없어. 라고 명시적으로 클라이언트에게 알린다.
      • 404 Not Found 의 경우 (네가 누구인지 아는데 해당 자원에 어차피 접근 못할거니까) 그냥 없는 페이지라고 알려줘야겠다. 라고 생각하면 된다. 아래 설명하겠지만, 보안적으로 이 편이 낫다.
• 권한 문제로 인해 접근이 불가능한 경우에는 404 Not Found으로 처리한다.
  • 의미적으로는 403 Forbidden 이 적합할 수 있다. 그러나, 보안적인 측면에서는 404 Not Found 를 전달하는 것이 더 유리하다.
  • 403 Forbidden
    The server understood the request, but is refusing to fulfill it. Authorization will not help and the request SHOULD NOT be repeated. If the request method was not HEAD and the server wishes to make public why the request has not been fulfilled, it SHOULD describe the reason for the refusal in the entity. If the server does not wish to make this information available to the client, the status code 404 (Not Found) can be used instead.
  • Attacker 입장에서 403 Forbidden 으로 전송받을 경우 유사 경로에 대해서 공격을 감행할 수 있는 근거가 마련될 수 있다. 서버 입장에서는 이러한 공격을 방지하기 위해 이러한 정보를 제공하지 않음으로서 보안을 한층 강화할 수 있다.
    • What is the reason behind marking forbidden pages as 404?
    • Security through obscurity
    • When Should You Return 404 Instead of 403 HTTP Status Code
  • Security through obscurity 에 대한 예시를 하나 들자면 이런 느낌이다.
    • 영화 '아저씨'를 보면, 특별한 과거를 가진 원빈의 정보에 대해서만 특별히 접근 권한을 제한했다. 경찰들은 이를 통해서 원빈에 대해서 이 사람 무언가 있다! 라고 추측을 할 수 있었다. 그리곤 알다시피 특별한 방법(?)를 동원해 그의 정보를 얻어냈다.
    • 만약, 해당 인물에 대해서 조회했을 경우 이런 사람 없는데요? 라고 조회 결과를 보여줬다면, 경찰들은 우리가 잘못 조회한건가? 우리 데이터베이스에 없는 사람인가? 아니면 이 사람 특별한 사람인가? 라고 여러 방식으로 생각한다. 일반적으로는 잘못 조회한 것 같네 가명을 쓰나? 성형했나? 뭐지? 라고 생각하며 그의 정보를 찾는데 어려움을 겪었을 것이다.
  • 따라서, 접근 불가능한 사용자가 경로에 대한 추측을 할 수 없도록 404 Not Found를 응답한다.
    • 다만, 서버 내에서는 이를 단순 Not Found 와 같은 로그를 남기기보다는 잘못된 유저의 접근임을 명확하게 남기자.

PassportJava

• 새로운 프로젝트에서 인증, 인가 과정에 Spring Security 를 사용하는 것이 적합하다는 의사결정을 내리기는 했으나, NestJS 를 통해 백엔드를 구현했던 입장에서는 Spring Security의 사용에 다소 불편함이 있었다. 때문에, Java + Spring 에서 NestJS Style (AuthGuard + Passport.js) 으로 인증 / 인가 프레임워크를 제작해보고 Spring Security 와의 장단점을 비교해보고자 했다.
• 내가 구현하고자 하는 시스템(?)의 목표는 다음과 같다.
  • NestJS 와 같이 @AuthGuard(Guard) 와 같은 형태로 Controller 의 method 에 대해서 가볍게 Auth 과정을 표현할 수 있을 것.
  • AuthGuard 의 경우 Strategy 의 선택을 통해서 Guard 의 작동 방식을 선택할 수 있어 유연성을 가질 수 있을 것. (Strategy pattern 적용)
  • Guard 에서 처리한 정보를 이후 Method 에서 사용할 수 있도록 Parameter를 통해서 주입할 수 있도록 할 것.
  • 사용자 입장에서는 Guard, Strategy의 정의만으로 쉽게 Auth 과정을 정의할 수 있을 것.
• Passport.js 의 구조와 NestJS 의 구조를 따라했다는 점에서 PassportJava 라는 이름을 붙여보았다.

구조

• Controller의 method를 대상으로 Request 처리 이전에 intercept하여 실행할 로직을 결정하는 시스템이다. 해당 시스템은 @UseGuards, @Guard 를 통해서 Guard를 선택하여 method에 적용할 수 있으며, 로직의 정의는 Strategy 를 통해 수행한다.

@Guard

• Controller 에서 사용자가 request 이전에 인증 / 인가 과정에 사용할 Guard를 선택할 수 있도록 하는 annotation 이다.
• 사용법
  • value = {...<T extends AuthGuard> T.class}
  • args = {...String}
    • 주입할 인자가 없을 경우 입력하지 않고 @Guard(RoleGuard.class) 와 같이 사용해도 된다.

@Guard(value = RoleGuard.class, args = {"ADMIN"})  
public ResponseEntity<UserResDto> getById(@PathVariable("id") Long id)  
	throws NotFoundException {  
	return ResponseEntity.ok(userService.getById(id));  
}

@UseGuards

• Controller 에서 사용자가 request 이전에 인증 / 인가 과정에 사용할 Guard를 여러 개 선택할 수 있도록 하는 annotation 이다.
  • Guard를 여러개 사용하는 것과 다르지는 않다.
• 사용법
  • value = {...Guard.class}
  • args = {...String.class}

@UseGuards({  
	@Guard(JwtGuard.class),  
	@Guard(value = RoleGuard.class, args = {"ADMIN"})  
})
public ResponseEntity<UserResDto> getById(@PathVariable("id") Long id)  
	throws NotFoundException {  
	return ResponseEntity.ok(userService.getById(id));  
}

AuthGuard

• AuthGuard 는 UseGuard 에서 사용할 Guard의 기틀이 되는 abstract class 이다.
• 해당 클래스는 AuthStrategy 를 private member 로 가지고 있으며, 이를 상속하는 모든 Guard 객체는 super(strategy) 를 통해 해당 Guard가 사용하는 Strategy를 결정한다.
  • AuthStrategy 를 통해서 직접 사용할 수 있으나 다음과 같이 구현한 이유는 아래와 같다.
    • Guard 의 경우 어떤 형태의 Auth 과정의 Guard를 적용 함을 의미한다.
      • Guard의 적용은 결국 Controller 의 method 실행 이전 어떤 동작이 실행됨을 적용하는 것이다.
    • 예를 들어, 유저의 로그인 가능 여부를 묻는 인증 과정이라고 하자. 이를 LoginedGuard 라고 하면, 해당 인증 과정에는 JWT 를 사용한 전략이 사용될 수도 있고, Session 을 통한 전략이 사용될 수도 있다. 혹은 또 다른 전략이 선택될 수도 있다.
    • 전략이 변경된 경우에도, 해당 Guard의 역할은 로그인 검증일 뿐이므로, 바뀌지 않는다. 따라서 단순히 해당 유저를 검증하는 전략만 변경 함으로써 코드의 단 한부분만 변경하여 해당 전략의 변경이 가능하다.
    • 만약 그렇지 않다면, @UseGuards({JwtStrategy.class}) 라고 작성된 모든 method를 변경해야할 것이다.
• 해당 클래스를 구현하는 객체는 @Component 를 통해 Spring bean 으로 등록되어야한다. GuardResolver 에서 해당 객체들을 스캔하여 가지고 있어야한다.
• 구현

public abstract class AuthGuard {  
	private AuthStrategy authStrategy;  
	/**  
	* 상속받은 클래스는 반드시 AuthStrategy를 지정해야합니다.  
	*  
	* @param authStrategy  
	*/  
	public AuthGuard(AuthStrategy authStrategy) {  
		this.authStrategy = authStrategy;  
	}  
	  
	public final void check(HttpServletRequest request, String... args) {  
		try {  
			authStrategy.check(request, args);  
		} catch (CustomException customException) {  
			throw customException;  
		} catch (RuntimeException e) {  
			throw new CustomException(ExceptionStatus.UNAUTHORIZED_USER);  
		}  
	}  
}

• 사용법

@Component  
public class RoleGuard extends AuthGuard {  
	  
	public RoleGuard(@Autowired RoleStrategy strategy) {  
		super(strategy);  
	}  
}

AuthStrategy

• AuthStrategy 는 사용자가 정의할 Strategy의 기틀이 되는 interface 이다.
  • 보다 유연하게 전략을 선택하여 Guard 를 정의하도록 하였다.
• 해당 interface 는 AuthGuard 에 주입될 객체를 정의하며, implements 하는 class 는 public void check(HttpServletRequest request, String... args) 를 정의해야한다.
• 이후 해당 전략을 사용하기 위해서는 AuthGuard 를 상속한 객체의 constructor에서 사용할 Spring bean strategy를 주입할 수 있도록 JwtGuard(@Autowired JwtStrategy strategy) 와 같이 정의해야한다.
• 구현

public interface AuthStrategy {  
	/**  
	* Check method는 해당 Auth 작업에 대한 전략을 수행합니다. 만약, 검증 과정에서 실패할 경우 Error를 throw 합니다. 해당 Error는  
	* Exception Handler 에서 처리할 수 있습니다.  
	*  
	* @param request  
	*/  
	public void check(HttpServletRequest request, String... args);  
}

• 사용법

@Component  
public class RoleStrategy implements AuthStrategy {  
	@Override  
	public void check(HttpServletRequest request, String[] args) {  
	// role check  
	}  
}

// JwtGuard 의 정의
public class RoleGuard extends AuthGuard {
  public RoleGuard(@Autowired RoleStrategy strategy) { super(strategy); }
}

GuardAspect

• @UseGuards 를 핸들링하기 위한 ApectJ를 사용하는 class이다. handleUseGuards() 를 통해 해당 annotation 을 선언한 메소드가 실행되기 이전에 Guard 의 Strategy 를 실행한다.
• GuardAspect 의 경우 GuardResolver 를 통해 Guard 객체를 찾아낸다.
• 구현

@Aspect  
@Component  
public class GuardAspect {  
	  
	@Autowired  
	private GuardResolver guardResolver;  
	  
	@Before("@annotation(useGuards)")  
	public void handleUseGuards(UseGuards useGuards) {  
		final HttpServletRequest request = ((ServletRequestAttributes) RequestContextHolder
		.currentRequestAttributes())
		.getRequest();  
		final List<Guard> guards = Arrays.stream(useGuards.value()).toList();  
		for (Guard guard : guards) {  
			AuthGuard authGuard = guardResolver.getGuard(guard.value().getSimpleName());  
			authGuard.check(request, guard.args());  
		}  
	}  
	  
	@Before("@annotation(guard)")  
	public void handleGuard(Guard guard) {  
		final HttpServletRequest request = ((ServletRequestAttributes) RequestContextHolder  
		.currentRequestAttributes()).getRequest();  
		final AuthGuard authGuard =  
		guardResolver.getGuard(guard.value().getSimpleName());  
		authGuard.check(request, guard.args());  
	}  
}

GuardResolver

• Spring Bean 으로 등록된 객체 중 AuthGuard 타입의 객체를 찾아 저장하고, 이를 이후에 GuardAspect 에 전달하는 역할을 수행한다.
• 구현

  
@Component  
public class GuardResolver {  
	  
	private final Map<String, AuthGuard> guards;  
	  
	public GuardResolver(List<AuthGuard> guards) {  
		this.guards = guards.stream()  
			.collect(  
				Collectors.toMap(  
				g -> g.getClass().getSimpleName(),  
				Function.identity()  
			));  
	}  
	  
	public AuthGuard getGuard(@NonNull String guardName) {  
		return this.guards.get(guardName);  
	}  
}

UserData

• Guard 를 통해서 Session 혹은 JWT 정보를 가져올 수 있다. 해당 경우를 위한 지원으로 HttpServletRequest 객체를 통해서 유저의 데이터를 parameter 를 통해 주입하는 역할을 수행하는 annotation 이 필요하다.

@UserData

• Guard 에서 주입된 정보를 사용하며, 이 정보는 HttpServletRequest 의 USER_DATA attribute 를 기본으로 한다. 만약 다른 형태의 attribute 를 사용하고자 하는 경우, @UserData 의 value 값을 지정해야한다.
  • 해당 값은 외부 Configure 을 통한 주입을 추천하며, HttpServletRequest 의 attribute 와 겹치지 않도록해야한다. SNAKE_CASE(UPPER CASE) 를 추천한다.

예시

• Guard

@Component  
public class JwtStrategy implements AuthStrategy {  
	@Value("jwt.data.name")  
	private String dataName = "JWT_DATA";  
	  
	@Override  
	public void check(HttpServletRequest request, String... args) {
		String token = getTokenFromRequest(request);
		request.setAttribute(dataName, token);  

	}  
	  
	private String getTokenFromRequest(@NonNull HttpServletRequest request) {  
		// Get Bearer token from authorization  
		return request.getHeader(HttpHeaders.AUTHORIZATION);  
	}  
}

• UserData 적용

// controller code
@Value("jwt.data.name")
private String jwtDataName;

//...

@GetMapping("/{id}")
public boolean someMethod(
	@PathVariable("id") Long id,  
	@UserData(jwtDataName) String token, // token is injected
	@UserData JwtData data // value 없이도 가능. default "USER_DATA" 사용.
	) throws NotFoundException {
	return ResponseEntity.ok(userService.getById(id, token));  
}

UserDataAspect

• @UserData 를 핸들링하기 위한 ApectJ를 사용하는 class이다. handleUserData() 를 통해 해당 annotation 을 선언한 parameter 값에 해당 Object 를 주입한다.
• 해당 annotation을 사용할 때 반드시 Strategy에서 사용하는 타입과 일치해야한다.
• 구현

@Aspect
@Component
public class UserDataAspect {

  /**
   * TokenData annotation 을 적용한 Parameter 에 대해서 Request의 TokenData Attribute 를 가져옵니다. Pointcut :
   * method(params.., @TokenData(Type data), params..)
   * <p>
   * TokenData 의 경우 v
   *
   * @param joinPoint
   * @return
   * @throws Throwable
   */
  @Around("execution(* *(.., @com.ticketwar.ticketwar.auth.pass.UserData (*), ..))")
  public Object handleUserData(ProceedingJoinPoint joinPoint)
      throws Throwable {
    final Signature signature = joinPoint.getSignature();
    final MethodSignature methodSignature = (MethodSignature) signature;
    final Method method = methodSignature.getMethod();
    final Parameter[] parameters = method.getParameters();
    final Object args[] = joinPoint.getArgs();
    final HttpServletRequest request = ((ServletRequestAttributes) RequestContextHolder
        .currentRequestAttributes()).getRequest();

    for (int idx = 0; idx < parameters.length; ++idx) {
      UserData userData = parameters[idx].getAnnotation(UserData.class);
      if (userData != null) {
        args[idx] = request.getAttribute(userData.value());
        break;
      }
    }
    return joinPoint.proceed(args);
  }
}

JWT 적용하기

JWT 의 경우 auth0:java-jwt 라이브러리를 활용하였다.

(단순한 PassportJava 적용 예시)

JwtConfigure

• Spring Bean 으로, 외부 변수를 주입하기 위함이다.
  • jwt.data.name
    • @UserData 에 저장할 request 의 attribute 이름을 지정함.
  • jwt.secret
    • JWT secret 지정.

@Component
public class JwtConfigure {
  @Value("${jwt.data.name:USER_DATA}")
  private String dataName;

  @Value("${jwt.secret}")
  private String secret;

  public String getDataName() {
    return dataName;
  }

  public String getSecret() {
    return secret;
  }
}

JwtUtil

• SpringBean (Configure 사용 및 타 Bean 에서 autowire 사용을 위함.) 으로, JWT 토큰 획득 과정과 관련된 method를 담는다.
• verifyTokenFromRequestAuthorizationHeader
  • HttpServletRequest 로 부터 Bearer Token 을 획득하고, 이를 JwtData 형태로 변환한다.
• 이후 다른 형태로 JWT 가 필요할 경우, 해당 형태로 가져와서 사용할 수 있도록 method를 추가할 것이다.

@Component
public class JwtUtil {
  private final String BEARER = "BEARER ";
  @Autowired
  private JwtConfigure jwtConfigure;

  /**
   * Verify Authorization header's bearer token.
   * <p>
   * if fails, it throws RuntimeException.
   *
   * @param request
   * @return
   */
  public JwtData verifyTokenFromRequestAuthorizationHeader(HttpServletRequest request) {
    final String bearerToken = request.getHeader(HttpHeaders.AUTHORIZATION).substring(BEARER.length());
    final Algorithm algorithm = Algorithm.HMAC256(jwtConfigure.getSecret());
    final JWTVerifier jwtVerifier = JWT.require(algorithm).build();
    final DecodedJWT decodedJWT = jwtVerifier.verify(bearerToken);

    return getJwtDataFromDecodedJwt(decodedJWT);
  }

  private JwtData getJwtDataFromDecodedJwt(DecodedJWT decodedJWT) {
    final Claim id = decodedJWT.getClaim("id");
    final Claim email = decodedJWT.getClaim("email");
    final Claim nickname = decodedJWT.getClaim("nickname");
    final Claim role = decodedJWT.getClaim("role");

    return JwtData.builder()
        .id(id.asLong())
        .email(email.asString())
        .nickname(nickname.asString())
        .role(role.asString())
        .build();
  }
}

JwtStrategy

@Component
public class JwtStrategy implements AuthStrategy {
  @Autowired
  private JwtConfigure jwtConfigure;
  @Autowired
  private JwtUtil jwtUtil;

  @Override
  public void check(HttpServletRequest request, String... args) {
    final JwtData jwtData = jwtUtil.verifyTokenFromRequestAuthorizationHeader(request);
    request.setAttribute(jwtConfigure.getDataName(), jwtData);
  }

}

JwtGuard

@Component
public class JwtGuard extends AuthGuard {
  public JwtGuard(@Autowired JwtStrategy strategy) {
    super(strategy);
  }
}

개발 과정 중 문제

Spring bean 획득과 new ()를 통한 Object

• AuthGuard 의 설계 초기에는 super(new JwtStrategy()) 와 같은 형태를 통해서 Strategy 를 주입하였다. Spring 과 상관 없이 Strategy 를 제작을 하고자 함이었다.

@Component  
public class JwtGuard extends AuthGuard {  
	  
	public JwtGuard() {  
		super(new JwtStrategy());  
	}  
}

• 그러나 JwtStrategy 를 만들면서, 실패했다. JwtStrategy 의 경우 필연적으로 secret 을 외부로부터 주입받아야하는데, 보통 그 수단으로 Spring의 @Value 를 통해서 값을 주입받는다. 그러나, 이는 Spring bean 에 의해서만 가능하다.
• 따라서 어쩔 수 없이, @Component 를 선언하고, Spring bean 에 등록을 하였으나, jwt.secret 의 값을 제대로 가져오지 못했다. 위 코드를 보면 알 수 있듯, JwtStrategy 를 new 를 통해서 새로 인스턴스를 만들고 주입하기에, Bean 과 관련없는 객체가 주입이되었다.
• AuthGuard 의 constructor 에서 직접 bean 을 찾아 넣는 방식도 시도하였으나, 적절하지도 않으며, 해당 시점에는 ApplicationContext가 완성되지 않아 활용할 수도 없다. (되도록이면 접근하지 않는 것이 맞다고 생각한다.) 이렇게 할 경우, Spring 자체에도 의존성이 생겨버린 상태기 때문에 의미가 없었다.
• 애초에 해당 시스템 자체가 Spring에 의존을 하고 있기 때문에, Strategy를 Component로 등록하지 않을 이유는 없었다. 따라서, 항상 AuthStrategy 구현 객체는 Spring Bean 에 등록하고, @Autowired 를 통해서 이를 등록하도록 했다.
• 결과적으로는 NestJS + Passport 의 방식에 비하면 조금 복잡하기는 하나, AuthGuard 의 유연성을 지키고, 몇 줄 안되는 코드로 AuthStrategy 를 결정할 수 있는 방식이 되었다. 나름 깔끔하게 사용자가 선언할 수 있어 마음에 든다.

@Component  
public class JwtGuard extends AuthGuard {  
	  
	public JwtGuard(@Autowired JwtStrategy strategy) {  
		super(strategy);  
	}  
}

@Guard, @UseGuards에서 arguments

@UseGuards({JwtGuard.class, RoleGuard.class})

• 초기에는 @Guard 없이 @UseGuards 만으로 구성했다. 또한, 인자를 받지 않았다.
• JwtGuard 의 경우, JWT verification 만 하고 끝내면 되니, 특별한 인자가 필요없지만, RoleGuard 의 경우 해당 method 의 접근 권한을 설정해야하기 때문에 문제가 발생한다.
• 또한 다른 custom guard 를 만들 경우에서도 인자를 받을 수 없어 유연성이 부족하다. 권한마다 매번 Guard를 만들 수는 없다.

@Target({ElementType.METHOD})  
@Retention(RetentionPolicy.RUNTIME)  
public @interface UseGuards {  
  
	Class[] value();  
	String[] args();
}

@UseGuards(value = {JwtGuard.class, RoleGuard.class}, args = {null, "ADMIN"})

• 그렇다고, 위와 같이 args를 순서대로 매핑하는 느낌으로 사용하는 것도 바람직하지 않다. 또한 여러 인자를 한 Guard에 전달할 수도 없다.
• 따라서, 각 AuthGuard는 해당 클래스와 인자를 전달하는 @Guard 를 통해서 사용하도록 했다.

@Target({ElementType.METHOD})  
@Retention(RetentionPolicy.RUNTIME)  
public @interface Guard {  

	Class value();  
	  
	String[] args() default {};  
}

• 이를 통해서 Guard 는 각각의 인자를 받아올 수 있게 되었다.
• 또한, 여러개의 Guard를 순차적으로 실행하는 것도 필요하기에 @UseGuards 는 다음과 같이 고쳤다.

/**  
* UseGuards  
*/  
@Target({ElementType.METHOD})  
@Retention(RetentionPolicy.RUNTIME)  
public @interface UseGuards {  
  
	Guard[] value();  
}

@GetMapping("/{id}")  
@UseGuards({  
	@Guard(JwtGuard.class),  
	@Guard(value = RoleGuard.class, args = {"ADMIN"})  
})  
public ResponseEntity<UserResDto> getById(){...}

• 다소 복잡하기는 하나, 필요한 요소들을 모두 표현할 수 있다. 다만, String을 통해서만 인자를 받아올 수 있기 때문에 아쉬운 면이 있다.
  • UserRole.ADMIN 과 같이 설정한다면 더욱 편리할 것이다. 하지만, annotation에서 Enum의 경우 특정해야만 사용 가능하여, 다양한 형태를 받아야하는 현재로서는 어쩔 수 없었다.

Spring Security 와의 비교

직접 구현 이전에는, Spring security 의 예시만 알고 있기 때문에 직접 개발한 형태의 방식은 어떤 장점과 단점을 가질 지에 대해서 명확하게 정의를 내리기 어려웠다. 직접 구현 이후 Spring security 의 적용에 비해서 가질 수 있는 장단점을 간략하게 생각해보았다.

장점

• 상대적으로 쉽다.
  • 이는 자체적으로 구조가 단순하기 때문이다. Spring security 의 경우 다양한 보안 관련 기능을 지원해야하고, 이로 인해서 어쩔 수 없이 복잡한 구조를 가져야한다. (실제로 사용자가 사용하지 않는 기능들 까지 담아야하므로...) 반면, 해당 PassportJava 의 경우 Controller method의 실행 이전 intercept 하여 실행할 내용을 정의하는 것을 지원하는 것 뿐이다. 구조적으로 단순하니, 쉬울 수 밖에 없다.
  • 또한, 개발자가 직접 해당 기능에 대한 작동을 정의하기 때문에 상대적으로 그 코드를 작성한 개발자에게 있어서는 이해가 쉬울 것이다. 그러나, 팀 단위로 개발하는 환경을 고려하면 정형화되어 있는 형태로 작성해야하는 생태계 (Spring security)가 오히려 코드와 구조를 이해하는 측면에서는 나을 것 같다.
• 직접 제어 가능하다.
  • Spring security 와 같은 형태의 이미 주어진 프레임워크에서는 어쩔 수 없이, 제한된 환경에서 해당 구조에 알맞게 코드를 작성해야한다. 물론 어느정도 유연하게 작성할 수는 있겠으나, 프레임워크가 제공하는 시점 아래에서 코드가 작성되어야하며 디테일한 조정은 불가하다.
  • 반면, 이렇게 직접 작성하는 경우 개발자가 원하는 방식으로 모두 제어할 수 있다. "불만이 있으면 직접 뛰던가" 의 예시...? 결국에는 Spring Security 가 등장하기 이전에는 어쩔 수 없이 이렇게 코드를 작성해야한 했을 것이다.

단점

• 다양한 기능 지원의 부재
  • "쉽다/단순하다" 에서 비롯되는 어쩔 수 없는 단점이다. 필요한 기능이 있을 경우 개발자가 직접 지원하도록 만들어야한다. 시간적인 측면에서 문제가 있다.
• 안정성
  • 거대하고 안정된 커뮤니티에서 만들어진 프레임워크를 사용하는 것에 비하면 안정성에서 확실하지 않다. 이는 이러한 형태의 시스템을 만드는 사람에 따라 다르겠으나, 아무래도 Spring Security 에 비하면 부족함은 사실이다.
• (내 구조의 경우) 여전히 Spring에 의존한다.
  • Spring bean 이 되어 해당하는 AuthGuard를 찾아내고, 적합한 Strategy를 주입한다. 이로 인해 Spring 으로부터 독립된 패키지가 아니다. 다른 Java 의 Framework 에 적용할 수 없다.
• 결국에는 Spring Security 형태를 따라갈 수 밖에 없다.
  • 이번에 PassportJava를 만들어내면서, Spring security 의 등장에 대해서 생각해보았다.
• Spring Security 이전에는 Spring scope 내에서 처리하기 위해서는 PassportJava 와 같은 형태로 제작을 해야만 했을 것이다.
• 혹은, Spring Security 와 마찬가지로 Servlet 에 직접 접근하여 Filter 를 사용하는 형식을 취할 것이다. 이런 형태의 최종 추상화가 바로 Spring Security 형태이다.
• 개발자가 원하는 형태의 사용자 인증 Process 는 결국 비슷하다. 다양한 형태의 인증 프로세스를 범용적으로 지원하기 위한 고민을 Spring security 에서 나름의 정답을 내놓은 셈이다. 더 나은 프로세스가 존재할 수도 있지만, 결국에는 유사한 형태의 결과가 만들어지곤한다.
• 특별히 더 나은 형태의 구조의 발상이 있지 않다면, 누구나 접근할 수 있으며, 사용법과 구조에 대해 이해가 있는 Spring Security 를 적용하는 것이 생산성 측면에서 더 유리하리라 생각한다.

테스트에서의 문제

• 해당 라이브러리는 AspectJ 를 활용해서 Method가 실행되기 이전 intercept 하여 실행한다.
• 이는 Controller 영역의 테스트에서 문제가 발생한다. Test 를 위한 지원이 포함되어있는 Spring Security 와 달리, 해당 라이브러리는 Test 를 할 때 Intercept 하고, argument 를 주입하는 영역에 대해 개별적으로 mocking을 하거나 하는 방식으로 처리를 해야한다.

@Test
void something() {
  // 이런 방식으로 Strategy 의 동작과 Resolver 의 동작을 구성해야함...
  BDDMockito.doNothing().when(jwtStrategy).check(any(HttpServletRequest.class));
      BDDMockito.given(userIdArgumentResolver.supportsParameter(any())).willReturn(true);
      BDDMockito.given(userIdArgumentResolver.resolveArgument(any(), any(), any(), any()))
}



꽤 어린 시절부터 블로그를 했었다. 햇수로 치면 15년 정도 되는 것 같은데, 약 3~5년 정도의 주기로 이번처럼 새로운 플랫폼에서 새로운 시작을 하곤 한다. 이전 블로그는 티스토리에서 https://photogrammers.tistory.com 으로 운영하고 있었고, 개발자의 길로 접어든 때에 시작을 했던 블로그이다.

티스토리 블로그는 큰 목적성을 두고 만든 블로그보다는 배운 내용들을 기록하는 용도로 활용했었고, 블로그 내에 의미가 없는 내용의 글 (코테 문제 풀이, 간략한 회고 등)이 많았다. 알찬 내용의 글들을 주로 싣고 싶었는데 목적이 섞이다보니 글 포스팅이 좀 애매해졌다. 때문에 주로 신경써서 쓴 글들은 Notion 을 통해서 작성하고 팔만코딩경을 통해서 올렸는데, 이게 내 블로그로의 유입은 줄이고 그 쪽으로의 유입만 올리는 꼴이라서 이것대로 고민이었다.

티스토리 자체도 사실 맘에 들지는 않았다. 노션을 사용하고부터 마크다운으로 주로 글을 작성했는데 티스토리에서는 이게 상당히 불편했다. 적당히 스킨 갈아 끼워보고 이래저래 해봐도 에디터의 근본적인 특성상 해결할 수는 없었다.

또한 티스토리에 2차 도메인을 붙이고 이전 포스팅과 현재 포스팅이 구글 엔진에서 겹치는 바람에 구글 검색에서 완전히 망해버렸고, 사실상 망한 블로그가 되어버렸다. ㅠㅠ..

그러던 와중 티스토리에서 해당 블로그가 약관 위반으로 인해 차단까지 당했다. 2차 도메인으로 강제 리다이렉트를 시키는 스크립트가 티스토리 약관 위반이었고 (해도 되는줄 알았지...) 블로그 글조차 조회를 할 수 없게 되어버려 그냥 기회다 싶어서 셀프 호스팅을 하는 방향으로 CMS 를 찾아보게 되었다.

CMS 선정하기

velog, medium 을 사용하거나 아니면 github.io 를 통한 블로그를 만드는 것을 처음에 고려했다. velog, medium의 경우 충분히 깔끔하기는 하나 "내 블로그" 를 만드는 개념이라기 보다는 해당 플랫폼에 글을 기고하는 느낌이기에 자유도 면에서 부족했다. 반면, 깃허브 블로그의 경우에는 자유도가 상대적으로 높다는 장점이 있지만, 그 자유도를 위해서 스스로 만들어야하는 것이 꽤나 많다는 것, 그리고 셀프 호스팅을 이번에 해보고 싶었다는 점에서 제외하게 되었다.

따라서, 목적에 맞게 만들기 위해서는 CMS 를 사용해야하는데 대표적으로 Word Press 가 있었고 또 하나의 대안으로 찾은 것이 Ghost CMS 였다. 디자인도 깔끔하고, 문서화도 잘 되어있고, 금방 올려서 사용하기도 편하고.. 여러모로 마음에 들어서 Ghost 를 채택했다. (그냥 왠지 끌렸다.)

Ghost 올리기

Ghost를 올리는 과정은 그닥 어렵지 않다. 나는 애초부터 Ghost 를 Docker 를 통해서 호스팅하고자 했기 때문에 그냥 compose 파일 하나 구성하고, 볼륨정도 잡아준 뒤 올리면 끝이다.

다만, 아무래도 블로그다보니 항상 서버가 켜져있어야하고 전력을 덜먹는 ZBOX nano에 고스트를 올려두었는데 이로 인해서 블로그가 상당히 느린 문제가 있어 아래 글들과 같은 삽질을 해야했다. 혹시나 Ghost 를 셀프호스팅 한다면 너무 저사양으로는 기대하지 말길..

내 Ghost blog는 왜 느릴까? - (1)

Ghost 블로그로 옮기고 이상한 문제를 발견했다. 블로그가 너무 느리다는 것. 내 블로그는 대체 왜 느린걸까? 하나 하나 짚어가며 해결하는 과정을 기록해보았다. 문제 상황 일단 속도 저하를 크게 두 가지 경우로 나눌 수 있었다. 문제상황 1 - 첫 로드 상황 특정 페이지에 완전히 첫 접근하는 경우에 문제가 발생했다. 한 포스팅 혹은

PhotogrammerSungjun Park

내 Ghost blog는 왜 느릴까? - (2)

앞선 글에서 느린 Ghost blog 의 원인을 찾고 개선(?)을 했다. 남겨진 문제를 해결하는 과정을 살펴보자. 남겨진 문제 서버 시작 후 첫 접근에서 8~10 s 의 시간이 소요되는 문제가 발견되었다. 그러나, 따로 ”서버 시작 후 첫 로딩이 엄청 느려요” 라는 문서를 찾아볼 수는 없었다. 답답한 마음에, 서버포럼으로 가서 질문글을

PhotogrammerSungjun Park

애초에 글을 모두 가져올 목적은 없었기에 2022 년 이후 작성한 기술 관련 글만 별도로 티스토리에서 가져왔다. 옮길 때 사진을 직접 가져와야한다는 점 제외하고는 딱히 문제가 있지는 않았다. (글 백업도 막혀서 다 들고올 수도 없었다...)

입맛대로 바꾸기

나름 스스로 건드릴 수 있는 부분이 꽤 있다. 티스토리와 깃허브 블로그 사이의 어딘가 느낌이다. 스킨 만드는데는 큰 취미가 없기에 그냥 적당히 필요한 것들만 넣어주었다.

카테고리(?) 만들기

Ghost 에서는 따로 카테고리 기능이 없다! 대신 태그를 사용한다. 내 블로그 상단에 "서버 개발 일상" 이런 것들도 그냥 태그 모아보기일 뿐이다. 티스토리의 경우 계층화되어있어서 편리했는데 조금 아쉽긴 하다. 다만, 오히려 태그로 분류하니 홈서버 - 개발 과 같이 겹치는 요소들을 동시에 각각에 둘 수 있어서 편하기도 하다.

아무튼, Admin에서 태그 생성하고 Navigation 에서 /tag/{tag_name} 으로 추가하여 네이게이션 바 위의 카테고리 느낌으로 살릴 수 있다.

About 페이지의 경우 "Post"가 아니라 "Page" 를 사용했다. Post는 일반적인 article 느낌이며 feed 에 등록이 된다. 반면 page 는 post 의 일종이나, feed 에 등록이 되지 않고, 직접 링크를 걸어서 들어갈 수 있다. 그래서 about 도 딱히 피드에 등록될 필요도 없고 독립적인 하나의 페이지라고 생각하여 이를 적용했다.

기본으로 추가 할 만한 기능

Ghost 블로그에서 필요하지만 없는 기능들은 요 정도가 있다.

• 코드 문법 강조
• 댓글 (멤버 등록해야지 쓸 수 있음)
• 목차

각각 다음과 같이 해결했다. 아래 링크도 같이 첨부해뒀다.

• prism syntax highlight
  • '```' 으로 만드는 코드 블럭에 대해서 문법 강조
  • Code injection 에서 스크립트 추가

ghost cms 에 prism js 로 구문 강조(syntax hightlight) 하기

기록은 기억을 지배한다.

• giscus
  • github discussion 을 통해서 댓글을 달 수 있음.
  • hbs 파일 수정

giscus

A comments widget built on GitHub Discussions.

giscus

• tocbot
  • 기본으로 제공하지 않는 목차 생성
  • Code injection + hbs 파일 수정

How to add a table of contents in Ghost without editing the site template

How to add a table of contents in Ghost without editing the site template

Ran DingRan Ding

별도로 운영과 관련하여 추가할 것들...

• Search console 동록
  • 구글 검색엔진에 긁혀야하니까 미리미리 추가를 해뒀다.
• Google analytics 등록
  • Pro 버전에서는 관련 통계 정보를 제공하는 것으로 알고있다. 그러나 직접 호스팅하는 경우에는 필요하다.
• Ghost SMTP 이메일 발송 설정
  • 설정 안해두면 나중에 어드민 계정 잃어버리면 골치아파진다. 기본으로는 mailgun 이라는 친구를 사용하라고 하는데, 이는 뉴스레터같은 것들을 보낼 때 목적성이 크다. 그냥 gmail 통해서 보내면 된다.

ghost에 구글 SMTP 설정하기

ghost 폴더에 있는 config.production.json 위 파일을 수정해야 합니다. 16번째 줄을…

WoosungWoosung

이미지 최적화를 위한 이미지 포멧 설정

Ghost 의 경우 자체적으로 이미지 최적화 기능도 제공한다. 내부 코어에서 자체적으로 클라이언트의 환경에 따라 더 작은 사진을 제공한다. (모바일에서는 w400, 데스크탑에서는 w2000으로...) 여기까지는 대부분 기본으로 설정이 가능하다. 다만, 해당 기능이 켜져있으면 서버에서 같은 이미지를 여러 사이즈로 만들어 내부 디스크 용량을 더 사용한다.

그리고 Ghost 5.7에서 만들어진 기능이 있는데, avif, webp 와 같은 포멧으로 보낼 수 있다면 해당 포멧의 사진으로 보내주는 기능이다.

Updated img_url helper: convert image formats automatically

In Ghost 5.7.0, we updated the functionality of the img_url helper: it now can convert image formats automatically! This update is perfect for theme developers who are serious about performance 🏎 Why it’s important Images are the heaviest part of your website. The new helper automatically converts an image from PNG, GIF, or JPEG to WebP, which reduces its size by ~25% without any visible loss of quality. Using the new helper will make your website faster, positively impact SEO, and…

Ghost ForumRyanF

이 기능을 사용하면 커버 이미지 / 포스팅 카드 이미지등 자주 노출되는 이미지에 대해서 작은 사이즈로 클라이언트에게 전송할 수 있다. 실제로 이를 통해 75kb 의 파일을 2kb 까지 줄여서 보낼 수 있었다.

(적용하느라 꽤 삽질을 했는데 <picture> 태그 안쪽에 <source> <img> 를 같이 사용했어야했다. HTML 알못... )

내 글에는 다이어그램을 excaildraw 를 통해서 png 로 복사해서 오거나, 맥의 캡쳐 기능을 통해서 넣는 경우가 꽤 있는데, 이렇게 넣은 파일이 너무 크기에 글 자체의 사이즈가 커지는 문제가 있었다. 그래서 해당 기능을 글 안에 있는 이미지에도 적용이 가능한지 이래저래 삽질을 해봤는데 결국 실패했다. 포럼에도 다음과 같이 물어봤는데 안된단다. (에디터 자체에서 만드는거라 어쩔 수가 없다. 그냥 자체적으로 사이즈에 따라 주는거에 만족하자..)

Is it possible to format via img_url for images included in content added via Editor?

I’m looking at that feature and trying to change the image format to serve it to the user. I modified the img_url that exists in the hbs file of the theme as suggested in the guide, and in that case, it is being sent to the user as an avif file or webp file as normal. However, it doesn’t seem to work for images added via the editor (both snippet and pasting images from the editor). I have not been able to find any relevant information or code on this either. How is it possible to send webp…

Ghost ForumJuneParkCode

해결 중인 문제

고스트 블로그 쓰면서 다 좋은데 지금 하나 맘에 안드는 것이 있다. 크로미움 계열에서 작성한 글을 Safari에서 읽으면 종종 이상한 문자가 보인다. 이래저래 테스트를 해봐도 도저히 문제가 무엇인지 모르겠어서 일단 포럼에 버그 이슈 등록만 해뒀다. (혹시 해결방안 알면 알려주세요...)

Unknown characters are visible only when using Safari browser + Korean input

Unknown characters are visible only when using Safari browser + Korean input. This only happens when a post containing Korean characters is created in the editor and viewed through Safari browser on Chromium-based browsers. (Same on mobile devices, not visible when viewed on Chromium-based browsers.) I’ve found a few cases through personal testing, but the problem still occurs in unknown cases. Here’s the page I tested for my own purposes. Test with only English input (no problem) Unknown C…

Ghost ForumJuneParkCode

사용 후기

꽤 괜찮은 CMS 이다. 처음에 딱 느낀 인상은 각 이러한 블로그 플랫폼에서 좋은 것들만 잘 빼왔다는 것이다. 굉장히 모던해진 티스토리를 직접 돌리는 것 같기도 하고 말이다. 내 경우에는 Pro 버전이 아닌 셀프 호스팅이지만, Pro 버전을 사용하는 것도 꽤 나쁘지 않을 것 같다.

플랫폼 위에서 편하게 검색 유입받을 수 있는 혜택은 날라갔지만, 그래도 직접 올리고 관리해보는 경험이 재밌기도 하고 종종 소스코드도 까보고 하다보니 배우는 것도 꽤 있다. 나름 괜찮은 선택이었다.

Influx DB 와 Grafana 를 통해서 Proxmox 를 모니터링 할 수 있도록 구성했습니다. 기본적으로 제공하는 데이터 이외에도, CPU 온도에 대한 패널을 추가하고 telegram을 통해 알림을 설정하는 과정까지를 담았습니다.

Proxmox 모니터링하기

우선, InfluxDB + Grafana 를 통해서 Proxmox 모니터링은 아래 사이트를 따라가시면 쉽게 해결하실 수 있습니다.

서버포럼 - InfluxDB 및 Grafana로 Proxmox 모니터링하기

안녕하세요. 오늘 열씸히 집에서도 일하고있는 달소입니다. ESXi부터 진행했던 홈서버가 어느덧 Proxmox에서 어느정도 정착을 하고 운영을 잘하고있는상황에서 많은 유저분들께서 Proxmox를 사용하고 계시니 Proxmox…

서버포럼유머&정보

이렇게 세팅을 하고 나면 초기에는 다음과 같은 뷰를 얻을 수 있습니다.

CPU 온도 모니터링 추가하기

사실 이 정도의 정보로도 모니터링하는데 충분합니다.

그러나, 제 경우에 CPU 온도 / VM 별 CPU | Memory 상태 / Docker container 별 상태를 한 곳에서 보고 싶었습니다.

특히, CPU 온도의 경우 서버를 위한 장비가 아닌 mini PC 를 통해서 작동하고 있는데, ZBOX 의 경우 팬 조차 존재하지 않는 제품이기에 주기적인 모니터링이 필요했으며 , X300 의 경우 소음으로 인해 팬 속도 제한을 걸어둔 상태인데 예상보다 CPU 온도가 너무 치솟을 경우 이 속도를 추후에 조절하고자 모니터링이 필요했습니다.

또한, 해당 방법을 잘 응용하면 CPU 사용량과 온도 그리고 메모리 사용량을 Router로 부터도 수집하여 제 서버를 구성하는 장치들의 상태를 일괄적으로 Grafana를 통해서 확인할 수 있을 것을 기대하고 작업을 시작했습니다.

다행히 시스템의 장치 온도를 얻어서 Influx DB 로 송신하는 툴은 이미 존재합니다. 아래 레포지토리를 가시면 확인하실 수 있습니다.

GitHub - MightySlaytanic/pve-monitoring: Proxmox VE temperature and disk-health stats upload to influxdb2

Proxmox VE temperature and disk-health stats upload to influxdb2 - GitHub - MightySlaytanic/pve-monitoring: Proxmox VE temperature and disk-health stats upload to influxdb2

GitHubMightySlaytanic

위 레포와 함께 아래 가이드를 따라하면, 최종적으로 이렇게 작동하게됩니다.

가이드도 잘 작성된 상태라서 해당 가이드를 쭉 따라가시면 CPU 온도를 얻어내실 수 있습니다. (스크립트 자체도 단순합니다.) 다만, 제 경우에 X300 에서 Ryzen 4750G 를 사용하고 있는데 해당 툴에서 정의해둔 규격과는 다소 다릅니다. AMD 의 경우 CPU Core 에 대한 정보, PCH 에 대한 정보들이 따로 존재하지 않습니다. 때문에 일부분 수정해야합니다.

제 경우에는 Core 에 대한 온도는 크게 의미 없으며, 통합적으로 정보를 얻어내기면 하면 되기에 스크립트를 일부 수정했습니다.

스크립트 고치기

• pve_temp_stats_to_influxdb2.py

#!/root/scripts/venv/bin/python3

# Note about python shabang string above: if you're running on a Debian 11
# system use the standard "#!/usr/bin/python3" string while if you are on
# a Debian 12 system you need to create a virtual-env with influxdb_client
# and use the shabang string pointing to the python3 interpreter within
# the virtual-env, such as "#!/root/scripts/venv/bin/python3"
#
# For example, to create the virtual-env in /root/scripts/venv and install
# the required package do the following:
#
# python3 -m venv /root/scripts/venv
# . /root/scripts/venv/bin/activate
# pip3 install influxdb-client
# deactivate

import re
import sys
import json
import argparse
from datetime import datetime
from os import getenv
from subprocess import run,PIPE

from influxdb_client import InfluxDBClient
from influxdb_client.client.write_api import SYNCHRONOUS
from influxdb_client.client.exceptions import InfluxDBError

INFLUX_HOST = getenv("INFLUX_HOST")
INFLUX_PORT = getenv("INFLUX_PORT")
INFLUX_TOKEN = getenv("INFLUX_TOKEN")
INFLUX_ORGANIZATION = getenv("INFLUX_ORGANIZATION")
INFLUX_BUCKET = getenv("INFLUX_BUCKET")
HOST = getenv("HOST_TAG")

CORE_OFFSET=2

CPU_TEMP = getenv("CPU_TEMP").split(':')

if __name__ == '__main__':
    parser = argparse.ArgumentParser(usage="PVE Sensors Stats to influxdb2 uploader")

    parser.add_argument(
        "-t",
        "--test",
        help="Just print the results without uploading to influxdb2",
        action="store_true"
    )

    args = parser.parse_args()

    measurements = []
    stats = {}

    data = json.loads(run(["/usr/bin/sensors -j"], stdout=PIPE, stderr=None, text=True, shell=True).stdout)

    if CPU_TEMP[0]: 
        stats[CPU_TEMP[0]] = int(data[CPU_TEMP[1]][CPU_TEMP[2]][CPU_TEMP[3]])

    measurements.append({
        "measurement": "temp",
        "tags": {"host": HOST, "service": "lm_sensors"},
        "fields": stats
    })

    if args.test:
        print(f"\nMeasurements for host {HOST}")
        print(json.dumps(measurements, indent=4))
    else:
        try:
            client = InfluxDBClient(url=f"http://{INFLUX_HOST}:{INFLUX_PORT}", token=INFLUX_TOKEN, org=INFLUX_ORGANIZATION, timeout=30000)
            write_api = client.write_api(write_options=SYNCHRONOUS)

            write_api.write(
                INFLUX_BUCKET,
                INFLUX_ORGANIZATION,
                measurements
            )

        except TimeoutError as e:
            failure = True
            print(e,file=sys.stderr)
            print(f"[{datetime.now().strftime('%Y-%m-%d %H:%M:%S')}] TimeoutError: Could not upload data to {INFLUX_HOST}:{INFLUX_PORT} for host {HOST}",file=sys.stderr)
            exit(-1)
        except InfluxDBError as e:
            failure = True
            print(e,file=sys.stderr)
            print(f"[{datetime.now().strftime('%Y-%m-%d %H:%M:%S')}] InfluxDBError: Could not upload data to {INFLUX_HOST}:{INFLUX_PORT} for host {HOST}",file=sys.stderr)
            exit(-1)
        except Exception as e:
            failure = True
            print(e, file=sys.stderr)
            print(f"[{datetime.now().strftime('%Y-%m-%d %H:%M:%S')}] Connection Error: Could not upload data to {INFLUX_HOST}:{INFLUX_PORT} for host {HOST}",file=sys.stderr)
            exit(-1)

        client.close()

• pve_temp_stats_to_influxdb2.sh

#!/bin/bash

export INFLUX_HOST="influx_IP_or_DNS"
export INFLUX_PORT="influx_PORT"
export INFLUX_ORGANIZATION="influx_organization"
export INFLUX_BUCKET="influx_bucket"
export INFLUX_TOKEN="influx_token"
export HOST_TAG="measurements_host_tag"
export CPU_CORES="6"

# Execute "sensors -j" and then use the information to set the following environment variables.
# In case some of them, like ACPITZ stuff, are not available, set them to ""
# For example if you want the PCH temperature to be stored in a pch field and you see the following
# within "sensors -j" output
#   "pch_cannonlake-virtual-0":{
#      "Adapter": "Virtual device",
#      "temp1":{
#         "temp1_input": 61.000
#      }
#   }
# AMD Ryzen 4750G output
#  "k10temp-pci-00c3":{
#     "Adapter": "PCI adapter",
#     "Tctl":{
#        "temp1_input": 62.875
#     }
#  },
# Set PCH_INFO as the following, by looking at the chain of values that lead to the temperature of PCH
export CPU_TEMP="cpu_temp:k10temp-pci-00c3:Tctl:temp1_input"

# Debian 11 without Python Virtual Environment
# python3 /home/scripts/pve_temp_stats_to_influxdb2.py $*

# Debian 12 with Python Virtual Environment in /path/to/venv
/path/to/venv/bin/python3 /home/scripts/pve_temp_stats_to_influxdb2.py $*

크게 바뀐 부분은 없고, 제게 존재하지 않는 정보 (PCH_INFO, ACPITZ_INFO,CORETEMP_NAME, NVME_INFO) 를 삭제하고 python 스크립트에서도 마찬가지로 제거했습니다. (nvme 의 경우 획득은 되나, 딱히 제게는 의미가 없어서 제거해두었습니다. 필요하시다면 가이드대로 정보 획득해서 추가해주시면 됩니다.)

Grafana에서 패널 추가하기

이제 InfluxDB 에 데이터가 수신되고 있으니, Grafana에 추가할 차례입니다. 최종적으로 결과는 이렇게 나올겁니다.

Grafana 대시보드에서 Add 를 통해 패널을 하나 추가합니다.

쿼리의 경우 다음과 같이 작성하면 됩니다. (가이드대로 따라하셨다면, r._field 값에 pch가 필요할 것입니다.)

from(bucket: "${Bucket}")
  |> range(start: v.timeRangeStart, stop:v.timeRangeStop)
  |> filter(fn: (r) => r["host"] =~ /${server:regex}/)
  |> filter(fn: (r) => r._measurement == "temp" and r._field == "cpu_temp")

저는 시계열 데이터를 그래프로 보여주는 Time series 와 Gauge 를 사용하였습니다. 처음 패널을 생성하게 될 경우 Threshold 값이나, 그래프에 대해서는 기본 값으로 설정되어있는데, 적당히 설정해서 사용하시면 됩니다.

같은 방법을 사용하여 아래와 같이 Summary 탭에서 Host 별 CPU도 보여줄 수 있습니다.

해당 패널의 쿼리는 아래와 같이 설정하시면 됩니다. (내부 패널 디자인은 취향에 맞춰 설정하시면 됩니다.

from(bucket: "${Bucket}")
  |> range(start: v.timeRangeStart, stop: v.timeRangeStop)
  |> filter(fn: (r) => r._measurement == "temp" and r._field == "cpu_temp")
  |> filter(fn: (r) => r.host == "${server}")

Grafana 를 통해 Alert 보내기

단순히 모니터링 시각화를 할 뿐만 아니라, 위험 수치에 도달했을 때 alert 를 보내줬으면 하여, grafana 를 통해 alert 시스템까지 한번 구축해보겠습니다.

Telegram 을 통한 Alert

Grafana 의 경우 다양한 방법을 통해 alert 를 보낼 수 있도록 설정할 수 있습니다. 여기서는 telegram 을 통해 설정해보겠습니다.

우선 Telegram 을 Contact point 로 지정해둬야합니다. Contact point 에서 Add contact point 를 누르고 Telegram bot을 선택합니다.

Telegram bot 의 생성의 경우 아래를 참고해주세요.

(1) 텔레그램 봇 만들기

1. 텔레그램 앱에 들어가셔서 BotFather를 검색하여 들어갑니다. ![](https://wikidocs.net/images/page/213846/%EB%B4%87%ED%8C…

위키독스

입력을 완료하면 Test 버튼을 통해서 정상적으로 메시지가 잘 수신되는지 확인합니다.

정상적으로 수신이되면, Notification Policies 로 갑니다. Default Policy 의 경우 Default email 으로 지정이되어있는데, 이를 방금 만든 Telegram bot 으로 contract point를 지정해줍니다.

이후 다시 대시보드로 돌아갑니다. 현재는 CPU 온도에 대한 알림을 구축하고 있으니, 앞서 만든 패널을 누르고 More -> New alert rule 을 통해 새 alert 규칙을 추가합니다. (이렇게 하면 관련 쿼리를 그대로 들고와서 편합니다.)

Rule 을 생성하는 곳에 도달하면 다음과 같은 쿼리를 볼 수 있습니다. 해당 영역에서는 따로 Grafana Dashboard 의 변수를 사용할 수 없어 명확하게 지정되어있는 모습을 볼 수 있습니다.

그런데, 패널에서 들고오면 보통 Host 에 대한 필터링이 있습니다. 이렇게 필터링이 된 쿼리를 사용할 경우 alert rule 을 host마다 각각 만들어야합니다. 따라서 쿼리에서 host를 따로 필터링하는 부분을 제거해주세요. 제 경우 다음과 같이 쿼리를 작성했습니다.

from(bucket: "proxmox")
  |> range(start: v.timeRangeStart, stop: v.timeRangeStop)
  |> filter(fn: (r) => r._measurement == "temp" and r._field == "cpu_temp")

그 다음에는 alert 를 위한 표현식을 작성하는 부분입니다. A 라는 결과는 쿼리를 통해서 얻은 결과이며 B는 여기서 값을 정하는 과정(평균값, 최대/최소값, 마지막 값) 그리고 C 에서 Threshold를 설정하는 것입니다. (단순하게 잘 만들어놨네요.)

CPU 온도가 일정 이상 오르면 알림이 가도록, Threshold 의 IS ABOVE 값을 변경합니다. 저는 70도를 기준으로 잡았습니다. (테스트를 위해서라면 당장 울릴만한 수치로 한번 설정해보고 추후에 변경하는 것도 좋습니다.)

Evaluation Behavior 에서는 같은 간격마다 alert 에 대한 평가를 진행할 그룹을 만듭니다. 앞서 cron 을 통해 1분마다 결과를 얻어내도록 하였으니, 저는 매 1분마다 온도를 보고하도록 설정했습니다. 이 또한 각자의 생각에 따라 설정하면 됩니다.

pending period 의 경우 Threshold 로 설정된 값이 일정 시간동안 지속되는지 모니터링 후 fire 하도록 합니다. 예를 들어, 5m 으로 잡으면 5분간 70도 이상의 온도가 감지될 경우 메시지가 발송됩니다.

이렇게 계속 threshold 를 넘는지 체크하여 적합한 상황에 fire될 수 있도록 할 수 있습니다. 만약, 즉각적으로 보내고자 한다면 0을 지정하면 됩니다.

설정이 완료되고 테스트를 해보았습니다.

텔레그램으로 알림이 잘 수신되는 것을 볼 수 있습니다.

언젠가 만들어봐야지.. 하고 마음 먹었던 홈서버. 드디어 구축을 했습니다. Host PC 구매부터 Proxmox 를 통한 가상화까지의 과정을 담았습니다. (티스토리에서 나눠져있던 글을 통합함)

홈서버 구축하기

나는 왜 서버를 구축하게 되었나.

어린 시절부터 나는 "나만의 서버"가 갖고 싶었다. 최근에는 클라우드를 간편하게 사용할 수 있게 되면서 그 필요성이 낮아지고 있지만 직접 내 서버 그리고 네트워크를 만들어나가는 일은 가슴이 두근두근거리는 일이다.

마침 42에서 제공하고 있던 AWS Credit 서비스가 종료되었다. 월 크레딧 $200 정도 소모하고 있었기에 (사실상 무료라고 너무 펑펑쓰기는 했다.) 이를 그대로 지출하는 것은 큰 부담이었고, 그냥 좋은 기회라고 생각하며 내 서버를 하나 만들어보기로 했다.

사실, 이전에도 놀고 있는 컴퓨터, 노트북으로 서버를 만드려는 시도는 많이했지만 그닥 활용성이 높지 않았다. 서버에 필요한 지식이 전무했기 때문이다. 그러나, 이제는 이래저래 치이면서 스스로 만들 준비가 되었다고 생각한다.

서버로 사용할 기기 구매하기

서버 구축의 시작은 서버로 사용할 기기를 구매하는 것이다. 보통 업그레이드 하면서 남는 PC, 노트북을활용하여 만들거나, 아니면 구 버전의 제온을 사서 그럴듯한 서버를 만들어본다거나, 아니면 나처럼 미니 PC 를 사기도 한다.

내 경우에는 내 방 안에서 운영해야하고, 전기세 또한 생각하면서 운영해야하기에, "저소음 - 저전력 - 소형" 이 기기 구매의 키워드였다.

기존에 가지고 있던 미니 서버

앞선 목적으로 예전에 ZBOX-nano 제품을 하나 구매해뒀다. "무소음 - 저전력 - 초소형"으로 완전히 내가 원하는 형태의 기기였다. 그러나, 잠깐 스펙을 살펴보면

CPU - Intel N4100 (1.1Ghz to 2.4Ghz)
RAM - 8GB
SSD - WD GREEN 120GB (SATA)

그냥 인터넷이나 겨우 할 성능을 가지고 있다. 더군다나 무소음이라서 로드가 오래 지속되면 큰 부담이 되어, 클럭이 2Ghz까지 잘 못간다. 지금도 사용하고는 있지만, Ghost 블로그를 여기에 올렸다가 성능때문에 너무 느려서 삽질을 하기도 했다.

내 Ghost blog는 왜 느릴까? - (2)

앞선 글에서 느린 Ghost blog 의 원인을 찾고 개선(?)을 했다. 남겨진 문제를 해결하는 과정을 살펴보자. 남겨진 문제 서버 시작 후 첫 접근에서 8~10 s 의 시간이 소요되는 문제가 발견되었다. 그러나, 따로 ”서버 시작 후 첫 로딩이 엄청 느려요” 라는 문서를 찾아볼 수는 없었다. 답답한 마음에, 서버포럼으로 가서 질문글을

PhotogrammerSungjun Park

아무튼, 해당 기기로는 제대로된 서버 운영이 힘들고 기존에 있던 서비스를 운영하거나, 새로운 서비스를 확장해서 운영하기에는 성능이 괜찮은 PC 가 하나 필요했다.

구매한 서버

여전히 "저소음 - 저전력 - 소형" 은 추구해야하지만 이번에는 "고성능" 까지 필요했다. 베어본 제품에서 주로 찾아보다가 해당 제품을 발견했다.

바로 Deskmini X300 제품이다. 기본적으로는 케이스 + AMD CPU 꽂을 수 있는 보드를 판매하고, CPU, RAM, SSD 등은 알아서 구매해서 사용하는 타입이다.

쇼핑몰을 뒤져보면 X300 에 5600G / 8GB / nvme 512 이런 식으로 같이 조립되어 파는 제품이 있으나, 아무래도 가성비가 조금 떨어진다. 어차피 컴퓨터는 중고로 사도 크게 차이가 없어 중고 제품을 알아보았다.

마침 중고나라에 가상화 서버 목적으로 사용하던 해당 제품이 있었고, 가격 또한 적당했다. 스펙은 이러하다.

CPU : AMD 4750G
RAM : 64 GB
SSD : Hynix Gold 500G

4750G 라서 스레드도 많고, 램도 넉넉하기에 바로 구매를 했다. 다만, 기본 쿨러의 경우 굉장히 소음이 심해서 녹투아 제품으로 교체했다. (녹투아 처음 써봤는데 거의 무소음이 되었다 ㄷㄷ..)

가상화

서버를 구매했으니, 다음으로 할 작업은 가상화이다. PC 의 성능이 너무 좋기에 여러 목적으로 나누어서 사용하고 싶었다. NAS (Synology) | Windows | Linux 이렇게 다양한 OS 를 두고 필요한 목적에 따라 사용할 수 있도록 가상화가 필요했다.

이 과정에서 Hypervisor 라는 것을 드디어 사용하게 되었다. 사실, Virtual Box, VMWare 등으로 종종 사용해본적은 있으나, 이렇게 베어메탈 위에 바로 붙어서 OS 를 여러개 돌리고 모니터링하는 Type 1 Hypervisor는 사용해본 적이 없었다.

VMWare ESXi 와 Prxmox 두 제품 중에 고민을 했고 다음과 같은 이유에서 Proxmox 를 골랐다.

• 오픈소스 / 무료
• ESXi 에서 제한걸어둔 기능들 사용 가능
• 서버 포럼에서 적극적으로 사용하고 있어, 문제 해결이 용이
• 리눅스라서 내부적으로도 다루기 편함.

서버 구조 계획

첫 홈서버의 구조와 글을 쓰는 지금의 구조가 상당히 다르다. 우선은 당시에 계획한 구조를 그려보겠다.

구조

단순히 X300 만 가상화를 하는 것이 첫 계획이었다. ZBOX 의 경우 사양이 낮아 Hypervisor - VM - Docker 까지 사용하면 상당히 부담이 될 것 같았고, X300 를 사용하게 되면 크게 사용하지 않을 것 같아 Proxmox 를 올릴 계획은 없었다.

따라서, Proxmox 를 X300에 설치하고, 돌아가는 VM은 총 3개의 운영체제 (Ubuntu / Windows / DSM ) 을 설치했다. 설치 과정의 경우 서버포럼 에 너무 잘 설명이 되어있어 생략..

요청 경로 (네트워크)

그리고 서버로의 요청은 다음과 같이 간략하게 잡았다.

단순히 포트 포워딩을 통해서 Ubuntu 의 Docker container 로 동작하고 있는 nginx 로 도달하고, 다시 nginx 에서는 내부 망에 존재하는 서비스로 Reverse proxy 하는 구조이다.

다만, 너무 단순하게 구성을 해둬서 이후에 보안적으로 취약한 부분들이 많이 보였다. 예를 들어, 내부 관리 서비스에 대한 접근 또한 *.photogrammer.me 를 통해서 접근이 가능하도록 해두었는데, nginx 에서 내부 망으로만 제한을 걸더라도 IP 스푸핑을 통해서 접근이 가능하기도 하였다. 이런 부분들을 추후에 VPN 과 관리 작업에 대한 호스트 분리 등을 통해서 해결하였다.

VM 활용 방안

Ubuntu

기본 목적은 다양한 Docker container 를 올리는 것이다. 컨테이너가 아니라, 잘게 VM 을 쪼개서 (EC2처럼) 사용할 수도 있겠지만, 관리적인 측면이나, 전체 자원 소모 측면에서나 OS 하나 두고 도커로 사용하는 것이 조금 더 낫다고 판단했다. 이후 k8s 관련 지식을 좀 습득하고 나면, Docker 보다 K8s 를 통해서 서비스들을 관리해볼 계획이다.

현재는 그냥 Docker 로 관리하지는 않고, Dockge 라는 docker 를 매니징 할 수 있는 도구를 통해서 관리하고 있다. 서버포럼을 통해 소개받아서 사용하고 있는데 생각보다 편하다. 나중에 한번 소개해보겠다.

DSM (Synology)

올해 부로 OneDrive, Google Drive 등 학교 계정을 통해서 제공받고 있던 클라우드 드라이브에 대한 접근이 제한되었다. 따라서, 기존의 데이터를 좀 옮겨둘 곳이 필요했고 헤놀로지를 올려서 해결하기로 했다.

이를 위해서 기존에 외장 SSD 로 쓰고 있었던 SSD를 X300 에 심었고, Proxmox 내에서 스토리지로 넣어두었다. DSM 에서도 도커 컨테이너 작동이 가능하지만, DSM 자체는 클라우드 드라이브의 성격으로 사용하기로 하여 컴퓨팅 성능을 낮게 잡아두었고, 대부분 저장된 정보를 통해서 무언가를 할 수 있는 성격의 서비스들만 올려두려고 한다.

Windows

Windows 의 경우 일부 윈도우를 통해서만 가능한 작업을 하거나, 가볍게 RDP 를 통해서 코딩 하는 용도로 선정해두었다. 다만, 실제로 설치하고 사용했을 때 Linux 나 DSM 과 달리 메모리가 실제 사용량에 따라 증가하지 않고, 초기에 16기가를 할당하면 그대로 사용 상태로 할당되어버리는 문제가 있었다. 이는 Windows 가 부팅과 동시에 메모리 영역을 0으로 초기화하며 접근하기에 발생하는 문제로, 딱히 해결을 할 수는 없었다.

때문에, 일반적으로 메모리를 정확하게 나눠서 사용하기는 하지만, 내 경우 다른 OS 쪽에 더 넉넉하게 주고, 겹치도록 사용하려고 하는 계획은 물거품이 되었다. (만약, 겹치는 순간이 오면 그냥 종료된다.) 다만, 램 자체가 넉넉해서 아직은 그냥 넉넉하게 주고 사용 중이다.

초기 설정은 끝났다.

초기 설정은 이정도로 마무리했었다. 다만, 이는 11월 쯤 구성했던 구성이었고, 지금은 바뀐 것들이 있다. 이후 포스팅에서는 서버를 어떤 식으로 변화해왔는지 한번 설명해보겠다.