쑤나이퍼's diary

 우연히 제 손에까지 오게 된 베뉴 프로 8 단말기가 한 대 생겼습니다만..

Windows 8.0 을 기반으로 나온 베뉴의 경우 활용 범위가 사실 무얼 해도 애매한 포지션을 갖고 있었습니다.

어쩌면 윈도우 기반의 OS를 태블릿으로 옮겼기 때문이라고도 할 수 있는데요..

윈도우 10이 출시된 이후 상황이 많이 바뀌지 않았나 싶습니다.

Window 8 에서부터 추가된 타일 형식의 메뉴는 그리 나쁘지 않았으나 막상 태블릿 환경에서 기존 프로그램들을 두꺼운 손가락으로 메뉴 하나씩 클릭 해 가며 사용하는게 여간 불편한게 아니었죠.

하지만 윈도우 10에서부터는 기존의 윈도우가 갖는 장점과 태블릿을 이제야 제대로 이해한다라는 듯한 뉘앙스를 풍길정도로 많은 부분 개선이 이루어 진것 같습니다.

그 중 오늘을 UI 관점에서만 인상 깊은 부분 몇 가지 소개합니다.

1. 시작 화면 

 - 윈도우 10으로 업그레이드 한 후 초반 화면이 이런식을 나옵니다.

  물론 윈도우 8에서도 타일 형식의 메뉴 구조를 갖었었지만 10으로 업그레이드 하면서 기본으로 설치되는 윈도우 앱들의 종류가 더 풍성해 진 느낌입니다.

아래는 제가 입맛대로 설정해 놓은 화면입니다.

2. 윈도우 앱 마켓

 - 윈도우 8에서는 마켓에서 다운로드 받을 수 있는 앱도 별로 없었고 힘들게 하나 찾아도 다운로드 하려면 오류가 나는 경우나 너무나 많았습니다.

 한 때는 MS가  마켓을 포기했나 싶을 정도로 불편하고 써 먹을 데 없는 애물단지 였었으나..

윈도우 10에서는 언제 그랬냐는 듯 다운로드도 쉽고 이 전보다는 훨씬 다양한 앱들을 확인 할 수 있었습니다.

앱이 다양하지 못한것은 어찌보면 마켓 시장에 뒤 늦게 뛰어 들어 시장을 만들었으니... 단말 보급이 확대된다면 자연스럽게 늘어날 수 도 있을것 같아 보입니다.

 (PDA 시절까지 생각해 본다면 늦지는 않았던 것 같네요.)

3. 날씨 앱 & 지도 앱

- 윈도우8에서 컴퓨터에서 윈도우 앱을 실행하면 화면 전체를 차지한다던가.. 

 또는 먼가 불편한 인터페이스가 있어 사실 윈도우 전용 앱을 PC에서는 전혀 사용하지 않았었습니다만..

윈도 10에서는 PC모드와 태블릿 모드의 차이를 확실히 인지 한 듯 싶습니다.

아래 날씨 앺의 경우는 정보도 다양하지만 일단 전체화면으로 실행되며 가로-세로 화면 전환에 따른 적절한 인터페이스 변화를 가져옵니다.

 물론 기존 다른 모바일 환경에서는 기본적으로 되었던 부분입니다만..

윈도우 모바일 환경에서 이 정도면 .. 상당히 진일보 한 부분이라고 생각됩니다.

전반적으로 윈도우를 사용한다기 보다... 정말 태블릿을 사용한다는 느낌이 듭니다.

4. 설치된 앱 전체 목록 보기

  - PC에서 전체 설치된 프로그램을 보는 화면은 동일합니다만..

느낌만으로는 이것 역시 먼가 새롭게만 보입니다.

기존의 PC용 프로그램도 쉽게 구동가능합니다. 

또한 기존의 프로그램도 윈도우 창의 사이즈 조절을 불가능하게 만들어서 전용 앱 같은 느낌을 주게 됩니다.

다만 메뉴가 많은 또는 터치해야 하는 부분이 많은 앱의 경우 키보드와 마우스 없이는 사용하기 불편합니다.

이 부분은 윈도우 모바일 전용앱이 아닌 부분이기에 감수해야 할 부분이지 않을까 싶으면서도 다른 한편으로는 어느 정도는 기존의 프로그램들 조차도 모바일 앱 같은 UX를 선택했다는 부분에 대해서는 높은 점수를 주고 싶습니다.

