寝ても覚めてもこんぴうた

プログラム書いたり、ネットワーク設計したり、サーバ構築したり、車いじったり、ゲームしたり。そんなひとにわたしはなりたい。 投げ銭は kyash_id : chidakiyo マデ

Spanner の DDL (スキーマ)管理を行う hammer を試してみた

f:id:chidakiyo:20200902100259j:plain

Datastore を利用していたときにはスキーマがあってなかったようなものなので、基本的にはエンティティの定義 ≒ スキーマみたいなところがあったが、Spannerは正統派RDB的な振る舞いをするので、 DDL によってスキーマを定義します。

スキーマの設計自体を DDL で行った場合、運用が始まったテーブルに対してはスキーマ自体ではなく、差分のクエリを発行する必要があります。(ALTER TABLE)

RDB を使ってきた人としては「まぁそうだよね」という感じの話ではあるが、毎回差分を把握して ALTER 文を作成するのも面倒なので、そのあたり「いいかんじ」にやってくれるという hammer を試してみます。

hammer をインストールする。

インストールにはバイナリでインストールする方法と、 go get を利用する方法がありますが、私の環境は go がすでにインストールされてるため、 go get コマンドを利用してインストールします。

go get -u github.com/daichirata/hammer

インストールが終わるまでちょっと待ちます。

注意 : Spannerライブラリ1.9 で若干構成が変わっているため go get でインストールできない場合があります。その場合はバイナリからのインストールをおすすめします。(2020/09/02現在)

インストールを確認

以下のコマンドで正しくインストールされたか確認してみましょう

hammer

色々それっぽい情報(?)が表示されれば OK です。(-v オプション実装されてない??)

2つのファイルから差分を出してみる

ドキュメントの例の通り、以下のような2つのファイルを用意してみます。

users.sql

CREATE TABLE users (
  user_id STRING(36) NOT NULL,
) PRIMARY KEY(user_id);

users2.sql

CREATE TABLE users (
  user_id STRING(36) NOT NULL,
  age INT64,
  name STRING(MAX) NOT NULL,
) PRIMARY KEY(user_id);
CREATE INDEX idx_users_name ON users (name);

これらを用意した上で以下のコマンドを実行してみます

hammer diff users.sql users2.sql

結果は以下のように表示されました。

ALTER TABLE users ADD COLUMN age INT64
ALTER TABLE users ADD COLUMN name STRING(MAX)
UPDATE users SET name = '' WHERE name IS NULL
ALTER TABLE users ALTER COLUMN name STRING(MAX) NOT NULL
CREATE INDEX idx_users_name ON users(name)

良さそうな感じですが、befor/after の2つのファイルを用意するというパターンは Git で DDL を管理している場合にはあまり発生しないパターンだと思うので、 Spanner の DB と直接比較するパターンを試してみます。

DB とファイルの差分を出してみる。

先程の users.sql を Spanner 側に適用した状態で、 users2.sql と比較してみます。

hammer diff spanner://projects/{PROJECT_ID}/instances/{INSTANCE_ID/databases/{DB_NAME} users2.sql

コマンドを実行すると以下のような結果が表示されました

ALTER TABLE users ADD COLUMN age INT64
ALTER TABLE users ADD COLUMN name STRING(MAX)
UPDATE users SET name = '' WHERE name IS NULL
ALTER TABLE users ALTER COLUMN name STRING(MAX) NOT NULL
CREATE INDEX idx_users_name ON users(name)

先ほどと同じ感じになりますね。
DBに適用したスキーマをベースに、新しく追加した DDL との差分を得るという運用の場合にはこの感じで利用できそうです。

おまけ : スキーマファイルを Spanner DB に適用する

ファイルを DB に適用する場合には apply コマンドを利用します。

hammer apply spanner://projects/{PROJECT_ID}/instances/{INSTANCE_ID/databases/{DB_NAME} users2.sql

ただ、裏側で何をやっているかあまり把握できていないので、プロダクション環境では利用しない感じでしょうか。

ちょっと不安な点

diff の定義的に、(コマンドでファイル連結するてもあるが) DDL ファイルは1ファイルで管理するイメージになるでしょうか。
テーブルなどが増えてきた際にファイル分割したくなったりするパターンもあるかな?
と思うところもあったので、使ってみて使用感とかまたアウトプットできればと思います。

