Go 1.11은 지원이 종료되었으며 2026년 1월 31일에
지원 중단됩니다. 지원 중단 후에는 조직에서 이전에 조직 정책을 사용하여 레거시 런타임의 배포를 다시 사용 설정한 경우에도 Go 1.11 애플리케이션을 배포할 수 없습니다. 기존 Go 1.11 애플리케이션은
지원 중단 날짜 이후에도 계속 실행되고 트래픽을 수신합니다.
지원되는 최신 Go 버전으로 마이그레이션하는 것이 좋습니다.
앱 리소스 관리
컬렉션을 사용해 정리하기
내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요.
App Engine은 애플리케이션의 성능 및 리소스 활용에 대한 사용 보고서를 생성합니다. 리소스를 보다 효율적으로 관리하는 데 도움이 되는 전략을 아래와 같이 소개해 드립니다. 자세한 내용은 가격 책정 페이지를 참조하세요.
사용 보고서 보기
애플리케이션 성능을 평가할 때는 애플리케이션에서 실행되는 인스턴스 수 및 애플리케이션의 리소스 소비 현황을 파악해야 합니다.
대시보드 사용 보고서 보기
인스턴스 페이지 보기
다음 섹션에서는 몇 가지 리소스 관리 전략을 제안합니다.
동적 인스턴스 확장 관리
지연 시간 줄이기
애플리케이션의 지연 시간은 트래픽을 처리하는 데 필요한 인스턴스 수에 영향을 줍니다. 지연 시간을 줄이면 애플리케이션을 제공하는 데 사용되는 인스턴스 수를 낮출 수 있습니다. Cloud Trace는 지연 시간에 대한 데이터를 보고 가능한 개선 방안을 파악하는 데 유용한 도구입니다.
Cloud Trace를 사용하여 지연 시간을 확인한 후 다음과 같은 전략을 시도하여 지연 시간을 줄여보세요.
- 자주 액세스되는 공유 데이터의 캐싱 증가 - App Engine Memcache를 사용하면 가능합니다. 또한 애플리케이션의 cache-control 헤더를 설정하면 서버 및 브라우저의 데이터 캐싱 효율이 크게 향상될 수 있습니다. 항목을 단지 몇 초만 캐싱해도 애플리케이션의 트래픽 처리 효율이 개선될 수 있습니다.
- App Engine Memcache를 더 효율적으로 사용 - 가져오기, 설정, 삭제 등의 작업에 개별 연속 호출이 아닌 일괄 호출을 사용합니다.
- 요청과 무관한 기능에 작업 사용 - 애플리케이션 기능 중 사용자가 관련되는 요청과 상관없이 수행 가능한 기능은 작업으로 처리합니다. 이러한 작업이 완료되기를 기다렸다가 응답을 반환하는 대신 태스크 큐를 활용하면 사용자가 체감하는 지연 시간을 크게 줄일 수 있습니다. 또한 태스크 큐는 실행 속도를 더욱 세밀하게 제어하고 부하를 고르게 분산하는 데 도움이 됩니다.
- Datastore 모드의 Firestore(Datastore)를 보다 효율적으로 사용 - 자세한 내용은 아래를 참조하세요.
- 여러 URL Fetch 호출을 동시에 실행:
- 여러 URL 가져오기 호출을 사용자가 관련되는 각 요청 내에서 개별적으로 처리하는 대신 하나로 묶고 비동기 URL 가져오기를 통해 오프라인 태스크로 일괄 처리합니다.
- goroutine을 사용합니다.
- HTTP 세션의 경우 비동기식으로 기록합니다.
app.yaml
구성 파일에는 특정 버전의 앱에 대한 성능과 리소스 부하 간의 균형점을 조정하는 데 사용할 수 있는 여러 가지 설정이 포함되어 있습니다. 사용 가능한 자동 확장 설정 목록은 확장 요소를 참조하세요.
App Engine 새 스케줄러 설정 동영상을 통해 이 설정의 효과를 확인하세요.
참고: 모든 Go 인스턴스에서는 동시 요청이 자동으로 사용 설정됩니다.
작업 대기열 설정 구성
태스크 큐의 기본 설정은 성능 우선으로 조정되어 있습니다. 이러한 기본값을 사용하여 큐에 여러 작업을 동시에 보내면 새 프런트엔드 인스턴스가 시작될 가능성이 높습니다. 다음과 같이 태스크 큐를 조정하면 인스턴스 시간을 절약할 수 있습니다.
- 지연 시간에 민감하지 않은 작업에 X-AppEngine-FailFast 헤더를 설정합니다.
이 헤더는 기존 인스턴스를 사용할 수 없으면 요청을 즉시 실패로 처리하도록 스케줄러에 지시합니다. 태스크 큐는 기존 인스턴스가 요청을 처리할 수 있게 될 때까지 재시도와 백오프를 반복합니다.
그러나 X-AppEngine-FailFast가 설정된 요청이 기존 인스턴스를 점유하고 있는 경우, 이 헤더가 없는 요청으로 인해 여전히 새 인스턴스가 시작될 수 있다는 점에 주의해야 합니다.
가급적 정적 콘텐츠 제공
정적 콘텐츠 제공은 인스턴스 시간을 소비하지 않는 특화된 App Engine 인프라에 의해 처리됩니다.
커스텀 헤더를 설정해야 하는 경우 Blobstore API를 사용합니다. Blob 응답이 실제로 제공될 때는 인스턴스 시간이 소비되지 않습니다.
애플리케이션 스토리지 관리
App Engine은 Datastore의 항목 크기, Datastore 색인 크기, 태스크 큐의 태스크 크기, Blobstore에 저장된 데이터 양을 기준으로 스토리지 비용을 계산합니다. 데이터가 필요 이상으로 저장되지 않도록 다음과 같은 조치를 취할 수 있습니다.
- 애플리케이션에서 더 이상 필요하지 않은 항목이나 blob을 모두 삭제합니다.
- 아래 Cloud Datastore 사용량 관리 섹션의 설명에 따라 불필요한 색인을 모두 삭제하여 색인 스토리지 비용을 줄입니다.
Datastore 사용량 관리
App Engine은 Datastore에서 수행하는 작업 수를 계산합니다. 다음은 Datastore 리소스 소비를 줄이고 Datastore 요청의 지연 시간을 단축시킬 수 있는 몇 가지 전략입니다.
- Google Cloud 콘솔 데이터 뷰어는 로컬 Datastore에 각 항목을 만드는 데 소요된 쓰기 작업 수를 표시합니다.
이 정보를 사용하여 각 항목의 쓰기 비용을 파악할 수 있습니다.
이 데이터를 해석하는 방법은 쓰기 비용 이해를 참조하세요.
- 불필요한 색인을 모두 삭제하여 저장소 및 항목 쓰기 비용을 줄입니다.
Google Cloud 콘솔 검색 페이지에서 현재 애플리케이션에 제공되는 색인을 확인할 수 있습니다.
- 데이터 모델을 설계할 때 가능하면 어떠한 경우에도 커스텀 색인이 필요하지 않도록 쿼리를 작성합니다. App Engine에서 색인을 생성하는 방법은 쿼리 및 색인을 참조하세요.
- 가능한 경우 색인이 생성된 속성(기본값)을 색인이 생성되지 않은 속성( )으로 바꾸어 항목을 배치할 때 Datastore 쓰기 작업 수를 줄입니다. 단, 이후에 색인이 생성되지 않은 속성을 쿼리할 수 있어야 한다고 판단될 경우 색인이 생성된 속성을 사용하도록 코드를 다시 수정해야 할 뿐 아니라 전체 항목을 대상으로 매핑 축소를 실행하여 항목을 다시 삽입해야 합니다.
- App Engine 1.5.2 및 1.5.3 출시 버전의 Datastore 쿼리 플래너 개선사항에 따라 쿼리에 필요한 색인 수가 전보다 감소했을 수 있습니다. 특정 커스텀 색인은 성능상의 이유로 그대로 유지하더라도 나머지 커스텀 색인을 삭제하면 저장소 및 항목 쓰기 비용을 절감할 수 있습니다.
- 데이터 모델을 재구성하여 쿼리 대신 키로 가져오기를 사용하면 비용이 낮아지고 효율성이 향상됩니다.
- 가능하면 항목을 쿼리하는 대신 키만 쿼리합니다.
- 지연 시간을 줄이려면 여러 항목의
get()
을 일괄 get()
으로 바꿉니다.
- 오프셋 대신 페이지 매김에 Datastore 커서를 사용합니다.
- Async Datastore API를 통해 여러 Cloud Datastore RPC를 병렬 처리합니다.
참고: 소규모 Datastore 작업에는 Datastore ID 또는 키 전용 쿼리를 할당하는 호출이 포함됩니다. 비용에 대한 자세한 내용은 가격 책정 페이지를 참조하세요.
기타 리소스 관리
항상 오류율을 점검하고 잘못된 호출이 없는지 확인하는 것이 좋습니다. 이렇게 하면 잘못된 호출을 조기에 발견할 수도 있습니다.
달리 명시되지 않는 한 이 페이지의 콘텐츠에는 Creative Commons Attribution 4.0 라이선스에 따라 라이선스가 부여되며, 코드 샘플에는 Apache 2.0 라이선스에 따라 라이선스가 부여됩니다. 자세한 내용은 Google Developers 사이트 정책을 참조하세요. 자바는 Oracle 및/또는 Oracle 계열사의 등록 상표입니다.
최종 업데이트: 2025-09-04(UTC)
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-09-04(UTC)"],[[["\u003cp\u003eApp Engine provides usage reports to help you understand your application's performance and resource consumption, with strategies available for more efficient resource management.\u003c/p\u003e\n"],["\u003cp\u003eReducing application latency, which can be achieved through techniques like increasing caching and using task queues, helps minimize the number of instances required to handle traffic.\u003c/p\u003e\n"],["\u003cp\u003eAdjusting the auto-scaling settings in the \u003ccode\u003eapp.yaml\u003c/code\u003e file allows for a trade-off between performance and resource load, with options outlined in the scaling elements section.\u003c/p\u003e\n"],["\u003cp\u003eOptimizing Task Queue settings, such as setting the X-AppEngine-FailFast header, can help conserve instance hours by managing how new instances are started.\u003c/p\u003e\n"],["\u003cp\u003eEfficient Datastore usage can be achieved by removing unnecessary indexes, replacing queries with key fetches, and utilizing batch operations and cursors.\u003c/p\u003e\n"]]],[],null,["# Managing App Resources\n\nApp Engine generates usage reports about your application's\nperformance and resources utilization. Listed below are potential strategies\nfor managing your resources more efficiently. For more information,\nsee the [pricing](/appengine/pricing) page.\n\nViewing usage reports\n---------------------\n\nWhen evaluating application performance, you should check the\nnumber of instances the application is running, and how the application\nconsumes resources.\n\n[View the dashboard usage reports](https://console.cloud.google.com/appengine)\n\n[View the Instances page](https://console.cloud.google.com/appengine/instances)\n\nThe following sections suggest some strategies for managing resources.\n\nManaging dynamic instance scaling\n---------------------------------\n\n### Decreasing latency\n\nApplication latency impacts the number of instances that are required to handle your\ntraffic. By decreasing latency, you can reduce the number of instances used to\nserve your application. [Cloud Trace](/trace) is a useful tool to view\ndata about latency and understand potential changes to decrease it.\n\nAfter using Cloud Trace to view your latency, try some of the following\nstrategies to reduce latency:\n\n- **Increase caching of frequently accessed shared data** - That's another way of saying - use App Engine Memcache. Also, setting your application's cache-control headers can have a significant impact on how efficiently your data is cached by servers and browsers. Even caching things for a few seconds can have an impact on how efficiently your application serves traffic.\n- **Use App Engine Memcache more efficiently** - Use batch calls for get, set, delete, etc instead of a series of individual calls.\n- **Use tasks for non-request bound functionality** - If your application performs work that can be done beyond the scope of a user-facing request, put it in a task! Sending this work to [Task Queue](/appengine/docs/legacy/standard/go111/taskqueue) instead of waiting for it to complete before returning a response can significantly reduce user-facing latency. Task Queue can then give you much more control over execution rates and help smooth out your load.\n- **Use Firestore in Datastore mode (Datastore) more efficiently** - See below for more detail.\n- **Execute multiple URL Fetch calls in parallel** :\n - Batch together multiple URL Fetch calls instead of handling them individually inside individual user-facing requests, and handle them in an offline task in parallel via async URL Fetch.\n - Use [goroutines](http://golang.org/doc/effective_go.html#concurrency).\n- **For HTTP sessions, write asynchronously**.\n\n### Change auto-scaling performance settings\n\nThe `app.yaml`\nconfiguration file contains several settings you can use to\nadjust the trade-off between performance and resource load for a specific version\nof your app.\nFor a list of the available auto-scaling settings, see\n[scaling elements](/appengine/docs/legacy/standard/go111/config/appref#scaling_elements).\nWatch the App Engine [New Scheduler Settings](https://www.youtube.com/watch?v=eUXUY7QFfAI)\nvideo to see the effects of these settings.\n**Note:** All Go instances have concurrent requests enabled automatically.\n\n### Configuring Task Queue settings\n\nThe default settings for Task Queue are tuned for performance. With these\ndefaults, when you put several tasks into a queue simultaneously, they will\nlikely cause new Frontend Instances to start. Here are some suggestions for\nhow to tune Task Queue to conserve Instance Hours:\n\n- Set the X-AppEngine-FailFast header on tasks that are not latency sensitive. This header instructs the scheduler to immediately fail the request if an existing instance is not available. Task Queue will retry and back-off until an existing instance becomes available to service the request. However, it is important to note that when requests with X-AppEngine-FailFast set occupy existing instances, requests without that header set may still cause new instances to be started.\n\n### Serve static content where possible\n\nStatic content serving\n\n\nis handled by specialized App Engine infrastructure, which does not consume\nInstance Hours.\n\n\nIf you need to set custom headers, use the\n[Blobstore API](/appengine/docs/legacy/standard/go111/blobstore). The actual serving of\nthe Blob response does not consume Instance Hours.\n\n\nManaging application storage\n----------------------------\n\nApp Engine calculates storage costs based on the size of entities in the\nDatastore, the size of Datastore indexes, the size\nof tasks in the task queue, and the amount of data stored in Blobstore. Here are\nsome things you can do to make sure you don't store more data than necessary:\n\n- Delete any entities or blobs your application no longer needs.\n- Remove any unnecessary indexes, as discussed in the *Managing Datastore\n Usage* section below, to reduce index storage costs.\n\nManaging Datastore usage\n------------------------\n\nApp Engine accounts for the number of operations performed in\nDatastore. Here are a few strategies that can result in reduced\nDatastore resource consumption, as well as lower latency for\nrequests to Datastore:\n\n- The Google Cloud console dataviewer displays the number of write ops that were required to create every entity in your local Datastore. You can use this information to understand the cost of writing each entity. See [Understanding Write Costs](/appengine/docs/legacy/standard/java/datastore/entities#Understanding_Write_Costs) for information on how to interpret this data.\n- Remove any unnecessary indexes, which will reduce storage and entity write costs. You can see what indexes are currently serving for your application in the [Google Cloud console Search page](https://console.cloud.google.com/project/_/appengine/search).\n- When designing your data model, you might be able to write your queries in such a way so as to avoid custom indexes altogether. Read [Queries and Indexes](/appengine/docs/legacy/standard/python/datastore/queries) documentation for more information on how App Engine generates indexes.\n- Whenever possible, replace indexed properties (which are the default) with unindexed properties ( ), which reduces the number of Datastore write operations when you put an entity. Caution, if you later decide that you do need to be able to query on the unindexed property, you will need to not only modify your code to again use indexed properties, but you will have to run a [map reduce](https://github.com/googlecloudplatform/appengine-mapreduce) over all entities to reput them.\n- Due to Datastore query planner improvements in App Engine 1.5.2 and 1.5.3 releases, your queries may now require fewer indexes than they did previously. While you may still choose to keep certain custom indexes for performance reasons, you may be able to delete others, reducing storage and entity write costs.\n- Reconfigure your data model so that you can [replace queries with fetch by\n key](/appengine/docs/legacy/standard/go/datastore/reference#Get) which is cheaper and more efficient.\n- Use keys-only queries instead of entity queries when possible.\n- To decrease latency, replace multiple entity `get()`s with a batch `get()`.\n- Use Datastore cursors for pagination rather than offset.\n- Parallelize multiple Datastore RPCs via the [async datastore API](http://golang.org/doc/effective_go.html#concurrency).\n\n**Note:** Small Datastore operations include calls to allocate\nDatastore ids or keys-only queries. See the\n[pricing](/appengine/pricing#cost_resource) page for more information on costs.\n\nManaging other resources\n------------------------\n\nIt's always a good idea to make sure you are checking your error rates and looking out for any invalid calls you might be making. In some cases it might be possible to catch those calls early.\n\n\u003cbr /\u003e"]]