センサースケーリングの話
どうもくろにゃんこたんです。
今回はKinesisFHを使っていて不思議な現象に出会ったのでまとめました。
こちらはSORACOM UG 信州#2のLT枠で発表させていただいたものを使っています。
なかなか煮え切らない感じで終わりますが、最後までお付き合いください(´ω｀；)
煮え切らないで終わるのもなんなので、おまけを怒涛3連発で同時公開しました！
こちらはおまけ1発目。
スライドにコメントを入れて公開しました。
おまけ2発目
PHPでSORACOMBeamを受けるって言う話なのですが、
IFTTTだとIMSIとかのカスタムヘッダーが取れない（らしい）ので、
IMSIとか取りたい場合やとりあえずレンタルサーバを使ってやってみたい人にはオススメです。
おまけ３発目
SORACOMコーポレートカラーのLチカを、誰かやっているようでやっていなかったかもしれないので作ってみました。
本当はもう少し公式的なものを使ってやってみようかと思ったのですが、
自分でカラーコードを一つ一つ調整しながら、キレイめに出したかったので地道に作ってみました。
analogwriteではなくWioLTEのライブラリを使っているので、やっていることはシンプルです。
なにかうまい方法があれば教えていただきたいです(・ω・)ノ
※注意！
いきなり負荷試験を行うと、攻撃とみなされAWSのアカウントを突然停止させられる可能性があります。
詳しくはこちらをご参照のうえ、AWSサポートに連絡したうえで行ってください（´ω｀）
https://aws.amazon.com/jp/security/penetration-testing/
ぼ、僕はちゃんとAWSの中の人と話を通して行ないましたよ！|дﾟ)
自己紹介と目次です。
LTでくろにゃんこたんです！って言うのもちょっと恥ずかしい(｡>﹏<｡)
僕のスキルクラウドです。
やってみたかったのでQiitaでも出しましたが流用いたしました。(´ω｀)
医療情報技師なんて資格を大学時代に取ったのですが、英語名称が長くてバランスが難しいです(´ω｀；)
最初はそらこむふぁんねるって読んでいたので、いつも忘れないようにふりがなを振るっていう(´ω｀)
SORACO Funnelを使ってS3に保存したデータをAthenaで解析するネタに使った画像の紹介。
S型がいい感じにハマって個人的には気に入っています(´ω｀)
本題
Kinesis Firehoseのリミット制限をAWSのWebから転載。
今回はこの黄色のマーカーがテーマです。
正直なところ、小規模データをS3へPUTするだけならトランザクションはほぼ無視出来るので
とりあえず問題はレコードです。
SORACOMに限ったことでは無いのですが、小さいデータを大量に送りつけるにはレコードがやっぱり重要なのかなと。
でも爆発的に広めたのはSORACOMなのでやっぱりSORACOMネタなんです！
ここで言うスケーリングと言うのは、端末側が増えたことを言ってます。
Kinesis Streamを使えば？っていうのは今回は考えません！FH一本で乗り切るにはどうするかと言うのを考えてます。
SORACOM Airなんて端末台数が1,000台あっても一瞬でコントロール出来るので、なかなかにありえる話です。
１０００台とかになってくるとこの「レコード」が重要になります。って話。(´ω｀)
まぁココまでは良いんですよ。数値で計算出来るので。。
問題はココから。
恐れ多いですが、インフラ初心者から見た負荷の設計についてです。
計算上は4000台まで1秒毎送っても大丈夫。
では無かった！！というところからが本番です。
テーマの素材をそのまま使わせていただきました。
僕としてはこんな感じのマウスは使いにくくて、エルゴノミクスデザインのガッチリしたやつが好きです。
ちょっと雑な感じもしますが、テストの構成としてはこんな感じ。
本当はSORACOM端末4000台でやるのが筋ですが、そんなに持ってないので、通常のHTTP→S3への構成でテストします。
テスト側のEC2はマスタにWindows、スレーブにAmazon Linuxのｃ4を採用しました。
24万アクセスを達成するのも案外お金が掛かるので、2万アクセスとさせてください。
大丈夫です。こんなグラフが出来ますので。
一発目は99.9％の信頼も担保できず、0.4％もエラーで返ってきました。
ですが、回を追う度に徐々に少なくなってきます。
HTTPだから？
確かにインターネットを経由しているので、パケットロスする可能性は十分にあります。
AWSからAWSに飛ばしていますが、異なるリージョンで行なっているのでインターネットを経由します。
端末からSORACOMを使って通信する場合そのままAWSに行くので、その点信頼性は高いですが、Funnelから別のAWSにPUTすることになるのでこのロスは見過ごせません。
が、パケットロスが原因ではないような感じですね。
だってエラーが減っていくんですもん。
昔ELBを使っていたときに、ちょいちょい暖機運転をサポートにお願いしていたことがあるのですが、その時の感じが思い起こされます。
暖気が必要なのか？疑惑発生。
サポートに聞いてみました。
他にも色々と回答があったのですが、抜粋しました。
結論としてはKinesis Firehoseには暖気という考えは無い。
ですが、継続的に負荷を掛けていくことによりエラーが解消することがあるとのこと。
うーむ根が深いですね(´ω｀；)
API GatewayからKinesisFHへ行くときにエラーになることもあるとのことです。
なので単にこの構成が駄目で、SORACOMだと問題無い。という可能性も十分にありえます。
こんな問題インフラ初心者が真っ向から挑んだってむだむだむだー(・ω・)ノ
そもそもそれが問題になるようじゃダメだ。という話に落ち着きます。
それにしてもGoogle Slideって便利ですね(・ω・)
画像を選択するときに、画像検索が出来るのですが、そこに出てくる画像は再利用OKのもの。というのがすごくやりやすいです(´ω｀)
まぁSORACOMで再現出来るのかはそもそもやってみないと分からない。という煮え切らない結論。
実機でやってみたいものです(´ω｀)
煮えきらないところで終わってしまいますが、結局そんなギリギリの状態で運用するのが間違ってる。
AWSだって既知の現象があるくらいなんだから自分の頭で考えたところで限界があるので、それ前提で考えましょう。
ということに落ち着きます。
Webでは無いので一斉にどかんとデータがSORACOM搭載のセンサーから来るという想定はあんまりないかもしれませんが、
数秒の間に数千件とかのレベルでデータが来ると、知らないところで抜け落ちる可能性がある。ということでそれを前提として考えたほうが精神的に楽です。
というか無線なんてそもそも何があってデータが送れないか分からないし、センサーだって何があるか分からないから、絶対動くと信じる前提はきついです。
送ったはずのデータが来ていない。ということが実運用であるので、その経験もあり今回の記事と
この前のBLEの記事もデータが来たらいいなーレベルで書きました。
もっと気楽に考えましょう(´ω｀)
はい今回のオチ。
これがやりたくて頑張ってブログも書きました。
どこかで見たことありませんか？この文言（笑）
以上です(´ω｀)
最後まで読んでいただき、ありがとうございます。(・ω・)ノ