ではでは。

参考

Spanner で 羃等スキーマ管理をするツール hammer の話 - Qiita

Google Cloud Japan イベントアーカイブ(オンラインイベントのアーカイブ一覧ページ)ができたっぽい

f:id:chidakiyo:20200901134824p:plain

最近は GCP 関連のイベントもほとんどがオンラインになりましたね。

興味ありそうな内容のイベントがあっても気づけなかったり、知っていても調べるのが大変、というのがあったと思いますが、公式にイベントアーカイブページが公開されていました。

Google Cloud Japan '20 イベント アーカイブ - ホーム

とても便利ですね。

私も漏らしているものなど、振り返っていろいろ見てみようと思います。

ではでは。

Cloud Code (IntelliJ) を利用して、 Cloud Run にアプリケーションをデプロイする

f:id:chidakiyo:20200831183254j:plain

タイトルの通り、IntelliJ 版の Cloud Code プラグインを利用して、 Cloud Run をデプロイすることを試してみます。

内容は こちら GCP ドキュメント をベースにしています。

事前に必要なこと

GCP のプロジェクトの課金を有効にしておく必要があります。
また、その他、開発などに必要なツールや、IntelliJ などはすでにインストール済みである前提です。
また、Cloud Run を利用する GCP プロジェクトを事前に作成しておく必要があります。

Cloud Code のインストール (IntelliJ 版)

IntelliJプラグインマーケットプレイスから [Cloud Code] を検索してインストールします。

f:id:chidakiyo:20200831182210p:plain

インストール後は再起動を求められるので IntelliJ を再起動します。

アプリケーションの作成

Cloud Code のテンプレートを利用しながらアプリケーションを作成する場合には、「File]→「New Project」から 「Cloud Code: Cloud Run」 を選択し、プロジェクトを作成します。

f:id:chidakiyo:20200831182248p:plain

今回は言語は 「Go」 を選択しました。

作成されたプロジェクトは、 Web アプリケーションを作成する際の最低限のスケルトンが用意されています。
出来上がったファイルを書き換えるなどしてアプリケーションを作成していくことができます。

f:id:chidakiyo:20200831182341p:plain

アプリケーションを Cloud Run にデプロイする

せっかくなので、一気に Cloud Run へのデプロイまで試してみましょう。

上段の実行バーの中から 「Cloud Run: Deploy」 を選択します。

f:id:chidakiyo:20200831182319p:plain

「▶ Run」 をクリックすることで、初回は「Edit Configuration」 のウィンドウが開きます。

GCP とインテグレーションを行い、 Project を指定した後、Run を起動する際に必要な様々な設定を入力します。

f:id:chidakiyo:20200831182546p:plain

入力内容が問題ないようであれば、最下段の 「Run」 ボタンを押して実行します。

しばらく IntelliJ 上のコンソールにログなどが流れるので、エラーが発生していないか確認しておきます。
ちなみに、このタイミングで Docker image を Build などするようで、端末の Docker を事前に起動しておく必要があります。

流れ的には、ローカルで Docker コンテナのビルド → GCRにpushする → Run へのデプロイを行う ということをやってくれているようですね。
コンテナのビルドがなにげにそこそこ時間がかかるっぽい・・・^^;
初回はキャッシュがなかったりするのでなおさら。気長に待ちましょう。あと、Macがだいぶ唸ります。笑

デプロイが成功すると、コンソールに run にアクセスするための https な URL が表示されます。

URLをクリックすると以下のように Run で公開されたウェブコンテンツを確認することができます。

f:id:chidakiyo:20200831182629p:plain

IntelliJ 上でのステータスの確認

IntelliJ 上で Run にデプロイしたサービスのステータスが確認できるようです。

f:id:chidakiyo:20200831182906p:plain

ログ画面を開くこともできる

f:id:chidakiyo:20200831182938p:plain

めちゃくちゃ便利ですね。

ちょっとだけ更新してみる

これだけかんたんにデプロイまでできたので、ちょっとだけHTMLファイルを修正してデプロイしてみましょう

f:id:chidakiyo:20200831183026p:plain

