비내리는사막

Linux CPU Load Averages 이해하기

비내리는사막 — Wed, 18 Nov 2020 16:19:28 +0900

linux 운영체제를 운영 해보신 경험이 있으신 분들은 Load Averages 라는 것이 중요하다는 것은 알고 있지만,

이 수치가 정확하게 뭘 의미하는지.. 얼마까지 괜찮은건지 모르는 경우들이 있었습니다.

이 수치에 대한 설명을 쉽게 해놓은 블로그가 있어 공유하고자 합니다.

결론만 말씀 드리자면, CPU의 Core당 처리 할 수 있는 양은 1로 표현 한 것이고, 이를 넘어서기 시작하면 대기열이 발생하는 것입니다.

대기열이 발생한다는 것은 현재 가지고 있는 처리량을 넘어섰기 때문에 지연이 발생하는 것이죠.

2 Core 기준 = Load Averages 2가 넘게 되면 지연 발생

16 Core 기준 = Load Averages 16이 넘으면 지연 발생

코어 기준으로 수치를 다르게 보고 판단을 해야 한다는 것입니다.

=========================================================================================

Linux로드 평균에 이미 익숙 할 것입니다. 부하 평균은 uptime및 top명령으로 표시되는 세 숫자입니다. 다음과 같습니다.

Load averages : 0.09, 0.05, 0.01

대부분의 사람들은 부하 평균이 무엇을 의미하는지 알 수 있습니다. 세 숫자는 점진적으로 더 긴 기간 (1, 5, 15 분 평균)에 대한 평균을 나타내며 숫자가 낮을수록 좋습니다. 숫자가 클수록 문제 또는 과부하 된 기계를 나타냅니다. 그러나 임계 값은 무엇입니까? "양호"및 "불량"부하 평균 값은 무엇입니까? 부하 평균 값에 대해 언제 염려해야하며 최대한 빨리 수정해야합니까?

첫째, 부하 평균 값이 의미하는 바에 대한 약간의 배경 지식입니다. 가장 간단한 경우로 시작하겠습니다. 하나의 단일 코어 프로세서가있는 머신입니다.

교통 비유

단일 코어 CPU는 단일 트래픽 레인과 같습니다. 당신이 다리 운영자라고 상상 해보세요 ... 때로는 다리가 너무 바빠서 차가 줄을 섭니다. 다리에서 교통이 어떻게 움직이는 지 사람들에게 알리고 싶습니다. 적절한 메트릭은 특정 시간에 얼마나 많은 자동차가 기다리고 있는지 입니다. 대기중인 차가 없으면 들어오는 운전자는 즉시 운전할 수 있다는 것을 알고 있습니다. 차량이 백업되면 운전자는 지연이 있다는 것을 알게됩니다.

그럼, Bridge Operator, 어떤 번호 체계를 사용할 건가요? 어때 :

0.00은 다리에 교통량이 전혀 없음을 의미합니다 . 실제로 0.00에서 1.00 사이는 백업이 없음을 의미하며 도착하는 차는 바로 계속됩니다.
1.00은 브리지가 정확히 용량에 있음을 의미합니다 . 모든 것이 여전히 양호하지만 교통 체증이 조금 더 심해지면 상황이 느려질 것입니다.
1.00 이상은 백업이 있음을 의미합니다. 얼마예요? 음, 2.00은 총 두 차선에 해당하는 차가 있음을 의미합니다. 한 차선은 다리에, 한 차선은 기다릴 가치가 있습니다. 3.00은 총 가치가있는 3 개의 차선이 있음을 의미합니다. 다리에 1 개 차선이 있고 대기 할 가치가있는 2 개 차선이 있습니다. 기타.

이것이 기본적으로 CPU 부하입니다. "자동차"는 CPU 시간 ( "브리지 교차")을 사용하거나 CPU를 사용하기 위해 대기하는 프로세스입니다. Unix는이를 실행 대기열 길이라고합니다 . 현재 실행중인 프로세스 수와 실행 대기중인 (대기중인) 수의 합계입니다.

다리 운영자와 마찬가지로 자동차 / 프로세스가 기다리지 않기를 바랍니다. 따라서 CPU로드는 이상적으로 1.00 미만으로 유지되어야합니다. 또한 브리지 운영자와 마찬가지로 1.00 이상의 일시적인 스파이크가 발생해도 괜찮습니다.하지만 지속적으로 1.00을 초과하면 걱정할 필요가 있습니다.

그래서 이상적인 부하는 1.00이라고 말하는 건가요?

음, 정확히는 아닙니다. 부하가 1.00 인 문제는 헤드 룸이 없다는 것입니다. 실제로 많은 시스템 관리자는 0.70에 선을 그립니다.

"필요는 그것으로 찾을 것이다" 엄지 손가락의 규칙 : 0.70 당신의 평균 부하는 상황이 더 악화되기 전에 조사> 위의 0.70, 그것의 시간을 머물 경우.
"지금 수정" 엄지 손가락의 규칙 : 1.00 . 부하 평균이 1.00 이상이면 문제를 찾아 지금 수정하세요. 그렇지 않으면 한밤중에 깨어나 재미 있지 않을 것입니다.
"Arrgh, 그것은 오전 3 WTF입니까?" 경험 법칙 : 5.0 . 부하 평균이 5.00 이상이면 심각한 문제에 처할 수 있고, 상자가 걸려 있거나 느려지고 있으며, 이는 한밤중이나 발표 할 때와 같이 가능한 최악의 시간에 (설명 할 수 없을 정도로) 발생합니다. 회의에서. 거기에 가지 마십시오.

