Thursday, October 20, 2016

Apache Kafka (아파치 카프카)란?

Apache Kafka란?

아파치 카프카는 2011년에 링크드인(LinkedIn)이라는 회사에서 자사의 웹사이트 이벤트 체크를 하기 위한 목적으로 만들어진 사내 프로젝트로 시작했다가 2014년에 아파치를 통해 오픈 소스화된 프로젝트로 현재 빅데이터 관련 프로젝트에 가장 널리 사용되고 있는 distributed messaging system입니다. 현재 링크드인을 비롯해서 야후, 트위터, 넷플릭스, 우버 등 실시간으로 대용량의 데이터를 처리해야 하는 어플리케이션을 운영하고 있는 회사에서 메세징 시스템 뿐만아니라 실시간 모니터링, 이벤트 프로세싱등 다양한 용도로 사용되고 있습니다. 그렇다면 아파치 카프카에 어떤 특별한 점이 있길래 이렇게 짧은 시간 안에 수많은 빅데이터 회사에게 널리 사용되게 되었는지 아래의 글에서 확인해보도록 하겠습니다.

Why Use It? 왜 사용하나요?

  • High-throughput message capacity: 쉽게 이야기해서 단 시간 내에 엄청난 양의 데이터를 컨슈머 쪽으로 전달 가능합니다. 다른 경쟁 제품에 비해 많은 양의 데이터 전송이 가능한 이유는 크게 두 가지 있는데 우선 첫째, 기존의 메세지 시스템이 메세지 브로커 쪽에서 가지고 있던 모든 복잡한 과정 또는 연산들을 제거했고 둘째, 하나의 토픽에 대해 여러 개의 파티션으로 분할 할 수 있도록 해서 컨슈머 쪽에서 분산 처리할 수 있도록 하였습니다. 좀더 자세히 설명하자면 기존의 메세지 시스템들은 (RabbitMQ 같은) 각각의 토픽에 대해 컨슈머들의 인덱스 (데이터를 어디까지 전송받았는지를 알려주는) 정보를 메세지 브로커 쪽에서 관리하였는데 카프카는 이 부분을 컨슈머 쪽으로 책임을 옮겼으며 또한 메세지를 유지하는 방법도 메모리에 잠시 보관하였다가 컨슈머에 전송된 후 삭제하는 방법이 아니라 일반 파일에 Log 형식으로 (데이터가 날짜순으로 저장되고 Append만 가능한 형식) 관리하여 전송 후에 Delete 연산이 필요없는 방식을 사용하고 있습니다. 또한 토픽의 분할 기능을 제공하여 같은 토픽에 대해 여러 개의 컨슈머가 동시에 메세지를 전송 받는 등의 분산 처리를 지원하여 많은 양의 데이터 전송을 가능하게 하고 있습니다.
  • Scalability와 Fault tolerant: 카프카는 클러스터 모드를 지원하고 있으며 위에 언급했던 토픽 파티셔닝 (하나의 토픽을 여러 개의 파티션으로 나눌 수 있는 기능)과 파티션 복제 (Replication) 기능을 통해 확장성과 Fault tolerant (부분적으로 고장나더라도 중요한 기능들은 정상적으로 작동하는 특성)을 제공하고 있습니다.
  • 메세징 시스템 외에 다양한 용도로 사용 가능: 일반적인 메세징 시스템과 달리 카프카는 다양한 용도로 사용 가능하며 자세한 사용 용도에 대해서는 아래의 글을 참조하세요.

Use Cases (카프카의 사용 용도의 예)

  • Messaging System: 가장 일반적으로 많이 사용되고 있는 용도로 메세지 제공자 (Producer 또는 Source)와 수신자 (Consumer 또는 Sink) 사이에서 메세지를 전달해주는 역할을 합니다. 각각의 컨슈머 (또는 컨슈머 그룹)는 전달받기를 원하는 메세지의 토픽에 구독 신청해야 하며 하나의 토픽에 여러 컨슈머가 구독 신청 할 수 있습니다. (이 경우에 메세지는 구독신청한 모든 컨슈머한테 Broadcast 됩니다.)
  • Website Activity Checking 및 Monitoring: 링크드인에서 처음 만들고 사용했던 목적처럼 웹사이트가 정상적으로 돌아가는지 또는 웹사이트 사용 시 유저들의 패턴이 어떻게 되는지 모니터링 또는 웹사이트 이벤트 체킹의 목적으로도 사용 가능하며 (중간에서 메세지를 전달하는 중간자의 역할을 할 수도 있지만 메세지 자체가 디스크에 일정 기간 동안 로깅이 되어 있기 때문에 직접 분석도 가능합니다.)
  • Log Aggregation: 하나의 웹사이트가 여러 대의 서버로 운영되고 있다면 (대부분의 엔터프라이즈 웹사이트들이 그렇듯이) 각각의 서버에 있는 로그를 통합해주는 시스템 구축에도 사용 가능합니다.
  • Stream Processing & Batch Processing: 요즘 빅데이터 쪽에서 가장 핫한 Spark나 Storm같은 Stream Processing (스트림 처리)을 지원하는 플랫폼이나 Hadoop과 같이 Batch Processing (일괄 처리)을 지원하는 플랫폼과 연결햐여 메세지의 변환도 가능합니다.
  • Etc: 그 외에 연결된 DB나 서치 엔진의 일시적 서비스 장애 때문에 다운이 되었을 때 메세지들을 잠시 저장해줄 수 있는 임시 버퍼의 역할도 가능하며 Operational metrics (각각의 토픽에 대해 들어오는 메세지의 수를 정기적으로 체크하여 그 수가 너무 낮거나 높을 때 문제가 있는 확인차 운영팀에 메일등을 통해 알려주는 용도)나 Event sourcing (특정 이벤트들을 시간 순으로 기록하여 나중에 필요할 때 사용하는 용도) 등의 용도로도 사용되고 있습니다.

References

  • http://kafka.apache.org/intro.html
  • http://www.javaworld.com/article/3060078/big-data/big-data-messaging-with-kafka-part-1.html
  • https://www.quora.com/Can-I-use-apache-kafka-for-memory-cache
  • http://events.linuxfoundation.org/sites/events/files/slides/The%20Best%20of%20Apache%20Kafka%20Architecture.pdf
  • https://auriga.com/blog/hands-on-experience-building-architecture-of-highly-available-scale-out-systems-introduction/
  • http://blog.cloudera.com/blog/2014/09/apache-kafka-for-beginners/
  • https://sookocheff.com/post/kafka/kafka-in-a-nutshell/
  • https://www.elastic.co/blog/just-enough-kafka-for-the-elastic-stack-part1

Tuesday, October 11, 2016

Apache Kafka (아파치 카프카) 설치 (CentOS 7.2.1511 64-bit)

설치 전 준비사항

  1. CentOS 7이 설치된 서버 (또는 VM)
  2. 오픈 JDK 패키지 설치
    1.  yum install java-1.8.0-openjdk.x86_64
    2. 설치가 잘 되었는지 확인하려면 아래의 명령어를 실행해서 자바 버전 확인
      1. java -version
  3. 자바 환경 변수 설정
    1. 텍스트 에디터를 이용해서 ‘/etc/profile’에 자바 환경 변수 설정을 추가 
      1. vim /etc/profile
      2.  profile 파일 안에 아래의 내용을 추가
        1. export JAVA_HOME=/usr/lib/jvm/jre-1.8.0-openjdk
        2. export JRE_HOME=/usr/lib/jvm/jre
      3. source 명령어를 이용해서 변경된 내용 적용
        1. source /etc/profile

