네팔 여행 Q&A

1. 혼자가냐?
혼자간다.
관광을 가도 싸움이 나는데 이 힘든데를 누굴 댈꼬가나
거기가면 나같은 인간 천지삐까리다 마음맞는 사람만나서 같이 다니면 된다.
여행은 사람이 반이다.

2. 언제 가냐 
2017년 1월 9일 출국 ~ 2월 24일 귀국

3. 회사서 보내줘?
사장이 대인배임

4. 와이프가 보내줘?
와이프가 대인배임

5.가족은 뭐먹고 살어?  월급은 나와?
무급 휴직이다. 사장이 땅파서 장사하냐
두달 때울 돈 모아뒀다.
든든한 마이너스 통장도 있다.
더 쓴건 다녀와서 갚으면 된다.

6.너 돈 많어? 두 달 동안 얼마나 쓰는겨?
네팔은 극빈국 중 하나이다
1루피 10원으로  열배 계산하면 되고
극단적으로 밥한끼에 200~300 루피면 먹는다
(물론 호텔가서 존거 먹어도 된다, 한국하고 비슷하거나 더 비싼것도 있다)
물론 외국인 가격은 따로 있으나  트레킹코스의 숙소의 식대는 국가에서 관리해서 바가지는 없다.
트레킹 기간 동안 1일 4만원으로 계산해서 100만원 정도 잡았다 (이정도면 잘먹고 잘 다니고 남을 듯)
두달 감안해서 월 1천달러 정도 해서 2천달러 예상하고 예비비(선물)는 따로 300달러 정도 생각함
3월 부터 매월 조금씩 달러 구입해서 5천달러 모아서 비행기비용 포함해서 남는다

7. 어디를 가나
네팔에는 크게
안나푸르나 히말라야, 쿰푸히말라야,  랑탕히말라야 지역이 있다.
우리가 아는 에베레스트는 랑탕히말라야 지역에 있다.
나는 안나푸르나 지역을 간다.

8.얼마나 높이 가는거야?? 안얼어죽어?
나는 전문 등산인도 아니고  안나푸르나 1봉 의 높이는 8091m(세계10위)이다
절대 못 올라간다

그리고 이곳은 들어가기 위한 허가만 1천만원 정도의 입산비(?)가 필요하다
트레킹은 수만원의 비용으로 허가를 받는다(퍼밋, 팀스 라는것을 발급받아서 간다)

일반인들은 일반적으로 "히말라야 간다" 하면 각 주요 산의 베이스캠프(본격 등산을 위해 산 아래 자락에 마련한 캠프지역)까지 트레킹 하는것을 말한다

안나푸르나 베이스캠프 : "ABC 간다"
마차푸차레 베이스캠프 : "MBC 에 있어!"
에베레스트 베이스캠프 : "EBC 간다!"  에베레스트 간다!  < == 간지난다.

그리고 안나푸르나에 간다는 것은 일반적으로 평지에서 ABC 까지 갔다가 오는것으로
"안나푸르나 생츄어리" 라고 부른다.

안나푸르나 히말에는 안나푸르나 하나의 산이 아니라
안나푸르나 1봉,2봉,3봉....등등 많은 산들이 모여있다

이 산들을 빙~ 둘러서 둘래길 걸어가듯이 트레킹하는 것을
"안나푸르나 서킷" 이라고 부른다.  (한국사람들이 라운드 라고 부르는데 서킷이 맞단다)

그래서 고도를 보면

서킷을 걸어가면   1000m에서 시작해서 최고 5416m 되시겠다.

생츄어리라면 ABC가 가장 높은 곳이므로 4136m 된다.

백두산이 2880m 이므로 꽤 높고 3000m 이상으로 올라가면 고산증을 주의해야 하므로 천천히 올라갈 예정임

3000m까지는 가을 산행복으로 입어도 낮에는 덥다고 하고
저녁에는??? 얼어디짐 다 껴입고 자야한답니다.

4000m 이상에서는 겨울 복장이고 이후 쏘롱라 패스 통과시  영하 10도 이하

계산을 좀 해보면

해발 100m 마다 0.64도씩 기온이 떨어진다
포카라가 1000m 이고 1월 최저 평균기온이 7도 이므로
쏘롱라 5416m 를 감안하면
표고차  4000m 이면   4000/100= 40  * 0.65도 = -26도 + 7도(포카라) = -19

영하 19도..... 바람불면.....

머 어떻게 다 된다.

9. 산에서 얼마나 있는거야?
대략 계산했을때 20일~28일 정도
시간이 없으면 차타고 좀 올라가서 시작하면 기간을 많이 줄일 수 있으나
본인은 전혀 트레이닝이 되어 있지 않아서
아래서 부터 천천히 걸어서 올라갈 예정이라 기간이 긴 편임

