★ 프로젝트 + 트러블 슈팅 ★39 Lambda@Edge / Secret Manager / CloudFront / S3 트러블 슈팅 (3) 이슈 Lambda@Edge는 환경변수를 지원하지않아, 보안상 노출하면 안되는 정보를 코드에 적는 상황이 발생하였다. 하지만 이건 보안상 좋지 않은 것으로 판단되어 다른 방법을 찾아봐야 할 것으로 판단되었다. 해결방안 아래와 같은 방법들을 찾아보았다. 1. aws secret manager를 통해 비밀값 세팅 및 읽어오기 2. s3에 비밀값을 세팅한 후, 해당 오브젝트를 읽어 비밀값 세팅 및 읽어오기 보안상 더 유리한 1번을 택하였고, 결국 AWS의 secret manager를 쓰는 방향으로 진행하였다. 허나 이때, 매 Lambda@Edge 요청마다 secret manager를 거쳐 비밀값을 가져오며 사용하는 것은 성능상 저하를 가져올 것이기에, secret manager를 통해 얻는 값을 전역 변수에 .. 2024. 1. 10. Lambda@Edge / CloudFront / Singed URL / S3 트러블 슈팅 (2) 이전에 쓴 게시글 이후로, 이미지 get서빙할 때 암호화된 path (URI상 Path, 전체URI를 말하는 것이 아님!) 를 CloudFront가 전달되면 그것이 트리거가되어 해당 path를 복호화하는 Lambda@Edge에 대한 내용을 적고자 한다. 왜 path를 암호화했나요? > s3를 퍼블릭 제한을 걸어두어 함부로 접근은 할 수 없겠으나, 사용자에게 이미지 원본의 s3 경로를 노출하는 것은 보안상 좋지않다 판단하여 이렇게 진행함 Path 복호화 Lambda@Edge 작성과정 1. 현재 유지보수중인 php 애플리케이션 내, 기존에 활용하던 AES 암호화가 있음. 하여 해당 메서드를 그대로 활용하여 Path 암호화를 진행하였음 2. 위 메서드를 통하 여 path가 암호화되어, viewer reques.. 2023. 12. 21. Lambda@Edge / CloudFront / Singed URL / S3 트러블 슈팅 최근, 이미지 get서빙 부분에 보완하면 좋겠는 점이 생겨서 아래와 같이 진행해보기로 하였다. (일부분만 발췌) CF(cloudfront)에 S3를 연동하여 인증된 사용자만 CF를 통하여 이미지를 가지고 오게함과 더불어, 캐시 기능도 활용하여 보다 빠른 이미지 서빙이 가능하게 하는 것이 목적이였다. 추가적으로, S3에서 가져오는 이미지를 Webp확장자 변환 및 리사이징하는 것도 목적이였다. (Path 암호화 Decode 부분은 우선 배제하고 진행하였다) 이를 위해 진행한 샘플 테스트 과정을 아래에 옮겨 기록해두려한다. 우선 위와 같이 운영할 경우의 이점을 파악하였다. CF+ S3 운영이점 및 방법조사 내용운영 이점https://aws.amazon.com/ko/blogs/korea/amazon-s3-am.. 2023. 12. 17. 쿼리 실행계획 (Query Plan)이란? 이슈 최근 회사에서 애플리케이션 기능개선 작업을 진행하던 중, 신규 테이블을 1개 생성해야하는 상황이 생기게 되었다. 그리고 기존 SQL들에서 해당 테이블을 사용하게끔 대거 수정하였다. 헌데 해당 테이블을 생성할 때 컬럼으로 INDEX를 덜 지정해둔 것 같아, 이로 인해 쿼리 성능이 낮아졌는지 체크하는 게 좋을 것 같아 쿼리 실행계획을 파악해보기로 하였다 INDEX는 추가적인 쓰기 작업과 저장 공간을 활용하여 DB 테이블 검색 속도를 향상시키기 위한 자료구조이니, 그냥 모든 컬럼 싹 다 INDEX 걸면 안되냐?! 라고 하면 필자도 사실 혹하긴하나, 아래와 같은 이슈가 있으니 배제하고 필요한 것만 INDEX를 걸기 위해 현재 쿼리 실행계획을 파악하고자 한다. * INDEX를 다 걸면 곤란한 이유 인덱스를 .. 2023. 12. 6. 토이 프로젝트 시작 (23.09.10) 최근 클라우드 서비스만 다루고 있어서, 코딩을 안 한지 꽤 되었다. 이대로 상황이 지속되면 곤란할 것 같아. 토이 프로젝트를 진행하려고 한다. 현재 인원은 프론트 1명, 백엔드 2명, 총 3명으로 구성되어 있다. 주제는 정해졌고, 이제 진행하면 된다. 앞으로 가야할 길은 많지만, 우선 아키텍처 설계한 걸 바탕으로 논의를 진행해봐야겠다. 무중단 배포 및 Nginx(Web Server)사용과 같은 여러가지 사항을 고려했을 땐, 아마 수정해야할 사항이 많을 것 같다. 화이팅 아자아자~! 2023. 9. 10. Timezone 트러블슈팅 (만남의 광장) - 문제상황 최근 프로젝트를 진행하던 중, localhost에서 실행했을 때 작성일자는 KST로 잘 나왔으나 실제 서비스 환경에 배포를 할 시에는 UTC기준의 시간으로 작성일자가 생성되고 있는 상황이 발생하였다. - 이유 1. AWS를 이용한 배포환경으로 인해, 해당 Server의 Timezone이 반영되어 위 상황이 발생함 (모든 Entity들은 아래 BaseEntity를 상속받고 있음) public abstract class BaseEntity { // Entity가 생성되어 저장될 때 시간이 자동 저장 @CreatedDate @Column(name = "created_at", columnDefinition = "DATETIME(6)", updatable = false, nullable = false.. 2023. 3. 4. 이전 1 2 3 4 5 6 7 다음
