달력

3

« 2024/3 »

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
.. .. ..

 

[펌 ] http://cafe.naver.com/anycallusershow/1803196

 

위 주소가 정리가 잘되있습니다^^

.
:
Posted by .07274.
.. .. ..

[펌] : http://helloworld.naver.com/helloworld/184615

[글쓴이] : NBP 웹플랫폼개발랩 박세훈

 

글이 상당히 좋아서 가져왔습니다. 문제가 될시에는 삭제를 하도록 하겠습니다.

 

이 글은 월간 "마이크로소프트웨어" 2012년 9월호에 "자바 애플리케이션 성능 튜닝의 도()"라는 제목으로 실린 글입니다. 편집 과정을 거치며 일부 내용이 책에 실린 내용과 다를 수 있습니다.


자바 애플리케이션의 성능을 튜닝하는 작업은 자바 및 JVM에 대한 지식과 수많은 튜닝 기법, 다양한 환경과 상황에 대한 경험 등을 필요로 한다. 그러나 이 모든 내용을 짧은 지면에서 소개하기에는 무리이니 이 글에서는 성능 튜닝 작업의 상세한 내용보다는 튜닝에 필요한 배경 지식과 튜닝 순서, JVM의 각종 옵션 및 튜닝 접근 방법 등의 간략한 소개를 통해 성능 튜닝의 전반적인 흐름과 방법론에 대해 살펴보도록 하자. 특히 자바 애플리케이션의 여러 도메인 중에서 인터넷 서비스를 위한 웹 애플리케이션에 중점을 두고 설명해나가겠다.

모든 애플리케이션이 튜닝을 필요로 하는 것은 아니다. 충분한 성능을 내고 있다면 굳이 추가적인 노력을 들일 필요는 없다. 하지만 방금 디버깅을 마친 애플리케이션이라고 해서 항상 목표 성능만큼 동작해 줄 것이라고 기대할 수는 없고 그렇게 기준치 이하로 성능이 미달될 때 튜닝이 필요해진다. 구현 언어에 상관없이 애플리케이션을 튜닝하는 것은 상당한 전문적인 지식과 높은 집중을 요구하는 일인데다, A라는 애플리케이션을 튜닝했을 때 사용했던 방법을 B라는 애플리케이션을 튜닝할 때 재활용할 수 있는 것도 아니다. 애플리케이션마다 고유한 동작이 있고 컴퓨터 자원을 사용하는 형태가 다르기 때문이다.

애플리케이션을 튜닝하기 위해서는 애플리케이션 작성 지식보다 좀 더 근본적이고 포괄적인, 예를 들면 버추얼머신이나 OS, 컴퓨터 아키텍처 등에 대한 지식이 필요하다. 이런 지식을 바탕으로 애플리케이션 도메인에 집중해야 수월한 튜닝이 가능하다.

자바 애플리케이션 튜닝이란 경우에 따라 GC 같은 JVM 옵션 값 변경만으로 충분할 수도 있고 아예 코드를 수정해야 할 때도 있다. 어느 방법을 선택하든 우선 자바 애플리케이션 수행 과정을 모니터링해야 한다.

그래서 이 글에서는 '어떻게 모니터링을 하는가', '어떻게 JVM 옵션을 주어야 하는가', '코드 수정 필요 판단은 어떻게 하는가'를 중심으로 살펴보도록 하겠다.

자바 애플리케이션 성능 튜닝에 필요한 지식

JVM상에서 동작하는 자바 애플리케이션의 튜닝을 위해서는 JVM의 동작 과정에 대한 이해가 필요하다. 여기서 말하는 JVM 동작 과정에 대한 지식이란 크게 Garbage Collection(이하 GC)에 대한 것과 HotSpot에 대한 지식을 꼽을 수 있다. 물론 GC나 HotSpot 지식만으로 모든 자바 애플리케이션에 대한 성능 튜닝을 할 수 있는 것은 아니지만 성능에 영향을 미치는 대부분의 요소는 이 두 가지에 속한다.

JVM의 원활한 동작 환경을 만들기 위해서는 OS가 각 프로세스에 자원을 분배하는 방식에 대한 이해가 필요하다. 자바 애플리케이션 성능 튜닝을 위해서는 JVM 자체는 물론 OS나 하드웨어에 대한 이해도 필요하다는 것이다. OS 관점에서 볼 때 JVM 또한 하나의 애플리케이션 프로세스라는 점을 염두에 두도록 하자. 덧붙여 자바 언어 도메인에 대한 지식도 중요하다. Lock이나 Concurrency에 대한 이해는 물론 클래스 로딩이나 객체 생성에 대한 지식 또한 중요도가 높다.

자바 애플리케이션 성능 튜닝을 할 때는 이러한 지식들을 종합해 접근해야 한다.

성능 튜닝 과정

<그림 1>은 찰리 헌트와 비아누 존 두 사람의 공동저서인 'Java Performance'에서 인용한 순서도로 자바 애플리케이션 성능 튜닝 과정을 표현한 것이다.

c51664a15481b6f135d9cc28f0344ea9.png

그림 1 자바 애플리케이션 성능 튜닝 과정

자바 애플리케이션 성능 튜닝 과정은 한 번에 통과하는 과정이 아니라 튜닝 완결까지 몇 번이고 계속 반복할 수도 있다. 기대 성능 수치 설정 또한 마찬가지다. 튜닝 과정을 통해 기대 성능 수치를 하향해야 할 때도 있고 오히려 기대 성능 수치를 상향할 때도 있다.

JVM 배포 모델이란 하나의 JVM에서 자바 애플리케이션을 동작시킬 것인지 여러 JVM에서 자바 애플리케이션을 동작시킬 것인지 결정하는 것으로 가용성, 응답 반응성, 관리 편의성 등에 따라 변경될 수 있다.

JVM이 여러 서버에서 동작하는 경우에도 한 서버에서 여러 개의 JVM을 동작하도록 하거나 서버마다 각각의 JVM을 동작하게 할 수도 있다.

물론 하나의 서버에 몇 개의 JVM이 동작할 것인가는 서버의 코어 개수와 애플리케이션의 특성 등에 따라 결정되겠지만 응답 반응성 관점에서 양자를 비교해볼 때, 같은 애플리케이션일 경우 2GB의 힙을 사용하는 경우가 8GB 크기의 힙을 사용하는 것보다 풀 GC에 걸리는 시간이 짧아 응답 반응성에 유리하다. 하지만 8GB 힙을 사용하면 2GB보다 풀 GC 발생 간격이 그만큼 줄어들 것이고 내부 캐시를 사용하는 애플리케이션이라면 히트율을 높여 응답 반응성을 높일 수 있다.

즉 하나의 장점을 선택했을 때 그 선택에 뒤따르는 단점을 극복할 수 있는 방법을 고려해야 적합한 배포 모델을 결정할 수 있다.

