안드로이드 어플리케이션 개발 시 YoutubeStandAlonePlayer 를 쓸 일이 있었서 사용했는데 예상치 못한 버그가 발생하더군요. 그 현상과 해결방법을 정리합니다.

1 현상

안드로이드 앱 개살시 메인 어플리케이션을 Portrait 전용으로 개발중이였습니다.

Intent intent = YouTubeStandalonePlayer.createVideoIntent(context,
                    DEVELOP_KEY, youtubeCode);
                context.startActivity(intent);

와 같은 식으로 유튜브 플레이어를 띄우니 띄운 액티비티(Activity) 와 그 스택에 쌓여있던 액티비티 들의 onResume 이 호출되는 현상이 있습니다. 그래서 플레이중에 멋대로 호출된 Activity 로 튕깁니다. 게다가 어찌 어찌 플레이되더라도 플레이중에 백키를 누르면 호출된 액티비티로 가는게 아니라 앱이 종료됩니다.

2 원인

아마도 Landscape 전용인 YouTubeStandalonePlayer 와 Portrait 로 만들어진 메인 앱과의 차이점 때문인 것 같다고 판단하여 해결법을 찾았습니다.

3 해결

YouTubeStandalonePlayer 를 호출하는 Activity 와 그 스택에 쌓여 있는 Activity 들의 AndroidManifest 안에 android:configChanges="orientation|screenSize|keyboardHidden" 와 같은 내용을 추가해주면 해결됩니다.

<activity
    android:name=".scene.IntroActivity"
    android:configChanges="orientation|screenSize|keyboardHidden"
    android:screenOrientation="sensorPortrait" />
<activity

와 같은 식입니다.

ADT (Android Developer Tool)를 사용하다 보면 중대한 한가지 문제(한가지 뿐이겠냐만은..)가 있습니다. 여러명이 작업을 할 때 한명이 프로젝트를 생성하고 git 레파지토리에 프로젝트를 올린 것을 다른 사람들이 받아서 프로젝트를 세팅할려고 할 때 문제가 발생합니다.

~/work/android-projects/Original

에 소스를 받았다고 하면 ADT 나 Eclipse 는 바로 저 위치에서 프로젝트를 만들 수가 없습니다. 바로 workspace 에 복사를 하던가 import 를 해야 하기 때문이지요. 강제로 같은 곳을 지정해주면 에러가 발생합니다. 이 부분은 정말 많은 구글링을 해봐도 거의 답이 없다는 것이 정설입니다. 많은 사람들이 Eclipse 를 욕합니다. 개발자들이 점점 git 이나 svn 을 이용하면서 IntelliJ 로 이동하는게 다 이유가 있는 것 같습니다. (물론 svn 이나 git 으로 바로 프로젝트를 생성하는 방법이 있기는 있는데 많이 불편합니다)

물론 Command Line 에서는 간단합니다. 'android update project' 명령을 이용하면 쉽게 ant 용 프로젝트로 변경시킬 수가 있고 이대로 공유하면 개발하는데 아무 문제도 없습니다.

그래도 같이 일하는 개발자들이 Command Line 을 좋아할 리가 없으니 IDE 를 이용하는 선에서 협상을 해야 합니다. 결국 답은 Android Studio 가 되겠지요. 그런데 Android Stuido 도 문제가 있습니다. 기존의 Eclipse 기반의 Project 구조를 변경합니다. (기존의 프로젝트를 app 이라는 이름으로 변경하여 구조가 변경됩니다) 이것이 변경되기 때문에 또 Eclipse 개발자가 개발하기 힘듭니다. 즉 정리하자면

  • git 레파지토리에 소스가 있고
  • Eclipse 개발자와 Android Studio 를 이용하는 개발자들 간에 협업을 할 수 있는 프로젝트 구조를 만들어야 함

이 두가지를 만족해야 합니다. 어려워 보이지만 (실제로도 어려웠습니다..) build.gradle 파일을 프로젝트 root 에 만들어주고 Android Studio 에서 'Import Non-Android Studio Project' 로 만들어 주면 됩니다.

