EMD Blog

개요 온프레미스와 클라우드 간의 전용선을 구축하는 것은 상당히 많은 시간이 소요된다. 신규 증설 같은 경우는 최소 2주 이상은 소요되는 경우가 많은데, 이 때문에 시간을 넉넉하게 잡고 전용선 증설을 하는 것이 좋다. 하지만 전용선 증설에는 각 부서간의 합의와 업체간의 계약이 이루어져야 하기 때문에 시간을 맞추지 못해 곤란해지는 상황이 종종 발생하기도 한다. 만약 시간을 제대로 맞추지 못해 전용선 증설 일정이 틀어질 것 같다면 어떻게 해야할까? VPN 같은 것을 사용할 수도 있고 사내 정책에 따라 임시로 공인 IP를 매핑해 작업을 이어나갈 수 있을 것이다. 하지만 이런 상황도 힘들다고 하면 다른 전용선을 빌려쓰는 방법도 고려해볼 수 있다. 전용선을 빌려쓰는 방법은 두 가지를 고려할 수 있다. 1. 신규 V..

IDC GCP Shared VPC ←—- (VPC Peering) —→ Other VPC 위처럼 구성했을 때 Other VPC에 대한 네트워크 대역들이 온프레미스에 전파가 안되고 있음. 문서상에서는 동적으로 경로를 전파(BGP로)한다고 적혀있기는 한데 전파가 안됨. 일단 VPC 에서 route 정보에 해당 네트워크 대역(Other VPC)이 등록은 되어 있음. 내용 확인해 보겠음. ========= 해결 됨 요약하면 다음과 같음. IDC Project A VPC Project B VPC 이렇게 구성하려할 때 IDC와 Project B VPC간 라우팅 정보는 수동으로 전파해야함. Peering 생성할 때 Project A > Project B로 커스텀 경로 내보내기..

현재 상황은 아래와 같음. ============================================================ - 현재 구축되어 있는 GCP의 네트워크(shared VPC 사용 중)와 IDC 센터는 인터커넥트로 연결되어 있음. - GCP 내에는 Cloud SQL이 비공개 IP로 구성되어 있으며, IDC에서 이 Cloud SQL로 접근해야하는 상황. - 하지만 IDC의 IP 대역은 172.17.0.0/16이기 때문에 GCP 비공개 서비스에 직접적으로 접근 불가.(GCP의 172.17.0.0/16 대역은 Docker 브리지로 예약) - 때문에 Proxy VM을 구축해서 IDC -> Proxy VM -> Cloud SQL 형태를 만드려고 함. - 여기서 Proxy VM은 MIG+자동복..

gcloud compute instance-groups managed rolling-action stop-proactive-update study-managed-instance-group \\ --zone=asia-northeast3-a gcloud compute instance-groups managed rolling-action stop-proactive-update 명령어가 MIG내 최대 인수턴스 개수에 어떤 영향을 미치는 지 궁금함. 그래서 GCP 케이스에 아래와 같은 내용으로 등록하였음. ==============[케이스 질문]================ 스테이트풀 구성 중 궁금한 점이 있어 문의드립니다. 처음에 아래와 같이 스테이트리스 인스턴스 그룹과 오토스케일링을 설정했습니다. ======..

Cloud 모니터링의 알림 채널을 Pub/Sub으로 설정해 알림 메세지를 게시하면 Cloud Functions에서 메세지 내용 확인 시 데이터가 암호화되어 있는 것을 볼 수 있다. 모니터링 알림 스키마 구조 https://cloud.google.com/monitoring/support/notification-options#pubsub 위 문서에서 중간쯤 보면 스키마 구조와 설명이 적혀있다. 하지만 메세지를 출력해보면 아래와 같이 나온다. (검은색으로 칠해진 부분은 base64 데이터이다.) 즉, 아래구조로 출력된다. ( Message ID와 Publish Time은 Pub/Sub에서 생성) { data : string, messageId: string, message_id : string, publish..

