기존 파일들을 어떻게 호환시킬 것인가?

문제상황

현재의 가장 큰 개발 과제 중 하나는 바로 기존 블로그 글에 대한 마이그레이션과 관련된 부분이다. 기존의 데이터는 정적 사이트 생성기인 Gatsby를 활용하여 쿼리를 통해 구현이 되어 있다. 하지만 웹 서비스 형식으로 구현이 될 현재의 형태에서 기존의 파일 기반의 블로그의 데이터들은 데이터의 변환이 되었든, 호환이 되었든 무언가 조치를 통하지 않으면 안된다.

요구 기준 사항

1. MySQL 을 기준으로 잘 동작할 수 있게 처리가 되어야 한다.
2. (미확정) 검색 기능 최적화를 위해 Elasticsearch 같은 검색 엔진을 고려할 수도 있다.
3. 2번이 아니더라도 자체적인 검색 기능 구현함에 있어 성능최적화를 고려해야한다.
4. 향후 글쓰기에서 필요한 기능들이 동일하게 동작하도록 호환이 되어야하고, 기존의 데이터들은 메타데이터 형식으로 MD 파일 상단에 동일하게 위치해 있음에서 호환이 되어야 한다.

결론

1. 파일 형식을 그대로 이어가면서, 파일 형식에서 열고 닫는 것은? -> 성능적인 이점을 살릴 수가 없음. 다른 복잡한 검색 엔진들에 사용하기 어려울 수 있음.
2. 따라서 메타 데이터를 파싱하고 기존 문서에 대해서는 데이터베이스에 이식하는 방식으로 진행하는 것이 어쩔 수 없는 선택으로 보인다.
3. 더불어도 고려해보면, 기존의 블로그에서는 필요 없는 데이터들이 있고, 이것 조차 끌어 안고 그대로 가는 것은 비효율적이고 무엇보다 중간에 들어있는 이미지에 대한 문제가 새로이 발생하는 만큼, 통으로 처리하는 스크립트를 구현할 필요가 있다.

추가 문제 사항 : 이미지는 어떻게?

• 현재 글과 함께, 새롭게 생긴 문제이다. 기존의 글들은 MD 파일이고 그 안에 링크 형태로 되어 있으며, 특히나 상대 위치로 가리키는 해당 MD 파일이 있는 폴더에서 src라는 폴더를 만들고, 컴파일 돌려서 정적사이트 생성을 진행하는 구조로 되어 있다.
• 그러나 글을 스크립트를 통해 반복문으로 데이터화, DB에 넣는 것을 구현한다고 할 때, 이미지 역시 적절한 처리를 해서 향후 사이트에서 요구를 받으면 전달해주어야 하는데, 어떻게 해결하면 좋은가?

대안 및 고려할 사항 (by ChatGPT )

1. 파일 시스템에 저장: 이미지와 같은 정적 파일은 데이터베이스보다는 파일 시스템에 저장하는 것이 일반적입니다. 파일 시스템에 저장함으로써 서버의 성능 부담을 줄이고, 데이터베이스의 용량을 절약할 수 있습니다. 각 글에 대한 고유한 폴더를 생성하거나, 일괄적으로 관리할 수 있는 한 폴더에 모두 저장할 수 있습니다. 고유 이름을 사용하되, 이미지의 원본 파일명이나 글과 연관된 정보를 포함시켜 관리하는 것이 좋습니다.
2. CDN (Content Delivery Network) 사용 고려: 성능 최적화와 글로벌 사용자에게 빠른 콘텐츠 제공을 위해 CDN을 사용하는 것도 좋은 방법입니다. CDN을 사용하면 이미지 파일을 여러 지리적 위치에 분산하여 저장하고 제공할 수 있어, 사용자에게 더 빠른 로딩 속도를 제공할 수 있습니다.
3. 데이터베이스에 메타데이터 저장: 이미지 파일 자체는 파일 시스템에 저장하되, 이미지에 대한 메타데이터(예: 파일명, 경로, 글과의 관계 등)는 데이터베이스에 저장하는 것이 좋습니다. 이를 통해 이미지를 효율적으로 관리하고, 검색 또는 글과의 연관성 파악이 용이해집니다.
4. 이미지 파일명 규칙 정의: 이미지 파일명을 시간이나 날짜로만 구성하는 대신, 글의 식별자나 키워드를 포함하는 명명 규칙을 설정하는 것이 관리에 유리합니다. 이렇게 하면 파일 시스템에서 이미지를 쉽게 찾을 수있습니다.