build.gradle 파일의 예입니다.

buildscript {

  repositories {
    mavenCentral()
  }

  dependencies {
    classpath 'com.android.tools.build:gradle:+'
  }
}

apply plugin: 'android' 


repositories {

  mavenCentral()
  mavenLocal()
}


dependencies {
  compile fileTree(dir: 'libs' , include: '*.jar')
  compile('com.google.android.gms:play-services:+') {
    exclude group: 'com.android.support', module: 'support-v4'
  }

  compile 'com.android.support:appcompat-v7:+'

  compile project(':aplib_aos')
}

android {

  compileSdkVersion 21
  buildToolsVersion "21.0.1"

  sourceSets {
    debug.setRoot('build-types/debug')
    release.setRoot('build-types/release')

    main {
      manifest.srcFile 'AndroidManifest.xml'
      java.srcDirs = ['src']
      resources.srcDirs = ['src']
      aidl.srcDirs = ['src']
      renderscript.srcDirs = ['src']
      res.srcDirs = ['res']
      assets.srcDirs = ['assets']
    }
  }

}

나머지 부분은 위의 내용을 그대로 써도 되지만 제일 중요한 부분이 바로 dependencies 부분입니다. 이 부분만 자신의 프로젝트에 맞게 구성만 해주시면 됩니다.

dependencies {
  compile fileTree(dir: 'libs' , include: '*.jar')
  compile('com.google.android.gms:play-services:+') {
    exclude group: 'com.android.support', module: 'support-v4'
  }

  compile 'com.android.support:appcompat-v7:+'

  compile project(':aplib_aos')
}

이 부분만 따로 설명을 드리자면 기본적으로 $PROJECT_ROOT 밑의 libs 밑에 있는 jar 파일을 포함시키라는 뜻입니다. 그리고 google-play-service 를 외부 라이브러리로 링크하고 support-library v7 도 외부 라이브러리로 링크하라는 것입니다.

compile project(':aplib_aos')

이 부분이 중요한데 이 부분은 안드로이드 스튜디오의 'File' - 'Import Module' 명령을 이용해서 외부의 라이브러리 프로젝트를 포함시킨 경우에 그 라이브러리 모듈이름을 적어 주는 부분입니다. 위 명령을 이용하면 자동으로 settings.gradle 파일에 어떤 모듈이 포함됐는지 쓰여집니다.

모바일 개발자가 혼자 일하는 상황이면 사실 이런 경우는 전부 삽질일것입니다. 그러나 레파지토리에 소스를 옮겨서 관리하는 경우도 그렇고 한번 내려 받은 소스를 이용해서 다시 프로젝트를 구성하는 경우에는 항상 발생하는 문제일 것이라 생각해서 정리해 둡니다.




Multiple dex files define Landroid/support/v4 관련된 어쩌구 저쩌구 에러가 발생했을 때의 대처법입니다.

100% 제 환경에서 발생하는 일이였습니다. 먼저 환경을 소개하자면 회사에서 개발하는 안드로이드 (Android) 프로젝트인데 전부 환경이 달라서 문제가 발생했습니다.

  • PM 인 저는 Command Line 에서 프로젝트를 개발합니다. 사용하고 있는 툴(Tool)은 Emacs 에 Ant 를 이용해서 빌드합니다.
  • 회사에서 작업하는 개발자는 Android Studio 를 이용해서 개발합니다.
  • 회사 외부에서 개발하는 개발자는 ADT (Android Development Tool) 을 이용합니다.

저와 외부에서 개발하는 개발자간의 호환은 별 문제가 없습니다. Eclipse 와 Command Line 은 거의 프로젝트 세팅이 비슷한거 같습니다. 물론 따로 설정해줘야 하는 부분이 있지만.. 하지만 ADT 와 안드로이드 스튜디오 간에는 차이가 확실히 존재하더군요.

play-services 를 이용해서 개발하는 것입니다. ADT 에서는 따로 Library Project 를 설정해서 기존 프로젝트에 포함시켜주면 되는 것이였습니다. 그러나 Android Studio 는 방법이 다르더군요.

