AdminID.kr (어드민아이디) - 미들웨어

하둡 분산 파일 시스템: 구조와 설계(The Hadoop Distributed File System: Architecture and Design)

2012-07-17T14:44:31+00:00

번역 문서 보기

원본 문서 보기

하둡 분산 파일 시스템: 구조와 설계

The Hadoop Distributed File System: Architecture and Design

by Dhruba Borthakur
Translated by INHWAN HWANG. http://www.virgo81.net / virgo81@gmail.com

1. 소개 (Introduction) 4
2. 가정과 목표 (Assumptions and Goals) 5
    2.1. 하드웨어 실패 (Hardware Failure) 5
    2.2. 스트리밍 데이터 접근 (Streaming Data Access) 5
    2.3. 대용량 데이터 집합 (Large Data Sets) 5
    2.4. 단순 간섭 모델 (Simple Coherency Model) 5
    2.5. “데이터를 옮기는 것 보다 계산을 옮기는 것이 저렴하다.” (“Moving Computation is Cheaper than Moving Data”) 5
    2.6. 이종 하드웨어와 소프트웨어 플랫폼으로의 이식성 (Portability Across Heterogeneous Hardware and Software Platforms) 6
3. 네임노드와 데이터노드 (Namenode and Datanodes) 7
4. 파일 시스템 네임스페이스 (The File System Namespace) 9
5. 데이터 복제 (Data Replication) 10
    5.1. 복제 배치: 걸음마 (Replica Placement: The First Baby Steps) 10
    5.2. 복제 선택 (Replica Selection) 11
    5.3. 안전모드 (SafeMode) 11
6. 파일 시스템 메타데이터의 영속 (Persistence of File System Metadata) 11
7. 통신 프로토콜 (The Communication Protocols) 13
8. 견고성 (Robustness) 14
    8.1. 데이터 디스크 실패, 심장 박동 그리고 재 복제 (Data Disk Failure, Heartbeats and Re-Replication) 14
    8.2. 클러스터 재 균형 (Cluster Rebalancing) 14
    8.3. 데이터 일관성 (Data Integrity) 14
    8.4. 메타데이터 디스크 실패 (Metadata Disk Failure) 15
    8.5. 스냅샷 (Snapshots) 15
9. 데이터 구성 (Data Organization) 16
    9.1. 데이터 블록 (Data Blocks) 16
    9.2. 옮겨 바꾸기 (Staging) 16
    9.3. 복제 파이프라이닝 (Replication Pipelining) 16
10. 접근 성... 18
    10.1. DFSShell 18
    10.2. DFSAdmin. 18
    10.3. 브라우저 인터페이스 (Browser Interface) 18
11. 공간 교정 (Space Reclamation) 19
    11.1. 파일 삭제 및 복원... 19
    11.2. 복제 인수 감소 (Decrease Replication Factor) 19
12. 참고문헌 (References) 20

1. 소개 (Introduction)

하둡 분산 파일 시스템(Hadoop Distributed File System, HDFS)은 기성 하드웨어에서 실행할 수 있도록 디자인된 분산 파일 시스템입니다. 그것은 기존의 분산 파일 시스템과 많은 유사성을 가지고 있습니다.
그러나, 다른 분산 파일 시스템과의 차이점은 매우 큽니다. HDFS는 상당히 내(耐)고장(fault-tolerant)하고 저비용 하드웨어를 통해 배포할 수 있도록 설계되었습니다. HDFS는 응용 프로그램 데이터의 접근에 높은 처리량을 제공하고, 대용량 데이터 집합을 갖는 응용 프로그램에 적합합니다.
HDFS는 파일 시스템 데이터의 스트리밍 접근을 가능하게 하기 위해 약간의 POSIX 요구사항을 게을리하였습니다. HDFS는 애초에 아파치 넛치(Apache Nutch) 웹 검색 엔진 프로젝트를 위한 하부 구조로써 만들어졌습니다.
HDFS는 아파치 루씬(Apache Lucene) 프로젝트의 부분인 아파치 하둡(Apache Hadoop) 프로젝트의 부분입니다. 프로젝트의 URL은 http://projects.apache.org/projects/hadoop.html 입니다.

2. 가정과 목표 (Assumptions and Goals)

2.1. 하드웨어 실패 (Hardware Failure)

하드웨어 실패는 예외와는 뚜렷하게 다른 기준입니다. HDFS 인스턴스는 파일 시스템의 데이터의 부분을 저장하는 서버 장비의 수백 또는 수천으로 구성될 수 있습니다. 사실 대단히 많은 구성요소가 존재하고 각 구성요소는 불분명한 실패의 확률을 갖습니다. 즉, HDFS의 일부 구성요소는 항상 기능을 수행하지 못합니다. 따라서 결함의 탐지와 빠르고 자동적인 복구는 HDFS의 핵심적인 구조적 목표입니다.

2.2. 스트리밍 데이터 접근 (Streaming Data Access)

HDFS에서 수행되는 응용 프로그램은 그들의 데이터 집합을 위하여 스트리밍 접근을 필요로 합니다. 그들은 일반적으로 일반적인 목적의 파일 시스템에서 수행되는 일반적인 목적의 응용 프로그램이 아닙니다. HDFS는 사용자에 의한 상호작용적(interactive) 사용 대신 배치 프로세싱에 더 적합하게 설계되었습니다. 강점은 데이터 접근의 낮은 지연(low latency)보다 데이터 접근의 높은 처리입니다. POSIX는 HDFS가 대상으로 하는 응용 프로그램이 필요로 하지 않는 많은 어려운 요구사항을 부과합니다. 약간의 키 영역들의 POSIX 의미론(semantics)은 데이터 처리율의 향상으로 교환되었습니다.

2.3. 대용량 데이터 집합 (Large Data Sets)

HDFS에서 수행되는 응용 프로그램은 대용량 데이터 집합을 가집니다. HDFS에서의 일반적인 파일은 기가 바이트부터 테라 바이트의 용량입니다. 따라서, HDFS는 대용량 파일들을 지원할 수 있도록 조정(tuned)되었습니다. 그것은 높은 총 데이터 대역폭과 단일 클러스터에서의 수백 노드로의 확장을 제공해야 합니다. 또한 단일 인스턴스에서 수 천만 파일을 제공해야 합니다.

2.4. 단순 간섭 모델 (Simple Coherency Model)

HDFS 응용 프로그램은 파일에 대해 한번 쓰고 여러 번 읽는(write-once-read-many) 접근 모델을 필요로 합니다. 파일이 한번 생성되고, 쓰여지고, 닫히면 변화를 필요로 하지 않습니다. 이런 가정은 데이터 간섭 이슈를 단순화하고 높은 처리량의 데이터 접근을 가능하게 합니다. MapReduce 응용 프로그램 또는 웹 크롤러 응용 프로그램은 이 모델에 완벽하게 적합합니다. 미래에는 파일에 추가-쓰기(appending-writes)를 제공할 계획이 있습니다.

