Category Archives: 소프트웨어

엑셀 스프레드시트 프린트 범위 설정하기

보통 엑셀 문서를 프린트 하면 페이지 전체가 프린트 됩니다.

그런데 특정 컬럼까지만 프린트하고 싶다거나, 다른 컬럼을 포함하고 싶다면 어떻게 해야 할까요?

 

답은 간단합니다.

메뉴에서 [페이지 레이아웃] 선택 → [인쇄영역] 선택 → [인쇄 영역 설정] 선택

image

그리고 인쇄버튼을 누르고 미리 보기를 확인하면 인쇄되는 컬럼에 변화가 생긴 것을 아실 수 있을 것입니다.

샤오미 YI 웹캠 덕분에 카메라에 녹화된 아버지의 모습을 복원하여 볼 수 있어 감사

저는 부모님 댁에 부모님을 상시 볼 수 있도록 CCTV를 설치 해 두었습니다.

제가 사용한 제품은 샤오미 Yi 스마트 웹캠입니다.

(아래 사진 참조)

image

 

이 제품을 사용하면 원격에서 틈나는데로 부모님의 얼굴을 볼 수 있고, 또 말도 걸 수 있습니다. 사실 말 거는 것은 놀라실까봐 거의 사용하지 않은 기능입니다.

최근에 아버지께서 돌아 가셨는데, 찍어둔 사진이나 비디오가 없어 매우 슬퍼하던 도중 샤오미 Yi 스마트 웹캠에 저장된 동영상이 저를 위로해주었습니다. 어젯밤 웹캠에 있는 마이크로 SD카드에 저장된 비디오를 PC에 복사하여 복원하였는데 2주치의 아버지 생전에 살아계시며 식사하시고 TV보시는 모습을 얻을 수 있었습니다.

이제 따듯한 아버지의 목소리를 비디오 파일로나마 볼 수 있어 너무 감사하게 생각합니다.

참고로 마이크로SD 카드에 저장된 비디오 파일은 제품 특성상 하나의 파일로 저장하기가 어려워 조각조각 쪼개져 있습니다 – 이는 파일 하나하나를 클릭해서 봐야 하는 구조로 이걸 이용하여 파일을 보기란 매우 많은 노력을 필요로 하게 됩니다. 아래의 사이트에 가면 zip파일이 하나 있는데, 그 소프트웨어를 이용하시면 여러개로 쪼개져 있는 파일을 비슷한 시간대로 합칠 수 있습니다.

http://qsok.com/display/YIHCM/YI+Home+Clip+Merger

Delphi Community Edition – 비영리/개인 개발자에게 완전 무료

오늘 델파이를 간만에 찾아보다가 커뮤니티 에디션이 최근에 나왔다는 것을 발견했습니다.

커뮤니티 에디션 사용 자격은 아래와 같습니다.

  • 총 연 매출 $5,000 미만인 기업 (개인사업자 포함)
  • 개발자가 5명 미만인 기업
  • 비영리 목적 개발 (개인 취미용)

image

해당 설치파일은 아래 링크에서 다운로드 가능합니다.

https://www.embarcadero.com/products/delphi/starter/free-download

다운로드를 완료하면 아래와 같이 메시지가 오는데, 이때 설치 시 입력한 이메일주소로 시리얼넘버가 오므로, 메일 주소를 아무 주소나 넣으시면 안됩니다.

image

CENTOS 7.x에 ffmepg 설치하는 방법

mov, avi 같은 포멧으로 Centos 기반 서버에 저장된 동영상을 mp4로 변환할 일이 생겨 ffmpeg을 설치하는 방법을 공유하고자 합니다.

STEP 1. epel-release를 설치합니다.
# yum -y install epel-release

STEP2. nux repository를 설치합니다.
# rpm -Uvh http://li.nux.ro/download/nux/dextop/el7/x86_64/nux-dextop-release-0-5.el7.nux.noarch.rpm

STEP3. ffmpeg과 ffmpeg-devel 패키지를 설치합니다.
# yum install ffmpeg ffmpeg-devel -y