Google Play Service 세팅법 을 참조해서 하면 build.gradle 을 열고 다음과 같이 추가해 주면 되는 것입니다.

dependencies {

    compile 'com.google.android.gms:play-services:6.5.87'
}

그러나 에러가 발생하더군요. 이유는 간단했습니다. ADT 에서 참조하는 libs 에 android-support-v4.jar 이 포함됐기 때문입니다. 그렇다고 바로 지우자니 그 담부터는 ADT 를 이용하는 외부 개발자님의 빌드가 깨지겠지요.

그래서 다음과 같이 바꾸어 줍니다.

dependencies {
    compile fileTree(dir: 'libs', include: '*.jar')
    compile ('com.google.android.gms:play-services:+') {
                exclude group: 'com.android.support', module: 'support-v4'
    }
}

그리고 Android Studio 에 있는 Toolbar 를 보면 'Sync Project with Gradle Files' 라는 버튼을 눌러주고 프로젝트를 빌드해 주면 됩니다.

제가 좋아하는 무협용어로 바꾸어봐도 비슷한 이야기라고 생각합니다. 고수와 중수의 차이란? 요즘 프로젝트들이 실패하는 광경을 여러번 봤기 때문에 다시금 이러한 생각을 하게 되는군요. 고수(고급)와 중수(중급)는 기술상으로는 별 차이가 없다고 봅니다. 가장 큰 차이는 무엇이 있을까? 라는 고민을 해보니 기술적으로 보면 그리 큰 차이가 없다고 봅니다. 구글이 모든 프로그래머들의 성전이 된 지금에 있어서는 고수도 검색하고 중수도 검색하고 하수도 검색합니다. 같은 기술을 찾아서 적용하는 것은 이해 속도의 차이일뿐 기술적으로 난이도가 크지는 않습니다. (예전에는 당연히 이것도 고수가 되는 조건중의 하나였을 것입니다) 


1. 적응성 

  고수들은 새로운 개발 환경, 새로운 언어에 적응이 빠릅니다. 새로 리눅스 환경에서 개발을 하든 , 또는 파이선에 플라스크로 개발을 하던, Node.js 로 개발하던 고수들은 당황하지 않고 '조금만 배우면 되지' 라는 마음으로 기술을 배우지만 중수들은 그러하지 않습니다. 일례로 자바를 잘하는 집단을 보유한 회사에서 파이썬으로 된 솔루션을 해석을 못해서 타 회사에게 맡기는 경우를 본 적이 있습니다. '대체 왜?' 라고 생각하시는 분들도 많겠지만 '귀찮음' 인지 진짜 몰라서 인지 그러한 경우에 포기를 하더군요. 이런 점에서 고수와 중수의 차이를 보게 됩니다. 단지 마음가짐의 차이가 아니겠는가? 라고 하시는 분도 있겠지만 마음가짐과 실제로 조금이라도 경험을 해본 것에 따르는 차이도 무시 못하겠더군요. 즉 한가지 기술에만 안주해서 '그걸로 다 되는데 왜 새로운 것을 배워야 하나?' 라는 마음가짐과 실제로 경험을 안 겪어본 사람과 새로운 것을 이거저거 실험해보는 사람과의 차이는 정말 무시하기 힘듭니다. 


2. 리더쉽 

 사실 이것이 가장 큰 이유라고 저는 보고 있습니다. 조금이라도 규모가 큰 작업들은 무조건 PL(Program Leader)급을 고용해서 진행하라는 조언을 아끼지 않는 이유가 바로 이러한 이유때문입니다. 위에서도 기술적인 난이도가 거의 없다고 말씀드렸습니다. 사실상 초급(하수)들을 데려다가 시간을 주고 괴롭히면(?) 어느정도 아웃풋이 나옵니다. 그건 정말 조그마한 프로젝트의 경우에만 그렇습니다. 정말 커다란 프로젝트나 말도 안되는 고객의 요구를 들어줘야 하는 프로젝트의 경우에 팀을 이끌어 가는 고수가 없다면 정말 헤아릴 수 없는 손해를 봅니다. 가장 최근에 이러한 경우를 겪었기에 정말 자신있게 말씀드릴 수가 있습니다. 안 그러한 분야가 거의 없겠지만 커다란 프로젝트는 정말 선택의 연속입니다. 여기 선택의 과정에서 적절하게 선택을 행해주지 않는다면 정말 배가 산으로 가는 경우를 자주 목격합니다. 따라서 본인 혼자의 기술 숙련도 뿐만 아니라 속해져 있는 모든 팀원들의 프로젝트 적응성을 이끌어 나갈수 있는 인재를 진정한 고수라고 볼 수 있습니다. 


