우아한 테크 세미나 - 자바, 성능, 모니터링 이야기 후기

안녕하세요. Popit에서 글을 쓰고 있는 김대희라고 합니다. 이번 우아한 테크 세미나는 자바 성능 개선 및 모니터링에 대한 설명이었고, 제가 사용하는 언어인 자바에 관한 것이었기 때문에 정말 참여하고 싶었습니다. 정말 운이 좋아 우아한 형제들의 테크 세미나에 당첨이 되었고,  이번 우아한 테크 세미나에서 자바 이야기, 자바 성능 이야기, 자바 모니터링 이야기에 대해 상민님께서 1시간씩 총 3시간동안 세가지 이야기를 나누어 설명을 해주었습니다. 흔쾌히 후기를 허락해 주신 상민님께 감사를 드립니다 .

상민님 대표 사진

자바, 성능, 모니터링 - 1 - 성능

자바 성능 - 1

첫번째로는 왜 성능이 중요한지, 이러한 성능에 끼치는 것들은 어떤 것들이 있는지에 대해 설명해주셨습니다.

1-1. Agenda

  • 왜 성능은 중요한가?
  • Users
  • Time
  • TPS & Time
  • Bottleneck

1-2. 왜 성능이 중요할까?

  • 성능이 중요한 이유 ( )
  • 성능 개선시 실제 사례
    • Pinterest는 응답시간 40% 개선
    • BBC는 10%의 추가적인 유저들 확보
    • etc...

1-3. 성능과 관련있는 항목들 

  • Users
  • Time
  • TPS
  • Users
    • User는 Activer User와 Concurrent User가 있다.
  • Active User
    • 서버에 부하를 주고 있는 User
    • 메뉴나 링크를 누르고 결과를 기다리는 사용자
    • 성능 테스트시 Virtual User와 거의 동일
  • Concurrent User
    • 서버에 부하를 주고 있거나, 줄 가능성이 매우 높은 서비스에 접속중인 사용자
    • 웹 페이지를 띄워 놓거나 앱을 실행하는 사용자
  • Active User와 Concurrent 사용자의 비율을 아는 것은 성능 테스트시에 매우 중요
    • 비율에 따라 실제 성능에 관해 좀 더 정확하게 테스트 하고 이를 파악할 수 있음
  • Time
    • User와 System, Server 의 Time 관점은 다름
    • 성능 테스트시 이러한 점을 모두 고려해야 함
  • TPS
    • Transaction Per Seconds
    • 초당 처리량
    • 1초에 얼마나 많은 요청들을 처리할 수 있는가
  • TPS & Time
    • TPS 는 Scale out / up 을 통해서 증가 시킬 수 있음
    • Time 은 Scale 으로 불가능
    • 둘다 Tuning 을 통해서 개선 시킬 수 있음
  • TPS & User / Time & User
    • TPS & User는 User가 증가하면 TPS가 증가하다, 어느 순간 증가 X
    • Time & User는 일정 수준에 도달할 때까지 Time은 유지하다가, 어느순간 병목 증상 발생시 급격히 증가
  • 성능의 가장 큰 문제는 Bottleneck ( 병목 때문이다. )
    • Bottleneck - 주요 병목 지점
  • Bootleneck - Server / Client 문제
    • Server ( Server 장비 , Application , 저장소, 설정, ETC .. )
    • Client ( Client 장비, Application )
    • 병목 지점은 한가지 원인이 아닌 여러가지 원인으로 인해 발생할 수 있음
  • Bootleneck Top 3
    • Web Page / App
    • DB
    • NetWork

1-4. 해당 세션에서의 결론과 소감평

결론 : Performance engineering is "Composite Art" of IT

소감평 : 해당 서비스를 하나 유지하기 위해서는 제일 중요한 것은 사용자가 느끼는 성능이라고 생각합니다. 이러한 성능을 개발자 입장뿐만 아니라 다른 관점으로도 들을 수 있었습니다. 또한 왜 성능이 중요한지, 어떠한 것들이 성능에 큰 영향을 끼치는지에 대해 자세히 알려주어서 실제 성능 개선시에 고려할 요소들에 대해 전체적으로 파악할 수 있을거라고 생각 되었습니다.

자바, 성능, 모니터링 - 2 - 자바

자바 성능 - 2

두번째 주제로는 자바가 어떻게 발전해온 역사와, 현재 Java의 흐름 , 그리고 OpenJDK에 관해 설명해 주셨습니다.

2-1. Agenda

  • Java Verions
  • OpenJDK

2-2. Java Version & Java History

  • Java History
    • Java Standard Edition 1.4 : 2002 (Code name Merlin)
    • Java Standard Edition 5.0 : 2004 (Code name Tiger)
    • Java Standard Edition 7.0 : 2011 (Code name Dolphin) - Oracle !
    • 세부적인 역사에 대한 설명은 해당 블로그 링크를 참조해 주세요.
  • Java 8
    • Lambda
    • Stream Interface
    • Default Method
    • LocalDate, LocalTime
    • Stream vs ParallelStream  => Stream을 쓰는 것이 더 좋다 ( ParallelStream은 해당 장비의 CPU 갯수만큼 Thread Pool을 만듬 )
  • Java 9
    • Compact Strings ( char[] -> byte[] )
    • G1 default GC
    • Java Platform Module System (Jigsaw) -> 거의 사용하지 않음
    • Collections of (불변) - List.of / Set.of / Map.of
    • StackWalker 
  • String BenchMark
    • String BenchMark Test 결과 (TPS)
  • Java 10
    • var 등장
    • Application Class-Data Sharing(AppCDS)
  • Java 11
    • Oracle JDK 유료화
    • Http Client
    • Applets, Web start , JavaFX 등 일부 모듈 삭제
  • Java 12
    • Switch Expression
    • break with Value

