GCP BigQuery 応用編 ~制限について~
入門編はこちら murabo.hatenablog.com
制限
詳細はオフィシャルのこちらを参照してください。
気をつけるものをピックアップして記載します。
標準テーブル
- 1 日あたりの最大テーブル オペレーション数 - 1,000
1テーブルに対して、
読み込みジョブ、コピージョブ、クエリジョブ
を組み合わせた合計数となります。
分割テーブル
分割テーブルとは、取り込んだ日、または指定した日付カラムを元に、デイリー毎にテーブルが分割されます。
- 分割テーブルあたりの最大パーティション数 - 4,000
4000日分まで保有することができる
- 1 つのジョブで変更される最大パーティション数 - 2,000
ジョブ オペレーション(クエリまたは読み込み)ごとに対象にできるパーティションは最大 2,000 です。2,000 を超えるパーティションを対象とするクエリまたは読み込みジョブは、Google BigQuery で拒否されます。 (2000日分のテーブルを操作可能という意味)
- テーブルごとの 1 日あたりの最大パーティション変更数 - 5,000
1テーブル(1日分のテーブル)に対して、5000回まで追加、削除、更新、マージが可能です。
※ただし、ストリーミング挿入はこの割り当てに影響しません
データ操作言語のステートメント
- UPDATE、DELETE、および MERGE の各ステートメントを組み合わせた実行数の 1 日あたりテーブルあたり最大値 - 200
- UPDATE、DELETE、および MERGE の各ステートメントを組み合わせた実行数の 1 日あたりプロジェクトあたり最大値 - 10,000
- INSERT ステートメント実行数の 1 日あたりテーブルあたり最大値 - 1,000
制限に対するベストプラクティス
上記に記載したとおり、更新を加える回数制限が厳しいため、用途によっては実現できない場面が発生します。
これらの制限を回避するためには、テーブル事態を分けることで回数制限を受けにくくすることが可能です。
例えば、
1.ログテーブルをBigQueryで実現したい場合、 - Log1テーブル - Log2テーブル - Log3テーブル などと、同じ構造のテーブルを作成し、userIDなどを元に、logの向き先を制御する。
2.ログテーブルをBigQueryで実現したい場合、 - 九州Log1テーブル - 四国Log2テーブル - 北海道Log3テーブル などと、同じ構造のテーブルを作成し、アクセスや登録エリアなどを元に、logの向き先を制御する。
これらの分割したテーブルは、
select * from logA union all select * from logB
のように連結させて同一テーブルのように扱うことが可能です。
GCP GKE(k8s) ノードがオートスケールしない or ノードプールが作れない
ノードが一定数からスケールアップしなかったり、ノードプールを作れなかった事態に陥ったので共有します。
下記のコマンドで、プリミティブなノードプールを作りたかった。
$ gcloud container node-pools create [node名] --zone asia-northeast1-a --cluster [クラスター名] --scopes gke-default,bigquery,logging-write,monitoring,monitoring-write,sql,sql-admin,storage-full --preemptible --machine-type custom-4-10240
表示されたエラー
This will enable the autorepair feature for nodes. Please see https://cloud.google.com/kubernetes-engine/docs/node-auto-repair for more information on node autorepairs. WARNING: Starting in Kubernetes v1.10, new clusters will no longer get compute-rw and storage-ro scopes added to what is specified in --scopes (though the latter will remain included in the default --scopes). To use these scopes, add them explicitly to --scopes. To use the new behavior, set container/new_scopes_behavior property (gcloud config set container/new_scopes_behavior true). ERROR: (gcloud.container.node-pools.create) ResponseError: code=403, message= (1) insufficient regional quota to satisfy request: resource "CPUS": request requires '12.0' and is short '2.0'. project has a quota of '24.0' with '10.0' available (2) insufficient regional quota to satisfy request: resource "IN_USE_ADDRESSES": request requires '3.0' and is short '3.0'. project has a quota of '8.0' with '0.0' available.
これはCPUの上限と、IPアドレスの上限に引っかかっているという内容です。
解消するには、プロジェクトで使用できる上限を引き上げてもらう必要があります。
メニューから[IAMと管理] > [割り当て]
を選択すると、上限がリストで表示されます
デフォルトでは、下記のようにCPUは24コアまで。
IPアドレスは8個までとなっていました。
申請は、変更したい項目にチェックを付けて、画面上部の[割り当てを編集]から申請を行うことができます。
時間かかるのかな・・・っと心配でしたが、ほぼ即時対応でした。
GCP GKE(k8s) kubernetes Tips
GKE Tips
ノードプールを指定してPodを実行する方法
メニューの [Kubernetes Engine] から [クラスタ] を選択。
下記のようにノードプールが表示されているので、指定するノードプールの名前を確認する。
manifestのDeploymentの場合、
apiVersion: apps/v1beta1 kind: Deployment metadata: name: test-app spec: template: metadata: labels: app: test-app spec: nodeSelector: cloud.google.com/gke-nodepool: default-pool ...
specの中に、nodeSelector
を定義して cloud.google.com/gke-nodepool: [ノードプール名]
と記載するだけ。
クラスターのマシンタイプ変更(移行)する方法
# gcloudコマンドでノードプールを作成する machine-typeとnum-nodesでスペックと数を指定する。 gcloud container node-pools create [任意のノードプール名] --cluster [クラスタ名] --machine-type=custom-4-10240 --num-nodes=3 --zone [クラスタのゾーン名] # 下記コマンドで各ノードをスケジュール不可にします。 for node in $(kubectl get nodes -l cloud.google.com/gke-nodepool=default-pool -o=name); do kubectl cordon "$node"; done # kubectl drain コマンドを実行して各ノードのポッドを正常にドレイン(ノードからpodを強制排除)します。 for node in $(kubectl get nodes -l cloud.google.com/gke-nodepool=default-pool -o=name); do kubectl drain --force --ignore-daemonsets --delete-local-data --grace-period=10 "$node"; done # 上記コマンドが完了すると、ポッドが larger-pool ノードで実行されます。 # 不要となったノードプールを削除する。 gcloud container node-pools delete [削除したいノードプール名] --cluster [クラスタ名] --zone [クラスタのゾーン名]
参考URL: https://cloud.google.com/kubernetes-engine/docs/tutorials/migrating-node-pool?hl=ja
python 3.7 リリース内容と注意点
リリース内容
新たな文法機能:
- PEP 563 、型アノテーションの評価の遅延。
後方非互換な文法の変更:
async
とawait
は予約されたキーワードになりました。
新たなライブラリモジュール:
- contextvars: PEP 567 -- コンテキスト変数
- dataclasses: PEP 557 -- データクラス
- importlib.resources
新たな組み込み機能:
- PEP 553 、新しい breakpoint() 関数。
Python のデータモデルの改善:
- PEP 562 、モジュール属性へのアクセスのカスタマイズ。
- PEP 560 、typing モジュールとジェネリック型に対する言語コアによるサポート。
- dict オブジェクトの挿入順序を保存するという性質が、公式に Python 言語仕様の一部であると 宣言されました 。
標準ライブラリーの顕著な改善
- asyncio モジュールに新しい機能が加わりました。 顕著な 使い勝手とパフォーマンスの改善 です。
- time モジュールが ナノ秒単位の分解能を持つ関数 をサポートするようになりました。
CPython の実装の改善:
- デフォルトのテキストエンコーディングとして ASCII を使わなくなりました:
PEP 552 、決定論的な .pyc
新しい開発用実行時モード
- PEP 565 、 DeprecationWarning の取り扱いの改善
C API の改善:
- PEP 539 、スレッドローカルなストレージのための新しい C API
ご注意を
async
と await
が使えなくなったので、tweepyなどのモジュールがうごかせなくなってます。
自作プロジェクトでも使ってる可能性があると思われるので注意してください。
GCP Google Cloud Memorystore ~実際に動かすまでのみちのり~
Memorystoreを動かすために必要な手順
何も考えずに動かしてみると疎通しない
同一リージョンしか接続できない。
- 東京リージョンで作成したGAEなどからは接続できません。正式版のリリースを待ちましょう。
今回は、memorystoreに併せて GKE をasia-east1
リージョンに作成してます。
構築手順では、IPエイリアスを有効にしない
- ドキュメントには有効にしろっと記載があります(罠)
指定すると、podからredisへの疎通はできましたが、ingressがurlからの疎通ができなくなりました。
わざわざエイリアスを有効にするために、クラスターを作り直したんですが、無駄でした・・・
っというわけで、ここはデフォルトの無効のままで進めます。
IPエイリアスが無効の場合の手順
- 下記が必要らしいので、下記をやります(理由は理解してない)
git clone https://github.com/bowei/k8s-custom-iptables.git cd k8s-custom-iptables/ # Memorystoreのインスンタンス情報確認 gcloud beta redis instances describe forte-dev --region=asia-east1 # 上記のreservedIpRangeを下記コマンドで指定する 192~は下記のままでいい(っぽい) TARGETS="10.0.0.0/29 192.168.0.0/16" ./install.sh # 上記のhost(今回は10.0.0.3)を指定して、configmapを作成 kubectl create configmap redishost --from-literal=REDISHOST=10.0.0.3
deploy yamlのenvに下記を追記
env: - name: REDISHOST valueFrom: configMapKeyRef: name: redishost key: REDISHOST
以上で、ingressの疎通もできて、podからmemorystoreへ接続する手順でした。
たったこれだけですが、実際はすごく時間がかかってしまいました・・・・
正式版がでるまでは、見送ったほうが良いかもしれませんね
GCP Google DATASTORE ~3日で45万溶かす・・・~
皆さーん、GAE使ってますか?
僕は使ってまーす
GAEのFlex使ってます。
理由は、standardはpython2系しか対応してないから
20年に2系のサポート終わるから、そろそろstandardでも3が使えるようになるのかな?なんて期待を持ちつつ、flex
今回初の試みで、DATASTOREに、マスターテーブルを作りました。
マスターにユニークなキーで問い合わせてるだけだったと思ったんですが・・・・
金曜日にデプロイし、月曜の朝来てみたろころ・・・
ざわ・・・・
ざわ・・・
ざわ・・・
ざわ・・・
ざわ・・・・
死ーーーーーん・・・・
金曜になんかリクエストすげー増えてたんですよ。
あとは・・・なんだ・・・・やらかしてたのかな・・・・
なんで、flexはmemcacheつかえねーんだよ。
なんで、MemoryStore東京リージョンからつながらねーんだよ。
もうすぐにエンドポイントコメントアウトして、デプロイですよ。
皆様も気をつけて下さい・・・