메뉴 건너뛰기

요약


소프트웨어 개발 라이프사이클(SDLC)에 연관된 모든 사람들의 작업은 어플리케이션과 비즈니스 성능 정보를 쉽게 확보할 수 있도록 함으로써 개선될 수 있다.

 

시작하며


일련의 상호의존적 절차를 분리된 행동으로 나누어 생각하는 것은 프로 오케스트라와 스포츠팀에 이르기까지 모든 방식을 향상시키는 첫걸음입니다. 소프트웨어도 예외는 아닙니다.

 

소프트웨어 개발 라이프사이클(SDLC)1960년대 후반 개선의 여지가 있는 미성숙한 산업에 품질 향상 프로세스를 적용하면서 시작됩니다. 물론 조직마다 SDLC를 구현하는 방법은 서로 다르겠지만 일반적인 단계는 다음과 같이 분석, 설계, 개발, 테스트, 릴리즈와 운영모니터의 6개 단계로 구성됩니다. SDLC가 소개되고 세월이 흘러도 지금 유행하고 있는 DevOps와 약간의 혼선이 있지만 SDLC는 여전히 성과를 내고 있습니다. 용어자체에 얽매이지 않는다면 그 이론은 동일합니다. 다만 단순히 그들이 이야기하는 이론을 따라하는 것만으로 다양한 지역과 규모의 서로 다른 플랫폼에 걸쳐 발생하는 문제를 해결해낼 수는 없습니다. 오늘날의 엔터프라이즈 개발 프로젝트에서 SDLC의 효율성을 높이기 위해 조직은 APM(Application Performance Monitoring)을 사용할 것을 고려해야합니다.

 

APM은 개발자로 하여금 자신이 수행한 변경이 성능에 도움이 되는지 방해가 되는지 알 수 있게 해줍니다. 어플리케이션, 인프라스트럭처 그리고 사용자 경험을 보여주는 통합 뷰는 머신러닝 알고리즘에 의거한 자동 베이스라인과 멀티 티어, 스택, 플랫폼에 걸친 연관 트랜잭션, 종속성을 가시화하고 Error Exception정보를 캡처함으로써 많은 추측기반의 작업을 줄여줍니다. 전세계의 데이터센터 걸친 대대적인 업데이트를 배포하든지 클라우드상에 컨테이너서비스를 롤아웃하든지 APM은 개발자의 작업에 많은 도움이 될 것입니다. APM이 일반적인 SDLC의 각 단계에서 어떤 성과를 낼 수 있는지 설명해 보겠습니다.

 

Plan

 

“Solid Code: Optimizing the Software Development Life Cycle”의 저자는 우선 이렇게 조언할 것입니다. “생각하는 것이 우선이고 코드는 다음이다.” 분석단계에서 프로덕트 매니저는 고객과 엔드유저, 세일즈와 많은 이해관계자로부터 요구사항을 수집합니다. 누가 이 소프트웨어를 사용할 것인 것? 어떤 방식으로 사용할 것인지? 무엇이 정상이고 무엇을 고쳐야하는지? 동등하게 중요한 문제로 구현에 어떤 자원이 필요한지와 프로젝트 비용은 얼마나 예상되는지가 있을 수 있겠습니다. 이 질문에 답하기 위해서 개발자는 현재의 시스템 아키텍트를 정확하게 이해하여 나타난 추가 요구사항 또는 발견된 리팩토링에 대응해야 합니다. 자동으로 어플리케이션 서버와 데이터베이스, 인프라스트럭처를 비즈니스 트랜잭션 기준으로 연관하여 플로우맵으로 시각화해주는 하나의 통합된 모니터링 솔루션이 있다면 이 작업은 아주 쉬운 일일 것입니다.

 

Design

 

분석단계에서 얻은 인사이트는 더 좋은 설계로 이어집니다. 설계 단계에서 개발자는 새로운 아키텍처를 검토하고 사용할 프레임워크와 라이브러리 그리고 알고리즘을 설계하며 데이터 관리에 대한 결정을 하게 됩니다. APM은 개발자로 하여금 현재의 시스템과 프레임워크의 상황을 보여주고 어떻게 사용되는지 알 수 있게 해주며 기존 코드의 목적이 변경되어도 재사용가능한지 또는 새로 작성해야 하는지를 판단할 수 있게 해줍니다. 개발자와 프로덕트 매니저는 엔드유저 모니터링 기능을 통해 사용자의 어플리케이션 사용 패턴과, 지역, 브라우저 정보를 현재 발생하는 퍼포먼스 문제와 장애상황과 함께 봄으로써 새로운 디자인을 설계할 수도 있을 것입니다.

 

Develop

 

개발 단계는 많은 개발자에게 의미 있는 단계입니다. Waterfall 개발방식이 만연했던 시대에서 개발자는 코드를 작성하고 디버깅하고, 완성된 코드를 통합 테스팅 영역으로 전달했습니다. 그러나 Agile 개발방식이 득세하면서 개발자는 조금 더 많은 피드백을 자주 받을 수 있게 되었습니다.

 

