ちょっとしたデザインの経験談

こんにちは、デザインチームのキョウと申します。
最近はスパイスとカレーにはまっていて、毎日寝る前にインスタで美味しそうなカレーの投稿写真をひたすら眺めることで、日々の癒やしの時間として過ごしています。
そろそろスパイスマスターの資格を取ろうかなとも考えております(・∀・)

さてさて、本題に入ります。

web業界の流行りのビジュアルデザインとUIデザインの変革をずっと見てきましたが、自分がデザインする時によくやっていることや、使っているツールについて、ちょっと話をしようと思います。

- ひたすら参考サイトを見る

デザイナーとして働いてもうすぐ9年になりますが、新人として働き始めた頃は、ひたすら参考サイトを探して、いいと思ったデザインをひたすら真似して作るという経験は、今でも生かしています。
特にデザインのアイディアがどうしても浮かばない時や、複雑なUIはどうやって作っていくのかは悩んでいる時に、とにかく参考書のようにいろいろなサイトを見ていました。

優れたものをひたすら眺めて、考えて、いざ手を動かして作ってみると、徐々に自分のものになっていく感じがとても実感できるようになります。
そしてこの過程をやっているうちに、自分なりのアレンジもできるようになり、最終的にデザイン感性の磨きとスキルアップには繋がったと、私はそう感じています。

最近では、作る前にもう既に頭の中にイメージが湧いたり、こういう場合はこういうUIだー、この改修ならこのサイトのUIを参考にすればいいよー、みたいなことができるようになりました。

私がよく参考にしているサイトはこちらになります。

webサイト系ならここらへん：
https://muuuuu.org/
https://bookma.torch.blue/
https://1guu.jp/

バナー、チラシ系ならここらへん：
https://retrobanner.net/
http://bannermatome.com/

配色に悩んだら：
https://colorhunt.co/
https://colors.muz.li/
https://coolors.co/

そしてみんなご存知のピンタレスト（何でも参考になります）：
https://www.pinterest.jp/

- このデザインは難しい、どうしたらいいかは分からない時は

最初の一歩が難しく、なかなか手を付けられないと感じているデザイナーはいると思いますが、そんな時に、とにかくめっちゃラフな状態でもいいので、紙にワイヤーを書いたり、FigmaやSketch、Adobe UXなどのUIが作りやすいツールで簡単なレイアウトを作ったり、コンテンツの整理から始まるといいと思いますね(σ・∀・)σ

もちろん会社にちゃんとしたディレクターがいて、ディレクターがキレイなワイヤフレームを書いてくれるケースも多いと思いますが、うちの会社の場合は、正式なディレクターという役割を持っている人はいないので、大きなコンテンツ改修や、新規ページを作成する際に、デザイナーはディレクターの役割として働かないといけない時は結構あります。
そういう時、やはり作業依頼者に要望を聞きながら、まず最初はコンテンツと情報の整理から、ワイヤフレームを作っていくというケースが多いです。

ワイヤフレームができたら、自分も作業依頼者も頭の中でイメージができるようになり、フィードバックのやりとりもしやすくなりますね。
そして最初からデザインガイドラインが決まっていれば、わりとデザインにすんなり入れるようになります。

もし最初から色もデザインのテイストも決まってないであれば、やはり先程申し上げた通り、参考サイトをとにかく真似して作ってみよう、そして細かいデザイン調整や、難しいパーツは後回しにしよう、と私はよくこのやり方でやっています。
そしたら、デザインのスピードもかなり上げられて、最初のデザインから何回もブラッシュアップして行くうちに、どんどんいいデザインが出来上がっていきます。

- 常識にとらわれない、時には変則も必要

