클라우드 개발자 앙몬드

인프라를 담당하시는 AWS Cloud Architect 분에게서 들어왔던 요청이 있었습니다.

EC2의 네트워크 Outbound 정책에 대하여, 나가는 대역을 애니오픈 0.0.0.0/0 에서 제한을 두자는 말이었죠.

사실 이에 대해서는 여러가지 고민해볼 필요가 있습니다.

EC2에서 실제 사용하는 서비스들에 대하여 VPC 엔드포인트를 모두 파악 / 구축해 아웃바운드를 둘 것인가.

혹은 AWS 에서 각 국가별로 사용하는 전체 AZ에 대한 Public IP를 찾아내 제어할 것인가.

* VPC 엔드포인트를 이용해 막아볼까?

  (1) 일반적으로, 프로젝트 초기 설계부터 빡세게 이를 알았다면 위 요건에 대한 문제는 쉽게 풀립니다.

  (2) VPC 엔드포인트는 외부망을 타지 않고, 나의 VPC 사설망에서 통신할 수 있게, 엔드포인트를 제공해주는 서비스입니다.

  (3) VPC EP 게이트웨이 (S3 & DynamoDB) / EP 엔드포인트 2가지로 나뉩니다.

  (4) 따라서, 프라이빗 엔드포인트가 생성될 시, 혹은 Public 게이트웨이 엔드포인트가 생성될 시, 이에 대하여 아웃바운드를 제어하면 만사 OK죠.

  (5) AWS 백서 참조 : docs.aws.amazon.com/ko_kr/vpc/latest/userguide/vpc-endpoints.html

이슈는 지금 구축 단계가 아니라, 현재 운영중인 엔터프라이즈 어플리케이션들에 대해서 이를 어떻게 네트워크를 틀어 막을 것인가 입니다.

아무리 처음부터 히스토리를 알고 있다고 하여도, 각 서버에서 무엇으로 통신하는지를 정확히 100% 파악해 틀어막을 수는 없습니다. 그러기엔 너무 위험부담도 크고, 또한 네트워크 블록킹 시 중요한 전문이나 오픈 API, Batch 작업이 돌아가지 않을 경우, 이에 대한 책임을 감당할 순 없을 겁니다.

그래서 생각한 나 (클라우드 개발자 앙몬드) 의 생각.

"어차피 물리적으로 아마존의 데이터센터가 한국에 위치해있다면, 그들이 사용하는 Public IP 또한 대역이 존재할 것 아닌가?"

"이를 통쨰로 파악하여 틀어막아보자."

하지만 한계도 있었죠. AWS의 Public IP들은 고정된 것이 아니라, 도약을 하기 때문에, 파악한 Public IP가 영원할 것이란 보장은 없었습니다.

흠.. 정답이 없을까.. 진짜 VPC 엔드포인트를 모두 위험을 감수하고서 SG 작업을 해야할까?

하지만 운좋게 2019년. AWS에서 멋진 기능을 제공해주기 시작했죠!

바로, AWS IP 대역 변경에 대해서, 이를 알려주는 서비스입니다.

aws.amazon.com/ko/blogs/korea/subscribe-to-aws-public-ip-address-changes-via-amazon-sns/

잠깐 요약을 하면, 특정 SNS 토픽에 대하여 구독 (Subscription) 을 생성하면, 그 메서드로 알림/트리거가 간다는 내용입니다.

보시면, SNS 토픽 ARN이 아예 고정되어 있습니다.

주의 사항도 있어요!

이 SNS는 us-east-1 (North Virginia) 에서 생성을 해야합니다. 저 ARN을 리전과 내 AWS 어카운트 12자리로 바꾸어도, 인식하지 않습니다.

(다시 말하면 뭐다? 저 806199016981 은 AWS의 고유 계정이다.. 라는 건데 나한텐 전혀 쓰잘데기 없는 거..)

SNS 서브스크립션 없이도, 오픈 API를 제공해줍니다. 하기와 같으며, 지금 한번 호출해 result json 파일을 뜯어보았습니다.

ip-ranges.amazonaws.com/ip-ranges.json

하지만, 앙몬드는 저걸 일일이 계속 호출하기 싫으니, SNS 구독을 받아 람다를 호출하는 형태의 Fan-out 람다를 만들어 보기로하였습니다.