Cloud Function을 HTTP 트리거로 생성함. 구독의 서비스 계정에는 해당 함수에 대한 호출자 역할을 부여하였으며 인증을 위해 서비스 계정 토큰 생성자 역할을 부여하였음. Cloud Function은 외부 호출을 허용 해놓은 상태. Publish하면 구독이 메세지를 받아오긴 하나 Push가 되지 않음. Cloud Logging으로 쿼리해보았지만 나오는 로그도 없음. 일단 문서 추가로 확인해보고 케이스에 등록할 예정. 도저히 모르겠음. 해당 내용 케이스로 등록함. ================== 케이스 등록 내용 ================= Cloud Function을 HTTP 트리거로 배포해 Pub/Sub으로 호출하려 합니다. 현재 아래처럼 구성하였습니다. Cloud Function - H..

GCP Cloud Function을 Pub/Sub 트리거를 통해 구성할 시 자동으로 구독이 생성되고 gcf-{cloud function name}-{region}-{topic} ID를 갖게 됨. 이는 기존 조직의 네이밍 룰을 따르고 있지 않아 관리가 불편해짐. Pub/Sub 트리거 구성 시 구독 ID를 직접 지정할 수 있는지 확인해 보았으나 관련 문서를 찾지 못했음. 그래서 GCP에 케이스를 남겨 아래와 같은 답변을 받음, ========================= 해당 이슈에 대하여 재현 해본결과 subscription 은 cloud functions 에 의해 자동으로 생성되며 안타깝게도 이 구독은 Cloud Functions에서 관리하므로 변경이 불가한것으로 확인 되었습니다. 말씀 하신대로 구독 ..

GCP에서 Cloud Monitoring의 Uptime Check를 설정할 때 방화벽에서 Uptime Check IP를 허용해주어야 한다. 하지만 문서상에서 이 Uptime Check가 분기마다 변경될 수도 있다라는 식의 설명이 작성되어 있는 것을 볼 수 있는데, 아래 처럼 적혀있다. =========== 문제의 문서 https://cloud.google.com/monitoring/uptime-checks/using-uptime-checks#get-ips 위 문서를 보면 “업타임 체크에 사용되는 IP 주소는 변경될 수 있지만, 일반적으로 분기별로 두 번 이상 변경할 수 없으며, 별도의 공지가 있어야 합니다.” 라는 문구가 있다. =========== 말이 애매모호 하지만 일단은 Uptime Check I..

가산 IDC와 GCP VPC를 인터커넥트로 연결했으나 대역폭 중첩의 문제로 IDC서버에서 GCP Cloud SQL Server 접속 시 프록시 서버를 거쳐가도록 설정함. 이 경우는 정상적으로 연결되는 것을 확인했으나 GCP에서 IDC에 운영중인 온프레미스 DB에 DB-link가 되는지 확인이 필요 === 시도했으나 아래 두 가지 문제 발생 Cloud SQL Server의 경우 sysadmin 권한 부여가 불가능 서버 링크 불가능 위 문제에 대해서는 문서와 GCP측에서도 확인해줌. 즉, 직접 VM에다가 SQL Server를 설치해 고가용성 설정을 하는 수밖에 없음.

기존에 gcloud compute ssh (IAP)를 사용해 위치에 상관없이 VM에 접속하고 있었으나 어느 순간부터 방화벽을 설정(22번 포트를 수동으로 허용)해야만 접속이 되는 문제 발생. IAP는 내부 IP만 있는 VM에 TCP 터널링을 통해 접속하는 방식이다. 하지만 외부 IP가 연결되어 있으면 TCP 터널링 대신 외부 IP를 사용하기 때문에 접속하고자 하는 IP에 대해 방화벽을 허용해줘야한다. 이 문제를 해결하기 위해 강제로 TCP 터널링을 사용하게하는 -tunnel-through-iap 플래그를 사용하면 외부 IP 존재여부에 상관없이 어디서든 IAP로 서버에 접속 가능해진다.