STEP4. 동작 여부를 테스트 해 봅니다.
# ffmpeg -version
ffmpeg version 2.6.8 Copyright (c) 2000-2016 the FFmpeg developers
built with gcc 4.8.5 (GCC) 20150623 (Red Hat 4.8.5-4)
configuration: –prefix=/usr –bindir=/usr/bin –datadir=/usr/share/ffmpeg –incdir=/usr/include/ffmpeg –libdir=/usr/lib64 –mandir=/usr/share/man –arch=x86_64 –optflags=’-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong –param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic’ –enable-bzlib –disable-crystalhd –enable-gnutls –enable-ladspa –enable-libass –enable-libcdio –enable-libdc1394 –enable-libfaac –enable-nonfree –enable-libfdk-aac –enable-nonfree –disable-indev=jack –enable-libfreetype –enable-libgsm –enable-libmp3lame –enable-openal –enable-libopenjpeg –enable-libopus –enable-libpulse –enable-libschroedinger –enable-libsoxr –enable-libspeex –enable-libtheora –enable-libvorbis –enable-libv4l2 –enable-libx264 –enable-libx265 –enable-libxvid –enable-x11grab –enable-avfilter –enable-avresample –enable-postproc –enable-pthreads –disable-static –enable-shared –enable-gpl –disable-debug –disable-stripping –shlibdir=/usr/lib64 –enable-runtime-cpudetect
libavutil 54. 20.100 / 54. 20.100
libavcodec 56. 26.100 / 56. 26.100
libavformat 56. 25.101 / 56. 25.101
libavdevice 56. 4.100 / 56. 4.100
libavfilter 5. 11.102 / 5. 11.102
libavresample 2. 1. 0 / 2. 1. 0
libswscale 3. 1.101 / 3. 1.101
libswresample 1. 1.100 / 1. 1.100
libpostproc 53. 3.100 / 53. 3.100

위와 비슷한 정보가 뜬다면 일단 ffmpeg 설치에 성공하신 것입니다. 이후 mp4 포멧으로의 영상 변환은 다음과 같은 커맨드로 가능합니다.

ffmpeg으로 mov file을 mp4로 변환하는 방법

아이폰에서 동영상을 찍거나 편집하면 mov파일로 저장됩니다. 이를 mp4로 저장하는 방법은 ffmpeg을 설치 한 후 커맨드라인에서 다음과 같이 명령어를 실행해 주면 됩니다.

방법1)

ffmpeg –i source_video.mov –vcodec h264 –acodec mp2 my-video.mp4

방법2) 오디오 코덱을 aac로 바꾸어 보았습니다.

ffmpeg –i source_video.mov –vcodec h264 –acodec aac my-video.mp4

마이크로 서비스 아키텍쳐 (MSA, Micro Service Architecture)의 장단점 및 구현 방법

마이크로 서비스 아키텍쳐(Micro Service Architecture)는 줄여서 MSA라고 부르며 서비스를 기능별로 작게 쪼개는 서버 아키텍쳐의 디자인 패턴으로, 기본 컨셉은 하나의 서비스는 한가지 일에 초점을 맞춘다는 것입니다. 또 다른 서비스와의 연계는 API로 구현합니다.

마이크로 서비스 아키텍쳐 구현 프로세스는 크게 4단계로 나눌 수 있는데, 구체적인 처리 절차는 다음과 같습니다.

STEP 1. 기능별로 서비스 어플리케이션 구분

마이크로 서비스 아키텍쳐 (MSA, Micro Service Architecture)의 장단점 및 구현 방법

STEP 2. 서비스 이미지 개발

– 이때 각각의 서비스 어플리케이션은 수샙, 수백여개의 서비스들로 구성되며, 각 서비스는 적절한 CPI, Memory, I/O리소스를 제공받아야 하고, 배포는 빠르고 효율적이어야 함. 참고로 배포 방법은 서버마다 전체 서비스를 적용하는 방법, 서비스를 VM위에 적용하는 방법, 서비스를 도커 콘테이너 위에 적용하는 방법 등이 있습니다.

– 서버별로 서비스를 적용하면 배포 및 서비스의 시작속도가 빠르다는 장점이 있습니다. 그러나 한 서비스 인스턴스가 CPU와 메모리를 모두 사용하는 문제점이 있습니다.

마이크로 서비스 아키텍쳐 (MSA, Micro Service Architecture)의 장단점 및 구현 방법

