Karzin Lab

Project.다원 Ensemble_내부망 구조(서버 도식화)

오늘은 제가 구현할 ERP Ensemble의 서버 구조를 간단하게 설계해 보았습니다.

이는 내부망 구조로, 웹 서버가 구축된 내부망에서만 사용이 가능하며,

외부에서 필요한 경우 VPN 접속을 열어 최대한으로 보안을 유지하기 위해서 설계를 했습니다.

 - 아래는 내부망 구조 (서버 도식화)

** 그림에 사용된 글자체는 네이버 나눔글꼴의 나눔스퀘어 Bold입니다.

** 상단 그림은 제가(Karzin) 직접 만들었으며, 필요한 픽토그램등의 작업도 직접 만든것임을 명시합니다.

** 상단 그림의 저작권은 Karzin에게 있음을 명시합니다.

- Ensemble는 위와 같은 구조로 개발이 진행 될 것입니다.

  -> 다만, 제게는 WEB, WAS, DB를 따로 두고 개발하진 못할것으로 보이며(테스트 서버의 부재), WEB/WAS/DB 서버를 하나로 합쳐서 테스트 할 것입니다.

-  WEB Server의 경우 Apache나 Nginx를 사용할 예정입니다.

  -> 이는 추후 변경가능성이 없지않아 있으며, 사실상 개발은 WAS단에서 이루어질 것이고, WEB서버는 사용자의 입맛에 맞추어 진행하는것으로 해볼 예정입니다.

  -> 다만, 제가 Apache나 Nginx 정도만 다뤄본 경험이 있어 추가적인 WEB Server에 대해서는 대응이 어려울 것으로 보여 Apache 혹은 Nginx를 Default로 잡았습니다.

- WAS Server의 경우 tomcat8을 타겟으로 잡고 진행합니다.

  -> 톰캣 외 WildFly (이전 JBoss)도 사용해보았지만, 저는 WAS는 아무래도 tomcat8이 좀 더 익숙하다 보니 tomcat8을 타겟으로 잡았습니다.

  -> 또한 tomcat은 APACHE 2 License를 따르고 있어 개인적 혹은 상업적 목적으로 사용할 수 있기 때문에(APACHE2 License를 포함시키고 아파치 소프트웨어 재단에 개발된 소프트웨어라는 것을 명확히 밝히기) 채택한 것도 큰 이유중 하나입니다.  

- DB Server의 경우 Master와 Slave를 나누어 사용합니다.

  -> Master는 CRUD 전반적인 입출력이 될 예정입니다.

  -> Slave의 경우 DBLink로 Master의 모든 테이블 및 데이터를 동일하게 복제할 예정이며, 이 복제된 데이터를 n일마다 새벽 2시(혹은 이외의 시간) 부터 Backup을 하여 Backup Storage로 Backup된 파일을 이동할 예정입니다.

    -->> Backup Data의 이동은 사람이 하는것이 아닌, Linux crontab(Shell Script)을 활용하여 옮길 예정입니다.

  -> Backup Storage의 경우 실제 물리적인 HDD를 따로 두어 Backup Data를 관리를 하던, Backup용 Server를 따로 구축하여 관리를 하는 형식으로 이루어질 예정입니다.

  * 저의 경우 어떠한 DB Data가 되었던 자신 혹은 회사 혹은 나라의 자산이라 생각하기 때문에 Backup을 굉장히 중요하다고 생각합니다. 따라서 가능하면 Backup에도 많은 공을 들일 예정입니다.

  -> WAS와 데이터를 주고 받을 시 중요한 데이터(Password 및 개인 정보 등)에 대해서 암호(encryption)/복호(decryption)화를 통해 주고받을 예정입니다.

  -> 또한 Master Server의 상태가 불안정할시 Slave Server로 변경하여 작업을 원할하게 진행할 수 있도록 개발할 생각입니다. (이는 추후 과제가 될예정)

  -> 사실 설계적인 부분에 있어서는 고민을 많이 했는데, 처음에는 Replication을 활용을 할까 고민을 많이 했습니다. (Insert/Update/Delete는 Master, Select는 Slave 형식의 분산처리) 다만, Replication을 활용할 만큼 엄청나게 많은 데이터가 오가지 않는다는 생각으로 설계를 했으므로, 추후 변경가능성이 다소 있습니다. (Ref1. DB를 DBLink가 아닌 Replication을 활용한 경우의 구조도)

- 내부망에 붙기 위해서는 VPN을 활용

  -> 요즘의 공유기는 날이 가면 갈수록 좋아집니다. 특히 VPN이 지원될 정도로 말이죠. (적어도 제가 사용중인 iptime의 경우 지원하고 있습니다.)

  -> 최대한 외부로의 포트를 막고 내부에서만 작업을 하게끔 하고 있으며, 외부에서 작업이 필요한 경우 VPN을 통해 접속을 할 수 있도록 생각하고있습니다.