다중 프로세서는 어떻습니까? 내 부하에 3.00이 표시되지만 문제가 없습니다.

쿼드 프로세서 시스템이 있습니까? 3.00의 부하로 여전히 건강합니다.

다중 프로세서 시스템에서로드는 사용 가능한 프로세서 코어 수에 상대적입니다. "100 % 사용률"표시는 단일 코어 시스템에서 1.00, 듀얼 코어에서 2.00, 쿼드 코어에서 4.00 등입니다.

다리 비유로 돌아 가면 "1.00"은 실제로 "1 차선의 교통량"을 의미합니다. 1 차선 다리에서는 채워 졌다는 의미입니다. 2 차선 교량에서 부하가 1.00이면 용량이 50 %라는 것을 의미합니다. 차선 하나만 가득 차서 채울 수있는 또 다른 전체 차선이 있습니다.

CPU와 동일 : 1.00의로드는 단일 코어 박스에서 100 % CPU 사용률입니다. 듀얼 코어 박스에서 2.00의로드는 100 % CPU 사용률입니다.

멀티 코어 대 멀티 프로세서

주제를 다루는 동안 멀티 코어 대 멀티 프로세서에 대해 이야기 해 보겠습니다. 성능상의 이유로 단일 듀얼 코어 프로세서가있는 시스템은 기본적으로 각각 하나의 코어가있는 두 개의 프로세서가있는 시스템과 동일합니까? 예. 대충. 여기에는 캐시 양, 프로세서 간 프로세스 핸드 오프 빈도 등과 관련하여 많은 미묘한 점이 있습니다. 이러한 세부 사항에도 불구하고 CPU로드 값 크기를 조정하기 위해서는 총 코어 수가 중요합니다. 이러한 코어가 분산되어있는 많은 물리적 프로세서.

이는 두 가지 새로운 경험 규칙으로 이어집니다.

"코어 수 = 최대로드"경험 규칙 : 멀티 코어 시스템에서로드는 사용 가능한 코어 수를 초과하지 않아야합니다.
"코어는 코어가" 코어가 CPU에 걸쳐 분산되어 얼마나 중요하지 않습니다 : 엄지 손가락의 규칙. 2 개의 쿼드 코어 == 4 개의 듀얼 코어 == 8 개의 단일 코어. 이러한 목적을 위해 모두 8 개의 코어입니다.

집으로 가져 오기

다음의 부하 평균 출력을 살펴 보겠습니다 uptime.

~ $ 가동 시간
23:05 14 일, 6:08, 사용자 7 명, 부하 평균 : 0.65 0.42 0.36

이것은 듀얼 코어 CPU에 있으므로 많은 헤드 룸이 있습니다. 로드가 1.7 정도 이상으로 유지 될 때까지 생각조차하지 않을 것입니다.

자,이 세 숫자는 어떻습니까? 0.65는 지난 1 분 동안의 평균, 0.42는 지난 5 분 동안의 평균, 0.36은 지난 15 분 동안의 평균입니다. 이것은 우리에게 질문을 던집니다.

어느 평균을 관찰해야합니까? 1 분, 5 분, 15 분?

우리가 이야기 한 수치 (1.00 = 지금 수정 등)의 경우 5 분 또는 15 분 평균을보고 있어야합니다. 솔직히, 박스가 1 분 평균 1.0 이상으로 급증해도 괜찮습니다. 15 분 평균이 1.0에서 북쪽으로 이동하여 스냅해야하는 지점에 머무르는 경우입니다. (분명히 우리가 배운 것처럼이 숫자를 시스템의 프로세서 코어 수로 조정하십시오).

따라서로드 평균을 해석하려면 코어 수가 중요합니다. 시스템에있는 코어 수를 어떻게 알 수 있습니까?

cat /proc/cpuinfo시스템의 각 프로세서에 대한 정보를 얻으려면 참고 : OSX에서는 사용할 수 없으며 Google에서 대체 할 수 있습니다. 카운트를 얻으려면 다음을 실행 grep하고 단어 수를 계산합니다.grep 'model name' /proc/cpuinfo | wc -l

더 많은 서버? 아니면 더 빠른 코드?

서버 추가는 느린 코드에 대한 반창고가 될 수 있습니다. Scout APM 은 비효율적이고 비용이 많이 드는 코드를 찾아 수정하는 데 도움이됩니다. N + 1 SQL 호출, 메모리 팽창 및 기타 코드 관련 문제를 자동으로 식별하므로 디버깅 시간을 줄이고 프로그래밍에 더 많은 시간을 할애 할 수 있습니다.

출처 : scoutapm.com/blog/understanding-load-averages

Cloud 환경에서의 KPI 수립 (핵심성과지표)

비내리는사막 — Thu, 25 Jun 2020 15:04:29 +0900

기업들이 클라우드로 전환하면서 많은 것들에 변화가 생겼습니다.

