이젠 정말 클라우드 뿐이야

Lambda가 Secrets Manager에 접근해야 할 일이 있습니다.해당 Lambda는 private db에 접근하기 위해 db와 동일한 vpc에 생성되어 있습니다. 즉, 람다는 private db에도 접근해야하고, Secrets Manager에도 접근해야하는거죠그러나 Secrets Manager는 VPC 외부에 존재하기 때문에 Lambda의 입장에선 인터넷 통신이 필요한 상황입니다. Lambda가 VPC에 생성되는 순간 인터넷 통신은 끊기기 때문에, 프라이빗하게 있어도 외부와 통신이 가능한 NAT Gateway를 만들기도 합니다.그러나 Secrets Manager는 외부 서비스가 아니라 AWS 내부의 서비스인 만큼, NAT gateway를 만들어서 외부를 통하지 않고서도 통신할 수 있는 방법이 있습..

GCP에서 도메인을 하나 구매했습니다.그리고 웹은 AWS에 배포가 되어있는 상태입니다. aaa.com이라고 하는 도메인이라고 가정해봅시다.그런데 이건 최상위 도메인이고, 제가 만드는 웹은 bbb.aaa.com이라는 하위 도메인에 연결을 하고싶습니다. 이 때 어떻게 할 수 있을까요? 우선 bbb.aaa.com이라고 하는 하위 도메인에 대한 hosted zone을 AWS Route53에서 생성합니다. 그리고나면 여기서 Create record를 클릭하고 A 혹은 CNAME을 추가해주어야 하는데요,보통 bbb.aaa.com과 www.bbb.aaa.com을 설정합니다. 여기서 A를 설정한다 라고 한다면, 사용자가 bbb.aaa.com으로 접속했을 때 redirect할 ip주소를 입력해야하고,CNAME을 설정..

원래는 Azure를 쓰려고 했으나,처음 써보는거기도 하고 설정값이나 리소스들을 사용하는게 너무 불편해서 AWS로 옮겼습니다. 지금 프로젝트가 혼자서 하는게 아니라 마감기한이 정해져있는 것이기때문에,Azure나 GCP를 써보는거는 나중에 혼자서 해보는게 좋을 것 같습니다. 우선 AWS S3 버킷에 build 요소들을 집어넣습니다. 그 전에, 버킷을 생성할 때 '공개 액세스 제한'은 모두 풀어주셔야 합니다. 그래야 웹에서 접근이 가능합니다.-> S3에서 직접 웹을 호스팅할 때는 그런 것으로 알고있는데, AWS Amplify를 활용하실거라면 굳이 풀어주지 않으셔도 되는 것으로 알고있습니다. 그리고 버킷의 properties로 들어와서 맨 밑으로 내리면, Static website hosting이라는게 있습니..

잘 모르겠는 내용은 아래 공식문서를 참고하며 작성했습니다: https://learn.microsoft.com/en-us/azure/azure-sql/database/connect-query-portal?view=azuresql Query SQL Database with Query Editor in the Azure Portal - Azure SQL DatabaseLearn how to connect to an Azure SQL database and use the Azure portal query editor (preview) to run Transact-SQL (T-SQL) queries.learn.microsoft.com Public Access 허용Azure 웹 콘솔에서 쿼리를 날리기 위해서는 Qu..

Azure는 다른 클라우드 기업과는 다르게 약간은 복잡한 클라우드 구조를 가지고 있습니다. 더 정확히 말하자면, 클라우드 리소스를 더욱 세부적이고 체계적으로 관리할 수 있도록 리소스를 그룹화하고 관리할 수 있는 기능이 있는건데이걸 처음 마주하는 사람 입장에서는 꽤나 어렵고 헷갈립니다 이걸 전체적으로 한번 다뤄보고자 합니다. Tenant---테넌트 라고 읽습니다.하나의 마스터 계정이 만들 수 있는 조직 단위라고 생각해주시면 될 것 같습니다. 즉, 하나의 마스터 계정이 '마이크로소프트'라고 하는 기업이 사용하는 모든 클라우드에 접근할 수 있습니다.이 '마이크로소프트'라고 하는 기업 아래에 'Office365 부서', 'Copilot 부서' 와 같은 부서들이 사용하는 별도의 클라우드가 있을 수 있습니다.이 때..

