발자취

개요 개발 경험이 많고 Heroku 플랫폼을 운영한 사람들이 정리한 규칙이다. 현대의 클라우드 애플리케이션 (SaaS)을 효율적으로 운영하기 위한 개발 규칙이다. 주요 내용 1. Codebase 코드베이스와 앱은 일대일 상관관계가 있다. → 코드는 한곳에서 개발 및 배포되어야 한다. 코드베이스가 여러개인 경우 → 분산 시스템으로 간주한다. 각각의 코드베이스는 12 factor를 준수한다. 여러앱이 동일한 코드를 공유하는경우 → 12 factor를 위반한 경우이다. 공유되는 코드를 라이브러리화 하고 각 앱에 종속성을 주입한다. 앱 배포가 여러개인경우 → branch를 활용하여 배포 분리 2. Dependencies 애플리케이션은 전체 패키지의 암묵적인 존재에 절대 의존하지 않는다. 애플리케이션의 모든 종속..

일반적인 웹(서버) 애플리케이션을 배포할 때는 외부에 보여지는 계층(80, 443포트)을 제외하고 다른 외부 출입은 다 막아버린다. 이 때 만약 개발자가 외부에서 직접 애플리케이션에 접속해야 할 때는 Bastion(배스쳔) 호스트를 통해서 접속한다. 애플리케이션 구조 먼저 실행되는 애플리케이션은 프라이빗 서브넷에 있다고 가정하자. 프라이빗 서브넷의 애플리케이션은 일반적으로 외부에서 접속하지 못한다. 하지만 ssh연결을 해야 할 경우에는, 퍼블릭 서브넷에 있는 배스쳔 호스트를 통해서 애플리케이션으로 접속한다. ssh 터널링이다. 그림으로 그리게 되면 다음과 같다. 아마존 ec2 인스턴스는 공개키를 사용해서 인스턴스에 접속하는 방식을 기본적으로 채택하고 있다. ssh에 pem파일을 태워서 접속하면 된다. 이..

최근들어 클라우드 관련한 아키텍쳐를 설계할 일이 생겼는데, 아키텍쳐를 설계할 때 마다 전체적인 구성이 그려지지 않는다는 생각이 너무 들었다. 그래서 전체적인 흐름을 알 수 있는 방법에 대해서 알아보다가 AWS에서 운영하는 자격증 시스템이 있어서 확인해 봤다. 내 수준에 적합한 자격증으로 SAA자격증이 있는거 같아서, 한번 따 보기로 했다. AWS 자격증 종류 사실 공홈이 잘 정리가 되어있다. https://aws.amazon.com/ko/certification/exams/ 모든 AWS Certification 시험 살펴보기 | AWS 클라우드 기술 검증 | AWS 언어: 영어, 프랑스어(프랑스), 독일어, 인도네시아어, 이탈리아어, 일본어, 한국어, 포르투갈어(브라질), 중국어 간체, 스페인어(라틴 아..

주말에 잠깐 시간내서 통관번호를 사용해서 택배를 조회하는 어플을 만들어 보았다. 몇년전에 안드로이드 스튜디오를 사용해서 꾸역꾸역 만들던 때와는 달리 요즘에는 빨리빨리 만들 수 있어서 좋았다. 제작기를 작성하긴 하는데, 사실 공식 문서만 보고 개발환경을 잘 설치하고 react를 어느정도 사용할 줄 안다면 단순한 웹 통신과 뷰만 있다고 하면 쉽게 제작할 수 있어서 간단히 설명만 할려고 한다. 기술스택 기술스택이라 하기에도 민망하다. React Native를 사용해서 만들어 보았다. 이미 React를 다룰 줄은 알기도 하고, 크로스 플랫폼이 가능해서 사용하기로 했다. 또한 Typescript를 사용해서 타입에 안정성을 주기로 했다. 하지만 막상 다 만들고 보니 별로 사용하지는 않았다는 게 함정... 개발환경은..

현재 풀스택 개인 프로젝트를 준비하고 있다. 어플리케이션 기반의 커뮤니티 앱이다. 서버와 어드민 페이지까지 만든 다음에 애플리케이션과 연결할 예정이다. 프로젝트의 목표는 다음과 같다. 개인 공부가 목표이다. 어드민 페이지를 통해 유저 관리가 되어야 한다. 앱스토어와 플레이스토어에 출시가 되어야 한다. Fcm을 통해 푸시 메시지를 제어한다. 앱에 공지사항과 강제 업데이트 같은 관리자가 외부에서 제어할 수단이 있어야 한다. 해당 목표를 이루기 위해서 기술스택을 찾고, 현재 제작 중이다. 백엔드 : NestJS : Typescript 기반으로 빠르게 작성하고 테스트가 가능하고 익숙함 ORM : Typeorm : 가장 많이 사용하고, 나중에 확장할 때 빠르게 할수 있다. DB : Postgres : 오픈소스, ..