클라우드는 단순히 인프라만 변화 되는 것이 아니라, 패러다임의 변화까지 줄 수 있는 파급력을 가지고 있습니다.

예산을 편성하기 위한 방법도 변화가 필요로 하고, IT 운영에 비용도 연결이 되어야 합니다.

우리의 핵심 가치를 어디에 둘 것 인가를 고민 해야 합니다.

무엇을 성과로 보고 측정 할 것인지..

KPI를 수립 함에 있어 아래와 같은 지표들을 통해서 아래와 같은 가치를 어떻게 높일 것 인지 고민 해야 합니다.

비용 절감, 직원 생산성, 운영 안정성/복원성, 비지니스 민첩성

- 매년 출시 되는 새로운 애플리케이션

- 새 애플리케이션의 출시 시간

- 새로운 환경을 프로비저닝하는 데 걸리는 시간 (일)

- 배도 빈도 (주기/년)

- 프로덕션 환경에 배포 하는데 걸리는 시간 (일)

- 테스트를 위해 배포 하는 데 걸리는 시간 (일)

- 릴리스 당 기능 수

- 총 인시던트 / 결함 수

- 테스트에서 발견 된 총 결함의 비율 (%)

- 평균 해결 시간 (MTTR)(시간)

- 결함에 대한 대응 시간 (시간)

- 고객 유지율 (%)

- 새로운 기능 도입(%)

- 릴리스당 가치 (잠재 수익 ₩,$)

- 직원 유지율 (%)

- 직원 결근율 (%)

- 직원 순 성과 점수/만족도

- 고객 순 성과 점수/만족도

DevOps Developer Roadmap (Career)

비내리는사막 — Thu, 7 May 2020 17:58:24 +0900

DevOps Certification : https://hakin9.org/wp-content/uploads/2020/02/0-2-1.jpg

출처 : https://www.freecodecamp.org/news/2019-web-developer-roadmap/

The 2019 Web Developer Roadmap - A Visual Guide to Becoming a Front End, Back End, or DevOps Developer

There are many ways you can go about picking up the skills you need to become a developer. There are linear curriculums that teach you a bit of everything - like freeCodeCamp's full stack development curriculum. And then there are massive lists of skills -

www.freecodecamp.org

There are many ways you can go about picking up the skills you need to become a developer.

There are linear curriculums that teach you a bit of everything - like freeCodeCamp's full stack development curriculum.

And then there are massive lists of skills - and sometimes lists of resources - you can use to "choose your own adventure" through the learning process.

One of the best such list of skills is Kamran Ahmed's Developer Roadmap, which he regularly updates.

This is no ordinary list of resources. Kamran has painstakingly mapped out all the skills he feels are essential to breaking into different fields of development.

I've written about his roadmap in the past. And to celebrate us all being half way into 2019, I'm going to share his entire roadmap here - all three of them.

That's right - he has lists of tools and resources that are required for the following paths:

Front end web development
Back end web development
DevOps (also known as "site reliability" - this is sort of an evolution of the old System Administrator role)

The skills all developers need regardless of their specialization

In addition to these paths, Kamran also recommends everyone who wants to work as a developer learn the following skills:

Git - Version Control

Git is a powerful version control system that as of 2019 is used almost universally. If you don't know it - yes it's related to GitHub and GitLab, and you can learn how to use those tools, too.

Basic Terminal Usage - The Bash Command Line, SSH, and other skills

This could be the terminal on a Mac, a Windows DOS prompt, or Bash/ZSH. Note that regardless of which operating system you use, you should probably learn Linux. Even if you're not using it for your laptop/desktop environment, you'll almost certainly use it for servers.

Data Structures and Algorithms

The freeCodeCamp curriculum covers these in-depth. You'll probably want to learn these by solving lots of algorithm problems on freeCodeCamp, CodeWars, Project Euler, or another drilling website. I personally recommend doing this in either JavaScript or Python but if you're up for a challenge and have lots of time on your hands, doing it in C wouldn't hurt.

An understanding of how the web works: HTTPS and APIs

There are a lot of other concepts you can learn. I recommend working through a good entry-level computer science course to get started. Here's all of Harvard's CS50 course lectures ad-free on freeCodeCamp's YouTube channel.

Design Patterns, YAGNI, KISS, SOLID

I don't think beginners need a deep understanding of these, but it wouldn't hurt.

Design Patterns are basically time-tested ways to implement different types of software systems and coding structures. You can learn these gradually as you progress.

As for the alphabet soup, here's what these stand for:

YAGNI - Ya Ain't Gonna Need It - The philosophy that most of the code you think you'll need to write and the features you'll need to implement will actually turn out to be unnecessary
KISS - Keep it simple, silly! - The simpler you keep your projects the easier your life will be when it comes to maintenance.
SOLID - This is a mnemonic for "Single responsibility,‌‌Open–closed, Liskov substitution, Interface segregation, Dependency inversion". Yeah - not beginner's stuff, but look into this if you're curious.

Front End Web Development Roadmap

Kamran's first roadmap focuses on front end web development.

Here's his Front End Roadmap in its entirety:

My thoughts on the Front End Roadmap

This is a solid list of fundamental skills.