그렇다면 경영자의 관점에서는 언제 어떠한 경우에 고수,중수,하수 를 적절하게 쓸 수가 있을까요? 아까 말했듯이 프로젝트의 규모에 따라서 고용 여부를 결정할 수가 있을 것입니다. '고수는 비싸지 않느냐?' 라고 외치는 경영자 분들이 계십니다. 하지만 그 몇 백만원을 아끼려다 2-3개월 딜레이 되고 몇천을 날리는 경우를 수도 없이 봤기 때문에 정말 단언할 수가 있습니다. 중요하거나 시간내에 끝내야 되는 일이라면 꼭 '고수'를 고용해서 고객(자사의 개발이라면 본인)의 신뢰를 얻어 내시기 바랍니다. 



하둡(hadoop) 의 옛버젼이 필요할 때가 있습니다. 예를 들면 최근 하둡(hadoop) 은 2.6.0 버젼대로 올렸지만 스파크(Spark) 는 1.2.0 버젼이 최신인데 하둡(hadoop)은 2.4.1 버젼과 맞춰줘야 하는 문제가 있습니다.

따라서 옛날 버젼의 하둡(hadoop)을 원하신다면 아래의 링크에 가서 원하는 버젼을 고르시면 됩니다.

http://archive.apache.org/dist/hadoop/core/

매번 버젼이 바뀔때 마다 쓰는 것이 지겨워서 한동안 안쓰고 있었는데 예전에 설치하던 시절하고 너무 많이 바껴서 정리를 할 필요가 있겠더군요.

http://rocksea.tistory.com/282

위의 링크는 제자가 열심히 정리한 버젼입니다. 이번 포스트는 저 포스트에서 부족한 부분을 채우는 식으로 정리할려고 합니다.

1 준비 사항

  • HOST OS: OSX Yosemite
  • 가상 컴퓨터 소프트웨어: VMWare 7.0 (아니면 Virtual Box)
  • Linux Ubuntu 14.04 LTS (Server Version)

1.1 버추얼 박스(Virtual Box)

굳이 버추얼 박스가 아니라도 괜찮습니다. VMWare 나 Parallel 도 괜찮습니다. 버추얼 박스는 공짜기 때문에 제목으로 달아논 것이고 저는 실제로 VMWare Fusion 을 썼습니다.

  • Guest OS 를 우분투로 세개 설치해줍니다. 저는 14.04 LTS 를 이용했습니다. 그리고 세개를 다 깔아주면 불편하기 때문에 한개를 깔고 기본적인 설정을 해주고 그 Guest OS 파일을 복사해주고 Mac Address 를 바꿔주는 식으로 설치해줬습니다.

1.2 네트워크를 고정 아이피로 설정해주기

고정 아이피로 만들면 이후에 세팅에서 엄청나게 편해집니다.

m/s hostname id
master cloud0 cloud
slave cloud1 cloud
slave cloud2 cloud


위와 같은 형태로 서버들을 구성할 예정입니다. 따라서 다음 부분은 각각의 Guest OS 에 전부 적용해 주어야 합니다.

1.2.1 DHCP 로 받아오는 부분을 static 으로 변경해서 파일을 변경해준다. /etc/network/inteface 를 열어서 다음 부분을 바꾸어 준다.

auto etho0
iface eth0 inet dhcp

이 부분을 커멘트 처리해주고 ('#' 을 맨 앞 라인에 써준다)

auto eth0
iface eth0 inet static 
address 172.16.242.100
netmask 255.255.255.0
gateway 172.16.242.2