– 서비스를 VM에 적용하면 서비스별로 고정된 자원을 사용할 수 있고 클라우드 인프라 기능을 활용할 수 있다는 장점이 있습니다. 반면에 의도 해던 기능 외의 다른 VM의 기능은 낭비된다는 단점이 있고, 또 VM 자체를 관리해주어야 하는 오버해드를 가지고 있습니다.

마이크로 서비스 아키텍쳐 (MSA, Micro Service Architecture)의 장단점 및 구현 방법

– 마지막으로 서비스를 도커 콘테이너에 적용하는 방법이 있는데, 이는 VM의 장점을 거의 포함하면서 VM 보다는 가볍다는 잇점이 있습니다. 반면에 VM보다는 다소 기능이 떨어 질 수 있습니다.

마이크로 서비스 아키텍쳐 (MSA, Micro Service Architecture)의 장단점 및 구현 방법

STEP 3. 클라이언트에서 필요한 서비스 선택

– 실제 서비스 설계시 클라이언트에서 어떤 기능을 필요로 하는지 모델링을 할텐데, 이때 기능에 중복성을 없애면서 통신을 최소 하는 방향으로의 설계가 바람직합니다.

– 최적화 된 클라이언트의 구현 방법으로 API Gateway와 IPC(Inter-process Communiation)의 두가지 방법이 있습니다.

– API Gateway는 내부 시스템 아키텍쳐를 캡슐화 해서 클라이언트에 적합한 API를 제공하는 방식인데, 이는 주로 Netty, Vert.x, Node.js, Nginx와 같은 비동기, 논블로킹 I/O를 지원하는 플랫폼으로 개발됩니다. 또 통신 규격의 다양화로 이중 가장 효율적인 것을 선택할 수 있다는 장점이 있으며, Auto Scaling 및 IP 주소 변경에 유연하게 대응할 수 있다는 장점이 있습니다. 마지막으로 서비스 오류 핸들링을 용이하게 할 수 있다는 장점이 있는데, 넷플릭스의 Hystrix가 바로 그 예입니다.

마이크로 서비스 아키텍쳐 (MSA, Micro Service Architecture)의 장단점 및 구현 방법

– IPC(Inter-process Communication)은 서비스-클라이언트, 서비스-서비스간 통신 구현 방식인데, 구현 방법에 따라 동기적(request)/비동기적(message-based) 방식으로 나뉩니다. 주로 HTTP Rest나 Thrift 프로토콜을 많이 사용하며, 서비스 오류 핸들링이 용이하다는 장점이 있습니다.

마이크로 서비스 아키텍쳐 (MSA, Micro Service Architecture)의 장단점 및 구현 방법

STEP 4. 인스턴스 선택/관리

– 서비스가 가상화되먄 여러 인스턴스로 실행 시킬 수 있습니다. 이때 Auto Scaling 혹은 장애 등으로 IP 주소가 변화될 수 있습는데, 장애를 막기 위해 서비스 레지스트리에 자신의 상태를 전달합니다. 이때 상태 전달을 hearbeat이라고 호칭합니다.

마이크로 서비스 아키텍쳐 (MSA, Micro Service Architecture)의 장단점 및 구현 방법

 

마이크로 서비스 아키텍쳐의 장점을 요약하면 다음과 같습니다.

  • 빠른 복구
  • Scaling
  • 서비스 확장 용이
  • 대규모 장애 확률 감소
  • 협업 용이

 

반면에 마이크로 서비스 아키텍쳐의 단점은 다음과 같습니다.

  • 복잡함
  • 트렌잭션 관리 어려움
  • 다중 테스트
  • 소규모 장애 확률 증가

 

 

AWS 기반 서버 없는 아키텍쳐(Server-less back-end architecture)

인터넷 기반으로 서비스를 하는데 서버 없는 아키텍쳐가 있다고 하여 이를 올려 봅니다.

제목에 서버가 없다고 했지만, 서버가 아예 없는건 아닙니다. 정확한 표현은 최소화했다고 보는 것이 맞을 것 같습니다.

 

아래의 사례는 Amazon S3를 기반으로 하는 서비스 아키텍쳐 입니다.

AWS 기반 서버 없는 아키텍쳐(Server-less back-end architecture)