(1) SNS 구독을 위 AWS IP 대역 변경에 대하여, 서울리전의 람다를 설정시킨다.

(2) IP대역 변경이 있을 시, 람다가 이를 실행한다. (SNS를 이용한 Fan-Out 패턴 살짝 변형)

(3) 람다는 SNS 이벤트에서, 대역 변경에 대한 정보 중, 서울리전의 Public IP 대역을 EC2 SG 아웃바운드 룰에 설정한다.

오늘은 앙몬드 또한, 이에 대하여 1번과 2번을 해보았지, 아직 3번에 대한 것을 해보진 않았습니다.

사실 그래봤자, 런타임에 따른 람다 SDK를 사용하는 것일 뿐이기에 큰 이슈는 없을 것으로 생각되네요.

(오히려 저 SNS 토픽 찾는게 더 힘들었음...)

만들게 되면, 3번에 대한 코드는 같이 포스팅하는 것으로 약속하죠 :)

* Fan-Out 에 대한 AWS 화이트페이퍼 레퍼런스 : aws.amazon.com/ko/getting-started/hands-on/send-fanout-event-notifications/

* 아마존이 설명하는 팬아웃은 SNS & SQS 조합이지만, 람다 조합도 팬아웃 패턴으로 인식해도 문제가 없다고 개인적인 판단이네요.. 근데 왜 SQS만 넣었는지는 조금 의문이긴 합니다..

[정리]

1. SNS -> SQS 를 이용한 조합을 AWS 팬아웃 아키텍처라고 합니다.

2. AWS AZ, 데이터센터 또한 명백히 사용하는 Public IP 대역이 있습니다.

3. 2번에 해당하는 Public IP는 고정이 아니지만, 바뀔 경우, SNS 혹은 API를 통해 인지할 수 있습니다.

오늘은 참 신기한 일이 있었댜...

어쩌면 지금까지 맹신하고 있었던 AWS 리소스들에 대한 API 명세서를 다시 한번 읽어보아야겠다는 의심을 가지는 하루..

먼저 플랫폼에 대한 아키텍처를 하기와 같이 간단하게 그려보았습니다.

1. 상황설명

  - AWS의 ECS 컨테이너 오케스트레이션 적용. EC2 컨테이너 인스턴스들, 오토스케일링 그룹

  - Launch Configuration 을 통하여, EC2 인스턴스 오토 스케일아웃 시, EBS 또한 자동 증설 및 마운트

  - EC2의 네임태그는 현재 관리가 되나, EBS 네임태그 관리되지 않아 파이썬을 통한 네임태그 자동화 스크립트 개발!

  - 해당 VPC 내부에 위치하는 람다를 이용하여, EC2의 정보를 읽어와 EBS의 네임태그 자동생성하는 것이 목적!

어찌보면 조금 간단합니다. 뭐 로컬에서 CLI나, 해당 VPC 내부에 임시 인스턴스, 혹은 저처럼 람다를 이용하여 개발하는 방법 등등 여러개가 있죠. 하지만 개발자 앙몬드는 람다의 재미에 빠져있기에 람다를 쓴댜 실시

람다를 사용하기로 한 앙몬드는, 파이썬3 런타임의 람다, 그리고 AWS에서 제공하는 파이썬용 AWS SDK boto3를 이용해, 상기 과제를 수행하기로 합니다. 작업 설계/계획은 다음과 같았죠.

2. 앙몬드가 생각한 작업 순서

 a. 람다에서, 해당 VPC 내부에 위치한 EC2 인스턴스들에 대한 정보를 가져온댜

 b. 인스턴스들에 마운트 (탑재) 된 EBS 정보를 리스트로 추출한댜

 c. EBS의 네임태그에 조합할, EC2 네임 태그도 같이 추출한댜

 d. EBS 태그 생성을 위해, 볼륨 ID를 추출한댜

 e. b/c/d 의 조합을 가진 리스트로, EBS 정보를 호출해 네임태그를 생성한댜

 *. EBS 네임태그 규칙 : volume--(탑재된_인스턴스_네임)--(마운트경로) / ex. volume--angmond_instance_1--/dev/xvda