2-3. OpenJDK 

2-4 . 생각하는 세션의 소감평

소감평 : 사용하는 언어에 대해 파악하는 것은 매우 중요한 문제이고, 라이센스와도 직결되는 문제라면 이는 두말할 필요가 없습니다. 회사에서는 Java 11 LTS 이후의 Oracle로 갈건지, 아니면 OpenJDK로 갈지에 대한 판단과 더불어, 예전 레거시의 프로젝트는 8에서 멈춰있다면 그 이후의 버전으로 넘어갈때에 대한 판단 , 즉 두가지 판단에 대해 개발자가 이를 정해야 할 때에 어떤 점들을 고려하여 이를 택할지 파악할 수 있던 세션이었습니다.

자바, 성능, 모니터링 - 3 - 모니터링

자바 성능 - 3

세번째 주제로는 서비스에 대한 모니터링 도구들에 대한 설명 및 특징들과,  해당 도구들의 도입을 어떻게 해야 되는지에 대해 설명해주셨습니다.

3-1. Agenda

  • APM ( Application Performance Management )
  • Scouter

3-2. APM , BCI, Plguin Example

  • 해외에서 만든 APM
  • Dynatrace는 무려 250명이 함께 개발한 APM
  • Dynatrace는 Agent 설치가 되면 별도 설정 없이 자동으로 세팅을 해줌
  • 국내에서 만든 오픈소스 APM
  • 국내에서 만든 APM
  • Scouter와 Pinpoint 간의 장점 및 단점
  • Scouter
    • 실시간 모니터링이 Pinpoint에 비해  빠르고 원활함
    • Pinpoint에 비해 전체 뷰 보기가 조금 불편하고, 분산 저장이 상대적으로 어렵다. ( Zipkin을 쓰면 일부 가능 )
  • Pinpoint
    • Scouter에 비해 전체 뷰 보기가 편하고, 분산 저장이 상대적으로 쉬움
    • 다만 Scouter에 비해 실시간 모니터링 기능이 약함
  • APM의 핵심은?
  • BCI 도구
  • APM에서 서버간 호출 관계는 어떻게 추적하나?
    • HttpHeader를 이용하여 서버간 호출 관계를 추적한다.
  • Scouter에 관한 Core Graph Example
    • CPU, TPS, etc...
  • Plugin
    • Server Plugin ( Alert Plugin , Counter )
    • Agent Plugin (  httpservice.plug, etc.. )

3-3. FAQ

  • Q1: Pinpoint와 Scouter를 같이 사용할 수 있는가?
    • Scouter Committer Comment : 같이 사용 가능하다.
  • Q2: Scouter에 관한 문의는 어떻게 할 수 있는가?
  • Q3 : 모니터링 도구의 도입 시 Application에 부담이 올 수 있는데 어떻게 도입하면 되는가?
    • 해당 서버의 상황을 보고, 서버에 부담이 없다면 1대를 우선 도입한다.
    • 1대 도입 이후에 이상이 없다면 차근차근 해당 모니터링을 도입하는 서버의 갯수를 늘려야 한다.
    • 모니터링이 Application에 부담이 없는지 서버 도입 후 기간을 두고 관찰해야 한다.
    • Scouter Committer 또한 모집 중.

3-4 . 생각하는 세션의 요점과 소감평

요점 : 절대로 단정짓지 마라 ! 데이터로 이야기 하자 ! ( 함부로 해당 상황에 대한 판단이 아닌 , 테스트 및 모니터링을 통해 문제의 원인을 파악하고 이를 해결하자. )

소감평 : 서비스에 모니터링 도구들을 도입하려면 어떤 툴들이 있고, 어떤 기능들이 있는지 생각하게 됩니다.  해당 모니터링 도구들이 어떤것들이 있고 그러한 모니터링 도구들의 핵심이 무엇인지  파악할 수 있는 세션이었습니다. 개인적으로 Scouter 및 Pinpoint의 비교 부분과, Scouter에 대한 기능들의 예시 부분이 인상적이었습니다.  Scouter와 Pinpoint는 서로 상호 보완을 할 수 있기 때문에 두가지 동시에 도입을 하고, 모놀리틱한 서비스에는 Scouter가 더 좋다고 생각되었습니다.

4. 마치며..

자바 서비스를 하는 입장에서, 이번 우아한 세미나를 통해 자바의 역사와 현재 우리가 어떤 방향으로 Java Version을 택해야 하는지, 또한 Java 를 택했다면 성능에 어떠한 요소가 있고 그러한 요소들을 개선하기 위해서는 어떻게 해야할지, 그리고 이를 도와주는 모니터링 ( APM ) 도구들은 어떤 것들이 있는지에 대해 전체적으로 큰 줄기를 말씀해 주셨습니다.  하나의 서비스를 유지하고 이를 개선하는 것은 쉽지 않습니다. 하지만 이번 세미나를 통해 어떻게 고쳐야 되는지에 대한 방향을 잡을 수 있었던 것 같습니다. 해당 세미나를 해주신 이상민 수석님과 이러한 자리를 만들어주신 우아한 형제들에게 다시 한번 감사의 말씀을 드립니다.


Popit은 페이스북 댓글만 사용하고 있습니다. 페이스북 로그인 후 글을 보시면 댓글이 나타납니다.