와 같은 식으로 적어준다. dhcp 가 static 으로 바뀌고 address , netmask , gateway 를 상황에 맞게 써주는 것을 잊지 않는다. 위의 것은 어디까지 나의 경우에 예에 해당하는 것입니다.

1.2.2 /etc/resolvconf/resolv.conf.d/base 의 수정

예전에는 /etc/resolv.conf 를 수정했으나 이 파일이 이제 서버가 리스타트 될 때마다 리셋이 된다. /etc/resolvconf/resolv.conf.d/base 를 열어서

nameserver 8.8.8.8

를 추가해주고

$ sudo resolvconf -u

로 새로 만들어 주면 된다. 이 작업은 cloud0 , cloud1, cloud2 각각의 상황에 맞게 작성해줘야 합니다.

그리고 /etc/hosts 파일에

172.16.242.100 cloud0
172.16.242.101 cloud1
172.16.242.102 cloud2

와 같이 추가해 줍니다. 역시나 각각의 cloud0, cloud1, cloud2 에서 작업해줘야 합니다. 주어진 ip 는 제 경우입니다.

1.3 password 없이 각각의 서버에 접속할 수 있게 만들기

master 에서 slave 들에만 접속할 수 있게 만들면 됩니다. 즉 cloud0 -> cloud1 , cloud2 로 연결되어야 하니 cloud0 에서 다음과 같은 작업을 해 줍니다.

$ ssh-kegen -t rsa 

$ ssh cloud@cloud1 mkdir -p .ssh
$ ssh cloud@cloud2 mkdir -p .ssh

$ cat ~/.ssh/id_rsa.pub | ssh cloud@cloud1 'cat >> ~/.ssh/authorized_keys'
$ cat ~/.ssh/id_rsa.pub | ssh cloud@cloud2 'cat >> ~/.ssh/authorized_keys'

1.4 add-apt-repository 을 사용할 수 있게 만들어 주기

우분투(Ubuntu) 를 쓰면서 한번도 add-apt-repository 가 동작 안하는 것을 상상해 본적이 없어서 당황스러웠습니다. 우분투 server 로 설치하면 add-apt-repository 를 사용하기 위해서 필요한 패키지가 있습니다.

$ sudo apt-get install software-properties-common

이것을 설치해 줘야 합니다.

1.5 Java 설치

Java 의 버젼은 상관 없다고들 합니다. 그런데 계속해서 테스트 했던 버젼이 oracle java 이기 때문에 그것을 설치하기로 합니다. 이래저래 귀찮으니까 apt-get 을 이용해서 설치해 주기로 합니다. 뭐니 뭐니 해도 쉬운게 최고입지요.

$ sudo add-apt-repository ppa:webupd8team/java
$ sudo apt-get update
$ sudo apt-get install oracle-java7-installer

질문 나오는 것에 모두 YES 해서 설치해주면 됩니다. 참고로 이건 cloud0, cloud1, cloud2 에서 다 설치해줘야 합니다.

2 하둡 (Hadoop) 설치

Guest OS 세대에 전부 Ubuntu Server 를 설치해주고 네트워크 까지 설치했다면 본격적으로 설치를 시작할 시간입니다. master 로 설정할 cloud0 에서 작업을 시작합니다.

2.1 하둡 다운로드

http://ftp.daum.net/apache/hadoop/core/stable2/hadoop-2.6.0.tar.gz

위의 파일을 다운 로드 받아서 게스트 (Guest) 에 밀어 넣던지 아니면 게스트에서 (인터넷이 된다는 가정하에)

$ cd ~/
$ wget http://ftp.daum.net/apache/hadoop/core/stable2/hadoop-2.6.0.tar.gz

같은 방식으로 다운 받으시면 됩니다. 그리고 rsync 를 이용할 것이기 때문에 master 인 cloud0 에서 작업을 진행하면 됩니다. 최근의 spark 는 2.4.1 대의 하둡을 지원합니다. 그러나 어느날 갑자기 옛날 버젼의 하둡이 사라졌습니다. 현재의 stable2 는 바로 hadoop 2.6.0 버젼입니다. 나중에 spark 는 따로 컴파일을 해줘야 할 것입니다. 아니면 2.6.0 대로 맞춘 버젼이 나오길 기다립시다.

