ここでは、クラウドサービスを使って、次の機能の実現を目指す。

「クラウドサービス上の Web インターフェースから、家にある raspberry pi を操作する」

言い換えれば、「家にある raspberry pi を外から操作する」ことを目標とする。

「ルータの DMZ やポートフォワードを利用すれば、クラウドサービスを使う必要がない」 という話もあるが、 その場合 raspberry pi のセキュリティが気になるし、 なによりクラウドサービスの勉強にならない。

そんな訳で、今回のシステムは次のような感じにする。

actor ユーザ
node スマホ
cloud クラウド{
database データベース
}
node raspberrypi

ユーザ -- スマホ
スマホ -- クラウド
クラウド -- raspberrypi

クラウドサービスと言えば、次の 3 つが代表に挙げられるだろう。

• AWS
• Azure
• GCP (and firebase)

お試しなので、無料で出来るものをピックアップした結果、 次の URL の内容を元に GCP を選択した。

• 【AWS, GCP, Azure, OracleCloud, Firebase】無料で使えるクラウドのサーバリソースまとめ【2020年1月版】

  • https://qiita.com/goyae/items/196221169391dd44125d

そんな訳で GCP を利用するために、まずは以下の URL からアカウントの登録を行なう。

<https://cloud.google.com/?hl=ja>

このアカウント登録には、個人情報やクレジット番号の入力が必要になる。 入力が必要な個人情報には、名前は当然として、住所も入力するのだが、 恐しいことに郵便番号の入力欄が自動的に入力された。

今回 GCP の登録に利用した gmail アカウントには、 個人情報を登録した覚えはない。 なのに、何故か Google にはこちらの郵便番号が分かるらしい。

ちなみに、2段階認証で Android スマホを利用しているが、 そのスマホの位置情報機能も原則 Off にしている。

それにもかかわらず、郵便番号が判ってしまうというのは、本当に恐しい限りだ。

ネットワークの通信遅延から大まかな場所を特定可能というが、 郵便番号レベルで判ってしまうというのは、 位置情報が半径数百メートル精度で把握されているということであり、 もはや恐怖でしかない。

まさに、Google にはプライバシーが筒抜けといっていいだろう。

そんな訳で、 Google の恐しさを感じてモチベーションが下りつつも、話を進める。

出来るだけ無駄なお金はかけくないので、無料枠をチェックする。 Google Cloud の無料枠の説明は以下にある。

<https://cloud.google.com/free/docs/gcp-free-tier?hl=ja >

ちなみに、ここはアカウント登録前にも確認できるので、 サービスをじっくり比較検討したいという人は参考に。

無料枠の終了条件は以下のいずれか早い方。

• 登録後 12 ヶ月が経過した場合。
• 登録時に支給される $300 相当のクレジットを使い切った場合。

自分の検討内容的に考えて、 $300 相当を使い切ることは無いだろう。 もちろん「意図せず何かを暴走させる」なんてことが無いことが前提だが。

自分のような Web 素人、かつ、お手軽にクラウドサービスを試したいという場合、 サーバレスの FaaS が一番良いだろう、ということで、 Google Cloud Functions から初める。

Google Cloud Functions の公式ドキュメントはこちら。

<https://cloud.google.com/functions/docs?hl=ja>

公式の入門日本語ドキュメントがあるというのは本当に素晴しい。

「いかかでしたか？」系の Web ドキュメントに頼ることなく、 安心して作業を進められる。 それだけ、誰でも使えるレベルの当たり前の技術になっている、ということなんだろう。 これは、周回遅れで勉強を初めることの数少ないメリットの一つと言って良い。

そんな訳で上記公式ドキュメントを、一からやってみる。

export GOPATH=/home/hoge/work/gcp

export GO111MODULE=auto

package main

import (
    "net/http"
    "Test/YYYYYYYY"
)

func main() {
    http.HandleFunc( "/XXXXXXXXX/", srrec.Access)
    http.Handle(
        "/content/",
        http.StripPrefix(
            "/content/", http.FileServer(http.Dir( "./content" ))))
    http.ListenAndServe(":28080", nil)
}

--- $GOPATH/src/Test
     +--- main.go
     +--- context   // テスト用コンテンツ置き場
           +--- index.html 
     +--- YYYYYYYY // (シンボリックリンク)
           +--- ZZZZZZZ.go   // XXXXXXXXX 関数を定義するソース

$ go run main.go

curl http://localhost:28080/XXXXXXXXX
curl http://localhost:28080/content/index.html

Cloud Functions は、入力を受けて出力を行なうフィルターのようなもので、 Cloud Functions 単体ではデータを保持できない。 データを保持する方法として、Firestore がサンプルとして挙げられている。

なお、Firestore には次の 2 つのモードがある。

• ネイティブモード
• Datastore モード

Cloud Functions からアクセスする場合、ネイティブモードを選択する。

REST API には必須の JSON。 今回は Go でコードを組むので、 Go で JSON を扱う必要がある。

JSON と静的型付け言語は、 JSON ⇔ データの変換が面倒なことが多い。 Go では JSON のデータの取扱がどうなっているか調べてみたが、 静的型付け言語としては、だいぶ簡単に扱えるようになっている。

{
  "Val1": 1,
  "Val2": "abc"
}

type Hoge struct {
  Val1 int
  Val2 string
}