개발 환경에 APM을 둠으로써 개발자는 실제 코드의 동작에 따른 코드 의존도의 변화를 확인할 수 있습니다. 또한 그들이 작성한 새로운 코드가 어플리케이션 전체규모에서 어떤 영향을 미치는지 확인해 볼 수도 있습니다. 이것을 잘 활용하면 개발자는 APM을 통해 잠재적인 이슈를 확인할 수 있습니다. 새로운 코드가 네트워크 지연에 영향을 미치는지? 메모리 사용에는 어떤 영향을 미치는지? 로드가 많은 상황에서는 어떻게 디자인해야 하는지? 적합한 호스트 환경의 스펙은 무엇인지? 어플리케이션을 안정적으로 서비스하는 데 필요한 CPU와 메모리는 어떻게 되는지? 와 같은 더 큰 문제도 해결해 낼 수 있습니다.

 

개발자가 APM을 통해 어플리케이션에서 발생할 수 있었던 문제를 Testing 또는 QA단에 넘기지 않은 상태에서 발견하는 것은 드문 일이 아닙니다. 오히려 개발자는 더욱 더 주의 깊게 버그를 줄이고 운영환경에 코드를 이관할 것입니다.


Fewer2.png


Test

 

Continuous Release 로의 지속적인 변화는 빌드 파이프 라인에서 자동화 테스트 사용을 증대시켰습니다. 이것은 주로 가시성 확보의 문제였습니다. 그런데 성능 저하를 초래하는 코드가 기능 테스트를 통과하고 프로덕션으로 푸시 될 수 있는 문제가 남아있습니다. 이러한 잠재적인 비용이 큰 시나리오는 테스트 환경을 APM으로 모니터링함으로써 피할 수 있습니다. APM을 사용하면 성능 메트릭을 기존 임계 값 또는 이전 릴리스와 쉽게 비교할 수 있습니다. 또한 개발 환경에서와 마찬가지로 APM은 성능 문제에 대한 근본 원인 분석 속도를 높입니다.

 

Release

 

APM이 주는 가장 큰 장점 중 하나는 바로 릴리즈 엔지니어가 릴리즈 작업 시, 운영 환경이전에서 발견되거나 알려진 이슈가 충분히 테스트되었으며 로드테스트를 통해 검증되었다는 안도감을 준다는 것입니다. 어플리케이션의 호출관계를 시각적으로 보여주는 플로우 맵, 어플리케이션 성능의 특이점을 표시해주는 히트맵은 특히 마이크로 서비스 아키텍처에서 종전의 Canary 또는 Blue-Green 배포와는 다른 추가적인 확신을 갖게 해 줍니다.

 

Monitor

 

APMMean time to Resolution(MTTR)최소화라는 1차적인 역할에 걸맞게 운영환경에 우선적으로 적용되어왔습니다. 그러나 개발팀의 민첩성이 요구되어짐에 따라 APM은 최종사용자의 행동 패턴에 대한 통찰력과 비즈니스 목표에 대한 어플리케이션 성능 영향도를 분석하여 다음 개발 주기에 반영할 수 있도록 더 많은 정보를 제공하기 위해 발전하고 있습니다. APM은 개발자로 하여금 어플리케이션의 최근 변경사항에 대한 실재를 포악하고 더 발전된 다음 릴리즈를 계획하는 데에 도움을 줍니다.

 

설명한 바와 같이 APMSDLC의 모든 단계에서 그 가치를 입증할 수 있습니다. 그리고 운영환경 뿐만 아니라 개발, 테스트 환경에서 APM을 채택한다면 더욱 큰 가치를 얻을 수 있을 것입니다. 개발자와 IT운영부서가 코드레벨 진단을 수행하는 능력, 공통적인 언어를 가지게 됨으로써 진정한 DevOps 문화가 뿌리내릴 수 있을 것입니다. 결국 DevOps는 의사소통의 문제이며 효과적인 의사소통을 하기 위해서는 문제를 바라보는 공통적 시각이 필요합니다. APM은 문제가 발생한 시점의 실재적인 요소를 보여줌으로써 많은 합리적인 또는 불합리한 의심과 학술적 논쟁을 제거해 줍니다. 개발자와 IT운영부서는 보다 효과적이고 유지보수비용이 적은 코드를 신속하게 배포한다는 공통의 목표에 더 가까이 갈 수 있습니다.


원문 : https://blog.appdynamics.com/product/how-apm-improves-software-development-life-cycle-sdlc/

Who's NeO

ALM, SW 모델링, SW 정적분석, Devops 특히 CI/CD, APM을 통한 Shiftleft에 관심이 많습니다. 

차세대 APM Cisco AppDynamics와 모바일 앱 모니터링 VMware Apteligent를 소개합니다.

http://www.solulink.co.kr