- Client

  -> 최대한 모든 Web Browser를 지원할 예정입니다. (시간이 걸리더라도)

  -> Front단을 Bootstrap을 이용하여 개발하여 PC, 모바일, 태블릿 등 OS에 상관없이 수많은 플랫폼에서 지원이 가능하며, Ensemble의 개발이 어느정도 진척이 이루어지면 Application(Android, iOS)을 제작하여 Ensemble의 장비관리 파트에 붙여서 사용할 예정입니다.

    -->> 장비관리 파트의 대략적인 기능으로는

          1. 모바일 등에서 장비촬영,

          2. 촬영된 장비를 등록 및 관리,

          3. 장비 상태에 따른 불용 및 폐기 처리 등을 지원하도록 할 예정입니다.

Ref1. DB를 DBLink가 아닌 Replication을 활용한 경우의 구조도

** 그림에 사용된 글자체는 네이버 나눔글꼴의 나눔스퀘어 Bold입니다.

** 상단 그림은 제가(Karzin) 직접 만들었으며, 필요한 픽토그램등의 작업도 직접 만든것임을 명시합니다.

** 상단 그림의 저작권은 Karzin에게 있음을 명시합니다.

버전정보 (v1.1)

 - v1.0 2020.06.16 배포

 - v1.1 2020.06.16 Ref1. 추가 (Replication의 활용 구조도 그림 추가)

* 저작권에 위반될 수 있는 컨텐츠(이미지, 동영상 등)나 게시글은 삭제되거나 수정될 수 있습니다.

* 문제의 여지가 될 수 있는 컨텐츠의 경우 댓글 달아 주시면 빠른 시일 내에 조치하도록 하겠습니다.

Project.다원은 개인(karzin)이 기획, 분석, 설계, 디자인, 개발, 유지보수 등

모든 부분을 혼자 맡아 진행하는 개인 프로젝트입니다.

Project.다원 Ensemble

Karzin

abbeea@naver.com

오늘은 Project [다원]을 정리하는 시간을 갖도록 하겠습니다.

가끔씩 물어보는 분들이 계십니다. [다원]이란게 뭐냐?

별다른 의미는 없어요 ㅎㅎ 그냥 프로젝트 명을 정하기 힘들어하다가 우리말이었으면 좋겠다는 생각에 여기저기 찾아보다가 다원이라는 우리말이 너무 맘에 들어 사용하게 되었습니다.

그래도 굳이, 왜 [다원]일까? 싶은데, 제가 생각하기로는 모두가 다 원하기도하고, 사랑하는 프로젝트가 되었으면 해서 사용한것도 이유중 하나가 될 것 같습니다.

[다원]이라는 말은 순 우리말로,

다원 - 모두가 다 원하는, 모두가 다 사랑하는 사람

이라는 의미를 가지고 있습니다.

자, 그럼 [다원] 프로젝트 내에 있는 항목들을 살펴 보도록 하겠습니다.

- 다원 ERP (Core - java)

- 다원 원격 마우스 (Android)

- 다원 원격 키보드 (Android)

- 다원 원격 키보드 & 마우스 (Android)

- 다원 PPT 원격 리모콘 (Android)

- 다원 영상편집 (iOS)

6가지의 항목이 있습니다. 앞으로 계속해서 추가될 예정입니다만, 몇가지는 병합되거나, 사라질 수 있음을 미리 공지해드립니다.

참고로 [다원]은 개인 프로젝트입니다. 저 혼자 진행하고 있는 만큼 진행속도가 많이 더딜수 있습니다.

그럼, 하나씩 살펴보도록 하겠습니다.

 - 다원 ERP : ERP Core를 만들고 있습니다. java로 만드는 만큼 Spring등에서 활용이 되도록 할 예정입니다.

 - 다원 원격 마우스 : 오래된 스마트폰 등을 마우스로 사용하면 어떨까 싶어 진행중인 프로젝트중 하나입니다. Android로 제작 후 시간이 될 때 iOS도 지원할 예정입니다.

 - 다원 원격 키보드 : 마우스와 마찬가지로 키보드만 지원되게할 예정입니다.

 - 다원 원격 키보드 & 마우스 : 상단의 두 항목과 합칠까 고민하고 있으며, 키보드와 마우스를 복합적으로 사용할 수 있는 어플을 생각하고 있습니다.

 - 다원 PPT 원격 리모콘 : 가끔 PPT를 이용하여 발표를 할 때가 많은데, 이럴때 스마트폰을 이용하면 어떨까 싶더라구요. 그래서 진행중인 항목입니다. 물론 Android를 먼저 제작한 후 이후에 시간이 될 때 iOS도 지원할 예정입니다.

 - 다원 영상편집(iOS) : iOS에서 기본적으로 지원하는 라이브러리가 괜찮은게 많은거 같아 무료로 제작할 예정입니다.

