웹 의 시대에서는 막대한 트래픽(요청)이 발생하면 그 만큼의 수익이 나는 것이 어느 정도 가능했으며(광고 수익, 제품 구매 등…), 흔히 말하는 Enterprise 기업들을 위한 제품 Oracle과 여러 상용 WAS를 구입하여 많은 문제(예: 세션 클러스터링 등…)를 기본적으로 해결된 전제에서 시작했습니다.

하지만 모바일의 시대가 대두되면서, 사용자가 늘어난 만큼 매출이 발생되지 않는 상황이 발생했습니다. 금액적인 압박이 훨씬 크기 때문에 Oracle과 상용 제품을 쓸 수 없으니, 다양한 오픈소스를 활용하게 되었으며, Micro Service Architecture 등이 하나의 패러다임으로 많은 개발자들에게 논해지면서 더욱더 백엔드의 복잡도가 증가되는 것이 현재의 상황입니다.


이러한 상황을 풍자한 위의 그림처럼 재미난 그림도 있습니다.

백엔드의 성능이 저하되거나 장애가 발생하면 서비스의 품질이 낮아지고 고객 이탈을 유발하기 때문에 갈수록 성능 모니터링 역시 중요해지고 있습니다. (사족: 실례로 MSA를 적용한 기업들을 만났을 때 가장 고통스러워하는 것이 하나의 긴 트랜잭션에서 병목구간이 어딘지 알 수 없다는 것이었습니다.  그래서 Zipkin과 같은 오픈소스를 활용하여 병목구간을 찾기위해 여러 노력을 하시는 분도 있습니다.)

와탭은 오랜 경험을 거쳐 백엔드 성능에 영향을 주는 대표적인 문제 유형들을 설명 드리고자 합니다. 그 중에서도 자바 웹 애플리케이션에서 발견되는 대표적인 문제 유형들에 대해 소개하겠습니다.


요청이 발생한 경우 수행되는 트랜잭션에서 병목이 되는 구간은 다음과 같은 카테고리로 묶을 수 있습니다.

     

  • Database 연결 및 쿼리 수행
  • 내부 로직 수행
  • 외부 호출 (HTTP, Socket 통신 등)
  • 그 외 환경 설정이나 네트워크 등의 문제


Database 연결 및 쿼리 수행 시 발견되는 문제 유형


전통적으로 장애의 가장 큰 원인을 차지하는 것은  Database입니다.  Database에 연결하기 위해 Connection객체를 사용하거나 Query를 수행하는 로직에서 성능 저하, 장애가 가장 많이 발견됩니다.

1) Slow Query / DB Lock

Slow Query, 과도한 업데이트, 인덱싱이 발생할 경우 Database는 Lock이 발생합니다. Database에 Lock이 발생하면, 해당 Row에 접근하는 요청들은 Lock이 풀릴 때까지 대기하거나 Timeout 됩니다. 이는 웹 애플리케이션 성능이 저하되는 대표적인 원인이며 이로 인해 장애가 발생하기도 합니다.

2) 불 필요한 DB Fetch

요청하는 데이터의 건수가 많을 수록 응답 시간이 느려집니다. 실제 필요한 데이터는 상위 몇 개인데  대량의 데이터를 요청하였거나, ResultSet에서 Last로 커서로 이동시키는 작업들이 빈번해지면 응답시간이 현저히 느려지고 Out Of Memory가 발생합니다. ORM에서 생성된 쿼리들도 주의깊게 보셔야 합니다.

 3) Connection Leak / 부적절한 Connection Pool size

DBMS들은 클라이언트가 요청을 할 때마다 매번 Connection 객체를 생성하지 않습니다. 요청할 때마다 Connection 객체를 생성할 경우 생성 비용이 만만치 않기 때문에,  Connection Pool에서 미리 생성된 Connection을 꺼내 사용하게 되어 있습니다.

문제의 핵심은 Connection Pool 사이즈를 너무 작거나 너무 크게 설정한 경우 성능에 안 좋은 영향을 미칠 수 있다는 것입니다. 특히, Connection의 개수를 설정하지 않으면 10~20 정도의 default값이 적용되기 때문에 동시 사용자가 많은 경우에는 Connection의 개수를 그에 맞게 적절히 조절해야 합니다. (너무 과하게 Connection Pool Size를 잡으면 과도한 메모리를 사용하겠죠.)

자바에는 Connection, Statement, ResultSet 등DB Connection과 관련된 JDBC 객체가 존재합니다. 이러한 객체는 사용한 후 close를 하지 않으면 Connection이 Pool에 반환되지 않아 Connection Leak이 발생되며, 부작용으로 DB에 접근하는 트랜잭션들이 Connection을 얻지 못 하고 대기하여 요청 시간이 현저히 느려지거나, 최악의 경우에는 장애가 발생할 수 있습니다.

4) 그 외

그 외에도 트랜잭션이 commit을 하지 않고 Connection Pool에 반환되거나, 잘못된 코드로 불필요한 commit이 빈번하게 발생하는 경우에도 성능에 영향을 줄 수 있으니 코드 작성 시 주의해야 합니다.

간혹 느린 쿼리가 튜닝의 대상이 아닌 경우도 있습니다. 실행 시간이 느리지만 튜닝이 더이상 되지 않는 (느린 것을 감수해야하는) 쿼리도 있고, 실행 시간이 빠르지만 빈번하게 호출되며 튜닝의 여지가 있는 쿼리도 있습니다. 이런 경우에는 후자를 튜닝해야 전체적인 성능을 개선시킬 수 있기 때문에, 전체 트랜잭션의 분포도의 관점으로 바라보아야 합니다. (분포도라는 관점을 고려해서 와탭의 히트맵이 만들어졌는데요, 왜 이렇게 설계되었는지 추후 성능적인 글로 설명드리겠습니다.)

성능에 영향을 미치는 문제는 데이터베이스와 관련된 문제가 가장 자주 발생하며 그 원인 또한 다양하게 나타납니다. 로그 트래킹, Slow Query를 수집 하더라도 원인이 숨겨져 있는 경우가 많고, 비즈니스의 전체적인 성능을 모니터링 하기는 어렵기 때문에 APM(Application Performance Monitoring)으로 웹 애플리케이션의 성능을 분석하고 모니터링 해야합니다.


