백자의 블로그

주제: 증권 거래소의 효율적인 운영을 위한 성능 튜닝

• 연상법: '증권 거래소의 거래 효율화 프로젝트'

1. 튜닝 3단계: 진분결 (증권 거래소 개선 프로젝트의 단계)

진단 단계 (진): '시장 조사 및 분석'

• 인설시자트:
  • 인터뷰(인): '투자자와의 인터뷰' - 투자자들과의 대화를 통해 그들이 거래 시 경험하는 문제점을 수집합니다.
  • 설계(설): '거래 시스템 설계 검토' - 현재 거래 시스템의 설계를 분석하여 효율성을 저해하는 요소를 식별합니다.
  • 시스템(시): '거래 플랫폼 기술 분석' - 거래 플랫폼의 기술적 구성을 검토하여 성능 저하의 기술적 원인을 파악합니다.
  • 자원(자): '자원 배치 최적화' - 거래 처리에 사용되는 컴퓨팅 자원의 배치와 활용도를 분석합니다.
  • 트레이스(트): '거래 데이터 흐름 추적' - 실시간 거래 데이터 흐름을 추적하여 병목 지점을 확인합니다.

분석 단계 (분): '시장 구조 및 운영 분석'

• 설쿼디오하:
  • 설계 내용(설), 쿼리(SQL), DBMS, 운영체제(OS), 하드웨어(HW) 등 거래소의 전반적인 시스템을 체계적으로 분석합니다.

결과 단계 (결): '거래 개선 결과 평가'

• 자분결산:
  • 자료수집/분석(자): 개선된 시스템에서의 거래 데이터를 수집 및 분석하여 성능 개선 효과를 평가합니다.
  • 결과 평가(결): 거래 속도와 효율성이 향상되었는지를 평가합니다.
  • 산출물 작성(산): 개선 프로젝트의 성과를 문서화하고 향후 개선 계획을 수립합니다.

성능 지표: TRL (Throughput, Response Time, Load Time)

• 연상법: '거래 효율성 측정'
  • 증권 거래소에서 거래 처리율, 거래 반응 시간, 최대 거래량 처리 시간을 측정하는 도구와 비교할 수 있습니다.

DB 튜닝 기법

• 디자인 단계 기법: 거래 시스템의 데이터베이스, 테이블, 인덱스 구조를 최적화하여 거래 지연을 최소화합니다.
• DB 환경: 거래소의 DBMS, OS, Storage, Network 구성을 최적화하여 빠른 거래 처리를 지원합니다.
• SQL 기법: 거래 쿼리 최적화, 조인 순서 조정, 병렬 처리를 통해 거래 처리 속도를 높입니다.

1. 옵티마이저 핵심 기능

• 실행계획 탐색: '탐험가의 지도 찾기'로 상상하세요. 탐험가가 보물을 찾기 위해 여러 지도 중 최적의 경로를 찾는 것처럼, 옵티마이저는 실행 계획을 탐색합니다.
• 비용 산정: '쇼핑 중 비교 가격표 확인'으로 연상하세요. 쇼핑을 할 때 다양한 제품의 가격을 비교하며 최적의 선택을 하는 것처럼, 옵티마이저는 각 실행 계획의 비용을 추정합니다.

2. 규칙기반 옵티마이저 (RBO)

• 우선순위 - SR CIF:
  • Single Row (SR): '싱글 레이서'로 상상하세요. 레이스에서 혼자 빠르게 결승점을 향해 달리는 것처럼, 단일 행 처리는 가장 빠릅니다.
  • Cluster (C): '클러스터 풍선'으로 상상하세요. 여러 풍선이 뭉쳐 있는 것처럼, 클러스터는 데이터 묶음 처리에 유리합니다.
  • Index (I): '인덱스 카드 정리'로 생각하세요. 정보를 빠르게 찾기 위해 인덱스 카드를 사용하는 것처럼, 인덱스는 데이터 접근을 빠르게 합니다.
  • Full Scan (F): '풀 코스 레이스'로 연상하세요. 모든 구간을 돌아야 하는 마라톤처럼, 전체 스캔은 데이터베이스 전체를 조사합니다.

