「GCP」の記事 - Crieit

数日で有料サービスをリリースしてみた話

2021-11-17T09:36:55+09:00

有料サービスを２，３日位で作ってリリースしてみました。多分計10時間ほど？　急にぱっと思いついて次の日の夜くらいにはだいたい完成していました。作ったのは下記のHand Refactorerというプログラムのコードを手動的にリファクタリングしてくれるサービスです。

130円でプログラムのコードを手動的にリファクタリングしてくれるサービスをリリースしました。プログラミングを始めたばかりの方にはもしかしたら役立つ場合もあるかもです。よろしければお試しください！！https://t.co/bHlNXJFbTh pic.twitter.com/VhPI80a6Cl
— だら@Flutterもやってる (@dala00) November 14, 2021

ちなみにこれ自体は単に自動的じゃなくて手動かよというツッコミがほしいだけのために作ったネタクソアプリです。

色々やるべきことを削ったりなどで考えたりしたので書いておきます。

サービスの流れ

そもそもサービスの流れですが、まずユーザーがリファクタリングしてほしいコードを入力して登録します。

それを僕が人力でリファクタリングし、回答として登録するとユーザーがそれを確認できる、という形です。

課金関連の開発を極限まで削る

課金となると、結構色々考えなければなりません。ユーザー登録し、そのユーザーに対して課金ログを保存し、購入履歴などを用意する必要があります。ただそこまでするとどうしても工数がかかってしまいます。そのため下記のようにして開発事項を削りました。

オーソリを使う

オーソリというのは、仮売上です。即課金確定するのではなく、注文が確定した時にキャプチャという処理を行って決済を確定させる方法です。ユーザーが注文してきた時に仮売上とし、僕が処理を行って納品でき、ユーザーがそれを意図的に閲覧した場合に納品確定としキャプチャを行うようにしました。

この方法には色々メリットがありました。

ユーザーの心理的不安を取り除ける

個人サービスですので、そこに課金するのにはちょっと不安があります。ただ、ちゃんと納品が行われないと課金が確定しないということが事前にわかっていればその不安をある程度取り除くことができます。

確定する場合には、ユーザーに回答画面のURLが貼られたメールが送られます。ここでも実際に見て課金を確定するかどうかをユーザーが意図的に選ぶ事ができます。興味がなければ見ずに終わらせればいいですし、お金を払ってでも見たいと思っていれば閲覧して確定できます。

運営側の不安も取り除ける

個人サービスで課金機能を提供するのは、運営者としてもなかなか気持ち的に不安になることが多いです。うまくサービスを提供できなかったらどうしよう、大きなミスに気づかず迷惑をかけてしまったらどうしよう、など。

しかしオーソリを利用してユーザーがお金を払って結果を見たいと確信して行動する時に初めて課金が行われるようにすれば、なかなか間違えたり問題が起こる可能性は低くなります。そうなると運営側としても問題が発生しにくく安心です。

また、最悪僕が怠けたりなにか急なトラブルで全然手を付けられず放置したとしても一切課金されることはありません。また、そんなにリファクタリングすることがないコードであれば確定しないことでキャンセル扱いにすることもできます。

このようにしてお互いの不安をなるべく少なくすることでユーザーは購入を、運営はリリースをしやすい気持ちにできるようにしました。これができなければ色々と複雑なテストをしたり入念にいろいろな機能をつくったりしてなかなかリリースはできなかったでしょう。

チェックアウトを使わない

Stripeにはチェックアウトというプログラムを書かなくても商品を売れる機能があります。すごく簡単なのですが今回はそれは使いませんでした。というのも売上の結果を知るためにWebhookでチェックする必要があり、ちょっとそれが面倒でした。プログラムで決済してしまえば登録時に一緒にやってしまえばすべてが終わるためそちらの方が処理的にもわかりやすくテストもしやすかったためです。

メールアドレスを使う

メールアドレスを使うことでログイン機能を削りました。ユーザー登録をすると、やはり離脱率は上がります。ちょっと投稿して利用するだけのサービスでユーザー登録は面倒くさいです。

また、ログイン機能を作るとそれはそれで結構面倒です。Next.js と Firebase を使っているのですが、それで認証を入れるとFirestoreのセキュリティルールも設定しなければなりませんし、その状態だとNext.jsのサーバーサイドレンダリング時にエラーが発生することもあり、結構確認事項が増えます。ログイン機能を作らずメールアドレスのみの照合とすることでそれら全ての開発を削りました。

メールアドレスだけでは勝手に決済されて危険なのでは？　と思われるかもですが、クレジットカード自体は操作している人自身のものを入れなければならないためなりすましは難しいですし、できたとしても結局オーソリまでしか進めないため、利用者が最後まで進まないとお金は一切動きません。

またこれにより結果のURLはメールで本人しか知ることができないため漏洩の心配などもありません。

最初はユーザーもメールアドレス登録するのはいやかな…とも思ったのですが、そもそも大量の依頼がくるとそれはそれで僕のスケジュールがパンクしてしまうのである意味抑制になっていいかなと思っています。

極限までハードルを下げる

このハードルというのはユーザー、運営者両方のことです。

まず費用は130円という自販機でジュースを買うのと同じ（？）ような料金にしました。また、説明分にはレジャー感覚で使ってほしいということ、意図した結果が帰ってくるとは限らないということを書いておき、運営者的にもちゃんとした結果をださなければ、という不安をなくし、利用者としてもさほど結果に期待しない状態を作っておきました。

ハイクオリティになったり、ハードルの認識の齟齬があると開発もそれに対処するためにちょっとやることや考えることが増えたりなど、すぐにリリースはできません。とにかくすぐに作るレベルのサービスに連動したクオリティの商品をそれに見合った低価格で提供することによってリリース時の負担を下げました。

管理機能を公開しない

リファクタリング結果の送信ですが、Firestoreのダッシュボードだけではできません。そのためそこは返答用の画面を作ってあげる必要がありました。

しかし前述の通り認証もありませんし、URLを作ってしまうと万が一アクセスされてしまった時に情報が漏洩してしまいます。

そのため管理画面は公開せず、別プロジェクトとして作り、ローカルのデバッグ実行だけでできるようにしました。絶対に他の人にアクセスされることもありませんので安全です。また、作っていたプログラムをコピーするところから始めたのでベース部分はまるまる流用でき、特に大変でもありませんでした。

Firebaseクライアントを使わず全部APIのみにする

前述の通り、セキュリティルールを設定するのが面倒だったためFirebaseのクライアントはアクセス解析にしか使っていません。セキュリティルールは全部のデータへのアクセス不許可にしています。

普通に単なるAPIとしてfirebase-adminを利用してサーバーサイドのDBのようにして作っています。なにもかんがえることもなく非常に楽です。勝手に変なデータにアクセスされてしまうこともありません。

また、Firestoreを使うことによってデプロイする場所を選ばなくてもよいようにもなっています。

今回はCloud Runにデプロイしました。前述の通りDBはFirestoreなのでどこにでもデプロイできます。本来はVercelが一番楽なのですが、この無料プランは個人的な利用のみに限られますので、今回の場合は利用できません。ということでCloud Runを使いました。GitHubにpushしたのに連動して自動的にデプロイもできますし。Herokuでも良いと思いますが頻繁に利用されるサービスではありませんし、あまりアクセスして遅いのもあれかなと思いCloud Runにしました。

せっかくなのでDockerfileを使わないでデプロイできるBuildpackというものを試してみたかったというのがあったのですが、どうもビルド無しで実行されてしまうようでエラーになったので今回は諦めてDockerfileを使うことにしました。だいたいDockerfileならどっかーにあると思いますので。

今回は下記を使いました。
【Node.js/Next.js】Cloud Runで動作する軽量なDockerを構築してみた

これの真ん中のやつでだいたいデプロイに8分ほどかかります。それほどパフォーマンスが必要ではないので一番最初の簡易的なやつでも良かったのかもしれません。なんにしろVercelよりはやはりどうしても遅くなってしまいますね。

あと日本リージョンにしたのでちょっとネットワーク料金がかかります（アクセスがちょっと多ければ月何十円とか100円とか？）

CSSも使わない

今回はChakra UIを使いました。とにかくデフォルトのデザインパーツで、カスタマイズは全部Chakraコンポーネントのプロパティのみで、ぶわっと作りました。非常に楽です。

DIFFの表示

リファクタリングということで、DIFFを表示したほうがわかりやすいかなと思いました。

React Diff Viewerというのを使いました。
https://github.com/praneshr/react-diff-viewer

まとめ

最初に書いたとおりクソアプリですので、ものすごい依頼が増えない限りは特にアップデートする予定はありません（依頼がきたらちゃんと対応します。リファクタリングは結構好きなのでわりと楽しんでやっています）。

ただ数日で作れたので、これを機に低価格で同じように自分で提供できることを売るのも面白いかなとは思います。どうしても手がかかるので規模が大きくなるとスケールもしないし限界がありますので、あくまでも今回のようにジョーク交じりかつすごく負担の少ない作業だけになるとは思いますが。

