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월 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


저번달인 7월 13일에 소개한 IBM IT insight의 2014년 2분기판이 나왔습니다. IT트랜드를 정리하여  잡지형태로 보여주는 사이트인 IBM IT Insight에서 매 분기마다 새로운 내용을 업데이트하는데요.

이번 2014년 2분기판은 클라우드 컴퓨팅(Cloud Computing)에 대한 이야기가 나옵니다.


IT Insight 2014 지금, 비즈니스 세계에는 '클라우드'가 뜨고 있다' 얼마전까지 IT영역의 일부분으로 여겨져 왔던 클라우드, 이제는 기업의 여러 가지 기능을 가능하게 하는 비즈니스 의사 결정의 항목으로 자리잡고 있다. 이런 변화에 따라 클라우드를 도입하는 기업도 매년 늘어나고 있다. 지금부터 IT Insight와 함께 클라우드 기술을 도입하는 기업이 늘어나고 있는 5가지 이유에 대해 알아보자.


"클라우드"컴퓨팅이 유행이라 신문기사나 방송, 인터넷에서 "클라우드(Cloud)"라는 단어가 많이 나옵니다.


이번 IBM Insignt 2014년 2분기호에서는 클라우드 컴퓨팅의 설명과 종류 그리고 IBM에서 나온 기사인 만큼 IBM의 클라우드 전략과 전망, 그리고 사업에서 클라우드 적용 등등 홍보성 글도 나옵니다.


요즘 IT업계의 화두인  클라우드 컴퓨팅(Cloud Computing) 내용 이해하는데엔 좋다고 봅니다.


참고로 내용을 e-book형태 및 PDF파일로 제공하기때문에 아이패드나 태블릿등에 PDF로 저장해서 돌아다니면서 읽을 수 있습니다.

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

관련 링크
The Chromium Project
Chromium OS


관련 서적

구글크롬OS클라우드OS와의첫만남
카테고리 컴퓨터/IT > 대학교재
지은이 코이케 료지 (한빛미디어, 2010년)
상세보기


학회지에 스마트폰 관련 논문을 쓰고 난 후, 넷북, 태블릿에도 관심이 많이 생겼습니다. Google에서 넷북,태블릿으로 탑재하려고 만들고 있는 Chrome OS에 대해서 관심이 있다보니, 모 기자님에게 구글이 취재원에게 잠시빌려준 ChromeOS 탑재 넷북 CR-48을 잠시 만져보기도 하였습니다. 그러나 뭔가 부족한듯한 느낌에 직접 Chrome OS를 빌드해서 사용해보자는 생각이 번쩍떠오르더군요.

2011.05.05

The Chromium Project 에서 Chromium OS 소스를 다운로드 받은 후 컴파일을 하였습니다.

Chromium OS 컴파일 방법은 Chromium OS Developer Guide  를 참조하시면 됩니다.

(64bit 머신에서 컴파일을 해야되더군요. 컴파일하는 방식이 Gentoo Linux 설치하듯 화면이 나와서 뭔가 무섭다는 느낌이 들었습니다. 실제로 OS를 구성하려면 계속 빌드만 몇 시간씩 투자를 해야합니다.

이번에 크롬 OS를 컴파일 해서 설치하려니, 64bit 머신을 구입 후 집에서 빌드 및 서버 굴려야겠단 생각을 계속 하게 되었습니다. - 전기값은 어쩌려고? ㅠㅠ)

Chromium OS의 컴파일이 완려된것을 확인하곤, 2011.05.06 USB메모리에 Chromium OS 부트이미지를 넣고, 컴퓨터에 부팅을 해보았습니다.


첫화면은 언어, 키보드 및 네트워크 설정이더군요.

Chromium OS 시작할때의 화면.


저 화면에서 언어 및 키보드, 네트워크 설정을 하면, 다음 화면에선 구글 계정으로 접속하기 화면이 나옵니다. 구글 계정입력한 후 비밀번호까지 입력하여 로그인을 하면 Chrome 웹브라우저 같은 화면이 나옵니다.

Google사에서 Chrome OS를 탑재한 Cr-48 노트북을 사용해본 사람으로서, 지금은 cr-48경우보다 속도는 빠릿해지고, 플래시도 돌아가고, 버벅거리는 면이 많이 줄었다는 걸 느꼈습니다. 그러나 아직도 불안정적이라 가끔 웹브라우저가 뻗기도 합니다.

페이스북, 트위터를 사용해도 AJAX로 돌아가는 부분도 버벅임도 없고, 심지어 페이스북 앱인 시티빌을 원활하게 할수 있습니다. (시티빌을 할수 있다니 이건 대박)

UI는 Chrome 웹브라우저 쓰는 것과 흡사하다고 보면 됩니다. Chrome 웹브라우저만 쓰는 컴퓨터를 접했다고 보면 이해 되실겁니다.


Chromiu, OS를 사용한 소감: Chrome 웹브라우저만 돌아가는 넷북을 만져보았답니다.

구글의 전략은 유비쿼터스환경에서 클라우드 컴퓨팅으로 구글 서비스를 언제 어디서든 사용하는 것입니다. 안드로이드와 크롬OS는 인터넷을 접속할 수 있는 수단이지요.  크롬OS는 인터넷을 쓰려는 저연령층과 저소득층에 만족스럽게 쓰일듯 합니다.


자세한 생각은 정리해서 다시 블로깅 하기로 하겠습니다.

Buy me a coffeeBuy me a coffee

+ Recent posts