feat: scaling component google cloud functions instance

[bryan-stclab]

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Refactoring (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• DevOps process (non-breaking change which improves efficiency and reliability for CI/CD)
• Documentation only

What this PR does / why we need it:

The Google Cloud Functions Scaling Component has been added to enable scaling of Google Cloud Functions instances.

Which issue/s this PR fixes

#116

How Has This Been Tested?

I wrote a plan YAML file and conducted tests in my actual Google Cloud Platform environment. (Google Cloud Functions instance)
Only Google Cloud Functions API tests and unit tests have been written, and the unit test code consists of test forms only.
We plan to enhance and add more unit tests in the future.

Checklist:

[pueding]

min instances
max instances

min instance count
max instance count

이 두개의 차이가 궁금합니다. v1, v2 둘다 결국 같은 의미로 데이터를 받는것 같은데, 나눈 이유가 궁금합니다! 🧐

[bryan-stclab]

말씀해주신 변수 및 연관된 함수를 만들 때 기본적인 사상은, 최대한 Google Cloud Platform에서 지원하는 Key-Value 형태를 유지하려고 하였고, 내부적으로 동일한 의미를 갖더라도 상위 개념이 다른 제품, 버전, 또는 설정을 의미한다면 서로 구분하는 방향으로 하였습니다. 이렇게 하면 Google Cloud Platform을 숙지하고 있는 사용자 입장, 그리고 개발자의 디버깅 입장에서 조금 더 명확하지 않을까라는 생각으로 나누었습니다.

Google Cloud Platform을 조사하면서, 실질적인 변경 값은 JSON 형태로 Payload를 보내고, 해당 변경 사항에 대하여 Query를 통해 수정하려는 것이 어떤 것인지 명확히 요청에 담아 표현하는 것을 확인하였습니다.
이에 대하여, 저는 add_to_payload_and_query라는 함수를 만들었고, 이 함수는 Google Cloud Platform API와 호환 가능한 Payload, 그리고 Query 형태로 조합합니다. 내부 동작은 각각에 대한 Key-Value 쌍을 입력 값으로 받고 최종 형태로 두 개의 출력 값을 생성합니다.

[bryan-stclab]

논의 결과 공유 드립니다.
v2에 맞게 변수 이름 통합하고 버전을 확인하는 로직을 통해 API 호출 시 수정하여 전송합니다.
(예: minInstanceCount(min_instance_count), maxInstanceCount(max_instance_count), maxRequestPerInstance(max_request_per_instance))