Amazon CloudFront를 통해 콘텐츠르 배포하고, Amazon API Gateway를 이용하여 필요한 기능은 AWS Lamda를 이용한 사례입니다. AWS Lamda는 하나의 함수를 코드조각으로 구성하여 실행하는 실시간 대응형 서비스입니다.

 

아래의 사례는 모바일 앱의 사례인데, 기능이 좀더 복잡하여 Amazon API Gateway로 분기하여 AWS Lamda를 호출 한 사례입니다.

AWS 기반 서버 없는 아키텍쳐(Server-less back-end architecture)

아래의 사례는 최소한의 기능만 가지고 서비스를 하는 마이크로 서비스의 사례입니다.

AWS 기반 서버 없는 아키텍쳐(Server-less back-end architecture)

뭐, 서버가 없다고 했지만, 이 모든것을 Lamda로 대체 가능하다고 주장하고 있습니다. 이를 위해서는 소프트웨어 구현 방법이 기존과는 달라져야 합니다.

넷플릭스 서비스 오토스케일링 아키텍쳐

글로벌 비디오 서비스 강자인 넷플릭스는 아마존 AWS를 운영환경으로 사용합니다.

그들이 온라인 비디오 시장에서 티격태격하면서 경쟁하고 있지만, 아이러니하게도 넷플릭스는 아마존과 끈끈한 관계를 유지하고 있습니다. 아마도 아마존은 넷플릭스덕분에 그들의 아마존 프라임 비디오 서비스를 위한 환경 구축을 북미 전역에 쉽게 얻었을 것이라는 생각을 하게 만듭니다. 

서비스 트래픽에 따라 서버 인스턴스를 늘렸다 줄였다 하는 오토스케일링(AWS Auto Scaling)을 기본으로 쓰고 있는데, 이는 다른 서비스 아키텍쳐와 다를 바가 없습니다.

다만, 트래픽이 증가한다고 무작정 오토스케일링을 하지 않고, 그들의 정책에 따라 EC2나 DynamoDB등의 키 컴포넌트를 스케일인, 스케일아웃을 한다는 것이 특징이라고 할 수 있습니다. 아래 그림에서는 Titus Control Plane이라 불리우는 넷플릭스 자체 시스템이 그러한 정책을 관리합니다.

넷플릭스 서비스 오토스케일링 아키텍쳐

또 하나 눈여겨 볼 것은 모바일/텔레비젼과의  통신은 Open API를 통해서 하지만, 자체구축하지 않고 Amazon API Gateway를 사용했습니다. 그럼으로 인해서 비용절감 및 보안(Security)을 해결하는 일타이피( ? ) 전략을 구사하고 있습니다.

참고로 위의 스핀네이커(Spinnaker)는 node.js 기반으로 동작하는 넷플릭스의 CDS(Continuous Delivery System)입니다.

Windows 10 – 로컬디스크 E 용량부족 메시지 뜨는 문제

윈도우 10 업데이트 후 갑자기 전에 안보이던 로컬디스크 E라는 것이 생기고 용량이 부족하다는 메시지가 자꾸 뜨는 분들 계실겁니다.

이런 고통스러운 메시지가 뜨시는 분들은 다음과 같이 조치를 취해주시면 더 이상 이 메지시를 보지 않으셔도 됩니다.

  1. 좌측 하단의 시작버튼 클릭
  2. CMD라고 치면 명령프롬프트라고 뜨는데 이때
    • 마우스 오른쪽 버튼으로 클릭하고 “관리자모드로 실행”
  3. 명령 프롬프트가 뜨면 아래 명령어를 입력하고 엔터
    mountvol e: /D

이러면 E 드라이브가 없어지고 더 이상 용량부족 메시지는 안뜹니다.

플러거블 스토리지 엔진을 가진 MySQL 아키텍쳐 – InnoDB는 인메모리 캐싱을 하는 고성능 솔루션

오라클 홈페이지에 가니 플러거블 스토리지 엔진 기반으로 동작하는 MySQL 아키텍쳐 그림을 볼 수 있었습니다. 플러거블(Pluggable)이라 함은 스토리지 방식을 선택할 수 있다는 것인데요. 이는 각각의 스토리지가 컴포넌트처럼 동작한다는 의미를 내포합니다.

