Cognos를 전통적인 데이터 센터에서 배치하면 여러 시스템이 필요할 가능성이 있는 것처럼, 사용자의 클라우드 솔루션은 여러 개의 이미지가 필요할 수 있다. 성능, 확장성 및 고가용성과 같은 기준은 대개 여러 이미지 토폴로지를 야기한다. 이 기사에서는 이러한 여러 이미지 토폴로지를 위한 우수 사례 중 일부를 이 기사에서 설명한다.

이는 클라우드에서 Cognos를 위한 우수 사례와 설치 및 구성 팁 시리즈 중에 첫 번째이다. 이 시리즈에서는 Cognos 8을 사용한다.

여러 소프트웨어 이미지, 성능 및 확장과 고가용성 문제를 사용하기 위한 우수 사례에 대해 시작하기 전에, 클라우드, 워크로드 및 Cognos 8이 어떻게 클라우드의 성능을 활용하는지에 대해 살펴보자.

Cognos 8 BI: 출발 준비

먼저, IBM Cognos 8 BI에 익숙하지 않은 독자를 위해 이 제품에 대해 몇 가지 사항을 알려주겠다.

IBM® Cognos® 8 Business Intelligence(BI)는 IBM의 정보 관리 브랜드 중 하나의 멤버로서, 모든 종류의 태스크 — 분석, 데이터 및 데이터베이스 관리, 엔터프라이즈 내용 및 준수 관리, 메시징 및 협업과 포털 및 매시업 —를 수행하는 모든 종류의 소프트웨어 — Cognos BI 이외에도 DB2®, Cloudscape, InfoSphere™, Optim™, FileNet®, Informix® 및 OmniFind®가 있음 —를 처리한다. Cognos 소프트웨어 및 SPSS의 통계적 분석 소프트웨어는 IBM의 Business Analytics 부서를 구성한다.

IBM Cognos 8 BI는 네 개의 주요 태스크 지향 컴포넌트로 구성 되어있다.

1. IBM Cognos 8 BI Reporting: 하나의 웹 기반 솔루션에서 보고 라이프사이클의 모든 컴포넌트를 위한 보고 기능 세트를 제공한다. 다음과 같이 예를 들 수 있다.
   • IT 부서를 통하지 않고도 사용자가 필요한 정보를 확보하도록 사용할 수 있는 셀프 서비스 보고.
   • 저자가 어디서나 액세스하는 보고를 통해 IT는 사용자가 다수의 디바이스에서 액세스할 수 있는 하나의 보고서를 작성할 수 있다. 이는 25개 이상의 언어에 대한 지원이 포함되고, 여러 포맷으로 발행되며, 다른 애플리케이션과 프로세스에서 액세스할 수 있다.
2. IBM Cognos 8 BI Analysis: 데이터가 저장된 장소(온라인 분석 프로세싱과 여러 차원으로 모델링된 관계형 소스)에 관계 없이 정보를 대화식으로 탐색할 수 있다. 이는 복잡한 문제에 대한 빠른 분석을 제공하여, 데이터의 중요한 부분을 찾기 위해 요약 레벨 세부사항과 트랜잭션 레벨 세부사항 사이에 이동할 수 있으며, 내장된 사용자 정의 가능한 시간 시리즈가 있어서, 회사에서 지난 시간 동안 발생한 일의 자세하고 복잡한 경향 "사진"을 구성할 수 있다.
3. IBM Cognos 8 BI Dashboards: 데이터가 나타내려고 하는 것을 한 눈에 보기를 제공하여 성능을 모니터하고 측정하며 관리하는 데 도움을 준다. 이는 대형 비즈니스 문제가 되기 전에 작은 이례적 사항을 포착하는 데 도움을 주는 핵심 도구이다. 대시보드는 필요한 가상화의 레벨을 생성하고 여러 포맷에서 결과물을 제공하도록 맞춤화할 수 있다.
4. IBM Cognos 8 BI Scorecarding: 대시보드를 통해 얻은 보고서에서 분석을 산출하여, 메트릭으로 변환한 다음에 분석에서부터 향후 전망 전략을 생성하는 데 도움을 준다. 이는 조치의 결과에 대해 측정할 수 있는 메트릭을 생성하여 이 전략을 다른 사람에게 의사전달하는 데 도움을 준다. 컴포넌트는 조작의 중앙 명령과 같다.
   • 스코어카드의 각 메트릭은 소유주를 지정할 수 있다.
   • 각 스코어카드는 전체 전략 맵에서 우선순위로 순위지정할 수 있다.
   • 각 스코어카드는 급변하는 상황에서 진행 중인 분석을 위해 이에 BI 기능을 임베드할 수 있다.
   • 각 스코어카드는 전체 전략 맵에서 볼 수 있기 때문에, 이를 통해 전체 계획이 진화하면서 스코어카드가 어떻게 맞추는지 결정하기 쉽다.