逆に言うと、低価格でちょっとなにか提供できる、というひとはたくさんいると思いますので、みんながこういうサービスを各々作れたら面白いのにな、とも作ってる途中に思いました。例えば小説の手直し、絵の手直し、もしくはちょっとした絵を書いてあげたり、サービスの感想を伝えてあげたり、なにか写真をとってあげたり、ロゴをつくってあげたり。皆自分の得意なことを提供して少しでもお金になれば楽しいのでは、と思いました。

もちろんそういうモール的なサービスはいくつかあると思いますが、あくまでも自分の個人商店的な感じで運用するのも面白いと思います。

自分でみんながそういうことを提供できるサービスを作ればよいのでは、とも一瞬思ったのですが、やはり価格的に運営者に入るお金はかなり薄利になり、儲けを出すにはかなり大量に集客しないといけませんし個人だと逆に大変なことが多そうなので、無理かなと思いました。Skebのもっと安くて気軽バージョン的な感じかもです。

なので可能な方は是非同じ様なサービスを作ってなにか提供してみると面白いのではないかと思います。

☆GCPのGCEでVNCのOBSしたやつは、やつの名は、openSUSE…!!

2020-12-12T10:06:10+09:00

☆GCPのGCEでVNCのOBSしたやつは、やつの名は、openSUSE…!!

はじめに

この記事はopenSUSE Advent Calendar 2020 - Adventarの12日目の投稿です。

このたび2年ぶりに参加をキメてみました。普段はDesktopでTumbleweedを使ってソフトウェアを書いたり書かなかったりしていますが、今回はGCP：Google Cloud Platrofmに関するお話をしたいとおもいます。

このお話は、先月11月28日にオンライン開催されたOSC福岡のライトニングトークセションで発表された資料から、クラウドコンピューティングに関する部分を詳解したものです。

なんなのか？

かいつまんで概要を解説しますと、昨今流行りのブロードキャスト映像配信システムをクラウドコンピューティングで実現してみたやつです。図で表すとこのような感じですね。

GCPが提供するクラウドコンピューティング、それはGCE：Google Compute Engineでワタシは4歳でした。
その味は甘くてクリーミィで、こんな素晴らしいCompute Engineを使えるワタシはきっと特別な存在なのだと感じました。

今ではワタシがオジイサン、インスタンスにあげるのはもちろんopenSUSE。
なぜなら、彼もまた特別な存在だからです。

なぜなのか？

補足しますと、Google Compute Engineというのは、クラウド上に仮想のコンピュータを作成して、インターネット経由で操作することが出来る仕組みを提供してくれるサービスです。たぶん。
で、作成された仮想のコンピュータのことをVMインスタンスみたいに呼びます。

※画像はイメージです。

インスタンスは仮想のコンピュータですので、OSが必要になりますよね。インスタンスにあげるのはもちろんopenSUSE。
なぜなら、彼もまた特別な存在だからです。

あるんかいないんかい

ということで、AMD Epyc CPUの搭載されたファンタスティックなインスタンスを作成しました。OSはもちろんopenSUSE、ブートディスクから接続されているイメージを変更してopenSUSEを選択しましょう。

そんな、ばかな……

ないんかい

最近ちょっと目が悪くなってきたのかもしれないのですが、見つからないです…。
昔はあったような気がするんですけど、選択できるOSが見つかりません。これではインスタンスを作成することが出来ないッ！一体どうすれば……

※注：この記事はopenSUSEアドベントカレンダーなので、openSUSEが見つからなければこの章で打ち切り未完丸投げ終了なんですが、皆様はぜひ親しみやすいOSを選択してご活用いただければ幸いです。

あるんかい

黒い画面「 ^ ^ ありまっせ」

コミュニティでサポートされるイメージ | Compute Engine ドキュメント | Google Cloud

ありました。

そう、よりオープンソースソフトウェア色の強いコミュニティサポートイメージとしてなぁッ！！

これをこうしてこうじゃ！

GCPは、ブラウザのコンソールからクラウドシェルっていう機能で黒い画面にgcloudというコマンドを入力することでも操作が出来ます。

なので、これをこうして、こうじゃぁあああ！！

gcloud compute disks create 作成するディスクの名前 --image-project=opensuse-cloud --image=opensuse-leap-15-2-v20200702 --type=pd-ssd --zone=ディスクを作成するゾーン --size=40GB

うまくいきおったら、冒頭のブートディスクに接続されているイメージを変更して、既存のディスクから作成したopenSUSEを選択できるようになっていますわい。

やったぜ！！

では早速起動してみましょう。

やったぜ！！これでyastし放題の心置きなくzypperできる、とびっきりのわがままインスタンスの完成ですね。

ゴエー！ブラウザで開くとフォントゴエー！！

ここから先は君たちの目で確かめてくれッ

ということで、ここから先はopenSUSEの話になりますので、GCPのGCEにあるopenSUSEを使って、自由自在にopenSUSEしてください。ありがとうございました。

―　完　―

おまけコーナー

上記のopenSUSEを、とびっきりのわがままopenSUSEして動画配信をしたときの様子は下記のとおりです。

こんな感じで、実際のオンラインカンファレンスの様子をリアルタイムで配信するシステムとして使われました。

https://youtu.be/r_DiQTWEOwc

予告編壱

上記内容の動画配信システムを作って配信する内容の電子奇書を技術書典10で頒布予定です。果たして原稿はあがるのか！？乞うご期待。

技術書典10

予告編弐

上記GCPのGCEに作られたAMD Epyc インスタンスで動作するファンタスティックopenSUSEが、バックヤードで大活躍するとまことしやかに囁かれているフルオンラインカンファレンス、DojoCon Japan 2020。

スタッフ一同鋭意開催準備中です。

2020年12月27日に、ご期待下さい。

DojoCon Japan 2020 - Beyond the distance(距離を超えて) -

いかがでしたか？

全然詳解されていないし、GCPの年収、最終学歴も公表されていないようです。調べてみましたが、結論はわかりませんでした！

気に入ったらぜひ、いいね、チャンネル登録、金塊送付をしてくださいね！

この記事はopenSUSE Advent Calendar 2020 - Adventarの12日目の投稿でした。

ひきつづき、openSUSE Advent Calenderをお楽しみ下さい。

Cloud RunでRate exceededエラーになる

2020-08-14T23:54:11+09:00

ある日突然Cloud Runにデプロイしているサービス（当サービス）にアクセスすると無情にも「Rate exceeded.」とだけ表示されるようになっていた。エラーログを見てみるとステータスは429、エラー詳細を開くと「The request was aborted because there was no available instance」と表示されている。

原因自体は初めてデプロイした時あたりにも出ていたのでわかる。Cloud Runには最大インスタンス数の設定があるのだが、それが足りないため。たしか最初は1～3あたりにしていたような気がする。それだと時々Rate exceededとなるため10くらいに増やしていた。それ以来自分は見ることがなくなった。

しかし突然の再発。原因は分からないが、引き金はクローラのアクセスが集中したりしたのかもしれない。想像でしか無いが、ただ時々クローラがアクセスしてきてエラーが大量に出ているのは見かける。

しかし今回は復旧する様子がない。22時くらいに発生し、色々と確認した。しかし原因はよく分からず。最大インスタンス数は20とか100とかにして試した気がするが、それでも復旧しなかった。原因が原因だけにもしかしたら放置しておけばいつの間にか治るかな、と思い、とりあえずねた。しかし次の日になっても治っていなかった。もしかすると時差の関係もあるのかなと思い一応夕方くらいまで待ってみたが、相変わらずだった。

解決した方法

最終的に、最大インスタンス数の設定を1000にしたら動くようになった。さすがにそんなにアクセスが続いているわけもないと思うのでなぜそこまで上げなければならないのか結局よくわからないまま……。

気づいたのは、Cloud Runにあるデモイメージを試してみたら動いたため。それは何の設定もいじっていなかったので最大インスタンス数が1000になっていた。

とにかく困ったら上限の1000まで上げてみるとよいかもしれない。

今回は一時的な問題かも

というか、今回のこれは僕以外も何人か発生してるのを観測したので一時的に発生している問題かもしれない。（多分書いている時点では未解決）

Googleスプレッドシートのシフト表を使ってTwilio Studioフローの転送先をNode.jsから更新する方法

2020-05-27T15:21:26+09:00

以前の記事で、在宅勤務に伴う電話問い合わせの一時休止を解決する方法として、Twilio Studioを利用し個人電話に転送する方法を紹介しました。

今回は別の記事で紹介したGoogleスプレッドシートのシフトデータをもとに転送先となる個人をNode.jsで変更する方法を紹介します。

前提条件

Twilioアカウントを持っていること（無料トライアルのサインアップ方法）
期間限定の問い合わせ番号となる電話番号を購入していること
（日本の番号を取得する場合）
こちらの記事に則りフローを作成、公開済みであること
こちらの記事に則りGoogleスプレッドシートからデータを取得するNode.jsアプリケーションを作成済みであること

Node.jsプロジェクトの作成とパッケージのインストール

以前の記事に沿って作成したNode.jsアプリケーションのフォルダーに移動し、twilio-nodeパッケージをインストールします。

npm i twilio

次に.envファイルにTwilioへの接続情報やStudioフローのIDを保存する環境変数を追加します。

SPREADSHEET_ID=
STAFF_WORKSHEET_ID=
SHIFT_WORKSHEET_ID=
TWILIO_ACCOUNT_SID=
TWILIO_AUTH_TOKEN=
TWILIO_STUDIO_FLOW_SID=

