LPG 차량분류
LPG 차 : 그냥 옛날 방식 ,기화기 있음
(가스공급)봄베 -> 기화기 -> 믹서 -> 엔진실린더
(공기공급)덕트 ->필터-> ->ISC밸브 ->
LPI(Liquid Propane Injection System) or LPLI (현대기아,삼성) : 기화기를 따로 두지 않는다
(가스공급) 봄베 (가압장비포함됨) ->인젝터-> 엔진실린더
(공기공급) 덕트 -> 필터 -> (믹서비슷한 역할이 있으나 큰의미없음)
연료 가압을 위한 장비가 봄베에 붙어있어 고장시 문제가 될 수 있지만 큰 문제 없고
기화기가 없으므로 LPG와 비교했을때 메인터넌스에 유리 (타르빼기 안해도 됨)
단 엔진구조가 복잡해져서 엔진쪽 메인터넌스는 불리 (돈 많이든다)
LPGi(GM대우,쉐보레) : 기화기 있음 메인터넌스 비용이 낮다.
봄베에 펌브(가압장비)없이 기화기를 사용하지만 직분사(인젝션) 방식으로 처리해서 기존 LPG 방식에서 믹서를 사용함으로써 나타나는 약점(시동성,부조문제등)을 개선한 형태
기화기가 있기때문에 기화기 메인터넌스 불리 (타르빼기의 귀찮음)
엔진 구조가 단순해서 LPI고장시 보다는 메인터넌스 유리 (비교적 저렴)
연비나 토크는 LPI보다 낮음
최근 나오는 LPG 기반 차량은 가스통(봄베)에서 압력을 조정해서 엔진으로 보내면 공기와 믹스 후 엔진으로 직접 분사되는 방식이다.
LPI의 경우 기화기가 별도로 없다는 점은 관리상 장점(큰 장점....타르빼기등 메인터넌스가 줄어든다)이지만 봄베의 압력 유지를 위한 가압 및 엔진에 직분사를 위한 제어부분의 추가로 가스통의 부담 및 부품가 상승등의 단점도 지적되곤 한다.
근데 우끼는게...
LPI는 기화기가 없으니 기화기 관리값을 빼면 그놈이 그놈 아닐까? 하는 생각도 해봄 ㅋ
LPG방식이야... 워낙 올드 한 방식이니 빼고
LPI 냐 LPGi 냐 가지고 말이 많은데.... 걍 개인적으로는
성능 중심 : LPI(LPLI)
비용 중심 : LPGi 라고 생각하고 LPGi나 개인적으로 나을듯...왜? 돈이 적게 들것 같아서!
각설하고......
얼마전 대박 메인터넌스부품을 구입했고....
그냥 시간나는김에 점화플러그와 케이블을 교체했다.
근데...그 다음부터 살짝 엔진부조(*)가 일어났다.
(*소리 : 다다다다~~ 해야 할께 다다다붕~ 다다다붕~
엔진 : 흔들리는게 안정적이지 않고 앞뒤로 털털거리는게 보인다)
뭐람....집에 굴러다니던 점화플러그를 끼웠는데 혹시 떨어트린적이 있나??
(떨어트릴때 간극이 틀어지면 부조의 원인)
아니면 교환할때 덜 조였나????
(덜 조여서 엔진압이 엔진과 플러그 사이로 누출되어도 부조의 원인)
일단....심하지도 않고 하니 시간 될 때 손을 대보지뭐.... 하고 지나갔다.
일이 좀 일찍마무리 되서 조기퇴근...
집에오니 손이 근질거려서 진주에 내려가서 작업할일 말고 미리 좀 해 놓을까 싶어서 손을 댔다...
점화 플러그 케이블 분리후 재 결합(혹시나 덜끼워졌나해서)
점화 플러그 교환 (불량을 끼웠나 해서...아까운 8천원...정품 4개 가격)
그래도 부조가 있다....이상하내....뭐지????
뭔가 상태가 변해서 ECU가 연료공급하는 벨런스가 깨진걸로 보인다....
전에도 이런적이 있었기에 떡본김에 제사라고 청소까지 해보기로 했다
(이거이....화근이다... 시간이 널널할때 해야 하는데....)
기화기 세척(분리하지 않고 구멍으로 액 주입)
ISC밸브 세척(솔레노이드 부분만 분리, 믹서에 붙은 메인부분은 그냥 두고)
믹서 는...그냥 캬브클리너로 뿌려서 청소...
약식으로 간단히 한다고(시간이없으니) 건드린 카렌스1...
아놔 씨바..
시동을 걸어보니 O/D램프가 깜박인다.
(OverDrive : 기어비를 다르게 해서 저단동작으로 강제하거나 고단으로 속도를 내거나 하는 기능을 이야기 한다. 미션의 기능이지만 미션부분에 이상이 생기면 점멸한다.)
킁~~!
전에도 이런적이 있었지만 ECU 리셋 후 학습과정을 거치면 괜찮아 지니까 ...
이번에도 그러겠찌..
일단 O/D 깜박이는 상태(**)로 방~방~ 거리며 살살 식당으로 가서
(**:기어가 상당히 고 RPM에서 변경된다. rpm 3000-40km정도에서 2단, rpm 5000-80km정도에 3단)
ECU 휴즈를 빼고 밥을 먹고 나와서 ECU 학습을 시켜본다.
- 여러가지 방법이 있지만 카렌스1 1.8 LPG는 구형으로 LPG2.0 과 다르다 하지만 방법은 별 차이 없다. -
1. 키 ON 하고 전기장치 켜지 말고 그냥 대기 (전기 최소값입력) -30초
2. 시동을 끄고 대기 - 10초
3. 시동(P상태) 수온계가 중간부분이 될때 까지 대기, 엑셀 밟지 말고 - ???초
- 만약 이미 고온상태에서 리셋한 것이라면 30초 정도 기다려 준다
4. 전장을 하나씩 켭니다. 각 단계에는 30초 대기합니다. (최대값 입력)
- 미등 - 전조등 - 전조등 상향 - 안개등 - 유리 열선 - 에어컨
5. 평소 운행 RPM 학습 (좀 시끄러울 수 있으니 ECU 리셋은 낮에 사람없는곳에서...)
- 핵심은 RPM을 1분정도 유지 하는겁니다. 밟았다 땠다 하면서 왔다리 갔다리 하지 말고
- 2000~2500RPM 수준으로 밟은 상태로 (살살 밟다보면 고정됨) 1분 이상 유지 시킵니다.
- 유지시키다 보면 상태가 변하면서 RPM이 상승합니다. (ISC와 믹서값이 조정됨)
- 이때 꾹~ 밟아서 5000RPM 까지 올립니다. (5초이상 유지)
- 엑셀에서 발을 땝니다.
** 이정도 RPM이면 시끄러워요...저녁이나 사람많은 대서 하면 좀 쪽팔림.. 조용한곳에서 할것
6. 전장을 하나씩 끕니다. 각 단계에 30초씩 대기합니다.
- 위에 켠것을 역순으로 하나씩 끕니다.
7 . 시동을 끕니다. (끄고 다음단계는 10초 이상 대기후)
8. 시동을 켭니다. 5분 정도 엑셀링하지 말고 방치 합니다.
..... 끝
으흠.... 출발하고 둘째를 대리러 가던중 기대했던 대로 O/D가 꺼지고 기어도 저단에서 정상적으로 들어가는듯....했으나..
집에 오는길 시내에서 잠시 섰다 가다를 하다보니 갑자기 또 O/D가 깜박이기 시작했다... ㅠ.ㅠ
"뭐지... 전이랑 좀 다른데..??"
일단 시내 주행이라 60km이상 달릴일이 없어서 엔진에 무리 갈 일 없이 집으로 와서 주차
다시한번 ECU 리셋을 수행하였으나..
여전히 부조 와 O/D 점멸....
내 생각에 기화기 타르녹이고 ISC밸브만 청소를 했으니...
떨어진 타르가 믹서에서 털려나가지 않고 어딘가 모여서 상태가 이상하게 된 듯...
아참... 연료공급선의 문제인데 왜 O/D가 점멸하느냐...
(O/D 점멸은 사실 미션센서에 문제가 있을때 발생한다)
나두 잘 모른다.... 차가 오래되서 센서가 문제가 있는것일 지도...
하지만 평소에 가서 스케너로 찍어보면 모든 센서 정보 정상임....
다만 경험상 엔진부조가 발생하면 rpm 문제가 생기고 이때 충격등으로 미션 구동계쪽 센서에서 측정값 오류가 뜨는것 같다. (걍 개인적 추측임)
타다가 중간에 O/D가 점멸한다면 미션을 의심해보고 샵에 가서 스케너로 확인하기 바람(미션 문제 있는데 계속 몰고 다니다가 큰문제 나면 돈 더 깨 질라...)
내 경우 ECU 리셋 후 발생하는 증상이고 (할 때 마다 그랬음) 학습을 시키고 나서 하루 이틀 지나면 점멸 증상이 없어지기 때문에 위와 같이 처리하고 있음
여하간....
하루가 지난 오늘 찜찜한 기분으로 출근하고
낮에 와이프에게 아침에 끌고 나갈때 어땠냐고 물어보니 O/D 안깜박인단다...
으흠.... 녹아서 흐른 타르들이 아래쪽으로 잘 모여들었나.... ^^;;
여하간 연료계통 청소후 ECU리셋 후 바로 정상적이였던 적은
기화기 교체 + 믹서 청소(벨브전체 탈거) 를 꼼꼼하게 했던 1회 뿐...
대충 청소하고 나면 꼭 그날이나 다음날 시동꺼짐 증상
(이건 청소액이 남아서 그럼...일단 청소 후에는 무조건 달릴 수 있는곳으로 가서 100Km이상으로 한번 달려주고 들어 올것...어설프게 N,P 놓고 방방~ 거려봐야 정차시 시동꺼짐으로 개고생할 수 있음)
또는
O/D 점멸로 인한 3단 기어 고정현상
(현기차의 경우 미션 센서에서 오류값이 나오면 그냥 기어를 3단이상으로 올리지 못하도록 고정하도록 설계 되어 있다고 함)
이 발생할 수 있습니다.
3단기어 고정상태에서는 고속으로 주행 하려고 밟아대면 엔진이 과열되겠죠?
RPM은 5천까지 올라가도 겨우 속도가 100Km 나옵니다.
여하간...
연료계통청소는 할 때 맘먹고 하고 (대충하지말고 꼼꼼하게)
ECU리셋은 무조건 해야 한다고 생각하시고 진행하며
청소나 작업간에 이상한짓(전선을 끊어먹거나 빼고 안끼우거나)을 한게 아니라면
낮은 기어라도 좀 달려서 청소액과 타르가 빠지도록 하고
(타르도 빼줘야함...어설프게 엔진실린더에 들어가면 장기적으로 좋을것 없을듯..)
냉간을 거친후(완전히 식은상태)
하루 이틀정도 몇 번 가깝께 돌아다니면서 O/D가 꺼지는지 확인하는 단계로....
O/D 점멸 상태로 샵에 가면 그분들도 스케너 찍어보고 난감해 함...
결국은 미션바꾸자 또는 기화기 바꾸자라는 소리부터 나오는데.....
여하간 난 그냥 이렇게 끌고 다닙니다.
오늘 저녁에 봐서 이상없으면 일단 진주에 내려가서 이번에는 믹서를 통째로 행궈(?) 봐야 겠음
.이상
2015년 9월 24일 목요일
2015년 9월 23일 수요일
JBoss Clustering Session 복제시 복제 기준
맨날 해깔려서 하는김에 정리해서 적어봄
1. 개요를 말하면....
공히 WAS 들은 Session Clustering 이라는 기능을 제공한다.
여러대의 WAS (Instance)가 하나의 서비스를 제공할때 각각의 WAS 에 로그인(**)한정보(Session)를 공유하여 일부 WAS가 정지되어도 로그인이 유지되는 기능이다.
** 엄밀히 로그인은 아니다. JSessionID 라는 WAS에서 생성해 주는 쿠키값으로 접속한 클라이언트의 세션을 유지하는 것으로 당신들이 ID/Password 를 입력하는 로그인 이라는 행위는 개발자가 개발해 놓은 기능이다.
상용 WAS 들 중에서 Enterprise 라는 단어가 붙어 있는 놈들과
Standard 버젼의 차이가 이거라고 보면 된다.
- 상용 제품군-
Web logic : Ent 와 Std 로 나뉜다.
JEUS : Ent 와 Std 로 나뉜다.
- 오픈소스(OSS)비지니스 제품군 - (오픈소스이기는 한데 돈내야 지원해준다)
JBoss EAP : Infinispan 기반으로 클러스터링 제공한다.
Resin : OSS 버젼과 Pro 버젼이 있으며 기본적으로 Clustering 기능이 있다. OSS 버젼은 Pure JAVA라 성능으로 따지만 Tomcat 이나 별반 차이도 없다.
- 오픈소스 제품군- (이건 기술지원 따위는 없다. 그냥 너님이 하는거다)
WildFly(구 JBoss AS) : Infinispan 이라는 Grid OSS 가 내부적으로 구현되어 있고 이기능올 클러스터링 제공
Tomcat : Clustering 기능이 최근에 추가 되어있다. 하지만 성능은 보장 못한다(않좋아...pure java 라넘 느려)
....
2. 근데 이거 꼭 써야해?
결론 부터 이야기하자... "아니다!"
세션을 유지한다는 것은 사용자 브라우져와 서버간의 접속이 유지되지 못하는 WEB의 특성상 (HTTP Protocol 은 stateless 라고 한다.)
한번 접속해서 화면 받아오면 상태(status)가 유실된다.
하지만 사용자의 상태가 유지되어야 로그인정보나 장바구니를 다시 볼 수 있기 때문에
이런 상태를 유지하는 것을 세션(Session)이라고 하며
이 세션을 유지하는 방법은 꼭 인프라(WAS) 에서 구현되어야 함은 아니다.
예를 들어 대규모 사이트의 경우 세션 정보를 WAS에서 복제하여 상태유지를 할 경우 세션을 모든 WAS가 동기화 하기위한 부하때문에 오히려 장애포인트가 되기도 한다. (Instance 여러개 + 사용자 대박!! 이면 WAS 지들끼리 세션 복사하다가 뻗어 버리기도 한다)
물론 JBoss 나 상용 WAS들은 이런 복제 Overhead 를 줄이기 위해서 몇몇 옵션등을 제공하기도 하므로 이런일로 고생하고 있다면 제품 지원팀에 문의해 보자.
(Sync 방식을 ASync 방식으로 바꾸거나, UDP 클러스터를 TCP로 바꾸거나 등등)
이러한 문제를 해결하기 위해서
WAS의 클러스터링 기능을 쓰지 않고
로그인처리시에 암호화된 세션정보를 사용자(브라우져)에 저장(쿠키)하도록 개발해서
세션을 유지 하기도 한다.
(사용자가 대박!인 글로벌 회사의 업무시스템 또는 대형 오픈마켓)
선택는 자유다.
단 팁을 준다면
2.1. 우리사용자가 졸라 많거나(동접 몇 만명 같이...) WAS 인스턴스가 너무 많아서 클러스터링을 하는게 부담스러운경우
(다수의 WAS를 Clustering 하는 경우 세션복제 Overhead 로 인하여 원래 1개 WAS 가 처리할 수 있는 능력이 감소한다)
상용 WAS 기준이라면
클러스터링 버젼(Enterprise)보다 Standard 버젼을 도입하고 세션을 쿠키로 유지하거나
그리드 솔루션이 있다(JBoss Data Grid, Oracle coherence, 국산도 있다 GTWorks )
쿠키를 쓰건 그리드솔루션을 사용하건 일단 개발자가 세션을 유지하기 위한 방법을 설계해야 하고 일부 세션 관리 코딩은 추가 되어야 한다.
개발자 학습비용 기준 : 코드기반으로 관리하려면 아키텍쳐 부터 설계필요
WAS Clustering < Grid Solution < 코드(Cookie) 기반
서버부하(Overhead) 기준 : Overhead 가 클수록 WAS 처리량은 낮아진다.
WAS Clustering > Grid Solution > 코드(Cookie) 기반
오픈소스기반이라면
여하간 Tomcat Clustering은 사용하지 말라
게시판 뒤져보면 알겠지만 아직 성능이나 안정성이나 그다지 좋다고 못하겠다.
JBoss EAP 자체의 Clustering 을 사용하거나 위에 말한 그리드 솔루션(JBoss Data Grid)을 같이 검토하도록 한다.
또 다른 방법으로 클러스터를 쪼개는 방법이 있다.
(나는 개인적으로 이 구조를 좋아하고 많이들 이렇게 한다...
근데...실제 운영해야하는 사람들이 WEB/WAS/HA등을 잘 모르면 맨날 장애를 일으킨다......
예를들어 공무원조직에 담당자는 그게뭔지 모른다...장애나면 사람부른다....사람도착할 때 까지 장애다.)
예를 들어 인스턴스가 8개라면 클러스터를 8개 통째로 묶는게 아니라
4개 + 4개 로 클러스터를 두개로 나누어 운영하도록 하고
사용자 트래픽을 웹에서 분산구조에서 제어해서 최대한 장애가 발생하지 않도록 한다.
WEB : 1,2 3,4
WAS : 1234 5678
위 구조에서 웹서버 1 또는 2로 들어온 사용자는 WAS1,2,3,4 로 접속이 되고 세션이 유지된다. 만약 was1,2,3,4 가 동시에 중지된다면 장애가 된다.
이러한 운영상의 논리적인 구조를 쪼개서 운영하는 경우 HA를 위하여 작업절차나 장애처리시 재구동 방법등을 세밀하게 조정하고 운영해야 한다.
(Ex, 배포후 재구동시 WAS를 1,2,3,4,5,6,7,8 순으로 재구동하지 말고 1,5,2,6,3,7,4,8 순으로 재구동 한다거나...)
2.2 걍걍 일반적인 업무 시스템 이라면
WAS의 Clustering 기능을 사용하도록 한다.
세션을 개발자가 코드상에서 생성하고 서버에 저장해서 유지를 한다는 일은......머리아프다....
기술적인 부하 문제가 없다면 Clustering 되는 제품간의 가격 비딩이 될 것이니...
알아서 하자.
3. JBoss EAP 에서 클러스터링 할 때 방법
아... 사실 Config를 하나하나 이야기 하려면 너무 많은 것을 설명해야 한다....
(UDP 냐 TCP 냐... 복제방식은 뭐냐...등등)
그냥 일단 클러스터링 되어 있다치고
개발자 입장에서 알아야할 세션 복제에 집중해서 적어본다.
일단 소스에서 /WAR_ROOT/WEB-INF/web.xml 파일안에 아래 볼드체가 있어야 동작한다.
두번째
세션 복제는 RMI 같이 네트워크 통신을 해서 복제 된다.
그래서 세션에 저장하는 모든 Object는 Serializable 해야 한다. (JAVA Spec)
이건 WAS 할아버지가 와도 지켜야 할 법칙이다. (제품 마다 다르다는 뻘소리 하지 말자)
복잡하게 세션 객체를 만들어 쓰는 개발자 라면 아래 같이 하자.
class UserSessionObj implements Serializable
{
}
UserSessionObj InstUserSessionObj = UserSessionObj();
InstUserSessionObj.setUDI = "이름";
....
session.setAttribute("SESSION_OBJ", InstUserSessionObj);
세번째
/WAR_ROOT/WEB-INF/jboss-web.xml 파일안에 이런게 있다.
없으면 만들어도 된다. 하지만 기본 값이 있으므로 클러스터링 부하로 인한 문제
또는 개발한 기능상 복제될 세션객체에 대한 제어가 필요하지 않다면 꼭 만들 필요는 없다.
아래 뻘건 글씨를 잘 보자, 일단 이게 기본값이다.
<jboss-web>
<context-root>/</context-root>
<replication-granularity>SESSION</replication-granularity>
<replication-field-batch-mode>true</replication-field-batch-mode>
.... 이거 말고도 잔뜩
</replication-config>
</jboss-web>
==========================================
웅??? 그게 뭐냐구???
메뉴얼 상에 글을 옮겨 보겠다.
SET: With this policy, the session is considered dirty only when an attribute is set in the session (i.e., HttpSession.setAttribute() is invoked.) If your application always writes changed values back into the session, this option will be most optimal in terms of performance. The downside of SET is that if an object is retrieved from the session and modified without being written back into the session, the session manager will not know the attribute is dirty and the change to that object may not be replicated.
>> 코드상에서 setAttribute()시 세션을 복제한다.
가장 클러스터링 부하가 낮다.
이렇게 해놓으면 값은 바뀌지만 복제가 안 될 수 있다.(코드 잘 짜면 그런 걱정 안해도 된다.)
세션에 저장되는 정보를 코드상에서 크게 컨트롤 하지 않는다면 부하를 줄이기 위해 사용해 볼 만 하다.
SET_AND_NON_PRIMITIVE_GET:(기본값) This policy is similar to the SET_AND_GET policy except that get operations that return attribute values with primitive types do not mark the attribute as dirty.
Primitive system types (i.e., String, Integer, Long, etc.) are immutable(수정불가능한), so there is no reason to mark an attribute with such a type as dirty just because it has been read.
If a get operation returns a value of a non-primitive type, the session manager has no simple way to know whether the object is mutable, so it assumes it is an marks the attribute as dirty.
This setting avoids the downside of SET while reducing the performance impact of SET_AND_GET. It is the default setting.
>> setAttribute()시 세션복제 + getAttribute()시 기본형(primitive type)들을 빼고 복제
(기본설정)
기본형(char,int,String, Integer**..등)는 재 할당은 가능하지만 할당된 값 자체를 변경할 수 없다. (이 객체들에는 set method가 없다) - 개발을 해보지 않으면 좀 해깔릴 수 있다. immutable 객체에 대한 내용을 인터넷에서 찾아볼 것을 권한다-
그래서 이 값들은 GET 하는 순간에는 변경이 일어나지 않았음을 보장할 수 있으므로 (대체한다는 것은 SET 을 수행했다는것을 의미하므로 이미 복제 되었다.)
GET할때 Primitive 형을 복제 대상으로 지정하지 않는다.
이 방식은 SET의 누락에 대한 위험(오류)성과
SET_AND_GET이 너무많은 데이터를 복제할 수 있는 위험(성능관련)을 적절하게 타협한 방식으로 기본값으로 적용되어 있다.
이 설정이 기본이고 보통 이설정으로 큰 문제 없이 사이트 들은 운영된다.
SET_AND_GET: With this policy, any attribute that is get or set will be marked as dirty. If an object is retrieved from the session and modified without being written back into the session, the change to that object will be replicated. The downside of SET_AND_GET is that it can have significant performance implications, since even reading immutable objects from the session (e.g., strings, numbers) will mark the read attributes as needing to be replicated.
>> setAttribute()시 세션복제 + Obj getAttribute()시 세션복제
세션에 속성으로 객체나 프리미티브정보를 최초생성 하거나 이 값에 접근할 때 여하간 복제한다.
SET 이나 SET_AND_NON_PRIMITIVE_GET 보다는 복제 부하가 크겠찌??? 그지??
ACCESS: This option causes the session to be marked as dirty whenever it is accessed. Since a the session is accessed during each HTTP request, it will be replicated with each request. The purpose of ACCESS is to ensure session last-access timestamps are kept in sync around the cluster.. Since with the other replication-trigger options the time stamp may not be updated in other clustering nodes because of no replication, the session in other nodes may expire before the active node if the HTTP request does not retrieve or modify any session attributes. When this option is set, the session timestamps will be synchronized throughout the cluster nodes. Note that use of this option can have a significant performance impact, so use it with caution. With the other replication-trigger options, if a session has gone 80% of its expiration interval without being replicated, as a safeguard its timestamp will be replicated no matter what. So, ACCESS is only useful in special circumstances where the above safeguard is considered inadequate.
>> HTTP 요청이 있으면 Session변경으로 간주하여 복제...여하간 무조건 복사
내 생각에 이거 하면 복제 트리거를 신경을 안써도 되니 간단해 보이지만 프로덕션환경에 적용하는 경우 그냥 사이트 무너진다고 보면 되겠다 (개인 홈페이지라면 상관없다)
.이상.
1. 개요를 말하면....
공히 WAS 들은 Session Clustering 이라는 기능을 제공한다.
여러대의 WAS (Instance)가 하나의 서비스를 제공할때 각각의 WAS 에 로그인(**)한정보(Session)를 공유하여 일부 WAS가 정지되어도 로그인이 유지되는 기능이다.
** 엄밀히 로그인은 아니다. JSessionID 라는 WAS에서 생성해 주는 쿠키값으로 접속한 클라이언트의 세션을 유지하는 것으로 당신들이 ID/Password 를 입력하는 로그인 이라는 행위는 개발자가 개발해 놓은 기능이다.
상용 WAS 들 중에서 Enterprise 라는 단어가 붙어 있는 놈들과
Standard 버젼의 차이가 이거라고 보면 된다.
- 상용 제품군-
Web logic : Ent 와 Std 로 나뉜다.
JEUS : Ent 와 Std 로 나뉜다.
- 오픈소스(OSS)비지니스 제품군 - (오픈소스이기는 한데 돈내야 지원해준다)
JBoss EAP : Infinispan 기반으로 클러스터링 제공한다.
Resin : OSS 버젼과 Pro 버젼이 있으며 기본적으로 Clustering 기능이 있다. OSS 버젼은 Pure JAVA라 성능으로 따지만 Tomcat 이나 별반 차이도 없다.
- 오픈소스 제품군- (이건 기술지원 따위는 없다. 그냥 너님이 하는거다)
WildFly(구 JBoss AS) : Infinispan 이라는 Grid OSS 가 내부적으로 구현되어 있고 이기능올 클러스터링 제공
Tomcat : Clustering 기능이 최근에 추가 되어있다. 하지만 성능은 보장 못한다(않좋아...pure java 라넘 느려)
....
2. 근데 이거 꼭 써야해?
결론 부터 이야기하자... "아니다!"
세션을 유지한다는 것은 사용자 브라우져와 서버간의 접속이 유지되지 못하는 WEB의 특성상 (HTTP Protocol 은 stateless 라고 한다.)
한번 접속해서 화면 받아오면 상태(status)가 유실된다.
하지만 사용자의 상태가 유지되어야 로그인정보나 장바구니를 다시 볼 수 있기 때문에
이런 상태를 유지하는 것을 세션(Session)이라고 하며
이 세션을 유지하는 방법은 꼭 인프라(WAS) 에서 구현되어야 함은 아니다.
예를 들어 대규모 사이트의 경우 세션 정보를 WAS에서 복제하여 상태유지를 할 경우 세션을 모든 WAS가 동기화 하기위한 부하때문에 오히려 장애포인트가 되기도 한다. (Instance 여러개 + 사용자 대박!! 이면 WAS 지들끼리 세션 복사하다가 뻗어 버리기도 한다)
물론 JBoss 나 상용 WAS들은 이런 복제 Overhead 를 줄이기 위해서 몇몇 옵션등을 제공하기도 하므로 이런일로 고생하고 있다면 제품 지원팀에 문의해 보자.
(Sync 방식을 ASync 방식으로 바꾸거나, UDP 클러스터를 TCP로 바꾸거나 등등)
이러한 문제를 해결하기 위해서
WAS의 클러스터링 기능을 쓰지 않고
로그인처리시에 암호화된 세션정보를 사용자(브라우져)에 저장(쿠키)하도록 개발해서
세션을 유지 하기도 한다.
(사용자가 대박!인 글로벌 회사의 업무시스템 또는 대형 오픈마켓)
선택는 자유다.
단 팁을 준다면
2.1. 우리사용자가 졸라 많거나(동접 몇 만명 같이...) WAS 인스턴스가 너무 많아서 클러스터링을 하는게 부담스러운경우
(다수의 WAS를 Clustering 하는 경우 세션복제 Overhead 로 인하여 원래 1개 WAS 가 처리할 수 있는 능력이 감소한다)
상용 WAS 기준이라면
클러스터링 버젼(Enterprise)보다 Standard 버젼을 도입하고 세션을 쿠키로 유지하거나
그리드 솔루션이 있다(JBoss Data Grid, Oracle coherence, 국산도 있다 GTWorks )
쿠키를 쓰건 그리드솔루션을 사용하건 일단 개발자가 세션을 유지하기 위한 방법을 설계해야 하고 일부 세션 관리 코딩은 추가 되어야 한다.
개발자 학습비용 기준 : 코드기반으로 관리하려면 아키텍쳐 부터 설계필요
WAS Clustering < Grid Solution < 코드(Cookie) 기반
서버부하(Overhead) 기준 : Overhead 가 클수록 WAS 처리량은 낮아진다.
WAS Clustering > Grid Solution > 코드(Cookie) 기반
오픈소스기반이라면
여하간 Tomcat Clustering은 사용하지 말라
게시판 뒤져보면 알겠지만 아직 성능이나 안정성이나 그다지 좋다고 못하겠다.
JBoss EAP 자체의 Clustering 을 사용하거나 위에 말한 그리드 솔루션(JBoss Data Grid)을 같이 검토하도록 한다.
또 다른 방법으로 클러스터를 쪼개는 방법이 있다.
(나는 개인적으로 이 구조를 좋아하고 많이들 이렇게 한다...
근데...실제 운영해야하는 사람들이 WEB/WAS/HA등을 잘 모르면 맨날 장애를 일으킨다......
예를들어 공무원조직에 담당자는 그게뭔지 모른다...장애나면 사람부른다....사람도착할 때 까지 장애다.)
예를 들어 인스턴스가 8개라면 클러스터를 8개 통째로 묶는게 아니라
4개 + 4개 로 클러스터를 두개로 나누어 운영하도록 하고
사용자 트래픽을 웹에서 분산구조에서 제어해서 최대한 장애가 발생하지 않도록 한다.
WEB : 1,2 3,4
WAS : 1234 5678
위 구조에서 웹서버 1 또는 2로 들어온 사용자는 WAS1,2,3,4 로 접속이 되고 세션이 유지된다. 만약 was1,2,3,4 가 동시에 중지된다면 장애가 된다.
이러한 운영상의 논리적인 구조를 쪼개서 운영하는 경우 HA를 위하여 작업절차나 장애처리시 재구동 방법등을 세밀하게 조정하고 운영해야 한다.
(Ex, 배포후 재구동시 WAS를 1,2,3,4,5,6,7,8 순으로 재구동하지 말고 1,5,2,6,3,7,4,8 순으로 재구동 한다거나...)
2.2 걍걍 일반적인 업무 시스템 이라면
WAS의 Clustering 기능을 사용하도록 한다.
세션을 개발자가 코드상에서 생성하고 서버에 저장해서 유지를 한다는 일은......머리아프다....
기술적인 부하 문제가 없다면 Clustering 되는 제품간의 가격 비딩이 될 것이니...
알아서 하자.
3. JBoss EAP 에서 클러스터링 할 때 방법
아... 사실 Config를 하나하나 이야기 하려면 너무 많은 것을 설명해야 한다....
(UDP 냐 TCP 냐... 복제방식은 뭐냐...등등)
그냥 일단 클러스터링 되어 있다치고
개발자 입장에서 알아야할 세션 복제에 집중해서 적어본다.
일단 소스에서 /WAR_ROOT/WEB-INF/web.xml 파일안에 아래 볼드체가 있어야 동작한다.
<?xml version="1.0" encoding="UTF-8"?>
<web-app version="3.0" xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd">
<session-config>
<session-timeout>30</session-timeout>
<tracking-mode>URL</tracking-mode>
</session-config>
<distributable></distributable>
</web-app>두번째
세션 복제는 RMI 같이 네트워크 통신을 해서 복제 된다.
그래서 세션에 저장하는 모든 Object는 Serializable 해야 한다. (JAVA Spec)
이건 WAS 할아버지가 와도 지켜야 할 법칙이다. (제품 마다 다르다는 뻘소리 하지 말자)
복잡하게 세션 객체를 만들어 쓰는 개발자 라면 아래 같이 하자.
class UserSessionObj implements Serializable
{
}
UserSessionObj InstUserSessionObj = UserSessionObj();
InstUserSessionObj.setUDI = "이름";
....
session.setAttribute("SESSION_OBJ", InstUserSessionObj);
세번째
/WAR_ROOT/WEB-INF/jboss-web.xml 파일안에 이런게 있다.
없으면 만들어도 된다. 하지만 기본 값이 있으므로 클러스터링 부하로 인한 문제
또는 개발한 기능상 복제될 세션객체에 대한 제어가 필요하지 않다면 꼭 만들 필요는 없다.
아래 뻘건 글씨를 잘 보자, 일단 이게 기본값이다.
<jboss-web>
<context-root>/</context-root>
<replication-config>
<replication-trigger>SET_AND_NON_PRIMITIVE_GET</replication-trigger><replication-granularity>SESSION</replication-granularity>
<replication-field-batch-mode>true</replication-field-batch-mode>
.... 이거 말고도 잔뜩
</replication-config>
</jboss-web>
==========================================
웅??? 그게 뭐냐구???
메뉴얼 상에 글을 옮겨 보겠다.
SET: With this policy, the session is considered dirty only when an attribute is set in the session (i.e., HttpSession.setAttribute() is invoked.) If your application always writes changed values back into the session, this option will be most optimal in terms of performance. The downside of SET is that if an object is retrieved from the session and modified without being written back into the session, the session manager will not know the attribute is dirty and the change to that object may not be replicated.
>> 코드상에서 setAttribute()시 세션을 복제한다.
가장 클러스터링 부하가 낮다.
이렇게 해놓으면 값은 바뀌지만 복제가 안 될 수 있다.(코드 잘 짜면 그런 걱정 안해도 된다.)
세션에 저장되는 정보를 코드상에서 크게 컨트롤 하지 않는다면 부하를 줄이기 위해 사용해 볼 만 하다.
SET_AND_NON_PRIMITIVE_GET:(기본값) This policy is similar to the SET_AND_GET policy except that get operations that return attribute values with primitive types do not mark the attribute as dirty.
Primitive system types (i.e., String, Integer, Long, etc.) are immutable(수정불가능한), so there is no reason to mark an attribute with such a type as dirty just because it has been read.
If a get operation returns a value of a non-primitive type, the session manager has no simple way to know whether the object is mutable, so it assumes it is an marks the attribute as dirty.
This setting avoids the downside of SET while reducing the performance impact of SET_AND_GET. It is the default setting.
>> setAttribute()시 세션복제 + getAttribute()시 기본형(primitive type)들을 빼고 복제
(기본설정)
기본형(char,int,String, Integer**..등)는 재 할당은 가능하지만 할당된 값 자체를 변경할 수 없다. (이 객체들에는 set method가 없다) - 개발을 해보지 않으면 좀 해깔릴 수 있다. immutable 객체에 대한 내용을 인터넷에서 찾아볼 것을 권한다-
그래서 이 값들은 GET 하는 순간에는 변경이 일어나지 않았음을 보장할 수 있으므로 (대체한다는 것은 SET 을 수행했다는것을 의미하므로 이미 복제 되었다.)
GET할때 Primitive 형을 복제 대상으로 지정하지 않는다.
이 방식은 SET의 누락에 대한 위험(오류)성과
SET_AND_GET이 너무많은 데이터를 복제할 수 있는 위험(성능관련)을 적절하게 타협한 방식으로 기본값으로 적용되어 있다.
SET_AND_GET: With this policy, any attribute that is get or set will be marked as dirty. If an object is retrieved from the session and modified without being written back into the session, the change to that object will be replicated. The downside of SET_AND_GET is that it can have significant performance implications, since even reading immutable objects from the session (e.g., strings, numbers) will mark the read attributes as needing to be replicated.
>> setAttribute()시 세션복제 + Obj getAttribute()시 세션복제
세션에 속성으로 객체나 프리미티브정보를 최초생성 하거나 이 값에 접근할 때 여하간 복제한다.
SET 이나 SET_AND_NON_PRIMITIVE_GET 보다는 복제 부하가 크겠찌??? 그지??
ACCESS: This option causes the session to be marked as dirty whenever it is accessed. Since a the session is accessed during each HTTP request, it will be replicated with each request. The purpose of ACCESS is to ensure session last-access timestamps are kept in sync around the cluster.. Since with the other replication-trigger options the time stamp may not be updated in other clustering nodes because of no replication, the session in other nodes may expire before the active node if the HTTP request does not retrieve or modify any session attributes. When this option is set, the session timestamps will be synchronized throughout the cluster nodes. Note that use of this option can have a significant performance impact, so use it with caution. With the other replication-trigger options, if a session has gone 80% of its expiration interval without being replicated, as a safeguard its timestamp will be replicated no matter what. So, ACCESS is only useful in special circumstances where the above safeguard is considered inadequate.
>> HTTP 요청이 있으면 Session변경으로 간주하여 복제...여하간 무조건 복사
내 생각에 이거 하면 복제 트리거를 신경을 안써도 되니 간단해 보이지만 프로덕션환경에 적용하는 경우 그냥 사이트 무너진다고 보면 되겠다 (개인 홈페이지라면 상관없다)
.이상.
2015년 9월 22일 화요일
카렌스1 자가수리 두번째....예정.....
울집 자동차
2000년식 카렌스1 기화기달린 1.8
한 이년전에 왕창 수리하고 중간중간 소모품 갈면서 잘 버텼는데...
헨들이 삐딱하고 (직진하려면 틀고감ㅋ)
유리는 금간지 이년째 (유리본드 바르고 그냥 버팀)
뒷유리창 워셔액 안나옴
40km이상에서 브레이크 밟으면 덜덜덜
엔진에 노킹
실내등 껌벅껌벅.... (LED 등이라고 바꿨는데...싼게 비지떡!!!)
계기판 수온센서 메터가 흔들흔들~(차량떨림에 따라 흔들 거림....배선에 문제 있는듯...)
이거... 대충 견적 뽑으니 백오십만!!!
차 보험가가 200이 안되는덱!!!!
이래저래 고민하다가
RV로 올란도... 신차 3천. 중고 1천500백...
역시 고민만하고 또 한번 산소호흡기 대서 살려보기로..
=샵에서=
유리교환 18만
유리교환 18만
로어암 교체(이놈이 뭔가 충격을 받아서 살짝 휘었음... 헨들이...삐딱함) 얼라이먼트포함 20만
=DIY(주말에....부품사다가 갈았음...)
워셔펌프 교체 3만(하는김에 프론트도 교환)
워셔펌프 교체 3만(하는김에 프론트도 교환)
 |
