New 병아리 개발자

*개발 기술 환경 요구사항 파악(실기)

1. 기술 환경 정의를 위한 자료 수집

- 온라인 트랜잭션 처리(OLTP) 시스템의 조사항목 (시스템 구축 형태) : 단독 시스템, 고 가용성 시스템, 병렬 구성 여부

- 온라인 트랜잭션 처리(OLTP) 시스템의 조사항목 (사용자 수) : 전체 사용자 수, 동시 사용자 비율, 연간 사용자 증가율

- 온라인 트랜잭션 처리(OLTP) 시스템의 조사항목 (트랜잭션 수) : 연간 트랜잭션 수, 1일 평균 트랜잭션 수, 피크타임 트랜잭션 수, 예상 연간 트랜잭션 증가율

- 웹/웹 애플리케이션 서버(WEB/WAS)의 조사항목 (시스템 용도 및 서비스 형태) : 웹 페이지만 제공, 트랜잭션이 빈번하지 않은 웹 서비스, 트랜잭션이 빈번한 웹 서비스인지 여부

- 웹/웹 애플리케이션 서버(WEB/WAS)의 조사항목 (시스템 구성 형태) : 1계층, 2계층, 3계층

- 웹/웹 애플리케이션 서버(WEB/WAS)의 조사항목 (접속자 수) : 평균/최고/연간 접속자 수, 증가율

- 현행 시스템 담당자가 제공하는 자료와 인터뷰 기록 분석한다.

2. 조사 자료 분석 및 개발 기술 환경 결정

- 조사한 자료를 이용하여 운연체제(OS), 데이터베이스(DBMS), 웹 애플리케이션 서버(WAS) 등을 결정한다.

- 조사 자료 분석 시 각 항목별 고려 사항을 반영하여 개발 기술 환경을 결정한다.

2-1. 조사한 자료를 이용하여 시스템 용량을 산정하는 방법

2-2. CPU 용량 산정(OLPT/배치/데이터베이스 서버)

- 분당 트랜잭션 수 : 산정 대상 서버에서의 분당 트랜잭션 발생 추정치의 합

- 기본 tpmC보정 : 실험환경에서 측정한 tpmC 수치를 복잡한 실제 환경에 맞게 적용하기 위한 보정

- 피크타임 부하 보정 : 업무가 과중한 시간대에 시스템이 원활하게 운영할 수 있도록 피크타임을 고려한 보정

- 데이터베이스 크기 보정 : 데이터베이스 테이블의 레코드 건수와 전체 데이터베이스 볼륨을 고려한 보정

- 애플리케이션 구조 보정 : 애플리케이션 구조와 요구되는 응답 시간에 따른 성능 차이를 감안한 보정

- 애플리케이션 부하 보정 : 온라인 작업을 수행하는 피크타임에 배치 작업 등이 동시에 이루어지는 경우를 감안한 보정

- 클러스터 보정 : 클러스터 환경에서 장애발생 시를 대비한 보정

- 시스템 여유율 : 예기치 못한 업무의 증가 등을 위한 여유율

- 시스템 목표 활용률 : 시스템의 안정적인 운영을 전제로 한 CPU 활용률

- 산정식 : CPU(tpmC 단위) = (분당 트랜잭션 수) X (기본 tpmC 보정) X (peak time 부하 보정) X (DB 크기 보정) X (앱 구조 보정) X (앱 부하 보정) X (클러스터 보정) X (시스템 여유율) / (시스템 목표 활용률)

2-2. CPU 용량 산정(WEB/WAS 서버)

- 동시 사용자 수 : 소프트웨어나 시스템을 네트워크 상에서 동시에 사용하는 사용자

- 사용자당 오퍼레이션 수 : 사용자 한 사람이 초당 발생시키는 오퍼레이션 수

- 기본 OPS 보정 : 실험환경에서 측정한 ops 수치를 복잡한 실제 환경에 맞게 적용하기 위한 보정

- 업무용도 보정 : 적용대상 시스템 유형에 따른 보정치

- 인터페이스 부하 보정 : 서버가 타서버와 통신하게 될 때 인터페이스에서 발생하는 부하를 고려한 보정

- 피크타임 부하 보정 : 갑자기 많은 접속으로 인해 부하가 발생하는 것을 해결하기 위한 보정

- 클러스터 보정 : 클러스터 환경에서 장애발생시를 대비한 보정(노드수에 따른 적용)

- 시스템 여유율 : 시스템의 안정된 운영을 위한 보정