Twilio Studio REST API v2を使ったフローの取得と更新

今回利用するTwilio Studio REST API v2は4月末にパブリックベータとしてアナウンスされたばかりの機能です。この新しいAPIを使って定義済みのフロー設定を外部から更新できます。

Twilioコンソールを開きACCOUNT SIDと、AUTH TOKENをそれぞれ.envファイルの TWILIO_ACCOUNT_SIDならびに TWILIO_STUDIO_FLOW_SID の値として設定します。

次に、Studioコンソールを開き、call forwardingフローのSIDを TWILIO_STUDIO_FLOW_SID の値として設定します。

index.jsを開き、前回の記事でテストに使用したコードを変更します。このコードでは、シフト担当者の電話番号を取得した状態で、Twilio Nodeクライアントを利用しStudioフローを取得します。

loadShiftPhoneNumbers().then (
    numbers => {
        // twilio client
        const client = require('twilio')
           (process.env.TWILIO_ACCOUNTSID,
            process.env.TWILIO_AUTH_TOKEN);

        // Studioのフローを取得
        client.studio.flows(process.env.TWILIO_STUDIO_FLOW_SID)
            .fetch()
            .then(flow => {})
            .catch(error => console.error(error))
    ;})
    .catch( error => console.error(error));

フローの定義情報は、definitionというプロパティに保持されているため、そちらを取得します。また、各ウィジェットについては、statesというプロパティに配列として定義されています。このstates配列からウィジェットの名前をキーとして着信を転送するウィジェットを取得し、更に転送先番号を更新します。

loadShiftPhoneNumbers().then (
    numbers => {
        // twilio client
        const client = require('twilio')
           (process.env.TWILIO_ACCOUNTSID,
            process.env.TWILIO_AUTH_TOKEN);

        // Studioのフローを取得
        client.studio.flows(process.env.TWILIO_STUDIO_FLOW_SID)
            .fetch()
            .then(flow => {
                // フローの定義を取得
                let definition = flow.definition;
                // forward_callウィジェットを取得
                let callForwardWidget = definition.states.find(
                    item => item.name == 'forward\_call');
                // 転送先番号をシフトの電話番号で更新
                callForwardWidget.properties.to = numbers;
            })
            .catch(error => console.error(error));
    })
    .catch( error => console.error(error));

後は更新した定義をStudio REST API v2を使い、反映させます。この際、statusプロパティで反映したフローを下書き状態（draft）にしておくことも、即座に公開（published）にすることもできます。

loadShiftPhoneNumbers().then (
    numbers => {
        // twilio client
        const client = require('twilio')
           (process.env.TWILIO_ACCOUNTSID,
            process.env.TWILIO_AUTH_TOKEN);

        // Studioのフローを取得
        client.studio.flows(process.env.TWILIO_STUDIO_FLOW_SID)
            .fetch()
            .then(flow => {
                // フローの定義を取得
                let definition = flow.definition;
                // forward_callウィジェットを取得
                let callForwardWidget = definition.states.find(
                    item => item.name == 'forward\_call');
                // 転送先番号をシフトの電話番号で更新
                callForwardWidget.properties.to = numbers;

                // 更新した定義を反映し、即座に公開
                client.studio.flows(process.env.TWILIO_STUDIO_FLOW_SID)
                    .update({
                        definition: definition,
                        commitMessage: 'シフトの更新 - 2020/05/15',
                        status: 'published'})
                    .then(res => console.log(res))
                    .catch(error => console.error(error));
            })
            .catch(error => console.error(error));
    })
    .catch( error => console.error(error));

index.jsを実行し、ログにエラーが含まれていないこと、Studioのフローが実際に変更されていることを確認しましょう。

node index.js

まとめ

ご覧いただいたように、パブリックベータとして公開されたREST API v2を活用することで、外部のデータやシステムと連携した上でTwilio Studioのフローを更新することができるようになりました。非常に強力なAPIなので、ぜひご活用ください。

今回のサンプルはこちらのGitHubリポジトリからクローンし、環境変数にそれぞれ値を設定することで確認することも可能です。

新型コロナウイルス感染症への支援策について

Twilioでは新型コロナウィルス感染症により引き起こされるさまざまな社会問題を解決する会社、団体、開発者グループに向けて無料クレジットの進呈など支援を行なっています。詳しくはこちらの記事をご覧ください。

また、Twilioを自社のシステム、ソリューションやパッケージに組み込みたいとお考えの場合は、営業部までお問い合わせください。

このエントリについての問い合わせ

不明点があればぜひ、お問い合わせください。オンライン登壇のご依頼等もこちらまで！

GoogleスプレッドシートからNode.jsでシフトデータを読み出す方法

2020-05-20T16:34:57+09:00

Google Cloud Platform（GCP）にはGoogle Sheets APIが提供されており、このAPIを利用してGoogleスプレッドシートのデータにアクセスすることができます。今回はGoogleスプレッドシートのスタッフ、シフトデータをNode.jsで読み込む方法を紹介します。

前提条件

Google Cloud Platform （GCP）のアカウントの作成、ならびに有効な支払い方法が登録されていること
Googleスプレッドシートを利用できること

シフトを管理するGoogleスプレッドシート

こちらにスプレッドシートのサンプルを用意しました。ファイルメニューからこのスプレッドシートを自分のGoogleアカウントで利用できるようにコピーします。スプレッドシートの中身をみてみましょう。Shiftシートには日ごとの担当者を4名まで設定しています。

また、Staffシートには担当者ごとの連絡先電話番号がE.164フォーマットで登録されています。

GCPでSheets APIを有効化

はじめてGCPを利用する場合は、コンソールからプロジェクトを作成します。

例ではプロジェクト名を google-sheet-studio としましたが、任意のプロジェクト名で構いません。

作成ボタンをクリックするとリソースの管理画面に戻り、プロジェクトの作成が開始されます。数十秒〜数分程度で作成が完了します。

次にAPI ライブラリを開きます。

先ほど作成したプロジェクトが選択されていることを確認します。

Google Sheets APIを検索し、プロジェクトに追加します。

詳細画面から 有効にする ボタンをクリックするとGoogle Sheets APIが有効になります。

APIが有効化されると、概要画面に遷移します。次に 認証情報を作成 ボタンをクリックし、このAPIを使用するための認証情報を作成します。

認証情報の追加画面において次の設定を行い、必要な認証情報 ボタンをクリックします。

使用する API - Google Sheets API
API を呼び出す場所 - ウェブサーバー（node.js、Tomcat など）
アクセスするデータの種類 - アプリケーションデータ
App Engine または Compute Engine でこの API を使用する予定はありますか？ - いいえ、使用していません

続けてサービスアカウント名とロールを設定します。例では、test およびロールを Project の 閲覧者 とし、キーのタイプを JSON としました。

次へ ボタンをクリックすると認証情報を含んだJSONファイルが作成されダウンロードされます。このファイルはGoogle Sheets APIを利用するために必要になります。作成されたJSONファイルを開くと client_email という名前のキーの値に先ほど作成したサービスアカウント IDが記載されています。Googleスプレッドシートを共有する際にこの情報が必要になります。

Googleスプレッドシートの共有とURLや情報の確認

次に、Google Sheets APIからアクセスをできるようにGoogleスプレッドシートをサービスアカウントに共有します。先ほど複製したGoogleスプレッドシートを開き、右上の 共有 ボタンをクリックします。表示された共有ダイアログに先ほどのサービスアカウント IDを入力します。

Enterキーを押すと、権限の設定を行えます。書き込み権限は必要ないため閲覧者としました。共有 ボタンをクリックし、共有を完了します。

更に、このGoogleスプレッドシートから次の情報を控えておきます。

スプレッドシートID（https://docs.google.com/spreadsheets/d/ の後に表示されている英数文字列のうち、次の’/’ の前の値。例: https://docs.google.com/spreadsheets/d/ 12312321xxx21232131212 /edit#gid=0 の太字部分）
Shift、StaffそれぞれのワークシートのID（URLが #gid=0 の場合は、 0 となる）

これでシートから情報を取得する前準備が整いました。

Node.jsプロジェクトの作成とパッケージのインストール

Google Sheets APIを利用することでGoogleスプレッドシートのデータにアクセスすることができます。このAPIに対応するNode.jsクライアントライブラリも用意されており、クイックスタートのようにセルの値を取得することもできるのですが、取得するセルの範囲を指定する必要があり、使いにくいと感じるかもしれません。そのため、今回はGoogle Sheets APIを使いやすくラップしたgoogle-spreadsheetパッケージを利用します。このパッケージを利用すると、セルの範囲を指定することなく、ワークシートから行オブジェクトとしてデータを読み込むことができます。

Node.jsアプリケーションを作成し、google-spreadsheetと環境変数を.envファイルからロードできるdotenvパッケージをインストールします。

npm i google-spreadsheet dotenv

次にGoogleスプレッドシートやシートのIDを記録しておく.envファイルを作成します。

touch .env

.envファイルには次の環境変数を追加しておきます。

SPREADSHEET_ID=
SHIFT_WORKSHEET_ID=
STAFF_WORKSHEET_ID=