또한 Cognos 8 BI를 확장하는 데 사용 가능한 다양한 컴포넌트가 있다.

위로

Cognos 8 BI: 클라우드로 진입

비즈니스 분석 소프트웨어의 성능과 클라우드 컴퓨팅의 범위가 흥미롭게도 잘 맞는다. 두 가지 개념은 다음과 같이 모두 전통적인 시스템이 이용하는 기존 제한사항의 붕괴에 관한 것이다.

• 클라우드 컴퓨팅은 데이터 자원을 공유하는 기능을 활용하고, 동일한 시스템에 호스트된 데이터 자원을 모두 보유할 필요 없이 가상 및 실제 자원 스토리지 제한점을 둘 다 파괴하려고 시도한다. 이는 문제의 클라우드 내부(및 때로는 외부)에서 다양한 시스템에 걸쳐 워크로드를 밸런싱하여 최대 CPU 사용 문제를 제거하려고 시도한다. 이는 사전정의된 애플리케이션 테스팅 시스템과 요구당 기준으로 사용 가능한 생산성 애플리케이션을 생성하여 액세스 비용 문제를 해결하려고 시도한다.
• 비즈니스 분석은 인적 자원에서부터 경향 및 이례적 사항 포착의 노동 집약적 업무를 제거하고 이를 자동화한다. 데이터의 "시각화"를 생성하여, 데이터를 정보로 변환하여 사람들이 경향을 쉽게 인식하고 이러한 발견을 쉽게 공유할 수 있다. 이는 가능한 해석/솔루션 조합을 제공하여, 정보를 지식으로 변환하여, 사람들이 무엇보다도 가장 중요한 태스크인 "여기에서부터 어디로 이동하는가?"라는 질문에 답하는 데 집중할 수 있다.

이 시리즈의 내용

이 시리즈에서 다음과 같이 경험에서 비롯한 우수 사례에 대해 논의한다.

• 성능, 확장성 및 고가용성과 같은 기준을 기반으로 하는 Cognos의 여러 이미지 클라우드 토폴로지 관리. 여러 이미지를 관리하기 위해 기존 호스트 파일을 사용하는 것, 다른 클러스터 크기로 확장하는 것, 개인용 이미지를 사용하여 스냅샷을 작성하는 것과 필요한 파일을 저장할 수 있는 장소에 대해 논의한다.
• 성능과 확장성을 위해 아키텍처의 크기 조정. 사용자 커뮤니티와 지리적 분배가 성능에 어떠한 영향을 주는 지와 애플리케이션 복잡도가 성능에 어떠한 영향을 줄 수 있는 지에 대해 논의할 것이다. 또한 사후 배치 확장성에 대한 일반적인 규칙도 제공할 것이다.
• 고가용성을 사용하는 설정 선택. 활성 및 대기 모드 둘 다에서 Cognos Gateways 및 Cognos Application Servers, Cognos Content Manager와 IBM DB2 HADR(High Availability and Disaster Recovery)을 사용하는 방법을 비롯하여, 고가용성과 재난 복구를 위해 클라우드에서 Cognos를 설정하고 유지보수하는 것에 대한 권장사항을 제공할 것이다.
• 일반 토폴로지, 보안 및 데이터 고려사항. 워크로드와 요구사항의 다양한 유형에 대해 데이터, 쿼리 데이터베이스 및 인증 소스가 존재해야 하는 장소에 대해 논의할 것이다.