3. 비용기반 옵티마이저 (CBO)

• 특징: '비용 효율적인 쇼핑'으로 비유할 수 있습니다. 가능한 한 적은 비용으로 최대의 효과를 얻으려는 쇼핑과 같이, CBO는 가장 비용 효율적인 실행 계획을 선택합니다.

4. 구성요소

• 질의 변환기 (Query Transformer): '요리 레시피 변환기'로 상상하세요. 다양한 재료를 사용해 새로운 요리를 만드는 것처럼, 질의 변환기는 SQL 질의를 최적의 형태로 변환합니다.
• 비용산정기 (Cost Estimator): '여행 비용 계산기'로 연상하세요. 여행 전에 경비를 계산하는 것처럼, 비용산정기는 실행 계획의 비용을 산정합니다.
• 실행 계획 생성기 (Plan Generator): '투어 가이드 플랜 생성기'로 생각하세요. 여행 일정을 계획하는 투어 가이드처럼, 실행 계획 생성기는 최종 실행 계획을 생성합니다.

기출문제

1. 소프트웨어 코드의 정제를 통한 생산성 향상기법, SW 리팩토링의 개요

가. SW 리팩토링(Refactoring)의 정의

• 소프트웨어 모듈의 외부적 기능은 수정하지 않고 내부적인 구조, 관계등을 단순화하여 소프트웨어의 유지보수성을 향상시키는 기법

1. SW 리팩토링의 목적

1. Good 소프트웨어의 조건

라. 리팩토리 대상

1. SW 리팩토리 수행절차와 기법

  가. SW 리팩토리 수행절차

나. SW 리팩토링의 주요 기법

III. 리팩토링을 제대로 하기 위한 기술 및 적용시점

1. 리팩토링을 제대로 하기 위한 기술

1. 리팩토링 적용시점

[참고]

1. Pull up Method

- 동일기능 중복해서 구현되었을 경우, 확산적 변경현상이 발생할 확률 농후

- 중복된 기능(메소드, 클래스)를 상위로 올리는 것

1. Extract Interface

- 두 클래스에 공통적인 기능(메소드, 클래식)이 있을 경우 인터페이스로 분리하여 참조 받는 방식

1. Move Method

- 메소드가 자신이 정의된 클래스보다 다른 클래스의 기능을 더 많이 사용하고 있다면 이 메소드를 가장 많이 사용하고 있는 클래스에 비슷한 몸체를 가진 새로운 메소드를 만들어라

-- 2018.06.04 추가내용 

<참조 사이트>

https://www.refactoring.com/catalog/

http://arisu1000.tistory.com/search/Inline%20Class

기법	개념도	설명
Inline Class		클래스가 별로 하는일이 없다면 해당 클래스의 기능을 다른 클래스안으로 옮기고 클래스를 삭제
Inline Method		메소드의 본문이 메소드 이름 만큼이나 명확하다면 해당 본문을 메소드를 호출하는 호출자 안으로 옮기고 메소드를 삭제
Extract Class		두개의 클래스에서 작업 되야 하는 하나의 클래스가 있다면 새로운 클래스를 만들고 이전 클래스에 있던 관련된 필드와 메소드를 새로운 클래스로 옮김
Extract Method		함께 그룹화될 수 있는 코드 조각이 있다면 적절한 메소드를 만들고 코드들을 해당 메소드 안으로 옮김
Extract Interface		인터페이스가 같은 부분을 사용하면, 인터페이스의 같은 부분은 추출하여 인터페이스를 통합 추출 적용함.
Move Class		기능과 관련 없는 다른 클래스들이 패키지에 포함되어 있다면 해당 클래스를 더 관련성이 높은 패키지로 옮기거나 추후 사용될 가능성이 있는 새 패키지를 생성
Move Method		메소드가 정의된 클래스보다 다른 클래스에서 더 많이 사용된다면 해당 클래스로 메소드를 옮기고, 이전 메소드에는 단순 대리자를 만들거나 전체에서 제거
Move Field		필드가 정의된 클래스보다 다른 클래스에서 더 많이 사용된다면 필드를 더 많이 사용되는 다른 클래스로 옮기고, 필드를 사용하는 모든 사용자들을 변경
Pull Up Method		서브클래스들에 같은 결과를 반환하는 메소드들을 가지고 있다면 해당 메소드들을 슈퍼클래스로 옮김
Pull Up Field		두개의 서브클래스가 같은 필드를 가지고 있다면 해당 필드를 슈퍼클래스로 옮김
Push Down Method		슈퍼클래스의 행위가 특정 서브클래스하고만 관련있다면 해당 메소드를 그 서브클래스로 옮김
Push Down Field		어떤 필드가 특정 서브클래스에서만 쓰인다면 그 서브클래스로 필드를 옮김.
Rename Method		메소드의 이름이 메소드의 목적을 나타내지 못한다면 메소드의 이름을 변경

