메뉴 건너뛰기

이 문서는 다음 링크의 글을 번역했습니다.

https://blog.appdynamics.com/product/the-importance-of-apm-for-developers/


The Importance of APM for Developers
 
소프트웨어 개발자를 중세시대의 장인과 비교해봅시다. 과거에는 나무를 가구로 만드는 과정 뿐만 아니라 만들어진 가구를 사용하는 사용자의 경험에 이르기까지 모든 것을 장인이 책임졌습니다. 디자인과 구현, 고객으로 전달에 이르는 모든 일을 직접 했습니다. 만일 의자 다리가 부러지거나 흔들리면 장인은 이것을 고쳐야 했습니다.
분명하게 말할 수 있는 것은 이런 전통적인 방식으로는 규모를 키우기 어렵다는 점입니다. 이는 곧 폭포수 모델로 이어집니다. 폭포수 모델에서 소프트웨어 개발자는 Check In까지 수행하고 QA빌드에 대해서는 잘 알지 못합니다. 그리고 코드가 운영환경으로 이관될 때에는 더 이상 그들의 소관이 아니고 운영팀에 일임됩니다. 이러한 방법은 마치 가내수공업을 대체한 대량 생산방식과 비슷합니다. 다행스러운 것은 APM을 통해 개발, 운영, 전략 등으로 나누어지는 Software Development Lifecycle(SDLC)에서 서로 간의 장벽을 허물어주고 의미 있는 통찰력을 나눌 수 있다는 점입니다.


개발자와 운영자의 갈등원인
 
만일 운영자와 개발자가 너무 적은 접점을 갖거나 아예 접점이 없다면 문제가 발생할 수 있습니다. 그들이 서로 의사소통 하지 않으면, 기능개발에 대한 우선 순위나 전략부족으로 갈등을 야기할 수 있습니다. 개발자는 고객이 원하는 기능을 제공하는 데에 관심을 갖지만, 운영자들은 코드의 신뢰도나 안정성을 확신하지 않으면 배포하려 하지 않을 것입니다.
따라서 팀 간의 부족한 연결고리는 에러가 양산되는 원인이라고 할 수 있습니다. 개발자에서 운영자로, 운영자에서 개발자로 돌아가야 할 피드백 사이클에 문제가 생기면 놓치는 데이터가 생기기 마련입니다. 이와 같이 무너진 SDLC에서는 다음과 같은 증상을 보입니다. 
 
 * 고객 평가가 전략을 좌지우지합니다. 
 * QA가 어플리케이션 성능에 대한 진상의 극히 일부만을 보고합니다. 
 * 개발자들이 그들이 만든 기능에 대한 사용현황에 대해 잘 알지 못합니다.
 * 운영 환경에서의 코드 문제를 해결하기 위해 개발자들이 추측해야 합니다. 
 * 운영팀이 부정확한 로그에 의존해 개발자와 협의하게 됩니다. 
 * PMO에서 적절한 로드맵 전략에 따른 우선 순위를 가지고 개발자와 협의하지 못합니다.


APM과 비즈니스 트랜잭션
 
성공적인 디지털 기반을 갖춘 회사에서는 개발자가 다양한 실환경에서 어떤 성능을 보이는지 제공하는 APM을 개발자가 사용할 수 있도록 하여 개발자와 비즈니스 목표를 긴밀하게 연결합니다. APM을 통해 SDLC의 모든 단계에 걸쳐 어플리케이션 코드를 검증하고 운영으로 넘어가기 전까지 개발자로 하여금 문제를 해결할 수 있도록 도와줍니다. 개발자는 APM을 사용하여 문제해결에 도움을 받을 수 있을 뿐만 아니라 다른 문제가 발생하기 전에 이번 코드 변경이 어떤 영향을 미칠 수 있는지에 대해 테스트할 수 있습니다.
 
APM의 주요 목표 중 하나는 바로 비즈니스 트랜잭션 관리입니다. 비즈니스 트랜잭션은 기술팀과 현업이 협업할 수 있다는 공통된 인식을 만들어 줍니다. 개발자는 기존의 개발자의 방식 뿐만 아니라 사용자의 관점으로 보다 넓게 소프트웨어를 바라봅니다. 소프트웨어를 처리, 탐색, 통신과 같은 기능적인 측면으로 만 바라보는 것이 아니라 보다 비즈니스 트랜잭션에 입각하여 개별 사용자들의 행동방식에 따라 전체 시스템의 복잡한 종속성을 생각하며 검증하게 됩니다.

APM과 SDLC
APM이 개선할 수 있는 SDLC의 다섯단계에 대해 제안합니다.
 