추가로 문의사항이 있으면 댓글을 달아주시면 감사하겠습니다^^

하나의 프로젝트를 완성하기 위해서는 좋은 설계가 필요하다. 그를 위해선 여러가지 카테고리를 나눠 보고서를 작성해두는 것이 좋은 방법이지만, 설계를 뛰어넘고 바로 개발로 넘어가는 경우가 허다하다. (귀찮기도하고..)

오늘은 대학을 졸업하고도 잊지 않기 위해 보고서에 들어가야할 내용들을 메모해놓기로 했다.

물론 개인적인 생각으로 정리된 부분들이지만, 대학졸업작품 보고서에도(컴공과등) 해당형식을 맞춰준다면 좋아하실 교수님들이 꽤나 있을것이다.(아마..도..? 맞겠죠..?) 그래도 워낙 각 교수님들이 성격들이 다르시다보니.. 원하시고 추구하시는것도 다르시기에 그냥 참고만 했으면 좋겠다.

1. 제대로 된 Project명과 개발프로그램의 명칭.
예) Projcet.다원, app명:runplay

2. 개발 내용 : 이 프로그램은 무엇을 하는것인데 무엇을 하기위해서 어떠한 개발을 할것인지에 대한 내용.

3. 개발 동기 : 이 프로젝트를 개발하게 된 동기가 무엇인지

4. 개발 목표 : 이 프로젝트를 개발할때의 목표.

5. 기대 효과 : 해당 프로젝트를 진행하면 어떠한형식의 효과를 볼수 있는지.

6. 벤치 마킹(중요) : 벤치마킹을 무척이나 헐겁게 볼 수도 있는데, 자세히보면 벤치마킹안에는 다른 프로그램과 내가 만들 프로그램을 비교하면서 어떤 부분을 강점으로세우고 어떤부분을 지워서 해당프로그램을 조금 더 좋게 만들지를 뚜렷하게 들어나게 해준다. 자기가 무언가를 만든다고 생각을 하면 그것에따라 어떠한 형식으로 만들지 생각하기 전에 벤치마킹을 해두는것이 중요하다. 자신의 프로그램을 조금 더 좋게 만드는 하나의 방법이라고 생각한다.

7. 특징 및 장점 : 해당 프로그램의 특징과 장점. 어떠한 형식의 특징이 있으며 장점이 있는지. (물론 단점을 마구 얘기하진않겠지만..)

8. 문제설명서 : 사실 문제설명서라고하면 문제를 설명한다 라는의미에서 안좋게 받아들일 수 있는데 사실, 그게 아니고, 이 프로그램에 대한 설명이라고 보면되겠다. 쉽게 말해 설명서? 같은건데.. 해당은 나중에 기회가 되면 다시한번 더 자세히 다뤄보도록...

9. UI : 꼭 UI가 아니어도 좋다. 개발직전의 WireFrame을 보여줘도 되는데, 해당은 개발단계 거의 바로직전에 어떠한 형식으로 개발이 될지 틀을 잡아주기때문에 꼭 있어야하는 부분이다. 물론 설계에 있어 모든부분이 필요하겠지만, UI(WireFrame)같은 경우 설계를 잘해두면 나중에 개발할시에 시간을 단축시켜주기 때문에 디자이너와 잘 연계해서 설계해두면 편하다고 볼 수 있다.

10. 요구사항분석 : 자신의 프로그램에 필요한 요구사항들을 모아놓는것으로, 쉽게말해 어떤 기능들이 필요한지 모두 짜집기하는 부분이다. 해당이 있어야 함수등의 개발시에 어려움없이 조금이라도 더 쉽게 설계하여 개발할 수 있다.

