당신의 잉여력, 지금 소중히 보관하고 있습니까?

Summary

항목	내용
장소	개롱
날짜	2018년 9월 8일(토요일)
시간	12시부터 20시까지

Motivation

Aurora Serverless가 출시 되었습니다. 이로써 대부분의 예전 서버 모델을 서버리스로 옮기는데 큰 무리가 없게 되었다고 봐도 과언이 아닙니다.

하지만 서버리스가 어떤 점이 더 나은지 고민이 부족한 것도 사실입니다. 따라서 기존 모델로 서버-클라이언트 구조의 서비스를 구축하고, 서버리스가 문제 해결에 어떻게 도움을 줄 수 있을 지 고민해봅시다.

Detail

다음을 만족하는 시스템을 개발합니다.

• 서버-클라이언트 모델이어야 합니다.
• 서버리스를 사용하지 않아야 합니다.
• 확장성은 생각만 하고 구현할 필요는 없습니다.
• 참가자들의 서버 사이에 서로 통신하여 동작할 수 있는 적어도 한 개 이상의 API point를 설계해야 합니다.
  • 때문에 개별/팀 참가자들은 자체적으로도 의미있는 수준의 서비스를 작성해야 하며,
  • 뿐만 아니라 다른 개별/팀 참가자들과도 의미있는 수준의 통신을 수행해야 합니다.
• 시스템은 게임이어도 좋습니다.

서버리스는 비용이나 확장성 측면에서 기존 개발 방법보다 더 유리하다고 알려져 있습니다. 그렇지만 이 구조는 필연적으로 microservice 구조를 따라가게 되고, 이 때문에 monolithic 구조와 비교했을 때 구현과 유지보수 비용 등이 증가한다고 알려져 있습니다.

따라서 본 대회에서는 최대한 서로 복잡하게 연동된 monolithic 서버 구조를 개발하고, 시스템의 유연성과 확장성 관점에서 서버리스가 문제를 어디까지 해결해 줄 수 있을 지 토론하고자 합니다.

서로 네트워크 통신을 진행해야 하는데 개롱 site의 네트워크는 상당히 취약합니다. 마침 monolithic 서버 구조를 개발하므로, 개별/팀 참가자들마다 aws m5.large ec2 instance 를 하나씩 지급할 예정입니다. 또한 개롱 site에는 적절한 presentation 도구가 없으므로, 적어도 *HDMI 단자를 지원하는 노트북- 혹은 그에 준하는 도구를 직접 준비해오시는 것을 권장합니다.

Schedule

본 대회는 *9월 8일(토요일)- 오후 동안 진행됩니다. 기다리는 다른 분들을 위하여 최대한 시간을 준수해주시기를 부탁 드리고 싶습니다.

시간	내용
12시-13시	점심 식사
13시-18시	대회 진행
18시-19시	결과 공유
19시-20시	저녁 식사, 토론

Participation

공간이 협소하기 때문에 on site 모임은 최대 10명 정도의 인원으로 제한하게 되는 점 양해 부탁 드립니다.
참가를 원한다면 Google Form에 이름과 연락처를 남겨주세요. 장소가 대단히 private한 관계로 이 쪽으로는 공개하지 않는 점도 양해 부탁 드립니다.

참가 신청은 9월 3일까지 받으므로 그 전까지 신청 부탁 드립니다.

Team

• 미리 팀을 구성해서 같이 신청을 해도 좋고
• 와서 팀을 구성해서 진행해도 좋고
• 아니면 1인 팀으로 진행해도 좋습니다.

원하는 가장 편한 방법을 택해서 진행하면 됩니다.

Result

GyroPlane (Airplane팀)

• https://github.com/kjyong1983/GyroPlane

<게임을 시작하자마자 추락을 시작하는 시점에서의 마지막 정상적인 카메라 앵글을 순간포착한 장면>

• 게임의 큰 틀은 잡힌 상태로 시작
• 휴대폰 자이로센서를 이용해 각자의 1인칭시점 비행기를 조종하고, 서로를 격추시켜 승리하는 게임
• 자이로센서가 입력이므로 도그파이트 상황에서 참여자가 모두 몸을 이리저리 비틀어야하는 점이 백미
• 네트워크 미들웨어로 Photon을 사용
• 클라이언트 구현 노트
  • 위에서 언급한 것처럼 빠른 시간내에 구현을 위해 자이로센서를 이용한 조작체계를 미리 잡아옴.
  • 서버 프로그래밍을 못하는 관계로 네트워킹은 모두 Photon에게 맡김
  • 유저가 게임을 켜면 자동으로 방으로 들어오고, 방이 없으면 하나 만들고 들어가서 전투하는 방식을 모두 Photon이 해줌
  • 간단하게 비행기의 가속과 감속, 총알 발사의 기능만 구현
  • 유니티의 자이로 센서는 Quaternion 값을 받아 쓰기 때문에 회전값을 파악하는데 머리가 아프다