기출문제

I. 합리적이고 객관적인 대가 산정을 위한 기준, SW 사업 대가 산정 가이드의 개요

가. SW 대가 산정 가이드의 정의

- 소프트웨어의 기획, 현 운영 등 수명 주기 전 단계에 대한 사업을 추진함에 있어 이에 대한 예산 수립, 사업 발주, 계약 시 적정 대가를 산정하기 위한 가이드

나. SW 대가 산정 가이드의 특징

-  2012년 2월 26일 이후 정부에서 민간으로 이양

- 글로벌 표준에 입각한 ISO 12207 기반의 소프트웨어의 수명 주기 (기획, 구현, 유지 보수/운영) 전반에 걸쳐 설명하고, 보다 편리하게 수행할 수 있는 도구를 제공

II. SW 대가 산정의 일반적인 절차 및 사업 유형

가. SW 대가 산정의 일반적인 절차

- 대가 산정의 대상이 되는 사업의 유형과 대가 산정 시점에 따라 적절한 모형을 선택하여 적용

나. 사업 유형 식별

- 대가 산정 시점은 예산 확보, 사업 발주, 사후 정산 단계 각각에서 수행함

III. 대가 산정 시점과 대가 산정 모형

가. 대가 산정 시점 구분

나. SW 대가 대가 산정 모형별 적용시점(2018년)

△1) - SLA기반 유지관리 및 운영비 정산법은 예산확보 단계 및 사업발주 단계에 사업비를 산정하기 위해 직접 적용되지는 않으나, SLA기반의 정산법을 사용하는 경우 사전에 사후 정산의 가능성을 고려해야 한다.

다. 수명 주기별 대가 산정 방식

IV. 소프트웨어 개발비 절차

라. 대가산정 방법별 주요 내용

IV. SW개발비 산정 사례

- 복잡도 보정요소를 반영하여 20FP(점)이 산정되었다 다음 항목을 반영하여 SW개발비를 산정하시오

기출문제

[문제에서 데이터 기능측정, 트랜잭션 기능측정 주어짐]

1. 소프트웨어 복잡도에 의한 규모 산정방식, FP의 개요

가. FP(Function Point, ISO/IEC 14143-1)의 정의

• 정보처리 규모와 기능의 복잡도 요인에 의거한 SW 규모 산정 방식
• 소프트웨어 크기를 결정하는 소프트웨어 기능 유형별 수량과 성능 및 품질요인들의 영향도를 고려하여 계산되는 SW 규모 산정 방식

1. FP의 산정방식 /* 사개보후지소 */

II. 기능점수 산출방법 사례를 통한 답안 작성

[문제풀이]

III, 기능점수 산출 방법의 두가지 유형(정규법과 간이법)비교

기출문제

1. 소프트웨어 복잡도에 의한 규모 산정방식, FP의 개요

가. FP(Function Point, ISO/IEC 14143-1)의 정의

• 정보처리 규모와 기능의 복잡도 요인에 의거한 SW 규모 산정 방식
• 소프트웨어 크기를 결정하는 소프트웨어 기능 유형별 수량과 성능 및 품질요인들의 영향도 고려하여 계산되는 SW 규모 산정 방식

나. FP의 등장배경 (LOC의 문제점)

다. FP의 특징

1. FP 개념도 및 구성요소

가. FP의 개념도

- FP 개념도와 구성요소

1. FP산정 절차 및 상세내용