2.5. “데이터를 옮기는 것 보다 계산을 옮기는 것이 저렴하다.” (“Moving Computation is Cheaper than Moving Data”)

응용 프로그램에 의해 요청된 계산은 만약 그것이 수행하는 데이터 근처에서 실행된다면 보다 더 효율적입니다. 이것은 데이터 집합의 사이즈가 대단히 클 때 특히 사실입니다. 이것은 네트워크 혼잡을 최소화 시키고 시스템의 전체적 처리량을 증가시킵니다. 가정은 응용 프로그램이 수행 되는 곳으로 데이터를 옮기는 것 보다 데이터 가까이로 계산을 옮기는 것이 더 낫다는 것 입니다. HDFS는 데이터가 위치한 곳 가까이로 그들을 옮길 수 있도록 응용 프로그램을 위한 인터페이스를 제공합니다.

2.6. 이종 하드웨어와 소프트웨어 플랫폼으로의 이식성 (Portability Across Heterogeneous Hardware and Software Platforms)

HDFS는 한 플랫폼에서 다른 플랫폼으로 쉽게 이식할 수 있도록 디자인되었습니다. 이것은 응용 프로그램의 대형 집합을 위한 선택의 플랫폼으로써 HDFS의 광범위한 적용을 용이하게 했습니다.

3. 네임노드와 데이터노드 (Namenode and Datanodes)

HDFS는 주/종 구조를 가지고 있습니다. HDFS 클러스터는 파일 시스템 네임스페이스를 관리하고 클라이언트에 의한 파일 접근을 통제하는 마스터 서버인 단일 네임노드로 구성됩니다. 추가적으로 클러스터에서 노드 당 하나며 노드에 붙은 스토리지를 관리하는 수 많은 데이터노드가 있습니다. HDFS는 파일 시스템 네임스페이스를 노출하고 사용자의 데이터를 파일로 저장되도록 허용합니다. 내부적으로 파일은 하나 또는 그 이상의 블록으로 쪼개지며 이러한 블록들은 데이터노드의 집합 안에 저장됩니다. 네임노드는 파일과 디렉터리의 열기, 닫기, 이름 변경과 같은 파일 시스템 네임스페이스 동작을 수행합니다. 또한 데이터노드로의 블록의 매핑을 판단합니다. 데이터노드는 파일 시스템의 클라이언트들로부터의 읽기와 쓰기 요청을 제공하는 역할을 합니다. 또한 네임노드의 지시에 따라 블록 생성, 삭제 그리고 복제를 수행합니다.

네임노드와 데이터노드는 기성 기계에서 실행하도록 설계된 소프트웨어의 조각입니다. 이러한 기계들은 일반적으로 GNU/Linux 운영체제(OS)를 수행합니다. HDFS는 Java 언어를 이용하여 만들었습니다; Java를 지원하는 어떤 기계도 네임노드 또는 데이터노드 소프트웨어를 수행할 수 있습니다. 높은 이식성의 Java 언어의 사용은 HDFS가 광범위한 기계에 배포될 수 있음을 의미합니다. 일반적인 배포는 네임노드만을 수행하는 전용의 기계를 가지고 있습니다. 클러스터에서의 각각의 다른 기계들은 데이터노드 소프트웨어의 한 인스턴스를 수행합니다. 구조는 같은 기계에서의 여러 데이터노드 수행을 제한하지는 않지만 실제 배포에서는 드문 경우 입니다.
클러스터에서의 단일 네임노드의 존재는 시스템의 구조를 대단히 단순화시킵니다. 네임노드는 모든 HDFS 메타데이터를 위한 중재자 그리고 저장소입니다. 시스템은 사용자 데이터는 결코 네임노드를 통해 흐르지 않도록 설계되었습니다.

4. 파일 시스템 네임스페이스 (The File System Namespace)

HDFS 전통적인 계층적 파일 구조를 지원합니다. 사용자 또는 응용 프로그램은 디렉터리를 생성할 수 있고 디렉터리에 파일을 저장할 수 있습니다. 파일 시스템 네임스페이스 계층은 대부분의 다른 기존 파일 시스템들과 유사합니다; 파일을 생성하고 지울 수 있고, 하나의 디렉터리에서 다른 디렉터리로 파일을 복사할 수 있고, 파일 이름을 바꿀 수 있습니다. HDFS에 사용자 한도 량(quotas)과 접근 허가(permissions)는 아직 구현되지 않았습니다. HDFS는 하드 링크와 소프트 링크를 지원하지 않습니다. 그러나, HDFS 구조는 이러한 특징들의 구현을 제한하지는 않습니다.
네임노드는 파일 시스템 네임스페이스를 유지합니다. 파일 시스템 네임스페이스 또는 그것의 속성에 가해지는 어떠한 변화도 네임노드에 의해 기록됩니다. 응용 프로그램은 HDFS에 의해 유지되어야 하는 복제 개수를 명기할 수 있습니다. 파일의 사본 수는 그 파일의 복제 인수라 불립니다. 이러한 정보는 네임노드에 의해 저장됩니다.

5. 데이터 복제 (Data Replication)

HDFS는 대단위 클러스터에 매우 큰 파일들을 견실히 저장할 수 있도록 설계되었습니다. 그것은 각 파일을 블록의 순서로 저장합니다; 파일에서의 마지막 블록을 제외한 모든 블록은 같은 크기입니다. 파일의 블록들은 내(耐)고장을 위해 복제됩니다. 블록 사이즈와 복제 인수는 파일마다 설정할 수 있습니다. 응용 프로그램은 파일의 복제의 수를 명기할 수 있습니다. 복제 인수는 파일 생성 시 명기되고 이후에 수정될 수 있습니다. HDFS의 파일은 바꿔 쓰기가 안되고(write-once) 엄격하게 말하면 언제나 하나의 작성자를 갖습니다.
네임스페이스는 블록의 복제에 관하여 모든 결정을 합니다. 그것은 심장 박동(Heartbeat)과 블록리포트(Blockreport)를 클러스터 내의 각 데이터노드로부터 주기적으로 받습니다.

5.1. 복제 배치: 걸음마 (Replica Placement: The First Baby Steps)

