개발자와 건강2

개발자들 중에서도 이런 분들이 있으려나 모르겠다.

야근이 기본적으로 잡혀있는 프로젝트를 하는 중에 회사에서 회식을 하겠다고 한다. 그러면 개발자들은 일이 남아있으면서 강제 참가한다. 회식자리에서 술을 엄청 먹게 되어 온 다음에 다시 회사로 돌아와서 술에 취한 채로 다시 개발 작업을 한다. 이게 몇개월 단위로 악순환이 돌면서 몸이 망가져서 은퇴한다.

대학 중에도 있는 일이긴 하지만 술먹고 코딩하는 사람들이 있다. 술먹고 코딩하면 그때는 좋을 지 몰라도 나중에 내가 뭘 짰는지 모르는 상황이 온다는 건 그냥 웃는 이야기일 뿐이고… 사실 술먹고 코딩하면 멀미하는 사람이 있을 정도로 좋지 않은 짓이다고 보면 된다.

눈앞에서 생각해 가면서 개발해야 하는 작업을 알코올로 인해 취해있는 상태로 개발하게 되면 여기저기에 몸에 이상신호가 온다. 문제는 그게 취해서 못느끼는 게 대부분의 사람들의 상황이다. 이게 쌓이고 쌓이면 그대로 몸이 망가지고는 나중에 개발을 못하는 정도가 되기도 한다.

가뜩이나 야근 하나만으로도 몸이 안좋아질대로 안좋아지면 여러모로 망가지는 게 한두곳이 아닌데 거기에 술로 인해 몸을 망치는 것이다. 술만 먹을까? 안주도 딸려온다. 지금 글쓰는 계절이라면… 치킨에 맥주겠지…(ㅇㅂㅇ);; 치킨에 맥주 먹고 월드컵, 올림픽 관전하면서 밤새고 돌아다니고 나서도 몸 안좋아졌다는 자잘한 뉴스가 보이는데 개발자가 저런 짓을 하면 그냥 뭐….

이전 글에도 적었지만, 개발자가 술마시고 코딩하는 상황이 생기지 않아야 할 환경이 있는 게 제일 좋으며, 개발자들도 이런 일들을 자재해서 하는 게 좋다. 진심으로….

클라우드의 생태계

현재 다양한 클라우드 서비스가 지원되고 있다. 가장 대표적인 서비스들은 아래와 같다.

  • Microsoft
    • Components-Hyper-V & .NET
    • SaaS-Office 365
    • PaaS-Azure
    • IaaS-Azure
  • Amazon Web Service (IaaS)
    • Elastic Compute Cloud (EC2)
    • CloudFront
    • SimpleDB
    • Simple Queue Service (SQS)
    • Simple Storage Service (S3)
    • Elastic Block Storage (EBS)
  • Google Apps
    • SaaS-Gmail
    • SaaS-Docs
    • PaaS-App Marketplace
    • PaaS-Developement
  • IBM Cloud Burst Enterprise (IaaS)
    • Terremark
    • SAVVIS
    • SunGard
    • Rackspace

이런 서비스들은 설립된 지 얼마 안된 작은 회사 또는 비영리 회사 등은 상기의 나열된 서비스들을 개별적으로 구매하기보다는 아웃소싱을 통하여 사용하는 것을 고려할지도 모른다.

이러한 서비스들은 실제로 사용한 만큼만 비용을 지불하면 된다는 장점이 있으며, 경우에 따라서는 무료로 제공받을 수 있는 장점이 있다. 즉, 비용 및 편리함 측면에서 큰 장점이 있다. 소비자들은 클라우드된 서비스를 사용하면서 그 서비스가 클라우드도니 서비스 인지를 모르면서 사용하는 경우도 있다.

대표적으로 구글의 Gmail과 Docs을 보면 된다. 특히 Gmail의 경우에는 미국의 큰 도시 기관이나 많은 대학들이 구글의 Gmail 서비스를 사용하지만, 도메인 이름은 Gmail.com이 아닌 자신드의 도메인을 이용할 수 있도록 서비스를 받기 때문에 자신들의 메일 주소가 Gmail 서비스를 사용하고 있는지 알지도 모르면서 사용하게 된다. 이런 경우는 실제로 많이 일어나고 있으며, 점점 서비스들이 이런 상황으로 진화되고 있다. 필자가 글을 올리고 있는 wordpress.com에서도 이런 종류의 서비스를 지원해 주니 찾아보는 것도 재밌을지도…ㅇㅅㅇ;;