As a front end developer, you will definitely be working with HTML, CSS, and JavaScript - lots and lots of JavaScript.

The only things I think are unnecessary here:

CSS Preprocessors. These use to be necessary, but CSS itself has added many of the features that made these preprocessors so useful.
CSS Architecture: I don't think these are necessary unless you designing CSS systems is a big part of your day-to-day job.
A bit of a nitpick: TypeScript is a promising way to reduce bugs and code with confidence. We're adding this to Version 7.0 of the freeCodeCamp core curriculum. I think this should be even more prominent on the roadmap, but it is on there.
Web Assembly is a nice-to-have in my opinion. Developers are starting to do exciting things with it, but it will be a while before this technology really becomes ubiquitous.

Back End Web Development Roadmap

Kamran's second roadmap focuses on back end web development. If you combine this with his front end map, you get a pretty good path to becoming a full stack developer.

Here's his entire Back End Roadmap:

My thoughts on the Back End Roadmap

I agree with everything here.

Yes you should learn SQL and relational databases

I want to strongly agree with his recommendation that you learn a relational database.

Yes - databases like MongoDB and Neo4j can do a lot for you, and are better suited to certain types of applications than relational databases.

But you should still learn SQL and understand how relational databases work.

I recommend PostgreSQL (which we use for several projects at freeCodeCamp), but other relational databases are pretty similar.

Here's freeCodeCamp's free 4-hour course on SQL, which will teach you the basics.

And if you want to dive even deeper, here's our free 8-hour course on relational database design.

How to choose the right back end development programming language

I also want to add a note on choosing a language.

Even though there are many languages - and you can do essentially anything with any language - I strongly recommend learning either Node.js (JavaScript) or Python as your first language.

Here is a detailed guide to which programming language should you learn first.

DevOps Roadmap

Finally, Kamran covers how to become a DevOps, or Site Reliability Engineer. This involves working with a lot of cloud services and overseeing infrastructure.

Here's his entire DevOps roadmap:

My thoughts on the DevOps roadmap

Linux, Linux, Linux.

Also, I would recommend working as a developer first, then gradually coming to specialize in DevOps.

Here's a quick 30-minute introduction to the field of DevOps that should give you a better idea of whether DevOps is something you're interested.

That's all. What do you think? Did Kamran leave out any essential skills or technologies? Leave a comment and let's hash this out.

Also, if you have any resources that have worked really well for you learning these skills, share them below as a comment.

Happy coding!

– Quincy

[MAC] MAC Book 구매 후 해야 할 일

비내리는사막 — Wed, 8 May 2019 14:40:16 +0900

iTerm2 설치하기 + 꾸미기

- https://beomi.github.io/2017/07/07/Beautify-ZSH/

무료 설치 유틸리티

- macs fan control : 쿨러 OC

- iterm2 : 터미널

- anaconda :

- itsycal : 미니달력

유료 설치 유틸리티

- Magnet : 화면 분할 유틸리티

Finder 경로 보기 설정

defaults write com.apple.finder PathBarRootAtHome -bool yes;killall Finder

다나와 x 공임나라 타이어 교체 후기!!

비내리는사막 — Sun, 25 Nov 2018 23:11:59 +0900

최근에 티스토리로 이사 온 후에 블로그 잘 하지 않고 있지만, 개인적인 일로는 처음으로 포스팅 해봅니다.

타이어 교체하면서 이벤트로 돈 굳었던 후기입니다.!

앞 타이어 교체 할 시기가 되었지만, 이래저래 가격적인 부담으로 고민 하고 있었습니다.

타이어는 뭐가 좋지... AU5 가 좋다던데.. 타이어 순위도 살펴보고..

(하.... 비싸다...)

앞 타이어 두 짝만 가는데도 짝 당 10만원 이상.. 게다가 장착비용 짝 당 최소 만원 이상 추가

자주 가는 쇼핑몰 사이트에서 기웃기웃.. 너무 비싼데.. 이벤트 안하나? 다음에 사자..

그러다 가격 검색 하던 중 다나와에서 공임나라와 공임비 지원 이벤트를 지원 한다는 것!!

오 이건 뭐지?!

안타깝게도 현재는 이벤트 기간 지났습니다...

(하지만, 19년도에도 진행 예정이라고 합니다.)

타이어 / 엔진오일 교체 예정이고 급하지 않다면,

다음 이벤트를 기대 하셔도 좋습니다!

[타이어/엔진오일 공임 지원 이벤트]

https://event.danawa.com/danawa_181102

처음엔 AU5 알아보다가 역시.. 나는 가성비가 최고다 싶어서 선택 한 것은 "넥센 N7000+"

자 종류는 정해졌으니... 지릅니다!

참여방법은...

1. 다나와에서 타이어 / 엔진오일을 검색해서 구매 한다.

- 넥센 N7000+ 215/55R17 검색

최저가를 찾았으니.. 쿠폰을 열심히 뒤적뒤적..

최저기 구매하기로 Gmarket에서 쿠폰 + 스마일캐시로.. 2짝에 12만 3천원에 구매완료!

공임나라 상대원지점으로 배송지 설정!

> 이거 중요합니다. 무심코 집 주소로 보내시면... 타이어 실어서 공임나라로 가셔야해요.