SPREADSHEET_ID、STAFF_WORKSHEET_ID、SHIFT_WORKSHEET_ID には先ほど控えておいたGoogleスプレッドシートのIDやそれぞれのシートのIDを追加します。

最後にGCPからダウンロードしたJSONファイルをプロジェクトフォルダーにコピーし、わかりやすいように名前を credentials.json と変更します。これで準備完了です。

Googleスプレッドシートからシフト表を取得

ここからはGoogleスプレッドシートからシフト表を取得するコードを実装します。Node.jsアプリケーションに新しくjsファイルを追加します。index.js という名前で作成しました。

touch index.js

index.jsをエディタで開き、環境変数の読み込みや必要なパッケージをインポートします。

'use strict';
require('dotenv').config();
const { GoogleSpreadsheet } = require('google-spreadsheet');

次にGoogleスプレッドシートからシフトデータを読み取り、担当者の電話番号を返す非同期関数を実装します。

// Googleスプレッドシートからシフト情報をロードし、担当者の電話番号を取得
async function loadShiftPhoneNumbers() {
    // 処理を実装
}

この loadShiftPhoneNumbers 関数でGoogleスプレッドシートをロードします。ここでGCPへの接続に必要になるのが先ほどコピーし、名前を変更した credentials.json です。

// Googleスプレッドシートからシフト情報をロードし、担当者の電話番号を取得
async function loadShiftPhoneNumbers() {
    // スプレッドシートIDと資格情報を用いてGoogleスプレッドシートをロード
    const doc = new GoogleSpreadsheet(process.env.SPREADSHEET\_ID);
    const credentials = require('./credentials.json');
    await doc.useServiceAccountAuth(credentials);
    await doc.loadInfo();
}

ワークシートを取得する場合は、GoogleSpreadsheet.sheetsById、またはGoogleSpreadsheet.sheetsbyIndexを利用できます。さらに、GoogleSpreadsheetWorksheet.getRowsメソッドを使用し、ワークシートの行を取得できます。残念ながら特定の列の値をキーにフィルタリングはできないようなので全ての行を取得します。

// Googleスプレッドシートからシフト情報をロードし、担当者の電話番号を取得
async function loadShiftPhoneNumbers() {
    // スプレッドシートIDと資格情報を用いてGoogleスプレッドシートをロード
    const doc = new GoogleSpreadsheet(process.env.SPREADSHEET\_ID);
    const credentials = require('./credentials.json');
    await doc.useServiceAccountAuth(credentials);
    await doc.loadInfo();

    //シフト情報を取得
    const shiftSheet = await doc.sheetsById[process.env.SHIFT_WORKSHEET_ID];
    const shiftRows = await shiftSheet.getRows();
    // 従業員情報を取得
    const staffSheet = await doc.sheetsById[process.env.STAFF_WORKSHEET_ID];
    const staffRows = await staffSheet.getRows();
}

GoogleSpreadsheetWorksheet.getRowsメソッドはGoogleSpreadsheetRowの配列を返します。また、このGoogleSpreadsheetRowオブジェクトは最初の行をプロパティのキーとしてアクセスできるため、Array.prototype.find()メソッドを利用し、Date列をキーとして特定の日付のデータを抜き出すことができます。この記事では、2020年5月15日を例として取得します。実際のアプリケーションでは new Date() などを利用し、当日のデータを取得することになるでしょう。

// Googleスプレッドシートからシフト情報をロードし、担当者の電話番号を取得
async function loadShiftPhoneNumbers() {
    // スプレッドシートIDと資格情報を用いてGoogleスプレッドシートをロード
    const doc = new GoogleSpreadsheet(process.env.SPREADSHEET\_ID);
    const credentials = require('./credentials.json');
    await doc.useServiceAccountAuth(credentials);
    await doc.loadInfo();

    //シフト情報を取得
    const shiftSheet = await doc.sheetsById[process.env.SHIFT_WORKSHEET_ID];
    const shiftRows = await shiftSheet.getRows();
    // 従業員情報を取得
    const staffSheet = await doc.sheetsById[process.env.STAFF_WORKSHEET_ID];
    const staffRows = await staffSheet.getRows();

    // シフト情報からDate列の値と指定した日付をロケール情報に基づいて取得
    let shiftRow = shiftRows.find(row =>
        new Date(row.Date).toLocaleDateString() ===
        new Date('2020/5/15').toLocaleDateString());
}

あとは、取得した行から必要なデータを読み取り、アプリケーションで使用できます。

データの活用例として、このシフトデータから担当者の電話番号をカンマ区切りの文字列で取得する方法も実装します。

shiftRow.Employee1のように各列のキーを指定してデータを取得することもできますが、shiftRow._rawData shiftRow には、行のデータが配列として保持されています。2020年5月15日のデータは、['5/15/2020', 'Mitsuharu', 'Yoshihiro'] となります。この配列をArray.prototype.slice()メソッドで最初の日付データを除外した配列とし、さらに、Array.prototype.map()メソッドでシフト担当の従業員の電話番号の配列へと変換します。そして、最後に、Array.prototype.join()メソッドで文字列として返すという処理を実装しました。

// Googleスプレッドシートからシフト情報をロードし、担当者の電話番号を取得
async function loadShiftPhoneNumbers() {
    // スプレッドシートIDと資格情報を用いてGoogleスプレッドシートをロード
    const doc = new GoogleSpreadsheet(process.env.SPREADSHEET\_ID);
    const credentials = require('./credentials.json');
    await doc.useServiceAccountAuth(credentials);
    await doc.loadInfo();

    //シフト情報を取得
    const shiftSheet = await doc.sheetsById[process.env.SHIFT_WORKSHEET_ID];
    const shiftRows = await shiftSheet.getRows();
    // 従業員情報を取得
    const staffSheet = await doc.sheetsById[process.env.STAFF_WORKSHEET_ID];
    const staffRows = await staffSheet.getRows();

    // シフト情報からDate列の値と指定した日付をロケール情報に基づいて取得
    let shiftRow = shiftRows.find(row =>
        new Date(row.Date).toLocaleDateString() ===
        new Date('2020/5/15').toLocaleDateString());

        // 元データ['5/15/2020', 'Mitsuharu', 'Yoshihiro']
        // Date列(最初の列)を取り除き、シフト担当の従業員を含む配列を取得する
        let employeesOnDuty = shiftRow._rawData.slice(1); 
        // ['Mitsuharu', 'Yoshihiro']
        // 名前から電話番号の配列に置換
        employeesOnDuty = employeesOnDuty.map(m => 
            staffRows.find(row => row.Name === m).PhoneNumber); 
        // ['+815012341235', '+815012341237']

        return employeesOnDuty.join(',');}

ここまで実装を終えた段階で、きちんとデータを読み込めるかどうかを確認しましょう。
loadShiftNumbers関数のスコープ外に次のコードを追加します。

// 実装した関数が正しく動作するかテスト
loadShiftPhoneNumbers()
    .then (numbers => console.log(numbers))
    .catch(error => console.error(error));

index.jsを実行し、次のような結果がコンソールに出力されていれば成功です。

node index.js

実行結果

+815012341235,+815012341237

想定した結果が得られない場合は、出力されたエラーを参考にGCPの設定や、JSONファイルの読み込みなどを確認してください。

まとめ

ご覧いただいたように、Google Sheets APIを使うことでGoogleスプレッドシートをデータソースとしたアプリケーションを構築することができます。ぜひご活用ください。

このエントリについての問い合わせ

不明点があればぜひ、お問い合わせください。オンライン登壇のご依頼等もこちらまで！

Nuxtアプリを無料で公開するときに試した5つの環境まとめ(Firebase/GAE/Netlify/Heroku)

2020-03-20T13:51:56+09:00

最近Nuxtでいろいろ作っているけど、無料で使える環境をいろいろ試してる。
いろいろメリデメあるけど、SPAならNetlify/SSRならHerokuがよさそう。
いままで試したものをまとめてみた。

ほしかったもの

主に開発してるのがCGM系のWebサービスなので、

動的なOGP画像などが設定できる(OGP芸)
カスタムドメインが使える
日次のランキング集計などの定期実行ができる

が、無料でできて、なるべく実装が楽で、そこまで遅くないのがうれしい。

試した5つのパターン

試したのは以下の5パターン。試してみた順で記載。

Nuxt(SSR) + Cloud Function
起動がかなり遅かった。。実装も大変なのでNG
Nuxt(SPA) + Firebase Hosting
構築はかなり楽。ただ、OGP芸が大変でFunctionsが必要
Nuxt(SPA) + Netlify
プレレンダリングでOGP芸が楽。定期実行はFunctionsでできる
Nuxt(SSR) + GAE(f1:256M)
メモリの制限きつく、たまに落ちる。。定期実行はcron.yamlでできる
Nuxt(SSR) + Heroku(free:512M) + Cloudflare
メモリ多くてよい。SSLはないのでCloudflareを併用。定期実行はHeroku Scheduler

SPAで十分であれば、「3.Nuxt(SPA) + Netlify」が構築も簡単で良かった。
積読ハウマッチは、現在この構成。

SSRの場合、「5. Nuxt(SSR) + Heroku(free:512M) + CloudFlare」が良い感じ。
へんあいマップがこの構成。

各パターンについて