향후 기사에서는 Cognos 8 BI/IBM Cloud별 보안 우수 사례 및 설치 변형에 대해 독자가 필요하다고 생각하는 경우, 이에 대해 다룰 수 있다.

이 시리즈를 시작하기 위해, 독자의 토폴로지 설계와 테스팅을 위한 간단한(총망라한 것은 아님) 고려사항 목록을 제공한다.

클라우드 시작에 관한 네 가지의 팁

토폴로지를 설계하고 개선하면서 다음을 고려한다.

1. 간단하게 시작하라. 요구사항을 충족시키되, 불필요한 복잡도를 방지하라.
2. 토폴로지에서 클라우드 인스턴스의 수를 되도록 적게 유지하라. 인스턴스를 추가하는 것이 간단하기 때문에, 처음에는 요구사항을 과소평가하라.
3. 고유 클라우드 이미지의 수에 대해서는 2번도 적용하라. 예를 들어, 다섯 개의 다른 쿼리 데이터베이스 이미지를 작성하는 것이 아니라, 시작 시 자체적으로 사용자 정의하는 하나의 DB2 데이터베이스 이미지를 관리하는 것이 더 쉽다.
4. 토폴로지를 설계하고 테스트하는 프로세스는 반복적이며, 다음과 같아야 한다.
   1. 토폴로지를 설계하고 개선한다.
   2. 요구된 인스턴스를 작성하고 사용자 정의한다.
   3. 인스턴스를 설치하고 구성한다.
   4. 이미지 스냅샷을 저장한다.
   5. 기능과 성능에 대해 테스트한다.
   6. 반복한다.

이제 기본 기사인 여러 이미지 클라우드 토폴로지를 관리하기 위한 우수 사례에 대해 살펴보자.

위로

우수 사례: 여러 이미지를 사용하기 위한 호스트 파일 사용

여러 클라우드 이미지를 처리할 때에, 이러한 이미지와 연관된 여러 개의 변경 IP 주소를 처리해야 한다.

호스트 이름은 논리적 이름이 IP 주소에 쌍을 이룬다. 호스트 이름은 때때로 DNS 서버에 의해 저장되어, 프로그램이 호스트 이름을 IP 주소로, 또는 그 반대로 맵핑할 수 있다. 예를 들어, 대기 Content Manager, 버전 10.3.0.1에 대한 IP 주소는 호스트 이름 cm_standby로 맵핑될 수 있다.

복잡한 솔루션의 경우, 이러한 호스트 이름을 관리하기 위해 내부 DNS 서버를 배치하는 것이 적절할 수 있다. 하지만, 보너스로 시스템도 호스트 이름을 IP 주소에 맵핑하기 위해 운영 체제가 사용하는 호스트 파일로 알려진 파일이 있다. 대부분의 경우에 다음 호스트 파일을 사용하여 인스턴스의 클러스터를 관리하는 것이 더 쉽다.

• UNIX®에서 호스트 파일은 /etc/hosts에 있다.
• Windows®에서 호스트 파일은 \Windows\System32\Drivers\etc\hosts에 있다.

이 기사의 목적상 사용자의 모든 인스턴스가 동일한 클라우드 영역에 있어서, 동일한 개인용 클래스 IP 범위에 있다고 가정한다. 클라우드 인스턴스가 다른 지리적 지역에 있는 경우 여러 클래스 IP 범위를 처리하는 것에 대한 고려사항이 추가될 수 있다.

위로

예제: 하나의 이미지로 탄력적인 Cognos 8 클러스터

이미지를 되도록 적게 보유한 클라우드 솔루션을 관리하는 것이 언제나 더 간편하다는 것을 명심하자. 예를 들어, Cognos 8 클라우드 배치에 다른 역할(게이트웨이, 디스패처, 내용 관리자 등)이 있는 인스턴스가 있다 하더라도, 때로는 사용자 정의할 수 있는 하나의 일반 이미지를 작성하여 배치를 관리하는 것이 더 쉽다.

