3-10. 효과분석

OAM Client Framework – 목차

[symple_box color=”gray” fade_in=”false” float=”center” text_align=”left” width=””] ■ 운용관리에 관한 이론적 고찰
1-1. OAM의 정의  1-2. EMS의 정의  1-3. OAM 표준화 동향  1-4. 3GPP 32 Series

■ OAM 프레임워크
2-1. OAM 프레임워크 필요성  2-2. OAM 시스템의 구성  2-3. OAM 요구사항  2-4. OAM 배포 아키텍쳐  2-5. OAM을 위한 Database의 구성 2-6. OAM 인터페이스  2-7. 구성 관리  2-8. 장애 관리  2-9. 성능 관리  2-10. 보안 관리

■ OAM 클라이언트 프레임워크
3-1. OAM Client 프레임워크 개요  3-10. 효과분석  3-2. 개발방법  3-3. 요구사항  3-4. 산출물 정의  3-5. 개발환경  3-6. 아키텍쳐 3-7. UI 정의  3-8. 프레임워크의 개발  3-9. 프레임워크를 사용한 개발
[/symple_box]

3-10. 효과분석

1. OMC의 장애 감소

OAM 프레임워크는 이동통신망에서 제공하는 서비스를 위한 시스템을 대상으로 하고 있으며 운용(Operation), 관리(Administration), 유지 보수(Maintenance), 프로비저닝(Provisioning), 문제해결(Troubleshooting)을 위한 기반을 제공한다. OAM 프레임워크는 피 관리 시스템, OAM 서버, OAM 클라이언트로 이루어진 3티어 아키텍쳐로 구성되었다.

OAM 클라이언트 프레임워크는 이동통신망 도메인에서 OAM 클라이언트라는 비즈니스에 특화된 문제를 반복적으로 해결하기 위해 설계의 원칙과 클래스와 인터페이스의 집합을 구성하여 재사용을 높임으로써 개발비용과 유지비용을 낮추며 제품의 품질을 높일 수 있는 반 완성된 어플리케이션이다. OAM 클라이언트 프레임워크를 사용하게 되면 다른 OAM 클라이언트에서 사용하여 검증된 설계, 클래스, 인터페이스를 재활용하게 됨에 따라 개발의 생산성이 높아지고 제품의 품질도 높일 수 있다.

실제로 OAM 프레임워크 구축에 따른 장애 감소 효과가 있는지 확인하기 위해, 프레임워크를 적용한 OAM 클라이언트와 적용하지 않은 OAM 클라이언트의 장애 발생 비율을 비교하였다. 비교를 위한 대상은 아래와 같다.

  1. 검증 대상 제품의 개발 기간 : 2007년 ~ 2012년
  2. OAM 클라이언트 프레임워크 적용 기간 : 2011년 ~ 2012년
  3. 장애 확인 방법 : 이슈 관리 시스템상에서 OAM 클라이언트 관련 PN(Problem Notice)

이슈 관리 시스템은 프로젝트를 진행하는 중 발생하는 버그와 이슈들을 추적하고 관리하기 위해 도입한 시스템으로 Atalssian사에서 개발된 JIRA를 사용하고 있다. 연구 과제 제품이 아닌 상용 제품에 장애가 발생했을 경우에는 PN(Problem Notice) 이슈를 생성한 후 문제를 해결하고 수행한 작업 이력을 관리자에게 보고하는 절차를 수행한다. 상용 제품으로 납품된 OAM 클라이언트에 장애가 발생하면 이슈 관리 시스템을 통해 문제 해결을 진행하여야 한다. 2007년 이후 등록된 OAM 클라이언트 관련 장애 건수를 비교해 보면 아래와 그래프와 같이 연 평균 장애 건수가 줄어 들었음을 알 수가 있다. 프레임워크 적용한 OAM 클라이언트의 장애가 더 적긴 하지만, 프레임워크를 적용한 제품의 개수가 적었으며 초기 버전의 프레임워크는 잠재된 오류가 존재하였기 때문에 획기적으로 낮은 수치는 보이지는 못하였다. 차후 프레임워크가 안정화될수록 프레임워크를 적용한 모든 제품의 안정성이 높아지므로 시간이 지날수록 장애 건수는 줄어들 것으로 예상된다.

사용자 삽입 이미지

[효과 분석 – 장애 건수 비교]

전체

장애 건수

연 평균

장애 건수

프로젝트별

연 평균 장애 건수

프레임워크 적용 OAM 클라이언트

5

2.5

