지난 '2010년 한국 소프트웨어 아키텍트 대회'를 참가한 이후 2년만에 다시 대회를 찾았다.
오늘은 아무런 준비없이 휴가를 쓴 날이었다. 그런데 휴가를 내고보니, 이 날에 아키텍트 대회가 있다는 이야기가 들려왔다. 아는 분에게 부탁드려서 무료참관 신청을 하고 수요일 아침 코엑스를 향했다. 코엑스에는 평일 이른 시간이었음에도 출근하는 직장은 외에도 많은 사람들이 있었다. 아직 우리나라에는 아키텍트 역할이 제대로 인정받고 있지 못하다. 그런 힘든 상황 속에서도 SW 아키텍트로서 다양한 경험을 공유하려고 하는 이런 대회는 참 좋다.
Architect!
Your Role, Our Future.
IT쪽에서 크게 관심을 기울이고 있는 몇가지가 있다.
* 생산성(여기서는 생산성보다는 관리적인 측면이 강하다)
* 프로젝트에서 발생하는 위험(리스크)을 줄이고
* 프로젝트를 관리하기 유용한 형태로 가고 있다.
* 빅데이터
* 클라우드 컴퓨팅
* 모바일 서비스
| |
1. 통합된 개발환경 기반 어프리케이션 관리체계
|
|
- 발표자 : 삼성SDS 김영신 수석보
- 통합된 개발환경은 소프트웨어 개발 라이프사이클 전체를 지원하는 툴과 가이드를 통합하여 개발관리를 Seamless하게 할 수 있는 개발환경
- 개발 라이프사이클 : 분석 -> 설계 -> 개발 -=–0 운영관리
- 개발산출물
- 개발자가 생산한 개발산출물에 대한 시스템 검증없이 구두 또는 테스트의 결과를 중심으로 공정, 진척, 품질관리ㅡㄹㄹ 수행
- 관련자 : 개발자(납기), 고객(진척률, 이슈/위험), PM/PL(진척률, 결함, 이슈/위험, 공수), 아키텍트/품질담당
- 개발자의 머리에 손을 얹고 ‘나는 너를 믿는다’ 라…
- 아키텍처 구성방안
- 개발환경은 복잡해짐
- 단순한 툴 조합만으로는 개발생산성이 나지 않음
- 개발생산성을 극대화 하려면 실행환경 구조, 개발환경, 관리환경을 Set화 하여 구성
- 코딩 산출물(프로그램 소스코드)
- 실행환경 구조(실행환경 구조, Runtime architecture)
- 개발환경(IDE/형상관리/빌드/코드품질(PMD)/테스트/이관)
- 관리환경(진척/결함/이슈 관리)
- 아키텍트는 프로젝트에서 사용하는 다양한 솔루션들을 조합하여 개발에 최적화된 환경을 제공할 수 있도록 해야한다.
- 관리툴이 연계가 잘 되어 있을 경우 시스템 오류가 생겼을 경우, 이것을 해결할 수 있는 손쉬운 방법들이 생겨난다.
- 실행환경 구조를 얼마나 잘 잡았느냐에 따라서 손쉬워진다.
- 실행환경 구조
- 개발환경
- 관리환경
- 위의 세가지를 하나로 엮는다(발표자는 ’set화’라고 지칭 ).
- 개발환경 set화
- Set화된 개발환경이란 공공, 금융 등 프로젝트에 동일하게 활용하는 실행, 개발, 관리환경의 툴, 가이드, 설정을 포함하여 설치 및 커스터마이징을 최소화한 개발환경 패키지이며 상호호환 가능
- 프로젝트의 성격에 따라서 필요한 솔루션들을 종합하는 작업이 필요하다.
- 구성방안
- 개발단계시 활용하는 Runtime, 개발자동화툴, 형상관리툴, 빌드툴, 인스펙션툴, 테스트툴, 운영이관 및 실물기반 관리기능이 연계되어 개발산출물 전체의 라이프 사이클을 통제, 관리하도록 구성
- 개발환경에 맞춰서 최적화 하는 것이 중요하군.
- 어플리케이션 실행환경 구성
- Broker, Controller
- TimeStamp
- Application Error
- Regression Test
- Test Pass rate
- Application Monitoring
- Dao
- 좋은부모 인생시스템이라…
- 애플리케이션 개발환경 구성
- 검수자(개발서버)
- 개발자(개발PC)
- 관리자(관리서버)
- 아키텍트, 테스터 운영자(관리서버)
- 현재 회사에서는 이와 같은 개발환경을 구축하과 관리할 수 있는 능력을 가진 사람이 없다. 그게 좀 큰 약점으로 적용된다.
- 개발자가 작성한 코드가 주석인지 실제로 동작하는 코드인지 관찰한다라…
- 실물기반 진척관리를 위한 관리체계 구성 예시
- 서버환경
- 개발툴
- 개발IDE툴 -> 형상관리툴 -> 빌드툴 -> 인스펙션툴 -> 테스트툴 -> 이관툴
- 실물자동 점검툴과 연계한 관리환경
- 진척관리 절차
- 적용사례
- OO기관 구축 사업에 통합된 개발환경 기반 관리체계를 적용하여 소스코드 자동화율 증대, 구축 시간 단축, 실시간 실물기반 관리로 관리효율을 높였음
- 관리효율을 높이는 것에 중점을 두고 있는 것인가?
- 개발자가 많고, 생산되는 소스코드가 많을수록 통제하는 것이 좋다는 경험담
- 그렇게했을 때 ’아키텍트’가 관리하기가 좋다.
- LOC(코드라인수) 이 감소하는 효과가 있었다.
- 개발환경을 통제하는 것이 개발효율을 높일 수 있다…로 정리될까
- 아키텍트가 ’좋은 구조’를 잡아준다면 개발자들에게서도 호응을 얻을 수 있게 된다.
- 실물자동점검을 위한 판정 기준
- ‘좋은부모 시스템’
- 개발환경의 통합
이 발표는 주로 아키텍트의 '관리'에 특면에서 많은 내용이 발표되었다. 아키텍트는 '개발자'의 '최종진화'판이라고 생각한다. 프로젝트 내에서 발생하는 소프트웨어적으로 어려운 난제들을 해결하는 것을 주업으로 하는 '해결사'라고 생각해왔다. 그런데 국내 아키텍트들의 활동을 가만히 살펴보면 '관리자'의 역할이 더 강렬하게 수행하게 되는 것으로 보인다.
| |
2. Mobile-centric HTML5 어플리케이션 개발 및 아키텍처
|
|
| |
3. No-SQL DB를 활용한 대용량 LOG 분석 및 아키텍처
|
|
발표자 : 삼성SDS 엄재형 책임
anyframe-logmanager-pi.1.0.1
Bic Data 는 상대적임
NoSQL 은 ‘상대적으로’ 저렴한 비용으로 이러한 대용량 데이터를 처리하기 위해 고안된 Database의 일종
- 로그데이터 처리를 위해서 NoSQL을 고려해야하는 이유
- NoSQL 종류
- MongoDB
- 다른 NoSQL Database 에서 제공하지 않는 기능들을 제공
- CouchDB
- Cassandra
- HBase
- MongoDB
- MongoDB 는 10gen 에서 개발한 NoSQL DB 제품의 한종류(Humongous)
- APGL 3.0 라이센스 사용
- 대형 업체에서 서비스하려고 하는 경우 제약사항이 발생
- MongoDB is Fantastic for Logging
- 입력이 비동기식으로 동작
- 오래된 로그 데이터는 자동으로 LRU’s out : 과거데이터가 삭제된다.
- Document-oriented(XML 과 같이 구조화 되어 있어서 문서자체를 저장하는 방식) / JSON 은 로그 정보를 위한 훌륭한 구조야?
- Log4mongo
- 로그 수집시 고려사항
- 로그 수집
- 직접 수집 : log4.xml -> append 처리
- 배치 수집
- 로그의 저장(=mongoDB 의 구성)
- 정책의 관리
- 로그 레벨의 (동적) 변경
- (동적) Appender 추가
- 변경사항의 중단없는 반영
- 로그정책의 통합관리(분산되어 있는 로그시스템의 통일)
- 데이터의 검색
- matched 검색
- range 검색
- 순차검색
- 검색항목
- 어떻게 보여줄 것인가?
- Enterprise Environment 대용량 환경에 적용할 때 고려할 사항
- Idea~
- 고려사항을 해결하기 위한 오픈소스 해결방법 ->
- Issue -> Open Source Technology -> Log Manager Feature
- 로그 수집
- 직접 수집 : log4.xml -> append 처리 : log4mongo
- 배치 수집 : osgi / apache felix
- 로그의 저장(=mongoDB 의 구성)
- 정책의 관리
- 로그 레벨의 (동적) 변경
- (동적) Appender 추가
- 변경사항의 중단없는 반영
- 로그정책의 통합관리(분산되어 있는 로그시스템의 통일)
- hessian, servletfilter, log4j api
- 데이터의 검색
- matched 검색
- range 검색
- 순차검색
- 검색항목
- 어떻게 보여줄 것인가?
- Enterprise Environment 대용량 환경에 적용할 때 고려할 사항
- 해결방안 : LogManager
- Apache 라이센스를 사용하는 오픈소스 로그관리도구
- MongoDB를 Log Repository로 활용
- OSGI 기반의 Agent Service 제공
- Jetty 기반의 웹관리모듈 제공(별도의 WAS 불필요)
- jQuery 기반으로 Ajax Web UI
- 다양한 검색옵션 제공
- 간단한 사용자 관리 기능으로 로그 접근권한 분리
- LogManager Senario
- Anyframe 쪽에서 확인 가능
- Log Agent Service
- OSGi - Apach felix
- Log Agent 관리
- Log Application 관리
- 계정 관리
- Technology Stack
- 기술적 종속관계를 통해 확인
- 대부분 Java를 기반으로 구성되어 있다.
- 오픈소스 라이선스의 로그관리 도구
- 로그를 빅데이터 관점에서 접근하여 NoSQL 제품과 접목한 오픈소스 형태의 로그 관리도구
- 자체로서 완결된 서비스를 제공하기 보다는 현장에서 보다 쉽게 응용하여 사용할 수 있도록 편의를 제공하는 것이 목적
- 발전방향
- 로그 프레임워크의 범위 확장 :Log back
- NoSQL DB 추가 : 인터페이스표준화
- 성능 최적화
- 기능 최적화
- 분석도구 제공
프로젝트 : http://www.anyframejava.org/project/logmanager
JIRA : http://dev.anyframejava.org/jira
- 개인의견
- UI 에서 Agent를 관리하는 기술이 참 부럽군.
- 저장된 로그를 필터링하여 관리하는 부분은 LogManager 사용자의 영역이로구나.
- 우리 회사에서도 고려하고 있는 사항인데, 중요한 것은 이렇게 기록된 정보를 어떻게 가공하느냐…
- 결국 빅데이터는… 그 방대한 데이터를 ‘어떻게 사용하느냐?’ 라는 사용방식의 차이가 그 효율성을 결정짓게 되는 것이다.
| |
4. 프로젝트 유형별 어플리케이션 플랫폼 구축 전략
|
|
- 발표자 : 삼성SDS 백창현 수석
- 프로젝트의 특징에 대한 명확한 분석이 필요하다는 거지.
- SI 프로젝트 기반 시스템 개발
- Eclipse 기반
- 배치 스케줄러 개발
- 배치 스케줄러 시스템
- 배치 스케줄러 구성요소
- Schedule Admin
- Schedule Agent
- Hadoop Zookeeper
- 일정을 어떻게 관리할 것인가
- 요구사항을 정확하게 분석해야한다.
- 설계 요소
- 작업 일정과 개별 실행 작업 인스턴스의 관리
- 쉽고 간편한 웹기반의 UI
- 멀티 에이전트 관리
- 스케줄러 어드민 이중화
- 웹크롤링 스케줄러 에이전트를 다시 만들어볼까나.
- Smart GWT
- 프로젝트 성격
- 개발목표
- 개발형태
- 요구사항 명확도
- 도입기술
- 기술적 난이도
- 비용확정
- 핵심이슈
- 리스크
- 아키텍트 역할
- 프로젝트 기간
- 프로젝트의 핵심요소들을 파악하여 어떻게 할 것인지 확인
- 프로젝트 유형별 어플리케이션 플랫폼 구축전략
- 프로젝트 성격 분석
- 개발목표
- 개발형태
- 요구사항 명확도
- 도입기술
- 기술적 난이도
- 비용확정
- 핵심이슈
- 리스크
- 아키텍트 역할
- 고가용성 구조 정의, 핵심클래스 데이터 모델 정의
- 프로젝트 기간
- 유형별 비교
- 금융 SI 시스템 개발
- 금융시스템 개발의 소프트웨어 아키텍처 및 기술 기반 구축
- 프레임워크 도입 후 커스터마이징
- 매우 명확함
- 높음(표준, 규격)
- 프로젝트 구축일정에 따라 M/M 투입
- 시각적 로직 명세 툴 개발
- SI 개발 지원을 위한 프로그램 상세 설계/명세 툴 개발
- 제품 기획 후 아웃소싱 발주 수행
- 불명확
- 배치 스케줄러 개발
- 정리
- 프로젝트 유형별 상이한 어플리케이션 구축 방향
- 프로젝트에서의 아키텍트의 미션 : 제품과 시스템의 완성
- 어떤 경우든, 아키텍트는 상황에 따른 중요한 설계 방향의 의사결정을 내리며,
- 제품과 시스템의 완성 책임을 지는 존재
- 매트릭스의 아키텍트
- 아키텍트는 프로젝트안의 세계를 창조하고 관리하고 책임지는 존재
- 발표자 : 삼성SDS 정유선 책임
- ** Cloud Provider 의 입장에서 **
- 클라우드 컴퓨팅 개요
- 클라우드 컴퓨팅
- 비즈니스 요구사항
- Cloud Provider
- Cloud Consumer
- 클라우드 서비스 제공자와 사용자의 두가지 관점에서 고려해야 한다.
- Scope of Control
- Available Service on Cloud, Cloud Computing Service model
- 클라우드 참조 아키텍처
- 클라우드 참조 아키텍처
- Cloud Provider - Service Orchestration
- Service Orchestration 이 뭐야?
- Cloud Computing Reference Architecture
- Cloud Consumer
- Cloud Provider
- Cloud Broker
- Cloud Auditor
- Cloud Carrier
- 오픈소스 클라우드 플랫폼
- OpenStack
- CloudFoundry
- BOSH
- 아키텍쳐 패턴
- Event-driven
- Asynchronous
- Independent
- Shared-nothing
- 공통 : Messaging bus
- 정리
- 오픈소스 클라우드 플랫폼의 활용
- 사내 private cloud 구축
- Cloud 환겨에 대한 이해
- IaaS 또는 PaaS 구축
- 오픈소스 기술 지원 : 소스를 열어보고 그것을 이해하는 노력이 필요하다.
- Trouble Shooting of Challenge
- Cloud Migration
- 물리적 환경의 일반적인 N-Tier 아키텍처
- 클라우드 환경에서는 클러스터링이 어려운 문제다.
- Memory tier를 분리하여 Session replication 및 객체 캐시를 통해 부하를 분산시켜 목적에 맞게 DB 선택
- Message passing 을 통해 동작을 제어
- 제언
- 전체 그림은 크게 그리고, 시작은 작게 천천히 시작하라.
| |
6. Fleible UI Reference method with Open Architecture
|
|