Cognos 8 클러스터는 다음 세 가지의 논리적 컴포넌트를 포함할 수 있다.

• 게이트웨이
• 디스패처 및 내용 관리자
• 데이터베이스

이 클러스터를 빌드하는 하나의 접근방식은 다음 별도의 세 가지 클라우드 이미지를 사용하는 것이다.

• 게이트웨이 이미지(Cognos 및 Apache 사용)
• 디스패처 클라우드 이미지
• DB2 데이터베이스 이미지

이미지의 수를 되도록 적게 하는 규칙을 명심하자. 이 시나리오에서 동적으로 솔루션을 확장하면, 모든 컴포넌트가 하나의 클라우드 이미지에서 로드될 때에 나타나지 않는 도전과제도 야기한다.

모든 소프트웨어 컴포넌트가 포함된 하나의 클라우드 이미지로 시작할 수 있다(Cognos 8, Apache 및 DB2). 그 다음에 이 하나의 이미지에서부터 인스턴스를 동적으로 시작하는 메커니즘을 정의하고, 이를 동적으로 성장하도록 구성한다.

이를 수행하기 위한 세 가지 기본 단계는 다음과 같다.

1. 요청된 모든 소프트웨어를 하나의 클라우드 이미지로 설치한다.
2. 호스트 이름 별명을 사용하여 솔루션 클러스터를 구성한다.
3. 이러한 별명을 호스트 파일을 사용하여 실제 인스턴스와 이에 연관된 IP 주소로 맵핑한다.

호스트 이름 별명

다음 항목이 들어있는 호스트 파일을 생성한다.

• myCognos. 현재 인스턴스로의 별명(localhost와 유사).
• vm-db2. DB2 인스턴스에 대한 별명.
• vm-gateway. Cognos 게이트웨이 인스턴스에 대한 별명.
• vm-cognos1. 첫 번째 Cognos 디스패처로의 별명.
• vm-cognos2 ... vm-cognos10. 남은 아홉 개의 잠재적인 Cognos 디스패처로의 별명.

기본값으로 호스트 파일에서 모든 별명은 현재 시스템 인스턴스에 대한 별명인 localhost로 맵핑된다.

Environment 탭의 Cognos 8 Configuration 도구에서부터 표 1의 다음 설정을 입력한다.

표 1의 URI에서 포트 9080(Websphere® Application Server로 설치될 때에 디스패처가 사용하는 기본 포트)을 사용자의 환경에 적절한 포트 번호로 바꾼다. 예를 들어, WebSphere Application Server 대신에 Tomcat을 사용하는 경우 9300이다.

이러한 구성 설정을 통해 단지 인스턴스를 시작하고 호스트 파일에 변경을 적용하기만 해도 클라우드 토폴로지를 하나의 인스턴스 클러스터에서부터 12개의 인스턴스로 확장할 수 있다.

이제 클러스터 크기에 대해 살펴 보자.

크기 1 클러스터

인스턴스는 크기 1로 하나의 독립형 클러스터로서 작동할 수 있다. 설치된 모든 소프트웨어(Cognos 8, Apache 및 DB2)는 하나의 인스턴스에서 실행된다.

크기 2 클러스터

크기 2의 클러스터의 경우 두 개의 인스턴스가 다음 역할을 담당한다.

• 인스턴스 1은 DB2 역할을 담당한다.
• 인스턴스 2는 게이트웨이, 디스패처 및 내용 관리자 역할을 담당한다.

인스턴스 1 호스트 파일에 다음 변경을 적용하여 인스턴스 1을 DB2 역할로 지정한다.

인스턴스 2 호스트 파일에 다음 변경을 적용하여 인스턴스 2를 게이트웨이, 디스패처 및 내용 관리자 역할로 지정한다.

호스트 파일에 변경사항은 즉시 효과가 나타나야 한다는 것을 유의하자. 대부분의 운영 체제(Windows와 Linux 포함) 하에서 새로 작성되고 업데이트된 호스트 항목은 다시 시작하는 서비스가 필요하지 않다. 게다가 이미 실행 중인 Cognos 8 인스턴스는 이러한 변경에 대한 효과가 나타나도록 다시 시작하지 않아도 된다.