플러거블 스토리지 엔진을 가진 MySQL 아키텍쳐 - InnoDB는 인메모리 캐싱을 하는 고성능 솔루션

MySQL 5.5.5 이전 버젼에서는 MyISAM이 기본 스토리지 엔진이었습니다, 그런데 5.5.5부터는 InnoDB가 기본적으로 붙도록 바뀌었습니다. 쓰는 입장에서는 별 차이를 느낄 수 없을 것이라 생각됩니다만, 고도화 된 연산을 하는 부분에서는 성능차이가 발생 할 수 있을 것으로 생각됩니다. 즉, 개발된지 오래 된 MyISAM은 성능적으로 좀 느린 피드백을 줄 가능성이 높습니다. 그렇지만 256TB의 대용량을 지원 및 검색 기능은 무시 할 수 없을것 같군요.

MyISAM 스토리지의 기본피쳐는 아래와 같습니다.

플러거블 스토리지 엔진을 가진 MySQL 아키텍쳐 - InnoDB는 인메모리 캐싱을 하는 고성능 솔루션

이와 비교할만한 DB로 InnoDB를 살펴봅시다.  보시는 바와 같이 스토리지는 64TB로 제한적이지만 주 메모리에 데이터와 인덱스(Index)를 상시 캐싱(Caching)하는 구조로 인한 퍼포먼스상의 잇점을 무시할 수 없을 것 같습니다. 즉, 인덱싱이 잘 되어져 있는 DB를 쓰시고 계신다면 설계시 감안했던 모든 잇점을 다 살리실 수 있을 것입니다.

플러거블 스토리지 엔진을 가진 MySQL 아키텍쳐 - InnoDB는 인메모리 캐싱을 하는 고성능 솔루션

좀더 자세한 기술적 자료는 아래 링크를 참조하세요.

https://docs.oracle.com/cd/E19957-01/mysql-refman-5.5/storage-engines.html

아틀라시안 뱀부(Atlassian Bamboo)를 활용한 CI(Continuous Integration) 환경 구축

아틀라시안 뱀부(Atlassian Bamboo)는 CI(Continuous Integration) Tool입니다. 여기서 CI는 어플리케이션 소스가 변경되면 이를 자동으로 빌드하고, 테스트하고 서버에 배포까지 완료해주는 일련의 프레스를 자동으로 수행하는 것을 가능하게 해주는 툴입니다.

일반적으로 개발자가 소스코드를 수정하여 소스코드 저장소에 올립니다. 이때 CI Tool이 저장소를 모니터링 하고 있다가, 뭔가 새로 변경된 것이 발견되면 소스코드를 다운로드하고 컴파일하여 자동실행 환경으로 배포까지 해 줍니다.

아틀라시안 뱀부(Atlassian Bamboo)를 활용한 CI(Continuous Integration) 환경 구축

뱀부(Bamboo)의 기본 기능은 아래와 같습니다.

  • 자동화(Automation)
  • BitBucket 소스코드 정합 및 Jira 트래킹
  • 모든 언어 지원
  • 병렬처리
  • 기존 자동화 툴(Hudson or Jenkins)로부터 소스코드 쉽게 이전 가능

유료라는 것이 함정이지만, 비용만큼의 가치가 있다는데 한표를 주고 싶습니다.

아키텍쳐 패턴이란 – 소프트웨어 디자인 패턴

외국인회사에 있다 보면 개발자 채용시 아키텍쳐 설계 부분도 이야기를 하게 됩니다. 그러면 어떤 어프로치로 소프트웨어를 설계해야 하느냐에 대한 논의를 하게 됩니다.

소프트웨어 개발/설계시 아키텍쳐링을 하다 보니 반복되는 패턴이 나오기 시작했고, 사람들은 이 패턴에 이름을 붙이기 시작했습니다. 즉, 아키텍쳐 패턴(Archiectural Patterns)이라 함은 소프트웨어 디자인 패턴이라고 할 수 있습니다. 참고로 패턴(Pattern)=유형,종류 라고 간주하셔도 될 것 같습니다.

 

아키텍쳐 패턴(Architectural Patterns)은 대략 다음의 10가지 종류가 있습니다.

1. Layered pattern

2. Client-server pattern

3. Master-slave pattern

4. Pipe-filter pattern

5. Broker pattern