복제의 배치는 HDFS 신뢰성과 성능에 중요합니다. 복제 배치의 최적화는 HDFS를 대부분의 다른 분산 파일 시스템과 구분시킵니다. 이것은 많은 조정과 경험이 필요한 특징입니다. 랙을 아는(rack-aware) 복제 배치 정책의 목적은 데이터 신뢰성, 가용성 그리고 네트워크 대역폭 이용을 증대시키는 것 입니다. 복제 배치 정책을 위한 현재의 구현은 이 방향에서의 첫 번째 노력입니다. 이 정책을 구현하는 단기 목표는 상용 시스템에 그것을 검증하고, 그것의 행동에 대해 더 배우고, 그리고 테스트와 연구를 좀 더 정교하게 하는 기반을 만드는 것입니다.
대형 HDFS 인스턴스는 일반적으로 많은 랙에 널리 퍼진 컴퓨터의 클러스터에서 수행합니다. 다른 랙에 있는 두 노드 사이의 통신은 스위치를 통해야만 합니다. 대부분의 경우 같은 랙 안의 기계 간에 네트워크 대역폭은 다른 랙 안의 기계 간의 네트워크 대역폭보다 훨씬 큽니다.
시작할 때, 각 데이터노드는 속해있는 랙을 판단하고 등록 시에 네임노드에게 자신의 랙의 아이디를 알립니다. HDFS는 기계의 랙 아이디를 판단하는데 사용되는 플러그 할 수 있는(pluggable) 모듈을 용이하게 하기 위한 API들을 제공합니다. 단순하지만, 최적화되지 않는 정책은 복제를 유일한 랙들에 위치 시키는 것 입니다. 이것은 전체 랙이 실패할 때 데이터를 잃는 것을 방지하고 데이터를 읽을 때 여러 랙으로부터의 대역폭의 사용을 허락합니다. 이 정책은 클러스터 안의 복제를 공평하게 분배합니다. 이 정책은 구성요소 실패 시에도 부하 균형을 쉽게 만들어 줍니다. 그러나 이 정책은 쓰기는 블록을 여러 랙으로 전송해야 하기 때문에 쓰기 비용을 증가 시킵니다.
일반적인 경우, 복제 인수가 3이고, HDFS의 배치 정책은 첫 복제를 로컬 랙의 하나의 노드에 놓고, 다른 하나를 로컬 랙의 다른 노드에 넣고 마지막 하나를 다른 랙의 다른 노드에 넣습니다. 이 정책은 랙 사이의 쓰기 트래픽을 감소 시키고 일반적으로 쓰기 성능을 향상시킵니다. 랙 실패의 기회는 노드 실패의 기회보다 훨씬 적습니다; 이 정책은 데이터 신뢰성과 가용성 보장에 영향을 주지 않습니다. 그러나 블록이 유일한 3개의 랙 대신 2개의 랙에 위치하기 때문에 데이터를 읽을 때 사용되는 총 네트워크 대역폭은 감소 시킵니다. 이 정책으로 파일의 복제는 랙 사이에 공평하게 분배되지 않습니다. 복제의 1/3은 한 노드에 있고, 복제의 2/3은 하나의 랙에 있고 복제의 1/3은 나머지 랙에 공평하게 분배됩니다. 이 정책은 데이터 신뢰성 또는 읽기 성능의 손상 없이 쓰기 성능을 향상시킵니다.
여기에 설명된 현재의 기본 복제 배치 정책은 진행 중인 작업 입니다.

5.2. 복제 선택 (Replica Selection)

전체 대역폭 소비와 읽기 지연을 최소화하기 위해 HDFS는 독자로부터 가까운 복제로부터 읽기 요구를 만족 시키는 것을 노력합니다. 만약 독자 노드와 같은 랙에 복제가 존재하면 그 복제가 읽기 요구를 만족 시키기 위해 선호됩니다. 만약 HDFS 클러스터가 여러 데이터 센터로 확장한다면 로컬 데이터 센터에 거주하는 복제가 어떠한 원격 복제보다 선호됩니다.

5.3. 안전모드 (SafeMode)

시작 시, 네임노드는 안전모드라 불리는 특별한 상태에 진입합니다. 데이터 블록의 복제는 네임노드가 안전모드 상태일 때 발생하지 않습니다. 네임노드는 데이터노드로부터 심장 박동(Heartbeat)과 블록리포트 메시지를 받습니다. 블록리포트는 데이터 노드가 호스팅하고 있는 데이터 블록의 목록을 포함합니다. 각 블록은 명기된 복제의 최소 수를 갖고 있습니다. 블록은 네임노드로에 점검된 데이터 블록의 복제의 최소 수 일 때 안전하게 복제된(safely replicated) 것으로 고려됩니다. 안전하게 복제된 데이터 블록의 설정 가능한 백분율이 네임노드와 점검한 이후에 (추가적으로 30초를 더함), 네임노드는 안전모드 상태를 벗어납니다. 그리고 나서 여전히 명기된 수보다 적은 데이터 블록의 목록을 판단합니다. 네임노드는 그리고 나서 이 블록들을 다른 데이터노드에 복제합니다.

6. 파일 시스템 메타데이터의 영속 (Persistence of File System Metadata)

HDFS 네임스페이스는 네임노드에 의해 저장됩니다. 네임노드는 영속적으로 파일 시스템 메타데이터에 발생하는 변화를 기록하기 위해 EditLog라 불리는 트랜잭션 로그를 사용합니다. 예를 들면 HDFS에서의 새 파일 생성은 네임노드에게 이것을 가리키는 기록을 EditLog에 넣는 것 유발합니다. 비슷하게 파일의 복제 인수의 변경도 EditLog로의 새로운 기록 삽입을 유발합니다. 네임노드는 EditLog를 저장하기 위해 그것의 지역 호스트 OS 파일 시스템 안의 파일을 사용합니다. 블록에서 파일로의 매핑과 파일 시스템 속성을 저장하는 전체 파일 시스템 네임스페이스는 FsImage라 불리는 파일 안에 저장됩니다. 또한 FsImage는 네임노드의 로컬 파일 시스템 안의 파일로 저장됩니다.
네임노드는 전체 파일 시스템 네임스페이스와 메모리 안의 파일 블록맵의 이미지를 유지합니다. 이 키 메타데이터 항목은 4GB의 램을 가진 네임노드가 거대한 수의 파일과 디렉터리를 지원하기에 충분하도록 작고 경제적으로 설계되었습니다. 네임노드가 시작하면 FsImage와 EditLog를 디스크로부터 읽고 EditLog로부터 모든 트랜잭션을 FsImage의 메모리 내 표현으로 적용하고 이 새 버전을 디스크의 새 FsImage로 내보냅니다. 그리고 나서 그것의 트랜잭션은 영속적으로 FsImage에 적용되었기 때문에 기존 EditLog를 버립니다. 이런 과정을 체크포인트(checkpoint)라 부릅니다. 현재 구현에서는 체크포인트는 네임노드가 시작할 때만 발생합니다. 가까운 미래에 주기적으로 체크포인팅을 지원하는 작업은 진행 중입니다.
데이터노드는 로컬 파일 시스템의 파일에 HDFS 데이터를 저장합니다. 데이터노드는 HDFS 파일에 관한 지식을 가지고 있지 않습니다. 그것은 그것의 로컬 파일 시스템의 분리된 파일에 HDFS의 각 블록을 저장합니다. 데이터노드는 모든 파일을 같은 디렉터리에 생성하지 않습니다. 대신에 디렉터리 당 파일의 최적화된 수를 판단하고 적절하게 부 디렉터리를 생성하기 위해 휴리스틱(heuristic)을 사용합니다. 같은 디렉터리 내에 모든 로컬 파일을 생성하는 것은 로컬 파일 시스템이 한 디렉터리에 대량의 파일 수를 효과적으로 지원할 수 없기 때문에 최적화가 아닙니다. 데이터노드가 시작할 때 로컬 파일 시스템을 통해 검사하고 로컬 파일 시스템 각각에 상응하는 모든 HDFS 데이터 블록의 목록을 생성하고 네임노드로 보고 합니다: 이것이 블록리포트 입니다.

