This page contains information related to upcoming products, features, and functionality. It is important to note that the information presented is for informational purposes only. Please do not rely on this information for purchasing or planning purposes. The development, release, and timing of any products, features, or functionality may be subject to change or delay and remain at the sole discretion of GitLab Inc.
Status Authors Coach DRIs Owning Stage Created
proposed @msaleiko @stanhu 2023-06-05

mail_room 이메일 수집을 예약된 Sidekiq 작업으로 대체하기

Summary

GitLab 사용자는 이메일을 통해 새 이슈 및 댓글을 제출할 수 있습니다. 관리자는 GitLab이 정기적으로 폴링하고 새로운 읽지 않은 이메일을 가져올 수 있는 특수 메일함을 구성합니다. 이메일 주소의 서브 주소 부분에 슬러그와 해시에 따라, 해당 이메일이 이슈를 기록하거나 서비스 데스크 이슈를 추가하거나 기존 이슈에 댓글을 추가할지를 결정합니다.

현재 이메일은 별도의 mail_room 프로세스에 의해 수집됩니다. 우리는 mail_room을 통해 이메일을 수집하는 것을 중단하고 대신에 예약된 Sidekiq 작업을 사용하여 GitLab 내에서 직접 처리하고자 합니다.

이는 Service Desk를 위한 사용자 정의 이메일 주소 수집, 자세한 건강 로깅 및 다른 서비스 제공 업체 어댑터(예: API를 통한 Gmail) 통합을 더욱 쉽게 만들며, 인프라 설정 및 유지 관리 비용을 줄이고 Self-managed 고객 및 팀 구성원이 GDK에서의 이메일 수집 작업을 더 쉽게 할 수 있도록 하는 기초를 마련합니다.

용어 해설

  • 이메일 수집: IMAP 또는 API를 통해 메일함에서 이메일을 읽어 처리를 위해 전달하는 것 (예: 이슈 생성 또는 댓글 추가)
  • 서브 주소: 이메일 주소는 로컬 부분(@ 이전의 모든 것)과 도메인 부분으로 구성됩니다. 이메일 서브 주소를 사용하면 로컬 부분에 + 기호를 추가한 다양한 형태의 이메일 주소를 생성할 수 있습니다. 이 서브 주소들을 사용하여 특정 메일을 필터링, 분류 또는 구별할 수 있습니다. 예를 들어 user+subaddress@example.com 및 user+1@example.com과 같은 서브 주소는 모두 동일한 메일함으로 전달됩니다.
  • mail_room: 새로운 프로세스를 생성하여 각 구성된 메일함에서 새 이메일을 정기적으로 읽고 처리 단위로 이메일을 전달하는 실행 가능한 스크립트입니다.
  • incoming_email: 이메일 주소로, 새로운 이메일을 읽고 GitLab에서 처리하도록 구성된 주소입니다. 이슈 댓글의 GitLab 알림에 회신하는 경우, 이 응답 이메일은 구성된 incoming_email 메일함으로 전송됩니다. 그리고 이를 mail_room에서 읽고 GitLab에서 처리합니다. 또한 이 주소를 서비스 데스크 이메일 주소로 사용할 수 있습니다. 이 구성은 인스턴스별로 이루어지며 메일함에 액세스하기 위해 전체 IMAP나 Microsoft Graph API 자격 증명이 필요합니다.
  • service_desk_email: 서비스 데스크 전용 별칭 이메일 주소입니다. 서비스 데스크에만 사용됩니다. incoming_email에서 생성된 주소를 사용하여 서비스 데스크 이슈를 생성할 수도 있습니다.
  • delivery_method: 관리자는 mail_room이 가져온 이메일을 GitLab에 어떻게 전달할지 정의할 수 있습니다. 레거시이자 현재 사용되지 않는 방식은 sidekiq로, 이는 Redis 대기열에 새 작업을 직접 추가합니다. 현재의 권장 방식은 webhook으로, 내부 GitLab API 엔드포인트로 POST 요청을 보냅니다. 이후 이 엔드포인트는 작업 데이터 압축을 위한 전체 프레임워크를 사용하여 새 작업을 추가합니다. 한 가지 단점은, mail_room과 GitLab이 대규모 설정에서 배포하는 데 어려움을 겪을 수 있는 공유 키 파일이 필요합니다.

동기