Atachment
첨부 '1'
?

 


  1. AppDynamics Cognition Engine을 통한 이상징후와 근본원인 분석

    Anomaly Detection and Root Cause Analysis with AppDynamics Cognition Engine Summary AIOps와 어플리케이션 인텔리전스를 결합하여 AppDynamics Cognition Engine은 시스템에서 발생하는 막대한 양의 메트릭을 분석하고 인사이트를 얻을 수 있습니다. AppD...
    Date2019.07.09 ByNeO Reply0 Views67
    Read More
  2. 코드 인스펙션 룰을 작성하는 과정

    훌륭한 Code Inspection 도구가 많고, 도구의 완성도와 빌트인 룰의 효용성이 좋아지고 있지만 여전히 프로젝트에서는 커스텀 룰을 필요로 합니다. 이것은 시큐어코딩이나 보안감사, 데이터 관리평가와 같은 외적 요인에 의한 동기와, 코드의 가독성 향상, 유...
    Date2018.07.31 ByNeO Reply1 Views820
    Read More
  3. 버그는 줄이고 릴리즈는 빠르게 : APM이 Software Development Life Cycle을 개선하는 법

    요약 소프트웨어 개발 라이프사이클(SDLC)에 연관된 모든 사람들의 작업은 어플리케이션과 비즈니스 성능 정보를 쉽게 확보할 수 있도록 함으로써 개선될 수 있다.   시작하며 일련의 상호의존적 절차를 분리된 행동으로 ...
    Date2018.07.25 ByNeO Reply0 Views471
    Read More
  4. 2. Service Endpoint를 활용한 Database 성능 모니터링

    본 문서는 다음 문서를 번역한 글입니다. 총 2개의 글로 이루어진 이번 연재는 AppDynamics Global Services team의 John Aronson이 작성한 글로, Database 성능 개선을 위한 AppDynamics 활용법이 설명되어 있습니다. https://blog.appdynamics.com/p...
    Date2018.06.21 ByNeO Reply0 Views468
    Read More
  5. 1. Business Transaction을 통해 문제가 되는 Database Query 찾아내기

    본 문서는 다음 문서를 번역한 글입니다. 총 2개의 글로 이루어진 이번 연재는 AppDynamics Global Services team의 John Aronson이 작성한 글로, Database 성능 개선을 위한 AppDynamics 활용법이 설명되어 있습니다. 글이 조금 깁니다. https://blog...
    Date2018.05.02 ByNeO Reply0 Views591
    Read More
  6. DevOps 시작을 위한 가이드

    데브옵스(DevOps)의 인기는 몇 년동안 지속되고 있다. 데브옵스는 문화의 변화, 자동화, 변경 관리, 지속적인 배포 등을 설명하는데 사용된다. 본질적으로 데브옵스는 개발(Dev)팀과 운영(Ops)팀이 협업하여, 더 빠른고 신뢰성있는 릴리즈 파이프라인 구축하는...
    Date2018.04.13 ByTom Reply0 Views1043
    Read More
  7. 7. 릴리즈와 시간의 흐름에 따른 모바일 메트릭을 관리하자

    7. 릴리즈와 시간의 흐름에 따른 모바일 메트릭을 관리하자 올바른 메트릭 관리하기 다양한 앱 사용자의 요구사항에 대응하는 성공적인 앱의 공통적인 요소는 바로 데이터를 지속적으로 측정하고 모니터링하는 데에 중점을 두고 있다는 것입니다. 성능메...
    Date2018.03.12 ByNeO Reply0 Views773
    Read More
  8. 6. 배터리 광탈과 데이터 과소비를 막자

    6. 배터리 광탈과 데이터 과소비를 막자 배터리 광탈이나 데이터 과소비는 사용자가 중요시 여기는 항목이지만, 앱을 제공하는 회사에서는 종종 잊어버리기 쉬운 메트릭입니다. 연구조사 업체인 IDC1의 조사에 따르면 대다수의 사용자들이 새로운 핸드폰을 ...
    Date2018.03.08 ByNeO Reply0 Views498
    Read More
  9. 5. 주요 Flow에서 네트워크 호출을 모니터링하자

    5. 주요 Flow에서 네트워크 호출을 모니터링하자 주요 Flow의 속도를 빠르게 하는 3가지 방법 1. 상위 3개의 인터랙션을 측정하라 앱의 속도를 빠르게 하기 위한 첫 걸음은 인터랙션을 완수하는 데 걸리는 시간을 측정하는 것입니다. Userflow 기...
    Date2018.03.06 ByNeO Reply0 Views474
    Read More
  10. 4. 인터랙션 타임을 최적화하여 사용자 경험을 개선하자

    4. 인터랙션 타임을 최적화하여 사용자 경험을 개선하자 우리 앱이 사용자를 당혹스럽게 만들고 있지는 않은지? App load time과 더불어 느린 트랜잭션은 사용자를 당혹스럽게 합니다. Jakob Nielsen의 UI디자인에 관한 powers of 10 연구결과에 의하...
    Date2018.02.27 ByNeO Reply0 Views417
    Read More
Board Pagination Prev 1 2 3 Next
/ 3