7. 통신 프로토콜 (The Communication Protocols)

모든 HDFS 통신 프로토콜은 TCP/IP 프로토콜 최상에 계층화되어 있습니다. 클라이언트는 네임노드 기계 상의 설정 가능한 TCP 포트로 연결을 설정합니다. 그것은 네임노드와 클라이언트프로토콜(ClientProtocol)로 말합니다. 데이터노드는 데이터노드프로토콜(DatanodProtocol)을 이용하여 네임노드에게 말합니다. 원격 프로시저 호출(Remote Procedure Call, RPC) 추상은 클라이언트프로토콜과 데이터노드프로토콜로 포장합니다. 설계에 의하면 네임노드는 어떠한 RPC들도 초기화하지 않습니다. 대신에 그것은 단지 데이터노드와 클라이언트들에 의해 발행된 RPC 요청들만 응답합니다.

8. 견고성 (Robustness)

HDFS의 주된 목표는 실패의 발생에서 조차도 데이터를 견실히 저장하는 것입니다. 실패의 세 일반적인 형식은 네임노드 실패, 데이터노드 실패 그리고 네트워크 분할 입니다.

8.1. 데이터 디스크 실패, 심장 박동 그리고 재 복제 (Data Disk Failure, Heartbeats and Re-Replication)

각 데이터노드는 네임노드로 심장 박동(Heartbeat) 메시지를 주기적으로 보냅니다. 네트워크 분할은 데이터노드의 부분집합이 네임노드와의 연결을 잃게 하는 것을 유발 시킬 수 있습니다. 네임노드는 심장 박동(Heartbeat) 메시지의 부재를 통해 이런 조건을 발견합니다. 네임노드는 최근 심장 박동(Heartbeat)이 없는 데이터노드를 죽은 것으로 표시하고 새로운 IO 요청을 그들에게 전달하지 않습니다. 죽은 데이터 노드에 등록된 어떤 데이터도 더 이상 HDFS에서 사용 가능하지 않습니다. 데이터노드 죽음은 복제 인수를 어떤 블록의 그들의 명기된 값 이하로 떨어지는 것을 유발합니다. 네임노드는 끊임없이 어떤 블록이 복제되어야 하는지 추적하고 필요할 때 복제를 시작합니다. 재 복제의 필요성은 여러 원인에 의해 발생합니다: 데이터노드가 사용 가능하지 않을 수 있고, 복제가 잘못 될 수도 있고, 데이터노드의 하드디스크가 실패할 수도 있고, 파일의 복제 인수가 증가되었을 수도 있습니다.

8.2. 클러스터 재 균형 (Cluster Rebalancing)

HDFS 구조는 데이터 재 균형 계획(scheme)과 호환 가능합니다. 계획은 만약 데이터노드의 여유 공간이 특정 임계 값 아래로 떨어졌을 때 자동적으로 데이터를 하나의 데이터노드에서 다른 노드로 이동시킬 수 있습니다. 특정 파일에 대한 갑작스런 높은 요구에 계획은 동적으로 추가적인 복제를 생성할 수 있고 클러스터 내의 다른 데이터를 재 균형 시킬 수 있습니다. 데이터 재 균형 계획의 이런 형식은 아직 구현되지 않았습니다.

8.3. 데이터 일관성 (Data Integrity)

데이터노드로부터 가져온 데이터의 블록이 잘못될 수 있습니다. 이러한 변조는 저장 장치의 결함, 네트워크 결함 또는 오류 있는 소프트웨어에 의해 발생할 수 있습니다. HDFS 클라이언트 소프트웨어는 HDFS 파일의 내용을 확인하기 위해 검사 합(checksum)을 구현합니다. 클라이언트가 HDFS 파일을 생성할 때, 파일의 각 블록의 검사 합(checksum)을 계산하고 이 검사 합(checksum)을 같은 HDFS 네임스페이스 안의 분리된 숨겨진 파일로 저장합니다. 클라이언트가 파일 내용을 탐색할 때 연관된 검사 합(checksum) 파일로 저장된 검사 합(checksum)을 데이터와 검증합니다. 만약 아니라면 클라이언트는 그 블록의 복제를 가진 다른 데이터노드로부터 블록을 탐색하는 것을 선택할 수 있습니다.

8.4. 메타데이터 디스크 실패 (Metadata Disk Failure)

FSImage와 EditLog는 HDFS의 중심 데이터 구조입니다. 이러한 파일의 변조는 HDFS 인스턴스를 동작하지 않게 할 수 있습니다. 이러한 이유로 네임노드는 FsImage와 EditLog의 여러 사본의 관리를 지원하도록 설정될 수 있습니다. FsImage 또는 EditLog의 어떠한 갱신도 FsImage들과 EditLog들의 각각의 동기적인 갱신을 유발합니다. FsImage와 EditLog의 여러 사본의 동기적인 갱신은 네임노드가 지원할 수 있는 초 당 네임스페이스 트랜잭션의 비율을 감소시킬 수 있습니다. 그러나 이러한 감소는 HDFS 태생적으로 응용 프로그램이 데이터 집중적이지 메타데이터 집중적이지 않기 때문에 수용할만합니다. 네임노드가 재 시작할 때 마지막 일관된 FsImage와 EditLog를 사용하기 위해 선택합니다.
네임노드 기계는 HDFS 클러스터에서 실패의 단일 지점입니다. 만약 네임노드 기계가 실패하면 수동적인 조정이 필요합니다. 현재로는 자동적인 재 시작과 다른 기계를 통한 네임노드 소프트웨어의 장애 극복(failover)은 지원되지 않습니다.

8.5. 스냅샷 (Snapshots)

스냅샷은 특정 시점의 순간의 사본의 저장을 지원합니다. 스냅샷 특징의 한 사용은 변조된 HDFS 인스턴스를 이전의 잘 알려진 좋은 시점으로 되돌리는 것일 수 있습니다. HDFS는 현재 스냅샷을 지원하지 않지만 미래의 발표 물에는 지원할 것 입니다.

9. 데이터 구성 (Data Organization)

9.1. 데이터 블록 (Data Blocks)

HDFS는 매우 큰 파일을 지원하도록 설계되었습니다. HDFS와 호환 가능한 응용 프로그램은 큰 데이터 집합을 다루는 그것 입니다. 이러한 응용 프로그램은 그들의 데이터를 한번만 쓰지만 한번 이상 읽고 이러한 읽기가 스트리밍 속도에 만족하는 것을 요구합니다. HDFS는 파일에서 한번 쓰고 여러 번 읽는 의미론(semantics)을 지원합니다. HDFS에서 사용되는 일반적인 블록 크기는 64MB입니다 따라서 HDFS 파일은 64 MB의 조각으로 잘리고 가능하면 각 조각은 다른 데이터 노드에 존재합니다.

