이번에 팀에서 코로나 원격의료와 관련한 정보 제공 앱을 만들게 되었다. 질병과 관련해서 형세가 급하게 흘러가다 보니, 원격 의료와 의약품 배달이 한시적으로 법적 제한이 풀리게 되었고, 원격 의료 및 의약품 배달을 실시하는 것에 대해서는 의료인들 자율적으로 따를 수 있게 했다. 해당 경험이 일반인들, 의료인들 모두 전무하다 보니, 프로세스에 대해서도 정부 지침 정도만 있고, 일반인들은 그 조차도 잘 모르는 게 현실이었다. 우리 팀은 PWA로 빠르게 해당 정보를 제공해주는 앱을 만들기로 결정했다

서버리스에서 VPC 내부로 배포하는 방법에 대해서 알아보려고 한다. 현재 진행 중인 프로젝트는 빠르고 간단하게 홍보용으로 만들고 있는 프로젝트라, 별다른 옵션 없이 퍼블릭하게 오픈된 API를 만들어놓고 개발 중이다. 그런데, 개발 서버를 분리해서 일정 기간동안 유지 보수 하면서 배포도 몇 번 더 해야 할 필요가 있어서 내부 VPC에 배포하는 방법을 확인해보려고 한다. 추가적으로, VPC 내부로 배포하게 되면 S3와 DynamoDB에 접근하기 위해 NAT Gateway 또는 VPC Endpoint를 만들어줘야 한다. 이번 글에서는 NAT Gateway를 설정해주는 걸 해볼 것이다.

깃헙에는 현재 백만이 넘는 도커파일들이 있다. 하지만 모든 도커파일들이 동일하지는 않다. 효율성은 중요한 것이고, 이번 블로그 시리즈는 도커파일의 다섯 가지 영역: 빌드 시간의 증가, 이미지의 사이즈, 유지성, 보안, 반복성에 있어서 베스트 프랙티스를 다룰 것이다. 만약 독자가 도커에 막 시작하는 사람이라면, 이 글은 독자를 위한 글이다! 이후 시리즈는 좀 더 Advanced한 주제가 될 것이다.

대부분의 웹 기반의 앱은 실제 서비스에서 개발자가 높은 트래픽에서 증가하는 워크로드를 처리할 능력을 더할 수 있게 하는 여러 컨테이너들을 사용하게 된다. 여러 도커파일을 사용하는 것은 개발자에게 어떻게 하나의 애플리케이션을 분할할 것인지를 결정하는 것을 돕고, 그러므로서 기능적인(함수적인) 집계가 동작할 수 있게 하지만, 개발자는 결정을 내리는 과정 중에 반드시 먼저 스스로에게 몇가지 질문들을 해야 한다.

개발자는 아마도 복수의 도커파일을 로드밸런서 앞단에서 동작하는 프론트앤드에서 작동하는 노드를 유저의 요청에 맞추기 위해 사용할 것이다. 하지만 개발자는 어떤 앱이 도커파일을 통해 이득을 얻을 수 있을지, 얼마나 많은 도커파일들이 각 애플리케이션에 필요한지, 그리고 개발자가 도커파일을 추적하는 과정을 취할 수 있는지와 같은 반드시 몇 요인들을 결정해야 한다.

현재 진행하고 있는 프로젝트에서는 크로나 현황을 간단하게 보여주는 섹션이 존재하는데, 이 부분을 누군가가 (API 형식으로다가?) 제공해주고 있는 것으로 알고 있었다. 그렇지만 아직 나온 건 없었고, 어쩔 수 없이 간단한 크롤러를 만들고 업데이트 해주기로 했다. 현재 프로젝트가 서버리스로 돌고 있기도 하고, Scheduled 된 작업을 돌리기 위해서는 람다가 적합하지 않을라나 싶어서 같은 서버리스 프로젝트에서 크론잡을 돌리는 함수를 만들어보기로 했다.