'기타'에 해당되는 글 5건

오늘의 5분 개발지식 라디오! 안녕하세요~ 오늘은 최근에 카카오 사태로 크게 이슈가 되었던 개념인 DR, Disaster Recovery에 대해서 알아보려고 합니다. 구체적인 방법이나 대책보다는 뉴스기사나 매체에서 나오는 단어들 위주로 간단하게 전달해드리겠습니다

먼저 IDC입니다. IDC는 internet data center의 줄임말인데요, 우리가 흔히 말하는 데이터센터입니다. 이름때문에 오해하기 쉬운데 단순하게 데이터만을 저장하는 시설이 아니라 서버를 구동하기 위한 여러 통신장비들부터 안정적인 전기 공급을 위한 전자장비들이 들어가있습니다. 

우리가 흔히 사용하는 AWS, GCP가 이러한 수많은 IDC들이 합쳐져 추상화되어 일반 개발자들이 클라우드 서비스를 사용한다고 생각하시면 됩니다. 

IDC는 엄청나게 많은 서버들을 구동하기 위해 전문적으로 지어지는 건물이기때문에 쿨링을 위한 공조시설도 설계시부터 꼼꼼하게 반영됩니다. 또 정전 등의 이유로 전기 공급이 끊어져도 다른 발전소에서 전기를 끌어오거나 어느정도는 자체적으로 발전하도록 되어있습니다. 특정 구역에 문제가 생기더라도 다른 구역에는 영향을 미치지 않도록 분리되는 등 안정적인 서비스를 위해 다양한 처리들을 해둡니다.

이렇게 IDC에는 다양한 안전장치들을 해놓지만 이번 카카오사태처럼 화재가 난다거나 하는 등의 이유로 문제가 생겼을 때 이를 사용하는 서비스기업들에서 피해를 최소화하기 위해 빠르게 복구하는 계획들을 수립해놓는데요, 이를 DR, Disaster Recovery라고합니다. 직역하자면 재해 복구 정도 될 것 같네요.

DR과 관련된 개념들이 있는데요 2가지정도 알아보겠습니다.

첫번째 RPO입니다. Recovery Point Objective의 줄임말인데요, 문제가 생겼을 때 어느 시점의 데이터까지 복구를 할 것인가를 정하는 기준입니다. RPO로 정해진 기준까지는 복구를 해야되기때문에 이 시점까지는 백업을 해둡니다.

다음은 RTO입니다. Recovery time Objective의 줄임말인데요, 기업에서 아무리 늦어도 이 시간까지는 복구가 되어야만 하는 시간입니다. 이 시간이 넘어가면 사업에 너무 크거나 복구 불가능한 피해를 입힌다는 의미입니다.

자 그럼 마지막으로 재해에 대비한 실행책들을 알아보겠습니다. 총 4가지 단계로 알려드리겠습니다.

첫번째는 Mirror Site입니다. 이름에서 알 수 있듯이 실제 서비스와 완전히 동일한 서비스를 하나 더 운용하는 것입니다. 최근의 예시로 들자면 판교 IDC이외에 다른 지역에 있는 IDC에 하나 더 서버를 운영하는 것입니다. 트래픽도 거의 동일하게 분산시켜 운용합니다. 두 지역 모두 완벽하게 동기화되어있으며 실제로 사용자들의 트래픽이 유입되고 있는 상태이기때문에 Active-Active 상태라고도 합니다. 두 지역에 동일한 수준의 인프라를 구축하여야되기때문에 가장 비용이 크지만 가장 안전하고 문제가 발생해도 문제가 발생하지 않은 지역으로 트래픽을 돌리면 되기때문에 바로 복구가 가능합니다. 

두번째는 Hot Site입니다. 미러사이트와 동일하게 바로 사용이 가능한 수준의 인프라를 다른 데이터센터에 구축하지만 실제로 트래픽을 보내지는 않는 것입니다. 한쪽은 실제로 사용자가 사용하고 한쪽은 만약을 대비하여 대기중인 상태이기때문에 Active-Standby 상태라고도 합니다. 

재해 발생시 standby상태인 데이터센터를 Active로 돌리기만 하면 되기때문에 미러사이트 보다는 느려도 빠르게 복구가 가능하고 한쪽을 Active가 아닌 Standby로 두기때문에 비교적 비용도 조금 더 저렴합니다.

세번째는 Warm Site입니다. 바로 운영이 가능한 상태는 아니지만 서비스에 중요한 데이터들을 가지고 있는 상태라고 생각하시면됩니다. 데이터는 최신상태가 아니며 데이터 손실이 발생할 수 있으나 비용이 더 저렴합니다.

마지막은 Cold Site입니다. Warm Site보다도 더 적은 데이터만을 가지고 있거나 빈 서버가 있는 정도입니다. 거의 모든 세팅을 처음해야되는 상태로 복구까지 오랜시간이 걸리는 방법입니다.

자 이렇게 오늘은 카카오로 크게 이슈가되었던 재해 대비책인 DR에 대해서 알아보았습니다. 당연히 모든 기업들이 미러 사이트 방식으로 수십개를 유지하면 좋겠지만 자원은 유한하기때문에 그렇게 운영하기가 현실적으로 어렵습니다. 만약 이번 사건처럼 화재가 나지 않는다면 운영하지 않고 있는 쪽이 훨씬 더 저렴했겠지만 이렇게 문제가 생겼을때는 발생하는 피해대비 추가 데이터센터를 운용하고 있는 쪽이 더 저렴하다고도 볼 수 있는 것이죠. 제가 생각하기에는 비용과 예방효과의 시소게임인 것 같습니다.

끝!