9.2. 옮겨 바꾸기 (Staging)

파일 생성의 클라이언트 요청은 네임노드에 즉각적으로 도달하지 않습니다. 사실, 초기에 HDFS 클라이언트는 파일 데이터를 임시 로컬 파일로 저장합니다. 응용 프로그램의 쓰기는 투명하게 이 임시 로컬 파일로 돌려집니다. 로컬 파일 누적 데이터가 HDFS의 블록 크기를 넘어서면 클라이언트는 네임노드에 접촉합니다. 네임노드는 파일 이름을 파일 시스템 계층에 삽입하고 그것을 위한 데이터 블록을 할당합니다. 네임노드는 데이터노드와 목적지 데이터 블록의 신원과 함께 클라이언트 요구에 응답합니다. 그리고 나서 클라이언트는 데이터 블록을 로컬 임시 파일로부터 명기된 데이터노드로 내보냅니다. 파일이 닫히면, 임시 로컬 파일 내의 나머지 내보내지지 않은 데이터는 데이터노드로 전송됩니다. 클라이언트는 그리고 나서 네임노드에게 그 파일이 닫혔다고 말합니다. 이 때 네임노드는 파일 생성 동작을 영속 저장소에 넘깁니다. 만약 파일을 닫기 전에 네임노드가 죽으면 파일은 잃습니다.
위의 접근법은 HDFS에서 수행하는 대상 응용 프로그램에 대한 신중한 고려 후에 적용되어야 합니다. 이런 응용 프로그램은 파일로 스트리밍 쓰기를 필요로 합니다. 만약 클라이언트가 클라이언트 측 버퍼링 없이 원격 파일에 직접적으로 쓴다면 네트워크에서 네트워크 속도와 혼잡은 처리량에 상당하게 영향을 줍니다. 이러한 접근법은 전례 없는 것은 아닙니다. 초창기 분산 파일 시스템, 예를 들면 AFS는 성능 향상을 위해 클라이언트 측 캐싱을 사용했습니다. POSIX 요구 사항은 데이터 전송(upload)의 높은 성능을 달성하기 위해 게을리 하였습니다.

9.3. 복제 파이프라이닝 (Replication Pipelining)

클라이언트가 HDFS 파일에 데이터를 쓰는 중일 때, 데이터는 이전에 장에서 설명했던 것처럼 로컬 파일에 먼저 쓰여집니다. HDFS 파일이 세 개의 복제 인수를 가지고 있다고 가정합니다. 로컬 파일이 사용자 데이터의 가득 찬 블록으로 누적 되었을 때 클라이언트는 네임노드로부터 데이터노드의 목록을 탐색합니다. 이 목록은 블록의 복제를 호스트 할 데이터노드를 포함하고 있습니다. 그리고 나서 클라이언트는 데이터 블록을 첫 번째 데이터노드로 내보냅니다. 첫 번째 데이터 노드는 작은 부분(4 KB)으로 데이터를 받기 시작하고 각각의 부분을 로컬 저장소에 쓰고 목록의 두 번째 데이터노드로 전송합니다. 데이터노드의 각 부분을 받기 시작한 두 번째 데이터노드는 부분을 로컬 저장소에 쓰고 세 번째 데이터노드로 내보냅니다. 마지막으로 세 번째 데이터 노드는 데이터를 로컬 저장소에 씁니다. 따라서 데이터노드는 파이프라인 내의 이전 데이터노드로부터 데이터를 받고 동시에 파이프라인 내의 다음 데이터노드로 전송합니다. 따라서 데이터는 한 데이터 노드에서 다음으로 파이프라인으로 보내집니다.

10. 접근 성

HDFS는 다양한 방법으로 응용 프로그램으로부터 접근될 수 있습니다. 본래, HDFS는 응용 프로그램이 사용하는 것을 위해 Java API를 제공합니다. 이 Java API를 위한 C 언어 포장(wrapper) 역시 있습니다. 추가적으로 HTTP 브라우저 역시 HDFS 인스턴스의 파일을 브라우저 하는 것에 쓰여집니다. HDFS를 WebDAV 프로토콜을 통해 노출하는 작업은 진행 중 입니다.

10.1. DFSShell

HDFS는 사용자 데이터를 파일과 디렉터리 형식으로 구성하는 것을 허가합니다. HDFS내의 데이터와 사용자가 상호작용할 수 잇는 DFSShell 이라 불리는 명령 줄 인터페이스를 제공합니다. 이 명령 집합의 구문은 사용자가 이미 익숙한 다른 쉘(shell)과 유사합니다. (예를 들면 bash, csh). 여기에 약간의 예제 액션/명령 쌍이 있습니다:

액션	명령
/foodir 이름의 디렉터리 생성	bin/hadoop dfs –mkdir /foodir
/foodir/myfile.txt 이름의 파일 내용 보기	bin/hadoop dfs –cat /foodir/myfile.txt

DFSShell은 저장된 데이터와 상호작용을 위해 스크립팅 언어가 필요한 응용 프로그램을 대상으로 합니다.

10.2. DFSAdmin

DFSAdmin 명령 집합은 HDFS 클러스터를 관리하기 위해 사용됩니다. HDFS 관리자에 의해서만 사용되는 명령들이 있습니다. 여기에 약간의 예제 액션/명령 쌍이 있습니다.

액션	명령
안전모드에서 클러스터 놓기	bin/hadoop dfsadmin –safemode enter
데이터노드의 목록 생성	bin/hadoop dfsadmin -report
datanodname 데이터노드의 중지	bin/hadoop dfsadmin –decommission datanodename

10.3. 브라우저 인터페이스 (Browser Interface)

일반적인 HDFS 설치는 HDFS 네임스페이스를 설정 가능한 TCP 포트로 노출하기 위해 웹 서버로 설정합니다. 이것은 사용자가 HDFS 네임스페이스를 항해하고 파일의 내용을 웹 브라우저를 통해 보는 것을 허가합니다.

11. 공간 교정 (Space Reclamation)

11.1. 파일 삭제 및 복원