설치 단계

  1. Kafka 패키지 다운로드
    1. wget http://www-us.apache.org/dist/kafka/0.10.0.1/kafka_2.11-0.10.0.1.tgz
      1. 위의 버전이 최신 버전이 아니면 kafka 웹사이트 (http://www-us.apache.org/dist/kafka)에 들어가셔서 최신 버전을 확인 후 다운 받으세요.
    2. tar xvf kafka_2.11-0.10.0.1.tgz
    3. mv kafka_2.11-0.10.0.1 /opt
    4. cd /opt/kafka_2.11-0.10.0.1
  2. Zookeeper 서버 시작
    1. bin/zookeeper-server-start.sh -daemon config/zookeeper.properties
  3. Kafka 서버 시작
    1. bin/kafka-server-start.sh config/server.properties
      1. 서버 시작 후 아래와 같은 로그를 확인하셨다면 서버가 정상적으로 시작된 것입니다.
      2. INFO [Kafka Server 0], started (kafka.server.KafkaServer)
  4. Kafka 패키지에서 제공하는 클라이언트 프로그램을 이용한 간단한 서버 테스트
    1. 테스트 토픽 생성
    2. bin/kafka-topics.sh --create --zookeeper localhost:2181 --replication-factor 1 --partitions 1 --topic test
    3. Consumer 생성
      1. bin/kafka-console-consumer.sh --zookeeper localhost:2181 --topic test —from-beginning
    4. Producer 생성
      1. 같은 SSH 연결에서 Consumer와 Producer를 같이 생성할 수 없기 때문에 새로운 SSH 연결을 한 후 에 아래의 명령어를 실행합니다.
      2. bin/kafka-console-producer.sh --broker-list localhost:9092 --topic test
      3. 위의 명령어를 실행 후 콘솔에 텍스트를 입력하고 엔터를 누르면 입력한 텍스트가 Consumer 쪽 콘솔에 출력 되는 것을 확인하실 수 있으십니다.
  5. References
    1. https://www.vultr.com/docs/how-to-install-apache-kafka-on-centos-7
    2. http://davidssysadminnotes.blogspot.com/2016/01/installing-apache-kafka-and-zookeeper.html
    3. http://www.javaworld.com/article/3060078/big-data/big-data-messaging-with-kafka-part-1.html

Sunday, October 9, 2016

Redis Cluster (레디스 클러스터) 설치 (CentOS 7.2.1511 64-bit)

설치 전 준비사항

  1.  최소 2개 이상의 서버 (또는 VM)에 CentOS 7 설치. 아래의 설명에 사용된 서버들 정보는 아래와 같습니다. 
    1. Server A: 192.168.2.105
    2. Server B: 192.168.3.105
    3. Server C:  192.168.3.102
  2.  Redis 3.0 이상 버전의 패키지를 인터넷에서 다운 받아서 설치. 참고로 Redis Cluster는 3.0 이상 버전부터 지원 가능합니다. 아래는 레디스 3.0.0을 다운 받아서 설치하는 명령어의 예이며 만약 더 최신 버전을 원하시면 http://download.redis.io/releases 페이지에 들어가셔서 최신 패키지 정보를 얻으셔서 다운 받으시면 됩니다. 
    1. mkdir build && cd build
      wget http://download.redis.io/releases/redis-3.0.0.tar.gz
      tar -xvfz redis-3.0.0.tar.gz
      cd redis-3.0.0/
  3.  아래의 패키지들을 yum을 이용해서 설치
    1.  yum install gem ruby ruby-devel ruby gems redis-stat rpm-build

설치 단계

  1. Redis Cluster용 설정파일 생성
    1.  기존의 설정파일인 ‘redis.conf’를 수정해서 사용해도 되나 우선 불필요한 설정들도 많고 Redis를 한 서버에서만 사용하게 되면 (클러스터 모드가 아닌) 다시 수정을 해야 하기 때문에 클러스터용 설정 파일을 새로 생성해서 사용하는게 좋습니다. (예를 들어 파일명은 ‘redis-cluster.conf’) 클러스터용 설정 파일의 예는 아래와 같습니다.
          port 6379
          cluster-enabled yes
          cluster-config-file nodes.conf
          cluster-node-timeout 5000
          append only yes
    2.  위의 설정파일을 이용해서 Redis Server 시작. 만약 클러스터 모드로 정상적으로 시작되었다면 서버 시작 후에 ‘Running in cluster mode’라는 글을 확인할 수 있습니다. 
      1. src/redis-server redis-cluster.conf
    3.  위의 두 사항을 클러스터에 포함될 다른 서버들에 반복해서 수행합니다. 
    4.  위의 과정을 거쳐 클러스터 모드로 시작된 Redis Server들을 아래의 명령어 실행을 통해 연결합니다. 참고로 이 과정은 하나의 서버에서만 수행하면 됩니다. 예를 들어 클러스터를 형성할 서버 A, B, C가 있다고 가정하면 A에서만 아래의 명령어를 실행하면 클러스터가 바로 형성되기 때문에 같은 작업을 B랑 C에서 반복적으로 할 필요가 없습니다. 
      1. src/redis-cli -p 6379 CLUSTER MEET 192.168.3.105 6379
      2. 참고로 위의 명령어는 서버 B의 IP가 192.168.3.105 이고 서버 A에서 클러스터를 형성한 경우의 예입니다.
    5.  ‘redis-trib.rb’라는 Redis 패키지에서 제공하는 유틸리티 프로그램을 이용해서 아래의 명령어를 실행해서 slot들을 할당합니다. 참고로  이 절차는 총 16384개의 슬롯을 오픈하고 오픈된 슬롯들을 클러스터 서버에 N 등분 해서 (여기서 N은 클러스터에 등록된 서버수) 할당하는 과정입니다. 
      1. src/redis-trib.rb create 192.168.2.105:6379 192.168.3.105:6379
    6. 만약 5번 실행 중 문제가 발생했다면 아래의 명령어들을 서버 A에서 실행해보세요. 
      1. for slot in {0..5400}; do redis-cli -h 192.168.2.105 -p 6379 CLUSTER ADDSLOTS $slot; done;
      2. for slot in {5400..10800}; do src/redis-cli -h 17.198.30.160 -p 6379 CLUSTER ADDSLOTS $slot; done;
      3. for slot in {10801..16383}; do src/redis-cli -h 17.198.30.157 -p 6379 CLUSTER ADDSLOTS $slot; done;
    7.  References
      1. http://redis.io/topics/cluster-tutorial
      2. https://www.digitalocean.com/community/tutorials/how-to-configure-a-redis-cluster-on-centos-7
      3. https://www.javacodegeeks.com/2015/09/redis-clustering.html
      4. https://ilyabylich.svbtle.com/redis-cluster-quick-overview

Monday, October 3, 2016

WebSocket이란?

WebSocket이란?

WebSocket이란 Transport protocol의 일종으로 쉽게 이야기하면 웹버전의 TCP 또는 Socket (소켓)이라고 이해하시면 됩니다.  WebSocket은 서버와 클라이언트 간에 socket connection을 유지해서 언제든 양방향 통신 또는 데이터 전송이 가능하도록 하는 기술이며 2008년에 HTML5에 포함이 되어서 여러 번의 토론을 통해 프로토콜이 제정되었고 2009년 구글 크롬을 시작으로 여러 웹브라우저에서 이 기술을 적용하여서 현재 Real-time web application 구현을 위해 널리 사용되어지고 있습니다. 참고로 Real-time web application이란 서버 쪽 또는 클라이언트 쪽 데이터가 실시간으로 업데이트 되는 웹 어플리케이션을 의미합니다.

왜 사용하는가요?

WebSocket을 사용하는 이유 또는 사용시 얻을 수 있는 장점에 대해서 이해를 하려면 WebSocket 이전에 사용되었던 기술과 어떤 차별성이 있는지를  이해하는게 중요합니다. 우선 웹어플리케이션에서 기존의 서버와 클라이언트 간의 통신은 대부분 HTTP를 통해 이루어 졌으며 HTTP는 Request/Response 기반의
Stateless protocol입니다. 무슨 말이냐 하면 서버와 클라이언트 간의 Socket connection 같은 영구적인 연결이 되어 있지 않고 클라이언트 쪽에서 (예를 들어 웹브라우저 쪽에서)  필요할 때 Request를 할 때만 서버가 Response를 하는 방식으로 통신이 진행되는 프로토콜이란 뜻입니다. (짧게 이야기하면 클라이언트 쪽에서만 대화를 시작할 수 있는 한 방향 통신입니다.) 그래서 어떤 문제가 생기냐면 서버 쪽 데이터가 업데이트 되더라도  클라이언트 쪽 (예를 들어 웹페이지)에는 화면을 Refresh 하지 않는 한 바뀐 데이터가 업데이트가 되지 않는 문제가 발생합니다. 그렇지만 이런 문제는 일반적은 웹 어플리케이션에서는 기존에 있던 임시 방편인 Long polling 이라던가 Ajax를 사용해도 어느 정도 해결이 가능하지만 데이터의 빠른 업데이트가 아주 중요한 요소 중에 하나인 어플리케이션 (예를 들어 주식 관련 사이트라던가 비디오 채팅 어플리케이션)에서는 실시간 업데이트가 아주 중요하기 때문에 (그리고 기존의 Long Polling 같은 기술은 서버에 많은 부담을 주는 부작용이 있기 때문에) WebSocket이 아주 유용하고 중요한 기술로 사용되고 있습니다.
또한 WebSocket은 Stateful protocol이기 때문에 클라이언트와 한 번 연결이 되면 계속 같은 라인을 사용해서 통신을 하기 때문에 HTTP 사용 시 필요없이 발생되는 HTTP와 TCP 연결 트래픽을 피할 수 있습니다.  마지막으로 WebSocket은 HTTP와 같은 포트 (80)을 사용하기 때문에 (Secure한 채널 같은 경우에는 HTTPS와 같은 443을 이용) 기업용 어플리케이션에 적용할 때 방화벽을 재설정하지 않아도 되는 장점도 있습니다. (대부분의 기업 방화벽은 외부에서의 접속은 HTTP나 HTTPS만을 기본으로
허용하고 있으며 만약 이외의 포트를 허용해야 할 경우에는 방화벽의 설정을 수정해야 하는데 큰 회사일 수록 방화벽 설정 수정 절차가 복잡하기 때문에 HTTP와 같은 포트를 사용한다는 점이 꽤 큰 장점이 될 수도 있습니다.)

작동 원리 및 그 외의 정보

우선 서버와 클라이언트 간의 WebSocket 연결은 HTTP 프로토콜을 통해 이루어집니다. 만약 연결이 정상적으로 이루어진다면 서버와 클라이언트 간에 WebSocket 연결 (TCP/IP 기반으로 하는)이 이루어지고 일정 시간이 지나면 HTTP 연결은 자동으로 끊어집니다.
기본적으로 WebSocket API는 아주 간단한 기능들만을 제공하기 때문에 대부분의 경우 SockJS나 Socket.IO 같은 오픈 소스 라이브러리를 많이 사용하고 있으며 메세지 포멧 또한 STOMP 같은 프로토콜을 같이 이용합니다. 마지막으로 스프링 프레임워크도 WebSocket을 간단한 메세지 브로커랑 SockJS 그리고 STOMP와 같이 지원하고 있습니다.

WebSocket 사용의 어려운 점

WebSocket은 사용시 위에 서술한 것과 같은 장점들을 주지만 그에 못지 않는 비용을 지불해야 합니다. 아래는 WebSocket 사용 시 발생할 수 있는 어려운 점 또는 문제점들입니다.
1. 프로그램 구현에 보다 많은 복잡성 초래: WebSocket은 HTTP와 달리 Stateful protocol이기 때문에 서버와 클라이언트 간의 연결을 항상 유지해야 하며 만약 바정상적으로 연결이 끊어졌을 때 적절하게 대응해야 합니다. 이는 기존의 HTTP 사용 시와 비교했을 때 코딩의 복잡성을 가중시키는 요인이 될 수 있습니다.
2. 서버와 클라이언트 간의 Socket 연결을 유지한다는 것 자체가 비용이 드는 일입니다. 특히나 트래픽양이 많은 서버 같은 경우에는 CPU에 큰 부담이 될 수 있습니다.
3. 오래된 버전의 웹 브라우저에서는 지원하지 않습니다. (물론 SockJS 라이브러리 같은 경우에는 Fallback option을 제공하고 있습니다.) 참고로 인터넷 익스플로어 같은 경우에는 10 버전부터 지원합니다.
4. 이건 제 개인적인 경험인데 서버와 클라이언트 간의 연결이 끊어졌을 때 생성되는 에러 메세지가 구체적이지 않아서 (예를 들어 여러가지 다른 이유로 연결이 끊어졌는데 에러 메세지가 같은 경우) 디버깅을 하는데 어려움이 많았습니다.

아무리 좋은 기술이라 할지라도 모든 경우에 유용할 수는 없는 법이기 때문에 프로그램에 꼭 필요한 기술인지 잘 체크하고 수용 여부를 결정하는 것이 바람직합니다.

대표적인 사용예

1. 페이스북 같은 SNS 어플리케이션
2. LOL 같은 멀티플레이어 게임들
3. 구글 Doc 같이 여러 명이 동시 접속해서 수정할 수 있는 Tool
4. 클릭 동향 분석 데이터 어플 (특정 시간동안 어느 사이트에 주로 접속했는지 등의 정보를 파악하는 어플)
5. 증권 거래 정보 사이트 및 어플
6. 스포츠 업데이트 정보 사이트 및 어플
7. 화상 채팅 어플
8. 위치 기반 어플
9. 온라인 교육 사이트 및 어플

References

https://www.websocket.org/aboutwebsocket.html
http://www.javaworld.com/article/2071232/java-app-dev/9-killer-uses-for-websockets.html
https://en.wikipedia.org/wiki/WebSocket
https://samsaffron.com/archive/2015/12/29/websockets-caution-required
https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API



Sunday, August 7, 2016

ACID란?




데이터베이스 영역에서 ACID란 Atomicity(원자성), Consistency(일관성), Isolation(고립성) 그리고 Durabiliy(지속성)의 약어로 데이터베이스 트랜젝션의 가장 중요한 특성들을 나타내는 말로 데이터베이스 시스템에서 기본적으로 제공해야할 가장 중요한 특성들입니다. 각각의 특성들에 대한 설명은 아래와 같습니다.
  • Atomicity (원자성): 하나의 데이터베이스 트랜젝션에 여러 개의 데이터를 변환 (수정/삭제/입력 등과 같은)하는 도중에 문제가 발생했을 때 문제가 발생한 시점과 상관없이 그 트랜젝션에 포함된 모든 데이터의 변환이 이루어지지 않도록 보장하는 것이 원자성의 중요한 특징입니다. 쉽게 이야기하면 데이터를 변환할 때 문제가 발생하면 트랜젝션에 포함된 내용의 어떠한 데이터의 변환이 이루어지지 않으며 많약 아무 문제가 없을 때는 트랜젝션에 포함된 내용의 모든 데이터의 변환이 이루어 지는 것을 의미합니다. (All or nothing)
  • Consistency (일관성): 일관성은 어떠한 트랜젝션 전후에도 데이터베이스가 valid 상태를 유지함을 보장하는 특성으로 쉽게 이야기해서 트랜젝션 동안 데이트베이스에서 지정된 Rule에 부합된 데이터들만 데이터베이스에 유지가 되어서 트렌젝션이 끝난 후에도 데이터베이스가 사용가능한 상태를 유지할 수 있도록 보장하는 특성입니다.
  • Isolation (독립성): 독립성이란 만약 한 데이터베이스 시스템에 여러 개의 트랜젝션이 발생했을 때 각각의 트랜젝션이 서로 독립적으로 (또는 서로 영향을 끼치지 않게) 데이터를 변환할 수 있게 보장하는 특성을 이야기합니다. 만약 독립성이 지원 않는 데이터베이스에서 동시에 두 개의 트랜잭션에서 같은 데이터를 변환한다면 그 값이 어떻게 변환될 지 (어떤 트랜젝션이 먼저 실행되는지에 따라) 예측 불가능하기 때문에 많은 문제들을 발생 시킬 수 있습니다.
  • Durability (지속성): 한 번 데이터베이스에 저장된 데이터는 그 데이터의 변환에 대한 다른 트랜젝션 요청이 없을 때까지 항상 같은 값을 유지함을 보장하는 특성을 데이터베이스에서의 지속성이라고하며 갑작스럽게 전원이 꺼졌을 때나 시스템 오류 같은 문제가 발생했을 때 자동으로 데이터베이스에 저장된 데이터의 복구도 이 특성에 포함됩니다.

References
  • https://en.wikipedia.org/wiki/ACID
  • http://terms.naver.com/entry.nhn?docId=860356&cid=42346&categoryId=42346
  • http://www.service-architecture.com/articles/database/acid_properties.html
  • http://searchsqlserver.techtarget.com/definition/ACID
  • https://vladmihalcea.com/2014/01/05/a-beginners-guide-to-acid-and-database-transactions/

Monday, July 4, 2016

Framework vs Library: 프레임워크와 라이브러리의 차이

많은 사람들이 프레임워크와 라이브러리의 차이를 단순히 사이즈의 차이 (프레임워크가 라이브러리에 비해 훨씬 크다 또는 여러 개의 라이브러리의 묶음이 프레임워크이다)라고 생각하는 경향이 있는데 이는 사실이 아닙니다. (물론 대부분의 경우 프레임워크가 라이브러리보다 사이즈가 더 크고 프레임워크가 여러 개의 라이브러리를 포함하고 있지만 그렇다고 라이브러리의 묶음이 프레임워크다라고 단순히 규정하기는 힘듭니다. 자세한 이유는 아래에 서술하였습니다.) 그 대신 기능적으로 무엇을 제공하는지와 사용할 때 어떤 방식으로 어떻게 사용할 지의 차이가 프레임워크와 라이브러리를 구별할 수 있는 더 중요한 요소가 아닐까 생각합니다.

우선 라이브러리는 보통 큰 개념으로 볼 때 하나의 기능을 제공하며 그 기능을 구현하기 위한 (또는 그 기능과 관련된) 부수적인 여러 개의 작은 기능들을 제공합니다. 예를 들어 GSON 라이브러리 (구글에서 제공하는 JSON 데이터 변환 라이브러리) 같은 경우에 큰 개념적으로 보면 JSON 형식의 데이터를 다른 형식으로 변환하는 기능을 제공하고 있으며 세부적인 기능들로는 JSON 형식의 데이터를 Java Object  형식으로 변환하는 기능을 제공하고 반대로 Java Object에 저장된 데이터를 JSON 형식의 데이터로 변환해주는 기능을 제공하고 있습니다.

반면에 프레임워크는 하나의 특정 기능을 제공하기 보다는 어플리케이션을 만드는데 있어서 뼈대가 될 수 있는 기능들을 제공하고 있습니다. 예를 들어 Spring Framework를 이용해서 MVC 모델의 웹어플리케이션을 만든다고 했을 때 스프링은 웹어플리케이션을 만들기 위한 기본적인 기능들만을 제공하며 (UI와 서버 쪽의 연동이나 데이터의 교환 또는 공유) 웹어플리케이션 구동을 위한 추가적인 기능들 (예를 들어 Front-end 쪽 디자인 관련 기능들이라던지 또는 서버의 효율성을 증진시킬 수 있는 기능들) 에 대한 지원을 기본적으로 하고 있지 않습니다.

위의 차이점 때문에 라이브러리와 프레임워크는 사용 방식 (또는 어플리케이션과의 연동방식)에서도 차이가 발생합니다. 우선 라이브러리는 보통 어플리케이션에 포함이 되어서 사용되고 있으며 개발자의 입장에서 봤을 때 라이브러리에서 제공하는 API 호출을 어플리케이션에서 어떻게 해서 사용할 지를 고민하게 됩니다. 그 반면에 프레임워크는 어플리케이션의 뼈대가 되기 때문에 어플리케이션의 메인 코드가 프레임워크의 여러 부분에 접합되어서 사용되어지며 (프레임워크가 사용자가 작성한 코드를 호출합니다.) 개발자의 입장에서 봤을 때 본인의 코드가 프레임워크와 얼마나 연동이 잘 되어서 사용되어지는 지 (또는 잘못 사용되어서 문제를 일으키지 않는지)를 고민하게 됩니다.

마지막으로 만약 로봇을 만든다고 가정을 했을 때 프레임워크를 사용하게 되면 로봇에 대한 기본적인 골격을 프레임워크가 제공하는 것이며 (아주 초보적인 걸음 정도를 할 수 있는) 개발자는 거기에 사람처럼 보일 수 있게 실리콘 피부를 입힌다거나 달리기를 잘 할 수 있는 로봇, 또는 시력과 청력이 아주 좋은 로봇을 만드는 일 (관련 기능들을 로봇에 추가해서)을 한다고 생각하시면 됩니다. 반면에 라이브러리를 사용해서 로봇을 만든다면 기본적인 골격은 직접 만들지만 특정 기능 (시력을 높이는 기능 또는 빨리 뛰게 할 수 있는 기능) 또는 특정 부위 (손, 발) 등은 라이브러리를 이용해서 구현한다고 생각하시면 됩니다.

Sunday, June 12, 2016

[잡담] 실리콘밸리(Silicon Valley)에서의 Software Engineer 포지션 구직 관련 팁 및 정보


미국에서 소프트웨어 엔지니어로 일하기 가장 좋은 지역이 세 곳이 있는데 (씨애틀 지역, 샌프란시스코/실리콘 벨리 지역, 텍사스 오스틴 지역) 그 중에서도 가장 평균 연봉도 높고 구글과 애플 그리고 페이스북 같은 거대 IT 대기업의 본사가 있을 뿐만 아니라 많은 스타트업 회사들이 포진해 있어서 기회가 많은 샌프란시스코/실리콘 밸리가 지역이 가장 엔지니어한테는 일하기 좋은 지역이 아닐까 생각합니다. 이 글은 필자가 실리콘밸리 지역에서 경험한 내용과 주변 사람들의 이야기를 통해 배운 구직 관련 내용입니다.

1. 접근성
본인이 정말 실리콘밸리에 있는 회사에 취직을 하고 싶다면 우선은 실리콘밸리 쪽으로 오는 것이 가장 좋다고 생각합니다. 사실 이 부분은 꼭 실리콘밸리 지역에 국한된 것은 아니지만 많은 분들이 이 접근성의 중요성에 대해 간과하고 있는게 사실입니다. 학교를 실리콘 밸리 쪽에 있는 학교로 오든 아니면 본인이 원하는 회사는 아니지만 실리콘 밸리 쪽에 있는 회사로 취직을 한후 이직을 준비하든 우선 이 곳에 와서 생활을 하고 인맥을 넓히고 실력을 쌓으면서 인터뷰 준비를 성실히 잘 한다면 기회는 꼭 찾아올 것입니다. 특히 인맥이 중요한 이유는 다른 사람들의 인터뷰 경험을 들을 수 있으며 때에 따라서는 그 회사의 오픈 포지션에 대한 리퍼 (추천)를 받을 수도 있어서 인터뷰 성공 확률을 높일 수 있습니다. 참고로 미국 내에 있는 대부분의 회사들은 추천만으로 고용이 되는 경우는 극히 드물지만 추천을 받게 되면 서류 심사 절차는 생략이 되는 경우가 많기 때문에 인터뷰를 함에 있어서 큰 도움이 됩니다. (특히 구글이나 페이스북 또는 애플 같은 큰 회사는 온라인으로 레즈메를 접수해도 너무나 많은 지원자들 때문에 서류 심사를 통과하는 것도 힘이 드는 경우가 많습니다.) 마지막으로 실리콘 밸리 지역에서는 개발자들을 위한 여러 형태의 컨퍼런스나 Hackathon 같은 이벤트가 매년 꾸준히 열리고 있어서 기술 동향이나 인맥 형성에도 큰 도움이 되고 있습니다.

2. 실력
물론 당연한 이야기지만 실리콘 밸리에 있는 좋은 회사에 취직하기 위해서는 경력과 레벨에 따른 실력이 있어야 합니다. 작은 회사일 경우를 제외하고는 다른 사람의 추천 만으로 취직을 하기가 쉽지 않고 실력이 없다면 대부분의 Technical 인터뷰 과정에서 떨어지기 때문입니다. 참고로 이제 막 졸업한 학생일 경우에는 몇 가지 특별한 도메인의 스페셜리스트가 되기 보다는 다양한 분야에 대한 경험이 있는 것이 더 좋을 수 있습니다. 그 이유는 첫째, 학교에서 경험할 수 있는 프로젝트에는 한계가 있고, 둘째, 그 경험들이 실제 인더스트리에서 사용되는 경우도 거의 없으며 (여러가지 환경적인 요인들 때문에) 마지막으로 그렇게 되면 결국 자신이 구할 수 있는 취직 기회의 범위를 축소하는 결과를 낳기 때문입니다. 대략적인 인터뷰 과정과 준비해야할 항목에 관해서는 따로 글을 작성해서 올리도록 하겠습니다.

3. 학력
몇몇 특정 기업의 특정 포지션에 한해서는 학력을 중요시하는 경우가 있지만 이곳에 있는 대부분의 회사들은 특정 학교 졸업을 요구하거나 인터뷰 시 중요하게 보고 있지 않습니다. 단 학사 졸업은 보통 기본으로 요구하고 있으며 (CS나 CE 쪽) 석사를 선호하는 편입니다. 어떤 학교를 나오든 인터뷰를 보는 절차는 같기 때문에 인터뷰 준비만 잘 하면 학력은 크게 문제가 되지 않는 것 같습니다.

4. 언어 능력 (영어)
미국 내에 있는 회사에서 일을 하려면 영어 구사 능력은 필수이지만 그래도 다른 직종에 비해 (회계사나 세일즈맨 같은) 엔지니어들한테 요구되는 언어 능력은 조금 덜 한 편이며 특히나 실리콘 밸리 지역은 워낙에 외국인 엔지니어들이 많기 때문에 (특히 인도인과 중국인) 미국 내의 다른 지역에 비해 언어 능력 부족에 조금 관대한 편입니다. 기본적인 회화 능력과 자기 생각에 대한 정확한 서술을 할 수 있고 상대방의 이야기를 이해하고 토론 가능한 정도면 일을 하는데 있어서 큰 무리가 없습니다. (물론 이전에 미국에서 생활한 경험이 없거나 영어권 국가에서 연수 및 유학을 하지 않은 경우에는 이 정도까지 오는데도 쉽지는 않겠지만요) 그렇지만 위의 내용은 말단 엔지니어일 때의 경우이고 좀더 높은 포지션의 인터뷰 때는 (매니저나 테크니컬 리드 같은) 기술적인 실력도 중요하지만 언어 능력이 더 많이 중요하게 작용하기 때문에 이 부분에 있어서는 좀더 많은 개선이 있어야 합니다.

5. 대기업 vs 스타트업 회사
일반적으로 스타트업 회사는 경험이 많이 있거나 여러가지를 다양하게 할 줄 아는 엔지니어를 선호하며 (지금 당장 쓸수 있는 엔지니어) 대기업은 경험이 부족해도 잠재력이 있거나 기초가 튼튼한 엔지니어들을 고용하는 경우가 많이 있습니다. 입사 후에 하는 일들도 대기업은 특정 분야에 대해서만 일을 하게 되지만 스타트업 같은 경우에는 여러 가지 다양한 일을 동시에 진행하는 경우들이 대부분입니다. 참고로 이야기하자면 스타트업의 업무 환경이 대기업보다 더 좋은 곳이 많으며 평균 이상의 스타트업 같은 경우 (투자금 상황이 괜찮은 경우) 직원 대우 (연봉 + RSU)도 대기업과 거의 비슷한데다가 향후 주식상장을 하거나 대기업에 합병되었을 때 스톡옵션이 대박나는 경우들이 있기 때문에 오히려 대기업보다 더 들어가기 힘든 곳들이 꽤 있습니다. (Uber나 Airbnb 같은)

6. 회사별 몇 가지 정보
 - Google: 구글은 웬만한 지원자들한테 인터뷰 기회를 주는 편이며(학벌이나 경력 상관없이) 인터뷰한 사람들의 DB를 구축해서 관리하고 있은 것으로 알고 있습니다. 인터뷰 난이도는 높은 편이지만 절차가 상당히 체계적이고 공정하게 진행되는 것으로 알려져 있습니다. 구글 인터뷰 과정의 특징은 Hiring Manager의 권한이 제한되어 있어서 소수의 인맥을 통한 편법적인 채용이 힘들고 모든 인터뷰 절차가 끝난 후 인터뷰를 진행한 사람들이 모여 인터뷰 결과를 공유하는데 이 때 다수로 부터 높은 점수를 받아야 합격이 되는 것으로 알고 있습니다. 만약 인터뷰에 패스를 못 하면 1년 안에 다시 지원을 못하며 (지원을 하더라도 새로운 인터뷰 진행이 안됩니다) 온사이트 같은 경우에는 최대 3번까지 가능합니다. (만약 온사이트까지 가서 떨어진게 3번이 되면 삼진 아웃제 같이 차후에 지원을 하더라도 인터뷰 진행 자체가 아예 안되는 것으로 알고 있습니다.)
 - Apple: 애플은 같은 부서에서 나온 포지션만 아니면 여러 부서의 여러 포지션에 대한 동시 인터뷰 진행이 가능합니다. 인터뷰 과정 중 특이한 점은 알고리즘 쪽 관련 질문 외에도 그 부서에서 사용하는 기술 관련 질문들의 비중도 꽤 높은 편이며 구글보다는 Hiring Manager의 권한이 큰 편입니다.
 - Amazon: 애플과 비슷하게 여러 오픈 포지션에 대해 동시에 지원이 가능하며 아마존 만의 특징은 우선 Scalability 관련 질문을 많이 하는 편이며 인터뷰 시작 때 Behavioral Question을 꼭 하나 이상 하는 경향이 있습니다.
 - 스타트업 회사들: 위에 언급한 것처럼 일반적으로 경험이 많이 엔지니어를 뽑으려 하는 경향이 있으며 인터뷰 과정이 나쁘지 않더라도 자신보다 나은 경쟁자가 있을 시에는 제한된 버젯 때문에 채용이 안 되는 경우도 더러 있습니다. (돈에 여유가 있는 대기업 같은 경우에는 인터뷰 과정이 괜찮은 후보자가 여럿 있을 경우 없는 포지션을 만들어서라도 둘다 고용하는 경우가 있는데 스타트업 회사 같은 경우에는 아마래도 돈에 제한이 있다보니 꼭 정해진 인원만 뽑으려는 경향이 있습니다. 물론 인터뷰를 정말 잘 했을 경우에는 다른 이야기지만요.) 또한 인터뷰 난이도도 일반 대기업들보다 더 높은 경우들도 많습니다.


Wednesday, September 30, 2015

Cache vs Cookies: 웹브라우저 캐시와 쿠키의 차이 점

Cache와 Cookies는 특정 웹사이트의 접속 속도 개선을 위해 클라이언트의 컴퓨터에 임시로 저장되어 있는 데이터란 개념은 같지만 아래와 같은 다른 점들이 있습니다.

Cookies란?
Cookies란 넷스케이프의 Netscape Navigator란 자사의 웹브라이저를 통해 소개된 기술로 특정 웹페이지에 대한 유저의 행동 패턴을 주로 저장하는 작은 사이즈의 텍스트 파일입니다. 주로 저장되는 정보로는 특정 웹사이트나 웹페이지에 얼마나 자주 또는 몇 번 방문했는지 그리고 특정 배너를 클릭을 했는지 했으면 얼마나 자주 했는지 검색 시 어떤 키워드를 사용했는지 등의 정보들입니다. 또한 웹서버 쪽에서 유저를 식별하기 위한 Session Tracking의 방법으로 사용되기도 합니다. Cookies 정보는 오직 그 Cookies를 작성한 웹서버만이 Access 가능하며 대부분의 Cookies는 Expiration Date (사용기한)이 정해져 있어서 기한이 만료되면 자동으로 삭제됩니다.

Cache란?

Cache란 웹페이지 Resource 파일들 (오디오, 비디오, 이미지 등)의 임시 저장소로 다음에 같은 웹페이지 (또는 웹사이트) 접속 시 페이지 로딩 속도를 개선해주는 역할을 합니다.

차이점
1. 유저의 컴퓨터에 임시로 저장되어 있는 점은 같지만 사용 목적은 위에 이야기한 것 처럼 다릅니다.
2. Cache는 오직 웹페이지 로딩 속도 개선을 위해서만 사용되지만 Cookies는 유저 관련된 여러가지 다른 목적으로 사용 가능합니다.
3. Cache는 오디오, 비디오, 이미지 등의 Resource 파일등을 주로 저장하는 반면에 Cookies는 User preference (유저가 웹사이트 접속 시 하는 행동 패턴 또는 관련 정보) 위주의 정보를 저장합니다.
4. 보통 Cache는 유저가 삭제할 때까지 유저의 컴퓨터에 저장되지만 Cookies는 서버 쪽에서 설정한 기간이 지나면 자동으로 삭제됩니다.
5. Cookies는 웹서버의 Access가  가능한 반면에 Cache는 Access가 불가능합니다. (사실 Access를 해야할 이유도 없지만요)

References
1. http://www.differencebetween.com/difference-between-cache-and-vs-cookies/
2. http://www.techcuriosity.com/resources/difference_between/difference_between_cache_and_cookies.php
3. http://www.guidingtech.com/8925/what-are-browser-cache-cookies-does-clearing-them-help/
4. https://answers.yahoo.com/question/index?qid=20081201160300AAa1kh8
5. http://www.ehow.com/info_8304895_difference-between-cookie-cache.html


Friday, May 1, 2015

Redis(레디스) 3.0 설치 (CentOS 6.5 64-bit)


Redis 설치
  1. Redis 설치 전에 필요한 패키지
    • $ yum install tcl*
  2. 가장 최신 버전의 Redis 다운로드 및 컴파일
    • $ wget http://download.redis.io/redis-stable.tar.gz
    • $ tar xvzf redis-stable.tar.gz
    • $ cd redis-stable
    • $ make
    • $ make install
  3.  Redis 서버 시작
    1. 기본 설정을 이용한 서버 시작: 간단한 테스트나 개발 환경에서만 사용을 추천하며 프로덕션 레벨에서의 사용은 추천하지 않습니다.
      • $ redis-server
    2. 설정파일과 함께 서버 시작: 설정 파일은 보통 Redis를 설치한 폴더에 포함이 되어 있습니다. 예를 들어 '/opt' 폴더에 설치했을 때는 '/opt/redis-stable/redis-conf'와 같은 형태로 포함해야 합니다.
      • $ redis-server ../redis-stable/redis-conf
  4. Redis 패키지와 함께 제공되는 클라이언트 프로그램을 이용한 간단한 테스트
    • $ src/redis-cli
    • 127.0.0.1:6379>ping
    • PONG
    • 127.0.0.1:6379> set foo bar
    • OK
    • 127.0.0.1:6379> get foo
    • "bar"
  5. Sources:
    1. http://redis.io/download
    2. http://briansnelson.com/How_to_install_Redis_on_a_Centos_6.4_Server
    3. http://blog.andolasoft.com/2013/07/how-to-install-and-configure-redis-server-on-centosfedora-server.html

Friday, March 27, 2015

AngularJS: $digest vs $apply vs $timeout vs $evalAsync 차이점 및 설명


 AngularJS (이하 Angular)Two-way binding이라는 편리한 기능을 제공하지만 이 기능을 사용할 때 몇 가지 어려운 점이 있습니다. 그 중에 하나가 Angular Context 외에서 들어오는 데이터를 모델에 업데이트를 할 때 (여기서 모델이란 $scope로 정의된 variable들을 이야기합니다. : $scope.data) 개발자가 인위적으로 업데이트를 해야하며 이 때 사용하는 것이 $digest, $apply, $timeout 또는 $evalAsync 입니다. 참고로 Angular Context (또는 Angular  Scope )Angular를 사용하지 않고 제작하는 모듈을 가리키며 가장 간단한 예로 서버를 들 수 있습니다. 서버에서 어떤 이벤트가 발생해서 Angular로 제작된 클라이언트 모듈 쪽으로 데이터가 들어오고 그 들어온 데이터를 UI에 반영하기 위해서 $scope.data에 업데이트를 해야 하는데 위에 언급한 함수들을 사용하지 않으면 클라이언트 모듈 쪽에는 데이터가 업데이트 되었지만 UI쪽인 HTML 쪽에는 (보통 {{data}} 형식으로 포함된) 업데이트가 되지 않아서 UI에 반영이 되지 않은채로 남아있습니다.

Two-way binding의 동작 원리
Two-way binding의 동작원리는 개발자가 $scope를 이용해서 variable을 생성하면 생성된 variable watcher가 생성되고 $apply()$digest()가 실행되었을 때 현재까지 생성된 모든 watcher들이 실행되어서 변화된 값을 업데이트합니다. 여기서 watcher란 할당된 variableold valuenew value를 비교하여 두 값이 다를 경우 old valuenew value로 업데이트해주는 모듈로 $scope.$watch 함수를 이용하여 이 작업을 합니다. UI쪽에서 발생하는 데이터값의 변화에 Two-way binding이 아무런 추가 작업 없이 정상 동작하는 이유는 AngularUI에서 발생하는 이벤트에 대해 $apply()를 자동으로 실행하기 때문입니다. 예를 들어 ng-click 같은 이벤트가 생성이 된다면 $apply()도 자동으로 실행이 됩니다.

$digest()
$digest()는 위의 동작원리에서 설명한 대로 현재까지 생성된 모든 $scope variable 들의 watcher를 실행하여 값이 변화된 variable의 값을 최신값으로 업데이트해주는 일을 합니다.
사용 예: $scope.digest();

$apply()
간단하게 설명하면 $apply() $rootScope.$digest()랑 같습니다. 하는 일은 $digest()와 같지만 다른 점은 커버하는 scope가 다르다는 점입니다. 다시 말해서 $digest()는 해당 scopevariable의 값들만 업데이트하지만 $apply()는 무조건 rootScoperootScope 밑에 있는 모든 child scope들의 variable들 값을 모두 업데이트하기 때문에 자주 사용하면 제품 전체의 성능/효율성을 저하 시킬 수 있습니다. 기본적으로 Angular$apply()의 사용을 추천하고 있지만 제 개인적인 의견으로는 만약 어떤 scopevariable이 업데이트 되어야 하는지 안다면 $digest()의 사용을 추천합니다.
사용 예: $scope.$apply(); 또는 $scope.$apply(function() { ….. } );

$timeout()
$timeout()은 일반적인 자바스크립의 APIsetTimeout()Angular 버전으로 $timeout()함수 안에서 바뀐 variable 값을 업데이트하기 위해 $apply()를 기본적으로 포함하고 있습니다. $timeout()은 보통 setTimeout()과 마찬가지로 얼마동안의 Delay 이후에 해당 코드를 실행하기 위해 사용되어지고 있는데 이 용도 이외에 ‘$digest already in progress’ 에러 발생에 대한 임시 해결책으로도 사용되어지고 있습니다. (DirectiveController 안에서 여러 번의 $apply()를 포함한 개발을 해본 개발자라면 최소한 한 번 이상은 저 에러 메세지를 본 경험이 있을겁니다.) ‘$digest already in progress’에러의 발생원인은 Angular는 기본적으로 한 번에 두 개의 $digest() 동시 실행을 금지하고 있어서 이미 $digest()가 실행 중일 때 또 다른 $digest()가 실행이 된다면 이 에러 메세지가 출력되고 나중에 실행된 $digest()는 실행이 되지 않습니다. 그럼 어떻게 $timeout()의 사용이 이 문제의 해결책이 될 수 있는건가요? 그 이유는 $timeout()$apply() 실행 타이밍 때문인데 $timeout()은 이미 기존에 실행되고 있는 $digest()가 있다면 그 실행이 끝날 때까지 기다렸다가 $timeout() 내부에 포함된 $scope.$apply()을 실행하는 특징이 있고 이 때문에 위의 에러에 대한 임시 해결책으로 사용되어 지고 있습니다.
사용 예: $timeout(function() {…….}, 0);

$evalAsync()
$evalAsync()‘$digest already in progress’에러에 대한 Angular팀의 근본적인 해결책으로 이해하시면 편합니다. (위에도 언급했듯이 $timeout()의 기본용도는 이 문제의 해결이 아닌 얼마간의 Delay이후에 실행이기 때문에 근본적인 해결책이 될 수는 없습니다. 또한 약간의 화면 깜빡이는 문제를 발생시킬 수도 있습니다.) $evalAsync()도 기본적으로 $apply() 함수를 포함하고 있으며 현재 진행중인 $digest()가 있을 경우에 이 $digest()의 실행이 끝나기 전에 $evalAsync()에 포함된 variable의 바뀐 데이터도 같이 업데이트할 수 있는 기능을 제공합니다. $evalAsync()AngularJS 1.2 버전부터 제공되어지고 있습니다.
사용 예: $scope.$evalAsync(function() {…….});

추가사항:
AngularJS 1.3 버전부터 $applyAsync() 함수가 추가 되었다고 합니다.  기본적인 기능은 $evalAsync()와 비슷하지만 효율성 면에서 아주 미세한 차이가 있다고 하는 것 같은데 필자는 사용 경험이 없어서 자세한 사항은 잘 모르겠습니다.

References

Wednesday, February 11, 2015

[NEWS] Node.js Foundation 출범


어제 있었던 Node Summit 2015 (2월 10일)의 마지막 세션이었던 'The future of Node.js'에서 Joyent의 CEO인 Scott Hammond가 Node.js Foundation의 출범을 선언했습니다. 그동안 Node.js 프로젝트는 Joyent가 메인으로 지원했었는데 그래서 폐쇄성과 새 릴리즈의 계속된 지연 등 여러가지 문제가 많이 있었습니다. (그래서 결국 초창기 핵심 개발자들의 주도하에 Node.js의 포크버전인 io.js가 작년에 나오게 되었습니다.)

아무튼 Joyent는 이런 여러가지 문제를 해결하고자 formal open governance 형태인 Node.js Foundation을 출범하기로 결정하였고 이 Foundation 멤버로는 Joyent를 포함해 IBM, Microsoft, PayPay, Fidelity, SAP 그리고 The Linux Foundation로 구성되었습니다. 또한 이 세션에서 앞으로 Node.js는 OpenStack과 비슷하게 두 가지 버전으로 출시할 예정이며 하나는 지금까지의 Node.js처럼 무료로 사용할 수 있는 오픈소스 버전으로 출시되며 이 버전을 Node.js Foundation가 지원할 예정이고 다른 버전은 몇 가지 기업용 기능이 추가된 유료 버전으로 Joyent가 이 버전을 지원/관리할 예정입니다. (즉 Rackspace가 OpenStack을 지원하는 방식처럼 오픈 소스도 지원하고 유료 버전을 따로 제작해서 지원하겠다는 의미입니다. 실질적으로 세션에서 이 내용을 이야기하면서 Rackspace가 오픈스택을 지원하는 모델을 따르겠다고 이야기하였습니다.)

출처: https://www.joyent.com/about/press/joyent-moves-to-establish-nodejs-foundation

Friday, January 9, 2015

앵귤러JS (AngularJS) 란?


앵귤러JS란
앵귤러JS (짧게 앵귤러라고도 합니다)는 MIT License로 무료로 배포되고 구글이 지원하고 있는 오픈 소스 웹 어플리케이션 프레임워크입니다. 앵귤러JS는 자바스크립트로 제작되었으며 기본적으로 MVC (Model-View-Controller) 모델 지원과 같은 다른 웹 어플리케이션 프레임워크에서도 지원하는 기능을 제공할 뿐만 아니라 Two-way data binding이나 directive 같은 새로운 개념의 기술도 지원하여 웹 개발자들이 해야할 많은 일들의 단축 및 좀더 파워풀하고 테스트가 용이한 웹 어플리케이션 제작에 도움이 되는 기능을 제공하고 있습니다. 아직 나온지 5년 정도 밖에 안된 프레임워크지만 구글의 전폭적인 지원 속에 다른 경쟁 프레임워크들이 비해 가장 빨리 커뮤니티가 성장하고 있는 프레임워크가 아닐까 생각합니다.

왜 사용하나요?
  • 체계적인 코드작성 지원: 개인적인 경험으로 JavaScript는 다른 프로그래밍 언어에 비해서 체계적으로 프로그래밍하기 어려운 언어인 것 같습니다. 그래서 프로젝트 사이즈가 커지면 금방 이해하기 힘들어지고 Debug가 어려워지는 Spaghetti Code가 되기 쉽습니다. 그렇지만 앵귤러같은 프레임워크를 사용하게 되면 이런 부분을 일정 부분 해소해줍니다. 
  • 앵귤러는 다른 프레임워크에 비교했을 때 아래와 같은 장점들을 가지고 있습니다. 
    • 구글의 지원 속에 개발자 커뮤니티가 가장 빠르게 성장하고 있고 앞으로도 성장 가능성이 큽니다. 
    • Two Way Data-Binding: 앵귤러가 제공하는 여러가지 기능 중 가장 유용한 기능이 이 Two Way Data-Binding 일 것입니다. 이 기능에 대해서 간단하게 이야기하면 Model과 View에서 사용되고 있는 데이터를 연결해줘서 어느 한쪽에서 이 데이터 값이 변화하면 다른 쪽에도 바로 업데이트가 되도록 해주는 기능입니다. 보통 이 기능 구현을 위한 코드가 전체 프로젝트의 80% 정도를 차지한다고 하는데 앵귤러는 기본적으로 이 기능을 제공하기 때문에 많은 코드의 반복을 피할 수 있습니다.
    • Dependency Injection 기능을 기본적으로 지원하기 때문에 컴포넌트들 간의 서비스 사용 및 Dependency 관리가 용이하며 각각의 컴포넌트들이 Decoupling (코드상에서 밀접하게 연관되어 있지 않음)되어 있기 때문에 테스트 하기가 쉽습니다. Dependency Injection에 대한 좀더 자세한 사항은 저의 다른 블로그 글인 'Dependency Injection이란'을 참고하시기 바랍니다. 
    • Directives: 앵귤러는 Directives를 제공함으로써 개발자가 자신의 용도에 맞게 HTML tag를 제작하여 사용할 수 있게 하였으며 DOM attributes도 수정 가능하게 하였습니다.


출처:
위키피디아: http://en.wikipedia.org/wiki/AngularJS
사이트포인트: http://www.sitepoint.com/10-reasons-use-angularjs/

Saturday, November 29, 2014

스프링 프레임워크 (Spring Framework)란?


스프링 프레임워크란?
스프링 프레임워크는 Pivotal Software에서 아파치 라이센스(무료 라이센스) 형태로 제공하는 오픈 소스 프로젝트로 자바 어플리케이션 (Standalone 과 웹 어플리케이션 모두 포함)개발에 필요한 여러 가지 서비스를 제공하는 프레임워크입니다. 현재 미국에서 자바로 어플리케이션을 개발하는 많은 회사들이 스프링 프레임워크를 사용 중이며 대한민국 공공기관의 웹 서비스 개발 시 사용을 권장하고 있는 전자정부 표준프레임워크의 기반 기술로도 쓰이고 있습니다.

왜 사용하나요?
1. 오픈소스 프로젝트: 다른 블로그에서도 여러 번 강조했지만 많은 회사들이 오픈 소스를 자사의 개발에 포함하는 이유는 라이센스 비용이 따로 들지 않기 때문입니다.
2. 다양한 기능 지원: 프로그램을 개발할 때 프레임워크를 사용하는 가장 큰 이유 중에 하나는 불필요한 반복을 없애고 업무의 양을 최소화하기 때문이 아닐까 싶습니다. 스프링 프레임워크는 엔터프라이즈용 프로그램을 개발하는데 관련해서 대부분의 기능을 제공하고 있으며 이 프레임워크를 사용하면 개발자들은 자사의 제품에 특화된 비지니스 로직만 추가하면 되기 때문에 많은 시간 및 개발비의 절약을 할 수 있습니다. 또한 많은 부분을 간단한 XML 설정이나 어노테이션으로 대신 할 수 있기 때문에 실제 코딩하는 소스코드의 양을 획기적으로 줄일 수 있습니다. 
3. 다양한 방식 지원: 스프링 프레임워크는 한 가지 컴포넌트에 대한 지원도 다양한 방식으로 하고 있습니다. 예를 들어서 DB 연결 같은 경우에도 Hibernate과 같은 모듈과 연동해서 여러 종류의 JDBC를 약간의 설정만 하면 사용할 수 있게 지원하고 있습니다. 이 점은 하나의 소스코드로 다양한 DB를 사용할 수 있게 해주기 때문에 큰 장점이 됩니다.
4. Dependency Injection: 스프링은 기본적으로 Dependency Injection을 지원하기 때문에 모듈들이 타이트하게 연결되어 있지 않으며 그래서 테스트가 용이한 프로그램을 만들 수 있습니다. (특히 유닛 테스트)

5. ETC: 그 외에도 스프링은 메세징, MVC, 테스팅, AOP 등 다양한 서비스를 기본적으로 제공합니다.

사용시 어려운 점 또는 단점
1. 스프링은 지원하는 기술의 양이 방대하고 같은 기술도 여러 가지 다른 방식으로 지원하기 때문에 처음 접하는 엔지니어들에게는 사용하기 힘든 프레임워크입니다.
2. 스프링은 비교적 무거운 프레임워크이기 때문에 이 프레임워크의 추가 만으로 어플리케이션을 상당히 무겁게 만들 수 있습니다. 

참고로 구글이나 애플 같은 큰 소프트웨어팀을 보유하고 있는 회사 같은 경우에는 자사에서 자체 개발한 프레임워크를 사용하고 있으며 보통 스프링 프레임워크와 비슷하거나 더 많은 기능을 제공하고 있다고 합니다. 그렇지만 사용 방식이나 개념에는 큰 차이는 없다고 합니다. 

출처
1. 위키피디아: http://en.wikipedia.org/wiki/Spring_Framework
2. 스프링 프레임워크 메인 페이지: http://projects.spring.io/spring-framework/

Tuesday, November 11, 2014

Dependency Injection (의존성 주입)이란?

Dependency Injection이란?
Dependency Injection이란 객체 또는 구성 요소간의 종속관계를 소스코드로 설정하지 않고 외부의 설정파일을 통해서 주입하도록 하는 디자인 패턴으로 주로 알려져 있는데요 쉽게 이야기하면 한 객체 안에 다른 객체가 사용되면 두 객체 간에 종속관계가 생기는 것이고 다른 객체를 포함한 객체를 생성하려면 포함된 객체가 미리 생성이 되어 있거나 그렇지 않을 경우 자동으로 생성을 해줘야 하는데 이 부분을 따로 코딩하지 않고 외부의 설정 파일을 통해서 설정해둬서 Dependency Injection 기능을 제공하는 프레임워크 (예를 들어 Spring 같은)에서 자동으로 생성하게 하는 기술입니다.

왜 사용하나요?
Dependency Injection을 사용하는 가장 큰 이유는 아래와 같습니다.
1. Loosely coupled: Dependency Injection는 보통 서비스 또는 인터페이스 개념과 같이 사용이 되는데요 한 객체를 다른 객체에 포함할 때 클래스 형태로 포함시키는게 아니라 인터페이스 형식으로 포함을 시키기 때문에 외부 설정파일이나 스프링 프레임워크 같은 경우에는 어노테이션 값의 변화를 통해 다양한 서비스를 사용할 수 있습니다. 위의 설명한 내용에 대해서 아래에 예를 참조하세요.

예1 - 클래스 형태로 포함시키는 경우 (Java)
public class Foo {
    .....
}

public class Poo {
   private Foo foo  = new Foo();
}

예2 - 인터페이스 형태로 포함시키는 경우 (Java)
public Interface FooService {
   .....
}

public class FooServiceImpl implements FooService {
   .....
}

public class Poo {
  private FooService fooServ;
}

2. Testability: Dependency Injection을 사용하게 되면 위에 설명한 것처럼 객체 간의 관계가 느슨해지기 때문에 유닛 테스트와 같은 테스트를 작성하기가 수월해집니다. 위의 두번 째 예처럼 다른 객체에 포함된 인터페이스 형태의 서비스 같은 경우에 Mock를 하여 유닛테스트를 작성하게 되면 그 서비스와 상관없이 작동가능한 테스트를 만들 수 있습니다.

마지막으로...
Dependency Injection은 단순히 그 의미나 사용 방법을 이해하려고 하기 보다는 왜 사용이 되는지를 파악해야 이해하기가 쉽습니다. 또한 같이 사용되고 있는 서비스의 개념과 왜 서비스의 형태로 사용되어야 하는지 등을 이해해야 좀더 이해하기가 쉬운 기술입니다.

출처:
http://ko.wikipedia.org/wiki/%EC%9D%98%EC%A1%B4%EC%84%B1_%EC%A3%BC%EC%9E%85

Friday, October 10, 2014

오픈스택(OpenStack)이란?


오픈스택이란?

오픈스택은 오픈소스 클라우드 컴퓨팅 소프트웨어로 2010년 나사와 랙스페이스 (Rackspace)의 공동프로젝트로 시작되었고 현재는 오픈스택 재단에서 운영되고 있습니다. 오픈스택은 현재 HP, AT&T, Intel과 우리 나라 기업 중 삼성과 KT등 많은 대기업들의 지원을 받고 있으며 2014년 10월 현재 408개의 회사 그리고 18,813명의 개발자가 개발에 참여하고 있는 전 세계에서 가장 큰 오픈 소스 커뮤니티를 보유하고 있는 클라우드 프로젝트입니다. 오픈스택 소프트웨어는 하나의 소프트웨어가 아닌 여러 개의 소프트웨어(또는 컴포넌트)로 구성이 되어 있는데 다음 파트에서 각각의 소프트웨어에 대해 좀더 상세히 다루도록 하겠습니다. 오픈스택은 현재 6개월 단위로 새 버전을 출시하고 있으며 매 버전마다 프로젝트 이름 (또는 릴리즈명)이 있는데 현재 가장 최근 버전의 프로젝트 이름은 지난 4월에 나온 아이스하우스(IceHouse)이며 이달 중순에 새 버전인 주노(Juno)가 출시 예정입니다.

오픈스택의 구성 및 구성원 각각의 정보
위에 언급한 것처럼 오픈스택은 여러 개의 컴포넌트로 구성이 되어있는데 2014년 10월 현재 총 10개의 컴포넌트가 정식으로 오픈되어 있으며 각각의 컴포넌트에 대한 간략한 설명은 아래와 같습니다. (*괄호 안의 이름은 해당 컴포넌트에 대한 프로젝트 이름입니다.)
  • Compute (Nova): 컴퓨트는 오픈스택 시스템에 연결된 하이퍼바이저에 행하는 모든 행위 (예를 들어 VM의 생성 또는 삭제)를 시행/ 관리하는 역할을 하는 사실 상 오픈스택에서 가장 중요한 역할을 하는 컴포넌트입니다. 
  • Dashboard (Horizon): 대쉬보드는 오픈스택 시스템 관리자를 위한 Web UI이며 관리자는 이 UI를 통해 오픈스택을 관리할 수 있습니다.
  • Object Storage (Swift): 오픈스택은 두가지 타입의 스토리지 서비스를 제공하는 그 중에 하나인 Object Storage 스위프트입니다. 오브젝트 스토리지에 대해 간략하게 설명하면 데이터를 오브젝트 단위로 저장하는 방식입니다.
  • Block Storage (Cinder): Swift와 함께 오픈스택이 제공하는 또 다른 스토리지 서비스는 Block Storage - Cinder 입니다. 이 스토리지 서비스는 우리가 일반적으로 사용하는 컴퓨터의 하드디스크에서 사용되고 있는 방식으로 데이터를 블록 단위로 저장하는 방식입니다.
  • Networking (Neutron): 네트워킹 서비스인 Neutron은 오픈스택 내의 IP address들과 네트워킹을 관리하는 기능을 제공하는 컴포넌트입니다.
  • Identity Service (Keystone): 아이덴티티 서비스는 오픈스택 내의 Authentication과 Authorization 기능을 제공하는 컴포넌트입니다.
  • Image Service (Glance): 이미지 서비스는 VM으로 생성될 이미지 파일들을 관리하는 기능을 제공하는 컴포넌트입니다. 이미지 서비스를 이용하게 되면 자주 생성하는 VM 같은 경우에 매번 이미지 파일을 업로드하지 않고 업로드한 이미지 파일을 템블릿처럼 사용할 수 있습니다.
  • Telemetry (Ceilometer): 텔레메트리는 사용자의 사용량을 측정해서 알려주는 기능을 제공하는 컴포넌트로 서비스 프로바이더 회사들에게 유용한 기능을 제공하는 컴포넌트입니다.
  • Orchestration (Heat): 오케스트레이션은 미리 작성된 스크립트와 준비된 템플릿을 이용해서 자동으로 개발 인프라를 구축할 수 있는 기능을 제공하는 컴포넌트입니다.
  • Database Service (Trove): 데이터 베이스 서비스는 이름 그대로 오픈스택 시스템 상에서 데이터 베이스 서비스를 구축할 수 있게 도와주는 기능을 제공하는 컴포턴트입니다.

왜 사용하나요?
많은 기업들이 오픈스택 사용을 결정하는 가장 큰 이유는 아래와 같습니다.
  • Open Source: 아무래도 가장 큰 장점 중에 하나가 바로 라이센스 비용없이 무료로 사용할 수 있는 오픈소스라는 점일 것입니다.
  • 거대한 커뮤니티: 위에 언급한 대로 오픈스택은 현재 많은 회사와 개인 개발자들이 참여/기여하고 있는 프로젝트이기 때문에 지속적으로 업데이트가 되고 있고 앞으로도 발전 가능성이 큰 프로젝트입니다. (반대로 커뮤니티가 작은 경우에는 중간에 프로젝트 자체가 중단이 되거나 버그가 발생했을 때 해결책이 빠르게 업데이트가 되지 않아서 직접 문제를 해결해야하는 일들이 발생할 수 있기 때문에 실제 제품화 할 때는 큰 문제가 될 수 있습니다.)
  • 다양한 하이퍼바이저 지원: 오픈스택은 다양한 하이퍼바이저(ESXi, Hyper-V, KVM, Xen 등)들을 지원하기 때문에 오픈스택을 사용해서 여러 다른 종류의 하아퍼바이저가 설치된 호스트들을 연결/관리할 수 있는 시스템을 제작할 수 있는 이점이 있습니다. 
그렇지만 위와 같은 장점에도 불구하고 아직까지 오픈스택은 많은 회사들이 사용에 어려움을 표현하고 있으며 아래는 오픈스택 사용시 어려운 점 또는 개선해야 할 점입니다.
  • 아직 완성되지 않은 서비스: 이제 출범한지 4년 정도 밖에 안된 프로젝트이고 오픈 소스 프로젝트이기 때문에 아직 부족한 기능이 많고 프로젝트가 컴포넌트 단위로 진행이 되기 때문에 이미 구축된 시스템도 하나의 컴포넌트에 문제가 발생했을 때 시스템 전체에 문제가 생기는 등 아직 전반적으로 불안정한 상태입니다. 
  • 시스템 구축의 어려움: 제대로된 오픈스택 시스템의 구축을 위해서는 클라우드 관련 다양한 지식 뿐만 아니라 네트워크나 시스템 관련 많은 경험/지식이 필요합니다. 또한 문제 발생 시 진단할 수 있는 API의 제공도 아직 부족하기 때문에 문제 해결에 많은 어려움이 있습니다.  
  • 협력업체와의 애매한 포지션으로 인해 생기는 문제점 (예:VMware, Citrix) 오픈스택 프로젝트를 지원하는 가장 큰 업체 중에 하나인 VMware는 협력업체이자 경쟁사이고 이런 애매한 포지션 때문에 전폭적인 지원을 받지 못하는 편입니다.
  • 체계적이지 못한 문서: 오픈스택 웹사이트에서 많은 문서들을 지원하고 있지 못하나 겹치는 부분도 많고 체계적이지 못 한 것이 사실입니다. 
이상 오픈스택에 대해 간략하게 정리해봤습니다. 혹시 잘못된 정보가 있거나 부족한 점이 있다면 글 남겨주세요. 나중에 시간이 된다면 간단한 오픈스택 시스템을 구축하는 과정에 대한 블로그를 작성해서 올리도록 하겠습니다.

Hope this helps!

Thursday, October 9, 2014

Jenkins에 SonarQube 연동

이번 블로그에서는 지난 번에 설치한 Jenkins에 SonarQube 설정을 해서 두 시스템을 연동해서 사용하는 방법에 대해서 설명하도록 하겠습니다.

연동하기 전에 필요한 것
  • Jenkins 서버
  • SonarQube
Jenkins에 SonarQube를 설정하기 위한 과정
  • Jenkins의 메인 웹 UI 접속
    • 웹브라우저를 통해 Jenkins의 메인 웹 UI 페이지로 갑니다. (예: http://[ipaddress]:8080)
  • Sonar 플로그인을 Jenkins에 설치
    • 메인 UI 페이지의 왼쪽에 있는 'Manage Jenkins' 링크를 클릭해서 'Manage' 페이지로 이동한 후 아래 그림과 같이 오른쪽에 있는 'Manage Plugins'을 클릭해서 플러그인들을 관리할 수 있는 페이지로 이동합니다. 
    • 'Manage Plugins' 페이지에서 우선 'Installed' 탭에 나열되어 있는 이미 설치된 플러그인들 리스트에서 'Sonar Plugin'이란 항목이 있는지 확인하시고 (만약 Jenkins가 최근 버전이 아닐 경우에는 'Jenkins Sonar Plugin'이란 이름으로 되어 있을 수도 있습니다.) 만약 없다면 'Available' 탭으로 이동해서 'Sonar Plugin'을 찾으신 후 설치하시면 됩니다.
  • JDK 설정 (이 부분은 Jenkins에 JDK설정이 안 되어 있을 경우에만 해당됩니다.)
    • 'Sonar Plugin' 설치가 끝나면 다시 위의 스크린샷에 있는 'Manage Jenkins' 페이지로 이동한 후 가장 위에 있는 항목인 'Configure System'을 클릭하여 Jenkins의 설정 페이지로 이동합니다. 
    • 설정 페이지에서 'JDK' 항목을 찾은 후에 'Add JDK' 버튼을 클릭해서 JDK 정보를 추가합니다. 
    • 버튼 클릭 후에 생기는 'Name'과 'JAVA_HOME' 부분을 현재 Jenkins가 설치된 리눅스 시스템의 환경 정보를 참조해서 기입하신 후에 'Install automatically' 항목을 클릭하시어 자동으로 설치되지 않도록 합니다. 
    • 위의 사항을 마치셨으면 'Apply' 버튼을 클릭해서 변경사항을 적용합니다. 아래는 위의 사항에 대한 스크린샷이며 기입된 정보는 저의 Jenkins가 설치된 리눅스 시스템의 환경정보이므로 하나의 예로 참고만 하세요. 

  • Sonar 설정
    • Sonar 설정을 위해 다시 위와 같이 'Manage Jenkins -> Configure System'을 통해 설정 페이지로 이동합니다. 
    • 이번에는 'Sonar' 부분을 찾아서 'Add Sonar' 버튼을 클릭합니다. 
    • 자신의 SonarQube 설정 정보를 이용해서 해당 사항을 입력한 후 'Apply' 버튼을 클릭하여 Sonar와의 연동에 필요한 정보를 업데이트합니다. 아래의 스크린샷을 참고하세요. (Server URL 부분과 Database URL 부분에 삭제된 부분은 현재 로컬에 설치된 SonarQube IP 주소를 대신 기입하시면 됩니다. 예: http://10.10.10.10:9000)

  •   Maven 설정 (이 부분 역시 추가적인 사항이며 만약 필요시에만 설정하시면 됩니다.)
    • 위의 설정 화면에서 Maven 부분을 찾은 후 'Add Maven' 버튼을 클릭합니다. 
    • Maven Name 부분을 본인이 원하는 이름으로 기입한후 'Apply' 버튼을 클릭합니다. 'Install Automatically' 부분은 클릭이 된 채로 두셔도 됩니다. 
 Hope this help!

Sunday, October 5, 2014

[잡담] 실리콘밸리에서의 생활 - 장점과 단점





아래는 지난 5년간의 실리콘 밸리 삶의 경험에 근거해 작성한 글, 잡담입니다.

장점:

  1. Software Engineer로서...
    1. 구직 또는 이직이 편하다. 특히 미국 경제 상태가 좋은 요즘 같은 경우에는...
    2. 소프트웨어 엔지니어에 대한 대우도 좋고 작업 환경도 너무 좋습니다. 보통 10시 반 또는 11시 출근해서 바쁜 정도에 따라 5시에서 6시 쯤 퇴근. (상사가 퇴근을 했든 안 했든)
    3. 미국 내의 다른 지역에 비해 외국인(인도인, 중국인 등)이 많다 보니 아무래도 다른 지역에 비해 영어에 대한 스트레스가 좀 덜 합니다. 
    4. 비슷한 일을 하는 사람들이 많기 때문에 인맥 쌓기도 좋고 자기 개발 및 성장에도 도움이 많이 됩니다. 
    5. 한국과 달리 엔지니어로서의 정년이 길기 때문에 오랜 기간 일을 할 수 있습니다.
  2. 생활 관련해서...
    1. 겨울에 잠시 비오는 걸 제외하고 일년 내내 맑은 날씨와 따뜻한 온도가 유지 됩니다. 특히 필자를 포함한 운동을 좋아하는 사람들한테는 이 점이 큰 장점중 하나입니다.
    2. 한국에 비해 싸고 신선한 과일들 (코스트코에서 바나나 한 다발에 2천원, 큰 수박 한 통에 6천원 - 7천원 정도) - 물론 품목마다 다를 수는 있지만 보편적으로...
    3. 산, 바다, 호수 등과 가까운 접근성 및 관련 레포츠 가능 - 이 부분은 정말 미국의 다른 지역 특히 중부나 동부 쪽에서는 이런 조건을 모두 갖춘 지역을 찾기 힘듭니다.
    4. 미국 내 다른 지역에 비해 높은 학구열과 좋은 평점의 학교가 많아서 자녀 교육에 좋습니다. (너무 경쟁이 심해 단점이 될 수도 있지만...)
    5. 도시 내에 나무가 많고 공원도 많은 편입니다. 
단점:
  1. Software Engineer로서...
    1. 아무래도 영어가 미국 사람이나 인도 사람들보다는 유창하지 못한 외국인이다보니 승진에 한계가 있거나 어려움이 있습니다. (물론 본인의 노력 여하에 따라 바뀔 수 있는 부분이기는 하지만 여기서 이야기하는 것은 보편적인 어려움을 이야기 하는 것입니다.)
    2. 항상 경쟁해야 하고 항상 공부해야 합니다. 실리콘 밸리는 인력을 구하는 회사도 많지만 그만큼 엔지니어들도 많기 때문에 엔지니어로 살아남기 위해서는 치열한 경쟁을 해야하며 특히 IT관련 기술들은 너무나도 빠르게 변하고 있기 때문에 계속 해서 공부를 하지 않으면 결국 뒤쳐지고 도태되게 됩니다. 특히 실리콘밸리는 미국의 다른 지역에 비해 변화가 더 빠른 편이기 때문에 더 많은 노력을 해야 하는 것 같습니다. 
  2. 생활 관련해서...
    1. 살인적인 물가 (특히 집값). 사실 일반 생활용품의 물가나 기름값 같은 경우에는 다른 지역에 비해 큰 차이가 없거나 조금 더 비싸지만 다른 지역에 비해 많이 받는 연봉으로 충분히 커버가 가능합니다. 그렇지만 집값은 월등히 비싸기 때문에 이 지역 사는 사람들 대부분의 걱정거리가 아닐까 생각합니다. 물론 기형적으로 비싼 서울 (특히 강남)에 비하면 싸거나 비슷하기 때문에 뭐가 그렇게 비싼가 할수도 있겠지만 미국에 있는 다른 지역의 집값에 비하면 월등히 비싸고 집 자체도 많이 낡은 편입니다. 
    2. 대중 교통의 부재: 버스가 있지만 노선이 지극히 제한적이고 택시는 상당히 비싼 편이기 때문에 기본적으로 차를 가지고 다녀야 하고 이 때문에 밖에서 음주를 하고 집에 오기가 부담스러운 편입니다. (대리도 있다고 들었는데 가격이 상당히 비싸다고 합니다.)
    3. 한국 음식: 미국의 다른 규모가 작은 도시에 비해서는 그래도 한국 식당이나 상점들이 많은 편이지만 그래도 맛있는 한국 음식점들이 많이 부족합니다. 
이상으로 필자가 경험하고 주변 사람에게 들은 내용을 기반으로 작성한 실리콘밸리 생활 관련 허접한 블로그였습니다. 

Friday, October 3, 2014

ESXi, vCenter, vSphere란?


VMware 제품들을 이용한 가상화 관련 작업을 할 때 가장 먼저 부딪치는 문제가 바로 여러 가지 새로운 개념들과 용어들 그리고 다양한 VMware 제품군들일 것입니다. (최소한 필자는 그랬습니다.) 그래서 이번 포스트에는 VMware의 엔터프라이즈 버전에서 가장 많이 사용되고 있는 제품들 (ESXi, vCenter, vSphere)의 개념과 차이점에 대해서 알아보도록 하겠습니다. 참고로 필자는 이 분야의 Expert가 아니기 때문에 아래의 정보는 필자의 경험을 바탕으로한 정보이며 부족한 부분이나 잘못된 정보가 있으면 글을 남겨주세요.

ESXi란?
ESXi는 VMware에서 나온 하이퍼바이저(Hypervisor)입니다. 하이퍼바이저란 쉽게 이야기하면 가상화 환경을 만들 수 있도록 최소한의 기능만을 지원하는 축소버전의 OS (윈도우즈나 리눅스 같은)라고 이해하시면 편할텐데요 (가상화 환경을 만드는데 소프트웨어의 도움없이 하드웨어를 그냥 사용할 수 없으니까요) Configuration과 시스템을 Manage할 수 있는 약간의 기능을 제외하고는 다른 기능들을 지원하고 있지 않습니다. (예를 들어서 GUI라던가…) 하이퍼바이저는 두 종류가 있는데 (Type 1과 Type 2) ESXi는 Type 1 하이퍼바이저입니다. 다른 회사에서 나온 경쟁 제품으로 Microsoft에서 나온 Hyper-V와 Citrix에서 나온 XenServer가 있습니다.

vCenter란?
가상화 환경을 만드는 가장 큰 이유는 여러 컴퓨터를 하나의 큰 성능/용량의 컴퓨터처럼 사용하기 위함인데 그 기능을 지원하는 것이 vCenter입니다. 다시 말해서 vCenter는 가상화 환경 구축을 위한 핵심 소프트웨어로 ESXi가 설치된 다수의 머신을 하나의 가상화 환경으로 만들어주는 기능을 제공합니다. 가상화 시스템 운영자의 입장에서 vCenter를 이용하면 여러 ESXi 호스트들을 쉽게 추가/제거할 수 있으며 그 외에도 아래와 같은 엔터프라이즈 기능들을 제공합니다.
  • vMotion: 현재 사용 중인 VM (Virtual Machine)을 VM의 전원을 끄지 않은 상태에서 다른 호스트로 (서버) 이동할 수 있게 해주는 기능
  • DRS (Distributed Resource Scheduler) & DPM (Distributed Power Management): VM의 컴퓨터 리소스 사용 (CPU나 메모리)을 계속 체크하고 경우에 따라 VM을 다른 호스트로 이동하거나 VM의 할당이 되지 않아서 아무런 일을 하지 않는 호스트의 경우 전원을 잠시 꺼두고 필요 시 다시 전원을 키는 등의 리소스 관리를 도와주는 기능

vSphere란?
vSphere란 위에 언급한 소프트웨어들을 전부 포함하고 있는 소프트웨어 Suite 또는 패키지를 일컬으며 위의 소프트웨어 외에도 다른 많은 소프트웨어를 포함하고 있습니다. (예를 들어 vSphere Client 또는 vSphere SDKs) 마이크로소프트 제품인 Office랑 비교하면 vSphere는 Office와 같은 개념이고 ESXi나 vCenter는 Word나 Excel이라고 이해하면 됩니다.

설치 및 라이센스에 대한 간략한 정보
대부분의 VMware 제품은 VMware 웹사이트(https://my.vmware.com/web/vmware/downloads)에서 무료로 다운로드 받아서 설치할 수 있으며 ESXi 같은 경우에는 무료 버전도 있기 때문에 무료로 다운 받아서 사용 가능합니다. 그렇지만 vCenter 라이센스는 유료이며 가격도 비싼 편입니다. (상당 부분의 VMware 영업이익이 vCenter 라이센스에서 발생된다고 들었습니다.) 사실 ESXi는 단순한 하이퍼바이저이기 때문에 무료로 배포를 한다고 해도 vCenter가 없으면 가상화 환경을 만들 수 없기 때문에 이런 사업 모델을 사용하는게 어떻게 보면 당연하다고 생각하며 이런 점 때문에 OpenStack 같은 오픈 소스 클라우드 플랫폼에 상당히 많은 사람들이 관심을 갖는게 아닌가 생각합니다. (OpenStack은 vCenter를 대체할 수 있는 오픈소스 프로젝트로 만약 OpenStack을 사용할 경우 vCenter 라이센스 없이 ESXi 호스트를 이용해서 가상화 환경 구축이 가능합니다. OpenStack 또한 하나의 큰 주제이기 때문에 나중에 시간이 된다면 따로 블로그를 작성해서 올리도록 하겠습니다.)  VMware 제품을 이용한 가상화 환경 구축을 위한 간단한 절차는 아래와 같습니다.
  1. 가상화 환경에 사용될 컴퓨터들에 ESXi 설치
  2. vCenter를 지원하는 OS (위에 언급한 컴퓨터와 다른 컴퓨터)에 vCenter를 설치. 각 버전마다 지원하는 OS가 다르기 때문에 VMware 웹사이트(http://www.vmware.com/resources/compatibility/search.php)를 참고해야 합니다.
  3. vSphere Client (또는 vSphere Web Client)를 통해서 vCenter에 접속해서 ESXi 호스트들을 추가/관리
사실 위의 과정들을 간략하게 소개했지만 각각의 과정들은 많은 세부 과정들을 포함하고 있습니다. 특히 vCenter 설치 같은 경우에는 다양한 방법들이 있고 약간 복잡한 면도 있기 때문에 나중에 시간이 된다면 따로 블로그를 작성해서 올리도록 하겠습니다.

Source (출처)
  • http://www.mustbegeek.com/difference-between-vsphere-esxi-and-vcenter/
  • http://www.vmware.com/products/vcenter-server/features
Hope this helps!

Friday, September 26, 2014

TURN 서버 설치

TURN 서버란?
TURN 서버는 Traversal Using Relays around NAT의 줄임말로 간단히 이야기 하자면 미디어 스트림을 Relay하는 Relay Server입니다. TURN 서버는 STUN 서버와 같이 WebRTC 어플리케이션에서 Firewall/NAT 문제를 해결할 때 사용되며 TURN 서버의 프로토콜에 대한 자세한 사항은 RFC 5766에 기술되어 있으니 참조바랍니다. (http://tools.ietf.org/html/rfc5766)

  • TURN 서버 설치 전에 필요한 것
    • CentOS 6.5 (64-bit)가 설치된 시스템 (또는 VM)
    • 최신 버전의 'libevent' 라이브러리 다운로드, 빌드, 인스톨
      • Download libevent from its github: https://github.com/libevent/libevent
      • tar xvfz libevent-[latest-version].tar.gz
      • cd libevent-[latest-verstion]
      • ./configure
      • make
      • make install 
  • TURN 서버 다운로드
    • 웹사이트: https://code.google.com/p/rfc5766-turn-server/wiki/newDownloadsSite?tm=2
    • 예: turnserver-3.2.3.94-CentOS6.5-x86_64.tar.gz (이 블로그에서는 이 패키지를 사용해서 설명하겠습니다.)

  • TURN 서버 빌드와 인스톨
    • 다운로드 받은 패키지를 '/opt' 폴더로 이동 후 압축해제
      •  mv turnserver-3.2.3.94-CentOS6.5-x86-64.tar.gz /opt
      • tar xvfz turnserver-3.2.3.94-CentOS6.5-x86-64.tar.gz
    • 압축을 푼 패키지의 폴더로 이동한 후 TURN 서버를 인스톨
      • cd turnserver-3.2.3.94-CentOS6.5-x86-64
      • ./install.sh
  • Long term credential 정보 추가
    • '/etc/turnserver/' 폴더에 생성된 'turnuserdb.conf' 파일에 'long term credential' (긴 기간 인증) 정보를 추가 (아래의 turnuserdb.conf 예 참조)
  • TURN 서버 시작
    • TURN 서버를 아래와 같은 옵션과 함께 시작
      • turnserver -v -a -r -n --userdb=/etc/turnserver/turnuserdb.conf
  • Sources
  • turnuserdb.conf의 예

#This file can be used as user accounts storage for long-term credentials 
#mechanism.
#
#username1:key1
#username2:key2
# OR:
Isley:abcd1234
#username1:password1
#username2:password2
#
# Keys must be generated by turnadmin utility. The key value depends
# on user name, realm, and password:
#
# Example:
# $ turnadmin -k -u ninefingers -r north.gov -p youhavetoberealistic
# Output: 0xbc807ee29df3c9ffa736523fb2c4e8ee
# ('0x' in the beginning of the key is what differentiates the key from
# password. If it has 0x then it is a key, otherwise it is a password).
#
# The corresponding user account entry in the userdb file will be:
#
#ninefingers:0xbc807ee29df3c9ffa736523fb2c4e8ee
# Or, equivalently (less secure):
#ninefingers:youhavetoberealistic
#