공유된 인프라 자원의 사용

한 가지 목적으로 사용되던 각각의 인프라들을 하나로 묶어 다각화된 구조의 서비스로 이용될 수 있도록 하나로 묶었다. 그렇다면 이 자원들은 어떤 식으로 처리될까?

간단하게만 본다면 이 자원들은 전부 공유된 인프라 풀로 옮겨지게 된다. 가상화를 통하여 여러 자원들을 공유된 인프라 풀로 옮겨놓고, 실제적인 서비스는 인프라가 필요에 따라서 프로비저닝(할당, 배포, 준비)되어 사용이 된다.

프로비저닝 되었던 자원이 더 이상 필요하지 않게 되면 그 자원들은 다시 본래의 공유된 풀로 회수되어 관리되어 진다.

이 과정이 각 서비스마다, 각 사용자마다의 할당이 이루어지게 되는 것이다. 각 어플리케이션에 적합한 자원을 사용자 수에 맞춰서 적절하게 할당하고, 필요 없으면 다시 대기 풀에 집어넣고의 반복이다. 컴퓨터가 필요해서 컴퓨터를 켜서 사용하고 필요 없으면 끄는 것과 마찬가지인 것이다. 단, 클라우드 서비스로써 이용되려면 1년 365일 내내 대기상태로 있어야 한다는 것이 다를 뿐이다.

클라우드 진화와 가상화 – 각 단계별 설명

각 단계별로 어떤 식으로 하여 서비스가 진화되는지를 실제로 살펴보는 글을 적어볼 것이다.

  • 가상화하기

가상화의 첫 단계는 제한적으로 사용되는 자원들을 통합된 자원으로 탈바꿈시키는 것이다. 즉, 가상화 서버를 도입하고, SAN을 티어링하여 부분적인 통합 관리를 하는 것이다. 그러면 데이터센터의 전력 및 공간 사용 비용의 절감 효과를 얻을 수 있으며(일부 인프라에서는 얻을 수 없다.), 스토리지 관리의 생산성을 증가시킬 수 있다.

가상화를 통하여 기본적으로 얻을 수 있는 효과는 다음과 같다.

  1. 전력 및 공간 사용 비용 절감
  2. 데이터 센터 장비 비용 절감
  3. 스토리지 관리 생산성 향상
  4. 에너지 효율성 증가
  5. 탄소 배출 감소
  • 운영화하기

그 다음 단계로는 IT 환경 통합과 운영화이다. 여기서는 보안, 가용성, 성능, 통제 요구 사항에 근거한 리소스 풀을 극대화한 스토리지 회적화 및 계층화된 티어드 가상화 서버를 포함한다. 통합된 관리 및 보안은 이 단계에서 궁극적으로 얻고자 하는 결과치를 극대화해주는 주요한 요소로 인식된다.

운영화를 통하여 기본적으로 얻을 수 잇는 효과는 다음과 같다.

  1. 운영 비용 절감
  2. 데이터 센터 장비 비용 절감
  3. OS 가상화
  4. 미션 크리티컬 어플리케이션내의 가상화 컴포넌트
  5. 탄소 배출 감소
  • IT-as-a-Service

마지막으로 총체적으로 공유되고 단계화된 인프라를 다중 소유, 셀프 서비스, 서비스 필요에 근거한 개발 플랫폼 및 서비스 소프트웨어 형식의 인프라로 변화시켜야 한다.

개발자들은 J2EE, .NET 같은 통합된 개발 환경을 선택하고, 셀프서비스 형식으로 자신들의 어플리케이션을 Quality Assurance / Develope / Test 의 과정을 거쳐 개발을 진행할 수 있으며, 최종 사용자는 서비스 카탈로그에서 원하는 것을 고르는 것처럼 원하는 어플리케이션을 고르고, 심지어는 2개 이상의 어플리케이션을 함께 선정하여 사용할 수도 있게 된다. 이것의 예로 들면 세일즈포스닷컴과 구글 맵을 사용하여 고객 사이트로의 목표, 방향 설정 등을 하는 서비스를 예로 들 수 있다.