この画面の It's running! の部分をちょっといじってみましょう。

index.html ファイルの 148行目がこの表示部分に当たります

f:id:chidakiyo:20200831183045p:plain

両脇に星をつけてみましょう

~snip~
<div class="message">
                <h1>★It's running!★</h1>
                <h2>Congratulations, you successfully deployed a container image to Cloud Run</h2>
            </div>
~snip~

変更が完了したら、ファイルを保存し、右上の 「▶ Run」ボタンを実行しましょう

初回とは違い、今回は設定内容などは確認されず、そのまま新しいコンテナがビルドされデプロイが行われます。

このように新しいリビジョンが表示されました

f:id:chidakiyo:20200831183115p:plain

URLからアクセスしてみます。

f:id:chidakiyo:20200831183156p:plain

変更点が反映されましたね。

めでたしめでたし。

Amazon の価格履歴が確認できる Chrome Extension の Keepa を利用したら高値づかみしなくなって QOL 上がった話

f:id:chidakiyo:20200825150709j:plain

みなさん、Amazon で買い物してますか?
以前から、Amazon の価格履歴が確認できるアプリがあることは知っていたのですが、関係ないっしょって感じでインストールしていなかったのですが、何かのきっかけでインストールしてみたら快適だったので共有します。

すでに Keepa をインストールしている人はこのタイミングでブラウザのタブを閉じて良いです。w

よく、 Amazon のタイムセールがタイムセール前に値上げして、タイムセールであたかも大幅値引きしている風に見せる罠などの話を聞きますが、このツールをインストールするだけでそういう罠を回避できます。

比較的高価な家電なども高値づかみすることなく安心して購入でき、いろいろなサイトを検索して最低価格など相場感を調べる時間などが削減できるので個人的にとても助かっています。
(別にお金をもらっている記事ではありません)

どういうもの?

こちら のサイトからインストールできます。
一般的なブラウザは大体サポートしているようです。私は Chrome にのみインストールしているので Chrome の例で下記します。

インストール方法

Chrome ウェブストア からインストールするだけです。

ワンクリックポチーで終了。
これであとは快適な Amazon ライフが楽しめます。

使い方(というほどの話ではないけど説明)

まもなく販売される SonyWH-1000XM4 というヘッドフォンを見てみましょう

f:id:chidakiyo:20200825150739p:plain

まだ発売されていない商品なので価格の変動は少ないですが、なぜか一時期安い時期があったようですね。
その時期に買いたかった・・・

また、M4 の前のモデル WH-1000XM3 に関しても見てみましょう。
プラグインをインストールしていれば↑のリンクから開くだけです。

f:id:chidakiyo:20200825150758p:plain

なるほど、直近が過去イチぐらいの勢いで値段が下がってるようにも見えます。
新しいモデルが出るというタイミングですが、私も M3 を使っていますがとても満足度の高いヘッドフォンで3万以下で買えるのは買いですね。

まとめ

そんな感じで最近 Keepa という Chrome Extension を入れたら買い物が捗るよ、という話でした。

ではでは。

Cloud Run で最新のリリースバージョンにトラフィックを流す

f:id:chidakiyo:20200824092244j:plain

Cloud Run を利用する際、defaultではデプロイした新しいリビジョンに対してトラフィックが移行されるような振る舞いになっていると思います。GAE の gcloud app deploy コマンドで言う --promote オプション相当です。

ただ、Web の UI などから過去のリビジョンにトラフィックを切り替えたりすると、次回からその appendine の --promote オプション相当の振る舞い(新しいバージョンにトラフィックが流れる)が無効になり、前回トラフィック切り替えをした状態が維持されます。

そのため、 gcloud run deploy コマンドで新しいバージョンをどんどんデプロイし、新しいリビジョンでリクエストを処理したい場合には新しいバージョンへのトラフィック切り替えが必要になります。

今回はそれをもとに戻しましょうという記事になります。

必要なコマンド

早速ですが、必要なコマンドは

gcloud run services update-traffic

になります。

GAE に慣れている人の感覚だと gcloud run deploy のオプションにありそうな気もしますが、 Run の場合には Traffic をコントロールするための別のコマンドで操作します。

必要なオプションは