10. 먹는건? 자는건?
이 트레킹 코스는 이미 수십년에 거쳐 개발 되었고
4000미터 이상의 베이스캠프 위치 정도가 이나라면 마을이 있고
마을마다 "롯지"  라는 숙소들이 있다
이 롯지에서 먹고 자고 한다.
난방은 전혀 안되므로 침낭은 싸들고 가야하고
실외와 실내의 온도차이는 거의 없는편이라고함

11. 하필이면 추운 1월이냐
원래 성수기가 따로 있다
근데 성수기에 나도 먹고 살아야지 회사일 바쁠때다 두달이나 휴직 못한다.
사실 12월이 딱인데 (눈 올 확률이 낮다)
일때문에 1월에 출발함

2월 부터는 눈이 내릴 확율이 높아짐 (한번 오면 미터단위로 온다...못넘어감)
더 따뜻해지면 낙석 및 눈사태 확율이 높아져서 목숨이 간당간당할 것 같아서 안되겠다.

Day	날짜	요일	시간	내용	비고	산행
1	2017-01-09	월	13:25	출국-도착18:10,픽업,KTM 숙박	11시30분 까지 공항도착
2	2017-01-10	화		마야거르츄.타멜.멍때리기	숙박은 옥상에서???
3	2017-01-11	수	14:00	포카라이동.예티항공	놀이터
4	2017-01-12	목		포카라 숙박.TIMS, PERMIT 발급	놀이터
5	2017-01-13	금	7:30	베시사하르(450루피,11시5H)-샨제(Syange)	버스,짚(차메까지 3k루피.11시30분발 18시30분도착 7h)
6	2017-01-14	토		샨제-딸(Tal)	1700m	1
7	2017-01-15	일		Tal - Darapani- DanaQue	2300m	2
8	2017-01-16	월		Danaque- 티망 - chame	2670m	3
9	2017-01-17	화		chame - Bhratnag - up Pisang	3300m	4
10	2017-01-18	수		up Pisang - 나왈 - Manang	3540m	5
11	2017-01-19	목		Manang - 캉사르 - 쉬리카르카 -틸리초BC	고소적응 4300m,또는 휴식	6
12	2017-01-20	금		틸리초BC - 틸리초 - 쉬리카르카	틸리초4919m	7
13	2017-01-21	토		쉬리카르카 - 야크카르카	4028m	8
14	2017-01-22	일		야크카르카	휴식, 4018m	9
15	2017-01-23	월		야크카르카 - 쏘롱패디	4450m	10
16	2017-01-24	화		쏘롱패디 - 하이캠프	4800m	11
17	2017-01-25	수		하이캠프 - 쏘롱라 패스 - 묵티나트	5416m - 3800m	12
18	2017-01-26	목		묵티나트 Muktinath	휴식	13
19	2017-01-27	금		묵티나트 - 까끄베니 Eklebhatti -Jomsom		14
20	2017-01-28	토	7:00	Jomsom - 버스 - Tatopani	7시버스 6H	15
21	2017-01-29	일		Tatopani - 시카 Sikha - 고레파니 Ghorepani		16
22	2017-01-30	월		Ghorepani - Tadapani		17
23	2017-01-31	화		Tadapani - 촘롱 Chomrong		18
24	2017-02-01	수		Chomrong - 히말라야호텔		19
25	2017-02-02	목		히말라야호텔 - MBC		20
26	2017-02-03	금		MBC - ABC	자던가 걍오던가	21
27	2017-02-04	토		ABC - 뱀부		22
28	2017-02-05	일		뱀부 - 오스트레일리안켐프		23
29	2017-02-06	월		오캠 - 카레 - 포카라		24
30	2017-02-07	화		포카라
31	2017-02-08	수		포라카
32	2017-02-09	목		포카라
33	2017-02-10	금		포카라
34	2017-02-11	토		포카라 - 룸비니	5H 이상
35	2017-02-12	일		룸비니
36	2017-02-13	월		룸비니
37	2017-02-14	화		룸비니 - 포카라	5H 이상
38	2017-02-15	수		포카라
39	2017-02-16	목		포라카
40	2017-02-17	금		포카라
41	2017-02-18	토		포카라
42	2017-02-19	일		포카라 - 카트만두	버스 8H이상
43	2017-02-20	월		카트만두 관광	타멜-스와얌부 템플
44	2017-02-21	화		카트만두 관광	파슈파티나트 사원
45	2017-02-22	수		카트만두 관광	박타푸르
46	2017-02-23	목		KTM 선물사기
47	2017-02-24	금	20:30	귀국비행기	KTM International
	2017-02-25	토	5:30	도착
	2017-02-26	일		집
	2017-02-27	월		집
	2017-02-28	화		집
	2017-03-01	수		3.1절
	2017-03-02	목		출근

