목적 함수(object function)

Policy Gradient 목적 함수

수식을 요약하자면 여러번의 에피소드를 해당 정책에 따라 수행했을 때 발생하는 누적 보상 기대 값이다.
하지만 위 수식은 현실적으로 불가능하다. 이유는 해당 정책에 대한 모든 궤적을 실제로 구할 수 없기 때문이다.

현실적으로 타협한 방법

따라서 에이전트가 직접 환경과 상호작용하여 샘플링한 데이터를 수집하는 방법으로 가능하다.
 

목적 함수 최대화하기

목적 함수를 최대화하기 위해 사용한 방법은 'Policy Gradient Theorm' 이다.
직관적으로 말하자면 목적 함수의 Gradient 를 구해서 Gradent ascent를 하는 방법으로 목적 함수를 최대화 한다는 것이다.

목적 함수의 미분

 하지만 문제가 있다. 미분을 해야하는데 수식에 기대값 항이 있다. 우리의 목표는 모든 궤적에 대한 누적 보상값을 최대화 하는 것이라서 기대값은 빠질수 없다.
그래서 이를 해결하기위해 강화학습을 연구하는 사람들이 아래 수식으로 유도했다.

  • 수식 유도에 필요한 지식은 'log 성질, 미분 간단한 지식, Likelihood Ratio Trick' 이다.
  • 이렇게 유도하여 기대값은 그대로 두고 미분항을 log 항으로 옮겼다.
  • 가장 아래에서 세번째 수식에서 두번째 수식으로 갈때에는 Casuality를 고려하여 t' < t 에서의 보상값에 영향을 끼치지 못한다는 점을 고려하여 수식을 재구성할 수 있다.

아래는 위 수식에 대한 python 코드이다.

for episode in range(1000):
    log_probs, rewards = sample_episode(env, policy_net)
    returns = compute_returns(rewards)

    ###
    # Policy Gradient Loss: -∑(G_t * log_prob)
    # loss += -log_prob * G : 
    # 1. loss 값에 모두 더하는 이유는 기대 값 때문
    # 2. log_prob에 -를 취하는 이유는 Gradient ascent를 하기위함 (pytorch의 backward 함수 설명 참고)
    # 3. log_prob에 미분항은 어디에?? loss.backward 수행시 자동으로 계산해줌 (pytorch backward 함수 설명 참고)
    ###
    
    loss = 0
    for log_prob, G in zip(log_probs, returns):
        loss += -log_prob * G

    optimizer.zero_grad()
    loss.backward()
    optimizer.step()

 
코드상에서는 log 항에 대한 미분이 안보이지만 이는 pytorch 내부적으로 자동으로 backward 수행시 자동적으로 미분 계산 해준다.
코드는 

backward 수행시

 
-가 붙은 이유는 Gradient ascent를 하기 위함이다.
 
이상 2년 넘게 미뤄온 Policty Gradient 수학적으로 풀어보기 완료!

어떻게 인생을 살아야 하는가

[250501] 캐묻지 않는 삶은 살 가치가 없다

'미덕에 관해 날마다 대화하는 것이야말로 인간에게 최상의 좋음' - 소크라테스의 변론 -

'캐묻지 않는 삶은 살 가치가 없다' - 소크라테스의 변론 -

소크라테스의 문단법 2가지

1. 반어법 : 어떤 문제에 대한 답을 알면서도 무지를 가장한 채 질문을 던지며 상대방과 함께 해답을 찾아가는 과정, 상대방이 정확한 정의를 내리지 못하는 '난론' 상태에 빠질 때까지 집요하게 논박하는 것이다. 이를 통해 상대방은 결국 자신이 아무것도 알지 못한다는 사실, 즉 '무지의 지'를 깨달았다.

2. 산파술 : 상대방이 스스로 진리나 지혜를 깨달을 때까지 질문을 던지는 것

풀리지 않는 문제의 해답을 찾는 가장 쉬운 시작은 가만히 관찰하는 것이다. 성급하게 결론을 내리기 전에 현상을 있는 그대로 바라보는 것이다.

[250504] 무지를 깨닳는 자만이 스스로를 돌본다

아무것도 모르는 무지한 사람이 되어라

'너 자신을 알라'

그는 당시 가장 명망 높은 사람들과 젊은이들에게 자기가 알지 못하는 것을 안다고 생각하는 '무지'야말로 비난받아 마땅하다고 목소리를 높였다.

이미 잘 안다고 믿으면 호기심이 생기지 않는다.

깊은 통찰을 얻을 기회를 날리는 셈이다.

내가 모른다는 사실을 안다는 건 알지 못하는 것을 적극적으로 배우려는 자세다.

 

[250505] 영원히 변하지 않는 절대 가치는 있다

타인의 생각은 어떠한지 상관하지 않고 나의 절대적인 기준을 내세우는 태도는 경계해야 한다.

그러나 도덕의 영역에서 옳고 그름에 대한 기준은 절대적으로 지켜야 할 것이다.

 

[250506] 이상주의자가 될 것인가, 현실주의자가 될 것인가

아테네 학당 가운대 하늘을 가르키는 남자는 플라톤, 그 오른쪽은 아리스토텔레스(출처 : 나무위키)

플라톤

  • 이상주의자
  • 이데아론 주장
  • 플라톤의 이데아는 '~자체'라고 표현하면서 '존재하는 모든 개체의 본성'이라 말한다.  

아리스토텔레스

  • 현실주의자
  • 먼 미래나 가능성보다는 지금 눈앞의 놓인 물질적 가치를 중요시함