1. Nuxt(SSR) + Cloud Function

一番はじめに積読ハウマッチでやろうとした構成。

細かいやり方は、以下の記事の「Firebase Cloud Functionsの設定してSSRできるようにする」あたりに。
・Nuxt.jsではじめるときのやることリスト(SSRも国際化も自動デプロイも) - くらげになりたい。

当時は動的ページのSEO対応するには、この方法が多く検索に出ていたので試したけど、
Cloud Functionのコールドスタートがつらすぎてお蔵入り。。SPAでいくことに。。

2. Nuxt(SPA) + Firebase Hosting

積読ハウマッチをリリースしたときの構成。

課題だった動的ページのSEOは、Cloud Functionsを経由して返す方法で対応。
こちらも当時よく検索に出てたけど、実装が大変そうだったので2番手に。

細かいやり方は、以下の記事に。（2020/03/22追記: OGP画像生成系の記事を追加）
・Nuxt(SPA)+FirebaseでSEO！OGP！: 特定のパスだけheadだけ返すやつ - くらげになりたい。
・Nuxt.js(SPA)+Firebaseで積読用の読書管理サービスを作ってみたときにハマったこと - Qiita
・Cloud Functions + ImageMagickでOPG画像の動的生成してCloud Storageにアップロードする - くらげになりたい。
・Cloud FunctionとSVGでOGP画像生成を試行錯誤したまとめ - くらげになりたい。

カスタムドメインについては、Firebase HostingでSSLと合わせて無料で設定可能。

定期実行は、Cloud Functionsでできるのでそれを利用した。
・関数のスケジュール設定 | Firebase
・Cloud Functions for Firebaseのcronみたいな定期実行を試したら簡単だった - Qiita

ただ、Cloud Functionsの定期実行は、
「Googleアカウントごとに3つのジョブを無料で使用できる」
なので、注意が必要。プロジェクトごとじゃない。。

3. Nuxt(SPA) + Netlify

積読ハウマッチの現在の構成。

NetlifyのPrerenderingが無料化されて使えるようになり、よいという話を聞くように。。

実装が複雑で、変更もしにくかったので、この方法に。
Netlify自体がCDNも提供していているので、すこしはやくなった(気がする)

カスタムドメインも、NetlifyのDNSを設定して無料で対応できる。

定期実行は、2.と同じ感じで、Cloud Functionsのまま。

コード量も減って変更もしやすくなったので、OGP画像の改善とかが楽にできるように。。(´ω｀)

4. Nuxt(SSR) + GAE(f1:256M)

SPAの課題として、初期表示が遅いのでなんとかしたいなと、SSRの環境を模索しはじめ。。
公開していないけど、1つ作ってみた。

試してみたところ、起動するだけでメモリ上限すれすれで、複数アクセスがあったりすると、落ちる場合も。。
(ts-nodeで動かしているのも悪い気がしている。。)

ただ、定期実行はcron.yamlを用意すればURLに送信でき、無料範囲も広い。
料金も「その他のリソース」をみるとcronは無料のよう。
・cron.yaml を使用したジョブのスケジューリング

カスタムドメインやSSLも無料で利用できる感じ。(試してないので未確認)

5. Nuxt(SSR) + Heroku(free:512M) + Cloudflare

GAEでうまくいかなかったので、無料でメモリも多いHerokuを利用。
へんあいマップがこの構成で稼働中。

定期実行は無料のアドオン(Heroku Scheduler)が利用できる。
Nuxt側でserverMiddlewareを用意すればOK。

ただ、メモリは多く定期実行もが、Herokuの無料枠だと制限も多い。

SSLは非対応
30分アクセスがないとスリープする
クレジットカードの登録で1000時間/月xアカウント
(未認証だと550時間/月xアカウント)

1. SSLは非対応

単体だけだとSSLに対応していないので、Cloudflareを併用。
CloudflareがCDNも提供してくれるので良い感じに。

2. 30分アクセスがないとスリープする

これは、Heroku Schedulerを使えばOK。
任意のURLを叩けるため、15分毎などスリープしないようにしておく。

3. 無料枠は1000時間/月xアカウント

1000時間あれば、24時間x31日でも744時間なので、大丈夫な感じ。
ただ、アカウント単位での無料枠なので、複数アプリを無料で稼働はできない。。

実際のやりかたとかは、

以下の記事に。
・Heroku+CloudflareなNuxtでSSRしてみる - くらげになりたい。

まとめ

いろいろ試してみたけど、Nuxt.jsを無料で公開するときは、

SPAならNetlify
- prerenderingで動的ページのSEOも対応
- カスタムドメインやSSLもNetlifyでOK
- 定期実行はCloud Functionsで。
- ただし、定期実行は1アカウントにつき、3ジョブまで
SSRならHeroku
- SSRで動的ページのSEOも対応
- 定期実行はHeroku Schedulerで
- Cloudflareを併用し、SSL対応
- 無料枠は1アカウントにつき、1アプリが限界かも

SSRの方は他にCloud RunやZEIT nowがある。
Cloud Runは立ち上げがGAEより遅いときので後手だけど、
ZEIT nowは気になってるので試してみたい(´ω｀)

以上!!

こんなのつくってます!!

積読用の読書管理アプリ『積読ハウマッチ』をリリースしました！
積読ハウマッチは、Nuxt.js+Firebaseで開発してます!