대안에 대한 나의 생각

1. 우선 파일 시스템에 그대로 저장하는 것은 어렵지는 않다. 하지만 전체 파일의 관리가 어려워졌고, 동시에거 검색하고 보여줄 때 곤란함이 있다. 검색 시는 특히나 이미지까지 서버에서 열고 전달해주는 방식은 성능적으로 적절한 구조는 아니.
2. 현재 올리려는 서버의 성능, 대역폭 등을 종합적으로 고려할 때 서버에서 글 외의 영역에 대한 정보를 전달해주는 것은 1번에서 언급했듯 좋은 상황은 아니다.
3. CDN서버를 활용하는 것도 좋은 방법일 수 있지만, CDN 서버에서의 비용도 문제를 포함하여 장기적으로 운용하기엔 어려운 면이 좀 있다.
4. 결정적으로 만약, 위에서 기존 데이터들을 전부 이동시키는 마이그레이션을 시킨다고 할 때, 해당하는 글의 이미지 전체를 일괄 처리를 할 수 있고, 그렇게 한다는 전제하에 생각하면 이미지의 처리는 proxy 서버인 nginx 가 요청을 받았을 때 처리하는게 가능하지 않을까 생각해본다.

이미지 처리에 대한 잠정 결론

1. 기본적으로 문서를 전체 분해하여 스크립트화 시킬 것은 이미 확정. 그렇게 하면서 기존의 파일 구조의 이미지들의 위치를 수정하고 이름 및 실제 글에서 이미지 링크를 바꾸는 방식으로 파일 주소를 정리한다.
2. 해당 내용을 DB에 기록하면서, 이미지들은 일괄적으로 저장할 공간을 지정해준다.
3. 프론트 작업 시 백엔드와는 별도로 이미지가 저장될 수 있도록 구현한 뒤 이러한 프론트의 이미지 저장에 관련해서는 nginx가 해당 내용을 담당하도록 하여서 백엔드에서는 이미지에 대해 거치거나 처리하지 않는 구조를 구현한다.

추가적인 고려사항

1. 이미지 최적화 : 웹사이트 성능 개선을 위한 이미지 최적화~ 어떻게 처리해서 압축을 해야 용량적인 면과 성능적인 면에서 좋을것인가?
   • 프론트엔드에서 적절하게 대처하여 이미지 사이즈를 확인하면서, 비정상적으로 클 경우 리사이징해주는 형태로 업로드를 해결하면 됨.
2. 보안 문제 : 이미지를 포함한 모든 정적 파일 처리의 보안 문제를 어떻게 해결하거나, 반대로 그 과정에서 보안적으로 적절하지 않은 파일이 업로드 되거나, 불법적인 요청을 어떻게 처리할 지 고려해봐야 한다.
   • 이에대해 가장 현실적인 방법은 다음과 같다.
     1. 서버에서 JWT 토큰을 만들어내고 발행해준다.
     2. 서버에서 받은 토큰을 가지고 문서 작성 내지는 문서를 보는 작업이 요청이 될 것이고
     3. nginx의 오픈소스를 활용하여 Lua스크립트로 구성된 jwt 해석하여 토큰 유효성 검사 기능을 내장, 해당 기능 기준으로 문제가 없다고 판단될 때
     4. 이미지의 다운로드를 가능케 한다.
   • 이미지 업로드는 어떻게 해야 하는가?
     • 해당 기능에 대해서는 서버에서 처리할 수 밖에 없어보인다. nginx에서는 다운로드에 대해서만 처리가 가능한편. 실제로 고려해보아도 결국 nginx에서 정적인 데이터의 처리 정도만 서버의 부하를 줄여줘도 큰 역할을 한다.
     • 뿐만 아니라 백엔드 서버에서 JWT 권한에 따라 업로드가 가능하도록 하는게 보안 적으로 이상이 없어보이니, 그렇게 유도가 되어야 하리라 생각된다.
3. 백업 및 재해 복구 계획 : 서버가 내려가거나 문제가 발생했을 때 이를 해결하거나 서비스 연속성을 유지시키는 방법이 있어야 한다.
   • 정적인 파일에 대해서는 cron 기능이나 rsync 기능을 통해 백업을 할 수가 있어 보인다. 따라서 nginx와는 별도로 해당 방식을 활용해서 데이터를 그대로 보관하면 될 것으로 보인다.
   • 향후 DB 쪽과 관련하여서도 함께 고려해야 할 문제로 보인다.