플라톤과 아리스토텔레스가 손으로 가리켰던 곳은 달랐지만, 두 철학자가 사물의 본질을 이데아, 즉 형상에서 찾고있다는 점에서는 차이가 없다.

이상과 현실 사이에서 방황할 때 가장 필요한 것은 온전한 자기 자신의 모습을 발견하는 것뿐이다.

[250508] 우리는 그림자를 진짜라고 믿고 있지 않을까

스스로 깨달은 참된 지혜는 누구도 훔쳐 갈 수 없다.

지성과 용기, 미덕과 지혜 등 눈에 보이지 않는 가치들을 깨닫기 위해 노력할 때 우리는 그림자와 쇠사슬에서 해방될 수 있다.

[250509] 욕망과 투쟁하고 타협하라

인간의 영혼은 이성, 기개, 욕망의 세 부분으로 이루어져있다.

  • 이성은 혼 전체를 보살피고 지배하는 것, '지혜'와 가까움
  • 기개는 인간을 분노하게 하는 것, '용기'와 가까움, 기개가 쾌락과 고통에 휩싸여도 두려워하지 않고 이성의 지시를 끝까지 보전하는 것
  • 욕망은 사랑과 배고픔과 갈증을 느끼는 것. '만족'과 '쾌락'과 가까움, '절제'라는 덕을 필요로 한다.

시와 예술을 통해 감수성을 배워야 한다.

"이성으로 혼 전체를 보살피고 지배하라." - 플라톤 -

 

어떻게 더 인간다운 삶을 살 것인가

[250512] 인간다운 사람만이 행복해질 수 있다 -미덕-

"미덕이 곧 지식이다."

"기회는 준비된 사람의 몫"

탕진하는 삶보다 가치를 생산하는 삶이 나를 더욱 행복하게 만들어줄 것이다.

하루아침에 벼락부자가 될 것처럼 요행을 바라거나 타인의 지위를 이용해 더 나은 삶을 꿈꾼다면 예상하지 못한 상황이 들이닥칠때 쉽게 무너져 버리고 말 것이다.

 

[250516] 몸은 영혼의 감옥이다 -영혼과 육체-

영혼은 육체에 숨 쉴 능력과 새로운 활력을 불어넣는다.

영혼은 육체 전체의 본성을 유지하고 지탱한다.

육체는 영혼의 '무덤'이다.

육체는 영혼의 '표지'이다.

육체는 영혼의 '감옥'이다.

'혼의 최선의 상태'에 관심을 기울이는 것이란 바로 자신이라는 감옥 안에 갇힌 어두운 영혼에 빛을 비추어주는 일이다.

혼의 최선의 상태에 관심을 기울여라.

중요한 건 허한 자신의 마음을 알아주는 것이다.

 

[250517] 삶의 고통을 회피할수록 무기력해진다 -교육-

자신을 다스릴 미덕을 키운다.

올바른 교육은 우리가 미덕과 악덕을 분명하게 구별하고 자신의 욕망을 스스로 이길 수 있는 능력을 키우게 하는 것이다.

인의 실천은 다른 사람이 아니라 자기 자신에게 달렸다.

쾌락과 고통의 감정을 훈련한다.

교육이란 쾌락과 고통의 감정을 제대로 배우는 과정입니다. -법률-

[250518] 죽음이란 영혼의 해방이다 -죽음-

사람들을 심란하게 하는 것은 죽음 자체가 아니라 죽음이 두렵다는 생각이다.

우리의 인생을 죽음이 아니라 삶으로 파고들 때 그 진가를 발휘한다.

[250520] 의심하는 사람만이 진실에 가까워진다 -선분의 비유-

완전한 앎으로 향하는 지식의 네 가지 단계

1. 상상 : 가장 낮은 수준의 인식능력으로 상상, 추측이다. 오직 동굴 벽에 비친 그림자를 실물이라 믿었던 죄수와 비슷하다.

2. 신념 : 세계의 실제 대상을 봄으로써 생기는 정신의 상태다. 타인의 해석을 통해 인식하는 상상 단계보다 명확성이 더 높다.

3. 추론적 사고 : 기하학처럼 가설로부터 결론을 이끌어 내는 수학적 대상에 관한 지식이다.

4. 지성 : 가장 높은 인식능력의 단계를 의미한다. 감각적 대상으로부터 완전히 벗어나 직접적으로 실재하는 이데아들, 즉 형상들을 인식한다.

모호하고 불확실한 상황에서는 차라리 아무런 말도, 아무런 생각도, 아무런 행동도 하지 않는 편이 더 나을지도 모른다.

[250521] 눈에 보이지 않는 세계를 바라보는 힘 -지성-

눈에 보이는 세계안에 살고 있는 우리는 이세계가 전부인 것처럼 착각한다.

고통스러운 현실 그 이상을 보는 눈은 처음부터 주어지지 않는다.

진정한 앎데 도달하기 위한 순서

첫째 눈앞에 보이는 현상에 머물지 마라

둘째 지성의 노예가 되어라

셋째 대체 그것이 무엇을 의미하는지 질문하라

넷째 마음의 눈을 정화하라

 

어떻게 더 행복한 삶을 살 것인가

[250525] 진짜 행복은 누구도 빼앗지 못한다 -태양의 비유-

참된 행복은 운명적으로 나타났다가 사라지는 것이 아니라 자신의 마음 상태에 있다. 진정한 행복은 영혼의 안정과 만족에 있다.

운명에 흔들리는 삶은 불행하다.

'Book > 인문학' 카테고리의 다른 글