11. 여러 다이어그램 : 해당은 자신이 무슨프로그램을 개발하느냐에 따라 제작해야하는 다이어그램이 조금씩 달라지는데, 내가 자주사용하는 다이어그램은 클래스 및 시퀀스 다이어그램이다. 

 - 클래스다이어그램 같은 경우 개발에 있어 어디 클래스에 어떠한 함수가 제작되어야하는 지를 명확하게 해주기때문에 설계단계에서 제대로 해줘야 개발시에 함수작성시에도 쉽고 편하게 개발할 수 있다.
 - 시퀀스다이어그램은 각 클래스나 함수에서 어떠한 형식으로 타임을 할당하고 실행이 되는지를 나타내는데 시퀀스 다이어그램을 제작하다보면 자신이 만들 프로그램에 대해서 좀더 체계적으로 개발할 수 있다고 볼 수 있다. (편하게 개발하는것과 체계적으로 개발하는것과는 전혀 다른차이. 꼭 알아둬야한다.)
 - ER다이어그램은 DB연동시에 꼭 필요한 부분이다. 프로그램에 DB가 들어가는데 ER다이어그램이 없다는건 개발을 할 마음이 없다는거다. 간략하게라도 ER다이어그램은 꼭 있어야하며, 추가적인 다이어그램은 추후에 기회가되면 설명하도록 하자.

12. 추가예정사항 : 자신이 프로그램을 만들고(혹은 런칭을 하고) 기능을 어떤것들을 추가할지를 작성한다. 주로는 프로그램을 업데이트를 하면서 어떤기능이 추가될지에 대해서를 작성.

13. 부록 : 해당 프로그램을 작성하면서 처음다루는 사람들을 상정해서 몇가지의 단어들이나, UI에 대해 짤막하게 정리해두면 좋다.

14. 여기서부터는 어플이나 웹프로그래밍등에 필요한 부분인데, 어쩌면 꼭 필요한 부분은 아니지만 알아두면 좋은 부분이다.
 - SITEMAP : 홈페이지나 어플을 작성할때 어떤식으로 각 액티비티들을 연결하고 연결이 될지가 나와있는 부분이다. 홈페이지 및 어플을 작성할때 꼭 필요한 부분.
 - Persona : 해당 홈페이지 및 어플을 이용하기 위한 가상의 인물을 만든다.
 - Context Scenario : 위 페르소나에 연동되는 부분 중 한부분으로, 가상의 인물이 자신이 개발할 홈페이지 및 어플을 어떠한 형식으로 이용하게 되었고 어떠한 느낌을 받았는지를 작성하는 부분이다.
위 두가지 경우에는 해당 어플 혹은 홈페이지를 어떠한 사용자가 사용할지 주요 타게팅을 잡을때 매우 편리하다.

15. 추가 : 벤치마킹을 할때에 홈페이지나 어플의 경우 Jacob Nielson's Heuristic Evaluation을 이용해 작성하면 매우 편리하다.
 - 1. Visibility of system status (사용자에게 시스템의 현재 상태를 시각화하여 보여준다.)
 - 2. Match between system and the real world (현실세계와 부합되도록 시스템을 설계한다.)
 - 3. User control and freedom (사용자에게 적절한 통제권을 부여한다.)
 - 4. Consistency and standards (일관성과 표준성을 높인다.)
 - 5. Error prevention (사용자의 실수를 미연에 방지할 수 있도록 설계한다.)
 - 6. Recognition rather than recall (사용자가 적은 인지적 노력으로 시스템을 사용할 수 있게 한다.)
 - 7. Flexibility and efficiency of use (사용자가 시스템을 유연하게 사용할 수 있도록 한다.)
 - 8. Aesthetic and minimalist design (심미적이고 간결한 시스템 디자인을 제공한다.)
 - 9. Help users recognize, Diagnose, and recover from errors (에러 발생시 사용자 스스로 문제를 파악하고 수정할 수 있도록 설계한다.)
 - 10. Help and documentation (사용자에게 충분한 도움말을 제공한다.)
또한 해당에 대한 평가가 따로 4가지로 나뉘어 존재하는데 해당은 나중에 기회가 된다면 추가하는걸로..

16. 개발기간 : 개발기간은 꼭 필요하다. 언제부터 언제까지 어떠한 기능을 구현하고 결국 언제 완성을 할것인지. 꼭 있어야하는부분. 이부분이 없다면 개발자들은 헤이하게 멍때리고 있을지도..(웃음)

17. 시연의 경우 있어도 되고 없어도 되지만 있으면 좋은게 해당 프로그램을 어떠한형식으로 실행하는지 타인들에게 좀더 이해력 높게 보여주기위해 있으면 좋다.

>> 사실 졸업작품을 개발할때 부랴부랴하느라 클래스도그렇고 함수들도그렇고 여기있을게 저기있고등등 아주 뒤죽박죽이다. 100점을 기준으로한다면 0점..
역시 개발은 설계를 확실하게 잡아두고 진전을해야 괜찮은 프로그램이 나온다고 생각할 수 있다. 다음부터는 꼭 설계를 착실하게하고 개발을 할 수 있도록 해야겠다.
기회가 된다면 뒤죽박죽으로 짜여진 졸업작품을 조금 더 다듬어보는것도 내 실력을 향상시킬 좋은 기회가 될 것 같다.