0.5

프레임워크 미적용 OAM 클라이언트

65

10.8

0.9

[효과 분석 – 장애 건수 비교]

년도별 OAM 클라이언트의 장애를 비교하면 2011년 이후 장애 건수가 급격하게 줄어들었음을 확인할 수 있다. 2011년 이후의 OAM 클라이언트는 프레임워크를 적용한 신규 제품이다. 제품의 초기 버전의 경우 잠재된 장애를 해결하지 않고 배포되는 경우 운용 중에 장애가 발생할 확률이 높지만 프레임워크를 적용한 제품은 장애 비율이 현저하게 낮아짐을 볼 수 있다. 주목할 만한 점은 2011년 이후에 프레임워크를 적용하지 않은 제품들도 장애가 낮아졌는데, 이는 OAM 클라이언트 프레임워크를 개발에 사용된 라이브러리들이 해당 제품에 맞게 일부 수정되어 반영되었기 때문이다. 주의할 점은 2011년 이후 제품의 장애가 감소한 직접적인 원인이 OAM 클라이언트 프레임워크일 수도 있지만, 요구사항 관리, 품질 관리, 정적 분석, 산출물 관리와 같은 다양한 요인이 제품의 품질에 영향을 줄 수 있음을 감안하여야 한다.

사용자 삽입 이미지

[효과 분석 – 년도별 장애 건수]

2. OMC의 성능 향상

피 관리 시스템의 전원이나 주요 부품에 고장이 발생하면 또 다른 논리적 장애 또는 물리적 장애를 유발하여, 순간적으로 많은 장애 메시지가 OAM 클라이언트로 전송된다. OAM 클라이언트를 처음 접하는 개발자는 이러한 장애의 특성을 고려하지 않고 OAM 클라이언트를 개발할 여지가 많으며, 짧은 시간에 발생하는 연속적인 장애(Burst Error)로 인해 OAM 클라이언트는 알람을 발생하지 못하고 비정상 종료되거나 기능이 멈춰버릴 수도 있다. OAM 클라이언트 프레임워크에서는 중요한 요구사항인 고가용성을 지원하기 위하여, 메시지 대기열(Message Queue)를 사용하여 순간적으로 연속적인 장애가  발생하여도 안정적으로 장애 메시지를 처리할 수 있도록 설계되었다.

OAM 클라이언트 프레임워크를 통해 개발한 OAM 클라이언트의 장애 처리 성능과 기존 OAM 클라이언트의 장애 처리 성능을 비교하기 위해 메시지 대기열의 사용을 선택할 수 있도록 기존 OAM 클라이언트 프레임워크를 수정하여 테스트를 진행하였다.

사용자 삽입 이미지

[성능 측정을 위한 OAM 클라이언트]

OAM 클라이언트는 OAM 서버로부터 장애 메시지를 수신 받아야 하므로, OAM 클라이언트 프레임워크의 산출물 중에 하나인 테스트용 OAM 서버를 사용하여 TPS(Transactions Per Second)에 따른 OAM 클라이언트의 처리 성능을 측정하였다.

시험용 OAM 클라이언트에서 메시지 대기열을 사용함이 선택되면 수신한 장애 메시지를 대기열에 보관하고 주기적으로 폴링(Polling)하여 메시지의 성격에 따라 장애 이벤트, 장애 이력, 시스템 정보에 분배하도록 구현되었다. 폴링하지 않는 유휴시간에는 메시지의 등급에 따른 우선순위, 종류, 환경에 따라 메시지의 정렬, 삭제를 수행한다. 장애 메시지는 UI와 바인딩되어 있는 Datasource에 추가하여 OAM 클라이언트 UI에 표시된다.

메시지 대기열을 사용함이 선택되어 있지 않다면 OAM 서버로부터 수신한 장애 메시지는 곧바로 장애 이벤트, 장애 이력, 시스템 정보에 분배된다. 수신한 장애 메시지는 UI에 바로 반영하고 화면을 갱신한다.

사용자 삽입 이미지

[성능 측정을 위한 시나리오]

위와 같은 환경에서 OAM 서버의 장애 메시지의 발생 빈도를 점차 높이면서 OAM 클라이언트가 UI를 표시 못하고 중지되는 시점을 분석하여 아래와 같이 OAM 클라이언트 프레임워크를 사용하여 성능 향상이 있었음을 알 수 있다.

구분

성능 측정 결과

프레임워크 적용 OAM 클라이언트

50 TPS에서 OAM 클라이언트 중지됨