package main
import "strings"
import "fmt"
import "encoding/json"

type Hoge struct {
    Val1 int
    Val2 string
}
func main() {
    reader := strings.NewReader( `{ "Val1": 1, "Val2": "abc" }` )
    var item Hoge
    if err := json.NewDecoder( reader ).Decode( &item ); err != nil {
        fmt.Printf( "error: %v\n", err ) // 失敗
    } else {
        fmt.Printf( "decode: %v\n", item ) // 成功
    }
}

{
  "val1": 1,
  "val2": "abc"
}

type Hoge struct {
    val1 int
    val2 string
}

type Hoge struct {
    Val1 int `json:"val1"`
    Val2 string `json:"val2"`
}

func struct2json( item *Hoge ) {
  jsonBytes, _ := json.Marshal( item )
  fmt.Printf( "items: %v", string(jsonBytes))
}

• スマホから Cloud Functions にアクセスし、 Raspberry pi への操作を要求する。

  • この時、Cloud Functions は操作要求情報を firestore に記録する

• Raspberry pi は、Cloud Functions にアクセスし、 操作要求情報を取得して処理する。

  • この時、Cloud Functions は操作要求情報を firestore から読み出す

• この構成の場合、Raspberry pi は、クラウド側に操作要求情報がないか 定期的にポーリングする必要がある。

• 一般的に、ポーリングはサーバ負荷がかかる。

  • とはいえ、1台の Raspberry pi からポーリングしたところで、 サーバ負荷を考えるレベルにはない。
  • また、常識レベルのポーリング間隔であれば、GCP の 1 ヶ月間の無料枠をオーバーすることもない。
  • よって、 ポーリングでも実質的な問題はない。
  • しかし、 ポーリングはかっこ悪い し、折角の勉強の機会なので、別の手段を考える。

PubSub は、一対多のメッセージングシステムを提供するサービスである。 これを利用することで、定期的な ポーリングが不要 になる。

ちなみに、 PubSub は Publisher と Subscriber を示しており、 Publisher 側でメッセージを通知し、 Subscriber 側でメッセージを受けとる形になる。

今回のシステムでは Cloud Functions 側が Publisher で、 Raspberry Pi 側が Subscriber になる。 Cloud Functions は、操作要求情報をデータベースに記録したタイミングで Publish し、 Raspberry Pi 側はメッセージを受信したタイミングで操作要求情報を取得し、 その要求を処理することで、定期的なポーリングが不要になる。 通知するメッセージに、操作要求情報を直接含めても良いが、今回は更新通知だけを送り、 操作要求情報は別途取得する構成にする。

import "cloud.google.com/go/pubsub"
func Publish( w http.ResponseWriter, r *http.Request ) {
    ctx := context.Background()
    var client *pubsub.Client
    var err error
    client, err = pubsub.NewClient( ctx, projID )
    if err != nil {
        fmt.Fprintf(w, "error NewClient: %v\n", err )
    }
    topic := client.Topic( "my-topic")
    if topic == nil {
        fmt.Fprintf( w, "error Publish -- not found topic\n" )
        return;
    }
    res := topic.Publish(ctx, &pubsub.Message{Data: []byte("payload")})

    if _, err := res.Get( ctx ); err != nil {
        fmt.Fprintf( w, "error Publish: %v\n", err )
    }
}

今回の GCP 構成をまとめた図を示す。

• HTML 等の静的コンテンツは github Pages でホスティングする
• javascript から GCP Cloud Functions にアクセスする
• GCP Cloud Functions から、 firestore, Pub/Sub にアクセスする
• raspberrypi から、 Pub/Sub に Subscriber としてアクセスする

actor ユーザ
node スマホ
node githubPages
cloud GCP{
database firestore
rectangle CloudFunctions
rectangle PubSub
}
rectangle 家 {
node raspberrypi
}

ユーザ -- スマホ
スマホ --> githubPages
githubPages --> CloudFunctions
CloudFunctions --> firestore
CloudFunctions --> PubSub
PubSub --> raspberrypi
CloudFunctions <-- raspberrypi

今回の構成は、無料期間が過ぎても無料で運用できる。

ポーリングではなく Pub/Sub を利用したことで、ほとんどサーバアクセスは不要になっている。 ただし、 Pub/Sub は publish しなくても Subscriber から pull していると、 pull の内部処理によってサーバにアクセスしている。

例えば、 subscriber の pull() 関数を実行して、メッセージ待ちしている時の subscriber の通信状況を図を示す。 これを見ると分かる通り、約 5 分間隔で通信のピークがある。 なお、この間、実際にはなんのメッセージも publish していない。

また、次の Pull リクエスト数を見ると 191 回となっている。

Pub/Sub ライブラリの Pull() を 1 度実行しているだけでも、 ライブラリの内部的には 191 回サーバにアクセスしていることになる。

Pub/Sub の料金が、この内部的なアクセスを含むのか含まないのかが不明だが、 もしも含んだとしても、月の通信量は (/ (* 191 24 31) 1000) 142MB 程度なので、 無料枠 10GB の 14% にしかならない。まず気にすることはないだろう。

Cloud Functions, firestore に関して言えば、 意図的にアクセスしない限りは定期的にアクセスすることはないため、 無料枠を越えることはありえない。

GCP -> 支払い -> 予算とアラート