외부 호출 (HTTP, 소켓 통신 등) 


트랜잭션 안에 포함된 또 다른 외부 트랜잭션(외부 호출)이 긴 시간 수행된다거나,   Timeout이 발생하는 경우 성능 저하가 발생합니다. 예를 들어 택시 호출 앱을 호출했을 경우, 위치 정보를 얻기 위해 지도 서비스를 호출해야 되는 경우이지요.

이런 경우의 대답은 이중화 입니다. 하나의 외부 서비스(결재 서비스 A)가 주어진 데드라인에 응답하지 않는다면, 대안 서비스인 결재 서비스 B, C를 호출하는 이중화 전략들이 필요합니다.



MSA(Micro Service Architecture)가 인기있는 프로그래밍 패러다임으로 전환되면서 그림 3과 같은 End2End Transaction 모니터링에 대한 강한 니즈가 생기게 되었습니다. (사실 금융권에서는 거래 추적이라는 이름으로 예전부터 지원되었습니다.)


긴 시간 실행되는 내부 로직 수행


내부 로직으로 인해 성능 저하가 발생하는 경우도 종종 볼 수 있습니다. 특히 모바일 상황이 되면서 완료되지 않는 트랜잭션들이 존재하는 상황이 비일비재합니다.

* 모바일 애플리케이션에서, 데이터를 다 전송받지 못 하고 인터넷 접속이 불능 상태가 되었을 때 (서버 소켓 Write는 계속 일어나고 있으나, 모바일 애플리케이션이 비정상적으로 Read가 수행되지 않은 경우)
* 특정 파일을 업로드 하거나, 다운로드 하는 상황 등
* 예외 처리를 제대로 하지 않아 행이 걸리는 상황 등

이러한 경우는 이 당시의 Call Stack 정보를 얻어 오는 게 중요하며, 와탭은 10초마다 실행 중인 모든 트랜잭션의 메모리 스택을 추출함으로서, 통계적으로 느린 내부 로직을 우선순위화 하여 보여줍니다.


그 외 환경 설정이나 네트워크 등의 문제


* 너무 작게 설정된 Thread Pool
* 너무 작게 설정된 Heap Memory
* 과도한 서비스 요청 증가 (처리 능력 초과)
* 네트워크 장비로 인한 데이터 손실

이상으로 성능에 영향을 주는 병목지점들을 설명해 드렸습니다. 다음 포스트에는 병목구간을 가지고 있는 몇 개의 Problem Set (샘플코드)들을 실행하여, 다양한 SaaS APM에서  비교/분석해 보는 시간을 가지도록 하겠습니다. 


http://tech.whatap.io/2016/07/15/java-web-app-performance-problems/

( 출처 : 이글은 와탭테크 블로그에서 옮겨온 내용이며, 와탭랩스의 개발자 이나라님이 작성한 내용입니다. )


자바 웹 서비스의 리팩토링 팩터를 데이터 기반으로 제시할 수 있는 와탭 서비스, 모니터링을 재해석 하고 있습니다. 지금 서비스 받아보세요.


http://whatap.io


저작자 표시
신고
크리에이티브 커먼즈 라이선스
Creative Commons License
by 꿈꾸는자의 생각의파편들 2017.06.22 14:18
부제 : 비즈니슨의 속도, 개발 방법을 바꾸다.


비즈니스의 속도가 민첩하게 변화되면서 가장 크게 변화된 것은 팀의 구조와 개발팀, 기획팀의 거버넌스 체계입니다. 다음의 그림을 보죠.


고객과 내부의 작업자를 연결한 비즈니스의 구성에 있어서 고속으로 기획 및 개발이 이루어지려면 어떻게 해야 할까요? 기존의 피라미드 구조의 권한을 가진 거버넌스 구조로 이런 기민한 비즈니스 민첩성을 가질 수 있을까요?

매우 당연하게 비즈니스의 통제와 관련된 직원에 대해서 엄청난 권한 이향이 발생되게 됩니다. 소비자의 요구사항이 거의 직접 내부 작업자들에게 연결됩니다.

기존의 프로세스와 시스템 중심의 구조에서 의사결정 중심의 구조로 이동하게 되며, 이 구조는 DevOps의 구조의 형태로 진행되게 됩니다. 보통, DevOps구조를 명확하게 가지고 있는 곳이라면, 팀의 체계가 세분화되고, 배포 권한들이나 신규 기획 및 구현과 관련된 '권한'등이 대부분 팀원들이나 조직원들에게 이동되게 됩니다.

당연하게 배포 자동화 프로세스나 QC/QA 등의 체계 등이 매우 세분화되고 유연한 형태로 변화된 구조만이 이러한 DevOps구조에 적합합니다.

제가 속한 와탭의 경우에도 거의 가상화 된 조직으로 구성되어져 움직이는 매우 기민한 DevOps조직입니다.

분명한 것은 '고객'부터 기업 조직 내의 다양한 '점'들이 모두 이어지게 됩니다.


디지털 마케팅과 기업의 서비스는 하나다


라고 정의할 수 있습니다.

디지털 마케팅, 비즈니스의 속도에 대해서 소프트웨어 공학에서의 해결책들은 대부분 계획과 설계에 집중화되어 있습니다. 실제, 구현되고 동작되는 서비스들의 모든 액션이나 로그들을 추적할 수 없기 때문에 '모델'을 세우고 그 모델을 중심으로 프로세스와 품질을 추상적으로 관리하려 했습니다.

그 대표적인 3가지의 프로세스 평가 모형들은 다음과 같습니다.

하지만, 이 방법들은 기민하게 가동되는 1주일 간격으로 배포가 동작하는 디지털 비즈니스의 환경에는 적합하지 않습니다. 다른 방법을 찾아야 합니다.

더군다나, 대표적인 경험 중심의 학문도 변화하고 있습니다.

