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. As with all projects, the items mentioned on this page are subject to change or delay. The development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.
Status Authors Coach DRIs Owning Stage Created
proposed @msaleiko @stanhu 2023-06-05

예약된 Sidekiq 작업을 사용하여 mail_room 이메일 수신 대체

요약

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

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

이것은 서비스 데스크를 위한 사용자 정의 이메일 주소 수신, 자세한 헬스 로깅 및 다른 서비스 제공 업체 어댑터(예: API를 통한 Gmail) 통합을 쉽게하는 기반을 마련하며, 관리 인프라 구축 및 유지 관리 비용을 줄일 것입니다. 또한, Self-managed를 사용하는 고객들과 GDK에서 팀 구성원이 이메일 수신을 처리하는 것을 더 쉽게 할 것입니다.

용어 해설

  • 이메일 수신: IMAP 또는 API를 통해 메일함에서 이메일을 읽고 처리를 위해 전달하는 것 (예: 이슈 생성 또는 코멘트 추가)
  • 하위 주소 지정: 이메일 주소는 로컬 부분(@ 이전의 모든 것)과 도메인 부분으로 구성됩니다. 이메일 하위 주소 지정을 통해 로컬 부분에 + 기호를 추가한 다음 임의의 텍스트를 덧붙여 기존 이메일 주소의 고유한 변형을 생성할 수 있습니다. 이러한 하위 주소를 사용하여 이메일을 필터링, 분류 또는 구분할 수 있으며 이러한 모든 이메일은 동일한 메일함으로 전달됩니다. 예를 들어 user+subaddress@example.com 및 user+1@example.com은 user@example.com으로 전송되는 하위 주소입니다.
  • mail_room: 실행 가능한 스크립트로, 각 구성된 메일함에 대해 새로운 프로세스를 생성하고 정기적으로 새 이메일을 읽어 이메일을 처리 단위에 전달합니다.
  • incoming_email: 이메일 주소로, 코멘트 및 이슈를 추가하는 데 사용됩니다. 이슈 코멘트의 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이 공유 키 파일이 필요하다는 점인데, 대규모 시스템에서 파일을 배포하는 것이 어려울 수 있습니다.

동기

현재의 구현은 확장 가능성이 부족하며 중요한 인프라 유지보수가 필요합니다. 또한, 구성 오류의 적절한 관찰이 부족하고 전반적인 시스템 헬스에 대한 부족도 있습니다. 더 나아가 다중 노드 Linux 패키지(Omnibus) 설치의 설정 및 지원 제공이 어려운 경우가 발생하며 주기적인 이메일 수신 문제로 반응적인 지원이 필요합니다.

우리는 mail_room 젬의 포크를 사용하고 있으며(gitlab-mail_room), 이는 상류에 이식되지 않을 일부 GitLab 특정 기능을 포함하고 있어 상당한 유지보수 부담이 있습니다.

서비스 데스크 단일 엔지니어 그룹 (SEG)은 서비스 데스크를 위한 사용자 정의 이메일 주소에 대한 작업을 시작했으며, 16.4에서 첫 번째 반복을 베타로 릴리스했습니다. MVC로, 우리는 전달 및 SMTP 모드를 도입했는데, 여기서 관리자는 사용자 정의 이메일 주소에서 프로젝트의 incoming_mail 이메일 주소로의 이메일 전달을 설정합니다. 또한, GitLab이 직접 사용자 정의 이메일 주소에서 이메일을 보낼 수 있도록 SMTP 자격 증명을 제공합니다. 이 접근 방식이 작동하려면 기존 기계 이메일 수신 외에 추가적인 이메일 수신이 필요하지 않습니다.

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

목표