• 서버 구현 노트
  • 다른 팀에서 사용할 공개 API로 두 가지를 계획: (1) 현재 플레이어 목록 및 점수, (2) 미사일 생성
  • Node.js를 이용해 프론트엔드 서버를 구축할 계획
  • Node.js - Photon 바인딩 라이브러리로 photon-node를 후보에 뒀으나, 여기의 photon은 그 Photon이 아닌 것으로 판명
  • 장시간 고민하다, 서버 역시 Unity로 작성하면 모든 문제가 눈녹듯이 사라진다는 사실이 번개처럼 뒷통수를 내려침
  • 초기 지급받았던 Ubuntu EC2 머신을 황급히 Windows EC2 머신으로 교체
  • 프론트엔드(HTTP 서버) - Unity - Photon Unity Network (PUN) 구조의 스택을 구현
  • 프론트엔드(HTTP 서버)는 uniwebserver의 것을 사용
  • 모든 구현은 C#
  • Photon 미들웨어를 배워서 쓸 시간이 없어서, 본 ‘서버’가 ‘서버’의 권한을 가지게 하는 방법을 제대로 배우지 못함
  • 즉, 다른 유저의 점수를 조회한다든지, 새로운 오브젝트(미사일)를 생성한다든지 하는 서버 권한의 작업을 어떻게 구현해야 할지 막막
  • 그냥 ‘권한’이란 개념을 없애고 보안상 문제가 아주 크겠지만, 모든 유저의 데이터와 미사일 생성 등을 공개 권한으로 하여, 문제 자체를 없애버림
  • 두 가지 API가 최종적으로 만들어짐
    • /players, /fireBullet
  • Windows 서버에 Unity 에디터를 설치하는 흔히 경험 못할 진귀한 일도 진행
  • 개발 과정 중, 동운의 DDOS 공격으로 개발 머신 블루스크린 경험
• 개인 소감
  • 거엽
    • 서버와 클라이언트가 모두 Unity라는 동일 엔진 위에서 돌아가니 만사가 편함
    • Photon 라이브러리는 무척 간단하게 쓸 수 있도록 잘 만들어짐
    • 다만, 너무 쉽게 만들어 둬서 그런지는 몰라도 첫 느낌은 성능상 오버헤드가 느껴짐 (실시간 동기화 랙)
    • 최종 결과물에 버그가 발생해서 모두가 함께 플레이해보지 못한 점은 무척 아쉬운 부분
  • 진용
    • 개발을 하는데 있어 유니티 PC 에디터와 안드로이드 플랫폼별로 작동이 제대로 먹히지 않았고
    • 개발용 디버그를 잘못 건드리는 바람에 결과물에 자이로 센서가 먹히지 않았던 부분은 매우 아쉬움
    • Photon을 처음 써봤지만 무척 쓰기 쉬웠다. 다만 아무리 쉽다고 해도 총알을 쏘는 것과 그것을 동기화하는 일은 그래도 어려움
    • 총알의 폭발 이펙트를 너무 무거운 것으로 넣어서 총알만 쏘면 폰이 멈추려고 함. 최적화가 필요함
    • 시간과 예산 부족으로 닉네임을 넣어서 화면에 띄우는 것과 RNG의 동기화에 실패함.

friendly-winner

Brumoval

모발계의 브루마블을 만들고 싶었다. 하지만 현실은… - lacti

• 기획
  • 장대한 김복치 유니버스의 일원으로, 요새 탈모가 늘어 이를 놀이로 승화시키고 싶었음
  • 브루마블의 맵 + 인생게임의 룰 + 모발 컨텐츠를 섞은 컨셉. 참여자는 각자 주사위를 던져 자신의 말을 이동시키고, 그 칸에서 벌어지는 이벤트에 의해 모발적 사건을 겪게 된다. 맵의 한 바퀴는 그의 대학, 구직, 결혼, 육아를 의미하는 기간이고 그는 과연 어떤 모발력으로 이것들을 헤쳐나갈 것인가!
• 개발
  • 간단한 서버/클라 모델로 개발할 계획이었고 serverless 금지이므로
    • 서버는 express로 api를 만들고
    • 클라는 react로 dom을 대충 구성해서 모바일에서도 바로 할 수 있게 만드려고 했음
  • 하지만,
    • 서버에서 모델 설계, 세션 관리 등의 기본 작업을 하는데에도 시간이 꽤 들어갔고
    • 클라는 react 자체도 익숙하지 않아 대부분 시간이 오래 걸리는데 게임 구성 요소를 html과 css로 responsive를 고민해서 구축하는게 간단하지 않음
    • 특히 그렇게 잘 구성한다고 해봤자 모바일에서 제대로 보일리가 없음
• 결론
  • 자주 사용하는 서버 구성 요소에 대해서는 미리 추상화를 해놓아서 라이브러리나 MSA 형태로 미리 구축해놓고 실제 대회 때에는 이를 적극 사용해보는 쪽을 해보면 좀 더 효율적인 개발을 할 수 있지 않을까 싶음.
  • 아니면 서버/클라를 동시에 개발한다는 것 자체가 시간상 무리일 수도 있겠음. 그냥 서버는 포기.
  • 클라는 react를 좀 더 연습하고, 어줍잖은 responsive 포기하고 타겟을 처음부터 정해놓는 것이 좋겠음.
  • 작다고 생각해도 실제 만들어보면 계속 시간이 부족함. 정말 더 작은 모델을 설계할 수 있도록 좀 더 익숙해져야겠음.