프레임워크 미적용 OAM 클라이언트

1000 TPS에서도 OAM 클라이언트 정상 작동

[효과 분석 – 성능 비교]

OAM 클라이언트 프레임워크에서는 장애 처리를 위한 프로토콜과 UI를 사용자 정의 컨트롤로 제공하고 있다. 차후 더 좋은 알고리즘과 UI를 적용한 프레임워크를 배포하게 되면 프레임워크를 사용한 모든 OAM 클라이언트에 대한 성능 향상의 효과를 볼 수 있다.

사용자 삽입 이미지

[프레임워크 성능 개선의 전파]

또한 OAM 클라이언트 프레임워크는 Spring.NET을 사용하여 각 클래스간 의존성을 제거하였고 CBD(Component Based Development) 방법론으로 개발되었기 때문에 같은 인터페이스를 사용하는 다른 컴포넌트로의 교체가 용이하다. 차후 사용 환경이 바뀌거나 UX에 대한 요구사항이 변경되면 프레임워크에서 정의한 인터페이스에 맞춰 개발한 컴포넌트로 교체하여 기능과 성능을 향상시킬 수 있게 되며, 제품마다 개발한 각 컴포넌트는 차후 개발될 OAM 클라이언트의 컴포넌트로서 재활용될 수 있게된다. 프레임워크를 사용하지 않은 OAM 클라이언트는 기능을 개선하거나 오류를 수정하여도 해당 제품에서만 성능이 향상되고 다른 OAM 클라이언트에 적용하기 힘든 점과 대비된다.

사용자 삽입 이미지

[컴포넌트 재활용을 통한 OAM 클라이언트의 구성]

메시지 대기열을 사용 여부에 따른 OAM 클라이언트 성능 비교는 임의의 제품과의 비교로서 객관적인 성능 개선율을 수치적으로 산정하기에는 무리가 있지만, OAM 클라이언트 프레임워크를 사용하여 OAM 클라이언트를 개발함으로써 지속적으로 성능이 개선될 수 있는 환경을 제공해 준다는 점이 중요하다.

3. OMC의 개발 비용 감소

소프트웨어의 구매, 개발, 유지보수의 비용을 관리하기 위해서는 누구나 납득할 수 있는 정량적 방법이 필요하다. 일반적으로 사용되는 LOC(Line Of Code)는 소프트웨어 개발 프로세스의 초기에는 적용될 수 없으며 사용자 중심이 아닌 개발자에 초점이 맞추어져 있다. 따라서 측정의 초점을 소프트웨어의 구현이 아니라 사용자가 요구하는 기능에 초점을 맞추어 비용을 산정하여야 한다.

기능 점수(Function Point)는 논리적 설계에 기초로 하여 사용자에게 제공되는 기능량을 계량(quantifying its functionality)하고, 물리적 화면 및 프로그램이 아닌 사용자 관점의 논리적 기능량(Logical functionality)을 측정한다.[주:이상운, “기능점수 기반 소프트웨어 공식”, 한국정보처리학회, 2010년] 기능 점수를 사용하면 소프트웨어 개발 촉진법에 따라 OAM 클라이언트의 SW 사업 대가를 산출할 수 있다. OAM 클라이언트 프레임워크는 반 완성된 어플리케이션으로서 OAM 클라이언트를 빠르게 개발할 수있는 템플릿을 제공한다. 템플릿에는 OAM 클라이언트가 기본적으로 제공해야 하는 기능들이 포함되어 있으므로 개발자는 공통적인 기능에 대한 추가적인 개발이 필요없게 된다. 템플릿이 제공하는 기능에 대한 개발 비용을 확인함으로써 OAM 클라이언트 프레임워크를 통해 절감할 수 있는 개발 비용을 산정할 수 있다.

기능 점수의 측정유형은 개발 프로젝트, 개선 프로젝트, 어플리케이션로 나뉜다. 개발 프로젝트 기능점수(DFP, Development Function Point)는 프로젝트가 완료되어 최초 설치되는 시점에서 사용자에게 제공되는 시스템의 기능을 대상으로 기능점수를 측정하는 방식으로, 개발 프로젝트 기능점수로 측정하여 OAM 클라이언트 프레임워크를 사용한 신규 개발 프로젝트의 기능 점수를 산정하기로 한다. 기능 점수를 산정하기 위해서는 소프트웨어의 범위 및 경계를 설정하고 데이터기능(Data Function)과 트랜잭션기능(Transaction Function)을 도출한 후 복잡도 가중치를 적용하여야 한다.