JVM 선택이란 32bit JVM을 사용할 것이냐 64bit JVM을 사용할 것이냐에 대한 결정이다. 동일 조건이라면 32bit JVM을 선택하는 것이 좋다. 32bit JVM이 64bit JVM보다 수행 성능이 좋기 때문이다. 32bit JVM은 논리적 최대 사용 가능 힙 크기가 4GB로, 이보다 큰 크기의 힙을 사용할 필요가 있을 때 64bit JVM을 사용하는 것이 좋다(단 32bit OS/64bit OS 모두 실제 사용 할당 크기는 2~3GB 정도다).

표 1 성능 비교 자료(출처 : http://www.readwriteweb.com/hack/2011/06/cpp-go-java-scala-performance-benchmark.php)

Benchmark

Time [sec]

Factor

C++ Opt

23

1.0x

C++ Dbg

197

8.6x

Java 64-bit

134

5.8x

Java 32-bit

290

12.6x

Java 32-bit GC

106

4.6x

Java 32-bit SPEC GC

89

3.7x

Scala

82

3.6x

Scala low-level

67

2.9x

Scala low-level GC

58

2.5x

Go 6g

161

7.0x

Go Pro

126

5.5x

이제 작성한 애플리케이션을 가동해 성능을 측정하자. 이 과정에서 시스템 모니터링 도구나 프로파일링 도구를 사용해 GC 튜닝, OS 설정 변경, 코드 수정 등의 작업을 한다.

응답 반응성을 위한 튜닝과 처리량을 위한 튜닝은 별개의 작업일 수 있다. 단위 시간당 처리량이 많더라도 풀 GC 등을 위해 때때로 긴 'stop the world' 현상이 발생한다면 응답 반응성이 낮아지게 된다. 또한 일정 부분 트레이드 오프가 발생할 수 있음을 고려해야 한다. 이런 트레이드 오프는 응답 반응성과 처리량 사이의 관계에만 있지는 않음을 염두에 두자. 적은 메모리 사용을 위해 CPU 자원을 더 사용해야 하거나 응답 반응성이나 처리량 손실을 감수해야 할 수도 있고 반대의 경우도 발생한다. 그러므로 우선순위를 설정해 접근해야 한다.

<그림 1>의 순서도는 Swing 애플리케이션을 포함한 포괄적인 자바 애플리케이션에 대한 성능 튜닝 접근 방법이기에 인터넷 서비스를 위한 서버 애플리케이션을 작성할 때는 적합하지 않다. <그림 1>을 바탕으로 인터넷 서비스에 맞는 절차를 만들면 <그림 2>와 같은 순서도가 된다.

855852fcee2754d34836a1a890b1409c.png

그림 2 인터넷 서비스 자바 애플리케이션 권장 튜닝 절차

<그림 2>를 참고해 각각의 절차를 수행하기 위해 필요한 일을 알아보도록 하자.

JVM 옵션

웹 애플리케이션 서버 위주로 JVM 옵션 지정 방법을 설명하겠다. 모든 경우라고 할 수는 없지만 대부분의 웹 서버 애플리케이션에서 가장 좋은 GC 알고리즘은 Concurrent Mark Sweep GC다. 이는 낮은 딜레이가 중요하기 때문인데, 물론 Concurrent Mark Sweep을 사용할 경우에는 fraction이 발생해 경우에 따라 매우 긴 Stop the World 현상이 발생할 수도 있다. 하지만 이 역시 New 영역의 크기나 fraction ratio를 조정해 해결할 수 있는 경우가 많다.

전체 힙 사이즈의 크기 지정만큼 New 영역의 크기 지정 또한 중요하다. XX:NewRatio 옵션을 이용해 전체 힙 크기 중 New 크기의 비율을 지정하거나 XX:NewSize 옵션을 사용해 원하는 크기만큼의 New 영역 크기를 지정하는 것이 좋다. 대부분의 객체는 생존 시간이 길지 않기 때문에 New 영역 크기 지정이 중요해진다. 웹 애플리케이션에서 캐시 데이터를 제외한 대부분의 객체는 HttpRequest에 대한 HttpResponse가 만들어지는 시간에 생성된다. 보통 이 시간은 1초를 넘지 않기에 객체의 생존 시간도 1초가 되지 않는다. 만약 New 영역의 크기가 크지 않다면 새로 생성되는 객체의 자리를 위해 Old 영역으로 이동돼야 하고 Old 영역에 대한 GC 비용은 New 영역에 대한 GC 비용보다 상당히 크기 때문에 충분한 New 영역 크기를 잡아줘야 한다.

다만 일정 수치 이상으로 New 영역의 크기가 커지면 오히려 응답 반응성이 떨어지는 문제가 발생할 수 있으므로 주의하자. New 영역에 대한 GC는 기본적으로 어느 한 서바이버 영역에서 다른 서바이버 영역으로 복사하는 것이기 때문이다. 또한 Old 영역뿐만 아니라 New 영역에 대한 GC를 할 때에도 Stop the World 현상은 발생한다. New 영역이 커지면 상대적으로 서바이버 영역의 크기도 커져 그만큼 복사해야 할 데이터의 크기도 늘어난다. 이런 특성을 감안해 New 영역의 크기를 정할 때는 HotSpot JVM의 OS별 NewRatio를 참고하는 것이 좋다.

표 2 OS와 옵션별 NewRatio

OS & option

디폴트 –XX:NewRatio

Sparc –server

2

Sparc –client

8

x86 –server

8

x86 –client

12

NewRatio를 지정하면 전체 힙 크기 중에서 1/(NewRatio + 1) 만큼이 New 영역의 크기가 된다. Sparc server의 NewRatio가 유독 작은 것을 알 수 있는데 기본값을 정하던 당시 x86보다 Sparc 시스템을 하이엔드 용도로 사용했기 때문이다. 요즘은 x86 서버 사용이 흔해졌고 성능 또한 향상됐기 때문에 Sparc server에 준하는 값인 2 또는 3 정도를 지정하는 것이 좋다.

NewRatio 대신 NewSize와 MaxNewSize를 지정할 수도 있다. NewSize에서 지정한 값만큼 New 영역이 생성됐다가 MaxNewSize에서 지정한 만큼 New 영역이 커진다. Eden이나 서바이버 또한 지정된 또는 기본 비율에 따라 같이 커진다. Xs와 Xmx 크기를 같게 하는 것처럼 NewSize와 MaxNewSize 또한 같게 지정하는 것이 좋다.

NewRatio와 NewSize를 지정했을 때는 둘 중 큰 값을 사용하기 때문에 힙이 생성됐을 때 최초의 New 영역의 크기는 다음과 같다.

min(MaxNewSize, max(NewSize, heap/(NewRatio+1)))

전체 힙과 New 영역의 적합한 크기를 한 번에 알 수는 없다. 웹 서버 애플리케이션을 기준으로 <표 3>과 같은 JVM 옵션으로 자바 애플리케이션을 가동해보는 것을 권한다. 이 옵션들로 성능을 모니터링한 후 더 적합한 GC 알고리즘이나 옵션으로 변경하자.

표 3 모니터링 후 옵션변경 예시

종류

옵션

동작 모드

-sever

전체 힙 크기

-Xms와 –Xmx의 값을 같게

New 영역 크기

-XX:NewRatio

2~4 정도의 값

-XX:NewSize=? –XX:MaxNewSize=?

NewRatio 대신 NewSize를 지정하는 것도 좋다.

Perm 크기

-XX:PermSize=256m

-XX:MaxPermSize=256m

성능에 영향을 미치지 않으므로 동작에 문제가 없을 정도만 지정한다.

GC 로그

-Xloggc:$CATALINA_BASE/logs/gc.log

-XX:+PrintGCDetails

-XX:+PrintGCDateStamps

GC로그를 남기는 것은 특별히 Java 애플리케이션 수행 성능에 영향을 미치지 않는다. 가급적이면 GC 로그를 남기는 것이 좋다.

GC 알고리즘

-XX:+UseParNewGC

-XX:+CMSParallelRemarkEnabled

-XX:+UseConcMarkSweepGC

-XX:CMSInitiatingOccupancyFraction=75

일반적으로 권할만한 설정일 뿐이다. 애플리케이션 특성에 따라 다른 선택이 더 좋을 수 있다.

OOM 에러 발생 시 힙 덤프 생성

-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=$CATALINA_BASE/logs

OOM 발생 이후 조치

-XX:OnOutOfMemoryError=$CATALINA_HOME/bin/stop.sh

또는

-XX:OnOutOfMemoryError=$CATALINA_HOME/bin/restart.sh

힙 덤프를 남긴 뒤, 관리 정책에 맞게 적합한 동작을 취할 수 있도록 한다.

애플리케이션 성능 측정

애플리케이션 성능을 측정하기 위해 파악해야 할 정보는 다음과 같다.

  • TPS(Transaction Per Second)/OPS(Operation Per Second): 개념적으로 해당 애플리케이션의 성능을 이해하는데 필요한 정보다.
  • RPS(Request Per Second): 엄밀한 의미에서 응답 반응성과는 다르지만 RPS를 응답 반응성으로 이해해도 큰 무리는 없다. 사용자가 원하는 결과를 보기 위해 기다려야 하는 시간을 알 수 있다.
  • RPS 표준편차: 가급적 고른 RPS가 나오도록 할 필요가 있다. 편차가 발생한다면 GC 튜닝이나 연동 시스템에 대한 점검이 필요하다.

정확한 성능 수치를 위해 충분히 워밍업된 상태에서 측정하는 것이 필요하다. HotSpot JIT에 의해 바이트 코드가 컴파일된 상태가 되기를 기대하기 때문인데, nGrider를 이용해 통상 10분 이상 특정 기능에 대한 부하를 준 뒤 성능 수치를 측정하는 것이 좋다.

본격적인 튜닝

본격적으로 사례별 접근 방법을 알아보자.

Stop the World 시간이 길다

Stop the World 시간이 긴 이유는 적합하지 않은 GC 옵션 때문일 수도 있지만 잘못된 구현 때문일 수도 있다. 프로파일러나 힙 덤프 결과를 통해 힙을 차지하고 있는 객체의 종류와 생성 개수를 확인해보고 적합여부를 판단한다. 불필요한 객체가 많이 생성돼 있다면 코드를 수정하는 것이 좋다.

객체 생성 과정에 특별한 문제가 없다면 GC 옵션을 변경하자. 적합한 GC 옵션 조정을 위해서는 충분한 시간 동안 확보한 GC 로그가 필요하다. 어떤 상황에서 긴 Stop the World가 일어나는지 파악하자.

GC는 객체를 얼마나 많이 생성하느냐보다는 생성된 객체가 얼마나 오래 남아있는가가 더 중요하다. 즉 객체가 보다 빨리 GC 대상이 될수록 Stop the World 시간은 줄어들 가능성이 높다.

객체가 빨리 GC 되게 만드는 팁은 다음과 같다.

  • 객체의 크기를 가급적 작게 유지한다.
  • Collection이나 기타 Container 형태의 자료구조 안에서 배열의 크기를 변경하는 작업은 가급적 피하자.
  • SoftReference는 사용하지 않는 게 좋다.

CPU 사용률이 낮다

TPS가 낮은데 CPU 사용률도 낮다면 blocking time이 원인이다. 이 경우 연동 시스템의 문제나 동시성(concurrency) 문제일 수 있다. 스레드 덤프 결과 분석이나 프로파일러를 이용해 확인할 수 있다. 상용 프로파일러를 이용하면 매우 정밀한 lock 분석을 할 수 있지만 대부분의 경우 jvisualvm에 있는 CPU 분석만으로도 충분한 결과를 얻을 수 있다.

CPU 사용률이 높다

TPS가 낮은데 CPU 사용률만 높다면 효율적이지 못한 구현 때문일 가능성이 높다. 이 경우 프로파일러를 이용한 병목 지점 파악이 유효하다. jvisualvm이나 eclipse의 TPTP, JProbe 등을 이용해 분석하자.

튜닝 접근 방법

애플리케이션을 튜닝할 때는 먼저 성능 튜닝이 필요한지 파악해야 한다. 성능 측정 과정은 매우 고되고 언제나 좋은 결과를 얻을 수 있다는 보장도 없기 때문에 충분한 목표 성능을 만족하고 있다면 굳이 튜닝을 하지 않는 것이 효율적이다.

  • 문제는 단 한 곳에 있고 그 하나만 수정하면 된다:
    파레토 이론은 성능 튜닝에도 적용된다. 문제는 반드시 하나라는 의미보다는 가장 성능에 영향을 미치는 하나에만 집중해 접근할 필요가 있다는 뜻으로 해석하자. 하나에 집중해서 해결하고 난 다음에 다른 문제 해결을 위해 노력하도록 하자.
  • 풍선 효과:
    무엇을 얻기 위해 무엇을 포기해야 하는지 결정해야 한다. 캐시를 적용해 응답 반응성을 높일 수는 있지만 캐시의 크기가 커지면 풀 GC 시간이 길어질 수 있다. 적은 메모리 사용량을 선택하면 대개 처리 용량이나 응답 반응 시간이 나빠진다. 하나를 선택하면 하나를 포기해야 한다는 것을 염두에 두고 우선순위를 정해 선택하자.

여기까지 자바 애플리케이션 성능 튜닝 방법을 정리해 봤다. 성능 측정에 대한 구체적인 절차를 만들다보니 세부적인 정보를 제외하고 설명하기도 했지만 자바 웹 서버 애플리케이션을 튜닝하기 위한 대부분의 경우는 만족시킬 수 있을 것이라 생각한다.

참고: 성능 튜닝 도구

성능 튜닝 작업을 위해서는 Java 애플리케이션의 성능을 측정하고 실행 상태를 모니터링할 다양한 도구가 필요하다. JDK에 내장된 명령 도구인 jstat, jmap, jstack, jhat도 유용하지만 그 외에도 다양한 도구가 있어 소개한다.

프로파일링 도구

JProbe, Yourkit 등의 상용 제품이 유명한데 대부분의 프로파일링 도구는 상용제품으로, 오픈소스나 공개된 프로파일링 도구는 거의 없는 형편이다.

  • Eclipse TPTP: 현재는 개발이 중단된 상태이나 공개된 프로파일링 도구 중 꽤 쓸만한 편이다.
  • JVisualVM: JDK에 포함된 기본 도구로 GC 분석, 힙 덤프 및 스레드 덤프 생성, 스레드 모니터링 등의 다양한 용도로 사용할 수 있다. 내장된 샘플러 도구를 통해 간단한 프로파일링이 가능하다.

성능 측정용 도구

성능 측정용 도구로는 HP의 LoadRunner가 가장 유명하다. 그러나 상용제품으로 꽤 비싼 가격이므로 본문에서 언급한 nGrinder를 소개한다.

  • nGrinder: NHN에서 제작해 공개한 오픈소스로 기존 오픈소스 성능 측정 도구인 Grinder의 불편한 점을 보완하고 통합 환경을 제공한다.

GC 로그 분석 도구

본문의 <표 3>처럼 GC 로그를 남겼다면 다양한 GUI 도구를 이용해 GC 추이를 분석할 수 있다.

  • Hpjmeter: HP에서 개발 배포하는 자바 성능 분석 도구로 Heap Dump 분석, 모니터링 등의 여러 기능을 가지고 있는 멀티툴이지만 GC 로그를 매우 깔끔하게 보여주므로 GC 로그 분석기로도 사용하기 좋다.
  • GC Viewer: 오픈소스로 개발된 GC 로그 뷰어다.
  • IBM Pattern Modeling and Analysis Tool for Java Garbage Collector: IBM developerworks에서 개발해 공개한 GC 로그 뷰어다.
  • JVisualVM의 VisualGC plugin: JVisualVM 내에 탑재된 GC 모니터링 플러그인이다. 현재의 GC 동작을 모니터링하기에 유용하다.

힙 덤프 분석 도구

Stop the World 시간이 길거나 기타 이유로 성능이 나쁘다고 여겨질 때 힙 덤프를 얻어 분석하는 것도 효과적이다.

  • Eclipse Memory Analyzer: 흔히 이클립스 MAT이라고 부르는 이클립스 기반의 메모리 분석기다. 이클립스 플러그인으로 설치해 사용할 수도 있고 이클립스 RCP로 된 스탠드 얼론 프로그램으로 사용할 수도 있다.
  • IBM HeapAnalyzer: IBM developerworks에서 개발해 공개하고 있는 힙 메모리 분석기다.

 

.
:
Posted by .07274.
.. .. ..

[펌] : http://www.mimul.com/pebble/default/2012/07/18/1342602654675.html

 

푸시 서버를 구축하는 분들이라면 Urban Airship 블로그를 관심있게 볼 필요가 있습니다. 푸시 서버 구축에 대한 시행착오나 튜닝 정보들을 포스팅하고 있어 도움이 될법한 콘텐츠들이 많습니다.
그 중 오늘은 "C500k in Action at Urban Airship"이란 아티클을 의역해 봅니다.

2000년쯤에는 c10k라는 문제(동시접속 만개를 해결하는 문제)가 주로 화두였는데, 현재는 c500k 도 이미 해결된 상태죠. Urban Airship의 경우를 본다면.. 물론 동접자수가 많은 것과 성능은 성질이 다르지만, 푸시같은 경우 지속적인 트래픽 처리도 중요하지만, 이벤트 캐치를 해 푸시 딜리버리 보장을 위해 영속성 있는 연결 구조의 특성을 가져가는 것도 중요해 보이네요.
그리고 이 글 다음으로 읽어야 할 것이 바로 "Linux Kernel Tuning for C500k"입니다. 커널 튜닝도 꼼꼼히 살펴봐야죠.

자, 그럼 내용으로 들어가 봅니다.

안드로이드용 AirMail 푸시 플랫폼 구축기

우리는 안드로이드용으로 AirMail Push 플랫폼을 구축중에 있고 이 플랫폼은 동시 접속 디바이스 수가 수백만을 처리할 수 있는 서버 사이드 인프라를 지원해야 한다. 애플의 iOS platform상의 푸시와 같이 안드로이드용 AirMail은 실시간으로 메세지를 푸시하기 위해서 서버와 클라이언트간에 연결 지향의 소켓 통신을 유지하고 있다.
이것은 서버 사이드에서 수십만 영속성 있는 소켓 통신 처리, 네트워크 끊기거나 네트워크에 재 연결된, 그리고 네트워크가 교환된 사용자의 경우처럼 클라이언트측의 연결 관리가 필요하고, 사용되지 않는 네트워크 감지하고 연결을 닫는 등의 복잡한 처리가 필요하다.

이 아티클은 서버 기반의 푸시 인프라 스트럭처를 구축하면서 직면했던 도전들을 설명한다. 어떻게 Java NIO 기반에 스레드/이벤트/큐 기반의 하이브리드형으로 재 설계하고 구현한 내용들이다.

많고 많은 소켓들

디바이스에 푸시 노티를 하기 위해서는 영속적인 소켓 연결을 가져가야 한다. 우리의 플랫폼은 디바이스의 동접이 수백만에 이르는 가용성이 필요했다. 그것은 서버 시스템의 스택과 소프트웨어는 각 노드가 수많은 동시 연결을 유지하면서 메세지를 받고 푸시 노티를 우아하게 수용할 필요가 있다. 중요한건 이들을 처리하는데 얼마나 많은 노드들이 필요한가?이다.
한 노드가 10,000 클라이언트를 지원한다면 벤처로서는 엄두도 못낼 비용을 감당해야 한다. 즉, 100만 디바이스를 수용할려면 100대의 서버가 필요하다는 이야기다.

초기에는 python의 Eventlet을 사용해 구현하면서 미지의 영역에서 벤처를 시작했다. Eventlet은 경량의 코루틴을 통해 병렬처리를 지원하는 환상적인 라이브러리다. Eventlet은 개발자들로 하여금 소켓 구현을 통해 대량의 접속을 쉽게 관리하고 수용할 수 있도록 해준다. 그리고 쓰레드 기반 서버와 달리 컨텍스트 전환이 쉽고 오버헤드가 적다. 그렇게 해서 Helium이라는 첫번째 엣지 서버가 탄생했다.

Eventlet기반의 초기 Helium 코드는 이해하기 쉽고 깨끗하고 심플했다. 우리는 Python도 좋았고, Eventlet 같은 라이브러리를 창출한 Python 커뮤니티도 마음에 들었다. Eventlet 기반 초기 Helium 성능은 EC2 하나의 인스턴스에서 사용할 메모리 1.7GB을 상한으로 설정하고 응용 프로그램 수준에서 keep-alive를 유지할 수 있는 조건으로 37,000 클라이언트를 수용했다. 숫자(성능)는 일단 만족하지만, 우리가 필요로하는 가용성을 수용하려면 많은 인스턴스가 필요로하게 된다. 이것은 돈이 많이 필요하다는 이야기가 된다.
우리는 성능적으로, 보안적으로, 때론 안정적인 플랫폼을 구축하기 위해 지속적으로 인프라스트럭처에 투자를 하고 있고, 우리는 인프라 관리자라기보다는 더 좋은 프로그래머들이고 싶고 성능과 비용 효율면에서 좋은 소프트웨어를 만들고 싶다.

바다 괴물처럼 엄청나 보이는 보이는 것들

우리는 (Eventlet기반의 초기 Helium보다) 매우 효율적인 소켓 서버 프로토타입을 구축하기 위해 탐구를 시작했다. 우리는 다양한 옵션들을 고려했다. C++기반의 [e]poll, 스레드/이벤트 기반 java나 scala구현, Node.js, 그외 다른 것들도 시도를 해봤다. 예상대로 순수 스레드 기반의 자바는 동시 연결 수가 수천대가 되면 쓸모없게 되고 C기반의 구현은 너무 저수준이어서 구현이 힘들고 프로젝트의 변화에 따라가지 못한다는 것이 판명되었다.

Java NIO(new/non-blocking IO) 라이브러리를 가지고 실험한 내용이 좋아서 아래의 세가지 경우를 가지고 다양하게 검증해 보았다.

  • 순수 자바 NIO 구현.
  • Netty에 NIO 얹은 구현.
  • Scala버전 Netty에 NIO 실은 구현.

위 세가지를 가지고 동시 연결 수와 메모리 효율성 관점에서 두 결과는 이전의 결과를 능가했다.

벤치 마크 1. 최대 동시 연결 수

구현안 연결수 메모리 사용량
Java Pure NIO 512,000 + 2.5 GB
Java w/Netty 330,000 2.2 GB
Scala w/Netty 173,000 1.5 GB

벤치 마크 2. 연결 당 메모리 효율성
구현안 연결수 메모리 사용량 Delta
Java Pure NIO 80,000 + 581 MB 1x
Java w/Netty 80,000 711 MB 1.3x
Scala w/Netty 80,000 937 MB 2.26x

열심히 하지 않았지만, 영리하게 작동했다.

EC2의 작은 인스턴스에 각 노드당 35,000개의 연결수였던 것이 512,000개까지 증가되었다. 이는 효율성, 인프라스트럭처 비용, 관리의 오버헤드 관점에서 크게 향상되었다. 각 노드당 동시 연결수는 Eventlet 기반 초기 Helium의 약 15배 향상되었다.
너무 일찍 터트린 샴페인일 수 있으나, NIO 플랫폼으로 구현된 우리의 애플리케이션 로직, keepalives, 메세지 통신을 구현한 뒤에서 전례없는 테스트 결과가 나왔다.

곁가지지만, Java+Netty나 Scala+Netty의 경우 드문 경우지만, Java 프로세스가 CPU 100%를 쳤는데도 콘솔에는 아무것도 출력되지 않았다. 이것은 예외상황에 노출되었으나 타이트한 무한 루프에서 예외상황을 방관하지 않았나 생각된다.(병목현상?)

이들 숫자를 바탕으로하여 우리는 Java + Pure NIO 구현을 밀어붙일 것이다. 그리고 계속 지켜봐주시기 바랍니다. 우리는 NIO구현과 관련된, 우리의 방법론이나 측정치에 대한 많은 정보들, 우리가 도중에 배운 것들, 우리가 피할수 있었지만, 곤란했던 상황들의 몇가지 포스트를 올릴 것이다.

Urban Airship의 푸시 아키텍처

참고로 Urban Airship의 아키텍처에 이해를 돕고자 추가한 단락이다. "Scaling Urban Airship’s Messaging Infrastructure to Light Up a Stadium in One Second" 아티클을 참고하여 작성했다.



  • Push Tag & Broadcast Service(codenamed Metalstorm) : 애플리케이션, 디바이스, 태그 사이의 연관 관계를 관리한다. 이 새로운 서비스는 매우 높은 푸시 처리량을 지원하고 수평적으로 확장 가능한 아키텍처를 통해 수억대 사용자를 가진 앱을 위해서 복잡한 태그 쿼리 수행을 지원한다.
  • Segments Data Storage(codenamed Penelope) : 고객의 위치 데이터를 포함한 공간 정보 질의에 최적화된 분산 데이터 베이스.
  • Message Routing Service(codenamed Gooey ButterCake) : 다양한 이기종 시스템을 엮어 질의를 통해 결과를 조합하기 위해서 소팅-머징-조인 알고리즘을 사용하는 라우팅 계층이다. 애플리케이션 태그와 디바이스 위치 정보를 조인하는 것이 한 예이다.
  • Edge Message Delivery Service(codenamed Yaw) : 높은 처리량과 낮은 지연 시간을 가진 APNS와 같은 3rd Party 푸시 프로바이더들에게 last-mile(푸시 수신 인프라와 디바이스 사이의 접점) 배달 처리를 한다. Yaw는 수십만의 연결 모두가 메세지 배달을 수행하도록 하는 TLS 협상, TTL 메세지, 프로토콜 준수 등을 관리한다.
.
:
Posted by .07274.
.. .. ..
[펌] : http://surpreem.wordpress.com/2011/07/01/sw-%EA%B0%9C%EB%B0%9C-%EA%B8%B0%EB%B0%98-%EC%8B%9C%EC%8A%A4%ED%85%9C-%EA%B5%AC%EC%84%B1-6-ci-%EC%84%9C%EB%B2%84-%EC%84%A4%EC%B9%98/

이 글은 S/W 개발에 가장 기본이 되는 이슈 추적(Issue Tracker), 버전 관리(Version Control), 빌드(Build), 지속적인 통합(CI) 시스템을 구성하는 방법에 대한 일련의 글 중 여섯 번째이다. 지난글에서 빌드 스크립트를 구성했으므로 이를 활용할 CI 서버를 설치하고 구성해 본다.

1. 미리 준비해야 하는 것들

  • CI 시스템은 Jenkins(젠킨스)를 사용한다. 여기에서 윈도용 설치 파일을 받을 수 있다.
  • Jenkins를 실행하려면 Java(자바) 런타임이 필요하다. SE 버전으로 설치하면 되며 여기에서 받는다.

2. 설치

Java 런타임을 먼저 설치하고 환경 변수에 다음 내용을 추가한다.

 
1 JAVA_HOME=C:\Program Files (x86)\Java\jdk1.6.0_26
2 CLASSPATH=.
3 Path=%JAVA_HOME%\bin

Jenkins를 설치하면 자동으로 서비스까지 등록한다. 기본 포트는 8080이므로 http://plab.net:8080으로 접속해 첫 화면이 뜨면 정상이다. 정상적으로 접속할 수 있으면 Apache 웹 서버를 통해 접속하도록 변경한다.

Apache 웹 서버 httpd.conf 파일에 다음 내용을 추가한다.

01 LoadModule proxy_module modules/mod_proxy.so
02 LoadModule proxy_http_module modules/mod_proxy_http.so
03
04 ProxyRequests Off
06 Order deny,allow
07 Allow from all
08 </Proxy>
09 ProxyPass /jenkins http://127.0.0.1:8080/jenkins
10 ProxyPassReverse /jenkins http://127.0.0.1:8080/jenkins

Jenkins 설치 디렉터리에 있는 jenkins.xml 파일 내용 중 <arguments> 항목에 다음과 같이 --prefix=/jenkins를 추가한다

<arguments>-Xrs -Xmx256m -Dhudson.lifecycle=hudson.lifecycle.WindowsServiceLifecycle -jar "%BASE%\jenkins.war" --httpPort=8080 --prefix=/jenkins</arguments>


Jenkins와 Apache 웹 서버를 모두 중지 후 새로 시작한 다음 http://plab.net:8080 대신 http://plab.net/jenkins로 접속하면 된다.

3. 설정

먼저 메일 전송 설정은 Manage Jenkins – Configure System 선택 후 E-mail Notification 항목을 채운다. 인증이 필요하면 Advanced 버튼을 누르면 된다.

Jenkins E-mail Notification

설정을 계속하기 전에 플러그인을 설치한다. Manage Jenkins – Manage Plugins를 선택한 후, ‘Available’ 탭에서 필요한 것을 선택하면 된다. 우선 NAnt, Mercurial 플러그인을 선택하고 그 외 필요에 따라 추가 선택하면 되겠다. 선택 후에는 화면 가장 아래에 있는 Install 버튼을 누르면 된다. 만약 인터넷에 연결할 수 없다면 여기에서 확장자가 hpi인 플러그인 파일을 받은 후, Manage Plugins 메뉴에서 ‘Advanced’ 탭을 선택하고 Upload Plugin에서 직접 선택해 설치할 수도 있다. 플러그인을 설치한 후에는 재시작해야 한다.

이제 Manage Jenkins – Configure System을 선택하면 Mercurial과 Nant Builder 항목을 볼 수 있다. 먼저 NAnt부터 설정한다.

Nant Builder 항목에서 Add 버튼을 누른다. 이름은 적당히 주면 되고 NANT_HOME에는 NAnt 설치 경로를 입력한 후 가장 아래에 있는 Save 버튼을 눌러 저장한다. 여기서 지정한 이름은 빌드 프로젝트 설정에서 사용한다.

Jenkins Nant Builder

Mercurial은 다음처럼 설정한다. Manage Jenkins – Configure System을 선택하고 Mercurial 항목에서 Add Mercurial 버튼을 누른다. 이름은 적당히 지정하면 되는데 여기서 지정한 이름은 빌드 프로젝트 설정에서 사용한다. 이전 글에 따라 설치했으면 python 패키지를 설치했을 것이므로 설치 위치를 따로 지정하지 않고 실행 파일만 지정하면 된다. 설정 후 가장 아래에 있는 Save 버튼을 눌러 저장한다.

Jenkins Mercurial

권한 설정은 Manage Jenkins – Configure System – Enable security 항목을 선택한다. OpenLDAP을 사용하므로 Access Control 항목에서 Security Realm은 LDAP을 선택하고 Advanced 버튼을 누른다. 각 항목은 다음과 같이 설정한다.

Jenkins Security Realm

Access Control 항목에서 Authrization은 Project-based Matrix Authrization Strategy 또는 Matrix-based security를 선택한다. Project-based는 Matrix-based에 추가로 프로젝트별로 접근 권한을 설정할 수 있다. 저장하기 전에 모든 권한을 가진 관리자 계정을 입력 후 Add 버튼을 눌러 추가하고 권한을 설정한다. 그러지 않으면 로그인 할 수 없으니 주의한다. 또한 인증으로 OpenLDAP을 사용하므로 추가하는 계정은 OpenLDAP에 추가한 계정이어야 한다.

또는 OpenLDAP에 Jenkins 관리자 그룹을 만들고 이를 사용할 수도 있다. DN이 cn=jenkinsadmins, ou=Groups, dc=plab, dc=net인 jenkinsadmins 그룹을 만들고 멤버를 추가한다. 이 그룹 정보를 Jenkins에서 사용할 때는 cn(common name)을 대문자로 쓰고 ROLE_을 접두어로 붙인다. 즉 ROLE_JENKINSADMINS가 된다. 이를 추가하고 권한을 설정한다. 필요에 따라 다른 그룹도 이처럼 설정한다.

Jenkins Authorization

설정 후 저장하면 자동으로 로그오프 되는데, 혹시 권한 설정을 제대로 못한 상태에서 로그인 할 수 없게 되면 Jenkins\config.xml 파일 내용에서 다음 내용을 찾아 false로 바꾼 후 Jenkins 서비스를 재시작한다. 이후에 권한 설정을 새로 하면 된다.

1 <useSecurity>true</useSecurity>

3. 작업 만들기

빌드를 하려면 작업(job)을 만들어야 한다. New Job을 선택하고 Job name에 이름을 지정한 후 Build a free-style software project를 선택한다. 지정 후 OK 버튼을 선택하면 작업을 만든다.

Jenkins New Job

해당 job에 대한 빌드 설정을 한다.

Advanced Project Options 항목에서 Advanced 버튼을 누르면 상세 내용을 볼 수 있다. 저장소에서 파일을 받아 빌드할 위치를 지정하려면 Use custom workspace를 선택하고 Directory를 지정하면 된다. 경로는 서버 내 위치이다.

Jenkins Advanced Project Options of the Job

빌드에 사용할 파일을 저장소에서 받기 위해 Source Code Management 항목을 설정한다. Mercurial Version 항목은 이전에 Configure System 메뉴에서 설정한 Mercurial 항목 이름이다.

Jenkins Source Code Management of the Job

Build 항목에서 Add build step 버튼을 누르면 빌드 단계를 추가할 수 있다. 여러 단계를 거쳐야 하면 차례로 추가해 설정하면 된다. 이전 글에서 빌드 스크립트를 배치 파일로 구성했으므로 Execute Windows batch command를 선택한다. 경로는 workspace를 루트로 한 상대 경로로 지정했다.

Jenkins Build of the Job

.\build\vc6_build.bat /f:.\build\vc6.build.xml clean build -D:server=yes -D:product_major=1 -D:product_minor=1 -D:product_patch=1

빌드를 마친 후 처리할 내용은 Post-build Actions 항목에서 설정한다. 여기서는 E-mail Notification을 선택한다. 메일 주소는 Recipients에 빈칸으로 구분해 적으면 된다.

Jenkins Post-build Actions of the Job

설정을 마쳤으면 화면 가장 아래에 있는 Save 버튼을 눌러 저장한다.

빌드가 정상적으로 되는지 확인한다. 첫 화면 또는 해당 프로젝트 화면에서 Build Now 아이콘을 선택하면 즉시 빌드를 할 수 있다. 빌드 상태는 날씨 아이콘으로 쉽게 파악할 수 있는데 실패 정도가 많을수록 날씨는 더 나빠진다.

Jenkins Dashboard

빌드를 실패했을 때는 진행 상황을 확인해야 한다. 첫 화면의 dashboard에서 날씨 아이콘을 선택하면 가장 최근 빌드 내용을 볼 수 있는데 여기서 Console Output을 선택하면 된다. 또는 해당 프로젝트에서 Build History – Console Output을 선택해도 된다.

Jenkins Build Console Output

참고: 빌드 스크립트에는 Visual Studio 환경 변수를 사용해 호출하는 부분이 있다. 명령 행에서 빌드할 때는 문제 없으나 Jenkins에서는 이 환경 변수를 인식하지 못해 실패한다. 이 때는 Jenkins 서비스를 관리자 계정으로 실행하도록 바꾸면 된다. 빌드 도중 Visual Studio 컴파일러나 링커 등에서 실패할 때도 이렇게 해결할 수 있다. 실행 계정을 바꾼 후에는 서비스를 정지 후 다시 실행하면 된다.

Jenkins Service Logon Account

빌드가 정상적으로 되는 것을 확인했으면 이제 자동으로 빌드하도록 설정한다. Build Triggers 항목에서 Build periodically나 Poll SCM을 선택한다. Build periodically는 지정 주기가 되면 빌드하는 것이고 Poll SCM은 일정 주기로 저장소에 변경 내용이 있는지 확인 후 있으면 빌드한다. 모두 Schedule에 주기를 지정하는데 프로젝트 성격에 따라 적절히 조절한다. 아래는 매 30분마다 확인 후 변경 내용이 있으면 빌드하는 예이다. 실제 적용은 10분마다 확인하도록 했으며 프로젝트별 설정 – Mercurial Polling Log에서 기록을 확인할 수 있다.

Jenkins Build Triggers

기본적인 설정은 모두 마쳤으나 추가로 이메일 발송 기능을 확장해 보자.

Email-ext 플러그인을 설치하고 Manage Jenkins – Configure System을 선택하면 Extented E-mail Notification 항목을 볼 수 있으며 모든 프로젝트에 적용한다. Override Global Settings를 선택하고 이전에 E-mail Notification에 적은 내용을 여기로 옮긴다.

Jenkins Extended E-mail  Notification

프로젝트별 설정 화면에서도 Post-build Actions에서 Editable Email Notification 항목이 생기며 프로젝트별로 적용한다. 이 항목을 선택하고 이전에 선택한 E-mail Notification은 선택 해제한다. OpenLDAP 계정에 mail 정보를 추가하면 로그인할 때 자동으로 메일 정보를 가져와 사용한다. 필요에 따라 메일 수신 목록을 Recipient List에 직접 추가해도 된다. 또한 프로젝트저장소에 커밋하면 해당 계정 정보를 자동으로 가져 온다. 또한 Email-ext 플러그인을 설치하면 Jelly script를 사용할 수 있으며 Default Content 내용을 꾸밀 수 있다. 자세한 내용은 플러그인 설명을 참고한다.

Jenkins Editable E-mil Notification of the Job

.
:
Posted by .07274.
2011. 8. 11. 16:02

제주 고미중 I.news()/I.news(etc)2011. 8. 11. 16:02

.. .. ..


성이시돌목장
곶자왈 (동백동산) //별로
곽금 올레길
사려니 숲길 // 땡김
조근모살(하얏트산책로)
한남해변
오월의 꽃 (무인카페)
돌문화공원
어승생 오름
협재?!


산지등대
두멩이 골목

먹거리
방주할머니식당
성산 오일장


잠잘곳
오신생 할망네 (2인 2만)
영등 현동순 할망집(

.
:
Posted by .07274.
.. .. ..
세계적인 네트워크 장비업체 시스코 본사에서 근무하는 최준형(가명, 40) 씨는 얼마 전 미국 시민권을 획득했다. 그의 정식 직함은 소프트웨어 팀의 'Research Manager'. 음성패킷망(VoIP) 개발부서의 개발팀장격이다. 한국에서 그와 비슷한 직군에 종사하는 이들은 '개발자'불린다. 하지만 이들은 스스로를 '노예'나 '막노동자'로 분류하며 자조하곤 한다.

사람들이 알아주는 명문대 공대를 졸업해 내로라하는 대기업에서 프로그래머의 경력을 시작했던 최 씨 역시 한국에서 개발자로 살면서 얻은 환멸을 뒤로 하고 미국행을 택했다.

"주말도 없이 일했죠. 알아서 나오는 거예요. 처음 3년 동안은 추석, 설날 당일 빼곤 쉬지 않고 출근했어요. 매일 아침 8시부터 밤 11시까지 일하는 건 기본이었고요. 밤 새는 것도 부지기수였죠. 6년 동안 이렇게 살다가 얻은 게 과로였어요. 저는 신장과 에 이상 진단 받았었고요, 스트레스성 장염이나 위장병으로 쓰러지는 동료도 허다했어요. 이런 일 이쪽 업계에선 당연한 일이에요."

------------------------------------------------------------------------------------------------------------------

http://www.pressian.com/article/article.asp?article_num=30100810150825&section=02

------------------------------------------------------------------------------------------------------------------

난 그래도 이정도는 아니니까 다행이라 생각하지만 같이하는 '을' 이나 '병'을 보면 나역시도
이 빌어먹을 노인네 CEO 들의 개념없는 회사 방침에 치를 떤다. 시대가 바뀌고 세대가 바뀌는 과도기에 있는
이쪽 업계는 아직도 5년동안은 개발자들의 피를 빨아먹으며 살아갈것이다.

후회하기 전에 정신좀 차렸으면...
.
:
Posted by .07274.
2010. 3. 15. 19:40

MIX10, 3월 15일 시작 I.news()/I.news(it)2010. 3. 15. 19:40

.. .. ..



Channel 9 라이브 중계
http://channel9.msdn.com/posts/NicFill/Channel-9-Live-at-MIX10--Who-What-Why-When-and-How/
• 3월 15일 월요일 : 10:30AM - 5:30PM (태평양 표준시)
• 3월 16일 화요일 : 10:30AM - 5:30PM (태평양 표준시)


라이브 중계
http://live.visitmix.com/

주요 발표 내용은 IE9 CTP, Windows Live Essentials 4 Beta 그리고 Windows Phone 7 Series입니다.

http://windowsteamblog.com/blogs/windowsexperience/archive/2010/03/15/mix10-begins-tomorrow.aspx 

 
ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ

드디어 시작하는구나.
키노트도 하나둘 올라오기 시작하고...

Windows Phone 7 Series

날 두근대게 해주렴^^



 

.
:
Posted by .07274.
.. .. ..


법정 스님께

언제 한번 스님을 꼭 뵈어야겠다고 벼르는 사이 저도 많이 아프게 되었고 스님도 많이 편찮으시다더니 기어이 이렇게 먼저 먼 길을 떠나셨네요.

2월 중순, 스님의 조카스님으로부터 스님께서 많이 야위셨다는 말씀을 듣고 제 슬픔은 한층 더 깊고 무거워졌더랬습니다. 평소에 스님을 직접 뵙진 못해도 스님의 청정한 글들을 통해 우리는 얼마나 큰 기쁨을 누렸는지요!

 

http://news.nate.com/view/20100311n14312

.
:
Posted by .07274.
.. .. ..
연인과 오랜 시간 함께 하며 로맨틱한 관계를 유지한 커플일수록 서로 헤어진 뒤 혼자가 됐을 때 “난 대체 누구인가?”에 대한 혼란 때문에 더 힘겨워한다는 연구결과가 나왔다.

http://news.nate.com/view/20100309n04535?mid=p0703&isq=2448




ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ

이런것도 요즘엔.. 과학적으로 증명해 과학 논문에 실리는 건가.

"연구진의 주된 관심사는 깊이 사귀던 연인과 헤어진 뒤 자기역할이나 존재에 대해 가지는 생각인 ‘자아상’이 어떻게 바뀌었는지, 헤어짐은 이러한 변화에 얼마나 영향을 미쳤는지 조사했다."

자아상..
그게 정말 나의 모습이였는지..
정말 공감 스럽게도
잃어버린 자아상 덕분에
사춘기를 십춘기째 겪고 있는지도..
...
뭐 이래저래 상관은 없는
그래도 공감은 했던 기사.
.
:
Posted by .07274.
.. .. ..
 

(서울=연합뉴스) 안승섭 기자 = 양모(34) 씨가 폐 일부를 잘라내는 수술을 받은 것은 지난해 1월이었다.

"수술을 할 수밖에 없었습니다. 항생제가 전혀 듣질 않았니까요. 면역력이 너무 약해졌다고 하더군요. 2년 동안 거의 매일 자정 넘어 들어갔으니 그럴만도 하겠다는 생각이 들더라구요"

얘기하는 양씨의 눈시울이 순간 붉어졌다. 그 동안 가슴 속에 꼭꼭 눌러두었던 서러움이 북받치는 듯했다.

◇ "무조건 일정 맞춰라"..야근 불가피

양씨는 2006년 7월 금융기관 IT 계열사에 경력직으로 입사했다. 첫 프로젝트는 모회사인 금융기관의 인터넷 쇼핑몰 사이트 재구축 작업이었다.

"연말 오픈 예정이었지만 6개월 일정으로는 어림없는 작업이었습니다. 외부 하청업체마저 `사람 잡는다'며 포기할 정도였으니까요. `월화수목금금금'의 연속이었습니다"

보통 밤 12시가 넘어 집에 들어갔다. 시내버스나 지하철 막차를 타기 힘들어 자기 차를 타고 다니는 사람이 많을 정도였다. 밤샘을 할 때면 사내 휴게실에서 잠깐 눈을 붙였다.

6개월 간의 지옥같은 일정이 끝났지만 곧바로 다른 프로젝트에 투입됐다. 모회사 식품 브랜드 IT시스템 개발 작업이었다.

"시스템 구축 작업이 너무 복잡해 1년 일정으로는 힘들었습니다. 다시 12시가 넘어 귀가하는 생활이 시작됐죠. 담당팀장에게 직원들이 너무 힘들어한다고 얘기했더니 험악한 말 밖에 안 돌아오더군요"

시스템에서 오류가 발견된 2007년 말부터 2008년 6월까지는 말 그대로 살인적인 야근에 시달렸다. 매일같이 새벽 2~3시까지 일하고 다음날 아침 9시까지 정시출근하는 날이 이어졌다.



◇ 폐 절제 후에도 싸늘한 사측 반응

양씨에게 이상 증세가 나타나기 시작한 것은 2008년 여름부터였다. 한여름인데도 기침이 자꾸 나왔다. 가을 들어서는 잠을 제대로 못 잘 정도로 기침이 심해졌다.

"저녁 먹다 졸고, TV를 보다 앉은 채로 잠이 들었습니다. 손님이 와서 얘기하던 중에 잠든 적도 있습니다. 하루종일 너무 피곤했습니다"

중병에 걸린 것을 알게 된 것은 10월 말 받은 정기 건강검진 때였다. 일부 혈액 성분의 수치가 말기암 환자 수준으로 나왔다. 다음달 입원해 한달 넘게 항생제를 집중 투여했지만 소용없었다.

"외과서는 `폐결핵', 내과서는 `결핵성 폐농양'이라고 하더군요. 여하튼 면역력 저하로 항생제가 안 들으니 수술밖에 다른 방법이 없었죠. 의사 선생님이 젊은 사람이 왜 이렇게 몸이 망가졌냐고 묻더군요"

하지만 지난해 1월 수술을 마친 그를 맞는 회사 측의 반응은 싸늘하기만 했다. 연차휴가가 남은 상태에서 병가를 냈으니 연차수당을 반납하라고 했다. 결국 160만원을 토해내야 했다.

"퇴원 후 복귀해 보니 저하고 한마디 상의도 없이 `대기팀'으로 발령까지 냈습니다. 회사에서는 몸이 안 좋아 쉬라는 뜻이라는데 야속하기만 하더군요"

◇ 산재 신청에 사측 거부.."우리 모두의 현실"

몸이 계속 안 좋아 지난해 3월 휴직한 양씨는 산업재해를 신청하려고 했다. 정상적인 사람이라면 안 걸릴 폐결핵을 지나친 야근으로 인해 걸렸으니 당연한 거라고 생각했다. 하지만 현실은 달랐다.

회사 측은 양씨가 제시한 야근 기록을 인정하기를 거부했다. 객관적인 기록이 아니라는 이유였다.

회사 인사담당자는 "초과근로는 월 10시간 안팎으로 제한하는 것이 회사의 공식적인 정책이다. 양씨가 제시한 기록이 있지만 그 시간에 회사 일을 했는지 아니면 다른 일을 했는지 알 수 없는 것 아니냐"고 말했다.

하지만 양씨와 같이 일했던 사람들의 증언은 다르다.

A씨는 "밤 11~12시에 집에 가면 빨리 간 편이었다. 일정이 너무 빡빡했고 투입된 인력도 적었다. 간부들이 저녁 늦게 와서 진행 상황을 체크하기도 했다. 날마다 밤 늦게 야근을 할 수 밖에 없었다"고 말했다.

B씨는 "매일같이 12시가 넘어 들어갔지만 사내 인사관리시스템에는 월 10시간 정도 밖에 입력할 수 없었다. 그 이상은 입력 자체가 안 됐다. 양 과장의 경우 경험많고 유능한 직원이라 일도 더 많았다. 하지만 누구도 야근 기록을 제대로 남길 수 없었다"고 말했다.

회사 측의 비협조로 산재 신청도 어려워진 양씨는 야근 인정을 위한 `나홀로 소송'을 준비하고 있다. 돈이 없어 변호사 구하기도 힘들다. 세살배기 딸 키울 돈이 없어 전셋집 평수를 줄여 생활비를 마련해야 한다.

"저만의 문제가 아니라고 생각합니다. 많은 IT 근로자들이 3D업종 종사자로 전락한 지 오래됐습니다. 장시간 노동에 야근수당마저 제대로 못 받는 현실입니다. 우리나라가 `아이폰' 같은 뛰어난 IT 제품을 만들기 위해서는 IT 근로자의 처우부터 개선해야 한다고 봅니다"

ssahn@yna.co.kr
(끝)
.
:
Posted by .07274.