デザインガイドラインは既に決まっていて、サイトで使う色やフォントも決まっている案件は多いと思いますが（特に自社の保守案件の場合）
明らかにここはこの色を使うと変だよー、でもデザインガイドライン上ではこのボタンの場合はこの色を使えと書かれているよー、この部分はデザインガイドラインに載せた色と文字サイズだとすごく見づらいよー、みたいな時は結構あると思います。
そういう時、きっちりデザインガイドラインを沿って作るより、やはりユーザー目線から見て、ユーザー層を考えた上で、見やすい、使いやすいデザインにするのが一番大事だと、私は思いますね。

もちろん、デザインガイドラインや、サイト全体の統一感からすごく離れたテイストや色を使うのは駄目だと思います。
でも、同じ色トーン、似たような構成であれば、ちょっとした変化を出したり、色を鮮やかにしたり暗くしたり、文字サイズもちょっと上げたり下げたりするなら、全然ありだと思いますね(σ・∀・)σ

そして世の中のデザインルールでは、同じサイトでは最大3-4種類のフォントスタイルと色を使わないという傾向があると感じてますが、もちろん統一感とスッキリ度は大事だと思います、自分もごちゃごちゃしたデザインより、スッキリしたデザインの方が好きです。
でも時には、どうしてもユーザーに見てもらいたい、どうしても特別感を出したい、どうしてもスペシャルなコンテンツにしたい時ってありますよね？
そういう場合、きちんとルールを守るより、時にはちょっと外れたデザインをするのもありだと思いますけどねヽ(^o^)丿

以上。
ちょっとした自分なりの経験談でした。
参考になれたら幸いでございます。

そして、スパイスの力でみんなが健康な体に作れたらいいなと、願います(｀・ω・´)ノ

AWS CodePipelineを用いたデプロイ

DevOps チームの うすい と申します。よろしくお願いします。 昨年11月にハーフマラソンに出てから膝に矢を受けてしまった状態が続いています。困っています。

今回は最近作ったシステムにおけるデプロイについてお話したいと思います。

前提

弊社の主だった環境は AWS 上にあります。また、ソースコード管理には GitLab を使用していて、GitLab CI も元気に稼働しています。 本システムは小規模で、リリース後のデプロイは多くないことが想定されています。

デプロイフロー

フローとしては下記のようになっています。

1. master マージ
2. GitLab CI で成果物を S3 にアップロード
3. S3 にファイルが作成されたことをトリガーとして CodePipeline がスタート
4. ステージング環境にて CodeDeploy でデプロイ
5. 本番環境デプロイ承認のためのメール送信と Slack 通知
6. 承認権限を持った人が CodePipeline の中で承認
7. 本番環境にデプロイ

少し細かく見ていきましょう。

GitLab CI

GitLab CI の中でcomposer installやnpm installをしています。各ツールのバージョンを簡単に固定したかったため、今回は PHP 用のイメージの中で npm をインストールしたりするのではなく、バージョンを指定したイメージを使用し作成した成果物を次のジョブに引き継ぐ方式をとりました。 .gitlab-ci.yml の概要です。

stages:
  - npm
  - composer
  - upload

npm:
  stage: npm
  image: node:12.14.1-alpine3.11
  script:
    - npm install
    - npm audit fix
    - npm run production
    - tar czf node_modules.tar.gz node_modules
  artifacts:
    paths:
      - node_modules.tar.gz

composer:
  stage: composer
  image: composer:1.9
  script:
    - composer install
    - zip -r ./${CI_PIPELINE_ID}.zip .
  artifacts:
    paths:
      - ./${CI_PIPELINE_ID}.zip

s3upload:
  stage: upload
  image: alpine:latest
  before_script:
    - apk add --no-cache python3
    - pip3 install awscli
  script:
    - aws s3 cp ./${CI_PIPELINE_ID}.zip s3://${S3BUCKET}/${APP}.zip

実際にはbefore_scriptと呼ばれる文字通りscriptの前に実行されるセクションで環境変数ファイルに秘匿情報を埋め込んだりもしています。それらの秘匿情報は GitLab のSecretに保存しています。 このようにして作成された成果物を最終的に S3 にアップロードしています。

また、これまでは nginx や php-fpm の設定ファイルは DevOps チームの Ansible のリポジトリで管理されていることが多く、開発チームで変更したい場合には