.이상.

PS : 더 궁금한건 술사라

JBoss EAP7 의 변경된 Connector와 Thread 처리

JBoss EAP 7 (이하 EAP7)이 나온지도 몇개월이 되었고 (2016년 Q3)

아직 시장에 많이 풀리지는 않았고

패치도 열심히 올라오는 중임

이번에 바뀐 부분중에서 핵심(?)적이라고 할만한 부분을 말해보자면

서블릿 컨테이너를 전면 교체 하면서

요청을 받아들이는 Connector 부분과

WAS의 실질적인 요청처리 작업을 하는 Thread의 구조 및 Pooling 방법이 변경되었다


먼저 톰켓(tomcat)과 같이 설명을 하자면

EAP6까지는 Listener(Connector), Thread Pool, servlet 처리 부분을 Tomcat으로 처리해왔다

실제 tomcat 소스를 임포트 해서 개발했다고 보면 무방하다

그러다보니 tomcat tuning 포인트와 같이 생각하면 됬다.

대표적으로  Production에 적용한 tomcat 에서 기본적으로 검토해야하는

Pure java가 아닌 tomcat Native 를 사용하듯이 (APRConnector)
(BIO-blocking , NIO-non blocking JAVA Connector ,
APR-Apache Potable Runtime Native)

EAP에서는 이미 컴파일 된 Native Module을 제공하였고

Thread처리도 기본이 아니라 Executor thread Pool을 별도로 생성하여

tomcat 내부 Thread와 사용자 처리 Thread를 분리 하여 동작하도록 튜닝했다.
(안정성 개선 등)

EAP7에서는 tomcat의 이부분(서블릿컨테이너라도 통칭)을 걷어내고

경량 서블릿컨테이너인 언더토우(Undertow)로 변경되면서

서블릿 처리를 수행하는 컨테이너를 포함하여

앞서 말한 Connector 처리와 Thread Model이 변경되었다

이렇게 변경된 이유를 추측(!) 해보면

JVM의 Native 성능에 대한 신뢰가 어느정도 올라간것이 아닌가 하는 생각이다

기존에도 NIO(New IO)라고 해서 JAVA에서도 native 통신성능을 개선한 JAVA API를 제공하였으나

API 편의성이 그다지 좋지 못하고

그냥 추론에 성능이 그리 훌륭하지 못하고 안정성에 대한 신뢰 문제.... (가 있다는것이 아니라 C로 개발된 Native에 비하여) 등의 고민때문에

별도의 native module을 개발하여 제공하였다 ( 확장자 so 파일)

하지만 아무래도 별도의 모듈 개발에 필요한 공수도 감안하고