크기 3의 클러스터

세 번째 인스턴스를 시작하고 호스트 파일을 다음 역할로 지정하도록 변경한다.

• 인스턴스 1은 DB2 역할을 담당한다.
• 인스턴스 2는 게이트웨이 역할을 담당한다.
• 인스턴스 3은 디스패처/내용 관리자 역할을 담당한다.

예를 들어, 인스턴스 3 호스트 파일은 다음과 같이 변경된다.

클러스터 크기 4를 12로 확장

크기 3 이상의 추가 인스턴스를 확장하기 위해 윤곽을 잡은 단계를 반복한다. 새 인스턴스를 추가하고, 남은 vm-cognos 호스트 이름을 새 인스턴스의 IP로 지정하여 토폴로지에 추가 디스패처로 이를 첨부한다. 예를 들어, 네 번째 인스턴스를 추가하면 인스턴스 4의 호스트 파일을 수정한다.

클라우드 인스턴스를 디스패처 목록에 추가하여 근본적으로 솔루션을 동적으로 확장하고 있다. 디스패처 목록은 로드 밸런서로 작동하여, Cognos 8은 Cognos 구성 내에서 표시되는 순서에 따라 디스패처에 접속할 것이다.

10개의 디스패처(이 토폴로지에서 총 12개의 인스턴스용) 제한은 이 예제에 대해 임의의 설정이었다. 이는 사용자의 요구사항에 따라 낮추거나 높일 수 있다.

위로

개인용 이미지를 사용하여 스냅샷 작성하기

솔루션을 개발하면서, IBM Cloud에서 개인용 이미지를 작성하여 작업을 스냅샷 처리해야 한다. 백업을 제공하는 것 이외에도 개인용 이미지는 사용자 이미지에 대한 모든 소프트웨어 설치 및 구성을 기록하여 시간을 절약할 것이다.

예를 들어, 저장소 변경, 보안/방화벽 설정 및 일부 일반적인 도구를 사용하여 운영 체제의 개인용 이미지를 작성하여 매번 "완전히 처음부터 시작"하지 않고 다른 이미지에 대한 시작 지점을 작성할 수 있다. 이러한 종류의 기본 이미지 스냅샷은 권장되는 우수 사례이다.

개인용 이미지를 변경하면 새 개인용 이미지를 작성하지만, 첫 번째 이미지와 두 번째 이미지 사이의 차이점만 저장된다. 이는 예를 들어, Cognos 8을 기본 이미지로 설치한 다음에 새 개인용 이미지를 작성할 때에 그 결과는 훨씬 더 작은 이미지라는 뜻이다. 이 경우에 이미지는 새롭게 추가된 Cognos 8 소프트웨어를 지속해야 한다.

중간 개인용 이미지를 삭제할 수는 없다. 왜냐하면 이전에 설명한 대로 개인용 이미지는 공간을 절약하기 위해(델타 변경이라고 함) 이미지 사이의 변경을 저장하는 것만 할 수 있다. 예를 들어, 이미지 C가 이미지 A를 기반으로 하는 이미지 B를 기반으로 하는 경우, C가 B에 의존하고 있기 때문에 B를 삭제할 수 없다. IBM Cloud는 B에 변경을 적용하여 A에서부터 C를 생성한다.

위로

클라우드 내 파일

IBM Cloud 내의 파일은 두 가지 장소 — 클라우드 인스턴스와 연관된 파일 시스템 또는 마운트된 디렉토리에 저장된다.

파일은 클라우드 인스턴스와 연관된 파일 시스템에 저장될 수 있다. 이 로컬 파일 시스템은 PC의 하드 드라이브와 유사하다. 여기에 저장된 파일은 각 인스턴스의 파일 시스템이 수명이 짧기 때문에 임시적으로 생각해야 한다. 인스턴스가 중지되면(또는 어떠한 실패로 인해 문제가 발생하면) 파일 시스템에 유지된 정보가 손실된다. 게다가 클라우드 인스턴스 내에 저장된 파일은 다른 인스턴스에 액세스할 수 없다.