사용자나 응용 프로그램에 의해 파일이 삭제 되었을 때, 그것은 즉각적으로 HDFS에서 제거되지 않습니다. 대신에 HDFS는 /trash 디렉터리의 파일로 먼저 이름을 변경합니다. 파일은 /trash에 남겨진 동안 빠르게 복원 될 수 있습니다. 파일은 /trash에 설정된 시간 동안 남아있습니다. /trash에서의 생활이 만료된 후, 네임노드는 HDFS 네임스페이스에서 그 파일을 지웁니다. 파일의 삭제는 파일과 연계된 블록의 해제를 유발합니다. 사용자에 의해 지워진 파일과 그에 상응하는 HDFS에서의 자유 공간 증가는 상당한 지연이 있을 수 있습니다.
사용자는 /trash 디렉터리에 남아있는 동안 삭제 후, 취소할 수 있습니다. 만약 사용자가 지운 파일의 취소를 원한다면 /trash 디렉터리를 항해하고 파일을 탐색할 수 있습니다. /trash 디렉터리는 단지 삭제된 파일의 최근 사본만 포함합니다. /trash 디렉터리는 한가지 특별한 특징(HDFS는 이 디렉터리로부터 자동적으로 파일을 삭제하기 위해 명기된 정책을 적용할 수 있습니다.)과 함께 어떠한 다른 디렉터리와 같습니다. 현재의 기본 정책은 /trash 로부터 6시간 이상 된 파일을 지우는 것 입니다. 미래에는 잘 정의된 인터페이스를 통해 정책을 수정할 수 있게 될 것 입니다.

11.2. 복제 인수 감소 (Decrease Replication Factor)

파일의 복제 인수가 감소 되었을 때, 네임노드는 삭제될 수 있는 초과 복제를 선택합니다. 다음 심장 박동(Heartbeat)은 이 정보를 데이터노드로 전송합니다. 데이터노드는 그러면 상응하는 블록을 제가하고 상응하는 자유 공간을 클러스터에 표시합니다. 다시 말하면, setReplication API 호출의 완료와 클러스터 내의 자유 공간 출현에는 시간 지연이 있습니다.

12. 참고문헌 (References)

HDFS Java API: http://lucene.apache.org/hadoop/api/
HDFS 소스 코드: http://lucene.apache.org/hadoop/version_control.html

출처 : http://www.virgo81.net/46

하둡(hadoop) 소개 문서

2012-07-17T14:41:01+00:00

작년 상반기에 신입 사원 교육을 위해 만들었던 문서이다.

전반적인 overview 수준이지만 워낙에 하둡과 관련된 한글 문서가 희귀하니 이거라도 다른 사람들에게 도움이 되지 않을까 싶어 내용 중 회사 시스템이나 업무와 관련된 내용을 언급한 부분은 삭제하고 올린다.

출처 : http://agbird.egloos.com/5423801

미들웨어란?

2008-08-07T12:06:56+00:00

미들웨어란 무엇인가?

기본적으로 미들웨어는 애플리케이션들을 연결해 이들이 서로 데이터를 교환할 수 있게 해 주는 소프트웨어다. 미들웨어는 애플리케이션들을 직접 연결하는 방식에 비해 몇 가지 중요한 이점이 있다. 애플리케이션들을 직접 연결할 경우, 일반적으로 관련된 애플리케이션 모두에 코드를 추가해 각 애플리케이션이 서로 대화하도록 지시해야만 한다. 반면 미들웨어는 이 대화 과정에서 번역기라는 독립적인 제3자의 역할을 함으로써 애플리케이션 모두에 코드를 추가하는 엄청난 작업을 할 필요가 없다.

미들웨어의 종류

기업들이 통합과 관련된 여러 업무를 더 잘 처리하기 위해 여러 종류의 미들웨어를 도입하는 일은 이례적인 일이 아니다. 일반적으로 더 복잡한 통합 작업이 요구되는 더 큰 기업들은 EAI(Enterprise Application Integration)와 같은 더 정교한 미들웨어 제품을 선호하기 마련이다.

RPC와 데이터베이스 게이트웨이

설명

아마도 이것들은 진짜 미들웨어가 아닐 수 있지만, 문맥상으로 볼 때 전혀 관련이 없다고도 말할 수 없다. 양쪽 모두 애플리케이션 연결 기능을 다루는 더 오래된 방법들로, 특히 분산 환경에서 그렇다.RPC는 원격절차호출(Remote Procedure Call)의 약어로, 서버 애플리케이션에 있는 어떤 절차를 촉발하는 클라이언트 애플리케이션의 코드중 한 조각을 말한다. 오늘날의 정의에 따르면 RPC는 미들웨어가 아니다. 비록 지금도 사용되고는 있지만, RPC는 여러 개의 애플리케이션을 서로 묶으려 할 때 프로그래머들이 반복해서 코딩 작업을 해야만 하는 방식이기 때문이다. 따라서 애플리케이션의 수가 늘어나면 RPC 외의 다른 미들웨어 방식이 더 효과적이다. 현재 RPC는 미들웨어들에 의해 대체되고 있다. 반면 데이터베이스 게이트웨이는 데이터 접근을 용이하게 할 수 있는 제3의 역할을 하기 때문에 RPC보다 미들웨어의 정의에 더 들어맞는다. 데이터베이스 게이트웨이는 애플리케이션들을 특정 종류의 데이터베이스 플랫폼에 연결해 준다. 일례로 HP 3000 서버에 있는 중대형 애플리케이션 및 데이터를 가진 기업을 생각해 보자. 많은 새로운 상용 애플리케이션들이 오라클이나 사이베이스 같은 유명 데이터베이스에 접근할 수 있도록 고안되었지만, 이 애플리케이션들이 더 오래된 HP 3000용 ‘터보이미지(TurboImage)’ DBMS를 이용하려면 약간의 도움이 더 필요한데, 이때 데이터베이스 게이트웨이가 그런 도움을 주다. 이런 것이 데이터베이스 게이트웨이의 전형적인 활용 사례다.

메시지-지향 미들웨어(MOM)

제품
MQ시리즈(MQSeries) - 아이비엠MSMQ - 마이크로소프트스마트소켓츠(SmartSockets) - 탈라리안(Talarian)

설명
MOM은 오래된 미들웨어 기술이다. 메시지-지향 미들웨어는 이메일과 비슷한 방식으로 데이터를 메시지 형태로 만들어 하나의 애플리케이션에서 다른 애플리케이션으로 전달한다. 사실 상용 MOM 제품이 보급되기 전, 세계 최대의 곡물회사인 카길 같은 대기업은 데이터 전송을 위해 휴렛팩커드의 오픈메일(OpenMail) 이메일 엔진을 토대로 MOM 통합 도구들을 자체 개발했었다.이메일의 원리를 이해하고 있다면, MOM의 원리도 알 수 있을 것이다. 그리고 이메일의 경우처럼, MOM의 장점은 애플리케이션 A의 데이터가 대기열에 가서 기다릴 수 있기 때문에 애플리케이션 B는 나중에 필요한 시점에서 그 데이터를 불러올 수 있다는 것이다. 이로 인해 일례로 애플리케이션 A가 정보를 전달하려는 순간 애플리케이션 B가 우연히 다운돼 재부팅을 해야만 하는 등의 상황에서도 데이터의 무결성이 보호될 수 있다. 이런 비동기적 접근법을 사용해, 미들웨어 서버는 애플리케이션 B가 다시 작동을 시작할 때까지 기다린 후 대기열의 데이터를 올바른 순서에 따라 던져준다.(이 같은 데이터 메시지의 전송 유보는 앞에서 말한 지속성의 한 예다.)

전형적인 사용처