어찌보면, 참 단순합니다. 단지, 저것에 해당하는 API가 무엇인지, 열심히 영문 API 명세서를 읽는 일이 문제였죠..

(누가 boto3 한글 번역좀 내주소!!!!)

3. boto3 API를 모아보쟈

EC2 인스턴스를 호출하기 위한 API입니다.

리턴 포맷까지 봐야하는데.. 너어어어무 기니까 우선 레퍼런스로 남길게요... (사실 출처도 필요했어!)

  출처 : boto3.amazonaws.com/v1/documentation/api/latest/reference/services/ec2.html#EC2.Client.describe_instances

하지만, 추출 시 필요한 녀석들은 캡처를 했죠 (흐뭇)

자.. 아무튼 요렇게 3가지를 이용했고, 이제 EC2 서비스 내부에 EBS 통신 커넥터를 생성해보죠!

하기와 같습니다.

ec2.Volume의 id는 EC2 인스턴스 id가 아니라, EBS 볼륨 ID입니다. 주의하세요!

그래서 describe_instances 시, EBS 매핑정보에서 VolumeID를 추출한거죵!

이제 다 왔습니다. EBS 볼륨에 태그 생성 함수를 호출해 끝내죠!

AWS 콘솔에서 이제 자동 완성된 EBS 네임태그를 한번 구경후 끝내려는데.. 이슈가 나옵니다.

대다수 EBS에 네임태그가 생성되었는데, 생성이 안된 녀석들이 있네..? (나닛!)

4. 트러블슈팅 시작

이제부터 또 트러블슈팅 들어가야죠.. 뭐가 문제였는지..

사실 가장 먼저 떠오른건..

    ****** EC2 인스턴스 정보를 못가져왔나?

그리고 그 불길한 예감은 맞았습니다.

콘솔 확인결과, 100개의 인스턴스가 제 눈에 보였는데,

boto3.client("ec2").describe_instances() 에는 100개보다 적은 90개만 보였기 때문이죠.

음? 왜? 뭐지? AWS가 고장났다

한참을 고민한 끝에.. 오랜만에 영문 독해를 다시 시작하고서야 깨닫는군요..

다시 아키텍처를 보죠.

우리가 처음에 고정 인스턴스를 사용자 혹은 어카운트 오너가 직접 생성합니다.

그러나, ECS에 묶인 ASG EC2 클러스터들은 유저가 생성하는 것이 아니라, ASG 즉 AWS 자체에 의해서 & 내가 정한 규칙에 의해 생성됩니다.

즉, 규칙은 내가 정했으나, EC2 실제 생성은 AWS에 위임한 것이죠.

그리고 EC2 describe_instances API 명세서에 그 단서가 나옵니다. 다시 찬찬히 읽어보죠.

형광펜 칠한 부분이 보이시나요?

"내가 소유하지 않은 인스턴스를 명세할 시, describe_instances 함수의 결과값으로 반환되지 않습니다."

즉, 저 100개 중, 10개는 ECS 오토스케일 아웃 정책으로 확장되었기에, 내가 직접 만든 인스턴스가 아니라고 판단하는 것으로 추정되는 것.

따라서, 100개의 정보가 아니라, 90개만, 내가 직접 생성한 것만 넘어온 것이며, 시스템에 의해 오토스케일 아웃된 EC2 인스턴스들은 이 API의 결과로 얻을 수 없었습니다.

프로덕션 단계의 서비스에 대하여 만든 스크립트이기에, 강제 스케일 인 하여 결과를 확인해보진 않았지만, 이에 대한 정확한 답은 AWS에 이슈잉을 하여 정확한 답변을 들어봐야겠습니다.

물론 지금 위에 있는 것은, 어디까지나 앞뒤 상황을 맞추어서 제가 추론해본 것이기에 정확하지 않습니다.

아니 어쩌면 앙몬드가 틀렸을 수도 있죠..

5. 앙몬드와 회고

단지 이게 보토스 (boto3) 의 오류만인지는, 내일 AWS CLI를 직접 날려보아 보토스와 결과가 같은지를 확인해보아야 겠습니다.