마흔에 읽는 니체  (0) 2025.03.01

니체의 인생 설명서

[250305]  위험하게 살아라 -신의 죽음-
익숙함과 결별하고 내가 원하는 나로 살아라
내가 원하는 나로 산다는 것은 창조자로서의 삶을 산다는 것이다
위험하게 살아라! 도시를 화산 위에 세우고, 미지의 바다로 항해를 떠나는 위험한 삶을 선택하라



[250306]  오히려 우리는 권태가 필요하다 -니힐리즘-
권태는 위기가 아니라 전환기이다.
자기 삶의 진정한 목표를 향해 나아갈 동력을 얻는 때이다.
반복되는 삶이 주는 허무주의는 결국 의식의 변화를 일으킨다. 이 순간이 질문할 때이다.
‘내 인생의 의미는 무엇인가?’



[250307]  사람은 극복되어야 할 그 무엇이다 -초인-
자기 자신을 사랑한다.
“그대들의 이웃을 언제나 자신처럼 사랑하라. 하지만 우선 자기 자신을 사랑하는 자가 되도록 하라”
자기 자신을 하나의 프레임에 가두지 말고 다양한 모습의 나를 인정하는 것이 진정으로 나다워지는 길이다.



[250308] 의욕할 수 있는 자가 되어라 -힘에의 의지-
하루하루를 자신의 재능을 드러내기 위한 배움의 시간으로 보내야 한다.



[250309] 너의 오두막에 불을 질러라 -모든 가치의 전도-
세상에 절대적인 것은 없다. 삶은 어쩌면 니체의 말처럼 오류투성이일지도 모른다. 하지만 삶의 오류들 때문에 불편함을 느낄 때 우리는 성장할 수 있다.



[250310] 네 운명을 사랑하라 -아모르파티-
피할 수 없는 운명이라면 너그럽게 사랑하라 그리고 더 깊이 감사하라

 

[250311] 영원을 넘어, 지치지 않고 처음부터 다시 한번 -영원 회귀
초인은 과거나 미래로부터 자유로운 인간이다. 초인에게 가장 소중한 것은 이 순간이다.


니체의 운명 관리론

[250312] 성스러운 긍정이 필요하다 -정신의 세 단계 변화-
낙타 정신 : 무거운 짐을 지고 버텨 내는 삶의 태도(강인한 정신, 인내심)
사자 정신 : 무거운 짐을 부정하고 파괴한다. “너는 마땅히 해야 한다”라는 명령에 맞서 “나는 하길 원한다”라는 자유 의지의 주인이 된다. (자유)
아이 정신 : 어린아이가 놀이에 흠뻑 빠져 몰두하듯 자기의 삶을 긍정적으로 살아가는 것을 의미한다. (순진 무구함, 망각, 새로운 출발, 놀이, 스스로 도는 수레바퀴, 최초의 움직임, 성스러운 긍정)


[250313] 너 스스로가 되어라 -신체-
이번 삶의 여행을 위해 영혼이 선택한 몸을 더욱 사랑하라.


[250314] 3. 사다리 하나만으로 먼 곳까지 휘둘러볼 수 없다. - 시도와 질문-
명사형의 세계에 익숙한 나머지 동사형의 세계로 이행을 두려워하며 저항한다. 하지만 변화무쌍한 동사형의 세계에서 경험을 통해 쌓은 지혜는 누구도 빼앗아 갈 수 없다.
명사형이 아닌 동사형의 삶을 추구할 때 비로소 "우리는 진정 누구인가?"라는 질문에 답할 수 있는 것이다.
마흔, 자기 삶에 던져야 할 질문을 구체적이고 현실적으로 적어 내려가야 할 때이다. 


[250317] 제대로 잘된 인간이 되어라 -인간 말종-
제대로 잘된 인간은 자신의 욕구나 욕망을 통해 진정한 자신을 재발견한다. 다시 말해 진정으로 행복한 삶을 살려면 자신이 원하는 것, 소유하고 싶은 것, 삶에서 체험하고자 하는 것이 무엇인지를 알아야 한다.
몸과 마음이 불타 버리는 시기라도 자신을 사랑하는 방법을 잊지 마라.


[250320] 역풍을 만나 보아야 어떤 바람에도 항해할 수 있다. -몰락-
힘의 느낌, 힘에의 의지, 용기, 긍지 같은 것들은 추한 것과 더불어 하강하며, 아름다운 것과 더불어 상승한다.
상승에서 하강으로, 하강에서 상승으로 전환될 때 우리가 취해야 할 행동은 판단을 보류하는 것이다.
경멸과 몰락, 인생의 하강과 막다른 길은 변화의 성장통이다.
고대 그리스의 회의론자들은 ‘판단 중지’라는 의미로 에포케(epoche)라는 용어를 사용했다.


[250321] 이미 정해진 것은 없다 -우연과 필연-
긍정은 우연을 필연으로 만드는 강력한 에너지이다.




니체의 자극제

[250322] 너는 네 삶의 주인이 되어야 한다 -자유정신-
너는 너의 주인이며 동시에 네 자신의 미덕의 주인이 되어야만 했다. 과거에는 미덕이 주인이었지만, 이제 미덕은 오로지 도구로 써만 의미가 있다.


[250323] 고결한 귀족이 되어라 -거리의 파토스-
고귀한 인간은 자기 자신에 외경심을 가지고 있다.
고귀한 인간은 허영심을 싫어한다.
고귀한 인간은 타인의 인정을 받으려는 생각을 하기보다 자기 자신을 먼저 인정한다.