MOM은 대개 데이터에 대해 수행되어야 하는 운영이 비교적 많지 않고 데이터 교환 시간이 그리 중요하지 않은 단순한 일방향의 교환을 위해 사용된다. 일례로 서로 다른 데이터베이스에 저장되어 있는 저축성 예금과 수표 계좌의 연결을 들 수 있다. 고객이 수표 계좌에 대한 자신의 주소를 갱신하면, 이에 따라 총괄 시스템은 이 고객의 다른 계좌의 주소들도 갱신하게 되지만, 이 갱신 작업에 3초나 10분이 걸린다고 해서 그것이 그리 큰 문제는 되지 않을 것이다.

거래처리(TP) 모니터

제품
CICS, 오픈CICS(OepnCICS) - 아이비엠BEA 턱시도(Tuxedo) - BEA 시스템즈

설명
거래처리(TP) 모니터는 본래 메인프레임 환경을 위해 개발된 유래가 오래된 기술이다.(MOM보다 오래됐다.) TP 모니터는 거래 데이터의 작성과 읽기를 관리하기 위해 전위처리 애플리케이션들과 후방지원 데이터베이스 사이에 위치한다.TP 모니터는 메시지-지향 미들웨어보다 더 애플리케이션들에 간여한다. 이것은 TP 모니터가 제공하는 고유의 서비스 이점을 활용하기 위해서 TP 모니터들이 애플리케이션들에 대해 더 많은 수정 작업을 요구한다는 의미다. TP 모니터는 또한 특수 보안 기능과 데이터 무결성 기능을 제공한다.

전형적인 사용처
TP 모니터는 대규모의 거래가 처리되는 환경에 맞는다. 다시 은행 업무의 예를 들면, 현금자동입출금기(ATM)에서 기록되는 모든 거래는 해당 금융기관이 고객의 계좌 잔고를 정확하게 추적할 수 있도록 세심하게 다뤄져야만 한다. 이 일을 TP가 담당한다. 특히 TP 모니터는 복수의 애플리케이션들이 보안이나 디렉토리 서비스 같은 동일한 기본 기능 몇 가지를 동시에 필요로 할 때 유용하다.“TP 모니터의 이점은 새로운 애플리케이션들을 작성할 때 이 애플리케이션들에 맞춰 이런 서비스들을 다시 개발할 필요가 없다는 것이다.”라고 부쉐는 말한다. “애플리케이션들은 다른 종류의 미들웨어를 통해 서로 의사소통할 수 있지만, TP 모니터는 그 이상의 기능을 제공한다.” 따라서 TP 모니터를 단순한 일대일 애플리케이션 연결성을 위해 사용할 경우, 그것은 “성능 과잉”이 될 것이라고 그녀는 덧붙인다.

객체 모니터(Object Monitors)

제품
아이비엠 컴포넌트 브로커(Component Broker)비지브로커 ITS(VisiBroker Integrated Transaction Server) - 인프라이즈(Inprise)마이크로소프트 트랜잭션 서버(Transaction Server)

설명
객체 모니터(Object Monitors, 객체 TP 모니터라고도 불린다.)는 앞에서 설명한 TP 모니터의 발전된 버전이다. 새롭게 태동중인 제품군인 객체 모니터는 TP 모니터의 기능을 그대로 제공하지만, 바로 아래에서 설명될 객체요구브로커(ORB) 모델들과 같은 객체-지향 표준에 따라 작성된다는 점이 다르다. ORB 모델을 사용하기 때문에, 기업은 애플리케이션에 손을 대지 않고도 TP 모니터에 의해 제공되는 서비스들을 수정할 수 있다.

전형적인 사용처
온라인 쇼핑 장바구니 및 관련 주문처리 애플리케이션들 같은 전자상거래 애플리케이션이 객체 모니터를 사용하는 경향이 있다. 이것은 전자상거래 애플리케이션들이 서로 다른 많은 원천들로부터 데이터를 끌어올 필요가 있고, 갈수록 늘어나는 기능성에 맞춰 자주 수정될 필요가 있기 때문이다. 이에 필요한 유연성으로 인해 컴포넌트

기반의 아키텍처가 인기를 끌고 있는데, 이 아키텍처는 시스템의 다른 부분에 영향을 주지 않으면서도 시스템의 한 부분을 바꿀 수 있는 능력을 제공하기 때문이다. 또 객체 모니터는 웹 상거래시 필요한 고도의 데이터 무결성과 초대규모의 거래 용량 처리 능력을 제공한다.

객체요구브로커(ORBs)와 아키텍처

아키텍처 표준들
코바(Corba, Common Object Request Broker Architecture) - OMG(Object Management Group)엔터프라이즈 자바빈즈(EJB, Enterprise JavaBeans) - 썬 마이크로 시스템즈COM+(Component Object Model) - 마이크로소프트

설명
ORB는 애플리케이션과 네트웍 서비스(보안, 성능 모니터링, 프린트 등) 사이에서 정보를 전달한다. ORB는 서비스들과 상호운영 애플리케이션들을 위한 더 넓은 아키텍처 표준들의 핵심 부분이다. 위에 나열한 세 가지는 이런 표준 가운데 가장 유명한 주자들이다. 이 표준 가운데 하나를 구현한 실제 미들웨어 제품의 한 예가 최신 코바 표준 3.0에 기초하고 있는 아이오나(Iona) 테크놀러지로스社의 ‘오빅스 2000(Orbix 2000)’이다.ORB의 기본 전제는 애플리케이션들이 다른 애플리케이션들뿐 아니라 동일한 서비스들에도 접근할 필요가 있다는 것이다. 오늘날의 컴퓨팅 현실은 이기종 컴퓨팅 하드웨어와 운영체제 플랫폼 및 다양한 개발 도구들과 언어들로 구축된 애플리케이션들이 혼재돼 있다. 이 모든 컴포넌트(구성요소)가 서로 통신할 수 있도록 하기 위해서, 기업은 일관된 객체-지향 아키텍처가 필요한 것이다.그리고 비즈니스 파트너나 공급자들과 데이터 공유를 해야 하는 기업의 애플리케이션들이 늘어나면서, 이런 종류의 표준화된 접근법은 통합 작업을 크게 단순화시켜 줄 수 있다.코바는 역사적으로 유닉스 환경에 초점을 맞추고 있으며, 반면 엔터프라이즈 자바빈즈는 자바 언어로 개발하고 있는 기업에 가장 잘 맞는 아키텍처다. 좋은 소식은 이 두 표준이 서로 협력하고 있으며, 조화를 이루고 있다는 것이다. 코바 지지자들은 최소한의 작업으로 자바 개발 프로젝트를 통합할 수 있게 될 것이다.