もしよかったら、遊んでみてくださいヽ(=´▽`=)ﾉ

要望・感想・アドバイスなどあれば、
公式アカウント(@MemoryLoverz)や開発者(@kira_puka)まで！

へんあいマップもリリースしました！

「偏愛マップ」を簡単に作れるWebアプリです!
へんあいマップも、Nuxt.js+Firebaseで開発してます!

偏愛マップは人見知りや口下手な人にも優しいコミュニケーションツールで、
勉強会、懇親会、オフ会などの余興・アイスブレイクや自分のプロフィールにも！

よかったら遊んでみてください(´ω｀)

GCEのMicro Instance with burstable CPU runningに注意

2020-03-08T22:46:20+09:00

GCPのGoogle Compute EngineにはAlways Freeによる無料枠があるため、f1-microというインスタンスタイプであればサーバー自体は無料で運用することができる。

ただし、あくまでもCloud Platformなので、実際にはサーバーを動作させるためのあれこれで費用がかかったりする。例えばネットワーク料金や、IPの料金など。もちろんこのあたりも無料枠があるので基本的にはだいたい無料で運用できる。かかるとしても数円程度。

料金が発生するパターン

しかし、色々試しているうちに費用が発生してしまうパターンが見つかった。料金表を見ていると「Micro Instance with burstable CPU running in Americas」ということで1,730円分も料金が発生していることに気づいた（無料クレジット期間のためまだ無料だが）。

これは何かというと、公式のマニュアルにも書かれているCPUバーストという機能。

CPU バースト

CPUが足りなくなった時に、自動的にCPUを一時的に追加してくれるというもの。追加料金は通常は無いのだが、f1-microのようなマシンタイプの場合はこのように追加料金になるらしい。

僕が前々から使っているこのCrieitなどで使っているf1-microサーバーではこの料金がかかったことはない。ただ、どうも使い方によってはこれが激しく使われる事があり、このように追加料金が発生してしまうっぽい。

具体的にはこの記事のパターンで発生した。

GCEをDBサーバーにしてGAEでサービスを無料運用する

単にDBサーバーとして利用していた、というだけなので、通常であればさほど料金が発生することはない。ただ、もしかしたら上記の構成だとちょこちょこ何かしらのアクセスや接続が発生してしまい、負荷につながってしまうのかもしれない。詳しいことは全くわからない。何にしろ、f1-microの無料枠は時間で決まっているので、このバーストにより時間が無料枠分を超えてしまう。

対処方法

GCPを利用し始めて1年間は無料クレジットが付いているため、基本的に問題になることは無いだろう。ちょこちょこ料金明細を見ておいて、おかしかったらその利用方法では費用が発生してしまう可能性があるため、構成を見直せばいい。それでどうしても費用とパフォーマンスがあわないようであればその間に他のサーバーを検討すればいい。

すでに無料クレジットの期間が終わってしまっている場合は注意が必要。無料だと思っていてこの料金がかかってしまうとちょっとびっくりする。

GCEをDBサーバーにしてGAEでサービスを無料運用する（を構築したけど費用がかかった）

2020-01-07T23:15:57+09:00

GCPでリリースしたサービスが1年経ち無料クレジットの期限をむかえそうになりました。Cloud SQLを使ってデプロイしたためその後は有料になってしまうのですが、誰も使っていないサービスのためなんとか無料で運用できる方法は無いかと考えました。ちなみに下記のような構成です。

Node.js
MySQL5.7

しかしサービスの性質上ちょっとデータベースのデータも多めで、HerokuのMySQLだと無料プランでは無理なのかな…という気がしました。そうするとMySQLを使えて無料で運用できるサービスが他にはありません。

そこでふと、アプリケーション・サーバーはGoogle App Engine、データベースサーバーをGoogle Compute Engineで運用してみたらどうだろう、と思い立ちやってみました。

後日談の追記

こういうのが出るみたいなので無料は無理なのかもしれません。Micro instance with burstable CPU running。

普通にサーバーとして使ってる時は出ないのでGAEかネットワークから必要以上に接続が来てしまうのかもしれませんね…。（もしくは最近新しく作ったGCEだと出るようになったとかだったり？）

追記）
GCEにWeb+DB全部入れにしたら費用がかからなくなったのでやはりこの構成だと費用がかかるみたいです。

GAEからGCEにローカル接続する

結局のところ、今回の話ではこれが一番重要です。そもそもApp EngineからCompute Engineにローカル接続できるのか、と。

これは実はこの記事を書いている2020/1時点では日本語マニュアルではまだβ版という表記が残っている、リリースされたばかりの「サーバーレスVPCアクセス」という機能を使うことによって可能です。

Connecting to a VPC network | App Engine standard environment for Node.js docs | Google Cloud

Compute EngineはVPCネットワーク内に位置しているのですが、App Engineはこれとは別のネットワークに存在しています。そのため、このサーバーレスVPCアクセスという機能を使うことで、下記にも書かれていますがApp Engineのスタンダード環境やCloud FunctionsからCompute EngineやCloud SQLに内部IPでアクセスできるようになります。

Serverless VPC Access の構成 | VPC | Google Cloud

日本語だとデプロイ時にbetaをつけろと書かれていますが恐らく今は不要だと思います。

サーバーレスVPCアクセスの設定

サーバーレスVPCアクセスのページを開くとコネクタを作成というリンクがあるのでクリックします。

作成画面に必要な項目を入力して作成します。

注意が必要な点としてまだリリースされたばかりのためリージョンが少ないです。最初にApp Engineを登録してしまうと、同じリージョンがない…！　みたいなことになるので気をつけましょう。us-central1であればGAEのus-centralと合います。

IP範囲は補足に書かれている感じで大丈夫です。要するに、既存のVPCネットワークのIPとかぶっていないIP範囲であれば大丈夫です。

App Engineの設定

App Engineのリージョンは先程作成したコネクタのリージョンに合わせて作成しましょう。多分作ってしまった後は変更できないのではないかと思います……。ただ、ちょっとApp Engineを作り直せない関係で色々試すことができたわけではないので、リージョンが違ったらダメかどうかは詳しく検証できていません。

あとはapp.yamlに、このコネクタに接続するための設定を追記します。

vpc_access_connector:
  name: "projects/PROJECT_ID/locations/REGION/connectors/CONNECTOR_NAME"

REGIONとCONNECTOR_NAMEはコネクタのものです。これでデプロイすれば接続され、Compute Engineの内部IPと接続することができるようになります。

Compute Engineの設定

デフォルトだとCompute Engineの内部IPはエフェメラルになっているため、時々勝手に変わってしまいます。

静的内部IPアドレスを予約して固定にしておきましょう。外部IPは不要です。固定外部IPを使っていた場合は、ただそれを外すだけだと使われない外部IPになってしまい、費用が発生してしまいますのでIPを解放しておきましょう。

あとはMySQLをインストールして設定しましょう。どこからもアクセスできないのでMySQLユーザーは ユーザー名@'%' とかでいいのではないかと思います（違ったら教えていただけると助かります）。

問題なければこれで接続できます（のはず……）

諸々設定

とはいえGAEは無料枠があるというだけでそれ以降は有料となってしまいます。こにさんのブログを参考にしてなるべくオーバーしないようにすると良いでしょう。

Google App Engineを無料で運用する方法（2018年版） - koni blog

スタンダード環境にてAutoScalingのF1というプランです。スケールしないプランもありますがそちらは無料枠が少なく毎月有料になってしまいます。

どちらにしろすごくアクセスのあるサイトだと有料になってしまうと思いますので今回のようにもう誰も使っていないサービスを残しておくとか、作ったばかりのサービスで試す場合とかにこの構成だと良いのではないかと思います。

あとCloud SQLのように便利な機能はないので適宜バックアップを取っておきましょう。

Google Cloud Storage無料DBバックアップ

また、DBサーバーはメモリが不足してしょっちゅう止まる可能性もありますので、swapの設定もしておいた方が良いでしょう。

2020年からはGCEの外部IPが有料となりますが無料枠もあります

2020-01-03T22:24:35+09:00

GCPのクラウドサーバーであるGoogle Compute EngineはAlways Freeという無料枠によりf1-microは無料で利用ができます（細かい条件はあります）。しかし2019年から囁かれはじめたとおり、2020年からは外部IPが有料となりました。

新年あけましておめでとうございますしてから、僕にも請求アラートが飛んでくるようになりました。見てみるとたしかに外部IPの費用分が追加されていました。（External IPの箇所）

ただし無料枠の割引もあるようです。

詳しくは下記に書かれていました。

Google Cloud の無料枠 | Google Cloud Platform の無料枠 | Google Cloud

注: Google Cloud では、2020 年 1 月 1 日から VM インスタンスの外部 IP アドレスの使用に料金がかかります。ただし、Google Cloud の無料枠では当月内の合計時間数と同等の時間数を使い切るまで、使用中の外部 IP アドレスを無料でご利用いただけます。使用中の外部 IP アドレスの Google Cloud 無料枠は、f1-micro インスタンスだけでなく、すべてのインスタンスタイプに適用されます。

無料枠はf1-microだけだと思うのでちょっとよく意味はわからないのですが、とりあえずf1-microであればずっと無料で行けるのではないかと思います。（実際に１ヶ月丸々試せてはいないので今後も引き続き見ていきますが）

とはいえ課金＋割引という方式のようですので、無料枠無視の請求アラートにしていた場合は、設定によってはアラートが飛んでくるようになっています。煩わしいようであれば請求アラートの設定を調整しておいた方が良さそうです。

GCEでインスタンスを作るときにやることリスト

2019-11-17T14:30:30+09:00

今更ながらGoogle Compute Engine(GCE)を使ってみたいなと思い、
インスタンス作るときにやった手順をまとめてみた。

ほぼ、以下の2つの記事を見てやった手順をまとめただけの備忘録。
・ GCE の無料枠のサーバを立るときに、初見でハマりそうなところ - Qiita
・ GCPで永久無料枠を利用してサービスを立ち上げたときにしたことの備忘録 - Qiita

1. インスタンス作成

imageはUbuntu 18.04(Minimal)を選択

f1-microにする
80, 433ポートを開放する
- 「HTTPトラフィックを許可する」にチェック
- 「HTTPSトラフィックを許可する」にチェック
IPを固定にする
- 「ネットワーキング」>「ネットワークインターフェース」>「外部IP」
- 「プライマリ内部IP」とは違うので注意

2. SSHの設定

2-1. ポート変更

メニューの「VPCネットワーク」>「ファイアウォールルール」から
「ファイアウォールルールの作成」を押して作成
- ターゲットタグ: original-allow-ssh
- ソースIPの範囲: 0.0.0.0/0
- プロトコルとポート: tcp 40022
VMの「ネットワークタグ」に「ターゲットタグ」をつける
「VMインスタンス」にある該当のVMの「接続」＞「SSH」を押してブラウザでログイン

# apt updateしないとvimをインストールできない
$ sudo apt update
$ sudo apt install -y vim

$ sudo vim /etc/ssh/sshd_config
$ sudo systemctl restart sshd

  #Port 22
+ Port XXXX （XXXX は さっき開けたポート番号）
  #AddressFamily any
  #ListenAddress 0.0.0.0
  #ListenAddress ::

sshdを再起動したら、編集したブラウザは閉じずに、
「接続」>「ブラウザからカスタムポートで SSH を開く」から
変更したポートで接続してみて、つながるかどうかを確認

うまくできたらポートを閉じる

「ファイアウォールルール」に移動
「ファイアウォールルールの作成」を押して作成
- ターゲットタグ: disallow-ssh22
- 一致したときのアクション: 拒否
- ソースIPの範囲: 0.0.0.0/0
- プロトコルとポート: tcp 22
VMの「ネットワークタグ」に「ターゲットタグ」をつける

2-2. 公開鍵の認証

# 鍵を生成。アカウント名はmemorylovers
$ ssh-keygen -t rsa -f ~/.ssh/gcp_key -C memorylovers

$ chmod 400 ~/.ssh/gcp_key 

# 公開鍵をコピー
$ cat ~/.ssh/gcp_key.pub | pbcopy

メニューの「VMインスタンス」から該当のVMを選択し、編集画面へ
SSHキーに貼り付けて、保存

接続確認をしてみる

$ ssh memorylovers@ -p <指定したポート> -i ~/.ssh/gcp_key

2-3. SSHの設定を変更

ポート番号以外について、確認・設定していく

  # プロトコルを2にする
+ Protocol 2

  # rootログインを無効にする
  #PermitRootLogin prohibit-password
+ PermitRootLogin no

  # パスワード認証を無効にする
  PasswordAuthentication no
  ChallengeResponseAuthentication no

  # 認証の試行回数を制限する
  #MaxAuthTries 6
+ MaxAuthTries 5

設定が終わったらsshdを再起動して設定を反映

$ sudo systemctl restart sshd

以上!! これでインスタンスが作成できた！

こんなのつくってます!!

積読用の読書管理アプリ『積読ハウマッチ』をリリースしました！
積読ハウマッチは、Nuxt.js+Firebaseで開発してます!

もしよかったら、遊んでみてくださいヽ(=´▽`=)ﾉ

