はてなブックマーク

GCPは従量課金なので、こまめに課金額を確認してあげるといいですね！ この記事は、そんな課金額の確認に便利な方法をご紹介します。 BigQueryとは？ GCPの中のサービスの1つで、ビッグデータに対してSQLを書いてクエリを実行し、分析を行うことができるサービスです。 料金体系は大雑把に見るとデータ保存容量のストレージと、クエリ実行時に読み込んだデータ量に対する課金です。 TBを超えるデータを分析するにも便利なBigQueryですが、マシンの管理運用の手間がまったくないため100MB程度のスモールデータを適当に分析するのにも便利です。 課金データをBigQueryにエクスポートする設定 課金データをBigQueryにエクスポートするには、Cloud Console上で設定を行います。 メインメニュー -> お支払 -> 課金データのエクスポート 課金アカウントごとに、エクスポート先のGC

Google Cloud Storage (以下GCS) 上のファイルを結合して、新しいファイルを作成する 複合オブジェクト を紹介します。 gsutil compose GCS上のファイルの結合を簡単にできるのが gsutil compose commandです。 例えば、以下の3つのファイルを結合して、 compose.txt を作成する場合は1commandで達成できます。 gs://cpb100demo1-input/1.txt gs://cpb100demo1-input/2.txt gs://cpb100demo1-input/3.txt gsutil compose gs://cpb100demo1-input/1.txt gs://cpb100demo1-input/2.txt gs://cpb100demo1-input/3.txt gs://cpb100demo1-in

Tableの分割 BigQueryでは日々生まれるデータを扱う場合、TableをDailyで分けていくのが定石としてあります。 現在、BigQueryではDailyで分ける方法が2つあります。 この記事ではそれぞれのやり方をメリット、デメリットをまとめていきます。 Table Wildcard Function Table名の末尾にYYYYMMDDを入れておけば、TABLE_DATE_RANGE Function を使って、指定した期間のTableを1クエリで扱うことができる機能。 Table自体は自分で日付で違うテーブルを作成しているだけ。 2014年春ぐらいにリリースされたような記憶。 Partitioned Table 1つのテーブルのように見えるが、BigQueryの中でDailyに分かれているテーブルを作成する機能。 2016年春にリリースされた。 どんな機能なのかは BigQu

中間テーブルを作成し、分析するクエリを中間テーブルに対して実行するという操作は、パフォーマンス向上や料金の節約のためなどにBigQueryでそれなりによくやる操作です。 一度やるだけならBigQuery Web UIで適当にやればいいんですが、何度も実行する場合や、毎日一回自動でやるという処理をしたい場合、どこからクエリを投げるのか、ちょっと悩むところです。 Compute Engineのcronで設定すると、Compute Engine管理するのが面倒だし、App EngineやGoogle Scriptでやる場合は、そこそこロジック組んであげる必要があります。 ごりごりロジック書ける人は好きな方法でやればいいんですが、今回は適当にブロック繋いでいけば適当にやってくれる MAGELLAN BLOCKS でやるやり方を紹介します。 実行するクエリ bigquery-public-data:

testerator はGoogle App Engine for Go(以下gae/go)のUnit Testを高速化するために生まれたライブラリです。 gae/goはサーバのSpinUp速度がJava, Python, PHPに比べて高速なので、最近App Engine Developerたちの間に人気ですが、いかんせんUnitTestの遅さだけは洒落にならないレベルで遅いです。 それを緩和するために生まれたのが、 testerator です。 testerator がやってくれることを理解するためには、まずgae/goのUnitTestがなぜ遅いのかを理解する必要があります。 gae/goのUnitTestが遅い原因は、テスト環境がgae/pythonの環境に間借りしているからです。 例えば、公式のサンプル にある通り、 aetest.NewContext() を利用すると、裏ではg

What is App Engine FE? App Engineのコンテナを、Dockerベースのものに差し替え、Compute Engineの上で動かす機能 旧 Managed VMs (Managed VMs誕生までの歴史を振り返る) App Engine Architecture App Engine Standard Environment 限定されたコンテナ runtime 縛り (Java, Python, Go, PHP) CPUはシングルコアのみ メモリの最大は1GB App Engine Standard Environment ミドルウェア利用不可 local file systemに書き込み不可 好きなportをlistenできない Compute Engine上にコンテナを立てる Dockerコンテナ 自由な世界 App EngineのAPIをそのまま使える ミド

