server (for dev) design

[mizosukedev]

• 動作確認するのに結構金がかかる。1回のトンネル作成で$5～$6。
• 基本動作は自前サーバーで実施して、最後に1回だけAWSのサービスを使って動作確認するのが良さそうという理由で検討中。
• 思い浮かんだイメージでは認証、DB保存先、デバイスへの通知などを自由に交換出来るように作った方が良さそうなので、golangじゃなくてC#で実装するかもしれない。
• スケールアウトできるような構成が厳しそうなので本番使用には耐えられなさそう。

[mizosukedev]

goでもdynamicに構造体や関数をロードできるらしい。

https://pkg.go.dev/plugin

[mizosukedev]

https://dagger.io/

serverが出来たらe2eテスト実装してci/cdパイプラインに乗せたいっすね～。

[mizosukedev]

Authorization WebAPI

• 認証用。
• 開発用目的なので後回し。つまり最初は認証無し。
• 変更しやすいように作る。

  Login

• Pending

  Logout

• Pending

[mizosukedev]

Tunnel WebAPI

• Tunnelの管理用API。
• Open / Close / Describeとかのアレ。
• AWS IoTのインターフェースに似せて作る。
• 開発用に楽できるAPIは追加しても良さそう。

OpenTunnel POST

• Request	name	required	description
  services	X	ServiceID。SSH/RDPとか。
  thingName	X	通知先device名
  timeoutMinutes	X	トンネル生存時間(分)
  payload	X	拡張用。URL入れてデバイスに通知とかできる。

• 処理内容

  • TunnelIDを生成する。
  • TunnelIDからdestination / source 両AccessTokenを生成する。
  • TunnelIDをキーにして、Tunnel情報を保存。
  • デバイスに通知する。 -> インターフェースにして変更可能にする。
  • TunnelID / AccessTokenを返す。

• Response	name	description
  TunnelID	Tunnel毎に固有のID
  DestinationToken	Destination localproxyの認証トークン
  SourceToken	Source localproxyの認証トークン

• 要検討事項

  • 同じTunnelID、同じTokenで接続してきたら先勝ちにするか？後勝ちにするか？
  • 一方のmodeのみ接続されている時に通信が始まった場合は？切っちゃう？以下に例。
  • sourceしか接続していないのにStreamStartが送られた。
  • 正常に通信していたが、一方が切れてしまった。接続が切れていない方からデータが飛んできた。

ListTunnels GET

• Request	name	required	description
  各種クエリ	X

• 処理内容

  • tunnel情報をクエリに応じて全て取得する。-> インターフェース
  • bodyにセットして返す。

• Response	name	description
  TunnelSummaries[]	Tunnel情報の配列
  - TunnelID
  - Status
  - ThingName
  - LastUpdatedAt

DescribeTunnel GET

• Request	name	description
  TunnelID	Tunnel毎に固有のID

• 処理内容

  • tunnel情報を取得する。
  • bodyにセットして返す。

• Response	name	description
  TunnelID
  ThingName
  TimeoutMinutes
  Payload
  Status
  DestinationConnectionState	destination localproxy Connected / Disconnected
  SourceConnectionState	source localproxy Connected / Disconnected
  LastUpdatedAt
  CreatedAt

CloseTunnel PUT

• Request	name	required	description
  TunnelID	O	Tunnel毎に固有のID

• 処理内容

  • tunnelIDをキーにしてtunnel情報を更新する。Lifetimeを現在時刻に更新する。
  • 実際の切断処理はここではやらない。

• 要検討事項

  • 閉じられているTunnelの接続を切断する処理は別途timerでTunnel/Connectionの情報を監視して実施するしかなさそう。
  • ↑の理由はマルチサーバーで実装した場合に、CloseTunnelしたトンネルの接続が自身のサーバーで管理されていない可能性があるから。

[mizosukedev]

Development WebAPI

• 開発、デバッグ目的のWebAPI。
• Endpointは分けた方がいいかもしれない。または設定や起動引数で有効/無効を制御できるようにすべきだろう。

SendToPeer

• Request	name	required	description
  TunnelID	O	Tunnel毎に固有のID
  Type	O	message type
  StreamID	X	streamID
  Payload	X	message payload
  AvailableServiceIDs[]	X	service id

• 処理内容

  • 送るだけ！

• Response

[mizosukedev]

TunnelID / AccessToken structure

• TunnelIDは乱数生成。
• AccessTokenは管理しやすいように下記の構造にする。
  • TunnelID + セパレータ文字 + ランダム文字列
  • セパレータ文字で区切ることによりtokenからtunnelIDを取り出せるようにする。

[mizosukedev]

Data structure

Tunnel

name	description
ID	TunnelID
[X] Status	Tunnel status Open / Closed。データとして持ってはダメそう。
SourceToken	AccessToken。ハッシュを保存すべき？
SourcePeer	全Connection共通の情報。
- ConnectionID	現在管理対象としているConnectionと関連付ける。
- ClientToken	最初に送られてきたclient-tokenヘッダの値。
- NumberOfConnections	接続回数。
DestinationToken	AccessToken。ハッシュを保存すべき？
DestinationPeer	全Connection共通の情報。
- ConnectionID	現在管理対象としているConnectionと関連付ける。
- ClientToken	最初に送られてきたclient-tokenヘッダの値。
- NumberOfConnections	接続回数。
Services	ServiceIDs
ThingName	通知先デバイス。
TimeoutMinutes	トンネル生存時間。
Payload	独自拡張用データ。
LifetimeAt	トンネル生存期間。このフィールドでOpen / Closedを判定しStatusはデータとしては持たない。
CreatedAt	作成時間
LastUpdatedAt	更新時間

Connection

name	description
ID	ConnectionID。
TunnelID	TunnelID
Status	Connected / Disconnected
CreatedAt	作成時間
LastUpdatedAt	更新時間

[mizosukedev]

Pluggable

• 起動引数や環境変数でロジックを交換可能にする。

対象機能

• 認証
  • cognitoでの認証。
  • 認証無し。
• データ保存
  • memoryでの保存。この場合はマルチサーバーは対応できない。
  • dynamodbでの保存。
• デバイスへの通知
  • awsiot mqttでの通知。
  • 独自サーバーへの通知。
  • slackでの通知。

[mizosukedev]

Scalable / Multiple server

• 本件は検証に時間がかかりそうなので後回しにする。あとで別途Issueを起票する。
• 何も考えずに実装してしまうと、複数台で動作させた場合にsourceとdestinationが同じホストに接続しないとうまく動作しない。
• これを解決するための実装は、今の所３つある。

サーバー間で通信する。

• grpcでサーバー間で通信させる。
• この場合はConnectionデータストアに接続しているサーバーのアドレスを保存しておけば実現可能。

メッセージのやり取りにマネージドなサービスを使う、または作る。

• AWS Kinesisとかだといける？だがAWSに依存したくないっすね。
• 作っても良いが、作るくらいならgrpcで通信させた方が良い。

ロードバランサーで頑張る

• localproxyが接続する時にtunnelIDをrequest headerに入れて接続するようにする。
• 同じtunnelidは同じホストに接続するようにロードバランサーを設定する、または実装する。
• ロードバランサーは自前でリバースプロクシを実装するか、Apache / nginxのプラグインで対応できそうなものがあるか？
• ちなみにAWSのELBでは無理そうだった。

[mizosukedev]

マルチサーバーとか言い出したら開発用じゃなくなってきてるね。。。 とりあえずdesingのラフはこんなところにして、プロトタイプを実装していくことにする。