니체의 마지막 질문

[250330] 고통에 대한 처방은 고통이다 -고통-
고통을 정면으로 응시하라
고통을 열망으로 바꾸어라
불행하고 고통스러운 삶이 우리를 단련한다




[250402] 고통을 감당할 힘을 보여주어라 -고독-
자신과 자연 속에서 가장 깊이 반성하는 15분을 가져라
너는 너 자신의 불길로 너 자신을 태워 버릴 각오를 해야 하리라. 먼저 재가 되지 않고서 어떻게 새롭게 되길 바랄 수 있겠는가!




[250403] 무엇이 선이고 무엇이 악인지 모른다 -르상티망-
주인 도덕 : ‘좋음’이 무엇인지를 지배자가 스스로 결정한다. 그들이 바로 ‘고귀한 인간’이다. 고귀한 인간은 자신에게 긍지와 자부심을 느낀다.
노예 도덕 : 주인 도덕을 호의적인 시선으로 보지 않고 증오한다. 이 감정이 바로 르상티망이다. 강자를 부정하다가 ‘악한 인간’으로 규정하고 이와 대조적인 ‘선한 인간’을 생각해 낸다. 노예 도덕은 약자는 무조건 ‘선’이고, 자기보다 강한 지배자는 모두 ‘악’으로 규정한다.




[250404] 나만의 작은 행복 정원을 꾸며라 -니체의 행복론-
행복한 시대는 없지만 언제든 지금 이 순간 행복할 수 있다.


[250405] 죽음을 맞이하는 법을 배워라 -죽음-

결코 제때에 살지 못하는 자가 어떻게 제때에 죽을 수가 있겠는가?

제때에 살아 본 사람만이 제때에 죽을 수 있다는 것이다.

제때에 죽기 위해서 매 순간 '메멘토 모리' 해야 한다. (메멘토 모리 : 죽음을 기억하라)

제때에 살고 제때에 죽어라.


[250406]이 세계를 있는 그대로 인정하라 -디오니소스적 긍정-

우리가 경험한 모든 것이 우리를 고귀한 인간으로 만든다.

 


후기

일하다보면 능동적인 사람, 수동적인 사람을 볼 수 있다. 꼭 2 부류로 떨어지지는 않는다.

나는 능동적인 사람이다. 일을 하면서 계획을 짜고 개인적으로 WBS로 만들고, 동기 또는 후배에게 일을 나눠준다.

여기서 계획을 짜고 WBS를 만드는 과정에서 나는 여러 생각을 하게 된다.

'이게 맞는 방향일까?', '계획이 부족한 건 없나?', '내가 너무 일을 던지나?', '다른 사람은 어떻게 생각하지?' 등..

생각을 보면 일을 잘하려고 하는 노력도 있지만 남의 시선도 신경 쓰는 경향이 있다.

니체는 자기 자신의 주관을 가지고 옳고 그름을 스스로 판단하라 했다.

맞는 말이다. 하지만 너무 극단적으로 스스로 판단하는 거는 문제일 것 같다.

이에 따라 스스로 판단해도 괜찮을 일, 다른 사람에게도 평가받은 후에 판단해도 괜찮을 일인지 구분할 필요가 있어 보인다.

다음은 인생애이다.

제때에 죽기 위해서는 제때에 살라고 했다.

나는 지금 까지 미래를 생각하며 준비하고, 도전하고, 투자했다.

그러다 보니 현재를 소홀히 하는 경향이 있었다.

앞으로는 미래도 생각하며 계획하지만, 현재에도 충실하고 행복을 즐길 줄 알아야겠다.

 

끝.

 

'Book > 인문학' 카테고리의 다른 글

플라톤의 인생 수업  (0) 2025.04.30

Kubernetes(K8s) 의 구조

  • 크게 Kubernetes Cluster가 있음
  • 그 안에 Master와 여러개의 node가 있음
  • DevOps (개발자)는 mater를 통해 개발하고 배포
  • User(사용자)는 외부에서 Service, Ingress Object를 통해 사용

  • kubectl 은 서비스 호출 클라이언트
  • master에 API 서버와 상태 저장소를 관리
  • node에 각 서버의 에이전트(kubelet)와 통신하는 구조

Master

  • Master는 API Server, Scheduler, Controller Manager, etcd로 구성됨
  • API Server
    • 대부분의 요청을 처리하는 담당, 중요한 역할 임으로 다중화를 함
    • 모든 컴포넌트들은 API 서버를 통해서 커뮤니케이션을 함
    • 인증 및 인가 기능도 보유함
  • Scheduler
    • 컨테이너를 어떤 노드에서 가동할지 결정하는 컴포넌트
    • 노드들의 정보를 파악하고 컨테이너를 가동할 노드 선택
  • Controller Manager
    • K8s 클러스터의 상태 모니터링
    • Desired state를 유지함
    • 실제 요청 된 state와 현재 시스템의 state에 차이가 있는지 감시 -> 다를 경우 같은 state가 되도록 조치
  • etcd
    • 분산 key-value 저장소임
    • 클러스터의 모든 설정, 상태 데이터를 저장함
    • Scheduler와 Controller Manager 등이 API 서버를 통해 etcd의 데이터 조회 및 갱신
    • 마스터에서 분리하여 독자적으로 구축이 가능