- 시스템 목표 활용률 : 시스템의 안정적인 운영을 전제로 한 CPU 활용률

- 산정식 : CPU(OPS 단위) = (동시 사용자 수) X (사용자당 operation 수) X (기본 OPS 보정) X (인터페이스 부하보정) X (peak time 부하 보정) X (클러스터 보정) X (시스템 여유율) / (시스템 목표 활용률)

2-3. 메모리 용량 산정

- 시스템 영역 : OS, DBMS 엔진, 미들웨어 엔진, 기타 유틸리티 등의 소요공간

- 사용자당 필요 메모리 : 애플리케이션, 미들웨어 DBMS의 사용에 필요한 사용자당 메모리

- 동시사용자 수 : 소프트웨어나 시스템을 네트워크상에서 동시에 사용하는 사용자

- OS 버퍼캐시 보정 : 처리 속도를 향상시키기 위해 일정량의 데이터를 임시로 모아 놓은 기억장소를 위한 보정

- 미들웨어 버퍼캐시 메모리 : DBMS의 공유메모리, WAS의 heap size 등 미들웨어에서 사용하는 캐시 영역

- 시스템 여유율 : 시스템의 안정된 운영을 위한 보정

- 산정식 : 메모리(MB 단위) = [(시스템 영역) + {(사용자당 필요 메모리) X (사용자 수)} + (미들웨어 버퍼캐시 메모리)] X (버퍼캐시 보정) X (시스템 여유율)

2-4. 디스크 용량 산정

- 시스템 OS 영역 : 운영체제 및 시스템 소프트웨어 등을 위한 영역

- 응용 프로그램 영역 : 미들웨어 및 응용 소프트웨어 영역, 데이터베이스 설치 영역, 기타 유틸리티 설치 영역 등 응용 프로그램을 대상으로 함

- SWAP 영역 : 시스템 장애 시의 Dump 역할 수행과 메모리 대용의 효율적인 Swapping을 수행하기 위한 작업공간

- 파일 시스템 오버헤드 : 일반 사용자 관리 영역을 위한 수퍼유저의 관리 공간 및 I-node Overhead, 수퍼블럭, 실린더 그룹 등 파일관리 공간

- 시스템/데이터 디스크 여유율 : 시스템의 안정된 운영을 위한 보정으로 업무의 중요도나 긴급도를 감안하여 적용

- 데이터 영역 : 실제 필요한 데이터량

- 백업 영역 : 데이터와 데이터의 변경내역 정보 등의 백업을 위한 공간

- RAID 여유율 : RAID 디스크가 도입될 경우 데이터 보호를 위한 패러티 영역으로 사용되는 공간을 위한 보정

3. 요구사항 정의서, 목표 시스템 구성도 반영 및 검토

- 운영체제, 데이터베이스, 웹 애플리케이션 서버 등 시스템 용량 산정 결과를 요구사항 정의서, 목표 소프트웨어 구성도, 목표 하드웨어 구성도에 반영한다.

- 각 팀별로 작성된 산출물을 상호 검토하여 의견을 제시한다.

- 다른 팀의 검토의견을 반영하여 산출물을 수정하고 최종 완료한다.

*개발 기술 환경 현행 시스템 분석

1. 운영체제 현행 시스템 분석

1-1. 운영체제란

- 컴퓨터 시스템이 제공하는 모든 하드웨어, 소프트웨어를 사용할 수 있도록 해주고, 컴퓨터 사용자와 컴퓨터 하드웨어 간의 인터페이스를 담당하는 프로그램이다.

- 사용자가 컴퓨터를 좀 더 쉽게 사용하기 위해 지원하는 소프트웨어이다.

1-2. 운영체제 현행 시스템 분석

- 운영체제 현행 시스템 분석 시 품질 측면과 지원 측면 등을 고려해야 한다.

- 품질 측면 (신뢰도) : 장기간 시스템 운영 시 운영체제의 장애 발생 가능성, 운영체제의 버그로 인한 재기동 여부

- 품질 측면 (성능) : 대규모 및 대량 파일 작업(배치 작업)처리, 지원 가능한 메모리 크기(32비트, 64비트)

- 지원 측면 (기술 지원) : 공급사들의 안정적인 기술 지원, 오픈 소스 여부

- 지원 측면 (주변 기기) : 설치 가능한 하드웨어, 다수의 주변 기기 지원 여부