依頼&マージリクエスト作成（開発チーム） → マージ＆反映（DevOps チーム） → 確認（開発チーム）

となっていましたが、開発チームで使用しているリポジトリに必要なファイルをすべて含め、CodeDeploy の中で反映を行うようにしました（後述）。

CodePipeline

CodePipeline は S3 にファイルが置かれたことをトリガーとしてスタートします。特に込み入ったことはしておらず、シンプルなパイプラインとなっています。

イメージ図

CodePipeline

SNS との連携も上記画像の真ん中の上にあるNotifyから簡単に作成することができて、今回はパイプラインの成功、スタート、失敗、そして承認時に SNS に通知を送って Lambda を起動し Slack の Incoming Webhooks で通知、といったことをしていますが、AWS Chatbot でも検証中です（下記図）。Lambda 内でメッセージをパースする必要もないので、こだわりがなければ AWS Chatbot で良いかと思います。 承認部分に関してはメールでの通知も行っています。

Chatbot

CodeDeploy

今回は AutoScaling と EC2 を組み合わせたシステム構成になっているので、コンピューティングプラットフォームはEC2/オンプレミス、またデプロイ設定はリリース後の修正が多くないこと、また利用される時間があらかじめ把握することができることから、時間の節約のためデプロイタイプはインプレースにしました。

CodeDeployはイベントという形で順々に処理を実行していきます。

イベント

こちらのAfterInstallの中で設定ファイルのアップデートや nginx の再起動などを行っています。

また、余談ですがインスタンス起動時のユーザーデータに登録したスクリプトで CloudWatch Alarm の作成を行い、ステージング環境など夜間休日にインスタンスを停止する環境において残り続けてしまう CloudWatch Alarm は AWS Batch で削除しています。 AWS Batch のコンテナイメージはこんな感じで作って ECR に push しています。

delete-insufficient-cloudwatch-alarm.sh

#!/usr/bin/env bash

aws cloudwatch describe-alarms --state-value INSUFFICIENT_DATA --region ap-northeast-1 | grep AlarmName | awk '{print $2}' > ./result.txt

sed -i -e 's/"//g' ./result.txt
sed -i -e 's/,$//g' ./result.txt

for name in $(cat ./result.txt)
do
  aws cloudwatch delete-alarms --alarm-names ${name} --region ap-northeast-1
done

Dockerfile

FROM amazonlinux:latest
 
ENV LANG C.UTF-8
RUN yum -y install unzip aws-cli
ADD delete-insufficient-cloudwatch-alarm.sh /usr/local/bin/delete-insufficient-cloudwatch-alarm.sh
 
ENTRYPOINT ["/usr/local/bin/delete-insufficient-cloudwatch-alarm.sh"]

まとめ

今回は EC2 を選択しましたが、別のプロジェクトでは ECS（Fargate）を使用していたり他にも IaC や CI / CD の強化といったこともしています。DevOps チームのメンバーは現在絶賛募集中ですので、興味を持たれた方はご連絡いただければと思います。また、もっといいやり方や改善点を指摘してくれる方もカジュアル面談でお越しいただければと思います。

Composer対応していないパッケージをComposerで定義する

こんにちは。
厳しい寒さが続いておりますが、いかがお過ごしでしょうか。
サービス開発チームのすずきです。

みなさんComposerは使っていますか？（何をいまさら）
弊社の英会話システムはPHPで作られており、パッケージの依存管理にはComposerを利用しています。
新しいパッケージを追加したいときは

$ composer require monolog/monolog

みたいな感じでPackagistから取得することが多いと思うのですが、
今回やりたいこととしてはS3バケットに上がっているパッケージを追加し利用できるようにする ことです。

元々は、弊社オンプレのGitlab上に配置されており、以下の様にcomposer.jsonに記載することで利用しておりました。

