[レポート] 【株式会社チカク様登壇】IoT スタートアップの小さくはじめるサーバインフラ #AWSSummit

[レポート] 【株式会社チカク様登壇】IoT スタートアップの小さくはじめるサーバインフラ #AWSSummit

Clock Icon2016.06.03

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

IoT スタートアップの小さくはじめるサーバインフラ

6/1 (水) ~ 6/3 (金) に開催された AWS Summit Tokyo 2016Develoeprs Confrence のセッション「IoT スタートアップの小さくはじめるサーバインフラ」を聴講しました。本記事はそのレポートです。

株式会社チカクは、離れて暮らすおじいちゃん・おばあちゃん宅に子どもたちの動画や写真を届けるサービス「まごチャンネル」を提供している社員 4 名の会社です。小さくてもしっかりとサービスを提供し続けるために AWS をどう活用しているのか、どのように考えて構築していったのか、今後どのように発展させていくのかについてご紹介します。

スピーカーは 高橋 一貴 氏(株式会社チカク シニアエンジニアリングマネージャー)です。

セッション

今日の話

  • 製品紹介、ハードウェア
  • サーバーインフラの開発と運用
  • 今後について

自己紹介

  • 株式会社チカク
  • シニアエンジニアリングマネージャー
  • サーバーサイドとオペレーションの中間で、落ちそうなボールを片っ端から拾う仕事
  • 元Yahoo!

チカクについて

  • 2014年創業
  • 平均年齢35歳
  • 社員4名 + インターン4名
  • 四苦八苦中
  • 最初のプロダクト「まごチャンネル」をリリース、出荷真っ只中

まごチャンネル

  • おじいちゃん、おばあちゃんのテレビにつなぐ
  • 動画を送ることができる
  • いい感じに光る (超重要!)
  • 沢山撮っている写真をおじいちゃん・おばあちゃんにどれほど見せているかというとそうでもない
  • うまくいく方法がないので作ろう、ということで生まれた
  • 動画や写真をスマホから届けることができる
  • インターネットのない家庭でもOK (SIM が入っている)
  • リモコンで簡単操作
  • セットアップまでしてから送付するので、繋げるだけですぐに見れる
  • テレビで出すと、実際の子どもより大きい
  • 見たことのフィードバックが送った側に届く(送るモチベーション、生存確認)

様々なメディアに登場

  • 日テレの Sensors で紹介
  • 日経新聞の第一面に
  • 様々なメディア

リアル店舗への展開

  • Isetan とコラボ (新宿伊勢丹で6/19までの期間限定)

まごちゃん受信ボックス

  • Linux ベースの何か
  • 動画や写真をポーリング
  • 電波状況を送り続ける
  • 深夜に S3 を見てファームウェアアップデート

ハード要件の特徴

  • コンセント差して常時稼働
  • 3Gモジュール搭載 (SORACOM)
    • 放射電波ノイズ、熱対策が必要
    • 玉川さん神
  • 普通の REST っぽい API を叩く感じ

ハード怖い #1

  • 量産まで持って行くのに半年以上 ES EVT DVT PVT MP
  • 不良がつきもの (部品、製造の歩留まり、)
  • 工程にも予想外のことが起こる
    • 射出成型だと斜面を作らないとダメ、などなど

ハードが怖い #2

  • 技適
  • 電気通信事業者の届け出
  • PSE
  • PL保険 (AC アダプタについているあれ)
  • HDMI コンソーシアムに登録必要
  • 製品保証
  • 先に出て行くお金が膨大
  • 重量負荷分散
  • などなど

IoTスタートアップに足りないもの

  • 人、時間、お金
  • これが極端に足りない
  • Yahoo!は、爆速という言葉がある。あと、黒帯とかで大企業ハックしてきた。
  • だがそれすらもできない。
  • ウィッシュリストでおねだり

関心ごとも多岐にわたる

  • 設置環境
  • 故障検知の可能性
  • カスタマーサポート
  • 分解、解析スキル
  • 在庫管理
  • ・・・

ならば、サーバーサイドをどう考えるか

  • やることいっぱい、サーバーばかり面倒見てられない
  • 「ちょうどぴったり」
    • 間に合うギリギリのタイミングで用意する
    • それが目の前に来るまで飛ばない
    • 先送りに見えるが、情報が出きってから判断する
    • サーバー多すぎると無駄、アラート地獄
  • なんでも「ちょうどぴったり」がいい
    • インフラ
    • サービス設計
    • システム設計
    • などなど
  • 目の前にフォーカス
    • 先読み難しい
    • 先読みのコストメリットが少ない
    • ビビってやるのは無駄では

まずは手馴れたものから

  • EC2/ELB
  • S3/RDS
  • ElastiCache
  • SNS/SES
  • Dockerもやりたいけど中途半端になりそうなものは今は切り捨て
  • 目まぐるしく変わるので、1週間後に変わるかもしれない

6つの構成要素

  • API
    • HTTP エンドポイント
    • ELB で受けて EC2 が処理
    • t2.medium で動かしている
    • 動画、写真を扱うので
  • Job
    • Redis でキューイング
  • Web
    • 冗長構成なってない
  • Data Insight
    • 集計
    • Kibana
  • Data Store
    • コンテンツを S3 に保存
    • 明らかに責務が違うものは RDS インスタンスごと変えている
  • STB Update
    • S3 においている
    • 深夜に観に行き、アップデート

監視

  • 兆候に気づく仕組みにしたい
  • CW / New Relic / Mackerel
  • PagerDurty すごい便利

シンプルな構成

  • サービスが自信あるが、継続が約束できると思っていない
  • 管理要素を減らし、その分変更に弱くなる
  • サービスを動かしてみて要件が出てくる
  • コスト構造も見えやすい

例えば

  • 出荷管理を Google スプレッドシートでやろうとしたら管理しきれそうにない
  • システム作る時間もない
  • Trello を活用した
    • 自動でタスクが登録される
    • QR コードを読み、手入力させない

ちょうどぴったりを支えるツール

  • RoR
  • Packer
  • RSpec
  • Bitrise / Circle CI
  • Capistrano3
  • Vagrant
  • waffle.io (GitHub の Issue管理)

現在の課題

  • 突発的な負荷があるとメモリを食い尽くす
  • 管理画面がまだないが必要ないものを作るよりはマシ
  • もう少し月々お安くしたい
    • AWS Activate プログラム良い!

次の「ちょうどぴったり」

  • もっとぴったりするものが出てくる
  • Lambda 登場、安くなりそう
  • システムが小さいうちに移行したい (API GW + Lambda など)

感想

技術だけではなく UX を意識したプロダクトで非常に好感が持てました。「ちょうどぴったり」大事ですね。時間もないしコストもない中で、とても大事な考え方だと思いました。

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.