하지만, 이 방법들은 기민하게 가동되는 1주일 간격으로 배포가 동작하는 디지털 비즈니스의 환경에는 적합하지 않습니다. 다른 방법을 찾아야 합니다.


더군다나, 대표적인 경험 중심의 학문도 변화하고 있습니다.


그 대표적인 학문은 바로 '의학'입니다. 기존의 임상의학의 경우에는 아픈 환자에 대한 모델과 의료행위에 대한 기존에 증명된 모델들을 통해서 과학적인 방법으로 접근하는 방법으로 의료행위가 동작하였습니다. 의사 또한 직접 증상을 관찰하고 자신의 가설을 통하여 환자를 치료했죠.

하지만, 시대가 변했습니다. 환자들은 connected health기술들을 통해서 데이터들을 방대하게 수집하고, 의사들 역시 새로운 논문이나 신약, 치료법들에 대해서 데이터 분석과 경험적인 서포트를 받기 위해서 방대한 데이터 분석의 도움을 받아서 진료를 하기 시작했습니다.
의학 역시, 기존에 다루지 않았던 데이터들에 대해서 집중하기 시작했습니다.
이제, 소프트웨어 개발도 이러한 관점으로 변화되어야 하지 않을까요?
기존의 리팩터링들이 체크리스트와 프로세스, 기법 등을 통하여 유용한 결과를 얻어내는 모델의 형태를 취하는 추상적인 단계로 실증적이지 못했고, 매우 많은 시간들이 필요했습니다.

특히, 리팩터링의 관점들은 다음의 단계들을 진행했지만, 그 작업은 매우 방대하며, 실제 개발기간보다 더 더 필요한 것이 사실입니다.



중복된 코드 Duplicated Code
긴 메서드 Long Method
거대한 클래스 Large Class
게으른 클래스 Lazy Class
추측성 일반화 Speculative Generality
임시 필드 Temporary Field
메시지 체인 Message Chains
미들 맨 Middle Man
부적절한 친밀 Inappropriate Intimacy
다른 인터페이스를 가진 대체 클래스 Alternative Classes with Different Interface
불완전한 라이브러리 클래스 Incomplete Library Class
데이터 클래스 Data Class
거부된 유산 Refused Bequest
주석 Comments

하지만, 관점을 이런 행위와 모델의 접근법이 아니라, 실제 구현되고 동작중인 서비스에서 문제를 찾는 방법으로 접근법을 바꾸고 의료행위에서 자신의 경험에만 의존하는 것이 아니라, 의료영상기기인 MRI를 사용하듯이 방법을 바꾸어야 합니다.

다음의 프로파일들을 자동으로 추출한다면 위에서 언급된 리팩터링 작업의 상당 부분들이 실증적으로 처리할 수 있습니다.

특정 시점의 Transaction End-List
특정 시점의 SQL Query List
특정 시점의 Nested Web-Transaction End-List
특정 시점의 User, Transaction, Resource List
특정 시점의 Remote HTTP Call List
특정 시점의 Method List

물론, 모든 소스를 검토하고 다시 리뷰하는 시간을 거치면서 작업하면 좋겠지만, 작업 시간의 효율은 매우 떨어집니다.

그래서, SW 구조에 맞추어서 사용자들이 실제 서비스를 사용하는 행위와 해당 행위의 웹 트랜잭션을 기반으로 해당 서비스의 실제 상태(CPU, 메모리, 네트워크)등의 트랜잭션을 추적 관리하고, 이를 기반으로 통계적인 접근법을 사용하는 방법으로 문제가 큰 부분부터 잡아들어가는 방법을 사용하도록 유도하겠습니다.

이 방식은 다음의 그림으로 표현할 수 있습니다.


물론, 이러한 데이터들을 추출하고, 정제하고, 통계적으로 빠르게 접근할 수 있는 방법을 제공한다면, 리팩터링은 전체 소스를 뒤져가면서 논리적인 상황들을 연상하는 방법만으로 접근하는 것이 아니라는 것을 보여줍니다.

이제, 기존 리팩터링의 방법을 넘어서서 메서드 프로파일링을 기반으로 웹 트랜잭션을 세밀하게 검토하고 관리할 수 있습니다.

물론, 이러한 방법은 그냥 되는 것이 아닙니다. WebService Performance Framework라는 도구의 도움을 받아야 합니다. 이 Framework는 메서드 레벨의 추적이 가능할때 부여할 수 있습니다. 기존에 만들어졌던 APM제품들은 이런 접근이 불가능합니다. ( 국내외 모든 APM 제품 기준 )

