デブサミ 2019 Ask the Speaker で 頂いた QA まとめ

Developers Summit 2019 で『サーバーレスで最高に楽しめるアプリ開発』の お話をした後の Ask the Speaker で 頂きました QA を まとめます。

頂いた質問は要点のみを一般化して書いています。背景などが入っていないので若干わかりにくい部分がありますが、ご了承ください。

シリーズの記事

発表資料 と Togetter

デブサミ2019【15-B-6】サーバーレスで最高に楽しめるアプリ開発 #devsumiB - Togetter
沢山のツイートありがとうございます!!

1. ピタゴラ装置式で障害が発生したら、どのように追跡するか?


例えば IoT プラットフォーム の 例では、AWS Lambda を 細かく分けていますし、いくつかの サブシステム や AWS アカウント を またがって処理を行っていたりします。

また入力ソースが バッチ と ウェブ が あり、途中から同じ処理フローになっていきます。

障害が発生すると、結局のところログを洗っていくしかないのは変わらずで。分散されているので地道に追いかけています。

開発メンバーのひとりが、トレースID を ヘッダーにつけてリレーする方式を導入を進めてくれているため、導入されている範囲は比較的探しやすいです。

その方法は以下となります。

  • リクエストを最初に受けた場所は、次のリクエストを投げるときに TRACE_ID というヘッダーに UUID を つけて送る (※ TRACE_ID は 本記事用の仮名)
  • 中間の処理でも TRACE_ID が なかったら、そこから TRACE_ID を つけ始める
  • TRACE_ID を 受け取った場合は、その値をリレーして使っていく(新たに発行しない)

マイクロサービスのトレーシング用ライブラリや基盤もあります。いまちょっと名前が思い出せないです。すみません。まだ、しっかり調査できてないので導入できてないです。

※ 本記事投稿時追記
マイクロサービスのトレーシング は Zipkin という 分散トレーシングシステム を 思い出して話していました。名前がすぐに出てこないとは💦
同様のプロダクトやサービスがあり、今後調べていきたいと考えています。

2. ラップ・アプリ の モバイル通知が Amazon SNS でないのは?


ラップ・アプリ は Web API を AWS に 構築しています。
AWS を 使っているので Amazon SNS(Simple Notification Service) を 使ってモバイル通知をすれば、ワンストップになるので良いのではないかとも考えられます。

これについては、ざっくり行ってしまうと「普段から使っていたから」が 一番大きい理由になります。

これは、ハッカソンという時間が限られた場で開発をするので、使い慣れているものを使うのが一番ということになります。

では、なぜ普段使いだったのか(普段 AWS なのだから、SNS が普段使いでもよいはずで)

モバイル通知を必要としたころの調べで、FCM(Firebase Cloud Messaging) のほうが手軽に扱えて、サポートするモバイルデバイスが広かったので FCM を 使い、その後も使い続けているといった理由になります。

今なら Amazon SNS でも変わらないのかな。いずれ調べてみたいと思います。

3. IoT プラットフォームでファイル分割処理場をしてる理由は?


開発当時 AWS Lambda が 5分しか稼働できなかったため、ファイルを分割しながら DynamoDB へ 投入しているとタイムアウトしてしまったためになります。

そのためいかに高速に処理を行えるようにするかを考え「ファイル分割だけ」をすることが高速化につながったので、ファイル分割を入れています。

高速化のために AWS Lambda の ローカルストレージを使ったりと様々な工夫が入っています。

2019年2月現在は 15分まで稼働できるので、このシステムではファイル分割をしなくても処理しきれるかもしれません。

4. IoT プラットフォームの DymemoDB はコスト高ではないか?


たしかに DynamoDB を 3つ使っていて、データの内容物としてはおぼ同じものになり、無駄になっているように見えます。

まず DynamoDB の ストレージ料金は、高額ではありません。
データの複製を大量に持ったとしても、ストレージについては気にしなくてもよいかもしれません。

ストレージ料金に対して Read/Write の キャパシティが高額です。
このシステムはバッチ処理で一時的に大量データを読み書きする必要があるため、特に1つめの DynamoDB の キャパシティは高く設定しています。

それでも何百ドルとまでは行っていないはずなので、1つの DynamoDB にして処理ロジックを複雑にさせるより、複数配置するほうを選んでいます。

※ 本記事投稿時追記
2019年2月 東京リージョン の ストレージ単価は 0.285 USD/GB
10GB の データベースで 約3ドル、超大規模デモない限りロジックの簡易さを求めてもよいのではないでしょうか。

Read/Write キャパシティについては、オンデマンドキャパシティモードも出たので、状況に応じて変わってくるかと思います。

Amazon DynamoDB 料金
https://aws.amazon.com/jp/dynamodb/pricing/

AWS Simple Monthly Calculator (簡易見積ツール)
https://calculator.s3.amazonaws.com/index.html?lng=ja_JP

5. Amazon SNS で 処理を分岐するメリットと活用方法について


IoT プラットフォーム の 例では、Amazon SNS で 本処理 と Redshift へ データを渡すのを分けています。

スライドの図では処理の流れを示したかったので矢印が Amazon SNS → DynamoDB の 用になっていますが、実際の流れとしては Amazon SNS へ Subscribe しているので矢印が逆になります。

処理を分岐しているというより、データの公開場所を用意したので、欲しい人は見に来てくださいという形になります。

この形のメリットはデータが欲しくなった人が増えた時に、Amazon SNS の Subscribe を 追加するだけで追加でき、ロジックを変更しなくてよいものになります。

6. Amazon SNS で ウェブの処理を分岐できますか?


Amazon SNS の Subscribe で 動作するのは非同期処理になります。

ウェブのリクエストが Amazon SNS の 先の処理結果を必要とせず、何かしらのデータを Amazon SNS に 公開して、ウェブのレスポンスを返せる場合は、処理分岐として利用可能です。

プログラミング の if文 の ような条件分岐としては利用できません。
Amazon SNS は データの公開場所を作っておき、そこにデータを置く人、データをもらう人、それぞれが それぞれのタイミングで動作するイメージになります。


Ask the Speaker へ 来てくださり、ありがとうございました。

QA や 議論 が でき、とても楽しかったです。そして お話しいただくことで気付きを得たり、考えの整理にもつながり、とても勉強になりました。

できる限り思い出して書きましたが、もし入ってなかったり、別途気になることなどがありましたら Twitter @lulzneko へ DM や メンションいただけたら幸いです。

Author: lulzneko