Node

  • Node는 kube proxy, kubelet, 다수의 pod로 구성됨
  • Kubelet
    • Master로 부터 생성 요청을 받으면 컨테이너 생성
    • 컨테이너의 상태를 모니터링
    • 컨테이너의 상태를 Master의 API 서버로 전송
  • kube proxy
    • 각 노드에서 실행되는 네트워크 프록시임
    • 노드의 네트워크 규칙을 유지 관리함
    • 내부 네트워크 세션이나 클러스터 바깥에서 컨테이너로 네트워크 통신을 할 수 있도록 
  • pod
    • 1개의 독립적인 컨테이너임
    • Kubelet이 생성 시킴

K8s Objects

  • 대규모 분산 환경에 필요한 요소들이 추상화 되어 있음
  • 컨테이너, 애플리케이션 수행 방식, 네트워크 등을 추상화 함
  • 추상화 한 것들을 Object라 함

K8s 는 기능 별로 아래와 같은 Object로 구성됨

  • Application 및 배포
    • Pod, ReplicaSet, Deployment, DaemonSet, StatefulSet...
  • 네트워크
    • Service, Ingress..
  • 설정 정보 관리
    • ConfigMap, Secrests
  • 배치 잡 관리
    • Job, CronJob

Pod

  • K8s에서 배포할 수 있는 가장 작은 단위
  • 한 개 이상의 컨테이너와 스토리지, 네트워크 속성을 가짐
  • Pod에 속한 컨테이너는 스토리지와 네트워크를 공유하고 서로 localhost로 접근 할 수 있음
  • 컨테이너를 하나만 사용하는 경우도 반드시 Pod로 관리해야함

ReplicaSet

  • Pod를 여러 개 복제하여 관리
  • Pod를 생성하고 개수를 유지하려면 ReplicaSet을 사용함
  • ReplicaSet는 아래의 설정 정보를 포함
    • 생성할 Pod를 복제할 개수
    • 생성할 Pod의 설정 정보

Deployment

  • K8s에서 실제 배포를 진행하는 기본 단위
  • 배포 전략 선택
    • Rolling Update
    • Recreate
  • 배포 Revision 관리 및 Roll Back 수행
  • 배포와 관련 된 다양한 기능 및 옵션 제공

DaemonSet

  • 클러스터 전체에 Pod를 띄울 때 사용하는 Controller
  • 항상 모든 Node에 특정 Pod가 실행 됨
  • 새로운 Node가 추가되면 자동으로 Pod 실행됨
  • 로그 수집기나 모니터링 에이전트 등 실행하는 용도

StatefulSet

  • K8s의 대부분의 Objet는 Stateless임
  • StatefulSet은 state를 유지하는 Pod를 위한 Object임
  • Volume을 사용해서 데이터를 저장하고 Pod 재기동 시에도 유지 가능
  • DB 등을 컨테이너화 할 때 사용 가능

Service

  • 네트워크와 관련된 Object임
  • Pod 간 연결 및 Pod와 외부 네트워크를 연결
  • 여러 개의 Pod에 대한 내부 로드밸런서
  • 내부 DNS에 서비스 등록하여 서비스 디스커버리 역할도 수행
  • Pod에 대한 L4 로드밸런싱 수행
  • 옵션 지정 가능
    • Cluster IP : 클러스터 내부에서만 통신 목적
    • Node Port : 외부로 IP Address를 노출
    • Load Balancer : 클라우드 서비스의 Load Balancer 기능 사용

Ingress

  • 외부 트래픽을 받는 Object임
  • http / https 등 L7 레벨로 라우팅 규칙, 로드밸런싱 규칙 등도 포함함
  • Service도 외부로 노출 가능하지만 L4 레벨만 가능
  • 일반적으로 K8s 클러스터를 외부로 노출 할 때에는 Ingress 사용

ConfigMap, Sercret

  • 설정 정보를 Key/Value 형태로 저장하고 Pod에서 참조

Job, CronKob

  • 배치 처리를 위해 특정 조건에 따라 작업이 수행 됨을 보장
  • 실패하면 자동 재 시작 하여 처리

Label과 Selector

  • K8s 내부 자원 관리를 위해 Label을 붙임
  • Selector를 이용해서 특정 Label이 붙여진 자원을 Filtering

Manifest 파일

  • K8s에서 선언적 설정을 위해 Manifest 파일을 사용함
  • YAML, Json 과 같은 파일로 작성 함
  • 리소스의 종류와 원하는 상태를 입력함
  • 식당 주문서와 유사함
  • Master 로 명세 파일을 제출하면 Master 에서 읽고 명세된 정보가 유지되도록 실행
  • 구성 요소
    • apiVersion : K8s API 버전 정보 
    • kind : Object의 종류
    • metadata.name : Object의 이름
    • spec : Object의 상세 정보

 

MSA를 구축하고 호스트 서버, 컨테이너를 관리할 때에는 아래의 기능이 필요

  1. 대량의 컨테이너를 쉽게/자동으로 관리하기 위해 사용
  2. 다수의 호스트(서버)를 하나의 클러스터처럼 사용
  3. 여러 개의 호스트(서버)에 컨테이너 배포
  4. 서비스 디스커버리로 서비스들을 연결
  5. 부하가 생기면 서버를 자동으로 Scale-out
  6. 장애가 발생하면 기존 컨테이너 kill 후 새로운 컨테이너 다시 생성
  7. 컨테이너 Health Check
  8. 컨테이너 간 Storage 및 Network 관리

Kubernetes

  1. 컨테이너 오케스트레이션 도구
  2. 분산 환경에서 대규모의 컨테이너 관리
  3. 이외 Docker Swarm, Apache Mesos/Marathon 등 도구들이 있음
  4. Kubernetes가 그중 거의 표준처럼 사용
  5. 멀티 호스트에서 컨테이너 관리
  6. 컨테이너 배포
  7. 컨테이너 간 네트워크 관리
  8. 컨테이너 모니터링
  9. 컨테이너 업데이트
  10. 장애 발생 시 자동 복구

