ラベル Cloudrun の投稿を表示しています。 すべての投稿を表示
ラベル Cloudrun の投稿を表示しています。 すべての投稿を表示

2020年5月21日木曜日

cloud runについて(メモ)

①CPU(1固定):1個

CPU(CPU Allowcated):
Cloud Runはデフォルトでコンテナインスタンスごとに1つのvCPUを割り当てますが
これは変更できます。(最大2個まで)

vCPUは、基礎となるハードウェアの抽象化として実装され、可変CPUプラットフォーム上の単一のハードウェアハイパースレッドとほぼ同等のCPU時間を提供します。
コンテナインスタンスは、複数のコアで同時に実行できます。 
vCPUは、コンテナインスタンスの起動時および要求処理時にのみ割り当てられ、それ以外の場合は調整されます。

別のvCPU値を割り当てるには、CPUの割り当てに関するドキュメントを参照してください。



②メモリ(Memory Allocated):2GB(値段が変わらない)
   ->都合で変更してもらって良い

各Cloud Runコンテナインスタンスは、デフォルトで256 MiBのメモリを取得します。
これを変更するには、最大2 GiBのメモリ制限を設定します。
メモリの一般的な使用法は次のとおりです。

1)サービスを実行するためにメモリにロードされたコードファイルシステムへの書き込み
2)nginxサーバーなどのコンテナーで実行される追加プロセス
3)PHP OpCacheなどのメモリ内キャッシュシステムリクエストごとのメモリ使用量


③Containet requests per container instance(最大:80 ->値段が変わらない)
Cloud Runサービスの各コンテナインスタンスによって同時に処理されると予想されるリクエストの平均数。


④Execution time per Request: 100ms
Cloud Runサービスで単一のリクエストを処理するのにかかった実時間


⑤Outband Network Bandwith per request execution(6.4MB)
リクエストごとにCloud Runサービスから送信される出力データの量

以下のサイトを参考にしてみると、データ表示のみであれば1MBから2MBのネットワーク帯域問題なさそう
https://webtan.impress.co.jp/u/2018/08/20/30244


⑥Request per Month(5000) 1000店舗  x 5回
1か月のCloud Runサービスへのリクエストの総数



メモ:
Cloud Run は、トラフィックに応じてゼロからNまで自動的にスケールします。

2020年5月20日水曜日

GCP cloud run (push 手順)


1)登録する
docker tag quickstart-image asia.gcr.io/test-xxxxx/quickstart-image:tab1


2)container registryにpush
docker push asia.gcr.io/test-xxxxx/quickstart-image:tab1

ローカルLLMでコーディングさせるポイント

 簡単な指示で、依頼するとコンテキストオーバーで記憶喪失になって コードの内容が一致しないことが起こるので、work.mdみたいな作業メモを取らせたるのがよい 途中から、別スレッドに再実施する場合でも、work.mdが引き継ぎとして 参照して実施してくれるのがポイント