{
    "repositories": [
        {
            "type": "vcs",
            "url": "git@bitbucket.org:vendor/my-private-repo.git"
        }
    ],
    "require": {
        "vendor/my-private-repo": "dev-master"
    }
}

上記のサンプルはこちらから拝借🙏

今回は、パッケージをZipしたものがS3にアップロードされている状態で、Composerを利用してパッケージ追加したいと思います。
そのためには自分でpackageを定義する必要があり、私たちの場合はpackageに対して、元々パッケージが定義していたcomposer.jsonの内容を記載することで対応しました。

パッケージが定義していたcomposer.json

{
    "name": "vendor/my-private-repo",
    "description": "this is a private package",
    "type": "library",
    "require": {
        "php": "^7.2.0",
        "ext-json": "*",
    },
    "require-dev": {
        "phpunit/phpunit": "< 7.2",
    },
    "autoload": {
        "psr-4": {
            "Vendor\\Private\\": "src/private"
        }
    }
}

パッケージを利用する側のcomposer.json

{
    "repositories": [
        {
            "type": "package",
            "package": {
                "name": "vendor/my-private-repo",
                "version": "3.1.7",
                "dist": {
                    "url": "https://path-to-aws-s3-bucket/my-private-repo-v.3.1.7.zip",
                    "type": "zip"
                },
                "require": {
                    "php": "^7.2.0",
                    "ext-json": "*",
                },
                "autoload": {
                    "psr-4": {
                        "Vendor\\Private\\": "src/private"
                    }
                }
            }
        }
    ],
    "require": {
        "vendor/my-private-repo": "3.1.*"
    }
}

パッケージが依存している他のパッケージをrequireに記載することでComposerが依存関係を解決してくれます。 また、パッケージを利用する側で不要なrequire-devは削除しています。

参考

getcomposer.org

寒い日が続きますが、来週には春の暖かさがくるようです🤗

Androidのダークテーマ

こんにちは、ネイティブアプリ開発を担当している杉山です。

今回は、Android 10 から利用可能となった「ダークテーマ」のお話です。

ダークテーマとは

Android 10 から利用可能となった黒基調の UI です。

ダークテーマのメリット

• 電力消費を節約！
• 視覚障がいのある方、明るい光が苦手な方にとって見やすさ向上！

ダークテーマを使う

1. アプリのテーマに DayNight Theme を継承させる

/res/values/styles.xml にて以下の設定を行う。

<style name="AppTheme" parent="Theme.AppCompat.DayNight">

MaterialComponents のダークテーマも利用可能です。

<style name="AppTheme" parent="Theme.MaterialComponents.DayNight">

2. リソースディレクトリを切り分ける

修飾子として、日中用には notnight を付け、夜間用には night を付けて、リソースを管理。（ notnight が付いていない場合、通常の values からリソースを取り出す。）

- res
  - values-night
  - values-notnight
  - values
  - drawable-night
  - drawable

3. アプリ内に適用するモードを設定

アプリケーションクラスを継承させたクラスの中で以下の設定を行う。

AppCompatDelegate.setDefaultNightMode([設定するモード])

モード一覧

• MODE_NIGHT_YES ... 常に夜間モードを使用。リソースはnight修飾子の付いたものを使用。

• MODE_NIGHT_NO ... 夜間モードは使用しない。リソースはnotnight修飾子の付いたものを使用。

• MODE_NIGHT_FOLLOW_SYSTEM ... システムの判断に従って判別

• MODE_NIGHT_AUTO ... 自動で判別。リソースは日中の場合 notnight修飾子の付いたものを、夜間の場合は night修飾子の付いたものを使用。

モードが切り替わったことをハンドリング

AndroidManifest.xml 内で以下の設定を行う。

<activity
    android:name=".Activity"
    android:configChanges="uiMode" />

onConfigurationChanged を用いて、設定されているテーマを確認する。