현재 구현은 확장성이 부족하며 상당한 인프라 유지 보수가 필요합니다. 게다가, 구성 오류에 대한 적절한 관찰 기능 부족과 전반적인 시스템 상태 확인 부족이 있습니다. 또한, 다중 노드 리눅스 패키지(Omnibus) 설치의 설정 및 지원 제공이 복잡하며, 주기적인 이메일 수집 문제로 반응적인 지원이 필요합니다.

mail_room gem의 포크인 gitlab-mail_room을 사용하고 있으며, 해당 gem에는 상류로 이식되지 않을 GitLab 특정 기능들이 포함돼 있어 상당한 유지 보수 부담이 있습니다.

Service Desk 단일 엔지니어 그룹 (SEG)은 Service Desk를 위한 사용자 정의 이메일 주소와 관련한 작업을 시작하고 16.4에서 베타로 첫 번째 반복본을 릴리스했습니다. MVC로서 우리는 Forwarding & SMTP 모드를 소개하였습니다. 여기서 관리자는 자신들의 사용자 정의 이메일 주소에서 해당 프로젝트의 incoming_mail 이메일 주소로 이메일 전달을 설정합니다. 또한 GitLab이 해당 사용자를 대신하여 해당 사용자 정의 이메일 주소에서 이메일을 보낼 수 있도록 SMTP 자격 증명을 제공합니다. 이 방식은 작업이 작동하려면 이미 있는 메커니즘이상의 추가 이메일 수집이 필요하지 않습니다.

두 번째 반복본으로는 마이크로소프트 그래프 지원을 통해 Service Desk를 위한 사용자 정의 이메일 주소를 추가하고자 합니다. 따라서 시스템에서 정의한 두 주소 이상을 수집하기 위한 방법이 필요합니다. 우리는 특권 있는 사용자가 자신의 사용자 정의 이메일 계정을 연결하고 우리가 마이크로소프트 그래프 웹훅을 통해 메시지를 수신할 수 있는 방법을 탐색하겠습니다. GitLab은 이메일 업데이트를 받기 위한 공개 엔드포인트가 필요할 것입니다. 이것은 Self-managed 인스턴스에는 작동하지 않을 수 있으므로 마이크로소프트 고객을 위해 직접 이메일 수집이 필요할 것입니다. 그러나 웹훅 접근 방식은 우리가 수천 개의 메일함을 폴링할 수 있는 GitLab SaaS의 성능과 효율성을 향상시킬 수 있습니다.

목표

이 이니셔티브의 목표는 이메일 수집의 확장성을 향상시키고 인프라를 크게 축소하는 것입니다.

  1. 이 통합을 통해 별도의 프로세스 설정이 필요 없어질 것이고, IMAP 및 마이크로소프트 그래프를 통한 직접적인 사용자 정의 이메일 주소 수집과 데이터 보존 (원본 유지), 이메일 크기 제한 내에서의 첨부 파일 처리 개선과 같은 미래 이니셔티브들을 위한 길을 열 것입니다.
  2. 팀 구성원이 이메일 수집 기능을 개발하기 쉽게 만들 것입니다. 지금은 여러 매뉴얼 단계가 필요합니다.

비목표

이 청사진은 나열된 모든 미래 계획에 대한 구현 세부 정보를 제시하는 것을 목표로 하지 않습니다. 그러나 이는 이후 기능(사용자 정의 서비스 데스크 이메일 주소 IMAP/Microsoft Graph, 상태 체크 등)을 위한 기반이 될 것입니다.

다른 수용 방법은 포함하지 않습니다. 우리는 현재 설정인 IMAP 및 Microsoft Graph API를 사용한 incoming_email 및 service_desk_email을(를) 제공하는 데 초점을 맞춥니다.

현재 설정

관리자는 gitlab.rb 구성 파일에서 이메일 매니폴드(incoming_email) 및 서비스 데스크 이메일(service_desk_email)을 위한 설정(자격 증명 및 전달 방법)을 구성합니다. GitLab에서 변경 후에는 새로운 설정을 적용하려면 GitLab을 재구성하고 다시 시작해야 합니다.

우리는 별도의 프로세스인 mail_room을 사용하여 이러한 메일 매니폴드에서 이메일을 수용합니다. mail_room은 각 구성된 메일 매니폴드마다 스레드를 생성하고 해당 메일 매니폴드를 매분마다 폴링합니다. 그 채로 스레드는 유휴 상태입니다. mail_room은 gitlab.rb의 설정에서 생성된 구성 파일을 읽습니다.