만약 둘 모두 결과가 동일하다면, CLI를 사용하여 클라우드에 액션을 취하는 행위도 굉장히 조심스럽게 될 수 밖에 없을 것 같습니다.

전국의 Cloud Architect들 화이팅!

그리고 영어를 열심히 공부합시댜.....

근 한달만에 정리를 하게 되었습니댜..

그동안 일이 조금 많기도 하고, 게으름도 조금 부렸었는데 다시 한번 잊어버릴라...

이전 파이썬 리스트에 대해 알아보았었는데, 오늘은 조금 더 심화시켜 리스트의 슬라이싱.

그리고 역인덱스를 파보도록하죠.

(사실 내가 안까먹기 위한 공부댜..)

1. 리스트 슬라이싱

파이썬에 입문하며 조금 생소했던 부분인데, 리스트 슬라이싱..

이눔.... 생각보다 중요합니다. (많이!)

이게 슬라이싱을 구성하는 기본 문법입니다.

간단히 사용사례를 스노우타운 주민들 리스트로 살펴볼겁니다. 문법자체보다는 다른 의미가 더 깊기 때문이죠.

한장으로 리스트 슬라이싱 문법과 사용케이스 끝낼테니 잘 보세요! 스노우타운 주민 여러분!!

자 본래 의미 고찰... 이녀석을 꺼낸 이유는 따로 있습니다.

바로.. 리스트 2장에서 살펴보았던, copy() 함수와 객체별 레퍼런스의 메모리 주소값의 연장선이죠.

이 녀석. 슬라이싱을 0번 앙몬드부터 시작하건, 중간에 2개씩 끊건. 우리는 하나의 "스노우타운_마을주민_리스트" 를 통해서 슬라이싱을 모두 끝냈습니다.

즉, 원본 리스트의 데이터값을 유지한채로 새로운 콜렉션을 탄생시켰댜.....

이거 생각보다 중요합니다.

호스팅 환경에 부담을 최대한 덜면서 원본 데이터 백업 및 데이터 처리가 가능하다는 의미이죠!

10만건 정도의 대량의 데이터가 있다고 가정하고, 그 대용량 데이터를 원본 손상 없이, 야금야금 떼어내서 처리한다. 문제가 생기면 바로 그 원본 데이터로 롤백시키면 된다..

사실 이것때문에 리스트 슬라이싱을 뽑아본 거였습니다. 개발의 세계에서는 이를 원본 데이터를 손상시키지 않는다하여, "비파괴동작" 이라고 부르죠. 그럼 "파괴동작"은 뭐가 있을까요?

전장에서 보았던, insert, append, remove, pop... 모두 원본 데이터를 조작해 기존 리스트가 변경되었었죠?

파괴동작입니다.

자 그럼 다시 2장에서 꺼내보았던 id함수를 또 여기서 써보도록 하죠. 무슨 주소값이 나올까요?

스노우타운 마을주민 리스트의 원본 메모리주소 (1)과, 슬라이싱 했을 때의 주소가 다른 것을 볼 수 있습니다.

즉 파이썬 실행 시, 인터프리터가 슬라이싱에 대하여 새로운 메모리 주소를 할당하고 그에 대해 쓰는 것을 알 수 있습니다.

  ***** 노트노트.....

2. 마이너스 인덱스

일반적으로 우리가 리스트나 배열하면, 0번부터 인덱스가 시작한다고 생각을 하죠.

0이 첫 값부터 쭈욱 시작하면, 마이너스 인덱스는 맨 마지막부터 첫 값까지 가요!

마이너스 인덱스를 통해, 데이터를 처리할 때 조금 더 센스를 발휘해보면 다른 개발자들도 뭔가 재미나게 로직을 꾸밀 수도 있는 상황이 올겁니다 :)

슬라이싱 자체는, 솔직히 저거를 왜 쓰는건가.. 라기보다는 특수 상황에서의 유용성. 그리고 가장 중요한

원본데이터를 그대로 보존시키면서 데이터 작업이 가능하다. 비파괴동작..

을 꼭 기억하고 가셨으면 합니다.

으.. 또 7시간 뒤면 출근해야한다.... 이만 개발자 앙몬드는 슬슬 자러갑니다...

리스트를 만들었는데 안에 있는 데이터를 만질 일이 생길 수 있어요.