Kubernetes 철학

  1. 철학 1 : Immutable Infrastructure
    1. 클라우드 환경에서 자원들을 간단하게 구축하고 파기 가능
    2. 한번 구축한 인프라는 수정하지 않음
    3. 원하는 상태를 만들어서 새로운 환경을 구축
    4. 현재 운영되고 있는 인프라의 상태를 관리
    5. 서버의 Java version은 올려야 하는 경우 업데이트한 Java version을 담고있는 컨테이너를 배포
  2. 철학 2 : Declarative Configuration
    1. 명령형이 아닌 선언형
      1. 구구절절 노노 -> 정해진 것 하나 shell 스크립트 하나 실행 시키듯.
    2. 원하는 상태를 만들기 위해 명령어를 하나 씩 치는 방식이 아님
    3. 원하는 상태를 기술하여 Kubernetes에 적용
    4. 원하는 상태 = 시스템이 되어 있어야 할 모습
      1. 앱을 클러스터 안에서 몇 개 올릴지
      2. 네트워크 구성은 어떻게 되어야 할지
    5. Desired State


      어떤 컨테이너들이 어떤 노드 위에서 동작 할지
      1. 컨테이너들이 replica set이 몇 개가 되어야하는지 등.. 
      2. 관리자가 최종적으로 바라는 상태
      3. 현재 상태를 실시간 모니터링
      4. 관리자가 설정한 원하는 새로운 상태를 주문하거나 클러스터의 상태가 변경되면  Kubernetes가 원하는 상태로 조정
  3. 철학 3 : Self Healing
    1. 장애 발생 시 자동으로 복구
    2. 사람의 개입을 최소화 함
    3. 시스템이 되어 있어야 하는 상태를 항상 감시
    4. 원하는 상태와 다를 경우에 자동으로 복구

 

 

 

 

Docker Swarm

  1. 설치와 사용이 Kubernetes에 비해 단순
  2. 단 대용량 분산환경에서 사용하기에는 기능이 부족
    1. 모니터링 기능 부재
    2. 스토리지 옵션 기능 부재

Apache Mesos/Marathon

  1. 분산 시스템 커널
  2. 분산 된 CPU, memory, storage 등을 추상화 하여 하나의 단일 리소스처럼 만듦
  3. Marathon은 컨테이너 관리 도구
  4. Mesos와 Marathon의 통합으로 대규모 환경의 컨테이너들을 관리할 수 있음

 

도커

  1. 컨테이너라는 독립적인 공간에서 동작하는 프로세스를 제공함
  2. 가상화 기술 중 하나
  3. 기존의 가상화 방식은 주로 OS를 통째로 가상화했음
  4. 동일한 컨테이너로 동작 시킬 시 컨테이너 위에서 동작하는 Application은 모두 동일한 환경(OS, 언어 런타임, 프레임워크 버전 등)에서 동작하게됨
  5. 변화하지 않는 실행 환경으로 Idempotency 확보
  6. 모든 대상 환경에 Dockerfile 파일을 통해 실행 환경 구축 가능
  7. 시스템을 구성하는 Application 및 미들웨어의 관리 용이성 증가

왼쪽 기존의 VM을 이용한 가상화, 오른쪽 도커 컨테이너를 이용한 가상화

MSA에 대한 성숙도 평가 방법은 표준은 없음

표준은 없으나 어느 정도 참고할만한 자료들이 있음

아래 2가지 사례는 유명 기업에서 사용하고 있는 평가 지표임

Rajesh RV 성숙도 모델

Application, Database, Infrastructure, Monitoring, Process 로 구분하여 Level을 적용함

  1. Application : 모놀리틱 -> API 기반 
  2. Database : 1개의 Fit한 DB -> Data Lake, 실시간 분석
  3. Infrastructure : 물리적 기계 -> 컨테이너
  4. Monitoring : 인프라만 모니터링 -> 로그 매니징 기반 중앙화
  5. Process : 폭포수 -> DevOps

Rishi Singh 제안 성숙도 모델

총 9개 영역에서 4 단계의 성숙도로 평가

  • Expanding 단계가 현실적인 MSA 수준임
  • Mature 단계는 이상적인 MSA 수준임 

마이크로서비스를 도입하는데 앞서 아래 4가지 capabailties이 내재되어 있어야함

Core capabilities- 서비스 별 배포 되는 SW 패키지에 필수 요소

Supporting  capabilities  - 지원 기술 및 설계 패턴

Infrastructure capabilities  - 컨테이너 및 컨테이너 오케스트레이션

Process & Governanace capabilities   - DevOps 및 문서화 

MSA 도입을 위해 필요한 4가지 역량(Core, Supporting, Infrastructure, Process & Governanace)


Core capabilities

 

Core capabilities은 단일 서비스 내에 패키징 되는 SW 컴포넌트들(구현체) 이다.

  • 서비스 Listener : 외부로부터 request 받았을 때 Endpoint로 전달하는 역할
  • Endpoint : 받은 request를 SW 컴포넌트로 전달하는 역 
  • Application  : 서비스 구현체 
  • 데이터 저장 : 단일 서비스의 데이터를 담고 있는 저장소