JVM의 NIO의 개선을 목적으로 XNIO (http://xnio.jboss.org/) 프로젝트가 진행되었고

이 Xnio를 기반으로 Undertow(http://undertow.io)가 개발되었으며

EAP7 에서는 이 부분을 신규로 적용한 것이다.


그럼 XNIO 기반의 Undetow를 적용함으로써 실제 좋아지는게 뭐냐?

니들끼리 바꿨다고 자축해봐야 나하고 뭔 상관이냐고....

라기 보다는

노가다 뛰는 엔지니어 입장에서 보면 다음과 같은 개선사항이 있다

1. Native 추가적인 설치가 필요없다
기본 Pure JAVA 기반의 WAS를 Native로 동작하게 하기 위해서는 별도의 Lib 모듈이 필요하며 tomcat의 경우 별도의 모듈 생성을 위하여 gcc를 사용하여 컴파일 하는 작업.....(아...구차나...안되면 골때리고...생성되도 운영시 문제발생시 해결방법이 없다)
JVM의 NIO를 기반으로 하는 XNIO를 사용하여 Connector 와 Buffer를 처리함으로써 JVM만 있으면 별도의 라이브러리가 필요없다.
설치가 단순해 진다.

2. Connector(Listener)의 단순화
EAP5를 구동하면  WAS 하나에 엄청나게 많은 Listen Port가 열렸다.
별별 다른 APP들과 충돌이 나고
포트 번호 하나 바꾸는데 진이 빠질 정도였던 환경에서
EAP6로 가면서 일부 최적화가 되었으나
tomcat Connector는 Multiplexer(MUX) 기능(1개 포트로 여러  프로토콜통신수행)을 구현할 수 없었기 때문에 어쩔 수 없이 다수의 Listen port가 사용되었다.
(예를 들어 관리용 Native Port 9999, EJB용, 기타 등등)
EAP7에서는 XNIO의 MUX기능을 사용할 수 있게 되었고 이를 통하여 Port를 통합함으로써 점유하는 Port 수를 획기적으로 줄였다
(관리용 Port 9999 하나로 EJB, JMX 등 여러 서비스를 동시 제공, HTTP 8080 포트하나로 HTTP2.0 프로토콜 동시제공)

3. Direct Buffer 사용
성능과 큰 관계가 있는 부분으로 기존에는 사용자 요청을 받으면  JVM 내부 Heap 영역의 일부를 Buffer로 지정하여 해당 영역에 저장하여 처리 하였으며 이 버퍼는 Blocking 모드로 동작했다(JVM의 내부는 무조건 Blocking Thread 모델이다...태생이 그렇다.
(Native 모듈설치한 WAS나 NIO 빼고)

EAP7 부터는 XNIO를 사용하여 JVM 외부 메모리 영역(Native Memory) 즉 Process의 메모리 영역에 접근할 수 있게 되어 non blocking으로 메모리에 저장함으로써 Buffer 처리 능력을 획기적으로 상승시킨다.
(솔까말 Native Module 설치한 WAS와는 비교하면 그놈이 그놈)

4. IO thread  별도로 추가됨 
위에서 말한 MUX에 들어오는 요청은 기존에는 WAS Thread와 1:1 매칭 되는 구조였으나
이제 부터는 별도의 IO Thread가 Listener로 들어온 요청을 non blocking으로 읽어서 direct buffer에 저장하게 되므로 Rush 성 요청에 대한 대응능력이 개선됬을 것으로 보인다.

무슨말이냐...

요청이 엄청나게 밀려드는 웹사이트에서 JVM이 그러한 요청처리를 하기 위해서는 Kernel과 통신하여 요청을 처리해야 하고 이때 Blocking이 걸린다.
만약 JVM이 처리하는 속도 보다 요청이 더 빠르게 유입된다면
요청은 큐에 쌓이다가 결국 튕겨져 나가는 현상이 발생할 수 있다.

느린 (blocking thread) JVM Thread는 기존과 같이 working thread로 사용하지만
그 앞단에 Non blocking Thread를 별도로 두어서
들어오는 요청을 빠르게 수용할 수 있도록 변경함으로써
일단 들어오는 요청은 최대한 빨리 내부로 진입 시킬 수 있도록 개선되었다는 이야기.....
(아...씨바...머이리 복잡해.....)

이러한 구조는
대형 사이트에서 사용되던 상용 Product 에 이미 적용되곤 했던 검증된 구조로써
대표적으로 Iplanet Web Server(Sun One Web Server, Oracle iplanet webserver)에 적용되어
뛰어난 성능과 안정성을 자랑했다.

5. Worker(Working Thread Pool) 가 추가 되었다.
IO Thread가 단순히 요청을 빠르게 읽어들어 뒷단으로 저장하는 기능을 담당(Non Blocking)한다면

Working Thread는 실제 처리를 수행하는 (파싱하고..적달한 엔진으로 넘기고...대답하고)하는 역할(Blocking)을 수행한다.

기존의 Executor Thread Pool 이라고 불리던 Thread Pool이
Worker 라는 이름으로 변경되었다고 보면 된다.

사실 Thread Pool이야 원래 있던 내용이지만
이전까지 직접 config 파일을 열어서 추가하고
connector와 연결하는 작업을 해야 했던 터라
구조를 이해 하지 못하고 작업 해서는 잘 되지 않고
잘못넣으며 문제를 일으키기 십상...

이러한 부분을 CLI 및 GUI로 통합하여 구성 할 수 있도록 해서
Pool 관리가 월등히 편리해 졌다.



그럼 사용자 입장에서는 뭐가 좋아졌을까?

일단 성능이 좋아졌을 것으로 기대(?) 하고 있다.

본인이 직접 BMT를 해보지 못해서 딱 그렇다고 는 못하겠지만

EAP7이 안정화 되면 기존 버젼보다는 안정성 및 성능면에서 상당한 개선이 기대 된다.


뭐...WAS가 다 그놈이 그놈이지...

내가 운영하는 사이트가 최소한 동시접속이 수천~만 까지 되는것이 아니라면

솔직히 직업 운영할 능력 되면 tomcat도 좋고  Resin도 좋다   그 단순함의 미학....

하지만 아무래도 대용량 접속이 고려 되는 사이트이거나

자체적인 운영 능력이 낮은 조직라면

이제와서 WAS BMT 하자는건 너무 오바고
(올해 2017년이다.
WAS BMT가 웬 말이냐 이미 시장에서 검증된것 좀 믿어라...
김태희 예쁜걸 꼭 같이 살아봐야 알겠냐... 믿어라)

되도록 상용 WAS를 권하고 싶다.

.이상