mail_room은 IMAP 및 Microsoft Graph를 통해 연결할 수 있으며, 읽지 않은 이메일을 가져와서 설정에 따라 해당 이메일을 읽음 또는 삭제합니다. 그런 다음 두 전달 방법 중 하나를 사용하여 해당 목적지로 이메일을 보냅니다.

webhook 전달 방법(권장됨)

webhook 전달 방법은 mail_room에서 GitLab으로 이메일을 이동하는 것을 권장하는 방법입니다. mail_room은 이메일 본문과 메타데이터를 내부 API 엔드포인트(/api/v4/internal/mail_room)에 전송하여 올바른 핸들러 워커를 선택하고 실행을 예약합니다.

flowchart TB User --이메일 전송--> provider[(이메일 제공 업체 메일박스)] mail_room --IMAP 또는 Microsoft Graph API를 통해 읽지 않은 이메일 가져오기--> provider mail_room --HTTP POST--> api api --이메일을 위한 작업 추가--> 생성 subgraph mail_room_process[mail_room] mail_room[mail_room 스레드] end subgraph GitLab api[내부 API 엔드포인트] 생성["이메일 주제에 따라 이슈/노트를 생성하는 Sidekiq 이메일 핸들러 작업"] end

sidekiq 전달 방법(16.0 이후로 사용 중지됨)

sidekiq 전달 방법은 이메일 본문과 메타데이터를 Sidekiq가 작업을 관리하는 Redis 대기열에 직접 추가합니다. 이는 전달 방법과 Redis 구성 사이에 강력한 결합이 있기 때문에 16.0에서 사용 중지되었습니다. 또한 작업 페이로드 압축과 같은 Sidekiq 프레임워크 최적화를 사용할 수 없습니다.

flowchart TB User --이메일 전송--> provider[(이메일 제공 업체 메일박스)] mail_room --IMAP 또는 Microsoft Graph API를 통해 읽지 않은 이메일 가져오기--> provider mail_room --Redis 대기열에 직접 작성, 작업 예약--> redis[Redis 대기열] redis --Sidekiq가 대기열에서 작업을 가져와 실행함--> 생성 subgraph mail_room_process[mail_room] mail_room[mail_room 스레드] end subgraph GitLab 생성["이메일 주제에 따라 이슈/노트를 생성하는 Sidekiq 이메일 핸들러 작업"] end

제안

Sidekiq 작업을 사용하여 정기적으로(매분마다 또는 나중에 구성 가능하게) 메일박스를 폴링합니다. 다른 모든 레거시 이메일 수용 인프라를 제거합니다.

flowchart TB User --이메일 전송--> provider[(이메일 제공 업체 메일박스)] 수용 --IMAP 또는 Microsoft Graph API를 통해 읽지 않은 이메일 가져오기--> provider controller --"각 메일박스에 대한 작업을 트리거함"--> 수용 수용 --가져온 각 이메일에 대한 작업을 추가--> 생성 subgraph GitLab controller[일정된 Sidekiq 수용 컨트롤러 작업] 수용[Sidekiq 메일박스 수용 작업] 생성["기존 Sidekiq 이메일 핸들러 작업 이메일 주소를 기반으로 이슈/노트를 생성함"] end
  1. 매분마다 또는 나중에 구성 가능한 controller 작업을 사용합니다. 이 작업은 각 구성된 메일박스(incoming_email 및 service_desk_email)에 대해 하나의 작업을 추가합니다.
  2. 구체적인 수용 작업은 메일박스(IMAP 또는 Microsoft Graph)를 폴링하고, 받지 않은 이메일을 다운로드하며, 해당 이메일을 처리하는데 대한 작업을 추가합니다. 사용된 To 이메일 주소에 따라 사용할 이메일 핸들러를 결정합니다.
  3. 기존 이메일 핸들러 작업은 이슈, 서비스 데스크 이슈 또는 기존 이슈/Merge Request에 대한 노트를 생성하려고 시도합니다. 이러한 핸들러는 또한 mail_room을 통한 레거시 이메일 수용에서도 사용됩니다.

Sidekiq 작업 및 작업 페이로드 크기 최적화