그러나 부쉐는 현시점에서 코바 모델로 개발된 서버 객체들이 COM+ 모델로 개발된 서버 객체들과 잘 통신되지 않는다는 점을 지적한다.(반대도 마찬가지) 이것은 기업들이 이 2개 ORB 아키텍처 가운데 어느 한쪽을 선택해 사용해야지, 혼합 사용해서는 안된다는 것을 의미한다. 윈도우 NT/2000 서버 사용자들은 COM+에 의해 최적의 서비스를 받을 수 있다. 반면 유닉스 서버 사용자들(마이크로소프트의 윈도우를 탑재한 데스크탑 컴퓨터에 의해 접근되는 경우에도)은 코바가 최고의 선택일 것이다.

특별히 주목할 사항

마이크로소프트의 미들웨어 구조와 제품 계획들은 계속 진화되고 있으며, 그에 따라 관련 용어도 바뀌고 있다. 따라서 이 회사의 계획을 세심하게 따라가지 않는 사람들에겐 이것이 혼란의 한 원인이 될 수 있다. COM+의 원래 명칭은 단순히 COM이었다. 그러다 DCOM(Distributed Common Object Model)이 되었다. 부쉐에 따르면, 마이크로소프트는 현재 DCOM에서 벗어나 현재의 이름인 COM+으로 옮겼다고 한다. 그러나 COM+도 미들웨어 범주를 넘은 제품과 서비스를 포함하고 있는 DNA(Distributed Network Architecture)란 더 커다란 마이크로소프트 아키텍처 계획의 일부일 뿐이다.

기업 애플리케이션 통합(EAI)

제품
액티브엔터프라이즈(ActiveEnterprise) - 팁코 소프트웨어(Tibco Software)네온 임팩트(NEON Impact) - 뉴 에라 오브 네트웍스(New Era of Networks)이-게이트(e-Gate) - STC(Software Technologies Corp.)비즈니스웨어(BusinessWare) - 비트리아 테크놀러지(Vitria Technology)제네바 엔터프라이즈 인티그레이터(Geneva Enterprise Integrator) - 레벨 8 시스템즈(Level 8 Systems)(그 외 다수)

설명
EAI 업체들은 EAI 제품을 미들웨어라고 부르는데 커다란 거부감을 느끼고 있다. 기업(enterprise)이란 매력적인 단어를 포함하고 있는 EAI에 미들웨어란 명칭은 어울리지 않는다는 것이다. 그러나 EAI의 근본 개념은 통합이다. 불행하게도 EAI란 단어는 마케팅 목적에 아주 유용하기 때문에, 많은 업체가 각자의 제품이 제공하는 기능성들이 그처럼 폭이 넓음에도 불구하고 이 용어를 굳이 사용하고 있는 것이다. EAI는 미들웨어 이상이다. ORB와 같이 EAI 도구들은 일반적으로 데이터 전송을 위한 기저 메커니즘으로 메시지 브로커(broker)를 사용한다. 여기에 EAI 도구들은 데이터를 받으려는 각각의 특정한 애플리케이션의 입맛에 맞춘 형태로 데이터를 분석, 복제, 변환할 수 있다. 대기업의 경우, MOM과 EAI를 모두 사용할 수는 있지만, 아주 탄탄한 EAI 제품을 사용하고 있다면, MOM 같은 더 낮은 수준의 통합 도구를 사용하지 않아도 된다.EAI 도구들이 제공하게 될 차세대 기능성(이 기능성으로 인해 EAI와 다른 종류의 미들웨어는 한층 명확히 구분이 될 것이다.)은 비즈니스 프로세스 규칙들(rules)의 지원이다. EAI는 사용자가 적절한 비즈니스 프로세스를 정의하고 이런 규칙에 따라 데이터를 통합할 수 있게 해 준다. 일례로 적절한 권한자에 의해 승인을 받기만 하면, 구매 애플리케이션에서 수취 계정 애플리케이션으로 데이터를 자동으로 이동시키도록 규칙을 정할 수 있다.허위츠 그룹에 따르면, 비트리아社의 제품이 이런 종류의 비즈니스 프로세스 규칙을 지원한 최초의 제품이라 한다. 현재 다른 경쟁사들도 기업의 내부 및 공급망 전체에 이 기능을 추가할 수 있도록 각사 제품에 대해 작업하고 있다.XML(eXtensible Markup Language) 지원은 EAI 제품의 최대 장점중 하나다. 또한 EAI 제품은 비쯔톡(BizTalk, 마이크로소프트가 후원하는 B2B 통신 프로토콜)과 로제타넷(RosettaNet, 전자 업계 통신 프로토콜을 만들기 위한 이 업계 컨소시엄) 등 표준도 지원한다.

대부분의 EAI 제품의 경우, 사용자는 중앙 모듈을 구매한 후 각자가 필요로 하는 특정 인터페이스만을 선택적으로 구매할 수 있다. 일례로 STC의 이-웨이(e-Way) 제품군은 SAP, 시벨, 로터스 노츠, 다양한 후방지원 데이터베이스들을 위한 개별적인 ‘어댑터들(adapters)’을 포함하고 있다. 또한 대부분의 EAI 업체는 고객이 자체적으로 개발한 애플리케이션들을 연결할 필요가 있을 때, 고객의 프로그래밍 작업을 지원하는 서비스 부서를 갖고 있다. “그들은 80-20 법칙을 따르는 것처럼 보인다. 다시 말해 인터페이스의 80%는 미리 구축된 것을 사용하도록 하고, 나머지 20%는 고객이 작업을 하도록 하는 것이다.”라고 컨설팅 업체인 ARC의 부사장 존 캠패네일은 말한다.

전형적인 사용처

EAI는 많은 애플리케이션들을 통합해야 하는 대기업에 적합하다. 일례로 카길은 ERP, 유지보수 관리, 재고, 비용 회계 시스템 등 다양한 애플리케이션들을 연결하기 위해 BEA 시스템즈社의 이링크(eLink) EAI 제품을 사용하고 있다.

결론
당신의 회사에 적합한 미들웨어는 어떤 것인가? 유일한 대답은 없다. 서로 다른 애플리케이션과 통합 요구에 맞춰 각기 다른 미들웨어를 사용해야 한다. 반면 단일화된 접근법은 규모의 경제성을 제공하고 개발에 따른 수고를 덜어줄 것이다. 어느 경우든 각 용어가 무엇을 의미하는지 알고 있을 때, 선택의 고민은 훨씬 가벼워질 것이다.

출처 :

u-City 방법론 및 미들웨어

2007-12-06T10:20:21+00:00

u-City 방법론 및 미들웨어
김은정┃LG-CNS 책임연구원
이정환┃LG-CNS 부책임연구원
총 5 쪽

목차 :
1. 개요
2. u-City의 효과적 구현을 위한 방안모색
2.1 u-City 구현의 필요 요소
3. u-City 엔지니어링 서비스
3.1 서비스 오퍼링 및 프레임워크
3.2 u-City 방법론
4. 도시통합운영센터(UMC) 미들웨어
4.1 UMC(u-City Management Center)의 정의 및 역할
4.2 UMC의 통합 플랫폼과 u-City에서의 주요 미들웨어
5. 결언
참고 문헌