적당한 곳에 풀어줍니다.

$ cd ~/
$ tar xvzf hadoop-2.6.0.tar.gz

$HADOOP_HOME = ~/hadoop-2.6.0 이라고 가정합니다.

2.1.1 실제 데이타 저장 디렉토리 생성

실제로 데이타가 저장될 디렉토리를 만들어 줍니다. cloud0, cloud1, cloud2 에서 모두 만들어줘야 합니다.

$ sudo mkdir -p /data/hadoop/tmp $ sudo mkdir -p /data/hadoop/dfs/name $ sudo mkdir -p /data/hadoop/dfs/data $ sudo chown -R cloud:cloud /data/hadoop

/data/hadoop 의 owner 를 cloud 로 바꿔주는 것을 잊으면 안됩니다. 이 작업을 안해주면 나중에 hadoop 이 포맷하고 실제로 네임노드 , 데이터노드가 실행시 에러가 발생합니다.

2.1.2 $HADOOP_HOME/etc/hadoop/core-site.xml 수정

다음과 같이 수정해줍니다.

<configuration>
  <property>
    <name>fs.defaultFS</name>
    <value>hdfs://cloud0:9000</value>
  </property>
  <property>
   <name>hadoop.tmp.dir</name>
   <value>/data/hadoop/tmp</value>
  </property>
</configuration>

fs.defaultFS 는 하둡 파일시스템의 진입점을 보통 지정합니다. master 를 가르키는게 일반적입니다.

2.1.3 $HADOOP_HOME/etc/hadoop/hdfs-site.xml 수정

다음과 같이 수정합니다.

<configuration>
    <property>
        <name>dfs.replication</name>
        <value>2</value>
    </property>
    <property>
        <name>dfs.namenode.name.dir</name>
        <value>file:/data/hadoop/dfs/name</value>
        <final>true</final>
    </property>
    <property>
        <name>dfs.datanode.data.dir</name>
        <value>file:/data/hadoop/dfs/data</value>
        <final>true</final>
    </property>

    <property>
        <name>dfs.permissions</name>
        <value>false</value>
    </property>
</configuration>

dfs.replication 은 HDFS 내에서 몇개의 블록을 복사해서 유지할 것인가 하는 것입니다. 숫자가 커질수록 안정도는 올라가지만 속도는 저하됩니다. 우리는 그냥 2로 정합니다. dfs.namenode.name.dirdfs.datanode.data.dir 은 위에서 지정해 준 디렉토리를 지정해줍니다.

2.1.4 $HADOOP_HOME/etc/hadoop/mapred-site.xml 수정

아마 파일이 없으면 만들어 주시면 됩니다.

<configuration>
  <property>
      <name>mapreduce.framework.name</name>
      <value>yarn</value>
  </property>
  <property>
    <name>mapred.local.dir</name>
    <value>/data/hadoop/hdfs/mapred</value>
  </property>
  <property>
    <name>mapred.system.dir</name>
    <value>/data/hadoop/hdfs/mapred</value>
  </property>
</configuration>

mapreduce.framework.name 이 중요합니다. 최근 하둡은 맵리듀스 관리를 얀(YARN) 으로 합니다. 꼭 지정해 줘야 합니다.

2.1.5 $HADOOP_HOME/etc/hadoop/yarn-site.xml 수정

<configuration>
<!-- Site specific YARN configuration properties -->
  <property>
    <name>yarn.nodemanager.aux-services</name>
    <value>mapreduce_shuffle</value>
  </property>
  <property>
    <name>yarn.nodemanager.aux-services.mapreduce_shuffle.class</name>
    <value>org.apache.hadoop.mapred.ShuffleHandler</value>
  </property>
  <property>
    <name>yarn.resourcemanager.resource-tracker.address</name>
    <value>cloud0:8025</value>
  </property>
  <property>
    <name>yarn.resourcemanager.scheduler.address</name>
    <value>cloud0:8030</value>
  </property>
  <property>
    <name>yarn.resourcemanager.address</name>
    <value>cloud0:8035</value>
  </property>