- 지원 측면 (구축 비용) : 지원 가능한 하드웨어 비용, 설치할 응용 프로그램의 라이선스 정책 및 비용, 유지 및 관리 비용

1-3. 운영체제의 종류 및 특징

- 대표적으로 PC, 모바일 운영체제로 나뉜다.

- PC (윈도즈 Windows) : Microsoft, 중/소규모 서버, 일반 PC 등 유지, 관리 비용 장점

- PC (유닉스 UNIX) : IBM, HP, SUN, 대용량 처리, 안정성 높은 엔터프라이즈급 서버

- PC (리눅스 Linux) : Linus Torvalds, 중/대규모 서버 대상, 높은 보안성 제공

- 모바일 (안드로이드 Android) : Google, 스마트폰, 태블릿 PC, 다양한 기기의 호환성 제공

- 모바일 (IOS) : Apple, 스마트폰, 태블릿 PC의 높은 보안성과 고성능 제공

- 리눅스 기반 시스템이 하드웨어 및 소프트웨어 소유 비용이 가장 적게 소요된다.

2. 네트워크 현행 시스템 분석

2-1. 네트워크란

- 컴퓨터 장치들의 노드 간 연결(데이터 링크)을 사용하여 서로에게 데이터를 교환할 수 있도록 하는 기술이다.

- 데이터 링크들은 광 케이블과 같은 유선 매체 또는 와이파이(Wi-Fi)와 같은 무선 매체를 통해 확립된다.

2-2. OSI 7계층

- 네트워크 통신에서 생긴 여러 가지 충돌 문제를 완화하기 위해 국제 표준화 기구(ISO)에서 제시한 네트워크 기본 모델이다.

- 응용 계층 : 사용자와 네트워크 간 응용 서비스 연결, 데이터 생성 (HTTP, FTP 프로토콜 / 전송단위는 데이터)

- 표현 계층 : 데이터 형식 설정과 부호 교환, 암호화/복호화 (JPEG, MPEG 프로토콜 / 전송단위는 데이터)

- 세션 계층 : 연결 접속 및 동기제어 (SSH, TLS 프로토콜 / 전송단위는 데이터) 

- 전송 계층 : 신뢰성 있는 통신 보장, 데이터 분할과 재조립, 흐름 제어, 오류 제어, 혼잡제어 등을 담당 (TCP, UDP 프로토콜 / 전송단위는 세크먼트)

- 네트워크 계층 : 단말 간 데이터 전송을 위한 최적화된 경로 제공 (IP, ICMP 프로토콜 / 전송단위는 패킷)

- 데이터 링크 계층 : 인접 시스템 간 데이터 전송, 전송오류 제어, 동기화, 흐름 제어 등의 전송 기능 제공, 오류 검출, 재전송 등 기능 제공 (이더넷 / 전송단위는 프레임)

- 물리 계층 : 0과 1의 비트 정보를 회선에 보내기 위한 전기적 신호 변환 (RS-232C / 전송단위는 비트)

2-3. 네트워크 현행 시스템 분석

- 현행 시스템이 구성된 네트워크 구조를 네트워크 구성도를 통해 분석한다.

- 네트워크 구성도를 통해 서버 위치, 서버 간 연결 방식을 파악할 수 있다.

- 백본망, 라우터, 스위치, 게이트웨이, 방화벽 등을 대상으로 분석한다.

- 네트워크 분석 시 물리적인 위치 관계 파악, 조직 내 보안 취약성 분석 및 대응이 가능하다.

- 네트워크 장애 발생 추적 및 대응 등의 다양한 용도로 활용할 수 있다.

3. DBMS 현행 시스템 분석

3-1. DBMS란

- 데이터베이스라는 데이터의 집합을 만들고, 저장 및 관리할 수 있는 기능들을 제공하는 응용 프로그램이다.

3-2. DBMS의 기능

- 중복 제어 : 동일한 데이터가 여러 위치에 중복으로 저장되는 현상 방지

- 접근 통제 : 권한에 따라 데이터에 대한 접근 제어

- 인터페이스 제공 : 사용자에게 SQL 및 CLI, GUI 등 다양한 인터페이스 제공

- 관계 표현 : 서로 다른 데이터 간의 다양한 관계를 표현할 수 있는 기능 제공

- 샤딩/파티셔닝 : 구조 최적화를 위해 작은 단위로 나누는 기능 제공

- 무결성 제약조건 : 무결성에 관한 제약조건을 정의/검사하는 기능 제공