6. Peer-to-peer pattern

7. Event-bus pattern

8. Model-view-controller pattern

9. Blackboard pattern

10. Interpreter pattern

 

여기에 하나 빠진것이 있다면 최근 떠오르는 MSA(Micro Service Architecture)가 있을텐데요… 이정도 길이면 학생들 가르킬때 21주짜리 프로그램이 하나 나올법도 하네요.

Interpreter pattern은 SQL 또는 통신프로토콜을 기술하는 언어 구현시 주로 이용되는 아키텍쳐

인터프리터 아키텍쳐 패턴(Interpreter Architectural pattern)은 프로그래밍 언어의 특정 구문을 해석/분석하는 컴포넌트 디자인에 많이 사용됩니다.

이 아키텍쳐의 기본 아이디어는 각각의 표현마다 클래스를 가지도록 하여 이를 조합하는 구조를 만드는 것입니다.

Interpreter pattern은 SQL 또는 통신프로토콜을 기술하는 언어 구현시 주로 이용되는 아키텍쳐
인터프리터 아키텍쳐 패턴(Interpreter Architectural pattern)은 SQL과 같은 Database Query Language 또는 특정 통신 프로토콜을 기술하기 위한 언어 등에 주로 응용되고 있습니다.

인터프리터 아키텍쳐 패턴(Interpreter Architectural pattern)의 장점이라 함은 동적인 설계가 가능하며, 최종 사용자가 프로그래밍하기 좋다. 즉, 인터프리터 프로그램을 쉽게 교체할 수 있기 때문에 유연성이 향상된다고 할 수 있습니다.

반면에 인터프리터 언어는 일반적으로 컴파일 언어보다 느리기 때문에 성능 문제가 발생할 수 있다는 단점이 있습니다.

Blackboard pattern은 오늘날 NLU(Natural Language Understanding)이나 차량인식 등에 응용되는 아키텍쳐

블랙보드 아키텍쳐 패턴(Blackboard Architectural pattern)은 Non-deterministic algorithm(비결정성 알고리즘)을 구현하는데 널리 이용되고 있습니다.

Non-deterministic algorithm(비결정성 알고리즘)은 그 다음 단계의 결과가 실행할때마다 다르게 나올 수 있는 알고리즘을 의미합니다. 참고로 Deterministic algorithm(결정성 알고리즘)은 결과가 유니크(Unique)합니다. 즉, 특정 값으로 떨어집니다.

Non-deterministic algorithm(비결정성 알고리즘)의 예는 “오늘 날씨 어떻지?”라는 함수를 호출했을때, 아침에는 “맑음”이었는데, 같은 함수를 오후에 호출하면 “흐림”으로 나오는 것이 그 예라고 할 수 있습니다.

블랙보드 아키텍쳐 패턴은 크게 3개의 컴포넌트로 이루어져 있습니다.

  • 블랙보드(blackboard) – 솔루션(solution space)에서 가져온 객체(object)를 가지고 있는 구조화된 전역 메모리 (structured global memory)
  • 지식소스(knowledge source) – 각각의 표현을 기술한 모듈
  • 컨트롤 컴포넌트(control component) – 상황에 맞게 모듈을 선택/설정/실행 합니다

모든 컴포넌트는 블랙보드를 통해 제어되며, 각각의 컴포넌트들은 백보드의 데이터 객체(data object)로 생성되어, 각각의 패턴에 맞는 지식소스로부터 패턴이 일치하게 되면 정해진 프로세스를 수행하게 됩니다.

Blackboard pattern은 오늘날 NLU(Natural Language Understanding)이나 차량인식 등에 응용되는 아키텍쳐

블랙보드 아키텍쳐 패턴(Blackboard Architectural pattern)은 구문인식(Speech recognition), 차량인식 및 추적(Vehicle identification and tracking), 시그널프로세싱, 단백질 구조 분석(Protein structure identification) 등에 응용되고 있습니다.

마지막으로 블랙보드 아키텍쳐 패턴(Blackboard Architectural pattern)의 장단점을 언급하면, 새로운 애플리케이션을 쉽게 추가할 수 있다는 장점이 있습니다만, 데이터 공간의 구조를 변경은 모든 애플리케이션이 영향을 받기 때문에 하기가 어렵다는 단점이 있어 동기화 및 접근 제어가 필요할 수 있습니다.