DB를 설계할 때가 왔습니다.DB를 설계할 때 고려한 사항은 아래와 같습니다:관계형 데이터베이스일 것제가 저장할 데이터들은 텍스트 데이터밖에 없으며, 하나의 데이터를 이곳저곳에 활용할 일이 많으며 다양한 방식의 조인과 집계가 진행될 예정입니다.여러 엔티티 간 관계가 이미 정해져있고 바뀌지 않습니다.모든 데이터는 암호화될 것계정 정보(이름, 이메일)을 제외하고는 모든 정보는 암호화할 예정입니다.사용자가 자유롭게 텍스트를 입력할 수 있기 때문에 혹시 모를 개인정보 침해를 방지하고자 합니다.물론, 문제가 발생할 경우 해당 데이터를 복호화하여 살펴볼 수 있도록 설정할겁니다.접근 제어 기능이 있을 것유료 사용자 여부에 따라, 등급에 따라 접근 가능한 기능, 혹은 기능에 접근할 수 있는 횟수에 제한을 둘 예정입니다..

Azure를 활용해 프로젝트를 하나 진행하고 있습니다.먼저 로그인 기능부터 구현해야 하는데,직접 백엔드를 구성하기보다는 소셜로그인을 Azure를 활용하여 구성할 계획입니다.Microsoft AD B2C라는 서비스가 있긴 하지만, 해당 서비스는 곧 종료 예정입니다. Microsoft Azure Entra External ID를 사용하는게 최신 방법입니다.이를 위해 "External Tenant"라고 하는 것을 만들어야 합니다.테넌트 (Tenant)란?---Tenant란 Azure에서 사용하는 하나의 Organization을 의미합니다. 테넌트가 하나의 조직을 나타내고,해당 테넌트 안에 생성된 여러 Subscription이 각자 독립된 비용 부과를 가지게 됩니다.즉, 하나의 큰 조직으로 Tenant를 만들어..

Session Affinity가 뭔가요?A/B테스트를 진행한다고 해봅시다.A와 B에 각각 들어가있는 기능들이 다를텐데, 사용자가 새로고침을 진행할 때마다 A에 들어갔다가, B에 들어갔다가 하면 앱에 일관성이 없어집니다. 이는 곧 나쁜 사용자 경험으로 이어지고, 회사 입장에서도 데이터를 수집할 때 제대로 된 수집이 불가능할 수 있습니다. 그래서 Istio에서는 Cookie, Header, SourceIP와 같은 값들을 hashing합니다.해싱하게 되면 같은 쿠키/헤더/ip는 항상 같은 해시값을 가지게 되므로똑같은 해시값은 똑같은 경로로 라우팅을 해주면 사용자 입장에서는 A에 고정, B에 고정됩니다. 이를 Session Affinity 라고 합니다. Session Affinity 구현하기*Session Af..

서비스 메시는 크게 두 개의 컴포넌트로 구성됩니다.Data Plane, 그리고 Control Plane입니다. Data Plane데이터 플레인은 proxy 네트워크로 구성됩니다.위의 구상도를 보면 Instance 아래에 Sidecar Proxy가 존재하는데, 하나의 pod 안에 서비스 컨테이너와 sidecar proxy라는 컨테이너가 생성됩니다.서비스 컨테이너는 우리가 kubernetes yaml파일에 적은대로 생성되고, 각각의 컨테이너 아래에 Istio라는 서비스가 알아서 sidecar proxy를 생성합니다. 지금 저의 서비스에는 Istio를 사용했기 때문에 Istio 기준으로 설명을 드리고 있지만,굳이 Istio가 아니더라도 다른 서비스 메시 서비스들이 모두 비슷한 동작방식을 가지고 있을 것입니다..

Istio를 이해하기 위해선 먼저 Service Mesh란 무엇인지에 대해 먼저 알고있어야 합니다. 참고 자료: What is a Service Mesh? 마이크로서비스, MSA가 등장하면서 도커, 쿠버네티스, 서비스 메시라는 개념이 나타났습니다.도커패키징 문제 해결애플리케이션과 런타임 종속성을 컨테이너로 패키징어디에서나 실행될 수 있는 대체가능한 단위 생성쿠버네티스도커 이미지를 컨테이너 서비스로 올렸을 때,그 수가 많을 경우 이들을 매핑하고 관리(=오케스트레이션)하는 도구서비스 메시마이크로서비스 간 통신을 제어/보안/관찰할 수 있도록 도와주는 인프라 계층To manage connections between services, a service mesh provides new features like mo..