- 백업 및 회복 : 데이터베이스 장애 발생 시 데이터의 보존 기능 제공

3-3. DBMS 현행 시스템 분석

- 성능 측면 (가용성) : 장기간 시스템을 운영할 때 장애 발생 가능성, 백업 및 복구 편의성, DBMS 이중화 및 복제 지원 여부

- 성능 측면 (성능) : 대규모 데이터 처리 성능, 대량 거래 처리 성능, 다양한 튜닝 옵션 지원 여부, 비용 기반 최적화 지원 및 설정의 최소화 지원 여부

- 성능 측면 (상호 호환성) : 설치 가능한 운영체제 종류, 다양한 운영체제에서 지원되는 JDBC, ODBC

- 지원 측면 (기술 지원) : 공급 업체들의 안정적인 기술 지원 여부, 다수의 사용자 간의 정보 공유 여부, 오픈 소스 여부

- 지원 측면 (구축 비용) : 라이언스 정책 및 비용, 유지 및 관리 비용

4. 미들웨어의 현행 시스템 분석

4-1. 미들웨어란

- 미들웨어는 분산 컴퓨팅 환경에서 응용 프로그램과 프로그램이 운영되는 환경 간에 원만한 통신이 이루어질 수 있도록 제어해주는 소프트웨어이다.

- 운영체제와 소프트웨어 애플리케이션 사이에 위치하고 있다.

- 대표적인 미들웨어로는 WAS가 있다.

4-2. 웹 애플리케이션 서버(WAS)란

- 웹 애플리케이션 서버는 서버계층에서 애플리케이션이 동작할 수 있는 환경을 제공하고 안정적인 트랜잭션 처리와 관리, 다른 이 기종 시스템과의 애플리케이션 연동을 지원하는 서버이다.

4-3. 미들웨어의 현행 시스템 분석

- 성능 측면 (가용성) : 장기간 시스템을 운영할 때 장애 발생 가능성, 안정적인 트랜잭션 처리 능력, WAS의 버그 등을 개선하는 패치 설치를 위한 재기동 기능 지원 여부, WAS 이중화 지원 여부

- 성능 측면 (성능) : 대규모 데이터 처리 성능, 다양한 설정 옵션 지원 여부, 가비지 컬렉션의 다양한 옵션 기능 여부

- 지원 측면 (기술 지원) : 공급 벤더들의 안정적인 기술 지원 여부, 다수의 사용자들 간의 정보 공유 여부, 오픈 소스 여부

- 지원 측면 (구축 비용) : 라이선스 정책 및 비용, 유지 및 관리 비용, 총 소유 비용

5. 오픈 소스 사용 시 고려 사항

- 오픈 소스를 사용하는 경우에는 라이선스의 종류, 사용자 수, 기술의 지속 가능성 등을 고려해야 한다.

- 오픈 소스 소프트웨어의 전체 조건인 자유 배포, 소스 코드 공개, 파생작업 허용, 소스 코드 일관성 확보, 차별금지, 라이선스 배포, 포괄적 허용을 고려해야 한다.  

*현행 시스템 분석서 작성 및 검토

1. 현행 시스템 관련 자료 수집

- 현행 시스템 관련 자료 수집을 위해서 수집 자료의 특성에 따라 3개의 팀을 구성한다.

- 정보시스템 구성/기능 및 인터페이스 자료 수집팀 : 정보시스템 구성도, 정보시스템 기능 구성도, 정보시스템 인터페이스 현황

- 현행 시스템 아키텍처 및 소프트웨어 자료 수집팀 : 현행 시스템 아키텍처 구성도, 소프트웨어 구성도

- 하드웨어 및 네트워크 자료 수집팀 : 하드웨어 구성도, 네트워크 구성도

- 수집 자료의 성격에 따라서 팀을 명확하게 구분하는 것이 필요하다.

2. 수집 자료의 분석

- 수집된 정보들을 취합, 정제하고, 중복되거나 유효하지 않은 정보들은 삭제 한다.

- 불명확한 부분은 체크한 후 분석 및 설계 단계를 통해 구체적으로 조사한다.

- 현행 시스템의 이슈 및 문제점을 파악한다.

3. 분석한 결과를 기반으로 산출물 작성

- 각 취득 자료를 분석한 결과를 기반으로 산출물을 작성한다.

- 현행 시스템의 이슈나 문제점을 산출물에 상세하게 포함하여 작성한다.

4. 산출물에 대한 검토 수행

