2016년 1월 7일, Amazon에서 AWS Seoul Region(서울 리젼) 설립을 발표하였습니다.




위의 발표공지를 보고나서, AWS Seoul Region의 Latency와 AWS Tokyo Region의 Latency를 측정해보았습니다.

측정은 Apache ab와 nginx를 이용하여 다음의 링크를 사용하여 측정했습니다.



AWS Tokyo Region 

 # ab -n 10 -c 1 http://**.**.**.**/index.html

This is ApacheBench, Version 2.3 <$Revision: 1706008 $>

Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/

Licensed to The Apache Software Foundation, http://www.apache.org/


Benchmarking **.**.**.** (be patient).....done



Server Software:        nginx/1.9.9

Server Hostname:        **.**.**.**

Server Port:            80


Document Path:          /index.html

Document Length:        612 bytes


Concurrency Level:      1

Time taken for tests:   0.848 seconds

Complete requests:      10

Failed requests:        0

Total transferred:      8440 bytes

HTML transferred:       6120 bytes

Requests per second:    11.79 [#/sec] (mean)

Time per request:       84.805 [ms] (mean)

Time per request:       84.805 [ms] (mean, across all concurrent requests)

Transfer rate:          9.72 [Kbytes/sec] received


Connection Times (ms)

              min  mean[+/-sd] median   max

Connect:       40   42   1.3     42      45

Processing:    41   43   1.2     43      45

Waiting:       41   42   1.2     42      45

Total:         82   85   1.8     84      88


Percentage of the requests served within a certain time (ms)

  50%     84

  66%     85

  75%     85

  80%     87

  90%     88

  95%     88

  98%     88

  99%     88

 100%     88 (longest request)

AWS Seoul Region

 # ab -n 10 -c 1 http://**.**.**.**/index.html

This is ApacheBench, Version 2.3 <$Revision: 1706008 $>

Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/

Licensed to The Apache Software Foundation, http://www.apache.org/


Benchmarking **.**.**.** (be patient).....done



Server Software:        nginx/1.9.9

Server Hostname:        **.**.**.**

Server Port:            80


Document Path:          /index.html

Document Length:        612 bytes


Concurrency Level:      1

Time taken for tests:   0.172 seconds

Complete requests:      10

Failed requests:        0

Total transferred:      8440 bytes

HTML transferred:       6120 bytes

Requests per second:    58.14 [#/sec] (mean)

Time per request:       17.201 [ms] (mean)

Time per request:       17.201 [ms] (mean, across all concurrent requests)

Transfer rate:          47.92 [Kbytes/sec] received


Connection Times (ms)

              min  mean[+/-sd] median   max

Connect:        7    9   1.3      9      11

Processing:     6    8   2.2      8      14

Waiting:        6    8   2.2      8      14

Total:         14   17   2.4     17      22


Percentage of the requests served within a certain time (ms)

  50%     17

  66%     18

  75%     18

  80%     19

  90%     22

  95%     22

  98%     22

  99%     22

 100%     22 (longest request)



AWS Tokyo Region Avg. Latency

 87.11111111(ms)

AWS Seoul Region Avg. Latency

 20.22222222(ms)


AWS Seoul Region 의 Latency와 AWS Tokyo Region의 Latency를 비교하니 AWS Seoul Region이 훨씬 빠르다는걸 체감하였습니다.

이후 다운로드 전송량 측정을 해보아도 AWs Seoul Region이 빠르다는 것도 확인하였습니다.


AWS Tokyo Transfer Rate

 9.72 [Kbytes/sec] 

AWS Seoul Transfer Rate

 47.92 [Kbytes/sec]


측정결과 AWS Tokyo와 AWS Seoul간의 엄청난 속도차이를 경험하였고, AWS Tokyo Region의 사용료보다 AWS Seoul Region의 사용료가 조금 더 저렴하다는 걸 보고 깜짝 놀랐습니다.


Tokyo 보다 접근 속도가 빠르면서, Tokyo보다 저렴한 Seoul을 사용해야겠다는 결론을 내렸습니다.


기존에 AWS Tokyo Region에서 생성한 인스턴스(Instance)를 AWS Seoul Region으로 옮기는 작업을 진행하였습니다.


AWS Tokyo Region(도쿄/東京 리젼)의 인스턴스를 AWS Seoul Region(서울 리젼)으로 옮기는 방법

이 방법은 

위의 링크를 참조하였습니다. 위의 링크에 있는대로 따라하니 문제 없이 Tokyo Region의 Instance가 그대로 Seoul Region의 Instance로 옮겨지고, 정상작동함을 확인함.


1. AWS Tokyo Region EC2 Instances 메뉴 

옮길려는 인스턴스의 속성 메뉴에서 Create image(EBS AMI)함.

2. AMIs 메뉴 - 새로 만든 AMI 이미지로 Launch Instance 하고 기존에 생성한 Instance와 같은 사양의 Instance를 만든다.

3. Instances 메뉴 - 새로운 Instance가 Running 되면 Instance의 속성 메뉴에서 Stop 한다.

4. Volumes 메뉴 - Instance에 연결된 볼륨의 속성 메뉴에서 Create Snapshot 한다.

5. Snapshots 메뉴 - 새로 만든 스냅샵의 속성 메뉴에서 Copy Snapshot 한다. 

6. 팝업창에서 Destination region 항목에 Seoul Region을 선택한다.


7. AWS Seoul Region EC2Snapshots 메뉴 - Tokyo Region 에서 복사 된 스냅샷의 속성 메뉴에서 Create Volume from Snapshot 한다.

8. Volumes 메뉴 - 스냅샷으로 만든 볼륨의 Volume ID를 확인 한다.

9. Instances 메뉴 - Tokyo Region Instance 와 같은 사양의 Instance를 Launch Instance로 생성하고 Instance가 Running 되면 속성 메뉴에서 Stop 한다.

10. Volumes 메뉴 - Instance에 연결(sda1)된 볼륨의 속성 메뉴에서 Detach Volume 하고 Instance에서 볼륨을 때어낸다. Tokyo Region의 스냅샷으로 만든 볼륨을 속성 메뉴에서 Attach Volume 한다. 

팝업창에서 Instance 항목에 해당 Instance를 선택하고, Device 항목에  "/dev/sda1"으로 수정한 다음 Yes, Attach 해서 볼륨을 붙인다.

12. Instance 메뉴 - Stop 되어 있는 Instance를 Start 한다. Instance가 Running 되면 접속해서 확인한다.


이제 AWS Seoul Region이 생겼으니 Seoul Region을 애용해야겠습니다 ~_~

Buy me a coffeeBuy me a coffee

2015년 4월 9일, 미국 캘리포니아주 샌프란시스코에서 열린 AWS Summit 2015 - San Francisco Keynote 동영상입니다.

AWS Summit 2015 | San Francisco – Keynote with Andy Jassy

아래는 호스트웨이 블로그에서 공개한 키노트 내용 정리 글입니다.


아래는 2015년 4월 9일, 미국 샌프란시스코에서 열린 AWS Summit 2015 동영상 기록 목록들입니다.

동영상 자료들을 보고 AWS에 대하여 많은 분석을 해야겠습니다.


Buy me a coffeeBuy me a coffee



2015년 4월 21일, 서울특별시 강남구 삼성동 코엑스에서 열린 "AWS Summit Seoul 2015"가 열렸습니다. 

참석은 안했지만, 어떤 내용인가 확인하고 구글링 하다보니 흥미로운 주제로 된 발표가 많더군요.


현재, AWS에 관심이 많고, AWS기술 문서 및 AWS도입 사례 및 문제 해결 방안에 대한 내용을 습득하다보니 이번 4월 21일에 열린 AWS Summit Seoul 2015의 발표세션중 2015년 6월 6일까지 공개된 슬라이드들을 모으고 정리하였습니다.



트랙1 AWS 신규 서비스 및 솔루션 

AWS 최신 서비스 살펴보기 - Aurora, Lambda, EFS, Machine Learning, ECS


국내 사례로 본 클라우드 운영 최적화 - 모니터링, 자동화, 빌링


AWS 클라우드를 활용한 빅데이터 및 실시간 스트리밍 분석


국민내비 김기사, AWS 하이브리드 환경 구축사례


모바일 및 IoT 환경을 위한 AWS 클라우드 플랫폼의 진화


AWS와 컴볼트가 함께하는 데이터 보안 및 관리 자동화


AWS와 연계하는 레드햇 오픈 하이브리드 아키텍처


EBS성능 향상 및 EC2 비용 최적화 기법


트랙 2 AWS 소개 및 활용 사례 

AWS 소개 - 컴퓨팅(EC2), 데이터베이스(RDS, Redshift), 스토리지(S3, EBS)


CloudFront와 Route53기반 콘텐츠 배포 전략


엔터프라이즈에서의 하이브리드 환경 전략


엔터프라이즈 클라우드 도입 및 고려사항 - 메가마트 사례


AWS를 통한 클라우드 보안 이해하기


보안을 통한 AWS에서의 신뢰성 강화


데이터 중심 클라우드 전략과 하이브리드 솔루션


AWS이용사례 - SM엔터테인먼트 및 셰이커미디어 사례를 중심으로



Buy me a coffeeBuy me a coffee

예전에 있던 곳에서는 거의 건드릴수 없던 Cloud Computing(클라우드 컴퓨팅)관련 기술을 요즘 보고 있다.

SI업으로 파견근무를 하다보니 갑님 회사들이 회사 정보를 중요하게 여기는 것도 있고, 정보 통제를 위하여 클라우드 서비스 도입을 할수가 없다만...

지금은 서비스를 만들다 보니, 확장성 있게 저렴한 비용으로 서비스를 어떻게 제공할까 등의 고려를 하다, 클라우드 컴퓨팅 서비스에 대하여 기술 조사중이다.

아래는  2015년 5월 29일에 공개된 윤석찬님의 "AWS와 함께 확장성 높은 천만 사용자 웹 서비스 만들기" 슬라이드

AWS와 함께 확장성 높은 천만 사용자 웹 서비스 만들기


AWS Activate Seminar에서 윤석찬 AWS 테크에반젤리스트께서 발표한 "AWS와 함께 확장성 높은 천만 사용자 웹 서비스 만들기 (모바일 앱을 위한 백엔드)" 입니다




Buy me a coffeeBuy me a coffee
"웹 서비스 개발 철저공략" 책의 내맘대로 평가 및 정리



웹 서비스 개발 철저공략

저자
카츠마 료 지음
출판사
비제이퍼블릭 | 2014-04-09 출간
카테고리
컴퓨터/IT
책소개
린 스타트업 사고방식 가치 있는 서비스를 어떻게 빨리 출시할 것...
가격비교

일본 원서 이름: Webサービス開発徹底攻略 (WEB+DB PRESS plus)    

勝間 亮 (著), 石田 忠司 (著), 杉谷 保幸 (著), 江口 滋 (著), 上谷 隆宏 (著), 青木 俊介 (著), 久保 達彦 (著), 池邉 智洋 (著), 谷口 公一 (著), 田淵 純一 (著), 伊野 友紀 (著), 西岡 拓人 (著), 吉田 俊明 (著), 古旗 雅史 (著), 木野瀬 友人 (著), かなだ まさかつ (著), 牧本 慎平 (著), 成田 一生 (著), 舘野 祐一 (著), 濱崎 健吾 (著), 鈴木 慎之介 (著), 齊藤 宏多 (著), WEB+DB PRESS編集部 (編集)



출판사의 "웹 서비스 개발 철저 공략" 책 소개 링크 http://bjpublic.tistory.com/191


"웹 서비스 개발 철저공략" 책의 내맘대로 평가 및 정리


내맘대로 평가

이 책은 일본사람들이 주로 사용하는 웹서비스인 "쿡패드(クックパッド)", "니코니코동화(ニコニコ動画)", "pixiv", "라이브도어(ライブドア, 이후 Naver Japan 이였다 현재는 Line Cooperation), 2ch에서 개발 및 운영을 하다 생긴 문제나 해결방법 등을 흥미롭게 작성했습니다.

웹 서비스를 제공하는데 사용하는 회사의 인프라스트럭쳐(Infrastructure), 서버, 웹 기술등의 핵심 내용을 짚어나가며 개발 및 운영하다 생긴 문제 및 이슈, 조직 구축 및 운영 및 그리고 시스템 향상을 어떻게 꽤하는지, 모바일 유행에 따라 서비스가 변화에 어떻게 대응했는지 등을 보여줍니다.


이 책에서는 애자일(Agile) 개발 방법론 이야기를 서론에 두고, 일본에서 유명한 웹 서비스들이 어떤식으로 애자일을 적용하여 서비스의 문제점을 개선하여 시스템을 향상시켰는지에 대한 초점을 맞춰서 서술하고 있습니다.

여기서는 기술뿐만 아니라 조직 운영에 대해서도 소개를 하여 개발을 하는데에 협업이 중요하다는 것도 보여줍니다.

(뭐 개발이 혼자서 개발하는 것이 아니라 여러 사람들이 모여서 개발하니깐 협업 중요함)


이 책에서 특이한 사항으로는 제가 모르는 라이브러리(오픈소스 라이브러리이든 상용 라이브러리이든)가 너무 많다는 것이다. 역시 "세상은 넓고 라이브러리는 넘쳐다더라"란 생각을 했습니다.

책에 나오는 라이브러리들을 보면 Perl, Ruby on Rails, PHP쪽 라이브러리가 많이 나오던데, 일본에서는 한국과 다르게 Ruby on Rails, Perl, PHP를 주로 쓰는 경향이 있는 것 같다는 생각을 하였다.


이 책이 좋은 점은 바다 건너 이웃나라인 일본에서 어떻게 웹서비스를 운영하고 개선 향상시키는지에 대한 귀중한 정보들을 얻을 수 있다는 점?


책에 나오는 내용들을 보면 Slideshare등 슬라이드 공유 사이트에서 얼핏 보거나 컨퍼런스 영상에서 들었던 내용들이 나오긴 한데, 이 내용들을 책으로 기술하다보니 정리가 잘 된 느낌이 든다.

만약에, 대형 웹 서비스를 접하고, 운영해본다면 어떻게 운영하겠다는 가이드라인(Guideline)을 제시해주는거라 보면 된다.


책의 단점이라면, 내용이 옛 기술이다보니 완벽하게 이해하는 것보단 어떻게 해결했다 정도 가이드 정도로 봐야한다고 생각합니다, (그래도 웹 서비스의 구축 및 운영 방향제시를 해주는 귀중한 정보를 출판한 것이라 흐름을 관심있게 봐야한다고 생각합니다)


저는 단순 SI(System integration)업을 하는 사람이라 보니 웹서비스들은 어떻게 구축되는지에 대한 호기심을 자극하네요.

SI(System integration)업 특성상, 고객의 필요로 인해 발주받은 내용을 토대로 시스템을 구축을 해주지만, 이후의 운영은 SM(System Management)업 또는 현행부서에서 하다보니 운영에 대한 지식이 거의 전무한데다, 시스템 구축도 주먹구구식 납기일에 맞춰 납기를 하다보니 기술이 딱히 좋은 것도 아니고 -_-;;

SI(System integration)업을 하는 본인으로서는 웹서비스들이 어떻게 구축되고 운영하여 돌아가는지에 대한 지식을 어느정도 알려주는 좋은 책이라고 생각한다.
그리고 SI업 추세가 웹+모바일이기때문에 웹 서비스 구축에 대하여 관심있게 봐야하기때문에 이 책을 꼭 봐야한다고 생각한다고 보는 1인.


여담으로 책을 보다 느끼는 것인데, 일본의 스타트업(startup)기업에서 웹서비스를 처음부터 만들고 대형 웹서비스를 운영하기까지 어떤 과정을 경험했더라는 경험담을 책으로 정리하여 출판하니, 부럽다 정도?

자세한 기술정보를 잡지와 책으로 냈다는 것 자체가 자부심이 있다는 것 같단 생각을 해봄.

일본사람들이 문서화 하는 걸 중요하게 여기는 문화 및 장인정신의 때문에, 일본 업체들의 서비스 문제 및 개선사항에 대한 내용을 일본 잡지나 책에 내놓는 생각을 한다. 그러나 한국에선 이런 서비스 문제 및 개선사항에 대한 내용을 잡지나 책에 낼 수 있을까?

일단 책이라는 것도 수요가 있어야 출판하는것일텐데, 일본은 그래도 수요가 있으니 책을 내겠다만, 한국에선 수요가 한정되어 있다보니 책을 낼수 있을까란 생각을 해본다.


ps. 한국의 대형 포털 2개 업체 중 하나인 NHN에서 "Hello World"(http://helloworld.naver.com/)라는 블로그를 통해서 기술 내용을 소개하고 있고, 다음(Daum)에선 DNA개발자네트워크(http://dna.daum.net/)라는 사이트에서 기술 내용 소개를 하고 있습니다.

ps2. 책을 보다보니 운영체제(Operating System)과 네트워크(Network), 데이터베이스 관리 시스템(DBMS, DataBase Management System)에 대한 지식이 너무 얇음을 느꼈고, 컴퓨터공학과에서 배웠던 위의 내용을 다시 보고 기본기를 쌓을려는 목표를 세웠습니다.




책에서 인상깊은 구절을 적은 내용 정리

린스타트업에 대한 소개

린스타트업에 대한 소개는 아래의 글에 정리를 함.

2014/07/03 - [독서(讀書)] - 린 스타트업(lean startup) 정리



일본에서 유명한 요리 제조 알려주는 웹서비스인 쿡패드

쿡패드는 일본 최대의 요리법 공유 사이트인 동시에 Ruby on Rails로 구축된 일본 최대의 웹 서비스이기도 하다. (생략) 200밀리초 이내에 사용자에게 응답하는 인프라부터, 대규모 서비스임에도 불구하고 단시간에 많은 서비스를 출시할 수 있는 개발 기반, 철저한 사용자 중심 서비스 개발, 효율적인 스마트폰 개발, 울타리를 넘어선 팀 구축 등 모두 놓쳐선 안 될 것들이다.

"DevOps 자체는 Dev와 Ops관계에 대해 이야기 하고 있지만, 그 내용을 비약해 생각해보면 엔지니어에 국한된 것이 아니라 입장이나 전문성이 다른 멤버 간 협력을 위한 연습을 이야기한다고 할 수 있다."

"쿡패드는 엔지니어 수도 늘었고 기술 기반도 향상돼서 수많은 새 기능과 새 서비스를 개발할 수 있었다. 그렇다고 효율적인 서비스 개발의 모든 장벽이 제거된 것은 아니다. 개발 속도는, 단순히 개인의 기술력이나 툴 문제가 아닌, 조직 차원에서 해결해야 할 문제다."


니코니코 동화(ニコニコ動画)

사용자가 동영상 위에 쉽게 댓글을 달 수 있는 서비스 '니코니코 동영상'은 매일같이 애용되고 있는 일본의 웹서비스중 하나다. 2006년에 서비스를 출시한 후 7년 동안 폭발적으로 증가한 사용자 수, 우수한 가용성, 독특한 커뮤니티, 기술력 등 내세울 자랑거리는 많지만, 서비스 출시 당시에는 많은 장애물이 있었다.

애자일 개발 방식과 니코니코 개발

  • 프로세스나 툴보다 사람 간의 상호작용을 중시한다
  • 포괄적인 문서보다 동작하는 소프트웨어를 중시한다
  • 계획상의 협상보다 고객과의 협력을 중시한다
  • 계획을 따르기보다 변화에 대응하는 것을 중시한다


소프트웨어 장인 기질

 장인(匠人)기질 : 장인 사회에 존재하는 특유의 기질. 자신의 기술에 자신이 있고, 완고하지만 근면하고 정직한 성질 - 일본 『코우지엔 5판』(1998, 2004)

職人気質: 職人社会に特有の気質。自分の技術に自信を持ち、頑固だが実直であるというような性質。 - 日本 「広辞苑」(1998, 2004)

장인 기질을 지닌 엔지니어는 자신의 경험이나 주변에서 얻은 정보를 사용해서, 짧은 기간에 실현 가능한 문제 해결법을, DRY원칙(Don't Repeat Yourself)이나 KISS 원칙(Keep It Simple and Small)을 사용해서 빠르게 결정하고, 이를 바탕으로 개발하고, 평가(테스트)한다.

개발해보고 실패해보고 실패하면, 그것을 버리고 다른 방법(평가)으로 도전해본다. 얼핏 시간 낭비로 보일 수 있지만, 실패한 경험은 나중에 유익한 경험으로 선용할 수 있다.

이런 식의 개발 방식은 심플하고 변화에 강하기 때문에 요구 변화에 비교적 빠르게 대응할 수 있다.


pixiv

pixiv는 사용자가 그림을 등록하고 그림과 관련된 다양한 커뮤니케이션을 하는 SNS이다. pixiv서비스 출시부터 주목을 받았고, 사용자 수가 점점 증가해서 결국 서비스를 확장해야했다. 제한된 리소스를 사용해서 나날이 증가하는 트래픽을 제어하기 위해 사용했던 튜닝이나 스케일업/아웃 방법 등 현장에서 일했던 엔지니어들의 노하우를 공개.


"그로부터 5년이 지나 정신을 차려보니 일러스트레이터가 아닌 프로그래머가 돼있었다."

"그림을 하나의 장소에 모아 플랫폼을 만들고 싶다는 열정에 사로잡혀 매일 개발에 몰두한 결과 탄생한 것이 바로 pixiv이다."

시작 당시의 pixiv는 매우 작은 시스템으로 운영됐지만, 사용자 경향이나 의견을 반영해가면서 개발을 통해 사용자 요구를 지원하는 형식으로 많은 기능을 추가했다. 겨로가적으로 대규모 서비스로 발전했다. 튜닝이나 기능 확장 면에서도 많은 고민을 통해 기술 축적을 이루었으며, 낮은 비용으로 서비스 안정화를 도모했다.


라이브도어(Livedoor→Naver Japan→ 현재는 Line Cooperation) 시스템 구축 노하우

라이브도어(Livedoor)는 오픈 소스 소프트웨어를 주로 사용해서 확장 가능한 시스템을 구축하고 있는, 일본 유수의 포털 사이트다.


"새로운 기술을 빠르게 적용하는 것은 엔지니어로서 중요한 임무지만, 한편 오래됐더라도 안정되게 시스템을 운영해 가면서 사업적 요소를 늘려가는 것도 중요한 일이라 생각한다."

"현재 사이트 규모가 작더라도, 몇 주 후 또는 몇 달 후에는 대규모 사이트로 성장할 가능성이 있는 사이트가 많을 것이다."


Yahoo! Japan 메일

PC용으로 개발되서 플래시UI를 가지고 있는 2008년도 당시의 Yahoo!메일(코드명: Hikari)을 살펴보고, 지금까지 진행 중인 개발 뒷단의 숨겨진 이야기를 소개함.

"소프트웨어 고속화에 있어서 중요한 것은 '실측 시간에 기반해야 한다'는 것이다. "

"이렇게 하면 빨라지는 게 아닐까? 이 계산은 의미가 없어 하고 추측만 하지 말고, 해당 코드 처리에 걸리는 시간을 꼭 실측해 보도록 하자. 의외로 1/1000초밖에 걸리치 않는 부분을 고속화하려고 고생하는 경우도 있고, 그 옆에 아무 생각 없이 쓴 코드 한 줄이 몇 초씩 프로그램을 지연시키는 경우도 있다."

"소프트웨어 개발에 있어서 고속화 기법은 누군가에겐 지루할 수 있지만, 쾌적하게 프로그램을 사용할 수 있도록 하는 것은 개발자가 생각하는 것 이상으로 중요하다"


2ch 전송량 줄이기

'2채널'(http://2ch.net)이란 니시무라 씨가 운영하고 있는 일본 최대 규모 커뮤니티 사이트(BBS)(공식적으로 '거대 게시판 집팝')이다.

"현재 광대역 시대가 도래했다고 하지만, 대역 부족은 언제나 고민거리로 이후로도 대역이 콘텐츠를 쫓아갈 수 없는 상태가 계속되리라 생각한다. 막대한 대역 사용료로 날마다 고민하고 있는 사이트 운영자들은 도입을 꼭 검토해보기 바란다."

편집부: "곤란할 때는 전문가를 화나게 화면 되는 거군요.(웃음)"

카나타: "(기술자 중에는) 승부욕이 강한 사람이 많으니까요.(웃음)"



ps. 니코니코(ニコニコ)란 한국어의 '싱글벙글'과 비슷한 의미로, 웃는 모습을 나타내는 일본어라고 하는군요. 새롭게 안 사실.

ps2. 일본 대형 웹서비스 업체의 사례를 보고 들으니, 나도 대형 웹서비스를 구축 및 운영해보고 싶단 생각이 든다. 단순 SI업무만 하다보니 계속 정체되는 느낌이랄까? 뜻과 목표는 높은데, SI업 특성상 단순 서비스 구축에만 신경쓰기 때문에 그런지 쓰던 기술만 계속 쓰는 느낌이 든다. 책을 보고 자극 받아서 계속 발전하고 싶다.

ps3. 나름 책을 읽고 정리하였으니, 책을 읽고 느낀 점을 마구잡이로 쓴거라 책을 다시 읽고 정리해야겠음.

Buy me a coffeeBuy me a coffee

개발자(Developer)와 감사자(Auditor)가 생각하는 클라우드(Cloud), IaaS, PaaS, SaaS정의


정보시스템 감사를 하는 감사자(Auditor)가 생각하는 클라우드(Cloud), IaaS, PaaS, SaaS의 정의는 아래 미국 정보시스템 감사통제협회 ISACA(Information Systems Audit and Control Association)에서 내놓은 2014 CISA(Certified Information Systems Auditor) 리뷰 매뉴얼책을 참조하였습니다.



2014 CISA Review Manual(한글판)

저자
ISACA 지음
출판사
한국정보시스템감사통제협회 | 2014-02-01 출간
카테고리
컴퓨터/IT
책소개
『2014 CISA Review Manual(한글판)』은 국제정...
가격비교



미국 정보시스템 감사통제협회 ISACA(Information Systems Audit and Control Association)의 CISA(Certified Information Systems Auditor) 매뉴얼에서 나오는 클라우드와 IaaS, PaaS, SaaS정의

클라우드 컴퓨팅

클라우드에 대해 기본적인 정의를 내린 두 기관은 NIST(National Institute of Standards and Technology)와 클라우드 보안 연합(Cloud Security Alliance)이다. 두 단체 모두 클라우드를 설정이 가능한 컴퓨팅 자원(네트워크, 서버, 스토리지, 애플리케이션 시스템 및 서비스)의 공유 저장소에 필요할 때 즉시 이용가능한 편리한 네트워크 접근을 가능하게 하는 하나의 모델로서 정의하고 있다. 클라우드에서는 이러한 자원들이 최소의 관리노력 또는 서비스 제공자와의 최소의 상호작용으로 신속하게 보급될 수 있다. 클라우드에서 제공하는 서비스를 설명하는 또 다른 방법으로서 공공서비스에 비유를 들 수 있다. 전기, 가스, 수도 사용에 대해 기업이 비용을 지불하는 것처럼 사용량에 따라 IT서비스에 대해서 비용을 지불할 수 있는 선택권이 생긴 것으로 이해할 수 있다.



클라우드 컴퓨팅 서비스 모델

 서비스모델

정의

고려사항

 서비스로서의 인프라

(Infrastructure as a Service: IaaS)

프로세싱, 스토리지, 네트워크 그리고 기타 기본적인 컴퓨팅 자원 제공 가능성 

운영체제 및 애플리케이션 프로그램을 포함하여 어떠한 소프트웨어라도 고객이 가동운영할 수 있도록 해준다

클라우드 서비스 제공업체로부터 서비스 장애가 발생할 경우 영향을 최소화하기 위한 대책

서비스로서의 플랫폼

(Platform as a Service: PaaS)

클라우드 서비스 제공업체가 지원하는 프로그래밍언어 및 툴로 고객이 개발 또는 도입한 애플리케이션 시스템을 클라우드 인프라 상에서의 가동 가능성

  • 가용성
  • 기밀성
  • 민감한 정보를 다루는 데이터베이스가 외부에 있음으로 인해 보안사항 위반 시 프라이버시 및 법적 책임 문제
  • 데이터 소유권
  • e-discovery 관련 문제

서비스로서의 소프트웨어

(Software as a Service: SaaS)

클라우드 인프라에서 동작하는 애플리케이션 시스템의 사용 가능성. 애플리케이션 시스템은 웹브라우저와 같은 저사양 단말용(thin client) 인터페이스를 통해 다양한 종류의 단말기에서 접근 가능하다.(예: 웹기반 E-mail서비스)

  • 애플리케이션 시스템에 대한 소유권
  • 애플리케이션 시스템이 가동되는 장소

 출처: ISACA, Cloud Computing: Business Benefits With Security, Governance and Assurance Perspectives, USA, 2009, 5페이지 도표 1.

http://www.isaca.org/Knowledge-Center/Research/ResearchDeliverables/Pages/Cloud-Computing-Business-Benefits-With-Security-Governance-and-Assurance-Perspective.aspx


정보시스템 개발을 하는 개발자(Developer)가 생각하는 클라우드(Cloud), IaaS, PaaS, SaaS의 정의는 아래 "생생 IT 토크 - 프로그래머들의 클라우드 이야기"의 내용을 참조하였습니다


"생생 IT 토크 : 프로그래머들의 클라우드 이야기" - http://www.hanbit.co.kr/ebook/look.html?isbn=9788968486920


정보시스템 개발을 하는 개발자(Developer)가 생각하는 클라우드(Cloud), IaaS, PaaS, SaaS, BaaS의 정의

클라우드

네트워크를 도식화하여 표현할 때 사용하던 구름 모양의 아이콘에서 유래된 것으로, 구름과 같은 무형의 공간에서 컴퓨터로 할 수 있는 업무들이 가능하도록 설계한 것을 뜻한다. 또한 클라우드 서비스란 컴퓨팅의 기능을 네트워크를 통해 제공하는 것으로 네트워크에 접속할 수 있는 단말만 있으면 컴퓨터를 보유하고 있는 것과 같은 효과가 있다.



설명

 IaaS(Infrastructure as a Service)

클라우드 서비스의 가장 기초적인 모델, 쉽게 말해 컴퓨터와 같은 기본적인 저수준 자원(인프라스트럭처:Intrastructure)을 제공해주는 서비스를 말한다. 물리적인 컴퓨터도 상관없지만 대부분 가상 서버를 제공한다. 컴퓨터 외에도 가상의 저장소(디스크), 방화벽, 로드밸런서, IP주소, 가상LAN까지 제공하기도 한다. IaaS이용자는 인터넷으로 요청만 하면 원하는 컴퓨팅 환경을 수 분 이내에 사용 가능한 상태로 제공받을 수 있고 사용한 만큼만 지급하면 된다.

 PaaS(Platform as a Service)

서비스 제공자가 운영체제, 프로그래밍 실행 환경, 데이터베이스, 웹 서버와 같은 컴퓨팅 플랫폼을 제공해주는 클라우드 서비스 모델이다. 이 서비스를 이용하면 각 플랫폼의 라이선스 구매나 복잡한 설치 과정 등을 신경 쓸 필요가 없다. PaaS위에 구축한 서비스 이용자가 늘어나면, 이를 지탱하는 데에 필요한 밑단의 컴퓨팅 파워와 저장소 크기도 자동으로 늘어난다.

 SaaS(Software as a Service)

 클라우드로 서비스되는 일반 사용자가 이용하는 애플리케이션 소프트웨어를 말한다. 클라우드로 서비스한다는 것은 사용자가 자신의 컴퓨터 애플리케이션을 설치할 필요 없이 언제 어디서건 네트워크만 연결되어 있다면 그 소프트웨어를 이용할 수 있다는 의미로 G메일이나 드롭박스가 대표적이다.

 BaaS(Backend as a Service)

 넓게 보면 PaaS에 포함할 수도 있는 서비스로 최신 트랜드의 모바일 혹은 웹 애플리케이션에서 공통으로 쓰이는 기능을 묶어 백엔드 형태로 제공하는 서비스다. 사용자 관리, 각종 통계, 소셜 네트워크 서비스와의 연동, '푸시 노티피케이션[Push Notification]'등이 이에 포함된다. BaaS를 사용하면 앱 개발자는 UI등 프론트엔드에 집중할 수 있어서 앱 개발이 빨라지고 직접 구축하는 것에 비해 안정적인 서비스도 가능하게 된다.



위의 감사자와 개발자가 생각하는 클라우드, IaaS, PaaS, SaaS정의를 견주어 보면 약간의 시각의 차이가 있음을 알수 있습니다.

감사자(Auditor)의 경우는 회사 조직의 전략과 목표, 그리고 외부 위협 및 위험 대처에 대하여 감사를 하다보니 고려사항에 법적 책임과 소유권, 서비스 장애 등의 대책까지 고려를 해야합니다. 결국에는 기업 측면에서 바라보게 되구요

개발자(Developer)의 경우는 클라우드, IaaS, PaaS, SaaS를 구현하기 때문에 구체적인 정의 및 작동과 기능적인 측면에서 접근하는 시각이 있습니다. 구체적인 동작 기능 측면에서 바라보게 됩니다.


개발자와 감사자 모두 시스템을 보는데에, 감사자가 기능을 중시하나 기업 거버넌스와 IT거버넌스에 맞게 해석한다면, 개발자는 말그대로 개발하는 입장이기 때문에 구체적인 동작, 기능 측면에서 해석하게 됩니다.


이번에 CISA(Certified Information Systems Auditor)시험을보고 나서 개발자가 생각하는 것과 감사인이 생각하는 것이 다르다는 것을 느꼈습니다. 그 느낌을 클라우드 개념 정리할때 위의 내용처럼 확실하게 구분할 수 있게 되더군요.


개발자도 개발자의 시각에서만 바라보지 말고, 사용자 그리고 감사자의 시각으로 어떻게 보는지 알아야겠다는 생각을 CISA시험을 통해 느낍니다.

Buy me a coffeeBuy me a coffee

아래는 Google사에서 자료가 인터넷으로 저장되기때문에 컴퓨터가 문제가 생기거나, 컴퓨터를 고장나도, 다른 컴퓨터에서 인터넷으로 자료를 접근 할수 있다는 동영상입니다.


Chrome OS는 기존의 운영체제와 다르게 로컬 디스크에 자료를 저장하는 것이 아니라, 클라우드 컴퓨팅으로 인터넷으로 접근하여, 인터넷 서버(구글 웹 서비스 서버)에 자료를 저장합니다.

Chrome OS에서 서버 접속하려면 부팅 후 네트워크 연결을 우선 하여 클라우드에 등록된 계정으로 로그인을 해야합니다. 로그인 이후, 항상 자신의 데이터를 서버에서 바로 불려서 사용할 수 있으며, 로그인 할 단말기가 어느 PC이든 상관 없이 접근 할수 있다는 개념으로 구상되었습니다.

아래는 컴퓨터를 계속 부셔도 항상 데이터가 인터넷에 저장(실제로는 구글의 웹서비스 서버에 저장됨)되기 때문에 자료 손실이 없다는 것을 보여주고 있습니다.

(그러나 불시의 정전으로 인하여 웹서비스가 중단되면? 서버 해킹당하여 데이터가 손실된다면면?, DDoS와 같은 사이버 공격으로 서버 접근 못하면? 이란 이슈는 아직도 해결 못했습니다)


http://www.businessweek.com/technology/content/dec2009/tc20091211_347388.htm 

위의 링크에 있는 글 처럼 클라우드의 발전은 멈추지 않는다는 견해가 지배적이긴 하다만... 2년전 동영상과 지금의 상황을 봐도 아직도 클라우드 컴퓨팅은 멀었다는 생각을 가끔씩 합니다.


‪How to remain calm, despite what's about to happen to your Chrome notebook‬

Chrome UX designer Glen Murphy demonstrates some advantages of using a Chrome notebook. 25 computers were harmed in the making of this video. Fortunately, no data was lost.

아래는 Chrome OS가 탑재된 노트북을 부시고 있는 동영상들입니다. (참고로 노트북이 아깝습니다 ㅠㅠ)

DemoLab: Ninja

Your data is safe, even if your notebook isn't.

DemoLab: Firecracker

Your data is safe, even if your notebook isn't.


Buy me a coffeeBuy me a coffee




웹개발자를위한대규모서비스를지탱하는기술
카테고리 컴퓨터/IT > 프로그래밍/언어 > 웹프로그래밍 > 웹프로그래밍일반
지은이 이토 나오야 (제이펍, 2011년)
상세보기


일본에서 매우 유명한 웹 서비스 업체(쉽게 말해서 다음, 네이버와 같은 대형 포털)인 하테나(Hatena,はてな)의 CTO와 엔지니어가 쓴 "웹 개발자를 위한 대규모 서비스를 지탱하는 기술"이 한국에 번역되어 출간된다군요.

저는 커피닉스에서  [공동구매] 웹 개발자를 위한 대규모 서비스를 지탱하는 기술 링크를 보고 책을 구입하게 되었습니다.


이 책은 하테나(Hatena)사의 인턴들에게 인턴십과정중에서 수행되는 실제 기술 강의를 기반으로 구성되어 있습니다.

대규모 서비스 개발과 운영을 다룬 책인데 한국에서 이런 책을 찾기가 가뭄에 콩나물 보듯 어렵다 보니 관심이 갑니다.

(참고로 2009년 5월 12일자로 커피닉스 공동구매로 구입한 "서버/인프라를 지탱하는 기술"이란 책도 일본의 유명인터넷 업체인 하테나(Hatena,はてな)와 KLab의 서버 운영 노하우를 기술한 책으로 지금 소개할 책과 비슷합니다.)


서버인프라를지탱하는기술24시간365일
카테고리 컴퓨터/IT > 데이터베이스 > SQL서버 > SQL서버일반
지은이 이토 나오야 (제이펍, 2009년)
상세보기


아직 2011년 3월 2일 발매라 아직 책을 얻지 못했지만, 도서 설명 내용을 보니 네이버나 다음, 구글, 페이스북과 같은 대규모 웹서비스를 운영하는 회사의 노하우가 들어갔다는 생각을 합니다.

아래는 책의 목차입니다.


1 대규모 서비스 개발 오리엔테이션 -전체 그림 파악하기

강의 0 책의 근본 - 책에서 설명하는 것과 설명하지 않는

강의 1 대규모 서비스와 소규모 서비스

강의 2 계속 성장하는 서비스와 대규모화의

강의 3 서비스 개발의 현장


2 대규모 데이터 처리 입문 - 메모리와 디스크, 애플리케이션과 부하

강의 4 하테나 북마크의 데이터 규모 - 데이터가 많을수록 처리에 시간이 걸린다

강의 5 대규모 데이터 처리의 어려운 메모리와 디스크

강의 6 규모조정의 요소

강의 7 대규모 데이터를 다루기 위한 기초지식


3 OS 캐시와 분산 - 대규모 데이터를 효율적으로 처리하는 원리

강의 8 OS 캐시 구조

강의 9 I/O 부하를 줄이는 방법

강의 10 국소성을 살리는 분산


4 DB 스케일아웃 전략 - 분산을 고려한 MySQL 운용

강의 11 인덱스를 올바르게 운용하기 분산을 고려한 MySQL 운용의 대전제

강의 12 MySQL 분산 확장을 전제로 시스템 설계

강의 13 MySQL 스케일아웃과 파티셔닝


5 대규모 데이터 처리 실전 입문 - 애플리케이션 개발의 급소

강의 14 용도특화형 인덱싱 대규모 데이터를 능수능란하게 다루기

강의 15 이론과 실전 양쪽과의 싸움


6 [과제] 압축 프로그래밍 - 데이터 크기, I/O 고속화와의 관계 인식하기

강의 16 [과제] 정수 데이터를 컴팩트하게 가져가기

강의 17 VB Code 속도감각

강의 18 과제에 대한 상세설명과 응답 사례


7 알고리즘 실용화 - 가까운 예로 보는 이론ㆍ연구의 실전 투입

강의 19 알고리즘과 평가

강의 20 하테나 다이어리의 키워드 링크

강의 21 하테나 북마크의 기사 분류


8 [과제] 하테나 키워드링크 구현 - 응용으로 가는 깨닫기

강의 22 [과제] 하테나 키워드 링크 만들기

강의 23 응답 사례와 사고방식


9 전문 검색기술 도전 - 대규모 데이터 처리의 노하우

강의 24 전문 검색기술의 응용범위

강의 25 검색 시스템의 아키텍처

강의 26 검색엔진의 내부구조


10 [과제] 전문 검색엔진 작성 - 기초, 상세부분 작성, 속도와 정확성 추구

강의 27 [과제] 하테나 북마크 전문 검색 만들기

강의 28 응답 사례와 사고방식


11 대규모 데이터 처리를 지탱하는 서버/인프라 입문 - 서비스의 백엔드

강의 29 엔터프라이즈 vs. 서비스

강의 30 클라우드 vs. 자체구축 인프라


12 확장성 확보에 필요한 사고방식 - 규모 증대와 시스템 확장

강의 31 계층과 확장성

강의 32 부하 파악, 튜닝


13 다중성 확보, 시스템 안정화 - 100% 근접한 가동률을 실현하는 원리

강의 33 다중성 확보

강의 34 시스템 안정화

강의 35 시스템 안정화 대책


14 효율향상전략 - 하드웨어의 리소스 사용률 높이기

강의 36 가상화 기술

강의 37 하드웨어와 효율향상 저비용을 실현하는 요소기술


15 서비스와 네트워크 - 서비스의 성장

강의 38 네트워크 분기점

강의 39 한층 높은 단계로


특별편 현대 서비스 구축에 필요한 실전 기술 - 대규모 서비스에 대응하기 위해서

Special 강의 1 작업큐(Job-Queue) 시스템 TheSchwartz, Gearman

Special 강의 2 스토리지 선택 RDBMS key-value 스토어

Special 강의 3 캐시 시스템 Squid, Varnish

Special 강의 4 계산 클러스터 Hadoop



일단은 책을 받아 읽고보고 나서야 소감을 쓸수 있을것 같다.


ps1. 책의 목차를 보니 체계적으로 정리된듯 하다. 인터넷에서 수박 겉핥기로 알고 있는 내용들이 정리된다는 느낌? 

ps2. 한국의 웹서비스 회사에서 이런 노하우를 책으로 공개할 수 있을까?


Buy me a coffeeBuy me a coffee

2010년 11월 22일 월요일 밤.


연구실에선 박사분들께서 대화하는 것 들으면서 내일 맡아야할 것들을 정리하고 책을 뒤져보고 있었다.


박사분들께서 전부 "Facebook"과 "Twitter"가 주위에서 많이 사용한다면서, Facebook이 주위서 많이 쓰는가 보다는 식의 결론을 내는 대화를 하고 있었다.

내 주위만 해도 같은 대학원 다니는 사람들이 Facebook을 많이 쓰고 있으며, 고등학교 친구들, 대학 친구들이 Facebook을 많이 사용하여 싸이월드보다 많이 활용하고 있으니, 싸이월드를 주위서 쓰는 사람을 내 주위서 본 적이 없다.


각설하고, 박사분들께서 Facebook 이야기를 계속하다 영화로 화제 전환하다가, 재미있는 영화 없냐고 하였다 내가 "소셜 네트워크"라는 영화를 이야기 하였다.


소셜 네트워크
감독 데이비드 핀처 (2010 / 미국)
출연 제시 아이젠버그,앤드류 가필드,저스틴 팀버레이크
상세보기


나는 "이번에 나온 '소셜 네트워크'라는 영화가 나왔는데, 이 영화 괜찮다고 하더군요. Facebook 창립자인 마크 주커버그(Mark Zuckerberg)의 일대를 그린 영화에요"라고 했다.

그러자 모 박사님께서 평이 여러개로 갈린다고 하던데, 재미있는 사람도 있고, 재미 없고 지루하다는 사람도 있다 라고 하였다.

이후, Facebook이 적응하기 어려운데, Twitter는 더더욱 적응하기 어렵다는 이야기등등을 들었습니다.


이런 대화를 토대로 저는 아래와 같은 생각을 하였습니다.

  • SNS(social network service)는 현재의 트랜드가 되었으며 미래에도 지속될것이다.
  • Facebook의 인기는 싸이월드를 제칠 것이다.
  • Twitter도 스마트폰의 보급으로 많이 사용될 것이다.
  • 미래 사회는 Social화 될것이다.
위와 같은 4가지 생각을 주절주절 적었습니다.
위의 4가지 생각를 한마디로 정리하면 "SNS없는 미래는 앙꼬없는 찐빵이다"

대학 3학년 말쯤에 미투데이를 사용하다 생각했던 것인데, 이 생각들이 3년 뒤에 스마트폰으로 실현되었습니다.
미투데이를 처음 접할 대학 3학년때, 과제하면서 미투데이 하느라 재미있었는데, 요즘은 Twitter와 Facebook을 하는데에 재미가 있더군요. 

Facebook이 주위서 많이 쓰는걸 보다 갑자기 떠오른 내용을 블로그에 잠깐 주절거렸습니다.


ps. 점점 주위 사람들이 Facebook에 온다는걸 요즘 직감하고 있습니다. 점점 SNS사용하기가 무서워진다는 생각을 합니다.
ps2. 피쳐폰들을 쓰던 사람들이 이제 스마트폰으로 바꾸고 있는데, 스마트폰의 쓰임새가 웹서핑보다는 SNS사용으로 주로 많이 사용할듯 합니다.
ps3. SNS이 뜰것이다는 생각은 대학 3학년 말쯤에 많이 하였는데, 지금 생각한것과 대학 3학년 말때 생각한거랑 많은 차이가 있더군요. 대학 3학년 말쯤엔 PDA는 많이 보급도 되지 않았고, 스마트폰은 꿈도 꾸지 못할 시기라 데스크탑 중심으로 SNS가 발달될것이라는 생각을 하였지만, 현재는 스마트폰의 빠른 보급으로, SNS을 일반인들이 스마트폰으로 많이 쓰고 있습니다. 단지 3년이란 시간이 지났을뿐인데도 이렇게 많은 차이가 나군요. 기술의 발전은 너무 빠릅니다.
ps4. 마크 주커버그(Mark Zuckerberg)의 삶을 각색한 "소셜 네트워크"라는 영화는 관심이 있는데, 시간이 없어 주말에 볼 생각입니다. 
Buy me a coffeeBuy me a coffee

클라우드 컴퓨팅과 타 컴퓨팅과의 비교 (출처: 한국 소프트웨어 진흥원, 2008)



 구분 주요개념  클라우드 컴퓨팅과의 관계 
Grid Computing 높은 컴퓨팅 리소스를 필요로 하는 작업의 수행을 위해 인터넷 상의 분산된 다양한 시스템과 자원들을 공유하여 가상의 슈퍼 컴퓨팅과 같이 사용하는 방식(분산 컴퓨팅 아키텍처)  Grid 방식의 분산 컴퓨팅과 Utility 개념의 과금 모형을 혼합한 컴퓨팅 방식
  • Grid: 인터넷 상의 모든 컴퓨팅 리소스
  • Cloud: 서비스 제공 사업자의 사유 서버 네트워크 
Utility Computing  컴퓨팅 리소스를 구매하거나 소유하지 않고 가스, 전기등과 같이 유틸리티로 필요할 때마다 사용하는 방식(사용량 기반 과금 모형) 
 Server Based Computing 서버에 애플리케이션과 데이터를 두고 필요할 때마다 접속해서 사용하는 방식(클라이언트는 입출력만 처리. 모든 작업은 100% 서버가 처리 - Thin Client 방식)  클라우드 컴퓨팅은 가상화된 분산 컴퓨팅에, SBC는 특정 기업의 서버에 중심을 둔다는 차원에서 개념적으로 구분. 그러나 SBC가 발전으로 점차 구분이 모호해짐 
 Network Computing SBC와 비슷하나, 애플리케이션을 서버에서 로드하여 로컬에서 수행하는 형태(이용자의 CPU를 사용하여 동작)  이용자의 컴퓨팅 리소스보다는 클라우드상의 IT 리소스를 사용하므로 개념적 구분 
 SaaS (Software as a Service)  서비스 제공자의 서버에 저장된 SW를 인터넷을 통해 서비스로 이용하는 SW 딜리버리 모형 클라우드 컴퓨팅은 모든 IT자원을 서비스로 활용한다는 차원에서 보다 SaaS(Software as a Service)를 포함하는 포괄적인 개념 




Buy me a coffeeBuy me a coffee

+ Recent posts