</configuration>

cloud0 로 쓰여진 부분은 각자 자신의 환경에 맞춰주면 됩니다.

2.1.6 $HADOOP_HOME/etc/hadoop/masters

마스터 (master) 서버가 어떤건지 지정해주는 파일입니다.

cloud0

cloud0 로 지정해주면 됩니다.

2.1.7 $HADOOP_HOME/etc/hadoop/slaves

datanode 로 사용할 서버들을 적어주면 됩니다.

cloud1
cloud2

전체 3대를 사용할 꺼기 때문에 master 를 제외한 나머지를 적어주면 됩니다.

2.1.8 $HADOOP_HOME/etc/hadoop/hadoop-env.sh 수정

export JAVA_HOME=/usr/lib/jvm/java-7-oracle

와 같은 식으로 자바 위치만 정해주면 됩니다.

2.1.9 rsync 를 이용한 복사

cloud0 에서 다음과 같이 실행해 줍니다.

$ rsync -avz ~/hadoop-2.6.0 cloud@cloud1:/home/cloud/
$ rsync -avz ~/hadoop-2.6.0 cloud@cloud2:/home/cloud/

이러면 모든 노드(Node) 의 설정이 동일해집니다. 나중에 따로 생각해 내서 하기 힘들기 때문에 이 부분을 스크립트(script)로 만들어서 노드가 추가되면 스크립트에 추가된 노드분만 추가해 주는 식으로 관리해 주는것이 편할것 같습니다.

2.2 하둡(Hadoop) 실행

사용하기 전에 HDFS 를 포맷해줄 필요가 있습니다.

$ hadoop namenode -format

그리고 분산파일 시스템과 맵리듀스 시스템을 구동시켜주면 됩니다. $HADOOP_HOME 에서

$ sbin/start-dfs.sh
$ sbin/start-yarh.sh

를 실행시켜주면 됩니다. 제대로 동작하고 있는지 확인을 위해서는 cloud0 (즉 마스터) 에서

$ jps

를 입력해서 namenode (dfs 관련 서버) 와 resourcemanager (yarn 관련) 가 구동되어 있는지 확인하면 되고 cloud1 와 cloud2 에서도 마찬가지로

$ jps

를 입력해서 datanode(dfs 관련 서버) 와 nodemanager (yarn 관련)이 구동되어 있는지 확인하면 됩니다.


리모트 브랜치 그대로 업데이트

외부의 소스를 받아서 변경점 그대로 업데이트 하고 싶을 때가 있습니다. 즉 외부 소스를 받아서 컴파일을 해서 사용하는 경우인데 변경된 점이 남아 있어서 'git pull' 명령을 쓰자니 컴파일을 위해서 생성된 파일들과 merge 가 되버려서 관리가 힘든 경우가 있지요. 이때 지금 변경된 것을 무시하고 리모트 브랜치로 강제로 변경하는 방법에 대해서 알아보겠습니다.

GIT 가이드

에 가시면 자세한 git 사용법에 대해서 배울 수가 있습니다. 사실 이 명령도 거기서 나온 방법이지요.

$ git fetch origin
$ git reset --hard origin/master

자주 안 쓸거 같아서 알고만 있었는데 의외로 자주 사용하게 되더군요.




1 플라스크 (Flask) 소개

파이썬 에서 쓰이는 웹 프레임워크라고 하면 장고 를 떠올리기 쉽습니다. 그런데 실은 장고는 이제 덩치가 많이 커져서 예전만 못하다는 이야기가 많습니다. 그래서 정말 간단한 웹이나 모바일 앱 서버를 만들기에 적합한 웹프레임워크를 찾게 됐는데 그게 바로 플라스크 입니다.

소개만 하고 직접 가셔서 보시는게 빠를 것 같습니다. 정말 단순하고 빠르게 웹을 만들 수가 있습니다. 제가 지금까지 접해온 웹 프레임워크중에 가장 가볍게 빠를꺼라고 자부합니다. (express 안녕~)