서비스 Listener

  • HTTP 등의 Listener 가 애플리케이션에 내장되어 있어야함
  • 새로운 서비스를 개발 했을 때 배포를 쉽게 하기 위함
  • 일례 : Web Server, Web Application Server, Spring Boot 같은 Self Contained 방식
  • tomcat 등의 WAS가 설치 되어 있고 앱을 WAS에 배포하는 형식은 하면 안됨, 새로운 서비스에 대한 배포가 힘듬

Endpoint

  • HTTP 요청을 받아 처리 할 API가 애플리케이션 내부에 있어야함
  • 다양한 프로토콜 사용 가능

Application

  • 서비스 로직의 구현체
  • 로직은 단일 책임의 원칙을 지켜야 함 (1기능만 수행)
  • 응집도 높게 구현, 계층형 아키텍처를 사용하는 것이 좋음
  • Hexagonal architecture를 만족해야함
    • 외부 기술과 분리시켜야함
    • 일례 1 DB를 무엇을 쓰던 비즈니스 핵심 로직은 변경이 필요 없어야함
    • 일례 2 Queue를 무엇을 쓰던 비즈니스 핵심 로직은 변경이 필요 없어야함
    • 일례 3 모바일/웹 등 UI에 따라서도 비즈니스 핵심 로직은 변경이 필요 없어야함

데이터 저장

  • 각 서비스 마다 데이터를 저장할 데이터 소스가 있어야 함
  • 데이터소스는 하나의 서비스에 한정 되야 함
  • 각각의 서비스는 데이터에 대해 독립적 이어야

Infrastructure capabilities

Infrastructure capabilities 아래 3가지의 역량이 필요함

  1. 클라우드
  2. 컨테이너 런타임
  3. 컨테이너 오케스트레이션

클라우드

  • On Demand
  • 대용량 확장 가능한 환경
  • 몇 번의 클릭만으로 리소스 사용 가능해야함
    • Auto Scaling으로 자동화 된 Provisioning
  • 다양한 자원/서비스 제공
    • 컴퓨팅 자원, DB, NoSQL, Big Data, AI

컨테이너 런타임

  • 각 서비스들이 다양한 기술 사용
  • 수백/수천 개의 인스턴스에 배포 해야함
  • 컨테이너 기술을 이용하여 빠른 환경 구성 및 배포 필요
    • 컨테이너 이미지에는 런타임과 코드가 동시에 존재
  • Docker

컨테이너 오케스트레이션

  • 많은 수의 컨테이너의 관리 역량 필요
  • 배포, 모니터링 등 운영 관리 비용을 최소화 하기 위함
  • Kebernetes

Supporting  capabilities 

  1. Service Discovery
  2. Config Server
  3. API Gateway
  4. SW Defined Load Balancer
  5. Circuit Breaker
  6. Distributed Tracing
  7. Data Lake
  8. Messaging

 

Service Discovery

  • 서비스 개수 및 인스턴스 개수가 급증함으로 전체 Topology가 복잡해
  • 한 서비스에서 다른 서비스를 호출 할 때 필요한 정보를 유지하는 것이 복잡해짐 (Service IP, Port 등..)

Service A가 Service B를 호출 할 필요한 정보 다루는 것은 Service가 증가 할 수록 복잡해짐

  • 중앙에서 시스템의 모든 서비스에 대한 정보를 저장
  • 새로운 인스턴스가 생성되면 중앙 시스템에게 자신의 정보를 등록
  • 서비스 간에는 다른 서비스의 정보를 유지해야 하는 기능을 제거
  • DNS 서버를 이용 하듯이 서비스를 호출할 인스턴스는 호출할 서비스의 이름(getAccount 등..)을 이용해 호출
  • 중앙 시스템은 인스턴스 및 서비스를 추가 삭제 가능해야함

Register -> Discovery -> Connect

 

Config Server

  • MSA를 도입하면 서비스가 많아 지면서 Config 파일, OS 설정 파일들의 갯수가 급증함
  • Service 구동 환경마다 새롭게 빌드/패키징을 해야하게 됨
  • 중앙 Config Server에서 설정 관리, 저장 Backend는 Git, DBMS를 사용함
  • 서비스들은 Application Runtime 중에 중앙 Config Server를 통해 정보를 획득
  • 설정 정보가 변경된다면 중앙 Config Server의 설정 파일을 툴을 이용해 변경

각각의 마이크로 서비스들은 Application Runtime 중에 중앙 Config Server로 부터 정보를 가져와서 수행!

Service Gateway

  • 다양한 서비스들에 대한 단일 진입 점을 제공
  • 인증, 인가, 로깅, 필터링 등의 공통 처리 수행
  • 서비스에 문제 발생 시 요청을 차단하거나 대안 경로로 변경하는 기능 수행

 

SW Defined Load Balancer

  • 서비스를 호출하는 클라이언트에서 SW로 Load Balancing 수행

전통적인 Load Balancer 구조
Service에서 코드레벨로 Load Balancing을 구현이때 중앙 시스템의 도움을 받음

Circuit Breaker

  • 서비스 장애 시 장애 전파를 막기 위함

Service C에서 오류가 생겼음에도 Service A,B 모두 오류 발생

 

  • 특정 Servivce의 장애는 그 Service만의 장애로 격리시키는 것이 중요함
  • Service 간의 Circuit Breaker 컴포넌트 도입
  • Service에게 요청했을 때 해당 요청은 Circuit Breaker를 통해 요청
  • Circuit Breaker를 연결되어있는 Service를 모니터링하여 문제 발생이 예측되는 경우 차단 시킴
  • Circuit Breaker에 의해 차단된 Service는 정상화 작업 수행 (문제 분석 -> 코드 수정 -> 빌드 -> 테스트 -> 배포)

 