override fun onConfigurationChanged(newConfig: Configuration) {
    super.onConfigurationChanged(newConfig)

    val isDarkTheme = newConfig.uiMode and Configuration.UI_MODE_NIGHT_MASK
    when (isDarkTheme) {
        Configuration.UI_MODE_NIGHT_NO -> Log.d("Mode : ", "通常モード")
        Configuration.UI_MODE_NIGHT_YES -> Log.d("Mode : ", "ダークテーマ")
    }
}

おまけ

ダークテーマに対応しない

styles.xml で、DayNight Theme を継承しない

<style name="AppTheme" parent="Theme.AppCompat.Light.DarkActionBar">

ダークテーマをレイアウトから確認

1. レイアウトファイルを開き、Design タブに切り替える。

2. 画像のようなアイコンが、左上にあるのでクリック。

3. Night Mode をNightに設定。( Not Night = 日中、Night = 夜間 )

まとめ

ダークテーマの対応は意外と簡単にできますが、イメージなどのリソースを作る対応が入ると大変だなと感じました。

ER図 の自動作成を CI に組み込んだ話

塚田です。新人の頃からドキュメントの管理が大の苦手です。

ドキュメントの更新は滞り陳腐化してしまい、必要な時に見直すと使い物にならなかったりします。誰もが経験あるのではないでしょうか。

少しでもその呪縛から解放されるのであれば全力を注ぎたくなる性分なので、 ER図 を自動作成してくれる SchemaSpy を社内で使っている GitLab CI に組み込みました。

今回は SchemaSpy の紹介と、CI に組み込んだ話をしたいと思います。

SchemaSpy とは

DBに接続してテーブル構成などをスキャンして、html としてアウトプットしてくれる機能を持っています。 MySQL や PostgreSQL などをサポートしています。

http://schemaspy.org/

CI への組み込み

弊社のCIのパイプラインでは、GitLab に push すると、自動でテストなどが動くような作りになっています。 そのテストの一環で、DBにスキーマ情報を migration する動きが既にありました。 そこに処理を追加し、CI で作られる DB へ SchemaSpy を繋げるようにしました。

SchemaSpy によって作られる成果物を S3 へ copy、 S3では Static website hosting を有効化にして、静的コンテンツを動かす Webサーバ のように使い、社内IPからのみ繋がるようにしました。

設定内容

.gitlab-ci.yml に追加したのは以下の部分

