背景
Kubernetes上でサクッと動作検証でPodを立てたい時に
kubectl run \ --generator run-pod/v1 \ --namespace $NAMESPACE \ --image google/cloud-sdk:alpine \ --rm -it gcloud-test
とやりますが、今実行すると以下のようにエラーになります。
error: unknown flag: --generator
これの対応方法です。
続きを読むKubernetes上でサクッと動作検証でPodを立てたい時に
kubectl run \ --generator run-pod/v1 \ --namespace $NAMESPACE \ --image google/cloud-sdk:alpine \ --rm -it gcloud-test
とやりますが、今実行すると以下のようにエラーになります。
error: unknown flag: --generator
これの対応方法です。
続きを読む重み付き乱択アルゴリズムは結果に偏りのある抽選で
といった用途で使えます。
今回はその説明と実装方法の紹介を行います。
重み付き乱択のイメージとしては以下のようにいくつかの重みがある中で、0〜重みの合計値の範囲でランダム値を生成してどの重みにヒットしたかを返します。
図ではランダム値34が出たため、item Cが結果として返ります。
続きを読むPythonはGILがあるためマルチコアの恩恵を受けづらいです。そのためGunicornのようなプロセスマネージャを利用してマルチプロセスで稼働させ、パフォーマンスを上げるといった手法があります。
しかしマルチプロセスにした場合、Prometheusのメトリクス値が収集するプロセス毎に異なってしまい、本来単調増加するはずの値が増減してしまいおかしなメトリクスになってしまいます。
ref: Strange drops in total requests · Issue #50 · trallnag/prometheus-fastapi-instrumentator · GitHub
そこでPythonのPrometheus clientにはマルチプロセスモードが用意されており、外部共有ファイルにstatsを書き出すことで整合性を保証します。
今回はFastAPIでマルチプロセスモードを用いたメトリクスの収集方法を説明します。
続きを読むBigtableのデータを他プロジェクトに移したい場合、公式のDataflowテンプレートを用いて以下の図のようにExport & Importできます。
しかしBigtableのデータが多すぎるとImportする際に、
Error message from worker: java.lang.IllegalArgumentException: Key xxxxxx has 141530 mutations, which is over the 100000 maximum.
といったBigtableのquotaエラーが発生することがあります。今回はその対応方法です。
MongoDBやPostgreSQLでは認証時にSCRAM (Salted Challenge Response Authentication Mechanism) と呼ばれる認証方式を採用しています。
これは従来のチャレンジレスポンス型の認証を改善したものであり、パスワード(ハッシュ値含む)といった機密情報をサーバ側で保持せずとも認証できる仕組みです。
今回はそのSCRAMについて図を交えて説明します。
SCRAMのシーケンスは以下です。
続きを読む
オンプレからクラウドに移行(マイグレーション)した場合や、クラウド上でセルフホスティングしていたDBをマネージドDBに移行した場合に問題となるのが「データは欠損なく移行されたか」です。
データの数が少なければプログラミングで差分チェックなどを書けますが、億単位の数であったりTB単位のサイズといったオーダーでは自前でプログラミングして差分を出すのは現実的では有りません。
そこで分散処理に強いBigQueryを利用することで、大規模データのマイグレーションにおいても完全性のチェックが実現できます。
アーキテクチャとしては以下です。今回データベースはMongoDBを想定しています。
続きを読む
Cloud ArmorのようなWAFは通常ルールベースで不正なアクセスを制御するため、悪意あるユーザがIPアドレスやパラメータをコロコロ変えたりすると都度ルールを設定する必要が出てきてイタチごっこになりがちです。
そんなケースに対応できるよう、機械学習を用いて攻撃であるかどうかを判断してくれるマネージドサービスがAdaptive Protectionです。
イメージとしては以下の図のように悪意あるユーザの攻撃と判断されたらアラートで通知してくれて、適用すべきルールまで自動的に教えてくれます。
ref: https://cloud.google.com/armor/docs/adaptive-protection-use-cases?hl=ja
なのでサービス側としてはアラートを見て「これは攻撃だろう」と判断したら提案されたルールを適用するだけで防ぐことが可能になります。
つまりAdaptive Protectionを用いることで
といったメリットを享受できます。
続きを読む