MVC(Model-view-controller) pattern은 Django, Rails와 같은 웹 어플리케이션 개발에 주로 응용되는 아키텍쳐

MVC(Model-view-controller) 아키텍쳐 패턴(Architectural pattern)은 웹 어플리케이션 개발에 주로 이용되는 아키텍쳐 패턴입니다.

MVC는 다음의  3개 파트로 구성되어져 있습니다.

  • 모델(model) – 기본 함수와 데이터를 포함합니다
  • 뷰(view) – 정보를 사용자에게 보여줍니다. 웹페이지 그 자체를 생각하시면 될 것 같습니다
  • 컨트롤러(controller) – 사용자로부터의 입력을 처리합니다

이 패턴의 기본 아이디어는 UI/연산(모델)/제어를 각각 분리하여 효율화를 하겠다는 것입니다. 실제 서비스 구축시에는 각각의 파트가 서버 인스턴스로 구성되어 퍼포먼스에 따른 서버 리소스 할당을 하여 효율화를 하기도 합니다.

MVC(Model-view-controller) pattern은 Django, Rails와 같은 웹 어플리케이션 개발에 주로 응용되는 아키텍쳐

MVC 아키텍쳐 패턴은 Java, Python, PHP와 같은 주요 프로그래밍 언어로 웹 어플리케이션 아키텍쳐 디자인시 주로 사용되고 있으며, Django나 Rails와 같은 웹 프레임웍(Web frameworks)에서도 사용되고 있습니다.

MVC 아키텍쳐 패턴은 동일한 모델에 대해 여러개의 뷰를 만들 수 있으며, 런타임에 동적으로 연결 및 해제를 할 수 있다는 장점이 있습니다. 그러나 이것이 오히려 복잡성을 증가시키며, 사용자의 행동에 대한 불필요한 업데이트가 많이 발생할 수 있다는 단점 또한 가지고 있습니다.

최근에는 RESTful API (Open API) 기반의 서비스/소프트웨어 개발이  널리 이용되면서 점차 MSA(마이크로 서비스 아키텍쳐; Micro Service Architecture)로 이동하는 추세를 보이고 있습니다.

Event-bus pattern은 Push Notification Service, 안드로이드 앱 개발에 주로 응용되는 아키텍쳐

이벤트-버스 아키텍쳐 패턴(Event-bus Architectural pattern)은 4개의 주요 컴포넌트로 구성되어져 있는데, 이들 컴포넌트는 이름에서 예상되듯 이벤트를 다루는 컴포넌트 입니다.

  • 이벤트 소스(event source)
  • 이벤트 리스너(event listener)
  • 채널(channel)
  • 이벤트 버스(event bus)

아래의 그림에서 특정 채널을 통해 메시지가 메시지 버스를 통해 전달 되면, 리스너(listener)는 등록(subscribe)한 특정 채널에 해당하는 메시지를 이벤트로 받는 구조입니다. 이 이벤트를 받는 것을 영어로 Event Notification이라고도 합니다.

Event-bus pattern은 Push Notification Service, 안드로이드 앱 개발에 주로 응용되는 아키텍쳐

안드로이드(Android)/아이폰 앱 개발이 이 아키텍쳐 패턴(Architectural pattern)에 해당하며, Push Notification Service도 이벤트-버스(Event-bus) 아키텍쳐 패턴(Architectural pattern)에 해당된다고 할 수 있습니다.

이벤트-버스 아키텍쳐 패턴(Event-bus Architectural pattern)은 고도로 분산화된 애플리케이션에 효과적이라고 할 수 있습니다. 반면, 모든 메시지가 동일한 이벤트 버스를 통해 전달되기 때문에 확장성 문제가 발생할 수 있다는 단점이 있습니다.

Peer-to-peer pattern은 BitTorrent와 같이 파일공유 솔루션이나 P2PTV, PDTP와 같은 멀티미디어 프로토콜에 주로 이용

P2P는 Peer-to-Peer의 줄임말입니다.

P2P 아키텍쳐 패턴(Architectural pattern)에서 개개의 각각의 독립적인 컴포넌트를 피어(peer)라고 부릅니다. 각각의 피어는 클라이언트로서 다른 피어에게 서비스를 요청하면서 한편으로는 서버로서 요청받은 서비스를 동적으로 처리해주는 기능을 가집니다.

