lulzneko
プレゼンテーション

デブサミ 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 を ３つ使っていて、データの内容物としてはおぼ同じものになり、ムダになっているように見えます。

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

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

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

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

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