要望・感想・アドバイスなどあれば、
公式アカウント(@MemoryLoverz)や開発者(@kira_puka)まで♪

参考にしたサイト

Google Compute Engine利用時に使うgcloudコマンド備忘録

2019-11-14T08:49:36+09:00

Google Compute Engineを使っているとサーバーと接続するために色々なgcloudコマンドを利用する必要がある。普段はシェルの実行履歴から呼び出して使っているけど、何かのひょうしにPCが壊れて履歴がなくなってしまったら困るし、結構一から使い方を探すと見つからなかったりするのでとりあえずまとめておく。

SSH接続

gcloud compute --project "my-project-id" ssh --zone "us-east1-b" "instance-1"

ポートフォワーディング

ローカルPCでサーバーのデータベースと接続するときとか

gcloud compute --project "my-project-id" ssh --zone "us-east1-b" "instance-1" -- -L 13306:localhost:3306

SCPで送信

SCPでファイルを送ったり受信したりする時。ファイルとフォルダによってちょっと違う。

ファイルを送信

gcloud compute scp --project "my-project-id" --zone "us-central1-f" instance-1:/home/dala00/profile.sql.gz .

フォルダを送信

gcloud compute scp --project "my-project-id" --zone "us-west1-b" --recurse instance-1:/home/dala00/questions localdir

コマンドを実行する

gcloud compute --project "my-project-id" ssh --zone "us-west1-b" dala00@"instance-1" --command 'touch bbb.txt;rm aaa.txt'

React PWA + Rails GraphQLで作ったポモドーロRPGに使った技術やその選定理由を書いてみた

2019-09-26T22:08:54+09:00

先日、『g4』というポモドーロ+RPGなサービスをリリースしました。

そのサービスで使った技術について聞かれることがあったので残しておきます。

どんなサービス?

ポモドーロ・タイマーを使い25分間集中すると経験値をもらえ、その経験値でレベルが上がる。
って言う感じのやつです。

https://www.g-g-g-g.games

こんな特徴があります。

ポモドーロ・タイマーやRPG的なUIはリッチで動きがある
現在のステータスをOGP画像にしてシェアできる
上昇する能力値や覚えるスキルは登録した文章を解析して決まる

構成はこんな感じ

フロントエンドの選定理由

フロントエンドはSSRしたReactアプリをfly.ioにおいています

[React]

自分は過去に仕事でNuxt.jsや生Vue.jsを使ったことがあり、個人ではExpoやNext.jsでReactにも触っていました。

今回Reactを選択した理由は以下です。

型が欲しかった。Typescriptを使いたかった
Reactのほうが書いていて楽しい（個人の感想です）
- React Hooksめっちゃいい
Apolloを使うならVueよりReactのほうが色々揃っている

[fly.io]

SSRするためにNode.jsをホスティングするやつが欲しかったので選定。
mizchiさんのブログで知り、面白そうだなと思ったのがきっかけ。
べつにfirebase hostingでもよかったですが、以下が決め手

firebase hosting同様初期導入費用がほぼ0
CDN
キャッシュコントロール
svgを使ったOGP画像の生成ができる

特に、

svgを使ったOGP画像の生成ができる

に有用性を感じて選定したんですが、現時点ではカスタムフォントと日本語への対応が十分でなく、別途Cloud Runを使うことになってしまっています（後述）
（サポートに聞いたらリポジトリ教えてもらったので（OSS）対応できるようなら自分で対応してなげたいなぁ）

キャッシュコントロールもよい

キャッシュの操作も面白くて、
g4の公開用ページではAPIからもらった結果をキャッシュして、キャッシュがあればそれをそのまま返すということをしています。

これによってAPIサーバーへの負荷はかなり低くなってると思います。
APIサーバー側からは、データ更新時にfly.ioのキャッシュを削除する操作をしていて、データが更新されるまではfly.ioはキャッシュを使い続けてます。

この辺のAPIが普通に使いやすくて簡単にかけるのでめっちゃ良きです。

fly.io良いよ

fly.io自体ははデプロイも早いし、導入コストも安いのでnowとかと並べて、手軽にNode.jsをホスティングするための選択肢にしてもいいんじゃないかなって思います。

Next.jsを選ばなかった理由

SSRする予定ではありましたが、OGPだけ生成できればいいなというレベルだったので、通常のReactアプリで作りました。
なるべく継続開発するため、アップデートの手間と依存を減らしたかったのも少しある

[PWA]を選定した理由

最初は、Expoで作ろうかと思っていました。

もともとSPAでアプリっぽいUIを作る仕事を受けたときに、Nuxt.js + Firebaseで作り、マルチブラウザ対応が辛いと思った経験がありました。

RNならその辺いい感じに作れるかもと思ってみんなの成長というアプリでExpoを試しみて、使い勝手が良い事までは確認してました。

ただ今回はモバイルより、デスクトップアプリのほうが欲しいということに気づき、
Electronで作りやすかったり、PWAならそのままインストールもできちゃうのでWebでいいかなって思いPWAにしました。

なのでマルチブラウザ辛いは解決してないです。
ここは個人開発なので修行と割り切って本業に生かしていきます。
Safari対応が結構めんどいけど、ユーザー多くて無視できない...

マルチブラウザと言っても、現状Chrome、Safari以外はほぼ無視してまっす。

[Apollo Client (react-apollo)]

これもSPAでアプリっぽいUIを作る仕事で、Nuxt.js + Firebaseで作ったときに、Firebaseのデータベース（このときはrealtime database使ってた)をフロントに反映するのが辛くて、同じようにREST APIも辛いだろうなと思って、GraphQLに手をだしたのがきっかけでした。

GraphQLだけでもすごく良いのですが、Apollo Clientがいいのはキャッシュコントールで、
クエリ毎にキャッシュを優先するかサーバーを優先するかを選択できます。

また、キャッシュがあれば再取得しないなどを簡単に書けたり、とにかくこれはSPAのベストプラクティスだなって感じの実装をシンプルに書けます。

Mutationするとキャッシュが書き換わったりするのもめっちゃ良き

正直この辺のこと考えながらSPA実装するのってかなり大変じゃない?ってか大変だった
アプリライクなUIのSPAならApollo Client使おうぜ！

こいつのおかげでこれまたAPIサーバーの負荷はまあまあ抑えられてそうです。

[Firebase Auth, Storage]について

バックエンドはRailsですが、APIサーバー作るのに正直Deviseとか使いたくないです（完）

Twitter連携やら諸々簡単なので選ばない理由がない。
Auth0は選択肢に入るけど今回GCPなのでGoogleでまとめられるし、そこまで込み入った認証必要ないしでこれにしました。

Storageは別に何でもよかったですが、Firebase Authの認証ユーザー単位での権限指定が楽なので使い勝手は良いです。

デザインについて

g4のデザインはレスポンシブのヘルパーとしてbootstrap-gridだけ使わせてもらってます。
めっちゃ便利なのでおすすめ。

それ以外はcss全部自分で書いてます。

コンポーネントファーストで作成しており、Atomic Designの粒度で、Storybook作ってコンポーネントを作ってる感じです。
Storybookは割とぶっ壊れやすかったり、他のビルド設定と競合とか重複したり、辛みもありますが、storyshotsによるスナップショットの差分確認ができるのと、テストの安心感があるので、無いと無いで不安ではあります。

バックエンドの選定理由

[graphql-ruby & Ruby on Rails]

Apollo Clientの項で書きましたが、GraphQLを使うことは決まっていました。
GraphQLをマネージドでホスティングしてくれるやつを探したりしたんですが、普段Railsエンジニアなので慣れてるからテストとかも書きやすいしRailsでいっかで、graphql-rubyにしました。

Railsにするとランニングコストは割とかかるんですが、今回は個人開発のメインに据えて長く継続開発したいを目的にしてたので、
稼働してないものにお金払うみたいなことにならない想定（自分が使い続ける）で、コストかける覚悟はしました。

graphql-rubyは仕事でも使ってるので、今後も押していきたい存在。

[GCP/App Engine]

App Engineについてはこちらの記事で書きました。

要約するとHerokuでも良かったけど、使ってみたかったのでGCPにした。です。

[GCP/Natural Language API]

便利。Azureとかにもありますが、今回はGoogle統一で行きました。くらいの選定理由

[GCP/Cloud Run]について

Cloud Runは今回使う予定は全くありませんでした。

今利用している理由としては、

fly.ioでOGPを生成できるとふんでいたができなかった。
とりあえず手っ取り早くカスタムしたDockerimageでfry.ioをあまりお金をかけずに使えるとこはないか。

からの、Cloud Run。

中身は日本語とフォントをインストールした普通のNodeイメージに
fly.ioのサーバーを単純に乗っけて起動しているだけです。（プレビルドして実行したいがやり方が分からずdevサーバー起動しているのでなんとかしたい。誰かやり方知りませんか。）

なので、いずれはfly.ioだけでできるようして、Cloud Runをやめたいです。

Cloud Run超便利

そんな理由で使い始めましたが、驚くくらい簡単かつ手軽にカスタムDockerイメージが使えるので、Cloud Runめっちゃ便利です。
今後活用していきたい。

おわりに

