自称フルスタックエンジニアのぶろぐ。

pythonやreactや、gcpやawsなどなどについて書いていこうかと思います。

GCP BigQuery 応用編 ~制限について~

入門編はこちら murabo.hatenablog.com

制限

詳細はオフィシャルのこちらを参照してください。

気をつけるものをピックアップして記載します。

標準テーブル

  • 1 日あたりの最大テーブル オペレーション数 - 1,000

1テーブルに対して、
読み込みジョブコピージョブクエリジョブ
を組み合わせた合計数となります。

分割テーブル

分割テーブルとは、取り込んだ日、または指定した日付カラムを元に、デイリー毎にテーブルが分割されます。

4000日分まで保有することができる

ジョブ オペレーション(クエリまたは読み込み)ごとに対象にできるパーティションは最大 2,000 です。2,000 を超えるパーティションを対象とするクエリまたは読み込みジョブは、Google BigQuery で拒否されます。 (2000日分のテーブルを操作可能という意味)

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個までとなっていました。

f:id:murabo408:20181002140703p:plain

申請は、変更したい項目にチェックを付けて、画面上部の[割り当てを編集]から申請を行うことができます。

時間かかるのかな・・・っと心配でしたが、ほぼ即時対応でした。

murabo.hatenablog.com

GCP GKE(k8s) kubernetes Tips

GKE Tips

ノードプールを指定してPodを実行する方法

メニューの [Kubernetes Engine] から [クラスタ] を選択。

下記のようにノードプールが表示されているので、指定するノードプールの名前を確認する。

f:id:murabo408:20180807190227p:plain

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

murabo.hatenablog.com

murabo.hatenablog.com

python 3.7 リリース内容と注意点

リリース内容

新たな文法機能:

後方非互換な文法の変更:

  • asyncawait は予約されたキーワードになりました。

新たなライブラリモジュール:

  • contextvars: PEP 567 -- コンテキスト変数
  • dataclasses: PEP 557 -- データクラス
  • importlib.resources

新たな組み込み機能:

  • PEP 553 、新しい breakpoint() 関数。

Python のデータモデルの改善:

  • PEP 562 、モジュール属性へのアクセスのカスタマイズ。
  • PEP 560 、typing モジュールとジェネリック型に対する言語コアによるサポート。
  • dict オブジェクトの挿入順序を保存するという性質が、公式に Python 言語仕様の一部であると 宣言されました 。

標準ライブラリーの顕著な改善

  • asyncio モジュールに新しい機能が加わりました。 顕著な 使い勝手とパフォーマンスの改善 です。
  • time モジュールが ナノ秒単位の分解能を持つ関数 をサポートするようになりました。

CPython の実装の改善:

  • デフォルトのテキストエンコーディングとして ASCII を使わなくなりました:
    • PEP 538 、レガシーな C ロケールの強制
    • PEP 540, UTF-8 実行時モードの強制
  • PEP 552 、決定論的な .pyc

  • 新しい開発用実行時モード

  • PEP 565 、 DeprecationWarning の取り扱いの改善

C API の改善:

  • PEP 539 、スレッドローカルなストレージのための新しい C API

ご注意を

asyncawait が使えなくなったので、tweepyなどのモジュールがうごかせなくなってます。

自作プロジェクトでも使ってる可能性があると思われるので注意してください。

GCP Google Cloud Memorystore ~実際に動かすまでのみちのり~

Memorystoreを動かすために必要な手順

何も考えずに動かしてみると疎通しない

同一リージョンしか接続できない。

  • 東京リージョンで作成したGAEなどからは接続できません。正式版のリリースを待ちましょう。
    今回は、memorystoreに併せて GKE を asia-east1 リージョンに作成してます。

構築手順では、IPエイリアスを有効にしない

  • ドキュメントには有効にしろっと記載があります(罠)
    指定すると、podからredisへの疎通はできましたが、ingressがurlからの疎通ができなくなりました。
    わざわざエイリアスを有効にするために、クラスターを作り直したんですが、無駄でした・・・

f:id:murabo408:20180702165631p:plain

っというわけで、ここはデフォルトの無効のままで進めます。

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へ接続する手順でした。

たったこれだけですが、実際はすごく時間がかかってしまいました・・・・

正式版がでるまでは、見送ったほうが良いかもしれませんね

murabo.hatenablog.com

murabo.hatenablog.com

GCP Google DATASTORE ~3日で45万溶かす・・・~

f:id:murabo408:20180627153415p:plain皆さーん、GAE使ってますか?

僕は使ってまーす

GAEのFlex使ってます。

理由は、standardはpython2系しか対応してないから

20年に2系のサポート終わるから、そろそろstandardでも3が使えるようになるのかな?なんて期待を持ちつつ、flex

今回初の試みで、DATASTOREに、マスターテーブルを作りました。

マスターにユニークなキーで問い合わせてるだけだったと思ったんですが・・・・

金曜日にデプロイし、月曜の朝来てみたろころ・・・

ざわ・・・・
    ざわ・・・
f:id:murabo408:20180627153222p:plain

ざわ・・・
   ざわ・・・
     ざわ・・・・

f:id:murabo408:20180627153523p:plain

死ーーーーーん・・・・

f:id:murabo408:20180627153429p:plain


金曜になんかリクエストすげー増えてたんですよ。
あとは・・・なんだ・・・・やらかしてたのかな・・・・


なんで、flexはmemcacheつかえねーんだよ。

なんで、MemoryStore東京リージョンからつながらねーんだよ。

もうすぐにエンドポイントコメントアウトして、デプロイですよ。


皆様も気をつけて下さい・・・

murabo.hatenablog.com

GCP Google Cloud Memorystore

GCPにredisをサービス化したものがベータ版で提供されています。

【注意点】 ・リージョンが限定的(東京リージョンはありません) ・ローカルIPしか指定できない

【ハマりどころ】 ・同一リージョンからしかアクセスできません。

GAEから接続したかったんですが、東京リージョンのため接続できませんでした。

GAEは、プロジェクトで作成したリージョンに作られるため、リージョンの変更はできません。

結果、プロジェクトの再作成は難しい状況だったので、使えない・・・

GAEを諦めて、GKE内に処理を移行し、GKEをasia-east1-aに作り直しました。。。