--to-latest
True to assign 100 percent of traffic to the 'latest' revision of this service. Note that when a new revision is created, it will become the 'latest' and traffic will be directed to it. Defaults to False. Synonymous with '--to-revisions=LATEST=100'.

これですね。
マニュアルには default で false になっていると書いてあります。(が、振る舞い的に true な気もするが・・・)

コマンド

以下のようなコマンドで実行します。

gcloud run --project=${PROJECT_ID} services update-traffic --to-latest

最低限上記のオプションぐらいで実行できますが、
--region , --platform あたりの引数を渡すとコマンド一発で実行できるようになるでしょう。

以上です。

参考

https://cloud.google.com/sdk/gcloud/reference/run/services/update-traffic#--to-latest https://cloud.google.com/sdk/gcloud/reference/run/deploy

# Go のテスト並列化してテストが速くなることを改めて確認してみた

f:id:chidakiyo:20200625164918j:plain

Go のテストに並列機能があるので、それで単純に速度アップができるのかという点と、 parallel オプションで並列数操作したらちゃんと反映されるよね。という点を確認した。

早速ソースコード

slow_test.go

func Test_slow1(t *testing.T) {
    time.Sleep(3 * time.Second)
}

func Test_slow2(t *testing.T) {
    time.Sleep(1 * time.Second)
}

func Test_slow3(t *testing.T) {
    time.Sleep(2 * time.Second)
}

fast_test.go

func Test_fast1(t *testing.T) {
    t.Parallel()
    time.Sleep(3 * time.Second)
}

func Test_fast2(t *testing.T) {
    t.Parallel()
    time.Sleep(1 * time.Second)
}

func Test_fast3(t *testing.T) {
    t.Parallel()
    time.Sleep(2 * time.Second)
}

見てわかるように fast の方ではテスト内で Parallel() を呼び出して並列処理を許可している。

早速実行

slow の方を実行する

% go test ./slow_test.go
ok      command-line-arguments  6.276s

6秒ちょい。
3 + 1 + 2 = 6秒なのでだいたい正しい。

fast の方を実行する

% go test ./fast_test.go
ok      command-line-arguments  3.729s

3.7秒。
3並列で実行され、一番遅い3秒のテスト時間+αという感じだろうか。

fast を並列数 1 で実行してみる

% go test -parallel 1 ./fast_test.go
ok      command-line-arguments  6.502s

6.5秒。 期待通り、並列化していない slow の結果とだいたい近い値になった。
Parallel() を呼び出していないものよりちょっと遅いのは Parallel() 呼び出しのオーバーヘッドがそこそこあるのだろうか。

fast を並列数 2 で実行してみる

% go test -parallel 2 ./fast_test.go
ok      command-line-arguments  3.342s

3.3秒。
3 : (1 + 2) で3秒少々で終わったという感じだろうか。

slow を並列数 3 で実行してみる

% go test -parallel 3 ./slow_test.go
ok      command-line-arguments  6.350s

6.3秒。
もちろんそうなるよね。という感じ。

まとめ

Go のテストは実行順序や、同時実行などを考慮しなくて良いテストに関しては Parallel() を実行し、並列化したほうがパフォーマンスが出る。
確認で使った環境は go1.14.3 で、このバージョンであれば、 go test コマンドに特に並列数など渡さなくてもテスト側で Parallel() を読んでいれば必要な数だけ並列化されそう。(もしくはPCのCore数に応じて?)

GitHub Actionsなどは時間課金なのでテスト高速化して削減できそう。

ではでは。

キャッシュレス関連用語集 [経済産業省]

f:id:chidakiyo:20200625113614j:plain

キャッシュレス関連用語集 が公開されていて良さそうな感じだったので。

目次はこんな感じ。
f:id:chidakiyo:20200625113305p:plain f:id:chidakiyo:20200625113448p:plain f:id:chidakiyo:20200625113316p:plain f:id:chidakiyo:20200625113338p:plain f:id:chidakiyo:20200625113349p:plain f:id:chidakiyo:20200625113406p:plain

リンク先はPDFです

https://www.meti.go.jp/policy/mono_info_service/cashless/image_pdf_movie/cashless_glossary_R1_06.pdf