가. FP의 산정 절차

나. FP의 상세내역

1. 측정 유형 결정

1. 측정 범위와 어플리케이션 경계 식별

• 사용자와 어플리케이션 경계 식별 구성도

1. 데이터 기능 유형(Data Function Type)

- 복잡도 산정 방법은 DET(Data Element Type)과 RET(Record Element Type)을 통해서 이루어짐.

- DET는 ILF나 EIF에 유지되는 필드 중에서 사용자가 식별 가능하고 비반복적인 필드 의미하고 RET는 DET의 서브 셋을 의미. 이 둘을 식별하고 개수를 파악하는 것.

- DET와 RET를 계산 후에 이것을 기여도 테이블로 변환해서 최종 데이터 기능점수를 계산.

- DET: 반복되지 않고 사용자가 식별 가능한 필드(속성값)

1. 트랜잭션 기능 유형(Transaction Function Type)

• FTR: 어플리케이션에서 참조하는 ILF나 EIF의 수를 의미

1. 미조정 기능점수 결정
2. 조정인자결정

- 조정인자 계산: [ {각 (14개 항목 * 0 ~ 5)의 합} * 0.01 ] + 0.65의 계산공식

1. 조정 기능점수 결정(±35% 조정가능)

(AFP: Adjusted Function Point, UFP: Unadjusted Function Point, VAF: Value Adjustment Factor)

1. 기능점수 산출 방법의 두가지 유형(정규법과 간이법)비교 및 규모산정 방식 비교

가. 기능점수 산출 방법 비교

나. 규모산정방식 비교

1. FP의 활용 부문 및 문제점

가. FP의 활용부문

• 생산성과 품질 등의 척도로 활용 가능, 생산성 = FP / MM, 품질 = 결함 / FP,

비용 = 비용 / FP, 문서량 = 문서페이지 / FP

나. FP의 문제점

• Data Function: 사용자 관점에서 측정되기 때문에 감추어진 EI, EO, EQ를 찾기 힘듦
• Transaction Function: 사용자 관점에서 사용되는 파일수를 정확히 찾기 힘듦
• 기술도 복잡도 측면: 14개 항목에 대한 측정자의 주관에 의존

기출문제

I. 소프트웨어의 적정한 비용산정 통한 대가산정방식, 소프트웨어 비용 산정의 개요

가. 개발비용 산정의 정의

• 소프트웨어 규모파악(양적 크기, 질적 수준) 통한 소요공수와 투입자원 및 소요기간 파악하여 실행 가능한 계획 수립하기 위한 비용 산정하는 과정
• 단위작업공수(비용) 통한 총공수(총비용) 산정 (WBS 근거해 비용산정)

나. 규모산정의 의의

II. 소프트웨어 비용산정 방법 및 비교

가. 소프트웨어 규모산정 방법 종류

- 기획단계: Man/Month 등

- 구현단계: 기능점수

- 운영단계: 요율제, 투입공수 등 (SW사업대가산정가이드, 2018)

나. 소프트웨어 규모산정 방법 비교

III. 소프트웨어 규모산정 시 고려요소

기출문제

I. 정보시스템 감리 보고서의 개념

- “감리보고서”란 감리인이 감리 및 시정조치확인을 수행한 후 그 결과를 기록한 문서

- “감리보고서”에는 감리대상사업 단계별 점검결과를 명시한 “감리 수행결과보고서”와 시정조치사항을 확인한 결과를 명시한 “시정조치확인보고서”가 있다

II. 감리수행결과보고서의 주요목차 구성 및 주요목차 설명

가. 감리수행결과보고서의 주요목차 구성

감리계획서

관련근거

감리목표

감리적용기준

사업개요

감리단계

감리영역별 점검항목

감리일정

투입인력편성

감리계획서 및 보고서 통보 기관

기타 행정사항

​

감리수행결과보고서

I. 종합의견

1. 전제조건

2. 총평

3. 감리영역별 세부점검결과 요약

​

II. 과업내용반영여부 점검결과

1. 점검현황

2. 점검결과

3. 세부점검결과

​

III. 감리영역별 점검결과

1. 점검항목별 점검결과

2. 상세점검결과