이번 편에서는 리스트 데이터를 만질 수 있는 방법 요약을 해봅시댜.

☆역순 탐색에 해당하는 -1부터 시작하는 인덱스는 (2) 편에서는 다루지 않고, 리스트 후속편에서 다루도록할게요!

☆-1 인덱스는 range와 리스트 슬라이싱과 연관이 많기떄문에, 리스트만 다루는 본 2장에서는 잠깐 패스!

1. pop() 함수 - 리스트의 데이터를 인덱스로 삭제하고, return으로 받아오는 함수입니댜.

스카피 리스트를 만들고, 하나의 백업본을 만들었는데

삭제하는 함수는 remove가 아니라 pop을 사용합니다.

remove에 대해서는 2번에서 알아볼거예요.

한번 출력해보면?

스카피 리스트의 0번 인덱스, 값이 3인 여석이 없어진 것을 확인했습니다.

1번 주제가, pop() 삭제함수는, return을 한다고 했는데 그 값도 받아오는지 확인해봐야죠?

대입/출력 코드를 합해서 테스트드라이브 결과 받아왔어요.

그럼 흔히 알고있는 remove함수와의 차이는?

2. remove() 함수 - 리스트의 데이터를 객체의 값으로 삭제합니댜

pop( index ) vs remove( value )

이것이 pop과 remove 함수의 결정적인 차이입니댜

인덱스로 리스트 데이터를 저격할 것인가, 아니면 값으로 데이터를 저격할 것인가.

우선, remove를 한번 써보고 결과를 봐보도록 하죠.

pop 데이터는 return으로 그 pop된 데이터를 들고왔지만, remove는 None을 리턴하고 있어요.

왜 값을 리턴하지 않을까?

이미 value 기준으로 값을 제거했는데, 그 삭제된 value를 다시 리턴해주는 것이 맞을까요?

인덱스로 접근시에는 그 값의 정체를 모르지만, value로 접근시에는 이미 내가 그 값의 정체를 알고 있기 때문에, 따로 value를 리턴해줄 필요는 없습니다.

None 은 흔히 다른 언어에서는 공통적으로 null value에 해당합니다. 혹은 다른 친구들과도 비교하자면, Void 객체, 대다수가 알고있는 Javascript 에서는 Undefined 객체와 비슷한 친구예요.

3. copy() 함수 - 해당 리스트 메모리에 할당된 데이터들에 대한 복제본을 만들어요

파이썬 또한 각 객체의 네이밍들은 객체, 즉 레퍼런스들입니다. C언어, C++ 등에서는 포인터로 표현되었죠. 메모리를 가리키는 주소값입니다.

A = [1,2,3]    # ... A라는 변수에 [1,2,3] 을 할당해, 그 레퍼런스를 붙였어요

B = A    # ... B라는 변수에 A라는 레퍼런스를 다시 붙였어요

2개 모두 [1,2,3] 을 가리킵니다.

이 때, A.pop(0) 을 하고, B를 출력해볼까요?

여기서 차이가 생깁니다. B와 A 모두 [1,2,3] 가 할당된 메모리 주소를 같이 가리키게 되는데, B라는 변수에 A라는 레퍼런스를 대입하며 벌어지게 된 일입니다.

위 예시 코드를 좀 더 확장해서 차이점을 볼까요? 이번엔 파이썬의 메모리 주소를 확인하는 id() 라는 함수를 써서 딥 다이브해볼거예요.

위 예시코드에, id() 를 추가했고, A = [1,2,3]  B = [1,2,3] 을 따로 설정해보았어요.

보시는 바와 같이, 첫번째 B=A 는 같은 메모리주소 57400968 같은 메모리 주소를 가리키고 있네요.

A가 바라보는 57400968 메모리주소의 [1,2,3] 에서 pop을 하니, B가 바라보는 57400968 도 같이 pop이 되는 것이죠.

반대로, 아래 추가 예시코드는, A와 B 모두 [1,2,3] 따로 할당 후, A만 pop하여도 B의 데이터는 그대로 남아있죠.

아래 A와 B 추가코드의 메모리 주소도 다른 것을 확인할 수 있습니다.

