Welcome to gwimong's Blog!
안녕하세요. 귀몽이의 개인 블로그입니다.-
소프트웨어 공학 기본 #2
소프트웨어 개발방법론
(SDM; Software Development Methodology) :
소프트웨어를 개발하는 방법에 대한 이론으로서, 소프트웨어 개발 과정, 절차, 방법, 산출물, 기법, 도구들을 체계적으로 정리하고 표준화시킨 것입니다.
구조적 방법론
(Structured Development) :
전체 시스템을 정형화된 분석 절차에 따라 요구사항을 파악하여 문서화 하고, 이를 기반으로 소트프웨어를 개발하는 방법론 입니다.
- 요구 사항 분석 : 고객이 원하는 요구사항을 끌어내어 명세화합니다.
- 구조적 분석 : 고객이 원하는 기능과 시스템 환경, 데이터를 종합하여 DFD(Data Flow Diagram)을 작성하고, 이를 통해 기능을 분해하여 기능별 소단위 명세( mini-Specification)를 작성합니다.
- 구조적 설계 : 모듈 중심으로 소프트웨어를 설계합니다.
- 구조적 프로그래밍 : 설계를 기반으로 소프트웨어를 개발합니다.
“거시적 관점”이 부족하다는 한계가 있음
정보공학 개발 방법론
(Information Engineering Development) :
비즈니스 시스템 규모 성장과 소프트웨어 공학 발전에 따라 1980년대 중반에 등장한 방법론으로
기업 전체, 또는 기업의 주요 부분을 계획, 분석, 설계 및 구축에 정형화 된 기법들을 상호 연관성 있게 통합, 적용하는 데이터 중심 방법론 입니다.
- 정보 전략 계획(ISP) : 업무프로세스와 시스템을 분석하고 미래 아키텍처와 전략계획을 수립합니다.
- 업무 영역 분석(BAA) : 업무 현황을 분석하여 개념 수준의 데이터와 프로세스를 설계합니다.
- 업무 시스템 설계(BSD) : 실질적으로 시스템을 설계하는 단계로 다양한 다이어그램을 사용하여 프로세스를 설계합니다.
- 시스템 구축(SC) : 설계 명세서로부터 데이터베이스를 상세 설계하고 실행 가능한 프로그램 코드를 생성합니다.
“경직된 구조”로 이전 단계의 변화에 대응하기 어려움
객체 지향 개발 방법론
(Object-Oriented Development) : 현실 세계의 개체(Entity)를 속성(Attribute)과 메소드(Method)가 결합된 형태의 객체(Object) 로 표현하며,
이 객체들이 메시지 교환을 통해 상호 작용함으로써 전체 시스템이 운영되도록 개발하는 방법론입니다.
- 개념화 : 요구 사항을 분석하여 정의합니다.
- 상세화 : 문제 영역(Problem Domaion)을 분석하고 견고한 아키텍처 토대를 마련합니다.
- 구축 : 사용자들에게 전이할 수 있도록 반복 및 점증적으로 제품을 완전히 개발합니다.
- 전이 : 소트프웨어를 사용자에게 전달합니다.
개발 수준이 저 수준의 추상화 개념이므로 실제로 재사용 가능한 소프트웨어 개발은 기대하기 어려움
컴포넌트 기반 개발 방법론
(Component Based Development) :
컴포넌트를 조립하여 시스템을 개발 하여 객체지향의 단점인 S/W 재사용성을 극대화한 개발 방법론입니다.
- 분석 : 사용자의 요구 사항을 수집하고 이를 정의합니다.
- 설계 : 소프트웨어의 아키텍처를 정의하고 이를 구성하는 콤포넌트와 데이터베이스 등을 설계합니다.
- 구현 : 개발 표준을 정의하고 이에 맞춰 코드를 구현합니다.
- 테스트 : 요구 사항이 모두 반영되었는지 테스트하고 이에 대한 결과를 보고합니다.
애자일 개발 방법론
(Agile Software Development) :
기존 개발 방법론들이 너무 절차를 중시한 나머지 변화에 대응하기 어려웠던 단점을 개선하기 나왔습니다.미래를 예측하기 보다는 주기적으로 제작 프로토타입을 시험해보는 철저한 관리를 통한 개발 방법론이라 할 수 있으며
끊임없이 개발하고 수정하는 일을 반복하면서 고객이 가장 만족할 수 있는 방향으로 소프트웨어를 개발합니다.
- 먼저 개발 범위 안에 있는 요구 사항을 분석해 우선 순위가 높은 요구 사항을 먼저 개발합니다.
- 개발 된 부분에 대해 실행하는 모습을 고객에게 보여주고 이에 대한 피드백을 받습니다.
- 고객의 요구 사항과 개선 사항을 반영하여 다음 요구 사항을 개발합니다.
- 1-3을 반복합니다.
테스트 기반 개발 방법론
(Test Driven Development) :
전통적인 개발 방법론에서의 구현 후 테스트를 수행하는 단계와는 반대로 테스트를 먼저 수행하고, 소프트웨어를 구현하는 개발 방법론입니다.
- 테스트 케이스 작성 : 요구 사항을 만족하기 위한 테스트 케이스를 작성합니다.
- 실제 코드 구현 : 테스트 케이스를 통과하기 위한 최소한의 코드를 구현합니다.
- 리팩토링 : 작성한 코드를 표준에 맞도록 리팩토링 합니다.
- 모든 요구 사항을 만족하는 테스트 케이스를 통과 할 때까지 1-3을 반복합니다.
행위 기반 개발 방법론
(Behaviour Driven Development) :
TDD에서 파생된 개발 방법론으로, 사용자의 행위를 정의하고 이에 대한 테스트 코드를 작성하면서 소프트웨어를 개발하는 방법입니다.
-
소프트웨어 공학 기본 #1
소프트웨어 개발 수명 주기
(Software Development Life Cycle, SDLC)
시스템 엔지니어링, 정보 시스템, 또는 소프트웨어 공학에서 정보 시스템을 계획, 개발, 시험, 채용하는 과정을 뜻하는 용어입니다.
대게 요구사항 분석→설계→개발→테스트→운영 단계로 구성되어 있습니다.요구 사항 분석
- 요구 사항을 수집하고 제품의 요구와 조건을 결정
- 소프트웨어의 기능과 제약 조건 등을 명확히 정의
설계
- 정의한 기능을 실제 수행할 수 있도록 수행 방법을 논리적으로 결정
- 시스템 구조 설계/ 프로그램 설계 / 사용자 인터페이스 설계 / 데이터베이스 설계 등
구현
- 설계 단계에서 논리적으로 결정한 문제 해결 방법을 특정 프로그래밍 언어를 사용하여 구현
- 인터페이스 / 자료 구조 / 오류 및 예외 처리 등
테스트
- 시스템이 요구을 모두 만족하는지 검사하고 평가하는 단계
- 단위 테스트 / 통합 테스트 / 시스템 테스트 / 인수 테스트 등
유지 보수
- 시스템이 인수된 이 후 일어나는 모든 활동
소프트웨어 생명 주기 모델
폭포수 모델 (Waterfall Model)
- 가장 오래 된 모델
- 순차적으로 각 단계를 완료 후, 다음 단계로 넘어가는 모델
- 단계별 정의와 산출물이 명확하나, 요구 사항 변경이 어려움
프로토타이핑 모델 (Prototyping Model)
- 주요 기능을 프로토타입으로 구현하고, 이에 대한 고객의 피드백을 반영하여 소프트웨어를 개발
- 요구분석이 쉽고 타당성 검증이 가능하나 프로토타입 개발에 따른 비용 증가
나선형 모델(Spiral Model)
- 점진적으로 완벽한 시스템을 개발해 나가는 모델
- 위험성 감소와 변경에 유연한 대처가 가능하나, 단계 반복에 따른 추가 비용과 관리가 어려움
반복적 모델(Iteration Model)
- 병렬적으로 개발 후 통합하거나, 반복적으로 개발하여 점증 완성시키는 모델
- 사용자의 요구사항 일부분 혹은 제품 일부분을 반복적으로 개발하여 최종 시스템으로 완성하는 모델
- 병행 개발로 인한 일정 단축이 가능하나, 관리 비용이 증가
-
Database 이해하기 #2
DB Lock
DBMS마다 Lock를 구현하는 방식과 세부 적용 방법은 다르지만,
데이터의 접근을 제한함으로써 일관성을 보장하기 위한 방법으로 기본적인 개념은 유사합니다.Lock 종류
DB Lock은 적용 대상과 상황에 따라 분류할 수 있습니다.
적용 대상에 따른 분류
- Row lock : 변경하려는 row에 대해 lock을 설정
- Record lock : index record에 대한 lock을 설정
- Gap lock : index record의 gap에 대한 lock 설정(gap은 index 중 실제 record가 없는 부분)
- Table lock : Table과 index에 모드 lock을 설정
- Database lock : 데이터베이스를 복구하거나 스키마를 변경할 때 설정
적용 상황에 따른 분류
- Shared Lock : 원하는 데이터에 lock을 걸었지만, 다른 세션에서 읽을 수 있습니다. 보통 데이터를 읽을 때 사용합니다.
- Exclusive Lock : 데이터에 lock을 걸면, 다른 세션에서 읽거나 변경 할 수 없습니다. 보통 데이터를 변경 할 때 사용합니다.
- Intention Lock : 요청한 범위에 대한 lock를 수행 할 수 있는지 빠르게 확인하기 위해 사용됩니다.
(예를 들어, Transaction A가 하나의 Row에 Exclusive lock을 걸어 놓은 상태에서 Transaction B가 해당 테이블 전체에 대한 lock을 걸기 위해선 모든 테이블 Row에 대한 lock 유무를 확인해야 합니다. 이 때, Transaction A가Intention Lock 테이블에 걸어두면 Transaction B는 좀 더 빠르게 Lock 적용 유무를 확인 할 수 있습니다.)
Blocking
Transaction 간의 lock 경합이 발생하여, 작업이 진행되지 않고 멈춰선 상태를 말합니다.
Shared Lock 간에는 발생하지 않지만, Exclusive Lock에선 경합을 하여 우선 순위에 따라 Transaction이 수행됩니다.이렇게 Blocking 된 Transaction은 lock이 해제 될 때까지 대기하게 되며, 이는 성능에 좋지 않는 영향을 미칩니다.
경합을 최소화하기 위해선 아래의 사항을 준수합니다.- Transaction은 길지 않게 작성합니다.
- 동일한 데이터를 갱신하는 Transaction은 동시에 수행되지 않도록 설계합니다.
- Transaction 격리 수준을 불필요하게 상향 조정하지 않습니다
- 한번에 수행되는 작업 단위(쿼리)를 너무 무겁게 작성하지 않습니다.
Dead Lock
Dead lock(교착 상태)은 두 개 이상의 작업이 서로 상대방의 작업이 끝나길 기다리고 있기 때문에, 결과적으로 아무것도 완료되지 못하는 상태를 말합니다.
Database에서 dead lock은 서로 다른 Transaction 간의 교착 상태를 의미합니다.해결 방법
- 예방 기법 : Dead Lock이 발생하지 않도록 미리 예방하는 방법입니다.
- Transaction이 실행되기 전에 필요한 모든 자원을 Lock 한다.
- 일정 시간이 지나면 쿼리가 취소도록 설정한다.
- 회피 기법 : 자원을 할당할 때 Time Stamp를 활용하여 Dead lock이 발생하지 않도록 회픠하는 방법입니다.
- Wait-Die 방식 : 먼저 들어온 Transaction은 대기(Wait)하고 나중에 들어온 Transaction은 포기(Die)하고 나중에 다시 요청한다.
- Wound-Wait 방식 : 먼저 들어온 Transaction은 데이터를 선점(Wound)하고, 나중에 들어온 Transaction은 대기(Wait)한다.
- 낙관적 병행 제어 기법 : Transaction이 커밋을 수행할 때, 데이터에 문제가 있다면 Roll-back 하는 방법입니다.
- 빈도 줄이기 기법 : Dead lock 발생 확률을 줄이는 방법입니다.
- Transaction 진행 방향을 같은 방향으로 처리
- Trahsaction 처리 속도를 최소화
- Lock 해제 시간을 조절
확인 방법
DBMS마다 Dead Lock을 관리하는 방법이 상이합니다.
MySQL-innodb 기준으로 아래의 쿼리를 통해 확인 할 수 있습니다.mysql> show engine innodb status위 쿼리를 수행하면 현재 innodb의 상태 정보를 표출되며, 최근 발생한 Dead lock 정보를 확인 할 수 있습니다.
만약 모든 deadlock에 대해 확인 하고 싶은 경우, 아래의 설정을 변경합니다.
[my.cnf][mysqld] innodb_print_all_deadlocks = 1또는
mysql> SET GLOBAL innodb_print_all_deadlocks = 1;
-
Database 이해하기 #1
DB Transaction
DB Transaction은 DBMS 또는 이와 유사한 시스템에서 사용되는 상호 작용의 단위입니다.
즉, 시스템을 변환시키는 하나의 논리적 기능을 수행하기 위한 작업의 단위로, 한번에 모두 수행되어야 할 일련의 연산들을 의미합니다.Transaction의 성질
ACID(원자성, 일관성, 고립성, 지속성)는 데이터베이스 Transaction이 안전하게 수행된다는 것을 보장하기 위한 성질을 가리키는 약어입니다.
- Atomicity(원자성) : 데이터베이스에 모두 반영이 되던지, 전혀 반영되지 않던지 해야 한다.
- Consistency(일관성) : 수행 전과 완료 후의 시스템의 상태가 같아야 한다.
- Isolation(독립성) : Transaction는 각각 독립적으로 수행되며, 다른 연산에 영향을 끼칠 수 없다.
- Durability(영구성) : 연산이 정상적으로 완료된 이후에는 영구적으로 반영이 되어야 한다.
Transaction 연산
Transaction은 시스템에 적용하기 위한 연산으로 Commit와 Rollback이 있습니다.
- Commit : Transaction의 모든 작업이 성공적으로 완료 된 것을 Transaction 관리자에 알려주는 연산
- Rollback : Transaction의 작업 중 일부가 비정상적으로 종료되어 데이터베이스의 일관성을 깨뜨렸을 때, 해당 Transaction이 행한 모든 작업을 취소( Undo)하는 연산
Transaction 상태
- Active(활동) : Transaction이 실행 중인 상태
- Failed(실패) : Transaction 실행 중 오류가 발생하여 중단된 상태
- Aborted(철회) : Transaction이 비정상적으로 종료되어 Roolback 연산을 요청한 상태
- Partially Committed) : Transaction 연산이 정상적으로 수행되었으며 Commit 연산을 요청하기 전 상태
- Committed(완료) : Transaction의 모든 작업이 정상적으로 수행되어, Commit 연산을 실행한 상태
Isolation Level
Transaction의 ACID를 엄격하게 준수하면, 데이터의 적합성은 보장 할 수 있지만 동시성 효율은 매우 떨어지게 됩니다.
이러한 Trade-off 관계에서 데이터베이스는 서로 다른 Transaction이 어느 정도 허용이 가능하도록 격리 수준을 지원합니다.
(Level 수준이 높을 수록 엄격한 격리 수준을 제공)Name Level Dirty Read Non-Repeatable Read Phantom Read 정합성 동싱성 Serializable 3 X X X 높다 낮다 Repeatable Read 2 X X O 중간 중간 Read Committed 1 X O O 중간 중간 Read Uncommitted 0 O O O 낮다 높다 - Dirty Read : 다른 Transaction에 의해 수정되었지만, 아직 커밋되지 않은 데이터를 읽어 발생하는 오류
- Non-Repeatable Read : Transaction에서 같은 데이터를 여러번 조회 할 때, 조회 결과가 상이한 현상(다른 Transaction에서 데이터를 수정함)
- Phantom Read : 한 Transaction에서 일점 범위의 레코드를 처음 조회 할땐 없던 유령 레코드가 그 다음 조회 시에 나타나는 현상
Serializable
Transaction이 사용 중인 테이블의 모든 Row에 대한 접근을 제한합니다.
이 격리 수준에서는 단순한 Select 쿼리가 실행되더라도, 다른 Transaction이 데이터에 접근 할 수 없습니다.
가장 높은 데이터 접합성을 보장하지만, 그만큼 성능은 가장 느립니다.Repeatable Read
Transaction이 Active 될 때 수행한 시간을 기록하고, 해당 시점을 기준으로 consistent read를 수행합니다.
하지만 새로운 Row가 추가 되는 것을 막지는 않습니다.* consistent read : Read operation을 수행 할 때, 현재 DB의 값이 아닌 특정 시점의 snapshot을 읽어 오는 것
Read Committed
Transaction은 읽기 연산 마다 DB Snapshot를 생성합니다. 이로 인해, 커밋이 완료된 다른 Transaction의 변경 사항은 consistent read 시 반영됩니다.
대부분의 DBMS가 기본 모드로 채택하고 있는 격리 수준입니다.Read Uncommitted
커밋이 되지 않은 데이터 변경을 다른 Transaction이 조회 가능하도록 허용하는 격리 수준입니다.
데이터 부정합 문제가 발생할 확률은 높아지지만, 그만큼 성능은 가장 빠릅니다.
-
Cloud not reserve enough space for object heap
장애 현상
Spring boot project를 내장 톰캣으로 실행시킬 때 아래의 오류가 발생함.
Error occurred during initialization of VM
Could not reserve enough space for 2097152KB object heap해결 과정
해당 오류는 프로젝트 실행 시 heap 메모리가 부족하다는 오류입니다.
- Intellij의 heap 메모리 설정
Help > Change Memory Settings
- Java VM 옵션 추가
-Xms1024m -Xmx2048m
- JDK 변경
JDK 1.8(64bit)를 추가로 설치하고, 실행 시 해당 JDK로 실행되도록 변경
원인 분석
The maximum theoretical heap limit for the 32-bit JVM is 4G.
Due to various additional constraints such as available swap, kernel address space usage, memory fragmentation, and VM overhead, in practice the limit can be much lower.
On most modern 32-bit Windows systems the maximum heap size will range from 1.4G to 1.6G. On 32-bit Solaris kernels the address space is limited to 2G. On 64-bit operating systems running the 32-bit VM, the max heap size can be higher, approaching 4G on many Solaris systems.32bit JVM은 이론상 최대 4GB의 메모리를 사용 할 수 있지만, Windows 환경에선 2GB로 제한됩니다. 이로 인해 2GB 이상의 프로젝트를 실행 할때 해당 오류가 발생 한 것입니다.
- Intellij의 heap 메모리 설정
-
HTTP Cookie의 Security
Http Cookie
HTTP Cookie는 서버에 의해 브라우저에 저장되는 데이터 조각입니다.
Cookie는 2개의 유형으로 나뉩니다.- persistent cookies : 만료일을 가지는 cookie로, 사용자 경험을 저장하기 위해 주로 사용
- session cookies : 세션 종료와 함께 삭제되는 cookie로, 자격 증명 등을 저장하기 위해 주로 사용
Session과 Cookie
Http는 connectionless & Stateless(무상태성, 상태 정보를 가지 않는) 프로토콜입니다.
서버는 요청한 클라이언트의 상태 정보를 알 수 없기 때문에, 매번 인증 절차를 수행해야 합니다.
- Client A는 Server로 사용자 정보를 전송하여 인증 절차를 수행합니다.
- Server는 Client A의 대한 Session을 생성하여 Set-Cookie에 담아 Client에 전송합니다.
- 이 후, Client A는 Server로 요청 시, 세션 정보를 cookie에 담아 함께 전송합니다.
- Server는 Session cookie를 해석하여 Client A라는 것을 확인하고, 요청을 처리합니다.