또, 자랑합니다. 필자는 25년을 소프트웨어 공학을 해왔습니다만, 이렇게 손쉽고 빠르고, 정확하게 메소드 레벨을 추적하는 기술을 본적이 없습니다. 그렇습니다. 와탭의 APM( http://www.whatap.io )은 가능합니다.

것도, 고가의 설치형 APM이 아니라, 필요시에 필요한 만큼만 서비스받아서 문제를 해결할 수 있습니다. (월 몇만원의 서비스로 리팩토링 전문가를 고용해보십시요. )

빠르게 변화해야 하는 비즈니스의 속도, 기존 리팩토링으로는 해결할 수 없습니다. 와탭은 기존의 정적 분석과 동적 분석을 뛰어넘어, 숨겨진 메서드의 문제들을 통계적으로 추적 관찰할 수 있습니다.

hidden method troubble 처리 기법은 와탭의 Active Stack 기술(특허 : 10-2016-0078864)은 비즈니스의 속도가 필요한 모든 IT기업에게 정말 매력적인 방법을 제공합니다.


blog_signup_banner_b (3)


저작자 표시
신고
크리에이티브 커먼즈 라이선스
Creative Commons License
by 꿈꾸는자의 생각의파편들 2017.06.20 17:06
부제 : 디지털 비즈니스와 소프트웨어 공학의 관계?



IT서비스는 비즈니스의 요구조건에 맞추어서 개발되고 구현되는 것입니다. 기존의 소프트웨어 공학이 현재의 관점에서 잘 맞지 않게 된 이유 중의 하나는 '비즈니스의 속도'와 깊은 연관성을 가지고 있습니다.

분명한 것은 기존의 Classic Business와 현재의 Digitacl Business의 환경은 정말 다릅니다. 그 이유를 다음의 그림으로 설명하겠습니다.



기존의 Classic Business에서 어떤 상품이나 서비스들은 직접 고객과 연결되지 않았습니다. 그리고, 해당 비즈니스를 위해서 어떤 광고를 하거나 어떤 마케팅 행위를 했는지에 대해서 추정할 수밖에 없었다는 것은 이미 널리 알려진 사실입니다.

또한, 새로운 비즈니스가 기획되는 기간은 통계적으로 대략 6~9개월 정도 소요되며, 해당 기간 동안 데이터를 수집하고, 분석하고, 기획과 구현 실행을 하는 기간들이 포함된 내용입니다.

실질적으로 고객을 이해하는 것은 정량적인 데이터들이라기보다는 정성적인 판단이나 유추한 해당 비즈니스의 모델 구조와 모형에 대한 이해로 풀이하는 정도였습니다.

하지만, 이러한 Classic Business는 Digital Business로 넘어오게 되면서 급변하게 됩니다. 그 가장 큰 이유는 웹의 시작이었고, 모바일로 진화되면서 이 구조는 이제 견고해졌습니다. 이제 모든 고객들과 기업들은 connected 되었습니다.

고객이 어떤 광고에 반응하고, 어떤 동작으로 서비스를 사용하며, 어떻게 지불하고 어떤 반응을 보이는지 '데이터'를 중심으로 확인할 수 있게 된 것이죠.

더군다나, 이런 환경에서 새로운 비즈니스가 동작하는 시간이 최대 1주로 짧아진 상황에서도 기민하게 새로운 서비스의 구현이 가능해졌습니다.

451 Research의 조사에 따르면, 기존의 Business에 비해서 출시 기간이 4000% 개선되고, 모든 것이 데이터가 되었기 때문에 분석 능력은 400배, 전체적인 소요비용인 TCO는 50%가 절감되고, 관리 오버헤드도 50% 감소.
특히나 IT서비스의 개발자 대응능력이 24시간 이내에 개념을 수립해서 배포가 가능한 환경으로 돌입했습니다.

Digital Business에서 '비즈니스의 속도'는 기존의 IT서비스를 만들던 방식의 소프트웨어 공학으로는 설명할 수 없게 되었습니다. 물론, 아직도 기존의 6~9개월 이상 소요되는 대규모 프로젝트라면 의미 있겠지만 말입니다.
분명한 것은 '비즈니스의 속도'에 의해서 '소프트웨어 공학'은 다시 생각되게 되었습니다.

디지털 비즈니스를 기획하고 있다면, 기존의 소프트웨어 공학은 완전 다시 생각해야 합니다.




blog_signup_banner_b (3)


저작자 표시
신고
크리에이티브 커먼즈 라이선스
Creative Commons License
by 꿈꾸는자의 생각의파편들 2017.06.20 17:03
부제 : 자바튜닝과 성능 모니터링(APM)을 위한 체크 몇가지


실전 환경에서 소프트웨어 공학은 무용지물인 경우가 많다. 왜냐하면, 급박한 IT 비즈니스 속도에 맞추어서 빠르게 개발되고, MSA구조에 맞추어서 클라우드 위에 서비스가 올라가면서, 매우 작고 기민한 형태로 개발이 이루어지기 때문에, 기존의 장기간 고민하면서 큰 서비스를 디자인하는 방식의 접근법은 사용할 수 없다.


기존 IT서비스들이 8~9개월에 1개의 큰 서비스를 론칭하는 형태에서는 기존의 소프트웨어 공학적인 접근법이 매우 유용한 것은 분명 사실이다. 요구사항을 잘 수집하고, 또 잘 정제하고, 이슈 트리를 만들고, 소프트웨어 아키텍처를 구성하면서 팀의 역량을 키워가면서 개발 성숙도와 팀의 성숙도를 향상하면 분명, 소프트웨어 개발의 품질은 향상된다.


하지만, 실제 주변 환경을 돌아보면, 2~3주 내에 하나의 서비스를 론칭해야 하고, 신규 기능이 계속 추가되는 환경에서 기존 방법론들은 대부분 추상적인 '가르침'만을 이야기할 뿐이다.


현시점에서 필요한 것은 '추상적인 공학'이 아니라, 지금 당장 작업하고 있는 팀의 구조와 개발 목표, 고객의 피드백과 서비스들이 빠르게 개발되고 관리되는 관점이 필요한 것이다.


물론, Node나 Python, PHP( 라라벨이나 코드 이그나이터 등)를 이용하여 빠르게 서비스를 DB서비스에 맞추어서 개발을 할 수 있다. 다만, 이렇게 만들어진 서비스가 갑자기 증가되면서 실제 서비스되면서 요구사항이 폭주하고 서비스가 복잡하게 변화하면서 문제는 발생한다.

서비스가 복잡해지면, 문제도 같이 늘어난다. 장애도 같이 증가하게 된다. 매우 당연하게 고객들은 세션이 끊어지는 현상을 경험하게 되고, 사용이 불편해지고, 그런 상황에서 경쟁자가 출현하거나, 새로운 데이터 마케팅 방법을 적용하려고 할 때에 매우 곤란한 상황을 만나게 된다.


리팩터링 할 여유도 없고, 새로운 버전과 새로운 기능에 몰두해야 한다. 이런 경우에 개발 총괄을 어떤 생각을 해야 하는 것일까? 현재까지의 정답은 기존에 만들어진 서비스로 최대한 버틸 때까지 버티면서 새로운 서비스를 만들어서 이를 대체하는 것이 최선이라고 이야기할 수 있다.


차선책은 그 부분을 어떻게든 레이어 구분을 해서 부분 부분 리팩터링을 하면서 서비스를 고도화하는 방법으로 진행하게 된다. 분명한 것은 이런 과정들이 매우 고통스러운 튜닝 작업의 연속이 되게 된다는 점이다.


아이러니하지만, 경험이 풍부한 자바 개발자가 있다면, 이런 상황들을 나름 서핑하듯이 넘어갈 수 있다. 하지만 그렇지 않다면, 이 작업들은 매우 고통스럽고, 작업 진행이 효과적으로 진행되지 않는다면, 서비스가 중단되거나 고객들이 만족하지 못하고, 신뢰가 떨어지면서 고객은 이탈할 것이고, 서비스는 문을 닫는 상황으로 진행이 된다.


대부분 스타트업들이나 IT기업들은 초기의 1차 작업은 빠르게 개발하는 환경에서 기민한 개발자가 가장 효과적으로 사용하는 툴을 사용하여 서비스를 빠르게 비즈니스 환경에 맞도록 론칭하고, 이를 기반으로 본격적인 서비스를 다시 구상하는 것이 대부분의 패턴이라고 할 수 있다.


보통, 투자를 많이 받거나, 어느 정도 고객이 확보되는 순간에 경험이 풍부한 CTO레벨을 영입해서 이를 해결하려 한다. 매우 당연하게 경험이 풍부한 CTO는 기술 스택의 부족함과 리팩터링 이슈에 대해서 질문을 개시하고, 이를 갈아 없기 위한 논의를 시작하는 것은 매우 당연하다.


하지만, 비즈니스의 특성상 중단될 수 없고, 순차적으로 넘어가는 방법에 대해서 내부 협의가 잘되지 않는 경우에는 영입된 CTO가 이탈하거나, 개발팀이 제대로 꾸려지지 않아서, 서비스가 안착되기 어려운 경우도 빈번하게 발생된다.


분명한 것은 경험이 풍부한 CTO라면, 백엔드 서비스들에 대해서 기민하게 컨트롤하기를 원하고, 100만, 1000만 사용자들을 컨트롤할 수 있는 자바 백엔드 서비스를 매우 당연하게 구상할 것이다. 더 글로벌 서비스라면 데이터 스토리지와 관련된 레이어까지 다시 구상할 것이다.


그리고, 자바 튜닝과 관련된 인프라와 리팩터링, 코드리뷰와 개발 문화를 위해서 고민하고 이를 반영하려고 할 것이다. 


이번에는 그중에 자바 튜닝과 관련된 내용만 일부 나열하자.


자바 튜닝과 관련해서는 한두 페이지로 설명을 전부 할 수 없다. 다만, 여기서는 향후 구체적으로 설명하기 위한 '다이내믹 리팩터링'에 대한 사전적인 설명을 하는 정도로 기본 정리만 하겠다. 관련 내용들은 별도로 기술할 생각은 있으나, 요즘 관련된 문서들이 인터넷에 너무 많아서, 간단하게만 정리하겠다.


자바와 소프트웨어 공학적인 측면은 매우 일맥상통하는 부분이 많다. 정적인 분석이나 동적인 환경에서의 분석 및 프로파일링을 통해서 실제 CPU와 메모리, 네트워크 등의 리소스에 대한 세밀한 제어까지 가능하기 때문에 대규모적인 서비스에서 성능을 컨트롤하기 원한다면, 분명. 자바로 코딩되는 것이 매우 유용하다.


주변에서는 Node.js나 PHP로 1차 구현된 이후에, 본격적인 서비스를 위해서 JAVA로 재 코딩되는 경우를 많이 본다. 특히, '성능'이 이슈가 되거나 기민하게 가동되며, 서버 리소스 비용을 최소화하기 위해서 클라우드와 결합된 환경에서 극단적으로 튜닝하는 경우에는 자바로 코딩하는 것이 분명 효과적이다. (다만, 그만큼 복잡하고, 그만큼 경험이 풍부한 개발자가 없다면 이 선택은 어려울 수 있다. )


하지만, 리팩터링과 성능 프로파일링을 기반으로 엔터프라이즈 환경에서 유연하게 확장과 세밀한 컨드롤등이 가능한 것이 자바인 것은 굳이 더 설명이 필요 없다고 생각한다. 특히나, 리팩터링이 원활하고 원하는 프레임웍들을 손쉽게 선택할 수 있는 환경임에는 분명하다. ( 그만큼 아는 사람이 잘 쓴다. )


자바로 구현된 서비스를 중심으로 리팩터링의 이슈를 해결하기 위해서 중요한 관점들을 몇 가지 정리한다면 다음의 관점들에 대해서 관심을 가져야 한다고 정리해보자.


첫 번째. garbage collection에 대한 이해

분명한 것은 메모리에 생성되는 변수와 객체에 대한 할당과 해제에 대해서 가장 민감하게 생각되어야 한다. 자바 코딩의 기본 중의 하나인 System.gc()를 명시적으로 호출하는 경우는 논외로 하자. 아주 특이한 경우가 아니라면 직접 호출하지 않을 테니.

다만, gc와 관련된 모니터링을 위한 툴과 방법은 다음과 같다.


* jvmstat : 무료, jdk 1.4.2 이상, 

* visualgc : 무료

* jps : jvm 프로세스 뷰

* jstat : jvm 통계수치 뷰

* jstatd : 원격으로 jstat을 사용하기 위한 데몬


두 번째. 프로파일링과  APM의 활용

자바로 구현된 상태에서 소스 레벨 분석용을 위하여 정적 분석을 위해서 DevPartner for Java, Jprobe, TPTP(Eclipse 기반)등을 사용할 수 있으며, 웹서비스가 실제 구현되고 동작되는 상황에서 동적 분석을 위해서 APM(Application Performance Management)을 기반으로 프로파일링 하는 방법이 있다. 


정적 분석의 경우에는 대부분 String의 상태, Collection과 Map에 대한 자료구조에 대한 상황들을 관찰하고 분석한다. 특히, 대용량 데이터를 사용할 경우에는 적절한 프로파일링을 통해서 선택하는 것이 좋다.


특히, 자바의 경우에는 Collection의 다양한 클래스들이 존재한다. 사실상, 이 자료구조의 선택을 어떻게 하느냐에 따라서 전체적인 서비스의 성능과 장애의 근본 원인이 되는 경우가 대부분이다. 특히, 자료구조의 경우 동기화가 되고 안되고의 차이도 크니 이 부분을 기민하게 상요해야 한다.


세 번째. 그 이외의 것들

작게는 Loop의 성능에 대해서도 이야기를 하나. 사실상 그다지 차이가 없다. if나 switch나 큰 문제가 되지 않는다.  이외에도 static이나 syncronized 등을 참고하겠지만, 대부분의 '성능장애'는 이런 부분에서 발생하지 않는다.


큰 문제는 보통 IO병목이거나 Logging과 관련된 이슈, DB 연동을 위한 connection관리 등에서 발생한다. Connection, Statement, ResultSet 등의 관리가 핵심이다.


생각보다, XML 관련 이슈는 대규모 서비스이거나 사용자가 급증했을 때에 전체 서비스의 성능장애를 발생시키는 주된 요인이 된다. SAX의 경우 추적이 어렵고, DOM의 경우에는 메모리 사용량이 많아서 대부분의 APM들에서 추적이 불가능한 경우도 많다. ( 유일하게, 와탭 APM만 해당 이슈의 추적이 가능하다. )


그 밖에도 웹서버 관련 이슈도 많이 존재하고, DB connection Pool, session timeout 등을 주목하게 된다. JVM의 메모리 설정을 잘못해서 생기는 문제도 은근 많이 발생한다.


이러한 리팩터링의 관점들을 APM들은 매우 손쉽게 프로파일링하고 필요한 포인트들에 대해서 명쾌하게 접근할 수 있도록 매우 큰 도움을 준다. APM의 장점은 크게 다음의 두 가지로 정리할 수 있다.


하나는 Slow Query를 매우 손쉽게 찾아준다는 점이고. 다른 하나는 웹서비스 트랜잭션에 대한 프로파일링을 통해서 성능상의 이슈나 잘못된 설정등을 빠르게 찾게 해준다. 이처럼, 대부분의 WebService의 문제의 70% 정도는 Slow Query의 문제이고, 25%정도의 WAS내부의 성능문제들을 찾게 해준다.


다만, 소스코드 상에서 특정 클래스나 특정 펑션의 성능적인 이슈가 발생되어 비정상적인 성능장애가 발생한 경우에는 추적이 매우 어렵다. 기존의 APM들은 다이나믹 프로파일링이라는 기법으로 개발자의 추측과 소스코드상의 분석등을 통해서 문제가 예측되는 상황들을 하나씩 검토해 보는 방법을 사용한다.


또는, 인젝션하는 방법으로 서비스에 직접 걸어서 추출하는 방법도 있기는 하나, 이는 실 서비스에서 인젝션된 에이전트의 부하와 구분할 방법이 명확하지 않기 때문에 실서비스 보다는 개발환경에서 사용하는 경우가 많다. 대부분의 APM들은 이런 5%의 특이상황들에 대해서는 튜닝을 포기한다. 그리고, 향후 고도화작업이거나 솔루션 대체를 할 경우에 이를 해결하려고 한다.


대부분의 상용APM들이나 Scouter와 같은 오픈소스 형태의 APM으로도 대부분의 95%의 문제는 해결이 가능하다. ( 다만, Scouter의 경우에는 1~5대 정도의 서버에 적합하지, 100대이상의 대규모 서비스에 적용한다는 것은 사실상 실패를 할수 밖에 없다. ) 


문제가 발생한 소스 코드의 위치까지 찾는 기능을 제공하는 APM은 기존 APM제품중에는 없다.


여기서 와탭을 잠시 자랑하겠다. ~.~ ( 저.. 와탭의 CBO랍니다. ~.~ )~~~


이런 문제를 해결하는 APM이 있다. 와탭의 APM( http://www.whatap.io )은 이렇게 숨어있는 특정 소스라인의 문제들을 추적하여 리팩토링이 가능한 쉬운 방법을 제공한다. 와탭의 특허인 Active Stack이라는 기법( 10-2016-0078864 )으로 마치, MRI촬영을 하듯이 실제 동작중인 웹서비스에 설치하여 ( 재기동 없이 ) 스냅샷을 찍어서, 프로파일링하는 기법으로 문제가 되는 부분들을 손쉽게 찾아서 리팩토링을 빠르게 처리한다.

( 실제 사례 : 2년동안 못 찾은 모바일 뱅킹의 장애원인을 진단하다. )


앞에서 설명한 복잡한 정적인 코드 리뷰나 분서기법들을 사용하지 않고서도, 현재 동작중인 웹서비스의 리팩토링을 실시간으로 처리한다. 마치, Dynamic Refactoring이라고 불러야 적당할 듯하다.


blog_signup_banner_b (3)

저작자 표시
신고
크리에이티브 커먼즈 라이선스
Creative Commons License
by 꿈꾸는자의 생각의파편들 2017.06.20 16:57

부제:만들기 전에 무언가를 해결하는 것이 효과적일까?

10년 넘도록 동작하던 레거시에 가까운 코드로 동작하던 A기업의 고객 시스템에서 지속적으로 성능 문제가 발생하고 있다면 해당 서비스의 담당자는 머리를 잡고 고민할 것이다.

여러 가지 고민을 하겠지만, 대부분의 결론은 '서버'의 용량을 증설하는 Scale Up이나 Scale Out으로 결론이 난다. 소스나 내부에 대해서 어떻게 할 수 없을 경우가 대부분이기 때문이다.

분명한것은, 어떤 방법으로 증설하던 '비용'이 추가적으로 발생할 것이며, 이 '비용'에 대해서 부연설명을 하거나 해명을 할 준비를 하게 된다.

임원회의 때에 땀을 흘리며 브리핑을 할 것인지, 수월하게 할것인지에 대해서 고민하게 된다. 이런 문제는 어느 회사, 어떤 조직, 어떤 관리장의 입장에서도 비슷하게 발생한다.

지속적으로 성능 문제가 발생한다는 것은 어떤 것일까? 대표적인 케이스들만 서술한다면 사용자가 로그인하기 힘들다던가, 반응이 느려서 고객센터에게 전화가 많이 오거나, 홈페이지에 댓글이 연달아 달리는 경우일 것이다.

문제는 이 문제가 과거에는 잘 동작하던 시스템이었는데, 모바일 시대로 바뀌면서 발생하는 경우이다.

과거에는 해당 서비스들이 기업 내부의 직원들이 주로 다루었기 때문에 아주 큰 문제를 일으키지는 않았다.

하지만, 사용자들이 증가하고 모바일로 유사 서비스들이 제공되는 시대로 돌입하면서, 기존에 유야무야 존재하던 버그나 성능장애에 대한 이슈들은 이제 실제 고객의 클레임이나 고객의 불평불만을 접수하는 CS 부서의 주된 요청사항의 하나가 되었다.

매번 고객담당부서의 아우성을 IT 인프라 운영부서나 개발 총괄이 들을 수밖에 없는 시대가 된 것이다.

물론, 이런 문제를 해결하기 위해서 소프트웨어를 연구하는 많은 사람들은 그 해결책을 찾기 위해서 많은 연구를 하고, 대응책을 마련했다. 그 대표적인 것은 바로 '프로세스 평가 모형'을 만들어서 만들어지거나 만들어진 소프트웨어, IT서비스의 문제를 해결하려고 한 것이다.

대표적인 것 3가지를 살펴보자.

하나. ISO 9000 ( ISO 9000-3)
품질경영원칙을 미리 정립하고 시스템 기준으로 구축한다면 소프트웨어 품질이 좋아져서 IT서비스가 매우 효과적으로 운영될 것이라는 생각으로 만들어진 품질 기준이다.

프로세스의 관점으로 고객만족을 지속적으로 개선하자는 것이며, 경영자의 책임이나 소프트웨어 개발에 투여되는 자원들에 대한 관리, 구현체에 대한 측정 분석 및 개선책을 통해서 SW 개발과 공급, 설치와 유지보수를 위한 지침서들을 통해서 이런 성능 장애와 품질문제를 해결하고자 한 것이다.

둘. CMM(Capability Maturity Model)
SW 개발 조직의 실제 수행평가를 통해서 품질을 잡고자 하는 시도였다. 미 국방성(SEI Software Engineering Institute)에서 추진한 방법으로, 신뢰성 있고 사용하기 편리한 소프트웨어는 '성숙된 조직'에서 얻어 낼 수 있다는 가설 위에서 출발했다.

그러므로, 보다 '성숙된 개발 조직'을 갖추기 위한 체크 방법과 구현 방법들이 주로 고민되었다.

셋. SPICE(Software Process Inprovement and Capability dEtermination)
CMM의 성숙도 모형과 ISO/IEC12207의 SW생명주기 모형을 결합하여 프로세스의 능력 결정과 프로세스 개선을 위한 방법으로 품질을 높이고, 성능을 잡는 방법을 고안한 것이다.

이런 소프트웨어 공학들이 실제 소프트웨어를 개발하고 Lean 하고 기민하게 움직이는 현재의 소프트웨어 개발 방법과 비교한다면 너무도 추상적인 개념과 측정할 수 없는 개발자나 개발 조직 등의 품질을 잡으려고 한 시도였다고 솔직하게 이야기하자.

과거, IT 비즈니스의 신규 기능이나 신규 서비스의 개발이 9개월 이상 소요되던 시대에는 이러한 방법을 통해서 반복적인 설계와 미리 예측된 상황들에 대해서 고민하면서 이 문제를 개발 전과 개발 중에 해결하려고 애를 쓴 것이기 때문에 나름 의미가 있었다.

하지만, 현재의 IT서비스를 돌아보자. 빠르면 1주, 늦어도 2~3주에 한 개의 IT서비스가 새로 만들어지며, 기획부서는 데이터를 직접 분석하여 새로운 서비스를 만들어낼 준비를 한다. 개발자들은 빠르게 이렇게 만들어지는 서비스들을 대응해야 하는 고속 개발의 시대로 접어들었다.

더군다나, 사용자들의 행동 패턴을 예측할 수 없는 모바일 기기들에 대해서 대응하는 IT서비스를 구현하기 위해서 수십만, 수백만의 사용자들을 고려해야 하는 MSA의 시대이다.

이제는 소프트웨어들은 어느 정도의 품질과 어느 정도의 성능을 위한 공학적인 도움은 받았으나, 그동안 공학의 '모델'에서 애써 외면하던 5%의 영역이 실제 IT서비스에서 문제를 일으키기 시작한 것을 다들 몸으로 느끼고 있다.

대표적인 것이 특정 시간, 특정 일자만 되면 CPU가 급등하거나 네트워크가 급등하는 등의 반복적인 상황이 발생하고 있다는 것이다. 이런 상황들은 '모형'에서는 대부분 오차로 인지하는 영역들이며, 특이한 영역으로 구분되었기 때문에 '공학'은 고민하지 않았다.

관리적으로는 경위서나 사유서로 대체하고... 1년에 며칠만 고생하면 되었기 때문이다. 하지만, 모바일 시대에서 이런 방식으로는 경쟁회사와 경쟁업체에게 자사의 서비스에 대한 신뢰도를 급락하게 하는 주요한 사유가 된다.

사용자들은 '어떤 날' '어떤 시간'에 성능장애를 겪고 있다면, 기존의 '소프트웨어 공학'만으로는 해결이 안 된다는 것을 이제 깨달아야 한다. 사용자들에게는 WebService Application Performance Framework의 접근법이 필요하고, 해당 장애나 문제를 일으키는 '한 줄의 코드'에 집중해야 한다.

기존의 공학은 이 '한 줄의 코드'를 유추와 분석, 가설과 모형으로 찾아냈지만, 현재의 IT기술은 소프트웨어 개발자들에게 관련 스냅샷과 프로파일링 기법으로 빠르게 1줄의 코드를 빠르게 찾아낼 수 있는 시대로 돌입했다.

다음의 사례를 참조하시기를... '2년 동안 못 찾은 모바일 뱅킹의 장애 원인을 진단하다.'


데이터기반의 리팩토링이 가능하도록 모니터링을 재해석한 와탭!

http://whatap.io


blog_signup_banner_b (3)


저작자 표시
신고
크리에이티브 커먼즈 라이선스
Creative Commons License
by 꿈꾸는자의 생각의파편들 2017.06.20 16:55

Apple | iPad mini 2 | Normal program | Pattern | 1/120sec | F/2.4 | 0.00 EV | 2.1mm | ISO-64 | No flash function | 2016:02:26 15:41:55

중국이나 일본 출장을 다니다 보면... 화상회의에 대한 필요성을 많이 느끼게 된다. 그 필요한 기능들을 몇가지 정리해보자.

위 사진은 상해를 방문했을때에 방문했던 대한민국 임시정부유적지 기념사진이다.

개인적으로 생각하는 화상회의 시스템의 기능...

1. 회의의 구성을 위한 슬롯의 구성으로 회의의 시작과 종료에 대한 보관자료 형태의 로그성 블록체인 기술로 논의된 내용의 위변조에 대한 대응방안이 구성된 형태

2. 회의를 진행한 내용에 대한 '구술'에 대해서 Text형태로 자동화된 구술 기록 서비스 기능

3. 전체적인 회의의 논의 내용에 대한 요약을 자동으로 하는 기능

이런 3가지의 기능이 들어가 있으면 좋겠다는...

저작자 표시
신고
크리에이티브 커먼즈 라이선스
Creative Commons License
by 꿈꾸는자의 생각의파편들 2016.07.01 19:59

스마트폰이 발전하고, 개인간의 화상통신이 가능한 서비스들이 많아졌다. 아이폰이나 아이패드, 맥을 사용하는 사람들의 경우에는 간단하게 FaceTime만을 사용해도 1:1의 화상통신은 간단하게 사용할 수 있다.

그래서, 화상회의는 이미 일상생활의 하나의 서비스로 인식되는 경우가 많다.

하지만, 구글 행아웃이나 페이스타임만으로는 원활한 원격 화상회의는 진행은 가능하다, 자료를 같이 보거나, 의견을 교환하는 용도로 사용하기에는 조금 불편함이 있다.

더군다나, 화상회의의 용도가 원격진료의 영역으로 넘어오면 그 기능적인 환경에 대해서는 더 많은 고려가 있어야 한다.

Apple | iPhone 6s | Normal program | Pattern | 1/33sec | F/2.2 | 0.00 EV | 4.2mm | ISO-40 | Off Compulsory | 2016:05:20 12:31:47

얼마전, 중국 전시회에서 본 홈헬스디바이스들이다.

어떤 정보를 사전에 전달하거나, 필요한 의견들에 대한 '정해진 규칙'에 의해서 기록이 남아야 하는 경우에는 그냥, 페이스타임이나 행아웃만으로는 그 행위 전체에 대한 근거를 남길 수 없다.

사실상, 기업이나 특정 목적을 위해서 원격으로 화상대화를 하거나, 업무에 대해서 진행할때에 기업용의 화상회의가 필요한 이유이기도 하다.

과거, 제약회사 시절에 지역 대리점들의 영업회의가 폰콜로 이루어지는 형태를 보았으나, 매우 비효율적이었고, 정해진 형태의 합의가 매우 진행되기 어려웠다.

화상회의는... 규칙과 의견들이 정해진 형태로 진행될 경우에 그 큰 의미를 발휘한다고 할 수 있다.


저작자 표시
신고
크리에이티브 커먼즈 라이선스
Creative Commons License
by 꿈꾸는자의 생각의파편들 2016.07.01 09:38


의료에서 사용되는 화상회의 솔루션에 대한 고민이 있다.
원격진료가 아닌 협진이나 의료공간에서의 활용에 대해서 생각을 해본다.

위의 사진은 원격으로 간질환지를 위한 IoT디바이스를 중국 북경 전시회에서 본것이다.

의료공간에서의 화상회의와 필요한 환경들을 어떻게 고민해야할까?


디바이스들은 한번 삽입되면 10년 이상 가동한다고 한다.

의료공간에서의 디바이스와 연동되는 것은 이제 너무나 당연한 고민인듯...

다시 고민한다... 의료공간에서 화상회의 솔루션을 응용하고 활용할 방법을 고민해본다.

저작자 표시
신고
크리에이티브 커먼즈 라이선스
Creative Commons License
by 꿈꾸는자의 생각의파편들 2016.06.28 17:49

Apple | iPhone 6s | Normal program | Pattern | 1/120sec | F/2.2 | 0.00 EV | 4.2mm | ISO-25 | Off Compulsory | 2015:11:03 12:20:57


애플와치를 지원하는 화상회의 시스템은 없을까? 가끔 생각해보면... 페이스타임이외에도 화상회의를 업무용으로 사용하는 경우가 발생하는데, 스마트워치와 결합된 화상회의나 화상회의 솔루션에 대해서 알고 싶어진다.


화상회의와 결합된 애플워치의 기능이나 화상회의에서 시그널이 결합되어진 형태로 제공되는 형태는 없을까?


요즘 해외로 미팅을 많이 다니는데... 그런 기능들에 대해서 갑자기 궁금해진다...

저작자 표시
신고
크리에이티브 커먼즈 라이선스
Creative Commons License
by 꿈꾸는자의 생각의파편들 2016.06.28 16:56

Apple | iPhone 6s | Normal program | Pattern | 1/17sec | F/2.2 | 0.00 EV | 4.2mm | ISO-200 | Off Compulsory | 2016:06:26 20:52:21


아이나비 OBD연동 정보로 최고기록인 리터당 26.6 km/L를 달성했습니다.


재미있네요... 트립컴퓨터의 정보가 더 적게 나온다는... 근거리의 이동거리를 함께 계산하는 형태로 계산이 되는 것도 매우 흥미롭습니다. 


좌우당간...


폭스바겐 파사트로 연비 26.6 km/L라니..


놀랍네요...

저작자 표시
신고
크리에이티브 커먼즈 라이선스
Creative Commons License
by 꿈꾸는자의 생각의파편들 2016.06.28 15:57

티스토리 툴바