먼 길을 돌아, 다시 copy 함수.... (음...)

데이터 처리 시, 원본 데이터를 한번 백업해두어야 하는 일이 있습니다.

위처럼, [1,2,3] 단순하다면 상관 없겠으나, 그게 수백건으로만 올라가도, 저렇게 하드코딩해서 대입하여 백업할 수 없는 노릇!

이 때 copy() 함수를 써서 새로운 메모리 공간을 할당해 백업해주는 좋은 꿀팁이 있어요!

방법은 간단합니다.

원하는 리스트에, copy() 함수 하나만 붙여 다른 객체에 할당해주면 끝!

결과를 보시면, pop 했는데도, B의 [1,2,3] 데이터는 그대로 남아있어요.

메모리 주소를 확인해봐도, A와 B가 같은 주소를 가졌던 것에 반해, 다른 메모리 주소가 할당된 것을 확인할 수 있죠!

copy() 함수는 유용하지만, 너무 큰 데이터를 동시에 백업할 때는, 호스팅 환경에 굉장한 부담을 줄 수 있습니다.

 (어쩌다보니 카피함수와 메모리 주소, 레퍼런스의 개념까지 요약하다보니 이게 제일 길어졌댜...)

4. append() - 리스트에 데이터를 뒤에 계속 가져다 붙여놓는 함수

삭제해봤으니 추가도 해봐야죠? 리스트 뒤에 하나하나씩 데이터를 할당 생성하는 함수입니다.

쉬워요!

앙몬드 스트링 데이터를 붙여 넣으니, 스카피리스트 데이터에 잘 붙어 들어갔습니다.

remove와 마찬가지로, value 기반 호출이니, 따로 return 값이 없는 것을 볼 수 있습니다.

5. extend() - 리스트에 리스트를 붙여 확장하는 함수

append()가 단일값으로 데이터를 추가하는 함수였다면,

extend() 는 아예 리스트 자체를 덧붙여 추가하는 함수입니다.

1 vs n 의 관계라고 보면 편하겠어요!

방금 앙몬드를 append 했던 스카피리스트 자체를, 스카피리스트에 extend 하니 곱절로 불어났네요!

  (앙몬드가 2명)

이번에도 리턴값은 없습니다. 함수 실행 후, 그에 대한 데이터 값은, 스카피_리스트 자체 내에 있기 때문에, 별도의 리턴값은 필요없겠죠?

6. insert() - 리스트의 특정 위치 (인덱스) 에 데이터 삽입하기 (새치기)

취소선은 그었지만.. 진짜 줄서있는 데이터 중간에 새치기해서 끼워넣기.. 라는 말이 최적 (ㅇㅈ)

특정 위치 - 인덱스에, 데이터를 끼워 넣습니다. 이 녀석은 파라미터가 2개로 지정되어 있으니, 규격을 글로 써볼게요.

리스트.insert( 인덱스-끼워넣을 위치 , 값-그 인덱스에 끼워넣을 값)

원래 스카피 리스트는 [3, 1, 2, ...., '앙몬드] 였어요.

즉, 0번 인덱스에는 3이란 값이 있었지만, 여기에 "케로와 베로니" 를 새치기시켰습니다.

원래 3이란 값은 새치기를 당해, 이제는 1번 인덱스로 가게 되었네요!

    (앙몬드들도 한칸씩 밀렸다)

7. sort() & reverse() - 리스트를 순차/역순 정렬하는 함수

리스트를 보기 좋게 정렬해주는 함수입니다.

그냥 한번 둘러보시면 아 이렇구나 하고 알게 될거예요! (근데 주의하실 것도 있습니다.)

원래 숫자만 있었던 카피_리스트를 재사용해봤어요.

3,1,2,4,5 무작위였던 녀석이, sort() 하니 자동 오름차순 정렬되었어요!

아래에서는 그 카피_리스트를 reverse() 해보니 내림차순 정렬되었습니다.

근데 주의사항이 있었죠?

리스트의 정렬은 내부 타입이 일관성이 있어야 한다는 점이죠!

숫자 리스트안에 문자나, 딕트, 세트 등 동일 대상 비교가 불가한 녀석들이 섞인 잡동사니 리스트에서는 쓸 수 없다는 점 유의해두세요!

원래는 간단하게 제 자신이 까먹지 않기 위해 쓰는 글이었는데, 어느 순간부터 글이 점점 늘어가는 기이한 일이...

무튼.. 다음 편에서는 이 리스트에 대한 슬라이싱과 마이너스 인덱스, range 에 대해서 더 딥다이브를 해보도록 하죠!

그 흔한 리스트.

파이썬은 특이한게, 타입 지정이 없어요. (사실 JS도 그런데..)

다 객체로 취급하기 때문에, 리스트 안의 데이터들도 특별한 타입 지정 없이 죄다 박혀 들어가요

한번 보도록 하죠 :)