schemaspy:
  <<: *go_setup
  <<: *tags
  stage: schemaspy
  services:
    - mysql:5.7
  script:
    - make ci-migrate
    - apt-get update
    - apt-get install -y openjdk-11-jre/stable unzip busybox build-essential graphviz
    - wget https://dev.mysql.com/get/Downloads/Connector-J/mysql-connector-java-5.1.48.zip -qO - | busybox unzip -
    - wget https://github.com/schemaspy/schemaspy/releases/download/v6.0.0-rc2/schemaspy-6.0.0-rc2.jar -O schemaspy.jar
    - java -jar schemaspy.jar -configFile ./ci/schemaspy.properties -vizjs
    - mkdir -p ${ARTIFACTS_DIR}/${CI_PIPELINE_ID}/schemaspy
    - mv output/* ${ARTIFACTS_DIR}/${CI_PIPELINE_ID}/schemaspy/.
  artifacts:
    paths:
      - ${ARTIFACTS_DIR}/${CI_PIPELINE_ID}/schemaspy
    expire_in: 3 days
  only:  
    - master
    - development

ER図の作成は全ての branch で動かす必要もないので 現在は限られた branch のみ、SchemaSpy を動かすようにしています。

DBの接続情報は schemaspy.properties に書いています。

# type of database. Run with -dbhelp for details
schemaspy.t=mysql
# optional path to alternative jdbc drivers.
schemaspy.dp=mysql-connector-java-5.1.48/mysql-connector-java-5.1.48-bin.jar
# database properties: host, port number, name user, password
schemaspy.host=mysql
schemaspy.port=3306
schemaspy.db=database
schemaspy.u=root
schemaspy.p=password
# output dir to save generated files
schemaspy.o=output
# db scheme for which generate diagrams
schemaspy.s=public

その後、AWS S3 への push は以下のように定義して、gitlab runner が動くインスタンス自体に適切な権限を付与しています。

document:
  <<: *awscli_definition
  <<: *tags
  stage: document
  before_script:
    - export REF_NAME=`echo ${CI_COMMIT_REF_NAME} | sed -e 's%/%_%g' -e 's%-%_%g'`
  script:
    - aws s3 cp ${ARTIFACTS_DIR}/${CI_PIPELINE_ID}/schemaspy s3://${s3-backet}/schemaspy/${repository}/${REF_NAME}/ --recursive
  only:  
    - master
    - development

S3 ではパブリックアクセスを拒否しております

バケットポリシーで社内の IP のみアクセスできるよう設定を入れています。

{
    "Version": "2012-10-17",
    "Id": "document from designated SourceIP",
    "Statement": [
        {
            "Sid": "document from designated SourceIP",
            "Effect": "Allow",
            "Principal": "*",
            "Action": "s3:*",
            "Resource": "arn:aws:s3:::xxxx-document/*",
            "Condition": {
                "IpAddress": {
                    "aws:SourceIp": "xxx.xxx.xx.xx/32"
                }
            }
        }
    ]
}

パイプライン が pass することを確認すると

S3 にファイルが置かれています。 ブラウザ で以下のような スキーマ情報 を見ることができます。

テーブル情報

自動生成されたER図

これで DB に関係するドキュメント、特に ER図 のメンテナンスから解放されそうです。

ちなみに、mysqldump から読み込ませるやり方はこちらに記載していますので、必要であればご覧いただけますと幸いです。

SchemaSpy で SQLファイル からスキーマ情報を出せるようにした - Tech Tips

それでは！

デザインスプリントを行った話

どうも！デザイナーの渡辺です！

みなさん新年が明け、お仕事が始まってから2週間程立ちましたが

いかがお過ごしでしょうか？(ﾟ∀ﾟ)
私は今年からジムに通い始めて
筋肉痛の毎日を過ごしておりますヽ(=´▽`=)ﾉｲﾀｲｲﾀｲ

さて、今回は昨年末にデザインチームで行った
デザインスプリントについてお話していきたいと思います！

デザインスプリントとは？

そもそもデザインスプリントって？という方もいらっしゃるかと思います。

デザインスプリントはGoogleが開発した
【5日間で価値のあるプロダクトを開発するフレームワーク】
なんだか凄そうですよね( ´∀｀)bｸﾞｯ!

それなら入れない理由はない！ということで
我らデザインチームが新しいプロジェクトで取り入れてみました！
（新しいこと取り入れるのが好きなチームなので(ﾉω・)ﾍﾍ）

5日間の流れ

デザインスプリントでは、5日間でやることが毎日変わってきます。
具体的には下記の流れで行っていきます。

デザインチームで実際にやってみました

1日目

こちらでは、問題点を洗い出し、課題の決定をしていきます。
理解というくらいですので、これでもかっ！というくらいに
知ってる情報を出し認識を深めて行き
課題の決定をしていきます。
ここでは、デザイナーだけでなくフロントエンジニアの方も交え
システム側の課題点も合わせて行いました！
複数人で行うので自身だけでは見えていなかった物が見え
「へー！そんな事あったんだ！」「確かに。それも課題だね」
という声が結構上がります(^^)/

2日目

1日目で見えてきた課題に対し、それを解決する案をひたすら出していきます！

案を出す際に行うのはスケッチ！
こちらはツールではなく、
ひたすら紙に手書きで書いていくことを言います(^^)
黙々とワイヤー案を書いていきます！
これが結構楽しいんですよね(´ω｀)

3日目

それぞれがスケッチしてきた紙を出し合い
全員でブレストをしていき、
どの案で進めるかを決めていきます！
ここではやることの決定ですので、予算であったり、
スケジュール等の観点が入ってくることもあります。

今回私達のデザインスプリントでは
POにも参加してもらい決定していきました！

4日目

ここでは3日目に決定したスケッチを元に
プロトタイプを作成していきます。
我々がプロトタイプ作成に使用したのは【Figma】です！

以前、Figmaに関しても少し記事を書きましたので
ご興味ある方はこちらもご覧ください(*´∀｀)

【レアジョブのデザインチームがFigmaを導入したお話】 https://appeal.rarejob.co.jp/2019/08/06/6116/

5日目

最終日！【検証】です！
5日間の集大成をお披露目する場面ですね！

実際のユーザーを招待して行うこともありますが
今回は社内のプロジェクトに関わる方に実際に見ていただき

FigmaでFBをいただくという形を取りました(*ﾟ∀ﾟ)

1〜3日目までの間に情報を出し切り、
その上で案を出していることでブラッシュアップされ

1人で作業するときよりも
FBの数は少なくなっているように感じます。

頂いたFBを元に今後の動き、修正するのかなどを決めていきます。

実際にやってみて

デザイナー全員の時間を使ってしまうので
他に並行している作業があると
時間の調整が難しいという難点がありますが
プロジェクトが大きければ大きいほど
5日間という短い時間の中で
認識のずれを軽減でき、質の高いプロトタイプを
生み出せるフレームワークだなと思いました！

ただし、逆を言えば小さいプロジェクトだと使う機会が少ないため
自社で行う際のルール作りなどは
精査できるまで時間がかかるのかなという印象です。

5日間がっつりコミュニケーションを取るので
常に黙々と作業しているというチームには
コミュニケーションを図る良い
機会にもなるのかなと思います(๑•̀ㅂ•́)و✧

また個人的には、「みんなで1つものを作っているんだ！」というのが
実感できるフレームワークだったので
やっていてモチベーションアップに繋がっているなと感じました！

中規模、大規模のプロジェクトを行う際には
ぜひデザインスプリントを
試してみてはいかがでしょうか？ヽ(=´▽`=)ﾉ

それではﾉｼ

Kinesis Video Streams （WebRTC）の話をしよう

AKEOME。ジャンボです。 今日はKinesisの話をして優勝していこうと思います。細かいWebRTCに関する説明は飛ばします。

Kinesis Video Streams とは

Amazon Kinesis Video Streams を使用すると、分析、機械学習 (ML)、再生、およびその他の処理のために、接続されたデバイスから AWS へ動画を簡単かつ安全にストリーミングできるようになります。

要するにストリーミングコンテンツを解析する仕組みです。IoT の文脈で監視カメラの映像で不審者の検出や工場の不整製品検知などがユースケースとして想定されます。これまでは映像を受け入れて解析することがサービスの主体でしたが、AWS re:Invent 2019 にてWebRTCのサポートが発表になりました。

今回のリリースでできるようになったこと

Kinesis Video Streams がサポートするオープンソースプロジェクトの WebRTC は、リアルタイムのメディアストリーミング、ウェブブラウザ間のインタラクション、モバイルアプリケーション、シンプルな API によるコネクテッドデバイスを可能にします。 用途としては、ビデオチャットやピアツーピアのメディアストリーミングが一般的です。

この記述のところですね。少し既存のユースケースとは実は違くて、Kinesisが拡張したというより、「WebRTCを使うための基礎的な仕組みを一部AWSが提供し始めた」というのが正しいかと思いました。

具体的に提供されるもの

• シグナリングのためのマネージド型エンドポイント
• STUN/TURNのマネージド型エンドポイント
• 各種SDK

これらはすでに他社製の既存のWebRTCプラットフォームでも提供されており、ここにAmazonが乗り出した感じですね〜気になる流れ 👀

コスト

従量課金製で使用量にコストがかかる形です。WebRTCはシチュエーションによったり、ユースケースで通信料が大きく変わるので見積もりが結構難しかったりするんですが、比較的安価に見えます。具体例を見ている限り基本的には

• 時間
• クライアント数

が大きな変数となります。

試してみる

＊ちなみにAWSの無料範囲外なので気をつけて下さい。

labからサンプルが公開されており、設定さえすればすぐに使えるようになっています。

言葉にすると簡単なんですが、

1. 以下のようにチャンネルを作成
2. 必要なtoken/userを作成して値をSDKに渡す
3. アプリケーションをつくる

これだけ。WebRTCの闇は運用してからなのでこの辺が簡単なのはもはや当たり前な時代・・・

webコンソールにこんな機能があり、作成したチャネルのパフォーマンスをモニターできるのはいいなと思いました。

サンプルコードとSDKの実装、APIのドキュメントから何ができるかを見ていきましょう。

• サンプルコード・SDK
• API Doc

サンプルコード・SDK

READMEにほぼ概要はありますが、気になる箇所をピックアップしてみてみましょう。

// SDKからオブジェクトのイニシャライズ
const kinesisVideoClient = new AWS.KinesisVideo({
        region: formValues.region,
        accessKeyId: formValues.accessKeyId,
        secretAccessKey: formValues.secretAccessKey,
        sessionToken: formValues.sessionToken,
        endpoint: formValues.endpoint,
    });

// 自分で作ったチャネルを指定してここから配信する
const getSignalingChannelEndpointResponse = await kinesisVideoClient
    .getSignalingChannelEndpoint({
        ChannelARN: channelARN,
        SingleMasterChannelEndpointConfiguration: {
            Protocols: ['WSS', 'HTTPS'],
            Role: KVSWebRTC.Role.VIEWER,
        },
    })
    .promise();
const endpointsByProtocol = getSignalingChannelEndpointResponse.ResourceEndpointList.reduce((endpoints, endpoint) => {
    endpoints[endpoint.Protocol] = endpoint.ResourceEndpoint;
    return endpoints;
}, {});

// にあるようにWebRTCの基本通信概念であるICEを自身でハンドリングする必要がある
signalingClient.on('open', async () => {
...
signalingClient.on('sdpAnswer', async answer => {
...

ここから読み取れるのは

• 配信はチャネルごとで基本的な話者（PeerIDなど）を指定するような概念はない
• role {Role} "MASTER" or "VIEWER" があり、双方向配信はこれが前提
• ICEを自分で裁く必要がある
• IE以外はサポートしている
• 実装はちゃんとWebRTCの知識がいる（よりコアに触れそう：小並感）

API Doc

絶対読みましょう。結構大事な制約とかが書いてあります。

• Currently, a signaling channel can only have one master
• A signaling channel can have up to 10 connected viewers

WebRTC Technology ConceptsとかはWebRTCに必要なことをシンプルな文章で登場人物とかをまとめてくれているので勉強になります。一方でこの記述を明記することは「フルマネージドなのはサーバの運用だけでICEをはじめとしたクライアント側の技術はラップしない、ちゃんと理解しろよ」っいうAmazonの優しさと切なさと心強さなので座して読みましょう。

サンプルコードではwebのコンソールからチャネルを作成していますが、リファレンスをみる限りhttpのエンドポイントも提供されており自身で増減させることが可能のようです。

テレビ会議システムで言えば作成されるルームごとにこのハンドリングをするようなイメージなので、webのコンソールだけだとかなりユースケース限られるなと思っていたのでさっと目を通すと良いです。

まとめ

全体的にWebRTCのコア機能に対して基本的なサーバサイドのマネージドサービスとそれを利用するための抽象度低いSDKとインターフェースを提供しています。 現状はまだ多機能とはいきませんが、AWS CloudTrailとの連携などクライアントのイベント管理と解析をできたり、単純にcloudwatchと連携できるのですでにインフラ基盤がAWSなら連携できるメリットがありますね。

ただユースケースとしてライブ配信や解析をベースとしたインターフェースになっているのとSDKの抽象度的に結構余力がないと導入できないと感じました。

ユースケース次第ではハマりますね。

それではハッピーフライデー。🍺