이 마지막 단계는 최종 사용자에게 투명한 비용 구조를 제공해 주는 역할을 한다. 즉, 최종 사용자는 원하는 대로 사용한 후, 상세한 비용 내역을 확인하고 비용을 지불할 수 있고, 또한 조직 내 및 회사 내의 어느 누가 서비스를 얼마만큼 사용하였는지 또한 총채적으로 파악할 수 있게 된다. 보안, 통제, 규제, 규정은 신뢰할 수 있을 만큼 각 서비스 내에 내제되어 있는 상태로 말이다.

개발자와 건강

개발자… 거의 매일 컴퓨터 앞에 앉아서 이것저것 막 하는 종족입니다…ㅇㅂㅇ;; (니트랑 히키코모리랑은 또 다른 종족이죠.. (엥?)ㅇㅅㅇ)

건강은 무지 잘 챙겨야 되는 겁니다.

제경우에는 고혈압, 비만 등이 있어서 운동을 하면서 개발하지만 제가 하는 개발의 특성상 한번 시작하면 몇날 몇일을 그냥 책상앞에서 살다가 운동합니다. (아이폰 개발은 둘째치고 유닉스 시스템 개발해보세요..) 그래서 몸이 안좋습니다만…ㅇㅅㅇ;;

개발자가 야근해야 되니 건강해야 된다면 한대 때리십시요. 제가 허락하겠습니다.

본인이 개발을 잘 하여 좋은 컨텐츠를 만들기 위해서도, 회사에서도 개발하려는 컨텐츠가 상당히 좋은 수준이 되기 위해서도 양쪽이 다 신경써 줘야 합니다. 물론 양쪽 다 건강에 대해서 생각한다는 것은 쉬운 입장은 아니죠. 개발자는 위로 눈치보일까봐서 못하고, 위에선 개발자 빨리 부려먹어서 컨텐츠를 바로바로 내놓는 걸 선호하니…

근데 건강으로 인해서 몸을 망치고, 그로 인해서 한 사람의 인생이 바뀌는 것이니 진지하게 생각해야 한다. 금방 살고 금방 죽을 사람들도 아니고… 특히 한국은 그게 좀 심하니 조절 가능할 때 잘 조절해서 생활하자.

클라우드 진화와 가상화

물리적인 인프라들을 결합하여 동일한 서비스를 지원하는 가상화 작업을 통해 운영화, IT-as-a-Service(Iaas)로 진화해 가는 과정에 있어서 어떤 과정으로 진화하는지, 그리고 가상화가 어떤 식으로 쓰이는지 알아보겠다.

가상화의 주체는 주요 IT조직, 부서이며, 가상화는 높은 운영비용 예산 하에서 운용된다. 각 비즈니스 부문은 가상화 인프라상에서 움직이게 된다. 그러나, 사용되는 어플리케이션은 특정 비즈니스 부분, 부서, 조직에서 사용하는 하드웨어와 연관성이 많다. 그 이유는 어플리케이션은 하드웨어(컴퓨터 하드웨어 뿐만 아닌 여러 복잡한 하드웨어 전체를 예기합니다.) 상에서 존재하고, 예산 편성이 어떻게 수렵되고 집행되는지는 일반적으로 그 비즈니스 부분, 부버, 조직에 따라 달라지기 때문이다. 이러한 환경은 비즈니스 부분의 필요에 따라 확장되게 되는데, 모든 일련의 IT 환경은 그 특정 부분, 부서, 조직의 필요품을 충족하면서 그에 맞는 신뢰받는 IT 환경으로 인식되어 사용될 수 있다.

이제 가상화를 통한 클라우드로의 진화를 이루기 위해서 비즈니스와 IT 조직은 점진적인 IT 통합 및 일반화된 리소스 풀(Resource Pool)을 통하여 추가적인 비용 절감을 할 수 있도록 지속적인 노력을 한다. 운영화에서는 IT 관리부서나 비즈니스 관리는 “모든 것은 가상화한다”라는 전략을 수렴해 놓은 상태이다. 운영화에서의 선택적인 접근 방식은 시스템 장비들의 효율성을 증가시킨다. IT 환경은 인건비 효율성을 향상시키기 윈하여 고도로 자동화되어야 한다. 이 단게에서 IT 환경은 이미 내부적으로 정의된 서비스 레벨 목표에 부합하기 위하여 On-Demand화 되고, 비즈니스는 IT 자원의 고가용성 및 높아진 용량을 최대한 활용할 수 있게 된다.

