서버 프로그램 구현 1
- 개발 환경 구축
- 개발 프로젝트를 이해하고 소프트웨어 및 하드웨어 장비를 구축하는 것
- 하드웨어 환경
- 사용자와의 인터페이스 역할을 하는 클라이언트, 클라이언트와 통신하여 서비스를 제공하는 서버로 구성
- 클라이언트의 종류 - 개인용 컴퓨터(PC), 스마트폰 등
- 서버의 종류 - 웹 서버, 웹 애플리케이션 서버(WAS), 데이터베이스 서버, 파일 서버
- 소프트웨어 환경
- 클라이언트, 서버 운영을 위한 시스템 소프트웨어, 개발에 사용되는 개발 소프트웨어로 구성
- 시스템 소프트웨어의 종류 - 운영체제, 웹 서버 및 WAS 운용을 위한 서버 프로그램, DBMS 등
- 개발 소프트웨어의 종류 - 요구사항 관리 도구, 설계/모델링 도구, 구현 도구, 빌드 도구, 테스트 도구, 형상 관리 도구 등
- 웹 서버의 기능
- HTTP/HTTPS 지원 - 브라우저로부터 요청을 받아 응답할 때 사용되는 프로토콜
- 통신 기록 - 처리한 요청들을 로그 파일로 기록하는 기능
- 정적 파일 관리 - HTML, CSS, 이미지 등의 정적 파일들을 저장하고 관리하는 기능
- 대역폭 제한 - 네트워크 트래픽의 포화를 방지하기 위해 응답 속도를 제한하는 기능
- 가상 호스팅 - 하나의 서버로 여러 개의 도메인 이름을 연결하는 기능
- 인증 - 사용자가 합법적인 사용자인지를 확인하는 기능
- 개발 언어의 선정 기준
- 적정성 - 개발하려는 소프트웨어의 목적에 적합해야 함
- 효율성 - 코드의 적성 및 구현이 효율적이어야 함
- 이식성 - 다양한 시스템 및 환경에 적용이 가능해야 함
- 친밀성 - 개발 언어에 대한 개발자들의 이해도와 활용도가 높아야 함
- 범용성 - 다른 개발 사례가 존재하고 여러 분야에서 활용되고 있어야 함
- 소프트웨어 아키텍처
- 소프트웨어를 구성하는 요소들간의 관계를 표현하는 시스템의 구조 또는 구조체
- 소프트웨어 아키텍처 설계의 기본 원리 - 모듈화, 추상화, 단계적 분배, 정보은닉
- 모듈화
- 소프트웨어의 성능 향상, 시스템의 수정 및 재사용, 유지 관리 등이 용이하도록 시스템의 기능들을 모듈 단위로 나누는 것
- 모듈 간 결합도의 최소화와 모듈 내 요소들의 응집도를 최대화하는 것이 목표
- 추상화
- 문제의 전체적이고 포괄적인 개념을 설계한 후 차례로 세분화하여 구체화시켜 나가는 것
- 추상화의 유형
- 과정 추상화 - 자세한 수행 과정을 정의하지 않고, 전반적인 흐름만 파악할 수 있게 설계하는 방법
- 자료 추상화 - 데이터의 세부적인 속성이나 용도를 정의하지 않고, 데이터 구조를 대표할 수 있는 표현으로 대체하는 방법
- 제어 추상화 - 이벤트 발생의 정확한 절차나 방법을 정의하지 않고, 대표할 수 있는 표현으로 대체하는 방법
- 단계적 분해
- 문제를 상위의 중요 개념으로부터 하위의 개념으로 구체화시키는 분할 기법
- 정보 은닉
- 한 모듈 내부에 포함된 절차와 자료들의 정보가 감추어져 다른 모듈이 접근하거나 변경하지 못하도록 하는 기법
- 상위 설계와 하위 설계
- 상위 설계
- 별칭 - 아키텍처 설계, 예비 설계
- 설계 대상 - 시스템의 전체적인 구조
- 세부 목록 - 구조, DB, 인터페이스
- 하위 설계
- 별칭 - 모듈 설계, 상세 설계
- 설계 대상 - 시스템의 내부 구조 및 행위
- 세부 목록 - 컴포넌트, 자료 구조, 알고리즘
- 소프트웨어 아키텍처의 품질 속성
- 소프트웨어 아키텍처가 이해 관계자들이 요구하는 수준의 품질을 유지 및 보장할 수 있게 설계되었는지 확인하기 위해 품질 평가 요소들을 구체화 시켜 놓은 것
- 품질 평가 요소의 종류
- 시스템 측면 - 성능, 보안, 가용성, 기능성, 사용성, 변경 용이성, 확장성 등
- 비즈니스 측면 - 시장 적시정, 비용과 혜택, 예상 시스템 수명, 목표 시장, 공개 일정 등
- 아키텍처 측면 - 개념적 무결성, 정확성, 완결성, 구축 가능성, 변경성, 시험성 등
- 협약에 의한 설계
- 컴포넌트를 설계할 때 클래스에 대한 여러 가정을 공유할 수 있도록 명세한 것
- 명세에 포함될 조건
- 선행 조건 - 오퍼레이션이 호출되기 전에 참이 되어야 할 조건
- 결과 조건 - 오퍼레이션이 수행된 후 만족되어야 할 조건
- 불변 조건 - 오퍼레이션이 실행되는 동안 항상 만족되어야 할 조건
- 아키텍처 패턴
- 아케텍처를 설계할 때 참조할 수 있는 전형적인 해결 방식 또는 예제
- 주요 아키텍처 패턴의 종류 - 레이어 패턴, 클라이언트-서버 패턴, 파이프-필터 패턴, 모델-뷰-컨트롤러 패턴 등
- 레이어 패턴
- 시스템을 계층으로 구분하여 구성하는 고전적인 방법의 패턴
- OSI 참조 모델
- 클라이언트-서버 패턴
- 하나의 서버 컴포넌트와 다수의 클라이언트 컴포넌트로 구성되는 패턴
- 파이프-필터 패턴
- 데이터 스트림 절차의 각 단계를 필터로 캡슐화하여 파이프를 통해 전송하는 패턴
- UNIX의 쉘
- 모델-뷰-컨트롤러 패턴
- 서브시스템을 모델, 뷰, 컨트롤러로 구조화하는 패턴
- 기타 패턴
- 마스터-슬레이브 패턴 - 슬레이브 컴포넌트에서 처리된 결과물을 다시 돌려받는 방식으로 작업을 수행하는 패턴
- 브로커 패턴 - 사용자가 원하는 서비스와 특성을 브로커 컴포넌트에 요청하면 브로커 컴포넌트가 요청에 맞는 컴포넌트의 사용자를 연결해주는 패턴
- 피어-투-피어 패턴 - 피어라 불리는 하나의 컴포넌트가 클라이언트가 될수도, 서버가 될수도 있는 패턴
- 이벤트-버스 패턴 - 소스가 특정 채널에 이벤트 메시지를 발행하면, 해당 채널을 구독한 리스너들이 메시지를 받아 이벤트를 처리하는 패턴
- 블랙보드 패턴 - 모든 컴포넌트들이 공유 데이터 저장소와 블랙보드 컴포넌트에 접근이 가능한 패턴
- 인터프리터 패턴 - 프로그램 코드의 각 라인을 수행하는 방법
- 객체지향
- 소프트웨어의 각 요소들을 객체로 만든 후 객체들을 조립해서 소프트웨어를 개발하는 기법
- 객체지향의 구성 요소 - 객체, 클래스, 메시지
- 객체지향의 특징 - 캡슐화, 상속, 다형성, 연관성
- 객체
- 데이터와 이를 처리하기 위한 향수를 묶어 놓은 소프트웨어 모듈
- 데이터 - 객체가 가지고 있는 정보로, 속성이나 상태, 분류 등
- 함수 - 객체가 수행하는 기능으로 객체가 갖는 데이터를 처리하는 알고리즘, 객체가 상태를 참조하거나 변경하는 수단
- 클래스
- 메시지
- 객체들 간의 상호작용에 사용되는 수단으로, 객체의 동작이나 연산을 일으키는 외부의 요구사항
- 캡슐화
- 외부에서의 접근을 제한하기 위해 인터페이스를 제외한 세부 내용을 은닉하는 것
- 상속
- 상위 클래스의 모든 속성과 연산을 하위 클래스가 물려받는 것
- 다형성
- 하나의 메시지에 대해 각각의 객체가 가지고 있는 고유한 방법으로 응답할 수 있는 능력
- 연관성
- 두 개 이상의 객체들이 상호 참조하는 관계
- 연관성의 종류
- 연관화 - 2개 이상의 객체가 상호 관련되어 있음을 의미함 - is member of
- 분류화 - 동일한 형의 특성을 갖는 객체들을 모아 구성하는 것 - is instance of
- 집단화 - 관련 있는 객체들을 묶어 하나의 상위 객체를 구성하는 것 - is part of
- 일반화 - 공통적인 성질들로 추상화한 상위 객체를 구성하는 것 - is a
- 특수화/상세화 - 상위 객체를 구체화하여 하위 객체를 구성하는 것 - is a
- 객체지향 분석
- 사용자의 요구사항과 관련된 객체, 속성, 연산, 관계 등을 정의하여 모델링하는 작업
- 객체지향 분석의 방법론
- Rumbaugh(럼바우) 방법 - 분석 활동을 객체 모델, 동적 모델, 기능 모델로 나누어 수행함
- Booch(부치) 방법 - 미시적(Micro) 개발 프로세스와 거시적(Macro) 개발 프로세스를 모두 사용, 클래스와 객체들을 분석 및 식별하고 클래스의 속성과 연산을 정의함
- Jacobson 방법 - 유스케이스를 강조하여 사용함
- Coad와 Yourdon 방법 - E-R 다이어그램을 사용하여 객체의 행위를 모델링, 객체 식별, 구조 식별, 주체 정의, 속성과 인스턴스 연결 정의, 연산과 메시지 연결 정의
- Wirfs-Brock 방법 - 분석과 설계 간의 구분이 없고, 고객 명세서를 평가해서 설계 작업까지 연속적으로 수행함
- 럼바우의 분석 기법
- 모든 소프트웨어 구성 요소를 그래픽 표기법을 이용하여 모델링하는 기법
- 객체 모델링 기법
- 객체 모델링 -> 동적 모델링 -> 기능 모델링
- 객체지향 설계 원칙(SOLID 원칙)
- 단일 책임 원칙(SRP) - 객체는 단 하나의 책임만 가져야 한다는 원칙
- 개방-폐쇄 원칙(OCP) - 기존의 코드를 변경하지 않고 기능을 추가할 수 있도록 설계해야 한다는 원칙
- 리스코프 치환 원칙(LSP) - 자식 클래스는 최소한 부모 클래스의 기능을 수행할 수 있어야 한다는 원칙
- 인터페이스 분리 원칙(ISP) - 자신이 사용하지 않는 인터페이스와 의존 관계를 맺거나 영향을 받지 않아야 한다는 원칙
- 의존 역전 원칙(DIP) - 의존 관계 성립 시 추상성이 높은 클래스와 의존 관계를 맺어야 한다는 원칙
서버 프로그램 구현 2
- 모듈
- 모듈화를 통해 분리된 시스템의 각 기능
- 서브루틴, 서브시스템, 소프트웨어 내의 프로그램, 작업 단위 등을 의미
- 결합도
- 모듈 간에 상호 의존하는 정도 또는 두 모듈 사이의 연관 관계
- 결합도가 약할수록 품질이 높고, 강할수록 품질이 낮다
- 결합도의 종류와 강도
- 내용 결합도 > 공통 결합도 > 외부 결합도 > 제어 결합도 > 스탬프 결합도 > 자료 결합도
- 결합도의 종류
- 내용 결합도 - 한 모듈이 다른 모듈의 내부 기능 및 그 내부 자료를 참조하거나 수정할 때의 결합도
- 공통 결합도 - 공유되는 공통 데이터 영역을 여러 모듈이 사용할 때의 결합도
- 외부 결합도 - 어떤 모듈에서 선언한 데이터(변수)를 외부의 다른 모듈에서 참조할 때의 결합도
- 제어 결합도 - 어떤 모듈이 다른 모듈 내부의 논리적인 흐름을 제어하기 위해 제어 신호나 제어 요소를 전달하는 결합도
- 스탬프 결합도 - 모듈 간의 인터페이스로 배열이나 레코드 등의 자료 구조가 전달될 때의 결합도
- 자료 결합도 - 모듈 간의 인터페이스가 자료 요소로만 구성될 때의 결합도
- 응집도
- 모듈의 내부 요소들이 서로 관련되어 있는 정도
- 응집도가 강할수록 품질이 높고, 약할수록 품질이 낮다
- 응집도의 종류와 강도
- 기능적 응집도 > 순차적 응집도 > 교환적 응집도 > 절차적 응집도 > 시간적 응집도 > 논리적 응집도 > 우연적 응집도
- 응집도의 종류
- 기능적 응집도 - 모듈 내부의 모든 기능 요소들이 단일 문제와 연관되어 수행될 경우의 응집도
- 순차적 응집도 - 모듈 내 하나의 활동으로 부터 나온 출력 데이터를 그다음 활동의 입력 데이터로 사용할 경우의 응집도
- 교환적 응집도 - 동일한 입력과 출력을 사용하여 서로 다른 기능을 수행하는 구성 요소들이 모였을 경우의 응집도
- 절차적 응집도 - 모듈이 다수의 관련 기능을 가질 때 모듈 안의 구성 요소들이 그 기능을 순차적으로 수행할 경우의 응집도
- 시간적 응집도 - 특정 시간에 처리되는 몇 개의 기능을 모아 하나의 모듈로 작성할 경우의 응집도
- 논리적 응집도 - 유사한 성격을 갖거나 특정 형태로 분류되는 처리 요소들로 하나의 모듈이 형성되는 경우의 응집도
- 우연적 응집도 - 모듈 내부의 각 구성 요소들이 서로 관련 없는 요소로만 구성된 경우의 응집도
- 팬인 / 팬아웃
- 팬인 - 어떤 모듈을 제어하는 모듈의 수
- 팬아웃 - 어떤 모듈에 의해 제어되는 모듈의 수
- N-S 차트
- 논리적 기술에 중점을 두고 도형을 이용해 표현하는 방법
- GOTO나 화살표를 사용하지 않음, 연속, 선택 및 다중 선택, 반복의 3가지 제어 논리 구조로 표현함
- 단위 모듈
- 소프트웨어 구현에 필요한 여러 동작 중 한 가지 동작 중 한 가지 동작을 수행하는 기능을 모듈로 구현한 것
- 단위 모듈로 구현되는 하나의 기능을 단위 기능이라 함
- 단위 모듈의 구현 과정
- 단위 기능 명세서 작성 -> 입.출력 기능 구현 -> 알고리즘 구현
- IPC
- 모듈 간 통신 방식을 구현하기 위해 사용되는 대표적인 프로그래밍 인터페이스 집합
- IPC의 대표 메소드 5가지
- 공유메모리, 소켓, 세마포어, 파이프와 네임드 파이프, 메시지 큐잉
- 테스트 케이스
- 구현된 소프트웨어가 사용자의 요구사항을 정확하게 준수했는지를 확인하기 위한 테스트 항목에 대한 명세서
- ISO/IEC/IEEE 29119-3 표준에 따른 테스트 케이스의 구성 요소
- 식별자 - 항목 식별자, 일련번호
- 테스트 항목 - 테스트 대상(모듈 또는 기능)
- 입력 명세 - 테스트 데이터 또는 테스트 조건
- 출력 명세 - 테스트 케이스 수행 시 예상되는 출력 결과
- 환경 설정 - 필요한 하드웨어나 소프트웨어의 환경
- 특수 절차 요구 - 테스트 케이스 수행 시 특별히 요구되는 절차
- 의존성 기술 - 테스트 케이스 간의 의존성
- 공통 모듈 명세 기반의 종류
- 여러 프로그램에서 공통으로 사용할 수 있는 모듈
- 구현할 때 다음과 같은 명세 기법을 준수
- 정확성 - 시스템 구현 시 해당 기능이 필요 하다는 것을 알 수 있도록 정확히 작성함
- 명확성 - 해당 기능을 이해할 때 중의적으로 해석되지 않도록 명확하게 작성함
- 완전성 - 시스템 구현을 위해 필요한 모든 것을 기술함
- 일관성 - 공통 기능들 간 상호 충돌이 발생하지 않도록 작성함
- 추적성 - 기능에 대한 요구사항의 출처, 관련 시스템 등의 관계를 파악할 수 있도록 작성함
- 코드의 주요 기능
- 코드는 자료의 분류 . 조합 . 집계 . 추출을 용이하게 하기 위해 사용하는 기호
- 코드의 주요 기능
- 식별 기능 - 데이터 간의 성격에 따라 구분이 가능함
- 분류 기능 - 특정 기준이나 동일한 유형에 해당하는 데이터를 그룹화 할 수 있음
- 배열 기능 - 의미를 부여하여 나열할 수 있음
- 표준화 기능 - 다양한 데이터를 기준에 맞추어 표현할 수 있음
- 간소화 기능 - 복잡한 데이터를 간소화할 수 있음
- 코드의 종류
- 순차 코드 - 자료의 발생 순서, 크기 순서 등 일정 기준에 따라서 최초의 자료부터 차례로 일련번호를 부여하는 방법, 순서 코드 또는 일련번호 코드
- 블록 코드 - 코드화 대상 항목 중에서 공통성이 있는 것 끼리 블록으로 구분하고, 각 블록 내에서 일련번호를 부여하는 방법, 구분 코드
- 10진 코드 - 코드화 대상 항목을 0~9까지 10진 분할하고, 다시 그 각각에 대하여 10진 분할하는 방법을 필요한 만큼 반복하는 방법, 도서 분류식 코드
- 그룹 분류 코드 - 코드화 대상 항목을 일정 기준에 따라 대분류, 중분류, 소분류 등으로 구분하고, 각 그룹 안에서 일련번호를 부여하는 방법
- 연상 코드 - 코드화 대상 항목의 명칭이나 약호와 관계있는 숫자나 문자, 기호를 이용하여 코드를 부여하는 방법
- 표의 숫자 코드 - 코드화 대상 항목의 성질, 즉 길이, 넓이, 부피, 지름, 높이 등의 물리적 수치를 그대로 코드에 적용시키는 방법, 유효 숫자 코드
- 합성 코드 - 필요한 기능을 하나의 코드로 수행하기 어려운 경우 2개 이상의 코드를 조합하여 만드는 방법
- 디자인 패턴
- 모듈 간의 관계 및 인터페이스를 설계할 때 참조할 수 있는 전형적인 해결 방식 또는 예제
- GOF의 디자인 패턴은 생성 패턴, 구조 패턴, 행위 패턴으로 구분
- 생성 패턴
- 클래스나 객체의 생성과 참조 과정을 정의하는 패턴
- 추상 팩토리 - 구체적인 클래스에 의존하지 않고, 인터페이스를 통해 서로 연관 . 의존하는 객체들의 그룹으로 생성하여 추상적으로 표현하는 패턴
- 빌더 - 작게 분리된 인스턴스를 건축 하듯이 조합하여 객체를 생성하는 패턴
- 팩토리 메소드 - 객체 생성을 서브 클래스에서 처리하도록 분라하여 캡슐화한 패턴
- 프로토타입 - 원본 개체를 복제하는 방법으로 객체를 생성하는 패턴
- 싱글톤 - 하나의 객체를 생성하면 생성된 객체를 어디서든 참조할 수 있지만, 여러 프로세스가 동시에 참조할 수는 없는 패턴
- 구조 패턴
- 구조가 복잡한 시스템을 개발하기 쉽도록 클래스나 객체들을 조합하여 더 큰 구조로 만드는 패턴
- 어댑터 - 호환성이 없는 클래스들의 인터페이스를 다른 클래스가 이용할 수 있도록 변환해주는 패턴
- 브리지 - 구현부에서 추상층을 분리하여, 서로가 독립적으로 확장할 수 있도록 구성한 패턴
- 컴포지트 - 여러 객체를 가진 복합 객체와 단일 객체를 구분 없이 다루고자 할 때 사용하는 패턴
- 데코레이터 - 객체 간의 결합을 통해 능동적으로 기능들을 확장할 수 있는 패턴
- 퍼싸드 - 복잡한 서브 클래스들을 피해 더 상위에 인터페이스를 구성함으로써 서브 클래스들의 기능을 간편하게 사용할 수 있도록 하는 패턴
- 플라이웨이트 - 인스턴스가 필요할 때마다 매번 생성하는 것이 아니고 가능한 한 공유해서 사용함으로써 메모리를 절약하는 패턴
- 프록시 - 접근이 어려운 객체와 여기에 연결하려는 객체 사이에서 인터페이스 역할을 수행하는 패턴
- 행위 패턴
- 클래스나 객체들이 서로 상호작용하는 방법이나 책임 분배 방법을 정의하는 패턴
- 책임 연쇄 - 요청을 처리할 수 있는 객체가 둘 이상 존재하여 한 객체가 처리하지 못하면 다음 객체로 넘어가는 형태의 패턴
- 커맨드 - 요청을 객체의 형태로 캡슐화하여 재이용하거나 취소할 수 있도록 요청에 필요한 정보를 저장하거나 로그에 남기는 패턴
- 인터프리터 - 언어에 문법 표현을 정의하는 패턴
- 반복자 - 자료 구조와 같이 접근이 잦은 객체에 대해 동일한 인터페이스를 사용하도록 하는 패턴
- 중재자 - 수많은 객체들 간의 복잡한 상호작용을 캡슐화하여 객체로 정의하는 패턴
- 메멘토 - 특정 시점에서의 객체 내부 상태를 객체화함으로써 이후 요청에 따라 객체를 해당 시점의 상태로 돌릴 수 있는 기능을 제공하는 패턴
- 옵서버 - 한 객체의 상태가 변화하면 객체에 상속되어 있는 다른 객체들에게 변화된 상태를 전달하는 패턴
- 상태 - 객체의 상태에 따라 동일한 동작을 다르게 처리해야 할 때 사용하는 패턴
- 전략 - 동일한 계열의 알고리즘들을 개별적으로 캡슐화하여 상호 교환할 수 있게 정의하는 패턴
- 템플릿 메소드 - 상위 클래스에서 골격을 정의하고, 하위 클래스에서 세부 처리를 구체화하는 구조의 패턴
- 방문자 - 각 클래스들의 데이터 구조에서 처리 기능을 분리하여 별도의 클래스로 구성하는 패턴
- 서버 개발 프레임워크
- 서버 프로그램 개발 시 다양한 네트워크 설정, 요청 및 응답 처리, 아키텍처 모델 구현 등을 손쉽게 처리할 수 있도록 클래스나 인터페이스를 제공하는 소프트웨어
- 대부분 모델-뷰-컨트롤러 패턴을 기반으로 개발됨
- 서버 개발 프레임워크 종류 - Spring, Node.js, Django, Codeigniter, Ruby on Rails 등
- 서버 개발 프레임워크의 종류
- Spring - JAVA를 기반으로 만든 프레임워크, 전자정부 표준 프레임워크의 기반 기술로 사용됨
- Node.js - JavaScript를 기반으로 만든 프레임웤, 비동기 입.출력 처리와 이벤트 위주의 높은 처리 성능, 실시간 입.출력이 빈번한 애플리케이션에 적합함
- Django - Python을 기반으로 만든 프레임워크, 컴포넌트의 재사용과 플러그인화를 강조, 신속한 개발이 가능하도록 지원함.
- Codeigniter - PHP를 기반으로 만든 프레임워크, 인터페이스가 간편하며 서버 자원을 적게 사용함
- Ruby on Rails - Ruby를 기반으로 만든 프레임워크, 테스트를 위한 웹 서버를 지원, 데이터베이스 작업을 단순화, 자동화 시켜 개발 코드의 길이가 짧아지게함으로 신속한 개발 가능함
- 서버 개발 과정
- DTO/VO 구현 - 데이터 교환을 위해 사용할 객체를 만드는 과정
- SQL 구현 - 데이터의 삽입, 변경, 삭제 등의 작업을 수행할 SQL문을 생성하는 과정
- DAO 구현 - 데이터베이스에 접근하고, SQL을 활용하여 데이터를 실제로 조작하는 코드를 구현하는 과정
- Service 구현 - 사용자의 요청에 응답하기 위한 로직을 구현하는 과정
- Controller 구현 - 사용자의 요청에 적절한 서비스를 호출하여, 그 결과를 사용자에게 반환하는 코드를 구현하는 과정
- API
- 응용 프로그램 개발 시 운영체제나 프로그래밍 언어 등에 있는 라이브러리를 이용할 수 있도록 규칙 등을 정의해 놓은 인터페이스
- 누구나 무료로 사용할 수 있게 공개된 API를 Open API 라고함
- 배치 프로그램
- 사용자와의 상호 작용 없이 여러 작업들을 미리 정해진 일련의 순서에 따라 일괄적으로 처리하도록 만든 프로그램
- 배치 프로그램의 필수 요소
- 대용량 데이터 - 대량의 데이터를 가져오거나, 전달하거나, 계산하는 등의 처리가 가능해야 함
- 자동화 - 심각한 오류가 발생하는 상황을 제외하고는 사용자의 개입 없이 수행되어야 함
- 견고성 - 잘못된 데이터나 데이터 중복 등의 상황으로 중단되는 일 없이
- 안정성/신뢰성 - 오류가 발생하면 오류의 발생 위치, 시간 등을 추적할 수 있어야 함
- 성능 - 다른 응용 프로그램의 수행을 방해하지 않아야 함, 지정된 시간 내에 처리가 완료되어야 함
- 배치 스케줄러
- 일괄 처리 작업이 설정된 주기에 맞춰 자동으로 수행되도록 지원해주는 도구
- 스프링 배치 - Spring Source 사와 Accenture 사가 2007년 공동 개발한 오픈 소스 프레임워크, 로그 관리, 추적, 트랜잭션 관리, 작업 처리 통계, 작업 재시작 등의 다양한 기능 제공
- Quartz - 스프링 프레임워크로 개발되는 응용프로그램들의 일괄 처리를 위한 다양한 기능을 제공하는 오픈 소스 라이브러리, 수행할 작업과 수행 시간을 관리하는 요소들을 분리하여 일괄 처리 작업에 유연성을 제공
- Cron - 리눅스의 기본 스케줄러 도구, crontab 명령어를 통해 작업을 예약할 수 있음
- crontab 명령어 작성 방법
댓글남기기