Aws 이관 설치 문의

문의|Support
1

안녕하세요.

온프라미스 서버를 AWS로 이관하는 작업을 진행중입니다.

관련하여 문의드릴사항이 있습니다.

바쁘시겠지만, 아래사항 답변 부탁드리겠습니다.

1. AS-IS 설치·라이선스 정보
1-1) 현재 버전(EMMA_unix_3.7.1)이 최신인지, Amazon Linux 2023 등 최신 OS에서 지원되는지
1-2) 라이선스가 서버(IP) 기반인지 — IP 기반이면 AWS 신규 Private IP·NAT EIP 사전 등록 필요여부
1-3) AWS 이전 시 라이선스 재발급 필요 여부

1-4) 개발 환경 지원여부( 즉, 개발(Sandbox)환경,운영환경 별도 지원가능한건지 )

1-5) 만약 AWS 설치를 할경우 , Go-Live 시점까지는 온프라이스환경과 AWS환경 함께 Agent가 돌게 될것 같은데,가능한건지요.

2. 기술 연동 요건

  • Agent ↔ DB 연결 방식·필요 권한(em_smt_tran/em_mmt_tran Polling 구조)
  • Agent → InfoBank 문자망 아웃바운드 포트·프로토콜, IP 화이트리스트 필요 여부
  • 발송 실패 시 재처리·Queue Backlog 동작 방식

등 가이드가 필요한 부분 있으면 말씀 부탁드립니다.

3. 설치·이관 지원
3-1) AWS EC2 환경 재설치 지원 가능 여부와 절차
3-2) 기존 설정(발송 이력, 큐 상태 등) 도 이관을 하고 싶은데 가능한지/ 있다면 방법 가이드 필요

확인 부탁드립니다.

2

안녕하세요. 비즈고를 이용해주셔서 감사합니다!

문의주신 내용 답변 드립니다.

  1. AS-IS 설치·라이선스 정보
    1-1) 버전 최신 여부 / Amazon Linux 2023 지원
    현재 사용 중이신 EMMA_unix_3.7.1은 저희 쪽 최신 배포 버전이 맞습니다.
    EMMA는 Java 기반 애플리케이션으로 설계 초기(3.x.x)부터 "Multi-platform Support(Java, Windows, Linux)"를
    지향해왔기 때문에 특정 OS에 종속적인 구조는 아니며, JRE/연동 DB용 JDBC 드라이버만 정상 동작하면
    Amazon Linux 2023에서도 기술적으로 구동 가능합니다.

1-2) IP 기반 라이선스 여부
EMMA는 서버 IP를 라이선스 키에 바인딩하는 방식이 아니라
auth.id/auth.password로 Infobank 인증서버(auth.infobank.net:12001)에 접속하여
인증하는 계정(ID/PW) 기반 인증 구조입니다.
따라서 서버 IP가 바뀌어도 클라이언트(EMMA) 쪽 인증 로직 자체는 영향을 받지 않습니다.

1-3) AWS 이전 시 라이선스 재발급 필요 여부
AWS 이관 시 EMMA 계정 그대로 사용하면 ./cert 디렉토리의 인증키 그대로 사용하면 됩니다.
신규라면 EMMA 계정 별도 발급 요청 후 사용해야 합니다.

1-4) 개발 환경 지원여부( 즉, 개발(Sandbox)환경,운영환경 별도 지원가능한건지 )
기술적으로는 서로 다른 auth.id 계정과 별도의 설치 디렉토리로
완전히 독립된 EMMA 인스턴스를 운영할 수 있어 개발/운영 분리 구성이 가능합니다.
다만 EMMA는 Sandbox가 아닌 다른 개발(테스트) 서버로 접속 관련 계정 발급부터
진행해야 하오니 영업담당자에게 문의 부탁드립니다.

1-5) 만약 AWS 설치를 할경우 , Go-Live 시점까지는 온프라이스환경과 AWS환경 함께 Agent가 돌게 될것 같은데,가능한건지요.
같은 auth.id 계정으로 두 대의 EMMA가 동시에 같은 DB(em_smt_tran/em_mmt_tran)를 폴링하면
동일 메시지가 두 번 발송(중복 발송)되는 문제가 발생할 수 있어 권장하지 않습니다.
별도의 auth.id(테스트/이관용 계정)를 발급받아 AWS에서 EMMA 접속 부탁드립니다.

  1. 기술 연동 요건
    Agent ↔ DB 연결 방식 및 필요 권한

JDBC로 고객사 DB에 직접 연결하며(Oracle/Tibero/MySQL/MariaDB/MSSQL/PostgreSQL/Sybase/DB2 지원),
em_smt_tran/em_mmt_tran과 각각의 로그 테이블(em_smt_log_YYYYMM, em_mmt_log_YYYYMM),
동보 발송용 상세 테이블(em_smt_client/em_mmt_client), 첨부파일 테이블(em_mmt_file) 등에 대한
SELECT/INSERT/UPDATE/DELETE 권한이 필요합니다.
최초 기동 시 관련 테이블/인덱스를 자동 생성하는 저장 프로시저(예: sp_em_smt_create, sp_em_mmt_create)를 실행하므로,
CREATE TABLE/INDEX 및 저장 프로시저 EXECUTE 권한도 필요합니다. (이미 테이블이 존재하면 자동으로 건너뜁니다.)
폴링 방식: 내부 큐 조회 주기는 que.pollinginterval(기본 2초) 설정을 따르며,
각 Distributor/Collector 워커 스레드가 주기적으로 대상 테이블을 SELECT하여 처리합니다.

Agent → InfoBank 문자망 아웃바운드

1차로 auth.infobank.net:12001(TCP)로 접속해 계정 인증을 수행하고,
인증 성공 후 반환되는 세션 정보를 통해 실제 발송 게이트웨이(TCP 소켓, 자체 프로토콜)로 재접속하는 구조입니다.
게이트웨이 서버의 실제 IP/포트는 설정 파일에 고정되어 있지 않고 인증 응답으로 동적으로 전달되는 구조라,
Outbound 방화벽 정책에는 auth.infobank.net:12001 + GW 주소/포트 아웃바운드는 필요합니다.

발송 실패 시 재처리 / Queue Backlog 동작

발송 대기 메시지는 로컬 파일 큐(디스크 기반)에 적재되며,
연결 장애 중에도 큐에 쌓인 상태로 보존되었다가 연결 복구 시 순차 발송됩니다.

  1. 설치·이관 지원
    3-1) AWS EC2 재설치 지원
    지원 가능 여부는 영업담당자에게 문의 부탁드립니다.

3-2) 기존 발송 이력·큐 상태 이관

발송 이력(DB 데이터): em_mmt_tran/em_smt_tran 및 로그 테이블 데이터는 일반적인 DB 마이그레이션(덤프/복제 등)으로 이관 가능합니다.
큐 상태(로컬 파일 큐): 서버 로컬 디스크에 저장되는 구조라, 전환 시점에 큐가 완전히 비워진(Drain) 상태에서 전환하시는 것을 권장드립니다.
큐에 남은 메시지까지 그대로 옮기는 것은 기술적으로 까다로워, 가능하면 온프레미스 발송을 먼저 중단 → 큐 Drain 확인 → AWS로 전환 순서를 권장드립니다.