갑자기 MS발 모바일 바람이 불기란 쉽지 않을테니까요.

6. 셧다운 

 - 마지막으로 셧다운화면입니다.

저의 경우 대기 상태의 배터리 소모를 줄이고자 아예 전원을 내려 놓고 이동하게 되는데요..

그저 전원 버튼을 꾹 누루면 아래와 같은 화면이 나옵니다.

윈도우 10의 경우 부팅 속도 역시 빠른 편이니...  

이 기능마저 저에게는 좋게 보이네요.

결론

 - 윈도우 8 기반의 베뉴는 업무를 볼 수 있는 태블릿이다.. 정도였다면..

윈도우 10 기반의 베뉴는 태블릿 + PC 의 조합을 잘 맞춘 태블릿 이다 라고 표현할 수 있을 것 같습니다.

기본 OS 환경에 몇 개의 클라우드까지 연동한다면 휴대성을 겸비한 업무을 볼 수 있는 재미진 태블릿이다 라고 생각하고 있습니다.

Redis 는 in-memory,  key-value 데이터 저장소이다. Redis는 가장 유명한 key-value 데이터 저장소이다. 또한 Redis는 세상의 모든 대형 IT 회사들이 사용한다. Amazon Elastic Cache 는 Redis  의 매우 강력하고 Key-value 데이터 저장소 기술로 활용된다. 이 포스트에서 redis.의 아키텍쳐에 대해 소개한다.

In- Memory, Key-value 저장소란 ?

키-밸류 저장소는 Key와  Value의 쌍으로 저장된 저장소이다. 우리가 흔히 In-memory key-value 저장소라 함은 메모리상에 key-value가 쌍으로 저장됨을 의미한다.  Redis 역시 이러한 구조이다.

Redis에서 key는 string이미지만 value는 string, list, sorted set 또는 hash 값을 갖을 수 있다.

이러한 몇가지 key-value 예는 아래와 같다.

name="narayan"

profession=["web", "mobile"]

여기에서 name과 profession은 key에 해당한다. 그리고 오른쪽에는 그에 해당하는 값들을 의미한다.

DBMS위에 Redis 와 장점과 단점

데이터베이스 시스템은 쓰기 명령을 기반으로 매우 느리게 기록되는는 이차(Secondary) 저장소이다. 하지만 redis는 모든 것을들 매우 빠른 속도로 읽기 및 저장하는 1차 저장소이다.

Primary memory의 크기는 제한적이다. 오직 작은 문자형 정보형들만 저장가능하다. 만약 우리가 메모리보다 더 큰 데이터를 쓰고자 하면 에러를 받을 것이다.

Redis Single Instance Architecture

Redis는 크게 2가지 client와 server 구성 프로스세로 나뉜다.

Redis client와 server는 단일 머신이나 또는 다른 2대의 computer에서 동작할 수 있다.

Redis server는 메모리상에 데이터를 저장하는 책임을 갖는다. Redis client는 console client나 또는 Redis API를 이용하여 다른 어떠한 프로그래밍 언어로도 사용 가능한다.

Redis Persistance

데이터를 저장하는데에는 크게 3가지 다른 방법이 존재한다. : RDB, AOF 그리고 SAVE

RDB Mechanism

RDB는 메모리상에 모든 데이터를 복사하고 그것들을 2차 저장소(디스크)에 저장한다. 이러한 행동들은 정해진 간격을 두고 행해진다. 그리고 이 때 RDB의 마지막 스냅샷을 기록한 이후부터는 데이터를 잃을 수 있는 가능성이 있다.

AOF

AOF는 모든 쓰기 명령들을 서버로부터 수신하여 기록한다. 그렇기 때문에 모든것들이 영구적이다. 다만 AOF는 모든 쓰기 명령들에 대해 기록하기 때문에 비용이 비싸며 RDB  파일보다 사이즈가 크다.

SAVE Command

사용자들은 언제든지 redis console clinet상에서 SAVE 명령을 이용하여 RDB 스냅샷을 강제 생성할 수 있다. 또한 최적의 결과를 얻기 위해 AOF와 RDB 둘 다 사용할 수도 있다.

Backup And Recovery Of Redis DataStore

Redis는 데이터 백업과 복원을 위해서는 어떠한 매커니즘을 제공하지 않는다. 그렇기에 하드디스크의 충돌(Crash)나 다른 어떠한 장애 상황을 대비해서 3rd party 서버 백업 솔루션이 필요할 것이다. 만약 당신이 redis 복제 환경을 구성했다면 백업 솔루션은 필요 없을 것이다.