| 패킹이다....대충딱아서 써도 되는대 500원 짜리라 그냥 바꿨다. |
 |
| 휀다 안쪽에 클립 빼고 + 범퍼 아래쪽 빼고 재끼면 워셔통에 두개가 끼워져 있다. 그냥 힘줘서 잡아 뽑으면 빠진다 |
점화플러그와 케이블교체 3만
열차단필름 3만5천
(아...같이온 헤라가 병신이라 -라기 보다는 시공한놈이 병신.... 누군가 하신다면 꼭 실리콘이나 고무헤라로 작업하시길....
오후에 시공하고 담날 보니..기스가 ㅠ.ㅠ 그냥 다녀 보기로.... 확실히 뜨거운건 덜함)
=추석맞이 공사 예정 (시골 부모님댁에 공구가 많아서....거기가서 조용히...) 구입한 물품
프론트 브레이크 드럼 2개 순정 6만8천
프론트 브레이크 패드 1셋 순정 2만2천
범퍼 도색용 위트실버 스프레이 3개 3만(페인트구입)
본네트 도색용 에보니블랙 스프레이 4개 외.... 10만(마스킹,사포,퍼티,프라이머,투명,검정등)
프론트 브레이크 패드 1셋 순정 2만2천
범퍼 도색용 위트실버 스프레이 3개 3만(페인트구입)
본네트 도색용 에보니블랙 스프레이 4개 외.... 10만(마스킹,사포,퍼티,프라이머,투명,검정등)
캬브레이터 크리너 1만원
녹전환제 2개 3만 (다 뿌리긴 뭐하고...조향, 휀다안쪽..가스통부분좀 처리해야 할듯..)
녹전환제 2개 3만 (다 뿌리긴 뭐하고...조향, 휀다안쪽..가스통부분좀 처리해야 할듯..)
폴리싱 패드 2만
상온흑색착색제 1개 1만
IPO 에바크리너 2개 1만 (누나꺼는 덤으로..)
작키 및 작키받침대 5만 (차에 하나 있는데...봉이 없어서 무용지물...새로구입+지지대 2개 1셋)
기타..윤활제,구리스,폴리싱컴파운드(맥과이어 UC), 고글, 부직포 작업복 2벌.....
대충 구입한 부품 및 자재 만 40만원어치 ....
Day1
1. 에어컨청소 (1H)
에바크리너 도포.....
3. 연료공급 청소 (3H)
기화기, 믹서, ISC밸브 청소 (대충...분해하지 말고....사고치지 말고...청소만 하자..)
2. 브레이크 계통 (4H)
드럼및브레이크 패드교체 --> 캘리퍼 청소 --> 조향장치 녹제거 -->타이어 장착
Day2
4. 하체 녹제거 (4H)
바닦 솔질로 녹털기 (디질듯....)
녹 제거제 도포
배기관 부분은 상온흑색착색제(고온이라....페인트나 언더코팅 등 다른건 안됨..)
뒤쪽 브레이크 부분 및 휀다 안쪽 녹제거
세차......
Day3
5. 도색 (????H)
앞,뒤 범퍼 긁힌곳만...--> 사이드 긁힌곳 복구
본네트 도색 (이거....졸라 걸릴듯)
운전석 문짝 녹썩은곳 갈아내고 도색
좌측 리어휀다 녹썩은곳 갈아내고 도색
무수히 많은......찍힌곳 폴리싱...아니면 이쑤시게 신공....
--------
다음에 처리할 부분
리어 브레이크 : 2000년식 카렌스 이지만...ABS&디스크방식임.... 뜯어서 상태보고 추가로 해야 할지도..
브레이크액 교환 : 유독성에...에어빼기가 지랄 맞아서 샵에 맞기는걸루
LPG 연료필터 : 구입하고 한번 갈았는데...한 5만 뛴듯....샵에서 교환한 일자 확인하고 봐서 교체(공임이 높아서 DIY 해야 할듯...)
엔진미미(엔진마운트) : 확실히 3번이 째졌고(바로 보임) 나머지는 숨어 있어 안보이고...(이번에 함 봐봐야 겠음) 이게..부품은 4개 다해도 5만원에서 왔다 갔다인데...난이도가 있어서 공임포함하면 20만원 넘어감ㅜ.ㅜ ...이건....다이하기에는....공구빨과 자신감이 부족하다....
... 사고치지 말고 잘하자....
2015년 9월 17일 목요일
상대적 박탈감에 대한 두번째 이야기
직장생활에서 상대적 우월감에 대한 쓰레기 같은 글을 적었었고
http://yckwon2nd.blogspot.kr/2013/08/blog-post_24.html
몇몇 과격분자들은 익명의 댓글로 공격을 시도 하기 도 했고
대부분은 침묵하는 그런 내용이였다.
이번에도 비슷한 이야기 이지만 약간 뒤집어 생각해 보기로했다
내가 상대적인 우월감을 성취했다면
결국 피대상자는 상대적인 박탈감을 가지게 되는것이 아닐까???
물론 아래 TED를 보면(전체 내용중 일부)
영장류가 가지는 이타심을 기반으로 다른 사람이 잘 되는 것을
호의적으로 받아들이는 사람이 없지는 않을 것이다.
내 경우
나와 소위 친한 사람들.. 누나, 와이프, 친한형님, 호감을 가지는 사람들...등 의 경우
뭔가 자신보다 우월한 행위
{
- 회사를 쿨 하게(?현실은 절대 그렇지않다) 때려치는 나를 보고 그걸 우월하다고 판단하기도 하고
- 멀리 스페인의 800Km 성지순례길을 걸었다는 자체에 대하여 우월하게 평가하기도 하며
- 아들과 같이 한달넘게 여행을 다닌다는 그 자체를 평가하기도 한다
}
에 대하여 순수하게 호의를 보이거나 감정이입을 하며 즐기는가 하면
일부는 기저에 깔린 질투, 시기심을 기반으로 내 행동에 따라 발생 할 수 있는 부정적 책임에 대하여 경고하기도 한다.
어느날인가 나는 내 즐거움을 위한 행동뒤에 따라오는 사람들의 이런 반응(긍정적 또는 부정적)에 대하여 선별하는 기술을 습득하게 되었다.
술한잔 하면서 넌지시 부정적인 키워드를 던졌을때 의 반응으로 그 기준을 정하는데
나 : "놀면서 돈을 너무 많이 써서 이제 한동안 힘들게 살아야되...여행이 좋은것 만은 아니야.."
부정적인 책임의 문제에대해서 긍정하는 반응을 보이는 경우
그 : "그렇지 앞일을 생각해서 열심히 지내야지"
상대방에게 내 즐거움을 너무 많이 이야기 하지 않기 위해 노력할 수 있게 되었다.
(상대가 더 힘들지 않도록 나름의 배려.....)
그렇다고 '그' 들이 회사에서 벌어먹느라 아무것도 못하고 숨만 쉬고 있는것은 아니다
종종 근교에 바람을 쐬러가기도 하고 여름때면 멋진 곳으로 여행을 가기도 한다.
헨드폰을 종종바꾸고, 얇고 가벼운 패드를 구입하고 소비의 자유를 한껏 누린다.
역으로 나는 그런 그들에게 질투를 느낀다. 왜? 소비할 돈이 없으니까(다 써버린다 ㅠ.ㅠ)
어짜피 자본주의사회에서 직딩이라고 하는 위치의 자유는 "소비의 자유" 뿐이라고 생각하는데
너나 나나 소비를 하는 대상이 다를뿐 소비를 하고 있는 것은 마찮가지 아닐까
그런데 거기에서 나오는 우월감과 박탈감의 아우라는 왜 발생하는 것일까
워낙 오래된 이야기라 아는 사람이 많겠지만 아래 동영상의 원숭이 실험을 보면서 그 생각을 해보았다.
두 원숭이에게 돌을 주고 그 돌은 건내 주면 오이를 준다.
반복적으로(20번이 넘도록) 수행해도 두 원숭이는 별 문제없이 돌을 건내고 오이를 먹는다.
그러다 한쪽에게 돌을 건낸 보상으로 포도를 주면
다른 한쪽이 그것을 인지하고 그때부터 오이를 거부하고 분노하기 시작한다.
그저 재미있는 실험이라고 하기에는 좀 무섭다 싶었다.
돌을 건내는 행위가 소비라고 한다면 그에 대한 보상은 먹을것 인데
이 먹을 것이 오이 또는 포도냐 에 따라 원숭이는 분노한다.
내가 소비를 했을때 얻어지는 만족감은 절대적이어야 한다.
만약 내가 소비하고 받는것을 그저 "먹이"라고 판단한다면 분노를 하지 않을 것이지만
"상대방 보다 덜 한 먹이" 라고 판단하는 순간 결과는 달라진다.
결국 해결 방법은 내 행위에 대한 결과에 대한 만족은 '절대적으로 자기중심적 ' 이어야 한다는 생각이다.
그렇다고 이기적이거나 자존심을 이야기 하는 것은 아니다
약간 빠져서 자존심을 이야기 하면
자존심은 타인과의 비교와 평가에 의해서 얻어지는 긍정 이라고 한다면
자기존중감(자존감-self-esteem)은 자신이 할 수 있다는 믿음(자신감)을 포함한 자신을 있는그대로 받아들이는 긍정이다.
** self-esteem 은 영어로 자존심,자만심,자신감으로 표현 될 수 있지만 여기서는 자신감에 가깝지만 철학적으로 해석이 조금 다르다.
그래서 교육학자나 철학관련(리더십 책을 포함해서) 내용에서 자존감을 이야기 하고
"타인의 눈으로 자신의 삶을 살지 말라"
"아이들의 자존감을 높여주어야 한다"
"사회생활에서 자신을 존경할 줄 모르는 사람은 실패한다"
....
등의 말들이 복잡한 설명의 간략 버젼으로 소비된다.
여행을가서 자기가 좋은장소, 자기가 좋은 시간을 최대한 누려야 할 것을
동행자의 변덕, 불필요한 배려와 참견, 복장, 타고다는 차의 종류, 숙소의 훌륭함, 맛집에 대한 집착 등으로
자신을 위한 시간을 보내지 못하는 시간을 여행이라 할 수 있을런지
자기가 아직 무엇을 할 줄 아는지, 해야 하는지, 하고싶은지 알 지 못하는 미성숙한 아이들에게
짧게 잡아도 수천년의 역사에서 누적된 지식을 꾸겨 넣는행위 (교육 이라고 부른다)를 하면서
대학도 엄마가 검토하고 아빠가 승인한 학과를 가서 평생을 자기 선택없이 살다가
회사에 가면 '당신은 창의적인 사람입니까?" 라는 질문에 네이버에서 "창의적 이란?" 이라는 검색을 해야 하는 친구들에게
우리가 뭐라 해야하는지
실적이 나쁘다고 팀장이라는 사람에게 뺨을 맞으면서도 울면서 야근을 하며 전화하는 콜센터의 직원은
자기자신에 대한 존중이 있는 것인지
절대적 자기기준이 없는 사람은 힘들다
하다못해 점심시간에 내가 먹고 싶은것도 선택하지 못하는 "결정장애" 증상을 흔하게 보이면서 문제라고 생각못한다.
내가 내 삶에 만족 하지 못하고 (기껏 이렇게 주절 거렸는데 삶의 만족을 노예의 삶과 유사하게 생각 말기를...)
연봉협상때만 되면 분노하고
친구가 땅사면 배가 아프고
그가 대기업에 취직되면 느껴지는 그 상대적 박탈감의 메커니즘을 생각해 본다.
=====
아래는 위의 동물실험이 나오는 TED 강연의 Full 영상이다.
[TED] 동물들의 도덕적 행동 Frans De Waal (프란스 드 월) - 영장류 동물학자
2015년 9월 7일 월요일
해본사람은 안다
해본사람은 안다
대학이란게 들어가기 빡빡했지 그다지(나에게) 훌륭하지 않았음을
그 개고생 후에 들어간 회사의 허무함
사직서 제출이 그리 힘들었건만 퇴직후 첫날의 별것 없음이란
신혼첫날이 기대와 같지는 않았음을
이혼이 그리 두려웠는데 정작 혼자되니 데면데면한 그 일상이란 (아직 못해 봤다. 많이는 봤지만)
첫경험의 부족함 (나름 만족 스러웠던 것 같기는 한데.....)
처음 돈주고 만난 여자와 지낸 다음날의 자괘감
티켓을 거머쥔 손을 바라보던 두근거림과 목적지에 도착했을때의 그 당혹스러움
여행을 마치고 돌아와
만나자는 사람들과 함께 할 때, 정작 자기 이야기를 하고 싶은 그들을 볼때
근데....
살다보니 이것도 익숙해 지면 나름대로 만족도가 높은 선택을 할 수 있는것 같다는...
결국은 아는게, 아는게 아닌 상태로 계속 사는것 보다는
좀더 익숙하게 살아보는것은 어떨까...
달아서 헐어진 느낌이 들더라도
그렇게 익숙하게 사는것도 그 나름으로 좋겠지 싶다.
대학이란게 들어가기 빡빡했지 그다지(나에게) 훌륭하지 않았음을
그 개고생 후에 들어간 회사의 허무함
사직서 제출이 그리 힘들었건만 퇴직후 첫날의 별것 없음이란
신혼첫날이 기대와 같지는 않았음을
이혼이 그리 두려웠는데 정작 혼자되니 데면데면한 그 일상이란 (아직 못해 봤다. 많이는 봤지만)
첫경험의 부족함 (나름 만족 스러웠던 것 같기는 한데.....)
처음 돈주고 만난 여자와 지낸 다음날의 자괘감
티켓을 거머쥔 손을 바라보던 두근거림과 목적지에 도착했을때의 그 당혹스러움
여행을 마치고 돌아와
만나자는 사람들과 함께 할 때, 정작 자기 이야기를 하고 싶은 그들을 볼때
근데....
살다보니 이것도 익숙해 지면 나름대로 만족도가 높은 선택을 할 수 있는것 같다는...
결국은 아는게, 아는게 아닌 상태로 계속 사는것 보다는
좀더 익숙하게 살아보는것은 어떨까...
달아서 헐어진 느낌이 들더라도
그렇게 익숙하게 사는것도 그 나름으로 좋겠지 싶다.
피드 구독하기:
글 (Atom)