원래는 크리스마스에 다 마무리 하려고 했는데...
저녁에 좀 쉬자고 한게..다음 날이 되어 버렸네요 -_-
그래서 벌로 오늘 밤에 남아서 작성합니다. ㅠㅠ
나머지 것들이라고 하면 이런 것들이 있습니다.
4. Cache Server
캐시 서버에 관련된 것은 효과적인 것 1개와 미약한 것 2개가 있습니다.
첫번째는 ....Cent(RHEL)과 같은 애들을 위한 Yum Repository 와 우분투 계열을 위한 apt Repository가 있습니다. 이 정보들은 모두 인터넷에서 긁어 오니...로컬에 캐시 서버를 두고 주기적으로 싱크하자는 개념이죠
당연히 이러면 빨라집니다. :)
특히 보안적으로는 DMZ에 캐시서버를 두고 관리하면 보안 측면에서도 좋겠네요.
관련 툴은 여기서 소개하고 있습니다.
yum's reposync or apt-cacher-ng
(https://www.ansible.com/blog/ansible-performance-tuning)
아주아주 크게 보면 KT에서 쓰고 있는 Youtube cache 서버도 같은 맥락이죠
(이 솔루션 C모사 꺼 였는데 지금도 그건가? 모르겠네용 ㅎㅎㅎㅎ )
미약한 것에 대한 첫번째는
apt에 대한 cache_valid_time 입니다.
현재 앤서블에서는 apt만 지원합니다. 음....향후에는 yum도 될 것 같은데 일단은 진행 중입니다. (링크 : Add an option to specifiy cache valid time period to YUM module)
이게 어떤 내용이냐면, apt-get update를 수행시에 특정 task를 cache_valid_time값보다 (그러니까 아직 나는 때가 아니다 라고 나온다면) 수행하지 않는 것인데....테스크마다 혹은 롤마다 다르게 적용할때 쓸모가 있을 수도 있는 것 같습니다....하하하;;
미약한 두번째 것은 fact_caching 즉 FACT에 대한 캐시입니다.
하지만 1.6 이후로 한번 gather한 것은 다시 gather안 하게다는 'SMART'의 등장으로
캐시는 어디다가 써야 하는지 모르겠습니다. (아시는 분 알려주세용;;;)
5. Async 테스크
Async는 쉽게 말하면 background 작업이 가능하게 해줍니다.
아시는 것처럼 forks된 숫자만큼 앤서블은 순서대로 열심히 꿋꿋이 수행해 줍니다.
그런데, 느린 웹이나, 업데이트가 느린 repo라든가 다양한 문제로 IDLE time이 발생한다면? 이 부분은 백그라운드 처리해 주고, 다른 작업부터 수행하는 것을 의미합니다.
예를 한번 보죠
Centos에 epel-release를 삭제하는 구문에
epel-release를 삭제하는 부분에 async 옵션을 넣습니다.
1000초 동안 5초의 인터벌로 체크하는 것입니다.
[ epel-release를 순서대로 지웠을때 ]
[ epel-release를 async로 처리하고 지웠을때 ]
멍때리는 시간을 줄이니 전체 시간도 많이 줄었네요.
음...-_-; 상황에 따라서는 이게 pipelining 보다 효과적일수도...쿨럭;;;;
=======================
번외편 (개인적으로 추천하지 않는 것들)
Ansible-Pull
알려져 있기로는 repo의 업데이트 확인이나, 굳이 중앙에서 관리할 필요 없는 소소한 것들은 클라이언트 단에서 자체적으로 해결 한다는 컨셉인데...
제일 큰 문제는..? 혹은 이슈는..이걸 위해서 앤서블을 모든 클라이언트에 설치해야 한다는거죠 -_- (내가 잘못 이해하고 있나 -_-?)
물론 요구사항에 따라서 repo 업데이트 확인이나 다른 목적으로 유용하게 사용할 수 있을 것처럼 보이나...굳이 앤서블을 써가면서 이걸 해야 하나 싶네요
어짜피 이걸 다시 crontab에 태워야 하는데 말이죠 ;;;
우앙 이로서 일단 퍼포먼스 튜닝은 마무리 합니다 :)
즐거운 연말~~~ 다들 되세요~~
0 개의 댓글:
댓글 쓰기