http://flask-docs-kr.readthedocs.org/ko/latest/index.html


위에 가서 보시면 되고 한글화도 잘 되어 있습니다. 빠르게 시작하기(Quick Start)튜토리얼(Tutorial) 을 보며 기본 공부를 하고 나머지 확장을 공부하시면 편할 듯 합니다. 튜토리얼(Tutorial) 은 이런 계열에서는 유명한 블로그 만들기 입니다. 확장으로 볼마한 것은 역시 큰 어플리케이션을 만들때 필요한 것들인데 이것들 또한 패턴들(Patterns) 에서 소개가 되고 있습니다.

마지막으로 제일 중요한 'Hello World' 를 출력하는 예제만 보기로 하지요.

from flask import Flask
app = Flask(__name__)

@app.route('/')
def hello_world():
    return 'Hello World!'

if __name__ == '__main__':
    app.run()

뭐 경기 끝이죠? 7줄입니다. ㅎㅎ

Author: crazia

Created: 2014-12-12 Fri 12:57

data-generate

빅데이타 인프라를 구축했는데 막상 뭔가 테스트 해보고 싶어도 돌릴만한 예제가 없는 분들을 위해서 만들어 본 라이브러리입니다. 뭐 대단한 것은 아니고 ‘ID,TIMESTAMP,TRANSACTION’ 형식으로 세개짜리 필드로 은행권 로그를 모방했습니다. 일단 급한대로 만들어 쓸려고 만든것이기 때문에 더 만들어야 할게 많습니다. 나름 동접처리를 한다고 쓰레드 방식으로 동접으로 접속해서 처리하는 것도 시뮬레이션 했습니다.

추후에는 - 트랜잭션중에 자주 일어나는 것에 대한 빈도수 조절이 가능해질 것입니다. - 현재는 랜덤으로 사용자를 뽑아오지만 충성고객에 대한 범위를 지정할 수가 있을것입니다. - MAC 이나 IP Address 생성룰을 고민해서 붙일 수도 있을것입니다.




결과입니다. 


EDITED:

TIMESTAMP 가 yyyyMMddHHmmss 에서 yyyyMMddHHmmss.SSS 형식으로 밀리세컨드까지 표현하게 바꼈습니다. 


사용법

  • 설명 보기
$ java -jar data-generate.jar 
  • 예제
$ java -jar data-generate.jar -a 1000000 -f 2014-03-07 -t 2014-05-06

2014년 3월 7일 부터 2014년 5월 6일까지 하루에 백만개의 로그를 생성하는 명령입니다.

License

Copyright © 2014 Comjuck

Distributed under the Eclipse Public License either version 1.0 or (at your option) any later version.



data-generate.jar



클로져는 정말 멋지게도 언어레벨에서 Concurrency 를 지원합니다. 물론 그래서 어렵다는 평을 받긴 하지만 이미 개념을 알고 있는 사람들은 이보다 더 편할 수가 없습니다. 게다가 자바와의 연계성이 뛰어난 점 때문에 클로져는 정말 멋진 언어입니다. 


최근 무어의 법칙이 더이상 통하지 않고 CPU 의 코어수만 늘어나는 상황하에서 멀티쓰레드 프로그래밍을 모른다면 진정한 컴퓨팅 파와를 쓸 수가 없습니다. 그렇기 때문에 저는 예전부터 클로져를 눈여겨 왔었는데요. 그 클로져의 Concurrent Programming 에 관한 괜찮은 글을 찾아서 여기에 소개합니다. 


http://blakesmith.me/2012/05/15/understanding-clojure-concurrency-part-1.html


위는 간단하 개요 소개의 글입니다. 정말 쉽게 설명했습니다. 아쉽지만 영어입니다 ㅎㅎ 


http://blakesmith.me/2012/05/25/understanding-clojure-concurrency-part-2.html


각각의 프로그램 언어에서 지원하는 개념들과 예제입니다. 차분히 읽어 가시면 어려울게 별로 없으니 클로져에 관심이 있다면 꼭 한번 보실만 합니다. 



+ Recent posts