공임나라로 직접 보내시는게 훨씬~ 편합니다.

[주소는 아래 4번에서 언급하고 있는 공임나라 가맹점 검색]

2. 이벤트 페이지 하단에 댓글로 신청 한다.

3. 다나와 구매확인 후 개발 쿠폰 발송

> 신청기간 : 2018년 11월 5일 ~ 19일

> 지급기간 : 1차 11월 14일 / 2차 11월 21일

- 반응이 괜찮아서 기간을 연장 했던 것 같다.

- 14일 문자로 쿠폰 두장이 전송 되었습니다~

4. 공임나라 장착 서비스 예약

- 공임나라 로그인 하시고..~ (전 네이버 아이디로..)

http://www.gongim.com

근처 공임나라 가맹점을 찾습니다.

내가 사는 지역의 가맹점을 검색!

- 후기나 평가, 무상서비스 종류도 지점 선택시 참고 하세요.

이번 포스팅에서는 자세히 언급하지 않겠지만, 생긴지 얼마 안된 곳이라

최신식 장비들을 많이 가져다 두셨습니다. 여기에서 브레이크오일 교체 했는데 자랑 하시던.. ^^;

예약 일정 확인 하셔서 예약 합니다!

저는 토요일 오전 11시에 예약 했습니다.

타이어교환만 할거라.. 타이어 교환 체크! 확인!

예약은 이렇게 완료 되었습니다.

자 이제.. 공임나라 방문기..

저는 K5 하이브리드 중고로 구매 한 지 어느 덧 6개월 갓 넘었습니다.

2013년식이지만, 굉장히 깨끗하게 1인 관리 된 차량.. 문 콕 조차 없던 차였는데...

이미 누구인지 모를 개념 없는 사람들로 인하여 옆구리에 상처가 많아지고 있습니다.

(최근에는... 휀다쪽을 긁고 튄 X 도 있었는데.. 하...)

공임나라 상대원점 예약을 하고 방문을 했는데, 이 곳은 두 번째 방문입니다.

사고나서 너무 신경을 안쓰는 듯 하여, 6000km 쯤 되었을 때 엔진오일 교체하러 방문한 적이 있었습니다.

엔진오일은 구매해서 교체 했고, 전체적으로 점검 해주시면 좋겠다 했더니,

다른 건 크게 문제 없는데 브레이크오일 조만간 교체 하는게 좋겠다 하셔서 쿨하게 바로 교체 했었습니다.

엔진룸 청소도 해주시고..

당시 네이버에서 조회해도 잘 나오지 않더라는.. 이유는? 오픈 한지 3주 밖에 안되셨다고..

[공임나라 상대원점 입구] 사기막골 버스 정류장 지나서 있습니다.

네이버 지도 http://naver.me/xv7NCW1m

타이밍을 놓쳐서.. 이미 교체를 끝내놓고 사진을 찍었네요.. ㅠㅠ

작업 시간 정말 빠릅니다.

아시는 분들은 다 아시는 휠 발란스도 잡고.. 타이어 와 휠을 분리 해주는 역할도 하는 장비.

잠깐 대기실에서 핸드폰 보고 있었더니, 다 끝내시고는 타이어에 바람 넣어주고 계시는 사장님

이렇게 공기압 자동 주입기로 쉽게..

어느덧 다 끝났다고 말씀 해주시기에.. 그럼 결제는요? 라고 했더니..

가만 보자.. 쿠폰 사용 하신다 그랬죠? 그거 사진만 찍어둡시다. 하시고선 찰칵 찰칵.

"음.. 폐타이어 처리 비용이 있는데.. 그냥 가세요~"

헐? 그렇게 저는 1원도 지불하지 않은 채로.. 대기실에서 귤 까먹다가 타이어 교체하고 나왔습니다.

끝내주시고는 이렇게 밖으로..

[교체한 타이어 넥센 N7000+]

두번째 방문이었지만, 앞으로 공임나라 자주 애용하게 될 것 같습니다.

지금도 차에 대해서 무지 하지만, 가족 차 (SM5) 차 문이 잠기질 않아서 수리 하러 갔다가

집 근처 센터에서 눈탱이(?) 맞을뻔 했던 기억이 있었는데 공임도 정해져 있고..

서비스까지.. Good!!

공임나라 상대원점 대박나세요~!!

[펌] 보고는 직장인의 능력을 평가하는 요소다.

비내리는사막 — Mon, 19 Nov 2018 10:32:21 +0900

출처 : http://blog.syszone.co.kr/2460

보고는 직장인의 능력을 평가하는 요소다.

여러 개의 지시를 동시에 처리하다가 보고할 시기를 놓쳐버렸거나, 결과가 좋지 않아 질책 받을 것이 무서워 보고를 못했거나, 지시한 날짜가 상당히 지났거나 상사가 요즘 다른 일로 정신없이 바쁘니 나에게 지시한 사항을 잊어버렸을 것이라는 생각이 들 때가 있다.

돈을 빌린 사람은 그것을 잊어버리기 쉬우나 빌려 준 사람은 잊어버리지 않는 것처럼 지시를 한 상사는 지시 사실을 잘 잊어버리지 않는다. 물론 잠시 잊어 버릴 수는 있어도 언젠가 반드시 그 일을 생각해 내기 마련이고, 심지어 완료기간을 추정하고 기록하는 상사도 있다.