Circuit Breaker가 Service C 호출을 막음

 

Distributed Tracing

  • 서비스 간 모든 호출에 추적 ID를 삽입 (ID 예시 : 암호화한 문자열, 암호화한 정보)
  • 추적 ID를 Key로 하여 단일 API 트랜잭션 활동을 파악

Zipkin을 이용한 호출 ID 추적

Data Lake

  • 비정형 raw 데이터를 그대로 저장( Hadoop, HDFS이용)
  • 데이터 분석 시점에 데이터 가공
  • 전통적인 ETL이 아닌 실시간 Data Ingestion 도구 사용 (Flume, Kafka, Logstash...)

Messaging

  • Messaging 기반 이벤트 주도 설계는 서비스 간 결합도를 낮춤
  • 고가용성의 Messaging 솔루션 필
  • RabbitMQ, ActiveMQ, Kafka, AWS Kinesis

Process & Governanace capabilities 

  1. DevOps
  2. 자동화 도구
  3. 컨테이너 레지스트리
  4. 문서화
  5. 참조 아키텍처 및 라이브러리

DevOps

  • 애자일과 DevOps는 필수임 (조직에 맞는 방법론을 선택 후 실행)
  • 한팀에서 지속적 통합, 배포, 운영, 모니터링이 되어야함
  • 애자일을 도입하여 짧은 개발 주기로 반복하여 빠른 업데이트 및 배포 (자동화!!!)
  • 통합, 배포, QA 모두 자동화!!

자동화 도구

  • 다수의 서비스를 테스트, 배포, 운영 가능 하도록 하는 자동화 도구를 갖춰야함
  • 테스트, 배포, 모니터링 경보 자동화

컨테리어 레지스트리

  • MSA에서 컨테이너는 필수임
  • 코드 형상 관리와 같이 이미지도 형상 관리를 해야함
  • Docker Hub, GCR, ECR ...

문서화

  • 서비스들은 인터페이스를 기준으로 통신함
  • 인터페이스 문서화!!
  • 인터페이스 문서는 아래 정보를 내포함
    • 필수/선택 파라미터
    • 버전
    • 응답 정보
    • 에러 코드
  • 인터페이스 정보는 웹으로 쉽게 열람할 수 있어야 함
  • Spring REST Docs, Swagger ...

참조 아키텍처 및 라이브러리

  • 탈중앙화 된 방식은 비효율성을 야기 할 수 있음
    • 서로 다른 아키텍처로 인한 유지 보수성 악화
    • 동일한 기능의 재개발
  • 조직의 기술 별 참조 모델, 아키텍처는 중요
    • 참조 아키텍처는 사내 프레임워크화 할 수도 있음 -> 전사 개발 팀들은 프레임워크를 기반으로 Service를 개발
  • 중족 개발을 막기위해 사내 오픈소스 라이브러리 활동
    • 사내 인프라에서 기능 검색
    • 사내 프레임워크 개발 활동에 대한 보상

 

 

 

 

 

마이크로서비스의 장점

  1. 작은 서비스 단위로 확장 가능
    1. 필요하면 추가하여 개발
    2. 다른 서비스와는 공통 인터페이스만 맞추면 됨
  2. 일부의 장애가 시스템 전체 장애로 이어 지지 않음
    1. 각 서비스 개별적인 장애는 다른 시스템에 장애를 일으키는 영향력이 적음.
  3. 서비스 단위로 자율적 배포 가능
    1. 각 서비스를 개발한 팀들은 기능 변경이 필요한 경우 개별 적으로 개발 후 배포
    2. 각 서비스들은 서로 다른 언어, 기술 스텍들을 이용해 개발할수있음.
  4. 빠르게 변화하는 비즈니스 환경에 민첩하게 대응 가능
    1. 각 서비스들은 성능 문제가 생기면 언어/프레임워크 자체를 교체하여 새롭게 개발할 수 있음.

-> 개인 의견 : 위 4개의 항목은 마이크로서비스의 SW 품질 요구 사항 같음

 

마이크로서비스의 단점

  1. 컴퓨팅 자원의 사용이 모놀리틱 보다 비효율적
  2. 성능 - 프로세스 내부 호출 보다 느리다.
  3. 메모리 - jvm 등 중복적인 자원 사용
  4. 운용 관리가 어려움
  5. 모니터링 대상 증가
  6. 배포 대상 서비스 증가 및 기술의 다변화
  7. 다양한 장애 상황 발생
  8. 단위 테스트 컴포넌트 테스트 난이도 증가
  9. DB 트랜잭션 처리 어려움
  10. 서비스 간 Polyglot Data Store 사용
  11. 분산 환경에서 트랜잭션 어려움

-> 개인 의견 : 1개의 서비스를 개발하던 팀이 통째로 나간다면..?? 그리고 단점이 생각보다 많음.

가장 큰 문제는 데이터의 일관성, 성능 문제 같음

마이크로서비스에서 요구하는 기술들

  1. Cloud 
    서비스 여러개를 배포하여 운영하는 클라우드
  2. NoSQL
    개별 서비스는 각기 다른 SQL과 개별 저장소를 이용하여 서비스를 운
  3. Docker, Kubernetes & Ecosystem
    도커 컨테이너를 이용해 편해진 배포 시스템
  4. Netflix OSS
    넷플릭스에서 배포한 마이크로서비스 지원 라이브러리
  5. 이외 여러 적용 사례 들 (아마존, 넷플릭스 등..)

 

 

 

 

 

+ Recent posts