파일은 IBM Cloud의 스토리지 인스턴스에서부터 파일 시스템에 기반하여 마운트된 디렉토리에 저장할 수 있다. 이 클라우드 파일 시스템은 여러 PC에 연결되는 NAS(네트워크 처리 가능 스토리지) 유닛과 유사하다. 여기에 저장된 파일은 IBM Smart Business Development and Test Cloud의 스토리지의 백업 및 중복 보증 덕분에 영구적인 것으로 생각할 수 있다.

이 마운트된 디렉토리에 저장된 파일은 모든 사용자 인스턴스로 액세스 가능하고, 서로 공유할 수 있다. 스토리지의 추가 백업 및 복구 서비스는 IBM Smart Business Development and Test Cloud에서 별도로 구입할 수 있다.

파일을 클라우드 이미지의 외부에 저장하거나 클라우드 인스턴스 사이에 공유해야 하는 경우, 파일을 IBM Storage Cloud에서부터 마운트된 디렉토리에 저장한다. Cognos 8의 여러 이미지 배치에서 로컬 인스턴스가 아니라 마운트된 디렉토리에 다음을 저장하도록 고려하자.

• 파일 기반 데이터 소스
• 일반 소프트웨어
• 일반 배치 스크립트(이를 통해 여러 개인용 이미지를 수정하지 않고 이러한 스크립트를 업데이트/변경 가능함)
• 사전 빌드된 호스트 파일과 다른 구성 파일(클라우드 인스턴스로 복사)
• 중요 감사 또는 로그 파일의 사본(따라서 원본 인스턴스가 종료되는 경우에도 지속함)
• 데이터베이스 백업 파일

위로

결론

이러한 우수 사례가 여러 이미지 클라우드 토폴로지를 더 효과적으로 관리하는 데 도움을 줘서, IBM Cloud에서 Cognos를 효과적으로 실행할 수 있기를 바란다. 클라우드 컴퓨팅의 성능과 소규모의 비즈니스 분석의 기능을 결합하면 애플리케이션에 경쟁력있는 우위를 제공할 수 있다.

Cognos 사이트와 developerWorks에서 클라우드에서의 Cognos 실행에 대해 더 자세히 살펴보자(참고자료).

참고자료

교육

• Cognos Business Analytics에 대한 자세한 정보를 찾아보자.
  
  
• 다른 IBM Business Analytics 소프트웨어를 살펴보자.
  
  
• Cognos 입증 사례 팀은 실제 고객 경험에서부터 빌드한 우수 사례의 문서를 제공한다.
  
  
• Redbooks 요약인 "IBM Smart Analytics Cloud"는 스마트 분석 클라우드의 랩 구현이 자세히 나와있다.
  
  
• developerWorks cloud developer resources에서는 클라우드 배치를 위한 프로젝트를 개발 중인 애플리케이션 및 서비스 개발자의 경험과 지식을 찾아보고 공유할 수 있다.
  
  

제품 및 기술 얻기

• Cognos 8 Business Intelligence 소프트웨어의 온라인 데모를 보고 확인하자.
  
  

토론

• My developerWorks의 클라우드 컴퓨팅 그룹에 참여하자.
  
  
• My developerWorks에 있는 뛰어난 클라우드 블로그를 모두 읽어보자.
  
  
• 연결, 공유 및 협업을 위한 전문가 네트워크이자 통합 커뮤니티 도구 세트인 My developerWorks에 참여하자.
  
  

필자소개

아티클 순위

의견

위로

목차

• Cognos 8 BI: 출발 준비
• Cognos 8 BI: 클라우드로 진입
• 우수 사례: 여러 이미지를 사용하기 위한 호스트 파일 사용
• 예제: 하나의 이미지로 탄력적인 Cognos 8 클러스터
• 개인용 이미지를 사용하여 스냅샷 작성하기
• 클라우드 내 파일
• 결론
• 참고자료
• 필자소개
• 의견