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

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

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/

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

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

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

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

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

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

앵귤러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/

스프링 프레임워크 (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/

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

오픈스택(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!

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!

SonarQube란?

소나큐브는 프로젝트의 품질을 관리할 수 있도록 여러가지 모니터링 툴을 제공하는 오슨소스 플랫폼입니다. 보통 소나큐브는 단독으로 사용되기 보다는 지난 번에 포스트한 Jenkins 같은 CI 서버와 연동이 되어서 사용이 되어지고 있으며 Java를 포함한 20가지가 넘는 프로그래밍 언어 (예: C#, C/C++, Javascript 등)로 제작된 프로젝트의 모니터링을 제공합니다.

아래는 소나큐브의 장점들입니다.

1. 오픈소스 프로젝트이기 때문에 라이센스 비용없이 다운받아서 사용 가능
2. 프로그램 설치 후 사용 가능한 파워풀하고 심플한 Web Monitoring UI (Dashboard) 제공
3. 테이블과 차트를 이용하여 시간이 지남에 따라 프로젝트가 얼마나 개선되고 있는지 보여줌
4. 코딩품질 개선을 위한 정보 (소스의 중복이나 복잡도 그리고 유닛 테스트의 커버리지 및 잠재적인 버그의 정보 등)을 프로젝트 단위부터 파일단위까지 제공

 위의 장점들 외에도 더 많은 기능들을 제공하지만 저의 개인적인 경험들로는 위의 부분들이 가장 크게 느껴졌었습니다. 그럼 소나큐브에 대한 간단한 설명을 마치고 다음 번 포스팅에서는 소나큐브의 설치와 Jenkins 서버와의 연동 방법에 대해서 설명하도록 하겠습니다.

Sources:

• SonarQube's Main Website: http://www.sonarqube.org/
• 메멘토님의 글: http://dryang.egloos.com/viewer/4005366

Jenkins 서버란?

Jenkins 서버란?
젠킨 서버는 Open Source CI (Continuous Integration) Tool로써 여기서 CI 란 팀의 구성원들이 작업한 내용을 정기적으로 통합하는 것을 의미합니다. 말이 약간 어려운데 쉽게 이야기하면 하나의 프로젝트를 여러 명으로 구성된 한 팀이 작업할 때 프로젝트를 리드하는 매니저가 일을 여러가지로 나눠서 팀멤버들한테 분배하고 팀멤버들은 각각 할당된 부분만 작업을 하게 됩니다. 그리고 팀멤버들은 자신이 담당해서 하고 있는 부분의 소스코드를 정기적으로 SVN과 같은 Version Control System에 Submit 하는데 이 각각의 팀멤버들로부터 Submit된 소스코드들을 정기적으로 통합하는 것을 CI라고 하고 이것을 시행해주는 프로그램을 CI tool이라고 합니다.

왜 사용하나요?
Jenkins 서버를 사용하는 이유는 여러 가지인데 제 개인적인 경험으로 봤을 때 가장 큰 이유는 아래와 같습니다.

1. 프로젝트의 빌드가 정상적으로 되고 있는지 체크할 때
2. 자동으로 유닛 테스트와 통합 테스트 (integration test)들의 정기적인 실행. 만약 테스트 결과에 문제가 있을 때 이메일을 통해 리포트
3. SonarQube 같은 코드의 질을 확인할 수 있는 모니터링 시스템과의 연동으로 코드의 질을 조절 

위의 내용을 짧게 이야기하면 Jenkins 서버는 현재 진행 중인 프로젝트가 정상적으로 빌드가 되고 있는지를 정기적으로 체크해서 결과를 팀원들한테 알려주고 문제가 발생했을 때 조기에 알려줄 수 있게 해줌으로써 여러 팀 멤버들이 큰 문제없이 각자의 맡은 부분만을 작업할 수 있도록 도와줍니다. 또한 프로젝트 빌드시 자동으로 유닛 테스트와 통합 테스트를 실행해줘서 잘 못된 점이 있으면 알려주고 또한 현재 얼마만큼의 소스코드를 유닛 테스트가 커버하고 있는지 및 어떤 부분에 문제가 있을 수 있는지 등의 정보도 SonarQube와 같이 연동시 모니터링 할 수 있도록 도와줍니다.

WebRTC란?

WebRTC는 구글이 2011년에 릴리즈한 오픈소스 프로젝트로 쉽게 말해서 브라우저 상에서 별도의 추가적인 설치 없이 (플러그 인이나 익스텐션없이) Web-based Video Conferencing (화상회의/ 화상채팅)을 구현할 수 있게 하는 기술입니다. 여기서 중요한 사실은 별도의 추가적인 설치(Plug-in) 없이 작동한다는 점인데 이 점이 왜 중요하냐면 개발하는 쪽에서는 추가적인 개발이 없이 원천 기술을 무료로 사용할 수 있기 때문에 관련 사업을 시작하기가 좋고 (큰 추가적인 비용이 없이) 사용하는 쪽에서는 매번 사용할 때마다 팝업이 떠서 추가적인 소프트웨어를 설치해야 하는 귀찮음을 덜 수 있어서 편리합니다.

그렇지만 이런 WebRTC를 사업화하는데 여러 가지 문제가 있으며 아래는 그에 해당하는 리스트입니다.
1. 지원하는 브라우저 수의 한계: WebRTC는 구글이 주도하는 프로젝트이고 마이크로 소프트와 애플은 여러가지 이유로 현재 지원하고 있지 않습니다. (코덱 표준 설정에 대한 의견 불일치 등) 그리고 Firefox나 Opera도 지원을 하고 있지만 Chrome과 세부적인 부분에서 약간의 차이가 있거나 특정 기능의 지원이 안되는 경우가 있습니다.
2. Firewall 문제 해결: 구글에서 제공하는 WebRTC API와 node.js 를 이용하면 간단한 화상채팅 프로그램을 만들수 있지만 STUN이나 TURN서버 없이는 같은 네트워크 상에서만 사용이 가능하고 만약 다른 네트워크나 방화벽이 설치된 네트워크에 있는 컴퓨터에서 접속하려면 위에 이야기한 STUN/TURN 서버를 설치한 후 ICE candidate에 포함시켜야 합니다. 서버 구축은 어렵지 않으나 여러가지 네트워크 상황에서도 일정하게 동작하게 하는데는 (Availability) 많은 시간과 노력이 필요합니다.
3. Signaling: 구글에서 제공하는 WebRTC API는 Signaling 관련된 사항은 포함이 안되어 있기 때문에 시크널링을 어떻게 구현할 것인지도 해결해야할 큰 문제 중에 하나입니다.
4. 확장성 (Scalability): MCU(Multipoint Control Unit)없이 사용하는 WebRTC 어플리케이션은 Mesh call이기 때문에 하나의 화상회의에 참가할 수 있는 인원이 최대 10명 (구글 측에서 제시한 자료에 따르면)이지만 사실 상 유저의 컴퓨터 사양과 네트워크 상태에 따라 틀리며 7명만 넘어가면 화면이 깨지는 현상이 발생합니다. 이런 확장성 문제를 해결하기 위해서는 위에 언급한 MCU를 제작해서 포함시켜야 하는데 이 또한 많은 시간과 노력 그리고 기술이 필요합니다.

위와 같은 제약에도 불구하고 많은 장점을 가지고 있기 때문에 (코덱의 무료 사용 및 여러가지 웹컨퍼런싱기술 제공) WebRTC는 미래가 밝은 기술입니다.

WebRTC의 공식 웹사이트는 www.webrtc.org이며 관련 소스는 아래와 같습니다.
- WebRTC Application: https://apprtc.appspot.com
- Sample Source Code: github.com/GoogleChrome/webrtc

FOUC란?

FOUC는 Flash of Unstyled Content의 약자로 웹브라우저가 웹 페이지를 로딩할 때 일시적으로 외부의 CSS stylesheet이 적용되지 않는 컨텐트를 로딩하여 화면에 출력하는 현상을 의마하는 말입니다.

원인: 이 현상은 브라우저마다 틀리지만 보통 아주 짧게 진행되며 이 현상이 생기는 이유는 웹브라우저가 컨텐트를 로딩할 때 한 번에 모든 컨텐트와 관련 화일을 로딩하여 출력하는 것이 아니라 우선 순위의 컨텐트를 먼저 로딩하기 때문에 (그리고 로딩이 다 끝나기 전에 화면에 출력이 되기 때문에) 발생합니다.

해결방법: HTML 파일의 Body tag에 'unresolved'라는 pseudo class를 포함하면 이런 현상이 생기는 것을 방지할 수 있습니다.
<body unresolved>

Sources:
http://en.wikipedia.org/wiki/Flash_of_unstyled_content
http://www.polymer-project.org/docs/polymer/styling.html#fouc-prevention
http://ko.wikipedia.org/wiki/FOUC