따라서 상사에게 지시받은 사항에 대해서는 반드시 보고해야 한다. 추진상황이 좋든 좋지 않든, 또는 시간이 한참이나 흘러 상사가 다시 챙기지 않거나 지시사항을 잊어버렸을 것 같더라도 보고는 해야 한다.

보고를 잘해야 인정받는다. 보고를 잘하기 위해서는 우선 보고 내용에 대해 명확히 이해해야 한다. 그래야만 보고 내용과 관련해 상사가 물었을 때 막힘없이 답변할 수 있도록 사전 준비를 철저히 할 수 있다. 그리고 보고서를 멋지게 작성하는 것보다 내용을 명확하게, 시기를 놓치지 않고 결과를 신속하게, 결과 중심으로 말해야 한다.

보고를 잘 하는 요령으로는 다음 ‘3가지 원칙’이 있다.

첫째, ‘즉시 보고’하라.

- 보고가 빠르면 의사결정도 빠르다. 일이 끝났으면 될 수 있는 대로 빨리 보고해야 한다. 상사는 보고를 듣고서야 일이 진행되거나 종료되는 상황을 알 수 밖에 없다. 바람직하지 못한 결과가 나오면 이를 보고하는 것이 망설여 지고 차일피일 미루기 쉽다. 그러나 이런 유혹을 무릅쓰고 즉시 보고 해야 한다.

- 새로운 상황이 예상되는 경우, 예기치 않은 상황이 발생한 경우 그 즉시 보고해야 한다. 안 좋은 일일수록 빨리 전해야 한다. 그래야만 상사도 그 상황을 제대로 인지하고 새로운 방안을 제시할 수 있을 것이다.

둘째, ‘중간 보고’를 생활화 하라.

- 진행하는 모든 시간이 보고의 순간이다. 일을 진행할 때 중간보고가 효율적이라는 얘기다. 보고내용은 추진 방향과 앞으로 계획을 중심으로 보고하는 것이 업무 Loss를 줄이는 방법이다.

- 진행과정이 오래 걸리거나 예정보다 지체되면 중간보고를 해야 한다. 보고 날짜를 미리 지정하지 않은 경우에도, 상사가 생각한 보고 예상 기일이 경과하였는데 부하직원의 보고가 없으면 일 처리 능력을 의심하게 된다. 따라서 예정일이 경과하면 그때까지의 진행상황을 보고하고 별도의 지시를 받는 것이 좋다.

- 처리기간이 오래 걸리는 것은 비록 상사의 요청이 없어도 직원 스스로 중간보고를 자주해 정보를 공유하도록 한다. 상사에게 자신이 계속 노력하는 모습을 보여 줄 수 있을 뿐 아니라 상사의 궁금증을 풀어줄 수 있어 좋다.

- 한 번에 완벽하게 보고하려 하지 마라. 중요한 것은 일의 방향에 대해 컨센서스를 형성하는 것이다. 중간 보고, 중간 연락, 중간 의논은 신뢰를 쌓는다.

- 사실 전달을 넘어 자신의 의견을 피력하고, 대처 방안을 제시하라. “~해서 될 것 같습니다”라는 말 보다는 “~해본 결과 이 방안이 가장 적합합니다 또는 좋습니다”라고 표현하라.

- 스스로 자신의 일정을 정한 다음 준수하도록 노력해야 한다. 그것이 불가능할 때는 솔직히 보고 한 후, 일정을 조정해야 한다.

셋째, ‘결론’부터 먼저 말하라.

- 결론→근거→경과로 설명하라. 보고를 할 때 흔히 일이 경과된 순서에 따라서 말하는 사람이 있는데 좋지 않은 방법이다. 상사는 부하직원이 생각하는 것보다 많은 보고를 받느라 늘 바쁘다. 처음에 “무엇 무엇은 잘 됐습니다”라던가 “아무리 해도 실패했습니다”라고 결과를 먼저 말하고 이유와 경과 등을 나중에 말하는 것이 바람직하다.

- 사실정보 데이터의 신뢰도는 100%를 추구하라. 사실인지 보고자의 추론과 판단에 의한 것인지 명확하게 밝혀야 힌다.

만약에 보고의 타이밍을 놓쳤으면 이렇게 대처하라

- 늦은 이유에 대한 충분한 설명과 지연된 기간만큼의 업데이트된 내용을 추가적으로 보고하라

- 보고는 상사와의 약속이자 자신의 업무 처리 능력을 보여주는 근거다. 보고 시기를 놓쳤다고 느끼는 순간, 즉시 그 이유를 설명하고 보고 시기를 재약속하라.

- 정확하게 타이밍을 놓친 사유와 그에 따른 대안을 제시하도록 한다.

- 솔직하게 말하라. 절대 핑계를 대지 말고 사실대로 말해야 한다.

- 식사시간과 같은 딱딱하지 않은 분위기를 활용한다.