1. 연구 및 분석 – 이해관계자들이 달성하고자 하는 바와 해결해야할 문제에 대한 데이터를 수집하기 위 해 Business iQ를 활용하여 비즈니스 영향도를 측정합니다.
2. 설계 – 로드맵 전략으로 어떤 기능을 완성하는 데에 필요한 프로젝트 종류를 정의하고 APM과 비즈니스 트랜잭션을 통한 접근 방식으로 개발자와 PM이 공통적인 관점에서 응용 프로그램을 바라볼 수 있게 합니다.
3. 테스트 – 프로덕션으로 넘어가지 않은 단계에서는 QA가 주인공입니다. 애자일 프로세스는 APM솔루션을 통해 보다 민첩하게 고객에게 영향을 미치기 전에 잠재적인 문제를 걸러냅니다.
4. 구현 – APM이 가장 필요한 단계입니다. 오류 또는 지연이 발생하지 않도록 이를 식별하고 방지할 수 있기 때문입니다. 실제 수준의 유저 시나리오를 모방한 부하테스트/스트레스테스트를 시행하고 APM솔루 션을 통해 실시간으로 병목현상이 발견되는지 확인하십시오.
5. 지원 및 유지 보수 – 이 단계는 운영팀이 주도권을 갖게 되지만 APM을 통해 개발자와 의미 있는 협의를 할 수 있습니다. 결과적으로 고객의 기대를 만족시키는 비즈니스를 이끌 수 있을 것입니다.


애자일 개발의 장
 
새로운 세계에서는 속도, 기능 그리고 보안측면에서 꾸준한 발전을 요합니다. 운영 환경은 코드가 이관되 고 앱이 주기적으로 업데이트 되는 애자일 개발의 장입니다. APM은 개발자, 운영자, QA 그리고 제품전략 모두에게 공통적인 목표를 향한 일관된 관점을 제시할 것입니다. 마치 수 천년 전 장인들이 해왔던 방식과 같이 말이죠.
AppDynamics를 통해 개발자들이 코드를 개선하고 SDLC의 효율성을 증진시키고, 어플리케이션 성능 향 상 및 MTTR 단축을 기대하세요.

Who's NeO

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

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

http://www.solulink.co.kr

?
  • ?
    APM lover 2018.03.09 15:56
    Open source와 commercial edition 두 가지를 지원하는 APM 솔루션에 대한 소개 부탁 드립니다.
  • ?
    NeO 2018.03.20 12:57
    안녕하세요, APM Lover님.
    무료버전과 유료버전을 제공하는 APM이라면 대표적으로 Datadog이 있을 수 있겠습니다.
    다만 datadog도 Free버전은 APM available이 아닌것으로 보아 원하시는 형태에 부합하는지 모르겠습니다.
    MoSKito라는 APM도 있는데 이 툴은 기능상의 차이가 아니라 서포트 수준에 따라 가격정책이 다른것으로 보입니다.

    완전한 오픈소스 툴으로는 Prometheus, Scouter, Glowroot, stagemonitor 등이 있습니다.
    오픈소스툴은 고유한 사용목적(제품개발자의 의도)과 간결한 사용예를 가지기 때문에 목적에 맞는 것을 찾고 적용하는 데에 공을 들일 필요가 있습니다.

    많은 상용툴도 trial 기간에는 주요기능을 완전하게 사용할 수 있도록 하고 있습니다.
    기회가 된다면 새로운 글에서 정리해볼 수 있도록 하겠습니다.

 


  1. No Image

    Microservices, Monoliths and Self-Contained Systems (1) Monoliths

    Monolith (1. 단일 암체;(특히 고대의)거대한 돌기둥 2. (변화가 느리고 개개인에게 무관심한)거대한 단일 조직 모노리스(Monolith)에 대해 알아봅시다. 모노리스는 가장 기본적인 소프트웨어 아키텍처입니다. 만일 여러분이 특별한 계획 없이 코딩을 시...
    Date2017.12.13 ByNeO Reply0 Views319
    Read More
  2. Microservices, Monoliths and Self-Contained Systems (0) 서문과 인포그래픽

    이 문서는 다음 링크의 글을 번역했습니다. https://blog.appdynamics.com/engineering/microservices-monoliths-and-self-contained-systems-time-to-break-it-down/ 문서가 길어서 분할하여 게시합니다. (0) 서문과 인포그래픽 (1) Monoliths (2) M...
    Date2017.12.13 ByNeO Reply1 Views364
    Read More
  3. No Image

    개발자관점에서 APM의 중요성

    이 문서는 다음 링크의 글을 번역했습니다. https://blog.appdynamics.com/product/the-importance-of-apm-for-developers/ The Importance of APM for Developers   소프트웨어 개발자를 중세시대의 장인과 비교해봅시다. 과거에는 나무를 가구로 만드는 ...
    Date2017.12.04 ByNeO Reply2 Views815
    Read More
  4. Release Automation의 분류

    이 문서는 Release Automation의 분류에 대해 설명합니다. 본 문서는 다음링크의 글에 영향을 받아 2014년 5월에 작성한 문서의 일부입니다. https://devops.com/approaches-to-application-release-automation/ 지금은 익숙한 개념인 Hudson/Jenki...
    Date2017.12.01 ByNeO Reply1 Views606
    Read More
Board Pagination Prev 1 2 3 Next
/ 3