네트워크:

mangkyu.tistory.com/91

프론트엔드:

- sunnykim91.tistory.com/121

- velog.io/@honeysuckle/%EC%8B%A0%EC%9E%85-%ED%94%84%EB%A1%A0%ED%8A%B8%EC%97%94%EB%93%9C-%EB%A9%B4%EC%A0%91-%EC%A7%88%EB%AC%B8-%EB%AA%A8%EC%9D%8C

- 

백엔드:

데이터베이스:

------국내------

네이버:

https://d2.naver.com/

우아한형제들:

http://woowabros.github.io/

카카오: 

https://tech.kakao.com/

VCNC(쏘카/비트윈):

http://engineering.vcnc.co.kr/

티몬:

https://tmondev.blog.me/

라인:

https://engineering.linecorp.com/ko/blog/

클래스101:

https://class101.dev/ko/

토스트:

https://meetup.toast.com/

레진코믹스:

https://tech.lezhin.com/

스포카:

https://spoqa.github.io/

------해외------

페이스북:

https://engineering.fb.com/

링크드인:

https://engineering.linkedin.com/blog

인스타그램:

https://instagram-engineering.com/

드롭박스:

https://blogs.dropbox.com/tech/

마이크로소프트:

https://techcommunity.microsoft.com/t5/custom/page/page-id/Blogs

트위터:

https://blog.twitter.com/engineering/en_us.html

넷플릭스:

https://medium.com/netflix-techblog

아마존:

https://developer.amazon.com/blogs

구글:

https://developers.googleblog.com/

이베이:

https://tech.ebayinc.com/

페이팔:

https://medium.com/paypal-engineering

에어비엔비:

https://medium.com/airbnb-engineering

본문은 Quora의 글을 번역한 글입니다.

의역이 포함되어 있을 수 있습니다.

원문:https://www.quora.com/What-is-the-hardest-skill-to-teach-in-software-engineering

원작자: Stephen M Greenfield

저의 답변은 Software Architect, UI 디자이너, 그리고 프로그래머로 33년간 일하면서 다양한 스킬 레벨을 가지고 있는 엔지니어들을 뽑으며 얻은 경험을 토대로 작성되었습니다. 제가 뽑았던 커리어를 시작한지 얼마 안된 뛰어난 엔지니어들은 Google, Facebook, Sun Microsystems, Yahoo, 등의 회사들로 옮겨갔습니다.


Software engineering에서 가르치기 가장 힘든 기술은?
이 질문을 한 엔지니어가 알고리즘에 매우 뛰어나다면, 그들이 배우기 가장 힘든 기술은 세련된 UI 디자인과 개발일 것이다.

반대로, 최고의 UI 개발자들은 세련되고, 튼튼하며, 성능이 좋은 UI가 아닌 알고리즘을 개발하는데 어려움을 겪는다.

자, 당신이 두 분야에 모두 뛰어난 사람을 안다고 긴 설교를 늘어놓기 전에 잠시만 기다려보라. 나 또한 두 분야에 모두 뛰어난 사람들을 여럿 알고 있다.

질문은 "가르치기 가장힘든 기술"에 집중했다. 내가 관찰한 결과, 뛰어난 엔지니어들은 천부적인 재능과 관심이가는 분야가 있다. 흥미롭게도, 몇몇의 가장 뛰어난 알고리즘 개발자들은 그들의 UI 개발 기술은 부족하다고 인정한다 - 아니면 아예 UI 개발에 관심이 없다고 하던가.

내가 수재 알고리즘 개발자로 하여금 UI 개발에 알고리즘 개발에 비슷한 열정을 붓도록 유도하려고 하자 나는 거의 항상 저항에 부딪혔다.

이렇게 보자: 두 분야는 모두 "미술"이라는 영역에서 겹친다. 두 분야는 특유의 관찰력과 창의력을 요구하는데 이 둘은 서로 매우 다르다.

거장 화가는 조각을 해도 거장이 될 수 있을까?
공평하게도, 누군가를 한분야라도 뛰어나게 만드는 것은 매우 힘들다.

평론가들은 뛰어난 분석 능력을 가지고 있지만, 대부분의 평론가들은 뛰어난 작품을 쓰지는 못한다.

비슷하게, 몇몇의 최고의 작가들은 다른 작가들의 분석에는 능하지 못하다.

당신은 이와 같은 문제를 당신이 알고, 같이 일했던 엔지니어들에게서 관찰한 적이 있는가?

본문은 Quora의 글을 번역한 글입니다.

의역이 포함되어 있을 수 있습니다.

원문:https://www.quora.com/Is-software-engineering-these-days-mostly-about-writing-glue-code-to-stitch-frameworks-together

원작자: Minh Thanh To

당연히 아닙니다.

당신은 프레임워크들이 어려운 부분들을 추상화시킴으로 우리의 삶을 편하게 만들었다고 생각할 수도 있습니다. 하지만, 이로 인해, 이상하게 작동하는 부분이나, 특이 케이스들을 해결하기 위해선 평소엔 신경쓰지 않을 작은 디테일부터 시작해서 기반이 되는 아키텍쳐가 어떻게 돌아가는지에 대한 더욱 섬세한 지식이 필요합니다.가끔씩은 불확실한 추측을 확인하기 위해 긴 시간이 필요하기도 합니다.

하지만 그게 제가 소프트웨어 엔지니어링을 좋아하는 이유입니다. 명료하게 아는 것을 코딩하는 것은 창의력을 필요로 하는 일은 아니지만, 프로그램이 어떻게 작동하는지 저 밑 분자 단위까지 알아가는 것은 정말 즐거운 일입니다.