우리는 Sidekiq 작업에 대한 크기 제한을 구현했으며, 특히 첨부 파일이 있는 이메일 작업 페이로드는 그 제한을 초과할 가능성이 있습니다. 우리는 이메일 처리를 Sidekiq 메일박스 수용 작업에서 직접 처리하는 아이디어를 실험해 볼 필요가 있습니다. 우리는 이 모드와 각 이메일에 대한 Sidekiq 작업 간에 전환하기 위해 ops 피처 플래그를 사용할 수 있을 것입니다.

또한 메시지 ID만 가져와서 완전한 메시지를 다운로드하는 방법을 탐구하고 싶습니다(예를 들어 UID 범위로 필터링). 예를 들어 우리는 메일박스를 폴링하고 메시지 ID 디렉터리을 가져옵니다. 그런 다음 25개(또는 n)의 이메일마다 메시지 ID나 범위를 인수로 취하는 새로운 작업을 생성합니다. 이러한 작업은 그런 다음 전체 메시지를 다운로드하고 동기적으로 문제나 답변을 추가합니다. 이메일 수가 25미만인 경우에는 심지어 리소스를 저장하기 위해 현재 작업에서 직접 이메일을 처리할 수 있습니다. 이렇게 함으로써 이메일의 크기를 제한 요소로 부여하지 않고 자원을 절약할 수 있습니다. 단점은 한 번에 두 번(개수+1)의 IMAP 서버 호출을 해야 한다는 것입니다.

실행 계획

  1. mail_room 이메일 수용에 대해 사용 중지 경고 추가.
  2. gitlab-mail_room gem에서 연결별 로직을 제거하고 새로운 별도의 gem에 이것을 저장합니다. mail_room 및 다른 클라이언트가 여기서 우리의 작업을 사용할 수 있습니다. 현재 우리는 IMAP 및 Microsoft Graph API 연결을 지원합니다.
  3. 새로운 작업 추가(만약 Sidekiq가 실행 중이 아니라면 거대한 작업의 백로그를 피하기 위해 동일성과 중복 제거 플래그를 설정합니다).
  4. gitlab.rb에서 Sidekiq 작업을 사용하여 이메일 수용을 활성화하는 설정을 추가합니다. 우리는 gitlab.rb에서 mailroom['enabled'] = false를 설정하여 mail_room 이메일 수용을 비활성화합니다. 추가로 피처 플래그를 추가할 수 있을 것으로 생각됩니다.
  5. 일반적으로 사용 가능하기 전에 gitlab.com에서 사용하고, 자체 호스트된 버전에서는 beta에서 시도할 수 있게 합니다.
  6. 일반적으로 사용 가능하게 되었을 때 및 제거가 예정되었을 때 gitlab-mail_room에 대한 의존성을 완전히 제거하고, api/internal/mail_room 내부 API 엔드포인트를 제거하고, mail_room.yml에서 동적으로 생성된 정적 구성 파일을 제거하며, 다른 구성 및 바이너리를 제거합니다.

변경 관리

우리는 GitLab 16.0에서 mail_room의 sidekiq 전달 방법을 폐기하기로 결정했고, 이를 GitLab 17.0에서 제거할 예정입니다.

이 설계도가 구현되고 고객이 새로운 이메일 흡수를 일반적으로 사용할 수 있는 경우에만 sidekiq 전달 방법을 제거할 수 있습니다.

그런 다음 mail_room을 제거할 것을 예정해야 합니다 (GitLab 17.0 이후). 이것은 파급 효과가 있는 변경일 것입니다. Self-managed 고객들이 조치를 취할 필요가 없도록 새로운 이메일 흡수를 미리 기본값으로 설정할 수 있습니다.

대안 솔루션

아무것도 하지 않기

현재 설정은 우리를 제한하며 두 개의 이메일 주소만 가져올 수 있습니다. IMAP 또는 API 통합을 사용하여 서비스 데스크 사용자 정의 이메일 주소를 게시하려면 위에 설명된 것과 같은 아키텍처를 제공해야 합니다. 그러므로 우리는 지금 조치를 취하고, incoming_email 및 service_desk_email을 위한 일반 이메일 흡수를 먼저 포함하고 인프라 비용을 제거해야 합니다.

추가 리소스

일정

  • 2023-09-26: 설계도의 초기 버전이 Merge되었습니다.