사용자 삽입 이미지

[기능점수 산정 방법]

기능 점수는 설계단계의 산출물들을 기반으로 산정하였다. 데이터 기능을 산정하기 위해서는 논리 ERD, 데이터 설계서, 인터페이스 설계서를 사용하였고, 트랜잭션 기능을 산정하기 위해서는 UI 설계서, 상세스펙을 사용하였다.

기능

외부입력(EI)

외부

출력

(EO)

외부

조회

(EQ)

Level 1

Level 2

Level3

입력

수정

삭제

로그인

로그인

로그인

1

성능 관리

성능 모니터링

성능 모니터링

1

서비스 모니터링

서비스 모니터링

1

구성관리

구성 관리

구성 항목 조회

1

구성 항목 추가/수정/삭제

1

1

1

형상 관리

형상 조회

1

운용자

관리

운용자 정보 관리

운용자 정보 조회

1

운용자 정보 수정

1

장애 관리

장애 이력 조회

장애 이력 조회

1

장애 모니터링

장애 모니터링

1

통계 관리

통계 관리

통계 조회

1

[OAM 클라이언트 템플릿의 트랜젝션 기능 수]

피 관리 시스템의 장애 정보와 성능 정보는 OAM Agent에 의해 수집되어 OAM 서버의 OAM Manager에게 전송된다. OAM Manager는 1분 주기로 장애 정보와 성능 정보를 집계하여 Database에 저장한다. 이 자료는 내부의 OAM 클라이언트와 외부의 망 관리 시스템(NMS)에게 전송된다. OAM 템플릿이 제공하는 성능 관련 데이터 기능은 대부분의 피 관리 시스템에서 공통적으로 지원할 수 있는 하드웨어 관련 성능 정보만을 처리한다. 장애 관리와 성능 관리를 위한 데이터는 OAM 클라이언트가 없는 OAM 시스템에서도 망 관리 시스템을 위해 존재하여야 하므로 OAM 클라이언트 기능 수에는 포함하지 않았다.

기능

내부 논리 파일

(ILF)

외부 연계 파일

(EIF)

비고

Level 1

Level 2

Level 3

운용자 관리

운용자 관리

운용자 정보

1

운용자 보안 관리

운용자 접속 정보

1

운용자 실행 권한

1

장애 관리

장애 관리

장애 코드

NMS 기능

장애 이력

장애 이력

NMS 기능

성능 관리

하드웨어 성능

CPU 성능

NMS 기능

Memory 성능

NMS 기능

NIC 성능

NMS 기능

File System 성능

NMS 기능

Table Space 성능

NMS 기능

[OAM 클라이언트 템플릿의 데이터 기능 수]

정보통신부 고시로 규정된 소프트웨어 사업대가 기준에서 제시하는 기능 점수 방식은 정규법과 간이법으로 구분할 수 있다. 간이법을 사용하면 트랜잭션과 데이터 기능 목록을 근거로 정통부 고시 평균 복잡도를 적용하여 기능 점수를 산출하고, 어플리케이션 유형, 언어, 품질 및 특성에 대한 보정계수를 적용하여 현실적인 개발 원가를 산정할 수 있다.

항목

구분

보정계수

비율

적용계수

어플리케이션 유형

업무 처리용

95%

1.0

1.0.15

멀티미디어용

5%

1.2

개발 언어

C#

80%

1.2

1.12

Query

20%

0.8

품질 및 특성

분산처리

영향도 1

1.075

성능

영향도 1

신뢰성

영향도 1

다중사이트

영향도 0

[OAM 클라이언트 템플릿의 보정계수]

산출된 기능 점수에 보정계수를 적용하면 OAM 클라이언트 템플릿이 제공하는 개발 원가를 산정할 수 있다. 이 금액은 하나의 OAM 클라이언트를 신규로 개발할 때 절감할 수 있는 금액이며, OAM 클라이언트 템플릿을 사용하여 개발하는 OAM 클라이언트가 많아질수록 절감할 수 있는 개발 비용은 비례하여 증가하게 된다.

Notice

  • 이 저작물은 크리에이티브 커먼즈 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용할 수 있습니다. 크리에이티브 커먼즈 라이선스
  • 저작권과 관련된 파일요청 및 작업요청을 받지 않습니다.
  • 댓글에 대한 답변은 늦을 수도 있습니다.
  • 댓글 남기기

    이메일은 공개되지 않습니다. 필수 입력창은 * 로 표시되어 있습니다