이번 계획의 목표는 이메일 수신의 확장성을 향상시키고 인프라를 크게 줄이는 것입니다.

  1. 이 통합은 독립적인 프로세스의 설정 필요성을 제거하고, 직접적인 사용자 정의 이메일 주소 수신 (IMAP 및 Microsoft Graph), 개선된 건강 모니터링, 데이터 보존 (원본 보존), 그리고 이메일 크기 제한 내에서 첨부 파일 처리 개선을 포함한 향후 계획을 위한 기반을 마련할 것입니다.
  2. 팀원들이 이메일 수신 기능을 쉽게 개발할 수 있도록 합니다. 현재는 수동 단계가 필요합니다.

비목표

이 설계도는 나열된 향후 계획에 대한 구현 세부 정보를 제시하는 데 목표를 두지 않습니다. 그러나 이것은 향후 기능들(사용자 정의 Service Desk 이메일 주소 IMAP/Microsoft Graph, 건강 점검 등)을 위한 기반이 될 것입니다.

다른 수신 방법은 포함되지 않습니다. 우리는 IMAP 및 Microsoft Graph API를 사용한 incoming_email 및 service_desk_email을 현재 설정에 중점을 두고 있습니다.

현재 설정

관리자는 gitlab.rb 구성 파일에서 이메일 메일박스 (incoming_email 및 service_desk_email)의 설정(자격 증명 및 전달 방법)을 구성합니다. 각 변경 후 GitLab은 새 설정을 적용하기 위해 다시 구성 및 재시작해야 합니다.

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

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

webhook 전달 방법 (추천)

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

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

sidekiq 전달 방법 (16.0부터 사용 중단)

sidekiq 전달 방법은 이메일 내용과 메타데이터를 직접적으로 Sidekiq이 작업을 관리하는 Redis 대기열에 추가합니다. Redis 대기열에서 Sidekiq이 작업을 가져와 실행합니다. 여기에는 전달 방법과 Redis 구성 간의 강한 결합이 있어 16.0부터 사용 중단되었습니다. 또한 작업 페이로드 압축과 같은 Sidekiq 프레임워크 최적화를 사용할 수 없습니다.

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

제안

Sidekiq 작업을 사용하여 메일박스를 정기적으로 폴링합니다(매분, 향후 변경 가능). 다른 모든 레거시 이메일 수신 인프라를 제거합니다.

flowchart TB User --이메일 송신--> provider[(이메일 제공 업체 메일박스)] ingestion --IMAP 또는 Microsoft Graph API를 통해 읽지 않은 이메일을 가져옴--> provider controller --"각 메일박스에 대한 작업 트리거"--> ingestion ingestion --가져온 각 이메일에 대해 작업 추가--> create subgraph GitLab controller[정기적인 Sidekiq 수신 컨트롤러 작업] ingestion[Sidekiq 메일박스 수신 작업] create["기존 Sidekiq 이메일 핸들러 작업 - 이메일 주소를 기반으로 이슈/노트를 생성함"] end
  1. 매분 또는 향후 변경 가능한 일정으로 예약된 controller 작업을 사용합니다. 이 작업은 각 구성된 메일박스 (incoming_email 및 service_desk_email)에 대해 하나의 작업을 추가합니다.
  2. 구체적인 ingestion 작업은 메일박스(IMAP 또는 Microsoft Graph)를 폴링하고, 읽지 않은 이메일을 다운로드하며, 해당 이메일을 처리하는 작업을 추가합니다. 우리는 사용된 To 이메일 주소에 기반하여 어떤 이메일 핸들러를 사용할지 결정합니다.
  3. 기존 이메일 핸들러 작업들은 문제, Service Desk 문제 또는 기존 문제/병합 요청에 노트를 생성하려고 시도합니다. 이러한 핸들러들은 또한 mail_room을 통한 레거시 이메일 수신에서도 사용됩니다.

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

Sidekiq 작업에 대한 크기 제한을 구현했으며, 특히 첨부 파일이 있는 이메일 작업의 페이로드가 해당 기준을 초과할 가능성이 있습니다. 우리는 이메일 처리를 직접 Sidekiq 메일함 수신 작업에서 다루는 아이디어를 실험해 보아야 합니다. 우리는 ops 기능 플래그를 사용하여 이 모드와 각 이메일에 대한 Sidekiq 작업 간을 전환하는 아이디어를 실험할 수 있습니다.

