Transcript 지하철_API_데이터 연계방안_V1.2

서울시 지하철 공공 데이터
Open API 개방 연계데이터 처리안
한국정보공학D&S
주식회사 오픈 소스 컨설팅
2015.02.06
한국정보공학D&S 최종희 부장
목차
1.
개요
2.
AS-IS 시스템 아키텍처
3.
교통정보센터 지하철 API 연계 방안
3.1 (1안) Tmax 어댑터를 통한 DB 저장
3.2 (2안) 신규 WAS 영역 서버 API 호출
3.3 (3안) 지하철 파일 데이터 전송을 통한 처리
3.4 실시간 데이터 연계방안 장단점 정리
4. 기반정보 연계방안
5. 요구사항 선택
2
- Internal Use Only -
1. 개요
본 문서는 지하철 6개 기관의 데이터를 수집하여 서울시 열린 데이터 광장에서 서비스 될 수
있도록 연계 아키텍처 구성안 및 고려사항을 기술
목적
연계 아키텍처
• AS-IS 시스템 기준 TO-BE 환경에 대한 도출 및 아키텍처 방향성 확인, 결정을 위한
도구 활용
• 현재 운영중인 버스API의 지하철 데이터 정보 연계에 대한 방안 수립
• 각 방안에 대한 장단점 제시 및 최적의 아키텍처 선택을 위한 가이드 라인 제시
3
- Internal Use Only -
2. AS-IS 시스템 아키텍처
지하철 데이터는 FTP를 통해 미들웨어로 전송
미들웨어에서 해당 데이터를 OPEN API DB로 저장
OPEN API-DB
통합가공
서버
OPEN API WEB
DB #1
Middleware #1, 2
WAS
지하철 위치, 도착
지하철 수집데이터
Middleware(Tmax)
Middleware(Tmax)
Unix
Unix
통합 DB
USER
Unix
DB #2
DB #1
VPN
서울시 교통정보과
Routing(90.XX.XX.XX)
1호선 서울 메트로
2-4호선 서울 메트로
5-8호선 서울도시철도
9호선 메트로9
신분당선
공항철도
Windows 2008 R2 64bit
Windowds 2003 R2
Windowds 2003 R2
Windows 2008 R2 64bit
Windows 2008 R2 64bit
Windows 2008 R2 64bit
Dell Power Edge (1core/4G)
ROBO-8713 VGA
ROBO-8713 VGA(1core/2G)
Dell Power Edge (1core/4G)
IBM X3250(1core/4G)
IBM X3250(1core/4G)
1) QPS: Query per Second, 초당 쿼리 건수
4
- Internal Use Only -
3. 교통정보센터 지하철 API 연계 방안
6개 기관에서 전달되는 데이터에 대한 신규 시스템 연계 방법에 대한 3가지 방안을 별도로 제시
미들웨어(Tmax)에서의 파일 전송, REST API호출, 파일 전송의 3가지 방법에 대한 고려
신규 시스템 구축 영역
지하철 API DB
지하철 미들웨어
DB #1
3. 파일 전송
지하철 WEB
WAS
Apache
x86 Linux
x86 Linux
1. Tmax를 통한 저장
2. REST API 호출
1안
2안
Middleware #1, 2
3안
지하철 수집데이터
VPN
OPEN API-DB
Middleware(Tmax)
Middleware(Tmax)
Unix
Unix
지하철 위치, 도착
DB #1
서울시 교통정보과
WAS
: Web Application Server(JBoss EWS)
5
- Internal Use Only -
USER
3.1 (1안) Tmax 어댑터를 통한 DB 저장
구분
내용
- 미들웨어에서 수집되어 OPEN API DB에 저장, 이후 금번 구축되는 DB에 추가로 데이터 저장
방식
- 교통정보센터의 데이터 저장 로직에 신규 지하철 DB에 대한 저장 로직 추가
장점
- 기존 애플리케이션에 대한 부가적인 공수를 통한 추가 로직 구현이 최소화
- 기존 버스 API DB에 저장하는 로직에 신규 지하철 API로 저장하는 로직 추가
단점
- 데이터 조회에 대한 지연(Delay)을 줄이기 위한 최소 시간 동기화 처리 방식 필요
지하철 API DB
DB #1
OPEN API-DB
1. Tmax를 통한 저장
Middleware #1, 2
지하철 수집데이터
DB #1
통합 DB
지하철 위치, 도착
Middleware(Tmax)
Middleware(Tmax)
Unix
Unix
DB #1
VPN
DB #2
서울시 교통정보과
6
- Internal Use Only -
3.2 (2안) 신규 WAS 영역 서버 API 호출
구분
내용
방식
- Tmax에서 지하철 데이터 파싱 후 신규 운영 WAS 서버의 REST API를 호출하여 동기화
장점
- - Tmax에서 파싱된 정보를 실시간을 클라이언트에 제공할 수 있음
- 신규 시스템의 DB 장애에 대한 우려 사항이 없음
단점
- Tmax 미들웨어에서 별도의 REST API 호출에 대한 기능 구현이 필요
- 지하철 API 서버에도 REST API 호출에 대한 기능 구현이 필요
지하철 API 서버
DB
WAS
#1
X86 Linux
OPEN API-DB
2. REST API 호
출
Middleware #1, 2
지하철 수집데이터
DB
#1
통합 DB
지하철 위치, 도착
Middleware(Tm
ax)
Middleware(Tm
Unix ax)
Unix
DB
#1
VPN
DB
#2
서울시 교통정보과
7
- Internal Use Only -
3.3 (3안) 지하철 파일 데이터 전송을 통한 처리
구분
내용
방식
- 각 지하철 연계서버에서 Tmax로 전송하는 데이터를 신규 지하철 API 서버로 동시 전송
장점
- 교통정보센터: 시스템 부담을 줄이며, 별도의 코드 수정, 추가 작업이 필요 없음
- 지하철 실시간 형태의 정보를 바로 로딩 가능
- 데이터베이스 의존도 제거 가능
단점
- 신규 시스템의 개발 공수가 추가: 파일 파싱, 데이터 저장, 처리 등
- 지하철 연계서버에 추가로 클라이언트 프로그램 설치
- 지하철 연계서버와의 통신과 데이터에 대한 품질 점검등 추가 업무 발생
지하철 API 서버
지하철 WEB
3.파일 데이터
Apache
WAS
DB #1
x86 Linux
X86 Linux
VPN
Routing(90.XX.XX.XX)
client
client
client
client
client
client
1호선 서울 메트로
2-4호선 서울 메트로
5-8호선 서울도시철도
9호선 메트로9
신분당선
공항철도
Windows 2008 R2 64bit
Windowds 2003 R2
Windowds 2003 R2
Windows 2008 R2 64bit
Windows 2008 R2 64bit
Windows 2008 R2 64bit
Dell Power Edge (1core/4G)
ROBO-8713 VGA
ROBO-8713 VGA(1core/2G)
Dell Power Edge (1core/4G)
IBM X3250(1core/4G)
IBM X3250(1core/4G)
8
- Internal Use Only -
3.4 실시간 데이터 연계방안 장단점 정리
1안 : Tmax 어댑터를 통한 DB 저장
구분
내용
-
미들웨어에서 수집되어 OPEN API DB에 저장, 이후 금번 구축되는 DB에 추가로 데이터 저장
-
교통정보센터의 데이터 저장 로직에 신규 지하철 DB에 대한 저장 로직 추가
장점
-
기존 애플리케이션에 대한 부가적인 공수를 통한 추가 로직 구현이 최소화
기존 버스 API DB에 저장하는 로직에 신규 지하철 API로 저장하는 로직 추가
단점
-
데이터 조회에 대한 지연(Delay)을 줄이기 위한 최소 시간 동기화 처리 방식 필요
방식
2안 : 신규 WAS 영역 서버 API 호출
구분
내용
방식
-
각 지하철 연계서버에서 Tmax로 전송하는 데이터를 신규 지하철 API 서버로 동시 전송
장점
-
교통정보센터: 시스템 부담을 줄이며, 별도의 코드 수정, 추가 작업이 필요 없음
지하철 실시간 형태의 정보를 바로 로딩 가능
데이터베이스 의존도 제거 가능
단점
-
신규 시스템의 개발 공수가 추가: 파일 파싱, 데이터 저장, 처리 등
지하철 연계서버에 추가로 클라이언트 프로그램 설치
지하철 연계서버와의 통신과 데이터에 대한 품질 점검등 추가 업무 발생
3안 : 지하철 파일 데이터 전송을 통한 처리
구분
내용
방식
-
각 지하철 연계서버에서 Tmax로 전송하는 데이터를 신규 지하철 API 서버로 동시 전송
장점
-
교통정보센터: 시스템 부담을 줄이며, 별도의 코드 수정, 추가 작업이 필요 없음
지하철 실시간 형태의 정보를 바로 로딩 가능
데이터베이스 의존도 제거 가능
단점
-
신규 시스템의 개발 공수가 추가: 파일 파싱, 데이터 저장, 처리 등
지하철 연계서버에 추가로 클라이언트 프로그램 설치
지하철 연계서버와의 통신과 데이터에 대한 품질 점검등 추가 업무 발생
9
- Internal Use Only -
4. 기반정보 연계방안
구분
내용
방식
- 버스 OPEN API DB 에서 제공하는 View 형태로 기반정보를 제공 받는다
장점
- 직관적 연계 방식
- 통합 DB에서 추가적인 외부 연결에 대한 설정이 필요 없음
단점
- 지속적인 조회 시 버스 OPEN API DB의 부하문제
(지하철 API 미들 웨어에서 캐쉬 처리를 하여 부하문제 해결 가능)
지하철 API DB
DB #1
버스 OPEN API-DB
View 제공
DB #1
통합 DB
DB #1
DB #2
서울시 교통정보과
10
- Internal Use Only -
5. 요구사항 선택
선택방안
구분
내용
선택방안
실시간 정보
1안 : Tmax 어댑터를 통한 DB 저장
- 짧은 개발 기간내에 안정적인 서비스가 가능
장점
- 각 시스템간 인터페이스가 간단하여 신뢰성 있는 연계가 가능
- 네트워크 셋팅의 간소화
- 기존의 안정적인 유지관리로 신뢰성 있는 지하철 정보의 연계가 가능
기반정보
선택방안
버스 API 에서 사용되는 방식인 뷰 테이블 형태로 제공 받도록 한다.
11
- Internal Use Only -