Peer-to-peer pattern은 BitTorrent와 같이 파일공유 솔루션이나 P2PTV, PDTP와 같은 멀티미디어 프로토콜에 주로 이용

2000년대 초반에 많이 쓰이던 당나귀(eDonkey), 냅스터(Napster), 소리바다와 같은 소프트웨어가 P2P 아키텍쳐 패턴에 해당하며, P2PTV나 PDTP같은 멀티미디어 프로토콜이 및 비트코인이나 이더리움 등의 최근 크립토 커런시(Crypto Currency) 등이 아키텍쳐 패턴에 해당합니다.

P2P 아키텍쳐 패턴(Architectural pattern)은 탈중앙화된 컴퓨팅을 지원하며, 특정 노드 장애에 매우 강하고, 리소스 및 컴퓨팅 성능면에서 확장성이 뛰어나다는 장점이 있습니다. 
반면에 노드들이 자발적으로 참여하기 때문에 서비스 품질에 대한 보장이 어려우며 보안에 대한 보장이 어렵고, 노드의 갯수에 따라 성능이 좌우된다는 것은 단점이라고 할 수 있습니다.

Broker pattern은 Apache ActiveMQ, Apache Kafka, RabbitMQ 등 메시지 미들웨어 같은 아키텍쳐에 주로 이용

브로커아키텍쳐 패턴(Broker Architectural pattern)은 클라이언트-서버(Client-Server) / 마스터-슬레이브(Master-Slave) 처럼 역할이 분리된 컴포넌트(decoupled components)를 구조화하는데 주로 응용되는 패턴입니다.

여기서 브로커 컴포넌트는 컴포넌트간 통신(communication)을 조율(coordination) 하는 역할을 담당합니다.

클라이언트가 어떤 요청사항을 전달하면, 브로커가 중간에 받아서 이를 처리할 기능이 있는 서버로 명령을 요청하게 되고, 서버가 이에 따른 결과를 처리하는 방식입니다.

Broker pattern은 Apache ActiveMQ, Apache Kafka, RabbitMQ 등 메시지 미들웨어 같은 아키텍쳐에 주로 이용

Apache ActiveMQ, Apache Kafka, RabbitMQ and JBoss Messaging과 같은 소프트웨어가 브로커(Broker) 아키텍쳐 패턴(Architectural pattern)에 해당합니다.

브로커아키텍쳐 패턴(Broker Architectural pattern)은 객체의 동적인 변경, 추가, 삭제 및 재할당이 가능하며 개발자에게 배포를 투명하게 할 수 있다는 장점이 있습니다.

또한 배포를 투명하게 하려면 서비스 표현에 대한 문서화 등의 표준화가 필요합니다.

Pipe-filter pattern은 컴파일러와 같이 통해 연속되는 필터링 기법을 통한 분석을 하는 아키텍쳐에 주로 이용

파이프-필터 아키텍쳐 패턴(Architectural pattern)은 웹로그와 같은 텍스트 기반의 데이터 또는 프로그램 소스 코드 등과 같은 데이터 스트림을 처리하는데 적합합니다.

각각의 프로세스는 필터 컴포넌트 내에서 처리되며, 데이터는 파이프를 통해 전달되어 처리되어집니다. 이러한 파이프는 버퍼링을 하거나 동기화 하는 목적으로 사용됩니다.

Pipe-filter pattern은 컴파일러와 같이 통해 연속되는 필터링 기법을 통한 분석을 하는 아키텍쳐에 주로 이용

컴파일러, DNA정보 분석 소프트웨어가 파이프-필터 아키텍쳐 패턴(Architectural pattern)기반이라고 할 수 있습니다.

파이프-필터 아키텍쳐 패턴(Architectural pattern)은 다음과 같은 장점이 있습니다.

  • 필터 추가가 쉬움
  • 시스템 확장성이 좋음
  • 필터 재사용 가능
  • 주어진 필터들을 재구성하여 또 다른 파이프라인을 구축할 수 있음

반면에 단점이라 하면, 특정 필터 연산의 성능이 전체 효율에 영향을 미칠 수 있다는 것입니다.