- 팀명: 고진감래
- 프로젝트 설명: 텔레그램과 같은 종단간 암호화(E2EE) 방식을 이용하는 채팅 서비스
- 팀원 노종빈, 20180891, 소프트웨어학부, 4학년 안시현, 20180502, 사회학과, 4학년 조동후, 20192248, 정보보안암호수학과, 3학년
- 프로젝트에서 팀원의 역할 노종빈 : 팀장, 백엔드, db관리 안시현 : Docker를 활용하여 애플리케이션을 컨테이너화, AWS 다양한 서비스 이용하여 배포, 백엔드 및 프론트엔드 간의 효율적 소통 구축, 최종 보고서 총괄 조동후 : 프론트엔드(App), 종단간 암호화(E2EE) 구현 프로세스 설계
-
효율적 자원관리
- vision - Docker를 활용한 채팅 시스템 관리: Docker를 사용하여 시스템을 쉽게 관리하고 확장하며 환경 간의 일관성을 유지
- scope - Docker 이미지를 작성하고 필요한 의존성 및 설정을 포함한다.
-
high - availability 시스템 만들기
- vision - aws의 기능을 활용하여 시스템의 availability를 높임
- scope
- Load-Balancer Architecture 구현 : load balancer architecture구현 ⇒ 채팅기능의 availability 상승
- Load-Balancer Architecture 구현 : load balancer architecture구현 ⇒ 채팅기능의 availability 상승
-
채팅 - 개인 채팅 및 그룹 채팅 가능
- vision - 실시간 커뮤니케이션: message broken architecture를 활용한 채팅 시스템 구현한다.
- scope
- 실시간 채팅 기능: 사용자는 실시간으로 채팅 메시지를 송수신한다.
- 메시지 브로커 구현: RabbitMQ 메시지 브로커를 사용하여 메시지 전파 및 처리를 구현한다. 컨슈머와 메시지 브로커간의 결합도가 높지만 현 프로젝트 규모에 맞게 트래픽이 작기 때문에 선택 예정이다.
- 개인채팅/그룹채팅 구분: 개인 채팅을 지원하기 위해 각 사용자는 고유한 식별자를 가진다. 채팅 메시지는 송신자와 수신자의 식별자를 사용하여 특정 대화 상대와 연결한다. 그룹채팅은 여러 사용자가 하나의 대화방에서 채팅하기 때문에 각 그룹 채팅은 고유한 식별자를 가진다.
-
종단간 암호화(E2EE)를 지원하는 개인 및 그룹 채팅 가능한 시스템 구현
- vision - 제3자로부터 채팅 내용을 보호하기 위해 채팅 시스템에 암호화를 적용한다.
- scope
- 종단간 암호화(End to End Encryption): 기존 암호화 방식은 서버에서 복호화되기 때문에, 내용 탈취 우려가 있다. 이를 방지하기 위해 단말기(Client)에서 암/복호화가 이루어지는 종단간 암호화를 적용한다.
- 하이브리드 암호 시스템: 대칭키 암호 시스템을 이용할 경우, 키 공유 등의 문제가 발생한다. 비대칭키 암호 시스템을 이용할 경우, 속도가 상대적으로 느리다는 문제가 발생한다. 따라서 대칭키와 비대칭키를 적절히 활용하여 장점을 극대화하는 하이브리드 암호 시스템을 사용하고자 한다.
-
단일 계층이 아닌 OSI layer의 여러 계층에서 보안 프로토콜을 이용하여 기밀성 보장 시스템 구현
- vision - 중간자 공격 등 제 3자의 위협을 방지하기 위해 OSI layer의 여러 계층에 암호화를 적용한다.
- scope
- 4 Layer: TLS 프로토콜 이용
- 7 Layer: HTTPS 프로토콜 이용
- UseCase Diagram
- 구현 부분: 채팅전송, 내용암호화, 채팅생성(개인,그룹), 채팅삭제(개인,그룹), 친구추가, 계정 정보 확인, 회원가입
- 미구현 부분: 사진전송, 파일전송,탈퇴,차단,
.png)
-
소프트웨어 시스템에 대한 개요 및 특성
-
Node.js
- 이벤트 기반: Node.js는 이벤트 기반 아키텍처를 이용. 이는 비동기적인 이벤트 처리를 통해 효율적인 넌블로킹 I/O 작업을 가능케 함.
- 실행 엔진: Node.js는 V8 JavaScript 엔진에서 실행됩니다. V8은 Google이 개발한 고성능 JavaScript 엔진으로, 빠른 코드 실행을 제공함.
- WebSocket: 채팅 서비스는 실시간 통신이 필수적인데, Node.js는 WebSocket과 같은 실시간 통신을 위한 기술을 지원. 실시간 업데이트를 쉽게 전송하고 수신할 수 있도록 도와주기 때문에 Node.js를 선택함.
-
AWS
-
<ec2 (Elastic Compute Cloud)>
- 가상화 기술 활용: 가상화를 통해 물리적 서버를 여러 개의 독립적인 가상 머신으로 분할함으로써 자원을 효율적으로 사용할 수 있음. 서버의 가상화를 통해 필요에 따라 가상 머신을 생성하고 크기를 조절할 수 있음.
- 유연한 스케일링: 필요에 따라 가상 서버의 수를 동적으로 조절할 수 있어서 필요 이상으로 많은 물리적 서버를 구입할 필요가 없음.
- 쓰지 않는 자원의 해제: EC2 인스턴스를 사용하여 필요한 만큼의 컴퓨팅 리소스를 구매하고, 필요 없어지면 인스턴스를 중지하거나 제거하여 비용을 절감할 수 있음.
- EC2 인스턴스 생성 및 관리: AWS EC2를 사용하면 필요에 따라 인스턴스를 생성하고 관리할 수 있어서 서비스의 확장성과 유연성이 향상
- EC2와 함께 다양한 AWS 서비스를 사용하여 서비스를 구성하고 최적화할 수 있는데 실제로 Amazon RDS를 사용하여 데이터베이스를 관리하고 Amazon S3를 사용하여 객체 스토리지를 활용할 수 있어서 소규모 팀프로젝트에 적합하다고 생각하였음.
-
<ELB (Elastic Load Balancer)>
- 다수의 서버에 대한 부하 분산: Chat service에서 다수의 사용자 및 다양한 기능을 처리하는데 로드 밸런서를 사용하여 서버 간 부하를 균등하게 분산시킬 수 있음. 이는 대량의 동시 접속이나 다수의 채팅 메시지를 처리할 때 효과적임.
- Health Check 활용: 로드 밸런서의 Health Check를 통해 사용 가능한 서버만에 트래픽을 분산함으로써 안정성을 확보. 채팅 서비스의 각 서버가 정상적으로 작동하는지 주기적으로 확인 가능함.
-
<RDS (Relational Database Service)>
- 다양한 DB 엔진 선택: Amazon RDS는 여러 가지 데이터베이스 엔진을 지원하며, Chat service의 요구 사항에 맞게 MySQL, PostgreSQL, 또는 Aurora와 같은 엔진을 선택하여 사용할 수 있음. 고진감래 팀은 MySQL 선택
- 자동 업데이트: RDS는 데이터베이스 엔진에 대한 패치 및 업데이트를 자동으로 관리해줌. 이는 보안 문제나 성능 향상을 위한 업데이트를 자동으로 적용하여 채팅 서비스가 최신 및 안정된 환경에서 운영될 수 있도록 함
- RDS AZ(Availability Zone)
- 데이터 보호를 위해서 db를 분산화 시킬 수 있음
- 자동백업, 실시간 복제, 자동 장애 복구를 통하여 가용성과 내결함성을 높임
-
docker
- 실행 환경의 용이성: 도커 컨테이너를 이용하여 호스트 운영체제나 환경에 관계없이 일관된 실행 환경을 제공
- 효율적인 자원환경: 가상 머신에 비해 가볍고 빠르게 컨테이너를 생성하고 시작. 공통된 커널을 공유하므로 더 적은 자원을 소비
- MongoDB
- 문서 지향적 저장: MongoDB의 문서 지향적인 구조는 채팅 메시지를 저장하기에 이상적임. 각 채팅 메시지를 MongoDB 콜렉션에 저장.
- **스키마의 유연성:**MongoDB의 유연한 스키마는 다양한 구조의 메시지를 저장할 수 있도록 함. 예를 들어, 그룹 채팅 메시지는 개인 메시지와는 다른 속성을 가질 수 있음.
- 빠른 검색을 위한 인덱스: MongoDB의 인덱스를 사용하여 채팅 메시지를 빠르게 검색. 타임스탬프, 발신자, 또는 채팅 방과 같은 필드에 인덱싱을 적용하여 쿼리 성능을 향상
- Rabbit MQ
- 오픈소스 메시지 브로커 소프트웨어
- AMQP(Advanced Message Queing Protocol) 지원
- 특징
- 메시지 지향
- AMQP 지원
- 큐와 메시지 라우팅
- 배달보장 (높은 신뢰선)
- 유연한 라우팅
- 클러스터링
- 플러그인 시스템
- 다양한 언어 및 프로토콜 지원
- 액세스 제어 및 보안
-
-
-
Software Architecture Style 을 가지고 있는 소프트웨어 시스템
- Telegram
- software architecture
- client-server model
- 클라이언트-서버 모델은 텔레그램의 아키텍처의 핵심이며, 여기서 클라이언트(사용자)는 텔레그램 서버와 상호 작용하여 메시지를 보내고 받습니다. 서버는 중간 매개체 역할을 하며, 클라이언트와 메시지를 중계하고 클라우드에 저장하여 전달될 때까지 보관합니다.
- P2P model
- 텔레그램은 또한 메시징 속도를 최적화하고 서버 부하를 감소시키기 위해 피어 투 피어 네트워크를 사용합니다. 두 클라이언트가 동일한 네트워크에 연결되어 있을 때 서버를 통하지 않고 직접 통신할 수 있습니다. 이로써 지연 시간이 감소하고 메시징 속도가 향상됩니다.\
- client-server model
- Security
- End - to -End Encryption
- 텔레그램은 종단 간 암호화를 사용하여 메시지를 가로채지 못하도록 보호하고 의도한 수신자만이 그 내용을 읽을 수 있도록 합니다. 이는 메시지가 발신자의 기기에서 암호화되고 수신자의 기기에서만 해독되며, 어떠한 제3자(텔레그램 자체를 포함하여)도 메시지 내용에 액세스할 수 없음을 의미합니다.
- End - to -End Encryption
- software architecture
- Telegram의 어떠한 부분(모듈, 서버, 서비스 등)을 사용했는지에 대하여
- client-server model을 이용하여 chat service 구현
- 종단 간 암호화를 통해 메시지의 안전성 보장
- HTTPS를 통한 통신은 데이터의 무결성과 기밀성을 강화하여 보안 수준을 높임
- Telegram
- 자신이 하는 작업의 FR 에 대한 Class Diagram
- NFR 에 대하여 고려하는 Quality Attributes 을 반영한 내용을 Class 에 설명 (양 식 활용)
- Architecture Driver (FR, QA 등) 에 대한 Tactics 을 반영 시 설명하기
Tactic1. Deployability
- 설명: 앱의 모든 구성 요소를 독립적인 도커 컨테이너로 패키징하여 각각의 컨테이너가 독립적으로 실행되고 확장될 수 있도록 함.
- 적용 방법: 서버는 도커 이미지로 패키징되며, 각 컨테이너는 필요에 따라 스케일링될 수 있음. 컨테이너는 운영체제의 종속성을 포함하므로 환경에 상관없이 일관되게 동작할 수 있음. Tactic 2: Availability
- 설명: 로드 밸런서는 클라이언트의 각 요청을 여러 서버로 분산하여 트래픽을 균형있게 분배함. 이로써 서버로 몰리는 트래픽을 효과적으로 분산함으로써 서비스의 성능을 향상시키고 부하를 분산시킴.
- 적용 방법: 클라이언트는 도메인에 대한 단일 엔드포인트(로드 밸런서 주소)를 통해 여러 서버에 연결할 수 있다. 로드 밸런서는 각 서버의 상태를 모니터링하고 새로운 요청을 받아들일 수 있는 서버로 트래픽을 분배함. 이때 서버는 필요에 따라 동적으로 추가될 수 있어야 함. Tactic 3: modifiability
- 설명: 소프트웨어를 모듈로 나누어 각 모듈이 독립적으로 개발 및 유지보수될 수 있도록 함. 모듈화된 코드는 특정 기능이나 책임을 담당하므로 해당 모듈을 수정하거나 업그레이드하는 데 다른 부분에 영향을 미치지 않음.
- 적용 방법: user, chat, chatroom 등 라우팅을 처리.새로운 채팅 관련 기능이 추가되거나 수정되더라도 한 모듈 안에서만 처리되면 됨.
- Deployment Diagram
- 비용 문제로 현재는 ec2 인스턴스 하나만 사용 (e1객체만 실행중)
- 시간 부족으로 sns, Aws elastic beanstock 구현 실패
- 비용문제로 Aws documment대신 mongodb atlats를 사용
- 시스템의FR특성과QA에따라서코드의주요부분을캡처하고결과화면캡처 하여 설명하기
- 종단간 암호화(E2EE) 채팅 서비스 제공
- 종단간 암호화를 적용한 채팅 서비스 구현으로 아래와 같은 FR과 QA를 충족한다.
- 텍스트 전송에 대한 요구 사항을 만족한다.
- 안전한 키 공유로 비밀 통신을 실현하여 **보안(Security), 신뢰성(Reliability)**을 제공한다.
- 키 생성을 위한 SEED 값으로 Hash 함수를 사용하며, 단말기 내 개인키가 변조되지 않는 공간에 보관되기 때문에 **무결성(Integrity)**을 제공한다.
- 종단간 암호화 프로세스를 요약하자면 아래와 같다.
- 회원가입 시 공개키/개인키 생성, 공개키는 서버, 개인키는 단말기에 저장
- 방 생성 시 비밀키 생성, 비밀키는 저장 후 상대방의 공개키로 비밀키를 암호화하여 서버 저장
- 각 사용자는 단말기에 저장한 개인키로 비밀키를 획득
- 안전하게 공유된 비밀키로 비밀 통신
- 본 프로젝트에서는 아래 이미지와 같이 종단간 암호화가 적용된 채팅 서비스를 제공한다.
- 종단간 암호화를 적용한 채팅 서비스 구현으로 아래와 같은 FR과 QA를 충족한다.
종단간 암호화를 위한 암호화/복호화 함수 구현
성공적으로 암호화 통신을 하고 있는 화면
종단간 암호화를 위한 키 생성 함수 구현
회원가입 시 최초 1회 암호키 생성
- 개인 채팅방 및 그룹 채팅방 생성
- 채팅방(1:1 채팅방, 단체 채팅방) 생성 서비스 구현으로 아래와 같은 FR과 QA를 충족한다.
- 개인 채팅방 생성, 그룹 채팅방 생성에 대한 요구 사항을 만족한다.
- 하나의 전체 채팅방이 아닌, 원하는 사용자만 초대하여 채팅 서비스를 이용할 수 있도록 **보안(Security)**을 제공한다.
- 채팅방 별로 채팅이 조회되며 관련 기능이 동작하기에, **성능(Performance), 사용성(Usability)**이 좋다.
- 채팅방을 쉽게 생성할 수 있으며, 다른 종류의 채팅방 필요 시 쉽게 추가할 수 있기 때문에 **확장성(Scalability)**이 좋다.
- 본 프로젝트에서는 아래 이미지와 같이 다양한 유형의 채팅방 생성 서비스를 제공한다.
- 채팅방(1:1 채팅방, 단체 채팅방) 생성 서비스 구현으로 아래와 같은 FR과 QA를 충족한다.
원하는 유형의 채팅방 생성 가능 화면
채팅방 생성 시 원하는 유저만 초대 가능
- 친구 추가 및 목록 조회
- 친구 추가 및 목록 조회 서비스 구현으로 아래와 같은 FR과 QA를 만족한다.
- 친구 추가에 대한 요구 사항을 만족한다.
- 친구에 대한 추가 정보 필요 시 추가할 수 있어 **확장성(Scalability)**이 좋다.
- 본 프로젝트에서는 아래 이미지와 같이 친구 추가 및 목록 조회 서비스를 제공한다.
- 친구 추가 및 목록 조회 서비스 구현으로 아래와 같은 FR과 QA를 만족한다.
친구 목록을 확인할 수 있는 화면
친구 추가를 할 수 있는 화면
-
RABBIT MQ와 socket io 를 사용한 채팅시스템 (서버)
- mongoDB 접속할때 메시지 큐에있는 data를 가져와서 업데이트하게 설정
- rabbitmq 설정 코드
- socket io를 활용한 채팅에서 데이터를 받고, 받은데이터를 rabbitmq로 전송
- 응답이느린 mongodb에 저장하는 내용은 Rabbitmq에게 맡기고 socket통신에 집중함
- 신뢰성을 높이고, mongodDB에 저장하는 부분을 분리 하기 편하게 만들어 확장성, 배포용이성을 높임
- mongoDB 접속할때 메시지 큐에있는 data를 가져와서 업데이트하게 설정
-
MVC 패턴을 적용해 확장성, 수정용이성 증가
-
docker를 이용한 deployment 증가
-
시스템 아키텍트로써 고려한 내용
- AWS 리소스 구성:
- 고려 사항: 어떤 AWS 서비스를 사용할지 고민함. 특정 요구 사항과 예산 제한을 고려해야 하기 때문임.
- 결론:
- 서비스의 규모에 따라 적절한 AWS 리소스를 선택함. 현재 서비스가 그리 크지 않기 때문에 여러 ec2를 사용하지는 않았지만 채팅 서비스가 커질수록 분산 서비스를 이용하는 게 맞다고 판단됨.
- 현재 실제 서비스중인 어플이아님, 또한 수익이날 수 없기때문에 최대한 비용을 적게 만들수 있도록 노력함
- 보안 및 개인정보 보호:
- 고려 사항: chat service는 보안이 핵심적이기 때문에 이에 대해 고민함.
- 결론: 종단간 암호화를 이용하여 사용자의 데이터를 보호하여 중간자 공격 및 불법 접근으로부터 안전을 제공.
- 서비스의 신뢰성
- 고려사항 : 사용자의 데이터, 활동이 누락되면 안됨
- 결론 :
- Message Queue, fault 및 error처리 복구에대한 방법을 세워 신뢰성을 높어야된다
ec2 성능의 문제로 container 여러개를 돌릴 수 없어 rabbitmq는 runtime에서 빠진상태
- AWS 리소스 구성:
-
참고문헌
- aws deployment diagram https://medium.com/@kachmarani/uml-deployment-diagram-in-modern-word-caee0a2ecaa3
- sns sqs https://aws.amazon.com/ko/blogs/architecture/best-practices-for-implementing-event-driven-architectures-in-your-organization/ https://channel.io/ko/blog/tech-backend-aws-sqs-introduction
- aws rabbitmq https://docs.aws.amazon.com/ko_kr/amazon-mq/latest/developer-guide/getting-started-rabbitmq.html
- aws eb https://catalog.us-east-1.prod.workshops.aws/workshops/3fd6c80b-39f2-4534-b69c-c400aed50c67/ko-KR/beanstalk/deploy-new-app
- Rabbit MQ 공식문서 https://www.rabbitmq.com/#features