- 자신의 업무중 스스로 판단, 조치를 하고 사후보고를 해도 무방한 업무와 반드시 사전에 상사와 협의 또는 지시를 받아서 진행해야 하는 업무가 무엇인지를 파악하여야 한다. 또한 스스로 보고 스케줄을 잡아놓고, 일정에 맞춰 진행하는 것도 보고 타이밍을 놓치지 않는 방법이다

AWS vs Azure 비교 자료

비내리는사막 — Tue, 3 Apr 2018 09:02:24 +0900

AWS 공식 자료 첨부

첨부파일1 : AWS Competitor Service Comparative AWS vs Azure.pdf

첨부파일2 : AWS competitive matrix- Azure- EXTERNAL.PDF

아래는 다른 블로거께서 정리 한 내용입니다.

향후 제가 보기 위해서 출처 포함해서 글 남겨둡니다.

출처 : http://cloud.syncrofusion.com/?page_id=4&uid=226&mod=document

아마존 AWS와 마이크로소프트 Azure의 "비슷한" 기능을 표를 만들어보았다.

하이브리드라는 단어는 온프레미스 + 클라우드 였던 시대에서 이젠 클라우드 + 클라우드 의 변형 형태로 바뀌어 가는 시점인듯하며 이제는 마이크로서비스에서도 클라우드 + 클라우드 등 다른 벤더사의 제품을 원하는데로 혼합해서 써서 디펜던시를 줄이는 부분이 큰 방향으로 흘러가며 한국 시장에서도 몇몇 큰 회사들은 이미 이런 형태로 쓰고 있다. 그렇지만 많은 벤더들이 그러하듯 다 자기만의 용어로 제품을 만들고 수백개의 제품이 있어서 서로 혼돈스러울때가 있다. 그래서 원래 이런 자료는 많이 있는거지만 2018 년 최신을 한번 만들어보았으며 다른 여러개의 자료들을 혼합했다. 제품의 기능이 완벽히 같지 않기 때문에 같은 분야 및 비슷한 기능을 엮었기 때문에 잘못된 자료도 있을수 있다.

[AWS] Aurora Database Failover 유의사항

비내리는사막 — Thu, 29 Mar 2018 16:40:40 +0900

AWS Aurora Failover시 설정과 관련하여 이슈사항 및 참고사항에 대하여 공유드립니다.

프로젝트를 진행하시다 보면 AWS Aurora를 이용하여 진행하는 사이트도 있을텐데 Database Failover 테스트시

WAS단에서 Connection들이 정상적으로 Failover 되지 않는 현상이 있습니다.(Write불가, Read만 가능)

위의 문제로 이슈가 발생했고 해결한 내용에 대하여 공유드립니다.

- 테스트 장비

Aurora Master DB 1대, Read-Replica 1대

Connection 수 : Min(50), Max(50)

- 테스트 상황

1. Master -> Read-replica로 Failover

2. Read-replica(1번 작업진행 후) -> Master로 Failover

위의 2가지 시나리오대로 진행 후 WAS에서 정상적으로 Application 동작여부 체크

- 이슈 사항

- DB는 정상적으로 Failover 되었음에도 Application에서는 Read-replica 쪽 디비를 바라보고 있음.

해결방안

1. AWS Aurora는 Mysql JDBC를 사용하면 안되고, 반드시 Maria JDBC를 사용할것을 권장드립니다.

JAVA설치 후 .JAR 파일을 추가시 JAVA/lib 폴더 밑에 Mysql JDBC파일과 Maria JDBC파일이 같이 존재하면 LIB 파일간의 충돌이 일어날 가능성이 많음

JDBC_DIRVER설정을 Maria로 선언 하여도 2개가 존재하면 driver간의 충돌이 일어나는 현상이 있습니다.

2. JVM의 TTL값을 60부터 그이상으로 설정하기를 권장드립니다.(Default : 10)

WAS엔진 종류에 따라서 NETWORKADDRESS_CACHE_TTL의 작동 방식이 다릅니다.

Tomcat의 경우 설정시간에 따라 성공시 Cache를 하지만, 그 외 엔진들은 설정시간마다 Cache를 진행하는 방식인듯 합니다.

어떠한 엔진이 1회 Cache를 하고 매번 Cache를 하는지는 Test해보진 않았지만 위 2가지 방식으로 동작합니다.

Amazone의 공식 매뉴얼 : https://docs.aws.amazon.com/ko_kr/sdk-for-java/v1/developer-guide/java-dg-jvm-ttl.html

결론

Aurora가 Failover될떄 클러스터엔드포인트에 맵핑된 IP변환이 시간과 TTL에 설정된 시간이 맞지 않아서 발생하는 문제인듯 합니다.

AWS매뉴얼에도 보면 TTL값을 60초 미만으로 설정하라고 되어 있지만 40부터 설정을 바꿔가며 테스트 해봤는데 60초가 적당한 듯 합니다.

CentOS root volume Resize

비내리는사막 — Fri, 9 Feb 2018 11:47:41 +0900

EC2 의 CENTOS 의 경우 8G 정도의 Root 볼륨이 할당됩니다. 약간 작아 20G로 resize2fs 시켜 사용중이었는데 6.7 버전부터 resizefs /dev/xvda1 을 하면

The filesystem is already 2096896 blocks long. Nothing to do!

라는 메세지가 발생합니다.