또한 메시지 ID만 검색하고 나서 완전한 메시지를 다운로드하는 솔루션 경로를 탐색하고 싶습니다(예: UID 범위별로 필터링). 예를 들어, 우리는 메일함을 폴링하고 메시지 ID 목록을 가져옵니다. 그런 다음 각 25개(또는 n개)의 이메일에 대해 메시지 ID나 범위를 인수로 새 작업을 생성합니다. 이러한 작업은 그런 다음 전체 메시지를 다운로드하고 동기적으로 이슈 또는 답장을 추가합니다. 이메일 수가 25개 미만인 경우에는 리소스를 절약하기 위해 심지어 현재 작업에서 직접 이메일을 처리할 수 있습니다. 이를 통해 우리는 작업 페이로드 크기를 이메일 크기의 제한 요인으로부터 제거할 수 있습니다. 이에 따른 단점은 IMAP 서버에 한 번이 아닌 두 번(n+1) 호출을 해야 한다는 것입니다.

실행 계획

  1. mail_room 이메일 수신을 위한 폐지 기능 추가.
  2. gitlab-mail_room gem에서 연결별 로직을 제거하여 새로운 별도의 gem으로 이동. mail_room 및 기타 클라이언트들은 여기서 우리의 작업을 사용할 수 있을 것입니다. 현재는 IMAP 및 Microsoft Graph API 연결을 지원하고 있습니다.
  3. 새로운 작업 추가 (Sidekiq가 실행되지 않았을 때 큰 백로그의 작업을 피하기 위해 idempotency 및 de-duplication 플래그 설정).
  4. gitlab.rb에서 이메일 수신을 Sidekiq 작업 내에서 활성화하는 설정 추가. gitlab.rb에서 mailroom['enabled'] = false를 설정하여 mail_room 이메일 수신을 제거합니다. 추가로 기능 플래그를 추가해도 좋습니다.
  5. GA 전에 gitlab.com에서 사용, 그러나 베타에서 Self-Managed가 시도할 수 있도록 허용.
  6. 일반적인 이용 가능성에 따라 전개된 후 및 제거가 예정된 이후에 gitlab-mail_room에 대한 의존성을 완전히 제거하고, 내부 API 엔드포인트 api/internal/mail_room 제거, mail_room.yml 동적 생성 정적 구성 파일 제거 및 mail_room 및 기타 구성 및 이진 파일을 제거합니다.

변경 관리

우리는 GitLab 16.0에 대해 mail_room의 sidekiq 전달 방식을 폐지하기로 결정하였으며, GitLab 17.0에서 제거되도록 예정하였습니다. 이 청사진을 구현하고 우리의 고객이 새로운 이메일 수신을 사용할 수 있는 경우에만 sidekiq 전달 방식을 제거할 수 있습니다.

그 후 mail_room을 제거하기로 계획했습니다(GitLab 17.0 이후 또는 그 이후). 이것은 중요한 변경사항일 것입니다. 새로운 이메일 수신을 사전에 기본값으로 만들 수 있으므로 Self-Managed 고객이 조치를 취할 필요가 없도록 할 수 있습니다.

대안적인 솔루션

아무 일도 하지 않기

현재 설정은 우리를 제약하고 두 개의 이메일 주소만 검색할 수 있도록 허용합니다. IMAP 또는 API 통합으로 Service Desk 사용자 정의 이메일 주소를 게시하려면 위에 설명된 것과 동일한 아키텍처를 제공해야 합니다. 그로 인해 우리는 현재 시점에서 incoming_email 및 service_desk_email을 위한 일반적인 이메일 수신을 포함하여 인프라 오버헤드를 제거해야 합니다.

추가 리소스

타임라인

  • 2023-09-26: 청사진의 초기 버전이 병합되었습니다.