대괄호로 표현하는게 특이한데, 앵간한 언어들의 대괄호 초기화는 배열을 의미했는데,

파이썬에서는 특별히 배열만 따로 분리되어 설명하는 개념은 없더라구요.

1번 공백 리스트, 2번 잡동사니 리스트, 3번 리스트와 잡동사니가 섞인 리스트, 4번처럼 iterable 객체를 다시 리스트로 변환하여 초기화한 리스트. 그 외 여러가지가 많습니다.

ps) print의 f는 파이썬3부터 지원하는, f-string 기능입니다. 구글링해보시면 능력자들의 더 뛰어난 글들을 만나보실 수 있어요!

ps) iterable 의 영문 의미는 "반복가능한" 이란 의미입니다. 뜻에서부터 유추 가능하듯, 반복, 즉 루프로 돌릴 수 있는 녀석들은 대개 iterable 객체로 집어넣을 수 있어요!

초기화도 해봤으니 간단한 출력 테스트 드라이브..

뒤 이어, 리스트의 데이터를 수정할 수 있는 함수들과, 기타 유용한 기능들을 알아보도록 하죠 :)

AWS AZ 간 시간때문에 애를 먹었던 일이 있었는데 이번에 또 발생했어요.

클라우드 개발 시의 시간 참조별.. 까먹지 않게..!

1. AWS Lambda 실행 시간

 - 기본적으로는 UTC 0시 (영국) 기준으로 돌아가요.

 - 람다 실행 시, 타임존 (TZ)를 [Asia/Seoul] 즉, UTC 9로 맞추고 하면 Cloudwatch (CW) 에서 실행 로그를 보기 좋아요

당연히! 서울 AZ를 쓰는 입장에서, +9로 맞추어야지! 했는데.. 이게 엘라스틱서치와 키바나에서 꼬일줄은...

2. AWS Elasticsearch 시간

 - 데이터를 들이밀어 넣는 요청 측에서 시간 데이터를 결정합니다. 주는데로 받아먹는 ES.

 - 영국은 0시, 한국은 이 때 9시가 되겠죠.

 - 람다가 한국 시간 9시 데이터로 ES에 들이 밀어넣으니..

3. AWS ES Kibana 플러그인 조회..

 - 분명 현재 한국 시간으로 조회했는데..

 - 데이터가 왜 없을까.. 분명 람다에서 한국시간 9시 기준으로 집어넣었는데, 키바나 조회가 안되요.

 - 하지만 AWS 콘솔 상으로도, CLI 상으로도 ES에는 데이터가 존재한다고 나오는데...

[결론 : 키바나 검색 시, 브라우저의 로컬 타임존을 자동 보정해 데이터를 가져온다..]

즉, 위 상황에서 키바나는 한국시간 +9로 보정되어 집어넣은 데이터에, 키바나가 한번 더 +9를 하니, 영국시간 0시보다 +18시간 (욕 아님) 된 데이터를 찾으려고 하는 것...

첫 설계 시, 시간에 대하여 어떻게 보정할 지 로직/공통 가이드를 제공하는 것이 필수.....

(1) 람다의 실행 시간을 어느 것을 기준으로 할 것인가

(2) 엘라스틱서치에 시계열 데이터 삽입은 어떤 시간을 기준으로 할 것인가

(3) 키바나 조회 시, 브라우저 로컬 타임존 시간 보정 여부도 확인해서, 아키텍처가 잘 짜이게 만들어야한다.

캡처를 좀 해서 올려놔야 하는데.. 음..

(설마 누가 볼까)