서비스로서의 IT 단계에서 IT는 비즈니스에게 있어서 유틸리티이다. 각 비즈니스 부문은 이제 원하는 자원 및 새로운 어플리케이션을 셀프서비스 형식으로 사용할 수 있게 되며, IT 자원이용 및 IT 비용에 대한 리포트를 구체적으로 작성하고 받아볼 수 있게 된다. 이것은 경쟁력 있는 IT를 사용하게 됨으로써 진정한 비즈니스 민첩성을 얻는 효과를 누리게 된다. IT 서비스는 마치 메뉴를 고르듯 서비스 카탈로그에서 찾아볼 수 있게 되고, 사용자는 원하는 만큼의 서비스를 필요에 따라 늘리거나 줄이면서 사용할 수 있게 된다.

모르면 몸이 피곤해질 때가 있다..ㅇㅅㅇ

진심으로 모르면 몸이 피곤해질 때가 있다. ㅇㅅㅇ;;

바로 내가 퀵타임으로 녹화를 못할 때의 일이었다…;ㅅ;

아이폰 강의 듣는 분들에게는 이거 참 뭐랄까.. 미안한 내용인데..;;

하둡이나 다른 거 강의할때는 칠판도 쓰고 하니 아예 방송용 장비로 찍으니 상관은 없지만..ㅇㅅㅇ;;;

가끔 개발 하기 힘들때…

개발자라고 해서 1년 365일 줄창 개발할 수는 없다.가끔은 개발하기 힘들 때가 있다. 작게는 그냥 컴퓨터 노후화로 인한 땡땡이부터 시작해서 크게는 마음의 상심까지…ㅇㅅㅇ;;

근데 대부분은 바로 놀고 싶은 마음이 생길 때이다. 이건 어쩔 수 없다.

개발자고 사람이고 한 사람의 노동자이다. 그렇기에 어느 정도의 놀고 싶은 마음이 생기고 하는 것도 사실이다. 영업사원들 잘 놀다오는데 개발자는 영업사원이 이것저것 해달라고 요청 쌓였으니 이거나 처리하고 있어라라고 생각하는건가? 그건 아니니깐…

평소에도 심경 변화가 여러모로 일어날 수 있는 게 사람인데… 가끔은 놀기도 해주는 것도 좀 인간답게 개발할 수 있을 거라고 본다. 단, 개발 기한만 제대로 지켜준다면 서로가 아무 불만 없이 할 수 있게 된다.

가상화의 역사

가상화는 1960년 중, 후반에 IBM이 가상화의 개념을 탄생시켰다. 당시 가상화는 하드웨어와 소프트웨어가 필요했으며, 가상 메모리가 가상화를 실현시키는 개념이었다. IBM은 현재까지도 가상화 메인프레임을 제작중이다.

이후에 x86 하드웨어 가상화는 1990년대 후반에 스탠포드대학의 리서치팀이 VMware를 개발하면서 소개되었으며, 당시 명명된 코드네임은 Disco였다. 이것에 대한 자료는 http://www.cs.pdx.edu/~walpole/class/cs533/winter2008/slides/9a.ppt를 참조. ㅇㅅㅇ

2000년대 초에 접어들면서부터, 상가상화가 개발되었다. 상가상화는 게스트 OS가 Hypervisor와 직접 연동될 수 있도록 시스템이 수정되었다. 지금 이것의 가장 대표적인 예가 바로 Xen이다.

가상화의 진화 과정 요약

  1. 1960년대: IBM 시스템 360-67 메인프레임 W/CP-40 OS
    1. 궁극적으로 VM/370으로 발전함.
    2. VM/370에 풀 버추얼 메모리 용량 추가.
    3. Hypervisor라는 용어가 Supervisor로부터 파생됨.
  2. 1990년대 후반: 전체 가상화(Full Virtualization) – Disco
    1. 수정되지 않은 OS/애플리케이션 코드.
    2. Hypervisor 조정으로 인한 Performance 감소
    3. x86 아키텍쳐 문제 발생
  3. 2000년대 초: 상가상화(Paravirtualization) – Xen
    1. OS가 Hypervisor와 직접 연동.
    2. OS 코드는 Hypervisor와의 직접 연동을 위해 수정되어 만들어짐.