최근에 ERD를 작성할 일이 생겼는데, ERD 툴을 새로 사용하자니 매우 귀찮은 생각이 들었다. Markdown처럼 ERD도 코드 형식으로 사용할 수 있게 하면 좋겠다는 생각이 들어서 여기저기 찾아보다가, mermaid라는 좋은 오픈소스 프로그램을 발견했다. 문법도 비교적 쉬운 편에 속해서 빨리 익힐 수 있었다. 공식 홈페이지는 다음 주소에 있다. https://mermaid.js.org/ 빠른 사용법 공식 홈페이지를 보면 텍스트와 코드를 사용해서 시각화를 빠르게 할 수 있는 툴 이라고 광고한다. 기본적인 문법은 Markdown을 많이 참고했고, 기본 목표는 ERD가 아닌 다이어그램을 표시하는 것이 원래 목적이다. 여기서 응용하여 마인드맵, 타임라인, ERD, 파이 차트 등의 다양한 작업에 활용할 수 있..

현재 프로젝트에서 docker image안에 azure cil을 설치하고, 해당 프로그램에 인자로 key값을 받는 작업을 수행했다. azure는 aws와 다르게 cli로 로그인 하기 위해서는 거의 무조건 web으로 연결해야 하는 로직이 있었다. oauth2를 사용해서 보안 강화에 초점을 맞춘 것 같다. 여하튼 해당 플로우를 구현하기 위해서 방법을 찾아봤는데, aws와 다른점이 있어서 방법을 찾을때 약간 고생좀 했다. 구현하기 기존의 로그인 플로우를 확인하면 다음과 같다. az login 실행 (--use-device-code 도 비슷한 플로우) 웹사이트 오픈 로그인 인증 후 cli로 전환 로그인 완료 여기서 웹사이트를 오픈하는 과정 자체가 보안에는 좋을지 몰라도 사용성에서는 상당히 별로인 것 같아 보였다..

현재 AKS에 NestJS 파드를 올려야 하는 상황이다. 분명히 네트워크 엔드포인트 잘 맞추고, 서비스 잘 올렸는데 자꾸 백엔드에서 DB에 접속을 하지 못하는 이슈가 있었다. 현재 이 상황에서 내가 해본 것들은 다음과 같다. Service 포트 확인하기 Deployment, Service 라벨 확인하기 Pod에 접속해서 curl 날려서 DB 연결 확인하기 Azure 가상 머신에 접속하여 이미지 빌드 후 푸시하기 원격 저장소에 있는 이전 이미지 배포하기(이건 잘됨) 클러스터 처음부터 다시 만들기 CNI 설정 처음부터 다시하기 이정도의 엄청난 삽질을 하고 있었다...그런데 CRI에 대해서 한번 확인해 보라고 주변 분께서 제안해 보셨다. 그래서 CRI에 대해서 잠깐 알아본 이후 바로 확인해 보았다. CRI C..

쿠버네티스는 컨테이너 애플리케이션을 제어할 수 있는 컨테이너 오케스트레이션 프로그램 중 하나이다. 현재 컨테이너 오케스트레이션 도구 중에서 독보적인 위치를 지니고 있으며, MSA를 사용하는 기업들은 거의 다 쿠버네티스를 사용하고 있다. 쿠버네티스는 각 컨테이너를 다루는 도구이므로, 당연히 그와 관련된 네트워크 설정들이 있을 것이다. 쿠버네티스에서 기본적으로 제공하는 네트워크에 대해서 간단히 알아보자. 쿠버네티스의 기본 네트워크 쿠버네티스의 구조에 대해서 간단히 알아보자. 쿠버네티스의 가장 작은 단위는 파드이다. 한 개의 도커 컨테이너라고 보면 된다. 파드들을 관리하는 상위 단위는 노드이다. 노드는 한 대의 pc라고 생각하면 된다. 이러한 노드들을 관리하는 것이 쿠버네티스 클러스터이다. 그림으로 보면 다음..

이번에 회사에서 terraform을 사용해서 간단히 정리해 보았다. Terraform이란 클라우드, 온프레미스 리소스들을 코드로 정의할 수 있는 도구이다. 컴퓨팅 리소스, 스토리지, 네트워킹 리소스, DNS, SaaS 등의 다양한 구성 용소를 코드로 정의할 수도 있다. 테라폼 API를 통해서 앞에서 말한 리소스들을 지정할 수 있다. 코드로 정의하기 때문에 기존의 코드를 작성하는 것처럼 협업이 가능하고 버전 관리가 용이하다. 테라폼의 워크플로에는 주로 3개의 단계가 있다. 먼저 코드를 작성하는 write 단계가 있다. 말 그대로 리소스를 코드로 작성한다. 두 번쨰는 plan이다. 기존에 있던 인프라를 기반으로 이후 변화될 계획을 구상한다. 구상하는 과정은 테라폼 자체적으로 알아서 순서를 정한다. 마지막으로..