割と構成的にはガチよりになりました。
自分の技術力総動員してる感じなのでテンション上がってめっちゃ楽しい！

g4の運用を支える技術についても今後書いていきたいです。

みんなでレベル上げしましょう！

https://www.g-g-g-g.games

Firestoreのデータをgcloudを使ってバックアップ＆別のプロジェクトへインポートしてみる

2019-09-24T19:17:59+09:00

Firestoreのデータをガリガリ見ていきたいなと思っていたら、
別のプロジェクトに移行できそうだったので、いろいろ調べたときの備忘録。

分析目的だけど、BigQueryは1000カラム制約で使えなかったので代替案...
別プロジェクトなら無料枠でいろいろできそう。

注意

Firestoreのエクスポート/インポートについて、いくつか注意。

Firestoreのエクスポート/インポートはBlazeプランが必要(無料枠では不可)
ドキュメントの読み取りと書き込み時にCloud Firestoreの料金が課金される

さらに、

エクスポート / インポートオペレーションのコストは、費用制限の対象にはなりません。
オペレーションが完了するまで、エクスポート/インポートでGCPの予算アラートはトリガーされません。

とのことなので、ご利用は計画的に..

1. gcloudのインストール

インストール

$ brew cask install google-cloud-sdk

.bashrcなどに以下を追記

source '/usr/local/Caskroom/google-cloud-sdk/latest/google-cloud-sdk/path.bash.inc'
source '/usr/local/Caskroom/google-cloud-sdk/latest/google-cloud-sdk/completion.bash.inc'

gcloudの初期化

# 初期設定の実行
$ gcloud init
# このあと、ログイン画面が出てきて認証する

# コンポーネントのアップデート
$ gcloud components update

# 現在のプロジェクトの確認
$ gcloud info | grep project

2. FirestoreのデータをExportする

firestore exportを使うと、データのバックアップが作成できるらしい。
バックアップデータはGCPのStorage上に作成されるので、
あらかじめ、Storageを作成しておく必要がある。

# 現在のプロジェクトの確認
$ gcloud info | grep project

# 全体のエクスポート
$ gcloud beta firestore export gs://[BUCKET_NAME]

# コレクションを指定して、一部だけをエクスポート
$ gcloud beta firestore export gs://[BUCKET_NAME] --collection-ids=[COLLECTION_ID_1],[COLLECTION_ID_2]

# 実行状況の確認
$ gcloud beta firestore operations list

データ量が多いと、コマンドが途中で終了するので、
完了したかどうかはoperations listを実行して確認する必要がある。

参考: データのエクスポートとインポート | Firebase

3. プロジェクトを変更する

# プロジェクトの設定
$ gcloud config set project [PROJECT]

# 現在の設定情報の確認
$ gcloud info

参考: SDK 構成の管理 | Cloud SDK のドキュメント | Google Cloud

4. アカウントを変更する

# アカウントの設定
$ gcloud config set account [ACCOUNT]

# 設定したアカウントの認証
$ gcloud auth login

# 登録しているアカウントの一覧を確認
$ gcloud auth list

# プロジェクトの設定
$ gcloud config set project [PROJECT]

# 現在の設定情報の確認
$ gcloud info

参考: Cloud SDK ツールの承認 | Cloud SDK のドキュメント | Google Cloud

5. バックアップを別のプロジェクトにインポートする

全体の流れはこんな感じ。

# バックアップしたいプロジェクトに設定
$ gcloud config set project [PROJECT]

# 全体のエクスポート
$ gcloud beta firestore export gs://[BUCKET_NAME]


# 別のプロジェクトにプロジェクトに変更
$ gcloud config set project [PROJECT]

# バックアップファイルのインポート
$ gcloud beta firestore import gs://[BUCKET_NAME]/[EXPORT_PREFIX]/

注意点

インポートしたいプロジェクトのFirestoreは初期設定までする必要がある
実行はプロジェクトのサービスアカウントで実行されるので、
バックアップファイルのバケットに権限を付与する必要がある

参考: データのエクスポートとインポート | Firebase

おわりに

有料のみではあるけど、

本番データの分析したり
本番データを開発用に利用したり
プロジェクトの移行

なんかにも使えそう。
分析はBigQueryを使えるならそのほうがいいかも？

こんなのつくってます!!

積読用の読書管理アプリ『積読ハウマッチ』をリリースしました！
積読ハウマッチは、Nuxt.js+Firebaseで開発してます!

もしよかったら、遊んでみてくださいヽ(=´▽`=)ﾉ

要望・感想・アドバイスなどあれば、
公式アカウント(@MemoryLoverz)や開発者(@kira_puka)まで

参考にしたサイト

GoogleのOAuth認証で追加できないスコープがある時

2019-09-04T22:16:22+09:00

Google Cloud PlatformにはOAuth認証を用いたGoogleログイン機能がある。普段色々なところでよく見かけるとは思うが。このGCPのOAuth認証にはスコープというものがあり、デベロッパーがそれを指定することで認証だけでなく、合わせて様々なAPIの利用許可をログイン時に得て利用することができるようになっている。

具体的にはGCPコンソールのOAuth 同意画面というところでスコープの追加を行うことができる。（実際にはアプリケーション側でも指定が必要）

しかし、下記の画像のように鍵付きのスコープは条件によってチェックボックスが表示されず、追加できない場合がある。

プライベートデータにかかわるスコープのため、条件的に問題がある場合は選択できなくなっている。

原因

調査＆問い合わせをしてみたところ、どうも既にスコープを利用してしまっているアプリケーションの場合、コールバックURLにhttp始まりの非SSLのものが既に混じっていると追加できない、ということだった。そのため混じっている場合は削除が必要とのこと。しかし、この画面には大まかなURLを設定する箇所はあるが、具体的なURLを一覧できる場所が見つからない。これを放置していると「Action Required」メールが飛んできて、このままだと未承認でログイン時に警告が出るようになるぞ、と脅しが来る。

で、よくよく探してみると「OAuth 同意画面」の方ではなく、「認証情報」のページに「OAuth 2.0 クライアント ID」の一覧がある。APIを開発する時に作成したもの。

これの名前をクリックすると無事コールバックURLの一覧が見つかった。

ここでhttpではじまるものを全て削除する。すると、スコープが追加できるようになった。

Googleによる確認

鍵付きのスコープを追加したあとは、Googleに承認をしてもらう必要がある。保存ボタンの右側にある「確認のための送信」を実行しておこう。

Google Cloud Storage無料DBバックアップ

2018-06-18T08:33:07+09:00

サービスを運用していると、データベースのバックアップが必要になります。ただ、同じサーバー内にバックアップを保存すると、サーバーが壊れた際にまるごと紛失してしまいます。

そんな時、Google Cloud Storageだと無料でデータベースのバックアップを保存できるため非常に便利です。

無料枠の詳細

容量5GBまでは無料

Always Freeにより、下記はずっと無料になっています。

5 GB の Regional Storage（米国リージョンのみ）
5000 回のクラス A オペレーション（1 か月あたり）
50000 回のクラス B オペレーション（1 か月あたり）
1 GB の北米から全リージョン宛て下りネットワーク（1 か月あたり、中国およびオーストラリアを除く）

上記の通り、米国リージョンでGoogle Cloud Storageのバケットを作成しておくと、5GBまでは無料になります。DBのバックアップであれば速度は関係ないため、米国で良いと思います。

Google Cloud Storageにバックアップする総容量が5GBを超えると費用がかかってきてしまいます。

通信料も無料

上り（Google Cloud Storageへのアップロード）は基本的に無料です。バックアップする際は特に気にすることはありません。

下り（Google Cloud Storageからのダウンロード）は、前述の無料枠の通り、1GBまでは無料となっています。北米のリージョンにバケットを作って運用しましょう。

Google Compute Engineからだったら楽

Google Compute Engineからバックアップを行う場合、非常に楽です。

というのも、Google Compute Engineには最初からGoogle Cloud Storageへのアップロードに必要なgcloudやgsutilが元々入っており、しかも最初から認証済みになっています。そのため、ほとんど事前準備もなくコマンドを叩くだけでバックアップを行うことができます。

バケットなどは事前に作っておきましょう。（非公開にしましょう）

僕は下記のようなバックアップスクリプトを作成しました。
(gsutilのパスは適宜実際のものとあわせてください）

rm backup.sql.gz
mysqldump -u dbuser --password=hogehoge dbname > backup.sql
gzip backup.sql
/snap/bin/gsutil cp gs://backup-bucket/2.sql.gz gs://backup-bucket/3.sql.gz
/snap/bin/gsutil cp gs://backup-bucket/1.sql.gz gs://backup-bucket/2.sql.gz
/snap/bin/gsutil cp bakup.sql.gz gs://backup-bucket/1.sql.gz

3世代まで保存しています。容量に応じてこの辺は増やしたり減らしたりすれば良いと思います。

GCP以外からの場合はkey fileを使って認証が必要なようです。

まとめ

何にしろAmazon S3等と違い、Google Cloud Storageは年間クレジットだけでなく永久無料枠があるのが大きな魅力です。さらに、GCPとの連携であれば初期設定も省くことができるのですぐに使えて便利です。ぜひ一度Google Cloud Storageの利用を試してみてください。

※料金についてはその都度実際に確認を行ってください。