Redis Replication

복제는 무장애를 만들 수 있는 기술이다. 복제환경상에서 많은 컴퓨터들을 동일한 데이터를 상호 교환함으로 만약 몇 대의 컴퓨터가 다운된다 하더라고 모든 데이터는 이용가능하다.

Persistance In Redis Replication

지금까지 예상치 못한 장애나 백엔드 단에서 안전하게 운영 및 유지하는 방안에 대해 살펴보았지만 단 한 경우 모든 복제 환경이 다운되었을 때 데이터를 잃을 수 있는 상황이 있다.

이러한 상황이 발생할 수 있는 이유는 모든 데이터가 Primary  메모리 상에 올라가기 때문에 발생한다. 그렇기에 우리는 마스터 또는 슬레이브 장비 중 하나에 대해 저장 속성(AOF 또는 RDB) 속성을 이용할 수 있다. 이러한 기능을 사용함으로 완전하게 안전하게 데이터를 저장 및 복제 운영할 수 있다.

Clustering In Redis

클러스터링 기술은 여러 컴퓨터들에데 데이터를 Shard (분산)하는 방식이다. 이 것의 가장 큰 장점으로는 컴퓨터들의 조합으로 인해 더 많은 데이터들을 저장 할 수 있다는 것이다.

예를 들어 우리가 하나의 redis server에 64GB의 메모리가 있다면 우리 데이터는 64GB 가 max 이다. 하지만 만약 우리가 10대의 컴퓨터에 클러스터링을 구성한다면 640GB의 데이터를 저장할 수 있게 된다.

위에는 4개의 노드로 샤드되어진 데이터를 볼 수 있다 .각각의 노드에서는 closter node 처럼 redis server가 구성되어져 있다.

만약 이 노드 중 하나의 노드가 멈추게 된다면 전체 클러스터가 멈추게 될 것이다.

Persistance In Cluster

데이터는 노드들의 primary  memory 상에서 저장되어져 있다. 여기서는 각각의 노드들에 persistance를 설정할 필요가 있다. 앞에서 언급했듯이 AOF 또는 RDF를 이용하여 모든 노드에서 persistance를 구정할 수 있다.

Clustering And Replication Together

디스크에서 Crash 가 발생하고 노드 중 하나가 멈추는 상황이 발생하면 전체 클러스터는 멈추게 되고 결코 되살아 나지 않을 것이다. 데이터들은 완전하게 잃을것이고 데이터를 복수 할 수 있는 상황을 없게 된다.

이러한 상황을 피하기 위해 각각의 노드들을 정기적으로 수동 백업을 할 수 있지만 매우 터프하고 부적절한 작업이 될것이다. 그렇기에 복제 기술로 이 문제를 해결할 수 있을 것이다.

위 그림에서 각각의 노드 서버들을 마스터 서버로 전환했다.  그리고 모든 마스터 노드들을 위한 slave를 유지했다. 그럼으로 만약 어느 노드라도 실패를 하게 되면 클러스터는 slave를 이용하여 클러스터 명령들을 수행할 것이다.

Redis Client

If you are first time getting yourself into redis then these links will be very helpful to install redis and learn redis client.

1. Try Redis: This is a awesome online Redis console client which will help you to learn how to use Redis console client.
2. Redis Quick Start: This article will help you to install redis and get started with it.
3. FAQ’s: You can see the frequently asked questions about redis on this link.

★닷넷에서 활요 가능한 Redis Client

출처: <http://redis.io/clients#c>

공식 페이지상에 여러 개의 3rd library 가 소개되어 있지만 개인적으로는 StackExchange 가 가장 쓰기 편한듯 싶다.

.

간만에 본 일본 영화.

일본 살 때도 좀 생각나고.. 

일본 사람들만의 특이한 대화법도 생각나는...

그러면서도 일본인들만의 고독한 도시에 사는 사람들의 감성을 풀어낸 영화.

2011년 대지진 때 한국으로 들어왔는데..

영화속에서 대지진 피해자 가족이 나오는게.. 조금이겠지만 같은 사건을 공유한 한 사람으로서 좀 더 마음이 끌리는 전형적인 일본 감성 드라마인듯 싶다.

http://m.movie.daum.net/moviedb/main?movieId=91681