High Compute Queryは2017年11月に廃止になったので、この記事は過去の思い出です。 https://cloud.google.com/bigquery/docs/release-notes?hl=en#november_14_2017 今後はBillingTierが100を超えない限りは、特に料金が変わることはありません。 BillingTier100超えはかなりの無茶をしないと出てこないので、滅多に気にすることはありません。 ただ、単純なパフォーマンスチューニングとして、以下のノウハウはまだ役に立ちます。 High Compute Queryに備える！Dremelの気持ちになって考えるパフォーマンスチューニング 以下、過去の思い出話となった内容 BigQueryのQuery料金は今までどんな複雑なクエリを書いても、データを読み込んだ容量に対して料金が決定されていました

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? [gcp ja night #28] (http://connpass.com/event/8120/) には、みんな大好きBrianが来て、MVMsについて語ってくれる予定です。 また、@ymotongpooさんもGAE/GoとManaged VMについてのSessionです。 今年のGoogle I/Oでも、Sessionがあり、徐々にリリースの足音が聞こえてきているMVMsですが、今まであまり気にしていなかった方や、普段GAEを使っていない方には、なぜMVMsが生まれたのかが、ピンと来ない方もいらっしゃるのではないでしょうか？ そ

instance_class: F1 automatic_scaling: target_cpu_utilization: 0.6 # default value target_throughput_utilization: 0.6 # default value max_instances: 5 min_instances: 5 max_idle_instances: automatic # default value min_idle_instances: 3 min_pending_latency: 30ms # default value max_pending_latency: automatic max_concurrent_requests: 80 target_cpu_utilization CPU利用率のしきい値で、0.5〜0.95の値を指定できる。デフォルトは 0.6

Google Cloud Shell? Cloud ShellはDevelopers Consoleの機能の1つで、Debian-based LinuxのShell環境を貸してくれる機能です。 gcloud sdkを始めとして、色んなtoolを最初からインストールしてくれているので、軽く何か試そうという時に便利な環境です。 DiskもUser毎に5GB使えるようになっているので、git cloneしたり、Cloud StorageやBigQueryのExport結果を、Diskに保存することができます。 ただ、$HOME以外はCloud Shellを再起動すると初期化されるので、注意してください。 何がインストールされているかは、Available toolsに書いてあります。 適当に抜粋してみます。 Available tools bash sh Google App Engine SD

従量課金のクラウドサービスを使う場合、クラウド死しないかドキドキしますよね！ クラウド死を予防するために、GCPには [Billing Alert] (https://support.google.com/cloud/answer/6293540?hl=en&ref_topic=6288636) の機能があります。 Billing Alertを設定しておくと、予め設定した閾値の50%, 90%, 100%を超えた時点で、メールを送ってきてくれます。 課金はリソースを追加する度にリアルタイムで発生するので、短い期間で大量の課金が発生した場合は、防ぎきれないかもしれませんが、リソースを消し忘れて1ヶ月放置していて、月末の請求で気付くというのは、Billing Alertを設定すれば、だいぶ無くなると思います。 設定の仕方 Billing AlertはBilling Account毎に設定するの

アクセストークンの生成 https://github.com/settings/tokens の手順に従いアクセストークンを生成する Github APIを叩く！ App EngineからHttp Requestを投げる時はurlfetch apiを利用する Authorizationにアクセストークンを入れるのを忘れずに！ Markdown API を叩いている雑な例 import ( "bytes" "encoding/json" "io/ioutil" "net/http" "google.golang.org/appengine" "google.golang.org/appengine/urlfetch" ) type MarkdownPostParam struct { Text string `json:"text"` Mode string `json:"mode"` Co

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

gae/goはSDKの中にgoそのものも内包しているため、GOROOTとGOPATHを切り替えてやる必要が出てきます。 shellで切り替えても良いのですが、環境を切り替えるためのtoolにgoenvがあるので、今回はこちらを使って環境を切り替えるやり方を紹介します。 goenv install goenvのinstallは公式Documentに書いてある通りです。 projectを作る goenvを利用してgae/go用のprojectを作ります。 $ goenv -gae -go /Users/sinmetal/bin/google-cloud-sdk/platform/google_appengine/goroot -deps /Users/sinmetal/go sample Environment /Users/sinmetal/Documents/temp/sample cre

Google Cloud Platformにはエッジキャッシュの機能がある。 あんまりDocumentにも乗ってないので、今回はエッジキャッシュを紹介します。 エッジキャッシュの特徴 エッジキャッシュはGoogleが利用しているキャッシュサーバに、自分のGCP上のコンテンツも乗せることができる機能です。 GCPのキャッシュサーバは全世界にあるため、日本だけで無く、海外も視野に入れたサービスでも有効です。 特徴 すさまじいキャパシティ とっても安価 キャッシュサーバの管理はGoogleで行ってくれる上に、すさまじいキャパシティを誇り、google.co.jpが落ちるぐらいのトラフィックが来ない限りは、問題ないとまで言われています。 料金も非常に安く、うまく使えば課金額を1桁減らしてくれます。 注意点 アクセス制御は使えない キャッシュに乗っている時間はベストエフォート キャッシュを明示的に消

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? GAEには Backend API という機能がありましたが、SDK 1.8.2で Modules API がリリースされ、その後、Backend APIは非推奨となりました。 このTopicではModulesとは何か？、Modulesの使い方、そして既存アプリの簡単な移行手順について説明します。 Modulesとはなにか？ 元々GAEにはVersionという機能がありましたが、Modulesはその上にもう1階層を作ったサービスです。 既存のGAEAppのVersionは、Modulesではdefault Modulesの各Versio

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? GCS ACL について Google Cloud StorageはBlobstoreと違い、ACLによるアクセス制御ができる。 設定できるスコープ Google Storage ID Google account email address Google group email address Google Apps domain Special identifier for all Google account holders Special identifier for all users Google Storage ID Go

GAEでユーザからのファイルのUploadなどを受け取る場合、選択肢は2つあります。 Blobstore Google Cloud Storage (以下GCS) Blobstoreは昔からあるServiceで、GAEにくっついて存在するServiceです。 GCSはGoogle Cloud Platform の中でFileを扱うことに長けたServiceです。 将来的にはGCSに集約したいという話もあるので、これからGAEでアプリを作る場合は、GCSを選択するのが無難でしょう。 この記事ではGAE/j (Slim3)からGCSのファイルを扱う方法について書きます。 GCSの設定 Productionで動かす場合、GCSの設定を行う必要があります。 GCSの設定については、こちらの記事を参照してください。 Localで試すだけなら、この設定はする必要はありません。 Google Cloud

golangにはgo testというunit test用の機能があります。 testを行うための testing package もあります。 しかし、gae/gでは、appengine固有の部分が動かないため利用できませんでした。 そこを解決するために以下のlibraryなどもあったのだけど、 gae 1.8.6でついにgae/gでもunit testができるようになりました！ Local Unit Testing for Go gae/g unit testで重要なのは、以下の3つです。 goapp test appengine/aetest testing この3つを抑えておけば、とりあえずunit testを作り始めることができます。 goapp test goapp testはgae/gでunit testを実行するためのcommandです。 通常、golangでは、go tes

Google Cloud Platform の中でファイルを扱う位置にいるのが Google Cloud Storage (以下GCS) です。 この記事では、同じく Google Cloud Platform に属する Google Appengine (以下GAE) からGCSのファイルを扱うための設定について書きます。 Cloud Console Projectの作成 GAEのProjectを作成すると、Cloud Console Projectも自動で生成されます。 GAEのProjectを作った後に Cloud Console にアクセスすれば、GAE AppIdと同じ名前のProjectが作られているはずです。 Billing設定 GCSを利用するためにBilling設定が必要です。 Cloud Console ProjectのMenuからBillingを選択し、クレジットカー

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

このTopicはWeb ApplicationのfrontendのProjectを管理するTopicの2つ目です。 node.jsのversionを管理するためにnodebrewを利用する npmでnode.jsのpackageを管理する grunt.jsを使って、frontendのビルドを行う 前提条件として、僕の環境はMac OSです。 ##npmとは？ npmはnode.jsのpackageを管理するためのツールです。 node.js自体はJavaScriptで出来たWeb Serverですが、frontendを管理するためのtoolもたくさんあります。 npmはnode.jsのpackageを管理すためのツールです。 Javaが分かる方は、mavenのようなものだと想像していただければ、分かりやすいかと思います。 ##npmでpackageをインストールする npmでpackage

このTopicはWeb ApplicationのfrontendのProjectを管理するTopicの3つ目です。 node.jsのversionを管理するためにnodebrewを利用する npmでnode.jsのpackageを管理する grunt.jsを使って、frontendのビルドを行う 前提条件として、僕の環境はMac OSです。 grunt.jsとは？ grunt.jsはnode.js上で動くTask Runnerです。grunt.jsそのものがビルドなどをしてくれるわけではなく、あくまでgrunt.jsは指定されたTaskを実行するだけです。 実際にビルドを行うためには、gruntを取り巻くたくさんのpackageを利用して、自分が望む内容を実行する環境を構築していく必要があります。 このTopicでは、その入り口として、grunt.jsでいくつかのpackageを実行できる

AngularJSで共通メニューを表示するための機能です。 機能としては、リンクをクリックした時に、classを変更してカレントページをハイライトしています。 前に作成したVersionだとclassにdirectiveを設定しないといけないので、htmlとの分離がいまいちという話があったので、改訂版を作成しました。 実際に動いているのはAngularJS Sampleにあります。 AngularJSのdirectiveを使って、作っています。 app.directive('navitop', function () { return { priority: 0, templateUrl: '/html/common/topmenu.html', replace: false, transclude: false, restrict: 'E', scope: false, controll