이를 해결하기 위해 아래의 방법을 실행합니다.

이는 시작 섹터를 변경하여 이전 파티션을 삭제하고 동일한 파티션 번호를 새로 생성하게 하는 것입니다. 잘못될 경우 부팅에 실패할 수 있으므로, 사용 중인 시스템에서는 백업이 필수라 여겨집니다.

[root@cateye ~]$ lsblk

NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT

xvda 202:0 0 20G 0 disk

└─xvda1 202:1 0 8G 0 part /

[root@cateye ~]# resize2fs /dev/xvda1

resize2fs 1.41.12 (17-May-2010)

The filesystem is already 2096896 blocks long. Nothing to do!

[root@cateye ~]# resize2fs /dev/xvda

resize2fs 1.41.12 (17-May-2010)

resize2fs: Device or resource busy while trying to open /dev/xvda

Couldn't find valid filesystem superblock.

[root@cateye ~]# df -h

Filesystem Size Used Avail Use% Mounted on

/dev/xvda1 7.8G 943M 6.5G 13% /

tmpfs 938M 0 938M 0% /dev/shm

[root@cateye ~]# fdisk /dev/xvda

WARNING: DOS-compatible mode is deprecated. It's strongly recommended to

switch off the mode (command 'c') and change display units to

sectors (command 'u').

Command (m for help): u

Changing display/entry units to sectors

Command (m for help): p

Disk /dev/xvda: 21.5 GB, 21474836480 bytes

255 heads, 63 sectors/track, 2610 cylinders, total 41943040 sectors

Units = sectors of 1 * 512 = 512 bytes

Sector size (logical/physical): 512 bytes / 512 bytes

I/O size (minimum/optimal): 512 bytes / 512 bytes

Disk identifier: 0x00057cbb

Device Boot Start End Blocks Id System

/dev/xvda1 * 2048 16777215 8387584 83 Linux

Command (m for help): d

Selected partition 1

Command (m for help): n

Command action

e extended

p primary partition (1-4)

Partition number (1-4): 1

First sector (63-41943039, default 63): 2048

Last sector, +sectors or +size{K,M,G} (2048-41943039, default 41943039): ENTER

Using default value 41943039

Command (m for help): p

Disk /dev/xvda: 21.5 GB, 21474836480 bytes

255 heads, 63 sectors/track, 2610 cylinders, total 41943040 sectors

Units = sectors of 1 * 512 = 512 bytes

Sector size (logical/physical): 512 bytes / 512 bytes

I/O size (minimum/optimal): 512 bytes / 512 bytes

Disk identifier: 0x00057cbb

Device Boot Start End Blocks Id System

/dev/xvda1 2048 41943039 20970496 83 Linux

Command (m for help): a

Partition number (1-4): 1

Command (m for help): w

The partition table has been altered!

Calling ioctl() to re-read partition table.

WARNING: Re-reading the partition table failed with error 16: Device or resource busy.

The kernel still uses the old table. The new table will be used at

the next reboot or after you run partprobe(8) or kpartx(8)

Syncing disks.

[root@cateye ~]# reboot

Broadcast message from root@cateye

[root@cateye ~]$ lsblk

NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT

xvda 202:0 0 20G 0 disk

└─xvda1 202:1 0 20G 0 part /

[root@cateye ~]$ df -h

Filesystem Size Used Avail Use% Mounted on

/dev/xvda1 20G 947M 18G 5% /

tmpfs 938M 0 938M 0% /dev/shm

위의 내용은 제가 직접 실행한 내용이고, 아래에 설명을 따라했습니다. 가급적이면 원본 사이트에가서 참조하시기 바랍니다.

To expand on JD's self-accepted answer, here's exactly what to do:

df -h #print the name of your boot partition

lsblk #show info on all your block devices

You'll see from that output what the name of the disk is of your root partition. For example, you probably see something like this: xvde 202:64 0 32G 0 disk └─xvde1 202:65 0 8G 0 part /

Our goal is to make xvde1 use the whole available space from xvde. Here's how your resize your partition:

fdisk /dev/xvda (the disk name, not your partition) This enters into the fdisk utility.

u #Change the display to sectors
p #Print info
d #Delete the partition
n #New partition
p #Primary partition
1 #Partition number
2048 #First sector
Press Enter to accept the default
p #Print info
a #Toggle the bootable flag
1 #Select partition 1
w #Write table to disk and exit

Now, reboot your instance: reboot

After it comes back do:

resize2fs /dev/xvde1 (the name of your partition, not the block device)

And finally verify the new disk size: df -h

1 출처는 여기

http://stackoverflow.com/questions/26770655/ec2-storage-attached-at-sda-is-dev-xvde1-cannot-resize

[Storage] LVM을 통한 RAID 구성

비내리는사막 — Wed, 12 Apr 2017 09:48:55 +0900

https://www.simonmott.co.uk/2016/07/growing-my-linux-raid5-array/

http://www.tecmint.com/create-raid-6-in-linux/

# yum install mdadm		[on RedHat systems]
# apt-get install mdadm 	[on Debain systems]

Create a partition on the new drive to be inserted
Add the new drive to my array
Grow the array
Add the free space to LVM
Grow the logical volume
Resize ext4 to make use of the new space