【レポート】時計会社がつくる UX 共有プラットフォームとは?ユーザーが開発したコードを AWS Lambda にデプロイする開発者参加型アプリケーションの仕組み #AWSSummit
どうも、もこ@札幌オフィスです。
今年はAWS Summit Onlineという事で、2020/9/8〜9/9の間のライブセッションと、9/30まで視聴可能なAWS認定セッション、お客様事例セッション、セルフペースハンズオン、Partner Discovery Session (パートナーセッション) などなど、場所を選ばずにオンラインで、好きな時に好きなだけ学べるような環境になっています。
本記事はオンデマンドセッション「CUS-73:時計会社がつくる UX 共有プラットフォームとは?ユーザーが開発したコードを AWS Lambda にデプロイする開発者参加型アプリケーションの仕組み」のセッションレポートとなります。
セッション概要
シチズン時計株式会社 時計開発本部 時計開発部 コネクテッド開発課 担当課長 松王 大輔 氏
2019 年、シチズンは Riiiver というプラットフォームサービスをリリースしました。本サービスのインフラには AWS を採用し、AWS Lambda の性質を活かした開発者環境も用意しました。Riiiver とはいったいどんなサービスなのか?時計会社がなぜプラットフォームを作るに至ったのか?その背景と仕組みをご紹介します。
セッションレポート
Agenda
- Riiiverとは?
- なぜ時計会社がAWSプラットフォームが必要になったか
- Riiiverの構想
- Riiiverの仕組み
- Piece開発者はサーバーレスでデプロイ
- Pieceのデプロイとデプロイ語の実行について
- まとめと課題
Riiiverとは?
- なぜ時計会社がAWSプラットフォームが必要になったのか
- これからの腕時計は何かを考えながら日々仕事をしている
- 今までの時計は工場に作ったときに製品の仕様が決まっている
- これからの時計は、ユーザーの手によって機能を設定したり、生み出したりできると素晴らしいと思った
- ハッカブルな時計を作りたい
- ハッカブルな時計だとプログラマーしか使えないので、誰でも使えるようにしたい
- UXを生み出す敷居を下げたい
- プログラミングが出来る人は世の中で少数
- 非プログラマーでも創意工夫できる敷居を下げたい
- Riiiverの仕組み
- RiiiverはIoTプラットフォーム
- 時計のボタンを使えたり、時計の各種機能がある
- 時計のボタン、光量、針の表示などの機能をモジュール化、アイコン化してシンボル化していく
- WebサービスもUXをベースにシンボル化
- 降水確率はどれくらいだろう?株価はどれくらいだろう?をシンボル化
- https://app.riiiver.com/piece_list/piece_list.html
- 何をしたいのか?
- プログラミングの代わりにこれらの機能を順番に選んでアプリに相当する機能を提供できる仕組みを作りたい
- スライドの例は、ボタンを押したときに、降水確率を取ってきて時計の針で表示する
- Pieceはユーザーが組み合わせる機能のパーツ
- Trigger Piece - きっかけ
- Service Piece - サービスを提供
- Action Piece - サービスの結果を出力
- iiideaはTrigger/Service/ActionのPieceの集合体
- これらの3つを組み合わせるだけでリリース出来るような仕組み
- Riiiverを開発する上でどのような点に気をつけたのか
- 世界中に時計を販売していて、Riiiverについてもグローバルで展開したい
- 時計会社が大きなサーバーサイドのシステムを作るのは到底無理
- 小さく初めてまずは試してみたい
- ユーザー数が上がったところで大きくしていく
- たくさんの開発者の成果物、Pieceを抱える
- Lambdaを使うことでうまくはまらないかなと考えていた
- グローバル展開
- Amazon VPC / Amazon CloudFrontを活用すればうまくいくことを期待して開発を進めている
Piece開発者はサーバーレスでデプロイ
- Pieceの数の多さがプラットフォーム成長の鍵になる
- 開発環境の種類は大きく分けて2種類
- Edge側で動作するPieceとWebで動作するPieceがある
- 今回紹介するのはRiiiverをWeb上で動かすPiece
- Web上で動かすPieceがAWS Lambdaを利用している
- Pieceの構成
- "誰がロジックか"の部分が重要
- iiideaの実行動作
- Lambda上の自分が受け取った値に対して処理して次のPieceに出すアウトプットだけにフォーカスすれば良い
- Lambda関数に渡されるinputにある前のpieceのデータを元に処理をして、次のPieceに渡すデータをJSONで返せばOK
- 開発者はWeb Portalを利用してLambda関数をアップロード
- Lambda関数の実行環境はRiiiver側で用意
- 開発者自身がLambdaの環境を整える必要は無い
- Piece開発からリリースまでのフロー
- 開発者はPieceの成果物をWeb Portalからアップロード
- S3に成果物を保存、PieceJSONをPiece Serverに送信
- Web PortalはAuroraやCognitoを利用して認証認可している
- PieceをStoreに出して良いのかを確認している
- Piece審査員が利用するWeb Portalもある
- 承認するとPiece Serverにて公開済みのフラグが立てられ、S3にあったPieceがLambdaの実行環境にデプロイされる
- 開発者はPieceの成果物をWeb Portalからアップロード
- Pieceの実行フロー
- Piece Coreによって、EC2にあるPiece Proxy Serverが呼ばれる
- Piece Coreの呼び先を同じするためにPiece Proxy Serverを用意
- Piece Proxy Core関数からPieceのLambda関数を実行して処理を行う
- Piece Coreによって、EC2にあるPiece Proxy Serverが呼ばれる
- Lambda関数を利用したPiece開発からリリースまで - Lambdaの特徴を活用できたか
- Pros
- 開発者はサーバーを準備しなくても良い
- スマートフォン側の処理や開発環境について意識する必要が無い
- 一つのLambda関数だけに集中出来る
- 独立性も担保出来ている
- 開発者の区切りが関数の区切り
- 障害が起きても他のPieceに影響しない
- Cons
- 現状、本番環境でテスト・デバッグ出来ない
- Pieceの承認フローがあるので、将来改善していきたい
- 現状、本番環境でテスト・デバッグ出来ない
- Pros
- Riiiver Platformの開発環境として - Lambdaを利用することで得られたこと
- Pros
- 開発者はサーバーを準備しなくても良い
- スマートフォン側の処理や開発環境について意識する必要が無い
- 一つのLambda関数だけに集中出来る
- プログラミングの敷居を下げれて、創意工夫出来る敷居も下げることが出来た
- Pieceがたくさん開発されて、非プログラマーの方でも既に開発済みのPieceを利用して創意工夫が出来る環境が出来る
- 世の中のリリースする初めてのプログラムが「Lambdaを利用したRiiiverのPiece開発でした」という人が増えれば嬉しい
- Pros
Developerサイトでチュートリアル公開中
- https://developer.riiiver.com/
- 開発者が作ったアウトプットはPieceでiiideaではない
- 開発者が作ったPieceともう二つの開発者の知識・知恵が集まって初めて一つのiiideaになる
- 非プログラマーがPieceを使ってどのように利用されるのかも一つの楽しみになることを期待