- 팀별로 작성된 산출물을 상호 검토하여 의견을 제시한다.

- 다른 팀의 검토의견을 반영하여 산출물을 수정하고 최종 완료한다.

*소프트웨어 아키텍처(실기)

- 여러 가지 소프트웨어 구성요소와 그 구성요소가 가진 특성 중에서 외부에 드러나는 특성, 그리고 구성요소 간의 관계를 표현하는 시스템의 구조나 구조체를 의미한다. 또한, 소프트웨어를 설계하고 전개하기 위한 지침이나 원칙이다.

*소프트웨어 아키텍처 프레임워크

- 소프트웨어 집약적인 시스템에서 아키텍처가 표현해야 하는 내용 및 이들 간의 관계를 제공하는 아키텍처 기술 표준이다.

*소프트웨어 아키텍처 프레임워크 구성요소

1. 아키텍처 명세서

- 아키텍처를 기록하기 위한 산출물

- 이해관계자들의 시스템에 대한 관심을 관점에 맞추어 작성한 뷰로 표현

- 개별 뷰, 뷰 개괄 문서, 인터페이스 명세 등이 있다.

2. 이해관계자

- 시스템 개발에 관련된 모든 사람과 조직

- 고객, 최종사용자, 개발자, 프로젝트 관리자, 유지보수자, 마케팅 담당자 등을 포함

3. 관심사

- 시스템에 대해 이해관계자들의 서로 다른 의견과 목표이다.

- 사용자 입장 : 기본적인 기능, 신뢰성, 보안, 사용성 등의 품질

- 유지보수자 입장 : 유지보수의 용이성

- 개발자 입장 : 적은 비용과 인력으로 개발

4. 관점

- 개별 뷰를 개발할 때 토대가 되는 패턴이나 양식

- 이해관계자들이 서로 다른 역할이나 책임으로 시스템이나 산출물들에 대해 보고 싶은 관점

5. 뷰

- 서로 관련 있는 관심사들의 집합이라는 관점에서 전체 시스템을 표현

- 시스템에 대한 아키텍처 설명에는 하나 이상의 뷰로 구성

6. 근거

- 아키텍처 결정 근거, 회의 결과, 보고 결과

*소프트웨어 아키텍처 4+1 뷰

- 고객의 요구사항을 정리해 놓은 시나리오를 4개의 관점에서 바라보는 소프트웨어적인 접근 방법이다.

- 4개의 분리된 구조로 구성되는 아키텍처 개념을 제시하고, 이들 4개 구조가 서로 충돌되지 않는지, 시스템의 요구사항을 충족시키는지를 증명하기 위해 체크방법으로 유스케이스를 사용한다.

*소프트웨어 아키텍처 4+1 뷰 구성요소

- 4+1에서 1은 유스케이스 뷰를 의미하고, 4는 논리 뷰 / 구현 뷰 / 프로세스 뷰 / 배포 뷰를 의미한다.

1. 유스케이스 뷰

- 아키텍처를 도출하고 설계하는 작업을 주도하는 뷰

- 다른 뷰를 검증하는 데 사용

2. 논리 뷰

- 설계 모델의 추상화이며, 주요 설계 패키지와 서브 시스템, 클래스를 식별하는 뷰

- 시스템의 기능적인 요구사항 지원

- 클래스와 이들 간 관계에 대한 집합을 보여주는 클래스 다이어그램으로 표현

3. 프로세스 뷰

- 런타임시의 시스템의 태스크, 스레드, 프로세스와 이들 사이의 상호작용 등의 관계를 표현하는 뷰

- 성능이나 가용성과 같은 시스템의 비 기능적인 요구사항을 고려

4. 구현 뷰

- 개발 환경 안에서 정적인 소프트웨어 모듈 (소스 코드, 데이터 파일, 컴포넌트, 실행 파일 등)의 구성을 표현하는 뷰

- 개발자 관점에서 소프트웨어의 구현과 관리적인 측면을 컴포넌트 다이어그램으로 표현

- 컴포넌트 뷰라고도 한다.

5. 배포 뷰

- 물리적인 노드의 구성과 상호 연결 관계를 배포 다이어그램으로 표현하는 뷰

- 다양한 실행 파일과 다른 런타임 컴포넌트가 해당 플랫폼 또는 컴퓨팅 노드에 어떻게 매핑되는가를 보여주며, 가용성, 신뢰성, 성능, 확장성 등의 시스템의 비 기능적인 요구사항을 고려